Una debilidad informática de día cero es aquella cuyos detalles han salido a la luz pública y que no cuenta con un parche (una solución por parte del fabricante). No es raro que salgan este tipo de debilidades (Zero Day Initiative nos puede dar un listado de ejemplos o bien eEye).
Cuando sale una de estas vulnerabilidades, las áreas de seguridad en las empresas suben su estado de alerta porque una vez que los detalles de la debilidad se han publicado en internet, puede ser cuestión de horas o días para que salga el exploit (el programa que utiliza esa debilidad contra la aplicación vulnerable). Los exploits más peligrosos son los que toman control remoto del equipo.
Cuando sale una de estas debilidades he visto que se recomienda dejar de usar la aplicación vulnerable. ¿Vale la pena hacerlo? Empecemos estableciendo lo siguiente:
· El software tiene debilidades. No importa si es desarrollado “en casa”, si es software comercial o libre. Salvo que sea el típico “hola mundo”, las aplicaciones desarrolladas en cualquier lenguaje y en cualquier plataforma tendrán vulnerabilidades. Tal vez tenga menos si se sigue una metodología de desarrollo seguro, pero aun así no es garantía (Microsoft sigue una).
· Existen días cero que no han sido descubiertos. Es un error pensar que si no hay debilidades publicadas entonces no están presentes en la aplicación. Bien, seamos claros. En todo momento (ahora mismo) tu software libre y comercial tiene debilidades aún no descubiertas. Lo único que hace falta es que alguien tenga el tiempo, las habilidades y la motivación para hallarlas.
Con los dos hechos anteriormente establecidos, ¿vale la pena seguir la recomendación de dejar de usar una aplicación que tiene un día cero? Hasta el momento no le veo sentido y me gustaría establecer otras dos verdades de las debilidades de día cero:
· Las vulnerabilidades de día cero se usan en ataques dirigidos. Cuando se identifica una de estas debilidades, el descubridor puede usarla o tratar de mantenerla oculta para sacar provecho económico al venderla. Hay buen dinero que se puede obtener. También puede no usarla y optar por avisar al fabricante. Asimismo, cuando finalmente sale a la luz pública normalmente su uso es limitado (en cantidad de afectaciones, no en cuestión de importancia de las víctimas). Luego entonces es poco probable que a ti o a mí nos manden uno de estos ataques con debilidades de día cero.
· Las debilidades que importan son las que se están usando activamente. Puede haber muchas debilidades de día cero (o las que todavía permanecen sin descubrir dentro de un software), pero finalmente importan las que se están usando activamente en ataques en este momento. Brian Krebs lo describe de una mejor manera. En resumen, si no hay un ataque en ejecución asociado a una debilidad de día cero, ¿vale la pena preocuparse? Los de seguridad podrán poner el grito en el cielo “¡pero no tiene parche!” Sin embargo, si bien existe la debilidad, no hay señales de la contra-parte, la amenaza que la usa.
Con esta información arriba descrita y asumiendo que estamos en una corporación con cientos de equipos cliente y partiendo de una administración de riesgos diría que cuando existe una debilidad de día cero se puede seguir usando la aplicación.
Ciertamente, tal vez valga la pena analizar de cerca los “workarounds” que propone el fabricante y ver si se pueden aplicar. Por otro lado, podemos analizar la criticidad real de la debilidad: ¿Permite tomar control remoto? ¿Debe de participar el usuario activamente para que un equipo se comprometa? ¿Se tienen controles que actualmente mitigan el riesgo? ¿Se puede poner ahorita un control compensatorio? Todo antes de sugerir dejar de usar esa aplicación vulnerable.
La verdad sea dicha, ante una debilidad de día cero, uno como usuario en casa podría dejar de usar el PowerPoint y mejor usar Keynote por un tiempo, pero en un corporativo con cientos de clientes ese escenario es verdaderamente muy poco práctico y se tendría que justificar muy bien. En la mayoría de las ocasiones, tal vez sea injustificable.
Nuestra preocupación ante una debilidad de día cero tal vez disminuya si tenemos por ejemplo: un buen análisis de riesgos, pentests frecuentes, detección y respuesta a incidentes, nos enfocamos en las generalidades y no en particularidades de un ataque con exploits, contamos con la llamada defense in depth y partimos de un modelo de amenazas.
La verdad sea dicha, la gran mayoría de las intrusiones (que se basan en explotar debilidades) echan mano de vulnerabilidades ya publicadas y con parche, no de día cero. Mejor primero preocupémonos por mantener actualizado todo el software de la infraestructura que ya cuenta con parches.
@FaustoCepeda
Fausto Cepeda es ingeniero en Sistemas Computacionales por el ITESM. Es Maestro de Seguridad de la Información por la Universidad de Londres (Royal Holloway). Actualmente labora en la Oficina de Seguridad Informática del Banco de México. También cuenta con las certificaciones de seguridad CISSP, CISA, CISM y CEH.