Earlier on my previous post about Enterprise HTTP Security, I described how HTTP Security is a fine clockwork for an application penetration tester; this post would look into deeper aspect of HTTP Security and how logical manipulation of HTTP could be potentially used by an attacker to manifest the underlying application level vulnerabilities bypassing any security restrictions which were in place originally.

In terms of application development during the standard phases, multi-tier application architecture is prevalent. The multi-tier architecture is a client-server architecture, where the presentation, the application processing and the data management is a complete separate processes. In basic terms, the multi-tier architecture are convenient for developers. The reason they are convenient for developers is the fact that developers have to re-use code and develop applications in which the whole application framework needn’t have to be written all over again. They could only modify parts of the application architecture based on tiers and profit flexibility in the use of such applications. The unfortunate part is the handling of the same data over multiple platform can lead to security breach, or leave the application vulnerable. Logical errors are triggered this way and are completely different from Injection based attacks such as:

LDAP/Blind LDAP Injections

XML Injection

HTML Injection

SQL Injection

ORM based Injection

Spring Injection/nHibernate Injection

Xpath Injection

Command Injection

All of the above mentioned ‘injection’ variants fall into code level application vulnerabilities and is completely different from ‘logical’ vulnerabilities which still have a greater level of impact on the web applications. During my old research at early phases of dissection behavioral pattern of different platform based application on different web-architectures, I found these led to couple of logical based vulnerabilities which could be used by an attacker for benefits. This lead self-curiosity to further research and I came up concluding something which already existed called ‘HTTP Parameter Contamination or HPC’. During my research at Defencely, I found out this particular attack methodology does not only rely on a specific platform but is widely used across many other different web based platforms, such as PHP on Apache, ASP.NET on IIS, etc.

HTTP Parameter Contamination Beneficiaries

Before I prove the absolute necessity for a manual application test, I must say, highlighting the beneficiaries of this particular vulnerability would be very essential to all of the security community in common. But before that, let’s see how applications are deployed in different ways and treated different way when handled or invoked for a ‘useful task’ to be accomplished. I want the readers to already know the primary basics of application deployment which is why I am taking the talk into the next steps which the reader must be already acquainted with. Web Architecture have become more complex and to keep everything simpler for the developers, the developers add layers (RAD Lifecycle) to re-use functions of those layers but this in itself could introduce security vulnerabilities. The image below would illustrate how a general application is deployed for convenience purposes:

In coherence with HTTP Parameter Pollution, which refers to additionally place query strings with the same name manipulating the logic how this newly formed query string is handled by a HTTP Handler of the web-server; there are possibilities HTTP Parameter Contamination attacks which target logical weaknesses of the web-architecture could be harnesses to benefit the attackers. This is where manual penetration testing review is an essential part of any security testing be it an application code review along with web-server logic review or a formal application penetration testing. To really harness the power of HTTP Parameter Contamination, a penetration tester or the attacker must have a deeper know-about of the HTTP and the HTTP Handler they are dealing with. Additionally, an attacker or the web penetration tester must know how HTTP Parameter Pollution attacks could be tested to give security or target an application for their beneficiaries. So what are these beneficiaries?

HTTP Parameter Contamination could be used to circumvent various Filters, security restrictions or regulations to bypass the Web Application Firewalls.

HTTP Parameter Contamination could be used by an attacker to benefit from the in-security a HTTP Handler might just throw such as informational application based web-server errors.

HTTP Parameter Contamination could be used by an attacker in parallel to existing vulnerabilities to bypass security rules and hence exploit these vulnerabilities.

For an example let a particular back-end ASP code be and assume mod_security as an application firewall is installed:

It is possible to bypass the security restrictions which are provided by mod_security and hence accomplish path traversal attacks which were originally never possible. This (Path Traversal) in contrast with HTTP Parameter Contamination made such resilient attacks possible and hence actually manipulated the query somehow in order to accomplish the bypass using how HTTP traffic were handled by the HTTP Handler. This similarly could be used along with MS-SQL Injection wherein an IIS server using MS-SQL Databases could lead to critical compromise and hence cause a severe damage.

Example:

The pattern here to bypass the MS-SQL Injection which had previous security restrictions used HPC or HTTP Parameter Contamination. This could be as well be targeted towards PHP Interpreters.

An example back-end PHP code:

And Perl is no longer bulletproof:

The Perl code along with HTTP Parameter Contamination applied gave these results:

Now, that I had proved my point across different application behaving in a different way using HTTP Parameter Contamination payloads, the take-away is to not use developer’s production time to keep them consuming development and rather actually focus on manual penetration test services to mitigate deeper issues which I had dealt with previous in large scale enterprise applications.

About the Author

Shritam Bhowmick is an application penetration tester professionally equipped with traditional as well as professional application penetration test experience adding value to Defencely Inc. Red Team and currently holds Technical Expertise at application threat reporting and coordination for Defencely Inc.’s global clients. At his belt of accomplishments, he has experience in identifying critical application vulnerabilities and add value to Defencely Inc. with his research work. The R&D sector towards application security is growing green at Defencely and is taken care by him. Professionally, he have had experiences with several other companies working on critical application penetration test engagement, leading the Red Team and also holds experience training curious students at his leisure time. The application security guy!

Shritam Bhowmick has been delivering numerous research papers which are mostly application security centric and loves to go beyond in the details. This approach has taken him into innovating stuff rather than re-inventing the wheel for others to harness old security concepts. In his spare time, which is barely a little; he blogs, brain-storms on web security concepts and prefers to stay away from the normal living. Apart from his professional living, he finds bliss in reading books, playing chess, philanthropy, and basket-ball for the sweat. He wildly loves watching horror movies for the thrill.