返回列表 发帖

FireWall因协议设计而存在的缺陷(下)

对于SecuRemote连接FIREWALL-1的简单通道协议证明在bootstrapping insertion attacks against stateful inspection非常有用,这个协议(FWZ tunnelling via IP protocol 94)pre-inspection最开始时解封装,在任何实际分析之前执行,被解封装的信息包然后在通过inspection进程来提交。为了使用这个封装协议就没有必须去认证或者加密信息包。此外,我们发现没有方法来关闭这项功能。   一个普通的FWZ封装IP是按照这样的方式的:原始源地址IP地址和协议作为一个尾部trailer追加到信息包得到最后,并通过目标地址(防火墙的其中一接口)和IP协议94来代替原始头。这个TRAILER的长度是5个字节数,在IP ID上通过使用KEYD HASH并XOR使其杂乱。虽然我们不能恢复用在HASH中的KEY,但我们的工具通过修改IP ID和XOR来欺骗一个静态HASH。   在这种方式下,FWZ封装可以用来通过防火墙发送目的信息包到本来不可路由的地方,如一些DMZ或者INTRANET到INTERNET的信息包,或者那些被指定为多播地址,或者信息包地址在NAT后面的或者是RFC1918所定义的一些非公开网络地址。 [如图: -------------------------- | s-addr=131.159.1.1 | IP Header | d-addr=194.221.6.19 | | d-addr=10.0.0.1 | 封装信息 -------------------------- ---------- ---- ---------- |10.x.x.x|----|防|<----|131.159.1.1|----|火|----|墙| ---- 信息包达到不可路由的地方 ] 3.3 IP Spoofing Protection --------------------------   FIREWALL-1中的IP伪造保护(IP spoofing protection)在每一个接口级别上的网络模块都被配置。一般典型的配置如下面所示:   1.DMZ和INTRANET接口设置为“This Net” 或者可能是“This Net +”,限制接口上的合法源IP地址直接到达网络或者路由到它的网络。   2.外部接口设置为“Others”,不允许信息包的地址是源自任何DMZ或者内部网络的地址。   这样的配置看起来已经足够了,但它没有保护最重要的一个IP地址--防火墙的外部接口,拒绝来自防火墙接口的伪造信息包一般在所有FIRWALL-1中都默认激活的,除了version 4.1 Service Pack 1。同样默认规则还有一条允许ISAKMP信息包,这个漏洞允许攻击者发送任何UDP数据帧到外部防火墙接口。   还有一个存在的问题就是默认规则允许ISAKMP信息包,这个漏洞允许攻击者发送任何UDP数据包到外部防火墙接口。   另一个逃避IP伪造保护的可能就是使用目的地址是多播地址(224.0.0.1) ,作为提交信息包到防火墙底下的操作系统,在我们的演示中,我们使用FWZ封装来伪造一个从多播地址的信息包到我们的攻击主机,允许我们回应发送到多播地址的信息包到我们攻击的主机,允许我们辉映一个以多播地址的信息包,通过防火墙。这个攻击方法也可以使用广播地址来实现。 [我们在用图来解释下上面关于多播的情况: 1.-------------------------- 2.------------------------- | s-addr=224.0.0.1 | | s-addr=191.168.0.2 | | d-addr=192.168.0.1 | | d-addr=192.168.0.1 | -------------------------- ------------------------ | s-port=161 | | s-port=53 | | d-port=53 | | d-port=161 | -------------------------- ------------------------ | d-addr=192.168.0.2 | | d-addr=224.0.0.1 | -------------------------- ------------------------ ---- 1,伪造的 DNS 请求 ------------- |防|<-------------------------- |131.159.1.1| |火| 2,防火墙通道 ------------- |墙| ---- 4 Stateful Inspection --------------------- Stateful inspection firewalls 4 Stateful Inspection --------------------- [ 首先介绍下Firewall-1的Stateful Inspection 技术: Stateful Inspection由CHECKPOINT 公司开发的技术,已经成为一种企业级网络安全的解决方案。Stateful Inspection结合了所有传统防火墙技术所定义的的安全需求,如一些包过滤和应用级网关,大家可以从下面的表中获得一些对比信息: Table1: 防火墙技术对比 防火墙能力 包过滤 应用级网关 Stateful Inspection Communication Information 局部 局部 Yes Communication-derived State No 局部 Yes Application-derived State No Yes Yes Information Manipulation 局部 Yes Yes 这里的防火墙能力指的是防火墙访问,分析,利用下面所示的能力: Communication Information --指的是所有7层总信息包的信息 Communication-derived State--指的是源自以前的通信状态,如:一个FTP会话出去的PORT命令可以被保存,因此进来的FTP数据连接可以被重新效验。 Application-derived State--指的源自其他应用程序的状态信息。如:一个以前认证的用户只允许访问通过防火墙授权的服务。 Information Manipulation--指的处理任何信息包部分在数据上逻辑或者算术功能的能力。   通过Stateful Inspection,为最佳的性能,信息包在网络层被截获,但再后来的源自所有通信层的数据将被访问和分析来提高安全。它使用了一个叫INSPECT引擎来提高在网关上的安全措施。要更多的信息,请你去查看http://www.checkpoint.com的站点内容。]   Stateful inspection firewalls在信息接替交换处理的时候加强了部分语义机制,这个机制就是利用stateful inspection来完成的,但类似与被动网络监视遇到的问题对于简单的插入,逃避检查等缺少完整的处理   FireWall-1s stateful inspection存在一些在检查中有关层冲突的问题,许多攻击依靠一些对IP伪造保护不正确,或者与其他机制不平衡如FWZ封装插入等问题而引起的。 4.1 FTP 数据连接(FTP Data Connections) -------------------------------------- 4.1.1 FTP PORT Firewall-1的FTP处理尝试限制FTP数据连接到FTP客户目的地相关的连接控制,防止经典的FTP BOUNCE攻击,在以前的FIREWALL-1版本中,这个能通过把PORT命令分开成多个数据包而简单的旁路过,或者在版本3.0中可以通过”PoRT”这样的拼法来旁路。即使现在FIREWALL-1对这样的欺骗使用限制一个信息包里只有一个命令在信息包,也可以旁路,只是增加了一些难度而已。 其中最主要的思想是FIREWALL-1对IP地址的解析和一般服务器上的解析不一样造成的,大家可以先看看下面图形的解释: [ FTP “PORT” Parsing “PORT 172.16.0.258,P1,P1” | | 解析 --------- ---------- 解析 172.16.0.2<-----|FTP机器| |过滤模块|------>172.16.1.2 ----”PORT 172,16,1349632,2,p1,p2”---- |---->|172.16.0.2|<-----|192.168.0.2| data | ---- 1349632 = ----connection| | 65536 * (192 - 172) + 256 * (168 - 16) 应用于:Bounce 攻击 ] 在我们的测试中,我们演示了使PORT命令解析中使用模糊化的处理来允许我们通过防火墙这个限制.FIREWALL-1处理IP地址的规则是提取每个提供的IP地址的八位字节作为一个长整数,并移动适当的位置处理成的IP方式,而一些FTP服务机器如我们现在的目标机器Solaris 2.6是以系数为256来解释每一个八位组。 由如图上面所描写的。[具体本人不明白,请大家分析下,偶太苯了:   我们攻击的演示是针对ToolTalk RPC守护程序,我们通过FTP服务器上载了两个文件到公共可写的目录,再通过精心编制的PORT命令指示FTP守护程序上载这些文件到他们自己的ToolTalk守护端口,第一个文件是成功的杀死守护进程,第二个文件是缓冲溢出,并产生SHELL。   我们也演示了使用FWZ封装来欺骗从我们受害机器到我们想要攻击的机器的一个FTP控制连接信息包。这个信息包装载了一个PORT命令,可以让FIREWALL的FTP stateful inspection 模块解释为合法的数据连接并通过防火墙。 [我们可以用图形来解释下: -------------------------- | s-addr=172.160.2 | IP Header | d-addr=192.168.0.1 | | ”PORT | TCP header+payload | 172,16,0,2,128,7 | | d-addr=192.168.0.2 |封装信息 ------------------- |172.16.0.2|--|防|<----|192.168.0.2| ---- |火| ----|墙| 192.168.0.1 4.1.2 FTP PASV 我们本来想演示这种攻击方法在我们的测试中,但这个漏洞已经由Mikael Olsson发布到VULN-DEV了,所以没有独立的演示。 为了演示目的。我们使用了“ftp-ozone”工具通过直接连接在FTP服务器上打开了 TOOLTALK守护程序,允许我们执行远程溢出。 [让我们来看下关于FTP PASV的图形解释: --------- ”XXXXXXXXXXXXXX227(172.16.0.2.128.7)” | | <----------------------- | | -------------------- | | ---- |500 Invalid command giv| | | | 172.16.0.2 ------------------- | | | |en: XXXXXXXXXXXXXX | |--------> | | --------------------| --------- |227 (172,16,0,2,128,7) | | 192.168.0.2 --------------------- ] 4.2 简单(Simplex TCP Connections) 一个连接在FIREWALL-1连接表中限制数据流向其他的方向(从一端到另一端),第一个信息包包含TCP数据连接的连接方向,并且任何数据流向其他方向会引起这个连接被连接表丢弃。在FIREWALL-1 4.1版本之前,检查这个数据只考虑一系列信息帧中的第一个帧。因而,其可能通过发送一个TCP数据包在两个IP帧中来旁路这个限制,第一个包含TCP头,第二个包含数据(这个是利用小数据帧攻击静态信息包过滤的一个变种). [下面用图形解释下上面的情况: TCP Header + payload -------------------- |过| <----| | 被丢弃----|滤|----| 内部网络 | |模| ----| INTRANET | |块| <-------| |--| | 被接收---- | | ---- TCP TCP Header payload --------------------------------------------------> 建立连接 ] CHECKPOINT在以后的版本中修正了这个问题,但还是有另外的方法来旁路它,要注意这里一个很重要的问题,是防火墙它不尝试拆卸这个连接,它只是简单把它从连接表去掉这个表项和丢弃后续的信息包而已,因为FIREWALL不效验TCP序列号号码,所以存在可能使用同样的源和目的参数来重新建立连接,允许重新发送以前丢弃的TCP数据来为连接设置一个新的数据通道,使数据重新通过防火墙。 To exploit this, a small program running in an infinite loop that constantly re-opens the FTP data connection can be used to leak the return data through, although somewhat inefficiently. [我们可以看看下面的图形解释: | open one-way connection | |<----------------------------------------- | | datagram A | ---- |<----|----| | | datagram B ---- | | | | | |------------->|过滤模块| | | | | | | ---------- | | | -------- | open one-way connection | -------- 172.16.0.2 |<----- | 192.168.0.2 | retransmission of B | |--------> | | ...... | ] 4.3 RSH stderr   RSH上一另一个协议允许插入攻击来允许重新建立连接并通过防火墙,类似于前面的FTP PORT EXPLOIT利用。这需要合法的RSH客户端在防火墙里面,并且防火墙要配置成允许RSH/REXEC stderr连接。 RSH stderr连接处理也表现出一个问题,存在在它的管理连接状态表中,虽然我们没能够在4.1版本和之后的版本利用出这个漏洞,但我们打算把这个讨论放到我们对FIREWALL-1中使用的一些状态跟踪机制的阐述。 当FIREWALL-1接收到第一个RSH或者REXEC连接的SYN包,它就记录源地址,源端口,和目的地址,和一个MAGIC号码,并把TCP序列号+1放到pending 表,防火墙记录这些信息是为了它能认出第一个连接数据包中包含的数据,当第一个RSH连接的数据信息包(即SYN后面的一个包)通过防火墙后,它在pending table中的表目将由一个新的条目代替,包含源IP地址,error port (由TCP PAYLOAD展开的),目的IP地址,同样的MAGIC号码,和IP协议。防火墙在截获第一个SYN的错误连接,防火墙检查它在pending表中的参数并增加其中的连接到连接表中. 在使用pending table中存在一个冲突可以被利用,如果我们提供一个初始化值为5,那样在pending表中加1变为6--与第一个信息包建立的条目,因此,通过伪造一个来字intranet或则DMZ机器的的数据包--其数据包由ISN初始化序列号值为5,包含我们要访问的源端口,我们要攻击的机器的目的IP地址,和RSH服务的目的端口组成,这样的一个SYN包就会把这个表项增加到连接表中以允许我们连接到“RSH client”. 在版本4.1中,这个问题不能被利用,因为初始化SYN包不能被通过 [我们可以参照下面的图形来帮助理解: ---------------------------------------- | |s-addr:s-port | |s-addr:s-port | | |d-addr:magic | |d-addr:magic | | |seq+1 | |seq+1 | SYN <----| ------| ------ || | |172.16.0.2:1024 | || | |192.168.0.2:magic | || | |250001 | || ------------------- || ------------------- || | |s-addr:error-port | || | |d-addr:magic | || | |protocol | | |packet#2<----| ------ vv(port info) | ------- | |172.16.0.2:1025 | |172.16.0.2:32775 | | |192.168.0.2:magic | |192.168.0.2:magic | | |6(TCP | |6 = seq + 1 = TCP |--------------- ] 4.4 UDP Replies   在FIREWALL-1 4.0默认安装下,允许DNS通讯所有的主机,当和不严格的IP伪造保护结合起来的时候,这个规则将允许我们从DMZ或者INTRANET伪造UDP数据包到我们所要攻击的机器,如果UDP回应允许,我们可以回答那些数据包--即有效的允许我们可以和防火墙后面的任意UDP服务通信。  我们这里的演示攻击了目标机器是SOLARIS2.6系统的SNMP守护程序,使用“tun”同居,我们发送FWZ封装的数据包到防火墙的外部接口,当被解封装的时候,被认为是来自内部机器的SNMP服务,并指定端口为53/UDP。 [先看看下面的图形解释: -------------------------- | s-addr=172.160.2 | IP Header | d-addr=192.168.0.1 | | s-port=161 | UDP header | d-port=53 | | d-addr=192.168.0.2 |封装信息 ------------ ---- ------------- |172.16.0.2|--|防| <------|192.168.0.2| ----|火| 伪造的DNS请求----DNS被请求 |墙|---- 192.168.0.1 ] 这样其实是对172.16.0.2的DNS作出了请求。 5 一些推荐 5.1 Non-reliance on NAT 就想上面提到的,FWZ封装可以用来发送信息包通过不能被路由的防火墙,这包括信息包指定在NAT或则RFC 1918私人网络后面的地址,举一个例子,在防火墙默认配置中,由于“allow all port 53” 规则一个攻击者可以直接访问INTRANET或者DMZ中的DNS服务。如果ICMP的“allow all”规则允许,一个攻击者可以MAP任意INTRANET或者DMZ的子网络。   NAT和不能路由地址不必要的提供任何固有安全,虽然FWZ封装对FIREWALL-1很有效,类似攻击使用其他VPN封装技术可以更加广泛的应用--GRE,为IPSEC的IP协议,和甚至在IPV4中的IPV6通道。 5.2 推荐配置 一些简单的规则: 1.尽可能运行最新的FIREWALL-1版本。 2.关闭一些规则,包括DNS,管理控制连接和ICMP 3.在定义规则的时候尽量明确--没有如“any”这样的源或者目的IP地址,拒绝多播和广播地址等等。 4.在所有接口中激活所有IP伪造保护机制。 5.Pre-filter IP protocol 94 6.给公共服务的使用的虚拟地址。 7.到目前使用FWA1认证。 5.3 补丁信息 CHECKPOINT已经发表对这些问题的补丁,当前的SERVICE PACK,HOTFIX和警告可以到下面的地址: http://www.checkpoint.com/techsupport/ http://www.checkpoint.com/techsupport/alerts 在这个建议里,我们概括了我们发现的和提供了一些安全配置的建议,并且提供了一些补充用的图片和源代码,大家可以到下面地方去查找: http://www.dataprotect.com/bh2000/ [上面地址包含测试工具的源程序,和帮助你理解的图形解释,虽然我这里为了方便大家,尽力把这些图文本化了,可你如果要色彩或者更明了的话就下载上面的.pdf文件,希望有点帮助。]

返回列表 回复 发帖