ThreatVector is an ongoing series where we break down recent security incidents in the news to understand how they happened, how they spread and what the ramifications are for companies as they evolve their defenses.
The messaging and communications giant Twilio was attacked via a social engineering on August 4, 2022 with an unknown number of employee accounts being taken over but 125 customers impacted. There are a few notable attributes about this attack:
- Twilio employees were targeted with fraudulent SMS communication supposedly from their IT department using words they expected like “Okta” and “SSO”
- Twilio’s Two-Factor Authentication (2FA) was neutralized or bypassed somehow
- Twilio appears to be the beachhead, not the primary target, which was at least 3 end-user services:
- Authy, a 2FA product purchased by Twilio in 2015
- Signal, a secure messenging service
- Okta, an identity provider and 2FA product
The ultimate result of this breach was unauthorized devices being attached to several Signal accounts, with the likley goal of intercepting communications on those accounts using devices under the attacker’s control. 93 Authy accounts were also accessed, with a potential compromise of any accounts protected by 2FA for those users, due to the attacker obtaining the secret second factor. Similar to Authy, 38 Okta user’s 2FA codes were also accessed.
We’ll break down #1 and #2 first to understand how the beachhead was established, then discuss the traversal to the final targets.
Bypassing Twilio’s defenses
Twilio employees were tricked into providing username and password details to a malicous URL, which per Twilio, “seemed to have sophisticated abilities to match employee names from sources with their phone numbers.”
There aren’t a lot of details about which parts of Twilio infrastruture were accessed or if there were further exploits used to gain access to the more sensitive parts of the infrastructure.
What is clear is that one of Twilio’s “crown jewels” workflows, the handling it’s messaging content for device or phone number verification, was breached. It’s safe to assume that the attacker understood that Twilio employees had elevated access to the verification codes being used by Authy, Signal and Okta, either through customer support functions, logging or debugging infrastructure, or through the queues and databases that allow Twilio’s messaging to function.
At EdgeBit, our philosophy is that every threat should be treated as an insider threat and that no humans should have access to sensitive data from production systems.
Malicious deviced added to Signal accounts
Signal follows a practice of extensive “defense in depth” throughout their infrastructure. They strive for zero knowledge and encrypted messaging end-to-end.
EdgeBit applauds them for their use of secure enclaves for processing the address books of their users — one of their “crown jewels” workflows. The enclave’s cryptographic properties disallow outside introspection of the data processed within, guarantees that the enclave code running is unmodified and only predefined outputs can be egressed back to the Signal user.
In this attack, one of the remaining weaknesses in Signal’s architecture was exploited — addition and removal of devices from your account. Reading message traffic is easy once you’re deemed a valid recipient.
Signal uses cell phone numbers as a means of user identity and to verify the ownership of them, a text message (powered by Twilio) is sent with a verification code. These verification codes were intercepted by the attacker and used to enroll devices under their control.
Increasing security and defense of “in-use” data
While it’s impossible to postulate about defending a specific software stack or system inside of Twilio, it is safe to say that somewhere there was customer message content that was able to be accessed by employees. This article isn’t meant to throw Twilio under the bus and there are a ton of things they did correct in handling this incident. Their communication and summary of the incident was excellent and timely. They had the correct audit trails in place to execute a swift investigation. They had tools to block the spread of the malicious URLs to their employees after identification.
This incident exemplifies the EdgeBit belief that we’re starting to hit the limits of reactive security tools and your engineering team’s existing toolbox for proactive defense won’t survive today’s threats.
Protection for data “in-use” within your applications and within your databases is essential for removing access to any human, especially for your “crown jewels” workflows. App-layer encryption and ensuring all decryption happens inside of a secure enclave gives strong guarantees that even access to a production environment is not enough to exfiltrate your data.
More from EdgeBit in the future
We’re looking for design partners to influence how we tackle the wider journey of building security-centric and privacy-preserving features of their SaaS applications. We would love to chat about your ideas and test out our software.
If you’re a customer of a SaaS platform and want to influence the platforms you are already using, we would also love to hear from you.
