Blog HackRTU

‹ Regresar

CWE, LISTANDO DEBILIDADES INDUSTRIALES

 

CNA

 

 

El CWE o Common Weakness Enumeration es una lista de debilidades comunes tanto a nivel software como hardware que podrían dar pie a vulnerabilidades. Las diferentes listas que pueden consultarse en la página oficial del CWE son desarrolladas por la comunidad. El objetivo principal de estas listas CWE es proporcionar un lenguaje común para describir, mapear y clasificar el origen de algunas vulnerabilidades.

Históricamente, la lista CWE fue desarrollada en 2005 como parte del proyecto SAMATE (Software Assurance Metrics and Tool Evaluation) bajo la participación de MITRE con el NIST (National Institute of Standards and Technology) y esponsorizado por el U.S National Vulnerability Database (NVD). Como resultado de este proyecto, se creó el documento “Preliminary List Of Vulnerability Examples for Researchers” (PLOVER) que sentaría las bases de lo que hoy conocemos como CWE.

 

ENTENDIENDO LAS LISTAS CWE

Las listas CWE emplean una estructura jerárquica basada en diferentes niveles de abstracción que van de lo más general a lo más específico, tanto para software como para hardware. Estos niveles de abstracción son muy importantes para utilizar la lista concreta seleccionada cuando se quiera ligar/mapear una vulnerabilidad CVE a un CWE-ID concreto. Los diferentes niveles de abstracción son:

• View: Subconjunto de entradas CWE que proporcionan una forma de examinar contenido CWE. Las estructuras principales de view son las Slices (listas planas) y las Graphs (contiene relaciones entre entradas). Como ejemplo de esta jerarquía, se propone la lista específica creada para sistemas de control industrial, CWE VIEW: Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS.

• Pillar: Nivel más abstracto para la asignación de debilidades dentro de una lista (View). Representa un tema amplio para todas las debilidades de class/base/variant relacionadas con ella. Un pillar es diferente de una categoría, ya que un pillar sigue siendo técnicamente un tipo de debilidad que describe un error, mientras que una categoría representa una característica común utilizada para agrupar términos relacionados. Un ejemplo de pillar dentro de la lista desarrollada sobre debilidades en ICS es CWE-710: Improper Adherence to Coding Standards.

• Category: Entrada del CWE que contiene un conjunto de otras entradas que comparten una característica común. Ejemplo de esta jerarquía se encuentra la categoría ICS Communications donde se observan entradas relacionadas a nivel de jerarquía con la categoría principal y todas ellas versan sobre comunicaciones industriales.

• Class: Debilidad que se describe de forma muy abstracta, normalmente independiente de cualquier lenguaje o tecnología específicos. Más específica que una debilidad pillar, pero más general que una debilidad base. Las debilidades de nivel class suelen describir problemas en términos de una o dos de las siguientes dimensiones: comportamiento, propiedad y recurso. Ejemplo de una clase en la lista CWE sobre ICS puede ser: CWE-1384: Improper Handling of Physical or Environmental Conditions.

• Base: De los niveles más utilizados ya que es el mejor para mapear vulnerabilidades reales. Permite la descripción de debilidades con suficiente detalle para que puedan usarse como “causa raíz” en la asociación CVE/CWE. (CWE recomienda usar Base cuando sea posible para mapear CVEs). Ejemplo de este nivel base a nivel industrial encontramos el CWE-1338: Improper Protections Against Hardware Overheating que se encuentra dentro de la lista desarrollada para ICS.

• Variant: Debilidad relacionada con un tipo concreto de producto/tecnología/lenguaje de una Base. Este nivel suele ser ideal para la definición de pruebas estáticas o dinámicas en aplicaciones (SAST/DAST). Como ejemplo de este nivel se presenta la siguiente debilidad CWE-121: Stack-based Buffer Overflow dentro de la lista 1358 desarrollada para ICS.

• Composite: Elemento compuesto que consta de dos o más debilidades distintas, en el que todas las debilidades deben estar presentes al mismo tiempo para que surja una vulnerabilidad potencial. La eliminación de cualquiera de las debilidades elimina o reduce drásticamente el riesgo. Como ejemplo de este nivel se presenta la siguiente debilidad CWE-384: Session Fixation que aparece en la lista 1358 desarrollada para ICS.

Además de estos niveles, es importante tener en cuenta que el CWE no es sólo una lista plana, las entradas están conectadas entre sí. Los tipos de relaciones comunes dentro del CWE son:

• ParentOf/ChildOf: Relaciones jerárquicas entre abstracciones, sirve para modelar diferentes niveles de generalidad. Por ejemplo, un Class o Base puede tener varios hijos. Un hijo tiene exactamente un padre principal. Vamos ahora con un ejemplo concreto:

  • CWE-119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) sería ParentOf del CWE-120 (Classic Buffer Overflow) y del CWE-125 (Out-of-bounds Read). Esto se debe a que, en sistemas de control, una lectura fuera de límites (CWE-125) detectado a nivel de firmware en un PLC puede provocar una corrupción de memoria o pérdida de control del proceso físico.

  • Si se va a clasificar una vulnerabilidad 0-day como investigador siempre se recomienda utilizar el CWE más específico partiendo del padre a sus hijos.

• HasMember/MemberOf: Estas relaciones se refieren más a la agrupación temática que a la propia jerarquía, facilitando filtrar los CWE según su contexto.

Como ejemplo concreto para esta relación tenemos que el CWE-1368 (View: ICS Dependencies & Architecture) tiene los siguientes miembros, es decir, HasMember CWE-15 (External Control of System or Configuration Setting) y CWE-287 (Improper Authentication). Si hablásemos por ejemplo del CWE-1368 hacia arriba, CWE-1368 MemberOf CWE-1360 (ICS Dependencies (& Architecture)). Si un SCADA no valida entradas de un HMI y carece de mecanismos para filtrar las peticiones a través de usuarios legítimos y autenticados, puede ser manipulado y un atacante podría enviar comandos no autorizados.

​​​​​​

• Related (PeerOf): Relaciones laterales entre CWEs con la misma abstracción, pero con distinto enfoque. Es decir, los CWE están vinculados conceptualmente pero no a nivel de jerarquía. Esta clasificación ayuda sobre todo a entender cadenas de debilidades que pueden combinarse en ataques complejos.
  • Por ejemplo, el CWE-295 (Improper Certificate Validation) guarda relación con CWE-322 (Key Exchange without Entity Authentication). Aterricemos el ejemplo, en gateways IIoT, es decir, relacionados con el mundo industrial de las cosas, un fallo CWE-295 puede estar relacionado con CWE-322 porque ambos afectan a la verificación de confianza del emisor, y en un ataque MITM pueden usarse combinando estas debilidades para suplantar un servidor legítimo.
  • Veamos la relación en la tabla dentro de la lista CWE “Research Concepts” (View-1000). Para un análisis autónomo de lo comentado, consultar el siguiente enlace de donde se ha extraído el ejemplo: https://cwe.mitre.org/data/definitions/295.html.

​​​​​​

Estas conexiones pueden consultarse en la columna Nature donde se indica la naturaleza de relación entre un CWE origen y un CWE destino. Es importante tener en cuenta que siempre se lee en el sentido Origen à Destino ya que como vimos en el ejemplo de ParentOf/ChildOf la misma pareja de CWEs podría aparecer con direcciones y “Nature” distintas dependiendo del punto de vista.

Ahora que ya entendemos ligeramente cómo funcionan las listas CWE, aquí van algunas recomendaciones prácticas para usarla:

• Si vas a realizar una clasificación de un CVE, revisa correctamente el nivel de abstracción priorizando las CWE en nivel Base. Si estas analizando una aplicación, mejor utiliza Variants.
• Dibuja cadenas de relaciones para seleccionar el CWE más específico que permita una clasificación más afinada.
• Utiliza las Views específicas como la existente a nivel de ICS (CWE-1358 - Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) o de la IEC 62443 (CWE-1424 - Weaknesses Addressed by ISA/IEC 62443 Requirements) cuando ejecutes un trabajo específico. En nuestro caso para la ciberseguridad industrial va de perlas.
• Utiliza herramientas que la comunidad ha publicado para mejorar tus búsquedas y entendimiento sobre CWE como cwe-tool.
• No tengas miedo a equivocarte, ¿Quién no ha utilizado un CWE equivocado alguna vez? :P.

​​​​​​​

HISTORIA DEL CWE

Tras la lista preliminar desarrollada (PLOVER), en 2006 la comunidad saca una beta de la lista CWE como respuesta a un catálogo de “causas raíz” donde se originan vulnerabilidades. Con aproximadamente 300 entradas de potenciales debilidades, la primera versión beta tenía como objetivo definir una terminología común para debilidades relacionadas con el software.

El 9 de septiembre de 2008, se publica de forma oficial la versión 1.0 del CWE que marcaría el camino inicial hasta la versión que conocemos hoy en día con todos los detalles afinados a lo largo de los años.

Posteriormente, la versión CWE 2.0 fue publicada a mediados de 2011 incluyendo un mayor número de debilidades y relaciones entre ellas.

La versión CWE 3.2 se lanzó de forma pública en 2019 y no agregó elementos de ciberseguridad industrial, pero si permitió afinar las listas de CWE con desacreditaciones de antiguos CWE clasificados como “deprecated”.

La versión CWE 4.7 marcó el inicio de incorporación para el mundo de la ciberseguridad industrial en las listas CWE con la vista CWE-1358 - Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS que ya hemos utilizado en varios ejemplos a lo largo del artículo. Posteriormente otras versiones como la 4.9 revisaría las categorías creadas dentro de la lista y potenciando la lista focalizada en los sistemas de control industrial.

Ya en 2024, se publica la versión CWE 4.14 que introduce otra nueva vista CWE-1424 - Weaknesses Addressed by ISA/IEC 62443 Requirements, en este caso relacionada con la familia de estándares IEC 62443 focalizando algunas debilidades en el estándar IEC 62443-3-3 o el estándar IEC 62443-3-2. Se entiende que la focalización se realizó sobre estos estándares por las debilidades a nivel de arquitectura y diseño (IEC 62443-3-3) y los potenciales problemas a nivel de operación o mantenimiento que pueden salir en un análisis de riesgos (IEC 62443-3-2).

Finalmente, la versión más reciente de las listas CWE es la CWE 4.17 donde se mantiene el trabajo de afinar y ampliar tanto las listas existentes como otras que puedan proponerse.

 

EJEMPLO CONCRETO DE LAS LISTAS CWE

En este caso, tal y como ya hemos comentado anteriormente en otras publicaciones hablando de CVE, CVSS y CPE aterrizaremos el análisis de la vulnerabilidad CVE-2025-41362 para conocer cómo sería su clasificación a nivel CWE.

Dado que el CWE es un campo que se utiliza directamente en los avisos, comentaremos como un investigador puede utilizar la clasificación para asignar la debilidad más coherente en base a la vulnerabilidad reportada.

La vulnerabilidad CVE-2025-41362 tiene el CWE-94      Improper Control of Generation of Code ('Code Injection') asignado. Esto se debe a que directamente la vulnerabilidad es una inyección de código y por lo tanto no tiene gran complejidad a la hora de ser clasificada. También se puede apreciar como este CWE no está estrictamente relacionado con el mundo industrial ya que la vulnerabilidad se ha encontrado en una tecnología web que poseía el dispositivo, pero ¿tendríamos un equivalente a nivel industrial?

Vamos a ver las posibilidades aplicando la lógica. Buscando inyección de código o código en general dentro de la lista Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS detectamos 3 resultados de los cuáles ya descartamos 2 porque una hace referencia a descargar el código de un dispositivo sin integridad y la otra a activar el modo debug en el código. Nos quedaremos con la siguiente debilidad CWE-470: Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection'). Ahora que tenemos la debilidad, vamos a ver las relaciones que pueda tener la misma y detectamos que esta el miembro (MemberOf) de la categoría OWASP Top Ten 2021 Category A03:2021 - Injection y, como es lógico, aquí si se incluye el CWE-94 por lo que, a nivel de relación, si se hubiese utilizado la lista específica para ICS, que no existía por aquel entonces, la catalogación de la debilidad podría ser CWE-470.

Desde HackRTU, consideramos que el uso de listas específicas dentro de CWE es fundamental para gestionar de manera precisa las debilidades que pueden originar potenciales vulnerabilidades. Además, en base a las nuevas normativas y directivas como la NIS2 y CRA, el uso de las listas CWE puede facilitar en gran medida a las organizaciones la gestión de problemáticas relacionadas con la ciberseguridad tanto a nivel industrial como a nivel corporativo.

 

 

EQUIPO DE HACKRTU