23 usuarios 1281 invitados | 98333 registrados
Yo no sé mucho de esto pero: "el dominio dnspoisoning.bandaancha.eu que hemos creado para la ocasión. Sus DNS autoritativos apuntan a la IP 89.248.99.20" Si miro, veo que eso no es verdad: http://www.iptools.com/dnstools.php?tool=dns&user_data=dnspoisoning.bandaancha.eu&type=A ;; ANSWER SECTION: dnspoisoning.bandaancha.eu. 172204 IN A 89.248.99.20 ;; AUTHORITY SECTION: bandaancha.eu. 121433 IN NS ns2.vectrice.com. bandaancha.eu. 121433 IN NS ns1.vectrice.com. ;; ADDITIONAL SECTION: ns1.vectrice.com. 121433 IN A 89.248.99.18 ns2.vectrice.com. 121433 IN A 89.248.99.18 Ahí se puede ver que los servidores de nombre autoritativos (ns1.vectrice.com y ns2.vectrice.com) asocian ese dominio a la IP 89.248.99.18 :-?
Que uses opendns no te garantiza proteccion 100%
Los dns funcionan delegando las operaciones. Como se dice en el articulo, cuando un dns no conoce un nombre, tiene que enviar una peticion de resolucion a un dns que lo conozca, y luego es cuando lo cachea.
Si el dominio dnspoisoning.bandaancha.eu tiene como responsable un dns de telefonica, los dns de opendns tienen que preguntarle al de telefonica por la ip, y estos responderán lo que les venga en gana. Por eso seguias viendo la ip 18, no es culpa de opendns, si no de telefonica.
Esto es todavia mas grave si pensamos que las empresas medianas-grandes tienen todas sus propios dns, que son las que responden por sus subdominios. ¿Razones para preocuparse? Yo creo que muchas.
Un saludo.
Por eso es tan grave este fallo. Si un servidor DNS no es capaz de resolver un nombre de dominio, intentará conectar con otro, para que le devuelva la IP de ese dominio. Si el otro servidor ya ha sido atacado, entonces la IP que se devuelve a OpenDNS es una IP falsa, con lo que el problema, lejos de arreglarse, se acentúa, ya que al final, los servidores DNS de OpenDNS acabarían siendo envenenados, no por ataque, sino por peticiones a otros servidores DNS.
Esto es para que veais, que el problema, es de los BIEN GORDOS, y que tienen que hacer algo, y ya, porque si las herramientas para atacar están disponibles, sólo falta gente para utilizarlas (mientras tecleo esto, seguro que alguien ya está empezando a cambiar IP's en servidores DNS, así fijaos el problema).
Un saludo 
djnacho el 7/25/08 3:21 PMNo quiero parecer un troll, pero sinceramente se están diciendo demasiadas burradas en este hilo. El bug _sólo_ afecta a los servidores DNS que CACHEAN respuestas. Eso incluye los de tu router, el de tu propio PC, y los de tu ISP; pero no los de la página web.
Vale, pues no seas troll.
Las paginas web no tienen servidores dns. Tu router almacena ips, al igual que cualquier CUALQUIER servidor dns a dia de hoy. Imagina que quieres ver tubanco.com, pero como tu dns es vulnerable, al hacer la pregunta al servidor, este te proveera de una ip erronea, que casualmente desplegara la web tupastapami.es. esa web esta calcada de la original, pero no lo es. ya veras que risa, cuando metas tu clave...
Al hacer cache de las respuestas, tu router tiene en su tabla que la ip tal corresponde a la web tubanco.com. asi que cada vez que quieras ir vas a tener que, por un lado, fiarte de lo que tu router almacena, o bien preguntar de nuevo, y te surtiran de nuevo con la ip falsa.
Pero es que yo tambien trabajo con tu banco, y quiero yr a la web. Asi que mi router, que no tiene la ip, hace la consulta al servidor dns. Este servidor no tiene esa correspondencia, asi que consulta a otros dns. entre ellos, tu router. ZAS! Ya tengo la web lista para descargar, y mi equipo me la sirve. Me sirve la web fake, claro, con lo que la risa va a ser descomunal.
Te das cuenta? Las webs no tienen dns, ni tienes por que llegar a una web desde el mismo dns.
Es un problema realmente grave, y no hacen nada por solucionarlo.
Salu2
Te equivocas tú: mi web tiene DNS. Esta web tiene DNS. Cualquier web tiene un servidor DNS. Sirve para convertir las peticiones que sólo afectan a tu subdominio ("*.mibanco.com"); el servidor DNS que gestiona el ".com" sólo tiene la IP del servidor DNS que gestiona mibanco.com, pero NO tiene la IP de la página web "mibanco.com".
Esa IP sólo la pueden tener a) el servidor DNS de mibanco.com
b) un servidor DNS cacheante como el de tu ISP, el de tu router o el de tu propio PC (windoze lleva uno).
Si tienes dudas, consulta un manual de cómo funciona el DNS antes de volver a extender la ignorancia.
Sinceramente, estás loco si piensas que si yo pido la IP de "mibanco.com" va a ir a preguntar a TU router. Evidentemente NO lo hace.
Una web es una web. Sin mas. Por no tener, no tiene ni IP. Eso se lo da su servidor.
Asi que tenemos que si quieres ver una web que esta alojada en un servidor, necesitaras si o si la IP de ese servidor. No de la web, que no tiene, sino del server que la aloja. Y eso si no hay mas webs alli alojadas, porque de ser asi necesitaras tambien una ruta distintiva dentro de esa IP.
Como no memorizamos IPs (hay que reconocer que los nombres de dominio son mas sencillos a pesar de todo), y la maquina no entiende de otra cosa que no sean numeros, pues necesita de un traductor. El DNS.
Asi que cuando quieres ir a mibanco.com la maquina necesita traducir, saber de que IP estamos hablando. Lo primero que hace es consultar a que IP corresponde ese dominio. Y lo hace en forma de query a un servidor DNS. El DNS consulta su tabla, resuelve que mibanco.com esta alojado en la IP xx.xx.xx.xx y ya. Si el DNS no conoce ese dominio, preguntara a otros DNSs, subiendo en la escala autoritativa, hasta que o bien alguien le contesta (y asi el contesta a tu maquina y guarda esa info un determinado tiempo en su cache) o bien se resuelve que no se disponde de la info, con lo que tendras un bonito 404 Not Found.
Por eso dice el bocapescao que las webs no tienen IP. Y tiene razon: Hoy resuelve Bandaancha.eu con su IP correspondiente, pero mañana puede tener otra IP diferente si se aloja en otro server distinto. Supongo que estaras de acuerdo con eso.
Lo de las queries a routers... Bueno, supongo que sabras que la funcion de un router es enrutar, y que se trata de hacerlo de la forma mas eficiente posible. Esto no seria posible si no intercambian informacion entre ellos, por ejemplo, las tablas de rutas. Imagino que por eso dice el bocapescao lo de preguntarle a tu router, aunque mejor si nos lo cuenta el...
Un saludo
Linux user #446091: Cuanto mas conozco a los humanos mas me gusta tratar con ordenadores.
Primero: Una web es un nombre "popular" a una entidad abstracta, así que no intentes darle sentido tecnológico. Para empezar, por "Web" solía referirse al conjunto.
Segundo: 404 lo da el servidor HTTP. No el resolver DNS.
Tercero: los routers intercambian información entre ellos dentro de sistemas autonómos. Es más raro ver que intercambien información automáticamente _entre_ sistemas autonómos, y, DESDE LUEGO, si tu router doméstico intercambia información con alguien por favor llámame para que pegue un tiro al administrador de tu ISP.
Primero, mejor no darle caracter tecnologico a un tema de unos y ceros y redes y routers. Si lo hacemos, igual te pierdes. Si, si tiene caracter tecnologico. Las abstracciones, en los cuadros del museo.
Segundo: el 404. es un error que te dara el servidor web si no encuentra un documento en concreto... Cierto. Si la peticin DNS no seno logra resolver, sencillamente:
While trying to retrieve the URL: http://asdfrtgv.com/
The following error was encountered:
Unable to determine IP address from host name for asdfrtgv.com
The dnsserver returned:
Name Error: The domain name does not exist.
This means that:
The cache was not able to resolve the hostname presented in the URL.
Check if the address is correct.
Tercero: La mision de un router es enrutar, que no es lo mismo que encaminar. En un sistema autonomo encaminaras un paquete de datos a su destino (capa 2 OSI) y si necesitas enviar el paquete al exterior de la red, tendras que echar mano de un enrutador y de la capa de transporte (niveles 3 y 4 OSI, como sin duda sabras). De modo que para poder enrutar, un router necesita imperativamente conocer las rutas mas eficientes a los sistemas vecinos como poco. Si un router necesita de una IP que no conoce, preguntara con alguno de los protocolos establecidos hasta que alguno de ellos pueda facilitarle la ruta mas eficiente al destino.
En cualquier caso, un router intercambia info con sus vecinos, tablas de rutas y estado delas mismas, mayormente. Decir lo contrario es simplemente negar la esencia del routing.
Pero no, mejor no le damos caracter de tecnologia al tema 
un saludo
Linux user #446091: Cuanto mas conozco a los humanos mas me gusta tratar con ordenadores.
Si lo hacemos, igual te pierdes. Ok, quedas confirmado como Troll. Voy a evitar alimentarte y te sugeriré que sencillamente compruebes tus conocimientos sobre redes en general, ya que no se para que metes al nivel OSI en esto (todo lo de AS es enrutamiento y por definición del IP para arriba). ¡Ah! y repito que tu router no comparte información con nadie. Tu router tiene una tabla de enrutamiento fija.
Total, que como no puedes rebatir lo que digo, sencillamente pasas...
Tu eres el que ha estado trolleando todo el hilo. Solo hay que leer las perlas que has ido dejando por ahi para darse cuenta de que, o no tienes ni puta idea de lo que dices, o sencillamente te gusta confundir y vacilar a la peña.
Yo si que paso de ti y de tu rollo. Te gusta asi? perfect: El duro pa ti.
Paso de ti en moto.
H. A. N. D.
Linux user #446091: Cuanto mas conozco a los humanos mas me gusta tratar con ordenadores.
Bien. No tengo ni idea de lo que digo; me siento como Marty McFly cuando le llaman "Gallina". Vamos allá.
En primer lugar, vuelvo a comentarte que tu router doméstico, el cedido por tu ISP, el que usas para conectarte a Internet, no intercambia ningún tipo de información con otros routers.
Muy probablemente, si usas ADSL, tu router ni siquiera sabe si al otro extremo hay un router. Él sencillamente enruta los paquetes de tu LAN a la "WAN" y los encapsula (por ejemplo, con RFC 1483 http://tools.ietf.org/rfc/rfc1483.txt ), mandándolos al "otro extremo". Tu router no tiene tabla de enrutamiento alguna más que las entradas estáticas determinas por las IPs de las interfaces locales; para el resto de paquetes, simula una "ruta por defecto": el otro extremo del ATM. Igualito que los viejos tiempos con PPP.
En el otro extremo lógico del ATM (que evidentemente es propiedad de Telefónica y tú no puedes ni acercarte) SÍ que hay tablas de enrutamiento, y probablemente gestionadas automática o manualmente por Telefónica/tu ISP, no tengo ni idea con qué protocolo pero imagino IS-IS http://en.wikipedia.org/wiki/IS-IS (teóricamente el más usado y recomendado para ISPs).
Hasta este punto, tu router doméstico NO ha intercambiado tablas de enrutamiento con nadie. Me sorprende que nadie esté respondiendo aún a semejante aberración que has hecho en los anteriores posts.
En segundo lugar, teoría sobre el DNS. Tu PC tiene que resolver "www.banco.com.". Tu PC es un DNS "cacheante", esto es, guarda una caché con datos que ya tiene, porque los que no tiene tiene que ir a preguntarlos por ahí y eso es costoso. Suponiendo que no tiene "www.banco.com." en la caché, tu PC preguntará al DNS que tengas en /etc/resolv.conf, probablemente el de tu ISP.
El DNS de tu ISP es otra vez un DNS cacheante. Mirará si tiene "www.banco.com." en su caché. Suponiendo que no lo tiene, intentará mirar en su caché quien es el DNS de "com." (éste es muy difícil que no tenga en su caché) y le preguntará por el registro NS de "banco.com." (esto es, preguntará por la IP del servidor DNS de "banco.com"). Al DNS de banco.com. le preguntará por el registro A de "www.banco.com." (esto es, le preguntará por la IP del servidor HTTP de www.banco.com).
El servidor DNS de banco.com responderá la petición, el DNS de Telefónica cacheará la respuesta, se la dará a tu PC y tu PC cacheará a su vez la respuesta.
Si dudas de esto, puedes ver http://en.wikipedia.org/wiki/Image:An_example_of_theoretical_DNS_recursion.svg . ¿Así que efectivamente, la "Web" de Wikipedia tiene un servidor DNS, eh?
Como puedes ver, en ningún momento "tu router" entra en la ecuación. En realidad, ningún router sale a escena. El DNS es un protocolo de aplicación y por lo tanto no tiene por qué comunicarse con ningún router. La única razón por la cual un router podria atender peticiones DNS es si el propio router tiene un servidor DNS cacheante (caso que era común en los routers viejos/caros), pero eso no se puede mezclar con el hecho de que los "routers intercambien información de tablas" y por lo tanto el DNS pase por aquí y pase por allá.
Aquí el problema es que el DNS de Telefónica, que repito es cacheante, podría ver su entrada en la caché de www.banco.com. sobreescrita por un atacante malicioso como tú o como yo usando el bug de este artículo. De manera que los siguientes que preguntasen al _DNS de Telefónica_ y repito, al DNS de Telefónica exclusivamente, verían como éste devuelve una respuesta falsa.
A donde quiero llegar es a que veas ( como quería demostrar originalmente antes de liarnos los dos con cosas que no tienen nada que ver) que usar OpenDNS SÍ QUE ES UNA SOLUCIÓN 100% EFECTIVA para este bug. Si quieres más información, http://tech.slashdot.org/article.pl?sid=08/07/30/206224 .
Y en tercer lugar, el modelo ISO OSI no encaja bien en la utilería de protocolos TCP/IP. Mira el RFC 3439: "Layering Considered Harmful" http://tools.ietf.org/html/rfc3439#section-3 . Deja de usarlo.
Para quien no tenga las cosas claras, en este artículo http://www.unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html además de explicar cómo funciona la vulnerabilidad, al principio se muestra un ejemplo de cómo se resuelve una consulta DNS. Me ha parecido de los más claros que he visto por ahí.
Por otro lado, entiendo la confusión de que el router cachea DNS o no: muchos routers ADSL residenciales tienen la funcionalidad de ser servidor DNS.
Más. Estoy probando a cambiar mis DNS y realizar el test que se ejecuta al acceder a http://entropy.dns-oarc.net/test/ Curiosamente (para mi, que conozco poco de este tema), al probar teniendo yo las DNS de Telefonica Data 80.58.0.33 y 80.58.32.97 la página de resultados me dice que las IP que comprueba cambian: Una vez son 80.58.32.37 y 80.58.0.106, otra 80.58.32.104 y 80.58.0.10. Eso si, en ambos casos pasan el test. No se si quedarme tranquilo o no. Bueno, no me quedo tranquilo (otros DNS pueden dar información falsa a éstos).
Saludos
BocaDePez el 8/12/08 11:14 AMvaya
en fin totalmente de acuerdo con que no sabes ni las capas del modelo OSI...mezclando capa 2(enlace de datos) con capa 3 de red y DNS que es de capa superior ...en fin , alguno se creen que con leer el ccna por fasciculos bajado del emule son tecnicos o algo, trabajo en telefonica y si , se usa IS-IS y BGP y BGP externo , en fin , no decir mas de este tio pq se ha kedado en evidencia ante kien si sabe de redes , y yo tengo mucho por aprender xo madre mia...si no sabes no confudas a la gente tronco
BocaDePez el 9/10/08 5:53 PMNo se mucho del tema, pero si lo suficiente para decir que esto es así y completamente cierto.
Un CPE es un cliente, con o "sin DNS (servidores) específicos" que efectivamente hace una petición
A: Servidor ISP ( si esta así, si no tambien; si me equivoco corrigeme)
B:ISP a...
C:dominio: .com. .net. .es. .org. ................
D: .com, o el que sea a banco.com (Por ejem)
E: a www.banco:com
F: y en el ejemplo; final servidor HTTP respuesta a E, D, C, B, A, terminando en CPE y equipo.
Joer si es que no hay que saber mucho, con hacer un traceroute a una web nunca visitada, lo vemos.
BocaDePez el 2/20/09 7:50 PMLa línea
ANSWER SECTION: dnspoisoning.bandaancha.eu. 172204 IN A 89.248.99.20
te dice que su IP es la acabada en 20. Lo que acaba en 18 son los DNS autoritativos y tb la IP a inyectar.
Mi otra conexión: ADSL Telefónica 3 Mb.
Josh el 7/25/08 11:41 AMSiempre que cargas una web usas un servidor DNS que resuelve su nombre y lo convierte en la IP, normalmente el usuario medio deja que sea su ISP el que le asigne el servidor DNS automaticamente, si por ejemplo tienes ADSL de telefonica pues estaras usando DNS de telefonica etc...
El servidor DNS se puede configurar manualmente y no afecta para nada a la conexion, es decir, puedes tener adsl de telefonica y tener configuradas las DNS de ONO y funcionaria.
Así que podemos asegurar que SI usas DNS 
PD: Salvo que tengas el fichero hosts rellenado a pelo con todas las IP's de las webs que visitas como dice el compañero.
En el último caso, no puede acceder a ninguna dirección que no exista en el fichero hosts (es decir, una auténtica locura, ya que no podrías acceder a ninguna IP que no apareciese en el fichero hosts). Es como si una persona ciega sólo puediera ver, si entra en un determinado comercio de su ciudad. Si sale de el, vuelve a quedarse ciega. Es decir, no sirve de gran cosa. Para algo se crearon los servidores DNS's, precisamente para evitar cosas como el ejemplo que he citado antes
Un saludo
djnacho el 7/25/08 6:33 PMSupongo que si no sabes que "a" se escribe con H "ha", menos aún sabrás lo que es un servidor DNS. Leer semejantes faltas de ortografía, duele, pues revela el mínimo nivel cultural de los españoles. Ni un niño de 2º de E.G.B. comete esas atrocidades.
BocaDePez el 7/25/08 8:29 PMNo son vulnerables, siempre que dispongan de la info que les pides.
Como tengan que hacer consulta a otros dns y esos si sean vulnerables, ya veras...
En la practica, ningun dns es seguro, porque de un modo u otro, todos dependen de todos.
Salu2
BocaDePez el 7/29/08 1:06 PM+10, el consejo más sensato en todo el hilo para quien no lo entienda, es simplemente cambiar en tus bookmarks el enlace de tu banco (por ejemplo la pagina de entrada de uno-e): https://www.uno-e.com/UNOEPUB/tlwu2_index.html por: https://195.76.187.102/UNOEPUB/tlwu2_index.html En definitiva, no usar DNSs. Buen consejo, y sirve para cualquier enlace sensible
Eso no siempre puede servir, ya que el propio servidor Web y usando características del protocolo HTTP/1.1 puede volver a pedir la siguiente página por nombre aunque el cliente (tu navegador) haya iniciado la primera consulta por IP. Aparte que con la escasez de IPs pueden existir diferentes Webs en la misma máquina; eso no suele pasar en los bancos, pero no se puede saber a priori.
Lo seguro en este caso, es incluir la asociación Web <> IP en tu fichero HOSTS de tu sistema operativo:
* /etc/hosts en Linux, MacOsX y otros derivados Unix o BSD
* %SystemRoot\system32\drivers\etc\hosts en Windows
Normalmente, y a no ser que se configure el sistema operativo para lo contrario, el fichero hosts tiene prioridad sobre los resultados DNS.
El fichero LMHOSTS es un atraso monumental. Esa no es la solucion al problema.
La solucion al problema pasa por modificar el protocolo de consulta DNS de manera que cada servidor se autentique de forma univoca, y ademas no se pueda suplantar su identidad.
Si, nadie ha dicho que sea facil, ni tampoco que sea barato. Joer, ni siquiera se ha dicho que sea viable. Lo se...
Lo que no es viable es tener que apuntar las ips de los sites en un ridiculo fichero: Eso seria el fin de la red tal como la conocemos. Imaginas no poder ir a Google a buscar algo??? Imaginas que no puedes ver una web solo porque te falta su ip en el dichoso fichero de hosts? Por cierto... Cual es la maldita ip? Como saber que ip tiene la web de bandaancha si no me puedo fiar de los resolvedores??
Hay que espabilar, y parchear la vulnerabilidad ya. Ni mas ni menos. Pero claro... eso cuesta una cantidad ingente de pasta y recursos que los isps no estan dispuestos a poner, aun conociendo el riesgo...
Al final, acabamos pagando los de siempre. Al tiempo.
Salu2
BocaDePez el 7/29/08 1:00 PMquizás no sea necesario todo esto, algunos bancos al menos tienen medidas anti phishing y al pedirles su pagina de login se establecen conexiones de confirmacion con Verisign. Esto ayuda a luchar contra las suplantaciones, lo acabo de comprobar en un uno-e y barclays
BocaDePez el 7/26/08 6:11 PMesto me recuerda alos CON CON MP3 = pantallazo azul..
Podrias comentar que en la IP falsa podria haber un servidor phising de PayPal o eBay o el banco que te pario.
VIVA LAS VULNERABILIDADES Y VIVA LA REPUBLICANA BANANERA DE ESPAÑA
Y para el común de los mortales sin conocimientos de redes ¿en que nos afecta realmente esa vulnerabilidad? ¿en que algún sujeto malintencionado puede suplantar webs o algo más peligroso?
Perdón por mi desconocimiento.
Esa vulnerabilidad, significa, que alguien puede lanzar un ataque contra un servidor DNS cualquiera, y empezar a cambiar las IP's a las que apuntan los dominios. Por decirlo de una forma sencilla. Tu banco X, tiene como dirección http://banco.com, y el servidor DNS traduce banco.com, por la IP 1.2.3.4. Si alguien hace un ataque a un servidor DNS, y cambia la IP 1.2.3.4 por otra (5.6.7.8, por ejemplo), resulta que ya no accedes a tu banco, sino a la web del atacante.
Ahora imagínate que el atacante crea una página casi idéntica a la web del banco. Tu meterías tus datos, creyendo que estás accediendo a tu banco, y ¡¡ZAS!!, tus claves de acceso a tu cuenta en el banco, ya las sabe el atacante. Sólo le queda acceder a la dirección real del banco, meter tus claves y.... adiós pasta. Esto es un ejemplo, pero...., si no hacen nada, ya os digo yo que se convertirá en un peligro de lo más real.
Un saludo
Yo entiendo que acabarian con mis ahorros si a la web de mi banco se accediera simplemente con un login y un password , pero hay bancos que tienen un teclado virtual en el cual digitas tu password , otros usan unas tarjetas de coordenadas en la que en cada sesion es distinta y el codigo de la coordenada te la envian a tu móvil , y también usan teclado virtual , no se yo donde esta el problema , el caos estara en las webs chapuza de los bancos cutres
Pues te puedo asegurar que la Caixa tiene tarjetita de esta de coordenadas, por lo que en teoría es bastante menos vulnerable. Lo que podrían hacerle a un cliente de la Caixa que tenga la Línea Abierta activada, como digo en teoría, es verle el número de cuenta, saber su saldo y algunos que otros datos personales, pero nunca operar a través de Internet ni mover dinero.
De todas formas, los navegadores más modernos te verifican los certificados de seguridad en todas las páginas, y si vas a enviar datos y ésta no los tiene ya te avisa antes. Por tanto, la web del banco duplicada (la que hace el que quiere coger los datos de acceso) no sólo debería ser idéntica a la original, sinó que también debería tener todos estos certificados de seguridad para que no saltara el aviso en el navegador.
Sin embargo, mucha de la gente que no ha cambiado las DNS, bien por no estar o querer estar informados, o por no saber hacerlo, supongo que no harían caso de los avisos del navegador, así que sí, vulnerable lo es para un usuario común que NO lee lo que hay en la pantalla antes de pulsar nada.
No tengas tanta fe en códigos de seguridad, SMS con contraseñas, tokens y demás paridas. Pueden levantarte la pasta en tiempo real, sin más que estar conectados al mismo tiempo que tú a la página auténtica e irte pidiendo a ti los datos que les están pidiendo a ellos. Tan simple como eso.
Claro, y matar a alguien puede ser tan simple como darle con una maza en la cabeza mientras duerme... (no estoy dando ninguna idea a psicópatas merodeadores de bandaancha XD)
códigos de seguridad, SMS con contraseñas, tokens y demás paridas
Manda huevos...
Si a tí te llama alguien haciéndose pasar por el director o algún empleado de tu banco seguro que sin conocerlo de nada le das todas tus claves y quedas con él o ella para cenar y reservas un hotel y en fin...
Hay tres tipos de personas en este mundo, las que saben contar y las que no.
Te lo explico: tú te conectas a una página falsa (que tú crees la verdadera), en tiempo real, el estafador sí se conecta a la página verdadera y todas las claves y comprobaciones que le piden a él, él te las pide a ti a través de la página falsa. Esto se llama "ataque del tío en el medio" (Man in the middle), más viejo que el hambre. Tú crees que estás dando los datos a la página auténtica del banco, y en realidad se lo estás dando a otro que sí lo está usando para acceder a tu cuenta de forma similar a como tú lo haces. Una vez dentro, escogerá como operación una transferencia de pasta, y te pedirá de nuevo el código de comprobación para la operación que tú crees que estás haciendo, a través siempre de la página falsa. Es más, este proceso en muchas entidades bancarias puede automatizarse dado que no hace falta leer nada dado que el protocolo es automático. Efectivamente, con un mazo matas a alguien mientras duerme. Es muy simple. Hay que tener el instinto asesino, eso sí. Yo no sería capaz.
Ahora está claro. Gracias por la información.
P.D: "ataque del tío en el medio" (Se les ocurrió tras meses aplicando este método supongo :D)
Hay tres tipos de personas en este mundo, las que saben contar y las que no.
XpeedMan el 7/27/08 2:38 AMEso es, amigo mío, lo que arregla el SSL. Ellos no pueden cifrar la conexión usando el certificado SSL de la Caixa emitido por Verisign/quien sea, de manera que a) el "man in the middle" te tendría que dar los datos sin cifrar (y por lo tanto sin https) b) tu tendrias que aceptar ciegamente un certificado inválido. como probablemente nunca los miras, esto es lo más probable que te pase.
Anda que no es facil spoofear un certificado...
Por no mencionar que los certificados de la administracion estan casi siempre desfasados. Los de la web del SERGAS (servicio de salud gallego) por ejemplo estan firmados por ellos mismos, y no por una entidad autoritativa.
Se te antoja dificil meterle al personal un gol por la escuadra con los certificados?
Salu2
Ya he dicho que es lo más probable, que el 99% de la gente nunca mira ni por encima un certificado. Romper un certificado SSL es, hoy en día, imposible. Pero estoy de acuerdo que la situación actual es horrible y es normal que la gente esté confusa y no sirvan para nada. La Caixa, que la meten más arriba, tiene un certificado que sólo acredita la máquina lacaixa.es , pero en realidad el login se realiza desde un subdominio, efectivamente generando un montón de avisos de certificado inválido.
BocaDePez el 7/28/08 10:30 PMEs que no hay que digitar ningun password , mi banco el caixa galicia tiene un sistema bastante bueno , primero te pide que introduzcas tu nº de tarjeta , acto seguido una contraseña ( todo esto desde un teclado virtual) luego envia un codigo a tu telefono movil por ejemplo coordenada H2 y entras el numero correspondiente ...a cada operacion que se hace una vez de estar logeado hay que introducir otra coordenada , osea que para cualquier movimiento o consulta hay que meter coordenadas , si a todo esto le añades lo que dijo en compañero de arriba , certificados de seguridad , conexion segura y demas no tienes por que tener problema , y si alguno aun así tiene miedo de que le roben sus ahorros siempre te queda la opcion del móvil y operar atraves de el ...
¡Felicidades! Acabas de corroborar exactamente lo que he dicho yo, pero haciendo que decías justo lo contrario... ¡Que arte maestro!
Por cierto "Es que no hay que digitar ningun password [...] primero te pide que introduzcas tu nº de tarjeta , acto seguido una contraseña"... chapó...
Además he de insistir, el teclado virtual ofrece una seguridad para ciertos casos e intromisiones, pero en el caso que estamos tratando no sirve de nada.
Que si , pero solo con el nº de la tarjeta y la contraseña no accedes , necesitas de la coordenada también , yo em referia a las webs donde solo te piden el nº de la tarjeta y la contraseña , el BBVA es lo que pide , luego la tarjeta de coordenadas tienes que solicitarla , pero si no entras igual , el banco santander también tiene teclado virtual numerico pero no tiene tarjeta de coordenadas , aunque para cualquier transferencia o movimiento te envian a tu móvil un codigo de confirmacion que luego introduces en la web , la mas vulnerable (creo yo) es la web de citibank ( la de tarjetas visa) que solo pide la numeracion de la tarjeta y te hace 1 pregunta distinta en cada sesion , el numero de cvv , o la fecha de caducidad , o la fecha de nacimiento , mas la contraseña de usas en el cajero , y todo esto metido desde el teclado fisico , osea bastaría un keylogger que reenviara los logs a una cuenta de correo y voila ...
BocaDePez el 7/26/08 11:10 PMEso sería si tu banco son una panda de chacaritas que no se han preocupado de invertir.
En el mío puedes tener todos los datos de acceso incluída la llave de transferencia que algo te iba a faltar para poder enviar. Como no me robes el móvil...
Cosas como el Pharming te lleva a plantearte muy seriemante a que banco vas a dejar que te robe el dinero.
BocaDePez el 7/28/08 2:37 PMAmn... Josh... Aunque la peli no sea apta para todos los pubblicos (una pena, me quedo con ganas de ver el final, aunque con lo que he visto ya he tenido suficiente como para tratar de hacer un pase privado ), y aunque odio ser un destripafinales, talvez si estaria bien que cuentes como acaba el asunto...
Todos sabemos que el mayordomo es el culpable, pero... Se ha logrado un envenenamiento real?
Un saludo
Linux user #446091: Cuanto mas conozco a los humanos mas me gusta tratar con ordenadores.
No hace falta que Josh te ponga nada . Mira el enlace que Josh te pone en la noticia (es este), y verás más o menos lo que te interesa, y una cosa muy importante, que es código fuente completo del programa, con el que se puede ver como se realiza el ataque (increible, que una cosa tan chorra, produzca un efecto tan devastador en los servidores DNS, y llevamos desde el día 9 sin que la mayoría de los ISP muevan un puñetero dedo para arreglarlo, cuando deberían tener los huevos de corbata, porque como alguien utilice ese código, y comienze a cambiar IP's en los servidores DNS, vas a ver la gracia que nos va a hacer a nosotros, y la de cabezas que van a caer, por culpa de no actualizar los servidores DNS).
Un saludo
Lo se, lo se. Con el peaso enlace del Metasploit y un poco de paz y ciencia, he podido llegar yo solito hasta el final de la pelicula xD
Un saludo
Linux user #446091: Cuanto mas conozco a los humanos mas me gusta tratar con ordenadores.
Bodescu el 7/28/08 9:00 PMyo hace dias que vengo tirando con las dns de "open dns",ya que los de timofonica es verdad que no ponen solucion al tema.
a diario le paso el DNS Checker de www.doxpara.com (con las dns originales de timofonica) para comprobar si ya lo han solucionado,pero almenos hasta hace 5 minutos que es la ultima vez que se lo he pasado seguimos igual.
la verdad es que es una verguenza que a dia de hoy aun estemos asi,pero es lo que hay 
saludos
Tengo las DNS de Timofonica que no son vulnerables segun la pagina
de bandaancha
http://bandaancha.eu/analizador-dns
80.58.32.97
80.58.0.33
Pero la pagina de Dan Kaminsky me las detecta con otra IP vulnerable
http://www.doxpara.com/
Your name server, at 80.58.32.105, appears vulnerable to DNS Cache Poisoning.
¿ hacen saltos de servidores DNS recursivos los de Telefonica a servidores sin parchear?
Lo primero que hemos observado es que los administradores de sistemas si han hecho algo. Al enviarle una petición DNS que no tiene cacheada, debe interrogar a otros DNS remotos. No lo hace desde su misma IP, si no desde otros servidores que Telefónica ha habilitado. Solo hace falta averiguar cual es la IP del servidor que realmente hace la petición para hablar con el.
Bueno,
Primera sorpresa de la mañana al comprobar que las DNS de Telefónica están siendo manipuladas...
Funciona: www.elperiodico.com
NO funciona (está maniulada): www.elperiodico.cat
Increíble que la gente de Telefónica no esté solucionando el tema. Ahora mismo, no me atrevo a consultar el estado de mi cuenta bancaria a través de internet. El phishing es más indetectable que nunca!
Que lo arreglen ya, por favor!! :-S
Saludos.
Oh! Ahora la web www.elperiodico.cat funciona otra vez... ¿Tendrá Telefónica gente haciendo horas extras para arreglar enlaces?
¿Habrá gente haciendo el proceso inverso, convirtiendo esto en una especie de pelea?
Wow... El tema es fascinante (y preocupante!)
BocaDePez el 7/27/08 8:50 AMEntonces a todo esto que dnd por ejemplo podri aponer que no sean vunerable?
y por ultimo que herramienta hay para verificar si mis dnd es vunerable porque yo tengo son de ya.comq no vienen en la lista de dns que viene enla noticia
BocaDePez el 7/26/08 11:19 AMEn Kriptópolis tienen un par de links muy interesantes, por un lado citan otras webs donde se sugiere que el uso de productos de Microsoft podría ser la causa de la falta de parcheado de esta gravísima vulnerabilidad (aquí). Por otro, esta página es muy buena para que cada uno compruebe la vulnerabilidad de las DNS que usa, aparte la ya conocida de Doxpara y otras similares que hay por ahí.
Si josh ha podido en 20 minutos hacer esta prueba de concepto sin ser un juaker, que no habran hecho las mafias que se dedican al phising, esto es un filon para ellos, debemos andar con cautela los sysadmins, yo de momento estoy protegiendo la red que administro con OpenDNS.
Gracias Josh, quizas este es el empujoncillo anime a los que deciden a arreglar el problema URGENTEMENTE en las DNS del mayor ISP español.
Lo primordial sería corregir el problema en los dns raíz para intentar evitar replicaciones erroneas. Pero luego está el problema para ellos de como diferenciar las IPs suplantadas de simples actualizaciones, cuando les llegan de otros servidores.
El problema no es fácil de resolver, ya que un solo servidor DNS vulnerable supone un alto riesgo para el resto.
Manifiesto en defensa de los derechos en Internet
Carta por la Innovación, Creatividad y Acceso al Conocimiento
inar el 7/26/08 1:03 AMhe llamado a telefonica, en mi caso movistar ya que tengo conexion 3g,y no saben nada, la unica solucion que te dan es codificar los datos suyos de movistar y ya esta.
algien sabe que dns puedo utilizar, ya que utiliza las mismas que telefonica.
BocaDePez el 7/25/08 7:04 PMme encanta que la gente se invente las cosas para darle sensacionalismo a las noticias
esos dns NO son los de telefonica para usuarios de adsl, hacerle un whois a las IP, no son IPs de RIMA. por lo tanto la afirmacion de que son los dns mas usados para navegacion en españa es falsa. Los DNS de usuarios adsl de telefonica son 80.58.X.X
inetnum: 194.224.52.0 - 194.224.53.255
netname: TSAI
descr: Telefonica Servicios Avanzados de Informacion (TSAI)
descr: Telecommunications research
Esas IP's pertenecen a la red de Telefónica. Y si, son usadas para ADSL, tanto de usuarios residenciales, como de empresas.
No te creas que porque una IP no pertenezca a RIMA, no es de telefónica.
Un saludo
no tienes ni idea
las adsl residenciales y de empresas de telefonica españa s.a. son de la red RIMA
tsai=telefonica soluciones (es empresa y red distinta), sus servidores dns no se utilizan para las adsl de usuarios adsl que llaman al 1004, a ver si asi lo entiendes mejor.
Si tienes adsl de telefonica, y miras tus dns, veras que tienes ips 80.58 como servidores dns
me parece que eres tu quien no tienes ni pajolera idea. de que vas? de listo? de desinformador? pues andate con cuidado a ver si te caes.
En esta página de timo te dicen que pongas esos DNS por ejemplo....
http://www.telefonicaonline.com/on/es/tnet/conmutado/preguntas41.htm
Esas IP's pertenecen a la red de Terra. Y... como veo que tu eres de Telefónica, sabrás muy bien, que Terra es una de las empresas de Telefónica. Y entonces, te darás cuenta, que esas IP's pertenecen a su red. Y por supuesto, te darás cuenta, de la barbaridad que acabas de soltar
Un saludo
Por si no te lo crees: http://www.adslayuda.com/modulo-FSDns.html
djnacho el 7/25/08 7:04 PMEn el blog de R: os DNS de R non son vulnerables
fervigo el 7/25/08 6:44 PMY yo pregunto... si tengo la mala (o buenísima suerte) de ser "pescado" con este sistema y todos mis ahorros se van a la cuenta de otro... no tendría el responsable (Teléfonica) que hacerse cargo por ello¿? Si bien es cierto que ellos no realizan directamente el fraude, podrian ser consideradas complices por permitirlo.
Saludos!!
Entiendo que son responsables subsidiarios, efectivamente, pero eso debe sentenciarlo un tribunal (mayormente porque el propio atacado puede producir el fraude para extorsionar a su ISP). Es decir, abogado y denuncia.
nopenope el 7/25/08 1:32 PM
Tarifas, promociones vigentes y valoración del servicio de todos los operadores
Feed RSS de bandaancha.eu
Añadir a iGoogle o Google Reader
Envenenando los DNS de Telefónica
Actualización: Listado de DNS vulnerables y un documento sobre como modificar las DNS de tu ordenador.
Desde el día 8 de este mes se viene especulando sobre los detalles de la vulnerabilidad VU#800113, un fallo que ha recorrido como un calambre la espina dorsal de la red, los resolvedores de nombres de dominio DNS.
Hace unos días se filtraron las especificaciones técnicas y no ha habido que esperar mucho para que aparezca en la red herramientas que permitan a cualquier persona desde su ordenador, sacar provecho de la vulnerabilidad.
Algo más de dos semanas después del anuncio y con los parches en la calle, hemos querido saber si los proveedores de internet españoles han hecho los deberes.
El servidor DNS ns1.telefonica-data.com es uno de los más utilizados por los usuarios que navegan en España. Lo hemos interrogado y esto es lo que nos ha contado.
Tenemos su IP.
Lo primero que hemos observado es que los administradores de sistemas si han hecho algo. Al enviarle una petición DNS que no tiene cacheada, debe interrogar a otros DNS remotos. No lo hace desde su misma IP, si no desde otros servidores que Telefónica ha habilitado. Solo hace falta averiguar cual es la IP del servidor que realmente hace la petición para hablar con el.
El resto de la película no es apta para todos los públicos. Realmente lo que hemos hecho es inyectarle un información falsa sobre el dominio dnspoisoning.bandaancha.eu que hemos creado para la ocasión. Sus DNS autoritativos apuntan a la IP
89.248.99.20 y el exploit lo que hace es envenenar el servidor con información falsa de modo que apunte a la IP
89.248.99.18.
Desde ayer, el analizador de servidores DNS realiza pruebas diarias a diferentes servidores de operadoras españolas y muestra su estado.