InformationWeek ran a story last week about misconfigured Apache web servers that exposed server settings. This is bad because bad actors can use that information to potentially successfully attack the server. For instance, if they know of a vulnerability in a particular version of an application, and see that a site is running that version of the application, it is possible or even likely that an attack making use of that vulnerability will succeed. The article discusses how to plug the leak.
The general concept of exposing unnecessary and potentially exploitable information is called information leakage. It applies to far more than server versions and software, however. Many of us know about it when it comes to personal information. We are told from an early age, for instance, to keep our vacation plans private and never to tell strangers or others who don’t need to know.
Company phone books — whether printed or on the web – are another source of leakage. They often list names, titles phone numbers and addresses/mail stops. Some even list mobile numbers. An attacker can use this information for impersonation or to bypass “gatekeepers”. If one knows the name and number of the IT tech, for instance, there is no need calling the main switchboard and asking for “the guy who fixes PCs”. That is why most security-conscious organizations shred phone books or lists before tossing them into the dumpster.
Another place we see information leakage is in error messages. Some error messages include extensive reporting so programmers can fix the errors when they are encountered. As a programmer I’ve done this many times. Production code, however, should not have these extensive errors because some of the information contained in the messages might make the system easier to attack.
Another vector for leakage occurs when users can inject database commands into a stream. For instance, if an entry requesting a customer name were not properly configured, it might allow a name such as
Mary; select * from users;
to be entered and perhaps a list of users to be displayed. Proper software design prevents this.
When I was first learning to program I used an IBM mainframe. We often used a timesharing system that allowed us to enter programs on printing terminals. When it was necessary to list the programs we could list them on the slow terminals or send them to a much faster shared printer. Once when doing the latter I got the listing of another user’s database included with my listing This leakage was due to some sort of system error that I was too inexperienced to understand, but the content of the database could have been very sensitive.
Some information leakage can be stopped by good software design. Some is stopped by good confidentiality practices (such as shredding). Unless people are aware of the dangers, though, the leakage is seldom addressed. We talk about information leakage and ways to address it in Course 468. What are you doing to monitor and eliminate information leakage?