Australian Cyber Attack Vectors Blocked Out of the Box by Imperva WAF

On June 18, 2020, the Australian Cyber Security Centre (ACSC) released a disclosure detailing a ‘sophisticated’ and sustained attack against Australian government bodies and companies. The disclosure was covered by several mainstream media outlets including the BBC, and the Guardian.

The following day, the Australian prime minister made a statement about the attacks in which, although he declined to attribute the attacks to a specific threat actor, he suggested that it was ‘state based’. According to the BBC the prime minister also stressed that the attacks were not limited only to Australia, but affected targets worldwide.

Several exploits and indicators of compromise were outlined in the ACSC’s disclosure, including initial access vectors, execution techniques, malware, and persistence techniques. These were all evaluated by our analysts to ensure that, where possible, the Imperva Cloud WAF could mitigate attempts to utilise such vectors. Naturally, some of these items fall outside of the scope of what a WAF is expected to mitigate, such as spear phishing attacks. However, in many instances, the wide-ranging capabilities of Imperva Cloud WAF allows for effective mitigation of the exploits and techniques leveraged in the campaign. In this blog post, we’ll explore some of these exploits and techniques and how Imperva Cloud WAF can mitigate against them.

The Access Vectors

The ACSC identified several initial access vectors during the campaign, all of which are detailed here. Let’s take a brief look at a few of these vectors, and the mitigation provided by the Imperva Cloud WAF.

Telerik UI CVE-2019-18935

CVE-2019-18935 is a vulnerability discovered in 2019 by researchers at Bishop Fox, in the RadAsyncUpload file handler in Telerik UI for ASP.net AJAX, a commonly-used suite of web application UI components. The vulnerability is brought about by the insecure deserialization of JSON objects, which can lead to remote code execution on the host.

In order to successfully exploit the insecure deserialization vulnerability identified in CVE-2019-18935, the attacker must also exploit a pre-existing file upload vulnerability, CVE-2017-11317, which identifies the use of a default encryption key to encrypt the data in file upload requests. With this knowledge, an attacker can use the key to modify the “TempTargetFolder” variable in the upload request, essentially allowing file uploads to anywhere in the file system the web server has write permissions to.

The more recent vulnerability, CVE-2019-18935, details the anatomy of the upload request from RadAsyncUpload, in which the rauPostData parameter contains both a serialized configuration object, and the object’s type.

Shown below is the HTTP POST request containing the encrypted rauPostData parameter. The part of the parameter before the “&”, highlighted in blue is the serialized configuration object, and the part after, highlighted in yellow is the object’s defined type.

When decrypted the configuration object resembles the following:

{
   "TargetFolder":"jgas0meSrU/uP/TPzrhDTw==Au0LOaX6ddHOqJL5T8IwoKpc0rwIVPUB/dtjhNpis+s=",
   "TempTargetFolder":"5wWbvXpnoGw9mTa6QfX46Myim0SoKqJw/9EHc5hWUV4=fkWs4vRRUA8PKwu+jP0J2GwFcymt637TiHk3kmHvRM4=",
   "MaxFileSize":0,
   "TimeToLive":{
      "Ticks":1440000000000,
      "Days":0,
      "Hours":40,
      "Minutes":0,
      "Seconds":0,
      "Milliseconds":0,
      "TotalDays":1.6666666666666665,
      "TotalHours":40,
      "TotalMinutes":2400,
      "TotalSeconds":144000,
      "TotalMilliseconds":144000000
   },
   "UseApplicationPoolImpersonation":false
}

And the type resembles:


Telerik.Web.UI.AsyncUploadConfiguration, Telerik.Web.UI, Version=2017.1.228, Culture=neutral, PublicKeyToken=121fae78165ba3d4


It was discovered that, if the attacker could modify the specified type to be a gadget – a class inside the scope of execution of the application – in a subsequent request, they could achieve remote code execution on the server.

Analysts at Imperva were able to take the proof of concept code provided, and reproduce the requests made. From here they were able to create cloud WAF rules to distinguish between legitimate traffic from the RadAsyncUpload file handler, and the malicious requests from the PoC code.

Statistics and observations:

Throughout June, we observed the attack pattern matching that of an exploit of CVE-2019-18935 on 645 occasions. The following chart shows the top targeted countries during that period.

Exploitation of Citrix Products CVE-2019-19781

The vulnerability in Citrix products CVE-2019-19781 was disclosed in a bulletin released by Citrix back in December 2019. Although no proof of concept or exploit was released at the time, it was said to potentially result in remote code execution and was presumed to take advantage of a directory traversal flaw in the application. We’ve already released a blog post covering our mitigation of this vulnerability here.

Statistics and observations:

During the month of June we’ve seen the rule put in place for this vulnerability by Imperva Cloud WAF triggered 155,050 times. The following chart shows the top targeted countries during that period.

Persistence Techniques

The ACSC identified several different persistence techniques used during the campaign. Among these were several webshells which allowed the attacker to interact with the compromised systems after achieving initial access.

A webshell is a script or piece of code which runs on a web server and allows for administrative actions to be performed remotely. Often these serve legitimate purposes, although uploading of webshells is common practice for attackers seeking to maintain persistence after initially compromising a server. These webshells are commonly referred to as backdoors.

Imperva’s backdoor protection

Backdoor protection, which forms a part of the Imperva Cloud WAF, is capable of both detection and mitigation of webshells uploaded to compromised servers to act as backdoors. When certain conditions are met, the Cloud WAF proxies inspect the response from the server, from which they can identify known webshells, and block the subsequent requests thereafter.

You can read more about Imperva’s backdoor protection here

Webshells observed in the campaign

In its disclosure, the ACSC provided a list of webshells observed during the attack campaign. In each instance, the source code for the webshell was provided, XOR’d, and base64 encoded to prevent ‘accidental mishandling’ of the code. We’ll look briefly at two of these webshells and outline how Imperva’s Backdoor Protection effectively mitigates them. Shown below is the Awen webshell source code in its encoded form.

Awen asp.net webshell

This is a simple, open source asp.net webshell outlined by the ACSC in its disclosure. It creates a simple HTML form which receives a string as input, and provides it as an argument to cmdexe. Shown below is the Awen webshell running in our sandbox environment, after executing the “systeminfo” command.

Analysts at Imperva were then able to decode the source code of both the webshells discussed, execute that code on a sandbox environment, and gather enough info to craft signatures to detect the webshells in the wild. Although neither of these webshells have been observed in the wild by Imperva at this time, we will be monitoring the traffic detected by these signatures closely in the coming weeks.

From even a brief look at the details provided about the recent Australian Cyber attack, a lot can be learned about the techniques used by threat actors, and many conclusions can be drawn. Among the most significant is that even advanced “state based” actors will make use of readily available exploits and attack code. Although the mitigation recommendations from the ACSC are well advised, the use of a well configured WAF can serve as an extra layer of protection. This is where the deployment of the Imperva WAF could make all the difference to your business.