My Blog

Molti sono i malintenzionati che navigano la rete, in alcuni casi disturbandoci non poco.



Un caso tipico è rappresentato da navigatori che, confusi nell'immensa folla di visitors dei nostri popolarissimi website, si avvicinano con l'intento inconfessabile di scardinare le nostre difese.
Capita allora di ritrovare nei nostri log dei segni del passaggio di questi scassinatori: insistenti richieste di pagine relative a qualche vulnerabilità applicativa più o meno nota, tentativi di SQL injection e via dicendo. E' abbastanza ovvio che è nostro interesse individuare questi tentativi di exploit, sia per difenderci che per porre una pezza nel caso in cui l'attacco sia andato (purtroppo per noi) a buon fine.
La ricerca dei segni di scasso non è sempre facile, qui di sotto elenchiamo alcune situazioni frequenti.
Come al solito, se qualcuno vuole suggerire o proporre casi specifici o comunque non contemplati, può comunicarceli attraverso i commenti.
Consultando i file di log di apache potrebbero insospettirci delle richieste aventi una o più delle caratteristiche seguenti:

• URL richiesta estremamente lunga.
• Presenza nella URL di parole tipiche delle query SQL.
• Richiesta insistita e non giustificata di un file.

Vediamo come fare ad individuare queste situazioni.
Utilizzeremo un file di log Combined di apache.

URL richiesta estremamente lunga.
E' forse la condizione più difficile da verificare, in quanto si tratta di stabilire, volta per volta, cosa intendiamo quando diciamo estremamente lunga. Per poterlo fare abbiamo bisogno di conoscere piuttosto bene il website.
In un website semplice, con pochi annidamenti di directory, già richieste lunghe un centinaio di caratteri potrebbero essere eccessive. E' da considerare però che vanno conteggiate tra i caratteri della richiesta anche le stringhe relative ai parametri GET e questi potrebbero contribuire molto alla lunghezza totale.
Un modo empirico per misurare [aggiungi]
In ogni caso, una volta che stabiliamo con sufficiente approssimazione cos'è estremamente lungo nel nostro caso, possiamo isolare le richieste sospette in questo modo:

cat mywebsite_access.log |awk '{if(length($7) > [LENGTH]){print $7}}'|sort|uniq -c | sort -nr


dove sostituiamo a  [LENGTH]  la lunghezza in caratteri.

Presenza nella URL di parole tipiche delle query SQL.
In molti casi gli applicativi sono vulnerabili alla SQL injection: con questo attacco si include nella URL - con particolari modalità che variano di volta in volta a seconda dell'applicativo - uno statement SQL che può avere diversi scopi

• Ottenere informazioni sulla struttura del DB.
• Modificare i dati presenti sul DB e di conseguenza sulle pagine dinamiche in modo da ottenere un defacing o l'aggiunta di codice malevolo alla pagina del sito violato.
• Creare un Dos con query pesanti o cancellando dati.

Un modo per individuare la maggior parte di questi attacchi è il seguente:

cat mywebsite_access.log | egrep -i '(select|update|insert|delete|alter table|drop table|drop database)'

Naturalmente dobbiamo aspettarci molti falsi positivi, vista la genericità dei termini usati, soprattutto le prime quattro parole. Per ovviare al problema si potrebbe affinare la ricerca spezzandola in questo modo:

cat mywebsite_access.log | egrep -i '(select|update|insert|delete|alter table|drop table|drop database)'
cat mywebsite_access.log | egrep -i '(select|update|insert|delete)'|egrep -i '(from|set|into)'

in modo da matchare solo le stringhe che contengono i termini associati alle query di select, update eccetera.

Richiesta insistita e/o non giustificata di un file.
L'ultimo caso di studio di questa brevissima trattazione riguarda le richieste di un particolare file, sia esso esistente o meno: in alcuni casi gli attaccanti sondano il sito alla ricerca di vulnerabilità note, richiedendo nomi tipici di file che sanno essere vulnerabili a qualche attacco.
Visto che siamo bravi amministratori di sistema appena scopriamo che il nostro sito ha delle potenziali vulnerabilità, ci interessa sapere se i file vulnerabili sono stati richiesti da qualcuno.
Questi attacchi (quando falliscono) sono spesso ben visibili dalle statistiche del sito, dove magari vediamo un ingiustificato numero di 404 (file not found). Se però non abbiamo ancora a disposizione le statistiche e abbiamo motivo di sospettare che qualcosa di strano stia accadendo, dobbiamo andare ad interpellare direttamente il file di log.
Possiamo lanciare il seguente comando:
cat mywebsite_access.log |awk '{if($7=="vulnus.php")print $1}'|sort|uniq -c

In questo modo vediamo gli IP di chi ha richiesto il file e la frequenza con cui è stato chiesto.