Web Hack Analysis, Part 3
Web Site Hacked
Web Hack Analysis Part 2
Web Hack Analysis Part 3
I believe I’ve identified how the hack on my websites occurred, and it wasn’t a WordPress vulnerability. It looks like the hacker got my Linux user password somehow, and then used ftp to login and modify the files on my web sites. Using the Linux command “last”, I generated a list of all logins from the past month, showing the method of login and the IP address. The result is shown above (I’ve blurred out my username because I’m starting to get paranoid, but it probably doesn’t matter).
There are lots of logins from 73.15.247.250 – that’s me. Some were console logins using ssh, and some were ftp logins. But on July 10 at 4:53 AM, there was an ftp login from 104.238.150.48. And not coincidentally, my site’s index.php file was modified 1 minute later, at 4:54 AM. Bingo.
Unfortunately the logs only go back a few days, so I can’t find any earlier instances of suspicious logins. And the FTP logs don’t even go back as far as July 10, so I can’t tell exactly what the hacker did when he connected by ftp.
So how did somebody get my password? Most likely it was due to my use of plain-old ftp for transferring files from my local machine to the web site, which sends my password over the internet in plaintext every time I log in. I knew it was insecure, but I did it anyway because it was convenient, and I figured “what could happen?” Well, this is what could happen. So I’ll be using sftp from now on.
If you’re a security guru or Linux know-it-all type, feel free to tell me what a dumb-ass I am. Believe me, I’m telling myself the same thing.
Read 7 comments and join the conversation7 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
So your attacker is in Japan.. Contact his ISP..
http://www.ip-tracker.org/locator/ip-lookup.php?ip=104.238.150.48
It’s an IP from a popular VPS host, Vultr. It’s likely just another compromised box…
Steve, SSH / SFTP with certificates is the way to go. Disable password login completely. Unless someone steals the keys off your computer / backups you’re completely safe.
It’s quite unfortunate that you don’t have older logs. That prevents a more detailed analysis.
But there are two things that you have missed:
1. Passwords can be guessed. I don’t think you used something stupid like 123456, or your website would have been successfully attacked about every two minutes. But from my experience with webservers, brute force attacks are quite common.
While there are some ways to make good passwords, most people use simple passwords and add some “decoration” that can easily be guessed (“I can’t use ‘ford’, so I’ll use ‘ford1234’. Stupid computer!”). Try to use ssh with public keys, preferably large ones, preferably with state-of-the-art algorithms (currently: elliptic curves, e.g. Curve25519 by djb).
If you have to use passwords, don’t invent them, use a completely random key (throw dices to generate ASCII codes, read from /dev/random) and make it as long as possible. Change the password, preferably every few days. Store the password ONLY offline, i.e. on a piece of paper.
As soon as you have ssh running, disable both ftp and telnet. You don’t need them any more, and they make your system vulnerable. If there is no obvious way to disable them (shared hosting), change the ftp and telnet passwords to something unguessable (200 or 1000 random characters or something like that). The same applies to ssh: If you can’t disable password logins via ssh, make the password unguessable. You don’t need the password, because you login via SSH using the public key algorithm.
2. The other way to “accidentally publish” passwords is malware on your computer. There are some programs that search your computer for stored passwords. Some stupid FTP clients store the password trivially encrypted, e.g. XOR with a constant key, some even more stupid FTP clients store the password in plain or write it to log files. Run a malware scan on your computers, preferably one that runs outside your operating system (i.e. boot from a fresh malware scanning live CD/DVD).
Even if you don’t find malware, consider your current password “published”. Change it, make it hard to guess, switch to SSH as soon as possible. If possible, change your account name, too.
Consider reverting your computer to a backup from before the attack, especially if you found malware, hoping that the malware was installed shortly before the attack. If you want to be sure/paranoid, wipe your harddisk/SSD and install your operating system from its original CD/DVD.
Tux2000
Good suggestions, thanks. I’ve been using SSH all along, so it’s only FTP that was an issue. I’ve now configured things such that it’s impossible to log in with vanilla FTP even if I wanted to. And telnet was never enabled.
I tend to doubt the password was guessed with a brute force attack – it was a fairly long string containing several words with some capitalization and punctuation substitutions thrown in. But I can’t be sure, of course. And I agree local malware is another possible cause that I need to rule out.
What’s interesting is that this was clearly a PHP-centric hack, meant to modify the PHP code of an existing web site. And I’ve since located at least one other web site that was hit with the same hack, so it’s not anything that was specific to me. But if my password was stolen with packet sniffing or malware, the hacker would have had no idea what he was stealing the password for – it might have been some random database password, or something else non-web, or just my Facebook password, instead of the password for a PHP-based web site. So the hacker would need to steal all these passwords, then review each one somehow to determine what the password was for, and what hacks he could apply to that type of account. That sounds like a slow, manual process, and the opposite of what I would imagine a hacker doing.
Thinking like a hacker, if I were designing some evil code meant to be injected into PHP web sites when they generate pages, I would look for a PHP-based security hole with which to inject the evil code. That way the whole thing could be automated, and would already know that a PHP-based site with the security hole was a viable target for the evil code. I’m a little surprised by the fact that this doesn’t seem to have been what happened in my case.
Maybe my site *was* originally compromised by a PHP-based security hole. Could that have been exploited to give the hacker a path to login over FTP, as shown in the the “last” logs? I don’t think so. There’s nothing about gaining shell access that would automatically give him my password, and I know he didn’t change my password. I doesn’t quite all add up, I think, but maybe I’m looking at it the wrong way.
I’d say your steaming right along there Steve. FTP alone should never have been enabled. How it was enabled would make for an interesting response. I suggest you ask your provider to tell you what happened and why.
Ideally the logs should cover at least the entire month, perhaps longer. Oddly enough on my site, they go back to the entire time the whole thing was first spun up, that is after I reinstalled everything. And sadly I sometimes do see the kinds of traffic that could be used to either crash it, or compromise it.
Another couple of suggestions for you:
First, run SSH on a port other than the standard port 22. Use a high port (20000-65535). This will help prevent finding the port using an NMAP scan of your machine (though only slightly; this is a “security through obscurity” tactic).
Second, if you have a static IP address that you’re managing this machine FROM (ie, at home), use Linux’s IPTABLES to only allow connections into your machine from your IP address on the SSH port you chose.
Third, use fail2ban to limit the number of connections per minute and failed connections to a given service.
Fourth, make sure you keep your WordPress up to date!