Posts Mentioning RSS Toggle Comment Threads | Keyboard Shortcuts

  • donpark 3:53 pm on April 28, 2009 Permalink | Reply
    Tags: ,   

    Why wasn’t OAuth Vulnerability found earlier? 

    According to OAuth about page, it was Blaine Cook who initiated the birth of the the standard while working at Twitter in Nov. 2006. Blaine mobilized the initiative by getting Chris Messina involved which attracted others at CitizenSpace to join the effort (an excellent demonstration of benefits co-working social environments offer). By April 2007, the initiative got to formalize and, by October 2007, OAuth Core 1.0 spec was finalized. The question of interest to me is, why did it take a year and a half to uncover the first vulnerability?

    It’s puzzling because OAuth was well known and popularized, attracted a large body of developers, many of whom I presume read the spec, and implemented by many, some very large companies. I’ve read the spec as well and discussed it with peers and partners in the security and payment industry on several occasions.

    I think the right answer might be that our collective perspective in dealing with the standard was focused on implementation, application, and hype while wrongly assuming that the standard was secure. Recollecting my thoughts when I was reading the spec for the first time, I now realize that it was the safety in numbers and the lure of promising applications that influenced me to focus only on implementation.

    The good news is that I think OAuth will be given the proper shake it needs to get any remaining kinks out. The bad news is that we are likely to repeat the mistake when the next popular grassroots standard emerges in a hurry. Relatively fast pace of community/grassroots standard initiatives is not a concern only if mass appeal can be effectively leveraged to shine intensive searchlight on all aspect of the standard.

     

    • Peter Keane 5:25 pm on April 28, 2009 Permalink

      I recently implemented my first OAuth client and had a slightly uneasy feeling that there was a bit of magic — I couldn’t cleary see how it was truly secure. Fact is, it was pretty darn close — the hole was never exploited (that we know) and steps are being taken to close that hole.

      That said, a simple fix will still leave a bit of “magic:” there is an authentication equivalency that is not being addressed (in OAuth terms, that user@consumer == user@service_provider) by way of a properly out-of-band mechanism. I would prefer to see that hole sewn up more definitively — essntially “whitelisting good guys” rather than “blacklisting bad guys” (which can become a game of whack-a-mole). I should note that many knowledgeable folks on the list feel the proposed fix is adequate. Two-legged OAuth, a less common use than the typical Three-legged flavor, is an excellent protocol (the exploit was discovered only in the Three-legged variety), and I suspect we’ll see more adoption as a stand-in for HTTP Basic & HTTP Digest authentication.

    • Matt Brubeck 7:24 pm on April 28, 2009 Permalink

      I don’t think it’s that complicated. There have been all manner of crypto protocols and security protocols that have been in use for years before critical flaws were discovered. Some were developed by standards bodies or subject to academic peer review. The fact is that any flaws left in a system after it’s been reviewed and revised and published can be quite hard to see, even if they’re obvious after someone points them out.

    • donpark 8:21 pm on April 28, 2009 Permalink

      Matt, while I agree that other protocols had flaws of varying nature, uncovering of fundamental flaws like the OAuth one and DNS one are rare events, often resulting in industry-wide scramble.

      Also, I don’t think we should accept incidental trickles of flaw discoveries as the norm when there are actions we can take to improve the process.

      IMO, it’s the same with open source projects. OS participants are primarily focused on using, extending, or repurposing the project code which means while bugs are uncovered, security vulnerabilities are rarely found until attack incidents occur or by chance.

      So I think some attention should be paid to finding ways or factors to introduce in grassroots initiatives and open source projects that encourages early detection of security vulnerabilities.

  • donpark 2:58 pm on April 25, 2009 Permalink | Reply
    Tags: , ,   

    On Twitter’s OAuth Fix 

    While the OAuth team is working on addressing the OAuth session fixation vulnerability at the spec level, Twitter made following changes to reduce the exposure window:

    • Shorter Request Token timeout – This is good practice in general. Developers tend to be too generous and, all too often, forget to enforce or verify enforcement.
    • Ignore oauth_callback, in favor of URL set at regration time – this prevents hackers from intercepting callback.

    Double-callback is still possible though which means Twitter OAuth Consumers will have to detect extraneous callbacks and invalidate access to everyone involved because they have no way of telling who is who.

    Remaining exposure to the vulnerability is when hacker’s simulated callback arrives before the user. We are talking temporal exposure of a couple of seconds at most which, given current Twitter use-cases, is not that big a deal. I wouldn’t do banking over Twitter though. ;-)

     

  • donpark 2:38 pm on April 23, 2009 Permalink | Reply
    Tags: ,   

    On OAuth Vulnerability 

    Twitter’s OAuth problem turned out to be a general problem affecting other OAuth service providers and well as consumers using ‘3-legged’ OAuth use-case. For details, you should read not only the relevant advisory but Eran Hammer-Lahav’s post Explaining the OAuth Session Fixation Attack.

    First hint of the vulnerability surfaced last November as a CSRF-attack at Clickset Social Blog which was initially diagnosed as an implementation-level issue. Well, it turned out to be a design flaw requiring some changes to the protocol.

    There are actually two flaws.

    The first flaw is that parameters of HTTP redirects used in OAuth can be tempered with or replayed.

    This flaw allows hackers to capture, replay, and mediate conversations between OAuth Consumer and Service Provider flowing over the surface of User’s browser between the User, Consumer, Service Provider.

    I think the easiest general remedy for this flaw is including a hash of the HTTP redirect parameters and some shared secret like consumer secret. A more general solution like evolving tokens could be done as well but inappropriate as a quick remedy.

    This flaw should not affect OAuth service providers that manage and monitor callback URLs rigorously.

    The second and more serious flaw is that the User talking to the Consumer may *not* be the same User talking to the Service Provider.

    This means that a hacker can start a session with TwitsGalore.com then phish someone to authorize at Twitter to gain access to TwitsGalore.com as that someone without stealing password or session-jacking.

    Solving the first flaw simplifies the solution to the second flaw by reducing the possibility of the hacker intercepting callback from Service Provider to Consumer which is not supposed to have any sensitive information but some implementations might include. Wire sniffing is a concern if HTTPS is not used but the relevant concerns for the flaw are integrity and identity, not secrecy which is an application factor.

    Removing the possibility of callback URL tempering leaves double callback, meaning that the hacker start things off, tricks someone into authorizing without intercepting the callback, then simulate a callback to Consumer. Note that the Consumer would have started a HTTP session with the hacker, session associated with the RequestToken in the callback. Even if HTTP session is not created until the callback is received, there is no way for the Consumer to tell who is who.

    I think Service Provider have to send back a verifiable token, like a hash of the RequestToken and consumer secret so the hacker can’t simulate the callback.

    Regardless of which solutions OAuth guys decide on, one thing is clear. It will take time, many weeks at least, if not months. That’s going to put quite a damper on developers in the Consumer side of the OAuth as well as the Service Provider side.

     

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
esc
cancel