ボットネットの観測方法をさらに詳しく分析する(1) - Obfuscationの実際

前回に引き続き、今回もKrakenボットネットについてDVLabsが行った調査(http://dvlabs.tippingpoint.com/blog/2008/04/28/owning-kraken-zombies)を紹介する。ただし、今回は観測によって得られたデータではなく、どのような事前調査を行うことでボットネットの観測を可能にしたのか、といった技術的な分析手法に主眼を置くことに注意されたい。

バイナリのObfuscation(難読化)

DVLabsによると、まずKrakenの検体をOffensive Computingから入手し、分析を行ったのだという。その結果、KrakenはUDP 447番ポートを使用した暗号化プロトコルを通じて指令(C&C)サーバと通信を行うことが判明した。通信先のC&Cサーバは、ダイナミックDNSプロバイダ(DDNS事業者)によるサービスが使用され、サブドメイン名にランダムな名称が付けられていた。ちなみにDDNS事業者のサービスがこうしたボットネットの基盤として使用されている例は枚挙に暇がない。このサブドメイン名は、あるアルゴリズムによって生成される。生成されたサブドメイン名に、DDNS事業者の提供するドメイン名が付け加えられ、通信先C&Cサーバ候補としてリストに追加される。

なぜ、このようなアルゴリズムをわざわざ使用してC&Cサーバのドメイン名をボットプログラムのなかで生成しているかというと、それはアルゴリズムによる処理が行われない限り、通信先を割り出すことができないからだ。もっと具体的に言い換えよう。図2は、筆者がある別のマルウェア検体を分析した際に特定した通信先のURLである。ちなみに参照するファイルの拡張子はtxtだが、実行可能バイナリがダウンロードされる。

このように、マルウェアのプログラムコード分析がうまくいけば、たいていはその通信先を特定することができる。もっと端的な言い方をすれば「マルウェア検体に通信先のFQDNやIPアドレスの文字列が(たいていは)埋まっている」のだ。他方で、Krakenはそうではなく、SEEDと呼ばれる文字列をあるアルゴリズムを使用して加工し、サブドメイン名として生成している。よって、dyndns.orgやyi.orgといったDDNS事業者の使用するドメインの文字列はKraken検体の中に埋まっているが、それが「本当の通信先か?」といえば、そうではないのである。これが、いわゆる「Obfuscation(難読化)」の具体例である。プログラムコードを分析したところで、その通信先をすぐに割り出すことができないよう、さらに分析者に手間をかけさせる仕組みが組み込まれているのだ。

5年ほど前であれば、ネットワーク経由で大規模な感染を行うマルウェアの検体を入手し、そのプログラムコード分析を行えば、その検体がどのような感染動作を引き起こすモノなのかを割り出すことは容易であった。しかし、現在はこのような難読化が施されていることが新規に発生するマルウェア検体の大半を占めており「その検体がどんな動作を行うモノか?」を特定することが、単純にプログラムコード分析を行うことのみでは困難になっている。Krakenはこのことを如実に語っていると思われる。尚、TippingPoint DVLabsの当該ブログではKrakenの使用するC&Cのリストが1万5千ドメイン分公開されている。

Krakenの使用する暗号化プロトコル

次に、DVLabsが明らかにしたことはKrakenが命令の送受信に使用している通信チャネルの暗号化プロトコルである。図3のように、socketを使用した通信に際しては、暗号化ヘッダの使用が認められる。

図3のように、何らかの暗号化のための鍵を取得し、そしてヘッダを構成たうえで、そのヘッダ自身を送信前に暗号化するのである(図中の呼び出し関数名称は便宜上、DVLabsが付与したものである点に注意)。他方で、Krakenによって行われる通信の詳細が様々なブログで紹介されている。そして、その通信の最初の8バイトが固定値であると指摘している。DVLabsは、その理由はKrakenの暗号化プロトコルで使用されている鍵がこの8バイトの値であることを明らかにしたのだ。