LulzSec Reborn vs Twitter and OAuth Security Issues

Wednesday, June 13, 2012

Pierluigi Paganini

03b2ceb73723f8b53cd533e4fba898ee

(Translated from the original Italian)

There is no peace for social network platforms, priority targets for cybercrime and governments, as they represent a mine of data useful for business and espionage.

After the news of the LinkedIn hack, Twitter has also been successfully attacked by a group of hacktivists named "LulzSec Reborn" that leaked the user credentials of more of 10,000 accounts.

LulzSec Reborn appears to be composed by member of LulzSec, and has also recently attacked the MilitarySingles.com website.

The compromised accounts used a third-party application, TweetGif, to share animated GIF files.

The breach has exposed a huge quantity of data from the Twitter members such as login credentials, names, bios and locations, all requested by TweetGif in the registration phase.

Part of the exposed data is also the secure tokens used by TweetGif to cross-authenticate with the Twitter accounts.

(click image to enlarge)

The hack raises a serious question regarding the security level ensured by third-party authentication processes that could expose the data of the principal platform, extending the surface area of an attack.

Do third-party companies adopt best practices for authentication processes? How do they grant access to the application?

The third-party authentication process is realized by implementing the open standard for authorization, or OAuth, that allows users to share private resources stored on one site with another site without having to hand out their credentials, typically by supplying username and password tokens instead.

(click image to enlarge)

Each token grants access to a specific site for specific resources and for a defined duration, allowing a user to grant a third party site access to the information stored with another service provider without having to share their access permissions or the full extent of their data.

It is clear that in those processes, OAuth authentication considers it essential that both parties implement security best practices, otherwise you run the risk of making it paradoxically more complex for the prevention and detection of attacks if they originate from trusted third parties.

Let me remark that On April 23, 2009, a session fixation security flaw in the OAuth 1.0 protocol was announced. It affects the OAuth authorization flow in Core 1.0 Section 6.

Version 1.0a of the OAuth Core protocol was issued to address this issue. OAuth 2.0 is the next evolution of the OAuth protocol, and is not backward compatible with OAuth 1.0.

OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and other devices.

In the following list of OAuth Service Providers it is possible to note Twitter is only implementing the OAuth 1.0a version.

(click image to enlarge)

What are the consequences of the hack?

Let's separate the emotional factor from the actual risks faced by the users. The data leak has given Twitter a negative image in a time when the reliability of social networks in terms of security is at a historic low.

Regarding the risks faced by the users, the 10,000 Twitter compromised accounts can be used to spread spam. The exposure of the consumer key and consumer secret key from a popular third-party Twitter application make spammers hard to detect.

The solution to the problem is revoke the privilege granted to the exploited third-party application - in this case the TweetGif Users - who need to got to: settings > apps > de-authorize application #TweetGif and then "Revoke Access".

Cross-posted from Security Affairs

Possibly Related Articles:
10692
Network Access Control
Information Security
Twitter Authentication Application Security Social Media Third Party Hacktivist hackers OAuth TweetGif LulzSec Reborn
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.