“Grab my iPad and lookup this web site.”
My friend’s iPad was sitting next to me so I grabbed it, performed a quick Google search, and clicked the first link. Nothing that doesn’t happen millions of times a day.
Only I didn’t land on the site we were looking for. I landed on a page with bright, flashing graphics claiming that I had won a free iMac. It wasn’t a popup. And the URL was clearly unrelated to the one I had clicked.
Puzzled I went back to Google to see if I had clicked an ad link by accident. I had not. The search produced the site my friend was talking about as the first result, and I had tapped that URL. I tapped it again and landed at the site we were looking for.
This isn’t right.
I opened Safari’s history and sure enough the redirect and scam site URL were still there. If it had been a Windows PC I would have assumed that it was infected by malware. But this was an iPad that had never been jail broken. Nothing is 100% secure, but the odds of malware on iOS are slim.
I pulled out my phone, made sure I was on the cell network to eliminate the possibility of a compromised router, and retraced my steps. Sure enough the first time I clicked the link I landed on a scam page. This time seizure inducing graphics let me know that my Flash plugin was out of date and needed to be updated. On a device that cannot run Flash.
The next day I did more testing to determine the problem and contacted the web site owners.
Hackers Are Getting Creative
I won’t link to the site in question because I do not want to cause them any embarrassment, and they immediately corrected the problem after I contacted them. Basically their site had been compromised with redirect code on the home page. The malware would only redirect a visitor with no prior cookies for the domain. But it would allow the legitimate code to write cookies before performing the redirect. This way a first time visitor would be redirected. But a frequent visitor, or a person who tried a second time, would get through. (It doesn’t appear that a single cookie controlled this, i.e. the redirector itself was not writing a cookie.)
Doing this accomplishes several things:
- The site owners and regular visitors are unlikely to notice that anything is wrong.
- Most first time visitors would assume one of the following:
- This site is a scam site. These visitors would likely never return.
- This site has some advertising up front. These visitors would likely hit reload and ignore what happened.
- My PC has an issue. These users might run a virus scan, but would never think that it was the web site and not their PC. Whatever the results of their virus scan, the second attempt would get through so they would assume the problem was solved.
In any case, since it effectively only happens once per new visitor, no one is likely to be annoyed enough to investigate the issue or complain to the site owners. And that means the exploit can sit unnoticed for months or even years.
Detecting the Hackers
If you have a web site it’s a good idea to have your site verified on a regular schedule, both to make sure that it’s running and to make sure that it has not been modified outside of your control. There are numerous automated solutions for this, but I’m hesitant to recommend one in this blog post because the best solution really depends on the site in question.
The thing I do want to note is this: however you verify your site, you need to make sure that the site is verified as a brand new visitor would see it. This means a clean browser with no cached files or cookies from your site, possibly on a random IP that has not visited your site before. For automated solutions this means an application or service that can emulate a visit by a new user.
You should also utilize more than one service or technique to verify your site. Hackers are taking steps to make sure that frequent visitors do not see their handiwork and alert web site owners. It’s no stretch to assume that they have or will take steps to make sure that automated verification services can’t see their modifications.
And that leads to my second note: a file integrity checker that runs directly on the server should be considered an important part of your site’s security in addition to any remote verification services. Such an application cannot tell you if your site is down for other reasons like a verification service can. But it can do something those services cannot. A hacker who exploits PHP, WordPress, or something else to gain write access to a file may write malicious code that does not appear to a frequent visitor or a site verification service. But those file changes should be noticed immediately by a process running on the server itself.
Again, I’m going to withhold product recommendations in this blog post. I will hopefully have time to review both remote and server based verification products in the near future.