Schwachstelle – Seite 2 – HiSolutions Research

15. Juni 202315. Juni 2023Schwachstelle

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

17. Mai 202317. Mai 2023News

Der Windows-Patch, der die Neuinstallation verhindert – auch von Ihrem Notfall-USB-Stick?

Im letzten Digest ging es um viele Aspekte des Patchens. Nun wurde ein Patch veröffentlicht, der in Einzelfällen auch extreme Auswirkungen haben kann – er verhindert Neuinstallationen auf dem Gerät.

Aber von vorn: Im Herbst 2022 tauchte das BlackLotus-Rootkit auf, das sich unbemerkt in das UEFI einschleichen kann (ganz ohne die oben beschriebenen Schlüssel). Martin Smolár von ESET hat das Rootkit tiefer analysiert und dabei neben bekannten Exploits für bekannte Lücken auch einen neuen Weg gefunden, um Windows Secure Boot zu umgehen (CVE-2023-24932). Dafür hat Microsoft jetzt einen Patch vorbereitet, der allerdings bei vollständiger Anwendung bestehende Boot-Medien ausschließt – und damit auch Installationsmedien und Notfall-Bootsticks, die man vorsorglich vorbereitet hat.

Das Risiko ist Microsoft bekannt, daher bringt das Update erst einmal nur alles in Stellung, und die Rekonfiguration des UEFI im System durch Einspielen einer Revocation List muss vor 2024 händisch angestoßen werden. Das gibt allen ausreichend Zeit, die Notfall-Bootsticks durchzugehen. Aber nicht zu lange warten: Im Q1 2024 soll die Änderung automatisch eingespielt werden.

Meldung von ESET: https://www.eset.com/at/about/presse/pressemitteilungen/pressemitteilungen/erstmals-umgeht-bootkit-das-uefi-secure-boot-von-windows/
Umfangreiche Anleitung von Microsoft zum Einspielen und den Nebenbedingungen: https://support.microsoft.com/en-us/topic/kb5025885-how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d

26. April 202327. April 2023Advisories, 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.

13. April 2023Schwachstelle

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:

https://learn.microsoft.com/en-us/security-updates/SecurityBulletins/2013/ms13-098 (Meldung zu der Signatur-Schwachstelle)
https://learn.microsoft.com/en-us/security-updates/SecurityAdvisories/2014/2915720 (Anleitung, um die striktere Prüfung zu aktivieren)

13. April 202313. April 2023News

Unser Schwachstellenreport: Was wurde besser? Was nicht?

Letzte Woche haben wir unseren jährlichen Schwachstellenreport veröffentlicht –erstmals nicht nur basierend auf den Prüfergebnissen unserer Pentester, sondern auch mit den wichtigsten Erkenntnissen aus unseren Forensik- und Incident-Response-Einsätzen. Darunter finden sich auch unsere Top-5-Maßnahmen zur Prävention, die die Auswirkungen reduziert oder gar den Vorfall selbst vermieden hätten. Mit dabei sind, passend zum Monatsthema Patchmanagement: „Zeitnahes Patchen exponierter Dienste und Systeme“ – aber auch manipulationsgesicherte Back-ups, Mehrfaktor-Authentisierung, bessere Zugriffskontrolle für Admin-Systeme und bessere Detektionsverfahren.

Bei unseren Penetrationstests, egal ob extern über das Internet oder nach dem Assume-Breach-Gedanken von einem internen Startpunkt aus, identifizieren wir auch regelmäßig Systeme mit bekannten Sicherheitslücken (und fehlenden Patches).

Die gute Nachricht im Jahresvergleich ist, dass wir bei externen Penetrationstests aus der Perspektive eines unauthentifizierten Angreifers aus dem Internet immer weniger kritische Lücken finden. Der Perimeter wird also immer besser geschützt. Das wissen leider auch die Angreifer und versuchen daher, möglichst von innen heraus zu agieren (z. B. VPN-Einwahl per Phishing erbeuten, Malware auf einem Client im internen Netz ausführen lassen). Unsere internen Penetrationstests, die ebenfalls von dieser Position starten, zeigen im Jahresvergleich einen kontinuierlich hohen Kritikalitätsvektor. Tatsächlich endet kaum ein interner Penetrationstest, ohne dass administrative Konten oder gar die gesamte Windows-Domäne übernommen werden konnten.

Noch mehr Auswertungen und Trends finden Sie im HiSolutions-Schwachstellenreport 2023: https://www.hisolutions.com/detail/schwachstellenreport-2023

24. März 202327. März 2023Advisories, 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:

Tool	Version
IrfanView	4.62
Greenshot	1.2.10
XnView MP	1.4.3
ShareX	15.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.

23. März 202323. März 2023News

Vertrauen gebrochen? TPMs geben ihre Geheimnisse preis

Das Trusted Plattform Module (TPM) soll den Vertrauensanker im Rechner bilden und kann beispielsweise die benötigten Schlüssel für die Festplattenverschlüsselung bereithalten. Genau bei dieser Aufgabe haben sie gerade etwas an Vertrauen verloren, da eine Lücke in der Referenzimplementierung zu einem Auslesen oder Verändern von geschützten Daten führen kann.

Je nachdem, wie sehr die Hersteller von der Referenzimplementierung abgewichen sind, so unterschiedlich fallen die konkreten Auswirkungen aus. Die Voraussetzung für den Angriff haben sie aber alle gemein: Der Zugriff klappt nur aus einem bereits laufenden System heraus mit einem Nutzerkonto, das entsprechenden Zugang zur betroffenen TPM-Funktion „CryptParameterDecryption“ hat. Die Lücke ist also nicht geeignet, um einem ausgeschaltetem Laptop den Bitlocker-Key zu entlocken. Aber wie „Bleeping Computer“ passend anmerkte, erfüllt bereits eine Malware auf dem Laptop die nötigen Bedingungen, um möglicherweise an vertrauliche Informationen aus dem TPM zu kommen.

https://trustedcomputinggroup.org/wp-content/uploads/TCGVRT0007-Advisory-FINAL.pdf
https://www.bleepingcomputer.com/news/security/new-tpm-20-flaws-could-let-hackers-steal-cryptographic-keys/
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-1017
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-1018

23. März 2023News

Wir nehmen RTF: Da gibt es keine Makros – dafür aber einen Exploit

Das Rich Text Format (RTF) wurde lange als plattformübergreifendes Austauschformat genutzt – auch wenn das Format genauso wie das Word-Format von Microsoft spezifiziert wurde. RTF-Dokumente können aber von Haus aus keine Makros enthalten, und es gibt neben den Microsoft-Produkten eine Reihe weiterer Tools auf verschiedenen Betriebssystemen, die damit umgehen können. Ganz Mutige lesen das RTF-Dokument direkt im Texteditor und denken sich das Layout einfach dazu.

Das klingt doch nach einer tollen Ablösung für den Mailversand von Office-Dokumenten mit potenziell verseuchten Makros. Das Format wird allerdings seit 2008 nicht mehr gepflegt. Noch viel entscheidender: Vor einem Monat wurde eine Lücke in Word bekannt, mit der über ein präpariertes RTF-Dokument beliebiger Code ausgeführt werden kann. Microsoft hat die Lücke mit den Februar-Patches bereits behoben. In seinem Bericht hat Joshua J. Drake, der Finder der Lücke, aber auch schon einen Proof-of-Concept-Exploit veröffentlicht.

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-21716

https://qoop.org/publications/cve-2023-21716-rtf-fonttbl.md

17. Februar 2023News

Wenn Angreifer VMs den Teppich unter den Füßen wegziehen: Große Angriffskampagne auf VMware-Hosts

Virtualisierung hat der Sicherheit einen deutlichen Schub gegeben. Nie war es einfacher, Dienste und Daten auf verschiedene (virtuelle) Systeme zu verteilen. Aber wie immer in der IT kommt das nicht ohne einen großen Haken: Der Virtualisierungshost wird zu einem Single-Point-of-Failure, von dem die Sicherheit aller darauf laufenden Systeme abhängt.

Nach einer großen Angriffskampagne mussten Betreiber von VMware-ESX-Servern dies am eigenen Leib erfahren. Verschiedene Informationssicherheitsbehörden gaben sogar Warnungen heraus – darunter Italiens ACN und das französische CERT. Bei genauerer Betrachtung der Kampagne sieht man, dass eine recht alte Lücke ausgenutzt wird (die CVE datiert von 2021, das Update ist seit einem Jahr verfügbar) und die Angreifer Zugriff auf den Port 427 benötigen. Dieser Port wird für das CIM-/SLP-Protokoll benötigt, mit dem man externe virtuelle Ressourcen verwalten kann – er dient also eher einer administrativen Funktion.

Durch systematisches Ausnutzen des fehlenden Patches und der offenen Adminschnittstelle konnten Angreifer sehr viele Hostsysteme kompromittieren und verschlüsseln – und damit eine natürlich umso größere Anzahl darauf laufender virtueller Systeme beeinträchtigen.

Glück im Unglück: Für Betroffene der ersten Angriffswelle gibt es bereits Skripte, mit denen virtuelle Maschinen aus Artefakten wiederhergestellt werden können. In späteren Angriffswellen haben die Angreifer die dafür nötigen Daten ebenfalls zerstört.

Wiederherstellungsskript: https://github.com/cisagov/ESXiArgs-Recover/blob/main/recover.sh

Warnung des BSI: https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2023/2023-205338-1032.html

17. Februar 2023News

Öffnen auch Sie nur sichere Anhänge? Wie steht es um OneNote-Dateien?

Beim Katz-und-Maus-Spiel zwischen Angreifern und Verteidigern in der Mailkommunikation wurde gerade wieder eine neue Runde gestartet: Microsoft hat per Default Makros in Office-Dokumenten deaktiviert, und in vielen Organisationen werden Office-Dokumente nur noch in makrofreien Varianten (.docx statt .doc oder .docm etc.) zugestellt.

Um neue Wege einzuschlagen, haben Angreifer jetzt das OneNote-Format entdeckt. OneNote-Notizbücher können nicht nur Notizen in Form von Text enthalten. Man kann die Notizen auch um Dateien ergänzen, die man dort aufheben möchte – vor dem inneren Auge hatten die Entwickler dabei wohl die vielen Zettelchen und Tickets, die sich in Papier-Notizbüchern immer wieder ansammeln. Vermutlich ahnen Sie schon, worauf es hinausläuft: In den digitalen Notizbüchern kann man auch ausführbare Skripte einfügen. Die Angreifer nutzen zudem die Möglichkeiten der freien Gestaltung der Notizseiten und versteckten ihre Dateilinks unter vermeintlichen Schaltflächen.

OneNote-Dokumente tauscht man vermutlich seltener aus als andere Office-Dokumente. Aber hatten Sie die schon auf Ihrer Blacklist?

Hier eine Beschreibung des konkreten Angriffs mit vielen Bildern: https://www.bleepingcomputer.com/news/security/hackers-now-use-microsoft-onenote-attachments-to-spread-malware/