Hunter
Summary
We start this machine with a list of usernames gathered in an assumed previous OSINT process. The goal is to identify the username that exists on the web app. (not shell access, the goal is just to find the user)
The pages identified o the web app are login/reset password pages but they did not show any useful feedback for identifying users. but the poor design of the app made it possible to identify the user based on response time(time based enumeration). to better understand this the attacker should have a good understanding of the execution path concept
Nmap Scan
Enumeration
The machine description mentions that we need to identify the valid user for the web app as foothold
Looking at the web app first thing I see is a login and a password reset pages, so I start by testing these pages behavior with random usernames to see if they show any feedback regarding the random username I use.
The login page did not show any feedback if the username exist or not or even regarding the login try it just stays on the same page without any feedback
The reset page showed a feedback message but this message does not give any indication if the username exists or not
Before I go any further I will run a quick dir bruteforce to make sure I’m not missing any endpoints.
As showing above there is only the 2 endpoints that we saw before identified by the dir bruteforce attack.
Get dj4m’s stories in your inbox
Join Medium for free to get updates from this writer.
This kind of push me towards what I was already thinking, a time based enumeration, even tho no obvious feedback is given by both pages, the web app can still give us some indication whether the username exist or not. Think of it this way, and lets consider the reset password page to make this easier to understand, when we submit a reset request the application checks if user exist, if the user exist it will generate and reset link and send it by email to user, but if the user does not exist it just skips all that. this should reflect in processing time of the request and eventually response time, if the app is poorly designed. same thing applies to login if the login process split the user validation into user validation then password validation(not both at same time). to verify this I will run a FUZZ attack with the username list from OSINT and analyse the responses timing to see if any take longer.
Foothold
First I copy the password reset post request from Burp and dump it in to a reset.req file
then I pass that request to ffuf with the usernames file as wordlist and use burp as proxy to keep track of the requests
And even before I check burp I can see that one request took much longer then the rest !
also visible on burp
well hi joey !
Fix
This enumeration path can be fixed simply by rendering the response page before processing the password reset request. an option would be the add the reset request to processing queue and sending the response, this way all HTTP responses would have similar timing as the execution path from HTTP request to HTTP response would be the same if the username exist or not. and there queue then can be processed in isolation from HTTP without any time reflection.
