(Letsdefend.io) Case: SOC169 — Possible IDOR Attack Detected
Letsdefend.io is a great platform where you can practise as SOC analyst, there are short tutorial and courses to take. In particular it’s very interesting the monitoring dashboard:
In this dashboard there are real case study that you can analyze and study. In the free plan you can see only 15 alerts each months but for getting started it’s a good source.
Today I’ve analyzed this case related to IDOR Attack:
Insecure direct object references (IDOR) is a type of access control vulnerability where unauthorized access to resources or actions can be gained through unvalidated user input.
The name “insecure direct object reference” was popularized by OWASP (the Open Web Application Security Project) as a collective label for vulnerabilities that allowed attackers to reference objects directly and so get unauthorized access to application resources.
First step to analyze this alert is to identify why the alert was triggered:
The reason is that consecutive requests have been made to the same page.(“hxxps://172.16.17.15/get_user_info/”)
Other important information that we can read from details are:
- Time: February 28, 2022 at 10:48 am.
- Hostname: WebServer1005
- Destination IP Address :172.16.17.15
- Source IP Address: 134.209.118.137
- HTTP Request Method :POST
Now we search the source IP address in the log management area:
We notice in fact that there are 5 requests from 10:45 pm to 10:48 pm to the same page.
The details of the first log:
The analysis of the logs shows that the attacker wanted to change the value of the ID (?user_id=2) to have access to the users’ information, in fact the other logs show the following parameters:
POST Parameters: ?user_id=1
POST Parameters: ?user_id=2
POST Parameters: ?user_id=3
POST Parameters: ?user_id=4
POST Parameters: ?user_id=5
The HTTP Response status in all logs is 200 which indicates that the specific request has been successfully completed.
Responses are grouped in five classes:
- Informational responses (100–199)
- Successful responses (200–299)
- Redirection messages (300–399)
- Client error responses (400–499)
- Server error responses (500–599)
After this log analysis, we can assume that there was an attack and therefore we need to proceed to contained it and escalate to Tier 2.
