给你一篇文章,希望对你有帮助!
前言:
Oicq 作为Inet实时通讯应该是一个不错的选择,
众多的用户群也证明了这点。(按照腾讯主页(www.tencent.com)
上的说话,截至目前,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 服务器转发。接受方
在收到消息后返回一个回应信息,发送方就是通过这个信息来确认消息是否已经收到。
消息的结构是:
(注意:本文中所有的 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 (zer9@21cn.com)
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 后,都可能不会成功。
声明:我们对该程序不提供技术支持,也不提供任何的保证)