http parameter pollution (hpp) - seacure.it edition
DESCRIPTION
HTTP Parameter Pollution (HPP) - SEaCURE.it presentation by Luca Carettoni and Stefano Di Paola Throughout this presentation, we will present a new attack technique called HTTP Parameter Pollution (HPP). We will examine with a fresh perspective a newly discovered input validation flaw, while demonstrating new threats and possible attack scenarios. Such injection can be defined as the possibility to override the HTTP GET/POST parameters within the query string. In such situations, an attacker may replace existent values which are normally hardcoded and not accessible. In many cases it can be used to modify the behaviors of client-side and server-side applications, to exploit vulnerabilities in uncontrollable variables as well as bypassing web application firewalls. Some of the attacks covered in this talk have been discovered in real-world applications. Although input validation vulnerabilities are a well-known subject in the web application security field and are extensively covered by several researchers, it is quite surprising that no formal definition of the HPP attack was previously published, as far as we know. Once again, it is a clear demonstration of how important is to develop comprehensive input validation filters in order to manage new incoming web application threatsTRANSCRIPT
SEaCURE.it ‐ 23 October 2009 – Milan
HTTP Parameter PollutionPast, Present, Future
Luca CarettoniIndependent [email protected]
Stefano di PaolaCTO @ Minded [email protected]
2
About us
Luca “ikki” CarettoniPenetration Testing Specialist in a worldwide financial institutionSecurity researcher for fun (and profit)OWASP Italy contributorI blog @ http://blog.nibblesec.orgKeywords: web application security, ethical hacking, Java security
Stefano “wisec” Di PaolaCTO @ Minded Security Application Security ConsultingDirector of Research @ Minded Security LabsLead of WAPT & Code Review ActivitiesOWASP Italy R&D DirectorSec Research (Flash Security, SWFIntruder...)WebLogs http://www.wisec.it, http://blog.mindedsecurity.com
Agenda
IntroductionServer enumerationBizarre behaviors
HPP in a nutshellHPP Categories
Server side attacksConcept and Real world examples
Client side attacksConcept and Real world examples
How to detect HPP issues?FAQsConclusions
DISCLAIMER: This is an updated version of our previous OWASP AppSec2009 presentation. New tricks and hacks are included!
Fact
In modern web apps, several application layers are involved
Consequence
Different input validation vulnerabilities existSQL InjectionLDAP InjectionXML InjectionXPath InjectionCommand Injection
All input validation flaws are caused by unsanitized data flows between the front‐end and the several back‐ends of a web application Anyway, we still miss something here !?!
_ _ _ Injection
An unbelievable story…
Before our first presentation @OWASP AppSec Poland 2009, there was no formal definition of an injection triggered by query string delimitersHPP is surely around since many years, however it is definitely underestimatedAs a result, several vulnerabilities have been discovered in real‐world applications
Further researches have to investigate business logic flaws triggered by HPP. As we know, it is tricky and time consuming since manual testing is required
Introduction 1/2
The term Query String is commonly used to refer to the part between the “?” and the end of the URIAs defined in the RFC 3986, it is a series of field‐value pairsPairs are separated by “&” or “;”The usage of semicolon is a W3C recommendation in order to avoid escapingRFC 2396 defines two classes of characters:
Unreserved: a‐z, A‐Z, 0‐9 and _ . ! ~ * ' ( ) Reserved: ; / ? : @ & = + $ ,
Introduction 2/2
GET and POST HTTP request
Query String meta characters are &, ?, #, ; , = and equivalent (e.g. using encoding) In case of multiple parameters with the same name, HTTP back‐ends behave in several ways
GET /foo?par1=val1&par2=val2 HTTP/1.1User-Agent: Mozilla/5.0Host: HostAccept: */*
POST /foo HTTP/1.1User-Agent: Mozilla/5.0Host: HostAccept: */*Content-Length: 19
par1=val1&par2=val2
Server enumeration ‐ List
Server enumeration ‐ Summing up
Different web servers manage multiple occurrences in several waysSome behaviors are quite bizarreWhenever protocol details are not stronglydefined, implementations may strongly differ Unusual behaviors are a usual source of security weaknesses (MANTRA!)
A bizarre behavior 1/4
A bizarre behavior 2/4
A bizarre behavior 3/4
A bizarre behavior 4/4
Since this error generates ~100 lines in the log file, it may be used to obfuscate other attacks
HPP in a nutshell
HTTP Parameter Pollution (HPP) is a quite simple but effective hacking techniqueHPP attacks can be defined as the feasibility to override or add HTTP GET/POST parameters by injecting query string delimitersIt affects a building block of all web technologies thus server‐side and client‐side attacks existExploiting HPP vulnerabilities, it may be possible to:
Override existing hardcoded HTTP parameters Modify the application behaviorsAccess and, potentially exploit, uncontrollable variablesBypass input validation checkpoints and WAFs rules
HPP Categories
Classification:Client‐side
First order HPP or Reflected HPP Second order HPP or Stored HPP Third order HPP or DOM Based HPP
Server‐sideStandard HPPSecond order HPP
According to our classification, Flash Parameter Injection* may be considered as a particular subcategory of the HPP client‐side attack
* http://blog.watchfire.com/FPI.ppt
Encoding & Parameters precedence
Several well‐known encoding techniques may be used to inject malicious payloads
The precedence of GET/POST/Cookie may influence the application behaviors and it can also be used to override parameters
Apache Tomcat/6.0.18
POST /foo?par1=val1&par2=val2 HTTP/1.1Host: 127.0.0.1
par3=val3&par4=val4
FIRST occurrence, GET parameter first
HPP Server Side Attacks 1/2
Suppose some code as the following:
Which is the attack surface?
void private executeBackendRequest(HTTPRequest request){
String amount=request.getParameter("amount");String beneficiary=request.getParameter("recipient");
HttpRequest("http://backendServer.com/servlet/actions","POST","action=transfer&amount="+amount+"&recipient="+beneficiary
);}
HPP Server Side Attacks 2/2
A malicious user may send a request like:
Then, the frontend will build the following back‐end request:
Obviously depends on how the application will manage the occurrence
http://frontendHost.com/page?amount=1000&recipient=Mat%26action%3dwithdraw
action=transfer&amount=1000&recipient=Mat&action=withdraw
HttpRequest("http://backendServer.com/servlet/actions","POST","action=transfer&amount="+amount+"&recipient="+beneficiary);
HPP Server Side Attacks ‐ Flow
HPP Server Side ‐WAFs evasion
What would happen with WAFs that do Query String parsing before applying filters?Some loose WAFsmay analyze and validate a single parameter occurrence only (first or last one)Whenever the devel environment concatenates multiple occurrences (e.g. ASP, ASP.NET, AXIS IP Cameras, DBMan, …), an aggressor can split the malicious payload
E.g. ModSecurity default core rules bypass“Split and Join” by Lavakumar Kuppanhttp://packetstormsecurity.nl/papers/attack/parameter‐pollution.pdf
http://mySecureApp/db.cgi?par=<Payload_1>&par=<Payload_2>
par=<Payload_1>~~<Payload_2>
HPP Server Side – URL Rewriting
URL Rewriting could be affected as well if regexp are too permissive:RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ .+page\.php.*\ HTTP/RewriteRule ^page\.php.*$ - [F,L]
RewriteCond %{REQUEST_FILENAME} !-fRewriteCond %{REQUEST_FILENAME} !-dRewriteRule ^([^/]+)$ page.php?action=view&page=$1&id=0 [L]
http://host/abc
becomes:
http://host/page.php?action=view&page=abc&id=0
An attacker may try to inject:http://host/abc%26action%3dedit
and the url will be rewritten as:
http://host/page.php?action=view&page=abc&action=edit&id=0
Once again, the impact depends on the functionality exposed
23
HPP Server Side – URL Rewriting
Real World Examples
Server Side Attacks
Google Search Appliance
Once upon a time, during an assessment for XXX…
GSA was the LAN search engine exposed for public search as well, with only three controllable values
The parameter named “afilter” is used unencoded
By polluting GSA parameters, appending %23 (“#”), we got full access to internal results. Pls note, this is not a GSA vulnerability!
Information leakage in Python 1/3
In Python, multiple occurrences of the same parameter generate a list type object
In case of hardcoded functions that are not applicable to such object type, the application may generate an exception and, consequently, information disclosure
This is not an issue within the Python framework. Developers have to properly handle unexpected errors as well as to avoid information leakage
In these real‐world examples, an aggressor can easily retrieve file system paths, application source code, SQL queries, …
Information leakage in Python 2/3
Information leakage in Python 3/3
PayPal NVP API 1/4
PayPal NVP API is a programmatic interface that allows interaction with PayPal’s business functionalities
PayPal NVP API is available for several programming languages such as ASP, ASP.NET, PHP, Java, etc.
PayPal API requires a registered username/password and, either a signature or a certificate, in order to identify the requestor
Example of a “GetBalance” operation:
METHOD=GetBalance&VERSION=51.0&PWD=<OMITTED>&USER=<OMITTED> &SIGNATURE=<OMITTED>
GetBalance Completed Successfully: Array(
[L_AMT0] => 35770864%2e46[L_CURRENCYCODE0] => USD[TIMESTAMP] => 2009%2d10%2d19T10%3a04%3a42Z[CORRELATIONID] => eab6e62b5727b[ACK] => Success[VERSION] => 51%2e0[BUILD] => 1073465
)
PayPal NVP API 2/4
PayPal warns developers about potential problems.
“The request and response are URL‐encoded. URL‐encoding ensures that you can transmit special characters, characters that are not allowed in a URL, and characters that have special meaning in a URL, such as the equal sign and ampersand.”Source: https://cms.paypal.com/uk/cgi‐bin/?cmd=_render‐content&content_ID=developer/e_howto_api_soap_NVPAPIOverview
However, developers are fully responsible here. A simple mistake may cause a critical security issue, as we are going to demonstrate
PhpNVPCodeGenerate/RefundTransaction.php is a sample script provided by PayPal in order to speed up the API integration
In this code, $memo is declared but not included within an “urlencode()” function (it is not used in such specific script). What about an innocent cut&paste within your own application?
PayPal NVP API 3/4
Original “RefundTransaction” (using an invalid transaction id)
PayPal NVP API 3/4
Tampered “RefundTransaction”
&METHOD=MassPay&EMAILSUBJECT=example_email_subject&RECEIVERTYPE=EmailAddress&CURRENCYCODE=USD&L_EMAIL0=user0%4a0paypal.com&L_Amt0=1&L_UNIQUEID0=example_unique_id&L_NOTE0=example_noteo&L_EMAIL1=user1%40paypal.com&L_Amt1=1&L_UNIQUEID1=example_unique_id&L_NOTE1=example_noteo&L_EMAIL2=user2%40paypal.com&L_Amt2=10000&L_UNIQUEID2=example_unique_id&L_NOTE2=example_noteo
HPP Client Side attacks 1/2
HPP Client Side is about injecting additional parameters to links and other src attributesSuppose the following code:
There's no XSS, but what about HPP?It’s just necessary to send a request like
To obtain
<? $val=htmlspecialchars($_GET['par'],ENT_QUOTES); ?><a href="/page.php?action=view&par='.<?=$val?>.'">View Me!</a>
http:/host/page.php?par=123%26action=edit
<a href="/page.php?action=view&par=123&action=edit">View Me!</a>
HPP Client Side attacks 2/2
Once again, it strongly depends on the functionalities of a link or formIt's more about
Anti‐CSRF Functional UI Redressing
It could be applied on every tag with Data, SRC, HREF attributesAction forms with POST method
HPP Client Side attacks – Example with Anti CSRF tokens 1/2
Suppose a Web GUI using Anti CSRF Tokens
If an attacker sends the link to the victim:
// Jsp Example http://host/page.jsp?folder=inbox<form action=“/servlets/addUser.do?folder=<%=HtmlEntities(request.getParameter(‘folder’))%>”>
<input type=“hidden” name=“tok” value=‘<%=getCSRFToken()%>’><input type=“hidden” name=“cmd” value=“add”><input type=text name=“user” value=“”><input type=“submit” value=“add User”></form>
http://host/page.jsp?folder=inbox%26action%3duser=EvilUser
HPP Client Side attacks ‐ Example with Anti CSRF tokens 2/2
Whatever user the victim add the value is overriden (In case of J2ee), since the action is going to be:
Since the Anti CSRF token is still there the action will be executed.
Yes, depending on what cmd parameter allows to do, the attacker could also modify/override the cmd parameter.
// Jsp Example http://host/page.jsp?folder=inbox<form action=“/servlets/addUser.do?folder=inbox&user=EvilUser”>
HPP Client Side attacks ‐ Example with Anti Tampering HMAC
Suppose there’s an antitampering solution which appends a HMAC based signature:
Yes, we can still try with HPP to tamper ‘id’ par by sending http://host/shownews.php?showall=yes%26id=2+or+3=3If the server takes the second occurrence then is still possible to tamper the id parameter
// http://host/shownews.php?showall=yes<a href=“<?=Hmac(“/printnews.php?id=2&showall=”+$_GET [“showall” ] +””)?>” >print</a>
// http://host/shownews.php?showall=yes<a href=“/printnews.php?id=2&showall=yes&hmac=89042ab23e65f4543e93” >print</a>
HPP Client Side ‐DOM based
It's about parsing unexpected parametersIt's about the generation of client side HPP via JavaScriptIt's about the use of (XMLHttp)Requests on polluted pars
// It considers the first occurrence
function gup( name ){name = name.replace(/[\[]/,"\\\[").replace(/[\]]/,"\\\]");var regexS = "[\\?&]"+name+"=([^&#]*)";var regex = new RegExp( regexS );var results = regex.exec( window.location.href );if( results == null )return "";
elsereturn results[1];
}
// It considers the last occurrence
function argToObject () {var sArgs = location.search.slice(1).split('&');var argObj={};for (var i = 0; i < sArgs.length; i++) {var r=sArgs[i].split('=')argObj[r[0]]=r[1]}
return argObj}
Real World Examples
Client Side Attacks
Excite.it 1/2Features:
Several parameters could be HPPedAnti XSS using htmlEntities countermeasuresDOM HPP + Client Side HPP friendly!
http://search.excite.it/image/?q=dog&page=1%26%71%3d%66%75%63%6b%6f%66%66%20%66%69%6e%67%65%72%26%69%74%65%6d%3d%30
41
Sweet dogs? Clicking on an image...
This is a kind of “content pollution”Even if the example seems harmless, it may help to successfully conduct social engineering attacks
Excite.it 2/2
Yahoo! Mail Classic
FeaturesCheck antiCSRFDispatcher ViewHtml Entities filtering, antiXSSHPP compliant! /* now fixed */
The dispatcher pattern helps the attacker%26DEL=1%26DelFID=Inbox%26cmd=fmgt.delete
%2526cmd=fmgt.emptytrash
Attack payload:http://it.mc257.mail.yahoo.com/mc/showFolder?fid=Inbox&order=down&tt=245&pSize=25&startMid=0%2526cmd=fmgt.emptytrash%26DEL=1%26DelFID=Inbox%26cmd=fmgt.delete
How to detect server‐side HPP? 1/2
Detect HPP issues is tricky and prone to false positiveMost of the time, an in‐depth business logic knowledge is required. Automatic tools can only assist auditors
A simple detector can act as a proxy for web clients, issuing arbitrary HTTP requests and analyzing server responses(1) file?par1=val1(2) file?par1=HPP(3) file?par1=val1&par1=HPPIf (3) != (1) and (3) != (2) possible HPP
Several other heuristics can be used. Encoding, double encoding, etc. should be considered too
How to detect server‐side HPP? 2/2
Enhanced web application flaws detectors (with HPP capability) added to the latest NessusThis is used to detect client‐side weakness tooA few other commercial and open source tools have included this check (e.g. Cenzic)ModSecurity added the following rule to the CRS v.2.0.0:
SecRule ARGS_NAMES ".*" "chain,phase:2,t:none,nolog,pass,capture,setvar:'tx.arg_name_%{tx.0}=+1',msg:‘Multiple Parameters with the same Name.'"
SecRule TX:/ARG_NAME_*/ "@gt 1"
How to detect client‐side HPP? 1/2
For each parameter value add %26PATTERNSearch in Html response if attributes like:
Data, SRC, HREF attributesAction in forms
Have %26PATTERN in their value displaying some way like:
&PATTERN&PATTERN
If it is so, then begin to think what can be done :)
How to detect client‐side HPP? 2/2
Also, DOM based applications could be prone to parameter injection
Check for Query String parameter later used inXHRRuntime attribute creation
Client side HPP could be also affect Flash Parameters , applets and other client side pluginsSo pay attention also to FlashVars and similar proprietary attributes.
Countermeasures
Speaking about HPP, several elements should be considered:
Application business logicTechnology usedContextData validation (as usual!)Output encoding
Filtering is the key to defend our systems!Don't use HtmlEntities. They're out of context!Instead, apply URL EncodingUse strict regexp in URL RewritingKnow your application environment!
URL encoding reference
ASPServer.URLEncode
ASP.NETSystem.Web.HttpUtility.UrlEncodeSystem.Web.HttpUtility.UrlDecode
Javajava.net.URLEncoder.encodejava.net.URLDecoder.decode
PHPurlencode() urldecode()
Three FAQs
Q: Most of your examples and findings use GET. What about POST ? A: POST and COOKIE parameters may be affected as well. It is a very interesting aspect since it gives additional flexibility for all attacks
Q: HPP is only about WAFs bypasses?A: Absolutely not! HPP is also about applications flow manipulation, anti‐CSRF, content pollution
Q: Is this a new class of exploits or just another case of applications lacking input validation?
A: Actually, HPP is an input validation flaw. As SQL Injection and XSS, we may consider it as an injection weakness. In this specific case, query string delimiters are the "dangerous" characters
Conclusion
HPP affects server side as well client side componentsThe impact could vary depending on the affected functionalities
HPP requires further researches in order to deeply understand threats and risksSeveral applications are likely vulnerable to HPP
Standard and guidelines on multiple occurrences of a parameter in the QueryString should be defined Awareness for application developers is crucial
Go and exploit HPP flaws !/* ethically */