An Analysis of A NASA Dbase Hack-and-Dump

This is just another in a long string of NASA security breaches

[Editor’s note: this analysis predates any official announcements by NASA]

Recently, some news of a NASA hack-and-dump passed my twitter deck. I decided after watching a few of my friends re-tweet the news that it might be worth checking out. At least I’d see if I could perform some password analysis on any dumped credentials, or even test out the new Crucialpoint Cloudera Hadoop password cracker on any leftover hashes. What follows is a step-by-step methodology of how I put together the pieces on the hack, and what I think likely happened based on my experience as a web application hacker/programmer.

First, I followed a re-tweet from someone I follow to this user account on twitter: https://twitter.com/#!/d4op. The user is a prolific poster about security vulnerabilities and has a long list of tweets linking to pastebin.com drops with account credentials. The NASA link is but one of many. I follow the link in the tweet to this pastebin paste: http://pastebin.com/W2K3pTyX, and from there, to a mediafire download: http://www.mediafire.com/?962aq85rgchjs7d.

I unpacked the RAR file to find a .sql dump script, a file typically used to restore the database and it’s contents in the event of data loss. Literally it’s a backup of the SQL data. A few quick searches shows that, true to it’s name, it contains data from the Solar and Heliospheric observatory (SOHO) database according to tidbits of data inside of the dump, the filename, and a few other markers.

Within the dump I was unable to find any credentials, mostly it contains instrument data tables, articles, and other data of scientific and academic interest. It does not appear as though there is any actionable data (from a security standpoint) contained within the dump. This may mean that either the attacker did not push the attack for more, or that they were confined to accessing a single database from within a vulnerable database application. In any event, it is clear that this database dump is publicly-accessible information from the SOHO website resources.

If it’s a SQL dump, it’s likely to be a SQL injection (one of the most commonly-exploited vulnerabilities). Some of the other disclosures mentioned in the twitter account also appeared to be SQL-injection related, so these factors started me searching for user interactions with the NASA database — specifically search functions. Search functions are great targets for XSS and SQL injections. Lo and behold, one such search function exists, and it looks to have been written a great deal of time ago: http://seal.nascom.nasa.gov/cgi-bin/bib_ui_seal

I did not attack/test the website in question to confirm the vulnerability of any SQL database application (that’d be illegal without permission), but I’d say there’s a pretty high likelihood that the SQL dump was caused by either an incorrect setup on the database itself or a SQL injection from that page due to the outdated programming methodologies it is apparently using (CGI) and the primitive layout structure of the view (tabular layout, popular in late 1990′s and early 2000′s).

For more information about SQL vulnerabilities or other kinds of web application vulnerabilities, I recommend starting here: https://www.owasp.org/index.php/SQL_injection OWASP is a great resource for developers, managers, and security personnel to get together, compare notes, and build secure websites.