Liebe Leserinnen, liebe Leser,

viele Experten sind der Meinung, dass mehr Sicherheitsmaßnahmen unsere Netze sicherer machen. In diesem Monat haben wir uns einige Beispiele herausgesucht, in denen zu diesem Zweck erdachte Systeme, Tools, Konfigurationen und Menschen die Sicherheit nicht erhöht, sondern gefährdet haben.

Freuen Sie sich auf folgende Themen in der Juni-Ausgabe unseres Cybersecurity Digest:

• Wenn die Sicherheitsappliance die Lücke ist
• Wenn der Sicherheitsmitarbeiter die Lücke ist
• Datenaustauschplattform mit unerwünschten Nebenfunktionen
• Trojanisierte SSH-Keys
• Eine Sicherheitslücke ausnutzen, um eine Sicherheitsfunktion umzusetzen

Wir wünschen Ihnen viel Spaß beim Lesen – Ihr Feedback ist wie immer herzlich willkommen!
Mit besten Grüßen
Jörg Schneider

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?

Quellen: 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

Wenn der Sicherheitsmitarbeiter die Lücke ist

Die Menschen im Unternehmen spielen eine zentrale Rolle bei der Informationssicherheit. Das gilt umso mehr für diejenigen, die wir extra für diesen Bereich eingestellt haben. Passend zu unserem Monatsthema „Sicher trotz Sicherheitsmaßnahmen“ gab es Ende Mai ein Urteil in Großbritannien, bei dem ein Informationssicherheitsexperte schuldig gesprochen wurde. Bereits 2018 gab es einen Sicherheitsvorfall bei seinem Arbeitgeber, und er war an der Aufklärung und Bewältigung des Vorfalls beteiligt.

Doch nebenbei wollte er auch direkt von dem Vorfall profitieren. Dafür nutzte er seine Zugänge, um die Mail mit der Erpressungsnachricht direkt im Postfach des Empfängers zu ändern. In der Hoffnung, sein Arbeitgeber würde die Erpressungssumme zahlen, änderte er die Zahlungsdaten auf eine eigene Adresse. Zusätzlich schickte er noch Mails im Namen der Erpresser hinterher, um auf eine Zahlung zu drängen.

Die Manipulation wurde entdeckt und konnte auf seine Person zurückverfolgt werden. Im Ergebnis hat er sich nun schuldig bekannt.

Quellen: https://www.bleepingcomputer.com/news/security/it-employee-impersonates-ransomware-gang-to-extort-employer/, https://serocu.police.uk/man-convicted-of-blackmail-and-other-offences/ (Beitrag offline)

Auswirkungen erforschen und minimieren - statt erfolglos versuchen, Zero-Day-Exploits zu verhindern

Auch dieser Digest zeigt, dass Angreifer durch das Ausnutzen unbekannter Schwachstellen immer neue Wege entwickeln, um Zugang zu einem Netzwerk zu erlangen.

Gerade bei Zero-Day-Schwachstellen, für die noch kein Update der Hersteller existiert, lässt sich eine Ausnutzung nicht zuverlässig verhindern. In internen Penetrationstests nehmen wir genau diese Startposition ein und untersuchen, welche Schwachstellen und Zugriffsmöglichkeiten ein Angreifer in Ihrem internen Netzwerk finden und ausnutzen kann. Als Ergebnis erhalten Sie ein umfangreiches Bild über die Wirksamkeit von Schutzmaßnahmen und Schwachstellen sowie über mögliche Angriffspfade in Ihrer internen Infrastruktur.

Welchen Schaden können Angreifer anrichten, wenn sie in Ihr Netz eingedrungen sind? Finden Sie es heraus: mit unseren maßgeschneiderten Pentests und Angriffssimulationen.

https://www.hisolutions.com/security-consulting/cybersecurity/penetrationstests-technische-audits

Datenaustauschplattform mit unerwünschten Nebenfunktionen

Um keine Dateien als Mailanhänge mehr verschicken zu müssen, werden häufig Datenaustauschplattformen aufgesetzt. Ähnlich wie das ESG können diese zur Vorprüfung eingehender und ausgehender Dateien genutzt werden und damit als klar definierter Ein- und Austrittspunkt aus dem eigenen Netz – also wieder eine klassische Sicherheitsfunktion. Bei der Lösung MOVEit Transfer von Progress ist jedoch Ende Mai eine Sicherheitslücke bekannt geworden, die ebenfalls bereits aktiv ausgenutzt wird. In Deutschland wurden diesbezüglich mehr als 100 betroffene Systeme vermutet. Mehrere AOKs haben die Lösung im Einsatz und hatten sie vorsichtshalber abgeschaltet.

Sehr viele Instanzen sind immer noch in der verwundbaren Version erreichbar – und das, obwohl die Lücke bereits u. a. von Ransomware-Gruppen ausgenutzt wird. Es gibt sogar Hinweise darauf, dass die CL0P-Gruppe bereits seit 2021 mit der Ausnutzung der Lücke experimentiert.

Quellen: https://community.progress.com/s/article/MOVEit-Transfer-Critical-Vulnerability-31May2023, https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-158a, aok-bv.de/presse/pressemitteilungen/2023/index_26408.html (Beitrag offline)

Trojanisierte SSH-Keys

In der Linux-Welt wird die Authentisierung beim Fernzugriff gern mit SSH-Keys umgesetzt. Diese Schlüsselpaare aus privatem und öffentlichem Schlüssel haben gegenüber Passwörtern viele Vorteile – so können z. B. für einen Nutzer mehrere autorisierte Schlüssel hinterlegt werden, und der gleiche Mensch kann sich je nach Quellrechner unterschiedlich anmelden (z. B. Laptop, Desktopsystem oder Sprungserver). In der zuständigen Datei „authorized_keys“ können noch weitere Einschränkungen für Zugriffe mit bestimmten Schlüsseln gemacht werden. Beispielsweise kann ein Backupsystem einen Zugriff erhalten, der lediglich das Ausführen des notwendigen Datensammelskripts erlaubt.

In einem Blogpost wurde gezeigt, wie sich diese eigentlich gut gemachte Sicherheitsfunktion ausnutzen lässt, um eine Hintertür auf einem System zu hinterlassen. Eine notwendige Voraussetzung dafür ist der Zugriff auf die Datei „authorized_keys“. Damit kann man sich natürlich auch einfach seinen eigenen Schlüssel in die Liste schreiben, aber das könnte bei einer Inventur der Zugänge auffallen. Daher wird bei dem geschilderten Angriff ein bestehender Eintrag so modifiziert, dass bei jedem Anmelden des berechtigen Nutzers zusätzlich eine Backdoor gestartet wird.

Die betroffene Datei „authorized_keys“ ist sehr geschickt gewählt, da sie nur jeweils den öffentlichen Schlüssel der berechtigten User enthält. Diese Datei wird daher häufig bei größeren Setups und automatischen Deployments mit Git versioniert und dann automatisch auf alle Systeme verteilt. Eine versteckte Manipulation kann also schnell viele kompromittierte Systeme zur Folge haben.

Quelle: https://blog.thc.org/infecting-ssh-public-keys-with-backdoors

Eine Sicherheitslücke ausnutzen, um eine Sicherheitsfunktion umzusetzen

Zum Schluss noch ein Beispiel für den umgekehrten Fall, bei dem eine Sicherheitslücke ausgenutzt wurde, um Sicherheit umzusetzen: Die Zertifizierungsstelle Let's Encrypt hat mit ihren automatisch vergebenen und verlängerten Zertifikaten für einen Umbruch bei der Generierung von TLS-Zertifikaten gesorgt. Das dabei eingeführte ACME-Protokoll wird inzwischen auch von anderen Anbietern genutzt, und es gibt eine Reihe von Tools, die das Protokoll unterstützen und auf Servern die automatische Verlängerung übernehmen können. Eines davon ist die Umsetzung als Shellskript, genannt acme.sh. Dieses Skript hatte eine Remote-Execution-Lücke – und öffentlich bekannt wurde sie auf einem eher kuriosen Weg.

Matt Holt ist über den Zertifikatsanbieter HiCA gestolpert, der das ACME-Protokoll nutzt, aber offiziell nur einen einzigen Client zur Nutzung empfahl – acme.sh. Andere Clients funktionierten tatsächlich nicht – daher versuchte er herauszufinden, wo die mögliche Inkompatibilität lag. Überrascht stellte er fest, dass die HiCA-Server während der Verifikation Antworten schickten, die einen Fehler im acme.sh-Client ausnutzten und vom Server versandte Shellbefehle ausführten. Der Hintergrund war, dass HiCA ein Reseller einer anderen Zertifizierungsstelle war, die zwar auch automatische Verifikationen nutzte, aber nicht nach dem ACME-Protokoll. Daher wurden andere Nachweisdateien auf dem Webserver benötigt, die nach dem ACME-Protokoll nicht erzeugt werden konnten. Der HiCA-Betreiber hat deshalb einen Exploit entwickelt, der die Verifikation nach dem anderen Protokoll durchführte und die Nachweise anlegte – also im Grunde eine Sicherheitsfunktion im Exploit umgesetzt.

Die Lücke und auch die HiCA sind inzwischen geschlossen.

Quelle: https://github.com/acmesh-official/acme.sh/issues/4659