FALLOUT — 1Password detects suspicious activity in its internal Okta account 1Password CTO says investigation found no compromise of user data or sensitive systems.
Dan Goodin – Oct 23, 2023 8:56 pm UTC Enlarge1Password reader comments 56 with
1Password, a password manager used by millions of people and more than 100,000 businesses, said it detected suspicious activity on a company account provided by Okta, the identity and authentication service that disclosed a breach on Friday.
On September 29, we detected suspicious activity on our Okta instance that we use to manage our employee-facing apps, 1Password CTO Pedro Canahuati wrote in an email. We immediately terminated the activity, investigated, and found no compromise of user data or other sensitive systems, either employee-facing or user-facing.
Since then, Canahuati said, his company had been working with Okta to determine the means that the unknown attacker used to access the account. On Friday, investigators confirmed it resulted from a breach Okta reported hitting its customer support management system.
Further ReadingOkta says hackers breached its support system and viewed customer filesOkta said then that a threat actor gained unauthorized access to its customer support case management system and, from there, viewed files uploaded by some Okta customers. The files the threat actor obtained in the Okta compromise comprised HTTP archive, or HAR, files, which Okta support personnel use to replicate customer browser activity during troubleshooting sessions. Among the sensitive information they store are authentication cookies and session tokens, which malicious actors can use to impersonate valid users.
Security firm BeyondTrust said it discovered the intrusion after an attacker used valid authentication cookies in an attempt to access its Okta account. The attacker could perform a few confined actions, but ultimately, BeyondTrust access policy controls stopped the activity and blocked all access to the account. 1Password now becomes the second known Okta customer to be targeted in a follow-on attack.
Mondays statement from 1Password provided no further details about the incident, and representatives didnt respond to questions. A report dated October 18 and shared on an internal 1Password Notion workspace said the threat actor obtained a HAR file a company IT employee had created when recently engaging with Okta support. The file contained a record of all traffic between the 1Password employees browser and Okta servers, including session cookies. Advertisement
1Password representatives didnt respond to a request to confirm the document’s authenticity, which was provided in both text and screenshots by an anonymous 1Password employee.
According to the report, the attacker also accessed 1Passwords Okta tenant. Okta customers use these tenants to manage the system access and system privileges assigned to various employees, partners, or customers. The threat actor also managed to view group assignments in 1Passwords Okta tenant and perform other actions, none of which resulted in entries in event logs. While logged in, the threat actor updated whats known as an IDP (identity provider), used to authenticate to a production environment provided by Google.
1Passwords IT team learned of the access on September 29 when team members received an unexpected email suggesting one of them had requested a list of 1Password users with admin rights to the Okta tenant. Team members recognized no authorized employee had made the request and alerted the companys security response team. Since the incident came to light, 1Password has also changed the configuration settings for its Okta tenant, including denying logins from non-Okta identity providers.
A summary of the actions the attacker took are: Attempted to access the IT employees Okta dashboard but was blocked Updated an existing IDP tied to 1Passwords production Google environment Activated the IDP Requested a report of administrative users
On October 2, three days following the event, the attackers logged back into 1Passwords Okta tenant and tried to use the Google IDP they had previously enabled. The actor was unsuccessful because the IDP had been removed. Both the earlier and subsequent accesses came from a server provided by cloud host LeaseWeb in the US and used a version of Chrome on a Windows machine.
The Okta breach is one of a series of attacks in recent years on large companies that provide software or services to large numbers of customers. After gaining entry to the provider, attackers use their position in follow-on attacks targeting the customers. It is likely that more Okta customers will be identified in the weeks to come. reader comments 56 with Dan Goodin Dan Goodin is Senior Security Editor at Ars Technica, where he oversees coverage of malware, computer espionage, botnets, hardware hacking, encryption, and passwords. In his spare time, he enjoys gardening, cooking, and following the independent music scene. Advertisement Channel Ars Technica ← Previous story Next story → Related Stories Today on Ars