CVE-2015-4670: Directory Traversal to Remote Code Execution in AjaxControlToolkit

Posted by Brian Cardinale in Application Security, Research | 0 comments

The AjaxControlToolkit prior to version 15.1 has a file upload directory traversal vulnerability which on a poorly configured web server can lead to remote code execution. This vulnerability has been issued CVE-2015-4670. It is recommended to update to the latest version of AjaxControlToolkit to resolve this issue. It is also recommended to review the file permissions granted to the web server user account to restrict the file locations the web application is allowed to write to. The flaw was introduced in version 7.429 which was released on April 30, 2013. The latest vulnerable version is 7.1213. The latest general available version is 15.2 as of the time of this writing. The vulnerable versions of the AjaxControlToolkit have a total download count of 375,973 on nuget.org as of the time of this writing.

The issue affects any application using the AjaxFileUpload control. The control generates a GUID called “fileId” which it uses to generate a temporary path for the uploaded file. The vulnerability arises because the “fileId” is not validated and can be altered by the user to contain directory traversal characters (\..\..\..\) allowing an attacker to write the uploaded file to any location on the file system that the web server’s file permissions allow. Writing an “.aspx” file to the web servers web directory can lead to remote code execution as demonstrated below.

A vulnerable demonstration app can be found here. The application is a default Asp.Net application with the AjaxControlToolkit library added and the AjaxFileUpload user control added to the default.aspx page. There is no custom code added to handle the file upload. This demonstrates that the vulnerability happens before the developer has a chance to protect against it.

You will need to be able to modify the ajax request sent from the browser to exploit this flaw. A simple way of doing this is to use an intercepting proxy, such as Portswigger’s Burp Suite. Configure your browser to proxy all traffic through the proxy and ensure that you can intercept requests.

In this demonstration we are going to attempt to make the remote web server connect to our attacker box. We will do this by uploading Netcat (nc.exe) and a customized .aspx file named nc.aspx that will be used to launch nc.exe. If you are unfamiliar with netcat you can read about it here. The Metasploit Framework is also capable of creating a crafted .aspx file to facilitate a reverse shell connection.

Attempt to upload nc.exe with intercept turned on. The first request can be ignored and forwarded along. The second request will need to be modified. There is a trivial file extension filter that can be enforced on the AjaxFileUpload control. This can be bypassed by changing the file name prior to uploading and then modifying the extension in the intercepted request. The file extension filter is not enforced on the server.

The “fileId” parameter is the parameter than need to be modified to exploit the flaw. We will inject a number of directory traversal characters (..\..\..\) at the end of the “fileId” parameter and then the path we want to write to. In this case, we want to write to the web directory. The web directory location will depend on the installation. This deployment has not modified it from the default so it is located at “\inetpub\wwwroot”. So our injection will look like:

/../../../../../../../../../../../../../../../../inetpub/wwwroot/

We will perform the same steps to upload nc.aspx. You should reload the page to upload the second file as our modifications will leave the page in an unknown state. The reason we are uploading nc.aspx is because we cannot force the web server to launch nc.exe directly so we need to do it via code that the application server understands. IIS will compile and run any .aspx file placed in the web directory. The file we are uploading has C# code embedded in it that will be compiled at runtime and run.

The uploaded nc.aspx will start a new process that will run nc.exe which will connect to the IP address and port specified in the request to nc.aspx. Once it connects it will pipe cmd.exe over the connection given the remote machine a interactive shell on the remote system.

We need to setup a listener on our attacker box to listen for the incoming connection.

We are ready to cross our fingers and attempt to exploit the remote web server. They way we do this is by passing the IP address and port to the nc.aspx waiting for us in the remote web directory.

Tremendous Success!

This issue was reported to DevExpress, who are now maintaining the AjaxControlToolkit, and they were prompt to resolve the issue.

Affected Versions:

• 7.1213.0
• 7.1005.0
• 7.1002.0
• 7.930.0
• 7.725.0
• 7.607.0
• 7.429.0

Sample Vulnerable Application:

• https://bitbucket.org/bcardinale/cve-2015-4670-vuln-app/src