¿Vivir con los Workarounds? Not.

¿Esperan los fabricantes de software que sigamos cada uno de sus workarounds para las vulnerabilidades de día cero? Debe de ser una mala broma.

Tenemos una debilidad de día cero en una aplicación o sistema operativo; esas que tanto nos gustan donde no hay parche que le dé solución y en la cual simplemente nos tenemos que aguantar…o comernos un sabroso workaround que es una medida temporal para evitar un ataque (esto claro, siempre y cuando el fabricante de software se “digne” siquiera a publicar un workaround; hay casos en donde simplemente hay que esperar el parche y uno mismo tiene que ideárselas para tratar de evitar el ataque).

En fin, podríamos pensar que los “workarounds” son los buenos de la película, ya que una vez que hay un defecto en el software, el buen fabricante nos propone esta medida alterna para ser aplicada y evitar un ataque a la falla. ¿Qué puede haber de malo en eso?

Si tuvieras días cero de vez en cuando y si tuvieras pocas aplicaciones en un solo sistema operativo, no tendría casi ninguna queja. Sin embargo eso no es la realidad ni para un usuario en casa y menos para una empresa donde al menos existe un sistema operativo (dije: al menos) y hay cientos de aplicaciones.

Tal vez para un usuario en casa aplicar workarounds no sea del todo fastidioso (aún así, cuántos usuarios en casa lo hacen?), pero aplicar un workaround en una organización no es de “enchílame éstas”. Hay que probar estos workarounds para ver que no afecten gachamente la operación, posteriormente aplicar progresivamente el dichoso workaround en todas las computadoras (efectivamente, algunos pocos workarounds se pueden aplicar en controles perimetrales). Luego cuando sale el parche conviene hacerle “undo” al workaround.

Y siendo sinceros, varios de esos dichosos workarounds son peor que el exploit, por decirlo de alguna manera. Para los que los hemos tratado de aplicar, finalmente te das cuenta de que se pierde tanta funcionalidad que es mejor olvidarlos. Tendrías a N usuarios llamándote para ver por qué diablos no pueden ver páginas web normalmente o una imagen en un documento. Ah sí, cuando bien te va; una vez me tocó un workaround que al cambiar una llave del registro salía la pantalla azul de la muerte en Windows.

Seguirle el paso a los workarounds de los día cero (ubicar-> probar-> implementar-> undo cuando salga el parche) del software en una empresa es un dolor de cabeza (y fui amable). Que levante la mano el que ha implementado todos los workarounds de los días cero del 2010 al menos para el software de Microsoft y de Adobe. Sí, debe de ser una broma.

¿Qué puedes hacer? Volverte esclavo de los workarounds o tener controles preventivos: una buena hardenización, un IPS personal y un sandbox, por poner unos ejemplos. Otra medida es analizar primero si la debilidad de día cero realmente te afecta y por otro lado ver si no tienes ya controles que mitiguen el riesgo para poder olvidarte del workaround hasta que salga el parche.

Seamos sinceros, no vas a aplicar todos los workarounds habidos y por haber (y créeme, no te culpo), así es que debes de pensar en una estrategia que te permita sobrevivir a los día cero…y a sus workarounds.

Nota: Las debilidades de día cero y sus workarounds están a la orden del día. Por poner sólo un ejemplo, entre el 14 de diciembre y el 5 de enero, salieron 4 debilidades de día cero sólo para Microsoft. Al día 9 de enero siguen sin parche. Y para varias de ellas se proponen workarounds. Checa lo que implican. Y como ejercicio, durante el 2011 ve cuántos workarounds te estarán proponiendo los fabricantes y checa cuántos de ellos puedes implementar sin problema.