Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Broken Business Logic leading into restrictions bypass and Alternative Solution found for PortSwigger Academy Lab: Username enumeration via account lock

Pedro | Last updated: Jan 11, 2022 02:54PM UTC

Hello! Found an alternative solution on the lab based on a bypass which I think would be awesome to present to the community. The bypass relays on switching the order of the HTTP POST parameters, which turns out to completely circumvent the account locking mechanism, enabling an attacker to test an unlimited set of passwords for whatever user he might want, skipping the enumeration phase and jumping directly into the correct combination of user:password, since we can differ by size and response contents those which aren't the correct combination and the exact correct one. PoC: https://www.youtube.com/watch?v=6ioVur1WrFQ ( account found at 5:30 )

Michelle, PortSwigger Agent | Last updated: Jan 12, 2022 05:15PM UTC

Thanks for getting in touch, we'll have a look through it and get back to you soon.

Michelle, PortSwigger Agent | Last updated: Jan 13, 2022 09:53AM UTC

We've taken a look through your video, thanks for sending us that link. Your solution is making use of the same deliberate logic flaw as our suggested solution. In the lab if you login with the correct username but an incorrect password, on the first three attempts you will see the error 'Invalid username or password', on the fourth attempt you will see the message 'You have made too many incorrect login attempts. Please try again in 1 minute(s)'. What you'll notice though is that during the minute the account is locked out, if you try to login with the correct password, you wont be logged in but there is a difference in the response, instead of seeing the message about the account being locked out there is no error. The logic flaw exists without needing to swap the order of the parameters in the login request, so you can run the cluster bomb attack in the same way you did but with the username as the first payload and the password as the second payload. You will then see the same effect where one of the responses is shorter because there is no error message. The downside to using the cluster bomb attack with all the username/password combinations at the same time is that more requests will be sent so in this lab example you need to send 10,100 requests to cover all the combinations. If you use two separate intruder attacks as we suggest in the solution then the first intruder attack will send 505 requests and the second will send 100 requests. The more usernames and passwords you have to test, the more the difference becomes noticeable. I hope this helps to explain the differences in the solutions. Please let us know if you have any questions. We hope you enjoy the rest of the labs :)

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.