|
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 翻译整理: XUNDI 注：带[]的段落都是本人整理的东西； 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服务器上打开了 一次简单脚本攻击实例 | 
