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...

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