Blog
Proyectos

miércoles 30 de enero de 2008

¿Con amigos así, quién necesita enemigos?

Viendo las cada vez más frecuentes noticias sobre dispositivos comprados en tiendas que estaban infectados por algún tipo de código malicioso (discos duros, iPODs, USB, GPS, ...) es la excusa perfecta que esperabamos los paranoicos para desconfiar cuando un amigo nos deja un USB, una cámara de fotos, cualquier dispositivo que se quiera conectar a nuestra máquina por alguno de sus interfaces. Pero imaginemos que estas Navidades nos han regalado uno de los regalos estrella de este año: un marco de fotos electrónico. ¿A quién se le va a ocurrir que al conectarlo a tu ordenador te va a poder infectar?


Parece que ha ocurrido en USA, pero no me atrevería a decir que no hubiera ocurrido en España. 
¿Necesitaremos los usuarios una protección adiccional al igual que tenemos nuestros IPS de red para confiar en dispositivos externos? ¿Son suficientes las capas de seguridad que tenemos en nuestros sistemas? Hagamos una prueba. O es un nicho de mercado a explotar, o la verdad, no tiene sentido.

Más bien las preguntas tendrían que ser ¿quién de vosotros tiene aún el AutoRun activado? ¿tenemos que concienciar más a los usuarios?¿por qué los fabricantes en su procesos de calidad rara vez contemplan aspectos de seguridad?¿os habéis encontrado con algún caso parecido?

David Barroso
S21sec labs

martes 29 de enero de 2008

Más seguridad para el protocolo HTTP

Actualizado (27/02/08): Ver Más seguridad para el protocolo HTTP (II)

La especificación del protocolo HTTP tiene ya más de 8 años, y es ahora, cuando se empieza a trabajar en la seguridad asociada a este protocolo, con la creación de un borrador por parte del IETF. Security Requirements for HTTP.

Los problemas que van a tratar son los mecanismos de seguridad asociados al HTTP o la falta de ellos. :)

Entre otros podemos ver:
  • Autenticación HTTP a través de claves de sesión en cookies y formularios HTML.
  • Susceptibilidad de las cookies a todo tipo de ataques por parte de intermediarios y mirones.
  • Autenticación básica, digest y otros esquemas basados en la capa de transporte.
  • Esquemas de autenticación basados en tickets centralizados.
  • Web Services. (protocolos basados en XML)
  • Posible revisión del protocolo HTTP en un futuro.

Ya hablamos de esto anteriormente, la seguridad en la capa de transporte proporcionada a los protocolos de nivel más alto, como HTTP, o lo que es lo mismo, HTTPS, no es suficiente para los riesgos que existen actualmente en las aplicaciones web.

Este documento cubrirá los mecanismos de seguridad de HTTP como una combinación del transporte seguro y la autenticación de acceso. Su objetivo será concluir con un documento de "Recomendación de las mejores prácticas actuales de la seguridad HTTP".
Hay que ver que en la actualidad se trata únicamente de un borrador inicial y está incompleto. Pero al menos, son buenas noticias, ya que se está trabajando en ello para que tarde o temprano se empiece a implementar. Puede que no sea todo lo que necesitamos, pero al menos es más de lo que tenemos actualmente.

Emilio Casbas
S21sec labs

lunes 28 de enero de 2008

Soporte papel: el gran arrinconado en la seguridad de la información.

En prácticamente todas las empresas actualmente podemos encontrar la aplicación de controles para el acceso a la información en soporte magnético, es decir, a la información que reside en archivos y ficheros informáticos. La funcionalidad relacionada con el control de acceso está `presente en prácticamente todos los sistemas operativos, aplicaciones, programas de gestión de BDD, etc.

La automatización en la gestión de accesos viene facilitada por la existencia de software específico pensado para realizar dicha labor como, por ejemplo, las aplicaciones de gestión de identidades.

En el “mundo físico” no obstante la realidad es bastante distinta: el control de acceso a la documentación es soporte papel debe realizarse mediante la aplicación de controles físicos, lo cual dificulta tanto la aplicación de los controles como la continuidad en el tiempo de la aplicación de las medidas que se apliquen. Otro de los inconvenientes del soporte papel es la dificultad de controlar la trazabilidad de un documento, es decir, el circuito que sigue desde su creación hasta su archivo definitivo y los posteriores accesos para su consulta una vez archivado: un documento que es extraído del archivo y no devuelto o que es fotocopiado, con lo cual se generan múltiples copias en soporte papel sobre las que también se deberá controlar su trazabilidad y circuito de distribución.

El marco legal vigente, en mi modesta opinión, ofrece motivos suficientes que justifican la aplicación de mecanismos de salvaguarda para proteger la información en soporte papel. Dentro de este marco legal podríamos destacar:

  • La ley de competencia desleal: dónde se establece que se considera desleal la divulgación o explotación, sin autorización del titular, de secretos industriales o de cualquier otra especie de secretos empresariales a los que se haya tenido acceso legítima o ilegítimamente.
  • El propio código penal: en el artículo 197 se establecen penas de prisión al que, con el fin de descubrir los secretos o vulnerar la intimidad de otro, sin su consentimiento se apodere de sus papeles, cartas o cualesquiera otros documentos (...).
  • El nuevo reglamento de seguridad de la LOPD: que establece las medidas que las empresas deberán aplicar a los datos en soporte papel.

Una vez vistas las dificultades principales veamos las alternativas posibles para superar estos inconvenientes. Veamos, pues, qué controles podemos aplicar sobre el soporte papel:

  1. Política específica de tratamiento de documentos confidenciales: No presuponer que el número de personas que acceden a documentos confidenciales en soporte papel es acotado o reducido, siempre existe el riesgo de divulgación no autorizada. Se deberá elaborar, aprobar, difundir e implantar una política dirigida especialmente a establecer las directrices para el tratamiento de los documentos en soporte papel que contenga información confidencial. Esto nos lleva de forma natural al siguiente punto.....
  2. Identificación de los documentos con información confidencial: Este punto es bastante más sencillo de los que pueda parecer: Fácilmente podemos intuir los departamentos dónde existen documentos confidenciales (Dirección General, RRHH, área Jurídica). Si no conocemos qué es importante (confidencial), no sabremos qué es lo que tenemos que proteger. Una vez identificada la documentación con requisitos de confidencialidad el siguiente control seria disponer de.....
  3. Metodología de clasificación y almacenamiento de los documentos confidenciales: En este punto juega un papel clave una interpretación libre del concepto “oficina sin papeles”: escanear los documentos y almacenarlos digitalmente aprovechando así, por un lado, la automatización de los controles de acceso del “mundo digital” y, por otro, disponiendo de una copia de seguridad.
  4. Disponer de contenedores específicos para la destrucción de documentos confidenciales: Dichos contenedores sería recomendable que estuvieran cerrados con llave evitando que queden abierto pues, en ese caso, serían equivalentes a una papelera convencional.
  5. Disponer de destructoras de papel (trituradoras) que garanticen la imposibilidad de recuperar la información. Estas destructoras pueden ser personales, departamentales o compartidas por varios departamentos de la empresa.
  6. Externalizar el servicio de destrucción de documentos en soporte papel: En este caso es aconsejable que se establezcan cláusulas orientadas a garantizar la confidencialidad durante la recogida y transporte de los documentos, establecer contractualmente el tamaño del residuo una vez destruidos los documentos y, como e todo contrato de externalización de servicios, tener potestad auditora sobre el prestador.
  7. Incluir cláusulas de confidencialidad con la empresa de limpieza: El personal de limpieza accede a aquellas áreas o zonas restringidas al resto del personal de la empresa, por ejemplo, el despacho del Director General en cuyo escritorio está el Plan Estratégico de negocio o el acuerdo de fusión con la competencia.....
  8. Revisión continua de la aplicación de los controles: El seguimiento continuo es lo que nos dará garantías que las iniciativas anteriores no se afrontan de forma puntual, ayudando así a crear la concienciación necesaria en todo el staff.

Joan Ayerbe
Manager de Consultoría, CISM.

Jugando con WiFi

Siguiendo con los post de concienciación mostrados por nuestro compañero José Miguel Esparza y abogando al tema de la confianza mostrado por Patxi Astiz, vamos a ver un tema que hoy día nos afecta a casi todos, el WiFi.

Todos utilizamos a diario alguna red WiFi: en casa, en el trabajo, en la universidad... Pero, ¿pensamos en lo que conlleva el utilizar una red WiFi?.

Pongamos tres escenarios:
1 - Red abierta
2 - Red con WEP
3 - Red con WPA2

En todos los casos utilizamos un medio compartido como es el aire, lo que acarrea problemas de seguridad, ya que cualquiera puede observar el tráfico generado por los dispositivos a su alcance. Vamos a analizar los tres casos:

Caso 1: Red abierta.

Todo el tráfico circula sin cifrar, por lo que una simple escucha nos permite ver todo el tráfico. Todo el tráfico que viaje en claro podrá ser escuchado, lo que implica poder espiar desde conversaciones de mensajería instantánea hasta contraseñas de correo pop, pasando por conexiones ftp y tráfico http...
Además ponemos en bandeja el robo de sesiones por robo de cookie, por lo que nuestras cuentas de diversos foros o incluso correo, como puede ser gmail, no están para nada a salvo.

Caso 2: Red con WEP

Sabemos que saltarse el cifrado WEP es "cosa de niños", y tenemos aplicaciones curiosas como airtun que nos permiten, una vez obtenida la contraseña WEP, tunelizar el tráfico a una interfaz virtual que recibirá el tráfico en claro. Conclusión: Caso 2 = Caso 1

Caso 3: Red con WPA2

En este caso, si la contraseña es robusta, podemos estar ciertamente más tranquilos cara a los curiosos pero, ¿y los que conocen la clave? Siempre hay a tu derecha algún compañero con mala gaita al que le bastará tener el wireshark a mano para poder descifrar el tráfico wireless que haya capturado.

Tendremos que confiar en los compañeros ;)

Mikel Gastesi
S21sec labs

sábado 26 de enero de 2008

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

Siguiendo con el tema que comentamos hace unos días, donde hablabamos de los riesgos inherentes a los entornos virtuales que muy poca gente toma a consideración, existen diversos movimientos en el mercado de la seguridad que nos demuestran que no todo el mundo se ha dormido en los laureles.


Sin ir más lejos, Cisco hace casi un año invirtió en VMware varias decenas de millones, además de que su presidente, John Chambers (que por cierto, es un presentador excelente), fue uno de los conferenciantes en la keynote de VMworld 2007. Todos los rumores apuntan a que dentro de poco veremos un switch Cisco virtual corriendo en ESX; está claro que Cisco se ha dado cuenta de la buena oportunidad que tiene.

Buscando en Internet sobre proveedores de productos que puedan ayudarnos a protegernos en entornos virtuales, pude comprobar que existen ya varios productos que intentar cubrir el gap entre entornos reales y físicos: VirtualShield de Blueline, ReflexVSA de Reflex, ...


Pero no sólo hay empresas que se preocupan por el tema, la propia VMware, el verano pasado adquirió la empresa Determina, que tenia varios productos como Memory Firewall, o LiveShield orientados a protección entre máquinas virtuales.

Así que en breve nos tocará modificar nuestras políticas de seguridad, procedimientos, formación y como no, nuestros presupuestos: ya no contentos sólo con todos nuestros dispositivos de seguridad, tendremos que fijarnos en dispositivos virtuales, pero eso sí, al menos no ocupan sitio en nuestros racks.


David Barroso
S21sec labs

viernes 25 de enero de 2008

Datos personales, direcciones IP y los movimientos de Google

Hace ya tiempo que creó bastante revuelta el Informe 2003-0327 "Carácter de dato personal de la dirección IP" de la AGPD, tema que se va a poner de moda de nuevo en los próximos meses, si bien hay que decir que aquél informe no fue la primera manifestación en este sentido, pues sobre ello ya trataba por primera vez en el año 2000 el Documento de Trabajo 37 del Grupo del Artículo 29 "Privacidad en Internet: Enfoque comunitario integrado de la protección de datos en línea" (ver todo el documento, pero en especial su página 23).

En mi opinión, el carácter personal de la dirección IP dependerá de las posibilidades de identificación del usuario del servicio de acceso a Internet que se encuentra o encontraba detrás de la dirección IP en un momento determinado, debiéndose tener en cuenta para ello factores como la disponibilidad de redes wi-fi abiertas, la utilización de proxies de navegación, la existencia de cibercafés donde no es necesario que los usuarios se identifiquen previamente y donde no se lleva un registro histórico de los usuarios, el uso compartido de ordenadores tanto en domicilios como en lugares públicos,....

Todo depende de los datos con que adicionalmente cuente el responsable del fichero, pero no por el hecho de que sea posible en determinados casos identificar al usuario de una dirección IP ésta va a ser un dato personal. Por otra parte, no todo el mundo tiene acceso a soluciones basadas en el uso de "cookies", "data mining ",... y no creo que pueda accederse fácilmente a los datos personales que obran en poder de terceros como las entidades responsables de la asignación de las direcciones IP, los proveedores de acceso a Internet, los administradores de una red local,... ya que para ello estos debieran infringir el principio de cesión de datos, esté el responsable del fichero ubicado en territorio europeo u operando en éste. Otro cosa sería que estos datos se recibieran de forma ilegal de estos terceros o se recabaron aprovechando por ejemplo vulnerabilidades de software, protocolos,..., pero piendo que estas alternativas no debieran considerarse como disponibles a la hora de valorar si un determinado dato permite o no identificar a una persona.

Google y especialmente su responsable de seguridad para Europa, Peter Fleischer, lleva algún tiempo haciendo cierto "lobby" para tratar de promover la estandarización a nivel internacional de la legislación en materia de protección de datos, a lo que se ha sumado nuestra AGPD. Y el asunto sobre la consideración de los datos de carácer personal es uno de los temas en los que están centrando actualmente sus esfuerzos aunque me temo que en el caso de Google las direcciones IP sí que han de ser consideradas datos de carácter personal. De hecho, me pregunto por qué entonces lo de la anonimización de las direcciones IP de los logs de las búsquedas.Estoy de acuerdo con las afirmaciones de nuestra AGPD en cuanto a que las políticas de protección de datos de los buscadores de Internet puedan ser consideradas "virtuales o ficticias", no ya tanto porque "los prestadores de servicios de búsqueda no destacan suficientemente en sus páginas de inicio, sus propias políticas de privacidad" o porque la información de las políticas de privacidad sea "compleja e ininteligible", sino más bien porque "los usuarios de los servicios de búsqueda no disponen de una forma clara y accesible de las consecuencias que su utilización tendrá respecto de sus datos personales" como por ejemplo "en lo que respecta a la finalidad para la que se utilizará la información, al uso de dispositivos instalados en sus ordenadores y a la posible elaboración de perfiles sobre sus hábitos a partir de las consultas que realizan".

Eso sí, aún mejorables, es justo reconocer que las políticas de privacidad de Google quizás sean las que mayor transparencia proveen en esta materia, y no sería justo obviar la protección de la privacidad de sus usuarios ante desmanes de las autoridades públicas. Y ello aunque en la otra cara de la moneda esté el hecho de que pretendan arrimar el ascua a su sardina tratando de traspasar la carga de la protección de datos personales en sus titulares (y no como han hecho otros), lo que han llamado el principio de elección o "choice" para lo que toma por referencia al APEC Privacy Framework, ya que entienden que este marco es mejor puesto que encuentra el equilibrio entre la privacidad, las necesidades de negocio y los intereses comerciales y porque ha sido desarrollada en la Era Internet a diferencia de lo que sucede con las Guías de Protección de la Privacidad de la OECD y la Directiva 95/46/CE. En la crítica que se puede hacer a las políticas de privacidad de Google esté también el hecho de que puedan ser discutibles por la excesiva o no del todo legalmente conforme intromisión en los derechos a la intimidad, el secreto de las comunicaciones o el derecho a la privacidad como consecuencia del uso de sus servicios, la adición de publicidad contextual (sea como peaje obligatorio -GMail- o no en algunos de sus servicios), o el acopio de "logs" de búsquedas por excesivo tiempo, la longevidad de las "cookies", la adquisición de DoubleClick (o de los perfiles creados por ésta desde hace años más bien), la creación de una plataforma para la promoción de desarrollo para facilitar el intercambio de nuestros datos personales entre diferentes sitios web y paquetes de software para poder reutilizarlos ,...

Entiendo las quejas de Peter Fleischer con respecto a la excesiva burocracia a la que han de enfrentarse en Europa las empresas multinacionales del sector de Servicios de la Sociedad de la Información y el comercio electrónico, la indeterminación en cuanto a la verificación de conformidad legal de las empresas amercianas que se adhieren al Safe Harbour Agreement y la complejidad de dar satisfacción a tantas legislaciones distintas al mismo tiempo, por mucho que sean parecidas. Es precisamente por todo ello por lo que se puede estar de acuerdo en que es necesario un proceso de estandarización y armonización internacional en la legislación para la protección de la privacidad, pero desde luego cuando una dirección IP puede ponerse en relación con tanta diversidad de datos como puede hacer Google o cualquier otro de los buscadores de Internet, contando con los medios que cuentan, mucho me temo que en el caso de estas empresas las direcciones IP sí que son datos personales por mucho que todavía nos queden las excepciones antes apuntadas. Y tenemos algunas pruebas de ello, aquí y otra aquí, pero además otra en la que hasta Google parecía estar de acuerdo en que son datos de carácter personal las direcciones IP junto con los números identificativos y las "queries", vamos lo principal de sus "logs" de búsquedas.

Álvaro Del Hoyo
Departamento de Consultoría

El Señor Cerebro

Siempre se ha comentado que el que roba a un ladrón tiene cien años de perdón, que siempre hay uno más listo que tú, que si el timo de la estampita… Cada uno que adapte el refranero a su gusto para el caso Mr-Brain.

Mr-Brain es la denominación que un grupo de personas se ha dado para desarrollar un software de tipo "phishing kit”, que se ofrece gratuitamente. Con este kit cualquier persona sin demasiados conocimientos acerca de phishing puede montar una web fraudulenta imitando cualquier web de alguna empresa de Internet y hacerse con números de cuenta, tarjetas de crédito, contraseñas,... de todo aquel usuario que cometa el error de entrar en dicha página y meter sus datos. Además viene con plantillas para spam de las diferentes empresas.

A pesar de que ya llevan algún tiempo, estos kits están bastante de moda últimamente y la oferta ha crecido considerablemente. En Internet se pueden buscar cosas parecidas a precios variados, que van desde los $20 - $30 hasta los de más de $3000, dependiendo de lo que ofrecen. Lo sorprendente del caso es que este kit se ofrece gratuitamente, lo que llama la atención, ya que están regalando algo que es ilegal para que el futuro phisher que recibe el regalo consiga un dinero que el creador del phishing kit podría conseguir igualmente. Si se ponen a hacer cosas ilegales, más fácil será quedarse con todo el pastel y no regalarlo, ¿no?

Pues ahí está el truco. El kit que Mr-Brain ofrece ha sido creado para enviar toda la información recopilada (por supuesto incluyendo tarjetas de crédito y cuentas bancarias) mediante correo electrónico a una cuenta controlada por Mr-Brain. No solamente Mr-Brain accede a esos datos sin mover un dedo, y consiguiendo robar lo que puede de las cuentas antes de que la cancelen, sino que el futuro phisher, que tan feliz se las prometía, estará haciendo todo el trabajo sucio, no verá ni un duro y además le caerá una denuncia por suplantar la identidad de la empresa.

Miguel López-Negrete
S21sec labs

jueves 24 de enero de 2008

¿Tomamos en serio la virtualización?

Ultimamente está de moda el tema de la virtualización, que permite una reducción de costes importante (menos hardware, menos espacio en el CPD, menos mantenimiento, etc), además de haber cambiado sustancialmente el uso que teníamos de diversos Sistemas Operativos (ahora es común tener varios sistemas operativos con diferentes versiones para test de aplicaciones, analizar malware, configurar un escenario de pruebas, etc.)


Casi siempre que se habla de virtualización, se habla de todas sus virtudes, pero muy pocas veces se piensa en las implicaciones que puede tener pasar de tener un sistema operativo por máquina, a tener pocas máquinas y muchos sistemas operativos.

Pensemos en todo nuestro hardware que tenemos en nuestra red interna: cortafuegos internos, NAC, IDS/IPS, etc. Tenemos todos estos elementos funcionando y protegiendo nuestra red. Pero, ¿y qué ocurre con la comunicación entre máquinas virtuales dentro de un mismo servidor? ¿Están cumpliendo mi política de seguridad?¿Controlo las máquinas virtuales que están corriendo?¿Qué ocurre si una de esas máquinas se infecta con un gusano atacando el servicio RPC, tengo algo que pueda bloquear ese acceso y no infectar al resto? ¿Qué ocurre si tengo una máquina donde tengo diversas máquinas virtuales para mis proveedores?

La verdad que en este escenario tenemos muy difícil el poder analizar con un IDS/IPS el tráfico entre máquinas virtuales, filtrar o controlar el acceso físico a la red, por lo que hasta que los fabricantes vayan evolucionando sus productos para contemplar esta situación (cortafuegos virtuales, NAC virtuales, etc.), tendremos que buscar medidas alternativas. ¿Cuáles conocéis?

David Barroso
S21sec labs

miércoles 23 de enero de 2008

Pérdidas, robos y estafas

La verdad es que últimamente los británicos están que no levantan cabeza.

Hace un mes supimos que la Oficina de Hacienda y Aduanas del Reino Unido había extraviado 15 millones de datos bancarios de los contribuyentes.

Por si eso no fuera poco, hace unos días se ha sabido que una banda criminal ha estafado al menos 22 millones de euros (aunque se cree que la cantidad es mucho más elevada) a la Hacienda británica usando para ello su propio portal de Internet.
Los delincuentes usurparon la personalidad de 13.000 empleados del gestor de la red ferroviaria, Network Rail, para solicitar en su nombre pagos de hasta 150 euros por persona.Los estafadores usaban su nombre, fecha de nacimiento y número de identificación para reclamar los pagos a través de Internet, alterando para ellos los datos referidos a número de hijos y estatus laboral del trabajador.

Y para rematar la faena, esta misma semana, el Ministerio británico de Defensa ha confirmado el robo de un ordenador portátil perteneciente a un oficial que contenía datos de 600.000 personas, incluidos sus números de pasaporte o de la seguridad social.

¿Estaría el disco duro de ese ordenador cifrado?.¿Por qué tenían esos datos en un portátil y no en un servidor?.


Asier Marruedo
S21sec labs

martes 22 de enero de 2008

De Diarios Oficiales, fuentes accesibles al público, y el deber de cancelación de datos

Curiosa noticia está que nos trae el diario El País de hoy en la que se trae a colación un asunto todavía por explorar en profundidad en el ámbito de la protección de los datos de carácter personal: la relación entre las libertades de expresión e información y la protección de datos de carácter personal.

Las resoluciones de la AGPD citadas en el artículo las tenéis aquí (caso BOE), a esta primera siguió con otra al interpuesto recurso de reposición, y aquí (caso del profesor y Google).

En su transposición la LOPD obvió el Considerando 37 y el artículo 9 de la Directiva 95/46/CE, cuestión que tampoco se encuentra del todo bien resuelta con respecto a los otros derechos de la personalidad reconidos en el artículo 18 de nuestra Constitución, esto es, la Ley Orgánica 1/1982, de 5 de mayo, de protección civil del derecho al honor, a la intimidad personal y familiar y a la propia imagen. No obstante, sí que podemos contar con el recurso a la jurisprudencia existente sobre la relación entre las libertades de expresión y de información y los derechos regulados en la Ley Orgánica 1/1982.

No encuentro justificación al hecho de que la AGPD considere que el BOE, por existir obligación legal de publicar los indultos, queda exento del deber de cancelación de oficio que impone a todo responsable de fichero el artículo 4.5 LOPD, sobre todo si tenemos en cuenta la declaración de inconstitucionalidad por STC 292/2002 del artículo 24.2 LOPD. En mi opinión transcurrido el plazo de prescripción del delito que hubiera sido indultado procedería la cancelación de oficio, consistente en este caso no en la supresión de los datos personales del indultado, sino en la anonimización de los datos de carácter personal por efecto de la obligación legal de publicación en el BOE no sometida a plazo determinado.

Al menos podría haber declarado la AGPD que el BOE procedió adecuadamente con la anonimización de los datos de carácter personal en lugar de tan sólo apuntarlo como algo positivo. A lo que debería haber añadido que se debía haber hecho de oficio, indicando el momento oportuno para la cancelación, aunque entiendo que reconocer esto implica el reconocimiento de una importante carga para el BOE dada toda la casuísitca de publicación de infracciones administrativas, resoluciones judiciales,... que debería gestionarse de acuerdo con el principio de calidad de datos en su versión de cancelación de los datos y que sería una pesadilla.

Recordemos que esta obligación de anonimización existe con respecto al CENDOJ en lo que a la publicación de resoluciones judiciales se refiere (aunque no con respecto a los datos de abogados y procuradores en su faceta profesional), y si bien no en el caso del Tribunal Constitucional .

A lo que sumaría el hecho de que en la resolución del profesor y Google la AGPD reconoce que el hecho de que los datos se mantengan accesibles en Internet atenta contra la dignidad del profesor. Pero, ¿qué protección se consigue evitando la indexación tan sólo por Google y no por otros buscadores o servicios como http://www.archive.org/ y siguiendo los datos accesibles en el BOE incluso sin la anonimización que la AGPD parece entender no era obligatoria?

Finalmente, no quisiera dejar sin apuntar la inseguridad jurídica a la que conduce el régimen de cancelación que la AGPD interpreta existe con respecto al BOE, tomándola en cuenta junto con la consideración de éste y de otros Diarios Oficiales como fuentes accesibles al público. Y ello aunque quienes empleen datos personales recabados de estas fuentes deban cumplir con el deber de información que les impone, según las finalidades pretendidas, el artículo 5.4 o el 5.5 párrafo 2 LOPD pudiendo dar con ello pie al ejercicio del derecho de oposición de los afectados ya sea ante el Diario Oficial en cuestión o ante el responsable del fichero que tomó los datos de éste, como sucede en el caso del profesor y del BOE.

Álvaro Del Hoyo
Departamento de Consultoría

lunes 21 de enero de 2008

Seguridad en teclados inalámbricos a 27 Mhz

Personalmente no soy muy aficionado a los teclados inalámbricos, no es que me guste tener la mesa llena de cables pero en el fondo tampoco me molestan tanto y eso de que en el momento más inoportuno se agoten la pilas y deje de funcionar, tengas que tener unas pilas cargadas para cambiarlas ... en definitiva que me parece menos incordio tener un cablecito por encima de la mesa.

Luego está la eterna pregunta, serán realmente seguros estos teclados. En las especificaciones técnicas de la inmensa mayoría dice que el tráfico está cifrado pero ¿como de seguro es este cifrado? Al fin y al cabo estamos lanzando al aire (cierto es que hasta distancias no muy lejanas, quizá puedan llegar hasta unos 5 metros dependiendo del modelo y la carga de las pilas) contraseñas de cuentas bancarias, cuentas de email y todo tipo de información privada y de carácter personal o laboral.

Esta misma duda les asalto a investigadores de la empresa suiza Dreamlab Technologies. En el informe se analiza el nivel de seguridad de algunos de los modelos más populares de teclados inalámbricos a 27 Mhz. Este estudio responde a nuestras inquietudes o más bien, podemos decir que nos deja aún más inquietos. El cifrado utilizado no pasa de ser una simple operación lógica XOR contra una clave de un solo byte que se genera aleatoriamente en el proceso de asociación entre el teclado y el receptor. Esto quiere decir que si estamos escuchando el tráfico y vemos los paquetes en el proceso de asociación, inmediatamente tenemos la clave de cifrado y somos capaces de ver lo que se está escribiendo en ese teclado. No obstante, si no tenemos la suerte de ver el intercambio de la clave en el proceso de asociación no pasa nada, sólo tenemos 256 claves diferentes para probar. Eso quiere decir que con cualquier ordenador por lento que sea (o con otro dispositivos como una PDA, smart-phone, etc) seríamos capaces de obtener la clave por fuerza bruta en poco tiempo. Para muestra, la presentación de los autores del estudio en la que muestran como capturan lo que se está escribiendo en varios teclados.

En definitiva, yo me quedo con mi teclado con cable de toda la vida.



Guzmán Santafé
S21sec labs

¿Qué ocurre realmente tras nuestros sitios web?

Las aplicaciones web construidas actualmente integran múltiples tecnologías,
lo que implica presumiblemente falta de cohesión en cuanto a la seguridad.
Es muy difícil desarrollar una aplicación web razonablemente segura e imposible hacerlo totalmente segura, pero existen tecnologías que nos
pueden ayudar a prevenir riesgos.

Situémonos ante un servicio web que exponemos públicamente.
No importa la seguridad de tu firewall, el diseño de tu red, la paranoia de
tu sistema de detección de intrusos, ni el cifrado de tus datos.
Si hospedas una página web deberás permitir el acceso a los puertos 80/443.




Por lo que deberemos pensar en proteger ese "agujero" que debemos tener
abierto inevitablemente para dar servicio web.
La seguridad a nivel de aplicación se ha convertido en el riesgo número uno para las organizaciónes hoy día. ver SANS top 20.

Parece que la historia se repite, hace años, el firewall de red, era la panacea de la seguridad, hoy día no se concibe red o equipo sin firewall. Pero actualmente, este mismo firewall no puede dar respuesta a todos los problemas asociados a la red y a las aplicaciones que en ella se sostienen.
Para mitigar este tipo de riesgos, existe desde hace ya unos años, una tecnología diseñada para proteger los sitios web y aplicaciones vulnerables, con múltiples propósitos más allá del bloqueo de ataques.
Esta tecnología es capaz de prevenir ataques que los firewalls de red no podrían, ni los sistemas de detección de intrusos actuales serían capaces de reconocer. Estamos hablando de lo que se conoce como WAF (Web Application Firewall), ver pila Tcp/Ip.
También la puedes encontrar como "Sistema de detección de intrusos web" o "Monitor de seguridad HTTP".

Para comprender su funcionamiento y despliegue, tendríamos que revisar primero conceptos como reverse proxy o surrogate, pero esto, esta fuera de este artículo.
Existen aplicaciones comerciales y Open Source, no nombraremos ninguna. Nos centraremos únicamente en los aspectos más importantes que poseen, -más allá del bloqueo de ataques- y la información que nos pueden proporcionar sobre que sucede realmente en nuestros sitios web.

Actualmente, ¿cuantas de las siguientes preguntas podríamos contestar?

  • ¿Serías capaz de inspeccionar el tráfico SSL de tu sitio web?
  • -¿Los logs de tu web contienen toda la información necesaria en caso de auditoría web?. La mayoría de aplicaciones tienen los archivos de log tipo CLF, esos no me sirven.
  • -¿Podrías identificar defectos de aplicaciones web a través de los logs?, y poder reportarlo así al equipo de desarrollo web.
  • -¿Y fugas de información?. Números de la seguridad social, tarjetas de crédito..
  • -¿Y ataques y vulnerabilidades web?

Lo anterior son preguntas que podríamos responder afirmativamente si tuvieramos en nuestro sitio web un Firewall de aplicación. Pero como en todo, demasiada información se puede volver en nuestra contra, por eso, necesitamos sistemas que recopilen, analicen y nos muestren de forma clara que es lo que está ocurriendo "behind the scenes".

Por último, pregúntate a ti mismo: Si hubiera una vulnerabilidad en tu sitio web que está siendo explotada actualmente pero no dispones de ningún sistema para que te avise de ello, ¿cómo vas a detectar que estás siendo atacado? ¿durante cuanto tiempo continuaría el ataque hasta que algún signo externo mostrase que las cosas no funcionan bien?
¿Sabemos realmente lo que ocurre tras nuestros sitios web?, ¿poseen nuestros logs la suficiente información?

Emilio Casbas
S21sec Labs

sábado 19 de enero de 2008

Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo de la Ley Orgánica 15/1999

Sin haber aún tenido demasiado tiempo para leer el Dictamen del Consejo de Estado 1909/2007, hoy nos encontramos con que ya tenemos publicado en el BOE el Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal.

El 19 de abril empieza el baile.

Álvaro Del Hoyo
Departamento de Consultoría

viernes 18 de enero de 2008

Dictamen del Consejo de Estado 1909/2007 sobre el nuevo Reglamento de desarrollo de la LOPD

En los últimos años hemos tenido bastantes debates internos en el departamento de Consultoría con ocasión de la recepción de los diferentes borradores del proyecto de Real Decreto que apruebe el Reglamento de desarrollo de la LOPD. Estos debates aún siguen produciéndose a la espera de la publicación en el BOE del Real Decreto que finalmente fue aprobado por el Consejo de Ministros el pasado 21 de diciembre de 2007.

En el Dictamen del Consejo de Estado 1909/2007 se vienen a listar los comentarios hechos a la última versión del borrador del Real Decreto (del mismo septiembre de 2007) y el Consejo de Estado emite su opinión acerca del mismo, teniendo especial trascendencia lo dicho en relación a la técnica legislativa empleada en la generación del Real Decreto, centro de uno de nuestros debates.

El texto de este definitivo Real Decreto viene a incluir algunas de las correcciones, modificaciones y adiciones propuestas en el mencionado Dictamen del Consejo de Estado.

En lo que a la conservación de los datos de tráfico y localización se refiere destacaría el comentario de la Dirección General para el Desarrollo de la Sociedad de la Información acerca del nivel de protección exigible actualmente y en el futuro a estos datos, cuestión sobre la que vendré en un próximo post.

Que aproveche su lectura a quienes estén interesados.

Álvaro Del Hoyo
Departamento de Consultoría

miércoles 16 de enero de 2008

Sentido Crítico

Este es uno de los sentidos, junto con el sentido común, que más valor tiene a la hora de evitar ser objeto de un hoax.

Estos son correos que difunden información falsa "pseudo-cientifica" sobre algún tema, lo que hace unos años era un rumor que se extiende lentamente, ahora es una avalancha que llega a oidos de todos en cuestion de dias o incluso horas. En esta era de internet, ademas de la velocidad de transmisión, el hoax o rumor cuenta con dos aliados que antaño no tenia:

a) Credibilidad: Todo lo que nos diga internet es cierto. Estamos tan acostumbrados a buscar información en internet que adjudicamos a todo lo que proceda de ella un nivel de veracidad superior al que nos dicta nuestros sentidos común y crítico u otras fuentes, p.ej. una enciplopedia o nuestro médico o profesor.
b) Exceso de desinformación: Este tipo de mensajes ya no nos habla de nuestra vecina o de cosas que conozcamos. Hablan de productos químicos, de descubrimientos científicos, de secuestros de personas en terceros paises, de oportunidades en bolsa; hay tantas cosas de las que no sabemos...

Cuando nos llega uno de estos mensajes, p. ej. diciendo que la Universidad de Miskatonik ha demostrado que tal producto de tal empresa tiene un compuesto cancerígeno, enseguida mandamos de nuevo el mensaje a todos nuestros contactos de internet para informarles. No nos paramos pensar en:
a) ¿Quién ha redactado esta información?
b) ¿Dónde puedo contrastar esta información?
c) ¿Quién se beneficia de esta información?
d) Si la noticia es cierta y tan grave, ¿Por qué no sale en prensa y televisión? ¿Y en las versiones digitales en la red?

Todas estas preguntas nos la plantea nuestro sentido crítico, ese mismo que nos hizo avanzar cuando estudiábamos, ¿por que esto es así y no de otra manera?.

¿Será este post cierto? ¿Te estoy engañando, manipulando?

¿Dónde puedo encontrar más información?

Eduardo Morrás González
S21SecLabs

Backtrack y S21sec

Backtrack es la distribución de linux por excelencia utilizada por Auditores de seguridad. Esta distribución es la evolución de la unión de otras dos distribuciones muy conocidas: WHAX y Auditor.

Actualmente es una de las pocas distribuciones que existen, ya que se posicionó como la distribución de facto debido a su gran calidad.

En última distribución podemos encontrar 7 herramientas desarrolladas por miembros de S21sec:


SING:
Herramienta de testeo IP/ICMP con múltiples opciones. Detección remota de SSOO, fragmentación, MAC spoofing, etc. Evolución del programa ping.

Yersinia:
Yersinia es una herramienta para verificar la correcta configuración y seguridad de los dispositivos de red.

Subdomainer:
Herramienta para obtener subdominios de diversas fuentes como buscadores, servidores pgp, etc.

Metagoofil:
Herramienta para obtener información sensible de documentos públicos encontrados a través de Google.

TheHarvester:
Herramienta para obtener direcciones de correo de un dominio particular a través de diversos buscadores.

SQLBif:
Herramienta para detectar la existencia de vulnerabilidades de Inyección de código SQL.

Metoscan:
La función de Metoscan es la de detectar los metodos soportados por un servidor Web.


Nos enorgullece ser parte de este proyecto, y es por eso que los invitamos a descargarse la distribución.

Web page de Backtrack

Christian Martorella
Departamento de Auditoría

martes 15 de enero de 2008

RFID comprometido

Aunque no es novedad nuestra preocupación por la poca concienciación de los fabricantes en materia de seguridad a la hora de crear nuevos dispositivos RFID en una industria incipiente y con enorme potencial, recientemente salieron a la luz en la 24 edición del "Chaos Communication Congress" los esfuerzos de un trabajo de investigación que pone en entredicho la seguridad de los tags RFID de Mifare en su modalidad "Classic" (con capacidades de 1Kb y 4Kb) con autenticación y cifrado del tráfico de datos intercambiado por el inherentemente inseguro medio aéreo.



En paralelo a este importante suceso, cabe destacar las vulnerabilidades que dos estudiantes de la Universidad de Amsterdam encontraron en el sistema de cobro de tarifas sin contacto y desechable del metro de su ciudad (se emplea Mifare Ultralight, que carece de autenticación y cifrado de las comunicaciones), llamado "OV Chipkaart", el pasado Julio de 2007, comunicándolo a la empresa responsable de la explotación del sistema inalámbrico. Sin embargo, recientemente se ha conseguido romper de nuevo su revisada seguridad mediante un sencillo ataque de repetición haciendo uso de las posibilidades de emulación que ofrece un amplio abanico de hardware RFID cuyos esquemas están disponibles al público: RFID Guardian, OpenPICC o Proxmark III.

La trascendencia de estos trabajos ha hecho que de momento no salga a la luz pública información sobre estos asuntos en profundidad, ya que actualmente el sistema RFID de Mifare es empleado por millones de personas en escenarios de cobro de tarifas de transporte público o control de accesos (que se supone son una evolución de los sistemas RFID clásicos de baja frecuencia) utilizados en empresas o en el mercado doméstico (vehículos y domótica) en todo el mundo. De hecho, las repercusiones de estas recientes investigaciones se empiezan a notar a nivel gubernamental en Holanda, existiendo un cierto miedo a un hipotético caos general que puedan provocar estas vulnerabilidades en malas manos, así como la difícil justificación del cambio de otros modelos de pago de tarifas que llevan tiempo en funcionamiento (como las tarjetas de banda magnética o las tarjetas chip) y de los que se conoce el riesgo implícito a su tecnología.

De hecho, ahora mismo esta teniendo lugar una sesión palamentaria "Tweede Kamer" en Holanda para hablar de la tarjeta de transporte del país. Parece que tras hacerse pública esta noticia ayer mismo, un grupo de partidos políticos holandeses se estan oponiendo al futuro despliegue generalizado de la versión de la tarjeta recargable con tecnología RFID.

Es interesante hacer una pequeña reflexión sobre lo ocurrido, que no deja de ser una consecuencia del ya demostrado inútil empeño que pone la industria en basar su seguridad en el "security through obscurity" (seguridad mediante la oscuridad). Mientras los esfuerzos fuera del ámbito empresarial productor de semiconductores se centra en potenciar la creación de una I+D+i en la que las universidades participen e innoven con algoritmias que mejoren la seguridad y eficiencia de estos pequeños dispositivos con importantes restricciones en potencia y consumo, la industria sigue reticente y esceptica a escuchar, colaborar y adoptar todo este trabajo que no traería más que beneficios para todos.

¿Hasta cuándo tendremos que esperar para que las empresas tecnológicas de este tipo se percaten de que van por el camino equivocado a la hora de abarcar la seguridad de sus dispositivos desde una óptica ocultista? ¿Optarán por presionar a los gobiernos en pro de una dura legislación que transforme en ilegal las labores de auditoría de este tipo de dispositivos y criptosistemas cerrados, muchas veces llevados por grupos universitarios de investigación con nula malicia?

Álvaro Ramón
S21sec labs

domingo 13 de enero de 2008

¿Revisión del desarrollo legislativo del artículo 18 de la Constitución?

El articulo 18 de nuestra Constitución nos reconoce los derechos fundamentales al honor, la intimidad personal y familiar, la propia imagen, la inviolabilidad del domicilio, el secreto de las comunicaciones y la autodeterminación informativa. Aunque todos estos derechos fundamentales son de aplicación inmediata, sí que es cierto que su desarrollo mediante la ley, que ha de ser orgánica, es necesario para la concreción de su alcance y sus límites a fin de contar con mayor seguridad jurídica.

Existían dudas sobre si el artículo 18.4 de la Constitución reconocía un nuevo derecho fundamental o si por el contrario era una garantía constitucional. La incógnita la vino a despejar el Tribunal Constitucional en sus sentencias STC 290/2000 y STC 292/2000, reconociendo como nuevo derecho fundamental la autodeterminación informativa que la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal había venido a desarrollar.

La Exposición de motivos de la Ley Orgánica 1/1982, de 5 de mayo, de protección civil del derecho al honor, a la intimidad personal y familiar, y a la propia imagen dice que viene a desarrollar el artículo 18.1 de la Constitución, si bien también en la definición de las intromisiones ilegítimas está desarrollando el secreto a las comunicaciones. Habría que añadir que el secreto de las comunicaciones se regula también en la Ley de Enjuiciamiento Criminal y en la Ley Orgánica 2/2002, de 6 de mayo, Reguladora del Control Judicial Previo del Centro Nacional de Inteligencia y también que este derecho ha tenido un desarrollo jurisprudencial bastante intenso.

En esta noticia de El País se indicaba el pasado martes que la Asociación de Internautas ha presentando varios escritos al Defensor del Pueblo solicitando que presente recurso de inconstitucionalidad a la Ley 25/2007, de 18 de octubre, de conservación de datos relativos a las comunicaciones electrónicas y a las redes públicas de comunicaciones. Esta Ley desarrolla el secreto de las comunicaciones y el derecho a la autodeterminación informativa, pues los datos de tráfico constituyen lo que se ha denominado el "ámbito externo" del secreto a las comunicaciones (al igual que los datos de localización en redes móviles) y resulta evidente que ambos tipos de datos revisten carácter personal.

Anteriormente, la Asociación de Internautas ya había presentado recurso contra el Real Decreto 424/2005, de 15 de abril, por el que se aprueba el Reglamento sobre las condiciones para la prestación de servicios de comunicaciones electrónicas, el servicio universal y la protección de los usuarios. Este Real Decreto desarrolla el secreto de las comunicaciones y la protección de los datos de carácter personal de los usuarios y abonados de servicios de comunicaciones electrónicas, aparte de otros aspectos regulados en la Ley 32/2003, de 3 de noviembre, General de Telecomunicaciones. Más en concreto, lo que se venía a poner en tela de juicio por la Asociación de Internautas era el resultado de la regulación sobre la interceptación de las comunicaciones, el Sistema Integral de Interceptación de Comunicaciones Electrónicas (SITEL).

En definitiva, a fin de aportar claridad y seguridad jurídica en cuanto a los derechos fundamentales reconocidos en los apartados 1 a 3 del artículo 18 de la Constitución, hace ya tiempo que viene siendo necesario que nuestro legislador dicte una o varias disposiciones orgánicas que regulen aquellos derechos de forma ordenada -siguiendo los trámites específicos establecidos por nuestra Constitución-, sistemática y alineada con los criterios jurisprudenciales sentados hasta la fecha por nuestros órganos judiciales. Aunque aún mejorable, esta normativa podría tomar como referencia la LOPD y su normativa de desarrollo.


Álvaro Del Hoyo
Departamento de Consultoría

sábado 12 de enero de 2008

S21SEC-039-en: Safari 2 Denial of Service

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

- S21Sec Advisory -

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

Title: Safari 2 Denial of Service
ID: S21SEC-039-en
Severity: Medium - Remote DoS
History: 15.Jul.2007 Vulnerability discovered
22.Jul.2007 Vendor contacted
27.Jul.2007 Vendor confirmed the vulnerability
26.Oct.2007 Safari 3 in Leopard
14.Nov.2007 Safari 3 in Tiger

Scope: Remote Denial of Service
Platforms: OSX
Author: David Barroso (dbarroso@s21sec.com)
URL: http://www.s21sec.com/avisos/s21sec-039-en.txt
Release: Public


[ SUMMARY ]

According to Wikipedia, Safari is a web browser developed by Apple Inc. and included in Mac OS X.
It was first released as a public beta on January 7, 2003, as the default browser
in Mac OS X v10.3. A beta version for Microsoft Windows was released for the first time on
June 11, 2007 with support for Windows XP and Windows Vista


[ AFFECTED VERSIONS ]

Following versions are affected with this issue:

- Safari Version 2 (MacOSX Version)


[ DESCRIPTION ]

A crafted HTML page can make Safari crash when trying to parse the page due to an unproper validation in the KHTML Webkit.

Example:

<html>
<head>
<title>Safari Exploit</title>
</head>
<body>

<form>
<div id="foo" style="display:none;">
<table>
<tr>
<td></td>
</tr>
</table>
</div>
<input type="text" />
</form>
</body>
</html>

[ WORKAROUND ]

The vulnerability was patched in Safari 3, officially released on October, 2007 (Leopard) and November, 2007 (Tiger).


[ ACKNOWLEDGMENTS ]

This vulnerability have been found and researched by:

- David Barroso S21sec labs


[ REFERENCES ]

* Wikipedia. Safari
http://en.wikipedia.org/wiki/Safari_%28web_browser%29

* Safari
http://www.apple.com/safari/

* S21Sec
http://www.s21sec.com

* Blog S21sec
http://blog.s21sec.com