OneLogin: Breach Exposed Ability to Decrypt Data(krebsonsecurity.com) |
OneLogin: Breach Exposed Ability to Decrypt Data(krebsonsecurity.com) |
“Our review has shown that a threat actor obtained access to a set of AWS keys and used them to access the AWS API from an intermediate host with another, smaller service provider in the US. Evidence shows the attack started on May 31, 2017 around 2 am PST. Through the AWS API, the actor created several instances in our infrastructure to do reconnaissance. OneLogin staff was alerted of unusual database activity around 9 am PST and within minutes shut down the affected instance as well as the AWS keys that were used to create it.”
Credit where credit is due, that's a pretty quick response time for data breaches, which are normally quoted as being discovered in an average of 30 or so days.
However the fact people's information can be decrypted from this breach is awful. Sounds a lot like the private key to decrypt this information was stored alongside the data in the database... whoops! That's like storing the clear text password. Let's hope the decrypted information contains strongly hashed passwords, but I'm not holding my breath.
Not necessarily, even if this was done "properly" there is no guarantee that from the internal network there wasnt a separate exploit that the attacker could use to gain access to a different node which had the key in memory. With breakages like these you generally have to assume that anything that is theoretically possible has happened.
Post: http://www.exfiltrated.com/research-Instagram-RCE.php
Discussion: https://news.ycombinator.com/item?id=10754194
Leak your cloud provider keys, leak everything. These should be kept under close scrutiny and locked down as much as possible.
Companies use OneLogin so employees have 1 service to enter their credentials and can then use federated access to apps like Google, Office 365, Salesforce, etc without signing in again, most often connected via SAML which uses public/private keys. The identity provider can also be external, so for example users can sign-in via the OneLogin UI but the username/password are actually authenticated against Office 365 Active Directory instead.
In addition, customers are unable to do any forensic analysis to determine how their data was affected.
> OneLogin’s blog post includes no other details, aside from a reference to the company’s compliance page.
The only option is to hope they provide customers with relevant information in a "timely manner", but that could be months for an organization with thousands of customers.
So it's better if that single point of failure the company puts all its eggs into is a hacked piece of shit by an engineer who couldn't build a secure login system if his life depended on it? This is a serious question and one that I've been struggling with at my current work and at every other job I've had in this industry without exaggeration. Plaintext passwords, passwords encrypted with an easily obtainable key, insecure hashes, no salts, etc. These things are the norm in DIY login schemes. This is what the quoted financial fraud analyst thinks is better and Krebs thinks is worth repeating? This should be the main point of discussion here, yet it's brushed off by the advice of a financial fraud analyst? Oh, our industry is fucked and I just lost a ton of respect for Krebs' reporting.
Isn't that at least somewhat analogous to using the same username and password on every site?
In reality OneLogin is typically using a federated login protocol like SAML or OIDC to grant access to third-party services. This means it can also be used to immediately revoke access, without having to reach out to and reconfigure various services.
If your OneLogin password was "pass123", so was the password for your OneLogin-managed accounts at Google, Salesforce, and so on. I believe but am not certain that this was even the case for some sites that used SAML but required passwords for non-HTTP access. Mail clients accessing Gmail is an example.
I do not know if this is still the case. I suspect it would not be difficult to check.
The sheer number of databases that have and can lose your password is most of the risk with password reuse.
Companies aren't going to maintain separate user tables for every authenticated service that employees use. The alternative is to have each service handle passwords directly and pass them through to an LDAP server, or run their own SAML IdP with considerable difficulty.
At least an individual company's IdP doesn't have the "hack many companies at once" target on its back.
Better services (1password for example) are specifically designed to never know your master password/key to avoid this very situation.
I wonder if in this case OneLogin was the victim of a MITM attach while the attacker had access to their infrastructure?
So they didn't decrypt data at rest that they obtained but rather they captured activity in transit?
Either way it sounds like OneLogin had some implementation issues.
As a result of trying to be more secure a big enterprise has gone from maybe a couple single points of compromise to several. It's not as easy to do script kiddie-level attacks but the tradeoff is that a very smart and/or well funded attacker now has some very, very powerful targets.
Runs securely cross-platform, including tablets & smartphones
Can present a great looking UI across all platforms
Has no licensing issues in proprietary walled gardens
Can securely support plugins to integrate with webapps
It's easy for a Gartner analyst to sit behind a desk and pontificate about the ultimate-most-secure single-sign-on, but resource constraints are a thing. SaaS SSO is a very reasonable compromise for those who don't have the time, money, or talent to invest in on-premise infrastructure.
The worse alternatives is where the "top passwords" lists come from... those lists are from people that are not using any password store:
https://www.google.com/search?q=top+passwords+2017&ie=utf-8&...
The most horrible alternative I've seen: I once worked with a person who used his Outlook "contacts" as his "password manager." I discovered that after he quit and I was deactivating his accounts. Not only did he use Outlook "contacts" as his "password manager", but his passwords were discoverable (based on readily available personal information), guessable (e.g. pa$$word), and heavily reused either directly or as minor variations.
In a perfect world, that is, if no service stored passwords with risible security, just remembering 2 or 3 strong passwords would be workable
Instead, since we live in a word where several system developers are inexperienced or just plain idiots, there is a need for passwords to be disposable
Password manager are worthy because they allow you to keep several different passwords and the strong password they require hopefully is not stored as MD5 anywhere.
See here: https://support.onelogin.com/hc/en-us/articles/201175264-Pas...
If they are storing the password and pushing it to the connected service on the user's behalf, then they have to be able to decrypt it somehow, and if the bad actor was able to intercept and decrypt data within the platform, then that may have included passwords stored using this mechanism perhaps
By storing so many passwords in one system, they made that system a high value target, all while not having the security chops they thought they had.
Password vaults should be distributed. This prevents the conglomeration of password secrets that creates a high value target. They would've been wise to have a series of password vault apps that are integrated with their system. They could have done this by leveraging Password Safe.
But not necessarily all of them all the time. The decryption key could be derived from the master password of each user and only kept around while the user is logged in.
I've used these, but refused to put more important things like aws in there.
I think we agree on all the major points here, but I would not diminish the significance based on the fact that OneLogin is not a password vault.
Any identity related service, especially one that also includes password manager and desktop login functionality along with secure notes, etc. being involved in something like this is a major issue. We were looking at using them but have decided to stick with Google instead.
Also don't forget having to audit each service's API keys/tokens/local users etc to make sure someone hasn't gotten access via a compromised certificate and then created a sneaky API key for them to use in the future.
Basically we had to assume every app had been compromised and rotate every internal key/certificate the was in each one, as well as reconfigure them with a new SAML certificate.
Many providers do have an agent that runs on the AD servers that MitM captures the passwords when the user rotates them but that's a lot more involved to get setup. They could either force use of that AD agent or remove the functionality entirely and force users to manage a password with the service but it would either make on-boarding slow/impossible or really reduce the convenience factor for users. It's something every identity provider would need to do (or be forced to do) because the ones that didn't would steal away all of their customers.
If the latter, then OneLogin has to possess the ability to decrypt the passwords without user input (edit: although I suppose the SSO token coming from the client could be the key? I don't know if that's possible or how that would work - the key would still need to be cached for some period of time post-auth either way I would think)..