Integración continua y entrega continua (CI/CD) pipelineLos s son la base de cualquier organización de software que cree software de una manera "moderna". La automatización proporciona un gran poder, pero la mayoría de los desarrolladores pasan por alto la responsabilidad que implica.
Developer: Sí, tomamos Seguridad en CI/CD seriamente y tener un fuerte control sobre los mantenedores del código, revisar commits antes de fusionarse; empleos y pipelineLos s son mantenidos por personal superior, ellos se encargan de no filtrar Secretos en el pipelines. Y la herramienta fue instalada por personal que conoce el tema. ¿Qué puede ir mal?
Estimado desarrollador, CI/CD Los sistemas son complejos. Su amplia superficie de ataque atrajo a actores maliciosos. Es mejor ser precavido y no confiarse demasiado.
A veces, la configuración predeterminada se mantiene y se convierte en la mejor aliada de los hackers. Pueden presentarse fallas críticas en CI/CD pipeline fuentes, en la configuración del sistema, o en torno al proceso y contexto de la pipeline y cómo se desencadena.
En este post nos pondremos en el lugar de los malos actores. Imaginemos que estuviéramos leyendo las reflexiones de M3M3N70 (¿Memento Mori?) y Furia del pantano en algún lugar de la web oscura, probablemente en un idioma no occidental, pero nunca te pierdas que el mal se extiende por todo el mundo.
En los viejos tiempos era tan fácil...
M3M3N70: Volviendo a los viejos tiempos, nuestro negocio era muuuy fácil... Los días cero eran frutos al alcance de la mano, las aplicaciones estaban muy abiertas con vulnerabilidades fáciles de explotar y podíamos movernos lateralmente en un instante.
Furia del pantano: Fu#@¡Diablos! Todavía hay algunos locos por ahí, pero las cosas cambiaron. Los grandes pusieron mucha atención en esa mierda de AppSec.
M3M3N70Sí. Pero los nuevos locos son los desarrolladores. Para nosotros, ha sido más fácil optar por las herramientas que usan estos chicos. ¡La integración continua, en particular, es una mina de oro! Tokens de acceso a la nube, SCM credenciales, contraseñas de bases de datos de producción, claves privadas SSH, credenciales de otros usuarios de CI... Pasar de las aburridas cosas del desarrollo a la esencia misma fue bastante trivial.
Automatización para crear, probar e implementar software con un CI/CD La herramienta a menudo necesita pasar secretos a los comandos paso a paso. Y a menudo se filtran, con consecuencias infames.
PipelineNecesitamos secretos que a veces se filtran
M3M3N70: The code monkeys slipped their AWS keys in a pipeline on a GitHub commit, later they removed the thing but not changed git history. For our scripts it was trivial to scan the history, grab the key and wreak havoc.
Quizás los buenos viejos tiempos fueron encontrar en la historia de Git una .env archivo (el desarrollador olvidó agregarlo a .gitignore):
AWS_ACCESS_KEY_ID=AKIA...AWS_Secreto_ACCESS_KEY=wJalrXUtn...AWS_REGION=us-east-1APP_FOLDER=...S3BUCKET=...
que se utilizó en un flujo de trabajo de GitHub .github/deploy.yaml que contenía algo como esto:
jobs:
build:
name: Automated build and deployment into AWS
runs-on: ubuntu-22.04
steps:
# Load environment from .env file
- id: dotenv
uses: falti/dotenv-action@v1.0.2
- name: Configure AWS Credentials
uses:
with:
args: --acl public-read --follow-symlinks --delete
aws-access-key-id: $
aws-Secreto-access-key: $
aws-region: $
# ... build steps skipped ...
- name: Upload compiled code for deployment
working-directory: $/packaged_app
run: aws s3 cp my-app.zip s3://$
- name: Deploy the app
run: aws deploy create-deployment ...
M3M3N70: ¡guau! ¡Esas teclas de AWS estaban funcionando! Primero probamos un cambio inocuo en la aplicación, luego agregamos el truco ya que esos tipos parecían no darse cuenta. ¡Bingo! Que campaña....
El atacante simplemente usó las claves de AWS para cargar una aplicación modificada con malware y luego ejecutó el comando de implementación con dichas credenciales. Los Secretos filtrados, junto con la información contenida en el... pipeline. “¡Qué campaña!” Probablemente significa que Memento causó estragos en la pobre víctima.
Lo que Memento nos dice aquí es que una vez que ocurre una fuga de Secreto, como las claves de acceso de AWS en el ejemplo, debes revocar el Secreto (rotar las claves anteriores). inmediatamente. Siempre hay un ventana de exposición entre las fugas commit y la invalidación del Secreto; reescribir la historia de Git es difícil (incluso el estado autoritario más duro intentó reescribir esa historia, sin éxito) y probablemente ineficaz (nuestros amigos podrían haber clonado antes el repositorio con la filtración de Secreto). commit). Gire las teclas inmediatamente y ore mientras lee los registros de actividad de la cuenta objetivo durante el período de exposición.
Probablemente las organizaciones deberían Prohibir el uso de Secretos a largo plazo en CI/CD pipelinesy reemplácelos con credenciales temporales. En el ejemplo anterior con claves de AWS en acciones de GitHub, es más seguro utilizar una Proveedor de OpenID Connect (OIDC) para obtener las credenciales de corta duración necesarias para las acciones.
Furia del pantano: ¡Tuviste mucha suerte! La filtración de scripts con claves codificadas era una práctica común en los viejos tiempos, incluso en depósitos S3 de acceso público. Todo lo que necesitabas hacer era recorrer los objetos en el cubo y buscar un poco para encontrar cosas interesantes.
A veces, el área utilizada para la implementación (un depósito de AWS S3 en este ejemplo) estaba abierta para la lectura de personas externas debido a una falla de configuración (que no se detectó). Qué Furia del pantano utilizado fue algo como esto:
aws s3 ls --recursive s3://<bucket_name>/<path>/ | \
awk '{print $4}' | \
xargs -I FNAME sh -c "echo FNAME; \
aws s3 cp s3://<bucket_name>/FNAME - | \
grep '<regex_pattern>'"
El depósito probablemente se creó en una plantilla de aprovisionamiento que podría escanearse automáticamente en busca de fallas de seguridad.
La configuración predeterminada de la herramienta fue un juguete para nosotros.
Para dar ejemplos concretos hablemos de Jenkins, una de las herramientas de CI más populares.
Furia del pantano: ¿Recuerda la casilla de verificación "Habilitar seguridad" en Jenkins y cuántas organizaciones eligieron no activarla por conveniencia? Y esos "Cualquiera puede hacer cualquier cosa“¿Combinaciones de permisos por defecto? Y esos molestos complementos de Jenkins, como el Complemento GitHub OAuth? El tipo que lo configuró seleccionó "Otorgar permisos de LECTURA a todos los usuarios autenticados" y "Usar permisos del repositorio de GitHub", dándonos acceso a todos sus proyectos.
(Disculpas, Jenkins, por ponerte de ejemplo 😉
Manténgase adepto (incluso adicto) a los principios de seguridad. uno es el Seguro por defecto Principio: los controles deben tener la configuración más segura posible por defecto. La seguridad debe estar integrada. CI/CD herramientas y pipelines desde cero, en lugar de ser una idea de último momento. Pero la facilidad de uso y la conveniencia a menudo chocan con la seguridad.
Para el caso de Jenkins, la autenticación integrada es demasiado frágil: Nunca utilice los mecanismos de autenticación integrados en Jenkins.. Es mejor optar por un mecanismo de terceros (SAML, LDAP, Google…), con el complemento Estrategia de autorización basada en roles (“RBAC”). Y tenga extrema precaución con el admin cuenta.
Cuida el trabajo y pipeline Se manejan los archivos en Jenkins. Lo mismo con Complemento de configuración como código y sus archivos de configuración, que se aplican a la configuración de Jenkins.
Pasando de un sistema autoalojado CI/CD La transición de los sistemas a sistemas SaaS basados en la nube elimina algunos riesgos potenciales que permiten el movimiento lateral dentro de la red de la organización, pero agrega otros, como tener que abrir conexiones externas entre los sistemas internos existentes y los externalizados. CI/CD .
Las organizaciones deben esforzarsecisy el debido cuidado en el endurecimiento de la CI/CD sistema, comenzando con las configuraciones más restrictivas y abriéndose gradualmente con los permisos mínimos requeridos para el pipeline pasos.
Configurar la seguridad en CI/CD Las herramientas pueden ser complejas. Muchas tienen complementos o extensiones con la mayoría de las vulnerabilidades y deben actualizarse.
Los escáneres de configuración incorrecta de seguridad para herramientas tan complejas o los puntos de referencia pueden ayudar.
Inyectando código en pipeline comandos para divertirse y obtener ganancias
M3M3N70: ¿Alguna vez ha utilizado comprobaciones de código que no son de confianza, que acciones y scripts vulnerables son vulnerables a la inyección de comandos?
Esta sección muestra que el pipeline mismo podría tener errores de codificación que permitan a los malos actores inyectar la ejecución de código arbitrario en el pipeline sin cambiar el pipeline fuente misma. Por ejemplo usando un PR
Un primer ejemplo de desafortunado flujo de trabajo de GitHub:
# INSECURE. Provided as an example only.
on:
pull_request_target #1
jobs:
build:
name: Build and test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
with:
ref: $ #2
- uses: actions/setup-node@v1
- run: |
npm install #3
npm build
# ... more steps ...
Combinando pull_request_target El desencadenamiento del flujo de trabajo con un checkout explícito de un PR que no es de confianza es una práctica peligrosa que puede comprometer el repositorio. En el ejemplo, la desafortunada combinación de:
pull_request_targetevento, que por defecto tiene permiso de escritura en el repositorio de destino y en el repositorio de destino Secretos, incluso desde bifurcaciones externas, y se ejecuta en el contexto del repositorio de destino del PR,- consulte el código PR de la fuente, repositorio que no es de confianza,
- activar cualquier script que pueda operar en contenidos controlados por relaciones públicas, como en el caso de
npm instally - no utilizar una condición para el desencadenamiento
pull_request_targetEl evento se ejecutará solo si se asigna algún tipo de etiqueta "este RP fue examinado" al RP (los usuarios externos no pueden asignar etiquetas al RP).
Un segundo ejemplo toma una entrada no confiable (de un problema, comentario o pull request) como fuente de argumentos pasados a un pipeline comando a través de expresiones. Este es el pipeline versión de la vulnerabilidad de inyección de comandos del sistema operativo.
- name: Check title
run: |
title="$"
if [[ ! $title =~ ^.*:\ .*$ ]]; then
echo "Bad issue title"
exit 1
fi
La operación de ejecución genera un script de shell temporal basado en la plantilla, con $ sustituido, haciéndolo vulnerable a la inyección de comandos de shell. Un atacante con una cuenta falsa de GitHub podría crear un problema con un título a"; bad_code_goes_here;#, y bum !
Furia del pantano: Oh, esos tipos estaban abriendo la puerta a la inyección de comandos simplemente abriendo un problema…
Había vulnerabilidades de ejecución de código en las acciones de GitHub, como comentario-gajira, ahora arreglado. Por favor lee "Entradas no confiables en los flujos de trabajo de GitHub" para más detalles.
La moraleja de la historia: Nunca revises ni crees relaciones públicas a partir de fuentes que no sean de confianza sin antes revisarlas. "No confiable" aquí, a menos que esté bajo una autenticación draconiana de procedencia, podría significar cualquier cuenta de desarrollador potencialmente secuestrada.
¡Implementación de malware no intencionada aquí!
Despliegue continuo es el clímax de la automatización, pero ese clímax podría verse frustrado por la falta de controles de aprobación adecuados en el pipeline flujo.
Los riesgos de una implementación totalmente automatizada desde el origen commit a los sistemas de producción incluyen la posibilidad de que se implemente código malicioso en entornos de producción sin ser detectado, así como la posibilidad de que errores en el proceso de implementación causen interrupciones o interrupciones.
Para mitigar estos riesgos, a menudo se recomienda que las organizaciones implementen una “ruptura total” en su proceso de implementación, lo que requiere aprobación humana antes de que los lanzamientos se implementen en los entornos finales.
estan cerrando las puertas
Furia del pantano:Esas alegres contraseñas predeterminadas en CI/CD Se están limpiando las herramientas. Accediendo a la
/var/lib/jenkins/Secretos/initialAdminPasswordAhora es una pista muerta. Muchas herramientas ahora proporcionan 2FA, que Covid hizo popular, ¡e incluso el mono codificador más vago que existe lo está usando!M3M3N70: Estamos luchando contra 2FA, pero no es tan fácil. Es difícil hacer phishing a esos tipos, ya que “Scatter Swine” lo hizo con Twilio. Con las claves de WebAuthn es mucho más difícil. Al menos podemos intentar robar cookies para evitar MFA, pero es necesario ingresar a la caja del desarrollador.
La autenticación multifactor es un buen paso en la dirección correcta para limitar el riesgo de fugas de información secreta de autenticación. La mayoría de las herramientas modernas de DevOps admiten MFA. Y las claves de autenticación bajo WebAuthn/U2F (ver proyecto FIDO2) son quizás la mejor opción para MFA en DevOps, si se administran adecuadamente.
Furia del pantano: Los chicos de DevOps se están despertando. Tienen el maldito “privilegio mínimo” en la sangre. Y ya no son monos codificados. Ahora los críticos nos pillan con las manos en la masa.
De hecho, pipelines son ahora un poco más robustos que hace un par de años, con acciones y scripts débiles eliminados, y con pasos de prueba de seguridad adicionales que incluso detectaron nuestros droppers ocultos de forma sigilosa. commits y paquetes que secuestramos.
Pregunta para el lector: ¿es el proceso de crear software a partir de fuentes e implementarlo en producción un negocio arriesgado? ¿Puedes ver tu DevOps en la etapa de viejos buenos tiempos ¿para los malos?
Recomendaciones finales
Por donde empezar CI/CD pipeline¿s?
La primera recomendación aquí es simple: con cuidado una estrategia SEO para aparecer en las búsquedas de Google. pipelines (ellos son crítico recursos) para cuestiones de seguridad. Las revisiones son costosas pero necesarias y deben realizarse correctamente. Los revisores deben saber qué mirar. Cada paso debe ser revisado para detectar fallas.
Quizás una combinación de revisores expertos armados con escáneres automatizados de códigos maliciosos podría ayudar.
La segunda recomendación es formar desarrolladores que escriban pipelines y mantenerlos en seguridad. Cosas para considerar:
- Cómo manejar adecuadamente la autenticación con servicios internos y en la nube, evitando la molestia de manejar credenciales a largo plazo.
- como limitar pipelines al conjunto exacto de recursos a los que necesita acceso. El principio de privilegio mínimo vuelve a brillar.
- Cómo escribir los pasos para hacer. pipelineEs reproducible, como fijar versiones y evitar vulnerabilidades de inyección de comandos.
- Cómo aprobar implementaciones desde la perspectiva de seguridad (¡son otras!): qué seguridad standards deben coincidir y cómo agregar controles/puertas correspondientes en el pipelines.
Una tercera recomendación es configurar el CI/CD sistema con el debido cuidado. Autenticación sólida, sin contraseñas predeterminadas ni configuraciones inseguras, privilegios mínimos… Ocúpese de las vulnerabilidades en los complementos y extensiones instalados. Este podría ser el tema central de las siguientes publicaciones, estad atentos.
La cuarta recomendación es aprovechar el CI/CD pipelines para automatización de seguridadAnálisis del código fuente (SAST), análisis de la composición de las fuentes (SCA), el análisis de fugas de Secretos, las herramientas antimalware, los escáneres de seguridad de contenedores o los detectores de tiempo de ejecución automatizados (DAST y malware) se pueden ejecutar de forma rutinaria en el pipeline. Y su organización puede hacer cumplir standardSe trata de la cobertura del escaneo de seguridad en CI/CD.
Recuerde que estas herramientas aún no eliminan la revisión de expertos de la ecuación; de lo contrario, podría tener una falsa sensación de seguridad.
Si eres experto en los diez primeros de OWASP, un buen proyecto reciente es el OWASP Top 10 Seguridad en CI/CD Supervisión.
Nota de descargo de responsabilidad
(1) Los ejemplos en esta publicación utilizan GitHub como SCM, AWS como proveedor de nube y GitHub Actions o Jenkins como CI/CD Herramienta. No son más débiles ni más seguras que sus alternativas. ¡Sin malas intenciones! Estas herramientas son poderosas y deben usarse adecuadamente.
(2) M3M3N70 y Furia del pantano son personajes ficticios. Cualquier parecido con personas o grupos, vivos o muertos, es mera coincidencia… ¿o no?
Leer más
- Haymore, A. y col. “10 historias del mundo real sobre cómo hemos comprometido CI/CD pipelines ”. Grupo NCC, enero de 2022.
configure-aws-credentialsAcción de GitHub y Configuración de OpenID Connect en Amazon Web Services para obtener detalles sobre cómo ejecutar comandos de AWS para su implementación en flujos de trabajo de GitHub.- Lobačevski J. "Mantener seguros sus acciones y flujos de trabajo de GitHub, Parte 1: Prevención de solicitudes pwn". Laboratorio de seguridad de GitLab, diciembre de 2020.
- Lobačevski J. "Mantener seguros sus acciones y flujos de trabajo de GitHub, Parte 2: Entradas que no son de confianza". Laboratorio de seguridad de GitLab, enero de 2021.
- OWASP. “OWASP Top 10 Seguridad en CI/CD “Riesgos”. julio de 2022.
- Saltzer J. y Schroeder M. “La Protección de la Información en los Sistemas Informáticos”. Abril de 1975. Los principios de seguridad evolucionaron con la tecnología, pero 47 años después la mayoría de las ideas de S&S siguen vigentes.
- NCSC del Reino Unido. “Asegurar la construcción y la implementación pipeline". Centro Nacional de Ciberseguridad del Reino Unido, febrero de 2019.
