Cómo usar Latch para proteger el acceso a sitios web de la Intranet publicados en Internet en un servidor Nginx

La idea de esto surge de la necesidad de poder habilitar bajo demanda la publicación de sitios en mi red hogareña a Internet de una forma simple. De esta forma se evita tener habilitados todo el tiempo en Internet servicios que se usan de forma esporádica, bajando la probabilidad de cualquier intento de acceso no autorizado. Una idea muy sencilla que pretende reducir la superficie de exposición temporal de un servicio en Internet para fortificar un servidor GNU/Linux.

Figura 1: Cómo proteger sitios en NGINX con Latch

¿Qué sale un 0day para las tecnologías que soportan el sitio? Solo tengo que esperar a parchearlo y volver a abrir el acceso. Para hacer esto utilizo Latch y un script que actualiza la configuración del webserver usado como Proxy Reverso que en mi caso es un servidor Nginx. Este es el proceso completo y los scripts que yo he utilizado para montar esta arquitectura de seguridad que publica y des-publica los sitios usando Latch.

Prerrequisitos para instalar el entorno

• Python
• Una cuenta de desarrollador del Latch
• Una cuenta de usuario del Latch
• La librería con el SDK de Latch para Python
• WebServer de su elección: Puede ser Apache Http Server, Nginx, o cualquier otro,  configurado para actuar como Proxy Reverso.
• Un rato de tu tiempo

Antes de ponernos con el paso a paso, les cuento que no tengo experiencia en Python por lo que seguramente encontraran formas más elegantes o eficientes de hacer esto, son bienvenidos los comentarios constructivos.

Integrar Latch con el Servidor Nginx: Creación de la app Latch

• Generar una cuenta de desarrollador de Latch: Una vez que tengas una cuenta de Latch, puedes convertirla en una cuenta de desarrollador. Si quieres proteger esta cuenta, ya sabes que también puedes por Latch a los accesos a Latch.

Figura 2: Poner Latch a la cuenta de desarrollador de Latch

• Generar una aplicación: El proceso es sencillo. Esto se hace primero haciendo clic en Mis Aplicaciones.  Luego en el botón Añadir una nueva aplicación. En esa parte del proceso 

Figura 3: Creación de una aplicación en Latch

• Le asignamos un nombre. En mi ejemplo: Mis Webs y luego tomamos nota de los campos remarcados (Id de aplicación y Secreto). Los necesitaremos para aparear nuestra aplicación cliente (en el celular) y el script.

Figura 4: Creación de la aplicación en Latch

Integrar Latch con el Servidor Nginx: Pareo de la aplicación con cuenta Latch

Para parear la aplicación se puede utilizar este pequeño usamos este script de Python que hace el proceso con un sencillo menú para interactuar.

pair.py:

import os
import json
import latch
appid = input("Ingrese el Applicatrion ID:")
seckey = input("Ingrese Secret Key:")

api = latch.Latch(appid,seckey)
pair_code = input("Ingrese el Pairing Code entregado por su celular:")
response = api.pair(pair_code)
responseData = response.get_data()
responseError = response.get_error()

print "Respuesta: ", responseData
if responseError != "" :
 print "Error:" , responseError

try:
    salida=json.dumps(responseData)
except (TypeError, ValueError) as err:
    print 'ERROR:', err

Antes de ejecutar el script debemos iniciar sesión en la aplicación de Latch en el terminal móvil con nuestra cuenta de usuario de Latch y marcar en la opción inferior, Añadir nuevo servicio y luego en el botón: Generar nuevo código. Cuando tengamos el código temporal de pareado visible lanzamos el script pair.py:

~/latch $ python pair.py
Ingrese el Applicatrion ID:"*****hqH3usJ4"Ingrese Secret Key:"j32mbXBfhHUyn*******************CrF"Ingrese el Pairing Code entregado por su celular:"*****Asqg"Respuesta: {u'accountId': u'7z3ZTP6p2H3***************************cHaYwmRQyHrk6JYae'}

Si este paso no muestra errores, la aplicación del terminal móvil indicará que hay un nuevo servicio asociado a nuestra cuenta de Latch. De esta forma hemos apareado la aplicación (nuestro script), con nuestra cuenta de Latch. Tomen nota del accountID, lo necesitaremos más adelante.

Figura 5: Cuenta de Latch pareada con la aplicación

Integrar Latch con el Servidor Nginx: Reverse Proxy permitido o denegado

Llegados a este punto, ya estamos listos para configurar el script que se ejecutara de forma recurrente, cada n minutos por crontab en mi caso, pero que cada uno puede configurar a su gusto. La lógica de este script es:

• Consultar el estado del Latch
• En base al cambio de estado del Latch manipularemos los archivos de configuración de Nginx para que opere como un Proxy Reverso o simplemente como una web con autenticación http.
El primer paso para hacer funcionar este script es reemplazar las tres variables appid, seckey (provistas por la web de latch) y el accid (accountId que anotamos al momento del pareo de la aplicación).
• Luego debemos generar un archivo de configuración de Nginx que bloquee el acceso y otro que lo habilite.

 A continuación un archivo de configuración que configura el Proxy Reverso:

/etc/nginx $ more rproxy.conf.allow

server {
    listen            80;
    return 301 https://$host$request_uri;
}
server {
    listen            443;
    server_name       xxxx.com;

    # Change this to the location you installed lirc_web
    root              /home/nginx/web;
    index             index.html index.htm;

    access_log        /var/log/SSL-rproxy.nginx.log;
    ssl on;
    ssl_certificate /etc/nginx/ssl/server.crt;
    ssl_certificate_key /etc/nginx/ssl/server.key;
    ssl_session_cache  builtin:1000  shared:SSL:10m;
    ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
    ssl_prefer_server_ciphers on;
    location / {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_set_header X-NginX-Proxy true;
        proxy_pass https://sitiointerno:443/;
        proxy_redirect off;
    }
    error_page 401 /401.html;
    location ~ (401.html)$ {
      alias /usr/share/nginx/www/$1;
    }

}

Y este que lo inhabilita forzando a autenticarse :

/etc/nginx $ more rproxy.conf.deny

server {
    listen            80;
    return 301 https://$host$request_uri;
}
server {
    listen            443;
    server_name       x.x.x.x;

    # Change this to the location you installed lirc_web
    root              /home/pi/web;
    index             index.html index.htm;

    access_log        /var/log/SSL-rproxy.nginx.log;
    ssl on;
    ssl_certificate /etc/nginx/ssl/server.crt;
    ssl_certificate_key /etc/nginx/ssl/server.key;
    ssl_session_cache  builtin:1000  shared:SSL:10m;
    ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
    ssl_prefer_server_ciphers on;
    location / {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_set_header X-NginX-Proxy true;
        proxy_pass https://sitiointerno:443/;
        proxy_redirect off;
        auth_basic "Restricted";
        auth_basic_user_file /etc/nginx/.htpasswd;
    }
error_page 401 /401.html;

location ~ (401.html)$ {
    alias /usr/share/nginx/www/$1;
    }
}

Integrar Latch con el Servidor Nginx: Consulta del estado de Latch

Con todos los puntos anteriores revisados y preparados, ya podemos correr este script para confirmar el estado de nuestro Latch:

estado.py:

import os
import json
import latch

appid = "[reemplazar por application id]"
seckey = "[reemplazar por Secret Key];"
accid = "[Reemplazar por account id]"

api = latch.Latch(appid,seckey)
response = api.status(accid)
responseData = response.get_data()
responseError = response.get_error()

#print "Respuesta: ", responseData
if responseError != "" :
 print "Error:" , responseError

try:
    salida=json.dumps(responseData)
except (TypeError, ValueError) as err:
    print 'ERROR:', err

response = json.loads(salida)

estado = response['operations'][appid]['status']
print "Estado:", estado
if estado == "on" :

 print "Ejecutando script de habilitación de Proxy Reverso"
# os.system("diff /etc/nginx/conf.d/rproxy.conf /etc/nginx/rproxy.conf.deny -q >/dev/null && sudo cp -p /etc/nginx/ rproxy.conf.allow /etc/nginx/conf.d/ rproxy.conf && sudo service nginx reload")

else:

 print "Ejecutando script de bloqueo de Proxy Reverso"
# os.system("diff /etc/nginx/conf.d/rproxy.conf /etc/nginx/rproxy.conf.allow -q >/dev/null && sudo cp -p /etc/nginx/rproxy.conf.deny /etc/nginx/conf.d/rproxy.conf && sudo service nginx restart")

Si el resultado es el esperado:

$ python /home/pi/latch/estado.py
Estado: off
Ejecutando script de bloqueo de Proxy Reverso

En este punto sólo es cuestión de descomentar las líneas del script estado.py donde se toma acción sobre el servidor Nginx:

print "Ejecutando script de habilitación de Proxy Reverso"# os.system("diff /etc/nginx/conf.d/rproxy.conf /etc/nginx/rproxy.conf.deny -q >/dev/null && sudo cp -p /etc/nginx/ rproxy.conf.allow /etc/nginx/conf.d/ rproxy.conf && sudo service nginx reload")

else:

 print "Ejecutando script de bloqueo de Proxy Reverso"# os.system("diff /etc/nginx/conf.d/rproxy.conf /etc/nginx/rproxy.conf.allow -q >/dev/null && sudo cp -p /etc/nginx/rproxy.conf.deny /etc/nginx/conf.d/rproxy.conf && sudo service nginx restart")

Por último, ya solo quedaría agregar nuestro script al crontab o similar. En este punto hay algo  que debes tener en cuenta. Si llegaste a este punto puede que te estés dando cuenta de algo muy molesto está pasando con tu terminal. Cada consulta sobre el estado del Latch (cuando este está bloqueado) nos dispara una notificación de intento de acceso no autorizado. Esto es parte de la seguridad de Latch y por ahora no existe la forma de “silenciar” las alertas de un Latch en particular. Como workaround en la configuración de Android he deshabilitado las notificaciones de la aplicación.

Autor: Gonzalo Trancillo

Nota de Chema Alonso: Desde Eleven Paths estamos trabajando en un sistema de silenciado de alertas para evitar el flooding de notificaciones en escenarios como éste. En la modalidad Silver de Latch - que puedes tener gratis si eres una Pyme Española, está disponible vía API la consulta silenciosa.

Nuevo Plugin para FOCA PRO: IIS Short Name Fuzzer

Ya había para la FOCA PRO - y siguen estando disponibles - un plugin para listar los ficheros en formato 8:3 de servidores web con IIS que tuvieran esa vulnerabilidad y un web fuzzer. FOCA detecta la vulnerabilidad de listados 8:3, así que nos parecía fundamental tener ese plugin en su momento. Además, también tiene FOCA PRO un web fuzzer para buscar diccionarios de términos en URLs.

Sin embargo, tras una reciente auditoría de seguridad de una aplicación web en que encontramos esta vulnerabilidad de los servidores IIS del cliente, nos dimos cuenta de que era necesario que funcionaran conjuntamente los tres: FOCA, el Web Fuzzer y el ISS Short Name Scanner. Así que, hemos dedicado unas jornadas de trabajo a desarrollar este plugin que se ha currado nuestro amigo Josemi, y ya está disponible para descarga desde la web de la FOCA. Ya sabes que si quieres conseguir la FOCA PRO, puedes ponerte en contacto con nosotros en i64@infomatica64.com.

Carga del plugin

El nombre del plugin es IIS Short Name Fuzzer (el del icono de IIS) y se puede descargar desde la web de los plugins de la FOCA. El plugin se carga como todos los otros desarrollados para FOCA.

Figura 1: Carga del plugin en FOCA PRO

Configuración

En la parte superior está el menú de configuración. Hay cuatro pestañas para configurar el plugin:

1. En la primera se selecciona la URL a atacar, el tipo de servidor, si se desea utilizar el fuzzer de carpetas para nombres de menos de 8 caracteres de longitud, los diccionarios para reconstruir las carpetas de 8:3 y un listado de USER-AGENTs a utilizar.

Figura 2: Configuración general del plugin

En esta versión, a diferencia del plugin anterior, se soportan 3 tipos distintos de servidores distintos: IIS 5-6, IIS 7 y Ngix (en fase de pruebas aún). A pesar de que en todos más o menos se explota la vulnerabilidad de manera similar, hay variaciones entre ellos. De hecho, el servidor Nginx es también vulnerable a este bug pero no tiene todas las posibilidades que ofrece en los servidores IIS.

2. En la siguiente pestaña se encuentran los controles avanzados de rendimiento, en ellos se puede configurar el número de hilos del fuzzer, el del scanner de short names viene prefijado, el máximo número de hilos concurrentes, el número máximo de reintentos en caso de error en la petición de la URLs y el retraso en el lanzamiento de cada hilo según el tipo.

Figura 3: Configuración de rendimiento del plugin

Hay que tener en cuenta que tanto el scanning de ISS Short name - que es un ataque Blind - como el del fuzzer - que es una fuerza bruta - son intensivos, así que para no tumbar el servidor conviene poder regular la intensidad del plugin.

3. En la parte de los diccionarios aparece la ruta relativa a cada uno de los diccionarios utilizados. Hay que tener en cuenta que el único utilizado en el fuzzer es el que viene indicado con el nombre, el resto se utilizan para recomponer el nombre de archivos y carpetas, (el del USER-AGENT no es configurable) y si se hace doble clic en los textbox aparece un cuadro de dialogo para seleccionar un diccionario propio.

Figura 4: Diccionarios utilizados en el plugin

4. En esta pestaña se pueden configurar parámetros especiales como son el rango de símbolos a probar, el rango de carpetas con el mismo nombre a abarcar y la posibilidad de alterar el comportamiento del programa en caso de que el servidor tenga un tipo de protección que arroje código de redirección en caso de error.

Figura 5: Configuración de caracteres especiales

Guardado y carga manual y automático

De manera automática el plugin está preparado para guardar el progreso del mismo cada 10 minutos en la carpeta “C:\Users\Ususario\FOCA”. Del mismo modo, al arrancar buscará dicho archivo para precargar el estado antes del último cierre*. De modo adicional se presenta la posibilidad de realizar el proceso manual.

Figura 6: Salvar y recuperar un trabajo del plugin

*En el estado actual de desarrollo el plugin es capaz de distinguir entre los elementos analizados y los pendientes de analizar tanto en el fuzzer como en el shorter. No obstante si se cierra la FOCA estando a mitad de analizar una URL, dicha URL aparecerá como no analizada.

Panel de monitorización

En este panel se puede encontrar un resumen sobre el estado del plugin, el número de hilos en uso y la cantidad de elementos encontrados hasta el momento. Es el que muestra un resumen de lo hecho hasta el momento.

Figura 7: Proceso general del plugin

Panel de seguimiento

En este otro panel se puede ver en mayor detalle las peticiones que se están haciendo y otros mensajes sobre el estado del plugin para conocer si está funcionando correctamente o está pasando alguna situación anómala.

Figura 8: Log de queries que está realizando el plugin

Panel gráfico de resumen

Este panel permite apreciar de manera más gráfica los resultados obtenidos mediante un árbol autogenerado a partir del sitio web y las extensiones de los ficheros que causan un comportamiento especial por parte del servidor, generalmente errores 500.

Figura 9: Lista de ficheros descubiertos con el plugin

Integración con la FOCA

Tras iniciar el plugin lo primero que hace es enviarle la URL a la FOCA para que ésta busque en internet elementos como el robot.txt u otras URLs. Después se queda esperando a recibir las direcciones URL reconocidas para pregenerar un árbol de directorios del sitio web ya conocidos y hacer que el escaneo sea mucho más rápido.

Cada vez que reconoce una URL completa y procede a analizarla con el plugin, es devuelta otra vez la URL a la FOCA para que la analice buscando los métodos HTTP soportados, listados de directorios abiertos, ficheros .listing, etcétera.

Resulta obvio, pero digno de mención, que al configurar la FOCA para que use un Proxy, los paquetes generados por el plugin también son redireccionados a través del proxy.

Correcciones manuales

En el mismo panel en el que se encuentran las opciones de carga y guardado se puede acceder a un menú especial que permite interactuar directamente con los resultados obtenidos por el plugin.

Figura 10: Probar nombres manualmente

En dicho panel se muestra un listado desplegable con todas las direcciones URL encontradas y un campo de texto para las sugerencias. Si selecciona la opción “check” el plugin comprobará, de manera muy ligera, la validez de las opciones encontradas, en caso contrario forzará los cambios. El botón “Remove” eliminará la dirección url del plugin y el botón “Apply” procederá a efectuar los cambios.

Saludos Malignos!

Linux/Chapro.A un módulo de malware para Apache

El mundo del malware destinado al fraude online y/o e-crime no para de adaptarse para buscar nuevas formas de infectar equipos, y hacerlo desde servidores web es algo de lo más común desde hace ya más de un lustro usando kits de explotación, como el archifamoso Black Hole. La idea es sencilla, desde un servidor web comprometido - si es popular como la web del sistema postal americano mejor - lanzar un exploit que afecte al software de un cliente que se conecta e inyectar un bot para controlar la máquina desde un panel de control. Sencillo y funcional, así que se sigue haciendo.

Figura 1: Aspecto de un panel de control de Black Hole

Una de las primeras formas de conseguir comprometer los servidores web han sido los bugs de aplicación tipo SQL Injection, RFI, o incluso XSS persistentes para lanzar el exploit a los clientes. Sin embargo no se quedaron ahí, y los bugs en gestores de contenidos populares de blogs, CMS, etcétera, pasaron a ser de los más utilizados - que se lo digan a WordPress, Joomla e incluso a los Moodle -. Con este tipo de ataques se realizaron campañas de infección masiva usando los buscadores - llegando a infectar sitios de renombre como Apple.com en operaciones como Lizamoon -.

Figura 2: La web de Apple fue infectada en un ataque SQLi masivo para distribuir malware

Sin embargo, las cosas no se quedaron ahí y han evolucionado hasta aprovechar cualquier punto de apoyo para conseguir lanzar los exploits desde los servidores web. En el caso de Linux, aparecieron cosas como Linux/Snakso.A, un rootkit a nivel de kernel que modificaba las páginas web enviadas desde servidores nginx o Apache para añadir un iframe que apuntaba al kit de exploits.

El último que ha salido a la primera plana de actualidad en el mundo del e-crime es Linux/Chapro.A, un malware en forma de módulo malicioso de Apache pensado para infectar con un iframe que apunta a un kit de exploits en todas las páginas que sirve el servidor web infectado para instalar bots de Zeus en los clientes que se infecten.

Figura 3: Esquema de Linux/Chapro.A

En este caso en concreto, el kit de exploits que se estaba utilizando era Sweet Orange que, por supuesto, tiene malware y exploits disponibles para equipos con sistemas operativos Windows, Mac OS X y Linux.

Figura 4: Kit de exploits Sweet Orange

Esta idea de utilizar un módulo malicioso de Apache no es nueva, y de hecho se usan como manera de mantener un servidor troyanizado después de una intrusión, como es el caso de mod_rootme, del que ya os hablé por aquí. Si quieres revisar los módulos cargados en tu Apache, en el artículo de Fortificar Apache tienes los comandos para revisar los módulos cargados en tu servidor web.

Saludos Malignos!