McAfee: Enabling Malware Distribution and Fraud
McAfee, widely recognized as one of the leading providers of online security software for both home and business, appears to be struggling to secure its own Web sites, which at the time of writing this post, allow anyone with enough tech savvy to covertly do whatever they want on, and with, the site.
During tests this weekend, we discovered the company who claims to "keep you safe from identity theft, credit card fraud, spyware, spam, viruses and online scams," has several cross-site scripting (XSS) vulnerabilities and provides the bad guys with a brilliant - albeit ironic - launching pad from which to unleash their attacks.
Why a Vulnerability on a McAfee Site is of Consequence
It can't get much worse than this. This is not "yet another embarrassing incident on the Web;" not by a long shot.
Lance James, co-founder of Secure Science Corporation and author of Phishing Exposed, noted that when a criminal locates an XSS vulnerability within a well-known Anti-Virus site, it only makes the attack more effective. "It generates misplaced trust (being that computer users trust AV companies) and is paradise for miscreants involved in Scareware (Rogue Anti-Virus) distribution, as they can infect a legit copy of MacAfee's product and distribute it under their name." James said. "A win for the bad guys through the power of branding; a major loss of trust for McAfee," he added.
Not only do security vulnerabilities harm a company's brand, they can also ultimately harm its bottom line, particularly when the company in point has made millions from the software it produces to protect you online; this will surely injure the McAfee brand.
It all began when we came across a post that described some of the issues facing McAfee. Very quickly, we realized the potential for phishing on one of McAfee's sites, the McAfee Rebate Center, which allows you to inject HTML code into one of the fields it provides on its site.
If you've never seen an HTML injection in action, try this out, it's an interesting experiment.
How To: HTML Injection
- Go to the McAfee Rebate Center
- Click on Get Rebate
- Include this line of code into the 'Date Purchased' field:
- Click on continue
This is a very basic redirect that will take you to ReadWriteWeb.
And voila - you've just effected your first HTML injection.
Although our example is extremely simple; a no-brainer for clever coders, it illustrates a significant and more sinister point: McAfee is clearly vulnerable to XSS attacks. Much like the recent Mikeey worm on Twitter, this XSS issue is a result of poor output filtering. And while Twitter can be forgiven for not laying down the correct foundation in the beginning, the same cannot be said of McAfee, which has built its entire business around its knowledge and expertise in the field of information security.
McAfee Secure May be Providing Incorrect Information to Users
And it gets worse. McAfee has a product called McAfee Secure which helps corporations determine whether their sites are open to malicious attack. The way it works is that sites participating in the McAfee Secure program are checked daily, and if they pass muster, they receive a McAfee Secure badge which is branded with the day of testing.
Unfortunately, it appears McAfee either doesn't run McAfee Secure across all of its sites, or if it does, the product is missing the bleeding obvious.
From the https, to the McAfee domain, this phish site that James created even includes a valid and dated McAfee Secure certificate.
To demonstrate how easily the exploit can be used, James created a phishing site to give ReadWriteWeb readers a real-time example. Go ahead, follow this link, and click on the "add to cart" button (we promise it won't hurt you).
What you are seeing is a cross-site scripting exploit in action. "Imagine," James said, "just how easy it would be to exploit home computers with Trojans that cause harm or steal information." A phishing site, like the one he created, could easily ask you to click a link for more information. "Or," he said, "imagine the e-mail: 'you're eligible for a McAfee rebate on your products, just click here!'" "Basically, the main use I see it for is to spread malware as McAfee."
What he's describing is ominous. The bad guys can create a modified version of a McAfee product or a bogus McAfee update that installs a Trojan, or whatever they like, and it arrives on your home machine, special delivery. You'd never know.
In creating the fake site, James points out that he didn't need to spoof the McAfee Secure logo. "We're using their certificate to validate our attack," he said.
Go ahead. Look up at the URL on the phishing site. See that https://?
Secure right?
Note: We've created a screencast (embedded below) of the redirection exploit for when McAfee fixes this; we hope it's soon.
Update May 5, 2009
It appears the vulnerability on McAfee's rebate site has been fixed; however, the test phishing site is still going strong. James gave us an update: My assumption is that remote referrers are blocking it based on firewall rules but a refresh locally shows it's still vulnerable. An attacker can simply do a meta refresh to redirect to it since that scrubs referrers.
Share
Facebook
Comments
Subscribe to comments for this post OR Subscribe to comments for all ReadWriteWeb posts
I never like McAfee anyway
thanks god i moved to avg (is it good?). left mcafee 4 years ago.
Oh the windows ecosystem, always something new, always something exciting happening.
I never ceases to amaze me!
Sorry for spamming but I thought you might want to know this ... The http://www.nytimes.com/external/readwriteweb/2009/05/04/04readwriteweb-mcafee-enabling-malware-distribution-and-fr-12208.html redirects to your main page at http://www.readwriteweb.com/ on my computer.
Is it just me?
If you solved the problem, or the problem cannot be reproduced, please feel free to delete this comment.
:D
Guys, I just pressed preview and the link submitted it. Oops!
For me, this calls into question the validity of their PCI-DSS certification programs. If they cannot catch potential XSS problems with their own code, how reliable are the scanners they are using to scan their customer's servers?
No mention of any attempts to notify the vendor in this article. Does anyone know if Lance James attempted responsible disclosure on this?
They were notified before I even came to play. All I did was assist in impact demonstration, I didn't discover it.
FYI, the McAfee vulnerability is still active, apparently if you click it from the readwriteweb link above it may not work the first time, but if you refresh it comes up (referrer blocking maybe)? Alternatively, here's the direct url from TinyURL which seems to work every time. http://tinyurl.com/dmvqz9
"It can't get much worse than this" - Come on, it's just YAXSS vuln.
Yes it can and does get much worse.
I assume all of your "tests" were authorized, including your suggestion for others to try it out?
-L
Hold the phone folks... Do you all remember the problems about 12 months ago with "HackerSafe" admitting they simply don't consider XSS a high-risk defect?
This is a perfect illustration of McAfee (who honestly considers them "one of the leading providers..." anyway?) just not getting it, period.
How sad.
Funny story about how this story caused an XSS in another site, known as the New York Times:
http://www.pcworld.com/article/164321/story_on_mcafee_security_hole_triggers_another.html
I was trying to shift MCafee
Anyways I am using Avast and happy with taht
Hey. My IE8 reported for XSS. At least IE tracks it.
@3
It's nothing to do with the "windows ecosystem" you moron!
The statement "It can't get much worse than this" is indicative of the level of experience and knowledge behind this article. Remote, zero-day, code execution exploits plagued the late 1990s and early 2000s. These were real vulnerabilities having real impact, not to be confused with the petty script injection influencing a user's web experience (XSS).
Cross-site scripting is by far not the "worst it can get", not even among web application vulnerabilities. SQL injection, Remote File Inclusion and Local File Inclusion weigh in significantly higher. More over, this isn't even persistent XSS (which is considered much more dangerous than the non-persistent XSS, as was reported in McAfee's case).
Speaking from experience, XSS is barely acknowledged as anything other than a buzzword by real security experts, and is often handled as an amateur (read: easy, simple, useless in most cases) security topic. Researchers who emphasize on cross-site scripting are often ridiculed within the industry for hyping its lackluster impact.
Additionally, a great percentage of the Internet is susceptible to XSS and most cases are not exploitable beyond a PR issue. Granted this instance may mean a little more in context, as any security problem is bad PR for a security firm. However, take note that the hundred thousand other XSS cases which were discovered in various sites were not reported. The truth is, the media reacts blindly without knowing better than to trust the words of incompetent attention-hungry security researcher. The result is a misinformed public.
Don't take my word for it. Perform your own research, and compare XSS to any other vulnerability class: buffer overflows, command injection, remote file inclusion, SQL injection; cross-site scripting is insignificant. Then again, you could obsess over it along with Swine Flu or Conficker or the 100 other things that the media hypes which never materialize.
Firefox with noscript could detect the XSS attempt and will not load the cross reference script.
already fixed .. gj on article btw
How do you figure this has nothing to do with the Windows ecosystem? If this exploit is truly exploited, do you think *nix users will be the target? Just waiting for the first round of holes in the Windows 7 RC.... =x
Cliff - you're underestimation of XSS is disturbing. All those buffer overflows you discuss, specifically remote buffer overflows that affect IE, Safari & Firefox, well XSS is one of the more effective attack vectors to conduct those types of attacks on since the security industry spends its' time trying to educate computer users on what to trust on the Internet. Web 2.0 is the future, and it drives the market at this point on the Internet. Security is as strong as it's weakest link, and right now that is the desktop user that is being attacked in an effort to steal information or cause harm. Understood the statement that was made by the author seemed a bit far-reaching, I believe it was made in context to XSS and the fact that it's on a security site, not that it's the worst vulnerability in the world.
@19 have you any idea at how XSS is actually used? Yes it can be used to deliver malware, but it can also be used in Phishing Scams, something which is dependant on the User infront of the computer.
User Stupidity is independent of Operating Environment, and before you say it, yes, there are stupid *nix users
@16
Well said Cliff!
XSS_Info (Post 20),
I appreciate your pointing out how XSS is leveraged to use real exploits, and I am by no means denying this. However, you did not point out how any of the other vulnerability classes discussed in contrast to XSS may also be used to achieve the same objective (such as, SQL injection used to forge data on a site to trigger a client-side vulnerability in the browser, like those you described). These classes yield not only potential of compromise the server, but also allow an attacker to lower their standards to gain any spoils also attainable through XSS. These vulnerability classes are therefore intrinsically more potent. I retort with my earlier statement, that in comparison to any other class of vulnerabilities (even in the web category), XSS is insignificant.
Further more, each case of non-persistent XSS used in order to target a user to perform client-side exploitation would require user interaction, relying on premises which could likely be used independently of XSS to achieve the same goal. In other words, if an attacker can inject a link and ascertain that a user will pursue it, the attacker has already won the client-side exploitation game. I will agree that the user's trust of any given site may contribute in their accepting of content from it, but having said that I also return to the statement regarding the hundred thousand other (likely, trustworthy) sites which have XSS in them and were not reported. I would be willing to bet that the users whom are most susceptible to this style of exploitation (that is, relying on user-interaction) have marginal variance in the different levels of trust between security vendors and foundational software vendors (such as Microsoft, Apple, etc) or even foundational service vendors (Amazon, eBay).
Best regards,
Cliff
@Cliff & @XSS de-valuers:
"most cases are not exploitable beyond a PR issue"
1. PR has hard business value. Whether or not it is positive or negative depends on context. TJX found it positive. A security provider might find this negative.
By example -- I find them funny in my personal website, but take them very seriously in my business websites.
2. XSS escalation of privilege -- XSS is a data/function boundary exploit just like SQLi or a Buffer Overflow. What's worse -- we have no stack canaries, ASLR, or parameterization of user-tainted data to provide a "transparent" containment of attack surface, which is why you see BoFs and SQLi going away in terms of broad exploitability. XSS will be the LHF of choice when those are gone I expect.
In AV vendor sites that use ActiveX controls for remote hosted AV scanners, for example, this gives you a fairly direct and immediate way to exploit a trust relationship to take control of the local system. Users expect to have to click okay to a lot of "stuff" including installables.
Today's Threat Landscape isn't about "rooting the box" anymore. Come on. It's all about taking control of the target parser, and leveraging that to steal data, or elevate privilege to install a bot/back door on the local system. Those are two different but equally important outcomes.
My mother would consider control of her PC worse than control of a website's remote servers. She can mitigate the latter by not using their websites. She cannot clean up her own box or browser reliably.
When you show a General Counsel or a CFO how you can use an XSS to grab their personal data, or gain control of their browser, if not the file system of their Windows laptop (via things like ActiveX or trojaned binaries) they consider that *a lot worse* IMHE than finding out someone compromised the web server of a website they may occasionally visit, and chose not to visit again.
Now I do not think all websites are equal candidates for these type of attacks, to be fair. There are ephemeral, hard-to-calculate qualities like type of users, expectations, and viability of social engineering.
By example again -- my mother will install anything she is prompted to (or looks interesting) off of Yahoo and Ebay, but not so much from other sites.
In that regard there is a definite difference between an XSS and a reliable remote BoF.
And, finally: XSS are exploited in the wild. I've known folks to make physical gains without getting caught using them. Reflected & Persistent. 'nuff said.
$0.02 USD. Adjust to your liking for pending inflation.
AE,
It appears as though you should perform a little more research.
Addressing ASLR, stack canaries, and DEP: these do inhibit buffer overflow exploitation in many cases, however as demonstrated some of the very clever exploit engineers, they are not a panacea and have all been broken. (I will agree that these protections probably disable researchers whom only have skill sets strong enough to exploit XSS. Again this is considered an amateur vulnerability class in the industry.)
To correct your statement on protections, there exists MANY protection mechanisms against XSS including add-ons like NoScript for Firefox, as well as anti-XSS technologies shipped by default in newer Internet Explorer. The HTTP-Only option exists for web servers and aims to prevent cookie theft in the cases where an attacker does find XSS. There are appropriate escaping functions available in every major web application language in order to avoid XSS. There are URL white listing add-ons for web servers which to restrict submitted character sets. The list goes on and on; honestly I am saddened that your limited experience with security has rendered you more susceptible, as you have not been exposed to the available protection mechanisms. I can only recommend information resources such as Wikipedia and OWASP to help you on your way.
As far as your mother's concern over control of her PC, it would seem she has more to worry about client-side application security (proper use of ActiveX, properly audited code that is less prone to overflows, etc) than cross-site scripting. Being that with just XSS, (read: only XSS), she will not lose control of her PC unless she willingly hands it over. Unfortunately misinformation campaigns such as that given by the security researcher featured in this article certainly don't help her understand that.
Please don't confuse XSS with the remote code-execution vulnerabilities in the browser or its components. Albeit an excellent delivery mechanism to trigger these vulnerabilities, XSS is still less potent of a delivery mechanism than SQL Injection or Remote File Inclusion (please see my post above - #23), and is not what is actually being exploited. Again, I restate that if an attacker convinces a user to click a link (as they would for non-persistent XSS), its already game over as far as client-side exploitation is concerned.
Finally, with regards to "it is not about rooting the box": the Internet is fraught SQL Injection and Remote File Inclusion. I have no doubt that you have known people who have leveraged XSS, congratulations. This does not add any merit to the fact that XSS is the bottom of the barrel for skills required or gains from exploitation. Nor does it add any merit to the statement "It can't get much worse".
Best regards,
Cliff
K One - Thanks for that. No, it's not just you - I should have used an image in the first place
Anthony - That's exactly it...
Question - yes, sorry, I did ask a security expert to talk to McAfee about this before I wrote this up and was told they were aware of the issues.
Leon - I'm unsure who you think should have authorize our tests. But yes, you're right it does get worse.
Rafal - Unfortunately, a lot of people with computers still use McAfee - just ask any regular user, generally the best known are McAfee and Symantec. To me, that makes it very sad.
Atul - I'm glad to hear you're happy with Avast - maybe I"ll give it a go
Devendra - Interesting point. We noticed that late Sunday night. Both Firefox and Chrome don't pick it up, but IE did - nice one for Microsoft
Cliff - Thanks for your detailed response. Two things I wanted to mention. One, a security provider being vulnerable - to me that's shocking. Also, the entire idea behind this post was to me security more understandable by those who are unfamiliar with the jargon. I think we managed that. And sure, there are other issues that can come into play - but slowly, slowly.
ecosystem - check my comment above to Devendra - You might not like Windows, but give IE a shot - you might be pleasantly surprised.
K One - Thanks for that. No, it's not just you - I should have used an image in the first place
Anthony - That's exactly it...
Question - yes, sorry, I did ask a security expert to talk to McAfee about this before I wrote this up and was told they were aware of the issues.
Leon - I'm unsure who you think should have authorize our tests. But yes, you're right it does get worse.
Rafal - Unfortunately, a lot of people with computers still use McAfee - just ask any regular user, generally the best known are McAfee and Symantec. To me, that makes it very sad.
Atul - I'm glad to hear you're happy with Avast - maybe I"ll give it a go
Devendra - Interesting point. We noticed that late Sunday night. Both Firefox and Chrome don't pick it up, but IE did - nice one for Microsoft
Cliff - Thanks for your detailed response. Two things I wanted to mention. One, a security provider being vulnerable - to me that's shocking. Also, the entire idea behind this post was to me security more understandable by those who are unfamiliar with the jargon. I think we managed that. And sure, there are other issues that can come into play - but slowly, slowly.
ecosystem - check my comment above to Devendra - You might not like Windows, but give IE a shot - you might be pleasantly surprised.
And I was thinking of using their 'McAfee Secure' service for our ecommerce website. Hmmm, anyone know of any good alternatives?
I'm not surprised the company had XSS's. Some companies have their web developers either outsourced or pooled from outside of the main engineering groups leading to a disconnect between security on the web and their own products. Sadly, a lot of business people think 'the web is the web, who will break our site?! Who would ever target us?'
I can inform you that if you follow the "Track Rebate" button from the http://www.mcafeerebates.com/promocenter/mcafee/index.jsp page, you arrive at a page that is still XSS vulnerable.
To try it, just click "Track Rebate". In the "Enter tracking number" field, enter the following string literally:
" onchange="alert(1)
Press enter as if submitting the tracking number. If you now enter some number in the track rebate field and then leave the field, a message box appears with a 1: this is the result of injecting the onchange hander into the rebate field.
Although this is perhaps not sufficient for an attack, it does show that the site is coded sloppy, and that there is no sufficient generic mechanism in place that properly catches wrong input.
Roland Bouman
http://rpbouman.blogspot.com/
@Cliff:
It seems to me the problem with vulnerabilities like this is that they make it very easy for just about anybody to modify (part of) the content of the page.
Granted, you need to convince users to visit such a page using a link or a page that you provide. This isn't that hard though, and once you can convince them, they will be looking at a page they can't distinguish from the real thing.
I think companies have a responsibility to protect their webvisitors against these attacks, especially as it is quite easy for the site builder to prevent this alltogether.
It is nothing new that McAfee is in this sort of trouble -- remember when they packaged a trojan with their product "for the purpose of making it easier for system admins"? LOL!!!
As a web developer, these are the types of issues I was dealing with month to month. That is why I started a whole new security company that does what all others have been promising to do. The problem is that there are no ingredients listed on the box..so you don't really know what you are buying..(another words what is actually being protected and not). Lack of standards and lack of disclosure have left many people in more danger than before. A false sense of security is a very bad thing indeed.
I think it's quite interesting that when this article was syndicated to 3rd party sites, the original example code in the article executed on the client and redirected their browser. As per the comment above, this happened on the New York Times website, and many others where the article was syndicated.
If you're interested in reading more about the security concerns that open APIs and data feeds pose, you can check out the blog post I wrote on this topic, http://stratusec.com/blog/2009/05/nytimescom-danger-for-your-browser
I'm not going to defende McAfee - these kind of things should be found and fixed. However, it's prevelent across the *entire* web - there's few companies that have never been caught somehow with XSS somewhere on their web presence. There's just too many people (including non dev/security people) putting pages up.
For example...
">https://www.symantec.com/connect/endpoint-management-virtualization/forums}">alert(String.fromCharCode(88,83,83))?sym=">alert(String.fromCharCode(88,83,83))
Even better - I found the source of this disclosure - so multiple AV vendors being shown with XSS, with screenshots, etc.
http://nemesis.te-home.net/News/20090510_Vulnerabilities_in_Websites_of_6_Antivirus_Vendors.html
This just shows that you can not belive everything you read! there are many forms of XSS some are bad and other just don't matter. There are some many Hackers in the world that would love to put their name and a little dancing man on McAfee's sites. How much money did the guy that hacked the iPhone get paid?
Who wrote this. Does he know what he is talking about? things to tink of b4 you runn out to the store and buy a new AV or just stop shopping online.
Lidija Davis, were you paid by another ASV or AV company to wright this?
thank you
Some companies have their web developers either outsourced or pooled from outside of the main engineering groups leading to a disconnect between security on the web and their own products. Sadly, a lot of business people think 'the web is the web, who will break our site?! Who would ever target us?'
I got Cyberdefender and it worked great as a free scanner with spyware and trojan removal. If it finds a virus, you need the upgrade, which I got since I liked the speed and user interface of the scanner. The Cyberdefender anti-virus works great, and the paid version I got also came with 24/7 computer help line with my wife found helpful while I was away. I found out Cyberdefender is a NASDAQ company and they have a great product.
I started a whole new security company that does what all others have been promising to do. The problem is that there are no ingredients listed on the box..so you don't really know what you are buying..
Additionally, a great percentage of the Internet is susceptible to XSS and most cases are not exploitable beyond a PR issue.
It can't get much worse than this. This is not "yet another embarrassing incident on the Web;" not by a long shot.
thanks...
I never like McAfee
Never liked McAfee. Our relationship could not work out. I had demands that McAfee could not meet.
Are we entering an era where we need two separate programs to effectively control virus and malware? It seems that in trying to do both, the antivirus cokpanies are neglecting both sides. Also, these companies do these revisions every year, but they are never correct. One year it will focus on lightening the resources, that will be the selling point, then the protection goes way under. The next year, vice versa. Where is the medium? I need a new young buck to emerge and wipe these old fogies off the map..
If it finds a virus, you need the upgrade, which I got since I liked the speed and user interface of the scanner.
It is nothing new that McAfee is in this sort of trouble -- remember when they packaged a trojan with their product for the purpose of making it easier for system admin
Some companies have their web developers either outsourced or pooled from outside of the main engineering groups leading to a disconnect between security on the web and their own products. Sadly, a lot of business people think 'the web is the web, who will break our site?! Who would ever target us?'
McAfee SiteAdvisor toolbar is complete crap. That' why you can get it for free. It's notorious for false positives and false negatives!!!!
And even worse - McAfee doesn't want to do anything about those mistakenly blocked sites. It takes 3 months for them to change the status of a site back to normal. I'm a web developer and I've seen this too many times.
I strongly advise against using junky toolbars like McAfee Site Advisor.
thanks for good article. mcaffee must die
1 2 Next