WormHole分析第二弹
0x00 背景
最近WormHole这个洞炒的比较火，今天看了几篇漏洞分析文章，都很详尽，笔者在这里再补充一些发现。
笔者在10月初就发现了百度地图的这个漏洞，并报给了BSRC得到确认，但与瘦蛟舞，蒸米等研究人员出发点不同，笔者并没有从SDK的角度出发去发掘出更多的使用moplus这个库的app，而是从功能性的角度出发，以地图类应用作为切入点，尝试去发现一些问题。虽说没有发现那么多存在漏洞的app，但好在也有一些发现。
0x01 百度地图
Wormhole的漏洞报告出来后，很多圈内人士针对“后门还是漏洞”的问题产生了激烈的讨论，微博、知乎上各种声音。
一个事物的出现必然有他的原因，一个应用为什么要在手机上开放一个端口呢？百度地图为什么在修复漏洞依然还开着40310这个端口？可见这个端口存在自然有其存在道理，于是开始进一步分析。
用Chrome模拟手机（Nexus 5）访问7b6K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4N6%4N6#2)9J5k6h3u0S2K9h3c8#2i4K6u0W2j5$3!0E0，在请求包里明显看到有访问fb6K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8U0p5J5y4#2)9J5k6e0m8Q4x3X3f1H3i4K6u0W2x3g2)9K6b7e0b7H3x3K6p5H3i4K6u0r3k6$3g2@1M7$3g2S2M7X3y4Z5j5X3!0^5K9h3&6X3L8#2)9K6c8Y4S2^5P5s2S2^5P5s2R3`.的数据包，心中一惊，这不就是wormhole的一个利用么？
难道百度开放一个端口就是为了能在web网页里访问一下？一次偶然的发现，访问搜狗网址导航也出现了6baK9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8U0p5J5y4#2)9J5k6e0m8Q4x3X3f1H3i4K6u0W2x3g2)9K6b7e0b7H3x3K6p5H3i4K6u0r3k6$3g2@1j5%4g2A6k6q4)9K6c8Y4S2^5P5s2S2^5P5s2R3`.之类的数据包，看来除了百度还有其他的地方在“利用这个漏洞”。
几番试验，笔者又在模拟手机在其他几个网站发现了同样现象，莫非这些网站都知道这个漏洞？几番研究后，最终锁定了源头——百度统计。
百度统计的脚本是hm.js，而hm.js加载了一个html: 5a4K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8X3u0G2M7$3y4V1L8W2)9J5k6h3u0H3j5#2)9J5k6h3u0S2K9h3c8#2i4K6u0W2j5$3!0E0i4K6u0r3N6U0q4Q4x3V1k6Z5L8$3I4E0k6i4y4Q4x3X3c8E0L8%4m8D9N6i4y4Q4x3V1k6E0M7q4)9J5k6r3y4V1L8W2)9J5k6h3S2@1L8h3H3`.
这个html又加载了一个js: 4d1K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4y4@1j5i4c8A6j5K6q4Q4x3X3g2K6k6h3q4J5j5$3S2T1L8%4S2Q4x3X3g2T1j5h3W2V1N6g2)9J5k6h3y4G2L8g2)9J5c8Y4y4@1j5i4c8A6j5#2)9J5c8Y4y4W2j5i4u0U0K9r3u0G2P5q4)9J5c8X3!0H3k6h3&6B7M7#2)9J5c8X3#2H3i4K6u0W2K9Y4x3`.
就是这个js中一段代码发出了对本地端口的请求，查看代码不难发现，该脚本对6259和40310这两个端口都发出了请求，这也正好印证了wormhole漏洞为啥固定开辟了这两个端口。
综上，不难发现百度开放6259和40310是为了百度统计服务的，但目前发现的情况也只是getcuid、getsearchboxinfo之类一些简单的信息，至于为什么在这个接口上实现获取所有安装包信息、写通讯录、任意上传下载文件等就不得而知了。但毋庸置疑，想要利用这些接口只需在百度统计脚本里加几行代码就可以了，只是现在未发现利用的证据。所以，至于是漏洞还是后门，笔者不作评价。
0x02 高德地图
仔细看上边百度的分析，不难得出结论，一个应用开放一个端口，本质上是为了web页面和app本身达到某种交互。既然百度地图有问题，那么其他地图类应用呢？
笔者先前看到乌云上有一个关于高德地图的漏洞c15K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4N6G2L8%4W2#2L8W2)9J5k6h3!0J5k6#2)9J5c8X3u0#2k6%4y4Q4x3V1k6%4L8$3!0&6N6h3&6Q4x3X3b7J5x3o6p5#2i4K6u0V1x3o6p5I4y4o6t1@1x3b7`.`.，原理和百度这个漏洞类似，也是开放了一个6677端口，那么高德是怎么修复这个洞的呢？
研究发现高德采用验证http_referer的方法，对比之前的漏洞发现高德把http_referer白名单由java层放到了native层
在验证http_referer时，高德竟然用了contains()这个函数去遍历，简直暴力啊
由此可见高德的修复并不彻底，一是contains()很容易被逻辑绕过，二是http_referer很容易伪造，当然高德地图的最新版本又做了一些改动，但不管怎么样修复，高德还是保留着6677这个端口。
这不禁令人生疑，究竟这个端口有什么用？在高德未修复漏洞时，笔者开发了一个exp，发现这个漏洞可以得到用户的位置信息。
我们仍然用Chrome模拟手机进行测试，访问232K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8X3q4E0j5i4m8Q4x3X3g2U0L8$3@1`.，发现了对本地6677端口的请求，其目的是为了获取用户的地理位置信息。
0x03 思考
Wormhole究竟该如何定义？
显然出现这种类型漏洞的不仅仅是百度系app，也不止是moplus这个SDK，笔者认为wormhole应重新定义为那些因开放端口导致的漏洞。
另外，目前列出的一些wormhole影响列表只是用了简单的静态扫描去匹配moplus的特征，事实上部分app仅仅是包含了这个库但没有实现，需要动态运行验证。
怎样做到安全的开放端口？
验证http_referer、remote-addr等显然不可靠
端口随机？如何保证web页能确切访问？（facebook安卓版）
SSLSocket?
Web页面和app之间有必要通信么？
开放端口不同于传统的client-server结构，传统的server端是透明的，但app上实现的server容易被逆向出关键逻辑，最终通信机制还是会被破解。
Web页用一个token去访问app，app拿这个token进行服务器验证，然后再判断是否把敏感数据返回给web页？
如何批量的检测这种开放端口的漏洞？
静态检测ServerSocket等API? 部分app只是包含了一些API，但是没有到该部分代码的执行路径。
动态检测？部分app在特定情况下才会开放端口，如豌豆荚在插入USB后才会开放端口。
Wormhole之后还有很多地方值得我们挖掘和研究，微博：m4bln，欢迎交流探讨！