Security By Default

Cámaras IP de Videovigilancia: Seguridad y Protección, o Inseguridad y Exposición

2013-06-19T07:42:00.000+02:00

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.

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.

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

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

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.

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

Para más información, las vulnerabilidades fueron reportadas en fulldisclosure en este enlace.

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:

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:

Archivo "../etc/device.conf"

CVE-2013-3691, Airlive. Denegación de Servicio (DoS).

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.

http://xx.xx.xx.xx/[a*3000]

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:

http://xx.xx.xx.xx/cgi-bin/hardfactorydefault

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.

http://xxx.xxx.xxx.xxx/configfile.dump?action=get

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:

Archivo "configfile.dump"

CVE-2013-3690, Brickcom. Cross Site Request Forgery (CSRF) + Privilege Escalation.
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.

El código, junto con un manual de usuario, están disponibles en el siguiente enlace:

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:

Eliezer Varadé Lopez
Javier Repiso Sánchez
Jonás Ropero Castillo

Hacker Épico (edición Hache)

2013-06-17T22:13:00.000+02:00

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.

Bueno y como resumen de esta desagradable historia, al menos para mi, recalcar una vez más que NO se me ha detenido por 'hacking' sino por posible 'corrupción de menores'. Sí, suena fuerte, pero es así.

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í:

http://elpais.com/diario/2010/06/06/sociedad/1275775203_850215.html

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

Básicamente el funcionamiento de los Onion Routers consiste en aplicar capas con diferente cifrado en cada nodo por el que va a pasar nuestro paquete. Un ejemplo:

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.

Y ya está listo el paquete, en este caso con 3 capas de cifrado, para su envío:

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:

Analyzing the Effectiveness of Passive Correlation Attacks on the Tor Anonymity Network

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

Monitorización de temperatura de UTMs NetASQ desde Nagios

2013-06-17T06:32:00.000+02:00

Me sucede con gran frecuencia, que mis clientes me sorprenden pidiéndome soluciones para sus sistemas, que escapan a lo que las propias herramientas permiten hacer. En este caso, un responsable de seguridad y sistemas, que tiene como objetivo el correcto funcionamiento y monitorización de un parque importante de dispositivos UTM NetASQ, que no siempre están en un CPD con condiciones óptimas de refrigeración, me indicó que quería poder adelantarse al verano, controlando la temperatura de todos estos equipos. A bote pronto, se me ocurrió que lo más normal sería obtener este dato por SNMP, o quizá, algún proceso del sistema operativo del propio NetASQ, lo guardaría de forma periódica en un fichero,… pero como andaba liado de tiempo, abrí un ticket en soporte. "Hola, he visto que en el Dashboard de gestión de estos equipos aparece la temperatura y quisiera que me dijeseis cómo poder acceder a él para monitorizarlo desde Nagios remotamente. ¿Se puede hacer por SNMP?". Respuesta de soporte: "Hola, lamentamos informarle que no es posible acceder a este dato por SNMP" Vaya… y yo que le he dicho al cliente que lo diese por hecho ¿y ahora qué hacemos?

Investigando qué hace el Dashboard por debajo, para el widget de la temperatura,.. y tirando de Tamper Data una vez más, ví que hacía una llamada a un procedimiento RPC llamado "MONITOR STATS". Hablando de este tema con el director técnico de NetASQ en España, me indicó que existía un a herramienta ejecutable desde un terminal, que permite inyectarle comandos y devuelve un resultado.

Se puede hacer en modo "una_sola_línea" mediante una sintaxis algo así como: nsrpc -c fichero_comando usuario:contraseña@IP_NetASQ, de manera que ejecutará lo que tenga dentro el "fichero_comando".

La plataforma desde la que iba a hacer estas pruebas es Nagios montado sobre Linux, por lo que el comando nsrpc no existía, aparte que implicaría tener que abrir el puerto TCP/1300 (por donde acepta las conexiones un NetASQ), para las peticiones desde la máquina Nagios, modificar políticas de seguridad en un montón (más de 80) equipos, así que… hubo que pensar en algo, con lo que ya tenía, que era acceso SSH desde la IP del Nagios.

Se me ocurrió que mediante comandos SSH, podría ejecutar todo lo necesario y extraer en remoto el valor que quería: la temperatura actual del equipo.

Como variables, establezco el usuario y contraseña SSH ($user/$pass), así como el $host al que me conecto, y creo en /tmp el fichero "comando" con el contenido a ejecutar

sshpass -p $pass ssh $user\@$host -o StrictHostKeyChecking=no "echo MONITOR STAT > /tmp/comando"

Lo siguiente es ejecutarlo en remoto, dejando el resultado de la ejecución en /tmp/comando en el sistema remoto ($internal_ip es la IP del equipo desde la que está permitido implícitamente que responda por RPC):

sshpass -p $pass ssh $user\@$host -o StrictHostKeyChecking=no "nsrpc -c /tmp/comando $user:$pass\@$internal_ip > /tmp/output"

Veréis que he incluido la opción "-o StrictHostKeyChecking=no" en el comando SSH. Esto es porque desde la máquina Nagios, hay equipos a los que nunca nos hemos conectado, por lo que para saltarnos la aceptación del certificado, "confiamos" donde nos estamos conectando.

Lo siguiente es "traerme" el contenido de la salida del comando anterior. Podría hacerlo con "scp", pero era aún más rápido hacerme un cat del fichero y guardarlo en una variable "$devuelve"

my $devuelve=`sshpass -p $pass ssh $user\@$host -o StrictHostKeyChecking=no "cat /tmp/output"`;

Después borro los rastros que haya dejado en el sistema remoto

sshpass -p $pass ssh $user@$host -o StrictHostKeyChecking=no "rm -rf /tmp/output /tmp/comando";

Ahora queda procesar el contenido de $devuelve para extraer únicamente la temperatura y tomar decisiones. Hasta ahora muy bien en modo BASH, pero hay que integrarlo con Nagios, y hacer que reciba entradas y devuelva resultados en el formato parseable por el sistema de monitorización.

Directamente, decidí hacerlo en Perl, con el menor número de módulos posibles (para evitar "ensuciar" el sistema Nagios), por lo que pido disculpas por la mezcla de llamadas a "system" dentro del código. El script es tan sencillo como las siguientes líneas:

En la configuración de Nagios, hay que modificar el fichero /etc/nagios/objects/commands.cfg y añadir lo siguiente:

define command{

command_name check_temp_netasq

command_line $USER1$/check_temp_netasq -H $HOSTADDRESS$ $ARG1$

}

Y luego en el fichero correspondiente al host con la configuración Nagios, indicaremos la llamada al comando con los parámetros -w y -c, siendo respectivamente la temperatura a partir de la cual queremos que cambie el estado a Warning y a Critical:

define service{

use generic-service ; Name of service template to use

host_name FQDN_or_IP_Address_NetASQ_device

service_description NetASQ_Temp

check_command check_temp_netasq!-w 45 -c 50

notifications_enabled 1

}

Bueno, pues esto así, tal cual… si se ejecuta desde línea de comandos, funciona estupendamente. Si se comprueban los valores de ejecución del comando con un "echo $?", devuelve 0, 1 ó 2, dependiendo de lo que suceda con la temperatura, pero desde Nagios, da un error en la ejecución del plugin con el mensaje "service check did not exit properly". Investigando el error, encontré un link muy interesante que dice que los exit de los plugins hechos en Perl, han de hacerse importando la variable %ERRORS y saliendo con exit $ERRORS{'OK'}, en vez de con exit 0… sustituyendo OK por WARNING o CRITICAL para los otros valores.

Sin embargo, después de pegarme un buen rato con ello, no hubo manera, y me sigue dando los mismos errores. ¿Solución? Según encontré aquí, poner en medio un subprograma en BASH que recoja bien los valores y los envíe de vuelta a Nagios. Este programita check_debug.sh deja logs en un fichero, pero se puede eliminar esa parte para que no ocupe de más, y simplemente nos haga el trabajo del parsing correcto de valores.

#!/bin/bash

RESULT=`$* 2>&1`

EXITCODE=$?

echo $RESULT

exit $EXITCODE

En este caso, la definición del comando en Nagios se haría así:

define command{

command_name check_temp_netasq

command_line $USER1$/check_debug.sh $USER1$/check_temp_netasq -H $HOSTADDRESS$ $ARG1$

}

Como véis es un script muy sencillo, y sé que por esto no me van a dar el premio a "programador del año", pero os puedo decir que así funciona correctamente y si a uno solo de nuestros lectores le sirve para su instalación, habrá merecido la pena compartirlo.... y si no, pues por parte de Securízame, otro cliente satisfecho!!!