Boletines de seguridad != gestión de seguridad

Buenas,

Secunia, Secwatch, Securiteam, Vupen, US-CERT … son muchos los sitios de Internet que se dedican a hablar de vulnerabilidades. Hay servicios gratuitos, los hay de pago. Demasiados para enumerarlos.

Estos servicios tienen un denominador común: son repositorios de información en los que se publica, para un producto y un problema determinado, una ficha en la que suele presentarse, además del producto y versión afectados, datos como nivel de riesgo o criticidad, existencia de parches o workarounds mitigatorios, fechas de descubrimiento, actualización y solución de las vulnerabilidades, así como una breve explicación de la problemática que se denuncia. Es lo que se llama un boletín de seguridad, y los hay de todos los colores y para todos los gustos.

Un boletín tiene una utilidad principal, y esa no es otra que poner en conocimiento de los equipos de gestión del cambio que se ha descubierto un problema de seguridad en un componente que podría pertenecer o pertenece a su parque. Aunque los boletines incluyen enlaces a parches, soluciones, comentarios, vida, obra y milagros de los descubridores del problema, y mucha más información (útil, nadie dice que no) los boletines per se sirven principalmente para avisar. Es por esto que los anglosajones los suelen llamar advisories, lo que a veces se traduce como avisos, pero estaría mejor traducido como consejos.

¿Y por qué son consejos o avisos y no mandatos? ¿Por qué es un error convertir cualquier aviso de seguridad en un mandato de seguridad? Pues oiga, muy fácil. Los boletines clasifican los riesgos sin tener en cuenta el despliegue real del producto. Cuando un investigador o empresa escribe un boletín, no lo hace poniéndose en la piel de la totalidad de los n usuarios que pueden tener instalado un producto determinado, entre otras razones, porque es imposible. A lo sumo, se basará en una batería de pruebas lo más amplia posible y en su experiencia, pero es imposible reproducir todas las condiciones que pueden darse cuando se instala un paquete o conjunto de programas. El boletín, en mayor o menor medida, se suele escribir de un modo abstracto, analizando los riesgos teniendo en cuenta el elemento de un modo aislado.

Los boletines suelen clasificar los riesgos en función de tres parámetros:

• Ámbito de explotación: local, remota o ambas
• Existencia de parches, contramedidas y exploits conocidos
• Tipología de acción maliciosa a la que puede conducir: revelación de información, escalada de privilegios, ejecución de código, denegación de servicio, etc.

Así, por poner dos ejemplos básicos, siguiendo esta clasificación un problema que sólo se puede explotar en local, sin acceso al sistema y condicionado, será poco crítico, mientras que una vulnerabilidad que pueda ejecutarse en remoto sin condiciones, y que conduzca a la ejecución de código, existiendo además exploits circulando en redes públicas, será un asunto altamente crítico.

Vamos a ver algunos ejemplos reales donde podremos comprobar que basarnos exclusivamente en un boletín de seguridad para calificar un riesgo para un despliegue determinado es un terrible error. Son cuatro ejemplos sobre cuatro productos distintos, y en este caso, son boletines públicos de la empresa Secunia, más o menos recientes en el tiempo.

Ejemplo 1

Título: Internet Explorer Data Binding Memory Corruption Vulnerability (10 de diciembre de 2008)

Calificación según el boletín: Extremadamente crítico (explotación remota, existencia de exploits confirmados, ejecución arbitraria de código)

Comentarios: ¿Dónde está reflejado ahí el ámbito de actuación de ese Internet Explorer? En ningún sitio. Es decir, si Internet Explorer es un producto de escritorio en una organización, donde es empleado para acceder a un CRM en red local, donde los equipos no admiten entrada de datos externos (no USB, no CD/DVD, etc) y donde no existe salida a Internet, ¿dónde está la criticidad? En ningún sitio.

Sin embargo, si es un navegador de usuario doméstico o profesional, existiendo salida a Internet y acceso a correo electrónico, sin presencia de medidas de protección, así como una fuerte interrelación con otras aplicaciones en la red, el riesgo sí puede considerarse como muy elevado. Entre ambos extremos, imaginaos la cantidad de supuestos que pueden existir.

Ejemplo 2

Título: IBM Tivoli Access Manager WebSEAL Denial of Service Vulnerability (25 de noviembre de 2008)

Calificación según el boletín: Moderadamente crítico. Razón fundamental, la mezcla de que sea un problema explotable remotamente que puede conducir a una denegación de servicio, y no a un problema de calado mayor (escalada de privilegios, ejecución de código, etc)

Comentarios: ¿Qué sucedería si ese TAM estuviera corriendo frente a una infraestructura crítica de autenticación admitiendo tráfico de Internet (lo habitual en un TAM, por cierto) y denegamos el servicio? Por lo pronto, teniendo en cuenta que estos productos suelen estar instalados en grandes infraestructuras, y habitualmente en servicios financieros, el primer efecto de un DoS en un TAM son los perjucios económicos, así como el daño de imagen y el daño reputacional, con lo que aventurar un problema moderadamente crítico podría hacer que nos quedemos cortos.

¿Y si estuviera en un segmento no accesible directamente por el tráfico de Internet, dando cobertura a una estrategia de autenticación de menor importancia? Poco, o nada. ¿Será siempre algo moderadamente crítico? La respuesta es no.

Ejemplo 3

Título: IBM AIX Multiple Privilege Escalation Vulnerabilities (27 de noviembre de 2008)

Calificación según el boletín: Poco crítico. Explotable localmente, y con posibilidad de escalada de privilegios, condicionada a que el sistema opere en determinadas maneras.

Comentarios: La primera pregunta. ¿Ha visto Usted un AIX en ejecución alguna vez? Como probablemente no lo habrá visto, yo le cuento: es un sistema profesional, propietario, y además de costar un pastón entre sistema y máquina (porque no corre en el PC que tiene en lo alto de la mesa, por desgracia) suele dar servicio, entre otras cosas, a aplicaciones que necesitan servidores Web estáticos y dinámicos que por desgracia, ni son para poner foros, ni fotos de los amiguetes ni musiquita MP3. Corriendo en un AIX es frecuente ver aplicaciones del mundo de seguros y de la banca a distancia, así como aplicaciones financieras no core y/o con datos muy sensibles. En definitiva, una escalada de privilegios, aunque sólo sea local, puede ser dramática dependiendo de dónde corra ese AIX.

¿Y si ese AIX está en una red interna, protegida del tráfico exterior, y su tráfico está convenientemente filtrado, por ejemplo, porque sólo se accede mediante transacciones CICS? Pues la escalada de privilegios deja de tener sentido, porque los accesos que no son CICS los harán los administradores y operadores de las máquinas, que normalmente tienen accesos UID 0. En estos casos, no es de esperar que haya cuentas de usuario susceptibles de atacar el sistema elevando privilegios.

Ejemplo 4

Título: Debian update for amarok (16 de enero de 2009)

Calificación según el boletín: Altamente crítico (acceso ilegítimo al sistema en remoto)

Comentarios: Lo primero es pensar, y darse cuenta de que las probabilidades de encontrarse Amarok corriendo en Debian (siendo la distribución un servidor) son análogas a las de encontrarse Winamp en un servidor Windows: escasas. ¿Que hay gente capaz de todo? Sí. ¿Que hay administradores poco o nada profesionales que tienen 800 paquetes en sus servidores, y sólo usan 50? Sí. ¿Que hay gente que tiene desktops Debian repletos de aplicaciones multimedia? Sí ¿Que la proporción de usuarios desktop en Debian es menor que la de usuarios profesionales? Probablemente. ¿Que lo normal es que alguien que sabe instalar Debian para usarlo de servidor no tenga instalado Amarok ni ninguna otra aplicación de escritorio? También.

Algunas conclusiones

1. Los boletines son útiles y necesarios para administrar la seguridad, pero es absolutamente necesario contextualizar la problemática en el despliegue particular que tengamos. Si no sabemos traducir las problemáticas abstractas de un aviso en los riesgos reales de una instalación, mejor que nos dediquemos a otra cosa. Asumir que el riesgo particular de una instalación es el que marca un boletín es un tremendo error.
2. Los boletines no son mandatos de seguridad, sino consejos de seguridad. Antes de instalar un parche hay que estudiar el caso con calma, y determinar los riesgos reales para nuestra instalación, no sólo los que puede explotar el problema de seguridad, sino la estrategia de aplicación de parches que puede llevar asociada (especialmente, en términos de incompatibilidad entre productos). Incluso en el caso de un usuario doméstico, tampoco deben ser entendidos como mandatos. Si ha aparecido un problema crítico en el Net Framework y yo no lo tengo instalado, ¿qué urgencia tengo en aplicar parche alguno?
3. Por último, y tal y como indica el título de este pequeño artículo, Boletines de seguridad != gestión de seguridad. Ni la gestión de parches es la gestión de cambios, ni la gestión de la seguridad es la gestión de parches. Cada disciplina tiene su ámbito y hay que saber diferenciar bien qué es cada cosa. Si vas a construir la gestión de tu seguridad obedeciendo sólo lo que te llega en forma de boletín, tu estrategia fallará, porque además de los boletines, de los servicios de consultoría y de las buenas prácticas, tu estratregia necesita algo que sólo puedes darle tú: el conocimiento de tu negocio y cómo atender sus riesgos.

Un saludo,