Hojas de trucos de seguridad: parches virtuales

El tema de nuestro artículo de hoy es Virtual Patching.

Virtual Patching es una capa de política de seguridad diseñada para detectar y prevenir la explotación de vulnerabilidades conocidas.

El parche virtual comienza a funcionar después del análisis de tráfico y evita que ingrese tráfico malicioso en la aplicación vulnerable. Por lo tanto, el parche virtual, si corresponde, evita la explotación de la vulnerabilidad sin modificar el código fuente de la aplicación. Por lo general, el parche virtual se implementa en firewalls para aplicaciones web (WAF).

Entonces, ¿por qué parche virtual, por qué no simplemente actualizar el código?

Por supuesto, actualizar el código es la primera solución recomendada, pero no siempre es posible, ya sea por falta de recursos en la organización (todos los desarrolladores ya están ocupados y no se pueden transferir a parches de emergencia), el uso del software de otra persona (¿cómo puedo cambiar el código aquí?) O simplemente necesito reescribir un poco si no toda la aplicación para este parche.
¡Esto no significa que los parches virtuales y la actualización de código sean cosas mutuamente excluyentes! Por lo general, se ejecutan mediante diferentes comandos (en vista de los detalles de estos procesos), de modo que los parches y las actualizaciones pueden ir en paralelo.

Los beneficios del parche virtual son los siguientes:

• Una solución rápida (relativamente) para cerrar la vulnerabilidad hasta que no haya posibilidad de un parche completo.
• Si la aplicación web es su producto, no viola los posibles procesos comerciales existentes, es decir, si el próximo parche para el producto está planeado, por ejemplo, en un mes, entonces no necesita romper el cronograma completo.
• La capacidad de cerrar vulnerabilidades con miembros de otro equipo si los desarrolladores no pueden hacerlo en este momento.
• Puntualidad: si utiliza un software listo para usar, no se sabe cuándo se lanzará el parche para su producto y, por supuesto, no desea dejarlo vulnerable.

Desventajas del parche virtual:

• Esto todavía no es una panacea. Al usarlo, no se pueden cubrir todos los vectores de ataque, por lo que el peligro de operación permanecerá.
• La desventaja de todas las soluciones temporales es la probabilidad de que lo temporal se vuelva permanente. La compañía decidirá que una vez que funcione, ya no lo tocaremos más y dejaremos las cosas como están.
• Esta es una solución complementaria, la vulnerabilidad en sí no desaparece, sino que simplemente se esconde detrás de una capa adicional de protección.

La preparación para el parche virtual se puede dividir en los siguientes pasos:

1. Preparación
2. Identificación de amenazas
3. Análisis
4. Crea un parche virtual
5. Implementación y prueba
6. Recuperación / continuación del trabajo.

Vulnerabilidad pública

Por ejemplo, tome la inyección SQL y ModSecurity WAF (desde código abierto).

WordPress Shopping Cart Plugin  WordPress /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php  reqID   SQL Injection. 

El complemento de carrito de compras de WordPress para WordPress contiene una falla que puede permitir que un atacante ejecute una inyección SQL. El problema radica en el script /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php, en el que el parámetro reqID no se desinfecta correctamente.

Esto puede permitir que un atacante incruste o manipule consultas SQL en el back-end, lo que lleva a la posibilidad de obtener acceso ilegal a los datos, con todas las consecuencias resultantes.

Etapa de preparación

Como en muchos procesos, la preparación para el parche virtual es un componente importante. Antes de lidiar con una vulnerabilidad descubierta (o peor aún con un ataque en tiempo real), debe hacer algunas cosas. El punto de preparación no es comprender frenéticamente durante el ataque cómo funciona el parche virtual y cómo integrar WAF en la infraestructura actual si no está allí, sino tomar ciertas acciones bien pensadas.

Aquí hay algunos puntos críticos que deben ser cubiertos en preparación:

• Supervisión de vulnerabilidades del proveedor o de fuentes públicas: si utiliza software de terceros, asegúrese de estar suscrito a todos los correos de emergencia de los proveedores. Esto lo ayudará a mantenerse actualizado sobre nuevas vulnerabilidades en su software y parches relacionados.
• Prepare todo el trabajo necesario por adelantado para permitir que los parches virtuales entren en producción: los parches virtuales deben integrarse rápidamente, por lo que el proceso de verificación habitual para los parches no funcionará aquí. Como los parches virtuales no cambian el código fuente, no requieren la misma cantidad de pruebas que los parches de software normales. Vale la pena atribuir parches virtuales a la misma categoría que las actualizaciones para antivirus o actualizaciones de firmas para IDS. Esto acelerará significativamente el proceso de implementación en producción.
• Inserte las utilidades para el parche virtual de antemano, ya que el criterio principal para el parche virtual es la velocidad, entonces instalar un nuevo software si necesita un parche de emergencia, por decirlo suavemente, es una mala idea.
• Aumente el registro para sus sistemas: el estándar de registro utilizado por la mayoría de los servidores de forma predeterminada (CLF) no proporciona suficientes datos para responder correctamente a los incidentes. Debe tener acceso a los siguientes datos:
  
  ◦ Solicitar URI (incluido QUERY_STRING)
  ◦ Todos los encabezados de solicitud (incluidas las cookies)
  ◦ Cuerpo de solicitud completo (incluida la carga POST)
  ◦ Encabezados de respuesta completa
  ◦ Cuerpo de respuesta completa

Etapa de detección de amenazas

Esta etapa comienza cuando la organización descubre que hay una vulnerabilidad en su aplicación web. En general, hay dos enfoques diferentes para identificar vulnerabilidades: proactiva y reactiva.

Enfoque proactivo

El caso cuando la organización asume el trabajo de seguridad y realiza las siguientes tareas:

• Evaluación dinámica de la aplicación: se realizan pentests y / o pruebas de evaluación automática en una aplicación web en ejecución para identificar deficiencias.
• Revisión del código fuente: se realiza una evaluación manual y / o automática del código fuente de una aplicación web para detectar deficiencias.

Enfoque reactivo

Existen tres métodos reactivos principales para identificar vulnerabilidades:

• Un mensaje del proveedor: cuando su proveedor de software publica información sobre una vulnerabilidad descubierta.
• La publicación pública es la publicación de una vulnerabilidad descubierta para el software que utiliza en fuentes públicas. En este caso, su respuesta a la vulnerabilidad debería ser más rápida que cuando informa del proveedor, ya que más personas conocen la vulnerabilidad.
• Incidente de seguridad: esto significa que el ataque ya está en progreso. Se requiere una acción inmediata para concretar y cerrar la vulnerabilidad.

Etapa de análisis

Pasos recomendados para la fase de análisis:

• Determine cómo el parcheo virtual es adecuado para su caso: es excelente para cerrar las deficiencias asociadas con la entrada (es decir, la inyección), pero puede no proporcionar un nivel adecuado de protección para ataques de otros tipos o categorías. Se debe llevar a cabo un análisis detallado y exhaustivo del problema subyacente para determinar si el software de parche virtual proporcionará un nivel adecuado de detección y cobertura.
• Involucre a sus sistemas para rastrear errores / tareas: ingrese información de vulnerabilidad en su rastreador para un mayor seguimiento e investigación.
• Verifique la vulnerabilidad: busque el nombre oficial de la vulnerabilidad, si existe. Si fue detectado por métodos proactivos, entonces debe darle su propio número / nombre único.
• Determine el nivel de riesgo: siempre es importante comprender cuán crítico puede ser para usted el impacto de explotar esta vulnerabilidad. Por ejemplo, si será una fuga de información o acceso a la base de datos.
• Determine qué versiones de software están en riesgo: es importante comprender si está en riesgo o no.
• Determine bajo qué configuraciones de software puede surgir un problema: algunas vulnerabilidades pueden aparecer solo con ciertas configuraciones de su software.
• Haga una lista de las vulnerabilidades o cargas de prueba de concepto utilizadas durante el ataque / prueba: muchas publicaciones de vulnerabilidad van acompañadas de un código PoC que demuestra la vulnerabilidad. Si tales datos están disponibles, analícelos. Esto será útil en un mayor desarrollo y prueba de un parche virtual.

Etapa de creación de un parche virtual

El proceso de crear un buen parche virtual está vinculado a dos aspectos:

• Sin falsos positivos: nunca bloquee el tráfico normal a pesar de las circunstancias
• Sin falsos positivos: nunca se pierda un ataque, incluso cuando el atacante intenta deliberadamente evitar ser detectado.

Se deben hacer esfuerzos para minimizar el impacto de ambas reglas. Es posible que no sea posible (lo que ocurre con mayor frecuencia) seguir ambas reglas, pero es importante recordar que el parche virtual se trata de reducir el riesgo.

Creación manual de un parche virtual.
Enfoque positivo (lista blanca, lista blanca) en parche virtual

Este enfoque es crear una validación de entrada independiente para la aplicación web. El enfoque determina las características de los datos válidos (juego de caracteres, longitud, etc.) y prohíbe todo lo que no se ajuste a estas condiciones. Al definir las reglas para cada parámetro en cada página de la aplicación web, envolvemos la aplicación en una capa adicional de protección, independiente de su código fuente.

Un ejemplo de creación de un parche virtual basado en la lista blanca en ModSecurity
Para crear un parche virtual en la lista blanca, debemos poder verificar los valores normales esperados. Si el registro correcto se configuró previamente como parte de la fase de preparación, entonces, a través de la revisión del registro, podrá comprender el formato de los valores de entrada esperados.

Un ejemplo

En este caso, el parámetro reqID debe contener solo enteros para que podamos aplicar este parche virtual:

 # # ,     1    "reqID" # SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:1,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter - Duplicate Parameters Names Seen.',logdata:'%{matched_var}'" SecRule &ARGS:/reqID/ "!@eq 1" # # ,   reqID     # SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:2,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter.',logdata:'%{args.reqid}'" SecRule ARGS:/reqID/ "!@rx ^[0-9]+$" 

Este parche virtual analizará el parámetro reqID y solo permitirá enteros en la entrada. Sin embargo, vale la pena recordar que el vector de ataque casi nunca es único y que el atacante puede probar suerte de otra manera.

Enfoque negativo (listas negras, listas negras) en parche virtual

Este enfoque se basa en una lista de reglas que definen ciertos ataques conocidos en lugar de permitir solo tráfico válido.

Un ejemplo de creación de un parche virtual basado en listas negras en ModSecurity

Por ejemplo, código PoC de una fuente pública:

 http://localhost/wordpress/wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php?reqID=1' or 1='1 

Después de analizar la carga, podemos ver que el atacante inserta una comilla simple y agrega lógica SQL al final. En base a estos datos, podemos prohibir comillas simples:

 SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:1,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter.',logdata:'%{args.reqid}'" SecRule ARGS:/reqID/ "@pm '" 

Cuidado con la creación de parches virtuales para exploits específicos

Por supuesto, esto se ve atractivo y ahorra tiempo. Por ejemplo, si pentest encontró XSS en su página y usó la siguiente carga:

 <script> alert('XSS Test') </script> 

No sería razonable crear un parche virtual que bloqueara específicamente dicha carga, por muy atractivo que sea en términos de esfuerzo y velocidad. Es necesario crear un parche virtual para cerrar el problema en su conjunto, y no su caso específico.

Crear automáticamente parches virtuales

La creación manual de parches puede volverse insoportable debido al creciente número de vulnerabilidades y la automatización se convierte en un paso necesario. Si se descubrieron vulnerabilidades utilizando herramientas automatizadas (por ejemplo, escáneres de vulnerabilidades), entonces es posible convertir informes de estas herramientas en parches. Las herramientas de automatización de parches más populares son la importación directa a WAF (naturalmente, si su solución lo admite), las secuencias de comandos OWASP ModSecurity Core Rule Set (CRS) y ThreadFix Virtual Patching.

Etapa de implementación y prueba

Para probar correctamente nuestro nuevo parche virtual, es posible que necesitemos las siguientes herramientas:

• navegador web
• utilidades web para terminales (por ejemplo, curl y wget)
• proxy local
• ModSecurity AuditViewer

Pasos:

• Implemente parches virtuales primero en el modo "solo registros", para asegurarse de que el tráfico normal de usuarios no esté bloqueado (opción de falso positivo).
• Si se descubrió la vulnerabilidad utilizando alguna herramienta o comando específico, solicite una nueva verificación.
• Si la nueva prueba falla porque se puede omitir el parche virtual, debe volver al paso de análisis para determinar la mejor manera de cerrar el problema.

Etapa de recuperación / continuación

• Actualice los datos en su sistema de tickets: aunque los plazos para instalar parches virtuales pueden estar activados, es mejor rastrear y actualizar los cambios en su sistema de rastreo. Esto permitirá abordar el problema original de manera más adecuada y más completa, con una menor probabilidad de que se pierdan algunos detalles. También le permite evaluar con mayor precisión el tiempo que se dedicó a cada etapa de la resolución del problema.
• Reevaluar periódicamente: esto ayuda a comprender qué parches virtuales se pueden eliminar ya / pronto, ya que, por ejemplo, se ha aplicado / se aplicará un parche de código fuente completo.
• Configure informes de sus parches virtuales: esto ayudará a comprender cuándo y cuántas veces estarán involucrados. Esto a su vez le dará estadísticas sobre los lugares en los que tiene más probabilidades de estar en riesgo.