Ing. Calogero Bono
Polymarketは、暗号資産を使った予測市場プラットフォームですが、外部のプロバイダーから発生した攻撃を受けて、約1時間取引を停止しました。Hudson Rockの調査によると、約250万ドルが盗まれたとされています。悪意あるコードは、Webサイトのパフォーマンスを計測するサービスであるDebugBearのインフラに置かれていました。暗号資産を利用しない人にも関係する話で、サイトに組み込まれた外部スクリプトひとつが、どれほど高くつくかを示しているからです。
事実に入る前に、いくつか用語を確認しておきます。予測市場とは、現実の出来事の結果に賭けるプラットフォームのことです。ウォレットは、暗号資産を保管するデジタル財布です。POLは、Polygonブロックチェーンの暗号資産です。RUMはReal User Monitoringの略で、訪問者のブラウザからサイトの性能データを収集するJavaScriptのスクリプトを指します。C2はCommand and Controlサーバーの略で、マルウェアが指示を受け取るためのサーバーです。
Polymarketで何が起きたのか？
Punto Informaticoの整理によると、プラットフォームのステータスページでは、リレイヤーの運用が止まった後の19時05分に調査が始まりました。その後、「cancel-only」モードが有効になり、注文の取り消しだけが可能になりました。約30分後、Polymarketは問題を特定して解決したと発表しましたが、慎重を期して運用は止めたままにしました。
BleepingComputerが伝えるところでは、同社は「第三者プロバイダーの一つが侵害されました。この件は関係する捜査機関に照会しています。」と書いています。被害を受けたユーザーには補償が行われるとも付け加えました。取引は最初の停止から約1時間後に再開されました。
問題は国際版プラットフォームに関するものでした。Wiredによると、米国向けのPolymarket USは影響を受けていません。同じくWiredによると、侵害された提供元は英国に拠点があり、英国の当局にも通知されています。
悪意あるスクリプトはどのように動いたのか？
Hudson Rockは、DebugBearのインフラ上のアドレスから配布された悪意あるJavaScriptを発見しました。Polymarketのサイトは、このスクリプトをRUMサービスの一部として読み込んでいたため、コードはユーザーのブラウザ内で実行されていました。Punto Informaticoによると、被害者がアカウントにログインすると、スクリプトはウォレットの残高を確認し、暗号資産を攻撃者に送っていました。
BleepingComputerはファイルのコピーを分析し、動作をより詳しく説明しています。
- 訪問者がPolymarketにログインしているかを確認し、認証済みのセッションを利用しようとします。
- 残高や保有ポジションを調べて、資産の価値を見積もります。
- 場合によっては、ポジションを自動で売却しようとし、別の場合にはトークンを攻撃者のウォレットへ直接送ろうとします。
- プラットフォームにもともとある取引機能を悪用して、暗号資産を移転しやすい資産に換えようとします。
スクリプトは、アカウントや住所、結果に関するデータを送信し、指示を受け取るためにDebugBearのサーバーとも通信していました。BleepingComputerは、同じインフラを配布とC2の両方に使っていることから、攻撃者がPolymarketのシステムにどの程度のアクセス権を持っていたのかに疑問を投げかけています。
実際にどれだけ盗まれたのか？
数字は一致しておらず、どれもPolymarketが確認したものではありません。以下は私たちの集計ですが、各情報源の数字を並べたものにすぎません。
- Hudson Rockは約2,860万POLと、約257万ドル相当だと述べています。これはPunto InformaticoとBleepingComputerが報じています。
- BleepingComputerによると、Hudson Rockが調査した時点で、問題のウォレットには約219万ドルが入っていました。
- Wiredによると、分析会社Bubblemapsは約700人のユーザーが関係し、約270万ドルが盗まれたと見積もっています。
Wiredの取材に対し、Polymarketは影響を受けたトレーダーの人数や損失額を明らかにしませんでした。影響を受けたユーザーに補償を行うとあらためて表明しています。
サードパーティ製スクリプトはなぜリスクになるのか？
外部のスクリプトは、訪問者のブラウザ上で自社サイトと同じ権限を持って動くからです。提供元が侵害されると、自分では一行も触っていなくてもコードが変わってしまいます。今回のサービスは性能の計測だけが目的でしたが、そこから認証済みセッションの中で行動できてしまったのです。
DebugBearはXでインシデントを認め、BleepingComputerによると、顧客に対してサイトからRUMコードを削除するよう求めました。同社は「We're impacted by an ongoing security incident」と述べています。Hudson Rockの研究者は、Polymarket自身のコミットメッセージも見つけています。「chore(polymarket) remove debugbear rum script」というもので、発表の少し前に連携が外されていたことを示しています。
これは、イタリアの中小企業と自動化された攻撃を取り上げたときにも扱ってきたテーマです。数十億ドル規模のプラットフォームでなくても、攻撃対象となる範囲は持っています。
知っておくべき限界
- Polymarketは、影響を受けたユーザーの数、盗まれた金額、補償の方法をまだ明らかにしていません。
- 提供元の名前はPolymarketからは出ていません。DebugBearの名前は、Hudson Rockの分析と同社自身の確認から判明したものです。
- イタリアと米国の情報源では時刻の基準が異なり、私たちは照合できていません。そのため、約1時間の停止という数字だけを採用しています。
- 攻撃者は特定されていません。DebugBearがどのように侵害されたのかもわかっていません。
- BleepingComputerは両社に問い合わせていますが、回答は報じられていないため、経緯は変わる可能性があります。
- Punto Informaticoは、このプラットフォームはイタリアからは本来アクセスできないはずだと指摘しています。
デジタル業務に携わる人にとっての影響
まず実務上の影響があります。アナリティクス、チャット、計測、広告など、サイトに貼り付けるスクリプトはすべて、自分で管理できていないかもしれないコードとして扱う必要があります。ログイン、決済、個人データを扱うサイトであれば、そのコードは利用者の画面に見えるすべてにアクセスできてしまいます。
開発者にとってのリスクは二重です。利用者の安全を守る責任があり、同時に顧客に対する責任もあります。顧客は自社のコードと提供元のコードを区別しません。ログインのあるページを持つネットショップや業務システムにも同じ考え方が当てはまり、暗号資産だけの話ではありません。ネットショップを運営しているなら、カートや決済のページにどのスクリプトが読み込まれているかを把握しておくべきです。
さらにスピードの問題もあります。スクリプトを外してから取引を再開するまで、約1時間しかかかっていません。侵害された提供元を切り離すための手順をあらかじめ用意しておけば、対応時間を大きく短縮できます。
編集部の見解
この事例が示唆に富むのは、失敗が派手なものではないからです。パフォーマンス監視サービスは無害に見えるため、誰も疑いの目を向けません。それでも機能させるためには、すべての訪問者のブラウザで動く必要があります。結局のところ、コードを一行貼り付ける手軽さの裏には、よく考えられないまま渡されるアクセス権があるのです。
Polymarketの対応は、スピードの面では妥当だったと考えます。取引を止め、スクリプトを外し、補償を約束しました。一方で、情報発信は説得力に欠けます。提供元の名前を出さず、影響を受けた人数も説明せず、数字の確認をHudson RockやBleepingComputerに任せた形になっています。Wiredは、2百万ドル超の損失を出した以前の侵害にも触れています。二つの類似した事故は、不運というより、プロセスの問題を疑わせます。企業にとっても同じ教訓があります。私たちが追ってきた別のケースと同じく、リスクは当たり前だと思っている部分から生じるのです。
よくある質問
Polymarketは直接ハッキングされたのですか？
いいえ、情報源によれば、攻撃は外部の提供元を経由したものです。Wiredは、侵害された英国のベンダーについて報じており、プラットフォームのサイト自体ではありません。ただし、悪意あるコードはPolymarketのページ上で動いていました。
盗まれた金額はいくらですか？
公式の数字はありません。Hudson Rockは約257万ドル、Bubblemapsは約270万ドルで約700人のユーザーが関係していると示しています。Polymarketは数字を確認していません。
ユーザーには補償されますか？
Polymarketによれば、はい。同社は影響を受けたトレーダー全員に補償すると表明しています。ただし、手続きがどのように進むのかはまだ説明されていません。
DebugBearとは何ですか？
Webサイトのパフォーマンスを監視するサービスです。同社のRUM製品は、JavaScriptを使って訪問者のブラウザから指標を収集します。同社はインシデントを認め、顧客にコードの削除を求めました。
外部スクリプトを使うサイトでどう身を守ればよいですか？
使っているスクリプトを一覧にして、必要のないものは削除しましょう。ログインや決済のあるページでは提供元を制限し、すぐに切り離せる手順を用意しておくことをおすすめします。
今後数か月で確認すべき点
今後も、当局の捜査、DebugBearの説明、Polymarketの補償の進み具合を追う必要があります。その間も、次の三つの面で対応できます。
- 自社サイトが読み込んでいる外部スクリプトをすべて書き出し、今も必要かを確認しましょう。特に会員専用エリアを重点的に見直してください。
- サーバーとコンポーネントを最新の状態に保ち、必要に応じてセキュリティ更新付きのマネージドホスティングも検討してください。提供元からのお知らせも確認しましょう。
- 連携を数分で外せる担当者と手順を決めておきましょう。インシデントの最中に慌てないためです。独自のアプリケーションを持つ場合は、ソフトウェア開発の段階から担当者と話し合っておくと安心です。
自動化によってリスクがどう移動するのかを知るには、自律型ハッカーが中小企業にとって何を意味するのかについての解説記事もあわせてご覧ください。
