Security News Hackers Stole Access Tokens from Okta’s Support Unit

[upnorth]

Content source

https://krebsonsecurity.com/2023/10/hackers-stole-access-tokens-from-oktas-support-unit/

In an advisory sent to an undisclosed number of customers on Oct. 19, Okta said it “has identified adversarial activity that leveraged access to a stolen credential to access Okta’s support case management system. The threat actor was able to view files uploaded by certain Okta customers as part of recent support cases.”

Okta explained that when it is troubleshooting issues with customers it will often ask for a recording of a Web browser session (a.k.a. an HTTP Archive or HAR file). These are sensitive files because in this case they include the customer’s cookies and session tokens, which intruders can then use to impersonate valid users. “Okta has worked with impacted customers to investigate, and has taken measures to protect our customers, including the revocation of embedded session tokens,” their notice continued. “In general, Okta recommends sanitizing all credentials and cookies/session tokens within a HAR file before sharing it.”

The security firm BeyondTrust is among the Okta customers who received Thursday’s alert from Okta. BeyondTrust Chief Technology Officer Marc Maiffret said that alert came more than two weeks after his company alerted Okta to a potential problem.

The disclosure from Okta comes just weeks after casino giants Caesar’s Entertainment and MGM Resorts were hacked. In both cases, the attackers managed to social engineer employees into resetting the multi-factor login requirements for Okta administrator accounts.

Hackers Stole Access Tokens from Okta’s Support Unit – Krebs on Security

More on the same company:

Okta's source code stolen after GitHub repositories hacked

Okta, a leading provider of authentication services and Identity and Access Management (IAM) solutions, says that its private GitHub repositories were hacked this month. According to a 'confidential' email notification sent by Okta and seen by BleepingComputer, the security incident involves...

malwaretips.com

 

[Gandalf_The_Grey]

Okta breach: 134 customers exposed in October support system hack

Okta says attackers who breached its customer support system last month gained access to files belonging to 134 customers, five of them later being targeted in session hijacking attacks with the help of stolen session tokens.

"From September 28, 2023 to October 17, 2023, a threat actor gained unauthorized access to files inside Okta's customer support system associated with 134 Okta customers, or less than 1% of Okta customers," Okta revealed.

"Some of these files were HAR files that contained session tokens which could in turn be used for session hijacking attacks. The threat actor was able to use these session tokens to hijack the legitimate Okta sessions of 5 customers, 3 of whom have shared their own response to this event."

The three Okta customers that already disclosed they were targeted due to the company's October security breach are 1Password, BeyondTrust, and Cloudflare. They all notified Okta of suspicious activity after detecting unauthorized attempts to log into in-house Okta administrator accounts.

Despite being alerted about session hijacking attempts on September 29, Okta took over two weeks to officially confirm the breach in their support system after multiple meetings with the three affected customers.

To breach Okta's support system, the threat actors used credentials for a support service account stolen from an employee's personal Google account after they logged into their personal Google profile while using an Okta-managed laptop.

While Okta didn't share how the attackers stole the service account credentials, the company said that "the most likely avenue for exposure of this credential is the compromise of the employee's personal Google account or personal device."

In response to the breach, Okta took multiple measures to prevent similar incidents in the future, including disabling the compromised service account, blocking the use of personal Google profiles with Google Chrome on Okta-managed devices, deploying additional detection and monitoring rules for its customer support system, and binding Okta administrator session tokens based on network location.

"We have notified all customers of our findings and have completed remediations to protect all our customers. We apologize to all our customers that trust Okta as their identity provider," Okta told BleepingComputer after the article was published.

Okta breach: 134 customers exposed in October support system hack

Okta says attackers who breached its customer support system last month gained access to files belonging to 134 customers, five of them later being targeted in session hijacking attacks with the help of stolen session tokens.

www.bleepingcomputer.com

 

[upnorth]

“During our investigation into suspicious use of this account, Okta Security identified that an employee had signed-in to their personal Google profile on the Chrome browser of their Okta-managed laptop,” Bradbury wrote. “The username and password of the service account had been saved into the employee’s personal Google account. The most likely avenue for exposure of this credential is the compromise of the employee’s personal Google account or personal device.”

This means that when the employee logged into the account on Chrome while it was authenticated to the personal Google account, the credentials got saved to that account, most likely through Chrome’s built-in password manager. Then, after compromising the personal account or device, the threat actor obtained the credentials needed to access the Okta account. Accessing personal accounts at a company like Okta has long been known to be a huge no-no. And if that prohibition wasn’t clear to some before, it should be now. The employee almost surely violated company policy, and it wouldn’t be surprising if the offense led to the employee’s firing.

However, it would be wrong for anyone to conclude that employee misconduct was the cause of the breach. It wasn’t. The fault, instead, lies with the security people who designed the support system that was breached, specifically the way the breached service account was configured.

First, Okta should have put access controls in place besides a simple password to limit who or what could log into the service account. One way of doing this is to put limit or put conditions on the IP addresses that can connect. Another is to regularly rotate access tokens used to authenticate to service accounts. And, of course, it should have been impossible for employees to be logged in to personal accounts on a work machine. These and other precautions are the responsibility of senior people inside Okta.

People who want to delve further into various approaches for securing service accounts should read this thread on Mastodon. A fair number of the contributions come from security professionals with extensive experience working in sensitive cloud environments.

No, Okta, senior management, not an errant employee, caused you to get hacked

If a transgression by a single employee breaches your network, you're doing it wrong.

arstechnica.com

 

[Gandalf_The_Grey]

Okta: October Customer Support Security Incident - Update and Recommended Actions

In the wake of the security incident Okta disclosed in October 2023 affecting our customer support management system (also known as the Okta Help Center), Okta Security has continued to review our initial analysis shared on November 3, re-examining the actions that the threat actor performed. This included manually recreating reports the threat actor ran in the system and the files the threat actor downloaded.

Today we are sharing new information that potentially impacts the security of our customers.

We have determined that the threat actor ran and downloaded a report that contained the names and email addresses of all Okta customer support system users. All Okta Workforce Identity Cloud (WIC) and Customer Identity Solution (CIS) customers are impacted except customers in our FedRamp High and DoD IL4 environments (these environments use a separate support system NOT accessed by the threat actor). The Auth0/CIC support case management system was also not impacted by this incident.

The threat actor ran a report on September 28, 2023 at 15:06 UTC that contained the following fields for each user in Okta’s customer support system:

Created Date	Last Login	Full Name	Username	Email
Company Name	User Type	Address	[Date of] Last Password Change or Reset	Role: Name
Role: Description	Phone	Mobile	Time Zone	SAML Federation ID

The majority of the fields in the report are blank and the report does not include user credentials or sensitive personal data. For 99.6% of users in the report, the only contact information recorded is full name and email address.

October Customer Support Security Incident - Update and Recommended Actions

In the wake of the security incident Okta

sec.okta.com