AOit Linux Admin Blog

Verschiedene Kunden haben uns davon berichtet das Ihre Windows PCs durch einen Trojaner infiziert wurden.

Ob Ihr Rechner mit diesem Trojaner infiziert wurde und DNS Einträge umgeleitet werden können Sie wie folgt feststellen:

http://www.dns-ok.de

Alternativ falls der Trojaner mal auch diese Auflösung umschreibt die direkte IP:

http://85.214.11.195/

Seit Anfang November steht OpenBSD 5.0 zur Verfügung und nach einer kurzen Testphase haben wir nun alle Rack Firewalls ausgetauscht.

Etwas was ich sehr an OpenBSD mag sind die seltenen Fehler/Lücken die korrigiert werden müssen. Die Version 4.9 ist seit Mai bisher ohne einen Patch ausgekommen. Und auch die 5.0 musste seit erscheinen noch nicht von uns gepatcht werden.

http://openbsd.org/errata50.html

Wir wurden gerade von einigen Kunden darüber informiert das Hetzner ein Sicherheitsproblem mit dem Kundenlogin hatte/hat.

Weitere Informationen zum Vorfall erhalten Sie über http://hetzner-status.de/

Der eine oder andere wird von der Sicherheitsproblematik schon gehört haben. Es geht darum das der zurzeit verwendete SSL Standard Algorithmus, der in den meisten Browsern und Server aktiv ist, angreifbar ist. Das bedeutet es können unter Umständen im Browser Session Cookies ausgelesen werden um Sicherheitsmechanismen zu umgehen. Aktiv ausgenutzt werden kann dieses zur Zeit durch eine Schwachstelle im Java Plugin.

Derzeit testen wir die Umstellung bzw. die Bevorzugung des RC4 Algorithmus unserer Apache und Nginx Server. Sollten diese Tests ohne Probleme verlaufen werden wir das ganze auch für unsere Wartungskunden ausrollen. Nicht Wartungskunden können sich gerne bei uns melden.

Ich hoffe das sobald wie möglich der TLS 1.1 Standard in den Browsern und auch im OpenSSL Projekt zum bevorzugten Standard wird. Dieser existiert zwar schon seit 2006, aber leider setzen sich neue Standards auch im modernen Zeitalter nur sehr schwer durch.

In den letzten Tagen gab es einen Plesk Bug der uns ganz schön nerven gekostet hat.
Und zwar hat Plesk ein Sicherheitsupdate seiner Mailpakete herausgebracht. Leider
wurde bei diesem Update der Serverhostname des Mailservers verändert und so wurde aus:

mail.example.net -> mail

Das führt natürlich zu Problemen bei vielen Maildiensten (gmx.de, web.de etc.).

Mittlerweile hat sich die Lage wieder entschärft, aber unsere Konsequenz daraus ist
auch den HELO und den Reverse DNS unserer Kunden per Monitoring zu erfassen.

Da Plesk closed Source Software ist, konnten wir nicht ermitteln warum plötzlich nur
noch der Hostname gesetzt wurde. Der FQDN Name (hostname -f) war vollkommen in Ordnung.

http://www.heise.de/security/meldung/Datenpanne-Unesco-entbloesst-Bewerber-im-Netz-1234573.html

Anlässlich dieses Vorfalls möchte ich einmal die technischen Gegenmaßnahmen erläutern die einen solchen Vorfall verhindert hätten. Also zunächst worum ging es genau.

Gegeben sei ein Login Bereich wo nur registrierte und eingeloggte Nutzer Zugriff haben. Nach dem Login kann der Nutzer seine Daten einsehen und ggf. bearbeiten. Der Aufruf seiner Daten erfolgt über folgende URL:

http://example.net/user.php?id=120

oder eine Seite die z.B. mod-rewrite nutzt:

http://example.net/user/120

Wie man sehen kann steht mit hoher Wahrscheinlichkeit die 120 für die Zuordnung zur ID des (MySQL) Datensatzes.

Natürlich kann im Hintergrund auch jede andere Art von persistenter Datenspeicherung erfolgen. Jetzt könnte man mit dieser ID ein wenig rumspielen und den Wert um eins erhöhen oder verringern:

http://example.net/user/121
http://example.net/user/119

Wenn die Anwendung nun nicht prüft ob die ID vom User überhaupt abgerufen werden darf, kann jemand relativ simpel alle Datensätze anderer User auslesen. Und genau das ist auch der Unesco passiert es wurde zwar Authentifiziert (Registrierung und Login) und evtl. sogar der Zugriff gruppentechnisch per ACL autorisiert, aber es wurde vergessen den Zugriff auf die einzelnen Datensätze des entsprechenden Nutzers einzuschränken.

Welche Lösungen gibt es so etwas zu verhindern?

1. Die ID als mehrstellige Zufallszahl ausführen
Das könnte dann so aussehen:

http://example.net/user/eachaeso1tie
http://example.net/user/aimizoh9oosu

Nun ist es für jemanden ohne interne Kenntnisse schwierig weitere IDs auf anhieb zu erraten. Aber auch nicht unmöglich. Denn eine Brute Force Attacke wäre auch hier noch erfolgreich. Auch muss man sich selbst um die Generierung der ID kümmern und dafür sorgen das keine Dubletten generiert werden. Ein weiterer kleinerer Nachteil liegt auch in der Performance. Allerdings kann man Brute Force Attacken sehr leicht erkennen und z.B. nach drei Fehlgeschlagenen abrufen den User sperren.

2. Ordentliche Rechteprüfung ob der Nutzer die Daten überhaupt abrufen darf
Schon etwas aufwendiger je nach zu Grunde liegender Architektur ist die saubere Prüfung ob der Datensatz dem Nutzer gehört.
Richtig sauber wird es dann wenn man auch hierbei fehlgeschlagene Abrufe loggt und somit ggf. komprimierte Logins aufdeckt und frühzeitig sperren kann.
Bei einem öffentlichen Dienst mit freier Registrierung ist es natürlich nur eine Frage der Zeit bis der Angreifer ein frisches Konto hat.

Der Grund warum so etwas immer wieder vorkommt ist wahrscheinlich die trügerischer Sicherheit das der Login schon autorisiert ist und der Kunde/Endnutzer nicht weiß wie schnell man seine Daten ausspähen kann. Bei Cakephp lassen sich diese Konzepte wunderbar z.B. in das entsprechende Model unterbringen/abstrahieren.

Der eine oder andere wird es sicherlich schon mitbekommen haben, aber zur Sicherheit einmal die Links zu den Patches einer schweren Sicherheitslücke die sowohl xtcModified wie auch xtCommerce betrifft.

Ein Angreifer kann hierdurch das Administrator Passwort ändern.

http://www.xt-commerce.info/index.php?_m=downloads&_a=viewdownload&downloaditemid=58

http://www.xtc-modified.org/forum/topic.php?id=11242