Games Irados is a simple Python web application that contains an example of a Security Logging and Monitoring Failure vulnerability and, its main goal is to demonstrate how important it is to properly log all requests made to the application and how easily malicious requests could go unnoticed.
Security Logging and Monitoring failure, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.
The main goal of this app is to discuss how Security Logging and Monitoring Failure can be exploited and to encourage developers to send secDevLabs Pull Requests on how they would mitigate these flaws.
To start this intentionally insecure application, you will need Docker and Docker Compose. After forking secDevLabs, you must type the following commands to start:
cd secDevLabs/owasp-top10-2021-apps/a9/games-iradosmake installThen simply visit localhost:10010 ! 😆
To properly understand how this application works, you can follow these simple steps:
- Create a new user!
- Check out all the games offered!
- Try redeeming a game coupon after login in!
Now that you know the purpose of this app, what could go wrong? The following section describes how an attacker could identify and eventually find sensitive information about the app or its users. We encourage you to follow these steps and try to reproduce them on your own to better understand the attack vector! 😜
To verify how an application handles events that are considered malicious, two attacks will be done to test it:
- Brute forcing the login screen
- Brute forcing the coupon validation screen
Initially, we begin the first attack by sending an intentionally wrong login attempt, as shown by the image below:
After that, an attacker could use Burp Suite as a proxy to send as many requests as needed until a valid password is found (if you need any help setting up your proxy, you should check this guide). To do so, after finding the login POST request, right click and send to Intruder, as shown below:
In the Positions tab, all fields must be cleared first via the Clear § button. To set password to change according to each password from our dictionary wordlist, simply click on Add § button after selecting it:
If a valid password is found, the application may process new cookies and eventually redirect the flow to other pages. To guarantee that the brute force attack follows this behavior, set Always into Follow Redirections options in the Options tab, as shown below:
You can use the following wordlist (poc.txt) just for POC purposes:
admin
password
123
qweasd
1qaz
123456789
flamengo
zxc
asd123qwe
YOURVALIDPASSWORD
Before executing the attack, you can open a new tab in your terminal and type the following command to observe how the malicious requests will come to the app:
docker logs app-a10 -fIn the Payloads tab, simply choose the wordlist from Load... option and then the attack may be performed via the Start attack button.
As we can see from the results of the requests, the application handles successful and unsuccessful requests differently by responding to different status codes. As shown below, when the payload is correct the application responds a status code 302 FOUND, otherwise it responds with a 200 OK.
By having a look at the application on the server side, it's possible to see that the logs provide little information regarding the attack, as shown below:
Furthermore, if we try the /coupon route, instead of the /login, we can see similar results. The coupon page is shown below:
Using Burp Suite again, we could send multiple requests to the application to simulate the second brute force attack, changing only the coupon field:
If you need to generate a simple number wordlist, you can use the following command:
seq 100 200 > coupons.txtAs we can see from the image below, the requests seem to have been handled properly by the server.
However, we can also confirm that little information is being logged at the server side, as shown by the image below:
How would you mitigate this vulnerability? After your changes, the new log system must give us:
- Who did the request
- What happened
- When did it happen
- Where did it happen
[Spoiler alert 🚨] To understand how this vulnerability can be mitigated, check out these pull requests!
We encourage you to contribute to SecDevLabs! Please check out the Contributing to SecDevLabs section for guidelines on how to proceed! 🎉