Vulnerabilidad en printf (y III)

Vamos a finalizar esta serie de artículos con un ejemplo, sencillito, en el que intentaremos explotar la vulnerabilidad de la función printf.

En el post anterior ya aclaré la diferencia entre vulnerabilidad y explotación de la vulnerabilidad. Vamos a analizar un programa que permite usar la función printf para obtener acceso a otras zonas de memoria. Un programa en el que podremos explota esta vulnerabilidad.
El programa en cuestión es este:

#include<stdio.h>

main()
{
char string1[] = "123456789abcdef";
int i, j, k;
    char _userin[80];
    i = 100;
    j = i + 1;
    k =  j + 1;
    scanf("%s", _userin);
    printf("%s, %s",_userin);
  

    return 0;

}
Podemos descargarnos el ejecutable y el fuente desde este enlace.

Vemos que hay una incorrecta llamada a la funcion printf

printf("%s, %s",_userin);

Este fallo nos va a permitir explotar la  vulnerabilidad y poder acceder a otras partes de memoria.
Si ejecutamos el programa normalmente veremos que el programa finalizará anormalmente.

Esto deberá ocurrir casi siempre. Supongamos que estas líneas de código forman parte de un gran sistemas de programas y que normalmente esta sentencia está un una de las ramas de algún programa y que ha pasado desapercibida en las pruebas de funcionalidad y de calidad que se han realizado.

Ahora carguemos el programa en Ollydbg y y pongamos un breakpoint justo antes de la llamada a la función printf y otro justo antes de la exit.

Para facilitar la búsqueda de estas instrucciones solo tenemos que fijarnos en la imagen superior.

La llamada a la printf está un poco encima de punto de entrada al programa y la salida por debajo.

Damos Run (F9) y se nos parará en la función scanf, introducimos cualquier texto, en el ejemplo hemos introducido "qwerty"

Observemos la pila:

La primera entrada es la cadena de formato y las dos siguientes entradas son los parámetros que se supone que tiene la función. El primer parámetro en la pila es una referencia a la al la cadena de caracteres que hemos introducido.
La siguiente entrada en la pila es la que va a asumir la función printf como dirección del segundo parámetro.

Volvamos al primer parámetros que sabemos contiene la dirección de valor que hemos introducido. Y vemos que apunta a la siguiente entrada en la pila. En esa entrada tenemos los la codificación ASCII de el literal "qwerty" cuyos primeros caracteres son: 72657771 y sabemos que la función printf usará ese valor para buscar la siguiente cadena de caracteres.
Normalmente este valor correspondera o bien a una dirección no válida o no accesible por lo que el sistema finalizará anormalmente como hemos visto antes.

Ya estamos en el punto clave: si yo en vez de meter la cadena "qwerty" pudiera introducir la dirección de la memoria de la que deseo sacar información obtendré dicha información.

Vamos a intentar obtener el valor de la cadena de caracteres string1 del programa. En un supuesto real este valor podría ser el hash de una clave que se procesa en ejecución o cualquier otra información comprometedora.

La dirección donde está la cadena que queremos conocer está en 0x12FF70 como se puede si investigamos un poco las entradas en la pila.

Y que no se corresponde con ningún caracter ASCII representable por teclado.


Esto tiene fácil solución ya que es posible intruducir cualquier caracter hexadecimal usando la tecla Alt y el teclado numérico (no vale usar los números que estan encima del teclado alfabético). Además debemos introducirlos al revés (formato litte endian) así pues haremos lo siguiente:

                            Alt 112 (soltar Alt) Alt 255 (soltar Alt) Alt 18 (soltar Alt) Intro
                           
El programa se parará en el siguiente breakpoint y observemos la pila:



Que tiene muy buena pinta, solo tenemos que volver a dar Run (f9) y dejaremos que el programa se pare antes de salir para que podamos ver el resultado:

Conclusiones.

Como se puede ver es tan fácil que asusta y hemos de aprender a vivir con esto y tomar medidas para que lo que hemos visto no pueda suceder.

• La primera medida es una buena depuración y un buen juego de pruebas antes de liberar el programa. Las prisas y urgencias de última hora son un mal aliado.
• Dar cierta aleatoriedad a la ubicación de las variables en el programa de manera que no sea fácil predecir donde podemos encontrar información sensible una vez el programa esté en ejecución. Algo que raramente se hace pero que da bastante robustez a los programas.

Y con esto acabamos el estudio de una vulnerabilidad en una función muy usada y que es aplicable al otras funciones que trabajen con cadenas de formato

                           

Vulnerabilidad en printf (II)

Continuamos analizando la función printf y la vulnerabilidad que lleva incorporada. En el post anterior finalizamos viendo como quitando una variable en la llamada a la función se lograba acceder a la siguiente entrada en la pila.

Lo mismo se hubiera obtenido si en vez de eliminar una variable hubiéramos colocado una definición de formato más.

Partiendo de la llamada original a la función

printf("%s - i = %d - J = %d - k = %d\n", string1, i, j, k);

Hemos llegado a obtener un valor que estaba más afuera del ámbito del programa modificando la llamada

printf("%s - i = %d - J = %d - k = %d\n", string1, i, j);

Y se hubiera obtenido el siguiente valor con la siguiente llamada a la función
printf("%s - i = %d - J = %d - k = %d  %s\n", string1, i, j, k);

Podremos avanzar en la lectura de la pila más allá del ámbito de la función según la siguiente resta:

(Núm. de especificaciones de formato - Núm. de variables)

Ejecutemos nuevamente el programa  hasta el breakpoint que está junto antes de la llamada a la rutina de impresión. Y  observemos la pila.

Según lo visto hasta ahora se podría acceder a cualquier valor, por ejemplo a la cadena ASCII que contiene el valor del valor del nombre del programa.

Pomgamos en nuestro programa entonces la siguiente llamada de función

printf("%x%x%x%x%x%x%x%x%x%x%x%x\n%s");

Compilamos y ejecutamos el programa

 Nos interesa la segunda línea de la salida que es el valor que buscábamos.

Vulnerabilidades y explotación de las mismas.

 Para finalizar  y antes de entrar en el siguiente post donde veremos si es posible ir directamente a una posición de memoria directamente, hay que aclarar la diferencia que hay entre vulnerabilidad y explotación de la vulnerabilidad. 

Es evidente que en este ejemplo, la información que hemos obtenido pues no nos sirve de mucho. Pero podría ocurrir que  una de las entradas en la pila fuera el puntero a una dirección de memoria con información sensible (por ejemplo el hash de una clave). Podríamos obtener ese hash y poder efectuar contra el un ataque de diccionario o de fuerza bruta.

También en este caso  estamos trabajando con un control total sobre la cadena de formato que confeccionamos a nuestro gusto. 

 En una situación real de intento de ataque aprovechando esta vulnerabilidad no tendremos esa posibilidad de forma directa y probablemente debamos llegar a ella a traves de otra vulnerabilidad, quizá un desbordamiento de memoria.

Pero lo que tiene que quedar claro es que una cosa es la existencia de una vulnerabilidad y  otra que esa vulnerabilidad sea explotable para sacar algún beneficio.

. 

Hasta la próxima

 

Vulnerabilidad en printf (I)

Vuelvo a retomar este blog tras un parón motivado por causas ajenas (léase falta de tiempo).

Aunque sé que voy dejando alguna serie de entradas sin finalizar me ha animado a escribir este post una vulnerabilidad sobre la que leí algo y sobre la que me pareció instructivo profundizar: la vulnerabilidad de la cadena de formato (format string).

La forma más fácil de empezar a explicar lo que es la cadena de formato es recurrir a la función printf() que todo el que haya programado un poco ha conoce.
¿Quien no ha escrito alguna vez printf( "hola mundo"); ?.

Lo más llamativo de esta función es que no tiene un número fijo de parámetros. Gracias a esta flexibilidad podemos confeccionar textos que contengan tantas variables como necesitemos. Pero en esta bendición lleva grabada su maldición.

Lo primero que necesitamos es ver como el compilador resuelve el paso de un número variable de parámetros. Para necesitaremos un depurador y algo de conocimientos de arquitectura x86.

La Pila

La pila, también conocida por su nombre en ingles: stack, es una zona de memoria que es referenciada por dos registros y gestionada por unas instrucciones determinadas.
Tres conceptos básicos del manejo de pila:

1. Las instrucciones que manejan de forma explícita (1)  la pila son: push y pop. La primera coloca en la pila y la segunda la extrae. La pila es una cola LIFO (last input - first output).
2. La pila está referenciada por dos registros: el registro base de la pila (BSP) y el registro indicador del tope (ESP) de la pila.
3. En la arquitectura x86 la pila va desde las posiciones altas a las bajas. Esto quiere decir que a cada push que hagamos el registro ESP disminuye en 4 porque cada entrada de la pila es una palabra (4 octetos).

Conceptualmente hay que ver la pila como sistema en que las piezas se colocan y extraen por debajo.

No necesitamos saber nada más para poder entender el resto del artículo.

Las Herramientas.

Necesitamos el depurador para ser capaces de sacar el estado de un programa en un momento determinado de su ejecución. Por estado del programa se entiende: la memoria, los registros, la pila y la instrucción siguiente a ejecutar.
Vamos a usar el conocido ollydbg.
Este programa puede ser descargado de su página web y no necesita instalación. Simplemente con descomprimir el fichero ya podemos trabajar con él.

Necesitaremos también un compilador C. Para este ejemplo he usado Tiny C Portable  que no necesita instalación y que se puede descargar de esta página.
Podemos usar cualquier otro compilador pero en este caso no será posible seguir la práctica tal cual. Cada compilador resuelve de forma diferente las referencias a funciones, la estructura de los datos y otros procesos.

En este enlace podréis encontrar tanto los fuentes, aunque son mínimos, como las compilaciones para aquellos que tenga pereza por compilar programas.

En esta práctica voy a omitir bastantes pasos intermedios que he he debido realizar para centrarme en el concepto por lo que si no se tienen conocimientos de ensamblador ni se tiene habilidad con el manejo de ollydbg lo que aconsejo es usar el mismo compilador que he usado para la práctica.

Empezando

Tenemos  este simple programa:

main()
{
char string1[] = "123456789abcdef";
int i, j, k;
    char _userin[80];
    i = 100;
    j = i + 1;
    k =  4194382; //j + 1;
   
    //printf("%s - i = %d - J = %d - k = %d\n", string1, i, j, k);

    return 0;

}

Arrancamos Ollydbg y lo cargamos

Podemos ver la ventana dividida en 4 secciones en sentido de las agujas de reloj:

1. Área de programa
2. Registros
3. la Pila
4. La memoria

      

   Compilamos y ejecutamos:

                                      
                    
Cargamos el programa en Ollydbg. 

En la ventana del programa podemos observar que está marcada la siguiente instrucción a ejecutar, que es en este caso el inicio de programa (Module Entry). Nos vamos un poquito más arriba hasta la dirección 

004010B6. 

Nos posicionamos con cursor sobre ella y hacemos click para seleccionarla.
Creamos un breakpoint en esta instrucción pulsando F2. Veremos que la línea queda en rojo.
Analicemos la línea que hemos seleccionado. 

Se trata de una llamada a la función printf (ollydbg siempre que puede resuelve las direcciones con nombres)
                       
Ejecutamos pulsando la tecla F9 (O bien en el menú superior Debug -> Run) y el programa se ejecutará hasta llegar al breakpoint marcado. Observamos la ventana 3  que es la ventana de la pila.

                           

Ahí tenemos los parámetros que se van a pasar a la función: La cadena de formato, el primer parámetro con la cadena de caracteres, y los siguientes parámetros con los valores 64, 65 y 66 que se corresponde con la representación hexadecimal de 100, 101 y 102.

Con esta información podremos entender un poco mejor como se realiza el análisis de parámetros de la función printf.

Extrae el primer elemento de la pila que es la cadena de formato. La analiza carácter a carácter. Si encuentra el caracter "%" analiza la siguiente letra.

•  Si la siguiente letra es una s extrae el siguiente elemento de la pila. Y coloca la cadena de caracteres apuntada por esa dirección en el lugar de %s.
•  Si la siguiente cadena de caracteres es d, extrae el siguiente elemento de la pila y coloca su valor en decimal.

 Análogos procesos realiza para las otras posibilidades: %x, %n, etc.

Como se puede ver en algunos parámetros se pasa el valor y en otros la dirección de memoria donde esta el valor. Esto es lo que se conoce como paso de parámetros por valores o por referencia. Las variables de tipo string (%s) siempre se pasan por referencia y las de tipo numérico (%d, %x) siempre se pasan por valor. Para el resto de los otros tipos de variables es necesario consultar la documentación.

Antes de continuar con la ejecución de programa nos más abajo, hasta encontrar la llamada a la función exit que en este caso estará en la dirección 00401159. Ponemos aquí otro breakpoint para detener el programa justo antes de salir y poder ver el resultado. Damos nuevamente run (F9) y cuando se detenga en la llamada a la función exit nos vamos a la salida del programa que en este caso es la ventana de DOS que se ha abierto al cargar el programa en Ollydbg. Y vemos, una vez más la salida esperada.

 Empezando a torcer las cosas.

 Una vez tenemos clara tanto la lógica básica de la función como el paso de parámetros empezamos a pensar de forma agresiva. ¿Y si cargo menos variables y mantengo el número de caracteres %?
 Vamos a sustituir la sentencia:

 printf("%s - i = %d - J = %d - k = %d\n", string1, i, j, k);

 por

 printf("%s - i = %d - J = %d - k = %d\n", string1, i, j);  //hemos quitado el último parámetros. La variable k

 Lo compilamos, lo ejecutamos y obtenemos lo siguiente:

                           

Antes de analizar el resultado, podemos pensar que el compilador debería haber detectado que se pasan menos variables de las que se pueden deducir analizando la cadena de formato. Bueno, eso es cierto en este caso en el que la cadena de formato es un texto fijo y predeterminado. En otras situaciones la cadena de formato es una variable cuyo valor solo es conocido en el momento de ejecución. El compilador poco tiene que hacer en esta situación.

Aclarado este punto vemos que donde debería estar el valor 102 sale 1244928.

Para entender lo que ha ocurrido arrancamos este nuevo programa en ollydbg y marcamos los dos breakpoint, uno en la llamada a printf que está por arribe del Punto de Entrada y otro en la salida que está por debajo. Recordemos que arrancamos otro programa y es necesario volver a definir estos puntos. Run (F9) nuevamente y una vez detenido el programa nos vamos a ver la pila

                           

                           
Vemos que el siguiente elemento en la pila pasa a formar parte de los parámetros. El valor en hexadecimal de ese elemento es 12FF00 que en decimal es 1244928 que coincide con el valor que nos ha salido en la ejecución.
Nuevamente Run (F9) comprobamos el resultado en la pantalla de ejecución y nuevamente Run F9 para finalizar el programa.

Antes de seguir avanzando en las posibilidades exploración de elementos en la pila vamos a ver el impacto que puede tener en esta vulnerabilidad el tipo de datos.
Cambiemos la sentencia printf por esta:

printf("%s - i = %d - J = %d - k = %s\n", string1, i, j);

Hemos cambiado el último tipo de variabla de númerico decima (%d) a string(%s).

Compilamos y ejecutamos.

                           

                           
Y nos saldrá la interpretación en carácteres de lo que haya en la dirección de memoria 12FF00. El paso de parámetros es igual en este caso como en el anterior, pero la función al ver %s en vez de usar ese valor lo usa como referencia para encontrar el valor que debe colocar en el buffer de impresión.

Más adelante veremos como también podemos usar esto para ir a otras direcciones. Por el momento paramos aquí y en la próxima entrega expandiremos la posibilidad de explorar la pila.

Por hoy es todo, sólo queda practicar un poco y familiarizarse con ollydbg. 


(1) Otras instrucciones como CALL y RETURN también introducen y extraen datos de la pila

                         

¿Ha sido la red TOR comprometida?

La noticia de que Eric Eoin Marques  dueño de un ISP llamado Freedom Hosting y que según el FBI este ISP es el mayor distribuidor de pornografía infantil,  ha sido detenido gracias a que ha sido localizado usando la red TOR ha causado cierta inquietud en los entornos preocupados por el anonimato.

Antes de sacar conclusiones vamos a ver que ha pasado realmente….

¿No garantizaba TOR el anonimato?

Pues sí, y lo sigue garantizando, pero para entender lo que ha pasado y saquemos conclusiones primero hemos de saber algunas cosas más que ofrece TOR y no son tan conocidas.

Los Servicios ocultos (Hidden Services).
Lo más fácil para entender lo que es un servicio oculto es pensar que es un servicio cuyo anonimato está garantizado por la red TOR. El anonimato en el otro lado de la conexión. Dentro la red TOR los servidores anonimos están en el dominio .onion
Veamos lo que dice la wikipedia sobre los Servicios ocultos de TOR:

"Tor can also provide anonymity to websites and other servers. Servers configured to receive inbound connections only through Tor are called hidden services. Rather than revealing a server's IP address (and thus its network location), a hidden service is accessed through its onion address. The Tor network understands these addresses and can route data to and from hidden services, even those hosted behind firewalls or network address translators (NAT), while preserving the anonymity of both parties. Tor is necessary to access hidden services<sup>"

The Freedom Hosting
Un proveedor de alojamiento con la posibilidad de alojar una web completamente anónima y secreta en sus servidores. Esto, en principio, no tiene nada de ilegal, pero los responsables de este ‘hosting’ tenían la manga demasiado ancha y, según cuentan, se convirtió en un nido de pedófilos y ya en 2012 Anonymous denunciaba su existencia. Se estima que la cantidad de pornografía infantil alojada en Freedom Hosting podría rondar los 100 GB.</sup>

Si bien están demostrados los beneficios de la red TOR para mantener el anonimato de la gente, sobre todo en los regimenes opresores. Los servicios ocultos  presentan una cara bastante más negra ya que se han convertido en un nido de webs con actividades ilegales: pornografía infantil, tráfico de armas y drogas, etc.
Muchas webs activistas han decidido alejarse de este submundo y han optado colocar sus servidores en sitios más transparentes.

¿Que ha pasado?. 

Primero indicar que el ataque no se ha realizado contra la red TOR, que en otros usos sigue garantizando el anonimato. Por suerte.

El  ataque ha tenido dos etapas.

• Han hackeado un número indeterminado de servidores de Freedom Hosting colocando un JavaScript.
• El JavaScript utiliza una vulnerabilidad conocida: MFSA 2013-53 del navegador que usa TOR y se ha distribuido entre los usuarios de estos servicios. 

 Este JavaScript obtiene la MAC y el nombre del equipo en el que se ejecuta y envía por fuera de la red TOR esta información. Y también de forma implícita la dirección IP del  equipo. 

Epílogo. 

Esta información era enviada a uno servidores que al parecer estaban alojados en una agencia gubernamental relacionada con el FBI. 


Los responsables del proyecto TOR han informado que esta red no tienen ninguna vinculación con TOR Project BLOG y que seguirán trabajando para reforzar la privacidad de la red.

Conclusiones. 

Los nodos TOR no han sido comprometidos ni los mensajes que circulan por la red han sido descifrados. El ataque ha sido realizado explotando vulnerabilidades  en los extremos las conexiones que usaban esta red.
La conocida vulnerabilidad  MSFA 2013-53 y otra no hecha pública que existía en los servidores del Freedom Hosting.

Usos atípicos de Google: El diablo está en los pequeños detalles.

Cuando se habla de protección de sistemas pensamos en firewalls, antivirus, IDS, etc.
y cuando se piensa en hackers o pentesters imaginamos con grandes conocimientos de informática o, al menos, el dominio de potentes harramientas: nmap, metasploit y otros. Y muchas veces olvidamos que pequeños detalles pueden dar al traste con un sólido sistema de seguridad.

En el escalón más primario está en dump diving. ¡¡¡Cuanta información no se puede encontar en las papeleras y contenedores!!!. Por suerte las empresas cada vez son más conscientes de este problema y dejan a empresas especializadas el tratamiento de sus papeles desechados. Pero hasta ese momento la informacion está en papeleras, incluso contraseñas anotadas en post-its en las pantallas.

Hay otro nivel también primario y que sin necesidad de conocimientos ni herramientas especiales es también capaz de aprovechar nuestros descuidos y esa falsa sensación de seguridad que a veces se tiene. Y esa debilidad puede tener resultados desastrosos para nuestra seguridad. Se trata del Hacking con Buscadores.

¿Usar un buscador para hacer hacking?
Pues sí. Todo es cuestión de imaginación. Y, a veces, un simple buscador nos puede dejar en muy buena situación para empezar a diseñar un ataque contra un sitio Web.
Aunque este artículo hable de Google todo lo explicado es posible realizarlo también con otros buscadores como Bing y Yahoo. Sólo es cuestión de estudiar la sintaxis de estos buscadores.


Hasta los buscadores tienen sintaxis.

En efecto, y esta sintaxis nos ayuda a filtrar la información que solicitamos. Veamos algunos de los filtros que podemos especificar en nuestra búsqueda:

• site: Permite restringir esos resultados bien a un sitio Web bien a un dominio de nivel superior
• ext: Restringe la búsqueda a ficheros con la extensión especificada
• intitle: Devuelve las páginas que contengan en su título ALGUNAS de las palabras especificadas
• inurl: Devuelve las páginas donde en su URL aparecen ALGUNAS de las palabras

Ahora, manos a la obra.
Como he dicho antes a veces tenemos una sensación de falsa seguridad que unida a cierta desidia puede tener como resultado la creación de un enorme agujero en nuestra seguridad.
Hemos realizado una copia de seguridad de una web.  Nuestro proveedor nos proporciona una herramienta online, tambien web, mediante la cual definimos y planificamos nuestras copias de seguridad, que suelen ir sobre uno de los directorios de la web.
Pensamos, erróneamente, que al no tener una extensión de las clásicas: .html, .css., etc., no es fácil llegar a ella. Incluso algunos pueden pensar que es imposible acceder ese fichero. O pensamos que queda fuera del alcance de los buscadores.
Nada más alejado de la realidad y vamos a verlo.
Hagamos esta simple, pero efectiva búsqueda.

 ext:sql "insert into" password.


Et voilá, podemos ver como por la red hay muchos ficheros con la extensión .sql que son el resultado de backups de la bases de datos que se han dejado alegremente a nuestro alcance

Si entramos en uno ellos podemos ver lo siguiente:

Pero no solo podemos encontrar los importantísimos volcados de las tablas de usuarios, también podemos encontrar cosas curiosas, como las conversaciones de messenger:

Y su contenido.

Fácil. ¿Verdad?

Bueno, pues vamos a por otra.

Seguro que antes de modificar algun fichero de configuración el prudente administrador ha hecho una copia de seguridad..  Y como es un poco vaguete y tiene la  sensación de falsa seguridad pues lo fácil es crearla en el mismo directorio (que es accesible por web). Y en un alarde de imaginacion le pone uno de estos sufijo: .old, .orig, .back, .bck

No tenemos más que hacer la siguiente búsqueda:

ext:old  inurl:configuration var

Y.....

Miramos en su interior y:

Y ya lo tenemos, usuario y contraseña para acceder a una base de datos MySQL, y con bastante probabilidad será un usuario todopoderoso,

¡¡¡Es tan simple que hasta da miedo!!!.

Y vayamos a los casos difíciles.
Estos casos han sido bastante simples pero lo que buscaba era dejar bien claro la forma en que se puede hacer hacking con un buscador.

Es nuestra imaginación el límite de este tipo de hacking, pero por si andamos cortos de ella o bien deseamos partir desde donde otros han finalizado (que es la opción más inteligente) solo tenemos que buscar "google dorks" en el propio google...

Bueno, pues ya lo habéis visto... tened mucho cuidado ahí fuera.

Herramientas .... (II) - Explorador de procesos

En esta segunda entrega del paquete de herramientas de sysinternals vamos a ver el Explorador de Procesos que al igual que TCP View enriquece la escasa información que suministra el gestor de tareas standard de windows.
Encontraremos este programa dentro de la suite completa de sysinternals con el nombre procexp.exe

Una vez arrancado este es su aspecto

Además del consumo instantáneo de CPU y de memoria podemos identificar que hace el proceso, siempre y cuando el programador se haya tomado la molestia de indicarlo, y que el software está firmado. Esto último es una garantía de tranquilidad.


Dado que la firma de programa es una aval lo suficientemente importante de seguridad si ordenamos por esta columna y vemos que tenemos pocos procesos cuyo programas no están firmados tendremos una garantía de que nuestro sistema está aceptablemente limpio.

La implantanción de firmas en el software lleva ya tiempo en el mundo del software y ver muchos procesos arrancados en un equipo sin firma no da una buena imagen de su propietario (descuidos, software antiguo, copias no legales, etc) y una mayor probabilidad para la existencia de troyanos y puertas traseras,

Evidentemente no todos los programas vienen firmados, pero si por ejemplo vemos un programa que se llame word.exe y no viene firmado por Microsoft podemos estar seguro que tenemos algo que no huele bien en nuestro equipo.

Si hacemos seleccionamos un proceso y hacemos doble click obtenemos una información completa sobre ese proceso:

Podemos destacar:

Los puertos que tiene abiertos:

O los zonas de memoria que identifica como strings (tanto en memoria como en el fichero del ejecutable)

La entrada del registro que lo arranca (si es un programa que se arranca al iniciarse)

Un consejo: si ves un programa no firmado, que abre una conexión y está en autoarranque no está de mas el intentar identificar que hace ese programa e intentar descargarte una versión firmada.

Y asi la información de proceso clasificada en 7 categorias: Imagen del programa, rendimiento (en formatos gráfico y numérico), threads, seguridad, TCP, entorno y strings.

Podemos dividir la ventana en dos vista y en la inferior podemos seleccionar o bien los handles o bien las DLL's que usa un proceso:

Otra potente herramienta es la posibilidad de identificar el proceso al que pertenece una ventana. Sólo tenemos de seleccionar este icono:

arrastrarlo y soltarlo sobre la ventana seleccionada.

Estas breves líneas sólo son una enumeración de básica de las múltiples posibilidades nos proporciona esta herramienta.

En próximos posts seguiremos viendo mas herramientas de esta suite.

Herramientas imprescindibles para analizar procesos en Windows (I)

 Todos estamos acostumbrados a dar el comando netstat o ver la lista processo como primera acción cuando algo no va bien en el equipo.

Lo primero que se hecha en falta es poder relacionar la información de ambas pantallas que es como decir: ¿que programa a arrancado esa conexión? o su inversa ¿cuantas conexiones ha arrancando un programa?

El Gestor de Tareas de Windows y el comando netstat son claramente insufucientementes y necesitamos de algunas herramientas para poder extraer más información.


La solución a estas preguntas y otras muchas más viene de la mano de la suite Sysinternals que Microsoft pone a nuestra disposición en esta direción http://technet.microsoft.com/en-us/sysinternals/bb842062.aspx

En sus origenes sysinternals fue desarrollado por programadores independientes y más tarde Microsoft adquirió no solo estas herramientas si no tambien su compromiso de mantenimiento.

Una de las ventajas, y es una gran ventaja, es que los programas de sysinternals son portables, es decir que no necesitan ser instalados en el equipo para funcionar. Lo que nos permite que sean añadidos al pen drive de herramientas que a modo de navaja suiza, todos los profesionales de la informática debemos llevar encima.

En un futuro post comentaré que llevo en mi pendrive-navajasuiza

Aunque son muchas herramientas y orientadas a diversos fines en este post vamos a tratar con las herramientas que nos pueden ayudar a analizar los procesos en ejecución en un sistema:
Tenemos:

• TCPView
• Process Explorer
• Process Monitor
• Handles
• ListDLL
• Autoruns

Cuyos nombres dice bastante acerca de lo que podemos esperar de cada una de ellas.

TCPView.
Nos permite ver la conexiones de red que tenemos en nuestro equipo:

Esta es una pantalla general de la aplicación:

Se puede limitar la salida a sólo aquellas conexiones activas:

Mediante Ctrl+R podemos activar / desactivar la resolución de nombres

Las filas pueden estar coloreadas:

• Amarillas - Conexiones que han cambiado de estado entre dos inspecciones
• Rojas - Conexiones que han desaparecido
• Verdes - Nuevas conexiones.

Una de las cosas que en mi opinión son mas útiles es la posibilidad de identificar al proceso que tiene la conexión.

Mediante nombre y su PID. Además si seleccionamos el proceso y vamos al menú y seleccionamos: Process --> Process Properties nos identifica en el fichero del programa:

Permitiéndonos incluso cancelar el proceso.

No alargo más este post y en los próximos iremos viendo y todos y cada uno de estos programas y finalizaremos con un ejemplo de uso de todos ellos para analizar un malware.

Denegación de servicio en las Base de Datos

A medida que han ido haciéndose los servidores más y más potentes las bases de datos han ido desarrollando modelas mas conceptuales y las capas de abstracción cada vez son más profundas. La consecuencia inmediata de ello es que cada vez menos programadores realmente conocen como son las sentencias SQL que hay detrás de esos conceptos y la consencuencia de ello es un descuido total hace las cuestiones de rendimiento.
El hecho de que los sistemas se hayan hecho más resistentes a los ataques DoS clásicos ha forzado a que las organizaciones que están detrás de estos ataques suban un escalon en los niveles OSI y dirijan sus esfuerzos en diseñar ataques a nivel de Aplicación.



La idea básica es construir ataques basados en consultas que sean veroces consumidoras de recursos en los servidores: ejecutar pesadas select desde diversos sitios (ataque distribuido), generar carritos de compra con varios cientos (o miles de productos) y realizar pequeñas variaciones en ellos para obligar a recalcular todo.
También puede aprovecharse las limitaciones de los sistemas de bases de datos que dan servicio a la aplicación. Incluso se puede llegar a realizar ataques de SQL Injection que no tienen porque ser demasiado elaborados porque el objetivo de un ataque DoS no es comprometer al equipo, si no colapsarlo. Un sencillo ataque de SQL Injection  que cause un inesperado consumo excesivo de recursos es suficiente.

La cosa se puede agravar más porque gran parte de estas aplicaciones se construyen con herramientas ya conocidas y siempre es posible realizar simulaciones offline para analizar el rendimiento de las consultas generadas y seleccionar las más pesadas.


Evitar estos ataques se hace difícil para los sistemas tradicionales. Pueden no ser necesarias tantas peticiones para bloquear una base de datos por lo que los sistemas de detección basados en volumen no garantizan que puedan detectarlos.
Por otro lado la detección de SQL Injection se basa en la comparación de patrones para detectar ataques y en este caso se va a trabajar en su mayor con peticiones legítimas. Basarnos en estos sistemas necesitarán un ajuste muy fino o nos podemos estar bloqueando peticiones legítimas.

Se pueden hacer sistemas mixtos que  ciertos tipos de consultas con incrementos en peticiones, pero todo es encaje fino y sin garantías.

La solución pasa por una vuelta atrás y volver a hacer énfasis en el rendimiento. Antes era obligado porque las máquinas eran menos potentes y ahora porque las pueden sobrecargar. Diseñar la basa de datos muy ajustada al tipo de consultas que se espera. Optimizar la consultas para que funcionen de la manera mas eficiente. Olvidar un poco los modelos generalistas y centrarse en entornos específicos. Mas caro, más lento de desarrollar pero que a la larga puede ahorrar más de un quebradero de cabeza.

El informe Mandiant (y II). Las debilidades.

Finalizamos con este post el análisis sobre el informe Mandiant. (Ir a la primera parte)
Después de analizar la metodología de los ataque que siguen un patrón muy clásico el informe nos da información sobre ciertas personas que han sido identificadas como pertenecientes a esta unidad: UglyGorilla, DOTA o SuperHard.

Perfil de UglyGorilla en  la los foros de China Military Online (chinamil)

Este quizá es un punto al que más se ha agarrado los críticos con este informe como podemos ver en el  blog de Jeffrey Carr

Aunque un poco extenso y demasiado formal, tan formal que hace que algunos detalles pasen un poco desapercibidos.

El más importante es que olvida decir que en el  sitio de donde parten los ataques se dan estas dos circunstancias:

• Es el punto donde está el mayor cable transoceánico y que agrupa a la mayorías las comuniaciones entre Asia y América
• La zona donde están ubicadas las direcciones IP atacantes tiene una población de 5 millones de habitantes y un gran número de pequeñas empresas.

No sería complicado montar una pequeña empresa y montar en ella un proxy para canalizar los ataques los ataques que se estén dirigiendo desde cualquier otra parte del mundo: Rusia, Pakistán, Irán....


La debilidad del argumento queda patente por la rápida respuesta china.

Y para finalizar un último apunte, más político que técnico. El ejército chino es una institución cerrada que puede considerarse un estado dentro del estado. Es todavía el valedor del espíritu comunista en China. Un caso similar al Ejército Turco y el legado de Ataturk o la dificil transición a la democracia del Ejército Español.
Aunque acepta los cambios que están transformando el país es bastante refractario a ellos y considera a la Universidad un sitio donde van a formarse futuros "capitalistas" y no parece probable que se siente tentado a recurrir a ellos. Principalmente cuando tiene sus propios centros de formación que, como ocurre en otros paises, no tienen nada que envidiar a los centros civiles.
Bajo ese punto de vista no parece tampoco muy acertada la información del informe cuando comenta que recluta a sus agentes en las universidades civiles.

En fin, informe controvertido y con lagunas que hace dudar de su fiabilidad.

¿Y tú, que opinas?

Técnicas de evasión de firewalls (I). Lo básico

Cuando se hace un test de penetración lo primero que hemos de pensar es que las cosas no van a ser tan fáciles como cuando realizamos ensayos en nuestro entorno de pruebas.

Firewalls e IDS se erigen entre nosotros y los sistemas objetivos y nos vemos obligados a tratar con ellos. Cuando hablo de evasión lo hago en su doble aceptación:

• Atravesarlos
• Evitar que nos identifiquen. 

No hay una receta mágica e infalible, todo depende de lo buena que sea la configuración del firewall (por firewall me refiero indistintamente a los propios firewall como a los IDS).

Cuanto más pobremente configurado esté un firewall más fácil nos será traspasarlos y escanear los sistemas objetivo.

Lo elemental.
Hoy en día hasta el más lego en redes sabe que la no respuesta a un ping no significa nada, pues las mayoría de los firewall (internos o externos) viene configurados para no responder a este mensaje.
El siguiente paso es hacer un scaneo de puertos y utilizamos el three way handshake cuya secuencia es la siguiente.

El equipo cliente envía un paquete SYN al que el equipo servidor responde con un paque SYN+ACK. El cliente responde con ACK y la conexión ya queda establecida.

Hasta el firewall más pobremente configurado está preparado para bloquear todos los paquetes SYN.

Veamos el mismo flujo en un diagrama temporal:

Sabemos que el firewall va a bloquear los paquetes SYN entrantes para evitar conexiones pero... ¿y si no empezamos por un paquete SYN?, ¿Y si directamente mandamos el paquete ACK?.



A menos que el firewall tenga "cierta memoria" y recuerde paquetes anteriores no tiene forma de saber si el paquete que recibe es legítimo o ilegítimo. Por tanto dejará pasar el paquete que llegará a la máquina objetivo.

Tanto si el puerto está abierto o cerrado el equipo receptor responderá con RST.



Si, por el contrario no se recibe respuesta sabremos que hay un elemento intermedio que está bloqueando los paquete y que además este elemento intermedio o bien está configurado de manera muy elemental o bien  se trata de un firewall con pocas capacidad.


Existen otros tipos de scaneos que se basan en el envío de pequetes fuera de secuencia que nos pueden ayudar a obtener más información aunque se suele tratar se situaciones muy particulares que no tienen que ser ciertas para todos los sistemas.

En la web de nmap podemos ver las posibilidades de scaneo disponibles en esta herramienta y una breve descripción de cada una de ellas.

 A parte de lo sencillo del ejemplo lo importante que podemos sacar como conclusión es que la configuración de un firewall va mucho más alla de bloquear los paquetes de solicitud de conexión y la posibilidad que tenemos de, al margen de los ataques ya existentes,  poder confeccionar nuestros propios paquetes y lanzarlos sobre un equipo determinado que tengamos para pruebas e ir viendo las distintas respuestas.

Bueno, pues os dejo practicando, y más adelante seguiremos viendo diversas tecnicas para evadir firewalls. Pero no será en el seguiente post, ya que tengo pendiente la segunda parte del Informe Mandiant. 

China, ciberguerra y el informe Mandiant (I)

Recientemente han aparecido en la prensa noticias sobre la supuesta responsabilidad del Ejército Chino en ataques y robos de información a empresas y organismos. Por supuesto el Gobierno Chino lo ha desmentido.

El origen de esta información ha sido un informe emitido por la empresa Mandiant, especialista en seguridad informática.

Es informe  se puede descargar desde este enlace y sin ser demasiado extenso ni profundo dice cosas muy interesantes y que merecen ser explicadas.

Empieza el informe indicando que lleva investigando desde el 2004 a los grupos más activos en ataques, reconoce que tiene identificados a más de 20, a los que llama APT (Advanced Persistent Thread). Curiosamente la amenza china es el APT1. Lo que es toda una declaración de intenciones de que empezaron por China.
Es de suponer que entre esos grupos APT se encuentren también grupos como Anonymous.
Así define a la APT1

  y más adelante aclara con un organigrama este galimatías.

Poco clara el informe sobre el tamaño de esta unidad. Habla de varios cientos quizá miles de personas con al menos alguna de las siguientes habilidades:

Y las dimensiones de los recursos son espectaculares:

Miles de sistemas dedicados en casi 1000 Centros de Control diseminados en 13 paises, aunque la mayoría de estos centros de control está en la propia china (según demuestran las IP's obtenidas).

Antes de entrar en otras cuestiones indicaré que la mayoría de los ataques están dirigidos a la industria:

Siguiendo un patrón clásico.

En este sentido poca novedad aporta APT1:

• Reconocer
• Penetrar
• Escalar privilegios
• Mantener el acceso. 

Según la fuente la principal forma de comprometer lo sistemas es mediante ataques de phishing. Sí, sí, la ingeniería social está detrás
APT1 mediante en la fase reconocimiento inicial identifica nombres y personas del objetivo y crea falsas cuentas de correo a través de las cuales se dirige a otros empleados.

¿Quien desconfiaría de un correo dirigido por el CEO de la compañía, usando el lenguaje habitual y todos las firmas, logos e imagén de los correos corporativos?
Y si además tenemos un anexo tan tentador como este:

 Una buena ingeniería social hará que este correo se mande solo a las personas adecuadas y en los momentos adecuadas.

Una vez un sistema está comprometido el siguiente paso es abrir una puerta trasera. Normalmente, y para evitar a los cortafuegos pobremente configurados la puertas traseras son activas, es decir hace que los equipos infectados se conecten al atacante.
Esta técnica también tiene un punto débil: hace más complicado camuflar la dirección IP del atacante. Aunque parece que los amigos de APT1 tampoco eran demasiado escrupulosos en ese sentido porque según dicen en el resumen el 97% de los ataques identificados provenían de direcciones registradas en Shangai.

Este es uno de los puntos que sirven al Gobierno Chino como argumento para negarlo todo. Lo poco determinante que puede ser una dirección IP para demostrar una autoría.

Las siguientes etapas siguen el manual: obtener los hashes de las contraseñas para poder efectuar ataques de fuerza bruta offline, explorar el entorno  y obtener un sitio seguro donde colocar las puertas traseras que nos garanticen el acceso durate el tiempo necesario para sacar la información deseada.

Por no alargarme demasiado doy punto final a este post y deja para un futuro post un estudio de los recursos usados por APT1 para llevar a cabo los ataques.

Han hackeado mi web... ¿Y ahora qué?

En anteriores post escribí sobre la detección de vulnerabilidades en Joomla ( Post 1 y Post 2)  y como fortalecer nuestra Web en Joomla. Finalizaba este último post con la pregunta que da título al este artículo.

Hemos sido atacados

Hace ya unos cuantos años, bastantes, iba tranquilamente paseando por el Paseo de las Delicias de Madrid cuando sonó mi teléfono.
Un amigo, presidente de una asociación a la que le había confeccionado su web en Joomla.
- Juanma, tío, que nos han hackeado la web.
- Vale cuando llegue a casa lo miro. - dije con falso aplomo porque en realidad no tenia ni puta idea  de lo que podía estar pasando ni de como afrontar el problema.
Ya en casa me conecto a la web navego por unas páginas y no veo nada raro. Llamo a mi amigo para que me de mas detalles. Albergo todavía la esperenza de que sea una falsa alarma.
Me comenta que si se entra desde una búsqueda de Google aparece un mensaje de sitio malicioso. ¡¡­­Bueno una pista!!
Busco el Google la asociación e intento acceder a ella desde el link que me suministra y me aparece una pantalla similar a esta:

­­¡¡¡ufff!! No  me atrevo a seguir.

Arranco una máquina virtual que tengo para experimentos y veo, con mucha alegría, que me lleva a otro sitio web, concretamente del dominio .tk

Me tranquilizo un poco, por lo visto no es mi web la que está marcada como sitio peligroso.

Accedo a otras webs conocidass en Joomla y veo que se accede correctamente.

Llega el momento de hacer la primera recopilación.

1. Cuando accedo a la web por su URL se llega a la web que, aparentemente esá  bien.
2. Cuando accedo desde una búsqueda de Google me lleva a un sitio que está  marcado como malicioso.
3. No parece ocurrir con otras webs escritas en Joomla.

Por humildad he de descartar que alguien haya hackeado Google para perjudicar a la web de la asocación, luego de he pensar que, en efecto, algo tiene mi web que hace que cuando se accede desde Google te redirige hacia otro sitio.

¿Cual es el siguiente paso?

Pues realmente no tenía en esos momentos demasiados conocimientos de Joomla y casi nulos de hacking. En esas condiciones poco más podía hacer que buscar por Google alguna información sobre mi problema.

Busqu‚ en español ( "google me redirige a otro sitio", la URL maliciosa, ) y lo mismo en inglés.

Tras un rato de análisis ya tenía claro como solucionarlo. Se trataba de localizar la siguiente sentencia en el código php:


eval(base64_decode("DQplcnJv..................................................KfQ0KfQ=="));

Los datos de la función no siempre coincid¡an en todas las búsquedas pero era un punto para seguir

Me descargue todo el sitio web a mi m quina virtual y con el comando grep localic‚ el string: eval(base64_decode

A partir de ahí hice una búsqueda en Google más concreta intentando hacer coincidir todo el literal y, no podía ser de otra manera, también la encontré. En este caso coincidía además el sitio malicioso al que te redirigía
Las indicaciones para eliminar el virus eran simples: eliminar esa l¡nea del código php. Aunque no eran muchos los ficheros infectados sí eran los suficientes como para desmotivarme ir eliminando esa línea fichero a fichero.
Con una concatenacion de los comandos find y grep logre eliminar el código malicioso y subir los ficheros limpios.

Una vez realizado esto comprobé que el acceso a través de Google era correcto.

El punto de entrada.

Aunque la web estaba arreglada, seguía sin saber como habia sido infectado el sitio y mientras no supiera eso estaría a merced de un nuevo ataque.

Puede fijar gracias a mi amigo el ataque con una precisión de 24 horas así que me descargué el log de accesos del servidor y me puse a buscar peticiones GET o POST que se salieran de los estándares de joomla y localicé varias de ellas, puse un orden de prioridad a aquellas que me parecían, por simple intuición, mas sospechosas.
Con esa información pregunté en foros de Joomla y me aconsejaron que una vez identificado el componente objeto de la URL sospechosa  consultara en la VEL y así lo hice.

Localicé vulnerabilidades en dos componentes que podían estar relacionadas con el ataque.
Ya tenía una pista de por donde podía haber venido el ataque así que volví a buscar en foros ataques similares al que sufrí y también vi como aparecía que en varios ellos el componente sospechoso estaba en los sitios infectados y además en la misma versión que el que yo tenía instalado.
Sólo me quedaba visitar la Web del fabricante. En su blog reconocía que existía la vulnerabilidad y recomendaba la urgente subida de versión.

Conclusiones.

Antes de seguir he de decir que tuve mucha suerte. Se trataba de un ataque inofensivo, que no compromet¡a la web y de fácil erradicación.

Dada mi poca experiencia en aquellos momentos si el ataque hubiera sido mas sofisticado no habría podido recomponer la situación.

Indistintamente de la complejidad del ataque, de las herramientas y de los conocimientos lo imporatante es el método.

• Identificar los síntomas del ataque
• Fijar con la m xima precisión posible cuando pudo ocurrir el ataque
• Buscar en información sobre el ataque (Google, BB.DD. vulnerabilidades, foros).

Con esta información:

• Reparar
• Proteger

Y para finalizar

 Realmente la cosa era menos dramática ya que tenía varias copias de seguridad y lo primero que hice fue verificar que pod¡a recuperar el sistema, pero si lo cuento al principio la cosa pierde interés ;-)

TrackDot unidad de seguimiento de equipajes

TrackDot es un pequeño dispositivo diseñado principalmente para el seguimiento de equipajes en vuelos de avión.

Solo tenemos que meter este aparato

en nuestra maleta y conectarnos al servicio al que previamente debemos abonarnos para tener un mapa sobre el que podemos seguir a  nuestro equipaje.

Bien de un ordenador:

(Fuente de la imagen: www.Trakdot.com)


o desde nuestro dispositivo móvil (iPhone o android)

(Fuente de la imagen: www.Trakdot.com)

Familiarizado como estoy, desde hace años, con los sistemas de posicionamiento en general y con los de seguimiento de flotas en particular al tener información sobre este dispositivo me venían a la cabeza algunas de las limitaciones típicas de estos equipos y me entró curiosidad por ver como las habían solucionado.

Localización en sitios cerrados.

Normalmente los equipajes van a estar en sitios cerrados y esto es una limitación de los sistemas de localización que se apoyan en las redes de satélites: GPS, Galileo, Glonass, etc.

La solución ha sido usar las redes de antenas celulares de telefonía móvil. Y garantiza una precisión de hasta 10 metros.

Pero eso nos lleva al siguiente problema....

Roaming low-cost

El gran enemigo, económico, de la comunicación intinerante es el cambiar de país. Y en caso de los vuelos es algo más que probable que ocurra. ¿Como lo ha solucionado este fabricante?.

Ha creado su propia compañía de telefonía móvil. Aunque esta compañía no presta servicio ni a particulares ni a empresas. Sólo se presta servicio a sí misma y ha conseguido unas muy especiales tarifas de roaming.

Autonomía

Mediantes pilas AA el fabricante garantiza tres semanas de funcionamiento continuo lo que es un tiempo razonable para poder localizar tu equipaje.

Aunque no soy partidario de las pilas normales, tanto por razones ecológicas como de precio, he de reconocer que la potencia que dan estas pilas eclipsan tanto a las recargables como a las baterías. Y para usos puntuales y específicos, como puede ser este he de reconocer que es la solución adecuada



¿Apagarse durante el despeque y aterrizaje?. 

Hasta aquí hemos visto como este curioso dispositivo va sorteando las limitaciones de los sistemas convencionales de localización de dato, pero había un tema que realmente me intrigaba: ¿como iba a ser compatible con las normas vigentes de navegación aérea que prohiben el uso de dispositivos con comunicación inalámbrica durante las maniobras de despegue y aterrizaje?.

Pues la solución está en el uso del acelerómetro que trae incorporado este dispositivo. Un chip igual al que tienen los modernos smartphones y que, entre otras cosas, hace rotar la pantalla o que se apague la pantalla cuando hacemos el movimiento de llevarlo a la oreja.

 Una vuelta a los tradicionales sistemas de navegación inercial, hasta hace poco el único sistema de navegación y que todavía se usa, con fines bélicos, en los submarinos atómicos para navegar sin emitir ninguna onda y así evitar ser descubiertos.

No queda claro en la poca información  que se puede encontrar sobre este dispositivo si el aparato está también encendido en vuelo estable o sólo se enciende cuando el sistema detecta que está en tierra firme.


Resumen.

A falta de análisis que puedan ir confirmando todo lo expuesto anteriormente no se puede negar que se trata de un aparato novedoso por la forma de utilizar las posibilidades de los sistemas.

El fabricante especifica mediante una nota que está diseñado para Viajes de Avión aunque no hay mención a ninguna homologación que sea admitido por todas las Administración de Aviación. 

Aunque tanto el precio del aparato (50 € ) como el abono al servicio (10€/año) son bastante asequibles se trata de un sistema que parece estar todavía en fase beta y que tardaremos algún tiempo en verlo en Europa.