"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."

Monday, 27 September 2010

One of the projects I'm working on heavily uses a ReST API and performs a lot of XML processing. Recently we've had some serialisation errors when processing some of the XML, resulting in a .Net error throwing:

System.InvalidOperationException: There is an error in XML document (1, XXX). ---> System.Xml.XmlException: XXX, hexadecimal value XXX, is an invalid character.

You can encode a massive range of characters in XML documents, but there are some non-pritable/control characters that are not supported. Legal non-pritable/control characters include tab (xx09), carriage return (xx0D) and line feed (xx0A). For printable characters it's the legal characters of Unicode and ISO/IEC 10646.

Tuesday, 21 September 2010

The ASP.Net vulnerability that was announced prior to the EkoParty conference in Argentina last week, initially sounded a lot like a whole lot smoke and not much fire. I read the summary of the exploit and belittled it in a blog post, telling people not to panic. I did however decide to review the slides of the technique used to expose the vulnerability as it all sounded rather interesting. However, I wish I hadn't as it soon came to light that the vulnerability was more serious than previously thought. Microsoft agreed and released a security advisory.

What can the attack do?

The attack is relevant to all versions and flavours of ASP.Net and is able to decrypt ViewState data, not an issue as long as you don't store sensitive info in the ViewState - which you shouldn't!

The real issue arises if using ASP.Net 3.5 SP1 or above, the attacker could use this encryption vulnerability to request the contents of an arbitrary file within the ASP.Net application i.e. the web.config.

How the does it work?

The attack makes use of cryptographic oracles. An oracle in the context of cryptography is a system which provides hints as you ask it questions. ASP.Net acts as a padding oracle in this case. Allowing an attacker to send chosen cipher text to the server and learn if it was decrypted properly by examining which error code was returned by the server (and even time taken). If the attacker makes enough requests, they can learn enough to successfully decrypt the rest of the cipher text. The attacker can then alter the plain text and re-encrypt it as well.

Silence that Oracle!

By returning only one application error page no matter what the error effectively silences the oracle and the attacker can no longer gain the info they need to decrypt your encrypted site data. Not ideal in web apps,

Anything else?

Yeah actually! Any sensitive files on your server within your application should be encrypted. For example your connection strings or your username and passwords in your web.configs should be encrypted.

It soon became obvious that the article was a little bit sensationalist to say the least (see quote above). Basically the exploit is low-risk. You should only be worried if your applications aren't communicating over SSL and if you have put sensitive information in you ASP.Net application's cookies and are trusting the cookie data blindly. Sensitive data should all be stored server side - but you knew that anyway!

Needless to say, I've not wrote any code lately that checks for an SuperUser=true value in the cookie!!!