Extra Vulnerability Not Included In Hacker101 CTF Postbook

The Postbook Capture The Flag (CTF)  is a great security testing exercise. It's an easy level exercise with 7 flags to be found in-order to complete the exercise. Working on this exercise is a good way to learn more about vulnerability exploits and if you get stuck, there are hints on the website to help guide you and should that not suffice, there are also many articles online with pointers on how to find each flag. While working on this exercise I noticed an exploit that was not included but would be fun to add to the flags. Since there are other resources that one could use to find the flags of this exercise, I will not be including the flags but will only focus on the extra exploit in this article found during the testing.

This exploit can be found on the view.php page but to get to it, the exploit will have to be created on the settings page of the application. This is because the settings page of the application is vulnerable to cross site scripting (XSS) attack. So a user of the application can enter javascript code into the username field and this code can be used to exploit a loophole within the application. Specifically, the code can be used to get the login information of other users on the application. To show this exploit, first the basic/simplest test for of XSS will be shown and then that will be built on to create the payload for the extra vulnerability.

So, the first step will be to sign-up on the application and subsequently update the username with an XSS code "<script>alert('Hello')</script>" and save it.

Next would be to create a post on the application. Each post on the application has the authors name on the post and in this case, the user name is the javascript code saved as the username. However because the name for this user is a javascript code and not an actual name, the script will be added to the details of the post but will not show to other users of the application. So, navigate to the post creation page by clicking on the "Write a new post" menu link at the top of the website, then add the title and details of the post. Once these have been added click on the "Create" button. Once the post is created as the next page for the created post is being rendered, the name of the author is retrieved from the database to add it to the post and the application unknowingly retrieves the javascript code and add it to the page and this causes the alert prompt to display. This is a clear sign of the possibility of the XSS exploit in the application.

Once the possibility of an XSS has now been confirmed the next step will be to see if javascript saved for the username field can be modified to to get data from other users on the application. To do this, a code will need to be written to get the information from other users page while using the application. The concept for the code will be to navigate to the settings page for other users and use the code to access the information of the page. The code below will do just that.

<script src='https://ajax.googleapis.com/ajax/libs/jquery/2.1.3/jquery.min.js'></script>

<script type='text/javascript'>$.get('https://630b16aac320a30c17ab5f34a2baa4c0.ctf.hacker101.com/index.php?page=account.php',function(data){alert(data);});</script>

The javascript code in green is the precise code for the exploit but if used only it would not work but the user will get an error message of "Reference Error: $ not defined". To  fix this error, a jquery.min.js (the version used for this testing is 2.1.3) will need to be added to resolve this error and let the postbook application understand and render the javascript code. So, once again, we navigate to the settings page and update the username with the new payload. The code saves successfully and payload has been created and inserted into the application.

Now navigate to the home page and click on the post created by the user and observe the alert notification.

To test the effectiveness of this exploit is by verifying that other users of the application will also see the alert popup of the XSS when they login to their own accounts and interact with the post created by this user. Now log-out of the account and create another user and login with that newly created users information to see if the user will see the exploit. The new users information for this test case will be "testing"

 

On the home page after logging-in to the application, click on the post created by the user with no name in the author area. This is the post created by the user with the javascript exploit as the username of the user. This will be the test to confirm if the XSS work. The confirmation will be the appearing of an alert popup with the page information. True to the hypothesis, clicking on the post shows the alert popup and this confirms that the page is susceptible to the exploit.

This is a cool exploit in the postbook exercise and it will be fun for the testers to go through the process of finding it out. I think the hacker101 site should include this exploit as one of the flags to be found in the exercise. It a nice way to introduce a beginning/learning security engineer the effects of XSS which will in-turn make them better engineers and motivate them to work diligently to prevent XSS vulnerability in their applications. Alright, 'nough said. Back to testing.