Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Dal punto di vista di un attaccante, questo è super interessante poiché sarai in grado di vedere tutti gli utenti registrati, i loro indirizzi email, i gruppi di cui fanno parte, i profili e persino i dispositivi (mobile insieme ai loro OS).
Per una revisione whitebox controlla che non ci siano più di "Azione utente in sospeso" e "Reimpostazione password".
Qui puoi trovare tutti i gruppi creati in Okta. È interessante comprendere i diversi gruppi (insieme di permessi) che potrebbero essere concessi agli utenti. È possibile vedere le persone incluse nei gruppi e le app assegnate a ciascun gruppo.
Ovviamente, qualsiasi gruppo con il nome di admin è interessante, specialmente il gruppo Global Administrators, controlla i membri per scoprire chi sono i membri più privilegiati.
Da una revisione whitebox, non dovrebbero esserci più di 5 global admins (meglio se ce ne sono solo 2 o 3).
Trova qui un elenco di tutti i dispositivi di tutti gli utenti. Puoi anche vedere se è gestito attivamente o meno.
Qui è possibile osservare come informazioni chiave come nomi, cognomi, email, nomi utente... sono condivisi tra Okta e altre applicazioni. Questo è interessante perché se un utente può modificare in Okta un campo (come il suo nome o email) che poi è utilizzato da un applicazione esterna per identificare l'utente, un insider potrebbe cercare di prendere il controllo di altri account.
Inoltre, nel profilo User (default) di Okta puoi vedere quali campi ciascun utente ha e quali sono scrivibili dagli utenti. Se non riesci a vedere il pannello di amministrazione, vai semplicemente a aggiornare le informazioni del tuo profilo e vedrai quali campi puoi aggiornare (nota che per aggiornare un indirizzo email dovrai verificarlo).
Le directory ti consentono di importare persone da fonti esistenti. Immagino che qui vedrai gli utenti importati da altre directory.
Non l'ho visto, ma immagino che sia interessante scoprire altre directory che Okta sta utilizzando per importare utenti così se comprometti quella directory potresti impostare alcuni valori di attributi negli utenti creati in Okta e forse compromettere l'ambiente Okta.
Una fonte di profilo è un applicazione che funge da fonte di verità per gli attributi del profilo utente. Un utente può essere sorgente solo da un'applicazione o directory alla volta.
Non l'ho visto, quindi qualsiasi informazione sulla sicurezza e hacking riguardo a questa opzione è apprezzata.
Controlla nella scheda Domains di questa sezione gli indirizzi email utilizzati per inviare email e il dominio personalizzato all'interno di Okta dell'azienda (che probabilmente già conosci).
Inoltre, nella scheda Setting, se sei un admin, puoi "Usare una pagina di disconnessione personalizzata" e impostare un URL personalizzato.
Niente di interessante qui.
Puoi trovare qui le applicazioni configurate, ma vedremo i dettagli di quelle più avanti in una sezione diversa.
Impostazione interessante, ma nulla di super interessante dal punto di vista della sicurezza.
Qui puoi trovare tutte le applicazioni configurate e i loro dettagli: Chi ha accesso a esse, come è configurato (SAML, OpenID), URL per il login, le mappature tra Okta e l'applicazione...
Nella scheda Sign On c'è anche un campo chiamato Password reveal che consentirebbe a un utente di rivelare la sua password quando controlla le impostazioni dell'applicazione. Per controllare le impostazioni di un'applicazione dal Pannello Utente, fai clic sui 3 punti:
E potresti vedere alcuni dettagli in più sull'app (come la funzione di rivelazione della password, se è abilitata):
Usa le Access Certifications per creare campagne di audit per rivedere periodicamente l'accesso dei tuoi utenti alle risorse e approvare o revocare automaticamente l'accesso quando necessario.
Non l'ho visto utilizzato, ma immagino che da un punto di vista difensivo sia una bella funzionalità.
Email di notifica di sicurezza: Tutte dovrebbero essere abilitate.
Integrazione CAPTCHA: È consigliato impostare almeno il reCaptcha invisibile.
Sicurezza dell'organizzazione: Tutto può essere abilitato e le email di attivazione non dovrebbero durare a lungo (7 giorni va bene).
Prevenzione dell'enumerazione degli utenti: Entrambi dovrebbero essere abilitati.
Nota che la Prevenzione dell'Enumerazione degli Utenti non ha effetto se una delle seguenti condizioni è consentita (vedi User management per ulteriori informazioni):
Registrazione Self-Service
Flussi JIT con autenticazione email
Impostazioni Okta ThreatInsight: Registra e applica la sicurezza in base al livello di minaccia.
Qui è possibile trovare impostazioni configurate correttamente e pericolose.
Qui puoi trovare tutti i metodi di autenticazione che un utente potrebbe utilizzare: Password, telefono, email, codice, WebAuthn... Cliccando sull'autenticatore Password puoi vedere la politica delle password. Controlla che sia forte.
Nella scheda Enrollment puoi vedere quali sono richiesti o opzionali:
È consigliabile disabilitare il telefono. I più forti sono probabilmente una combinazione di password, email e WebAuthn.
Ogni app ha una politica di autenticazione. La politica di autenticazione verifica che gli utenti che tentano di accedere all'app soddisfino condizioni specifiche e applica i requisiti di fattore in base a tali condizioni.
Qui puoi trovare i requisiti per accedere a ciascuna applicazione. È consigliato richiedere almeno una password e un altro metodo per ciascuna applicazione. Ma se come attaccante trovi qualcosa di più debole potresti essere in grado di attaccarlo.
Qui puoi trovare le politiche di sessione assegnate a diversi gruppi. Ad esempio:
È consigliato richiedere MFA, limitare la durata della sessione a qualche ora, non persistere i cookie di sessione attraverso le estensioni del browser e limitare la posizione e il Provider di Identità (se questo è possibile). Ad esempio, se ogni utente dovrebbe accedere da un paese, potresti consentire solo questa posizione.
I Provider di Identità (IdP) sono servizi che gestiscono gli account utente. Aggiungere IdP in Okta consente ai tuoi utenti finali di registrarsi autonomamente con le tue applicazioni personalizzate autenticandosi prima con un account sociale o una smart card.
Nella pagina dei Provider di Identità, puoi aggiungere accessi sociali (IdP) e configurare Okta come fornitore di servizi (SP) aggiungendo SAML in entrata. Dopo aver aggiunto gli IdP, puoi impostare regole di instradamento per indirizzare gli utenti a un IdP in base al contesto, come la posizione dell'utente, il dispositivo o il dominio email.
Se un provider di identità è configurato dal punto di vista di un attaccante e di un difensore controlla quella configurazione e se la fonte è davvero affidabile poiché un attaccante che la compromette potrebbe anche ottenere accesso all'ambiente Okta.
L'autenticazione delegata consente agli utenti di accedere a Okta inserendo le credenziali per il server Active Directory (AD) o LDAP della loro organizzazione.
Ancora una volta, ricontrolla questo, poiché un attaccante che compromette l'AD di un'organizzazione potrebbe essere in grado di passare a Okta grazie a questa impostazione.
Una zona di rete è un confine configurabile che puoi utilizzare per concedere o limitare l'accesso a computer e dispositivi nella tua organizzazione in base all'indirizzo IP che richiede l'accesso. Puoi definire una zona di rete specificando uno o più indirizzi IP individuali, intervalli di indirizzi IP o posizioni geografiche.
Dopo aver definito una o più zone di rete, puoi utilizzarle nelle Politiche di Sessione Globali, politiche di autenticazione, notifiche VPN e regole di instradamento.
Dal punto di vista di un attaccante è interessante sapere quali IP sono consentiti (e controllare se ci sono IP più privilegiati di altri). Dal punto di vista di un attaccante, se gli utenti dovrebbero accedere da un indirizzo IP specifico o da una regione, controlla che questa funzionalità sia utilizzata correttamente.
Endpoint Management: La gestione degli endpoint è una condizione che può essere applicata in una politica di autenticazione per garantire che i dispositivi gestiti abbiano accesso a un'applicazione.
Non l'ho ancora visto utilizzato. TODO
Servizi di notifica: Non l'ho ancora visto utilizzato. TODO
Puoi creare token API di Okta in questa pagina e vedere quelli che sono stati creati, i loro privilegi, il tempo di scadenza e gli URL di origine. Nota che i token API vengono generati con i permessi dell'utente che ha creato il token e sono validi solo se l'utente che li ha creati è attivo.
Le Origini Affidabili concedono accesso ai siti web che controlli e di cui ti fidi per accedere alla tua organizzazione Okta tramite l'API di Okta.
Non dovrebbero esserci molti token API, poiché se ce ne sono un attaccante potrebbe cercare di accedervi e usarli.
Le automazioni ti consentono di creare azioni automatizzate che vengono eseguite in base a un insieme di condizioni di attivazione che si verificano durante il ciclo di vita degli utenti finali.
Ad esempio, una condizione potrebbe essere "Inattività dell'utente in Okta" o "Scadenza della password dell'utente in Okta" e l'azione potrebbe essere "Invia email all'utente" o "Cambia stato del ciclo di vita dell'utente in Okta".
Scarica i log. Vengono inviati all'indirizzo email dell'account attuale.
Qui puoi trovare i log delle azioni eseguite dagli utenti con molti dettagli come il login in Okta o nelle applicazioni tramite Okta.
Questo può importare log dalle altre piattaforme accessibili con Okta.
Controlla i limiti di frequenza API raggiunti.
Qui puoi trovare informazioni generali sull'ambiente Okta, come il nome dell'azienda, l'indirizzo, il contatto email per la fatturazione, il contatto email tecnico e anche chi dovrebbe ricevere gli aggiornamenti di Okta e che tipo di aggiornamenti di Okta.
Qui puoi scaricare agenti Okta per sincronizzare Okta con altre tecnologie.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
