Log4j Pandemic and Some Thoughts on 0-Day Threats
Nearly a month and a half has passed since the events described here took place, and it seems that virtually everyone who is anyone in the IT sector (or close to it) heard when the story broke.
Unfortunately, just hearing the news is one thing, being affected by it is another thing entirely. The worst part of the story is that right in the middle of the Christmas holidays, countless industry pros were called out to patch their servers and try to fix the issue. Could all of this have been easily avoided? Oddly enough, it seems so.
The whole idea is based on an old principle:
“You don’t have to run faster than the bear to get away. You just have to run faster than the guy next to you.”
In order to understand the situation, you need to know what a 0-day vulnerability is (feel free to skip this paragraph if you know the basics). A 0-day vulnerability is a threat that has never been seen before – a completely new threat – which makes it impossible to detect and block through traditional mitigation means. Typically, server security threats are identified using the existing data on the well-known features of existing vulnerabilities and threats. This is what we call a signature method: the request coming from the visitor is compared with previously identified threat signatures, and if it does not match, we can conclude that it is safe.
For obvious reasons, this type of an approach doesn’t work with previously unknown, “0-day” threats. In this case, alternative approaches like Heuristics and Anomaly Detection algorithms may be implemented. Unfortunately, in practice, these algorithms are often responsible for most of the false positives, which can be especially frustrating for hosting companies. This type of solution requires you to maintain a team of security engineers who are constantly fine-tuning the system and settings. With so much advanced tech out on the market today, it seems that there should be an easier way to protect against most of these threats, at least for a while, until the vulnerability is fixed in a more relaxed manner.
Ironically, protecting your servers from 0-day vulnerabilities is often possible even if you don’t know anything about the nature of the threat. Let’s break it down together using good, old fashioned logic! It comes as no surprise that the first phase of an attack is usually a search for vulnerabilities, which is carried out by automated software tools, also known as bots. We may not know what this new threat is, but we know exactly who is carrying out the attack. If you can block the bots sent in the first phase, you will at the very least gain valuable time to react. Circling back to that slightly cynical old principle we mentioned earlier, if such automatic tools (bots) do not have access to your servers, then your engineers get to take a breather while attackers continue next door to hack your neighbours.
Simply put, if you are currently blocking all “bad” bots by successfully distinguishing them from humans, you are surprisingly much better protected against 0-day attacks than your peers and competitors.
To be fair, this will not protect you completely from hackers acting manually and maliciously, although even in this case it may somewhat complicate their task. By utilizing this so-to-speak “security by obscurity” method, your engineers can calmly finish their coffee and carefully, without panic, start fixing the gaps.
If you have any thoughts or desire to discuss this topic, please write to me at konstantin (at) botguard.ee.