1Password Latest Hit With Okta Related Intrusion

1Password is confirming it was attacked by cyber criminals after Okta was breached for the second time in as many years, but says customers’ login details are safe.

The outfit said the attack was initially detected on September 29 by a member of 1Password’s IT team after they received an email indicating that they had ordered a report including a list of all 1Password admins.

Knowing they didn’t order this report, the company’s incident response team was quickly engaged. They found a suspicious IP address and later realized the unknown attacker accessed the company’s Okta instance with admin privileges.

The investigation found no evidence of data exfiltration or access of any systems outside of Okta. Attackers were instead observed attempting to “lay low” and scout for intelligence that might later lead to a bigger, more sophisticated attack.

“We immediately terminated the activity, investigated, and found no compromise of user data or other sensitive systems, either employee-facing or user-facing,” said Pedro Canahuati, CTO at 1Password, in a blog post.

Before being removed from the network, the attacker performed actions including:

• Attempted access to the 1Password IT staffer’s user dashboard (Okta blocked this)
• Updated an existing identity provider (IDP) tied to 1Password’s Google production environment to impersonate the company’s users
• Activated that IDP
• Requested a report of all admin users

How the 1Password attack unfolded

The attack on 1Password began in the same way as others have in this new campaign, with the attacker accessing a HTTP Archive (HAR) file uploaded to Okta’s customer support portal.

Uploading HAR files to Okta’s customer support portal is common practice when Okta support is engaged with a customer. 

Inside this HAR file was information about the traffic to and from Okta’s servers from the IT team member’s browser, but also inside it is other data like the session cookie.

At some point after 1Password engaged Okta’s support and before the support agent interacted with the HAR file, an attacker was able to access it and use the session to access Okta’s admin portal, according to the incident response report.

“It is not known how the actor gained access to this session, though it has been confirmed that the generated HAR file contained the necessary information for an attacker to hijack the user’s session,” the report read.

“This was confirmed by IT creating a HAR file, and Security using Burp Suite to force the browser to use the session cookies captured in the HAR file to reproduce the events of the incident.”

Originally, there was some confusion over how this was carried out. Initial investigations focused on Okta’s side but logs revealed that the attackers’ actions all occurred before the Okta support agent accessed the HAR file, eliminating the possibility of there being a rogue support staffer.

Then attention turned to the 1Password IT worker who uploaded the HAR file over a public Wi-Fi network at a hotel, but this avenue also proved fruitless.

“Based on an analysis of how the file was created and uploaded, Okta’s use of TLS and HSTS, and the prior use of the same browser to access Okta, it is believed that there was no window in which this data could have been exposed to the Wi-Fi network, or otherwise subject to interception.”

Finally, the IT staffer’s macOS machine was scanned for malware but showed no sign of any nasty activity, neither on their machine nor on their user accounts. 

The main suspicion continued to be malware until last week when Okta publicized the issues it was facing with a number of its customers, including 1Password. The attacker was able to compromise Okta’s internal support systems, which is how they were able to access the 1Password IT team member’s HAR file after they sent it to Okta support.

After terminating the intrusion, the IT team member’s credentials were rotated and their Yubikey was the only way to complete MFA safeguards. 

A number of configuration changes were also made to the company’s Okta instance, including the tightening of MFA rules, reducing admin session times and the number of super admin accounts, and denying logins from non-Okta IDPs.

Another Okta nightmare

1Password joins BeyondTrust and Cloudflare in the list of high-profile customers to have mitigated attacks brought on by Okta’s issues.

Cloudflare was quick to highlight that it’s the second time security failings at Okta have led to attacks on the web performance and security company.

In March 2022 it was revealed that during a five-day window, a Lapsus$ attacker had remote access to an Okta support engineer’s computer but Cloudflare found no evidence of real compromise of its Okta tenant.

At the time, according to screenshots posted by the attackers, their level of access suggested they had the power to change customers’ user’s passwords, but it wouldn’t have impacted Cloudflare since it uses a combination of passwords and hardware keys for MFA.

Similar to the 1Password case, a Cloudflare session token was hijacked after it was created with Okta support. Cloudflare said it was able to detect and mitigate the intrusion of its Okta instance more than 24 hours before Okta notified it.

It was a similar story at BeyondTrust: Stolen session token, immediate detection and remediation, seemingly knew about it before Okta did.

“We raised our concerns of a breach to Okta on October 2nd,” BeyondTrust said in its disclosure. 

“Having received no acknowledgment from Okta of a possible breach, we persisted with escalations within Okta until October 19th when Okta security leadership notified us that they had indeed experienced a breach and we were one of their affected customers.

Okta confirmed in its October 20 disclosure that all customers that were impacted by the incident have been notified.

“Okta has worked with impacted customers to investigate, and has taken measures to protect our customers, including the revocation of embedded session tokens,” it said. 

“In general, Okta recommends sanitizing all credentials and cookies/session tokens within a HAR file before sharing it. 

“Attacks such as this highlight the importance of remaining vigilant and being on the lookout for suspicious activity.” ®

READ MORE HERE