Ask pen-testers and they will tell you that the attack is as successful as how much information they can gather during the reconnaissance phase. Reconnaissance is the phase where the attacker tries to gather as much information about your application as possible. How is this useful? ……Simple….Information is POWER.
If the attacker knew which operating system you are running on, they can look for vulnerabilities related to this specific operating system. Even better, if they can find out the specific version, you just made it easier for them.
Another instance, if the attacker found a name inside an HTML comment, they can start social engineering this name and through him, or his personal computers, they can get to the application. And this is exactly what happened when Twitter’s admin account was hacked.
So what are the information that can be leaked:
– Detailed Error Messages: As mentioned above, this can help an attacker profile and fingerprint the application. Afterwards, it is just a matter of time until they find a way to exploit your system.
– Confidential Information: Credit card numbers, social security numbers, passwords, usernames, dates of birth…etc. All these are goodies for the attacker.
– Names: As mentioned before, names are very helpful in a social engineering attack.
– Source Code: Yes, source code. That’s an attacker’s dream to get the source code, just a gold mine. All the business logic, passwords, details, names, history, servers…everything he’s ever wished for would be in there.
So where are the places you would look for information leakage in your information?
– Web Services: A lot of developers rest assured that since web services does not have an actual interface, so they think an attacker will not be able to find these services. They are right, attackers will not find them….they will let some tools find them !!. A lot of web services out there are not properly protected or are not protected at all. And there is a lot of information that can be leaked by these web services.
– Printing to the console: I am guilty of this myself. I admit it, I have used the console in the first programming years almost always, it is easy to use, easy to check what went wrong with the application and almost zero maintenance. What’s the problem then? exactly what I just said: It is easy to see what went wrong with the application. I can hear you saying: but the attacker has to be on the machine in order to attack the application? The answer is yes. BUT, remember a lot of the attacks happen by or through internal employees. Here is an article by ITSecurity that claims that internal threat is responsible for up to 85% of the application attacks.
– Log Files: Log files contain a lot of information. A lot of programmers log usernames, passwords and other sensitive data. Heck, I have seen applications that log the whole request in the log files. Now imagine, the following scenario: some problem happens on the production, the programmers ask for the log files in order to know what went wrong. The IT person sends the files to the programmers, and CC a whole bunch of people. One of the programmers decide that it is not their problem and forwards the email to another person and CC a different whole bunch of people. See how many individuals had access to the what’s supposed to be confidential data?….you get the point.
– Web Pages: Confidential data written unmasked to web pages is a serious problem. why? the problem is that these web pages could be cached either by the browser or by the cache server. Or it does not have to be that complicated, a shoulder surfer can see your user’s credit card number while they are enjoying their favorite latte at Starbucks and empty it in a matter of seconds.
There are numerous causes for information leakages. The above is just the tip of the iceberg. So the question is: is your application leaking?