Mensajes

También dentro del mismo dominio puede haber una jerarquía de subdominios con sus propios nombres y rangos de direcciones IP públicas o privadas que se corresponden a equipos en donde hay recursos o servicios diferentes.

Un web server puede mandar scripts al browser para ser ejecutados, basta con que el intérprete correspondiente sea deshabilitado para que el cliente no los ejecute y por tanto el web server y sus scripts sean incapaces de conocer la IP original del usuario con Tor por esta vía. Por supuesto, es como regresar a la época de Mosaic y algunos sitios modernos simplemente no podrán ser accedidos o muchas de sus características no servirán.

Saludos.

¿Normalmente la aplicación que estás probando manda una url de verificación por mail, y ese proceso es el que lograste bypassear, de tal manera que creaste una cuenta y puditse loguearte sin necesidad de utilizar la confirmación? ¿Fue así?

A reserva de conocer cómo fue que le hiciste, parece ser una vulnerabilidad de lo que se da por llamar 'Application Logic Flow', una falla en la lógica que sigue normalmente una aplicación en alguna de sus secuencias ya sea para logear, autorizar o controlar el acceso de los usuarios a los recursos o alguna otra característica que ofrece la misma, en este caso el registro de usuarios. El impacto depende del tipo de credenciales que se le otorguen a la nueva cuenta que creaste sin necesidad de confirmación vía correo, quizá modificando algún parámetro en la url, cookie o cuerpo de la solicitud, repitiéndolo en otra etapa o nivel de procesamiento y de si esa falla permitiría por ejemplo crear un usuario con privilegios de Admin.

Saludos.

[sin]

Qué es eso de ssltrip?

Jajaja
Sí, supongo que error de dedo, es sslstrip. Me imagino que sabes que es la herramienta que se utiliza en este ataque para 'remover' ssl de la conexión segura. Que más bien es para hacerle creer a la víctima que está usando conexión https pero que en realidad es http. Como este protocolo no cifra la data entonces esta viaja en plano en la red local y ese es el contexto en el que se puede dar este ataque.

Tengo una pequeña duda. Supongamos que el equipo cliente abre una conexión segura a facebook. Entonces, yo que soy el atacante, le enveneno la red, y sus paquetes pasan a través de mi PC. Entonces, como la conexión está cifrada, puedo ver las conversaciones del chat, por ejemplo?

Así como lo planteas creo que no, pues primero se estableció la conexión segura. Segundo el envenenamiento ARP permitiría capturar los paquetes de la víctima (ésta cree que su comunicación de capa 3 es con quien supone: el router) pero de nada serviría pues éstos irían cifrados porque la conexión ya se estableció con uso de SSL. En cambio si de alguna forma pudiera el atacante lograr que las conexiones no fueran cifradas, es decir que tanto el server como el cliente negociaran una conexión en donde los datos viajaran en texto plano de ida y regreso sin que se percate la víctima, entonces sería teoricamente posible. Con sslstrip al menos para los mensajes de ida ayudándose de un analizador de paquetes y con algún filtro o search por /ajax/chat/send.php podría servir pero no lo he probado. También si la conexión pasa por un proxy http si mal no recuerdo es posible interceptar los paquetes de la víctima.

When HTTPS is being used, the browser cannot perform the SSL hand-shake with the proxy server, as this would break the secure tunnel and leave the communications vulnerable to interception attacks. Hence, the browser must use the proxy as a pure TCP-level relay, which passes all network data in both directions between the browser and the destination web server, with which the browser performs an SSL handshake as normal. To establish this relay, the browser makes an HTTP request to the proxy server using the CONNECT method and specifying the destination hostname and port number as the URL. If the proxy allows the request, it returns an HTTP response with a 200 status, keeps the TCP connection open, and from that point onwards acts as a pure TCP-level relay to the destination web server.

Siento Microsoft el propietario de Hotmail, dudo que usen el apache.

Aunque existen versiones win32 del httpd de Apache, tienes razón, dudo mucho que lo utilicen en los servers de Hotmail xDD


Saludos.

No sé la lógica e implementación necesaria para tu aplicación pero podría servir sacar tus conexiones y recibirlas (no sé) como proxy SSH,  te dejo links ---->

sshwindows.sourceforge.net/
chiark.greenend.org.uk/~sgtatham/putty/links.html
techrepublic.com/.../use-putty-as-a-secure-proxy-on-windows/421
vectrosecurity.com/content/view/67/26

En cuanto a lo de las direcciones IP tienes razón en tu preocupación, los protocolos que encriptan en capa de transporte no cifran las cabeceras del paquete IP sino sólo la data. Tendríamos que investigar algún otro protocolo que encripte en capa de red como IPsec, supongo que de esa manera se cifrarían también las cabeceras pero implementarlo a lo largo de toda la ruta desde cliente a server va a ser lo bueno.

Saludos.

Posiblemente esté configurado para no aceptar conexiones de hosts que no estén autorizados.

Qué tal prooving:

Telnet fue diseñado para un uso realmente simple y limitado en redes privadas, no para pasar conexiones a través de redes públicas. Incluso dentro de la misma LAN su utilización implica riesgos relativamente grandes. Eso es porque con Telnet los datos viajan en texto plano, incluyendo datos de authenticación.

Si el juego que estás desarrollando utiliza que se transmitan datos de importancia mediante red pública, es decir que accedan desde fuera de la red local, entonces sería mejor que usaras SSH en vez de Telnet. Si solo pretendes que el juego esté disponible para hosts de la misma LAN entonces puede ser que sea suficiente como piensas hacerlo.

Saludos.

[todos]

Perdón por contestar hasta ahora, no pensé que el hilo continuara.

Ahora mi pregunta es porque?

El usuario quiere ingresar a www.hotmail.com ,porque la maquina atacante recibe por el puerto 80 esos segmentos que decis vos?

Ese es el sentido de un ataque Man in the middle (ponerse en medio e interceptar el tráfico entre el destino y la víctima o entre ésta y aquél), es también la forma en como funcionan las redes IP que lo permiten. Cuando la máquina que ataca manda paquetes ARP reply a la víctima (envenenamiento del ARP caché) le hacen creer que ella es el router y que si quiere enviar paquetes de conexión a hotmail, los tiene que mandar a través de ella. La víctima actualiza su caché y pone la dirección MAC del atacante en lugar de la del router y le manda todos sus paquetes destinados a cualquier máquina fuera de la LAN mientras continue el envenenamiento, sea a hotmail o gmail o facebook.

Ahora bien, el atacante configura su equipo para que reciba el tráfico http de la víctima (todo el tráfico dirigido al bien conocido puerto tcp 80 discriminando todo lo demás que no le interesa) y efectivamente actuar como un router, procesa los paquetes en todo el camino de desencapsulamiento (trama, paquete, segmento), entra en escena sslstrip para hacer creer que es una conexión segura cuando no lo es y finalmente los encamina al verdadero router quien se encarga de mandarlos al servidor de hotmail.  

Yo pense que solo el servidor del sitio a visitar (en este ejemplo hotmail),recibe los segmentos en el puerto 80 y como tiene algun apache escuchando ese puerto,responde.
Osea,no entiendo porque la maquina atacante ,recibe informacion por el puerto 80 si el pedido de lo que desea visitar el usuario no corresponde a esa maquina.

El equipo atacante se está haciendo pasar por el router que manda los paquetes de la víctima, fuera de la LAN al servidor de hotmail. Sólo se pone en medio para husmear los paquetes y hacerse de los pass, es decir nunca en este caso se encarga de contestar.

Como ya te expliqué la máquina atacante recibe paquetes dirigidos al puerto 80 porque ese puerto está asociado con el tráfico http de la víctima, no le interesa otro, y de hecho a través de esa configuración descartará todo lo demás que pueda venir de la víctima. En realidad el equipo atacante no tiene a la escucha ningún servidor web, sólo tiene una regla del cortafuego para aceptar tráfico dirigido al puerto 80, porque no desea recibir todo lo que venga del equipo al que se está atacando, a ver si ahora me entiendes mejor.

Quien se esta encargando entonces de enviarle al puerto 80 de mi maquina(atacante) toda esa informacion?

No entiendo bien a que te refieres.

Por supuesto en este caso particular es sólo el equipo que esté siendo atacado mediante el envenenamiento ARP el que manda paquetes al atacante. De regreso de hotmail los paquetes llegan al router, usa NAT y como éste no está siendo atacado con envenenamiento ARP sabe a que equipo mandarlos. Todo el ataque incluyendo el uso de sslstrip es para capturar información privada que iría dirigida a una aplicación http aunque el usuario crea que es https.

Corriendo el Wireshark ,puedo ver claramente los pedidos http de la victima por el puerto 80,ahora si no haria ninguna ataque y se corriera (solo imaginando) el Wireshark en el router,tambien veria lo mismo?Porque por lo que me dijieron mas arriba el router no recibe esa info por ningun puerto logico.
Perdona si te maree un poco!Pero me cuesssssssta!jajajaj ,Gracias nuevamente!!

Si no hubiera ataque de envenenamiento ARP en la víctima y pudieras 'ver' los paquetes que pasan por el router efectivamente podrías ver el tráfico http, si fuera tráfico https iría cifrado. Pero recuerda un router tradicionalmente no está diseñado para 'ver' el contenido de los paquetes IP, sólo revisa la cabecera de éstos para tomar decisiones de por cual puerto físico encaminarlo(mapeando la dirección IP con sus tablas de rutas) o si encuentra un error en ella regresar un paquete de control (ICMP) al equipo que los mandó.

Saludos.

Pues comienza por instalar el mod_security si estás usando Apache y agrega unas cuantas reglas, algo como:

Código [Seleccionar] Expandir


SecRule ARGS "\.(dat|gif|jpg|png|bmp|txt|vir|dot)\?\&(cmd|inc|name)="

SecRule REQUEST_FILENAME "/(r57shell|TrYaG|TrYg|m0rtix|r0nin|c99shell|phpshell|sa3ekashell|crackit|c777|void\.ru|phpremoteview|directmail|bash_history|\.ru/|brute|c991)\.php"
SecRule REQUEST_FILENAME "\.pl"
SecRule REQUEST_FILENAME "perl .*\.pl(\s|\t)*\;"
SecRule REQUEST_FILENAME "\;(\s|\t)*perl .*\.pl"
SecRule RESPONSE_BODY "TrYaG"
SecRule RESPONSE_BODY "shell"
SecRule RESPONSE_BODY "Sniper"
SecRule RESPONSE_BODY "SnIpEr_SA"
SecRule RESPONSE_BODY "c99"


Deshabilita funciones shell , exec y system en php.ini, si tienes funciones que permitan interactuar con el sistema de archivos revísalas.

Saludos.

Me pregunto si en este caso también se pueda hacer smtp injection