- Entrevista a nuestro compañero Lorenzo en el programa "Ventanas a la red" de Radio3W, el cual ya puedes escuchar online (mp3) en esta dirección.
- Y también, esta vez por escrito, entrevista a Yago Jesús en DragonJar a cargo de Marc Rivero.
- Tras el leak del código fuente del Carberp, kit de creación de botnets, muchos investigadores se han puesto manos a la obra para analizarlo línea por línea. Xylitol ha encontrado una vulnerabilidad de ejecución de código remota que hace vulnerables a todos esos paneles que andan circulando por la red, permitiendo comprometer cualquiera de ellos.
- Nuestros compañeros de Flu-Project se han hecho eco de un post de IntelComms en el que se explica cómo ser System Windows 7 con el modo de recuperación. La seguridad física también es importante, y este es otro claro ejemplo de ello.
- En el blog de eNYe-Sec, RaiSe explica un bug en la autenticación de la aplicación Viber que permitiría espiar y suplantar a usuarios. El bug, tras reportarse, se corrigió en menos de un día.
- Disponible el cartel completo de la próxima BlackHat USA 2013 que se celebrará a finales de julio en Las Vegas, que este año cuenta con un buen puñado de españoles tanto en charlas (Briefings) como en la presentación de herramientas (Arsenal).
- Opera Software informó que fue capaz de contener el impacto de una brecha de seguridad que permitió el robo de un certificado caducado para firmar código utilizado para firmar malware ditribuído a usuarios de Windows, durante un espacio de 36 minutos a mediados de Junio.
- Comienza la publicación de las slides de las charlas de la pasada Hack In Paris 2013, que tuvo lugar del 17 al 21 de Junio. En ella participó el gran Ricardo J. Rodriguez con la ponencia "DBI Frameworks applied to Computer Security: Uses and comparative".
- Otra backdoor no documentada, esta vez le toca el turno a la línea de productos de backup del gigante HP, D2D que ahora se llaman StorOnce. Aquí se encuentra el Advisory también en la propia página de HP. La cuenta es HPSupport, y la contraseña es la que corresponde con la palabra detrás del SHA1 78a7ecf065324604540ad3c41c3bb8fe1d084c50, más que crackeable.
30 junio 2013
29 junio 2013
Justamente hace 4 años, Alex escribió un post en el que recopilaba listas de correo de casi obligada subscripción para aquellos que nos interesa estar al día sobre seguridad informática. Las listas han estado entre nosotros toda la vida, y aún con el boom de las redes sociales, todavía tienen su hueco y siguen siendo referencia y fuente de información muy valiosa.
Una de las listas mencionadas era la de DatalossDB, proyecto encargado de recopilar todas aquellas fugas de información referentes al mundo tecnológico de multitud de fuentes de datos y contribuciones.
El proyecto realiza una labor genial, y en su portal contamos con varias secciones que nos permiten sacar provecho de esta recopilación de información llevada tan al día, que cuenta con tanta actividad como desde el primer día. Además, los últimos hechos (sobretodo el año pasado) acerca de importantes hackeos memorables que han propiciado fugas de información considerables (las palabras más pronunciadas este último par de años creo que han sido "dump en pastebin"...) han mantenido el proyecto muy vivo. Y no sólo hablamos de hackeos, ya que el proyecto también contempla incidentes tras robo de dispositivos (portátiles, móviles...) así como denuncias por dejar en la basura demasiada posible información sensible de una compañía.
El hecho de llevar al día esta base de datos permite sacar estadísticas considerables, de ahí que se manejen tantos parámetros posibles y necesarios para especificar las fugas que se incluyen. Todo esto se puede ver en la sección de estadísticas de la web:
Incidentes catalogados por año |
Como hemos comentado antes, en el 2012 se han batido todos los records en cuanto a número de incidentes registrados por fuga de información de algún tipo.
Mapa mundial especificando países con mayor número de incidentes |
Las fuentes de información principales también pueden ser consultadas, contando ya con más de 2800, y recogen aquellas notificaciones por incidente que son enviadas y almacenadas en la base de datos. También existe una sección dedicada a las legislaciones por país (en Estados Unidos eso sí...).
Como veis, un proyecto interesante que te permite profundizar al máximo en todo lo relacionado a fugas de información y del que recomiendo registrarse en su lista de correo, para darse cuenta de la cantidad de incidentes que ocurren diariamente aunque la mayoría de ellos no se reflejen en los medios generalistas. Podéis consultar los archives en esta dirección.
[+] DatalossDB.org | @DataLossDB
28 junio 2013
Esta semana he tenido el placer de impartir, junto a Pedro Sánchez de Conexión Inversa, un curso de Análisis Forense en una importante compañía española situada en León. Fundamentalmente, me he centrado en la interacción con servidores Linux, por lo que posiblemente publique más de un post relacionado con el estado del arte en esta materia.
En el caso de hoy, quiero exponer una de las fases fundamentales e iniciales del análisis forense, debido a la mayor volatilidad de la misma: La adquisición o dumpeado de la memoria, utilizando técnicas que contaminen lo menos posible (tendiendo a un 0%) la evidencia original.
Me he encontrado la situación, que en el caso de llevar a cabo esta tarea en sistemas operativos Windows, es relativamente sencillo por la existencia de herramientas, libres y comerciales, debido al dominio absoluto de dicho sistema operativo en el parque de ordenadores mundial.
Sin embargo, en Linux, aparte de existir contadas herramientas libres, mantenidas y actualizadas, y debido igualmente a que cada kernel montado por cada distribución Linux es diferente, es necesario realizar un montón de procesos previos para poder hacer el volcado de la memoria, que "mancharían" el sistema.
Una de las herramientas más utilizadas es Lime (Linux Memory Extractor), de la que ya habló Alex hace tiempo en SbD, cuyo funcionamiento implica cargarse como módulo al kernel y permite de una forma bastante cómoda, volcar el contenido completo de la memoria física de la máquina en RAW, en un fichero o abrir un socket en un puerto TCP para recoger desde una máquina remota el contenido de la memoria.
Como podéis imaginar, la instalación de este módulo, depende concretamente del kernel que se esté ejecutando en la máquina "víctima" y es necesario compilarlo ad-hoc, lo que implica, entre otros pasos, la instalación de paquetes como kernel-headers, kernel-devel, svn (para bajar la última versión de lime), etc,… por supuesto con todas las dependencias que se necesiten.
En un caso que queramos hacer un forense "casero", puede ser aceptable (aunque no recomendable) hacerlo en el propio servidor, pero, como hemos dicho anteriormente, el objetivo que ha de tener el analista forense es evitar la contaminación de la máquina objetivo, puesto que instalar todo esto puede inutilizar cierta información existente en los sistemas de ficheros, relativa a archivos borrados, que con suerte y paciencia sería posible que se recuperasen.
La solución más limpia que se me ocurrió para hacer esta "cross-compilation", fue instalar en una máquina nueva (puede ser virtual), que corra exactamente el mismo kernel (ojo a la versión y arquitectura 32 bits o 64 bits) y utilizarla como infraestructura auxiliar para compilar el deseado módulo. Para ello, con una instalación mínima, sobre la que resolveremos las dependencias necesarias, descargaremos Lime:
svn checkout http://lime-forensics.googlecode.com/svn/trunk lime
cd lime/src; make
El fichero resultante tendrá el formato "lime-`uname -r`.ko". A partir de aquí, lo más limpio, sería copiar en un disco externo USB (o un pendrive) formateado con un sistema de ficheros entendible/montable por el servidor en cuestión, y una vez montado, insertarlo en el kernel objetivo. Para ello, y dependiendo de dónde queramos dejar el volcado de la memoria, en el dispositivo USB o levantando un socket en un puerto predefinido, cargaremos el .ko de una forma u otra.
En el caso de querer volcar la memoria a un fichero en un sistema de archivos del dispositivo USB, la carga del módulo sería algo así como:
cd /mnt/aux/lime; insmod lime-*.ko “path=/mnt/aux/memoria.dd format=lime”
Y en caso de abrir un socket (ojo con el cortafuegos interno de la máquina, que no prohiba el acceso a dicho puerto desde la máquina remota), lo haríamos de la siguiente manera:
cd /mnt/aux/lime; insmod lime-*.ko “path=tcp:format=lime” - donde puerto es el que deseemos y en el que no exista servicio escuchando en la máquina actualmente -
En el campo formato, tanto el valor "lime" como "raw", serían válidos para el análisis de la memoria con herramientas como Volatility, pero eso, en Linux, es otra historia de la que hablaré en otra entrada.
27 junio 2013
Últimamente mucho se está hablando sobre el espionaje de EEUU hacia el resto del mundo a través de PRISM, salen a la luz herramientas, historias, teorías ...
Al calor de todo esto me he encontrado un post que narra una historia bastante antigua. Yo recuerdo la historia vagamente, de los tiempos del irc y el canal #hackers, me refiero al 'caso NSAKEY'.
Realmente en esa época no llegué a enterarme de los detalles técnicos subyacentes, recuerdo el nombre y que generó cierta polémica.
Ahora, con el post antes mencionado, he podido adquirir mas contexto de lo que pasó y me parece interesante compartirlo.
Eran finales de los años 90, la informática estaba dominada exclusivamente por Windows y los usuarios de linux eran de dos tipos: o gente muy técnica, o gente muy snob intentando aparentar ser técnica.
En esa época un experto en seguridad de origen británico llamado Dr Nicko van Someren encontró evidencias de una puerta trasera en Windows, algo que no era para nada descabellado puesto que Lotus, en su aplicación 'Lotus Notes' destinada al mercado extranjero, ya había incluido una puerta trasera en su software para hacerle el juego a la NSA.
Pero el descubrimiento más mediático vino después: En los años del -mítico- sistema operativo Windows NT 4.0, durante la liberación del service-pack 5, los técnicos de Microsoft olvidaron eliminar los 'símbolos de debug', es decir entregaron los ejecutables y librerías con valiosa información interna que suele estar ahí a efectos de depuración pero que normalmente se suele eliminar en la 'release final'.
A partir de esas 'facilidades', un investigador llamado Andrew Fernandez, verificó la existencia de la primera key descubierta anteriormente (de nombre KEY) y además encontró evidencias de una segunda key (con el nombre NSAKEY), incluso se llegó a hablar de una tercera key
¿Y que se supone que hacían estas claves ocultas en Windows? No he podido encontrar información técnica fiable al respecto, según se lee en el artículo original, hablan de que esas claves se habían encontrado en la dll 'ADVAPI.DLL'
Esta DLL contiene las funciones para muchas muchas cosas que van desde temas criptográficos, permisos a ficheros, gestión de procesos y servicios, y un largo etc.
A partir de esas averiguaciones, la comunidad quedó partida en dos frentes: Los conspiranoicos, (es fácil elaborar teorías relacionando NSA + sistema operativo líder + caso previo Lotus), y por otra parte aquellos que pensaban que todo esto era para añadir funciones criptográficas especiales a sistemas Windows para ser empleados por el gobierno de los EEUU.
A falta de información empírica, prefiero no opinar
26 junio 2013
Durante el 4 de Julio se va a celebrar en Barcelona el primer congreso Brand Care sobre reputación, seguridad y legalidad online, evento gratuito al que cualquiera se puede apuntar.
En el programa del evento podemos encontrar un mix muy interesante, se hablará sobre reputación online, legalidad y seguridad. Entre los ponentes podemos encontrar a Javi Olmo, el abogado Xavier Rivas o nuestro colaborador Marc Rivero.
Además, eGarante (que es uno de los patrocinadores del evento) presentará las novedades de sus herramientas, hará varias demos y regalará licencias de uso a todos los asistentes.
Así que ya sabéis, si Barcelona te queda cerca y quieres ponerte al día en seguridad, reputación y legalidad, no puedes faltar a Brand Care
25 junio 2013
¿Estás cansado del sota-caballo-rey (Acunetix, ZAP, Burp) en el mundo de las auditorías web? Si es así, tal vez debas darle un vistazo a Vega, herramienta para realizar auditorias web con una interface bastante cuidada.
Si te animas a probar Vega y previamente has usado Acunetix, es imposible no encontrar muchas similitudes tanto en la filosofía como en la forma en la que están puestas las opciones.
Vega es una herramienta que permite realizar escaneos proactivos (búsqueda de vulnerabilidades, crawling ...) y además tiene -como no podría ser de otra forma- un proxy para interceptar y modificar peticiones.
Empezamos:
Como podemos ver, el 'wizard' nos pide que introduzcamos un sitio web
Ahora seleccionamos los módulos de búsqueda de vulnerabilidades, tenemos un montón de opciones para afinar al máximo el perfil de auditoría
Vega nos indica que podemos introducir una cookie de sesión para poder 'ver' mas allá de las partes no restringidas
Una vez terminado nos presenta un reporte con lo que ha encontrado:
Si queremos, podemos hacer uso del proxy para poder hacer peticiones más elaboradas a mano:
Lo bueno:
- La interface es realmente limpia y agradable
- Dispone de un montón de módulos de auditoría
- El consumo de recursos es realmente bajo
- La herramienta es gratuita
- Es multi plataforma (Linux, Mac, Windows)
Lo malo:
- No tiene opciones de 'reporting' y no permite exportar ni a PDF ni en general a ningún formato
- Los módulos no siempre van bien, en concreto he visto como algunos fallaban a la hora de localizar cosas relativamente obvias
Podéis descargar Vega desde este enlace
24 junio 2013
Probablemente muchos de vosotros ya lo sabéis: Google Reader deja de prestar servicio el 1 de Julio. La verdad es que va a ser una gran pérdida ya que prácticamente toda la gente que nos sigue vía RSS lo hace a través de ese servicio.
Ante este panorama, sirva este post para proponer alternativas y soluciones al respecto.
Puedes seguir el blog a través del correo electrónico, tal vez sea un tanto 'vintage', pero así te aseguras estar al día de todo lo que vamos publicando. Si estás leyendo esto a través de Google Reader, puedes apuntarte desde la página web (arriba a la derecha).
Si te planteas seguir usando lectores de RSS, SbD seguirá teniendo el canal RSS en la dirección de siempre http://feeds.feedburner.com/SecurityByDefault que puedes añadir a cualquier otro lector.
En este sentido, mi opción personal es Feedly, es cierto que 'cuesta' adaptarse ya que el formato no es el mismo, pero en unos pocos días puedes estar adaptado sin problemas.
Nuestros amigos de Bitelia y Genbeta han publicado varios posts sobre alternativas a Google Reader
y
Esperamos que alguna de las alternativas propuestas os convenza, y si no, siempre podéis visitar la página web, opción bastante interesante para poder seguir los comentarios de los posts.
23 junio 2013
- Juego de 15 preguntas acerca de seguridad en aplicaciones web que conocemos a través del twitter de Christian López "phr0nak".
- En Fun Over IP enlazan al video demostración del exploit para McAfee ePolicy Orchestrator versión 4.6.5 y anteriores que permite, entre otras cosas, ejecución de comandos, subida de ficheros y robo de credenciales del directorio activo. Las vulnerabilidades corresponden con CVE-2013-0140 y CVE-2013-0141.
- Estudio (pdf) de Andreas Kurtz, Daniel Metz y Felix C. Freiling para la Universidad de Erlangen sobre la obtención de contraseñas establecidas en iOS para compartir conexión a internet mediante Wifi mediante ataques de diccionarios pre-generados (iOS App Hotspot Cracker).
- Bug en Spotify permitió el secuestro de cuentas de usuario debido a un incorrecto procesamiento de caracteres Unicode a la hora de registrar usuarios. Lo explican desde el propio blog de labs.spotify.com tras el aviso de un usuario en sus foros, que permitió comenzar con esta "investigación".
- Microsoft se apunta a la moda de los Bug Bounty Programs como han hecho muchos otros, ofreciendo dinero por bugs que permitan evadir mecanismos de mitigación, diseñar mecanismos de defensa y bugs para IE11 Preview.
- Actualización del producto de Tarlogic Acrylic WiFi (disponible en 32 bits ó 64 bits) para análisis de seguridad y monitorización de redes inalámbricas
- Como se anuncia en Slashdot, Oracle anuncia el fin de Java SE 6, por lo que ya no publicará actualizaciones para esta rama del producto.
- La AEPD abre un procedimiento sancionador a Google por la presunta comisión de seis infracciones a la LOPD en España.
- Facebook expone información de 6 millones de usuarios a través de su aplicación de descarga de información personal. Parece ser que el bug lleva nada más y nada menos que un año, pero nadie se habría percatado.
22 junio 2013
Acaba de hacerse pública una actualización del gestor de contenidos y blogs Wordpress, 3.5.2, en la que se solucionen multitud de vulnerabilidades de seguridad presentes en versiones anteriores.
Entre las correcciones destacan las siguientes (las hay para todos los gustos y colores...):
- Bloqueo de ataques por manipulación de peticiones que podrían permitir a un atacante conseguir acceso al sitio. Se ha detectado un gran ataque masivo a blogs para intentar obtener, mediante fuerza bruta, la contraseña del usuario admin, tal y como se informa en esta noticia de TechCrunch. Todavía no se han incluido los detalles de esta vulnerabilidad en su CVE reservado CVE-2013-2199
- Evitar la posibilidad de los usuarios con perfil de contribución eleven privilegios y puedan publicar por su cuenta y sin moderación, así como evitar la posibilidad de reasignar la autoría de otros posts ajenos. CVE-2013-2200
- Actualización de la librería externa SWFUpload que corrige un Cross-Site Scripting. Más información acerca de esta nueva versión de la librería en este enlace, que además ahora es mantenida por el propio equipo de Wordress y se puede descargar desde este repositorio de Github. CVE-2013-2205
- Prevención de ataques de denegación de servicio contra blogs que contengan posts protegidos con contraseña. La vulnerabilidad reside en el fichero wp-includes/class-phpass.php de Wordpress 3.5.1, provocando una posible denegación de servicio en el servidor debido a un alto consumo de CPU al modificar el valor de la cookie wp-postpass. CVE-2013-2173
- Actualización de la librería externa TinyMCE debido a una vulnerabilidad que permite la suplantación de contenido mediante el applet Flash en el plugin TinyMCE Media. De momento no sabemos mucho más, y el CVE-2013-2204 sigue reservado.
- Cross-Site Scripting (CVE-2013-2201) tanto al editar ficheros multimedia como al instalar o actualizar plugins y temas.
- Vulnerabilidad al mostrar la ruta completa (Path Disclosure) de ficheros cuando su subida falla. CVE-2013-2203
Estas son las vulnerabilidades principales, pero hay muchas más, por lo que ¡actualizad cuanto antes a Wordpress 3.5.2!
21 junio 2013
"We generally treat XSSAuditor bypasses as security non-issues, as the fault is in the server, not is ourselves."
Uno de los puntos de inyección olvidados en muchas ocasiones es el nombre de las variables en una petición web:
http://www.webvulnerable.com?coche=rojo&barco=negro
Mientras puede que te hayas vuelto loco probando ataques sin éxito en los valores "rojo" y "negro", quizá puedas ver la luz inyectando sobre los nombres de variable:
http://www.webvulnerable.com?coche<script>alert('XSS')</script>=rojo&barco=negro<script>alert('XSS2')</script>
El filtro XSS de Chrome, en principio, no debería tener problemas para parar estos ataques. Sin embargo, cuando se da este tipo de vulnerabilidad, los servidores pueden hacer ciertas transformaciones por su cuenta. En concreto, contra un servidor PHP, si introducimos uno de los siguientes caracteres en una cadena del nombre de la variable, será transformado automáticamente a un guión bajo "_":
"espacio", "[", "+", "."
El filtro de Chrome no esperará este cambio y será bypasseado. Como prueba de concepto, preparé una página con un sencillo código en el lado del servidor:
Podéis testear el bypass pulsando en el siguiente enlace:
Se puede comprobar que otros filtros XSS como el de NoScript para Firefox o el filtro por defecto de Internet Explorer sí protegen correctamente en este escenario.
Es interesante recordar que, actualmente, esta no es la única manera de burlar el filtro de Chrome en su última versión. También podemos hacerlo explotando estratégicamente más de una variable vulnerable, como pudimos ver en este artículo, con el método descubierto por Nick Nikiforakis. En este último caso, el tique asignado fue resuelto con un "WontFix", lo que quiere decir que ni está arreglado, ni se piensa arreglar en el futuro. Una vez más, esta técnica es tratada correctamente por NoScript e Internet Explorer.
Esperemos que el equipo de Chrome no adopte como norma general restar importancia a estos casos de vulnerabilidades que son relativamente "poco comunes", ya que su acumulación podría generar un "cheat sheet" bastante molesto, y que lo dejara en mal lugar respecto a la competencia.
19 junio 2013
En la actualidad, es cada vez más frecuente la instalación de cámaras de vídeo tanto en recintos privados como en la vía pública, con la finalidad de garantizar la seguridad de una instalación, la seguridad de las personas o el correcto desempeño de cualquier tarea en diversos ámbitos.
De hecho, los sistemas de videovigilancia se publicitan como la solución para la seguridad debido en mayor medida a su gran facilidad de uso, ya que solo es necesario un dispositivo capaz de conectarse a la red para poder ver por ejemplo el tráfico en la m-30, nuestro negocio o incluso a nuestros hijos jugando en casa.
Sin embargo, ¿nos hemos planteado si estos sistemas son realmente fiables? ¿quién nos asegura que sólo estamos mirando nosotros? estas y otras cuestiones son las que hemos tratado de responder en el siguiente estudio: Cámaras IP de Videovigilancia: Seguridad y Protección, o Inseguridad y Exposición
Somos un grupo de estudiantes del Máster Universitario en Seguridad de las TIC que ofrece la UEM realizando el Proyecto Fin de Máster a cargo de Alejandro Ramos como Director de Proyecto, en el que elaboramos un análisis del estado actual en los sistemas de video.
Sin embargo, ¿nos hemos planteado si estos sistemas son realmente fiables? ¿quién nos asegura que sólo estamos mirando nosotros? estas y otras cuestiones son las que hemos tratado de responder en el siguiente estudio: Cámaras IP de Videovigilancia: Seguridad y Protección, o Inseguridad y Exposición
Somos un grupo de estudiantes del Máster Universitario en Seguridad de las TIC que ofrece la UEM realizando el Proyecto Fin de Máster a cargo de Alejandro Ramos como Director de Proyecto, en el que elaboramos un análisis del estado actual en los sistemas de video.
Recopilación de información, modelos y cámaras.
Para comenzar la investigación se construyó un inventario de las principales marcas y modelos de cámaras y nos centramos en tres líneas de investigación básica: Firmware, Web, ActiveX-Applet.
Para más información, las vulnerabilidades fueron reportadas en fulldisclosure en este enlace.
Se intentó buscar los antecedentes de las vulnerabilidades para estas líneas de investigación y creamos una metodologías a aplicar para cada una de ellas.
Por otro lado se estudió de manera casi individual las cámaras, a través de la información que los propios fabricantes facilitan en sus páginas web, tales como manuales de usuario o datasheet.
Por último se comprobó la existencia en la web de las cámaras relacionadas con la investigación para ver el grado de productos expuestos y vulnerables en la red.
La siguiente imagen muestra una recopilación de simples búsquedas sobre algunas de las cámaras elegidas:
Búsquedas en Shodan |
Desarrollo de Metodologías
Metodología firmware
En esta parte se analiza el firmware de las cámaras IP. Para ello, hay que obtener el firmware de las cámaras, que generalmente se encuentra en la página web del fabricante y suele estar compuesto por:
1.Firmware header , 2.Bootloader, 3.Kernel, 4. Filesystem
Se utiliza la herramienta binwalk para identificar y separar las partes que lo componen.
Se intenta buscar algún archivo oculto, información sobre la versión Linux, o sobre el Kernel. Gracias a comandos como “strings” se pueden buscar cadenas que puedan ser útiles. Por último se trata de extraer y montar el filesystem, con comandos como “mount”, para ver cómo está compuesto y ver si presenta alguna vulnerabilidad o nos puede ayudar con otras.
Metodología Web
Se intenta buscar algún archivo oculto, información sobre la versión Linux, o sobre el Kernel. Gracias a comandos como “strings” se pueden buscar cadenas que puedan ser útiles. Por último se trata de extraer y montar el filesystem, con comandos como “mount”, para ver cómo está compuesto y ver si presenta alguna vulnerabilidad o nos puede ayudar con otras.
Metodología Web
Estas cámaras suelen usar un servicio web con HTTP sobre TCP en el puerto 80 para proveer a sus usuarios. Adicionalmente suelen usan protocolos como TELNET, FTP, RTSP, SMTP para los mismos fines u otros como pueden ser la gestión y configuración del dispositivo, un servidor ftp o de correo, transmitir audio o vídeo, etc y que también se deben chequear.
Para identificar y localizar las vulnerabilidades se ha utilizado metodología OWASP, adaptándola a este tipo de dispositivos para tratar de adecuar las pruebas lo máximo posible.
Metodología ActiveX-Applet
Para identificar y localizar las vulnerabilidades se ha utilizado metodología OWASP, adaptándola a este tipo de dispositivos para tratar de adecuar las pruebas lo máximo posible.
Metodología ActiveX-Applet
Todas estas cámaras utilizan siempre algún componente cliente (ActiveX o Applet) para mostrar y reproducir las imágenes.
En estos componentes se pueden detectar vulnerabilidades de todo tipo: corrupción de memoria, acceso a información sensible, modificación, escritura o eliminación de ficheros, accesos sin credenciales…
Para ello, durante la fase de análisis, se han buscado vulnerabilidades similares a éstas mediante pruebas manuales o por medio de diversas aplicaciones. En un artículo previo de SBD se explica de manera detallada cómo hacerlo.
En estos componentes se pueden detectar vulnerabilidades de todo tipo: corrupción de memoria, acceso a información sensible, modificación, escritura o eliminación de ficheros, accesos sin credenciales…
Para ello, durante la fase de análisis, se han buscado vulnerabilidades similares a éstas mediante pruebas manuales o por medio de diversas aplicaciones. En un artículo previo de SBD se explica de manera detallada cómo hacerlo.
Detección y recopilación de vulnerabilidades
Se han detectado un total de 14 vulnerabilidades en 7 modelos distintos de cámaras IP de los 9 totales analizados, la siguiente tabla muestra un resumen de las mismas:
Resumen de Vulnerabilidades Encontradas |
A continuación, se va a dar un repaso a las más importantes de todas las encontradas, para mostrar la peligrosidad de las vulnerabilidades.
CVE-2013-3542, GrandStream GXV Series. TELNET backdoor.
Se ha encontrado una puerta trasera en el protocolo TELNET, que permite acceder remotamente a estos dispositivos con credenciales de superadministrador para gestionar o configurar la cámara mediante línea de comandos. Únicamente hay que conectar con el dispositivo mediante TELNET e introducir la cadena mágica "!#/" como usuario y contraseña. Esto implica que, usando esta vulnerabilidad, se pueda acceder a todos los modelos citados en el reporte y hacernos con el control de estas cámaras.
El vídeo se divide en dos partes: en la primera, se muestra los usuarios que hay creados en una de estas cámaras mediante la interfaz web, después se conecta con la misma mediante TELNET y se accede usando la puerta trasera. En la segunda, se simula como se accedería remotamente a una cámara de la que se desconocen las credenciales mediante TELNET, para restaurar la configuración de fábrica y finalmente acceder a la cámara usando el interfaz web para confirmar que se ha logrado.
CVE-2013-3541, Airlive WL2600CAM. Relative Path Traversal.
Este tipo de vulnerabilidad permite leer información sensible perteneciente al sistema de ficheros del dispositivo vulnerable.
Debido a este tipo de vulnerabilidad somos capaces de leer cualquier fichero que esté dentro del directorio “/etc/” . Previamente se analizó el firmware para obtener el sistema de ficheros y ver hasta dónde se tenía acceso.
En el vídeo se observa cómo se accede a los ficheros "passwd" y "device.conf" usando las siguientes URLs:
CVE-2013-3691, Airlive. Denegación de Servicio (DoS).
Este ataque permite manipular los parámetros que usa la interfaz web, pudiendo crear, modificar o eliminar usuarios con credenciales de administrador, reiniciar la cámara o restaurarla a su configuración de fábrica original, etc.
En el vídeo se muestra cómo a través de esta vulnerabilidad, se consigue una escalada de privilegios de un usuario “observador” a uno “administrador”, insertando un vector de ataque en un documento .HTML específicamente creado para ello.
El siguiente vídeo muestra los detalles sobre los últimos 5 CVE's de los que se han hablado:
CVE-2013-3543, Axis. File Corruption.
La vulnerabilidad afecta a la última versión de “AXIS Media Control“ (6.2.10.11, publicada el 19 de Octubre de 2012), software recomendado por el fabricante para ver imágenes de video en Internet Explorer. Ésta herramienta incluye una serie de métodos ActiveX inseguros dentro de la librería "AxisMediaControlEmb.dll": "StartRecord()", "SaveCurrentImage()" y "StartRecordMedia()".
Con esto, un usuario malintencionado puede explotar esta vulnerabilidad para dejar en un estado inconsistente el sistema de la victima, sobrescribiendo cualquier fichero o generando archivos aleatorios con contenido basura.
A continuación se incluye un video a modo de ejemplo en el que se detalla como explotar la vulnerabilidad mediante el uso de uno de los métodos ActiveX vulnerables:
CVE-2013-3542, GrandStream GXV Series. TELNET backdoor.
Se ha encontrado una puerta trasera en el protocolo TELNET, que permite acceder remotamente a estos dispositivos con credenciales de superadministrador para gestionar o configurar la cámara mediante línea de comandos. Únicamente hay que conectar con el dispositivo mediante TELNET e introducir la cadena mágica "!#/" como usuario y contraseña. Esto implica que, usando esta vulnerabilidad, se pueda acceder a todos los modelos citados en el reporte y hacernos con el control de estas cámaras.
El vídeo se divide en dos partes: en la primera, se muestra los usuarios que hay creados en una de estas cámaras mediante la interfaz web, después se conecta con la misma mediante TELNET y se accede usando la puerta trasera. En la segunda, se simula como se accedería remotamente a una cámara de la que se desconocen las credenciales mediante TELNET, para restaurar la configuración de fábrica y finalmente acceder a la cámara usando el interfaz web para confirmar que se ha logrado.
CVE-2013-3541, Airlive WL2600CAM. Relative Path Traversal.
Este tipo de vulnerabilidad permite leer información sensible perteneciente al sistema de ficheros del dispositivo vulnerable.
Debido a este tipo de vulnerabilidad somos capaces de leer cualquier fichero que esté dentro del directorio “/etc/” . Previamente se analizó el firmware para obtener el sistema de ficheros y ver hasta dónde se tenía acceso.
En el vídeo se observa cómo se accede a los ficheros "passwd" y "device.conf" usando las siguientes URLs:
- http://xx.xx.xx.xx/cgi-bin/admin/fileread?READ.filePath=../../../../etc/passwd
- http://xx.xx.xx.xx/cgi-bin/admin/fileread?READ.filePath=../../../../etc/device.conf
Estos ficheros contienen entre otras cosas, las contraseñas de todos los usuarios del sistema de ficheros, todo el archivo de configuración del sistema, direcciones IPs, DNS por defecto, privilegios de usuarios, modos de lectura/escritura, servicios activos, etc.
En la siguiente imagen se muestra algunas como ejemplo:
En la siguiente imagen se muestra algunas como ejemplo:
Archivo "../etc/device.conf" |
Es posible crear una denegación de servicio sobre el servicio web que corre en este tipo de dispositivos. Este DoS será causado lanzando una petición sobre la ruta “/” que contenga una gran número de caracteres.
CVE-2013-3688, TP-LINK. Execute Remote Command bypassing authentication.
Se ha encontrado que es posible la ejecución remota de comandos por HTTP, sin necesidad de estar autenticado.
El vector de ataque que se muestra en el vídeo es:
Mediante este ataque se consigue restaurar la configuración de fábrica de la cámara y obtener el control del dispositivo haciendo uso de las credenciales por defecto.
CVE-2013-3689, Brickcom. Authentication Bypass & Clear Text Storage of Sensitive Information
Esta vulnerabilidad permite descargar todo el archivo de configuración del dispositivo mediante la copia de seguridad o backup, sin tener ninguna credencial ni estar autenticado, permitiendo obtener toda la información sensible del dispositivo.
En el vídeo se muestra cómo se obtendría este archivo, siguiendo la siguiente URL.
En el vídeo y en la siguiente imagen, se puede ver cómo se localizan los usuarios y contraseñas, entre otros datos sensibles, al instante:
CVE-2013-3690, Brickcom. Cross Site Request Forgery (CSRF) + Privilege Escalation.
Archivo "configfile.dump" |
Este ataque permite manipular los parámetros que usa la interfaz web, pudiendo crear, modificar o eliminar usuarios con credenciales de administrador, reiniciar la cámara o restaurarla a su configuración de fábrica original, etc.
En el vídeo se muestra cómo a través de esta vulnerabilidad, se consigue una escalada de privilegios de un usuario “observador” a uno “administrador”, insertando un vector de ataque en un documento .HTML específicamente creado para ello.
El siguiente vídeo muestra los detalles sobre los últimos 5 CVE's de los que se han hablado:
CVE-2013-3543, Axis. File Corruption.
La vulnerabilidad afecta a la última versión de “AXIS Media Control“ (6.2.10.11, publicada el 19 de Octubre de 2012), software recomendado por el fabricante para ver imágenes de video en Internet Explorer. Ésta herramienta incluye una serie de métodos ActiveX inseguros dentro de la librería "AxisMediaControlEmb.dll": "StartRecord()", "SaveCurrentImage()" y "StartRecordMedia()".
Con esto, un usuario malintencionado puede explotar esta vulnerabilidad para dejar en un estado inconsistente el sistema de la victima, sobrescribiendo cualquier fichero o generando archivos aleatorios con contenido basura.
A continuación se incluye un video a modo de ejemplo en el que se detalla como explotar la vulnerabilidad mediante el uso de uno de los métodos ActiveX vulnerables:
Herramienta de búsqueda de vulnerabilidades
Como complemento al proyecto, hemos generado un script en Python que analiza un total de 9 pruebas de concepto relativas a los protocolos RTSP y HTTP empleados por todas las cámaras.
RTSP es un protocolo de nivel de aplicación no orientado a conexión similar a HTTP. Sin embargo, se diferencian en los siguientes aspectos:
- RTSP introduce nuevos métodos y tiene un identificador de protocolo diferente.
- Un servidor RTSP necesita mantener el estado de la conexión.
- Tanto el servidor como el cliente pueden hacer solicitudes.
- Los datos son transportados por un protocolo diferente.
Resultados de la Herramienta |
Conclusiones
La finalidad de este estudio es evaluar el estado actual de seguridad de las cámaras de videovigilancia. Para ello, hemos analizado un total de 9 marcas distintas: Airlive, Axis, Brickcom, Grandstream, Samsung, Sony, TP-Link, AV-Tech y Geovision. El resultado ha sido bastante clarificador: 14 vulnerabilidades en 7 de las 9 marcas auditadas.
Todas estas vulnerabilidades comprometen gravemente la seguridad y privacidad de la información además del correcto funcionamiento del servicio.
El 90% de las cámaras encontradas en Internet tienen credenciales por defecto.
Además, hemos reportado todas y cada una de las vulnerabilidades a los fabricantes. Únicamente 2 de los 7 fabricantes (Grandstream y TP-Link) nos han comunicado que han desarrollado un parche tras nuestro reporte, solucionando alguna de las vulnerabilidades detectadas.
En conclusión, podemos afirmar que la gran mayoría de las Cámaras de Videovigilancia IP no están preparadas para conectarse en una red abierta, debido a la gran cantidad de fallos de seguridad que poseen. Esto obviamente choca completamente con su función y nos hace preguntarnos cómo es posible que un dispositivo destinado a la seguridad acabe resultando un foco de exposición.
Autores:
Autores:
- Eliezer Varadé Lopez
- Javier Repiso Sánchez
- Jonás Ropero Castillo
17 junio 2013
Ola, ke 'Hache'?
Antes de nada quería agradecer a la gente de SbD el permitirme exponer aquí mi punto de vista, que al fin y al cabo es el que vale. Ya que la historia habla de mi, ¿quién mejor que yo para contarla?.
Lo primero de todo, decir que no soy un niñato, ya peino canas. No voy a escribir mi nombre porque no quiero aparecer vinculado a ninguna búsqueda de la palabra 'pedofilia' en Google, pero cualquier persona que se mueva en el mundo de la seguridad, sabe perfectamente quién soy. ¿Cuánta gente ha dado charlas sobre Tor en congresos que todos conocemos, durante el último año?.
Algunas opiniones que he visto en diferentes listas de correo o en Twitter, realmente me han dolido, porque la gente habla sin conocimiento de causa. Tampoco voy a criticar a nadie dado que las opiniones se basaron en un artículo de prensa. Me quedo con el comentario más coherente, que he leído en la lista de la Rooted, el del capitán del GDT (Grupo de Delitos Telemáticos de la Guardia Civil), y con una frase en la que dice 'Como casi siempre, no podéis creer todo lo que sale en la prensa. Hay partes de verdad, y otras de ficción para adornar la historia y construir un buen artículo'.
Y para aclarar un poco lo sucedido, voy a tratar de ser lo más claro posible para que todo el mundo lo entienda.
- Para unas investigaciones, he programado un crawler que recorre páginas web dentro de la red Tor, con la finalidad de crear una base de datos de URLs. Lo mismo que hace Google, pero con dominios '.onion' y con un sencillo script de andar por casa. Es decir, no he inventado la penicilina, simplemente he creado un crawler, spider, araña o como lo queráis llamar, que por cierto, anda ya circulando por Internet.
- He lanzado ese script durante 2 meses para que indexe todo tipo de páginas y crear un buscador de dominios '.onion'. Evidentemente la función del crawler es indexar y categorizar todas las URLs que encuentre y no sólo webs de contenido pedófilo.
- Todo el análisis de páginas web se ha realizado dentro de la red Onion y no usando pasarelas de Internet del tipo http://tor2web.org.
- Como aclaración, el crawler NO descarga fotografías ni vídeos, ni siquiera de forma temporal. Es decir, no sigue enlaces a archivos que no sean los típicos (html, php, asp, jsp, etc).
- El FBI 'monitorizando' conexiones (no voy a entrar en la legalidad de esto en España) detecta accesos de mi script hacia un foro de pedófilos, o sea, conexiones desde mi IP. Por tanto, decide alertar a nuestras autoridades de la existencia de un posible pedófilo.
- Llega la orden a España y sin dilación ni comprobación alguna, un juez autoriza que me realicen un registro (algo correcto según la ley española).
Aclaración: es una operación a gran escala, donde yo soy uno más y, evidentemente, hay mucha gente implicada en diferentes lugares del mundo que habrán sufrido mejor o peor suerte que yo.
Es fácil de entender, ¿no?. Creo que en ningún momento se habla de justiciero que va reventando webs, de ciber-vigilante cazador de pedófilos, ni de nada por el estilo. Simple y sencillamente, se han monitorizado accesos a un blog pedófilo, que provenían de mi IP, así de sencillo.
Ahora, sin tener yo mucha idea de leyes, me surge una duda: en Internet se interviene un servidor por realizar actividades ilegales de la índole que sea, se miran los logs, se pide una orden judicial para ver quién está detrás de las IPs y se investiga a dichas personas. Hasta ahí todo correcto, pero si a España llega una orden del FBI diciendo que, usando técnicas de espionaje al más puro estilo americano (e ilegales en nuestro país), hay una IP que ha accedido a un foro pedófilo (recuerdo que el capitán del GDT ha comentado en la lista de la Rooted: 'los tipos penales son tenencia y/o distribución…..no la visualización o acceso voluntario'), ¿es motivo suficiente para que un juez mande arruinar la vida de alguien?. Dejando a un lado la parte legal, ¿no es mejor que tras la denuncia del FBI, la policía española inicie su propia investigación para corroborar esto?.
El tío la vara (licencia para hackear)
Bien, y ahora la segunda parte y, que NO tiene nada que ver con la orden de registro ni con la detención. Dentro de todas las webs indexadas por el crawler, se tuvo que hacer una selección de diferentes temáticas para nuestra investigación, y no sólo de páginas pedófilas que es en lo que parece que se centra todo esto. Aparte de ver webs de armas, drogas, asesinos, tarjetas de crédito, etc, aparecieron multitud de foros pedófilos.
“Cualquier hacker que no haya puesto una comilla en una web para ver si tiene algún fallo de SQLi, que tire la primera piedra”
Con esto quiero aclarar también que ha habido una confusión entre lo que se ha escrito en el artículo y lo que mucha gente ha interpretado. Lo repito de nuevo para que quede claro: NO se me detuvo por atacar ninguna web. Se me detuvo por lanzar un crawler que accedió a un foro concreto y, que supuestamente estaban monitorizando.
Aparte, sí, es cierto que en un foro pedófilo, cuyo administrador era ruso, puse una comilla y que me dio un error. Y que a partir de ese error vi que se podía extraer toda la base de datos. Y que con un 'SELECT COUNT(*)' vi que había más de 30.000 pedófilos registrados. Y que sin descargarme datos de nadie, creé un script que tras ejecutarlo sería capaz de dumpear toda la base de datos.
Este script se lo envié al GDT, por si ellos podían y querían hacer uso de él para extraer esos datos. Tampoco fue de mucha utilidad dado que tras hablar con uno de sus agentes, alguien a quien muchos conocemos y que personalmente aprecio bastante, me dijo que eso no podía hacerse, puesto que era ilegal hasta para ellos.
¿He cometido un delito por poner una comilla? Si gracias a eso meten en la cárcel aunque sea a un sólo pedófilo, pues pagaré gustosamente la multa por ello, pero que quede claro que no soy un justiciero y, ni mucho menos, un pedófilo.
Y aquí llega la parte de aclaraciones, acerca de todos los comentarios que he visto en diferentes lugares …
- Lo más importante, no tengo nada que ver con ningún cuerpo del estado. Nadie me ha pedido nada. No colaboro con nadie. No soy un hacker a sueldo. Simplemente informé inicialmente al GDT de la investigación que estaba realizando, sobre lo que he ido encontrando, y posteriormente les cedí el crawler por si les era de utilidad.
Tal y como comenta el capitán del GDT, desde el principio de la investigación lo primero que me ha dicho el GDT es 'cuidado con lo que haces' y cuando he tenido el problema, su ayuda ha sido crucial y me han ahorrado bastantes disgustos dando la cara por mi. Un 10 por la gran labor de todo el equipo del GDT.
- Por otro lado, no he descargado ningún tipo de material pedófilo, ni fotografías, ni vídeos, ni nada. Lo digo porque en algunos comentarios he visto gente que, sin pruebas, me acusa de ello, simplemente por conclusiones propias que han sacado tras leer el artículo. Como he comentado antes, el crawler NO descarga ni imágenes ni vídeos.
- No tengo ningún dump de ninguna base de datos hackeada. Repito que hice la herramienta que permitía dumpear la base de datos de un foro concreto y la facilité al GDT por si ellos podían usarla legalmente, pero no me dediqué a extraer de forma ilegal ningún dato, que por otro lado, tal y como dijo Alejandro Ramos, moralmente me hubiera apetecido sacar los datos de los 30.000 personajes y publicarlos en Internet, pero no lo hice.
- No me dedico a buscar webs de pedófilos ni para denunciarlas ni para reventarlas. Todo ha ocurrido, como he comentado ya decenas de veces, por una investigación acerca de lo que se encuentra en la Deep Web, es decir, por preparar una conferencia.
No soy un justiciero ni nadie que dedique su tiempo libre (que por cierto es muy poco) a cazar pedófilos. Si me topo con alguna web de este estilo me hierve la sangre, al igual que a cualquiera que esté leyendo esto, pero sé de sobra que nadie se puede tomar la justicia por su mano y no es algo que yo haga tampoco.
- ¿Por qué he lanzado el crawler desde casa? ¿soy tonto? ¿un novato? Simplemente, porque no hacía nada ilegal.
Y lo que quiero decir con esto es que los comentarios que he leído en la lista de la Rooted del tipo 'alguien me argumenta la pederastia para pedir poderes excepcionales' o 'me descargo fotos de niños desnudos porque soy un luchador por la libertad' y demás, pues aparte de dolerme por venir de alguien a quien consideraba amigo, están totalmente fuera de lugar, porque repito que todo ha ocurrido por realizar accesos desde un script a páginas HTML de un foro determinado y no por ser 'el tío la vara' ni 'Duckman'.
Mi primera vez
En el artículo también se hace referencia a otro caso de hace unos años en el que visitando una web, que no tiene nada que ver con todo esto, vi unos mensajes despotricando sobre un foro de pedófilos. Entré en ese foro, y vi un montón de comentarios de gente hablando sobre 'sus hazañas' como el que habla de recetas de cocina. Me dio tanta grima que me puse a indagar un poco.
Con un whois vi que el dominio estaba registrado anónimamente pero una geolocalización de la IP situaba el servidor en Barcelona. Además, accediendo por web a la IP en lugar de al dominio, se podían ver una serie de directorios con copias de otros foros previamente desmantelados por las FCSE en diferentes operaciones.
Además de enviar un informe detallado a la Brigada de Investigación Tecnológica (BIT) del CNP y a diferentes asociaciones anti-pedofilia, se lo comente al 'amigo' que aparece aquí:
y que no tardó en hablar con la prensa diciendo que todo lo había hecho él.
y que no tardó en hablar con la prensa diciendo que todo lo había hecho él.
Como curiosidad, la primera vez alerté al CNP y apareció en mi casa la GC enviada por los Mossos. La segunda vez alerté a la GC y apareció en mi casa el CNP … ¿hay una comunicación fluida entre los diferentes cuerpos policiales? Yo creo que no. No dudo que a posteriori exista una comunicación, tal y como afirma el capitán del GDT, y como se ha demostrado en mi caso, pero creo que sería muy interesante un cruce de información inicial para evitar no sólo estos temas sino posibles investigaciones paralelas.
Oiga, pero Tor ¿no es anónimo?
Dejando de lado los motivos de la detención, que creo que han quedado más que claros (si tienes más dudas escribe a hache@salvame_deluxe.es), supongo que mucha gente se hará esta misma pregunta. ¿Cómo te rastrean desde la Deep Web?
Sinceramente yo también le he dado muchas vueltas a la cabeza y tengo algunas teorías:
Control de nodos
- A quiere enviar un mensaje a B, el cual pasará por 3 nodos.
- A usando la clave pública del último nodo (el tercero), cifra el mensaje.
- A usando la clave pública del nodo 2, vuelve a cifrar el mensaje (previamente cifrado).
- Por último, A vuelve a cifrar usando la clave pública del primer nodo.
- El primer nodo recibe el paquete y con su clave privada lo descifra (aún así seguirá teniendo 2 capas de cifrado). Luego lo envía al nodo 2.
- El nodo 2 realiza la misma operación, descifra con su clave privada y manda al nodo 3.
- El último nodo (en este caso) descifra el mensaje obteniendo el paquete en claro, que entregará al destinatario, a B.
Aclarar también que cada nodo únicamente conoce únicamente la ruta hacia el nodo siguiente.
Y aquí tenemos 2 puntos débiles:
- Por un lado, la conexión con el último nodo no va cifrada y si alguien monitoriza ese nodo, verá toda la comunicación en claro … pero esto ocurre cuando accedes desde tu ordenador a una URL pública a través de la red Tor, es decir, accedes a http://cualquierweb.com … pero en el caso de acceder a un dominio .onion no tengo tan claro que ese último paquete llegue a pasar por un nodo de salida, puesto la comunicación NO sale de Tor.
- Por otro lado, supuestamente el primer nodo, donde la información va cifrada, es el que comunica directamente con tu IP y el que mediante diferentes ataques puede revelar tu identidad.
Para más información: https://www.torproject.org/docs/hidden-services.html.en
Y no creo que diga ninguna tontería al suponer que diferentes cuerpos policiales americanos controlan muchos nodos de salida.
Control de descriptores
A diferencia de la Open Web que usa servidores DNS, en la Deep Web, cuando tratamos de acceder a un dominio .onion, nos descargaremos los descriptores de una tabla de hashes distribuida, donde realizaremos la consulta y de donde obtendremos información para llegar a nuestro destino. ¿Y si alguien altera los descriptores de ciertos Onion Router y nos envía a un servidor controlado en lugar de al destino solicitado? ¿Es posible realizar algún tipo de ataque MITM?.
DNS Leaks
Pancake (@trufae) me planteó otra posibilidad que me parece bastante coherente e interesante.
¿En qué consiste un DNS leak? Como se puede apreciar en la imagen, a pesar de que realicemos una comunicación segura a través de una VPN, o en este caso, hacia la red Tor, las consultas DNS se realizan antes de establecer la comunicación.
¿Cuánta gente utiliza las DNSs de Google? Esas que son tan rápidas resolviendo, tan fáciles de recordar y totalmente gratis? Yo soy uno de ellos.
Ahora imaginemos sobre el dibujo anterior que se hace una petición al dominio xxxxx.onion:
- Mi equipo intenta resolver ese dominio a través de mi servidor DNS (el de Google).
- No resuelve pero continúa la navegación usando la red Tor.
- Y la consulta con Google está hecha, donde perfectamente han podido guardar un registro de la URL a la que estaba intentando acceder, desde mi IP, antes de entrar en la red Tor.
Honeypots
¿Quién dice que la web destino, dentro de Tor, no sea un cebo? Siempre cabe la posibilidad de que sea un foro falso montado por el FBI, que tengan un 0-day que afecte a navegadores, y que cuando entre un 'visitante' le infecte, o que traten de colarte algún tipo de malware o troyano … aunque este no sería el caso dado que un crawler ni descarga ni ejecuta.
Diferentes técnicas de ataque a redes Onion
Recomiendo la lectura de:
donde se explican diferentes técnicas para atacar redes Tor, como por ejemplo:
Stream Correlation
Consiste en tratar de ver la correlación de diferentes paquetes capturados. Al estar los datos cifrados, es necesario usar otras técnicas como análisis de tiempos, recuento de paquetes, etc.
Clogging
Consiste en saturar X nodos para forzar la comunicación por uno concreto. Esto actualmente con miles de nodos, no es viable.
Round-Trip Travel Time
Consiste en un ataque desde el servidor destino, que recibe el mensaje, y desde donde se intenta forzar al cliente a realizar un número elevado de conexiones o redirecciones para analizar la frecuencia del tiempo de ida y vuelta. Si esta frecuencia es similar, se puede asumir que las conexiones provienen de una misma ruta.
Metrics for Tor Traffic
Consiste en analizar los factores que provocan, según la definición del algoritmo, las diferentes decisiones que pueden tomarse para que se escoja un determinado nodo (tráfico, latencia, etc).
Correlation Algorithms
Básicamente, controlando el nodo de inicio y el nodo final de un circuito, se trata de comprobar las tramas recogidas en el nodo final (en claro) con las recogidas en el nodo de inicio (cifrado) para buscar una asociación entre ambos.
Reflexiones
No quiero pensar mal pero también que existen muchas papeletas de que el tío Sam apuntara su dedo hacia mí por intercambiar conversaciones a través de Gmail con mi compañero de investigación … y con esto volvemos al todopoderoso Google … ¿leen mis correos? ¿poseen filtros de palabras que hacen saltar alarmas? Si es el caso (algo que nadie duda), ya que leen, que lean todo para poder obtener una visión global de toda la comunicación. Podemos imaginar a un periodista realizando su tesis doctoral sobre terrorismo y realizando búsquedas en Internet que puedan hacer saltar algunas alarmas y, tal y como me ha ocurrido a mi, pasar un mal trago por ello.
Creo que queda en cada uno la decisión de sacrificar tecnología por privacidad. ¿Quiero hacer fotos con el móvil y que, sin ningún esfuerzo, aparezcan solas en mi ordenador? ¿Quiero que mis amigos del pueblo vean mis fotos de la playa? El peaje por ello es que el gran hermano tendrá copia de todo, extraerá los metadatos, sabrá dónde las has tomado, con quién has estado, tu forma de vestir, tus gustos culinarios, …
Tened cuidado ahí fuera y, no hagáis nada malo.
Hache
Suscribirse a:
Entradas
(
Atom
)