Repeater in Burp Suite
Il repeater è uno strumento che ci verrà utile per l'exploiting manuale delle vulnerabilità. Non fa altro che prendere una richiesta esistente (comprensiva di tutti gli header) e ripeterla a seconda dei parametri che andremo a modificare.
Applicazioni di utilizzo:
Multiple (non esistono casi particolari, il repeater è utilizzato per tutti i tipi di assessment). Una volta individuata la richiesta che vogliamo modificare basterà cliccarci sopra e selezionare “Send to Repeater”.
La Tab del Repeater verrà evidenziata in giallo per farci capire che c'è stato un evento che richiede la nostra attenzione. Questa è la schermata principale:
Nel riquadro di sinistra troviamo la nostra richiesta che contiene due diversi colori:
- In blu è il nome del parametro
- In rosso è il valore del parametro
Il resto del testo è l'header originale che possiamo lasciare così com'è o modificare. Nel riquadro di destra (che apparirà solo dopo aver inviato la richiesta con “Go”) c'è la risposta del server. Diamo uno sguardo all'interfaccia del repeater:
- la tab “Raw” ci presenta del testo in chiaro, non alterano né decodificato (alcune risposte potrebbero essere in formato gzip);
- la tab “Params” ci porta all'attenzione i parametri dinamici passati nella richiesta;
- la tab “Headers” ci mostra solo gli headers di richiesta/risposta, senza aggiungere ulteriore contenuto;
- la tab “Hex” presenta il contenuto della richiesta/risposta in formato esadecimale (utile per verificare mime type multimediali);
- la tab “Render” è un browser integrato che ci mostrerà la richiesta con immagini e testo formattato.
- appena sotto alla richiesta / risposta c'è un campo di testo che serve alla ricerca di testo all'interno di quella specifica finestra;
- infine nell'angolo in basso a destra troviamo il peso della risposta e i millisecondi impiegati a riceverla;
Proxy Intercept in Burp Suite
Questa funzione ci consente di modificare “al volo” i dati che passiamo al server o la risposta del server verso il nostro browser. Di default è abilitata solo la modifica delle richieste, ma visto che l'abbiamo già fatto su “Repeater”, vediamo come modificare la risposta del server verso il nostro browser.
Applicazioni di utilizzo:
- Mobile assessment (L'intercept è molto utilizzato per passare all'applicazione mobile dei dati che non si aspetterebbe dal server);
- Web application in Ajax (Tecnologie come ajax modificano dinamicamente i contenuti del sito, per questo motivo siamo costretti ad usare l'intercept per vedere i risultati sul browser, cosa che con il repeater vedremmo solo staticamente in Burp).
Impostiamo l'intercept per modificare solo le risposte dal server:
- Posizioniamoci su Proxy - Options
- Su “Intercept Client Requests” togliamo la spunta ad “Intercept....”
- Su “Intercept Server Responses” aggiungiamo la spunta ad “Intercept...”
- Posizioniamoci su Proxt - Intercept e clicchiamo su “Intercept is off” per attivarlo.
A questo punto la prossima richiesta partirà normalmente verso il server senza essere modificata, ma la risposta apparirà in questa Tab di Burp. Modifichiamo il contenuto e clicchiamo su “Forward” e disattiviamo l'intercept per far passare tutte le altre richieste senza doverle approvare manualmente. Questo è il risultato:
Un esempio utile per quanto riguarda il mobile assessment è provare ad inserire codice javascript e vedere se l'applicazione lo esegue.
Comparer
Il Comparer di Burp è uno strumento che ci consente di evidenziare le differenze fra due richieste/risposte. Funziona allo stesso modo di “diff” su Linux. Applicazioni di utilizzo:
- Username enumeration: evidenziare le differenze in una richiesta con username valido e in un'altra con username non valido;
- Blind SQL Injection: essendo una SQL Injection in cui non appaiono errori dobbiamo capire qual è il contenuto di risposta per una condizione vera e qual'è invece il contenuto per una condizione falsa.
Per utilizzarlo ci servono quindi 2 richieste/risposte differenti: prendiamo l'esempio della pagina “/wp-admin/admin-ajax.php” che è adibita a fare richieste XMLRPC in WordPress.
Per vedere le differenze basterà cliccare col pulsante destro e “Send to Comparer”. Facciamolo per entrambi le risposte e posizioniamoci sulla schermata del Comparer. Ora possiamo cliccare sul pulsante “Words” per vedere cos'è cambiato:
In rosso sono evidenziati gli elementi che differiscono fra le due risposte:
- X-Ants-Machine-Id è un header che identifica quale server ha inviato la risposta (html.it fa uso di load-balancer per smistare traffico);
- Content-length: è la lunghezza della risposta, nella prima richiesta c'è 1 carattere, nella seconda ce ne sono 2;
- Date: Ora di risposta (ovviamente differisce non essendo stata ricevuta nello stesso momento);
- X-Varnish: header con identificativo univoco che serve ad riconoscere una richiesta sui log del web server;
- X-Vanish-Hn: un altro header personalizzato dallo staff di html.it per Varnish;
- Ed infine il contenuto della risposta.
Nella prima troviamo “0” (zero) che ci fa capire che la funzione che abbiamo richiamato “NOT_EXIST” non è stata riconosciuta dal sistema. Mentre nella seconda risposta troviamo “OK”, un semplice messaggio che ci conferma che la funzione “html_cdb_update_cache” è terminata con successo.
Nella prossima uscita della guida vedremo gli altri strumenti inclusi in Burp Suite
