I did a presentation at the DefCon Comedy Jam about how the update mechanism for Firefox was just a total mess from a security perspective. It had a lot to do with the fact that they are using round robin DNS and relying on the good will of a lot of dispirit sites to do their hosting for them. Well, I’ve been wondering more and more about how I may or may not be able to download these releases securely. So I did a few checks and here’s the IP space I found and the status of what their SSL/TLS ports were when checked yesterday:

63.245.208.152 (live but with SSL/TLS mismatch)
128.61.111.9 (connection refused)
129.101.198.59 (connection refused)
131.188.12.212 (connection refused)
149.20.20.5 (connection refused)
156.56.247.196 (connection refused)
202.177.202.154 (connection refused)
204.152.184.196 (connection refused)
204.246.0.136 (connection refused)
216.165.129.141 (connection refused)
64.50.236.214 (connection refused)
64.50.236.52 (connection refused)
129.101.198.59 (operation timed out)
155.98.64.83 (operation timed out)

So only out of 14 even have SSL enabled. Okay… well today, I took a little spin on SSLLabs and I found that the one site that does have SSL enabled (63.245.208.152) has a SSL/TLS mismatch error for videos.mozilla.org. I mean… seriously! If your browser goes to https://releases.mozilla.org this is sort of what’s happening under the hood:

$ telnet releases.mozilla.org 443
Trying 202.177.202.154…
telnet: connect to address 202.177.202.154: Connection refused
Trying 204.152.184.196…
telnet: connect to address 204.152.184.196: Connection refused
Trying 204.246.0.136…
telnet: connect to address 204.246.0.136: Connection refused
Trying 216.165.129.141…
telnet: connect to address 216.165.129.141: Connection refused
Trying 64.50.236.214…
telnet: connect to address 64.50.236.214: Connection refused
Trying 128.61.111.9…
telnet: connect to address 128.61.111.9: Connection refused
Trying 129.101.198.59…
telnet: connect to address 129.101.198.59: Connection refused
Trying 131.188.12.212…
telnet: connect to address 131.188.12.212: Connection refused
Trying 149.20.20.5…
telnet: connect to address 149.20.20.5: Connection refused
Trying 155.98.64.83…
telnet: connect to address 155.98.64.83: Operation timed out
Trying 156.56.247.196…
telnet: connect to address 156.56.247.196: Connection refused
Trying 63.245.208.152…
Connected to releases.geo.mozilla.com.
Escape character is ‘^]’.
^]
telnet> quit

Yes, after a minute of trying your browser will eventually find the one HTTP server - or it won’t (sometimes it just gives up). So then in poking around within my Mozilla config I saw a reference to http://en.www.mozilla.com/en/firefox/3.5.7/releasenotes/. So I switched to SSL/TLS with this link, because I like being secure, and I get a SSL/TLS warning as well. These are the kinds of things that make Firefox incredibly unsafe to download and update if you are in a hostile environment. And I’m just scratching the surface compared to my presentation. How many of those 3rd party sites do you think can be exploited?

MITM, SSL and Session Fixation

23 posts left…

It’s been known for a long time that HTTP can set cookies that can be read in HTTPS space because cookies don’t follow the same origin policy in the way that JavaScript does. More importantly, HTTP cookies can overwrite HTTPS cookies, even if the cookies are marked as secure. I started thinking of a form of session fixation during our research that uses this to the attacker’s advantage. Let’s assume the attacker wants to get access to a user’s account that’s over SSL/TLS. Now let’s assume the website sets a session cookie prior to authentication and after authentication the site marks the cookie as valid for whatever username/password combo it receives.

First, the attacker goes to the website before the victim gets there so he can get a session cookie. Then, if the victim is still in HTTP for the same domain the attacker can set a cookie that will replay to the HTTPS website. So the attacker sets the same cookie that he just received into the victim’s browser. Once the victim authenticates, the cookie that the attacker gave the victim (and knows) is now valid for the victim’s account. Now if the victim was already authenticated or had already gotten a session token, no big deal. The attacker overwrites the cookie, which at worst logs the user out. Once the victim re-authenticates, voila - session fixation. Now all the attacker has to do is replay the same cookie in his own browser and he’s in the user’s account.

MITM, SSL and Session Fixation

23 posts left…

It’s been known for a long time that HTTP can set cookies that can be read in HTTPS space because cookies don’t follow the same origin policy in the way that JavaScript does. More importantly, HTTP cookies can overwrite HTTPS cookies, even if the cookies are marked as secure. I started thinking of a form of session fixation during our research that uses this to the attacker’s advantage. Let’s assume the attacker wants to get access to a user’s account that’s over SSL/TLS. Now let’s assume the website sets a session cookie prior to authentication and after authentication the site marks the cookie as valid for whatever username/password combo it receives.

First, the attacker goes to the website before the victim gets there so he can get a session cookie. Then, if the victim is still in HTTP for the same domain the attacker can set a cookie that will replay to the HTTPS website. So the attacker sets the same cookie that he just received into the victim’s browser. Once the victim authenticates, the cookie that the attacker gave the victim (and knows) is now valid for the victim’s account. Now if the victim was already authenticated or had already gotten a session token, no big deal. The attacker overwrites the cookie, which at worst logs the user out. Once the victim re-authenticates, voila - session fixation. Now all the attacker has to do is replay the same cookie in his own browser and he’s in the user’s account.

MITM, SSL and Session Fixation

23 posts left…

It’s been known for a long time that HTTP can set cookies that can be read in HTTPS space because cookies don’t follow the same origin policy in the way that JavaScript does. More importantly, HTTP cookies can overwrite HTTPS cookies, even if the cookies are marked as secure. I started thinking of a form of session fixation during our research that uses this to the attacker’s advantage. Let’s assume the attacker wants to get access to a user’s account that’s over SSL/TLS. Now let’s assume the website sets a session cookie prior to authentication and after authentication the site marks the cookie as valid for whatever username/password combo it receives.

First, the attacker goes to the website before the victim gets there so he can get a session cookie. Then, if the victim is still in HTTP for the same domain the attacker can set a cookie that will replay to the HTTPS website. So the attacker sets the same cookie that he just received into the victim’s browser. Once the victim authenticates, the cookie that the attacker gave the victim (and knows) is now valid for the victim’s account. Now if the victim was already authenticated or had already gotten a session token, no big deal. The attacker overwrites the cookie, which at worst logs the user out. Once the victim re-authenticates, voila - session fixation. Now all the attacker has to do is replay the same cookie in his own browser and he’s in the user’s account.

Microsoft issues updates to sysinternals ProcDump and Process Monitor: http://blogs.technet.com/b/sysinternals/archive/2010/08/30/updates-procdump-process-monitor-and-a-new-mark-s-blog-post.aspx, (Wed, Sep 1st)