Escaneo de vulnerabilidades y desarrollo seguro. Parte 1

imagen

Como parte de sus actividades profesionales, los desarrolladores, los pentesters y los profesionales de seguridad tienen que lidiar con procesos como Vulnerability Management (VM), (Secure) SDLC.
Debajo de estas frases hay diferentes conjuntos de pr√°cticas y herramientas utilizadas que est√°n entrelazadas, aunque sus consumidores difieren.

El progreso t√©cnico a√ļn no ha llegado al punto de reemplazar a una persona con una herramienta para analizar la seguridad de la infraestructura y el software.
Es interesante entender por qué esto es así y qué problemas tiene que enfrentar.


Los procesos


El proceso de gestión de vulnerabilidades está destinado a la supervisión continua de la seguridad de la infraestructura y la gestión de parches.
El proceso Secure SDLC ("ciclo de desarrollo seguro") est√° dise√Īado para admitir la seguridad de la aplicaci√≥n 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 en el escaneo dentro de VM y SDLC es que, en el primer caso, el objetivo es detectar vulnerabilidades conocidas en software de terceros o en una configuración. 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 solo en componentes de terceros (dependencias), sino principalmente en el código del nuevo producto.

Esto da lugar a diferencias en las herramientas y enfoques. En mi opini√≥n, la tarea de encontrar nuevas vulnerabilidades en la aplicaci√≥n es mucho m√°s interesante, ya que no se reduce a las versiones de huellas digitales, la recopilaci√≥n de pancartas, la clasificaci√≥n de contrase√Īas, etc.
El escaneo automatizado de alta calidad de las vulnerabilidades de la aplicación requiere algoritmos que tengan en cuenta la semántica de la aplicación, su propósito, las amenazas específicas.

El escáner de infraestructura a menudo se puede reemplazar por un temporizador, como lo dijo avleonov . El punto es que, puramente estadísticamente, puede considerar su infraestructura vulnerable si no la actualizó, por ejemplo, un mes.

Las herramientas


El escaneo, así como el análisis de seguridad, se pueden realizar como un cuadro negro o un cuadro blanco.

Caja negra


Cuando se escanea el blackbox, 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 "pancartas", determinan las versiones de software instaladas y buscan en su base de conocimiento informaci√≥n sobre vulnerabilidades en estas versiones. Tambi√©n intentan detectar errores de configuraci√≥n, como contrase√Īas predeterminadas o acceso abierto a datos, cifrados SSL d√©biles, etc.

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

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

Caja blanca


Los escaneos de Whitebox tienen m√°s diferencias.
A lo largo del proceso, los escáneres VM (Vulners, Incsecurity Couch, Vuls, Tenable Nessus, etc.) a menudo tienen acceso a los sistemas mediante la realización de un análisis autenticado. Por lo tanto, el escáner puede descargar versiones instaladas de paquetes y parámetros de configuración directamente desde el sistema, sin adivinarlos en los banners de los 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 hablamos sobre análisis de código estático y el uso de las herramientas correspondientes de la clase SAST - Pruebas de seguridad de aplicaciones estáticas.

Los problemas


¡Hay muchos problemas con el escaneo! Tengo que tratar con la mayoría de ellos personalmente en el marco de la prestación de un servicio para crear procesos de escaneo y desarrollo seguro, así como al realizar trabajos de análisis de seguridad.

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

Problemas de escaneo de aplicaciones web


  1. La complejidad de la implementaci√≥n. Los esc√°neres deben implementarse, configurarse, personalizarse para cada aplicaci√≥n, asignarse un entorno de prueba para los an√°lisis e implementarse en el proceso de CI / CD para que sean efectivos. De lo contrario, ser√° un procedimiento formal in√ļtil, que dar√° solo falsos positivos.
  2. Duración del escaneo. Los escáneres, incluso en 2019, funcionan mal con la deduplicación de la interfaz y pueden escanear miles de páginas durante 10 días con 10 parámetros en cada uno, considerándolos diferentes, aunque el mismo código es responsable de ellos. Al mismo tiempo, la decisión de desplegarse en producción dentro del ciclo de desarrollo debe tomarse rápidamente
  3. Pocas recomendaciones. Los escáneres ofrecen recomendaciones bastante generales, y no siempre es posible que un desarrollador comprenda rápidamente cómo reducir el nivel de riesgo y, lo que es más importante, si debe hacerse en este momento o no.
  4. Efecto destructivo sobre la aplicación. Los escáneres pueden llevar a cabo un ataque DoS en la aplicación, y también pueden crear una gran cantidad de entidades o modificar las existentes (por ejemplo, crear decenas de miles de comentarios en un blog), así que no inicies un escaneo sin pensar en el producto.
  5. Detección de vulnerabilidades de baja calidad. Los escáneres generalmente usan una matriz de cargas fijas y pueden pasar por alto fácilmente una vulnerabilidad que no se ajusta a su escenario conocido de comportamiento de la aplicación.
  6. El escáner no comprende las funciones de la aplicación. Los escáneres mismos 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 en la lógica empresarial permanece completamente descubierta, no adivinarán escribir dos veces, espiar los datos de otras personas por ID o liquidar el saldo a través del redondeo
  7. El escáner no comprende la semántica de la página. Los escáneres no saben cómo leer las preguntas frecuentes, no saben cómo reconocer captchas, por sí mismos no adivinarán cómo registrarse, y luego deben iniciar sesión, que no pueden hacer clic en "cerrar sesión" y cómo firmar solicitudes al cambiar los valores de los parámetros. Como resultado, la mayor parte de la aplicación puede no escanearse en absoluto.


Problemas de escaneo del código fuente


  1. Falsos positivos. El análisis estático es una tarea difícil, para resolver lo que es necesario recurrir a muchos compromisos. A menudo hay que sacrificar la precisión, e incluso los costosos escáneres empresariales producen una gran cantidad de falsos positivos.
  2. La complejidad de la implementaci√≥n. Para aumentar la precisi√≥n y la integridad del an√°lisis est√°tico, es necesario refinar las reglas de escaneo, y escribir estas reglas puede llevar demasiado tiempo. 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 soporte de 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 conocimiento del escáner no tiene información sobre "sumideros" en estos marcos, esto 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 difícil en términos de algoritmos. Por lo tanto, el proceso puede retrasarse y requerir importantes recursos informáticos.
  5. Baja cobertura A pesar del consumo de recursos y la duración de la exploración, los desarrolladores de herramientas SAST todavía tienen que recurrir a compromisos y analizar no todas las condiciones en las que el programa puede estar
  6. Reproducibilidad de hallazgos. Se√Īalar una l√≠nea espec√≠fica y una pila de llamadas que conducen a una vulnerabilidad est√° bien, pero en realidad el esc√°ner a menudo no proporciona suficiente informaci√≥n para verificar una vulnerabilidad externa. Despu√©s de todo, una falla tambi√©n puede estar en c√≥digo muerto, lo cual es inalcanzable para un atacante


Problemas de escaneo de infraestructura


  1. Inventario inadecuado. En grandes infraestructuras, especialmente separadas geográficamente, a menudo es más difícil entender qué hosts necesitan ser escaneados. 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 inconvenientes que no son explotables 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 arreglarse primero
  3. Pocas recomendaciones. La base de conocimiento del escáner a menudo tiene 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. Trabajo manual Las infraestructuras pueden tener muchos nodos, lo que significa que hay potencialmente muchas deficiencias, informes sobre los cuales deben desmontarse y analizarse manualmente en cada iteración
  5. Mala cobertura La calidad del escaneo de la infraestructura depende directamente del volumen de la base de conocimiento sobre vulnerabilidades y versiones de software. Al mismo tiempo, resulta que incluso los líderes del mercado no tienen una base de conocimiento integral, y hay una gran cantidad de información en las bases de datos de soluciones gratuitas que los líderes no tienen.
  6. Problemas con parches. El parche m√°s com√ļn para vulnerabilidades en la infraestructura es actualizar el paquete o cambiar el archivo de configuraci√≥n. El gran problema aqu√≠ es que el sistema, especialmente el heredado, puede comportarse de manera impredecible como resultado de una actualizaci√≥n. En esencia, deber√° realizar pruebas de integraci√≥n en la infraestructura viva en producci√≥n.


Los enfoques


Como ser
Te contaré más sobre ejemplos y cómo lidiar con muchos de estos problemas en las siguientes partes, pero por ahora te indicaré las principales áreas en las que puedes trabajar:
  1. Agregaci√≥n de diversas herramientas de escaneo. Con el uso correcto de m√ļltiples esc√°neres, se puede lograr un aumento significativo en la base de conocimiento y la calidad de la detecci√≥n. Puede encontrar a√ļn m√°s vulnerabilidades que en total todos los esc√°neres lanzados por separado, mientras que es posible evaluar con mayor precisi√≥n el nivel de riesgo y dar m√°s recomendaciones
  2. Integración de SAST y DAST. Puede aumentar la cobertura DAST y la precisión SAST compartiendo información entre ellos. Desde la fuente puede obtener información sobre las rutas existentes, y con DAST puede verificar si la vulnerabilidad es visible desde el exterior
  3. Machine Learning ‚ĄĘ . En 2015, habl√© (y a√ļn ) sobre el uso de estad√≠sticas para dar a los hackers la intuici√≥n de los esc√°neres y acelerarlos. Esto definitivamente es alimento para el desarrollo de futuros an√°lisis de seguridad automatizados.
  4. Integración de IAST con autotest y OpenAPI. En el marco de la canalización de CI / CD, es posible crear un proceso de escaneo basado en herramientas que funcionan como proxies HTTP y pruebas funcionales que funcionan en HTTP. Las pruebas y los contratos de OpenAPI / Swagger le dará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, debe crear un perfil de escaneo adecuado que tenga en cuenta el n√ļmero y la naturaleza de las interfaces, las tecnolog√≠as utilizadas
  6. Personalización de escáneres. A menudo, una aplicación no se puede escanear sin finalizar el escáner. Un ejemplo es una pasarela de pago en la que se debe firmar cada solicitud. Sin escribir un conector en el protocolo de la puerta de enlace, los escáneres superarán sin pensar las solicitudes con la firma incorrecta. También es necesario escribir escáneres especializados para un tipo específico de falla, como la Referencia directa insegura de objetos
  7. Gestión de riesgos. El uso de diversos escáneres y la integración con sistemas externos, como la Gestión de activos y la Gestión de amenazas, le permitirán utilizar 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!

Source: https://habr.com/ru/post/444534/


All Articles