Let’s move to the technical side: it was a pretty small DDoS, with about 50MBit/s – we probably wouldn’t have noticed as it just looked like a normal traffic spike and did not endanger the availability of the website at all. We’ve handled much larger legitimate traffic spikes for that site already.

A quick investigation showed that WebLOIC was being used and was ‘hosted’ on a nopaste service. Requests looked like this:

GET /?id=1300380622178&msg=We%20Are%20Legion! HTTP/1.1
Host: XXXXXXXXX
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20100101 Firefox/8.0
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://xxxxxxxxx.html

Quickly checking out the referer gave me the sourcecode; the id consists of a timestamp and the request id. The ‘msg’ is a user-changable text, but ‘id’ is javascript-generated.

How to block it?
- Use a regular expression for the query string (very easy)
- Block users with a referer from that nopaste service (very easy, too)
- Block users that do more than X connections within a minute (easy if you have a decent firewall), side-effects might cause large NAT gateways from mobile providers to be blocked, but that’s better than being completely offline, right?

Where to block:
- block as early as possible: in your DPI firewall, web application firewall or loadbalancer
- *not* in every single webserver

Having Fun:
As the WebLOIC runs in the attacker’s browser, there are lots of possibilites:
- redirect attackers to a site known to be monitored by the FBI (explosives, terrorism etc.)
- CSRF, make them post something on a service like facebook or twitter (#iDDoS-site.tdl) and search for their posts. Kindly ask them to stop.
- redirect the attackers to do lots of google searches – they will quickly be blocked by google services
- send a gzip-encoded stream that consumes lots of cpu time and memory on their side, this might even crash the browser
- ‘reflect’ the DDoS to somewhere else (sending 301/302 redirects is pretty low-bandwidth for you)

So in total, WebLOIC was a good idea, but right now rather inefficient and its usage might have unwanted sideeffects…

about:config
browser.urlbar.trimURLs
Doppelklick. 

During the week, we polished up some GLSAs and since sunday, we send these (a lot more to come!):

OpenSSL: Multiple vulnerabilities
Wireshark: Multiple vulnerabilities
Bugzilla: Multiple vulnerabilities
Dovecot: Multiple vulnerabilities
GnuTLS: Multiple vulnerabilities
PHP: Multiple vulnerabilities
vsftpd: Denial of Service
feh: Multiple vulnerabilities
Conky: Privilege escalation
Wget: User-assisted file creation or overwrite
Adobe Flash Player: Multiple vulnerabilities

Thanks for helping out, everyone!

Here are some impressions:

Interessant sind die Statistiken:

Gesamte Updates: 1565
Security: 767
Empfohlen: 718
Optional: 72
YaST: 8

Das CVE-Tracking war im ersten Jahr nicht vollständig, daher sind die Nummer eigentlich etwas höher.

Insgesamte CVE-Einträge: 1447

Top CVE-Kanidaten:

127 IBM Java 5
125 IBM Java 1.4.2
84 kernel
66 SUN Java 1.4.2
76 clamav
68 ethereal
58 mozilla
44 cups
32 mysql
31 libpng
28 freetype2
24 ruby
21 XFree86
20 libexif
18 mailman
18 horde
16 quagga
17 tomcat
16 apache2
15 openssh
15 gd
14 python
13 yast2-packagemanager-devel
13 km_nss
12 openssl
12 samba
11 tk
10 pcre

Interessant, dass der Kernel sogar schlimmer als Mozilla war…ich dachte das wäre unmöglich… :/ Clamav mit 76 Löchern finde ich aber auch eine ziemliche Katastrophe, zumal das ja auch oftmals auf Mailgateways läuft…

Schön, dass dort schnell reagiert wurde.

Jeder kennt das Problem: immer wieder mal benötigt man einen USB Stick mit einem DOS wegen BIOS Updates, muss einen zickigen RAID-Controller flashen oder sonstiges… hier eine Kurzanleitung dazu, wie man einen bootbaren USB-Stick mit FreeDOS erstellt.

Vorbereiten der Umgebung

mkdir -p /tmp/usbboot/exec/file-system
cd /tmp/usbboot
mkdir build && cd build

Tool zum Schreiben der Daten auf USB-Stick herunterladen, entpacken, compilieren

wget "http://prdownloads.sourceforge.net/advancemame/makebootfat-1.4.tar.gz?download" -O - | tar -xvzf -
cd makebootfat*
./configure && make
cp makebootfat ../../exec
cd ..

Nötige FreeDOS-Binaries und MBR herunterladen

wget http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/pkgs/kernels.zip
wget http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/pkgs/commandx.zip
wget http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/pkgs/unstablx.zip
# Kernel.org hat derzeit noch nicht wieder alle Inhalte online; daher Mirror nutzen
#wget http://www.kernel.org/pub/linux/utils/boot/syslinux/syslinux-4.04.tar.gz -O - | tar -xzvf - syslinux-4.04/mbr/mbr.bin
wget http://ftp.uni-ulm.de/mirrors/kernel.org/boot/syslinux/4.xx/syslinux-4.04.tar.gz -O - | tar -xzvf - syslinux-4.04/mbr/mbr.bin
mv syslinux-4.04/mbr/mbr.bin ../exec

Nun extrahiert man die relevanten Dateien aus den .zips und kopiert sie an die passende Stelle:

unzip kernels.zip
unzip commandx.zip 
unzip unstablx.zip
find ./ -name command.com -exec mv '{}' ../exec/file-system ';'
find ./ -name kernel.sys -exec mv '{}' ../exec/file-system ';'
 
for file in fat12.bin fat16.bin fat32lba.bin
do
	find ./ -name $file -exec mv '{}' ../exec ';'
done
 
cd .. && rm -fr build && cd exec

An dieser Stelle kopiert man alle Dateien, die nachher auf dem Stick liegen sollen nach ./file-system. Daraufhin befüllt man den USB-Stick per makebootfat und räumt auf.

./makebootfat -o /dev/sdb -E 255 -1 fat12.bin -2 fat16.bin -3 fat32lba.bin -m mbr.bin ./file-system
cd ../../
rm -fr usbboot

Getestet zuletzt am 29.08.2011 – sofern es nicht mehr funktioniert, bitte kurz kommentiere, dann aktualisiere ich ggfs. den Blogeintrag.