¿Estamos listos para lidiar con actualizaciones maliciosas masivas?

Un vistazo más de cerca a los vectores de ataque de software

Queda claro que tanto los estados nacionales como los grupos de hackers seguirán atacando a proveedores de la cadena de suministro de distintas industrias. Ya escribí sobre cómo la deuda técnica puede hacer que las organizaciones sean vulnerables. Eso es una cosa a considerar. Sin embargo, ¿cómo y dónde lanzarán sus nuevos ataques los delincuentes? ¿Qué otros vectores de ataque podrían verse vulnerados?

Si bien los ataques como Sunburst, los ataques de ransomware perpetrados por el grupo REvil como el que realizaron contra Kaseya y otros siguen captando la mayor atención, un ataque menos conocido de 2021 me resultó llamativo: las cuatro vulnerabilidades OMIGOD que afectaron al agente de software Open Management Infrastructure (OMI, Infraestructura de Gestión Abierta) en máquinas con el agente de Linux de Azure.

Los proyectos de código abierto siguen creciendo exponencialmente. Es cierto que la seguridad del software de código abierto mejoró drásticamente durante los últimos 10 años, y no hay duda de que las vulnerabilidades del software de código abierto se corrigen a un ritmo mucho más rápido. Esas son las buenas noticias. No obstante, también es cierto que los ataques a la cadena de suministro de código abierto están aumentando a una velocidad alarmante. En su informe sobre el Estado del software de la cadena de suministro de 2021 Sonatype estimó que ocurrieron 12 000 ataques a proyectos de código abierto, lo que representa un incremento del 650 % de un año al siguiente.

 

La prioridad competitiva que se da a la innovación y el enfoque implacable en acortar el tiempo de salida al mercado hace que las organizaciones grandes y pequeñas adopten proyectos de código abierto. Tanto las agencias gubernamentales como las organizaciones del ámbito privado sienten la presión de innovar e implementar proyectos de software a un ritmo cada vez mayor. Sin embargo, como dice el dicho “rápido y bien, no siempre marchan juntos”, y este apuro tiene un costo, especialmente desde la perspectiva de la ciberseguridad.

Por lo tanto, es imperativo que cada uno de nosotros, tanto en el sector público como en el privado, prioricemos la seguridad en cada uno de nuestros proyectos de código abierto. Sacar provecho del código abierto se trata en parte sobre la innovación y en parte sobre el tiempo de salida al mercado. No obstante, las organizaciones deben realizar la diligencia debida en muchas etapas a lo largo del proyecto. Eso significa llevar adelante muchas etapas de revisión del código tanto al comienzo de un proyecto como durante el desarrollo y el proceso de implementación. Efectivamente, no es una tarea fácil, y se vuelve todavía más complicada si se consideran las explotaciones de vulnerabilidades que pueden venir de parte de atacantes externos o por medio de recursos internos que trabajan en esos proyectos.

¿Cómo podemos protegernos?

Un arma clave en la lucha contra las actualizaciones de software maliciosas es abordar la deuda técnica. La deuda técnica consiste en la diferencia entre el “precio” (tiempo, recursos humanos, inversión en tecnología) que debe tener un proyecto técnico para ser perfecto y estar preparado para el futuro, y el “precio” que una organización está preparada para pagar en el momento. Los productos pueden verse demorados debido a una menor inversión, pero mucha de esta deuda se centra en torno a la aplicación de actualizaciones de software, que son absolutamente necesarias pero frecuentemente pasadas por alto.

Incluso si existe la posibilidad de que los atacantes (ya sea que se trate de estados nacionales o delincuentes con motivaciones financieras) puedan lanzar malware mediante actualizaciones de software, los administradores de TI deben asegurarse de aplicar las actualizaciones y los parches a medida que aparecen.

Si se acumula deuda técnica, las vulnerabilidades y los baches de seguridad brindarán una vía de acceso a los atacantes, y la combinación de las nuevas técnicas de entrega de malware sumadas a las vulnerabilidades sin corregir son motivo de preocupación.

Además, con el aumento del trabajo híbrido, los usuarios finales deben ser más responsables en lo que respecta a corregir y actualizar sus sistemas. Esto puede llevar a que no se apliquen las actualizaciones o que las apliquen personas no acostumbradas a la tarea, lo que significa que son más propensos a aceptar comportamiento que los equipos de TI detectarían como sospechoso. Los líderes deben garantizar que se implemente y actualice con regularidad la capacitación en ciberseguridad, para asegurarse de que los empleados actúen como la primera línea de defensa.

El de Solarwinds no fue el primer incidente en sacar ventaja de actualizaciones de software maliciosas y, con certeza, no será el último, pero con conciencia a nivel de toda la empresa y una administración de parches sólida, podemos aumentar nuestras defensas.

Taking a closer look at software attack vectors

It's clear that both nation-states and hacker groups alike will continue to target supply chain providers across multiple industries. I’ve written about how technical debt can make organizations vulnerable. That’s one consideration. But how and where are bad actors launching new attacks? What other attack vectors could be exploited?

While attacks like Sunburst, ransomware attacks perpetrated by the REvil group such as against Kaseya and others continue to draw mainstream attention, one lesser-reported hack in 2021 caught my attention: the four OMIGOD vulnerabilities that affect the Open Management Infrastructure (OMI) software agent on Azure Linux machines.

Open source projects continue to grow exponentially. It’s true that open source software security has improved dramatically over the last 10 years, and it’s no question that open source software vulnerabilities are being patched at  a much more rapid pace. That’s the good news. But it’s also true that open source supply chain attacks are increasing at an alarming rate. In its 2021 State of the Software Supply Chain report, Sonatype estimates 12,000 attacks on open source projects occurred—representing a 650% increase year over year.

 

The competitive priority placed on innovation and relentless focus on shortening time-to-market drives organizations large and small to adopt open source projects. Government agencies and private sector organizations alike feel the pressure to innovate and to deploy software projects at an ever-increasing rate. But the adage to ‘move fast and break things’ comes at a cost, especially from a cybersecurity perspective.

As such, it’s imperative for each of us across the public and private sector to prioritize security across every one of our open source projects. Leveraging open source is partly about innovation and time to market. But organizations must perform due diligence at many stages throughout a project. That translates to multiple layers of code review both at the start of a project and throughout the development and deployment process. No small undertaking indeed - and made even more complicated when you consider exploits can come from bad actors outside or via internal resources working on those projects.

How can we protect ourselves?

A key weapon in the fight against malicious software updates is addressing technical debt. This is the difference between the ‘price’ (time, human resources, technology investment) a technical project should cost in order to be perfect and future-proofed, and the “price” an organization is prepared to pay at the time. Products can get behind the curve due to reduced investment, but a lot of this debt centres around applying software updates – absolutely necessary, and so often overlooked.

Even though there is the possibility that malicious actors (whether nation-state or financially-motivated criminal!) may output malware through software updates, IT administrators must keep on top of applying updates and patches as they come in.

If technical debt builds, vulnerabilities and security holes will provide a way in for attackers – and the combination of new malware delivery techniques plus unpatched vulnerabilities causes concern.

In addition, with the increase in hybrid working, end users are having to be more responsible for patching and updating their systems. This could lead to either updates not happening at all, or updates being applied by those unused to the task, meaning they are more likely to accept behavior IT teams would spot as suspicious. Leaders should ensure that cybersecurity training is rolled out and regularly updated, to ensure employees act as a first line of defense.

The Sunburst malware wasn’t the first incident to take advantage of malicious software updates and it certainly isn’t going to be the last, but with company-wide awareness and strong patch management we can raise our defenses.