Skip to content

Kommentare zu PostgreSQL, Ad-Blockern, AT&T Passwortregeln und mehr

Die Themen heute: PostgreSQL ergreift vor der Veröffentlichung eines Sicherheitsupdates eine zweifelhafte Schutzmaßnahme, Ad-Blocker können vor Drive-by-Infektionen schützen, und AT&T verwendet unsichere Passwortregeln. Außerdem noch zwei kurze Lesetipps:

Der Schädling "Flashback" sorgte vor gut einem Jahr dafür, dass die Gefahren von Schadsoftware auch auf dem Mac bekannt wurden: Er baute ein für Mac-Verhältnisse riesiges Botnet auf und war der erste Mac-Schädling, der eine Drive-by-Infektion nutzte, und das sogar vollständig ohne Benutzerinteraktion. Brian Krebs konnte nun den mutmaßlichen Entwickler von Flashback aufdecken, einen 30 Jahre alten Einwohner von Saransk, der Hauptstadt der russischen Region Mordwinien.

Und es gibt etwas Neues zu den Angriffen über Java: Shinsuke Honjo von McAfee berichtet über eine JAR-Datei, die gleich mehrere Exploits enthält. Also sozusagen eine JAR-Datei, sie alle zu knechten. Könnte mal jemand einen Hobbit den Java-Quellcode geben? Nur die JAR-Datei zu entsorgen ist in diesem Fall wohl zu wenig.

PostgreSQL mit zweifelhafter Schutzmaßnahme

Am 4. April wurde von PostgreSQL ein Sicherheitsupdate veröffentlicht, mit dem eine kritische Schwachstelle behoben wurde: Jeder mit Zugriff auf den Port, an dem der PostgreSQL-Server lauscht, konnte Dateien auf dem Server zerstören, und unter bestimmten Bedingungen war einem Benutzer die Ausführung beliebigen Codes möglich. Details verrät eine FAQ.

Das ist aber noch nicht weiter erwähnenswert, jedenfalls nicht in einem "Standpunkt"-Text. Das besondere an diesem Update war eine in meinen Augen zweifelhafte Schutzmaßnahme, die vor der Veröffentlichung des Updates ergriffen wurde: Am 28. März wurden die Aktualisierungen der öffentlichen Quelltext-Repositories gesperrt, nur noch registrierte Entwickler hatten Zugriff auf die Änderungen der Quelltexte.

Damit sollte verhindert werden, dass die Schwachstelle vor der Veröffentlichung des Updates bekannt wird. Auch die Commit-Log-E-Mails wurden während der Sperre nicht zugestellt, da darüber die Änderungen zum Beheben der Schwachstelle ebenfalls bekannt geworden wären. Der Hintergedanke dabei: Die Schwachstelle würde normalerweise durch das Entwickeln der Patches bekannt, bzw. durch die erste entsprechende Fehlermeldung. Ab diesem Zeitpunkt können die Cyberkriminellen einen Exploit für die Schwachstelle entwickeln. Die Betreiber der PostgreSQL-Server können die Schwachstelle aber erst beheben, wenn der Patch fertig und ausreichend getestet ist und die Binärdateien vorliegen. Durch das Sperren der Veröffentlichung der Änderung wurde den Cyberkriminellen dieser Zeitvorsprung genommen.

Was bringt das?

Diese Maßnahme ist aus meiner Sicht nicht wirklich zweckmäßig. Vor allem, weil die Änderungen am Quelltext nach der Veröffentlichung des Updates wieder für alle online gestellt wurden (was aber im Grunde egal ist, da die Änderungen auch durch einen simplem Vorher-Nachher-Vergleich aufgedeckt werden könnten). Und das aus zwei Gründen:

Erstens: Die Cyberkriminellen haben oft genug bewiesen, dass sie durch den Vergleich von gepatchten und ungepatchten Binärprogrammen bzw. der Analyse der binären Patches die zugehörigen Schwachstellen erkennen und Exploits dafür ableiten können. Nicht umsonst gab es lange Zeit nach Microsofts Patch-Tuesday den "Exploit-Wednesday" oder "-Thursday", an dem die ersten Exploits für die gerade gepatchten Schwachstellen die Runde machten. Die Cyberkriminellen brauchen also gar keinen Zugriff auf den Quelltext, um einen Exploit zu entwickeln. Zumal sie ja in diesem Fall nach der Veröffentlichung der Ankündigung der Updates wieder Zugriff auf den Quelltext haben.

Und damit komme ich zum zweiten Grund: Die am "Exploit-Wednesday" oder "-Thursday" verbreiteten Exploits waren meist ziemlich erfolgreich, da die Patches eben veröffentlicht, aber noch nicht überall installiert waren. Ich erinnere in diesem Zusammenhang nur an den RPC-Wurm Conficker, der erst nach der Veröffentlichung eines Updates für die ausgenutzte Schwachstelle veröffentlicht wurde, aber eine extreme Verbreitung erreichte.

Wenn die Cyberkriminellen es wirklich darauf anlegen würden, könnten sie nach der Veröffentlichung der Updates in Kürze einen Exploit entwickeln und die ungepatchten PostgreSQL-Server angreifen.

Glashaus mit Kies-Haufen davor

Die PostgreSQL-Entwickler hielten die Sperre während der Patch-Entwicklung und vor der Veröffentlichung des Updates für nötig. Das kann man so sehen, auch wenn ich mich frage, ob man dann nicht sämtliche Quelltexte offline nehmen sollte, irgendwo wird schließlich immer an einem kritischen Patch gearbeitet. Und manchmal wird die Brisanz eines Fehler oder Patches ja nicht mal von Anfang an erkannt. Was, wenn ein Cyberkrimineller schneller als die Entwickler merkt, dass da eine kritische Schwachstelle existiert? (Das ist jetzt nicht ernst gemeint, denn das Closed Source, und genau darum würde es sich dann ja handeln, nicht sicherer ist, ist ja ausreichend bewiesen - es nur eine Anregung, sich darüber mal ein paar Gedanken zu machen!)

Kritischer sehe ich das Aufheben der Sperre sofort nach der Ankündigung des Updates. Hätte man damit nicht einige Zeit warten müssen, bis die Updates eine gewisse Verbreitung gefunden haben, wenn man sich schon zur außergewöhnlichen Maßnahme der Sperrung entschließt? Mit der Sperre macht man deutlich, für wie gefährlich man die Schwachstelle hält - und das macht sie für die Cyberkriminellen natürlich erst recht interessant. Und statt in einem Vorher-Nachher-Vergleich nach den relevanten Codeänderungen suchen zu müssen, müssen sie nun nur die entsprechenden Commits untersuchen.

Irgendwie erinnert mich diese Aktion an jemanden, der in einem Glashaus sitzt (= es gibt Schwachstellen), sich eine Ladung Kies davor kippen lässt (= der Quelltext samt Änderungen ist öffentlich) und dann schreit "Werft doch!". Laut Sprichwort soll man ja nur nicht selbst mit Steinen werfen, wenn man im Glashaus sitzt. In der Realität ist es aber auch sehr empfehlenswert, niemand anderen zu provozieren, von außen mit Steinen zu werfen.

Ach, und ein letzter Punkt noch: Woher nehmen die Entwickler die Sicherheit, das kein schwarzes Schaf unter ihnen ist, dass die Änderungen weitergibt, zum Beispiel verkauft? 0-Day-Exploits bringen schließlich gutes Geld auf dem Schwarzmarkt! Bei einem Open-Source-Projekt würde ich eigentlich schon aus Sicherheitsgründen davon ausgehen, dass eben nicht alle Beteiligten wirklich so brav sind, wie sie zu sein vorgeben.

Ad-Blocker als Schutz vor Drive-by-Infektionen

Das die Cyberkriminellen gerne Ad-Server kompromittieren, um darüber Code für Drive-by-Infektionen zu verbreiten, hatte ich bereits des öfteren erwähnt. Aktuell warnt das Bundesamt für Sicherheit in der Informationstechnik (BSI) vor laufenden Angriffen. Das Gefährliche an solchen präparierten Werbeanzeigen: Da sie auf vielen "vertrauenswürdigen" Websites eingeblendet werden, kann auch der Besuch einer an und für sich harmlosen Website zur Infektion des eigenen Rechners führen.

Sofern Sie noch keinen Ad-Blocker installiert haben, sollten Sie mal über eine Installation nachdenken. Denn ein Ad-Blocker, der dafür sorgt, dass die Werbung gar nicht erst geladen wird, sorgt gleichzeitig dafür, dass der eingeschleuste Schadcode den eigenen Rechner nicht erreicht. Ad-Blocker, die die Werbung laden, dann aber nicht anzeigen, könnten dabei die Schadsoftware durch lassen, da die ja nicht angezeigt, sondern nur ausgeführt werden muss.

Damit wiederholt sich ein Effekt, den ich bei Mails mit schädlichen Anhängen oder Links schon seit längerem beobachte: Meist fischt der Spamfilter diese Mails bereits raus, bevor sie überhaupt auf Schadsoftware etc. geprüft werden.

Ach ja: In den meisten Fällen schützt auch ein Rechner auf dem aktuellen Stand vor einer Drive-by-Infektion, da meist "nur" Exploits für längst behobene Schwachstellen eingesetzt werden. Drive-by-Infektionen mit 0-Day-Exploits sind relativ selten, die werden meist erst für gezielte Angriffe genutzt und erst wenn sie dabei entdeckt wurden von den Entwicklern der Drive-by-Infektionen übernommen. In diesem Sinne: Halten Sie System und Anwendungen aktuell, und verzichten Sie möglichst auf die ebenso unsicheren wie bei den Cyberkriminellen beliebten Programme Java, Adobe Reader und Flash Player. Was nicht installiert ist, kann auch nicht angegriffen werden!

Und auch bei den Ad-Servern sieht es ähnlich aus: Die Cyberkriminellen nutzen meist bekannte und längst behobene Schwachstellen in der Ad-Server-Software aus, vor allem OpenX scheint dabei sehr beliebt zu sein. Falls Sie also einen Ad-Server betreiben, achten Sie darauf, die Software auf dem aktuellen Stand zu halten. Und wenn das zur Zeit nicht so ist, sehen Sie sich den Server mal genau an. Evtl. verteilt der mehr als nur Werbung.

Unsichere Passwortregeln

Eigentlich verfasst man Passwortregeln, damit die Benutzer sichere Passwörter wählen müssen. Man kann aber auch Regeln aufstellen, die die Sicherheit verschlechtern, wie es nun AT&T getan hat: Zu den "Password restrictions" gehört als letzter Punkt

"The password can't contain obscene language"

Mal abgesehen davon, dass die Frage, was denn nun "obscene" ist, jeder anders beantworten wird, ist diese Regel auch gefährlich, da sie die Menge der möglichen Passwörter unnötig einschränkt. Denn da die "obscene" Wörter aus Wörterbüchern schon wegen ihrer Eigenschaft "steht im Wörterbuch" zurückgewiesen werden sollten, betrifft es ja nur sichere, d.h. irgendwie zusammengewürfelte Passwörter, die zufällig etwas enthalten, was AT&T für "obscene" hält.

Und in der Tat wurde diese Regel von Randy Janinda, einem Twitter-Techniker, entdeckt, als sein zufällig erzeugtes Passwort zurückgewiesen wurde.

Ach so: Hätte ich bei AT&T ein Benutzerkonto, hätten die mir inzwischen schon erklären dürfen, wer sich denn durch das Passwort gestört fühlen könnte. Denn das darf eigentlich nur der Benutzer kennen. Auf dem Server darf es gar nicht als Klartext gespeichert sein, und an der Hotline wird man ja wohl hoffentlich auch nicht nach dem Passwort fragen. Wo also liegt bei AT&T das Passwort in Klartext vor? Da drängt sich doch der Verdacht auf, dass man da nicht nur ein Problem mit "obscene" Passwörtern hat, sondern auch mit der Sicherheit.

Carsten Eilers

Trackbacks

Keine Trackbacks