Falling victim to a zero-day cyberattack feels very much like having your house broken into in broad daylight. Except the burglars get in through a front door, with a duplicated set of keys, instead of climbing through a smashed window, says Matias Madou, CTO and co-founder at Secure Code Warrior.
Sadly, zero-day attacks are on the rise, leaving numerous organisations around the globe violated and exposed. With the widespread recent Log4Shell vulnerability, it’s safe to say this serves as a wake-up call for many businesses. However, there is path forward for defending against the zero-day threat category, not to mention vulnerabilities that have been missed in the software development process.
The rise of a million-dollar zero-day market
Zero-day exploits tend to go for a pretty penny on the dark web, with one listed for $2.5 million (€2.31 million) at the time of writing. Reported to be an exploit of Apple iOS, this golden ticket has the potential to compromise millions of devices, harvest billions of sensitive data records, and do it as long as possible before it’s discovered and patched.
The zero-day market is based on supply and demand, so the question is who has that kind of money? Well, organised cybercrime syndicates will come up with the cash if it’s deemed worthy, especially for ever-popular ransomware attacks. Global governments and defence departments often use them for threat intelligence. Additionally, the companies themselves may be buyers of their own potential zero-day exploits so they can mitigate disaster.
The auctioning of cybersecurity exploits is also becoming a concern in the face of increasingly popular non-fungible tokens (NFTs). Originally listed by a cybercriminal on the OpenSea NFT marketplace, a token for sale was described as a post-authentication memory corruption vulnerability in the ioquake3 engine. It claimed that it could be reliably used to trigger a known issue on the 28 games that use the engine, and therefore cause a denial-of-service condition.
In August 2021, data compiled by Google’s Project Zero revealed that it was already the biggest year on record for ‘in the wild’ zero-day exploits, with the industry detecting more exploits in the first five months of the year when compared to 2020 in its entirety. It is large organisations, government departments, and infrastructure that are most at risk of being probed for any weaknesses.
Whilst there is no way to be completely safe from the possibility of a zero-day attack, organisations can “play the game” somewhat by offering a generous bug bounty programme. Rather than wait until someone offers the keys to your software on a dark web marketplace, get legit security experts on your side and offer them decent rewards for ethical disclosure and potential fixes.
The new and dangerous breeding ground for zero-day threats
A shared and truly immersive virtual world is currently being created by some of the world’s largest organisations such as Meta. As the roots of the metaverse are now taking shape, the new virtual world could unfortunately be the next dangerous breeding ground for zero-day exploits, bringing dire ramifications to our reality.
A significant amount of new infrastructure and devices are being incorporated into the metaverse, with the cybersecurity risk associated with it steadily increasing. This is, and will continue to be, partly driven by a much wider uptake of VR headsets that carry unprecedented levels of user data. Undoubtedly, complex embedded systems security will be required to protect emerging IoT technologies such as VR and augmented reality (AR) as usage grows.
The wider industry has focused on the level of security integrated into metaverse platforms from the outset, and whether this will influence how successful they are with consumers. Attacks that aim to exploit web services are likely to present a similar challenge in the metaverse. To add more complications, there’s also the need to consider NFTs and the wider role of cryptocurrency in the metaverse as real life and virtual wealth starts to intertwine.
A big headache for CISOs
The rise of new technologies, fast-tracked hybrid working models, and a widening security skills gap all contribute to giving a lot of CISOs around the world a giant migraine.
In a field known for its burnout, they grapple with the lack of security-skilled people to meet demand and a growing need for agility, forcing security professionals to work with information overload in the form of data, reporting, and monitoring of huge toolsets that could be a potential liability. Depending on the size of the organisation, the seemingly simple process of patching can be a cross-departmental bureaucratic undertaking. There are also few patch management mandates, while widespread legislation is currently a pipe dream.2
On top of that, not all professionals and developers will have a comprehensive knowledge of all libraries, components and tools actively in use. Professionals in the development space also typically have one hand tied behind their back by strict deployment schedules in place to reduce any downtime. All these factors can create exactly the type of scenario that can cause them to miss a critical alert, which may well have been the case when it came to properly assess Log4j for its weaknesses.
Developer-driven threat modelling
As code-level vulnerabilities are often introduced by developers, they need precision guidance and regular learning pathways to build secure coding skills. Trained, next-level secure developers should also be given the opportunity to learn and practice threat modelling as part of their software creation process. After all, these are the people who know their software best and they hold powerful knowledge on its features and how users interact with it. Therefore, if they are sufficiently security-aware, they should know all of the potential scenarios where it could break or be exploited.
Bringing this back to the Log4Shell exploit, we are seeing a scenario where a catastrophic vulnerability has escaped detection by experts and complex toolsets, however, it may not have occurred at all if the library was configured to sanitise user input. The decision against doing so seems to have been an obscure feature for added convenience but made it painfully easy to exploit. If threat modelling was done by a group of security-savvy developers, it’s highly likely the situation could have been prevented.
A great security programme has human intervention and nuance at the heart of solving human-created issues. Threat modelling takes empathy and experience to be effective, as does secure coding and configuration at the architectural level of software and applications. This is something that takes time to upskill to a level where developers can take the pressure off the security team and work in collaboration to create solid zero-day defence.
The next part of dealing with a zero-day is getting patches out as fast as possible, in the hope that every user of the vulnerable software applies it before an attacker gets there first. With Log4Shell, it could eclipse Heartbleed in its endurance and potency in the face of it being embedded in millions of devices and creating complex dependencies across a software build.
The Log4Shell debacle is just the tip of the iceberg. Zero-day attacks are on the rise and can indeed be the stuff of nightmares, however, organisations that commit to the use of all available tools and implement threat modelling will sleep a little easier.
The author is Matias Madou, CTO and co-founder at Secure Code Warrior.
Follow us and Comment on Twitter @TheEE_io