Analysis of social site hack: Are risks too great for gov workers?
An analysis of a military dating website hack in March shows how hackers can exploit weaknesses on social media sites and crack poorly protected passwords, and raises the question of whether government employees should “be held to a higher standard” when using such sites.
Data security company Imperva performed a breakdown of the hacker group LulzSec’s attack on MilitarySingles.com, after which user names and passwords of 170,937 subscribers were posted. A key finding was that the attack was made easy by the very lifeblood of social networking sites: user-generated content.
Once inside, the hackers were able to crack weakly protected passwords, many of them belonging to users with military e-mail addresses, leading the reports authors to warn: “Social networking and the public sector don’t mix.”
LulzSec reborn? Military dating data dump may be work of reformed group
Is Facebook the next cybersecurity nmightmare?
Sites that thrive on content uploaded by users operate on a level of trust that can be exploited, according to the report, which detailed how hackers got past MilitarySingles’ filters.
MilitarySingles allowed users to upload their profile pictures. And although it had filters designed to restrict uploads to picture files only, the filters determined a file’s validity according to its file extension, such as common image formats as .jpg, .gif or .bmp. As a result, a hacker could add, say, .jpg to a text file containing malicious code and upload it to the site.
The site’s filter also trusted browsers to specify file types, which would allow an attacker to use a proxy to change a file name to one ostensibly containing a picture file without changing the file’s content.
Imperva researchers found evidence that the hackers use this approach to change uploaded file names to PHP, a scripting language that would make it executable on the server. The report notes that PHP, used by about 77 percent of Web applications, is vulnerable to Remote File Inclusion attacks. “That’s probably how the LulzSec attacker has obtained control over the server,” the report states.
Once hackers had control of the servers, they also had access to the data, including passwords, which were hashed but with the MD5 algorithm that hadn’t been strengthened. The report cites an IQ Security analysis concluding that 92 percent of the password hashes were cracked within nine hours.
(On top of having weak protection, many of the passwords were easily guessed. A word graphic built from the passwords used on the site shows many of the usual suspects as the most popular choices: “123456,” “password” and “iloveyou” lead the way, followed by some that could be common among other military sites, such as “military,” “marines,” “ranger” and “freedom.” Some first names, some animals and at one least expletive also were popular.)
Web 2.0 applications, including social networking sites, are here to stay, the report notes, adding that user-generated content, “the main driver of today’s Internet, is also its Achilles' Heel.”
When combining the risks of these types of applications hackers’ increasing use of social engineering tricks to get inside networks and frequent targeting of government users, the report suggests that public employees might need to do more than other people to protect themselves. “Imperva calls into question if military and government employees should be held to a higher standard when it comes to social networking,” the authors write.
A start on those higher standards would be password encryption on top of strong password policies. The report recommends using SHA-2 hashes, such as SHA-256, as recommended by the National Institute of Standards and Technology, and adding “salt,” or random bits that make cracking the algorithm even more difficult.
On file uploads, the report recommends:
- Assigning minimal permissions to uploaded content, especially not allowing executable permissions.
- Hosting user-generated content on a different domain. That way, even if the code is malicious it’s not evaluated in the context of your site. For example, Facebook stores user uploads on the fbcdn.net domain.
- Hosting user-generated content on a different machine, so that code that is executed won’t be on the machine storing sensitive data and resources.
- Whitelisting, to make sure the content is a valid instance of the file type that the application expects, such as a valid JPEG file.
- Blacklisting, scanning files for malicious content, using a relevant scanner and as antivirus to detect malware or an HTML scanner to detect cross-site scripting.
- Implementing all security checks on the server side; do not trust the client, as the client cannot be trusted.