Advertisement

Security leaders at Okta and Zscaler share lessons from Salesloft Drift attacks

Okta thwarted the supply-chain attack with security controls it had in place. Zscaler did not. Their experiences provide insights into the root of a much broader problem.
Listen to this article
0:00
Learn more. This feature uses an automated voice, which may result in occasional errors in pronunciation, tone, or sentiment.
(Getty Images)

When security researchers issued warnings about the Salesloft Drift issues last month, two prominent cybersecurity companies found themselves facing the same threat — but their stories ended up unfolding in different ways. 

Okta and Zscaler, among the larger players in the identity management space, were among the more than 700 Drift customers targeted in what has become one of the most significant supply chain attacks of the year.   Within a week of Google security researchers’ warning about the incident, which targeted the widespread theft of Salesforce customer data, both companies went to work in figuring out how bad the damage would be.  

The companies had very different experiences. While Okta’s security measures thwarted any lasting damage, Zscaler wasn’t as lucky, having to deal with unauthorized access of both customer and internal company data. Same threat actor. Same timeline. Opposite outcomes.

The divergence in incidents and responses offers a rare opportunity to understand how a cybersecurity strategy works in action. CyberScoop spoke with the security leaders of both companies to learn about how the attack went down from those directly in its crosshairs, and lessons learned that could bolster defenses of their companies and others going forward.

Advertisement
From warning to incident

Salesloft hasn’t publicly released a comprehensive root-cause analysis into the attack, but initial results of its investigation revealed a threat group gained access to its GitHub account as far back as March. The group, which Google tracks as UNC6395, achieved lateral movement and set up workflows in the Salesloft application environment before it accessed Drift’s Amazon Web Services environment and obtained OAuth tokens used by Drift customers. 

Those tokens allowed the threat group to access and steal data from separate platforms integrated with Drift, an AI chat agent primarily used by sales teams. Google said the “widespread data theft campaign” occurred during a 10-day period in mid-August. Nearly 40 companies, including more than 20 cybersecurity vendors, have publicly disclosed they were caught up in the attack spree.

Zscaler received its first security alert from Salesforce a week after the data theft concluded, warning the security vendor that unauthorized IP addresses were using the application programming interface (API) for its Drift OAuth token. Zscaler immediately revoked the token, “even though it didn’t really matter by that point,” said Sam Curry, the company’s chief information security officer.

The damage was already done. Data on a large number of Zscaler’s customers was exposed, including names, business email addresses, job titles, phone numbers, location details, Zscaler product licensing and commercial information, and plain text content from some support cases. 

Advertisement
IP limitations for defense

Since Okta uses Drift, it proactively hunted for signs of compromise when threat intel experts started warning about an issue with the service. The company found a “short burst of attempts” to use Drift tokens from locations outside of the manually configured IP range it set up for security purposes, David Bradbury, Okta’s chief security officer, told CyberScoop.

That control blocked the attack and kept Okta’s Drift integrations secure. Yet, many companies don’t take that approach because setting IP restrictions for API calls is a manual and often laborious process requiring input and support from every vendor in the supply chain. 

“If we can put our minds to these problems, we can come up with solutions so that you can implement IP restrictions in a matter of clicks, rather than in a matter of days and weeks of continuous testing, and investigation and discovery,” Bradbury said.

Okta’s investigation revealed a seemingly automated threat campaign. “They were not persistent,” Bradbury said. “The hypothesis that we have at the moment is that there was a single significant script that was engineered that hit all of these all at once and pulled down all of this information in a series of events.”

Advertisement

Zscaler’s compromise was particularly frustrating given the timing: the company had already stopped using Drift in July, a decision completely unrelated to security — and made before any indicators of the attack campaign came to light. 

“That OAuth token that was being used with [Drift] was still active,” Curry said. “It was due to be retired by the end of August,” he added, describing that decision as a deliberate delay to make sure the token was fully disconnected and no longer in use. 

Token theft cause remains a mystery

Salesloft hasn’t explained how the threat group accessed its GitHub account, nor how it accessed Drift’s AWS environment and ultimately obtained customers’ OAuth tokens. 

“I don’t actually know how they got the tokens out. I just know they did,” Curry said. “As for how they store it, I don’t know internally, except that they passed our security questionnaire and probably hundreds, if not thousands of others” for third-party risk management, he added. 

Advertisement

Okta also doesn’t know how the threat group accessed its Salesloft Drift OAuth token. That information would have to come from Salesloft, Bradbury said.

“The internet is connected by some very brittle, small pieces of information — these tokens that we constantly talk about, these combinations of letters and numbers in files that ultimately provide access to all of the applications that we use,” he said. 

“Those tokens need to be stored somewhere, and sadly there are mechanisms in place right now which doesn’t necessitate actually tying these tokens directly to something — to prevent their reuse,” Bradbury added. 

Most SaaS applications implement tokens and authentication in rather rudimentary means. “They’re doing what’s easy and what works, and what works is once you’ve granted access you’re actually storing these tokens somewhere,” he said. 

Lessons learned for collective defense
Advertisement

While their experiences in the wake of the Salesloft Drift attacks were quite different, Bradbury and Curry shared similar reflections and took many like-minded lessons from the third-party compromise that impacted hundreds of companies. 

“APIs are becoming a new highway of access that we need more control over, and we need better control of collectively,” Curry said. “APIs get wider in terms of what you can do with them, and you need the ability to monitor them and to put preventative controls on them to look for behavioral changes.”

Zscaler learned another lesson the hard way — the importance of limiting IP address ranges for API queries, and rotating tokens more frequently. 

“For me, this wake-up call is saying API is a new attack-and-control plane that’s far more exposed than most people realize from just a simple risk exercise,” Curry said.

“There are no small vendors in an API-connected world. It’s just like — if you think about border security — there’s no small and insignificant ports of entry,” he added. “They all use the same highway systems.”

Advertisement

Bradbury, who is expectedly pleased Okta wasn’t impacted by this malicious campaign, can’t help but feel frustrated because he believes there are better, more secure methods to protect unauthorized token use. The central issue in this supply-chain attack could have been avoided with Demonstrating Proof of Possession (DPoP), a mechanism that can constrain token use to a specific client and prevent the use of stolen tokens, he said. 

Once attackers steal tokens that can be reused without restriction, disastrous consequences await all, Bradbury added. 

“We need to see more SaaS vendors actually prioritizing security features on their roadmap, not just the features that will result in customer growth and revenue,” he said. 

Security leaders have an important role to play in demanding these changes from their vendors. “It’s about time that we started to use our collective ambitions to raise the bar for security to actually hold our vendors accountable,” Bradbury said. 

Curry is taking a similar forward-looking approach. “Let’s learn from one another, instead of bayoneting the wounded,” he said. 

Advertisement

“After the fact, in the cold light of day, we’ll all look at what happened,” Curry added. “I’m not interested in blame at this point. I’m interested in better security.”

Latest Podcasts