The Okta Mess Is Even Worse Than It Appears
On March 1, 2022, Okta, the cloud-based identity management company, was going great guns. Okta’s fiscal year 2022 revenue had just come in and it totaled $1.30 billion and had grown 56% year-over-year. Its customers included FedEx, Moody’s, T-Mobile, JetBlue, and ITV and it was Federal Risk and Authorization Management Program (FedRAMP) approved. What could go wrong? Three weeks later we found out.
The hacking group LAPSUS$ revealed that they’d gotten their way into Okta’s systems and showed off screenshots to prove it. On Telegram and social networks, LAPSUS$ mocked Okta saying, “For a service that powers authentication systems to many of the largest corporations (and FEDRAMP approved) I think these security measures are pretty poor.”
Okta’s Reply
Okta replied that there was little to see here:
In late January 2022, Okta detected an attempt to compromise the account of a third-party customer support engineer working for one of our subprocessors. The matter was investigated and contained by the subprocessor. We believe the screenshots shared online are connected to this January event.”
Okta concluded, “Based on our investigation to date, there is no evidence of ongoing malicious activity beyond the activity detected in January.”
Later the same day, Okta Chief Security Officer David Bradbury admitted, “After a thorough analysis of these claims, we have concluded that a small percentage of customers — approximately 2.5% — have potentially been impacted and whose data may have been viewed or acted upon. We have identified those customers and already reached out directly by email.”
That doesn’t sound like the information you usually find on a third-party customer support engineer laptop to me.
Nature of the Attack
Subsequently, Okta said an attack had actually been made on Okta via a Sitel support engineer’s computer. The attacker had started a Remote Desktop Protocol (RDP) session on the laptop. From there, the attacker used Okta’s customer support engineer Super User application. Despite the scary name, Okta states that it only gives read access to some files. More worryingly, Super User could reset passwords and multifactor authentication (MFA). That’s big-time bad news.
Sitel admitted there had been a security breach in January but didn’t confirm the exact details of the breach. Okta would eventually admit that the attacker had potentially had access to Okta’s data for five days.
Still, Okta insists that while data could have been collected, such as Jira tickets and user lists, there was no impact on Auth0, HIPAA, or FedRAMP customers.
Okta is admitting, however, that since it had known about the potential security invasion since January, the company really should have notified its customers then. Instead, the company waited until after the LAPSUS$ fox revealed to the world it had been in the Okta chicken house.
Worse Than Initially Admitted
Now, it appears the attack was even worse than Okta first admitted. Independent security researcher Bill Demirkapi tweeted, LAPSUS$ created “backdoor users in Sitel’s environment after retrieving an Excel document conspicuously titled “DomAdmins-LastPass.xlsx”
Yeah, that’s rather a big red flag there.
Demirkapi asks the very good questions: “My questions for Okta: You knew that the machine of one of your customer support members was compromised back in January. Why didn’t you investigate it? Having the capability to detect an attack is useless if you aren’t willing to respond.” And, Even when Okta received the Mandiant [security incident] report in March explicitly detailing the attack, they continued to ignore the obvious signs that their environment was breached until LAPSUS$ shined a spotlight on their inaction
He doesn’t let Sitel off either. “Why weren’t your customers immediately informed upon the first sign of compromise? Why did your customers have to wait two months to even hear that you were breached?”
All good questions and there are no good answers.
Script Kiddies?
As for LAPSUS$? United Kingdom police arrested a sixteen-year-old in Oxford and six other teenagers and young people for being behind the group. It seems they had used simple social engineering to break into companies that employed help desk personnel. They also, seriously, advertised for people willing to compromise their companies.
Once in, as Demirkapi pointed out, they “used off-the-shelf tooling from GitHub for the majority of their attacks.”
So, it appears this major cybercrime group is just one-step above script kiddies in their technical expertise.
Still, that puts them ahead of other groups. Clearly, a company such as Okta, and its partners, that work with such vital security matters as enterprise single-sign-on (SSO) must do a better job of stepping up their own security. A security chain is only as secure as its weakest link.
Okta and company must also do better at being transparent with their customers. When there’s even a chance that users’ login information is at risk, the customers must be kept in the loop. It’s that simple. No one likes to admit to security mistakes, but waiting until after there’s been an exploited vulnerability only makes you look even worse.
