#MundoHacker: Aprendiendo un poco sobre exploits en páginas web

Volvemos nuevamente con una entrada de la serie #MundoHacker, destinada a ofrecer un acercamiento a los principales vectores de ataque informático, esta vez centrada en profundizar en la seguridad web.

pentester

¿Y qué mejor manera de aprender que con una colección de ejercicios con solución incluida?

PentesterLab es un proyecto destinado al aprendizaje de técnicas de intrusión en diferentes plataformas y ecosistemas, y que recientemente ha incluido en su haber una muy jugosa colección de ejercicios para principiantes que vienen como anillo al dedo para nosotros los desarrolladores para entender qué debemos hacer y qué no a la hora de segurizar una web.

En Web For Pentester encontraréis la descarga de un archivo .ISO que contiene el desarrollo de una web de ejercicios bajo Debian. Así mismo, tenéis a vuestra disposición un PDF con la documentación y explicación de cada ejercicio, aunque éste último recomiendan usarlo únicamente después de haberte peleado un tiempo con cada problema.

El PDF contiene información realmente interesante para conocer de primera mano, con ejemplos reales, las técnicas de intrusión usadas para atacar webs, y que a continuación resumiré brevemente.

Ataques XSS o cross-site scripting

En español tendría un nombre parecido a Secuencia de comandos en sitios cruzados (ahí es nada…), y viene a definir uno de los ataques más comunes, que busca vulnerabilidades que permitan ejecutar código JavaScript (principalmente, aunque podría tratarse de cualquier lenguaje de cliente).

Este tipo de ataques los vemos tanto en webs como aplicaciones locales, y muchas veces en el propio navegador, que queda abierto para el robo de credenciales de acceso y demás información confidencial (historial de navegación, cookies,…).

Existen dos métodos de ataques XSS,

  • Directo o persistente: consiste en embeber código en algún sitio de la web (formularios, comentarios,…) que permita a a su vez ejecutar código. Se ve mucho con etiquetas HTML en comentarios (que normalmente están permitidas), y que estas a su vez ejecutan comandos Java.
  • Indirecto o reflejado: Normalmente se usa la misma URL para inyectar un frame, de tal forma que una web del tipo www.example.com/home.asp?frame=menu.asp, podría ser vulnerable al inyectarle en el frame código ajeno. Se usa sobre todo para casos de Phishing (entras en una web, pero en verdad te están redirigiendo a otra).

Paradójicamente, tenéis un tutorial muy sencillo de entender en la Wikipedia.

RFI o inclusión remota de archivos

Poco hay que decir sobre este ataque. Se puede llevar a cabo en aquellas webs que permiten la subida de archivos. Es quizás la vulnerabilidad más sonada de PHP (en ASP no se puede dar ya que no contempla funciones de inclusión), y se basa en aprovecharse del potencial de include() para enlazar contenido alojado fuera del servidor en el propio dominio.

La forma de defenderse es realmente sencilla, y puesto que se aprovecha de una familia de funciones, basta con restringir su uso al estrictamente necesario, mediante la validación de la variable enviada como parámetro (URL o formatos permitidos).

De nuevo os dejo la explicación de la Wikipedia.

Ataques LDAP

Alguien te dice LDAP y te quedas a cuadro. Pero seguramente si os hablo de Active Directory, ya vais entendiendo por donde van los tiros. El Active directory es el LDAP que usa Windows (a groso modo, no me matéis todavía), es decir, el encargado de las listas de acceso de un dominio o red determinado.

Un ataque de este tipo lo que busca es hacerse con el control del sistema de validación de usuarios, de tal forma que así podremos crear o modificar los usuarios de una web, y acceder a contenido que de base estaba oculto mediante permisos.

Para ello, se suele usar la picaresca (como ya hemos explicado en la entrada sobre SQL injection), forzando al servidor a devolvernos la contraseña de un usuario al incluir el usuario.
string nombre = Request.Querystring("nombre")
String ldapSearchQuery = "(cn=nombre)(|(password=*))

A esto únele una biblioteca de nombres, un poco de tiempo, y ya tienes un script para acceder a foros muy concurridos.

La forma de defenderse pasa por validar (de cara al servidor, por favor, no uséis JavaScript) cada parámetro de entrada (vamos, lo mismo que en SQL injection, pero en vez de con SQL, con el LDAP que estemos usando).

Tenéis un tutorial muy completo (5 entradas) en el blog de Chema Alonso.

SQL injection

Son ataques hacia una base de datos SQL. Ya he dedicado una entrada completa a este tipo de ataques (debido principalmente a que son de los más usados), por lo que doy por zanjado el tema.

Code injection

Hablamos normalmente de SQL injection, por ser lo más habitual, pero en la práctica se podría aprovechar cualquier vulnerabilidad para inyectar código, sea del lenguaje que sea (siempre y cuando el servidor lo contemple).

Debido a que crear medidas contra todos y cada uno de los lenguajes habidos y por haber es una locura, la mejor defensa contra inyecciones de código es tener la plataforma en la que se ha desarrollado actualizada (muy atentos sobre todo a plataformas open source como los típicos CMS que todos usamos, y que debido a ello, son las más atacadas).

La mayoría de actualizaciones menores de servicios como WordPress, Joomla y compañía vienen a solucionar vulnerabilidades 0-day, así que ya sabéis.

File upload

Se parece bastante al RFI, aunque en este caso afectaría a cualquier plataforma de subida de archivos, ya que usa como método de entrada hacerse con el control de la shell que lo gobierna.

Os dejo con un vídeo donde se ve en funcionamiento el ataque:


Seguramente en este punto ya os habréis dado cuenta que la mejor forma de defenderse de ataques file upload es restringiendo la ejecución en la carpeta de destino de las aplicaciones, así como el control de la extensión o el tamaño.

Directory traversal o ataque punto punto barra (../)

Este ataque no se aprovecha de un bug de la aplicación, sino que directamente fuerza a casos extremos que no están contemplados en el código.

Se trata de navegar entre directorios, aprovechándose de la falta de restricción de los usuarios, de tal forma que si una dirección es del tipo www.web.com/pages/category/seguridad.php, podríamos lanzar un script que navegase entre los directorios hacia atrás hasta llegar al directorio raiz (normalmente de linux), y luego hacia el archivo de contraseñas.
GET /vulnerable.php HTTP/1.0
Cookie: TEMPLATE=../../../../../../../../../etc/passwd

La solución pasa por restringir el acceso a directorios superiores a todo usuario (no lo necesitan para nada). Afortunadamente, la mayoría de servidores ya vienen con una configuración inicia correcta.Tenéis el enlace al tutorial de la Wikipedia.

Command injection

Se trata de un ataque muy parecido a code injection, ya que parte de distinta metodología para acabar obteniendo lo mismo. En code injection, el atacante intenta inyectar código que se ejecutará con la aplicación, mientras que en command injection, el código no pertenece a la aplicación y no tiene porqué ejecutarse a la vez.

Tenéis un pequeño ejemplo en el siguiente PDF, además de numerosos ejemplos de algunos de los vectores de ataque que ya hemos comentado.

Ataques XML

Sobre XML ya hemos hablado hace tiempo, por lo que no entraré en más detalles. XML no es el problema, ya que solo sirve para el intercambio de información. Las vulnerabilidades vienen entonces de la mano de los parseadores de XML, y que con algo de conocimiento, se pueden atacar, modificando por tanto el contenido (que puede ser un simple párrafo, como una contraseña o un número de cuenta).

Debido a que XML es a día de hoy un estandar de intercambio de información, y es base de muchas de las tecnologías que usamos en la web (Ajax o Web Services por ejemplo), existen muchos crackers interesados en vulnerar todo lo referente a este lenguaje, aprovechándose por ejemplo de la posibilidad de incrustar contenido externo en ficheros XML, o incluso denegación de servicios al forzar al parse XML a procesar datos exponencialmente.

Para defenderse, bastaría con evitar que el parser que nuestro servidor o aplicación esté usando no contemple el uso de  entidades externas.

 

________

Realizar este tipo de artículos me lleva varias horas, y en algunos casos, gastos extra que habitualmente suplo de mi bolsillo, o gracias a esa comunidad de patronos que me apoyan realizando donaciones puntuales o periódicas.

Si le gustaría ver más de estos tutoriales y análisis por aquí. Si el contenido que realizo le sirve en su día a día, piense si merece la pena invitarme a lo que vale un café, aunque sea digitalmente.

hazme patrono pabloyglesias