IIS-Backdoor

在本文中，我将解释如何为微软 Internet 信息服务（IIS）设计一个 rootkit。问题是：为什么要在 Web 服务器中植入后门？

首先，一个显而易见但无用的答案：因为我们可以。

好吧，让我们给出一个更聪明的答案。在 Web 服务器中植入后门的目的有两个：

它允许攻击者访问客户端发送的数据。例如，如果网站受密码保护，我们可以获取此密码。
它允许动态地对服务器发送给 Web 客户端的任何内容进行后门操作。

第二点尤其有趣，因为它允许攻击者根据请求网页的 Web 浏览器注入适当的漏洞，或者感染从服务器下载的可执行文件。 IIS 后门

什么是 IIS

IIS 是微软的 Web 服务器，它是微软基于 Web 的技术（如 OWA）的重要组成部分。从第一个版本（Windows NT 3.51 下的 IIS 1.0）到最新版本（Windows Server 2008 下的 IIS 7.5），已经发布了多个版本。它广泛部署于互联网和公司内部网。 IIS 扩展

微软定义了一个名为 ISAPI（Internet 服务器应用程序编程接口）的 API，以帮助开发人员为 IIS 添加功能。可以添加到 IIS 的组件有两种类型：扩展或筛选器。 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 筛选器链表中。为此，我将我的 DLL 注入到 IIS 进程中，该 DLL 解析 IIS 进程堆并手动将自身注册到 IIS 筛选器列表中。

内存中维护 IIS 筛选器列表使用了两种结构类型。第一种如下：

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：一个幻数 DWORD，值为 "FLIS"。
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：一个幻数 DWORD，值为 "FDLL"。
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 服务器中植入后门并不那么困难，并且可以为您提供很多机会...

IIS-Backdoor

最受欢迎

IIS-Backdoor

什么是 IIS