Facebook Notes consente agli utenti di inserire i tag img. Ogni volta che viene utilizzato un tag , Facebook carica l’immagine dal server esterno e memorizza nella cache. Facebook caricherà in cache l’immagine una volta però utilizzando i parametri get casuali (random) la cache può essere by-passata e la funzione può essere abusata per causare un enorme HTTP GET flood.
I passaggi per ricreare il bug come riportato a Facebook Bug Bounty il 03 marzo 2014.
Passo 1. Creare un elenco di unico tag img come un tag è sottoposto a scansione solo una volta.
<img src=http://targetname/file?r=1></img><imgsrc=http://targetname/file?r=1></img> .. <img src=http://targetname/file?r=1000></img>
Passo 2. Usa m.facebook.com per creare le note. Si tronca in silenzio le note ad una lunghezza fissa.
Passo 3. Creare più note dallo stesso utente o utente diverso. Ogni nota è ora responsabile per oltre 1000 richieste http.
Passo 4. Visualizza tutte le note allo stesso tempo. Il server di destinazione sarà vittima di migliaia di HTTP GET flood. Migliaia di richiesta GET vengono inviati a un singolo server in un paio di secondi. Oltre 100 sono il numero totale di server di Facebook che accederanno in parallelo.
Dopo aver scambiato qualche e-mail mi è stato chiesto di dimostrare se l’impatto sarebbe elevato. Ho sparato su un bersaglio virtualizzato in cloud, e utilizzando solo i browser da tre computer portatili sono stato in grado di raggiungere 400 + Mbps traffico in uscita per 2-3 ore. Numero di Facebook Servers: 127
Naturalmente, l’impatto potrebbe essere più di 400 Mbps come mi è stato solo utilizzando il browser per questo test ed è stato limitato dal numero di file caricabili del browser per ogni dominio. Ho creato uno script proof-of-concept che potrebbe causare impatto ancora maggiore.
Vedo anche un paio di altri problemi con questo tipo di abuso:
- Uno scenario di traffico di amplificazione: quando l’immagine viene sostituito da un pdf o un video di dimensioni maggiori, Facebook dovrebbe caricare un file enorme, senza che l’utente si accorga di nulla.
- Ogni nota supporta 1000 + collegamenti e blocchi di Facebook di un utente dopo la creazione di circa 100 Notes in un breve arco. Poiché non vi è alcun captcha per la creazione di note, tutto questo può essere automatizzato e un utente malintenzionato potrebbe facilmente preparare centinaia di note con più utenti fino al momento di attacco quando tutti loro viene visualizzato in una sola volta.
Anche se una sostenuta 400 Mbps potrebbe essere pericoloso, ho voluto provare per l’ultima volta per vedere se può effettivamente avere un impatto maggiore.
Per liberarsi dalle limitazione del browser ho utilizzato lo script ad hoc e sono stato in grado di ottenere ~ 900 Mbps. traffico in uscita.
Stavo usando un normale file PDF di 13 MB che è stato prelevato da Facebook + 180.000 volte, il numero di server di Facebook coinvolti era 112 .
Possiamo vedere il grafico del traffico è quasi costante a 895 Mbps. Questo potrebbe essere a causa del traffico massimo imposto sulla mia VM, che sta usando una porta ethernet Gbps condivisa. Sembra che non vi è alcuna restrizione mettere sui server di Facebook e con così tanti server possiamo solo immaginare quanto traffico si possa ottenere.
La combinazione di Google e Facebook, sembra che possiamo facilmente ottenere più Gbps di Flood GET.
Facebook crawler si mostra come facebookexternalhit. In questo momento sembra che non c’è altra scelta che quella di bloccarlo per evitare questo fastidio.
Gli attacchi DDOS 
Tra le cose che più destano indignazione nel mio lavoro, è quello di vedere colleghi o sedicenti tali, fare un uso delle tecnologie in modo errato, non avendo a cuore la lungimiranza e gli eventuali problemi che potrebbero verificarsi da li a poco.
