Introduction

Untitled

I feel like a lot of mystery surrounds this topic. 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 ofcourse 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 disclosers 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 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.

How does it occur

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 webserver itself might contain configuration files which are visible to visitors of the webserver
• 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.

Physical threats

When it comes to pentesting, i think a lot of hackers forget the physical aspect of pentesting. I've worked with numerous clients that i offered a physical pentesting packages as well and i've been able to just walk in with employees by just pretending like i belonged there. I observed the dress code, bought a fluo vest and a helmet and walked right into a high security construction zone like nothing wrong was going on. I took one of their keyboards to show i was at the main frame and i turned in my assignment to get a hefty bonus. All of this would not have mattered if i would not have found the password to the mainframe on a physical post-it note on the server rack which i took a picture off.

This is a cool story from my experiences but the point i am trying to make is that physical entry does need to be considered when creating a security plan. When a pentester is on an assignment but not assigned to do physical pentesting, he/she should report any infractions they see though as it's not part of the scope but as long as you do not do intrusive testing, an observed defect can be reported like a door that is always open.