Zero-Day Exploits – Part 2

In the second part of our ongoing series about the dreaded zero-day exploit, we will look at specific types of zero-days. These include memory control flaws and ICS/SCADA flaws. If you don’t recognise any of these terms, don’t be alarmed as these types go by a variety of names and there is really no consensus as to what they should be called. Along with the analysis of the type of exploit, we will look at how threat actors discover and exploit these in the real world. In the next article, we will take a look at SQL Injection flaws and OS Command flaws. Each of these topics can fill a textbook and keep this article readable and not too academic. We will focus on two at a time.

Memory Control Flaws

Memory Control Flaws can cover a wide array of different flaws but perhaps the most infamous is known as a Buffer Overflow Flaw. This has been defined as,

“The program copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow…A buffer overflow condition exists when a program attempts to put more data in a buffer than it can hold, or when a program attempts to put data in a memory area outside of the boundaries of a buffer. The simplest type of error, and the most common cause of buffer overflows, is the “classic” case in which the program copies the buffer without restricting how much is copied. Other variants exist, but the existence of a classic overflow strongly suggests that the programmer is not considering even the most basic of security protections.”

As with all definitions they can be a slog to get through. In practical terms, a buffer overflow occurs when the developer has incorrectly managed memory within C/C++ code. These can be incredibly dangerous when discovered by a threat actor, as can be seen by the typically high price they demand on underground hacker forums.

The flaw was brought to the public attention in the early 2010s with two flaws, in particular, CVE-2012-1876 a buffer overflow in Internet Explorer, and CVE-2014-1303, a buffer overflow in Apple Safari.

Threat Actor Exploitation

The singular most important reason as to why these flaws are considered to be so dangerous is that if correctly exploited the attack has complete control over the victim’s machine. Once successful exploitation is achieved the threat actor can change the instructions of the vulnerable application while the program is loaded in the memory helping ensure persistence as well as making pivoting to other machines on the network easier.

An attack in 2015, involving vulnerabilities in Internet Explorer and the security nightmare that was Flash, proved to be one of the great examples of how flaws can be exploited to cause a security disaster. In the attack, a Chinese state-sponsored threat actor used the above-mentioned flaws to conduct a watering hole attack on the popular financial news outlet Forbes. Watering hole attacks typically involve the attacker compromising a website known to be used by the attacker’s targets to in turn compromise their machines. The compromise of the target machine is possible if the vulnerability used by the attacker hasn’t been patched on the target machine. In the past Internet Explorer and Flash were notorious for being an avenue of attack.

The attack involved the threat actor compromising the Forbes website by dropping a malicious widget. When the victim visited the website, the Adobe Plugin, which was discovered to be vulnerable by the attacker, downloaded and executed malicious code. The malware immediately started to collect information about the compromised computer and its network environment. The attack was found to attack predominantly those in the defense and financial sectors and was primarily a cyber espionage campaign. Due to flaws in Adobe’s Flash program, malicious code was being executed and importantly without detection, a must for cyber espionage campaigns.

ICS/SCADA Flaws

Industrial Control Systems (ICS) and their subset technology Supervisory Control and Data Acquisition (SCADA) systems have come under increased attack in recent years, primarily from nation-state groups looking to steal vital information or disrupt and destroy infrastructure. These systems have formed the backbone of modern industry but the rapid adoption of technology, amongst other reasons, has left massive gaps in the security structures of these systems.

Diving deeply into these flaws would take hours of reading and even more time writing. Rather, it is wiser to look at why these systems have proved vulnerable in the past and why they still present a major security problem. As to why these present a problem, three factors continually arise as issues. The first of which is available, these systems have to be online for extended periods, when a cyber-attack occurs they cannot be shut down quickly like typically IT systems to stop the bleeding so to speak. Fast shutdowns can present safety concerns and other factors impacting the bottom line.

Secondly, the lack of standardization is a major headache to any security professional. Systems often have proprietary protocols that are not designed to communicate to the wider IT infrastructure. In practical terms, this means that when patches are released they can’t be updated and applied quickly like the company’s desktops. This issue is further exacerbated by vendors’ operating on variable patch timetables leaving gaps in the security structure even after the vulnerability has been made public. 

Lastly, when companies invest in an ICS system they need it to be operational for years, often long after the support window has closed. These systems come with a price tag and a return on investment is needed even if the security of the product is relegated to a smaller concern. This means that if a hacker discovered a zero-day in older versions of the product no longer supported a fix from the vendor is unlikely.

Threat Actor Exploitation

One of the more infamous exploits of an ICS zero-day was Stuxnet. While there have been documentaries and reams of academic literature dedicated to the topic, perhaps McAfee’s summary best describes it. The security firm stated,

“Stuxnet was a multi-part worm that traveled on USB sticks and spread through Microsoft Windows computers. The virus searched each infected PC for signs of Siemens Step 7 software, which industrial computers serving as PLCs use for automating and monitoring electro-mechanical equipment. After finding a PLC computer, the malware attack updated its code over the internet and began sending damage-inducing instructions to the electro-mechanical equipment the PC controlled. At the same time, the virus sent false feedback to the main controller. Anyone monitoring the equipment would have had no indication of a problem until the equipment began to self-destruct.”

The result of this was alleged American and Israeli state-sponsored groups destroying the uranium enrichment centrifuges central to the Iranian government’s nuclear weapons program. Regardless of how you feel about the morality of the operation, the hard truth is the attack opened a Pandora’s Box emboldening other nations and hackers to exploit flaws in these critical systems. The box cannot be closed and security professionals have a major headache to deal with and no easy fixes to help.

What’s Next?

As mentioned above, looking at the varied types of zero-days encountered by analysts is not done. In the next part, we will look at SQL Injection flaws and how your operating system (OS) can be vulnerable to malicious commands.

Tags: No tags

Comments are closed.