Español | English
rss facebook linkedin Twitter

Reto 4

Tras un pequeño periodo de descanso, volvemos con los retos.

Pasamos de un crackme tedioso a uno sencillito para que se anime todo el mundo.

Es un crackme implementado en masm, sin ofuscación, y con un par de trucos antidebug, pero que no ofrecerá ninguna resistencia a la mayoría de vosotros.
Como es tan sencillo, esta vez será necesaria la realización de un keygen (generador de claves) para que la solución sea tomada como correcta.

Dejamos un plazo de dos semanas para el envío de la solución ( 16 de marzo), y el que envíe la solución más completa/detallada/amena/interesante se llevará una copia del libro Hacking Exposed Wireless, para cambiar un poco la temática ;)

Podeis descargaros el crackme desde aquí

Enviad tanto la solución como cualquier duda/sugerencia a labs@s21sec.com

¡Suerte!

Mikel Gastesi
S21sec labs





Donde los scanners de vulnerabilidades no llegan – III

“In banner we trust”


La mayoría de los scanners confían en la información recibida en los banners de los servicios para determinar la presencia o no de una vulnerabilidad.

Como hemos comentado anteriormente, la detección de una vulnerabilidad la mayoría de veces se realiza a partir de la estimación de la versión del software utilizado. Si se estima una versión concreta y esta se encuentra catalogada como vulnerable, el servicio se marca como vulnerable sin llegar a confirmar si la vulnerabilidad existe realmente.

Los fabricantes alegan las siguientes razones para hacerlo así:
  • Simplicidad.
  • Evitar los posibles DoS (Denegación de Servicio) que podría provocar la explotación activa de la vulnerabilidad.
  • Muchas vulnerabilidades carecen de PoC (Prueba de concepto) que permitan confirmarlas.

Pero este enfoque presenta dos grandes problemas:
  • Los banners pueden ser modificados/falseados/malinterpretados: El banner de texto de la mayoría de servicios puede ser ocultado y/o alterado, de forma que la confianza que se puede tener en el mismo es minima. Para colmo, la heterogeneidad de los banners según cada fabricante hace que no sea raro encontrar situaciones en las que el scanner malinterpreta la versión publicada.
  • Las bases de datos de vulnerabilidades suelen estar incompletas: Sobre todo en el caso de software poco habitual como veremos más adelante. Por ejemplo es clásico ver descripciones muy amplias del alcance de una vulnerabilidad, por ejemplo: "Las versiones anteriores a la 4.26 son vulnerables", pero sin dar más detalles. De forma que al desarrollador del scanner se le plantean una serie de dudas: ¿las versiones 3.x son vulnerables? ¿Y las 2.x de hace 6 años que ya nadie usa y que nadie se ha molestado de estudiar, son vulnerables? Según sea el criterio del programador del scanner, tendremos entonces una respuesta más o menos atrevida, y muchas veces desacertada.

Hasta la próxima entrega!

Ramón Pinuaga
Departamento de Auditoría






Massive DoS?

Hay que tener cuidado con lo que se desea… no vaya a ser que se cumpla.

Esto es lo que deberían pensar los dirigentes del Pakistán cuando quisieron “erradicar” las comunicaciones con el conocidísimo portal YouTube.

Dichos dirigentes, decidieron que los contenidos de este popular portal no eran lo suficientemente buenos para ser visualizados por sus conciudadanos por lo que pidieron su prohibición a los proveedores de Internet (ISP).

El problema vino cuando ignorando lo que se podría venir un entusiasmado ISP decidió que la mejor forma de cumplir con lo dictado por los dirigentes era redirigir el tráfico de este portal a cualquier otra IP con contenidos “más apropiados”.

La primera consecuencia… YouTube desapareció de Internet por lo menos una hora, y mientras seguían trabajando para poder arreglar semejante “entuerto”, desde PCCW no tuvieron más remedio que “apagar” la red de Pakistán de Internet.

Resumiendo, un DoS masivo que afectó a un país entero.

Más información aqui.

José María Arce Guillén
S21sec labs






Más seguridad para el protocolo HTTP (II)

Hace aproximadamente un mes, comentábamos el esfuerzo por parte de la IETF de reforzar la seguridad del protocolo HTTP con la creación de un borrador. Entonces ya indicamos que se trataba de un borrador inicial y estaba incompleto, y así es, siguen trabajando en él. La anterior url ya no está disponible, ahora podemos encontrar la nueva versión en Security Requirements for HTTP.

¿Por qué es importante este tipo de documentos?

Actualmente las aplicaciones basadas en web se estan volviendo cada vez más sofisticadas y vitales para los negocios online creando así nuevos riesgos de seguridad. Este tipo de documentos ayudará a los desarrolladores web y analistas de seguridad a tener una visión más detallada de los riesgos subyacentes.

Emilio Casbas
S21sec labs





Fiberparty 2008

Este viernes, 29 de febrero, Joan Ayerbe, manager de consultoría de S21sec, ofrecerá una ponencia titulada “Transformando los datos en información útil para el negocio” en las conferencias FIST que se celebrarán dentro de la Fiberparty 2008.

Las conferencias se celebrarán en la Facultat d'Informatica de Barcelona – UPC.

Podéis consultar aquí la agenda y más datos sobre la localización. Para asistir, solo tenéis que inscribiros. ¡Esperamos veros por allí!






Datos personales, direcciones IP y los movimientos de Google (III)

En relación con esta serie de posts, 1 y 2, hemos de indicar que Google ha dado un nuevo paso. Y el Grupo del Artículo 29 también.

Por otra parte, gracias al blog de Samuel Parra he accedido a esta interesante resolución de la AGPD en la que se decide que dada la posibilidad de modificar una dirección IP no se puede determinar con exactitud que un usuario de una red local, haciendo uso del equipo informático que la empresa le tenía asignado, fuera quien publicó en una página web datos personales contenidos en un fichero responsabilidad de aquélla.

Una buena monitorización y gestión de "logs" podía haber ayudado a esta empresa a evitar la interpretación hecha en la jurisdicción social.

Álvaro Del Hoyo
Departamento de Consultoría





S21SEC-040-en: Infinite invalid authentication attempts possible in BEA WebLogic Server

##############################################################

- S21Sec Advisory -

##############################################################

Title: Infinite invalid authentication attempts possible in BEA WebLogic Server
ID: S21SEC-040-en
Severity: Medium
Scope: BEA Weblogic
Platforms: All
Author: rpinuaga@s21sec.com
URL: http://www.s21sec.com/avisos/s21sec-040-en.txt
Release: Public



[ SUMMARY ]

It's possible to launch a credentials brute force attack against known
users through an internal servlet that permits the bypass of the user
locking mechanism.


[ AFFECTED VERSIONS ]

The vulnerability was confirmed on:
7.0sp6
8.1sp4
9.0sp2

Versions 6 and previous are not vulnerable.


[ DESCRIPTION ]

BEA WebLogic Server is the world leading application server software.

To avoid credential brute force attacks, Weblogic server have a locking
mechanism that lock the corresponding account after some invalid login
attempts.

The default lock shots if 5 invalid login attempts were made. The lock
remains 30 minutes.

S21SEC has found that exists an internal servlet that allow the guess of
valid credentials even if the attacked account is locked.

This allows infinite invalid authentication attempts against an account.
When the correct credentials are guessed, it's only needed to wait for the
account to unlock and then logon into the server.

The affected servlet is:

/wl_management_internal1/LogfileSearch (Version 7 & 8)
/bea_wls_diagnostics/accessor (Version 9)


[ WORKAROUND ]

BEA has released an advisory about this vulnerability. Updates and more
information are available at Bea website:

http://dev2dev.bea.com/pub/advisory/271

[ ACKNOWLEDGMENTS ]

This vulnerability has been found and researched by:

Ramón Pinuaga Cascales


[ REFERENCES ]

http://dev2dev.bea.com/pub/advisory/271





Afinando la puntería

Desde hace ya algún tiempo a nadie en su sano juicio se le ocurre abrir correos electrónicos ni visitar páginas de dudosa reputación. En primer lugar porque cada vez somos más desconfiados ante posibles situaciones de riesgo, y en segundo lugar porque muchas veces los correos que nos llegan tienen un formato estándar y es fácil adivinar qué correo puede ser maligno o su traducción es bastante deficiente, lo que nos alerta del peligro que conlleva.

Para tratar de paliar esta parte, los creadores de malware se dedican a contratar "traductores". Ya sabemos que no es nuevo este interés por mejorar las capacidades del malware en todos los aspectos. Lo que ahora les lleva a mejorar el lenguaje es el hecho de las posibilidades que ofrece, ya que aumenta la cantidad de personas que pueden caer en el engaño.






De momento la cosa mejora lentamente, pero es más que posible un aumento de spam o programas maliciosos en un perfecto idioma nativo de los posibles objetivos, y es que cada vez más el malware se hace sofisticado y esta es una de las ramas menos explotadas hasta ahora.

¿Se divisa a lo lejos la creación de malware personalizado para cada objetivo? ¿Qué dificultades supone eso ahora para los creadores de malware y qué inconvenientes para el futuro a la hora de acabar con ese malware?


Miguel López-Negrete
S21sec labs





¿Tomamos en serio la virtualización? (III)

Al hilo de las noticias anteriores relacionadas con las seguridad en entornos virtuales (parte I, parte II), ha salido una vulnerabilidad en VMware que permite el acceso desde una máquina virtual Windows (guest) a crear y modificar ficheros en la máquina real (host) si se usan las carpetas compartidas (Core Security dixit).

No me extrañaría ver dentro de poco a malware capaz de explotar esta vulnerabilidad afectanado a todos los profesionales de la seguridad que se dedican a analizar malware en máquinas virtuales, o a la gente que utiliza una máquina virtual para otro tipo de cosas. ¿Existe algún virus que sea capaz de infectar ficheros dentro de una máquina virtual desde el host?

¿Cómo gestionáis la actualización de software de virtualización cuando las máquinas virtuales que corren están en producción?

David Barroso
S21sec labs





No des tu password

La gestión de cuentas/contraseñas de usuarios, que comprende aspectos como eliminar o modificar cuentas de usuarios que cambian de puesto dentro de una misma compañía, o modificar el nivel de acceso de un usuario con su cuenta, es una tarea a la que a menudo no se le da la importancia que le corresponde.

Al tratarse de una tarea algo repetitiva, en teoría sencilla, debido a algún descuido, puede ocurrir que no se realice correctamente (dejarse cuentas viejas activas etc.). Además, hay que añadir que en algunas ocasiones son los propios usuarios del sistema los que lo comprometen al facilitar la contraseña de su cuenta.¿Quién no ha
visto o conocido la situación en la que un compañero de oficina se va de vacaciones y tiene que dejar su password a otro para realizar una tarea en concreto?.

Todos estaréis pensando que lo que digo no es nada nuevo, pero ante casos como lo ocurrido con el banco frances Société Générale creo que es necesario sacar el tema a la palestra. Si una entidad financiera tan importante como esta última (a la que se le supone que cuenta con unas medidas de seguridad importantes) ha descuidado tanto este aspecto, ¿que es lo que estará ocurriendo en otro tipo de compañías?

Es necesario pues, para que una compañía funcione con unas garantías mínimas de seguridad, por un lado concienciar a los usuarios (mi contraseña es mía y de nadie más) y por otro, llevar un control exhaustivo de quien puede entrar y que puede hacer dentro del sistema.



Asier Marruedo
S21sec labs






Donde los scanners de vulnerabilidades no llegan – II

Servicios UDP

La mayoría de los scanners no son capaces de analizar y detectar correctamente vulnerabilidades en servicios UDP.

Esta es tal vez la deficiencia más flagrante de este tipo de programas, ya que es un problema técnicamente solucionable. Aunque la concepción clásica de estos scanners no se adapta bien a este tipo de servicios.

El proceso de trabajo clásico de un scanner de vulnerabilidades es:

  1. Explorar los puertos abiertos.
  2. Determinar el tipo de servicio y la versión del software utilizado (normalmente a través del banner).
  3. Determinar si el servicio o la versión del software esta afectado por alguna vulnerabilidad.
  4. Presentar un informe de lo encontrado.

El problema es lo que los puertos UDP no permiten determinar claramente su estado:

http://en.wikipedia.org/wiki/Portscanning#UDP_scanning

Básicamente cuando probamos un puerto UDP solo nos responderá con un paquete ICMP_PORT_UNREACHABLE si el puerto esta cerrado. Si no recibimos ese paquete, podemos estar ante 2 situaciones: el puerto esta abierto o el puerto esta filtrado. No podemos diferenciar a priori si el puerto esta filtrado o abierto.

La única forma de determinar de forma fiable si un puerto UDP esta abierto y existe un servicio accesible, es utilizar una petición especifica de cada protocolo concreto y esperar una respuesta en ese protocolo.

Algunos scanners incluyen pruebas simples para protocolos UDP habituales: DNS, SNMP, IKE.

Pero estas pruebas solo se realizan contra el puerto por defecto: DNS(53/udp), SNMP(161/udp), IKE(500/udp). Si el número de puerto ha sido cambiado, el scanner será incapaz de detectar correctamente el servicio y por lo tanto de determinar si presenta vulnerabilidades.

Algunos pensaran, "bueno, los servicios UDP son marginales", pero están lejos de la realidad. Aquí tenéis por ejemplo una lista de servicios UDP que son ampliamente utilizados:

  • DNS = 53/udp
  • TFTP = 69/udp
  • NNS (NetBIOS Name Service) = 137/udp
  • SNMP = 161/udp
  • IKE = 500/udp
  • NTP = 123/udp
  • BOOTPS/DHCP = 67/udp y 68/udp
  • SUNRPC = 111/udp
  • SYSLOG = 514/udp
  • RIP = 520/udp
  • RADIUS = 1812/udp
  • RTSP (Real Time Streaming Protocol) = 554/udp
  • Clientes P2P = Unos cuantos
  • L2TP = 1701/udp
  • HSRP (Hot Standby Router Protocol) = 1985/udp

A que más de uno os suena...

Ramón Pinuaga
Departamento de Auditoría





Donde los scanners de vulnerabilidades no llegan – I

Introducción:

Un scanner de vulnerabilidades es un programa informático diseñado para buscar debilidades en una aplicación, un ordenador o una red.

Tras unos primeros años en los que los análisis de vulnerabilidades se realizaban prácticamente de forma manual, aparecieron los primeros scanners de vulnerabilidades que automatizaban y estandarizaban este tipo de trabajos. Se establecieron en el mercado una serie de competidores que fueron mejorando y ampliando sus productos, hasta conformar un catálogo de opciones relativamente atractivo para los auditores de seguridad.

Pero desde hace unos años, la evolución se ha detenido. Los productos son prácticamente los mismos que hace 5 años. La tecnología es la misma. Y las carencias que tenían siguen ahí, nadie mejora...

En esta serie de artículos realizaremos un análisis de los scanners de vulnerabilidades genéricos (También conocidos como scanners de vulnerabilidades de red). Existe una rama especializada en el análisis de vulnerabilidades de aplicaciones Web, este tipo de scanners son mas recientes y su forma de funcionar es muy diferente ya que se orientan a las características típicas de las vulnerabilidades Web. Tal vez hagamos también una pequeña comparativa de estos productos en otra serie.

Hasta la próxima!

Ramon Pinuaga
Departamento de Auditoría





Inteligencia artificial - Un poco de historia y su uso para fines fraudulentos.


La “inteligencia artificial” es algo que está muy de moda últimamente, y prueba de ello es que encontramos referencias sobre inteligencia artificial desde casi cualquier disciplina incluyendo por supuesto la seguridad informática. Cuando pensamos en inteligencia artificial nos viene a la cabeza máquinas avanzadísimas que imitan a los humanos tanto en apariencia física como en comportamiento llegando incluso a superar las capacidades de éstos.


Sin embargo, la realidad de la inteligencia artificial actualmente persigue otras tareas como por ejemplo la clasificación automática de datos, la explotación de forma automática de grandes volúmenes de información, el reconocimiento de imágenes o reconocimiento del lenguaje natural que a pesar de representar logros muchas veces sorprendentes, quedan lejos de la ciencia ficción y de los humanoides inteligentes que vemos en las películas.

Fue ya el que conocemos como el padre del ordenador moderno y en cierta forma también precursor de lo que hoy conocemos como inteligencia artificial (Alan Turing) el que propuso en 1950 en un artículo en la revista Mind, las bases para identificar inteligencia en una máquina. A ésto se le conoce como el test de Turing y que básicamente consiste en un reto: se pone a una persona, sin avisarle, a chatear con una máquina y, si la persona no es capaz de distinguir si su interlocutor es humano o máquina, entonces se entiende que la maquina tiene en cierta forma un comportamiento inteligente. Esto motivó que las primeras aplicaciones relacionadas con la inteligencia artificial fueran precisamente robots de conversación en modo texto, los conocidos como chatbots. Las primeras propuestas datan de hace mucho tiempo como ELIZA (1966). Desde entonces ha llovido mucho y obviamente los chatbots han evolucionado hasta el punto que se han creado herramientas comerciales que se integran , por ejemplo, en páginas web para ayudar y solucionar dudas técnica rápidamente o como ayuda a la navegación. Un ejemplo de estos asistentes es el famoso clip de Microsoft Office o la cyber-dependienta de la tienda de muebles IKEA.

Como podemos ver buscando por internet, los chatbots son muy populares, existen multitud de ellos. Incluso existe un premio, el Loebner Prize, que año a año premia a los chatbots que mayor comportamiento humano tengan. Escribiendo estas líneas no puedo evitar referenciar algunos intentos fallidos de robots de conversación que propiciaron alguna divertida anécdota. Por ejemplo el Santa Claus que Microsoft puso en el msn-messeger las pasadas navidades y al que al final tuvo que "matar" por aprender a decir cosas que no debía, o también el orientador sexual para jóvenes del ministerio de sanidad que al final también fue desconectado porque más que orientar desorientaba.

Por último, desde este post no podíamos dejar pasar la oportunidad de hacer mención al uso de estas tecnologías por parte de los “chicos malos”. Una de las últimas producciones de los creadores de software malicioso rusos es el cyberlover, que no es más que un chatbot que actúa en los canales de ligue de los IRC y que intenta seducir a los usuarios conectados para intentar dirigirlos a supuestas páginas personales en las que en vez de encontrar fotos y otro tipo de contenidos prometidos conseguimos infectar nuestro equipo con código malicioso. En fin, otro motivo más para desconfiar de los interlocutores en los canales de IRC.

Guzmán Santafé
S21sec labs







¿Qué haces hijo? -Estudiar matemáticas papá-

...mientras tanto, al otro lado de la habitación...

young
Si ahora convierto 216.163.137.3 a binario obtengo 11011000 10100011 10001001 00000011 ahora lo transformo a decimal y me queda 3634596099 que pasándolo finalmente al sistema hexadecimal ya tengo d8a38903, esto es, http://0xd8a38903
-----------

Existe gran cantidad de información disponible sobre esta técnica de ofuscación de urls aprovechándose del desconocimiento de su estructura, pero, ¿cuál es la base de todo esto?. Gran parte, se debe a las diversas implementaciones que se realizan a partir de una especificación estándar.

Sección 7.4 del RFC3986
[..]
Adding further to the
confusion, some implementations allow each dotted part to be
interpreted as decimal, octal, or hexadecimal, as specified in the C
language (i.e., a leading 0x or 0X implies hexadecimal; a leading 0
implies octal; otherwise, the number is interpreted as decimal).

These additional IP address formats are not allowed in the URI syntax
due to differences between platform implementations. However, they
can become a security concern if an application attempts to filter
access to resources based on the IP address in string literal format.
[...]

Se podría tratar como un viejo y conocido bug en múltiples navegadores que interpreta erróneamente los nombres de host numéricos como direcciones IP.

El caso es que, hasta ahora, este tipo de ambigüedades venía siendo explotada por spammers y phishers como método de ofuscación de urls. Pero últimamente, se está viendo su uso por jóvenes en grandes ISPs con sistemas de filtrado de contenidos. ¿Quién dijo que las matemáticas no servían para nada?

Afortunadamente, parece que este tipo de debilidad, será reforzada o solucionada de alguna manera a partir del nuevo borrador para la seguridad del protocolo http, del cual ya indicamos su existencia anteriormente.
"Many users do not understand the construction of URIs [RFC3986], or their presentation
in common clients [...]. As a result, forms are extremely vulnerable to spoofing."
Mientras esto llegue, podremos seguir viendo urls como:
http://216.0xa3.137.3/
http://216.10717443/
http://0xd8a38903/
http://033050704403/

Lo de los jóvenes saltándose sistemas de filtrado a través de esta técnica podría quedar como mera anécdota si lo comparamos con los riesgos actuales de XSS y CSRF, más peligrosos de lo que la gente quiere creer.

Emilio Casbas
S21sec labs





Datos personales, direcciones IP y los movimientos de Google (II)

Peter Fleischer, responsable de privacidad para Europa de Google, ha publicado un nuevo post en su blog personal acerca del debate sobre la consideración o no de las direcciones IP como datos de carácter personal.

Expone los mismos argumentos en contra del carácter personal de las direcciones IP que exponía yo en nuestro anterior post sobre este tema, pero sigue olvidándose de tomar en cuenta que los buscadores de Internet, proveedores además de otros muchos servicios de la Sociedad de la Información, adquieren cantidades ingentes de datos que relacionan o pueden relacionar con los identificadores únicos que asignan a los navegadores de sus usuarios y que se recopilan junto con las direcciones IP fijas o dinámicas que estos emplean.

Parece que Peter Fleischer declaró que "there is no black or white answer: sometimes an IP address can be considered as personal data and sometimes not, it depends on the context, and which personal information it reveals" y quizás sus propias palabras le estaban dirigiendo a la respuesta que no espera recibir del Grupo del Artículo 29.

Me temo que próximamente todos los buscadores de Internet se van a llevar un par de jarros de agua fría en forma de Dictamen del Grupo del Artículo 29: uno, sobre el uso de "logs" y "cookies" y, otro sobre publicidad contextual. Aparte de la que se le pueda venir encima en términos de privacidad a Google en relación con la compra de Double-Click.

En cualquier caso, sí que estoy de acuerdo con Peter Fleischer en destacar los problemas que trae consigo la consideración de las direcciones IP como datos de carácter personal en relación con el deber de información, el principio de consentimiento, ya sea para el tratamiento o para la cesión de las direcciones IP, o con las transferencias internacionales de estos datos o con el ejercicio de derechos de acceso, rectificación cancelación y oposición.

Pensemos por ejemplo en el tratamiento que de los datos de tráfico -las direcciones IP lo son- están habilitados los ISPs a llevar a cabo para la gestión de la seguridad de sus servicios y redes (ver artículo 4 de la Directiva 2000/58/CE) o en el tratamiento de direcciones IP que hacen los CERT para la vigilancia de la Red y la defensa organizada contra el ciberterrorismo o ataques a gran escala contra los usuarios de la Red.

¿No sería mejor que los ISPs no necesitaran de consentimiento para la cesión entre operadores para combatir de forma conjunta ataques distribibuidos, el "spam" o el "phishing"? ¿Realmente no sería beneficioso que un CERT quede excepcionado de cumplir con los principios de transparencia, consentimiento y cesión con respecto a las direcciones IP que tratan?

Veremos en qué resulta finalmente todo este debate.

¿Alguna modificación en ciernes de la regulación europea de la privacidad?

Álvaro Del Hoyo
Departamento de Consultoría





Skype

Skype is getting more and more famous and the among of users is rapidly increasing. Mainly because it is the first well working VoIP software where one can make free phone calls over the Internet. Even video conferencing is available on Windows and MacOSX, and recently added to the Linux port.

But not only in the private environment Skype gets more and more famous. Even companies use the software to hold meetings via video conference and have a company wide communication platform. This is a reason to look at the security of Skype.

Skype uses for communication and speech forwarding the ports 80 and 443 (http and https). If these ports are prohibited Skype has no problem to work behind NAT routers or to drill holes into the corporate firewall. This is done by the STUN protocol and tricky procedures to allow UDP packets passing Statefull Firewalls.

Generally Skype works as a peer-to-peer network. Data is not only transferred directly with the communication partner, but also over other Skype nodes. And not only communication, also the contact list for Skype is distributed to many computers of other Skype users.

If the user has a fast Internet connection (>256k upload) and is long-term connected; he will become automatically a Supernode. Then, not only contact data of others is stored in the computer, also telephone calls are routed through these Supernodes. Until now this behaviour can be disabled.

To protect the privacy of their users Skype uses encryption with AES-256. Everything which can be found about the security implementation of Skype is a study which is paid from Skype itself! This document states that the AES implementation is standard conform and well done.

However, Skype is closed source and nobody can have a look into the source code. Skype even has techniques to avoid debugging and reverse engineering.

The fact that this implementation is not as compliant as proposed shows a document which appeared in the German press. In this document the German company DigiTask offers to the German government a product to sniff and decode Skype VoIP traffic.

Generally one should consider using alternatives like wengo or gizmo which provide the same functionality like video conferencing and encryption with AES - the main difference is that they are Open Source and everybody can verify the proposed security.


Clemens Kurtenbach
S21sec Labs





Marzo, el Reto de la adecuación a la normativa de desarrollo de la LOPD 15/1999 tras la aprobación del Real Decreto 1720/2007

De cara a la próxima entrada en vigor del Proyecto de Real Decreto por el que se aprueba del Reglamento de Desarrollo de la Ley Orgánica 15/1999 de 13 de diciembre de Protección de Datos de Carácter Personal, queremos proponer a los bloggers, lectores y editores de este blog un calendario con los post a publicar sobre esta temática para prepararnos ante la inminente entrada en vigor del texto el próximo 19 de abril.


El calendario propuesto tratara sobre los siguientes temas:
  1. Procedimiento para la Autorización de Conservación de Datos para fines Históricos y Estadísticos (Título IX Capitulo VII Sección Segunda)
  2. Medidas Aplicables a los Ficheros y tratamientos no Automatizados de Datos (Título VII Capitulo IV)
  3. Novedades en la Gestión de Soportes y Documentos Art. 92, 97 y 101 (Título VIII Capitulo III)
  4. Regulación de la función de auditor LOPD de acuerdo al Art.106 (Título VIII Capitulo III)
  5. Disposiciones Generales de las medidas de Seguridad en el Tratamiento de Datos de Carácter Personal. La figura del encargado del tratamiento (Título VIII Capitulo I)
  6. Novedades para los Niveles de Protección
  7. Transferencias Internacionales de Datos y códigos tipo (Título VI Título VII)
  8. Datos especialmente protegidos frente a la aplicación del los niveles de seguridad de acuerdo al Art. 81.5.

Os invitamos a participar mediante comentarios en este foro que pretende resolver o al menos dar una visión y una interpretación a las controversias que plantea el nuevo texto.


David Imizcoz Etxeberria
Manager de Consultoría





Haciendo imposible lo fácil

Somos humanos, y por ello tenemos una tendencia innata a complicarnos la vida más de los necesario. Sirva este ejemplo ilustrativo donde una persona tiene en su casa dos (2) ordenadores.
Para compartir archivos entre ellos tiene muchas posibilidades, desde las más sencillas como activar compartir archivos y carpetas con unos cuantos clicks de ratón (incluso en linux/Unix si se usa KDE, Gnome o similar), pasando por activar NetBIOS/Samba/NFS como administrador, poner servidores FTP, añadir un sistema gestor de cuentas para todo lo anterior, ya puestos un servidor LDAP, y asi "ad infinitum"; nuestra capacidad de complicar las cosas es enorme.
Este escenario me recuerda mucho a los "Inventos del Profesor Franz de Copenhagen" del antiguo TBO, donde para abrir un huevo y freirlo usaba complicadísimos sistemas de poleas, motores, cuerdas, y cachivaches. Por supuesto nunca monté ninguno, pero estoy seguro que algunos de esos diseños tenían errores y no funcionaban.
Lo mismo le pasa a la persona del ejemplo, quiere compartir archivos y carpetas entre dos ordenadores y conforme va complicando las cosas llega un momento en que falla y no se sabe por qué. Incluso puede que tenga un fallo de seguridad por que los diferentes servicios que usa tienen una incompatibilidad de configuración, o simplemente por que no sabe al 100% lo que está haciendo o pasando realmente. Si quiere instalar un servidor web personal, le hace realmente falta un apache completo con php/perl/RoR, bases de datos y sus conectores, configurar permisos, acls, ldap y un sin fin más de cosas y configuraciones o le basta con un servidor pequeñito con un solo fichero ejecutable y dos más de configuración restringido a un único directorio.
Ésto es solo un ejemplo extrapolable a otras muchas facetas de la informática, donde se van creando monstruos que resuelven un único problema de solución simple. Ahora me viene a la cabeza un ejemplo sobre la programación, que cuando nos encontramos un problema y no sabemos seguir solemos decir "Esto me lo va a solucionar otra clase o función que programaré luego." y cuando llegamos a tener que escribir esa nueva clase/función que nos va a solucionar el problema anterior vemos que genera otro u otros problema adicionales que resolvemos... añadiendo más clases/funciones. Al final necesitamos un topólogo para que nos explique qué estructura y relaciones tiene la jerarquía de clases de nuestro propio programa.

Resumiendo: No hacer imposible lo fácil, es más sencillo... y seguro.

Eduardo Morrás
S21secLabs





Redes P2P, datos personales, ilícitos civiles, delitos y seguridad de la información (II)

En el anterior post comentábamos la sentencia del caso 275/06 del TJCE y adelántabamos el contenido de este nuevo post.

Como constata el TJCE no existe en España norma alguna que obligue a los operadores a comunicar los datos personales de sus clientes en el marco de un proceso civil de cualquier tipo ni en concreto con la finalidad de la protección de los derechos de autor. O al menos de momento, pues aunque sea por la inercia tomada en otros Estados europeos incluso puede que también vayamos más allá de una regulación que obligue a los ISPs a ceder los datos personales de sus clientes usuarios de redes P2P como ya está sucediendo en algunos Estados europeos.

En Francia se ha optado por un modelo voluntario de colaboración de los ISPs con las sociedades de gestión de derechos de autor, a la espera de que llegue la ley que regule esta invasión de los derechos a la intimidad, al secreto de las comunicaciones y a la protección de datos, además de a las libertades de expresión y de información. El objeto de estos acuerdos es el filtrado de la navegación de los usuarios de Internet para el bloqueo del acceso a las redes P2P. Este filtrado ha sido puesto por los ISPs en manos de terceros, cuya actividad parece ser está y seguirá estando celosamente supervisada por la CNIL, en especial en lo que atañe a la obligación de que las direcciones IP se hagan anónimas inmediatamente durante el filtrado. De las dos inspecciones realizadas hasta la fecha en una de ellas ya se ha encontrado al encargado del filtrado registrando las direcciones IP para una sociedad de gestión de derechos de autor.

Ante el fracaso de las negociaciones entre las sociedades de gestión de derechos de autor y los ISPs británico para establecer un sistema similar al ya existente en Francia, parece que la semana que viene se presentará en el Reino Unido una nueva ley que obligará a los ISPs a trazar las comunicaciones de sus clientes, de modo que en caso de que se detecte se está haciendo uso a redes P2P habrán de remitir por dos veces una advertencia de cese que en caso de no ser atendidas implicará la interrupción del servicio de acceso a Internet. Los datos identificativos y otros datos personales de los usuarios infractores podrán ser cedidos a los tribunales. Es preciso recordar que en el Reino Unido no se halla establecida la limitación de copia privada, siendo el uso de redes P2P en todo caso una infracción civil.

No obstante, en el Reino Unido la obligación de ceder los datos para procesos civiles ya existe gracias al Common Law puesto que ya se dio una resolución de la High Court que obliga a los ISPs a trazar las comunicaciones de aquellos de sus clientes -"uploaders" masivos- como consecuencia de la Regulation of Investigatory Powers Act (RIPA).

En Estados Unidos el Common Law nos ha ofrecido una resolución que establece exactamente lo contrario, si bien indicando como responsable para este tipo de autorizaciones al Congreso, razón por la que es previsible que puedan darse los mismos pasos que en Europa.

En cualquier caso, al respecto de estas futuras leyes francesa y británica, quisiera recordar la existencia de las exenciones de responsabilidad de los prestadores de servicios de intermediación establecidas en los artículos 12 a 14 de la Directiva 200/31/CE, así como que el artículo 15 de esta Directiva prohibe expresamente a los Estados miembros imponer una "obligación general de supervisar los datos que transmitan o almacenen, ni una obligación general de realizar búsquedas activas de hechos o circunstancias que indiquen actividades ilícitas" a los prestadores de servicios de transmisión de datos por redes, servicios de acceso a redes, servicios de almacenamiento automático, provisional y transitorio de datos para su transmisión ("caching") y servicios de almacenamiento de datos. En cualquier caso los prestadores de servicios de intermediación podrán ser requeridos conforme a Derecho por los órganos judiciales y administrativos competentes a poner fin o impedir infracciones y tendrán el deber de colaborar en la interrupción del servicio o la retirada de contenidos ilícitos. Este régimen de responsabilidad fue transpuesto al Derecho español por el Capítulo II del del Título II de la LSSI.

Debates aparte sobre la ilicitud civil y la tipicidad del uso por particulares de redes P2P, lo que sí quisiéramos precisar es que en el caso de la descarga por personas jurídicas tanto de programas de ordenador como de bases de datos o de cualquier otro tipo de obras sí que estamos ante una infracción civil y un acto de competencia desleal, aparte de que por lo general se podría estar incurriendo en la comisión de un delito contra la propiedad intelectual al acceder ilegítimamente a informaciones, programas de ordenador o bases de datos que puede que puedan ser empleados en los procesos productivos de la organización por las personas que trabajan para ella (por tanto, con fines comerciales). Aparte las redes P2P consituyen un importante vector para posibles infecciones por códigos maliciosos, fugas de información culposas o por error o la comisión de delitos de posesión o distribución de pornografía infantil, así como para la infracción de la buena fe o el abuso de confianza por parte de los trabajadores de la empresa. Por ello nos gustaría recomendar que las organizaciones privadas o públicas incluyan en sus políticas de gestión de la seguridad de la información la prohibición de uso de aplicaciones P2P en sus redes corporativas y que se establezcan los procedimientos para detectarlas, bloquearlas y eliminarlas en caso de que estuvieran siendo empleadas.

¡Ah, por cierto! Aquí estamos para asesorar técnica, operativa y jurídicamente sobre cómo definir, implantar, revisar y auditar políticas y procedimientos de gestión de seguridad de la información, integrando en ellos como no la prohibición de uso de redes P2P con los medios corporativos. Y todo ello de conformidad con estándares internacionales de seguridad de la información, la legislación vigente y jurisprudencia relevante al caso.

Álvaro Del Hoyo
Departamento de Consultoría





Redes P2P, datos personales, ilícitos civiles, delitos y seguridad de la información

En relación con la ya larga polémica sobre si el uso de las redes P2P es un delito o un ilícito civil o ambas cosas a la vez, recientemente recibíamos la noticia de que según el Tribunal de Justicia de las Comunidades Europeas (TJCE) los proveedores de acceso a Internet no tienen la obligación de comunicar los datos personales de sus clientes que les hubieran sido solicitados en sede civil por haber sido identificados como usuarios de redes P2P, y al propósito final de que pudieran serles interpuestas demandas civiles por la infracción de derechos de autor.

Este asunto ha sido tratado en profundidad en el blog de David Maeztu, y es especialmente interesante el debate que se ha generado en sus comentarios. En este documento adjunto hago un análisis de la sentencia y doy mi punto de vista a varias de las cuestiones surgidas en este debate, además de aportar el análisis sobre otros aspectos relevantes al caso como la consideración de las direcciones IP como dato de carácter personal, o sobre la ilicitud y tipicidad del uso de redes P2P.

Esta resolución del TJCE surge de la cuestión prejudicial planteada por el Juzgado de lo Mercantil Nº 5 de Madrid que depuraba el caso que enfrentaba a Promusicae (antes AFYVE) con Telefónica al haberse negado ésta a entregar los datos identificativos de determinados clientes, de los que Promusicae conocía la dirección IP y que compartían música de obras cuyos derechos patrimoniales de autor corresponden a discográficas españolas.

Es evidente que Promusicae hizo en la red KaZaA uso de alguna tecnología para registrar las direcciones IP, de si no todos, al menos algunos de sus usuarios, así como para enviarles mensajes de advertencia a los usuarios españoles de este Red y finalmente para solicitar judicialmente a Telefónica la identificación de aquellos de sus clientes que tienen asignadas direcciones IP dentro del rango del operador y que han sido encontradas haciendo uso de la conocida red P2P.

En este vídeo puede verse cómo de fácil es realizar un escaneo de los usuarios de las redes P2P:



En la sentencia al caso-275/06 el TJCE concluye que "las Directivas 2000/31/CE, 2001/29/CE, 2004/48/CE y 2002/58/CE no obligan a los Estados miembros a imponer, en una situación como la del asunto principal, el deber de comunicar datos personales con objeto de garantizar la protección efectiva de los derechos de autor en el marco de un procedimiento civil". Afirma ello el TJCE sin perjuicio de que también concluya que "la Directiva 2002/58 no excluye la posibilidad de que los Estados miembros impongan el deber de divulgar datos personales en un procedimiento civil" y que "sin embargo, el tenor del artículo 15, apartado 1, de esta Directiva no puede interpretarse en el sentido de que obliga a los Estados miembros a imponer tal deber en las situaciones que enumera".

En la continuación de este post comentaremos las iniciativas legislativas existentes en Francia y Reino Unido en este sentido y sus antecedetes.

Álvaro Del Hoyo
Departamento de Consultoría





Metodología de análisis de riesgos para abordar una certificación ISO/IEC 27001

El proceso de certificación de un Sistema de Gestión de Seguridad de la Información ISO/IEC 27001 requiere la elaboración de un Análisis de Riesgos como medio de diseñar el Plan de Gestión de Riesgos del sistema, e identificar la aplicabilidad de los controles a implantar en una organización.

Por el momento la familia de las 27001 no nos ha dotado de un método para la elaboración del análisis de riesgos, dicho método será la futura ISO/IEC 27005 de la que por el momento solamente tenemos un draft mientras que el estándar será publicado previsiblemente en 2009.

Debido a la ausencia de metodología propia para la certificación ISO/IEC 27001 nos encontramos con la duda de qué metodología emplear, debido a sus diferentes funcionalidades, a las herramientas en las que se soporta, a los estándares y normativas a las que da conformidad, la metodología idónea parece ser MAGERIT II.

Objetivos de MAGERIT II

MAGERIT; persigue los siguientes objetivos:
  1. Concienciar a los responsables de los sistemas de información de la existencia de riesgos y de la necesidad de atajarlos a tiempo
  2. Ofrecer un método sistemático para analizar tales riesgos
  3. Ayudar a descubrir y planificar las medidas oportunas para mantener los riesgos bajo control
  4. Apoyar la preparación a la Organización para procesos de evaluación, auditoría, certificación o acreditación, según corresponda en cada caso
¿Porque MAGERIT II?

El análisis de riesgos propuesto por MAGERIT II es una aproximación metódica que permite determinar el riesgo siguiendo unos pasos:
  • Determinar los activos relevantes para la Organización
  • Determinar a que amenazas están expuestos aquellos activos
  • Estimar el impacto, definido como el daño sobre el activo derivado de la materialización de la amenaza.
  • Valorar dichos activos en función del coste que supondría para la Organización recuperarse ante un problema de disponibilidad, integridad, confidencialidad o autenticidad
  • Valorar las amenazas potenciales.
  • Estimar el riesgo, definido como el impacto ponderado con la tasa de ocurrencia (o expectación de materialización) de la amenaza.

El método propuesto por MAGERIT II da cumplimiento en lo establecido en la ISO 13335, en el epígrafe 4.2.1.d Identificar Riesgos, 4.2.1.e Analizar y evaluar riesgos de la ISO /IEC 27001:2005 , y además garantiza conformidad respecto los estándares:
  • ISO/IEC 27001 / 2005 “Sistemas de Gestión de Seguridad de la Información”
  • ISO/IEC 15408 / 2005 “Criterios de Evaluación de Seguridad de la Información”
  • ISO/IEC 17799 / 2005 “ Manual de Buenas Prácticas de Gestión de Seguridad de la Información”
  • ISO/IEC 13335 / 2004 “Guía para la Gestión de Seguridad TI”
Comparativa con otras metodologías de análisis de riesgos:


http://www.enisa.europa.eu/rmra/rm_ra_tools.html

En la comparativa de las diferentes metodologías y herramientas de análisis de riesgos se puede concluir que MAGERIT II es el método ideal por las siguientes razones:
  1. Por estar impulsado por el Consejo Superior de Administración Electrónica.
  2. Por ser un método desarrollado en su integridad en castellano.
  3. Por tener la herramienta de gestión de Análisis de Riesgos EAR/PILAR mantenida y actualizada
  4. Por dar conformidad a los estándares internacionales y a la normativa de protección de datos.
  5. Por dar conformidad a la ISO/IEC 27002:2005
  6. Por contar con el perfil para dar conformidad al RD 1720/2007 de desarrollo del Art. 9 de la Ley Orgánica de Protección de Datos 15/1999, en versión beta
  7. Por su próxima incorporación de los perfiles Sarbanes Oxley y a Cobit 4.1
David Imizcoz Etxeberria
Manager de Consultoría S21sec






Real Decreto 181/2008,de 8 de febrero de ordenación del Boletín Oficial del Estado

Hace unos días comentábamos que la Agencia Estatal Boletín Oficial del Estado está obligada a cumplir con la Ley Orgánica 15/1999, de 13 de diciembre, sobre Protección de Datos de Carácter Personal.

Como prueba de ello basta con ver el artículo 17 del Real Decreto 181/2008,de 8 de febrero de ordenación del Boletín Oficial del Estado. Ya veremos cómo resuelven el proceso de cancelación de los datos, cuestión que se intuye bastante compleja.

A partir de ahora las ediciones del BOE vendrán firmadas con certificados de firma electrónica avanzada.

Álvaro Del Hoyo
Departamento de Consultoría





USB wireless

Ya hemos hablado varias veces de ello. Las tecnologías inalámbricas tienen un riesgo inherente mayor. La información viaja por el aire, un medio compartido en el sentido más estricto de la palabra. Los distintos protocolos tienen esto en cuenta e incluyen mecanismos de cifrado y de autenticación, en algunos casos con poco éxito. El caso más claro es el WEP, con una longitud de clave y de vector de inicialización demasiado corta y un sistema de comprobación de la integridad de los datos prácticamente inútil. Otro caso es el bluetooth, basado en una modificación del SAFER+. En principio, utilizar una modificación de un algoritmo conocido no es una buena idea, ya que con el tiempo puede descubrirse que el resultado es vulnerable. Actualmente la mayor dificultad es poder capturar el tráfico que se intercambian los dispositivos durante el proceso de emparejamiento. Si se consigue esta información, el sistema el mecanismo de autenticación y de cifrado es inseguro. De hecho, oficialmente se recomienda hacer el emparejamiento de dispositivos en un "lugar seguro".

Dentro de poco va a llegar el USB inalámbrico. A día de hoy, por las conexiones USB viajan muchos datos sensibles, como las contraseñas que tecleas o los datos que lees de un disco duro externo. Es obvio lo peligroso que sería que alguien consiguiera capturar este tráfico, fuera capaz de suplantar la identidad de un teclado, o hacer un ataque de "man-in-the-middle" con un disco duro. Según la especificación, el algoritmo de cifrado a utilizar es AES-128 con CCM, proporcionando así confidencialidad y autenticación. También se permite utilizar RSA para el intercambio de las claves simétricas, aunque se obliga a que el nivel de seguridad sea comparable al de AES-128. Parece que en este caso han optado por utilizar algoritmos conocidos y probados con una longitud de clave suficiente. Esperaremos a ver los primeros dispositivos.

Patxi Astiz
S21sec labs





CONOCE A NUESTROS EXPERTOS

La semana que viene estaremos patrocinando las VII Jornadas de Seguridad de la Información en Defensa organizadas por ISDEFE. Las jornadas tendrán lugar del 11 al 14 de febrero y el día 12 David Barroso, director de Investigación de S21sec labs dará una ponencia sobre el código dañino.

Por otra parte, Antonio Ramos, director de consultoría de S21sec dará una ponencia sobre PCI en las Conferencias sobre el cumplimiento de PCI DSS organizadas por Cisco que se celebrarán el próximo jueves, 14 de febrero en el Museo Thyssen, Madrid.

Y, Antonio Ramos ofrecerá también una ponencia en Palencia el 19 de febrero dentro de las jornadas Globaltech. En esta ocasión sobre la gestión de incidentes y los planes de continuidad del negocio.

¡Nos vemos allí!






Seguridad: mitos de ayer, excusas de hoy

Actualmente, no hay semana que pase en la que no veamos una noticia relacionada con nuevas amenazas web, malware, phishing, perdidas de datos, usuarios descuidados, revelaciones de datos confidenciales etc.

Por ello, aunque a modo general, parece que el concepto de seguridad está empezando a tomarse en serio por el usuario medio, lo cierto es que aún, una vasta mayoría, todavía subestima la importancia de estas medidas o tienen ideas equivocadas.

Actualmente, el grado de sofisticación de los ataques en Internet o directamente a los usuarios, roza ya lo irreal. Y esto, es algo que no va a parar de crecer, mientras exista detrás todo un mercado negro con una gran infraestructura establecida.


Los usuarios deben ser conscientes de ello, pero haría falta mucha educación y sensibilización, cosa que no siempre está al alcance de todos, o no se está por la labor. Tambien observamos cómo los usuarios creen que estan a salvo y fuera de peligro porque creen en mitos que ya no son ciertos actualmente y los ponen como excusas poniendo en peligro su seguridad por el desconocimiento ¿de qué mitos hablamos?:

  1. No tengo nada importante en mi equipo.
    • Cuestión: No se trata de lo que tengas o no tengas en tu equipo. Se trata de lo que pueden hacer a través de él.
    • Solución: No digas "me da igual".
  2. Utilizamos scp para transferir ficheros en la red.
    • Cuestion: Aunque se usen algoritmos de cifrado y una longitud de clave apropiada, sólo estas seguro seguro desde un punto al otro.
    • Solución: ¿dónde se transmiten los ficheros? ¿quién tiene acceso? ¿se realiza backup de esos ficheros? ¿es necesario? ¿cual es la política de backup?. En cuantos más sitios residan los datos, más difícil es protegerlos.
  3. Estamos detrás del Firewall de nuestra empresa o casa.
    • Cuestión: Esta puede ser la excusa más típica, los usuarios se sienten a salvo trás esa "máquina" que les protege. Con las amenazas actuales, los firewall de red e IDS no son suficientes.
    • Solución: La seguridad necesita combatirse a varios niveles. El firewall de red es simplemente uno de esos níveles. El usuario necesita herramientas de seguridad en su propio equipo que le avisen cuando algo ocurre, y explorar la red con navegadores fiables y seguros.
  4. Para las transacciones online sólo me fío de los sitios con https.
    • Solución: Concienciación del usuario, experiencia y un sexto sentido.
  5. Utilizo un sistema operativo que no necesita antivirus.
    • Cuestión: Cual, ¿Mac?, ¿GNU/Linux?, ¿Windows?.. Los mayores peligros hoy día son multiplataforma, no importa qué SO utilicemos. ¿Se os ocurre cómo un simple rootkit podría introducirse en usuarios de Windows/Linux y MacOS?. Sí ampliamos el concepto de rootkit que tenemos hoy día para ir más alla del S.O como objetivo de éste, podremos verlo en una extensión de firefox por ejemplo.
    • Solución: Muchos abogan por tener un navegador para el ocio y otro para realizar transacciones en Internet, pero no resultaría algo cómodo para el usuario. Hay que buscar nuevas soluciones para las nuevas amenazas.

Recuerda, la seguridad es el proceso de mantener un nivel aceptable del riesgo que se percibe, no hay que vivir en un constante estado de paranoia, pero tampoco debemos poner como excusas de nuestra seguridad mitos de ayer que no valen hoy. Al final, todo es cuestión de confianza.

Emilio Casbas
S21sec labs





Seguridad utópica

En mis dos anteriores posts he intentado crear un poco de conciencia de seguridad en los lectores de este blog. No sé si lo habré conseguido, pero dicen que la intención es lo que cuenta,¿no?:) La cuestión es que a raíz de estas publicaciones un amigo me comentó que esos consejos/avisos eran correctos si los lectores eran gente con experiencia en esto de los ordenadores, del uso de Internet e incluso de la seguridad, pero, ¿y qué pasa con aquellas personas que no tienen ese nivel? Seguramente ellas no leerán estas líneas, pero es que realmente yo también pienso en ellas cuando las escribo. ¿Qué es lo que falla aquí? ¿es culpa del usuario que su sistema sea vulnerable si no tiene ni idea de seguridad?

Es evidente que hay un amplio abanico de personas que descuidan la seguridad de sus equipos, ya sea por desconocimiento o por pensar que ese tipo de medidas son innecesarias. Y en cuanto a desconocimiento no me refiero a la ignorancia de la existencia de los peligros de Internet, sino que aun conscientes de ellos no saben cómo protegerse. Siempre está la posibilidad de que pidan ayuda a usuarios más experimentados (¿no os viene a la cabeza el pringao howto? espero que no sea el único...), pero no siempre es posible, y, además, no creo que sea una buena solución.

¿Entonces qué se puede hacer? La solución podría basarse en que tanto fabricantes como desarrolladores tuvieran en cuenta que los ordenadores deben llegar al usuario totalmente securizados y sin la necesidad de interacción por su parte. Algo totalmente automatizado que les proteja sin darse cuenta: antivirus que no caduquen a los dos meses y que se actualicen diariamente, cortafuegos competentes que permitan la adición de excepciones de programas de forma intuitiva, descargas de actualizaciones de seguridad diarias tanto del sistema operativo como de las aplicaciones instaladas, sistemas operativos con políticas y configuraciones por defecto seguras... Muchas de estas consideraciones se solucionarían con un sistemas operativo de código libre, pero no quiero entrar en ese tipo de discusiones, sólo me gustaría que se tuviera en cuenta a este tipo de usuarios a la hora de fabricar un ordenador, a la hora de elegir los programas preinstalados, en definitiva, que no sólo se piense en la mejor forma de sacar dinero.

Y ya que nos ponemos a analizar esta situación, empecemos desde abajo. ¿Por qué no incluir en las típicas clases de informática de los colegios todo un tema dedicado a la seguridad? peligros/defensas, buenas prácticas, instalación y mantenimiento de programas especializados...etc. Y ya no sólo en el colegio, sino que se debería formar sobre este tema a todo trabajador que use diariamente un ordenador, con el correspondiente examen. Esto evitaría unos cuantos problemas.

Queremos que el mundo de la tecnología de la información avance, pero, ¿a toda costa? Normalmente la filosofía es lanzar un producto cuanto antes, adelantándose a la competencia, y que los usuarios lo compren como rosquillas. Ya más tarde surgirán los problemas derivados de esa prisa, pero el dinero ya estará facturado. Lo que hace falta, en mi opinión, es un profundo cambio donde lo primordial sea la programación segura de las aplicaciones y la formación en seguridad de todo usuario, complementado con ordenadores securizados de base. ¿Es esto una utopía? ¿otra utopía? ¿es una utopía el fin del calentamiento global? ¿la paz mundial? hay utopías que pudiendo ser realidad nunca dejarán de ser utopías...


José Miguel Esparza
S21sec labs





TrueCrypt 5.0 is out

After a long 9 months wait, TrueCrypt 5.0 was released yesterday. This major version upgrade (up from 4.3a) is mainly justified by the inclusion of a new feature which allows an entire system drive or partition helding a Windows OS (XP/2003/Vista) to be encrypted with a pre-boot authentication interface, as most commercial full disk encryption software do. But there are other important improvements in this new version, like the new GNU/Linux GUI (older versions only had a command line interface and third party front-ends) and the MacOS X port. How many multi-OS FDE tools are out there? Not many I guess.

I would like to introduce anyone who didn't know about this open source software. TrueCrypt is a tool which can easily encrypt hard drive, flash (USB, memory cards...) and other storage media. It was programmed with Windows in mind, and it's not focused on being a commercial FDE software competition. These products shine on their own thanks to their centralized administration console to control many computers, and their data rescue tools for recovering encrypted files which password was lost or data from an employee who left the company.

There are two main operational modes: file container based and partition/drive based. There is no recommended mode, as it depends on the storage media where encrypted data is being saved. File based containers are ideal if mobility is the main concern (it is a simple file at all which can be copied, moved...), whereas drive/partition containers have an important speed edge. The final decision has to be made having in mind the main use of the encrypted data.

This storage space can be encrypted using three different symmetric key algorithms (AES, Serpent or Twofish) or a combination of those two/three with a cascade. These algorithms are patent free so they should be unsuspicious of having some extra backdoor code (paranoid people can look through TrueCrypt source code and compile it instead of using precompiled binaries). TrueCrypt maps decrypted data on a drive letter or a mountable mapper device (depending on the OS).

There are other interesting features that I would like share with you. Hidden volumes are useful to protect data within an inner container which is decrypted using a different password than the normal contanier. This is useful in case of a coercion scenario. Last but not least, you can complement the encryption password by using a second authentication factor, a keyfile. This keyfile provides the encrypted data owner with an additional security layer (something you have in addition to something you know), making keyloggers useless for intruders. If you decide to use keyfiles, it's extremely important to have it properly stored in a removable memory device and kept away from the computer where the data is, when not in use.

I highly recommend our readers to have a look at this fine software that will protect our most sensitive data from undesired eyes. It can be intimidating at first due to the high amount of advanced options available, but it isn't necessary to learn them all. Most important features are quickly learnt thanks to its complete tutorial and documentation.

Álvaro Ramón
S21sec labs





Wii exploit

El mundo de las consolas de videojuegos está cambiando continuamente. Han pasado de ser elementos aislados en la casa de su feliz consumidor a elementos interconectados a Internet capaces de interactuar a través de la red. De todas las consolas de última generación actuales la que más difusión está teniendo es la Wii.


Pues bien, ni siquiera un mundo tan cerrado como este se libra de exploits. Se ha descubierto recientemente un exploit capaz de ejecutar código privado dentro de la consola Wii. No es una vulnerabilidad peligrosa que pudiera ser explotada a través de Internet, pero sí que puede ser un comienzo para futuras versiones.


El exploit consiste en modificar el código almacenado dentro de una partida guardada de un conocido juego. No es una tarea sencilla ya que cada partida guardada almacena tres campos de datos:

  • La partida guardada cifrada.
  • Una firma de la partida guardada, usando la clave privada de la consola.
  • Una copia de la clave pública de la consola.


Por lo tanto es necesario conocer los datos de la clave pública y privada de la consola a ser atacada para poder inyectar el código dentro de los datos. Una vez modificados esos datos es posible la ejecución de código privado, aunque muy pocas líneas de código, por lo que de momento no es muy peligroso.


Una vez conocido todo el proceso, no representa un gran riesgo para el usuario final, pero las consolas de hoy en día están conectadas a Internet, e incluso son utilizadas para navegar, y la posibilidad de poder ejecutar código malicioso las hace potencialmente vulnerables.

¿Qué pasaría entonces?


José María Arce Guillén
S21sec labs






Doctor…¡oigo voces! (a través del Bluetooth)

La escucha de comunicaciones realizadas a través del protocolo Bluetooth se considera algo muy difícil debido a los mecanismos de seguridad implícitos en el mismo. El protocolo Bluetooth dispone de codificación a nivel de enlace, con una clave de 128 bits. Sin embargo, en entornos académicos se ha demostrado que esta clave puede ser vulnerable si se captura el intercambio de claves que tiene lugar en el “emparejamiento” de dispositivos Bluetooth.

Por otro lado, pese a disponer de dicha clave, el protocolo Bluetooth presenta otras dos grandes barreras a nivel físico que incrementan su seguridad. La primera es que emite cada paquete en una frecuencia diferente, y salta 1600 veces por segundo. La segunda es un procesado que se hace de los datos a nivel de bit para evitar cambios en la energía DC emitida (conocido como“data whitening”).

Por último, la máxima distancia para la que se diseño este protocolo es de 100 m para los dispositivos de clase 1. Sin embargo, con ayuda de antenas direccionales se pueden alcanzar distancias que superan ampliamente el kilómetro, como ya nos demostraron en su día los chicos de Flexilis.

Así que, aunque el protocolo aún resulta bastante seguro en cuanto a escucha ilegítima de comunicaciones, existen otros tipos de ataques documentados y herramientas software disponibles, como recoge de manera excelente el grupo de expertos Trifinite.

Ellos son también los creadores del famoso programa Carwhisperer , en el cual, se aprovecha que la mayoría de los dispositivos audio o “manos libres” que funcionan con Bluetooth, llevan implícito el pin “0000” o “1234”, lo que han querido denunciar con la creación de este programa. Una vez más, gran parte de la seguridad diseñada por los expertos, se ve después despreciada en bien de la facilidad de uso del aparato u otras causas de índole comercial. A su vez, como es éticamente correcto, los creadores del programa han suministrado a la industria una guía de buenas prácticas para evitar esta debilidad.

En definitiva, por medio del programa Carwhisperer, y una antena direccional, una vez establecida la asociación con un dispositivo manos libres, se puede recoger remotamente el audio que está captando el micrófono sin que el usuario final sea consciente. Por otro lado, así como es posible capturar el sonido que recibe el micrófono, también es posible inyectar audio en los auriculares, con lo que se puede conseguir crear una confusión bastante impactante. En este video del consultor de seguridad Joshua Wright se puede ver una demostración práctica de su uso.

Así que, si te gusta pasearte con el “pinganillo” en la oreja, y te parece que estás oyendo voces, antes de ir al médico, prueba a quitártelo primero, ¡no sea que hayas sido victima de un ataque con Carwhisperer!


Jon Asín

S21sec labs






Bases de datos biométricas

Al hilo de la noticia que se produjo hace unas semanas en relación con la mayor base de datos biométrica a nivel mundial que quiere confeccionar el FBI y en la que quiere sumar a la policía del Reino Unido, recordé lo caro, tedioso y delicado a nivel de LOPD que resulta reunir una gran base de datos biométrica.

Estas bases de datos se utilizan en distintos ámbitos. En la investigación académica y empresarial son de gran ayuda para probar la bondad de nuevos algoritmos biométricos. Así mismo, también son muy útiles como sistema de testeo masivo de nuevos dispositivos que vayan a salir al mercado. Estos tests permiten dar las figuras de mérito habituales de tasa de falsas aceptaciones, falsos rechazos y otra serie de parámetros.

Sería de gran interés poder generar características biométricas artificiales con la suficiente calidad y aleatoriedad como para poder confeccionar una gran base de datos de este tipo. Surfeando la web me encontré con Sfinge, una herramienta que permite generar huellas dactilares sintéticas. Aquí podéis bajaros la versión demo. Permite configurar multitud de parámetros como son las dimensiones, la clase de huella (remolino, bucle, delta, etc.), las posiciones de las características principales, cortes en la dermis, etc.


Arriba os muestro una de las huellas que he generado en menos de un minuto. Espero que os pique la curiosidad y os haga pasar un rato divertido intentando imitar vuestras propias huellas. ¡Realmente engancha!


Elyoenai Egozcue
S21sec labs







(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2012 - Todos los derechos reservados


login