Una vulnerabilidad de día cero (0 días) es una vulnerabilidad de software introducida durante el proceso de desarrollo y aún no descubierta por los desarrolladores. Los hackers pueden explotar las vulnerabilidades de día cero, lo que afecta la reputación de la empresa. Los desarrolladores deben tratar de minimizar la cantidad de defectos que conducen a tales vulnerabilidades. PVS-Studio, un analizador de código estático para C, C ++, C # y código Java, es una de las herramientas capaces de detectar problemas de seguridad.
Vulnerabilidades de día cero
Una
vulnerabilidad de día cero (también conocida como vulnerabilidad de
0 días ) es una vulnerabilidad de software que los desconocidos o que no deben abordar, deben estar interesados en mitigar la vulnerabilidad (incluido el proveedor del software de destino). Hasta que se mitigue la vulnerabilidad, los piratas informáticos pueden explotarla para afectar negativamente a programas informáticos, datos, computadoras adicionales o una red. El término significa que los desarrolladores no tienen un solo día para arreglar el defecto porque aún nadie lo sabe. Algunos de los conocidos proveedores y productos de software como
Adobe ,
Windows , el
navegador Tor y muchos otros, se vieron afectados por vulnerabilidades de día cero en el pasado.
Algunos tuvieron la suerte de tener una vulnerabilidad encontrada e informada por personas que no iban a explotarla. El caso de
MacOS es uno de esos ejemplos. En algunos otros casos, los propios desarrolladores produjeron un parche con el que, al agregar nuevas características, también corrigieron una vulnerabilidad de día cero sin saberlo.
Sin embargo, otros tuvieron menos suerte. Por ejemplo, no hace mucho tiempo, Google Chrome tuvo que corregir urgentemente una
vulnerabilidad que podría explotarse para ejecutar código arbitrario de forma remota.
El problema es que no puede garantizar una protección del 100% contra estas vulnerabilidades, ya que no puede combatir eficazmente una amenaza que ni siquiera conoce. Sin embargo, hay maneras de hacer que tales defectos sean menos probables en su programa; este será el tema de este artículo, pero primero deberíamos echar un vistazo a alguna teoría.
Análisis estático
El análisis estático es un método para verificar el código fuente de un programa de software utilizando un analizador sin ejecutar el programa en sí y puede verse como una revisión de código automatizada. A veces, el análisis estático puede ser mucho más efectivo que la revisión de código de pares, pero no puede reemplazarlo por completo. Intenté resumir los pros y los contras de la revisión de código y el análisis estático entre sí en la siguiente tabla:
CVE y CWE
Common Vulnerabilities and Exposures (CVE) es una base de datos de vulnerabilidades y exposiciones de seguridad de la información. Su propósito inicial era organizar defectos de software conocidos en una lista coherente. En el pasado, la mayoría de las herramientas de seguridad de la información usaban sus propias bases de datos y nombres para tales defectos, y fue para poner orden en ese caos y establecer la compatibilidad entre las diferentes herramientas que MITER Corporation desarrolló CVE en 1999. Sin embargo, CVE resultó ser ser insuficiente para estimar la seguridad del código. Se necesitaba algún otro sistema, con una clasificación más fina y descripciones más detalladas. Así es como surgió la Enumeración de Debilidad Común (CWE). Si un defecto aparece en la lista de CWE, puede causar una vulnerabilidad explotable y también agregarse a la lista de CVE. El siguiente diagrama de Euler muestra las relaciones entre los estándares.
Algunos analizadores estáticos pueden informarle si, por ejemplo, su proyecto emplea una biblioteca que contiene una vulnerabilidad. Sabiendo esto, puede descargar una versión más nueva de la biblioteca, con el defecto solucionado, para que su código sea menos susceptible a las amenazas de seguridad causadas por un error en el código de otra persona.
A medida que los estándares CVE y CWE fueron adoptados por la comunidad de desarrolladores, también fueron respaldados por muchas herramientas de seguridad de la información, incluidos los analizadores estáticos. Los analizadores que admiten estas clasificaciones se pueden ver como soluciones SAST. SAST (Static Application Security Testing) permite a los desarrolladores detectar vulnerabilidades en el código fuente de los programas en las primeras etapas del ciclo de vida del desarrollo de software.
SAST es otra práctica para minimizar la probabilidad de que ocurran vulnerabilidades de día cero en su proyecto. Un analizador que admita el estándar CWE puede decirle dónde se esconde una vulnerabilidad potencial para que pueda solucionarlo y hacer que su aplicación sea más confiable y menos propensa a contener una amenaza de 0 días.
Hay una variedad de herramientas SAST. Tomaré el analizador
PVS-Studio como ejemplo para mostrar cómo estas herramientas pueden ayudar a combatir las vulnerabilidades. Las advertencias de este analizador se clasifican como CWE. Algunos ejemplos se dan a continuación.
Mensaje de diagnóstico de 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 contiene un error tipográfico: las condiciones de ambas declaraciones
if verifican la misma variable. El mensaje que acompaña a la excepción sugiere que la segunda condición debería verificar la variable
outputPath en su lugar. Este error ha hecho que una parte del código sea inalcanzable.
Errores como ese pueden parecer inofensivos, pero esta impresión es incorrecta. Echemos un vistazo a otro error trivial y aparentemente inofensivo que tiene que ver con una declaración
goto duplicada.
Este error una vez causó una vulnerabilidad en iOS.
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; }
Como en el primer ejemplo, el
goto duplicado aquí condujo a un código inalcanzable: cualesquiera que sean las condiciones de las declaraciones
if , la segunda declaración
goto se ejecutará de todos modos. Como resultado, la firma no se verificaría, la función devolvería 0, lo que significa que la firma estaba bien, y el programa recibiría una clave del servidor incluso si la verificación de firma fallaba. Esta clave se usa para cifrar los datos que se transmiten.
Este error trivial tuvo implicaciones drásticas. El incidente ilustra por qué no tiene sentido especular si este o aquel defecto de CWE es peligroso o no, solo tiene que arreglarlo por la seguridad de su código.
Por cierto, PVS-Studio podría haber encontrado fácilmente este error, informándolo con dos advertencias CWE a la vez:
Aquí hay otro ejemplo. Hace mucho tiempo, en 2012, se descubrió un problema de seguridad en MySQL, que podría ser explotado por un atacante para ingresar a la base de datos MySQL. A continuación, verá el fragmento de código defectuoso, donde se produjo la vulnerabilidad.
La vulnerabilidad
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 misma contraseña incorrecta, lo 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); }
La función
memcmp devuelve un valor de tipo
int , mientras que la función
check_scramble devuelve un valor de tipo
my_bool , que de hecho es
char . El valor
int se convierte implícitamente en
char , con los bits más significativos truncados. Esto causó aproximadamente 1 de 256 intentos de iniciar sesión con una contraseña arbitraria para que un nombre de usuario conocido tenga éxito.
Una vez más, este defecto de CWE podría haberse neutralizado e impedido convertirse en una vulnerabilidad de CVE mucho antes, en la etapa de codificación. Por ejemplo, PVS-Studio lo informa como
CWE-197 (
V642 ): Error de truncamiento numérico.
Consulte el artículo "
¿Cómo puede PVS-Studio ayudar en la detección de vulnerabilidades? " Para obtener más información sobre el tema.
Conclusión
No puede estar 100% seguro de que su programa esté a salvo de vulnerabilidades de 0 días. Pero aún puede hacer que sea mucho menos probable que ocurran. Esto se realiza mediante el uso de herramientas SAST especializadas como PVS-Studio. Si se encuentra que su proyecto contiene defectos clasificados como problemas de CWE, asegúrese de solucionarlos. Aunque pocos de los defectos de CWE terminan en la lista de CVE, corregirlos ayuda a proteger su programa de muchas amenazas potenciales.
Referencias
- Descargar y evaluar PVS-Studio
- Tecnologías utilizadas en el analizador de código PVS-Studio para encontrar errores y vulnerabilidades potenciales
- Clasificación de las advertencias de PVS-Studio de acuerdo con la enumeración de debilidad común (CWE)
- Clasificación de las advertencias de PVS-Studio según el estándar de codificación SEI CERT