当前位置：WooYun >> 漏洞信息

漏洞概要 关注数(24) 关注此漏洞

缺陷编号：wooyun-2015-0156430

漏洞标题：从一个“无标题”邮件到QQ邮箱服务器文件下载（运行日志、附件等）

相关厂商：腾讯

漏洞作者： gainover

提交时间：2015-11-27 19:19

修复时间：2016-01-14 10:46

公开时间：2016-01-14 10:46

漏洞类型：任意文件遍历/下载

危害等级：高

自评Rank：20

漏洞状态：厂商已经确认

漏洞来源： http://www.wooyun.org，如有疑问或需要帮助请联系 [email protected]

Tags标签： 无

4人收藏 收藏
分享漏洞：

漏洞详情

披露状态：

2015-11-27： 细节已通知厂商并且等待厂商处理中
2015-11-30： 厂商已经确认，细节仅向厂商公开
2015-12-10： 细节向核心白帽子及相关领域专家公开
2015-12-20： 细节向普通白帽子公开
2015-12-30： 细节向实习白帽子公开
2016-01-14： 细节向公众公开

简要描述：

前些天使用QQ邮箱，看见有一朋友快过生日的提醒，于是给自己发了一个贺卡，结果不知道是哪里误操作，导致自己收到了一封“无标题”也无“发件人”的邮件，接着，就开始了下面的旅程。

详细说明：

1. 首先，是我的误操作，导致发送了一个“无标题”也没有发件人的“贺卡”。看来是QQ邮箱后端处理出现问题了，正好当时开着抓包软件，就开始分析了。
今天已经无法重新这个发“无标题”邮件的操作了，结合后文所述，应该是被修复了。
还好我留了一封，截图做纪念：

1.jpg


2. 为了找到导致这个BUG的原因，我先将邮件正文替换为aaaa，发现邮件恢复正常，于是局部删除邮件内容，
最后删除到只剩下以下内容时，出现了奇怪的情况。

/cgi-bin/viewfile?f=13233D0948115D858519BF93BD54FF886202F13BF853330C64A28B5A1AF42AA3BBA42274B655A284D586A6E0A6F8E89A52EB57A9F990FED871606D2C2EA2B9B679646DF7AC74F0AF50FE438B43BA3FD12FD061B11B1B92BEE0AD80C1EC0B5BF38F7D0367D413E52C76E676B9EBBFD13C&sid=3"


收到的邮件内容，竟然是下面这个：

2.png


我了个去，这是爆路径了么？
3. 继续测试，看看这里是怎么回事,在f参数末尾再加一些AAAAAA：

/cgi-bin/viewfile?f=13233D0948115D858519BF93BD54FF886202F13BF853330C64A28B5A1AF42AA3BBA42274B655A284D586A6E0A6F8E89A52EB57A9F990FED871606D2C2EA2B9B679646DF7AC74F0AF50FE438B43BA3FD12FD061B11B1B92BEE0AD80C1EC0B5BF38F7D0367D413E52C76E676B9EBBFD13CAAAAAAAAAAAA&sid=3"


返回的内容变成了下面的（没有截图了）
/data//80/QQ号码/groupattach/postcard201511231423453JSakETkjg1fBARS.jp乱码乱码乱码"
4. 经过分析得知，这里的 f参数的内容13233D0948115D858519BF93BD54FF886202F13BF853330C64A28B5A1AF42AA3BBA42274B655A284D586A6E0A6F8E89A52EB57A9F990FED871606D2C2EA2B9B679646DF7AC74F0AF50FE438B43BA3FD12FD061B11B1B92BEE0AD80C1EC0B5BF38F7D0367D413E52C76E676B9EBBFD13C 就是/data//80/QQ号码/groupattach/postcard201511231423453JSakETkjg1fBARS.jpg 加密后的内容，
当我们把末尾加上AAAAAAAA后，服务器会认为AAAA也是程序的路径，于是也进行解密，从而得到乱码。
传入更长的AAAAA之后，可以发现，每16个A被解码为8个字符，反之，就是每8个字符为一组进行加密，得到一个16字符的大写字符串，推测可能是ECB模式的DES加密。
---------------------------------------------------------
5. 如果我们可以得到 ../../../../../../../etc/passwd 的加密串，那么是不是可以通过viewfile接口下载 passwd文件了呢？
然而，虽然我们可以得到一些密文与明文，但是是不大可能破解这个算法的。
我们是否可以找到一些接口，传入一些明文内容，来得到正向的加密串呢？
有意思的是，发现这个问题的同时，我还发现了另外一个“看起来并没有什么用的”链接。

3.png


6. 看到链接里那么一长串大写字符串时，我就想啊，这个会不会也是同一个加密算法加密的，于是发一封邮件试一试。
/cgi-bin/viewfile?f=B7F3991201E485FEEE27031F724A14F8B779A0FC4F5792143CB767E2EF4B3DA3BFDB6E7B65D642E9CF5D037A1ADE3492&sid=3"
上面链接里的一长串就是链接里的一长串，
结果发现，果然被成功解密了。

4.png


7. 可以看到，B7F3991201E485FEEE27031F724A14F8B779A0FC4F5792143CB767E2EF4B3DA3BFDB6E7B65D642E9CF5D037A1ADE3492 解密后的内容的串是由3部分组成:
QQ号码 & 收件人@126.com; &postcard&1448280990
QQ号码是发信人的，不能改，否则不能正常发送，
收件人这里，我们是否可控呢？
于是进行以下尝试，

5.png


将一个收件人设置为正常邮箱，另外收件人的邮箱设置为我们所需的路径字符串。
并且，由于加密是每8个字符进行的，我们需要按照以下的方式来构造收件人：

6.png


构造好发件人之后，我们还需要在邮件内容里加上 #{direct_sendcard_url}#，服务器端会将这个指令，替换为 包含收件人加密串的URL，

111.jpg


最终测试成功，我们可以成功得到加密后的串。

B7F3991201E485FE2E0014A1553847D07F72928DCFE6A4ECB36E568D8400A4F5B44F4E6E5CB0A4CCBB0CC8200C8C6CEF6367DC612E4BC3B45E8CA3F8B72B32AF702E95FFDCCC8DE300DA7994E641E46D1FA319F6424BF6D8


8. 去掉前面的64个字符，因为前面64个字符是 “QQ号码&收件人1号@126.com;//”的加密内容，
去掉末尾的64个字符，末尾的64个字符是“@163.com;&postcard&1448280990”的加密内容，
于是，得到：
B44F4E6E5CB0A4CCBB0CC8200C8C6CEF6367DC612E4BC3B4
我们访问：
https://set2.mail.qq.com/cgi-bin/viewfile?f=B44F4E6E5CB0A4CCBB0CC8200C8C6CEF6367DC612E4BC3B4&mailid=ZL3127-3JRtOe0Vqil%7EZmYwRRSAB5b&sid=XXXXXXXXXX【SID】XXXXXX&net=931323402

7.png


9. 既然可以读/etc/passwd，那么我们是否可以读到其它的, 于是，我们还尝试读取了 /home/qspace/.bash_history，然而并不存在，试了好几次，都不存在。
10. 经过测试，我们又发现 rsyncd.conf 也存在，并且里面存在WEB路径。

8.png


11. 可激动了。。马上就去试，看看 /home/qspace/QQMail/WEB目录/cgi-bin/是否存在，然而并不存在。。。
继续测试，发现/home/qspace/QQMail也不存在。。。
奇怪了。
纠结了许久，发现， 前述的接口，发件人的地方，会进行一次小写的转换，然后再加密，也就是说，我们最终得到的是 /home/qspace/qqmail 而非 /home/qspace/QQMail
12. 然后呢，我就继续找其它接口，寄希望于找到一个接口，可以得到允许大写的路径，弄了2天，并没有找到什么，即使中间找到了一个点，可以生成任意文件名的加密串，与上一个接口不同的是，这个接口是文件名，所以不能包含 / ，但是由于QQMail是6个长度，我们即使得到QQMail的加密串，实际上得到的是 QQMail+2个padding的加密内容，当我们想访问
/home/qspace/QQMail/WEB目录的时候，其实我们只能得到
/home/qspace/QQMail【2个0x03的padding】/WEB目录 的加密串，这样并不能访问。
13. 今天准备放弃了，就用找到的接口做最后的挣扎，
首先，用收集的已知信息和linux下的常用文件名，路径名之类的准备一个小字典，只有130多条左右。

9.png


然后写了一个JS脚本，挨个测试 /home/qspace/字典内容 是否存在，
前面好像并没有发现什么信息，但是直到最后一条的时候，。。。。
/home/qspace/.bash_history 竟然奇迹般存在了，马上下载内容回来看看。

1.png


14. - -，然后呢，看到了奇葩的一幕，这个管理员登录到服务器后，首先查看了服务器日志，在日志里查看IP为10.222.*(这台Mail的IP段)的记录，接着又开始看错误日志，并且grep了一个QQ号码。。。并且这个QQ号码，就是我测试用的小号！！！！

10.png


后面还有其它的命令也在grep我的小号。
15. 我推测，应该是我前些天的测试，导致QQ邮箱后端出现了某些BUG？
然后服务器管理员上来找原因来了？
然后，就留下了.bash_history
16. 他这么一看，显然就把日志的目录、文件名信息全部暴露给我了。
于是下载了一个运行日志，和一个错误日志（部分）
/home/qspace/log/********112715.log
/home/qspace/log/error/********112715.log
这里面存在一些信息，比如：
他人的cookie信息，服务器重要配置文件的路径，他人的附件路径等。
比如我自己测试小号的cookie就在其中，

11.png


17. 里面还会存在一些他人的附件路径，这些附件路径中也存在大写字母，那么我们是否可以下载别人的附件呢？
比如路径是这样的：
/home/qspace/data/webmailcache//179/他人QQ号码/ZL2303-ROarGPbI~DmvW2o_GOA4I57_Attach/babd406fadb5fc53f2e8e595cddb27e0
和上面说的QQMail有点不一样的地方是，我们可以将路径分为3个部分加密：
/home/qspace/data/webmailcache//179/他人QQ号码/ <--全部小写可以得到
ZL2303-ROarGPbI~DmvW2o_GOA4I57_A <-- 虽然包含大写，但是32个字符，8的整数倍，可以通过另外一个文件名的接口来加密获得。
ttach/babd406fadb5fc53f2e8e595cddb27e0 <--全部小写可以得到，
最终，我们可以得到3个加密串，然后拼接在一起。

6529F33AD830402BFB0DF3A711FE868689A7790DD41F8F365B6F15F348D2FBE28548F1183CB3766F1AB41D9FFA578C17FAFDE1B79BE66A492945A1D63EF0A2515B4B7799C164183BBF4D7380C5275D617E03ED2088CAE432C93B82E82F3FCC3F78FEC605301CACC1960BB628A8C55123D6A0E41DFBBD1D0495E3DEE452E92EFB0FCB23BFDEEE2744


用viewfile访问：

2.png


最后可以看到，这个人的附件是一张图片，是一个可爱的小狗。

adsada.png


18. 最终，我们还是没能够拿到cgi的内容，不过过程还是挺有意思的。

漏洞证明：

如上。

修复方案：

1. 整个过程是在发自定义明信片的时候测试的，
具体请求为：https://set2.mail.qq.com/cgi-bin/compose_send?sid=
参数如下图所示：

12.png


这个是会意外解密出路径的明文的BUG的位置，此外bcc处的收件人允许 ../../之类的
2. 泄漏明文加密的是在上述请求里添加 #{direct_sendcard_url}#，
3. viewfile 这里解密后的路径，过滤 ../ 之流，防止跨目录读取。
4. 文章还提到一处可以获取明文加密串的请求是：
https://set2.mail.qq.com/cgi-bin/bottle_opr
自行考虑对文件名参数进行判断。

版权声明：转载请注明来源 gainover@乌云

漏洞回应

厂商回应：

危害等级：高

漏洞Rank：15

确认时间：2015-11-30 10:44

厂商回复：

非常感谢您的报告，问题已着手处理，感谢大家对腾讯业务安全的关注。如果您有任何疑问，欢迎反馈，我们会有专人跟进处理。

最新状态：

暂无