BadStore is a popular application for demonstrating possible vulnerabilities that may occur in web applications. Bad Store is packaged as part of a disk image available from VulnHub and can be run within the Hypervisor of your choice (I use VirtualBox). Recently I was shown it by someone and thought I’d write a small walkthrough of some of the vulnerabilities I found.

Once you’ve ran the BadStore disk image if you run the ifconfig command which will return the machine IP address so you can view the site in a browser of your choice.

Bad Store Homepage Screenshot

First Steps

The first steps I try to take when analysing anything are to start with the simplest steps first. This means first of all simply looking at the site within a browser and looking for potential vulnerabilities. Some potential warning flags are:

When clicking on the “What’s new” section of the website the user details at the top of the page will be presented as “Welcome {unregistered user}”; while not a vulnerability in itself, it’s not a good sign that this is presented without proper formatting.
Moving onto the previous orders page a message will be shown that there are no previous orders and that the browsers back button must be used and Login selected.
Within the “About Us!” section a link to send Bad Store an email is shown with the email address fully visible upon mouseover. While some sites choose to present a contact address for support, this can sometimes lead to bots crawling the site then sending spam to the email addresses it finds.
The supplier contract link also downloads a word document which on a genuine site could contain useful information someone could use for nefarious purposes (in this case the document contains Lorem Ipsum). It would be a good idea to have this behind a login.
The “Supplier Procedures” link explains that suppliers can upload price lists and descriptions that will be automatically updated. If descriptions and prices can be updated without review this could result in a third party changing prices to differing amounts that allow them to get products more cheaply. They could also insert text into product descriptions that may harm the stores reputation. This description will also likely be user facing so serves as a potential Stored Cross Site Scripting (XSS) vulnerability.
While browsing the site the URL will also follow the format http://192.168.0.51/cgi-bin/badstore.cgi?action=XXXX, changing depending on the page and action taken, e.g. action=aboutus, action=aboutnew, action=myaccount.

Already a number of warning flags are shown just from browsing basic pages on the site. More interactive pages on the site are even more worrying.

Account Creation

Login creation is one of the most questionable of any I’ve seen. This is a demonstration of how not to build an online store, but it’s entirely possible that some companies out there operate a system with similar security practices to BadStore.

There is no input validation on any of the account creation fields, I entered “test” as the email address and it created the account.
Perhaps the most questionable of all the steps is that the password hint field only lets you pick from a set of six predetermined options within a combo box. A hacker would make short work of working through the options if they knew the account ID.
If you have forgotten your password, once you’ve entered your ID and picked from the six recovery answers your password will be shown in (a rather large) plaintext on screen and will also be reset to the insecure “Welcome” without any form of email verification.

Account creation and recovery already looks like it’s in need of massive improvement.

XSS Attacks

XSS attacks are arguably the most prominent web vulnerability, XSS vulnerabilities occur when data entry fields on the site a not coded to validate data inputted into them. This means if HTML code were entered into them the code would be executed as though it were part of the sites code; a good way to think of this is when someone is telling you words in a foreign language, but not telling you what they mean so you end up shouting a foreign word in a public place.

If you’re trying this for yourself XSS can be frustrating to take advantage of within modern browsers as they will apply protections unless the site specifies otherwise; some of my experiements were flagged in Safari’s code editor. Some XSS vulnerabilities I found were:

Within the guestbook on the website it is possible to type anything in, including code, without any validation. E.g. Insert or within the “Comments” section.
The search field is also vulnerable to the same commands when the same code is entered as the last bullet point, again this will likely be stopped, but viewing Safari’s console will show you it stopping the code from being executed.

Finding Hidden Directories

A common issue some sites have is that they leave directories exposed that contain sensitive data, so it’s a good idea to check for these hidden directories. I ran an Nmap scan command as

_$ nmap –script http-enum _

This returned the information that /backup, /robots.txt, /icons/, /images/, and /supplier/ were exposed. The robots.txt file will nearly always be visible as it advises various bots what should be included in it’s scans and what not to include. However, this does mean that by simply adding a sensitive directory to the file it will be secure, it just means bots may choose to ignore it.

/supplier/ represents one of the biggest issues for exposed directories. When this directory is navigated to, four account IDs are shown. The data next to the user IDs are encoded; using GCHQ’s CyberChef I found that they were user details encoded in Base64.

Accessing the Admin Page

Gaining administrator access on BadStore is quite easy. Previously we found that you could reset any user IDs password quite easily and when reset the password would be set to “Welcome”. If you try to reset the password for the account “admin” all you need to cycle through is one of the six colour options and eventually you’ll be given access to the “Master System Administrator” account. Edit the URL to cgi-bin/badstore.cgi?action=adminportal which will take to you to what is termed the “Secret Administration Portal”.

The administration portal has number of issues beyond being easy to access.

The sales report panel presents full credit card details in plaintext along with various other identifying user data.
Users can be added and deleted without any verification.
The “Show Current Users” page has the users password encoded as an MD5 hash that can be easily decoded.
Upon requesting Bad Store to create a backup of the site databases it will store the backups in the publicly accessible /backup folder. This data shows the sales reports with the credit card details as well as the current user details with an MD5 hash of their passwords.

Upon creating an account on the site, using Wireshark or a similar tool you will find that it sends the credentials back to the server in plaintext meaning that if a user is navigating this site on a public hotspot, their login information could be easily retrieved. It is also possible to modify this POST data in order to create an account with administrator rights, allowing greater access on the site.

Bad Store Plaintext Credentials Screenshot

Conclusions

These are only the initial findings of what BadStore is doing that are bad practices and more issues are listed in the BadStore manual; these issues are just scratching the surface. In most cases it would be absurd that a site would have this amount of security issues, but I find these test boxes can serve to illustrate what can go wrong in the design of a site to help prevent further mistakes.

A good resource that explains some of the more technical aspects of site security is Google’s Gruyere which functions similar to BadStore in that it has a site that has been designed to have poor security that can be examined and dissected however, Google’s is accompanied with more documentation that explains security issues such as Path Traversal, Denial of Service and XSS vulnerabilities.