ReYDeS's blog

El análisis del código fuente no siempre es posible. Esto es particularmente cierto cuando se evalúan aplicaciones propietarias con código fuente cerrado. Esto de ninguna manera previene el profesional en ingeniería inversa examine la aplicación; simplemente hace el examen sea algo más difícil. La auditoría binaria requiere un conjunto de habilidades más amplio comparado con la auditoría del código fuente.

Si se tiene la fortuna de tener acceso hacia el código fuente de la aplicación, el trabajo para realizar ingeniería inversa a la aplicación será más fácil. Se seguirá un proceso laborioso y largo para entender exactamente como la aplicación realiza cada tarea, pero esto debería ser más fácil comparado con abordar el binario de la aplicación correspondiente. Existen una serie de herramientas las cuales intentan escanear el código fuente automáticamente, para detectar prácticas de programación deficientes. Estas herramientas pueden particularmente ser útiles para aplicaciones grandes.

Las vulnerabilidades existen en el software por un diverso número de razones. Algunas personas podrían decir, todas estas provienen de la incompetencia del programador. Aunque hay quienes nunca han visto un error en la compilación. En la actualidad las razones son mucho más variadas y pueden incluir:

• Falta de verificación para las condiciones de error
• Pobre comprensión sobre los comportamientos de las funciones
• Protocolos diseñados pobremente
• Inadecuadas pruebas para las condiciones de límites

Con todas las diversas técnicas ya conocidas sobre Hacking Ético y Pruebas de Penetración, la pregunta es ¿Porqué se querría recurrir a algo supuestamente tan tedioso como la ingeniería reversa?. Pues se debería estar interesado en la ingeniería inversa, si se requiere expandir las habilidades y conocimientos sobre evaluación de vulnerabilidades, más allá de únicamente utilizar las herramientas y trucos estándar. No hace falta tener muchas capacidades para ejecutar un escaner de vulnerabilidades y reportar sus resultados.

¿Dónde encaja la ingeniería inversa para el profesional en Hacking Ético y Pruebas de Penetración?. La ingeniería inversa es frecuentemente vista como el arte del “Cracker”, quien utiliza sus conocimientos y habilidades para eliminar la protección de copia desde un software o medio. Como resultado de esto, se podría dudar en emprender cualquier esfuerzo de ingeniería inversa. DMCA (Digital Millennium Copyright Act), se presenta frecuentemente cuando se discute la ingeniería inversa de software.

En los recientes años, los proveedores han adoptado algunos principios como parte de sus programas para recompensar el reporte de fallas. Microsoft por ejemplo, alguna vez mencionó el hecho de no demandar a los investigadores quienes envíen de manera responsable las potenciales vulnerabilidades de seguridad en los servicios en linea. Mozilla también tiene un programa para la recompensa de errores, por informes válidos o vulnerabilidades críticas. Google también ofrece recompensas en efectivo por las vulnerabilidades encontradas.

Aquellos quienes descubren vulnerabilidades usualmente están motivados para mejorar la protección de la industria. Esto realizado mediante la identificación y ayuda en la eliminación de software peligroso en los productos comerciales. Un poco de fama, admiración y derechos para jactarse son agradables también para aquellos con bastante ego. Los proveedores de otro lado, son motivados para mejorar sus productos, evitar problemas legales, no tener malas noticias en lo medios de comunicación, y mantener una imagen pública responsable.

Entender las fases para una divulgación responsable de vulnerabilidades es fundamental. Este procesose resume a continuación. Sin embargo se sugiere revisar el documento de la “Organization for Internet Safety”, o por su traducción al idioma español, La Organización para la Seguridad de Internet. La cual publicó hace muchos años un documento titulado “Guidelines for Security Vulnerability Reporting and Response”, o por su traducción al idioma español, Directrices para el Reporte y Respuesta de Vulnerabilidades de Seguridad.

Antes de la lista Bugtraq fuese creada, los individuos quienes descubrían vulnerabilidades y las maneras de explotarlas, únicamente se comunicaban directamente los unos con otros. La creación de Bugtraq proporcionó un foro abierto para estos individuos, de tal manera podían descubrir los mismos temas y trabajar de manera colectiva. El fácil acceso hacia las maneras de explotar las vulnerabilidades dio paso a diversas herramientas “fáciles” disponibles en la actualidad, las cuales permiten a personas quienes no entienden una vulnerabilidad explotarlas satisfactoriamente.

Desafortunadamente casi todos los productos de software actuales están plagados de fallas. Estas fallas pueden presentar serias consecuencias para los consumidores. Para los clientes quienes dependen en gran medida de las aplicaciones para realizar funciones empresariales fundamentales, los errores pueden ser paralizantes, y por lo tanto deben tratarse adecuadamente. La mejor manera de abordar el problema es un tema complicado, pues involucra dos actores quienes usualmente tienen muy diferentes perspectivas sobre como lograr una resolución.