Autor
Una guía para ser consciente de los riesgos a los que se expone y algunos consejos para protegerse de ellos.
Recientemente ha salido a la luz un nuevo tipo de ciberamenaza: los ataques a la cadena de suministro de software. Aunque son poco frecuentes, tienen un impacto masivo y protegerse contra ellos es una preocupación creciente. Debido a su variedad de casos de uso, no existe una única regla que aplicar a sus proyectos python para estar seguro y, como siempre, depende de su contexto.
Introducción
En las industrias tradicionales, una cadena de suministro es todo aquello que permite a una empresa entregar un producto al cliente. Por ejemplo, cuando usted compra un cruasán en la panadería, todos los ingredientes, el envasado y el transporte forman parte de la cadena de suministro.
En el ámbito del software, una cadena de suministro es cualquier cosa que afecte a su software antes de su despliegue en producción. Abarca todo, desde la fase de desarrollo hasta el proceso de lanzamiento, incluido el código que usted escribió, sus dependencias, su entorno de compilación, su IDE, su registro de imágenes... ¡todos los componentes con los que interactúa su software en cualquier momento!
El término “cadena de suministro” ha salido a la luz recientemente debido a ciberataques que tuvieron un amplio impacto. Entre todos los ataques, el de Solarwinds puede que sea el más famoso. De hecho, se han visto afectados el gobierno estadounidense, grandes empresas tecnológicas como Microsoft e Intel, pero también hospitales, compañías eléctricas e instituciones financieras.
Irónicamente, la causa raíz es la infección de Solarwinds Orion, un monitor de seguridad de red. El sistema de compilación había sido comprometido y todas las nuevas versiones entre marzo y junio de 2020 fueron infectadas por malware. El resultado es que todos los clientes que actualizaron su software durante ese periodo se vieron comprometidos.
Aunque el ataque de Solarwinds ha sido ampliamente cubierto por los medios de comunicación, existen docenas de ataques similares de los que nunca hemos oído hablar. Afortunadamente, la Cloud Native Computing Foundation hace un seguimiento de todos ellos en un depósito público. Puede que le sorprenda la aceleración de estos ataques en los últimos años.
Abarcar todo lo relacionado con la seguridad de la cadena de suministro no es factible en una sola entrada de blog, por lo que en este artículo nos centraremos especialmente en los proyectos que utilizan Python como lenguaje principal.
Cómo gestionar sus dependencias en Python
Aunque Python tiene una filosofía de “pilas incluidas”, a menudo necesita bibliotecas externas que puede descargar de PyPI, el índice oficial de paquetes, y es en este punto donde debe tener mucho cuidado.
El ecosistema Python ya ha sido objeto de ataques, en particular mediante el uso de dos técnicas:
La primera técnica afecta a un comando que todo desarrollador de Python ha ejecutado al menos una vez a lo largo de su carrera:
pip install
Los piratas informáticos publican paquetes casi con el mismo nombre que los paquetes existentes con la esperanza de que usted cometa un error tipográfico e instale su paquete en lugar del paquete oficial. Por ejemplo, un paquete llamado python3-dateutil en lugar del oficial dateutil ha sido detectado recientemente.
La comunidad python es trabajando duro para mitigar el riesgo, pero éste sigue siendo elevado.
La segunda técnica, la confusión de dependencia, es más sofisticada que la primera y tiene que ver con cómo pip funciona bajo el capó.
Esta vez, este comando le expone al riesgo:
pip install --extra-index-url
Cuando escriba este comando, esto es lo que ocurre:
Pongamos un ejemplo:
En este ejemplo, el paquete del hacker malicioso se instalará en la máquina. De hecho, el número de versión más alto se encuentra en el índice público de paquetes.
Es posible que haya comprendido lo que puede salir mal en este proceso. Alguien con malas intenciones puede publicar paquetes en un repositorio público que tengan los mismos nombres que los alojados en los índices de paquetes internos y etiquetarlos con un número de versión ridículamente alto. Además, encontrar nombres de paquetes relevantes no es tan difícil como demostrado por este investigador de seguridad.
Este comando podría calificarse como “inseguro por diseño”. Este ataque aprovecha una característica del gestor de paquetes de Python y sólo unos pocos desarrolladores son conscientes de este comportamiento.
Cómo defenderse de estos ataques a la cadena de suministro
Para defenderse de los ataques de typo-squatting, puede utilizar un archivo de bloqueo. A buen archivo de bloqueo tiene los siguientes atributos:
La buena noticia es que existe un paquete cuyo propósito es crear un archivo de bloqueo para usted: pip-tools. Con sólo unos pocos comandos, puede generar un archivo de bloqueo con todos los atributos que hemos descrito anteriormente.
$ python3 -m venv mi-env # crear un nuevo entorno virtual $ source my-env/bin/activate # actívelo $ pip install pip-tools==6.3.0 # instale el paquete que le permitirá gestionar correctamente sus dependencias $ echo “sacremoses==0.0.46” >> requirements.in # añada el paquete de su elección en requirements.in $ pip-compile --generate-hashes # compila requirements.txt con hashes basándose en lo que ponga en requirements.in
Su archivo requirements.txt debería tener este aspecto:
Ahora que tiene este archivo que contiene todas sus dependencias con sus versiones y hashes asociados, puede ejecutar el siguiente comando la próxima vez que despliegue:
pip install --require-hashes -r requisitos.txt
Así, estará seguro de que los paquetes que utiliza en producción no han sido alterados. Suponiendo que haya tenido cuidado al escribir su requisitos.en archivo 👀, también puede estar seguro de que descargará el paquete que realmente desea, ya que todo está automatizado. ¡Sin riesgo de error tipográfico!
Esta práctica recomendada es buena para defenderse de los ataques de "typo-squatting", pero ¿qué ocurre con la confusión de dependencias?
Si se fija en el pip verá que hay dos opciones que puede utilizar para descargar paquetes de un repositorio interno:
La documentación dice:
Como puede ver, hay una ligera diferencia entre ambos y no es evidente a primera vista. La diferencia es que si especifica el --index-url opción, pip sólo extraería paquetes del repositorio con la URL que usted proporcionó, y no de repositorios públicos. Así que, si quiere evitar el comportamiento que hemos descrito antes, utilice --index-url en lugar de --extra-index-url ¡y estará a salvo!
Por último, para seguir las últimas vulnerabilidades que se descubran en sus dependencias, puede optar por comprobar periódicamente el archivo GitHub asesor database o mejor, aproveche herramientas como dependabot que enviará automáticamente un pull request en su repo para actualizar una dependencia en la que se haya identificado recientemente una vulnerabilidad crítica.
Resumen
En este artículo, introdujimos el concepto de cadena de suministro para el mundo del software. En concreto, hemos estudiado cómo se aplica este concepto al ecosistema Python. Se han explicado el typo-squatting y la confusión de dependencias y se han propuesto soluciones para mitigar el riesgo de verse comprometido.
Esta rápida introducción a la seguridad de la cadena de suministro sólo ha cubierto la punta del iceberg, no hemos tenido la oportunidad de hablar de cómo construir sistemas o incluso su IDEs puede verse comprometida, ¡pero eso lo dejo para otro artículo!
Gracias por leer hasta aquí. Estaré encantada de escuchar sus comentarios. Si le ha gustado la lectura, no dude en consultar nuestro puestos vacantes en Artefact 🙂 .
