Pen-Test: Hardening a Joomla

1. INTRODUCCIÓN.

Tras preparar la máquina virtual para el hackme, voy a aprovechar para explicar una de las posibles formas de hacer hardening de un Joomla. Tal y como hemos supuesto para el hackme, nuestro objetivo será securizar una versión del joomla vieja, ya que la posible incompatibilidad de contenidos hace muy difícil su actualización en un entorno real.

No nos entretendremos en detalles de cómo se instala cada una de las herramientas, sino que nos ceñiremos a la configuración de las piezas más importantes y a cómo hay que poner los IDS para que funcione todo correctamente.

Y sí, este artículo describe el hardening del hackme ...

2. ¿CÓMO FUNCIONA UN SERVIDOR JOOMLA?

Joomla es un gestor de contenido usado por múltiples entidades para publicar sus webs. Consta de un apache con php, una base de datos MySQL y el propio Joomla, que es una aplicación escrita en php.

3. SEGURIDAD DE CADA UNO DE LOS COMPONENTES.

En esta sección revisaremos cada uno de los componentes del servidor e iremos detallando los pasos que hemos seguido para securizar el servidor.

3.1. SECURIZACIÓN DEL APACHE.

Existen numerosos documentos sobre cómo securizar un apache, así que no me voy a entretener demasiado.

Parte de este proceso consiste en ocultar los banners que da el apache, para que el atacante no pueda identificar la versión y sea más difícil lanzar exploits contra el servidor:

ServerTokens ProductOnly
ServerSignature Off

Otro paso importante consiste en reducir la lista de módulos que carga el apache a un mínimo absoluto, por ejemplo mod_userdir puede ser eliminado en este caso, y como él muchos más, cuestión de ir quitando uno a uno mientras se pueda.

También, para "oscurecer" más el servidor, redirigiremos todos los errores a la página principal:

ErrorDocument 400 /joomla/
ErrorDocument 401 /joomla/
ErrorDocument 402 /joomla/
ErrorDocument 403 /joomla/
ErrorDocument 404 /joomla/

Aparte, necesitamos restringir los comandos disponibles a GET, POST y HEAD, añadiendo esto dentro de las opciones de mod_rewrite:

RewriteEngine on
RewriteCond % {REQUEST_METHOD}!^(GET|POST|HEAD)$
RewriteRule .* â [F]



Y por supuesto, las directivas habituales para proteger el acceso a los directorios: que no se pueda leer .htaccess y, además, que no se puedan leer los archivos xml, que son fuente de valiosa información ya que no son interpretados por php.

Con esto, tenemos un apache relativamente seguro.

3.2. MODSECURITY.

Lo primero que hay que hacer, base de todo lo demás, es securizar el apache frente a sql-injection y otros ataques. Para ello, instalaremos mod_security: yum install mod_security.

Tras esto, lo siguiente es configurar mod_security para que la acción por defecto sea hacer DROP y devolver un 404 NOT FOUND, para lo que pondremos esto en modsecurity_crs_10_config.conf: SecDefaultAction "phase:2,log,deny,status:404,t:lowercase,t:replaceNulls,t:compressWhitespace".

Con mod_security, tenemos cubiertos los principales ataques contra nuestra web. No es que no sea posible saltárselo, pero desde luego es lo suficientemento complicado como para que no merezca demasiado la pena intentarlo. Deberemos, eso sí, estar al tanto de todas las actualizaciones que vayan saliendo de mod_security, ya que también hay exploits para las herramientas de seguridad ...

3.3. MYSQL.

La securización de mysql en un entorno como este es relativamente sencilla. Deberemos poner una password fuerte para el root del mysql (que no es el mismo que el root del servidor), borrar la base de datos test y todos los usuarios que estén en blancos. Además, dentro de /etc/my.cnf añadiremos:

skip-networking
set-variable=local-infile=0

La primera línea es para que no escuche en el puerto TCP/3306, sino que sólo va a usar un socket local, con lo que nadie podrá conectarse desde internet (también podemos cerrarlo en el fw, pero mejor así). La segunda evita los comandos típicos del mysql con INFILE, etc para leer y escribir archivos del sistema, que son base de muchos ataques por inyección de código.

Con esto será suficiente. También podríamos renombar el root de mysql a otra cuenta, pero no nos vamos a complicar tanto. Es más importante securizar el joomla.

3.4. PHP.INI.

Dentro del archivo de configuración php.ini, hay una serie de parámetros que podemos usar para configurar nuestra versión del php, los siguientes:

- estos dos hacen que php chequee los permisos de los archivos que "llama"

safe_mode = On
safe_mode_gid = On

- este hace que el php se limite al directorio base donde está instalado joomla, otra nueva medida de seguridad ante LFI (local file include) y similares:

open_basedir = /var/www/html/joomla

- deshabilitamos todas estas llamadas desde el código php:

disable_funcions = php_uname, getmyuid, getmypid, passthru, leak, listen, diskfreespace, tmpfile, link, ignore_user_abord, shell_exec, dl, set_time_limit, exec, system,...

- no damos información en los errores

expose_php = Off
display_errors = Off
display_startup_errors = Off

- ésta evita que nos sobreescriban parte de la memoria del host desde las variables del PHP:

register_globals = Off

- evitamos algunos ataques típicos de sql-injection:

magic_quotes_gpc = On


- evitamos RFI (remote file inclusion):

allow_url_fopen = Off
allow_url_include = Off

Y todavía tenemos alguna que otra más, de menor importancia, pero tampoco hace falta dar demasiado detalle. Si no fuera un gestor de contenidos (supuestamente) con usuarios que pueden subir y bajar documentos, sería conveniente evitar la subida de archivos (file_upload=off) y abrirla sólo para cuando el admin lo necesite. Pero repito que estas son las principales, compatibles con la mayoría de instalaciones de joomla.

3.4. JOOMLA

Una cosa importante cuando se securiza un servidor, y ésta no la pone en ningún libro, es ser un poco cabr**. Vamos a hacer unos "pequeños" cambios en joomla para fastidiar a posibles atacantes. Estoy seguro de que lo agradecerán:

- renombrar la cuenta "admin" a otra cosa, como pueda ser "miadminxxx" o algo así. Con esto, muchos de los exploits no funcionarán, porque se basan en conocer el nombre de la cuenta del administrador de joomla. Además, evitamos ataques por fuerza bruta contra el loggin de joomla.

- borrar todos los archivos de ayuda, archivos puestos por defecto por Joomla. Sobreescribir todas las imágenes de /images/ con las de la última versión (con esto, nos aparecerá el logotipo de Joomla 1.5 en lugar del que de verdad deberíamos tener).

- restringir el acceso a /administrator/ usando htacess (esto no lo he hecho, porque si no sería demasiado difícil)

- mover /administrator/ a /miadministrator/, u otro directorio similar que no sea fácil de encontrar por enumeración.

- impedir el registro de usuarios en el joomla.

Como véis, se pueden hacer unas cuantas cosas.


3.5. SNORT.

Por supuesto, instalaremos nuestro IDS favorito (snort), que en combinación con OSSEC y mod_security harán hackear el servidor una absoluta pesadilla.

Respecto de esto, y dado que la instalación de snort es totalmente trivial, tan sólo quiero señalar que las reglas que estoy usando no son las "ofiales" de snort.org, sino las que dan en emergingthreats.net, que están mucho más actualizadas.

Dentro del servidor, he puesto una tarea automática que se encarga de bajarse cada hora la última versión de las reglas, actualizarlas y reiniciar snort. Con esto, estamos a la última.

3.6. FIREWALL EN LOCAL.

Por si fuera poco, aunque alguien consiguiera romper el servidor tendría realmente difícil establecer una shell inversa: sólo permitimos queries DNS, NTP a un servidor de hora y HTTP para bajarnos las reglas.

La única posible conexión inversa que podríamos establecer sería un tunnel DNS, que no es nada fácil de hacer. E incluso esta conexión de salida podría cortarse, ya que nuestro servidor para nada hacer queries dns.

3.7. OSSEC.

Debo reconocer que, tras instalarlo en el trabajo a diestro y siniestro, le he cogido especial cariño a este HIDS. Es realmente bueno y, si lo configuras bien, puede competir perfectamente con los IDS comerciales.

Instalaremos ossec en local con la opción respuesta activa a "yes", para que bloquee todos los posibles ataques. Una vez instalado, nos aseguraremos de que está configurado de forma que vigila los logs del snort y del apache, que será que sí si lo hacemos en este punto.

Tras esto, añadiremos las siguientes líneas para que lea el log de mod_security:



Con lo cual, en cuanto alguien intente un ataque tipo sql-injection o similar, será banneado en el acto.

4. NOTAS FINALES.

Todavía hay más pasos por detallar en lo que es el hardening del servidor, pero no quiero distraeros con detalles sobre cómo desinstalar software innecesario (por ejemplo netcat), configurar ssh y otras cosas de menor importancia.

Con las medidas adoptadas, tendremos un servidor Joomla bastante seguro, contando con que la versión instalada, que en este caso es la 1.0.X, sea vulneable a todo tipo de exploits. Y no, lo cual suele hacerse pero es un poco ingenuo, contando con que la versión de Joomla es la última que ha salido.


5. APÉNDICE.

Este es el pantallazo de un ataque detectado por mod_security e inmediatamente cortado por ossec:



Como podéis ver, ha devuelto un 404 (NOT FOUND) y ha banneado la IP, con lo que el hacker se estará subiendo por las paredes ...

Y este otro pantallazo es para que veáis como, con un poco de mala leche, puede engañarse al hacker y hacerle pensar que realmente esto es un Joomla 1.5, y no un 1.0, como realmente es:

Fuente: hacking-avanzado

Saludos

Dr.White