Zero Day Threat es un término para las vulnerabilidades de desarrollo que aún no se han descubierto. Dichas vulnerabilidades pueden ser explotadas por los ciberdelincuentes, lo que finalmente afectará la reputación de la empresa. Los desarrolladores se enfrentan a la tarea de minimizar la cantidad de defectos en el código que podrían causar tal vulnerabilidad. Una de las herramientas para ayudar a identificar fallas de seguridad es el analizador de código estático PVS-Studio para C, C ++, C #, Java.
Amenaza de día cero
Amenaza de día cero es un término que identifica brechas y vulnerabilidades permitidas por los desarrolladores, pero que aún no se han descubierto. Hasta que se corrija la vulnerabilidad, se puede usar para acceder a redes, controlar remotamente una computadora, manipular datos, etc. Este nombre del término está bien establecido debido al hecho de que los desarrolladores no tienen un día para arreglar el defecto, ya que nadie lo sabe aún. A su debido tiempo, grandes empresas y software como
Adobe ,
Windows , el
navegador Tor y muchos otros sufrieron tales vulnerabilidades.
Algunas organizaciones tuvieron suerte, su vulnerabilidad fue encontrada por personas que no iban a usarla, y simplemente proporcionaron información sobre el problema. Por ejemplo, esto fue con
MacOS . O hubo una actualización que, además de las nuevas características, también reparó accidentalmente la amenaza de día cero.
Sin embargo, hubo otras situaciones. Por ejemplo, Google Chrome tuvo que corregir urgentemente una
vulnerabilidad que permitía a un atacante ejecutar remotamente código arbitrario en el dispositivo de la víctima.
El problema con esta amenaza es que es imposible defenderse al 100%, ya que es difícil defenderse contra lo que aún no sabe. Sin embargo, hay formas de reducir la probabilidad de tal amenaza en su proyecto, y las discutiremos más adelante, pero para comenzar con una pequeña teoría.
Análisis estático
El análisis de código estático es el proceso de verificar el código del programa por el analizador sin iniciar el programa en sí. El análisis estático se puede considerar como un proceso de revisión de código automatizado. En algunos casos, la efectividad del análisis estático es superior a la revisión de código, pero varios programadores no pueden considerarla como una alternativa completa a la revisión de código. A continuación, intenté describir brevemente los pros y los contras de la revisión de código y el análisis de código estático entre sí.
CVE y CWE
Common Vulnerabilities and Exposures (CVE) es una base de datos de errores de software que pueden ser utilizados por ciberdelincuentes. CVE fue creado para optimizar defectos de software conocidos. La mayoría de las herramientas de seguridad de la información usaban sus propias bases de datos y nombres, y para eliminar este caos y agregar compatibilidad con varias herramientas, MITRE en 1999 creó CVE. Sin embargo, CVE no fue suficiente para evaluar la seguridad del código. Esto requiere algo más preciso, con una descripción detallada de los problemas y menos burda que ella. Por lo tanto, se creó la base de Enumeración de Debilidad Común (CWE) que cumple con estos requisitos. Si el error está en la lista CWE, entonces es probable que conduzca a una vulnerabilidad que podría ser explotada por el atacante y entrar en la lista CVE. Para mayor claridad, puede mirar el diagrama de Euler a continuación.
Algunos analizadores estáticos pueden decirle al desarrollador que, por ejemplo, el proyecto usa la biblioteca en la que se encuentra la vulnerabilidad. Esto le permite elegir una versión más nueva de la biblioteca en la que ya se ha solucionado la vulnerabilidad y reducir la probabilidad de que surjan problemas con las amenazas derivadas del código de otra persona.
Con el advenimiento del desarrollo de las listas CVE y CWE, muchas herramientas de seguridad de la información se han encargado de su soporte, incluidos los analizadores estáticos. Dichos analizadores pueden considerarse como una solución SAST. SAST (Static Application Security Testing) permite a los desarrolladores encontrar vulnerabilidades en el código fuente de la aplicación ya en las primeras etapas del ciclo de vida del desarrollo de software.
Usar SAST en el desarrollo es otra opción para minimizar la probabilidad de una amenaza de día cero. El analizador, al clasificar sus errores de acuerdo con el CWE, puede determinar dónde se esconde una posible vulnerabilidad. Y al corregir estos errores, el desarrollador hace que su aplicación sea más confiable y reduce la probabilidad de una amenaza de 0 días.
Existen varias herramientas para las pruebas de seguridad estática. Para demostrar las capacidades en el manejo de vulnerabilidades, analicemos la herramienta
PVS-Studio . Las advertencias de este analizador se pueden clasificar como CWE. Veamos algunos ejemplos.
Advertencia PVS-Studio:
CWE-561 : Código muerto (
V3021 ).
public string EncodeImage(....) { if (string.IsNullOrWhiteSpace(inputPath)) { throw new ArgumentNullException("inputPath"); } if (string.IsNullOrWhiteSpace(inputPath)) { throw new ArgumentNullException("outputPath"); } .... }
Este código inadvertidamente hizo un error tipográfico. En dos condiciones
si , se verifica la misma variable. A juzgar por la excepción generada, en la segunda condición se debe verificar la variable
outputPath . Como resultado, parte del código es inalcanzable.
Tales errores parecen inofensivos a primera vista. Sin embargo, esta impresión puede ser muy engañosa. Considere un error muy simple e inofensivo a primera vista relacionado con la duplicación del operador
goto .
En un momento, este error causó una vulnerabilidad en el sistema operativo iOS.
Descripción de la vulnerabilidad
CVE-2014-1266 : La función SSLVerifySignedServerKeyExchange en libsecurity_ssl / lib / sslKeyExchange.c en la función de transporte seguro en el componente de seguridad de datos en Apple iOS 6.x antes de 6.1.6 y 7.x antes de 7.0.6, Apple TV 6.x antes de 6.0.2, y Apple OS X 10.9.x antes de 10.9.2 no verifica la firma en un mensaje de intercambio de claves del servidor TLS, que permite a los atacantes intermedios falsificar servidores SSL mediante el uso de un arbitrario clave privada para el paso de firma u omitir el paso de firma.
static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen) { OSStatus err; .... if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; .... fail: SSLFreeBuffer(&signedHashes); SSLFreeBuffer(&hashCtx); return err; }
Debido al doble
goto , también surge una situación con código inalcanzable. Independientemente de las condiciones, la segunda
instrucción goto se ejecutará en las instrucciones
if . Esto lleva al hecho de que no se verifica la firma. La función devuelve 0, lo que significa que todo está bien con la firma, y luego el programa recibe la clave del servidor, incluso si hay un problema con la firma. Esta clave es necesaria para cifrar datos durante la transmisión.
Las consecuencias de un error tan simple fueron muy graves. Por lo tanto, no tiene sentido argumentar cuán peligroso se clasifica este o aquel error como CWE. Solo necesita ser reparado, lo que hace que el código sea más seguro.
Por cierto, el error descrito podría ser fácilmente detectado por el analizador PVS-Studio. Daría dos advertencias de CWE aquí de inmediato:
Veamos otro ejemplo. En 2012, se supo sobre el problema de seguridad en MySQL, en el que un atacante podía ingresar a la base de datos MySQL. Proporcionaré un fragmento de código que sirvió como razón para esto.
Descripción de CVE-2012-2122 : sql / password.c en Oracle MySQL 5.1.x antes de 5.1.63, 5.5.x antes de 5.5.24 y 5.6.x antes de 5.6.6, y MariaDB 5.1.x antes de 5.1.62, 5.2.x antes de 5.2.12, 5.3.x antes de 5.3.6 y 5.5.x antes de 5.5.23, cuando se ejecuta en ciertos entornos con ciertas implementaciones de la función memcmp, permite a los atacantes remotos omitir la autenticación autenticándose repetidamente con el mismo contraseña incorrecta, que eventualmente hace que una comparación de tokens tenga éxito debido a un valor de retorno incorrectamente verificado.
typedef char my_bool; my_bool check_scramble(const char *scramble_arg, const char *message, const uint8 *hash_stage2) { .... return memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE); }
El tipo de retorno de la función
memcmp es int , y el tipo de retorno de la función
check_scramble es my_bool , de hecho,
char . Como resultado, un
int se convierte en un
char , en el que se descartan los bits de orden superior. Esto llevó al hecho de que en aproximadamente 1 de cada 256 casos, era posible conectarse con cualquier contraseña, conociendo el nombre de usuario.
Nuevamente, este error CWE podría neutralizarse y evitar que se convierta en un CVE incluso en la etapa de escritura del código. Por ejemplo, el analizador estático PVS-Studio genera la siguiente advertencia:
CWE-197 (
V642 ): Error de truncamiento numérico.
A continuación de este tema, propongo consultar el artículo "
¿Cómo puede ayudar PVS-Studio a buscar vulnerabilidades? ".
Conclusión
Vulnerabilidades de 0 días: algo de lo que no hay protección garantizada. Pero la probabilidad de que ocurran puede reducirse significativamente. Para esto, se pueden utilizar soluciones SAST especializadas como PVS-Studio. Si su proyecto detecta errores que pueden clasificarse como CWE, entonces debe prestarles atención y corregirlos. A pesar de que solo una pequeña cantidad de CWE llenará la lista de CVE al eliminar los errores de CWE, protege su aplicación de muchas amenazas potenciales.
Enlaces de sitio
- Descargue y pruebe PVS-Studio
- Tecnologías utilizadas en el analizador de código PVS-Studio para buscar errores y vulnerabilidades potenciales
- Clasificación de advertencia de PVS-Studio según la enumeración de debilidad común (CWE)
- Clasificación de advertencia de PVS-Studio según el estándar de codificación SEI CERT
Si desea compartir este artículo con una audiencia de habla inglesa, utilice el enlace a la traducción: Ekaterina Nikiforova.
PVS-Studio Static Analyzer como herramienta para la protección contra vulnerabilidades de día cero .