Recovering from a hack

At the end of last week, I got a message from my sister about a problem with her email account. It is a Google Apps for your Domain account and luckily, I don’t manage it! Around the same time I got her message, I received email from Google that her account was suspended. Turns out when I setup the Google account, I added an admin account for me and had email forwarded to my main email address. This turns out to be a good thing as I was able to reset her password and get her going again. My sister explained that she had checked her email from her work Windows machine and it had some type of virus/malware on it and that caused her account to be compromised. Ouch. Like a good brother, I helped get things going again and told her (and the rest of my family) to enable 2 factor/2 step authentication everywhere it was available. In addition, I told her never to check her Google email from her work computer and just use her phone. That’s probably good advice; don’t use machines that aren’t under your control if you can help it. Email can wait and with a smartphone, it is easy enough to check mail on the phone.

Her email address (not the account) was then used to send a bunch of spam. Unfortunately, there isn’t much that can done about it. However, since I have control over the DNS for her domain, I setup SPF and DKIM so that any service that implements either or both of these will mark any mail that doesn’t originate from Google servers as spam. Email that originates from a server not identified by SPF will have something like this in the header:

Received-SPF: fail (google.com: domain of person@example does not designate 185.27.28.62 as permitted sender)
client-ip=185.27.28.62; Authentication Results: mx.google.com;

spf=fail (google.com: domain of person@example does not designate 185.27.28.62 as permitted sender)
smtp.mailfrom=person@example.com

Whereas legitimate email will look like this:

Received-SPF: pass (google.com: domain of person@example.com designates 2607:f8b0:400e:c03::232 as permitted sender)
client-ip=2607:f8b0:400e:c03::232; Authentication-Results: mx.google.com;

spf=pass (google.com: domain of person@example.com designates 2607:f8b0:400e:c03::232 as permitted sender)
    smtp.mailfrom=person@example.com; dkim=pass header.i=@example.com

(This SPF pass also shows a DKIM pass.)

Many providers (such as Gmail) use SPF and DKIM to mark messages as spam; Gmail doesn’t flat out refuse the email, but some providers will. For anyone that receives spoofed email from a person whose domain uses SPF and DKIM, I’d recommend letting the provider know about this. SPF has been around for years and takes just a few minutes to setup.

While email is still going out using my sister’s email address, there is absolutely nothing she (or I) can do about it.

Lessons learned:

1. Turn on SPF and DKIM on domains.
2. Use 2 factor/2 step authentication where available.
3. Don’t use untrusted computers.

I thought one hack related problem was enough for a week, but the world thought I could handle another. While I was investigating an SSL problem at work, I checked this blog to make sure that everything was using SSL. I have now redirected all traffic to SSL and should get the lock icon in the browser bar. In Safari, the lock icon only appears if ALL elements on the page use SSL, so I went through last week and make sure that all elements, including the Amazon links, used SSL. When I loaded my page, I saw the lock icon and then saw it go away. I used the tools in Safari to see that there were some elements loading off unknown websites. Google searches yielded information about some malware on Windows machines affecting WordPress sites. OK, I don’t use Windows except in limited cases and don’t use it to browse the web. I started digging around and found out that the header.php file in many of the themes on my site had some JavaScript injected in them that was obfuscated and when it was executed, injected that malicious code that loaded http (not https) sites. After I removed all the themes, except for 1 and replaced the theme I used, the malicious code was gone. I changed my WordPress password and that should have been that.

I backup my virtual server daily and then sync them to my laptop, so I started going through the backups to figure out when the code was modified. It appears that the code was modified right around when WordPress 4.3.1 came out. That is quite coincidental and scary. I couldn’t pinpoint the exact date or method of injection, but WordPress is a constant target for hacks and is patched all the time for security issues.

So now I’ve cleaned up this mess and disabled a bunch of plugins. While I hope this doesn’t happen again, I’m not sure what I can do to protect my site. I’ll keep a closer eye on the logs and see if I notice anything.

Dealing with this kind of thing keeps me up at night and gives me heartburn. It is too bad that criminals and miscreants don’t have better things to do than to cause problems for others. My wife believes in karma, and I’m sure that those that perpetrated these hacks will get what’s coming to them.