Okta Security
Basiese Inligting
Okta, Inc. word erken in die identiteits- en toegangsbestuursektor vir sy wolkgebaseerde sagteware-oplossings. Hierdie oplossings is ontwerp om gebruikersverifikasie oor verskeie moderne toepassings te stroomlyn en te beveilig. Dit spreek nie net maatskappye aan wat hul sensitiewe data wil beskerm nie, maar ook ontwikkelaars wat belangstel om identiteitskontroles in te skakel in toepassings, webdiens, en toestelle.
Die vlagskipaanbod van Okta is die Okta Identity Cloud. Hierdie platform omvat 'n reeks produkte, insluitend maar nie beperk tot:
Enkelinvoer (SSO): Vereenvoudig gebruikerstoegang deur een stel aanmeldingsgelde oor verskeie toepassings toe te laat.
Meerfaktor-verifikasie (MFA): Verbeter sekuriteit deur die vereiste van meervoudige vorme van verifikasie.
Lewensiklusbestuur: Outomatiseer die prosesse vir die skep, opdateer, en deaktiveer van gebruikersrekeninge.
Universele Gids: Maak gesentraliseerde bestuur van gebruikers, groepe, en toestelle moontlik.
API-toegangsbestuur: Beveilig en bestuur toegang tot API's.
Hierdie dienste het gesamentlik ten doel om data beskerming te versterk en gebruikerstoegang 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. Vanaf die laaste opdatering in September 2021, word Okta erken as 'n prominente entiteit in die Identiteits- en Toegangsbestuursarena.
Die hoofdoel van Okta is om toegang tot verskillende gebruikers en groepe na eksterne toepassings te konfigureer. As jy daarin slaag om administrateursbevoegdhede in 'n Okta-omgewing te kompromitteer, sal jy waarskynlik in staat wees om alle ander platforms wat die maatskappy gebruik, te kompromitteer.
Om 'n sekuriteitsondersoek van 'n Okta-omgewing uit te voer, moet jy vra vir administrateur lees-slegs toegang.
Opsomming
Daar is gebruikers (wat in Okta gestoor kan word, aangemeld vanaf gekonfigureerde Identiteitsverskaffers of geauthentiseer via Active Directory of LDAP). Hierdie gebruikers kan binne groepe wees. Daar is ook verifikators: verskillende opsies vir verifikasie 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 koppeling met Okta hê om inligting te deel (soos e-posadresse, voornames...). Verder moet elke toepassing binne 'n Verifikasiebeleid wees, wat die benodigde verifikators vir 'n gebruiker om die toepassing te betree, aandui.
Die kragtigste rol is die Super-administrateur.
As 'n aanvaller Okta met Administrateurtoegang kompromitteer, sal al die toepassings wat op Okta vertrou, waarskynlik gekompromitteer word.
Aanvalle
Lokaliseer Okta-portaal
Gewoonlik sal die portaal van 'n maatskappy geleë wees op maatskappyname.okta.com. As nie, probeer eenvoudige variasies van maatskappyname. As jy dit nie kan vind nie, is dit ook moontlik dat die organisasie 'n CNAME-rekord het soos okta.maatskappyname.com wat na die Okta-portaal verwys.
Teken in by Okta via Kerberos
As maatskappyname.kerberos.okta.com aktief is, word Kerberos gebruik vir Okta-toegang, wat gewoonlik MFA vir Windows-gebruikers omseil. Om Kerberos-geautentiseerde Okta-gebruikers in AD te vind, hardloop getST.py met die toepaslike parameters. Na die verkryging van 'n AD-gebruikerstiket, inspuit 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 behoort 'n JSON "OK" terugvoer te gee, wat Kerberos-tiketaanvaarding aandui, en toegang tot die Okta-dashboard verleen.
Die kompromittering van die Okta-diensrekening met die delegasie SPN maak 'n Silver Ticket-aanval moontlik. Tog vereis Okta se gebruik van AES vir tiketversleuteling die besit van die AES-sleutel of platte wagwoord. Gebruik ticketer.py om 'n tiket vir die slagoffer-gebruiker te genereer en lewer dit via die webblaaier om met Okta te verifieer.
Kyk na die aanval in https://trustedsec.com/blog/okta-for-red-teamers.
Ontvoering van Okta AD-agent
Hierdie tegniek behels toegang tot die Okta AD-agent op 'n bediener, wat gebruikers sinchroniseer en verifikasie hanteer. Deur die ondersoek en dekripsie van konfigurasies in OktaAgentService.exe.config, veral die AgentToken met behulp van DPAPI, kan 'n aanvaller potensieel verifikasiedata onderskep en manipuleer. Dit maak nie net die monitoring en vaslegging van gebruikersgeloofsbriewe in platte teks tydens die Okta-verifikasieproses moontlik nie, maar ook die reageer op verifikasiepogings, wat ongemagtigde toegang moontlik maak of universele verifikasie deur Okta bied (soortgelyk aan 'n 'skelet-sleutel').
Kyk na die aanval in https://trustedsec.com/blog/okta-for-red-teamers.
Ontvoering van AD as 'n Admin
Hierdie tegniek behels die ontvoering van 'n Okta AD-agent deur eers 'n OAuth-kode te verkry, en dan 'n API-tiket aan te vra. Die tiket is geassosieer met 'n AD-domein, en 'n konnektor word genoem om 'n valse AD-agent te vestig. Inisialisering maak dit vir die agent moontlik om verifikasiepogings te verwerk, geloofsbriewe vas te vang via die Okta API. Outomatiseringstools 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.
Okta Valse SAML-verskaffer
Kyk na die aanval in https://trustedsec.com/blog/okta-for-red-teamers.
Die tegniek behels die implementering van 'n valse SAML-verskaffer. Deur 'n eksterne Identiteitsverskaffer (IdP) binne Okta se raamwerk te integreer met 'n bevoorregte rekening, kan aanvallers die IdP beheer, enige verifikasieversoek goedkeur. Die proses behels die opstel van 'n SAML 2.0 IdP in Okta, die manipulasie van die IdP Enkelinvoer-URL vir omleiding via 'n plaaslike gasheerlêer, die genereer van 'n selfondertekende sertifikaat, en die konfigurasie van Okta-instellings om ooreen te stem met die gebruikersnaam of e-pos. Suksesvolle uitvoering van hierdie stappe maak verifikasie as enige Okta-gebruiker moontlik, wat die behoefte aan individuele gebruikersgelde verbygaan, wat toegangsbeheer aansienlik verhoog op 'n potensieel onopgemerkte wyse.
Hengel Okta-portaal met Evilgnix
In hierdie blogpos word verduidelik hoe om 'n hengelveldtog teen 'n Okta-portaal voor te berei.
Kollega-impersonasie-aanval
Die eienskappe wat elke gebruiker kan hê en wysig (soos e-pos of voornaam) kan in Okta gekonfigureer word. As 'n toepassing 'n eienskap as ID vertrou wat die gebruiker kan wysig, sal hy in staat wees om ander gebruikers op daardie platform te impersoneer.
Daarom, as die toepassing die veld userName vertrou, sal jy waarskynlik nie in staat wees om dit te verander nie (omdat jy gewoonlik daardie veld nie kan verander nie), maar as dit byvoorbeeld primaryEmail vertrou, kan jy dit dalk verander na 'n kollega se e-posadres en dit impersoneer (jy sal toegang tot die e-pos moet hê en die verandering moet aanvaar).
Let daarop dat hierdie impersoantasie afhang van hoe elke toepassing gekonfigureer is. Slegs dié wat die veld vertrou wat jy gewysig het en opdaterings aanvaar, sal gekompromitteer word. Daarom moet die toepassing 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 (uiteindelik is verskillende toepassings verskillend gekonfigureer).
Die beste manier om uit te vind of jy enigiemand op elke toepassing kan impersoneer, is om dit te probeer!
Ontduiking van gedragsdeteksiebeleide
Gedragsdeteksiebeleide in Okta mag onbekend wees totdat dit ondervind word, maar dit kan omseil word deur Okta-toepassings direk te teiken, deur die hoof Okta-dashboard te vermy. Met 'n Okta-toegangstoken, speel die token af by die toepassing-spesifieke Okta-URL in plaas van die hoof aanmeldingsbladsy.
Belangrike aanbevelings sluit in:
Vermy die gebruik van gewilde anonimiseerproksi's en VPN-diens wanneer jy vasgelê toegangstokens herhaal.
Verseker konsekwente gebruikersagentstreke tussen die klient en herhaalde toegangstokens.
Hou op met die herhaal van tokens van verskillende gebruikers van dieselfde IP-adres.
Wees versigtig wanneer jy tokens teen die Okta-dashboard herhaal.
As jy bewus is van die slagoffermaatskappy se IP-adresse, beperk verkeer tot daardie IP's of hul reeks, blokkeer alle ander verkeer.
Okta-verharding
Okta het baie moontlike konfigurasies, op hierdie bladsy sal jy vind hoe om hulle te hersien sodat hulle so veilig as moontlik is:
pageOkta HardeningVerwysings
Last updated
