Usos y prácticas con CWE en el mapeo de debilidades de software y hardware

A menudo conocemos noticias de incidentes de seguridad informática que evidencian debilidades por errores básicos. Como espectadores nos vemos desconcertados por la falta de cuidado de los sistemas informáticos y como encargados de ciberseguridad decimos, ¿cómo es que no tienen 2FA aún?, ¿por qué dejarían cuentas por defecto?, ¿quién les dijo que la contraseña iba hardcoded?

Y aunque estas preguntas no me quiten el sueño, a veces pienso,... ¿esto podría pasarme a mí?. Y sí, podría. Porque no puedo ni conocer todos los fallos posibles de memoria, ni tampoco la causa raíz de cada uno de ellos, pero aquí va una ayuda...

¿Qué es CWE?

El término de enumeración de debilidades comunes (CWE, por sus siglas en inglés), es un diccionario de debilidades que emplea una nomenclatura que permite identificar las debilidades del software y mapearlas de forma específica al caso particular de cada sistema informático. El objetivo es cartografiar (o mapear) las debilidades presentes en un sistema informático, generando una esquematización de debilidades en un modelo de nodos con relaciones padre-hijo.

CWE cuenta con niveles de abstracción, donde una mayor abstracción hace más general la descripción de la vulnerabilidad sin relación con tecnologías específicas; por el contrario, menor abstracción indica una debilidad más especifica, frecuentemente relacionada a tecnologías. Los tipos de abstracción son: Pillar, Class, Base y Variant.

Las debilidades pillars (representada por triángulos) no son accionables, esto debido a que no entregan suficiente información para elaborar planes de control o remediación.

Las debilidades class están descrita en una alta abstracción, no relacionada a productos o tecnologías. Un poco más específico que una debilidad pillars, pero más general que una base.

Las debilidades base aún se distancia de un recurso o tecnología, pero provee suficientes detalles de métodos de detección y prevención, por lo que a menudo son accionables.

Las debilidades variant es relacionada a un tipo de producto, lenguaje o tecnología, menor abstracción.

Fig 1. Abstracción de las debilidades. Fuente: CWE "Root Cause Mapping".

Además, los CWE tienen relaciones padre-hijo, permitiendo realizar el mapeo desde las debilidades más generales hasta dar con el que más se adapte al caso particular. Usualmente, la asignación de CWE en debilidades mapeadas (incluso en proveedores conocidos) es errónea/desactualizada, limitando la visibilidad e incluso generando controles inadecuados de los fallos de seguridad.

Caso de ejemplo

Imaginen un sistema que permite a las personas consultar información hiper sensible sobre su registro de deudas en el que solo piden el nombre o RUT. En el storyboard, la persona que ingresa al sistema tiene un único objetivo: consultar su propio registro y únicamente el suyo.

La premura con la que era necesario desarrollar el sistema impidió que esta sea auditada en aspectos de seguridad, y no se contaba con los recursos necesarios para contar con profesionales en DevSecOps.

Utilizando una base de datos SQL, se almacenó la información de registros de cada ciudadano, las consultas son diréctas desde el servidor y la mayor parte de las consultas están codificadas en duro (hardcoded).

Al cabo de un tiempo, les reportan que la base de datos del registro de deudas de todos los usuarios ha sido filtrada y vendida en foros de la DarkWeb.

Fallos explotados

Podemos observar que la plataforma implementa un inadecuado control de un recurso en el ciclo de vida del desarrollo (Pillar: CWE-664). Esto se evidencia en el almacenamiento inseguro de información sensible (Class: CWE-922), que dada la falta de controles de acceso (Base: CWE-921) en la consulta a través de la aplicación web, permite su acceso por terceros no autorizados.

En este caso podemos identificar que la plataforma no cuenta con un control de acceso (Pillar: CWE-284), por ende, no valida que el usuario que consulta un dato es auténticamente su dueño (Class: CWE-287). Esto se debe a que en realidad no existe autenticación (Base: CWE-306), considerando que solo pedía nombre completo o RUT, información actualmente pública.

Consecuentemente, la falta de neutralización de los campos de ingreso (Pillar: CWE-707) ocasionó que fuera posible ingresar elementos especiales interpretados por un proceso interno (Class: CWE-74). El proceso particular correspondía a la lógica de consultas de datos (Class: CWE-943) , específicamente de inyección SQL (Base: CWE-89) permitiendo ejecutar comandos SQL arbitrarios (Variant: CWE-564) y extraer la base de datos completa.

Como podemos ver, la explotación podría darse de un conjunto de fallos que, explotados de forma secuenciada o independiente, se obtiene un recurso valioso. Ciertos fallos son más globales que otros, y esto se distribuye en relaciones de pertenencia o herencia (parent-child) y otras relaciones clave que permiten mapear correctamente la debilidad específica para cada caso.

Fig 2. Mapeo de debilidades en caso de ejemplo.

Como podemos observar, la imagen anterior muestra inicialmente la debilidad Pillar, seguida por las debilidades Class y Bases según el caso. No todos los fallos técnicos se encuentran especificados (lógicamente), por lo que existen debilidades base que son accionables para mapeo de seguridad.

Asignación e identificación de CWE

Cada CWE tiene atributos importantes que debemos conocer para poder realizar una correcta asignación de debilidades, según lo específico o respectivo al caso del software y/o hardware que estamos evaluando.

Descripción

Explica de forma breve o extendida los aspectos de la debilidad, tales como las consecuencias e implicancias de la debilidad, el contexto en el que se aplica y ejemplos que permiten observar relaciones más directas.

Consecuencias comunes

Contiene palabras clave de las consecuencias resultantes de la explotación de la debilidad descritas en alcance (confidencialidad, disponibilidad, integridad, otros) e impacto (modificación, lectura, otros).

Relaciones

Describe relaciones entre debilidades que corresponden a ciertas categorías superiores, o relaciones de sub-debilidades que se derivan de otras. Estas relaciones facilitan la investigaciones de debilidades. Están organizadas acorde a abstracciones de comportamiento, partes del código en que se encuentra o cuando se introduce en el ciclo de vida del desarrollo.

Modos de introducción

Cómo y cuándo la debilidad fue introducida en el software o hardware, considerando la fase del ciclo de vida en el que de introdujo.

Fig 3. Modos de introducción en CWE-89.

Asociaciones

Muestra categorías y referencias para las que la debilidad forma parte. Esto permite comprender que existen diferentes categorías de vulnerabilidades, útiles para comprender de mejor manera los ámbitos en los que la debilidad puede generarse.

Fig 4. Asociaciones de CWE-200.

Notas de mapeo de vulnerabilidad

No todas las debilidades son aptas para ser utilizadas en entornos reales, debido a que existe evolución de los procesos y conceptualmente las formas de denominar debilidades está tendiendo a ser más específico.

Esta sección permite comprender el uso apropiado para cada CWE conforme la evolución del diccionario, el cual es extendido para lograr definiciones más específicas, facilitando la investigación.

Fig 5. Notas de mapeo CWE-200.

Una nota de DISCOURAGED indica que la utilización de esta debilidad no es válida para mapear vulnerabilidades de la vida real. Los motivos de su invalidación se encuentran descritas como se puede ver en la figura anterior.

Por otro lado, las debilidades que están permitidas para mapeo dirán ALLOWED, éstas podrían no ser necesariamente debilidades variant. Es clave leer esta sección para un mapeo adecuado.

Es importante comprender una debilidad desalentada (discouraged) o prohíbida para su utilización porque son necesarias durante una investigación, sus relaciones y asociaciones permiten dar una perspectiva global de un hallazgo, y poder observar categorías o grupos de debilidades presentes en un sistema informático. Por ejemplo, observar una alta presencia de debilidades de la categoría de inyección (CWE-1409) en sus distintas "formas" nos permite saber que existe la necesidad de aislar recursos clave, implementar controles de detección de payloads.