Auditando un SFTP en 3 horas

Hace unos días en el trabajo me pidieron que auditase un servidor SFTP, y al igual que cuando escribí el post "Auditando una librería en 16 horas" es algo que no suelo hacer, por lo que me he decidido a escribir este post explicando lo poco que conseguí por si alguien está en la misma situación y le pudiera dar mejores resultados. (Aunque sea una pena de este tipo de cosas hay poco que rascar)
Antes de empezar tenemos que tener claro que es un servidor SFTP. Así que vamos a acudir a WikiPedia que lo explica muy bien, pero básicamente funciona igual que un servidor FTP, pero en este caso el contenido de las peticiones y las respuestas del servidor va cifrado. https://es.wikipedia.org/wiki/SSH_File_Transfer_Protocol

Una vez sabido esto, y como no tenemos mucha experiencia en hacer esto, vamos a crearnos una Checklist de posibles vectores de ataque para mirar y saber que podemos reportar.

• Lo primero que pensé era mirar si es posible obtener la versión del servicio, servidor y posteriormente buscar vulnerabilidades CVE para estos.

• En segundo lugar sería interesante comprobar si es vulnerable a fuerza bruta y en caso de que lo sea armarnos un diccionario y probar suerte.

• Otra cosa interesante sería mirar las suites de cifrado que soporta el servidor y comprobar si soporta alguna suite que no sea segura.

• En último lugar, como me dieron acceso con varios usuarios de pruebas, sería buena opción comprobar que se puede hacer con ellos y probar si me dejara acceder a directorios en los que en un principio no se podría.

Una vez terminada nuestra Checklist podemos ponernos manos a la obra.

Fingerprinting y búsqueda de vulnerabilidades

Lo primero que vamos a hacer tirarle nmap a ver que nos devuelve y después podremos con esta información ver si podemos entrar a algún lado. Yo lo tiré de la siguiente forma.

 nmap -sV -O -Pn sftp.dominio.com

sV: Nos listará los servicios disponibles con sus versiones.
O: Nos indicará si es posible indentificarlo el sistema operativo.
Pn: Toma el host como si estuviera Online. En muchos casos el servidor bloquea las peticiones de Ping y cuando escaneamos con nmap este piensa que no está activo, que es lo que pasaba en esta ocasión, así que con este parámetro intenta hacer el análisis independientemente.

Vemos que la versión del servidor SFTP es "Serv-U SSH Server 15.1.6.25", así que lo que vamos a hacer es buscar esta versión en CVE details, a ver si hay alguna vulnerabilidad conocida aquí (además sabemos que el sistema operativo del servidor es Windows server 2008).

Desafortunadamente todas las vulnerabilidades conocidas habían sido ya parcheadas, esto es debido a que la versión del SFTP es la última según lo que pude encontrar en el "changelog". https://support.solarwinds.com/Success_Center/Serv-U_Managed_File_Transfer_Serv-U_FTP_Server/Serv-U_Documentation/release_notes

Igualmente por seguridad el servidor no nos debería de responder la versión del servicio en el banner, ya que si en el futuro sale alguna vulnerabilidad para dicha versión y no se actualiza entonces será vulnerable y será facil detectarlo.

Fuerza Bruta

Para probar si el servicio era vulnerable a fuerza bruta, lo primero que hice fue sacar un listado de los correos electrónicos existentes para ese dominio y de esta forma poder elegir un posible usuario al que realizar este ataque, para ello use la herramienta TheHarvester, que a partir de búsquedas por internet recopila posibles correos electrónicos con el dominio. Lo hice con los siguientes parámetros:

 python theHarvester.py -d dominio -l 500 -b google

-d: El dominio del cual se quieren buscar correos electrónicos y usuarios.
-l: Número de resultados en los que se quieren buscar usuarios.
-b: Lugar donde se quieren buscar estos usuarios.

De entre todos los resultados que obtuve (que eran bastantes) deicidí centrarme en los usuarios que se llamaban "quality", porque fue el que más me llamó la atención ya que supuse que todos los servicios tendrían  que pasar unos requisitos que comprobarían en el departamento de calidad (puede que fuera una suposición poco acertada, pero los demás usuarios dudaba más que tuvieran usuario en el SFTP).

Para crearme el diccionario de contraseñas descargué de internet un diccionario con las 1000 contraseñas más usadas. https://github.com/danielmiessler/SecLists/blob/master/Passwords/Common-Credentials/best1050.txt

A esto le añadí un listado de contraseñas que cree con la herramienta DxD y alguna información que sabía sobre la víctima.

Una vez hecho esto usé Hydra para que probase todas las combinaciones a ver si había suerte. Para esto usé los siguientes parámetros:

 hydra -l "usuario" -P "listaPasswords.txt" ssh://sftp.dominio.com

-l: El usuario que se quiere bruteforcear.
-P: El fichero con la lista de contraseñas a probar.

Lamentablemente esto no dió resultado, aunque a pesar de no obtener la contraseña el servicio si es vulnerable a fuerza bruta, tan solo habría que generar el diccionario correcto.

Suites de cifrado soportada

Lo próximo que quise observar eran las suites de cifrado soportadas por el servidor, para ver si soporta alguna que esté obsoleta. Esta información es fácil de obtener con nmap, para ello hay que usar los siguiente parámetros.

 nmap -Pn --script ssh2-enum-algos -p 22 sftp.dominio.co.uk

-p: El puerto en concreto que se quiere analizar.
--script: Sirve para usar scripts en nmap, en este caso he usado "ssh2-enum-algos" que sirve para enumerar las suites de cifrado soportados por el servicio ssh.

Vemos que soporta una cantidad bastante grande de cifrados, buscando por ahí encontré que los que debería soportar son los siguientes (lo encontré aquí https://www.linuxjournal.com/content/cipher-security-how-harden-tls-and-ssh):

Ciphers aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-ripemd160

Algunos cifrados soportados en este caso como 3DES son vulnerables, en ese caso al ataque SWEET32, aquí podemos ver algo más de información al respecto. https://threatpost.com/new-collision-attacks-against-3des-blowfish-allow-for-cookie-decryption/120087/

En este caso no podemos realizar ningún tipo de ataque porque no tenemos una víctima, pero de igual forma es reportable.

Errores con los permisos 

En este caso hice varias pruebas pero ninguna de ellas dió resultado, por lo que no tengo ninguna evidencia, de todas formas voy a decir lo que hice por si a alguien le da resultado.

En primer lugar probar a leer o a escribir ficheros fuera de nuestro directorio, intentándolo con ficheros como ../../../../../etc/passwd. Pero en ambos casos me daba error.

En segundo lugar, en mi caso tenía dos usuarios de SFTP, pero ambos se corrían con el usuario: "user", por lo que intenté escribir y leer en carpetas de otros usuarios con algo como ../nombreUsuario2/fichero.txt para ver si se podía acceder o escribir en estos ficheros, pero tampoco dió resultado.

Mas allá de eso se me ocurrió poco que probar así que lo dejé por aquí, igual que este post, que ya lo voy a dar por acabado. Hay veces que las cosas se quedan en poquito.

Saluti.

Espero que a alguien le sea útil aunque yo no haya llegado muy lejos.