|
![]() | 作者: wojiaokl1 [wojiaokl1]
![]() |
登录 |
本帖由 [NightColor] 从 << 网络集成
>> 转移而来 OICQ安全问题 前言: Oicq 作为Inet实时通讯应该是一个不错的选择,其众多的用户群也证明了这点。(按照腾讯 主页(www.tencent.com)上的说话,截至目前,Oicq 用户已经突破 450 万,而且以每天300 00的速度增加)在安全问题日益突出的今天,一个如此*广泛使用*的产品不去考虑安全方面 的问题,显然是不明智的。而且这个考虑应该是在产品规划阶段就提上日程的。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 Floo d,注意的是,此时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 的地址也会更新。在 Oi cq 的所有消息传送过程中,除了上线和下线时向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 后,都可能不会成功。声明:我们对该程序不提供技术支持,也不提供任何 的保证) FAQ:1. 我如何得到对方的 的 IP地址?如果你知道了他的 oicq 号码,搜索加为好友,然后 可以得到。最快的方法是向他发送一条消息,然后 Sniff 一下发出的 Udp 包。 Larkin转载自绿色兵团 [此贴被 菜鸟阿纱……(wojiaokl1) 在 01月03日15时08分 编辑过] |
地主 发表时间: 04-01-03 11:13 |
![]() | 回复: xiaokai [xiaokai] ![]() |
登录 |
什么年代的东西?
http://210.34.18.39/~cyq/ |
B1层 发表时间: 04-01-03 23:15 |
![]() | 回复: zybzc [zybzc] ![]() |
登录 |
太老了``郁闷得 转载也得看日期啊 |
B2层 发表时间: 04-01-04 13:01 |
|
20CN网络安全小组版权所有
Copyright © 2000-2010 20CN Security Group. All Rights Reserved.
论坛程序编写:NetDemon
粤ICP备05087286号