斌、朵♫恋 » 入侵手法 » ｡◕‿◕｡FireWall-1由于协议设计而存在的可利用缺陷｡◕‿◕｡
| FireWall-1由于协议设计而存在的可利用缺陷 原文 Thomas Lopatic, John McDonald TUV data protect GmbH {tl,jm}@dataprotect.com Dug Song Center for Information Technology Integration University of Michigan dugsong@monkey.org 注：带[]的段落都是本人整理的东西； BTW：本人能力有限，错误难免,请指正。 [首先我用ASCII码画出TOPOLOGY图，这样可以更容易的理解文章的内容： --------------------------------------------------------------------- -------- | NT | 194.221.6.149 -------- | |194.221.6.159 | ---- --------- |防| ----- -------- |Solaris|_____________________|火|_______________|HUB|_________| Linux| --------- 172.16.0.1 |墙| 192.168.0.1 ----- -------- 172.16.0.2 | | | 192.168.0.2 ---- | | --------- |OpenBSD| 194.221.6.149 --------- 192.168.0.3 | | | | -------------------------------------------- ------------------------- Victim network Hostile network ] ----------------------------------------------------------------------------- 1,介绍 -------- 在Black Hat Briefings 2000中，我们介绍了由协议设计缺陷而造成的Check Point FireWall-1 的漏洞分析或者由普通或者默认配置错误的问题，以及 在实现室过去几月发现的一些小的实现错误并在在实际突破测试里进行了验证。 我们的研究是针对一运行FireWall-1 version 4.0 Service Pack 5的NOKIA IP440 系统上的。CHECK POINT后来提供了4.1 版本Service Pack 1，但这个版本还是存在 大多数我们在这里描述的漏洞，不过对于默认中的配置已经安全了不少。CHECKPOINT 已经发布了关于所有这里描述的漏洞的SERVICE PACK。 [大家可以到http://www.checkpoint.com/techsupport/获取更多资料] 2 认证 ---------- [这里先用图形介绍下FireWall-1 Modules: ---------------------------------------------------------------------- ------- Port 258/TCP ---------- | GUI | ---------->> |管理模块|(Management Module) ------- ---------- ^^ || 认证方式 Port 256/TCP || Authentication methods 安全措施，状态，LOG || S/Key, FWN1, FWA1 vv ^^ || {-------------------------------------------------------------} { } ---- ---- ---- |过| |过| |过| |滤| |滤| |滤| |模| |模| |模| |块| |块| |块| ---- ---- ---- ] 在任何安全产品的检查中，管理的控制渠道是通常与其漏洞有关 -- 也是最必要 的安全检查处。事实上，我们发现在FireWall-1中的内部模块认证协议容易受到 一些简单的攻击。 我们这里的攻击是假设攻击者可以在过滤模块(filter module)上能访问256/TCP端口， 且知道一个管理模块(management module)的IP地址或者等同于一些共享的认证secret (shared authentication secret)已经使用``fw putkey.'' 进行了配置。在4.0版本中， 这个端口默认配置下是向外界打开的，它也能通过SecuRemote 客户端来使用，在4.1版 本中，SecuRemote使用了264/TCP端口，对256/TCP端口的访问被限制了。 虽然只有管理控制台可以发布unload命令，但两进制的load(bload)命令默认状态下可以 由过滤模块(filter module)认证过、有(authentication secret)任意IP地址来发布。 我们这里可以通过使用load命令来上载"allow all"措施来验证低于4.0版本产品。我们 旁路过认证来发布unload命令是比较容易实现和可以各个版本之间容易移植。 2.1 IP 地址验证 ----------------- [首先先用图形介绍Inter-Module authentication Protocol： | Version(版本) | |-----------------------------------------> | | Version(版本) | ----- |<----------------------------------------- | ---- |管 | | Command(命令) | |过| |理 | |-----------------------------------------> | |滤| |模 | | IP addresses(IP地址) | |模| |块 | |-----------------------------------------> | |块| ----- | IP addresses(IP地址) | ---- |<----------------------------------------- | | Required authentication | |<----------------------------------------- | | Authentication(认证) | |<----------------------------------------> | | Arguments, Result | |<----------------------------------------> | ] 在内部的安全认证模块里，过滤模块(filter module )不通过一个连接中相匹配的 地址来验证认证模块的源IP地址。它仅仅检查的是IP列表并来处理它，一个 通常的错误配置就是把 127.0.0.1: */none 放到了control.map中，以便方便的本地管理。一个攻击者只需要发送127.0.0.1 以它的源地址来完全绕过认证，我们的"fw1none"程序就能很好的进行测试。 在交换Version(版本)和IP地址信息(见上图)后，过滤模块回应它想被执行的 认证，在成功的认证之上，管理模块就传送了命令执行的参数，最后过滤模块 返回一状态代码来指示是否命令执行成功。 此协议没有很严格的同步，特别对于IP地址交换的出现不同步，如管理模块 可以不首先发送它的IP地址信息，它可以等待过滤模块发送所有IP地址并再 传送它自己的。在这种方式下，一个攻击者可以扮演管理模块来知道防火墙 的所有IP地址并不进行实际的认证，这在下面讨论的关于封装攻击或者发现 管理模块的IP地址上很有用。 如果我们提供的一个IP地址给过滤模块并不与管理模块相同或者就是说这个IP 地址没有一个 authentication secret--过滤模块就会简单的拒绝其认证，然 而我们可以通过重复的连接扫描正确的IP地址，就是说每连接一次给一个不同 的IP地址来暴力型的猜测。 2.2 S/KEY ---------- [首先先用图形介绍S/KEY的工作原理： Hash n (x) = Hash(Hash(... Hash(x))) = Hash(Hash n-1 (x)) {______________________} n times | Index = 99 | |<----------------------------------------- | | Hash 99 (x) | ----- |-----------------------------------------> | ---- | 管| | .... | |过| | 理| | | |滤| | 模| | Index = 1 | |模| | 块| |<----------------------------------------- | |块| ----- | Hash 1 (x) | ---- Seed x |-----------------------------------------> | Hash 100 (x) (password hash) | 计算seed y, Hash 100 (y) | |-----------------------------------------> | -- "y = MakeSeed(time(NULL))" -- Attack: brute force暴力方式 ] S/KEY认证一般在用于当与嵌入到FireWall-1的设备通信的时使用。它也是版本4.0 过滤模块中那些没有加密许可证或者不支持FWA1必要的认证方式 Check Point的 S/Key 问题是在99次反复使用shared secret后，管理模块就使用 time()函数来产生一个新的认证SECRET，而time()函数是以秒为单位的，因此，在 单单一天里生成SECRET的可能几率只有24 * 3600 =86400 不同的可能性，更甚的 是，如果过滤模块的状态间隔每10秒轮循一次，99次认证将最大在990秒内执行完成。 所以我们必须在990秒之内可以尝试990次可能值，因为我们确信在这阶段至少有一个 新的shared secret 产生。 通过我们的S/KEY暴力破解程序"fw1bf"，我们可以通过使用并行连接对Firewall-1 4.0 进行每秒50次的猜测，这样就可以在半小时内猜测包含整天的认证secret.版本4.1不支 持多个并行连接，降低了我们的有效性。 当S/KEY的认证SECRET一旦被破获，就可以使用我们这里的"fw1skey"工具来发布 unload命令给过滤模块。 如果没有S/KEY认证加密或者其他数据完整性的防备，内部的威胁如TCP连接HIJACKING 会经常被采用而受到攻击。 2.3 FWN1 -------- [首先先用图形介绍FWN1 Authentication的工作原理： | 随机数 R1 | |<----------------------------------------- | | S1 = Hash(R1 + K) | ----- |<----------------------------------------- | ---- |管 | | | |过| |理 | | | |滤| |模 | | 随机数 R2 | |模| |块 | |-----------------------------------------> | |块| ----- | S2 = Hash(R 2 + K) | ---- |-----------------------------------------> | -- Shared key K (“fw putkey”) -- Attack: 选择 R2 = R1 , 因此 S2 = S1 ] FWN1是可以作为S/KEY的替代品，有时用来站点缺少对版本4.0过滤模块的加密 许可证。FWN1在版本4.0和4.1里是OPSEC默认的认证方式。 认证是基于shared secret K，这个secret需要使用一个keyed hash来对数据签字， K追加到数据中并把结果传递给一个加密的安全hash函数，其结果的摘要(digest) 用来作为数字签名。相同的，K也能通过计算同样的keyed hash来效验这个数字签名。 其中原始的K值是使用"fw putkey"来设置的，因此，在第一次认证后，Diffie-Hellman key交换被初始化，起结果是生成一个新的共享1024 bit secret K来作为认证。 FWN1 协议按照如下的方式工作： 1，过滤模块生成一个随机数R1。 2，过滤模块对R1签字，数字签名S1=Hash(R1+K)，这里的+是表示串联。 3，R1和S1发送到管理模块。 4，管理模块验证S1。 5，管理模块生成随机数R2。 6，管理模块计算相应的签字S2=Hahs(R2+K),这里的+表示串联。 7，R2和S2被发送到过滤模块。 8，过滤模块在验证S2。 这个协议是通过简单的攻击来破坏。我们可以简单的重新使用通过过滤模块发送 的R1，然后我们再重新使用S1来代替我们必须生成自己的S2。也就是上图所说的： 选择 R2 = R1 , 因此 S2 = S1。 我们的"fw1fwn"工具可以实现通过FWN1认证来发布unload命令。 如果没有FWN1认证加密或者其他数据完整性的防备，内部的威胁如TCP连接HIJACKING 会经常被采用而受到攻击。 2.4 FWA1 -------- [首先先用图形介绍FWN1 Authentication的工作原理： | 随机数 R1 | |<----------------------------------------- | | S1 = Hash(R1 + K) | ----- |<----------------------------------------- | ---- |管 | | | |过| |理 | | | |滤| |模 | | 随机数 R2 | |模| |块 | |-----------------------------------------> | |块| ----- | S2 = Hash((R1 ^ R2 ) + K) | ---- |-----------------------------------------> | -- Shared key K (“fw putkey”) -- Attack: 选择 R 2 = 0, 因此 --R1 ^ R2 = R1 和 --S2 = Hash((R1 ^ R2 ) + K) = Hash(R1 + K) = S1 --要解决的问题是:通信时候的加密 ] FWA1类似于FWN1,不过增加了模块之间的通信加密。这个机制在版本4.1上默认使 用，当有加密许可证提供的时候，在版本4.0上也可以使用绝大多数命令。 和上面一样，其中原始的K值是使用"fw putkey"来设置的，因此，在第一次认证后， Diffie-Hellman key交换被初始化，起结果是生成一个新的共享1024 bit secret K来认证。 FWN1 协议按照如下的方式工作： 1，过滤模块生成一个随机数R1。 2，过滤模块对R1签字，数字签名S1=Hash(R1+K)，这里的K是表示串联。 3，R1和S1发送到管理模块。 4，管理模块验证S1。 5，管理模块生成随机数R2。 6，管理模块计算R3 = R1 ^ R2，之中"^"表示XOR。 7，管理模块计算相应的签字S2 = Hash(R3 + K)，这里的+表示串联。 8，R2和S2发送到过滤模块 9，过滤模块在验证S2。 因此，对比FWN1认证唯一改变的管理模块签字R3 = R1 ^ R2来代替R2，这样， 这个协议也可以被击破，我们可以选择R2为0，按照这种方法，R3 = R1 ^ R2 就等于R3=R1，我们就能再重新使用过滤模块签名了。 我们的"fw1fwa"工具用来实现FWA1认证，然而unload命令是不能发布，因为使用 加密的方法保护了通信通道。 我们为了清楚明了的缘故，简化了对FWN1和FWA1认证算法的测试。在实验中，仅仅 对签名的128位中的64位进行的传输，在FWA1中S1和S2的剩余64 bits连接形成128 bit 加密KEY，由于要对S1=S2进行攻击，我们要成功实现unload命令就需要猜测64位 加密KEY，这里需要更复杂和更多的实验来进行观测。 如果shared 1024 bit secret的产生由Diffie-Hellman key exchange计算出，那么由 于缺少熵而使通过暴力攻击需要更多的可猜测性。我们可能通过暴力找到一组相 关的基于R1和S1的K的候选值。然后我们在尝试所有K的候选值来发现真正的K，为 了鉴定真正的K，我们可以使用明文``authentication successful'' 来回应我们 接收到的加密信息。 由于时间原因，我们没有对FWA1协议进行完成的测试攻击，包括加密。但是作为这个 认证机制还是有严重的问题。 FWA1使用了proprietary stream cipher算法的FWZ1，这个方法是近来在USENET 上的sci.crypt新闻组上报道的。不幸的是，一个简单的命令如unload也需要至少 18个字节的参数。而且，不同的KEY使用在任一个方向上，使针对``authentication successful'' 回应的明文攻击难于成功。 3 Packet Filtering(包过滤) -------------------------- 静态包过滤可能是最简单的网络访问控制机制，但很迷惑的是也是最难正确的 实现。我们发现FIREWALL-1可被许多基于不完全输入验证攻击，也包括一些对 stateful inspection的攻击。 3.1 TCP Fastmode ---------------- [首先用图形介绍下FASTMODE： ---- |过| ------------ non-SYNs |滤| non-SYNs ----------- |127.16.0.x|<------------|模|-------------> |Internet | ------------ |块| ----------- ---- -- non-SYN 信息包被接受 -- Source port = fastmode service -- Destination port = fastmode service -- Stealth scanning (FINs, ...) FireWall-1 提供一个叫"fastmod"的机制来允许一个管理者可以增加部分设备的 性能，但也带来部分安全性。FIREWALL-1 内核模块对那些含有目的端口和源端口 都是FASTMODE服务的信息包没有进行额外的连接或者规则的检查。 另外，在FASTMODE里，只有SYN包被验证，这就允许攻击者提供non-SYN TCP信息包 通过FIREWALL来MAP网络。我们演示了在nmap中使用-g和-sF选项来完成。 3.2 FWZ 封装(Encapsulation) -------------------------- [首先看看FWZ 封装的图形解释： 2. d-address = firewall, protocol = 94 | | 1. original d-address, original protocol | | |_______ |-----------------------------------------| | | | --------- --------- |修改的 | ---------------------------- |封装的 | | IP 头 | | IP 装载(payload) | + |信息 | --------- ---------------------------- --------- -- VPN tunneling protocol -- Decapsulation without decryption or authentication -- Cannot be disabled ] 对于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-1's 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文件，希望有点帮助。] xundi@xfocus.org 2000-08-28 http://www.xfocus.org http://focus.silversand.net |
« 关于IPV6的一些设置测试无法查看工作组计算机（找不到网上邻居）解决方法 »
.clear
发表评论: