RE: "Ticken" web attacks?

["James C. Slora Jr." <james.slora () phra com>]

I have not seen such an attack. Here are some thoughts for discussion.

Since it was a DoS that got past filters, a reasonable starting
assumption would be that the request is simply designed to do just that
- get past filters and load balancers, and maximize your customer's
resource waste.

It starts off with a word that would be parsed as an HTTP method but
that would not be able to be served. The rest of the request wastes
server time figuring out the URL - there are standard parsing precedence
characters mixed with % characters, which should maximize the victim
server's effort involved in parsing the URL for each request without
having to make a long request that would trigger request filters. Since
the URL does not contain any characters other than delimiters and escape
characters, and does not start with a / it might not even register in
some balancing and filtering applications.

I don't know if the attacked server wastes time parsing the URL even if
the method is bad, but IIS does.

=================================================

GET 

Gives:
HTTP/1.1 400 Bad Request
Content-Type: text/html
Date: Wed, 22 Nov 2006 00:19:28 GMT
Connection: close
Content-Length: 34

<h1>Bad Request (Invalid URL)</h1>

=================================================

GET /

Returns the default home page if there is one for the server.

=================================================

Ticken /validpage

Gives <h1>Bad Request (Invalid Verb)</h1>

=================================================

Ticken /nonexistentpage

Gives <h1>Bad Request (Invalid URL)</h1>

=================================================

Ticken <%/%>%:|||:<&%%><<><?>

Also gives <h1>Bad Request (Invalid URL)</h1>

=================================================

So the attacker gets a little more DoS weight out of the request that is
harder to parse, even if using a nonexistent method. I assume (probably
wrongly) that the parsing engine has a low processing priority since the
big work on the server is normally the page composition and
presentation. That probably makes the parser an easier component to DoS
even on a well-resourced server.

The invalid verb might also take longer to process than a valid one
would, but I don't know if that is true.

They might also have been playing games with character encoding, using
escaping unnecessarily on characters that do not require escaping. That
might also have some interesting system-specific effects. 

http://www.mnot.net/blog/2006/06/30/percent_encoding

Shows some interesting variations of results you can get when sending
such requests. That blog focuses on requestor parsing oddities, but note
in particular Dilip's accidental variation of the original test, which
might have triggered a redirection loop response from the target server.
I don't understand how that would work exactly, but it looks like it's
worth some thought.

Maybe there was something like this going on in the DoS - I think you
would have to have packet captures and replay some variations against
the attacked server to really be sure about that. At a minimum the
attack looked like a tiny request designed to waste maximum resources
without getting filtered out or setting off alarms or getting balanced
away.


------------------------------------------------------------------------------
This List Sponsored by: Black Hat

Attend the Black Hat Briefings & Training USA, July 29-August 3 in Las Vegas.
World renowned security experts reveal tomorrow's threats today. Free of
vendor pitches, the Briefings are designed to be pragmatic regardless of your
security environment. Featuring 36 hands-on training courses and 10 conference
tracks, networking opportunities with over 2,500 delegates from 40+ nations.

http://www.blackhat.com
------------------------------------------------------------------------------