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
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-2808
Published: 2015-04-01
The PRNG implementation in the DNS resolver in Bionic in Android before 4.1.1 incorrectly uses time and PID information during the generation of random numbers for query ID values and UDP source ports, which makes it easier for remote attackers to spoof DNS responses by guessing these numbers, a rel...

CVE-2014-9713
Published: 2015-04-01
The default slapd configuration in the Debian openldap package 2.4.23-3 through 2.4.39-1.1 allows remote authenticated users to modify the user's permissions and other user attributes via unspecified vectors.

CVE-2015-0259
Published: 2015-04-01
OpenStack Compute (Nova) before 2014.1.4, 2014.2.x before 2014.2.3, and kilo before kilo-3 does not validate the origin of websocket requests, which allows remote attackers to hijack the authentication of users for access to consoles via a crafted webpage.

CVE-2015-0800
Published: 2015-04-01
The PRNG implementation in the DNS resolver in Mozilla Firefox (aka Fennec) before 37.0 on Android does not properly generate random numbers for query ID values and UDP source ports, which makes it easier for remote attackers to spoof DNS responses by guessing these numbers, a related issue to CVE-2...

CVE-2015-0801
Published: 2015-04-01
Mozilla Firefox before 37.0, Firefox ESR 31.x before 31.6, and Thunderbird before 31.6 allow remote attackers to bypass the Same Origin Policy and execute arbitrary JavaScript code with chrome privileges via vectors involving anchor navigation, a similar issue to CVE-2015-0818.

Dark Reading Radio
Archived Dark Reading Radio
Good hackers--aka security researchers--are worried about the possible legal and professional ramifications of President Obama's new proposed crackdown on cyber criminals.