So while the tool did not directly have the ability to tweet, it effectively did.
Also, admin tools are often "afterthoughts", there is usually a motley collection of them, and often considered as an expense/cost to be minimized and not a revenue generating asset that gets more budget and attention.
Of course, some of the targeted users presumably had 2FA enabled. How to do account recovery with 2FA in a consumer context is a complicated problem and I'm not aware of any good answers, but there's certainly an argument that the protections in place there weren't adequate and I wouldn't be surprised to see them changing soon.
I would also hope that rank-and-file support staff can't change users' email addresses, and the attackers had to spear-phish one of a smallish number of people whom more complicated account-recovery cases are escalated to. But who knows if that's how it works.
I've always wondered why there isn't more use of time delays for this sort of thing.
If there was a notification e-mail and a 7-day wait, that would offer a fair chance for the real account holder to cancel the change. Not 100% - the user might be on holiday - but it would catch a lot, and hence decrease attackers' motivation. And while a 7-day wait is inconvenient, for services like Twitter and Steam losing access for a week isn't the end of the world.
We had a running gag in our social media startup of tweeting "poop" from people who left their phones/computers unlocked ... someone did it to an employee that was logged in as a customer (corporate brand) context and that was the end of that 'joke'.
> For 45 of those accounts, the attackers were able to initiate a password reset, login to the account, and send Tweets.
Furthermore, they're a classic cost center, not a lot of love or budget goes into reducing their tech debt, or bulwarking them up against a sophisticated adversary. Red teaming yourself full time is expensive and not profitable. What's the worst that happens from a breach like that? Well, Equifax is still going strong!
I recall being party to an amusing conversation at a major network services provider at a team meeting for people with access to such tools, to the effect of:
- Alright, we're modifying <internal tool A> to lock down access to accounts related to <major political figure>. You will no longer be able to use <internal tool A> on <accounts>, only select supervisors will have that access.
%%% ah, okay, that makes sense
# uh, hey, regarding <internal tool B>, which allows us to look up <thing that would provide equivalent access to internal tool A>? does that still work the same?
- Uh, yeah, it does.
# okay?
%%% ... silence ...
- Alright, next item!
To the best of my knowledge, that was never addressed. <internal tool A> has audit logs. <internal tool B> doesn't.
I don't know what all Twitter uses, but I know that many companies have various methods of authentication depending on how much damage can be done:
- Logging on using a username/password and 2FA is enough for some activities.
- More sensitive operations have to be done on hardware that has a certificate installed and backed by something like Windows Hello.
- Even more sensitive operations require a JIT account and a certificate stored on a separate hardware key such as a yubikey.
- Very sensitive work gets done on a secure device that is very locked down and can detect changes to the hardware that may suggest tampering.
- Some stuff simply isn't allowed to be done remotely, even with the above restrictions.
Obviously not every company needs such a complex setup, but for someone as high profile as Twitter, you'd expect more thought to be put into this.
This isn’t the right way to do it, but given they work at Twitter I could imagine this isn’t the first big mistake they’ve made.
If that is the case, that same proxy software could proxy the security key requests too.
Are you sure there wasn't a notification?
https://krebsonsecurity.com/2018/07/google-security-keys-neu...
https://medium.com/@antonisikora/how-u2f-security-keys-can-e...
But I don't know what "The right kind of xss vulnerability would enable them to bypass 2fa too" means. If the attacker doesn't have 2FA I would think the attacker can't log in, thus meaning the first link of the chain has no purpose.
But I also think XSS in this case is not very likely. From interviews with the attackers it sounds like they're social engineering experts who hang out on social engineering forums, not XSS experts[1][2][3].
[1] https://krebsonsecurity.com/2020/07/whos-behind-wednesdays-e...
[2] https://www.nytimes.com/2020/07/17/technology/twitter-hacker...
[3] https://krebsonsecurity.com/2020/07/twitter-hacking-for-prof...
for a moment I thought it read `tweeting from 45's`
Hands down the easiest way to make Shaun Cassidy sound like one of the Chipmunks.
Many security researchers have already established that the benefits of a VPN especially in the modern distributed world are marginal at best.
Basically, yes a VPN makes you a tiny bit safer but it also adds a lot of networking complexity and adds more friction to the job of your employees. It also becomes an attack vector for malicious parties, since once they get VPN access they can theoretically access at least the first layer of protected resources.
So in layman's terms an attacker just needs to phish for VPN credentials, maybe steal an OTP token and they will have access to a non-trivial amount of network protected resources.
On the other hand if every service you use has its own authentication then the attacker needs to target each service and to know what services to attack they need knowledge that is possibly contained in another system that also requires authentication and is definitely not guaranteed for the attacker that all the systems will have the same password and/or have 2FA disabled.
Honestly, in my opinion VPNs are just an excuse to monitor traffic. This is a bit of cynical take, but I'm convinced that companies that use VPNs are more interested in seeing what goes in and out their network than in protecting their resources.
If your enterprise is a global network with millions of nodes operating a blend of modern and legacy systems accumulated through hundreds of acquisitions in 100+ countries over the course of the last 50 years, a VPN with hardware tokens isn't a bad additional layer. It isn't even mutually exclusive with zero trust, it's just another layer of auth and access.
Twitter? Largely a different story and commando zero trust might be a viable option. As observed many other places, this sounds like a poor authentication model and probably poor governance for highly privileged access. Presumably they will take a look at their authentication, which sounds like it's making some bad assumptions, and improve.
This would be a nightmare for the people managing any nontrivial system. There are good reasons to use something like Active Directory and tie systems and applications to it for easier policy enforcement and management. There are good reasons to avoid this centralization for certain things too. Either extreme would be an exercise in frustration.
I’m not so sure that it works that well once it becomes the actual authentication middleware. But as a single sign on directory it definitely reduces the complexity for the employees and for IT departments.
Either way I think more than systems, people need training. I know there are sophisticated phishing attacks but someone who has been trained to understand and acknowledge these situations should be able to detect when someone is trying to steal information.
I think Twitter’s failure was to not properly train their employees especially when they are such a visible and juicy target for bad actors.
Yes, with the (wrong) assumption that after you have connected to a VPN, all other services are free for the taking, without any further authentication.
On our vpn we require a non-exportable certificate in the tpm chip, normal user credentials, then we have a captive portal that forwards to our SSO that requires a yubikey.
Consider this: * You go to your office, connect to the network * Now you have access to internal services, by virtue of being on the network
In a Zero Trust network it does not matter what network you are on. Trust is handed out individually, based on the identity/ role of the user and the context of their session (is their os patched? running security tools?).
The attacker can surely use a patched OS. Are the security tools secret? If not, then the attacker can run the security tools too.
User agent is a great place for a version 0, sure. 99% of your assets aren't compromised, so worrying about a bypass isn't important to most of them. For a v0 just knowing that most of your boxes are patched is a huge win.
Of course you'll want client certificates on devices, or some sort of TPM, which is how Chromebooks work. The attacker having a box is not enough - identity is a key principal of zero trust networks.
Security comes in layers. That first layer of requiring a VPN can stop many types of attacks from happening.
Next layer is requiring MFA for VPN access. Then for admin access, require MFA only from approved devices on the domain.
Large banks and the DoD have been doing this for years.
The "fail often and fail fast" crew are always reinventing the wheel after bad experiences. I honestly feel sorry for them.
> The social engineering that occurred on July 15, 2020, targeted a small number of employees through a phone spear phishing attack. A successful attack required the attackers to obtain access to both our internal network as well as specific employee credentials that granted them access to our internal support tools. Not all of the employees that were initially targeted had permissions to use account management tools, but the attackers used their credentials to access our internal systems and gain information about our processes. This knowledge then enabled them to target additional employees who did have access to our account support tools. Using the credentials of employees with access to these tools, the attackers targeted 130 Twitter accounts, ultimately Tweeting from 45, accessing the DM inbox of 36, and downloading the Twitter Data of 7.