Seitenkanal des Monats: Das Bild, das den Nutzer beobachtet

Forschende der TU Graz haben einen spannenden Aufbau entwickelt, um herauszufinden, auf welchen Webseiten ein Nutzer surft. Dafür reicht ihnen ein offener Browser-Tab, in dem ein Bild sehr langsam vor sich hin lädt.

Das Szenario setzt voraus, dass der Angreifende es geschafft hat, das Opfer auf eine Webseite zu locken, und dass diese Seite in einem Browser-Tab weiterhin offen ist. Grundsätzlich sorgt der Browser wirksam dafür, dass ein Tab nichts von den Inhalten der anderen erfahren kann. Bei dem Angriff wird jedoch ausgenutzt, dass die Kommunikation zu den verschiedenen Webseiten durch den gemeinsam genutzten Internetzugang verläuft und sich dort die Bandbreite teilen muss. Die Forschenden haben jetzt einen Server so aufgesetzt, dass er sehr langsam ein Bild ausliefert und dabei genau beobachtet, wie schnell die Fragmente ausgeliefert werden können. Damit kann das Lastprofil des Internetzugangs des Opfers so gut rekonstruiert werden, dass typische Muster von populären Webseiten wiedererkannt werden können.

Zur besseren Veranschaulichung lohnt sich ein Blick auf die Beispielwebseite mit einer gelungenen Erläuterung und Demonstration. Außerdem haben die Forschenden die Latte für das Marketing zukünftiger Sicherheitslücken noch einmal etwas höher gehängt: Die Lücke hat nicht nur ein Logo, einen prägnanten Namen und eine Webseite, sondern auch noch ein Musikvideo.

https://www.snailload.com

Seitenkanal des Monats: Laser, die auf Bits schießen

Das BSI hat das Fraunhofer AISEC gebeten, sich das Signaturverfahren XMSS (eXtended Merkle Signature Scheme) anzuschauen – und zwar im Wortsinn „unter dem Mikroskop“. Dieses Verfahren ist gut gegen mögliche zukünftige Angriffe mithilfe von Quantencomputern gewappnet und bietet sich auch an, um die Integrität der Firmware von IoT-Geräten zu sichern. Im konkreten Anwendungsfall ist aber ein direkter Angriff auf das Gerät auch sehr wahrscheinlich – schließlich sind die Geräte außerhalb von gesicherten Rechenzentren verbaut und lassen sich stehlen.

Die Frage lautete also, wie sich dieses Signaturverfahren gegen Angreifer wehren kann, die physischen Zugriff auf das Gerät haben. Um das herauszufinden, nahmen sich die Fraunhofer-Forscher Mikroskop und Laser, um die entscheidenden Bits zu kippen, damit eine gefälschte Signatur als rechtmäßig durchgeht. Das hat auch grundsätzlich geklappt, aber für die Risikoabwägung ist auch wichtig, wie kompliziert der Angriff ist und wie sicher er funktioniert. In der BSI-Studie sind die Schritte beschrieben, wie die Forscher den Prozessor präpariert haben, durch Beobachtungen das Speicherlayout auf dem Chip nachvollzogen haben, die physischen Koordinaten einer Speicheradresse herausgefunden haben, den richtigen Zeitpunkt durch von außen beobachtbare Signale bestimmt haben und dann einen 1.600-ns-Laserimpuls zur richtigen Zeit auf die richtige Stelle gefeuert haben. In 50 bis 80 Prozent der Versuche brachte das den gewünschten Erfolg. In der Studie für das BSI sind die Schritte detailliert beschrieben, wobei auch dort hinter jedem kurzen Satz eine längere Experimentierserie steckt.

BSI-Studie mit dem technischen Ablauf: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/LFI_Attack_XMSS/LFI_Attack_XMMS.pdf

Artikel mit mehr mathematischen Details: https://eprint.iacr.org/2023/1572.pdf

Wenn der Dienstleister des Dienstleisters die Daten verliert

Wenn man sich als Veranstalter auf seine Veranstaltung konzentrieren will, übergibt man den Ticketverkauf an einen Dienstleister. Und schon kann man die Sorgen mit verschiedenen Zahlungsdienstleistern, einer möglichen Überlast zum Vorverkaufsstart und der Absicherung der persönlichen Daten der Besucher den Profis überlassen. Einer der Großen in diesem Geschäft ist TicketMaster: Dort wollte man einen Teil der IT auch den Profis überlassen und hat daher Dienste vom Cloud-Anbieter Snowflake genutzt.

Im Ergebnis bietet jetzt die Angreifergruppe Shinyhunters die Daten von 560 Millionen Ticketmaster-Kunden feil – also den Besuchern der Veranstalter, die genau diese Sorge loswerden wollten. Da mehrere Snowflake-Kunden gleichzeitig betroffen sind, vermuten einige, dass die Angreifer sich Zugriff auf den Cloud-Dienstleister selbst verschafft haben. Der bestätigt die Vorfälle, sieht die Ursache aber nicht bei sich, sondern eher bei seinen Kunden. Laut Snowflake sollen die Zugangsdaten zu Snowflake-Diensten den Kunden anderweitig gestohlen worden seien.

Wie auch immer der genaue Ablauf war: Am Ende müssen sich nun doch die Veranstalter um das digitale Wohl ihrer Besucher sorgen.

https://www.golem.de/news/nicht-nur-ticketmaster-datenlecks-bei-mehreren-kunden-des-gleichen-cloudanbieters-2406-185640.html

Mehr Bänder, mehr Back-ups!

Das Ende der Magnetbänder wurde schon aus verschiedenen Gründen angekündigt – seien es Virtual Tape Librarys oder Cloud-Back-ups. Ungeachtet dessen spielen sie weiter ihre Vorteile beim Back-up aus, und dazu passt die beruhigende Nachricht des LTO-Konsortiums: 2023 vertrieben die drei Hersteller dieses Bandtyps in Summe mehr Bandkapazität als je zuvor. Gerade bei Offline-Back-ups, die in Zeiten von Ransomware für Firmen überlebenswichtig sind, und bei der Archivierung können die Bänder punkten.

Ein Band der aktuellen Generation LTO-9 kann komprimiert 45 TB fassen und mit 1 GBit/s beschrieben werden. Und dazu kann man es leicht auswerfen und sicher verwahren.

DORA kommt und BAIT geht

Regulatorische Vorgaben zum Umgang mit IT-Risiken helfen, branchenweit ein gleiches Mindestmaß herbeizuführen. Aber dabei kann auch schnell ein „Zuviel“ an konkurrierenden Vorgaben entstehen. Daher ging ein Aufatmen durch die Finanzbranche, als die Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) in ihrem Juni-Rundschreiben ankündigte, dass mit dem Inkrafttreten der europäischen DORA-Verordnung Anfang nächsten Jahres die bisherigen Regeln der BAIT auslaufen.

Wer bisher bereits die nationalen Regeln der BaFin umgesetzt hat, setzt damit auch schon einen guten Teil der DORA-Anforderungen um. Aber es gibt Abweichungen im Detail und gänzlich neue Themen. Im Bereich des Outsourcings gibt es beispielsweise neue Anforderungen an das Notfallmanagement der Dienstleister und zu Exit-Strategien, falls es bei einem Dienstleister zu Problemen kommen sollte. Auch die Vorgaben zu Schulungen und Übungen sind strenger als zuvor. Was unsere Kollegen bei Kunden auch beobachten, ist die Unsicherheit darüber, wie einzelne Regeln konkret ausgelegt werden sollen. Es ist also noch einiges zu tun, um bis zum Inkrafttreten am 17.01.2025 alles umgesetzt zu haben. HiSolutions begleitet Sie gerne dabei, Ihre Sicherheitsdisziplinen auf das DORA-Level zu heben und effizient miteinander zu verzahnen.

Informationen zu DORA: https://www.bafin.de/DE/Aufsicht/DORA/DORA_node.html

Juni-Rundschreiben der BaFin: https://www.bafin.de/SharedDocs/Downloads/DE/Rundschreiben/dl_2024-05-29_MaRisk_Anschreiben_an_die_Verbaende_pdf_BA.pdf

Zum DORA-Beratungsangebot von HiSolutions: https://www.hisolutions.com/dora

Was ist echt? Was ist falsch?

Die folgende Geschichte klingt erst mal wenig passend für unseren Digest: Bei eBay wurde der Firmenausweis der Apple-Mitarbeiterin Nummer 10 zum Verkauf angeboten. Der Zugang zum heutigen Hauptsitz Apple Park ist damit wohl kaum möglich, aber für Sammler sind solche Originale sehr wertvoll. Aber stand dort wirklich ein Original zum Verkauf? Cabel Sasser, der sich öfter mit der Aufdeckung von gefälschten Erinnerungsstücken beschäftigt, stellte sich und später auch dem Verkäufer diese Frage.

Vermutlich ahnen Sie schon die Antwort, daher nehmen wir uns ein Artefakt der Unterhaltung heraus: eine deutsche Rechnung, mit der der Verkäufer die Provenienz beweisen wollte. Werfen Sie doch mal einen Blick auf die Rechnung und zählen Sie, wie viele Dinge Ihnen auffallen, die komplett falsch sind oder die Sie so nicht auf einer Rechnung des DRK erwarten würden. Da kommt einiges zusammen, aber lassen Sie uns gleich noch den Spieß umdrehen: Wie viele der Fehler haben Sie schon auf einer regulären privaten oder beruflichen Rechnung gesehen? Sicherlich nicht so geballt wie hier, aber einzeln passiert das schon mal.

Die Erkennung von gefälschten Nachrichten und Rechnungen bleibt ein schwieriges Feld – womit wir wieder bei unserem Thema Sicherheit und Prävention von Phishing und CEO-Fraud sind. Vielleicht können Sie besagte Rechnung auch gut als Aufhänger für die nächste Diskussion zur Awareness nutzen.

Zum Bild der gefälschten Rechnung: https://cabel.com/2024/05/16/the-forged-apple-employee-badge/#jp-carousel-4219

Der Blogartikel mit mehr Kontext und der Auflösung: https://cabel.com/2024/05/16/the-forged-apple-employee-badge/

Happy Birthday SYN, ACK!

Vor mehr als 50 Jahren fanden sich die ersten Computer zu Netzwerken zusammen. Damit kam auch schnell der Wunsch auf, die Grenzen dieser Netzwerke zu überschreiten und zwischen Netzwerken kommunizieren zu können – das Internetworking war erfunden. Wie immer in Pionierzeiten gab es viele verschiedene Ansätze. Die heute in Lehrbüchern so harmonisch nebeneinander dargestellten Ansätze des ISO-OSI-Schichtenmodells und von TCP/IP sind die wohl bekanntesten Konkurrenten jener Zeit. Sie führten sogar zu den transatlantischen „Protocol Wars“, die defacto von TCP/IP gewonnen wurden.

Als erstes Lebenszeichen von TCP/IP kann man die Mai-Ausgabe der „IEEE Transactions on Communications“ im Jahr 1974 annehmen, in der die beiden Protokolle und ihr Zusammenspiel in einem Artikel von Vinton Cerf und Robert Kahn eingeführt wurden. Daher feierte die IEEE auch jetzt am 19. Mai und nannte die Festivität ganz unbescheiden „den 50. Geburtstag des Internets“.

Wie in der Wissenschaft üblich, war aber nicht alles komplett neu oder bereits einsatzbereit, sondern basierte teilweise auf Vorarbeiten von Kollegen und wurde dann weiter verfeinert. So findet sich in dem Artikel bereits eine Skizze für den Handshake zum Verbindungsstart. Der ikonische Drei-Wege-Handshake mit „SYN, SYN ACK, ACK“ wurde aber erst kurz danach von Ray Tomlinson ergänzt, damals noch mit leicht erratbaren, zeitbasierten Initialwerten für die Sequenznummern, die dann später durch Zufallszahlen ersetzen wurden. Und so ist das Protokoll nicht nur robust gegen Ausfälle (das Ziel der frühen Internetworker), sondern auch heute noch gut gewappnet gegen Angreifer, die sich in die Verbindung einschleichen wollen.

Ein weiterer Vorteil der Schichtenmodelle ist, dass der Programmierer die Details der unteren Schichten nicht kennen muss, und dass sich die Protokollschichten um die gesamte Unbill komplexer Netzwerke kümmern. Das hat sicher auch dazu beigetragen, dass schnell viele TCP/IP-basierte Anwendungen entstanden und heute noch entstehen. Zu viel Abstraktion kann aber auch hinderlich sein. Daher wechselte das Protokollschwergewicht HTTP gerade vom Geburtstagkind TCP zum neueren QUIC als Grundlage – unter anderem, um mehr Einfluss auf die Flusskontrolle zu haben und den Verbindungsaufbau zu beschleunigen.

Video der Geburtstagsfeier: https://ieeetv.ieee.org/video/our-virtual-celebration-of-50-years-of-the-internet-an-ieee-milestone-event

Der ursprüngliche Artikel von 1974, leider nur über gut sortierte wissenschaftliche Bibliotheken lesbar: https://ieeexplore.ieee.org/document/1092259

Öffentlicher RFC, etwas später im Jahr 1974 veröffentlicht: https://datatracker.ietf.org/doc/html/rfc675

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.

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

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/