はじめに
このブログ記事では、国家に支援された、DNS システムを巧みに操作する攻撃の技術的な詳細について説明します。今回のキャンペーンの標的は、中東および北アフリカの国家安全保障組織にほぼ限定されています。影響を誇張する意図はありませんが、今回の成功を受け、攻撃者が標的を世界中の DNS システムにまで広げる可能性が懸念されます。DNS はインターネットの基盤となる技術です。DNS システムが操作されてしまうと、インターネットに対するユーザの信頼性が損なわれる可能性があります。こうした信頼性と DNS システムの安定性は、一体となってグローバル経済を牽引しています。信頼できる国家であれば DNS を攻撃対象とするのではなく、DNS とその管理組織に対する一切の攻撃を排除すべく連携して取り組むべきです。同時に、DNS を標的とする無責任な攻撃者を協力して追跡すべきです。
エグゼクティブ サマリー
Cisco Talos は、「Sea Turtle(ウミガメ)」と名付けた、新しいサイバー脅威キャンペーンを発見しました。このキャンペーンの標的は主に中東や北アフリカの官民機関で、国家安全保障組織も含まれています。Sea Turtle の推定開始時期はかなり前の 2017 年 1 月ですが、攻撃は 2019 年第 1 四半期も続いています。Talos が調査したところ、このキャンペーンにより 13 ヵ国で少なくとも 40 の組織が侵害を受けています。Sea Turtle について Talos では、機密性の高いネットワークやシステムへの永続的なアクセスの取得を目指す、国家に支援された高度な犯罪組織が背後にいる可能性が高いと考えています。
Sea Turtle の中心的な攻撃手口は DNS ハイジャックです。「DNS ハイジャック」とは、DNS ネーム レコードを不正に改ざんし、攻撃者自身が制御するサーバにユーザを誘導する手口を指します。2019 年 1 月 24 日に米国国土安全保障省(DHS)が出した警告では、DNS ハイジャックによってユーザ トラフィックがリダイレクトされ、組織のドメイン名に有効な暗号化証明書を不正に取得される可能性があると注意を喚起しています。
Sea Turtle のキャンペーンを分析したところ、2 つの異なる被害者グループを特定しました。1 つ目の被害者グループは「本命の標的」、つまり国家安全保障機関、外務省、大手のエネルギー企業などです。これらの標的への侵入経路となったのは、標的組織にサービスを提供する第三者組織でした。2 つ目の被害者グループは「二次的な標的」で、多数の DNS レジストラ、通信会社、およびインターネット サービス プロバイダーが含まれています。Sea Turtle で注目すべき点のひとつは、これらの第三者組織を足がかりにして「本来の標的」に DNS ハイジャックを仕掛けた手口です。
Sea Turtle の手口は、2018 年 11 月に Talos が紹介した DNSpionage の手口とは明確に異なる、独立したものであると考えられます。Sea Turtle キャンペーンは幅広い DNS レジストラとレジストリを標的にしているため、DNSpionage よりも深刻な脅威であることはほぼ確実です。DNS ハイジャックを成功させるために必要であろうアクセス レベルを踏まえれば、中東や北アフリカなどでは今でも高度な脅威にさらされていると考えられます。Sea Turtle の攻撃手法は効果的であるため、他の犯罪組織が同じ手法を採用しても不思議ではありません。そのため、国や組織の規模を問わず、同様の手口への対策を進めておくことをお勧めします。
Sea Turtle の背後にいる攻撃者は明らかに技術力が高く、大胆であると言えます。Sea Turtle の攻撃者は、DNS レジストリの侵害が最初に確認されたケースの攻撃者でもあり、非常に高度な知識があることは確実です。また Sea Turtle の攻撃者は、自分たちの手口が広く公開されているにもかかわらず攻撃を継続しています。これは他の攻撃者と比べて大胆であり、今後の抑止が難しい可能性もあります。多くの攻撃者は、自身のキャンペーンが一般に知られると活動を停止するか、停滞させる傾向にあるからです。
この記事では、通常の Talos ブログ記事と同様、技術的な分析をご紹介します。また、攻撃手法や思考プロセスについても解説します。記事の最後では、これまでに観察してきた IOC を公開します。ただし IOC はこれら以外にも間違いなく存在すると考えられます。
ドメイン ネーム サービスとレコード管理の背景
Sea Turtle の攻撃者は、ドメイン ネーム空間内の各レベルで DNS レコードを巧みに操作して偽造することにより、組織への侵入に成功しました。このセクションでは、背景を整理できるよう、DNS レコードが管理されている場所と、DNS レコードへのアクセス方法を簡単に説明します。
組織の DNS レコードにアクセスする 1 つ目の方法は、最も直接的なもので、レジストラと登録者のクレデンシャルを通じて行われます。これらのクレデンシャルは、クライアント側、つまりレジストラから DNS プロバイダーにログインするために使用されます。組織のネットワーク管理者のクレデンシャルを入手できれば、攻撃者は同じ組織の DNS レコードを自由に変更できます。
DNS レコードにアクセスする 2 つ目の方法では、「レジストラ オペレータ」とも呼ばれる DNS レジストラを使用します。DNS レジストラは一般に ISP、通信プロバイダー、Web ホスティング企業などの組織で、ドメイン レジストリを通じて登録者に代わって DNS レコードを管理しています。ドメイン レジストリ内のレコードには、Extensible Provisioning Protocol(EPP)を使用するレジストリ アプリケーションを介してアクセスします。EPP については、「レジストラのアプリケーションとレジストリ アプリケーションとの間の通信手段」として、Request for Comment(RFC)5730 に詳細情報が記載されています。レジストラから EPP キーのいずれかを不正に取得できた場合、攻撃者は、そのレジストラが管理する DNS レコードを自由に改ざんできます。
DNS レコードにアクセスする 3 つ目の方法では、レジストリのひとつを介します。現時点では 12 のレジストリが存在し、各ドメイン情報のデータベースを管理しています。たとえば Verisign は、「.com」のトップレベル ドメイン(TLD)に関連付けられているエンティティすべてを管理しています。ICANN によると、ドメイン レジストリは、「(13 の)権威サーバによって委託管理されるルート ゾーン」に保存されています。これらのレジストリは、国別コード トップレベル ドメイン(ccTLD)と汎用トップレベル ドメイン(gTLD)全体を管理しています。
最後は、攻撃者がルート ゾーン サーバを攻撃して、レコードを直接変更する方法です。ただし Sea Turtle を含めたいかなるケースであれ、ルート ゾーン サーバが攻撃または侵害されたことを示す証拠は見つかっていません。ここでは可能性の話として紹介しています。ルート DNS サーバの各管理機関は、「ルート(サーバ)ゾーン内のデータの整合性が失われた、または侵害された兆候はない。(中略)クライアントがルート サーバから予期しない応答を受信した兆候はない」という共同声明を出しています。
Sea Turtle の DNS ハイジャック手法の分析
重要な点ですが、DNS ハイジャックは、攻撃者にとって主な目的を達成するための手段にすぎません。確認された行動を考慮すると、攻撃者の最終的な目的は、クレデンシャルを盗み、特定のネットワークやシステムへ侵入することであると考えられます。そのために Sea Turtle の攻撃者が取った手口は、以下のとおりです。
- 標的の DNS レコードを制御する手段を確立する。
- DNS レコードを改ざんし、標的の正規ユーザを自身が制御するサーバに誘導する。
- 自身が制御するサーバとユーザが通信する間に、正当なユーザ クレデンシャルを取得する。
以下の図は、Sea Turtle の攻撃者が最終目標を達成するために使用したと考えられる DNS ハイジャックの方法です。
リダイレクション攻撃の手順
攻撃のノウハウ
侵入経路
Sea Turtle の侵入経路は、既知の脆弱性のエクスプロイトや、スピアフィッシング電子メールです。侵入目的で、または侵入した組織内での水平移動のために、既知の CVE が複数エクスプロイトされたと考えられます。Talos の調査で利用が判明した脆弱性は以下のとおりです。
- CVE-2009-1151:phpMyAdmin に影響を与える PHP コード インジェクションの脆弱性
- CVE-2014-6271:GNU Bash システム(特に SMTP)に影響を与えるリモート コード実行の脆弱性(Shellshock CVE の一部)
- CVE-2017-3881:シスコ スイッチの昇格権限を使用した、未認証ユーザによるリモート コード実行の脆弱性
- CVE-2017-6736:シスコのサービス統合型ルータ 2811 で発見されたリモート コード実行の脆弱性
- CVE-2017-12617:Tomcat を実行する Apache Web サーバで確認されたリモート コード実行の脆弱性
- CVE-2018-0296:Cisco 適応型セキュリティ アプライアンス(ASA)およびファイアウォールへの不正アクセスを許可するディレクトリ トラバーサル
- CVE-2018-7600:Drupal(別名「Drupalgeddon」)で構築された Web サイトにおけるリモート コード実行の脆弱性
2019 年当初の時点で確認できたスピアフィッシング電子メールの唯一の証拠は、侵害された組織による情報開示で得られたものです。証拠が得られたのは 2 月中旬で、ドメイン ネーム システムの中核要素を管理するインターネット エクスチェンジの 1 社である Packet Clearing House が、スピアフィッシング電子メールによる侵害を受けたと公表したことがきっかけとなりました。
高度な攻撃者による他の侵入ケースを考えると、上記の CVE リストは不完全であると考えられます。Sea Turtle の攻撃者にとって、新しい侵入経路を見つけた際に既知の脆弱性を利用するのは造作もないことでしょう。CVE リストは「氷山の一角」だと言えます。
感染経路を築くため、各国の標的に DNS ハイジャック攻撃が実施
典型的なキャンペーンでは、攻撃者が標的の NS レコードを変更して悪意のある DNS サーバにユーザを誘導することで、すべての DNS クエリに対して攻撃者が制御する応答を返します。DNS レコードがハイジャックされた状態が続く時間は、数分から数日に及びます。攻撃者はその間、特定のドメインに対してクエリを実行した被害者をリダイレクトできる可能性があります。こうした攻撃手法については、これまでに他のサイバーセキュリティ企業からも報告されてきました。攻撃者が制御するネーム サーバは、標的ドメインに対するクエリを受信すると、偽造された「A」レコードで応答します。この「A」レコードは、正当なサービスの IP アドレスの代わりに、攻撃者が制御する MitM ノードの IP アドレスを返します。一部のケースでは、存続可能時間(TTL)の値が 1 秒に変更されました。おそらくこれは、被害者のマシンの DNS キャッシュにレコードが残るリスクを最小限に抑えるためです。
Sea Turtle キャンペーンで使用されてきたネーム サーバのうち、2019 年に確認されたものは以下のとおりです。
ドメイン | 使用されていた期間 |
ns1[.]intersecdns[.]com | 2019 年 3 ~ 4 月 |
ns2[.]intersecdns[.]com | 2019 年 3 ~ 4 月 |
ns1[.]lcjcomputing[.]com | 2019 年 1 月 |
ns2[.]lcjcomputing[.]com | 2019 年 1 月 |
中間者サーバによるクレデンシャルの収集
ドメインの DNS レコードにアクセスした後、攻撃者は自身が制御するサーバに中間者(man-in-the-middle、MitM)フレームワークを構築します。
攻撃のこの段階では、ユーザのクレデンシャルを取得するために、正当なサービスに扮した MitM サーバを構築します。攻撃者はクレデンシャルを取得した後、ユーザを正当なサービスに渡しますが、検出を回避するため「証明書を偽装(certificate impersonation)」します。「証明書偽装」の手口では、標的のドメインに対して署名済み X.509 証明書を(標的が使用しているのとは別の)認証局から取得し、標的が使用している正規の証明書だと見せかけます。たとえば DigiCert 発行の証明書を使う Web サイトでは、同じドメインで証明書を取得しますが、署名者は Let’s Encrypt や Comodo 社といった別の認証局になります。この手口では、Web ブラウザの URL バーに普段と同じ「SSL 鍵」アイコンが表示されるため、MitM の検出がさらに困難になります。
こうしてスプーフィングされた Web ページに被害者がパスワードを入力すると、ログイン情報が攻撃者の手に渡ることになります。被害者にとっての攻撃の兆候は、ユーザが自身の情報を入力した際や、サービスへのアクセスが確立された際の短い遅延だけです。アカウントへのアクセスには正当なネットワーク クレデンシャルが使用されているため、防御側が検出できる攻撃の兆候はほぼ皆無です。
以前の記事では MitM サーバの IP アドレスを公開しましたが、攻撃を観察した結果、16 台の別のサーバも特定されました。既知の不正な IP アドレスの一覧は、末尾の「侵害の兆候(IOC)」セクションを参照してください。
盗み出した SSL 証明書によるクレデンシャルの収集
ネットワークへのアクセスを確立した後、攻撃者は組織の SSL 証明書を盗み出します。盗み出した証明書は自身が制御するサーバ上で使用します。他のクレデンシャルも収集すべく、このサーバから追加の MitM 攻撃を仕掛けます。これにより、被害者のネットワーク内では攻撃者のアクセスが拡大することになります。盗まれた証明書が使用される期間は一般に 1 日未満です。これは攻撃者側にとっての安全措置だと考えられます。盗んだ証明書を長期にわたって使用すると、検出されるリスクが高まるからです。攻撃者が制御するサーバで盗まれた証明書が表示されたケースもあります。
Sea Turtle の注目すべき点のひとつは、MitM 攻撃で VPN アプリケーション(Cisco 適応型セキュリティアプライアンス(ASA)など)を偽装できる攻撃者の技術力です。現時点では、ASA の新たな脆弱性を攻撃者が発見したと考えていません。考えられる可能性は、被害者のネットワークにリモートからアクセスするため、ASA の SSL 証明書の信頼関係を逆手に取って VPN クレデンシャルを収集したということです。この手の MitM 攻撃では他の VPN クレデンシャルも収集できます。
たとえば DNS レコードを調べたところ、標的ドメインは攻撃者が制御する MitM サーバに解決されたことが判明しました。その翌日には、前述の IP アドレスに関連して、サブジェクト欄のコモン ネームが「ASA Temporary Self Signed Certificate」と記載された SSL 証明書を発見しました。この証明書は、攻撃者が制御する IP アドレスと、被害者の組織と関連する IP アドレスの両方で確認されています。
同じ攻撃者による別のケースでは、レジストリの 1 社である NetNod が侵害されました。同社は公式声明で侵害の事実を認めています。NetNod 社への不正アクセスを足がかりに、攻撃者は sa1[.]dnsnode[.]net の DNS レコードの改ざんにも成功しています。改ざんによりリダイレクトが発生し、最終的にはサウジアラビア(.sa)の TLD 管理者のクレデンシャルが攻撃者の手に渡りました。サウジアラビアには他にも被害者がいると考えられます。
2019 年 3 月 27 日に発生した最近のキャンペーンでは、スウェーデンのコンサルティング企業である Cafax 社が標的にされました。Cafax 社が公開している Web ページによれば、コンサルタントの 1 人は特定の DNS サーバ ゾーン(i[.]root-server[.]net)の管理に深く関わっています。この DNS サーバ ゾーンを管理しているのは NetNod 社です。NetNod 社が標的になったのは、攻撃者が以前に侵害した NetNod ネットワークへのアクセスの再確立を試みるためだと考えられます。
「本命の標的」と「二次的な標的」
Talos では、キャンペーンの標的となった 40 の組織を特定しています。被害者の組織は 2 つのグループに大別できます。1 つ目の被害者グループ(本命の標的)は、ほぼすべてが中東および北アフリカに位置しています。以下に、侵害された組織の例を示します。
- 外務省
- 軍組織
- 諜報機関
- 大手エネルギー企業
2 つ目の被害者グループ(二次的な標的)は、本命の標的に侵入するための足がかりとして利用されたと考えられます。2 つ目の被害者グループは世界中に点在しているものの、中東と北アフリカに集中しています。以下に、侵害された組織の例を示します。
- 通信企業
- インターネット サービス プロバイダー
- IT 企業
- レジストラ各社
- 1 つのレジストリ
注目すべき点は、Amnic の下で ccTLD を管理するレジストラ各社に攻撃者が不正アクセスできたことです。Amnic は、IANA のサイト に ccTLD 「.am」の技術パートナーとして記載されています。これらの ccTLD レジストラへ不正アクセスできたことで、関連 ccTLD を使用するどのドメインでもハイジャック可能になったと考えられます。
他のキャンペーンとの違い
Sea Turtle の攻撃は 2 年以上も続いています。彼らの攻撃が広く公開されているにもかかわらず攻撃を続けていることは、攻撃者の技術力の高さを裏付けています。Sea Turtle は、ドメイン ネーム レジストリが侵害された(知られている限りは)初めてのケースです。
以前に報告された他の攻撃(DNSpionage など)と比べて、Sea Turtle には以下のような特徴があります。
- 攻撃者は、自身が制御するネーム サーバを介して DNS ハイジャック攻撃を実行する。
- DNS レジストリと多数のレジストラ(ccTLD の管理組織も含む)を、よりアグレッシブに標的にしている。
- 最初のクレデンシャルを取得するために、MitM サーバで Let’s Encrypts、Comodo、Sectigo、そして自己署名証明書を使用する。
- ネットワークにアクセスできるようになると、組織の正当な SSL 証明書を盗み出し、自身が制御するサーバで使用する。
この攻撃が大きな成功を収めた理由
Sea Turtle は今後も大きな脅威であり続けると考えられますが、その理由にはいくつかあります。最初の理由は、Sea Turtle の攻撃者が独自のアプローチで標的ネットワークへアクセスしていることです。IDS や IPS システムといった従来のセキュリティ製品の大半は、DNS 要求を監視、記録するようには設計されていません。別の理由は、DNS のセキュリティが後になって追加されたことです。ccTLD にレジストラ ロックなどのセキュリティ機能が多く実装されていたら、攻撃者は標的ドメインをリダイレクトできなかったでしょう。
他にも攻撃者は、「証明書偽装(certificate impersonation)」と呼ばれる興味深い手口を使用しています。この手法が成功した理由のひとつは、SSL 証明書の目的が(整合性ではなく)機密性の確保にあることです。攻撃者は、セキュリティ アプライアンス(Cisco ASA など)で使用されている組織の SSL 証明書を盗み出すことで、VPN クレデンシャルの取得に成功しています。これは最終的に、標的ネットワークへのアクセスを許しています。
侵害されたネットワークの多くでは、攻撃者がクレデンシャルを不正入手して使用していたこともあり、攻撃者がいつでもアクセスできる状態が長く続いていました。
脅威について広く周知し、お客様を継続的に保護できるよう、Talos ではパートナーと協力して Sea Turtle の分析や監視を続けます。
リスク軽減策
Sea Turtle などの脅威から組織を守るため、いくつかの対策を取ることができます。まず、レジストリ ロック サービスの利用をお勧めします。これにより、組織の DNS レコードが変更される際は事前にアウトオブバンド メッセージで確認されます。お使いのレジストラがレジストリ ロック サービスを提供していない場合は、組織の DNS レコードへのアクセスで DUO などの多要素認証を実装することをお勧めします。自社の DNS レコードが狙われていると感じる場合は、ネットワーク全体のパスワード リセットを、できれば信頼できるネットワーク上のコンピュータから開始します。最後に、インターネットに接続するマシンを中心に、最新アップデートを適用しましょう。ネットワーク管理者は、ドメイン上のパッシブ DNS レコードを監視することで異常を検知できます。
カバレッジ
CVE-2009-1151:phpMyAdmin に影響を与える PHP コード インジェクションの脆弱性
SID:2281
CVE-2014-6271:GNU Bash システム(特に SMTP)に影響を与えるリモート コード実行の脆弱性(Shellshock CVE の一部)
SID:31975–31978、31985、32038、32039、32041–32043、32069、32335、32336
CVE-2017-3881:シスコ スイッチで確認されたリモート コード実行の脆弱性
SID:41909–41910
CVE-2017-6736:シスコのサービス統合型ルータ 2811 で発見されたリモート コード実行の脆弱性
SID:43424–43432
CVE-2017-12617:Tomcat を実行する Apache Web サーバで確認されたリモート コード実行の脆弱性
SID:44531
CVE-2018-0296:Cisco 適応型セキュリティ アプライアンス(ASA)およびファイアウォールへの不正アクセスを許可するディレクトリ トラバーサル
SID:46897
CVE-2018-7600:Drupal(別名「Drupalgeddon」)で構築された Web サイトにおけるリモート コード実行の脆弱性
SID:46316
侵害の兆候
攻撃者は、仮想プライベート サーバ(VPS)プロバイダーからリースされた IP アドレスを使用していました。VPS プロバイダーは、同様の IP アドレスを多くの無害な顧客に再販しています。ネットワーク防御に役立つように、攻撃で使用された IP アドレスの一覧と、それらの IP アドレスが使用されていた年月を以下に記載します。
IP アドレス | 月 | 年 | 標的となった国 |
199.247.3.191 | 11 月 | 2018 年 | アルバニア、イラク |
37.139.11.155 | 11 月 | 2018 年 | アルバニア、アラブ首長国連邦 |
185.15.247.140 | 1 月 | 2018 年 | アルバニア |
206.221.184.133 | 11 月 | 2018 年 | エジプト |
188.166.119.57 | 11 月 | 2018 年 | エジプト |
185.42.137.89 | 11 月 | 2018 年 | アルバニア |
82.196.8.43 | 10 月 | 2018 年 | イラク |
159.89.101.204 | 12 ~ 1 月 | 2018 ~ 2019 年 | トルコ、スウェーデン、シリア、アルメニア、米国 |
146.185.145.202 | 3月 | 2018 年 | アルメニア |
178.62.218.244 | 12 ~ 1 月 | 2018 ~ 2019 年 | アラブ首長国連邦、キプロス |
139.162.144.139 | 12 月 | 2018 年 | ヨルダン |
142.54.179.69 | 1 ~ 2 月 | 2017 年 | ヨルダン |
193.37.213.61 | 12 月 | 2018 年 | キプロス |
108.61.123.149 | 2 月 | 2019 年 | キプロス |
212.32.235.160 | 9 月 | 2018 年 | イラク |
198.211.120.186 | 9 月 | 2018 年 | イラク |
146.185.143.158 | 9 月 | 2018 年 | イラク |
146.185.133.141 | 10 月 | 2018 年 | リビア |
185.203.116.116 | 5月 | 2018 年 | アラブ首長国連邦 |
95.179.150.92 | 11 月 | 2018 年 | アラブ首長国連邦 |
174.138.0.113 | 9 月 | 2018 年 | アラブ首長国連邦 |
128.199.50.175 | 9 月 | 2018 年 | アラブ首長国連邦 |
139.59.134.216 | 7 ~ 12 月 | 2018 年 | 米国、レバノン |
45.77.137.65 | 3 ~ 4 月 | 2019 年 | シリア、スウェーデン |
142.54.164.189 | 3 ~ 4 月 | 2019 年 | シリア |
199.247.17.221 | 3 月 | 2019 年 | スウェーデン |
次のリストは、攻撃者のネーム サーバ ドメインとその IP アドレスの一覧です。
ドメイン | 使用されていた期間 | IP アドレス |
ns1[.]intersecdns[.]com | 2019 年 3 ~ 4 月 | 95.179.150.101 |
ns2[.]intersecdns[.]com | 2019 年 3 ~ 4 月 | 95.179.150.101 |
ns1[.]lcjcomputing[.]com | 2019 年 1 月 | 95.179.150.101 |
ns2[.]lcjcomputing[.]com | 2019 年 1 月 | 95.179.150.101 |
本稿は 2019年4月17日に Talos Group のブログに投稿された「DNS Hijacking Abuses Trust In Core Internet Service」の抄訳です。