Mar 132012

Hackers Discover US Government Employees Using Work Emails On Porn Websites

The Atlantic
Adam Clark Estes
Mar. 13, 2012
A group of hackers calling themselves Th3 Consortium and  claiming to be affiliated with Anonymous and LulzSec broke into yet,the third porn site it’s hacked in as many weeks, stealing 72,000 passwords and 40,000 credit card numbers.All three porn sites Th3 Consortium has targeted are owned by Luxembourg-based Manwin: Brazzers got hit in mid-February – 350,000 usernames and passwords were stolen — and then came a major hack at YouPorn – a million usernames and passwords were compromised. But the porn network does not seem to be the real target of the attack: the hackers seem most interested in embarrassing government employees who used their official email addresses (for some reason?) to register for a porn site. Foolish government employees beware.

As reports, “According to Th3Consortium, it hacked 27 admins’ names, usernames, e-mail addresses, and encrypted passwords; 85 affiliates’ usernames, plain text passwords, and in some cases, IP addresses; and 82 .gov and .mil e-mail addresses with corresponding plaintext passwords.”

“And of course as this is a porn site,” Th3 Consortium bragged in their release about the attack, “there was no shortage of .mil and .gov emails in their user list.” The hackers’ taunting of government employees could be nothing more than taunting. Those who have seen the data say that there are only a few dozen on the list. 

But the hackers seem to share the view that catching government employees engaged in naughty online behavior — whether it’s watching porn or illegally downloading movies — it refutes the calls for more aggressive enforcement of copyright laws. Fresh out of jail, Megaupload founder Kim Dotcom sounded ready for some blackmail when he told TorrentFreak in an interview, “Guess what — we found a large number of Mega accounts from US Government officials including the Department of Justice and the US Senate.” And we’re not just talking about usernames and passwords in MegaUpload’s case. It’s terabytes of actual files. Luckily for these public officials, the government has control of that data for the time being.

There are three takeaways from the recent rash of porn site hacks. Number one: if you’ve got an account and credit card on file with a porn site, double check to make sure that info is secure. Two: Don’t take the hackers too seriously. While they brag about how tens of thousands of accounts were compromised, those numbers are usually greatly exaggerated. And finally: if you work for the government, don’t sign up for porn sites with your official email address. Taxpayers are paying to keep that address up and running. The least you can do — if only to be courteous — is set up a fake Hotmail account or something. And save the porn for your personal time. We don’t want to pay for that — or any resulting sexual harassment cases — either. 

Nov 052011

Password Hash: It’s Okay to Inhale…
Monday, July 18, 2011
Contributed By: Vulcan Mindm3ld

As security experts, we know the importance of password hashing. Unfortunately, recently compromised systems leads me to believe that their designers, implementers, and management teams which accepted these systems were exposed to too much tetrahydrocannabinol.

In a recent discussion with some friends in the information technology industry, I was shocked when they didn’t understand what I meant by storing passwords as “plain text” instead of a hash.

I had flashbacks of when I was responsible for some production systems many years earlier. Because I was the guy “facing” the auditors, I wanted to get some insight on a new application we were expecting. I had asked a developer how the web application stored user account passwords.

I asked him, “Does it use MD5 or SHA?” and he responded “No. It wasn’t necessary.” He said, “since we must secure shell into the box over an encrypted channel and you must have a password to get into the database then he added it wasn’t worth the performance hit to hash the passwords.”

Of course, I was outraged and began to complain to anyone who would listen. Soon, I was labeled as a nosy systems guy who didn’t know what I was talking about. Some of the developers insisted I wasn’t even qualified to discuss such matters. Nonetheless, I persisted and got my way – but not without a fight.

I explained to some of the managers that a password table is like a “spreadsheet” with rows and columns (Yeah, I had to get that basic). One column contains a user name and the adjacent column is the password. If the database is compromised, this table can be extracted and the attackers will have a list of user names and passwords.

Once they grasped this concept, I explained hashed passwords. If we take the plain text password BEFORE it is entered into the table, we can use a cryptographic function on the plain text in order to store a large hexadecimal string.

The important thing here is that it is not the plain text password which is stored in the database. For example, two highly complex passwords (insert sarcasm) chosen by the finest executives might be “apples” and “applesoranges”:

“apples” – 76c2436b593f27aa073f0b2404531b8de04a6ae7

“applesoranges” – 1748298913aca6c373b52958ec224508a790e5b6

When a user logs into the system, the cryptographic function is called using the password they’ve provided and the result is compared to the value stored in the database for that user. If it does not match, the user is not authenticated and access is denied.

Once they understood the technical aspects of the problem, I assumed they would understand how risky the design was. In the end, it wasn’t my over-simplified explanations and their understanding of the risk, the design was changed because of their fear of not getting their system approved for operations. It is appalling to think that they would have implemented it despite the risk.

I had this encounter several years ago but this kind of implementation continues. The recent IRC Federal and HBGary SQL injection vulnerabilities allowed attackers access to a username/password table stored in the database. IRC Federal’s “experts” simply stored unencrypted passwords while HBGary’s “expert” third-party developers implemented unsalted, non-iterated MD5.

This simple use of MD5 is highly susceptible to dictionary attacks and brute-force attacks. Think of two tables: one, a list of common words and their pre-computed hash. The second is the compromised table. 

To “crack” this password, the stored hash is simply checked against many common dictionary files. A brute-force attack is significantly slower depending on the complexity (e.g., character composition, length) of the user’s chosen password . Of course, attackers can use a cross between a dictionary attack and a brute-force attack called rainbow tables (see RainbowCrack Project for more information).

To defend against these kinds of attacks it is recommended to use “salt” when computing the hash or even use Password-Based Key Derivation Function (PBKDF2) in lieu of iterative hashing.

I am not going to discuss the merits of different algorithms, salting, or other techniques in this post. Instead, I would much rather see interested parties ask developers, implementers, and maintainers the right questions. How are passwords stored? What have we done to protect against SQL injection?

Finally, to compound the problem some of HBGary’s executives used very, very weak passwords which were easily broken. Both IRC Federal and HBGary executives used the same password on many of their other information technology resources including their own email accounts. You might as well have invited the attackers over for cocktails and hors d’oeuvre.

Simple passwords and reusing said passwords has been part of every security professional’s mantra for years. Shame on them.

Direct Link: