Exploitation

Welcome back to Insufficient Logging and Monitoring session. In this second part, we will exploit our target application while analyzing its logging and monitoring approach. We will jump straight to our intentionally vulnerable application, and then move on to the mitigation part. In our broken authentication session, we exploited our target application using a brute force attack called Credential Stuffing. We will do the same, but now, we will focus on what is logged by our target application and how it looks like while it is under attack. To do that, we will access Juice Shop server, running on a virtual machine in our one computer, using the terminal window in the top right corner of the screen.

Juice Shop runs in a Docker container and logs are kept locally. To be able to inspect the logs, we have to access the container itself. To do so, we ran the sudo docker exec -it juice-shop/bin/sh.

Inside the container, we can see a directory called Logs, where log files are stored.

There are only access log files. Apparently there is no effort logging at all, but we will discuss it later in the mitigation part. Let’s see what is written to the log file while the user performs authentication in the web application. Let’s type tail - n 0 - f, followed by the name of the access log file.

Now let’s use the login form to log in as admin using the wrong passwords.

We’ve got three new entries. Two of them to the /rest/users/whoami endpoint, and the third one to the /rest/user/login endpoint.

The log entry includes the user source IP, the request date and time, the end point, the URL from where the request came from, and finally, the user agent.

We also have the HTTP response that is code, in this case the 401. On a successful login, we should expect it to be a 200 status code. Now we will keep monitoring the access log and start the credential stuffing attack the terminal window, at the bottom right of the screen. Let’s first clear the screen and monitor the access log file using the same commands. To start the credential stuffing attack, we run our scripts, passing the admin, email address, and a password list.

At first, we have solved two Juice Shop challenges. We have done it before on our broken authentication session. Let’s focus on the new entries in the log file on the top right terminal. We can see several new entries in the log file, all of them to the /rest/user/login endpoint, with a 401 HTTP response status code.

Suddenly, we have a 200 that should be a response status code to that same endpoint, meaning that we got the right user account password, via our credential stuffing attack. Clearly, logging does not include sufficient details. We have several failed login attempts with the 401 response status code, but we don’t know if several accounts are being used or they are all targeting the same account. What is the case? Juice Shop does not include any monitoring or alerting. Attackers may use different source IP addresses to perpetrate such attacks. And entries in the log file may be confused with regular activity. What we have here is definitely insufficient monitoring. Next we will discuss what makes the application vulnerable and how to prevent it.