27 mayo 2015

¡Nos vemos en Hack In The Box 2015 AMS!

A partir de mañana comenzará el congreso Hack In The Box 2015 celebrado en Amsterdam, el cual durante dos días (28 y 29) y con dos tracks simultáneos, podremos disfrutar de un buen conjunto de charlas de seguridad informática en estado puro con ponentes de todo el mundo.



Personalmente, es todo un orgullo haber sido elegido para dar una charla el Viernes 29 a partir de las 15:00 (Track 1) en el que mostraré algunos detalles sobre cómo poder comprometer un sistema de gestión de parkings mediante técnicas muy sencillas, al alcance de todo el mundo que tenga mínimos conocimientos de seguridad en entornos y aplicativos web. A pesar de ello, el impacto que se puede ocasionar es grave.



Obviamente, huelga decir que una vez finalice el evento, tendréis un post en Security By Default relacionado con el contenido de la charla, además de contar tanto con la presentación como con el whitepaper una vez sea publicado por la organización.

¡Pero hay más presencia española en esta edición del congreso! Por un lado, tendremos a Alfonso Muñoz y Sergio de los Santos que darán la charla "Opcodes in Google Play: Tracing Malicious Applications" en el Track 2 el 29 de Mayo de 15:00 a 16:00.


Por otro lado, también podremos ver la charla "Relay Attacks in EMV Contactless Cards with Android OTS Devices" de Ricardo J. Rodríguez y Pepe Vila el Jueves 28 de Mayo de 14:00 a 15:00 en el Track 1.



El resto de la agenda se puede consultar en este enlace o en este documento PDF.

El evento también contará con la presencia, entre otros muchos, de John Matherly, creador de Shodan, que dará la Keynote 2 titulada Return Of The Dragons. Otras charlas que a priori pueden resultar interesantes serán la de What You Always Wanted and Now Can: Hacking Chemical Processes, Supervising the Supervisor: Reversing Proprietary SCADA Tech y The Savage Curtain: Mobile SSL Failures

Esperamos poder cubrir lo máximo posible el evento a través de nuestra cuenta de twitter @secbydefault (con el hashtag oficial #HITB2015AMS) la cual creamos hace ya 6 años para, justamente, cubrir la Black Hat Europe 2009 que también se celebró en Amsterdam.

Si tienes la suerte de pasarte por allí, ¡nos vemos en Hack In The Box 2015!
Leer más...

26 mayo 2015

Haciendo fuerza bruta a contenedores cifrados en Mac OS X



A todos nos ha pasado alguna vez, que guardamos algo tan seguro, tan seguro, tan seguro,…. que no nos acordamos dónde lo dejamos. Hace unos días me tocó tirar de un disco duro que guardo cifrado, mediante el sistema de ficheros HFS+ de Mac, con las opciones Journaled, Encrypted.

Cuando insertas el USB, Mac te muestra un Pop-Up, en el que se te pide la contraseña de desbloqueo del volumen. Todo esto está bien cuando usas esa contraseña a menudo, pero cuando no es el caso dices… por qué habré puesto una contraseña de cifrado tan rara. 

A todo esto, el pop-up, no te permite ver la contraseña en claro, por lo que si te has equivocado en una letra, te toca volverla a escribir completa. Tampoco permite hacer copy-paste, por lo que no podemos escribirla en un bloc de notas y pegarla en la caja de texto, así que volvemos al paso 1. 




Como la contraseña era bastante complicada, me puse a investigar la opción de hacer el montaje desde un terminal.

El comando diskutil tiene múltiples combinaciones que nos permiten gestionar, entre otras cosas, los volúmenes cifrados.

Con el flag “cs list”, el CoreStorage nos muestra la estructura formada por los diferentes Grupos de Volúmenes, Volúmenes Físicos, Familias de Volúmenes Lógicos y finalmente los Volúmenes Lógicos que ve el sistema operativo. Si tenemos habilitado Filevault2 para el cifrado del disco completo (opción muy recomendable), nos aparecerá el primero de ellos, con el volumen desbloqueado (Unlocked dentro del campo Encryption Status)





En el caso que se ve arriba, dentro de la sección Logical Volume, AA0E91…. etc… se puede ver que el Status es Locked.

Con Diskutil y los flags unlockvolume , te pediría por línea de comandos la contraseña de desbloqueo. Si además le añadimos -passphrase , ya nos permite hacerla en claro y ver si nos estamos equivocando o no, hacer copy/paste o incluso… montarnos un bruteforcer. Ya que estaba, he hecho algo muy sencillito pero que si a alguien le puede ser de ayuda, pues aquí lo tiene:




Tan fácil como pasarle con el parámetro -u el UID del volumen a desbloquear y con un -d un fichero “diccionario”, que previamente habremos generado. En este punto, la inteligencia a aplicar es diferente y no voy a entrar. Que haya palabras concatenadas con números, caracteres especiales o lo que queráis, es otra historia diferente. 
Una vez el script acierta con la contraseña, lo deja desbloqueado, pero sin montar.





Nos dice cuál era la contraseña, por si sólo necesitamos eso. Si queremos montarlo, tan sencillo como “diskutil mount disk4” (en este caso) y ya está! 

Lo que es un axioma innegable es que la prisa que te corre recuperar lo que hay dentro de un contenedor cifrado, es directamente proporcional a las posibilidades que te pegues con una contraseña que no funciona (o que no recuerdas ;D)


Leer más...

25 mayo 2015

PowerUp es una herramienta escrita en powershell que forma parte del framework Veil y que facilita la auditoría de sistemas Windows con el propósito de escalar privilegios sin recurrir a alguna vulnerabilidad concreta, como por ejemplo el CVE-2015-1701. Mediante PowerUp se comprueban servicios vulnerables, aplicaciones susceptibles a DLL Hijacking, configuración del registro y otras comprobaciones.

En los servicios comprueba si se almacenó la ruta del binario en el registro tiene comillas o no (Get-ServiceUnquoted), si el binario tiene permisos incorrectos (Get-ServiceEXEPerms) y un usuario puede sobrescribirlo o servicios con permisos incorrectos (Get-ServicePerms).

En el caso de las DLL, permite detectar aplicaciones vulnerables en ejecución (Invoke-FindDLLHijack) o buscar en el PATH del sistema (Invoke-FindPathHijack).

De el registro se comprueba si está habilitado el permiso especial "AlwaysInstallElevated" que permite instalar aplicaciones sin ser administrador (RegAlwaysInstallElevated) y las credenciales de autologon (RegAutoLogon).

Como complemento, la función Get-UnattendedInstallFiles busca ficheros pendientes de instalaciones no atendidas, Get-Webconfig permite descifrar cadenas cifradas de ficheros web.conf y Get-ApplicationHost comprueba el cifrado de los pool de aplicaciones y directorios virtuales.

Una vez identificados todos los problemas; para el análisis de todo el sistema es posible usar Invoke-AllChecks, también existe la opción de explotarlos. Por ejemplo, Write-UserAddMSI genera un instalable que crea un usuario y será útil en caso de que AlwaysInstallElevated esté habilitado o Write-UserAddServiceBinary genera el binario de un servicio al ser arrancado que crea un usuario administrador.

PowerUp PS1
No solo de Metasploit vive el hombre.  
Leer más...

24 mayo 2015

Enlaces de la SECmana - 277

Leer más...

21 mayo 2015

El año pasado, Yago planteaba la pregunta en forma de post: "¿Puede un blog de habla hispana ganar un premio internacional?". En él comentábamos la nominación que recibió Security By Default en los European Security Blogger Awards en la categoría "Best Personal Security Blog"


No recibimos finalmente el premio, pero la verdad es que estar nominados en unos premios de este alcance y compartiendo votos con blogs de tal categoría, para nosotros ya es todo un honor.

Este año, para nuestra sorpresa, Security By Default está nominado en dos categorías:

  • Best Corporate Security blog
  • Best European Corporate Security blog

Ya ha comenzado el período de votación, el cual finalizará el próximo viernes 29 de Mayo a medianoche (GMT)

Puedes realizar las votaciones a través del formulario en el siguiente enlace:


Dentro del formulario, podréis encontrar las nominaciones de Security By Default en las siguientes categorías como hemos comentado anteriormente:

Nominaciones en la categoría "The Best Corporate Security Blog"

Nominaciones en la categoría "The Best European Corporate Security Blog"

El resto de categorías que se han valorado este año son:
  • The Best European Security Podcast
  • The Best Security Podcast
  • The Best Security Video Blog
  • The Best Personal Security Blog
  • The Best European Personal Security Blog
  • The Most Entertaining Blog
  • The Most Educational Blog
  • The Best New Security Blog
  • The Grand Prix Prize for the Best Overall Security Blog
En cuanto a las reglas:
  • Sólo se permite un voto por persona
  • La organización se reserva el derecho de validar cualquiera de los votos utilizando los datos de contacto proporcionados
  • Los ganadores se seleccionarán tanto con las votaciones públicas como con votos de un jurado
  • La decisión de los jueces será la final
Los premios se entregarán durante el Infosec Europe que tendrá lugar en Londres del 2 al 4 de Junio de este año.

Independientemente de ser ganadores de alguna de las categorías, desde Security By Default queremos agradecer a todos los que nos seguís tanto por el blog como por Twitter

Como ya dijimos en el post del año pasado, todo esto es gracias a vosotros

Leer más...

20 mayo 2015

Recursos para análisis de Malware

Introducirse en el mundo del análisis de malware requiere tiempo, disciplina y profundizar en múltiples materias. Localizar muestras, encontrar herramientas, guías etc resulta una tarea muy entretenida y a veces frustrante.

Desde r00tsec nos llega un estupendo artículo en el que recopilan un montón de sites que aglutinan bastante información.

Desde sitios para conseguir muestras (en muchas ocasiones muestras MUY frescas, como el caso de kernelmode.info), listados de C&C, listas de webs relacionadas con malware o listados de servicios online para analizar muestras.

Algunos ejemplos:

 Malware website list

Esta, y mucha más información, en el post original
Leer más...

19 mayo 2015

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:


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


Leer más...