phpMyAdmin 5.2.3 の WebAuthn 2FA バイパス｜署名未検証の CustomServer

データベース管理の定番ツール phpMyAdmin の 5.2.3 に、WebAuthn の 2FA が署名を検証せずに通ってしまう問題が、Abraxas Labs の研究で指摘されました。当サイトは、この主張を phpMyAdmin 本体の 5.2.3 ソースで独立に確認しました。核心は、WebAuthn の検証を担う外部ライブラリが既定では入らず、署名を暗号検証しない自前の実装（CustomServer）に静かにフォールバックすることです。結果として、MySQL のパスワードを通ったあと、構造だけ整った出鱈目な署名でも第二要素を抜けられます。この記事は、仕組みと「自分が対象か」の見分け方、そして対策を、本体ソースと公式の構成で裏を取って整理します（攻撃手順＝PoC は載せません）。認証ライブラリの不備が乗っ取りに直結する例はBetter Auth の SCIM 実装で起きたアカウント乗っ取り、認可の確認が抜ける類型はIDOR とは｜認可チェックの抜けを塞ぐ設計、依存の扱いが守りを崩す全体像はサプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説にまとめています。

まず自分の構成がどちらのサーバを使っているかを確かめます。

composer show web-auth/webauthn-lib 2>/dev/null || echo "未インストール → CustomServer（対象）"

ライブラリが入っていなければ、署名を検証しない CustomServer が動いています。これは侵害の判定ではなく、どちらの実装かの確認です。

何が起きるのか

phpMyAdmin は、WebAuthn（FIDO2）の検証を外部ライブラリ web-auth/webauthn-lib に任せる設計です。ところが、このライブラリは composer.json の require-dev と suggest に置かれていて、本番向けの require には入っていません。つまり、公式の配布 tarball をそのまま使う場合や、composer install --no-dev で入れた場合、このライブラリは同梱されません。

ライブラリが無いとき、phpMyAdmin の createServer() は、Webauthn\Server クラスの有無を class_exists で見て、無ければ自前の CustomServer を使います（本体の WebAuthn.php で確認）。問題はこの CustomServer にあります。認証時に呼ばれる parseAndValidateAssertionResponse は、credential id が許可リストにあるか、clientData.type が webauthn.get か、challenge が一致するか、origin のホストが一致するか、rpIdHash が一致するか、user-present フラグが立っているか——といった構造の確認は行います。しかし、response.signature を保存済みの credentialPublicKey で暗号検証する処理が、どこにもありません（本体の CustomServer.php で確認）。公開鍵は登録時に保存されるだけで、認証時には使われていません。

なぜ 2FA が素通りするのか

WebAuthn の検証は、本来「構造の確認」と「署名の暗号検証」の二本立てです。構造の確認は、リプレイや別サイトでの使い回しを防ぐための前提で、challenge や origin の一致を見ます。そして署名の暗号検証が、「登録したその鍵が、今まさに応答した」という本人性を担保します。CustomServer は前者だけを実装し、後者を欠いていました。

その結果、攻撃者が MySQL のパスワード（第一要素）を通したあと、構造の条件（正しい challenge・origin・rpIdHash・user-present・enrolled な credential id）を満たしつつ署名部分は出鱈目な assertion を送っても、検証を通過してしまいます。2FA は実質的に「決まった形の JSON を返すだけ」になり、物理キーを持っているかどうかは問われません。ここでは攻撃に使える具体的な手順（PoC）は示しません。要点は、WebAuthn の背骨である署名検証が、フォールバック実装で抜けていたことです。

どこまでの影響か

誤解を避けるために、影響の範囲を正確に押さえます。これは第一要素を飛ばせるものではありません。攻撃者はまず MySQL のパスワードでログインできる必要があり、その上で第二要素の WebAuthn 2FA を無効化できる、という性質です。研究者の評価は CVSS 3.1 で 8.1、ベクトルは権限一部必要（PR:L）です。到達できれば、得られるのは phpMyAdmin が持つ権限の範囲——つまりその接続で触れるデータベースへのフルアクセスで、ホスト上の PHP シェルではありません。

とはいえ、WebAuthn を 2FA に選ぶ動機は「パスワードが漏れても、物理キーが無ければ入れない」という強い保証です。その保証が、ライブラリを入れ忘れただけで静かに消えているなら、2FA を設定している安心感に反して、パスワード漏洩の時点で守りが崩れます。多層防御の最も頼りにしていた層が、実は検証していなかった——というのが、この問題の重さです。

何を直すか

一番確実なのは、web-auth/webauthn-lib を導入することです。これが入ると、createServer() は WebauthnLibServer を選び、署名の暗号検証を含む正しい WebAuthn 検証が行われます。CustomServer は使われなくなります。

自分の環境を確認する

版が 5.2.3 で WebAuthn 2FA を使っているなら、どちらのサーバが動いているかを確かめます。

php -r "var_dump(class_exists('Webauthn\\Server'));"

true なら WebauthnLibServer（本検証・対象外）、false なら CustomServer（署名を見ない・対象）です。false だったら、web-auth/webauthn-lib を入れて再確認します。いずれも「いま攻撃されているか」ではなく、どちらの実装で動いているかの確認です。確認できたら、ライブラリを導入し、公式の対応が出たらそれにも追随します。

影響範囲

直接の対象は、phpMyAdmin 5.2.3 で WebAuthn 2FA を使い、かつ web-auth/webauthn-lib を入れていない環境です。公式 tarball や --no-dev のインストールは、この条件に当てはまりやすい構成です。逆に、ライブラリを明示的に入れている環境は、WebauthnLibServer で正しく検証しているため、この問題の対象ではありません。phpMyAdmin は世界中で使われ、DB の管理画面という性質上、守りの要になります。WebAuthn 2FA を「入れたから安心」で終わらせず、実装がどちらで、本当に署名を検証しているかまで確かめることが、確実な備えです。とくに公開しているインスタンスや、多数の開発者が触る共有環境では、第二要素が形だけになっていないかを早めに点検する価値があります。公式の修正・CVE が出たら、本記事も合わせて更新します。

参照ソース

• phpMyAdmin WebAuthn.php（createServer のフォールバック・RELEASE_5_2_3）
• phpMyAdmin CustomServer.php（assertion を署名検証しない実装・RELEASE_5_2_3）
• phpMyAdmin composer.json（web-auth/webauthn-lib は require-dev）
• Abraxas Labs の研究（PMA-5.2.3-WebAuthn-2FA・責任ある開示）