Dipl.-Inform. Carsten Eilers

Los geht es mit Nachrichten zu Java. Schlechten natürlich, oder hätten Sie etwas anderes erwartet? Zunächst einmal hat Juan Vazquez einige neue Java-Exploits für das Metasploit-Framework veröffentlicht. Dabei handelt es sich zwar nicht um 0-Day-Exploits, die Schwachstellen wurden bereits in Java 7 Update 9 behoben. Aber immerhin lässt sich damit bei einem Test prüfen, ob Java auf dem aktuellen Stand ist oder nicht. Vermutlich wird viel zu oft letzteres der Fall sein.

Die aktuelle 0-Day-Schwachstelle (zu der es übrigens eine neue Analyse von Microsoft gibt) wurde zwar teilweise behoben und der aktuelle Exploit funktioniert auf gepatchten Systemen nicht mehr, das stört die Angreifer aber nicht. Im Rahmen eines "Wasserloch-Angriffs" wurde nun die Website der "Reporter ohne Grenzen" kompromittiert und mit den Exploits präpariert. Urheber soll der inzwischen schon übliche Verdächtige sein: China.

Was übrigens die Java-Updates betrifft: Die nutzt Oracle gerne, um Browser-Toolbars von Drittherstellern zu verbreiten. Nicht gerade die feine englische Art. Aber für die ist Oracle ja auch nicht bekannt. Aber was soll die Aufregung, die geben sich halt nur alle Mühe, die Leute von der Java-Nutzung abzubringen. Was im Sinne der Sicherheit ja eigentlich zu begrüßen ist. Kein installiertes Java, keine Angriffe darüber - was will man mehr? Also, Oracle: Immer fleißig weitermachen mit der Aktion "Benutzer vergraulen"!

Wissen Sie eigentlich, wer sonst noch Tools von Drittherstellern mit seinen Sicherheitsupdates verbreitet? Adobe! Die liefern mit dem Adobe Reader X den McAfee Virenscanner aus. Eine auf den ersten Blick sehr gute Idee, wer den Adobe Reader installiert, fängt sich früher oder später Schadsoftware ein. Und auch auf den zweiten Blick noch gut: Wenn es die Benutzer vom Installieren des gesamten Pakets abhält, verringert das wieder die Angriffsfläche. Wunderbar!

Aber kommen wir nun zum Schluss noch zur schlechtesten der schlechten Java-Nachrichten: Adam Gowdiak hat berichtet, dass die von Oracle mit Java 7 Update 10 eingeführten Sicherheitseinstellungen umgangen werden können. Ein bösartiges, unsigniertes Java-Applet wird unter Umständen auch dann uneingeschränkt ausgeführt, wenn unsignierter Code eigentlich gar nicht oder erst nach Nachfrage ausgeführt werden sollte.

10 Jahre SQL Slammer

Am 25. Januar 2003 machte sich SQL Slammer auf den Weg durch die MS SQL Server im Internet, auf denen ein damals bereits 6 Monate altes Update nicht installiert war. Zum zehnjährigen Jubiläum erinnert F-Secure an den Wurm, der einigen Schaden anrichtete: Die Flugverkehrskontrolle in den USA hatte Probleme, ein Atomkraftwerk in Ohio wurde infiziert, und der Telefonnotruf in Seattle sowie die Geldautomaten der Bank of America fielen aus.

David Litchfield, der die Schwachstelle entdeckt und den später vom Wurm missbrauchten Exploit geschrieben hat, erinnert sich in einem Artikel auf Threat Post an die damaligen Ereignisse.

Was man so auf GitHub findet...

Am Mittwoch wurde auf GitHub eine neue Suchfunktion bereitgestellt. Damit lassen sich unter anderem die Code-Repositories sehr viel komfortabler durchsuchen. Und es dauerte nicht lange, bis diese Funktion ausgiebig genutzt wurde. Vor allem, nachdem bekannt wurde, was man damit alles finden kann. Zum Beispiel private SSH- und SSL-Schlüssel, Konfigurationsdateien oder auch das SSH-Passwort für ein Produktivsystem. Am Freitag erschien im GitHub-Blog eine Warnung vor der Veröffentlichung geheimer Daten, und es gibt auch eine Anleitung zum Entfernen versehentlich hochgeladener sensitiver Daten. Das kann man sich aber eigentlich fast sparen, denn die Daten sind sowieso kompromittiert und müssen ersetzt werden.

Und wenn das nächste mal was zu GitHub hoch geladen wird sollten keine privaten Schlüssel dabei sein. Die erkennt man ganz einfach am Text
PRIVATE KEY
am Anfang des Schlüssels. Der öffentliche Schlüssel wird entsprechend als
PUBLIC KEY
markiert. Der Rest ist ganz einfach: "PRIVATE" bedeutet privat halten, "PUBLIC" ab in die Öffentlichkeit.

Das kann ja eigentlich nicht so schwierig zu unterscheiden sein, oder? Ich vermute daher, dass die meisten sensitiven Daten auf GitHub gelandet sind, weil ganze Verzeichnisse ohne Rücksicht auf ihren Inhalt hoch geladen wurden. Das würde nämlich auch die ebenfalls gefundenen Shell-Histories wie zum Beispiel .bash_history erklären: Diese Dateien sind normalerweise unsichtbar und wohl kaum absichtlich hoch geladen worden. Wird jedoch ein komplettes Verzeichnis kopiert, werden auch die "unsichtbaren" Dateien erfasst.

Carsten Eilers