Zeitserver: Sicherheitslücken in NTP
22.12.2014 - In der Referenzimplementierung des Network Time Protocol (NTP) wurden mehrere Buffer Overflows gefunden, die die Ausführung von Code auf NTP-Servern erlauben.
Die Entwickler der NTP-Software haben eine Sicherheitswarnung herausgegeben. Demnach wurden mehrere Buffer Overflows gefunden, die es einem Angreifer erlauben, Code auf betroffenen Servern auszuführen. Nutzer des NTP-Daemons sollten schnellstmöglich updaten. Zur Zeit ist die Webseite des NTP-Projekts überlastet, sie lässt sich aber über den Google-Cache abrufen.
Zeit setzen über das Internet
Das Network Time Protocol (NTP) dient dazu, die Uhrzeit eines Systems über das Internet zu stellen. Meistens kommt dabei die Referenzimplementierung von NTP zum Einsatz, die sowohl einen Client als auch einen Server bereitstellt. Der NTP-Daemon ist dabei auf vielen Unix-Systemen in der Standardkonfiguration installiert. Der Daemon sorgt zum einen dafür, dass die Uhrzeit in regelmäßigen Abständen geprüft und bei Bedarf neu gesetzt wird, zum anderen kann er auch gleich für weitere Systeme die Uhrzeit bereitstellen.
Entdeckt wurden die Sicherheitslücken von Neel Mehta und Stephen Roettger vom Google-Sicherheitsteam. Neel Mehta hatte bereits den Heartbleed-Bug entdeckt. Neben drei Buffer Overflows an verschiedenen Stellen im NTP-Code wurden noch drei weitere Sicherheitslücken gefunden und behoben. Das NTP-Projekt hat die Version 4.2.8 seiner Software veröffentlicht, die alle Lücken behebt. Wer den NTP-Daemon (ntpd) betreibt, sollte die Software umgehend aktualisieren. Anschließend muss auch sichergestellt werden, dass ntpd neu gestartet wurde. Laut der Webseite Threatpost gibt es bereits öffentlich verfügbare Exploits, die die Lücken ausnutzen.
Die Buffer Overflows haben die CVE-IDs CVE-2014-2014-9295 erhalten. Weiterhin wurden an verschiedenen Stellen im Code schwache Zufallszahlen genutzt (CVE-2014-9293, CVE-2014-9294) und in einer Funktion wurde beim Auftreten von Fehlern der Programmablauf nicht abgebrochen (CVE-2014-9296).
NTP-Protokoll generell problematisch
Das NTP-Protokoll stammt aus den 80er-Jahren und hat in der heutigen Zeit mit einigen Problemen zu kämpfen. NTP-Abfragen sind unverschlüsselt und üblicherweise nicht kryptographisch authentifiziert. Damit sind Man-in-the-Middle-Angriffe auf eine NTP-Verbindung problemlos möglich. Zwar gibt es ein Authentifizierungsprotokoll für NTP, aber es wird selten genutzt und ist auch nicht sicher.
Im Oktober zeigte ein Sicherheitsforscher auf der Black Hat Europe, wie man mit Hilfe gefälschter NTP-Antworten den Schutz des HTTP-Strict-Transport-Security-Protokolls (HSTS) aushebeln kann.
NTP-Server werden auch häufig für sogenannte Reflection-Angriffe genutzt. Dabei wird ausgenutzt, dass das von NTP verwendete UDP-Protokoll ein verbindungsloses Protokoll ist. Ein Angreifer kann ein Paket mit einer gefälschten Absenderadresse an einen NTP-Server schicken, die Antwort landet dann beim Opfer. Wenn die Antwort größer als die Anfrage ist kann man damit Denial-of-Service-Angriffe verstärken. Auch DNS wird gerne für Reflection-Angriffe eingesetzt.
TLS als Alternative zu NTP
Eine Alternative zu NTP ist die Möglichkeit, die Uhrzeit über TLS zu setzen. Denn ein TLS-Paket enthält immer auch einen Zeitstempel (je nach Server muss diese allerdings nicht immer korrekt sein). Das von Jacob Appelbaum entwickelte Tool tlsdate kann hierfür genutzt werden.
POODLE kann auch TLS betreffen
Vor knapp zwei Monaten machte die sogenannte POODLE-Sicherheitslücke Schlagzeilen. Durch eine geschickte Ausnutzung des Paddings von Verbindungen mit dem uralten SSL-Protokoll Version 3 (SSLv3) konnte ein Angreifer unter Umständen mit Hilfe einer Man-in-the-Middle-Attacke bestimmte Inhalte entschlüsseln. Problematisch wurde das ganze deshalb, weil alle gängigen Browser bei Verbindungsfehlern mit modernen TLS-Versionen einen erneuten Verbindungsaufbau mit älteren Protokollen versuchen.
Die relativ simple Empfehlung nach POODLE lautete: SSL Version 3 muss abgeschaltet werden. Firefox hat das in der letzten Version umgesetzt, Chrome plant es für Version 40 und auch die meisten Serverbetreiber haben SSL Version 3 abgeschaltet. Doch wie Google-Entwickler Adam Langley nun herausgefunden hat, ist das Problem damit noch nicht aus der Welt geschafft.
Die POODLE-Lücke betrifft nur die alte SSL-Version 3, weil dort das Padding, also die Füllbytes, die einen Datenblock auf eine bestimmte Größe bringen, beliebige Werte enthalten können. In TLS wurde dies geändert, und es ist genau definiert, welche Werte das Padding enthalten muss. Der Mozilla-Entwickler Brian Smith hatte in einer Mailinglisten-Diskussion um die POODLE-Lücke darauf hingewiesen, dass es möglich ist, dass manche TLS-Implementierungen dies nicht beachten und weiterhin beliebige Padding-Bytes akzeptieren. Das ist laut der TLS-Spezifikation sogar erlaubt, denn das Prüfen der Padding-Bytes ist optional. Smit hatte selbst dieses Problem vor längerer Zeit in der Bibliothek NSS entdeckt und behoben.
Langley hatte jetzt die Befürchtung, dass nicht nur alte NSS-Versionen von diesem Problem betroffen sind und entwickelte einen Scanner, mit dem er nach Servern suchte, die von diesem Problem betroffen sind. Dabei stellte sich heraus, dass auch Hardware der Firma F5 von diese Schwachstelle hat. Ebenso betroffen sind Produkte der Firma A10. Für die Produkte beider Hersteller soll es in Kürze Firmwareupdates geben. Die Lücke hat die ID CVE-2014-8730 erhalten. Langley weist darauf hin, dass möglicherweise noch weitere Produkte von dem Problem betroffen sind. Er fand neben den F5- und A10-Produkten noch Geräte der Firma Citrix, die ebenfalls die Padding-Spezifikation von TLS nicht korrekt prüfen, allerdings akzeptieren diese nur Null-Bytes, was zwar nicht dem Standard entspricht, aber keine Angriffe ermöglicht.
Seitenbetreiber können mit dem SSL-Labs-Test der Firma Qualys prüfen, ob ihre eigenen Webseiten betroffen sind. Ivan Ristic, der Betreiber des SSL-Labs-Tests, schreibt, dass zur Zeit etwa zehn Prozent der Server im Netz diese Neuauflage der POODLE-Lücke aufweisen.
Es ist nicht das erste Mal, dass TLS-Produkte von F5 Probleme bereiten. So fiel vor einiger Zeit auf, dass deren TLS-Loadbalancer ein Problem mit Handshakes haben, deren Größe sich zwischen 256 und 512 Bytes befindet. Da diese Geräte weit verbreitet sind und zahlreiche Nutzer keine Updates einspielen, wurde dafür sogar eine eigene TLS-Erweiterung geschaffen, die den Handshake entsprechend vergrößert, um das Problem zu vermeiden.
Adam Langley nutzte die Gelegenheit noch, um darauf hinzuweisen, dass generell alle TLS-Verbindungen, die nicht TLS 1.2 mit authentifizierter Verschlüsselung nutzen, problematisch sind und als kryptographisch gebrochen gelten. Inzwischen gibt es eine ganze Reihe bekannter Angriffe, die auf die Padding-Schwächen der CBC-Verfahren abzielen, darunter neben POODLE auch die BEAST-Attacke und die Lucky-Thirteen-Attacke. In älteren TLS-Versionen steht als Alternative zu CBC nur das ebenfalls problematische RC4 zur Verfügung. Wirkliche Sicherheit bieten zur Zeit nur die Verfahren, die AES mit dem Galois/Counter-Modus (GCM) einsetzen - und die stehen nur für TLS 1.2 zur Verfügung.
Mailserver unter Shellshock
2014-10-25 - Der Schock sitzt tief in den Knochen der Mailserver - Shellshock ist noch nicht vorbei.
Nach Informationen von heise Security stehen derzeit vermehrt Mailserver im Fokus der Cyber-Kriminellen, die durch Lücken im Mailserver auf die bash des Betriebsystems zugreifen wollen. Dabei übertragen sie speziell präparierte Mails an die SMTP-Server, in deren Headern an mehreren Stellen Shell-Befehle stecken, mit denen ggf. die Shellshock-Schwachstelle ausgenutzt werden können. Auf einem ungeschützten System wird dieser Code unter Umständen ausgeführt, wenn der Mailserver eine Shell mit einem dieser Header-Werte ausführt – zum Beispiel, um die Metadaten der Mail an einen Spam-Filter weiterzugeben.
Seit geraumer Zeit existiert ein Exploit für Postfix, prinzipiell können aber auch andere Server wie qmail anfällig sein. Server-Betreiber sollten daher auf Nummer sicher gehen und die in der Bash klaffenden Lücken durch ein passendes Update schließen. Wie schon bei den Attacken auf Webserver versuchen die Angreifer auch im aktuellen Fall, eine Backdoor einzuschleusen. Infizierte Server melden sich in einem IRC-Channel, in dem sie auf weitere Instruktionen der Angreifer warten.
Gartner Report - 97% aller Firmen mit Malware verseucht
2014-10-21 Basierend auf den Ergebnissen von FireEye, dass in 97% aller Firmen Malware zu finden ist, gibt es einen neuen Gartner Report zu diesem Thema.
Im Gartner Report "Malware is Already inside Your Organization: Deal With It" finden Sie unter anderem folgende Empfehlungen:
- Verteilen Sie Ihre Investments über den Security Life Cycle
- Gehen Sie davon aus, dass Ihr Organisation schon durch Malware infiziert ist
- Sehen Sie sich neue Lösungen und Tools an, die Ihnen helfen, die komplexen Aufgaben im Security Bereich einfacher zu lösen.
So schützen Sie sich vor dem Poodle
2014-10-15 - Der kürzlich veröffentlichte Poodle-Angriff erzwingt einen Rückfall einer verschlüsselten Verbindung auf das längst veraltete Protokoll SSLv3. Lässt sich das verhindern?
Ja - meistens!
Ein Poodle Angriff erzwingt in der Verschlüsselung einen Rückfall auf das veraltete Protokoll SSLv3. Aus Kompatibiltätsgründen unterstützen das nahezu alle Browser und auch die Server noch. Wirklich benötigt wird es jedoch eigentlich nicht mehr. Der beste Schutz ist also: abschalten.TLS v1.0 ist seit mehr als 10 Jahren Standard - alle gängigen Client und Server Produkte unterstützen sowohl dieses Protokoll als auch der Nachfolgeversionen.
Schützen Sie Ihren Browser
SSLv3 wird heutzutage nicht mehr benötigt. Bei Internet Storm Center finden Sie eine einfache Seite, die testet, ob Ihr Browser anfällig für Poodle-Angriffe ist. Relativ einfach geht das Abschalten von SSLv3 in Firefox. Dort öffnet man in der Adressleiste about:config, sucht dann nach tls und stellt die Option security.tls.version.min auf 1.
Dies ist im Grunde ungefährlich - Sie kommen damit dem Browser-Hersteller nur etwas zuvor. Mozilla hat bereits angekündigt, SSLv3 in Firefox 34, der am 25. November veröffentlicht werden soll, standardmäßig abzuschalten.
In Chrome ist es ein bisschen aufwändiger, da man den Browser mit der Kommandozeilen-Option --ssl-version-min=tls1 starten muss. Am einfachsten legt man sich einen entsprechenden Shortcut an. Im Internet Explorer kann man in den Internetoptionen unter Erweitert SSL 3.0 verwenden abwählen – und bei der Gelegenheit auch gleich TLS 1.1 und 1.2 aktivieren.
Server und andere Dienste
Alle gängigen Webserver unterstützen in den SSL Optionen TLS in verschiedenen Varianten. Bei anderen Programmen mit verschlüsselter Übertragung sollte Ihr Softwarehersteller auch auf dem neuesten Stand sein.
Quelle: Heise.de (http://www.heise.de/security/meldung/So-wehren-Sie-Poodle-Angriffe-ab-2424327.html)
ShellShock - noch drei weitere Sicherheitslücken
Jetzt geht es Schlag auf Schlag: immer mehr Securitylücken werden in der Bash gefunden.
CVE-2014-6271 ... die "Originallücke"
CVE-2014-7169 ... die schon seit einigen Tagen bekannte zweite Lücke
CVE-2014-7186 ... neuer Off-by-One-Fehler im Parser-Code
CVE-2014-7187 ... neuer Off-by-One-Fehler im Parser-Code
CVE-2014-6277 ... ein Bug im ASLR - Address Space Layout Randomizer der Bash
Für die ersten beiden BUGs gibt es von den Herstellern (RedHat, Oracle,...) schon die ersten Patches. RedHat behauptet, dass auch die zwei Off-by-One Fehler im Patch vom Freitag, 26. September 2014 behoben werden - so ganz sicher ist das aber noch nicht.
Testen Sie, ob auch Ihre Bash anfällig ist!
Unter https://github.com/hannob/bashcheck finden Sie ein Script, mit dem Sie feststellen können, welche der bis jetzt bekannten Sicherheitslücken in der Bash bei Ihnen noch nicht behoben sind.