ISAPI后门与代理研究

版权归T00ls与本人共同所有，转载请联系T00ls管理员

0x01 ISAPI介绍

ISAPI（Internet Server Application Programming Interface）作为一种可用来替代CGI的方法，是由微软和Process软件公司联合提出的Web服务器上的API标准。ISAPI程序和CGI程序完成类似的功能，但是实现方法不同。
关于ISAPI更为详尽的介绍请参考这里：http://www.chinaitpower.com/A/2002-07-23/29847.html
简单来讲，ISAPI是以dll文件的形式被IIS加载运行。主要分为两种：ISAPI Extension和ISAPI Filter。
Extension是对IIS功能上的扩展，常见的使用方法一是直接将dll文件放在web可执行目录中供客户访问，比如这样：http://www.twi1ight.org/example.dll;二是注册一个后缀交给指定的ISAPI Extension dll去解析，比如ASP就是这样的。具体asp的实现细节微软并未公开，不过这篇文章有一个基于猜想的大概的描述，我觉得应该八九不离十：http://blog.csdn.net/misterliwei/article/details/1375124
Filter可以设定触发规则，然后检查每一个request请求是否需要进行处理。Filter可以完成以下功能：更改request中的数据（URL或headers)，基础认证，修改response数据，当request请求完成或者client断开时进行相关操作，进行特定的日志或流量分析，自定义加密或压缩请求等等。所以说Filter的功能相当强大，一方面，Filter可以分析request数据，故而可以用来进行客户端数据的分析和过滤，防止SQL注入和其他相关的web攻击，可以用来做WAF；另一方面可以修改response数据，也就意味着可以达到劫持的目的，对于任何访问该服务器的请求都可以转发到另一个URL地址，或者也可以用来挂黑链等等。

0x02 Lion及云舒的端口复用后门分析
　　
      既然ISAPI有如此强大的功能，自然想到要利用其做后门，隐蔽性比之webshell要好的多，同时后门数据可以混在正常的web请求中，可以很容易躲过防火墙，也很难被检测到。
　　有这个想法的人不止我一个，我百度之后找到了lion和云舒两位前辈大牛的作品，而且刚好一个是基于ISAPI Extension，一个是基于ISAPI Filter。
　　先来看lion的，他的代码是基于ISAPI Filter的。触发后门条件是QueryString包含shell=xxxx，如果是shell=rebindshell，则开启一个复用80端口后门等待连接，如果是stopbind，则关闭后门，如果是其他字符串，则当做cmd命令直接执行。
由于是用Filter形式实现，所有request请求都会通过Filter检查。所以只要访问web服务器上的任意页面（不存在的也行）并加上QueryString形如?shell=rebindshell就可以开启后门，然后再用nc连接输入密码givemeshell!就可以获取一个cmd shell了，这个可是实实在在的80端口复用后门。



再看云舒的后门，他的代码是基于ISAPI Extension。鉴于Extension的功能，所以需要直接访问dll文件或者注册一个后缀交给dll解析。这里采用注册后缀的方法来测试，首先添加一个后缀t00ls，注意取消勾选检查文件是否存在，这样当访问并不存在的文件时也会加载dll执行。
这个后门是采用请求方法作为密码的，当用Icy方法请求后缀为t00ls的文件时就会触发后门执行，获得一个80端口复用的shell。



两个后门都是真正意义上端口复用的，但是在实现的原理上却是相差很多。
Lion的代码中采用的方式是socket的重绑定，利用setsockopt函数设置SO_REUSEADDR，正常应用程序使用127.0.0.1，而另外一个IP地址则被后门程序占用，后门程序对收到的数据进行判断，若不是自己的数据包则转发给正常应用程序，从而达到端口复用的目的。关于端口重用这部分的代码和原理可以往前追溯到flashsky在2002年发表在安全焦点的一篇文章《端口截听实现端口隐藏，嗅探与攻击》，文章地址：http://www.xfocus.net/articles/200211/458.html
  Lion后门的通讯模型可以参考下图：



当ISAPI接受到？Shell=rebindshell请求时，会创建一个绑定80端口的socket，当有客户端连接输入密码时则会创建一个cmd进程，这个socket和cmd.exe进程以管道通信，此时正常的数据请求也通过这个socket，Filter后门程序会判断数据是正常IIS数据还是后门数据，如果是正常数据则将其转交给IIS。

云舒的代码实现起来却没那么复杂，将IIS作为一个数据中转站，通过API函数ReadClient读取客户端发送的数据，然后将数据通过管道交给cmd进程处理，cmd执行结果通过管道传递给IIS，再调用API函数WriteClient将结果返回给客户端。整个过程在一个Request请求周期中完成。
云舒的通讯模型是把IIS作为服务端CMD进程和客户端的中转站。
具体可以参考下图：


0x03 伪端口复用IIS反连后门

Lion和云舒的后门出现时间很早，这两个后门也都是用于IIS5的，对于IIS6已经完全没有用了，Lion的后门在重绑定端口时出错。
IIS5和IIS6在本质上有极大的不同，IIS6是完全重新设计后的产品，新增了核心驱动程序http.sys，http.sys会检查所有的web请求，确定请求是否有效，是否符合HTTP请求格式，如果不符合则返回一个无效的请求代码（400错误），这意味着客户端发送给IIS的数据每个数据包都必须符合HTTP请求格式，否则在驱动层就被丢弃，根本到达不了应用层的ISAPI程序，所以云舒后门的交互式shell根本不能使用了，当命令发送过去在IIS6中会显示400错误（Bad Request)。
这样一来正向的端口复用后门基本上是没希望，所以我根据Lion的后门把代码稍作改变，变成了一个反向连接的后门，当向IIS发送特定的数据包时，服务器会反弹一个shell到指定的IP地址。



当发送的数据包header中包含X-DATA时，Filter后门会对其值做出处理，如果是backshell:ip:port这种格式则会反弹一个shell过去，如果不是这种格式则当做命令执行，当做是C语言中的system函数的参数。
　　这个后门比webshell的隐藏性好一点，但是需要服务器能够访问外网。如果不能访问外网，也可以利用执行命令的功能echo一个webshell到web目录。

0x04 ISAPI终极用法——内网代理

在极端网络情况中，由于防火墙与各种安全设备的限制，我们一般只有一个webshell，无法反弹cmdshell，也无法反弹代理，就不方便进一步对内网进行渗透。现在唯一已知的解决办法是reDuh，但是速度相当慢。

　　根据我的研究，ISAPI可以作为一种代替reDuh的解决方案，不过现阶段我并没有完全写完这个程序，只有一个demo，这个demo可以通过IIS服务器的访问其内网中其他服务器的telnet。
　　本地(192.168.1.222)-----> IIS服务器(192.168.1.117)-----> Telnet服务器(192.168.1.113)
　　

这个程序由两个部分构成：python客户端，ISAPI Extension程序服务器。
Python客户端在本地监听一个端口12345，然后telnet本地的12345端口，python脚本会把本地telnet程序发出的socket数据包封装成HTTP的POST请求提交到ISAPI Extension程序，ISAPI会建立一个到目标服务器的socket连接，然后提取python提交的POST数据包中的数据转发给目标服务器。从目标服务器socket返回的数据ISAPI会通过WriteClient函数发送回python客户端，python客户端再将该数据转发给本地的telnet客户端。Python客户端作为本地软件的封装和解包代理程序，然后ISAPI作为路由一样的转发设备，这样就能轻轻松松进入内网了。

　　我的demo程序暂时只能完成telnet通讯，RDP协议还在测试中。事实上我觉得应该可以把ISAPI设计封装成一个Socks5代理，那样就可以在内网中横行了，纯设想，暂未实现，不知可行性如何。

ISAPI Filter反弹shell后门源码：
编译环境：2003 server + vc6.0  适用于IIS6以上
欢迎修改源码，但是希望修改后能发我一份，最后那个demo还没写完，就不提供源码了