Security Expert Doubts SCO's Attack Story (Groklaw)

Posted Dec 11, 2003 3:11 UTC (Thu) by AnswerGuy (guest, #1256) [Link]

I didn't read this in detail but a couple of things strike me as obvious.
First SYN floods don't require distribution from hundreds or "thousands"
of machines. You don't need a DDoS for a SYN flood. Just any host and
a network connection that doesn't do egress filtering. You can then simply
fire off a few hundred or thousand SYN packets (forging SRC addresses, and
perhaps diddling some TTLs for further source obscuration).

As the Groklaw article says, SYN flooding is of little consequence these
days since Linux and most other modern TCP stacks now support SYN cookies.

Also the allegation that this was consuming "all the ISP's bandwidth" is
equally non-sensical. The whole point of SYN flooding is that it required
very little bandwidth for the attacker. In fact it consumes a tiny fraction
of the bandwidth that would be utilized by normal traffic.

It simply amazes me that these people are pushing out such press releases
without having even the most cursory examination by someone with a
modicum of technical competance. I think they should at least enlist a
few of Microsoft's QA people to help them out! (Since MS is footing the
bill for such a large part of their litigation war chest).

Jim

Posted Dec 11, 2003 4:23 UTC (Thu) by huaz (guest, #10168) [Link]

I found Steve's comment a little suspicious too:

"Dealing with an DDoS atack when your bandwidth is NOT eaten up is fairly simple. A quick and dirty script to read your firewall log(s) for incoming addresses that are trying the SYN attacks is fairly easy. Adding those IP addresses to a quick block list is also easy."

SYN flood comes with random forged source IP addresses. How could the script block forged IP addresses?

Posted Dec 11, 2003 5:48 UTC (Thu) by error27 (subscriber, #8346) [Link]

The opinion on Groklaw was that they were faking it last time too.

Last time, there were conflicting reports from SCO admins and employees, ESR, and people who worked in the same building as SCO and shared internet access with them. SCO admins claimed they were just taking the website down to reconfigure it. Other SCO employees said the same thing. Some SCO employees claimed it was a DoS. ESR claimed that the script kiddie contacted him and said he would stop the attack. Other people in the building said their internet access was really slow.

My own opinion from last time was that there was an initial small DoS and then the admins at SCO took the website down for a couple days to reorganize the infrastructure.

Since then Darl McBride has definately decided to call it an "attack" and tried to paint ESR as an accomplice. They are definately claiming that the last alleged DoS attack took them offline for a couple days which is probably not true.

Posted Dec 11, 2003 11:17 UTC (Thu) by davidl (guest, #12156) [Link]

Oh poor SCO! They've been hit by a non-existant attack in order to try to gain sympathy. Sad. Very sad.

Posted Dec 11, 2003 11:22 UTC (Thu) by melevittfl (subscriber, #5409) [Link]

I posted a longer version of the following at Groklaw:

SCO is absolutly lying to say they are under a SYN attack.

Here is the output of sniffing the network packets from my machine to SCO's web server:

1. 07:36:40.068702 sheryl.46702 > www.sco.com.http: S 3257175132:3257175132(0) win 5840
2. 07:36:40.085872 www.sco.com.http > sheryl.46702: S 3322256980:3322256980(0) ack 3257175133 win 8568
3. 07:36:40.085929 sheryl.46702 > www.sco.com.http: . ack 1 win 5840
4. 07:36:40.128975 sheryl.46702 > www.sco.com.http: P 1:99(98) ack 1 win 5840
5. 07:36:40.142052 www.sco.com.http > sheryl.46702: . ack 99 win 16384
6. 07:36:52.105080 sheryl.46702 > www.sco.com.http: F 99:99(0) ack 1 win 5840
7. 07:36:52.116928 www.sco.com.http > sheryl.46702: . ack 100 win 16384

First of all, I captured this sequence a few minutes ago. However, I tried it last night before I went to bed and saw the same thing.

This is the sequence of packets exchanged between my machine (sheryl) and www.sco.com's web server) (www.sco.com.http), captured by the tcpdump program.

So, the implication here is interesting. If the web server software was simply not running, the OS would not accept the connection to port 80 (the http port). As soon as packet #1 arrived, the OS would reply with a "connection refused" packet.

The fact that the OS allowed the connection to complete means that the web server software is running.

This is weird.

• If someone had simply pulled the network cable on the machine, the connection wouldn't get past sending the first packet.
• If the web server software was not running, packet #2 would be a connection refused packet the connection would stop.

So, it seems as if there is nothing at all wrong with SCO's internet connection or the OS running the web server software. I can only think of two possibilities:

1. SCO's web server is badly misconfigured by accident.
2. SCO has intentionally crippled there web server to not reply to request.

I'm not much for conspiracy theories, but I find I can't think of a normal failure mode or a DDOS attack where the OS would be perfectly capable of establishing a connection, the web server is running and accepting those connections, but doesn't actually send any data.

I can say that it is definitly not a SYN flood attack. I saw the same sequence of packets when it was first reported. SCO is lying. Why, I cannot imagine.

Posted Dec 11, 2003 11:49 UTC (Thu) by ballombe (subscriber, #9523) [Link]

SCO as anybody else running Linux, had to update its kernel to
fix the do_brk() vulnerability and reboot its box, causing some downtime
(well, unless they have back up or redundant servers as anybody that want
a 99.99% uptime should have, but they don't seem to.)

Maybe they just called the downtime a DDoS in remember of the good ol'
DrDOS days.