DNSトンネリング技術とその応用: 近年増えつつある4つの技術応用分野

はじめに

郵便の「宛先住所」と「郵便番号」の関係は、よくインターネット上の「FQDN (完全修飾ドメイン名)」と「IPアドレス」の関係にたとえられます。郵便で一意な「宛先住所」を書けばそこから「郵便番号」を調べることができるように、インターネットも一意な「FQDN」を指定すればDNSサービスを経由して「IPアドレス」を調べられます。そして郵便と同じく、このしくみはインターネットで情報をやりとりする上で接続先と接続元の一意な特定に欠かせない基盤となっています。このため、DNSサービスを提供する53/udpや53/tcp宛の通信は従来のファイアウォールであればたいてい通過が許可されています。DNSトンネリングはこのしくみを悪用する攻撃です。

DNSトンネリング技術とは

DNSトンネリング技術は、セキュリティ対策が手薄になりがちなこのDNSサービスを逆手に取り、密かに交換したい情報のやりとりにDNSプロトコルを使う技術です。さきほどの郵便の例でいうなら、「宛先住所」や「差出人住所」にやりとりしたい情報を含めてしまうのです。たとえば、封書の宛先住所に「東京都千代田区 1-1-1 victiminfo win-pc01 user01 password123!  様」として封書を送り、返信する封書の宛先住所に「東京都千代田区1-1-2 exec systeminfo /s win-pc01 /u user01 /p password123!  様」のような形で (実際にはここに難読化や暗号化を施した形で) 情報を含めて何通も繰り返し封書を送り合うようなものです。

図1に具体例を示します。ここでは、攻撃者が侵害したホストを接続元とし、攻撃者が管理しているドメイン (badsite[.]com) 上で DNS サービスを提供しているドメイン ネームサーバー宛に $secret.badsite[.]com というFQDNを解決するDNSクエリーを組織のリゾルバーを経由して送信させています。リゾルバーはルート ネームサーバー、TLDネームサーバー、攻撃者配下のドメインネームサーバーの順に再帰的に問い合せを行い、最終的に攻撃者が管理するドメイン ネームサーバーのCNAMEレコードから「 secret.badsite[.]com は $payload.badsite[.]com の別名なのでその名前で問い合わせください」というDNS応答を受け取っています。これにより、C2 サーバーは $secret のデータを、感染ホスト側は $payload のデータを受け取れることになります(なお、この図の $secret 、 $payload は変数名で、これらの変数のなかに、実際の暗号化/難読化されたデータが入っていると考えてください)。

つまり、接続元環境でDNSクエリーの送出がセキュリティ対策に妨害されていなければ、DNSクエリーと応答のやりとりだけで、攻撃者は機微情報( $secret )を持ち出したり、ペイロード( $payload )を持ち込んだりできることになります。

最近確認されている技術応用

先にあげたのはDNSトンネリングをC2(コマンド&コントロール)に応用した例ですが、セキュリティ対策が手薄になりがちなDNSサービスは、C2を含むさまざまな攻撃技術に応用されています。ここでは主な4つの技術を紹介します。

C2 (コマンド&コントロール)

DNSトンネリング技術の応用の代表例といえるのが先にもあげたコマンド&コントロールです。

フィッシングメールなどの手段で被害者環境のホストを侵害後、そのホストから被害者のシステム情報やユーザーのクレデンシャルを持ち出したり、攻撃者の配下にあるサーバーから追加のコマンドを送り込んだりする用途にDNSトンネリング技術が用いられるケースです。最終的に窃取したデータの漏出にもDNSトンネリングが使われることがあり、持ち出されるデータの量によっては、非常に多数のDNSクエリーが組織内のホストから出されることになります。

VPN (仮想プライベートネットワーク)

C2と並んでよくDNSトンネリング技術が利用されるのがVPN(Virtual Private Network: 仮想プライベートネットワーク) です。

たとえば自身が所属する組織のファイアウォールに妨害されず、組織では検閲やブロックの対象となっているコンテンツを閲覧したい従業員が、DNSトンネリング技術を使ってVPNを実装している外部サービスを利用する、といったケースがその代表的な例です。このほか過去にUnit 42が調査した例では、運輸サービスが有料で提供しているインターネット接続サービスにタダ乗りするためにDNSトンネリング技術でVPNを実装しているVPNサービスを利用していた例が確認されています。

VPNの場合、たとえ外部からの初期侵害がなくとも、内部関係者が故意あるいは無自覚にDNSトンネリングで実装したVPNサービスを使うことがあります。このことを防御側は理解しておかねばなりません。

追跡

スパム、フィッシング、広告コンテンツに関連する被害者の行動追跡に従来のようなWeb用URLではなくDNSトンネリング技術を使うケースです。何らかの方法で被害者のホストを侵害した後、その被害者が感染ホスト上で取ったアクションを、そのユーザーを一意に特定する情報とともにサブドメイン部にエンコードして攻撃者が管理しているドメイン ネームサーバーにDNSクエリーとして送信します。攻撃者が管理しているサーバーは送信されたDNSクエリー情報を保存し、それを被害者の行動追跡ログとして利用します。

スキャン

侵害した組織のネットワークインフラを偵察し、たとえば脆弱性を探す手段としてDNSトンネリングを使うケースです。この用途でDNSトンネリングが使われるケースにはあまり先行研究例がないのですが、Unit 42が発見したある事例では組織内のオープンリゾルバーを探す、リゾルバーの応答タイムを検証する、リゾルバーの脆弱性を悪用する、TTL情報を取得するなどの用途にDNSトンネリング技術が使われていました。被害組織にオープンリゾルバーが見つかると、その後リフレクション攻撃に悪用されるようすが観察されています。

おわりに

今回とりあげた技術応用は4つですが、DNSプロトコルが手薄とみなされ続ける限り今後も応用範囲は広がっていくと想定すべきでしょう。

組織内でDNSトンネリングが発生すると、平時と比べて単一ホストから出されるDNSクエリー数が異常に増えたり、DNSのキャッシュヒット率が極端に下がったり、といったアノマリーが観察されます。これは、被害組織内のキャッシュサーバーに保存されているDNS情報にヒットしてしまうと、攻撃者配下のサーバーまでDNSクエリーが届かず欲しいデータを受け取れないので、クエリーごとに一意なFQDNを使ってキャッシュにヒットしないように攻撃者側がさまざまに工夫をこらしているためです。

インターネットサービスの根幹となるDNSにポート番号のレベルでフィルタリング設定することは難しいので、組織側はこうしたDNSトンネリング特有の振る舞いが見られないかどうかを監視しておく必要があります。それには、こうした振る舞いを行うドメインをリアルタイムに分析し、そのトンネリングに紐づいた有害なツールや攻撃キャンペーンを検出したり、アトリビューションを行ったりできるシステムを構築しておく対策が有効です。