RIAA website hacked

January 20, 2008

When you are as disliked as the RIAA (or MPAA for that matter) by the tech community, you had better make sure your site is bulletproof as it’s going to have a huge target painted on it.  So, to hear that the RIAA website was hacked this weekend isn’t really a surprise (the image shows a previous time they were subtly defaced, and one that I’ve used a few times in presentations I’ve done).  What is a surprise however is that it’s a very simple SQL injection.

http://riaa.com/news_room.php?resultpage=9&news_year_filter=2007%20UNION%20ALL%20SELECT%20BENCHMARK(100000000,MD5(’asdf’)),NULL,NULL,NULL,NULL%20–

What this query does (the malicious data I’ve colored in red) is to force the back-end database server to perform a MD5 hash of “asdf” 100 million times.  This is obviously a very slow operation, and holds up the database from performing other operations, unless of course it times out depending on it’s settings.

Some commenters are claiming that the site was wiped, by modifying the malicious data to perform a DELETE or DROP operation on the database.  Although this is possible, I’m not 100% convinced - the original “hack” could very well have the same observable effects (no content on the site) because the connection times out and the front-end code just doesn’t have anything to display.

I’m always looking out for things to learn in these cases, and unfortunately it’s nothing that people in the webappsec world don’t already know.  Firstly, validation, validation, validation!  The news_year_filter parameter should only have been expecting a number (and one within a “reasonable” range), so if that was done correctly, it would have shut this attack vector.  Several other people have used the vector to show other vulnerabilities like XSS, so clearly there’s some sloppy programming going on there.  Second, is that any long-running operation on the server is an opening for attack.  In this case the operation that took the time wasn’t native and was injected into a query.  However, that needn’t necessarily be so, so identify operations, queries, pages, that take significant time and gage the security risk (e.g. do you have to be authenticated to get to them, GET vs POST, user interaction required, potential for “scripting”) and mitigation’s (e.g. is there a “time-out”, are results cached and reused).  Finally, it is doubly important that the privileges on the database are restricted - if, as best practices dictate, the RIAA website connection to the database was restricted to read-only, at least all their data would be preserved.

Perhaps the blame can’t be entirely put on the RIAA, as there’s some suggestions and good evidence that the vulnerability might have been part of the content management system they are using.  Although there’s nothing wrong with PHP/MySql - there are lots of sites (and projects) out there using these technologies and are secure - it seems a bit strange that such an organization would put so much faith in this “free” software (the CMS included, if indeed the observation is correct) when they are such a target.  It’s just too easy to shoot yourself in the foot.

I guess the first commenter on reddit said it best - “guess that’s the kind of thing you get when you hire more lawyers than programmers”.

Posted in Security