Grey bar Blue bar
Share this:

Fri, 14 Dec 2012

Dangers of Custom ASP.NET HttpHandlers

ASP.NET HttpHandlers are interesting components of a .NET web application when performing security assessments, mainly due to the fact they are the most exposed part of the application processing client requests in HttpContext level and at the same time, not yet part of the official ASP.NET framework.

As a result, data validation vulnerabilities in custom HttpHandlers can be exploited far easier than issues on the inner layer components. However, they are mostly overlooked during the web application tests for two reasons:

  1. They are used by a 3rd party component of a target application and often the auditor wants to focus on the main functions of the application

  2. They often are found performing such operations as displaying an icon file or chart from image cache. This is deemed useless during an assessment.

In this post, I'm going to demonstrate a data validation vulnerability in a custom HttpHandler which is used by a number of well known ASP.NET apps such as DotNetNuke CMS and was not fixed by the vendor until 2012/3. We still come across web applications that use this vulnerable component, so thought it useful that we document this vulnerability in the Telerik ASP.NET UI Control, which could allow a remote user to download and remove files from the web server under application's pool permission.

If you are using any of the Telerik components in your application, make sure to replace the "Telerik.Web.UI.dll" with the latest version (about 9MB!).

Vulnerability details:

The Telerik UI control has a web-based charts feature, which stores rendered graphic files in a cache folder for performance reasons. It registers a custom HttpHandler in the web.config file, which processes the following GET request and displays the chart in the client browser:

http://site/ChartImage.axd?useSession=false&imageFormat=image/png&ImageName=[base64 encoded value]

The next step is to decompile the code of the ChartHttpHandler.ProcessRequest(HttpContext), which gives us:

Although, the ImageName query string parameter is encrypted using an AES algorithm to prevent tampering, the encryption key and initialization vector are embedded in the application's assembly (Telerik.Web.UI.dll) and can be used to construct malicious requests to download files from the remote server, as shown in the following figure:

All versions up to and including 2011.2.915.35 are vulnerable. I've created a proof of concept that can be downloaded here . Please note that the target file will be deleted from the web server by the chart image handler after being downloaded from the server, as it considers the requested file as an expired cache entry.

Next time you are on an assessment, don't overlook the mundane and not-so-interesting parts of the application, as they can often provide you with an additional attack surface area.