Archivi tag: http 404

Swatch ed HTTP 404 (not found)

Premessa

Swatch monitora attivamente tutte le richieste dirette ai miei server Web, quindi qualunque tentativo di accesso ad una particolare pagina viene loggato.

Problema

Ultimamente le richieste verso una particolare URL sono aumentate a dismisura. Ecco uno stralcio degli alert generati dal suddetto tool:

201.157.16.123 - - [06/Aug/2012:01:28:55 +0200] "GET /vtigercrm/modules/com_vtiger_workflow/sortfieldsjson.php?module_name=../../../../../../../..//etc/amportal.conf%00 HTTP/1.1" 404 2089 "-" "-"

201.22.125.163 - - [06/Aug/2012:00:03:58 +0200] "GET /vtigercrm/modules/com_vtiger_workflow/sortfieldsjson.php?module_name=../../../../../../../..//etc/amportal.conf%00 HTTP/1.1" 404 2089 "-" "-"

77.54.223.3 - - [05/Aug/2012:22:13:00 +0200] "GET /vtigercrm/modules/com_vtiger_workflow/sortfieldsjson.php?module_name=../../../../../../../..//etc/amportal.conf%00 HTTP/1.1" 404 2089 "-" "-"

95.229.250.152 - - [05/Aug/2012:20:59:13 +0200] "GET /vtigercrm/modules/com_vtiger_workflow/sortfieldsjson.php?module_name=../../../../../../../..//etc/amportal.conf%00 HTTP/1.1" 404 2089 "-" "-"

 

elastix, amportal.conf, directory traversal, input sanitiziation, php vulnerability, querystring, swatch, http 404

Trattasi palesemente di un attacco directory traversal, data la sintassi ../../../../../../../../ utilizzata nella URL, che consente all’attaccante di accedere alla directory /etc ed in particolare al file di configurazione amportal.conf

Tale attacco può essere attuato grazie ad una vulnerabilità specifica che affligge la distro Elastix, in particolare il CRM Vtiger. La vulnerabilità consiste nell’uso errato delle procedure di input sanitization, che consente l’uso dei caratteri . e / all’interno della querystring (espressi in URL encoding), in modo da eseguire la “scalata” delle directory fino ad arrivare al file di configurazione target.

Soluzione

Aggiornare il pacchetto elastix-vtigercrm alla versione 5.2.1-5.

Alla prossima.

Apache, swatch e favicon inesistente

Premessa: i browser di ultima generazione che tantano di connettersi ad un sito (non presente nella loro cache) vanno automaticamente alla ricerca della famigerata favicon (ovvero quell’iconcina che appare a fianco della barra degli indirizzi – benedetto Web 2.0).

swatch, log, apache, favicon, http 404, not found, log monitoring

Fatto: se il sito non contiene la suddetta iconcina, il Web server (Apache nella fattispecie), genererà un bell’errore HTTP 404 (not found).

Problema: se il file di log del Web server è monitorato mediante un’apposita applicazione (leggasi swatch), che intercetta gli errori HTTP 404, il povero sistemista che legge gli alert (leggasi il sottoscritto), si ritroverà con un kg di mail praticamente inutili.

Soluzione: fare in modo che swatch ignori completamente le entry del file di log di Apache che contencono la keyword favicon.

In particolare, tali entry avranno la seguente forma:

79.5.*.* - - [29/May/2012:13:57:45 +0200] "GET /favicon.ico HTTP/1.1" 404 628 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.4) Gecko/20100101 Firefox/10.0.4"

indi per cui, nel file di configurazione di swatch basterà aggiungere la seguente direttiva (in testa):

#Favicon
ignore /favicon/

Niente di più facile.

Per rendere la modifica operativa occorre killare tutti i processi attivi di swatch (sudo killall -w swatch) e successivamente avviare nuovamente tale applicativo.

Alla prossima.

Script kiddie ed errore HTTP 404: tiriamo le somme

Non è certamente un caso che abbia configurato swatch in modo da tenere d’occhio anche gli errori HTTP 404 (Not Found). In questo modo ho potuto “registrare” in un file apposito tutti i tentativi di cracking perpetrati contro i miei server Web, individuando quali sono le URL cercate dai lamer di turno.

Ecco le 2 entry più significative:

 211.191.168.214 - - [26/Dec/2011:21:01:57 +0100] "GET /admin/Y-ivrrecording.php?php=info&ip=uname HTTP/1.1" 404 2050 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9) Gecko/2008052906 Firefox/3.0"

173.243.121.58 - - [06/Jan/2012:19:54:16 +0100] "GET /admin/config.php HTTP/1.1" 404 2041 "-" "Python-urllib/2.4"

Nel primo caso hanno verificato la presenza di FreePBX sulla mia macchina (ovviamente con interfaccia di management in forwarding e dunque accessibile dall’esterno).

Nel secondo caso, invece, hanno controllato se sul mio server fosse presente l’interfaccia di gestione relativa a trixbox. Ho optato per trixbox (anzichè PHPMyAdmin), in quanto, dopo aver lanciano un nmap avente come target l’IP sorgente loggato, la porta TCP 443 (HTTPS) risultava in ascolto e proprio grazie ad essa era raggiungibile l’interfaccia Web di trixbox. Si trattava quindi di una testa di ponte.

Inoltre, dallo User Agent (Python-urllib/2.4) si può avere la certezza che si tratta di uno scrip (editato in Python), il cui compito è quello di scansionare range di IP alla ricerca di macchine vulnerabili.

Tra qualche mese vedrò di stilare un nuovo report.

A presto.