发信人: flyingblue (好想睡觉！), 信区: Encrypt
标 题: Re: 请教OICQ的加密原理
发信站: 武汉白云黄鹤站 (Wed May 31 13:52:22 2000), 站内信件
c前言:
Oicq 作为Inet实时通讯应该是一个不错的选择，
众多的用户群也证明了这点。(按照腾讯主页（www.tencent.com)
上的说话,截至目前，Oicq 用户已经突破 450 万，而且以每天30000的速度增加）
在安全问题日益突出的今天，一个如此*广泛使用*的产品不去考虑
安全方面的问题，显然是不明智的。而且这个考虑应该是在产品
规划阶段就提上日程的。Oicq 显然没有把安全放在第一位，几个月
前，安安（
[email protected]）就已经指出了 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 服务器转发。接受方
在收到消息后返回一个回应信息，发送方就是通过这个信息来确认消息是否已经收到。
消息的结构是：
（注意：本文中所有的 Oicq 协议结构是通过分析得来，不能保证其正确性）
struct TOicqPtoP
{
char Tag1; // 0x02 // 显然是 Oicq 的协议编号 or 版本，固定
char Tag2; // 0x01 // 显然是 Oicq 的协议编号 or 版本，固定
char Tag3; // 0x07
char Tag4; // 0x00
char Tag5; // 0x78
char Tag6; // 这两个字节相当于 unix 上的进程 ID,
char Tag7; // 随便赋值就可。
char cOicqNub[]; // 发送方的Oicq 号码。 exp:123456
char cFF; // 0x1f 在所有的Oicq 信息结构中，分割符都是 0x1f
char cR; // '0' 固定
char cFF; //
char cE[]; // "75" ，这一位相对固定，可能是操作方式。
char cFF;
char cDateTime[]; // exp: "2000-4-10",0x1f,"12:00:12",0x1f
char OutMsg[]; // 发送的消息内容。
char cEnd; // 0x03 ,所有的 oicq 信息都已 0x03 为标记结束。
};
当接受方收到以上格式的 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 联系，反复多次没有回音就通过服务器转发。
下面是 Oicq server 通知Oicq 好友上线和下线的消息结构：
struct TOicqUp
{
char Tag1; // 0x02 // 显然是 Oicq 的协议编号 or 版本，固定
char Tag2; // 0x01 // 显然是 Oicq 的协议编号 or 版本，固定
char Tag3; // 0x00
char Tag4; // 0x00
char Tag5; // 0x81
char Tag6; // 这两个字节相当于 unix 上的进程 ID,
char Tag7; // 随便赋值就可。
char cOicqNub[]; // 通知上线的Oicq 号码。 exp:123456
char cFF; // 0x1f 在所有的Oicq 信息结构中，分割符都是 0x1f
char cIP; // 该号码所在的 IP 地址
char cFF; //
char cE[]; // "8685" ，这一位相对固定，随便添一个四位数字
char cFF;
char cDD[]; // exp: "10",0x1f,"107" 基本固定
char cEnd; // 0x03 ,所有的 oicq 信息都已 0x03 为标记结束。
};
//--------------------------------------------------------
struct TOicqDown
{
char Tag1; // 0x02 // 显然是 Oicq 的协议编号 or 版本，固定
char Tag2; // 0x01 // 显然是 Oicq 的协议编号 or 版本，固定
char Tag3; // 0x00
char Tag4; // 0x00
char Tag5; // 0x81
char Tag6; // 这两个字节相当于 unix 上的进程 ID,
char Tag7; // 随便赋值就可。
char cOicqNub[]; // 通知上线的Oicq 号码。 exp:123456
char cFF; // 0x1f 在所有的Oicq 信息结构中，分割符都是 0x1f
char cIP; // 该号码所在的 IP 地址 // 随便填
char cFF; //
char cE[]; // "8685" ，这一位相对固定，随便添一个四位数字
char cFF;
char cDD[]; // exp: "20",0x1f,"107" 基本固定
char cEnd; // 0x03 ,所有的 oicq 信息都已 0x03 为标记结束。
};
向目标发送一个上述的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 发送一个
回复。结构是：
struct TOicqReply
{
char Tag1; // 0x02 // 显然是 Oicq 的协议编号 or 版本，固定
char Tag2; // 0x01 // 显然是 Oicq 的协议编号 or 版本，固定
char Tag3; // 0x07
char Tag4; // 0x00
char Tag5; // 0x79
char Tag6; // 值得注意的是，此时Tag6,Tag7 不能随便了，应该添写发过来的消息中的
char Tag7; // Tag6,Tag7.
char cOicqNub[]; // Oicq 号码。 exp:123456
char cEnd; // 0x03 ,所有的 oicq 信息都已 0x03 为标记结束。
};
//--------------------------------------------------------
值得注意的是，如果此时 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 也
很难立即作出大的改动。希望腾讯公司能尽可能修复这些问题，保护好广大用户的利益。
zer9 (
[email protected])
2000-4-12 15:47 于 I S B A S E 网络安全实验室
-
附录 & FAQ：
001.exe 和 002.exe 只是作为测试使用，请不要使用在违背国家法律的地带。
001.exe 和 002.exe *只能* 使用在 Microsoft Windows2000 平台上，测试是在
Windows2000 Server & Windows2000 Adv Server 上进行的。
001.exe 的作用是向目标发送完全匿名的消息，以及测试 Oicq 的远程溢出。
同时，对于 Build: 410 的 Oicq ,你向目标发送的匿名消息，目标回复时，消息
会回到指定地点。（UPD 源地址) 如果你正好在 该地址上装有 Oicq, 就会直接显示。
exp: 已知 A: Oicq: 10000 IP: 10.0.0.1
B: Oicq: 20000 IP: 10.0.0.2
C: Oicq: 30000 IP: 10.0.0.3
A 希望冒充 B 给 C 发送消息，同时希望接受到 C 给 B 的回复。
则在 UPD 源地址中添 A 自己的 IP,目标地址添 C 的 IP,目标号码添 B 的号码，
端口不变。就可以了。
002.exe 则只能用在 Build: 220 一下版本中，主要是使对方上下线。
最后，如果测试的任何一方处于网管或 Firewall 后，都可能不会成功。
声明：我们对该程序不提供技术支持,也不提供任何的保证)
本文地址：http://com.8s8s.com/it/it3648.htm