There. Now let’s take a look at the recent activity we saw on Twitter over the weekend into Monday. There were two distinct, very likely related events.

The Phish

On Saturday, Twitter was hit with a phishing attack. While the events surrounding that have been widely documented, there was an undercurrent of discussion from developers of third-party Twitter applications claiming that this was exactly why Twitter needed to implement OAuth. With the sale of a Twitter application that had been around for one day and accumulated approximately 1,000 accounts, speculation was high that this phishing attack was a direct result of developers being “forced” to request user credentials to build their Twitter apps.

There are a couple things to address here. First is that OAuth is most definitely not a web application silver bullet and would not have prevented the phishing attack that occurred.

Plain and simple.

OAuth provides a secure manner for interacting with an application’s API. Phishing is an attempt to retrieve valid user credentials by spoofing or forging the target site. While Twitter users are admittedly lackadaisical with their account credentials (as seen with a test I performed earlier this year on a site called TwitterAwesomeness), the fact is that this attack occurred because somebody created a legitimate looking Twitter login page and some users fell susceptible to the spoof.

For those looking for more details, there was some good discussion on the Twitter Development mailing list if you can wade through the various misconceptions. Chris Messina actually has a fantastic blog post on password usage and Twitter. Unfortunately, there is still the misconception that OAuth would have fixed this and prevented the worm from propagating. To address that – any application can spoof the Twitter home page. Once those credentials have been obtained, the attackers can automate the Twitter website in a variety of ways.

While I agree that the pattern of password usage needs to change on Twitter, restricting application access is a different battle from educating users on preventing themselves from being victims of phishing attacks. Not to mention that chances are high that a web application vulnerability such as SQL Injection exists within the numerous third-party web applications that accept Twitter usernames and passwords. Ultimately, however, OAuth will be beneficial in locking down Twitter from an API and third-party application perspective.

The Hack

On Monday morning, there was a post indicating Twitter had been “hacked” and several high-profile accounts had been compromised and used to post fake updates. This is more of an operational issue, but may have been indirectly related to the ongoing phishing attacks if a staff member had been phished. Based on the Twitter blog post, it would appear as if the admin tools utilized by Twitter support staff are available externally and may even share Twitter account information. From a security operations point of view, this is a recipe for disaster. If possible, administrative functions should be logically separated from user activity. Twitter is rather fortunate this happened at the same time and that the attackers didn’t have more malicious or damaging ideas in mind.

This prank is simply the tip of the iceberg. While Twitter may be able to secure the admin tools, the site will continue to grow and the phishing attacks will continue to advance to take advantage of how Twitter is used. How so? Well many Twitter-folk utilize automatic-follow techniques so they don’t have to manage it. This means immediate acceptance into a larger network, even more so if you have somebody reply to you. Further, “re-tweeting” is a popular concept on Twitter to share links. Finally, any URL over 30 characters is automatically shortened by Twitter and many users do so manually or utilize client applications further obfuscating the destination site.

A Little Perspective

I urge those people pushing so hard for strong account controls on Twitter, to also direct their resources and energy towards more critical assets. With the estimated Internet population at nearly 1.5 billion people, Twitter’s population accounts for a minuscule fraction of that. Wells Fargo has 48 million customers. Bank of America employed 206,587 people in 2008. Based on my Twitter stats service that records analysis of every update on Twitter, there were 358,691 distinct users that posted tweets on January 5 of this year. I would love to see more critical assets such as banks implement more secure authentication methods as well, and those user populations are even larger and more critical than our favorite micro-blogging site.

Update: Seems it was an unrelated brute-force attempt that compromised Twitter’s Admin tools. Interestingly enough, I’ve seen this functionality other places and noticed when I had a support ticket that the username was the same. It seems my hope that the systems were somehow logically separated was not to be realized. Oh, Twitter.

There were two failings here, which is why layered security is beneficial.

1. A weak password was being used for a highly-privileged account
2. The administrative tools were exposed in such a way that an external attacker could continually attempt passwords and not be automatically locked out or noticed

Yes. It is just a micro-blogging site. But when the President-elect is relying on it to get his message out and people are staking their reputations and businesses on it…it suddenly becomes more.

I fully believe that Twitter does realize this and we know they are working to address some of the more pressing issues. Yes it’s taking a “long time” and we can criticize all we want, but who’s really at fault here – Twitter for not prioritizing the security of what was originally conceived to be an offline AIM status service, or the developers for propagating what they knew was an inherently insecure method of authentication with only the dollar signs of success in their eyes. In my opinion, why bother throwing blame. Let’s work together towards building a more secure web 3.0.

</soapbox>

This is inherently broken.

Why do I make that statement? Because when there is no enforcement of that “private” data other than a database flag, it should be considered public. Let’s take one of our favorite examples, Twitter. A vulnerability in Twitter was recently announced (and subsequently patched) that revealed protected account’s messages. The flaw here is simply that Twitter didn’t really consider this use case when writing the SQL query and forgot to account for protected accounts with a small SQL statement that probably looked like “AND protected = 1“.

So why is this a problem?

Because the application server always connects to the database server as the same user and it is the responsibility of the developers to not forget to account for protected accounts. Unfortunately, we as humans are fallible and while this practice continues, mistakes will be made.

How can we fix this?

There are several approaches, but I’ll talk about a couple. One relies on process, the other on technology.

1. Threat modeling, data flow and data classification

   This really should be done anyway, but there’s a process known as threat modeling where application developers, business owners and security personnel review an application and identify the data that flows through it, potential avenues of attack and the classification of said data, among various other things. Every application should have this concept of data flow and classification (public vs. private) and verify new code against this model during the development process.

2. Build identity into the data layer

   More mature databases such as Microsoft SQL and Oracle have various concepts of row-level security where options exist to further limit access to data based on a combination of data classification labels and restrictive views. Combined with impersonation, this approach actually relies on the database to enforce privileges, rather than the developer. While I know views and the potential for row-level security exist on MySQL, I don’t think they’re considered or used very often.

The moral of the story is that your data may only be as “private” as the security awareness of the developer coding your SQL queries.

Oh, another topic I should talk about sometime is security through obscurity or other ineffective means. That link I posted to sqlpass.org? That “login” box is simply a CSS overlay that can be removed in about three steps using one of my favorite tools, Firebug.

Update: Somebody asked where they could find more resources about Threat Modeling. Microsoft is actually one of the best places for this and the Application Threat Modeling page and Threat Modeling blog provide hours of endless entertainment. They also have a fantastic Threat Modeling Tool that greatly helps the process. Free, no less! And they are apparently releasing an update soon. I’ve had the pleasure to work with Microsoft in the past and they are very dedicated to the Secure Development Lifecycle. (*I’ll ignore the peanut gallery’s comments about the recent out-of-band patch, but that actually is a good example of how well their process works*)