Google - Mixed-Content Security Bugs

10:46 AM

Mixed-Content is one of the most common mistakes in web applications; developers often miss fixing it. Thus, being a common target for bounty hunters. The idea is very easy to understand, like its name it is a mixed content between HTTP and HTTPS. What that means could be an https page including a script, image, CSS or anything (executable) from an http domain or vice versa.
 
How is including a script, image or CSS from a non-secure (http) domain harmful? Basically, one way, Man in the middle (MiTM) attacks. As we know ARP/DNS Spoofing, in MiTM essentially are ways of making the victim’s machine think our spoofed ip is the one matching the one the victim is requesting. This means, if the victim requests http://google.com and http://google.com have 1.2.3.4 IP. If we spoof the DNS responder, gateway’s IP to ours and respond google.com have 5.6.7.8 Ip (our ip pretending to have a similar page to google.com) the victim won’t notice the difference since the address bar is google.com and we can steal data, in some cases Login credentials.

In HTTPS connection, MiTM is not possible because we can’t read, modify and write in the victims HTTP request/responses because it’s encrypted. That however won’t apply if the HTTPS site is embedding a script, image or css from a non secure (http) domain (very probable).

Example: Say google.com (https) is embedding a script from site.com/jquery.js (http), say site.com have an IP of 6.7.8.9 now we spoof the address to our IP, so when the victim browser request site.com a wrong DNS entry (our IP) will be responded to them, thus the victim will instead be accessing our site.com. Now we host jquery.js on our server so when google.com(https) requests site.com/jquery.js (our controlled server in local gateway), we instead be sending our malicious Jquery.js, this js can modify anything on the page the victim is viewing. Access cookies, modify data, practically like an XSS.

But if the victim is embedding image from insecure source, what is the worst this can do? Well, we can make the image/favicon/logo big enough to say something the page normally won’t say, like, “this server has moved to an external service for security reasons, please temporarily access https://hacker.phising.com” and make a legit (seeming) attempt to capture credentials.
Embedding css files can actually be as worse as embedding scripts (js, vb…) with some requirement from browser manipulation. Since CSS can also include Javascript, this is also worse for most (modern) browsers.

So Mixed Content Bugs are basically like XSS for a local attacker. They are bad. Vice versa, if we are on http domain and sending form values (username, password, anything sensitive) to HTTPS domain, this can still be captured because the request is made with unencrypted connection.
This is what exactly happened in Google. I find https://google.com/friendconnect trying to embed scripts & images from http domain. Thus letting us manipulate the whole Google.com content, read some cookies.

The attack scenario at Google would be to spoof the IP of http://netlog.com (google’s script host) to our IP. And when https://google.com/friendconnect tries <script src=” http://netlog.com/somescript.js”></script> we instead be delivering them a modified js to do malicious things to *.google.com domains. An XSS if you may.

This wasn't fairly enough for a reward but Google offered me a spot in their Honorable Hall Of Fame Page.

Conclusion:


-           Mixing content is extremely bad if you take your website security seriously and can ease access for local attackers to takeover accounts (if you don’t use HttpOnly and Secure Cookies), perform operations (steal money, send message).

-          Simply make sure every include you make is internal and try to put your needed files in a relative location (src=”/file.js”) instead of requesting it externally.

You Might Also Like

1 comments