13 ms·

Updated Okta Statement on Lapsus$

341 points by rcoppolo 5y ago

adam0c 5y ago
Copy / Paste from Lapsuss telegram ;) https://www.okta.com/blog/2022/03/updated-okta-statement-on-lapsus/ https://www.okta.com/blog/2022/03/updated-okta-statement-on-... I do enjoy the lies given by Okta. 1. We didn't compromise any laptop? It was a thin client. 2. "Okta detected an unsuccessful attempt to compromise the account of a customer support engineer working for a third-party provider." - I'm STILL unsure how its a unsuccessful attempt? Logged in to superuser portal with the ability to reset the Password and MFA of ~95% of clients isn't successful? 4. For a company that supports Zero-Trust. Support Engineers seem to have excessive access to Slack? 8.6k channels? (You may want to search AKIA* on your Slack, rather a bad security practice to store AWS keys in Slack channels ) 5. Support engineers are also able to facilitate the resetting of passwords and MFA factors for users, but are unable to obtain those passwords. - Uhm? I hope no-one can read passwords? not just support engineers, LOL. - are you implying passwords are stored in plaintext? 6. You claim a laptop was compromised? In that case what suspicious IP addresses do you have available to report? 7. The potential impact to Okta customers is NOT limited, I'm pretty certain resetting passwords and MFA would result in complete compromise of many clients systems. 8. If you are committed to transparency how about you hire a firm such as Mandiant and PUBLISH their report? I'm sure it would be very different to your report :) _________________________________________________________________________________________________________________________________________________________________________________________________________ https://www.okta.com/sites/default/files/2021-12/okta-security-privacy-documentation.pdf https://www.okta.com/sites/default/files/2021-12/okta-securi... 21. Security Breach Management. a) Notification: In the event of a Security Breach, Okta notifies impacted customers of such Security Breach. Okta cooperates with an impacted customer’s reasonable request for information regarding such Security Breach, and Okta provides regular updates on any such Security Breach and the investigative action and corrective action(s) taken. - But customers only found out today? Why wait this long? 9. Access Controls. Okta has in place policies, procedures, and logical controls that are designed: b. Controls to ensure that all Okta personnel who are granted access to any Customer Data are based on leastprivilege principles; kkkkkkkkkkkkkkk 1. Security Standards. Okta’s ISMP includes adherence to and regular testing of the key controls, systems and procedures of its ISMP to validate that they are properly implemented and effective in addressing the threats and risks identified. Such testing includes: a) Internal risk assessments; b) ISO 27001, 27002, 27017 and 27018 certifications; c) NIST guidance; and d) SOC2 Type II (or successor standard) audits annually performed by accredited third-party auditors (“Audit Report”). I don't think storing AWS keys within Slack would comply to any of these standards?
- ttt2022 5y ago
  > kkkkkkkkkkkkkkk "kkkkkkk" is the Brazilian way of typing "hahaha". Is Lapsus from South America?
  - hudsonjr 5y ago
    I believe they are Brazil. Also a month or two back there were claims that a member accidentally doxxed themselves a couple times, and they were in Spain.
jgrahamc 5y ago
Lots more detail: https://blog.cloudflare.com/cloudflare-investigation-of-the-january-2022-okta-compromise/ https://blog.cloudflare.com/cloudflare-investigation-of-the-...
- ktsayed 5y ago
  the difference in level of detail and amount of information provided has been out of this world. Thank you!
  - chockchocschoir 5y ago
    Also a fun exercise in "Show don't tell" when it comes to transparency. Okta writes "We are deeply committed to transparency" but shows none in their blogpost in contrast to CloudFlare, that doesn't write anything about transparency but displays a lot of it. A bit like queuing for your internet providers customer support for 3 hour and hearing "We care about customer satisfaction" every five minutes.
- indigodaddy 5y ago
  I thought that a CF person (can’t remember if it was Prince or not) said in the main HN thread yesterday, that CF uses their own homegrown SSO internally, and Okta externally, but this blog article seems to infer the opposite… Anyway, I likely misinterpreted yesterday’s comment..
  - deleted 5y ago
    [deleted]
  - 0x0000000 5y ago
    I think you're referring to this tweet: https://twitter.com/eastdakota/status/1506148082194386949 https://twitter.com/eastdakota/status/1506148082194386949 I believe @eastdakota is saying that Cloudflare has their own homegrown SSO internally, but they do not make that available externally to their customers (it's not a public product that one can buy). I don't think that the tweet was saying that they use Okta externally.
eyeareque 5y ago
It feels like a lawyer heavily tweaked this to sound better than it really is.
- swiftcoder 5y ago
  That's just a reality of corporate disclosures, I'm afraid. No one is going to let something like this go to press without a full round of legal and PR editing.
  - chippiewill 5y ago
    I think there's two ways about it though. Most "good" companies (e.g. Cloudflare) will try to be transparent and proactive without taking on liability. In this case it reads as though Okta are obfuscating the truth, and that's not good.
- WrtCdEvrydy 5y ago
  Source: https://www.google.com/search?q=okta+stock https://www.google.com/search?q=okta+stock
  - etcet 5y ago
    Besides the opening it doesn't appear to have moved very much. I wonder if LAPSUS$ have short positions open and are frustrated it's not moving which is why they're posting responses to Okta and then updated their response with more information (as linked above).
koolba 5y ago
> Support engineers do have access to limited data - for example, Jira tickets and lists of users - that were seen in the screenshots. Support engineers are also able to facilitate the resetting of passwords and MFA factors for users, but are unable to obtain those passwords. This means they could have reset anybody’s credentials and logged in. There would a record of it if the audit logs are valid, but saying no action is needed may be a stretch.
- giaour 5y ago
  It's been a minute since I was an admin in an Okta directory, but don't all resets use a self-service flow? In order to log in to someone's account, I think you need to compromise their email, too.
  - dhagz 5y ago
    They do indeed use a self-service flow.
  - codebje 5y ago
    Super admins can set a temporary password. But they can also change a user's email address, disable password and email change notifications, lock out all other admins... They have complete control of the org. It's pretty clear there is no super admin breach here. None of the screenshots show an admin interface - the app portal shot clearly shows a distinct lack of the "Admin" button. No user directory shots. There is a single image of a password reset confirmation, but those are also in documentation so it's hardly a smoking gun. It seems far more likely that a support engineer had their laptop compromised and their limited access was used to try and make a mountain out of a molehill. Not like a ransomware group would have reason to over-exaggerate their access and ability, right?
- bhaney 5y ago
  > This means they could have reset anybody’s credentials and logged in Does it? It specifically says "but are unable to obtain those passwords," which reads to me like they are able to trigger a password reset email to the user, but are not actually able to set the password themselves.
dogecoinbase 5y ago
More than a little concerning that they apparently investigated this in January, and while there's a lot of talk about what could or could not have happened, they don't seem to know what actually happened, and no customers were notified (but now: "[we are] identifying and contacting those customers that may have been impacted).
- Melatonic 5y ago
  I believe that is because they are now hitting the legal limit of when they are required by law to notify people.
chockchocschoir 5y ago
> Support engineers are also able to facilitate the resetting of passwords and MFA factors for users, but are unable to obtain those passwords. Very ambiguous statement, not really fitting in with the whole "deeply committed to transparency" image they are trying to emit. What does "facilitate" really refer to here? If it was just triggering it, they would have said so, presumably. And why is only passwords mentioned as what couldn't be obtained and not the tokens from MFA as well, does that mean they could obtain those tokens? I wonder how it fits in with the groups own statements that they still have active access. Gonna be interesting to see what Lapsus$ replies to this statement.
- phphphphp 5y ago
  what I don’t get is, if support can’t do anything but “reset” which doesn’t expose the ability to gain access… how is support helping users? If a user can access their email, then they can reset themselves — surely? The idea that support can just trigger a reset email makes little sense. Perhaps Okta has some complex mechanisms that I am not aware of, but if this was any system I’ve ever worked on, an employee could take over an account if they so desired.
  - deleted 5y ago
    [deleted]
  - mdoms 5y ago
    You should do a stint in support. You'd be amazed how many people would rather interact with support than click the Forgot Password link.
    - phphphphp 5y ago
      As much as I’d like to forget, I’ve done a lot of support and much of that was authentication issues. I can certainly imagine in a corporate environment that some contingent of users would prefer to be hand-held through the reset request process, but all of them? My expectation (and experience of other similar systems) was that Okta would not allow password resets by anyone but the organization administrators. However, that doesn’t appear to match up with what has been disclosed here.
smcl 5y ago
> In January 2022, Okta detected an unsuccessful attempt to compromise the account of a customer support engineer working for a third-party provider It looked kinda successful though...
- Helloyello 5y ago
- duncan-donuts 5y ago
  > The report highlighted that there was a five-day window of time between January 16-21, 2022, where an attacker had access to a support engineer’s laptop. This is consistent with the screenshots that we became aware of yesterday. Yeah, it was.
  - djrogers 5y ago
    You can take my laptop from me and have access to it without having compromised my Okta account. In that scenario you wouldn't have my okra password or my MFA - what you would have is transient access to everything I'd already auth'd to until it times out and requests that you auth again.
    - lIIIllllIIII 5y ago
      At which point your browser probably auto-fills the credentials again :-)
      - d3nj4l 5y ago
        But ideally you would have MFA on a second device, so just the credentials aren't enough.
- benatkin 5y ago
  I think they're meaning it like a login attempt here. If you submit a login form 5 times, that's 5 login attempts. Another similar example is free throw attempts. https://www.statmuse.com/nba/ask/most-free-throw-attempts-per-game-2021 https://www.statmuse.com/nba/ask/most-free-throw-attempts-pe... I wouldn't have realized that unless I'd read far enough to see that Entity A did compromise Account B. Since the author didn't define what an attempt in this context means, I think it would be proper to assume that attempt meant the overall effort to compromise the account.
mimikatz 5y ago
I don't understand how they can say "unsuccessful attempt to compromise the account of a customer support engineer" . then can say "Following the completion of the service provider’s investigation, we received a report from the forensics firm this week. The report highlighted that there was a five-day window of time between January 16-21, 2022, where an attacker had access to a support engineer’s laptop. This is consistent with the screenshots that we became aware of yesterday." and the screenshots of the attackers looking at Okta's support portal.
- vault 5y ago
  If somebody uses my laptop, my Gmail account is not compromised; I'm being dolphined. Of course 5 days is quite a long time, but this is just to clarify what you didn't understand.
  - mimikatz 5y ago
    If I use your laptop to get access to your Gmail isn't your Gmail account compromised? I might not have access to your Gmail username and passwords (and MFA), but I can read your email, I can send email as you, etc etc. I feel like I have compromised your gmail account. If I steal your secure token and log into you through a cloned browser session and access your gmail have I compromised your gmail? It feels like it. Maybe it is just a distinction without a difference.
    - tomnipotent 5y ago
      > your Gmail account compromised The access is transient and you remain in ownership over the credentials and account, because the credentials were not compromised (just the programs/browsers with pre-existing auth). Though with physical access it's probably only a mater of time before local admin passwords are brute forced and access to keychain/browser saved logins is inevitable? > If I steal your secure token It's more like you just logged in using your secure token then someone stole the device and took advantage of that. I think we can all agree there's a difference between having access to the laptop and access to the account without the laptop.
skilled 5y ago
I mean, ultimately, it is now up to Lapsus$ to confirm this. If everything they say (and the Cloudflare post, also) is true then I don't think anyone should be worried.
- Johnny555 5y ago
  It's an interesting world we live in if the word of an organization that earns a living by stealing data and extorting companies is trusted more than the word of a public company.
  - MrStonedOne 5y ago
  - lnxg33k1 5y ago
    I would say it's more about what each entity has at stake, the public company could be read as "An entity which sold something that didn't have the capability to offer and has a lot to lose if the issues are uncovered" Against "Someone that what has to lose at this point?"
    - Johnny555 5y ago
      "Someone that what has to lose at this point?" What to lose? Their reputation? Both sides have incentive to stretch the facts. But Okta has more accountability since if an Okta customer comes forward and says "We had credentials of several of our users maliciously reset during that time period and have the logs to prove it", then Okta is going to have a hard time of it. If Okta comes up with proof that Lapsus didn't have the access they said they did, Lapsus is not going to have many "customers" complaining "you didn't crime that other company as much as you said you did"
tofuahdude 5y ago
> Okta service has not been breached and remains fully operational > highlighted that there was a five-day window of time between January 16-21, 2022, where an attacker had access to a support engineer’s laptop These are some impressive mental gymnastics!
- RL_Quine 5y ago
  Yeah, this blog post is shoveling it. They were popped, they aren't internally consistent in their dismissal of it.
- benatkin 5y ago
  What got me was this: > Okta detected an unsuccessful attempt to compromise the account of a customer support engineer working for a third-party provider > highlighted that there was a five-day window of time between January 16-21, 2022, where an attacker had access to a support engineer’s laptop
- c7DJTLrn 5y ago
  You didn't see graphite. Identity providers cannot be compromised!
  - chippiewill 5y ago
    Only a support engineer was compromised. Not great, not terrible.
- Ozzie_osman 5y ago
  Not saying this is what happened or defending Okta, but these two statements could be true. Assuming the support engineer had ACCESS to allow him to do some bad stuff, but they have audit logs to prove his account didn't use that access (except to take screenshot), both statements could be true. It's unlikely but possible.
- deleted 5y ago
  [deleted]
paxys 5y ago
There were a lot of doomsday predictions in yesterday's thread before any real info had been shared, but it was always the more likely scenario that a support agent contracted through a vendor would have limited read access to their internal systems and wouldn't be able to cause any real damage.
- evan_ 5y ago
  you can do a lot of damage with read access depending on what you're able to read
  - chippiewill 5y ago
    Especially with how much access they had on the company Slack org. Everyone's terrible with secops, but Okta employees were apparently dumping AWS keys into public channels.
  - j4yav 5y ago
    They are at least saying that Okta engineers were posting AWS keys in Slack, which they had full access to and found by searching for AKIA.
hericium 5y ago
> limited data - for example, Jira tickets I wonder how many passwords and other creds were harvested from tickets alone. Lapsus$ went after Okta's customers and in some cases successfully, it appears.
- tuwtuwtuwtuw 5y ago
  > it appears. Where does it appear like that? I have tried to follow this but the only thing I have seen shares is info from within Okta. I have seen email addresses of CloudFlare employee in screenshot of Okta, is that what you are referring to?
  - flutas 5y ago
    Lapsus$ has released data from Microsoft, Nvidia, Ubisoft and Samsung over the past few months. https://www.vice.com/en/article/y3vk9x/microsoft-hacked-lapsus-extortion-investigating https://www.vice.com/en/article/y3vk9x/microsoft-hacked-laps...
templapsusread 5y ago
Lapsus has responded https://img.guildedcdn.com/ContentMedia/e4149dc99f447074cb2c385f1929d262-Full.webp?w=513&h=1033 https://img.guildedcdn.com/ContentMedia/e4149dc99f447074cb2c...
- templapsusread 5y ago
  they edited and added more content https://img.guildedcdn.com/ContentMedia/372280f522049aa0b0eb1f5255d1b921-Full.webp?w=483&h=1700 https://img.guildedcdn.com/ContentMedia/372280f522049aa0b0eb...
  - intunderflow 5y ago
    To note in some of the earlier screenshots you can see they have the EC2 Instances menu open in their tabs - that's a bit concerning, why does a support engineer need AWS EC2 access?
    - Consultant32452 5y ago
      The LAPSUS$ post suggests that they queried the AWS keys out of Slack. So the support engineers just have access to Slack, and Okta engineers were dumb enough to put those keys in Slack.
      - gedy 5y ago
        I'm incredulous an auth focused company would do this without someone freaking out? Even my much smaller SaaS companies would react quickly to stop and rotate these if this happened.
        zmmmmm 5y ago
        looking closely at that I'm suspicious that lapsus$ is playing up what were perhaps trivial or ephemeral keys that were non-sensitive ... eg: test / dev / debug instances etc. The reason I think that is because if they really had keys for production machines it seems very unlikely they wouldn't have used them to produce some more damaging collateral than they've presented.
mdoms 5y ago
Ctrl+F 'very seriously' There it is.
HL33tibCe7 5y ago
> The Okta service has not been breached and remains fully operational Oh okay then, pack up guys, everything’s fine I really hate this kind of corporate bullshit > There are no corrective actions that need to be taken by our customers. Isn’t this an objectively false statement?
- CoastalCoder 5y ago
  > Isn’t this an objectively false statement? IMHO it's more of an empty statement. They never pin down what end-state is being discussed. So we can't evaluate if "additional steps are needed" to achieve that (unspecified) state. It could be that the speaker is intentionally equivocating. I.e., knowing that the audience will assume some particular end-state. But if cornered, the speaker can claim (lie) that he implicitly meant a different end state.
nimbius 5y ago
>The Okta service has not been breached and remains fully operational. There are no corrective actions that need to be taken by our customers. despite an overwhelming preponderance of damning evidence from twitter (as well as the hacker themselves) you've somehow managed to find yourselves secure instead? Christs whiskers thats some impressive doublethink. Its also an excellent opportunity to fall on a sword that gives future attackers --hat colour dismissed-- an immediate incentive to simply publish regardless as you dont appear to be acting with very much good faith. if this sort of an attack is a carrot, you've clearly shown a predilection for the stick.
- gurjeet 5y ago
- Melatonic 5y ago
  This is going to get interesting in the days ahead
- Bombthecat 5y ago
  According to gdpr, this post could be illegal (because.. Lie)
  - jbrownbridge 5y ago
    IANAL but this definitely seems like a breach of Art 33 of GDPR as it meets the criteria of involving personal data (list of users was exposed) and the 72 hour window has passed.
- hughrr 5y ago
  This is prime bad PR. This is going to be an absolute shit show.
- GordonS 5y ago
  If there is one thing you want from a 3rd party auth provider, it's trust - this is not the time to play word games. I'd have far more faith in them if they were transparent about what had happened, what they're doing about it, and how they will make sure it can't happen again. Instead, they are being weasels - I for one, will not be using their services again, and this behaviour is the reason why. Here's another example from a couple of years back where they used some really weasely language to claim they weren't vulnerable to a CVE (spoiler: they were): https://twitter.com/jonoberheide/status/1506280347306188805?t=zcmm1nU3E5_zlcvFwIDt8w&s=03 https://twitter.com/jonoberheide/status/1506280347306188805?...
sergiotapia 5y ago
>The Okta service has not been breached and remains fully operational. There are no corrective actions that need to be taken by our customers. The rest of the note literally show they have been breached. What?
deleted 5y ago
[deleted]
thorin1 5y ago
> there was a five-day window of time between January 16-21, 2022, where an attacker had access to a support engineer’s laptop. > Support engineers are also able to facilitate the resetting of passwords and multi-factor authentication factors for users No breach at all here.
datavirtue 5y ago
Felt like a bluff to me. The claims were outlandish.
deleted 5y ago
[deleted]
trhway 5y ago
Looks like Lapsus didn't do any damage and thus Okta dismisses the breach as not a breach - just like a proof-of-breach starting notepad.exe on compromised machine was at one of my old jobs dismissed because notepad doesn't do any damage. The security professionals today are the second sellers of snake oil after MBAs. Cue SolarWind with their it is ok for binaries' signatures to differ as they get deformed while being forced through the internet pipes :) Lapsus not being a "state level actor" denied that easy get-out-of-jail-free card to Okta.
- hcazz 5y ago
  >The security professionals today are the second sellers of snake oil If someone breaks into your house, and stays there for a week, would you say they didn't really break in because they didn't murder you? >proof-of-breach Maybe you're referring to a "proof of concept"? A "proof of breach" in the security industry is an incident to be investigated, and if necessary, involve law enforcement. It isn't meddling kids that didn't cause any harm. As a side note, I've never heard anyone use the term "proof of breach" in that context in the industry. The fact that Okta didn't detect this earlier is concerning in its own right, let's not downplay the fact that the level of access that third party providers have is not a solved issue in the industry. The RCA/post mortem/follow up actions from Okta's side should not be "they got access but didn't do anything with it, we don't need to change anything".
t0bia_s 5y ago
Reply from Lapsus$ on Telegram: I do enjoy the lies given by Okta. 1. We didn't compromise any laptop? It was a thin client. 2. "Okta detected an unsuccessful attempt to compromise the account of a customer support engineer working for a third-party provider." - I'm STILL unsure how its a unsuccessful attempt? Logged in to superuser portal with the ability to reset the Password and MFA of ~95% of clients isn't successful? 4. For a company that supports Zero-Trust. Support Engineers seem to have excessive access to Slack? 8.6k channels? (You may want to search AKIA* on your Slack, rather a bad security practice to store AWS keys in Slack channels ) 5. Support engineers are also able to facilitate the resetting of passwords and MFA factors for users, but are unable to obtain those passwords. - Uhm? I hope no-one can read passwords? not just support engineers, LOL. - are you implying passwords are stored in plaintext? 6. You claim a laptop was compromised? In that case what suspicious IP addresses do you have available to report? 7. The potential impact to Okta customers is NOT limited, I'm pretty certain resetting passwords and MFA would result in complete compromise of many clients systems. 8. If you are committed to transparency how about you hire a firm such as Mandiant and PUBLISH their report? I'm sure it would be very different to your report :) _________________________________________________________________________________________________________________________________________________________________________________________________________ https://www.okta.com/sites/default/files/2021-12/okta-security-privacy-documentation.pdf https://www.okta.com/sites/default/files/2021-12/okta-securi... 21. Security Breach Management. a) Notification: In the event of a Security Breach, Okta notifies impacted customers of such Security Breach. Okta cooperates with an impacted customer’s reasonable request for information regarding such Security Breach, and Okta provides regular updates on any such Security Breach and the investigative action and corrective action(s) taken. - But customers only found out today? Why wait this long? 9. Access Controls. Okta has in place policies, procedures, and logical controls that are designed: b. Controls to ensure that all Okta personnel who are granted access to any Customer Data are based on leastprivilege principles; kkkkkkkkkkkkkkk 1. Security Standards. Okta’s ISMP includes adherence to and regular testing of the key controls, systems and procedures of its ISMP to validate that they are properly implemented and effective in addressing the threats and risks identified. Such testing includes: a) Internal risk assessments; b) ISO 27001, 27002, 27017 and 27018 certifications; c) NIST guidance; and d) SOC2 Type II (or successor standard) audits annually performed by accredited third-party auditors (“Audit Report”). I don't think storing AWS keys within Slack would comply to any of these standards?
ppvfy 5y ago
> The Okta service has not been breached and remains fully operational. There are no corrective actions that need to be taken by our customers. > Support engineers are also able to facilitate the resetting of passwords and multi-factor authentication factors for users, but are unable to obtain those passwords. Those two things are at odds with each other, no?
dboreham 5y ago
The post could use some review/edit. This: "a customer support engineer working for a third-party provider" actually means "one of our customer support engineers, who happens to be an employee of another company, working for us under contract".
- hackmiester 5y ago
  Don't believe for a moment that this misdirection is unintentional. It's one big reason you might have contract workers instead of employees in this role, actually.
  - nopcode 5y ago
    In EU, the GDPR closes this loophole: > Where that other processor fails to fulfil its data protection obligations, the initial processor shall remain fully liable to the controller for the performance of that other processor’s obligations. GDPR Art 28(4): https://gdpr-info.eu/art-28-gdpr/ https://gdpr-info.eu/art-28-gdpr/
siskiyou 5y ago
I've never worked at Okta, but I've worked with several production ticketing systems at big and small companies, and all of them contained critical information about customers and operations. Including credentials.
- dboreham 5y ago
  Not putting secrets and sensitive data in bug reports / tickets has been a thing for at least 20 years, so you worked at some crappy run places.
  - wepple 5y ago
    Ah, I see you’ve never worked at a large company with lots of humans
daenz 5y ago
Given the nature of what Okta does, is this going to kill them? It's like the business version of a headshot.
- gtsteve 5y ago
  Probably not. It's really inconvenient for a large organisation to drop them given how embedded identity gets into everything. It's reputational damage but something worse [0] happened to OneLogin a few years back and they're still around. [0] https://www.csoonline.com/article/3389138/how-onelogin-responded-to-its-breach-and-regained-customer-trust.html https://www.csoonline.com/article/3389138/how-onelogin-respo... (unsurprisingly the canonical article from their weblog is missing now)
  - password4321 5y ago
    https://news.ycombinator.com/item?id=14458105 https://news.ycombinator.com/item?id=14458105 | https://web.archive.org/web/20170621202358/https://www.onelogin.com/blog/may-31-2017-security-incident https://web.archive.org/web/20170621202358/https://www.onelo...
lambda_dn 5y ago
My booking.com account was hacked and someone from China booked a hotel using my account (Im in UK). Managed to cancel it for free, changed password, logged out of all sessions, turned on 2FA and removed all cards. Wondering if this is related.
- 0xbadcafebee 5y ago
  My booking.com account also notified me someone booked a hotel in Brazil, and I went in and cancelled it and reported it. Extra weird because the notification came in through an old email address. That was on Saturday, Mar 19, 10:43 PM EDT. But it could have just been a large attack on Booking.com, unknown if it's Okta-related (and not necessarily a compromise, if I accidentally reused a password)
wellthisisgreat 5y ago
Was there any development to the Nvidia hack? Didn't they demand open-sourcing all the drivers or something like that? Or was that all bluff and lapsus didn't have anything
londons_explore 5y ago
Anyone any idea how it appears this breach could have caused far more mayhem, yet the attackers didn't? Is it common for attackers to just get bored and leave taking just a few screenshots?
physicsguy 5y ago
“Nobody ever got fired by choosing Microsoft”
megatron4537 5y ago
Did anyone get an impromptu password reset recently?
uean 5y ago
I saw the tweet a few mins after it was posted (thanks to the original article here on HN). We are a small startup and made the call to treat this like an exercise in failover process and ripped Okta out from our systems in around an hour. It was satisfying to see the process work. Original emails to staff were to wait for Okta to weigh in with their response before moving back to SSO but… not sure how that’s looking now given how they’re handling things so far.
darepublic 5y ago
They look bad from this but really if nothing else comes out seems like they weathered this OK
jzer0cool 5y ago
I see the benefits of Okta. Does anyone have decent experience working rolling a in-house single sign-on solution, or similar, that can share a bit about maintaining such service?
dang 5y ago
Related ongoing thread: New Updated Okta Statement on Lapsus$ - https://news.ycombinator.com/item?id=30774193 https://news.ycombinator.com/item?id=30774193 - March 2022 (24 comments) Also: DEV-0537 (LAPSUS$) Criminal actor targeting organizations - https://news.ycombinator.com/item?id=30774406 https://news.ycombinator.com/item?id=30774406 - March 2022 (0 comments) Lapsus$ hackers leak 37GB of Microsoft's alleged source code - https://news.ycombinator.com/item?id=30763623 https://news.ycombinator.com/item?id=30763623 - March 2022 (117 comments)

341 points by rcoppolo 5y ago

Copy / Paste from Lapsuss telegram ;) https://www.okta.com/blog/2022/03/updated-okta-statement-on-lapsus/ https://www.okta.com/blog/2022/03/updated-okta-statement-on-... I do enjoy the lies given by Okta. 1. We didn't compromise any laptop? It was a thin client. 2. "Okta detected an unsuccessful attempt to compromise the account of a customer support engineer working for a third-party provider." - I'm STILL unsure how its a unsuccessful attempt? Logged in to superuser portal with the ability to reset the Password and MFA of ~95% of clients isn't successful? 4. For a company that supports Zero-Trust. Support Engineers seem to have excessive access to Slack? 8.6k channels? (You may want to search AKIA* on your Slack, rather a bad security practice to store AWS keys in Slack channels ) 5. Support engineers are also able to facilitate the resetting of passwords and MFA factors for users, but are unable to obtain those passwords. - Uhm? I hope no-one can read passwords? not just support engineers, LOL. - are you implying passwords are stored in plaintext? 6. You claim a laptop was compromised? In that case what suspicious IP addresses do you have available to report? 7. The potential impact to Okta customers is NOT limited, I'm pretty certain resetting passwords and MFA would result in complete compromise of many clients systems. 8. If you are committed to transparency how about you hire a firm such as Mandiant and PUBLISH their report? I'm sure it would be very different to your report :) _________________________________________________________________________________________________________________________________________________________________________________________________________ https://www.okta.com/sites/default/files/2021-12/okta-security-privacy-documentation.pdf https://www.okta.com/sites/default/files/2021-12/okta-securi... 21. Security Breach Management. a) Notification: In the event of a Security Breach, Okta notifies impacted customers of such Security Breach. Okta cooperates with an impacted customer’s reasonable request for information regarding such Security Breach, and Okta provides regular updates on any such Security Breach and the investigative action and corrective action(s) taken. - But customers only found out today? Why wait this long? 9. Access Controls. Okta has in place policies, procedures, and logical controls that are designed: b. Controls to ensure that all Okta personnel who are granted access to any Customer Data are based on leastprivilege principles; kkkkkkkkkkkkkkk 1. Security Standards. Okta’s ISMP includes adherence to and regular testing of the key controls, systems and procedures of its ISMP to validate that they are properly implemented and effective in addressing the threats and risks identified. Such testing includes: a) Internal risk assessments; b) ISO 27001, 27002, 27017 and 27018 certifications; c) NIST guidance; and d) SOC2 Type II (or successor standard) audits annually performed by accredited third-party auditors (“Audit Report”). I don't think storing AWS keys within Slack would comply to any of these standards?

ttt2022 5y ago
> kkkkkkkkkkkkkkk "kkkkkkk" is the Brazilian way of typing "hahaha". Is Lapsus from South America?
- hudsonjr 5y ago
  I believe they are Brazil. Also a month or two back there were claims that a member accidentally doxxed themselves a couple times, and they were in Spain.

jgrahamc 5y ago

Lots more detail: https://blog.cloudflare.com/cloudflare-investigation-of-the-january-2022-okta-compromise/ https://blog.cloudflare.com/cloudflare-investigation-of-the-...

ktsayed 5y ago
the difference in level of detail and amount of information provided has been out of this world. Thank you!
- chockchocschoir 5y ago
  Also a fun exercise in "Show don't tell" when it comes to transparency. Okta writes "We are deeply committed to transparency" but shows none in their blogpost in contrast to CloudFlare, that doesn't write anything about transparency but displays a lot of it. A bit like queuing for your internet providers customer support for 3 hour and hearing "We care about customer satisfaction" every five minutes.
indigodaddy 5y ago
I thought that a CF person (can’t remember if it was Prince or not) said in the main HN thread yesterday, that CF uses their own homegrown SSO internally, and Okta externally, but this blog article seems to infer the opposite… Anyway, I likely misinterpreted yesterday’s comment..
- deleted 5y ago
  [deleted]
- 0x0000000 5y ago
  I think you're referring to this tweet: https://twitter.com/eastdakota/status/1506148082194386949 https://twitter.com/eastdakota/status/1506148082194386949 I believe @eastdakota is saying that Cloudflare has their own homegrown SSO internally, but they do not make that available externally to their customers (it's not a public product that one can buy). I don't think that the tweet was saying that they use Okta externally.

eyeareque 5y ago

It feels like a lawyer heavily tweaked this to sound better than it really is.

swiftcoder 5y ago
That's just a reality of corporate disclosures, I'm afraid. No one is going to let something like this go to press without a full round of legal and PR editing.
- chippiewill 5y ago
  I think there's two ways about it though. Most "good" companies (e.g. Cloudflare) will try to be transparent and proactive without taking on liability. In this case it reads as though Okta are obfuscating the truth, and that's not good.
WrtCdEvrydy 5y ago
Source: https://www.google.com/search?q=okta+stock https://www.google.com/search?q=okta+stock
- etcet 5y ago
  Besides the opening it doesn't appear to have moved very much. I wonder if LAPSUS$ have short positions open and are frustrated it's not moving which is why they're posting responses to Okta and then updated their response with more information (as linked above).

koolba 5y ago

> Support engineers do have access to limited data - for example, Jira tickets and lists of users - that were seen in the screenshots. Support engineers are also able to facilitate the resetting of passwords and MFA factors for users, but are unable to obtain those passwords. This means they could have reset anybody’s credentials and logged in. There would a record of it if the audit logs are valid, but saying no action is needed may be a stretch.

giaour 5y ago
It's been a minute since I was an admin in an Okta directory, but don't all resets use a self-service flow? In order to log in to someone's account, I think you need to compromise their email, too.
- dhagz 5y ago
  They do indeed use a self-service flow.
- codebje 5y ago
  Super admins can set a temporary password. But they can also change a user's email address, disable password and email change notifications, lock out all other admins... They have complete control of the org. It's pretty clear there is no super admin breach here. None of the screenshots show an admin interface - the app portal shot clearly shows a distinct lack of the "Admin" button. No user directory shots. There is a single image of a password reset confirmation, but those are also in documentation so it's hardly a smoking gun. It seems far more likely that a support engineer had their laptop compromised and their limited access was used to try and make a mountain out of a molehill. Not like a ransomware group would have reason to over-exaggerate their access and ability, right?
bhaney 5y ago
> This means they could have reset anybody’s credentials and logged in Does it? It specifically says "but are unable to obtain those passwords," which reads to me like they are able to trigger a password reset email to the user, but are not actually able to set the password themselves.

dogecoinbase 5y ago

More than a little concerning that they apparently investigated this in January, and while there's a lot of talk about what could or could not have happened, they don't seem to know what actually happened, and no customers were notified (but now: "[we are] identifying and contacting those customers that may have been impacted).

Melatonic 5y ago
I believe that is because they are now hitting the legal limit of when they are required by law to notify people.

chockchocschoir 5y ago

> Support engineers are also able to facilitate the resetting of passwords and MFA factors for users, but are unable to obtain those passwords. Very ambiguous statement, not really fitting in with the whole "deeply committed to transparency" image they are trying to emit. What does "facilitate" really refer to here? If it was just triggering it, they would have said so, presumably. And why is only passwords mentioned as what couldn't be obtained and not the tokens from MFA as well, does that mean they could obtain those tokens? I wonder how it fits in with the groups own statements that they still have active access. Gonna be interesting to see what Lapsus$ replies to this statement.

phphphphp 5y ago
what I don’t get is, if support can’t do anything but “reset” which doesn’t expose the ability to gain access… how is support helping users? If a user can access their email, then they can reset themselves — surely? The idea that support can just trigger a reset email makes little sense. Perhaps Okta has some complex mechanisms that I am not aware of, but if this was any system I’ve ever worked on, an employee could take over an account if they so desired.
- deleted 5y ago
  [deleted]
- mdoms 5y ago
  You should do a stint in support. You'd be amazed how many people would rather interact with support than click the Forgot Password link.
  - phphphphp 5y ago
    As much as I’d like to forget, I’ve done a lot of support and much of that was authentication issues. I can certainly imagine in a corporate environment that some contingent of users would prefer to be hand-held through the reset request process, but all of them? My expectation (and experience of other similar systems) was that Okta would not allow password resets by anyone but the organization administrators. However, that doesn’t appear to match up with what has been disclosed here.

smcl 5y ago

> In January 2022, Okta detected an unsuccessful attempt to compromise the account of a customer support engineer working for a third-party provider It looked kinda successful though...

Helloyello 5y ago
duncan-donuts 5y ago
> The report highlighted that there was a five-day window of time between January 16-21, 2022, where an attacker had access to a support engineer’s laptop. This is consistent with the screenshots that we became aware of yesterday. Yeah, it was.
- djrogers 5y ago
  You can take my laptop from me and have access to it without having compromised my Okta account. In that scenario you wouldn't have my okra password or my MFA - what you would have is transient access to everything I'd already auth'd to until it times out and requests that you auth again.
  - lIIIllllIIII 5y ago
    At which point your browser probably auto-fills the credentials again :-)
    - d3nj4l 5y ago
      But ideally you would have MFA on a second device, so just the credentials aren't enough.
benatkin 5y ago
I think they're meaning it like a login attempt here. If you submit a login form 5 times, that's 5 login attempts. Another similar example is free throw attempts. https://www.statmuse.com/nba/ask/most-free-throw-attempts-per-game-2021 https://www.statmuse.com/nba/ask/most-free-throw-attempts-pe... I wouldn't have realized that unless I'd read far enough to see that Entity A did compromise Account B. Since the author didn't define what an attempt in this context means, I think it would be proper to assume that attempt meant the overall effort to compromise the account.

mimikatz 5y ago

I don't understand how they can say "unsuccessful attempt to compromise the account of a customer support engineer" . then can say "Following the completion of the service provider’s investigation, we received a report from the forensics firm this week. The report highlighted that there was a five-day window of time between January 16-21, 2022, where an attacker had access to a support engineer’s laptop. This is consistent with the screenshots that we became aware of yesterday." and the screenshots of the attackers looking at Okta's support portal.

vault 5y ago
If somebody uses my laptop, my Gmail account is not compromised; I'm being dolphined. Of course 5 days is quite a long time, but this is just to clarify what you didn't understand.
- mimikatz 5y ago
  If I use your laptop to get access to your Gmail isn't your Gmail account compromised? I might not have access to your Gmail username and passwords (and MFA), but I can read your email, I can send email as you, etc etc. I feel like I have compromised your gmail account. If I steal your secure token and log into you through a cloned browser session and access your gmail have I compromised your gmail? It feels like it. Maybe it is just a distinction without a difference.
  - tomnipotent 5y ago
    > your Gmail account compromised The access is transient and you remain in ownership over the credentials and account, because the credentials were not compromised (just the programs/browsers with pre-existing auth). Though with physical access it's probably only a mater of time before local admin passwords are brute forced and access to keychain/browser saved logins is inevitable? > If I steal your secure token It's more like you just logged in using your secure token then someone stole the device and took advantage of that. I think we can all agree there's a difference between having access to the laptop and access to the account without the laptop.

skilled 5y ago

I mean, ultimately, it is now up to Lapsus$ to confirm this. If everything they say (and the Cloudflare post, also) is true then I don't think anyone should be worried.

Johnny555 5y ago
It's an interesting world we live in if the word of an organization that earns a living by stealing data and extorting companies is trusted more than the word of a public company.
- MrStonedOne 5y ago
- lnxg33k1 5y ago
  I would say it's more about what each entity has at stake, the public company could be read as "An entity which sold something that didn't have the capability to offer and has a lot to lose if the issues are uncovered" Against "Someone that what has to lose at this point?"
  - Johnny555 5y ago
    "Someone that what has to lose at this point?" What to lose? Their reputation? Both sides have incentive to stretch the facts. But Okta has more accountability since if an Okta customer comes forward and says "We had credentials of several of our users maliciously reset during that time period and have the logs to prove it", then Okta is going to have a hard time of it. If Okta comes up with proof that Lapsus didn't have the access they said they did, Lapsus is not going to have many "customers" complaining "you didn't crime that other company as much as you said you did"

tofuahdude 5y ago

> Okta service has not been breached and remains fully operational > highlighted that there was a five-day window of time between January 16-21, 2022, where an attacker had access to a support engineer’s laptop These are some impressive mental gymnastics!

RL_Quine 5y ago
Yeah, this blog post is shoveling it. They were popped, they aren't internally consistent in their dismissal of it.
benatkin 5y ago
What got me was this: > Okta detected an unsuccessful attempt to compromise the account of a customer support engineer working for a third-party provider > highlighted that there was a five-day window of time between January 16-21, 2022, where an attacker had access to a support engineer’s laptop
c7DJTLrn 5y ago
You didn't see graphite. Identity providers cannot be compromised!
- chippiewill 5y ago
  Only a support engineer was compromised. Not great, not terrible.
Ozzie_osman 5y ago
Not saying this is what happened or defending Okta, but these two statements could be true. Assuming the support engineer had ACCESS to allow him to do some bad stuff, but they have audit logs to prove his account didn't use that access (except to take screenshot), both statements could be true. It's unlikely but possible.
deleted 5y ago
[deleted]

paxys 5y ago

There were a lot of doomsday predictions in yesterday's thread before any real info had been shared, but it was always the more likely scenario that a support agent contracted through a vendor would have limited read access to their internal systems and wouldn't be able to cause any real damage.

evan_ 5y ago
you can do a lot of damage with read access depending on what you're able to read
- chippiewill 5y ago
  Especially with how much access they had on the company Slack org. Everyone's terrible with secops, but Okta employees were apparently dumping AWS keys into public channels.
- j4yav 5y ago
  They are at least saying that Okta engineers were posting AWS keys in Slack, which they had full access to and found by searching for AKIA.

hericium 5y ago

> limited data - for example, Jira tickets I wonder how many passwords and other creds were harvested from tickets alone. Lapsus$ went after Okta's customers and in some cases successfully, it appears.

tuwtuwtuwtuw 5y ago
> it appears. Where does it appear like that? I have tried to follow this but the only thing I have seen shares is info from within Okta. I have seen email addresses of CloudFlare employee in screenshot of Okta, is that what you are referring to?
- flutas 5y ago
  Lapsus$ has released data from Microsoft, Nvidia, Ubisoft and Samsung over the past few months. https://www.vice.com/en/article/y3vk9x/microsoft-hacked-lapsus-extortion-investigating https://www.vice.com/en/article/y3vk9x/microsoft-hacked-laps...

templapsusread 5y ago

Lapsus has responded https://img.guildedcdn.com/ContentMedia/e4149dc99f447074cb2c385f1929d262-Full.webp?w=513&h=1033 https://img.guildedcdn.com/ContentMedia/e4149dc99f447074cb2c...

templapsusread 5y ago
they edited and added more content https://img.guildedcdn.com/ContentMedia/372280f522049aa0b0eb1f5255d1b921-Full.webp?w=483&h=1700 https://img.guildedcdn.com/ContentMedia/372280f522049aa0b0eb...
- intunderflow 5y ago
  To note in some of the earlier screenshots you can see they have the EC2 Instances menu open in their tabs - that's a bit concerning, why does a support engineer need AWS EC2 access?
  - Consultant32452 5y ago
    The LAPSUS$ post suggests that they queried the AWS keys out of Slack. So the support engineers just have access to Slack, and Okta engineers were dumb enough to put those keys in Slack.
    - gedy 5y ago
      I'm incredulous an auth focused company would do this without someone freaking out? Even my much smaller SaaS companies would react quickly to stop and rotate these if this happened.
      - zmmmmm 5y ago
        looking closely at that I'm suspicious that lapsus$ is playing up what were perhaps trivial or ephemeral keys that were non-sensitive ... eg: test / dev / debug instances etc. The reason I think that is because if they really had keys for production machines it seems very unlikely they wouldn't have used them to produce some more damaging collateral than they've presented.

mdoms 5y ago

Ctrl+F 'very seriously' There it is.

HL33tibCe7 5y ago

> The Okta service has not been breached and remains fully operational Oh okay then, pack up guys, everything’s fine I really hate this kind of corporate bullshit > There are no corrective actions that need to be taken by our customers. Isn’t this an objectively false statement?

CoastalCoder 5y ago
> Isn’t this an objectively false statement? IMHO it's more of an empty statement. They never pin down what end-state is being discussed. So we can't evaluate if "additional steps are needed" to achieve that (unspecified) state. It could be that the speaker is intentionally equivocating. I.e., knowing that the audience will assume some particular end-state. But if cornered, the speaker can claim (lie) that he implicitly meant a different end state.

nimbius 5y ago

>The Okta service has not been breached and remains fully operational. There are no corrective actions that need to be taken by our customers. despite an overwhelming preponderance of damning evidence from twitter (as well as the hacker themselves) you've somehow managed to find yourselves secure instead? Christs whiskers thats some impressive doublethink. Its also an excellent opportunity to fall on a sword that gives future attackers --hat colour dismissed-- an immediate incentive to simply publish regardless as you dont appear to be acting with very much good faith. if this sort of an attack is a carrot, you've clearly shown a predilection for the stick.

gurjeet 5y ago
Melatonic 5y ago
This is going to get interesting in the days ahead
Bombthecat 5y ago
According to gdpr, this post could be illegal (because.. Lie)
- jbrownbridge 5y ago
  IANAL but this definitely seems like a breach of Art 33 of GDPR as it meets the criteria of involving personal data (list of users was exposed) and the 72 hour window has passed.
hughrr 5y ago
This is prime bad PR. This is going to be an absolute shit show.
GordonS 5y ago
If there is one thing you want from a 3rd party auth provider, it's trust - this is not the time to play word games. I'd have far more faith in them if they were transparent about what had happened, what they're doing about it, and how they will make sure it can't happen again. Instead, they are being weasels - I for one, will not be using their services again, and this behaviour is the reason why. Here's another example from a couple of years back where they used some really weasely language to claim they weren't vulnerable to a CVE (spoiler: they were): https://twitter.com/jonoberheide/status/1506280347306188805?t=zcmm1nU3E5_zlcvFwIDt8w&s=03 https://twitter.com/jonoberheide/status/1506280347306188805?...

sergiotapia 5y ago

>The Okta service has not been breached and remains fully operational. There are no corrective actions that need to be taken by our customers. The rest of the note literally show they have been breached. What?

deleted 5y ago

[deleted]

thorin1 5y ago

> there was a five-day window of time between January 16-21, 2022, where an attacker had access to a support engineer’s laptop. > Support engineers are also able to facilitate the resetting of passwords and multi-factor authentication factors for users No breach at all here.

datavirtue 5y ago

Felt like a bluff to me. The claims were outlandish.

deleted 5y ago

[deleted]

trhway 5y ago

Looks like Lapsus didn't do any damage and thus Okta dismisses the breach as not a breach - just like a proof-of-breach starting notepad.exe on compromised machine was at one of my old jobs dismissed because notepad doesn't do any damage. The security professionals today are the second sellers of snake oil after MBAs. Cue SolarWind with their it is ok for binaries' signatures to differ as they get deformed while being forced through the internet pipes :) Lapsus not being a "state level actor" denied that easy get-out-of-jail-free card to Okta.

hcazz 5y ago
>The security professionals today are the second sellers of snake oil If someone breaks into your house, and stays there for a week, would you say they didn't really break in because they didn't murder you? >proof-of-breach Maybe you're referring to a "proof of concept"? A "proof of breach" in the security industry is an incident to be investigated, and if necessary, involve law enforcement. It isn't meddling kids that didn't cause any harm. As a side note, I've never heard anyone use the term "proof of breach" in that context in the industry. The fact that Okta didn't detect this earlier is concerning in its own right, let's not downplay the fact that the level of access that third party providers have is not a solved issue in the industry. The RCA/post mortem/follow up actions from Okta's side should not be "they got access but didn't do anything with it, we don't need to change anything".

t0bia_s 5y ago

Reply from Lapsus$ on Telegram: I do enjoy the lies given by Okta. 1. We didn't compromise any laptop? It was a thin client. 2. "Okta detected an unsuccessful attempt to compromise the account of a customer support engineer working for a third-party provider." - I'm STILL unsure how its a unsuccessful attempt? Logged in to superuser portal with the ability to reset the Password and MFA of ~95% of clients isn't successful? 4. For a company that supports Zero-Trust. Support Engineers seem to have excessive access to Slack? 8.6k channels? (You may want to search AKIA* on your Slack, rather a bad security practice to store AWS keys in Slack channels ) 5. Support engineers are also able to facilitate the resetting of passwords and MFA factors for users, but are unable to obtain those passwords. - Uhm? I hope no-one can read passwords? not just support engineers, LOL. - are you implying passwords are stored in plaintext? 6. You claim a laptop was compromised? In that case what suspicious IP addresses do you have available to report? 7. The potential impact to Okta customers is NOT limited, I'm pretty certain resetting passwords and MFA would result in complete compromise of many clients systems. 8. If you are committed to transparency how about you hire a firm such as Mandiant and PUBLISH their report? I'm sure it would be very different to your report :) _________________________________________________________________________________________________________________________________________________________________________________________________________ https://www.okta.com/sites/default/files/2021-12/okta-security-privacy-documentation.pdf https://www.okta.com/sites/default/files/2021-12/okta-securi... 21. Security Breach Management. a) Notification: In the event of a Security Breach, Okta notifies impacted customers of such Security Breach. Okta cooperates with an impacted customer’s reasonable request for information regarding such Security Breach, and Okta provides regular updates on any such Security Breach and the investigative action and corrective action(s) taken. - But customers only found out today? Why wait this long? 9. Access Controls. Okta has in place policies, procedures, and logical controls that are designed: b. Controls to ensure that all Okta personnel who are granted access to any Customer Data are based on leastprivilege principles; kkkkkkkkkkkkkkk 1. Security Standards. Okta’s ISMP includes adherence to and regular testing of the key controls, systems and procedures of its ISMP to validate that they are properly implemented and effective in addressing the threats and risks identified. Such testing includes: a) Internal risk assessments; b) ISO 27001, 27002, 27017 and 27018 certifications; c) NIST guidance; and d) SOC2 Type II (or successor standard) audits annually performed by accredited third-party auditors (“Audit Report”). I don't think storing AWS keys within Slack would comply to any of these standards?

ppvfy 5y ago

> The Okta service has not been breached and remains fully operational. There are no corrective actions that need to be taken by our customers. > Support engineers are also able to facilitate the resetting of passwords and multi-factor authentication factors for users, but are unable to obtain those passwords. Those two things are at odds with each other, no?

dboreham 5y ago

The post could use some review/edit. This: "a customer support engineer working for a third-party provider" actually means "one of our customer support engineers, who happens to be an employee of another company, working for us under contract".

hackmiester 5y ago
Don't believe for a moment that this misdirection is unintentional. It's one big reason you might have contract workers instead of employees in this role, actually.
- nopcode 5y ago
  In EU, the GDPR closes this loophole: > Where that other processor fails to fulfil its data protection obligations, the initial processor shall remain fully liable to the controller for the performance of that other processor’s obligations. GDPR Art 28(4): https://gdpr-info.eu/art-28-gdpr/ https://gdpr-info.eu/art-28-gdpr/

siskiyou 5y ago

I've never worked at Okta, but I've worked with several production ticketing systems at big and small companies, and all of them contained critical information about customers and operations. Including credentials.

dboreham 5y ago
Not putting secrets and sensitive data in bug reports / tickets has been a thing for at least 20 years, so you worked at some crappy run places.
- wepple 5y ago
  Ah, I see you’ve never worked at a large company with lots of humans

daenz 5y ago

Given the nature of what Okta does, is this going to kill them? It's like the business version of a headshot.

gtsteve 5y ago
Probably not. It's really inconvenient for a large organisation to drop them given how embedded identity gets into everything. It's reputational damage but something worse [0] happened to OneLogin a few years back and they're still around. [0] https://www.csoonline.com/article/3389138/how-onelogin-responded-to-its-breach-and-regained-customer-trust.html https://www.csoonline.com/article/3389138/how-onelogin-respo... (unsurprisingly the canonical article from their weblog is missing now)
- password4321 5y ago
  https://news.ycombinator.com/item?id=14458105 https://news.ycombinator.com/item?id=14458105 | https://web.archive.org/web/20170621202358/https://www.onelogin.com/blog/may-31-2017-security-incident https://web.archive.org/web/20170621202358/https://www.onelo...

lambda_dn 5y ago

My booking.com account was hacked and someone from China booked a hotel using my account (Im in UK). Managed to cancel it for free, changed password, logged out of all sessions, turned on 2FA and removed all cards. Wondering if this is related.

0xbadcafebee 5y ago
My booking.com account also notified me someone booked a hotel in Brazil, and I went in and cancelled it and reported it. Extra weird because the notification came in through an old email address. That was on Saturday, Mar 19, 10:43 PM EDT. But it could have just been a large attack on Booking.com, unknown if it's Okta-related (and not necessarily a compromise, if I accidentally reused a password)

wellthisisgreat 5y ago

Was there any development to the Nvidia hack? Didn't they demand open-sourcing all the drivers or something like that? Or was that all bluff and lapsus didn't have anything

londons_explore 5y ago

Anyone any idea how it appears this breach could have caused far more mayhem, yet the attackers didn't? Is it common for attackers to just get bored and leave taking just a few screenshots?

physicsguy 5y ago

“Nobody ever got fired by choosing Microsoft”

megatron4537 5y ago

Did anyone get an impromptu password reset recently?

uean 5y ago

I saw the tweet a few mins after it was posted (thanks to the original article here on HN). We are a small startup and made the call to treat this like an exercise in failover process and ripped Okta out from our systems in around an hour. It was satisfying to see the process work. Original emails to staff were to wait for Okta to weigh in with their response before moving back to SSO but… not sure how that’s looking now given how they’re handling things so far.

darepublic 5y ago

They look bad from this but really if nothing else comes out seems like they weathered this OK

jzer0cool 5y ago

I see the benefits of Okta. Does anyone have decent experience working rolling a in-house single sign-on solution, or similar, that can share a bit about maintaining such service?

dang 5y ago

Related ongoing thread: New Updated Okta Statement on Lapsus$ - https://news.ycombinator.com/item?id=30774193 https://news.ycombinator.com/item?id=30774193 - March 2022 (24 comments) Also: DEV-0537 (LAPSUS$) Criminal actor targeting organizations - https://news.ycombinator.com/item?id=30774406 https://news.ycombinator.com/item?id=30774406 - March 2022 (0 comments) Lapsus$ hackers leak 37GB of Microsoft's alleged source code - https://news.ycombinator.com/item?id=30763623 https://news.ycombinator.com/item?id=30763623 - March 2022 (117 comments)