Posted on 2020-07-21 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.
Even with the greatest of anti-phishing and anti-malware security stack, social engineering attacks are extremely difficult to stop. In our social engineering exercises we may call a 5% response rate to a social engineering attack a good result, but for many organisations just having one response is a catastrophic scenario.
Many guides when they talk about social engineering talk about user training and “users being the weakest link”. While security awareness is important, the social engineers are smart. It’s almost impossible to tell the difference between what is real and what isn’t. Why are we blaming users when they’re being put in an impossible situation?
It’s easy, then, to throw your hands up and say “there’s nothing we can do”. That’s not really good enough in this day and age, and it’s definitely not good enough for a company like Twitter that has become part of the basic infrastructure of the internet.
I don’t have any more information about the Twitter breach than is public, but it’s interesting to look at what kind of security controls may have helped Twitter stop or limit this attack. I’ve written up a two part post on some of these security controls that might just have helped Twitter.
Today’s blog post goes over all the multi-X controls. What we’re looking for here is to stop putting all our eggs in one basket and to reduce single points of failure where if an attacker compromises one thing then we’re gone.
Multi-factor authentication
We should all be familiar with this one. MFA is becoming standard everywhere and is an essential security control to stop a user’s account being compromised. The Essential 8 maturity model says that security-conscious organisations should use MFA externally for all remote access and internally for administrator functionality. That’s a good guideline for all organisations in my opinion.
As critical-a function that MFA is, it might not protect you in the case of a successful social engineering attack. If the attacker has access to the user’s phone or laptop, then the attacker will have access to the user’s browser and will be able to access the account anyway. If the social engineering attack is really good they can ask for the MFA token at the same time and proxy that token through.
If we’re going to get to the level you’d expect Twitter to be at, we need something more. This brings us to…
Multi-party authorisation
You know the scene. They’re about to launch the bomb. The two agents get out their keys and turn at the same time and the light goes green.
This is a security control known as “multi-party authorisation”. The idea is to prevent the case where one person goes rogue. You ensure that at least two people must give their authorisation before things are executed.
With a multi-party authorisation scheme in place if one person is compromised then the damage is limited. By themselves they can’t do much. The attacker would need to compromise multiple people to have any hope of getting anywhere.
Multi-party authorisation is different from a regular sign-off where you need a superior or relevant authority’s go-ahead. It is a technical control where the system will not move forward without the additional explicit authorisation. The second party also doesn’t necessarily need to be a superior, but could also be a peer. What’s important is having two or more people.
The idea of some sort of multi-party authorisation is huge in finance, with large financial transfers often needing two sets of signatures before they are executed. It helps stop the guy that transfers all the money and then runs off to an island somewhere drinking mojitos.
Great, now we need more than one person, so if any one person gets their device popped we’re still good. But there’s still the single source of failure there. What if the attacker goes after the system itself?
Multi-system authorisation
The application makes sure that more than one person needs to give authorisation to make a change – the user makes the change and another user in the same application clicks “yes I would like to authorise that change”.
What if the application itself is compromised? If that happens then the attacker would be able to both make the change and authorise the change through the compromised application. An administrator of the application would also likely be able to do the same thing, making that administrator a single source of failure and a good target for attack.
To stop this we might want to implement multi-system authorisation. This will make sure that the initiating path and the authorisation path are through two separate systems.
The way this is implemented in practice is to have multiple loosely coupled systems connected by APIs or something similar. These systems are:
- The initiating system, where the initial request is made
- The authorising system, where the authorisation is provided
- The execution system, which makes the change itself
This doesn’t need to be complex – the authorisation system could be something like Slack, for example. By having this separation you can ensure if the initialising or authorising system is compromised the attacker can’t singularly make those malicious changes.
The main consideration here is of “security boundaries”. Are all these systems on the same web server? Are they administered by the same people? Are they all connected to AD such that a domain admin account has full control over them all? If any of these are the case, then there’s not an effective security boundary there. What we’re aiming for here is to remove the single sources of failure where if one system is compromised then the entire process gets corrupted.
Eggs separated out yet?
With our single sources of failure reduced, in the next part we’ll look at other ways of stopping this kind of attack. In the meantime, if you need help with your security reviews or security strategies, putting in multi stuff or if you’d like us to try and break in and see if we can make malicious changes, contact us at Volkis!
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