Last week, I decided to take a stab at implementing a basic OAuth consumer in order to integrate Twitter Karma with Twitter using OAuth. I’d read through the OAuth 1.0 specification before, but never closely enough to realize that there was a serious attack vector in it. So, I mentioned this on the twitter-development-talk mailing list, hoping to get some answers on April 16th:
Also, the redirect to the callback URL has no signature. What stops an attacker from brute-force attacking an OAuth consumer, iterating through posisble tokens? Simply the large search space of valid OAuth tokens? Even if it’s only “possible in theory” … some teenager with nothing better to do is going to eventually turn that theory into practice.
My concern was met with confusion so I brought the concern to the OAuth mailing list (also) on April 17th:
Currently, the OAuth callback URL is susceptible to replay attack and token shooting. Signing it would eliminate this in a very low-effort way.
…
[...] it’s very desirable to be able to tell if the callback was legitimate or either a replay attack or a brute-force token shooting attack.
Even client-side browser cookies may not win here if a simple session fixation attack is coupled with the token shooting attack.
I wasn’t sure if I was being understood, either, but then a few days later on April 20th, Twitter yanked their OAuth support offline.
Eventually, an OAuth security advisory 2009-1 was published on April 23rd that clearly states “A modified specification to address this issue is forthcoming” as I pointed out was necessary, and Eran Hammer-Lahav writes a thorough explanation of the problem in his blog. The money quote:
If we put it all together, even if an application:
- Makes sure to use the account of the user coming back from the callback and not that of the one who started
- Checks that the user who starts the process is the same as the one who finishes it
- Uses an immutable callback set at registration
It is still exposed to a timing attack trying to slide in between the victim authorizing access and his browser making the redirection call. There is simply no way to know that the person who authorizes is the same person coming back. None whatsoever.
This is exactly why the callback URL that the OAuth provider uses to redirect the user back to the OAuth consumer needs to be signed.
So, why am I making a big deal out of all of this? Well, I’m irked. Coincidentally, their “discovery” of this issue conveniently coincided with my raising of the issue publically on the mailing lists, yet nowhere is my name mentioned in any of this. In my opinion, that’s really poor form in an “open community” where often the only compensation for effort is recognition. It’s this kind of back-handed treatment that encourages people to demonstrate these security concerns through actual working exploits, which benefits no one but guarantees the creator their recognition.
In the end, I’m glad that this issue is going to be addressed and hopefully in a timely fashion because all of us developing applications in the public software ecosystem will benefit, but I still feel slighted. I’ll get over it, while I wait for the OAuth 1.1 specification.
So, I’ve sent a request to have the DNS updated.
Programmer, husband, father, singer, guitarist, tinkerer, reverse engineer, strange, and living in New Jersey. 
Latest comments