One of the more popular events at Microsoft’s TechEd, yesterday’s ‘HackEd’ saw Auckland’s SKYCITY Theatre packed almost to the last seat with developers and professional techies. Everyone in attendance was there to watch Kirk Jackson (security officer, Xero) and Andy Prow (managing director, Aura Information Security Ltd) deliver an hour of security tales, tech-humour and live hacking on-stage.
The event kicked off with Jackson and Prow detailing some of New Zealand’s most recent hacks and tech flubs, such as the WINZ kiosk debacle, and the launch-day security flaws that saw TradeMe competitor Wheedle close for six months before a quiet reopening in April this year.
The duo also outlined a serious security flaw in last year’s TechEd website, which saw attendees’ passwords included in plaintext in the URL when self-printing registration barcodes online. In a nod to their hosts (and, as they jovially stated, to cover themselves legally), the pair were clear that the issue was caused not by Microsoft or the website host, but by a third-party programmer. They also pointed out that the vulnerability was addressed shortly after it was discovered.
Jackson and Prow went on to speak about ‘application-layer Denial of Service (DoS) attacks’, which are gaining popularity among groups such as Anonymous. Traditional DoS attacks have targeted the network layer – preventing legitimate access to a website or other networked resource by swamping its network connection with requests, or otherwise affecting the network infrastructure. Application-layer DoS attacks target vulnerabilities in specific web or networked applications, and may seek to overwhelm a system by maxing out its database connections, disk storage, CPU, RAM, threads, or network bandwidth.
Denial by RegExOne specific example was a ‘Regex DoS’ – an attack that exploits the way regular expressions are processed in order to max out a single CPU thread or core for an extended period of time. In this manner, only a small number of attacks (equal to the number of threads available on the web server) are necessary to block all legitimate access.
Regular whatsits? Regular expressions are a technique used to define a pattern, which a string of text or numbers can be matched against. It’s a feature supported across many modern programming and scripting languages, and is an exceedingly common means of validating web input (e.g. ‘only numbers are allowed in this field’, or ‘this should be a valid email address’).
The problem is, a perfectly valid, workable regular expression can be written in a manner that generates quite a bit of work behind the scenes when validating certain forms of input. Jackson and Prow demonstrated how an input of just a few dozen characters written into a text field could be used to tie up 100% of a web server’s CPU core for a few minutes, as the web server backtracked through the text over and over trying to validate the field’s contents.
Executioner’s XMLExtensible markup language, or XML, is everywhere. You know, it’s that structure of
Anyway, XML underpins many of today’s applications, particularly but not exclusively websites and web apps, in a continuum of forms – from beautifully defined databasey-structures that some would say should actually be databases, to loosely not-quite XML structures that some would say should actually be plain text files. It’s so ubiquitous that virtually nobody writes code to parse XML any more, besides programming students with assignments to do so, and amateurs who don’t realise there are fifty bazillion parsers out there already, some of which are likely an integral part of whatever programming or scripting language they’re using.
According to Jackson and Prow, many programmers write code that takes an XML file, say one uploaded by a user on a website, and throws it wholesale to one of those black-box parsers in order to get a nice in-memory data structure. What’s the problem with this? The pair demonstrated it with a simple but terrifying example.
XML has a nice little feature called ‘entities’, which are used to represent characters that can’t be expressed in XML itself. For instance, you can’t use a less-than sign in-text within XML, because it represents the start of a tag. Instead, you use the predefined entity <. This is resolved to < when the file is parsed.
You can also define your own entities. Here’s where the fun starts.
The dynamic duo showed off an XML file which defines the entity &m; as &l;&l;&l;&l;&l;&l;&l;&l; – eight of another user-defined entity. In turn, &l; as &k;&k;&k;&k;&k;&k;&k;&k; – and so forth, all the way down to &a; defined as eight normal characters. So, include a single &m; entity in the document, and by my math, that’s 8 ^ 13 = 549,755,813,888 characters for the parser to generate, in memory. Interpreting that one simple XML file will tie up a CPU core and, probably more harmfully, exhaust all memory available to the web server.
Jackson and Prow also demonstrated how in some environments and with some XML parsers, defining an entity as a reference to an external file on the web server would cause the parser to load that file. They used this technique to load win.ini, and attempted to load their ASP.NET server’s web.config file in a similiar manner. The latter attempted failed, but did spit out the exact path to the file they were looking for, showing where the web server was installed and possibly facilitating further exploits.
Not my favouriteOptimistically assuming that the NSA hasn’t cracked the encryption we all rely on to secure the web, seeing ‘https://’ in the address bar is usually a fair indication of security, right? Yeah, there’s a demo for that, too.
Jackson and Prow showed an interesting session-hijack method based around the ‘favicon.ico’ – a website’s ‘Favourite Icon’, though there are many other cases in which the exploit would be equally usable.
Their attack relied on the fact that their server – a fake version of the TechEd website used to demonstrate HackEd exploits – sent all traffic to a logged-in user over HTTPS, with one minor and seemingly innocent exception: favicon.ico. The little icon that appears in your address bar beside a web address, or (hence its name) in your favourites/bookmarks menu.
Everyone sees the same icon, whether they’re logged in or not. There’s nothing ‘secure’ about it – so why spend the overhead used to send it over HTTPS, when you can simply send it over HTTP? It may not even be a developer’s decision: an incorrectly-configured web server could do this as a matter of course.
The problem is, a web server doesn’t simply respond to a request with the file you asked for: there’s a bunch of stuff in the response header that the user never sees. In the case of this demo, the HTTP session token and ASP.NET authorisation token that identify a logged-in user to the web server. This is all sent in the clear along with favicon.ico, potentially accessible to anyone on the same network. At a conference, like TechEd, on an unsecured Wi-Fi network? Yeah, game over.
By intercepting the request for favicon.ico and lifting the necessary tokens from the response header, Jackson and Prow were able to successfully demonstrate a session hijack (gaining the same access as another currently logged-in user), in a matter of seconds.
Check my Dapper black hatNo security or hacking talk is worth its salt* without a mention of SQL injection. It’s a means of attack that, as Jackson and Prow acknowledged, predates the internet. It’s a concept that’s somewhat hard to explain to a non-programmer, but breathtakingly simple to anyone that codes. It’s a concept known to programmers old and young, across any language that can interact with an SQL database.
It’s such a well-known and explored concept that I won’t even try to explain it here. That’s what makes it so surprising that programmers are very, very good at writing code that’s vulnerable to SQL injection attacks.
I won’t go into the attacks demonstrated at HackEd, as they were all completely run-of-the-mill – the kind of thing you’d learn in the first semester of an IT-security class.
What was interesting, though, was Jackson and Prow’s mention of Dapper.NET – a library that’s been gaining popularity as a way for .NET programmers to integrate code and SQL-based data access.
HackEd’s presenters were quick to extol the virtues of Dapper, but pointed out that it makes it easier than ever for programmers to write code that proves vulnerable to the simplest of SQL injection attacks.
At the end of the dayIt’s clear to see why HackEd draws such a large crowd, and why the one-hour session ends with such uproarious applause: it’s fun to laugh at others’ mistakes, and in doing so, recognise and hopefully seek to correct your own.
As I packed up at the end of the session, several developers around me bemoaned their own use of vulnerability-inducing techniques, wondering just how open their own projects may be to attack. That’s a conversation developers should be having, before those products make the next year’s HackEd intro roll.
Five stars, would attend again.
* Sorry, couldn’t resist