CyLab Chronicles
Q&A with Collin Jackson
posted by Richard Power
"It turns out that some ad networks will let you run whatever JavaScript or Flash movie you want in the ad, so exposing a victim to an exploit is quite cheap (less than one cent per impression) and it doesn't even matter whether the victim clicks the ad."
CyLab Chronicles: The story of your experiment in running a "Flash Ad" is a fascinating one. And what the data revealed offers a meaningful insight into the type of door to door, alley to alley battle going on in the shadow realm of cyber security. Briefly, recount what you did and what the numbers looked like.
Collin Jackson: We wanted to determine how powerful web advertising networks could be in the hands of an attacker. In our experiment, we tested a DNS rebinding exploit for Flash Player, which can be used for sending spam as well as reading private data inside your network. It turns out that some ad networks will let you run whatever JavaScript or Flash movie you want in the ad, so exposing a victim to an exploit is quite cheap (less than one cent per impression) and it doesn't even matter whether the victim clicks the ad. Due to timing and version differences, our experimental exploit worked about half the time, and many of the visitors had the ad open for several days so we had a lot of computers under our control. Of course, we didn't harm the victims in any way, but if we were an actual attacker this method of hijacking machines would compare favorably to the cost of renting a botnet for sending spam. It's also convenient for the attacker since the ad network keeps coming up with fresh victim IP addresses that are unlikely to be blacklisted for spam.
We worked with Adobe to get the vulnerability fixed in the latest version of Flash Player. However, it's only a matter of time before new vulnerabilities are found, and it takes a long time before everyone updates to the latest version. I think ad networks will remain a potential platform for attacks unless steps are taken to control the content that can be displayed in ads. On the plus side, ad networks are also a great platform for web security research, because I can use them to measure browser security policies from a large sample of users.
CyLab Chronicles: Tell us about Cross-Site Request Forgery (CSRF) attacks. What is lacking in current defenses? What issues are you exploring in your research?
Jackson: In a CSRF attack, a malicious site instructs a
victim’s browser to send a network request to an honest site, such as
your bank. The bank site is confused into accepting the request,
because it doesn't know that the request came from the malicious site.
This allows the malicious site to make changes to your bank account,
such as initiating a transfer.
There a few different defenses for CSRF attacks, but none of them are
really satisfactory. The HTTP "Referer" header reveals the source of
the requests, but it's often blocked for privacy. You can set custom
headers that can't be spoofed, but this only works for sites that are
using cutting-edge AJAX techniques for everything and are limited to a
single domain. Finally, there are secret token approaches, which are
hard to use and often miss certain types of attacks.
One solution we've been exploring is combining the Referer header with
browser encryption to reduce the likelihood that privacy blocking will
occur. We've also been working on a new "Origin" header that has better
privacy properties than the Referer header, so it's less likely to be
blocked. The Origin header has been deployed in Safari and Google
Chrome.
CyLab Chronicles: Tell us a little bit about Frame Isolation and Frame Communication. What did you find lacking in frame navigation policy? How do you address cross-window and same window attacks? What problem does your secure protocol for fragment identifier messaging address? What did you fix in the new postMessage() API?
Jackson: Frames allow you to compose together several HTML documents on a single page. They're a nice way to isolate third-party content, but there needs to be a security policy to decide who can decide who can navigate a frame (i.e. who cause the frame to display a new document). For example, Google puts their login form in a frame, so an attacker who navigates that frame can show you a spoofed login form and steal your Google password. The browser needs to prevent the attacker from navigating that login frame. We examined the frame navigation policies of the existing browsers and found that they were all over the map -- there wasn't a consensus among the vendors what the policy should be. So we worked together with web standards bodies to deploy a consistent policy that prevents these attacks. You can now only navigate a child frame if it's a descendant of a frame you control.
We also looked at the effect of frame navigation on client-side messaging protocols that sites can use to communicate with each other through your browser. Malicious navigation could be used to compromise the authentication of the fragment identifier messaging, and it could be used to compromise the confidentiality of the newer postMessage API. We made some tweaks to those protocols to harden them against unexpected navigation.
CyLab Chronicles: In regard to your current browser research, the Web application platform is, as you say, ubiquitous, interactive, easy to update and powerful. I would add it is also something that has evolved swiftly and spread pervasively, and is, because of the features you mention, both irresistible and unstoppable. But, of course, this is technology and technology is always a two-edged sword. So tell us about the two categories of threats you are looking at, i.e., malicious servers and network attacks.
Jackson: One of the reasons the Web has been so successful is
that it allows you to safely interact with web applications written by
anyone — even someone they do not fully trust. The availability of
cheap web hosting and advertising has made it easier than ever for
malicious servers to get introduced to victims, and the browser is
largely what keeps those attackers at arms length. For example, a web
site you visit shouldn't be able to make unauthorized changes to your
computer or read your private data. There's a lot of engineering effort
that goes into browsers to make sure that your local system is
protected from web sites you visit, and that the blog site you're
viewing in one tab isn't able to access the bank site you've got
running in another tab. But there is still plenty of room for
improvement, and new vulnerabilities are discovered every day.
Besides protecting you from malicious web sites, browsers are also
responsible for keeping you safe from network attackers. When you're
using the wireless network at Starbucks, for example, someone nearby
might try to listen in on your web traffic or even hijack your session.
Browser encryption (HTTPS) is supposed to protect against these types
of attacks, but it's hardly ever used. Even worse, if you go to a web
site that appears to be using no encryption, there's no way to tell
whether the web site owner is being negligent or there's someone
listening in. There are also a number of security problems with sites
that do go the extra mile and turn on encryption. I've been working on
tools to try to make it easier to use correctly.
CyLab Chronicles: How do you assess the commercial or communal impact of your research? Is there a measure of the impact?
Jackson: It's easy to come up with new ideas for web security, but getting them deployed is another story. If the proposal breaks existing web functionality, users won't be able to browse to their favorite sites and browser vendors will be reluctant to adopt the proposal. This is why it's so important to assess the compatibility impact of changes to browser security policies. It's also helpful to get the proposal reviewed by one of the web standards working groups to ensure that all the browser vendors are on board and they will implement it the same way. We went through this process to change postMessage and the browser frame navigation policy, for example, and I'm happy to say that our proposals were adopted by all the major vendors.
Collin Jackson is an assistant research professor at CyLab and INI.
He is based at the Carnegie Mellon Silicon Valley campus. His research
focuses on the security of browsers and web applications.