PDF de programación - Caso real y práctico de hacking Inseguridad en guiones shell

Publicado en la revista @rroba, nº 60, pp. 84-87. Septiembre, 2002. © Román Medina-Heigl Hernández.


Caso real y práctico de hacking
Inseguridad en guiones shell

La programación shell constituye un importante recurso para todo administrador
de sistemas. Unas simples nociones de bash o cualquier otro lenguaje shell
bastarán para que seamos capaces de escribir útiles programas en unas pocas
líneas de código. Sin embargo, a veces los programadores de guiones shell (“shell-
scripts”) olvidan o simplemente ignoran las implicaciones que un script defectuoso
o mal diseñado puede tener en la seguridad de una máquina. Ilustraremos paso a
paso el ataque a un servidor que ofrece un servicio de shells gratuitas basándose el
sistema de altas “automatizadas” en uno de estos guiones shell.


Escenario


Sea "vuln" la máquina a atacar. Se trata de un sistema Linux con el último kernel
2.4, muy poco software instalado, con últimas versiones para los distintos servicios
(“demonios”) activos y con los últimos parches. A primera vista parece un sistema
robusto y difícil de romper.


El servidor, orientado al desarrollo, ofrece cuentas shell gratuitas para sus
colaboradores. Para obtener cuenta simplemente se ha de hacer telnet a la máquina, y
entrar como usuario "guest" sin contraseña. A partir de ahí se nos pedirá un username y
password, proporcionaremos ciertos datos para cumplir con el protocolo (nombre real,
etc) y nuestra cuenta será creada al instante. El posterior acceso a nuestra nueva cuenta
se realiza mediante SSH (“Secure SHell”) lo que dotará a nuestras sesiones interactivas
de una privacidad extra gracias a la encriptación.


Un paseo por la máquina


Tras llevar a cabo el proceso de registro entramos en nuestra cuenta recién
creada (sin privilegios, evidentemente). Lo primero es como siempre inspeccionar el
sistema: hacer un "netstat -na" o "netstat -na | grep LISTEN" (esto último sólo muestra
los puertos TCP abiertos, no UDP) para ver los servicios que corre, "cat /proc/version"
para ver la versión completa de kernel, buscar algún fichero del tipo /etc/xxxx-release
(ej. redhat-release, suse-release, ...) que de una pista de la distribución Linux de que se
trata para posteriormente buscar vulnerabilidades de la misma, buscar ficheros “suid”
que puedan ser atacados, bugs conocidos, etc.


Después de obtener una rápida panorámica y no encontrar fallo alguno en los
ejecutables propios del sistema decidimos centrarnos en el sistema de registro (alta de
nuevas cuentas). Éste lo acabamos de usar y no nos ha parecido un sistema muy
elaborado sino más bien al contrario: no creemos que el progra-mador del mismo le
haya dedicado demasiado tiempo.


El peculiar sistema se compone de una cuenta “guest” con uid 0 (en Unix todo
identificador de usuario o “user id” con valor 0 corresponde a una cuenta privilegiada,

1

más concretamente al superusuario o “root”) cuya shell inicial es un script llamado
“shguest”. De esta forma al conectar mediante telnet al servidor y autentificarnos como
“guest” el control le es pasado automáticamente al script anterior (el cual se va a
encargar de dar de alta a nuevos usuarios). La configuración de PAM nos impide saltar
al contexto de usuario guest (mediante un "su guest") y evita lo que sería un root
instantáneo.

roman@vuln:~$ ls -l /usr/local/bin/shguest
-rwsr-s--- 1 1004 root 201 Nov 11 15:34
/usr/local/bin/shguest

Si analizamos lo anterior observamos varias cosas. En primer lugar el script se
ejecutará con privilegios de superusuario (uid 0) (lo cual resulta lógico hasta cierto
punto si tenemos en cuenta que dar de alta una cuenta es una operación administrativa
que normalmente requerirá de privilegios). Nótese además los peculiares permisos del
script. Los bits suid y sgid sobran ya que el usuario guest ya tiene permisos de root y
lanzará el script como tal. Por último, los permisos para "otros" usuarios distintos del
1004 y que no pertenezcan al grupo de root (donde se incluye el usuario con el que
estamos operando) son nulos lo que implica que no podremos listar el contenido del
script ni tampoco auditar el código en busca de vulnerabilidades. La dificultad aumenta
un punto: tendremos que trabajar a ciegas. No obstante y para facilitar la comprensión
del texto mostraremos al lector el contenido del script:

#!/bin/bash
echo "Add New UserName"
read -p "Enter a username to add: " login
/usr/sbin/adduser $login
echo ""
echo "Correctly added user $login"
echo ""
read -p "Press [ENTER] to continue..."
echo ""

inteligente.

Intenta ser

relativamente segura e

Es el momento de hacer una pausa en el camino y reflexionar. Bash es una shell
bastante
implementa ciertas
"protecciones". Por ejemplo, si hacemos "suid root" al correspondiente ejecutable de la
shell y un usuario sin privilegios ejecuta dicho fichero éste no obtendrá una root shell,
como cabría esperar en un principio (más adelante veremos cómo solventar esto).
Probad con otras shells y veréis que la mayoría sí lo consienten. Tampoco permite
ataques basados en la utilización de metacaracteres como "; | `". Sin embargo, podemos
apreciar que nuestro script ejecuta un comando que toma la cadena suministrada por el
usuario, sin “parsear” (es decir, sin filtrar caracteres potencialmente peligrosos y en
definitiva, sin tener en cuenta la posibilidad de que el usuario introduzca algo
inesperado e inusual). Esta fase de “parseo” o verificación de datos nunca se debería de
pasar por alto ni obviar y de hecho va a propiciar el éxito de nuestro ataque.


Comenzamos lanzando los típicos patrones de ataque:

1.- Enter a username to add: paquito ; /usr/bin/id
2.- Enter a username to add: paquito | /usr/bin/id
3.- Enter a username to add: `/usr/bin/id`
4.- Enter a username to add: paquito > /tmp/roman

No vamos a entrar en detalles. Nos basta con saber que los tres primeros intentan
ejecutar el comando “id” y el último sobrescribir o crear el fichero /tmp/roman. Las

2

cuatro pruebas han resultado infructuosas. El script no es vulnerable (recordemos que
está escrito en bash). Si el script se ejecutara bajo el contexto de una shell tradicional
(sh, tcsh, ksh) más que probablemente aquí habría terminado este escrito y habríamos
encontrado la puerta para entrar ;-)


Sin embargo, al ir viendo las respuestas del script (a todo esto, para probar lo
anterior simplemente basta con hacer un "telnet localhost" e introducir como usuario
"guest" para que el script de registro sea lanzado) nos iremos dando cuenta de que usa
"adduser" para añadir los nuevos usuarios y que se le pueden pasar parámetros a dicho
programa (recordemos que en este punto de nuestra investigación aún no hemos podido
obtener el listado del contenido del script). Por ejemplo, si intentamos crear un usuario
llamado “--help” obtendremos la ayuda en pantalla del comando “adduser”:

Enter a username to add: --help
adduser [--home DIR] [--shell SHELL] [--no-create-home] [--uid ID] [--firstuid ID] [--
lastuid ID]
[--gecos GECOS] [--ingroup GROUP | --gid ID] [--disabled-password] [--disabled-login]
user
Add a normal user

adduser --system [--home DIR] [--shell SHELL] [--no-create-home] [--uid ID] [--gecos
GECOS]
[--group | --ingroup GROUP | --gid ID] [--disabled-password] [--disabled-login] user
Add a system user

adduser --group [--gid ID] group
addgroup [--gid ID] group
Add a system group

adduser user group
Add an existing user to an existing group

Global configuration is in the file /etc/adduser.conf.
Other options are [--quiet] [--force-badname] [--help] [--version] [--conf FILE].

Correctly added user --help

Press [ENTER] to continue...

Si nos fijamos en la salida anterior nos daremos cuenta de que el script ni
siquiera ha detectado nuestra “jugada”: responde diciendo que el usuario se añadió
correctamente, lo cual no es realmente cierto. Hemos dado el primer paso hacia delante.
Es hora de estudiar el comando adduser. Para ello haremos un "man adduser" y
leeremos. Lo primero que se nos ocurre es intentar crear una nueva cuenta con permisos
de root pero adduser no nos deja porque detecta que el uid 0 ya está asignado a otra
cuenta (sin ir más lejos, root y guest tienen dicho uid):

Enter a username to add: --uid 0 paquito
adduser: The UID `0' already exists.

Correctly added user --uid 0 paquito

Press [ENTER] to continue...

Lo intentamos de nuevo, esta vez jugando con el gid. Trataremos de crear una

cuenta con “group id” 0:

Enter a username to add: --gid 0 paquito
[...]

¡Esto último funciona! (cid:1). Obtenemos una cuenta con gid root. A partir de ahí
seguro que se os pueden ocurrir algunas ideas para lograr el root total (uid 0), ¿no?
Bueno, pues aunque parezca extraño, no vamos a aprovecharnos de esto, y dejaremos

3

nuestra cuenta gid root apartada, no la vamos a usar (más difícil todavía ;-)). No se si os
habréis dado cuenta pero realmente llegado a este punto ya estamos en condiciones de
obtener el listado del script (repasad los permisos del mismo). Para ello simplemente
habría que entrar al sistema con el usuario creado con gid 0.


¿Y entonces? ¿Nos hemos quedado sin ideas? "Use the code, Luke":


roman@vuln:~$ ls -l /usr/sbin/adduser
-rwxr-xr-x 1 root root 25538 Sep 17 15:23
/usr/sbin/adduser
roman@vuln:~$ more /usr/sbin/adduser
[...]

Es decir, nos ponemos a mirar el código de adduser. Se trata de un script en perl
(si no recuerdo mal, típico de Debian, aunque esto