Natas is hacking game hosted at overthewire.org that centres around web application security. Each level must be compromised by some means to reveal the password for the next level. Below is a writeup of the method I used to penetrate the security of level 19. I highly recommend this game to anyone interested in web application security.
Upon loading the main page, natas19 presents the user with a login page and a message that the credentials for natas20 are available to users with admin privileges. A quick overview of the structure of this web application reveals that, as with the previous level, PHP sessions are used to control access.
What is notable in this case is that some effort has been made to complicate session ID brute force attacks by using non-sequential session IDs. However as we shall soon see this alone is not enough to deter a determined attacker.
The attack hypothesis we shall pursue is that there is an open admin session we can hijack by determining its session ID. This necessitates a brute force attack, however we must first collect additional data to determine the format of the session IDs used. This is initially done by submitting POST requests to the web server with login data and capturing the session IDs it returns in Burp Suite:
Next, we need to see what patterns and consistencies can be observed between multiple session IDs when the username and password parameters are null. I wrote the following script in Python to automate this:
The results as shown below indicate that session IDs range from 4 to 8 characters, always begin with 3 and end with 2d:
This is theoretically enough to conduct a brute force attack, however we must observe the behaviour of the web application under the same conditions as an authorized admin login. Thus, our session ID collection script is amended to provide username and password data:
As we see from the above results, the additional and consistent characters “61646d696e” are placed after “2d”. Running the same script with the username “admin” and a null password reveals that these characters remain unaffected. This indicates that the additional characters correspond directly to the username and upon closer inspection the session ID is revealed to be an ASCII hex encoding of a decimal number, a hyphen and the username:
Herein lies a critical security flaw, if a user’s session ID directly corresponds to their username it can be quite easy to attack a specific account. Furthermore, the fact that in this case the session ID actually contains the username in reversible ASCII hex encoding exposes the full format of session IDs used by this login page. Armed with this information I wrote the following script to brute force the session ID:
Click image to enlarge.
Further explanation; the brute forced value in the POST request is the cookie parameter “PHPSESSID”. The for loop submits a value between 1 and 100000 as the dynamic segment of the session ID between 3 and 2d. The remaining characters are the ASCII hex encoding of the username ‘admin’. Finally, we need a success condition drawn up by the if statement. This specifies that the returned page does not contain default messages such as “Please log on with your admin account to retrieve credentials for natas20”.
As predicted our script eventually returns the admin session ID:
Which is ASCII hex for: “595-admin”.
Logging on to natas19 with this ID reveals the credentials for natas20: