Patch Madness: los avisos de errores del proveedor están rotos, muy rotos

BLACK HAT EE. UU. – Las Vegas – Mantenerse al día con los parches de vulnerabilidades de seguridad es, en el mejor de los casos, un desafío, pero priorizar en qué errores enfocarse se ha vuelto más difícil que nunca, gracias a los puntajes CVSS que carecen de contexto, los avisos confusos de los proveedores y las correcciones incompletas que deja a los administradores con una falsa sensación de seguridad.

Ese es el argumento que Brian Gorenc y Dustin Childs, ambos de Zero Day Initiative (ZDI) de Trend Micro, esgrimieron desde el escenario de Black Hat USA durante su sesión, “Cálculo del riesgo en la era de la oscuridad: lectura entre líneas de los avisos de seguridad."

ZDI ha revelado más de 10,000 2005 vulnerabilidades a los proveedores de la industria desde XNUMX. En el transcurso de ese tiempo, el gerente de comunicaciones de ZDI, Childs, dijo que notó una tendencia preocupante, que es una disminución en la calidad de los parches y una reducción de las comunicaciones relacionadas con las actualizaciones de seguridad.

“El verdadero problema surge cuando los proveedores lanzan parches defectuosos o información inexacta e incompleta sobre esos parches que pueden hacer que las empresas calculen mal su riesgo”, señaló. "Los parches defectuosos también pueden ser una gran ayuda para los escritores, ya que los 'días n' son mucho más fáciles de usar que los días cero".

El problema con las puntuaciones CVSS y la prioridad de aplicación de parches

La mayoría de los equipos de seguridad cibernética no tienen suficiente personal y están bajo presión, y el mantra "siempre mantenga todas las versiones de software actualizadas" no siempre tiene sentido para los departamentos que simplemente no tienen los recursos para cubrir el frente marítimo. Es por eso que priorizar qué parches aplicar de acuerdo con su calificación de gravedad en la Escala de gravedad de vulnerabilidad común (CVSS) se ha convertido en un recurso alternativo para muchos administradores.

Childs señaló, sin embargo, que este enfoque es profundamente defectuoso y puede llevar a que se gasten recursos en errores que es poco probable que alguna vez se exploten. Eso se debe a que hay una gran cantidad de información crítica que el puntaje CVSS no proporciona.

“Con demasiada frecuencia, las empresas no buscan más allá del núcleo base de CVSS para determinar la prioridad de los parches”, dijo. “Pero el CVSS realmente no analiza la explotabilidad, o si es probable que una vulnerabilidad se use en la naturaleza. El CVSS no le dice si el error existe en 15 sistemas o en 15 millones de sistemas. Y no dice si está o no en servidores de acceso público”.

Agregó: "Y lo más importante, no dice si el error está presente o no en un sistema que es crítico para su empresa específica".

Por lo tanto, aunque un error pueda tener una calificación crítica de 10 sobre 10 en la escala CVSS, su verdadero impacto puede ser mucho menos preocupante de lo que indicaría esa etiqueta crítica.

“Un error de ejecución de código remoto no autenticado (RCE) en un servidor de correo electrónico como Microsoft Exchange generará mucho interés por parte de los escritores de exploits”, dijo. "Un error de RCE no autenticado en un servidor de correo electrónico como Squirrel Mail probablemente no generará tanta atención".

Para llenar los vacíos contextuales, los equipos de seguridad a menudo recurren a los avisos de los proveedores, que, señaló Childs, tienen su propio problema evidente: a menudo practican la seguridad a través de la oscuridad.

Los avisos de Microsoft Patch Tuesday carecen de detalles

En 2021, Microsoft tomó la decisión para eliminar resúmenes ejecutivos
de las guías de actualización de seguridad, en lugar de informar a los usuarios que los puntajes CVSS serían suficientes para la priorización, un cambio que Childs criticó.

“El cambio elimina el contexto que se necesita para determinar el riesgo”, dijo. “Por ejemplo, ¿un error de divulgación de información descarga memoria aleatoria o PII? O para una omisión de funciones de seguridad, ¿qué se omite? La información en estos artículos es inconsistente y de calidad variable, a pesar de las críticas casi universales al cambio”.

Además de que Microsoft "eliminó u ocultó información en las actualizaciones que solían generar una guía clara", ahora también es más difícil determinar la información básica del martes de parches, como cuántos errores se corrigen cada mes.

“Ahora tienes que contarte a ti mismo, y en realidad es una de las cosas más difíciles que hago”, señaló Childs.

Además, la información sobre cuántas vulnerabilidades están bajo ataque activo o son conocidas públicamente todavía está disponible, pero ahora está enterrada en los boletines.

“Como ejemplo, con 121 CVE parcheados este mes, es un poco difícil examinarlos todos para buscar cuáles están bajo ataque activo”, dijo Childs. “En cambio, la gente ahora confía en otras fuentes de información como blogs y artículos de prensa, en lugar de lo que debería ser información fidedigna del proveedor para ayudar a determinar el riesgo”.

Cabe señalar que Microsoft se ha duplicado en el cambio. En una conversación con Dark Reading en Black Hat USA, el vicepresidente corporativo del Centro de Respuesta de Seguridad de Microsoft, Aanchal Gupta, dijo que la compañía decidió conscientemente limitar la información que proporciona inicialmente con sus CVE para proteger a los usuarios. Si bien los CVE de Microsoft brindan información sobre la gravedad del error y la probabilidad de que se explote (y si se está explotando activamente), la compañía será juiciosa sobre cómo publica la información de explotación de vulnerabilidades, dijo.

El objetivo es dar a las administraciones de seguridad suficiente tiempo para aplicar el parche sin ponerlas en peligro, dijo Gupta. “Si, en nuestro CVE, proporcionamos todos los detalles de cómo se pueden explotar las vulnerabilidades, seremos un día cero para nuestros clientes”, dijo.

Otros proveedores practican la oscuridad

Microsoft no es el único que proporciona detalles escasos en las revelaciones de errores. Childs dijo que muchos proveedores no proporcionan CVE en absoluto cuando lanzan una actualización.

“Simplemente dicen que la actualización corrige varios problemas de seguridad”, explicó. "¿Cuanto? ¿Cuál es la gravedad? ¿Cuál es la explotabilidad? Recientemente, incluso un proveedor nos dijo específicamente que no publicamos avisos públicos sobre cuestiones de seguridad. Ese es un movimiento audaz”.

Además, algunos proveedores colocan avisos detrás de muros de pago o contratos de soporte, lo que oscurece aún más su riesgo. O bien, combinan varios informes de errores en un solo CVE, a pesar de la percepción común de que un CVE representa una única vulnerabilidad única.

“Esto lleva a posiblemente sesgar su cálculo de riesgo”, dijo. “Por ejemplo, si observa la compra de un producto y ve 10 CVE que se han parcheado en un cierto período de tiempo, puede llegar a una conclusión sobre el riesgo de este nuevo producto. Sin embargo, si supiera que esos 10 CVE se basaron en más de 100 informes de errores, podría llegar a una conclusión diferente”.

Parches de placebo Priorización de plagas

Más allá del problema de la divulgación, los equipos de seguridad también se enfrentan a problemas con los propios parches. Los "parches placebo", que son "arreglos" que en realidad no hacen cambios de código efectivos, no son infrecuentes, según Childs.

“Así que ese error todavía está ahí y puede ser explotado por los actores de amenazas, excepto que ahora han sido informados al respecto”, dijo. “Hay muchas razones por las que esto podría suceder, pero sucede – errores tan agradables que los parcheamos dos veces”.

A menudo también hay parches que están incompletos; de hecho, en el programa ZDI, entre el 10 % y el 20 % de los errores que analizan los investigadores son el resultado directo de un parche defectuoso o incompleto.

Childs usó el ejemplo de un problema de desbordamiento de enteros en Adobe Reader que conduce a una asignación de montón de tamaño insuficiente, lo que resulta en un desbordamiento de búfer cuando se escriben demasiados datos en él.

“Esperábamos que Adobe corrigiera al establecer cualquier valor sobre un cierto punto como malo”, dijo Childs. “Pero eso no es lo que vimos, y dentro de los 60 minutos posteriores a la implementación, hubo una omisión del parche y tuvieron que parchear nuevamente. Las reposiciones no son solo para programas de televisión”.

Cómo combatir los problemas de priorización de parches

En última instancia, cuando se trata de la priorización de parches, la gestión efectiva de parches y el cálculo de riesgos se reduce a identificar objetivos de software de alto valor dentro de la organización, así como al uso de fuentes de terceros para delimitar qué parches serían los más importantes para un entorno determinado, el señalaron los investigadores.

Sin embargo, el problema de la agilidad posterior a la divulgación es otra área clave en la que las organizaciones deben centrarse.

Según Gorenc, director sénior de ZDI, los ciberdelincuentes no pierden el tiempo integrando vulnerabilidades con grandes superficies de ataque en sus conjuntos de herramientas de ransomware o sus kits de explotación, buscando armar las fallas recientemente reveladas antes de que las empresas tengan tiempo de parchear. Estos llamados errores de n-día son una trampa para los atacantes, quienes en promedio pueden aplicar ingeniería inversa a un error en tan solo 48 horas.

“En su mayor parte, la comunidad ofensiva está utilizando vulnerabilidades de día n que tienen parches públicos disponibles”, dijo Gorenc. "Es importante para nosotros comprender en el momento de la divulgación si un error realmente se convertirá en un arma, pero la mayoría de los proveedores no brindan información sobre la explotabilidad".

Por lo tanto, las evaluaciones de riesgos empresariales deben ser lo suficientemente dinámicas para cambiar después de la divulgación, y los equipos de seguridad deben monitorear las fuentes de inteligencia de amenazas para comprender cuándo se integra un error en un kit de explotación o ransomware, o cuándo se lanza una explotación en línea.

Además de eso, una línea de tiempo importante que las empresas deben considerar es cuánto tiempo se tarda en implementar un parche en toda la organización y si hay recursos de emergencia que se pueden utilizar si es necesario.

“Cuando se producen cambios en el panorama de amenazas (revisiones de parches, pruebas de concepto públicas y lanzamientos de exploits), las empresas deben cambiar sus recursos para satisfacer la necesidad y combatir los riesgos más recientes”, explicó Gorenc. “No solo la última vulnerabilidad publicitada y nombrada. Observe lo que sucede en el panorama de amenazas, oriente sus recursos y decida cuándo actuar”.