1Password ontdekt 'verdachte activiteit' op Okta-account na hack bij Okta

Wachtwoordmanager 1Password zegt 'verdachte activiteit' te hebben opgemerkt op zijn interne Okta-account. Volgens onderzoek van het bedrijf lijken daarbij geen gebruikersgegevens te zijn gestolen. Okta maakte vrijdag melding van een datalek in zijn supportsystemen.

"Op 29 september ontdekten we verdachte activiteit op onze Okta-instance, die we gebruiken om onze apps voor werknemers te beheren", schrijft 1Password-cto Pedro Canahuati. "We hebben de activiteit onmiddellijk beëindigd, onderzocht en geen compromittering van gebruikersgegevens of andere gevoelige systemen gevonden."

1Password zegt samen met Okta, een provider van authenticatiemanagementsoftware, naar de oorzaak van het lek te hebben gezocht. Vorige week vrijdag werd daarbij geconcludeerd dat dit het resultaat was van een hack bij Okta, waarbij hackers toegang kregen tot de supportsystemen van die provider. De hackers kregen toegang tot de Okta-instance van 1Password met adminprivileges, blijkt uit een rapport van 1Password.

Hackers kregen toegang tot het Okta-account van 1Password via een HAR-bestand. Een medewerker van 1Password maakte een dergelijk bestand op verzoek van de Okta-klantenservice. Het bestand bevatte 'al het verkeer' tussen de browser van de medewerker en de Okta-servers, waaronder sessioncookies. Een van die cookies werd gebruikt door hackers om toegang te krijgen tot het Okta-adminportaal van 1Password. Okta erkende vorige week dat onbevoegden toegang kregen tot 'sommige bestanden' die klanten hebben geüpload naar de servers van Okta.

"Op basis van onze eerste beoordeling hebben we geen bewijs dat laat zien dat de threatactor toegang heeft gehad tot systemen buiten Okta", schrijft 1Password. De hackers zouden in eerste instantie 'verkennend' te werk zijn gegaan, met het doel om onopgemerkt te blijven en informatie te verzamelen voor een grotere, geavanceerdere aanval.

De hackers probeerden verschillende acties uit te voeren op het Okta-account van 1Password. Zij probeerden bijvoorbeeld het userdashboard van 1Passwords IT-medewerkers te benaderen, maar dit werd geblokkeerd door Okta. Er werd ook een update doorgevoerd bij een andere identiteitsprovider, die 1Password gebruikt voor zijn Google-omgeving, waarna geprobeerd werd deze te gebruiken. De threatactor vroeg ook een overzicht van admingebruikers van 1Password op bij Okta. Na die laatste actie werd een e-mail gestuurd naar een IT-medewerker van 1Password, waarna het securityteam van de wachtwoordmanager op de hoogte werd gesteld en de hackpoging werd opgemerkt.

Reacties (51)

[tja]

slecht dat ze zo lang hebben gewacht met informeren.

[Cergorach]

Wat hadden ze dan exact eerder moeten melden? Het kan wel even duren voordat een bedrijf dat servers over de hele wereld heeft staan alles heeft gecontroleerd. Als je iets vind kan je direct zeggen: "Gevonden!", als je niets vind ga je verder zoeken...

En in dit specifieke geval kwam Okta pas op 21 oktober (vrijdag) met een officiële statement dat het issue bij hun lag en niet bij 1Password, de statement van 1Password is van 23 oktober (maandag). Dus zo vreemd is het allemaal niet, want men wist pas zeker vrijdag dat dit issue bij Okta lag en niet begonnen is binnen het 1Password netwerk. Wat belangrijk is voor de evaluatie van je eigen security.

Addendum
Oct 21, 2023: Okta confirmed publicly that their internal support systems were compromised.
This answers how the HAR file was accessed by the attacker and that the initial compromise
was not through the employee’s laptop

[michelr]

Exact dit. Roepen dat er iets aan de hand is direct gevolgen heeft voor het imago als niet aantoonbaar de oorzaak niet bij jou ligt. Daar is onderzoek voor nodig en dat kost tijd.

[HADES2001]

Als een bedrijf een pers bericht er uit moet sturen als ze 1 dingetje raar zien in hun logs dan mag elk bedrijf er wel 10 media mensen bij aannemen.
Eerst gedegen onderzoek doen en bevestigen dat het geen false positive is, dan onderzoeken wat er is gebeurt en hoe het geeft kunnen gebeuren, Vervolgens dicht je het probleem en dan kom je naar buiten met informatie en een pers bericht.
Geen slapende honden wakker maken want ook de hackers lezen het nieuws, als die zien dat ze op het punt staan gepakt te worden en zitten echt binnen kunnen ze nog snel schade aanrichten of alle logs verwijderen zodat onderzoek lastiger word.

[cricque]

Correct, tevens hebben de meeste ook geen tijd en personeel om constant logs liggen na te pluizen. Tevens is er dan zo een vervelend probleem met privacy en gdpr ... Want ja je mag bijna niks bijhouden, met als gevolg dat je dus geen maanden logs gaat bijhouden. Maanden logs kost ook veel geld. En nee zelfs in grote bedrijven hebben ze geen maanden logs.
Maar bij grote bedrijven hebben ze wel meestal een security team zitten, maar in de gemiddelde kmo alvast niet.

[Hann1BaL]

Niet zo mee eens, omdat ze wel eerst goed de tijd moeten hebben om na te gaan of er niet meer aan de hand is. Waar toegang tot verkregen is en dat kost echt wel tijd. Ik vind dit dus niet zo lang.

[bhartman]

Daar denkt Cloudflare toch echt anders over: https://blog.cloudflare.c...-another-okta-compromise/

Take any report of compromise seriously and act immediately to limit damage; in this case Okta was first notified on October 2, 2023 by BeyondTrust but the attacker still had access to their support systems at least until October 18, 2023.

[Reactie gewijzigd door bhartman op 25 juli 2024 01:46]

[Ireyon]

Is, met wat hier gebeurd is in gedachte, nu te concluderen dat cookies de nieuwe aanvalsvector is voor hackers? Het traditionele gebruikersnaam en wachtwoord ontfutselen via brute force, social engineering of andere methodes is nu niet meer in trek?

Wat kun je doen om te voorkomen dat iemand je sessiedata steelt en op deze manier 2FA kan omzeilen?

[latka]

In 2007 hadden we al interne regels voor app. development die voorschreven dat je geen cookies mocht zetten: dat was voorbehouden aan de infrastructuur. Dit omdat cookies/sessies echt heel gevoelig zijn en niet iedereen kan overzien wat een 'goede' cookie is en het eenvoudig is maar een beperkt aantal cookie generatoren te bewaken/aan te passen ipv. iedere applicatie continue monitoren op correct en veilig inzetten van cookies.

[Cergorach]

Is, met wat hier gebeurd is in gedachte, nu te concluderen dat cookies de nieuwe aanvalsvector is voor hackers?

De tokens, waar we het hier over hebben zijn geen cookies, daar zit een verschil in:
https://www.linkedin.com/...okies-sessions-tokens-web

Die tokens zijn echter nog steeds te stelen, door op het device zelf ze te gaan halen of er tussen te gaan zitten (AitM). Dit speelt al langer en was best een enorm issue want je kan er vrij weinig tegen doen zonder massive changes aan je infra en dat is lastig bij grote organisaties. Vanuit de M365 vind ik dit een erg goed artikel wat ook je exact laat zien hoe zo een AitM werkt:
https://jeffreyappel.nl/a...oft-protections-2023-edt/

[Tomino]

Zeker. Impersonification as a service

https://www.theverge.com/...o-factor-passwords-how-to

[DVBNL]

Zelf gebruik ik voor alle accounts met high impact een Yubikey.

[SniperEye]

Op donderdag 21 september kreeg ik rond 14:00 uur een automatische mail dat er met Safari was ingelogd op mijn 1Password terwijl ik op dat moment een ijssalon binnenliep.

Ik heb hen direct gecontacteerd. Ik zag geen afwijkingen van devices in mijn profiel. Het wachtwoord is ook uniek en durf wel te stellen onkraakbaar. Er was alleen een IPv6 vermeld in de mail. Ik kon niet achterhalen of die voor mij bekend was. Ik vroeg dus of zij het MAC-adres loggen bij het inloggen. Dat was makkelijker. Dan kon ik achterhalen of dat deze inlogpoging op mijn iPhone of iPad was gedaan.

Dit was hun reactie:

Thanks for reaching out! Rather than any sort of compromise, it's highly likely that you received this notification because of our browser extension's background activity, which can cause these extraneous notifications to be sent out.

Additionally, if you don't sign into 1Password in Safari for about a week and then sign back in (or you manually clear your history/browser data in any browser), this will also likely cause a new sign-in notification to be sent out.

Lastly, we don't log a device's MAC address. For sign-ins on our website, the main things we keep track of include browser that was used, the public IP address, and the user agent of the browser. This typically reveals the operating system it was running on, along with the browsers version number. For this reason, there isn't any particularly useful information we can share with you.

I hope this helps! That being said, should you need anything else or have any questions, please don't hesitate to reach back out.

[Sebazzz]

Ik vroeg dus of zij het MAC-adres loggen bij het inloggen. Dat was makkelijker.

Je MAC adres bestaat niet buiten je huidige netwerk. Online 1Password kan dat dus niet zien.

[nl-x]

De client zelf zou dat kunnen loggen en doorgeven.

[Sebazzz]

Dit was (1) op Safari, een webbrowser weet het MAC-adres niet, (2) de client vertrouwen is hoe je gehackt wordt.

[Verwijderd]

Sebazzz schreef:

Dit was (1) op Safari, een webbrowser weet het MAC-adres niet, (2) de client vertrouwen is hoe je gehackt wordt.

Precies vanwege dat laatste heb je ook geen zekerheid dat de aanvaller daadwerkelijk gebruikmaakte van Safari; het kan om andere software gaan die zich voordoet als Safari.

Als @SniperEye geen Safari gebruikt (in elk geval niet kort voorafgaand en tijdens het incident) is dit wel een extra aanwijzing van "foute boel", en dat lijkt mij voldoende reden om ook een "onkraakbaar" wachtwoord te wijzigen (want aan "onkraakbaar" heb je niets als een aanvaller dat wachtwoord ook kent).

Het is ook verstandig om te checken of er geen alternatieve inlogmethode is toegevoegd (zoals een passkey).

[Reactie gewijzigd door Verwijderd op 25 juli 2024 01:46]

[SniperEye]

Wat is kort? Ergens in de 30 minuten voorafgaand wel. Maar goed, blijft heel raar.

[Verwijderd]

SniperEye schreef:

Wat is kort? Ergens in de 30 minuten voorafgaand wel. Maar goed, blijft heel raar.

Als dat daadwerkelijk met Safari was, is het denkbaar dat er bij 1Password een klok niet op tijd loopt of dat er om een andere reden een vertraging is ontstaan (uitermate slordig natuurlijk).

Pure speculatie (misschien zet het je op een spoor): als je een iPhone gebruikt en Safari niet echt gesloten had, is het ook denkbaar dat Safari opnieuw verbinding probeerde te maken en dat dit bij de ijssalon via 4G/5G (i.p.v. jouw thuis- of werk-WiFi) gebeurde - met een nu voor 1Password onbekend IP-adres.

[nl-x]

Er is niks mis met het loggen van client gegevens. Dat je het logt betekent niet dat je het moet vertrouwen. Wij loggen steevast ook headergegevens zoals user-agent en x-forwarded-for. Totaal niet te vertrouwen, maar wel het loggen waard.

[Reactie gewijzigd door nl-x op 25 juli 2024 01:46]

[mfkne]

geen compromittering van gebruikersgegevens of andere gevoelige systemen gevonden

betekent helaas niet "er heeft geen compromittering plaatsgevonden".

[AverageNL]

Inderdaad, op basis van een eerste onderzoeken is er geen bewijs gevonden. Ik pas de titel iets aan

[Pim0377]

De hackers zouden in eerste instantie 'verkennend' te werk zijn gegaan, met het doel om onopgemerkt te blijven en informatie te verzamelen voor een grotere, geavanceerdere aanval.

Met het doel om onopgemerkt te blijven? En dat doe je dan door een overzicht op te vragen van alle admingebruikers van 1Password? Klinkt meer als een "we laten hier en daar wat belletjes rinkelen, kijken of er iemand / het systeem, op zit te letten en er melding van maakt"

Maar goed om te lezen dat het vrij snel is opgemerkt en gestopt. Ik neem aan dat ze de systemen voorlopig nog even extra in de gaten houden en alle gerelateerde zaken zullen napluizen.

[Reactie gewijzigd door Pim0377 op 25 juli 2024 01:46]

[djiwie]

Niet alleen 1Password, ook Cloudflare heeft (eerder dan Okta!) verdachte activiteit ontdekt: https://blog.cloudflare.c...-another-okta-compromise/

Bizar dat Okta zelf zo lang heeft gewacht met iets melden en lange tijd niets doorhad.

[Byron010]

Okta (en zijn/haar klanten) heeft het lastig de laatste tijd..

Vorig jaar zowel gehackt als de broncode gestolen en nu weer een incident
nieuws: Vijf vragen over de hack op Okta en de mysterieuze Lapsus$-hackergroep
nieuws: Okta erkent dat klanten zijn getroffen door aanval van Lapsus$
nieuws: Hackers stelen broncode van Okta via GitHub-repository's

Edit:
Nou ben je als login provider natuurlijk ook een super interessant doelwit voor hackers

[Reactie gewijzigd door Byron010 op 25 juli 2024 01:46]

[JulianvDijk]

Ik denk dan ook dat een login provider er van uit moet gaan dat gehackt worden sowieso een keer gaat gebeuren. Ik ben dan ook veel meer geïnteresseerd in de aanpak van zo'n provider wanneer zoiets gebeurd. Dat bericht van de ING over dat derden op een account van een ander konden was schokkend, maar dat ze het slachtoffer niet geïnformeerd hadden was nog schokkender. Het lijkt erop dat ze het hier heel netjes hebben aangepakt en uitgezocht.

[willieverhoef]

Waarschijnlijk hadden en hebben ze nog steeds geen idee of het bij deze 5 mensen is gebleven of wie het waren. En vonden ze het gewoon niet nodig om iedereen te informeren. Want dat zou onrust geven.
Maar in ieder geval zeker niet juist.

[Cergorach]

Hoe bedoel je de 'laatste tijd'? Je bedoeld de afgelopen drie jaar? Het gelazer begon al in maart 2021 met de Verkada (video camera) hack...

[MGutker]

Hacks zoals deze, bij grote "security" georienteerde bedrijven doen mij altijd afvragen: Waarom hoor je nooit over zo'n gebeurtenis bij Gooigle, etc? Gebeurt het gewoon niet? Of word het allemaal onder een mat geveegd?

[Johan9711]

Waarom niet? Eigenlijk is dat wel hun branche. Ze doem aan identity en access management software, dat is toch echt wel security...

[Herko_ter_Horst]

Check, niet goed gelezen, ik dacht dat het over een customer support aanbieder ging.

[latka]

Tsja, bij de timmerman thuis lekt het dak. In mijn ogen is Okta vooral een marketing machine die roept dat ze het regelen. Een beetje zoals Diginotar: ja, het is een certificaat uitgevende instantie op papier, maar in de praktijk is het een gatenkaas.

[PLeX]

Ik denk dat MGutker probeert te zeggen dat security van wezenlijk belang is bij een IDP zoals Okta. Dat je binnen je dienstverlening als Identity Provider security als Prio #1 hebt lijkt me vanzelfsprekend.

[latka]

Lol. Kijk nog even naar Diginotar.

[PLeX]

Ik begrijp je reactie, en mijn "vanzelfsprekendheid" is in die zin allicht overdreven, maar ten tijde van de overname door Vasco een hack op een 26 koppen tellend bedrijf vergelijken met een hack op een 5000+ employees hebbende "global" identity provider, als ook iets van 12 jaar vergelijken met iets van nu, zit toch nog wel een hele grote nuance in.

[latka]

In mijn ogen niet: security is altijd een kostenpost en totdat het misgaat bij een bedrijf is het 'kosten maken om een mogelijk risico te vermijden'. Dat vliegt zelfs bij een bedrijf dat zichzelf IdP noemt niet. Juist met 5k+ employees is security een illusie (een gebruiker die verkeerd klikt en er zit iets op je interne netwerk). In 2000 stuurde MS alle devs 1 week op security cursus omdat het aantal bugs in Win2k zo groot werd. Afgelopen patch tuesday: 103 bugs die snel geplet moeten worden en een deel al actief misbruikt werd. Het is naïef om te denken dat Okta het beter kan dan een bedrijf als MS die het al 20+ jaar niet lukt.

Centraliseren van security (okta/azure etc.) betekent vooral: handig voor hackers. Vanuit security oogpunt is het discutabel.

[livePulse]

Is een hacker iets anders dan een threatactor?

[Cergorach]

Nuance verschillen:

The terms threat actor, hacker and cybercriminal are often used interchangeably, especially in Hollywood and popular culture. But there are subtle differences in the meanings of each and their relationship to each other.

Not all threat actors or cybercriminals are hackers. By definition, a hacker is someone with the technical skills to compromise a network or computer system. But some threat actors or cybercriminals don’t do anything more technical then leave an infected USB drive for someone to find and use, or send an email with a malware attached.

Not all hackers are threat actors or cybercriminals. For example, some hackers—called ethical hackers—essentially impersonate cybercriminals help organizations and government agencies test their computer systems for vulnerability to cyberthreats.

Certain types of threat actors aren’t cybercriminals by definition or intent, but are in practice. For example, a thrill seeker who is ‘just having fun’ by shutting down a town’s electrical grid for a few minutes, or a hacktivist who exfiltrates and publishes confidential government information in the name of a noble cause, may also be committing a cybercrime, whether or not they intend to or believe they are.

Bron:
https://www.ibm.com/topics/threat-actor

[livePulse]

Duidelijk, bedankt! Ik kon zelf zo snel iets niet vinden dat zo specifiek was.

[Tomino]

Met veel of weinig uitleg en verklaringen van 1Password zelf of andere websites krijg ik toch een onbehaaglijk gevoel. Met name omdat de 2FA codes tegenwoordig ook in de app aangemaakt worden. Mogelijk toch slim om een aparte authenticator te gebruiken..

[MiNDiT]

Ja dat kan je beter gescheiden houden idd, het liefst offline

[Forte]

Heb er zelf bewust voor gekozen om 2FA codes in een aparte authenticator app te blijven gebruiken. Als je én je passwords én je 2FA codes in één app gaat zetten dan gaat die extra beveiliging die het toe zou moeten voegen er een beetje van af naar mijn idee. Plus nu heb je echt mijn smartphone nodig als extra fysieke horde, via de 1Password app zou je ook 2FA codes op de laptop kunnen genereren.

[Niemand_Anders]

Als je 2FA codes op dezelfde plek bevinden als de credentials bevinden beide zich op dezelfde plek en heeft 2FA minder toegevoegde waarde. Je zilt juist kennis (password) en bezit (OTP generator) gescheiden houden. Maar zelfs als je de OTP tokens in je password manager staan, zijn je accounts nog steeds beter beveiligd dan als je geen 2FA gebruikt.

Echter zodra je kluis uitlekt, heb je wel een probleem.
Maar veiligheid en gemak is en zal altijd een lastige balans blijven...

[Cergorach]

2FA/MFA is ook niet meer zo heilig als eerst gedacht, het is een extra toevoeging, maar zodra iemand je token te pakken heeft kan deze aanmelden zonder ww of 2FA/MFA (totdat die token verloopt). En daar hoeft men echt niet je PC voor te hacken, via attacker-in-the-middle kan men ook de tokens verkrijgen. Daar is eigenlijk niet tegen te beschermen (met alleen ww+2FA/MFA), alleen op in te grijpen als het gebeurd... Je zal dan ook eerder moeten kijken naar FIDO2 (Windows Hello for Business of certificates).

Dat gezegd hebbende, ik heb sinds kort ook 1Password en hou voorlopig ook mijn MFA gescheiden, zal wel moeten, want sommige diensten hebben heel specifieke eisen qua app. Maar zelfs dan... Ik ben begonnen met me oriënteren op de 'juiste' FIDO2 oplossing...

Je restore codes voor 2FA/MFA zou je wellicht ook beter offline kunnen bewaren.

[flaskk]

Ik vind het wel een beetje ingedekte reactie, hoogstwaarschijnlijk is er niks aan de hand. move along peope!