A3: Sensitive Data Exposure 2017 OWASP

In this article we will talk about kinds of information disclosure going from debug information to admin passwords.

What is Sensitive Data Exposure 

This issue type occurs when too much information is disclosed, and it could be a serious security threat. There are several places we can go looking for sensitive information. let's start by listing all the ways sensitive data exposure can occur.

• A post-it on the monitor with a password. This one is pretty obvious.
• Debug information is very useful for both pentesters and bug bounty hunters.
• Github repository with either passwords directly committed into a public repo or other sensitive information. Github can also be used to get an overview of the application as it might contain the code that is being used.
• Twitter might contain some tweets with sensitive information by employees
• The web server itself might contain configuration files which are visible to visitors of the web server
• LinkedIn might contain information that it should not on the timelines of the employees
• Comments left by the developers
• Javascript files
• Directory listings are sometimes exposed to the public which allows attackers to view the internal structure of a website but even worse is when the directory listing is not secured at all and the attacker can just freely browse every file of the website.
• Directory listings can lead to backup files being exposed and if the attacker can download and analyse this, they can investigate the source code and get a better idea of how the application works and sometimes even find secrets.

How vulnerable is my confidential information? 

This is a hard question to answer as it will differ for every organization. You will have to create a data plan to keep a list of every piece of data and how it is being stored and transferred. Is your information sent over plain text? This is of course not good as it sets you up for a man in the middle attack. 

If you do encrypt your data, are you using weak or outdated algorithms to encrypt your data? This is also not good as attackers can either crack the data or sometimes even outright steal the key to decrypt your data so make sure those are stored safely as well. 

Does your application send out too much information in the form of debug messages, logging of data or by decreasing the API security when disclosing too much information from said API.

‍

How to test for information disclosure

This is really hard to define, there are some general strategies you can follow which we will outline right here:

• It is generally important to not focus too much on one thing because you might not see some other obvious issues which have been hidden by drawing your attention into a rabbit hole.
• Look everywhere you can for sensitive data, do not just keep it to the topics covered in this article but if you can think of any other places to look for sensitive data, definitely add it to your methodology.
• Usually you will not find information when you are specifically looking for it but when you are doing other activities. This means that you need to be pretty decent at recognising what sensitive data looks like. This requires some pretty deep understanding of the target you are attacking, otherwise you can't know what is supposed to be sensitive information

Checklist

• If possible check for physical threats
• If the target disclosed debug information, explore it
• Explore Git, both the company profiles and the employees
• Explore social media such as twitter, facebook and linkedIn. both the company profiles and the employees
• Check the comments of the HTML and javascript file
• Check for directory listings
• Check for backups, if possible by directory tree or by brute forcing and fuzzing looking for .bak files

Sensitive Data Exposure Example

Debug information

Developers have the option of enabling debug information when they create an application and add that into their code. This information can be used to find and fix any flaws that still exist in the application and they are very useful however when the developer forgets to disable them in production, we can use them to gather information from.

Sometimes this information might be very simple useless information for example

```bash
DEBUG Wrong email or password entered
```

‍
Sometimes however, valuable things can be found in those debug messages. An example I found was when I tried to change my userType parameter from "user" to "administrator". This was the following message i got

```bash
DEBUG Unable to find enum value "administrator" in userTypes Enum. Possible values are
- Admin
- User
- Reporter
```

Of Course i fixed my mistake and collected my bounty. It is so nice when your targets tell you exactly what to do. Depending on the context you should report this as a bug bounty hunter but only if you can prove impact with this vulnerability. As a pentesters you should definitely report any information disclosure you find.

We can possibly also find the following information in debug messages

- Values for key session variables that can be manipulated via user input, for example the JWT encryption key allowing you to craft your own JWT

- Hostnames and credentials for back-end components, for example admin login credentials. The hostnames should be noted but the credentials should be reported by bug bounty hunters. Again, pentesters should always report information disclosure but the hostnames will be a medium/low bug while the account data will be a high/critical, depending on how you can exploit them or low if there is no way to exploit them at all.

- File and directory names on the server. This should not always be reported by bug bounty hunters but for pentesters, this is something you should always report. It can help hunters find files for LFI (Local File Inclusion) for example.

- Keys used to encrypt data transmitted via the client. This can be used to decrypt data but it requires the attacker to already have access to that data so for bug bounty hunters this might help us understand things a little bit better by being able to decrypt our transmissions but this is not worthy of reporting in general. A pentester will probably report this as a medium/high vulnerability.

Git Gud

Git is an amazing source for information disclosure and often people don't realise how big of a rabbit hole github can be. Often the developers that work at our target will create public repositories and without realising commit sensitive information.

Usually config files are interesting as they might contain passwords and api keys to back-end services, however this is not always the case. Most developers these days are smarter than this and put their passwords in the CI/CD pipeline's environment variable. This means that we can't find it in the config file anymore but just a reference to it

Something else we might be able to find is source code which is always a good thing, source code is like a map to find our treasure and can help us understand the application on a whole new level.

A lot of hunters realise that github is a good source of information or maybe even privately hosted Git instances that are open to the public. What a lot of hunters miss though is that the commit history might be one of the best sources for information. A developer might have commited sensitive information and realised his mistake but if he commited a fix to remove that data, the commit history will still show the first version with sensitive information.

JavaScript commentary

Comments left in by the developers are often a goldmine of information about how the application works. There are also times when a developer will even leave an API key or credentials in the comments and forget to remove them before committing them.

You can find these comments by inspecting the source code of a webpage or if you have burp suite professional, you can also use the engagement tools by simply right clicking our target in the site map and selecting 'Engagement tools > Find comments'.

As a pentester, this is one of the few things that you will rarely report unless we are talking about secrets or credentials of course.

As a bug bounty hunter, these comments can be very useful to us as they lay out how the application works. This map of our target should be used and appraised but instead a lot of hunters tend to ignore it because it's tedious work to check all the comments but I find that it's usually well worth it to gain insight in how my target works.

These comments can usually be found in HTML but also in the javascript files at times and much more.

In the javascript files, we can also find things like API keys and credentials though we have to realise most API keys in javaScript files are actually supposed to be public like google maps API keys though if those keys to a third party exists, all is not lost.

If we have a third party connection which charges us per request, we need to limit the amount of requests a user can make, otherwise an attacker can make a lot of automated requests and rack up our bill. As a pentester and bug bounty hunter, we have to report issues like this but build a very clear PoC and case.

The severity of this issue can be pretty devastating to a company. For example a company that is just starting up can not handle a 100 000$ bill out of nowhere.

Building a list and checking it twice

Some web servers have a directory listing enabled by default. If this happens, an attacker can at least view the internal structure of a website, often allowing them to find new endpoints without doing much effort. 

BACK UP! This is your last warning!

Directory listings can lead to backup files which can contain source code. This is a great source of information for both pentesters and bug bounty hunters though probably not directly exploited. This information will give attackers a better overview of the inner workings of the application. Information is one of the most important things we can have in hacking.

Real life examples

Let’s talk about some real life examples to show this vulnerability type can have some serious implications. The first issue we are going to talk about pertains to a vulnerability where users' client lists are sent through SMB in cleartext. This should not be an issue as the attacker needs to perform a MiTM attack to get that SMB list or needs to be inside of the network to sniff this data. 

https://nvd.nist.gov/vuln/detail/CVE-2018-11338

Our second example may seem to carry less impact until we look at the affected organization which is the DoD in this instance. They were leaking some custom field names and custom SLA names through a JIRA endpoint. The vulnerability was as simple as finding the correct URL and browsing to it with undesired consequences.

https://hackerone.com/reports/1067004

‍

How Can I Prevent Sensitive Data Exposure?

To prevent this vulnerability we have to guard our data very carefully. We need to create a plan for keeping track of all of the data we have and what is sensitive. When doing this we will need to keep several things in mind, these are regulations, privacy issues such GDPR and what data matters to the business stakeholders.

When handling this data, for example in debug or log messages, make sure to apply the strategy we set out per data type as some can have different requirements than others.

When handling this sensitive data, we need to make sure that we get rid of it as soon as possible and that we do not register or log it when it is not needed. This will greatly reduce the chance of exposing sensitive data.

If there is no other way than to store sensitive data, make sure that it is not in plain text format but encrypted properly. This is important because if the data does get stolen, it will be much harder to use and maybe even useless to the attacker.

This encryption needs to be done securely and with the correct, strong and up-to-date encryption algorithms applied to all data encryption. 

It goes without saying that data that is being sent over any network is best encrypted to prevent any data leakage as well.

Moreover a company should have a great grip on their security. They should not leave any ghost repositories floating around with potentially sensitive data. In the case of repositories this also goes for comments and commits.

Special attention should be put into the caching of data as well as this is also a potential location of sensitive data.

Any password should be stored in password managers which should be set up to ensure secure storage with a proper encryption algorithm.

‍

Conclusion

Sensitive information disclosure is one of the bugs that rarely leads to a report as a bug bounty hunter and rarely leads to a report with more than a medium/low severity rating. When it comes to the leaking of

• Account information
• Credentials
• API keys

Usually information disclosure is used to pivot to a much more impactful vulnerability. Information in and off itself is useless if we can't use it after all. The reputation and technical know-how of a company is at stake as their internal, web and API security can easily be open to sensitive data exposure.

Watch the video: