Hacker News Reader

Comment by a-dub | Hacker News Reader

> And then go on to write paragraphs of detail and a timeline that explicitly shows for a five day period an unauthorized user had full super user access to the service.

it sounds like they built the support tool (with its unfortunate name) such that it places limited trust in support contractors and the information technology that supports them. because of this they're able to identify potentially affected customers and even audit all activities that have taken place. in other words, the system worked as designed.

this is very different (and orders of magnitude less severe) than an actual compromise of the production service itself.

View on HN

A person who should not have had access to the system gained near full admin access for five whole days. That is the textbook definition of a breach of security.

It doesn't matter if they did it by fooling or paying a low level CS rep to get access to their account vs. using their 'leet hacking skillz' to pwn the electronic defenses. A breach is a breach and the CSO of all people has to own up to that fact.

> A person who should not have had access to the system gained near full admin access for five whole days.

"This is an application built with least privilege in mind to ensure that support engineers are granted only the specific access they require to perform their roles. They are unable to create or delete users. They cannot download customer databases."

not being able to create or delete users seems a far cry from "near full admin access."

Why? We only know that they are not able to create new users.

But at least changing passwords of existing accounts seemed possible according to the screenshots, perhaps disabling 2FA as well.

As long as Okta does not provide a list of what the user was able to do, we don't know

At my own workplace (a SaaS service), we cannot change passwords, we can only send reset links (and the reset email goes to the end user).

I can't see any place in the screenshots where they are setting a user's password, only sending reset links (which would do nothing if the support user does not have access to system email or end users email).

Also at my workplace, 2FA is not enforced by an IdP (like Okta), but by our own application (and therefore could not be disabled at the IdP level).

How do you send a reset password email with a SSO platform that gates email?

If you have 2FA a OTP can be sent to a trusted device or app to allow a password reset without having access to email?

Is your workplace Okta? They built a custom internal tool. Until they enumerate exactly what the attacker had access to it’s hard to infer anything.

The article specifically addresses this, right? They log every interaction from support engineers and are going to report to the affected customers what actions were performed.

As others have mentioned, the slack access is potentially more concerning.

Based on the screenshots and Okta's description (which absolutely needs to be more clear), the attacker couldn't directly change passwords, they could only trigger password reset emails.

The linked article states that SuperUser is the name of their internal software. It's a confusing name, but at no point did the attacker have access to "near full admin access", based off the report.

The relevant question is "near-full admin access of a system that does what?"

If Okta has implemented a BeyondCorp model, the attackers had access with known limits. It doesn't matter how much access if the machine they've accessed is itself untrusted. That's the punchline of an episode of Star Trek: Lower Decks where they allowed an evil computer to take over the lighting systems on a starship; while they repaired the ship, all the computer could do was flick the lights on and off angrily.

On the topic of 'leet hacking skillz' I personally find it strange that so many Silicon Valley companies only care abut leetcode for the interview process.

You can be a security expert and no tech company will care unless you cram leetcode non-stop.

On the plus side the lack of security focus makes for a lot of opportunities for the stock market when betting against overvalued tech companies with this problem!

security design is pretty much the only thing that resembles real engineering in software. other than safety critical systems, it's pretty much the most common thing that can actually go wrong and harm people.

one day there will probably be professional engineering certifications for software engineers, and those certifications will largely center around building secure software and systems. (with maybe some focus on safety critical systems as well)

it's funny when you think about how young the field is.

The screenshots by the attacking group claimed to have access to thousands of slack channels, many of which they say included API keys. It's likely that some or many of those were to prod services.

This is the actual egregious thing in the breach. All of the support tool stuff seems like it was acting as designed and prevented the breach for sprawling.

The idea that at a security focused company they are passing around secrets via public slack channels is wild. That’s the thing they need to address.

Reply on news.ycombinator.com