HiSolutions Cybersecurity Digest April 2023
Wenn der Patch zum Trojaner wird
Liebe Leserinnen, liebe Leser,
patchen, patchen, patchen – eines der Mantras der Informationssicherheit. Diesen Monat haben wir Nachrichten an den Anfang gestellt, die sich unter anderem um das Patchmanagement drehen. Und damit der Newsletter nicht zu softwarelastig wird, runden wir das Ganze mit Berichten aus dem Betrieb und zu Hardware ab.
Diese Themen gibt es heute:
- Wenn der Patch zum Trojaner wird
- Unser Schwachstellenreport: Was wurde besser? Was nicht?
- Cropocalypse: Wenn Wegschneiden nicht Wegschneiden ist.
- Reddit-Ausfall: Nicht nur Systeme, sondern auch die Menschen aktuell halten
- Explodierende USB-Sticks
Wir wünschen Ihnen viel Spaß beim Lesen! Ihr Feedback ist wie immer herzlich willkommen.
Mit besten Grüßen
Jörg Schneider
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:
https://www.3cx.com/blog/news/desktopapp-security-alert/
https://www.bleepingcomputer.com/news/security/cryptocurrency-companies-backdoored-in-3cx-supply-chain-attack/
https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/3cx-supply-chain-attack
https://www.zscaler.de/security-research/3CX-supply-chain-attack-analysis-march-2023
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)
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
Cropocalypse: Wenn Wegschneiden nicht Wegschneiden ist.
Direkt nach Redaktionsschluss unseres März-Newsletters wurde eine spannende Sicherheitslücke in zwei verschiedenen Bildbearbeitungstools identifiziert: Wenn man ein Bild zugeschnitten und dieses Bild als PNG gespeichert hatte (z. B. um vertrauliche Details zu entfernen), enthielt die Datei teilweise noch die nicht mehr sichtbaren Bildbereiche (und wenn man Pech hatte, auch das vertrauliche Detail), so dass diese mit entsprechenden Tools wieder sichtbar gemacht werden konnten. Betroffen waren das Bildverarbeitungstool für Google-Pixel-Smartphones sowie das unter Windows 11 „Snipping Tool“ bzw. unter Windows 10 „Ausschneiden und skizzieren“ genannte Screenshot-Tool (das klassische „Snipping Tool“ von Windows 10 war nicht betroffen).
Da zwei komplett verschiedene Programme den gleichen Fehler aufwiesen, haben wir in unserem Labor einen Aufbau erstellt, um weitere betroffene Programme erkennen zu können. Dazu haben wir auch das Tool der ursprünglichen Entdecker der Lücke, Simon Aarons und David Buchanan, für die Windows 11/10-Tools angepasst. Zudem haben wir weitere Tools, die unsere Kunden für die Screenshot-Erstellung verwenden, auf Auffälligkeiten geprüft – und glücklicherweise keine weiteren betroffenen Tools gefunden. Falls Ihr favorisiertes Screenshot-Tool nicht dabei ist, schicken Sie uns gern eine Mail einschließlich Benennung der Softwarequelle und ggf. mit einem zugeschnittenen PNG.
Fehlt noch die Referenz zum Monatsthema Patchmanagement – diesmal nicht als Herausforderung beim sicheren Betrieb, sondern in der Softwareentwicklung. Eine Änderung in der Android-API fand die Entwicklerin Iliana Etaoin als mögliche Erklärung für den Fehler in der Google-Pixel-App. Seit Android 10 muss man den Parameter „t“ dem Befehl zum Öffnen der Datei mitgeben, damit ungenutzter Speicher nach dem Schreiben freigegeben wird. Davor war das auch ohne zusätzlichen Parameter der Fall. Möglicherweise wurden also die Änderung der Funktionsweise des Befehls und die sich daraus ergebenden Seiteneffekte nicht berücksichtigt.
https://research.hisolutions.com/2023/03/acropalypse-now/
https://twitter.com/ItsSimonTime/status/1636857478263750656
https://iliana.fyi/blog/acropalypse-now/
Reddit-Ausfall: Nicht nur Systeme, sondern auch die Menschen aktuell halten
[Text]In der pointierten Kurzform klingen die Ursachen für den jüngsten Ausfall der Plattform „Reddit“ wie der Albtraum jedes Betreibers von historisch gewachsenen Systemlandschaften: Die Routing-Regeln, die der Ursprung für einen Ausfall waren, wurden vor sehr langer Zeit geschrieben – und jeder aus dem ursprünglichen Team war inzwischen entweder in einer anderen Rolle im Unternehmen oder ganz woanders unterwegs.
Für mehr Details empfiehlt sich der sehr lange, aber auch schön zu lesende Post des Reddit-Engineering-Teams. Er schildert sehr anschaulich das Auf und Ab zwischen gewählten Lösungsansätzen und dann plötzlich querschlagenden Komplikationen, für die wieder neue Lösungen gesucht werden müssen. Auch die schwierige Entscheidung zwischen dem Weiterdebuggen im laufenden Restbetrieb und dem aktiven Abschalten zum Einspielen der Back-ups ist ein gutes Beispiel für die Entscheidungen in einer Krise, wie sie unsere Krisencoaches auch bei unseren Kunden begleiten.
Neben dem Problem, dass es für das ursächliche Teilsystem keine Experten mehr gab und dieses ganz anders verwaltet wurde als die neueren Teile, so dass sich die Mitarbeiter erst tiefer einarbeiten mussten, war auch ein weiteres organisatorisches Problem, dass die Wiederherstellung aus dem Back-up in der Form nicht geübt worden war. Damit fehlten Erfahrungswerte für die Dauer der Wiederherstellung, und man liest aus dem Beitrag auch heraus, dass dieser Lösungsweg aus Furcht vor Fehlern anfangs vermieden werden sollte.
Aber auch unser Monatsthema Patchmanagement kommt in dem Bericht nicht zu kurz: Die Back-up-Wiederherstellungsskripte wurden nicht an die Änderungen im produktiven Cluster angepasst. Daher passten sie nicht zu architektonischen Änderungen des Reddit-Teams, enthielten aber auch Kommandos für eine inzwischen End-of-Life-Version von Kubernetes. Der ursächliche Fehler mit den „Route Reflectors“ basierte auf einer Umbenennung, die bereits mit Kubernetes 1.20 im Jahr 2020 eingeführt wurde. In den folgenden Versionen waren dann noch übergangsweise die alten Bezeichner gültig, bis sie in der beim Vorfall installierten Version 1.24 ganz entfernt wurden.
https://www.reddit.com/r/RedditEng/comments/11xx5o0/you_broke_reddit_the_piday_outage/
Explodierende USB-Sticks
In fast jeder Sensibilisierungsschulung wird auf die Risiken von gefundenen oder zugesendeten USB-Sticks hingewiesen. Dabei sind aber meist Risiken für die IT-Systeme gemeint, in die der USB-Stick dann eingesteckt wird. Die Beispiele reichen vom einfachen Speicher-USB-Stick, auf dem eine Malware liegt und die vom Nutzer aus Neugier per Hand gestartet wird, über automatisierte Tastaturen wie den „Rubber Ducky“ bis hin zu USB-Geräten, die das Gerät mit Stromschlägen physisch beschädigen sollen (z. B. USBKill).
In Ecuador haben fünf Journalisten eine noch drastischere Version per Brief zugeschickt bekommen. Die Geräte in Form von handelsüblichen USB-Sticks sollten nach dem Einstecken explodieren. In einem Fall kam es tatsächlich zu einer Explosion des enthaltenen Sprengstoffes, und der Journalist Lenin Artieda wurde dabei verletzt. In den anderen vier Fällen konnten die Briefe rechtzeitig als Briefbombe identifiziert werden.
Der nächste HiSolutions Cybersecurity Digest erscheint Mitte Mai 2023
Lesen Sie hier auch alle HiSolutions Cybersecurity Digests der letzten Monate.
Kontaktieren Sie uns gern mit Rückfragen und Anregungen!