Could this be a web.config hack?

[Fit2Page]

Hi,

 

Yesterday I discovered in the web.config on one of our webs the following:

 

<add name="Telerik_Web_UI_DialogHandler_aspx" path="me.hochalla.aspx" type="Telerik.Web.UI.DialogHandler" verb="*" preCondition="integratedMode" />

 

normally this is:

 

<add name="Telerik_Web_UI_DialogHandler_aspx" path="Telerik.Web.UI.DialogHandler.aspx" type="Telerik.Web.UI.DialogHandler" verb="*" preCondition="integratedMode" />

 

What do you think this is?

Strangest thing is I removed the line yesterday but now it is in again.

Please respond soonest.

Marc

[Rumen]

Hi Marc,

Yes, this might be a security issue, especially if me.hochalla.aspx handler/page is not among the known files of your web application.

You may also search for me.hochalla.aspx in the app files and if it exists to examine its code which might give you any clues.

My advice is to upgrade your project to the latest version 2020.1.219 of Telerik.Web.UI.dll  and to apply the recommended security keys. If they are already applied, create new ones since the original keys might be stolen from the compromised web.config file.

The latest version provides fixes for the following vulnerabilities:

• Allows JavaScriptSerializer Deserialization
• Unrestricted File Upload
  
• Cryptographic Weakness
• Insecure Direct Object Reference

You can find more information on how to secure your app in these articles:

• RadAsyncUpload Security article
• RadEditor Security article

Regards,
Rumen
Progress Telerik

[Chad]

Are there any other measures that need to be taken to secure the Telerik.Web.UI.DialogHandler.aspx?

Our IIS logs have thousands of hits to variations of the following path.

/common/admin/Jobs2/Telerik.Web.UI.DialogHandler.aspx

When I go to that path I get a message saying "Loading the dialog..."

Should I be concerned with this?

 

[Rumen]

Hi Chad,

It looks like somebody is trying to exploit your app via one of the known vulnerabilities in the suite - CVE-2017-9248.

That's why it is a must to secure your web apps with the most secure versions of Telerik.Web.UI.dll released after R3 2019 SP1 or even better the latest one R3 2020 SP1 to protect from all known vulnerabilities in the suite. Please see the following video which shows how to generate the recommended security keys for the web.config appSettings for the Telerik controls - https://www.youtube.com/watch?v=J18zDKtiBFE. 

Please also read these online resources:

• https://docs.telerik.com/devtools/aspnet-ajax/general-information/web-config-settings-overview#mandatory-additions-to-the-webconfig
• https://docs.telerik.com/devtools/aspnet-ajax/controls/editor/functionality/dialogs/security 
• https://www.telerik.com/blogs/first-5-tips-for-building-secure-web-apps 

The vulnerability related to the Telerik.Web.UI.DialogHandler.aspx is discussed in the following article: https://www.telerik.com/support/kb/aspnet-ajax/details/cryptographic-weakness. If your app is using an older version where the vulnerability is not fixed, please directly upgrade to the latest version R3 2020 SP1 (2020.3.1021) since this will ensure that the hackers won't be able to decrypt the handler information and exploit your site. 

By the way, in version 2020.2.512, we updated the error message of the handler - https://feedback.telerik.com/aspnet-ajax/1463808-security-improvement-in-handling-telerik-web-ui-dialoghandler-errors which is yet another reason for an upgrade. Security is a top priority and we are constantly enhancing the security of the suite.

Best Regards,
Rumen
Progress Telerik

[Chad]

Thank you. We upgraded the controls and applied the recommended settings.

I would like to secure it further. In our application we only have a need for the Telerik.Web.UI.DialogHandler.aspx page to be accessible behind login. Is there a way to lock down the dialog handler so only logged in users have access? 

[Rumen]

You are welcome, Chad. It is perfect that you have updated the Telerik.Web.UI.dll version and applied the security settings!

The Telerik.Web.UI.DialogHandler.aspx does not offer built-in authentication. 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.

Regards,
Rumen
Progress Telerik

[Stanislav]

Hi Rumen,

after changing the keys, I cannot log on to the site!!! The password was created using the previous key! Besides restoring the previous web.config there are no other ways?

 

[Stanislav]

It turns out that it is necessary to transfer the previous <machineKey validationKey....../>  from the old web.config to the new one and then the keys are decrypted correctly!

[Rumen]

Hi Stanislav,

Thank you for following up and sharing this know-how with the community!

Best Regards,
Rumen
Progress Telerik

[Stanislav]

Hi, Rumen,

I write through a translator.
I have a website on DotNetNuke Community Edition 05.06.02 (144). Yeah, I know he's very old:) How do I upgrade telerik editor to a new version? The one that is standing now was silent with the distribution. I do not want to update DotNetNuke due to the availability of modules for the current version. Can you help me step-by-step? what to download-where to put and how to register. Thank you!

 

[Rumen]

Hi Stanislav,

The recommended approach is to contact the DNN support or ask their community in the DNN forums since we do not provide support for the third-party DotNetNuke CMS system.

As far as I know, after updating the Telerik.Web.UI.dll assembly in DNN, you have to set a bindingRedirect in the web.config to prevent problems with the assembly version and the reference to the old one.

<configuration>
    <runtime>
        <dependentAssembly>
            <assemblyIdentity name="Telerik.Web.UI" publicKeyToken="121fae78165ba3d4" />
            <bindingRedirect oldVersion="1.0.0.0-2021.1.330.45" newVersion="2020.1.330.45" />
        </dependentAssembly>
    </runtime>
</configuration>

Best Regards,
Rumen
Progress Telerik

[Stanislav]

Hi, Rumen

OK. I realized by attending the DNN forum that there would be no support. Then the question is: is there a query string sent to the site that uniquely indicates an attempted hack? May I lock this line in file2ban or nginx filters?

[Rumen]

Hi Stanislav,

The query string data is encoded so I am not aware of a specific string that shows that it is a hack or not. You may want to check the information about the vulnerability to get a better overview of how it is happening:

You can find technical information on the CVE-2019-18935 vulnerability in the following resources: 

• https://github.com/bao7uo/RAU_crypto  
• https://codewhitesec.blogspot.com/2019/02/telerik-revisited.html  
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18935 

 

What the 2020.1.114 and later versions do is to provide a strong encryption mechanism that cannot be broken by the hackers as well as the type whitelisting feature, which is strong prevention of CVE-2019-18935.

There are alternative approaches but they are not safe and they cannot guarantee full protection as upgrading to version 2020.1.114 or later  - these alternative approaches are provided in my answer here -> see the two bullets for "Use a URL redirect rule similar to the one below" and "Change the Telerik.Web.UI.WebResource handler registration so IIS does not allow POST requests to it".

Regards,

Rumen
Progress Telerik