Sometimes, even the best of us can get a good lesson in security.
Last week, I found out that my website was attacked by crackers. Notice I use the word ‘crackers,’ not ‘hackers’, because hackers are not crackers, and it’s important to maintain the distinction. From what they left I can tell that they clearly fall in the black-hat camp. If I’d gotten a warning e-mail or a message on my site to tighten my security, I would take it as a reminder to batten down the hatches. But since they just left a juicy payload, I can assume that they’re up to no good.
From looking at the files they left, I can tell they wanted continuing access to the shell account on my web host, and they wanted to do so in secret. Since I work in web programming, I’ve seen my share of more-conspicuous payloads. These are usually surreptitious JavaScript files, plopped at the end of legit PHP scripts to do nasty things. Most of what I’ve seen have been little snippets of code that act as drive-by downloaders, trying to pull malicious executables onto hapless users’ computers. The only thing that my attacker’s payload did was grant PHP execution and shell access. Not damaging to anyone who happens across a compromised site, but potentially damanging to me — it essentially gave them free reign of my SHH account.
I could speculate about what they wanted to do. There are a lot of ways to do nasty things on the web. PHP is web-aware enough to allow them to do as they please and ( assuming they’ve covered their track properly) not get caught, either. But I doubt they were able to get much nastiness accomplished, because they executed their attack sloppily: they dropped their payload in the wrong directory. They put their files one level above my web root, meaning that the scripts were inaccessible over the web. At first I thought they may have found an exploit in my framework to allow access to anything on the filesystem, but after reviewing their code, I can see that this is not the case. I guess they wanted to get in, drop off the files, and get out. They may have even made a second attempt after determining that the first one didn’t work; I found two files with exactly the same code.
How did they do it? I’m not certain, but I have an idea. The only web app I use is WordPress, and I’m updated to the current version, so this is an unlikely point-of-entry. They would have to know about an exploit that’s not been reported yet, which is possible, but doubtful.
Much more likely is that they managed to guess or sniff my password. I’m the guilty one here, as I was using a simple password that I’ve been using for years, which had little variation, was dictionary-based, and was much too short. In addition to that, I’ve got a webcam at home that posts images fairly frequently (at regular intervals), and it used the same account as my main FTP/Shell account. As you may know, FTP passwords are sent in cleartext, so this was definitely a potential point of entry. Assuming that the password was the point of failure, I’m lucky that they didn’t do more damage, as I used the same password for shell access, MySQL, and even my web control panel, so they theoretically could have locked me out of everything. I’m hypothesizing here, but I’d guess such an attack would be counterproductive; I think they just wanted another remote-control node on the web to carry out any dirty business they happened to think up.
Of course, I took steps to ensure that things are more locked down, starting with changing every password associated with this site. I did this as soon as I found out, and before anything else, to sever any venues they might have had to retaliate against me. Then I checked WordPress for updates, just in case there might have been an exploit I missed. Next, I updated how my webcam saves the periodic images and created a new account specifically for it. Finally, I did a quick review of my code base, making sure they hadn’t left another way to re-gain access. Basically, I pulled down my whole site and did a global search for any of the crackers’ friend functions: eval(), the base64 functions, system() and friends, and file-related functions. I’ve still got to re-upload all the code to feel 100% safe again, but I’m pretty certain that nothing slipped by.
Stay tuned, because after I’ve further reviewed what they left and when I’ve done a bit more research, I’ll post an analysis of the code itself.
Updates via 