En el post anterior nos planteamos el ejercicio teórico del coste y viabilidad de escanear todas las direcciones IP de Internet y una vez calculado vimos que el coste de hacerlo era muy bajo. Por tanto, decidimos llevar a cabo un pequeño experimento: comprobar si era posible escanear toda Internet, por supuesto sin realizar ninguna acción dañina para nadie en la red.

Si bien la acción puede no ser totalmente inocua (algún IDS puede haberse quejado), hemos tratado de hacer el experimento lo menos dañino o problemático posible. En este sentido, lo más inocuo que se nos ha ocurrido es lanzar un ping (ICMP echo) a todas y cada una de las direcciones de Internet. Aunque sólo hemos enviado un único paquete por IP, hemos desordenado los escaneos para evitar que una red recibiera un alto número de paquetes consecutivos.

Para ello preparamos los dos hilos de ejecución, en cuyo trabajo he contado con la inestimable ayuda de Nacho López, un experimentado programador de C. En cualquier caso las mismas fuentes del ping podrían haber sido una buena fuente de inspiración:

Envia_echo-icmp ()
Recibe_echo_icmp ()

El proceso funciona de manera stateless: uno envía de manera ciega, y el otro simplemente va anotando los paquetes respuesta que le llegan, por lo que no se consume ninguna cantidad de memoria por cada conexión.

La mayor complejidad ha venido por el coste de recursos de almacenar en disco, debido a que era necesario ajustar bien y programar teniendo en cuenta el rendimiento de disco, de manera que cuando llegasen los resultados no perdiésemos paquetes. Tras 10 horas, obtuvimos los siguientes resultados:

Resultado de global de ping contestados: 284.401.158 direcciones IP han contestado al ping, es decir un 7% de equipos. Gráficamente:

Si lo separamos por redes /8 vemos los siguientes porcentajes:

Gráficamente:

Hay que tener en cuenta que hemos escaneado todo el espacio de direccionamiento sin eliminar direccionamiento privado ni redes reservadas. Obviamente vemos que las direcciones reservadas no contestan, lo que encaja con lo que dice IANA sobre las redes reservadas.

También hemos agrupado el numero de pong que nos han contestado las redes /24 (clase C), con lo que podemos ver el nivel de densidad de direcciones IP de estas redes. Por ejemplo, ¿cuántas clases C han contestado 20 pongs?

Gráficamente:

Vemos que muchas redes no contestan nada, principalmente porque son redes reservadas, y vemos que hay bloques en los que contestan muchas.

También hemos realizado el análisis sobre el byte de menos peso de la dirección IP, teniendo en cuenta que hemos tratado las direcciones como si fuesen todas “normales”. Se ve claramente que tanto las acabadas en .0 como las acabadas en .255 contestan mucho menos al ping. Por otro lado también podemos observar que la IP acabada en .1 es la que mas contesta al ping, debido a que normalmente es la utilizada para el router, y a partir de ahí suele filtrarse el tráfico. Esto se puede ver claramente en el X% respecto a la media habitual. También se perciben una franjas que nos muestran las subredes /25, /26, /27, etc…

Gráficamente:

Obviamente del hecho de que contesten más o menos direcciones no es posible extraer conclusiones sobre la densidad de población IP, ya que pueden estár filtrados convenientemente.

El % de IPs que contestan al ping parece razonable, teniendo en cuenta que es lógico que para ayudar a la resolución de incidencias los equipamientos externos contesten a este protocolo. También es lógico que muchos otros no contesten, pero en todo caso no parece que el espacio IPv4 este tan saturado como anuncian.

Este experimento es una prueba de concepto de lo sencillo que es realizar una acción global contra toda Internet, con coste casi despreciable, tiempo corto y conocimientos básicos.

Podemos ver cómo sería posible escanear un puerto TCP, o incluso hacer algún ataque de intrusión de manera global (siempre que sea stateless), para lo cual cualquier ataque UDP puede ser muy efectivo (como ya pasó con slammer). En todo caso estas acciones sí que son y serian consideradas como ataques, por lo que como es de esperar no vamos a ir más allá ni evolucionar este proyecto.

Queda claro y demostrado que IPv4 realmente es muy pequeño, un argumento más para responder a la pregunta: ¿Por qué me van a atacar? Con IPv6, el vector de ataque será de muchos órdenes de magnitud superior, impidiendo este tipo de escaneos tan de fuerza “bruta”.

Como curiosidad, no tuvimos respuesta de ningún contraataque, ni recibimos actividad hostil en respuesta, pero sí que estuvimos recibiendo tráfico de un servidor que nos estuvo enviando durante horas el pong de manera continua y repetida (paquetes DUP!), pensamos que debido a un error de IP que no hemos podido determinar.

Aunque el experimento ha sido lo más inocuo e inofensivo que se nos ha ocurrido, durante el experimento han llegado algunas quejas de organizaciones quejándose del escaneo. No obstante, tratándose de un “ataque” de escala mundial, las quejas han sido pocas y el proveedor de hosting receptor de los pings actuó en todo caso comunicando la queja tiempo después de haber finalizado el experimento, lo que pone de manifiesto que algo así no da tiempo a pararlo o analizarlo.

Con los datos extraídos se pueden realizar más análisis interesantes que dejamos para posteriores entradas, como por ejemplo el tema de las direcciones de red y broadcast. Espero que les haya gustado el experimento y en todo caso disculpas si les ha molestado que les hagamos un ping.

(Puedes comprobar el resultado de este experimento en la segunda parte de este post: Resultado de un ping lanzado a todas las direcciones de Internet)

Internet, la red de redes; todas las organizaciones modernas del mundo están conectadas a Internet. Un gran número de individuos disponemos de conexión a Internet, en el trabajo, en el domicilio particular y en el dispositivo móvil.

Esto nos puede hacer pensar que estamos hablando de un vasto rango de direcciones, dentro de las cuales los atacantes pueden centrar sus ataques en una organización determinada. Por ahora tomaremos como toda Internet el espacio de direcciones de IPv4. Cuando se despliegue y esté en uso IPv6, está claro que todo esto cambiara y habrá un nivel añadido de complejidad.

Pero, ¿y si quisiéramos realizar una acción contra todas y cada una de las direcciones de Internet? ¿Sería viable? ¿Cuánto nos costaría? ¿Recursos técnicos? ¿Recursos físicos? ¿Tiempo? ¿Dinero?
Todas estas cuestiones nos las podemos plantear de manera teórica y quizás después hacer un pequeño experimento. Para empezar con el ejercicio teórico, vamos a suponer el siguiente escenario:

• Queremos hacerle un ping (ICMP ECHO) a todas y cada una de las direcciones de Internet.
• Queremos almacenar el resultado de si han contestado al ping o no (vamos si han hecho pong).

Veamos algunos cálculos:

¿Cuántas direcciones IP hay?

256^4= 4.294.967.296, en números redondos 4 mil millones de direcciones.

¿Cuánto ancho de banda consume un ping?

• En nuestro caso como vamos a considerar 58 bytes por ping.
• Veamos el ancho de banda que consumiríamos en hacerle un ping a toda Internet: 256^4 * 58 bytes = 232 GB.

Si queremos almacenar en disco la respuesta con solo un bit por dirección nos ocuparía 512 MB. Si por comodidad de proceso guardamos un byte por cada respuesta tenemos 4GB.

Si consideramos un ancho de banda de 50 Mbits/sec tenemos que en 10 horas podemos tener el escaneo realizado.

Conocimientos técnicos necesarios: Necesitamos hacer un programa que envíe de manera continua y ciega los paquetes, y otro proceso recibirá las respuestas de manera stateless (existe software similar para escaneos TCP llamado scanrand).

Capacidad técnica: Cualquier informático con conocimiento de sockets en C, mirando el ping.c podría realizar este programa.

Potencia necesaria: Con un PC normalito es más que suficiente; en nuestros experimentos hemos podido hacerlo sin problemas con un Dual-Core 2.66Ghz 4GB de RAM y una conexión de 100Mbits a Internet.

Coste del equipo y la conexión: Pues en algún conocido hoster puede costar 30 EUR al mes. En porcentaje de uso del servidor podríamos decir que 0,42 EUR de presupuesto.

Así pues, cualquier persona con conocimientos programación en C con 30 Euros puede realizar una acción masiva y global a todas las direcciones de Internet en menos de 10 horas. Una muestra más que simplemente por estar conectado a Internet es posible recibir un ataque. En la historia de Internet han existido múltiples gusanos que han atacado de manera indiscriminada todas las direcciones de Internet, y las redes de hoy en día y la potencia de los equipos hacen que las incidencias locales se conviertan en globales en pocos minutos. Un famoso ejemplo de esto fue el gusano SQL Slammer que consiguió en poco menos de 10 minutos colapsar Internet, aprovechándose de una vulnerabilidad atacada con un solo paquete UDP de 376 bytes.

Así pues, ha quedado claro que Internet es un lugar muy, muy pequeño, y hay que estar bien protegido, ya que con tan solo estar conectado a Internet te conviertes en (al menos) un objetivo indirecto de ataques globales y automatizados. Y no estar en Internet ya no es una opción.

En el siguiente post veremos el resultado de llevar a la práctica este ejercicio teórico. Para ello, nos decidimos a realizar un simple y benigno ping, contra todas las direcciones IP de Internet. Aunque es cierto que un ping puede ser el primer paso para un ataque más sofisticado posterior, no es esta (evidentemente) la intención de este experimento. Además, el realizar un ping nos puede mostrar además el nivel de filtrado o en nivel poblacional de los rangos IP de Internet lo cual puede tener un cierto interés académico.

No se pierdan el siguiente post en el que pasaremos a describir los resultados del experimento. ¿Qué problemas técnicos nos habremos encontrado? ¿Cuántas habrán hecho un pong? ¿Cuántas quejas habremos recibido? ¿Algún contraataque? ¿Qué redes contestan más?

Cualquiera que viva en el mundo de hoy en día es consciente de que vivimos rodeados de un gran número de números de serie. Éstos posibilitan identificar de manera única un software, dispositivo o elemento, y si esto va asociado a una persona, permite monitorizar, controlar y registrar lo que hace esa persona si estos números pueden ser accedidos. Nótese que a diferencia de los patrones de fingerprinting, estos números no son nada accidental, sino que han sido diseñados para ser únicos.

Tras esta breve introducción, me gustaría repasar algunos de los números de serie que llevamos encima y por los cuales se nos puede identificar y de los que quizás no seamos totalmente conscientes.

Empecemos por cosas que llevamos encima:

[Read more…]

En esta entrada me gustaría repasar algunas técnicas de fingerprinting aplicadas a la privacidad/seguridad informática, teniendo en cuenta que la idea es la misma que en la clásica huella dactilar: aunque todas son parecidas, no hay dos iguales, y se puede identificar individuos concretos analizándolas. Además de las huellas dactilares hay muchos otros casos de elementos de serie o estandar, pero que acaban siendo diferentes e identificativos, como una bala que identifica el arma que la disparo, la rueda de un coche, etc.

En estos ejemplos estamos viendo que son elementos que dejan “huella”, y por lo tanto suponen un riesgo importante para la privacidad (el riesgo se convierte en ventaja para las fuerzas de seguridad del Estado). Estas mismas técnicas llevadas a las redes informáticas nos permiten hacer cosas similares e identificar tipos de sistemas de manera única. Por nombrar tipos clásicos diferentes de herramientas, me gustaría reseñar una de cada tipo:

• Nmap active fingerprinting Fue la primera herramienta que conocí de este tipo: dada una dirección IP, le lanza una serie de paquetes y según las respuestas es capaz de saber que sistema operativo hay al otro lado.
• Passive fingerprinting p0f Esta herramienta obtiene algo parecido a la anterior pero con la gracia de que no necesita enviarle nada, sino que simplemente ve pasar el trafico y con eso ya tiene bastante.

Los dos casos anteriores son clásicos y conocidos, y en el fondo sólo detectan un sistema operativo, pero este proyecto que cito a continuación es bastante mas inquietante:

• No hay dos navegadores iguales, PANOPTICLICK Este proyecto de la EFF nos muestra como cada navegador es diferente de otro, por la diferencia de plugins, fuentes, configuración, de manera que se puede sacar una “huella” diferente de cada uno e identificarlo de manera unívoca. Es sorprendente cómo funciona incluso en equipos de la misma organización, que en teoría deberían de ser iguales. En todos mis equipos en los que he probado el proyecto, nunca me ha salido repetido, por lo que para ese servidor soy “unicamente” identificable.

La base matemática de cualquier fingerprinting es bastante sencilla; sólo tiene que tener un número de parámetros variables de entrada, y una respuesta. Con eso, simplemente se rellena la tabla, si es capaz de identificar lo que se quiere con las entradas, tenemos la respuesta, si aparece un nuevo patrón, se da de alta. Dicho esto, si combinamos las nuevas tecnologías con las huellas físicas o comportamientos físicos/humanos, da lugar a interesantes e inquietantes nuevas posibilidades. Por ejemplo:

¿Puede identificarse un individuo por la manera en la que teclea? ¿Cadencia de tecleo, letras que teclea más rápido, etc.? Si se escanea una firma, ¿puede identificarse o diferenciarse no por el trazado final, sino por la fuerza, velocidad de los trazos? Seguro que más de una vez han reconocido a una persona desde lejos solo por la manera de caminar; ¿puede automatizarse este rasgo y combinado con otros rasgos identificar individuos? En este caso, la huella que dejaríamos que nos identificaría, no es física, sino virtual, ya que la podrían recoger cámaras, sensores, etc.

Adicionalmente, se pueden realizar técnicas de fingerprinting de manera activa, es decir interaccionando con el individuo u objeto que se quiera perfilar, o de manera pasiva simplemente “viendo” pasar al individuo o sus dispositivos, sin que tenga éste que hacer nada especial, y por supuesto, sin su consentimiento.

Sin duda nuevas posibilidades, cada una de ella con sus ventajas e inconvenientes que los individuos y las organizaciones tendremos que gestionar.

La respuesta habitual de muchos responsables de informática (de informática sí, pero no demasiado responsables) frente a la seguridad es que no tienen que preocuparse en exceso ya que según ellos, su organización no es objetivo de ataque de nadie y por lo tanto se sienten tranquilos respecto a la seguridad de sus servidores.

Obviamente, si eres un banco está claro que eres un objetivo de ataque, ya que albergas dinero, y si alguien consigue realizar una intrusión, obtiene un beneficio económico directo. Si eres un comercio online, a través de éste se puede llegar a disponer de datos de tarjetas bancarias, lo cual también se traslada en dinero. Este tipo de organizaciones ya tienen en su cabeza que son objetivo directo de ataque, y normalmente están al tanto de la seguridad de sus servidores expuestos a Internet.

Pero, si no soy ninguna de estas cosas, porque me dedico a la fabricación artesana de tornillos, ¿soy objetivo de ataque? Pues sí. Usted puede tener enemigos, empleados o ex-empleados disgustados, la competencia (poco ética), proveedores, o clientes que por alguna razón estén disgustados y tengan un particular sentido de la justicia. Pero en fin, usted puede pensar que no estamos en ninguno de estos casos; no tiene empleados o desempleados descontentos, sus clientes y proveedores (y todos sus empleados) le tienen en alta estima, su competencia juega limpio, y además, se lleva usted bien con todo el mundo.

Entonces, ¿por qué me van a atacar a mi, si no le importamos a nadie y nadie nos tiene manía? ¿Quién puede querer perjudicar a mi organización, que no ha roto un plato?

Pues mucha gente; es lo que tiene Internet. Pero, de nuevo: ¿por qué? Pues dejando aparte que su organización muy probablemente maneja dinero, es muy sencillo. Sus servidores disponen de potencia de calculo, almacenamiento, conexión a Internet, y reciben visitas de clientes o usuarios, recursos todos ellos sumamente interesantes para los atacantes; en su mayor parte, quizá no se enfrente a ataques en los que su organización sea el objetivo final, pero sí será víctima de ataques cuyo objetivo es un pez más grande. Pongamos algunos ejemplos de intrusiones, o explotación de vulnerabilidades habituales en Internet:

• Servidor de correo: Si su servidor de correo está (incorrectamente) configurado para permitir el reenvío de correos de terceros sin autorización, será cuestión de minutos que algún spammer le utilice para desde tu servidor se envíen correos no deseados a medio mundo. Quizá no lo considere un ataque, cuando se vea incluido en listas negras de servidores de correo y los servidores de sus clientes y proveedores le devuelvan los correos, verá que la cosa no tiene demasiada gracia. Sin mencionar la posibilidad de que su servidor de correo sea saturado o le provoquen un DoS.
• Uso del ancho de banda: Aunque puede no considerarlo un ataque en el sentido más estricto del término (usted no es el atacado), pueden utilizar sus servidores para provocar una denegación de servicio a un tercero, lo que evidentemente influirá en su conectividad y por ejemplo, la disponibilidad de los servicios que ofrece a través de esa línea de Internet.
• Uso de sus visitas licitas y reputación para redirigir a sus clientes a páginas maliciosas, con virus y troyanos; existen virus y gusanos cuyo ataque se basa en ese propósito. Asimismo, un problema de Cross Site Scripting, de poca relevancia técnica para sus sistemas, puede tener como objetivo incrustar una página web remota con virus y troyanos en su frontal web, con lo que todos los visitantes de éste no suficientemente protegidos serán infectados con el malware. Imagine las consecuencias reputacionales.
• Uso de un servidor para albergar una pagina de phising, de modo que un servidor de su organización albergue una copia de la página del banco XYZ.
• Uso de la CPU de los ordenadores y servidores locales para romper contraseñas por fuerza bruta.
• Uso de los servidores para colocar Bots de IRC, con el objetivo de poder llevar a cabo comunicaciones de manera anónima y secreta. Es habitual encontrarse este tipo de artefactos, y en mi vida profesional el mayor numero de intrusiones ha sido con este cometido.
• Uso de los servidores para albergar contenidos ilegales, con los posibles problemas que pueden implicar: desde programas pirata, películas, o música, hasta mucho cosas peores.
• Uso de tu servidor como anonimizador de otros ataques, con lo que los atacantes evitan que se localice su IP origen. Esto le puede meter en un lío legal de cuidado. Además de ello es habitual que una vez atacado el site remoto que era el objetivo final, para evitar dejar rastros formateen completamente el servidor intermedio.
• Robo de publicidad: Si su organización dispone de banners publicitarios, un ataque reciente se dedica a cambiar la cuenta de publicidad “oficial” por la del atacante para conseguir llevarse los ingresos.
• Conseguir enlaces o referencias a otro site (esto es otra especie de spam: webspam) para posicionarse bien en los buscadores (SEO). Este tipo de enlaces hay incluso quien los vende.
• Uso combinado de un sniffer para obtener cuentas de usuarios de su organización: cuentas ftp, cuentas de shell y cuentas de correo electrónico, capturadas y utilizadas por numerosos robots y malware, sin ser en absoluto ataques dirigidos contra su organización, pero de los que es víctima.

Esta lista de posibles ataques es sólo una pequeña muestra de lo que he visto en alguna ocasión, pero no le quepa duda de que los atacantes tienen otras muchas “ideas” para utilizar sus servidores, sin que se trate un ataque dirigido en especifico a su organización. Así pues, tenga usted cuidado ya que cualquier servidor de Internet es objetivo de ataque; hay muchas razones para que le ataquen, y muy probablemente en estos momentos le estén atacando. Sea prudente y no infravalore a los criminales.

Siguiendo con la entrada sobre la inseguridad de sentirse seguro, me gustaría ahora describirles 3 tecnologías de uso habitual que dan una falsa sensación de seguridad:

– Antivirus: Siempre que le explico a algún no especialista que es un antivirus, le explico que no es un “antivirus”. Es muy sencillo; un antivirus es la forma abreviada (o comercial) de decir que es un antivirus de virus conocidos. Sí, existen módulos heurísticos y otras historias de ciencia ficción, pero la realidad es que los virus nuevos no son detectados por los antivirus hasta que son conocidos. Esto implica que si tenemos la mala suerte de toparnos con un virus de relativa novedad no conocido por nuestro antivirus, éste será de poca utilidad. Obviamente, aunque el antivirus que utilizamos lo reconozca, si el nuestro no se encuentra actualizado, la consecuencia es la misma, de ahí la importancia de actualizar las firmas del AV.

– IDS de red: Los IDS tienen el mismo problema que los antivirus: son “IDSs de patrones conocidos”, pero son mucho peores que los AV ya que por lo general no toman medidas inmediatas, sino que se limitan a registrar e informar. Además, existen numerosas ocasiones en las que están “ciegos”, como por ejemplo en el tráfico cifrado en el que funcionan todas nuestras web corporativas importantes. Además únicamente registran intrusos en base a patrones “técnicos”, pero no a nivel de “negocio”, de modo que alguien puede estar haciendo transferencias bancarias de forma masiva, y el IDS sólo vera un usuario utilizando la aplicación de transferencias.

– Los auditores de vulnerabilidades (Nessus / OpenVAS / etc): Volvemos a lo mismo. No podemos estar tranquilos con haber pasado un scanner de vulnerabilidades y ver que todo queda corregido, dado que éstos únicamente lo son de vulnerabilidades conocidas y en su gran mayoría de software conocido, por lo que todos los desarrollos adhoc pueden ser completamente vulnerables a ataques de todo tipo y pasar inadvertidos. Es cierto que en este campo las herramientas están evolucionando y cada vez son mas capaces de analizar desarrollos desconocidos, pero cualquier auditoria automática de este tipo debería incluir un disclaimer en el que se indique que la herramienta sólo comprueba vulnerabilidades en versiones y configuraciones de programas conocidos, por lo que no incluye la detección de problemas en desarrollos propios, programas no conocidos o partes no públicas que pueden ser facilmente explotables por usuarios maliciosos. De aquí la necesidad e importancia de que una auditoría de este tipo sea complementada con auditorías manuales, tanto de los desarrollos a nivel de código, como a nivel de interacción con el usuario final.

Dicho esto, ¿cómo actuar en estos casos? El planteamiento es muy sencillo: se debe trabajar con el supuesto de que las herramientas no existen:

– Antivirus: Debemos actuar como si no se dispusiera de antivirus. En un entorno de oficina, por ejemplo, no ejecutar programas de los que no se conozca el origen, limitar la ejecución de binarios y código externo, eliminar los ejecutables que llegan por correo electrónico, restringir la descarga de ejecutables a través del proxy web, y deshabilitar el acceso a programas en unidades CD/USB.

– Detección de intrusos de red: Al IDS de red le pasan desapercibidas muchas cosas, y potencialmente puede generar un gran número de falsos positivos. No obstante, si conoce su negocio y sus aplicaciones seguro que sabe dónde mirar para detectar cosas extrañas; trate de añadir IDS de host, o integrados dentro de la lógica del negocio, ya que serán mucho más efectivos. Y por supuesto no los utilice como excusa para no tener en perfecto estado de revista la seguridad de sus servidores.

– Auditorías de vulnerabilidades: Como se ha comentado, no es suficiente con los análisis que se limitan a los datos de la caja negra. Debemos revisar de manera no exclusivamente automática las actualizaciones de versiones de los programas, su funcionamiento cuando interactúan con el usuario, la configuración de las aplicaciones con respecto a la seguridad (usando guías de buenas practicas, o mediante el análisis de todas sus funcionalidades), y por supuesto controlar el desarrollo desde su orígenes, incluyendo la seguridad en todo el ciclo. La idea es que el hecho de que la herramienta de auditoría que utilizamos no haya encontrado un problema de seguridad no significa que no exista, e incluso puede estar más cerca de lo que pensamos.

Entonces, ¿dejamos de utilizar estas incompletas e imperfectas medidas de seguridad? Repasemos de nuevo los tres puntos:

– Antivirus: Hoy en día, en ninguna cabeza cabe el no disponer de antivirus en cualquier entorno Windows, así que además de aplicar las prácticas seguras descritas previamente, hay que asegurarse de su correcta actualización de este, para que al menos esté al día de los virus conocidos. Es decir, que obviamente sí lo debemos de tener.

– IDS: Mi opinion sobre los IDS (no compartida por muchos miembros de este blog) es que son bastante inútiles (esta entrada que va un poco en esa línea), y si no tienen funcionalidad automática de IPS sirven para muy poco (aunque eso puede generar otro tipo de problemas diferentes). En todo caso, la mayor utilidad que le veo a un IDS es la de detectar malware interno poco sofisticado, es decir intrusos internos, con lo que sí pueden ser positivos, aunque el objetivo debería ser que no llegaran dentro. También puede ser útil como herramienta de diagnóstico, para buscar algún patrón concreto en difusión amplia de malware. En definitiva, para ciertas finalidades contar con un IDS es sumamente interesante.

– Auditor de vulnerabilidades: Aunque sean herramientas imperfectas, por su bajo coste de ejecución (se realiza de manera centralizada) pueden ser un primer paso para auditar una red. Aunque es verdad que cada vez son mas inteligentes y son mas capaces de auditar desarrollos genéricos (sqlmap es una maravilla), siguen siendo potencialmente peligrosas en cuanto a que la visión de auditoria de caja negra dista mucho de ser todo lo completa que la puede realizar un “humano” y puede generar una percepción de seguridad inexistente, además de ser infinitamente mas incompleta que una auditoria de caja blanca.

Como creo que era de esperar, usen todas ellas, pero tengan en cuenta siempre los disclaimers correspondientes y no se queden tranquilos con estos “false friends“. En una entrada posterior veremos qué pasa con las certificaciones: ¿”false friends“, o no?

En esta entrada me gustaría repasar algunas aproximaciones al respecto del concepto de Trusted Computing, y como lo lógico es empezar con la definición, por Computación Confiable nos solemos referir a sistemas completos e integrados hardware+software, en los que todo lo que se ejecuta se encuentra bajo el control del sistema y hay muy poca flexibilidad para la ejecución de otras cosas; enseguida veremos algunos ejemplos. Así pues, podría decirse que disponemos de una caja “blindada” que no puede en teoría ser manipulada ni por software ni por hardware, de modo que sólo realizará las funciones para las que esta diseñada siguiendo las directrices marcadas por el fabricante, sin que pueda ser manipulada o alterada.

Para evitar dichas manipulaciones el propio fabricante intenta proteger el sistema para que incluso el “propietario” del hardware (en el sentido de dueño del hierro) pueda utilizarlo para lo que guste. Este tipo de protecciones se usan de manera habitual para proporcionar contenidos con restricciones de uso (DRM), aplicar comisiones a los productos software, sistemas incopiables, etc. En algunos casos, los motivos aducidos serán razonables y en mi opinión otras veces abusos, la pregunta es: ¿Obedece el ordenador a su dueño? ¿U obedece a otra organizacion como Microsoft, Apple , Sony, Nokia, etc.? ¿Somos propietarios de nuestro propio hardware? ¿Quién manda en nuestra propia casa?

Algunos de nuestros lectores estarán ya pensando que que no son usuarios de este tipo de sistemas, pero la realidad es que existen muchos dispositivos de uso cotidiano que se han diseñado con esa filosofía. Vamos a ver algunos aparatos que, en muchos casos sin ninguna razón coherente, hacen “lo que ellos quieren” y no lo que quiere el dueño del “aparato”; son nuestros, pero no del todo, ya que obedecen a sus fabricantes (y a menudo en un sentido literal si existe algún tipo de conexión remota a los dispositivos).

Empecemos por las consolas de videojuegos. En todos los casos estos dispositivos están diseñados para poder ejecutar sólo un software determinado firmado digitalmente, lo que les protege de ejecutar copias de juegos, pero también impide la ejecución de software propio como Linux, o juegos sin pagar comisión. Como veremos, Internet es muy amplia y este tipo de protecciones no suelen durar demasiado tiempo, a pesar del tiempo y recursos utilizados por los fabricantes para diseñarlas (también es cierto que las modificaciones no llegan al gran público, por lo que el objetivo que se persigue con la protección se alcanza). Veamos:

• Xbox: Estos sistemas han sido vulnerados tanto por software mediante el uso de exploits, como por hacks hardware (los famosos modchips).
• Playstation 2: También reventado por hardware mediante modchips.
• Playstation 3: Les ha costado pero tras 3 años, parece que ya ha sido vulnerada.
• Wii: Vulnerado tanto por software como por hardware.
• PSP: Vulnerado tanto por software como por hardware (pandora battery).

En estos casos podríamos comentar que al desproteger el aparato se puede usar para ejecutar copias de juego, algo de moralidad cuestionable, pero también te permite ejecutar tus propios programas “hechos en casa” (homebrew) lo cual parece razonable en un aparato que has pagado y que no entra en conflicto con los intereses del fabricante que te lo vendió. Al respecto, hay ya varias sentencias que determinan la legalidad de estas modificaciones por hardware [ElPaís.com, sentencia completa en Bufet Almeida]aludiendo precisamente a la posibilidad de ejecutar programas como Linux.

En segundo lugar, están los teléfonos móviles, que cada vez son más inteligentes. En este caso, solo aplicaciones firmadas y que hayan pagado la correspondiente licencia pueden ejecutarse en estos dispositivos. En teoría, ademas se revisa que estas aplicaciones no sean dañinas para la estabilidad del teléfono, o incluso para la estabilidad de las redes de telefonía móvil (seguridad por lo tanto bastante cuestionable, si no es por la propia seguridad del protocolo, sino por el acceso a uno de los extremos). Las principales plataformas han sido manipuladas, como se muestra a continuación.

• Symbian: Solo el código firmado se puede ejecutar, si bien han aparecido diversos métodos para saltarse esas limitaciones.
• Iphone: Solo el codigo firmado y descargado de la Apple Store se puede ejecutar, también son ampliamente conocidas los hacks para poder ejecutar cualquier aplicación.
• Android: Incluso los moviles con Android por defecto no te dejan ser root (hay que hacer algunas triquiñuelas para serlo).

Por último, en la categoría de “Otros” existen multitud de dispositivos que entran dentro de este tipo de hardware. Veamos los ejemplos más relevantes:

• Ipad: Tal como lo describe la Free Software Fundation es un gran paso atrás en la historia de la computación ya que sólo permite ejecutar el código autorizado por Apple, siendo además difícil incluso acceder a los contenidos archivados en el propio aparato.
• Subsistema de video de ordenadores HDMI: Los cables HDMI de los equipos informáticos o televisiones disponen de sus protocolos de DRM, con lo que pueden establecer la resolución de la imagen dependiendo de las características del otro lado, o incluso no sacar señal si así lo deciden. Conecten un cable HDMI a su portátil, prueben a reproducir diversos contenidos con DRM y verán la pesadilla.
• Routers, dispositivos domesticos (NAS): numerosos aparatos domésticos están diseñados para que nadie pueda modificar, mejorar o tener pleno control de los aparatos.
• SmartCards, tarjetas de crédito EMV (tarjetas chip), DNI digital: Estos dispositivos aprovechan las funcionalidades de un pequeño sistema informático incrustado en la tarjeta, que tiene su procesador y su memoria, y que es muy robusto tanto desde el punto de vista del software como desde el punto de vista del hardware; al respecto, son sistemas muy difícilmente atacables en comparación con el resto de dispositivos comentados, lo que permite que la tarjeta proteja la clave privada con un PIN, y de ninguna manera la extraiga sino que solo opere con ella en su interior. Podríamos decir que se trata de un sistema confiable y que debe de ser así por la propia funcionalidad que el aparato ofrece, que protege al usuario ante un tercero que robe el propio aparato, y en principio no está a las ordenes de ninguna otra organización. En general estos sistemas no son vulnerados, quizá porque aun no están suficientemente extendidos. Debe destacarse que otros sistemas basados en tarjetas inteligentes como las de suscripciones de TV de pago si que han sido vulnerados, por lo que no seria de extrañar que también aparecieran exploits para estos sistemas.
• Decodificadores de televisión de pago: Normalmente los decodificadores incluyen una tarjeta criptográfica (que en sí mismo es un dispositivo de Computación confiable), que es el que se encarga de recibir las claves de los contenidos desde el proveedor y decodificar o no los contenidos. Al ser tarjetas criptográficas, no son fácilmente atacables debido a que además protegen un activo muy valorado economicamente. A pesar de ello, estos sistemas han sido vulnerados en repetidas ocasiones, pero en la actualidad los sistemas actuales de TV de pago están protegidos por un sistema denominado Nagra3 que parece que es resistente a los ataques.
• Trusted Platform Modules: Los equipos TPM son equipos PC que han sido adaptados para que funcionen de manera “Trusted” (Confiable/Controlada), integran procesadores criptográficos y dan una solución global (cifrado de disco, hardware, etc.). Con estos equipos se pueden diseñar sistemas que sólo ejecuten tu versión de Linux y los paquetes determinados, así como otros sistemas operativos. La solución en principio se ha diseñado para que sea robusta, sin embargo ha sido recientemente vulnerada. En torno a estos sistemas TPM y sobre todo para módulos criptográficos, en los que se quiere certificar su robustez desde el punto de vista lógico pero también desde el punto de vista fisico, existen certificaciones como FIPS que se centran en ello, como por ejemplo este pendrive.

Por último, y como precursor de todos estos artilugios, me gustaría comentar el artilugio de la edad media (popular tras la pelicula del código Davinci) Criptex, un aparato capaz de almacenar un pergamino, pero con vinagre de manera que si no introduces el código correcto destruye el pergamino. Para que vean que la idea de tener una máquina que tome sus propias decisiones en contra de quien la posee viene de muy lejos.

Todos los sistemas comentado se encuentran con los siguientes problemas:

• El software es atacable: Mediante todos los métodos que se os ocurran (exploits, overflows, etc.).
• El hardware es atacable: Se puede modificar el hardware añadiendo circuiteria (los famosos modchips que les comentaba). En el caso de las tarjetas las cosas se complican, aunque existen diversos ataques basados en modificar el voltaje, medir consumos para realizar ingeniería inversa, técnicas con microscopios electrónicos, limpiar con ácido los circuitos y otros muchos métodos de los cuales no soy ningún experto.

Como hemos podido ver, todos los intentos por parte de la industria de disponer de sistemas que no obedezcan al usuario en algún momento han fracasado, por lo que hemos de plantearnos varias cosas (aspectos que también y con mayor interés deberían plantearse los fabricantes de estos dispositivos),

• Primero, desde el punto de vista de la ingeniería, ingeniería del software y evolución técnica de la sociedad no debemos permitir que se impongan limitaciones artificiales sobre el software que se puede ejecutar en cada aparato. Sin duda alguna si el software y el hardware no hubieran funcionado como sistemas interoperables, la sociedad no habría avanzado todo lo que ha avanzado; es necesario por tanto impedir que los sistemas en su conjunto estén controlados por corporaciones.
• Desde el punto de vista de los usuarios, a nivel empresarial debemos de estar atentos a las limitaciones impuestas a nuestros aparatos/sistemas, cuáles son razonables y cuáles son excesivas.
• Desde el punto de vista de los desarrolladores de soluciones tecnológicas de este tipo, visto lo visto, hay que tener en cuenta que tarde o temprano si hay suficiente interés este tipo de sistemas serán vulnerados, y se debe de estar preparado para ese momento.

Este post me gustaría dedicarlo a Alan Turing (23 Junio 1912 – 7 Junio 1954) por inventar una máquina de propósito general, y al mismo tiempo no dedicarlo al resto de la industria por desear hacer todo lo contrario.