Blog HackRTU

‹ Regresar

CPE, EL PASAPORTE DE LOS DISPOSITIVOS VULNERABLES

 

CNA

 

 

Los CPE o Common Platform Enumeration son un esquema de nomenclatura estándar legible para codificar sistemas informáticos, software y paquetes. Basado en la sintaxis genérica de los Identificadores Uniformes de Recursos (URI), los CPE incluyen un formato de nombre formal, un método para comprobar nombres de un sistema y un formato de descripción para vincular texto y pruebas a un nombre.

En resumen, los CPE proporcionan un diccionario de sistemas informáticos, plataformas y paquetes comunes codificados en un formato de nomenclatura normalizado y adecuados para su interpretación y procesamiento.

Originalmente fue desarrollado por MITRE a mediados de los años 2000, pero desde 2013, la propiedad y operación de los CPE fue transferida al NIST (National Institute of Standards and Technology) como parte de la U.S National Vulnerability Database (NVD).

 

HISTORIA DEL CPE

Aunque en el año 2013 MITRE transfirió la propiedad del CPE y su operación al NIST, ya existían varias versiones anteriores. En el año 2005, MITRE publicó el primer borrador, la versión CPE 0.9, para evaluar la viabilidad del estándar (actualmente esta versión no está disponible en el repositorio oficial).

La versión CPE 1.1, publicada en marzo de 2007, fue la primera en aparecer oficialmente dentro de los repositorios de MITRE. Esta versión, establecía una sintaxis XML básica para describir los nombres de los productos sirviendo como punto de partida para próximas versiones.

Posteriormente, la versión CPE 2.0 de finales de 2007, introdujo un cambio fundamental, separando las especificaciones que contenía el CPE en diferentes módulos (esquema de diccionario, lenguaje de expresión, esquemas de validación, etc). La versión CPE 2.1 fue publicada el 31 de enero de 2008 por parte de MITRE, representando un gran avance tanto en la formalización como en la relevancia en el sector. La versión CPE 2.2, similar a la versión anterior, se publicó en el año 2009, e introdujo una implementación de referencia nueva, un código Java del que se podía extraer la información de forma sencilla mediante herramientas de seguridad automatizadas.

Finalmente, el NIST, publicó en agosto de 2011 la versión CPE 2.3. Esta versión es la versión que se utiliza actualmente durante la gestión de las vulnerabilidades, aunque sigue existiendo soporte por parte del NIST para el diccionario basado en la versión CPE 2.2 a través de su buscador de CPE.

 

CPE 2.3, LA ÚLTIMA VERSIÓN PUBLICADA

Desde su publicación a mediados del año 2011, la nueva versión del estándar es la más utilizada debido a sus nuevas implementaciones y mejoras en cuanto a la separación en diferentes especificaciones independientes: “Naming Specification”, “Dictionary Specification”, “Applicability Language Specification” and “Matching Specification”.

En definitiva, la versión 2.3 define un formato de cadena uniforme, especificaciones para su uso y reglas de comparación para identificar equivalencias entre plataformas. Además, a diferencia de las versiones anteriores, proporciona una estructura totalmente legible por humanos y máquinas facilitando aún más la integración en herramientas para la detección de vulnerabilidades en base a los activos inventariados, por fabricante, sistema operativo, versiones de firmware, dispositivos objetivo, etc.

La versión CPE 2.3 se basa en las cuatro especificaciones mencionadas anteriormente y que ahora desglosaremos brevemente:

• Naming Specification: Esta sección indica como debe escribirse un CPE, el orden de las características, formato hasta un máximo de 13 valores empezando por CPE, la versión del estándar utilizada y luego el producto afectado (con múltiples características):
  • wfn:[part="o",vendor="zivautomation",product="idf",version="0.10.0-0C03-03 ",update="beta"]
  • Este método de denominación se conoce como CPE bien formado (WFN). Posteriormente, la propia especificación también define como transformar la cadena anterior en un enlace Identificador Uniforme de Recursos:
  • cpe:/o:zivautomation:idf: 0.10.0-0C03-03:beta.
  • Así mismo, también, dentro de la especificación, se admite y está contemplada la llamada cadena formateada, similar a la anterior cadena, pero con características complementarias a la base:
  • cpe:2.3:o:zivautomationidf: 0.10.0-0C03-03 beta:*:*:*:*:*:*
• Dictionary Specification: Hace referencia a un registro o listado de todos los productos válidos, es decir, es como un diccionario con todas las posibles combinaciones válidas de CPE únicas. Cada entrada de estos “diccionarios” tiene su identificador CPE, la fecha de publicación, un título, referencias externas, etc. En estos diccionarios, solo se almacenan los WFN que identifican una sola clase de producto, no un conjunto de clases de productos:
  • wfn:[part="o",vendor="zivautomation",product="idf",version="0.10.0-0C03-03 ", update="NA",edition=NA,language=NA,sw_edition="NA", target_sw=NA,target_hw="NA",other=NA]
  • Como se ha mencionado antes, existen varios diccionarios, pero el diccionario oficial de CPE esta gestionado por el NIST y es el repositorio autorizado de nombres de CPE permitiendo a cualquier persona, organización u herramienta automatizada encontrar los nombres de los identificadores en un lugar centralizado.
• Applicability Language: Permite conocer a que versión exacta del producto afecta la vulnerabilidad. Define una forma estandarizada de describir las plataformas afectadas mediante la formación de expresiones lógicas complejas.
• Matching Specificación: Esta especificación define el método para realizar una comparación uno a uno de un nombre CPE de origen con un nombre CPE de destino. Es decir, permite verificar si un producto en particular está instalado en un sistema. Esto permite a herramientas de gestión de activos que tengan información recopilada comparar sus características con una cadena WFN para saber si el activo desplegado es el mismo que puede tener vulnerabilidades de forma rápida y eficiente. Un ejemplo de la WFN dentro de esta especificación sería:
  • wfn:[part="o",vendor="zivautomation",product="idf", versión="0.10.0-0C03-03 ",actualización=NA,edición=NA,idioma="en\-us"]

Aunque en términos generales las especificaciones del CPE y el identificador CPE pueden parecer complejos, simplifican muchos procesos como la rápida detección de vulnerabilidades en base a sistemas desplegados o en base a componentes utilizados en un sistema industrial en conjunto. Un ejemplo claro, dentro de un SBOM (Software Bill of Materials) con información sobre versiones, permitiría gracias a los CPE, detectar mediante una herramienta automatizada de forma rápida y eficaz que CVE afecta a ese componente, activo o sistema.

 

EJEMPLO CPE 2.3

En este caso, y para dar un contexto de los diferentes campos que tiene el CPE, utilizaremos la vulnerabilidad CVE-2025-41362, con un CVSS 4.0 de 5.3 detectada por uno de nuestros investigadores.

Antes de ver el CPE (todavía no existe en la base de datos de CPEs), por dar contexto, la vulnerabilidad asociada a este CPE se trata de una inyección de código tanto en el IDF v0.10.0-0C03-03 como en el ZLF v0.10.0-0C03-04 y con CWE-94 (Code Injection) lo que permitiría a un atacante almacenar una carga maliciosa en el software para posteriormente ejecutarse en el navegador de la víctima. Esta vulnerabilidad fue descubierta durante el análisis del dispositivo (más información sobre el servicio aquí) en un entorno de laboratorio.

Aunque el CVE ID fue publicado el 6 de junio de 2025, a fecha de la publicación de este post, 7 de julio de 2025, todavía no existe el CPE correspondiente al producto y versión (IDF v0.10.0-0C03-03 y ZLF v0.10.0-0C03-04 de ZIV Automation) afectados por la vulnerabilidad, en esta entrada de nuestro blog, vamos a simular lo que podría ser el CPE oficial publicado por el NIST y explicando cada uno de los campos para el producto IDF con versión v0.10.0-0C03-03:

CPE:2.3:o:zivautomation:idf_firmware:0.10.0-0C08:1.1.0:*:*:*:*:*:*:*

• CPE: Primer valor de la cadena indicando que se hace referencia a un identificador de CPE.
• 2.3: Versión del estándar utilizada, en este caso la última disponible y publicada por el NIST.
• o: Hace referencia al tipo de producto afectado, habiendo 3 posibilidades: Aplicación (a), sistema operativo (o) o hardware (h). En este caso, y dado que se tiene información sobre el sistema operativo se utiliza la o.
• zivautomation: Sección del fabricante o proveedor que se ha visto afectado, en este caso ZIVAUTOMATION en vez de ZIV dado que buscando otras vulnerabilidades del propio fabricante existían CPE ya asociados con el fabricante ZIVAUTOMATION dentro del diccionario.
• idf_firmware: Modelo del dispositivo afectado y dentro del diccionario de CPE.
• 0.10.0-0C08:1.1.0: Versión del producto afectado, en este caso, extrayendo información del CVE, tenemos que la versión afectada del IDF es 0.10.0-0C08:1.1.0.

El resto de los campos del CPE en este caso están marcados como un *, lo cual hace referencia a cualquier posibilidad, pero, a continuación, mostramos a que harían referencia los campos restantes siguiendo el orden establecido por MITRE y las especificaciones:

• Update: Actualización o parche del dispositivo.
• Edition: Campo remanente de la versión 2.2. En la actualidad en casi todos los casos aparece como * o – dado que este campo ahora esta desglosado en sw_edition, target_sw, target_hw, language, otros.
• Language: Idioma del producto afectado (es, en, pt, etc.)
• Sw_edition: Versión del software (Ejemplo: professional, en referencia a Siemens SIMATIC WinCC Professional version)
• Target_sw: Plataforma objetivo del CPE (Ejemplos: vxworks, unix, aix, etc)
• Target_hw: Hardware afectado objetivo. (Ejemplos: s7-1500, rx3i, cibtrikkigux-5580, etc).
• Other: Campo reservado para otras características de relevancia.

 

Desde HackRTU, consideramos que el uso de estándares como CPE es fundamental para gestionar de manera precisa y automatizada los riesgos asociados a vulnerabilidades, especialmente en entornos industriales. Además, en base a las nuevas normativas y directivas como la NIS2 y CRA, el uso de los CPE puede facilitar en gran medida a las organizaciones la gestión de vulnerabilidades en base a sus inventarios o a SBOMs específicos para la automatización de revisión de CVE en base a CPE.

 

 

EQUIPO DE HACKRTU