Hacking Series Part 18
Category: web security
We are given an instance of a website that requires us to login when we navigate to it. There is a message indicating that there is a new update with how users can login and it is posted by someone who is likely an admin of the website.
After scanning the website, I first noticed that there is a reflected XSS vulnerability that exists with the
message parameter in the URL leading to the login page. You could enter an
The real vulnerability exists in the way that the login credentials are processed in the back end and in the database. Since we know that there is likely a user named “Reese” that has an account, I entered variations of the name as the username. Since we do not know the password, I entered “*” in for the password.
An asterisk is sometimes used as a wildcard that returns all entries in a database/filesystem. For example, if I want to get a list of usernames that start with “A” but end with anything else, I could enter “A*” into my query for usernames. In this case, if I want to return all passwords associated with the username “reese”, I would enter “reese” as the username and “*” as the password.
This worked and brought me to another page that implements a basic search functionality for a phone book.
In the search query I entered a space character, which returned the results above. After looking through the data, I found nothing interesting in particular, which meant that the flag was probably the real password to the username “reese”.
To figure out the real password, you can input a single letter of the alphabet then append “*” to the end of it. If you are successfully logged in, that means the letter you chose was the first letter of the real password. If you are not logged in, then you can choose another letter and try again…