Category Archives: Security


D-Link DGS-1210 Vulnerabilities

We’ve used D-Link DGS-1210-48 at work for a while, and found some vulnerabilites by accident. We decommissioned all of them about two years ago, so it’s already overdue to publish this. Enjoy!

The first two are relevant (tested) for hardware revision A1, Firmware before V 2.03.001. See

Searching throught some PDFs, this also seems relevant for DGS-3200 and DGS-1500. D-Link clearly has not a good security history., so I cannot recommand them from a security point of view at all, as it seem they don’t even have a proper testing process.

#1 Information/Config Leak

Just download the device Configuration directly from http://IP/config.bin

It took them 11 months to release a new firmware to fix this.

#2 Denial of Service

Just download the configuration (/config.bin) 23 times. It will crash due to a memory leak and reboot after a while.

#3 Time-based Security Tokens

The “gambit” value you get after logging into the web interface is not random, but time-based.

See for yourself, unix timestamp vs. “gambit”:

1328333368 jdfdkdbdadedbdjdjdjdcdkdadkdbgegngjgogkdlgfgjgogdh
1328333369 jdfdkdbdadedbdjdjdjdddkdadkdbgegngjgogkdlgfgjgogdh
1328333370 jdfdkdbdadedbdjdjdjdedkdadkdbgegngjgogkdlgfgjgogdh

This issue is not fixed AFAIR. It’s probably possible to calculate valid gambit tokens without a valid login, but I haven’t put much time into this.

#4 Directory Traversal via HTTP

This is not your usual ../../ traversal, but try this:


<134> Jan 1 00:00:00 2009:SYSTEM-6:Side Fan is in low speed.
<130> Jul 25 15:40:35 2012:SYSTEM-2:System started up
<134> Jul 25 15:40:49 2012:LinkStatus-6:Port 48 link up, 100Mbps FULL duplex


There are some more interesting files available. 😉

#5 Directory Traversal via TFTP

Found in 2015, not sure on which firmware version – no details here, enjoy looking. 😉

Review of Open-E DSS v7

Initially, we were looking for a 10GE-iSCSI storage solution that would do synchronous or at least memory-synchronous mirroring of data to a second system and automatic failover. We planned to use the system as storage backend for a few dozens VMs, and wanted the storage to be highly available on a shared IP. Active-Active supported seemed pretty awesome too, and the system should allow seamless failover.

However, some vendors didn’t provide this option, others were too expensive and the project was an open bidding, so we had to be cheap. The only viable options seemed to be building something ourselves or buying Open-E from a distributor that would take care of the hardware part. They were also offering 24/7 support. It sounded pretty good, and our distributor was saying he did a couple of installations with it, so we went for it. The system consisted of:

Continue reading

Eindeutigkeit von IP-Adressen bei Unitymedia nicht gegeben

Bis vor wenigen Tagen konnte man bei Unitymedia anonym oder mit der Adresse eines anderen Internetteilnehmers im Internet surfen. Sofern man einen Linuxrechner mit dem von Unitymedia bereitgestellen Cisco-Router EPC3212 verbunden hatte (etwa als Firewall), ging das sehr leicht, und wird im Folgenden beschrieben. Linux-Grundkenntnisse werden vorausgesetzt. Da dies nicht mehr funktioniert, sehe ich kein Problem damit, hier eine Anleitung zu veröffentlichen. 🙂

Zuerst guckt man, welche IP und welches Subnetz man im Unitymedia-Netz derzeit nutzt:

Continue reading

Defending against & having fun with WebLOIC

Lately, one of the websites under my protection was being DDoSed by a well-known trouble-making party whose name shall not be released and stay anonymous. Another party that is monitoring the web for threats against our websites notified me that a DDoS was currently being  started. It seemed that the attackers were spamming a link to an automatically starting WebLOIC via mail and tricked others with a variation of methods to open the URL so that they would automatically participate in the DDoS.

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
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… 😉

Gentoo Linux Security Weekend

Last weekend, Gentoo Linux developers a3li and keytoaster came around and with help from p-y and underling via IRC, we killed the huge backlog of open CVEs in our tracker, voted on about 100 security bugs, drafted several dozens of GLSAs and were hunting bugs on GLSAMaker2. We also had good company from (non-security) developer idl0r on saturday. 🙂

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:






byebye, SLES 9

Heute kam wenig ĂŒberraschend eine Mail von Novell, dass der SLES 9 Support nun nach 7 Jahren zu Ende ist – außer man ist LTS Kunde – was wohl ziemlich teuer wird und nur fĂŒr Großunternehmen Sinn macht. SLES9 ist so dermaßen angegraut, beim Blick auf die Paketversionen wird man schon leicht Nostalgisch… ;D


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…