Ti suggerisco di cominciare con la Portswigger Web Academy. E’ gratuita e ti da’ una ottima foundation con labs fatti bene. Una volta che hai passato tutti quei labs, ti suggerisco di continuare con TryHackMe e HackTheBox come secondo step. Una volta fatta pratica con questi, un passo successivo e’ quello di completare le CTFs (capture the flag) su e.g. HackerOne. Potresti anche fare una certification per esempio con OffSec. A questo punto potresti gia’ iniziare con bug bounties almeno con vulnerabilita’ semplici. Per beginners consiglio sempre di cercare vulnerabilita’ di broken access control e IDOR (insecure direct object reference), perche’ TUTTE le apps hanno questo tipo di vulnerabilita’ e sono piuttosto facili da trovare.
Oggi ho trovato soltanto una vulnerabilita’, ma una cool. In realta’ ho copiato un attacco fatto a OpenAI di recente e basato su un problema con alcune CDN, in questo caso Cloudflare. 
Quindi non una idea originale ma utile. Quando fai BB e’ importante seguire i trend e le news perche’ cosi’ si imparano methodi nuovi.
Spiegazione per gli interessati: l’applicazione target salva in Cloudflare cache tutto quello che sta sotto /static, segno che gli admin hanno configurato una page rule per mettere tutto quello che e’ in /static in cache per performance. Questo viene fatto spesso quando si vuole mixare contenuto dinamico con contenuto statico sotto lo stesso hostname, invece di usare un hostname separato per static assets. Nel mio caso, l’applicazione serve dynamic content che bypassa la cache a meno che quel content sia in /static. Il trucco si basa su path traversal.
Se visito lo URL https://domain.com/static//../path-to-risorsa-riservata?cache-buster=blah, Cloudflare correttamente si accorge che sto facendo path traversal e che il contenuto richiesto in realta’ non e’ sotto /static, e per questo motivo lo tratta come dynamic content e quindi non lo mette in cache.
Il problema e’ che se pero’ invece di “/…/” metto lo stesso ma URL-encoded, cioe’ “%2F…%2F”, Cloudflare non fa decoding di %2F, quindi pensa che il path sia in /static e percio’ salva il contenuto in CDN cache. Spiego il significato del param cache-buster in un attimo.
L’exploit consiste nell’usare path traversal con quello URL-encoding per far si’ che Cloudflare salvi in cache il response di una pagina per un altro user che normalmente non dovrebbe essere salvata in cache, nel mio caso il path completo della API e’ /api/v1/me/tokens. Se visito https://domain.com/api/v1/me/tokens, il response in JSON contiene i miei API tokens e il response non viene salvato in cache, come atteso.
Ma se visito https://domain.com/static/%2F..%2Fapi/v1/me/tokens?cache-buster=1, per il motivo spiegato prima Cloudflare mette in contenuto in cache, il che significa che se dopo visito di nuovo lo stesso URL, il response di prima viene restituito dalla cache. Fin qua ci siamo?
Se in qualche modo forzo una vittima che e’ loggata sulla target app a visitare quello URL, il risultato e’ che la lista dei loro tokens viene salvata in cache per lo URL che ho fatto usare. Quindi per me, come attacker, e’ sufficiente visitare lo stesso URL in seguito per vedere i tokens della vittima
cache-buster e’ semplicemente un parametro che deve avere un valore diverso per ogni vittima, cosi’ da mettere in cache tokens diversi per diverse vittime.
Quindi l’unica cosa che devo fare e’ far visitare lo speciale URL che ho preparato ad una vittima che potrebbe essere loggata nella app, e ci sono molti modi per fare questo. Tutto qui Ovviamente poi con i loro API tokens posso fare quello che voglio sul loro account e/o risorse che quei tokens possono gestire.
Se siete interessati a questo tipo di update continuo, senno why bother :D Fatemi sapere se siete interessati.
