Myth Buster II: We’ve Never Been Hacked
“We’ve never been hacked.” Those words are generally what let IT people sleep at night (or take long breaks to go play Guitar Hero). While it gives everyone a nice warm, fuzzy feeling like a lolcat, how would you know that it is true? Cause you haven’t had a customer complain about a strange transaction? Cause the data in your database looks fine? Cause your web server hasn’t crashed recently? Often, it’s because of a strong belief that logs will tell you everything and you don’t see anything crazy in there.
While most companies do spend some time and money on log analysis, a number of web attacks can go completely undetected given common logging architectures and configurations. A very simple example of this would be POST parameters. You can check all the boxes for the IIS logging configuration, but there’s still no way to enable logging of POST parameters without some custom programming. Not logging POST parameters makes sense as they are most often used to send usernames and passwords (something you wouldn’t want sitting as plaintext in your logs); but then any SQl injection attempts to bypass login go undetected. So, some programmers take it upon themselves to add additional logging in the application itself. Items such as writing out when someone logs in, or what data they are viewing or entering. While this is recommended and can often be helpful, it can also lead to a false sense of security. Most often a vulnerability in an application occurs at a point where the developer was unaware of a security risk. Therefore, developers commonly miss logging data at the correct spots, logging the correct parameters, that are used in an attack. In a number of cases, there is often no validation or encoding of data written to these custom logs. Thus it’s rather easy for an attacker to forge entries into the logs or truncate data by appending null characters in their attacks.
Even if you do log everything properly, some attacks don’t have signatures that would stand out. Parameter manipulation attacks often take advantage of subtle changes to the information sent to the webserver. Changing one account number to another valid account number. Flipping a zero to a one to get admin access. These attacks are going look like normal request to anyone reviewing the logs unless you already know some information about an attack that has occurred.
We have also seen a number of attacks against weak encryption that can go unnoticed for a huge amount of time. This should be painfully obvious now in the wireless world after the TJX attacks. Consider your own wireless network for a moment. Even if you are logging MAC addresses for every connection, how do you know someone is not passively capturing your traffic and decrypting it? Or has sniffed a legitimate user’s MAC address and is impersonating it?
In the web application world, we have seen weak homegrown session “encryption” for persistent logins. This didn’t take millions of sessions ids to crack, but rather just a handful any normal user would be issued. Think you would detect it based on IP addresses in your logs? Fairly unlikely, because your logs probably aren’t saving the session ids. If they are, the number of false positives is so high based on legitimate mobile users, that its often impossible to use that information to realize it’s an attack. Your IPS/IDS often will miss this attack as well since there’s nothing out of the ordinary in the requests or paths through the site.
How about Session Riding attacks? In these cases, we have a legitimately logged in user, coming from their normal IP address and standard web browser. If the attacker has done a proper job, a single Session Riding attack entry in a log file will look exactly like legitimate traffic. You would need to analyze the user’s path through the site to realize something was out of order. Again, in most cases, companies to not have the tools or resources to do this.
So before the next board meeting when someone announces “we’ve never been hacked”, take a few minutes to think about if there’s anyway you could know that is true. In most cases, there should be reasonable doubt to know the jury is out on that myth.