¿Es fácil o no encontrar vulnerabilidades en los principales navegadores?

Es una carrera entre las personas que quieren arreglar las vulnerabilidades y las personas que quieren explotarlas. Encontrar vulnerabilidades es difícil: escribir el código correcto es mucho más difícil que escribir el código casi correcto .

Supongamos (números extraídos) que los propios autores encuentran y solucionan el 99% de los defectos de seguridad en los productos lanzados, o los informan de forma privada a los autores. Eso significa que el 1% de los defectos de seguridad se hacen públicos a través de un exploit (un día cero ). Solo escuchas sobre las hazañas publicitadas, no sobre las que están arregladas silenciosamente, por lo que el 1% es todo lo que escuchas. Los autores y los analistas tienen que corregir cada vulnerabilidad para poder hacer un producto completamente seguro; los "piratas informáticos" solo necesitan encontrar una vulnerabilidad no solucionada.

Pero en realidad es peor que eso: incluso en el caso del 99%, cuando los autores lanzan una nueva versión, no todos se actualizan de inmediato. Hay otra raza: la carrera entre la explotación y el parche. Una vez que la actualización está disponible, los crackers pueden estudiar las diferencias con la versión anterior y crear exploits para versiones anteriores que las personas aún están ejecutando. Esto deja muchas máquinas expuestas.

Existen varias técnicas para buscar vulnerabilidades, utilizadas por ambos lados por igual. Fuzzing es uno de ellos: intente enviar datos aleatorios a un programa y ver si reacciona de manera interesante. Por ejemplo, si el programa falla (lo que en sí mismo es a menudo una denegación de servicio), estudie la forma en que se bloquea con cuidado; a menudo, la creación de los datos de entrada le permite escalar para ejecutar código arbitrario. Otro enfoque es análisis estático : ejecuta análisis automáticos en el código fuente o en el código compilado, para buscar patrones sospechosos (por ejemplo, buscar sin marcar acceso a la matriz) o verifique la ausencia de ciertos tipos de mal comportamiento (por ejemplo, probar que todos los accesos de la matriz no están verificados). El análisis estático puede complementarse con revisiones manuales, para buscar aspectos que las herramientas automatizadas no son suficientes para detectar (por ejemplo, revisar que todos los archivos temporales se crean de forma segura). La experiencia ayuda, por supuesto, a veces alguien pensará "hey, este es un problema difícil, me pregunto si los desarrolladores entendieron bien el caso".

Recomiendo leer la presentación de proceso de auditoría de OpenBSD y seguir estudiando el proyecto OpenBSD. Este es un proyecto de código abierto, con discusiones abiertas, y hacen de la seguridad una prioridad. No conozco una presentación más completa de su proceso de auditoría de seguridad; Puede encontrar más información al respecto en sus listas de correo .

Más generalmente, consulte los anuncios de seguridad para software de código abierto (por ejemplo, una distribución de Linux). Cuando se anuncie un parche de seguridad, mire la descripción de la vulnerabilidad, la fuente original y el parche. Trate de tener una idea de qué patrones pueden ser problemáticos, cómo se encontraron (el anuncio de vulnerabilidad a menudo tiene un enlace a una descripción más detallada) y cómo se solucionaron.

Permítame tratar de abordar la parte "parcheada" de su pregunta: Encontrar los problemas, al menos en el software, es un orden de magnitud más fácil que arreglar . Considere la lista más corta posible de obstáculos para superar:

0) ¿Es un error o una característica?
1) ¿Es este el defecto real, o simplemente una manifestación de un problema más profundo? 2) ¿Es el problema lo suficientemente grave como para justificar una solución?
3) ¿Es esto incluso solucionable? (por ejemplo, si su programa se escribió bajo el supuesto de que las fechas de soporte posteriores al año 2038 no tienen sentido o que nadie necesitaría un archivo de más de 4 GB , podría ser necesaria una reescritura completa)
4) Si solucionamos esto, lo que dependa de la conducta se romperá. ¿Es eso aceptable? ¿Necesitamos idear soluciones alternativas? ¿Cuáles son las probabilidades de que esas soluciones tengan sus propios errores? 5) "La corrección de un error siempre presenta al menos dos errores nuevos"
6) ¿Existe un presupuesto (en tiempo y dinero) para corregir el error, probar y desplegar la solución?

Y esto es todo antes de que comience la política de la empresa: después de todo, se ha sabido que algunas compañías se niegan a reconocer los informes de errores y mueren (por cualquier motivo).

Algunos pensamientos más:

Si los piratas informáticos pueden detectarlos, ¿por qué los analistas de seguridad no pueden detectarlos y parchearlos?

Ten en cuenta

• para cualquier producto dado, hay un número fijo de personas que crean y arreglan el producto y un número casi ilimitado de personas disponibles para romper o explotar el producto. La cantidad de personas que intentan romper el producto puede estar más o menos correlacionada con la popularidad del producto, su preferencia y la naturaleza de la información que maneja o protege. Entonces, mucha gente está intentando romper IE (muy popular), software de banca en línea (alto valor) y no mucha gente está intentando romper un producto de nicho creado con un propósito oscuro.

• "un joven pirata informático descubre un gran error en el producto" es un titular excelente . Considere sus fuentes cuando parece que solo los jóvenes están encontrando errores. "El viejo tío crujiente rompe el producto en el curso de hacer negocios" no va a vender ningún periódico en línea. Los jóvenes hackers están encontrando errores y haciendo titulares. A los piratas informáticos antiguos se les suele llamar "analistas de seguridad" y muchos de ellos tienen trabajos que implican la búsqueda silenciosa de proezas (solo un poco de lengua).

• Solucionar un error no es tan difícil. Solucionar un error y no romper cualquier otra cosa suele ser bastante difícil. Peor aún, son los errores que surgen del mal uso que simplemente no se pueden arreglar

También, sueño con encontrar una vulnerabilidad en un software importante, como IE o Chrome. ¿Es fácil? ¿Es sistemático o es aleatorio? ¿Qué libros necesito leer para detectarlos a tiempo?

Si está especialmente interesado en los navegadores web, le sugiero que se familiarice con la tecnología que rodea la web: representación HTML, Script de Java, Active X, AJAX, SSL, DNS, CSS: todo lo que se transmite y procesa el navegador web. La comprensión de estas tecnologías y cómo funcionan los navegadores es la clave de esta área.

No hay un solo libro. Ni siquiera hay una lista de lectura. Esta área cambia RÁPIDO: las correcciones nuevas para los principales navegadores se publican con mucha frecuencia, las nuevas tecnologías y los nuevos navegadores se publican anualmente. El ciclo de desarrollo en esta área es en realidad más rápido que el ciclo de publicación para cualquier cosa que no sea un libro electrónico. Puede obtener una lectura de fondo decente sobre las tecnologías que mencioné, pero muy pronto va a querer leer sobre los estándares WWW reales (como www.w3c.org) para que conozca los detalles actualizados de estas tecnologías.

El pirateo es sistemático y al azar. Necesita saber lo suficiente sobre el dominio en el que está pirateando para poder hacer conjeturas razonablemente buenas sobre qué intentar para encontrar un exploit. Es probable que casi todos los productos modernos sean demasiado complicados para usted, ya que intente con absolutamente cada entrada y salida, por lo que se requerirá un cierto grado de buenas suposiciones para probar una posible área de vulnerabilidad. El mejor análisis que conozco es el que ve el sistema como un todo, y puede profundizar rápidamente en la mayoría de las áreas y ver cómo los factores ambientales unidos pueden contribuir a hacer que un producto sea vulnerable.

Ahora sé cómo programar en C / C ++ / Java. Puedo aprender fácilmente la Asamblea.

Honestamente, no veo cómo la Asamblea le ayudará. En ocasiones, es útil saber el idioma del código base del producto, SI tiene acceso a él. Pero lo más importante es saber qué se supone que debe hacer el producto y poder analizarlo de manera efectiva para averiguar dónde está fallando en lo que se debe hacer, o dónde lo que está haciendo hacer es indeseable. resultados.

Las respuestas aquí son geniales. Aquí hay otra manera de pensarlo.

Todo el software tiene errores. Una tasa de defectos estándar es de 2 a 10 defectos por mil líneas de código; alguna fracción de estos serán defectos relevantes para la seguridad (de severidad variable). Los navegadores tienen millones de líneas de código. Por lo que sabemos, un navegador típico puede tener cientos o miles de defectos de seguridad al acecho, a la espera de ser descubierto.

Supongamos que hay 500 vulnerabilidades de seguridad desconocidas en el navegador, que aún no se han descubierto. Digamos que si realiza 500 horas de trabajo (fuzzing, revisión de diseño, revisión de código, etc.), descubrirá una vulnerabilidad, una extraída al azar del grupo de 500 vulnerabilidades.

¿Cuánto tiempo tarda un atacante en encontrar su primera vulnerabilidad desconocida anteriormente? 500 horas = 3 meses-persona.

¿Cuánto tiempo tarda un defensor en encontrar todas de las vulnerabilidades, para que puedan ser reparadas? Al menos 500 * 500 = 250,000 horas = 125 persona-años. De hecho, eso es una subestimación. Debido a un fenómeno matemático conocido como el problema del coleccionista de cupones, el número real es más de 500 * log (500) * 500 = 1.5 millones de horas = 776 persona-año. Esto ni siquiera tiene en cuenta la cantidad de trabajo para solucionar los problemas una vez encontrados, probarlos para solucionarlos, enviarlos a los usuarios, o la probabilidad de que alguna fracción de los arreglos pueda introducir nuevos problemas por su cuenta. En la práctica, la situación del defensor es aún peor de lo que podría sugerir.

Así que puedes ver que el atacante tiene una ventaja tremenda sobre el defensor. Con un poco de esfuerzo, el atacante puede encontrar una vulnerabilidad (ya que al atacante no le importa cuál encuentra; cualquiera lo hará); mientras que el defensor requiere un esfuerzo tremendo para encontrarlos y solucionarlos. Debido a que el defensor debe encontrar todas las vulnerabilidades, mientras que el atacante solo necesita encontrar una, el atacante tiene una ventaja tremenda.

Esta es una de las razones por las que la gente dice "no puedes atacar la seguridad después del hecho" o "no puedes probar la seguridad". Si ha creado el software con prácticas de seguridad inferiores, es probable que ninguna cantidad razonable de pruebas después del hecho sea suficiente.

Las respuestas mencionadas anteriormente son realmente excelentes y me gustaría agregar algo desde la perspectiva de la complejidad computacional, específicamente para abordar el problema de la búsqueda de vulnerabilidades en cualquier caso general (o en cualquier código dado). La idea es similar a encontrar obstrucciones, que en cierto sentido son "pruebas" de que una computación no puede completarse en tiempo "realista" (tiempo polinomial). Ahora, no es factible encontrar un algoritmo de tiempo polinomial que pueda proporcionar la existencia de una familia de obstrucción.

Una familia de obstrucciones es simplemente un conjunto de etiquetas de obstrucción donde cada etiqueta apunta a una obstrucción bien definida y construida explícitamente. Entonces, imagine un escenario en el que conozcamos a todos los miembros de este conjunto, luego podemos parchearlos fácilmente, pero de lo contrario, para encontrar miembros de este conjunto, uno tendría que probar todas las combinaciones posibles que no sean realistas. En la práctica, encontrarlos por lo tanto parece aleatorio, sin embargo, puede haber pistas sobre un procedimiento en particular donde pueden surgir vulnerabilidades, por lo que definitivamente podemos encontrar algunos miembros, pero no todos.

Encontrar vulnerabilidades de día cero es aún más difícil, sin embargo, como veo en otras respuestas, hay algunas listas de verificación que pueden usarse para ayudarlo en el proceso. En general, sigue siendo un caso de éxito o falta, algunas personas tardan años en encontrarlas, mientras que otras las encuentran con relativa rapidez.

Otra conexión que veo es especialmente con los navegadores, puede que en cierto sentido sea más fácil encontrar vulnerabilidades, ya que hay muchos componentes en el navegador, como ya sabrás, la base de datos de metasploit sigue acumulándose con ellos. De modo que quizás sea un buen lugar para comenzar y, si puedo sugerirlo, busque una vulnerabilidad específica y lea cómo se encontró, luego trate de encontrarlo usted mismo, eso le dará una buena práctica. Diviértete :)