Hackers claim to have breached Okta systems
twitter.com
twitter.com
I checked their telegram group and I can see that they specifically recruit people with access to VPNs/internal support systems. This okta breach seems to have happened through similar means. The group has made specific calls for access to gaming companies, hosting providers, telcos, call centers, and bpm providers. They offer payment.
It doesn’t feel difficult to see how some overworked, underpaid support agent (or even a well paid disgruntled one) might decide to go with this. Just takes 1 well placed agent to give creds and this group has access to a huge attack surface instantly. This might sound like an overreaction, but corporations in the future might need to make least privilege access and access logging everything a priority from day 1.
https://t.me/minsaudebr/162 (Link to the recruitment message)
This raises a number of architectural questions for Okta:
- Can a support engineer for customers in one region access the systems/databases relied upon by customers in other regions?
- Do employees get notified when their account is logged into or used (e-mail/SMS/otherwise)?
- Do customers get notified when a support engineer accesses (with privileges) a system/database the customer relies upon?
[1] https://work180.com/en-US/for-women/job/215617/tier-2-techni...
Otherwise, the goal is to give each agent access to an arbitrary subset of users, so it's harder to recruit an agent who can access the "target" victim customer.
* Balancing the assignment of users to appropriate agents
* Less flexibility for agents to be specialized (instead of an agent responding to all X related tickets everywhere in the world, an agent must respond to X, Y, and Z from these specific users)
* Handling user coverage when agents are busy, PTO, etc. The spirit of splitting agent access would mean agents would need to request access from an out-of-region authority in order to help with things last minute. An authority who will be expected to be responsive 24/7 without also being an attack vector
Technically, the current model is a full M customer x N agents mapping. All customers served by all Agents. Adding some 0's to that mapping should certainly be possible without sacrificing much from current system. No way to know how many is reasonable
All that said, there is a natural logic that arises from this 'analysis' - Limit access to customers who are inactive, or who rarely have issues. A common sense addition would be to raise their default priority for when they do interact.
The screenshots show that LAPSUS$ had access via the account of the outsourced Costa Rican based Tier 2 TSE worker to view details of and reset the password of a UK-based site reliability engineer of a well known Internet global infrastructure company. This level of access in itself doesn't sound hugely problematic on its own if it weren't for job applications for Okta Tier 2 TSE workers indicating server/network administration responsibilities. There is some publicly published information that provides more context on what access a Tier 2 TSE worker may have to customer data:
- Okta's security whitepaper [1] states that multi-factor authentication is needed for administrative access to AWS instances (host operating systems) so this could have possibly prevented LAPSUS$ from using their access to do anything more sinister than perhaps causing customer organisation-wide outages by disabling/resetting all their user accounts. The response for control AC-17(06) at [3] indicates that remote access requires valid multi-factor authentication to occur so if LAPSUS$ could gain remote access, perhaps they had already gained the ability to generate valid multi-factor authentication tokens, or otherwise bypass multi-factor authentication for remote access.
- The response for controls IA-02(09), AC-06(07), PS-04(01) and SA-12 at [3] indicates that Okta employee access to customer data is deemed privileged access and that fewer than 30 Okta employees have this level of privileged access to this customer data. I doubt this is true, unless the SP 800-53r4 responses at [3] are only referring to the US government tenancies that are hosted separately from tenancies of global companies.
- The response for controls SI-04(12), SI-04(19) and SI-04(20) at [3] indicates that changes made to a customer tenancy (for example resetting passwords for customer users as shown in the LAPSUS$ screenshots) should have triggered events being sent to both Okta's Splunk SIEM system and also to a customer SIEM system if they have set one up. Theoretically this should quickly raise a red flag to the customer if LAPSUS$ were to use this access to bulk deny the customer access to their ICT systems. It is however not clear that privileged access to the host operating system for the AWS instance would cause an event to be sent to the customer's SIEM system.
== Level of segregation of customer tenancies and whether LAPSUS$ may have been using Okta access to attack customers ==
It's fairly straightforward to enumerate the Okta hosting arrangements from DNS records as listed below. The sample targeted company in the screenshots has their Okta tenancy hosted within AWS region us-west-2 (Okta OK7) and other screenshots showed that the compromised account had recently accessed privileged access tools for OK3, OK8 and OK12. Thus it would appear that a Costa Rican-based Tier 2 TSE worker would have access to customer information within perhaps any of the clusters (not geographically restricted).
ok-crtr-tls1-nlb-36253386bec48ce6.elb.us-east-1.amazonaws.com - response when a tenancy is invalid/doesn't exist
ok2-crtr-tls12-nlb-xxxxxxxxxxxxxxxx.elb.us-east-1.amazonaws.com - companies (global)
ok3-crtr-tls12-nlb-xxxxxxxxxxxxxxxx.elb.us-east-1.amazonaws.com - companies (global)
ok4-crtr-tls12-nlb-xxxxxxxxxxxxxxxx.elb.us-east-1.amazonaws.com - companies (global)
ok5-crtr-tls12-fips-nlb-xxxxxxxxxxxxxxxx.elb.us-west-2.amazonaws.com - US government agencies
ok6-crtr-tls12-nlb-xxxxxxxxxxxxxxxx.elb.us-east-2.amazonaws.com - companies (global)
ok7-crtr-tls12-nlb-xxxxxxxxxxxxxxxx.elb.us-west-2.amazonaws.com - companies (global)
ok8-crtr-tls12-nlb-xxxxxxxxxxxxxxxx.elb.ap-southeast-2.amazonaws.com - Australian government agencies and some other Australian companies/associations
ok9-crtr-tls12-nlb-xxxxxxxxxxxxxxxx.elb.eu-west-1.amazonaws.com - unknown / no customers found
ok10-crtr-tls12-fips-nlb-xxxxxxxxxxxxxxxx.elb.us-east-2.amazonaws.com - US government agencies
ok11-crtr-tls12-nlb-xxxxxxxxxxxxxxxx.elb.us-east-2.amazonaws.com - unknown / no customers found
ok12-crtr-tls12-nlb-xxxxxxxxxxxxxxxx.elb.us-west-2.amazonaws.com - unknown / no customers found
microsoft.okta.com - likely customer - ok3-crtr-tls12-nlb-dfef298ffc8f82ca.elb.us-east-1.amazonaws.com
nvidia.okta.com - likely customer - ok2-crtr-tls12-nlb-acd62f33a2a6a463.elb.us-east-1.amazonaws.com
vodafone.okta.com - confirmed customer [4] - ok4-crtr-tls12-nlb-29367a8e4bb80716.elb.us-east-1.amazonaws.com
samsung.okta.com [5] - possibly not a customer - ok-crtr-tls1-nlb-36253386bec48ce6.elb.us-east-1.amazonaws.com
ubisoft.okta.com - possbily not a customer - ok-crtr-tls1-nlb-36253386bec48ce6.elb.us-east-1.amazonaws.com
lg.okta.com [5] - possibly not a customer - ok-crtr-tls1-nlb-36253386bec48ce6.elb.us-east-1.amazonaws.com
[1] https://www.okta.com/resources/whitepaper/okta-security-tech...
[2] https://trust.okta.com/security/
[3] https://www.okta.com/resources/whitepaper/using-okta-to-prot...
[4] https://miniorange.com/atlassian/atlassian-single-sign-on-ss...
[5] Note: also tried similar names known to be used by company divisions.
My (admittedly outdated) experience is that this is always the case, regardless of any assurance vendors might have provided to the customer. In the end, people have to get stuff done, and offshore bodies are just too cheap to pass on. Things might have changed a bit since GDPR but, in practice, I expect there will always be "channels" for people to reach out cross-region.
Just because a customer is based in Europe doesn't mean they don't need to get a hold of support at 03:00 local time. Even small, growing, startups now have HQs in one part of the world and staff across the globe due to the ease of movement many enjoy.
No. It's a tricky situation too, since even if one did receive such email, I won't look at work email until working hours. So even with such a notification, if you logged in on friday 20:00, you've over 50 hours to do your work.
I might also add that Okta DOES NOT support any form of physical 2FA (e.g.: yubikeys), only software-based ones.
Not sure where you got this from, but we've been using yubikeys for a few months now. They even allow policies to only allow physical 2FA methods.
You might be operating under outdated information. I absolutely use a YubiKey with my Okta account.
A single support account reading say 10x the normal number of accounts per day, with a different geographic distribution than the norm, should ring alarm bells. It’s not enough to say “well shucks they have access to the data, guess we’ll do nothing”
As an industry I don't know if we have made rational choices along the way.
This is cope - managers repeat this narrative so they can blame some other factor rather than having to put in the work to fix the problem of hiring good FTEs. Unfortunately, this narrative has been repeated so often that it is perceived to be axiomatic, which is why it is repeated without any criticism.
No, its not that hard to find good FTEs, you just haven't tried hard enough, or you're not paying enough, or your glassdoor reviews are bad.
this is not a negligible barrier. Sure you could argue that a business that isnt successful enough to hire for that expensive FTE maybe shouldnt exist at all, but a lot more is possible by being able to outsource it. And there really isnt a good reason why it cannot be outsourced from an operations standpoint - it is entirely a security problem. It's not like auth is hard to do for a third party.
e.g. nobody got a promotion because the change they pushed for 5 years ago prevented an attack today.
That's not to say people are just greedy and only chase what gets them a promotion, but replace "promotion" with "received positive feedback".
A portion of our industry seems to be bad at risk calculation, but that's not inherent to the SaaS model - this app very well could've been made with strictly separated tenants.
> well-tested, audited and certified software package
Who is selling this?
> If you receive a credible bribe and report it immediately to X we will report to relevant authorities and provide a bonus equal to the value of the bribe (capped at Y).
If you reported a fraudulent bribe, which was reported to the police there is a risk the briber and you both are arrested.
I see only trouble with this approach.
Just hire good people, treat them right, have sensible audit and monitoring procedures.
It's very difficult.
Some will take it as a sign they should poke further your system, or shop around for others paying better.
That's kind of a weird moral take on things. If you don't like the bounties offered then simply don't invest time in the platform looking for things to exploit.
Industries ex software know that since time immemorial.
Prob the software way of solving that is with least privileged access, automatic auditing and approvals.
I wonder why not even security companies are doing that correctly though.
Why should a business care if it gets hacked? It's the users that suffer and they don't have an alternative.
Only if you assert that it is only useful if it solves 100% of the cases.
There are other motivations, but money is a big one. If you could block X% for a large value of X (I'd say easily > 50) then you're better off than before, even if some insiders driven by other motivations still remain.
Similar to how IT in many large companies nowadays runs internal phishing tests.
That changes the risk/reward, so while every reported bribe is a nice cash bonus, accepting any received bribe becomes significantly riskier, and by 'practicing' bribe reporting it becomes the default reaction.
(not a criticism of the comment above me, btw. not point I was making.)
[1] https://www.theregister.com/2022/03/21/microsoft_lapsus_brea...
[2] https://www.wired.com/story/lapsus-hacking-group-extortion-n...
[3] https://analyticsindiamag.com/lapsus-hack-leaves-nvidia-in-a...
And sometimes there are chains of dependencies that need to be swapped out in sequence.
So from acquisitions alone it would seem reasonable to expect that Microsoft at any point in time has at least a handful of usages of certain SaaS offerings, even if MS themselves offer their own versions of those services.
That said, the surface area of these "unofficial" 3rd party systems is likely to be quite small in comparison to whatever their official tech stack looks like (which does -- I would assume -- centre around Azure AD). I'm not expressing an opinion on whether the GP is correct to make this link...
I've worked with some very large companies where internally they (surprisingly to me) make use of competitors' products even when that company makes their own version of that product. There are all sorts of legitimate reasons why this happens.
https://gizmodo.com/microsoft-investigating-potential-lapsus...
That other product/service was compromised, which let hackers hack into MS employee’s computer, which gave them access to Azure infrastructure.
Lesson: ask your (in this case Microsoft) employees to not use work computers for any personal use.
/me goes to check if my password manager company uses Okta.
This is just wild speculation to make up a scenario where Microsoft could be affected by the Okta hack with no evidence to back it up.
[1] https://twitter.com/BillDemirkapi/status/1506109956298317830...
If you are in the 5%, great! You are probably set already.
If you are not, overreacting isn't going to help anyone. There's no need to start writing user login code tonight.
I think it's worth pointing out that replacing Okta for most people isn't just doing login +MFA stuff.
Sure, there's that part of it - but a lot of the value in going with Okta in particular is that so many third parties support integrating with them in ways that other Identity providers are just not supported.
Account lifecycle stuff (via SCIM) is often limited to just Okta support for products.
There's also the account lifecycle stuff so that HR doesn't have to tell you when they hire someone, they just add them into the HR system and all the things flow out from that. Similarly when someone leaves, you can have those workflows go and disable/delete their accounts.
In fact, a third-party’s “Okta integration” should work out of the box with Keycloak or any other IdP.
Wait, what exactly makes this problem so fundamentally hard?
What stops someone from just releasing a software system that solves the authentication infrastructure problem in a general way (e.g. as Kubernetes did for cloud orchestration)?
Kubernetes doesn’t go after it, either; it complicates your system so exponentially that it drives the same lie. All Kubernetes does is assign a workload to a machine and hook crap up to it. That problem was solved in the 1960s by systems that don’t take multiple FTEs just to operate itself. When you look at Kubernetes in this light there’s a moment of clarity waiting regarding why it exists in the first place, and why it will never in a millennium replace Borg.
In 2010, I joined a social media startup. I was the only operations employee on the team of nine who had ever touched an actual server with my hands. We’re on the third or fourth generation of systems people now who’ve never heard anything except the cloud-native drum and how they’ll never be qualified to run their fingers along the faceplate of the computers running their business. paxys is sharing a derivative of that because it is a strongly held industry belief and a safe language to speak in this market. It just doesn’t make it true, and that’s a powerful realization, but that’s not something most people are ready to hear and truly understand.
You’re asking the absolutely right questions. You’re just asking an industry that gave up on itself so long ago that kids born after UTAH2000 can vote now.
I agree. That being said, there's no need to write login code yourself. Trust on the existing, tested, proven OSS solutions and libraries available, if you decide to not rely on a provider like Okta.
Can you recommend some?
On the other hand, I feel fine using GSuite for SSO because we have a much better view of their security.
That said, it sucks that everyone is so fucking bad at security. I maintain that it is not that hard.
What are their usual criticisms? Genuinely curious. I've always hated their UI, their docs, and lack of real support but felt that at least they had security going for them. The last assumption might have been proven wrong tonight.
Also, what would be a reasonable alternative to Okta now that their nearest competitor, Auth0, was acquired by them. Is GSuite a reasonable alternative for SSO with multiple different providers and supporting SAML, etc.? Thanks in advance.
I wouldn't want to make a recommendation, but I'll say that my company uses GSuite.
Add in systems that were built for X and now doing Y. This is hard to get right. A single slip up will lead to you being compromised.
Yeah, people need to stop using memory unsafe languages. They choose not to.
> A single slip up will lead to you being compromised.
Not if you add multiple layers of security. Like sandboxing. Or mTLS. It's not hard to do that.
edit: Let me clarify. Security isn't hard generally, but it's hard individually, because you're drowning under everyone else making it artificially 10000x harder.
Then their SNMP mib doesn't work properly. So you have a a box that is proxying some of your most critical systems that are so old that to integrate them with MFA requires OAG (think mainframes, old ERP systems etc) and you have to take Okta's word for it that the server is secure and not hacked.
They do thankfully support Syslog for logs, but again you have to take their word for it that you're getting all the logs, because you can't access the system to verify.
Having said all that. OAG solves a very real business problem and it is hard to find a competitor in the market with the level of integration it has to legacy platforms.
I don't remember Google having any large-scale security incidens.
Have they been better at playing down their security incidents or are they doing something very right that the rest of the industry can learn from?
yes
> that the rest of the industry can learn from
unlikely
It's simple: they pay absurd amounts of money for top talent and let them work. Look: https://www.levels.fyi/company/Google/salaries/Software-Engi... can your company afford to pay 2-300K cash -- not to mention serious stock -- to bread and butter mid level engineers?
Security isn't just about overflows and injections, outsider enemies vs insider allies. Any human with privileged access that can be compromised will eventually be compromised as the perceived value of his privilege increases beyond the cost of compromising him. Logging, distribution of privileges, and other such solutions aren't really solutions so much as just a sort of cat and mouse game.
I would claim that impenetrable security is not only hard, but ultimately impossible.
For medium to large enterprises, the calculus is harder and there's going to be months of flame war trying to hash that out.
The problem is motivation to break it trends up over time as the service gets more and more popular.
In some ways, if Okta can fall basically anyone can. Sometimes there's an advantage in being smaller. One would hope that the actual attack surface on Okta was smaller than the post seems to imply. That there is even any way to get full access to all customers would seem to be a critical failure.
This might be true, but for someone to "fall" they must be targeted to begin with.
If "LAPSUS$" is after big companies with significant IP which they can hold ransom for millions, as a small business you'll be safe because they won't even bother attacking you, and may not be willing to put the same amount of effort into breaching your small company's SSO than they would for Okta.
Yes, it's going to cost more upfront, but there are a wide range of options between "rely on a blackbox PaaS/SaaS" and "write and deploy everything yourself".
Maybe a company that specializes in this kind of thing? Like Okta?
Agreed. Centralization of attack surface is a major risk.
I understand the allure and have been in situations where even knowing the risks, the path is forced upon us because "nobody is fired for buying IBM".
But yes, a centralized service holding all the marbles is an infinitely more attractive target than lots of disjoint little systems which aren't individually very interesting. The centralized system may be better run (arguable, but at least they have the resources and it is their primary job) but they also face a much higher attack concentration.
A compromise solution is to have both. I've been in one company where okta was used as the primary SSO and for most internal systems the only one. But for the very sensitive resources, one had to be authenticated via okta but also via a homegrown MFA system.
[1] https://www.thediff.co/p/plaid-data-layer-to-payments-layer
In a B2B setting you get rid of a LOT of paperwork and due diligence by just saying "We use Okta for X, Y, Z." Hell for SOC2, Okta got rid of a shit ton of verifications for us at a critical stage of the startup I was leading, Papa.
Sure you can build your own but at that point you're wasting months for zero customer benefit. You could be building product. I don't know what the right answer is.
No, not just that.
Commercial open source companies (COSS) minimise those tradeoffs and give you the best of both worlds. That is - The power of build and the speed of buy.
You can migrate to and from a completely self hosted solution to a managed service as your needs change (for many COSS alternatives)
It doesn't work.
In my book that counts as "obscurity". "We are not an attractive target, hence we won't be targeted". You will be targeted, as long as your defence is weak. Only if you manage to set up a comparable defence to a large provider, this argument flies: because all things equal, attackers will attack the more attractive party. But all things are not equal. (Which I'm not certain about, it may very well be that Okta has a really poor defence in place, in which case my argument falls apart, because you'd be able to "make all things equal" much easier. I doubt this though).
> Are we really at a point where not relying on external account providers is considered unusual, or a bad practice?
No. I consider it reasonable to "build your own", but only in certain cases. Things like auth are not your core domain (unless you are an auth-provider, obviously), so all effort and time you spend on building the umpteenth login/auth-flow is not spent on building the stuff that sets you apart. Even if you drag in a standard library and only spend an afternoon: you're still maintaining it, testing it, etc. And with external parties, generally, you'll be following market best practices: fingerprint-login becomes standard? You'll get it almost for free, whereas in the diy-case you'll be designing, testing, building such progressing tech for ever. The economics for building are just wrong.
As are the security: as pointed out above: I highly doubt you'll be able to match a level of defence a large, focused, experienced party can obtain.
But there may very well be cases in which building your own login/auth makes sense and the tradeoffs in economics and security (and features) make sense. Maybe it has to integrate into some legacy; maybe (legal) requirements enforce you to keep it all in-house, etc.
> In late January 2022, Okta detected an attempt to compromise the account of a third party customer support engineer working for one of our subprocessors. The matter was investigated and contained by the subprocessor. (1 of 2)
> We believe the screenshots shared online are connected to this January event. Based on our investigation to date, there is no evidence of ongoing malicious activity beyond the activity detected in January. (2 of 2)
1. when marketing to customers - "our support engineer"
2. when reporting on an incident - "a third party customer support engineer working for one of our subprocessors"
It's clear some service team at Microsoft used Okta to SSO, or a contractor that did that's why they only got 37GB of code and Bing/Cortona not Windows OS or internal tools.
The group probably enumerated as much access from Okta as possible and when they had every juicy target decided to release it all for the lols. They probably have more in the works too.
I'd suggest everyone today revoke any Okta SSO sessions for your apps and force a new session as a precautionary measure.
Did i miss some news or? I know Okta and Microsoft was compromised, but is there anything which shows it was related except for the hacker group and timing?
Speculation from here on.
In my personal opinion,Cloudflare's actions indicate that Cloudflare was not notified of the breach until today.
```We are aware that @Okta may have been compromised. There is no evidence that Cloudflare has been compromised. Okta is merely an identity provider for Cloudflare. Thankfully, we have multiple layers of security beyond Okta, and would never consider them to be a standalone option.``` - @eastdakota - https://twitter.com/eastdakota/status/1506143353544478724
Thus, it should take approximately zero actual time to conclude what was stated here.
[1] https://blog.cloudflare.com/cloudflare-investigation-of-the-...
Up until that statement I was willing to believe that they only just found out about it.
One can only imagine the many security breaches that are never revealed (from any company).
However, if LAPSUS have more, this could easily lead to them wanting to prove him wrong and release more proof of compromise. If that happens his credibility will be toast.
Holy red flags Batman. How can you be a serious security company while outsourcing such critical components?
Edit: to be clear, I don't know, it's a genuine question. Does "any breach" count?
Otherwise, business as usual.
https://twitter.com/BillDemirkapi/status/1506117152461496323
Organizational endpoint security seems to be much more about incident response than incident prevention. That is, it's more focused on providing a nice audit trail that can be used to find and fire/arrest the perp once a breach occurs than it is at preventing breaches from happening. It probably fills a due-diligence tickbox somewhere, allowing the company to say "if a breach occurs (the probability of which is always nonzero) then we have measures in place to find out how, where, and by whom and mitigate the damage" to shareholders and important customers.
It is a complex issue with entry of nuance I'm too tired to thumb type. I know there are lines that shouldn't be crossed. But it is so naive to think companies shouldn't have an eye on their data.
Do you think banks shouldn't have cameras in their lobbies? Or that tellers can walk in and out of the vault with black bags and no one ask what's inside?
To use your camera analogy, you better have a good lock on the security room holding the tapes.
Software diversity is good. Remotely controlled mono-cultures are bad. IT management and security compliance people need to understand this.
I liken the mindset of (only we will use the remote control software to do good things) to Encryption back doors (only law enforcement will use them to catch criminals). Computer scientists call these 'Exceptional Access Systems' and it has been shown (many times) that it is impossible to ensure they will not be abused and used against you.
Keys Under Doormats: Mandating insecurity by requiring government access to all data and communications:
Software diversity also means attack surface multiplication, so it's a delicate tradeoff.
What alternatives are there? I honestly don't know
I have talked to security engineers that have had the company procure millions of dollars worth of security tools, and yet they don't even know the basics of security.
For God's sake, I had to explain what end-to-end-encryption was to a team of "senior" security engineers the other day. They genuinely had no concept of it. As a security SWE I am so done with these sort of people. Fuck them! Why are they even in security!? Real private data is at risk because of their incompetency!
It would be interesting to know Tanium takes to backport security fixes. I mean py2.7 was sunset 2020-01-01 [1].
[0] https://www.tanium.com/ [1] https://www.python.org/doc/sunset-python-2/
Same company had a head of security who was full-time employed by two different companies at the same time (he had unlimited vacation time for both) without either knowing the other existed.
Best thing was that the company did investment/insurance services and had a banking division.
When I was in college the whole student network went down. Apparently there was a hack from the student network to the campus police network, so campus IT pulled the plug on any of us having network access. Because those two weren't separated because why would they be?
So I hoofed it to the IT department and I asked to talk to someone who knows a thing or two about networking. The director of IT came out. He sat me down and started telling me about the $300,000 budget he just got approval on. I was thinking, you can't take some of that and stand up a router with packet filtering to isolate the student network from the police network in two different subnets? A FreeBSD box might do in a pinch. (It was the early 2000s and network traffic loads were... different.)
I learned a lesson that day about seniority and the Peter Principle. Climb high enough and your mindset changes, from technical solutions to issues of money and resource allocation. From there, "let's just pay $VENDOR to do it, they'll solve the problem for us" is but a small step.
0: https://twitter.com/BillDemirkapi/status/1506123471352438784
“Authentication services company Okta Inc said on Tuesday it is investigating a report of a digital breach after hackers posted screenshots of what they claimed were its internal company environment.”
I really don't see the problem with their response. What would you propose in the circumstances?
It's distinguishable from a noop because some information is imparted, namely that a) they are aware of the issue and b) that they have formed a preliminary view it warrants a response.
It’s perfectly okay to not say anything prematurely that can cause any confusion; with the employees, customers, and media.
All eyes are on them; it’s better not to screw up whatever little trust they have left.
(I'm aware he's often on here as well, hi eastdakota!)
It’s also very disappointing this is surfacing via tweets and not a breach notice from Okta, who apparently suspended at least one account used for entry.
Like I mentioned, it's sort of an "Armageddon", or worst case scenario. It's meant to help us identify issues with our docs, assist with order of operations, and it exposes any new hires to the full scope of all the moving pieces.
We already perform DR exercises, including testing our online backup restores, between production and DR sites, but this tabletop takes it further.
Hope that answers your question.
If your own company's RTO is 2w, that sounds like a lot needs to be in place. Part of the business continuity/ disaster recovery is getting management to sign off on those types of numbers, big or small. Make sure they're realistic.
You're right that this type of recovery is not fun. Bryan Cantrill gives a great presentation about managing an outage (https://www.youtube.com/watch?v=30jNsCVLpAE). One of my biggest takeaways, if you're looking at a sweeping outage and a long haul of a recovery, do sleep management asap with your team. Dead tired people are more likely to make brain dead decisions.
The lawyers might be sweating on their next round of bonuses, due to dealing with the fallout. But their jobs are not likely to be on the line.
When they always have a safe haven to run to and lay low in a comfortable way without significant losses (that aren't just cost of business), what good is such a slap?
In my mind I see it like the same as throwing a beer bottle at a robbers car as they drive away. Even if you hit it, at best it's some scratches or maybe a busted tail light, but they're still gone with your goods.
No secret or top secret info is permitted in the typical Impact Level 4 and Impact Level 5 FedRAMP systems. Okta is only certified at IL4 I think.
AWS & Azure do offer IL6, meaning information processed up to the SECRET classification.
Doubt it
> Can anyone who’s gotten a satisfactory answer to #Log4J #Log4Shell from @Okta raise their hand? We certainly haven’t. #rottenfishstinks
The news of the coming days may well prove me wrong, but i am not assuming the worst from this yet. Many companies whether or not they use an idaas do things like login anomalie detecting, and users coming in from weird locations and weird times of day would be sure to set of alarm bells at some of the big targets. Heck, AWS does it for customers with guard duty.
It seems strange that such a user would have wide access. It could be that his account was just used to gain further access, or it could be that his account had wide access by mistake. Or the user doesn't actually have that wide access.
There are talks about superuser access. But is that referring to the user's actual privileges or the fact that he has access to the tool called "superuser" shown in the screenshots?
I need more patience.
Because, technically speaking, Okta advertises with their SOC II / ISO27001 / ISO27017 / ISO27018 compliance certificates [1] and [2]; which means there has to be an incident response system that would've caught this. Well, either that, or the ones that manage the incident response system are the mischiefs themselves.
[1] https://trust.okta.com/compliance/ and https://archive.ph/654MX
[2] https://www.schellman.com/certificate-directory -> search for Certificate No. "1106074-8"
Like actually being told that as reason to use Microsoft AD. Or the nobody is better dealing with spam than Google (when I was at a G Suite company). Or never to roll your own security library.
All these were in the same ballpark and in some occasions the latter one was used to drive home the others.
I am not sure what to do/say about it.
I am not (by trade) an IT person but hopefully learned a bit in my time. Trying to understand how all the different tools on my corporate device work (together?) to enhance security is impossible to me. I can't name them but from anti virus, to compliance checking to additional compliance checking by VPN software to endpoint monitoring to remote install capabilities to windows management to remote desktop capabilities and many more.
To me this sounds like too many potential attack vectors waiting to be exploited.
Any URL *.okta.com resolves and loads an Okta login screen but doesn't mean it's an actual customer.
For example, https://fake-ycombinator.okta.com works and shows the same login screen as https://pets.okta.com/. But only the latter is on the list, how do you know it's a legitimate customer?
Can someone help me out then here? I checked the domain here: https://phonebook.cz/, but manually inspecting the certificate, I don't see the * in front of okta.com to denote a wildcard domain is in use(*.okta.com). What am I missing?
Does Gartner have any credibnility other than being a pay to be endorsed shill?
So, while I realize this is a small data point, it is one backed by quite a bit of data/analysis. Their report was well reasoned and accurate given the stated priors.
I would say that their credibility is fine so long as you read the reports fully and not simply glance at their magic quadrant figures.
seems like it'd be possible write an app that scans email history to detect services that have your data, scrape their websites to determine support email address(es), and send a GDPR data deletion request template to each of the selected ones.
> In late January 2022, Okta detected an attempt to compromise the account of a third party customer support engineer working for one of our subprocessors. The matter was investigated and contained by the subprocessor. (1 of 2)
> We believe the screenshots shared online are connected to this January event. Based on our investigation to date, there is no evidence of ongoing malicious activity beyond the activity detected in January. (2 of 2)
Regardless, their statement was a legal word-soup that bounced around the issue. The Lapsus$ team responded to it and said they could reset the passwords and MFA of over 95% of Okta customers which would mean they could get into any account, and thus any service, they wanted, though obviously they would be noticed pretty soon after.
This is both sides claiming things without any evidence, mind you, so take it with as many grains of salt as you need.
I had never heard of it.
It's an auth/ID service provider for many of the things I have heard about, I guess. For internal IT systems? Or for customer (public-facing) auth?
They have plenty of business customers using it for auth to their external public customers. You can see MGM resorts, Major League Baseball, Albertson's Groceries, etc, here:
I bet a lot of IntoSec departments are stressing right now because of this tweet.
WASHINGTON (Reuters) - Authentication services company Okta Inc said on Tuesday it is investigating a report of a digital breach after hackers posted screenshots of what they claimed were its internal company environment.
A hack at Okta could have potential major consequences because thousands of other companies rely on the San Francisco-based firm to manage access to their own networks and applications.
The screenshots were posted by a group of ransom-seeking hackers known as LAPSUS$ on their Telegram channel late on Monday.
> Authentication services company Okta Inc said on Tuesday
Where? What did they say? To who? The person writing the article?
WASHINGTON (Reuters) -Authentication services provider Okta Inc is investigating a report of a digital breach, the company said on Tuesday, after hackers posted screenshots showing what they claimed was its internal company environment.
A hack at Okta could have major consequences because thousands of other companies rely on the San Francisco-based firm to manage access to their own networks and applications.
The company was aware of the reports and was investigating, Okta official Chris Hollis said in a brief statement.
"We will provide updates as more information becomes available," he added.
The screenshots were posted by a group of ransom-seeking hackers known as LAPSUS$ on their Telegram channel late on Monday. In an accompanying message, the group said its focus was "ONLY on Okta customers."
Security experts told Reuters the screenshots appeared to be authentic.
"I definitely do believe it is credible," said independent security researcher Bill Demirkapi, citing pictures of what appeared to be Okta's internal tickets and its in-house chat on the Slack messaging app.
Dan Tentler, the founder of cybersecurity consultancy Phobos Group, said he too believed the breach was real and urged Okta customers to be "very vigilant right now."
In an email, Tentler added, "There are timestamps and dates visible in the screenshots indicating January 21st of this year, which suggests they may have had access for two months."
seems pretty easy to hack a SaaS anyway. just need to phish an engineering employee account. often they have superuser access to debug customer issues
> yes we know the URL has a email address. the account is suspended - we dont care
Not saying this looks good and really not trying to defend Okta, but a user account being terminated isn't proof that Okta knew about it.
There is a lot of conversation here about building your own vs using something 'centralized'. All software comes with the “build vs buy” tradeoff.
Our goal at SuperTokens is to minimise those tradeoffs and give you the best of both worlds. That is - The power of build and the speed of buy.
You can migrate to and from a completely self hosted solution to a managed service as your needs change
If some people are using it, I would enjoy their feedback.
My reasons for avoiding any online, managed by random company, type of service like this is for the risk of a single point of failure demonstrated in this attack.
262 points by jstanley 13 hours ago | flag | hide | 162 comments
11. Hackers claim to have breached Okta systems (twitter.com/_mg_)
824 points by obi1kenobi 9 hours ago | flag | hide | 280 comments
There is no way to justify this. This smells of yet another mass flagging by interested parties and/or their network of friends. Or something worse.
Typically with the aim of shifting power from one group to another.
The world isn't getting worse, we just hear a lot more about what's going on.
People are as selfish and power/money hungry as they've always been. Humans haven't changed, there's just a lot more of us each day.
We're a long way from global peace and economic and environmental harmony but I feel like there are a lot of people who want to try.
More people than ever before and with the Internet providing means of rapid, global communication and coordination those voices are reaching further.
If we can replace capitalism with something sustainable that brings peace and equality to all, perhaps then the world will start to be a better place (but will we ever rid ourselves of the selfishness that means some people want to be more equal than others).
Why are people Nittering something they can view from source. This is why propaganda is so easy, it's what people want.