Cuando hablamos de ataques a la cadena de suministro no hablamos de un tipo de ataque específico sino más bien de una estrategia de ataque. En los últimos tiempos hemos visto gravísimos ejemplos a nivel mundial como el de Solarwinds o Log4Shell, que han puesto en jaque a medio mundo... Vamos a ver cómo funcionan este tipo de ataques, porque tienen tal magnitud y porque es una prioridad el cambio de modelo para intentar prevenirlos.

Ataque a la cadena de suministros Supply Chain Attack

Por qué se da el ataque a la cadena de suministros?

Puede que no fuera en vuestra primera clase de programación, pero seguro que no tardaron mucho en deciros que "no hay que reinventar la rueda".. Esto es básico en informática, diría que en cualquier ingeniería, pero paradójicamente es la fuente de los ataques en la cadena de suministros.

Imaginemos cualquier software como un puzzle de componentes, funciones, etc.. en el que sí tiene una mínima complejidad se van a utilizar partes previamente programadas por otros. En muchos casos no se puede o no se dedica el tiempo suficiente para verificar el código de estos componentes externos o directamente se dan por buenos y se integran sin más. Según diferentes reportes, por ejemplo este de Synopsis, la práctica totalidad del software comercial contiene partes de código abierto, programado por terceros.

Si un atacante consigue colar o detectar en este código alguna puerta trasera o vulnerabilidad, estaremos incluyendo la misma directamente en nuestra solución final. El tema es que estos componentes pueden ser usados en miles de aplicaciones diferentes y que estás pueden contener a su vez cientos de funcionalidades o dependencias de terceros, por lo que cualquier vulnerabilidad en un componente ampliamente utilizado por otros se convierta en un enorme problema afectando multitud de software y sistemas que por lo general jamás será completamente parcheado.

Al final tenemos que entender el ataque a la cadena de suministros como dos ataques sucesivos. El primero contra este componente inicial y posteriormente cuando esté es incorporado en una solución más compleja a este último software. Por lo general y hasta ahora este código inicial está sujeto a muchos menos controles, siendo para los atacantes mucho más fácil de modificar. Como hemos visto en algunos de estos ataques resultaba al final que este código era mantenido por programadores a modo de hobby, obviamente sin recibir ningún tipo de compensación aunque su trabajo fuera pieza importante en productos que generan cientos de millones..

Esto está forzando a las empresas a adoptar el modelo de desarrollo devsecops, en el que al desarrollo y puesta en producción continua se une el trabajo conjunto con los equipos de seguridad para tratar de asegurar que el código no contiene vulnerabilidades, ya sean las propias que pueden aparecer durante el desarrollo como las que pueden esta presente en esas dependencias de terceros.

Un problema para el software comercial y de código abierto

Tradicionalmente alterar un software final significaba recompilar la versión final del mismo, incluyendo fragmentos de código malicioso y sustituyendo la versión publicada del mismo en webs o similares. Esto dio paso a la generalización de la comprobación de los mismos a través de hash, lo que complicaba el proceso.

Hoy en día, con la modularidad del software y la generalización de repositorios y software open-source, hace que estos cambios sean mucho más difíciles de identificar. Aunque haya un control de cambios y revisiones, que no pasa siempre, es muy difícil evitar que se cuelen bugs y como decíamos casi todo el software existente tiene componentes de terceros que a su vez, en su gran mayoría no se auditan exhaustivamente.

Un problema también de hardware

La cadena de suministros no es sólo de software sino también de componentes y aquí entran los ataques producidos en nuestra red a través de vulnerabilidades introducidas en productos de terceros o directamente por funcionalidades deliberadamente ocultas en los propios firmwares.

¿Quién no recuerda la polémica latente de los switches Huawei? En algunos países y sistemas se ha optado por prohibir la presencia de hardware de empresas chinas por el riesgo de puertas traseras.. aquí tendríamos un posible ataque de ataque a la cadena de suministros por un actor que tiene detrás un país.

Tipos de ataques de cadena de suministros

Como hemos visto no hablamos de un único tipo de ataque sino más bien de una categoría en el que todos ellos implican aprovechar una vulnerabilidad en una solución posteriormente usada por otros. De todas maneras en cuatro grandes grupos.

  • Software comprometido - Ya sea el propio código de un componente del software o incluso las herramientas usadas para escribirlo o compilarlo.
  • Hardware comprometido - A través de código insertado en el firmware de los dispositivos los atacantes pueden disponer de puertas traseras, controles de apagado o terminales contra la red en la que están instalados estos dispositivos.
  • Malware preinstalado - En estos casos el atacante es capaz de instalar malware en dispositivos con destino a su objetivo. Hablamos de ordenadores, dispositivos USB... Que más tarde le permitirán un acceso a esas redes internas o a información sensible.
  • Certificados robados - Otro ejemplo bastante habitual estos últimos años. En el caso que un atacante pueda robar un certificado usado por una empresa para firmar su software o identidad puede luego utilizarlo en este tipo de ataques.

Como evitar este tipo de ataques

Como vemos es un problema muy difícil de atajar completamente. A nivel de hardware no queda mucho más remedio que confiar en empresas que al menos demuestren un buen ciclo de actualizaciones de sus productos y que tengan una buena reputación en este sentido ya que de esa manera podemos relativamente "confiar" que internamente dispondrán de los controles y prácticas adecuadas para minimizar riesgos..

A nivel de software, aquí tenemos un par de áreas esenciales, una es controlar y reducir el software que se puede ejecutar en nuestra empresa. De esta manera estaremos reduciendo los vectores de ataque y potencialmente también la superficie de ataque. al igual que con el hardware también es importante "confiar" únicamente en desarrolladores con una postura en ciberseguridad contrastada, si dependemos de un software el cual es pobremente mantenido y que no presta atención a tendencias tan básicas como el MFA o el SSO mejor planificar una alternativa.

La otra área en cuestión de software vendría en relación a la protección de los dispositivos en sí para poder bloquear o minimizar cualquier ataque. Hablamos tanto de disponer de antivirus y sistemas EDR en clientes, de mantener una política activa de actualización de software o básicamente una postura global en términos de seguridad que dificulte al máximo los movimientos posteriores al ataque y que nos permita su detección.