I feel sorry for Twitter – they have the poster child of low value apps (which usually means no security controls or review), and then all of a sudden, they get done over using such a simple attack that it’s generous to call the attack a “hack”. Of course, because of the targets – Barak Obama, Stephen Fry (the world’s best comedian bar none), who are HIGH value targets, Twitter is feeling the pain of applied media heat today.
Twitter on Monday said the hacker had broken into 33 accounts by gaining access to tools used by its support team.
“These accounts were compromised by an individual who hacked into some of the tools our support team uses to help people do things like edit the email address associated with their Twitter account when they can’t remember or get stuck,” wrote Twitter co-founder Biz Stone in a blog post. “We considered this a very serious breach of security and immediately took the support tools offline. We’ll put them back only when they’re safe and secure.”
– from ZDNet
If Twitter had simply built their software (in 2006) to follow the 2005 OWASP Guide 2.0, they would have been safe today in 2009.
I cribbed and re-phrased these from the 2002 Guide 1.0, which were in turn cribbed from the seminal Saltzer and Schroeder’s 1975 paper. This stuff is not new.
- 5.1 Minimize attack surface area
- 5.3 Principle of Least privilege
- 5.4 Principle of Defense in depth
- 5.7 Separation of duties
- 5.8 Avoid security by obscurity
This is all about application architecture. If Twitter had designed their admin app to be non-reachable from the Net, the attack would have failed. If they had made users unable to perform admin tasks, they would have been safe. If they had defense in depth, they would at the very least known about the attack. If they had separated admin tasks from user tasks properly, they would have been safe. If they had not hidden the URL or parameters to the admin interface, they would have been safe as it would have been unreachable.
These are all design time considerations, one that is ultra important … even when you design a low value application.
- Principle of least privilege
- Centralized authorization routines
- Authorization matrix
- Controlling access to protected resources – All functions must be access controlled
If ANY of these had been followed, they would have been safe.
- Best practices – describes the Twitter issue completely. It would be the new example if I was writing this today.
- Users are not admins, admins are not users.
- Divide the admin interface off into its own app, unreachable from the Internet.
If ANY of these had been followed, they would have been safe.
In general, we know and have documented the solutions to these ultra common issues. Here’s my rule of thumb – if you design insecurely, you WILL be broken into. Security Architecture is a MUST.
Leave a Reply