# Okta Hardening

{{#include ../../banners/hacktricks-training.md}}

## Directory

### People

Dal punto di vista di un attaccante, questo è super interessante poiché potrai 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 diversi "**Pending user action**" e "**Password reset**".

### Groups

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).

### Devices

Trova qui un **elenco di tutti i dispositivi** di tutti gli utenti. Puoi anche vedere se è **gestito attivamente** o meno.

### Profile Editor

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 è usato 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).

### Directory Integrations

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 usando 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**.

### Profile Sources

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.

## Customizations

### Brands

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 admin, puoi "**Use a custom sign-out page**" e impostare un URL personalizzato.

### SMS

Niente di interessante qui.

### End-User Dashboard

Puoi trovare qui le applicazioni configurate, ma vedremo i dettagli di quelle più avanti in una sezione diversa.

### Other

Impostazione interessante, ma nulla di super interessante dal punto di vista della sicurezza.

## Applications

### Applications

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, clicca sui 3 punti:

<figure><img src="../../images/image (283).png" alt=""><figcaption></figcaption></figure>

E potresti vedere alcuni dettagli in più sull'app (come la funzione di rivelazione della password, se è abilitata):

<figure><img src="../../images/image (220).png" alt=""><figcaption></figcaption></figure>

## Identity Governance

### Access Certifications

Usa le Access Certifications per creare campagne di audit per rivedere periodicamente l'accesso degli 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à.

## Security

### General

- **Security notification emails**: Tutti dovrebbero essere abilitati.
- **CAPTCHA integration**: È consigliato impostare almeno il reCaptcha invisibile.
- **Organization Security**: Tutto può essere abilitato e le email di attivazione non dovrebbero durare a lungo (7 giorni va bene).
- **User enumeration prevention**: Entrambi dovrebbero essere abilitati.
- Nota che la prevenzione dell'enumerazione degli utenti non ha effetto se una delle seguenti condizioni è consentita (vedi [User management](https://help.okta.com/oie/en-us/Content/Topics/users-groups-profiles/usgp-main.htm) per ulteriori informazioni):
- Registrazione self-service
- Flussi JIT con autenticazione email
- **Okta ThreatInsight settings**: Registra e applica la sicurezza in base al livello di minaccia.

### HealthInsight

Qui è possibile trovare impostazioni **configurate correttamente** e **pericolose**.

### Authenticators

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:

<figure><img src="../../images/image (143).png" alt=""><figcaption></figcaption></figure>

È consigliabile disabilitare il telefono. I più forti sono probabilmente una combinazione di password, email e WebAuthn.

### Authentication policies

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.

### Global Session Policy

Qui puoi trovare le politiche di sessione assegnate a diversi gruppi. Ad esempio:

<figure><img src="../../images/image (245).png" alt=""><figcaption></figcaption></figure>

È 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 specifico, potresti consentire solo questa posizione.

### Identity Providers

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 social o una smart card.

Nella pagina dei Provider di Identità, puoi aggiungere accessi social (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.

### Delegated Authentication

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.

### Network

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 o regione specifica controlla che questa funzione sia utilizzata correttamente.

### Device Integrations

- **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
- **Notification services**: Non l'ho ancora visto utilizzato. TODO

### API

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 **Origin URLs**. 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**.

I **Trusted Origins** 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.

## Workflow

### Automations

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".

## Reports

### Reports

Scarica i log. Vengono **inviati** all'**indirizzo email** dell'account attuale.

### System Log

Qui puoi trovare i **log delle azioni eseguite dagli utenti** con molti dettagli come il login in Okta o nelle applicazioni tramite Okta.

### Import Monitoring

Questo può **importare log dalle altre piattaforme** accessibili con Okta.

### Rate limits

Controlla i limiti di frequenza API raggiunti.

## Settings

### Account

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 aggiornamenti di Okta e che tipo di aggiornamenti di Okta.

### Downloads

Qui puoi scaricare agenti Okta per sincronizzare Okta con altre tecnologie.

{{#include ../../banners/hacktricks-training.md}}
