- CIA Triad: Confidentiality, Integrity, Availability - i tre pilastri che ogni attacco viola
- Un ransomware li colpisce tutti e tre in sequenza: esfiltra (C), cifra (I), blocca (A)
- L'ingresso era un bit SUID lasciato su
python3- zero exploit, zero CVE - Senza la CIA Triad come mappa, stai guardando i sintomi senza vedere la malattia
▶ $ history
Sono le 23:12. Il telefono vibra tre volte di fila - notifiche di monitoring. Mi alzo, apro il portatile.
Il dashboard è rosso.
Non uno o due alert. Rosso ovunque. Processi che non esistevano un'ora fa. I/O di disco a 100% su prod-db-01. Un file che si chiama READ_ME_BITCOIN.txt comparso in /var/www/html/.
Apro una connessione SSH. Il cursore lampeggia.
ls -la /var/www/html/READ_ME_BITCOIN.txtEsiste. 847 byte. Creato 23 minuti fa.
Non lo apro ancora. Prima guardo cosa sta girando.
La scena#
Il disco sta ancora scrivendo. Qualcosa cifra i file in tempo reale - li rinomina con estensione .locked. Ho venti secondi prima che arrivi anche alle directory di configurazione.
Isolo il server dalla rete. Stacco il cavo virtuale. Il disco si calma.
Troppo tardi per i file. Non troppo tardi per capire.
Apro il file di testo:
Your files have been encrypted.
Send 0.15 BTC to 1A2B3C... within 72 hours.
Do not contact authorities.La mappa#
In quel momento non penso a "ransomware". Penso a tre lettere: C, I, A.
Non la Central Intelligence Agency. La triade che ogni analista di sicurezza ha in testa come bussola.
Confidentiality - chi poteva leggere quei file? Integrity - qualcuno ha modificato qualcosa che non avrebbe dovuto? Availability - i dati sono ancora accessibili?
L'ultima risposta è ovvia. I file non sono più leggibili. Availability violata.
Ma le altre due?
La traccia - Integrity#
Cerco le modifiche recenti. I log di sistema hanno una lacuna strana - 40 minuti senza righe, poi riprendono come nulla fosse.
diff /backup/etc/passwd /etc/passwd> svc-backup:x:1003:1003::/home/svc-backup:/bin/bashUn utente nuovo. Aggiunto durante la lacuna nei log. Integrity violata - i dati di sistema sono stati modificati senza autorizzazione, e la modifica è stata progettata per non essere rilevata.
La traccia - Confidentiality#
Prima di cifrare, quasi sempre c'è una fase di esfiltrazione. I dati valgono due volte: prima li vendono, poi chiedono il riscatto.
Guardo il traffico di rete delle ultime ore nei log del firewall. C'è una connessione in uscita verso un IP esterno - 847 MB trasferiti tre ore prima della cifratura.
Il database clienti pesa 820 MB.
Confidentiality violata - i dati sono usciti prima che qualcuno se ne accorgesse.
Il punto d'ingresso#
La domanda che rimane è: come sono entrati? Non c'erano porte esposte, nessun servizio web vulnerabile noto.
find / -perm -4000 -type f 2>/dev/nullLa lista scorre. Quasi tutto normale. Poi:
/usr/bin/python3stat /usr/bin/python3Access: (4755/-rwsr-xr-x) Uid: ( 0/ root)Quattro. Sette. Cinque. SUID root su python3.
Da lì in poi era tutto in discesa. L'account svc-backup - aggiunto via Integrity violation - aveva accesso limitato. Con SUID root su python3, tre righe di codice erano sufficienti per diventare root. Da root, tutto il resto: cifratura, log tampering, utente fantasma.
Dietro le quinte#
La CIA Triad#
Tre obiettivi che qualsiasi sistema di sicurezza deve proteggere:
graph TD
C[Confidentiality\nSolo chi è autorizzato può leggere]
I[Integrity\nI dati non vengono alterati senza autorizzazione]
A[Availability\nI dati sono accessibili quando servono]
Un ransomware moderno li viola tutti e tre in sequenza:
| Fase | Pilastro violato | Cosa succede |
|---|---|---|
| Esfiltrazione | Confidentiality | I dati escono prima della cifratura |
| Log tampering | Integrity | Le tracce vengono cancellate |
| Cifratura file | Availability | I dati non sono più accessibili |
Come rilevare ogni violazione#
# Confidentiality - file sensibili esposti?
ls -la /etc/shadow
# deve essere: -rw-r----- root shadow
# Integrity - modifiche non autorizzate?
diff /backup/etc/passwd /etc/passwd
# Availability - servizi attivi?
systemctl status ssh nginxIl vettore: SUID su python3#
Come documentato in chmod +s - il bit che dimentichi e l'attaccante trova: SUID root su un interprete è escalation immediata, senza exploit, senza CVE. Un typo in un chmod alle 23:00 può aprire una backdoor root per ore.
IoC#
| Tipo | Valore | Pilastro | MITRE ATT&CK |
|---|---|---|---|
| File | READ_ME_BITCOIN.txt | Availability | T1486 |
| Utente | svc-backup aggiunto | Integrity | T1136.001 |
| Traffico | 847 MB verso IP esterno | Confidentiality | T1041 |
| Binario | python3 con SUID root | - | T1548.001 |
| Lacuna log | 40 min di silenzio | Integrity | T1070.002 |
exit 0#
La CIA Triad non è un framework accademico da imparare e dimenticare. È una lista di controllo da avere in testa durante un incidente: cosa hanno violato? In quale ordine? Cosa manca ancora da trovare?
Quella notte, senza quella mappa, avrei visto solo i file cifrati. Con quella mappa, ho trovato l'esfiltrazione, l'utente fantasma, e il bit SUID che aveva reso possibile tutto.
Concetti correlati: iam · linux permissions
Approfondimento tecnico: Il bit s - capire il SUID · chmod +s in produzione
