Sending files through ICMP

DISCLAIMER: English isn’t my mother tongue so it’s possible that you’ll find some grammatical mistakes on the text, feel free to point them out on the comments so I could learn and improve. Thanks.

Today I want to talk about a technique that I heard on latest No cON Name by Juan Garrido and Pedro Laguna, both guys did a presentation about data exfiltration, that’s it: an unauthorized release of data from within a computer system, and one of the methods they explain for exfiltrate data was the ICMP tunneling.

Nowadays network administrators are aware of the security problems of anyone inside the network with the permissions to reach arbitrary ports outside the network, so they use firewalls that could block unauthorized connections and proxies that can inspect and log the authorized ones in order to seek for malicious activities. And that is true mainly for any TCP and UDP connections, but network administrators tend to underestimate other protocols less designed to transport arbitrary data as, for example ICMP. What harm could made an user pinging his own server? Well, let’s take a look and maybe you’ll get a surprise.

The ICMP is a layer 4 (transport) protocol designed to troubleshoot and debug computer networks, for example a router will respond an ICMP net unreachable message (type 3 code 0) if receives a packet with an IP destination address that isn’t on its routing table, another example could be the ICMP redirect message (type 5) that is sent by a router indicating the networks hosts that it is no longer the default gateway and that those hosts have to update their routing tables.

The most known ICMP messages are ICMP echo request and ICMP echo reply messages, used by the ping (Packet INternet Groper) application. The main usage of ping is to troubleshoot networking issues determining if the problems occur above or below the network layer, basically ping sends an ICMP echo request to a host and, if that host is configured to respond ICMP echoes, it will respond with an ICMP echo reply, this way you could determine if the layers below IP are working properly, sending a burst of them you could check how many packets gets lost on the path, measuring the time between you send an echo request and you receive an echo reply you could determine the latency of that link, and so on. Because of that troubleshooting versatility most networks administrators allow the pass of these packets.

An ICMP echo request & reply packets looks like:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7|8 9 0 1 2 3 4 5|6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Identifier          |        Sequence Number        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Data ...
+-+-+-+-+-
  • Type field tells us what type of ICMP packet (obviously, duh), in our case we’re only interested on 8 (echo request) and 0 (echo reply).
  • Code field is used to determine subtypes of ICMP packets, in the echo request & reply types there aren’t any subtype (but you can find on, for example, type 3 -Destination unreachable- the codes 0 -destination network unreachable-, 1 -destination host unreachable-, 4 -Fragmentation required and DF flag set-, and so on)
  • Checksum is, as you could guess, a field with the checksum of the packet used to “ensure” the integrity of the packet through the link.
  • Identifier and sequence number fields are used to create “streams” of ICMP packets, so you could send a burst of ICMP echo request and determine which of then got lost over the wire (or the waves).
  • And finally the data field, that should contain an arbitrary array of bytes that the remote host must replicate on the ICMP echo reply (so we could determine that it received exactly the same data that we send).

So, as I said, the data field can be any arbitrary array of bytes, so we can “easily” break any file on tiny bits and send it through the network without any problem. A few time ago I wrote some kind of quick and dirty proof of concept in Python (maybe one day I will make it cleaner but, you know, procrastination :P) so you can to take a look at it if you want to know better how to send files over ICMP.

A bit of this post being sent through ICMP

But it doesn’t limit to send files, you also could build a tunnel to have full TCP connections over ICMP (you can check that isn’t something new).

For more information you could take a look at the RFC 792 (INTERNET CONTROL MESSAGE PROTOCOL).

¿Qué es DevOps?

Aprovechando que me he leído el libro What is DevOps? (un e-book que, por cierto, es gratuito), voy a explicaros un poco de qué va el tema.

La idea principal del DevOps es la fusión del departamento de sistemas con el departamento de desarrollo. ¿Por qué? Pues porque la división de estos dos departamentos hace que sus miembros se vean como “enemigos”. Digamos que el objetivo del trabajo del departamento de sistemas es el mantener la aplicación funcionando, mientras que el objetivo del trabajo del departamento de desarrollo es (simplificando) añadir nuevas funcionalidades a la aplicación. El problema es que esas nuevas funcionalidades suelen ser vistas por el departamento de sistemas como potenciales desestabilizadores de la aplicación, es decir como más trabajo, por lo que sistemas intentará retrasar al máximo el despliegue en producción de esas nuevas funcionalidades (ha de pasar un tiempo en el entorno de test), lo que será percibido por desarrollo como un menosprecio o amenaza a su trabajo y ya tenemos montado el mal rollo dentro de la empresa.

Lo que propone DevOps es que uniendo ambos departamentos no sólo consigues una mayor harmonía dentro del departamento de IT, si no que consigues una mayor eficiencia a la hora de resolver incidencias. Por ejemplo, desarrollando la parte de logs ¿Cuántos de nosotros ha tenido un problema con una aplicación, ha ido a echarle un ojo al log y ver un galimatías que es incapaz de entender (no entremos cuando vemos el chorro de excepciones no capturadas tan típicas de una aplicación Java)? ¿Por qué? Pues por que el que ha programado la aplicación no sabe que información necesita sistemas, el es de desarrollo y pondrá la información que le resultaría útil a él o ella. Y no por ánimo de joder al pobre sysadmin a media hora de acabar su turno, si no simplemente porque no es consciente de lo que necesita el sysadmin.

Otra de las cosas interesantes que comentan, es hacer que la aplicación se “autoadministre”. Dado que sistemas ahora participa en el desarrollo, se puede añadir código que gestione las típicas incidencias que se resuelven reiniciando un demonio (¿a que jode una alerta a las tres de la mañana para, simplemente, reiniciar un Apache y que ya no te vuelva el sueño?). Hacer la aplicación más resiliente se le llama a esto. Si a esto le sumamos la aparición del IaaS (AWS, Rackspace, CloudBuilder, etc.) podemos hacer que la propia aplicación levante más frontales web cuando lo necesite, o pare un esclavo de base de datos y levante otro porque había fallos con la replicación de forma totalmente automática. Obviamente esto haría mucho más agradable el trabajo del sysadmin de guardia, que sólo sería despertado para incidencias gordas e interesantes, no para chorradas.

La verdad que es una idea que me parece interesante y creo que el futuro de sistemas a por ese camino, al menos en entornos web.

PD: Ya sabéis empresas web que estéis interesadas en un sysadmin molón y que sepa de qué va el rollo DevOps os invito a visitar mi perfil de LinkedIn.😛

Instalar WebGoat de forma sencilla

WebGoat es una aplicación web deliberadamente vulnerable, creada para aprender y practicar lecciones de seguridad en aplicaciones web. Así que como ahora tengo tiempo me propuse instalármelo y practicar un poco, el problema vino en el momento que intenté instalarlo, ya que las instrucciones que ponen en la web son algo confusas (al menos para mí).

Si vamos a la página de descargas  (al menos en el momento de escribir éste artículo), vemos que se distribuye de dos formas: un paquete .zip para Windows (o eso se deduce, erróneamente, al leer el nombre del fichero) y en un fichero .war. Entiendo que todo aquél que vea esta situación y lo quiera desplegar en una máquina no Windows, se bajaría el .war, instalaría un Tomcat, desplegaría la aplicación y luego configuraría el Tomcat para que la aplicación funcione correctamente. El problemilla es que esas configuraciones no están documentadas en ningún lado y las tienes que ir viendo por “ingeniería inversa” (como mínimo vi que se tenían que definir los roles en tomcat-users.xml). Pues vaya rollo ¿no? Aunque para un sysadmin como yo, con los huevos “pelaos” de desplegar aplicaciones sobre Tomcat, tampoco sería un trabajo muy arduo😛

Aunque si le echamos un ojo al paquete para Windows, vemos que hay un directorio con la aplicación desplegada y el Tomcat configurado. Y como Tomcat está escrito en Java pues “Run everywhere” y usamos este paquete para nuestro Linux:

cd /tmp
wget -c http://webgoat.googlecode.com/files/WebGoat-5.4-OWASP_Standard_Win32.zip
unzip WebGoat-5.4-OWASP_Standard_Win32.zip
mv WebGoat-5.4/tomcat /opt/WebGoat-5.4
chmod +x /opt/WebGoat-5.4/bin/catalina.sh
ln -s /opt/WebGoat-5.4/bin/catalina.sh /etc/init.d/WebGoat

De este modo ya podemos levantar/parar la aplicación WebGoat mediante

/etc/init.d/WebGoat start
/etc/init.d/WebGoat stop

Y por defecto la tendremos escuchando por el puerto 8080, por lo que entramos a http://hostname:8080/WebGoat/attack y ya podemos empezar a jugar🙂

PD: Ya sé que para mis avezados lectores esta advertencia no es necesaria, pero por si acaso. Recordad que esta aplicación es vulnerable por lo que no la instaléis en ninguna máquina que sea accesible desde Internet.

Compartir ficheros en una red local de forma fácil y sencilla (con Netcat)

Una de las cosas que más rabia me dan es cuando quieres copiar un fichero (algo grande) entre dos equipos que tienes en casa.

Un método sencillo y rápido es copiarlo en un pendrive y moverlo de un equipo a otro, el problema es que nunca encuentro un pendrive que funcione cuando lo necesito (tengo un montón de petados).

Otra idea sería la de configurar un servidor de SSH en un equipo y copiarlos por SCP, lo cual también sería efectivo, pero te obliga a instalar y configurar un servidor de SSH, otro problema sería que podrías estar desperdiciando ancho de banda debido a que el fichero se tiene que cifrar antes de enviar (tal vez en la red de casa te dé igual, pero si estás en la oficina podrías estar desperdiciando una buena conexión a gigabit).

Para ello puedes emplear Netcat (la navaja suiza de los administradores de red :P), simplemente ejecuta lo siguiente en el equipo donde quieres recibir el fichero:

nc -l ${puerto} > ${nombredelfichero}

Lo que arrancará una instancia de Netcat que escuchará el puerto que le hayas indicado en $puerto. En el equipo que esté el fichero que quieres copiar escribe:

cat ${nombredelfichero} | nc ${ipdestino} ${puerto}

Lo que enviará el fichero hacia el equipo destino, sin “perder tiempo” cifrando el contenido y sin tener que instalar ni configurar ningún extra.

Borrón y cuenta nueva

Después de unos meses de locura intentando tener acabado el PFC para la convocatoria de este junio, por fin soy libre. Así que he decidido desempolvar este blog que tenía bastante aparcado.

Dado que las pocas entradas que tenía eran poco relevantes, he decidido cepillármelas y empezar desde 0 (bueno en realidad he mantenido el pequeño tutorial sobre como montar un USB físico en la versión libre de VirtualBox, que era la única que tenía enlaces desde el exterior y no era plan de “romper el Internet” :P)

Me gustaría enfocar la temática de este blog sobre sistemas, redes, seguridad informática y programación. Especialmente con artículos técnicos y algo de opinión, aunque no me gustaría llenar esto de tutoriales, más que nada porque no creo que un blog sea el medio apropiado, tal vez si empiezan a salir demasiados tutoriales mire de abrir una wiki o algo.

Así que espero tener suficiente tiempo y paciencia para hacer de este sitio algo útil para la comunidad…🙂

Usar memorias USB y compartir carpetas con VirtualBox OSE

Buenas, hoy traigo un HowTo muy sencillo para ir empezando con la sección más “técnica” de este blog.


Una de las featuresmás interesantes, para el usuario medio, de la versión privativa de VirtualBox, es la capacidad de montar las unidades USB en el sistema virtual. Lo cual es útil cuando quieres transportar cómodamente los datos del sistema virtual, por ejemplo para prácticas de universidad.

Pero esta característica es emulable gracias a que en los sistemas Unix todo se considera un fichero (y las unidades USB también ;)).

Antes de nada veamos como compartir un directorio de nuestro GNU/Linux con un Windows XP virtualizado.Primero debemos de indicarle al Virtualbox cuál es la carpeta que vamos a compartir. Para ello escribimos en la consola:

ataulfo@vidimensional:~$ vboxmanage sharedfolder add Nombre -name /carpeta/carpeta -hostpath /carpeta/carpeta

Donde ‘Nombre’ es el nombre que tenga la maquina virtual en Virtual Box (ojo con las mayúsculas) y /carpeta/carpeta pues la ruta del directorio que vamos a compartir.

Luego entramos en Windows XP y una vez allí, abre “Mi PC” y en el menú “Herramientas” > “Conectar una unidad de red” seleccionamos la unidad que nos plazca (por defecto, Z:) y en la dirección debemos poner: VBOXSVR/carpeta/carpeta.

Y si todo a transcurrido normalmente veremos una nueva unidad de red en nuestro Mi Pc, que podremos usar normalmente.

Para poder usar la unidad USB, simplemente debemos compartir el directorio donde nos monte el USB (/media/usb, por ejemplo) y ya tendremos acceso a nuestra memoria USB.