Attacks/Breaches
5/23/2012
10:37 AM
Connect Directly
RSS
E-Mail
50%
50%

7 Lessons From MilitarySingles.com Hack

LulzSec Reborn hacktivist group exploited the site's poor security checks on user-uploaded content, made away with easily cracked passwords.

Want to stop hackers from stealing sensitive data about your users? Then you must properly encrypt and salt stored passwords, subject any user-uploaded content to rigorous server-side security checks, and put mechanisms in place to detect when an attempted breach is underway.

Those are just some of the findings highlighted in a new study from Web application firewall vendor Imperva that analyzes the March 2012 attack by LulzSec Reborn on the MilitarySingles.com website. Ultimately, the hacktivist group disclosed sensitive information on 170,000 members of the online dating site.

How can website operators prevent their site from being hacked like MilitarySingles.com? Start here:

1. Get breach detection. The last public statement from MilitarySingles.com dates from March 28, 2012, when an administrator continued to deny that the site had been hacked, despite attackers releasing a decrypted user database--allegedly from the site--and then uploading an arbitrary image to the site. (The parent company of MilitarySingles.com, ESingles, did not immediately respond to a new request for comment.) Numerous security experts believe the site was indeed exploited, but that administrators had failed to spot the breach. "A denial-of-service attack is visible; you can see that the site is unavailable," said Tal Be'ery, the lead Web security researcher for the Imperva Application Defense Center. "But when all of the data is stolen--which is a much more grave and serious problem--the hacker can do it without leaving any trace, if you don't have the right equipment." Attackers with commercial or economic aims in particular, he said, rarely leave obvious traces

[ For more security lessons learned the hard way, see 9 Lessons From Utah Data Breach. ]

2. DDoS attacks remain a last resort. A recent Imperva study of an Anonymous attack against the Vatican website found that while hacktivists do launch distributed denial of service (DDoS) attacks, it's often not their first attack-type choice. "Hacktivists prefer to hack websites with Web application vulnerabilities, because if there are vulnerabilities, it's a lot easier than creating a denial-of-service attack," said Be'ery. "You could say that a denial-of-service attack is the last resort of an attacker; he hasn't found any easier way to hack into the server."

3. Don't trust Web 2.0 functionality. With MilitarySingles.com, "attackers abused a file-upload mechanism that was only supposed to be used for pictures, and were able to upload an executable file, execute it, and take over the server," he said. Accordingly, treat any such must-have website functionality that adds a security risk with extreme caution. "You can't imagine a dating website that doesn't include pictures, so you must include this functionality, but you also must do it safely," said Be'ery. "Web 2.0 is all about sharing user content, but when you allow users to upload arbitrary data into your Web servers, this is a problem, because usually a file on your server is something that's trusted." And not least by the server's operating system. In other words, watch for all weak points attackers can potentially abuse.

4. Segregate uploaded files. With a server tending to trust files stored on the server, do what Facebook and Google do: keep user-uploaded content away from critical servers in case it's malicious. "You can see that pictures on Facebook aren't served by Facebook.com, but by a different domain name, and there are different servers, permissions, and environments," said Be'ery. "[Code] isn't allowed to execute on those servers, and they also validate the content of that file. If it's supposed to be a picture, then it's validated--on the server side--that it's a picture and not some executable code."

5. Validate all user-provided content. When assessing files, don't just trust client-side validation mechanisms. In the case of MilitarySingles.com, for example, "the site was trying to validate the uploaded file with the picture in it, but it used client-side mechanisms," explained Be'ery. Such checks--typically handled using JavaScript--are useful for error-checking and helping warn users if they're uploading the wrong type of file, but an attacker can easily defeat such a mechanism, according to Be'ery. Similarly, make all security checks on the server side too.

6. Apply modern password hashing. After exploiting the MilitarySingles.com site, attackers accessed a database containing users' passwords, which were hashed using the MD5 algorithm. "They weren't stored in plaintext, but MD5 is an outdated algorithm these days--known to be broken since 2004--and it's very easy to brute-force the hashed password back to the root password," said Be'ery. "So hashing is a good way to store the passwords, but you need to use updated algorithms ... and SHA-256 is a good candidate."

7. Salt passwords. The site also failed to salt its passwords, which would have made them even more difficult to crack. "Salt means using an arbitrary string that you concatenate to the password before hashing it, and it really creates a unique password," said Be'ery. "If you don't use any salt, it means that if a user uses any popular password, such as '123456' ... then all of the '123456' passwords will end up with the same hash." This makes them easy for an attacker to spot and crack. "But if you salt it, say with a unique number," Be'ery explained, "then every password will have a different hash, making it more difficult to brute force and analyze the password behind the hash."

At a time when cybercrime has never been more prolific and sophisticated, budgets are being cut. In response, IT is taking a hard look using third-party services--outsourcing--to meet security challenges. Our Making The Security Outsourcing Decision report outlines the various security outsourcing options available. (Free registration required.)

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-6306
Published: 2014-08-22
Unspecified vulnerability on IBM Power 7 Systems 740 before 740.70 01Ax740_121, 760 before 760.40 Ax760_078, and 770 before 770.30 01Ax770_062 allows local users to gain Service Processor privileges via unknown vectors.

CVE-2014-0232
Published: 2014-08-22
Multiple cross-site scripting (XSS) vulnerabilities in framework/common/webcommon/includes/messages.ftl in Apache OFBiz 11.04.01 before 11.04.05 and 12.04.01 before 12.04.04 allow remote attackers to inject arbitrary web script or HTML via unspecified vectors, which are not properly handled in a (1)...

CVE-2014-3525
Published: 2014-08-22
Unspecified vulnerability in Apache Traffic Server 4.2.1.1 and 5.x before 5.0.1 has unknown impact and attack vectors, possibly related to health checks.

CVE-2014-3563
Published: 2014-08-22
Multiple unspecified vulnerabilities in Salt (aka SaltStack) before 2014.1.10 allow local users to have an unspecified impact via vectors related to temporary file creation in (1) seed.py, (2) salt-ssh, or (3) salt-cloud.

CVE-2014-3587
Published: 2014-08-22
Integer overflow in the cdf_read_property_info function in cdf.c in file through 5.19, as used in the Fileinfo component in PHP before 5.4.32 and 5.5.x before 5.5.16, allows remote attackers to cause a denial of service (application crash) via a crafted CDF file. NOTE: this vulnerability exists bec...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Three interviews on critical embedded systems and security, recorded at Black Hat 2014 in Las Vegas.