Buenas prácticas de seguridad en Docker

Docker es una plataforma abierta que permite construir, portar y ejecutar aplicaciones distribuidas, se basa en contenedores que corren en Linux y funcionan tanto en máquinas físicas como virtuales simplemente usando un runtime. Está escrito en Go y usa librerías del sistema operativo así como funcionalidades del kernel de Linux en el que se ejecuta. Consta de un engine con API RESTful y un cliente que pueden ejecutarse en la misma máquina o en máquinas separadas. Es Open Source (Apache 2.0) y gratuito.

Los contenedores existen desde hace muchos años, Docker no ha inventado nada en ese sentido, o casi nada, pero no hay que quitarles mérito, están en el momento adecuado y aportan las características y herramientas concretas que se necesitan en la actualidad, donde la portabilidad, escalabilidad, alta disponibilidad y los microservicios en aplicaciones distribuidas son cada vez más utilizados, y no sólo eso, sino que también son mejor entendidos por la comunidad de desarrolladores y administradores de sistemas. Cada vez se desarrollan menos aplicaciones monolíticas y más basadas en módulos o en microservicios, que permiten un desarrollo más ágil, rápido y a la vez portable. Empresas de sobra conocidas como Netflix, Spotify o Google e infinidad de Start ups usan arquitecturas basadas en microservicios en muchos de los servicios que ofrecen.

Te estarás preguntando ¿Y no es más o menos lo mismo que hacer un chroot de una aplicación? Sería como comparar una rueda con un coche. El concepto de chroot es similar ya que se trata de aislar una aplicación, pero Docker va mucho más allá, sería un chroot con esteroides, muchos esteroides. Por ejemplo, puede limitar y controlar los recursos a los que accede la aplicación en el contenedor, generalmente usan su propio sistema de archivos como UnionFS o variantes como AUFS, btrfs, vfs, Overlayfs o Device Mapper que básicamente son sistemas de ficheros en capas. La forma de controlar los recursos y capacidades que hereda del host es mediante namespaces y cgroups de Linux. Esas opciones de Linux no son nuevas en absoluto, pero Docker lo hace fácil y el ecosistema que hay alrededor lo ha hecho tan utilizado. 

Adicionalmente, la flexibilidad, comodidad y ahorro de recursos de un contenedor es mayor a la que aporta una máquina virtual o un servidor físico, esto es así en muchos casos de uso, no en todos. Por ejemplo, tres servidores web para un cluster con Nginx en una VM con una instalación de Linux CentOS mínima ocuparía unos 400MB, multiplicado por 3 máquinas sería total de uso en disco de 1,2 GB, con contenedores serían 400MB las mismas 3 máquinas corriendo ya que usa la misma imagen para múltiples contenedores. Eso es sólo por destacar una característica interesante a nivel de recursos. Otro uso muy común de Docker es la portabilidad de aplicaciones, imagina una aplicación que solo funciona con Python 3.4 y hacerla funcionar en un sistema Linux con Python 2.x es complicado, piensa en lo que puede suponer en un sistema en producción actualizar Python, con contenedores sería casi automático, descargar la imagen del contenedor y ejecutar la aplicación de turno. 

Solo por ponernos en situación de la envergadura Docker, unos números alrededor del producto y la compañía (fuente aquí):

• 95 millones de dólares de inversión.
• Valorada en 1.000 millones de dólares.
• Más de 300 millones de descargas en 96 releases desde marzo de 2013

Pero un contenedor no es para todo, ni hay que volverse loco “dockerizando” cualquier cosa, aunque no es este el sitio para esa reflexión. Al cambiar la forma de desarrollar, desplegar y mantener aplicaciones, también cambia en cierto modo la forma de securizar estos nuevos actores.

Docker aporta seguridad en capas, aísla aplicaciones entre ellas y del host sin usar grandes recursos, también se pueden desplegar contenedores en máquinas virtuales lo que aporta otra capa adicional de aislamiento (estaréis pensando en VENOM pero eso es otra película que no afecta directamente a Docker). Dada la arquitectura de Docker y usando buenas prácticas, aplicar parches de seguridad al anfitrión o a aplicaciones suele ser más rápido y menos doloroso.

Buenas Prácticas de Seguridad:

Aunque la seguridad es algo innato en un contenedor, desde Docker Inc. están haciendo esfuerzos por la seguridad, por ejemplo, contrataron hace unos meses a ingenieros de seguridad de Square, que no son precisamente nuevos en el tema. Ellos, junto a compañías como VMware entre otras, han publicado recientemente un extenso informe de sobre buenas prácticas de seguridad en Docker en el CIS. Gracias a este informe tenemos acceso a más de 90 recomendaciones de seguridad a tener siempre en cuenta cuando vamos a usar Docker en producción. En la siguiente tabla podemos ver las recomendaciones de seguridad sugeridas, algunas son muy obvias pero un check list así nunca viene mal:

1. Recomendaciones a nivel de host

1.1. Crear una partición separada para los contenedores 

1.2. Usar un Kernel de Linux actualizado 

1.3. No usar herramientas de desarrollo en producción

1.4. Securizar el sistema anfitrión 

1.5. Borrar todos los servicios no esenciales en el sistema anfitrión

1.6. Mantener Docker actualizado 

1.7. Permitir solo a los usuarios autorizados controlar el demonio Docker

1.8. Auditar el demonio Docker  (auditd)

1.9. Auditar el fichero o directorio de Docker - /var/lib/docker 

1.10. Auditar el fichero o directorio de Docker - /etc/docker 

1.11. Auditar el fichero o directorio de Docker - docker-registry.service 

1.12. Auditar el fichero o directorio de Docker - docker.service 

1.13. Auditar el fichero o directorio de Docker - /var/run/docker.sock 

1.14. Auditar el fichero o directorio de Docker - /etc/sysconfig/docker 

1.15. Auditar el fichero o directorio de Docker - /etc/sysconfig/docker-network 

1.16. Auditar el fichero o directorio de Docker - /etc/sysconfig/docker-registry 

1.17. Auditar el fichero o directorio de Docker - /etc/sysconfig/docker-storage 

1.18. Auditar el fichero o directorio de Docker - /etc/default/docker 

2. Recomendaciones a nivel de Docker Engine (daemon)

2.1 No usar el driver obsoleto de ejecución de lxc 

2.2 Restringir el tráfico de red entre contenedores 

2.3 Configurar el nivel de logging deseado 

2.4 Permitir a Docker hacer cambios en iptables 

2.5 No usar registros inseguros (sin TLS)

2.6 Configurar un registro espejo local

2.7 No usar aufs como driver de almacenamiento

2.8 No arrancar Docker para escuchar a  una IP/Port o Unix socket diferente

2.9 Configurar autenticación TLS para el daemon de Docker

2.10 Configurar el ulimit por defecto de forma apropiada



3. Recomendaciones a nivel de configuración de Docker

3.1 Verificar que los permisos del archivo docker.service están como root:root 

3.2 Verificar que los permisos del archivo docker.service están en 644 o más restringidos 

3.3 Verificar que los permisos del archivo docker-registry.service están como root:root 

3.4 Verificar que los permisos del archivo docker-registry.service están en 644 o más restringidos

3.5 Verificar que los permisos del archivo docker.socket están como root:root 

3.6 Verificar que los permisos del archivo docker.socket están en 644 o más restringidos

3.7  Verificar que los permisos del archivo de entorno Docker (/etc/sysconfig/docker o /etc/default/docker) están como root:root 

3.8 Verificar que los permisos del archivo de entorno Docker (/etc/sysconfig/docker o /etc/default/docker) están en 644 o más restringidos

3.9 Verificar que los permisos del archivo /etc/sysconfig/docker-network (si se usa systemd) están como root:root 

3.10 Verificar que los permisos del archivo /etc/sysconfig/docker-network están en 644 o más restringidos

3.11  Verificar que los permisos del archivo /etc/sysconfig/docker-registry (si se usa systemd) están como root:root

3.12 Verificar que los permisos del archivo /etc/sysconfig/docker-registry (si se usa systemd) están en 644 o más restringidos

3.13 Verificar que los permisos del archivo /etc/sysconfig/docker-storage (si se usa systemd) están como root:root 

3.14 Verificar que los permisos del archivo /etc/sysconfig/docker-storage (si se usa systemd) están en 644 o más restringidos 

3.15 Verificar que los permisos del directorio /etc/docker están como root:root 

3.16 Verificar que los permisos del directorio /etc/docker están en 755 o más restrictivos 

3.17 Verificar que los permisos del certificado del registry están como root:root 

3.18 Verificar que los permisos del certificado del registry están en 444 o más restringidos 

3.19 Verificar que los permisos del certificado TLS CA están como root:root 

3.20 Verificar que los permisos del certificado TLS CA están en 444 o más restringidos 

3.21 Verificar que los permisos del certificado del servidor Docker están como root:root 

3.22 Verificar que los permisos del certificado del servidor Docker están en 444 o más restringidos 

3.23 Verificar que los permisos del archivo de clave del certificado del servidor Docker están como root:root 

3.24 Verificar que los permisos del archivo de clave del certificado del servidor Docker están en 400 

3.25 Verificar que los permisos del archivo de socket de Docker están como root:docker 

3.26 Verificar que los permisos del archivo de socket de Docker están en 660 o más restringidos 

4. Imágenes de Contenedores y Dockerfiles

4.1 Crean un usuario para el contenedor

4.2 Usar imágenes de confianza para los contenedores 

4.3 No instalar paquetes innecesarios en el contenedor

4.4 Regenerar las imágenes si es necesario con parches de seguridad

5. Runtime del contenedor

5.1 Verificar el perfil de AppArmor (Debian o Ubuntu) 

5.2 Verificar las opciones de seguridad de SELinux (RedHat, CentOS o Fedora) 

5.3 Verificar que los contenedores esten ejecutando un solo proceso principal

5.4 Restringir las Linux Kernel Capabilities dentro de los contenedores 

5.5 No usar contenedores con privilegios   

5.6 No montar directorios sensibles del anfitrión en los contenedores

5.7 No ejecutar ssh dentro de los contenedores

5.8 No mapear puertos privilegiados dentro de los contenedores

5.9 Abrir solo los puertos necesarios en un contenedor

5.10 No usar el modo “host network” en un contenedor 

5.11 Limitar el uso de memoria por contenedor 

5.12 Configurar la prioridad de uso de CPU apropiadamente 

5.13 Montar el sistema de ficheros raíz de un contenedor como solo lectura

5.14 Limitar el tráfico entrante al contenedor mediante una interfaz específica del anfitrión

5.15 Configurar la política de reinicio 'on-failure' de un contenedor a 5 

5.16 No compartir PID de procesos del anfitrión con contenedores

5.17 No compartir IPC del anfitrión con contenedores 

5.18 No exponer directamente dispositivos del anfitrión en contenedores

5.19 Sobre-escribir el ulimit por defecto en tiempo de ejecución solo si es necesario



6. Operaciones de Seguridad en Docker

6.1 Realizar auditorías de seguridad tanto en el anfitrión como en los contenedores de forma regular

6.2 Monitorizar el uso, rendimiento y métricas de los contenedores

6.3 Endpoint protection platform (EPP) para contenedores (si las hubiese) 

6.4 Hacer Backup de los datos del contenedor 

6.5 Usar un servicio centralizado y remoto para recolección de logs

6.6 Evita almacenar imágenes obsoletas, sin etiquetar correctamente o de forma masiva.   

6.7 Evita almacenar contenedores obsoletos, sin etiquetar correctamente o de forma masiva.

En algunos casos, hay recomendaciones que merecen un artículo por si solas. Si quieres profundizar más en este tema recuerda que los pormenores de estos aspectos de seguridad y auditoría los ampliaremos durante el curso online de Securízame "Hardening de Windows, Linux e Infraestructuras" en el que colaboraré junto a Lorenzo Martínez, Yago Jesús, Juan Garrido y Pedro Sanchez, todo un lujo de curso en el que aportaré mi granito de arena con seguridad en Docker completando el módulo de Hardening Linux. Más información aquí: https://www.securizame.com/curso-online-hardening-sistemas-windows-linux-infraestructuras/

Para otros posibles artículos en el futuro me parece interesante ver algunas consideraciones de seguridad en Docker Hub y otros componentes relacionados, así como auditorías de contenedores con Lynis.

Recursos y referencias:

https://d3oypxn00j2a10.cloudfront.net/assets/img/Docker%20Security/WP_Intro_to_container_security_03.20.2015.pdf

https://benchmarks.cisecurity.org/tools2/docker/CIS_Docker_1.6_Benchmark_v1.0.0.pdf

Contribución por Toni de la Fuente (@toniblyx y blyx.com)

Leer más...

Tunelizar conexiones de manera selectiva en Windows

El trabajo de un auditor, administrador de seguridad, etc.., requiere que en su día a día tenga que estar conectado, y siempre hablando de determinados escenarios, a varias redes, establecer conexiones con un origen específico, uso de conexiones VPN, etc..

El otro día, hablando con Jose Selvi vía telefónica sobre cosas mundanas y terrenales, me comentaba que en su portátil con Windows había tenido que configurar este tipo de cosas.

Es interesante destacar que, como hemos comentado en anteriores párrafos, en determinados escenarios puede ser interesante encaminar cierta parte de nuestro tráfico a través de distintas redes. Como principal ejemplo Selvi me comentaba que esto lo hacía cuando no gestionaba el EndPoint – por ejemplo una VPN que no controlamos – y que no le gustaba que cierto tráfico de su propiedad se pudiese ver “comprometido” o dar facilidades de acceso al mismo a un tercero.

Hay muchas opciones y muchos escenarios en donde también es interesante habilitar este tipo de configuraciones, como por ejemplo si necesitamos utilizar la salida de una determinada herramienta para alimentar a otra y no queremos andar “parseando” tráfico local nuestro. Otro ejemplo se puede dar cuando en determinadas auditorías exigen que se entregue una bitácora de peticiones – por ejemplo en formato PCAP – a modo de auditoría.

En Linux esto es posible realizarlo a través de netfilter/iptables y con las opciones de PREROUTING. Para hacerlo en Windows necesitamos entender cómo se gestionan y se crean conexiones de tipo VPN para luego poder encaminar los datos que necesitemos.

Cuando Windows genera una conexión VPN y nos conectamos a través de ella, el sistema operativo crea una ruta por defecto en la que se indica que todo nuestro tráfico lo encaminará a través de dicha conexión, y será el servidor final el que tendrá que realizar una acción de forwarding en caso de que se utilice también como conexión a Internet. Esto se puede verificar una vez conectados a la VPN con un simple route print.

Imagen 1. Información en la tabla de rutas

En caso de que no queramos que todo el tráfico pase por la VPN, en Windows pasa por configurar la nueva conexión de acceso remoto y desmarcar las opciones de Default Gateway en IPv4 e IPv6. Para ello, y en tus conexiones de red, debes configurar esta opción en la pestaña Networking de tu conexión de acceso remoto.

Imagen 2.- Conexiones de acceso remoto en Windows

Una vez desmarcada esta opción, usaremos la flexibilidad del comando route, y generaremos las entradas necesarias para encaminar el tráfico deseado por la conexión VPN. Para ello necesitamos conocer varios elementos:

• Dirección - Rango de direcciones – Redes completas a encaminar
• Número de interfaz

El número de interfaz se puede averiguar con el propio comando route print, o también a través del instrumental de administración de Windows.

Imagen 3.- Extracción de InterfaceIndex a través de WMI

Una vez tengamos estos datos, podremos utilizar la flexibilidad que nos otorga la creación de rutas para generar la nuestra. En el caso de que necesitemos generar una ruta para una dirección IP concreta, se podrá utilizar el siguiente comando:

Imagen 4.- Creación de ruta en Windows

En caso de necesitar que la ruta fuese persistente, se puede hacer uso del flag –p. Una vez realizado este paso para cada una de las direcciones IP o redes concretas, la próxima vez que nos conectemos a través de esa red VPN, todas las conexiones realizadas desde nuestro equipo a esas direcciones IP, se encaminarán a través de la conexión remota. El resto de peticiones se realizará con nuestra conexión local.

Si se desea realizar esto de manera masiva – por ejemplo a través de Directorio Activo y a un número determinado de equipos – se puede realizar a través de PowerShell y políticas de grupo. Para los interesados Microsoft ha generado un documento con scripts de ejemplo, el cual puedes descargar desde la siguiente dirección:

http://www.microsoft.com/en-us/download/details.aspx?id=2555

Los servicios y aplicaciones Microsoft permiten determinados tipos de configuraciones y vías de fortificación con mucha flexibilidad y a través de múltiples vías. Para los que estéis interesados en este tipo de tips y escenarios de fortificación avanzados, Lorenzo Martínez, uno de los editores de SecurityByDefault, me ha invitado a dar unas sesiones en el curso de Hardening de Sistemas Windows, Linux e Infraestructuras, y del cual estoy encantado de participar junto a buenos ponentes y amigotes, como Pedro Sánchez o Yago Jesús. Si quieres más información, así como un índice del mismo, puedes consultar el siguiente enlace:

https://www.securizame.com/curso-online-de-hardening-de-sistemas-windows-y-linux-e-infraestructuras_jg/

Referencias adicionales

https://technet.microsoft.com/nl-nl/library/ee431701(v=ws.10).aspx

                                                                                                                             Juan Garrido (@tr1ana)

                                                                                                                             MVP Enterprise Security

Leer más...

Enlaces de la SECmana - 276

• Vulnerabilidad con campaña mediática detrás (nombre, logo, eslogan...): VENOM, afecta a QEMU, software de virtualización ampliamente utilizado. Más detalles también en este enlace la lista OSS-Security
• Número 3 de la revista digital CIBER Elcano ya disponible
• Nueva versión de TeslaCrypt que utiliza la extensión .EXX
• Post de Silvia Barrera (Jefa de Grupo de Redes de la Unidad de Investigación Tecnológica de la Policia Nacional) en Tecnoxplora sobre los peligros con los acortadores de URL
• Gran actualización en el portal de Offensive Security, Exploit-DB
• En Full-Disclosure, cómo detectar interfaces de red en modo promiscuo mediante WMIC
• Comienzan los preparativos para el Capture The Flag de la próxima hack.lu que se celebrará en Octubre de 2015
• Tras el anuncio de un supuesto Jailbreak de PS4, se confirma que ya se está comercializando con él en Brasil.
• Información en Forbes sobre la charla de la próxima Hack In The Box en Amsterdam en referencia a graves vulnerabilidades encontradas en algunos sistemas de gestión de Parkings.
• Supuesto hackeo de una pantalla publicitaria en Atlanta en la cual publicaron un Goatse.
• Analizando el MS15-050 con Diaphora, el plugin de diffing de binarios para IDA Pro de Joxean Koret. La vulnerabilidad se encuentra en el Windows Service Control Manager (SCM) de Windows que permitiría la ejecución de código.

Leer más...

Y tu, ¿tapas las cámaras de tus dispositivos?

Llevaba tiempo dándole vueltas al asunto de la privacidad y las cámaras de los móviles, pensando ¿por qué si tapaba la cámara del PC no hacía lo mismo con la del télefono? A fin de cuentas, es un dispositivo que cada vez se usa más o incluso ha llegado a prácticamente sustituir al ordenador para el usuario medio. Siempre se ha dicho que hay que tapar la cámara para protegernos, aunque como veremos más adelante no todo el mundo comparte la misma opinión, sin embargo, yo nunca he visto a nadie con conocimiento de causa recomendar tapar la cámara de los móviles.

Esto me llevó a crear una pequeña encuesta en un foro que frecuento, preguntando sobre si los otros usuarios tapaban o no las cámaras de su smartphones o tablets. Para mi sorpresa, muchos empezaron a contestar diciendo que ni si quiera tapaban la del ordenador, como para tapar la del móvil. Esto me chocó bastante, ya que estamos hablando de un foro técnico en el que hay gran cantidad de gente con certificaciones de seguridad. Visto esto, decidí crear una encuesta en Google Forms que publiqué en distintos sitios dónde se supone que el público tiene concienciación sobre la privacidad y la seguridad informática:

• Un foro sobre certificaciones y trabajo en IT, con gran cantidad de gente con CISSP, CISM, CISA, Security+, OSCP, CEH....
• El canal ##security de FreeNode
• Un foro sobre cypherpunk
• El grupo de LinkedIn de la EFF
• La lista de correos de la RootedCON

Por lo tanto, los resultados de este análisis están basados en gente que se supone que tiene cierta base en seguridad y privacidad.

Antes que nada, me gustaría aclarar una cosa, ya que recibí varias quejas sobre por qué hacía una encuesta anónima y sin embargo requería tener cuenta en Google. Esto era simplemente por utilizar la opción de evitar que una misma persona pudiera votar más de una vez, pero en ningún caso yo podía ver quién votó y quién no.

Figura 1 - Aparte de los resultados sólo aparecía la hora a la que se votó

Dicho esto, veámos los resultados de esta pequeña encuesta en la que han participado 100 personas. En el caso de los ordenadores:

Figura 2 - Votación sobre la cámara de los ordenadores

Considerando el público que fue encuestado, me parece sorprendente que hayan tantos que han votado no. Las opiniones de los que defienden que tapar la cámara es irrelevante se pueden resumir en:

• El micrófono es más importante que la cámara.
• No es necesario ya que la luz indica cuando está en funcionamiento.
• La probabilidad de que te hackeen es mínima.
• Si alguien tiene acceso a la cámara, significa que ya tiene acceso al sistema, por lo que que pueda verme la cara es el menor de mis problemas.
• Me da igual que me saquen una foto, no hay nada que esconder.
• No es una amenaza seria.
• No cubrir la cámara permite identificar a un posible ladrón. 

En mi opinión, esta última es la única que tiene una base razonable, y de hecho, se han recuperado ordenadores gracias a eso. El resto son ampliamente debatibles. Por ejemplo, el caso del micrófono, yo también estoy de acuerdo en que el micrófono es igual o incluso más importante que la cámara, especialmente en un entorno laboral. Pero, y qué? Por este motivo no hay que decidir implementar otra medida de seguridad? Me quedo con el comentario de Kinomakino en la lista de la Rooted:

por que pones un un waf, si actualizas wordpress? por que fortificas

wordpress, si tienes waf y updates? porque gestionas el siem, si tienes waf,

updates, fortificación? por qué pones un antivirus si tienes...

TODAS las medidas que pongamos para velar por nuestra seguridad y la de los

que nos rodean (empresa-familia) que no impliquen una perdida/Deterioro del

servicio, no se porque no ponerlas en marcha.

Sobre el tema de la luz, está demostrado que se puede activar la cámara sin encender el LED. De hecho, esta es una de las técnicas que usó el FBI en la búsqueda de un terrorista.

La opinión de que si se tiene acceso a la cámara significa que se tiene acceso al sistema no la veo acertada (puedo equivocarme que conste), pero entiendo que está opinión se basa en que el sistema tiene un RAT y no tiene por qué ser siempre así. Veáse por ejemplo la reciente vulnerabilidad de Flash Player, CVE-2015-3044.

Que la probabilidad de tener problemas a través de la cámara sea mínima es aceptable teniendo en cuenta la base de los votantes, ya que se supone que cada uno sabe como defender sus sistemas. Pero, tanto cuesta colocar un trocito de cinta como media preventiva ante un 0day?

Por último y no menos importante, no hay que ser tan narcisista. No sólo se trata de que se pueda ver a la persona física que hay detrás, que esto ya de por sí es una violación de privacidad, sino también de ver el entorno, con el objetivo de obtener cualquier pieza de información que pueda ser utilizada posteriormente en un ataque. Por ejemplo, en una búsqueda rápida por "webcam selfies", me encuentro esta imagen de un adolescente en el que se puede observar en el fondo que es fan de One Direction. Un dato tal vez irrelevante, pero quién sabe... También se pueden encontrar títulos, diplomas, fotos....

Figura 3 - Un fan de One Direction

Los resultados de la votación sobre los smartphones son los siguientes:

Figura 4 - Votación sobre la cámara de los smartphones

Como me imaginaba se puede observar que la mayoría no tapamos la cámara de nuestros teléfonos. La opción de Yes implica tanto la cámara delantera y la trasera, como solo la trasera en caso de que el terminal no disponga de cámara frontal. Como era de esperar, nadie protege únicamente la cámara trasera en caso de tener ambas cámaras.

Añadido a lo dicho anteriormente, otro de los motivos por los que no se tapan las cámaras es porque generalmente el móvil se encuentra o bien en el bolsillo o bien sobre una mesa. Respecto a lo segundo, hay que tener en cuenta el campo de visión de la cámara.

Qué medidas se pueden tomar para hacer frente a esto? Algunos más radicales sugieren quitar los drivers del dispositivo, pero esto afecta directamente a la usabilidad. Si nunca vas a utilizar la cámara, pues bueno..., pero generalmente no es una buena opción. La solución más fácil y práctica es aplicar algo tan simple como un trozo de cinta negra o algo "más elaborado" como un parche con una pestaña deslizante, aunque esto puede provocar que no se pueda cerrar la tapa correctamente. En el caso de una webcam externa, mirando para la pared o desenchufada cuando no se use (y así se evita el problema del micrófono también!).

Ayoze Fernández (@ayozint)

www.ayozint.com

Leer más...

ThreatGlass: Recopilación de páginas comprometidas con malware web

Ya hace aproximadamente un año que Barracuda Labs publicó su portal web Threatglass, cuyo objetivo es permitir a los usuarios compartir y recopilar páginas comprometidas mediante malware tipo web.

El backend de dicho portal se encarga además de navegar por el top de páginas de Alexa con el objetivo de analizarlas y, en caso de detectar un positivo, realizar una captura y enlazarlo en el panel. Adicionalmente, es posible enviar portales a través de la opción de Submit

Para cada web, se ofrece la posibilidad de:

• Mostrar visualmente el acceso a la web que contiene el malware
• Información referente al malware
• Listado de dominios solicitados
• Enumeración de tráfico anómalo detectado
• Descargar fichero PCAP con la captura de red generada al acceder a dicho portal

A continuación podemos ver un ejemplo de aparición en el portal, que corresponde a PHP.net, el cual fue detectado como comprometido el 22 de Octubre de 2013.

Captura de PHP.net comprometida al haber incluido malware

Tabla de tráfico anómalo detectado al acceder a PHP.net cuando fue comprometido

Sin duda otra nueva fuente de información que nos puede venir bien en tareas de análisis, y sin duda es el típico portal donde no interesa nunca aparecer. Si encuentras tu dominio tras la búsqueda, mala señal...

[+] Threatglass.com by Barracuda Labs

[+] Introducing ThreatGlass

Leer más...