Ataques de cadena de suministro: Cuando los malos atacan por la espalda

Los componentes de software hacen que nuestra vida sea más sencilla. Gracias a ellos, las empresas y las personas pueden realizar miles de acciones que eran inimaginables en el mundo analógico. Desde emplear una solución para comercializar los productos de una compañía, hasta una aplicación para que una persona pueda controlar sus cuentas. Los componentes software se han convertido en activos críticos de las compañías y en uno de los elementos más expuestos a las acciones maliciosas. Así lo demuestra el auge de los ataques de cadena de suministro y su impacto en compañías del calibre de Microsoft o IBM.

A finales de 2020, salió a la luz un ataque de cadena de suministro que tuvo una repercusión global: Solorigate. Este ciberataque afectó a la empresa tecnológica SolarWinds. Quizás este nombre no le diga nada a un profano en el mundo digital. Pero SolarWinds suministra software empresarial a compañías y administraciones públicas de todo el planeta. A la ya mentada Microsoft podemos añadir Intel, Orange, la agencia que controla el arsenal nuclear de Estados Unidos (NNSA), la NASA o el Parlamento Europeo.

Los agresores introdujeron malware en el servidor que empleaba la compañía para crear las actualizaciones de software de Orion, una de sus plataformas. Así, cada vez que una empresa que empleaba Orion actualizaba el software, permitía que el troyano se colase en su sistema. De tal forma que los atacantes pudieron robar información de más de 18.000 empresas en todo el mundo y, en especial, de algunas de las compañías y administraciones públicas más importantes del planeta.

Este incidente de seguridad es el ejemplo perfecto de la gravedad y el alcance que pueden alcanzar los ataques de cadena de suministro exitosos poniendo en jaque los datos de las organizaciones y sus clientes.

1. ¿Qué son los ataques de cadena de suministro?

Antes de nada, debemos responder a la pregunta más obvia: ¿En qué consisten exactamente los ataques de cadena de suministro del software?

1.1. Atacar vulnerabilidades de librerías

Cuando vemos y empleamos una solución sabemos que es el resultado del trabajo y el talento de sus desarrolladores.

Sin embargo, hoy en día, prácticamente ningún software se escribe partiendo de cero. Es decir, los profesionales no tienen que picar la totalidad del código que sustenta un software, sino que recurren a componentes de código abierto ya desarrollados que se encuentran en librerías y repositorios. De tal forma que, si un ciberdelincuente ataca a uno de estos componentes, puede impactar en todo el software que los emplea.

INFO1 – Dentro de la cadena de suministro de un desarrollo propio se cubre la necesidad de incluir una librería o paquete de software que, en caso de no estar instalado, el sistema lo descarga desde su repositorio de software correspondiente. Cualquier sistema como Windows, Android, GNU/Linux… tiene sus propios repositorios para librerías y software. Una vez localizado el paquete y la versión requerida, este se instala en el sistema y el desarrollo propio ejecuta las funciones que incluye de dicho paquete.

1.1.1. Log4Shell, un ejemplo paradigmático

Esto es, precisamente, lo que sucedió con uno de los ataques de cadena de suministro más relevantes de la última década: Log4Shell. Vulnerabilidades detectadas en el componente Log4j, ampliamente utilizado en aplicaciones Java para una tarea tan cotidiana como la gestión de mensajes de log, permitían que ciberatacantes pudieran comprometer totalmente la seguridad de las aplicaciones que hacían uso de este componente.

De hecho, es tan común su uso que hasta el helicóptero Ingenuity de la NASA emplea Log4j. Pero también aplicaciones como IBM Qradar SIEM o NetApp.

INFO2 – En este ejemplo la cadena de suministro es alterada en el propio repositorio de software. El atacante consigue los permisos para poder alterar el paquete e insertar código malicioso, el cual se instalará en cada sistema que lo requiera para hacer funcionar el software desarrollado. Al ejecutar dicho código malicioso en el sistema este se verá comprometido por el atacante.

1.2. Atacar un software para impactar en las empresas que lo usan

Asimismo, los ataques de cadena de suministro también pueden consistir en vulnerar un producto de software, como en el caso de SolarWinds, como un primer paso para colarse en las empresas que lo emplean.

De esta manera, una compañía puede verse atacada a través de uno de sus proveedores de software. Pensemos, por ejemplo, en los proveedores de identidad externos.

Los casos de Solorigate y Log4Shell nos permiten observar una realidad ineludible: una de las consecuencias de la digitalización es el aumento de la cadena de suministro tecnológica de una empresa. Y, así como la cadena de suministro es un activo, también conlleva riesgos. De nada sirve que una empresa securice sus sistemas y redes, si uno de sus proveedores es vulnerable.

2. ¿Quién se ve involucrado en los ataques de cadena de suministro?

A través del contexto que venimos de relatar podemos vislumbrar la inmensa amplitud de las cadenas de suministro, pero también de las posibilidades de ataque, así como de las compañías e instituciones que pueden ser el objetivo de esta clase de agresiones.

Las empresas que desarrollan software propio pueden sufrir un ataque de cadena de suministro explotando una vulnerabilidad presente en el código. Y, a su vez, si se logra atacar con éxito este software y dicha solución se comercializa a terceros, también se puede atacar a las empresas que lo emplean.

Podríamos decir que la cadena de suministro funciona, casi, como una tela de araña, interconectando compañías que a priori no tienen por qué estar relacionadas.

Por ejemplo, si usamos una app de una entidad bancaria para gestionar nuestros ahorros e inversiones, tendemos a pensar que el banco desarrolló dicha aplicación. Sin embargo, puede ser que alguna de las herramientas que se emplean para sustentarla sea provista por una compañía de desarrollo independiente.

El salto al Cloud y la comercialización masiva de los Software as a Service (SaaS) han provocado que la tela de araña sea cada vez más amplia y opaca. Desarrolladores, compañías, instituciones públicas y ciudadanos debemos tomarnos la ciberdefensa de la cadena de suministros muy en serio. De lo contrario, las consecuencias económicas, legales y sociales pueden ser devastadoras.

3. Ataques dirigidos y no dirigidos: recoger percebes y hacer pesca de arrastre

Cuando hablamos de ciberataques debemos tener en cuenta, claro está, los objetivos de los delincuentes que los diseñan, planifican y ejecutan. O, dicho de otra forma: a quién van dirigidos.

En función de esto, podemos hablar de ataques dirigidos y no dirigidos. Si un actor malicioso emplea el phishing para lograr los datos bancarios del mayor número de personas, está claro que su objetivo es hacer pesca de arrastre. Todas las víctimas que caigan en su red son válidas.

En cambio, si emplea otras técnicas de Ingeniería Social para realizar lo que se denomina fraude del CEO, nos encontramos ante un ataque dirigido. No le vale cualquier fruto del mar, el ciberdelincuente quiere capturar un percebe en concreto.

Si saltamos al terreno de los ataques de cadena de suministro, podemos encontrarnos con ataques dirigidos y con ataques que, a priori, no lo están. Pero también podemos detectar que la frontera entre unos y otros se vuelve líquida en esta tela de araña que es la cadena de suministro digital.

Un grupo de cibercriminales puede encontrar un componente de código abierto que presenta vulnerabilidades, lanzar un malware y colarse en todos los software que emplean este elemento en su código. ¿Esto sería un ataque no dirigido? ¿Y si aprovechan la brecha de seguridad para atacar a una serie de empresas en concreto? ¿Se transformaría en un ataque dirigido?

Los ataques de cadena de suministro son un fiel reflejo de la creciente complejidad de dicha cadena.

¿Quiere decir esto que los desarrolladores, las compañías que contratan software y los usuarios están atrapados en la tela a merced de las arañas? En absoluto. Securizar todo el ciclo de vida del software y auditar las soluciones de terceros son servicios de ciberseguridad de gran valor añadido para combatir los ataques de cadena de suministro.

4. Integrarse en el ciclo de vida del software para securizarlo

Todos los componentes del software que empleamos tienen un ciclo de vida. Que va desde que surge la idea hasta que el software está en pleno funcionamiento, y es necesario realizar las pertinentes tareas de mantenimiento y actualización para protegerlo frente a los ataques y optimizarlo.

Por ello, la mejor forma de proteger un software es contar con un servicio de análisis y detección de vulnerabilidades continuo a lo largo de todas sus fases.

A menudo, las compañías contratan una auditoría para analizar el nivel de seguridad de un software cuando ya se ha desarrollado y lanzado al mercado. Esta medida es de gran utilidad para detectar vulnerabilidades, evaluar los riesgos y proponer medidas para subsanar las debilidades. Pero llega demasiado tarde.

Además, teniendo en cuenta que el software se actualiza periódicamente, también resulta pertinente evaluar cada actualización antes de generar su nueva release. Como nos ha demostrado Solorigate, la actualización de una solución puede ser la puerta de entrada perfecta para atacar a las empresas que la tienen integrada en sus sistemas.

De ahí que la mejor opción sea contar con un servicio de ciberseguridad que se integre en el ciclo de vida del software. Esta clase de servicio puede analizar el software desde el propio desarrollo, chequeando las librerías empleadas en busca de vulnerabilidades, así como debilidades en el código fuente.

Actualmente, los profesionales de Tarlogic Security están diseñando este servicio para ayudar a las compañías a proteger su software a lo largo de todo su ciclo de vida. Combinando herramientas tecnológicas de vanguardia con los profundos conocimientos en materia de ciberseguridad acumulados por los profesionales de Tarlogic a lo largo de los años.

A continuación, vamos a abordar las claves de este servicio para integrarse en el ciclo de vida del software y securizarlo en su totalidad.

4.1. Automatizar la búsqueda de vulnerabilidades

En el proceso de integrarse en el ciclo de vida de un software puede resultar de enorme utilidad contar con una solución que se pueda integrar en los repositorios de código, así como en los procesos de integración continua del software (CI/CD). El objetivo de esta herramienta es encontrar vulnerabilidades que afecten al software en su etapa de desarrollo, antes de que la nueva versión de la aplicación sea publicada y puedan ser explotadas por los ciberdelincuentes.

De esta forma, se puede proceder a realizar en el ciclo de vida de un software un análisis de las dependencias de la aplicación con respecto a librerías de todo tipo.

Además, es posible buscar automáticamente vulnerabilidades en las diferentes versiones de un componente o de un software, visualizarlas en un panel de control y contribuir a que no lleguen a estar presentes en el producto final que se lanza al mercado.

El objetivo del servicio es realizar un análisis de las dependencias de una aplicación y evitar que vean la luz actualizaciones que generen una brecha de seguridad en el software y en las empresas y usuarios que lo emplean.

4.2. SBOM, una cartografía de los elementos de un software

El Software Bill of Materials (SBOM) es, como su propio nombre deja entrever, un inventario de los elementos con los que se han desarrollado los componentes del software.

Este inventario incluye las librerías empleadas, las versiones y las vulnerabilidades.

Como señalábamos antes, la cadena de suministro de software no solo es cada vez más amplia, sino también más opaca. Contar con un SBOM permite arrojar transparencia sobre los componentes de terceros empleados para desarrollar un software.

Lo cual es de gran interés tanto para la empresa que lo desarrolla de cara a analizar todos los componentes en busca de vulnerabilidades, como para las compañías que adquieren la solución, que pueden evaluar su seguridad.

En este sentido, los SBOMs se han convertido en un recurso de gran valor para llevar un control exhaustivo y preciso de la cadena de suministro de un software, contribuyendo a protegerlo y mitigar vulnerabilidades a lo largo de todo su ciclo de vida.

Por ello, una solución que se integre en todo el ciclo de vida de un software y automatice la búsqueda de vulnerabilidades debe contar, también, con un SBOM automatizado. De cara a testear todo el código tanto del software como de los elementos de terceros empleados.

4.3. SCA y SAST. Analizar las librerías y el código fuente

El SBOM nos ayuda a saber con precisión cuáles son los elementos de terceros que se emplean en un software. Pero, ¿cómo analizamos la solución para detectar vulnerabilidades?

Aquí entran en juego dos tipos de análisis:

• Software Composition Analysis (SCA)
• Software Application Security Testing (SAST)

El SAST es un tipo de análisis especialmente útil durante el desarrollo del software, es decir, antes de que este vea la luz, puesto que estas pruebas de seguridad analizan el código fuente del software de cara a detectar vulnerabilidades nuevas. De ahí que podamos sostener que el SAST es embrionario y de gran valor añadido para realizar desarrollos seguros.

Mientras que el SCA se emplea para identificar los componentes de código abierto empleados en un software y detectar vulnerabilidades en ellos que pudieran afectar a su seguridad. Así como el SAST es embrionario, el SCA se pone en marcha para analizar las vulnerabilidades conocidas en software de terceros ya desarrollado que se integra en nuestro código.

Debemos destacar, también, que el SCA apenas da falsos positivos, puesto que trabaja con vulnerabilidades que ya existen. Ello implica que su implementación es más sencilla, ya que las alertas de seguridad que se generan son en su mayoría certeras.

¿Cuál de los dos tipos de testeo es mejor para securizar un software? En un escenario óptimo la mejor solución sería implementar ambas herramientas. Ya que el SCA permite controlar las librerías y repositorios de software y el SAST sirve para controlar el código fuente. De tal forma que su uso combinado contribuye a fortalecer la seguridad de un software a lo largo de su ciclo de vida.

4.4. Servicio de asesoramiento integral

Un servicio de ciberseguridad que se integre en todo el ciclo de vida de un software para automatizar la detección de vulnerabilidades en su código fuente y controlar las librerías y repositorios a los que recurre la aplicación requiere, también, contar con un asesoramiento integral.

En este sentido, el equipo de Tarlogic planea emplear las herramientas que mejor se adapten a cada caso y, además, ofrecer un asesoramiento continuo. Las soluciones que automatizan la búsqueda de vulnerabilidades pueden generar falsos positivos.

Por ejemplo, en un código de gran envergadura se pueden detectar 200 vulnerabilidades, pero, en realidad, solo 50 de ellas son debilidades reales que se deben subsanar. Si se cuenta con la experiencia y los conocimientos de profesionales experimentados en este ámbito, no se llevará a cabo una gestión de los recursos deficiente, intentando subsanar problemas inexistentes o irrelevantes.

A la hora de securizar la cadena de suministro del software y prevenir ataques de cadena de suministro no basta con tener la capacidad de detectar deficiencias, sino que también hay que subsanarlas. Por ejemplo, implementando versiones nuevas de un elemento de código abierto. O liberando un parche que subsane un problema relacionado con el código fuente.

En este sentido, también resulta de vital importancia disponer del asesoramiento de profesionales de la ciberseguridad que puedan establecer una serie de recomendaciones para mitigar los problemas.

5. Auditar a los proveedores de software

Hasta ahora hemos abordado cómo se puede fortalecer la seguridad de un software a lo largo de todo su ciclo de vida y prevenir ataques de cadena de suministro. Pero este tipo de ataques va más allá de esta cuestión. No basta con centrarse en analizar y securizar el software de desarrollo propio. Sino que hay que contemplar, también, los riesgos de seguridad asociados al software de terceros que empleamos.

Las empresas no emplean, solo, aplicaciones desarrolladas por ellas mismas, sino que contratan herramientas de proveedores e, incluso, hacen uso de la integración de componentes de terceros enfocados a tareas específicas.

Pensemos, por ejemplo, en Bizum que provee su software de servicios de pago a las entidades bancarias que, a su vez, integran esta herramienta en sus aplicaciones móviles.

¿Cuál es la consecuencia de todo esto?

Las compañías que emplean software no pueden ignorar el control de la seguridad de sus proveedores.

De ahí que las auditorías de seguridad a proveedores sean un servicio de ciberseguridad de gran valor añadido y en auge. Puesto que son una herramienta de gran utilidad a la hora de controlar la cadena de suministro y prevenir las consecuencias económicas, legales y reputacionales de los ataques de cadena de suministro.

Así, muchas compañías contratan a empresas de ciberseguridad como Tarlogic la auditoría de soluciones de terceros que emplean. Lo que requiere la autorización del desarrollador del software a auditar.

6. Controlar la cadena de suministro en la era del Cloud y los SaaS

La transformación digital de las empresas ha traído consigo un alud de beneficios, tanto en el terreno comercial, abriendo nuevas vías de negocio, como en lo que respecta a la gestión y a los procesos internos. Sin embargo, también conlleva riesgos.

Cuanto más digitalizada esté una compañía, mayor es su nivel de ciberexposición frente a los criminales.

Si al famoso superhéroe Spider-man le decían aquello de «todo gran poder conlleva una gran responsabilidad», nosotros podríamos sostener que todas las bondades de la digitalización también conllevan tomarse en serio la ciberseguridad. Para ello no basta con invertir en proteger los activos y los sistemas propios, sino que es fundamental, también, controlar la seguridad de los proveedores.

6.1. El salto al Cloud complejiza la cadena de suministro

Más aún en un estadio como el actual, en el que ya no es que las empresas hayan digitalizado sus estructuras, sino que ya han ido más allá: han pegado el salto a la nube.

El Cloud está ganando terreno día a día. La proliferación del Software as a Service (SaaS) o de las Platform as a Service (PaaS) dan buena fe de ello.

Las ventajas de estas tecnologías son harto conocidas. Pero también debemos señalar que contribuyen a complejizar la cadena de suministro tecnológico de una compañía.

Por ello, resulta de vital importancia que las compañías tomen medidas para protegerse frente a los ataques de cadena de suministro.

La consolidación del Cloud deja clara una tendencia ineludible en materia de ciberseguridad: los ataques de cadena de suministro van a ir en aumento. Tanto en cantidad como en nivel de sofisticación. Si un software integra otro software que integra otro software que integra otro software… Atacando una debilidad de la cola de la cadena de suministro se puede llegar a causar un incidente de seguridad gravísimo en la cabeza.

En definitiva, los ataques de cadena de suministro se han convertido en una amenaza que se cierne sobre miles de empresas, a veces, sin que sean tan siquiera conscientes del riesgo. Por ello, todas las compañías deben tomarse en serio sus peligros y contratar servicios para securizar su software de desarrollo propio, pero también para auditar las soluciones de terceros que emplean.