Cyber Warfare – The threat of the 0-day – Is there nothing we can do?
Introduction
Breaking news within our Cyber Security domain has become almost an everyday business; Cyber-Warfare and crime has become an everyday threat against democratic values, privacy and the livelihood of most organizations are threatened. Our online and interconnected networks, ranging of hundreds of systems and hundreds of thousands of lines of code are putting us at risk.
Yesterday, principal consultant Chris Dale commented on the 9 ‘o clock TV2 news here in Norway. The Norwegian parliament had become one of the many victims of the Microsoft Exchange vulnerability everyone has heard of by now. The status quo? A much more serious attack than the Solarwinds compromise which is still lingering fresh in our minds.
This post tries to address some of the things which was commented on in order to shed more light and nuances in the debate. The interview (in Norwegian) can be found here: https://www.tv2.no/v/1640084/?wf=ext
Can 0-days not be prevented?
One of the statements from the parliament were “Because the software provider was not aware of this vulnerability, criminals had knowledge of it, the parliament could not have prevented this breach“. In its nature, a 0-day is a vulnerability for which there exists no patch, but that does not imply that no mitigation exists.
There are many ways for networks, systems and applications to be configured with resilience against unknown attacks, whether it is by disrupting the attack and ruining the exploitation efforts completely, or by simply preventing the installation, execution or completion of backdoors.
Let us explore some options which can help prevent the inevitable unknown vulnerability having a dire consequence.
Availability of Systems
Do not expose the systems on the Internet directly. Instead, work towards implementing zero-trust architecture where users and clients must identify themselves in order to get access to the ranges of systems behind it. This greatly limits the attack surface available online. Consider what would happen if you allowed clients to synchronize their emails only if the client was authenticated via a VPN software?
Some of us will recognize that this is not a perfect solution. You might even be opposed in approaching such a solution, just because it is not a perfect solution. The VPN could have a 0-day vulnerability, the clients can get compromised and so on. That is however outside the scope of mitigation. We are not looking to create perfect security solutions, they simply do not exist. Instead we are looking at reducing and mitigating the threat of adverse effects, unfortunately often compromising with the ease-of-use and user-friendliness of using our systems and tools .
Perhaps more effort should placed into teaching awareness, creating easy to use applications. How hard is it really to enable a VPN over your smartphone or computer? In many cases VPN are really easy to use and can even be automatically enabled on our users devices. It seems that still today, availability of solutions are in favor of organizations decisions in how they make secure decisions, or they do not know of the capabilities and solutions which are present on the market to make things secure enough.
Application Specific Firewalls
The vulnerabilities in Microsoft Exchange were using web-application vulnerabilities. A Web-Application Firewall (“WAF”) can use not only signatures against known attacks to block threats, but also heuristics to block unknown attacks. Some WAF’s can be configured with a very strictly configured ruleset which only accepts known good behaviors of the application it protects.
While a WAF could potentially protect against these attacks, it would not serve as a perfect solution. A hardened and tightly configured WAF would have even more opportunities not not only block attacks, but detect reconnaissance and the abuse of the service.
For critical services, such as emailing, organizations should focus on building defense-in-depth so that the services are not easily crumbled via attacks like those made possible via 0-day vulnerabilities. Defense-in-depth can serve as effective roadblocks which could be circumvented, but in many cases would defeat the initial attack enough for a patch to be developed before attackers are able to circumvent the defenses.
Blocking Attacker Goals
The communication channels which the attackers require to utilize the exploit can be prevented. A simple example would be to limit a servers capability to connect out-bound via the firewall back to attacks, also known as blocking reverse-connections. While not all backdoors rely on reverse-connections, this is a mitigation which can be implemented without harming the usability of the service. A service is deployed to accept connections from users (and also attackers), but is not designed to connect to arbitrary IP addresses on the Internet.
Many of the backdoors seen installed as part of the Microsoft Exchange vulnerability was not reverse-connections, but instead hosted backdoors which could be accessed the same way as you would access the compromised service. This has also many avenues for defenders to block. What about antivirus scanning files uploaded to the web-server? Yes, your servers can run antivirus too! This would force the threat actors to create backdoors that when uploaded would have to defeat signatures of antivirus tools. This further hinders the attackers as while they might be able to evade the antivirus on some systems, eventually when the backdoor is detected, signatures would be created and distributed across other clients and customers also running antivirus, creating a somewhat effective prevention and detection mechanism.
With backdoors uploaded to a service, this also significantly disrupts the traffic patterns on how the service is accessed. All of the sudden a new script (the backdoor) is being accessed, never seen accessed before. Traffic which is not recognized as users checking their emails is happening, using functionality never seen before on the system. Log management and baselining of our systems could help detect this, perhaps before it is too late.
Logging is essential, especially in critical applications. The logs would likely reveal misuse, giving attackers less time to secure their actions on their objectives.
What else is there?
There are other mitigations as well, many which would greatly handicap the attackers ability in exploiting and abusing the service. While it seems the world is burning and there is no fire-extinguishers available, it is simply not true. There are many mitigations available, but the challenge in implementing these are time, knowledge and ability to change.
In many IT environments, IT operators are not able to challenge the already established. We have not already been hacked, so why create mitigations for something which we are not seeing? Just like the virus pandemic of Covid-19, the enemy is invisible. The vulnerabilities are always there, just not yet abused. We must always expect the unexpected, especially in IT where adversaries with a press on a keyboard can compromise everything we trust.
