Httprint – webserver fingerprinting

***

Ciao a tutti,

eccoci di nuovo tornati a parlare di Finferprinting e questa volta lo faremo a riguardo di un tool molto particolare …l’ HTTPrint.

Httprint è un tool per l’information-gathering di web servers sviluppato dal team Net-Square.

In BackTrack-3.Final è preinstallata la versione 301, in modalità GUI e da linea di comando (le due ovviamente svolgono le stesse funzioni).

Httprint utilizza le caratteristiche dei web servers per identificarli, e tenta di farlo nonostante offuscamenti vari o mediante l’utilizzo di plugins come mod_security o servermask (che servono appunto a mascherare il  web-server in questione).

Il tool, per adempiere a ciò, utilizza delle stringhe di testo che vengono confrontate con le stringhe di risposta ottenute in rete, da ciò scaturisce il risultato; è inoltre molto semplice aggiungere altre stringhe al database predefinito di Httprint modificando il file di testo apposito o utlizzando un database più aggiornato.

***

Per utilizzare il tool in modalità CLI dobbiamo selezionare dal menu Backtrack>Network Mapping>Service Fingerprinting>Httprint
oppure da shell:

______________________________________________________

#cd /pentest/enumeration/www/httprint_301/linux
# httprint

______________________________________________________

Per utilizzare invece la modalità GUI del tool dobbiamo selezionarlo dal percorso:

______________________________________________________

Backtrack –>Network Mapping –> Service Fingerprinting –> Httprint_GUI,

______________________________________________________

Per comodità useremo per il nostro test l’ interfaccia grafica.
La prima cosa che si consiglia di fare prima di utilizzare il tool è di aggiornare il database delle signatures sovrascrivendolo con quello più recente.

Il database lo troviamo nella directory:

/pentest/enumeration/www/httprint_301/linux/

il nome è “signatures.txt”
Scarichiamo il file aggiornato da questo indirizzo: http://www.net-square.com/httprint/signatures.txt
e sovrascriviamolo a quello più datato.
Ora dobbiamo creare il nostro file di input nel quale specificheremo gli obbiettivi che il tool dovrà analizzare.

Il file di input , (input.txt) , si trova nella stessa destinazione di signatures.txt dunque:

/pentest/enumeration/www/httprint_301/linux

Apriamo il file input.txt con l’editor e dovrebbe apparire qualcosa del genere:

***

# inputs for httprint can be:
# – individual IP addresses (default port 80)
# – http://servername:%5Bport%5D/
# – https://servername:%5Bport%5D/
# – IP ranges xx.xx.xx.xx-yy.yy.yy.yy
#
http://www.apache.org/

***

Come possiamo vedere da questo file HTTPrint accetta diversi tipi di input i quali, qualora fossero più di uno, potrebbero essere anche analizzati contemporaneamente dato che ha la possibilità di lavorare su più bersagli in modo parallelo.

Noi faremo delle prove su un solo bersaglio.

L’host da voi designato dunque dovrà essere sovrascritto al posto di http://www.apache.org, noi useremo google.com e apache.org.
Non ci resta che aprire Httprint_GUI. Fatto ciò possiamo notare che Httprint non accetta come input solo files .txt ma anche files di tipo .xml creati dal famoso tool nmap, [(1) – (2)] , è infatti selezionabile questa opzione nella finestra principale; in seguito proveremo anche questa possibilità.
Diamo uno sguardo ora alla parte centrale della GUI dove possiamo osservare le seguenti voci:
Host ; Port ; Banner-Reported ; Banner-Deduced ; Confidence
La prima voce è Host: questa ci darà naturalmente google.com o apache.org, in seguito abbiamo la porta (se non la impostiamo nel nostro file di input manualmente quella di default rimarrà la 80), l’ultima voce sarà il tasso di affidabilità (confidence rating), in questo momento ci indicherà 0 -zero- , perchè ancora non abbiamo iniziato la scansione.
Per iniziare dobbiamo schiacciare il tasto verde nella parte bassa della GUI, ciò farà partire il processo di raccolta informazioni.
Nota: Se hai selezionato bersagli multipli dovrai aspettare un bel pò , ma se vuoi interrompere il processo puoi sempre utilizzare il tasto stop.
Una volta completato dovremmo vedere utilizzati i campi che prima erano vuoti e una finestra popup ci dovrebbe anche informare che il processo è terminato.

Ora dovremmo avere informazioni molto importanti sul nostro bersaglio. Dovremmo avere informazioni sul banner ricevuto , e sul webserver che Httprint ritiene sia il più probabile infine anche qualche info relative all’SSL (se utilizzato).

***

Iniziamo:
Settiamo l’ input file:      z:\pentest\enumeration\www\httprint_301\linux\input.txt
signature file:              z:\pentest\enumeration\www\httprint_301\linux\signatures.txt
e ora il percorso in cui vogliamo salvare il nostro file di report:
z:\root\Desktop\httprintoutput.html
io lo salvo sul desktop.

***

***

Diamo l’avvio col tasto verde
Ecco i risultati:
Banner reported: Apache/2.2.9(Unix)
Banner deduced:  Apache/2.0.x

con una confidence rating del del 78,31%, quindi abbastanza alta.
Dunque le informazioni ricevute direttamente dal server web ci dicono che esso è un Apache 2.2.9 mentre il nostro Httprint  in base al confronto fra le stringhe di testo ricevute e quelle presenti nel suo database ci dice che il server è un  Apache 2.0.x. Risultato soddisfacente considerando l’alto tasso di confidence rating, l’unica divergenza è la versione che oscilla tra la 2.0 e la 2.2, cosa del tutto naturale considerando che quando si fa un fingerprinting è quasi impossibile avere la certezza matematica di ciò con cui si ha a che fare.
Questo è il report file:

***

***

Ora facciamo una prova utilizzando un file di output di nmap:
Il comando di input che darò a nmap sarà il seguente:

#nmap http://www.google.com -p 80 -oX /root/aaa.xml

L’ host che utilizzeremo sarà: http://www.google.com , la porta sarà la 80, il file creato si chiamerà aaa.xml e la sua destinazione sarà nella cartella root/

***

***

Apriamo a questo punto Httprint_GUI e selezioniamo “nmap nella parte dedicata all’input file, premiamo il tasto sfoglia e selezioniamo il file aaa.xml , infine col tasto “load” lo carichiamo.

L’unica cosa da fare a questo punto sarà premere il tasto verde di avvio.
Una volta terminato possiamo constatare che , mettendo in correlazione la stringa catturata e quelle del nostro database, Httprint ipotizza che il web-server da noi analizzato possa essere un WebSitePro/2.3.18 , con un tasso di affidabilità del 39,76% , dunque non molto affidabile.

Solo al secondo posto troviamo come risultato gws , (google web server) , cioè l’informazione che abbiamo ottenuto direttamente dal server che stavamo analizzando (come si può vedere dalla foto in basso).

In questo caso credo che il secondo sia il risultato più accreditabile dato che tutti sanno che google.com utilizza web-server del tipo gws (web-server particolari per far fronte all’enorme traffico di cui è oggetto).

***

***

Possiamo aprire a questo punto il “Report File” che dovrebbe fornirci qualche info in più.
Alla prossima.

SinFP -alternative OS fingerprinting-

***

Ciao a tutti , ecocci di nuovo a scrivere su un altro tool in BackTrack , il SinFP. utilizzato per il Network Mapping.

SinFP è un tool scritto in PERL utilizzato per l’OS fingerprinting, sia attivo che passivo.

In pratica , per coloro che ancora devono avvicinarsi alle caratteristiche di un programma come quello che stiamo per descrivervi , SinFP è uno di quei programmi inseriti in BackTrack che serve per ottenere informazioni su di un determinato host , più precisamente ci mette in condizioni di sapere il tipo di sistema operativo che gira sull’ host che si va a “scannerizzare”.

È importante dire che ci sono 2 tipi di Fingerprinting , il fingerprinting attivo , ovvero quello che viene fatto durante l’ attivita del sistema preso come esempio… …ed il fingerprinting passivo , quello che viene fatto per capire il sistema operativo di un determinato host , mentre lo stesso non è in attività , infatti , come anche in quest’ esempio fatto tramite Wireshark , ci si serve di un file catturato precedentemente con un programma di sniffing.

Secondo i fautori del tool , questo sarebbe in grado di bypassare le limitazioni del più famoso e utilizzato Nmap. Come tutti sappiamo Nmap è stato utilizzato per questo scopo da anni in modo efficiente ma , oramai, con con la presenza sempre più assidua di dispositivi di filtraggio , configurazioni PAT/NAT e altre strategie utilizzate, l’approccio utilizzato dal famoso tool nel fare OS fingerprinting sta diventando obsoleto. Dunque, detto questo, SinFP basa la sua filosofia proprio su queste limitazioni e quindi getta tra le sue basi proprio il fatto di fare OS fingerprinting in modo dissimile da Nmap e altri.

Il tool richiede dunque soltanto una porta TCP aperta che sarà l’unica responsabile del risultato ottenuto dalla scansione; SinFP invia dei pacchetti TCP standard e limita i test effettuati sul sistema da scansionare a 2-3, anche se secondo lo sviluppatore SinFP sarebbe in grado di riconoscere il sistema già al primo responso dei pacchetti TCP inviati.
Di seguito stiliamo una lista di varie caratteristiche della versione 2 del tool, molte di queste caratteristiche sono viste come confronto alla versione 1 dello stesso.
-completamente riscritto (rispetto alla 1);
-sinfp.db completamente rielaborato;
-nuovi metodi basati sul confronto tra l’invio di pacchetti e la risposta ottenuta;
-nuovi algoritmi di confronto che lavorano come un motore di ricerca;
-possibilità di cambiare un algoritmo di confronto passando al tool manualmente una
“matching mask”;
-passive OS fingerprinting molto accurato grazie ai nuovi algoritmi;
-Possibilità di inviare pacchetti P1P2P3, o solamente P1P2 o ancora solo P2;
-consente di utilizzare l’IPv6 mentre la versione 1 non lo consentiva;
-cambiamenti all’ API, non compatibili con la versione precedente;
-cambiamenti allo schema del DB, anche questa incompatibile con la versione precedente;
-Molti bug corretti;

***

La sintassi utilizzata per il corretto funzionamento del tool è la seguente:

/usr/local/sinfp/bin/sinfp.pl -i <targetIp> -p <openTcpPort>

dove:
-i istruisce il programma che in seguito sarà riportato un indirizzo ip, mentre
-p indica al tool quale porta tcp aperta utilizzare per portare a termine il fingerprinting.

Vediamo ora le opzioni che possono essere utilizzate con questo tool:
-3 -> quello di default, invia 3 pacchetti;
-2 -> invia soltanto 2 pacchetti (P1 e P2) (modo silenzioso);
-1 -> invia soltanto un pacchetto (P2) (modalità molto silenziosa);
-v -> è il verbose mode cioè il tool ci informa in tempo reale su cosa sta lavorando;
-s <file> -> è il signature file da usare;
-C -> Stampa tutte le info possibili sul sistema “vittima”;
-O -> Ci mostra invece soltanto il sistema operativo;
-V -> Ci stampa il sistema operativo e a quale famiglia appartiene la sua versione;
-H -> usa masks HEURISTIC2 per abbinare le signature (indicato per utenti avanzati)
-A <mask1,mask2,…> -> permette di utilizzare una lista personalizzata di masks
per il confronto (anche questo indicato per utenti avanzati).
Parametri specifici per modalità online:
-k -> conserva il file pcap generato;
-a -> non generare una traccia anonima del file pcap;
Parametri specifici per modalità offline:
-f <file> -> nome del file pcap da analizzare
Parametri specifici per IPv6:
-6 -> utilizza il fingerprinting IPv6 invece dell’ IPv4
-M <mac> -> MAC address sorgente da utilizzare;
-m <mac> -> MAC address vittima da utilizzare;
-4 -> questa opzione ci permette di utilizzare l’IPv4 se non va a buon fine quello
con IPv6;
Parametri specifici della modalità “attivo”:
-r <N> -> numero di prove da effettuare per ogni test (3 di default);
-t <N> -> timeout prima di considerare perduto un pacchetto (3 di default);
Parametri specifici della modalità “passivo”:
-P -> istruisce il tool di effettuare un fingerprinting passivo;
-F <filter> -> filtro pcap;

***

Vediamo ora un esempio di OS fingerprinting attivo utilizzando un ip che presenta la porta tcp 80 aperta (scan eseguito con nmap -> status open)…

bt sinfp # /usr/local/sinfp/bin/sinfp.pl -i 78.13.252.72 -p 80

P1: B11113 F0x12 W16616 O0204ffff M1412
P2: B11113 F0x12 W16944 O0204ffff010303000101080a000000000000000001010402 M1412
P3: B11021 F0x04 W0 O0 M0
IPv4: BH0FH0WH1OH0MH1/P1P2P3: Windows: Windows: 2000
IPv4: BH0FH0WH1OH0MH1/P1P2P3: Windows: Windows: XP

*** File [sinfp4-127.0.0.1.anon.pcap] generation done.
*** Please send it to sinfp@gomor.org if you think this is not
*** the good identification, or if it is a new signature.
*** In this last case, please specify `uname -a’ (or equivalent)
*** from the target host.

Come possiamo leggere dal risultato riportatoci dal nostro tool abbiamo inviato 3 pacchetti e cioè P1,P2 e P3 (come di default per giunta) e abbiamo ricevuto dunque in base a questi pacchetti 3 risposte che il tool ci ha anche stampato. Dunque in base all’abbinamento fatto da SinFP confrontando le risposte con i dati contenuti nel suo database è giunto alla conclusione che la “vittima” è dotata di un sistema della famiglia windows e. in particolare possiede o windows 2000 o windows XP.

Ora eseguiamo un’altra prova su un ip che che presenta la porta 22 aperta (come l’esempio di prima anche questo fingerprinting è di tipo attivo).

bt sinfp # /usr/local/sinfp/bin/sinfp.pl -1 -v -O -i 78.14.40.211 -p 22
DEBUG: using db: /usr/local/sinfp/bin/../db/sinfp.db
DEBUG: DescL3: dev: [ppp0]
DEBUG: DescL3: ip: [79.9.159.145]
DEBUG: DescL3: mac: [ff:ff:ff:ff:ff:ff]
DEBUG: DescL3: ip6: [::1]
DEBUG: DescL3: gatewayIp: [0.0.0.0]
DEBUG: Frame: DescL3 object created
DEBUG: Dump: will run in mode: 0
DEBUG: Dump: dev: [ppp0]
DEBUG: Dump: file: [sinfp4-78.14.40.211.22.pcap]
DEBUG: Dump: filter: [host 78.14.40.211 and host 79.9.159.145 and tcp and port 22 and (port 41568)]
DEBUG: Frame: send: l3: protocol:6, size:60, 79.9.159.145 => 78.14.40.211
DEBUG: Frame: send: l4: TCP, 41568 => 22
DEBUG: Frame: Reply received
P2: B10113 F0x12 W5792 O0204ffff0402080affffffff4445414401030300 M1412
IPv4: Linux
DEBUG: Dump: will run in mode: 1
DEBUG: Dump: will run in mode: 2

*** File [sinfp4-127.0.0.1.anon.pcap] generation done.
*** Please send it to sinfp@gomor.org if you think this is not
*** the good identification, or if it is a new signature.
*** In this last case, please specify `uname -a’ (or equivalent)
*** from the target host.
DEBUG: Dump: Frames received : 6
DEBUG: Dump: Frames dropped : 0
DEBUG: Dump: Frames if dropped: 0
DEBUG: Dump: sinfp4-78.14.40.211.22.pcap removed

In questo caso per dimostrare la funzionalità del tool abbiamo aggiunto altre opzioni nella nostra ricerca.
Cioè SinFP invierà un solo pacchetto (1), attiverà il verbose mode (-v) e ci dirà soltanto il sistema operativo identificato (-O).
Dunque leggiamo il risultato:
La porta utilizzata è la 22, il pacchetto inviato è il P2, la risposta è stampata e dunque il nostro tool l’ha associata a un sistema operativo linux (stampato alla 16° riga).

Eseguiamo una nuova prova utilizzando questa volta la tecnica del OSfingerprinting passivo e cioè mediante un file di sniffing. Il file in questione è stato editato da WireShark , tool che sicuramente molti di voi conosceranno; è bene che sappiate che quando salvate il file da Wireshark selezionate il tipo “modified tcpdump/libcap”, o almeno così ho fatto io, altrimenti il nostro tool SinFP potrebbe non leggerlo correttamente e non prenderlo come input valido.

bt sinfp # /usr/local/sinfp/bin/sinfp.pl -P -f /root/Desktop/capture.pcap

209.85.135.147:80 > 79.9.159.145:53224 [SYN|ACK]
P2: B11011 F0x12 W5672 O0204ffff0402080affffffffffffffff01030306 M1412
IPv4: BH1FH0WH1OH0MH1/P2: GNU/Linux: Linux: 2.6.x

209.85.135.147:80 > 79.9.159.145:53225 [SYN|ACK]
P2: B11011 F0x12 W5672 O0204ffff0402080affffffffffffffff01030306 M1412
IPv4: BH1FH0WH1OH0MH1/P2: GNU/Linux: Linux: 2.6.x

209.85.135.147:80 > 79.9.159.145:53226 [SYN|ACK]
P2: B11011 F0x12 W5672 O0204ffff0402080affffffffffffffff01030306 M1412
IPv4: BH1FH0WH1OH0MH1/P2: GNU/Linux: Linux: 2.6.x

209.85.135.147:80 > 79.9.159.145:53227 [SYN|ACK]
P2: B11011 F0x12 W5672 O0204ffff0402080affffffffffffffff01030306 M1412
IPv4: BH1FH0WH1OH0MH1/P2: GNU/Linux: Linux: 2.6.x

209.85.135.147:80 > 79.9.159.145:53228 [SYN|ACK]
P2: B11011 F0x12 W5672 O0204ffff0402080affffffffffffffff01030306 M1412
IPv4: BH1FH0WH1OH0MH1/P2: GNU/Linux: Linux: 2.6.x

Vediamo che il nostro tool confrontando le varie risposte con il database in suo possesso è riuscito a capire che in questo specifico caso ha avuto a che fare con sistemi dotati di distribuzioni linux e con il kernel 2.6 .

Per concludere facciamo una ulteriore prova per verificare se il nostro tool sia in grado di riconoscere sistemi della famiglia FreeBSD (visto che i riconoscimenti di linux e windows sono stati portati a termine con successo), per fare ciò utilizziamo il sito di FreeBSD e cioè http://www.freebsdfoundation.org.

Il fingerprinting che utilizzeremo sarà di tipo passivo e il file catturato è stato creato come prima da WireShark.

bt sinfp # /usr/local/sinfp/bin/sinfp.pl -P -f /root/Desktop/capture.pcap

87.13.247.89:57951 > 69.147.83.42:80 [SYN]
P2: B11110 F0x12 W5808 O0204ffff0402080affffffff0000000001030305 M1452
IPv4: unknown

69.147.83.42:80 > 87.13.247.89:57951 [SYN|ACK]
P2: B11111 F0x12 W65535 O0204ffff010303010101080affffffffffffffff04020000 M1412
IPv4: BH0FH0WH0OH0MH1/P2: BSD: FreeBSD: 6.0
IPv4: BH0FH0WH0OH0MH1/P2: BSD: FreeBSD: 6.1
IPv4: BH0FH0WH0OH0MH1/P2: BSD: FreeBSD: 6.2

87.13.247.89:60373 > 64.147.173.80:80 [SYN]
P2: B11110 F0x12 W5808 O0204ffff0402080affffffff0000000001030305 M1452
IPv4: unknown

87.13.247.89:55535 > 66.249.91.115:443 [SYN]
P2: B11110 F0x12 W5808 O0204ffff0402080affffffff0000000001030305 M1452
IPv4: unknown

64.147.173.80:80 > 87.13.247.89:60373 [SYN|ACK]
P2: B11111 F0x12 W65535 O0204ffff010303000101080a000000000000000001010402 M1300
IPv4: BH0FH0WH0OH0MH1/P2: Windows: Windows: 2000
IPv4: BH0FH0WH0OH0MH1/P2: Windows: Windows: XP

87.13.247.89:41187 > 66.211.168.209:443 [SYN]
P2: B11110 F0x12 W5808 O0204ffff0402080affffffff0000000001030305 M1452
IPv4: unknown

66.249.91.115:443 > 87.13.247.89:55535 [SYN|ACK]
P2: B11011 F0x12 W5672 O0204ffff0402080affffffffffffffff01030306 M1412
IPv4: BH1FH0WH1OH0MH1/P2: GNU/Linux: Linux: 2.6.x

66.211.168.209:443 > 87.13.247.89:41187 [SYN|ACK]
*** WARNING: not enough TCP options for P2 reply, result may be false
P2: B11011 F0x12 W8190 O0204ffff M1380
IPv4: BH0FH0WH0OH0MH1/P2: Unknown: GoogleOS: unknown

E’ chiaro che SinFP ha riconosciuto anche sistemi operativi del tipo FreeBSD e ci dice che il sistema con cui abbiamo avuto a che fare è dotato di una delle 3 versioni stampate. Gli altri risultati presenti nel report sono altri dati raccolti dallo sniffing e li ho voluti riportare perchè ho pensato sarebbe stato più opportuno pubblicare il risultato integralmente.

Come possiamo vedereSinFP ha fatto il proprio dovere davvero bene e secondo il mio modestissimo parere non è secondo davvero a nessuno, infatti SinFP in tutte le circostanze si è comportato egregiamente non manifestando alcun tipo di problema.

Ciao a tutti e alla prossima.