在过去的十年里,世界上已经有数以百万计的人在电脑上装了杀毒软件。在本文中,我们针对世界上Top 9杀软公司的网站里攻克下了8个,成功实现了XSS的利用。
前言
现如今的杀软已经非常成熟,还拥有了针对ransomware、间谍软件、木马、后门、蠕虫和rootkits等攻击的保护手段。
我们针对世界上Top 9杀软公司的网站里攻克下了8个,成功实现了XSS的利用。此外,下文会根据漏洞发现的难度和严重程度,对其进行评级,评级模型如下:
Severity: ⅖
Difficulty: ⅘ |
而在报告给厂商后,我们还有个厂商响应评级供用户参考:
Speed: ⅖
Interest: ⅘ |
下面我们进入正题,我们将分析一下每个触发弹窗的POC,并按困难程度进行排序:
各厂商XSS漏洞大合集
BitDefender(比特梵德)
影响域名:lv2.bitdefender.com
上面提到的这个子站,受影响的点在网站404页面,在路径处直接加上攻击向量(如
<script>alert(document.domain)</script>),就可以轻松进行XSS攻击。
评级:
Severity: ⅖
Difficulty: ⅕ |
这个Severity评级是因为其与主域名共享了cookie,所以影响力是较大的。但是因为没有做XSS防护,所以Difficulty评级较低。
最终Payload如下:
https://lv2.bitdefender.com/<script>alert(document.domain)</script> |
卡巴斯基
影响域名:kids.kaspersky.com
该子站的url里,其中age参数没有进行保护,加上攻击向量“>
评级:
Severity: ⅖
Difficulty: ⅕ |
由于卡巴斯基这个子站也是跟主站共享cookie,而且也没有加防护,所以它跟BitDefender的XSS评分差不多。
最终Payload如下:
https://kids.kaspersky.com/?age=”><svg/onload=alert(domain)> |
Panda Security(熊猫安全)
影响域名:download.pandasecurity.com
该子站影响在参数url上,在页面返回了三次,有两次在<h1>之间出现,还有一次出现在脚本内容(<script>标签)里。因为参数值并没有被编码或者转义,所以我们有两个选择。第一种就是用<svg onload=alert(domain)>用HTML标签注入payload。另一个选择是突破参数字符串的值,用-alert(document.domain)-进行利用,我们这里选择了第二种方式,因为固有的兼容性和简短性。
评级:
Severity: ⅗
Difficulty: ⅖ |
这个Severity评级是由于cookie都没采用HttpOnly,所以带来了一定的风险,漏洞页面采用了403返回信息。
最终的payload:
http://download.pandasecurity.com/cav/eng/malicious/?url=”-alert(document.domain)-“ |
小编批注:
可能有人会有点疑惑这里是如何触发的,我不会告诉你们某人傻气地跟我争论了半天(完全是毫无意义的好么!),下面放一张图,大家可能会看得明白一点:
影响域名:search.avira.com
这个子站某个GET参数“gct”的值在返回页面出现了6次,但是其中有一个没有进行转义和加密,存在于一个脚本内容里,至于另外5处则是没有问题的。
最后我们再次选择了上面那个带减号的payload:
评级:
Severity: ⅗
Difficulty: ⅗ |
这里Severity评级与Panda Security的网站类似,包括PHPSESSID在内都可以被黑客所取到,而Difficulty评级则是因为寻找漏洞页面费了点劲儿。
最终的payload:
http://search.avira.com/?gct=’-alert(document.domain)-‘ |
AVG
影响域名:toolbar.avg.com
这个站的漏洞与前面四个都不同,其默认使用了微软的asp.net的默认过滤器,如果A-Z或a-z字符后跟了<,会被网站判定为XSS攻击。该web应用在GET参数“op”和“pid处,里面的值被设置为div标签的class值,我们这里采用的是onmouseenter事件。
评级:
Severity: ⅖
Difficulty: ⅘ |
很可惜,这里的cookie采用了cookie保护,启用了HttpOnly选项,所以Severity评级并不高。
不过这里的Difficulty评级还是比较客观的,主要有以下原因。第一,受影响的页面不太好找,费了点时间。第二,ASP.NET自带的XSS过滤器还是很恶心的,增加了测试的难度。
我们只有一条路,突破class限制而不是div,那就需要用到JS事件句柄了。遗憾的是,常用的onmouseover事件被某WAF拦住了,我们只好换成了onmouseenter。然而,这坑爹的WAF还把“(”给ban掉了,不过最后还是让我们用HTML编码(给绕过了。
http://toolbar.avg.com/almost-done?op=”onmouseenter=”alert%26lpar;document.domain)
http://toolbar.avg.com/almost-done?pid=”onmouseenter=”alert%26lpar;document.domain) |
Symantec(赛门铁克)
影响域名:library.symantec.com
该域名不同于此前其他案例,因为这个XSS是存储型的。Symantec并没有把代码放在该子站,而是采用了其他公司开发的某平台(Getty Images)。该存储型XSS影响了该子站的应用Lightboxes,它可以让用户创建自己的lightbox并与其他用户分享。
该漏洞存在于lightbox的name处:它的name出现在脚本内容里,而且没有做处理,所以就造成了一个严重的XSS攻击。自然而然,我们这里仍然选择了上面的那个payload。
评级:
Severity:5/5
Difficulty: ⅘ |
该XSS漏洞在Severity评级达到顶级,是考虑了以下三个因素。第一,该XSS是存储型的影响力实在不小,还可能用作蠕虫。第二,就是这些cookie都没有采取任何保护措施。
最后还有一点,CSRF的token还是明文存在于页面的代码里。综上所述,黑客可以很容易取得其他用户的权限的。
至于Difficulty的评级是给花在寻找漏洞网站和漏洞点的时间上的,检查多个输入点和创建多个测试账户进行交互测试还是很费劲的。
这里的payload还是”-alert(document.domain)-”。
McAfee(迈克菲)
影响域名:
|
这里四个字站都受影响的原因,是因为他们都采用了同一套代码。受漏洞影响的GET参数term,在页面中出现了4次,其中3次都进行了编码,而还有一次进行单引号转义(因为在单引号之中)。
这里我们采用了一个非常有意思的payload,我们接着看:
评级:
Severity: ⅖
Difficulty:5/5 |
这里的Severity评级是因为cookie是受保护的,而与此同时我们试图触发alert(document.domain)时,也遇到了很多困难。
第一个难点,我们由于单引号的过滤,用不了’-alert(document.domain)-’这类的payload了。
因此,我们尝试用事件句柄去注入HTML标签,绕过了这点。
第二个问题则是注入了HTML标签后,我们还是不能用alert(document.domain)。在这里“(”也被ban掉了。我们如果加上反引号(`) 则是可以弹窗的,但是弹出的是“document.domain”,而不是真实的网站域名。
我们尝试用(取替换“(”,结果返回了500页面。然后我们尝试加了“#”,这个标志符号通常能让我们加上额外的文本内容,而且不会被服务端所解析(只有客户端的属性location.hash会解析)。
我们这里来看看location based payloads,这里使用了javascript 协议,利用document.location属性来改变URL的导向。
不幸的是,我们没能使用下面的payload:
</script><svg/onload=location=”javascript:alert”+location.hash>#(document.domain) |
因为location.hash回显的是#(document.domain),而不是(document.domain)。我们不能使用substr()或者slice()函数,因为他们也使用了括号。
为了绕过这一点,我们使用了HTML元素的innerHTML属性,这会返回当前元素闭合和开放的标签内的文本内容。我们可以创建下面的payload:
</script><svg/onload=location=”javascript:”+innerHTML+location.hash>”#”-alert(document.domain) |
上面的payload改变了页面里的document.location,转为javascript:”#”-alert(document.domain)。这里#因为包含在引号里,所以被解析为字符串,同样能触发弹窗。
最终payload:
https://service.mcafee.com/webcenter/portal/cp/home/faq?term=</script><svg/id=javascript:+onload=location=id%2binnerHTML%2blocation.hash>”&mode=search#”-alert(document.domain)
https://att.mcafee.com/webcenter/portal/cp/home/faq?term=</script><svg/id=javascript:+onload=location=id%2binnerHTML%2blocation.hash>”&mode=search#”-alert(document.domain) https://verizon.mcafee.com/webcenter/portal/cp/home/faq?term=</script><svg/id=javascript:+onload=location=id%2binnerHTML%2blocation.hash>”&mode=search#”-alert(document.domain) |
相关内容在这里。
ESET
影响域名:www.eset.com
这里的XSS漏洞是通过GET参数q触发的,也就是查询关键词的内容。这是第三方厂商开发的一款名为TYPO3的CMS,我们发现了其中的XSS漏洞。
评级:
Severity: ⅕
Difficulty: 5/5 |
这里的Severity评级是由于cookie设置了保护,但是需要用户交互才能触发。
而Difficulty设置的高评级,是因为我们花了许多时间寻找其他子站的XSS漏洞,然后才想到了去判定网站指纹,看看是否存在公开XSS漏洞。
接着,我们发现该网站采用了TYPO3的CMS,我们开始去Fuzz这个CMS的过滤器。后来,我们发现了Github上,该CMS放置了一些单元测试脚本,我们终于弄明白了过滤器的细节。
该CMS使用了黑名单来拦截事件句柄,如onclick之类的会被替换成on<x>click。而javascript:会被替换成ja<x>vascript:。与此同时,尖角符号也会被编码。我们尝试了javascript:来代替javascript:然后成功了。还有,我们也用( 和)代替了小括号。
在返回页面里输入内容出现了两次,一个在<strong>标签里,另一个在<input>标签的value值里。在该CMS里尖括号被HTML编码后,我们只有考虑向<input>标签里注入事件句柄和属性。
幸运的是,HTML5有了一个新的属性,也就是<input>标签可以调用的formaction。我们可以用它设置<form>里的action属性的值,<input>也在其影响之中。即使<input>标签里的action已经设置了值,我们还是可以覆盖里面action的参数值。
结合type属性使用上面提到的属性,我们可以将<input>转换为一个button,将document.location设置为“javascript:alert(document.domain)”。
最终的payload:
https://www.eset.com/us/search/?q=1″type=image formaction=javascript%26colon;%26lpar;document.domain%26rpar;+1 |
在本节中,我们将杀软厂商的漏洞响应进行了评级,评级方式与前面大致相同。我们初始提交漏洞给各厂商时都是在1月27日,直到90天后我们才发布了这篇报告。
各厂商响应情况
BitDefender
我们在1月31日和3月1日分别给它发了消息,而在第三封消息后,他们才向我们要了漏洞细节。我们发现在此前他们已经修复了漏洞,但却没有给我们回信。
后来他们在4月12日声明这问题早已有人报告过,而且修复了(在我们发了初始报告之后的时间内修复的),所以并没有给我们奖金。
评级:
Speed: ⅕
Interest: ⅕ |
卡巴斯基
我们在发送初始报告消息后,在27分钟后就收到了厂商的回复,是诸厂商中最快的。
在2月4日漏洞被确认,我们检查了下漏洞已经被修复。我们在那天又发了消息给卡巴斯基,他们表示正在等待安全团队的消息。然而至今为止,还是没有下文。
评级:
Speed: 5/5
Interest: ⅘ |
PandaSecurity
我们在给Panda Security发送初始报告后,还发过一封消息。在1月31日后,他们回复已经知晓了漏洞,并且在2月1日进行了修复,是厂商里最重视漏洞的。
评级:
Speed: ⅘
Interest:5/5 |
Avira
在发送初始报告后,我们曾通过他们的推特账户进行联系。他们给了我们一个email地址,似乎是很重视他们的互联网用户安全的。
我们在2月2日向他们给的email地址,发送了该漏洞的POC。后来,我们又分别在2月8日、20日和27日也发送了消息,但是直到本文发布还是没收到任何回应。
然而,我们发现至少在4月21日以前该漏洞就已经被修复。但厂商没有表示任何形式的感谢,甚至根本不回复我们消息。
评级:
Speed: ⅕
Interest: ⅕ |
AVG
AVG在我们初始报告两天后回复了我们,然后又在回复消息后10天内修复了该漏洞。为此,他们还奖励了我们一件T恤和一份感谢信。
Speed: ⅘
Interest: ⅘ |
Symantec
Symantec在我们发出第二封消息(1月31日)后进行了回复,我们在2月2日发送了POC。直到我们又发了三封消息(2月8日、22日、27日)后,才确认了这个漏洞。他们表示已经联系了该平台的厂商,等待修复完成。
不过直到发文之时,该漏洞仍然没有修复。
评级:
Speed: ⅕
Interest: ⅕ |
McAfee
我们尝试了各种方式联系McAfee,支持中心、推特账户,虽然他们最后还是回复了我们。后来,在2月4日我们给厂商发送了POC。但是,直到本文发布该漏洞仍然未修复。
评级:
Speed: ⅕
Interest: ⅕ |
ESET
ESET在我们发送初始报告47分钟后就回复了,算是厂商中回复第二快的。在我们发送POC之前的当天(晚上9:57前),漏洞就已经被修复,不过此前我们已经将利用结果的截图发过去了。为此,ESET还给我们发了一封正式的感谢函。
评级:
Speed:5/5
Interest:5/5 |
Avast
Avast是我们唯一没有发现XSS漏洞的厂商,但并不意味着他们并没有这样的漏洞。毕竟这个测试项目,我们只花了一周的时间来做。但是这也许也象征着他们的WEB安全方面强于竞争对手,我们最后对他们的团队表示衷心的敬佩和祝贺。
本文来源于互联网:如何用XSS“干掉”90%的顶级杀软厂商