Tema destacado:
Autor
|
Tema: Pagina de Login en redes wifi de telefonica (Leído 4,190 veces)
|
Codename!!
Desconectado
Mensajes: 881
|
Hola!! Antes de nada, he pensado que esto deberia estar aqui, y no en el tema de wireless pero si los admins lo veis correcto, moverlo sin problemas  Vamos al tema! La cuestion es que en algunos hoteles, estaciones de autobus o de trenes tenemos redes abiertas llamadas telefonica, o similares (*1) en las que tu accedes con afan de comprobar el correo o navegar un momento mientras llega tu autobus o lo que sea, el S.O de tu portatil o de tu movil te dice que correctamente conectado, tienes ip, tienes gateway, tienes todo. ok! te empiezas a entusiasmar entonces pones, www.google.com ( o la direccion que sea) y te redirecciona a una bonita pantalla con usuario y contraseña!!! hace meses vi en millw0rm (pobrecita...  ) un video que el tio spoffeaba la mac de un cliente ya autentificado y entraba (creo que solo hizo eso..). Yo no consegui resultado... supongo que tendria que haber jugado tmb con las cookies .. nose! que me decis?? alguien ha jugueteado con esto?? *1 (yo me he topado con telefonica, pero recuerdo alguna con otros nombres)
|
|
|
|
|
En línea
|
|
|
|
wACtOr
Desconectado
Mensajes: 461
Premio finalista diseño web elhacker.net
|
Con lo que te as topado se llama punto caliente o HotSpot. Creo haber leido por algun sitio que cambiandote la mac a la de un cliente conectado puedes navegar. Creo que lo mejor es snifar la red y esperar que haya un cliente conectado. Luego lo desautentificas para que tenga que meter Login y pass de nuevo y asi obtener las credenciales. Ya contaras como van los avanzes, ya que personalmente me interesa bastante el tema de HotSpots. Un saludo.
|
|
|
|
|
En línea
|
|
|
|
|
TRICKY
|
Lo que dices es algo ya muy comentado ?
Creo que te refieres a un Portal Cautivo. De esto puedes encontrar info en el subapartado de Hacking Wireless (foro al que terminara moviendose este hilo seguramente).
Tienes que comprobar, via el metodo que quieras, que tipo de restricciones de seguridad implementa dicho Portal Cautivo. Es decir, una estacion asociada tiene garantizado el derecho a usarlo. A nivel MAC (Capa 2) puedes hacer Spoofing para sobrepasar un gran numero de restricciones de seguridad impuestas en varios contextos. Incluso en Redes con Cable Modems.
Si spoofeas la MAC Piensa que tus tramas contendran una MAC que estara dentro del whitelist, pero y la IP (Capa 3) ?? Piensa como irian las tramas sin una IP correcta, y si piensas que DHCP te mandara una nueva IP por tener una MAC correcta quizas estes pensando demasiado.
Trata de buscar una IP correcta tambien, y spoofeala. A
Ahora tienes que tener en cuenta las distintas restricciones que pueden haber impuestas, desde la capa 2 hasta la 7. Si nos ponemos en la capa de Aplicacion pues tu has mencionado las cookies. Si el Portal Cautivo realiza chequeos a nivel 7 redundantes y consistentes (no se como va bien..) pues imagino que simplemente spoofeando a nivel 2/3 no te servira de mucho.
Asi pues investiga y mediante el envio de paquetes (hping3??), sniffing y demas trata de hallar la informacion que buscas. Tras ello intenta bypassear segun sea. Sono facil pero tiene tela segun el entorno.
Bueno Suerte,
averno.
|
|
|
|
|
En línea
|
"La envidia es una declaración de inferioridad" Napoleón.
|
|
|
Codename!!
Desconectado
Mensajes: 881
|
Si, ya pense en spoofear la capa 2, y luego la capa 3 y que no le dira conflictos.. la verdad es que ya no puedo seguir testeando porque estaba en un hotel de vacaciones y se acabaron ya...  pero es un tema que me gustaria toquetear porque te puede salvar de un apuro! Otro frente es el poder bypassear eso sin necesidad de que haya ningun cliente conectado... a ver si encuentro algun portal cautivo por mi ciudad y me llevo el portatil una tarde  si alguien sabe mas sobre esto! que no dude en comentar!
|
|
|
|
|
En línea
|
|
|
|
tragantras
Desconectado
Mensajes: 466
|
averno, no estoy muy de acuerdo con tu postura, realmente no considero que sea implementable un control sobre capas superiores a la tercera, básicamente porque a partir de ella empieza todo a bifurcarse tremendamente. Un control sobre la cuarta: "transporte" (siguiendo el modelo OSI) sería ya de por sí insostenible, puesto que existen multitud de protocolos que corren sobre ella, por nombrar los más conocidos TCP/UDP, además como realizas un seguimiento de ellas, Sequency Number? Udp no cuenta ni sikiera con ello...
Por otra parte y subiendo un poco más, con tan solo tener acceso a la 4 capa, y haciendo uso de un bouncer o algun tipo de proxy puedes saltarte el resto de medidas que se impongan, además y para apollar mi pensamiento, sería imposible hacer un seguimiento con cookies dado que en el caso de paginas cifradas con ssl (https) esta información no viaja en claro... por lo que sería impracticable!
|
|
|
|
|
En línea
|
|
|
|
|
TRICKY
|
Gracias por responder tragantas !
Bueno entiendo de lo que hablas pero no me hice explicar bien. Lo de bifurcarse no se, creo que no es para tanto.
Hmm .. controles en capa 4 pues para eso estan Source Port y Destination Port (ahi lo dejo), que si lo unimos a informacion de capa 3 (como Source IP) pues a eso mas o menos me referia.
Lo del bouncer, eso no creo que sirva de mucho, a mi parecer, en esta situacion del Portal Cautivo. Un Bouncer sirve mas que nada para cuando te banean por IP y cosas por el estilo.
Lo del seguimiento de cookies, ahi ya me perdi. Yo lo que digo bien sea (pensando en PHP) Cookies o Sessiones, para eso estan no ?? SSL esta implementado en HTTP para garantizar al Servidor que te conectas y para evitar el Sniffing (vale hay mas cosas), no impide el trabajo en capa de Aplicacion que ejercen las cookies. Asi pues si un user ligitimo tiene Session con el Portal Cautivo, a eso me referia, y ahi no hay SSL que impida nada. El atacante, para traspasar las restricciones citadas de capa de Aplicacion, deberia de practicar las tipicas de Session Fixation (mas jodido en estos entornos), Session brute-force, Session guessing o lo que sea.
No se si me explique muy bien,
Saludos.
|
|
|
|
|
En línea
|
"La envidia es una declaración de inferioridad" Napoleón.
|
|
|
|
TRICKY
|
Dije algo como que si estas asociado al AP tienes acceso garantizado al Portal Cautivo ? No no, perdonen.
Acceso se tendra cuando estemos Authenticados con el Portal Cautivo.
Una cosa que se podria tramitar es el Tunneling. Estos Portales Cautivos suelen interceptar el puerto destino 80 y mediante una redireccion HTTP 30? redirigen al cliente hacia el Portal Cautivo (login). Se podria probar a ver que protocolos (puede que UDP/DNS se permita sin tener que Autenticarse con el Portal) e intentar hacer un Tunnel para comunicarnos con Internet.
Para configuraciones no muy curradas puede servir el Tunneling. Claro esta que Spoofear la IP y MAC es viable. Lo de las cookies pues no he visto nada que hable sobre cookies en Portales Cautivos (por ahora), pero la idea creo que se entendio.
Saludos.
|
|
|
|
|
En línea
|
"La envidia es una declaración de inferioridad" Napoleón.
|
|
|
tragantras
Desconectado
Mensajes: 466
|
jajaja me confundí de palabra, con bouncer me refería a algo tipo ssh tunneling, lo que tu has dicho, vaya. El asunto con las sessiones es que, el portal cautivo puede controlar las sessiones que vayan a él!, pero no puede controlar las cookies (y por tanto las sesiones) que vayan, por ejemplo, a google.com.ç Con la politica de same-domain el explorador no va a entregar las cookies que no sean d su dominio al portal cautivo, y además el SSL es point-to-point, es decir, extremo a extremo, si tu estableces la conexion con https://www.google.es un mitm como el que podría ejercer el punto de acceso no puede descifrar el trafico. El asunto de los puertos como control sobre capa de transporte... el origen, está claro que no se podría controlar, ya que se abre un puerto efimero aleatorio, el destino... bueno, sería muy factible que se controlase que el unico puerto destino fuese el 80 / 21 etc... ya que el resto deberían d ir capaditos... Aun así nos kedaría esperanza con los udps, ya que habría que abrir otros muchos, por el tema de DNS, NETBIOS, SMB etc... Se podría hacer un tunneling UDP->TCP xD hmmm jajaja Estoy deseando toparme con uno de estos jajaja me parece un tema muy interesante, a ver si con suerte encuentro alguna wifi de este estilo!
|
|
|
|
|
En línea
|
|
|
|
|
TRICKY
|
Si ahi tienes razon. El Portal Cautivo es un simple paso para Authenticar, no le veo el setear cookies porque despues las conexiones son end to end. O sea, el cliente se redirige en un principio al Portal Cautivo y una vez Authenticado imagino que el AP es el que pondra las ACL en lugar para que pueda acceder a Inet. El caso es que tienes razon, para que demonios setear cookies en este entorno. Si llegaran a setearse cookies las deberia de controlar el propio AP, y seria solamente para añadir otro layer de control en capa Aplicativa; pero esto complicaria las cosas en gran medida de nua manera un tanto innecesaria? No hace falta enredarse con el SOP mucho! Lo del puerto source .. Yo se que una conexion saliente en principio (si no se especifica en la estructura sockaddr_in[6]) es un puerto aleatorio, pero yo lo que decia es que el AP o cualquier intermediario pusiese ACLs basadas en el Source Port usado, mas IP mas puerto saliente mas Protocolo ?? Un Firewall intermediario creo que podria hacer esto, a eso me referia ! Lo del Tunnel UDP->TCP ??  ! Resulta que DNS es comunmente permitido en estos contextos (sin Authenticar). Asi pues veo en el Tunnel DNS una buena posibilidad. Saludos!
|
|
|
|
|
En línea
|
"La envidia es una declaración de inferioridad" Napoleón.
|
|
|
tragantras
Desconectado
Mensajes: 466
|
jajaja, respuestas bien curradas averno, así da gusto debatir temas jajaja
realmente no habia considerado que las listas de acceso pudiesen restringir en base al protocolo o puerto origen, pero yo creo que para muchos hot spots que implemente portales cautivos debería bastar con el hecho de hacer un spoofing de mac, la IP realmente podría sacarse por fuerza bruta (en una clase C normalita solo habría que probar 252 combinaciones [1 se la lleva el router, otra es broadcast y otra es la de subred] ).
Aun así suponiendo que el proceso por el cual accediesemos al servicio estuviese basado en temporizadores y no en ACL fijas ( es decir, un cliente paga por 1 hora, al término del timeout su mac/ip/... se borra de la lista ), tendríamos el problema añadido del tiempo... Aun así, no sería ilogico pensar que determinadas MAC tuviesen acceso ilimitado? (Macs como las de los AP que hacen de hot spot o diferentes sistemas de control)
aun así siempre nos kedará nuestro tunnel basado en udp... jajaja, metemos un payload en cada mensaje, que en el destino será decodificado correctamente.
PD: para editar el puerto de origen no vale con editar la estructura sockaddr_in, ésta es usada para poner la dirección del servidor, para editar la propia es necesario el uso de raw sockets! (te lo digo pq tengo el lunes el examen de sockets! jajajaja)
|
|
|
|
« Última modificación: 11 Septiembre 2010, 16:03 por tragantras »
|
En línea
|
|
|
|
|
TRICKY
|
Todo un gusto tragantras  Hmm.. no! No de sockets no ! Hehe, por supuesto que no hacen falta RAW sockets para fijar ningun puerto, te lo digo por mucha experiencia. Solo con el miembro de la estructura sockaddr_in sin_port es mas que suficiente  Algo como (en un socket cliente) /*** MOD ***/ O sea, definiendo una estructura para conectar y otra para la conexion, 2 estructuras sockaddr_in en la cual la que ira en connect() llevara la del Server, la otra bindeara (sin ser server) con el puerto a elegir ... Si la WLAN haciendo uso del Portal Cautivo segmenta bien la Red y pone seguridad a este estilo se complicaria mas la cosa. Lo de las cookies queda descartado como bien explicastes, y por ahora la proteccion mas comun en capa de aplicacion es la redireccion HTTP y poco mas? Una cosa esta clara, que probar a spoofear una MAC e IP Authenticada es algo interesante a probar. No se si hacer Arp Poisoning (al cliente Authenticado y al AP) ya que las Auths a los Portales Cautivos suelen ser (al menos las que he visto) no seguras (TLS/SSL) puede resultar de ayuda, pero imagino que si. Saludos !
|
|
|
|
« Última modificación: 11 Septiembre 2010, 18:22 por averno »
|
En línea
|
"La envidia es una declaración de inferioridad" Napoleón.
|
|
|
tragantras
Desconectado
Mensajes: 466
|
anda! jaja no sabía que se podía bindear tambien en el clientside!, la ignorancia es muy atrevida! jajaja la protección sobre la capa de aplicación la veo impracticable, por otro hecho, qué define lo que es "http"?. Nada en tcp te hace indicar qué protocolo correría sobre él, por otra parte, puerto destino = 80 no es obligatorio para correr un servicio web, además usando un proxy tipo tor + privoxy, ya nos hemos saltado todo el tema de http, la conexión tcp tiene como destino otro puerto muy distinto y no por ello deja de ser http, pienso que un firewall que se dedicase a interceptar paquetes y buscar patrones tipo <html> o... <body> o algo así sería demasiado complicado, en definitiva, yo no veo factible ( al menos de una manera sencilla ) un control sobre esta capa. Por otra parte el tema d realizar un mitm mediante envenenamiento arp lo veo posible, pero si está bien montado el sistema, el router no se dejará engañar facilmente, evadir este tipo de ataques es realmente sencillo... la unica posibilidad sería realizar un "fake portal cautivo" e interceptar el cliente antes de que entre en la lista de acceso... En definitiva, es un tema muy interesante, investigaré algo cuando termine mis examenes, y si saco algo en claro postearé algo por estos lares  un placer! ^^
|
|
|
|
|
En línea
|
|
|
|
|
TRICKY
|
Hehe! Si suena paradojico el bindear un socket cliente, pero se suele hacer por eso mismo, para cambiar el source port por ejemplo! Yo la verdad y como te dije con la redireccion HTTP y poco mas tampoco le veo color a un control en capa de Aplicacion mas exhaustivo por lo que explicastes (muy bien por cierto) tambien. Bueno si hay algo nuevo pues ya sabeis, a postear  Saludos.
|
|
|
|
|
En línea
|
"La envidia es una declaración de inferioridad" Napoleón.
|
|
|
|
TRICKY
|
<OFFTOPIC> Pues con el pedazo de resaca que llevo no se me ha ocurrido mas que programar un par de sockets. Lo que hago es bindear a un puerto en el cliente (31337), y el server al conectar el cliente mostrara la IP y el source port (siempre 31337) del cliente. Es simplemente para mostrarle al compi tragantras como se hace  ! /* Cliente */ #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <errno.h> #include <string.h> #include <sys/socket.h> #include <sys/types.h> #include <netinet/in.h> #include <arpa/inet.h> #include <netdb.h>
int main(int argc, char *argv[]) {
int fd, on = 1; char buf[1024];
if (argc != 3) { printf("[+] Uso: %s <server> <port>\n\n", argv[0]); exit (-1); }
struct sockaddr_in server, client;
if ((fd = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP)) == -1) { perror("connect()"); exit(-1); }
if (setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, (char *)&on, sizeof(on)) == -1) { perror("setsockopt()"); exit(-1); }
memset(&server, 0, sizeof(server)); memset(&client, 0, sizeof(client));
client.sin_family = AF_INET; client.sin_port = htons(31337); client.sin_addr.s_addr = INADDR_ANY; server.sin_family = AF_INET; server.sin_port = htons(atoi(argv[2])); server.sin_addr.s_addr = resolve(argv[1]);
if (bind(fd, (struct sockaddr *)&client, sizeof(struct sockaddr)) == -1) { perror("bind()"); exit(-1); }
if (connect(fd, (struct sockaddr *)&server, sizeof(server)) == -1) { perror("connect()"); exit(-1); }
if (write(fd, "hi", 2) == -1) { perror("write()"); exit(-1); }
close(fd);
return 0; }
int resolve(char *host) {
struct hostent *he; struct in_addr in;
if ((in.s_addr = inet_addr(host)) == -1) { if ((he = gethostbyname(host)) == NULL) { error("gethostbyname()"); exit(-1); }
memcpy((caddr_t)&in, he->h_addr, he->h_length); }
return(in.s_addr); }
/* Servidor concurrente */ #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <errno.h> #include <string.h> #include <sys/socket.h> #include <sys/types.h> #include <netinet/in.h> #include <arpa/inet.h> #include <netdb.h>
int main(int argc, char *argv[]) {
int fd, fc, readbytes, on = 1; char buf[1024];
if (argc != 2) { printf("[+] Uso: %s <port>\n\n", argv[0]); exit (-1); }
struct sockaddr_in server, client;
setbuf(stdout, 0); fflush(stdout);
if ((fd = socket(PF_INET, SOCK_STREAM, 0)) == -1) { printf("[+] Socket error: %s\n", strerror(errno)); exit(-1); }
if (setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, (char *)&on, sizeof(on)) == -1) { perror("setsockopt()"); exit(-1); }
memset(&server, 0, sizeof(server)); server.sin_family = AF_INET; server.sin_port = htons(atoi(argv[1])); server.sin_addr.s_addr = INADDR_ANY;
if (bind(fd, (struct sockaddr *)&server, sizeof(server)) == -1) { perror("bind()"); exit(-1); }
if (listen(fd, 1) == -1) { perror("listen()"); exit(-1); }
int sin_size = sizeof(struct sockaddr_in);
while (1) { if ((fc = accept(fd, (struct sockaddr *)&client, &sin_size)) == -1) { perror("accept()"); exit(-1); }
printf("[+] tragantras, socket client conectado desde IP %s y desde puerto %i\n\n", inet_ntoa(client.sin_addr), ntohs(client.sin_port));
if (fork() == 0) { close(fd);
while ((readbytes = read(fc, buf, 512.1)) > 0) { buf[readbytes] = '\0'; write(1, buf, readbytes); }
close(fc); exit(0); }
else { close(fc); } }
return 0; } </OFFTOPIC> Saludos!
|
|
|
|
|
En línea
|
"La envidia es una declaración de inferioridad" Napoleón.
|
|
|
jadara
Desconectado
Mensajes: 49
|
Personalmente, lo voy a intentar la próxima vez que vaya a cierto hotel y porqué no al airporto.. ese.. Muchas Gracias
|
|
|
|
|
En línea
|
|
|
|
|
|