在过去的十年里，世界上已经有数以百万计的人在电脑上装了杀毒软件。 在本文中，我们针对世界上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参数没有进行保护，加上攻击向量“><svg/onload=alert(domain)>”，就可以进行XSS攻击。

评级：

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)-"

• 小编批注：

可能有人会有点疑惑这里是如何触发的，我不会告诉你们某人傻气地跟我争论了半天（完全是毫无意义的好么！），下面放一张图，大家可能会看得明白一点：

• Avira（小红伞）

影响域名：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编码&lpar;给绕过了。

最终的payload：

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”，而不是真实的网站域名。

我们尝试用&lpar;取替换“(”，结果返回了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)

https://truekey.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&colon;来代替javascript:然后成功了。还有，我们也用&lpar; 和&rpar;代替了小括号。

在返回页面里输入内容出现了两次，一个在<strong>标签里，另一个在<input>标签的value值里。在该CMS里尖括号被HTML编码后，我们只有考虑向<input>标签里注入事件句柄和属性。

幸运的是，HTML5有了一个新的属性，也就是<input>标签可以调用的formaction。我们可以用它设置<form>里的action属性的值，<input>也在其影响之中。即使<input>标签里的action已经设置了值，我们还是可以覆盖里面 action 的参数值。

结合type属性使用上面提到的属性，我们可以将<input>转换为一个button，将document.location设置为“javascript&colon;alert&lpar;document.domain&rpar;”。

最终的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安全方面强于竞争对手，我们最后对他们的团队表示衷心的敬佩和祝贺。

 *参考来源： brutelogic ，FB小编dawner编译，转载请注明来自FreeBuf黑客与极客（FreeBuf.COM）