Archive for marzo, 2014


Ucrania-Snake-800px

Una variante del Rootkit Snake está siendo detectada con frecuencia cada vez mayor en Ucrania. Anteriormente, Snake fue utilizado para el peor ataque cibernético experimentado en la historia de Estados Unidos.

El departamento de Inteligencia Aplicada de la empresa británica BAE Systems ha publicado un informe sobre una operación de ciberespionaje denominada “Snake”. El código en cuestión es descrito como Rootkit; es decir, malware que es instalado subrepticiamente en el sistema operativo, y que logra permanecer indetectable.

El informe de BAE Systems describe la forma en que Snake (PDF) logra penetrar la potente protección en torno al núcleo de 64 bits de Windows, incluyendo las versiones 7 y 8. En el documento se indica que Snake “tiene una arquitectura increíblemente compleja, diseñada para vulnerar el núcleo del sistema operativo”.

BAE Systems continúa señalando que “la construcción lleva a suponer que los atacantes disponen de un verdadero arsenal de herramientas de infiltración, presentando todos los indicios de que se trata de una ciber-operación altamente refinada”.

Snake puede propagarse mediante diversos procedimientos, que incluyen correo electrónico dirigido a destinatarios específicos, y memorias USB infectadas.  A juicio de BAE, Snake constituye una grave amenaza contra organizaciones legítimas en la mayoría de los países, especialmente aquellas con grandes redes, como empresas multinacionales y el sector público.

Desde 2010 se han detectado 56 variantes del malware, en 9 países. La mayoría de los casos, 32, corresponde a Ucrania, con 8 incidencias en 2013, y 14 en lo que va del presente año.

BAE hace además referencia a un informe publicado el 28 de febrero por la empresa de seguridad informática alemana G Data, donde da cuenta de un rootkit denominado Uroburos, vocablo griego traducido como “serpiente”. El informe, titulado “Uroburos, un software de espionaje altamente complejo, con raíces rusas”, no deja dudas sobre la autoría del malware.

Según BAE, Uroburos es un componente de Snake. Al igual que BAE, G Data menciona el alto grado de complejidad del malware, recalcando que su desarrollo y actualización requiere de grandes recursos, de todo tipo.

En sus respectivos informes, BAE y G Data coinciden en que Uroburos es un desarrollo de Agente.btz, un código maligno detectado en redes de las Fuerzas Armadas estadounidenses en 2008, en Estados Unidos y Afganistán. 2 años más tarde, el viceministro de defensa de Estados Unidos, William Lynt, reveló que la extracción del malware de las redes del pentágono había tomado 14 meses.

En 2010 trascendió que el Pentágono sospechaba que Agent.btz tenía un origen ruso, aunque no se proporcionaron detalles. El informe de BAE no menciona directamente a Rusia. La empresa analiza distintos detalles, entre ellos cronología y compilación, concluyendo que los autores del código han trabajado en “horas de oficina” en zonas horarias equivalentes a San Petersburgo y Moscú.

La conclusión principal es que el código maligno -altamente avanzado y que supuestamente es una variante del peor ataque cibernético dirigido contra Estados Unidos- se propaga estos días con gran intensidad en Ucrania.

“Es una de las amenazas más avanzadas y resistentes que estamos observando” se indica en el informe de BAE, agregando que Snake instala puertas traseras, se oculta con gran eficacia, y establece conexiones con servidores de comando, incluso desde sistemas desconectados de Internet. Asimismo, los métodos de transmisión de datos dificultan sobremanera detectar que información está siendo transmitida desde el sistema intervenido.

Gran parte de los procedimientos empleados serían manuales, es decir, requerirían la intervención de un operador humano, lo que nuevamente lleva a suponer que los responsables tienen cuantiosos recursos a su disposición.

Fuente | ITSitio

keyholders

Desde hace unos cuatro años, varias personas se reúnen cada tres meses en las instalaciones de la ICANN en Estados Unidos para llevar a cabo una ceremonia realmente curiosa. Hasta ahora esto había pasado por debajo del radar, pero James Ball, periodista de The Guardian, pudo estar en una de esas ceremonias contando todo desde dentro.

La ceremonia es una versión más elaborada, compleja y segura de lo que hacemos con menor frecuencia de la que deberíamos: cambiar nuestras contraseñas. Esas siete llaves controlan la seguridad del sistema DNSSEC, uno de los puntos troncales para la seguridad en Internet – aunque no está todavía extendido por toda la red -.

Tras pasar varios controles de seguridad, incluyendo un reconocimiento de retina que no acaba de funcionar del todo bien, siete representantes con amplia experiencia en seguridad se reúnen con varios testigos y otros oficiales para dar comienzo a la ceremonia. Cada representante tiene una llave metálica que abre una caja fuerte. En esas cajas hay tarjetas inteligentes (smartcards) guardadas en cajas con indicadores de manipulación.

cards

– Esas tarjetas activan el HSM, el encargado de firmar las claves –

Una vez recuperadas las tarjetas y después de verificar que no se ha accedido a ellas desde la última vez que se guardaron, se activa con ellas un HSM (Hardware Security Module o módulo de seguridad hardware). El HSM se conecta a un ordenador y, después de seguir pasos detallados al milímetro – incluyendo como configurar una impresora -, se ejecuta el procedimiento de firma y se crea una SKR (Signed Key Response), que contiene las nuevas claves que habrá que distribuir por Internet para asegurar los sistemas DNS. La SKR se guarda en una memoria USB, y sus contenidos serán transmitidos por un operador de ICANN a VeriSign a través de una conexión segura.

Después de que la firma se complete, se vuelven a aplicar cuidadosos procedimientos para guardar de nuevo las tarjetas inteligentes y dejar todo tal y como estaba, listo para la siguiente ceremonia de firmado.

Todos los detalles del evento están en el muy recomendable relato de The Guardian, en inglés. Pero, ¿en qué consiste realmente esa ceremonia? ¿Qué quiere decir que esas llaves tienen el destino de la seguridad de los DNS en sus manos?

> Fallos de seguridad en DNS y su respuesta: DNSSEC

datacenter

Muchos ya sabréis de qué estamos hablando con DNS. Por si acaso, hagamos un repaso rápido. Como os podéis imaginar, los ordenadores y los humanos no se llevan muy bien: a los primeros les gustan los números y a los segundos nos gustan las cadenas de texto. Eso genera ciertas discrepancias a la hora de, por ejemplo, navegar por páginas web. El ordenador identifica los servidores con una dirección IP, como pueda ser 199.16.156.230. Esto le da información más que suficiente para enrutar las peticiones a través de la red y mostrarte la página web.

Si nosotros tuviésemos que acordarnos de esas direcciones cada vez que queremos visitar una página web andaríamos servidos. Para eso está el sistema DNS: traducir cadenas fáciles de recordar a las respectivas direcciones IP que interpreta el ordenador, promoviendo así la paz, el amor y el entendimiento entre máquinas y humanos. Como Her, pero en pequeño y discreto.

Y como buen sistema que pretende llevar la paz al mundo, también es un poco ingenuo. Tenemos que tener en cuenta el contexto: DNS se creó en los inicios de Internet, cuando poca gente tenía acceso a él y no había hackers malvados (ya sabéis, los del antifaz, fusil y cebolla a la espalda). Si un servidor DNS te decía “google.com tiene la dirección 87.12.3.12” te fiabas.

Pero se veía que eso tenía fallos. Ya en 1990 se empezaron a difundir avisos sobre los problemas de seguridad del protocolo. Por ejemplo, si a un servidor le preguntaban la IP para el dominio “pepe.com”, podía responder “pepe.com tiene la IP 1.2.3.4. Por cierto, tubanco.com tiene la dirección 7.8.9.0, apúntate eso también”. Y tu ordenador se lo creía. También era posible interceptar las comunicaciones entre tu ordenador y los servidores DNS, modificando las repuestas a las IPs que le convenga al atacante. Es decir, se podía realizar DNS Spoofing y engañar a los navegadores para que accedieran no al servidor real de tu banco, sino a uno falso que obtendría tu usuario y contraseña.

En 1999 se plantea el estándar DNSSEC. Introducía el concepto de firmar digitalmente los registros de DNS, para asegurarte así que no habían sido modificados por el camino.

La idea era buena, pero contaba con un pequeño fallo de diseño. Si se actualizaba la clave de un servidor, se tenían que regenerar cada una de las firmas de los registros dependientes. Por ejemplo, si cambiaba la clave de firma del servidor raíz de los dominios .com, habría que volver a firmar todos y cada uno de los dominios. Imaginaos qué bien se lo pasaría el servidor raíz encontrándose con más de 100 millones de dominios que firmar, recibidos de varios servidores DNS a lo largo y ancho del globo y teniendo que intercambiar una cantidad de datos más que considerable para llevar a cabo la firma de cada dominio.

La IETF (Internet Engineering Task Force) crea un estándar modificado, DNSSEC-bis, que además de proporcionar seguridad consigue no ser un sistema para la autodestrucción por sobrecarga de servidores DNS. El cambio consiste en que cada servidor tiene su propia clave, que está firmada por el servidor anterior en la jerarquía. Por ejemplo, la clave de los servidores DNS de GoDaddy para dominios .com estaría firmada por VeriSign (los gestores de todos los dominios .com), y la clave de firmado de VeriSign estaría firmada por…

Efectivamente, lo habéis adivinado. La ICANN. Y eso nos lleva a nuestros queridos señores expertos y criptógrafos que tienen una llave que abre una caja que tiene otra caja que tiene una tarjeta que activa un módulo que tiene una clave que firma cosas.

> ZSK, KSK, KSR, SRK

lineatiempoclaves

Los informáticos somos muy dados a los acrónimos, ya lo sabéis. En concreto, las del título explican, en orden, el proceso que se lleva a cabo en la ceremonia de la ICANN.

Empezamos con la ZSK: Zone Signing Key (clave de firmado de zona). Esta clave, RSA de 1024 bits, pertenece a VeriSign, una empresa estadounidense dedicada a la seguridad e infraestructura de redes. Entre otras cosas, está encargada de mantener el fichero raíz de zonas. Se trata de un registro que indica qué servidores DNS corresponden a cada TLD (los TLD o top level domain son las terminaciones de los dominios: .com, .net, .es…). Es, por lo tanto, la raíz de todo el sistema DNS (de ahí su nombre). En DNSSEC, esos registros se firman con la ZSK, lo que certifica su autenticidad.

Ahora bien, alguien tiene que certificar que efectivamente esa ZSK es legítima y pertenece a VeriSign. Eso lo hace la ICANN con la KSK o Key Signing Key (clave de firmado maestra), clave RSA de 2048 bits. La parte pública está disponible en su sitio web para que cualquiera pueda consultarla y verificar la cadena de firmas. La parte privada, la que se utiliza para firmar, permanece guardada en los HSMque comentábamos antes antes.

Hay un pequeño problema con las firmas de las ZSK, que viene bien explicado en la página de DNSCurve. Imaginaos que vuestro banco cambia de proveedor de hosting, y la IP de los servidores cambia. Hasta ahora todo normal. Pero, ¿qué pasa si alguien consigue poner sus servidores en la IP antigua del banco? Podría haberse guardado las firmas de esos registros, que seguirían siendo válidas, y así redirigir a usuarios al sitio web falso para robar claves y hacer demás cosas malvadas.

Hay que fijar tiempos de validez para las claves y minimizar los riesgos de que eso ocurra. Actualmente, el tiempo de validez son 15 días, y recordemos que cada una de esas claves ZSK tiene que ir firmada por la KSK. Para evitar sobrecargas, VeriSign hace las peticiones de firmado en tandas de 9 claves.

Esas peticiones son las KSR o Key Signature Request (petición de firmado de claves). En la ceremonia de firmado de la ICANN se comprueba primero la integridad de la KSR, comprobando que el hash o huella digital del KSR recibido coincide con el que calculó VeriSign al generar la petición. Después, se verifica que las ZSK sean las mismas que se generaron en la anterior ceremonia.

Los HSM son los módulos hardware que contienen la clave de firma, KSK, y los que firmarán cada una de las ZSK. El resultado se encapsula en una SKR o Signed Key Response (respuesta de claves firmadas), que se enviará a VeriSign. Una vez obtenida la autorización de la NTIA (la agencia de administración de telecomunicaciones estadounidense), VeriSign usará las nuevas claves para firmar los registros del archivo raíz de zonas. Tres meses después, se volverá a repetir la ceremonia para regenerar las ZSK.

seguridadfisica

Con todo este procedimiento se trata de establecer una raíz de confianza para todo el sistema DNSSEC, una entidad que todo el mundo tome por confiable por defecto. Eso explica toda la seguridad y parafernalia alrededor de la ceremonia: si alguien ajeno a la ICANN tuviese la clave maestra, podría modificar los registros DNS sin alertar (al menos no inmediatamente) de que han sido modificados y están redirigiendo a servidores potencialmente peligrosos.

La ICANN y los expertos responsables de las llaves que dan acceso a las claves mantienen que el sistema es seguro y que es prácticamente improbable que alguien se haga con la clave privada. Es cierto que no es algo que el mundo de la seguridad cuestione, aunque sí es más polémico el control de Estados Unidos en todo el proceso. VeriSign es una empresa privada estadounidense, la ICANN tiene la misma procedencia y las ceremonias se realizan igualmente en Estados Unidos. En algunos países esto produce desconfianza, más aún tras las filtraciones de la NSA, y se propone que el control pase a manos de organizaciones internacionales como Naciones Unidas.

Fuente | The Guardian

 

todo-sobre-ios7

Apple suele ser muy opaca a la hora de explicar cómo funciona su sistema operativo móvil, iOS. Por eso resulta curioso ver toda la información que comparten en un paper sobre la seguridad en iOS, que expone los sistemas que usan para proteger los datos de sus usuarios.

Quizás esta publicación tenga algo que ver con el fallo de SSL de hace unos días. Sea como sea, el documento es una lectura recomendada si tenéis curiosidad por la criptografía y seguridad, aunque es bastante técnico.

> Arranque y actualización del sistema

Apple pretende que el sistema sea seguro desde el primer momento. ¿Cómo lograr eso? Con una cadena de confianza que empieza en la ROM de arranque. Este segmento de memoria es sólo de lectura y se crea durante la fabricación del teléfono. Entre otras cosas, contiene la clave pública del certificado raíz de Apple.

Con la clave pública podemos verificar la firma y asegurarnos que los datos firmados no han variado absolutamente nada desde que Apple los creó y firmó con su clave privada. De esta forma, el cargador de arranque verifica la firma del LLB (Low Level Bootloader). Este a su vez comprobará la firma de la siguiente etapa de arranque, iBoot, que finalmente verificará la firma del núcleo de iOS.

Esta cadena de confianza asegura que todo lo que se está ejecutando en el dispositivo está firmado por Apple. Teóricamente, no podríamos crear un SO alternativo y cargarlo en un iPhone: la verificación fallaría al cargar el núcleo y nos aparecería la pantalla de “Conectar a iTunes” para restaurar el teléfono.

Cupertino también tiene preparado un sistema de verificación para evitar los downgrades, instalación de versiones antiguas del sistema. La razón es impedir a posibles atacantes instalar versiones antiguas que tengan fallos de seguridad.

El proceso se llama System Software Authorization: se crea una especie de “firma” del sistema que se envía a Apple junto con un ID del dispositivo y un código (nonce) único para cada verificación.

Los servidores de Apple verifican que efectivamente esa versión de iOS se puede instalar y devuelve una autorización firmada al dispositivo. Al incluir el ID y el nonce, Apple se asegura de dos cosas respectivamente: que no estás reutilizando una autorización para otro dispositivo (por ejemplo, puedes instalar iOS 6 en un iPhone 3GS, pero no en un iPhone 5) y que no estás reutilizando autorizaciones que ya fueron usadas.

> Secure Enclave y criptografía hardware

secureenclave

La seguridad de Secure Enclave comienza en el momento en el que se arranca el sistema por primera vez. Durante la fabricación, se “imprime” en el chip un ID único (UID), que Apple dice no conocer y que no es accesible por ninguna otra parte del sistema. Ese UID se combina con una clave temporal para generar la clave de cifrado de la memoria de Secure Enclave, de tal forma que lo que se guarde ahí no podrá ser leído (teóricamente, como siempre) por nadie más.

Secure Enclave no es la única parte del sistema que cuenta con criptografía directamente enhardware. iOS cuenta con Data Protection, una característica para cifrar todos los datos sensibles, activada por defecto para todas las aplicaciones en iOS 7 cuando el usuario crea una contraseña de bloqueo.

Para poder cifrar esos archivos, Apple usa un sistema de criptografía hardware que se interpone entre la memoria del sistema y el disco de datos. Cuando leemos un archivo (por poner dos ejemplos, un ejecutable de una aplicación o un correo), pasa por el procesador criptográfico que cifra y descifra los archivos según corresponda, usando AES 256. Las claves de cifrado están de nuevo embebidas en el procesador, y ni el software ni el firmware pueden acceder a ellas.

> Touch ID y contraseñas de bloqueo

touchid

Una de las características estrella del iPhone 5S es Touch ID. En este paper se profundiza más en cómo funciona el sistema, que está muy vinculado con las contraseñas de bloqueo del teléfono.

Al configurar tu huella dactilar, se escanea tu dedo y se guarda en la memoria de Secure Enclave. Tras ser analizada para obtener los rasgos que la identifican, la imagen de tu huella se elimina del teléfono. Los rasgos se guardan en el sistema de archivos del iPhone cifrados por Secure Enclave. Según Apple, esos datos cifrados no se envían a ningún servidor, ni se guardan en iCloud o iTunes.

¿Cómo funciona el proceso de bloqueo y desbloqueo? Mientras iOS está funcionando, los archivos que usen se descifran con una clave que está en memoria. Al bloquearse, esas claves se agrupan y se cifran con una clave que almacena el sistema Touch ID. En ese momento los archivos protegidos, como tus correos, aplicaciones o datos confidenciales de tus cuentas, se vuelven inaccesibles. Sin clave no hay ficheros, y sin ficheros no puedes hacer nada.

Así, cuando el teléfono está bloqueado, se mete en su caparazón, por así decirlo. Uno pensaría que bloquear el teléfono es sólo superficial y sólo sirve para evitar que tus amigos cambien los nombres de tus contactos cuando tú no miras. La realidad es que la protección es mucho más profunda. El teléfono está realmente bloqueado y no puede seguir funcionando porque no tiene acceso a los archivos cifrados.

Al desbloquear el iPhone con la huella dactilar o con la contraseña, se recuperan las claves y el sistema sigue funcionando normalmente accediendo a los ficheros protegidos.

> Seguridad en iMessage: quizá no tan seguro

messages-1

El paper de Apple también explica cómo funciona la seguridad en iMessage. El sistema usa cifrado de punto a punto, de tal forma que (en teoría, como veremos más adelante) los de Cupertino no pueden ver qué mensajes estás enviando.

Cuando vinculas un dispositivo con tu cuenta de iMessage, se crean dos pares de clave pública/privada: uno para cifrar y otro para firmar. Las claves privadas se quedan en tu dispositivo y las públicas se envían al IDS, el directorio de usuarios de iMessage almacenado en los servidores de Apple.

¿Cómo se envían los mensajes? Supongamos que Alicia quiere enviar un mensaje a Bernardo, que es todo un fan de Apple y tiene un iPhone, un iPad, un Macbook y un iMac. Alicia escribe el mensaje en iMessage y le da a enviar. Entonces, la aplicación se conecta a IDS y mira los registros de Bernardo. Ve que tiene varios dispositivos y se descarga las claves públicas de cada uno de ellos junto con la dirección a la que enviarles el mensaje.

El iMessage de Alicia cifra el mensaje con la clave pública del iPhone de Bernardo, de tal forma que sólo ese dispositivo podrá descifrarlo con su clave privada, y lo envía a la dirección correspondiente. Hace lo mismo con cada uno de los dispositivos de Bernardo, enviando un mensaje cifrado a cada uno.

Si el mensaje incluye adjuntos, el iMessage de Alicia subirá cada adjunto cifrado a iCloud. El mensaje que se envíe a Bernardo contendrá información para descargar y descifrar el archivo desde iCloud.

Sin embargo, este esquema tiene fallos. Decíamos que en el directorio se guardan las claves públicas de los dispositivos de Bernardo. Ahora bien, ¿cómo sabemos que esos dispositivos son realmente de Bernardo? ¿Qué pasa si Bartolo, el hermano gemelo malvado de Bernardo, entra en los servidores de Apple e inserta la clave pública y dirección de su iPhone? A Bartolo le llegarían todos los mensajes de Bernardo, y Alicia no tendría forma de detectarlo.

Ese es el fallo del esquema de iMessage. Y es que no hace falta que sea Bartolo el superhacker quien entre a los servidores. Pensando mal, podríamos imaginarnos que Apple podría colocar claves públicas a petición de la NSA para espiar a ciertos usuarios. O quizás, si tu iPhone no ha sido actualizado, alguien podría manipular las respuestas del servidor IDS de Apple e introducir claves públicas adicionales para ver los mensajes que envías.

> iCloud Keychain, contraseñas en la nube

icloud

Para acabar, repasemos cómo funciona iCloud Keychain, el servicio de Apple que permite sincronizar contraseñas en varios dispositivos. La idea del Keychain de iCloud es, curiosamente, que las contraseñas no se almacenan en iCloud, al menos no de forma permanente. Lo que se almacena es un círculo de confianza que incluye las identidades de cada uno tus dispositivos.

Al activar Keychain por primera vez en tu cuenta, tu teléfono crea un par de clave pública y clave privada. La clave pública se almacena en el círculo de confianza, que se firma con la clave privada y con una clave derivada de tu contraseña de iCloud.

Cuando añades otro dispositivo a iCloud Keychain, este crea su par de claves y, al detectar que ya hay otros dispositivos vinculados, crea una petición de vinculación. Esa petición o ticket contiene la clave pública del dispositivo, y está firmada con la clave derivada de la contraseña de iCloud. La petición se envía a iCloud.

En ese momento tienes que usar el teléfono en el que ya esté configurado iCloud Keychain, que habrá detectado que hay una petición pendiente y te preguntará con un popup si quieres añadir la nueva identidad. Si aceptas e introduces tu contraseña de iCloud, se verifica la firma y se añade la clave pública al círculo de confianza. De nuevo, el círculo se firma con la clave privada y la clave derivada. El nuevo dispositivo también firma el círculo con su clave privada.

El funcionamiento puede parecer bastante lioso (de hecho, lo es). Hagamos una analogía. iCloud Keychain es un club elitista del cual tú eres el presidente. Si alguien quiere entrar, primero tiene que preguntarte a ti el santo y seña. Después va al club y les dice a los miembros que quiere entrar, y les da el santo y seña. Ellos te preguntan si el santo y seña es válido. Si lo es, el nuevo miembro es bienvenido al club.

A la hora de enviar los datos, se hace entre los clientes. Si creas una nueva contraseña en tu iPhone y hay que sincronizarla en tu Macbook, el iPhone cifra la nueva entrada con la clave pública del Macbook y se la envía directamente a través de iCloud.

De esta forma, tus contraseñas se guardan en tus dispostivos. Se transmiten de tal forma que nadie más que el dispositivo destino puede descifrarlas.

Por otra parte, cada dispositivo envía una copia de seguridad de tus contraseñas a los servidores de Apple. Ahí se guarda cifrada con tu código de seguridad de iCloud, de tal forma que si pierdes tu dispositivo puedes recuperar las contraseñas. Las copias de seguridad están almacenadas en uncluster de servidores seguros, que cifran las copias de nuevo con una clave única para cada servidor. A la hora de recuperar la copia, se verifica que el usuario conoce el código de seguridad de iCloud sin pedirlo directamente (no sale del teléfono). Si todo sale bien, se envía la copia al usuario y se recuperan las contraseñas.

Como medida de seguridad adicional, el firmware de esos servidores borra automáticamente los registros si se tratan de desbloquear 10 veces sin éxito o si se intenta modificar el propio software de los servidores.

Estos son los aspectos más destacados del paper de Apple. Desde luego, es muy de agradecer tener tantas explicaciones sobre un aspecto en el que Apple es normalmente muy opaca. De nuevo, si tenéis curiosidad, en el PDF hay más datos y más técnicos, como por ejemplo el sistema de cifrado de archivos o cómo ejecutan sólo aplicaciones autorizadas en el teléfono.

Fuente | iOS Security

A %d blogueros les gusta esto: