| Re: [higgins-dev] Attack on CardSpace possible with CloudSelector? |
From the paper the attack only works if the user is taken to the bad site first where they somehow insert some JS masquerading as the RP but with a bad cert. The user then loads the real page with the real certificate. The JS somehow gets triggered in the DOM and redirects the post URL. The token would be encrypted and audience restricted to the correct RP. This is not entirely different from what Kynetics is doing hooking into pages using same origin. However the attacker needs to manipulate the users Router or browser to have any chance of this working. There are a lot of ownd routers out there so it could happen. I still think that if someone has control over your router you are in much bigger trouble than just a attack on card space. This attack is only considered worth requiring mitigation against at LoA 4. I do think addressing LoA 4 is however a requirement for the US Gov. John B. On 2010-03-29, at 10:20 PM, Mike McIntosh wrote: > The Cert used to encrypt the Token is the Cert provided by the fake RP site, the real RP can't read it, so it can't be replayed. > > Regards, > Michael McIntosh > VP Development > Azigo > > -----Original Message----- > From: Jonathan Tellier [mailto:jonathan.tellier@xxxxxxxxx] > Sent: Monday, March 29, 2010 6:48 PM > To: Higgins (Trust Framework) Project developer discussions; Mike McIntosh; John Bradley > Subject: Re: [higgins-dev] Attack on CardSpace possible with CloudSelector? > > Mike, what you said makes sense, but it's addressed in the paper. You said that the SSL certificate used by the IdP to encrypt the token for the RP will not match the one used by the attacker, so he won't be able to see it. That true and that's why the authors said that their proposed methodology can only be used as a replay attack. Or maybe I'm missing something. I'm not that much of an expert on InfoCards... > > For that reason, I agree with John that masquerading as the IdP or as the cloud selector would be more useful. However, I do think that this attack is pretty far fetch. If you have that much control over a user's (who's not paying attention to SSL error) DNS server, then there's not an awful lot of stuff that he can do securely. > > Jonathan > > > On Mon, Mar 29, 2010 at 9:19 AM, Mike McIntosh <mmcintosh@xxxxxxxxx> wrote: >> The attack described in the paper referenced is pretty unrealistic. CardSpace and Higgins use the RP's SSL certificate to encrypt the token. Even IF (A very big if) you can manipulate DNS entries in real-time and get a user's browser to land on two different sites with the same DNS entry on consecutive HTTPS Requests, they will have different SSL certificates and the token encrypted with the first site's key will be unusable on the second site. >> >> Also, if you have such complete control over the user's machine that you can manipulate its DNS entries in real time, all bets are off wrt security. For instance, you could let the user's machine login to a site (without the "attack" described in the paper) and then just hijack its connection to perform whatever transactions you like. This is not a CardSpace/Higgins/IMI specific problem. >> >> Regards, >> Michael McIntosh >> VP Development >> Azigo >> >> -----Original Message----- >> From: higgins-dev-bounces@xxxxxxxxxxx >> [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jonathan Tellier >> Sent: Saturday, March 27, 2010 10:28 PM >> To: Higgins (Trust Framework) Project developer discussions >> Subject: [higgins-dev] Attack on CardSpace possible with CloudSelector? >> >> Hello there, >> >> I've recently stumbled upon a paper that describes an attack that can be made on CardSpace. The article can be downloaded here: >> http://demo.nds.rub.de/cardspace/GaScXu08_CardSpaceTR.pdf. >> >> To summarize briefly, after a successful DNS spoof attack, a malicious Web server is accessed when a user tries to visit a RP's site. The malicious server then redirects the user to the legit page, but breaks the "same origin policy". That makes it able to intercept the token that is sent to the RP by the card selector through the browser. >> >> Basically, I was wondering if this attack is possible if the user is using the CloudSelector. It is my understanding that the token that comes from the selector and is sent to the RP passes through the browser, even though the selector is not running on the user's computer. If it's the case then the attack would be possible. >> >> Am I missing something? Any thoughts? >> >> Thanks, >> Jonathan >> _______________________________________________ >> higgins-dev mailing list >> higgins-dev@xxxxxxxxxxx >> https://dev.eclipse.org/mailman/listinfo/higgins-dev >> _______________________________________________ >> higgins-dev mailing list >> higgins-dev@xxxxxxxxxxx >> https://dev.eclipse.org/mailman/listinfo/higgins-dev >>
Attachment:
smime.p7s
Description: S/MIME cryptographic signature