Some days you get up and wish you hadn't. How about this one:

The ZDNet article begins by reassuring us:
“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.
“The vulnerability, described in this white paper (.pdf), affects the SAML Single Sign-On Service for Google Apps.
“This US-CERT notice describes the issue:
“A malicious service provider might have been able to access a user’s Google Account or other services offered by different identity providers. [US-CERT actually means ‘by different service providers’ – Kim]
“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.
“To exploit this vulnerability, an attacker would have to convince the user to login to their site
Incredibly basic errors
The paper is by Alessandro Armando, Roberto Carbone, Luca Compagna, Jorge Cuellar, and 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.
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. The industry has known about exactly these problems for a long time now. Yet people keep making the same mistakes.
Do your own thing
The developers decided to forget about the SAML specification as it's written and just “do their own thing.” 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. In fact it is insideous since the claim that Google SSO implemented a well vetted protocol tended to give security professionals a sense of confidence that we understood its capabilities and limitations. In retrospect, it seems we need independent audit before we depend on anything. Maybe companies like Fugen can help in this regard?
What was the problem?
Normally, when a SAML relying party wants a user to authenticate through SAML (or WS-Fed), the replying party sends her to an identity provider with a request that contains an ID and a scope (e.g. URL) to which the resulting token should apply.
For example, in authenticating someone to identityblog, my underlying software would make up a random authentication ID number and the scope would be www.identityblog.com. The user would carry this information with her when she was redirected to the identity provider for authantication.
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 identity, and the identity provider's identity.
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. Because of the unique ID, the relying party knows this assertion was freshly minted in response to its needs. Further, since the scope is specified, the relying party can't abuse the assertion it gets at some other scope.
But according to the research done by the paper's authors, the Google engineers “simplified” the protocol, perhaps hoping to make it “more efficient”? So they dropped the whole ID and scope “thing” out of the assertion. All that was signed was the client's identity.
The result was that the relying party had no idea if the assertion was minted for it or for some other relying party. It was one-for-all and all-for-one at Google.
Wake up to insider attacks
This might seem reasonable, but it sure would sure cause me sleepless nights.
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 ONE of them “goes bad”, the penetrated service can use any tokens it gets to impersonate those users at any other Google relying party service.
It is a red carpet for insider attacks. It is as though someone didn't know that insider attacks represent the overwhelming majority of attacks. Partitioning is the key weapon we have in fighting these attacks. And the Google design threw partitioning to the wind. One hole in the hull and the whole ship goes down.
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 insider attacks. This is itself worrisome since it seems that thinking about the insider isn't something that comes naturally to us.
Then it gets worse.
This is all pretty depressing but it gets worse. At some point, Google decided to offer SSO to third party sites. But according to the researchers, at this point, the scope still was not being verified. Of course the conclusion is that any service provider who subscribed to this SSO service – and any wayward employee who could get at the tokens – could impersonate any user of the third party service and access their accounts anywhere within the Google ecosystem.
My friends at Google aren't going to want to be lectured about security and privacy issues – especially by someone from Microsoft. And I want to help, not hinder.
But let's face it. As an industry we shouldn't be making the kinds of mistakes we made 15 or 20 years ago. There must be better processes in place. I hope we'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.
Let's work together to build our systems to protect them from inside jobs. If we all had this as a primary goal, the Google SSO fiasco could not have happened. And as I'll make clear in an upcoming post, I'm feeling very strongly about this particular issue.
