Schlagwort: Schwachstelle

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:

News

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

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.

News

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

News

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

News

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

News

Ö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/

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

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