Oicq 的安全问题

清风客

Oicq 作为Inet实时通讯应该是一个不错的选择，其众多的用户群也证明了这点。(按照腾讯主页上的说话,截至目前，Oicq 用户已经突破 450 万，而且以每天30000的速度增加）
在安全问题日益突出的今天，一个如此*广泛使用*的产品不去考虑安全方面的问题，显然是不明智的。而且这个考虑应该是在产品规划阶段就提上日程的。Oicq 显然没有把安全放在第一位，几个月前，安安（watchsea@sina.com）就已经指出了 Oicq 存放在本地的用户口令仅仅使用了微弱的加密手段。 （ build:220 中，Oicq 声称已经将其修正）
经过我们的分析测试，更加严重的问题还在后面。在发现了这些问题后，我们马上通知了腾讯公司，腾讯的反应很快，一夜间，Oicq 的版本就从220 升级到了 410 . 在其 whatnew 中，声称解决了这些问题。
我们立即对其进行了测试。应该看到，在 Oicq build 410 中，腾讯使用了某种加密协议，从而解决了明文传输的问题。应该说是一个很大的进步。
因此本文分为两章，第一章针对 Oicq Build 220 及其以下版本。
第二章针对 Oicq Build 410 (截至目前最新版本）
应该看到，本文不带有任何地感情色彩，我们也是使用 Oicq 进行日常的联络的.希望腾讯公司能尽快的解决这些问题。
- I -
测试报告：
除开安全问题，Oicq 应该是一个很好的选择，其功能实用，不花哨。但作为一个放在互连网上的产品，必须还要考虑到安全性。Oicq 采用的是 server-client 模型，使用的是 UDP 协议。和 TCP 相比，UDP 本身就是不可靠的，可被轻易的伪造。使用 UDP 协议的软件必须自身在两端进行可靠性检测。但和 TCP 相比,UDP 在资源占用上显然要小许多，这也是 Icq,Oicq 选择 UDP 的一个主要原因。
经过分析，Oicq 在所有的传输过程中，任何数据都使用了明文发送，也就是说，一个窃听者能直接的偷听到经过其的所有 OICQ 信息。这是一个不大不小的问题，象往常一样，你有两个选择，更低的资源占用率和更高的安全性。很难作出决定在二者之间。显然， Oicq 选择了前者。
在Oicq中最常用的消息传送时，Oicq 采用了如下策略： 当二者能直接（点到点）通讯时，消息就直接的发送到对方，否则重试 N 次后通过Oicq 服务器转发。接受方在收到消息后返回一个回应信息，发送方就是通过这个信息来确认消息是否已经收到。
当接受方收到Udp Packet,就会显示有信息收到，完全没有其他的验证过程。也就是说，如果我从 linux 上发了个符合上述格式的 Udp packet,在 cOicqNub 处可填写任意的oicq 号码，也就是可以伪造了任何的 oicq 号码。(你看到Oicq 上显示号码为 1 的用户向你发信，不要吃惊。)
例如：有 A, B ,C 三用户，Oicq 分别是：
A: 10000
B: 20000
C: 30000
已知 B 和 C 是好友，则 A 可以发送一个带有 B 号码的Udppacket 给 C, 在C 处看来，完全就像是 B 亲自发给他的一样，但此时如果 C 点回复的话，信息会回到 B 的地址(IP)上。A 不能收到。也就是说 A 只能冒充B 发消息。如果此时 A 不停地发，就形成了 Oicq Flood,注意的是，此时Tag6,Tag7 两处要不停地
变化，Oicq 对两个完全一样的信息只显示一次。
严重的是，虽然Oicq 本身对发送的消息的长度做了限制，但这种限制是在发送方进行的，一旦发送的长度超过 2000 or >2000 个字节，接受方的 Oicq 就会发生缓冲区溢出，相当严重的远程溢出。
接下来就是谈谈怎样让 C 回复伪造消息时直接返回到 A 处。
运行 Oicq 时，过程如下：
start oicq.exe-> 上线 -> oicq 把口令发给 oicq server -> oicq server 返回
其好友名单以及其对应的 IP (Oicq 把他存到本地内存中的一张表中)
当 Oicq 给相应的好友号码发送消息时，依据的地址就是这个 IP.即首先与该 IP 联系，反复多次没有回音就通过服务器转发。
向目标发送一个UDp packet ，可让任意的在其列表上的好友上线或下线。在上线时，IP 可填任意的你所希望的。然后Oicq 就会更据该 IP 来发送消息。
这样，上面的例子就改为：
首先， A 发送一个带有 B 上线信号的消息给 C, 但其 IP 添写 A 自己的IP,不管此时 B 在线上没有， C 的 oicq 中就会显示 B 正在线上，此时 C 给 B 发消息，更据的地址(IP) 就是 A 的地址，其所有的消息都会发往 A 处。
但此时有个问题：
如果 C 反复发送多次都没有收到来自 ‘B' 的回复时，就会通过Oicq 服务器转发。这样 真正的 B 也会收到。解决方案是 C 在收到消息的同时也给 A 发送一个回复。--------
值得注意的是，如果此时 A 所指定 C 回复的 IP 处正好有一个 Oicq ,C 发给 B 的信息就会直接显示在其上面，不用伪造回复包。
至此，完整的一次Oicq 欺骗就完成了。
再来一次：
A 发送一个带有 B 上线信号的消息给 C, 但其 IP 添写 A 自己的IP(或所希望的),这样 C 的 oicq 中就显示了 B 正在线上，当 C 给 B 发消息时，更据的地址却是 A 的地址，其所有的消息都会发往 A 处。A 及时的返回一个表示已收到的消息给 C ，C 处不会感到任何地异常，就仿佛是在和真正的 B 通讯一样，
如果当 A 发送消息时 B 已经在 C 的 Oicq 线上，此时 C 的 IP 表中关于 B 的ip 是其真实的 地址，此时我们有两种方法：
1. 向 c 发送一个 B 已下线的信号，让真正的 B 下线，然后再发送一个假的上线信号2. 直接发送一个假的 B 上线信号，同样的， C 的IP 表中关于 B 的地址也会更新。在 Oicq 的所有消息传送过程中，除了上线和下线时向oicq server 效对了口令之外，其余的所有过程中，都没有进行任何的口令效验. 显然这是腾讯公司程序员的疏忽。
- II -
在我们告知腾讯公司关于 Oicq 的问题之后，腾讯很快的就推出了一个新版。以修正其安全问题。在此之前，我就得知，Oicq 最近会有大的改动，可能是我们的原因，迫使得他们提前将不成熟版推出。在新版中, 腾讯使用了某种新的算法将所有的明文进行加密。算法的强度我们不得而知。但应该会在很大的程度上增强其安全性。如果其早一周公布，这篇文章也就不会公布了。
在新版中，以前能随意使用户上下线的方法不行了，但其他的问题依然存在。首先是缓冲区溢出，问题依然，任何熟悉安全的人士都知道这是个严重问题，远不止当掉 Oicq 那么简单。希望腾讯能马上解决。
其次是类似于 build: 220 中那种假冒任意用户的 bug 依然如故。方法一样。这也是个严重的问题，我们应该相信谁？
最后是象 Build 220 中那种完全欺骗 C 的技巧依然存在，即可以在某些情况下截获任何人的对话，然后冒充之。
这个问题严重吗？赫赫...老话，希望腾讯马上修正。
总结：
有 ICQ 的前车之鉴， Oicq 本应做得更好。作为一个传递着纵多用户隐私的重要通讯工具，Oicq 应该说在安全方面做得很糟。发展到现在，为了保持向下兼容，Oicq 也很难立即作出大的改动。希望腾讯公司能尽可能修复这些问题，保护好广大用户的利益。
FAQ:
1. 我如何得到对方的 的 IP地址？
如果你知道了他的 oicq 号码，搜索加为好友，然后可以得到。最快的方法是向他发送一条消息，然后 Sniff 一下发出的 Udp 包。