España
Reino Unido
Italia
Portugal
Autor/a: David Asraf, Software Developer en Vicarius
“Patch Tuesday o martes de parches” es un término ampliamente utilizado entre los equipos de TI y de seguridad para describir el momento en el que Microsoft publica las últimas actualizaciones. Los que participan en él conocen el verdadero coste del ciclo de parches, ya sea obtener la aprobación, diseñar el plan o lidiar con el resultado.
No todos los parches están relacionados con la seguridad, pero los que sí suelen desencadenar un ciclo de parches. En este sentido, ¿cómo surgen los parches de seguridad? ¿Por qué son tan frecuentes?
El aumento de vulnerabilidades y las nuevas técnicas para identificar los problemas de seguridad a escala provocan un incremento de parches de seguridad que los fabricantes se ven obligados a lanzar. Por este motivo, se diseñó un proceso de divulgación responsable para asegurar que los fabricantes tengan la oportunidad de solucionar el problema antes de que los ciberdelincuentes se aprovechen de ello.
Una vez informado, el fabricante debe validar el fallo (generalmente reproduciéndolo), identificar el código inseguro, arreglarlo y publicar una actualización nueva y (con suerte) segura. Esta actualización de seguridad –conocido como parche– debe ser desplegada dondequiera que resida la versión vulnerable.
Mientras que algunos fabricantes responden rápidamente a las amenazas reveladas, otros muestran una respuesta tardía e incluso retiran algunas de sus versiones, diciendo que ya no continúan con su mantenimiento. Se estima que los fabricantes tardan en parchear de media de 2 a 5 meses, durante este tiempo las empresas están expuestas a vulnerabilidades conocidas.
En este blog, exploraremos varias formas de evitar esta exposición y reducir el riesgo de una explotación.
Hay muchas maneras de que un fabricante pueda desarrollar un software más seguro. Seguir unas simples directrices en el proceso de desarrollo puede ayudar en este sentido. Cuando el software interactúa con el mundo, todos los inputs externos deben ser validados. Comprobar que el input recibido coincide con el input esperado puede limitar la cantidad de ataques que explotan los problemas internos del software.
Las pruebas exhaustivas del producto en diversos escenarios pueden detectar problemas que no aparecen a simple vista. Usar un análisis de código estático puede proporcionar un input que apunte a áreas problemáticas en el código. Cuando se utilizan librerías externas, es importante usar librerías probadas y más importante aún si se utiliza para la criptografía.
Un área en la que los fabricantes pueden focalizarse es el proceso de compilación. Por ejemplo, los exploits que abusan del desbordamiento de pilas podrían evitarse potencialmente utilizando stack canaries. Otro ejemplo es el bloqueo de exploits que se basa en modificar la tabla de compensación global (GOT, por sus siglas en inglés) con la habilitación del RELRO. Cuando RELRO está habilitado, todas las entradas en GOT se resuelven al inicio de la aplicación. A partir de aquí, GOT se configura para ser de sólo lectura. Aunque estas características de seguridad pueden añadirse fácilmente, muchos fabricantes siguen optando por no habilitarlas durante la compilación.
Incluso si un fabricante siguió estas directrices de desarrollo seguro y permitió todas estas características de seguridad durante la compilación, esto no garantiza que el software sea seguro. Todos los días se descubren nuevas vulnerabilidades y técnicas para atacar a los activos digitales, una batalla interminable entre atacantes y defensores.
Cuando se descubre una vulnerabilidad y se informa al fabricante, comienza el ciclo de parcheado (como se ha descrito anteriormente). Pero es demasiado largo. Mientras esperamos a que se lance un parche, estamos expuestos a ataques que explotan esta vulnerabilidad. En muchos entornos, no es posible parchear todos los productos justo cuando el proveedor los lanza debido a consideraciones comerciales. Aún así, no podemos permitirnos dejar estos entornos vulnerables. Por lo tanto, ¿qué podemos hacer? Repasemos algunas nuevas formas de proteger nuestro entorno de las explotaciones.
Muchas compañías dirigen todo el tráfico de entrada a través de un firewall, que a veces se mejora con capacidades de IPS/DPI. Una de sus técnicas está diseñada para reconocer patrones de ataque y bloquearlos antes de que exploten el activo vulnerable. Este tipo de protección ofrece un gran valor al evitar que el atacante tenga acceso sin restricciones. Sin embargo, hay deficiencias. Un patrón perdido, un falso positive o una identificación negativa falsa puede dar como resultado la interrupción de los servicios de empresas de todo el mundo.
Otra opción de post-lanzamiento es usar características de seguridad nativas de sistemas operativos. Los sistemas operativos modernos ofrecen características para ejecutar aplicaciones con ciertas limitaciones. Bajo estas limitaciones, incluso un exploit exitoso puede verse limitado para acceder a otros recursos u otros dispositivos en la red (por ejemplo, permisos insuficientes, modo de ejecución del proceso, etc.). Otra táctica consiste en utilizar ASLR para impedir que un atacante sepa con certeza dónde se encuentra exactamente un recurso específico en la memoria de una aplicación, lo que hace que ésta sea más difícil de explotar.
Hay soluciones de seguridad que ofrecen parches para vulnerabilidades específicas fuera del ciclo de desarrollo del fabricante. En lugar de recompilar los binarios, el parche se inyecta en la aplicación vulnerable, cambiando el comportamiento de la misma. Después de aplicar este tipo de parche, la aplicación seguirá funcionando, pero ya no será vulnerable a esta amenaza específica. Las principales ventajas de este tipo de parche son que la aplicación parcheada está protegida sin ninguna modificación permanente, además no es necesario reiniciar la aplicación. Asimismo, muchos parches incluyen tanto actualizaciones de seguridad como nuevas características, las cuales pueden alterar el comportamiento de la aplicación y dar lugar a problemas de interoperabilidad.
En esta misma idea de inyectar un parche en una aplicación en ejecución, también existen un conjunto de diferentes soluciones de seguridad. En estas soluciones, se analiza la aplicación y se genera una lista de las posibles vulnerabilidades y parches adecuados, que se priorizan mediante diversos algoritmos. Los algoritmos tienen en cuenta el entorno en el cual se está ejecutando la aplicación y crean parches para las vulnerabilidades explotables. Los parches que no son necesarios, se ignoran.
Sólo se aplican los mínimos cambios requeridos para que las aplicaciones sean seguras. Además, la investigación y el conocimiento adqueridos para un tipo de vulenerabilidad se transfiera automáticamente a otras aplicaciones con características similares, ofreciendo así protección a algunas vulnerabilidades antes de que sean conocidas públicamente.
Las estadísticas muestran que el 60% de las brechas relacionadas con las vulnerabilidades podrían haberse prevenido con el parcheo apropiado. Pero los equipos de seguridad tienen dificultades para hacer un seguimiento de las más importantes. A esto se le suma el estrés por el tiempo de inactividad y las interrupciones causadas. Parchear no es algo liviano, es una carga pesada de soportar.
Vicarius Lab ha desarrollado una nueva generación de tecnología que permite prevenir la explotación sin cambiar los binarios del disco. Su solución TOPIA aplica parches virtuales en la memoria que mitigan la explotación. Una vez que el administrador del sistema define una política, la aplicación vulnerable es protegida a nivel de memoria, tanto externa como internamente. De esta forma, se aprovechan varias técnicas de protección de la memoria, incluyendo la Instrumentación Binaria Dinámica (DBI).
Basándose en una política definida, un intento de explotación desencadena una de las capas de protección, en concreto, la capa relevante lo registrará y lo evitará. Los mecanismos de protección bloquean la llamada del sistema malicioso, deteniendo el intento de explotación.
En el dashboard, el administrador del sistema puede revisar el intento, el origen, el target y otra información que puede ser útil para una mayor investigación.
En el siguiente vídeo, Roi Cohen, VP Sales & Co-Founder de Vicarius, y David Asraf, Software Developer de Vicarius, se unen a Paul para hablar y hacer una demostración sobre Patchless Horseman.
Puede leer el artículo original en la web de Vicarius.