Tag Archives: DOM

Why is Passive Mixed Content so serious?

One of the most important tools in web security is Transport Layer Security (TLS). It not only protects sensitive information during transit, but also verifies that the content has not been modified. The user can be confident that content delivered via HTTPS is exactly what the website sent. The user can exchange sensitive information with the website, secure in the knowledge that it won’t be altered or intercepted. However, this increase in security comes with an increased overhead cost. It is tempting to be concerned only about encryption and ignore the necessity to validate on both ends, but any resources that are called on a secure page should be similarly protected, not just the ones containing secret content.

Most web security professionals agree that active content — JavaScript, Flash, etc. — should only be sourced in via HTTPS. After all, an attacker can use a Man-in-the-Middle attack to replace non-secure content on the fly. This is clearly a security risk. Active content has access to the content of the Document Object Model (DOM), and the means to exfiltrate that data. Any attack that is possible with Cross-Site Scripting is also achievable using active mixed content.

The controversy begins when the discussion turns to passive content — images, videos, etc. It may be difficult to imagine how an attacker could inflict anything worse than mild annoyance by replacing such content. There are two attack scenarios which are commonly cited.

An unsophisticated attacker could, perhaps, damage the reputation of a company by including offensive or illegal content. However, the attack would only be effective while the attacker maintains a privileged position on the network. If the user moves to a different Wi-Fi network, the attacker is out of the loop. It would be easy to demonstrate to the press or law enforcement that the company is not responsible, so the impact would be negligible.
If a particular browser’s image parsing process is vulnerable, a highly sophisticated attacker can deliver a specially crafted, malformed file using a passive mixed content vulnerability. In this case, the delivery method is incidental, and the vulnerability lies with the client, rather than the server. This attack requires advanced intelligence about the specific target’s browser, and an un-patched or unreported vulnerability in that specific browser, so the threat is negligible.
However, there is an attack scenario that requires little technical sophistication, yet may result in a complete account takeover. First, assume the attacker has established a privileged position in the network by spoofing a public Wi-Fi access point. The attacker can now return any response to non-encrypted requests coming over the air. From this position, the attacker can return a 302 “Found” temporary redirect to a non-encrypted request for the passive content on the target site. The location header for this request is a resource under their control, configured to respond with a 401 “Unauthorized” response containing a WWW-Authenticate header with a value of Basic realm=”Please confirm your credentials.” The user’s browser will halt loading the page and display an authentication prompt. Some percentage of users will inevitably enter their credentials, which will be submitted directly to the attacker. Even worse, this attack can be automated and generalized to such a degree that an attacker could use commodity hardware to set up a fake Wi-Fi hotspot in a public place and harvest passwords from any number of sites.

Protecting against this attack is relatively simple. For users, be very suspicious of any unexpected login prompts, especially if it doesn’t look like part of the website. For developers, source in all resources using HTTPS on every secure page.

#HackerKast 40: OPM Breach, Sourcepoint, AdBlock Plus, NSA and AV software, Adobe Flash, Chrome Listens In via Computer Mic

Hey Everybody! Welcome to our 40th HackerKast! Thanks for listening as always and lets get to the news!

Our first story to chat about this week was news bubbling up still about the recent OPM breach. This time, the news outlets are latching on to the fact that data encryption wouldn’t have helped them in this case. Jeremiah poses the question “Is this true? And if so, when does it protect you?” Robert and I go back and forth a bit about layers of protection and how encryption in this regard will only help with host layer issues. Some other ideas come up about data restrictions being put upon the database queries as they are taking place so that the crown jewels can’t be stolen via one simple hole.

Next, we moved on to a story Robert was drooling over about Google’s new pet project company, Sourcepoint, which exists to stop ad blocking. Apparently they originally launched to detect when ads are being modified, which was apparently an issue in the SEO world. However, the way the tech worked, monitoring the DOM allowed them to pivot a bit to detect ad blocking by users. This could be leveraged to stop the user from blocking, or could alert the user and ask really nicely for them not to block ads which could be harming some sites’ revenue. We then all made the comparison here that the modern age of ads looks a lot like the age of Anti-Virus with the whole cat and mouse game of writing signatures to catch which domains are serving ads.

On the topic of ad blockers, AdBlock Plus added a feature which would allow enterprise level IT admins to roll out the browser plugin to an entire company. We need to remind people that AdBlock Plus also is the ad blocker on the market that will allow ads that pay them to be whitelisted. This means the more computers their software is on, the more they can ask to be whitelisted.

Jer couldn’t wait to talk about this next story about the NSA reverse engineering AV software. He starts by giving us all a quick history lesson of his interest in AV being the ironic attack vector for hackers to get into systems. The current story is about a recently leaked Snowden document that outlined an NSA program which reversed AV software — including Kaspersky — to utilize it to track and monitor users. Not a good week for Kaspersky coming off the heels of Duqu 2.0 recently.

Our transition from one virus propagator to another here brings us to our next story: Adobe Flash. The initial story that made our list was Brian Krebs talking about detoxing from Flash for 30 days with it completely removed from his system. He gives some good advice about disabling flash, removing it altogether, or enabling click to play. While editing this story though, he had to add a note at the top which proved his point that the day it was published there was an out-of-band Zero-Day patch Adobe released this week. The Zero-Day was identified by some ridiculously named FireEye report of an attack being used in Singapore from a Chinese hacking group they call APT3. We have a good conversation about Flash and what a huge target it’s been and what a nightmare it is to get users to update.

The icing on our cake to go back to ragging on Google is a story that hit the privacy community this week of Chrome listening to you via your computer microphone. For some reason, the initial group they decided to test this with was Chromium users on Debian who noticed the silent update start to log this audio information. Apparently there is some legitimate purpose behind this, like saying “Hi Google” to your computer and giving it voice commands. They then send this audio to their servers to do analysis to improve their service. They double, triple, super duper promise they aren’t logging it or sharing the audio. We went off on a tangent here on how awful of an idea this is. I brought up how we’ve got a nice diagram from the NSA showing how they strip HTTPS at the Google layer to monitor users so it really doesn’t matter if they log or store it if the NSA can just snoop on the wire there. Who knows where this is going to go, but now you might have an always on microphone in your house.

Thanks for listening! Check us out on iTunes if you want an audio only version to your phone. Subscribe Here
Join the conversation over on Twitter at #HackerKast
or write us directly @jeremiahg, @rsnake, @mattjay

Resources:

Encryption Would Not Have Helped at OPM Says DHS Official
Former Google Exec Launches Sourcepoint To Stop Ad Blockers
Adblock Plus Rolls Out Mass Deployment For IT Administrators
NSA Has Reverse-Engineered Popular Consumer Anti-Virus Software In Order To Track Users
Operation Clandestine Wolf: Adobe Flash Zero-Day
Krebs month without Adobe Flash Player
Google Chrome Listening In To Your Room Shows The Importance of Privacy Defense In Depth
Just another source on the Chrome listening to you

Notable stories this week that didn’t make the cut:

Heinz QR porn code too saucy for ketchup customer/
Critical Bug Found in Drupal OpenId
The Myth of the Dark Web
How DOJ Gagged Google over Surveillance of Wikileak’s Appelbaum
1,400 Passengers Grounded in Warsaw Due to Airport Hack
DuckDuckGo on CNBC: We’ve grown 600% since NSA surveillance news broke

It’s a DOM Event

All user input must be properly escaped and encoded to prevent cross-site scripting. While the idea of sanitizing user input is nothing new to most developers, many of them encode special characters and fail to account for how the resulting document will handle the input. HTML encoding without proper escaping can lead to malicious code execution in the DOM.

Be sure to note that all of the following descriptions and comments are dependent on how the application output encodes the related content and, therefore, may not reflect the actual injection.

 

HTML Events

HTML events serve as a method to execute client-side script when related conditions are met within the contained HTML document. User-supplied input can be encoded in the related HTML; however, when the condition of the event is met, the document will decode the injection before sending it to the javascript engine for interpretation. Consider the example below of an embedded image that evaluates “userInput” when a user clicks on the image:

<img src="CoolPic.jpg" onclick="doSomethingCool('userInput');" />

Now here’s the same image that has been hi-jacked by an attacker with an encoded payload:

<img src="CoolPic.jpg" onclick="doSomethingCool('userInput&#000000039;);sendHaxor(document.cookie);//');" />

The hacker’s injection uses HTML decimal entity encoding with multiple zeros to show support for padding. When a user interacts with the altered image, the DOM will evaluate the original function, followed by the hacker’s injection, followed by double slashes to clean up any trailing residue from the original syntax. All of the character encoding presented immediately below will work across all current browsers, with the exception of HTML name entity apostrophe in Internet Explorer.

 

Vulnerable HTML Encoding

 

Javascript HREF/SRC

When javascript is referenced in either HREF or SRC of an HTML element an attacker can achieve code injection using the same method as above, but with the additional support for URL hex encoding. The DOM will construct the related javascript location before evaluating its contents. Here’s a dynamic link that, when followed, does something “cool” with user input:

<a href="doSomethingCool('userInput');">Cool Link</a>

The hacker likes the “super-cool” link so much that he decides to add his own content to capture the user’s session:

<a href="doSomethingCool('userInput%27);sendHaxor(document.cookie);//');">Cool Link</a>

 

Remediation

The lesson to be learned here is that encoding alone may not be enough to solve cross-site scripting. Therefore, encode all special characters to prevent an attacker from breaking the resulting HTML; escape each character to prevent breaking any related javascript; and, of course, always remember to escape the escapes.

<img src="CoolPic.jpg" onclick="doSomethingCool('userInput\\\&#39;);attackerBlocked();//');" />

 
Jason Calvert @mystech7
Application Security Engineer
WhiteHat Security, Inc.