Okta Security
Last updated
Last updated
Impara e pratica il Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica il Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Okta, Inc. è riconosciuta nel settore della gestione dell'identità e degli accessi per le sue soluzioni software basate sul cloud. Queste soluzioni sono progettate per semplificare e garantire l'autenticazione degli utenti attraverso varie applicazioni moderne. Si rivolgono non solo alle aziende che mirano a proteggere i propri dati sensibili, ma anche agli sviluppatori interessati a integrare controlli di identità nelle applicazioni, nei servizi web e nei dispositivi.
L'offerta principale di Okta è il Okta Identity Cloud. Questa piattaforma comprende una suite di prodotti, tra cui ma non solo:
Single Sign-On (SSO): Semplifica l'accesso degli utenti consentendo un unico set di credenziali di accesso attraverso più applicazioni.
Multi-Factor Authentication (MFA): Migliora la sicurezza richiedendo più forme di verifica.
Lifecycle Management: Automatizza i processi di creazione, aggiornamento e disattivazione degli account utente.
Universal Directory: Consente la gestione centralizzata di utenti, gruppi e dispositivi.
API Access Management: Sicurezza e gestione dell'accesso alle API.
Questi servizi mirano collettivamente a rafforzare la protezione dei dati e semplificare l'accesso degli utenti, migliorando sia la sicurezza che la comodità. La versatilità delle soluzioni di Okta le rende una scelta popolare in vari settori, utile per grandi imprese, piccole aziende e sviluppatori individuali. A partire dall'ultimo aggiornamento nel settembre 2021, Okta è riconosciuta come un'entità prominente nel campo della gestione dell'identità e degli accessi (IAM).
L'obiettivo principale di Okta è configurare l'accesso a diversi utenti e gruppi per applicazioni esterne. Se riesci a compromettere i privilegi di amministratore in un ambiente Okta, sarà molto probabile che tu possa compromettere tutte le altre piattaforme utilizzate dall'azienda.
Per eseguire una revisione della sicurezza di un ambiente Okta, dovresti richiedere accesso in sola lettura per amministratori.
Ci sono utenti (che possono essere memorizzati in Okta, autenticati da Identity Providers configurati o autenticati tramite Active Directory o LDAP). Questi utenti possono essere all'interno di gruppi. Ci sono anche autenticatori: diverse opzioni per autenticarsi come password e vari 2FA come WebAuthn, email, telefono, okta verify (possono essere abilitati o disabilitati)...
Poi, ci sono applicazioni sincronizzate con Okta. Ogni applicazione avrà una certa mappatura con Okta per condividere informazioni (come indirizzi email, nomi...). Inoltre, ogni applicazione deve essere all'interno di una Authentication Policy, che indica gli autenticatori necessari per un utente per accedere all'applicazione.
Il ruolo più potente è Super Administrator.
Se un attaccante compromette Okta con accesso da amministratore, tutte le app che si fidano di Okta saranno molto probabilmente compromesse.
Di solito il portale di un'azienda sarà situato in companyname.okta.com. Se non lo trovi, prova semplici variazioni di companyname. Se non riesci a trovarlo, è anche possibile che l'organizzazione abbia un record CNAME come okta.companyname.com che punta al portale Okta.
Se companyname.kerberos.okta.com è attivo, Kerberos è utilizzato per l'accesso a Okta, bypassando tipicamente MFA per gli utenti Windows. Per trovare gli utenti Okta autenticati tramite Kerberos in AD, esegui getST.py con parametri appropriati. Dopo aver ottenuto un ticket utente AD, inietta il ticket in un host controllato utilizzando strumenti come Rubeus o Mimikatz, assicurandoti che clientname.kerberos.okta.com sia nella zona "Intranet" delle Opzioni Internet. Accedere a un URL specifico dovrebbe restituire una risposta JSON "OK", indicando l'accettazione del ticket Kerberos e concedendo accesso al dashboard di Okta.
Compromettere l'account di servizio Okta con il delegato SPN consente un attacco Silver Ticket. Tuttavia, l'uso di AES da parte di Okta per la crittografia dei ticket richiede di possedere la chiave AES o la password in chiaro. Usa ticketer.py per generare un ticket per l'utente vittima e consegnalo tramite il browser per autenticarti con Okta.
Controlla l'attacco in https://trustedsec.com/blog/okta-for-red-teamers.
Questa tecnica implica accedere all'Okta AD Agent su un server, che sincronizza gli utenti e gestisce l'autenticazione. Esaminando e decrittografando le configurazioni in OktaAgentService.exe.config, in particolare l'AgentToken utilizzando DPAPI, un attaccante può potenzialmente intercettare e manipolare i dati di autenticazione. Questo consente non solo di monitorare e catturare le credenziali degli utenti in chiaro durante il processo di autenticazione di Okta, ma anche di rispondere ai tentativi di autenticazione, consentendo così accessi non autorizzati o fornendo autenticazione universale tramite Okta (simile a una 'chiave scheletro').
Controlla l'attacco in https://trustedsec.com/blog/okta-for-red-teamers.
Questa tecnica implica l'hijacking di un Okta AD Agent ottenendo prima un OAuth Code, quindi richiedendo un token API. Il token è associato a un dominio AD, e un connettore è nominato per stabilire un agente AD falso. L'inizializzazione consente all'agente di elaborare i tentativi di autenticazione, catturando le credenziali tramite l'API di Okta. Sono disponibili strumenti di automazione per semplificare questo processo, offrendo un metodo fluido per intercettare e gestire i dati di autenticazione all'interno dell'ambiente Okta.
Controlla l'attacco in https://trustedsec.com/blog/okta-for-red-teamers.
Controlla l'attacco in https://trustedsec.com/blog/okta-for-red-teamers.
La tecnica implica implementare un fornitore SAML falso. Integrando un Identity Provider (IdP) esterno all'interno del framework di Okta utilizzando un account privilegiato, gli attaccanti possono controllare l'IdP, approvando qualsiasi richiesta di autenticazione a piacimento. Il processo comporta la configurazione di un IdP SAML 2.0 in Okta, manipolando l'URL di Single Sign-On dell'IdP per la reindirizzazione tramite il file hosts locale, generando un certificato autofirmato e configurando le impostazioni di Okta per corrispondere al nome utente o all'email. Eseguire con successo questi passaggi consente di autenticarsi come qualsiasi utente Okta, bypassando la necessità di credenziali individuali, elevando significativamente il controllo degli accessi in modo potenzialmente inosservato.
In questo post del blog viene spiegato come preparare una campagna di phishing contro un portale Okta.
Gli attributi che ogni utente può avere e modificare (come email o nome) possono essere configurati in Okta. Se un applicazione si fida di un attributo che l'utente può modificare, sarà in grado di impersonare altri utenti in quella piattaforma.
Pertanto, se l'app si fida del campo userName, probabilmente non sarai in grado di cambiarlo (perché di solito non puoi cambiare quel campo), ma se si fida ad esempio di primaryEmail potresti essere in grado di cambiarlo con l'indirizzo email di un collega e impersonarlo (dovrai avere accesso all'email e accettare la modifica).
Nota che questa impersonificazione dipende da come è stata configurata ciascuna applicazione. Solo quelle che si fidano del campo che hai modificato e accettano aggiornamenti saranno compromesse. Pertanto, l'app dovrebbe avere questo campo abilitato se esiste:
Ho anche visto altre app che erano vulnerabili ma non avevano quel campo nelle impostazioni di Okta (alla fine diverse app sono configurate in modo diverso).
Il modo migliore per scoprire se puoi impersonare qualcuno su ciascuna app sarebbe provarlo!
Le politiche di rilevamento comportamentale in Okta potrebbero essere sconosciute fino a quando non vengono incontrate, ma bypassarle può essere ottenuto mirando direttamente alle applicazioni Okta, evitando il dashboard principale di Okta. Con un token di accesso Okta, riproduci il token all'URL specifico dell'applicazione Okta invece della pagina di accesso principale.
Le raccomandazioni chiave includono:
Evita di utilizzare proxy di anonimizzazione popolari e servizi VPN quando riproduci token di accesso catturati.
Assicurati che ci siano stringhe user-agent coerenti tra il client e i token di accesso riprodotti.
Evita di riprodurre token di utenti diversi dallo stesso indirizzo IP.
Fai attenzione quando riproduci token contro il dashboard di Okta.
Se sei a conoscenza degli indirizzi IP dell'azienda vittima, limita il traffico a quegli IP o al loro intervallo, bloccando tutto il resto del traffico.
Okta ha molte configurazioni possibili, in questa pagina troverai come rivederle affinché siano il più sicure possibile:
Impara e pratica il Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica il Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
