30 junio 2013

Enlaces de la SECmana - 181

Leer más...

29 junio 2013

DatalossDB: mantente al día sobre fugas de información


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.

Leer más...

28 junio 2013

Análisis forense en Linux: Adquisición de memoria




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.


Leer más...

27 junio 2013

La supuesta 'back-door' de la NSA en Windows

Ú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
Leer más...

26 junio 2013

Congreso BRAND CARE (4 de julio, Barcelona)


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
Leer más...

25 junio 2013

Vega, herramienta para auditar websites



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

C

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
Leer más...

24 junio 2013

Ahora que Google Reader se va ...

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.
Leer más...

23 junio 2013

Enlaces de la SECmana - 180


Leer más...

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!
Leer más...

21 junio 2013

A pesar de que el tique asignado siga privado y sin resolver a día de hoy, el equipo de Chrome me ha dado permiso para hacer público este fallo que descubrí a finales de marzo. Generalmente, los fallos que permiten bypassear el XSSAuditor de Chrome son calificados por su equipo técnico con un nivel de severidad nulo respecto a la seguridad del navegador, ya que consideran que la brecha se encuentra realmente en la página vulnerable. Tal como indicaron en el hilo de comentarios de la incidencia:

"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.

¡Saludos!

Artículo cortesía de José Rabal Sastre

Leer más...

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.

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
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:
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"
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.
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:

Archivo "configfile.dump"
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
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


Leer más...

17 junio 2013

Hacker Épico (edición Hache)

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


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.


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
Leer más...


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!!!
Leer más...