On the Twitter hack

Preface

Let’s first get this out of the way: The Twitter hack of July 2020 could have ended a lot worse, all things considered. Using the access they got to run a simple Bitcoin scam is one of the least damaging things that they could’ve done, considering the current socio-political climate. I don’t believe I’m exaggerating when I say that these kids could have started a serious conflict if they were a bit more subtle and patient in their methods. But most of my thoughts on this are not about what they could have done, but rather what Twitter got wrong in avoiding this.

Bad design

Giving employees, even your most trusted ones, access to a tool that has unrestricted access to any account is simply not acceptable.
While I lack detailed insight into Twitter’s administrative processes, there is most likely a lack of simple security controls; Something a basic as entering a 2FA/TOTP code before reading sensitive date or performing the likes of a password reset would likely have prevented this attack from succeeding.

An alternative I’ve heard some people bring up would be to have another support operator confirm “risky” actions before they are actually effectuated. Personally, I think this is an even better option, but not a very easy one to implement due to the sheer size of Twitter’s userbase compared to the support team.

It’s not clear how the attackers managed to access these internal tools. I would expect them to be available only when connected through a VPN, so that may indicate that a support operator got spearphished. A zero-trust design like BeyondCorp could have prevented this, and may be worth considering for a company like Twitter.

To Twitters defence, they were able to conduct an investigation based on the logs that this tool generated, indicating a pretty good logging policy. Unfortunately for them, the damage was already done of course. Even with adequate logging in place, this incident demonstrates that it’s a bad idea to build such a tool.

Decent response

Not all is gloom however, Twitter did respond within an acceptable timeframe and with well thought-out measures. The blocking of all verified accounts tweeting may seem excessive, but at the point in time they made that decision Twitter did not know what was going on yet.
While the account checkout feature was not blocked in time (8 accounts had their data exported), it may have still prevented other users from having their private data leaked in the same way.

While the investigation is still ongoing, most of these features remain disabled. Verified accounts regained the ability to tweet fairly quickly, but password resets and the account checkout feature are still disabled at the moment.

Improvements to be made

The most important improvement that Twitter can make is to restrict their internal tool’s abilities. While it may be useful for the helpdesk to be able to change a user’s email, it does open up the potential for abuse. Apparently, users did recieve a mail that their email addresses were changed, but that’s not a warning: It means things have already gone wrong.

Additionally, Twitter should actively push for users to enable 2FA, and make it impossible for support operators to easily disable it. Immediately sending an email or text message to the users when it’s disabled, and only allowing the account to be logged into without the 2FA after 24 hours would definitely have stopped this compromise from happening.

Closing thoughs

It’s unfortunate that this has happened, especially considering that it seems like it would have been avoided by implementing a few basic security controls.
Twitter responded adequately and is providing updates on their investigation, and although this shouldn’t have happened in the first place, they seem to be taking responsibilities.

I’ll be awaiting the post-mortem with great anticipation, to see if they’ve learned enough from this incident to prevent similar issues from occurring.