HTTP verb tampering is a serious threat, oft-ignored

Application Security Threat Research Series – Part 2: HTTP Verb Tampering

Aleph-Tav-Technologies_ApSec_Vulnerabilities_HTTPVerbTampering3

Anybody with a flourishing business goes paranoid every now and then that a begrudging party might unleash an attack with the motive of bringing down the reputation of their brand. While it isn’t always easy to stop meddlers, many companies fail to pay attention to minor details that can actually help save face by deflecting attempts at cyber defamation and other attacks. One such simple, albeit vital area of focus is how web applications use the HTTP verbs.

HTTP allows a set of actions apart from the most widely known GET and POST. These methods of indicating one’s intended action for the target resource are commonly used in the instances of authentication and access control on many web applications. Some of these functions allow an attacker to alter or destroy web server files and resources.

For every 10 applications we test, at least 7 on an average have unnecessary and potentially risky HTTP methods enabled in their release build. We observe a lack of awareness about the numerous possibilities of exploiting them. For instance, the OPTIONS method serves as enough foothold for an attacker to enumerate the list of all allowed HTTP request functions. From there, the attack surface looms into view. Say an application has the TRACE (or TRACK) method enabled. Exploiting it will give him the opportunity to read the HTTP headers which are otherwise invisible to JavaScript.

Aleph-Tav-Technologies_AppSec_Vulnerabilities_HTTPVerbTampering4

By leveraging this, an attacker may bypass authentication and authorization in web applications. This is because the TRACE function makes the web server echo user inputs in the HTTP response header making it easy to steal a victim user’s personal information such as cookies and credentials. If the attacker can intercept the response, the purpose of a login gateway/access control could be defeated. 

After using custom script checks to do a bit of probing in a web-based enterprise IAM application, it was found that the PUT and DELETE methods were enabled on the host. The target server was evidently riddled with the issue of unrestricted file write (not upload). The situation presented ample opportunity to mount attacks. Using the freeway, we were able to write a .exe file containing an ASP shell script to the target server. Using the HTTP PUT method, the rand.exe file was uploaded (PUT/rand.exe). The PUT request fetches the HTTP status code 201 CREATED, indicating that the request was successful.

An exploit such as this can induce a range of adverse impacts limited only by the skill of the attacker. For instance, once he gets a shell access, he could tap one of those notorious privilege escalation flaws and proceed to command the system to shut itself down or even make a bot out of it.

As a manifest demonstration of the possibilities of writing, deleting and performing other actions on files on the victim server, we used the PUT method to upload a simple HTML file with content intended to deface the target webpage.

Aleph-Tav-Technologies_AppSec_Vulnerabilities_HTTPVerbTampering1

Aleph-Tav-Technologies_AppSec_Vulnerabilities_HTTPVerbTampering2

The common mitigation for this issue is to disable all HTTP functionality other than POST and GET. But if particular requirement entails the use of non-standard methods, be sure to thoroughly appraise the application with a penetration test carried out from the perspective of how these methods could be employed in accessing data or actions without proper authorization. It is best to restrict these methods to pages that do not involve user actions.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

* Please enter the Characters - [Case Sensitive]