Simple mistakes allowed LulzSec hackers to steal sensitive information from the MilitarySingles.com dating website, according to a security specialist.

LulzSec attack Military Singles dating website Imperva report

Imperva published step-by-step details showing how it thinks LulzSec breached server security in the attack in March 2012.

The sensitive information of 170,937 Military Singles members was disclosed and the damning indictment from Imperva's report is that the Remote File Inclusion attack was "nothing new".

Today's Web 2.0 internet format, which allows users to upload their own content such as pictures straight to the server, was highlighted as the Achilles heel.

Imperva pointed out that it is hard to avoid creating a website where users don't interact in this way with the server, with the report stating: "For example, imagine social networks without pictures and webmail without attachments. Very dull indeed."

The analysis found that better filtering would have stopped the rogue file being placed on the site. A filter was put in place by the militarysingles.com website but it only checked the file extension (for example, .jpg or .gif) and was easily bypassed.

LulzSec hackers were able to upload a file in the format 1.txt.jpg and rename it once it was on the server.

The Imperva report said the filter had major flaws.

"The filter seems to trust the content type as specified by a browser - which is a client-side control instead of properly checking files on server side. So an attacker, using a proxy to fiddle with traffic after it had passed client-side security implemented on the browser, was able to change the filename without changing the 'image' content-type," it read.

Once the file was changed from an image to a piece of code, the attacker gained control over the server and the data stored within it. This included sensitive details such as full user name, address, phone number, email address and more.

Imperva said the attack also showed the need for proper password encryption. In the MilitarySingles case, archaic methods of password encryption meant hackers could decrypt the full list of passwords in just nine hours.

"Even when all users details on the application are exposed, passwords are still considered to be sensitive and had the passwords been properly stored, it would be difficult for the attacker to find out the customer's passwords," Imperva's research said.

"In the militarysingles.com hack, passwords were not stored in plaintext but were hashed. How were the passwords breached? The problem was that the hash was created using the MD5 algorithm and no additional salting was involved."

According to one blog, more than 90 percent of the disclosed hashes were leaked were cracked in nine hours.

How To Get It Right

Imperva suggested a number of changes that could have foiled the attack.

In order to refrain from allowing malicious user-untrusted content to abuse the trust that's related with the server's trusted content, the server needs to isolate the original trusted content and the new, user-generated, untrusted content.

Doing so requires:

  • Assigning minimal permissions to the uploaded content - especially not giving the file 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 fbcdn.net domain.
  • Hosting user-generated content on a different machine - that way, even if the code gets executed, it's not executing on the machine that stores sensitive data and resources. That machine needs to be considered as untrusted and have minimal permissions. For example, Facebook stores user uploads on fbcdn.net domain which is hosted on Akamai machines.
  • Another key action - filter the uploaded content. This can be done in several ways:
  • Whitelisting - make sure the content is a valid instance of the file type that the application expects - for example, be certain that the picture is a valid jpeg file.
  • Blacklisting - scan the file for malicious content, using a relevant scanner, e.g. antivirus to detect malware; HTML scanner to detect XSS.
  • All security checks need to be implemented on the server-side and not trust client, as the client cannot be trusted.

Imperva also advised on ways to store user passwords so they cannot be accessed or cracked so easily.

  • Use a modern strong hash function - MD5 is not suitable for modern applications. Best-practice involves using cryptographic hashes from the SHA-2 family, such as SHA-256. In fact, today, NIST specifications
  • Add salt to the hash function - this would make the cracker work much harder as it disables the use of rainbow tables.
  • Enforce a password policy that would force users create less predictable passwords. When users are allowed to choose their password, they tend to choose very predictable passwords such as '123456'.
Facebook