Skype Account Hijack Attack: Lessons Learned

relying on the guys in the white hats to prevent attacks like the Skype account hijack attack

There’s been a flurry of online discussion the past few days about a Skype account hijack attack. Apparently it was first documented several months ago on a Russian-language web site. Today The Next Web posted an article, “Security hole allows anyone to hijack your Skype account using only your email address (updated)” which describes the nature of the attack in a little more detail.  While not outright confirming the story, Microsoft has issued a statement indicating that they have temporarily disabled the account password reset procedures as a “precautionary step.”

Reading through the description of the Skype account hjack attack on The Next Web, it appears that the core issue is that you could convince Skype to send a password reset token to the Skype web application even though you weren’t logged into the account.

As always in these situation, I think it’s important not to point fingers, scream about lack of security and shame companies that “should  have known better.” Instead it’s important to think about when/how the flaw could have been prevented and what controls appropriate for preventing a future Skype account hijack attack style attack.

Controls for the Skype Account Hijack Attack

From what I’ve read of the Skype account hijack attack, it is yet another attack on a password reset procedure. Apparently password reset attacks are one of the most vulnerable aspects of public facing web applications today. So what can be done about them? Why do these keep popping up over and over again.

As I’ve said in this blog many times. The guiding principle should be “A credential can only be protected by a credential of equal or greater strength.” That’s why it’s so important that we stop using the knowledge of personal information to allow passwords.

But the Skype account hijack attack didn’t rely on knowledge of the victim’s personal information other than their email address. As I understand the various explanations of the attack that are floating around, the vulnerability that was exploited was an ability to convince Skye to send a password reset token to the skype application in addition to (or instead of?) sending the password reset token to the victim’s email address.

In typical password reset scenarios, you go to the service website and request a password reset. They service sends an email that contains a one-time use  password reset token encoded in a link. You go login to your email account, open the mail, click the link that has the token. That effectively authenticates you to the service that then lets you reset your password. The act of logging into your email account is establishing an alternate, equally strong credential to use for the password reset. So this is consistent with the principle stated above.

The problem in the Skype account hijack account was that it was possible to convince the Skype web application to give you that reset code instead of making you get the code out of the email.  So the question is how could this have been detected as a problem before it was exploited?

Could this have been detected with an application source code scanning tool? Maybe. Source code scanners are getting better and better at understanding the model of the application and understanding the flow of information across modules in an application. But unless a human being had tagged the password reset token as being security related, it would be difficult for a code analyzer to know that a password rest token was appearing in the web application where it shouldn’t be.

Could this problem have been detected by an dynamic application scanner like IBM Security AppScan? Maybe. But again, you’d need to tell AppScan to look for that reset token and flag it as a problem. Once you reduce the problem to looking for a particular type of pattern, scanning tools are diligent. But the other problem with dynamic application scanners is that they often have to be trained to follow navigation paths through the application. But attackers are much more inventive and specialize in finding oddball ways to interact with the application which the scanners may not be trained to follow.  So I’d not bet on that kind of technology to detect or prevent attacks like the Skype account hijack attack.

The problem is that you need an ability to understand when the current execution environment is covered by an appropriate credential and when it’s not. We need something that can say, “Whoa! A security token exists in a run-time context that is not covered by an appropriate credential.” That requires a run time model of the application and it requires a run-time model that has security awareness.  So it seems to me that the Skype account hijack attack highlights the need to use threat modeling and risk analysis tools.

In this day and age of agile development, constant deployment, and minimizing back-end design documentation etc, modeling tools don’t seem to be much in fashion. Who’s got time to invest in creating and maintaining a model like this?  I’d be interested in hearing examples of companies/organizations/people investing in these sorts of models and how they can be kept up to date efficiently and integrated smoothly into an agile development environment. So please send them my way.

Meanwhile, I think we’re doomed to relying on hackers for exploring deployed code for these types of weaknesses that lead to the things like the Skype account hijack attack. I’m not sure we can do nothing but hope that the penetration testing white hats find these vulnerabilities before the folks with the black hats do.

photo credit

Leave a Reply

Your email address will not be published. Required fields are marked *