{"id":1011,"date":"2008-09-14T21:16:00","date_gmt":"2008-09-15T05:16:00","guid":{"rendered":"\/?p=1011"},"modified":"2008-09-14T21:40:05","modified_gmt":"2008-09-15T05:40:05","slug":"hole-in-google-sso-service","status":"publish","type":"post","link":"https:\/\/www.identityblog.com\/?p=1011","title":{"rendered":"Hole in Google SSO service"},"content":{"rendered":"

Some days you get up and wish you hadn't.\u00a0 How about this one:<\/p>\n

\"Google<\/p>\n

The ZDNet article begins by reassuring us:<\/p>\n

“Google has fixed an implementation flaw in the single sign-on service that powers Google Apps follow a warning from researchers that remote attackers can exploit a hole to access Google accounts.<\/p>\n

“The vulnerability, described in this white paper <\/a>(.pdf), affects the SAML Single Sign-On Service for Google Apps.<\/p>\n

“This US-CERT notice describes the issue:<\/p>\n

“A malicious service provider might have been able to access a user\u2019s Google Account or other services offered by different identity providers. [US-CERT actually means ‘by different service providers’ – Kim]<\/p>\n

“Google has addressed this issue by changing the behavior of their SSO implemenation. Administrators and developers were required to update their identity provider to provide a valid recipient field in their assertions.<\/p>\n

“To exploit this vulnerability, an attacker would have to convince the user to login to their site<\/p>\n

Incredibly basic errors<\/strong><\/p>\n

The paper is by Alessandro Armando,\u00a0 <\/span>Roberto Carbone, <\/span>Luca Compagna, <\/span>Jorge Cuellar, and <\/span>Llanos Tobarra, who are affiliated with University of Genoa, Siemens and SAP, and is one of an important series of studies demonstrating the value of automated protocol verification systems.<\/span><\/p>\n

But the surprising fact is that the errors made are incredibly basic – you don't need an automated protocol verification system to know which way the wind blows.\u00a0 The industry has known about exactly these problems for a long time now.\u00a0\u00a0 Yet people keep making the same mistakes.<\/span><\/p>\n

Do your own thing<\/strong><\/p>\n

The developers decided to forget about\u00a0the SAML specification as it's written and just “do their own thing.”\u00a0 As great as this kind of move might be on the dance floor, it's dangerous when it comes to protecting peoples’ resources and privacy.\u00a0 In fact it is insideous since the\u00a0claim that\u00a0Google SSO\u00a0implemented a well vetted protocol tended to give\u00a0security professionals\u00a0a\u00a0sense of confidence that we understood its capabilities and limitations.\u00a0 In retrospect, it seems we need\u00a0independent\u00a0audit\u00a0before we depend on anything.\u00a0 Maybe companies like Fugen <\/a>can help in this regard?<\/p>\n

What was the problem?<\/strong><\/p>\n

Normally, when a SAML relying party wants a user to authenticate through SAML (or WS-Fed), the\u00a0replying party\u00a0sends her to an identity provider with a request that contains\u00a0an ID\u00a0and a\u00a0scope\u00a0 (e.g. URL)\u00a0to which the resulting\u00a0token should apply.<\/p>\n

For example, in authenticating someone to identityblog,\u00a0my underlying software would make\u00a0up a random authentication\u00a0ID number and the scope would be www.identityblog.com<\/a>.\u00a0 The user would carry this information with her when she was redirected to the identity provider for authantication.<\/p>\n

The identity provider would then ask for a password, or examine a cookie, and sign an authentication assertion containing the ID number, the scope, the client\u00a0identity, and the\u00a0identity provider's identity.\u00a0\u00a0<\/p>\n

Having been bound together cryptographically in a tamperproof form where authenticity of the assertion could be verified, these properties would be returned to the relying party.\u00a0 Because of the unique ID, the relying party knows this assertion was freshly minted in response to its needs.\u00a0 Further, since the scope is specified,\u00a0the relying party\u00a0can't abuse the assertion it gets at some other scope.<\/p>\n

But according to the research done by the paper's authors, the Google engineers “simplified” the protocol, perhaps hoping to make it “more efficient”?\u00a0 So they dropped<\/strong><\/em> the whole ID and scope “thing” out of the assertion.\u00a0 All that was signed was the client's identity.<\/p>\n

The result was that the relying party had no idea if the assertion was minted for it or for some other relying party.\u00a0 It was\u00a0one-for-all and all-for-one at\u00a0Google.<\/p>\n

Wake up to insider attacks<\/strong><\/p>\n

This might seem reasonable, but it sure would sure cause me sleepless nights.<\/p>\n

The problem is that if you have a huge site like Google, which brings together many hundreds (thousands?) of services, then with this approach, if even\u00a0ONE of them “goes bad”,\u00a0the penetrated service\u00a0can use any tokens it gets to impersonate those users at any other Google relying party service<\/em>.<\/p>\n

It is a red carpet for insider attacks<\/em>.\u00a0 It is as though someone didn't know that insider attacks\u00a0represent the\u00a0overwhelming majority of attacks.\u00a0 Partitioning is the key weapon we have in fighting these attacks.\u00a0\u00a0And the\u00a0Google design threw partitioning to the wind.\u00a0 One hole in the hull and the whole ship goes down.<\/p>\n

Indeed the qualifying note in the ZD article that “to exploit this vulnerability, an attacker would have to convince the user to login to their site” misses the whole point about how this vulnerability facilitates\u00a0insider attacks.\u00a0 This\u00a0is itself worrisome since it seems that thinking about the insider isn't something that comes naturally to us.<\/p>\n

Then\u00a0it gets worse.<\/strong><\/p>\n

This is all pretty depressing but it gets worse.\u00a0 At some point, Google decided to offer SSO to third party sites.\u00a0 But according to the researchers,\u00a0at this point, the scope still was not being verified.\u00a0 Of course the conclusion is that any service provider\u00a0who subscribed to this SSO service –\u00a0and\u00a0any wayward employee who could get at the tokens\u00a0– could impersonate any user of\u00a0the third party service\u00a0and access their accounts anywhere within the Google ecosystem.<\/p>\n

My friends at Google aren't going to want to be lectured about security and privacy\u00a0issues – especially by someone from Microsoft.\u00a0 And I want to help, not hinder.<\/p>\n

But let's face it.\u00a0 As an industry we shouldn't be making the kinds of mistakes we made 15 or 20 years ago.\u00a0 There\u00a0must be better processes in place.\u00a0\u00a0I hope\u00a0we'll get to the point where we are all using vetted software frameworks so this kind of do-it-yourself brain surgery doesn't happen.\u00a0<\/p>\n

Let's\u00a0work together to\u00a0build our systems to protect them from inside jobs.\u00a0 If we all had this as a primary goal, the Google SSO fiasco could not have happened.\u00a0 And as I'll make clear in an upcoming post, I'm feeling very strongly about this particular issue.<\/p>\n

\"\"<\/p>\n","protected":false},"excerpt":{"rendered":"

The “do-it-yourself” protocol was a red carpet for “inside jobs”… under the guise of being SAML<\/p>\n","protected":false},"author":68,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[63,21,13,11],"tags":[],"_links":{"self":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/1011"}],"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=1011"}],"version-history":[{"count":0,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/1011\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1011"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1011"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1011"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}