Hace un par de días, durante un reto de seguridad, nos encontramos con la situación de tener que modificar con GDB el código de un binario para que realizara las acciones que nos interesaban y no para las que había sido programado; esto suele usarse en los retos tipo “crack me” o “patch me”. Todo sea dicho, al final no era la solución al reto, pero como todo reto, se suelen probar distintas opciones.

De forma resumida tenemos un programa con la función principal y dos funciones adicionales declaradas. En la función principal se llama solo a una de las dos funciones, en este caso a la función que llamaremos “malo”, pero nosotros necesitábamos que en vez de llamar a esa función llame a la otra función, la que llamaremos “bueno”.

Para comprender mejor la técnica de esteganografía comentada en la entrada del viernes, he realizado una serie de scripts en PHP que nos permiten realizar todo este procedimiento de manera automática, simplemente indicando los archivos a utilizar.

Un año más hemos acudido a las Jornadas SID (que ya van por su XI edición) del Ministerio de Defensa, y como el año pasado hemos estado sólo en la parte de acceso libre (jornadas 3 y 4); la bienvenida a esta parte pública de las jornadas corrió a cargo de D. Esteban Cueva Álvarez, Subdirector General TIC del Ministerio de Defensa, quien muy brevemente nos recordó a todos la importancia de la protección de la información no sólo en el ámbito de defensa, sino en general en cualquier entorno, haciendo especial hincapié en los relativos a infraestructuras críticas.

Tras las palabras de bienvenida, entró en escena un representante del CCN-CERT, quien presentó los servicios que el Centro ofrece a la Administración Pública en general y al Ministerio de Defensa en particular. De su charla, creo que fue particularmente interesante para todos la declaración de objetivos para este año 2012, en especial los relativos a correlación y generación de inteligencia de las alertas generadas por el servicio de sondas de Internet del CCN-CERT, así como la presentación de CARMEN para la aplicación de técnicas de minería de datos, aún en fase piloto pero con muy buena pinta… Además de previsiones, formación, objetivos para este año… resalta (en rojo :) dos ideas fundamentales para cerrar la charla: cooperación e intercambio de información. Nos suena, ¿no? :)

En esta ocasión vamos a seguir hablando sobre esteganografía, concretamente sobre una de las técnicas que se pueden utilizar para ocultar cualquier tipo de información dentro de ciertos tipos de archivo, como por ejemplo imágenes o audio.

El método en cuestión es conocido como LSB (Least Significant Bit) y como su nombre indica consiste en aprovechar el bit menos significativo de cada byte para guardar información en él. En la introducción que se hizo en este mismo blog sobre esteganografía ya se comentó esta técnica, pero esta vez vamos a entrar un poco más en detalle y para hacer más comprensible la técnica vamos utilizar un ejemplo basándonos en una imagen en formato png (llamada “A”) en la que queremos ocultar un documento de texto (llamado “B”), creando la imagen “A+B”.

(N.d.E. A partir de ahora, y debido al volumen y calidad de las colaboraciones de Borja Merino, pueden encontrar todas sus entradas, futuras y pasadas, en el menú de autores ubicado en el lateral de la derecha.)

Una de las herramientas más utilizadas para analizar e identificar posibles shellcodes es libemu. La idea de esta librería, escrita en C e implementada en frameworks como Dionaea —de la que por cierto ya hablamos en el blog aquí y aquí— o PhoneyC, es emular instrucciones x86 e identificar/hookear llamadas a la API de Windows, con la que poder obtener información suficiente del código sin necesidad de llevar un análisis exhaustivo con debbugers como Inmunity u Olly.

Libemu utiliza técnicas heurísticas GetPC (Get Program Counter) para localizar shellcodes que utilizan encoders como shikata ga nai, fnstenv_mov, etc. Raro es encontrarse payloads que no utilicen algún tipo de cifrado o encoder para intentar evadir IDS/AV, por lo que esta característica lo hace realmente útil para buscar posibles shellcodes en ficheros .pcap, exploits, pdf, etc. Entender cómo funcionan estos métodos GetPC será fundamental para entender exactamente cómo trabaja libemu y saber así también cuáles son sus limitaciones y porque es incapaz de detectar determinados shellcodes. Los métodos GetPC (que vagamente se explicaron en el post “Buscando buffer overflow desde Wireshark” ) son simplemente instrucciones que ayudan a nuestro código a localizarse a si mismo dentro del espacio de direcciones del proceso. Esto es importante si lo que queremos es que nuestro código sea portable y que no dependa de direcciones ‘hardcodeadas’ (por ejemplo, cuando escribimos exploits y desconocemos en qué dirección de memoria se va a alojar nuestro payload).

Este es el primer post de una serie elaborada por José Luis Chica y Guillermo Mir. En ésta se quieren recoger los pasos que se pueden realizar (en muchos casos creemos debería ser imperativo realizar) para instalar y securizar un servidor Apache. Existen múltiples entradas y páginas que explican, de manera separada, como realizar diversas tareas, pero nosotros nos hemos propuesto exponerlas todas en esta serie, de manera que puedan servir de guía a todos aquellas personas que se han de instalar o gestionar un servidor de estas características. El sistema operativo que vamos a usar en los ejemplos es un Linux con distribución Debian Squeeze (6), pero esto sólo va a influir en las rutas dónde se encuentran los distintos ficheros de configuración.

Primer paso: Ocultando información

Una instalación por defecto de Apache muestra cierta información relacionada con el entorno donde ha sido desplegado. Dependiendo del sistema operativo, esta información puede variar pero en general, un posible atacante puede recopilar datos muy útiles que le puedan aportar vectores de ataque adicionales. Así pues, solo tendría que comprobar si existen vulnerabilidades conocidas en las versiones de las tecnologías utilizadas.

Como muchos de vosotros sabréis hay un ámbito de la seguridad que nos preocupa especialmente y es el que concierne a los más pequeños. Como en muchos otros aspectos ellos son los más vulnerables al uso (y abuso) que se pueda hacer de la tecnología. Por la exposición que supone y por la vulnerabilidad a la que pueden estar sometidos lanzamos hace un tiempo Hijos Digitales, un blog donde intentamos enseñar a los más mayores y a los más pequeños a convivir tecnológicamente.

Dentro de esta línea nos gusta participar, en la medida de lo posible, en aquellos foros que nos permitan dar visibilidad a esta inquietud, sin alarmismo pero siendo totalmente realista. En este sentido hoy vamos a analizar la amenaza, real o potencial, que puedan llegar a ser las redes sociales para los menores, y lo haremos en la mesa redonda que tendrá lugar hoy de 13h a 14:15h en el Café Comercial de Madrid, situado en la Glorieta de Bilbao.

Siguiendo con la serie de posts sobre monitorización de entornos no cooperativos, y recapitulando un poco, debemos tener -al menos parcialmente- claro qué queremos monitorizar y dónde y cómo hacerlo. Seguramente hemos diseñado y desplegado agentes, al menos los más sencillos, capaces de detectar la presencia de detonantes en algunos de los entornos no cooperativos que veíamos en el último post y, una vez detectado el detonante, hacer “algo”. Ahora viene el determinar qué es, o qué debería ser, ese “algo”.

Lo más inmediato que se nos puede ocurrir ante la activación de un detonante es, obviamente, enterarnos. Tan sencillo como eso. Así, cuando desplegamos el primer, el segundo o el tercer monitor de entornos no cooperativos (o de entornos cooperativos, da igual), seguramente lo primero que se nos ocurre es recibir las alertas de monitorización a través de correo electrónico. Simple y efectivo: cuando sucede algo que me interesa, me envío un mail; y como además hoy en día puedo acceder a mi correo electrónico desde casi cualquier dispositivo y en cualquier momento y lugar, paso a estar notificado con un esquema 24x7x365 con un esfuerzo mínimo. Vamos, una especie de Google Alerts de andar por casa :)

(N.d.E. Después de las entradas técnicas de los últimos días, hoy traemos una visión diferente y más “fresca” del cloud)

Desde hace ya tiempo existe un consenso general sobre el hecho de algo está pasando, algo grande y profundo que, todavía hoy, no estamos muy seguros de lo que en realidad es.

Mucho se ha hablado acerca del cloud computing, y no es mi intención aburrir más a la audiencia con el tema. Ya parece que más o menos estamos todos de acuerdo de lo que estamos hablando. ¿O no?

Hace un par de años cayó en mis manos un estudio sesudo de una fundación innovadora acerca de eso que estaba generando tanto entusiasmo y alboroto. Me gustó la explicación que daban acerca del concepto. Se preguntaban entonces que era exactamente el cloud computing: ¿la evolución de internet? ¿Un nuevo modelo de computación? ¿Una forma de ofrecerlo todo como servicio? ¿O quizá suponía la industrialización de las tecnologías de la información, como ocurrió hace un siglo con la electricidad cuando se empezó a usar de forma masiva en la economía y en la sociedad?

El cloud computing, en su opinión, era todo lo mencionado y algo más. Era como la fábula de los ciegos y el elefante. Cada uno toca una parte diferente del elefante. Después comparan lo que han percibido y se dan cuenta de que están en completo desacuerdo.

Y bien; ¿cuál es el mensaje oculto? :-)

En principio, la imagen no parece más que ruido blanco. ¿Podría tratarse entonces de un reto de esteganografía, como el publicado hace poco? Esperamos que hayáis probado unas cuantas técnicas, pero no es el caso :-)

Un detalle curioso, si revisamos el código fuente de la página, es que la imagen la “devuelve” un script en PHP; no es un simple enlace a un fichero JPG o PNG estático. Tratándose éste de un blog sobre seguridad, y dado que lo que ahora está “de moda” es la seguridad web, sobretodo las inyecciones SQL y similares, esperamos también que hayáis intentado buscarle las cosquillas a ese foo.php. Tampoco va por ahí…

Pero el hecho de que la imagen se genere dinámicamente sí es importante. De hecho, si visitamos la URL de la imagen y le damos varias veces al botón de “refrescar” algo pasa, ¿no? ;-) De vez en cuando sale “algo” como subliminal, y los entrenados en técnicas de lectura rápida (o los aficionados a las pestañas ;-) puede que ya tengan el mensaje oculto en su poder. Pero ¿qué es exactamente lo que produce ese efecto óptico, y cómo podemos hacer que el mensaje se “quede quieto”?