[25/02/2022] A mediados del 2017, atacantes rusos patrocinados por el Estado, instalaron un gusano malicioso en un paquete de software financiero ucraniano. Cuando las empresas actualizaron su software, este se infectó. El gusano, NotPetya, se extendió rápidamente, haciendo miles de millones de dólares de daño en todo el mundo. La Casa Blanca lo calificó como "el ciberataque más destructivo y costoso de la historia".
Tres años más tarde, atacantes vinculados a Rusia secuestraron el proceso de actualización de software de otra pieza de software empresarial, el conjunto de herramientas de monitorización de red Orion de SolarWinds. De nuevo, el impacto fue generalizado.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
"Tener acceso a los conductos de desarrollo de software les da la oportunidad de llegar a la infraestructura de red y obtener acceso a la propiedad intelectual", comenta Viktor Gazdag, consultor de seguridad senior de NCC Group, una firma de asesoramiento de ciberseguridad global.
Aumentan los ataques a los pipelines DevOps
Puede ser tentador decir que este tipo de ataques son aislados y que dependen de atacantes muy motivados y hábiles. De hecho, el pipeline de DevOps se ha convertido en un objetivo popular no solo para los actores estatales, sino para las bandas criminales.
Según un estudio publicado el mes pasado por Argon, una empresa de seguridad de Aqua, los ataques a la cadena de suministro de software crecieron más del 300% en comparación con el 2020. Las tácticas comunes incluyen plantar código malicioso en paquetes populares de código abierto o explotar las vulnerabilidades que ya están allí, comprometer las herramientas de pipeline de CI/CD, y aprovechar las credenciales codificadas y otras configuraciones erróneas y problemas de seguridad. El canal de componentes de código abierto fue un objetivo especialmente popular.
Los ataques a la cadena de suministro de software de código abierto aumentaron un 650% el año pasado en comparación con el 2020, según un estudio de Sonatype publicado en septiembre. La superficie de ataque es enorme. Más de 37 millones de componentes y paquetes se encuentran en los cuatro principales ecosistemas de código abierto, según Sonatype. Las descargas de software de código abierto alcanzaron los 2,2 billones el año pasado, un 73% más que en el 2020.
Por qué los pipelines DevOps son vulnerables
Los desarrolladores de software a menudo tienen altos niveles de permiso y privilegios de acceso, señala Gazdag. Si el software que se produce está diseñado para el consumo externo, el impacto puede ser dramáticamente mayor. "Los atacantes también tienen la oportunidad de conseguir un punto de apoyo en la aplicación final", anota.
Por lo tanto, los pipelines DevOps deberían tener niveles más altos de seguridad. En cambio, tienen muchas prácticas de seguridad débiles y una infraestructura y credenciales expuestas. "Si se utiliza Shodan y se busca [la herramienta de desarrollo] 'Jenkins', se puede ver una gran cantidad de infraestructura de Jenkins disponible y accesible en Internet", comenta GazDag.
Con demasiada frecuencia, la infraestructura de CI/CD no recibe el mismo nivel de atención que otras áreas de la empresa, añade Gazdag. Con las prácticas de desarrollo modernas, la situación está empeorando.
"A medida que las organizaciones pasan a DevOps, hay una tendencia a relajar algunos de los controles que tenemos en torno al desarrollo", sostiene Dale Gardner, analista de Gartner. "Queremos ser flexibles y todo el método DevOps es que estamos tratando de sacar el código rápidamente. Los límites y los controles se interponen en el camino".
Tipos de ataques a los pipelines DevOps
Según David Wheeler, director de seguridad de la cadena de suministro de código abierto en la Fundación Linux, los tres tipos de ataques más comunes son la confusión de dependencias, el typosquatting y la inyección de código malicioso.
La confusión de dependencias, también conocida como confusión de espacios de nombres, se produce cuando un atacante averigua los nombres de los paquetes de software empresarial propietario, y crea paquetes de código abierto con los mismos nombres y fechas de lanzamiento posteriores. Algunas herramientas de canalización intentan descargar automáticamente la última versión de un paquete de software y acaban obteniendo la que contiene la carga útil maliciosa.
El typosquatting es cuando un atacante crea un paquete de software de código abierto con un nombre casi idéntico al real, con la esperanza de que un programador cometa un error de escritura y utilice la biblioteca equivocada.
La inyección de código es cuando los atacantes añaden código malicioso a un proyecto legítimo de código abierto. Pueden hacerlo robando las credenciales del mantenedor de un proyecto y subiendo el código en su nombre, ofreciéndose a trabajar en el proyecto ellos mismos, o manipulando las herramientas de desarrollo de código abierto.
Vulnerabilidades en los componentes de código abierto
Luego está el problema de las vulnerabilidades conocidas en los componentes de código abierto, vulnerabilidades que los atacantes no tardan en explotar. En abril, la empresa de pruebas de seguridad de aplicaciones Synopsys revisó el código de más de 1.500 proyectos de software empresarial, tanto internos como comerciales, y descubrió que el 98% de ellos contenía algún código de fuente abierta. Para una aplicación media, el 75% del código base era de código abierto.
Esta es la parte que da miedo: En el análisis de Synopsys, el 84% de las bases de código tenían al menos una vulnerabilidad. Eso es antes de que saliera a la luz la vulnerabilidad Log4J, que los investigadores de seguridad calificaron como el exploit de Java más peligroso en años. Además, el 91% de los componentes de código abierto utilizados no habían recibido ningún mantenimiento en los últimos dos años.
En el 2021 se revelaron más de 28 mil nuevas vulnerabilidades, un récord, según un informe publicado este mes por Risk Based Security de Flashpoint. De ellas, más de cuatro mil eran explotables de forma remota, con un exploit público e información de solución documentada.
La vulnerabilidad Log4j fue especialmente peligrosa, superando a todas las demás en cuanto a impacto, según el informe. La biblioteca se encontró en más de 6.200 productos de software, y el número de avisos de los proveedores sigue aumentando.
Cómo proteger los pipelines de desarrollo de software
¿Qué deberían hacer las empresas para proteger sus procesos de desarrollo de software? Comience con la educación y la formación de los desarrolladores, instituyendo las mejores prácticas, como la autenticación de dos factores y la revisión del código, e instalando herramientas de supervisión para detectar actividades sospechosas.
Comience con los desarrolladores: En el proveedor de servicios gestionados Ensono, David Gochenaur, director senior de ciberseguridad, afirma que tanto los desarrolladores internos como los talleres de software de terceros deben supervisar la seguridad del proceso de desarrollo y despliegue del código. Los dos grupos de desarrolladores deben ser abordados de manera diferente.
Ensono no vende software, pero necesita un software a medida para gestionar sus portales de clientes. La seguridad de estos portales es de suma importancia. "Gestionamos sistemas para muchos clientes, y recogemos datos sobre el estado de esos sistemas y los ponemos en un portal", comenta Gochenaur.
Eso significa que las herramientas de Ensono tienen acceso a los sistemas de esos clientes, lo que convierte a Ensono en un objetivo de alto valor para los atacantes. "Como hay tantos clientes, hay que asegurarse de que el cliente A no pueda acceder a los datos del cliente B", añade Gochenaur.
Es mucho lo que está en juego, sostiene Gochenaur. "Algunos de nuestros clientes son muy sensibles desde el punto de vista de la seguridad nacional y la privacidad", afirma. Así que el primer reto es ser muy estricto a la hora de investigar a los proveedores. "Hay que conocerlos muy bien", señala. "El incidente de SolarWinds es un buen ejemplo y hay muchos otros ejemplos por ahí de terceros que no se aseguraron muy bien, y fueron utilizados como puntos de entrada para los actores de amenazas".
Eso incluye a las empresas externas de desarrollo de software. "Cuando utilizamos a terceros, los investigamos a fondo para asegurarnos de que tienen procesos y controles para garantizar que lo que recibimos de ellos es seguro", anota Gochenaur. Esto incluye la revisión de sus procedimientos de prueba y los controles de seguridad que tienen en su entorno de desarrollo. "Además, incorporamos sanciones por defectos en los contratos", añade.
Luego, para los propios desarrolladores de la empresa, el mayor problema es no utilizar repositorios de código de acceso público "porque cualquier cosa puede estar ahí fuera", indica Gochenaur. "Puede haber código que simplemente parezca impresionante. Probablemente sea impresionante por muchas razones. Hace cosas increíbles para usted, pero permite a los actores de amenazas acceder a lo que sea que tenga en marcha".
Los desarrolladores podrían tomar muchas otras medidas para ayudarles a producir un código más seguro, señala Gochenaur. Una estrategia que ha ayudado a proporcionar tanto formación como motivación en materia de seguridad es la realización de pruebas de penetración por parte de terceros y de equipos internos. "Supone una gran diferencia en la calidad del producto que se desarrolla", afirma.
De hecho, cuando Gochenaur realiza pruebas de penetración en el software de la empresa, los desarrolladores siempre han pedido asistir a las pruebas y ver a los hackers de sombrero blanco hacer su trabajo. "Querían entender lo que estaban haciendo y aprender de las vulnerabilidades que los pen-testers encontraban", señala. "Esto dio a los desarrolladores una forma diferente de pensar. Ahora, cuando traigo a un tercero, éste es uno de mis requisitos: que los equipos técnicos puedan mirar por encima del hombro y ver lo que está pasando y aprender de ellos".
Utilizar herramientas y controles adecuados: Para ayudar a los desarrolladores de la empresa a tomar buenas decisiones, y para ayudar a mantenerlos seguros, Ensono cuenta con varios controles de seguridad. Por ejemplo, la autenticación de múltiples factores ayuda a evitar que personas ajenas accedan al pipeline de DevOps. La empresa utiliza bibliotecas de código privadas para que los desarrolladores puedan elegir entre el código que ya ha sido revisado y aprobado.
Ensono también cuenta con equipos dedicados a la aplicación de parches en los sistemas, para garantizar que todo lo que se despliega es actual y está al día. "Escaneamos regularmente todo nuestro entorno en busca de vulnerabilidades", afirma Gochenaur.
Las empresas pueden hacer otras cosas para ayudar a bloquear su canal de desarrollo que a menudo se pasan por alto, señala Venky Chennapragada, arquitecto de DevOps en Capgemini Americas. Por ejemplo, las empresas deberían tener pipelines separados para el entorno de preparación de no producción y para la producción, y limitar las personas que tienen acceso a ambos sistemas. Para bloquear aún más el acceso, las empresas deberían utilizar sistemas de gestión de acceso de nivel empresarial, como Active Directory o LDAP.
Muchas empresas tienen una base de datos de usuarios separada para los equipos de desarrollo de software, o utilizan herramientas de gestión de usuarios integradas. Es más fácil tener un sistema separado.
"Si estoy integrando con Active Directory o LDAP va a haber una auditoría de seguridad", señala Chennapragada. "Algunos ingenieros podrían querer saltarse la auditoría de seguridad porque no instalaron las cosas correctamente".
El acceso basado en roles es otro control que puede irritar a los desarrolladores. "Siempre es fácil dar acceso total y no tener que crear grupos de usuarios y roles", señala Chennapragada, "pero es una mala práctica".
Por último, Chennapragada recomienda que las organizaciones hagan un seguimiento cuidadoso de todos los componentes que entran en su software, especialmente las bibliotecas de código abierto. "Los desarrolladores tienen tendencia a incluir código de fuente abierta en su software, y éste puede tener errores y vulnerabilidades de seguridad", indica.
Las bibliotecas externas deben someterse a análisis de seguridad y revisiones de código, y los desarrolladores deben limitarse a utilizar únicamente dependencias certificadas. No son solo las bibliotecas las que los desarrolladores pueden querer tomar de Internet. Otras herramientas atractivas son las variantes del sistema operativo y los plugins.
Linux, por ejemplo, viene en millones de sabores diferentes. "Asegúrese de que cualquier versión que utilicen esté reforzada, sea la última y esté actualizada", sostiene Chennapragada. La popular herramienta de desarrollo Jenkins, un servidor de automatización de código abierto, viene con una variedad de plugins. "Hay plugins para todo", señala, "pero los plugins pueden ser realmente vulnerables. La gente puede poner código malicioso en el plugin que puede tomar el control de su sistema".
Hay muchos controles y procesos de seguridad disponibles que no cuestan mucho y no crean demasiados gastos generales, pero que requieren una planificación o formación cuidadosa, comenta Ilia Kolochenko, CEO del proveedor de ciberseguridad ImmuniWeb. Por ejemplo, AWS ofrece controles y herramientas de seguridad integrados que no son caros o incluso gratuitos, anota. "La gente no se decide por ellas porque no es consciente, no cree que las necesite o es demasiado difícil indagar en ellas y aprovecharlas".
La nube facilita el despliegue de herramientas como la supervisión continua de la seguridad y la respuesta a incidentes, anota. "Se puede detectar una actividad sospechosa, detenerla inmediatamente, sustituirla por una imagen limpia y continuar con las operaciones sin desconectarse. La nube ofrece muchas y muy buenas oportunidades para automatizar la monitorización continua de la seguridad y la respuesta a incidentes, pero la gente no las utiliza".
Solicitar SBOMs pero también escanear en busca de vulnerabilidades: Muchos en la industria han estado presionando por una lista de materiales de software (SBOM). El pasado mes de mayo, el presidente Biden emitió una orden ejecutiva por la que se exigían SBOMs a los proveedores que suministran software al gobierno federal. Dos días más tarde, la Cloud Native Computing Foundation publicó un whitepaper de buenas prácticas en el que recomendaba a todos los proveedores proporcionar una SBOM siempre que fuera posible, con enlaces claros y directos a las dependencias.
Un SBOM ayudaría a las empresas a encontrar instancias de componentes vulnerables en su entorno. Por ejemplo, Log4j fue parcheado en diciembre, pero, al 11 de febrero, el 40% de las descargas seguían siendo de la versión vulnerable.
"Si compra una barra de pan, tiene la lista de ingredientes escrita en el lateral", comenta Kayne McGladrey, miembro senior del IEEE y estratega de ciberseguridad en Ascent Solutions, una empresa de consultoría tecnológica. "Tener eso para el software permite a las organizaciones tomar decisiones de riesgo informadas".
McGladrey espera que los proveedores de software con visión de futuro empiecen a incluir estas listas con su software, porque es algo que sus clientes querrán ver. Recomienda que los proveedores de software vayan un paso más allá y proporcionen información sobre cómo se supone que debe actuar su software, y cómo se supone que no debe actuar. "Si los proveedores de software proporcionaran una lista de comportamientos normales de su software, podríamos decir: 'Este software se comporta de forma extraña porque se conecta a servidores que no debería'", afirma.
Independientemente de que el SBOM sea obligatorio, las empresas deberían analizar su software en busca de vulnerabilidades conocidas y otros posibles problemas de seguridad. Todos los principales programas de escaneo buscan ahora paquetes Log4j vulnerables, señala Ray Kelly, miembro de NTT Application Security, un proveedor de ciberseguridad.
Está claro que las empresas no están utilizando las herramientas. "A pesar de que los parches están disponibles desde hace dos meses, las empresas siguen utilizando versiones antiguas de Log4j", afirma Kelly. "Eso habla de lo atrasadas que están muchas organizaciones cuando se trata de asegurar el código".
Basado en el artículo de Maria Korolov (CSO) y editado por CIO Perú
Puede ver también: