Ir al contenido principal

Entradas

Mostrando entradas de 2013

Técnicas anti-depurador (anti-debugging)

Una de las herramientas más utilizadas en la ingeniería inversa de software son los depuradores. Hay múltiples razones por las que un programa querría poder evadir el uso de un depurador, ya sean plenamente legítimas o más oscuras. Muchos virus y malware, por razones obvias, suelen usar técnicas para dificultar la depuración de su código, pero también hay casos legítimos donde es interesante tratar de evitar que cualquiera pueda descifrar nuestro código. Un ejemplo claro son los sistemas de protección anti-copia. Por otro lado, conseguir una protección total contra la depuración de un código no es posible. Sólo depende de la pericia y de lo motivado que esté el analista. En cualquier caso, es bueno conocer algunas de estas técnicas ya sea para proteger tu código o para poder saltártelas mientras haces ingeniería inversa de un malware.

El gobierno americano quiere que volvamos a confiar en los estándares de cifrado

Por mucho que la NIST (National Institute of Standards and Technology) quiera convencernos de que no creó sistemas de cifrado debilitados con el fin de que fueran fáciles de romper para la NSA, lo cierto es que parece bastante claro que se introdujeron puertas traseras en los algoritmos que sustentan la privacidad y la seguridad en Internet. El problema es que estos estándares de cifrado acaban formando parte de los estándares internacionales a través de ISO (International Organization for Standardization) , de la que forman parte 163 países, entre ellos el nuestro. A raíz de las filtraciones de Snowden, acabamos enterándonos (siempre según él) que en 2006 se certificó el estándar Dual EC DRBG 800-90 , que es la especificación para un generador de números aleatorios determinista necesario para la implementación de cifrados de flujo, como los usados en las conexiones HTTPS en Internet o en las comunicaciones móviles, y que dicha especificación tenía una puerta trasera para la NSA.

¿Son fiables los antivirus?

Cuando de virus y malware se trata, existen cientos de mitos que se propagan como verdades absolutas por la red, sin que nadie se plantee si son ciertas o no. Algunas de las más manidas son que MacOS o Linux no son vulnerables al malware, o que si no se visitan sitios "raros" no hay peligro. Pero la peor sin duda es pensar que si instalamos un antivirus, estaremos bien protegidos. Vamos a realizar un pequeño experimento que dejará asombrado a más de uno.

De cómo hemos perdido la batalla de la privacidad en Internet

Últimamente es raro el día que no aparecen noticias nuevas relacionadas con la privacidad en Internet y los esfuerzos de la NSA por escudriñar cada milímetro de la red de redes. El desencadenante de todo esto fue la información filtrada por Edward Snowden días después de que tuviéramos conocimiento del proyecto PRISM de la NSA (en colaboración con la GCHQ inglesa y el gobierno de Israel). Lo sospechábamos, pero ahora ya sabemos que grandes empresas como Google, Microsoft o Apple cede información privada de sus usuarios al Gobierno Americano. No en vano, la NSA ha hecho grandes esfuerzos por desarrollar técnicas de datamining con la intención de que nada escape a sus ojos y poder procesar las grandes cantidades de información a la que tienen acceso, tanto de ciudadanos americanos como de cualquier otra parte del mundo .

Evitando la protección de ejecución en la pila con ROP (Return Oriented Programming)

En un artículo anterior ya hice una introducción a la explotación de vulnerabilidades por buffer overflow . Durante mucho tiempo, este tipo de ataques era muy común pero, afortunadamente, cada vez es más difícil explotar este tipo de vulnerabilidades gracias a mejoras como NX (también conocido como DEP o PAX). Básicamente consiste en evitar que se pueda ejecutar código dentro del marco de la pila. Entonces problema solucionado -estarás pensando. Pues no.

Explotando vulnerabilidades: buffer overflow y shellcode

El anterior post lo dediqué a hablaros del funcionamiento de la pila en las llamadas a funciones con la intención de seguir profundizando hoy en los posibles problemas que pueden surgir de una programación poco cuidadosa. La mayoría de los problemas de seguridad que surgen a diario tienen su raíz en una vulnerabilidad del código ejecutable de un programa. Hoy voy a hablar de desbordamiento de buffers o buffer overflow y shellcodes.

La pila y las llamadas a funciones

Me sorprende la frecuencia con la que cada día aparecen nuevas vulnerabilidades en software hecho por buenos programadores. Conste que nos puede pasar a cualquiera (el que esté libre de pecado que tire la primera piedra), así que me gustaría dedicar un par -o tres, ya veremos- de artículos a tratar de concienciar (y concienciarme) sobre la programación de código seguro. Antes de entrar en harina voy a dedicar este artículo a aclarar cómo funciona la llamada a una función y el papel que juega la pila en todo esto. El ejemplo que voy a mostrar están desarrollados sobre arquitectura x86 y GNU/Linux.