Threat Intelligence: Log File Hacking

We noticed an interesting attack during a forensic investigation recently. It wasn’t at all obvious where the ingress point for the attack was.

So we had a look at the web server logs and found some interesting artefacts.

The client web browser user agent from a few connections looked really odd – it appeared to be a PHP back door, base64 encoded, looking a bit like this:

Why would you put back door code in a user agent? It won’t execute, so no connection back.

However, if you know you’ve now got back door code on to the server, maybe you could call and execute it somehow. The logs are likely to be in the default path, so you know where your code is likely to be.

Maybe if you’re lucky, as in this case, there was a local file inclusion and directory traversal vulnerability. It was a simple matter of using the inclusion to call the back door, build and execute it, e.g.

If you are really lucky, then you could hammer the web server to the point where the administrator starts to investigate. You could continually poison the logs with your bad user agent – that might be enough to raise their interest.

First place they go are the server logs. They see an odd user agent, view it, the code executes (again, success depends on lots of factors) and you have a back door.

What can you do?

Sanitise user input. Yes, even browser user agents are a source of client-supplied input, so sanitise them.

Run the web server as a low privilege user. Don’t give the hacker local admin!

Don’t store logs in the default location on the web server. Under Windows, store them on a separate drive or drive letter, to make the traversal attack harder.

Back up your logs often, remove them from the web server and store them elsewhere. Reduce the window of opportunity.

And a random thought – if you run a WAF (Web Application Firewall) on the same server as your web server, you’re asking for trouble. Easily done if you run Apache and mod_security. Let’s say the WAF blocks and logs some back door code sent in by the hacker. The hacker finds a directory traversal on the web server, then uses it to navigate to the WAF logs, in which the back door code has helpfully been placed.

Your WAF creates a security vulnerability. Nice!