Perdí una máquina

Con esto de la remotidad, hemos todos tenido problemas nuevos.

El siglo pasado me ocurrió al estar operando en un servidor que lo apagué de modo remoto pero estaba en otra ubicación, por suerte era a pocas cuadras.

Lo que ocurrió esta vez es que en la oficina tengo una máquina, con la IP fijada por DHCP. ¿Qué significa esto? Que aunque en su configuración local no tiene IP fija, el servidor de DHCP recuerda la MAC Address y me asigna siempre la misma IP. Esto es vital para que la pueda encontrar en modo remoto.

Por algún motivo que desconozco, no puedo acceder pese a que me consta que está prendida y conectada pues una persona tuvo la gentileza de ir a fijarse.

¿Qué puedo hacer? Si supiera la MAC Address, avisarle a quien administra el DHCP para que restaure la regla si es que se ha ido.

También, si pudiera acceder a una máquina en la misma red, asignarle en esa máquina esa MAC Address a una IP libre arbitraria, de esta manera:

$ arp -s 192.168.1.200 14:de:39:16:a0:57

Luego, independientemente de que dirección tenga, llegaría con:

$ ssh 192.168.1.200

Si no me creés, hacés bien. Dije lo anterior pues estoy completamente seguro que había dispositivos que para conectarte por primera vez tenías que hacer eso, pero por las dudas he comprobado el procedimiento y no funciona.

El rojo representa la temperatura del horno

 

Para averiguar la MAC hay varias opciones

• fijarse en la etiqueta del gabinete.
• averiguar el nombre del puerto en el que está conectado y pedirle a quien administra los switches que se fije.
• entrar una vez y consultarle al sistema operativo 

Para hacerla difícil, optaré por la última. Pero si no sé la IP...

• Puedo fijarme en otra máquina desde la que me haya conectado la firma del servidor conservada y consultar a cada máquina que tenga SSH la firma a ver cuál coincide.
• Puedo barrer todas las IP de la red intentando entrar
  

Barrer y que un equipo malicioso me tome la clave, modo hacker

 

Podría alguien tener configurado que se tome nota de las credenciales ingresadas en caso de error. No es algo que se pueda hacer con PAM según dice wikipedia de PAM,  "This lack of functionality is also the reason SSH does its own authentication mechanism negotiation." pero quizás no estoy interpretando bien, pues en /var/log/auth.log hay entradas como esta:

 

auth.log:Aug 21 22:50:55 carlos-VirtualBox sshd[65233]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.1.190  user=carlos

o quizás sea una falsa alarma, pues luego en SSH dice que "keyboard-interactive (RFC 4256): a versatile method where the server sends one or more prompts to enter information and the client displays them and sends back responses keyed-in by the user. Used to provide one-time password authentication such as S/Key or SecurID. Used by some OpenSSH configurations when PAM is the underlying host-authentication provider to effectively provide password authentication."

 

Luego hacemos un sudo fallido:

Aug 21 23:11:55 carlos-VirtualBox sudo: pam_unix(sudo:auth): authentication failure; logname= uid=1000 euid=0 tty=/dev/pts/9 ruser=carlos rhost=  user=carlos

Vamos bien, hay que aprender un poquito de PAM a ver como ponemos nuestro propio autenticador que guarde las credenciales.

Empecemos por...

[/etc/pam.d/sshd]
# Standard Un*x authentication.
@include common-auth

Suficiente, ya me aburrí, mejor veámosle las tripas al correr, cuando ingresamos "xxxxx" como password emite esto:

$ ps ax | grep sshd: | grep -ve grep | cut -d"?" -f 1 | xargs strace -f --attach
....
[pid 65596] read(4, "\200\216\2337-)\372dz\204\20\307\214\367\16\27\276?\346\341\26,\375\f\241\17\210\2\2318\206\340"..., 8192) = 84
[pid 65596] write(5, "\0\0\0\n\f", 5)   = 5
[pid 65592] <... poll resumed>)         = 1 ([{fd=6, revents=POLLIN}])
[pid 65596] write(5, "\0\0\0\5xxxxx", 9 <unfinished ...>
[pid 65592] read(6,  <unfinished ...>
[pid 65596] <... write resumed>)        = 9
[pid 65592] <... read resumed>"\0\0\0\n", 4) = 4
[pid 65596] read(5,  <unfinished ...>
[pid 65592] read(6, "\f\0\0\0\5xxxxx", 10) = 10
[pid 65592] getuid()                    = 0
....
 

Hagamos algo mejor, asumamos que ya conocemos el $PID del sshd y usemos clave 01234567 para variar:

$ strace -f -eread --attach $PID
...
pid 65628] read(5, "\0\0\0\0", 4)      = 4
[pid 65628] read(4, "\361\376l\340\225\267\260Y\".'\301\237\353\3412\210\4\r\273'D\301\30\272\350\346\375\3544Q\""..., 8192) = 148
[pid 65627] read(6, "\0\0\0\r", 4)      = 4
[pid 65628] read(5,  <unfinished ...>
[pid 65627] read(6, "\f\0\0\0\01001234567", 13) = 13
[pid 65627] read(5, "#\n# /etc/login.defs - Configurat"..., 4096) = 4096
[pid 65627] read(5, " issuing \n# the \"mesg y\" command"..., 4096) = 4096
[pid 65627] read(5, "algorithm compatible with the on"..., 4096) = 2358
...

Mejor, pero trae demasiadas líneas, un poquito de grep

$ strace -f --attach 65570 |& fgrep 'read(6, "\'  
[pid 66019] read(6, "\0\0\0D", 4)       = 4
[pid 66019] read(6, "\6", 68)           = 1
[pid 66019] read(6, "\0\0\0\v", 4)      = 4
[pid 66019] read(6, "\0\0\0\6carlos", 10) = 10
[pid 66019] read(6, "\0\0\0\1", 4)      = 4
[pid 66019] read(6, "\0\0\0\33", 4)     = 4
[pid 66019] read(6, "\4\0\0\0\16ssh-connection\0\0\0\0\0\0\0\0", 27) = 27
[pid 66019] read(6, "\0\0\2,", 4)       = 4
[pid 66019] read(6, "\26\0\0\0\2\0\0\0\0\0\0\0\0\0\0\2\27\0\0\0\7ssh-rsa\0\0\0\3"..., 556) = 556
[pid 66019] read(6, "\0\0\1,", 4)       = 4
[pid 66019] read(6, "\26\0\0\0\2\0\0\0\0\0\0\0\0\0\0\1\27\0\0\0\7ssh-rsa\0\0\0\3"..., 300) = 300
[pid 66019] read(6, "\f\0\0\0\t987654321", 14) = 14

 

Es verdad, no es muy fácil de automatizar, quizás sea mejor tomar probablemente el código fuente de pam_unix.so, modificarlo, recompilarlo y reinstalarlo, esto fué solo una POC de por que no hay que probar contraseñas en equipos que no confiás.

 

Barrer y que un equipo malicioso me tome la clave, modo programador

Podemos instalar nuestro propio servidor ssh modificado para que registre las credenciales.

sudo apt  update
sudo apt install dh-autoreconf libz-dev libssl-dev
git clone https://github.com/openssh/openssh-portable.git
autoreconf
./configure
make ; # paciencia
 

Buscás y buscás el punto de inserción, que resulta ser

 

patch

 

Luego:

$ sudo service sshd stop
$ sudo $(realpath sshd) -D
 

Intentás conectarte y tenés las claves:

sudo tail -f /var/log/auth
Nov  8 18:14:58 template sshd[1458]: User carlos Password XXXXXXXX
Nov  8 18:14:58 template sshd[1458]: Failed password for carlos from 192.168.1.100 port 49320 ssh2
Nov  8 18:15:01 template sshd[1458]: User carlos Password 12345678
Nov  8 18:15:01 template sshd[1458]: Failed password for carlos from 192.168.1.100 port 49320 ssh2
Nov  8 18:15:05 template sshd[1458]: User carlos Password mySecret
Nov  8 18:15:05 template sshd[1458]: Failed password for carlos from 192.168.1.100 port 49320 ssh2
Nov  8 18:15:05 template sshd[1458]: error: maximum authentication attempts exceeded for carlos from 192.168.1.100 port 49320 ssh2 [preauth]
Nov  8 18:15:05 template sshd[1458]: Disconnecting authenticating user carlos 192.168.1.100 port 49320: Too many authentication failures [preauth]

Ambos métodos requieren root, así que tiene que ser un equipo del atacante o que esté comprometido.

Buscar firmas

Para consultar las firmas a cada máquina, en teoría se hace así con nmap:

 

nmap

Si no tenés nmap o el servidor no te da la información como a mi me ocurre con algunas direcciones, no sé si es por alguna configuración del servidor o falla del script de nmap, usás ssh-keyscan:

 

ssh-keyscan

Si te habías conectado antes, con ssh-keygen podés relacionar:

ssh-keygen

 

Si tuvieras la primera conexión:

 

ssh primera conexión

 

la correlacionás con 

ssh -v

No he podido relacionar las firmas de ambos métodos.

Todo esto es muy complicado pero es scripteable:

START=106

STOP=110

NET=192.168.1.

TARGET=$( ssh-keygen -F 192.168.1.108 | grep -o "ecdsa.*" | cut -d" " -f 2 )

for HOST in $(seq $START $STOP); do

ssh-keyscan "$NET$HOST" | fgrep "$TARGET"

done

 

Ejecución script

Si la máquina hubiera cambiado a otra IP, la encontrábamos si estaba en el rango del seq.

 

Putty

¿Qué pasa si tu conexión fué desde putty en windows? Hay que usar Regedit, buscar esta clave y ahí la IP de interés:

HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys

SSH Host Key en putty

 

Para obtener el valor, le das botón derecho, modify...

 

SSH Host Key en putty

Son estos dos valores:

 

0x2c41d8156e8fa6ff033b9bccde9005e7063dbbe5cff38334e336af7569bea178

0x17657a34f156c9f05ecae35749499ef23954a1b217f42c6ac946ce2a6073f8c5

 

Ahora hay que ver como se relacionan con:

AAAAC3NzaC1lZDI1NTE5AAAAIMX4c2AqzkbJaiz0F7KhVDnynklJV+PKXvDJVvE0emUX

echo -n AAAAC3NzaC1......JV+PKXvDJVvE0emUX | base64 -d | hexdump -C

00 00 00 0b 73 73 68 2d  65 64 32 35 35 31 39 00 |....ssh-ed25519.|
00 00 20 c5 f8 73 60 2a  ce 46 c9 6a 2c f4 17 b2 |.. ..s`*.F.j,...|
a1 54 39 f2 9e 49 49 57  e3 ca 5e f0 c9 56 f1 34 |.T9..IIW..^..V.4|
7a 65 17                                         |ze.|

Puede ser que no sea con la ecdsa, supongo que sabrás arreglártelas...

Conclusión

No es buena idea intentar autenticarse ante un sistema que no sabés si es el correcto.