0x00 背景
某个周末的下午，终端安全团队小伙伴们在海边团建烤着肉喝着酒的时候，TSRC漏洞报告邮箱收到趋势科技的同学发来的漏洞报告，报告中提到了手机QQ音乐使用的第三库libupnp也存在类似虫洞（WormHole）的漏洞。小伙伴们放下了正在进行的活动，立即同TSRC团队启动了对这个漏洞的应急响应流程。
整个过程还算顺利，产品团队迅速发布新版本修复了漏洞——手机QQ音乐就像在虫洞里逛了一圈有惊无险的回到了原地。
趋势科技安全团队秉承了对用户负责任的精神，给了我们足够的时间来修复问题，同时也在技术上为我们提供了帮助，在此我们对趋势科技表示感谢与敬意。
0x01 漏洞处理时间线
2015年11月14日 16：20，收到LeoZhang@TrendMicro关于手机QQ音乐引入的第三库libupnp存在“虫洞”漏洞的报告；
2015年11月14日 20：00，完成漏洞确认，将漏洞细节和修复方案同步给QQ音乐开发团队；
2015年11月14日 23：00，QQ音乐开发团队完成漏洞修复并验证修复ok，启动新版本发布流程；
2015年11月19日，手机QQ音乐发布升级版本5.7.1.5（趋势的文章中误为24日）；
2015年12月3日，趋势科技博客发布关于libupnp漏洞的技术细节；
2015年12月7日，TSRC博客发布本文。
0x02 漏洞成因
手机QQ音乐为了实现局域网内便捷播放的功能，使用了业界广泛采用的UPnP架构，而UPnP能力的构建直接使用了开源的第三方库libupnp。导致漏洞的地方在QQ音乐最初在2012年4月使用了libupnp v1.6.17版本以后，并未及时保持这个库版本的更新，而把这个版本中存在的已知漏洞（CVE-2012-5958 – CVE-2012-5965），一直带到了现在的现网版本。
0x03 原理简析
这些CVE所指向的关键漏洞，是一个教科书式的栈溢出漏洞。我们来简单看下这个漏洞的原理。
代码：upnp/src/ssdp/ssdp_server.c@480
至此，strncpy中，目标缓冲区是固定的栈内容，源缓冲区来自网络，拷贝长度网络可控，一个教科书式的栈溢出由此形成。标准的漏洞，修复方案也很标准，对n的长度进行限制，确保不会超出栈缓冲区的范围。
代码：upnp/src/ssdp/ssdp_server.c@479
这个经典的strncpy函数导致的漏洞，相信做漏洞挖掘的同学一定不会陌生。实际上，同样是在2012年某个版本的QQ影音，几乎一模一样的栈溢出漏洞。不过在基于Java或者OBJ-C编写的移动APP中，栈溢出攻击虽然未消亡，但黄金年代已经一去不复返了。
0x04 攻击场景
这个漏洞刚爆出的时候，考虑到2012年PC或者服务器操作系统中漏洞缓解机制远不如今天成熟，所以这个漏洞的利用难度很低：通过简单的栈溢出覆盖返回地址，配合一些关键函数的定位技巧，远程代码执行并不是一件困难的事情。这个从metasploit中的exploit/multi/upnp/libupnp_ssdp_overflow模块中的大量硬编码地址也能看出一些端倪。
但现在当我们回过头来考虑在Android上的栈溢出利用时，会突然发现已经完全不是当年的情况。Android 4.0以后版本引入的ASLR，配合上NX保护，在不考虑这些安全机制本身漏洞的情况下，想完成一次远程代码执行攻击变得困难了许多。其中最难的部分是在ASLR的环境中，shellcode难以预测完成代码执行时所需的关键系统函数的地址，一般需要一个额外的远程信息泄漏漏洞的配合。获取到信息泄漏漏洞后，ROP链的构造，exploit的稳定性，也都不是一件轻松的事情。我们也在Android 5.0上实际尝试了这个漏洞的利用，可惜最终只能完成远程拒绝服务攻击。
目前我们也没有捕获到利用这个漏洞对用户进行的实际的攻击的情况。
0x05 举一反三
10月份百度的虫洞漏洞，让安全圈子在这两个月没有闲着。
从最开始的虫洞，到随后各种SDK产品的类似问题，再到我们对腾讯自身产品的排查，UDP端口的攻击场景一直被大家所忽略。我们可以看到，趋势科技安全团队对漏洞进行了更为细致深入的分析。
其实UPnP在我们的日常生活中应用广泛，其中最主要的使用场景有两个：内网穿NAT和视频音频播放。在现在所谓的“智能”电视，智能手机大范围使用的年代，相信大家应该都听说过DLNA吧？
DLNA构建在UPnP的基础上，通过UPnP实现视频、音频、控制设备的互联，那么必不可少需要开放的UDP 1900端口。
经过分析，我们发现不少具备DLNA能力的音视频APP、智能电视、智能音箱甚至是一些具备互联能力的汽车，都直接开放了UDP 1900端口，而这些端口背后，通过旧版本libupnp库来实现UPnP能力的也不在少数（我们也将发现的问题通知了受影响厂商）。除了趋势科技小伙伴们提到的高难度远程代码执行攻击，结合DLNA的多媒体特性，其实会有更多令人背脊发凉的攻击场景。
想象一下，半夜在卧室睡觉的时候电视突然来了一段《午夜凶铃》，在你随身携带的智能音箱中加入一些影响情绪的低频干扰，在你开着车听着音乐的时候突然一阵车祸现场刹车撞击的声音，你会是什么感受？你是否还能安全的看电视、听音乐或者开车？你是否还能安全的享受智能家居生活？
0x06 给我们的启示
这个漏洞对于产品的启示是：如果产品使用到第三方库，应该及时升级到最新版，避免旧版本出现安全问题。一个很典型的案例就是Android的WebView控件使用的旧版Chromuim，引入了很多的历史漏洞，Android的碎片化又导致很多手机没法升级，带来较大安全隐患。
安全团队应该对所负责产品使用的第三方库这个做一个监控，维护好这个基础数据，以便及时化解安全风险。这个事件也是对我们的一个教训，团队也在反思为何会漏掉了libupnp。
0x07 后记
最后，再次感谢趋势科技对腾讯安全的帮助。也诚邀广大安全专家跟我们一起来保护广大互联网用户，通过我们的漏洞报告平台http://security.tencent.com或者邮箱security@tencent.com反馈的问题都有专人跟进，你除了获得不菲的奖励外还有我们全体同仁的友谊。
最后请允许我自夸一下，大家要对腾讯产品和业务的安全质量有信心，如你所见，任何时候我们都会竭尽全力提升我们的产品和业务的安全质量（此段转载可删除）。
0x08 涉及链接
1）比葫芦娃还可怕的百度全系APP SDK漏洞 - WormHole虫洞漏洞分析报告，
http://drops.wooyun.org/papers/10061
2）High-Profile Mobile Apps At Risk Due toThree-Year-Old Vulnerability，
http://blog.trendmicro.com/trendlabs-security-intelligence/high-profile-mobile-apps-at-risk-due-to-three-year-old-vulnerability/
3）Serious, YetPatched Flaw Exposes 6.1 Million IoT, Mobile Devices to Remote Code Execution，
http://thehackernews.com/2015/12/iot-mobile-security.html
4）libupnp，http://pupnp.sourceforge.net/
5）http://sourceforge.net/p/pupnp/code/ci/2bb79879b77dd215a26c92d1348adf2ae406dfd8/
8）Metasploit exploit/multi/upnp/libupnp_ssdp_overflow
https://www.rapid7.com/db/modules/exploit/multi/upnp/libupnp_ssdp_overflow
9）http://www.symantec.com/connect/articles/microsoft-upnp-universal-plug-and-play-vulnerability
10）UPnP，https://tools.ietf.org/html/rfc6970
捐款成功，感谢您的无私奉献
评论留言