Working with a website owner recently, we came across a new method of delivering infectious code (drive-by downloads) – at least it’s a method we’ve never seen before.
The scenario: Website owner gets the email from Google telling them their website is serving up malscripts to visitors and adds “This website can harm your computer” to all their SERPs. The website owner can’t find the malscript anywhere.
We scan their site and find nothing. Our scanning spiders their site, all links and even spiders the sites they link to.
Someone from another vendor says they found malware on a webpage that we didn’t even see. I start screaming “Why didn’t we find this page?” We try to manually download the page and we get a 404 error – page not found.
Turns out, the page didn’t even exist. We try to access the non-existent webpage with a sandboxed browser (sandboxed means it’s a system that can’t be infected due to all the security measures we’ve taken. It also records any attempted file changes, registry changes, etc.).
Bam! We see in the 404 error page that there’s some redirect code in there trying to access martuz.cn. Interesting.
We look at the address bar in our browser and see that it didn’t redirect to a custom 404 error page, it still shows the URL we typed in with the john_doe.html page at the end. We know from our scan that this client is running their website on an Apache 2.0 server.
Our research showed that in the Apache installation folder under a sub-folder of “error”, the HTTP_NOT_FOUND file had been modified and the malscript added.
Which begs the question, why would a cybercriminal go through all that trouble to only deliver the martuz.cn malscript to people who type in a non-existent webpage?
Not sure on that one.
We also found these files had been added to the default directory on the webserver:
Each of these pages looked like the default Apache error pages but with the martuz.cn malscript inserted between the closing HEAD tag and the opening BODY tag.
We found that Apache uses one of 4 options when handling error responses:
- output a simple hardcoded error message
- output a customized message
- redirect to a local URL-path to handle the problem/error
- redirect to an external URL to handle the problem/error
It didn’t appear to be redirecting as the URL in the address bar was still what we had entered. So we eliminated options 3 & 4.
At first when we saw the malscript only being delivered with 404 responses, we thought that maybe there must be some line in the httpd.conf file like:
ErrorDocument 404 /404.html
But there was no such entry in the httpd.conf file. It was definitely the default Apache error page with the martuz malscript inserted.
Further investigation found our theory was correct.
Lesson: When trying to find all the infectious pages on your site, don’t overlook the non-existent webpages as well. In this particular case, those were the only files serving infectious code.