[WEB SECURITY] HTTP Verb Tampering for Dummies

Arian J. Evans arian.evans at anachronic.com
Tue Jun 3 21:52:20 EDT 2008


The reason for my post was two-fold. I wanted
to simply my explantion pointing out the root
causes lend themselves to both semantic
and syntax attacks equally. And second to
stimulate some productive discussion on
this subject. It seems to me that most automated
tools, black box or source, don't have much
to offer here (today) and the average pen
tester isn't leveraging these techniques.

I figured lots of folks new to the list might
be able to use an "overview" of the subject.

Regarding Vendors:

I'm a bit torn on that one. I like vendors to give me
the flexibility to do what I want. In one specific
case I used a proxy to modify the method on
certain request conditions and used that to
distinguish which requests went to which
request handlers on IIS to provide a rudimentary
migration path to .NET for some old code.

Passing them on, transparently by default,
is probably not a smart default however.

The examples that I have found over the years
were mostly due to improper code implementations,
mostly in ASP Classic designs where security
decisions were made at every page level (and
borked depending on how they parsed
Session.ServerVariable(all), and J2EE
designs were requests were trusted to be
handled by a servlet making the right decisions,
but requests didn't necessarily all come
through the proper servlet as expected.

But I've found cases were you can leverage
method abuse for attacks in about every
framework & implementation language
I've tested, including .NET and the early
versions of the request validators.

Thanks for the link, Adam.

-- 
-- 
Arian J. Evans. Software Security Stuff.

Not a Verb? Well it's definitely not a Noun.



On Tue, Jun 3, 2008 at 6:16 PM, Arshan Dabirsiaghi
<arshan.dabirsiaghi at aspectsecurity.com> wrote:
> This is exactly the message we were sending, and absolutely qualifies as
> prior art. Thanks!
>
> Does anyone else feel like like the vendors should bear some "blame" for
> forwarding on arbitrary "methods" (not verbs, which I was scolded for using)
> onto the GET handler? It seems really arbitrary of them.
>
> Arshan
> ________________________________
> From: Adam Muntner [mailto:adam.muntner at quietmove.com]
> Sent: Tue 6/3/2008 9:15 PM
> To: Arshan Dabirsiaghi
> Cc: Arian J. Evans; websecurity at webappsec.org
> Subject: Re: [WEB SECURITY] HTTP Verb Tampering for Dummies
>
> Here is the whitepaper from 2004 I had been trying to find
>
> http://www.kernelpanik.org/docs/kernelpanik/bme.eng.pdf
>
> An Apache 2.0 land one should use LimitExcept instead of Limit in  .htaccess
> files. Still, this is an interesting paper because it describes using method
> tampering to bypass an authentication mechanism.
>
>
>
> On Tue, Jun 3, 2008 at 3:40 PM, Arshan Dabirsiaghi
> <arshan.dabirsiaghi at aspectsecurity.com> wrote:
>>
>> > Let's face it: there are several poorly-documented and
>> > obscure subjects we debate on this list which depend
>> > on domain knowledge tucked away in a lot of folks'
>> > brains here. Those brains are still unsearchable by Google
>>
>> It's too true. I don't want to get into the "is this groundbreaking"
>> argument again - the top 2% of veteran testers may have known about verb
>> tampering (likely), using HEAD to forward to GET behind security controls
>> (possible), or even using arbitrary verbs to do the same thing (unlikely).
>>
>> In the end, most people did not. I received a lot of positive offline
>> responses as well, and I couldn't ask for more validation than that (well,
>> maybe some positive *online* responses).
>>
>> AS FOR WHAT ARIAN is blabbing about, I wholeheartedly agree. This
>> illuminates the need for a kind of single, trusted channel through which our
>> applications can operate on request data. It seems like a high-security
>> component should take the initial HTTP request, perform whatever global
>> security it can perform (AuthN, URL AuthZ, limited DoS, limited IV), and
>> only send on the exact data that the action needs to implement its use
>> case. Tools like SiteMinder almost actually do this and I think something
>> like it should be baked into our frameworks - something else to bug Sun and
>> Mark Curphey about.
>>
>> > Some were intimidated by the list
>> > debate. (and I think a few confused myself with Arshan :)
>>
>> If anyone is looking to distinguish between us at Blackhat, I'm the
>> slightly browner one. Arian, maybe we should incentivize someone to find a
>> prior vuln using these techniques? Incentivizing is my answer to everything.
>> =P
>>
>> Arshan
>> ________________________________
>> From: arian.evans at gmail.com on behalf of Arian J. Evans
>> Sent: Tue 6/3/2008 5:47 PM
>> To: websecurity at webappsec.org
>> Subject: [WEB SECURITY] HTTP Verb Tampering for Dummies
>>
>> ****Answering questions about HTTP Verb Tampering Attacks****
>>
>> --
>>
>> I received many offline questions about the Aspect
>> HTTP verb tampering paper, and my response. The
>> questions largely come from people newer to the
>> webappsec "field" who genuinely want to learn more
>> about the subject. Some were intimidated by the list
>> debate. (and I think a few confused myself with Arshan :)
>>
>> Let's face it: there are several poorly-documented and
>> obscure subjects we debate on this list which depend
>> on domain knowledge tucked away in a lot of folks'
>> brains here. Those brains are still unsearchable by Google.
>>
>> In this air of open documentation I'm going to attempt to
>> summarize Aspect's paper and my subsequent post
>> focusing on the core issues underlying this.
>>
>> (In fact, it's probably about time we write a "Webappsec
>> for Dummies" book. Maybe Andre can help me on this.)
>>
>> On Tue, Jun 2, 2008 at 8:00 AM, Big Bob Thundercup <bigbob at fukung.net>
>> wrote:
>> > Hi Arian,
>> [...]
>> > would you mind explaining what you were refering to when you mentioned
>> > using
>> > HEAD (or any arbitrary HTTP verbs) in a replay attack?
>> > --
>>
>>
>> I mistakenly used the phrase 'replay requests' in my
>> reply to Arshan's paper. Strike the word "replay" as it
>> was only referring to testing actions. In many of these
>> cases, the real attack c/would be the first one that the
>> system had ever seen.
>>
>>
>> So here is the core of the matter of the HTTP Verb [stuff]:
>>
>> Q: Why do we care about HTTP Verb tampering?
>>
>> A: Because some pieces of software may perform
>> security or safety functions *independently* of the
>> functions accepting & processing the data submitted
>> in the HTTP request.
>>
>> So you have, in order of operation and dependency:
>>
>> 1. Safety function performing some form of input
>> validation, type safety, or an authentication or
>> authorization check that is:
>>
>> 1.1. Bound to SPECIFIC HTTP VERBs (e.g.- GET and/or POST)
>>
>> or
>>
>> 1.2. Bound to a specific part of the request object (e.g-the querystring)
>>
>> "bound to" == some form of dependency. This could
>> be due to a default framework file config, but most
>> commonly (in my experience) is an implementation
>> mistake made by a developer, out of innocent ignorance
>>
>>
>> And next in the chain you have:
>>
>> 2. A function operating on the request data that is
>> NOT bound to any specific part of the HTTP request
>> or is parsing *different* parts of the request for
>> data than the control function is.
>>
>> ==
>>
>> If these conditions are true, you have the potential
>> to attack the software by using all your normal
>> arsenal of attacks -- by fiddling with the HTTP Verb
>> or request structure to slide the attack by the
>> applications existing controls.
>>
>>
>> 3. Attack vectors
>>
>> 3.1 Here is a sample syntax attack attempting SQL
>> Injection on an application via a GET request:
>>
>> + GET http://www.anachronic.com/retirementfund/?module=' SELECT * FROM
>> ACCOUNTS....
>>
>>
>> 3.2 Here is a semantic attack on an application
>> resetting my password to password using GET:
>>
>> + GET
>> http://www.anachronic.com/secret/admin.php?uid=aevans&role=uber&password=password&reset=true
>>
>> (please, no one request this actual URL from my software, thanks)
>>
>>
>> In 3.1, this example will get blocked by rigorous input validation,
>> or perhaps a blacklist that does not allow SELECT * in "modules=".
>>
>>
>> In 3.2, this example will get blocked by an authorization check,
>> or perhaps a blacklist that does not allow: password=password.
>>
>>
>> However: in BOTH cases the following controls:
>>
>> + input validation/strong data typing
>> + blacklists
>> + authentication and/or authorization checks
>>
>> Are be bound to a specific HTTP verb like GET, or a specific part
>> of the HTTP request object, like the querystring of the URI.
>>
>> If this is true -- if the control functions are bound to a verb,
>> or a specific part of a request object, then there is a chance
>> you can bypass those controls with minimal manipulation.
>>
>> By manipulating the verb, e.g.-changing GET to POST
>> or the upcoming HTTP 2.0 Verb ARIANROCKS or even
>> a made-up verb like WASC (http://blahblahblahblah)
>> you may be able to thread your attack into the application.
>>
>> Also -- by malforming the request you can sometimes
>> achieve the same end. So turn a POST into a GET request,
>> but *leave* the attack values in the Postdata body.
>>
>> And, alternately, take a GET request, and leave it so that
>> it looks like a GET, but put the attack data values down in
>> the Postdata part of the request (which is invalid for a GET)
>>
>> By stuffing your attack into an application using unexpected
>> Verbs, or malformed requests (for the Verb in question)
>> you may bypass the input validation filters, the authorization
>> check, or other security controls -- yet the application may
>> still process the data making this a viable attack vector.
>>
>> --
>> The long and short -- these techniques are simply subtle
>> twists of the protocol on all the usual web application
>> security attack vectors.
>> --
>>
>> We are taking all our normal attack vectors, from authorization
>> bypasses to SQL Injection, and using Verb tampering to
>> slide attacks into the application around security controls.
>>
>> And as many will tell you -- variations of these techniques
>> are well-known by a handful of top-rung experienced
>> pen-testers, and many tools also exist to help you create
>> these types of attacks today. However, outside of the
>> Aspect paper, the specifics of constructing these attacks
>> are not well documented.
>>
>> In fact, if you dig through the myriad of open-source
>> advisories on XSS and SQLi, I don't think you'll find
>> any documented attack vectors in those advisories
>> using these techniques, but I bet we'll see them soon.
>>
>> --
>>
>> I hope someone finds this post useful or I just drank
>> six cups of coffee & rum this morning for nothing.
>> (Which I further blame on Francois Larouche & SQL
>> Power Injector, but that's another story.)
>>
>> So who all is going to Vegas for BH 2008?
>>
>> Someone likely owes me a drink for something, IIRC.
>>
>> ciao
>>
>> --
>> --
>> Arian J. Evans.
>>
>> I spend most of my money on motorcycles, mistresses, and martinis. The
>> rest of it I cheerfully squander!
>>
>>
>> ----------------------------------------------------------------------------
>> Join us on IRC: irc.freenode.net #webappsec
>>
>> Have a question? Search The Web Security Mailing List Archives:
>> http://www.webappsec.org/lists/websecurity/
>>
>> Subscribe via RSS:
>> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>>
>> Join WASC on LinkedIn
>> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>>
>
>
>
> --
> Adam Muntner, CISSP
> Managing Partner
> QuietMove, Inc.
> (602)793-5969
> http://www.quietmove.com

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA



More information about the websecurity mailing list