暗号通貨は自分たちの生活を送っていて、ネットワークとネットワークサービスは自分たちの生活を送っているという事実に何とか慣れています。 もちろん、暗号通貨の開発者は、ルーティング情報を交換するためにインターネットチャネルプロバイダーが使用する
BGPプロトコルを必要としないことがよくあります。 まあ、これは攻撃者が彼らの創意工夫、ネットワーク技術の知識を使用すること、およびイーサリアム暗号通貨の信頼できる所有者のエレガントな強盗を手配することを止めませんでした。

攻撃の本質は簡単です。BGPを使用して、攻撃者は
Amazon Route 53サービス (これはAmazonが提供するDNSサービス)
のトラフィックをDNSサーバーに
リダイレクトできました。これにより、MyEtherWallet.com元のサイト。 オリジナルのMyEtherWallet.comには、イーサリアム暗号通貨ウォレットのWeb実装が含まれていますが、クローンはフィッシング攻撃を実行しました。その結果、攻撃者は2時間で215 ETH(〜137千ドル)を盗みました。

架空のルートの置換は、コロンバス(米国オハイオ州)にあるアメリカの大手インターネットプロバイダー
eNet (
AS 10297 )に代わって
行われました。 BGPの発表後、レベル3、ハリケーンエレクトリック、コジェント、NTTなどの最大のオペレーターを含むすべてのeNetピアは、攻撃ルートによって指定されたAmazon Route 53方向に送信されるトラフィックのラップを開始しました。 BGPの架空の発表のため、サイズ/ 24の5つのAmazon所有サブネットへのリクエスト(合計約1300のIPアドレス):
- 205.251.192.0/24
- 205.251.193.0/24
- 205.251.195.0/24
- 205.251.197.0/24
- 205.251.199.0/24
それらは、シカゴのEquinixプロバイダーのデータセンターにある攻撃者が制御するサーバーにリダイレクトされ、そこでDNSの回答を置き換えるためにMiTM攻撃が組織されました。 その結果、ドメインに対して権限のあるサーバー(この下のスライドではサーバー205.251.195.x)に要求が送信される通常のDNS操作スキームは以前と同様に機能し続けましたが、攻撃者サーバーはアドレス205.251.195.xで動作を開始しました。


状況は逸話的ですが、
ほぼ2時間 (2018年4月24日
午前 11
時 5
分から午後 12
時 55
分まで)、誰もこの置換に気付かず、人々は(注意!)
自己署名 HTTPS証明書が使用されました(これについては、ブラウザーは安全な接続の問題に関する警告を表示します)。 証明書の承認(!)およびフィッシングサイトでの認証の場合、ユーザーはウォレットからすべての資金を
引き落とされました。
攻撃者は明らかに貧弱ではないことは注目に値します。攻撃中に転送がリダイレクトされたETHウォレットには、現在24,276 ETHがあり、これは1,500万ドルを超えています。
攻撃中にMyEtherWallet.comのDNSレコードが変更されたことは確かに知られていますが、これはこのサイトのみが終了したことを意味するものではありません。 大規模なISPのBGPルーターにアクセスし、巨大なDNSトラフィックを処理するためのリソースが利用できるということは、攻撃がMyEtherWalletに限定されていなかったことを示していると考えるのは理にかなっています。 この仮説は、攻撃で使用されるETHウォレットへの継続的な転送ストリームによってもサポートされています。 他の仮定によると、より大規模な攻撃を実行する前にテスト実験のみが行われました。
証明書の問題は非常に微妙です。 攻撃者は、Let's Encryptから証明書を取得することができます
。DV検証はかなりの時間を費やすことを除いて、DV検証がかなり可能だったためです。アナウンスメントがそれらに届かないようにし、LEが悪意のあるDNSを「見ない」ようにします。
明らかに、DNS over HTTPS(DoH)やDNS over TLS(どちらもCloudFlareの
DNSサービス1.1.1.1で提供されています)など、DNSを操作するためのより安全なプロトコルとテクノロジーを使用するという考えは、すべて関連するオーバーヘッドにもかかわらず、より合理的です。