¿Cómo se encuentran los cero días?

Los días cero se encuentran exactamente de la misma manera que cualquier otro tipo de agujero. Lo que hace que un agujero de seguridad sea un "día cero" se basa exclusivamente en quién es consciente de la existencia del agujero, no en ninguna otra característica técnica.

Los agujeros se encuentran, generalmente, por personas inquisitivas que notan un comportamiento extraño, o imaginan un posible error y luego intentan ver si el programador se dio por vencido. Por ejemplo, puedo imaginar que cualquier código que maneje el contenido de la cadena y se esfuerce por ser impermeable a las diferencias de caso (es decir, que maneja "A" como equivalente a "a") puede tener problemas cuando se ejecuta en una computadora turca (porque en idioma turco, la letra minúscula para "I" es "ı", no "i") que puede provocar errores divertidos, incluso agujeros de seguridad (p. ej., si algunas partes del sistema verifican la equivalencia de la cadena en una ubicación sensible al entorno camino, mientras que otros no lo hacen). Por lo tanto, puedo intentar configurar mi computadora con una configuración local turca y ver si el software que apunto comienza a hacer cosas raras (además de hablar turco).

Parte de la búsqueda de errores se puede automatizar probando muchas "combinaciones inusuales". Esto se conoce como fuzzing . Puede ayudar como primer paso, encontrar combinaciones de entrada que desencadenen bloqueos; cualquier cosa que haga que el sistema de destino se bloquee debe ser investigada, ya que los bloqueos generalmente significan corrupción de memoria, y la corrupción de memoria puede a veces ser objeto de abuso en cosas ingeniosas como la ejecución remota de código. Sin embargo, tales investigaciones aún deben ser realizadas por cerebros humanos.

(Si hubiera una forma completamente automática de detectar agujeros de seguridad, entonces los desarrolladores de software lo usarían para producir código libre de errores).

Para agregar a la excelente respuesta de Thomas Pornin, generalmente se encuentran vulnerabilidades de día cero a través de la auditoría de código fuente, ingeniería inversa y fuzzing (o pruebas de fuzz).

La elección de la técnica generalmente depende de la información disponible. Por ejemplo, si el software es de código abierto, la forma preferida es buscar en el código fuente y buscar vulnerabilidades. Las vulnerabilidades encontradas a través de la auditoría del código fuente suelen ser las más fáciles de explotar, ya que puede examinar y comprender todas las ramas de ejecución mirando el código fuente. El proceso de auditoría del código fuente puede ser tan simple como greping para llamadas a funciones peligrosas como strcpy o puede ser tan complejo como las pruebas automatizadas de cobertura de código en busca de cada ejecución y análisis de código de sucursal.

Si el código fuente no está disponible, la siguiente opción para el investigador de vulnerabilidades es aplicar ingeniería inversa a la aplicación y analizar el código de bajo nivel. Cuando una aplicación se analiza a través de un depurador o más preferiblemente a través de un descompilador como IDA, los fragmentos de código y las mnemotécnicas de ensamblaje se asignan a estructuras de rutina de lenguaje de nivel relativamente alto que son fáciles de analizar. El investigador de vulnerabilidades puede seguir el flujo de ejecución y analizar el comportamiento de forma estática o dinámica para encontrar diferentes errores de seguridad. Por ejemplo, asignar un búfer de tamaño fijo y luego copiar la entrada controlada por el usuario en el búfer asignado generalmente significa que se puede explotar a través de un exploit de desbordamiento de búfer.

El método final para encontrar nuevas vulnerabilidades en el software es a través de pruebas fuzz. Esto también se puede considerar como un error en la búsqueda bruta, ya que se genera una entrada aleatoria y se proporciona a todas las interfaces de entrada disponibles de la aplicación con la esperanza de que una cadena especialmente diseñada (como una cadena demasiado larga o una cadena con caracteres especiales) pueda causar software para bloquearse. Una vez que el software se bloquea, la prueba de fuzz se detiene y permite al investigador de vulnerabilidades analizar la entrada en la que se bloqueó la aplicación. Si el bloqueo se puede activar de manera confiable (por ejemplo, cada vez que un conjunto particular de bytes proporcionado a la aplicación produce un bloqueo) y el flujo de ejecución podría desviarse a los datos controlados por el usuario en una memoria ejecutable, el error se clasifica como remoto error de ejecución de código. De lo contrario, si crash es un error confiable, no se puede convertir en ejecución de código, entonces se clasifica como un error de denegación de servicio.