Muy buenas de nuevo!
Mixing y másssss mixing, tal y como nos gusta por aquí, los que somos del mundo «informático» reconvertidos en networking warriors, siempre acabamos mezclando, este post sigue esa senda 🙂
Antes de continuar, un spoiler que os ahorrará mucho tiempo perdido si no queréis continuar: Nada de lo expuesto aquí es susceptible de ser puesto en producción, si lo que estáis buscando es algo de nuestros topics más habituales (SBC’s, Kamailio / OpenSIPS, Alta Disponibilidad, Rendimiento, …), este no es el post. Ahora que se acerca el VoIP2Day, cualquiera de esos temas lo podremos comentar en vivo y en directo 😉
Preflight, entrando en ambiente
Básicamente este es un post por amor al arte, algo con lo que hemos estado trabajando simplemente porque nos gusta y por poder probarlo, es más bien algo artístico (si se nos permite profanar dichos lares).
Como curiosidades: Por aquí ya sabéis que somos muy pero que muy amantes de los túneles, quizás la gente telco pura lo ve como algo sin más y en su cabeza sea algo similar a la MTU. Para los viejunos a los que nos apasionaba ver como hablaba el grandísimo Pablo Garaizar (Txipinet!) de la nueva técnica polimórfica ideada por GriYo de 29A, es algo que nos apasionaba en aquellas épocas, consideramos que tunelizar es algo mas que una técnica 🙂
Seguramente la periodista experta en ciberseguridad Mercè Molist lo haya escuchado más de una vez cuando hacía Hackstory (gracias por tu gran trabajo!), libro que por cierto recomendamos encarecídamente 🙂
El caso es que gran parte de esa época la pasábamos tunelizando, por ejemplo en la universidad (TCP22 Over HTTP con HTTP TUNNEL) para poder salir al «mundo real» fuera del corralito de los administradores de sistemas – Aitor Ibarra y Luis Lázaro, con los que ahora trabajamos, eran los «protectores» a los que había que burlar para poder salir, como si fuéramos El Chapo Guzmán intentando escapar.
Épicas noches ! Profesionales expertas reputadas de gran talento internacional como Nuria Lago (gran hacker curtida en aquellas épocas) rondaban dichos lares. Tenemos grandes recuerdos con ella, desde tunelizaciones standard hasta noches enteras haciendo bots que tunelizaban comandos del host over IRC Protocol (con su ping y su pong programados a mano (antes de tantas high level’s API) 😉 del RFC1459.
Este post busca mezclar esos conceptos con la vida técnica y path profesional actual 🙂 Algo como lo que hicimos en el Minicong Team en ruta hacia Mongolia, con el Missed Call’s Transport Layer – que presentamos en el VoIP2Day de hace 9 años 😉 Dónde tunelizábamos «any string» over llamadas perdidas.
Dicho esto, la música que toca con este post es la de Prodigy, Voodoo People, como le gusta al experto en seguridad Alfredo Beaumont (ziberpunk 😉 ) ver Hackers(1995) grabada en RAW /dev/cdrom0 jiji antes de participar en los CTF’s mundiales, seguro que su compañera de aventuras Sonia Meruelo (Tekess) se la ha visto ya unas cuantas veces 😉 Tendrá tiempo entre tanto premio que gana últimamente ? Enhorabuena desde aquí !
¿MultiVPN ?
Ciertos integrantes actuales de Irontec participamos allá por el 2004 (14 años ya) en un pequeño proyecto, más bien educacional, que buscaba preparar la tool definitiva para tunelizar sobre cualquier cosa, como si fuera lo que cualquier hackerzillo necesita para salir de casa y sentirse protegido – sin que le falte de nada 🙂
Obviamente, era un target demasiado alto, que se quedó en una mera proof of concept, para comprender como funcionaba los temas de los devices tun’s y la E/S asíncrona en sistemas Linux/Unix con SELECT y similares.
En aquella época, junto con Topo[LB] utilizábamos CVS, y estaba en SourceForge, pero «recientemente» (4 años) lo subimos desde aquí a a GITHUB y está disponible en algo «más moderno»
Cabe destacar antes de nada, y sobre todo recomendar: que nadie use esto en producción, más bien, que nadie use esto de ninguna forma 😉
¿IP over SIP?
La idea principal, siguiendo la línea de MultiVPN es utilizar mensajes SIP para enviar tráfico tunelizado proveniente del envío al interface virtual (tun/tap).
Realmente sencillo, no tenemos que implementar ningún driver de red, simplemente asignando IP’s y creando rutas, el kernel de encarga de mandarlo por el tun/tap, y como en Unix every
thing is a file , está hecho 😉 Es algo de lo que podemos leer como quien lee de /dev/urandom 🙂
¿Y por qué SIP?
Es a lo que nos dedicamos, como bien decía nuestro gran amigo Saghul «si amas un protocolo lo tienes que implementar«, por aquí diríamos:
si amas un protocolo, lo tienes que utilizar para tunelizar
Ya en un plano más técnico-realista, lo interesante de que sea SIP es que lo puedes encaminar hop by hop en application layer, no siendo tan estricto como una conexión TCP por ejemplo, que hacer virguerías de reencaminar (salvo con evil NAT o Anycasting o aventuras complejas) más allá de las src/dst headers no son fáciles.
Aunque realmente, la pregunta es: ¿Y por qué no?
Escogiendo el método SIP
Nos marcamos como objetivo tener algo cerca en el tiempo, poder tocarlo al de poco de empezar, en el mismo día.
Es posible que caminos orientados a la sesión hubieran sido mejores, estableciendo una sesión multimedia y por rtp fakeado tunelizar el application layer nuestro. Pero eso ya obligaba a handshakes invite 200 ok ack que queríamos evitar. Somos amantes confesos del stateless y de udp (si, a buen sitio hemos ido a parar jiji), así que esto nos dejaba únicamente para escoger entre requests de tipo OPTIONS, INFO NOTIFY, PUBLISH y MESSAGE (quitamos todas las que estén orientadas a sesión o registro).
Nos quedamos con OPTIONS, INFO era el otro gran candidato , por ser usado mucho para DTMF y despertar de sus vacatas a Iñaki Baz, gran defensor de los tonos DTMF y que seguramente lo re-implementará en JSSIP a su vuelta, ya que le gustó muchísimo 😉
Como stack sip, PJSIP dispone de muchos ejemplos y tienes un SIP UA que manda una request stateless en cuestión de segundos, así que el target de montar todo esto en un día parecía viable.
Entendiendo los internals de MultiVPN
Sirva este esquema para ilustrar el flujo de datos y componentes de este pequeño software:
(en el ejemplo pone INFO pero realmente es OPTIONS la request escogida, aunque realmente daría igual).
Si algun@ que leáis esto estáis interesados en hackear un poco el código, sin problemas, que sepáis que nada de esto está bien implementado o del todo: Temas de MTU broken, overflows por todos lados para ser exploiteados, 0 security at all, 0 implementación de rendimiento (pruebas de iperf’s de unos 200Kbits simétricos), mallocs no gestioandos (especialmente en base64.c) que luego no se liberan, etc … el interés principal es ver ping funcionando y una consola SSH usable mientras vemos un aluvión de diálogos en sngrep 😉
El tema del transport se ha quedado by default (UDP), pero si alguien le interesa es quite easy ponerlo. Igualmente, habría que plantearse anular toda retransmisión, para que sea lo más parecido a IP y que SIP no aplique retrans, para evitar problemas. Aunque seguramente si quisiéramos hacer esto en plan bien, el mejor camino sería tunelizar over RTP y fin 😉 Con headers, poco rendimiento pero infinitamente más fácil de desplegar.
Resolviendo el desafío
Uno de los caminos que cogimos IVOZProvider, al igual que hacen otros grandes del escenario como SIPWISE, es intentar utilizar un único protocolo a la hora de hacer debugging de escenarios complejos.
Aunque correlacionadores como HOMER7 permitan soportar cualquier protocolo y relacionarlos entre sí, es siempre más fácil ver con SNGREP una header en un forbidden con «clid not allowed» que estar buscando en millones de logs.
Así que optamos por añadir nuestro payload en una header SIP «MultiVPN:» en la que irá todo el pastel, en base64 por supuesto, todo muy fácil de ver 🙂
Llegados a este punto, el esquema conceptual, más allá de los internals de MultiVPN seŕia:
Compilando la aventura
El código lo tenéis disponible en Github, necesitaréis al menos estos paquetes instalados, en una Debian9 fresquita:
Para tenerlo todo ready:
apt-get install git gcc make autoconf libpjproject-dev cd /usr/src git clone https://github.com/zetagor/multivpn cd multivpn autoreconf -i ./configure make
It works!
Para ejecutar desde dos máquinas diferentes, adaptando los ficheros de config:
root@zgordevsiptunnel1:~/remoto# cat test.config.sip.alice # Sample config for SIP Plugin (Alice Side) plugin sip sip_port 4060 sip_transport udp sip_fromuri sip:bob@10.10.0.180 sip_remoteuri sip:alice@10.10.0.176 local_ip 10.200.200.1 local_netmask 255.255.255.0 root@zgordevsiptunnel2:~/remoto# cat test.config.sip.bob # Sample config for SIP Plugin (BOB Side) plugin sip sip_port 4060 sip_transport udp sip_remoteuri sip:bob@10.10.0.180 sip_fromuri sip:alice@10.10.1.76 local_ip 10.200.200.2 local_netmask 255.255.255.0
Máquina Alice
./multivpn -c test.config.sip.alice
Máquina Bob
./multivpn -c test.config.sip.bob
El log ya veréis que es bastante heavy, con toda la parte de PJSIP que la hemos dejado «tal cual».
Y con ello veréis 10.200.200.1 y 10.200.200.2 en los tap0 de ambos server’s y se pueden pingar / ssh 😉
Si entráis por SSH entre ellos, recomendamos tocar la MTU para evitar el freeze (ifconfig tap0 mtu 1400 – por ejemplo).
Contextualizando la prueba
Sirvan estos ejemplos para verlo todo un poco más unificado, en este ejemplo el tráfico es P2P, porque SIP así lo permite 😉 Pero realmente pasarlo por un proxy o un b2bua es cuestión de editar el .conf y poner el sip domain correcto y fin.
Hollywood style
No podía faltar el vídeo final, con la música que llevamos escuchando en la cabeza estos días 😉 Para seguir con la fantasmada 😉 jiji
Fuera bromas, aquí podéis ver como cada paquete que sale por el el interface acaba siendo transformando en tráfico SIP hacia el destino (la ventana de SNGREP es para que veáis dichos datos)
Despedida y cierre
Nada más en este pequeño tributo a aquellas épocas, a los protocolos y los excavadores de túnel / o más bien a los «hidden channel’s» en en el sec world 🙂 En próximos posts trataremos temas más solicitados del panorama actual y habitual.
Nos vemos pronto!
Queremos tu opinión :)