Vicarius - "Protecciones sin Parches"

“Patch Tuesday” es un término ampliamente utilizado entre los equipos de seguridad y TI para describir el momento en que Microsoft lanza las últimas actualizaciones. Quienes participan en él conocen el costo real del ciclo de parcheo, ya sea para 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 lo son suelen desencadenar un ciclo de parcheo. ¿Cómo surgen los parches de seguridad? ¿Y por qué con tanta frecuencia?

El aumento de las vulnerabilidades y las nuevas técnicas para identificar problemas de seguridad a escala dan como resultado un aumento de los parches de seguridad que los proveedores se ven obligados a publicar. Se diseñó un proceso de divulgación responsable para garantizar que los proveedores tengan la oportunidad de solucionar el problema antes de que los piratas informáticos se aprovechen de él. Un investigador de seguridad que descubrió un defecto podría informarlo al proveedor antes de que se utilice incorrectamente.

Una vez informado, el proveedor debe validar la falla (generalmente reproduciéndola), identificar el código inseguro, corregirlo y lanzar una actualización nueva y (con suerte) segura. Esta actualización segura, también conocida como parche, debe implementarse dondequiera que resida la versión vulnerable.

Si bien algunos proveedores responden rápidamente a las amenazas reveladas, otros muestran una respuesta tardía e incluso retiran algunas de sus versiones y afirman que ya no se mantienen. Suponiendo que el proveedor sea responsable y que se mantenga la versión, se estima que el tiempo medio de aplicación del parche durará entre 2 y 5 meses. Esta brecha deja a las empresas expuestas a vulnerabilidades conocidas.

A lo largo de este blog exploraremos varias formas de cerrar esta exposición y reducir el riesgo de explotación.

PRELANZAMIENTO: (PAUTAS DE DESARROLLO)

Hay muchas formas en que un proveedor puede hacer que su software sea más seguro. Seguir pautas sencillas en el proceso de desarrollo puede ayudar. Cuando el software interactúa con el mundo, todas las entradas externas deben validarse. Verificar que la entrada recibida coincide con el patrón de entrada esperado puede limitar la cantidad de ataques que explotan problemas internos en el software. Las pruebas exhaustivas del producto en varios escenarios pueden detectar problemas que no aparecen a primera vista. El uso de análisis de código estático puede proporcionar una entrada que apunta a áreas problemáticas del código. Al usar bibliotecas externas es importante usar bibliotecas probadas y confiables, y es aún más importante si se usa para criptografía.

COMPILACIÓN ASEGURADA

Un área en la que los proveedores pueden concentrarse es el proceso de compilación. Por ejemplo, los exploits que abusan del desbordamiento de la pila podrían prevenirse potencialmente utilizando Stack canaries. Otro ejemplo es el bloqueo de exploits que se basan en modificar la tabla de compensación global (GOT) con la habilitación de RELRO. Cuando RELRO está habilitado, todas las entradas en GOT se resuelven al inicio de la aplicación. A partir de ahí, el GOT está configurado para ser de solo lectura en lugar de la población perezosa predeterminada del GOT. Aunque estas características de seguridad se pueden agregar fácilmente, muchos proveedores aún optan por no habilitarlas durante la compilación.

POSTERIORES A LA LIBERACIÓN:

Incluso si un proveedor siguió las pautas de desarrollo seguro y habilitó todas las funciones de seguridad durante la compilación, no garantiza que el software sea seguro. Todos los días se descubren nuevas vulnerabilidades, y siempre se encuentran nuevas técnicas para atacar activos digitales en una batalla interminable entre atacantes y defensores.

Cuando se descubre una nueva vulnerabilidad y se informa al proveedor, comienza el ciclo de parches (como se describió anteriormente). Pero es demasiado largo. Mientras esperamos que se publique 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. Aun así, no podemos permitirnos dejar estos entornos vulnerables.

¿Qué se puede hacer? Revisemos algunas formas nuevas de proteger nuestros entornos de las vulnerabilidades.

PROTECCIÓN DE LA RED

Muchas empresas enrutan todo el tráfico entrante a través de un firewall con estado, que a veces se mejora con capacidades 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 acceda sin restricciones. Sin embargo, existen deficiencias. Un patrón faltante, un falso positivo o una identificación falsamente negativa pueden resultar en la interrupción de los servicios a empresas de todo el mundo.

FUNCIONES DE PROTECCIÓN DEL SISTEMA OPERATIVO

Otra opción posterior al lanzamiento es utilizar las funciones de seguridad nativas del sistema operativo. Los sistemas operativos modernos ofrecen funciones para ejecutar aplicaciones con ciertas limitaciones. Bajo estas limitaciones, incluso un exploit exitoso puede verse limitado para obtener acceso a otros recursos en el activo u otros dispositivos en la red (por ejemplo, permisos insuficientes, modo de ejecución del proceso, etc.). Otra táctica es usar ASLR para evitar que un atacante sepa de manera confiable dónde se encuentra exactamente un recurso específico en la memoria de una aplicación, lo que hace que la aplicación sea más difícil de explotar.

PROTECCIÓN EN MEMORIA

Existen soluciones de seguridad que ofrecen parches para vulnerabilidades específicas fuera del ciclo de desarrollo del proveedor. En lugar de volver a compilar los binarios, el parche se inyecta en la aplicación vulnerable, cambiando su comportamiento. Después de aplicar este tipo de parche, la aplicación seguirá ejecutándose, pero ya no será vulnerable a esa amenaza específica. Las principales ventajas de este tipo de parche es que la aplicación parcheada está protegida sin modificaciones permanentes y no es necesario reiniciar la aplicación. Además, muchos parches incluyen tanto actualizaciones de seguridad como nuevas funciones que pueden alterar el comportamiento de la aplicación y provocar problemas de interoperabilidad.

La misma idea de inyectar un parche en una aplicación en ejecución también existe en un conjunto diferente de soluciones de seguridad. En estas soluciones se analiza la aplicación y se genera y prioriza una lista de posibles vulnerabilidades y parches apropiados utilizando varios algoritmos. Los algoritmos toman en consideración el entorno en el que se ejecuta una aplicación y crean parches para vulnerabilidades explotables. Los parches que no son necesarios se ignoran. Solo se implementan los cambios mínimos necesarios para hacer que las aplicaciones sean seguras. Además, la investigación y el conocimiento adquiridos para un tipo de vulnerabilidad se transfieren automáticamente a otras aplicaciones con características similares, ofreciendo así protección a algunas vulnerabilidades antes de que se conozcan públicamente.

MANTENERSE POR DELANTE DE LA CURVA

Las estadísticas muestran que el 60% de las infracciones relacionadas con vulnerabilidades podrían haberse evitado con el parche adecuado. Pero los equipos de seguridad tienen dificultades para realizar un seguimiento de los importantes. Agregue a eso el estrés del tiempo de inactividad y las interrupciones ocasionadas. Parchear no es un picnic. Es una carga pesada de soportar.

Ha surgido una nueva generación de tecnologías del laboratorio de Vicarius para evitar la explotación sin cambiar los archivos binarios en el disco. TOPIA aplica parches virtuales en memoria que mitigan la explotación. Una vez que el administrador del sistema define una política, la aplicación vulnerable está protegida en el nivel de la memoria, tanto externa como internamente. Aprovecha varias técnicas de protección de la memoria, incluida la instrumentación binaria dinámica (DBI).

Según la política definida, cuando un intento de explotación activa una de las capas de protección, la capa correspondiente lo registrará o lo evitará. El mecanismo de protección bloquea la llamada al sistema malicioso, deteniendo el intento de explotación.

En el tablero, el administrador del sistema puede revisar el intento, el origen, el objetivo y otra información que puede ser útil para una investigación más profunda.

Adelante, aligera tu carga. No es necesario que lleve la carga de los parches solo.