Re: OBESEUS - A new type of DDOS protector

[Guillaume FORTAINE <gfortaine () live com>]

Dear Mister Jain,

Thank you for your reply.

Please see the following article from Barry Greene :

http://www.senki.org/?p=623

DDOS Trends Changing – More Effective Attack Classes.

I will giving an interview today that the industry has done a poor job 
in communicating the changes in Denial of Service (DOS) attacks. 
CERT-FI’s release of the “Sockstress” details yesterday has a few people 
confused.  Outpost24 discovered some new TCP state abuse technique which 
can cause a range of issue on a TCP stack (see CERT-FI’s release 
details). It is a serious issue. But, if it is serious, why is there not 
a lot of attention on this attack vector.

The answer is simple. There is a lot of attention – TCP Connection 
Oriented State abuse is real. There is a real TCP state DOS threat. It 
is just not generally visible to the public.

In fact, the TCP Connection Oriented  State attacks more real than the 
general IT industry realizes. Why? Cyber-Criminal Market Dynamics!

Go back to 2006. In those days, a cyber-criminal would plan a extortion 
attack. “Pay me big buck by this date or I’m going to DOS you to 
oblivion.” To demonstrate the threat is real, the cyber-criminal would 
provide a demonstration, whacking the victim with a TCP SYN flood which 
would overwhelm the site’s ability to respond via TCP (TCP table s 
full). The TCP flood would take up all the target’s bandwidth to the 
Internet. To achieve this, the cyber-criminal would need to put more 
bandwidth at the target then the bandwidth available to the target (i.e. 
throw 1 Gbps of attack traffic down a 155 Mbps link). This overload 
would trigger a second set of events. The “demonstration” would send way 
too many TCP SYNs, filling up the bandwidth to the victim, back 
pressuring on the Service Provider’s PE router, and creating collateral 
damage on the SP’s other customers. This collateral damage wakes up the 
sleeping giant – with a SP’s SLA getting violated and forcing them to 
act. Now the cyber-criminal is dealing with their “target” and the 
target’s SP. The SP can and will throw want ever resource available to 
insure their SLAs to the range of the customers to not get violated. The 
victim gets help (or gets offered a ‘clean pipes’ service). In the end, 
the cyber-criminal’s pay off of “big bucks” is disrupted. All because 
their TCP State attack threw to many packets at the target. What they 
need was a better tool.

Fast forward to July 2009. A new BOTnet starts an attack on a range of 
US Government, commercial and Korean sites. The press goes wild with 
“North Korean cyber-warefare.” What is missed is that this attack is 
effective and not choking up bandwidth. This July 2009 attack is typical 
of what is seen today – a crafted TCP Connection Oriented State attack 
which is not a SYN flood. The malware in the BOTNET is designed to use a 
variety of TCP techniques – some simple (open a TCP connection and 
tickle it to keep it alive) and TCP abusive (attacks highlighted by 
Outpost24, Phrack, and others). All these techniques are designed to 
fill up a target’s “state table.” This state table can be a server (web, 
voice, application), a firewall, a load balancer, a reverse cache or any 
other device which terminates TCP State. The core principle of these 
sort of TCP State attack are to keep TCP connections open and alive. The 
more TCP connections you can keep open, greater the chance you will fill 
up the TCP state table – allowing no new TCP connection into the system 
– completing the DOS attack. The advantage with this class of TCP State 
attacks is that you do not need a lot of bandwidth. TCP SYN floods FIFO 
(First In First Out) the TCP state table, which is why it requires a lot 
of packets. Connection oriented TCP state attacks just need to open the 
session and keep the session open, needing far fewer packets.

Far fewer packets mean you are not flooding the target’s links to the 
Internet. Not flooding the links to the Internet means no collateral 
damage on the SP’s infrastructure or customers. The SP’s SLA is not 
violated, hence, the SP is not motivated to jump into the middle of the 
attack.  In essence, the cyber-criminal’s goal is complete. They can now 
threaten the target with “Pay me big buck by this date or I’m going to 
DOS you to oblivion” without the big SP getting into the way of the “big 
bucks.”

The obvious next question is “if this is so easy, why isn’t it happening 
more often?” We’ll get to that in the next article. There are a range of 
factors – some economic, some technology, and some based on the 
dialectic with the community which mitigates wide spread extortion, 
retribution, and vindictive TCP Connection Oriented  State Attacks from 
being more widely used.

For now, anyone who is really interested in this topic should download 
and read Security Assessment of the Transmission Control Protocol (TCP) 
by Fernando Gont and sponsored by the UK CPNI (Centre for the Protection 
of National Infrastructure). 
http://www.cpni.gov.uk/Products/technicalnotes/Feb-09-security-assessment-TCP.aspx



Best Regards,

Guillaume FORTAINE


On 03/15/2010 06:04 PM, Deepak Jain wrote:
> At first blush, I would say it's an interesting idea but won't actually resolve anything of the scariest DDOS attacks we've 
> seen. (Unless I've missed something obvious about your doodle).
>
> The advantage/disadvantage of 100,000+ host drone armies is that they don't actually *have* to flood you, per se. 10 pps (or less) each and 
> you are going to crush almost everything without raising any alarms based on statistically significant patterns especially based on IPs. 
> Fully/properly formed HTTP port 80 requests to "/" won't set of any alarms since each host is opening 1 or 2 connections and 
> sending keepalives after that. If you forcibly close the connection, it can wait 5 seconds or 15 minutes before it reopens, it doesn't 
> really care. Anything that hits you faster than that is certainly obnoxious, but MUCH easier to address simply because they are being boring.
>
> You *can* punt those requests that are all identical to caches/proxies/IDS/Arbor/what have you and give higher priority 
> to requests that show some differences from them... but you are still mostly at the mercy of serving them unless you 
> *can* learn something about the originator/flow/pattern -- which might get you into a state problem.
>
> Where this might work is if you are a large network that only serves one sort of customer and you'd rather block rogue 
> behavior than serve it (at the risk of upsetting your 1% type customers). This would work for that. Probably good at 
> stomping torrents and other things as well.
>
> Best,
>
> Deepak
>
>    
> > -----Original Message-----
> > From: Guillaume FORTAINE [mailto:gfortaine () live com]
> > Sent: Monday, March 15, 2010 2:57 AM
> > To: nanog () nanog org
> > Subject: Re: OBESEUS - A new type of DDOS protector
> >
> > Dear Mister Wyble,
> >
> > Thank you for your reply.
> >
> >
> > On 03/15/2010 07:00 AM, Charles N Wyble wrote:
> >      
> > > The paper is pretty high level, and the software doesn't appear to be
> > > available for download.
> > >        
> >
> > http://www.loud-fat-bloke.co.uk/obeseus.html
> >
> > http://www.loud-fat-bloke.co.uk/tools/obeseusvB.tar.gz
> >
> >
> >
> >      
> > > So it's kinda theoretical.
> > >
> > >
> > >        
> >
> > "We have it running parallel with a commercial product and it detects
> > the following
> > attacks
> > ▪ SYN floods
> > ▪ RST floods
> > ▪ ICMP floods
> > ▪ General UDP floods
> > ▪ General TCP floods"
> >
> >
> >
> >
> > Best Regards,
> >
> > Guillaume FORTAINE
> >
> >      
>