Das Einspielen von Sicherheits-Updates ist ein zentraler Baustein der IT-Sicherheit. Soft- und Hardware haben Sicherheitslücken, die irgendwann bekannt werden. Dann muss man die möglichst flott schließen und die hoffentlich vom Hersteller bereitgestellten Patches einspielen, bevor die Lücke ausgenutzt wird. Doch manchmal ist sofort patchen immer noch nicht schnell genug. Das illustriert ein genauerer Blick auf die Timeline eines aktuellen
Viele Server nutzen exiftool, um hochgeladene Bilder automatisiert von Meta-Daten zu befreien. Allerdings hat das Skript in DjVu-Dateien diese Meta-Daten nicht ausreichend gefiltert, sodass man recht einfach eigene Befehle einschleusen konnte, die bei der Analyse von Bildern dann ausgeführt wurden (
Vermutlich nicht. Ich denke eher, dass die sich einfach auf die Sicherheits-Updates ihrer Linux-Distribution verlassen haben. Und bei
Für Beinahe-Zero-Days haben andere den Großteil der Arbeit bereits erledigt und nicht nur die Sicherheitslücke aufgespürt und auf Ausnutzbarkeit bewertet, sondern oft auch schon Proof-of-Concept-Exploits entwickelt, die man nur noch mit einer eigenen Payload scharf schalten muss. Wer also die entsprechenden Mailing-Listen von Open-Source-Projekten aktiv beobachtet, kann da aus dem Vollen schöpfen.
Wie soll man sich davor schützen? Ich muss gestehen, dass ich da recht ratlos bin. Man kann ja unmöglich alle relevanten Projekte selbst verfolgen und Updates am Distributionsprozess vorbei installieren. Darüber habe ich übrigens auch gerade mit Felix von Leitner diskutiert, der sich mit dem Thema des Patch Managements intensiv beschäftigt hat. Das ist einer der Gründe, warum ich mich auch schon sehr auf seinen Vortrag "Die andere Seite der Medaille – was Sie über Patch-Management wissen sollten" auf der
Quelle: heise
Du musst dich
Anmelden
oder
Registrieren
um diesen link zusehen!
sehr gut.Ein unscheinbares Sicherheitsproblem
Ursprung war ein unscheinbares Sicherheitsproblem: "Patched security vulnerability in DjVu reader" hieß es in den Release-Notes der Version 12.24 von exiftool. Das ist ein kleines Perl-Skript, mit dem man die Meta-Informationen in Bildern auslesen und bearbeiten kann. Ich habe das im Rahmen von Recherchen mehrfach benutzt und auch um vor einer Veröffentlichung auf heise die GPS-Koordinaten aus Smartphone-Fotos zu entfernen.Viele Server nutzen exiftool, um hochgeladene Bilder automatisiert von Meta-Daten zu befreien. Allerdings hat das Skript in DjVu-Dateien diese Meta-Daten nicht ausreichend gefiltert, sodass man recht einfach eigene Befehle einschleusen konnte, die bei der Analyse von Bildern dann ausgeführt wurden (
Du musst dich
Anmelden
oder
Registrieren
um diesen link zusehen!
).Timeline eines erfolgreichen Angriffs
Das meldete ein Sicherheitsforscher am 7. April 2021 zunächst noch vertraulich über die Bug-Bounty-PlattformDu musst dich
Anmelden
oder
Registrieren
um diesen link zusehen!
beim betroffenen GitLab. Die reagierten schnell, reichten das an die exiftool-Maintainer weiter, die schon am 13. April eine
Du musst dich
Anmelden
oder
Registrieren
um diesen link zusehen!
Version 12.24 bereitstellten und am 14. April erhielt der Forscher 19.000 US-Dollar Belohnung. Doch damit war die Geschichte nicht vorbei. Am 30. April – also mehr als zwei Wochen danach – reichte
Du musst dich
Anmelden
oder
Registrieren
um diesen link zusehen!
bei Googles Vulnerability Reward Program einen Bericht ein. Sie hatten festgestellt, dass ihnen bei Virustotal hochgeladene DjVu-Bilder Zugriff auf Scan-Server bescherten. Hatten die Betreiber dieser Server die Patches verschlafen?Vermutlich nicht. Ich denke eher, dass die sich einfach auf die Sicherheits-Updates ihrer Linux-Distribution verlassen haben. Und bei
Du musst dich
Anmelden
oder
Registrieren
um diesen link zusehen!
etwa kam das erst am 2. Mai; bei
Du musst dich
Anmelden
oder
Registrieren
um diesen link zusehen!
sogar erst am 4. Mai. Es gab also nach der Veröffentlichung des Patches, der das Problem offenlegte, ein Zeitfenster von über 2 Wochen, in dem Linux-Systeme mit exiftool anfällig waren für eine bekannte, leicht auszunutzende Sicherheitslücke. CySrc nutzte dieses Zeitfenster, um bei Googles Vulnerability Reward Program zu punkten (wobei nicht klar ist, ob sie eine Prämie bekamen). Aber genauso gut hätten staatliche APT- oder Cybercrime-Hacker dieses Einfallstor für ihre Zwecke ausnutzen und damit echten Schaden anrichten können.Beinahe-Zero-Days
Exiftool ist nur ein Beispiel für solche Beinahe-Zero-Days, die wahrscheinlich sogar eine größere Bedrohung für Firmen darstellen, als die viel gehypten, echten Zero-Day-Lücken. Bei letzteren hat man gar keinen Vorlauf, um sich durch Patches oder Mitigations vor Angriffen zu schützen. Doch diese Lücken sind teuer, schwer zu finden und oftmals auch nicht einfach auszunutzen.Für Beinahe-Zero-Days haben andere den Großteil der Arbeit bereits erledigt und nicht nur die Sicherheitslücke aufgespürt und auf Ausnutzbarkeit bewertet, sondern oft auch schon Proof-of-Concept-Exploits entwickelt, die man nur noch mit einer eigenen Payload scharf schalten muss. Wer also die entsprechenden Mailing-Listen von Open-Source-Projekten aktiv beobachtet, kann da aus dem Vollen schöpfen.
Wie soll man sich davor schützen? Ich muss gestehen, dass ich da recht ratlos bin. Man kann ja unmöglich alle relevanten Projekte selbst verfolgen und Updates am Distributionsprozess vorbei installieren. Darüber habe ich übrigens auch gerade mit Felix von Leitner diskutiert, der sich mit dem Thema des Patch Managements intensiv beschäftigt hat. Das ist einer der Gründe, warum ich mich auch schon sehr auf seinen Vortrag "Die andere Seite der Medaille – was Sie über Patch-Management wissen sollten" auf der
Du musst dich
Anmelden
oder
Registrieren
um diesen link zusehen!
freue.Quelle: heise
