XUNDI·yesky
原文 Thomas Lopatic, John McDonald
TUV data protect GmbH
@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 ----- --------
---- |
|
---------
|OpenBSD| 194.221.6.149
---------
| | | |
-------------------------------------------- -------------------------
Victim network Hostile network
]
-----------------------------------------------------------------------------
--------
在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/获取更多资料]
----------
[这里先用图形介绍下FireWall-1 Modules:
----------------------------------------------------------------------
------- Port 258/TCP ----------
| GUI | ----------"gt;"gt; |管理模块|(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命令来上载"quot;allow all"quot;措施来验证低于4.0版本产品。我们
旁路过认证来发布unload命令是比较容易实现和可以各个版本之间容易移植。
-----------------
[首先先用图形介绍Inter-Module authentication Protocol：
| Version(版本) |
|-----------------------------------------"gt; |
| Version(版本) |
----- |"lt;----------------------------------------- | ----
|管 | | Command(命令) | |过|
|理 | |-----------------------------------------"gt; | |滤|
|模 | | IP addresses(IP地址) | |模|
|块 | |-----------------------------------------"gt; | |块|
----- | IP addresses(IP地址) | ----
|"lt;----------------------------------------- |
| Required authentication |
|"lt;----------------------------------------- |
| Authentication(认证) |
|"lt;----------------------------------------"gt; |
| Arguments, Result |
|"lt;----------------------------------------"gt; |
]
在内部的安全认证模块里，过滤模块(filter module )不通过一个连接中相匹配的
地址来验证认证模块的源IP地址。它仅仅检查的是IP列表并来处理它，一个
通常的错误配置就是把
放到了control.map中，以便方便的本地管理。一个攻击者只需要发送127.0.0.1
以它的源地址来完全绕过认证，我们的"quot;fw1none"quot;程序就能很好的进行测试。
在交换Version(版本)和IP地址信息(见上图)后，过滤模块回应它想被执行的
认证，在成功的认证之上，管理模块就传送了命令执行的参数，最后过滤模块
返回一状态代码来指示是否命令执行成功。
此协议没有很严格的同步，特别对于IP地址交换的出现不同步，如管理模块
可以不首先发送它的IP地址信息，它可以等待过滤模块发送所有IP地址并再
传送它自己的。在这种方式下，一个攻击者可以扮演管理模块来知道防火墙
的所有IP地址并不进行实际的认证，这在下面讨论的关于封装攻击或者发现
管理模块的IP地址上很有用。
如果我们提供的一个IP地址给过滤模块并不与管理模块相同或者就是说这个IP
地址没有一个 authentication secret--过滤模块就会简单的拒绝其认证，然
而我们可以通过重复的连接扫描正确的IP地址，就是说每连接一次给一个不同
的IP地址来暴力型的猜测。
----------
[首先先用图形介绍S/KEY的工作原理：
Hash n (x) = Hash(Hash(... Hash(x))) = Hash(Hash n-1 (x))
n times
| Index = 99 |
|"lt;----------------------------------------- |
| Hash 99 (x) |
----- |-----------------------------------------"gt; | ----
| 管| | .... | |过|
| 理| | | |滤|
| 模| | Index = 1 | |模|
| 块| |"lt;----------------------------------------- | |块|
----- | Hash 1 (x) | ----
Seed x |-----------------------------------------"gt; | Hash 100 (x)
(password hash) | 计算seed y, Hash 100 (y) |
|-----------------------------------------"gt; |
-- "quot;y = MakeSeed(time(NULL))"quot;
-- 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暴力破解程序"quot;fw1bf"quot;，我们可以通过使用并行连接对Firewall-1 4.0
进行每秒50次的猜测，这样就可以在半小时内猜测包含整天的认证secret.版本4.1不支
持多个并行连接，降低了我们的有效性。
当S/KEY的认证SECRET一旦被破获，就可以使用我们这里的"quot;fw1skey"quot;工具来发布
unload命令给过滤模块。
如果没有S/KEY认证加密或者其他数据完整性的防备，内部的威胁如TCP连接HIJACKING
会经常被采用而受到攻击。
--------
[首先先用图形介绍FWN1 Authentication的工作原理：
| 随机数 R1 |
|"lt;----------------------------------------- |
| S1 = Hash(R1 K) |
----- |"lt;----------------------------------------- | ----
|管 | | | |过|
|理 | | | |滤|
|模 | | 随机数 R2 | |模|
|块 | |-----------------------------------------"gt; | |块|
----- | S2 = Hash(R 2 K) | ----
|-----------------------------------------"gt; |
-- 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值是使用"quot;fw putkey"quot;来设置的，因此，在第一次认证后，Diffie-Hellman
key交换被初始化，起结果是生成一个新的共享1024 bit secret K来作为认证。
FWN1 协议按照如下的方式工作：
这个协议是通过简单的攻击来破坏。我们可以简单的重新使用通过过滤模块发送
的R1，然后我们再重新使用S1来代替我们必须生成自己的S2。也就是上图所说的：
选择 R2 = R1 , 因此 S2 = S1。
我们的"quot;fw1fwn"quot;工具可以实现通过FWN1认证来发布unload命令。
如果没有FWN1认证加密或者其他数据完整性的防备，内部的威胁如TCP连接HIJACKING
会经常被采用而受到攻击。
--------
[首先先用图形介绍FWN1 Authentication的工作原理：
| 随机数 R1 |
|"lt;----------------------------------------- |
| S1 = Hash(R1 K) |
----- |"lt;----------------------------------------- | ----
|管 | | | |过|
|理 | | | |滤|
|模 | | 随机数 R2 | |模|
|块 | |-----------------------------------------"gt; | |块|
----- | S2 = Hash((R1 ^ R2 ) K) | ----
|-----------------------------------------"gt; |
-- 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值是使用"quot;fw putkey"quot;来设置的，因此，在第一次认证后，
Diffie-Hellman key交换被初始化，起结果是生成一个新的共享1024 bit secret K来认证。
FWN1 协议按照如下的方式工作：
因此，对比FWN1认证唯一改变的管理模块签字R3 = R1 ^ R2来代替R2，这样，
这个协议也可以被击破，我们可以选择R2为0，按照这种方法，R3 = R1 ^ R2
就等于R3=R1，我们就能再重新使用过滤模块签名了。
我们的"quot;fw1fwa"quot;工具用来实现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也需要至少
successful” 回应的明文攻击难于成功。
--------------------------
静态包过滤可能是最简单的网络访问控制机制，但很迷惑的是也是最难正确的
实现。我们发现FIREWALL-1可被许多基于不完全输入验证攻击，也包括一些对
stateful inspection的攻击。
----------------
[首先用图形介绍下FASTMODE：
----
|过|
------------ non-SYNs |滤| non-SYNs -----------
|127.16.0.x|"lt;------------|模|-------------"gt; |Internet |
------------ |块| -----------
----
-- non-SYN 信息包被接受
-- Source port = fastmode service
-- Destination port = fastmode service
-- Stealth scanning (FINs, ...)
FireWall-1 提供一个叫"quot;fastmod"quot;的机制来允许一个管理者可以增加部分设备的
性能，但也带来部分安全性。FIREWALL-1 内核模块对那些含有目的端口和源端口
都是FASTMODE服务的信息包没有进行额外的连接或者规则的检查。
另外，在FASTMODE里，只有SYN包被验证，这就允许攻击者提供non-SYN TCP信息包
通过FIREWALL来MAP网络。我们演示了在nmap中使用-g和-sF选项来完成。
--------------------------
[首先看看FWZ 封装的图形解释：
|
| 1. original d-address, original protocol
| |
|_______ |-----------------------------------------|
| | |
--------- ---------
|修改的 | ---------------------------- |封装的 |
| IP 头 | | IP 装载(payload) | |信息 |
--------- ---------------------------- ---------
-- VPN tunneling protocol
-- Decapsulation without decryption or authentication
-- Cannot be disabled
|
