2019-126: Recommendations for mitigation of vulnerable version of Telerik UI

The ACSC recommends organisations consider the following actions:

Identify and patch vulnerable web servers

Identification

1. The most reliable way that agencies 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, agencies can identify this file to determine Telerik usage as well as determine the product version. Identification can be performed though software asset management software 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.
2. The use of Telerik can also be performed through the inspection of Internet Information Service (IIS) web server logs and or other web application logs for known Telerik resources. The following resources are the resources requested when using the public exploitation technique making them good candidates to search for:
   • Telerik.Web.UI.DialogHandler.aspx
   • Telerik.Web.UI.WebResource.axd
3. An alternative to inspecting application logs is to implement network detection rules within network security products. A sample ruleset has been provided in Appendix B – Sample network detection rules. If Telerik is identified through log or network detection methods it is advised that agencies perform further analysis on the version of Telerik being requested to confirm if it is a vulnerable version.
4. Network vulnerability scanners may be able to assist with the identification of Telerik within an agency, 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.
5. Once Telerik installations are identified, agencies should consult the vendor’s documentation to determine if they are at risk.

Mitigate Vulnerabilities

Once Telerik tools have been identified agencies should follow the vendor procedures to ensure that the risk is mitigated within the environment. Links to the vendor documentation are available in the References of this report.

Investigate for evidence of exploitation

Agencies currently using or having used vulnerable versions of Telerik should look for signs of a compromise in any environment that the Telerik product was running in.

Observed exploitation attempts have involved multiple HTTP GET and POST requests to the vulnerable resource. Looking for suspicious or patterned requests to the following resources within IIS and Application logs may reveal an attempt to exploit the vulnerability:

• Telerik.Web.UI.WebResource.axd?type=rau
• Telerik.Web.UI.DialogHandler.aspx

If multiple simultaneous requests are observed then agencies should search for the existence and/or execution of other files that may have been uploaded using this technique.

Network security products can assist in the ongoing detection of exploitation attempts. A sample ruleset has been provided in Appendix B – Sample network detection rules.

Implement complimentary 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 agencies 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.

Incident Reporting

If you have questions about this advice or have indications that your environment has been compromised, contact the ACSC or calling 1300 CYBER1 (1300 292 371).

References

1. Relevant ACSC advisories
   1. Securing content management systems
   2. Web shells - Threat awareness and guidance
2. Telerik vulnerability advisories:
   1. Telerik - Cryptographic weakness
   2. Telerik - Insecure direct object reference
   3. Telerik - Unrestricted file upload