RootedCon Valencia 2019 Thumbnail


RootedCon Valencia 2019

Cada año en la ciudad de Valencia tiene lugar una de las conferencias más conocidas por todos, o al menos, más sonada. Se trata de 2 días intensos en los que se dan formaciones y charlas sobre diversos temas enfocados en el hacking, la tecnología y la seguridad informática, con participantes y público de toda índole.

Este año hemos tenido la ocasión de ir como pequeña "delegación" de APSL a disfrutar de charlas variopintas y aprender acerca de Docker y el SecDevOps.

A lo largo de este post iremos abordando desde la formación que nos ha brindado Elías el Grande (🐦 @3grander) como algunas de las ponencias a las que hemos podido asistir. Pequeño spoiler, hemos asistido a todas.

Primer día, formación.

Como he comentado, Elías nos ofreció una formación sobre Docker, SecDevOps y algunos tips para hacer los contenedores e imágenes de Docker más seguras.

Para los que no sepáis lo que es Docker, tenéis un poco de información en la página oficial.

Comenzamos viendo la forma en la que se comunicaba cada contenedor de Docker y las redes que gestiona Docker por defecto, que son bridge, host y none y el motivo de cada una de estas redes. La red más curiosa de todas era la red none que, como explicó Elías, se trata de una red que no se conecta a nada y que está pensada para contenedores cuya funcionalidad es solo, por ejemplo, de computo.

Vimos cómo se construye una imagen Docker a través el archivo Dockerfile usando una amplia lista de comandos tipo FROM, RUN, ENV, VOLUME, WORKDIR, STOPSIGNAL y un largo etcétera.

Tenéis más información aquí.

La charla tomó cierto auge cuando Elías pasó a hablar sobre "Buenas Prácticas de Seguridad" y qué puntos había que tener en cuenta. Tened en cuenta que varios de estos puntos se pueden aplicar más allá de los contenedores Docker.

Punto número uno, configuración del host. Aquí hablamos de la configuración que hemos implementado en la parte host de Docker (nuestra máquina). A qué zonas de nuestra máquina puede acceder el contenedor, que permisos y demás.

Punto número dos, configuración de demonio de Docker y sus ficheros. Si ejecutamos el demonio de Docker por nuestra cuenta, hay que tener presente qué configuración le estamos pasando ya que normalmente el demonio se encarga de muchas tareas de gestión sobre los contenedores. Podemos definir si queremos que el contenedor se monte cuando el demonio se despierte con la máquina o incluso indicarle los puertos que queremos que tenga abiertos el contenedor.

Charla RootedCon VLC 2019

Por lo general esto es sensible debido a que normalmente no se apaga la máquina que tiene el demonio en ejecución y por ende, podemos estar ejecutando un demonio con una mala configuración sin darnos cuenta y que prevalezca hasta el infinito.

Información sobre los demonios de Linux aquí.

Punto número tres, configuración de la imagen y del fichero Dockerfile. Esto hace referencia a las directivas que hemos mencionado antes. Algunas de ellas entrañan ciertos riesgos si se usan sin cuidado. Por ejemplo, la directiva USER a la cual le decimos qué usuario debe usar dentro del contenedor. Si por ejemplo, le decimos USER root todo lo que se realice dentro del contenedor será como root y como muchos sabréis eso entraña muchos pero que muchos riesgos.

Tips generales.

  • Evitar en la medida de lo posible el tráfico entre contenedores usando el comando dockerd --icc=false. Si un contenedor se ve comprometido y tiene conexión directa con otros contenedores estos también se verán afectados. La idea es la misma que la del principio de least privilege que se basa en dar los privilegios mínimos necesarios. En el caso del contenedor, las conexiones mínimas necesarias para desempeñar su labor.

Más info sobre el principio mencionado aquí

  • Configurar el archivo Dockerfile con usuarios que no sean root.
  • No usar la directiva ADD, usar en cambio la directiva COPY. La diferencia reside en que, por ejemplo, si yo hago ADD de un archivo local comprimido, cuando se copie al contenedor ADD intentará descomprimir dicho archivo mientras que COPY sólo copiará el archivo. En pocas palabras COPY es una versión de ADD sin tanta automagia.
  • No almacenar secretos en el Dockerfile. Este punto es muy sencillo de entender, cuando se crea un contenedor a través de un Dockerfile todo lo que contenga ese archivo se podrá ver después usando sencillamente el comando history por lo que si tenemos algún secretillo por ahí metido será expuesto con facilidad.
  • Si creamos la variable de entorno DOCKER_CONTENT_TRUST=1 conseguiremos que Docker solo se descargue/use imágenes de las que pueda asegurar su integridad (que la imagen es confiable).

Variables de entorno en Linux, aquí

Más info sobre Docker Content Trust aquí

Sec + DevOps = SecDevOps

En este apartado vamos a tratar primero a qué nos referimos cuando hablamos sobre DevOps.

DevOps no es más que la unión de 2 disciplinas, Desarrollo y Operaciones. Entendemos por Desarrollo las tareas de creación de un producto, por ejemplo, una aplicación web de ventas. Por Operaciones entendemos la parte de Servicios y servidores que alimentarán esa aplicación web de ventas.

Cuando una persona dice ser DevOps se refiere a que es una persona que desempeña tanto tareas de Desarrollo como tareas de Operaciones en un flujo llamado integración continua:

DevOpsImage

Más info sobre integración continua de la mano de amazon.

La idea detrás de SecDevOps (o DevSecOps o DevOpsSec o OpsDevSec ...) es la de añadir la seguridad a esa integración continua de tal forma que sea un engranaje más de la máquina y no algo que pique y luego tengamos que sanar.

SecDevOPs

Más info sobre SecDevOps aquí

Creo que es importante plasmar aquí unas palabras que Elías mencionó en su formación (no son exactas):

"Hay que reeducar a la gente para que entienda que los análisis de seguridad dentro del ciclo de desarrollo es parte del control de calidad"

Hablamos por ejemplo de crear pruebas unitarias que prueben la seguridad de nuestras aplicaciones intentando encontrar y explotar vulnerabilidades, de tener unas buenas prácticas a la hora de programar que faciliten la creación de código reduciendo al mínimo las brechas, de realizar pruebas manuales que pongan a prueba cambios sensibles que hemos hecho en la aplicación. A nivel de Ops, por ejemplo, sería tener un WAF que monitorice entradas y salidas de las peticiones.

La idea final detrás del Sec es la de asegurar el flujo constante de entrega llegando a considerar inaceptable el bloqueo de dichos flujos sin una justificación precisa y necesaria.

Tenemos que entender que los aspectos de seguridad no solo recaen en una o dos personas sino que recae en todas y cada una de las partes que influyan en el desarrollo del producto, sean Ops, Dev, QA, Dirección o incluso Administración.

Segundo día, ponencias.

En esta sección seré un poco más breve ya que cada ponencia era de alrededor de 1h y me llevé más puntos para investigar que cosas a contar.

UAC-A-Mola².

Comencemos con la ponencia de Pablo González (🐦@pablogonzalezpe) quien nos mostró que habían desarrollado una herramienta que detectaba nuevos bypasses de UAC en máquinas Windows usando 2 técnicas: dll hijacking y fileless.

Info sobre dll hijacking.

Info sobre fileless.

Explicó que para realizar un bypass de UAC (User Account Control) se deben cumplir una serie de puntos:

  1. El usuario debe permanecer al grupo de administradores.
  2. El UAC debe estar en la configuración por defecto.
  3. Se debe ejecutar un proceso como administrador (contexto de integridad alto).

El contexto de integridad se refiere al nivel en el que se ejecuta una tarea, si se ejecuta en un nivel alto podemos tomar el control de la máquina de forma muy sencilla.

Sharing Privacy.

Gran charla de Alfonso Muñoz (🐦@mindcrypt) que nos demostró que la criptografía actual tiene bastantes defectos por tema de dificultad y por la dificultad de los testeos.

"La información/clave en algún momento está en claro."

Alfonso nos comentó qué era el cifrado SMC y qué defectos tenía:

  • Requiere de mucha memoria.
  • Tarda tiempo (dependiendo de la velocidad de procesamiento).
  • No tiene soporte para números negativos (de momento).

Info sobre SMC.

Lo que un stalker puede saber de ti.

Junto con Ruth González y Miguel Hernández descubrimos que hay una menestra más que amplia de herramientas para la recopilación de datos personales.

Mostraron una herramienta que habían creado que servía para buscar información de una persona usando una imagen y/o información que ya supieras de ella.

A modo de curiosidad, el buscador Yandex permite subir una imagen y a través de reconocimiento facial mostrarte las personas que más se parezcan a la de la foto. Eso sí, solo gente de Rusia.

Pequeña conclusión.

Los eventos tipo RootedCon, NoConName, SecAdmin, Navaja Negra y muchos otros son eventos en los que se puede aprender muchísimo, conocer gente nueva y ver mundo 😉.

Recomiendo a todas aquellas personas que no han ido todavía a un evento que se lancen a ello y lo prueben, no creo que se queden indiferentes.