HTTP Evasions原理解析:Deflate压缩绕过防火墙

原文地址:http://noxxi.de/research/http-evader-explained-2-deflate.html

本文是HTTP Evasions系列的第二篇文章,本文主要讲支持压缩功能的浏览器或者其他设备,将有可能导致防火墙的绕过,简单来说,就是通过发送一个经过压缩的响应包来绕过防火墙。

 

  1.  HTTP/1.1 200 ok
  2.  Content-Encoding: deflate
  3.  insert compressed malware here

HTTP中的压缩是什么样的

由于压缩/解压的方式比占用高带宽传输数据的方式更加容易实现,因此压缩的方式被广泛的运用于相应包的交付。在浏览器中,内容的压缩是通过http头中的Content-Encoding字段来标识,如下:

  1. HTTP/1.1 200 ok
  2. Content-Encoding: gzip
  3. Content-type: text/html
  4. ...HTML content compressed with gzip

这种压缩方式是浏览器通过请求包向服务端请求的格式,在请求包中的体现如下:

  1. GET / HTTP/1.0
  2. Accept-Encoding: gzip, deflate

实际上,当前的浏览器提供了压缩方法“gzip”和“deflate”,这在HTTP标准中有规定。Chrome浏览器也支持“sdch”的压缩方式,Opera甚至提供“lzma”的方式。这篇文章中,我们只讨论“gzip”和“deflate”的情况。

许多读者可能觉得’gzip’压缩有点眼熟,因为他们觉得类似用系统命令’gzip’命令来得到 *.tar.gz 文件。目前,Gizp被广泛的运用于编码wen内容,而且防火墙几乎全都支持这种方式的压缩。但是,另外一种方式编码“deflate”就不同了。

什么是Deflate加密方式?

Deflate与gzip非常像。甚至可以简单的说,gzip就是带有一些头部可和尾部的deflate。

当然,在Deflate中也有其他的封装:zlib,常常被用于PNG图片的压缩。zlib格式是浏览器常用的,让人疑惑的是,这种编码方式在浏览器中被命名为‘deflate’。这样的错乱通常容易产生误解,使得大多数浏览器会同时接受zlib和deflate压缩,因为他们的名字都是deflate。

总的来说,以下几种方式的压缩方式都会被相同的算法解压(DEFLATE):

  1. n gzip – 带有头部和尾部的deflate,RFC1952:所有浏览器
  2. n deflate – 带有zlib头部和尾部的deflate算法,RFC1950:除了IE外的所有浏览器
  3. n deflate – 不带头部和尾部的原始deflate,RFC1951:所有浏览器

如果防火墙无法识别Deflate算法,会发生什么?

最理智的做法当然是隔离这些内容,因为这些可能存在危险。但是,如果真这样做了,有很多正常的数据就会被防火墙拦截掉,这显然是我们不乐意见到的。对此,当防火墙无法识别压缩方式的时候,就会直接让包通过防火墙。这种看似是用户友好型的解决方案,但实际上是大大方便了攻击者。因此,只要简单的使用deflate方式压缩,就可以让恶意软件顺利通过一些防火墙和安全系统。

更糟糕的是,有些恶意软件可能不需要压缩。只要简单的把Content-Encoding的内容换成防火墙无法识别的压缩方式,防火墙就会停止扫描这个文件,甚至,防火墙也将不会解压这个文本:

  1.  HTTP/1.0 200 ok
  2.  Content-Encoding: foobar
  3.  ...plain uncompressed malware ...

为何那些防火墙可以侦测Gzip压缩中的恶意软件,却不能侦测Deflate的?

一个HTTP响应包是由响应头和响应体构成的。使用什么方式的压缩算法被记录在响应头里面,同时,响应体中的内容就是真正被压缩的内容。最典型的处理方法是,防火墙只把响应体的内容发送给杀毒软件进行分析。由于gzip中有一个很容易识别的头,杀毒软件可以成功的侦察出这个压缩方法并且分析被压缩的内容。

但是Deflate压缩方式中没有像这样的特有的标识头,这种压缩出来的文本看起来更像是随机的。因此,杀毒软件无法侦察到压缩的部分是用哪种方式压缩的。这个时候,需要在把这个压缩文本发送给杀毒软件前告知杀毒软件他的压缩方式。

为什么有些防火墙可以处理Deflate (RFC1951) 但是无法出来其他的Deflate (RFC1950) ?

我们可以猜测防火墙的作者并没有意识到有两种Deflate方式或者他们觉得只需要处理所有浏览器都支持的方式就行了。因为没有那个正常的web开发者会使用一些所有浏览器都无法解压的压缩方式。可惜的是,攻击者并不会这么做,甚至攻击者更乐于使用这样的方式。

我们可以事先让服务器不使用Deflate算法压缩?

这也是一些产品的做法。他们从浏览器的请求头中的Accept-Encoding字段知道浏览器可以解压那些压缩方式的文件,而这个字段告诉服务器要用Accept-Encoding字段所说的压缩方式对内容进行压缩。但是这样的想法也是有问题的,因为,攻击者还是可以用自己可控的服务器来进行那些操作。就像这个连接中所展示的那样

    http://noxxi.de/research/content-encoding-online-scanner.html

所以,防火墙不应该只把希望寄托在服务器上,不能太信任服务器,而是要检查压缩算法是否被使用。但是,所有的防火墙都只是看起来好像是假定了攻击者也要遵守这样的规则,而没有检测压缩是否真的被使用了。实际当中,ZScaler URL checker 和Comodo Web Inspector都犯了同样的错误,他们仅仅请求包中有无压缩请求,而根据盲目的相信服务器不会交付压缩的数据,详情请看。

可以认为使用Deflate的就是黑客行为吗?

根据Alexa 统计的10000台服务器中,gzip是使用最多的压缩方式。但是仍然有许多服务器使用的是Deflate来压缩数据。所以不能简单的认为一个服务器使用Deflate压缩就算攻击行为了。

最后

很明显,你不能过于相信供应商,所以最好自己检测下这些说自己是具有先进的威胁保护系统的供应商是否是吹牛逼。如果你想,可以下载HTTP Evader工具测试下。

    http://noxxi.de/research/http-evader.html