Liebe Leserin, lieber Leser,

ich hoffe, Sie sind gut in das neue Jahr gestartet. 

Zwischen den Jahren findet ja immer der Chaos Communication Congress statt – dieses Jahr wieder „in echt“ und in Hamburg. Spannende Vorträge gab es sowohl zu den im letzten Digest vorgestellten gehackten Zügen als auch über einen Tesla-Hack, den wir uns diesmal als Seitenkanal des Monats anschauen. Als Top-Thema betrachten wir die Welt des Responsible Disclosure, da sie vor und nach der Veranstaltung einige Wellen geschlagen hat.

Die Themen des Monats:

• Veröffentlichen, aber verantwortungsvoll: Responsible Disclosure 
• Das Passwort war nicht RIPE genug
• Die Umwelt und die Sicherheit
• Aufstieg und Niedergang des Mirai-Botnetzes
• Seitenkanal des Monats: Ein Auto

Wir wünschen Ihnen viel Spaß beim Lesen – Ihr Feedback ist wie immer herzlich willkommen!

Mit besten Grüßen
Jörg Schneider
 

Veröffentlichen, aber verantwortungsvoll: Responsible Disclosure

Findet man eine Sicherheitslücke, dann sollte man sie verantwortungsvoll veröffentlichen (Responsible Disclosure). Aber was ist verantwortungsvoll – und wem gegenüber? In der Regel kommen ja verschiedene Interessenlagen zusammen: Die Nutzer der betroffenen Anwendung wollen so schnell wie möglich davon erfahren und hätten gern auch Details, um das Risiko und mögliche Gegenmaßnahmen bewerten zu können. Der Hersteller dagegen hätte gern einen zeitlichen Vorsprung, um vor dem öffentlichen Bekanntwerden bereits eine Lösung vorzubereiten. Das sind aber noch nicht alle Beteiligten im Spiel: Der Entdecker will eigentlich nicht viel zusätzliche Arbeit haben und unbezahlt die Qualitätssicherung für den Hersteller übernehmen. Da sich aber gefundene Sicherheitslücken auch gut im Lebenslauf machen, will er die Lücke möglichst schnell und öffentlichkeitswirksam publik machen. Die Angreifer freuen sich am meisten, wenn außer ihnen niemand oder nur wenige von der Lücke wissen, das Thema also möglichst spät und mit möglichst wenig Tamtam öffentlich wird.

Daher hat sich inzwischen ein Ablauf mit einer Vorwarnzeit für den Hersteller etabliert. Die Zeiträume variieren dabei – wir bei HiSolutions etwa planen in unserem Responsible-Disclosure-Prozess 90 Tage für die Reaktion des Herstellers ein. Falls mehrere Hersteller gleichzeitig betroffen sind, gibt es inzwischen auch etablierte Wege für eine koordinierte Veröffentlichung.

Diese Koordination ist bei der jüngst entdeckten SMTP-Smuggling-Lücke schiefgegangen. Die technischen Details zur Lücke und wer jetzt was patchen muss, hat mein Kollege Folker Schmidt in unserem Research Blog zusammengestellt.

Die Lücke wurde von Timo Longin von SEC Consult auf dem 37. Chaos Communication Congress vorgestellt. Die Hersteller der Mailserver, die in seinen Experimenten auffällig waren, wurden auch im Vorfeld informiert und reagierten teilweise direkt mit einer Lösung. Betroffen waren aber auch weitere Mailserverlösungen wie Postfix, deren Entwickler von der Veröffentlichung überrascht wurden und sehr schnell aktiv werden mussten. Eine Rekonstruktion, wie es dazu kommen konnte, wurde inzwischen im Blogpost von SEC Consult ergänzt.

Wenig später machte ein anderer Maintainer einer Open-Source-Software seinen Unmut öffentlich, diesmal jedoch nicht wegen ausbleibender Benachrichtigungen, sondern über viele unsinnige: Daniel Stenberg ist der ursprüngliche Entwickler und inzwischen Maintainer des Open-Source-Projects cURL, das von modernen Linux-Konsolen nicht mehr wegzudenken ist. In letzter Zeit häufen sich dort KI-generierte Meldungen von angeblichen Sicherheitslücken. Das Perfide daran ist, dass sie alle sehr schlüssig klingen und teilweise vorgebliche Exploits mitliefern. Erst beim Nachvollziehen im Sourcecode fällt dann auf dass der beschriebene Angriff gar nicht möglich ist. Halluzinationen sind ein bekanntes Problem von großen Sprachmodellen (LLM) und werden mit solchen halluzinierten Reports nun auch zu einem Problem für die Softwareentwickler.

SMTP Smuggling

• Veröffentlichung von SEC consult: https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/
• Reaktion von Postfix: https://www.postfix.org/smtp-smuggling.html
• Unsere technische Zusammenfassung für betroffene Nutzer: https://research.hisolutions.com/2024/01/smtp-smuggling-fallout-oder-wer-muss-jetzt-eigentlich-was-patchen/

cURL und von der AI halluzinierte Schwachstellen: https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-for-intelligence/

Das Passwort war nicht RIPE genug

Für die spanische Mobilfunktochter von Orange begann das Jahr mit einem Schrecken und für die meisten Kunden landesweit mit einem dreistündigen Internetausfall: Ein Unbefugter hatte sich im Namen von Orange auf der Administrationswebseite des RIPE NCC angemeldet. Das RIPE NCC verwaltet nicht nur die IP-Adressräume von Europa über den Nahen Osten bis nach Zentralasien, sondern bietet auch digitale Zertifikate an, mit denen das Routing im Internet abgesichert werden kann. Genau diese Zertifikate (genauer: Route Origin Authorisations, ROA) hat der Angreifer ändern lassen und damit dafür gesorgt, dass die Router anderer Internetprovider denen von Orange nicht mehr vertrauten.

Da der Angreifer mit Screenshots bei Twitter/X angegeben hat, ist auch bekannt geworden, dass die Ursache für den großen Ausfall mit einem sehr einfachen Passwort („ripeadmin“) zusammenhing und die Administrationswebseite auch keinen zweiten Faktor für so weitreichende Änderungen benötigte. Hier hätten beide Seiten besser agieren können: die Nutzer bei Orange, indem sie auch für externe Dienste sichere Passwörter wählen und die angebotene Zwei-Faktor-Anmeldung aktivieren. Und der Anwendungsanbieter RIPE NCC, der so triviale Passworte abweisen und die Zwei-Faktor-Anmeldung verpflichtend machen sollte. 

Tatsächlich sind Vorgaben für Passwörter bei Onlinediensten nicht immer so streng, wie man es von internen Anwendungen kennt. Suood Alroomi und Frank Li vom Georgia Institute of Technology haben letztes Jahr einen großen Scan von 20.000 Webanwendungen durchgeführt und beim Anlegen von Nutzerkonten ausprobiert, wie schwach ein Passwort sein konnte. Ein erschreckendes Ergebnis: Die Hälfte der getesteten Seiten akzeptierte sehr schwache Passwörter wie „123456“ oder „password“. Mit verschiedenen Stichproben haben sie dabei auch gezeigt, dass populäre Seiten häufiger mit strengeren Regeln aufwarteten als solche, die weiter hinten in den Rankings der Top-1-Million liegen.

Aber war nun das triviale Passwort die Ursache für den Ausfall? In diesem Fall hätte der Angreifer nicht viele Versuche beim Raten benötigt. Aber nach den von ihm geposteten Screenshots zu urteilen, brauchte er gar nicht erst zu raten, da scheinbar die Racoon-Malware auf einem System lief und dort unter anderem die RIPE-Zugangsdaten abgegriffen wurden.

Wie sieht es bei Ihnen aus? Gibt es eine Übersicht über alle Zugangsdaten für externe Dienste – vom Social-Media-Account über Dienstleister-Weboberflächen bis zum ELSTER-Steuerkonto? Entsprechen die Passwörter Ihren Anforderungen und sind sie sicher abgelegt? In Pentests finden wir gelegentlich immer noch gemeinsam gepflegte Excel-Tabellen mit solchen Zugangsdaten.

Mehr Details zum Orange-Ausfall: https://doublepulsar.com/how-50-of-telco-orange-spains-traffic-got-hijacked-a-weak-password-d7cde085b0c5

Der wissenschaftliche Artikel zur Verbreitung von Passwort-Vorgaben: https://dl.acm.org/doi/abs/10.1145/3576915.3623156

Die Umwelt und die Sicherheit

Am Beispiel der Gegenmaßnahmen zu den Prozessorlücken Spectre und Meltdown hat die Forscherin Henriette Hofmeier aufgezeigt, dass sich mit einem gezielten Einsatz von Sicherheitsmaßnahmen auch der Energieverbrauch senken lässt. In diesem Fall deaktivieren die Gegenmaßnahmen Optimierungen und verbrauchen zusätzliche Taktzyklen. Sie werden aber eigentlich nur benötigt, wenn besonders schützenswerte Informationen aktiv verarbeitet werden, beispielsweise die privaten Schlüssel beim Verschlüsseln. Trotzdem werden sie in der Praxis derzeit global für das gesamte System dauerhaft aktiviert. Wie Hofmeier mit Änderungen am Linux-Kernel gezeigt hat, geht das auch anders – dann müssen allerdings die Anwendungen ihren Schutzbedarf auch an den Kernel melden, damit dieser die passenden Maßnahmen an- und ausschalten kann.

Dieses Spannungsfeld existiert auch an vielen anderen Stellen. Ein äußerst plakatives Beispiel bilden signierte Mails, in denen die Signatur in der Regel den eigentlichen Textanteil um ein Vielfaches übersteigt. Aber deshalb gleich alle Sicherheitsmaßnahmen abstellen, ist auch keine Lösung. Eher sollten, wie in Hofmeiers Arbeit gezeigt, die für den Schutzbedarf passenden Maßnahmen zur richtigen Zeit greifen.

https://inf.gi.de/04/wie-viel-energie-darf-schutz-kosten

https://sys.cs.fau.de/publications/2022/hofmeier_22_thesis.pdf

Aufstieg und Niedergang des Mirai-Botnetzes

Falls das Jahr es bei Ihnen noch ruhig angehen lässt, hätte ich noch einen längeren Lesetipp. Schon im November veröffentlichte Andy Greenberg einen sehr ausführlichen Artikel über die Anfänge und das Ende des Mirai-Botnetzes. Sie erinnern sich vermutlich an das damals größte Botnetz, das zwar hauptsächlich aus leistungsschwachen Webcams bestand, aber durch die schiere Masse an Geräten ganze Internetprovider per DDoS überlasten konnte.

Der Artikel geht auf die technischen Aspekte nur so weit wie notwendig ein und konzentriert sich eher auf die Entstehungsgeschichte und die spätere Entdeckung und Läuterung der Verursacher. Mit vielen Emotionen und einer Art Happy End ist es auch eine (verspätete) kleine Weihnachtsgeschichte.

Ein weiterer spannender Aspekt der Geschichte: Die Macher des Botnetzes wollten zwischenzeitlich einen legitimen DDoS-Verteidigungsdienst aufbauen – und als dieser nicht so erfolgreich war, selbst per DDoS die Kunden zu sich treiben. Dieser Versuch war ebenfalls nicht von Erfolg gekrönt, so dass sie schlussendlich doch wieder zum reinen Verkaufen von offensiven Angriffen zurückkehrten.

https://www.wired.com/story/mirai-untold-story-three-young-hackers-web-killing-monster/

Seitenkanal des Monats: Ein Auto

Diesmal nehmen wir ein größeres Ziel für den Seitenkanal des Monats. Und auch die Richtung des Angriffs ist anders als in den letzten Digests. Heute geht es um ein Auto, genauer einen Tesla und dessen System für das autonome Fahren. Und statt direkt an Daten zu kommen, soll diesmal dem Gerät ein falsches Zertifikat untergejubelt werden. Forscher des Fachgebiets SecT der TU Berlin haben es geschafft, den Steuerungsrechner mit einer manipulierten Firmware zu starten. Eigentlich sollten kryptografische Prüfungen nur das Starten der Hersteller-Firmware erlauben, aber durch Glitchen der Versorgungsspannung konnte das Zertifikat für die Prüfung geändert werden.

Durch die so gestartete Firmware hatten die Forscher vollen Zugriff auf das laufende System und konnten auch Informationen auslesen. Alle Details gibt es im Vortrag der Forscher auf dem 37C3.

https://media.ccc.de/v/37c3-12144-back_in_the_driver_s_seat_recovering_critical_data_from_tesla_autopilot_using_voltage_glitching

Kompetenztraining Stabsarbeit: 25.01.2024 – Berlin

Die Mitglieder eines Krisenstabs sehen sich in Krisenlagen besonderen und zum Teil individuellen Herausforderungen gegenüber, die im Arbeitsalltag selten anzutreffen sind. Unklare Informationslagen, hohes Kommunikationsaufkommen und enormer Entscheidungsdruck sind dabei ebenso typische Gegebenheiten wie das anspruchsvolle Zusammenarbeiten verschiedener Persönlichkeiten in einer besonderen Bewältigungsorganisation. Diese Umstände erfordern neben organisatorischen Maßnahmen des Krisenmanagements auch gesonderte Kompetenzen der Stabsmitglieder. Ebendiese lassen sich schulen, indem die Funktionsträger aus ihrem Alltag herausgezogen und in simulierte Krisenlagen versetzt werden. So können sie wertvolle, praxisnahe Erfahrungen sammeln und sich auf den konkreten Ereignisfall vorbereiten.

In der Veranstaltung „Kompetenztraining Stabsarbeit“ kommen die Funktionsträger besonderer Aufbauorganisationen verschiedener Institutionen zusammen, um unabhängig vom eigenen beruflichen Umfeld die persönlichen Fähigkeiten zu verbessern.

https://www.hisolutions.com/security-consulting/academy#c12565

IBM Lizenz-Schulung: 21.02.2024 – remote

Das Lernziel in dieser Schulung ist, den Schulungsteilnehmenden die wichtigsten Vertragsarten der IBM und die darin enthaltenen Verbindungen zu weiteren Policies und Regelungen nahezubringen. Sie werden für vertragliche Pflichten sensibilisiert und sind mit den wesentlichen IBM-Lizenzmetriken bekannt. Außerdem wird der Ablauf eines Audits mit den entsprechenden Rechten und Pflichten in Grundzügen beleuchtet. Abschließend wird zur Überprüfung eine IBM-Lizenzbilanzierung im Rahmen eines Miniprojektes durchgeführt.

https://www.hisolutions.com/security-consulting/academy#c2077

KI – Chancen und Risiken für die Sicherheit bewerten: 27.02.2024 – remote

Der Wunsch, sich von künstlicher Intelligenz bei der Arbeit unterstützen zu lassen, ist groß. Aber was bedeutet das aus der Sicherheitsperspektive? Um entscheiden zu können, ob und wie der Einsatz reglementiert werden kann und sollte, muss man die Chancen und Risiken für die Informationssicherheit kennen. In dieser Schulung werden zuerst die wichtigsten Grundlagen zu aktuellen KI-Verfahren wie maschinelles Lernen (ML) und große Sprachmodelle (LLM) betrachtet. Darauf aufbauend wird auf die aktuellen Sicherheitsauswirkungen beim Einsatz dieser Verfahren in der Praxis eingegangen. Die Themenauswahl orientiert sich an den häufigsten Fragestellungen, die Informationssicherheitsbeauftragte (ISB) an uns herantragen.

https://www.hisolutions.com/security-consulting/academy#c12585