Commentary on ArsTechnica article dated March 16, 2023: “Federal agency hacked by 2 groups thanks to flaw that went unpatched for 4 years” and how a Positive Security Model would have averted the successful breach.
Background:
On March 15th, 2023, CISA, FBI, and MS-ISAC reported that an unnamed civilian US Federal Agency had been hacked by two threat actors, at least one of whom was working on behalf of a nation-state. The agency had not patched a critical four-year-old vulnerability, CVE-2019-18935, present in a publicly exposed IIS Web server. This vulnerability was reported to NVD on 12/11/2019 and involves a Telerik library that bundles UI components used by developers to build web applications that are hosted on web servers like the IIS Server.
A Deeper Dive into the Attack:
To exploit the abovementioned CVE, a bad actor would need to have encryption keys for the UI components in question. To get around this problem, the attackers used an even older critical vulnerability, CVE-2017-11317, that also had remote code execution attributes. This obfuscated the need for any UI component access.
The exploit used by the bad actors targeted the Telerik code that ultimately deserialized user-provided input that had a malicious code in the form of a dynamically linked library (DLL) lurking in it. The vulnerability led to the malicious DLL executing on the victim server, thereby allowing attackers to execute arbitrary code of their choosing on the vulnerable server.
Attack Kill Chain
The attacker sent a serialized “object” which contains a malicious file and requested the vulnerable Telerik UI component to install the malicious file at the instructed path IIS server to install as below:
object = {'Path': 'file:///' + temp_target_folder.replace('\\', '/') + '/' + filename_remote}
type = 'System.Configuration.Install.AssemblyInstaller, System.Configuration.Install, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
raupostdata = build_raupostdata(object, type)
On receiving this mal-constructed request, the vulnerable Telerik UI IIS server installed and loaded the malicious DLL into memory. The malicious DLL contained a function called DllMain that automatically executes immediately on loading into memory and does not need any user interaction. This DllMain contains enough code to start up a reverse shell to the attacker’s command control center
Attack Containment
Fast forward to November ’22, the victim server in the US Federal Agency exhibited signs of being compromised. On digging into the logs, it was found that the nation-State threat actor was lurking in the US Federal Agency’s network since August ’22. On researching the IP addresses from where the nation-state-based threat actor infiltrated, one address was found to be in North Bergen, New Jersey, USA, and another in Seattle, Washington. The other threat actor was, with a high likelihood, a hacking organization called XE Group, based in Vietnam, that typically engages in payment-card skimming. The DLLs this group delivered included code that establishes a reverse connection back to their command control centers.
Telerik Patch
On Jan 14th, 2020, Telerik released a patched version of the vulnerable library. Vulnerability Scanners use software package-dependent plugins to scan for vulnerabilities those packages. However, in this case, the impacted agency used a reputed Vulnerability Scanner but the required plugin was not configured adequately and ended up excluding the directory path through which the vulnerable Telerik code was installed.
Some “interesting” facts from this (yet another) CISA Alert:
There are several very interesting aspects that one needs to ponder on as below:
Inertia in Compensating Vulnerabilities with Remote Code Execution (RCE) could be Disastrous.
A vulnerability with RCE attributes is a ticking time bomb. In a previous blog, we identified that ~92% of vulnerabilities in the CISA Catalog of Known Exploited Vulnerabilities had RCE attributes. The other 8% of vulnerabilities involved other procedures (or TTPs) that facilitate what an attacker would need to accomplish. For example, one of the non-RCE vulnerabilities helped to escalate privileges.
With the unfortunate incident described in this latest CISA alert, the role of an RCE vulnerability has yet again been brought into sharp focus. The connection between RCEs and attacks is no coincidence. We should think of the RCE as a facilitator for the bad actor.
The need for an unconditional Compensating Control cannot be understated. Such a Compensating Control must not need signatures or any prior knowledge if we are to be able to protect our respective enterprises from risk from vulnerabilities that have RCE attributes.
Vulnerability Scans Could Give a False Sense of Security
In the aforementioned previous blog, it was also highlighted that many vulnerabilities had been exploited even before the vulnerability was registered in the National Vulnerability Database (NVD). This means that Vulnerability Scanners, which inherently rely on vulnerabilities being reported into, a vulnerability database would be totally blindsided by an unreported vulnerability. Therefore, a cyber protection strategy that relies solely on vulnerability scanning can lull us all into a false sense of security.
The Federal Agency did the right thing by scanning its servers for vulnerabilities but failed to configure the .NET plugin correctly. Vulnerability scanners are usually run by IT/ InfoSec Staff, whereas the nuances of the plugin should ideally be handled by the AppSec Team, who typically have finer grain intelligence about the various 3rd party packages used by the application. This communication gap can lead to misconfiguration, which, in this instance, resulted in the scanner being blindsided not only by a four-year-old vulnerability, as reported in the article, but, even more importantly, a six-year-old vulnerability, as well. With third-party applications using hundreds of 3rd party packages, it is easy for the IT Team to fall into the plugin misconfiguration trap we discussed above. How is the IT/InfoSec person even supposed to know what scanner plugins they should be using and how to configure these effectively?
Had there been an unconditional Compensating Control that protects applications, the Federal Agency would not have found itself in the news cycle.
Patch May Not be Available When Vulnerability is Announced
There are many instances of a patch not being available for a significant time after the vulnerability is reported. In this instance, the vulnerability was reported on 12/11/2019, but the patch became available on 1/14/2020. What is an organization supposed to do in this eventuality?
This complication notwithstanding, had there been an unconditional compensating control that protects applications at run time irrespective of whether the application was patched or not, the Federal Agency would not have found itself in the news cycle.
Prioritizing Patching: Real World vs. Real-Time?
Given the sheer volume of vulnerabilities that are reported daily, especially those with RCE attributes, prioritization of patching is a natural response for most organizations. Unfortunately, bad actors operate on a totally different opportunistic principle. The smallest chink in a victim application’s armor is enough to spur a bad actor into action. Organizations should not expect any mercy from attackers.
To date, Federal Agencies have only had two choices in patch management:
-
-
Patch multiple times per day, per week, per month: This requires heavy amounts of human capital (time), pulling limited resources away from more business-critical cyber activities. Further, this model presents an increased risk of disrupting continuity of operations.
-
Follow the current ‘best-effort’ model: This comes down to patching when you can, or at least when you absolutely have to, resulting in an increased attack surface due to inherent software vulnerabilities which are not addressed as quickly as they emerge.
-
Published Exploits Activate More Script Kiddies
It turns out that the exploit code for both vulnerabilities used in this attack was posted on the Internet. Unlike script kiddies, organized criminals have paid professionals who have a better ability to develop exploits. Nation-state attackers have an even better ability to generate exploits for RCE vulnerabilities where one does not already exist.
As reported, there were two sets of threat actors at work – a nation-state bad actor and a threat actor from Vietnam. What is interesting in this case is that the population of attackers who joined the party increased substantially since the barrier for generating exploits didn’t exist. The odds of exploitation go up substantially as the pool of bad actors looking to take advantage increases. Organizations need to pay special attention to those vulnerabilities where exploit code is available as a free download.
No matter what source the attack is coming from, unconditional Compensating Control would still be a very effective deterrent.
Consider a New Approach Through the Positive Cyber Security Model
For some time, the security controls we leverage to protect our organizations from bad actors have relied on post-mortem analysis. That is, analyzing successful attacks in order to try and prevent them from happening again. However, today’s malware authors are rapidly turning to “Short Fuse Malware” that can complete its malicious objective in less than one second, long before the current set of security controls have had a chance to “learn” this new behavior of the application. This inability to “learn” fast enough is fundamentally a time-based vulnerability in the security product itself.
Relying almost exclusively on the current Detect-Respond-Remediate paradigm, organizations still struggle with what is quickly becoming a vulnerability-driven tsunami of attacks, challenging even the most vigilant among us to stay ahead of determined cyber adversaries. While the Detect-Respond-Remediate approach may be a good strategy for protecting from a second wave or known attacks, it does little for the first wave, or zero-day attacks – before traditional security controls have analyzed the appropriate signature or behavioral profile of the attacker’s techniques. It is abundantly clear that the current generation of security controls is destined to be behind the eight-ball for the foreseeable future.
By stark contrast, a security control that implements the Positive Security model does not factor in any attacker dependency. Instead, it focuses on the application’s “intent” (as delivered and implemented by the application’s code). To better understand the application “intent”, let’s ponder on the code that a calculator uses to add two numbers. As long as the prescribed addition code is used, the result will be the same; today, tomorrow, and five years from now. On the other hand, if the calculator’s code had an RCE vulnerability and come under attack, a security control that leverages the positive security control would—within a few milliseconds—see that it is not the application’s code but some “foreign” code that processed the user input. The security control would not need to bother analyzing this foreign code to determine if the calculator was under attack or not. The mere fact that the calculator-provided code did not process end-user input would be enough to declare that the calculator had come under attack. In this scenario, a positive security model would interdict and kill the threat within before it had a chance to do any harm—all while allowing the application to work unencumbered and without latency. In the calculator example above, the attacker’s foreign code could do any number of operations, and it would be impossible to predict exactly what that calculator’s code would do.
Further, rich post-mortem telemetry would be provided to existing workflows such as a SIEM or SOAR, allowing the user to see exactly how and where the adversary’s code went awry.
This distinction between security controls that track application intent vs. attacker behavior is very powerful and can deliver millisecond protection from even the first wave of attacks. That is what an unconditional Compensating Control can achieve.
Conclusion
Security controls that implement a Positive Security Model are capable of being the unconditional Compensating Control that can protect our organizations from even first-wave cyber-attacks even if a targeted application has a vulnerability with RCE attributes and has not been patched for whatever reason. Such a Compensating Control does not rely on Threat Feeds, signatures, behavior analytics, AI/ ML, etc. Organizations can reduce the cyber risk that they are exposed to on account of software vulnerabilities because the unconditional Compensating Control effectively reduces the attacker’s dwell time to zero or near zero.
Please visit www.virsec.com to learn more about the Positive Security model and unconditional Compensating Controls.
