Ein GHOST geistert durch die GLIBC
29.01.2015 In den Funktionen von gethostbyname bzw. gethostbyname2 der zentralen GLIBC Bibliothek gibt es einen Buffer Overflow, der aktuell als "GHOST" bekannt wird.
Die Linux Welt kommt in der letzen Zeit nicht zur Ruhe - immer neue Security Lücken werden entdeckt. Was sich so anhört als wäre das grundsätzlich schlecht, hat auch etwas gutes: Bekannt gewordene Lücken werden unter Linux sehr, sehr schnell behoben. Bei anderen Herstellern - wie Microsoft, Apple, Adobe und auch Oracle - ist dies nicht unbedingt so. Da werden bekannte Lücken erst nach vielen Monaten (oder Jahren) behoben.
In GLIBC 2.2 vor der Release 2.18 kann ein Buffer Overflow erzeugt werden, der dazu genutzt werden kann, Code einzuschleusen (siehe auch CVE-2015-0235). Der Fehler im Code wurde anscheinend im November 2000 eingebaut und im Jan 2013 von SuSE Entwicklern gefunden und behoben. Allerdings haben die Entwickler die Auswirkungen des Fehlers falsch eingeschätzt (nicht als Securityrelevant). Aus diesem Grund ist der Fehler in älteren Linux Distributionen (Release Datum vor 2013) in den meisten Fällen noch nicht behoben, da die Firmen oft nur Securitypatches und Bugfixes für ältere Releases ausliefern.
Aktuell gibt es aber Updates für zumindest folgende Distributionen (Stand 30. Jan 2015):
- RHEL 6 sowie RHEL 7 - somit in Kürze auch für OEL 6 und OEL 7
- Ubuntu 12.04 LTS
- Debian Wheezy
Es gibt aktuell noch keinen bekannten Exploit, der diese Lücke nutzt, das ist aber nur eine Frage der Zeit, daher sollte man die Patches umgehend einspielen.
Unzureichender Schutz der IT von Industrieanlagen und Infrastruktur
30.12.2014 - Bis jetzt waren die Ziele von Hackern meist Personendaten und Finanzunternehmen (Kreditkarten), das könnte sich aber schon bald ändern.
Der Wurm Struxnet aus dem Jahr 2010 hatte es auf die Irans Atomkraftwerke - um genauer zu sein die Urananreicherungsanlagen - abgesehen und dazu Sicherheitslücken im Siemens SCADA Code ausgenutzt. In vielen Bereichen, wo mit Personendaten bzw. Kreditkarten- und Bankdaten gearbeitet wird,, wird inzwischen - leider noch nicht flächendeckend - mehr für die IT Sicherheit getan. Die Frage ist aber, was passiert im Bereich der Sicherheit von Industrieanlagen und Infrastruktur?
Auch wenn Heartbleed, Shellshock, Poodle und noch viele andere uns in der letzten Zeit beschäftigt haben, hier gab es die Patches relativ rasch - nach Tagen oder spätestens Wochen gab es einen Schutz (auch wenn sich bei Weitem nicht alle IT Verantwortlichen darum gekümmert haben).
Wie Beispielsweise golem.de vor kurzen berichtet hat, dauert es bei Herstellern im Industriebereich oft 18 Monate, um bekannte Sicherheitslücken zu schliessen. Von den Lösungen im Gesundheitsbereich wird da noch nicht einmal gesprochen. In diesem Bereich gibt es immer wieder Unternehmen, in denen die IT auf Grund der Vorgaben der Hersteller überhaupt keine Patches einspielen DARF (weil diese ja den Betrieb der Geräte beeinflussen könnte) - daher sind viele dieser Geräte im Gesundheitsbereich (CT, MR, Ultraschall, Röntgen,...) praktisch ungeschützt und hängen natürlich im Netzwerk der Ärzte/Krankenhäuser, da diese die Daten der Geräte natürlich elektronisch verarbeiten wollen/müssen.
Stellen Sie sich vor, wie interessant diese Informationen sein können - erinnern Sie sich noch an den Aufschrei, als die Patientendaten von Michael Schumacher im Juni 2014 gestohlen wurden?
Jetzt sellten wir uns einmal vor, Hackern gelingt es, die Geräte im Gesundheitsbereich großflächig zu hacken - abgesehen von der Möglichkeit die Patientendaten zu nutzen (Beispielsweise für Erpressung?!) wäre es möglich diese auf einem Schlag unbenutzbar zu machen und für die Reaktivierung einen entsprechenden Betrag zu fordern...
Hoffen wir einmal, dass das Thema Security 2015 einen höheren Stellerwert bekommt und wir nicht auf dem falschen Fuß erwischt werden.
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.