- TSAのKCM/CASS認証フローでは、航空会社側システムが侵害されると、雇用状態の検証を通過したかのように任意のユーザーを追加でき、保安検査の迂回やコックピットアクセスにまでつながる可能性があった
- FlyCASSは小規模航空会社向けにCASSのWebインターフェースを提供しており、Air Transport InternationalのログインページにあるSQLインジェクションによって管理者ログインが可能だった
- 管理画面では新規従業員追加時に追加検証なしでKCMとCASSの権限を付与でき、テストユーザーが両システムで承認状態として確認された
- 2024年4月末にARINC、FAA、DHS/CISAへ開示された後、DHSはFlyCASSがKCM/CASSから切り離されたことを確認したが、TSAの説明に対する訂正要請には応じなかった
- TSAはKCMバーコード発行前の審査のためチェックポイントへはアクセスできないと説明したが、実際の手順には従業員IDの手動入力経路が残っており、脆弱性の影響はより大きかった
KCMとCASSが担う検証
- Known Crewmember(KCM) はTSAのプログラムで、パイロットや客室乗務員が国内の個人旅行中でも保安検査を迂回できるようにする
- 従業員は専用レーンでKCMバーコードを提示するか、TSA職員に従業員番号と航空会社を伝える
- TSA職員のノートPCが航空会社に雇用状態を確認し、成功するとその従業員は追加検査なしで保安区域に入れる
- Cockpit Access Security System(CASS) は、コックピットへのアクセス資格を確認する別のシステムである
- ほとんどの航空機にはコックピット内、操縦士の後方にジャンプシート(jumpseat)がある
- パイロットが通勤や移動を行う際、有償座席を使いにくい場合はジャンプシートを利用できる
- ゲート係員はCASSでジャンプシート利用者が承認済みパイロットかを確認し、乗務員にCASS認証済みであることを伝えられる
- 両手続きの要点は現在の航空会社での雇用状態の確認である
- 航空会社の従業員でなければ身元調査を受けた状態ではないため、保安検査の迂回やコックピットアクセスは許可されてはならない
- 承認対象者本人かを確認するため、乗務員の写真も返される
ARINCと航空会社ごとの認証システム
- ARINCはCollins Aerospaceの子会社で、TSAからKCMの運営を委託されているとみられる
- ARINCは、パイロットや客室乗務員がKCM状態を確認するオンラインWebサイトと、航空会社間の承認リクエストをルーティングするAPIのような中央コンポーネントを運用している
- 各航空会社はKCMとCASSに参加するため独自の認証システムを運用しているとみられ、このシステムがARINCのハブと連携する
- TSAと航空会社は
CockpitAccessRequest、CrewVerificationRequestのようなリクエストをARINCへ送信できる
- ARINCはリクエストを該当航空会社のシステムへルーティングし、応答を受け取る
- 現在、KCMには77社の航空会社が参加している
- 大手航空会社は独自システムを構築している可能性があるが、小規模航空会社がKCMやCASSのリクエストにどう応答しているかが調査対象となった
FlyCASSで発見されたSQLインジェクション
- 研究者らは認証システムを実際に運用しているベンダーを探す中で、FlyCASSというサイトを発見した
- FlyCASSは小規模航空会社向けにCASS用のWebベースインターフェースを提供していた
- 各航空会社は個別のログインページを持ち、Air Transport International(8C)は
/atiからアクセスできた
- ログインページでユーザー名にシングルクォートを入れると、即座にMySQLエラーが返された
- ユーザー名がログインSQLクエリに直接挿入されているとみられた
- sqlmapによりSQLインジェクションの問題が確認された
- ユーザー名
' or '1'='1 とパスワード ') OR MD5('1')=MD5('1 の組み合わせで、Air Transport Internationalの管理者アカウントにログインできた
管理者権限でKCM/CASS承認ユーザーを追加
- FlyCASSは参加航空会社向けにKCMとCASSの両方を運用していた
- Air Transport Internationalの管理者権限を取得すると、その航空会社に紐づくパイロットや客室乗務員の一覧を管理できた
- 新しい従業員を航空会社に追加する際、追加の確認や認証はなかった
- 航空会社管理者は誰でもKCMおよびCASS承認ユーザーとして追加できた
- テスト用に
Test TestOnlyという従業員を作成し、任意のテスト写真を登録したうえでKCMとCASSのアクセス権を付与した
- その後Query機能で確認したところ、テストユーザーはKCMとCASSの両方で承認状態だった
- 基本的なSQLインジェクションの知識だけでサイトにログインし、任意ユーザーをKCMとCASSに追加できる状態だった
- 結果として、保安検査をスキップし、商用旅客機のコックピットにアクセスできる可能性があった
- 最初の問題を発見した直後に開示手続きが始まり、そのほかにも深刻な問題が複数見つかった
開示手続きとTSAの反応
- 適切な開示先の連絡先を見つけること自体が簡単ではなかった
- FlyCASSは1人で運営されているように見えたため、最初から直接連絡して驚かせたくはなかった
- 2024年4月23日にDepartment of Homeland Securityへ問題が開示され、DHSはこれを認識し、「非常に深刻に受け止めている」と確認した
- その後FlyCASSはKCM/CASSから無効化され、後に問題は修正されたとみられる
- 問題修正後、安全な公開を調整しようとしたが、DHSは応答を止めた
- TSA広報室は脆弱性の影響を否定する説明を出した
- TSAは、新しいKCM会員にバーコードを発行する前に審査手続きが始まるため、この脆弱性ではKCMチェックポイントにアクセスできないと述べた
- しかし、KCMチェックポイントの利用にKCMバーコードは必須ではなく、TSOが航空会社の従業員IDを手動入力できる
- 研究者らがこれをTSAに伝えた後、TSAは従業員IDの手動入力に言及していたWebサイトの該当セクションを削除し、訂正要請には応じなかった
- TSOが使うインターフェースは、依然として従業員IDの手動入力を許可していることが確認された
可能だった追加攻撃と公開タイムライン
- この脆弱性では既存のKCM会員を修正できたため、既存登録ユーザーの写真や名前の変更も可能だった
- この方法なら、新規会員向けの審査手続きがあっても回避できた可能性がある
- 未登録のKCMバーコードを入手できれば、KCM Webサイト上でそれを従業員IDに直接登録することも可能だった
- 公開タイムライン:
- 2024-04-23: ARINCとFAAへ初回開示
- 2024-04-24: CISAを通じてDHSへ追加開示
- 2024-04-25: DHS CISOが対応作業中であることを確認
- 2024-05-07: DHS CISOがFlyCASSがKCM/CASSから切り離されたことを確認
- 2024-05-17: TSAの説明についてDHS CISOにフォローアップしたが応答なし
- 2024-06-04: TSAの説明についてDHS CISOに再度フォローアップしたが応答なし
1件のコメント
Hacker Newsのコメント
ここでのTSAの対応は幼稚で見苦しいレベルだが、実際のセキュリティには大して関心のない組織だと考えれば驚くことでもない
DHSは当初、通報を迅速かつプロフェッショナルに扱ったように見えるが、その後、修正と公開手続きに対する上位の権限を最後まで維持できなかった点が興味深い
露出したキーのような重大な問題が些細なものとして扱われる一方で、古いJavaScriptライブラリやIPv6未対応のような事案がエスカレーションされるのを見たことがある
TSAと協力会社が潜在的な露出を矮小化しようとしているのは明らかだが、多くの管理者は脆弱性の意味を理解するのが難しく、開発者も自分の責任を小さく見せ、他人のせいにしている可能性が高い
実際には監視体制を固め、強そうに見える外形を作ることが目的のように見える
彼らはSQLインジェクションを確認するだけでなく、偽の従業員レコードまで作成していたのに、Homeland Securityが関係者を逮捕しに来なかったのは衝撃的だ
Homeland Securityなら、責任ある公開を悪意あるハッキングと誤解し、そう呼ぶ可能性が最も高いところだと思っていた
実際の脆弱性のひどさより、この点のほうが印象的だ
もし自分たちをKnown Crewmemberに追加し、実際に空港の保安検査を迂回していたなら、そのときは刑務所行きだっただろう
そうなると、あまり友好的でない他国の最高の人材が代わりに調べることになり、彼らが責任を持って公開する可能性は低い
https://bugcrowd.com/engagements/dhs-vdp
何年も関係があるので、ある程度は慣れているはずだと思う。TSA自体はあまり慣れていないかもしれないが、DHSが省全体の脆弱性公開ポリシー（VDP）を運用し、CISAを通じて他省庁にもVDP運用を助言している状況で、DOJに起訴を依頼するとは思えない
ただし、自分が楽観的すぎるのかもしれない
そうすれば、責任ある公開を理由に起訴されるリスクを減らせる
さらに安全な方法は、報告書を匿名で送り、公開または全面公開の明確な期限を設けることだが、もちろんこの場合、発見者として認められるのは難しい
あまりに深刻なので、この記事を書いている時点でも、誰もMD5でパスワードを保存していた問題がどれほど悪いかを話していないほどだ
この場合、ソルトすら使っていなかったことも明らかになっているが、MD5ではソルトを使っても不十分だ
しかしリクエストだけでSQLクエリ自体を好き放題いじれるなら、パスワードをどれだけ適切に保存していたかは大した意味を持たない
ソルトを使い、暗号学的に安全なハッシュまで使っていた割合はおそらく20%未満で、MD5は本当によく出てきた
この面接の前にも相当ふるいにかけていたことを考えると、全体の基準線はそれよりさらに悪い
「FlyCASSが1人で運営されているように見えたので先に連絡しなかった」という説明は信じがたい
サイト開発者がすぐに修正してしまうことを分かっていて、自分たちの発見をもっと大きく取り上げたかったように感じる
担当者がこっそり直して終わりにする話ではなく、データベース内の全員を再検証する必要がある
唯一の開発者が即座に直していたら、上層部まで問題を上げて体系的に直させるのは難しかっただろう
そのような全面的な見直しが実際に起こるかは分からないが、エスカレーションしなければ起こる可能性はさらに低くなる
問題の深刻さを否定したことは驚きではないが、FBIに知らせたり逮捕しようとしたりしなかったのはかなり驚きだ
小さいながら進歩かもしれない
TSAに直接報告していたら、法的脅しと虚勢につながっていた可能性も十分ある
Ianが起訴されることに50ドル賭けてもいい
偽の身分証を持った退屈した17歳が、飛行機にこっそり乗り込む動画をTikTokにまだ上げていないのが不思議なくらいだ
SQLインジェクションだなんて
旧式のSQLインジェクションひとつが、年間数十億ドル規模のセキュリティ劇場全体を無力化するというのは笑えるが、それほど驚きでもない
航空会社がこれほどセキュリティに敏感なソフトウェアを、1人だけの会社から買っているというのはかなり驚きです
米国企業の大半に SaaS を売ろうとしてある程度の段階まで行くと、少なくとも SOC2 監査報告書は求められます
SOC2 は監査基準としては、大きな指摘なしに通過するのが比較的容易な部類ですが、会社が1人で運営されているなら、報告書上で赤信号がともるはずの基準がいくつもあります
TSA のアクセスシステムと連携するソフトウェアなら、要件は SOC2 よりはるかに厳しいものだと思っていました
バックエンドのあらゆるものが、平均的な小企業以上にダクトテープでかろうじて貼り合わされています
古い旅客機を数機買って貨物機に改造すれば、「航空会社」になれます
新しい航空会社が生まれることには価値があるのでしょうか？ 数年から数十年かかるシステムをまだ備えていないという理由で、彼らを廃業させるべきなのでしょうか？ どこでもない場所とどこでもない場所の間の1路線を2機の航空機で運航する会社が、大手旅客航空会社向けのカスタムシステムに大金を払うべきなのでしょうか？
ここで要件や監査は答えではありません。根本的な設計上の問題は、TSA が「航空会社 XXX があなたを従業員だと言っている」という認証を、「全国どの空港でもすべての保安検査を迂回できる」という非常に広い権限と結びつけてしまった点にあり、「その航空会社はこの空港で運航しているのか？」という基本的な確認すらなかったことにあります
こんなことがこれほど簡単にできるというのも驚きでしたが、後半の TSA の対応の説明は本当に深刻に不安になります
これをやった人たちは、おそらく Homeland Security や FBI の訪問を受けることになりそうです
何が得られると思っていたのか分かりません
政府がセキュリティを気にしているとは思いませんが、報復的ではあります
ここで可能な手口は、大手航空会社の航空券を買い、持ち込み禁止品を機内持ち込み手荷物に入れたうえで、第三者の FlyCASS システムへの SQL インジェクションによって自分を小規模航空会社の Known Crew Member リストに追加し、TSA の検査を迂回する、というものです
その後、禁止品を持って大型機に搭乗できる脆弱性なのでしょうか？
最近の TSA の検査列の多くは搭乗券すら要求しないので、理論上は爆弾を持って行って、このセキュリティ劇場をすべて迂回することもできるでしょう