En el artículo anterior hablamos de cómo podemos montar una VPN con nuestra raspberry pi. Sin embargo, a veces esto no resulta tan fácil si el lugar que nos ofrece acceso a Internet no confiable (WiFis publicas en general) decide aplicar filtrado del tráfico de VPN.

Básicamente un filtrado consiste en evitar que los paquetes lleguen a su destino y esto puede conseguirse de diferentes formas:

• Por un lado, pueden estar filtrando el tráfico que tenga como destino puertos “raros”, como podría ser el puerto 1194 que es el que estamos utilizando en el caso de nuestra VPN. En este caso la forma de evitarlo es sencilla: simplemente tendríamos que cambiar el puerto del servidor VPN a uno de uso común, como el 80, el 443 o incluso el 8080.
• Por otro, podría estar implementado un filtrado de protocolos, como por ejemplo denegar el tráfico UDP en determinados puertos que habitualmente se utilizan con otros protocolos, como el 80 TCP. La solución en este caso sería cambiar el archivo de configuración de la VPN y establecer que se utilice TCP.

Con este par de sencillos pasos puede evitarse en muchos casos el filtrado de las VPN, pero ¿y si el restaurante, cafetería, aeropuerto u hotel va más allá en el filtrado de nuestro tráfico VPN (que recordemos, es imprescindible para establecer una conexión segura)?

[Read more…]

Hoy en día es habitual conectarse desde diferentes lugares mediante los múltiples dispositivos que utilizamos de manera cotidiana: móviles, tablets, relojes, libros electrónicos o demás. Por supuesto, esto implica que nuestros datos están viajando por las conexiones de los propietarios de esas redes, lo que supone un gran riesgo de seguridad. Esto no necesariamente significa que el dueño sea “el malo”, simplemente puede ser negligente administrando su red; nunca se puede saber quién puede estar detrás de una red, por muy “honrado” que sea su propietario.

Con esto me estoy refiriendo en concreto a un enemigo, las redes WiFi; nos conectamos a ellas en cafeterías, parques, plazas, hoteles, casas de amigos… Y claro, siempre puede que haya alguien “pegando la oreja”.

[Read more…]

Una práctica recomendable cuando se utilizan servidores es cifrar los datos del servidor, especialmente cuando éste se encuentra en un lugar poco protegido o cuya seguridad no controlamos (por ejemplo, la sala de café, el despacho de alguien, un CPD externo, etc.). Esto evita que la información almacenada pueda ser comprometida y expuesta, si alguien roba el equipo o extrae el disco para clonarlo.

Pero (siempre hay un pero), hay un pequeño problema cuando se realiza un cifrado completo mediante LVM y LUKS. Si el servidor necesita ser reiniciado (o falla, que también puede pasar) se necesita que alguien físicamente introduzca la clave de cifrado para arrancar de nuevo. Ni que decir tiene que esto puede ser un problema si no tenemos un 24×7 o acceso físico al servidor (o no queremos compartir la clave de cifrado con el personal 24×7).

[Read more…]

Este domingo pasado se dieron dos factores interesantes: el primero, una tarde-noche tirando a bastante aburrida y el segundo, que tenía materiales que me habían llegado el sábado. Así que decidí probar algo que había leído. Una técnica de la que había oído hablar mucho pero que no había tenido la oportunidad de probar personalmente: un “cold boot attack”.

Para aquellos que no sepan de que va, se trata de una técnica en la cual se aprovecha que la información de la memoria RAM no se borra instantáneamente, sino que se degrada poco a poco durante un breve tiempo. Ese tiempo parece ser de unos segundos, pero si se reduce la temperatura de la memoria RAM, se puede conseguir que este tiempo se incremente sustancialmente.

Una vez introducida brevemente la teoría es hora de pasar a la práctica, que es lo interesante. En este caso vamos a hacer un montaje casero, en un escenario en el que no se cuenta con demasiados recursos: un ordenador con Windows 7 y 2 GB RAM DDR3 y otro con Windows 7 y 4 GB de RAM DDR3. El primero será el sistema atacado y en el segundo se montará el modulo de RAM, que además contará con memoria extra (los otros 4GB) con la esperanza de que al cargar el sistema operativo (otro Windows 7) no se sobrescriban los datos alojados en la RAM “congelada”.

Aunque esta forma no es la más óptima, el objetivo es realizar una prueba de concepto simple y fácil de montar, ya habrá tiempo más adelante de probar en detalle.

El proceso llevado a cabo consistió en arrancar el PC con el modulo de 2 GB de RAM con sistema operativo Windows 7, en el que se abren diversos procesos: navegador firefox, imagen descargada de Google, un cliente de VoIP y otros programas. Con esto se busca dejar trazas en la RAM que puedan ser identificadas en un posterior análisis forense: se busca un punto conocido por el que poder buscar después.

Una vez hecho, botonazo y a empezar el lío. Con el PC previamente abierto, sacamos el módulo de RAM y se mete en un recipiente especializado (también conocido como tupper viejo de la cocina), se empieza a rociar la RAM para enfriarla y cuando han pasado unos segundos (a decir verdad no probé la temperatura, pero había cristales de hielo) la coges con el dedo y consigues el primer objetivo del post: dedo congelado.

Acto seguido, se conecta el modulo de RAM “congelado” y se enciende el PC. Cuando ha terminado de arrancar se lanza DumpIt la utilidad de volcado de RAM, una herramienta que crea una imagen en RAW del contenido de la memoria, que es lo que posteriormente será analizado.

Una vez hecho esto ya se puede pasar al siguiente paso, al cual me ayudó mi compañero David García (que tuvo la genial idea de utilizar foremost): análisis de la RAM. Para ello utilizamos dos herramientas clásicas: volatility y foremost. Con el primero encontramos diferentes procesos abiertos y demás, pero nada que nos pareciera una prueba concluyente. Con el segundo, foremost, encontramos esto:

Aunque como puede apreciarse, la imagen no está completa, pero se recupera gran parte y se ve claramente que es la imagen que se tenía en memoria.

No esta mal para un primer intento, ¿verdad? En otro post analizaremos soluciones a este tipo de ataques y formas de enfocar el forense, pero como resumen ya sabéis que a) no estáis a salvo solo con apagar el PC y b) debéis llevar un spray congelante si trabajáis para la NSA.

(Nota: el autor no se hace responsable de módulos de RAM rotos ni dedos congelados ;-) )

Aprovechando uno de los múltiples eventos de seguridad que se organizan en nuestro país, se me ocurrió hacer un pequeño experimento parecido al que mi compañero Roberto llevó a cabo hace ya un par de años, pero en este caso en un entorno algo más especializado (aunque podía encontrar uno público de todo tipo).

Antes de nada, es necesario decir que los datos recogidos fueron analizados únicamente a título estadístico y no se extrajo ningún tipo de información privada o sensible, y señalar que la organización se encargó de informar por diversos medios a los asistentes de que utilizasen únicamente la WiFi oficial del evento… pero ni por esas.

[Read more…]