Basic auth, Sistemas de Control Industrial & Laboratorio

El otro día, haciendo unos ajustes en un servidor web, me vi en la necesidad de proteger momentáneamente un directorio con contraseña, por lo que rápidamente vino a mi cabeza hacer uso del famoso archivo “.htaccess” para resolverlo.

Si buscamos en Google cómo proteger directorios o archivos, este vuelca “.htaccess” como la respuesta más común y, dentro de este proceso, es posible encontrar varias formas de hacerlo.

Si buscamos en Google cómo proteger directorios o archivos, encontramos el .htaccess como la respuesta más común Click Para Twittear

Es aquí donde empiezan los problemas de seguridad, como siempre que buscamos en Google y hacemos un copy & paste sin tener muy claro qué estamos haciendo. Podemos meter la pata si no andamos con cuidado.

Siguiendo esta premisa, tenemos como ejemplo la siguiente sintaxis que algunos sitios recomiendan emplear para proteger un directorio:

Si miramos este fragmento de código podemos apreciar que solamente protege las peticiones del tipo GET, por lo que ya sabemos cómo vulnerar esa seguridad, ¿verdad? (podéis ponerlo en práctica en el lab que aparece más adelante).

Por suerte este esto no es muy común, y en general la autenticación del tipo “Basic” está cada vez más en desuso en las páginas webs actuales. Así se deja paso a otros sistemas propietarios desarrollados para la app que, además pueden incluir sistemas de protección extra como el 2FA.

El caso es que, dando una vuelta por Shodan, me di cuenta de que hay un lugar en el que este tipo de seguridad “desactualizada” está a la orden del día. Me refiero a los sistemas de control industrial (ICS), entre los que podemos encontrar gran cantidad de servicios web abiertos y publicados en internet bajo una IP cuya única protección es ese .htaccess.

Si realizamos una búsqueda, probablemente nos encontremos con el hecho de que todos los servidores que tienen abierto el puerto 80 o el 8080 se defienden así.

¿Qué pasaría si alguien se dedicase a aplicar fuerza bruta a estas IPs?, ¿Qué se esconderá detrás de cada una de ella? Nodos de plantas eléctricas, plantas potabilizadoras, líneas de producción de fábricas…, las opciones son muy amplias.

Tras reflexionar sobre ello, vamos a ver qué es y cómo funciona la autenticación básica en el protocolo http, para más tarde practicar su ruptura o bypass.

EL PROTOCOLO HTTP

Resumiendo en breves palabras el protocolo “http” podemos decir que es un protocolo de tipo “stateless”, usado para comunicarse en internet y cuyo esquema sigue el orden “petición-respuesta”. Cuenta con varias versiones y con una serie de métodos para cada petición.

Estos métodos son GET, POST, PUT, DELETE, TRACE, OPTIONS y CONNECT.
Por último es importante decir que también existen unos códigos de respuesta 1xx, 2xx, 3xx …

Si queréis profundizar más podéis leer el RFC correspondiente en el siguiente link: https://tools.ietf.org/html/rfc2616

LA AUTENTICACION.

Cuando surgió este protocolo, se creó la necesidad de poder proteger algunas de las páginas web mediante una contraseña. A su vez también apareció la necesidad de incorporar la autenticación “basic” y la “digest”.

Según su RFC, la autenticación del tipo basic se basa en un nombre de usuario y una clave que tienen que usarse para identificarse en una web con un realm especifico.

Por tanto, para hacer uso de este tipo de seguridad nuestra web tendrá que enviar en sus cabeceras dicho “realm” al tiempo que nosotros proporcionamos el usuario y la clave.

Dependiendo de lo introducido por el usuario en el challenge el servidor responderá con un código u otro.

Para ver mas información este es el RFC correspondiente https://tools.ietf.org/html/rfc2617

IMPLEMENTACION Y BYPASS.

Una vez visto lo más básico de su funcionamiento, vamos a ver cómo se implementa en algunos lugares de la red.

Como vimos al principio del post, en algunos lugares se recomienda que se bloquee el acceso a un directorio de la siguiente forma:

De esta manera lo único que hacemos es bloquear las peticiones de tipo GET, pero no es así respecto a las demás peticiones. Si hacemos uso de alguna herramienta como curl, y cambiamos el tipo de petición a POST, comprobamos que el código de respuesta cambia a 200 y es posible ver todo el HTML sin problema alguno. Para hacer esto desde el navegador se puede emplear alguna extensión que nos permita realizar peticiones específicas como “postman”.

Por suerte esta implementación es altamente amateur, y no muy común. Aun así, nunca está de más comprobarlo y hacer una petición del tipo OPTIONS para ver los métodos permitidos por el servidor.

A continuación se muestra otra implementación, más común y segura que la anterior, que podemos encontrar en gran número de servidores web en ICS (Sistemas de control industrial) como vimos anteriormente:

En este caso, para el archivo private_two.html se bloquean todas las peticiones de cualquier tipo para todos los usuarios no autentificados. Esto podría parecer seguro, pero no os dejéis engañar. La autenticación de este tipo tiene un gran fallo, puesto que no tiene control de intentos erróneos, ni posibilidad de ello (al menos de forma nativa, aunque por ejemplo sería posible controlar el número de veces que se muestra un 404 o un 401 y banear al usuario).
Por consiguiente, un ataque de fuerza bruta es completamente factible y, si a eso le sumamos la mala práctica de poner admin como usuario, el plan está servido.

ATAQUE

Visto lo anterior, resulta evidente que realizar un ataque de fuerza bruta a este sistema es muy simple. Es posible hacerlo de muchos modos (incluso a mano) pero la forma más simple es usar alguna herramienta como metasploit o nmap.

Metasploit cuenta con un módulo llamado “http_login” que permite hacer esto de forma fácil con sus propios diccionarios u otros proporcionados por nosotros.
Pero hoy quiero enseñaros a hacerlo con nmap, una herramienta que, además de sus utilidades normales, cuenta con un potente motor de scripts.

Para ello usaremos el script http-brute con los parámetros requeridos, pero antes tenemos que proporcionar un diccionario que en este caso crearemos con crunch.

He dejado un video (atacando a un servidor propio, recordar no meteros en problemas) para que veáis como funciona, además he preparado un pequeño lab con dos pruebas de distinta dificultad que seguro podréis resolver después de haber leído este post.

Acceso al Lab: http://learn-webmiplabs.rhcloud.com/lab/basicauthlab/ (una vez dentro pulsar sobre el reto 1 y o)

Si no habéis sido capaz de resolver el reto no os preocupéis, aquí os dejo el video para que comprobéis como resolver el segundo.

Espero que os haya gustado y, si conocéis otras formas de realizarlo, ¡agradeceré todos vuestros comentarios!
Pd: No seáis malos y absteneros de lanzar DDoS u otros ataques a la plataforma del laboratorio, o no podrá estar disponible para todos.

Saludos.