要約

  • 2018年4月の攻撃は、Amazon Route 53 のアドレスへ向けたより具体的な BGP 経路を一部ネットワークが受け入れ、再帰リゾルバーが偽の権威サーバーへ到達したことで成立した。
  • 有効な対策は万能な管理者を置くことではない。各層の拒否権を残し、経路・DNS・証明書・取引の異常を不可逆な操作より先に結びつけることである。

最後の警告から逆にたどる

Cloudflare の記録では、偽サイトの証明書は自己署名だった。ブラウザーは信頼できない発行者を検出し、利用者に警告した。つまり攻撃者が経路と名前解決を欺いた後にも、まだ一つの拒否権が残っていた。

被害は、その警告を越えて偽ページを操作した場合に生じたと公開資料は説明する。MyEtherWallet は後に約15万ドル相当の Ether が失われたとした。ただし、この金額は被害サービス側の発表であり、全取引を独立監査した数字ではない。

警告を無視した利用者だけを原因にするのは不正確である。ブラウザーに届くまでに、敵対的な状態は複数の運用判断を通過していた。最後の判断が見えやすいからといって、上流の判断が消えるわけではない。

二時間弱の経路が作った入口

2018年4月24日、Cloudflare は11時05分頃から12時55分頃まで、Amazon の四つの /23 内に複数の /24 広告を観測した。対象アドレスは AS16509 の Amazon Route 53 権威 DNS に使われ、観測起点は eNet の AS10297、経路の一部には Hurricane Electric AS6939 が含まれた。

AS10297 が見えたことは、eNet 自身が攻撃した証明ではない。Cloudflare は顧客が広告した可能性も示した。経路データは到達性の変化を記録するが、操作した人物や意図までは記録しない。

偽の /24 は Amazon の正規集約より具体的だった。受け入れたネットワークでは最長一致が働き、正規経路を消さずに一部トラフィックを引き寄せられた。他の上流は広告を受け入れなかったようで、影響は均一ではなかった。

Cloudflare の 1.1.1.1 でも、シカゴ、オーストラリア、アジア、中東、アフリカの一部拠点が影響を受け、他は正常だった。このばらつきは、被害範囲が国ではなく相互接続とリゾルバーの経路で決まったことを示す。

再帰リゾルバーが他者へ影響を運ぶ

利用者の回線が偽経路を受け入れていなくても、利用中の再帰リゾルバーが受け入れていれば偽回答を受け取れた。リゾルバーは自分の経路表で到達した権威サーバーへ問い合わせ、その結果を複数の利用者へ配る。

偽サーバーは Route 53 全体を再現しなかった。Cloudflare によれば myetherwallet.com には応答し、他の問い合わせは失敗した。標的だけ正しく見え、周辺が SERVFAIL になる形は、障害平均では埋もれやすいが強い異常信号である。

公開記録は AWS コンソールへの侵入、ホストゾーンの変更、ドメイン移管、MyEtherWallet コードの侵害を示していない。攻撃者が得たのは一部パケットを受け取る技術的能力であり、アドレスや名前への正当な権限ではなかった。

五つの狭い判断

BGP 広告は経路を提案した。上流と受信ネットワークは伝播と採用を判断した。再帰リゾルバーは到達したサーバーから DNS データを得た。ブラウザーは証明書を検査した。最後にウォレット操作が価値移転を可能にした。

経路は名前を認証しない。DNS 応答は証明書を認証しない。証明書はサービスの善意を保証しない。ウェブページは取引意思を証明しない。狭い証拠が次の層で広い権限に読み替えられたとき、攻撃が完成する。

RPKI と DNSSEC の役割を混ぜない

RFC 6811 の経路起点検証は、検証済み ROA と BGP 起点を比較する。適切な長さで限定された ROA を検証し、Invalid を拒否するネットワークなら、異なる起点からのより具体的な広告を、リゾルバへ影響する前に入口で止められる。

それでも RPKI は AS パス全体を証明せず、全ネットワークに拒否を強制しない。許可起点の偽装や広すぎる maxLength には別の監視が要る。

DNSSEC は DNS データの出自と完全性を検証する。RFC 4033 が機能を定義し、RFC 9364 は最良現行慣行と位置づける。BGP が偽サーバーへ導いても、検証リゾルバーは正しい署名のない回答を拒否できる。

AWS が Route 53 の公開ゾーン署名と Resolver 検証を発表したのは2020年12月である。この事実から2018年の MyEtherWallet ゾーン状態を断定してはならない。DNSSEC は経路や取引意思も検証しない。

事後対策を機能別に読む

MyEtherWallet はドメインの Registry Lock と Registrar Lock、HSTS と preload、CAA、DNSSEC、CDN、DDoS 対策を挙げた。各対策は異なる失敗を止める。

ドメインロックは登録情報の不正変更を抑えるが、BGP 広告を止めない。CAA は認証局を制限するが、自己署名証明書はもともと信頼されない。HSTS preload は警告を越える操作をなくす。DNSSEC は偽回答を拒否する。ROA と ROV はその手前の起点を制約する。

対策数を数えるだけでは不十分だ。どの条件を止めるのか、誰が鍵や連絡先を管理するのか、失敗はどのログに出るのか、復旧後に何が残るのかを対応づける必要がある。

Running-Code Primacy が示す境界

Heng Lu の Running-Code Primacy をこの事件に当てると、記録が力を持つのは実装が受け入れた範囲だと分かる。偽経路は一部で採用され、他では拒否された。偽回答は一部リゾルバーで流通し、別の経路では届かなかった。TLS 警告は最後まで独立していた。

分散は自動的な正しさではない。それは複数の拒否点を残す設計条件である。技術的にパケットを引き寄せられても、合法的な権限は生まれない。運用上の能力と正当な権限を混同しないことが、事故記録の第一歩になる。

結論

事件の実行者、全被害者、全キャッシュ、正確な損失は確定していない。世界規模の一様な乗っ取りでもなかった。

それでも教訓は明確だ。一時的な経路が名前を借り、名前がアプリケーションの信頼を借りようとした。堅牢な設計は、その借用を各層で止める。

前の層が嘘をついたとき、次の層が許可を待たずに拒否できるか。それが多層依存を持つサービスの実効的な安全性である。

出典