¿El ganador del Cyber Grand Challenge de DARPA realmente descubrió vulnerabilidades previamente desconocidas?

11

DARPA anunció un ganador el 4 de agosto de 2016 de su Cyber Grand Challenge DARPA Cyber Grand Challenge . El concurso fue descrito como

  

diseñado para acelerar el desarrollo de sistemas avanzados y autónomos que pueden detectar, evaluar y parchar vulnerabilidades de software antes de que los adversarios tengan la oportunidad de explotarlos. Los siete equipos que compiten en el evento final de hoy estaban compuestos por piratas informáticos, académicos y expertos en sistemas cibernéticos del sector privado.

Describieron el desafío real como:

  

Durante casi 10 horas, los competidores jugaron el ejercicio clásico de ciberseguridad de Capturar la bandera en un banco de pruebas creado especialmente para computadora, con una gran variedad de errores ocultos dentro de un software personalizado y nunca antes analizado. Las máquinas tuvieron el desafío de encontrar y parchar en segundos, no en los meses habituales, un código defectuoso que era vulnerable a ser pirateado, y encontrar las debilidades de sus oponentes antes de que lo hicieran los sistemas defensores.

El sistema ganador, Mayhem, se invitaría formalmente a participar en la competencia DEF CON Capture the Flag, "marcando la primera vez que se permitirá que una máquina juegue en ese torneo históricamente humano".

Leí y releí el material en DARPA y todavía no puedo creer que un sistema automatizado haya encontrado algo en el nivel de abril de 2014 error de Heartbleed . Me pregunto si las vulnerabilidades fueron más en el nivel de los avisos de seguridad de Microsoft publicados o las actualizaciones recomendadas o similares (en otras palabras, el "buscador de errores" es más un instalador de parches automático).

¿Alguien sabe cuál era el nivel técnico del banco de pruebas de desafío DARPA en relación con las vulnerabilidades reales de Heartbleed o similares? Supongo que descubriré cuándo Mayhem realmente compite contra humanos en la competencia CTF, pero en este momento tengo dudas.

    
pregunta Dalton Bentley 07.08.2016 - 20:56
fuente

1 respuesta

8

El banco de pruebas DARPA, CGC (Cyber Grand Challenge), fue una plataforma Linux modificada (DECRETO). Sus binarios (el código mecanizado compilado para el sistema) contenía solo 7 llamadas al sistema (por ejemplo, terminar, recibir, fdwait, asignar, etc.). Dentro del código del sistema en su conjunto, se crearon los binarios de desafío (CB) de DARPA con una o más vulnerabilidades a fuzzing, es decir, vulnerables a la entrada de algún carácter.

Uno de los primeros ejemplos de pruebas de fuzz fue el "Mono" de Steve Capps para detectar errores en MacPaint mediante la introducción de eventos aleatorios en el código. "Mono" alude a que "mil monos en mil máquinas de escribir eventualmente escribirán todas las obras de Shakespeare", es decir, si envía suficiente información aleatoria o programada a un programa, eventualmente encontrará una manera de bloquearlo. Por lo general, las pruebas Fuzz no encontrarán amenazas de seguridad que no causen bloqueos de programas, por ejemplo, spyware, muchos virus, gusanos, troyanos y registradores de teclas. Sin embargo, encontrará vulnerabilidades basadas en la entrada inesperada del programa (o errores de código relacionados con la entrada del programa), por lo que pudo haber encontrado el error Heartbleed, que fue un error causado por la validación incorrecta de la entrada en la implementación del TLS (Capa de transporte Protocolo de seguridad) (en OpenSSL).

El equipo ganador, Mayhem, utilizó un ejecutor simbólico (Mayhem) junto con un fuzzer dirigido (Murphy). Un ejecutor simbólico es familiar para aquellos de ustedes que han trabajado con depuradores simbólicos en entornos de desarrollo integrado, es decir, es básicamente un interpretador que recorre el código y permite la asignación y el seguimiento de valores simbólicos para entradas en varias partes del código de ejecución. En otras palabras, el equipo de Mayhem pudo analizar estáticamente partes de los CB (Challenge Binaries) con Mayhem para detectar (o analizar las sugerencias de Murphy) las vulnerabilidades de los códigos. Este fue un requisito del desafío DARPA, es decir, para encontrar una vulnerabilidad y demostrarla, es decir, POV (Prueba de vulnerabilidad). Desafortunadamente, la ejecución simbólica no se escala muy bien ya que la cantidad de rutas en un programa crece exponencialmente y puede ir infinita con iteraciones de bucle ilimitadas, por lo que las heurísticas o la búsqueda de rutas (ingrese a Murphy Fuzzer) para resolver parcialmente este problema de explosión de rutas como ayuda paralela también).

El DARPA CGC (el desafío) requería que los equipos no solo localizaran las vulnerabilidades en los CB (binarios de desafío), sino que documentaran a aquellos con un POV (prueba de vulnerabilidad) y repararan la vulnerabilidad con un parche de reparación binario (RB) . Ese parche se probaría para el rendimiento, tanto el funcionamiento correcto sin la vulnerabilidad como el impacto del rendimiento literal en el código relevante (tiempo de ejecución). Todo esto es bastante sorprendente teniendo en cuenta que a un humano no se le permitió contribuir a nada de lo que acabo de describir.

Puedes leer más en el blog del equipo ganador de Mayhem aquí ¡Liberando a Mayhem! , obtenga las reglas del Gran Desafío de DARPA y otros documentos aquí Documentos relacionados con el Gran Desafío de Darpa , lea acerca de la confusión en Pruebas de Fuzz y ejecución simbólica aquí Ejecución simbólica .

    
respondido por el Dalton Bentley 08.08.2016 - 19:26
fuente

Lea otras preguntas en las etiquetas