Last updated 22 May 2020
The Australian Cyber Security Centre (ACSC) has become aware that sophisticated actors have been scanning for and attempting exploitation against unpatched versions of Telerik UI for ASP.NET AJAX using publicly-available exploits. Successful exploitation could allow an attacker to execute arbitrary code on the vulnerable server.
This advisory is focused around the targeting of CVE-2019-18935 but has significant overlap to the previously released ACSC 2019-126 advisory.
Details
Telerik offers a variety of products which are used to provide functionality used by web pages. In some cases, Telerik products may be installed as a third party component included by web applications, and as such, may be unknowingly in use.
In November 2019, a security vulnerability was published that affects some Telerik products which could allow a malicious cyber actor to gain control over a server. Details of this vulnerability are outlined in the following resources:
A prerequisite for exploitation of this vulnerability is a malicious actor having knowledge of the Telerik RadAsyncUpload encryption keys. This can be achieved through either prior knowledge or exploitation of vulnerabilities present in older, unpatched versions of Telerik released between 2007 and 2017.
For further information on these older vulnerabilities, associated malicious activity and recommended mitigations, please see ACSC Advisory 2019-126: Vulnerable version of Telerik UI being actively exploited by APT actor.
Exploit code and tools to target this vulnerability have been publicly published and require only basic knowledge or skills to use successfully. Any servers currently running a vulnerable version should be considered at risk and remediation steps should be taken.
Recommendations
The ACSC recommends organisations consider the following actions:
Identify and patch vulnerable web servers
Identification
- The most reliable way that organisations can identify the existence of Telerik installations is by identifying Telerik DLLs within web application root directories. As the exploitable functions within the Telerik library are located within a single DLL file,
Telerik.Web.UI.dll, organisations can identify this file to determine Telerik usage as well as determine the product version. Identification can be performed though software asset management or host-based inspection software. A sample PowerShell script has been provided in Appendix A – Sample PowerShell script for the detection of vulnerable DLLs to assist with identification efforts. - The use of Telerik can also be identified through the inspection of Internet Information Service (IIS) web server logs and or other web application logs for known Telerik resources. The following resource is requested when using the public exploitation technique making them good candidates to search for:
Telerik.Web.UI.WebResource.axd - Network vulnerability scanners may be able to assist with the identification of Telerik within an organisation, however this is probably the least reliable method of detection. If scanning for this vulnerability, please be aware that some security products such as Intrusion Prevention Systems may detect the attack and block it, leading to a false negative.
Mitigate vulnerabilities
Once Telerik has been identified organisations should follow the vendor security advisory to identify whether they are vulnerable and apply the recommended mitigations. The vendor security advisory is available at the Telerik product site.
Investigate for evidence of exploitation
Organisations currently using or having used versions of Telerik vulnerable to CVE-2019-18935 or the older 2017 CVEs should look for signs of compromise in any environment that the Telerik product was running in.
Review web server request logs
Exploitation attempts involve requests to the vulnerable resource. For CVE-2019-18935 these take the form of HTTP POST requests to Telerik.Web.UI.WebResource.axd?type=rau. Malicious exploitation requests will result in a HTTP 500 Internal Server Error which web server logs can be reviewed for. An example is included below:
POST /Telerik.Web.UI.WebResource.axd type=rau 443 – 192.0.2.1 - - 500 0 0 457
Organisations should analyse Microsoft IIS web request logs, load balancer logs or other web application logs for suspicious requests.
These POST requests may be larger in size than legitimate requests due to the malicious actor uploading malicious files for the purposes of uploading a reverse shell binary. Upon log review it may be identified that requests to Telerik.Web.UI.WebResource.axd?type=rau are not an expected pattern of standard, legitimate web site use and that any requests to the above resource is worth investigating further.
Review Windows event logs
The ACSC has identified that upon successful exploitation a log entry will be created within the Application.evtx Windows event log. This log entry will have the following characteristics:
- Event ID: 1309
- Source: ASP.NET <version_number>
- Message: Contains the following strings in addition to other error message content:
An unhandled exception has occurred.
Unable to cast object of type ‘System.Configuration.Install.AssemblyInstaller’ to type ‘Telerik.Web.UI.IAsyncUploadConfiguration
Organisations should review the application event logs on vulnerable or previously vulnerable hosts for indications of Telerik exploitation. This analysis can be combined looking for associated HTTP 500 responses as identified above.
Implement complementary security controls and/or transfer risk
The ACSC strongly recommends the implementation of the ASD Essential 8 Mitigations to mitigate threats to internet-facing systems. Specifically for this vulnerability, maintaining a regular patch process and validating the application of patches reduces the risk of exploitation and is an essential part of a mature cyber program.
To limit the extent of cyber security incidents related to compromise of web servers, organisations should segment and segregate internet-facing servers whenever possible. Methods of network segmentation for a web server may include:
- move the web server to an appropriate network segment (e.g. a DMZ) for the environment
- move the web application to an externally-hosted server (e.g. within a cloud-hosted environment).
The following controls should be applied to externally-facing servers, whether DMZ or cloud-based, to limit trust and data movement into the internal network. These controls will include:
- Apply host segregation by only allowing specified communications between servers where required and over specific protocols. Additional considerations and limitations should be applied to communications between the server and network internal segments.
- Internal authentication credentials should be protected from externally-facing servers. Do not use or store internal segment credentials on externally-facing servers.
- An additional protection for web servers is the removal of impersonate privileges from service accounts that do not require this privilege. Please note: This will need testing as some service accounts may require this privilege.
Additionally, logging on externally-facing servers (both operating system and application logs) should capture the appropriate events to enable a security team to effectively monitor for compromise. The logs should be centralised and continuously monitored for signs of anomalous activity.
Other relevant detection and mitigation measures
The ACSC recommends that organisations review and implement the following additional guidance:
Incident reporting
If you have questions about this advice or have indications that your environment has been compromised, contact the ACSC via 1300 CYBER1 (1300 292 371) or https://www.cyber.gov.au/acsc/contact.