Pierluigi Paganini
October 24, 2023
The password management and security application 1Password announced it had detected suspicious activity on its Okta instance on September 29, but excluded that user data was exposed.
The activity is linked to the recent attack on the Okta support case management system.
Okta this week said that threat actors broke into its support case management system and stole authentication data, including cookies and session tokens, that can be abused in future attacks to impersonate valid users. The company asks customers to upload an HTTP Archive (HAR) file in order to support them in solving their problems and replicating browser activity. HAR files can also contain sensitive data, including authentication information.
“Within the course of normal business, Okta support will ask customers to upload an HTTP Archive (HAR) file, which allows for troubleshooting of issues by replicating browser activity. HAR files can also contain sensitive data, including cookies and session tokens, that malicious actors can use to impersonate valid users.” reads data breach notification published by the company.
According to the advisory published by the company, Okta Security has identified adversarial activity abusing access to a stolen credential to gain access Okta’s support case management system.
The attackers gained access to files uploaded by certain Okta customers as part of some recent support cases.
The company pointed out that the breached system is separate from the production Okta service, which was not impacted. The company states that the Auth0/CIC case management system is not impacted and it has already notified all impacted customers.
One of the impacted customers is 1Password, which immediately launched an investigation into the incident and the potential impact on its activities.
“We detected suspicious activity on our Okta instance related to their Support System incident. After a thorough investigation, we concluded that no 1Password user data was accessed.
On September 29, we detected suspicious activity on our Okta instance that we use to manage our employee-facing apps. We immediately terminated the activity, investigated, and found no compromise of user data or other sensitive systems, either employee-facing or user-facing.” reads a notice published by 1Password.
“Since then, we’ve been working with Okta to determine the initial vector of compromise. As of late Friday, October 20, we’ve confirmed that this was a result of Okta’s Support System breach.”
1Password published technical details of the investigation in an internal Okta Incident Report.
Like other customers, a member of the IT team sent a HAR file to the Okta Support.
In the early morning of Friday, September 29, threat actors used the same Okta session that was used to create the HAR file to access the Okta administrative portal, and performed the following actions:
The alert was triggered after the IT team member received an email about the requested administrative user report.
“Based on the activity logs provided by Okta for their Support Portal, the HAR file had not been accessed by their support engineer until after the events of the incident. Security confirmed that the act of downloading the file would be captured in the activity logs by downloading the file from the support case. This eliminated the possibility that the Okta support engineer or administrative user had accessed the file before the incident to perform the events of the incident.” states the incident report. “There has been no indication of this actor accessing any other systems, based on the indicators available.”
1Password adopted necessary countermeasures in response to the incident, such as denying logins from non-Okta IDPs, reducing session times for administrative users, tighter rules on MFA for administrative users, and the number of super administrators was reduced. The company uploaded the datadog with additional alerts to reduce the time to detection for such events, as well as alerts related to specific actor indicators. The company also cleared sessions and credentials rotated for Okta administrative users.
“In the early morning hours of Monday, Oct. 2nd, the actor returned and attempted to use the Google IDP that they had enabled, though this failed as the IDP had been removed. In both cases, the actor accessed Okta via a server hosted by LeaseWeb in the US, and used a very similar and older version of Chrome (though different operating systems). It is unknown if the actor possesses valid Google account credentials that would have allowed them to complete a login via this IDP” concludes the report.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, 1Password)
