Attacks/Breaches
5/23/2012
10:37 AM
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
Cartoon
Current Issue
Dark Reading December Tech Digest
Experts weigh in on the pros and cons of end-user security training.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-5426
Published: 2014-11-27
MatrikonOPC OPC Server for DNP3 1.2.3 and earlier allows remote attackers to cause a denial of service (unhandled exception and DNP3 process crash) via a crafted message.

CVE-2014-2037
Published: 2014-11-26
Openswan 2.6.40 allows remote attackers to cause a denial of service (NULL pointer dereference and IKE daemon restart) via IKEv2 packets that lack expected payloads. NOTE: this vulnerability exists because of an incomplete fix for CVE 2013-6466.

CVE-2014-6609
Published: 2014-11-26
The res_pjsip_pubsub module in Asterisk Open Source 12.x before 12.5.1 allows remote authenticated users to cause a denial of service (crash) via crafted headers in a SIP SUBSCRIBE request for an event package.

CVE-2014-6610
Published: 2014-11-26
Asterisk Open Source 11.x before 11.12.1 and 12.x before 12.5.1 and Certified Asterisk 11.6 before 11.6-cert6, when using the res_fax_spandsp module, allows remote authenticated users to cause a denial of service (crash) via an out of call message, which is not properly handled in the ReceiveFax dia...

CVE-2014-7141
Published: 2014-11-26
The pinger in Squid 3.x before 3.4.8 allows remote attackers to obtain sensitive information or cause a denial of service (out-of-bounds read and crash) via a crafted type in an (1) ICMP or (2) ICMP6 packet.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Now that the holiday season is about to begin both online and in stores, will this be yet another season of nonstop gifting to cybercriminals?