Automated Detection of HPP Vulnerabilities in Web Applications Version 0.3, Black Hat USA 2011

Automated Detection of HPP Vulnerabilities in Web ApplicationsMarco `embyte` Balduzzi

RoadmapIntroductionHTTP Parameter PollutionClient-SideServer-SideOther UsesDetection ApproachToolDemoExperimentsResultsPrevention

Who am I?From Bergamo (IT) to the French RivieraMSc in Computer EngineeringPhD at EURECOM8+ years experience in IT SecurityEngineer and consultant for different international firmsCo-founder of BGLug, Applied Uni Lab, (ex) SPINE Group, Nast, etc…http://www.iseclab.org/people/embyte

The Web as We Know ItHas evolved from being a collection of simple and static pages to fully dynamic applicationsApplications are more complex than they used to beMulti-tier architecture is the normalMany complex systems have web interfaces

Increased Importance of Web SecurityAs a consequence:Web security has increased in importanceOWASP, the Top Ten Project Attack against web apps constitute 60% of attacks on the Internet (SANS’s The Top Cyber Security Risks)Application being targeted for hosting drive-by-download content or C&C serversMalware targeting browsers (e.g. key and network loggers)

Increased Importance of Web SecurityA lot of work done to detect injection type flaws:SQL InjectionCross Site ScriptingCommand InjectionInjection vulnerabilities have been well-studied, and tools existSanitization routines in languages (e.g., PHP)Static code analysis (e.g., Pixy, OWASP Orizon)Dynamic techniques (e.g., Huang et al.)Web Application Firewalls (WAF)

HTTP Parameter PollutionA new class of Injection Vulnerability called HTTP Parameter Pollution (HPP) is less knownHas not received much attentionFirst presented by S. di Paola and L. Carettoni at OWASP 2009Attack consists of injecting encoded query string delimiters into existing HTTP parameters (e.g. GET/POST/Cookie)If application does not sanitize its inputs, HPP can be used to launch client-side or server-side attacksAttacker may be able to override existing parameter values, inject a new parameter or exploit variables out of a direct reach

Research ObjectivesTo create the first automated system for detecting HPP flawsBlackbox approach, consists of a set of tests and heuristicsTo find out how prevalent HPP problems are on the webIs the problem being exaggerated?Is this problem known by developers?Does this problem occur more in smaller sites than larger sites?What is the significance of the problem?

HTTP Parameter HandlingDuring interaction with web application, client provides parameters via GET/POST/CookieHTTP allows the same parameter to be provided twiceE.g., in a form checkboxhttp://www.w3schools.com/html/tryit.asp?filename=tryhtml_form_checkboxWhat happens when the same parameter is provided twice?http://www.google.com/search?q=italy&q=chinahttp://www.site.com/login?user=alice&user=bob

HTTP Parameter HandlingWe manually tested common methods of 5 different languagesThere is nothing bad with it, if the developer is aware of this behaviorLanguages provide secure functions (python’s getfirst())

HTTP Parameter Pollution (Client-Side)Malformed PageMalicious ActionUser AttackAttacker generatesThe Trigger URLTrigger URL aresent to the victimsExamples: Deletion of personal emails

Generation of custom friend-requests

Purchasing unintended products

Unintended votingSite vulnerable toHTTP Parameter Pollution

Client-Side #1: Unintended votingAn application for voting between two candidates The two links are built from the URLNo sanitizationUrl: http://host/election.jsp?poll_id=4568Link1: <a href="vote.jsp?poll_id=4568&candidate=white”> Vote for Mr.White </a>Link2: <a href="vote.jsp?poll_id=4568&candidate=green”> Vote for Mrs.Green </a>ID = Request.getParameter(“pool_id”)href_link = “vote.jsp?poll_id=” + ID + ”&candidate=xyz”

Client-Side #1: Unintended votingpoll_id is vulnerableAttacker generate a Trigger URL to be sent to his victims:http://host/election.jsp?poll_id=4568%26candidate%3DgreenThe resulting page now contains injected links:Candidate Mrs. Green is always voted!<a href=vote.jsp?pool_id=4568&candidate=green&candidate=white> Vote for Mr. White </a><a href=vote.jsp?pool_id=4568&candidate=green&candidate=green> Vote for Mrs. Green </a>

Client-Side #2: Misleading shopping users

Client-Side #3: Sharing componentsSharing functionalities can be attackedNo validation in the sharer API (Facebook, Twitter, …)Injection on the customer side (e.g. blog post)Client-side attackPosting of unintended data

Automated Detection of HPP Vulnerabilities in Web Applications Version 0.3, Black Hat USA 2011

HTTP Parameter Pollution (Server-Side)FrontendBackendAttacker generatesThe Trigger URLUsed to exploit the server-side logic of the web-applicationThe attacker sends the Trigger URL to the vulnerable application

Server-Side #1: Payment SystemE.g., Payment system (di Paola / Carettoni)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);}Trigger URL: http://frontendHost.com/page?amount=1000& recipient=Mat%26action%3dwithdrawInjected query on the backend:HttpRequest("http://backendServer.com/servlet/actions","POST”, action=transfer&amount=1000&recipient=Mat&action=withdraw);

Server-Side #2: Database hijackingE.g., Access the user passwordsASP concatenates the values of two parameters with the same name with a commaThis permits to inject and modify the query on the databaseNormal requests: URL: printEmploys?department=engineering Back-end: dbconnect.asp?what=users&department=engineering Database: select users from table where department=engineeringHPP injected requests: URL: printEmploys?department=engineering%26what%3DpasswdBack-end: dbconnect.asp?what=users&department=engineering&what=passwdDatabase: select users,passwd from table where department=engineering

Server-Side #3: Authorization BypassGoogle Blogger exploited by NirGoldshlagerGet administrator privilege over any blogger accountAttacker uses the add authors functionalityThe server checks the 1stblogid value but executes the 2ndblogid value of the attackerWhen the attacker is added as user to the victim’s blogger, he raises his privileges to administratorPOST /add-authors.do HTTP/1.1 security_token=attacker_token&blogID=attacker_blogidvalue&blogID=victim_blogidvalue&authorsList=attacker_email&ok=Invite

Parameter Pollution – More uses1) Cross-channel pollutionOverride parameters between different input channels (GET/POST/Cookie)Good security practice: accept parameters only from where they are supposed to be supplied2) Bypass CSRF tokensE.g. Yahoo Mail client-side attack (di Paola & Carettoni)The user’s mails get automatically deleted!

Parameter Pollution – More uses3) Bypass WAFs input validation checksSplit & Join the attack payloadE.g., SQL injection via parameter replicationExploit ASP concatenation behavior and inline commentsStandard: show_user.aspx?id=5;select+1,2,3+from+users+where+id=1– Over HPP: show_user.aspx?id=5;select+1&id=2&id=3+from+users+where+id=1—Standard: show_user.aspx?id=5+union+select+*+from+users—Over HPP: show_user.aspx?id=5/*&id=*/union/*&id=*/select+*/*&id=*/from+users--

System for HPP DetectionFour main components: browser, crawler, two scanners

P-Scan: Analysis of the Parameter PrecedenceAnalyzes a page to determine the precedence of parameters, when multiple occurrences of the same parameter are submittedTake parameter par1=val1, generate a similar value par1=new_valPage0 (original): app.php?par1=val1Page1 (test 1) : app.php?par1=new_valPage2 (test 2) : app.php?par1=val1&par1=new_valHow do we determine precedence? Naïve approach:Page0==Page2 -> precedence on first parameterPage1==Page2 -> precedence on second parameter

P-Scan: Problem with the naïve approachIn practice, naïve technique does not work wellApplications are complex, much dynamic content (publicity banners, RSS feeds, ads, etc.)Hence, we perform pre-filtering to eliminate dynamic components (embedded content, applets, IFRAMES, style sheets, etc.)Remove all self-referencing URLs (as these change when parameters are inserted)We then perform different tests to determine similarity

V-Scan: Testing for HPP vulnerabilitiesFor every page, an innocuous URL-encoded parameter (nonce) is injected in the page’s parametersE.g., ?q=italy%26foo%3DbarThe page is submitted (GET/POST)Then, the answered page is checked for containing the decoded version of the nonce (&foo=bar):In links or forms (action)

Where to inject the noncePA = PURL ∩ PBody: set of parameters that appear unmodiﬁed in the URL and in the page content (links, forms)PB = p | p ∈ PURL ∧ p /∈ PBody: URL parameters that do not appear in the page. Some of these parameters may appear in the page under a different namePC = p | p /∈ PURL ∧ p ∈ PBody: set of parameters that appear somewhere in the page, but that are not present in the URL

Reducing the False PositivesE.g., one of the URL parameters (or part of it) is used as the entire target of a linkSelf-referencing linksSimilar issues with printing, sharing functionalitiesTo reduce false positives, we use heuristicsE.g., the injected parameter does not start with http://Injection without URL-encoding

Implementation – The PAPAS toolPAPAS: Parameter Pollution Analysis SystemThe components communicate via TCP/IP socketsCrawler and Scanner are in PythonThe browser component has been implemented as a Firefox extensionAdvantage: We can see exactly how pages are rendered (cope with client-side scripts, e.g. Javascript)Support for multiple sessions (parallelization)

Implementation – The PAPAS toolPAPAS is fully customizableE.g., scanning depth, number of performed injections, page loading timeouts, etc.Three modes are supportedFast mode, extensive mode, assisted modeIn assisted mode, authenticated areas of a site can be scanned as wellNow, as a free-to-use-service:http://papas.iseclab.org

Possible improvementsPAPAS does not support the crawling of links embedded in active contentE.g., flashSupport additional encoding schemas (UTF-8, Double URL)PAPAS currently only focuses on client-side exploits where user needs to click on a linkHPP is also possible on the server side – but this is more difficult to detectAnalogous to detecting stored XSS

Ethical ConsiderationsOnly client-side attacks. The server-side have the potential to cause harmWe provided the applications with innocuous parameters (&foo=bar). No malicious code.Limited scan time (15min) and activityWe immediately informed, when possible, the security engineers of the affected applicationsThankful feedbacks

Two set of experiments1) We used PAPAS to scan a set of popular websitesAbout 5,000 sites collected by the first 500 of Alexa’s main categoriesThe aim: To quickly scan as many websites as possible and to see how common HPP flaws are2) We then analyzed some of the sites we identified to be HPP-vulnerable in more detail

Efficient assessmentIn 13 days, we tested 5,016 sites and more than 149,000 unique pagesTo maximize the speed, the scannerCrawled pages up to a distance of 3 from the homepageConsidered links with at least one parameter (except for the homepage)Considered at max 5 instances for page (same page, different query string) We disabled pop-ups, images, plug-ins for active content technologies

Evaluation – Parameter PrecedenceDatabase ErrorsWeb developers does not seem conscious of the possibility to duplicate GET/POST parameterNo sanitization is in place

Nasa.gov: coldfusion SQL Error

Evaluation – Parameter PrecedenceParameter InconsistencySites developed using a combination of heterogeneous technologies (e.g. PHP and Perl)This is perfectly safe if the developer is aware of the HPP threat… this is not always the case

Evaluation – HPP VulnerabilitiesPAPAS discovered that about 1,500 (30%) websites contained at least one page vulnerable to HTTP Parameter InjectionThe tool was able to inject (and verify) an encoded parameterVulnerable != ExploitableIs the parameter precedence consistent?Can a possible attacker override existing parameter values?

Vulnerable or Exploitable?Injection on linkRead a mail: http://site.com/script?mail_id=10&action=readParameter in the middle -> always overriding?mail_id=10&action=delete&action=readParameter at the begin/end -> automated check via P-Scan?action=read&mail_id=10&action=deleteInjection on form:The injected value is automatically encoded by the browserStill, someone may be able to run a two-step attack (client-side) or a server-side attack702 applications are exploitable (14%)

EvaluationMore sensitive sites are equally (or even more) affected by the problem

False Positives10 applications (1.12%) use the injected parameter as entire target for one linkVariation of the special case we saw in previous slide (V-Scan: special cases)The application applied a transformation to the parameter before using it as a link’s URL

Some Case StudiesWe investigated some of the websites in more detailAmong our “victims”: Facebook, Google, Symantec, Microsoft, PayPal, Flickr, FOX Video, VMWare, …We notified security officers and some of the problems were fixedFacebook: share componentSeveral shopping cart applications could be manipulated to change the price of an itemSome banks were vulnerable and we could play around with parametersGoogle: search engine results could be manipulated

Automated Detection of HPP Vulnerabilities in Web Applications Version 0.3, Black Hat USA 2011

More Related Content

Automated Detection of HPP Vulnerabilities in Web Applications Version 0.3, Black Hat USA 2011