AS-SET攻撃者に被害者ASを追加することによるBGPハイジャック

この記事は3つの部分に分かれています。 1つめには、BGPハイジャックとその従来のバージョンに関する一般情報が含まれています。 この現象に精通している人は、第2部に直接行くことをお勧めします。 2番目の部分では、AS-SETに外部ASを追加して、外部プレフィックスをアナウンスする方法について説明します。 3番目のパートでは、2番目のパートで説明した方法を使用して、torproject.orgリソースのIPアドレスを取得し、その証明書を発行する複雑さを評価します。 読者はBGPv4の原則に精通していると想定されます。

単純なBGPハイジャック

一言で言えば、BGPハイジャックは他の誰かのIPアドレス（ランダムまたは意図的）をキャプチャしています。

通常、BGPハイジャックは次のようになります。一部のプレフィックスに属さないASは、それをアナウンスし始め（エイリアンプレフィックス）、アップリンク/ピアがそれを受け入れ、インターネット上で広がり始めます。 彼らは、ジャンクションでプレフィックスのフィルタリングがないという理由でこれを受け入れます（これは設定エラーであるか、またはそのように考えられています（さまざまな理由で非常に大きな演算子を持つジャンクションでプレフィックスフィルターを構築することは非常に難しいため、この記事では重要ではありません） ） Rostelecom（ AS12389 ） が接頭辞Mastercard（ AS26380 ）、Visaおよびその他の金融機関（ソフトウェア障害の結果としての公式バージョンによる） を発表し始めた最近の最も有名な例の1つ。 これらのアナウンスメントがbgplay履歴（ web 、 json （ アーカイブ ）で表示）でどのように見えるかを見ることができます。これは、RIPEコレクターの1つにあります（プレフィックス216.119.216.0/24はMastercard（AS26380）に属します）。

"source_id": "05-193.203.0.185", "path": [ 6939, 12389 ], "community": [], "target_prefix": 216.119.216.0/24 

そして、実際の発表は次のようになりました。

  "source_id": "05-193.203.0.63", "path": [ 6720, 8447, 32787, 26380, 26380, 26380 ], "community": [ "1120:1" ], "target_prefix": 216.119.216.0/24 

つまり この場合、RostelecomはASから直接プレフィックスをアナウンスしました（AS-PATHの最後のASは12389です）。 AS-SETに従ってプレフィックスリストを構築したり、ROA RPKIに従ってプレフィックスを検証したりすることで、RostelecomのアップリンクとごちそうがRostelecomからプレフィックスをフィルタリングした場合、問題を回避できます。 大規模なオペレータ間のプレフィックスリストの構築は、多くの場合行われず、すべてがRPKIを実装しているわけではありません（ただし、 進捗はあります ）。 理論的には、このようなハイジャックは誰でも行うことができますが、発表されたプレフィックスが少なくとも1つのアップリンク/フィーストを「リーク」する場合のみです。 通常、ロシアの大規模なオペレーターは、顧客の方向にプレフィックスフィルターを構成するため、小さなAS（中小規模のオペレーター、一部のホスティングおよび一部の企業）は、ほとんどの場合、そのような攻撃を実行できません（ただし、すべては地域/国/特定のオペレーター）。

ただし、攻撃者は依然としてフィルタリングが設定されていない場所（アップリンク）を見つけ（2017年にはブラジルがハイジャックのリーダーでした）、より効果的な攻撃のためにIPアドレスを取得して攻撃を実行します（多くの場合、このようなイベントはニュースフィードに分類されます）。実際の発信者よりも特定のプレフィックス（長いマスク）をアナウンスします。 次に、ROA RPKI検証もAS-SETプレフィックスリストも保存しない攻撃バリアントに移りましょう。

AS-SETにAS犠牲者を追加したBGPハイジャック

次のシナリオを検討してください。

1. 攻撃者はASアドレスとIPアドレスを取得します（実際、技術的には、IPアドレスは必要ありません。質問をしない可能性が高いです）。
2. 攻撃者は、発表されたプレフィックスに関するデータのソースとしてASだけでなくAS-SETを指定して、さまざまな大規模なオペレータとIX（少なくとも1つのオペレータまたはIX）に接続します（これは、オペレータ間相互作用の通常のプラクティスです（クライアントとアップリンクの関係にある場合を含む）、またはIX-ahに含める場合））。 通常の場合、クライアントが行き止まりではなく、それ自体がbgpおよび独自のネットワークを持つクライアントを持っている（または持っている）と想定される場合、ASだけでなくAS-SETが指定されます。
3. しばらくすると、攻撃者は被害者のASをAS-SETに追加し、自分自身でプレフィックスをアナウンスし始めます。 発表されたAS-PATHは「AS_ attacker AS_victims」のようになります。 自動構築されたプレフィックスリストの観点から、およびRPKIの観点から、これは完全に有効なアナウンスであるため、両方の保護メカニズムはここでは機能しません。
4. アナウンスされたプレフィックスは、実際のアナウンス（犠牲者のアナウンス）と競合し始め、勝者はルーティングテーブルに入り、敗者は勝ち負けない（犠牲者のアナウンスはそのまま残ります）。 攻撃者が使用するアップリンクの数とIXの数に依存します。 攻撃者がクライアントとしてASに接続し、その内部（ほとんどの場合）で、ローカル設定が大きいために被害者に勝ちます（被害者が同じアップリンクのクライアントでない限り、被害者はAS-PATHに従って勝ちます。 prepend）、つまり 攻撃者は、攻撃の効果を最大化するために、AS-SETでできるだけ多くのアップリンクに接続する必要があります。
   また、攻撃者は最大数のIXに接続する必要があります。 通常、デッドロックASは最大のローカル設定をIXに設定し、被害者プレフィックスがIXに関係しない場合、デッドロックASのルーティングテーブルで攻撃者のアナウンスが失われます。

理論的には、これは非常に強力な攻撃ですが、幸いなことに実際には、次の制限が発生します。

1. 少なくとも1つの法人を作成する必要がありますが、実際には、さまざまな国で必要になる可能性が高いでしょう。
2. LIR / RIRと、ほとんどの場合、接続料を支払うオペレーターIXと契約を結ぶ必要があります。
3. 一部の演算子はまだAS-SETプレフィックスリストを自動的に作成しないため、このための文字を書く必要があります。 経験豊富な管理者は、広く知られているAS-kaが未知の会社のAS-SETに登場すると、何かを疑います。
4. 攻撃後、使用されている機器（何らかのデータセンターにある場合）は、刑事事件が開かれた場合に押収される可能性が高くなります。
5. さまざまな演算子/ IXのプレフィックスリストはさまざまなタイミングで更新されるため、これが最も簡単な仕事ではない場合は、誰が更新するかを分析する必要があります。

可能な保護対策：

1. 理論的には、このような攻撃から防御するには、できる限り多くのインターフェイス（より良い、クライアント側、ローカル設定が高いため）とIXが必要です。 つまり 攻撃者が行うのと同じことを行います。 もちろん、実際にはこれを実装するのは非常に難しく、かなりのリソースが必要になります。 この方法は、プロベースで情報セキュリティサービスを提供するサービスにのみ関連します。
2. Webサイトがある場合は、アカウントタスクでCAAレコードを使用します（SSL証明書プロバイダーがサポートしている場合。Letsencryptがサポートしています）（ RFC6844を参照）。 この場合、攻撃者は証明書を発行できません（CAAレコードを変更できない場合）。
3. 理論的には、BGPsecの広範な実装によってこのような攻撃は排除されるはずですが、その運命はまだ明確ではありません（実際にはまだ適用されていないか、非常にまれです）。
4. 代替検証AS_PATHの実装（BGPsecなし）（これまでのところ、これは、その広範な実装の場合に説明された問題を解決するドラフトです）。
5. AS-SETに外部ASを無制限に追加することを禁止すると（AS所有者の許可なしに）、AS-SETを使用してジョイントをフィルタリングする地域でこのような攻撃を実行する可能性を減らすことができます。 現在、そのような禁止事項はありません。

実際、ほとんどの読者にとって、彼らに適用される唯一のアドバイスは、No。2（CAAレコードでのアカウントの使用に関して）であり、接続性の良いホストを選択するという点で部分的にNo. 1です。 同時に、レコードをホストしているDNSサービスに対する攻撃の可能性を覚えておく必要があります（ただし、これは別の問題であり、多くの資料があります）

torproject.orgをキャプチャするのは難しいですか

攻撃者は次の2つの問題を解決する必要があります。

• トラフィックをターゲットオーディエンスにリダイレクトします（ターゲットオーディエンス-偽サイトを受け取るユーザー）
• 証明書を生成する

入門：

 $ dig torproject.org CAA +short 128 issuewild "\;" 0 iodef "mailto:torproject-admin@torproject.org" 128 issue "globalsign.com" 128 issue "letsencrypt.org" $ dig torproject.org +short 95.216.163.36 138.201.14.197 

ご覧のとおり、CAAレコードがあり、letsencryptから証明書を取得できます。CAAレコードにはアカウントへのバインドがありません。つまり、理論的には問題は攻撃者によって解決されます。 torproject.orgのIPアドレスは、有名なHeznerホスティングが所有しています。

攻撃者のターゲットオーディエンスがロシアのオペレーターのクライアントであるとします。 ヘズナーはロシアの事業者のクライアントではありません（ただし、直接またはIX-sを介して大規模な事業者とピアリングしています）。 攻撃者がCAトラフィックを自分自身にリダイレクトする最も簡単な方法は、このオペレーターのクライアントになり、より高いローカル設定を犠牲にして単純に勝つことです。 ここでは、すべてが特に比較的単純で明確です。

letsencryptで証明書を取得するには、letsencryptがホスティングしているプロバイダーが必要で、Hezner（AS24940）ではなく攻撃者にトラフィックを誘導します。 letsencryptはアメリカとヨーロッパのIPの異なるアドレスに解決しますが、acme-v02.api.letsencrypt.org / 2.19.125.202からのトラフィックが攻撃者のホス​​トに送信されるのに影響を与えることがどれほど難しいか見てみましょう。 ここでは、letsencryptが世界中で非常に良好な接続性を備えたAkamai CDNでホストされているという事実に直面しています（ほとんどの主要なIXに存在し、多数の主要なプレーヤーと直接結合しています）。 アカマイにはパブリックLGがありません。原則として、traceroute / pingを実行できるクライアント用のAPIがありますが、パブリックLGがなくても、 ピアリングデータベースを調べてその存在の規模を評価できます。 同様に、 heznerを見ることができます。 両方のASに同じIXが存在することは容易にわかります。そのため、統一に近い確率で、Akamaiテーブル（AS20940）のAS Heznerプレフィックス（AS20940）はAS_PATH 24940で見えると結論付けることができます。 IXを通じてHeznerのプレフィックスをアナウンスしようとすると、AS_PATHに従って、Heznerからの実際のアナウンスが失われます（AS_PATHには攻撃者のASが含まれるため）。 考えられる解決策は、攻撃者とアカマイの間で「直接」ピアリングを編成することです（アカマイがこれに同意し、ローカル環境がIXとのジャンクションよりも高い場合）。

要約すると、他の誰かのASをAS-SETに追加すると、torproject.org Webサイトの大幅な劣化を引き起こす可能性があります（ただし、一般的なケースではなく、多数のクライアントに対して）。実際の発信者（Hezner）とletsencrypt（アカマイ）が使用するCDNとの接続が良好であるため、うまくいかない可能性があります。 ただし、他のケースでは、被害者サイトのホストと認証機関の間に通過ASがあり、それらがAS_PATHに存在する場合、説明した方法を使用して証明書を取得するリスクが大幅に増加します。