OneLogin warns that attacker could be able to decrypt data

Single sign-on company OneLogin has finally offered more details about the data breach it suffered earlier in the week – and it’s not information customers will find reassuring.

On June 1, the company announced it had “detected unauthorized access to OneLogin data in our US data region,” which it said had been blocked.

Not good, but not a disaster necessarily. But on the same day it transpired that OneLogin had also emailed its customers to inform them:

All customers served by our US data center are affected. Customer data was compromised, including the ability to decrypt encrypted data.

The phrase “ability to decrypt data” immediately sounds more alarming.  A day on and OneLogin has now admitted it suffered a potentially serious breach of its systems and advised customers to perform a number of actions ASAP.

Before listing these, let’s summarise what happened because it raises flags.

It seems that for the seven hours between 2am and 9am PST on May 31 a cybercriminal got hold of the “AWS keys” giving them API access to the company’s cloud service.

This allowed them to create “reconnaissance” instances inside this infrastructure, from where the attacker was able to access databases containing details of users, apps and key types. Said OneLogin:

While we encrypt certain sensitive data at rest, at this time we cannot rule out the possibility that the threat actor also obtained the ability to decrypt data.

OneLogin decided to put out its warning, “erring on the side of caution”.

AWS, of course, is Amazon Web Services, while “keys” refers to the private 2048-bit SSH-2 RSA key PKI key bound to name within the service. The attacker got hold of this from “another, smaller service provider in the US”.

This is like a password/user name combination on steroids. Anyone gaining access to OneLogin’s infrastructure would have to have the unique name associated with the key but also specify the key separately. Normally, that would be held in a secure store the user would have to be authenticated to.

Getting hold of this would not be a matter of phishing someone and just entering a password. Layers of authentication should sit between a user and OneLogin’s cloud.  How this was bypassed deserves forensic investigation because it might hold lessons for other companies protecting similar services.

OneLogin’s emailed advice to customers runs as follows:

• If you replicate your directory password to provisioned applications, force a OneLogin directory password reset for your users.
• Generate new certificates for your apps that use SAML SSO.
• Generate new API credentials and OAuth tokens.
• Generate and apply new directory tokens for Active Directory Connectors and LDAP Directory Connectors.
• Update the API or OAuth credentials you use to authenticate to third-party directories like G Suite, Workday, Namely and UltiPro.
• Generate and apply new Desktop SSO tokens.
• Recycle any secrets stored in Secure Notes.
• Update the credentials you use to authenticate to third party apps for provisioning.
• Update the admin-configured login credentials for apps that use form-based authentication.
• Have your end users update their passwords for the form-based authentication apps that they can edit, including personal apps.
• Replace your RADIUS shared secrets.

In short, set the security up from scratch. Ticking off that list won’t make for a great few days at the office for the IT team.

What’s worse than a company you use suffering a data breach? Without doubt, a security company you use suffering a data breach.

We don’t yet know how much damage has really been done here, but with any company running single sign-on for large numbers of others ones, it’s an anxiety.

We await further details with interest.