WebUSB非対応問題を回避するためのFirefoxハック手法
(github.com/ArcaneNibble)- この proof-of-concept は、WebUSB がなくても Web ページが特定の USB デバイスと通信できることを示しており、Raspberry Pi Pico を U2F セキュリティキー のように動作させることで、ブラウザーの既存のセキュリティキー対応を利用する
- Pico は実際のセキュリティ機能は実行せず、
U2F_AUTHENTICATEメッセージの key handle と ECDSA 署名領域に任意のデータを隠し、LED 制御とGP22ピン状態の読み取りを実装する - U2F key handle は、セキュリティドングルが所有する 不透明なデータブロブ として設計されており、低価格ドングルが限られたメモリで複数サイトの登録を処理できるようにする仕組みが、データ隠蔽に悪用される
- この手法は任意の USB デバイスにアクセスする脆弱性ではなく、意図的にルールを破るデバイスでのみ動作するが、悪意ある USB デバイスがキーボードやマウスのように振る舞える USB セキュリティモデル の問題は依然として存在する
- 論点は Firefox の WebUSB 対応可否を超えて、開発者とユーザーの双方が理解し制御できる 健全なコンピューティングプラットフォーム とエコシステムをどう作るかへと広がる
WebUSBなしでUSBデバイスにアクセスするデモ
- Web ページが、WebUSB を巡る政治的な論争やユーザー同意の要求なしに USB デバイスと通信できる方法を示す proof-of-concept
- 手早いデモは、Raspberry Pi Pico の RP2040 版に
u2f-hax.uf2を書き込み、index.htmlを localhost または別の secure context で開くことで実行できる - ページの
On!とOff!ボタンは Pico の LED をトグルする GP22ピンの状態はページ上で定期的に更新され、隣接する GND パッドとワイヤーや金属でショートさせてテストできる
動作原理: U2Fセキュリティキーになりすます
- Pico は U2F ドングル、つまり物理的な二要素認証セキュリティキーのようにエミュレートされる
- 実際のセキュリティ機能を実行する代わりに、
U2F_AUTHENTICATEメッセージ内に任意のデータを隠す- データは key handle と署名領域に入る
- key handle が
0xfeedfaceで始まると、Pico は直ちにユーザー存在確認済みとして扱い、データを返す
- ブラウザーから見ると、セキュリティキーと相互作用する既存機能を使っている形になる
U2F key handleが悪用できる理由
- U2F の key handle は、概念上はセキュリティドングルが所有する不透明なデータブロブである
- 一般的な流れは次のとおり
- 登録結果としてドングルが key handle を返す
- relying party がそれをそのまま保存する
- 認証時に同じ値を再びセキュリティドングルへ渡す
- この仕組みは、メモリが限られた低価格ドングルでも多くの Web サイト登録を処理できる設計と結び付いている
- ドングルは内部に固有の master 暗号鍵を保存する
- 新規登録時に公開鍵/秘密鍵ペアを生成し、公開鍵を返す
- 秘密鍵を master 鍵で暗号化した値を key handle として返す
- 認証時には受け取った key handle を master 鍵で復号し、秘密鍵を使う
- 内部アルゴリズムを特定しないために key handle は不透明に扱われ、この性質が任意データの隠蔽に使われる
返却データはECDSA署名のように包装される
- データを返送するため、任意データを ECDSA 署名 のように隠す
- ECDSA 署名は 2 つの数
(r, s)のタプルであり、各数は楕円曲線 base point の order であるnを基準に計算される - secp256r1 base point の order 範囲内にある数値が ASN.1 で包まれる
- 実際に正しく計算された ECDSA 署名かどうかを見分けられる場合もあるが、relying party でない構成要素にとって、基本的な妥当性検査以上を行う強い理由はない
- ブラウザーごとに挙動差がある
- Chrome は、署名の数値が
0からnの範囲内にあるかを確認しているようだ - Firefox はその範囲確認すらしない
- Chrome は、署名の数値が
- Chrome の基本検査を安定して通過するため、各数値の先頭バイトに
0x7fを使って無駄にする- こうすることで数値は常に正となり、
nより小さくなる - ブラウザーの JavaScript までのソフトウェアスタックは、この「十分に有効な」数値をそのまま渡す
- こうすることで数値は常に正となり、
セキュリティ脆弱性かどうかとUSBセキュリティモデル
- この手法は 任意の USB デバイス にアクセスする脆弱性ではない
- 意図的にルールを破るデバイスでのみ動作し、本質的には意図的に脆弱に作られたデバイスである
- ただし、ほとんどのプラットフォームにおける USB デバイス周辺のセキュリティモデルは、一般に疑わしい状態にある
- 悪意ある USB デバイスを接続すると、キーボードやマウスのようなデバイスを通じて、ユーザーにできる操作を実行できる
- 任意の未知のデバイスをコンピューターや携帯電話などに接続すべきではない
プラットフォームとエコシステムへの問題提起
- この proof-of-concept の目的は、個人的な「できるからやる」を超えて、コンピューティングプラットフォームの現状をあぶり出すことにある
- ガジェット製造者の立場では、エンドユーザーが新しいデバイスをできるだけ苦痛なく使えるようにしたい
- 現在のコンピューターとガジェットのエコシステムには、ユーザーが直感的に可能だと期待することと、実際に可能なことの間に不一致がある
- 「セキュリティキー」は、うまくパッケージされた単一目的製品のように見えることが期待されるが、実際には任意コードを実行でき、どんな形にも見せられ、任意の動作も可能である
- USB Rubber Ducky と O.MG Cable も、この問題に触れる例である
- USB の「Universal」な性質には長所と短所がある
- 人間にもコンピューターにも、USB デバイスがユーザーの利益に反するものか、ユーザーを助けるものか、あるいはより大きな力や創発的な振る舞いの結果なのかを、容易かつ確実に見分ける良い方法がない
- Web は、他人のコンピューターで実行されるソフトウェアを配布する最も簡単な方法である
- 開発者は対象プラットフォームごとの細部を学ぶ必要が減った一方で、各プラットフォームの慣習や期待も学ばなくなっている
- 議論は「なぜ Firefox は WebUSB を実装しないのか」や「Chrome にさらに押されるのか」を超えて、デスクトップ、ノートPC、タブレット、携帯電話、IoT、スマートホームを含むコンピューティング全体の 健全なプラットフォーム を意図的に育てる方向へ移るべきだ
1件のコメント
Hacker Newsのコメント
Firefoxは任意のUSBデバイスと通信する機能をサポートしていないが、ChromeにはそのためのWebUSBがある
ただしFirefoxも、USB経由でのU2Fセキュリティキーとの通信はサポートしている
このプロジェクトは、マイクロコントローラにU2Fセキュリティキーのふりをさせ、FirefoxでUSB経由でマイクロコントローラと通信しようとする試みである
JavaScript Credentials API（https://developer.mozilla.org/en-US/docs/Web/API/Credential_...）と少しのトリックで、データを送り応答を受け取る
それでも、Webページが同意プロンプトなしで使えるカスタムデバイスを作る用途には使える
QMK/Viaファームウェア入りのキーボードをWebUSBでカスタマイズするのは悪夢に近い
ブラウザがファームウェアと通信するには、実質的に
/dev/hidrawデバイスの1つを全世界から読み取り可能にする必要があり、あらゆるキーロギングの悪ふざけを招くようなものだ使い方が非常に気持ち悪く、オフラインのカスタマイズツールもすべてElectronベースなので、利点は大きくない
まだ合理的な回避策は、Webサイト上でテンプレートJSONから望みのキーボード配列を作り、結果のJSONをダウンロードしたうえで、sudo権限のフラッシュツールでキーボードにファームウェアを書き込む方法だ
それでも、もっと気持ち悪くない方法があればいいと思う
main()を変更できるキーボードでも似たことができそうだ
ただしファイルシステムが不正なJSONならエラーを出し、エミュレートされたファイルシステムにセキュリティ属性を持たせて管理者だけが書き込めるようにすればよい
sudoは不要で、新しい設定を仮想フラッシュドライブにダウンロードまたはコピーするときに権限プロンプトを承認するだけで済む
少なくともCaps LockはJavaScriptからも設定できるようなので、事実上1ビット幅の通信バスになる
通常のOSツールなら3ビットまで可能だ
権限モデルの核心は、ブラウザ製品群がハードウェアアクセスを仲介するという点だ
当然、ブラウザがそれを行うには、最初からハードウェアへのアクセス権を与える必要がある
ハードウェア抽象化レイヤーの管理者としてブラウザを信頼しないならそう考えるのもありだが、Viaが期待しているモデルはそれだ
ブラウザにカメラ、マイク、ストレージ読み取り権限を与えることより、なぜそれ以上に「気持ち悪い」のかは分からない
ロックダウンされた企業管理のChromebookでもhttps://usevia.appにアクセスしてQMKキーボードを問題なくいじれるし、当然このデバイスでは
/devノードには一切触れられないQMKはすべて手動フラッシュだ
それでも、コードで配列、レイヤー、ライティングをカスタマイズするのが思ったより簡単で驚いたし、コミュニティのサポートが大きい
Viaほど便利ではないが、それでもグラフィカルなキーマップエディタがあり、ファームウェアをコンパイルしてくれ、はるかに軽量だ
Keeb.ioのボードでは良い体験だった
このコメントの流れは、WebUSBを使っている人たちがどれほど良いかを語る側と、使っていない人たちがなぜ必要なのか理解できない側が混在していて興味深い
個人的にはとても良かった
自分が使うWebUSBユーティリティの大半はインストール型アプリとしても提供されているが、使う頻度があまりに低いので、アプリをインストールして更新してから実行する手順よりWeb版のほうがずっと簡単だ
インストールすべきアプリが1つ減るのも利点だ
あらゆる物ごとにアプリをインストールしなければならないことに疲れた人たちに人気があると思っていた
だから両刃の剣だ
利便性とセキュリティは相性が良くない
便利で簡単ではあるが、脆弱性が生まれるにもあまりに都合がよい
Webの肥大化は止めるべきだ
ブラウザがテック業界の誰もが望むあらゆるものを詰め込む万能シンクになってはいけない
ネイティブアプリケーションのインストールも、そこまで難しいことではない
厳密にはUSBではなくHIDだが、似たようなアイデアだ
少し話題から外れますが、この流れの大半は元記事そのものより WebUSB 全般についての話に見えます
もちろん、元記事のハック自体はかなり格好いいです
一方で WebUSB は本当に必要だと思いますが、同時に一般ユーザーに WebUSB が与えられるのは本当に望ましくありません
実際、同意ポップアップは機能しておらず、人々は自分でも気づかないうちに何でも承認してしまいます
「何も押していない」と言いますが、スパムのプッシュ通知を50件消し、十数個の「ニュース」サイトのプッシュ権限を削除する羽目になる、という具合です
正直なところ、Internet Explorer 式の権限モデルはある程度気に入っています
特定の機能を有効にするには、サイトを「信頼済み」としてマークしなければならない方式です
見つけにくく、少し時間がかかり、やや分かりにくく、システム風のモーダルポップアップにかなり恐ろしい大きな警告アイコンが出ます
WebUSB や WebBluetooth のような危険な API を使うには、サイトを「信頼済み」としてマークする手順を踏ませるなら、誤って有効にする人はずっと少なくなるでしょう
ユーザー体験はそれでもネイティブアプリのインストールより良く、サンドボックス化もおまけで得られるので、その折衷には価値があるように見えます
平均的な高齢ユーザーは、ウェブ通知が何なのかまったく分かっていません
時間が経つにつれて怪しいウェブサイトの通知をうっかり有効にし、スマホに飛んでくる「HELLO YOUR PHONE HAS VIRUS DOWNLOAD "CLEANER APP" TO FIX BEFORE PHONE DIE」のようなウェブスパム通知を本気で信じてしまいます
物を壊す超能力でも持っているような人たちがいます
何かを文字どおり不可能にしない限り、必ずうっかりやってしまう方法を見つけます
理解していない設定を変更するガイドに従い、理解していない機能を実行し、理解していないアクセス権を付与します
手順をどれだけ複雑にし、警告をどれだけ付け、こうした愚かさを防ごうとしても、そうなります
問題は、自分が何をしているか分かっていて意図的に使う人たちもいることです
そういう人たちは、愚か者には絶対に与えてはいけない強力な機能に感謝することがあります
しかしその力を露出させると、馬鹿げたことをしでかした人たちであふれるのを現実的には避けにくい、というのがつらいところです
多くのユーザーが自分が何をしているのかまったく理解していない、という点をきちんと理解していないのが大きな問題です
Google は、そういう人たちにとって安全なソフトウェアを設計する方法を理解していません
面倒な手続きは無意味に見えますが、しばしば明確な目的があります
ユーザーの意図が確固たるものかを確認することです
Apple は最近、いくつかの Web API をウェブサイトをインストールした場合にのみ動作するよう実装しましたが、人のための設計を理解した戦略に見えます
有用な PWA 機能にはアクセスできるようにしつつ、どのサイトにも勝手に使わせるわけではありません
一般の人が理解できる追加手順があります
インストールされた PWA はホーム画面にずっと表示されるため、権限付与を目に見える形で思い出させ、ユーザーがそのアクセスを望んだという明確なシグナルになります
多くの人がデバイスとやり取りする必要がありますが、今は閉じた App Store 経由で提供されるアプリが事実上唯一の選択肢である場合が多いです
公式サポートが打ち切られたデバイスに、より多くの人がアクセスする方法を配布するには、WebUSB が圧倒的に簡単な方法です
Chrome がサポートしていない別の世界なら、一般ユーザーは [python or other scripting language] をインストールして実行できなければならなかったでしょう
開発者が本当に熱心なら、デスクトップアプリを提供するか、App Store への提出という長く高価なプロセスを経なければならなかったかもしれません
WebUSB には安全な UI を作れると思いますし、平均的なユーザーが接続しているデバイスのうち何が侵害され得るのかもあまり思い浮かびません
WebUSB でキーボードやマウス（HID）、ストレージ、Wi-Fi、オーディオ、スマートカード、U2F デバイスを乗っ取ることはできないはずです
しかし、独自仕様のラベルプリンター、雑多なおもちゃや機器、マイクロコントローラーのプログラミングやフラッシュ書き込みには非常に有用です
使いやすく便利ではありますが、信頼できない第三者に非常に広いアクセス権を誤って与えてしまうのも簡単です
ページに権限を与えることは、言われているように、権限パネルでユーザーが明示的に開始するフローであるべきです
サンドボックス化されたデスクトップアプリケーションでも同じです
あるアプリが画面を継続的に録画したいなら、権限コントロールパネルで明示的にその権限を受けるべきです
人々にただ「yes」を押させるモーダルダイアログを表示できてはいけません
多くの場合、人々は自分が何を求められているのかを技術的に理解していないからです
USB Serial は本当に素晴らしい
1つの用途にしか使われない面倒な Electron アプリに、ようやく終止符を打ってくれる
今ではブラウザでデバイスを設定するツールがあり、とても良い
ESPHome とそれを基盤にする何百ものプロジェクト、Betaflight、ELRS、Flipper を見てもそう
WebKit は Apple が開発しているのでサポートが不足しているのは理解できるし、周辺機器へのアクセスを許可するなら慎重になるだろうという点も理解できる
しかし Firefox は違う
Firefox はハードウェアの「接続」サポートが深刻に不足しており、昔から開発者に優しくなかったため、結局使わなくなった
サポートしない理由として、ユーザーの同意だけではデバイスへのアクセスには不十分だと言っているが、それは筋が通らない
開発者フラグのようなものの裏に置くことだってできたはず
Blink は安全に作れることを証明した
理由もなく意地を張っていて、ブラウザを使い物にするユースケースが見えていないように思える
https://developer.mozilla.org/en-US/docs/Web/API/Serial
https://mozilla.github.io/standards-positions/
U2F 資格情報はフィッシング不可能であるべきもの
ブラウザの U2F API がトークン要求にドメイン名を入れるため
しかし WebUSB を使うと、サイトが任意のドメイン名に対するトークンを要求できてしまった
U2F と WebUSB はどちらもかなり似たユーザー同意ダイアログを表示していたため、一部のユーザーが混乱するのを避けるのは事実上不可能だった
信じがたいが、Google の解決策は WebUSB で多くのデバイスをブロックリストに入れることだった
今では U2F デバイスを作るところは、新製品を出すたびに Google にブロックリストへの追加を依頼しなければならない
ブラウザが信頼できないコードを実行させる安全なサンドボックスである点は皆気に入っているのに、なぜそのサンドボックスにこれほど多くの穴を開けたがるのか分からない
[1] https://www.yubico.com/support/security-advisories/ysa-2018-...
[2] https://github.com/WICG/webusb/blob/main/blocklist.txt
物理ハードウェアとやり取りするために Electron アプリを受け取らなくて済む数十人のエンドユーザーのために、フィンガープリンティングのリスクを負う価値はないと思う
機能を実装しておいて開発者向けトグルの裏に閉じ込めるのは正気の沙汰ではない
有用なことに使える何百時間もの開発時間を無駄にして、どうせ誰も見つけられない機能を公開するようなもの
開発者として、こうした Chrome 専用 API は Chrome だけに残っていても構わない
どうせ Firefox で実際に壊れるウェブサイトがあった時に備えて Chromium ブラウザを1つ待機させておく必要があるので、Web USB の作業をするときはそれを使えばいい
かっこいい技術デモではあるが、ブラウザがやるべきことではない
Firefox 拡張として WebUSB 機能を追加した人がいないという事実も、この機能を使う人たちにとってさえ開発時間をかけるほどの価値はないことを示しているように思える
プライバシーとセキュリティの問題が提起されてきた
Web Serial はウェブ標準ではなく、Mozilla や Apple がこれらの問題は解決されたと見るまでは標準にはなれない
Google が単独でウェブ標準にすることはできず、標準には合意が必要
Mozilla の議論はこちら: https://github.com/mozilla/standards-positions/issues/336
WebKit の議論はこちら: https://github.com/WebKit/standards-positions/issues/199
webusb のためにウェブ閲覧用として Firefox を捨てるというのは、なかなか想像しにくい
ダウンロードでき、外部サーバーに依存しないソフトウェアであるべき
ただしデバイスがそもそもその会社のサーバーに依存して動作するなら、ソフトウェアをダウンロードして信頼しなくて済むのは良いこと
ブラウザベースのコードから USB ポートを使えないのは、むしろ良いことかもしれない
これをサポートしているオーディオ機器メーカー、たとえば Novation のファームウェア更新やユーティリティツールを実行するために、もう Windows VM を開く必要がないから
WebUSB も、より多くの種類のデバイスで同じことを可能にすべきだが、当然ながら適切な権限メカニズムは必要
デバイスを頻繁にフラッシュする人にとって利点は明らか
しかし普通のユーザー、つまり残りの30億人くらいの人たちはまったく気にしない
その人たちのためにサンドボックスに穴を開けるのは、よく言っても不注意
解決策は、この用途専用の別ツール、あるいは別ブラウザかもしれない
Flash Browser のようなもの
この作業を助ける追加ツールまで含められる
事前設定された許可リストやブロックリスト、よく使われるフラッシングツールのブックマーク、参考資料を入れるといった形
WebUSB をそのままブラウザに無理やりくっつけるより、より良い体験を作れる
その「標準」をめぐる論争や批判は理解するが、Pixel スマートフォンに GrapheneOS をフラッシュするのに使ったときは、どのデバイスで試した OS インストールよりも快適で簡単で速かった
文字どおり、差して、クリックして、すぐ使えるレベルだった
「マスター」キーで秘密鍵を暗号化し、暗号化された秘密鍵をキーハンドルとして返すという部分に驚き
実際には動きはするのだろう
攻撃者に、手元にある秘密鍵を復号してみる無限の機会を与えるのは、いつか裏目に出る気がするが、自分に何が分かるのかという感じ
例えば別の方式として、キーハンドルから決定論的な鍵導出で秘密鍵を作ることもできる
攻撃者は、キーハンドルに保存された暗号化済みのサイト別キーと同様に、これも総当たりできる
重要なのは、ステートレス認証器は定義上、グローバルに、つまりシークレットとサイト全体にわたって決定論的だという点である
入出力ペアが与えられれば、内部シークレットを総当たりできる
解決策は、その内部状態を十分大きくして、計算上不可能にすることである
WebUSBに関する政治的論争が何なのか気になる
Googleが作ったBlink専用APIであり、MozillaとAppleはプライバシーとセキュリティ上の理由で拒否した
独立した実装が2つなければWeb標準にはなれず、GoogleはGoogleの外の誰にも実装するよう説得できなかった
それでも多くのWebサイトでは、FirefoxとSafariが「対応できていない」かのように扱われている
“This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.”
— https://wicg.github.io/webusb/
“WebKit declined to implement several APIs, including WebUSB, due to concerns over fingerprinting”
“We have previously stated privacy concerns, thus the concerns: privacy label. We agree with Mozilla's security concerns raised in their standards position issue, thus the concerns: security label.”
— https://github.com/WebKit/standards-positions/issues/68
“Because many USB devices are not designed to handle potentially-malicious interactions over the USB protocols and because those devices can have significant effects on the computer they're connected to, we believe that the security risks of exposing USB devices to the Web are too broad to risk exposing users to them or to explain properly to end users to obtain meaningful informed consent. It also poses risks that sites could use USB device identity or data stored on USB devices as tracking identifiers.”
— https://mozilla.github.io/standards-positions/#webusb
ブラウザはすでに通常のOSインターフェースを通じて、必要なUSBデバイスにアクセスできる
キーボードとマウスが明白な例だ
どのWebサイトが別途の直接アクセスを必要とするのか分からない
ユースケースといえば、スタンドアロンアプリケーションを使うのを面倒がるWebプログラマーにアクセス権を与えること、またはユーザーを追跡する追加の手段を提供することのように見える
どちらも信頼したくない
GoogleやMozillaにもそのようなアクセスを与えるほど信頼していないのに、Webサイトを作った見ず知らずの任意の人ならなおさらだ
すべてがWebからアクセス可能であるべきではない
どこで線を引くべきかは分からないが、自分にとってUSBアクセスはその線を越えている
たいていは、今すぐ機能を欲しがる人たちが勝つ戦いである
セキュリティ上の欠陥は、実際に野放しの環境で悪用されるまでは仮定上の問題に見えるからだ
そうなればなるほど、Chromeへの依存はますます深くなる
自分もそれは望んでいない