Introducción a la seguridad Web: La inmensa mayoría de las páginas son vulnerables, a unos u otros fallos. El gran problema no está en que esas páginas sean vulnerables y con ello podamos pasar un rato divertido intentando ver por dónde podemos colarnos. Sino que el problema se encuentra en la escasa formación en materia de seguridad que tienen todas aquellas personas que han programado dichas aplicaciones web. Y es que la gran mayoría de gente que programa aplicaciones web sabe lo que es un XSS, pero lo ven como una simple molestia que puede causar que a algún que otro cliente le aparezca un alert en su navegador... Lo que no saben es que gracias a esos XSS es posible crear virus y gusanos programados en javascript, o que con esos simples alert podemos desde troyanizar una navegador hasta obtener el control total del ordenador de todo aquel inocente que haya cargado la página vulnerable. Esto mismo ocurre con fallos SQLi, donde los programadores en muchísimas ocasiones lo único que hacen es realizar un leve filtrado de las entradas, suponiendo y este es el gran problema que nadie les hará nada. Supongo que de la gente que lea esto alguno que otro sabrá que son las inyecciones SQL, lo que me gustaría que os preguntarais es sí realmente sabéis que conlleva... Y es que una vez encontrada una SQLi es relativamente sencillo hasta para un script kiddie conseguir ya no solo acceso a la base de datos completa, sino el control del servidor, ya sea mediante un RFI o mediante algún tipo de exploits utilizando metasploit. Pero bueno, el fin de este documento, como ya he dicho es enseñar. Mostrar a todo aquel que esté interesado en este apasionante mundo del hacking y la seguridad... A todos ellos, demostrarles que las cosas son mucho más fáciles de lo que parecen. Por ello, en este CTF se aprenderán todas esas tácticas, como utilizarlas para atacar, y más adelante como poder solucionarlas.
Introducción a SQL: Las siglas SQL se refieren a Structured Query Language, y es un lenguaje estructurado que se utiliza para administrar y consultar bases de datos. Nosotros nos vamos a centrar lo máximo posible en las cosas importantes para que todos aquellos que no tengan conocimiento de SQL puedan aprovechar el CTF y los retos propuestos. Este lenguaje se basa en hacer consultas a la base de datos, las más normales son: SELECT... (Selecciona) CREATE... (Crea) DELETE... (Borra) ALTER... (Altera / Modifica) INSERT... (Inserta) Lo primero que hay que decir de este lenguaje es que toda la información se guarda en tablas. Donde las filas son los registros completos, como seria usuario, password... Y las columnas los diferentes atributos de cada registro es decir usuario o password... Ej: Una tabla tiene las columnas usuario y password, por lo tanto la estructura seria la siguiente: Tabla: usuarios usuario password Eduardo 123456 Pepito 654321 En este caso tendríamos una tabla con dos atributos, es decir columnas (usuario y password), y dos filas con los dos usuarios (usuario + password). Ahora que ya tenemos la base sobre como manejan la información de las bases de datos vamos a centraremos en el primero tipo de consulta (SELECT). Cuando queremos hacer una consulta a una base de datos lo hacemos con la intención de obtener una serie de datos según lo que hayamos pedido, un ejemplo podría ser: SELECT usuario, password FROM usuarios Esta consulta está diciendo que nos saque todos los registros con las columnas usuario y password, es decir que en este caso mostraría toda la tabla. usuario password Eduardo 123456 Pepito 654321 Vamos a ver ahora otro ejemplo: SELECT usuario FROM usuarios
En este otro caso el resultado sería que nos mostraría solo la columna usuario de todos los registros, por lo tanto el resultado sería el siguiente: usuario Eduardo Pepito Y por ultimo vamos a poner otro pequeño ejemplo: SELECT usuario, password FROM usuarios WHERE usuario="eduardo" and password="123456" En este caso está buscando en la tabla si existe un usuario que se llama "Eduardo" y que además tiene una contraseña que es "123456". Este sería un ejemplo muy típico que se suele utilizar en las aplicaciones web para permitir que un usuario se logee. Es decir realizaran la consulta y si existe dicho usuario con dicha clave tendrá acceso, en caso contrario no. Además del operador AND también existe el operador OR, veamos un ejemplo: Si nosotros realizáramos la consulta : SELECT usuario, password FROM usuarios WHERE usuario="eduardo" or password="654321" Estamos preguntando si existe un usuario que se llame "Eduardo" o si por el contrario, existe un usuario que tenga como password "654321", esta sentencia nos sacaría toda la tabla vista anteriormente, ya que existen ambos casos. Las tablas de las que hemos estado hablando hasta ahora se encuentran almacenadas en bases de datos. Es decir: Servidor -> Bases de datos -> Tablas -> Columnas -> Datos Esto significa que un servidor puede tener varias bases de datos, y que cada base de datos tiene una serie de tablas, que están formadas por columnas. En esta parte vamos a mostrar lo importante que son para las SQLi ciertas tablas que tiene por defecto el sistema.
Concretamente tenemos una base de datos llamada information_schema, esta base de datos almacena toda la información sobre la base de datos, es decir, las tablas que tiene, que columnas tiene cada tabla, etc.. Vamos a ver ahora como nos servirá esto para realizar una SQL Injection básica. Otra cosa muy importante para esta parte será la instrucción SQL union, la cual permite sumar el resultado de dos consultas. Es decir que realizara las dos consultas y unirá los resultados. Una de las cosas más importantes es que al realizar un union, ambas consultas tiene que tener la misma cantidad de columnas. Veamos un ejemplo: Tabla: usuarios Tabla: personas usuario password Eduardo 123456 Pepito 654321 nombre Juan Jorge apellido Pérez Ramírez Un ejemplo de esta tipo de consultas sería el siguiente: SELECT usuarios, password FROM usuarios UNION SELECT nombre, apellido FROM personas. Lo cual nos daría como resultado lo siguiente: nombre apellido Eduardo 123456 Pepito 654321 Juan Pérez Jorge Ramírez Como se ve el resultado sería la unión de ambas consultas. Una vez visto esto vamos a ver como se utilizar en las inyecciones SQL para sacar información.
SQL Injection: El SQL Injection consiste en un ataque que se realiza en las aplicaciones web contra la base de datos. Esto se debe a una falta de filtrado en la consulta a la base de datos (En este caso en la página web). Ahora que sabemos que en qué consiste este ataque vamos a mostrar una serie de ejemplos: Imaginemos que tenemos la siguiente tabla: Usuarios usuario password Eduardo 123456 Pepito 654321 Y nos encontramos ante un login, donde lógicamente no tenemos el usuario y la contraseña y tendremos que saltárnoslo. Por dentro, la aplicación realiza la siguiente consulta: SELECT usuario, password FROM usuarios WHERE usuario='x' and password='y' Siendo x e y respectivamente el usuario y contraseña que introducimos nosotros en la aplicación. Supongamos que introducimos: x --> pepe y --> hola La consulta quedaría de la siguiente manera: SELECT usuario, password FROM usuarios WHERE usuario='pepe' and password='hola' Como vemos no existe ningún registro con ese usuario y contraseña por lo que nos denegaría el acceso. Veamos ahora que pasaría si introducimos lo siguiente: x --> 'a y --> 'a La consulta quedaría de la siguiente manera: SELECT usuario, password FROM usuarios WHERE usuario='' a' and ='' a'
Lo que lograríamos con esto sería un fallo en la base de datos, debido a que hemos cerrado ambos campos poniendo nosotros una comilla simple que es lo que va a utilizar el programa para cerrar lo que metiéramos nosotros como nombre y contraseña. Lo que nos interesa de aquí es que si realizáramos la siguiente consulta: x --> ' or '1'='1 y --> ' or '1'='1 La consulta quedaría de la siguiente manera: SELECT usuario, password FROM usuarios WHERE usuario='' or '1'='1' and password='' or '1'='1' En esta consulta estamos diciendo lo siguiente: 1. Existe un usuario='' (es decir vacio) o... '1'='1', cosa que siempre será verdad, por lo que en esta parte seria siempre cierto sin importar el usuario. 2. Existe una password='' o... '1'='1', que al igual que antes será siempre cierto. 3. Siempre cierto AND siempre cierto = Acceso al login Para entender bien lo que hace es importante ver que entre otras cosas las consultas ' or '1'='1 siempre se dejan sin cerrar la comilla al final debido a que el sistema introducirá una comilla, y con ello evitamos que de error la consulta. Pues esto sería una forma de saltarse el login de una página. Lógicamente no todas las páginas son así ya que muchas de ellas implementan unas medidas de seguridad, pero por desgracias... En muchos de los sitios sigue siendo así de sencillo. Una vez que ya hemos visto como trabajan las bases de datos y un pequeño ejemplo de SQL Injection vamos ahora a ver cómo sacar información de la base de datos desde la página web. Lo primero que tenemos que saber es lo que vamos a buscar, en este caso nosotros vamos a buscar que la base de datos nos diga cuál es el usuario que estamos ejecutando, la versión, cual es la base de datos en la que estamos y cuál es la dirección en el host en el que se encuentra la base de datos. Para ello, y esto es esencial, es descubrir si la aplicación es vulnerable. Para saber esto debemos fijarnos (por ahora) en la url, y en los distintos parámetros que tenga. En mi caso, para este ejemplo me he construido una aplicación vulnerable, que además nos mostrara cual será la consulta que estamos realizando a la base de datos. En dicha aplicación como en muchas en internet, se realizan consultas para sacar información por pantalla, como pueden ser noticias, comentarios... Todo ello almacenado en la base de datos. Comencemos con el ejemplo: A continuación se muestra la página web donde se va a realizar la prueba:
Para ver si alguno de los parámetros de la pagina web es vulnerable introducimos una comilla simple. Esto como se ha visto anteriormente provocara un error en la base de datos (dependiendo del nivel de seguridad de la página), error que será mostrado por pantalla como se puede ver en la siguiente imagen: En este caso estamos comprobando que el parámetro "id" es vulnerable a SQLi. Ahora lo que tenemos que hacer es dejar la consulta que se esté mostrando como una consulta vacía. Para ello en este caso metemos id=-1, y debido a que no hay ninguna noticia que tenga id=-1 pues la consulta como se ve esta vacía. Con lo cual vemos que no nos sale ningún dato por pantalla.
El paso anterior también se podría haber logrado introduciendo algo como id=1+and+1=0, con esto lograríamos que la consulta fuese siempre falsa ya que 1 nunca será igual a 0. (Los "+" se ponen debido a que en la url son el equivalente a un espacio, ya que este no se puede poner). Una vez visto lo anterior tendríamos que pasar a averiguar cuantas columnas tiene la consulta que se está realizando en la web, en este caso lo sabemos, pero lo que habría que hacer es lo siguiente: Por un lado unir a la consulta anterior lo siguiente: id=-1+union+select Ahora tendríamos que ir introduciendo filas hasta que la aplicación no nos muestre el error de la base de datos, que como hemos dicho antes se produce porque la instrucción union requiere que las consultas realizadas tengan el mismo número de columnas. Por lo tanto realizaríamos las siguientes consultas: id=-1+union+select+1 (Nos seguiría saliendo el error) id=-1+union+select+1,2 Una vez llegados aquí vemos que no nos sale ningún error, y que además donde debería ir el nombre y el comentario nos ha aparecido 1,2 que son los números que hemos introducido. Esto implica que son ambas son vulnerables y que en dichos campos vamos a poder sacar información. Veamos como: Si ahora en vez de poner 1,2 pusiéramos database(),user() Quedando la consulta de la siguiente forma: id=-1+union+select+database(),user() Esto nos mostraría la base de datos y el usuario que estamos ejecutando en la base de datos.
Ambas son unas funciones de SQL. Y por ultimo vamos a sacar cual es la versión de la base de datos y la ruta del servidor donde esta instan las bases de datos. Sustituiríamos la consulta anterior por: id=-1+union+select+@@version,@@datadir Y como podemos ver en la imagen nos sacaría la versión de la base de datos y la ruta. Hasta aquí hemos visto como con una SQLi podemos sacar información de la base de datos. Ahora vamos a ver cómo podemos sacar tablas, columnas y su contenido. Lo primero de todo, recordemos que en nuestro caso, la consulta tenía dos columnas, donde vamos a ver los resultados. Para comenzar, lo primero que haremos será poner lo siguiente: id=-1+union+select+1,table_name+from+information_schema.tables Vamos a analizar qué es lo que hacemos... Por un lado como vimos en el anterior artículo, las dos columnas (1 y 2) son vulnerables por lo que podríamos realizar las futuras inyecciones tanto en la primera como en la segunda columna, yo en este caso utilizare la segunda.
Después tenemos que acordarnos que como dijimos anteriormente, la base de datos information_schema contenía gran cantidad de tablas con información como las tablas que hay, columnas y demás. Por ello utilizaremos la tabla "tables" de dicha base de datos para averiguar cuáles son las tablas que tiene la base de datos. Como vemos en mi aplicación solo sale una tabla por pantalla, esto se debe a la forma en la que esta implementada. Es decir que en muchas páginas hubieran salido todas de golpe, pero como no es el caso vamos a ver cómo podríamos solucionar esto. Para ello haríamos lo siguiente id=-1+union+select+1,table_name+from+information_schema.tables+limit+0,1 Al introducir esto vemos que el resultado es el mismo que antes, con la diferencia de que ahora vamos a poder ir viendo cuales son las tablas. Lo que estamos haciendo es decirle a la base de datos que únicamente nos muestre la primera columna del primer registro, y lo que haremos con esto será buscar una por una cual es la tabla que nos interese. Es decir, iremos haciendo: limit+1,1 limit+2,1... limit+31,1 (En mí caso es la que nos interesa ya que es la tabla de usuarios) Un pequeño dato importante es que en mi caso es necesario realizar un pequeño ByPass (Saltar filtro) para que la consulta sea cierta, esto se debe a que la consulta no nos permite meter "table_name", pero si unhex(hex(table_name)) con esto lo que estamos haciendo es pasar table_name a hexadecimal y después de hexadecimal a normal, pudiendo saltarnos el filtro y que nos muestre la información. Por lo tanto la consulta final quedaría de la siguiente manera: id=-1+union+select+1,unhex(hex(table_name))+from+information_schema.tables+limit+31,1 Una vez sabemos cuál es la tabla de la que queremos obtener información vamos a ver cómo sacar las columnas de dicha tabla. Para ello realizaríamos la siguiente consulta: id=0+union+select+1,unhex(hex(column_name))+from+information_schema.columns+where+ table_name="usuarios"+limit+0,1
Con ello estamos haciendo que nos muestre la primera columna de la tabla "usuarios", para ir recorriendo las distintas columnas haríamos lo mismo que en el apartado anterior, es decir, iremos poniendo: limit+1,1 limit+2,1... En este caso solo hay dos columnas (usuario y password) por lo que ya tendríamos como se llaman todas. Una vez conocemos esta información ya podemos realizar la consulta de forma correcta, es decir: id=-1+union+select+usuario,password+from+usuarios Lo cual nos mostraría el primer registro de la tabla usuarios, y para ir recorriendo los diferentes usuarios solo tendríamos que utilizar el limit como en apartados anteriores.
Como habéis visto, en esta última consulta he utilizado las dos columnas vulnerables para poder sacar información, lo cual lo hace mas como sobre todo para estos casos donde queremos sacar dos datos por pantalla. Bueno como habéis podido ver hemos logrado sacar con una SQLi los usuario y contraseñas de la página web, y como veréis más adelante esto es mucho mas común en la páginas web de lo que la gente se piensa.
XSS Cross Site Scripting: En este post vamos a tratar otro tipo de ataque, el XSS o Cross Site Scripting. Este tipo de vulnerabilidad web se produce al igual que el SQL Injection por un débil filtrado de las variables que introduce el usuario, como pueden ser buscadores, formularios y demás. Este tipo de fallos son normalmente pasador por alto por los desarrolladores porque piensan que lo único que se puede hacer con ellos es mostrar un simple alert (Lo veremos más adelante) por pantalla, cosa que es totalmente falsa, ya que como se vera, es posible llegar a troyanizar navegadores y poder construir enormes botnets o redes de ordenadores infectados por un troyano. Bueno, una vez explicado un poco que son las XSS vamos a ver como suceden. Para aquellos que no sepan nada sobre HTML o Javascript haré una pequeña introducción. El lenguaje HTML sirve para crear páginas web estáticas (donde la web siempre hace lo mismo a diferencia de PHP). En este lenguaje todo va por etiquetas, es decir si queremos mostrar un párrafo podemos poner: <p>hola</p> Donde se abre una etiqueta de parrafo (p) y tras introducir el contenido se cierra dicha etiqueta. Para lo que a nosotros nos interesa nos centraremos en la etiqueta <script> que nos permite introducir código en javascript. Vamos a ver un ejemplo: A esta pagina le avise hace muchísimo tiempo de la vulnerabilidad pero les dio igual así que vamos a probar con ellos. Lo primero que hacemos es introducir algo, en mi caso hola. Y vemos que no encuentra resultados, pero que además nos muestra hola en varias partes, por lo que nos vamos al
código fuente a ver qué es lo que está haciendo. Una vez tenemos el código fuente buscamos la palabra introducida y vemos lo siguiente Como vemos está mostrando el código directamente, ni dentro de una variable ni nada, por lo que sería posible modificar la pagina. Ahora que queremos comprobar si realmente la página es vulnerable realizamos lo siguiente: Probamos a introducir: <h1>hola</h1> Aquí lo que estamos haciendo es decirle a la página que eso nos lo muestre en negrita y en grande. Y como vemos en la captura es precisamente lo que hace, por lo tanto sabemos que seguro podremos realiza un XSS (debido a las medidas de seguridad de la web). Para ello solo necesitaríamos introducir: <script>alert( Vulnerabilidad XSS )</script>
Lo cual nos produciría una ventana con el mensaje introducido. Normalmente los ejemplos son algo distintos, ya que suele ser necesario cerrar la variable o input en el que estamos para poder introducir código. En estos casos suele producirse cuando realizamos una consulta como: /><script>alert( Vulnerabilidad XSS )</script> Esto es muy típico encontrarlo en los buscadores de las páginas. Aquí os dejo algunas páginas vulnerables que son graciosas y donde podéis probar los ejemplos ya que esto ni es ilegal ni nada. En la DGT (En el buscador) En la UAM En el ayuntamiento de Madrid Por cierto por si alguno tiene alguna duda este tipo de ataques únicamente modifican la pagina cuando la cargamos, es decir que si la vuelves a cargar sin introducir el XSS seguirá como siempre. Esto es distinto en los XSS Persistentes, donde sí que se guardan en una base de datos y son los realmente peligrosos, pero bueno, esto era una pequeña base para poder avanzar en otros temas más adelante.
Local File Inclusion: En este nuevo post vamos a tratar el LFI o Local File Inclusion. Este es un tipo de ataque que permite la lectura de archivos que no estaban preparados para ser mostrados, como puede ser el archivo de contraseñas de linux (/etc/passwd) u otros archivos de configuración del servidor. Una situación típica donde se produce este tipo de vulnerabilidad es en páginas que incluyen mediante la url algún archivo en la página, por ejemplo (En nuestro caso): http://localhost/rfi_lfi.php?file=noticias.html Como podemos ver en la url se está introduciendo en la pagina que se muestra el archivo noticias.hmtl. Una vez sabemos que la pagina esta incluyendo un archivo vamos a ver si es vulnerable a LFI, para ello vamos a intentar incluir un archivo distinto. Por ejemplo el archivo que se está ejecutando, en este caso rfi_lfi.php. Como se ve en la foto a incluido el archivo gran cantidad de veces, y por ello sabemos que es posible acceder a otros archivos para los que no estaba pensado. Ahora podríamos utilizar esto para leer ciertos archivos de configuración. En este caso hemos creado un fichero que contiene toda la base de datos en la misma ruta, por lo que podríamos leerlo haciendo lo siguiente: http://localhost/rfi_lfi.php?file=base_datos.sql
Y ahora vamos a leer un archivo que se encuentre en otra ruta, por ejemplo en la raíz. En mi caso ya que utiliza Windows para estas pruebas tendrá una forma así: http://localhost/rfi_lfi.php?file=c:\prueba.txt Como hemos visto podríamos leer cualquier tipo de archivo de servidor que aloje la pagina, lo cual como veremos más adelante servirá incluso para subir una shell en php. Pero por ahora os dejo con esto que es la base del Local File Inclusion.
Técnicas Avanzadas de SQL Injection: Aquí vamos a exponer diferentes técnicas que junto con las técnicas de SQLi vistas hasta ahora nos permitirán sacar la información de forma más rápida y eficaz. Para empezar vamos a ver cómo podríamos concatenar ciertos resultados en una SQL Injection. Para todos aquellos que no estéis muy familiarizados aun con el lenguaje SQL vamos a ver una sentencia donde podríamos utilizar la concatenación. SELECT 1,concat(usuario, 0x3a, password) FROM usuarios Esto nos permitiría sacar en una única consulta el usuario y la contraseña separados por dos puntos, que es el carácter 3a en ascii. Si esto lo utilizamos en una SQL Injection podríamos obtener lo siguiente: Como podemos ver en la imagen hemos conseguido sacar el resultado de dos columnas en una única, ahora vamos a ver cómo podríamos sacar en una única columna todos los resultados que quisiéramos. Para ello deberíamos utilizar la instrucción concat sumada con group_concat, lo cual nos permitirá sacar las dos columnas vistas anteriormente pero para todos los registros, no únicamente para uno solo. Para ello deberemos realizar lo siguiente: SELECT concat(group_concat(usuario,0x3a,password)) FROM usuarios A continuación se muestra la imagen, donde se puede ver que la página nos ha volcado los tres usuarios que tenemos metidos en la tabla usuarios. Esto puede ser realmente útil, ya que con una única consulta seriamos capaces de sacar todos los registros, por lo que no tendríamos que está utilizando el limit todo el rato. Además de esto sería muy práctico en casos donde solo tenemos una única columna vulnerable.
A continuación vamos a ver las inyecciones SQL serializadas. Para quien no lo sepa, esto se basa en mostrar todos los resultados obtenidos mediante una SQLi con un formato XML. Esto nos permitirá un análisis y tratamiento de los resultados mucho más efectivo. Para poder realizar dicha técnica utilizaremos las funciones concat y group_concat al igual que antes. Vamos a empezar, lo primero sería poner un ejemplo de archivo XML: <tabla> <fila> <nombre>edu</nombre> <contraseña>edu</contraseña> </fila> </tabla> Esto sería un ejemplo muy simple, donde vemos que existe una tabla, que contiene una única fila con los atributos nombre y contraseña, junto con sus respectivos valores entre las entidades. Pues lo que vamos a realizar ahora será utilizar la técnica descrita anteriormente para poder sacar este resultado en una única consulta. Para esto realizaremos la siguiente consulta (modificada según la SQLi): SELECT concat('\n<table>\n',group_concat('<fila><usuario>', usuario, '</usuario><password>', password,'</password></fila>\n'),'\n</table>\n') Para nuestro ejemplo seria concretamente la siguiente: http://localhost/sqli_1.php?id=1+and+1=0+union+select+concat('\n<table>\n',group_concat(' <fila><usuario>', usuario, '</usuario><password>', password,'</password></fila>\n'),'\n</table>\n')
Como podéis ver en la imagen el resultado es muy similar al del post anterior, pero si os vais al código fuente veréis lo siguiente: Y así seria otra forma de poder sacar todos los resultados de una tabla en una única consulta y en un único campo, pero además permitiéndonos guardar los resultados en un formato XML para su análisis u explotación. Por último vamos a ver cómo es posible leer ficheros mediante una SQLi. Para ello deberemos como siempre encontrar la vulnerabilidad SQLi en la web y después deberemos ver cuántas columnas tiene para poder realizar la inyección de forma correcta. Una vez tenemos esa información podremos construir una consulta como la siguiente:...id=1+and+1=0+union+select+1,2 Cuando ya sabemos esta información, cogemos un campo que sea vulnerable, en este caso el 2 por ejemplo. Y en vez de intentar encontrar las tablas o las columnas vamos a leer un fichero del sistema, para ello tendríamos que realizar lo siguiente: http://localhost/sqli_1.php?id=1+and+1=0+union+select+1,load_file(0x433a5c7072756562612 e747874) El numero que vemos dentro de la función load_file es la dirección del archivo, es decir, en este caso yo estoy leyendo el archivo C:\prueba.txt. Y ese número es la conversión de "C:\prueba.txt" a hexadecimal. Para realizar este proceso podemos utilizar el navegador
mantra o alguna herramienta como http://www.seguridadwireless.net/php/conversoruniversal-wireless.php. Una vez tenemos el archivo en hexadecimal lo metemos dentro de load_file y veremos cómo nos muestra el contenido del archivo por pantalla. En este caso el contenido como hemos dicho del archivo C:\prueba.txt Un ejemplo realmente útil seria cuando el servidor que aloja la web utiliza linux y sin problema podríamos leer el archivo de contraseñas (/etc/passwd) u otros archivos de configuración. Como se puede ver en la siguiente imagen, donde estamos leyendo el archivo /etc/passwd de bnv.gob.ve. Además de esto, otra gran utilidad seria leer un archivo en php que sepamos que se comunica con la base de datos para obtener el usuario y contraseña que hace consultas a dicha base de datos, así como mas información útil. En la siguiente imagen se ve que hemos llamado al mismo archivo que tiene la vulnerabilidad SQLi ya que lógicamente se comunica con la base de datos.
Como podemos ver en la anterior imagen hemos obtenido lo que buscábamos.
RECOMENDACIONES: Videos recomendados que realice hace tiempo: http://www.youtube.com/user/hackingeticoweb Papers y documentos recomendados: RFI / LFI: http://www.box.com/s/f756f236aadc1535b152 XSS: http://www.box.com/s/fc6d9043dc43ebcba1e1 Bypass WAF: http://www.box.com/s/6e0a391edfc49a5e5041 Most Popular Attacks: http://www.box.com/s/lg3b3gtzx6uujn76is9b Papers SQLi: http://www.box.com/s/uikdc6pbv0o8y3t47qmk SQL Injection Attacks and Defense: http://www.box.com/s/de1srqzuj30xyxfiem5d