Umgehung der Flughafensicherheit durch SQL-Injection

 (ian.sh)
1 Punkte von GN⁺ 2024-08-30 | 1 Kommentare | Auf WhatsApp teilen
  • Wenn im KCM/CASS-Authentifizierungsablauf der TSA ein System auf Airline-Seite kompromittiert wurde, konnten beliebige Nutzer so hinzugefügt werden, als hätten sie die Überprüfung ihres Beschäftigungsstatus bestanden; das hätte bis zur Umgehung der Sicherheitskontrolle oder zum Zugang zum Cockpit führen können
  • FlyCASS stellte kleinen Airlines ein CASS-Webinterface bereit, und über eine SQL-Injection auf der Login-Seite von Air Transport International war ein Admin-Login möglich
  • Die Admin-Oberfläche konnte neuen Mitarbeitern ohne zusätzliche Prüfung KCM- und CASS-Berechtigungen erteilen; ein Testnutzer wurde in beiden Systemen als genehmigt angezeigt
  • Nach der Offenlegung gegenüber ARINC, FAA und DHS/CISA Ende April 2024 bestätigte das DHS, dass FlyCASS von KCM/CASS getrennt wurde, reagierte aber nicht auf Korrekturanfragen zur Darstellung der TSA
  • Die TSA erklärte, wegen der Prüfung vor Ausgabe eines KCM-Barcodes sei kein Zugang zu Checkpoints möglich; im tatsächlichen Verfahren existierte jedoch weiterhin ein Pfad zur manuellen Eingabe der Mitarbeiter-ID, sodass die Auswirkungen der Schwachstelle größer waren

Welche Prüfungen KCM und CASS übernehmen

  • Known Crewmember(KCM) ist ein Programm der TSA, das Piloten und Flugbegleitern erlaubt, auch bei privaten Inlandsreisen die Sicherheitskontrolle zu umgehen
    • Mitarbeiter zeigen in einer speziellen Schlange einen KCM-Barcode vor oder nennen einem TSA-Mitarbeiter ihre Mitarbeiternummer und Airline
    • Der Laptop des TSA-Mitarbeiters prüft bei der Airline den Beschäftigungsstatus; bei Erfolg darf der Mitarbeiter ohne separate Kontrolle in den Sicherheitsbereich
  • Cockpit Access Security System(CASS) ist ein separates System zur Prüfung der Berechtigung für Cockpit-Zugang
    • In den meisten Flugzeugen gibt es im Cockpit, hinter den fliegenden Piloten, einen Jumpseat
    • Wenn Piloten pendeln oder sich versetzen lassen und es schwierig ist, einen bezahlten Sitzplatz zu nutzen, können sie den Jumpseat verwenden
    • Gate-Mitarbeiter prüfen über CASS, ob der Jumpseat-Nutzer ein zugelassener Pilot ist, und können der Crew mitteilen, dass die CASS-Authentifizierung erfolgt ist
  • Kern beider Verfahren ist die Bestätigung des aktuellen Beschäftigungsstatus bei der Airline
    • Wer kein Airline-Mitarbeiter ist, hat keine Hintergrundüberprüfung durchlaufen; daher dürfen Umgehung der Sicherheitskontrolle oder Cockpit-Zugang nicht erlaubt sein
    • Um zu prüfen, ob es sich um die berechtigte Person handelt, wird auch ein Foto des Crewmitglieds zurückgegeben

ARINC und die Authentifizierungssysteme der einzelnen Airlines

  • ARINC ist eine Tochter von Collins Aerospace und scheint von der TSA mit dem Betrieb von KCM beauftragt zu sein
  • ARINC betreibt eine Online-Website, auf der Piloten und Flugbegleiter ihren KCM-Status prüfen, sowie zentrale Komponenten wie eine API, die Genehmigungsanfragen zwischen Airlines routet
  • Offenbar betreibt jede Airline ihr eigenes Authentifizierungssystem, um an KCM und CASS teilzunehmen; dieses System interagiert mit dem Hub von ARINC
    • TSA und Airlines können Anfragen wie CockpitAccessRequest oder CrewVerificationRequest an ARINC senden
    • ARINC routet die Anfrage an das System der jeweiligen Airline und erhält die Antwort
  • Derzeit nehmen 77 Airlines an KCM teil
    • Große Airlines haben wahrscheinlich eigene Systeme gebaut, doch wie kleinere Airlines auf KCM- oder CASS-Anfragen antworten, wurde zum Untersuchungsgegenstand

In FlyCASS gefundene SQL-Injection

  • Die Forscher suchten nach Anbietern, die tatsächlich Authentifizierungssysteme betreiben, und stießen auf eine Website namens FlyCASS
    • FlyCASS bietet kleinen Airlines ein webbasiertes Interface für CASS
    • Jede Airline hatte eine eigene Login-Seite; Air Transport International(8C) war unter /ati erreichbar
  • Als auf der Login-Seite ein Apostroph in den Benutzernamen eingegeben wurde, kam sofort ein MySQL-Fehler zurück
    • Der Benutzername schien direkt in die Login-SQL-Abfrage eingefügt zu werden
    • Mit sqlmap wurde das SQL-Injection-Problem bestätigt
  • Mit der Kombination aus Benutzername ' or '1'='1 und Passwort ') OR MD5('1')=MD5('1 war es möglich, sich in das Admin-Konto von Air Transport International einzuloggen

Hinzufügen von für KCM/CASS zugelassenen Nutzern mit Admin-Rechten

  • FlyCASS betrieb für teilnehmende Airlines sowohl KCM als auch CASS
  • Nachdem Admin-Rechte für Air Transport International erlangt worden waren, konnten die mit dieser Airline verknüpften Listen von Piloten und Flugbegleitern verwaltet werden
  • Beim Hinzufügen eines neuen Mitarbeiters zur Airline gab es keine zusätzliche Prüfung oder Authentifizierung
    • Airline-Administratoren konnten beliebige Personen als für KCM und CASS zugelassene Nutzer hinzufügen
  • Zu Testzwecken wurde ein Mitarbeiter namens Test TestOnly erstellt, ein ausgewähltes Testfoto hinterlegt und ihm Zugriff auf KCM und CASS gewährt
    • Bei anschließender Prüfung über die Query-Funktion wurde der Testnutzer sowohl in KCM als auch in CASS als genehmigt angezeigt
  • Mit grundlegenden Kenntnissen über SQL-Injection war es möglich, sich auf der Website einzuloggen und beliebige Nutzer zu KCM und CASS hinzuzufügen
    • Dadurch hätte man letztlich die Sicherheitskontrolle überspringen und sogar Zugang zum Cockpit eines kommerziellen Passagierflugzeugs erhalten können
  • Unmittelbar nach Entdeckung des ersten Problems wurde der Offenlegungsprozess begonnen; darüber hinaus wurden mehrere weitere schwerwiegende Probleme gefunden

Offenlegungsprozess und Reaktion der TSA

  • Schon die Suche nach einem geeigneten Offenlegungskontakt war nicht einfach
    • Da FlyCASS offenbar von einer einzelnen Person betrieben wurde, wollte man FlyCASS nicht von Anfang an direkt kontaktieren und erschrecken
  • Am 23. April 2024 wurde das Problem dem Department of Homeland Security gemeldet; das DHS bestätigte, davon Kenntnis zu haben und es „sehr ernst“ zu nehmen
  • Anschließend wurde FlyCASS in KCM/CASS deaktiviert, und später scheint das Problem behoben worden zu sein
  • Nachdem das Problem behoben war, versuchte man, eine sichere Veröffentlichung abzustimmen, doch das DHS stellte die Kommunikation ein
  • Die Pressestelle der TSA veröffentlichte eine Erklärung, in der sie die Auswirkungen der Schwachstelle bestritt
    • Die TSA sagte, vor Ausgabe eines Barcodes an neue KCM-Mitglieder beginne ein Prüfverfahren, daher könne diese Schwachstelle keinen Zugang zu KCM-Checkpoints ermöglichen
    • Für die Nutzung eines KCM-Checkpoints ist ein KCM-Barcode jedoch nicht zwingend erforderlich; ein TSO kann die Mitarbeiter-ID der Airline manuell eingeben
    • Nachdem die Forscher die TSA darauf hingewiesen hatten, entfernte die TSA den Abschnitt der Website, der die manuelle Eingabe der Mitarbeiter-ID erwähnte, reagierte aber nicht auf Korrekturanfragen
    • Es wurde bestätigt, dass das von TSOs verwendete Interface weiterhin die manuelle Eingabe der Mitarbeiter-ID erlaubt

Mögliche weitere Angriffe und Offenlegungs-Timeline

  • Da die Schwachstelle die Änderung bestehender KCM-Mitglieder erlaubte, war auch das Ändern von Foto und Namen bereits registrierter Nutzer möglich
    • Auf diese Weise hätte sich ein eventuell vorhandenes Prüfverfahren für neue Mitglieder möglicherweise umgehen lassen
  • Wenn man einen nicht registrierten KCM-Barcode erlangen konnte, ließ sich dieser auf der KCM-Website auch direkt einer Mitarbeiter-ID zuordnen
  • Offenlegungs-Timeline:
    • 2024-04-23: Erstmeldung an ARINC und FAA
    • 2024-04-24: zusätzliche Meldung an DHS über CISA
    • 2024-04-25: DHS CISO bestätigt, dass an der Behebung gearbeitet wird
    • 2024-05-07: DHS CISO bestätigt, dass FlyCASS von KCM/CASS getrennt wurde
    • 2024-05-17: Nachfasskontakt beim DHS CISO zur TSA-Erklärung, aber keine Antwort
    • 2024-06-04: erneuter Nachfasskontakt beim DHS CISO zur TSA-Erklärung, aber keine Antwort

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-08-30
Meinungen auf Hacker News

  • Die Reaktion der TSA ist hier kindisch und peinlich, aber angesichts dessen, dass diese Organisation offenbar wenig Interesse an echter Sicherheit hat, auch nicht überraschend.
    DHS scheint die Meldung anfangs schnell und professionell behandelt zu haben; interessant ist aber, dass es danach nicht gelungen ist, die Kontrolle über Korrektur und Offenlegungsprozess bis zum Ende auf höherer Ebene zu behalten.

    • Für Führungskräfte, ja selbst für IT-Manager, ist es sehr schwer, vollständig zu verstehen, was solche Dinge bedeuten.
      Ich habe gesehen, dass große Probleme wie offengelegte Keys als Kleinigkeiten behandelt wurden, während Dinge wie veraltete JavaScript-Bibliotheken oder fehlende IPv6-Unterstützung eskaliert wurden.
      Es ist offensichtlich, dass TSA und ihre Partner die potenzielle Exponierung herunterspielen wollen, aber sehr viele Manager verstehen die Bedeutung von Schwachstellen nur schwer, und wahrscheinlich spielen auch Entwickler ihre eigene Verantwortung herunter und schieben die Schuld auf andere.
    • TSA ist Sicherheitstheater und existiert eher, um die Illusion von Sicherheit zu vermitteln, als tatsächlich Sicherheit zu bieten.
      In Wirklichkeit scheint das Ziel eher zu sein, ein Überwachungssystem zu festigen und nach außen Stärke zu demonstrieren.
    • Ein DHS-Mittelmanager hat wohl einen TSA-Mittelmanager angeschrien, das ging dann nach oben in die TSA-Führung, und danach griff offenbar die übliche Politik aus Leugnen, Ausweichen und Ignorieren.
    • Eher überraschend ist, dass sie nicht im Morgengrauen das Haus des Pentesters gestürmt und ihn mit Verweis auf Antiterrorgesetze ohne Anwalt festgehalten haben.

  • Sie haben nicht nur die SQL-Injection bestätigt, sondern sogar gefälschte Mitarbeiterdatensätze angelegt; schockierend ist, dass Homeland Security nicht gekommen ist, um die Beteiligten zu verhaften.
    Ich hätte gedacht, Homeland Security sei genau die Stelle, die Responsible Disclosure am ehesten als böswilliges Hacken missversteht und so bezeichnet.
    Das beeindruckt mich mehr als die Inkompetenz bei der eigentlichen Schwachstelle.

    • Nicht ganz falsch, aber als Geschworener fände ich es schwer, wegen eines CFAA-Verstoßes zu verurteilen, wenn statt eines Fotos nur ein hellpinker Platzhalter verwendet und der Name auf „Test TestOnly“ gesetzt wurde.
      Hätten sie sich selbst zu Known Crewmember hinzugefügt und tatsächlich die Flughafenkontrolle umgangen, wären sie wohl im Gefängnis gelandet.
    • Wenn man eine Atmosphäre schafft, in der man selbst bei Responsible Disclosure eine Anklage fürchten muss, schreckt das die besten einheimischen Talente ab, die sich solche Systeme ansehen würden.
      Dann schauen stattdessen die besten Talente aus weniger freundlich gesinnten anderen Ländern hinein, und die werden die Schwachstellen wahrscheinlich nicht verantwortungsvoll melden.
    • DHS nutzt offiziell Bugcrowd.
      https://bugcrowd.com/engagements/dhs-vdp
      Da die Beziehung seit Jahren besteht, dürften sie damit einigermaßen vertraut sein. Die TSA selbst ist möglicherweise weniger vertraut damit, aber da DHS eine behördenweite Vulnerability Disclosure Policy (VDP) betreibt und über CISA auch anderen Behörden beim Betrieb von VDPs berät, glaube ich nicht, dass sie das DOJ um eine Anklage bitten würden.
      Allerdings bin ich vielleicht zu optimistisch.
    • In Ländern wie Deutschland, wo so etwas häufiger vorkommt, meldet man das Problem normalerweise Journalisten oder einer gemeinnützigen Organisation wie dem CCC, und diese geben den Hinweis dann an die Behörde oder das Unternehmen weiter.
      So lässt sich das Risiko verringern, wegen Responsible Disclosure angeklagt zu werden.
      Noch sicherer ist es, den Bericht anonym zu senden und eine klare Frist für Veröffentlichung oder Full Disclosure zu setzen; natürlich ist es dann schwieriger, als Entdecker anerkannt zu werden.
    • Die Verjährungsfristen sind lang, und HSI wartet mit Anklagen oft, bis die Ermittlungen fast abgeschlossen sind.

  • Es ist so gravierend, dass zum Zeitpunkt dieses Textes noch niemand darüber spricht, wie schlimm es ist, Passwörter mit MD5 zu speichern.
    In diesem Fall zeigt sich sogar, dass nicht einmal Salts verwendet wurden; bei MD5 wären Salts aber ohnehin nicht ausreichend.
    Wenn man allerdings schon allein per Request die SQL-Query selbst beliebig manipulieren kann, ist es ziemlich egal, wie gut die Passwörter gespeichert wurden.

    • Das war früher fast genau so eine Frage in Triplebyte-Interviews, und selbst ziemlich gute Engineers haben sie erstaunlich oft falsch beantwortet.
      Der Anteil derjenigen, die Salts und zusätzlich einen kryptografisch sicheren Hash verwendeten, lag vermutlich unter 20 %, und MD5 kam wirklich häufig vor.
      Wenn man bedenkt, dass vor diesem Interview bereits stark ausgesiebt wurde, ist die allgemeine Baseline noch schlechter.
    • Bei der SQL-Injection scheint der md5-Teil vom Pentester hinzugefügt worden zu sein, wahrscheinlich weil innerhalb des Injection-Parameters ein mit Klammern endender Aufruf nötig war.

  • Die Erklärung „Wir haben FlyCASS nicht zuerst kontaktiert, weil es so aussah, als würde es von einer einzelnen Person betrieben“ ist schwer zu glauben.
    Es wirkt eher so, als hätten sie gewusst, dass der Website-Entwickler es sofort beheben würde, und als hätten sie ihren Fund größer herausbringen wollen.

    • Genau solche Bugs sind Bugs, die groß publik gemacht werden müssen.
      Das ist nichts, was der Verantwortliche still beheben und damit erledigen sollte; jede Person in der Datenbank muss erneut verifiziert werden.
    • Unabhängig vom Motiv ist der Engineering-Prozess, der einen so gewöhnlichen Bug zugelassen hat, kaputt.
      Wenn der einzige Entwickler es sofort behoben hätte, wäre es schwer gewesen, das Problem nach oben zu eskalieren und systematisch beheben zu lassen.
      Ob so eine umfassende Überarbeitung tatsächlich passiert, ist unklar, aber ohne Eskalation ist sie noch unwahrscheinlicher.
    • Ich stimme zu, dass sie vor der Veröffentlichung den Umfang des Vorfalls vollständig verstehen wollten.
    • Es war überhaupt nicht angemessen, bei einer Website mit so einer Lücke nicht zuerst Kontakt aufzunehmen und direkt zu Homeland Security zu gehen.

  • Dass die Schwere des Problems bestritten wurde, überrascht nicht; ziemlich überraschend ist aber, dass sie nicht das FBI informiert oder versucht haben, jemanden festnehmen zu lassen.
    Vielleicht ist das ein kleiner Fortschritt.

    • Der Autor hat richtig entschieden, es nicht direkt der TSA zu melden, sondern über FAA und CISA, also über den DHS-Weg.
      Eine direkte Meldung an die TSA hätte durchaus in rechtlichen Drohungen und Einschüchterung enden können.
    • Solche Prozesse laufen sehr langsam.
      Ich würde 50 Dollar darauf wetten, dass Ian angeklagt wird.
    • Das ist eine Nachricht wert.
      Es ist fast überraschend, dass noch kein gelangweilter 17-Jähriger mit gefälschtem Ausweis ein TikTok-Video gepostet hat, in dem er sich heimlich in ein Flugzeug schmuggelt.
      SQL-Injection, wirklich.

  • Es ist witzig, dass eine altmodische SQL-Injection ein Sicherheitstheater im Wert von zig Milliarden Dollar pro Jahr aushebelt, aber auch nicht wirklich überraschend.

    • Erinnert sich noch jemand an Bruce Schneier und seine gefälschte Bordkarte? Früher waren die Kritzeleien der TSA die Schwachstelle des ganzen Systems.

  • Es ist ziemlich erstaunlich, dass Airlines derart sicherheitssensible Software bei einer Ein-Personen-Firma kaufen.
    Wenn man bei den meisten US-Unternehmen bis zu einem gewissen Punkt kommt, um SaaS zu verkaufen, verlangen sie mindestens einen SOC2-Auditbericht.
    SOC2 ist als Audit-Standard ziemlich leicht ohne größere Beanstandungen zu bestehen, aber wenn ein Unternehmen von nur einer Person betrieben wird, gibt es mehrere Kriterien, bei denen im Bericht die Alarmglocken angehen müssten.
    Bei Software, die mit TSA-Zugangssystemen integriert ist, hätte ich gedacht, dass die Anforderungen deutlich strenger sind als SOC2.

    • Die „Airlines“, die so etwas wie FlyCASS nutzen, sind selbst kleinere Betreiber und haben oft extrem niedrige Margen oder schreiben sogar Verluste, in der Hoffnung, dass irgendwann Geld auftaucht und das Geschäft tragfähig wird.
      Im Backend ist alles mit mehr Klebeband zusammengehalten als bei einem durchschnittlichen Kleinunternehmen.
      Wenn man ein paar alte Passagiermaschinen kauft und zu Frachtflugzeugen umbaut, kann man eine „Airline“ werden.
      Ist es wertvoll, dass neue Airlines entstehen? Sollte man sie schließen lassen, nur weil sie noch keine Systeme aufgebaut haben, deren Aufbau Jahre bis Jahrzehnte dauert? Sollte ein Unternehmen, das mit zwei Flugzeugen eine einzige Route zwischen Nirgendwo und Nirgendwo bedient, viel Geld für maßgeschneiderte Systeme für große Passagierfluggesellschaften bezahlen müssen?
      Anforderungen und Audits sind hier nicht die Antwort. Das grundlegende Designproblem besteht darin, dass die TSA die Bestätigung „Airline XXX sagt, dass du ein Mitarbeiter bist“ mit einer sehr weitreichenden Berechtigung verknüpft hat, nämlich „du darfst an jedem Flughafen im ganzen Land sämtliche Sicherheitskontrollen umgehen“, und dass es nicht einmal die grundlegende Prüfung gab: „Fliegt diese Airline an diesem Flughafen überhaupt?“

  • Dass so etwas so einfach sein kann, war schon erstaunlich, aber die Beschreibung der TSA-Reaktion weiter hinten ist wirklich schwer beunruhigend.

  • Die Leute, die das gemacht haben, werden wahrscheinlich Besuch von Homeland Security oder dem FBI bekommen.
    Ich weiß nicht, was sie sich davon erhofft haben.
    Ich glaube nicht, dass der Staat sich um Sicherheit schert, aber vergeltungsfreudig ist er schon.

    • Was könnten Homeland Security oder das FBI schon erreichen, nachdem sie zu dem Schluss gekommen sind, dass diese „Leute“ zwei bekannte, kompetente Sicherheitsforscher sind, die versucht haben, durch Responsible Disclosure den Flugverkehr sicherer zu machen?

  • Die hier mögliche Methode wäre also: ein Ticket bei einer großen Airline kaufen, verbotene Gegenstände ins Handgepäck packen und sich dann per SQL Injection in einem Drittanbieter-FlyCASS-System auf die Known-Crew-Member-Liste einer kleinen Airline setzen, um die TSA-Kontrolle zu umgehen.
    Ist das dann die Schwachstelle, mit den verbotenen Gegenständen an Bord eines großen Flugzeugs zu gelangen?

    • Im Großen und Ganzen ja.
      Heutzutage verlangen die meisten TSA-Kontrollschlangen nicht einmal mehr eine Bordkarte, also könnte man theoretisch mit einer Bombe hingehen und dieses ganze Sicherheitstheater umgehen.
    • Klingt so, als könnte man dann sogar im Cockpit Platz nehmen?