可能使剖析的输出出现偏差的一个问题是放置在Web应用之前的中间基础架构。这种基础架构可能包括负载平衡器、虚拟服务器配置、代理和Web应用防火墙。接下来,我们将讨论这些干扰因素对我们刚才讨论的基本指纹识别技术的阻碍,以及发现它们的方法。
虚拟服务器
需要考虑的一个问题是虚拟服务器。一些Web主机公司试图在相同机器上的多个虚拟IP地址之上运行不同的Web服务器,以节约硬件成本。要知道,端口扫描所指出的不同IP地址上的大量活跃服务器,实际上可能是具有多个虚拟IP地址的单台机器。
检测负载平衡器
因为负载平衡器一般“不可见”,许多攻击者进行评估的时候忽略了它们。但是负载平衡器可能极大地改变评估的方式。负载平衡器部署用来帮助确保单个服务器的请求不会超载。负载平衡器通过在多个服务器中分割Web流量来做到这一点。例如,当你向一个网站发出请求,负载平衡器可能将你的请求交给4个服务器中的任何一个。这种配置意味着虽然一次攻击可能在一个服务器上有效,但是如果下一次发送给另一个服务器就可能无效,这会让你觉得沮丧和困惑。尽管从理论上,所有服务器应该是完全相同的复制品,而且任何服务器的响应都应该和其他服务器相同,但是现实中并非如此。即使所有服务器上的应用都相同,文件夹结构(这种不同非常常见)、补丁级别和配置在每个服务器上都可能不同。例如,某个服务器上可能留有“测试”文件夹,而其他服务器则没有。这就是不要忽略负载平衡器的识别,以免扰乱你的评估结果的重要性。下面是检测目标网站上是否有负载平衡器运行的方法。
对邻近IP范围进行端口扫描: 识别负载平衡服务器的一种简单方法是,首先确定公认服务器IP地址,然后编写脚本对周围的IP范围发出请求。我们已经发现这种技术得到多个几乎相同的响应,这可能都是负载平衡的相同Web服务器。但是,我们偶尔也会碰到一个或者几个服务器和其他有所不同,在运行过时的软件版本或者替代的服务如SSH或者FTP。这些异类通常很可能有某种错误的安全配置,可以通过它们的IP地址单独发起攻击。
时间戳分析: 检测负载平衡器的一个方法是分析响应时间戳。因为许多服务器没有同步时间,你可以通过在一秒之内发出多个请求来确定是否有多台服务器。这么做,你可以分析服务器日期首部。如果你的请求被分发到多台服务器,那么首部中回报的时间可能有些不同。你需要多次分析以消除“假阳性”,发现真实的情况。如果幸运,每个服务器都不同步,你就能计算出实际有多少台服务器。
ETag和Last-Modified的差异: 通过比较相同请求资源的首部响应中的ETag和Last-Modified值,你能够确定是否会从多个服务器上得到不同的文件。例如,下面是多次请求index.html得到的响应:
ETag: "20095-2de2-3fdf365353cc0" ETag: "6ac117-2c5e-3eb9ddfaa3a40" Last-Modified: Sun, 19 Dec 2004 20:30:25 GMT Last-Modified: Sun, 19 Dec 2004 20:31:12 GMT
这些响应中Last-Modified时间戳的差异表明服务器没有立即复制,请求的资源在大约1分钟之后才复制到其他服务器。
负载平衡器Cookie: 有些代理服务器和负载平衡器在HTTP会话中添加自己的cookie,这样它们可以保持更好的状态。这些cookie很容易找到,所以如果你看到不寻常的cookie,就应在Google上做个相关的搜索,以确定其来源。例如,浏览一个网站时,我们注意到这个cookie被传递给服务器:
AA002=1131030950-536877024/1132240551
因为这个cookie没有明确给出属于哪个应用的指示,我们用AA002=作了一个快速的Google搜索,得到了使用这个cookie的网站的多个搜索结果。经过进一步分析,我们发现这个cookie是一个跟踪cookie,名为“Avenue A”,一般来说,如果你不知道,就找Google!
枚举SSL异常: 对于识别代理和负载平衡器来说,这是最后的办法。如果你确定应用实际上是负载平衡的,但是前面的方法都无效,那么可以尝试看看网站的SSL证书是否存在差异,或者SSL证书是否都支持相同的密码长度。例如,一个服务器可能按照常规,只支持128位加密。但是如果网站管理员忘记将这一策略应用到其他服务器,那么这些服务器支持96位以上的所有加密。这样的错误就可以确定网站有负载平衡。
检查HTML源代码: 尽管我们会在本章稍后的2.2节“应用剖析”中更深入地讨论,但是需要注意的一点是,HTML源代码也能够透露负载平衡器的情况。例如,相同页面的多次请求可能返回不同的HTML源代码注释,如(HTML注释用<!--指出):
<!-- ServerInfo: MPSPPIIS1B093 2001.10.3.13.34.30 Live1 --> <!-- Version: 2.1 Build 84 --> <!-- ServerInfo: MPSPPIIS1A096 2001.10.3.13.34.30 Live1 --> <!-- Version: 2.1 Build 84 -->
网站上的一个页面显示了更隐秘的HTML注释。采样5次后,对这些注释进行比较,如:
<!-- whfhUAXNByd7ATE56+Fy6BE9I3B0GKXUuZuW --> <!-- whfh6FHHX2v8MyhPvMcIjUKE69m6OQB2Ftaa --> <!-- whfhKMcA7HcYHmkmhrUbxWNXLgGblfF3zFnl --> <!-- whfhuJEVisaFEIHtcMPwEdn4kRiLz6/QHGqz --> <!-- whfhzsBySWYIwg97KBeJyqEs+K3N8zIM96bE -->
这些注释内容看起来是MD 5 hash加上开始的whfh。但是还不能确定。我们将在应用剖析的部分里讨论更多关于如何收集和识别HTML注释的内容。
检测代理
毫不意外,你会发现某些最有趣的目标是不可见的。代理这样的设备对于最终用户应该是透明的,但是如果你发现了它们,它们就是很好的攻击点。接下来列出可以用于确定目标网站是否通过代理运行请求的方法。
TRACE请求: TRACE请求通知Web服务器回复刚刚收到的请求内容。这个命令在HTTP 1.1中作为调试工具。但是,幸运的是,它也能揭示我们的请求在到达Web服务器之前是否经过代理服务器。通过发出一个TRACE请求,代理服务器将修改请求并且将其发送给Web服务器,代理服务器接着传回所接收到的请求。这样,我们可以发现代理对请求的修改。
代理服务器通常添加某些首部,看起来像下面这样:
"Via:","X-Forwarded-For:","Proxy-Connection:" TRACE / HTTP/1.1 Host: www.site.com HTTP/1.1 200 OK Server: Microsoft-IIS/5.1 Date: Tue, 16 Aug 2005 14:27:44 GMT Content-length: 49 TRACE / HTTP/1.1 Host: www.site.com Via: 1.1 192.168.1.5
当你的请求穿过一个反向代理服务器时,会得到不同的结果。反向代理是一个前端代理,将来自互联网的入站请求路由到后端服务器。反向代理通常有两种方式修改请求。第一种,它们将重新映射URL指向内部服务器上的相应URL。例如,TRACE/folder1/index.aspx HTTP/1.1可能改为TRACE/site1/folder1/index.asp HTTP/1.1。第二种,反向代理将修改Host:首部指向相关的内部服务器来转发请求。看看下面的例子,你会发现Host:首部被改为server1.site.com。
HTTP/1.1 200 OK Server: Microsoft-IIS/5.1 Date: Tue, 16 Aug 2005 14:27:44 GMT Content-length: 49 TRACE / HTTP/1.1 Host: server1.site.com
标准连接测试: CONNECT命令主要用于代理服务器代理SSL连接。用这个命令,代理代表客户端建立一个SSL连接。例如,发送一个CONNECT https://secure.site.com:443命令,将通知代理服务器建立一个指向secure.site.com 443端口的SSL连接。如果连接成功,CONNECT命令,将建立用户连接与安全连接的隧道。但是,这个命令可能被滥用,用于连接网络内部的服务器。
检查是否有代理的一个简单方法是发送一个CONNECT到已知的网站如:www.google.com,看看它是否符合要求。
注意 许多时候防火墙可能能够防御这种技术,所以你可能要尝试猜测内部IP地址,用来进行测试。
下面的例子展示了CONNECT方法如何用于连接到一个远程Web服务器:
*Request* CONNECT remote-webserver:80 HTTP/1.0 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 4.0) Host: remote-webserver *Successful Response* HTTP/1.0 200 Connection established
标准代理请求: 你可以尝试的另一个方法是插入公共网站的地址,查看代理服务器是否返回来自该网站的响应。如果返回,就意味着你可以将这个服务器导向任何你选择的地址,使你的代理服务器成为一个向公众开放的匿名代理,更糟糕的是,允许攻击者访问你的内部网络。这在下面会加以说明。现在,可用的一种较好的技术是识别目标的内部IP地址范围,然后对这一范围进行端口扫描。
提示 这种方法也同样适用于CONNETCT命令。
例如,使用这种机制的开放代理测试如下:
GET http://www.site.com/ HTTP/1.0
你可以使用这种技术扫描开放Web服务器的网络:
GET http://192.168.1.1:80/ HTTP/1.0 GET http://192.168.1.2:80/ HTTP/1.0
甚至可以这样进行端口扫描:
GET http://192.168.1.1:80/ HTTP/1.0 GET http://192.168.1.1:25/ HTTP/1.0 GET http://192.168.1.1:443/ HTTP/1.0
检测Web应用防火墙
Web应用防火墙是放在用户和Web服务器之间的保护性设备。应用防火墙通过分析HTTP流量来确定是否是有效的流量,试图避免Web攻击。你可以把它们看做Web应用的入侵防御系统(IPS)。
Web应用防火墙在评估应用时相对较少考虑,但是能够监测它们还是很重要的。下面示例并没有给出识别Web应用防火墙所有方法,但是足够帮你识别这种防御设施。
检测应用之前是否运行应用防火墙实际上相当简单。如果在测试中你总是被踢出来,或者在发送攻击请求时超时,那么很可能在你和应用之间有一个应用防火墙。另一个迹象是Web服务器对于不寻常的请求的响应和一般的情况不同,而代之于始终返回相同类型的错误。下面列出的是一些常见的Web应用防火墙和一些非常简单的检测方法。
Teros: Teros Web应用防火墙技术将对简单的TRACE请求或者任何无效的HTTP方法(如PUT)响应如下错误:
TRACE / HTTP/1.0 Host: www.site.com User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) HTTP/1.0 500 Content-Type: text/html <html><head><title>Error</title></head><body> <h2>ERROR: 500</h2> Invalid method code<br> </body></html>
检测Teros box的另一种简单方法是定位它发出的cookie,看上去类似这样:
st8id=1e1bcc1010b6de32734c584317443b31.00.d5134d14e9730581664bf5cb1b610784)
当然,这种cookie的值会变化,但是cookie名st8id露出了马脚,在大部分情况下,cookie的值将具有类似的字符集和长度。
F5 TrafficShield: 当你发送异常的请求到F5的TrafficShield,可能会得到包含以下错误的响应。例如,我们发送一个没有数据的PUT方法:
PUT / HTTP/1.0 Host: www.site.com User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) HTTP/1.0 400 Bad Request Content-Type: text/html <html><head><title>Error</title></head> <body><h1>HTTP Error 400</h1> <h2>400 Bad Request</h2> The server could not understand your request.<br>Your error ID is: 5fa97729</body></html>
TrafficShield也有一个专用的标准cookie。这个cookie名称是ASINFO,下面是一个例子:
ASINFO=1a92a506189f3c75c3acf0e7face6c6a04458961401c4a9edbf52606a4c47b1c 3253c468fc0dc8501000ttrj40ebDtxt6dEpCBOpiVzrSQ0000
Netcontinuum: 检测Netcontinuum应用防火墙部署与其他产品类似,只需要查找它的cookie。如果cookie不存在,我们注意到这些设备对所有无效的请求都响应一个404错误——这对于任何Web服务器来说都很不正常。Netcontinuum的cookie如下:
NCI__SessionId=009C5f5AQEwIPUC3/TFm5vMcLX5fjVfachUDSNaSFrmDKZ/ LiQEuwC+xLGZ1FAMA+
URLScan: 这是一个免费的ISAPI过滤器,为控制HTTP请求提供了很多灵活工具,但是我们不将其看作一个真正的应用防火墙。这类产品不提供动态保护,而是依赖冗长的特征码配置文件或者允许长度配置文件来阻止攻击。只要URLScan是以默认的规则来实施,检测就可能很简单。
例如,默认情况下,URLScan有一条限制路径为260个字符的规则,所以如果你发送一个超过260个字符的路径,URLScan将响应一个404错误。如果你添加以下的任何一个首部,URLScan将拒绝该请求:
·Translate:
·If:
·Lock-Token:
·Transfer-Encoding:
使用这些首部将导致URLScan返回404错误。但是,在任何其他情况下,Web服务器只会忽略额外的首部并且正常响应你发送的请求。
SecureIIS: SecureIIS类似于URLScan的增强版本——它是添加了漂亮的GUI和一些极好特性的扩充商业版本。使用它比编辑URLScan那种大配置文件要容易得多,但是检测的方法则很相似。研究其默认的规则,并且破坏它们——这将导致SecureIIS返回一个拒绝响应,默认情况下是406错误码(注意,商业版本允许修改这个错误码)。
默认规则中有一条是限制任何首部值长度都为1024字符。所以只要设置超过这一限制的首部值,查看请求是否被拒绝就可以了。SecureIIS默认的拒绝页面相当明显:它指出安全违规发生,甚至给出SecureIIS的图标和横幅。当然,大部分使用这个产品的人会修改这个页面。观察HTTP响应可能更真实,因为SecureIIS对超长首部的请求实施不寻常的406“不可接受”响应。