Last week at CanSecWest, Alex Sotirov and Mike Zusman showed how extended validity (EV) certificates don't really provide much additional help to securing a site with SSL. To sum-up a couple of their conclusions:
1. It's not hard to get a regular cert for an interesting domain.
2. An EV-certified site can load data from any other SSL-encrypted locations, regardless of the cert.
3. Rogue cert + MITM + EV-site = arbitrary attack code execution on EV-site.
It seems to me that the problem is rooted in a slight but pervasive misunderstanding of what EV certs do: they provide a more rigorous check to ensure that the entity serving data through the EV certified channel is actually who they claim to be. They don't currently give proof to a site's visitor that the site has not been compromised.
Having said that, if an attacker can prey on the way the site serves content, it doesn't matter whether or not the EV entity is actually who they claim to be; an attacker can just piggyback on their session, serving some cleverly crafted data with a rogue cert. This can be done by playing man in the middle with third-party content embedded on the EV site, or by playing tricks with the browser's cache.
Easy fix: In order to display the green bar (EV badging) require all the stuff on a web page to be served with the same EV cert. This is not attractive for many reasons, including ad syndication and distributed content serving -- both highly desirable uses may cross the fully-qualified domain border and thus require non-EV certs or multiple different EV certs. (EV certs are not allowed to have wildcard domain matching, so any difference in domain name will cause the cert to be invalid).
A more desirable fix, in my opinion, will take a look at the problem from a base level and figure out why EV breaks in these mixed-content or mixed-cert scenarios--then fix EV. The EV cert says "trust my subject at domain.com." What we really need is a way to say "trust this site."
More to come.
Cheers to Sotirov and Zusman for this excellent discovery and PoC man-in-the-middle script.
Wednesday, March 25, 2009
Tuesday, March 10, 2009
where should web policies be enforced?
I've been spending a lot of time thinking about context-based security decisions lately. These are decisions made on behalf of a website (or its users) in order to maintain data integrity and secrecy. Take for instance the issues of CSRF and Clickjacking; both of these attacks involve some sort of contextual manipulation. CSRF is a HTTP request generated by an untrustworthy source and Clickjacking is data theft by overlaying forms (etc).
There are many approaches to stop these things... but on whose shoulders should the policy enforcement lie? Should a web browser be in charge of making sites safe, or should it just be an enabler that provides enough information to a server so it can make appropriate decisions?
CSRF can be stopped by the browser, but in a fairly convoluted way. It's tough for a web browser to discern which requests will cause a significant transaction on the web server. For example, the simple request
could be enough to trash someone's account on a server. Even some POST requests don't cause internal state changes (imagine a currency conversion calculator or a POST-based language translator form). It seems a bit easier to stop CSRF on the server where the application itself can decide whether or not to trust each request. This requires the browser, however, to provide some information about the request such as where it came from (but HTTP-Referrer is not reliable) or how it came (such as whether it was from an image tag, etc).
Clickjacking is more easily approached on the client side. One approach is to make an impenetrable fence around certain special frames where any outer/parent frames can't layer stuff on top of their children. This frame-firewall approach is not always attractive, so maybe there should be some mechanism that allows the server to say "hey, this is sensitive, don't overlay this content I'm serving." Then again, maybe it would be ideal to just tell the server a bit about where the content will be rendered, and let the server decide whether or not to serve data.
But what both Clickjacking and CSRF have in common is that they leverage contextual blindness that many web applications have -- they're not aware of where requests come from or where there responses end up.
It seems clear that we can't rely on just a browser-side or server-side fix for these types of things, and instead we need to have some sort of cooperation. The question remains, however, who should do the bulk of the enforcement. I'm currently leaning towards using the browser as a context-revealing tool and leaving enforcement and policy decisions up to the server, but there's many times when that's not enough to stop client-side attacks.
There are many approaches to stop these things... but on whose shoulders should the policy enforcement lie? Should a web browser be in charge of making sites safe, or should it just be an enabler that provides enough information to a server so it can make appropriate decisions?
CSRF can be stopped by the browser, but in a fairly convoluted way. It's tough for a web browser to discern which requests will cause a significant transaction on the web server. For example, the simple request
GET /profile/deleteme.do
could be enough to trash someone's account on a server. Even some POST requests don't cause internal state changes (imagine a currency conversion calculator or a POST-based language translator form). It seems a bit easier to stop CSRF on the server where the application itself can decide whether or not to trust each request. This requires the browser, however, to provide some information about the request such as where it came from (but HTTP-Referrer is not reliable) or how it came (such as whether it was from an image tag, etc).
Clickjacking is more easily approached on the client side. One approach is to make an impenetrable fence around certain special frames where any outer/parent frames can't layer stuff on top of their children. This frame-firewall approach is not always attractive, so maybe there should be some mechanism that allows the server to say "hey, this is sensitive, don't overlay this content I'm serving." Then again, maybe it would be ideal to just tell the server a bit about where the content will be rendered, and let the server decide whether or not to serve data.
But what both Clickjacking and CSRF have in common is that they leverage contextual blindness that many web applications have -- they're not aware of where requests come from or where there responses end up.
It seems clear that we can't rely on just a browser-side or server-side fix for these types of things, and instead we need to have some sort of cooperation. The question remains, however, who should do the bulk of the enforcement. I'm currently leaning towards using the browser as a context-revealing tool and leaving enforcement and policy decisions up to the server, but there's many times when that's not enough to stop client-side attacks.
Wednesday, February 25, 2009
career move
I have been trying to keep this blog fairly technical, but since I haven't posted anything in a while and I've more or less changed my main focus, I figure it is relevant to post an update.
Recently I completed my Ph.D. and took a position at Mozilla Corporation. I'm going to be working on the security team there to protect the internets. Eventually I'll get back into the groove of posting relevant information to this blog (since I'll keep my focus in the security/computing realm) but it might take me a while to ramp up. In the meantime, thanks to all those nice folks at Mozilla who have been helpful with my move.
Recently I completed my Ph.D. and took a position at Mozilla Corporation. I'm going to be working on the security team there to protect the internets. Eventually I'll get back into the groove of posting relevant information to this blog (since I'll keep my focus in the security/computing realm) but it might take me a while to ramp up. In the meantime, thanks to all those nice folks at Mozilla who have been helpful with my move.
Thursday, October 02, 2008
lappy goes down
Yesterday my laptop's hard drive made some funny noises, so I shut the sucker down, and guess what? It wouldn't come back up.
I replaced the drive with a 250GB one (bigger and cheaper than an exact "Death Star" replacement from an Apple dealer), then restored from TimeMachine backup (pretty slick, actually), and am now trying to figure out what is broken.
Other than that, time machine saved my butt. Now to recreate the last week's worth of work, and to convince myself to do daily backups instead of weekly ones.
I replaced the drive with a 250GB one (bigger and cheaper than an exact "Death Star" replacement from an Apple dealer), then restored from TimeMachine backup (pretty slick, actually), and am now trying to figure out what is broken.
- Fink stopped working, but probably due to me being stupid (found an error in a config file, and easily fixed Fink)
- Had to reinstall developer tools.
- Needed to perform software update twice before mail worked
Other than that, time machine saved my butt. Now to recreate the last week's worth of work, and to convince myself to do daily backups instead of weekly ones.
Saturday, March 22, 2008
Monday, March 10, 2008
iphone's ambiguous http-auth
I'm a little disappointed at Apple. While I think the iPhone is a pretty nice piece of work and their browser is pretty nice too, I don't like the way it handles HTTP-AUTH. (There are other gripes I have, like no "find" feature in safari or the mail app, but we'll stick with a security problem for now). Most browsers are kind enough to display on the "safe" pop-up login box which which website requested the authentication. This is not so with iPhone Safari.
Not only does the pop-up "enter your password" box fill the whole screen (a rather necessary evil), but it doesn't display the domain, URL or any information about the website where you're sending your credentials. If I had some free time, I would hack together a quick demo to show how, using iframes (suitably) or images, I can make you think you're logging into one site but you are actually sending your password to another one entirely. It does indicate whether you are sending your password in the clear or if the connection is secured with TLS/SSL, but in a subtle gray font under the login boxes.
I want to know where my password goes!
Tuesday, January 22, 2008
Drive-by pharming (really) exists!
According to my colleague at Symantec, Drive-By Pharming has been spotted in the wild.
Maybe this indicates that attackers read academic papers?
I presented our paper (finally) in China last December. It was pretty fun...
Maybe this indicates that attackers read academic papers?
I presented our paper (finally) in China last December. It was pretty fun...
Wednesday, December 12, 2007
battery woes
I'm traveling right now and I am taking along my teeny little 12" PowerBook which has been good to me for many years. Only, this time, I upgraded it to Leopard and I think it messed up my battery stuff. (Also, upgrading may not have been a good idea since Leopard heavily uses CoreImage, and this computer doesn't support it. The 12-incher is also the minimum specs for the OS: 867MHz, 640MB RAM, 32MB GeForce 4MX video).
I noticed that it goes to sleep quickly -- say when the battery was drained less than half -- and it charges quickly. This lead me to believe it might be a power management issue, so I rebooted the machine and reset the PMU and PRAM. No luck. Still problems. I decided to "condition" the battery, or drain it all the way and charge it again, but I planned to monitor the battery status with pmset (a mac os x command line utility). Here's it's output:
Notice how it drops into sleep at 88%, and the perceived status drops to zero... I think either this battery is toast, or Leopard destroyed it. (I verified the full/empty statuses by pushing the meter button on the battery itself, watching the LEDs tell me how full it is.)
Anyhow, I'm going to let it try to charge all night, even though it will surely give up. Maybe the Internets will tell me what's going on, or maybe I'll just use it as a portable desktop computer. I'll follow this post up with results from pmset while charging to see what it tells me.
Here's some info from system profiler about the battery as it begins charging:
I noticed that it goes to sleep quickly -- say when the battery was drained less than half -- and it charges quickly. This lead me to believe it might be a power management issue, so I rebooted the machine and reset the PMU and PRAM. No luck. Still problems. I decided to "condition" the battery, or drain it all the way and charge it again, but I planned to monitor the battery status with pmset (a mac os x command line utility). Here's it's output:
sid-stamms-powerbook-g4-12:~ sidstamm$ pmset -g pslog
pmset is in logging mode now. Hit ctrl-c to exit.
12/12/07 4:57:20 AM GMT-05:00
Currently drawing from 'Battery Power'
-InternalBattery-0 98%; discharging; 10:00 remaining
12/12/07 4:57:24 AM GMT-05:00
-InternalBattery-0 97%; discharging; 10:00 remaining
12/12/07 5:05:05 AM GMT-05:00
-InternalBattery-0 96%; discharging; 10:00 remaining
12/12/07 5:14:44 AM GMT-05:00
-InternalBattery-0 95%; discharging; 10:00 remaining
12/12/07 5:25:30 AM GMT-05:00
-InternalBattery-0 94%; discharging; 10:00 remaining
12/12/07 5:34:33 AM GMT-05:00
-InternalBattery-0 93%; discharging; 10:00 remaining
12/12/07 5:45:17 AM GMT-05:00
-InternalBattery-0 92%; discharging; 10:00 remaining
12/12/07 5:54:55 AM GMT-05:00
-InternalBattery-0 91%; discharging; 10:00 remaining
12/12/07 6:03:09 AM GMT-05:00
-InternalBattery-0 90%; discharging; 10:00 remaining
12/12/07 6:11:24 AM GMT-05:00
-InternalBattery-0 89%; discharging; 10:00 remaining
12/12/07 6:19:20 AM GMT-05:00
-InternalBattery-0 88%; discharging; 10:00 remaining
12/12/07 6:20:08 AM GMT-05:00 Sleeping...
12/12/07 6:20:08 AM GMT-05:00
-InternalBattery-0 0%; discharging; 0:00 remaining
Notice how it drops into sleep at 88%, and the perceived status drops to zero... I think either this battery is toast, or Leopard destroyed it. (I verified the full/empty statuses by pushing the meter button on the battery itself, watching the LEDs tell me how full it is.)
Anyhow, I'm going to let it try to charge all night, even though it will surely give up. Maybe the Internets will tell me what's going on, or maybe I'll just use it as a portable desktop computer. I'll follow this post up with results from pmset while charging to see what it tells me.
Here's some info from system profiler about the battery as it begins charging:
Battery Information:
Charge Information:
Charge remaining (mAh): 177
Charging: Yes
Full charge capacity (mAh): 20494
Health Information:
Cycle count: 294
Battery Installed: Yes
Amperage (mA): 2079
Voltage (mV): 12250
Subscribe to:
Posts (Atom)