Sobre la última vulnerabilidad crítica de Microsoft (parche MS08-067) ¿Hora de cambiar el mensaje?

Hola,

He preferido esperarme un poco a la hora de hablar de este problema, por eso de tener las cosas claras, y es que cuando salen parches inesperados sin detalles, es mejor esperar y ser prudentes antes de opinar, porque de lo contrario es probable que entremos en la especulación. Es siempre preferible esperar actualizaciones en la información cuando se va a opinar de asustos como el que nos ocupa. Esta lección me la apunto para mí también, porque yo soy el primero que a veces ha opinado sin que estuvieran todos los detalles en lo alto de la mesa, y esto puede tener efectos adversos, sobre todo en los que llegan a la información que publicas.

El pasado 23 de octubre, tan pronto estuvo disponible, Microsoft emitió un boletín de seguridad fuera de su ciclo habitual de actualizaciones: Microsoft Security Bulletin MS08-067 – Critical – Vulnerability in Server Service Could Allow Remote Code Execution (958644), cuya aparición se desveló en un aviso previo, en el que poco o nada se decía.

Efectivamente, el día 23 apareció este parche, y así lo hizo saber el fabricante. En este comunicado se confirmaba que el problema afecta a todas las versiones de Windows en soporte, indicando que era de carácter critico para todas las versiones con la excepción de Vista y «otras versiones nuevas». El carácter crítico no lo discute nadie: hablamos de ejecución remota de código en algo tan básico como el servicio server de Windows. El resumen de impactos es el que sigue:

Versiones con afectación catalogada como crítica

Microsoft Windows 2000 Service Pack 4
Windows XP Service Pack 2
Windows XP Service Pack 3
Windows XP Professional x64 Edition
Windows XP Professional x64 Edition Service Pack 2
Windows Server 2003 Service Pack 1
Windows Server 2003 Service Pack 2
Windows Server 2003 x64 Edition
Windows Server 2003 x64 Edition Service Pack 2
Windows Server 2003 with SP1 for Itanium-based Systems
Windows Server 2003 with SP2 for Itanium-based Systems

Versiones con afectación catalogada como importante

Windows Vista and Windows Vista Service Pack 1
Windows Vista x64 Edition and Windows Vista x64 Edition Service Pack 1
Windows Server 2008 for 32-bit Systems*
Windows Server 2008 for x64-based Systems*
Windows Server 2008 for Itanium-based Systems

¿Hora de cambiar el mensaje?

En seguridad es frecuente que los que nos dedicamos a escribir sobre estos temas, que somos muchos, nos limitemos a hacer descripcones técnicas de los incidentes. Por ejemplo:

Le informo que el parche MS08-067, que solventa una vulnerabilidad en el Server Service de las versiones en soporte declaradas el ciclo de vida de Microsoft Windows, ha sido liberado fuera del ciclo de actualizaciones, con lo que, dada su gravedad, la recomendación es que actualice de manera urgente. La vulnerabilidad, caso de ser explotada, facilitaría una posible ejecución remota de código.

Esta información es suficiente para un técnico o un usuario con cierto conocimiento, pero os invito a que hagáis una prueba con vuestros allegados, a ver quién, después de escuchar un discurso similar, sabe resumir qué pasa, si es o no es un problema, cuáles son las acciones a tomar y porqué hay que tomarlas. Creo que todos coincidiremos que esta información es insuficiente e inútil para la amplia mayoría de la ciudadanía, porque el usuario medio ni sabe lo que es ejecución remota, ni lo que es el servicio server de Windows, ni sabe discernir entre lo que es crítico, importante o poco relevante en el ámbito de la seguridad, ni qué es el ciclo de vida de Microsoft, etc. De hecho, muchos ni sabrán si tienen instalado un Service Pack 2 o un Service Pack 3, ni lo que es un Service Pack, o si su sistema es o no es x64.

La información que realmente importa en este asunto es que esta vulnerabilidad, como reconoce el mismo fabricante, se descubrió como parte de un proceso de investigación en series limitadas de malware especializado orientado a Windows XP. Durante unas dos semanas (nos remontamos a la semana del 8 de octubre) los técnicos de Microsoft estuvieron, como es normal y lógico, analizando el tema. Habían descubierto malware (TrojanSpy:Win32/Gimmiv.A y TrojanSpy:Win32/Gimmiv.A.dll) que explotaba una vulnerabilidad que no conocían, y que por ende, se investigó, disparando un proceso de gestión de incidencias que internamente denominan Software Security Incident Response Process (SSIRP).

Según este proceso, se determinó que la vulnerabilidad era potencialmente «wormable«, es decir, diseminable masivamente sin intervención del usuario, al igual que sucede con los gusanos, lo cual es sin duda preocupante. Por otro lado, como es normal, el fabricante orientó la producción de un parche corrector a la distribución masiva, rápida y que no ocasionase problemas a la clientela, lo que llevó a acelerar el proceso y no esperar al ciclo de actualizaciones de Noviembre. Una actitud responsable, sin duda alguna, acompañada de otra actitud igualmente responsable, consistente en la notificación a los partners de los hallazgos y las firmas empleadas para detectar esa nueva amenaza.

Riesgos reales

He echado muy en falta que este problema no haya sido orientado al riego real, y ese no es poder sufrir una ejecución remota de código. El riesgo real para mí es que este problema puede conducir a que el crimen organizado tome control de nuestras máquinas para sostener actividades criminales. En definitiva, que nuestros recursos (nuestro PC, nuestra ADSL, la electricidad que pagamos mes a mes) sirvan para cometer delitos, sin nuestro consentimiento, y sin nuestro consentimiento.

Si hay que señalar a culpables, que sea a quienes investigan estas cosas no por afición, o por colaborar con los fabricantes, sino con fines criminales. Yo en este caso no tengo nada que objetar respecto a la actuación del fabricante, que ha dispuesto todos los medios a su alcance para atender a su clientela, siendo todo lo diligentes y responsables a la hora de emitir un parche necesario, pero que de hacerlo mal, podría afectar a muchas personas.

Desde webcasts, a la información sobre la importancia de ir de la mano de sus partners, así como de los programas activos de Microsoft para solventar problemas, o de la importancia de ser prácticos hablando de impactos en estas materias, ofreciendo información detallada y medios para protegerse.

¿Pero qué ha sido del malware que ha provocado este jaleo? ¿Y de la posibilidad de que se esté explotando el problema desde hace semanas? ¿Y de las probabilidades de que otras vulnerabilidades no conocidas, similares a la descrita, estén siendo explotadas en la actualidad?

¿Por que no se ha remarcado o enfatizado que la vulnerabilidad se ha descubierto viendo lo que hace un juego de malware? Es decir, que todo esto se ha descubierto porque unos atacantes se han inventado una manera de explotar millones de máquinas, y la han empaquetado el método en un juego de troyanos, que una vez distribuido, ha llegado a las manos de quienes velan por la seguridad de una plataforma desembocando en acciones de mitigación del problema.

Pero, ¿cuántas máquinas han podido recibir ese malware antes de la aparición del parche? ¿Cuáles son los detalles que nos permiten saber qué hacen y cómo lo hacen esos troyanos? ¿Son pruebas de concepto? ¿Es malware consolidado? Vaya usted a saber …

Soy usuario doméstico de Windows. ¿Qué hago?

1. Actualice el sistema.
2. Compruebe si está infectado (desconozco qué antivirus aparte del propio de Microsoft detectan y solventan la amenaza)
3. Actuar sobre la infección, si existe. Si tiene dudas, acuda al fabricante.

Soy usuario profesional de Windows. ¿Qué hago?

1. Diríjase al fabricante.
2. Adopte con su ayuda una estrategia de gestión de incidentes específica para el caso.
3. Actúe en función a la estrategia definida en el paso anterior.

Blogs del fabricante que tratan estas temáticas

Os dejo algunos enlaces útiles del mismo fabricante, para poder tener más información sobre vulnerabilidades en plataformas Windows. Son los siguientes:

The Microsoft Security Response Center (MSRC)
MSRC Ecosystem Strategy Team
Security Vulnerability Research & Defense
Microsoft Malware Protection Center

Un saludo,

10 errores frecuentes en la gestión de actualizaciones de seguridad

Hola,

Me ha lanzado Juan Antonio Auñón (un saludo) una pregunta por correo, en la que me viene a consultar por servicios de alertas de seguridad. Juan Antonio está evaluando las distintas soluciones que hay en el mercado, y me preguntaba qué pienso yo de las mismas. Le he comentado que si le importa que le mencione, y que abramos el debate a los lectores del blog, para lo que me ha dado su consentimiento.

A Juan Antonio ya le he dado respuesta, y no ha descubierto nada nuevo. Lo que hay es lo que hay, y todos los que nos movemos en este mundillo conocemos más o menos qué ofrecen las empresas, qué costes suele acarrear y qué nos ofrece cada servicio. No voy a entrar si es mejor Secunia, o si es mejor tirar del SANS, Security Focus, Secwatch, Securiteam, FrSIRT o los gestores de actualización inherentes a las aplicaciones o a los sistemas operativos. El objetivo de este artículo lo vamos a dirigir a repasar conceptos y a enumerar una serie de errores frecuentes cuando se realizan actividades de actualización en las plataformas que dan servicio a las operaciones de una empresa.

El debate lo vamos a centrar en lo que suelen ser los errores típicos en este tipo de actividades. Tirando un poco de la teoría, creo que todos estamos de acuerdo que los servicios de alertas son una parte importante de lo que se viene a llamar gestión de las actualizaciones, o patch management si preferís la terminología inglesa. Si tenemos que ir mejorando gradualmente la seguridad de un servicio, a medida que se van descubriendo vulnerabilidades, lo primero es enterarnos bien sobre el problema de seguridad que sufre o puede sufrir, para posteriormente tomar las oportunas medidas. Es aquí donde un servicio de alertas juega un rol importante, avisando al usuario de la existencia de un problema.

Volvemos a tirar de la teoría, para recordar que el patch management no es una actividad de gestión por sí misma, sino que debe estar integrada en un concepto mayor llamado gestión del cambio, que incluye no sólo los cambios que hay que hacer a los programas y servicios por cuestiones de seguridad, sino en general, aquellas transformaciones necesarias para dar cobertura al normal desenvolvimiento de un negocio determinado. La gestión de las actualizaciones ni tan siquiera es siempre un proceso orientado a las fallas de seguridad, ya que los parches pueden estar orientados a dotar de nuevas funcionalidades a un aplicativo o sistema operativo.

Por poner un ejemplo fácil, instalar un parche de seguridad para Microsoft Word es en sí gestionar las actualizaciones, pero a su vez también es gestionar el cambio, ya que a fin de cuentas, hay una transformación en ese componente de la suite de productividad Microsoft Office. Ni qué decir tiene que si el parche se ha generado para dotar de nuevas funcionalidades al programa, incorporando por ejemplo una nueva barra de herramientas, o un traductor de formatos, es aún más claro que hay cambios que son ajenos, en principio, a la seguridad, pero que no dejan de ser cambios en el aplicativo.

Repasemos los errores típicos cuando se realizan actividades de este tipo. Estos errores no tienen por qué ser los únicos, ni están ordenados por relevancia o probabilidad de ocurrencia. La amalgama de sucesos es amplia, y no suele haber patrones de ordenación claros, pero es posible que estos diez conceptos resuman la problemática más habitual y frecuente en los procesos de gestión de las actualizaciones.

  1. El primer error es precisamente en lo que hemos comentado anteriormente. Considerar la gestión de atualizaciones como un proceso independiente, fuera de la gestión de cambios, es el primer y más importante error que podemos comenter al gobernar la tecnología. Los parches SIEMPRE incluyen cambios, y por tanto, hay que evaluar adecuadamente los impactos que éstos pueden ocasionar a la producción de la empresa. Instalar un parche y mirar para otro lado sin pensar en qué implicaciones puede tener es una práctica poco o nada recomendable, y que puede conducir a efectos indeseados con un elevado impacto en las operaciones.
  2. Inundación de información. son muchos los servicios que proporcionan información sobre actualizaciones de seguridad, y dar seguimiento a todos es costoso y puede provocar que el tiempo de reacción se prolongue demasiado en el tiempo. Hay que saber elegir bien nuestras fuentes, en función de nuestros requisitos, para poder así optimizar el tiempo que dedicamos a la investigación y análisis. Es mejor basarse en un único servicio fiable que en varios servicios dudosos.
  3. Información insuficiente y/o servida en plazos temporales inadecuados. Este problema consiste en disponer únicamente de un aviso que nos dice, en líneas muy generales, de qué va el problema, qué versiones están afectadas, y cuáles son las fuentes de las que podemos obtener el parche. Surge aquí la corriente que dice que una cosa es el aviso, y que luego la empresa debe evaluar el despliegue en sus propios laboratorios empleando sus propios medios. Sin quitar razón a este planteamiento, que es válido y extendido, yo sin embargo apoyo la teoría de que un servicio de avisos de seguridad sólo es excelente si hay un equipo detrás que soporta todo el proceso, evaluando mano a mano con el destinatario de las transformaciones los impactos, diseñando la estrategia de despliegue y soportando el seguimiento posterior a los cambios. Respecto a los plazos temporales, qué duda cabe que las alertas debemos recibirlas (si proceden de fuera) o recabarlas (si gestionamos internamente su seguimiento) en tiempo y forma, ya que los tiempos de reacción pueden ser cruciales, especialmente en ataques 0 day con exploits públicos, y donde el tiempo de reacción es crítico para salvaguardar en el menor plazo los activos de información que puedan quedar comprometidos como consecuencia de un problema de seguridad.
  4. Aplicación indiscriminada de parches. Es un error derivado de las prácticas domésticas, donde la producción suele consistir en un único terminal sin relación con otros servicios o máquinas, y donde instalar todos los parches que se nos ofrecen no suele provocar problemas. En un entorno multiplataforma, aplicar indiscriminadamente todos los parches que nos sugieren los servicios de actualización es una práctica suicida que puede provocar problemas críticos de funcionamiento y rendimiento: consumo excesivo de tiempo, problemas de almacenamiento, aumento de gasto de CPU e impacto en el ancho de banda son sólo algunos ejemplos.
  5. Análisis de impacto incompletos. Los análisis de impacto tienen que contener las probabilidades, los medios de impacto y lo que es más importante: una traducción económica de los mismos. Si consideramos que un problema de seguridad tiene una solución cuyo coste es superior a los problemas que puede desencadenar, estamos perdiendo el tiempo considerando esa actualización. Traducir a términos económicos es complejo y requiere tiempo, con lo que debe reservarse para problemas críticos o muy críticos, y no para asuntos menores que estén acotados, cuyas decisiones son más fáciles de tomar.
  6. Ausencia de estrategias de despliegue. Cuando se parchea un equipo, la estrategia es clara, pero cuando hay que parchear 100.000 terminales, la cosa cambia. El ancho de banda, la disponibilidad, la continuidad de las operaciones, los impactos cruzados entre equipos … son muchos los factores que hacen obligatoria la presencia de una estrategia de despliegue de las actualizaciones. Es absurdo considerar estrategias manuales, donde sólo conseguiremos incrementar el riesgo de error derivado de la intervención humana. Normalmente será automática, y convenientemente priorizada para cubrir los riesgos más importantes en el menor plazo de tiempo, así como respetar las secuencias de actualización requeridas en cada caso.
  7. Ausencia de estrategias de rollback. Bien podría ser parte del punto anterior, aunque conviene diferenciarlo para hacer hincapié en la importancia de este aspecto. Sin un plan de reversión, los errores inesperados y/o no previstos que no puedan resolverse cómodamente tras los cambios resultan mortales de necesidad. Hay que tener un as en la manga, y ese no es otro que una estrategia de recuperación para volver al punto estable inmediatamente anterior a los cambios.
  8. Ausencia de planes de pruebas. Este concepto también lo podríamos ligar a la estrategia de despliegue, aunque por su importancia, lo comentamos también en un punto diferenciado. Los parches y los cambios en general pueden impactar, y de hecho, impactan gravemente en la producción. Siempre deben ser probados en el laboratorio, por inocuos que parezcan, aún a sabiendas de que los principales fabricantes someten a pruebas exhaustivas los parches antes de liberarlos. Los fabricantes tratarán siempre de maximizar el espectro de las pruebas, pero nunca podrán simular una producción real compleja, ya que las particularizaciones suelen ser abundantes y condicionadas igualmente por la presencia de productos propios interrelacionados con las plataformas y programas a parchear. Una vez evaluado el impacto, se decide sobre el despliegue, nunca antes. Cambiar programas conlleva siempre riesgos que deben ser considerados y evaluados, para poder decidir adecuadamente qué hacer, y cómo hacerlo. Con relación a las pruebas posteriores, convocar al usuario final para que certifique la idoneidad de un cambio es siempre una buena práctica, aunque hay que ser hábiles seleccionando qué se prueba, ya que, obviamente, es inviable probar todos los cambios, especialmente aquellos que son transparentes al usuario final.
  9. Ausencia de conocimiento técnico suficiente. No hay nada más peligroso que actualizar una plataforma sin saber qué cambios induce, y en qué consisten los cambios. Este tipo de errores es crítico, y hace absolutamente imprescindible conocer al más mínimo detalle la actividad del parche a instalar. Aquí enlazamos con lo expuesto al principio, ¿de qué sirve un aviso de seguridad que se limita a describir el problema sucintamente, y que sólo me dice qué plataformas o versiones están afectas? Al igual que al ingerir un medicamento existe (si hay exigencia de receta, obviamente) una prescripción médica previa, y un laboratorio farmacéutico nos informa de la posología, efectos secundarios, y en general, toda la información que aparece en el prospecto, cuando desplegamos un parche importante y no trivial, lo normal es que esté prescrito por un profesional que ha considerado y conoce bien la totalidad de condiciones de contorno e implicaciones de implantar una transformación determinada. En estos términos, los parches abiertos proporcionan una ventaja consistente en poder interpretar el código, y así facilitar la comprensión del cambio propuesto, llegando incluso a modificarlo si fuera necesario.
  10. Por último, y no por ello menos importante, comentar que la gestión de cambios debe ser integral, especialmente en todo aquello que tiene que ver con la interrelación de áreas involucradas. Ya no es sólo una cuestión de que el servicio de seguridad interno o externo que nos suministra la información y la organización hablen sobre cómo conviene aplicar los parches, sino que internamente, hay áreas que deben conocer los cambios para poder así planificar adecuadamente la producción, reservando espacios de tiempo para los cambios, especialmente en sistemas centrales que están en continuo funcionamiento y sometidos a múltiples modificaciones planificadas. Otras áreas, como la de continuidad, agradecerán recibir información sobre los cambios, por si éstos requieren cambios en la infraestructura o en los procedimientos de recuperación. Las áreas de diseño siempre verán con buenos ojos estar informados sobre los cambios, en caso que haya que modificar las especificaciones de un producto o desarrollo relacionado con aquello que estemos parcheando. En definitiva, constituir un comité de cambios con la representación adecuada es algo más que necesario, y otorga claridad, calidad y eficiencia a los procesos de transformación.

Espero que estos consejos os resulten de utilidad. Un saludo ;)