Introduzione
Ci sono moduli web ovunque su Internet. Anche i siti che di solito non consentono agli utenti regolari di accedere hanno probabilmente un'area di amministrazione. È importante quando si esegue e si distribuisce un sito per assicurarsi che le password che accedono ai controlli sensibili e ai pannelli di amministrazione siano il più sicure possibile.
Esistono diversi modi per attaccare un'applicazione Web, ma questa guida tratterà l'utilizzo di Hydra per eseguire un attacco di forza bruta su un modulo di accesso. La piattaforma di destinazione preferita è WordPress. È facilmente la piattaforma CMS più popolare al mondo ed è anche nota per essere gestita male.
Ricorda, questa guida ha lo scopo di aiutarti a proteggere il tuo WordPress o un altro sito web. L'utilizzo su un sito che non possiedi o di cui disponi dell'autorizzazione scritta per eseguire il test è illegale .
Preparazione
Prima di fare qualsiasi cosa, avrai bisogno di un sito Web WordPress come target. Questa guida presuppone anche che tu stia ospitando il sito WordPress sul tuo computer. Se hai bisogno di aiuto per configurare LAMP sulla tua macchina, consulta le nostre guide Debian LAMP e Ubuntu LAMP.
Puoi farlo su una normale installazione di Linux o su un'installazione di Kali Linux. Se stai usando Kali, segui Debian LAMP dalla guida ai sorgenti. Assicurati solo di avere Hydra e cURL installati su qualsiasi sistema tu scelga. Sono disponibili nella maggior parte dei repository.
Se davvero non vuoi usare la tua installazione normale, puoi sicuramente usare un'altra macchina, basta inserire l'IP di destinazione per localhost e assicurarti che la macchina di destinazione sia accessibile da quella attaccante.
Raccolta di informazioni
Una volta che WordPress è attivo e funzionante, è il momento di trovare quante più informazioni possibili sull'installazione a cui ti rivolgerai. Ciò significa scoprire come viene creato il modulo di accesso, cosa succede quando lo invii e, eventualmente, dove va se l'accesso va a buon fine.
Sorgente HTML
Inizia navigando alla pagina di accesso. Puoi trovarlo su localhost/wp-login.php . Usa la capacità del tuo browser per ispezionare il codice sorgente. Puoi semplicemente fare clic con il pulsante destro del mouse in un punto qualsiasi della pagina e selezionare "Visualizza sorgente" o "Ispeziona elemento". In entrambi i modi puoi visualizzare la fonte, verrà semplicemente visualizzata in modi diversi.
Cerca intorno al centro del codice. Stai cercando i tag. Questo è il modulo di accesso effettivo. All'interno di quel modulo ci sono un paio di informazioni di cui hai bisogno.
Prima di raccogliere le informazioni, controlla se il modulo invia una richiesta GET o POST. Nella prima riga del modulo, dovrebbe esserci un'opzione del metodo simile a questa:method="post" . Nel caso di WordPress, è un POST.
Innanzitutto, trova l'input del nome utente. Dovrebbe assomigliare alla linea qui sotto.
<input type="text" name="log" id="user_login" class="input" value="" size="20" />
La parte di cui hai bisogno è il name . In questo caso, è log .
Quindi, trova la password inserita. Dovrebbe essere simile.
<input type="password" name="pwd" id="user_pass" class="input" value="" size="20" />
Ancora una volta, trova il name che è pwd .
Devi anche identificare il pulsante di invio in modo che Hydra possa inviare il modulo.
<input type="submit" name="wp-submit" id="wp-submit" class="button button-primary button-large" value="Log In" />
È importante registrare sia il name e il value .
C'è un ultimo pezzo. Se non te ne sei accorto, ci sono due campi nascosti nella parte inferiore del modulo. Uno dice a WordPress di reindirizzare quando il modulo viene inviato e l'altro è un cookie che WordPress cercherà quando il modulo viene inviato. Hai bisogno del cookie.
<input type="hidden" name="testcookie" value="1" />
Ancora una volta, prendi nota del name e value .
cURL
Anche se c'erano molte informazioni da ottenere guardando il sorgente HTML, ci sono alcune altre cose che devi sapere prima di lanciare Hydra. Nella maggior parte dei casi, tuttavia, potresti essere in grado di eseguire il test solo con le informazioni raccolte. Dovresti semplicemente tentare di accedere con credenziali errate, registrare il messaggio di errore e utilizzare quel messaggio come condizione di test non riuscita in Hydra.
Tuttavia, WordPress è progettato in modo diverso e non c'è davvero un buon modo per testare con tentativi di accesso falliti. Per questo motivo, è necessario verificare un accesso riuscito. Perché puoi mantenere la tua installazione di WordPress e accedere it, questo non farebbe differenza se stessi testando un sistema per un client. La condizione che trovi localmente dovrebbe essere universale per WordPress.
C'è anche un'altra ruga qui. Ricordi il campo di reindirizzamento nascosto nel modulo? Bene, quel reindirizzamento ti impedisce di utilizzare una condizione come la presenza della parola "Dashboard", anche per testare il successo. Dovrai dare un'occhiata alla richiesta stessa e, per questo, c'è cURL.
Per fare un confronto, devi prima vedere la pagina di accesso originale con cURL.
$ curl -v http://localhost/wp-login.php
La maggior parte delle informazioni è la stessa del codice sorgente che hai guardato nel browser. In alto, però, ci sono le informazioni sulla richiesta HTTP. Prendere nota di queste informazioni. Dovrai confrontarlo con un accesso riuscito.
La prossima cosa che devi fare è accedere con successo con cURL. Per fare ciò, avrai bisogno del cookie della richiesta precedente. Dai un'occhiata ai dati HTTP e individua una riga simile a quella qui sotto.
< Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/
Avrai bisogno del wordpress_test_cookie=WP+Cookie+check parte.
Bene, ora avrai bisogno delle informazioni che hai raccolto dall'HTML insieme a quel cookie per effettuare la richiesta. Ecco come dovrebbe essere.
curl -v --data 'log=username&pwd=realpassword&wp-submit=Log+In&testcookie=1' --cookie 'wordpress_test_cookie=WP+Cookie+check' http://localhost/wp-login.php
Quindi, hai la stessa richiesta di base di prima, ma questa volta stai usando il --data flag e il --cookie flag per passare cURL con i dati del modulo con cui desideri interagire e quel cookie, in modo che il modulo venga effettivamente inviato.
Quella stringa di dati, log=username&pwd=realpassword&wp-submit=Log+In&testcookie=1 corrisponde direttamente alle informazioni che hai raccolto dall'HTML. Sta dicendo di inserire il valore "nome utente" nell'input chiamato log e il valore "realpassword" nell'input chiamato pwd . Assicurati di utilizzare il nome utente e la password effettivi per accedere. Quindi, utilizza l'invio con il nome wp-submit e un valore di Log In per trasmettere i dati. Alla fine c'è testcookie con un valore di 1 . Questo sta solo dicendo a cURL di inviarlo insieme al resto dei dati del modulo.
Quando cURL completa la richiesta, in realtà non vedrai alcun codice HTML, solo molte informazioni sulla richiesta. Ricordi quel reindirizzamento che ha reso i test con "Dashboard" non funzionanti come condizione di test? Bene, ora il reindirizzamento stesso sarà la condizione di test. Dai un'occhiata alla riga qui sotto.
< Location: http://localhost/wp-admin/
Quella riga non era nella richiesta precedente. Inoltre, non contiene alcuna informazione specifica relativa a quell'utente o accesso. Ciò significa che sarà sempre essere presente durante un accesso riuscito a WordPress, il che lo rende la perfetta condizione di successo con cui testare.
Test con Hydra
Infine, hai tutto ciò di cui hai bisogno per testare le tue password con Hydra. Il punto di questa guida non è tanto quello di coprire la sintassi di Hydra, ma analizzerà il comando utilizzato. Se vuoi saperne di più su Hydra, dai un'occhiata alla guida SSH che approfondisce molto di più.
C'è davvero un solo comando di cui hai bisogno affinché Hydra esegua possibili nomi utente e password per testare la sicurezza del tuo sito WordPress. La cosa più semplice da fare è dare un'occhiata al comando e scomporlo.
$ hydra -L lists/usrname.txt -P lists/pass.txt localhost -V http-form-post '/wp-login.php:log=^USER^&pwd=^PASS^&wp-submit=Log In&testcookie=1:S=Location'
Ok, quindi questo è ovviamente molto da prendere in una volta. Il -L flag dice a Hydra di usare una lista di nomi utente in lists/usrname.txt . Allo stesso modo, il -P flag dice a Hydra di usare un elenco di parole d'ordine in lists/pass.txt . localhost dice a Hydra di scegliere come target localhost e -V gli dice di registrare ogni test nell'output della console.
Il resto del comando si occupa della richiesta HTTP stessa. http-form-post attiva il modulo Hydra per la gestione dei moduli HTTP con un metodo POST. Ricorda da prima che il modulo di accesso di WordPress è di fronte a un POST da. La stringa che segue contiene tutti i parametri che Hydra utilizzerà. Dovresti notare che è molto simile a quello utilizzato per accedere tramite cURL.
La stringa è composta da diverse sezioni separate da : . La prima parte è l'indirizzo esatto che viene testato, /wp-login.php . La parte successiva è quasi esattamente come quella usata da cURL. Passa i valori nel modulo e lo invia, incluso il cookie. Invece di passare valori letterali, Hydra sta effettivamente usando variabili. Avviso in log=^USER^ e pwd=^PASS^ . Quelle sono variabili separate dal carattere carota che prendono i valori dalle liste di parole e li trasmettono nella richiesta per ogni test eseguito da Hydra.
L'ultimo pezzo della stringa è la condizione di test. S significa che sta testando il successo. Se volessi testare il fallimento, utilizzeresti F . Lo imposti uguale alla parola o alla frase per cui sta testando. Pensa se è quasi come grep .
Quando lo esegui, dovresti ottenere un risultato positivo, a condizione che il nome utente e la password corretti siano negli elenchi di parole che hai fornito a Hydra.
Pensieri conclusivi
Prima di tutto, congratulazioni per aver superato tutto questo. Se ce l'hai fatta, ora hai un metodo solido per testare la sicurezza della password dei tuoi account utente WordPress.
Questa guida è stata adattata per WordPress, ma puoi facilmente seguire gli stessi passaggi per testare altri moduli web. Se esegui un'applicazione Web con più utenti, è sicuramente una buona idea assicurarsi
che utilizzino password complesse. Questo può aiutare a informare la tua politica sulla password. Ancora una volta, assicurati di testare sempre solo con il permesso.