IPv6 Security (III)

IPv6 in general brings lots of changes directly related to security. But not only these improve the security of the new IP protocol. In this post we will see how some of the features and changes comming with IPv6 affect the security of the protocol in an indirect manner.

Enhanced address space vs. ping sweeps
In IPv6 the default subnet size is 2^64 - which means it can exist of 18.446.744.073.709.551.616 hosts within one network.

With a 2GHz Dual Core machine connected to a 100MBit network a nmap scan (using the echo request/reply mechanism) for a /24 subnet takes 2.554 seconds. If we assume there is the same speed to the IPv6 remote network we want to scan it would take 5.835.714.585 years to scan the 2^64 subnet.

Network administrators face the problem that IPv6 addresses are not really friendly to remind. For practical reasons all the hosts in an IPv6 network will be in a DNS server. Thus the main target to find hosts in a remote network will be DNS servers.

Stateless Address/Router Configuration
This is a point which affects the security of IPv6 in a negative way. What is a real help for administrators can also be an advantage for attackers with the aim of gaining access to the infrastructure.

If there is a new machine in the net, it will generate its EUI-64 IPv6 address - but before assigning the address to the interface it will check with a request packet if this address is already used by another host to avoid conflicts.
Later on the host will ask in the local network for a router. The router will respond to that request and provide the necessary information in order to connect the host to e.g. the Internet.

All these automatic configuration mechanisms are based on trust, so everybody could spoof a message that says this address is already assigned, or respond to the router request to make a man-in-the middle attack.

The THC (The Hackers Choice) Group has proved these and more attacks in practice and released the code here . Also the presentation is truly worth a look.

The solution to this problem - SEcure Neighbor Discovery (SEND) is already discussed in 2005 in the RFC 3971 , but until now there is no implementation found in recent operating systems.

Some more attacks to IPv6 not only related to the local trust model can be found here .

Clemens Kurtenbach
S21sec e-crime

GRC: Governance, Risk & Compliance.

Durante los últimos años los estados -con Estados Unidos a la cabeza, pero cada vez más también en Europa- han mostrado un interés creciente en regular las actividades de las compañías obligando a estas a presentar informes de cumplimiento de diferentes normativas. Sarbanes-Oxley, HIPAA, PCI-DSS, ISO 27001 o nuestra LOPD son los nombres de algunas de las regulaciones que han provocado esta necesidad en los diferentes países involucrados.
Las compañías están teniendo que adaptarse a una gran cantidad de cambios tanto estructurales, como técnicos y de proceso. Lo cual, naturalmente, provoca a sus responsables no pocos quebraderos de cabeza, por lo que la industria ha reaccionado ofreciendo soluciones denominadas GRC (de Governance Risk Management & Compliance) para que les asistan en su tarea.
Pero, ¿qué es lo que hacen exactamente? La respuesta no es en absoluto sencilla.
En primer lugar, es necesario dejar muy claro que las siglas GRC no hacen estrictamente referencia a un producto ni a una tecnología, ni siquiera a una familia de ellas. Se trata más bien de una rama de la estrategia empresarial que, eso sí, se puede apoyar en diversas tecnologías y procesos.

Para entenderlos bien, merece la pena detenerse en cada una de las siglas a las que hace referencia el acrónimo:

• Gobernanza: Comprende las costumbres, organismos y procesos que determinan cómo se ejerce el poder, cómo se define la función de cada miembro de la organización y cómo se alcanza la transparencia . La gobernanza también se denomina, en ocasiones, de forma más autoexplicativa como “gobierno relacional”. Aunque se puede hablar de gobernanza en distintos ámbitos, las características de una buena gobernanza serían la legitimidad del poder, visión estratégica, capacidad de respuesta ante necesidades, efectividad y eficiencia, transparencia y monitorización, igualdad y participación, y respeto a la ley. (En la práctica, a menudo se utiliza la palabra "gobierno", pero siendo estrictos es una palabra más genérica y menos precisa que "gobernanza").

• Gestión del Riesgo: El término Risk Management hace referencia al asesoramiento, la mitigación hasta un nivel aceptable y monitorización de los riesgos como un enfoque estructurado mara manejar la incertidumbre asociada a posibles amenazas. En el caso que más interesa en este post, incluye –aunque no exclusivamente- las diferentes herramientas de seguridad tecnológica.
• Cumplimiento: Es el proceso de monitorizar y almacenar toda la información de control de una organización para garantizar el acatamiento de una determinada normativa externa o interna.
Es importante señalar que el orden de las siglas no es arbitrario. Sin una gobernanza de cierta calidad, es imposible realizar una gestión del riesgo coherente, del mismo modo que sin las dos anteriores, no se puede garantizar un cumplimiento sólido.
Por otra parte, también conviene precisar que los métodos GRC pueden ir enfocados a cada actividad de una organización y que, aunque las soluciones presentes en el mercado no siempre se ajustan a esta división, suelen distinguirse tres grandes áreas: GRC Financiero, GRC Legal y GRC de Tecnologías de la Información (IT GRC).
Continuaremos tratando el tema en futuros posts.

Luis Tarrafeta
S21sec labs

RSA Conference (II)

Continuando sobre los posts de la RSA Conference, además de los comentarios que realizamos en el primer post, es interesante resaltar que:

• Existen varias compañias asiáticas presentes (cosa que antes era raro encontrar). Sobre todo para tema de hardware (aceleración, descifrado de SSL, interceptación, ...). Hay varias empresas de China y de India
• Si hemos comentado que Cloud Security eran las palabras mágicas, también es verdad que el tema del segundo factor de autenticación está bastante presente (biometría, OTP, USB, ...)
• Hay cada vez más empresas dedicadas a seguridad de bases de datos, tanto desde el punto de vista de protección, como de análisis forense.
• La seguridad en VoIP es algo que ya no está de moda
• La seguridad en virtualización parecía un tema importante, pero la realidad es que nadie comenta nada en los stands
• Alemania tiene un stand gigante con muchas empresas alemanas (¿se quiere posicionar Alemania como el país europeo donde más se crea productos/servicios de seguridad?)

Muchas de las charlas durante estos dos últimos días han sido realmente muy atractivas, principalmente las que han versado de ciberseguridad (ha habido varios paneles con increibles ponentes), una sobre virtualización (el esperado cara a cara de Chris Hoffman) y muchas más que tendremos que esperar a que esté el audio y el video disponible porque en cada sesión, a la vez había 17 diferentes charlas, cada cual más interesante.

David Barroso

S21sec e-crime

Ias Jornadas sobre Seguridad Informática BS3C 2009

Este fin de semana, en concreto el viernes y el sábado, se celebrarán en Bilbao las Ias Jornadas sobre Seguridad Informática BS3C 2009. En ellas, además de las ponencias de expertos en internet y seguridad, habrá distintas actividades lúdicas y el sábado por la noche una fiesta como final de las Jornadas. 

Nosotros no queríamos faltar y Mikel Gastesi, Investigador de S21sec e-crime, estará allí el sábado para hablar de Malware y Cibercrimen.Podéis ver toda la información aquí, para asistir es necesario inscribirse.

¡Nos vemos el fin de semana en Bilbao!

Dpto. Marketing

Foto: http://www.flickr.com/photos/homeofbastian/

(Ciber)ética vs tecnología

Ríos de tinta se han vertido sobre la difícil relación que tienen la ética y la tecnología en los tiempos que corren. Las tecnologías de la información están evolucionando a un ritmo vertiginoso, que incluso la generación del baby-boom en muchos casos no puede seguir. Se podría decir que los mayores beneficiados de esta carrera del silicio son los jóvenes, más concretamente los menores, que demuestran tener una enorme capacidad de asimilar nuevos conocimientos para su propio beneficio. El problema es que pocos adultos son capaces de guiar de la forma más segura y sensata de emplear estos medios.

En esta situación, los padres se encuentran indefensos. Son capaces de inculcar unos valores que poca relación guardan con la informática o las comunicaciones, generándose un vacío ético en donde el bien y el mal se relativizan en unos y ceros, se amplían las distancias y muchas veces se desconoce el alcance de las acciones. Por ejemplo, leo en la prensa que se ha expulsado a 19 alumnos de un IES asturiano, por el simple hecho de haber hecho fotos y colgado en redes sociales.

Tratando de ponerme en la piel de uno de los menores expulsados, rodeado de toda esa tecnología, la cuál manejo con cierta soltura, y sin terminar de entender las consecuencias últimas de llevar a cabo ciertas acciones, me imagino encontrarme en una situación de profunda indignación. Y es que, si mi móvil tiene una cámara capaz de capturar fotos y vídeo, ¿por qué no iba a compartir buenos momentos con la gente con la que paso la mayor parte del día?

Pero claro, no se tienen en cuenta ciertas reacciones asociadas a las acciones. Esto va más allá de buscar un castigo ejemplar, una forma de advertir al resto del alumnado que el hecho de hacer fotos en el centro está completamente prohibido. Cierto es que hay una mayor concentración de menores, a los que afortunadamente la ley les ampara en todas las ocasiones. Pero mientras ese alumno expulsado pueda pensar en la injusticia que se ha cometido, no se ha parado a pensar en los efectos colaterales de sus acciones: está publicando fotografías en redes sociales sin pedir permiso a la gente que aparece en ellas, desvelando en ocasiones su identidad. Todos sabemos que las redes sociales son una herramienta de doble filo en la que casi siempre el usuario menor de edad es el perjudicado, aunque no se dé cuenta de ello.

Yo me hago una pregunta. ¿El objetivo último de este castigo consistente en la expulsión de estos 19 menores era el de recalcar la prohibición, o existe una intención moral de advertir al menor de las consecuencias de tomarse la tecnología tan a la ligera? Yo me temo que se trata de lo primero, y es que los padres y los educadores, por desgracia para ellos, tienen inculcados unos valores éticos que no contemplan el último grito en móviles multimedia, ciñéndose al hecho de que hay que respectar unas normas y leyes para poder convivir en una sociedad. Obviamente, ambas se complementan.

Este tipo de temas se están tratando en multitud de iniciativas y proyectos que nacen a nivel europeo, en donde se busca dar solución a esta problemática. Sin embargo, veo que existe un problema: la falta de cohesión, la falta de un mensaje único, uniforme, adaptado a padres e hijos y que acabe cayendo por su propio peso en los valores morales de ambos. ¿Responsabilidad de los gobiernos, actualizándose y dándose prisa en endurecer las penas de aquellos que, siendo conscientes de lo que hacen, tengan malas intenciones en el mundo digital? ¿Responsabilidad de las compañías que desarrollan las redes sociales, poniendo especial interés en la seguridad de aquel segmento de mercado en el que los protagonistas son los jóvenes? ¿De los medios de comunicación, que en el 99% de las ocasiones mezclan peras con manzanas, amarillean y no logran transmitir el mensaje adecuado de la seguridad? ¿De los padres, quienes por cansancio, desinterés o falta de ganas de aprender, no se ponen al día en las tecnologías que explotan sus hijos? Creo que no hay un único responsable, es un problema que concierne a todos.

En un mundo cada vez más "digitalizado", es preciso incorporar toda una serie de valores, rompiendo una serie de barreras que de momento separan la identidad física del equivalente binario de un individuo. Es decir, no se trata de pensar en un mundo utópico en el que no se conciba hacer el mal con los ordenadores (en tanto en cuanto en muchas ocasiones se trata de un negocio), sino de tener bien claros los do's y dont's y que estemos a la altura de hacérselo entender a las generaciones posteriores, que nos tomarán el testigo del mismo modo que hicieron nuestros padres con nosotros.

Álvaro Ramón
S21sec labs

RSA Conference (I)

Hoy ha sido el primer día de la feria y aunque nos temíamos que iba a haber menos stands este año, realmente están los mismos o más que otros años anteriores. Como impresiones rápidas podemos decir que:
- Las palabras de moda son Cloud Security o Seguridad en la Nube (incluso en el panel de criptoanalista se ha hablado de este tema)
- El otro tema principal es el de Identity Management o Gestión de Identidades.

Realmente la RSA Security Conference es para bien o para mal un indicador muy claro sobre la evolución de las empresas de Seguridad, puesto que dependiendo del tamaño del stand en comparación con otros años se puede adivinar si les ha ido bien o mal, o si simplemente la empresa ya no tiene stand es probable que su idea no haya tenido éxito. Temas como el famoso NAC, virtualización, o DRM son temas que ya no están de moda (debido principalmente a que no son soluciones maduras, o por el contrario, el mercado no estaba preparado).

Es interesante destacar que es la primera edición que Google tiene un stand (aunque realmente no ofrece nada de Seguridad, tan sólo servicios "seguros" en la nube), pero sobre todo, que todo el mundo habla de ciberseguridad (incluso el Department of Homeland Security tiene un stand). Si nos fijamos en las charlas que se dan, todos los días hay temas de ciberseguridad o protección de infraestructuras críticas.

Estamos cubriendo el evento de la RSA mediante Twitter, aunque también lo intentaremos hacer mediante este blog.

David Barroso
S21sec e-crime

Cosechando resultados

Cualquier código malicioso, como todo producto, tiene asociados unos costes de diseño, desarrollo, testing y despliegue. Evidentemente, llega un punto en el que se pretende obtener un ROI para amortizar la inversión, todo esto es un negocio, ilegal, pero negocio.

Tras toda la rumorología que hubo alrededor de la actualización de Conficker C para el 1 de Abril, en el que decenas de administadores de sistemas y equipos de seguridad se mantuvieron de guardia esperando algún tipo de catastrofe (que posteriormente no ocurrió), es ahora cuando se empieza a apreciar cierto movimiento en la red de máquinas infectadas por este troyano. Ciertos segmentos de la red creada por el gusano se están empezando a actualizar vía P2P de un modo muy discreto y sin ningún tipo de patrón aparente en lo que respecta a qué máquinas se actualizan.

Una de las hipótesis es que se están empezando a alquilar algunos segmentos de la red para uso de terceros, empezando a amortizar así toda la inversión realizada en un principio. Recordemos que Conficker empezó su modelo de negocio mediante la descarga de falsos AntiVirus y AntiMalware, un esquema más que rentable: durante el 2008 algunas estimaciones apuntan a unos ingresos de hasta 10 millones de euros mensuales sumando este tipo de fraude a nivel mundial. Parece que en una segunda etapa entra el alquiler de las redes para ofrecer otros servicios.

Y es que montar y mantener este tipo de "servicios" es costoso. Sirva como ejemplo la lista del TODO para las próximas versiones de ZeuS, uno de los troyanos bancarios más extendidos:

1. Complete work in Windows Vista/2008/Seven.
2. Changing the method of intercepting WinAPI.
3. Random generation: the names of files, settings and data.
4. Console builder.
5. x64 version.
6. Support for IPv6.
7. Writing full documentation.
8. Collecting statistics using software (antivirus, firewall, etc.).
9. Interception of FireFox 3 +.

Como se puede apreciar, los cambios planteados son importantes y suponen una dedicación de horas de especialista considerable. Destacar la afectación para nuevos sistemas operativos y navegadores, así como soporte para 64 bits e implementación de IPv6. Por supuesto las mejoras responden a un beneficio esperado a partir de las mismas: el modelo de negocio no dista de cualquier otro legítimo, en este aspecto.

Vicente Díaz

S21sec e-crime

Propiedad intelectual, ¿estamos protegidos?

En este post vamos a hablar sobre la propiedad intelectual y sobre el uso indebido de la misma. Si se quiere consultar la definición de la propiedad intelectual según la legislación vigente, consultar aquí.

El objetivo principal es concienciar a nuestros lectores de la importancia y complejidad de preservar dicha propiedad. Queremos remarcar que aunque se publique una noticia, fotografía o vídeo en un medio público, generalmente, no es información libre de ser utilizada en cualquier medio o formato, sino que está protegida por propiedad intelectual. Por lo tanto en caso de querer hacer uso de dicha información o publicarla, necesitaremos el consentimiento de su autor.

Existen infinidad de ejemplos, divulgación de noticias en medios no autorizados, usos indebidos de logotipos, o divulgación de material multimedia sin el consentimiento de su autor.

¿Cómo tengo el conocimiento de que mi propiedad intelectual está protegida? Ahí está el problema. Si queremos controlar medios como la prensa escrita, televisión, son medios acotados con un número finito de lugares a controlar, se podría hacer manualmente, pero ¿qué pasa con Internet?, Internet es una gran contenedor de información (estamos hablado de magnitudes de billones de documentos) ¿Cómo nos protegemos ante este problema?, ¿Cómo sabemos que en determinados sitios no están utilizando mis contenidos?, ¿cómo sé que en cualquier foro o blog o página web en general se están utilizando (debida o indebidamente) estos contenidos? Podemos apoyarnos en buscadores, pero simplemente es insuficiente por dos problemas bien diferenciados: primero, no tienen indexadas todas las paginas de Internet, por lo que nunca podríamos encontrarlas todas, y segundo, tendremos que revisar manualmente todos los resultados devueltos por el mismo, e ir refinando continuamente nuestras consultas para alcanzar mayor cobertura. Por lo tanto existe la necesidad de utilizar servicios o herramientas que nos faciliten dicha labor de monitorización y gestión de los posibles incidentes. Queremos destacar que la complejidad de dichas soluciones ya que no es únicamente texto lo que hay que monitorizar, sino también imágenes, audio y vídeo.

Desde S21sec queremos concienciar que la información es útil, utilizable y explotable, pero eso sí, siempre dentro del marco de la legislación vigente.


José María Arce Guillén
S21sec e-crime

Protección de nuestro AP

Una de las labores de un WIDS (Wireless Intrusion Detection System) puede consistir en proteger tu propio punto de acceso, para lo que puedes controlar que no cambie de SSID, que no cambie de canal (si es que no debe) o que no utilices cifrado WEP, pero lo divertido llega cuando alguien pretende suplantar tu punto de acceso y se molesta en ponerse la misma dirección MAC, mismo SSID y mismo canal. ¿Qué hacemos ahora?

Como previamente hemos diseccionado todos los paquetes que vemos en el canal de nuestro AP, podemos realizar una comprobación de cualquier campo del mismo, y una manera más que interesante de detectar este tipo de suplantaciones consiste en comprobar la secuencia de timestamp de los paquetes correspondientes a la dirección MAC de tu AP, que deberá ser ascendente hasta que se resetee. Esto puede ser representado así:


Además, se puede mantener una comprobación adicional de la potencia de señal recibido desde dicha MAC y, dado un margen de +-10 dB, podremos indicar que nos encontramos en una situación "normal" (supongo emisor y receptor inmóviles).

En el caso de encontrar algún paquete fuera de lugar, nos podemos encontrar una situación como esta, que nos indicará que algo no marcha bien.


Esta ruptura de linealidad la podemos tratar de encontrar vigilando únicamente los últimos 3 paquetes recibidos, secuenciales en el tiempo, que llamaremos previous, last y current.


Manteniendo la información de los últimos 3 paquetes, si vemos que...

previus > last y previous < current

...llegamos a la conclusión de que algo no está bien, ya que ha habido una bajada antes de haber llegado al valor máximo del timestamp. Es mejor guardar los máximos durante un tiempo para que esta comprobación sea más efectiva, pero no es estrictamente necesario para obtener resultados.

Es un tema interesante al que merece la pena dedicarle unos minutos de "pensada".

Siguiendo con el ejemplo de los 3 paquetes puede pasar que, por ejemplo, la secuencia de timestamp del atacante sea inferior a nuestra. En este caso, en el momento en que se cuele un paquete de esa secuencia y quede situado entre dos paquetes de la secuencia original (bien instantáneamente o al desplazarlo por obtención de un paquete "bueno" más) quede rodeado por dos paquetes de nuestra secuencia, saltando así la alarma.

Para simplificar, el caso en el que la secuencia "mala" sea mayor que la "buena" puede quedar reducida al mismo ejemplo, ya que al crecer al mismo ritmo, en algún momento pasará a estar por debajo, aunque esta simplificación nos supone una pérdida de tiempo en la detección.

Técnicamente, no es infalible, ya que si consigues controlar el timestamp (muy difícil) y consigues sincronizarlo (muy difícil)... También depende del tiempo de envío de paquetes y el orden de recepción, pero las pruebas de laboratorio (con el código que se muestra a continuación) ha resultado satisfactorias.

Existen más estrategias, como controlar la tasa de beacons por segundo, que si es incrementada quiere decir que otro RogueAP está enviando beacons. El RogueAP, por supuesto, podría no enviar beacons y únicamente responder al cliente, pasando a la detección por el caso anterior.

Esto está implementado en el sistema de Protección y Vigilancia en redes inalámbricas, de la que pretendemos liberar en breve una versión de la sonda bajo licencia GPL, para que quien quiera pueda trastear con ella. ;)

Antes de terminar, quiero agradecer a mi compañero en este viaje por el mundo wireless a mi compañero Patxi por toda la labor realizada en el proyecto.

Mikel Gastesi
S21sec e-crime

No sólo de pan viven los phishers

Aunque un elevado tanto por ciento de los phishing actuales suelen tener como objetivos cualquier tipo de entidad o de organización que esté relacionada de forma directa con asuntos económicos, desde hace ya tiempo hemos ido comentando la aparición de phishings destinados a usuarios de redes sociales, principalmente motivados para obtener suficiente información personal de la persona engañada y sus contactos para realizar ataques dirigidos (spear phishing), o disponer de repositorios de ficheros donde almacenar código malicioso o datos de intercambio, o simplemente controlar cuentas personales para pedir un rescate por devolverlas; y como muestra, un incidente de la semana pasada donde se pueden observar qué redes son interesantes:

• Mensajería: AOL, ICQ, Yahoo
• Redes Sociales: FaceBook
• Intercambio de ficheros: FileFront, MegaUpload, PhotoBucket, RapidShare, UseNeXT
• VoIP: Infozech, Skype
• Webmail: Gmail, Yahoo
• Música y video: iTunes, YouTube, Sirius
• Inversiones: Vanguard

Aunque quizás lo mejor sería obtener la información personal de los asistentes de un congreso de Seguridad (BlackHat, Defcon, ...) y lamentablemente parece que es bastante fácil, como el caso reportado ayer (un CSRF) por SecureScience sobre la web de la RSA.

David Barroso

S21sec e-crime

IMS: Control de acceso, registro y autenticación. Parte II

En el post de hoy continuaremos explicando los entresijos de la arquitectura de autenticación de IMS. En el post anterior, explicamos algunos de los mecanismos utilizados para la utenticación en IMS, tales como el IMS AKA. A continuación explicaremos brévemente que es y en que consiste la GAA o "Generic Authentication Architecture".

GAA (Generic Authentication Architecture)

La GAA es la arquitectura de autenticación que hace posible extender los mecanismos de autenticación existentes en IMS a nivel de aplicación/servicio. GAA define dos tipos de implementaciones: una de ellas basada en criptografía asimétrica y PKI (SSC - Support for Subscriber Certificates) y la otra basada en la posesión de un secreto compartido (GBA - Generic Bootstrapping Architecture) que se deriva de las claves utilizadas en la autenticación AKA. De las dos alternativas, la basada en secretos compartidos es la que está teniendo mayor aceptación, al menos entre los suministradores de redes de telecomunicación, y la que está teniendo un mayor recorrido en 3GPP y está siendo adoptada por algunos servicios de OMA como OMA XDMS o el Smartcard Profile de OMA BCAST (mobile TV).

En la imagen observamos los protocolos, interfaces y especificaciones que intervinen en la GAA:

La gran ventaja de GAA/GBA es que permite la creación de "asociaciones de seguridad" entre el agente de usuario y las distintas aplicaciones. Estas asociaciones consisten fundamentalmente en compartir una clave (el secreto compartido) que permite la autenticación posterior del agente de usuario frente a la aplicación, y, si son necesarias, otras características de seguridad como la garantía de confidencialidad e integridad de la información (mediante cifrado y firma digital), no repudio (firma digital), etc. (estas últimas características son usadas, por ejemplo, por el Smartcard Profile de OMA BCAST).

Otro punto a tener en cuenta a favor de GAA es que 3GPP y OMA han especificado que ciertas aplicaciones deben utilizar GAA/GBA como marco de autenticación, no pudiendo acogerse a otros mecanismos. Esto convierte a GAA en un requisito a tener en cuenta a la hora de generar una solución que incluya autenticación.

Entrar en detalle en cada una de las especificaciones de la GAA resultaría bastante extenso, es por esto que se deja de mano del lector indagar en los detalles de éstas especificaciones.

GAA, Lyberty Alliance y el SSO o Single Sing On

El Liberty Alliance es un consorcio de empresas que se dedica a la creación de especificaciones en torno a aspectos relacionados con la autenticación, privacidad y gestión segura de las identidades de usuarios de aplicaciones "online". Uno de los conceptos manejados por este consorcio de empresas es el de SSO o Single Sign On, propiedad gracias a la cual un usuario solo necesita autenticarse una sola vez para acceder a diferentes aplicaciones/servicios.

El 3GPP ha introducido una recomendación para la combinación de GAA/GBA y los mecanismos de autenticación y SSO definidos por Liberty Alliance y SAML v2.0. De esta forma, es posible beneficiarse de una autenticación fuerte, basada en AKA, con los mecanismos definidos por SAML v2.0 y Liberty Alliance para proporcionar SSO. Esta recomendación es la TR.33980, recomendación en la que se especifican diferentes maneras de complementar la arquitectura GAA con las especificaciones del Liberty Alliance. Así pues, parece que usando alguno de los mecanismos definidos por al GAA en conjunto con los mecanismos definidos por la Liberty Alliance y SAML v2.0 se podría obtener una solución completa de gestión de la identidad en entornos IMS (en esencia, gestión del acceso y uso de aplicaciones/servicios construidos sobre la arquitectura IMS).

No obstante, la mayor desventaja de GAA/GBA es que ha sido diseñada para agentes de usuario que cuenten con soporte de algún tipo de tarjeta inteligente (la GAA asume por defecto autenticación basada en SIM). Ello origina que cuando este soporte no está disponible, las especificaciones no sean de ayuda y cada aplicación deba encontrar una solución ad hoc para su problema de autenticación de usuarios. OMA ha especificado soluciones de autenticación, por ejemplo basadas en HTTP Digest con credenciales de usuario, para terminales que no dispongan de tarjeta SIM, como por ejemplo en las especificaciones de OMA XDMS.

Además, no sólo no tiene en cuenta otros mecanismos de autenticación, sino que tampoco proporciona ninguna manera para integrar la información que a este respecto el operador podría tener ya (fruto de autenticaciones previas), no proporcionando por tanto una solución completa de gestión de la identidad.

En el siguiente post nos acercaremos un poco más a la capa de aplicación y trataremos algunas de las implementaciones existentes cara a ofrecer servicios basados en la arquitectura IMS, tales como Parlay/Parlay X.

Asier Marruedo

S21sec e-crime

RSA Conference 2009

Durante la próxima semana se celebra la RSA Conference 2009 en San Francisco, el evento de Seguridad empresarial más grande que se celebra durante el año, con más de 400 empresas que presentan sus soluciones en sus stands, y más de 17.000 personas que visitan durante toda la semana todas las soluciones que se presentan.

Realmente la RSA es la feria por excelencia de Seguridad, y es donde se vislumbra hacia donde se dirige el mercado de la seguridad durante los próximos 12 meses, puesto que todos los fabricantes se esfuerzan en tener listo todos sus nuevos productos y servicios para lanzar durante la feria las novedades del año (ante sus clientes, y sus competidores).

Además, siempre hay un especial cuidado a la hora de seleccionar las keynotes de la feria, y por ella han desfilado gente como Bill Gates, Bruce Schneier, Al Gore, o Colin Powell, entre otros. 

La RSA también sirve como punto de reunión de muchos grupos e iniciativas de Seguridad (Cloud Security, NSS, ...) y en cierta forma se parece a la semana veraniega de BlackHat+Defcon en Las Vegas, puesto que durante toda la semana muchos de los fabricantes y empresas organizan reuniones con clientes y todo tipo de invitados en diversos hoteles y pubs de la zona.

Durante toda la semana también se ofrecen numerosas presentaciones y por primera vez tenemos el placer de poder realizar una presentación en la feria; la sesión tiene como título "Common Browser Hijacking Techniques in Fraud Incidents" y tendrá el lugar el próximo Jueves a las 9:10 de la mañana.

Intentaremos cubrir el evento a través del blog y de twitter, y por supuesto, si estáis por el Moscone Center, ¡no dudéis en localizarnos!

David Barroso

S21sec e-crime

Concienciación o catastrofismo

Tras la debacle de Conficker y su famoso día de activación uno se plantea unas cuantas cosas. Están a la orden del día los artículos y posts de concienciación de los usuarios con el tema de la seguridad de sus ordenadores y redes, de hecho, yo mismo escribí algunos. La finalidad de éstos no es más que lo que se deja entrever: un intento por parte de su autor de que los usuarios de a pie, los que no saben tanto de informática como los frikis de turno, se tomen en serio ésto de la seguridad, controlen sus ordenadores, no se fíen de todo lo que circula por Internet, y sobre todo, que se den cuenta de los peligros a los que se exponen si no lo hacen. Algunos de ellos pueden parecer demasiado pesimistas, otros quizá rocen la paranoia, pero, en mi opinión, no se alejan demasiado de la realidad.

Por un lado tenemos esta concienciación, y por otro, lo que pasó con la última versión de Conficker. Casi todos los medios especializados y no especializados (por no decir todos) redactaron al menos un artículo sobre él y las devastadoras consecuencias del día del fin del mundo, el día de la activación de la función secreta del gusano, el pasado 1 de abril. Mientras en los blogs técnicos de todo el mundo se sucedían los informes y análisis de esta última versión desde un punto de vista meramente técnico, la otra parte de Internet se dedicaba a reproducir mensajes alarmistas y catastrofistas.

Ahora yo me planteo si lo que hice en su día, alarmando a los usuarios de los posibles peligros al descuidar la seguridad, no es similar a lo que ha pasado con el archiconocido gusano. Para limpiar mi conciencia, pienso rápidamente que no tiene nada que ver, nada que ver con el amarillismo de hacer sentir inseguro a medio mundo sólo por el hecho de que el gusano tuviera un día de activación, como si fuera el primero...Además, para cuando llegara el día fatídico, la mayoría de los administradores de sistemas o encargados de seguridad ya tendrían parcheados y desinfectados todos los equipos, y estarían corriendo alguno de los escáneres publicados para detectar nuevas máquinas infectadas. Desde el lado del usuario, ya casi todos los antivirus lo detectaban y el parche se distribuía de forma automática entre los usuarios de Windows.

Está claro que Conficker se ha extendido como la pólvora, y que, de haber sido la activación más íntima, rápida y efectiva hubiera ocasionado unos cuantos problemas, pero con tanto tiempo como ha habido para reaccionar, ¿por qué organizar semejante revuelo? ¿para concienciar? ¿para ganar visitas con un titular que llamara la atención? ¿para generar miedo y nuevos contratos con las compañías de seguridad? (¿estoy tirando piedras contra mi propio tejado? :p) Lo cierto es que no sé realmente cuál era su finalidad, pero lo que tengo cada vez más claro es que en este mundo hay que hacer muy poquito caso a los medios de comunicación, ser muy cuidadosos a la hora de procesar toda la información que nos llega, contrastar diferentes fuentes, etc. Desde luego ésto no sólo aplica al mundo de Internet... No os cuento nada nuevo ¿verdad? ;)

Jose Miguel Esparza
S21sec e-crime

SnortSP beta 3? o alpha -3?

Leo por casualidad que el día 1 de Abril salió una nueva versión beta de snortsp (AKA Snort Security Platform). Pensé que después de la beta 2 ya no veríamos más betas y podría aparecer algún tipo de roadmap con el que ver hacia donde evoluciona, pero no ha sido así.

Es muy complicado entender porque se le llama a snortsp beta, y lo que es peor, porque se le llama beta 3. Se ha perdido el concepto de tecnology preview o alpha completamente.. A continuación expongo un par de reflexiones acerca del estado de snortsp a día de hoy, y desde hace más de un año que está así. No he querido investigar mucho más, pero la versión beta 2 ya existía en Julio de 2008..

Para los que desconozcan que es snortsp, sirva como resumen que se trata de un sistema flexible para ejecutar snort o lo que pudiera venir.. y digo bien, porque snortsp no es snort, sino que permite ejecutar snort como un módulo más.

Desde el punto de vista purista y tecnológico se trata de un framework que permite canalizar entradas y salidas a través de analizadores, configurable (en parte) en tiempo real a través de un interfaz, que permite además la manipulación a través de scripting con Lua. Cuando se ejecuta el programa tenemos acceso a un intérprete por comandos que permite crear orígenes de datos (interfaces de red o archivos), crear analizadores, crear salidas para los datos, y enlazarlo todo para que los analizadores realicen el trabajo sobre las fuentes de datos antes de ir a las salidas.

Desde el punto de vista objetivo tecnológico, han reinventado la shell, reprogramado una, y complicado un poco más el hecho de lanzar snort, ya para ejecutarlo es necesario aprender Lua scripting, programar un objeto analizador siguiendo el estándar snortsp, y finalmente asociarlo. Siguiendo esta filosofía acabaremos enviando mails usando visual basic over telnet otra vez..

Por lo menos se incluye la opción 'no sé nada de snortsp' que hace esto de forma automática (el término esto no incluye la ejecución de snort) que se encarga de crear un engine de captura u origen de datos, un analizador de ejemplo, y los enlaza. Para que snort funcione analizando los datos a través de snortsp es necesario compilarlo (ha cambiado el código un poquito para que funcione) específicamente para ello, y crear el analizador adecuado, cambiar algunas cosas de la configuración de snort (stream4 ya no existe, así como algunos parámetros de reglas que tampoco existen de momento), y rezar, el que sepa..

Es importante leer las release notes antes de continuar este post..Se supone que snortsp va a ofrecer un mejor rendimiento ya que permite gestionar tanto los orígenes de datos como los flujos de operación de forma común y no será necesario interpretar los paquetes varias veces.. Bien, esto puede ser cierto o no, eso si, ha sido en la versión beta 3 donde han incluido la opción:

Single-threaded mode (new):  this is enabled by configure

  --enable-single-threaded.  In this mode, the framework and analytics are
"stacked" up to run sequentially in the same thread.  You can even configure
multiple stacks to run in parallel.

Hasta ahora una de las supuestas ventajas era que el modo multi-hilo mejoraba el rendimiento general de todo el programa. Ahora ya sí que no sé hacia donde van con snortsp.. Por cierto, como referencia curiosa..

Snort 2.8.2.1:

* This release is the initial port of snort to SSP.  Full integration is
underway (eg to use the SSP packet_t directly instead of converting that to
the Snort 2.8 Packet).

A día de hoy todavía se siguen convirtiendo los paquetes de formato snortsp a formato snort para que puedan ser interpretarlos..

Conclusiones:

- esta es la evolución del software..
- esta es la evolución del software libre..
- esta es una forma de buscar publicidad por parte de sourcefire..

Iñaki López
S21Sec Labs

El Cazador Fue Cazado

Uno de los eslabones más débiles de la seguridad informática tanto a nivel doméstico como a nivel empresarial es el usuario. No tenemos más que mirarnos a nosotros mismos. Dentro de nuestro ordenador tenemos numerosos documentos de vital importancia para la empresa protegidos mediante cifrado FDE en el mejor de los casos. Si estos documentos se encuentran dentro de un ordenador de sobremesa no hay mucho problema porque la seguridad de ese equipo se gestiona tanto con recursos de la propia red (firewalls,detectores de intrusiones...) como por la propia seguridad física que proporciona el recinto de la oficina o domicilio.

El problema aparece cuando el equipo a utilizar es un ordenador portátil que se expone a numerosas redes inseguras fuera de la empresarial o del hogar, o se deja en nuestro puesto de trabajo sin ninguna protección antirobo. La seguridad de los equipos portátiles no solo debe pasar por el mundo digital sino también debe hacerlo por el mundo físico. Nadie te garantiza la seguridad física de tu portátil cuando dejas tu puesto de trabajo para ir al baño o a una reunión. Menos aún cuando te lo llevas de viaje, o paras en un bar a tomar un café.

En casi todas las empresas se utilizan sistemas biométricos como detección de huellas, tarjetas RFID, etc para el acceso físico a las instalaciones. Estos sistemas nos los podemos saltar mediante la copia de huellas dactilares, clonado de los pases, o pasando los tornos detrás de un operario de la empresa (táctica “pig dig”) entre otros. Incluso el personal de mantenimiento ajeno a la organización, puede, en caso de tener una seguridad física relajada, burlarla y cometer el robo de los equipos portátiles, fácilmente disimulables.

Para proteger nuestro equipo de éstos incidentes existen varias técnicas que pasan por las más diversas de las estrategias.

Entre las más simples se encuentra la de atar nuestro ordenador a sitios más robustos mediante el uso de una pequeña cadena y un candado. Éste sistema es uno de los más primitivos y su eficacia se centra en la robustez de la cadena y la complejidad del candado.

Otra conjunto de técnicas un poco más complejas se centran en la alarma como medida antirobo, es decir, hacer sonar una alarma cuando haya un intento de robo del portatil tal y como ocurre hoy en día con los coches o en las tiendas/hipermercados. Uno de estos sistemas consiste en colocar un receptor RFID al portátil de tal forma que cuando sale de nuestra empresa sin nuestro permiso suene una alarma detectando al ladrón al instante. Existen otros centrados en sensores de golpes del disco duro para hacer sonar la alarma o avisar al usuario.

Las estrategias más complejas consisten en la geo-localización de equipos robados. Entre este tipo de estrategia tenemos la generada por Apple para los MAC que dando de alta un ID te localizan el ordenador,capturas de imágenes de pantalla, le simulan fallos del sistema para que no pueda ser vendido por internet, activación de la webcam para ver la cara del ladrón...

Como hemos visto, hay diversas formas de proteger físicamente tu portátil atendiendo a la complejidad, eficacia, coste...Pero, lo más importante, no es el portátil sino impedir el acceso a esos valiosos documentos empresariales y confidenciales que en manos inadecuadas podría causar pérdidas económicas y de imagen mucho más graves que el mero hecho de la sustracción del portátil. Para eso, tal y como se ha comentado, los sistemas de cifrado FDE resultan de enorme ayuda.

Aitor Corchero Rodríguez
S21sec labs

When a Bot master goes mad - Kill the OS

This time we are taking a close look about what things could happen with an infected computer when the running bot receives an specific command about to kill the Operating System. Not all type of bots usually have this functionality, but banking Trojans usually have. We will take three examples (InfoStealer, Zeus/Zbot and Nethell/Ambler), these are the most common Trojans where we've definitely found in their binaries the malicious code that is responsible for the Execution of Windows.

Nethell / Ambler:

Bot commands often can be observed with pure eyes in the binary as simple strings, however not as always trivial as in the case of Nethell:

Looking for the subroutine referencing to the above strings, we arrive to the code that is doing the dirty job:

mov esi, offset aCNtdetect_com ; "C:\\NTDETECT.COM"
push edi
push esi
call GetFileAttributesA
mov edi, SetFileAttributesA
and al, 0F8h
push eax
push esi
call edi
push esi
call DeleteFileA
mov esi, offset aCNtldr ; "C:\\ntldr"

The code above deletes the files NTDETECT.COM and NTLDR, before deletion, removes the Hidden/System/Read-Only attribute bits. The other botcommand, KILLWINANDREBOOT, calls this same subroutine + immediately tries to do a system reboot.

InfoStealer:

The way of InfoStealer is undoubtedly effective:

push offset aDrivers_sys ; "\\drivers\\*.sys"
push eax ; Dest
call ds:wcscat
push 1 ; hFindFile
push offset delete ; int
lea eax, [ebp+FileName]
push 98967Fh ; int
push eax ; lpFileName
call recursive_findfile
add esp, 18h
call reboot

The subroutine tries to delete each driver within the System32 directory, the first attempt is with a normal delete, in case it fails it is going to call the MoveFileEx API with the flag MOVEFILE_DELAY_UNTIL_REBOOT, which will delete the file upon startup.

InfoStealer also removes necessary registry keys for creating a logon session:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Shell = Explorer.exe
UIHost = logonui.exe
HKLM\SYSTEM\CurrentControlSet\Services\DcomLaunch\Parameters
ServiceDll = rpcss.dll
HKLM\SYSTEM\CurrentControlSet\Services\RpcSs\Parameters
ServiceDll = rpcss.dll

Zeus / Zbot:

Last but not least here comes the old Zeus. Considering that it requires the less code to execute, nevertheless it is the most aggressive and robust:

push eax

push 80000001h
call ds:SHDeleteKeyA
mov eax, ds:buffer
push dword ptr [eax+50h]
mov esi, 80000002h
push esi
call ds:SHDeleteKeyA
mov eax, ds:buffer
push dword ptr [eax+54h]
push esi
call ds:SHDeleteKeyA
push 3E8h
call ds:Sleep
xor eax, eax
push eax
push eax
push eax
push eax
mov eax, ds:buffer
push 0Eh
push dword ptr [eax+30h]
call write_read_namedpipe

It "just" deletes two kind of registry entries, but this will include WHOLE branches:

HKEY_CURRENT_USER,
HKEY_LOCAL_MACHINE\software
HKEY_LOCAL_MACHINE\system

The execution flow does not end up here. After the deletion is finished, it sends a 0E command to its pipe server, where the following code starts zeroing bytes of the virtual memory (4GB):

push 8007h
call eax ; <--- SetErrorMode, to ignore everything
xor eax, eax
mov [eax], eax
xor eax, eax ; from address 0x00000000 - 0xFFFFFFFF
loc_1: mov byte ptr [eax], 0 ; fill the memory with zeros
inc eax
jmp short loc_1

Invoking Zeus' method in our test environment resulted in a B.S.O.D (Blue Screen Of Death).

What could be the possible intention of an attacker to take the victim's computer offline? To disappear and hide all tracks, making further analysis harder? Talking about banking trojans, obviously it is not. As we have seen non of these methods lead to a significant data loss, the trojan binaries are not removed, neither registry startup entries. The point more probably for a phisher is to earn time. Taking the victim away from Internet connection - before the unwanted money transfer is realized and further actions could be taken.

Of course, knowing these informations is not proposed to give tips for anyone how to kill the Windows, indeed hope it may help to roll up some misterious case, and may help forensic analysis.

Jozsef Gegeny
S21sec e-crime

Incidentes de campeonato

Entre los incidentes relacionados con la seguridad, la relevancia normalmente va asociada a la cantidad de máquinas afectadas y las cifras estimadas de pérdidas. Sin embargo hay casos muy relevantes que han afectado a pocas personas o instituciones pero de especial relevancia.

Un caso especialmente relevante es el que sucedió entre el 2004 y el 2005 en Grecia. En Atenas, teléfonos móviles de muchas personalidades griegas fueron pinchados y sus conversaciones pudieron ser fácilmente grabadas por terceras personas. El caso da casi para una película, con supuesto suicidio incluido. Se pueden leer todos los detalles de cómo sucedió y se consiguió burlar la seguridad y ocultar las modificaciones hechas al sistema . Una lectura muy recomendable para quien no se hubiera informado del caso en su momento.

Recientemente ha surgido a la luz otro caso de película. Investigadores canadienses y británicos han investigado durante 10 meses una botnet que tenía como objetivo ordenadores del gobierno tibetano en el exilio, así como embajadas de decenas de países. El objetivo de espionaje político parece bastante obvio. Más aún teniendo en cuenta que el malware en cuestión, enviaba copias de la información de los ordenadores comprometidos a direcciones en China. Al parecer, el vector de infección más habitual eran correos falsos redactados especialmente para cada objetivo concreto (whaling). Estos correos demuestran que ha habido una labor previa de investigación de los usuarios de las maquinas a infectar. Los resultados de la investigación se han hecho públicos (1), (2) y se van descubriendo más detalles de todas la trama.

Como curiosidad, estos dos casos han coincidido con las olimpiadas del 2004 de Atenas y 2008 de Pekín. Estaremos atentos a Londres 2012.

Patxi Astiz
S21sec labs

Hola, quería darme de baja del ADSL...

Mucho se ha hablado estos últimos días del pirata informático que se dedicaba a comprometer cuentas de correo de personajes famosos, entre otros.

No voy a darle vueltas a la noticia en sí, ya que el tema es tan común que a menudo nos encontramos con este tipo de noticias. Pero quiero hacer una reflexión sobre el tema y dar una opinión. ¿Hasta qué punto estamos protegidos de los ataques de ingeniería social?

No todo el mundo es experto en seguridad informática, ni tiene por qué saber si alguien está intentando "estafarle", con lo que sería conveniente que las empresas, bancos, proveedores de correo, etc., dispusieran de más métodos de autenticación.

Llama la atención la facilidad que existe para darse de alta en compañías de telecomunicaciones mediante una llamada telefónica o impersonar a otro para hacer una portabilidad del ADSL (en el que la operadora antigua escucha de tu "voz" que te quieres cambiar).

También llama la atención cómo se puede dar de baja la luz, el gas, ... mediante un burofax o incluso por teléfono. Suena gracioso, pero estoy seguro de que le cuesta menos a la persona que intenta hacer el mal que al afectado si quisiera darse de baja.

¿Y qué se puede hacer? En primer lugar las empresas deberían usar tecnologías como la biometría para la voz para permitir este tipo de operaciones. Existe una tecnología emergente dedicada al comercio mediante la voz con el fin de que las empresas comprueben la identidad real del interlocutor. Este servicio lo ofrecen diversas empresas, entre ellas Semarket y Agnitio.

Desde S21sec también se investiga en estas tecnologías para la mejora de seguridad de nuestros clientes, participando en proyectos de investigación como el Proyecto IDENTICA.

Con el envío de faxes, burofaxes, etc., deberían adoptarse medidas similares, ya que a veces no se hace necesaria la fotocopia del DNI, sino simplemente el número de DNI (en cualquier caso, ¿en ese burofax alguien comprueba algo más que nombre, apellidos y número del DNI en una fotocopia?).

Otras soluciones, más acordes a la era tecnológica en la que nos encontramos, serían igualmente adecuadas. Códigos de un solo uso para ciertas acciones -como ofrecer un OTP a cada cliente y que marque en el teléfono el código que le aparece-, extender el uso de certificados para realizar ciertas acciones por Internet, evitar el uso de correos sin certificado para que no se pueda impersonar a cualquiera,...

Se debería concienciar a la sociedad de cómo protegerse de realizar acciones indebidas, usando métodos de autenticación seguros, y a los administradores de las empresas, para usar dichos métodos con sus empleados a la hora de acceder a recursos internos, y de este modo evitar o disminuir la fuga de datos confidenciales, accidentales o intencionados, como se menciona en este post.

De acuerdo, esto es otro paso más que realizar y mucha gente pensará: ¡vaya rollo tener que instalar un certificado o que me graben la voz!... pero allá cada uno con la responsabilidad que asume. ¡Que sea el usuario el culpable y no la empresa que ofrece el servicio!

Una pequeña reflexión final (pfff, ¿otra?). Visto que el gobierno va a tomar medidas contra el spam telefónico, y esperemos que siga en esa línea de proteger al usuario/cliente, se hace necesario crear una normativa que obligue a las empresas a evitar problemas de ingeniería social. Sobre todo para las personas mayores o aquellos que por desconocimiento sufren este tipo de ataques. De este modo se migrarán estos servicio a tecnologías cada vez más seguras. ¿Tecnologías seguras como Internet?

Miguel López-Negrete
S21sec labs

Diodos de datos

Cuando se interconectan dos redes con distinto nivel de seguridad es buena práctica establecer los mecanismos que eviten que las posibles brechas de seguridad en la menos segura puedan aprovecharse para comprometer la más segura. Supongo que ya habréis pensado en los firewalls, o eso espero.

Desde el punto de vista de la confidencialidad de datos, es necesario evitar que la información almacenada en un sistema/red donde es considerada como "confidencial" pase a otro sistema/red donde las medidas de protección son propias de información de "libre distribución". Para tratar este tipo de situaciones tenemos, los clásicos cortafuegos de nivel de aplicación que pueden realizar control de contenidos, o tecnologías más avanzadas como el DLP (Data Leakage/Loss Prevention) del que ya se habló en este post.

Existen también otras dos dimensiones de la seguridad que se deben tener en cuenta, la integridad y la disponibilidad. En el primer caso, es necesario evitar que desde la red de menor protección se pueda acceder a los datos de la red de mayor nivel de seguridad y modificarlos. En el segundo, es necesario evitar que una denegación de servicio pueda ser causada a los sistemas asociados a la red de mayor nivel de seguridad. En estos dos casos, los clásicos firewalls bien de red, o también los más complejos cortafuegos de aplicación son la solución más inmediata.

Los firewalls y los sistemas DLP son sistemas software y por tanto están sujetos a defectos de implementación o de configuración, dejando la puerta abierta a que pueden ser saltados por un atacante experto (o no tan experto), que sabe lo que hace. Cuando los requisitos en la tríada CIA son muy elevados, como es el caso de vigilar la fuga de información de entornos gubernamentales, o salvaguardar la integridad y disponibilidad de los entornos SCADA de las consecuencias de interconectar la red de mando y control con la red corporativa (revísese la idea errónea 2 de este post), se hacen necesarios otros mecanismos. Una solución drástica sería la de "la red más segura se deja aislada del mundo y si se necesita acceder a ella desde el exterior, se hace a través de mensajeros humanos". Pero existe otra solución… los diodos de datos.

Los diodos de datos, de los que podéis encontrar más información aquí, son una cosa tan sencilla como un medio físico que sólo permita tráfico unidireccional. Existen múltiples implementaciones comerciales. Unas se basan en una fibra óptica con un transmisor en un extremo y un fotodetector en el otro, mientras que otras pueden ser mucho más peregrinas, como el uso de enlaces serie RS232 donde se corta el cable de transmisión que interese (desde la red de más alto nivel de seguridad hacia la red de menor nivel, para el caso de la confidencialidad; a la inversa, para la integridad y la disponibilidad).

Algunas de las empresas que comercializan esta solución son la estadounidense OWL USA, la australiana Tenix, la francesa Thalesy o la israelí Waterfall.

A estas alturas espero que todos os hayáis dado cuenta de una cosa. ¿Qué pasa con aquellos protocolos que son intrínsecamente bidireccionales, como por ejemplo TCP? Efectivamente, si los datos, por pura limitación física, solo pueden viajar en un sentido, los mensajes de control como los ACK, los mecanismos de control de flujo para evitar la congestión de los buffers del sistema receptor, etc. quedan anulados. Esto restringe enormemente las posibilidades de esta tecnología. De todas formas UDP, que no requiere de confirmaciones ni establece requisitos propios de protocolos orientados a conexión, puede ser bastante fiable bajo condiciones muy controladas, como es el caso de enlaces punto-punto (sin colisiones), de longitud corta para evitar la atenuación en la propagación de la señal, y protegidos contra interferencias electromagnéticas externas.

Para terminar, imaginemos que queremos permitir el envío de información vía FTP de una red segura hacia otra no segura/no confiable. Supongamos que queremos utilizar la tecnología de diodo de datos para estar seguros al 100% de que no se podrá aprovechar una vulnerabilidad del servidor de FTP para tener acceso al resto de sistemas de la red de alta seguridad. A priori esto parece imposible puesto que FTP funciona sobre TCP. No obstante, existe una solución. Podríamos integrar un agente cliente FTP en el extremo transmisor y un servidor FTP "fake" en el extremo receptor del diodo de datos. El agente cliente, estará situado en la red de mayor nivel de seguridad, y se conectará periódicamente para descargar a local los ficheros del servidor FTP legítimo. Cada vez que se descarga un fichero se transmite a través del diodo mediante un protocolo unidireccional, que suele ser propietario, hasta el servidor FTP integrado en el extremo receptor del diodo. Este servidor FTP "fake", estará en el extremo inseguro del diodo, es decir, en la red de menor nivel de confianza. Así, los clientes FTP legítimos se conectarán contra este servidor "fake" y tendrán acceso a aquélla información que desean descargar.

Elyoenai Egozcue,

S21sec labs