↓ Skip to main content
u-random
u-random
  1. Concetti/

Secret Scanning - trovare segreti esposti

·4 mins
base
Dfir Threat-Intel
Alessio Barnini
Author
Alessio Barnini
Table of Contents
Secret Scanning - trovare segreti esposti

Cosa fa
#

Pratica difensiva e offensiva di cercare credenziali, chiavi API, password e token esposti involontariamente in repository git, file di configurazione, log e documentazione. Uno dei vettori di compromissione piu' comuni — il caso AWS da 50k$ in una notte e' reale.

TL;DR
#

Sviluppatore commette chiave API per errore
           │
           ▼
Bot su GitHub trova la chiave in 30 secondi
           │
           ▼
Chiave usata per accedere all'account cloud
           │
           ▼
Istanze EC2 create per mining → bolletta da 50.000$
           │
           ▼
Sviluppatore rimuove la chiave dal codice
           │ ← TROPPO TARDI
           ▼
La chiave e' ancora nella storia git

I posti dove cercare segreti
#

In un repository git
#

# 1. Storia dei commit — il posto piu' ovvio
git log -p | grep -i "password\|secret\|key\|token\|api"

# 2. Branch nascosti — spesso dimenticati
git branch -a
git checkout dev
git log -p | grep -i "password"

# 3. Tag — raramente controllati
git tag
git show <tag>

# 4. Stash — modifiche temporanee salvate
git stash list
git stash show -p stash@{0}

# 5. File di configurazione nel repo
find . -name "*.env" -o -name "*.config" -o -name "config.yml" | xargs grep -i "password"

# 6. Cerca in tutti i branch contemporaneamente
git log --all -p | grep -i "password\|secret\|api_key"

In un sistema Linux
#

# File di configurazione con credenziali
grep -r "password" /etc/ 2>/dev/null
find /etc -name "*.conf" -exec grep -l "password\|secret\|key" {} \;

# Bash history — comandi digitati con credenziali
grep -i "password\|token\|key" ~/.bash_history
grep -i "curl.*key\|wget.*token" /home/*/.bash_history 2>/dev/null

# File .env nelle home
find /home -name ".env" 2>/dev/null

# Variabili d'ambiente del processo
cat /proc/<PID>/environ | tr '\0' '\n' | grep -i "key\|secret\|password"

In file di log
#

# Credenziali nelle URL (errore comune)
grep -r "password=" /var/log/ 2>/dev/null
grep -r "token=" /var/log/ 2>/dev/null

# Curl/wget con credenziali nei log
grep -E "curl.*-u|wget.*--password" /var/log/

Pattern comuni di segreti
#

# AWS
AKIA[0-9A-Z]{16}                    # Access Key ID
[0-9a-zA-Z/+]{40}                   # Secret Access Key

# Chiavi generiche
[Aa]pi[_-]?[Kk]ey.*[:=].*['\"][0-9a-zA-Z]{20,}
[Ss]ecret.*[:=].*['\"][0-9a-zA-Z]{20,}
[Pp]assword.*[:=].*['\"][^'\"]{8,}

# Token JWT
eyJ[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]{10,}

Strumenti professionali
#

ToolUsoNote
truffleHogScansione storia gitTrova pattern ad alto entropy
gitleaksScansione repoPiu' veloce, regole configurabili
git-secretsPre-commit hookBlocca commit con segreti
GitHub Secret ScanningAutomatico su pushNotifica per chiavi note
detect-secretsYelp open sourceBaseline di segreti noti

Come prevenire
#

# 1. Pre-commit hook con git-secrets
git secrets --install
git secrets --register-aws   # pattern AWS predefiniti

# 2. File .gitignore — esclude file sensibili
*.env
*.key
config.local.*
credentials/
secrets/

# 3. Variabili d'ambiente invece di hardcoding
# SBAGLIATO
api_key = "sk-ant-abc123..."

# CORRETTO
import os
api_key = os.environ.get("API_KEY")

Cosa fare se un segreto e' gia' esposto
#

  1. Revoca immediata — la chiave compromessa va invalidata subito, prima ancora di rimuoverla dal codice. Se e' su GitHub, i bot ci arrivano in 30 secondi.
  2. Rimozione dalla storia — git filter-repo --path file --invert-paths riscrive la storia. Ma chiunque abbia clonato ha ancora la versione vecchia.
  3. Notifica — se la chiave aveva accesso a dati di altri utenti, potrebbe esserci obbligo di notifica (GDPR, NIS2).
  4. Audit — verifica se la chiave e' stata usata nel periodo di esposizione (log del provider cloud, audit trail).
Warning

Rimuovere il segreto dal codice senza revocarlo e' inutile. La chiave e' ancora valida — chiunque l'abbia vista puo' usarla. Revoca sempre prima, rimuovi dopo.

Scenario Reale — il caso AWS 50k$
#

Uno sviluppatore committa per errore le credenziali AWS in un repo pubblico GitHub. In meno di un minuto, bot automatici trovano le chiavi e creano centinaia di istanze EC2 per il mining di criptovalute. La bolletta AWS arriva a 50.000$ in una notte.

AWS ha un sistema di secret scanning integrato con GitHub — quando rileva una chiave, notifica sia lo sviluppatore che AWS stessa. Ma la notifica arriva dopo l'esposizione.

La lezione: le credenziali cloud nei repo pubblici vengono trovate in secondi, non minuti.

Dove l'ho incontrato
#

  • bandit-28 — storia commit con password rimossa
  • bandit-29 — branch dev con credenziali production
  • bandit-30 — tag con password
  • git — nota git con caso AWS

Collegato a
#

  • incidents — categoria
  • git-objects — struttura interna git — perche' i segreti sopravvivono
  • git — comandi per il secret scanning manuale
  • bash-startup-files — dotfile come vettore di esposizione

Related