In this blog, I am going over the Information Disclosure labs offered by port swigger. Although the exploitation of information disclosures is absolutely basic with no advance techniques or technical required, finding one small tidbit of information can be enough to tip the scales for an attacker to get his foot in the door and find additional vulnerabilities or bugs.
Basic steps can be taken to avoid information disclosure.
Team awareness on sensitiveness and non sensitive information
Code auditing for left behind information from development or quality assurance stages
Review error messages and keep them generic
Reduce the attack surface where you can
LAB: Information Disclosure in error messages
Summary
Identify URL parameter input
Pass a non integer to produce an unhandled exception
Review error page for server version
Visiting the main website we have a standard shopping page.
When selecting a product, we have a classic example of a template for many beginner CTF's. This is a URL value tampering vulnerability where the URL calls a user changeable variable, the product ID.
Changing this to a different number gives us a different page on the website which in itself is not a big issue. However the issue comes with being able to fuzz random strings, numbers and escape characters in hope of coming across something of value. In this particular instance we can enter a string in place of the product ID to cause an unhandled exception.
Having entered a string in the "product=" variable, gives us an error with the stack trace log which exposes the Apache Struts 2.2.3.31 server and version. This now enables an attacker to start enumerating the infrastructure and looking for Apache specific vulnerabilities and exploits over on the old exploit-db.
Lab: Unprotected admin functionality
Summary
In this lab we are tasked with finding information disclosed through the source of the website. Although this may not be a sophisticated vulnerability that results in gaining high level access, it demonstrates the importance of basic enumeration, and the possibility of low hanging fruit. I have read about many bug bounties and CTF's that involve such simple yet over looked paths to exploitation, or unauthorized access.
We have the standard shop page with some very interesting items, including caution signs which I wouldn't mind getting if the price were a little cheaper. lets check out the source code and scripts on the website site.
Eventually I found under the index script an attribute that references /admin-dnzc97. This is a directory that you could not find by brute force or fuzzing due to the entropy of characters.
Browsing to this directory we delete the user Carlos. The challenge is solved upon blowing away his account.
Lab: Information disclosure on debug page
Summary
View page source for hidden page
Review hidden page for environment variable
This lab is quite similar to the others, in the sense that we are looking for low hanging fruit as opposed to a complex or sophisticated attack like XXS - CSRF. Some times the path of least resistance really is worth taking, if we find an API key or hidden information.
The goal here is to find a debug page and locate Secret_key environment variable.
Yet again we land on our favorite shop known as "We Like to Shop". Lets inspect the code and utilize the find function to locate any string containing "Debug".
We find the disclosed debug page and browse over to this URL.
Sure enough our secret key is sitting in the Environment section.
Lab: Source code disclosure via backup files
Summary
Check robots.txt
View leaked backup directory
Find Password
This is another lab that affords us a good example of accidental information disclosure. Something to keep in mind, although this may seem cheesy, quite often these simple mistakes found on a site for a short period of time. It is not necessarily a final production website, but perhaps a website that has many developers working day and night to update on an ongoing basis, thus the risk exposure can be constant.
Once again we land at our favorite place to shop.
The hint in the description is robots.txt so we head right over there and notice the suggestion of a backup directory.
Browsing to that directory brings us to a page of code with a leaked postgres password.
Lab: Authentication bypass via information disclosure
Summary
Change the request type to trace
Modify the custom header X-Custom
Delete the user
This is a neat challenge that requires verb tampering which is to do with changing the request type from Get to Trace as per the challenge description. As well as modifying a custom header titled "X-Custom-IP-Authorization".
To start the challenge we simply browse to the /admin page and get an unauthorized response as seen below.
So we do exactly what the challenge description suggests and change the request from GET to TRACE and we get a 200 OK response, but the page still will not load. Upon further investigation we noticed a custom header at the bottom titled "X-Custom-IP-Authorization".
We then change this header to our proxy's address of 127.0.0.1 using the burp suite Match and Replace function as seen below.
Sending a new request with a Trace header and our Custom-IP header gets us a 200 OK and loads the page.
We are able to delete the user Carlos and complete the challenge.
Lab: Information disclosure in version control history
Summary
Check the .git page
Download the repo
Browse the git repo
Identify the admin password variable
This was an odd challenge and you have to be somewhat familiar with git to know that there can be a hidden repo in a website at /.git.
After browsing to the .git file there was nothing useful so after some research I realized I could open up a .git file in my local github editor.
So I used Linux to curl all the files, and used windows to access the git with my local git desktop.
Upon opening the conf file it appears that a file had been deleted and a reference to an admin password object. From here I clicked Repository and selected visualize history.
There you have a deleted password from the admin.conf file.