31 agosto 2010

Comunidad @ SbD

Hace ya mas de 2 años desde que empezó la andadura de este blog, un día hablando de la cantidad de horas que 'perdíamos' hablando sobre temas técnicos se nos ocurrió que podría ser interesante exponerlos en un blog, buscamos un nombre y empezamos. No teníamos ninguna 'meta' definida, simplemente tratar de hablar sobre temas en los que trabajamos / habíamos trabajado, temas de interés y respetar siempre la máxima de contenido original.

Después de dos años es sorprendente como ha crecido el blog, la gente que nos lee, comenta y aporta. Incluso (y pese a que esto de los rankings es como las encuestas electorales), según Wikio somos el blog número 45 en la clasificación de 'Tecnología' mes Julio (y en alguna ocasión hemos estado en el puesto 36). Tenemos casi 1500 followers en nuestra cuenta de Twitter, un montón de gente que ha añadido a nuestros bots de Gtalk / MSN / Facebook y otros tantos que están en nuestros grupos de Facebook y Linkedin.

Últimamente como habréis observado están apareciendo por el blog bastantes colaboraciones por parte de algunas personas, lo cierto es que ha sido una de las cosas mas gratas que nos ha reportado el blog: ver como la gente tiene ganas de implicarse. Algunas veces han sido personas que conocíamos previamente, en otros casos nos han llegado por mail.

El objetivo de este post es tratar de hacer oficial los canales y las formas en las que, si te apetece y quieres, puedes colaborar con nosotros. Estamos abiertos a todo tipo de colaboraciones, si dominas un tema y te apetece escribir un artículo, genial !. En concreto estamos interesados en aportaciones sobre cosas novedosas y temas que tengan cabida en el blog. Si, por ejemplo, has desarrollado alguna herramienta / exploit / técnica y quieres darla a conocer, bienvenida sea.

Creemos firmemente (como incuestionablemente ha quedado claro en la rootedcon) que la comunidad hispanohablante de seguridad goza de un estupendo nivel y hay muchísima gente capaz de asombrarnos con un montón de conceptos interesantes.

Incluso también estamos abiertos a colaboraciones por parte de empresas. Es un tema delicado y como en todo, prima el sentido común. Por ejemplo, alguien que trabaje en 'Menganitos Abogados' empresa con tradición y experiencia en auditorías en LOPD podría estar interesado en contarnos tips sobre ese tipo de auditorias. Evidentemente si 'Menganitos Abogados' vende un pack de 'Auditoria LODP + seguimiento por 4.000 Euros' NO estamos interesados en que nos hables de tus competitivos precios, mas bien lo que buscamos sería un artículo tipo 'Checklist para auditores LOPD' y si lo quieres firmar como 'Menganitos Abogados' no hay ningún problema. ¿Se entiende, verdad?

En principio, la forma mas rápida y eficaz para contactar con nosotros es vía nuestro mail contacto@securitybydefault.com, no obstante, si te quieres dirigir personalmente a alguno de nosotros por algún otro medio, también es valido.

¡¡ Ánimo y muchas gracias a todos por hacer de SbD lo que es !!
Leer más...

30 agosto 2010

Ayudando a creadores de malware despistados

Poniéndome al día en un montón de RSS acumulados, encontré una noticia que me abrió los ojos ante cómo funcionan (o no) ciertas mentes humanas.

En Windows, cuando una aplicación ha ejecutado alguna instrucción no autorizada, el sistema operativo reacciona cerrando la aplicación mostrando una ventana con un mensaje que permite notificar a Microsoft sobre qué ha sucedido en dicha aplicación. La idea es ayudar al equipos de desarrolladores de Microsoft para mejorar las capacidades del sistema operativo y de la integración con las aplicaciones (ya las desarrollen ellos mismos también o por parte de terceros), así como sugerir a los usuarios si algún parche corrige la causa del "cuelgue".

Gracias a esto, según Rocky Heckman, arquitecto senior de seguridad de Microsoft, a lo largo del día, reciben un montón de estas notificaciones, con parte del código (un dump de cierta porción de memoria) que generó el error. El tema está en que muchas de estas notificaciones corresponden a acciones por parte de desarrolladores de virus/malware (con prisa, -podríamos añadir-) que en fase de creación de sus nuevas obras de arte, lógicamente hacen pruebas sobre sus propias máquinas. Al no estar depurado el comportamiento del software, lo normal es que se generen "crashes" de aplicación sobre el sistema operativo y al pulsar el botón "Enviar Informe" de la ventana que se abre (sin leer el texto de la misma), se enviará información preciosa de la creatividad del revolucionario troyano beta directamente a Microsoft. ¿Paradójico no? Precisamente el fabricante del sistema operativo de cuyas vulnerabilidades se quieren aprovechar, reciben información de primera mano directamente de parte de su creador.

Y es que estas cosas pasan cuando no "escuchamos" TODO lo que nuestro sistema operativo nos dice… Pero venga va, ¿quién se lee siempre el texto completo de un EULA cuando lo está instalando? Si el mensaje es muy largo o muy "repleto de letras y líneas" directamente buscamos el botón "Aceptar" y que continúe lo antes posible.

Y pensar que el propio Windows proporciona la posibilidad de deshabilitar la solicitud y envío de informe de errores a Microsoft... Cuántos leaks podrían haberse evitado por parte de estos despistados desarrolladores de malware sobrados de creatividad e ilusión si, en Windows 2000/2003 o XP, hubieran ido al menú contextual de "Mi PC" -> "Propiedades" -> "Informe de Errores" y hubieran configurado convenientemente esta opción para evitar la notificación de errores a los de Redmond.


En caso de que nuestros desarrolladores despistados de malware usen Windows Vista o Windows 7, la forma de deshabilitar la notificación de errores es diferente.
Para ello, ejecutaremos "gpedit.msc" en Inicio -> Ejecutar para abrir la "Configuración de Políticas Locales". En "Administración de Plantillas" -> "Componentes de Windows", modificaremos "Deshabilitar Informes de Error de Windows" a "Habilitado"






Leer más...

29 agosto 2010

Enlaces de la SECmana - 34

Leer más...

28 agosto 2010

Montando nuestro propio proxy web

Seguro que todos hemos usado alguna vez un proxy a través de una web, caracterizados por ser cómodos y funcionar bien. Sin embargo muchas veces para poder usar el servicio plenamente hay que pasar por caja, además de que estamos haciendo uso de algo que nosotros no administramos, por lo que no sabemos si nos están monitorizando, ni qué datos se guardan. La solución a todo esto es montarnos nuestro propio proxy web, y lo podemos hacer programándolo nosotros mismos o usando alguno ya hecho.

PHProxy es un proxy web de código abierto escrito en PHP, y aunque el proyecto está inactivo desde 2007, han surgido otros proyectos que lo mantienen actualizado y lo han mejorado, al final de la entrada están los enlaces.

Tienen la ventaja de que se pueden montar en casi cualquier alojamiento que soporte PHP, incluidos los gratuitos. Una vez subido el funcionamiento es muy sencillo, y hay a nuestra disposición bastantes opciones de navegación y de ofuscación / codificación.



Además, si nuestro servidor admite HTTPS podemos cifrar el tráfico en ese tramo, lo que nos añade una capa de privacidad muy interesante.

Todos los proyectos son muy personalizables, y tienen más opciones que se pueden administrar de forma muy sencilla modificando el código fuente. Si quereis probarlo sin instalarlo, a poco que busqueis en google encontrareis varias páginas donde está disponible (muchas veces personalizado, y/o con publicidad).

Enlaces a los proyectos:
[+] PHProxy
[+] phpr0xy

Artículo por Alberto Ortega Llamas.
Leer más...

27 agosto 2010

Muy pronto... wargame de SecurityByDefault

Desde hace unas semanas se ha estado modelando un proyecto por parte del equipo de Security by Default, algo que teníamos pensado desde hacía tiempo y que consideramos que podría ser interesante.

Como ya sabéis nos hemos encargado de realizar el concurso de hacking de la Campus Party España los dos últimos años, además de la Campus Party Europe que se celebró este mes de Abril. Hemos compartido buenos momentos y conocido a grandes personas. Esto nos ha hecho meditar y querer llegar a toda la gente que se ha quedado con ganas de probar sus habilidades en nuestros retos y que no pudieron asistir a estos eventos. Así que finalmente y con la ayuda de Panda Security lanzaremos un concurso online.

Esta vez estáis todos invitados a lo que será el juego oficial de Security By Default  y del que esperamos sea el comienzo de un encuentro anual, para todos los amantes de la seguridad como somos nosotros mismos. En este sentido queremos que os sintáis participes de este proyecto y sean cuales sean tus habilidades, seas capaz de aprender, entender y compartir tus capacidades con todos los participantes.

Es hora de desempolvar todas esas herramientas porque os enfrentareis a una tanda de pruebas que os harán reír, sufrir y llorar (el orden no es necesariamente así). Por ahora sólo os diremos que os enfrentáis a pruebas de Web, Redes, Trivia, Crypto y Binarios.

El concurso estará un periodo de tiempo en funcionamiento y si eres el más rápido de todos serás  el ganador de un estupendo iPad cedido por nuestro patrocinador. Pero si terminas entre los finalistas no te irás con las manos vacías ya que tendrás también tu premio (que todavía no está decidido).

Os seguiremos informando con el tiempo suficiente para que canceléis todos vuestros planes y podáis dedicaros de pleno al concurso. Pero no os despistéis porque la fecha está mas próxima de lo que pensáis... Mientras podéis releer el blog para ir ampliando vuestra fuente de conocimiento que os hará falta :)


Leer más...

25 agosto 2010

Como bloquear el acceso a Internet al Internet Explorer

Si estás cansado de recomendar el uso de navegadores alternativos a familiares y amigos que delegan en ti "el correcto funcionamiento de su equipo", si te has hartado con la vulnerabilidad de los LNK, o si directamente no te gusta Internet Explorer, puedes bloquear su acceso a Internet y evitar que se utilice para navegar.

Existen múltiples formas de llevar a cabo esta tarea, detallo los pasos de la que más me gusta.

EVITAR CONECTIVIDAD

1.- Configurar el navegador para que utilice un proxy incorrecto: por ejemplo, 127.0.0.1 con el puerto 80, así ni Internet Explorer ni otras aplicaciones que puedan hacer uso de su configuración, tendrán acceso a la red de forma descontrolada. Esta medida es un arma de doble filo, ya que hay muchas aplicaciones que consultan estos datos para tratar de actualizarse o hacer otro tipo de peticiones automáticas. Por lo que hay que considerar que puede tener impacto su implantación.

La configuración de sobra conocida en Herramientas -> Opciones de Internet -> Conexión -> Configuración de LAN.


2.- Restringir la modificación de la configuración del proxy: mediante una política que prohíba su alteración: Inicio->Ejecutar->gpedit.msc

Cambiar "Deshabilitar el cambio de configuración proxy" y "Deshabilitar el cambio de valores de Configuración automática" a Habilitado en las directivas de la Configuración de Usuario -> Plantillas Administrativas -> Componentes de Windows -> Internet Explorer



ELIMINAR EL ACCESO A LA APLICACIÓN

1.- Eliminar el acceso al navegador: evitando que este sea ejecutado por el usuario. Para restringir su uso se puede configurar el control de acceso mediante los Programas Predeterminados del Panel de Control.





Eliminado el permiso al desmarcar la casilla "Habilitar el acceso a este programa" que se muestra junto a Internet Explorer.

Leer más...

24 agosto 2010

Análisis de la gestión de contraseñas en la UCM

En este pequeño artículo voy a exponer cómo se podría realizar un ataque contra los sistemas de recuperación de contraseñas de la UCM pudiendo llegar a obtener el control de la cuenta atacada.

La clave del ataque se encuentra en resetear la contraseña del objetivo, por lo que éste no podrá acceder a los servicios que utilicen dichos credenciales. Por lo tanto, cabe destacar que el acceso que se consigue no es transparente y seguramente tengamos limitado el intervalo de actuación.

¡Comencemos!

Disclaimer:
No me hago responsable del mal uso que pueda darse a esta información. En ningún momento la intención del artículo es el incitar a que se produzcan ataques sobre las cuentas de los alumnos de la UCM, más bien su finalidad es la de concienciar al alumno/universidad de lo fácilmente explotables que son estos sistemas si no se toma, por ambas partes, todas las medidas de seguridad.

1. Campus Virtual (https://cv.ucm.es/CampusVirtual/CambioPropia.do)

Para poder resetar la contraseña del Campus Virtual lo único que se nos pide, en realidad en un primer acercamiento, es el DNI del alumno.

La primera pregunta que me hago cuando me encuentro con éste tipo de sistemas es: ¿será vulnerable a un ataque por Fuerza Bruta (de ahora en adelante FB)? En este caso sí, lo cual posibilita la realización de un ataque aleatorio.

A pesar de lo "cantoso" que es un ataque de FB, podemos utilizarlo para realizar un filtrado de los DNIs pertenecientes a alumnos de la UCM y posteriormente realizar un ataque sobre sus cuentas (o utilizar dicha información para cualquier otro propósito).

¿Y si no queremos realizar un ataque de FB? En el caso de que sea un ataque dirigido hacia un objetivo específico todo se simplifica pues podríamos saber ya desde un principio su DNI o, en caso contrario, buscarlo en Google (CV, listas públicas, etc) o bien acudiendo al registro.

Otra opción podría ser el atacar a un grupo de personas (por ejemplo una clase, etc), y entonces podríamos sacar partido, p.e si se trata de enfermería (entre otras), a las listas que publica la UCM con los turnos de las prácticas en los hospitales universitarios, las cuales contienen nombres, apellidos y DNIs completos!

Bien, ya tenemos el DNI del objetivo pero aun queda un segundo paso, el desafío.

¿Qué es el desafío? Bueno pues no es más que la típica pregunta secreta de siempre. Es un buen sistema si la implementación es correcta y los usuarios están lo suficientemente concienciados como para no facilitar el proceso.

¿Implementación? Me refiero a que el sistema no sea vulnerable a un ataque por FB, por desgracia, es el caso. ¿Concienciación? La mayoría de las veces el ataque se reducirá a un listado de palabras muy común, ¿por qué? pues porque muchos usuarios no se toman en serio éste tipo de peticiones al realizar el registro y nos encontramos que la pregunta y la respuesta es la misma o que la pregunta es del tipo ¿mi fecha de nacimiento?, ¿el nombre de mi perro?, ¿mi color favorito?, etc, teniendo respuestas muy fáciles de sacar.

Por lo tanto, si unimos una mala implementación con unos usuarios que se toman poco en serio los desafíos, nos encontraremos con cuentas extremadamente vulnerables, siendo ambos los culpables.
En sí el sistema no es un desastre, a pesar de que esté mal implementado.

Como opinión personal decir que estos sistemas encargados de manejar reseteos de credenciales tan críticos, como los del Campus Virtual de la universidad, los eliminaría y obligaría a rellenar una instancia y evitando que se pueda hacer online (como hacen en la UAH).

¿Cómo se podría hacer sin realizar modificaciones en los datos que se piden? En primer lugar sería eliminar cualquier intento de FB restringiendo el número de peticiones por IP e implementando un sistema de bloqueo preventivo de la cuenta (ya sea un bloqueo temporal o que haya que acudir a la escuela/facultad a restablecer el servicio).

En segundo lugar sería evitar las dos fases del proceso (DNI y desafío) uniéndolas en uno mismo y en caso de error devolviendo un mensaje del tipo “DNI/Desafío incorrecto” evitando dar información de qué dato es el incorrecto. Por desgracia en este caso no se puede pues el desafío no es una pregunta establecida, sino personalizada por usuario, por lo que se obtiene tras validar el DNI.

2. Activar cuenta (https://idm.ucm.es/cgi-bin/idmActivarAuth.pl)

Éste ataque solo se puede llevar a cabo sobre una cuenta que no haya sido activada, por lo que los objetivos han de ser alumnos de nuevo ingreso, lo cual es perfecto para éstas fechas.

¿Cómo podemos obtener el DNI de un alumno de nuevo ingreso? El formulario de consulta de las notas de las pruebas de acceso es vulnerable a FB por lo que podemos realizar utilizar dicho servicio para realizar el filtrado. Para activar la cuenta se nos pide el DNI del alumno y el código de activación. Para obtener el DNI bastaría con utilizar cualquiera de los métodos anteriormente comentados. Con respecto al código de activación, si atendemos a la ayuda del sistema de recuperación de contraseña veremos que éste sigue una estructura fija dependiente de la diplomatura/licenciatura que eligió el alumno en primera opción y el código postal del mismo. La estructura en sí es la siguiente:

XXX‐XXXXX (CESTUDIO‐CPOSTAL).

Podemos utilizar las redes sociales para obtener ambos datos y reducir mucho el ataque de FB (pues nuevamente es vulnerable a este ataque).

Para la diplomatura podríamos tener suerte y que la haya añadido ya a su perfil de, por ejemplo, Tuenti. En tal caso, bastaría con utilizar los filtros del buscador para averiguarla (a pesar de tener el perfil privado hay demasiada información pública). Si no tenemos suerte deberíamos de añadir esta parte al ataque de FB (serían 103 combinaciones).

Para el código postal bastaría con delimitar su ciudad (al igual que anteriormente, es información accesible por cualquier miembro de la red social), localizar el identificador postal de la misma (se podría utilizar la página de Correos) y añadir al ataque 103 combinaciones de la terminación.

De ésta forma podemos ver que el código de activación podría quedar con una estructura similar a:

‐ Solo hemos obtenido la ciudad: XXX‐28XXX
‐ Hemos tenido suerte con la diplomatura/licenciatura: 050‐28XXX

Como hemos podido ver, el eslabón más débil es el código de activación siendo recomendable que éste no siguiera un patrón, sino que fuera aleatorio y se le entregara al futuro alumno (por ejemplo en la carta de admisión) o que éste tuviera que ir a recogerlo a la secretaría de su centro.

¡Hasta aquí todo! Ya para terminar...

A lo largo del artículo se ha explicado cómo podrían ser atacados los credenciales de la UCM. En muchos casos se ha explicado como atacar a un objetivo aleatorio para demostrar que las cuentas son vulnerables sin tener que conocer al alumno en cuestión. A pesar de esto, el tener un objetivo simplifica mucho el proceso, llegando a ser preocupante el tiempo que se tarda en conseguir acceso a su cuenta.

Como he dicho antes de empezar, no me hago responsable del uso que se haga de ésta información, la intención del artículo es concienciar a los usuarios y obligar a las universidades a prestar verdadera atención a todos los servicios que ofrecen y que éstos han de estar bien implementados pues los datos que manejan no son ninguna tontería.

(Artículo cortesía de Luis Delgado J @ldelgadoj )
Leer más...

23 agosto 2010

Top módulos recomendados para Apache

Una de las características fundamentales de Apache es la ventaja que aporta el poder añadir/habilitar dinámicamente cuantos módulos necesitemos. Digamos que Apache es la base de la pizza sobre la que añadimos los ingredientes a nuestro gusto y necesidades (estoy escribiendo este post cerca de la hora de comer y los ejemplos que se me ocurren son los que son…)

En varios de nuestros blogs favoritos, ya hay buenas guías de securización de Apache, en las que nos hablan de cómo hemos de asignar los permisos, configuración de accesos, ocultar la información mostrada en banners, etc, etc,…

Así pues, únicamente he querido centrarme en hacer una recopilación de aquellos módulos que he utilizado en Apache y que me han valido para dotarlo de un mejor rendimiento, así como de un mejor nivel de protección ante las amenazas a las que el servidor web se encuentra expuesto.


Aceleración
  • mod_gzip/mod_deflate: En general, casi todos los clientes web son capaces de "hablar" HTTP recibiendo los datos comprimidos por parte del servidor. La idea es configurar el servidor web para que sea capaz de servir los datos comprimidos, ahorrando parte del ancho de banda disponible acelerando el tráfico web. Tanto mod_gzip como mod_deflate son capaces de comprimir los datos servidos.
  • mod_cache: Es sobre todo útil cuando se usa a la vez que mod_proxy (se verá más adelante). La idea es que Apache cachee los datos que ya ha servido, y no tenga que procesar las peticiones de nuevo. Este módulo depende a su vez de mod_disk_cache y mod_mem_cache para cachear la información en un espacio de disco o en memoria predefinidos para ello. En el caso de usarse con mod_proxy, la idea es que el servidor web final tenga una carga inferior para los contenidos más utilizados, estando estos cacheados en el servidor Apache que actúa como proxy intermedio.


Confidencialidad y autenticación

  • mod_ssl: El tráfico web HTTP va en claro o sin cifrar. Si queremos ser capaces de hacer que el servidor web trabaje sirviendo datos cifrados desde extremo a extremo mediante HTTPS, debemos habilitar mod_ssl. De esta forma incluso podremos exigir a nuestros clientes la autenticación mediante certificados SSL X.509 de cliente (soportados mediante SSL v3).
  • mod_auth_*: Si queremos que ciertas partes de los datos que servimos vía web requieran otro tipo de autenticación basado en usuario y contraseña, Apache nos provee de una infinidad de módulos para esta funcionalidad. El más básico es mod_auth. Podemos exigir autenticación Básica y Digest comparando los pares usuario/contraseña (o hash de la misma) contra un fichero, por convención llamado .htaccess, y permitir o no el acceso a los datos. Sin embargo, muchas veces se quiere utilizar para autenticar otros servidores de autenticación centralizada como pueden ser Radius, LDAP, Directorio Activo o una base de datos mysql por ejemplo. Para ello contamos con: mod_auth_radius, mod_auth_ldap o mod_auth_mysql por ejemplo.


Protección ante ataques


  • mod_security: Tanto de forma embebida en el servidor web final, como en conjunción con mod_proxy para proteger ante accesos internos, mod_security es la alternativa libre en cuanto al software de Cortafuegos de Aplicación Web (o WAF) de los que hemos hablado varias veces en SbD. La idea es blindar el servidor web ante las peticiones que puedan ser ataques de tipo Inyección SQL o XSS, entre otros...
  • mod_proxy: Una de las mejores maneras de aislar un servidor del mundo exterior es poner un proxy inverso de por medio. De esta manera, publicamos un servidor Apache en este caso hacia fuera y las peticiones se las lleva éste, como se hace en un sistema de correo con un relay que comprueba el spam y los virus. Así, si queremos incluso balancear tráfico entre diferentes servidores web finales, Apache con mod_proxy hará las peticiones hacia los internos. Como se comentó anteriormente, si además utilizamos mod_cache, podremos acelerar la aplicación web al cachear en el proxy inverso según que tipo de contenidos. Lo mismo ocurre con mod_security, al recibir Apache las peticiones, efectuará las que considere sanas hacia el servidor web final, no dejando pasar las demás.
  • mod_evasive/mod_qos/mod_limitipconn/mod_antiloris: Dotar de la mayor disponibilidad posible el sistema es una de las labores de varios módulos diferentes. El más completo de todos es mod_evasive, aunque los otros módulos expuestos son buenas alternativas si sólo queremos limitar la Calidad de Servicio del servidor Apache mediante el ancho de banda y/o número de conexiones desde una determinada IP. Con mod_evasive incluso se puede reaccionar de forma dinámica cuando se detecte un ataque, bloqueando vía IPTables la IP atacante, avisos por correo o syslog, etc,... La idea principal de estos módulos es evitar los ataques de denegación de servicio debido al consumo de los recursos disponibles en el servidor. mod_antiloris está especificado para evitar ataques con la herramienta Slowloris. Lo he probado en una red local y efectivamente lo que antes bloqueaba mi Apache, al aplicarlo, permite que se siga utilizando por otras IPs.
Leer más...

22 agosto 2010

Enlaces de la SECmana - 33


Leer más...

21 agosto 2010

Cifrado en Windows con AxCrypt

En todas las listas y foros de seguridad en los que estoy, esta es una pregunta que en algún momento se ha tratado: "¿Qué aplicación puedo utilizar para mandar archivos cifrados, sin necesidad de que el receptor tenga nada instalado?

Una de las respuestas posibles es la solución OpenSource AxCrypt, un software ligero que se integra en el menú contextual de Windows y permite cifrar un fichero o directorio creando un paquete ejecutable auto-descifrable (Encrypt to EXE) utilizando AES-128. A modo de orientación, estos son los tamaños que ha generado de un documento PDF de 6.3Mb:



Nombre       Tamaño
Doc.pdf (original) 6.332.876
Doc-pdf.exe 6.480.302
Doc-pdf.axx 6.333.166

La aplicación únicamente se puede acceder desde este menú donde se encuentran todas las opciones, incluidas el cambio de idioma al Español.



Entre sus principales ventajas se encuentra un uso muy sencillo, basta con pulsar con el botón derecho sobre el contenido que se desea cifrar y asignarle una contraseña, que posteriormente será compartida mediante otro canal, como por ejemplo vía telefónica.


Una vez enviado el ejecutable generado, muestra una pantalla que solicita la contraseña y desempaqueta los archivos.


Otra característica importante y útil es la inclusión de borrado seguro o wipe (Shred and Delete), con la que rápidamente se eliminan ficheros y directorios asegurando que no podrán serán recuperados.

No es la única herramienta que hace estas funciones, incluso el propio WinRAR permite generar SFX cifrados con las mismas características,  pero por su integración en el sistema operativo, su sencillez y su precio, posiblemente sea una de las mejores opciones.
Leer más...

20 agosto 2010

Ojeada a la seguridad de Jolicloud


Jolicloud es uno de los últimos gritos en cuanto a cloud computing se refiere. Se define como un sistema operativo ideado para netbooks, que nos facilita la gestión de nuestros datos y los servicios que usamos en Internet. Al final, es un sistema operativo que centraliza diferentes servicios externos y facilita su uso. Dicho así parece atractivo, pero por otro lado algo que se basa tanto en la nube necesita unas medidas de seguridad extra, y si no las tiene puede jugarnos una mala pasada.

Hasta hace poco sólo se podía probar mediante invitación, pero en estos momentos está disponible la primera versión del sistema, y cualquiera puede crearse una cuenta y empezar a usarlo.

Puesto que ya está abierto al público, es el momento de ver cómo se han hecho las cosas. Vamos a crearnos una cuenta, y arrancamos la Live CD para probar. Además, vamos a monitorizar el tráfico que genera.

Lo primero que nos pide Jolicloud cuando termina de arrancar es que nos conectemos a Internet para poder iniciar sesión en el ordenador. Una vez preparados iniciamos sesión y vemos qué y cómo ha enviado los datos al servidor:



El nombre de usuario y la contraseña se envían en una petición POST HTTP en claro. ¿SSL? ¿Para qué?

Después de que nuestros credenciales hayan viajado legibles por medio mundo, estamos dentro de nuestro ordenador, con nuestras aplicaciones en local, y un montón de accesos directos a servicios online (Dropbox, Gmail, Facebook, Twitter ...). Vamos a descargar nuestra primera aplicación, que va a ser VLC:


La petición vuelve a ser en claro, indicando la aplicación y la acción a realizar.

Son pocas las peticiones que realiza el propio Jolicloud a sus servidores (y menos mal), el resto están gestionadas por el servicio en cuestión, ya que realmente lo que nos facilita el sistema es un acceso directo a la página web o la aplicación oficial del servicio.

Que cada uno saque sus propias conclusiones.

Artículo por Alberto Ortega Llamas.
Leer más...

19 agosto 2010

Analizando cabeceras HTTP 'just for fun'

Para cualquier persona 'normal' navegar implica abrir un navegador, poner una URL y visualizar la web, lo que sucede entre el navegador y el servidor web para llegar a ese punto normalmente es una conversación HTTP orientada 'a maquinas'.

Aun así resulta curioso dedicar un rato a ojear en modo crudo el flujo del protocolo HTTP para descubrir cosas extrañas.

Primer caso: 'Cookies antediluvianas'

Ignoro el porqué de este tipo de cookies, pero como ya me las he encontrado en varios servidores, supongo que alguna razón de ser habrá, el caso es que ojeando por ejemplo la red social profesional www.linkedin.com nos encontramos con esta extraña cookie (click en la foto para ampliar):

s_leo_auth_token="delete me"; Version=1; Max-Age=0; Expires=Thu, 01-Jan-1970


Una cookie que lleva 'expirada' desde 1970

Otro caso de cookies caducadas http://es.yahoo.com


En este caso, del año pasado. Sin duda, alguna razón debe haber, tal vez sea un método de prueba del servidor web para validar que tienes activada la creación de cookies

Segundo caso: Una de Pareidolias

Este ejemplo está cogido con alfileres y sin duda es pura sugestión mental del 'querer ver'. El caso de www.bing.com que en su política P3P (una especie de información donde se indica el uso que se va a hacer de la información obtenida) se puede leer en el banner 'STA LOC CURA'


Tercer caso: El site de contactos y experimentos

Para el que no lo sepa, www.adultfriendfinder.com es un sitio web de contactos, donde 'Papa y Mama' buscan amiguitos mientras sus hijos montan orgías en Tuenti. En el caso de adultfriendfinder lo extraño que se puede ver es en el header ETAG. Si ojeamos la wikipedia podemos ver que ETAG se emplea para optimizar el uso de la cache de un site web, y sobre el header ETAG: 'is an opaque identifier assigned by a web server to a specific version of a resource' vamos que cada servidor web asigna el valor como quiere, lo normal es encontrarse números grandes o strings sin sentido, en el caso de adultfriendfinder nos encontramos como valor 'TESTBED'


Según la wikipedia un 'TESTBED' es un entorno controlado para hacer pruebas científicas reproducibles (is a platform for experimentation of large development projects. Testbeds allow for rigorous, transparent, and replicable testing of scientific theories, computational tools, and new technologies).

Cuarto caso: Headers para 'Hackers'

El caso mas obvio de modificación con intención de que alguien lo vea lo podemos encontrar en Wordpress.com, que añade el siguiente Header:
X-hacker: If you're reading this, you should visit automattic.com/jobs and apply to join the fun, mention this header.


Una curiosa y divertida forma de reclutar personal
Leer más...

18 agosto 2010

Auditando la seguridad de dispositivos de red con nipper

Todo administrador de redes debería tener esta herramienta dentro de su arsenal, y si no, ahora ya no podrá poner excusas cuando le pidan el estado de seguridad de los dispositivos de red de su empresa. Nipper, Network Infraestructure Parser es una herramienta de auditoría de seguridad de dispositivos de red, tanto routers, como switches o firewalls.

Con nipper únicamente necesitaremos el fichero de configuración del dispositivo que queremos analizar, que servirá como parámetro de entrada de la herramienta (--input) e indicar el nombre que queremos dar al fichero-informe que nos devolverá como salida (--output):

nipper --TIPO_DISPOSITIVO --input=CONFIGURACION.conf --output=SALIDA.html

Nipper es capaz de analizar/parsear las configuraciones de los siguientes elementos de red:
  • 3Com SuperStack 3 Firewall
  • Bay Networks Accelar
  • CheckPoint Firewall Module
  • CheckPoint Management Module
  • Cisco IOS-based Router
  • Cisco IOS-based Catalyst Switch
  • Cisco PIX-based Firewall
  • Cisco ASA-based Firewall
  • Cisco FWSM-based Router
  • Cisco CatOS-based Catalyst
  • Cisco NMP-based Catalyst
  • Cisco Content Services Switch
  • HP ProCurve Switches
  • Juniper NetScreen Firewall
  • Nokia IP Firewall
  • Nortel Passport Device
  • Nortel Ethernet Routing Switch 8300
  • SonicWall SonicOS Firewall
Al ejecutar esta herramienta, en cuestión de unos pocos segundos tendremos como resultado un informe en el que tendremos un resumen de las configuraciones de nuestro dispositivo así como una relación de vulnerabilidades en base a lo analizado. Seguridad sobre contraseñas, servicios que se recomienda deshabilitar, fallos o ausencias de parámetros de configuración, opciones de logging y monitorización, vulnerabilidades asociadas a la versión del sistema operativo...todo vendrá descrito tanto con recomendaciones como con los riesgos asociados a las vulnerabilidades detectadas. 


Con nipper se acompaña un fichero nipper.ini que nos permitirá describir los parámetros de configuración y valores por defecto tanto para el análisis como para los resultados descritos en el informe generado. Se recomienda echarle un vistazo para así tener claro todo lo que se analizará, y dejar bien establecidas las métricas que más se adapten a nuestro entorno.

En caso de que tengáis un dispositivo de los listados anteriormente a mano, únicamente tendréis que obtener su configuración. También existe la posibilidad de configurar nipper para que acceda al dispositivo y obtenga su configuración por SNMP (para más información, teclear nipper --help=SNMP)

¿Que no disponéis de un dispositivo, pero queréis probar la herramienta? Muy sencillo, en nuestra fuente inagotable de ficheros de configuraciones, listados de contraseñas, conversaciones privadas, salidas de keyloggers, como es pastebin, podréis probar nipper descargando cualquiera de los ficheros que aparecen como resultados de la siguiente petición en google (es que el motor de búsqueda en pastebin, como que no es tan bueno...¿verdad?):

inurl:pastebin "Building Configuration..."



Actualmente nipper ya no es gratis: la última versión disponible (y comercial) podréis encontrarla en titania.co.uk (en este enlace podréis revisar las licencias...), pero no todo está perdido. En este otro enlace podréis encontrar las últimas versiones disponibles de nipper como Open Source (0.12.6). Creedme, aunque se trate de una versión que se ha dejado de mantener, es más que suficiente si no podéis sacarle convencer a vuestra empresa que obtenga una licencia de este producto.

Existe un proyecto denominado nipper-ng que intenta mantener el producto actualizado y open source, pero de momento está bastante muerto y tiene pinta de seguir así por un tiempo (únicamente podemos encontrar la última librería disponible, 0.12.6 subida al SVN), crucemos los dedos para que esto cambie pronto.

De todas formas, contamos con otras alternativas para, por lo menos, auditar la seguridad de dispositivos Cisco, como son RAT/NCAT. ¿Alguna recomendación más para este tipo de tareas?

Leer más...

17 agosto 2010

Vigilando la casa cuando no estás

Vacaciones! qué palabra tan maravillosa. Por fin podemos recoger el petate y largarnos fuera de la ciudad en la que hacemos nuestra vida cotidiana, a pegarnos vuelta y vuelta en la playa o disfrutar de lo sano de la montaña.

El problema es que no todo el mundo coge las vacaciones en las mismas fechas. Las bandas organizadas suelen "trabajar" justo cuando nosotros descansamos. Por ello, aparte de tachar de la checklist cortar el agua, el gas y regar las plantas,… deberíamos considerar la protección o vigilancia de nuestra casa para no encontrarnos una desagradable sorpresa al volver.

Una herramienta que permite tener la casa controlada en todo momento es Motion. Simplemente es necesario un ordenador con Linux (Redhat, Debian o cualquiera compilando el tar.gz) o FreeBSD, así como una o varias webcams USB o netcams accesibles vía TCP/IP, ya sean con cable o inalámbricas. Gracias a Motion, al estar activo, por cada cámara configurada, empezará a comparar los fotogramas actuales con los inmediatamente anteriores, de manera que si se detecta que ha habido un número determinado (configurable) de pixels en una de ellas, se considerará como que ha habido movimiento y se grabará a disco.

Fundamentalmente tiene un único fichero de configuración por cada cámara en el que se podrán indicar entre otras cosas:

  • El/los dispositivo/s en sí: Un /dev/videoX en el caso de una cámara V4L (Video 4 Linux) o la URL (con el usuario y la contraseña) del streaming de la netcam que se desea.
  • Por cada cámara, es posible ajustar parámetros del estilo de la saturación, brillo, contraste, etc,…
  • Es necesario también definir el umbral de píxels que queremos permitir por cambio de imagen en cada cámara: lo que definiríamos como "he detectado un movimiento, así que graba a disco!". Esto es imprescindible puesto que las condiciones de luz y calidad de cada cámara no tienen por qué ser las mismas por lo que tiene sentido personalizarlo en cada caso. Igualmente para no tener muchos falsos positivos conviene afinar la configuración de este tipo de parámetros.
  • Importante es también especificamos la ruta dónde queremos guardar los ficheros, ya sean fotogramas sueltos o hacer que grabe en video una secuencia completa de movimiento según sea detectado, así como el formato de los nombres de los ficheros. Es posible configurar una base de datos MySQL o PostgreSQL para guardar todas las imágenes y videos generados.
  • Podemos hacer además que cuando se detecte un movimiento se ejecute un comando determinado. Una buena idea podría ser utilizar Tweetme! para avisarnos vía twitter estemos dónde estemos que algo ha pasado.
  • Si queremos monitorizar de forma continua lo que detecta cada cámara, al levantar el servicio Motion, podremos acceder a un puerto (configurable) que nos muestre por streaming lo que la cámara está viendo en cada momento.
  • Es útil hacer que se guarde un snapshot cada X segundos, que permita acceder a la última imagen disponible de cada cámara vía web. En mi caso dispongo de una aplicación para iPhone llamada "Webcams" que permite en un momento dado conectarse para ver cómo están tus cámaras (y aquellas webcams públicas que configures)
Hay diferentes GUIs para poder acceder a la estructura de directorios y previsualizar qué ha ocurrido en nuestra ausencia. Llevo utilizando Motion desde 2003 con la GUI MotionCGI aunque el proyecto no esté mantenido actualmente, he ido efectuando yo mis propias modificaciones en la instalación para que sea válido.

Felices y tranquilas vacaciones!
Leer más...

16 agosto 2010

Fortificación de MySQL - 2/3

Parte 1 de 3
Parte 2 de 3
Parte 3 de 3


Continuamos con la segunda entrada sobre fortificación de MySQL.

7.- Uso de los mínimos privilegios: aplicable a versiones anteriores del motor 5.x. Las bases de datos se han de almacenar propiedad del usuario mysql u otro creado para tal propósito sin privilegios de administración del sistema operativo.
Para comprobar los permisos:

shell> ls -l /var/lib/mysql 
Todos los directorios deberían mostrarse como usuario mysql y grupo mysql, con permisos 700 o lo que es lo mismo: "drwx------". Para modificar el usuario y grupo de un directorio y posteriormente sus permisos:
shell> chown mysql:mysql /var/lib/mysql/mibbdd
shell> chmod 700 /var/lib/mysql/mibbdd

El servicio ha de ser ejecutado con este usuario, que además no puede tener permisos para conectarse localmente. En sistemas Unix, el usuario ha de tener como shell el binario /sbin/nologin

Para comprobar la shell:
shell> grep mysql /etc/passwd
mysql:x:27:491:MySQL Server:/var/lib/mysql:/bin/bash 
Para cambiar la shell:
shell> chsh -s /sbin/nologin mysql 

En el caso de Windows, el usuario ha de estar incluido en los Deny log on locally y ejecutado como usuario NETWORK_SERVICE

8.- Permisos de administración en usuarios: la base de datos dispone de usuarios al igual que el sistema operativo, root es el administrador y únicamente debería ser utilizado para tareas de gestión como altas y bajas de otros usuarios, modificación de permisos, etcétera. Es importante que no se use al usuario root para el acceso a datos. Al igual que los usuarios que tratan datos (selects, inserts o updates) no han de tener habilitados permisos especiales, ya que en caso de encontrarse una inyección de código podrían ejecutarse tareas con privilegios mayores.

Para consultar la lista de usuarios y sus permisos:
mysql> use mysql;
mysql; select * from user;
Para ver los permisos de un usuario en concreto:
mysql> show grants for ‘root’@’localhost’;
El siguiente ejemplo muestra la modificación del usuario "miuser" en la base de datos "mibbdd", dejando únicamente INSERT, SELECT, UPDATE y DELETE:
mysql> show grants for miuser@localhost;
+--------------------------------------------------------------------------------------+
| Grants for miuser@localhost                                                         |
+--------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'miuser'@'localhost' IDENTIFIED BY PASSWORD '6212cdea5883c099' |
| GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX,
 ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW,
 CREATE ROUTINE, ALTER ROUTINE ON `mibbdd`.* TO 'miuser'@'localhost' |
+--------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)

mysql> revoke all privileges on mibbdd.* from 'miuser'@'localhost';
Query OK, 0 rows affected (0.11 sec)

mysql> show grants for miuser@localhost;
+--------------------------------------------------------------------------------------+
| Grants for miuser@localhost                                                          |
+--------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'miuser'@'localhost' IDENTIFIED BY PASSWORD '6212cdea5883c099' |
+--------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> grant select,insert,update,delete on mibbdd.* to 'miuser'@'localhost';
Query OK, 0 rows affected (0.00 sec)

mysql> show grants for miuser@localhost;
+--------------------------------------------------------------------------------------+
| Grants for miuser@localhost                                                          |
+--------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'miuser'@'localhost' IDENTIFIED BY PASSWORD '6212cdea5883c099' |
| GRANT SELECT, INSERT, UPDATE, DELETE ON `mibbdd`.* TO 'miuser'@'localhost'           |
+--------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)
9.- Eliminación de visualización de base de datos: con esta medida se pretende que los usuarios no puedan conocer que otras bases de datos se encuentran en el servidor, eliminando el acceso comando SHOW DATABASES. Para aplicar esta opción, se puede arrancar el servicio mysqld con el parámetro "--skip-show-database" o añadir al archivo de configuración este mismo nombre:
[mysqld]
skip-show-database
Si por algún motivo se desea asignar este privilegio a un usuario, se puede llevar a cabo mediante el GRANT correspondiente.

10.- Configuración de los registros: siempre y cuando el sistema no haga demasiadas peticiones, se pueden almacenar todas las peticiones que reciba el servicio. Esta opción no es recomendable si la base de datos tiene mucho tráfico ya que genera mucha carga e información en disco. Para activarla, modificar el archivo my.cnf con:
[mysqld]
log=/var/log/mylogfile
Este fichero log, al igual que el de registro, como el de errores, el archivo binario, o el de consultas lentas solo han de tener permisos para los usuarios mysql y root. Puede causar problemas importantes de confidencialidad si otros usuarios del sistema tienen acceso.

11.- Almacenar los datos de la base de datos en una partición distinta al sistema operativo: evitando que la base de datos sufra pérdidas por ataques de denegación de servicio que llenen el disco duro libre del sistema operativo.
[mysqld]
datadir=/path/dir
12.- Eliminación del historial del cliente de MySQL: que almacena los comandos ejecutados por el cliente mysql y puede facilitar información crítica. Para configurarlo, añadir la siguiente línea al /etc/profile:
declare -r MYSQL_HISTFILE=/dev/null
Además es recomendable crear un enlace de los ficheros a /dev/null también.

shell> ln -s /dev/null $HOME/.mysql_history
13.- Comprobación de contraseñas almacenadas en texto claro: que se guardan en la variable de entorno MYSQL_PWD y en el archivo de configuración, bajo la directiva password.

Para evitar que se use la variable de entorno añadir al archivo /etc/profile:
declare -r MYSQL_PWD
En el archivo de configuración comprobar que no existe la linea "password":
[client]
password=TuContraseña


Referencias:
Leer más...

15 agosto 2010

Enlaces de la SECmana - 32

Como buena sección dentro de un programa, se merece una entrada con algo de ritmo: 
<música-tecno-de-fondo> En-en-en-la-la-ces  de la sec-sec-sec-mana </música-tecno-de-fondo>

  • Parche para Aircrack  y soporte al ataque de migración de modo WPA en Cisco.
  • SecurityGarden es un portal que recopila herramientas. Esperemos que pronto tengan versión en inglés o español
  • Con la aplicación web mxtoolbox se ejecutan pruebas de configuración DNS y correo electrónico sobre dominios. Otra opción interesante es el procesamiento de las cabeceras de un correo electrónico para su visualización en formato inteligible.
  • PhreakVids colecciona una lista de videos de Phreaking
  • Asegurando memcache en 2 minutos (más los que lleve leerse la entrada) 
  • Solución a una de las pruebas del CTF de Defcon 18 por parte del grupo PainSec.
  • Liberada la aplicación para el análisis de código PHP  RIPS 0.32 de FluxReiners, conocidos en todos los concursos de hacking.
  • Maracon, una backdoor que se inyecta en  WARs
  • Análisis en profundidad del troyano para Android Trojan-SMS.AndroidOS.FakePlayer.a por Jaime Blasco
  • KiTTY (Windows), una alternativa muy interesante a PuTTY.
  • Smashing the Stack in 2010 (PDF)
Leer más...

14 agosto 2010

Cuando 'Privado' significa 'casi privado'

Desde hace algún tiempo los navegadores han incorporado un método de navegación al que han denominado privado en el que se supone que toda actividad que se realice desde ese modo, debe quedar entre tu y tu conciencia.

Como viene siendo habitual cualquier axioma que implique 'certeza absoluta' suele permanecer así hasta que alguien lo mira con cierto detenimiento.

En el caso de los Navegadores y su modo privado, así ha sido. Los cuatro grandes de la navegación: Internet Explorer, Firefox, Chrome y Safari implementan el modo privado de una forma inconsistente y que permite obtener mas datos de los debidos.
El estudio disponible aquí (y bastante denso, muy de corte universitario) se puede resumir en lo siguiente:

Un navegador debería tener como 'metas' los siguientes puntos:

  • Al navegar de forma privada y luego / antes de forma normal en un site web, este no debería poder distinguir entre  uno y otro visitante (Consideraciones de IP aparte)
  • Un servidor web no debería poder distinguir al mismo usuario si este se conecta al servidor web empleando dos sesiones privadas diferentes. (Es decir, se conecta en modo privado, cierra, abre el navegador en modo privado y vuelve a conectar)
  • Un servidor web no debería poder distinguir si un usuario está usando el modo privado durante la navegación
Como se puede ver en el estudio publicado, esas tres máximas de la privacidad son subvertidas de diferentes formas.
Ejemplos de 'leaks' que no deberían estar ahí:
  • Algunos navegadores almacenan tanto en el lado 'publico' como 'privado' la actividad SSL basada en certificados digitales, es decir, aquellos que se han generado durante la navegación
  • Igualmente, algunos navegadores almacenan en modo publico / privado certificados 'self signed' (no validados por CAs de confianza) permitiendo acceder a ellos en ambos modos
  • Ficheros descargados durante la navegación privada
  • Conexiones Netbios: Explorer permite y entiende links tipo \\unamaquina\unrecurso, si un usuario en modo privado realiza una petición de ese tipo, estará enviando junto al intento de conexión mucha información.
  • Ciertas extensiones como 'No Script' que almacenan y manejan listas blancas / negras de hosts, no tienen en consideración el modo privado, por lo que tratan y almacenan los datos de forma indistinta en lado privado / lado normal
Como nota curiosa, los investigadores de la universidad de Stanford diseñaron un tipo de ataque basado en 'CSS History Hacking' (ver nuestra maquina de Zoltar) por el cual eran capaces de averiguar si alguien estaba usando el modo privado / no privado durante la navegación. Contrataron dos campañas de anuncios, una de ellas para un sitio 'de mayores' y otra en una tienda de regalos. Empleando su sistema de tracking para usuarios con navegación privada, llegaron a la conclusión de que el porcentaje de uso en un sitio 'porno' era bastante superior que en el de una tienda normal.
Leer más...

13 agosto 2010

Retos forenses, practicar para avanzar.

Los análisis forenses son un tipo de trabajo que requiere personal altamente cualificados y preparado para que su ejecución sea satisfactoria y su resultado favorable.

Pese a que existe mucha literatura en libros y blogs lo mejor es practicar con casos lo más reales y variopintos posibles que hagan enfrentarse a cada uno de los problemas que vayan surgiendo. De esta forma será difícil olvidar lo que se sudó y cuando una situación similar se presente, será sencillo dar con la solución.

Con este propósito distintas organizaciones, blogs y compañías publican concursos y retos de análisis forense en los que se puede participar. Generalmente se descarga una imagen o archivo y se solicita la solución en un documento técnico y otro ejecutivo.

A continuación hemos recopilado algunos de los más populares, en muchos casos ya resueltos... ¡¡pero no hagáis trampa!!
Leer más...

12 agosto 2010

A las BlackBerry le huele el aliento, pero todos la besan

No, la imagen no es de la ferretería-café de Luke, hace referencia al culebrón que tienen montados los canadienses de RIM y sus BlackBerry con la seguridad en sus dispositivos móviles o mejor dicho, en el diseño de la arquitectura de comunicaciones y la centralización de sus sistemas en países no controlados por gobiernos que desean controlar (y espiar)  las comunicaciones.

Ya hace cuatro años se podían ver análisis profundos de esta plataforma en la Blackhat, y algún ataque en Defcon. Pero las alertas empezaron a sonar cuando la mismísima NSA le prohibió al recién elegido honoluluense utilizar el terminal BlackBerry que tanto le gustaba y que  le deberían "arrancar de las manos" como si fuese el rifle Winchester de Charlton Heston.

Aunque al final, he can, y se salió con la suya. Imagino que por la falta de imaginación y las esperpénticas alternativas de las que se hablaba.

Desde ese momento no se pone en duda la seguridad de los servicios de Blackberry, más bien lo que desean los gobiernos es poder acceder a la información que transmiten.

El siguiente capítulo es en el 2008 cuando la India exige a RIM las claves para descifrar tráfico y mensajes electrónicos, aunque finalmente no lo ven necesario. Por lo menos, hasta la semana pasada, donde sus antiguos miedos volvieron a surgir levantando nuevamente la reclamación.

Otro asalto exactamente igual ésta ocurriendo con Arabia Saudí, Emiratos Arabes e Indonesia este mes de Agosto, y del que esperamos noticias, ya que por el momento solo se ha acordado instalar un servidor en Arabia Saudí, evitando más conflictos en este país.

El último golpe que ha recibido Research In Motion es el gobierno Alemán que no permite a sus ministros el uso de esta tecnología (tal y como hizo la NSA) sustituyendola por el terminal movil SiMKo 2 (la M bien podría ser de Merkel, por la publicidad que les hace). Aunque aquí no parece haber discusión.

¿Qué opináis? No, aún no, primero deberíamos entender bien cómo funciona su sistema, aquí unos enlaces por dónde empezar:


Leer más...