{"id":987,"date":"2008-05-30T16:00:58","date_gmt":"2008-05-31T00:00:58","guid":{"rendered":"\/?p=987"},"modified":"2008-06-01T12:12:28","modified_gmt":"2008-06-01T20:12:28","slug":"students-enlist-readers-assistance-in-cardspace-breach","status":"publish","type":"post","link":"https:\/\/www.identityblog.com\/?p=987","title":{"rendered":"Students enlist readers’ assistance in CardSpace “breach”"},"content":{"rendered":"

Students at Ruhr Universitat Bochum in Germany have published an\u00a0account <\/a>this week describing an attack on the use of CardSpace within Internet Explorer.\u00a0 Their claim\u00a0is to “confirm the practicability of the attack by presenting a proof of concept implementation<\/em>“.<\/p>\n

<\/span>I\u2019ve spent a fair amount of time reproducing and analyzing the attack.\u00a0 The students were not actually able to compromise my safety except by asking me to go through elaborate measures to poison my own computer (I show how complicated this is in a video<\/a> I will post next).\u00a0\u00a0For the\u00a0attack to succeed,\u00a0the user has to\u00a0bring full administrative power to bear against\u00a0her own system.\u00a0 It seems obvious that if people go to the trouble to manually circumvent all their defenses they become vulnerable to the attacks those defenses were intended to resist.\u00a0 In my view, the students did not compromise CardSpace.<\/p>\n

DNS must be undermined through a separate (unspecified) attack<\/strong><\/p>\n

To succeed, the students first require a compromise of a computer\u2019s Domain Name System (DNS).\u00a0 They ask their readers to reconfigure their computers and point to an evil DNS site they have constructed.\u00a0 Once we help them out with this, they attempt to exploit the fact that poisoned DNS allows a rogue site and a legitimate site to appear to have the same internet \u201cdomain name\u201d (e.g. www.goodsite.com<\/a>) .\u00a0 Code in browser frames animated by one domain can interact with code from other frames animated by the same domain.\u00a0 So once DNS is compromised, code supplied by the rogue site can interfere with the code supplied by the legitimate site.\u00a0 The students want to use this capability to hijack the legitimate site\u2019s CardSpace token.<\/p>\n

However, the potential problems of DNS are well understood.\u00a0 Computers protect themselves from attacks of this kind by using cryptographic certificates that guarantee a given site REALLY DOES legitimately own a DNS name.\u00a0 Use of certificates prevents the kind of attack proposed by the students.<\/p>\n

The certificate\u00a0store must also\u00a0“somehow be compromised” <\/strong><\/p>\n

But this is no problem as far as the students are concerned.\u00a0 They simply ask us to TURN OFF this defense as well.\u00a0 In other words, we have to assist them by poisoning all of the safeguards that have been put in place to thwart their attack.\u00a0\u00a0<\/p>\n

Note that both safeguards need to be compromised at the same time.\u00a0 Could such a compromise occur in the wild?\u00a0 It is theoretically possible that through a rootkit or equivalent, an attacker could completely take over the user\u2019s computer.\u00a0 However, if this is the case, the attacker can control the web browser, see and alter everything on the user\u2019s screen and on the computer as a whole, so there is no need to obtain the CardSpace token.<\/p>\n

I think it is amazing that the Ruhr students describe their attack as successful when it does NOT provide a method for compromising EITHER DNS or the certificate store.\u00a0 They say DNS might be taken over through a drive-by attack on a badly installed wireless home network.\u00a0 But they provide no indication of how to simultaneously compromise the Root Certificate Store.\u00a0<\/p>\n

In summary, the students\u2019 attack is theoretical.\u00a0 They have not demonstrated the simultaneous compromise of the systems necessary for the attack to succeed.<\/p>\n

The user experience<\/strong><\/p>\n

Because of the difficulty of compromising the root certificate store, let\u2019s look at what would happen if only DNS were attacked.<\/p>\n

Internet Explorer does a good job of informing the user that she is in danger and of advising her not to proceed.\u00a0<\/p>\n

First the user encounters the following screen, and has to select \u201cContinue to the website (not recommended)\u201d:<\/p>\n


\n\u00a0
\nIf recalcitrant, the user next sees an ominous red band warning within the address bar and an unnaturally long delay:<\/p>\n

<\/p>\n

The combined attacks require a different yet coordinated malware delivery mechanism than a visit to the phishing site provides.\u00a0 In other words, accomplishing two or more attacks simultaneously greatly reduces the likelihood of success.<\/p>\n

The students\u2019 paper proposes adding a false root certificate that will suppress the Internet Explorer warnings.\u00a0 As is shown in the video<\/a>, this requires meeting an impossibly higher bar.\u00a0 The user must be tricked into importing a \u201croot certificate\u201d.\u00a0 This by default doesn\u2019t work \u2013 the system protects the user again by installing the false certificate in a store that will not deceive the browser.\u00a0 Altering this behavior requires a complex manual override.<\/p>\n

However,\u00a0should all the planets involved in the attack align, the contents of the token are never visible to the attacker.\u00a0 They are encrypted for the legitimate party, and no personally identifying information is disclosed by the system.\u00a0 This is not made clear by the students’ paper.<\/p>\n

What the attempt proves<\/strong>\u00a0<\/p>\n

The demonstrator shows that if you are willing to compromise enough parts of your system using elevated access,<\/em> you can render your system attackable.\u00a0\u00a0 This aspect of the students\u2019 attack is not noteworthy.\u00a0<\/p>\n

There is, however, one interesting aspect to their attack.\u00a0 It doesn\u2019t concern CardSpace, but rather the way intermittent web site behavior can be combined with DNS to confuse the browser.\u00a0 The student\u2019s paper proposes implementing a stronger \u201cSame Origin Policy\u201d to deal with this (and other) possible attacks.\u00a0 I wish they had concentrated on this positive contribution\u00a0rather than making\u00a0claims\u00a0that\u00a0require suspension of disbelief.\u00a0<\/p>\n

The students propose a mechanism for associating Information Card tokens with a given SSL channel.\u00a0\u00a0 This idea would likely harden Information Card systems and is worth evaluating.<\/p>\n

However, the students propose equipping browsers with end user certificates so the browsers would be authenticated, rather than the sites they are visiting.\u00a0 This represents a significant privacy problem in that a single tracking key would be used at all the sites the user visits.\u00a0 It also doesn\u2019t solve the problem of knowning whether I am at a \u201cgood\u201d site or not.\u00a0 The problem here is that if duped, I might provide an illegitimate site with information which seriously damages me.<\/p>\n

One of the most important observations that must be made is that security isn\u2019t binary \u2013 there is no simple dichotomy between vulnerable and not-vulnerable.\u00a0 Security derives from concentric circles of defense that act cumulatively and in such a way as to reinforce one another.\u00a0 The title of the students’ report misses this essential point.\u00a0 We need to design our systems in light of the fact that any system is breachable.\u00a0 That\u2019s what we\u2019ve attempted to do with CardSpace.\u00a0 And that\u2019s why there is an entire array of defenses which act together to provide a substantial and practical barrier against the kind of attack the students have attempted to achieve.<\/p>\n","protected":false},"excerpt":{"rendered":"

Student researchers have NOT demonstrated the simultaneous compromise of the systems necessary for the attack to succeed. <\/p>\n","protected":false},"author":68,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[63,16,13,61,23],"tags":[],"_links":{"self":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/987"}],"collection":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/users\/68"}],"replies":[{"embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=987"}],"version-history":[{"count":0,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/987\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=987"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=987"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=987"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}