Rogue CA Certificates

So much for a relaxed end to the year. This morning, at the Chaos Communication Congress, security researchers created a rogue CA certificate which is trusted by all major browsers by default. This means, that in effect, they have become a virtual CA and any can certify any website with a certificate signed with their rogue certificate and pass the inspection by the browser. Malicious sites could impersonate legitimate mail providers or banking sites during a Man in the middle attack and completely deceive the user.

The attack targets CAs that continue to sign their certificates using the MD5 hash algorithm. It relies on generating a "collision" between the certificate that is originally requested from the CA, and a duplicate, rogue certificate generated by the attacker. It is also, at the moment, only possible in case the CA generates certificates using predictable serial numbers.

The danger here is that since browsers implicitly trust the certificates that are signed by trusted roots, there is no mitigation possible on the client end and one has to rely on CAs to upgrade their infrastructure.

The surprising fact is that CAs are still using MD5 - 3 years after the first attacks and collisions surfaced. Let's hope that when they upgrade their infrastructure, CAs don't just move to SHA-1 which is also rumoured to be susceptible to collision attacks, but to stronger algorithms like SHA-2 or Whirlpool. Oh, and that they start randomizing the serial numbers for the certificates as well.

More details about the attack can be found here.

Merry Christmas

Another year has gone by and there's been some really neat stuff in the security space. We've seen lots of 'The Internet is coming to an end' kind of vulnerabilities, but for the most work has continued with mild, if any disruption. There has also been a whole lot of debate about full vs partial disclosure and responsible reporting of vulnerabilities, but we're not going to be getting into that here. Here's to a Merry Christmas and all the best for 2009 to everyone! We're all looking forward to a really exciting year ahead over here.

SQL Injection

SQL Injection is at once, one of the most common and most misunderstood vulnerabilities that we've come across in our testing. Part of the fault lies with the remediation steps given by Microsoft which state that one should use stored procedures, without delving into how one should use them.
Are stored procedures immune to SQL Injection attacks? Undoubtedly not! Let's have a look at the following line in a stored procedure

set @query = 'Select * From Users Where UserID Like %' + @userId + '%'
exec (@query)

This procedure is also vulnerable because the parameter is directly appended to the query and then executed. Now, why exactly does SQL Injection occur? It happens because the execution engine takes a string as input, without distinguishing between user supplied data and the query logic. This allows the user to format his input in a way to modify the structure of the query. When the data is passed via parameters, the execution engine is careful to distinguish between the code and data segments, and not allow user input such as ' or -- to break the structure of the query. However, when it is directly concatenated as a string and then executed, SQL injection is possible - even in stored procedures.