Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Attacks/Breaches

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.)

 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/3/2020
Pen Testers Who Got Arrested Doing Their Jobs Tell All
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/5/2020
Browsers to Enforce Shorter Certificate Life Spans: What Businesses Should Know
Kelly Sheridan, Staff Editor, Dark Reading,  7/30/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-17366
PUBLISHED: 2020-08-05
An issue was discovered in NLnet Labs Routinator 0.1.0 through 0.7.1. It allows remote attackers to bypass intended access restrictions or to cause a denial of service on dependent routing systems by strategically withholding RPKI Route Origin Authorisation ".roa" files or X509 Certificate...
CVE-2020-9036
PUBLISHED: 2020-08-05
Jeedom through 4.0.38 allows XSS.
CVE-2020-15127
PUBLISHED: 2020-08-05
In Contour ( Ingress controller for Kubernetes) before version 1.7.0, a bad actor can shut down all instances of Envoy, essentially killing the entire ingress data plane. GET requests to /shutdown on port 8090 of the Envoy pod initiate Envoy's shutdown procedure. The shutdown procedure includes flip...
CVE-2020-15132
PUBLISHED: 2020-08-05
In Sulu before versions 1.6.35, 2.0.10, and 2.1.1, when the "Forget password" feature on the login screen is used, Sulu asks the user for a username or email address. If the given string is not found, a response with a `400` error code is returned, along with a error message saying that th...
CVE-2020-7298
PUBLISHED: 2020-08-05
Unexpected behavior violation in McAfee Total Protection (MTP) prior to 16.0.R26 allows local users to turn off real time scanning via a specially crafted object making a specific function call.