A3: Sensitive Data Exposure 2017 OWASP
I feel like a lot of mystery surrounds this issue from the top 10 OWASP vulnerabilities. A lot of people seem to wonder which data is sensitive when exposed. Some people seem to think every single API key disclosed in a JS file is a vulnerability but of course this is not the case! Some API keys are supposed to be used by XHR requests and they are supposed to be public. When it comes to information disclosure we always have to keep in mind that what we see should be private and even then it's not guaranteed to be a vulnerability. Depending on which viewpoint you take (Pentesters or Bug Bounty Hunters) you should be less or more careful with what you report. We will go much deeper into this when we talk about what to report and what not to report.
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
- 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
- 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 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
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
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
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 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.
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.
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.
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.
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.
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
- 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:
Understanding how to prevent Sensitive Data Exposure - OWASP pdf
Sensitive Data Exposure - Github topics
Subscribe for the latest news
Our recent webinar with the industry overview and product demo.
Solution brief on protecting apps and APIs with Wallarm.