Zentrale technische Untersuchungsergebnisse zur Schlüsselbeschaffung durch Storm-0558

 (msrc.microsoft.com)
1 Punkte von GN⁺ 2023-09-07 | 1 Kommentare | Auf WhatsApp teilen
  • Technische Untersuchungsergebnisse zu einem Vorfall, bei dem der in China ansässige Bedrohungsakteur Storm-0558 mit einem entwendeten MSA-Consumer-Signaturschlüssel Tokens fälschte und damit auf OWA und Outlook.com zugriff
  • Ein Crash Dump, der im April 2021 durch einen Absturz des Consumer-Signatursystems erzeugt wurde, enthielt aufgrund einer Race Condition den Schlüssel; das System erkannte dies nicht
  • Der Crash Dump mit dem Schlüssel wurde aus einem isolierten Produktionsnetzwerk in eine Debugging-Umgebung des mit dem Internet verbundenen Unternehmensnetzwerks verschoben; auch ein Credential Scan erkannte ihn nicht
  • Dass mit einem Consumer-Schlüssel auf Enterprise-Mail zugegriffen werden konnte, lag daran, dass Entwickler des Mail-Systems die Scope-Prüfung der Bibliothek falsch einschätzten und keine issuer/scope-Prüfung ergänzten
  • Alle Schwachstellen wurden behoben; als Nachmaßnahmen wurden mehrschichtige Abwehrmaßnahmen wie automatisierte Key-Scope-Prüfung verstärkt

Wie der Schlüssel erlangt wurde

  • Microsoft betreibt eine isolierte und eingeschränkte Produktionsumgebung mit Background Checks, dedizierten Konten, Secure Access Workstations und Multi-Faktor-Authentifizierung auf Basis von Hardware-Tokens
    • Diese Umgebung blockiert die Nutzung von Kollaborationstools wie E-Mail, Meetings und Web-Recherche, um Wege zur Kontoübernahme wie Malware-Infektionen und Phishing zu verhindern
    • Zugriff auf Systeme und Daten wird durch Just-in-Time- / Just-Enough-Access-Richtlinien beschränkt
  • Die Unternehmensumgebung (corporate environment) verlangt Sicherheitsauthentifizierung und sichere Geräte, erlaubt aber E-Mail, Meetings und Kollaborationstools und ist dadurch anfällig für Spear-Phishing, Token-stehlende Malware und Ähnliches
    • Gemäß Zero-Trust- und „assume breach“-Prinzipien darf Schlüsselmaterial die Produktionsumgebung nicht verlassen
  • Im April 2021 erzeugte ein Absturz des Consumer-Signatursystems einen Crash Dump (Snapshot des abgestürzten Prozesses)
    • Crash Dumps maskieren sensible Informationen und sollten daher keine Signaturschlüssel enthalten; aufgrund einer Race Condition war der Schlüssel jedoch enthalten (behoben)
    • Das System erkannte nicht, dass sich ein Schlüssel im Crash Dump befand (behoben)
  • Der Crash Dump, von dem damals angenommen wurde, dass er keinen Schlüssel enthält, wurde aus dem isolierten Produktionsnetzwerk in eine Debugging-Umgebung verschoben
    • Dies entsprach den Standard-Debugging-Verfahren; ein Credential Scan erkannte den vorhandenen Schlüssel nicht (behoben)
  • Nach dem Schlüsselabfluss kompromittierte der Akteur Storm-0558 das Unternehmenskonto eines Microsoft-Ingenieurs
    • Dieses Konto hatte Zugriff auf die Debugging-Umgebung, in der sich der Crash Dump mit dem Schlüssel befand
    • Aufgrund der Log-Aufbewahrungsrichtlinien gibt es keine konkreten Log-Beweise für den Abfluss; dies ist jedoch der wahrscheinlichste Weg, auf dem der Schlüssel erlangt wurde

Warum mit einem Consumer-Schlüssel auf Enterprise-Mail zugegriffen werden konnte

  • Als Reaktion auf Kundenbedarf nach Unterstützung sowohl von Consumer- als auch von Enterprise-Anwendungen wurde im September 2018 ein gemeinsamer Endpunkt zur Veröffentlichung von Schlüsselmetadaten eingeführt
    • Im Rahmen des integrierten Angebots wurde die Dokumentation aktualisiert, um die Anforderungen an die Key-Scope-Prüfung für Enterprise- und Consumer-Konten klarzustellen
  • Zwar wurde eine API zur kryptografischen Prüfung von Signaturen bereitgestellt, die Bibliothek wurde jedoch nicht so aktualisiert, dass sie die Scope-Prüfung automatisch durchführt (behoben)
  • Das Mail-System wurde 2022 aktualisiert, um den gemeinsamen Metadaten-Endpunkt zu verwenden
    • Entwickler des Mail-Systems nahmen fälschlicherweise an, dass die Bibliothek die vollständige Prüfung durchführt, und ergänzten nicht die erforderliche issuer/scope-Prüfung
    • In der Folge akzeptierte das Mail-System Anfragen an Enterprise-Mail mit Sicherheitstokens, die mit einem Consumer-Schlüssel signiert waren (durch aktualisierte Bibliothek behoben)

Nachträgliche Prüfung und Verbesserungsmaßnahmen

  • Identifizierung und Behebung der Race Condition, durch die ein Signaturschlüssel in einen Crash Dump aufgenommen werden konnte
  • Stärkung von Prävention, Erkennung und Reaktion für Fälle, in denen Schlüsselmaterial fälschlicherweise in Crash Dumps enthalten ist
  • Verbesserung des Credential Scanning, um das Vorhandensein von Signaturschlüsseln in Debugging-Umgebungen besser zu erkennen
  • Bereitstellung einer verbesserten Bibliothek, die die Key-Scope-Prüfung in Authentifizierungsbibliotheken automatisiert, sowie Präzisierung der zugehörigen Dokumentation

Update vom 12. März 2024

  • Die Kernhypothese bleibt bestehen, dass Schlüsselmaterial aufgrund eines betrieblichen Fehlers die Umgebung für das Signieren von Sicherheitstokens verlassen hat und über ein kompromittiertes Ingenieurskonto in der Debugging-Umgebung zugänglich war; es gibt keine Änderungen bei den Auswirkungen auf Kunden oder Microsoft oder bei den Aktivitäten des Akteurs
  • Es hieß, ein Crash Dump aus dem Jahr 2021 könne die Ursache für den Zugriff des Akteurs gewesen sein, doch es wurde kein Crash Dump gefunden, der das betroffene Schlüsselmaterial enthält
  • Die erwähnte Race Condition betraf nicht die Frage, ob sich ein Schlüssel im Crash Dump befand, sondern ob ein Crash Dump aus der sicheren Signaturumgebung herausgebracht werden konnte
  • Die Formulierung, dass das Herausbringen des Crash Dumps den Standard-Debugging-Verfahren entsprach, bedeutete, dass es früher nicht verboten war; die heutigen Standard-Debugging-Verfahren von Microsoft verbieten das Herausbringen solchen Materials aus Produktionsumgebungen
  • Die laufende Untersuchung hat Grenzen der Credential-Scanning-Technologie aufgezeigt; diese sollen behoben werden, sobald sie entdeckt werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-09-07
Hacker-News-Kommentare

  • Hier scheint ein fehlendes Bindeglied zu sein: Es ist leicht nachzuvollziehen, dass ein Private Key durch einen Concurrency-Bug oder einen Memory-Safety-Bug versehentlich in Debugging-Artefakte geraten kann. Aber der Angreifer müsste doch von dem Crash und der Struktur des Crash-Dumps gewusst haben und innerhalb des Microsoft-internen Netzes auf der Lauer gelegen haben, oder?
    Defense assuming breach ist eine gute Strategie für Netzwerksicherheit, aber man sollte die Annahme, dass man tatsächlich kompromittiert wurde, nicht einfach hinnehmen.

    • Wenn ich ein chinesischer Advanced Persistent Threat (APT) wäre und mit Mitarbeiter-Credentials in das interne Microsoft-Netz eingedrungen wäre, würde ich als Erstes herausfinden, wo Crash-Logs gespeichert werden, und sie zusammen mit Debug-Symbolen leise exfiltrieren.
      Solche Daten werden im Verhältnis zu ihrem tatsächlichen Wert oft nicht ausreichend sicher aufbewahrt. Aus meiner Zeit bei FAANG weiß ich: Neueinsteiger ohne Erfahrung mit Finanz- oder Unternehmensregulierung halten es fast alle für okay, Crash-Daten an Bugtracker anzuhängen. Deshalb muss man die Gewohnheiten so ändern, dass Dinge wie Crash-Dumps in einem Tresor landen, der so einfach zu benutzen ist, dass niemand ihn umgehen möchte.
      Hat man ein kompromittiertes Engineering-Konto, hat man mindestens Zugriff auf den Bugtracker und vermutlich auch die Möglichkeit, Debug-Symbole der Binaries zu bekommen oder zu erzeugen. Dann muss man nur noch warten, bis irgendein Engineer unvorsichtig einen Crash-Dump als Bug-Anhang hochlädt, und ihn sich holen, bevor jemand es bemerkt und löscht.
    • Dem Artikel zufolge geschah die Kompromittierung des Mitarbeiterkontos, nachdem der Crash-Dump ins interne Netz verschoben worden war. Microsoft sagt zwar, es gebe keine Belege für eine Exfiltration, aber für die Kompromittierung des Kontos scheint es nach meinem Verständnis durchaus Belege zu geben.
      Außerdem hat Microsofts Credential-Scanning-Tool den Schlüssel nicht gefunden, und dieses Problem sei behoben worden; der Schlüssel war also offenbar in einer Form vorhanden, die per Scan erkennbar war.
      Insgesamt wirkt es so, als hätte ein Engineer den Dump mit dem Schlüssel unter seinem eigenen Konto abgelegt und eine Weile liegen lassen. Später brach ein Angreifer in das Konto ein, nahm alle brauchbaren Dateien mit und scannte dann mit besseren Tools als Microsoft nach Schlüsseln – und landete einen Volltreffer.
    • Wenn die zitierte Darstellung stimmt, wurde der Schlüssel nach April 2021 über einen Crash-Dump in die interne Umgebung geleakt. Danach kompromittierte Storm-0558 das interne Konto eines Microsoft-Engineers, und dieses Konto hatte Zugriff auf die Debugging-Umgebung, in der der Crash-Dump mit dem fälschlich enthaltenen Schlüssel lag.
      Das heißt: Entweder war der Angreifer bereits im Netzwerk und fand den Dump zufällig bei einem unentdeckten Scan, oder dieses konkrete Konto war von Anfang an das Ziel.
    • Soweit ich weiß, gab es schon seit den Zeiten der Cold-Boot-Angriffe Standard-Tools, um in Memory-Dumps nach kryptografischem Material zu suchen. Man kann sich durchaus vorstellen, dass ein Angreifer aus dieser Perspektive opportunistisch nach Crash-Dumps sucht.
      Trotzdem wirkt die Ereigniskette aus Sicht des Angreifers schon übermäßig glücklich gefügt.
    • Wenn man in ein System eingedrungen ist und im Dateisystem sshd.core sieht, nimmt man das doch selbstverständlich mit.

  • Es gibt System-Engineering-Kurse, die behandeln, wie kleine Probleme in einer bestimmten Reihenfolge aufeinanderfolgen und schließlich zu einem katastrophalen Versagen führen. Dieser Fall ist genau so ein katastrophales Versagen.
    Zuerst muss es eine Race Condition geben, und diese Race Condition muss zu einem unerwarteten Ergebnis führen. Wenn der Code getestet wurde und häufig genutzt wird, liegt die Eintrittswahrscheinlichkeit hier vermutlich schon unter 10 %. Danach muss ein Engineer ausgerechnet entscheiden, dass er diesen Crash-Dump braucht; die Credential-Scanning-Software darf genau diese Credentials nicht finden; ein Konto muss kompromittiert werden und dadurch Netzwerkzugriff entstehen; dieser Nutzer muss Zugriff auf diesen Dump haben; und der Hacker muss ihn finden und mitnehmen.
    Eigentlich hätte es trotzdem sicher sein sollen, weil der Schlüssel alt war und nur für den Zugriff auf Consumer-E-Mail-Konten verwendbar sein sollte. Doch es gab zusätzlich einen Bug, der alte Schlüssel akzeptierte, und einen weiteren Bug, der diesen Signaturschlüssel nicht für Tokens von Firmen-E-Mail-Konten ablehnte.
    Eine gute Lektion in System Engineering: Egal wie sehr man sich bemüht, irgendwann sammeln sich genug Kleinigkeiten an, dass ein großer Vorfall passiert. Also muss man so entwerfen, dass selbst dann der Blast Radius begrenzt bleibt.

    • In der Sicherheit braucht es den Hinweis, dass solche Ketten nicht wie ein Zufallsprozess entstehen, sondern aktiv anvisiert und ausgenutzt werden. Angreifer werfen keine Münzen völlig zufällig; sie können eine Münze, die häufiger Kopf zeigt, zu ihren Gunsten werfen.
      Post-Mortems stellen es gern so dar, als hätten sich unglückliche Ereignisse zufällig überlagert: Der Angreifer hatte zufällig Microsoft im Visier, es gab zufällig eine Race Condition, zufällig kam es zu einem Crash, und zufällig fand man irgendwo einen Crash-Dump.
      Man muss aber auch die Möglichkeit in Betracht ziehen, dass schon der ursprüngliche Race-Condition-Bug absichtlich eingebaut wurde. Der Crash könnte gezielt ausgelöst worden sein, der Angreifer könnte darauf gewartet haben, dass der Dump an einem bestimmten Ort entsteht, und es könnte einen Komplizen gegeben haben.
    • Es klingt so, als würdest du voraussetzen, dass Microsoft System Engineering betreibt und Produkte testet; die Realität scheint davon weit entfernt zu sein.
      Das Microsoft-Ökosystem wirkt wie ein Lego-Auto, das Nachbarskinder aus Teilen zusammengefrickelt haben, die jeder von zu Hause mitgebracht hat.
    • „Race Condition“ ist die Begründung, die alle benutzen, um dem Management einen dummen Bug zu erklären. „Der Masker war asynchron, deshalb begann der Writer, den Dump zu schreiben, bevor der Masker gesetzt war“ klingt einfach nach einer völlig unsinnigen Implementierung.
      Wenn man „Race Condition“ sagt, reden die Leute von „unter 10 % Eintrittswahrscheinlichkeit“, aber in Wirklichkeit könnte es bei jedem größeren Crash passieren – nur crasht es eben nicht so oft.
      Warum nicht vor dem Schreiben auf die Platte maskiert wurde, weiß wohl nur Gott.
    • Solche unbekannten unbekannten katastrophalen Fehler hat es immer gegeben und wird es immer geben. Deshalb braucht es Resilienz und vermutlich eine weniger zentralisierte Perspektive.
      Dass mehr als die Hälfte der westlichen Geschäftswelt von Outlook.com abhängt, ist ziemlich nah an einem völlig verfehlten Zustand. Aber die derzeitigen finanziellen Anreize sind nicht auf Resilienz oder darauf ausgerichtet, hyperzentralisierte Instanzen wie Outlook.com aufzubrechen; daher wird so etwas wohl weiter passieren.
    • Beim Lesen dachte ich: „Da sind aber wirklich viele Nadelöhre getroffen worden.“ Es fühlt sich an, als wäre Voyagers Grand-Tour-Gravitationsassistenz-Trajektorie aus Versehen passiert.

  • Es gibt Punkte, die nicht klar erklärt werden: Wenn es am 11. Juli 2023 entdeckt wurde und der Vorfall mutmaßlich im April 2021 begann, heißt das, dass der Angreifer diese Zugangsdaten mehr als zwei Jahre lang hatte und dass es von der Entdeckung bis zur Offenlegung zwei Monate dauerte.
    Es fehlt auch, wie viele Tokens gefälscht wurden und wie weit der Zugriff reichte. Wenn man das nicht offenlegt, liegt eine ungünstige Annahme nahe.
    Auch ein Zeitplan von der Entdeckung bis zum Ausrollen des Fixes fehlt; es heißt nur: „Dieses Problem wurde behoben“. Man kann nur hoffen, dass es schnell behoben wurde.
    Die vier unmittelbaren Probleme wurden behoben, aber es scheint eindeutig ein systemisches Problem zu geben, und es ist nicht ersichtlich, was dagegen unternommen werden soll.

    • Eine ungünstige Schlussfolgerung ist völlig plausibel.
      https://en.m.wikipedia.org/wiki/Adverse_inference
    • Wenn diese Zugangsdaten zwei Jahre später immer noch gültig waren, fragt man sich, wie bitte die Richtlinie zur Rotation von Zugangsdaten aussieht.

  • Für einen solchen Einbruch ist ein sehr tiefes Verständnis der internen Infrastruktur von Microsoft nötig. Es ist wohl sicher, von der organisierten Arbeit eines Hacker-Teams auszugehen.
    Billig ist so etwas nicht, aber der Lohn ist enorm. Hyperzentralisierung führt dazu, dass Hacker ihre Anstrengungen auf wenige hochwertige Ziele konzentrieren. Denn wenn sie Erfolg haben, ist der Gewinn gewaltig.
    Ich bin mir ziemlich sicher, dass es staatlich unterstützte Hacker-Teams gibt, die die interne Infrastruktur von Google, Microsoft, Amazon und ähnlichen Unternehmen bereits intensiv untersuchen und analysieren. Dieser Einbruch zeigt, wie gut sie sie bereits verstehen.
    Meiner Meinung nach ist es an der Zeit, innerhalb weiter gefasster Sicherheitsgrenzen zu dezentralisieren.

    • Wenn eine Organisation groß genug ist, sollte man davon ausgehen, dass staatliche Akteure intern mitarbeiten. Leider kann jeder jederzeit kompromittiert werden, daher lässt sich diese Annahme kaum vermeiden.

  • Wenn man die vorsichtige Formulierung weglässt: Jemand hat in der Produktionsumgebung einen Minidump auf eine Entwickler-Workstation heruntergeladen, und der lag dann vermutlich irgendwo im internen OneDrive dieses Entwicklers herum, bis das Konto kompromittiert wurde. Jemand hat sich den Dump geholt, den Schlüssel gefunden und damit den Jackpot geknackt.

    • Entscheidend dafür, dass dieser Angriff tatsächlich so weit erfolgreich sein konnte, war, dass Microsoft-Entwickler auf ihren eigenen Libraries und ihrer eigenen Infrastruktur keine sicheren Authentifizierungsprüfungen implementiert hatten.
    • Außerdem gab es ein Redaktions-/Maskierungssystem, das den Schlüssel nicht unkenntlich machte, und ein Erkennungssystem, das ihn nicht fand. Danach wurde der Schlüssel in einem völlig anderen System mit völlig anderem Zugriffsniveau verwendet, und es funktionierte einfach.
      Die Formulierung, „ein paar obskure Bugs seien raffiniert ausgenutzt worden“, wirkt etwas daneben. Es sieht eher nach einer Kette von Fehlern aus, bei der keines der Sicherheitssysteme seine Aufgabe erfüllt hat.

  • Ich verstehe nicht, warum kein HSM verwendet wurde. Ist der zentrale Zweck solcher Hardware nicht gerade die Verhinderung der Exfiltration von Schlüsselmaterial?

    • Diese Unternehmen behaupten [1], das „weltweit schnellste Payment-HSM“ zu haben, das „mehr als 20.000 Transaktionen pro Sekunde“ verarbeiten kann. Die Spitzenlast beim Signieren von Microsoft-Konto-Authentifizierungstokens dürfte wahrscheinlich deutlich höher liegen.
      [1] https://www.futurex.com/download/excrypt-ssp-enterprise-v-2-...
    • Nach der Art der Beschreibung dachte ich, die von ihnen erhaltenen Crash-Logs kämen aus einem HSM.

  • Das bedeutet, dass der Schlüssel nicht in nicht auslesbarer Hardware gespeichert war, sondern für einen gewöhnlichen Serverprozess zugänglich war: einfach kompilierter Code, der in einer hochprivilegierten Umgebung lief.
    Es gibt auch keinen Hinweis darauf, dass das System mit Zugriff auf diesen Schlüssel in einer separaten Umgebung statt in der normalen Produktionsumgebung lag. Daher kann man annehmen, dass jedes beliebige Produktionsgerät Zugriff auf den Schlüssel haben konnte und jeder mit Zugriff auf diese Umgebung potenziell Schlüsselmaterial exfiltrieren konnte.

  • Wenn man sich den Validierungsabschnitt unter https://learn.microsoft.com/en-us/azure/active-directory/dev... ansieht, scheint – sofern ich nichts übersehen habe – weiterhin der wichtige Hinweis zu fehlen, dass das Datum des Ausstellers und ein Widerruf geprüft werden müssen.
    Auch im Pseudocode steht es nicht, daher ist es gut möglich, dass es weitere Implementierungen gibt, die jedem Schlüssel vertrauen, den Microsoft irgendwann einmal veröffentlicht hat. Abgesehen von Ausnahmen wie dem Löschen von Caches.

    • Genau das ist der besorgniserregendste Teil. Microsoft-Entwickler konnten auf ihren eigenen Libraries und ihrer eigenen Infrastruktur keine sicheren Authentifizierungsprüfungen implementieren.
      Wenn nicht einmal Microsoft seine eigene Identitätsplattform in seinem Vorzeigeprodukt Outlook korrekt verwenden kann, welche Chance haben dann andere?
    • Das ist das Kernproblem. Alle reden über Crash-Dumps und Leaks, aber im Kern geht es darum, dass Microsoft weder die Gültigkeit des Schlüssels noch den Nutzungskontext des Schlüssels geprüft hat. Der geleakte Schlüssel war bereits ungültig, und er war auch kein Schlüssel, der zum Erstellen von Admin-Tokens zugelassen war.
      Es wurde einfach nur geprüft, ob eine Microsoft-CA signiert hatte. Das ist ein Problem, das in einem Code-Review unglaublich offensichtlich auffallen müsste.

  • Einer der Gründe, warum es so schlimm wurde, scheint zu sein, dass der Schlüssel nicht rotiert wurde. Es klingt so, als sei zwischen dem Zeitpunkt, an dem der Schlüssel an einen Ort gelangte, an dem er nicht hätte sein dürfen, und dem Zeitpunkt, an dem er tatsächlich gestohlen wurde, ziemlich viel Zeit vergangen.
    Wären Schlüssel regelmäßig rotiert worden, wäre es unmöglich gewesen, mit diesem Schlüssel Tokens zu fälschen.

  • Ich denke das jedes Mal, wenn solche Texte erscheinen: Es wirkt wirklich merkwürdig, dass die Reaktion auf Angriffe auf staatlichem Niveau privaten Unternehmen überlassen wird, nur weil der Angriff nicht physisch, sondern digital ist.
    Wenn ein chinesischer Kampfjet über dem Pazifik ein FedEx-Flugzeug abgeschossen hätte, würde das als Angriff auf die Souveränität der USA gelten, und die Regierung hätte angemessen reagiert. Niemand würde erwarten, dass FedEx eigene Kampfjet-Staffeln unterhält, um seine Transportflugzeuge zu schützen. Niemand würde sagen: „Selbst schuld, FedEx hat keine ordentliche Flugabwehr betrieben.“
    Sobald es aber in den digitalen Raum geht, entsteht eine Stimmung, in der man akzeptiert, dass Microsoft sich selbst gegen China und Russland verteidigen muss.

    • Wenn eine Gruppe Chinesen eine US-Bank, etwa die Federal Reserve, ausgeraubt und enorme finanzielle Schäden verursacht hätte, aber niemand gestorben wäre, wäre die Reaktion ähnlich. Erst recht, wenn Verbindungen zur tatsächlichen chinesischen Regierung vermutet würden, sich aber nur schwer eindeutig beweisen ließen.
      Regierungen nehmen ziemlich regelmäßig ausländische Agenten fest, aber solche Festnahmen führen nicht zu einem totalen Krieg.
    • Anders als im Beispiel mit dem FedEx-Flugzeug wurde hier keine Infrastruktur angegriffen oder zerstört, und es gab auch keine Todesopfer. Es wurden lediglich E-Mails von US-Regierungsvertretern gelesen.
      Zweitens tun die USA solche Dinge ebenfalls ständig, auch gegenüber befreundeten Staaten, weshalb härtere Maßnahmen schwer zu rechtfertigen sind.
    • Der digitale Raum hat grundsätzlich ein geringeres Risikoniveau und ist schwieriger zu verteidigen als der physische Raum. Es ist gut, dass man auf Cyberangriffe nicht wie auf physische Angriffe reagiert. Sonst wäre die Lage schon vor mehr als zehn Jahren bis zu einem Atomkrieg eskaliert.
      Umfang und Menge von Cyberangriffen sind sehr groß, aber nach meinem Verständnis führen auch die USA in entsprechendem Maß viele externe Angriffe durch.
    • Es gibt mehrere Fälle, in denen ein Staat Passagierflugzeuge abgeschossen oder Schiffe aufgebracht hat, ohne dass dies als Kriegsakt behandelt wurde.
    • Ein aus den USA nach Asien fliegendes Zivilflugzeug mit einem US-Kongressabgeordneten an Bord wurde abgeschossen, aber tatsächlich kam es nicht zum Dritten Weltkrieg: https://en.wikipedia.org/wiki/Korean_Air_Lines_Flight_007