What on earth do these two things have to do with each other? Well before I can discuss that, I need to dig out another forgotten vulnerability, mixed scripting!
Mixed scripting happens when an application served via https references resources including CSS,XML,JS from domains that are not served via https so a typical example would look like this:
So why is this a problem? well because it means in a Man in the middle attack you can influence the behaviour of a trusted domain without mirroring the entire domain! You can have your victim---during a mitm attack---use the services on their trusted domain with out having to use sslstrip or other anit-ssl tech you don't need to touch anything on the ssl layer because the application inherently serves unauthenticated content to the user! All you really need to accomplish is mapping the unauthenticated domain to a machine under your control.
So then how does this tie into the Google Web Cache? It turns out google webcache also suffers from mixed scripting!
This may not seem like such grave news, you may want to know why this is unwanted behaviour?
Well I rate this as something dangerous not because I could demonstrate an autonomous way to exploit peoples trust in this domain to do very very harmful things, but because I know if I have an idea, then people much much more intelligent than me will have some ideas of there own!
The baseline argument motivating the critical nature of this vulnerability would be the trust that people have in this particular domain. I can only imagine how many XSS filters out there have Google web cache on some whitelist, I mean come on its Google after all! My conclusion is that this behaviour is a total fail!
Thats not the end of my story!
As it turns out Google Search has a peculiar behaviour that would go nicely with this vulnerability. If you've been following this blog for a while you may recall another post about google web cache and how you can have google.com autonomously redirect to webcache using a very special search term.
that post is over here
So the long and short of it is, if you feed someone a link that looks like this
So now putting this all together, what it means is if you are MITM-ing someone and you'd like to take control of some browser-based information or even take control of your victim's browser, all you need to is feed them a link like the one above and then do a little DNS poisoning or DNS spoofing---via an arpspoofing attack, or any attack that gateways a Man in the middle---so can associate unauthenticated resources with domain you control. I feel I need to summerize this:
Mixed scripting happens when an application served via https references resources including CSS,XML,JS from domains that are not served via https so a typical example would look like this:
 |
| googleusercontent mixed scripting vulnerability |
So why is this a problem? well because it means in a Man in the middle attack you can influence the behaviour of a trusted domain without mirroring the entire domain! You can have your victim---during a mitm attack---use the services on their trusted domain with out having to use sslstrip or other anit-ssl tech you don't need to touch anything on the ssl layer because the application inherently serves unauthenticated content to the user! All you really need to accomplish is mapping the unauthenticated domain to a machine under your control.
So then how does this tie into the Google Web Cache? It turns out google webcache also suffers from mixed scripting!
 |
| Pics or it didn't happen right? |
Well I rate this as something dangerous not because I could demonstrate an autonomous way to exploit peoples trust in this domain to do very very harmful things, but because I know if I have an idea, then people much much more intelligent than me will have some ideas of there own!
The baseline argument motivating the critical nature of this vulnerability would be the trust that people have in this particular domain. I can only imagine how many XSS filters out there have Google web cache on some whitelist, I mean come on its Google after all! My conclusion is that this behaviour is a total fail!
Thats not the end of my story!
As it turns out Google Search has a peculiar behaviour that would go nicely with this vulnerability. If you've been following this blog for a while you may recall another post about google web cache and how you can have google.com autonomously redirect to webcache using a very special search term.
that post is over here
So the long and short of it is, if you feed someone a link that looks like this
https://www.google.com/search?q=cache:k3170makan.blogspot.comYou get redirected to webcache autonomously!
So now putting this all together, what it means is if you are MITM-ing someone and you'd like to take control of some browser-based information or even take control of your victim's browser, all you need to is feed them a link like the one above and then do a little DNS poisoning or DNS spoofing---via an arpspoofing attack, or any attack that gateways a Man in the middle---so can associate unauthenticated resources with domain you control. I feel I need to summerize this:
- DNS spoof/poison so you can have "http://trustme.com/something.js" under your control, all you need is one resource thats what makes it so sneaky
- Perform a man in the middle attack---the above step can be encompassed into this one ;)---
- Feed the vicitim a link like this:
- https://www.google.com/search?q=cache:[a domain that references "http://trustme.com/something.js"]
Comments
Post a Comment