Posted on 2020-07-22 by Matt Strahan in Business Security , Social Engineering
Last week Twitter had a successful social engineering attack that pushed through a Bitcoin scam. The scam netted about $120k for the scammers, but for Twitter it caused huge damage to their brand with the news of this attack going around the world.
Although we don’t have any hidden information about the Twitter hack that’s not already public, I thought it would be fun to look at the kinds of security controls that would help stop this kind of attack.
Yesterday we looked at all the multi-X controls. Today we’ll be looking at other strategies that can help mitigate the compromise.
The greater the impact, the greater the authorisation requirement
I created a twitter account quite recently and as a new Twitter account I currently have a grand total of 22 followers. I’m not exactly an influencer.
As important as those 22 followers may be, I must admit that it might be of greater impact if Elon Musk or Barack Obama has a malicious tweet posted than if I do. With 120 million followers, Barack Obama beats me by roughly 120 million followers.
When designing the workflows and processes for systems like Twitter, it’s common to look at things from a functionality point of view. You identify the risk: “Someone can make malicious tweets”. The risk is quantified and treated.
This method of risk identification ignores that functions can have wildly different risk profiles depending on the context. Inserting a tweet into my account (as important as I am) and inserting a tweet into Barak Obama’s account are the same function from a coding point of view, but from a risk point of view they are completely different.
This greater exposure should be considered when designing those workflows and processes. The authorisation level might be higher, for example, potentially requiring even executive level authorisation for making changes to those accounts. There might even be a completely different system that handles the administration of those high profile accounts that has greater security controls applied and more limited access.
Before designing this system though, one thing needs to be considered…
Does this functionality even need to be there?
It might be a bit strange to think about, but why would any Twitter employee ever need to be able to post tweets on behalf of a Twitter user, especially a verified public figure with millions of followers? Would there ever be a reason for a Twitter employee to be able to post on behalf of a former president?
For other methods of obtaining account access, does there need to be a publicly accessible forgotten password function for high profile users or could you use a more direct method of recovering accounts? With the relatively low number of high profile users, they could keep authorised personnel on file and give them a call if there’s an issue.
A lot of developers just put in functionality because they can, but sometimes the functionality doesn’t really need to be there. For high-risk functions like this, sometimes the organisation should take a step back and figure out if there’s a real use case that justifies the risk of the function being misused.
There’s an old saying that “the most secure system is one that’s off”. You know it’s not exactly true – it’s much harder to hack a system that isn’t there. It’s very hard to make API calls to an endpoint that hasn’t been implemented and it’s very hard to maliciously trigger a function that hasn’t been coded.
In practice this is an often overlooked risk treatment in the risk assessment process. You identify a risk, say of malicious tweets by compromised insiders. Often the risk treatment will be “raise the authorisation level” or “put in greater security controls on the insiders’ systems”. It’s a different way of thinking to go “remove the code so insiders can’t put tweets in user accounts”. People don’t like deconstructing or removing things even if it makes everything more secure.
Sometimes though it’s just better to remove it. You can’t hack what’s not there!
Effective logging and incident response
Even with the best security controls, with multiple levels of authorisation, multiple system requirements, sensible risk profiles for greater exposures and the removal of unnecessary functionality, things might still get through. To mitigate the impact of the compromise we need effective logging and incident response.
The startling part of the Twitter breach is that it took hours to stop and resolve. There are two things this might indicate:
- They weren’t able to detect which account(s) performing the compromises; or
- They weren’t able to revoke the access of those accounts.
Both of those aspects are rather surprising. Audit logs are critical for tracking potential compromises back to the location of compromise and there should be trained personnel who are able to take immediate action when a compromise happens.
Incident response is a huge topic, but in this particular instance I’d like to focus on one little piece of it: scenario based wargames. For Twitter I would have expected inserting malicious tweets to be the first on the list of scenario based wargames performed when considering incident response. It’s the number one risk, you’d expect.
The best way to perform this is to simply make a change (with the cooperation of the owner of the account of course) and see if everyone knows what to do. This should have all been practiced before it happened in real life.
A compromise shouldn’t lead to a catastrophe
In these two posts we looked at multi-X authentication and authorisation, risk profiling, removal of functions, and incident response. All of these controls form part of a mature, secure organisation. We know that phishing and social engineering is effective and so we must implement controls to limit what happens when people get their systems compromised.
At Volkis we can help on the advisory, analysis, and audit of these controls. If you would like to test your users in social engineering attacks, test your systems with penetration testing, or go a step up and perform a high level red team engagement where we acts as a persistent adversary, contact us now!
About the author
Matthew Strahan is Co-Founder and Managing Director at Volkis. He has over a decade of dedicated cyber security experience, including penetration testing, governance, compliance, incident response, technical security and risk management. You can catch him on Twitter and LinkedIn.
Photo by Morning Brew on Unsplash.
If you need help with your security,
get in touch with Volkis.
Follow us on Twitter and
LinkedIn