CVE-2019-18935 vulnerability caused our systems to get infected

[Roelande]

Hi,

2 Of our production webservers got infected last week with Bitcoin miner software and after thorough research, it appears that the Telerik Web UI CVE-2019-18935 vulnerability was used to initiate the attack. More information regarding this attack can be found here: https://www.baco.sk/posts/xmrig-blue-mockingbird/

At the moment, all of our systems are at risk as we've got hundreds of websites running on multiple servers which use the Telerik control, varying from as old as version 2013.3.1114, till the more recent versions, such as 2019.3.1023.

As a (panic) reaction to mitigate this problem, we've replaced the existing Telerik.Web.UI.dll files on the affected server with the 'patched' version downloaded on the product download patch: https://www.telerik.com/account/product-download?product=RCAJAX 

However, after more research, I read on https://www.telerik.com/support/kb/aspnet-ajax/details/allows-javascriptserializer-deserialization that the only way to fix this problem is to upgrade to version R3 2019 SP1 or later. Can you tell me what the patched version is for then? What does it patch?

Also, can you please advise on how we can fix this problem with the least amount of effort, as we literally have hundreds of websites using this DLL. Is there a way that we do not have to upgrade to the latest version and can have it fixed by an IIS setting perhaps? We basically only use the Telerik Editor.

Thank you.

 

 

 

 

 

[Roelande]

A quick addition, the Telerik editor is only used on back-end screens by users who have authenticated themselves. Is there a way to block the vulnerable files for public users, and leave it open for authenticated users? That would give us more time to fix all websites properly.

[Rumen]

Hi Roeland,

I am really sorry to hear that your servers are infected and will do my best to help you.

As you have seen in the dedicated KB article, there are two prerequisites for the CVE-2019-18935 to happen:

The first and most important one is for an attacker to be able to break the RadAsyncUpload encryption and stage a malicious request. This is possible for the version prior R2 2017 SP1 (2017.2.621) regardless of whether the AsyncUpload is available on the page/app or not - of course the app should be publicly accessible. While the available patches which we released in 2017 may be helpful to prevent the vulnerabilities discussed in Unrestricted File Upload and Cryptographic Weakness, they are not so secure as the versions released afterward.

The available options to cover completely the crypto issue and make your apps/servers more secure are:

• Upgrade at least to R2 2017 SP2 and disable the AsyncUpload handler - DisableAsyncUploadHandler. This way this will disable the possibility to upload any files via RadAsyncUpload.
• [recommended] Upgrade to R1 2020 (2020.1.114) and later since they offer the AllowedCustomMetaDataTypes feature which prevents the second prerequisite for the CVE-2019-18935 vulnerability - The type whitelisting feature of RadAsyncUpload is not enabled.

Please allow me to answer your additional questions:
The KB did feature info on avoiding the issue through general web.config networking settings but we removed it because it appeared not enough sufficiently safe. Just to get an idea what it was, I am pasting it below but not recommend it. So here is the removed part of the KB:

Prevent POST requests to the handler used by RadAsyncUpload

Versions starting from R2 2017 SP2 and the provided patches allow you to set an appSettings key to disable file uploads. If you cannot upgrade or apply a patch, an alternative is to disable the POST requests that upload the file to the built-in Telerik handler from your web.config. Here are two suggestions on how to achieve this:

• Use a URL redirect rule similar to the one below. You can modify it to return errors or other content. This example redirects to a page. Note that this will also prevent file uploads via RadCloudUpload.

  <rewrite>
      <rules>
          <rule name="DisableAsyncUpload" enabled="true" stopProcessing="true">
              <match url="^Telerik.Web.UI.WebResource.axd" />
              <conditions>
                  <add input="{QUERY_STRING}" pattern="type=rau" />
              </conditions>
              <action type="Redirect" url="not-allowed.aspx" redirectType="Permanent" />
          </rule>
      </rules>
  </rewrite>

• Change the Telerik.Web.UI.WebResource handler registration so IIS does not allow POST requests to it. Added ways to disable file uploads without a patch. Note that this will also prevent file uploads via RadCloudUpload and can disrupt some functionality in RadImageEditor.

  <system.web>
    <httpHandlers>
      <add path="Telerik.Web.UI.WebResource.axd" type="Telerik.Web.UI.WebResource" verb="GET" validate="false" />
    </httpHandlers>
  </system.web>
  <system.webServer>
    <handlers>
      <remove name="Telerik_Web_UI_WebResource_axd" />
      <add name="Telerik_Web_UI_WebResource_axd" path="Telerik.Web.UI.WebResource.axd" type="Telerik.Web.UI.WebResource" verb="GET" preCondition="integratedMode" />
    </handlers>
  </system.webServer>

  


Since there isn't built-in authentication which comes with the asyncupload handler- if the hacker predicts the path to the handler, he will be able to read the encrypted params and decrypt them-of course if the app is using an old and non-patched version of Telerik.Web.UI. If the app is not public-facing or if a secure version of Telerik.Web.UI.dll is used then the app will be secured and the hacker won't be able to access or decrypt the handler.

You can also find upgrade instruction here.

Please let me know if you have any other questions!

Regards,
Rumen
Progress Telerik

[Terence]

Hi Rumen

Could you please re-explain why the solution with the rewrite rule is not safe to avoid CVE-2019-18935. For instance:

<rewrite>
    <rules>
        <rule name="DisableAsyncUpload" enabled="true" stopProcessing="true">
            <match url="^Telerik.Web.UI.WebResource.axd" />
            <conditions>
                <add input="{QUERY_STRING}" pattern="type=rau" />
            </conditions>
            <action type="Redirect" url="not-allowed.aspx" redirectType="Permanent" />
        </rule>
    </rules>
</rewrite>

I am no security specialist and I would appreciate if you could reword the reason you gave ("Since there isn't built-in authentication which comes with the asyncupload hand [...]")

Many thanks!

[Rumen]

Hi Roeland,

The ^Telerik.Web.UI.WebResource.axd rewrite rule simply does not match all possible combinations on the path to the handler. 

Another problem is the case sensitivity of the pattern which may prevent it to catch many of the combinations.

Best Regards,
Rumen
Progress Telerik

[Bob]

Hello,

I wanted to check if these 2 vulnerability patches:
CVE-2019-18935 - Allows JavaScriptSerializer Deserialization
CVE-2017-11317 - Unrestricted File Upload

are compatible with the current version of Telerik we use:
Telerik UI for ASP.NET AJAX Q1 2015 SP1               2015.1.401

Thank you
Bob

[Rumen]

Hi Bob,

Q1 2015 SP1 (version 2015.1.401) of Telerik UI for ASP.NET AJAX (Telerik.Web.UI.dll) is vulnerable to both vulnerabilities:

CVE-2019-18935 - Allows JavaScriptSerializer Deserialization
CVE-2017-11317 - Unrestricted File Upload

We recommend an upgrade to at least R1 2020 (2020.1.114) as explained in the Allows JavaScriptSerializer Deserialization article and the Blue Mockingbird Vulnerability Picks up Steam—Telerik Guidance blog post.

Best Regards,
Rumen
Progress Telerik

[Bob]

Thank you Rumen for the quick response and the linked information. I wanted double check with you if there was any possibility the patches could work on our version in the interim, until we make the upgrade to the version you recommended? Or a patch that could work for us on a request basis? Thank you again.

 

T

[Rumen]

Hi T,

It is technically not possible to provide patches that will guarantee prevention for the CVE-2019-18935 vulnerability. 

That's why we have offered a complimentary upgrade for R1 2020 (2020.1.114) to everyone no matter what license they are on at the moment - just to be sure that everyone is on an up-to-date version which is not only secure but also offers support for the latest browsers, stability improvements, and fixes.

 

Best Regards,
Rumen
Progress Telerik