Hardening GNU/Linux: "Access Denied" Gold Edition en @0xWord

Cuando un libro de seguridad informática llega a los 5.000 ejemplares impresos, es un hito muy especial para nosotros en 0xWord, y hoy tenemos la alegría de tener la quinta edición del libro de Hardening de servidores GNU/Linux, lo que lo convierte en GOLD Edition para nosotros, así que lo tintamos en oro para reconocer el trabajo de sus autores. Y desde ya, puedes adquirirlo desde la web de 0xWord.

Figura 1: Hardening de servidores GNU/Linux Gold Edición

El mantenimiento de una infraestructura informática segura dentro de una organización grande, mediana o, incluso pequeña es algo complejo. Hay que tener muchos aspectos en cuenta y deben de seguir un modelo o metodología que ayuden al arquitecto y al administrador ha diseñar y preparar a los sistemas y la red a protegerse de las amenazas. En este libro encontrarás un modelo defensa en profundidad para la fortificación y securización de entornos GNU/Linux, que ha sido actualizado a día de hoy.

Figura 2: Libro de Hardening de Servidores GNU/Linux GOLD Edición

(Revisada y Ampliada) de Carlos Álvarez y Pablo González en 0xWord

En el libro se diferencia entre diferentes capas, las cuales serán configuradas y protegidas de forma adecuada en las hojas de este libro. El principal objeto es la seguridad global, dificultando a cada paso los avances de un potencial atacante. Durante el transcurso de esta lectura se ofrecen bases teóricas, ejemplos de configuración y funcionamiento y buenas prácticas para mantener tus entornos GNU/Linux lo más seguros posible. Gracias a la flexibilidad y opciones de los entornos GNU/Linux llegarás a tu objetivo con este libro. Aquí tienes el índice completo del libro subido a SlideShare.

Figura 3: Índice del libro de "Hardening de Servidores GNU/Linux" 4ª Edición

En resumen, este libro está recomendado a todos aquellos que deseen aprender y reforzar los conceptos del fortificación de sistemas, así como para los que necesiten una base desde donde partir a la hora de fortificar un servidor GNU/Linux. ¿Estás preparado para la fortificación? Éste es tu libro.

Figura 4: Puedes contactar con Pablo González en MyPublicInbox

Para cualquier consulta extra, además, tienes a Pablo González en MyPublicInbox, donde puedes estar en contacto con él, y con la gran mayoría de los autores de libros de 0xWord, para que puedas sacar el máximo en tu aprendizaje de estar en contacto con grandes profesionales de la seguridad informática. Y además, recibirás 100 Tempos de MyPublicInbox por la compra del libro, que además puedes utilizar para comprar más libros. Puedes pagar completa o parcialmente este libro con Tempos de MyPublicInbox. Aquí te explico cómo se hace.

Enviar tus Tempos a 0xWord y recibir el descuento

La idea es muy sencilla, hemos creado un Buzón Público de 0xWord en MyPublicInbox y tenemos disponible el módulo de transferencias de Tempos entre cuentas siempre que el destinatario sea un Perfil Público de la plataforma. Para que se puedan hacer estas transferencias, primero debe estar el Perfil Público destinatario de la transferencia en la Agenda.

Figura 5: Perfil de 0xWord en MyPublicInbox. Opción de "Añadir a  la Agenda".
https://MyPublicInbox.com/0xWord

Para dar de alta un Perfil Público en tu agenda, solo debes iniciar sesión en MyPublicInbox, y con la sesión iniciada ir a la web del perfil. En este caso, a la URL del perfil público de 0xWord en MyPublicInbox, - https://MyPublicInbox.com/0xWord - donde te aparecerá la opción de "Añadir a la agenda". Cuando acabe este proceso, podrás ir a la opción Agenda de tu buzón de correo en MyPublicInbox y deberías tener el Perfil Público de 0xWord allí.

Figura 6: Cuando lo agregues estará en tu agenda

Una vez que lo tengas en la agenda, ya será tan fácil como irte a tu perfil - se accede haciendo clic en la imagen redonda con tu foto en la parte superior - y entrar en la Zona de Transferencias. Desde allí seleccionas el Buzón Público de 0xWord, el número de Tempos que quieres transferir, y en el concepto debes poner que es para recibir un código descuento para usar en la tienda de 0xWord.

Figura 7: Zona de Transferencias en el Perfil de MyPublicInbox

No te preocupes por el texto concreto, porque los procesamos manualmente como los pedidos de se hacen en la tienda. 

Canjear 500 Tempos por un código descuento de 5 €

La última opción es bastante sencilla. Solo debes irte a la sección de Canjear Tempos -> Vales para Tiendas, y "Comprar" por 500 Tempos y código de 5 €. Es lo mismo que enviar la transferencia pero en un paquete de 500 Tempos y de forma totalmente automatizada, así que solo con que le des a comprar recibirás el código descuento y lo podrás utilizar en la tienda de 0xWord.com

Figura 8: Canjear Tempos por Códigos para libros de 0xWord

Así que, si quieres conseguir nuestros libros de Seguridad Informática & Hacking aprovechando los descuentos de las ofertas, entre el código de descuento DIALIBRO2023 y los Tempos de MyPublicInbox podrás hacerlo de forma muy sencilla y mucho, mucho, mucho más barato. Y así apoyas este proyecto tan bonito que es 0xWord.com.

Ser escritor de libros de 0xWord

Además, todos lo que queráis convertiros en escritores y hacer un proyecto de libro con nosotros. Podéis también enviarnos vuestra propuesta a través del buzón de 0xWord en MyPublicInbox, y si sois Perfiles Públicos de la plataforma, podéis entrar en la sección de Mi Perfil -> Servicios para ti y solicitar más información sobre el proceso de escribir un libro en 0xWord.

Figura 9: Si eres un Perfil Público de MyPublicInbox

puede solicitar info para escribir un libro en 0xWord

Y si no eres Perfil Público, puedes enviar tu propuesta a nuestra Call For Autores que hemos hecho en 0xWord. Nuestro equipo se pondrá en contacto contigo y evaluará tu proyecto de publicación de libro. Ya sabes que principalmente de Seguridad Informática & Hacking, y puede ser técnico, súper-técnico, o divulgación, y si es una novela... podemos estudiarlo también.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso) (Consigue 100 Tempos gratis con ESET)

La importancia de los laboratorios para aprender hacking y un WAF como modSecurity a prueba

Llevo muchos años siendo docente en diferentes universidades con temáticas de ciberseguridad. He tenido la suerte de poder conocer a muchos alumnos, de poder motivar a muchos de ellos y de poder hacerme amigos de mucha gente con un gran potencial. Para mí ha sido y es un orgullo poder decir que he tenido muchas horas de vuelo en las clases y que creo que un porcentaje alto de alumnos han estado contentos conmigo y con lo que he podido transmitirles.

Figura 1: La importancia de los laboratorios para aprender

hacking y un WAF como modSecurity a prueba

Siempre he hablado de la importancia que tiene que un alumno no se limite a observar al profesor, cuando éste les muestra un ejemplo para afinar el conocimiento. El alumno debe actuar y poner a prueba lo que le cuentan, lo que le muestran, lo que le enseñan. Es importante que los alumnos levanten sus contenedores de Docker, sus máquinas virtuales, sus entornos privados para probar sobre sus recursos lo que les enseñan.

Figura 2: Libro de Docker: SecDevOps de
Fran Ramírez, Rafael Troncoso y Elías Grande

Muchos me habrán escuchado decir que no vale de nada que yo lo haga, que yo ya lo hice muchas veces, que tienes que probarlo tú, hacer el conocimiento tuyo, hacerlo interno, entenderlo a base de encontrarte problemas cuando al profesor no se le presentaron dichos problemas. Creo que en algún minuto de este video se puede ver justo lo que comento.


Figura 3: Pablo González en CiberCamp 2018: Aquellos años locos
No creáis que hoy me he levantado nostálgico o que voy a dejar algo que me llena tanto como seguir conociendo al talento, al potencial que hay detrás de cada historia que se sienta a ver lo que éste joven les tiene que contar. Solo quería dar pie al artículo técnico que quería contar hoy y es que hoy quiero hablar de la importancia de montarte tus laboratorios y aprender.  Hoy quiero dar respuesta a algunas consultas que me llegan y que me preguntan por mi buzón de MyPublicInbox por algún consejo para aprender, para iniciarse, para entrar en este mundo tan apasionante, por consultas de alguno de mis libros, etcétera. 

Figura 4: Libro de Hardening de Servidores GNU/Linux 4ª Edición

(Revisada y Ampliada) de Carlos Álvarez y Pablo González en 0xWord

Muchos no saben que simplemente con su curiosidad y con sus ganas ya están dentro de este mundo.  Aprovechando que acaba de salir la 4ª Edición del libro de Hardening Servidores GNU/Linux donde yo participo, hoy quiero hablar de ModSecurity, quiero montarme mi laboratorio con dos, tres máquinas y mostrar cómo sería eso de “móntate tu entorno y prueba, aprende”. Lo primero es tener claro que queremos montar:

- Una máquina Ubuntu a la que instalaremos modsecurity. 

 

- Una máquina Kali Linux 2020 a la cual llamaremos “la mala”.

- Un entorno web vulnerable al que ayudaremos a proteger.

Hay que tener en cuenta que poner un WAF (Web Application Firewall) no es exactamente solventar los problemas de seguridad. Los problemas de seguridad del entorno web seguirán estando ahí, aunque el WAF nos proteja de ciertas situaciones. Por esto, es interesante que en las auditorías web se prueben con y sin WAF activado. La falsa sensación de seguridad que nos puede dar un WAF puede ser un fallo de concepto de nuestra apreciación.

Instalando ModSecurity: Manos a la obra

Vamos a instalar ModSecurity. Haremos un resumen y una instalación sencilla, ya que el proceso se puede complicar hasta límites, en algunos casos, insospechados. A continuación, se resumen el proceso de instalación de un Apache con     :

- Instalar apache2 y modsecurity a través de Ubuntu con apt install. Ejemplo: apt install apache2 libapache2-mod-security2. 

 

- Tras instalar apache2 y la librería de modsecurity hay que verificar que modsecurity está habilitado. Para ello se puede hacer uso de apachectl -M. con esta instrucción podemos verificar que modsecurity se encuentra instalado, incluso podríamos filtrar con un grep para encontrar entre todo lo disponible.

Figura 5: Instalación de Apache

- Encontramos el módulo security2 con el valor “(shared)”. 

 

- Si es así, parece que todo ha ido bien, toca configurar modsecurity.

La configuración de modsecurity se puede llevar a cabo a través del fichero /etc/modsecurity/modsecurity.conf. Hay varias cosas que debemos mirar y revisar en este fichero que vamos a ver a continuación.

Figura 6: modsecurity.conf

La primera regla y la más importante es SecRuleEngine que habilita modsecurity. Después, modsecurity tiene un conjunto de reglas por defecto, las cuales se encuentran en el directorio /usr/share/modsecurity-crs. Es altamente recomendable descargar reglas actualizadas desde repositorios de Github, con ejemplos para aprender. 

Un ejemplo de repositorio a tener localizado es el de SpiderLabs con Owasp-modsecurity-crs. Ahora se conoce como OWASP Modsecurity Core Rule Set. Para poder descargarlo se puede hacer uso de git clone. Una vez descargado se puede copiar el fichero de configuración a /usr/share/modsecurity-crs/crs-setup.conf. 

Figura 7: modsecurity core rule set en Git Hub

Ahora se puede configurar dichas reglas editando el fichero security2.conf que se encuentra en el directorio /etc/apache2/mods-enabled. Debemos añadir un par de IncludeOptional en el fichero security2.conf.

o IncludeOptional /usr/share/modsecurity-crs/*.conf. 

 

o IncludeOptional /usr/share/modsecurity-crs/rules/*.conf.

Una vez hecho todo esto, debemos reiniciar el servicio de Apache2 y tendremos listas las nuevas reglas descargadas y ModSecurity. 

Probando ModSecurity: Entorno con dos máquinas

Lo primero es definir qué tendremos en la máquina Ubuntu, en este caso tenemos una aplicación web vulnerable y nuestro apache con la librería de modsecurity. Hemos montado un DVWA sobre Ubuntu, la instalación se puede encontrar fácilmente. Nuestro modsecurity protegerá al DVWA y se podrá estudiar el funcionamiento del WAF in situ. En este ejemplo vamos a utilizar uno de los ataques a aplicaciones web más conocidos y del que Chema Alonso escribió un libro junto con Enrique Rando: Los ataques de SQL Injection.

Figura 8: Libro Hacking de Aplicaciones Web: SQL Injection 3ª Edición
de Chema Alonso y Enrique Rando en 0xWord

 

Esto es algo vital, enfrentarse a las situaciones, a los entornos, es una forma interesante de aprender y encontrarse con la realidad, por compleja que pueda parecernos. DVWA (Damn Vulnerable Web Application) es un entorno de pruebas para practicar y entender las vulnerabilidades web. Una de las cosas interesantes de este entorno es que se puede ver el código web con diferentes niveles. Es decir, si tenemos un SQL Injection se puede ver en diferentes dificultades, diferentes errores en el código que introducen en la aplicación el SQL Injection. Sin duda, interesante para aprender.

Figura 9:  Aplicación DVWA

Con la configuración de DVWA en modo fácil, en la última versión hay 4 niveles, introduciendo una comilla veremos como se genera un error de sintaxis. Si aplicamos un ‘or’1’=’1 veríamos los datos de la tabla a la que se consulta. Seguramente sea el SQL Injection más sencillo y más intuitivo. Perfecto para aprender.

Figura 10: Resultado del SQL Injection Level 1

Ahora habilitamos modsecurity a través del fichero /etc/modsecurity/modsecurity.conf. Habilitamos la opción SecRuleEngine y la ponemos a ON. A partir de aquí todo el tráfico pasará por las reglas de modsecurity que descargamos y añadimos en los apartados anteriores. Ahora veremos que cuando se intenta llevar a cabo la misma operación el resultado es un “forbidden”.
 

Figura 11: modsecurity funcionando

Una forma de aprender cómo funcionan, no solo los ataques de SQL Injection, sino todas las técnicas de Hacking Web Technologies, e incluso se pueden ver los ataques Client-Side que pasan por un servidor web, y como un WAF puede ir trabajando sobre ellos para protegernos es éste. Aplicando a diferentes tipos de ataques en plataformas como DVWA se puede aprender y mucho. Siempre pensando en el ataque y en la protección. En la vida real te encontrarás protecciones y tendrás que conocer cómo funcionan para poder aplicar bypasses. Eso lo dejamos para otra historia.

Saludos,

Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell”, "Pentesting con Kali Silver Edition" y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González - Conseguir 100 Tempos Gratis en MyPublicInbox

 Contactar con Pablo González

Apache: Server-Side Session Hijacking con Virtual Hosts hackeados (2 de 2)

Tras haber concluido la primera parte de este artículo, espero haberte dejado intrigado y con ganas de saber cómo se podría hacer un Server-Side Session Hijacking en esa aplicación corriendo sobre un servidor Apache con PHP que hemos dejado bastante fortificado, así que espero que la segunda parte te responda a esa pregunta con algo de información nueva.

Figura 21: Server-Side Session Hijacking con Virtual Hosts Hackeados (2 de 2)

El truco que se puede utilizar es uno bastante sencillo, que está ahí, en muchos servidores Apache que corren sobre servidores GNU/Linux, y consiste en usar una de las características más conocidas de estos sistemas operativos.

Valor simbólico

Hay, al menos, una forma de "traernos" la aplicación víctima al servidor del atacante. Y la que se me viene a la cabeza utiliza una característica del sistema de ficheros: los enlaces. El usuario "net" no puede crear un enlace duro (hard link) al script "index.php" de la aplicación víctima ya que carece de los permisos necesarios. Pero no hay problema para crear enlaces simbólicos. De modo que si ejecutara un comando como el que sigue:

ln -s /var/www/html/com/index.php /var/www/html/net/app.php

...creando un enlace en el virtual hosts del atacante que respondería ante una petición del tipo:

http://danger.example.net/app.php

... entonces el servidor Apache se encontraría con el enlace simbólico:

 "/var/www/html/net/app.php".

Y en esa situación, lo que pueda hacer con él dependerá de la configuración que tenga establecida. Lo más frecuente, y lo que me encuentro en este caso, es que esté activada la opción FollowSymLinks. Esto quiere decir que Apache seguirá el enlace simbólico que le llevará a "/var/www/html/com/index.php".

Y lo abrirá con los permisos de su propietario, "com", y comenzará a interpretarlo. Pronto llegará a una sentencia que da más de pensar de lo que a primera vista parece:

require_once "include/login.inc.php";

Vale. Necesitamos leer el fichero "include/login.inc.php". Pero ¿de qué directorio? La documentación de PHP señala que, para cosas como "require_once" que leen ficheros, existen tres posibilidades:

- Que la ruta de fichero sea absoluta. Del tipo "/var/www/html/index.php". En este caso, está claro el fichero que hay que leer. 

- Que la ruta de fichero comience con "./" o "../", para el caso de sistemas *nix, o ".\" o "..\" para Windows. Entonces la ruta se considera relativa al directorio actual. 

- En otro caso, PHP utiliza una variable de configuración llamada "include_path" que contiene una lista de directorios. Si no encuentra el fichero a cargar en ninguno de ellos, lo intenta con el directorio en el que se encuentra el script. Y, si aún sigue sin encontrarlo, busca en el directorio de trabajo actual.

En el caso de la aplicación víctima tenemos esta última situación. Con una condición curiosa:

- El directorio del script, el que se pidió a Apache, es "/var/www/html/net", controlado por el atacante. 

- El directorio de trabajo es "/var/www/html/com". El de la aplicación víctima.

Gracias a esto, el atacante podría redefinir algunos de los ficheros utilizados en los "require", "require_once", etcétera.

Figura 22: Documentación de inlude & require en PHP

Para ello le basta con crear en su directorio una estructura de directorios similar a la de la aplicación, crear en ella los ficheros que necesite "ajustar" a sus necesidades y asegurarse de que el usuario "com" puede acceder a todo ello. Para lo que necesite la aplicación y no se halle en los directorios del atacante, ahí estará PHP, que se encargará de buscarlo en el directorio de la propia aplicación víctima.

Al ataque

Ya sabemos lo que hay que hacer, de modo que tomamos la shell PHP y nos ponemos a ello. En este caso, redefinimos sólo el fichero "login.inc.php" en el lado de la aplicación atacante para que, sin necesidad de hacer nada, nos cree una sesión con privilegios de administrador:

Figura 23: Creando el login.inc.php alternativo

Aunque los nuevos "app.php" y "login.inc.php" estarán alojados en "/var/www/html/net", el usuario "com" podrá leerlos. Ahora, si visitamos "http://danger.example.net/app.php"...

Figura 24: Accediendo a las opciones de administración

En la imagen superior puede observarse que hemos conseguido acceder a las funcionalidades de administración de la aplicación. Además, la información de diagnostico indica que el proceso está ejecutándose con la cuenta "com".

Por otro lado, en la parte inferior se aprecia que se han usado las herramientas para desarrolladores para obtener el valor de la cookie que se acaba de recibir. Una cookie a la que el usuario "com" sí podrá acceder, pues fue él mismo quien la creó. De modo que, si ahora cargamos "http://webserver.example.com" y se la forzamos:

Figura 25: Forzado de la cookie de sesión

Y ahora, si recargamos la página, obtenemos las opciones de administración.

Figura 26: Hemos hecho el Server-Side Session Hijacking desde
un virtual host hackeado en un Apache con seguridad mejorada.

Y podremos seguir con nuestra sesión sin problemas. Y con privilegios de administración. Así que la fortificación de Apache no ha sido todo lo eficaz que deberíamos esperar, y hay que hacer alguna cosa más para evitar este tipo de ataques. Vamos a ver qué se podría hacer.

Tratar de arreglar las cosas

En casos como éste, poner soluciones es tarea tanto de los desarrolladores de la aplicación como de los administradores del servidor. Y, además, ambos deben tratar de afrontar todos los posibles problemas: ni los desarrolladores deben dar por supuesto que los administradores han configurado el equipo de forma segura. Ni los administradores deben confiar en que las aplicaciones que instalan están bien desarrolladas.

Los desarrolladores podrían haber cambiado las rutas de las que se hace el "require_once" y haberlas convertido en absolutas. Con valores como "/var/www/html/com/include/login.inc.php", poco margen habría quedado para la manipulación.

Debe señalarse que en este caso de nada habría servido que las rutas se hubieran indicado de forma relativa comenzando con "./". Como en "./include/login.inc.php". De hacerlo, las peticiones realizadas a "http://danger.example.net/app.php" serían servidas tomando "/var/www/html/net" como directorio base y al atacante le habría bastado con redefinir - o crear enlaces simbólicos a - todos los ficheros en el directorio "include" de la aplicación víctima.

Figura 27: SymLinksIfOwnerMatch en documentación de Apache

En cuanto a los administradores, hay que recalcar que el uso de "FollowSymLinks" podría haber sido sustituido por "SymLinksIfOwnerMatch", que sólo sigue los enlaces simbólicos si el propietario del enlace es el mismo que el del fichero de destino. Algo que, por otro lado, aparece etiquetado muchas veces como poco recomendable en Internet por sus efectos sobre el rendimiento.

Otra importante mejora sería utilizar "ruid2" en modo "config". Para ello, en el fichero "apache.conf" habría que sustituir el RMode stat por RMode config y añadir unas líneas a la configuración de cada sitio virtual en el fichero "/etc/apache2/sites-enabled/000-default.conf", dejándolo como sigue:

Figura 28: Configuración de sitios virtuales modificada

De este modo se asegura que todo lo que se pida usando el nombre de servidor "danger.example.net" va a ser procesado usando los privilegios de la cuenta "net" y el grupo "net", lo cual evitaría la escalada de privilegios mostrada anteriormente.

Pero quizá pudiera hacer posible otras). Por ejemplo, si se pudiera crear un fichero en una carpeta cualquiera de otro host... ¿quién sabe?. Y pueden presentarse otros ataques de naturaleza diferente que pudieran terminar consiguiendo el mismo efecto. U otro distinto. Puestos a aislar, quizá lo mejor sea dejarse de complicaciones y utilizar una máquina, posiblemente virtual, para cada aplicación. Y, aún así, nunca se sabe.

Conclusión

Al final, la aplicación sí era vulnerable. Muy vulnerable. Al menos, bajo ciertas condiciones. Algo que no es poco frecuente. Los desarrolladores crean un producto y, según lo finalizan, suelen perder control sobre él. No pueden determinar completamente en qué circunstancias está siendo utilizado, qué configuraciones le dan soporte, qué entorno lo rodea, etcétera.

Todo esto que no pueden controlar, deben tratar de preverlo en las etapas de diseño. Ponerse siempre en el peor de los casos: cuando todo falla y, además, hay alguien que intenta sacar partido.

Hablando de la aplicación utilizada en este artículo, los desarrolladores posiblemente deberían, entre otras cosas, haber tomado medidas que evitaran el acceso a las variables de sesión, tanto para lectura como para escritura, por parte de otras aplicaciones. Quizá, cifrando su contenido y manteniendo un hash que permitiera detectar cualquier cambio no autorizado.

Al fin y al cabo, estamos hablando de "confidencialidad" e "integridad". Y eso es parte de la seguridad. Pero, ¿cómo de frecuente es encontrarse estas medidas de protección? ¿y cómo de habitual el no encontrarlas? Si tienes experiencia, tú tendrás una buena estimación.

ANEXO: La aplicación

Solo por responder cualquier duda que pudiera salir, os dejo los códigos utilizados en esta aplicación, para que podáis tener toda la información de lo que se ha presentado en este entorno

Figura 29: Index.php

Figura 30: include/Login.inc.php

Figura 31: include/app.inc.php

Figura 32: include/diag.inc.php

Figura 33: js/1.js

Autor: Enrique Rando, escritor de los libros "Hacking con Buscadores", Hacking Web Applications: SQL Injection y "Hacking Web Technologies" de 0xWord.

Apache: Server-Side Session Hijacking con Virtual Hosts hackeados (1 de 2)

El artículo de hoy, que por su extensión estará dividido en dos partes, comienza con una pregunta que me surgió el otro día cuando me encontraba mirando cosas por si hay que escribir la siguiente parte de nuestro libro de Hacking Web Technologies y me topé por ahí una aplicación que, a pesar de todas las protecciones que trataba de implementar, permitía subir archivos de cualquier tipo a una carpeta publicada por el servidor web. No hace falta decir que eso no es bueno.

Figura 1:Server-Side Session Hijacking con Virtual Hosts Hackeados (1 de 2)

Un atacante podría aprovechar esta vulnerabilidad para mil cosas distintas y todas perversas: desde alojar o promocionar en host ajeno su propia web de venta ilegal de fármacos, hasta colocar una shell con la que ejecutar comandos de forma remota. Tal interfaz de comandos le permitiría atacar, no sólo a la aplicación vulnerable sino también al propio servidor - de lo que por esta vez nos olvidaremos -, sino también a otras aplicaciones que pudieran estar alojadas en él. Lo cual obliga a hacerse, entre otras, las siguientes preguntas:

- ¿Cómo proteger a una aplicación frente a otras que estén alojadas en el mismo servidor?

- ¿Qué medidas debe implementar la propia aplicación para protegerse de estos problemas?

Si no se encuentran las respuestas correctas, la seguridad final de todas las aplicaciones podría quedar comprometida. Si sólo se responde a una de ellas, posiblemente queden resquicios por los que alguien se podría colar. Si los desarrolladores dejan de implementar una protección porque la creen innecesaria, dado que "los de sistemas" configuran la seguridad del servidor de forma ideal, más temprano que tarde encontrarán un caso en que su suposición era incorrecta. Incluso aunque la aplicación venga con instrucciones precisas sobre cómo hacerlo. Y si los de sistemas confían en que las aplicaciones que instalan en sus servidores no presentan ni suponen problemas de seguridad... es que llevan poco tiempo en el negocio.

Escenario

Para explorar un poco, me planteé un escenario en el que un servidor web Apache con PHP tiene configurados dos servidores virtuales en dominios distintos. El primer dominio, "webserver.example.com", tiene una aplicación web de la que no se conoce - aún - ninguna vulnerabilidad. El directorio del servidor en que está alojada es "/var/www./html/com". Para no entorpecer demasiado la lectura, se dejará para el final su listado completo. Baste por ahora con señalar que viene de fábrica con tres cuentas de acceso:

Figura 2: Cuentas en el servidor de Apache

Y cuyo script principal "index.php" tiene el siguiente código:

Figura 3: index.php que gestiona los accesos y las sesiones a la aplicación

Dependiendo de si utilizas una cuenta de administrador o una de usuario, la aplicación ofrece distintas funcionalidades, tal y como se puede ver a continuación:

Figura 4: Inicios de sesión con diferentes cuentas de usuario

Del otro dominio, "danger.example.net", se supone que tiene una vulnerabilidad que permite subir ficheros con cualquier extensión. O que, sencillamente, está bajo control de un atacante. El directorio en que está alojado es "/var/www/html/net". En él se habrá colocado una sencilla shell PHP cuyo código se muestra en la siguiente imagen:

Figura 5: Shell PHP en el sitio web controlado por el atacante 

Simple, pero efectiva.

Cuentas separadas

En la configuración por defecto de Apache - aun sin pasar un proceso de fortificación - , éste utilizará una misma cuenta, "www-data" en el caso de Ubuntu, para acceder a ambos servidores virtuales. Unas condiciones en que poco se podrá hacer desde el punto de vista defensivo: La shell será capaz de leer los scripts de la aplicación víctima y obtener sus parámetros de configuración y cuentas de acceso a bases de datos, etcétera. Una información que después se podría utilizar para ejecutar instrucciones, modificar las tablas, u otras acciones de ataque.

Figura 6: lectura de ficheros del servidor

Con esto, el atacante tendría ya ganada la partida. Pero, a meros efectos ilustrativos, es conveniente presentar en este punto un ataque que pone de manifiesto la forma en que PHP usa las cookies. Todo empieza cuando el atacante abre su shell y la utiliza para crear una sesión en "danger.example.net" y poblarla con unas variables similares a las que utiliza la aplicación víctima:

Figura 7: Creación de cookies en la aplicación a través de la shell

Tras pulsar el botón "OK", las instrucciones se ejecutarán y realizarán su cometido. Hecho esto, el atacante abre las herramientas para desarrolladores (las de la tecla F12) y utiliza la consola para obtener el valor de la cookie de sesión:

Figura 8: Accediendo a la cookie generada en el cliente

Entonces, visita "webserver.example.com" y se encuentra con la página de inicio de la aplicación víctima. Pero, en lugar de introducir sus credenciales, vuelve a utilizar las herramientas para desarrolladores. Esta vez para asignar el valor de la cookie de sesión y forzar el valor obtenido en el paso anterior:

Figura 9: Se modifica la cookie de la web víctima con el valor de la cookie en la web del atacante

Ahora, refresca la página con F5 y ¡ya es administrador! Lo cual indica nuestro PHP, cuando recibe una cookie de sesión, no se pregunta de dónde - de qué dominio - le llega.

Figura 10: La web reconoce la cookie como si fuera de este servicio

En las siguientes pruebas se utilizará un módulo de Apache denominado "ruid2" que ayuda a mitigar estas situaciones. Con "ruid2", cada petición HTTP es servida por un proceso que se ejecuta utilizando la cuenta del usuario propietario del fichero correspondiente. O sea, que si el propietario del fichero "index.php" es "usuario", cuando alguien lo solicite, Apache lo abrirá en un proceso con permisos de "usuario".

Y, antes de que alguien pregunte: con "root" se hace una excepción. Los ficheros de "root" se ejecutan con permisos de "www-data". Lo contrario podría tener efectos devastadores. En definitiva, será necesario crear una cuenta de usuario en el sistema para la aplicación víctima y otra para la aplicación maliciosa. Y después asignar propietarios, grupos y permisos de forma que esta última no pueda acceder a los ficheros y directorios de la primera.

Entorno de pruebas

Para experimentar un poco preparé una máquina virtual nueva. Instalé en ella Kubuntu y le dejé instalar las últimas actualizaciones. Después le añadí Apache, PHP y el módulo ruid2 con unas pocas órdenes lanzadas desde la shell:

sudo apt-get update
sudo apt-get install apache2
sudo apt-get install php
sudo apt-get install libapache2-mod-ruid2

Con ello basta para tenerlo todo instalado, configurado y habilitado. A continuación, creé las dos cuentas de usuario a utilizar por las aplicaciones,  con el objeto de tener un entorno fortificado de Apache sobre GNU/Linux.

adduser comadduser net

Para configurar los servidores virtuales, abrí el fichero "/etc/apache2/sites-enabled/000-default.conf" y lo dejé como sigue:

Figura 11: Configuración de virtual hosts

Y para habilitar el uso de ruid2, añadí unas líneas al fichero "/etc/apache2/apache2.conf".

Figura 12: Configuración mod_ruid2.c en Apache

Después tocó reiniciar Apache con un simple sudo service apache2 restart. Finalmente, asigné propietarios, grupos y permisos a la aplicación y la dejé como se ve en la imagen siguiente:

Figura 13: Configuración de permisos en ficheros y carpetas. En general: usuario "com", grupo "com"
y permisos totales sólo para el propietario del fichero.

Las execpciones son el propio directorio principal ("com") y su subidrectorio "js". Porque Apache ("www-data") necesita poder pasar por estos directorios (permiso de "ejecución") para poder llegar a determinados ficheros, como "1.js".

En cuanto al directorio del otro servidor virtual, tenemos algo similar pero utilizando una cuenta distinta:

Figura 14: permisos de ww-data

Eso por lo que respecta al servidor. En cuando a lo que tiene que ver con cliente de las pruebas, que se supone que es el equipo del atacante, habrá que crear unas entradas en el fichero "hosts":

192.168.94.10 webserver.example.com
192.168.94.10 danger.example.net

Esa fue la IP que yo utilicé para mi máquina virtual. Si tú utilizas otra(s)...

Cookies y permisos

Por defecto, PHP usa ficheros para almacenar los valores de las variables de sesión. La shell PHP permite comprobar si así ocurre en este caso particular:

Figura 15: Protección de directorios para las variables de sesión

Como cabe esperar, el directorio utilizado para ello tendrá unos permisos que impidan listar su contenido:

Figura 16: Listado de contenido protegido

Y esto es importante. Porque los ficheros con los datos de la sesión tienen un nombre que incluye el valor de la cookie de sesión (típicamente, PHPSESSID). De modo que, si fuera posible listar el directorio, bastaría una orden del tipo "ls /var/lib/php/sessions" para hacerse con todas las cookies de sesión del servidor. Cosa poco deseable. Salvo para el atacante, claro.

Por otro lado, si se inicia sesión en la aplicación víctima, la información de diagnóstico mostrará que, gracias al módulo "ruid2", está siendo ejecutada con su propia cuenta:

Figura 17: La aplicación se ejecuta con su propia cuenta

Ojo al grupo, que es "www-data". Que, si uno no tiene cuidado al asignar grupos y permisos a los ficheros, este detalle puede ser de lo más relevante. Y obsérvese el valor de la cookie. En el directorio de las variables de sesión aparecería el correspondiente fichero cuya configuración de seguridad lo haría inacccesible a todo usuario menos para "com" (y, por supuesto, para "root" y quienes hagan un "sudo"):

Figura 18:  Sesiones solo accesibles a dueño y root

También la shell PHP se ejecutará con los permisos correspondientes al fichero que la aloja:

Figura 19: Shell ejecutada con sus propios permisos

Como puede observarse, se trata del usuario "net", que no tiene permisos para leer la cookie creada por la aplicación víctima. De modo que, aunque forcemos la cookie y le pongamos la misma que tiene dicha aplicación, la shell PHP será incapaz de leer o escribir las variables de sesión.

Figura 20: No se pueden leer o escribir variables de sesión

Por otro lado, PHP rehusa leerlo o escribir en una cookie cuyo propietario no sea el mismo usuario con el que se está ejecutando el script. De modo que tampoco valdría generar las variables de sesión desde la shell PHP, asignar permisos sobre el fichero de sesión que hagan posible su lectura por "com" y forzar la cookie para "webserver.example.com". Además, el usuario "net" no tiene privilegios suficientes para cambiar el propietario o el grupo de sus ficheros de sesión e intentar asignárselos a "com".

Reflexión intermedia

Llegados a este punto, todo parece apuntar a que:

- Los permisos de ficheros y carpetas impiden que la shell PHP pueda leer el contenido de los scripts de la aplicación. 

- La shell PHP no puede leer ni escribir las variables de sesión de la aplicación. 

- La shell PHP no puede crear un conjunto de variables de sesión que después puedan ser forzados a la aplicación víctima.

Entonces... todo está bien ¿verdad?

La respuesta es: NO

Y no hacía falta demasiada agudeza para darse cuenta: Si todo estuviera bien, este post no estaría publicado en este blog, pero deberás leer la segunda parte para conocer el resto de la historia.

Autor: Enrique Rando, escritor de los libros "Hacking con Buscadores", Hacking Web Applications: SQL Injection y "Hacking Web Technologies" de 0xWord.