Another day, another web application gets hacked. Most of the time web application hacks fly under the radar and are discovered years after the data breach occurred, but every so often, after learning what had happened, website administrators hire computer forensic experts in order to help reconstruct and solve high-tech (computer-related) crimes. Every computer forensic expert (or a team of computer forensic experts) has different methods of approaching and solving the problem – but in many cases, the very first thing computer forensic experts need to do is to secure the evidence of the incident. Securing the evidence is necessary so that the incident can be reviewed and potential threats and vulnerabilities can be unmasked and successfully patched.

But not all investigations go according to plan – at times, no evidence could be obtained. Where’s the problem you ask? The problem is that when no evidence can be obtained, the investigations come to a halt. When cyber incident investigations come to an end, website administrators are left clueless and with the same questions like how did the adversary gain access? What data was compromised and what should they do next in order to prevent such accidents from unfolding for the second, third, fourth time?

That’s bad news for the developer. On the other hand, this is great news for the attacker! Attackers rely on the lack of logging and monitoring in order to accomplish their goals without being detected.

Defining insufficient logging & monitoring

Insufficient logging and monitoring is such a vulnerability that occurs when a web application fails to sufficiently log accidents, does not monitor policy violations, or does not register any event that could be a potential indicator of a compromise.

Let’s start with the usual attack vectors, security weakness and impacts bit:

Threat Agents / Attack Vectors		Security Weakness		Impacts
App Specific	Exploitability: 2	Prevalence: 3	Detectability: 1	Technical: 2	Business: ?
Exploitation of insufficient logging and monitoring is the bedrock of nearly every major incident. Attackers rely on the lack of monitoring and timely response to achieve their goals without being detected.		This issue is included in the Top 10 based on an industry survey. One strategy for determining if you have sufficient monitoring is to examine the logs following penetration testing. The testers’ actions should be recorded sufficiently to understand what damages they may have inflicted.		Most successful attacks start with vulnerability probing. Allowing such probes to continue can raise the likelihood of successful exploit to nearly 100%. In 2016, identifying a breach took an average of 191 days – plenty of time for damage to be inflicted.

The OWASP definition mentions that some of the most successful attacks on web applications start with the attackers probing for vulnerabilities – if website administrators are allowing the attackers to gain insight into their web application by allowing the probes to be completed, their web application might be exploited.

How would an attack look like?

In its essence, this security vulnerability is pretty simple to understand – your web application might be susceptible to this flaw if its logging of events is non-existent or insufficient.

Imagine you own a PHP-based shopping website. With your website being related to commerce and shopping, it is likely to attract the attention of an attacker. The attacker has already tried phishing your customers, but since your customers were educated and informed such actions might be a possibility, they recognized what’s happening and did not get their identity stolen.

The nefarious party realized that his first plan to harm your customers was blasted – now he needs to come up with a better idea. Not long after, he came up with another plan – the attacker will now try to find security vulnerabilities in your website and exploit them so that he can be granted access to the administration control panel.

The attacker failed to find any vulnerabilities that would help him accomplish his goal, but he did some digging and stumbled upon a login page:

He tried logging in with all sorts of default combinations of credentials, this was the outcome:

Then he tried a few more times:

Wait – what’s that? The response is now different! The response does not tell much, but what it is saying is “yes, that account exists on this website”. And that’s everything an attacker needs to know – he now knows that the website is vulnerable to account enumeration. Knowing that, everything that the hacker needs to do now is make a script that would automate the process and wait. And when the attacker eventually knows the credentials that are being used, he will log in.

Bingo – access has been acquired.

A couple of weeks (or even months) pass and you notice something weird. Some of your settings have been changed, some new products have been added, some of the testimonials are written in a foreign language. That leaves you and your team wondering whether your website did suffer a data breach. You hire a data breach response team in order to evaluate the situation, they launch a briefing and ask your in-house team to hand over the evidence of the incident, more specifically, the access logs. Your team is baffled – what access logs? “We did not preserve any logs..” – you answer. You follow up with a question: “why did you ask for them?”

Here’s the thing – in order to gather as much information as possible and provide guidance how to proceed, the data breach response team needs to review the logs. Because your in-house team did not preserve logs, they cannot be reviewed. Because the logs cannot be reviewed, the incident response team may fail to uncover the true extent of the breach. Because the root causes of the data breach may remain undetected, there’s a good chance your web application will suffer a data breach again. This is not exactly the scenario you were dreaming about, is it?

What made this possible?

Because your web application did not preserve adequate logs, the attacker(s) were able to rely on your web application’s lack of monitoring and response to achieve their goals without being detected. In order to ensure your web application does not suffer a data breach again, and if it does, mitigate the consequences as quickly as possible, make sure your web application logs all failed logins (to make your web application even more secure, consider logging all successful logins too) and server warnings or issues.

Backup everything (including logs)

What if I told you that your web application can still preserve logs even if a data breach has occurred and the logs were deleted? Imagine your web application is hosted on a Virtual Private Server (VPS). To accomplish this, simply back up all logs to another VPS (or a dedicated server), so even if your website gets hacked and the hacker deletes the logs, your team will have a copy that can be provided to a data breach response team.

Summary

Even though this vulnerability occupies the very last place in the 2017 OWASP Top 10, it is not a vulnerability that should be taken lightly or ignored. Insufficient logging and monitoring covers situations where logging could improve the security of a web application. In the best case scenario, both logging and monitoring of your system should be automated – there are a few tools that can help you accomplish that goal:

• Splunk – Splunk “turns machine data into answers” or in other words, it allows you to identify security issues in a very fast, convenient way.
• Tripwire – Tripwire is a data integrity tool. It allows you to monitor your files and directories for any changes.
• Snort – Snort is a network intrusion detection and prevention system.

To sum up, there is no “one-size-fits-all” solution when dealing with insufficient logging and monitoring. To avoid being in situations like the one above, prepare your team for a data breach – it will happen. When tackling insufficient logging and monitoring, what matters is your preparation and handling. Harden the security of your web application, put some integrity controls in place and have a good data breach response plan. That should set you (and your team if you have one) on a good path.