Taking advantage of regexp for fun&profit
I’m gonna tell you a story, based on real events.
Let’s assume a big network, with a highly restrictive policy about who can access the Internet and which sites you can browse. The users can’t access the Internet directly from their workstations (from a layer 3 routing point of view) the only way out is using the corporate browser (an IE6 by the way) which is configured and locked to use a proxy to get access to the world out there.
This proxy is the typical corporate web proxy, I mean, it demands the user to authenticate before it grants access to the requested URL, that previous authentication avoids any anonymous surfing moreover it’s used to track how long the user has been surfing, the requested URL is checked against a set of rules based on regular expressions that allow the proxy admins to filter which URLs or sites are allowed. In practice only a bunch of sites and URLs are allowed by the security policy, so the “interesting” Internet is completely blocked by this ‘fraking’ proxy, no google, no webmail, no access to the server in your home, no pr0n, nothing… just a bunch of bored and only work-related URLs.
Of course, the only protocols allowed by this proxy are HTTP and HTTPS, and as the access to the Internet isn’t network routed from the point of view of the local workstation but proxified at the application level, SSH, the magic-hacker-tool for network tunneling, is useless too :(
Nothing new under the sun so far, we’ve got the typical corporate Internet access scenario based in a HTTP/HTTPS proxy… but there’s more, the foolish-admin-factor works in our favor :)
As an eager mind myself, I wanted to check how these rules were setup by the admin. I managed to get a user account in the proxy server, and of course the first thing that I did was to learn more about the proxy that was installed there finding the config file… and you know what? the file rights were rw-r–r–
I like this admin :) config files readable to everyone in the system. I guess (and now I know for sure) that the admin doesn’t care about these kind things, he should think that everybody is good in this world, that everybody agree with the restrictions and the rules… or maybe he thinks that nobody cares about his servers and his config files… well, he’s wrong!
Be able to read the config file isn’t a big deal if there’s nothing interesting in the file… but if reading the file reveals a bad configuration that creates a hole in the system, then it’s important! I’m talking about how the regular expressions in the filtering rules were coded by our dear admin.
Let’s say you want your users be able to access slashdot.org, a simple and easy way to write a regular expression to permit this could be one like this: http://.*\.slashdot.org/.*
What do you say if someone claims to filter the access with a rule like this one: .*slashdot.org.*
Not so clever, don’t you think? This rule just says: accept any URL that has the string slashdot.org and the dot isn’t really a dot, is any character as it isn’t escaped :)
OK, let’s say you got your own DNS domain, so you can create whatever DNS name you want in it. Let’s say your domain is itsucks.org so you can create the name slashdot.org.itsucks.org so that matches the filtering rule that our “savvy” admin has written in his proxy configuration file.
So, just creating the right name in our DNS pointing at the IP of one of our systems, we got a direct link between the “protected” inside workstation in the “highly restricted” inside network and our external server.
Note that we haven’t cracked, tampered or modified in any way the browser, the proxy or the network. We’ve just took advance of the misconfiguration to reach directly a machine under our control from our internal PC.
Of course, we could use our external server as a forward or reverse proxy to freely browse any site or page, or better than that, we could create a SSH tunnel or any other kind of VPN tunnel being able to connect through the HTTPS proxy to freely get any TCP connection out or even in.
If you have an Apache server running in your server, you can do the trick with a configuration like this:
<VirtualHost *:443>
SSLEngine On
SSLProtocol All -SSLv2
SSLCertificateFile /etc/apache2/ssl/cert.pem
SSLCertificateKeyFile /etc/apache2/ssl/key.pem
ServerName slashdot.org.itsucks.org
ServerAdmin root@itsucks.org
ErrorLog /var/log/apache2/proxy/error.log
CustomLog /var/log/apache2/proxy/access.log common
ServerSignature On
ProxyRequests On
ProxyVia On
AllowCONNECT 22
<ProxyMatch slashdot.org.itsucks.org>
Order deny,allow
Deny from all
Allow from 1.2.3.4
</ProxyMatch>
</VirtualHost>
First of all, I didn’t want to move my SSH server from the 22/tcp to the 80/tcp or 443/tcp, doing that I could avoid the trick and connect directly to the SSH server, but I wanted to keep my HTTP/HTTPS ports for the web services so the connection redirection from Apache turn out to be pretty useful.
How it works:
A SSL virtual host is defined in the standard way on the 443/tcp port. The X.509v3 certificate and the private RSA key are created and defined. The server name is the one that is recognized as a valid and allowed external site by the corporate proxy as it matches the regular-expression filtering rules. This DNS name is resolved by our own DNS server to our own external server IP address. At this point, the HTTPS connection reach our Apache web server from our PC. The forward proxy feature is enabled with the ProxyRequests sentence but the access is denied from all but the IP address that we know is the public address of the corporate proxy that give us access to the Internet from the internal LAN.
The AllowCONNECT sentence is an interesting one, it defines which ports the proxy will be able to connect to when the HTTP CONNECT method is in use. In this case we’re interested in transport the SSH session inside the HTTPS session so when the connection ends in the Apache server and the SSH client sends the CONNECT method to connect to the SSH server, it’ll try to connect to the 22/tcp port so we’ve to permit it.
The last piece of this puzzle is the SSH client. Any client with HTTPS proxy support will do the trick. I got PuTTY in my PC which is perfect to do the trick. You only need to configure the corporate proxy in the Connection/Proxy preferences, try to connect to your server using the funny DNS name that matches the regexp and here you have!
Now, if you configure a tunnel using a local port to go out or a remote port to go in, or even if you use PuTTY as a socks server, you’ll have free rein.
Kill’em all TCP DoS
Last week a new hot topic arose in many security related blogs, podcasts and forums. A “new” and “devastating” DoS attack against TCP was revealed in a interview to two security researchers, Jack C. Louis and Robert E. Lee, both of them from Outpost24, who talked about their research in this podcast.
OK, a new “massive-destruction-bug”, one more to the list… do you remember when I wrote about the OpenSSL, BGP and DNS bugs? (in spanish).
The technical details that they have released are few and ambiguous, there were some confusion in many forums where people thought that it was a problem related with the Syn Cookies implementation, but it isn’t. They talked about Syn Cookies not in the server side but in the client side, as a way to establish a lot of connections without exhausting local resources.
Where’s the problem then? seemingly they were performing a massive scan and pentesting work with their UnicornScan tool when they found out that several hosts stuck, hanged even rebooted after the TCP connection was established in several “creative ways”.
Mainly it seems that one of those “creative ways” is the use a TCP window of 0, this means from the server point of view, that the client hasn’t enough resources (buffers) to receive data so the server waits until the retry timeout finish, send an ACK TCP segment to the client and waits for the answer to check if the window has been increased, in other words, if the client has now buffers to receive data.
It seems that if you establish several connections to a server that have an open TCP port, set a window of 0 in the initial negotiation during the three-way-handshake, and always answer to the ACK of the server with a window of 0, the server may end up using all the available resources, or maybe is just a matter of filling up the established connection table with never ending connections due to the 0 size TCP window.
From the client side, this work can be done with a minimum resource consumption as the connections are established through a TCP/IP stack in userland, and not the kernel one, here is when sockstress tool do the trick, besides that very few packets/bandwidth are needed to force the server to go to this state.
Maybe the problem is related to huge timeouts when a connection is in TIME_WAIT state, or with SACK before FIN state… Well I don’t know, there’re a lot of strange combinations that can end in a closed socket but with the related resources not correctly freed.
Neither a detailed technical explanation nor the sockstress tool has been released yet, so this is only a personal interpretation of what I have readed and listened. I guess that we’ll have to wait one more week to T2 Conference to learn more about all this mother-of-all-DoS thing. Some people is a bit skeptical about all this thing, just have to read Fyodor’s great post about all this topic.
Even though researchers assert that all network stacks (Windows, Linux, Solaris) are vulnerable to this bad client behaviour, no attack has been publicly reported to date. Hype? marketing to attract people to the conference? We’ll see in a week.
“The Grid” la red de datos del LHC
Hoy, a las 07:30 GMT, se ha puesto en marcha el LHC (Large Hadron Collider). Inicialmente, las pruebas de hoy van orientadas a comprobar que no hay ningún problema en los 27 Km que conforman el acelerador de partículas. El objetivo de hoy es conseguir que las partículas den una vuelta completa de forma estable, comprobando cada uno de los elementos que intervienen durante todo el recorrido.
Cuando toda la instalación se haya validado, lo cual podría ser dentro de unas semanas, comenzarán las primeras colisiones y la obtención de datos gracias a los cuatro grandes detectores que se encuentran a lo largo del recorrido:
- Experimento ATLAS: Su objetivo es detectar las partículas que aparezcan tras una colisión de protones. Aún siendo un detector polivalente, se centrará en detectar el bosón de Higgs. Por el momento, la partícula de Higgs es una hipótesis, no ha sido observada completamente hasta el momento y ha sido predicha por el modelo estándar de física de partículas. Confirmando su existencia se daría sentido a muchas teorías cuánticas elaboradas en los últimos años.
- Experimento CMS: Al igual que ATLAS su objetivo es detectar el bosón de Higgs. La diferencia entre ATLAS y CMS son los diseños de los detectores. En el caso de ATLAS se tiene un sistema magnético toroidal, formado por ocho bobinas de imanes, mientras que el CMS está formado por un único iman en forma de bobina. Tanto ATLAS como CMS buscarán también indicios de materia negra.
- Experimento ALICE: Este detector estudiará los quarks y gluones tras la colisión de iones de plomo. Este estado de la materia, el plasma de quarks-gluones, permitirá reproducir las condiciones que se dieron justo después del Big Bang.
- Experimento LHCb: Se centrará en el estudio del quark beauty o quark b, con el objetivo de averiguar por qué actualmente no existe una antipartícula para cada una de las partículas conocidas, tal y como sucedió tras el Big Bang.
Hay otros dos experimentos, TOTEM que comparte detector con el experimento CMS, y LHCf que comparte el detector ATLAS.
Pero, no voy a dedicar este post al LHC desde el punto de vista de los avances que habrá en el campo de la física gracias a estos experimentos que en él se realicen, ni a niguno de los polémicos aspectos de su puesta en marcha (fin del mundo, amenazas de muerte a científicos…).
Voy a dedicar este post a The Grid, la red de datos que se ha creado, en paralelo al LHC, para poder distribuir, almacenar y procesar la ingente cantidad de datos que se generan diariamente en el CERN en base a los experimentos realizados en el LHC.
La motivación principal en el diseño y despliegue de The Grid era disponer de una red de datos que uniera a los centros de investigación y académicos con el CERN, de tal forma que pudieran acceder y utilizar los datos generados a partir de los experimentos que se realicen. La cantidad de datos es ingente, se calcula que los experimentos asociados al LHC generarán alrededor de 15 petabytes de datos anualmente, y que los datos deberán estar accesibles durante los próximos 15 años, que es el periodo de vida previsto para el LHC.
La Internet actual no ofrecía ni la conectividad ni la capacidad necesaria para poder distribuir los datos a través de las conexiones existentes, así que se decidió la creación de una red paralela, diseñada en varias capas, e interconectada a partir de enlaces de fibra dedicados. Así nació, hace cinco años, el Worldwide LHC Computing Grid.
La red está estructurada, de forma jerárquica, en varias capas o niveles:
- El nivel-0 lo constituyen los sistemas del CERN. Todos los datos generados por los experimentos se transmiten a los sistemas del CERN, donde sufren un primer filtrado y análisis y donde se almacenan en cinta. Esto supondrá unos 27 TBytes de datos raw diarios.
- Al CERN se conectan, mediante enlaces dedicados de 10 Gbps, once centros que conforman el Nivel-1, estos centros están situados en Canada, Francia, Italia, España, Alemania, Holanda, países Nórdicos, Taipei, Reino Unido y Estados Unidos. Estos centros reciben subconjuntos de datos raw así como de datos resumidos. En el Nivel-1 se almacenan los datos recibidos en cinta.
- Desde el Nivel-1 se distribuyen los datos al resto de Nivel-1 y al Nivel-2, que está formado por otros 120 centros académicos y de investigación de todo el mundo. Es en estos centros donde se hace la mayoría del análisis, y las simulaciones. Los resultados son enviados de vuelta al Nivel-1.
- El último nivel de la red, el Nivel-3, estará formado por centros de cálculo de universidades o incluso redes de ordenadores particulares.
La capacidad de cálculo necesaria para analizar los datos que se generen por los experimentos del LHC se estimó en el año 2.006 en aproximadamente unas 100.000 CPUs atendiendo a la potencia de cálculo de hace un par de años.
El centralizar esta potencia de cálculo en data center del CERN se vió totalmente inviable, por lo que se optó por una arquitectura de cálculo distribuida. La gestión de los servicios de cálculo se realiza en base a la colaboración de varios organismos que cuentan con infraestructuras de computación grid. En concreto se trata de EGEE, OSG y Globus Alliance.
EGEE (Enabling Grids for E-sciencE) es un proyecto fundado por la Comisión Europea para proveer a los científicos de una infraestructura de cálculo disponible permanentemente, en base a infraestructuras grid de menor tamaño que se unan al proyecto, y que pueden tener caracter local o regional. Actualmente forman parte de este grid 250 organismos repartidos por 50 paises, proporcionando 68.000 núcleos de CPU y 20 petabytes de almacenamiento al proyecto.
OSG (Open Science Grid) consorcio de universidades y centros de investigación localizados en América del Norte, América del Sur y Asia. El proyecto está financiado por el NSF (National Science Foundation) y por la oficina de Ciencia del DoE (Department of Energy) de Estados Unidos.
Globus Alliance aúna los esfuerzos de varias universidades y laboratorios de investigación para el desarrollo de tecnologías grid open-source.
La integración dentro del GRID se haría a través del middleware oficial, que por el momento es el middleware gLite, evolución del middleware desarrollado para el proyecto EGEE y que ha incorporado funciones de otros proyectos como el LCG y el VDT.
Por otro lado, a través del CERN OpenLab, las empresas pueden probar nuevas tecnologías aplicables a la computación grid en el marco del LCG. Es una relación por la cual las empresas obtienen un campo de pruebas dentro de los proyectos del CERN, y a su vez el CERN obtiene tecnología de última generación.
OpenSSL, DNS o BGP: ¿algún bug histórico más?
En los últimos meses no hacen más que anunciarse fallos de seguridad que afectan a los protocolos base de Internet, yo al menos no recuerdo una época en la que saliesen a la luz tantos avisos considerados como “el peor bug de la historia” y que además tuviesen tanto eco en publicaciones no especializadas de carácter general quienes, por desgracia, caen con suma facilidad en el sensacionalismo.
El “apocalipsis” comenzó en mayo cuando Luciano Bello avisó de que la generación de números aleatorios del paquete OpenSSL incluido en Debian era de todo menos aleatoria, lo cual dejaba en entredicho todo el material criptográfico generado desde la incorporación a la distribución de la versión 0.9.8c-1.
El origen de este fallo es totalmente absurdo, se comentaron unas líneas de código para evitar unos warnings en la compilación, y quitar ese código significó el no inicializar correctamente con datos aleatorios el PRNG (Pseudo Random Number Generator) de OpenSSL, el cual se inicializaba únicamente en base al PID del proceso actual… esto hace que sea totalmente predecible su resultado ya que pueden replicarse en cuestión de horas los 32.768 posibles escenarios (uno por cada posible PID) y generar todas las claves RSA de 1.024, 2.048, 4.096 bits… esto supone: vulnerar la autenticación RSA de servidores SSH, romper el intercambio de claves Diffie-Hellman, clonar certificados SSL… es decir, hay que regenerar todo aquello que se generó en base a un PRNG predecible :(
Las herramientas para explotar este fallo no se hicieron esperar, y como no, el bug tuvo su pequeño hueco en la DefCon de este año de mano de su descubridor, Luciano Bello, quien ofreció una presentación sobre el tema.
Aún estábamos actualizando servidores y certificados cuando a principios de julio Kaminsky nos viene con el tema del DNS, que ya comenté en el post “El culebrón del DNS“. Pero por si esto no fuera poco, la DefCon revive viejos fantasmas, y me estoy refieriendo al protocolo de encaminamiento BGP (Border Gateway Protocol), uno de los pilares sobre los que se apoya la Internet que conocemos hoy día.
Las debilidades de BGP son bien conocidas, organismos como el NIST, han elaborado informes analizando la seguridad del protocolo y lleva hablándose de este tema desde hace más de 10 años, pero estas cosas son como cuando se barre y se mete la basura debajo de la alfombra, cada cierto tiempo alguien te recuerda que la mierda sigue ahí y que sería mejor hacer una limpieza a fondo.
En esta ocasión los encargados de recordarnos que debajo de la alfombra hay aún mucha mierda que limpiar han sido Alex Pilosov y Anton Kapela, quienes demostraron un ataque MitM en toda regla redirigiendo todo el tráfico destinado a la red de la DefCon hacia sus sistemas de Nueva York (pilosoft.com) antes de enviarlo de nuevo hacia Las Vegas. Lo mejor es que echéis un vistazo a su presentación.
¿Y esto se pueda hacer?… pues sí, se puede hacer y el problema es que “cualquiera” lo puede hacer, ya que no se trata de explotar un 0-day ni nada por el estilo, es una cuestión de diseño de la red, de abusar de un protocolo que se diseñó para una red en la que los nodos confiaban unos en otros… está claro que la ARPANET de los 70 está bastante lejos de la Internet actual. Un comportamiento inadecuado por parte de uno de los nodos, ya sea de forma intencionada o no, puede provocar una situación “delicada” a nivel de routing en Internet.
El ejemplo más claro en este sentido lo protagonizaron el pasado mes de febrero, el Gobierno de Pakistán y YouTube. El Gobierno de Pakistán quería evitar que se accediera a YouTube desde su país debido a un video que estaba publicado y que consideraban ofensivo, así que le pidió a Pakistan Telecom que bloquease el rango de direcciones correspondiente al servicio de Google. Una mala configuración en los routers provocó que se anunciara por BGP el rango de direcciones 208.65.153.0/24, subred que pertenece a YouTube. El peer de Pakistan Telecom, PCCW no filtró estos anuncios, así que se propagaron. El problema está en que esa subred pertenece a un prefijo más general, el 208.65.152.0/22, que es anunciado por el AS36561 (YouTube). Al anunciar el AS17557 (Pakistan Telecom) una ruta más específica, provocó que a los pocos minutos esa información fuera incorporada por el resto de routers de Internet y que todo el tráfico destinado a servidores de YouTube dentro de esa subred se perdiera, ya que los routers de Pakistan Telecom estaban descartando todo el tráfico destinado a esa subred. Se produjo un DoS en toda regla durante casi 2 horas.
Si os sorprende que un “despiste” de este tipo pueda ocasionar un escenario tan grave, os recomiendo que veáis el video donde la gente de RIPE explica el seguimiento que se hizo a este suceso.
El caso de YouTube fue un accidente, o al menos esa fue la declaración oficial de Pakistan Telecom. Ahora bien, ¿y si se quiere capturar tráfico destinado a redes que no nos pertenecen de forma malintencionada?… este es el escenario del cual se ha advertido en la DefCon, y del cual se viene advirtiendo desde hace más de 10 años ya.
Un atacante podría anunciar por BGP direccionamiento que no le pertenece. Si el anuncio que hace consigue ser más “atractivo” que el anuncio de la victima, conseguirá desviar hacia sus sistemas el tráfico destinado hacia el prefijo de la víctima. Se puede ser “más atractivo” publicando una ruta más específica o presentando un AS-path más corto. El resultado es un ataque en el cual el tráfico capturado puede ser analizado y/o modificado antes de ser reenviado al destino legítimo. Hay que notar que “la belleza” de la técnica presentada en la DefCon es conseguir hacer el hijacking sin generar una pérdida de tráfico, es decir, generar un MitM limpio para que el tráfico desviado finalmente alcance su destino, por lo que puede ser un ataque dificil de detectar a no ser que se estén comprobando en tiempo real las rutas que sigue el tráfico, en busca de AS intermedios no autorizados anunciando tus prefijos, a modo de “IDS BGP“.
Pilosov y Kapela hicieron su demo en base a un “AS path prepending” para conseguir reenviar el tráfico capturado a su destino original y no causar un DoS sino hacer un MitM. Por otra parte jugando con los TTL de los paquetes consiguieron ocultar los AS intermedios.
El “AS path prepending” es un “truco” para influir en el camino que seguirá el tráfico hacia un destino, en base a hacer el atributo AS-path más corto o más largo, sabiendo que se prefieren los AS-path más cortos, es decir, el camino hacia un destino con menos AS intermedios. Si un AS hace “AS path prepending” lo que está haciendo es indicar varias veces su AS en un anuncio BGP, de tal forma que se favorezca la llegada de tráfico por un camino en vez de por otro. Esto es típico cuando se tienen varias conexiones a Internet con diferentes ISP y se quiere favorecer el enlace principal en vez de el de backup. Se haría “AS path prepending” por el enlace de backup.
Ahora bien, no nos confundamos, aplicado a este escenario de ataque, el “AS path prepending” es usado para incluir en los anuncios del prefijo para el cual se está haciendo el IP hijacking los AS que se quieren usar para hacer llegar el tráfico IP de vuelta al destino. Cuando estos AS ven el anuncio enviado por el atacante lo descartan, ya que ven en el AS-path que ellos están incluidos en el camino hacia el destino, eso implicaría un bucle, y por tanto lo descartan. De esta forma el atacante consigue tener un camino “sin contaminar” con sus anuncios, y que tomará sus decisiones de routing en base a otra información, que seguramente sean los anuncios BGP originados en el AS atacado. El atacante debe establecer una ruta estática hacia el primer nodo de este camino de vuelta para poder hacer llegar el tráfico IP al destino una ve haya sido interceptado.
Pero pensemos que el hacer un MitM limpio no siempre es el objetivo. Publicar un prefijo ajeno, para terminar las conexiones en tus sistemas haciéndote pasar por el sistema atacado puede ser un escenario muy grave si pensamos en distribución de malware, phising, etc.
¿La solución? Que los routers no confien en la información de routing que les llega, ser más desconfiado, y comprobar que los AS que anuncian redes lo están haciendo de prefijos que les pertenecen y no se están apropiando del direccionamiento de otros.
Decir la solución es fácil, implementarla ya es otra historia. Eliminar esta amenaza implica que los ISP apliquen estrictas políticas de filtrado con sus peers de BGP, de tal forma que únicamente se acepten los prefijos declarados de los peers autorizados. Otro acercamiento al problema es desplegar SBGP, que ofrece la posibilidad de autenticar los anuncios de rutas, de tal forma que se pueda validar un anuncio BGP en base al AS que lo emite y al prefijo que anuncia. Esto implica el despliegue de toda una infraestructura PKI y de dar soporte para ello en los routers.
Desgraciadamente, es improbable que se ponga en marcha debido al tiempo y dinero que llevaría el desplegar esta arquitectura, y las estimaciones más optimistan hablan de un tiempo de implantación de unos 2 años si empezásemos a trabajar en ello ahora mismo.
Por tanto, por el momento, es interesante el hacer uso de los servicios de monitorización y alerta ante cambios en el AS-path hacia tus prefijos en espera de que se haga un filtrado generalizado a nivel de ISP y/o se desplieguen mecanismos como SBGP.
El culebrón del DNS
Recién finalizadas tanto la BlackHat como la Defon de este año, me gustaría comentar brevemente el “culebrón” del DNS, que realmente ha dado muchisimo juego durante estos últimos meses, y que tiene como colofón la charla de Dan Kaminsky en ambas convenciones sobre este tema.
Kaminsky descubrió un problema de envenenamiento de caché DNS a principios de este año. Dada la gravedad del asunto, ya que podría afectar potencialmente a la mayoria de DNS presentes en Internet, en marzo se reune con los principales fabricantes e ISPs para exponerles la vulnerabilidad y que tomen las medidas necesarias para solventarlo. Comienza un proceso de parcheo de servidores DNS. A principios de julio Kaminsky hace pública la vulnerabilidad y se generan los avisos de seguridad correspondientes.
Kaminsky pide a la comunidad de expertos en seguridad que no adelanten detalles, al menos hasta que él haga público oficialmente el fallo durante el mes de agosto, en el BlackHat y la Defcon. Esta ventana de 1 mes entre la publicación oficial del fallo y la explicación técnica detallada que Dan promete para el BlackHat tiene el objetivo de dar algo de tiempo para que se realice el parcheo de todos los servidores vulnerables presentes en Internet antes de que se publiquen exploits.
Parte de la comunidad critica durametne a Kaminsky y le acusan de orquestar todo este tema para publicitarse… no hay que olvidar que Dan Kaminsky tiene una gran parte de showman y algo así le viene fenomenal para publicitarse y aparecer en la BlackHat y la Defcon como el principal ponente. Prueba de ello es que en su aparición en la Defcon consiguió reunir a más de 1.000 personas en su charla y no me extrañaría que en diciembre, este tema del DNS aún le siga dando juego para su participación en el CCC de este año.
Al poco de hacerse pública la vulnerabilidad, empezaron a aparecer explicaciones técnicas en muchos blogs, siendo algunas hipótesis realmente acertadas y detalladas, lo que permitía la generación de exploits sin ningún problema a poco que se entendiese de qué iba el asunto y se tuviesen ciertas habilidades de programación.
En un par de semanas ya había un par de módulos (DNS BailiWicked Host Attack y DNS BailiWicked Domain Attack) del framework Metasploit que comprobaban y explotaban el fallo. No se había agotado el tiempo de 1 mes marcado por Kaminsky antes de su aparición en la BlackHat. Surge la polémica y se reabre el eterno debate del full disclosure. Hay que tener en cuenta una cosa… que un fallo de seguridad no se haga público o que sus detalles técnicos no salgan a la luz, no significa que no haya exploits “in the wild“.
Llega agosto, se celebra la BlackHat y la Defcon. Kaminsky hace su multitudinaria aparición y hace la tan esperada presentación.
Y ahora, lo divertido… ;)
Supongamos que queremos envenenar la caché de ns.victima.es para meterle un RR que asocie la dirección IP 1.2.3.4 al nombre www.banco.es
Generamos múltiples consultas por nombres dentro del dominio banco.es del tipo 001.banco.es, 002.banco.es, 003.banco.es … 999.banco.es y se las enviamos a ns.victima.es
ns.victima.es comenzará el proceso de resolución necesario para obtener la respuesta a esas consultas, que para todas y cada una de ellas será un NXDOMAIN desde ns.banco.es, que es el servidor DNS autorizado para el dominio banco.es, ya que el nombre consultado es desconocido para él.
A nosotros nos interesa hacernos pasar por ns.banco.es y que nuestra respuesta llegue antes del NXDOMAIN para que sea introducida en la caché del servidor ns.victima.es
Para que nuestra respuesta sea aceptada, el TXID debe ser el mismo que el que generó ns.victima.es para la consulta. Nosotros no sabemos cuál es, pero podemos enviarle un número considerable de respuestas, cada una de ellas con un TXID y sentarnos a ver qué pasa ya que la probabilidad juega a nuestro favor.
Si alguna de nuestras múltiples respuestas a una de las múltiples consultas, que hemos forzado a ns.victima.es a realizar, tiene el TXID correcto, el RR de respuesta será aceptado y cacheado durante el tiempo que se indique en el TTL. Lo que se va a enviar en estas respuestas son registros NS, es decir, referencias a los DNS que pueden resolver el nombre por el que se pregunta. En resumen, lo que aparentemente ns.banco.es le está diciendo a ns.victima.es es lo siguiente: “me has preguntado por 137.banco.es y yo no sé cuál es su dirección IP, pero quién lo sabe y a quién tienes que preguntar es www.banco.es cuya dirección IP es 1.2.3.4″.
Cuando ns.victima.es recibe esta respuesta de quien aparentemente es ns.banco.es y que es a quien ha preguntado, y la acepta porque el TXID es correcto, automáticamente cachea la asociación www.banco.es/1.2.3.4
Los administradores de ns.victima.es hacen bien su trabajo, y no permiten consultas recursivas a sus DNS desde Internet. ¿Son vulnerables?. La respuesta es sí. Desde luego, si desde Internet podemos forzar a un DNS a generar una consulta porque permita recursividad, nos están poniendo las cosas muy fáciles. Pero eso no implica que no se pueda “forzar” a un DNS a generar ciertas consultas, ya que cualquier usuario que navegue por una web en donde haya un recurso que requiera esa resolución, generará una consulta a su DNS, la recepción de una conexión SMTP en donde se indique ese dominio en el HELO o en el MAIL FROM provocará una consulta… hay muchas formas de generar ese tipo de consultas de forma indirecta.
La solución a este tipo de escenario es complicada desde el punto de vista de que se está explotando una característica propia del diseño del protocolo DNS. El cómo explotarlo se ve simplificado por el hecho de que el único impedimento entre la aceptación de una respuesta falsificada o una real es un TXID que tiene “unicamente” 65.536 posibles valores. El puerto origen suele ser fijo (53) o secuencial, por lo que es trivial de predecir y no añade complejidad de cara al atacante.
Una mejora es usar puertos origen aleatorios en las consultas. De esta forma no hay que “predecir” únicamente el TXID sino también el puerto origen.
Por otro lado el servidor de DNS puede ser capaz de detectar ataques de este tipo, detectando la llegada de numerosas respuestas con puerto origen y TXID incorrectos para una consulta generada. No es algo que pase desapercibido.
Interesante también el saber que hay en desarrollo un RFC para reforzar la seguridad de DNS en este sentido, actualmente es un draft y su lectura es muy interesante, nos llega de la mano de Bert Hubert el autor de PowerDNS.
Proyecto Ibercivis
En mi anterior post comenté brevemente mi motivación a la hora de publicar en el blog información relativa a computación distribuida voluntaria y realicé una pequeña introducción al tema. En este post paso a comentar el proyecto Ibercivis, como ejemplo práctico de aplicación de todos esos conceptos a una plataforma de computación usada por los investigadores españoles en áreas como el estudio de nuevos materiales, la búsqueda de fármacos más eficaces o el estudio de nuevas fuentes de energía limpias e inagotables.
En el siguiente post que escriba sobre este interesante tema me centraré en BOINC, el middleware que se ha convertido en el estándar de facto para Desktop Grid Computing, e intentaré sintetizar cómo crear tu propia plataforma de computación basada en BOINC, ya que al fin y al cabo es lo que quiero proponer como proyecto de innovación dentro de mi centro de trabajo, para que lo evalúen como alternativa computacional para los problemas que se consideren como de paralelismo débilmente acoplado.
Pero por el momento, conozcamos el proyecto Zivis e Ibercivis…
Ibercivis es un proyecto de computación distribuida voluntaria (también referenciado a veces como computación ciudadana), de caracter científico, basado en el middleware BOINC que se encuentra activo desde el pasado mes de abril. Pero empecemos por el principio, Ibercivis nace como evolución del proyecto Zivis, así que conozcamos en primer lugar qué es Zivis.
Zivis se presentó en sociedad un año antes que Ibercivis, en abril de 2.007. El coordinador del proyecto, Alfonso Tarancón, contó con el apoyo del Ayuntamiento de Zaragoza, del BIFI (Instituto de Biocomputación y Física de Sistemas Complejos) y del LNF (Laboratorio Nacional de Fusión) e inicialmente nació con un carácter muy local, cuyo ámbito iba a ser principalmente la provincia de Zaragoza en particular y el resto del territorio español en general, aunque lógicamente ponerle fronteras a un proyecto de computación distribuida en Internet no tiene mucho sentido, y en la práctica hubo participantes de otros paises de Europa y del continente americano. Zivis estuvo activo, exclusivamente, durante un mes y medio, cediendo capacidad de cálculo para el desarrollo del reactor de fusión ITER. Durante este tiempo tuvo el rendimiento equivalente de un supercomputador de 800 CPUs, generando 800.000 horas de cálculo y ahorrando de este modo casi 1 año de trabajo a los investigadores con los recursos disponibles del CIEMAT. Si los investigadores del CIEMAT hubieran tenido acceso a Mare Nostrum, hubieran hecho en 3 días lo que con Zivis hicieron en mes y medio, pero el superordenador español está tan demandado y su utilización tan restringida que es mucho más factible hacer uso de un superordenador virtual como lo fue Zivis y actualmente lo es IberCivis.
Inicialmente Zivis se marcó los siguientes objetivos:
- Obtener la participación de 1.000 usuarios con sus 1.000 PC.
- Obtener 20.000 horas de CPU.
- Dar a conocer el proyecto al público general.
Los resultados obtenidos, en únicamente 1 mes y medio, fueron más allá de lo esperado:
- Se obtuvo la participación de 3.000 usuarios.
- Se registraron 5.500 PC.
- Se obtuvieron 850.000 horas de CPU.
- Se calcularon 4.2 millones de trayectorias de particulas dentro del reactor.
A modo de resumen, un buen reportaje que se emitió en su día sobre Civis es el del programa de divulgación “A Ciencia Cierta” de TVE, en donde entrevistan a Alfonso Tarancón, director del proyecto.
Un año después del fantástico éxito de Zivis, nace IberCivis. Un proyecto de ámbito nacional (aunque la participación está abierta a cualquier voluntario de todo el mundo), que cuenta como director, una vez más, a Alfonso Tarancón y en donde se incorporan dos nuevos proyectos en los que participar además del de fusión que sirvió como experiencia piloto en Zivis.
A fecha de hoy, la plataforma de computación Ibercivis permite la participación en tres proyectos:
- Fuentes de energía. Una de las líneas de investigación más importantes hoy día es en nuevas fuentes energéticas de cara a un futuro en el cual ya se habrán agotado los recursos que se explotan en la actualidad. Una de las áreas de investigación en la que se trabaja es la fusión por confinamiento en campo magnético. Quizás en un futuro la energía eléctrica necesaria para nuestro desarrollo provenga de plantas de producción de energía como ITER situada en Cadarache, en el sur de Francia, y que se tiene previsto entre en funcionamiento en el año 2016. Para que esto sea posible, se necesita experimentar con la creación de plasmas de fusión, es decir, recrear en la Tierra y en un entorno controlado los mismos escenarios que se crean en las estrellas, los rayos… es decir, alcanzar el estado físico de la materia cuando es calentada millones de grados. En este estado de la materia, los electrones y los iones generan nuevos comportamientos colectivos que pueden aprovecharse para obtener una fuente de energía limpia y virtualmente inagotable.
- Medicamentos. Los medicamentos están formados por una sustancia química llamada principio activo, y que es la que actúa en el organismo, y por otro conjunto de componentes llamados excipiente que son los encargados de hacer llegar al princpio activo al punto del organismo sobre el que debe actuar. El momento en el que el principio activo encuentra su centro activo y se acopla a él se denomina docking. Este proceso es muy complejo y se realiza una investigación muy activa en este campo para optimizar el comportamiento de los fármacos, minimizando los efectos secundarios. Para ello es necesario realizar complejas simulaciones de cómo se unen las moléculas de las proteinas y de los principios activos de los fármacos.
- Simulación de materiales. La investigación se centra principalmente en la simulación de vidrios. El conocimiento en estos materiales permitirá avances en la investigación de los spin-glasses, de los superconductores o de la magnetorresistencia colosal (CMR) base de los avances en el desarrollo de cabezas de lectura/escritura de discos para almacenamiento magnético de alta capacidad.
En el siguiente video se explica perfectamente la filosofía de trabajo que hay detrás de Ibercivis y los proyectos en los que se puede participar hoy día.
Los resultados de Ibercivis parecen buenos de acuerdo a las estadísticas que se pueden consultar en boincstats. A fecha de hoy estos son algunos de los datos más relevantes:
- Unos 2.000 usuarios activos de unos 2.700 usuarios censados.
- Unos 3.500 equipos activos de unos 4.500 equipos censados.
- Una capacidad de calculo de unos 1,867 TeraFLOPS.
Para seguir al día la evolución de Ibercivis, lo mejor es visitar su blog o el blog de investigadores y por su puesto unirse al proyecto. Si os animáis podemos crear un equipo y ceder algunos ciclos de CPU ;)
Computación Voluntaria Distribuida
Hoy, hablando con un compañero del trabajo, me he enterado de una cosa que nunca me habría imaginado que se hiciera en donde me gano la vida actualmente. Parece ser que una vez al año se conceden premios a aquellos proyectos que por su innovación o eficacia supongan un avance para el Departamento de Informática en el que actualmente trabajo. Hay que decir que la organización en la que me encuentro no es precisamente una empresa tecnológica, por lo que su negocio no es la tecnología. Para ellos la tecnología no es más que una herramienta, un medio, de conseguir su objetivo, que no es de caracter tecnológico sino de caracter económico/fiscal.
Al enterarme de que había la posibilidad de presentar una propuesta de innovación tecnológica me ha dado el subidón, ya que me ha parecido la oportunidad de hacer algo interesante durante este mes de agosto de cara a poder presentarlo a partir de septiembre una vez se abra el plazo de presentación de propuestas y me vaya enterando de cuáles son las condiciones en las que se deben presentar estas propuestas.
Ahora bien, la organización para la que trabajo podriamos decir que es “demasiado conservadora” en el sentido de que su prioridad es el negocio, y como suele ser bastante habitual en organizaciones con esta filosofía de “si funciona no lo toques”, cuanto mas clásica y estable sea la infraestructura tecnológica que sustenta el negocio mejor, experimentos pocos y además observados con lupa, reticencia y en muchos casos, hasta rechazo :(
Esto hace que sea bastante escéptico en cómo puedan evaluarse realmente las propuestas que se hagan, en cualquier caso… me parece un ejercicio interesante el desarrollar la propuesta, así que aunque no sirva de nada dentro de mi organización… hacerlo lo voy a hacer ;)
Aprovechando este mini-proyecto que me he marcado he pensado que podría ser interesante ir publicando en el blog piezas de información que vaya desarrollando para el documento que voy a presentar como propuesta, además de que precisamente va a ser sobre un tema que queríamos tratar con cierta profundidad en el podcast… por tanto, de una forma u otra… I’ll have fun with it! que a fin de cuentas es lo que importa, ¿no? ;)
¿Y qué es lo que voy a proponer?… la organización en la que trabajo es bastante grande, estamos hablando de 30.000 puestos de trabajo con PC relativamente potentes que durante la jornada de trabajo estándar de 8 horas están totalmente infrautilizados, y luego se encuentran 16 horas completamente ociosos. Es un escenario ideal para proponer una solución de computación grid basada en BOINC, creando un superordenador virtual que complemente la capacidad de cálculo que actualmente se concentra en servidores pSeries de IBM para un conjunto de aplicaciones muy concretas que hay en mi organización basadas en redes neuronales y cálculos masivos con datos extraidos de un datawarehouse.
De todas formas, sobre el escenario concreto en el que se encuentra mi organización hablaré en algún post futuro, por el momento introduzcamos el escenario tecnológico en el que se desarrollará mi propuesta. Ni que decir tiene que cualquier comentario es bien recibido :)
Computación voluntaria distribuida… ¿y eso qué es?
Puede definirse como una plataforma de computación distribuida donde los recursos hardware de cálculo y/o almacenamiento son provistos, de forma voluntaria por el público general, quienes destinan parte de los recursos disponibles en sus ordenadores personales conectados a Internet a proyectos de investigación concretos, normalmente de carácter científico o académico.
Un detalle importante vinculado al concepto de voluntariedad es que los participantes permanecen anónimos, y se establece una relación de mutua confianza entre el usuario que destina parte de sus recursos personales al objetivo del proyecto que ha sido declarado oficialmente y el coordinador del proyecto que confía en que los resultados obtenidos del usuario no han sido manipulados maliciosamente.
El proyecto GIMPS (Great Internet Mersenne Prime Search) es considerado como uno de los primeros proyectos de computación voluntaría, y se remonta al año 1.995. Posteriormente se hicieron relativamente famosos otros proyectos como los de cracking de algoritmos criptográficos de distributed.net en 1.997 o el proyecto SETI@Home en 1.999, el cual dió pie al desarrollo de BOINC (Berkeley Open Infraestructure for Network Computing). Actualmente hay toda una variedad de proyectos de computación distribuida en donde participar.
El escenario actual en donde cada vez hay más dispositivos conectados a Internet, donde las conexiones permanentes de banda ancha son el modelo de conectividad residencial predominante, donde los equipos informáticos y de ocio tienen capacidades de proceso cada vez mayores y que exceden en mucho lo necesitado realmente por el usuario. Con todo esto, el modelo voluntario de computación distribuida tiene gran sentido hoy día, ya que se dan los factores necesarios para su éxito.
Vamos a analizar con algo más de detalle algunos de estos factores.
Creciente número de individuos conectados a Internet. Según los últimos datos publicados por el Instituto Nacional de Estadística relativos al pasado año 2.007, casi el 45% de los hogares españoles se encuentra conectado a Internet, de los cuales el 39% lo hace a través de un enlace de banda ancha. Si hablamos de cifras concretas, estaríamos barajando unas cifras de alrededor de 6.5 millones de viviendas conectadas a Internet, siendo hoy día unos 15 millones de personas las que se pueden considerar usuarios frecuentes de Internet.
Capacidad de cálculo y conectividad. Tomando la cifra de 6.5 millones de viviendas conectadas a Internet como referencia y, suponiendo según los datos estadísticos del INE, que aproximadamente unos 6 millones lo hacen usando banda ancha (ADSL, cable, etc.), nos encontramos con 6 millones de potenciales colaboradores en proyectos de computación voluntaria, ya que son usuarios con, al menos, un ordenador personal, conectado a Internet por banda ancha, y con la posibilidad de estar on-line y activo 24 horas. Lógicamente, lo que no se puede esperar es que estos 6 millones de hogares conectados cuenten con lo último en tecnología y que la dedicación de sus equipos a computación voluntaria sea del 100%. Supongamos un escenario realista-pesimista :) en el cual los equipos caseros con los que podemos contar tienen alrededor de 5 años de antiguedad, lo que nos daría un parque de equipos similares al Pentium 4 de 3.2 GHz con rendimientos alrededor de los 9.000 MIPS y los 6.000 MFLOPS. Si fuésemos optimistas nos imaginaríamos un escenario donde los participantes tienen Quad-Core de Intel a 3 Ghz dando cada uno aproximadamente 50 GFLOPS… o si ya dejamos volar la imaginación podemos pensar en PC equipados con tarjetas gráficas que ofrecen GPUs capaces de proporcionar 100 GFLOPS ;)
Supongamos que los usuarios de estos ordenadores personales, dejan sus equipos encendidos las 24 horas, y se puede contar con una franja horaria de alrededor de 8 horas (quizás en horario nocturno) en la cual el usuario no hace uso interactivo de su PC, y lo dedica a labores de computación voluntaria. Nuestro hipotético escenario daría como resultado un super-ordenador virtual de 36 PetaFLOPS disponible durante 8 horas al día.
Teniendo en cuenta que la supercomputadora más potente del mundo (según el TOP500 y su lista del pasado mes de junio) actualmente es el Roadrunner de IBM ofreciendo un rendimiento de 1 PetaFLOP, una plataforma de computación voluntaria de este tipo, aún siendo dependiente de la participación voluntaria e impredecible de usuarios particulares, es una opción realmente interesante para aquellos proyectos científicos que necesiten del procesamiento masivo de grandes cantidades de información.
Esta es precisamente la filosofía que hay por detrás del proyecto IberCivis, que se presentó en sociedad hace unos meses y de la cual hablaré más en detalle en un futuro post. Hay que tener en cuenta que desde el punto de vista presupuestario, el cubrir las necesidades de cálculo en base a una plataforma de computación voluntaria “gratis”, evita cargar el coste de esta infraestructura a los presupuestos de los proyectos, los cuales ya de por sí arrancan con presupuestos limitados y en muchos casos insuficientes, en clara contraposición con el modelo clásico en el que hay que cargar al presupuesto del proyecto lo que cuesta el tiempo de cálculo en superordenadores privados o institucionales.
Por otro lado, el promover este tipo de plataformas realiza una tarea de divulgación científica importante de cara al público general, que puede participar activamente en los proyectos científicos y ser parte de los avances conseguidos por ellos.
Computación Voluntaria vs Computación Grid
El rasgo diferenciador más claro es el anonimato o no de los participantes. En un modelo de computación voluntaría, los participantes son completamente anónimos y no son auditables. En un modelo de “Desktop Grid Computing” dentro de una organización (o dominio), los equipos/usuarios participantes no son anónimos, están inventariados, son gestionables y son auditables. Los recursos que se dedican para crear la infraestructura de computación son recursos corporativos y la topología es conocida, por lo que puede adoptarse un modelo “push” (comunicación hacia el cliente) en contraposición con el modelo “pull” (comunicación desde el cliente) necesario en un modelo de computación voluntaria en el que el cliente pueden estar detrás de firewalls y otros elementos de red que impidan una comunicación directa hacia el cliente. Dentro de un modelo de computación grid también se pueden establecer relaciones entre diferentes organizaciones, para solicitar y hacer uso de los recursos de computación de los que disponga cada organización.
Superordenador vs Grid
Según datos de la lista elaborada en junio de la Top500 Supercomputing Sites el actual número 1 con un total de 1,026 petaflops es el ordenador Roadrunner, desarrollado por IBM para el Laboratorio Nacional de Los Alamos del Departamento de Energia de los EEUU. El Roadrunner está formado por servidores Blade IBM QS22 interconectados por Infiniband, mezcla 12.960 procesadores IBM PowerXCell 8i con 6.480 AMD Opteron dual-core, corre Fedora Linux y hace uso del middleware de computación distribuida xCat.
En contraposición a este “número uno” tenemos otro “número uno”, el superordenador virtual que da pie al proyecto Folding@Home, uno de los proyectos actualmente activos que cuenta con mayor número de participantes. El proyecto FaH superó el petaflop en septiembre de 2.007 gracias a la liberación del cliente para Sony PS3, esto supuso un incremento considerable en la capacidad de cálculo, al incorporar los poderosos procesadores Cell de las PS3 de los nuevos voluntarios que se unieron al proyecto. Hasta ese momento el proyecto contaba con alrededor de 250.000 CPUs activas, la incorporación de usuarios con PS3 supuso un importante incremento de usuarios y un salto inmediato a rendimientos superiores a petaflops. Actualmente, otro nuevo salto de rendimiento se ha producido con la liberación del cliente para GPUs de tarjetas gráficas. Esto ha supuesto la incorporación de 4.000 GPUs aportando alrededor de 450 teraflops de proceso, lo que supone para el proyecto, un rendimiento global de 2.52 Petaflops, según los últimos datos de junio.