クレジットカード端末で root shell を取得
(stefan-gloor.ch)- Worldline Yomani XR クレジットカード端末のセキュリティ研究のため、リバースエンジニアリングを試みた
- 内部分解の過程で、物理的な侵入検知機能はよく実装されている一方、ソフトウェア的にはroot shell が外部シリアルポートに露出している問題が見つかった
- メモリダンプ、ファームウェア抽出および分析を通じて、Linux 3.6 カーネルベースのシステム構造と非常に古い構成要素群を確認した
- シリアルコンソールポートを通じて、装置を分解しなくても容易に root 権限を取得し、マルウェアを導入できることを実証した
- 決済や認証に関わる重要な処理全体は別個のセキュアプロセッサで行われており、実際に重要データが露出するリスクは大きくない
プロジェクト概要
- 本プロジェクトは、決済端末のセキュリティ研究を目的として、Worldline Yomani XR モデルをリバース解析する過程を中心とする
- スイス全土で広く使われているこのモデルは現在は生産終了しているが、多くの大手小売店や小規模店舗で今も使用されている
最初の観察とハードウェア分解
- UI の探索、ポートスキャンなど基本的な調査の後、ハードウェア分解を開始した
- 複数の PCB、よく設計された筐体、カスタム ASIC ベースのデュアルコア Arm プロセッサなど、かなり高いハードウェアセキュリティが観察された
- 主要 SoC は Samoa II というコードネームの専用 ASIC で、外部にフラッシュと RAM が搭載されている
侵入検知と改ざん防止
- 筐体を開けなくても、圧力検知式の基板接続（Zebra strip）の不良やネジの緩みだけで侵入イベントが検知される
- バッテリーにより、電源遮断時でも検知が維持される
- 主要 PCB のジグザグ配線（トレース）、カードリーダーを包むフレキシブル PCBなどは、損傷時に侵入が検知される
- 一時的に分解して再組み立てすると、侵入検知により装置は赤い "TAMPER DETECTED" 画面だけを表示し、外部入力に応答しなくなる
チップオフによるファームウェア抽出
- オンボードフラッシュを取り外して直接接続し、ファームウェアを抽出した
- データは暗号化されていなかったが、独特な ECC 構造と YAFFS2 ファイルシステムのメタデータ配置が確認された
- ファイルシステムリーダーを実装して、全ファイル一覧を取得した
- システムは2010年版 Buildroot ベースの 3.6 カーネルを使用しており、uClibc、busybox、および多数の古いライブラリが存在していた
偶然 root shell を発見するまで
- ファームウェア分析後、フラッシュを再接続し、シリアルコンソール回線を見つけてロジックアナライザで信号を取得した
- ブートログとともにログインプロンプトが露出した
- "root" と入力すると、パスワードなしで即座に root shell に入ることができた
- 実際にこのシリアルポートは、外部からカバーを開けるだけですぐアクセスできる
- 攻撃者は端末を分解しなくても迅速に接続し、マルウェア注入などを行える
どれほど深刻な問題か？
- ブートおよびシステム構成の分析結果から、Linux はネットワーク、アップデート、一部のビジネスロジックのみを担当している
- カード決済、PIN 入力、ディスプレイなど、すべてのセキュリティ関連機能は別個の mp1 プロセッサが管理している
- Linux（mp2）は常に起動し、その後署名・暗号化されたイメージがセキュアブートローダーによってセキュアコアへロードされる
- 内部的にはセキュアコアの保護は正常に機能しており、セキュリティの中核データは root shell の露出では流出しない
公開と報告のスケジュール
- 2024年11月14日: root shell を発見
- 2024年11月15日: 90日後の公開予定とともにメーカーへ通知
- 2024年11月18日: メーカーから報告確認の返信
- 2025年6月1日: プロジェクト公開
結論
- 外部シリアルポートを通じたroot shell の露出は、明らかに不要な攻撃面でありエンジニアリング上のミスである
- ただしセキュアプロセッサを分離した設計のおかげで、実質的な決済情報露出リスクは低い
- root ログイン許可が本番ファームウェアに誤って適用されたか、バージョンによって異なる可能性がある
- 調査過程では、root ログイン機能が完全に無効化されている個体も存在した
- 内部的には、この問題はすでに認識され修正されている可能性がある
このプロジェクトは多くの興味深い結果を残し、ファームウェアを深く掘り下げる価値を改めて示した
1件のコメント
Hacker News のコメント
若い開発者たちへひと言。「Hacker News」の“ハッカー”とはまさにこういう意味なのだ、という説明。この投稿は典型的なハッカーの旅路をわかりやすく段階的に分析した好例だとしておすすめされており、似た事例をもっと知りたければ Hack-a-day を見てみるとよいという案内もある。筆者は好奇心旺盛で、基礎知識も非常にしっかりした人物に見えるという評価。本質的には、チップのデータシート調査、破損させないデソルダリング、メモリならワイヤで再接続、即興対応と試行錯誤、といった要素で成り立っているとの見方。次は浅い穴を開ける際にピンホールカメラを使って損傷の痕跡を避ける方法も検討するとよいという助言もあり、もし筆者がタンパー検知まで突破して正常動作まで試していたら本当に面白かっただろう、という惜しむ声もあった
ハッカーという用語はコンピュータセキュリティに限定されるものではなく、はるかに広い意味と哲学的定義を持つという説明。Guy Steele らがまとめた Jargon File を引用し、たとえば「プログラミングシステムの細部を学び、その限界を押し広げることを楽しむ人」「プログラミングそのものを情熱的に楽しむ人」、そして「特定のプログラムに熟達した専門家」まで、さまざまな意味で使われると要約している。おそらく Hacker News の創設者 PG もこの広い定義を念頭に名前を付けたのだろうという推測もあり、ハッカー用語の歴史には The UNIX-HATERS Handbook も必ず言及すべきだという補足もある
最初の一文に全面的に共感する。今どき LLM ラッパーがもうひとつ出てきたら本当にうんざりしそうだ、という感想
このサイトが VC スタートアップインキュベータ発というだけで、ハッキングセキュリティを意味すると見るのは無理があるという見解。おそらく「move fast and break things」というスタートアップ流のハッキング、つまり素早くコードを書き散らして問題を突破するスタイルに近い意味だろうという解釈
長いあいだ読むだけだったが、最近ようやくアカウントを作ってコメントし始めた。こういう情報量と実行力が際立つ投稿こそ、Hacker News の「ハッカー」精神を示しているという賛辞
この記事が実際にハッキングについての内容だったので、初めておすすめボタンを押したという告白。普段はコメントにしか投票しないが、これは例外だったとのこと
2ドルの USB カードリーダーで偽のクレジット/デビットカード取引をシミュレートできる、という紹介。仕様やプロトコルは膨大だが公開されているので、文書を読むだけで実装は可能だという説明。ただし実際に取引を承認してもらうにはインターネット経由で銀行へデータを送る必要があり、そうすればすぐに当局（たとえば FBI）が動かざるを得ない、という警告。カードリーダー自体にはほとんど保護機構がなく（大半が Linux と弱いパスワードを使用）、セキュリティは店舗と銀行のあいだの契約や規定から生まれている、という説明
カードリーダーに「保護機構がない」という主張への反論。実際には署名済みバイナリしか実行できず、実行ファイルシステムは読み取り専用、データファイルシステムにも noexec フラグ、root ログインは無効化、機能削減版の busybox を採用、鍵は起動時にセキュア領域から読み込まれ、マスターキーの挿入も工場でしかできない。起動自体も非常に安全で、タンパー検知時にはチップ自体が空の状態に初期化される構造だという詳細説明。安価な未認証端末にはほぼセキュリティがない場合もあるが、EMV 開発経験者として、実際の端末はほぼ完全にロックされているという体験談
「店舗と銀行のあいだの規制が唯一のセキュリティだ」という部分は正確だと認めつつ、だからといって携帯型カードリーダーで非接触カードから金を盗めるという陰謀論は実行に移しにくい、という意見。実際に取引を作れたとしても、その後の手順や事前準備の問題で、安全に金を抜き取るのはほぼ不可能に近いという指摘。特に今は取引のプッシュ通知があるので、犯罪の試みは露見しやすいだろうという推測
むしろ心配なのは、カードリーダーが現場でハッキングされてキャッシュされた CC 情報を読まれたり、インターセプト型のマルウェアが仕込まれたりする状況であり、この分野の研究が重要な理由でもある、という意見
取引は銀行にインターネットで送らなければ承認されないという説明は事実ではない、という指摘。銀行はカード取引を処理するためのオープン API をインターネット上に持っていない、とのこと
カードリーダーのセキュリティが弱いという主張には同意できず、実際の店舗端末には銀行や決済ネットワークの鍵を安全に保管するセキュアハードウェアが組み込まれているという説明。もしその鍵が漏れれば正規取引の偽造が可能になる、と付け加えている
Stripe M2 リーダーを 36 台購入して使ったところ 7 台が故障したという体験談。2 台はバッテリーが充電できず、1 台は NFC スキャン不能、4 台は「タンパー済み」エラーを出して死亡した。表面的には不良率が深刻に見えるが、使用日数や年式などの文脈も考慮すべきだという話。ただ実際には 1〜3 年物のリーダーを合計 9 日しか使っていないのに 7 台も壊れた点がより深刻だと感じる、という不満。移動時にはそれぞれハードシェルケースとフォームインサートで厳重に管理しており、保管不良でもないという。それでも Stripe M2 リーダーが依然として最も使い物になる選択肢なので、仕方なく使っているという現実の説明。ちなみに会社が祭りの決済担当なので、短期間だけ大量に使うことになった背景も補足されている
物理的なタンパー防止が発動すると root shell が開くのではないか、という想像。つまりシステムが必要な暗号鍵をすべて持つセキュアモードのままなのか、それとも root shell が開いてデバッグ/故障解析用に切り替わる仕組みなのか、という推測。ただしその場合でも重要な秘密鍵は自動削除されていてほしい、という願い
「root shell が開いてもカード情報は危険にさらされない」という原文の引用とともに、セキュリティ設計者ならぜひ読むべき資料だというおすすめ
（タンパーされた）Linux が「compromised mode」コードと mp1 セキュリティシステムのどちらを読み込むか決める構造なのではないか、という意見。ブートローダー自体が安全でも、どの環境で実際に実行されるかによって意味が変わり得ると指摘。co-processor が Secure Enclave 的な役割を果たせても、Linux 側が別のブートローダーを載せられる構造ならセキュリティ上深刻な問題になり得る、という懸念
初心者なら最新の Android ベースのクレジットカード端末を先に試してみるといい、というおすすめ。タッチスクリーンで PIN を入力するので、より面白いという誘い
タッチコントローラは通常、セキュアプロセッサが制御する MUX に接続されており、セキュア情報の入力時にはタッチ入力がそのままセキュアプロセッサへ渡されて Android 系 OS は関与しない、という説明
タッチパッドに表示されていても、PIN データは TrustZone で動くファームウェアが管理しており暗号化状態にある。途中にいるアプリは PIN を見ることができない、という強調
こうした Android 端末をハックしても、セキュリティ設計が同じならカード自体が複雑な暗号化を行うので、実用的な情報は得られないだろうという見通し。こういう攻撃が効くのはクレジットカードリーダーだけが残っている場合であり、そういう端末は利用者にとってすでにスキマーの危険信号になっているはずだ、という意見
インドで使われている Android 端末は今でも Android Oreo（2021 年 1 月にサポート終了）で動いている、という点に短く触れ、それを興味深いとしている
端末内部を分析しようとして、いきなり開けてタンパーモードを発動させたのが不思議だ、という反応。たいていのリーダーにタンパー検知があることを知らなかったのではないか、という推測。タンパーモードでテストしても意味は薄れるかもしれず、実際にはタンパートリガー後に初期化用の shell が開く仕組みなのではないか、という疑問。最後に、そもそも最初から開けるのが当然の流れなのか、もう一度考えてみてはという助言
「徹底したタンパー防止にもかかわらず、回避の余地や興味深い痕跡がまだたくさん残っているのは驚きだ」という賛辞。セキュリティ部分は安全に無力化されるのが正しい設計だという評価
強化されたプロセッサ（mp1）は依然として侵入不能のままだという点を強調。実際には文字列を display_tool バイナリに渡して別のプロセッサとメッセージをやり取りする構造だと説明している。カードリーダーやキーパッドなどには Linux から直接アクセスできず、完全に分離された mp1 プロセッサがカード、PIN 入力、画面表示などの「セキュア」処理を担当し、mp2 Linux はネットワーク、アップデート、業務ロジックだけを処理するという説明
Linux 側が tamper イベント処理の検知役を担っている可能性はあるが、tamper 発生を完全に検知した後でしかセキュリティキーを削除できないなら、事前に root shell を取っておいて tamper を回避する流れもあり得て危険だ、というシナリオ提示
こうした端末がヨーロッパ中に広がっているという事実と、スイスは確かではないが、自分の知るヨーロッパの多くの地域ではクレジットカードを持っている人はあまり多くないように感じる、という経験談。代わりに POS 端末はあらゆる種類のカードを読めるので、「POS システム」と呼ぶほうが適切だという意見。それでも投稿は面白く読んだ、という感想