Escaneo de vulnerabilidades y desarrollo seguro. Parte 1

En el marco de sus actividades profesionales, los desarrolladores, pentesters y especialistas en seguridad tienen que ocuparse de procesos como la gestión de vulnerabilidades (VM) y el SDLC (seguro).
Debajo de estas frases se esconden diferentes conjuntos de prácticas y herramientas utilizadas que están entrelazadas, aunque sus usuarios difieren.

El progreso técnico aún no ha llegado al punto en que una herramienta pueda reemplazar a una persona para analizar la seguridad de la infraestructura y el software.
Es interesante entender por qué esto es así y qué problemas enfrentamos.

Процессы

El proceso de Gestión de vulnerabilidades está diseñado para el monitoreo continuo de la seguridad de la infraestructura y la gestión de parches.
El proceso Secure SDLC (“ciclo de desarrollo seguro”) está diseñado para mantener la seguridad de las aplicaciones durante el desarrollo y la operación.

Una parte similar de estos procesos es el proceso de Evaluación de Vulnerabilidad: evaluación de vulnerabilidad, escaneo de vulnerabilidad.
La principal diferencia entre el escaneo VM y SDLC es que en el primer caso el objetivo es detectar vulnerabilidades conocidas en software o configuración de terceros. Por ejemplo, una versión desactualizada de Windows o la cadena de comunidad predeterminada para SNMP.
En el segundo caso, el objetivo es detectar vulnerabilidades no sólo en componentes de terceros (dependencias), sino principalmente en el código del nuevo producto.

Esto crea diferencias en herramientas y enfoques. En mi opinión, la tarea de encontrar nuevas vulnerabilidades en una aplicación es mucho más interesante, ya que no se trata de tomar huellas dactilares de versiones, recopilar pancartas, forzar contraseñas, etc.
Para un escaneo automatizado de alta calidad de las vulnerabilidades de las aplicaciones, se requieren algoritmos que tengan en cuenta la semántica de la aplicación, su propósito y las amenazas específicas.

Un escáner de infraestructura a menudo se puede reemplazar con un temporizador, como dije avleonov. La cuestión es que, puramente estadísticamente, puedes considerar vulnerable tu infraestructura si no la has actualizado, digamos, durante un mes.

Instrumentos

El escaneo, al igual que el análisis de seguridad, se puede realizar utilizando un cuadro negro o un cuadro blanco.

Caja Negro

Al escanear caja negra, la herramienta debe poder trabajar con el servicio a través de las mismas interfaces a través de las cuales los usuarios trabajan con él.

Los escáneres de infraestructura (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose, etc.) buscan puertos de red abiertos, recopilan "banners", determinan versiones de software instalado y buscan en su base de conocimientos información sobre vulnerabilidades en estas versiones. También intentan detectar errores de configuración como contraseñas predeterminadas o acceso a datos abiertos, cifrados SSL débiles, etc.

Los escáneres de aplicaciones web (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, etc.) también pueden identificar componentes conocidos y sus versiones (por ejemplo, CMS, frameworks, bibliotecas JS). Los pasos principales del escáner son el rastreo y la confusión.
Durante el rastreo, el escáner recopila información sobre las interfaces de aplicaciones existentes y los parámetros HTTP. Durante la fuzzing, se insertan datos mutados o generados en todos los parámetros detectados para provocar un error y detectar una vulnerabilidad.

Estos escáneres de aplicaciones pertenecen a las clases DAST e IAST: pruebas de seguridad de aplicaciones dinámicas e interactivas, respectivamente.

Caja blanco

Hay más diferencias con el escaneo de caja blanca.
Como parte del proceso de VM, los escáneres (Vulners, Incsecurity Couch, Vuls, Tenable Nessus, etc.) a menudo obtienen acceso a los sistemas mediante la realización de un escaneo autenticado. De este modo, el escáner puede descargar las versiones de los paquetes instalados y los parámetros de configuración directamente desde el sistema, sin adivinarlos en los anuncios de servicios de red.
El escaneo es más preciso y completo.

Si hablamos de escaneo de caja blanca (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs, etc.) de aplicaciones, generalmente estamos hablando de análisis de código estático y el uso de herramientas apropiadas de la clase SAST: Pruebas de seguridad de aplicaciones estáticas.

Problemas

¡Hay muchos problemas con el escaneo! Tengo que tratar con la mayoría de ellos personalmente como parte de la prestación de un servicio para el escaneo de edificios y procesos de desarrollo seguros, así como cuando realizo trabajos de análisis de seguridad.

Destacaré 3 grupos principales de problemas, que se confirman en conversaciones con ingenieros y jefes de servicios de seguridad de la información en una variedad de empresas.

Problemas de escaneo de aplicaciones web

1. Dificultad de implementación. Para que esto sea efectivo, los escáneres deben implementarse, configurarse, personalizarse para cada aplicación, asignarse un entorno de prueba para los escaneos e implementarse en el proceso CI/CD. De lo contrario, será un trámite formal inútil que sólo producirá falsos positivos.
2. Duración del escaneo. Incluso en 2019, los escáneres no hacen un buen trabajo a la hora de deduplicar interfaces y pueden pasar días escaneando mil páginas con 10 parámetros en cada una, considerándolas diferentes, aunque el mismo código sea responsable de ellas. Al mismo tiempo, la decisión sobre la implementación en producción dentro del ciclo de desarrollo debe tomarse rápidamente.
3. Malas recomendaciones. Los escáneres dan recomendaciones bastante generales y el desarrollador no siempre puede comprender rápidamente cómo reducir el nivel de riesgo y, lo más importante, si es necesario hacerlo ahora mismo o si todavía no da miedo.
4. Impacto destructivo en la aplicación. Los escáneres pueden llevar a cabo un ataque DoS en una aplicación y también pueden crear una gran cantidad de entidades o cambiar las existentes (por ejemplo, crear decenas de miles de comentarios en un blog), por lo que no debe iniciar un escaneo sin pensar en producción.
5. Baja calidad de detección de vulnerabilidades. Los escáneres suelen utilizar una serie fija de cargas útiles y pueden pasar fácilmente por alto una vulnerabilidad que no encaja en el escenario de comportamiento conocido de la aplicación.
6. El escáner no comprende las funciones de la aplicación. Los propios escáneres no saben qué son "banca por Internet", "pago" y "comentario". Para ellos, solo hay enlaces y parámetros, por lo que una enorme capa de posibles vulnerabilidades de la lógica de negocios permanece completamente descubierta; no se les ocurrirá hacer una doble cancelación, espiar los datos de otra persona por ID o aumentar el saldo mediante redondeo.
7. El escáner no comprende la semántica de las páginas. Los escáneres no pueden leer las preguntas frecuentes, no pueden reconocer captchas y por sí solos no descubrirán cómo registrarse y luego volver a iniciar sesión, que no se puede hacer clic en "cerrar sesión" y cómo firmar solicitudes al cambiar el parámetro. valores. Como resultado, es posible que la mayor parte de la aplicación no se analice en absoluto.

Problemas al escanear el código fuente

1. Falsos positivos. El análisis estático es una tarea compleja que implica muchas compensaciones. A menudo hay que sacrificar la precisión, e incluso los costosos escáneres empresariales producen una gran cantidad de falsos positivos.
2. Dificultad de implementación. Para aumentar la precisión y la integridad del análisis estático, es necesario perfeccionar las reglas de escaneo, y escribir estas reglas puede requerir demasiada mano de obra. A veces es más fácil encontrar todos los lugares en el código con algún tipo de error y corregirlos que escribir una regla para detectar tales casos.
3. Falta de apoyo a la dependencia. Los grandes proyectos dependen de una gran cantidad de bibliotecas y marcos que amplían las capacidades del lenguaje de programación. Si la base de conocimientos del escáner no tiene información sobre los "sumideros" en estos marcos, se convertirá en un punto ciego y el escáner simplemente ni siquiera entenderá el código.
4. Duración del escaneo. Encontrar vulnerabilidades en el código es una tarea compleja en términos de algoritmos. Por lo tanto, el proceso puede llevar mucho tiempo y requerir importantes recursos informáticos.
5. Baja cobertura. A pesar del consumo de recursos y el tiempo de escaneo, los desarrolladores de herramientas SAST todavía tienen que hacer concesiones y analizar no todos los estados en los que se puede encontrar el programa.
6. Reproducibilidad de los hallazgos. Señalar la línea específica y la pila de llamadas que conduce a una vulnerabilidad es excelente, pero en realidad, a menudo el escáner no proporciona suficiente información para verificar la presencia de una vulnerabilidad desde el exterior. Después de todo, la falla también puede estar en un código inactivo, que es inalcanzable para un atacante.

Problemas de escaneo de infraestructura

1. Inventario insuficiente. En infraestructuras grandes, especialmente aquellas separadas geográficamente, suele ser más difícil saber qué hosts escanear. En otras palabras, la tarea de escaneo está estrechamente relacionada con la tarea de gestión de activos.
2. Mala priorización. Los escáneres de red a menudo producen muchos resultados con fallas que no se pueden explotar en la práctica, pero formalmente su nivel de riesgo es alto. El consumidor recibe un informe que es difícil de interpretar y no está claro qué debe corregirse primero.
3. Malas recomendaciones. La base de conocimientos del escáner a menudo contiene sólo información muy general sobre la vulnerabilidad y cómo solucionarla, por lo que los administradores tendrán que armarse con Google. La situación es un poco mejor con los escáneres de caja blanca, que pueden emitir un comando específico para solucionar
4. Hecho a mano. Las infraestructuras pueden tener muchos nodos, lo que significa potencialmente muchas fallas, cuyos informes deben analizarse manualmente en cada iteración.
5. Mala cobertura. La calidad del escaneo de la infraestructura depende directamente del tamaño de la base de conocimientos sobre vulnerabilidades y versiones de software. Donde, vueltas, Incluso los líderes del mercado no tienen una base de conocimientos completa, y las bases de datos de soluciones gratuitas contienen mucha información que los líderes no tienen.
6. Problemas con los parches. En la mayoría de los casos, parchear las vulnerabilidades de la infraestructura implica actualizar un paquete o cambiar un archivo de configuración. El gran problema aquí es que un sistema, especialmente uno heredado, puede comportarse de manera impredecible como resultado de una actualización. Básicamente, deberá realizar pruebas de integración en la infraestructura activa en producción.

Aproximaciones

¿Cómo puede ser eso?
Le contaré más sobre ejemplos y cómo abordar muchos de los problemas enumerados en las siguientes partes, pero por ahora le indicaré las direcciones principales en las que puede trabajar:

1. Agregación de varias herramientas de escaneo. Con el uso correcto de varios escáneres, se puede lograr un aumento significativo en la base de conocimientos y la calidad de la detección. Puede encontrar incluso más vulnerabilidades que el total de todos los escáneres iniciados por separado, al mismo tiempo que puede evaluar con mayor precisión el nivel de riesgo y hacer más recomendaciones.
2. Integración de SAST y DAST. Es posible aumentar la cobertura de DAST y la precisión de SAST intercambiando información entre ellos. De las fuentes puede obtener información sobre las rutas existentes y utilizando DAST puede comprobar si la vulnerabilidad es visible desde el exterior.
3. Aprendizaje automático™. En 2015 yo dijo (y mas) sobre el uso de estadísticas para dotar a los escáneres de la intuición de un hacker y acelerarlos. Sin duda, esto es material para el desarrollo de análisis de seguridad automatizados en el futuro.
4. Integración de IAST con autotests y OpenAPI. Dentro del proceso de CI/CD, es posible crear un proceso de escaneo basado en herramientas que funcionan como un proxy HTTP y pruebas funcionales que funcionan a través de HTTP. Las pruebas y contratos de OpenAPI/Swagger brindarán al escáner la información que falta sobre los flujos de datos y permitirán escanear la aplicación en varios estados.
5. Configuración correcta. Para cada aplicación e infraestructura, es necesario crear un perfil de escaneo adecuado, teniendo en cuenta la cantidad y la naturaleza de las interfaces y las tecnologías utilizadas.
6. Personalización del escáner. A menudo, una aplicación no se puede escanear sin modificar el escáner. Un ejemplo es una pasarela de pago, en la que se debe firmar cada solicitud. Sin escribir un conector para el protocolo de puerta de enlace, los escáneres bombardearán sin pensar con solicitudes con la firma incorrecta. También es necesario escribir escáneres especializados para un tipo específico de defecto, como Referencia de objeto directo inseguro
7. Gestión de riesgos. El uso de varios escáneres y la integración con sistemas externos como Asset Management y Threat Management permitirán el uso de muchos parámetros para evaluar el nivel de riesgo, de modo que la administración pueda obtener una imagen adecuada del estado de seguridad actual del desarrollo o la infraestructura.

¡Estén atentos e interrumpamos el escaneo de vulnerabilidades!

Fuente: habr.com