- スイスで使われている Worldline Yomani XR 決済端末を分解・ファームウェア解析した結果、背面ハッチからアクセス可能なシリアルコンソールで
root と入力するだけで root shell に入れた
- 端末には筐体開封、PCB 接触の解除、ジグザグトレースの切断、カードリーダー周辺の flex PCB 損傷を検知する タンパー保護 が備わっていたが、デバッグポートの露出が別の攻撃経路になっていた
- オンボード flash から抽出したファームウェアには暗号化されていないファイルシステムが含まれており、Linux 3.6 カーネル、Buildroot 2010.02、BusyBox、uClibc、カスタムブートローダー Booter v1.7 を基盤として動作していた
- カード・PIN・画面・キーパッドのようなセキュリティ機能は別プロセッサ
mp1 と暗号化・署名された mp1.img が担う構成のようで、Linux mp2 から直接アクセス可能な証拠はなかった
- 脆弱なファームウェアバージョンは特定されておらず、root login が無効化された機器もあったが、物理的に一時端末を占有できる環境では不必要に大きな攻撃面が残っている
Worldline Yomani XR の分析対象
- 分析対象はスイスで広く使われている Worldline Yomani XR 決済端末だった
- 起動後の UI 確認とポートスキャンでは目立った結果がなく、ハードウェア分解へ進んだ
- 内部は複数の PCB で構成されていた
- 外部コネクタ用の小型ボード
- メインボード
- カードスロットが実装された垂直ボード
- メイン SoC はファームウェア内で「Samoa II」というコードネームで現れる dual-core Arm ベースのカスタム ASIC とみられる
- Worldline の文書によれば、このチップは既製品のリブランドではなくカスタム ASIC に該当する
- SoC の横には小型の外部 flash と RAM がある
ハードウェアのタンパー保護構造
- 一般的な筐体開封検知スイッチは見つからず、代わりに board-to-board interconnect 自体が開封検知手段として使われていた
- ボード間には圧力に敏感な Zebra strip があり、ボードをネジでしっかり固定しないと接触が維持されない
- 一部のネジを緩めるだけでも接触が切れてタンパーイベントが発生する可能性がある
- 電源が切り離された状態でも検知が必要なため、coin cell battery が使われていた
- 脆弱な PCB 領域はジグザグ形状の タンパー検知トレース で覆われていた
- 物理的侵入で copper trace を 1 本切断しただけでもタンパー検知が発生しうる
- カードスロットは別の内部筐体内にあり、周囲を囲む flex PCB がタンパー保護の役割を果たしていた
- 再組立て後、端末は「TAMPER DETECTED」という大きな赤い画面だけを表示し、このモードでは外部入力に反応しないように見えた
flash 抽出とファイルシステム復旧
- ランタイム探索が阻まれたため、オンボード flash chip を取り外して wire を接続し、内容をダンプした
- ダンプ内容は予想に反して全体として暗号化されていなかった
- flash には一般的ではない ECC 配置が使われていた
- 標準的な 2048 byte payload + 64 byte ECC/spare 構成ではなかった
- 694 byte のデータ chunk が 3 個あり、各 chunk の後ろに 10 ECC byte が付く構造だった
- spare area の最後の 16 byte は YAFFS2 ファイルシステム metadata とみられた
- 一般的な YAFFS2 より metadata 領域が小さく、より小さい metadata 構造を扱えるようファイルシステムをパッチする必要があった
- 互換ファイルシステム reader を実装した後、ファイルシステム内容の抽出に成功した
古い Linux ベースのシステム
- 抽出したファイルシステムから、この端末が Linux を実行していることが確認された
- システムには古い構成要素が含まれていた
- Linux kernel 3.6
- Buildroot 2010.02
- 2023 年 2 月ビルド
- カスタムブートローダー
Booter v1.7
- init script、BusyBox、uClibc
libcrypt 0.9.26
- ダンプしたファームウェアバージョンがどの程度新しいのかは確認できなかったが、2023 年 2 月以降にリリースされたファームウェアである必要がある
パスワードなしの root shell
- flash chip を wire で再接続すると、端末はタンパーメッセージを表示しながらも再び起動した
- Linux boot log を見るため、debug connector 周辺を logic analyzer で調べたところ、未実装の debug connector のある pad で活動が見つかった
- シリアルコンソールには Linux boot log とともに login prompt が表示された
- boot log には「Reset reason: Tamper」と表示された
dropbear is not present、firmware update 確認、application monitoring daemon 起動といったログも表示された- 最後に
samoa login: prompt が表示された
- login として
root を入力すると、パスワードなしで shell prompt ~ # が表示された
- このアクセスには exploit chain も brute-force password cracking も不要だった
外部からアクセス可能なデバッグポート
- root shell へのアクセスは端末内部を開けた場合だけに限定されていなかった
- serial port は端末背面の小さな hatch を通じて外部からアクセス可能だった
- 端末を開けてタンパー保護を発動させなくても debug connector に接続できた
- 端末を一時的に占有できれば、シリアルポートへ接続してログインし、malware を設置して立ち去るシナリオが可能だと判断された
セキュリティプロセッサと Linux の役割分担
- 露出した root shell が直ちにカード・PIN データへのアクセスを意味するわけではない
- Linux システムは全体構造の一部であり、ディスプレイ・キーパッド・カードリーダーへ Linux から直接アクセスできる証拠は見つからなかった
- 画面出力も framebuffer driver が直接処理する方式ではなく、文字列を
display_tool binary に渡し、この binary が inter-processor message を送る方式のようだった
- カード、PIN 入力、画面表示のようなセキュリティ関連機能は別プロセッサ
mp1 が処理する構成とみられる
- 2 番目のプロセッサ
mp2 で動く Linux は networking、update、business logic を担当する
ブートフローとセキュアイメージ
- Linux core はタンパー状態に関係なく常に起動するように見える
- その後 Linux が secure bootloader である
loadercode をメモリにロードする
loadercode はタンパー保護が発動したかどうかを確認する
- タンパーが検知されると赤い画面を表示する
- 問題がなければ実際の secure image である
mp1.img を起動する
mp1.img は Linux ファイルシステム内にあるが、暗号化され、2 つの entity によって署名されているようだ- カード、ディスプレイ、キーパッドを処理する secure image は適切に暗号化・署名されていた
公開日程と残る不確実性
- 公開日程は次のように記録されている
- 2024 年 11 月 14 日: root shell を発見
- 2024 年 11 月 15 日: メーカーに報告し、90 日後に公開予定であると通知
- 2024 年 11 月 18 日: メーカーが報告受領を確認
- 2025 年 6 月 1 日: 公開
- 露出した root shell は不必要に大きな攻撃面だが、カード情報のような機密データがこの経路で侵害可能だという証拠は見つからなかった
- どのファームウェアバージョンが脆弱なのかは特定されていない
- 調査中には root login が無効化された機器も見つかった
- debug feature がどの時点で production firmware に入ったのか、メーカー内部で既に発見・修正されていたのかは確認できていない
1件のコメント
Hacker News のコメント
2ドルのUSBカードリーダーで偽のデビット／クレジットカード取引を作ること自体はできる
仕様はすべて公開されていて、プロトコルも文書化されている。記憶ではPDFが5000ページくらいあって、読むのはかなり苦痛
ただ、その取引を検証するにはインターネット経由で銀行に送る必要があり、そうすると連邦機関／FBIのようなところがやって来る可能性がある
カードリーダー自体には本当の保護はほとんどなく、多くは小さなLinuxにひどいパスワードを使っているようなもの。保護は店舗と銀行の間の契約と規制から来ている
noexecが設定されているrootログインは無効化されており、機能をかなり削ったbusyboxを使い、鍵は起動時にセキュア領域からロードされる。マスターキー注入は工場でのロード時にしかできず、起動自体もある程度安全で、改ざん検知が起きるとチップを消去する
もちろん、アジアから入ってきた低価格のEMV未認証Android端末なら、標準的なLinuxに読み書き可能なrootファイルシステム、rootログイン、アプリ実行ユーザーへのsudoまで有効になっている可能性が高い。改ざん検知もなく、画面キャストもロックされておらず、ポートも開けられ、busyboxもほぼ完全な形かもしれない
何年もカードアクワイアリング用のEMVアプリケーションを開発していて今も時々やっている立場から言うと、開発モードでさえベンダーが開発者IDを提供する必要があり、かなり厳重にロックされている
だから、携帯型カードリーダーを持ち歩いて非接触カードから金を盗むといった陰謀論も間違っている。そういう取引自体は作れるが、その後に起きることと、事前に必要な設定が問題になる
捕まってブロックされる前に資金を引き出せるかどうかも定かではない。最近は取引のプッシュ通知をオンにしている人が多いので、さらに難しいと思う
その鍵が漏えいすれば、誰かが正規の取引を装うことができる
この特定のケースでは難しいか不可能に見えるが、だからこそこの分野の研究には意味がある
何を見るべきか分かっているわけではないが、手元にあるStripe M2リーダーを1台開けて中を見たい誘惑に駆られたことがある
問題は、購入したリーダー36台のうち7台が「死んだ」こと。2台は充電を保持できず、1台はNFCをスキャンできず、4台は「tampered」と表示する。表面的にも損失率は悪いが、使用頻度と年数を見ないと全体像は分からない
ところが、その答えはさらに悪い。機器は1〜3年もので、総使用日は最大で9日しかない。合計9日の使用で36台中7台が何らかの形で故障したことになる。移動時もすべて、フォームインサート付きのハードシェルケースにリーダーごとのスロットを分けて保管している
なのでM2リーダーを大いに気に入っているわけではないが、それでも自分にとっては最善の選択肢
[0] 背景を補足すると、うちの会社はフェスティバルの決済を処理している。会場へ移動してiPadとM2リーダーで対面決済を処理し、決済の大半はWeb／アプリ上で行われる。だから3年間で「使用日」がこれほど少ない
それに、改ざん検知も正常に動作するバッテリーを必要とする可能性が高い
改ざんシールが発動するとrootシェルが開く仕組みなのかもしれない
つまり、システムが動作に必要な暗号鍵を持つセキュアモードにあるか、デバッグと障害解析のためにrootシェルが開く非セキュアモードにあるが、その移行過程で重要な秘密鍵が削除される、という形かもしれない
実際に端末を1台手に入れられるのか気になってきた。置き換えられて消えつつあるなら、中古を探すのはそれほど難しくないかもしれない
興奮しがちな人向けに付け加えると、「露出したrootシェルは、当初懸念されたほど大きなリスクには見えない。カード情報のような機密データがこの方法で侵害され得るという証拠は見つからなかった」という内容がある
それでもセキュリティ設計者には良い読み物
セキュリティにおいて物理アクセスは、程度はやや下がるがrootアクセスも、事実上ハッキング成功とほぼ同等だ
侵害されたLinuxが「侵害モード」コードとmp1セキュリティシステムのどちらをロードするかを決める構造なら、探る価値のある経路に見える
ブートローダー自体は安全だとされているが、実際の実行場所によっては侵害された環境の中へロードされるのだとしたら、大きな意味はないかもしれない
補助プロセッサを一種のSecure Enclaveと見ることもできるが、Linuxが別のブートローダーをロードして実行できるという点は懸念される
loadercodeという「セキュア」ブートローダーを改ざんしてみたが、起動しなかったそのため、第三者、おそらくブートROMがこれを検証しているのだと推測している
またLinuxは、改ざん状態に関係なく常に
loadercodeとmp1.imgをロードするようだ。改ざん状態に応じた別のコードパスは、完全性保護を受けているloadercodeの中で選択されるように見える簡単モードを望むなら、最近出ている Android ベースのカード端末を見ればよい
特に PIN を画面に直接入力するので、はるかにやりがいがある可能性が高い
PIN や PAN のような機密データを入力するときは、タッチコントローラの出力が GUI を担当する Android 系 OS を迂回し、セキュアプロセッサへ直接ルーティングされる
そのため、この種の攻撃でアクセス可能な中間アプリケーションは PIN を見ることができない
現代のカードはこのような攻撃を防ぐため、カード内部で多くの 暗号演算を行う
この攻撃が通用するのは、決済オプションのうち磁気カードリーダーだけが生きている端末くらいだろうが、そういう端末は PIN プロンプトを見る前からスキマー警告ランプが点くべきだ
素晴らしい。こうした広範な 改ざん防止のようなハードウェア制限を迂回して悪用する方法を考えるのは好きだが、いったん発動すればゲームオーバーだと思っていた
しかし必ずしもそうではなく、まだ覗いてみる価値のある興味深い部分がたくさん残っていた。ただし、セキュリティ部分がきちんと無効化されるのは当然だ。そうでなければ設計者への信頼をすべて失っていただろう
テキスト文字列だけが
display_toolというバイナリに渡され、そのバイナリがプロセッサ間メッセージを送っているように見える。キーパッドやカードリーダーも同様だ。こうした周辺機器に Linux から直接アクセスできるという証拠は見つけられなかった代わりに、
mp1と呼ばれる完全に別のプロセッサが、カード処理、PIN 入力、画面情報表示といった「セキュア」な作業を担当しているようだ。2 つ目のプロセッサmp2で動く「非セキュア」な Linux は、ネットワーク、アップデート、ビジネスロジックだけを処理するそれでも、改ざんが発生したという事実を見られるだけの構造であってほしい。そうでなければ、先に root シェルを取ったうえで、改ざんイベントによる セキュリティキー削除を阻止する機会が生まれかねない
デバイスのあらゆる 改ざん検知について読んでいて、改ざんモードを最も簡単に発動させる方法は何だろうと気になった
結局、こうしたデバイスを数台でもそうできれば、決済の大半またはすべてがこの端末を通じて行われる店舗には、効率的なサービス拒否攻撃になり得る
こういう装置を覗いてみるのは興味深いが、なぜすぐに開けて 改ざん状態を発動させたのか分からない。ほとんどのリーダーにそういう仕組みがあることを知らなかったのだろうか？
改ざん状態で行う実際のテストは意味がないかもしれない。初期化目的で改ざん状態になるとシェルが開く構造である可能性もある
見たところ、デバイスを開けるのは最後に試すことのように思える
そうでなければあまりにも手探りだ。もちろん振り返れば、単にデバッグコネクタにタップを当てて終わりにできたかもしれない
そして、改ざんされていない 2 台目のデバイスでもシェルを取得した
こういうデバイスはヨーロッパの至るところにある。スイスはよく分からないが、私の知るヨーロッパのかなりの地域では、クレジットカードを実際に所有したり多用したりはしない
私ならこれを POS、つまり販売時点情報管理システムと呼ぶ。こうした装置はあらゆる種類のカードを読み取れる。いずれにせよ良い記事だ
携帯電話やスマートウォッチにさらに多くのものを入れる魅力も分からない。機械式時計のほうが好きだし、携帯電話をなくしたらプライバシー面ではすでに十分な大惨事だ。もちろんこれは私の場合だ