Schlagwort: Schwachstelle

News

Schwachstelle in Confluence

In der Wiki-Software Confluence ist vor kurzem eine Lücke in der Wiederherstellungsfunktion bekannt geworden. Angreifer können diese auch ohne Zugangsdaten nutzen, um eigene Administrator-Accounts anzulegen. Mit diesen lassen sich dann weitere Manipulationen durchführen – zum Beispiel Plug-ins installieren, die wiederum einen weiterreichenden Zugriff auf das Betriebssystem des Servers ermöglichen. Die Lücke wird bereits bei selbstgehosteten Confluence-Servern, die im Internet erreichbar sind, ausgenutzt, und wir unterstützen bereits mehrere Betroffene bei der Bewältigung des Vorfalls.

https://confluence.atlassian.com/security/cve-2023-22518-improper-authorization-vulnerability-in-confluence-data-center-and-server-1311473907.html

Cyberwar, Schwachstelle

Was haben drei Töne mit Informationssicherheit zu tun?

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

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

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

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

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

News

Vorfallupdates – Microsoft und LastPass

Zu zwei Vorfällen, die wir bereits in unserem Digest behandelt haben, gab es in den letzten Tagen Neuigkeiten, die ich gern aufgreifen möchte.

Zuerst zu Microsofts Problem mit unberechtigten Anmeldungen in der Cloud, ein Thema aus dem letzten Digest. Eine zentrale Rolle spielte dabei ein privater Schlüssel, den die Angreifer erbeutet hatten, und mit dem sie sich dann beliebige Zugangstoken selbst unterschreiben konnten. Zu diesem Fall gibt es inzwischen von Microsoft eine detaillierte Beschreibung, wie der Schlüssel über mehrere Stufen aus dem produktiven Server auf eine Testumgebung gelangen konnte. Es wird vermutet, dass er dort von den Angreifern entwendet wurde.

Zusammengefasst wurde zur Rekonstruktion eines Fehlers ein Crashdump des produktiven Servers in die Testumgebung zur Analyse kopiert. Dabei hätte der Crashdump keine Schlüssel enthalten dürfen und falls doch, hätte es an mehreren Stellen in dem Kopierprozess auffallen müssen – keiner der Filter hat jedoch angeschlagen. Das ist aus meiner Sicht eine der Lektionen aus dem Vorfall: Vertraue keinem automatischen Bereinigungsprozess – gerade bei komplexen, unstrukturierten Daten wie Crashdumps –, sondern behandle diese Daten so sensibel wie die ursprünglichen.

Die andere Lektion ist, dass sich die Spur ab der Testumgebung verliert. Es waren keine Protokolldaten mehr da, um die Spur weiter zu verfolgen. Es bleibt also eine bloße Vermutung, dass die Schlüssel über diesen Weg zu den Angreifern gelangten. Gerade bei weiter zurückliegenden Vorfällen stehen auch unsere Forensiker immer wieder vor dem Problem, dass Protokolldaten fehlen. Entweder sie wurden gar nicht erst aufgezeichnet oder aber automatisch gelöscht bzw. überschrieben.

Das zweite Info-Update betrifft den Vorfall beim Passwortmanager LastPass im letzten Jahr, den wir in unserem Januar-Digest thematisierten. Jetzt gibt es einen Verdacht, was mit den gestohlenen Passwörtern passiert sein könnte. Es wird vermutet, dass die Angreifer in den LastPass-Daten Seeds Phrases – also Zugangsdaten für Konten von Krypto-Währungen – gefunden und damit unberechtigte Abbuchungen vorgenommen haben. Taylor Monahan vom Krypto-Wallet-Hersteller MetaMask hatte angesichts einer Reihe von Diebstählen von Krypto-Werten Verdacht geschöpft und die LastPass-Nutzung als gemeinsamen Nenner identifiziert. Sicherheitsexperte Brian Krebs ist in seinem Blog dieser Vermutung nachgegangen und hat noch ein paar weitere Indizien ergänzt.

Advisories, Cyberwar, Incidents, Schwachstelle, Zeroday

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

Update vom 10.08.2023:

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

Update vom 01.08.2023:

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

Update vom 31.07.2023:

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

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

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

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

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

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

Die 25 gefährlichsten Sicherheitslücken

Neben den allseits bekannten CVE-Nummern verwaltet MITRE auch CWE-Nummern. Auch beim Ausschreiben der Abkürzungen ist der Unterschied nicht gleich offensichtlich: Während die „Common Vulnerabilities and Exposures“ (CVE) konkrete vorhandene Sicherheitslücken beschreiben, lautet das Ziel der „Common Weakness Enumeration“ (CWE), eine Liste von möglichen Schwachstellenarten zu pflegen. Daher finden sich in einigen CVE-Datenbanken auch zu jedem CVE-Eintrag eine CWE, also die Art der Schwachstelle.

Aus dieser Zuordnung berechnet das CWE-Team jedes Jahr ein Ranking der 25 gefährlichsten Sicherheitslücken(-arten). In die Berechnung fließen die Häufigkeit und die Risikobewertung sämtlicher CVE-Meldungen der letzten zwei Jahre ein.

Die ersten drei Plätze haben die Klassiker Buffer Overflow, Cross-Site-Scripting und SQL-Injection verteidigt. Aber auch in der übrigen Liste gibt es nur wenig Bewegung und lediglich zwei Auf- bzw. Absteiger. Fazit: Es gibt noch viel zu tun bei der Absicherung.

Schwachstelle

Wenn die Sicherheitsappliance die Lücke ist

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

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

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

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

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

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

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

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

News

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.

Advisories, 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.

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