Got malware? How to find help recovering your website.

The dreaded Google Malware Warning, most amateur website operators have, or will have experience with it. When Google detects that your website has been compromised and is providing a channel for the distribution of malware, they show this warning for anyone referred from a Google property, including users of Google’s Chrome browser, who get the protection whether they click a Google search result or simply type the URL into the address bar.

With the rise of lightweight, easy to administrate, CMS systems like WordPress, Joomla, etc. Google’s Safe Browsing program is great. The inner workings of these CMS are still pretty complicated, from the perspective of the average user. They are usually made up of (at least) a SQL database and some PHP, which most site owners know little about. With the advent (and proliferation) of installers like Fantastico, which will install common services in a users account on their webserver, the knowledge barriers to CMS entry are getting even lower. These reasonably complex systems are being managed by people who don’t know too much about what makes them run.

Security vulnerabilities in these systems are discovered with regularity, and are patched by subsequent updates. Adding to the difficulty of securing these systems are their ability to run plugins, and custom themes that open other vectors for attack. Recently, I reached out to an organization whose website had been compromised. The organization’s event (the Alcan 5000 rally) starts tomorrow (February 23rd), and they didn’t have time to resolve their malware difficulties. Their website contains entry forms, and other technical information, also public interest is never higher than when the event is actually taking place, so this is a pretty critical time for the website to be up and functional. Also, I would love the do the Alcan 5000, so I had a personal interest. For these reasons, my company, Plain English Technology Services, reached out to help them.

Their website (and event) administrator had already taken a few good steps to resolve the problem, deleting the PHP and javascript of an old WordPress installation (which was way out of date, a big WordPress no-no), changing the FTP password, and switching away from cleartext FTP settings. He also discovered and removed a rogue .htaccess file that was redirecting users to a PHP file on Russian domain. Bad news. It was at this point that I came in. My first order of business was to scan the files for scripts of any type that could allow a backdoor into the hosting account. This is a particularly tedious exercise, as malware purveyors are great at hiding this stuff. They often use tricks like encoding the script before inserting it, inserting it after hundreds of blank lines (and many indents), etc. Very frustrating. Luckily, the Alcan 5000 website is mostly static HTML, and thus it is easier to identify problem scripts.

After removing all of the remnants of the malware I was still seeing a malware at various URLs (even some that didn’t exist) when I ran a Sucuri scan (their free scan is a service I cannot recommend highly enough), so I opened up Res Swain’s HTTP View tool. This tool allows you to send an HTTP GET request and see the raw HTTP header returned. It also has options to specify a referring URL, user agent, etc. for your request. This revealed to me a conditional 301 redirect any time I had the referrer set to (or any of their domains, really). Without Google’s referral, the HTTP header contained no redirect. There was no .htaccess file left in the HTML root that could have instigated this redirect, and I was stumped. For a minute.

GoDaddy (not a favorable choice for anything, if you ask me) just happened to be hosting this website, and GoDaddy doesn’t allow you to view anything in your account above the HTML root. Theoretically, it is possible to have an .htaccess file above the HTML root, and that is exactly what happened here. The folks behind the malware somehow managed to place a compromised .htaccess file above the HTML root, somewhere I couldn’t get to. In reading online, a member of named RedLeg notes this apparently flaw in GoDaddy’s security.

After taking a few deep breaths in preparation for having to call GoDaddy, I dialed the fateful numbers. The first GoDaddy rep I spoke to took their typical route, “the problem is in your computer/browser, I’m not seeing any Google warning over here.” Yeah buddy, thats because you’re using Internet Explorer and not getting the referral. I patiently explained to him the conditional redirect I was getting, etc. Nothing. He was sure the problem was on my side, and that there is no higher level in the filesystem than the HTML root. He was dead wrong on both counts.

At this point I could rightly have been quite frustrated, but I had prepared myself to make more than one call to GoDaddy. I’ve dealt with them before. The second time around, representative two was a lot more helpful. She tried to pull the same tricks as rep one, but would at least hear what I had to say about the conditional redirect, and was willing (and able) to pull up the page in Firefox, which took advantage of Google SafeBrowsing. She had to get “an admin” on the phone, but eventually she did find the rogue .htaccess file and remove it. Her admin confirmed that this was a growing problem with GoDaddy hosting.

After GoDaddy removed that .htaccess file the site scanned cleaned, and after a request to Google for them to rescan the page, the malware warning to users disappeared. The moral of this story is not to put complete faith in your hosting representative when you get them on the phone. Don’t be afraid to call back and get a different rep that is willing to actually listen to you. Especially if you have to deal with GoDaddy.

For interested parties, I offer generous hosting for about $7.50 a month, and as any of my customers will report, I am almost always available to help you solve any problems immediately.

Thanks for reading!