Estas aquiContenido / La caza de bugs, paso a paso
La caza de bugs, paso a paso
No es nada habitual que un reputado "cazador de bugs" desvele públicamente sus métodos, pero Tom Ferris -un nombre habitual en la sección de agradecimientos de los boletines de Microsoft- lo ha hecho, no sin antes advertirnos que encontrar bugs en productos Microsoft no es tan difícil como parece: "Es un asunto muy básico. Me sorprende que Microsoft no encuentre estas cosas por sí misma."
Ferris ha explicado a eWEEK [1] la metodología que utiliza, y que consta básicamente de los siguientes pasos:
- Saber dónde mirar: un buen consejo es mirar en las partes del programa donde se validan entradas, sobre todo cuando provienen de un protocolo exterior, como RDP. Tampoco es mala idea mirar los sitios que Microsoft acaba de parchear. "Muchas veces introducen un nuevo fallo donde han parcheado", dice Ferris.
- Obtener el código: y puesto que el de Microsoft es propietario no queda más remedio que recurrir a la ingeniería inversa, utilizando depuradores como SoftICE, y desensambladores como IDA Pro para traducir las DLLs -o los ejecutables- a ensamblador.
- Encontrar el agujero: a tal fin, Ferris construye algún tipo de script capaz de probar miles de datos intencionadamente malformados contra los puntos del programa que se sospechan débiles. Eventualmente, se logra hacer caer al programa.
- Analizar la vulnerabilidad: es decir, comprobar si es o no crítica, si es factible escribir un exploit, etc.
Artículo completo:
- Bug Hunting, Step by Step [eWEEK]
Etiquetas
Uhmm... El punto segundo me da que pensar...
¡A ver si van a tener razón los que dicen que es más seguro el código propietario...!
Porque de las palabras de Ferris parece deducirse que no disponer del código entraña un paso más, una mayor dificultad.
¿Cómo lo véis vosotros?
No tiene porqué ser más seguro el código propietario.
Aunque es cierto que el no disponer del código entraña un paso más, detrás del código libre hay mucha gente trabajando que, a su vez, verifica y comprueba la seguridad de éste.
Realmente, creo que es un tema en el que nunca nos pondriamos de acuerdo, porque hay opiniones para todos los gustos, dependiendo del sistema operativo que use cada uno y otros factores.
Lo que es cierto es que seguro no hay nada :)
Lo que dices pareciera tener sentido, y en realidad lo tiene, pero cuantas veces vimos en el pasado que la seguridad por oscuridad es la peor forma de dar seguridad.
Puedo decirte que en en la empresa donde trabajo se hizo un concurso para descubrir vulnerabilidades, y la premisa era demostrar que podría encontrarse sin conocer ni el código fuente, ni la estructura interna del sistema. Da fe de que podía accederse y borrarse datos en menos de 15 minutos, el pedazo de portátil que gané, y el pedazo de HomeCinema que gano otro compañero. Ahora ya solucionado, no se presupone en la empresa que el ocultar el código fuente y la estructura del sistema nos de seguridad alguna, sólo una pequeña cantidad de tiempo extra.
--
Tomad y ejecutad todos en él, porque éste es mi Quantum. (Peibol)
--
Tomad y ejecutad todos en él, porque éste es mi Quantum. (Peibol)