Thursday, July 11, 2013

So, Snowden let the cat out of the bag. They're listening - the news are so big, that feds are no longer welcome at DEFCON. But let's all be honest - who doesn't like to snoop into other person's secrets? We all know how to set up rogue AP and use ettercap. Setting up your own wall of sheep is trivial. I think we can safely assume - plaintext traffic is dead easy to sniff and modify.

The real deal though is in the encrypted traffic. In browser's world that means all the juicy stuff is sent over HTTPS. Though intercepting HTTPS connections is possible, we can only do it via:

hacking the CA

social engineering (install the certificate)

relying on click-through syndrome for SSL warnings

Too hard. Let's try some side channels. Let me show you how you can view all SSL encrypted data, via exploiting Amazon 1Button App installed on your victims' browsers.

The extension info

1,791,011 users (scary, becase the extension needs the following permissions):

Amazon cares for your privacy...not

First, a little info about how it abuses your privacy, in case you use it already (tldr; uninstall NOW!). There's a few interesting things going on (all of them require no user interaction and are based on default settings):

Here's exemplary Google search and a view of what's sent over the proxy.

Notice that the URL and extracted page information travels over HTTP to http://widgets.alexa.com. So in man-in-the-middle attackers can access the information that extension is configured to send to Alexa.

Bottom line - Amazon is evil.

Amazon, did you just.... really?!

The real problem though is that attackers can actively exploit described
extension features to hijack your information, e.g. get access to your
HTTPS URLs and page contents. Extension dynamically configures itself by fetching information from Amazon. Namely, upon installation (and then periodically) it requests and processes two config files. Exemplary config is presented below:

First file defines what HTTPS sites can be inspected. The second file defines URL patterns to watch for, and XPath expressions to extract content being reported back to Alexa. The files are fetched from these URLs:

Limitations

We are limited to XPath expressions to retrieve content, so I can't return the usual HTML source, nor can I access headers etc. The closest I got is string value of //html node, which is somewhat the content of all text nodes on a page

AJAX applications snooping works poorly, as the extension does not report XMLHttpRequest responses

Update: One day after the publication, Amazon did not stop tracking, but fixed the vulnerability - the config links are now served over HTTPS. Once again, full disclosure helped the common folks' security.

CSP will only protect you when something loads a script into the DOM of the page, but in this case an external script (from chrome-extension:// protocol ) is run by the browser directly and that bypasses CSP. Basically, all chrome extensions (depending on their permissions) can run scripts on pages regardless of CSP.

That's about CSP bundled with the extension (i.e. protection from XSSing the extension code itself). In this case we're only concerned with website's CSP - and that protection is simply bypassed by how Chrome extensions work.

I think it's somewhat inevitable - the whole point of extensions is to alter the way the user views & interacts with websites, and at the end of the day, that's the users choice. Perhaps the browser could warn them a little more aggressively, and perhaps the extension security model could be improved, but I'm not holding my breath.

A much worse issue in my mind is the terrible security say-OK-to-everything model in the mobile app world, and google (and apple) don't seem to be in a hurry to fix that either.

"The Amazon Browser Apps may also collect information about the websites you view, but that information is not associated with your Amazon account or identified with you."

"Well, request to https://www.amazon.com/gp/bit/apps/web/SIA/scraper?url=https://gist.github.com/ sends a lot of my Amazon cookies, doesn't it? But that's just a start."

While the data is sent to Amazon, that doesn't imply what happens on the other side. The best you can say is that Amazon *could* be logging it. but then they also might not be. It also could be that they aren't and that the cookies are used just for authentication, preventing the listener from collecting garbage data. If I did a code review on such a system, I'd point out the possibility of abuse if it were designed that way, and make sure that the cookie is used only for authentication but not stored with the data. But we just don't know what they're doing. So that's a problem, but it's overstated by the author.

"Amazon XSS-es every website you visit"

A plugin injecting a script and XSS are *not* the same thing.

"All captured HTTPS data will be in pwn.log file.""We are limited to XPath expressions to retrieve content, so I can't return the usual HTML source, nor can I access headers etc. The closest I got is string value of //html node, which is somewhat the content of all text nodes on a page"

My analysis: this isn't awesome sauce, but the post is overstating the case.

The Alexa stuff is more worrying, but you didn't discuss the Alexa AID tracking cookie in depth. Alexa being included at all is troubling because user didn't install an Alexa toolbar, they installed an Amazon toolbar.

Thanks for insightful comments, I'd like to address the points you raised:

1. Amazon being sent vs collecting data Yes, I cannot know how are they using the data, but the fact that it's accessible to them is enough for me to raise the point. I honestly don't believe that it's being only done as a mistake and the cookies are discarded. It's very sensitive data, they should design the data collection adhering to their own Privacy Policy.

2. "A plugin injecting a script and XSS are *not* the same thing."XSS is exactly that - code being injected into a benign page by an outside party (attacker). They are abusing Chrome extension infrastructure to inject the code (so they don't need a vulnerability in a website), and the code can be tailored to the user & the exact site. XSS payload does not have to be malicious. Alert(1) is also a totally harmful code, just like an empty function() that they run. But they're actively injecting it, performing an XSS attack on all websites (apart from CSP-protected site, but that's another story)

3. "All captured HTTPS data will be in pwn.log file." vs XPath data. That might be confusing as you pointed out. Not to overstate the issue though, I clearly describe & demo what is actually captured. What I meant is "all _captured_ HTTPS data", not "all HTTPS data". Still, even the limited dataset leaked is a huge deal for me and contains a lot information that could be used in further, targetted attacks.