jueves, 31 de mayo de 2018

Comprobar la seguridad de tus servidores

#DISCLAIMER
/*
Esta entrada la hago para comprobar la seguridad y algunas configurciones que pueden llevar a fallo en nuestro servidor. Este es un post con un objetivo académico y educacional. Ya he dicho que es para comprobar la seguridad de TU servidor, no del servidor del vecino, por lo que no me responsabilizo del uso que le podáis dar, panda de cabrones.

Además he estado durante unos cuantos días pensando si hablaba en esta entrada también sobre cómo fortificar el servidor, pero al final he decidido dejarlo para otro post que vendrá más adelante.

*/

Los servidores son una de las partes más críticas en una organización. Muchas veces basta con que caiga el sevidor central para generar un caos enorme a nivel de red en la organización en cuestión. Yo en este post no voy a enseñar cómo comprometer a un servidor en todos los casos, voy a hacer una especie de guía, un procedimiento que podéis seguir en las auditorías que os toque hacer o con los servidores que os montéis.




Yo para este post he utilizado un Debian 8 con un servidor Apache 2.4.10, MySQL y en la que he montado un Wordpress 4.9.6. El Wordpress tiene una configuración por defecto, está todo recién instalado para ir modificándolo todo en un post que estoy preparando sobre hardening de servidores.


¿Cuál es el problema cuando nos podemos a realizar una auditoría? Pues que muchs veces caemos en el fallo de ver que al tirar de Nmap, nos muestra por pantalla un Apache 2.4.25 y cuando nos vamos a la lista de releases de Apache y vemos que la última versión de la 2.4.x es la 2.4.33  del 17 de Marzo de 2018 ya empezamos a aplaudir porque creemos que es vulnerable.

Esto no es siempre así, ya que si nos vamos a la lista de releases estables de Debian, vemos que para Debian 9{última versión} la versión de Apache es la 2.4.25, que es stable, está actualizada y por tanto no es vulnerable.

Este ha sido solamente un ejemplo, pero que nos suele ocurrir //A mí al primero que le ocurría y muchas veces aún me sigue ocurriendo. Este fallo en el pensamiento, creo que se debe a que en muchas CONs los ponentes son confusos o no explican este matiz del todo. Muchas veces puede ser por ir apretados de tiempo, lo entiendo, no es por acusar a nadie.

Tirando de Nmap 

El primer paso a aplicar, sería tirar de Nmap contra tu servidor. Aquí, podemos usar la funcionalidad tan buena que tiene Nmap de ejecutar scripts. En este caso vamos a empezar ejecutando el script con la opción por default. {Para encontrar la lista completa de scripts que se pueden ejecutar en Nmap, deberéis escribir locat nse | grep script}



Aquí observamos varias cosas curiososas. Para empezar, tiene 3 puertos abiertos bajo tcp {recordemos que tendríamos que comprobar también los puertos bajo udp}. El primero es el servidor ssh, que lo tiene en su puerto por defecto, el 22; algo que en la entrada del hardening cambiaremos.

Como otra curiosidad, vemos que en el puerto 80, tiene montado un Worpress 4.9.6, que es la versión más actual, pues es del 17 de Mayo de 2018 tal y como apreciamos en la lista de relases de Wordpress.

También nos deja una puerta abierta a entrar por escritorio remoto, algo bastante peligroso en caso de dar con la contraseña del sistema de este servidor montado bajo un Debian.


Otro aspecto muy interesante, es ejecutar Nmap con un script con la opción auth, para tratar de encontrar, como en este caso ocurre, el usuario de Wordpress, por lo que cuando más adelante usemos la herramienta Hydra, ya es un campo que conocemos.

Además, existe el problema en que el resultado de SSH no aparece un mensaje como


============================================================
"Supported authentication methods:
publickey"

============================================================

Esto nos permitiría poder entrar obteniendo la contraseña mediante ataques de fuerza bruta o diccionario, ya que permitirá cualquier autenticación aunque no se tenga certificados de clave pública. Esto nos motiva para hacer uso de Hydra.

Nikto

Vale, ya hemos visto por qué caminos tenemos un posible acceso, en este caso tanto por SSH como por web. Vamos a tratar de explotar lo máximo posible la web. Para realizar esto, Nikto escaneará plugins e irá encontrando vulnerabilidades en el servidor.


Una vez que lo lanzamos, vemos que nos muestra respuestas como que la versión de Apache está outdated, desactualizada, que el anti-clickjacking o la protección XSS no están habiliadas,etc.


Revisaremos bien la respuesta de Nikto para ver si encuentra alguna vulnerabiliad que podamos explotar o si podemos aprovecharnos de algún archivo por defecto del servidor Apache como nos reporta Nikto con el README.


El reporte no nos dice que TRACE esté activo, pero como puede dar falsos positivos, podemos comprobarlo en un momento. Como era de esperar, no estaba habilitado, por lo que no seremos susceptibles a ataques de Cross Site Tracing.

Aunque no esté activo, sí que nos da información sobre la máquina en la que está montada el Wordpress. En este caso, un Debian, que era una de las cosas que nos podía faktar por conocer.


Esta es la información que muestra OWASP sobre este posible ataque, por lo que si tenéis este método activo en vuestro servidor, será mejor que lo desactivéis para que un atacante no pueda ver lo que se está recibiendo desde el otro punto final.

Automatizando y comprobando posibles vulns con Golismero

Golismero es una herramienta muy usada por pentesters, ya que reúne varias de las herramientas de seguridad más utilizadas, además de que con su opción -o te monta un html si lo deseas para que tengas toda la información obtenida de una forma más gráfica. Podéis descargar golismero de la siguiente forma.

apt-get install python2.7 python2.7-dev python-pip python-docutils git perl nmap sslscan

git clone https://github.com/golismero/golismero.git 
cd golismero 
pip install -r requirements.txt 
pip install -r requirements_unix.txt

Una vez instalado lo podremos ejecutar para que realice un escaneo completo con la instrucción 

python golismero.py scan [IP || HOST] -o /var/www/html/reportes.html



Tardará un poco puesto que lanzará Nikto, Nmap, Ip Geolocation,etc. Pero cuando termine, podremos irnos al navegador y escribir [IP]/reportes.html y veremos todo lo que ha ido obteniendo Golismero de una forma gráfica.


Ojo, reitero que no tenemo que fiarnos de todo lo que nos muestre Golismero, y que puede dar falsos positivos. La información que nos muestra es para que sepamos por dónde tirar, pero tenemos que comprobar que efectivamente se pueden aprovechar cada vulnerabilidad encontrada.


Iremos viendo cómo nos muestra un listado de enlaces con posibles vulnerabilidades o debilidades. Esta herramienta está bastante bien porque incorpora las grandes herramientas en una y además muestra la información de una forma bastante visual.




Si vamos a uno de los enlaces en los que nos dice que sufre de fuga de información, veremos que nos muestra la versión del Worpress. Alo que ya sabíamos pero que ahora podemos confirmar con mayores evidencias.

Comprobando si existen SQL Injection en nuestro server

Las vulnerabilidades de tipo Injection es una de las tareas pendientes cuando se trata de un servidor web. Esto lo demuestra año tras año OWASP con su TOP 10 de vulnerabilidades. Si comparamos lo obtenido en 2013 y 2017, vemos que en el puesto 1, aún siguen los ataques de tipo Injection.





Por esta misma razón, será una de las cuestiones que más tengamos que revisar. Para esto, podemos utilizar la herramienta sqlmap.


Tendremos que ir viendo lo que nos muestra por pantalla esta herramienta y ver si es vulnerable o no. En mi caso me salió el siguiente mensaje mientras realizaba l prueba.


Esto lo que quiere decir es que o no ha encontrado vulnerabilidades con los parámetros enviados o que está protegido por un Firewall Web.
Obteniendo contraseñas con Hydra
Como vimos anteriormente con el caso del SSH del servidor, permitía las conexiones sin certificados digitales, por lo que será importante para nosotros obtener la contraseña que se está usando para entrar al sistema.
Nosotros lo que tendríamos que hacer sería lanzar Hydra con los diccionarios que tengamos o que hayamos generado. Yo aquí, como ya sabía el usuario y la contraseña, los he introducido directamente, aunque algo recomendable sería lanzar los diccionarios que dispone Kali Linux para ver si obtendrían o no la contraseña y el usuario y en caso de obtenerlo, cuánto tiempo tardarían. 
Comprobando la facilidad de realizar un DoS 

A ver, aquí siempre hay mucha confusión, incluso por gente que se dedica a Seguridad que se empeña en llamar DoS a lo que no es, ya que muchas veces un servidor cae por tener malas configuraciones.
Tened en mente que un servidor no es solamente el sistema operativo sobre el que está montado un recurso como un FTP, una página web, un DHCP, un DNS,etc. No. Un servidor es el sistema operativo, el servidor Apache con sus configuraciones, la Base de datos con su configuraciones, el código de la web ¿Es redundante el código de la web? ¿Hay mucho entorno gráfico que con menos transmites lo mismo y encima el rendimiento sea mayor?  Todas estas son preguntas que deberemos  responder en función de lo que vayamos encontrando en los archivos de configuración o en el código de la web o configuraciones del sistema operativo.


En esta entrada no voy a entrar en temas de explicar cada parte  de cada archivo de configuración. En este caso vemos el MaxKeepAliveRequest. En el mismo archivo de configuración explica lo que es, y no es otra cosa que el número máximo de consultas que va a permitir el servidor Apache.


Si entramos en el archivo de configuración de MySQL, tendremos que tener cuidado de que no ponga 0.0.0.0 en el bind-address para que no pueda entrar cualquiera a la Base de datos.




Si seguimos bajando por el archivo, veremos que en la opción de max-connections, tenemos por defecto como comentario, por lo que no tendríamos límite de conexiones a la vez en la base de datos.
Esto es una mala configuración, ya que Apache permite 100 consultas, pero la Base de datos no tendría límite, por lo que se crea un cuello de botella de libro.
A ver, esto nosotros lo podemos controlar porque es nuestro server, aunque sino lo fuese, recordemos que tenemos la contraseña y el usuario para acceder por SSH.
Este problema puede desencadenar en una "DoS", aunque no es fallo del servidor ni de la web, es una mala configuración, el Apache no cae. Es el que crea el cuello de botella con respecto a la Base de datos, pero el servidor no cae. Reiniciamos y sigue funcionando todo.

Tener clara esta idea es vital. Un servidor no cae, es muy difícil que caiga, y si la web se cae, puede er por mil cuestiones, ya que una web no es solamente la web, es Apache o Nginx, es la Base de datos, es el Kernel. Es una combinación de cosas, no es un problema único.


Por si queremos buscar los demás límites máximos de la base de datos, es tan sencillo como hacer un cat my.cnf | grep "max".


Para las pruebas de DoS que queráis hacer sobre vuestro servidor, podéis usar la herramienta de Apache2-utils ab, que es de fácil uso. con -c indica el nivel de concurrencia y -n el número de peticiones. Aquí todas las opciones.

Como vemos en el servidor con el comando netstat -plan|grep :80 | awk {'print $5'} | cut -d: -f1 |sort| uniq -c| sort -n veremos las peticiones que llegan, en este caso de 50 en 50 hasta 100, por lo que, en teoría, no debería caer ¿no?


Pues lo cierto es que si te vas a la web, no carga, y si tratas de ejecutar cualquier comando en el terminal del Debian, te va a ser difícil porque empieza a pillarse. Tened en cuenta que estamos realizando pruebas de estrés.

Esto ocurre, entre otras cosas, porque los archivos de configuración de Apache y MySQL están por defecto y sn contradictorios, además de que no se disponen de sistemas de caching y que encima estamos con un Wordpress, que sin caching, al final cae.


Otra herramienta muy útil para realizar estas pruebas de DoS es UfoNet. Aquí podéis ver mejor cómo funciona UfoNet, aunque para casos básicos es muy sencillo de usar, con -a indicamos el sitio a atacar y -r indica el número de veces que cada host atacará a la víctima.


Y tendremos que esperar y ver cómo reacciona nuestro servidor. Con netstat lo podemos ver aunque también sería aconsejable el uso de Mod-Status para ver desde dónde y qué IPs nos están atacando.

Creo que si se siguen los pasos enunciados en este post, podremos tener una visión general de los problemas de seguridad y configuración que puede tener nuestro servidor. Conocer los fallos que puede tener nuestro server es importante para no perdernos mucho al aplicar las soluciones, unas soluciones que os dejaré más adelante en otro post. Me llevará un tiempo preparar esa entrada, así que a lo mejor para mediados de junio está lista, aunque no prometo nada.

¿Hackeamos el Mundo?

No hay comentarios:

Publicar un comentario

Related Posts Plugin for WordPress, Blogger...

Entrada destacada

El server me sabe a poco.

Soy un fanático del Rock y de Debian . (Creo que voy a inventar Rockbian, que suena bien y todo xD) Llevaba tiempo queriendo unir estos 2 c...