21 marzo 2009

Evitando las escuchas en redes conmutadas

En un artículo que publiqué en Diciembre hablé sobre distintas técnicas para realizar escuchas en redes conmutadas. Me quedó pendiente desarrollar qué opciones tenemos frente a este tipo de ataques.

Las ataques de ARP Spoofing, también llamados envenenamiento ARP, se basan en introducir información falsa en las tablas de ARP de uno (o ambos) de los de los extremos de una comunicación con el fin de que este utilice inadvertidamente al atacante como intermediario a la hora de trasnmitir y recibir información. Esto permite al atacante no sólo espiar la información intercambiada por el atacado, sino también modificarla a su antojo.

Para combatir con eficacia este tipo de amenazas, un ingeniero de seguridad debe ser consciente de las técnicas de prevención, detección y reacción que puede emplear contra ellas.

La principal técnica de prevención es un buen diseño de la red. Muchos ingenieros no se dan cuenta, pero poner PCs de usuario en redes de paso supone un verdadero riesgo ya que si alguno decidiese utilizar herramientas de ARP Spoofing podría interceptar no sólo el tráfico destinado y originado hacia/desde su segmento sino todo aquel que lo utilice como red de tránsito. Un diseño correcto puede limitar a un único segmento de red el daño que un atacante puede realizar mediante ARP Spoofing. La manera de evitar esto es mantener las redes intermedias de tránsito vacías de PCs de usuarios, concentrando a estos en segmentos localizados en las "hojas" de nuestra red.



A la izquierda de la figura anterior (no se por qué pero Blogger la saca muy borrosa, si quiere ver el original, mucho más definido, pulse sobre la imagen) se puede ver una red mal diseñada al permitir que la red de paso (B) contenga PCs de usuario. Cualquiera de estos PCs de usuario puede lanzar un ataque de ARP Spoofing para desviar el tráfico cursado entre el router interior y el exterior con el resultado de que podría espiar todo el tráfico saliente de la red A.
A la derecha de la figura anterior se encuentra un diseño correcto. En él, la red B se ha vaciado de PCs de usuario. Los PCs que antes estaban en B han pasado a una red "hoja", C. Gracias a este diseño, un atacante de la red C sólo podría escuchar el tráfico de su red pero no de la B.

Este buen diseño sobre el papel debe desplegarse en la práctica de manera correcta. Si a pesar de haber vaciado de PCs las redes de tránsito, un intruso puede pinchar un portátil a una de estas redes seremos igual de vulnerables que antes. Para evitarlo hay que tomar medidas preventivas en los niveles de la capa OSI 2 y 1 (enlace y físico):
  • En la capa 2 hay que segmentar los conmutadores que dan servicio a las distintas redes en VLANs separadas asignando a cada VLAN única y exclusivamente los puertos dedicados a cada uno de los equipos residentes en ellas. Muchos administradores dejan puertos libres en cada VLAN por si un día se necesita pinchar urgentemente un equipo a ellas sin tener que esperar a que el administrador lo configure en el conmutador; esa comodidad tiene su contrapartida negativa y es que se deja abierta una puerta a nuestra red, puerta que puede aprovechar un atacante para pinchar su equipo a nuestra red si consigue acceso físico al conmutador (cosa no demasiado difícil en algunas organizaciones). Además, los puertos en uso de las redes de tránsito deben protegerse de alguna manera para evitar que máquinas no autorizadas se conecten a ellas. Lo ideal sería desplegar una solución del tipo NAC o 801.1X, pero la mayor parte de las redes actuales carece por ahora de la infraestructura necesaria para algo tan complejo. Al menos, lo que sí se puede hacer es limitar el uso de esos puertos concretos del conmutador a las MACs concretas de los equipos legítimos. No es una solución definitiva porque es muy fácil falsificar la MAC de un equipo, pero al menos servirá para retrasar al atacante y, con suerte, generará algún log de error en el equipo que servirá para alertar a los administradores si estos cuentan con una infraestructura de correlación de logs adecuada (del tipo Cisco Mars, Bitácora, logICA, etc). Por último, habrá que configurar los conmutadores correctamente para evitar que se utilicen contra ellos algunas de las VLAN Hopping existentes para acceder a una VLAN desde un puerto perteneciente a otra diferente.
  • En la capa 1 las medidas de seguridad son evidentes y se corresponden, al fin y al cabo, con las medidas de seguridad habitualmente recomendadas para las instalaciones de comunicaciones y tratamiento de datos. Básicamente se trata de impedir que una persona no autorizada pueda interactuar físicamente con alguno de nuestros conmutadores, por ejemplo pinchando su portátil a una VLAN no autorizada, apagando el conmutador para forzar una redirección del tráfico, o accediendo al puerto de consola del conmutador para reconfigurarlo. Para ello, el equipamiento de comunicaciones debe situarse en armarios cerrados con llave y preferiblemente vigilados con un circuito cerrado de cámaras, en salas de acceso restringido y con un soporte eléctrico y climático controlado y a prueba de fallos.
También está la opción de desplegar infraestructuras especializadas en combatir este tipo de ataques. Tal es el caso de algunas propuestas de código abierto enfocadas a integrar en la red un servidor dedicado a responder a las peticiones ARP a partir de una tabla centralizada con todas las correspondencias IP-MAC de la red, de manera que los conmutadores bloquearían todas las respuestas ARP (incluidas las utilizadas por el atacante para envenenar las tablas de ARP) excepto los originadas desde el puerto de este servidor. El problema de esta opción es la complejidad al no existir herramientas ya desarrolladas que implementen estos mecanismos y depender de las soluciones artesanales que se programe cada uno.

Para seguir el resto de las explicaciones le recomiendo que descargue y experimente con la maqueta de Netkit que he utilizado para escribir este artículo, es similar a la que se usó de ejemplo en los artículos "Creación de laboratorios virtuales con Netkit" I y II (lea estos artículos si no sabe como utlizar una maqueta realizada con Netkit) pero le he añadido una red de gestión, de manera que tenga una puerta trasera para acceder a los equipos por SSH sin mezclarse con el tráfico de la red de pruebas.

En el escenario de ejemplo, Alice quiere navegar por internet a través de un conmutador y un enrutador que le sirve de puerta de enlace; y PC-Sniffer quiere espiar el tráfico que Alice intercambia con Internet.

Teniendo en cuenta lo anterior y a partir de ahora, el esquema de la red de pruebas que vamos a utilizar en este artículo es el siguiente:




En lo que se refiere a las técnicas de detección, la vigilancia de los paquetes intercambiados en la red y de las tablas de ARP de los equipos clave serán nuestras principales armas.

Vigilando el tráfico de red se pueden detectar anomalías que nos alerten del trascurso de un ataque de ARP Spoofing. Examinando con Wireshark capturas del tráfico cursado a través del Switch de la maqueta podemos ver las siguientes anomalías:
  • En la captura del ataque con Ettercap podemos ver (paquetes 1 a 4) como el PC Sniffer (192.168.0.3) pregunta a la red por la MAC del Router (192.168.0.1) y por la de Alice (192.168.0.2). En los paquetes 5 y 6 ya aparecen las primeras señales de alerta; aparentemente el Router y Alice se lanzan pings entre sí, pero si examinamos la MAC de origen de ambos ping podemos ver que ¡en realidad se trata la MAC del PC-Sniffer!. Inmediatamente después, y sin esperar respuesta a los ping, el PC Sniffer manda actualizaciones de ARP para "envenenar" las tablas de Alice y el Router (paquetes 7 y 9). El resultado es que las respuestas a los pings le llegan al PC-Sniffer, lo que le permite saber que su ataque ha tenido éxito. En los paquetes 15 y 16 se puede ver como las respuestas a los pings se reenvían a sus legítimos destinarios, tal y como se hará con el resto del tráfico una vez que el PC-Sniffer lo haya visualizado. A partir de ahí (paquetes 19 a 26) se puede ver como el PC-Sniffer insiste machaconamente en enviar paquetes de actualización ARP para mantener las tablas de Alice y del Router "correctamente envenenadas". Si todo lo anterior ya debería inquietarnos, es cuando Alice comienza a navegar cuando vemos que algo va definitivamente mal. Porque a partir del paquete 43 vemos que todo el tráfico parece duplicado. Esto se debe a que el tráfico tiene que atravesar el Switch una vez, de camino al PC-Sniffer, y otra, de camino a su destinatario, en vez de atravesar el Switch una única vez (que sería lo lógico). De hecho, al mismo Wireshark le parece rara la situación y a partir del paquete 48 comienza a colorear de negro los paquetes repetidos para alertar de que algo no va nada bien.
  • Por su parte, en la captura del ataque realizado con Arppoison (incluido en la carpeta /root/scripts del PC-Sniffer de la maqueta), se pueden observar comportamientos anómalos. Arpoison es una herramienta programada con fines didácticos, así que su funcionamiento es algo más primitivo que el de Ettercap. Para empezar no hace un ping previo para comprobar que el envenenamiento se ha realizado con éxito y luego produce las mismas anomalías en los paquetes intercambiados e incluso alguna más. Y es que, cuando se usa Arpoison, se puede ver como en las capturas realizadas en el Switch aparece paquetes de ICMP Redirect (el primero aparece en el paquete 12), tan raros en las redes modernas que el Wireshark lo colorea de negro para señalarlo como anomalía. Esto se debe a que Arpoison utiliza Scapy para manejar paquetes y este a su vez Libpcap para realizar las escuchas. el problema es que Libpcap saca copias de los paquetes recibidos y se las entrega a las aplicaciones de usuario, pero no impide que los paquetes originales sigan siendo procesados por el kernel del PC. El kernel del PC-Sniffer no sabe nada de las aviesas intenciones de su dueño por lo que reacciona automáticamente cuando recibe un paquete que no está dirigido a su dirección IP enviando un paquete de ICMP Redirect alertando al remitente de que esos paquetes no le corresponden. Esta anomalía es tan evidente que cualquier IDS/IPS, por malo que fuese, lo habría detectado; para evitarla el dueño del PC-Sniffer podría haber activado su cortafuegos local para bloquear con él todos los paquetes ICMP salientes (si su cortafuegos le permite afinar bastaría con bloquear los paquetes ICMP Redirect salientes).

A nivel local, las inconsistencias en las tablas de ARP son síntomas muy serios de un posible ataque. Generalmente, es muy difícil que un PC y el enrutador que hace de puerta de enlace de la red tengan la misma MAC por lo que cuando esto ocurra deberían encenderse nuestras alarmas. Otra anomalía que debería ponernos en alerta es el cambio de la MAC conocida de equipos clave de la red, como por ejemplo los enrutadores que hacen de puerta de enlace.

En estado normal, la tabla de ARP de Alice tiene el siguiente aspecto:

PC-Alice:~# arp -i eth0 -a ? (192.168.0.1) at EA:0E:85:D7:58:04 [ether] on eth0

Si el atacante (PC-Sniffer) iniciase un ataque con Ettercap:

PC-Sniffer:~# ettercap -M arp:remote -T /192.168.0.1/ /192.168.0.2/ ettercap NG-0.7.3 copyright 2001-2004 ALoR & NaGA Listening on eth0... (Ethernet) eth0 -> CA:88:E3:51:83:57 192.168.0.3 255.255.255.0 SSL dissection needs a valid 'redir_command_on' script in the etter.conf file Privileges dropped to UID 65534 GID 65534... 28 plugins 39 protocol dissectors 53 ports monitored 7587 mac vendor fingerprint 1698 tcp OS fingerprint 2183 known services Scanning for merged targets (2 hosts)... * |==================================================>| 100.00 % 2 hosts added to the hosts list... ARP poisoning victims: GROUP 1 : 192.168.0.1 EA:0E:85:D7:58:04 GROUP 2 : 192.168.0.2 BA:4E:E3:B8:96:91 Starting Unified sniffing... Text only Interface activated... Hit 'h' for inline help Sat Mar 14 10:59:44 2009 TCP 192.168.10.1:49581 --> 192.168.0.2:22 | AP ...`..........I.S.4S..o^...D./~.....u.i....K...gaK5J


El resultado sobre la tabla de ARP de Alice sería el siguiente:

PC-Alice:~# arp -i eth0 -a ? (192.168.0.1) at CA:88:E3:51:83:57 [ether] on eth0 ? (192.168.0.3) at CA:88:E3:51:83:57 [ether] on eth0

Como se puede ver, desde el punto de vista de Alice, no sólo ha cambiado la MAC del enrutador (192.168.0.1) sino que además ahora parece coincidir con la MAC de un PC (192.168.0.3), lo que es señal inequívoca de que se está produciendo un ataque de ARP Spoofing que intenta desviar el tráfico de Alice destinado al enrutador hacia un PC intruso. Cuando este PC finaliza Ettercap, este se encarga de restablecer las tablas de ARP a su estado correcto. Lo que deja a Alice de la siguiente manera:

PC-Alice:~# arp -i eth0 -a ? (192.168.0.1) at EA:0E:85:D7:58:04 [ether] on eth0 ? (192.168.0.3) at CA:88:E3:51:83:57 [ether] on eth0

Como se puede ver, el ataque deja huellas tanto durante su transcurso como durante un corto tiempo tras él (hasta la expiración de la entrada en la tabla de ARP). Esto se debe a que el intruso debe interactuar con sus víctimas, antes de iniciar el ataque, para recopilar las MACs de dichos equipos con el fin de reparar las tablas de ARP tras él. Se puede estudiar la estructura interna de un programa similar a Ettercap en el mencionado artículo sobre escuchas en redes conmutadas. En ese programa, el Arpoison mencionado antes, la función que deja la huella "incriminatoria" en las tablas de ARP es la función gatherData(), ejecutada antes del ataque mismo. Como esta función debe preguntar a Alice y al Router por sus MAC mediante una llamada de ARP (representada en el código fuente del artículo por la llamada a la función scapy.getmacbyip() dentro de gatherData()), es el momento en el que el atacante PC-Sniffer "toca" directamente a sus víctimas dejando las huellas mencionadas. Se podría plantear la pregunta de si el atacante podría renunciar a ejecutar esta función para minimizar su huella, pero lo cierto es que no, porque si no averigua las MACs originales de los equipos a espiar no podrá lanzar el ataque ni reconstruir las tablas de ARP tras él.

Visto lo anterior, es evidente que son necesarias herramientas automatizadas que nos permitan defender las tablas de ARP de los equipos críticos que queramos salvaguardar de este tipo de ataques.

Una de las herramientas clásicas a este respecto es Arpwatch. Esta herramienta monitoriza la tabla de ARP y alerta por correo electrónico al administrador cuando se produce el cambio de una correspondencia IP-MAC. Lo ideal es instalar dicha herramienta en todas las estaciones de trabajo Linux de la red. En redes con direccionamiento estático, si se tiene la certeza de que no se ha producido el recambio de la tarjeta de red de ningún ordenador, la llegada de un correo de Arpwatch suele ser alerta inequívoca de que se está produciendo un ataque de ARP Spoofing. En redes con direccionamiento dinámico (DHCP), los pares IP-MAC cambian con cierta frecuencia, por lo que puede ser complicado monitorizar todos los cambios, aunque lo que sí se puede vigilar es el registro IP-MAC de la puerta de enlace por defecto de cada red, la cual debería permanecer inalterable en las tablas de ARP de todas las estaciones de trabajo.

Otra opción, algo más compleja pero con más posibilidades es ArpON. A diferencia de Arpwatch, ArpON no se limita a alertar al administrador sino que reacciona para bloquear el ataque. ArpON tiene dos modos de funcionamiento, estático y dinámico. En modo estático (SARPI), ArpON toma nota al arrancar de las entradas de la tabla de ARP, guardando esta información en una caché alternativa. A partir de ahí, ArpON sólo permite que se tramiten las peticiones y respuestas ARP de pares IP-MAC que no entren en contradicción con la información previa de su caché. El modo dinámico (DARPI) es similar, pero permite que la caché de ArpON vaya incorporando nuevos pares IP-MAC desconocidos en el momento de su arranque.

En redes con DHCP se puede optar también por activar un sistema de DHCP Snooping. Aparte de evitar que aparezcan servidores DHCP "furtivos", este sistema mantiene un registro de las MACs asociadas a las IPs concedidas y los puertos de los conmutadores donde se encuentran estas MACs. Con esta información, el sistema monitoriza los intercambios de ARP que se producen en sus puertos y si detecta un paquete ARP cuyo origen a nivel IP no se corresponde con la MAC registrada lo bloquea para impedir el envenenamiento. Esta opción se encuentra ampliamente disponible, por ejemplo en los equipos de Cisco donde recibe el nombre de Dynamic ARP Inspection.

07 febrero 2009

Las Crypto Guerras


Las Crypto Wars o Crypto Guerras es como se conoce al conflicto desarrollado desde los años 70 entre los gobiernos y los grupos de defensa de las libertades civiles acerca del uso de técnicas criptográficas por los particulares.

Todo comenzó cuando en los años 70 el gobierno americano empezó a darle a la comercialización y exportación del software y de los algoritmos criptográficos un tratamiento equivalente al del armamento. La medida se situaba dentro del contexto del punto más crudo de la Guerra Fría, cuando la Inteligencia de ambos lados del Telón de Acero movilizaba ingentes recursos humanos, económicos y materiales para averiguar lo que sabía el enemigo y, a la vez, evitar que este hiciese lo mismo.

Por tanto, resultaba crucial reforzar la criptografía que protegía la información gubernamental. Pero a la vez, había que asegurarse de que en caso de que se produjese una fuga de información o una conjura interna esta podría ser detectada por los servicios de contrainteligencia por lo que había que evitar la difusión de una criptografía fuerte entre los particulares. Esta dicotomía de intereses es la razón de la profunda implicación de los gobiernos, a través de Agencias y de los departamentos de Defensa, en la investigación y el desarrollo de técnicas criptográficas con el fin de ajustar dichos desarrollos a sus intereses concretos y controlar en lo posible su difusión a los ciudadanos.

Dado que es muy difícil mantener en secreto un algoritmo criptográfico, los gobiernos han optado por tres vías de control:
  • Prohibir el uso de técnicas criptográficas.
  • Limitar la longitud de las claves utilizadas a un valor demasiado difícil de romper por un particular pero vulnerable a los sistemas informáticos gubernamentales.
  • Obligar al uso de sistemas y algoritmos con una puerta trasera (en la literatura anglosajona red thread) accesible por el Gobierno para descifrar el tráfico.
El uso de la primera vía ("prohibir el uso de técnicas criptográficas") apenas se da en la actualidad. Al principio, este control no fue demasiado difícil ya que la informática que se daba fuera del sector militar y universitario era muy escasa. El sector militar siempre ha obedecido órdenes y el universitario recibe importantes subvenciones del militar por lo que en general se ajustó a las restricciones gubernamentales. Los problemas comenzaron a surgir cuando los hogares empezaron a adquirir ordenadores, y más importante: a unirlos a través de Internet. En ese momento empieza a cobrar fuerza la reivindicación de los ciudadanos de asegurar la confidencialidad de sus datos mediante cifrado. Además, esas reivindicaciones no tardaron en ser apoyadas por sectores económicos que veían en Internet un medio para establecer nuevas vías de negocio que debían ser lógicamente protegidas mediante cifrado. Toda esa presión conjunta ha obligado a la mayor parte de los gobiernos a aceptar el uso de técnicas criptográficas por parte de los ciudadanos.

Un ejemplo de la segunda vía ("limitar la longitud de las claves utilizadas") se dió en la definición del algoritmo DES. En los años 70, aún se utilizaban cifradores mecanicos de tipo rotor (meras evoluciones del clásico Enigma alemán). La Agencia de Seguridad Nacional (NSA) estadounidense podía descifrar sin problemas este tipo de tráfico. Sin embargo el sector bancario presionaba para obtener un algoritmo de cifrado moderno que permitiese asegurar sus transmisiones de datos. La NSA temía perder el control que tenía sobre las comunicaciones si se generalizaba el uso de un algoritmo realmente potente por lo que se involucró directamente en el diseño del DES. Hay dos elementos que fueron duramente criticados del DES: por un lado, el fuerte secretismo que había en torno a la cajas-S en las que se basaba el algoritmo, y por otro, la escasa longitud de clave elegida (56 bits). Pronto se extendió el rumor de que la ocultación del diseño de las cajas-S se debía a que la NSA había instalado en ellas puertas traseras y que la longitud de la clave se había elegido corta a adrede para que los sistemas de la NSA pudiesen realizar ataques de fuerza bruta para descifrarlo. Un par de décadas más tarde parece demostrado que ambos rumores eran infundados, las cajas-S no tenían puerta trasera y la NSA carecía en ese momento del equipamiento necesario para tumbar por fuerza bruta un texto cifrado con DES (lo consiguió unos años más tarde). Lo que sí parece que ocurrió es que la NSA difundió intencionadamente ese rumor para extender la creencia de que el DES era inseguro lo que evitó su adopción por parte de gobiernos extranjeros, los cuales que siguieron utilizando máquinas de rotores... a las que la NSA pudo seguir espiando sin problemas.
Cuando el uso de los nuevos algoritmos de cifrado comenzó a generalizarse, el gobierno de los EEUU optó por prohibir la exportación de cualquier producto que incluyese procesos criptográficos que utilizasen claves de longitud superior a los 40 bits, incluyendo además este tipo de exportaciones en la categoría de armamento y materiales peligrosos para la seguridad nacional.

La tercera vía se basa en la premisa de que cualquiera que encripte datos debería darle al gobierno una copia de la clave utilizada para el cifrado, de manera que las agencias de inteligencia gubernamentales puedan descifrar el tráfico si lo consideran necesario. Un ejemplo de este enfoque se dió en 1993 cuando la administración de Bill Clinton propuso un estándar, denominado Clipper Chip, para sustituir al DES. Este estándar se basaba en un chip criptográfico que utilizaba un algoritmo clasificado, y por tanto no sujeto a una revisión pública, denominado Skipjack. Este algoritmo permitía que las agencias gubernamentales pudiesen escuchar las transmisiones cifradas con el chip. La idea del gobierno era incentivar el uso de este chip entre los fabricantes de telefonía y equipos de telecomunicaciones. Sin embargo, la idea no llegó a buen puerto porque el carácter secreto del algoritmo despertó la desconfianza de los fabricantes (que luego se vió justificada al descubrirse varias vulnerabilidades en el estándar) y además la libre circulación por Internet de otras soluciones de cifrado fuerte como PGP, Nautilus y PGPfone dejaba en clara desventaja al Clipper Chip. En 1996 ya era innegable el fracaso de esta iniciativa y de otras similares ante la dificultad de crear la figura de un tercero de confianza que almacenase una copia de las claves de forma segura y que no se prestase a abusos.

Las respuestas a estas iniciativas gubernamentales por parte de los adalides de las libertades civiles han sido variadas. La creación del PGP, en 1991, puso por primera vez la criptografía asimétrica a disposición del gran público convirtiéndose en una herramienta imprescindible para las organizaciones de defensa de los derechos civiles, sobre todo en países no democráticos. Paradójicamente, su creador, Phil Zimmermann, fue procesado por tráfico de armas debido a que el PGP usaba claves de 128 bits, lo que estaba muy por encima del limite de 40 bits que fijaba la ley estadounidense sobre venta de armas, que, como mencionaba antes, integraba la exportación de algoritmos criptográficos. Sin embargo, Zimmermann había sido considerablemente astuto y había exportado PGP de una manera bastante inusual. Había imprimido el código fuente en libros editados por la editorial del MIT y eran estos los que se habían exportado fuera de los Estados Unidos. Los programadores extranjeros sólo habían tenido que arrancar las cubiertas del libro y pasar sus hojas por un escáner OCR, para obtener el código fuente en formato digital y listo para compilarlo con GCC. Finalmente, los juzgados tuvieron que dejar en libertad a Zimmermann, libre de cargos, ya que aunque la exportación de software criptográfico estaba regulada por ley, la exportación de libros está sin embargo protegida por la Primera Enmienda, de rango constitucional (y por tanto superior), que defiende la libertad de expresión y de prensa.

Tras el caso Zimmermann se hizo evidente que no se podían poner puertas al campo y se relajaron los controles, de tal manera que ya sólo está prohibida la exportación de software criptográfico a los países de la lista negra de los Estados Unidos (Irán, Corea del Norte, etc).

El problema del terrorismo internacional ha devuelto a la vida el debate acerca de la necesidad de monitorizar el tráfico de voz y datos con el fin de cazar a los terroristas. El hecho de que gran parte de las infraestructuras de comunicaciones actuales se construyeran durante la vorágine de las puntocom es la causa de que estas no se diseñasen con criptografía integrada, lo que las hubiera encarecido considerablemente y alargado sus plazos de despliegue. Esta carencia de criptografía integrada en las redes de comunicaciones facilita la labor inspectora de las agencias gubernamentales.

Pero hoy en día está claro que el mercado tiende cada vez más hacia las transacciones electrónicas, y estas deben ser protegidas mediante cifrado, razón por la que el conjunto de la industria tiende a dotar (ahora sí) a sus nuevos sistemas de sistemas de cifrado integrado (por ejemplo: Skype).

Ante esta situación, y dado que el dinero manda, resulta cada vez más evidente que este se inclina por el lado del libre uso de la criptografía, lo que supone la victoria en las Crypto Guerras de los defensores de los derechos civiles.

01 febrero 2009

El poder de Google


Ayer descubrí que Google calificaba mi blog como fuente de malware. Eso significa que cada vez que alguien hacía una búsqueda en Google y danteslab estaba entre los resultados, aparecía un aviso de que este blog contenía software dañino que podía dañar el PC del visitante.

Parece ser que Google se asoció hace ya tiempo con Stopbadware.org para analizar webs en búsqueda de scripts ocultos que pudieran atentar contra los navegadores de los visitantes. A grandes rasgos, cuando los spiders de Google analizan una web parsean el contenido de esa web contra las firmas de Stopbadware y si se da un positivo se marca esa web como dañina. A partir de ahí, el administrador de la web marcada debe buscar en su código HTML el script malicioso y eliminarlo. Hecho esto debe dirigirse a la página de Herramientas para Webmasters de Google para solicitar que se reconsidere la calificación de su web como dañina.

En mi caso, por la web de las herramientas para webmasters de Google pude averiguar que la calificación de dañino para danteslab se puso el día 26 de Enero. Danteslab se basa en una plantilla de Blogger y el único contenido que puede insertar el usuario son sus comentarios a los artículos, así que las posibilidades de inyección de código son muy limitadas y, de darse, afectarían a la práctica totalidad de los blogs alojados en Blogger. Lo único que se salía del estándar eran los botones para publicar en Menéame, Digg, etc que había encontrado buscando en Google, pero el código era tan sencillo que era imposible que ocultase algo maligno. Así que convencido de que todo había sido un error, un falso positivo, solicité una revisión de la calificación y finalmente me retiraron la advertencia.

Todo el asunto me hizo reflexionar. Era indudable que había perdido visitantes durante la semana que había durado la advertencia y que no volverían ante el temor de dañar sus PCs. No es que me importase, este blog es un proyecto personal, meramente intelectual, en ningún momento me plantee seriamente que tuviera algún beneficio económico. Pero ¿qué le habría pasado a una web que sí dependiese de sus ingresos?. Seguramente el impacto habría sido realmente importante tanto para su reputación como para su balance económico.

Ese es el poder de Google. Actualmente es la puerta de entrada principal de los usuarios a Internet. Ya no es sólo que la gente use Google para conocer las páginas que necesitan sino que hay muchos que usan Google para acceder a páginas ya conocidas. Es el caso de muchos que no memorizan las urls para acceder a páginas sino los términos que hay que poner en Google para que la página aparezca en los resultados de la búsqueda. Por tanto, si Google decide condenar al ostracismo a una página web apartándola de los resultados de sus búsquedas (o peor, acusándola de contener malware) es muy posible que esa web no se recupere nunca.

Muchos dirán, ¿y por qué iba Google a hacer algo así?. Pues por los intereses que tienen todas las empresas que cotizan en Bolsa. No voy a ser tan presuntuoso como para pensar que Google quiso tomar represalias contra mi por haber hablado de su papel en el Escudo Dorado chino (aunque se haya dado la casualidad de que mi blog fuese calificado de malware justo un día después de publicar ese artículo), pero ¿y si mi blog hubiese tenido la suficiente popularidad como para ser una amenaza para los intereses de Google?. Resulta inquietante saber que Google tiene una herramienta tan poderosa como su buscador para silenciar cualquier tipo de crítica contra ella. Creo que empieza a ser el momento de que surja una alternativa real a Google... por el bien de la independencia y democracia que representa Internet.

25 enero 2009

El Escudo Dorado


El Escudo Dorado (the Golden Shield), también conocido como el Gran Cortafuegos de China (the Great Firewall of China), es un gigantesco sistema informático dedicado a la represión y a la censura de todo lo que entra o sale de China a través de Internet.

A finales de los 90, Internet suponía una nueva amenaza para la tiranía comunista china. La gerontocracia china era consciente de que Internet era un medio que escapaba a su control y que permitiría a los chinos acceder a contenidos sin censurar, exponer sus opiniones, organizarse y denunciar los abusos comunistas... en resumen: Internet era, para un país con 137 millones de internautas, una auténtica vía de entrada de la Democracia. Por supuesto, los jerarcas comunistas no estaban dispuestos a arriesgar su poder por lo que decidieron construir un sistema, el Escudo Dorado, capaz de controlar todos los contenidos que se intercambiasen a través de Internet desde China.

Como tantas cosas en ese país, el resultado fue colosal. Su construcción se inició en 1998 y en él se invirtieron 800 millones de dólares. Comenzó a estar operativo en 2003 y no ha sido hasta el 2008 que se han dado por finalizados todos los objetivos del diseño original. Se calcula que al menos 30.000 técnicos, funcionarios y policías se ocupan de su funcionamiento.

El Escudo Dorado se basa en una arquitectura multicapa en la que se van filtrando progresivamente los intercambios a través de Internet.

La primera capa tiene sus sistemas situados en la región de Shenzhen, cerca de Hong Kong, y es donde se centraliza el tráfico de entrada y salida de Internet. Esta capa se encarga de filtrar en función de las direcciones IP involucradas, denegando la conexión en caso de que alguno de los extremos esté incluido en una gigantesca lista negra de direcciones IP "subversivas" (entre las que se encuentran la BBC o la Voz de América). EL DNS poisoning es otra de las herramientas que se utilizan en este nivel para entorpecer el libre acceso a páginas de contenidos no autorizados. Además de lo anterior, se inspeccionan todos los paquetes de datos intercambiados para comprobar si contienen palabras "prohibidas" como Falung Gong (organización opositora) o Taiwan (nación no reconocida por China). En caso de que aparezcan este tipo de palabras, el Escudo Dorado manda un paquete de TCP reset a ambos extremos para finalizar la conexión.

El segundo nivel del Escudo Dorado se dedica a la inspección a nivel de aplicación, denegando una lista determinada de servicios. Que el servicio de una empresa esté o no en la lista negra depende en muchos casos de su docilidad con el ŕegimen. En el caso de Google, estos tuvieron que crear un índice especial para China formado por spiders con base en el país, de manera que sólo se indexase lo que permitiese el Escudo Dorado. La transigencia con este régimen de compañías como Cisco o Google, con sedes en países democráticos, sólo se explica por el jugoso mercado que supone una China con miles de millones de potenciales consumidores.

El tercer nivel es social. Miles de censores se sientan delante de ordenadores situados en plantas industriales para examinar manualmente el correo electrónico interceptado por el Escudo Dorado, así como para evaluar la conveniencia política de los artículos de las webs chinas. Hasta se han creado dos mascotas, Chacha y Jingjing, cuyo fin es aparecer regularmente en las páginas intervenidas por el Escudo Dorado para intimidar a los usuarios recordándoles que la policía política vigila Internet.

Paradójicamente, es relativamente fácil escabullirse del sistema aunque se requiere una poderosa razón para hacerlo ya que un único fallo puede atraer la atención de la temida policía política.

El cifrado puede ocultar la naturaleza de la información intercambiada aunque, en teoría, puede atraer atención (la policía pensará "si cifra tráfico es que hay algo que quiere ocultar"). Sin embargo, en la práctica, la represión generalizada del tráfico cifrado no resulta factible al ser uno de los pilares del comercio electrónico crucial para el crecimiento económico de China. Por eso, la combinación de técnicas de cifrado con otras de anonimización que eviten las listas negras de direcciones de IP deberían ser suficientes para superar las tres barreras del Escudo Dorado.

El uso de proxies puede evitar el filtrado por IP destino, y si además se combina con cifrado HTTPS se anula el filtrado por palabras prohibidas. Este es el enfoque de herramientas como UltraSurf o Freegate que utilizan una lista variable de proxies abiertos en Internet para anonimizar el destino de las conexiones de sus usuarios y ocultando el contenido de dichas conexiones mediante cifrado.

Otra opción es el llamado Onion Routing, cuyo más célebre exponente es la herramienta Tor, el cual permite tunelar de manera cifrada el tráfico a través de una lista variable de servidores intermedios. La ventaja de Tor frente a otras opciones es que, bien configurado, puede anonimizar no sólo la dirección IP de destino del tráfico sino también la dirección IP de origen. En un futuro artículo explicaré con detalle el funcionamiento de esta poderosa herramienta.

El cifrado mediante SSH o VPN-IPSec es otra opción a la hora de blindar el tráfico frente a inspecciones indeseadas, aunque en este caso habría que buscar una manera de anonimizar la IP de origen y la de destino para evitar engrosar a la larga la lista negra del primer nivel del Escudo.

Y todo ello sin tener en cuenta otras técnicas, como el uso de canales encubiertos mediante esteganografía. Y es que el Escudo Dorado es incapaz de detectar mensajes escondidos en imágenes o sonidos, tarea que requeriría unos recursos computacionales y humanos imposibles de aplicar al tráfico generado por 137 millones de personas.

Todo ello demuestra que a la hora de la verdad el Escudo Dorado ha sido más bien una medida propagandística desesperada que ha intentado "poner puertas al campo" y que quizás marque el comienzo del fin de un régimen tiránico y genocida.

24 enero 2009

Security Engineering


El Security Engineering de Ross Anderson es con toda probabilidad el mejor libro sobre seguridad que he leido hasta la fecha.

A diferencia de otras obras que adoptan un punto de vista meramente tecnológico, Anderson prefiere centrarse en el plano conceptual estableciendo los distintos principios que deben guiar a un ingeniero de seguridad en las diferentes disciplinas de su actividad. Por eso no habla de ninguna marca específica de cortafuegos ni de ningún lenguaje de programación o sistema operativo concreto, sino de los errores y aciertos de diseño que se han dado a lo largo de la historia de las tecnologías de la información y las comunicaciones. Esto resulta tremendamente enriquecedor ya que la publicidad de los fabricantes de herramientas de seguridad mantiene vivo el mito de que basta con invertir ingentes cantidades de dinero en la última tecnología para asegurar de manera efectiva los activos. Sin embargo Anderson insiste en que la tecnología es una mera herramienta al servicio de un análisis y planificación adecuados, frutos de una mentalidad basada en principios globales e independientes del estado del arte tecnológico del momento.

A lo largo de la obra se analizan estos principios, aplicados a las distintas áreas de la seguridad y se van contrastando con casos históricos. Así, se cubren temas tan dispares e interesantes como la psicología, la usabilidad, la criptografía, las políticas de control de acceso a la información, el impacto de los factores económicos en la seguridad, los controles de integridad, la seguridad en entornos multilaterales (aquellos en los que se comparten activos con otras organizaciones), la propiedad intelectual o el terrorismo, entre un largo etcetera.

La larga experiencia del autor ilustra el libro de interesantísimos ejemplos y aportes históricos tanto del mundo de la banca, como del militar y del espionaje (que son, al fin y al cabo los grandes impulsores históricos del mundo de la seguridad). Entre estos ejemplos se describen desde la evolución de los sistemas IFF (Identify-Friend-or-Foe), a las organizaciones de las redes de mando y control militar; desde los sistemas de control del armado de los misiles nucleares a lo largo de la historia, hasta los avances en las investigaciones para espiar aparatos electrónicos en función de sus emisiones electromagnéticas.

Además, la vida útil del libro es muy larga, dada la vigencia a través del tiempo de las materias que trata, por lo que no es de esos libros de seguridad que a los dos años se han quedado tan antiguos que acaban en la papelera.

Todo ello hace de Security Engineering un libro imprescindible para cualquier ingeniero de seguridad y una inversión que realmente merece hasta el último céntimo de lo que vale.