Regole d'ingaggio nel bug bounty: perimetro, safe harbour e divulgazione

#Che cos'è un programma di bug bounty

Un programma di bug bounty è un invito permanente di un'organizzazione a testare i suoi sistemi pubblici e a segnalare falle di sicurezza, di solito in cambio di una ricompensa. L'invito ha delle condizioni. Quelle condizioni, di solito chiamate policy, dicono quali sistemi puoi testare, come puoi testarli, cosa non devi toccare, come devi segnalare e cosa promette in cambio l'organizzazione.

La policy è il regolamento. I guai spesso iniziano quando un ricercatore l'ha saltata o l'ha letta come una formalità. Un laboratorio ti insegna a trovare una falla. La policy di un programma ti insegna dove puoi guardare e quando fermarti al confine del permesso. Questo articolo parla della seconda capacità.

Qui non testerai niente. Leggerai una policy di esempio, la annoterai e scriverai una checklist pre-test da riusare sui programmi reali. Gli unici comandi che esegui toccano file sul tuo computer.

#Perché le regole vengono prima dei test

Il rischio legale è il primo motivo che si cita di solito, ed è reale. In molti paesi le leggi sull'uso illecito dei computer sono scritte in modo così ampio che un accesso senza permesso può essere perseguito anche quando l'intenzione era buona. Il Computer Fraud and Abuse Act (CFAA) negli Stati Uniti è l'esempio più noto. Nel maggio 2022 il Dipartimento di Giustizia degli Stati Uniti ha cambiato il modo in cui i suoi procuratori applicano quella legge alla ricerca di sicurezza in buona fede. La policy rivista indica ai procuratori di non incriminare la ricerca condotta al solo scopo di testare, esaminare o correggere una falla, che evita danni e le cui informazioni servono soprattutto a migliorare la sicurezza. Non modifica la legge. Non protegge la ricerca finalizzata all'estorsione. È una linea guida sull'azione penale e non un diritto, e non vincola i procuratori statali né i privati che fanno causa. Leggi il comunicato del DOJ per il testo esatto. Non prenderlo come un permesso di testare quello che vuoi.

Il secondo motivo è pratico. Chi finisce in un sistema di pagamento, nel dominio di un'azienda acquisita o nell'API di un partner ha toccato qualcosa che il proprietario non ha mai offerto. Anche se il finding è reale, ora il proprietario deve decidere se la segnalazione è un regalo o un incidente. Restare nel perimetro scritto fa sì che si continui a parlare del bug.

Quindi la regola è semplice: se la policy non elenca un asset nel perimetro, non puoi testarlo. Il silenzio non vale come consenso. La risposta di un addetto al supporto conta solo se la policy dice chi può concedere eccezioni, e solo per iscritto.

#Leggere la policy di un programma, passo per passo

Affronta la policy sempre nello stesso ordine. Ogni sezione qui sotto è una domanda a cui devi saper rispondere prima che la prima richiesta lasci la tua macchina.

#1. Asset nel perimetro e fuori perimetro

Il perimetro è l'elenco degli asset che il proprietario ti permette di testare. Un asset può essere un dominio, un intervallo IP, un'app mobile, un'API, un prodotto o un tipo di account. Una buona policy nomina esattamente ogni asset e dice se un wildcard come *.example.test copre ogni sottodominio.

Leggi con la stessa attenzione l'elenco fuori perimetro. Di solito nomina i servizi di terzi che l'azienda non possiede, come pagine di pagamento in hosting, provider di email e content delivery network. Una policy può dare il permesso di testare i sistemi del proprietario. Non può dare il permesso di testare quelli di un vendor, e ogni vendor ha le sue condizioni.

Due abitudini aiutano. La prima: controlla dove punta ogni nome nel perimetro. Se un nome si risolve su un host di una piattaforma terza, leggi le condizioni di quella piattaforma prima di testarlo. La seconda: annota la data del controllo, perché gli elenchi di perimetro cambiano.

#2. Tecniche consentite e vietate

Le policy descrivono le tecniche come consentite, vietate o non menzionate. Tratta le non menzionate come vietate. Tra i divieti comuni ci sono denial of service, ingegneria sociale verso il personale, accesso fisico e attacchi che copierebbero o modificherebbero dati altrui. Alcuni programmi vietano del tutto gli scanner automatici. Altri li consentono con dei limiti.

Scrivi l'elenco con parole tue prima di iniziare: "Consentito: test manuale dell'app web con un account di test. Vietato: denial of service, phishing verso il personale, scanner." Se non riesci a scriverlo, non sei pronto per testare.

#3. Rate limit e carico

I rate limit proteggono i sistemi del proprietario e gli altri utenti. Una policy può indicare un tetto di richieste, un limite di richieste simultanee o una regola come "non più di un test al secondo". Se non dice niente, tieni il traffico basso e manuale. Un'esecuzione automatica che dal tuo lato sembra innocua può rallentare un piccolo servizio, e il disservizio diventa un incidente tuo.

Metti il numero nella checklist. Configura lo strumento per rispettarlo e controlla l'impostazione prima di iniziare.

#4. Account di test

Molti programmi ti chiedono di registrare un account di test, a volte con uno schema di email preciso, e di usare solo account creati da te. Alcuni vietano di creare account per altre persone, di usare il login di un cliente reale o di testare con dati che non hai creato. I test di controllo degli accessi di solito richiedono due account, quindi la policy dovrebbe dire quali puoi usare e quali dati puoi crearci dentro.

#5. Gestione dei dati

Questa sezione decide cosa puoi fare con quello che trovi. Le regole tipiche dicono che devi fermarti quando arrivi a dati personali, non devi scaricare più del necessario per dimostrare il problema, non devi conservare copie e devi cancellare il materiale quando la segnalazione viene chiusa. Alcune policy richiedono di oscurare gli screenshot.

La regola di fermarsi davanti ai dati personali coglie impreparate molte persone. Se un insecure direct object reference (IDOR) ti dà il record di qualcun altro, la prova giusta di solito è l'identificatore e una breve descrizione, non il dump della tabella. Registra quello che hai visto e lascia il resto dov'è.

#6. Clausole di safe harbour

Il safe harbour è la promessa del proprietario di non avviare azioni legali contro chi fa ricerca in buona fede nel rispetto della policy. Il progetto disclose.io pubblica testi di safe harbour e strumenti per le organizzazioni che vogliono scrivere il proprio. Il suo sito dice che lo scopo è permettere alle persone di segnalare problemi di sicurezza senza temere conseguenze legali, e precisa che il materiale non è una consulenza legale.

Leggi con attenzione il testo del safe harbour. Una buona clausola indica le sue condizioni, come rispettare la policy, segnalare tempestivamente e non usare l'accesso per altro. Copre inoltre i sistemi del programma stesso. La promessa di un'azienda non copre terzi né condotte estranee. Se una policy non ha alcun safe harbour, valuta questo fatto prima di testare.

#7. Contatti e termini di divulgazione

La sezione dei contatti dice dove inviare una segnalazione e come risponderà il proprietario. Cerca un contatto di sicurezza, una casella su una piattaforma o un file security.txt sotto /.well-known/. Cerca i tempi di conferma della ricezione e cosa succede al finding dopo la correzione.

I termini di divulgazione dicono quando puoi pubblicare. Alcune policy consentono la pubblicazione una volta rilasciata la correzione. Altre fissano una finestra a partire dalla prima segnalazione. La pagina di CISA sulla divulgazione coordinata delle vulnerabilità dice che, quando un vendor non risponde o non si impegna su una tempistica ragionevole, CISA può divulgare già 45 giorni dopo il primo tentativo di contatto. Questa è la regola di CISA per il proprio ruolo, non un numero universale. I tuoi termini li fissa la policy del tuo programma, e non pubblichi prima di quanto consentono.

#Divulgazione coordinata delle vulnerabilità

La divulgazione coordinata delle vulnerabilità (CVD) è il processo in cui chi trova una vulnerabilità la segnala a chi può correggerla, il vendor e le altre parti coinvolte preparano una correzione e delle indicazioni, e l'informazione viene pubblicata quando chi ne ha bisogno può agire. CISA dice che il suo programma facilita la diffusione tempestiva e sincronizzata delle informazioni sulle vulnerabilità e delle eventuali mitigazioni.

ISO/IEC 29147, intitolata "Vulnerability disclosure" nella serie Information technology, Security techniques, è lo standard internazionale per il lato esterno di quel processo. Spiega come un vendor riceve le segnalazioni, comunica con chi segnala, si coordina con altri vendor e pubblica i bollettini di sicurezza. La norma collegata, ISO/IEC 30111, riguarda come il vendor gestisce internamente la vulnerabilità. Il catalogo ISO indica il documento come seconda edizione del 2018. Controlla su iso.org lo stato attuale prima di citarlo.

Per chi fa ricerca, in pratica una segnalazione apre una conversazione dentro un processo. Segnali, aspetti la conferma di ricezione, condividi quello che serve a riprodurre il problema e rispetti la tempistica concordata. Questi passi seguono il modello dello standard anche quando un programma non lo cita mai.

#Perché testare fuori perimetro è vietato

Il permesso viene dal proprietario di un sistema, e ha un confine. Il perimetro è quel confine messo per iscritto. Per il tuo test, tutto ciò che sta fuori è il sistema di qualcun altro, e in molte leggi sull'uso illecito dei computer un accesso senza permesso può valere come accesso non autorizzato.

Quando si testa fuori perimetro vanno storte tre cose. Primo, ci si può sbagliare su chi possiede l'asset, e il test colpisce un estraneo. Secondo, il proprietario può aver escluso l'asset per un motivo che non vedi, come un vecchio sistema fragile. Terzo, anche se hai ragione, la segnalazione diventa più difficile da accettare, perché il proprietario deve decidere se premiare un finding che non ti ha mai chiesto di cercare.

La risposta onesta a un dubbio sul perimetro è chiedere per iscritto al programma prima di testare, oppure lasciar perdere l'asset. Una domanda breve costa molto meno di una causa legale.

#Pratica: annota una policy di esempio e scrivi una checklist pre-test

Per questa sezione non serve alcun laboratorio. Il programma di esempio qui sotto è fittizio e usa il dominio riservato example.test. Lo leggerai, lo annoterai e controllerai una checklist con un piccolo script sulla tua macchina. Niente di quello che fai qui invia richieste a un host reale.

#La policy di esempio

Salva questo testo come sample-policy.md in una cartella vuota.

Example Widget Co. Vulnerability Disclosure Program (fictional)

1. Scope
   In scope: *.example.test and api.example.test.
   Out of scope: payments.example.test (hosted by a payment provider),
   any third-party SaaS host, staging-old.example.test.

2. Techniques
   Allowed: manual testing with a test account you created.
   Allowed: automated scanners at no more than 2 requests per second.
   Forbidden: denial of service, phishing or contacting staff, physical access.

3. Test accounts
   Create accounts with the suffix [email protected].
   Do not use accounts that belong to customers.

4. Data
   If you reach personal data, stop and report the identifier only.
   Delete copies within 30 days of the report being closed.

5. Safe harbour
   We will not pursue legal action against good-faith research that follows
   this policy.

6. Reporting
   Send reports to [email protected]. We acknowledge within 3 business days.
   We ask for 90 days between first report and public disclosure.

#Esercizio di annotazione

Copia la policy in un file di testo e assegna a ogni riga una di queste quattro etichette: [SCOPE], [RULE], [ASK] o [GAP]. Usa ASK quando devi chiarire qualcosa con il programma prima di testare. Usa GAP quando la policy non dice niente su qualcosa che ti serve.

Poi rispondi per iscritto a queste domande. Cita la riga che risponde a ciascuna e non rispondere a memoria.

1. api.example.test è coperto dalle stesse regole del sito principale, o richiede un controllo a parte?
2. Il rate limit vale solo per gli scanner o anche per il traffico manuale?
3. Qual è lo stato di payments.example.test, e cosa faresti se un test lo raggiungesse per sbaglio?
4. Il safe harbour copre un finding che espone dati dei clienti?
5. Quale parte dei termini di divulgazione è un impegno del proprietario e quale una richiesta rivolta a te?

La domanda 4 non ha risposta nel testo. Etichettala GAP e scrivi la domanda che invieresti al programma.

#La checklist pre-test

Scrivi la checklist prima di ogni test. Dovrebbe stare in una schermata, con una riga per voce ricavata dalle sezioni della policy su perimetro, tecniche, account, dati e contatti. Salva questo testo come checklist.md:

# Pre-test checklist

- [ ] written scope:
- [ ] excluded assets:
- [ ] allowed techniques:
- [ ] test account rules:
- [ ] data handling:
- [ ] contact and disclosure terms:

Compila ogni riga con la risposta e, accanto, una citazione dalla policy. Una voce che non riesci a compilare è una domanda aperta, e non dovresti testare finché non è chiusa.

#Controlla la checklist con uno script

Salva lo script seguente come precheck.py nella stessa cartella. Legge un file di testo locale e non si collega a niente.

import re, sys

REQUIRED = [
    "written scope",
    "excluded assets",
    "allowed techniques",
    "test account rules",
    "data handling",
    "contact and disclosure terms",
]

def read_fields(path):
    fields = {}
    with open(path, encoding="utf-8") as f:
        for line in f:
            m = re.match(r"^- \[( |x)\] ([^:]+):\s*(.*)$", line.rstrip("\n"))
            if m:
                fields[m.group(2).strip().lower()] = (m.group(1) == "x", m.group(3).strip())
    return fields

fields = read_fields(sys.argv[1])
missing = 0
for name in REQUIRED:
    if name not in fields:
        print(f"MISSING LINE: {name}")
        missing += 1
        continue
    done, value = fields[name]
    if not done or not value or value.upper() in ("TBD", "?"):
        print(f"OPEN: {name}")
        missing += 1
    else:
        print(f"OK: {name}")
print(f"{len(REQUIRED) - missing} of {len(REQUIRED)} items closed")
sys.exit(1 if missing else 0)

Eseguilo da Git Bash nella cartella che contiene entrambi i file:

python precheck.py checklist.md
echo "exit=$?"

L'autore lo ha eseguito su una macchina Windows 11 con Git Bash, usando una checklist in cui la riga dell'account di test riportava ancora TBD. L'output è stato:

OK: written scope
OK: excluded assets
OK: allowed techniques
OPEN: test account rules
OK: data handling
OK: contact and disclosure terms
5 of 6 items closed
exit=1

Lo script segnala la voce aperta ed esce con stato 1, così uno script esterno può fermare il test. Controlla solo che il modulo sia completo. Non può dire se una voce corrisponde alla policy, ed è per questo che ogni voce richiede accanto la riga citata.

#Errori comuni

• Scambiare il nome del programma per il perimetro. Un programma chiamato "Example Widget" può coprire un solo prodotto, più aziende o nessuna delle controllate a cui pensi. Leggi l'elenco.
• Testare un asset indovinato o ereditato. Un sottodominio che hai indovinato, o un indirizzo preso da un vecchio record pubblico, è fuori perimetro finché la policy non lo elenca.
• Lanciare uno scanner a piena velocità perché la policy non parla di limiti. Il silenzio sui limiti non è un permesso di andare veloce.
• Conservare i dati dopo la segnalazione. Le copie rimaste su un portatile sono ancora dati del proprietario, e la policy può richiedere di cancellarle.
• Pubblicare in anticipo perché il vendor ha risposto "risolto". Leggi i termini di divulgazione e aspetta i tempi che prevedono.
• Scrivere una segnalazione che dimostra più di quanto potevi raccogliere. L'identificatore e un campo oscurato di solito dimostrano il problema quanto un dump.
• Dare per scontato che il safe harbour copra tutto. Copre quello che dice il suo testo, per i sistemi che nomina.

#Per andare oltre

Allenati a leggere le policy dei programmi pubblici che rendono note le loro regole. Tieni una checklist per programma e rileggi la policy il giorno stesso del test, perché il perimetro cambia. Leggi per intero il materiale sul safe harbour di disclose.io e la pagina di CISA sulla divulgazione coordinata. Impara la differenza tra una vulnerability disclosure policy, che può non prevedere ricompense, e un programma di bug bounty, che paga i finding. Poi leggi come scrivere il tuo primo report di sicurezza per vedere come dovrebbe presentarsi un finding quando hai il permesso e hai trovato qualcosa.

Tieni appunti su cosa hai testato, quando e da quale account. Se una domanda arriva mesi dopo, quegli appunti sono la tua prova.

Costruisci le competenze tecniche in un laboratorio isolato, non sul sistema di qualcun altro. I passi sono in come creare una rete Docker isolata per i laboratori. Anche le informazioni pubbliche hanno i loro limiti, trattati in etica e privacy nell'OSINT.

#Fonti

• disclose.io, strumenti per safe harbour e policy: https://disclose.io/
• ISO/IEC 29147, Information technology, Security techniques, Vulnerability disclosure: https://www.iso.org/standard/72311.html
• CISA, Coordinated Vulnerability Disclosure Process: https://www.cisa.gov/coordinated-vulnerability-disclosure-process
• U.S. Department of Justice, New Policy for Charging Cases Under the Computer Fraud and Abuse Act (maggio 2022): https://www.justice.gov/opa/pr/department-justice-announces-new-policy-charging-cases-under-computer-fraud-and-abuse-act