Okta Security
Last updated
Last updated
Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Okta, Inc. word erken in die identiteit en toegang bestuur sektor vir sy wolk-gebaseerde sagteware oplossings. Hierdie oplossings is ontwerp om gebruikersverifikasie oor verskeie moderne toepassings te stroomlyn en te beveilig. Hulle is nie net gerig op maatskappye wat hul sensitiewe data wil beskerm nie, maar ook op ontwikkelaars wat belangstel om identiteitsbeheer in toepassings, webdienste en toestelle te integreer.
Die vlaggies aanbod van Okta is die Okta Identity Cloud. Hierdie platform sluit 'n suite van produkte in, insluitend maar nie beperk tot nie:
Single Sign-On (SSO): Vereenvoudig gebruikers toegang deur een stel aanmeldbesonderhede oor verskeie toepassings toe te laat.
Multi-Factor Authentication (MFA): Versterk sekuriteit deur verskeie vorme van verifikasie te vereis.
Levensiklusbestuur: Automatiseer die skepping, opdatering en deaktivering van gebruikersrekeninge.
Universele Gids: Maak sentrale bestuur van gebruikers, groepe en toestelle moontlik.
API Toegang Bestuur: Beveilig en bestuur toegang tot API's.
Hierdie dienste het ten doel om dataprotectie te versterk en gebruikers toegang te stroomlyn, wat beide sekuriteit en gerief verbeter. Die veelsydigheid van Okta se oplossings maak dit 'n gewilde keuse oor verskeie bedrywe, voordelig vir groot ondernemings, klein maatskappye en individuele ontwikkelaars. Soos van die laaste opdatering in September 2021, word Okta erken as 'n prominente entiteit in die Identiteit en Toegang Bestuur (IAM) arena.
Die hoofdoel van Okta is om toegang tot verskillende gebruikers en groepe tot eksterne toepassings te konfigureer. As jy daarin slaag om administrateur regte in 'n Okta omgewing te kompromitteer, sal jy hoogs waarskynlik in staat wees om al die ander platforms wat die maatskappy gebruik te kompromitteer.
Om 'n sekuriteitsherziening van 'n Okta omgewing uit te voer, moet jy vra vir administrateur lees-slegs toegang.
Daar is gebruikers (wat kan wees gestoor in Okta, ingelogde van geconfigureerde Identiteitsverskaffers of geverifieer via Active Directory of LDAP). Hierdie gebruikers kan binne groepe wees. Daar is ook authenticators: verskillende opsies om te verifieer soos wagwoord, en verskeie 2FA soos WebAuthn, e-pos, telefoon, okta verify (hulle kan geaktiveer of gedeaktiveer wees)...
Dan is daar toepassings wat gesinkroniseer is met Okta. Elke toepassing sal 'n paar kaarte met Okta hê om inligting te deel (soos e-pos adresse, voorname...). Boonop moet elke toepassing binne 'n Verifikasiebeleid wees, wat die nodige authenticators aandui vir 'n gebruiker om toegang tot die toepassing te verkry.
Die mees kragtige rol is Super Administrator.
As 'n aanvaller Okta met Administrateur toegang kompromitteer, sal al die toepassings wat Okta vertrou hoogs waarskynlik gekompromitteer wees.
Gewoonlik sal die portaal van 'n maatskappy geleë wees in companyname.okta.com. As dit nie so is nie, probeer eenvoudige variaties van companyname. As jy dit nie kan vind nie, is dit ook moontlik dat die organisasie 'n CNAME rekord het soos okta.companyname.com wat na die Okta portaal wys.
As companyname.kerberos.okta.com aktief is, word Kerberos gebruik vir Okta toegang, wat tipies MFA vir Windows gebruikers omseil. Om Kerberos-geverifieerde Okta gebruikers in AD te vind, voer getST.py uit met geskikte parameters. Na die verkryging van 'n AD gebruikerskaart, injekteer dit in 'n beheerde gasheer met behulp van gereedskap soos Rubeus of Mimikatz, en verseker dat clientname.kerberos.okta.com in die Internet Opsies "Intranet" sone is. Toegang tot 'n spesifieke URL moet 'n JSON "OK" antwoord teruggee, wat die aanvaarding van die Kerberos kaart aandui, en toegang tot die Okta dashboard verleen.
Die kompromitering van die Okta diensrekening met die delegasie SPN stel 'n Silver Ticket aanval in staat. egter, Okta se gebruik van AES vir kaartversleuteling vereis dat die AES-sleutel of platte wagwoord besit word. Gebruik ticketer.py om 'n kaart vir die slagoffer gebruiker te genereer en lewer dit via die blaaier om met Okta te verifieer.
Kyk na die aanval in https://trustedsec.com/blog/okta-for-red-teamers.
Hierdie tegniek behels toegang tot die Okta AD Agent op 'n bediener, wat gebruikers sinkroniseer en verifikasie hanteer. Deur konfigurasies in OktaAgentService.exe.config te ondersoek en te ontsleutel, veral die AgentToken met behulp van DPAPI, kan 'n aanvaller potensieel verifikasiedata onderskep en manipuleer. Dit stel nie net in staat om te monitor en **gebruikers se akrediteer in platte teks tydens die Okta verifikasie proses te vang nie, maar ook om te reageer op verifikasie pogings, wat ongeoorloofde toegang moontlik maak of universele verifikasie deur Okta bied (soos 'n 'skelet sleutel').
Kyk na die aanval in https://trustedsec.com/blog/okta-for-red-teamers.
Hierdie tegniek behels die kaaping van 'n Okta AD Agent deur eers 'n OAuth Code te verkry, en dan 'n API token aan te vra. Die token is geassosieer met 'n AD domein, en 'n connector word genoem om 'n vals AD agent te vestig. Inisialiserings laat die agent toe om verifikasie pogings te verwerk, wat akrediteer vang via die Okta API. Outomatisering gereedskap is beskikbaar om hierdie proses te stroomlyn, wat 'n naatlose metode bied om verifikasiedata binne die Okta omgewing te onderskep en te hanteer.
Kyk na die aanval in https://trustedsec.com/blog/okta-for-red-teamers.
Kyk na die aanval in https://trustedsec.com/blog/okta-for-red-teamers.
Die tegniek behels die ontplooiing van 'n vals SAML verskaffer. Deur 'n eksterne Identiteitsverskaffer (IdP) binne Okta se raamwerk te integreer met behulp van 'n bevoorregte rekening, kan aanvallers die IdP beheer, enige verifikasie versoek na willekeur goedkeur. Die proses behels die opstelling van 'n SAML 2.0 IdP in Okta, die manipulasie van die IdP Single Sign-On URL vir herleiding via die plaaslike gashere lêer, die generering van 'n self-ondertekende sertifikaat, en die konfigurasie van Okta instellings om teen die gebruikersnaam of e-pos te pas. Die suksesvolle uitvoering van hierdie stappe stel in staat om as enige Okta gebruiker te verifieer, wat die behoefte aan individuele gebruikers akrediteer omseil, wat toegangbeheer in 'n potensieel onopgemerkte manier aansienlik verhoog.
In hierdie blogpos word verduidelik hoe om 'n phishing veldtog teen 'n Okta portaal voor te berei.
Die kenmerke wat elke gebruiker kan hê en wysig (soos e-pos of voornaam) kan in Okta geconfigureer word. As 'n toepassing vertrou as ID 'n kenmerk wat die gebruiker kan wysig, sal hy in staat wees om ander gebruikers in daardie platform na te boots.
Daarom, as die app die veld userName vertrou, sal jy waarskynlik nie in staat wees om dit te verander nie (omdat jy gewoonlik nie daardie veld kan verander nie), maar as dit vertrou vir byvoorbeeld primaryEmail kan jy dalk dit na 'n kollega se e-pos adres verander en dit na boots (jy sal toegang tot die e-pos moet hê en die verandering moet aanvaar).
Let daarop dat hierdie impersonasie afhang van hoe elke toepassing geconfigureer is. Slegs diegene wat die veld wat jy gewysig het vertrou en opdaterings aanvaar, sal gekompromitteer wees. Daarom moet die app hierdie veld geaktiveer hê as dit bestaan:
Ek het ook ander toepassings gesien wat kwesbaar was maar nie daardie veld in die Okta instellings gehad het nie (aan die einde is verskillende toepassings anders geconfigureer).
Die beste manier om uit te vind of jy iemand op elke app kan impersonate, sal wees om dit te probeer!
Gedragsdeteksiebeleide in Okta mag onbekend wees totdat dit teëgekom word, maar omseiling daarvan kan bereik word deur direk op Okta toepassings te teiken, en die hoof Okta dashboard te vermy. Met 'n Okta toegangstoken, herhaal die token by die toepassing-spesifieke Okta URL in plaas van die hoof aanmeldblad.
Belangrike aanbevelings sluit in:
Vermy die gebruik van gewilde anonymiseringsproxies en VPN-dienste wanneer jy gevangen toegangstokens herhaal.
Verseker konstante gebruikers-agent strings tussen die kliënt en herhaalde toegangstokens.
Vermy die herhaling van tokens van verskillende gebruikers vanaf dieselfde IP-adres.
Wees versigtig wanneer jy tokens teen die Okta dashboard herhaal.
As jy bewus is van die slagoffer maatskappy se IP-adresse, beperk verkeer na daardie IP's of hul reeks, en blokkeer alle ander verkeer.
Okta het baie moontlike konfigurasies, op hierdie bladsy sal jy vind hoe om dit te hersien sodat dit so veilig as moontlik is:
Okta HardeningLeer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
