Durante la semana pasada, además de las charlas que me llevaron a que terminara como estoy ahora - completamente devastado - tuvimos la oportunidad de tener una reunión con el equipo de Microsoft en Barcelona, encabezado por el propio Satya Nadella. Como sabéis, en el Mobile World Congress de este año la estrella fue Mobile Connect, que recibió varios premios y mucha atención por parte de todos los medios.
Figura 1: Cuando los mensajes SMS son realmente el First Factor of Authentication
En la reunión, aprovechando que teníamos a Satya delante, le pedí personalmente que se pensara en utilizar Mobile Connect como First Factor of Authentication en Office 365, porque al final, si se confía en un SMS como sistema de recuperación de contraseñas, es exactamente lo mismo que si Mobile Connect fuera el First Factor of Authentication pero más incómodo y menos robusto.
Número de teléfono como recuperación de contraseña
Ya sea vía llamada, o vía mensaje SMS, casi todos los principales servicios en Internet confían en el número de teléfono como forma de recuperar la contraseña. Si has añadido el número a Facebook, Google o Twitter, puedes recuperar la contraseña siempre mediante un envío de un SMS con un OTP que se puede utilizar para poner una nueva contraseña.
Figura 2: Cuenta de Gmail con recuperación de password basada en SMS
Muchos usuarios, realizan este proceso de manera sistemática, ya que se confían en que siempre pueden recuperarla y cada vez que quieren entrar recuperan la contraseña, ponen una nueva, y entran. Esto sucede especialmente en aquellos servicios en los que no se entra de manera continuada, sino de forma esporádica.
Figura 3: Cuenta de Twitter de El Rubius protegida por SMS
Al final si el servicio confía en el SMS como forma de recuperar la contraseña, sería mucho más cómodo para el usuario confiar en el número de teléfono como First Factor of Authentication, vía Mobile Connect. Esto permite que no haya ninguna contraseña que el usuario deba recordar y pueda usar siempre el número de teléfono para autenticarse, pero sin la necesidad de tener que pegarse con las políticas de contraseñas para poner una nueva contraseña en cada caso.
Figura 4: La cuenta de Twitter de Satya está asociada al correo de Microsoft.com. Los correos de Microsoft.com utilizan el SMS y el Phone Call como 2FA.
Por supuesto, nuestra visión es que hay que darle al usuario todas las posibilidades robustas que se pueda para que él elija en cada caso qué mecanismo quiere utilizar, ya que existen muchas formas robustas de autenticarse y, dependiendo de la casuística, un usuario puede decantarse por una u otra dependiendo de cada caso.
Figura 5: La cuenta Twitter de Pablo Iglesias está asociada la cuenta de Podemos.info. Podemos.info usa un RoundCube sin 2FA (Solo password). Deberían poner Latch al menos };)
Si confías en el el SMS para recuperar la contraseña, entonces podrías simplificar la vida a tus usuarios simplemente permitiendo que se autentiquen con Mobile Connect, así será mucho más cómodo y aún más robusto, ya que podrías eliminar las contraseñas para muchos usuarios que no deseen utilizar esa forma de autenticarse.
He subido a mi canal Youtube la conferencia que impartí durante la Dot Net Conference Spain 2016 sobre cómo explotar algunos trucos sucios, rápidos y bien conocidos en aplicaciones web escritas en .NET que no han sido tratadas con mucho cariño.
Figura 1: Some dirty, quick and well-known tricks to hack your bad .NET WebApps
La conferencia duran 40 minutos y las diapositivas ya las subí a mi canal Slideshare y las tenéis publicadas junto con la demo que hice con los mensajes de error en Microsoft.com. Este es el vídeo completo de la charla que puedes ver ahora si no pudiste asistir al evento, o si preferiste no venir a verla en directo por ver otras charlas o por cualquier otra razón - tú sabrás tus motivos -.
Figura 2: Some dirty, quick and well-known tricks to hack your bad .NET WebApps de Chema Alonso
El evento, estuvo muy divertido y, a título personal, fue volver a reencontrarme con amigos y compañeros MVP. Os dejo esta foto que me hice con Lluis Franco (@lluisfranco) tras haberme invitado a pasar un fin de semana "romántico" en su Andorra - tomo la palabra e iré para allá con la tabla Exclaibur - que refleja cómo me lo pasé aquel día, a pesar de que luego acabara devastado por el cansancio.
También acepto el resto de invitaciones para ir a visitar Girona, para ir a comer y cenar por Madrid, León y Galicia que me hicisteis, que ya que os ofrecisteis hay que aprovechar }:P.
Como viene siendo tradición, un año más he vuelto a "torturar" a mis alumn@s con un examen al final del módulo dedicado a la seguridad de las aplicaciones. No me gusta ser excesivamente maligno, así que más o menos pongo siempre los mismos exámenes pero cambiando las preguntas porque, en este módulo de 16 horas, yo quiero que se lleven claros algunos conceptos básicos fundamentales. Estas son las preguntas que les tocó responder ayer a última hora. Anímate a responderlas.
Figura 1: Examen del módulo de Seguridad en las Aplicaciones del Máster de Seguridad de la UEM. Curso 2015 -2016
A ver si saco algo de tiempo para responderlas yo - y las del último examen que también las dejé sin responder - para que tengáis la información completa. Al final os dejo la lista de exámenes de años anteriores.
1.- Tu organización dispone de una aplicación web de cara a internet consistente en ofertar productos y servicios con pasarela de pago propia desarrollada para una plataforma Java utilizando tecnologías Linux. Los datos de registro de los clientes, así como los pedidos solicitados se almacenan en una base de datos MySQL de la empresa, gestionando todo el proceso a través de la lógica de negocio. ¿Qué mecanismos de protección consideras que deberían implantarse en cuanto a la arquitectura de servidores y servicios se refiere? Cita reglas generales de fortificación y algunas medias concretas que creas convenientes para implantar.
2.- Una aplicación web de una empresa proporciona un proceso de autenticación que sospechamos un tanto curioso. Al analizar el código fuente de la página, vemos que la aplicación utiliza para el proceso de autenticación un Applet de Java con extensión JAR. Tras probar varios intentos de inicio de sesión, detectamos que no se produce Post-Back al servidor. ¿Qué fallo de seguridad podría tener esta aplicación y cómo debería investigarse?
3.- En qué consiste un ataque de tipo SQL Injection inband a una aplicación web. Pon algún ejemplo para sacar la lista de usuarios Tabla_USERS[Campo_Login, Campo_Password] de una web en un entorno vulnerable.
4.- Describe en qué consisten los ataques de Time-Based Blind SQL Injection y con qué tipo de funciones o métodos pueden realizarse en los motores de base de datos SQL Server, MySQL, Oracle y Access.
5.- Describe con tus palabras en qué consisten los ataques de LFI y cómo los podrías descubrir en una aplicación web durante un proceso de auditoría.
6.- Una aplicación web en PHP con MySQL es vulnerable a SQL Injection. Se quiere extraer la versión de Mysql realizando un ataque de Blind SQL injection. Describe el proceso que habría que realizar.
7.- En una aplicación web, la aplicación autentica a los usuarios con un árbol LDAP, para ello, cada usuario tiene un atributo uid y un atributo password. El programador ha filtrado el * y utiliza la función crypt antes de usar la contraseña en una consulta AND LDAP como ésta.
V_username: valor de usuario introducido en la página web por el cliente. V_passwd: valor de contraseña introducido en la página web por el cliente. C_passwd =crypt(v_passwd) Consulta que da acceso o no a la aplicación: (&(uid=+v_username+)(password=+c_passwd+)) ¿Con qué inyección LDAP conseguirías entrar si la se está utilizando un árbol LDAP basado en OpenLDAP?
8.- Como administrador del sistema de tu organización, una mañana monitorizas que el antivirus corporativo reporta un malware en un directorio local del servidor donde tu empresa tiene alojado el sitio web. El archivo en cuarentena es un fichero denominado C99.php. ¿Qué tipo de ataque estás sufriendo y qué fallo o fallos de seguridad se ha/n podido aprovechar?
9.- Describe un posible método para robar una cookie marcada como HTTP-Only con un ataque de XSS y describe en qué entornos funcionaría.
10.- Describe como se puede hacer un proceso de hijacking de sesión a un usuario de una red social en la que las cookies no vayan por HTTP-s si en la web no se ha descubierto ninguna vulnerabilidad de código (ni SQLi, ni XSS).
Tiempo: 1 hora
Por si te animas a seguir, aquí tienes los exámenes de años anteriores, que también los he ido publicando en el blog.
Como suelo hacer todos los meses, antes de que acabe el mes os traigo un adelanto de los eventos, cursos y conferencias en los que voy a participar yo, alguno de mis compañeros de Eleven Paths o apoyamos desde 0xWord. A lo largo del mes suele ir habiendo modificaciones de fechas, lugares o agenda, por lo que este mismo artículo lo iré actualizando según tenga la información disponible. Esto es lo que a día de hoy tengo en el radar.
Figura 1: Calendario para Marzo
RSA Conference - San Francisco
Este lunes que viene da comienzo la RSA Conference en San Francisco. Yo estaré allí con la delegación de Telefónica - Eleven Paths, donde además hemos conseguido por primera vez un pequeño booth para poder tener un punto de referencia de todos. Además, participaré en un par de eventos por los que me pasaré. El evento de ICEX y el organizado por Dtex. Luego, ya sabéis, cenas, reuniones y demás actividades para aprovechar el punto de contacto a nivel mundial que es la RSA Conference.
RootedCON - Madrid
Al mismo tiempo que tiene lugar la RSA Conference, tiene lugar en Madrid una nueva edición de la RootedCON que en esta ocasión será en los Cines Kinépolis de la Ciudad de la Imagen. Yo voy a dar una charla con mi compañero Pablo González sobre un tema con el que hemos estado jugando este mes, así que espero que os guste lo que os hemos preparado.
Regreso el viernes por la tarde de San Francisco para dar la charla el sábado por la tarde en el día de cierre del evento. Habrá stand de 0xWord allí, así que si quieres un libro, puedes reservarlo y recogerlo allí poniéndote en contacto por correo en info @ 0xWord.com.
KeyNote en Infarma - Madrid
El día 9 de Marzo, en el evento de Infarma, me han invitado a dar una conferencia sobre estafas en Intentet, así que aprovecharé para hablar de la "magia". El evento tiene lugar en IFEMA y tienes toda la información en la web: Infarma 2016.
Durante el mes de Marzo también darán comienzo tres cursos online de The Security Sentinel. Como sabéis, colaboramos con ellos desde 0xWord proporcionando los materiales. El calendario de los cursos disponibles este mes es el siguiente:
Por lo demás, ya sabéis, seguiré posteando mis cosas por aquí, recopilando las charlas en mi canal de Youtube y saldrán los últimos capítulos de la webserie "Risk Alert" que he grabado con A3Media.
A lo largo de los últimos años he hablado mucho de los mensajes de error en las aplicaciones web. Mucho y de muchas formas distintas, así que si quieres pasar un buen rato leyendo, hazte algunas búsquedas sobre los posts de los últimos diez años que seguro que te salen muchos resultados. Los mensajes de error son fabulosos en la fase de footprinting y fingerprinting de una auditoría de seguridad, y te pueden llevar a descubrir pequeños bugs en los sitios adecuados para conseguir encontrar el camino directo al gran bug, por eso yo suelo pedir a mis compañeros que sean muy cuidadosos con ellos.
Figura 1: La higiene en los mensajes de error. Un ejemplo con Microsoft.com
En el evento de ayer, en la Dot Net Conference, - donde he de reconocer que me lo pasé como un niño pequeño con tanto amigo y gente buena - utilicé como primera parte de la charla sobre "Some dirty, quick and well-known tricks to hack your bad .NET WebApps" una referencia y una demo a la importancia de la higiene con los mensajes de error. Aquí tenéis las diapos de la charla.
La primera de las demos la hice con la web de Microsoft.com, en la que, dependiendo de cómo fuerces los errores obtienes resultados diferentes. Estos son los ejemplos.
Como podéis ver, seis mensajes de error distintos para el mismo dominio. La culpa es porque hay muchos elementos que pueden interceptar la petición de error y dar la respuesta ante cada situación. Una buena política higiénica debería devolver siempre los mismos mensajes.
Figura 8: Momentos durante mi charla de ayer }:)
Aprovecho para mandar un saludo, un fuerte abrazo y un beso a tod@s los que os acercasteis a mí para saludarme, pedirme una foto o charlar un rato dentro del evento. Hicisteis que me volviera a sentir como esperaba sentirme cuando regresé de mis vacaciones. Si no te saludé, deberías haberte acercado a decir "hola", que seguro que me hubiera encantado hacerlo.
El documento ha estado circulando este sábado por varios lugares en la red, y parece ser que apareció entre los archivos filtrados por Edward Snowden pero pasó por debajo de mi radar. Supongo que debido a la cantidad de información que salió publicada en esa época no lo leí. En el documento aparece una lista de varios investigadores de seguridad - algunos amigos míos y otros conocidos - que hemos estado dentro del espionaje del programa PRISM realizado a ciudadanos extranjeros a Estados Unidos.
Figura 1: Un documento en Pastebin dice que la NSA me ha estado espiando.
Esto quiere decir que nosotros y todos los que han tenido comunicaciones con nosotros dentro del tiempo que ha estado este programa funcionando, podríamos haber visto nuestras conversaciones interceptadas. El contenido del archivo publicado lo podéis leer en Pastebin, y la verdad es que aunque siempre sospeché que podría pasar esto, no sienta nada bien. No quiero hacer muchas valoraciones sobre esto, así que podéis leer el texto del documento tal y como aparece en Pastebin.
Figura 2: Texto del documento tal y como fue publicado
Desde que lo descubrí he estado obteniendo algún dato más al respecto de lo que aquí se dice, pero prefiero no comentar nada en el blog. La lista de las personas que aparecen en este documento, por si en algún momento en el futuro se borra, es la siguiente, pero toda persona que se haya comunicado con nosotros también habría podido ver interceptada su comunicación y rota su privacidad.
BIRSAN ADRIAN
RYAN ADRIAN
CHEMA ALONSO
DHARROL ALVES
JAMES ARLEN
SIMON ARNOLD
MIKE ARPAIA
ADAM BALDWIN
ANDREA BARISANI
RYAN BARNES
JAY BAVISI
MICHAEL BOMAN
AMY BURG
NEIL BURROWS
PETER CHAN
JOHN CUNNINGHAM
ARTEM DINABURG
TRAVIS DOERING
WILLIAM EDWARDS
ALADDIN ELSTON
MOHSAN FARID
BEN FEINSTEIN
IVAN FONTARENSKY
GORDON FYODOR LYON
LAURENT GAFFIÉ
JUAN GARRIDO CABALLERO
SYLVAIN GAUDREAU
JEAN-GABRIL HAYS
MANUEL HENRY
MYLES HOSFORD
DAVID JACOBY
MEHRDAD JANBEGLOU
SEBASTIEN JEANQUIER
ZSOMBOR KOVACS
NATHALIE LESSARD
CLAUDE LÉVEILLÉE
CRAIG MARSHALL
ANDREW MASON
JAMES NEWMAN
DEVIANT OLLAM
KYLE OSBORN
TYLER PITCHFORD
MATTHEW PLATTEN
SHYAMA ROSE
DRAGOS RUIU
MICHAEL SCHEARER
ROGER SELS
WINDOW SNYDER
MATHIEU THERRIEN
JON WELBORN
Recordad que el programa PRISM permitía a los servicios de la NSA espiar a ciudadanos extranjeros bajo la ley FISA (Foreing Intelligence Survilliance Act), que ha estado funcionando con normalidad hasta el año pasado que fue fuertemente debatida en el congreso.
La semana pasada hablaba de la técnica Network Packet Manipulation con la que podíamos modificar consultas MySQL al vuelo en aquellas conexiones a bases de datos no cifradas. Hablando con Chema Alonso sobre ello llegamos a la conclusión de que podríamos modificar fácilmente las consultas que un WordPress realiza sobre la base de datos. Echando una pensada, podríamos crearnos con un filtro un usuario en el sistema y poder entrar a través del panel de administración en WP-Admin o, incluso, actualizar el campo contraseña de un usuario y robar directamente dicha cuenta. ¿Te imaginas haciendo esto al usuario admin de tu Wordpress?
Figura 1: Hackear un WordPress con Network Packet Manipulation
La primera traba que muchos pueden pensar es: la mayoría de los servidores WordPress instalan en la misma máquina la base de datos y la aplicación web. Esto es cierto, puede que en un alto porcentaje de usuarios este hecho sea así, pero en muchas ocasiones, en entornos empresariales estas dos capas se separan. Es decir, encontraríamos la aplicación web por un lado, y la base de datos por otro.
Figura 2: Escenario de un pentesting interno con servidores independientes
En un escenario de auditoría interna podremos encontrar una oportunidad para realizar este tipo de manipulaciones y poder llegar a tomar el control del gestor de contenidos. Por defecto, la aplicación web de WordPress no va cifrada, y las consultas contra el motor MySQL tampoco, y son tareas de fortificación que deben hacerse para evitar los ataques de red.
Preliminares: Analizando las consultas de WordPress
En primer lugar hay que estudiar qué tipo de peticiones realiza WordPress contra el servidor MySQL. Como se puede ver en la siguiente imagen, las consultas van en plano, por lo que basándonos en el ataque de Network Packet Manipulation podemos modificar las consultas y tomar el control de la máquina.
Figura 3: Consulta SQL en texto plano capturada por la red
El siguiente paso es acudir al panel de control de un WordPress y ver qué tipo de peticiones realiza cuando accedemos a la gestión de usuarios. El objetivo es claro, entender qué consulta SQL o conjunto de consultas SQL realiza la aplicación de WordPress a MySQL cuando damos de alta un nuevo usuario o modificamos algún parámetro.
Figura 4: Forzando la creación de un usuario de WordPress para capturar las consultas
Analizando las peticiones podemos encontrar que la inserción o alta de usuarios se realiza a través de una instrucción SQL de tipo INSERT INTO en la tabla wp_users y se pasan una serie de parámetros. En la imagen inferior se puede visualizar parte de dicha sentencia.
Figura 5: Consulta SQL lanzada para la creación de un usuario de WordPress
La idea será capturar un paquete que encaje con un patrón y modificar la consulta por la que nosotros queramos, por ejemplo una consulta UPDATE que permita modificar la contraseña de un usuario existente con el fin de robar una cuenta, o una inserción que nos permita crear un nuevo usuario en la base de datos.
Ataque 1: Cambiando las passwords a los usuarios
Ahora llega el momento de crear los filtros con Etterfilter. El primer filtro que crearemos será el que nos posibilite cambiar las contraseñas del WordPress. Para ello la sentencia que debemos tener en mente será “UPDATE wp_users SET user_pass = [contraseña hasheada]". Antes de mostrar el filtro debemos tener en cuenta una cosa. En los paquetes de MySQL hay un campo denominado Packet_Length. Este valor le indica al motor de MySQL cuantos bytes debe leer y ejecutar en la base de datos. Debemos localizar una consulta común de WordPress y utilizarla modificando el Packet_Length.
El primer filtro detecta si el paquete está destinado al puerto 3306, que es el que utilizar MySQL por defecto, y decodifica el mensaje filtrando por la palabra “SELECT”. En primer lugar reemplazaremos el Packet_Length, que en el caso del paquete seleccionado es \x49\x00\x00, por el tamaño que estipulemos que será la longitud de nuestra consulta en hexadecimal. En el caso del valor del user_pass pondremos una que queramos, hasheada con el mismo algoritmo que utiliza WordPress.
Figura 6: Filtro para cambiar las passwords a los usuarios de WordPress
Una vez creado el filtro se debe compilar con la herramienta Etterfilter mediante la instrucción etterfilter –o wp.ef wp.filter, siendo wp.filter el nombre del fichero dónde escribimos el filtro. Una vez compilado se debe ejecutar Ettercap para realizar el ataque de MiTM entre el servidor web donde corre WordPress y el servidor donde corre el motor de bases de datos MySQL mediante la instrucción ettercap –T –q –i [interfaz de red] –F wp.ef –M ARP. Si hiciéramos una consulta antes de envenenar con ARP Spoofing veríamos lo siguiente:
Figura 7: Contraseñas cambiadas (no se ha utilizado un hash válido)
El valor de user_pass está preparado para cambiar, aunque en este caso no es un hash real y se ha puesto esa cadena solo para que se vea más claro. Una vez el filtro es ejecutado y un usuario refresca la página principal de control de WordPress se interceptará un paquete MySQL que coincide con lo que nuestro filtro busca y se llevará a cabo el proceso de actualización. Con la ejecución del mismo, todas las contraseñas de las cuentas de WordPress serán modificadas y actualizadas a la contraseña que nosotros queramos, eso sí hasheada.
Figura 8: Nueva contraseña configurada para los usuarios de WordPress
En esta imagen se puede ver el cambio gracias al filtro ejecutado y el ataque de ARP Spoofing. Ahora mismo ya tenemos acceso al WordPress, simplemente conociendo uno de los usuarios, por ejemplo el usuario wordpress o root habrán sido afectados por esta actualización.
Ataque 2: Creando un usuario de WordPress
A continuación os muestro el segundo filtro. Este filtro crea un usuario para que el administrador del WordPress no detecte tanto el robo. La consulta SQL para crear un usuario es INSERT INTO, tal y como hemos visto antes, sobre la tabla wp_users con, al menos, los atributos de contraseña, usuario e id. Hay que tener en cuenta de nuevo el tamaño correcto del paquete.
Figura 9: Filtro para crear un usuario de WordPress
De nuevo elegimos la consulta SQL de tipo SELECT option_val para generar el filtro y reemplazamos el tamaño del paquete por el hexadecimal 0x71, ya que nuestra consulta tiene dicho tamaño.
Figura 10: Ejecución del ataque de Network Packet Manipulation con EtterFilter
De nuevo hay que compilar el filtro con Etterfilter y ejecutar un ataque de spoofing de ARP con la herramienta Ettercap. El resultado es el que se puede ver en la imagen, donde obtenemos un nuevo usuario denominado pablo con un id alto, para no colisionar con otros posibles usuarios, y con la contraseña hasheada que queramos, en ese instante el pentester tendrá acceso al panel de WordPress con este usuario recién creado.
Figura 11: Usuario de WordPress creado correctamente
En conclusión, además de todas las opciones de fortificación de WordPress para evitar ataques a las cuentas de usuario, hay que cifrar las consultas SQL que se realicen entre los frontales web y los motores MySQL. Si un atacante puede colocarse en medio de la comunicación todo el servidor WordPress podría quedar a merced de éste por no haber fortificado la cadena de conexión.
No es ni mucho menos el primer trabajo relativo a técnicas Tempest, ni el primero que roba las claves de cifrado de un sistema con un Side-Chanel, pero sí es el primero que lo hace utilizando emanaciones electromagnéticas sobre claves de cifrado ECDH (Eliptic Curve Diffie-Hellman) aprovechándose de una implementación software "ruidosa" en emanaciones Electro-Magnéticas y la posibilidad de inyectar procesos de descifrado remotamente.
Figura 1: Cómo robar claves de cifrado de curva elíptica en OpenPGP - GnuPG con técnicas Tempest
Esto que, a priori, puede sonar a muchos como un galimatías sin pies ni cabeza, la verdad es que se puede explicar paso a paso para que todo el mundo lo entienda, a ver si soy capaz.
Las Técnicas Tempest
Hace mucho tiempo que se conocen estas técnicas, y consisten en medir la fuga de información que se produce de un sistema informático por culpa de emanaciones físicas del mismo. Desde poder ver lo que se está visualizando en una pantalla a base de medir los cambios en las emanaciones Electro-Magnéticas de la pantalla, hasta descifrar qué es lo que está tecleando alguien en su equipo a base de medir las ondas transmitidas por la mesa con cada golpe de dedo sobre una tecla.
Cada técnica Tempest elige un medio físico para acceder a la fuga de datos que se produce para correlacionar la información que se quiere extraer con el medio físico. Estas emanaciones físicas, ya sean ondas en Radio-Frecuencia, Electro- Magnéticas, el Calor o Vibraciones en superficies, dependerá del hardware que se esté analizando. Este medio será el Side-Channel o Canal Paralelo que utilizará el atacante para leer la información del sistema remotamente.
Figura 3: Equipo del atacante para medir las emanaciones EM del equipo víctima
Las ondas Electro-Magnéticas se han utilizado ya en el pasado para medir las fugas de información que se producen en los chips de las tarjetas hardware en los equipos informáticos. Desde hace tiempo se conoce que es posible saber cuándo un determinado chip está realizando una operación matemática de suma, de resta, de división, o de movimiento de datos. Así que es posible sacar una historia de las operaciones que está realizando. En esta conferencia tienes una explicación de algunas de ellas y una demostración de cómo saber qué operaciones realiza un microprocesador con Tempest.
Figura 4: Conferencia sobre Tecnologías Tempest
Para evitar esta fuga de información, los investigadores llevan ya años trabajando en algoritmos y técnicas para conseguir un hardware menos ruidoso en emanaciones Tempest y en protecciones hardware especiales que bloqueen la fuga de ondas Electro-Magnéticas o de Radio Frecuencia a través de determinadas superficies.
Figura 5: Equipo de la víctima
En este caso, los investigadores han utilizado como víctima de sus grabaciones un equipo portátil Lenovo 3000 N200, del que han medido las ondas EM para poder descifrar las claves de descifrado del algoritmo ECDH remotamente.
Asociar algoritmo a Tempest
Medir la onda es el primer paso, el segundo es reconocer el modo de instrucción en que se encuentra el chip en cada momento. Esto es una asociación ente las emanaciones EM y lo que se conoce del sistema. Es necesario medir previamente con un sistema de entrenamiento cómo se comporta el Side Channel en función de cada instrucción para luego poder reconocer la instrucción que está ejecutando en función de cada emanación.
Figura 6: Pseudocódigo de uno de los algoritmos de libgcrypt
Para conseguir este objetivo, los atacantes utilizaron un sistema bastante inteligente. Su objetivo era descifrar las claves ECDH que eran utilizadas en el cifrado y descifrado de mensajes con OpenPGP. Este software utilizar las librerías libgcryt de GnuPG 2.x de las que ya se conocía, gracias a estudios Tempest anteriores para extracción de claves de cifrado, que era posible asociar las emanaciones a las fases del algoritmo en que se encuentra.
Figura 7: Ajuste de onda EM grabada con partes del algoritmo
Al final, según la fase del algoritmo ECDH en que se encuentre un sistema se emiten unas determinadas emanaciones EM que pueden llevar al atacante a saber qué está haciendo OpenPGP en cada momento. Esto se considera un fallo de seguridad y desde hace tiempo los investigadores recomiendan hacer software menos ruidoso en emanaciones, para evitar los ataques Tempest, e incluso se proponen métricas como SAVAT para conocer el nivel de protección que da un determinado sistema.
Forzar un sistema de cifrado
Conocer el software en detalle que se utiliza en el equipo de la víctima es el primer paso, pero hay que hacer el ajuste, para lo cual los atacantes necesitan conocer no solo cómo se comporta el sistema con el algoritmo, sino como lo hace en cada momento. Para esto utilizaron otro vector de ataque muy interesante, que no es otro que Enigmail, un plugin para usar OpenPGP en Mozilla ThunderBird que descifra automáticamente el correo electrónico según llega.
Figura 8: Enigmail con OpenPGP para Mozilla ThunderBird
Esto le permitía al atacante enviar correos electrónicos cifrados con PGP a la víctima y ver cómo se comporta el Side Channel con cada sistema de cifrado elegido, teniendo en cuenta que conoce, además, la clave de cifrado utilizado. Es decir, que el atacante puede inyectar comportamientos automáticos en el equipo de la víctima por culpa de esta característica de descifrado automático en Enigmail.
Descifrado de las claves
El resto del trabajo consiste en aplicar los vectores de ataque a los ECHD sabiendo cómo está cifrando y descifrando con la clave en cada momento. Es decir, trabajo ingeniería inversa sobre el algoritmo de cifrado en el que se hace un ataque a los bits de la clave K conociendo características especiales de ellos. Esta es la parte puramente criptográfica en la que se hace uso de técnicas de criptoanálisis de la señal.
Figura 9: Reconocimiento de bits en señal EM capturada
La ventaja es que no se hace sobre el mensaje cifrado final, sino sobre las partes del proceso en el algoritmo donde influye el uso da la clave K. Es decir, que se puede ir viendo como varia la señal en cada ciclo del algoritmo durante el cual se está construyendo el mensaje final cifrado y/o el mensaje final descifrado. Si te gusta la criptografía y el criptoanálisis, ya sabes que este libro de los doctores Jorge Ramió y Alfonso Muñoz hace un recorrido sobre ellas: Cifrado de las Comunicaciones Digitales. De la Cifra Clásica a RSA
Conclusiones y Otros ataques Tempest
Las técnicas Tempest ya están muy presentes en nuestro día a día, y todo Canal Paralelo o Side-Channel que se pueda correlacionar con la información de un sistema se convierte en un bug de seguridad que debe protegerse. En el pasado yo he ido "coleccionando" algunos de estos ataques de Side-Channel, así que si te gustan, puedes leer alguno de ellos aquí:
La semana que entra va a ser bastante movida para mí. Estaré a caballo entre Madrid y Barcelona, donde tendré que participar en varios eventos en las dos ciudades. Todas ellas con un cariz totalmente distinto entre sí, lo que me obligará a cambiar el registro en cada una de ellas. Por si os va bien, y os apetece, os dejo información de estos actos.
Figura 1: Un charla con Incibe, un evento con Satya Nadella y un desayuno en Primera Plan@
Un charla sobre con INCIBE en el Mobile World Congress
El INCIBE ha organizado un panel en el Mobile World Congress de Barcelona en el que además del instituto hablaremos Raúl Siles y yo. El panel tiene lugar dentro del Mobile World Capital y será el martes 23 de Febrero de 13:30 a 15:00 horas.
Figura 2: Mobile World Congress 2016
Para poder entrar en el evento hay que tener entrada para el MWC, así que es gratuito, pero no del todo. No os preocupéis, regreso a Barcelona a dar otro evento el mismo jueves, sigue leyendo. Además, desde el lunes por la tarde y todo el martes estaré en el Stand de Telefónica, por si quieres venir a verme.
Un evento con Satya Nadella y Microsoft: Dot Net Spain Conference
El miércoles 24 de Febrero, ahora en Madrid, tendrá lugar la Dot Net Spain Conference en los cines Kinépolis de la Ciudad de la Imagen. En dicho evento hay una agenda brutal con un montón de ponentes entre los que estaré el CEO de Microsoft, Satya Nadella. Pero la agenda es brutal, y el número de ponentes es alto.
Yo daré una charla para hacer amigos allí que he titulado "Some dirty, quick and well-known tricks to hack your bad .NET WebApps", pero creedme que merece la pena revisar la agenda en detalle, porque hay mucho ingeniero de Microsoft y MVP dando charlas. Yo voy a aprovechar para ir a ver a mis amigos Rodrigo Corral, Unai Zorilla o el gran Lluis Franco (@lluisfranco) que se va a dignar a venir desde su Andorra a darnos unas charlas, que merecen la pena cuanto menos.
Desayuno Primera Plan@ con el Periódico de Catalunya
Después de la merecida cena con los MVPs y ponentes del evento del miércoles, el jueves regreso a Barcelona para estar en el Hotel Juan Carlos I en un desayuno organizado por Primera Plan@, de El Periódico de Catalunya. Será de 09:00 a 11:00 y hablaré de identidad digital, passwords, fortificaciones, sistemas de autenticación robustos, etcétera.
Creo que el evento es gratuito y que basta con presentarse a las 09:00 en el hotel para poder acceder al evento, pero ante la duda, podéis contactar con el periódico.
Esa semana, si queréis, continúa también el ciclo TASSI con una charla sobre Hardware Hacking en la Universidad Politécnica de Madrid. Ya os contaré a lo largo de esta semana el calendario de actividades de Marzo, para que os podáis planificar con tiempo, pero antes de que acabe Febrero tenéis también el Curso Online de Análisis Forense.
Este lunes comienza el Mobile World Congress y, sin duda, una de las estrellas de esta edición será Mobile Connect, el nuevo estándar para autenticación en servicios basados en el número de teléfono. Detrás del estándar está la GSMA, que es la organización que aglutina a todas las Telcos del mundo, y nosotros en Eleven Paths hemos estado trabajando fuerte para que Telefónica sea una de las primeras en tenerlo listo y funcionando. Y ya está disponible para que empieces a integrarlo donde quieras.
Figura 1: Ya puedes integrar Mobile Connect en tus servicios
El funcionamiento de Mobile Connect es fácil de entender y se basa en autenticar a los usuarios de cualquier sistema mediante un desafió a la tarjeta SIM de su número de teléfono. Es decir, cuando un usuario se quiere autenticar en un servicio, en lugar de introducir un login_id y una password, pide autenticarse con Mobile Connect e introduce su número de teléfono. El servidor en el que se quiere autenticar comprueba que ese número de teléfono es de uno de sus empleados y entonces solicita a la operadora - a la telco - que verifique si el dueño del número de teléfono realmente se quiere conectar a su sistema.
El servidor se conecta con un servicio de Mobile Connect que ofrece una de las telcos y será la infraestructura de red de las telcos la que busque la SIM del número solicitado para enviar, vía canal de operadora, un mensaje a la SIM del usuario. Ese mensaje hará que se ejecute un programa en la SIM del cliente que le preguntará si quiere autenticarse en ese servicio, y lo hará solicitando diferentes niveles de seguridad, según lo haya requerido el servicio en el que se está autenticando. El siguiente vídeo muestra un ejemplo sencillo de uso.
Figura 2: Ejemplo de login con Mobile Connect
En un nivel de autenticación básica se le solicitará al usuario que dé su aprobación con un clic. En un nivel de aprobación superior se le solicitará el PIN de Mobile Connect. En un nivel de autenticación superior se solicitará el PIN y que luego introduzca un OTP en el servidor web y, en un nivel de autenticación aún superior se le puede exigir que usando FIDO, ponga su huella dactilar para aprobar el acceso con biometría o incluso con el DNIe. Es decisión de lo que quiera el servicio al que se vaya a conectar.
El servicio ya está lanzando en varios países en Telefónica desde hace un tiempo, que lo hemos tenido a prueba, y ya puedes usarlo en Mi Movistar España y en Mi Movistar Perú, donde puedes aprender también a utilizarlo fácilmente.
Figura 4: Mi Movistar Perú permite autenticarse también con Mobile Connect
La ventaja de utilizar Mobile Connect es que el usuario no necesita ni un smartphone ni una conexión de datos, es decir, no necesita que el cliente tenga un plan de Internet en el terminal para poder autenticarse usando Mobile Connect y no se necesita un smartphone porque el cliente de Mobile Connect corre directamente en la SIM del terminal.
Desde ahora ya puedes comenzar a integrar este sistema de autenticación en tus servicios, con lo que podrías tener cualquier servicio en el que si tienes el número de teléfono de tus usuarios podrías autenticarlos con Mobile Connect, lo que además te sirve como forma de verificación de los datos. En la web de Developers de Mobile Connect ya tienes toda la información que necesitas para comenzar a trabajar con él, y en el vídeo siguiente se explica un poco su funcionamiento.
Figura 6: Integración y uso de Mobile Connect
Además, si necesitas ayuda para implementarlo en algún servicio, puedes ponerte en contacto con nuestros ingenieros de Eleven Paths a través de la Comunidad de Eleven Paths, donde hemos abierto una categoría de Mobile Connect para escuchar vuestras ideas, dudas o comentarios. El uso del servicio es gratis para los sistemas de autenticación básica en Internet, así que puedes ponerlo donde quieras en Internet.
Como ya os he contado en el pasado, nuestra visión de autenticación y autorización se basa en crear soluciones robustas adaptadas a las necesidades de los clientes, para permitir que el usuario decida cuál es la forma más cómoda para autenticarse en un sistema en cada caso. Nuestra idea es poder ofrecerle un abanico lo suficientemente grande de opciones como para que sea una experiencia satisfactoria a la vez que segura. Para ello tenemos soluciones de autenticación y de autorización que se pueden implementar todas juntas en un sistema y adaptarse a las necesidades y situaciones del usuario.
Figura 8: Demostraciones de Mobile Connect + Latch + SMS + Biometría
Al final, a lo largo de los últimos tres años hemos construido un ecosistema de tecnologías que generan una solución de identidad digital de las que nos sentimos muy satisfechos, ya que recoge la visión que teníamos al inicio de construir algo centrado en el usuario y robusto. En este artículo que os publiqué contamos nuestra visión de autenticación y autorización, pero se resume bien en esta demostración que hicieron nuestros compañeros durante el último Security Innovation Day (vídeo superior) y durante el Security Day 2015 (vídeo siguiente).
Figura 9: Demos de autenticación con SmartID usando DNIe, Biometría, NFC y Latch.
Además autenticación vía firma digital manuscrita con SealSign
Las piezas tecnológicas que usamos para que luego se apliquen a gusto del usuario y del servicio para los procesos de autenticación y autorización son:
Jugando con todos estas tecnologías, y aplicándolos todos a la vez, un sistema podría requerir uno u otro dependiendo del entorno en el que se encuentre el usuario, o dejar que el usuario elija en cada caso qué es lo que quiere usar para autenticarse. El mundo no debe pararse por las contraseñas y tenemos ya a día de hoy soluciones para hacer la vida más fácil y más segura a los usuarios.
Como cada vez que escribo de un tema que sin duda puede generar opiniones encontradas, dejadme que aclare que estas son todas opiniones personales mías que, para bien o para mal, tengo como ciudadano de la sociedad en la que vivo. Lo comparto con vosotros, en el afán que me ha llevado siempre de contar lo que sé para después de escucharos saber más de lo que conté, así que lo que aquí queda escrito no es nada más que la exteriorización de un proceso de debate interno sobre los acontecimientos acaecidos en los últimos días.
Figura 1: A los CEOs de las multinacionales no los elige el pueblo.
Todo gira ante el deseo del FBI de investigar el terminal iPhone de uno de los miembros de la pareja que mató a 14 personas y dejó heridas a 22 en San Bernardino, Estados Unidos. Para realizar un análisis forense del dispositivo que pueda aclarar las conexiones de los terroristas, saber más sobre las motivaciones y los hechos sucedidos, necesitan saltarse el passcode. Tecnológicamente esto posible en algunas circunstancias y parece que no se ha dado ninguna de ellas en este caso, así que solicitan que Apple desactive una medida de seguridad desbloqueando el terminal, algo que Apple sí que puede hacer.
El objetivo es que Apple permita remotamente abrir el iPhone, se cambie la configuración del borrado automático de la información tras "ene" fallos al introducir el passcode y así poder automatizar un proceso de fuerza bruta contra el passcode y poder averiguarlo. Es necesario descubrir ese passcode porque hay determinados ficheros del sistema operativo - sobre todo aquellos que almacenan claves de servicios remotos como los keychain - que están cifrados con las claves de usuario. En la guía de seguridad de iOS se explica en detalle.
Figura 2: Esquema de Data Protection en iOS
Lo que desea el FBI es que Apple desbloquee con la clave de hardware el sistema operativo, para luego poder hacer algún ataque de fuerza bruta. Esto se podría hacer ya contra un fichero concreto del sistema - cualquier plist o bplist que son formatos de fichero que usa iOS tienen caracteres predecibles al principio que podrían atacarse - o bien deshabilitar la opción de "borrado tras 10 intentos fallidos al passcode" y poner un "robot" a romper el código como en el vídeo de la figura 3. Problemas tecnológicos, al fin y al cabo.
Pero el debate no viene por ahí, sino por si Apple debe ayudar o no a que el gobierno investigue los datos de uno de sus clientes, favoreciendo que se rompa el derecho a la privacidad que Apple promete a sus usuarios. Para poder analizar esto, primero hay que entender los hechos durante el proceso de investigación.
El conflicto de intereses e ideas
Primero el FBI solicitó a Apple el acceso a los datos, dentro del proceso normal de colaboración que Apple y el resto de empresas tecnológicas norteamericanas tienen establecido para que los cuerpos de seguridad de todo el mundo soliciten datos de sus usuarios. Apple ha colaborado en el pasado y colabora actualmente con los cuerpos de seguridad de los estados para resolver casos. En esta ocasión Apple se negó a colaborar, algo que, desde que se vio tan duramente salpicada con las filtraciones de Edward Snowden en las que aparece Apple como una de las piezas del programa PRISM ha hecho en varias ocasiones. El FBI interpuso una denuncia a la justicia, y un juez ha dictaminado que Apple debe colaborar en este caso de terrorismo, pero Apple se ha negado. CEOs de Google, Twitter y Facebook se han sumado a su causa.
Una cosa importante que hay que notar es que la diferencia fundamental entre las apariciones en PRISM y la situación actual, es que en el caso de las filtraciones de Edward Snowden se habla de aplicación de un sistema que no requiere la orden de un juez que aplica la ley, sino que la ley ya permitía espiar a ciudadanos extranjeros sin necesidad de pedir orden judicial.
Figura 4: Diapositiva del programa PRISM donde aparece Apple
Los motivos por los que se ha negado Apple son fáciles de imaginar, suponer o especular, desde un punto de vista puramente empresarial - luego vemos los ideológicos - ya que si se abre esta puerta significaría enviar un mensaje a todos los países del mundo de que el gobierno de USA tiene la posibilidad de desbloquear el iPhone de cualquier persona del mundo, con lo que rápidamente aparecerían "banneos" o bloqueos de iPhone en los procesos de compras de empresas, administraciones públicas e incluso particulares de todo el mundo. Es un mal negocio para Apple enviar este mensaje al mundo. Es malo para el negocio.
Desde el punto de vista ideológico se trata de defender el derecho a la privacidad que todos los individuos tenemos y que si abrimos esa puerta, mañana un gobierno - no solo de USA sino de cualquier lugar del mundo - podría hacer abuso de poder y utilizar esta llave para hacer daño a las personas. La argumentación de "Si no tienes nada que esconder, entonces no tienes nada que temer", es una de las más peligrosas y falsas que he escuchado en mi vida, ya que los tiempos, las ideas y las situaciones cambian.
Yo suelo decir que esta frase debería ser "Si no tienes nada que esconder, entonces no tienes nada que temer... hasta que cambiemos las reglas". Al final, en Rusia ninguna persona tenía ningún motivo para ocultar su sexualidad, hasta que sacaron una ley que estigmatiza algunas de ellas y los convierte en objetivo social vejatorio, o hasta que una revolución cambia los ejes de poder e ideológicos en un país y todo lo que hayas dicho podría volverse en tu contra. A lo largo de la historia tenemos muchos ejemplos de esto.
Presentados estos dos puntos de vista de inicio, me gustaría desarrollar en profundidad mis reflexiones personales al respecto y cuál es el ideario que a mí me lleva a tener una postura concreta a este respecto.
Derechos Universales y la protección de los mismos
El derecho a la privacidad es algo que hay que preservar y cuidar. Estoy de acuerdo con eso, y quién debe ser el garante de que eso sea así es la ley que los ciudadanos construyen en sus sociedades. Me gustan los países donde la legislación protege la privacidad. Y no todas las legislaciones son iguales, ni todas las sociedades. Algunas protegen más la privacidad, otras menos. Algunas protegen el derecho a las personas puedan llevar armas por la calle otras no. Algunas igualan en derechos a los hombres y a las mujeres, otras no.
Me gusta, por mi educación, por mi idiosincrasia, por mis circunstancias existenciales o mis opiniones religiosas, que la ley proteja el derecho a la privacidad de las personas, incluso frente a las grandes compañías y/o especialmente de ellas.
También me gustan las legislaciones que protegen el derecho a la vida, a que las personas no tengan que sufrir una muerte violenta e injusta, o que sean ejecutadas por la decisión arbitraria de alguien que se erija en un determinado instante en juez, jurado y verdugo. Mucho menos, si esta muerte es un acto asociado al lucro personal, la ideología o el mero sadismo.
Me gustan las leyes que protegen la igualdad de derechos sin importar sexo, ideología o sexualidad, que ayudan - a mi entender - a que la sociedad sea mucho más sana en su desarrollo, en su convivencia y en su disfrute.
Y el derecho a la infancia. Me gustan las leyes que protegen a los niños y niñas de nuestra especie como seres que deben acceder a la educación, disfrutar de unos años de cuidados, cariños y juguetes. A salvo de depredadores sexuales, abusos emocionales o violencia física. Una entapa donde debemos invertir en lo que será nuestro futuro. En crear evoluciones mejores de nosotros mismos como seres humanos.
Figura 5: Una mujer pedófila de Valencia buscando hombres pedófilos para tener un bebe y "disfrutarlo" juntos en un foro de la DeepWeb
Defender todos los derechos en un mundo ideal en el que todos fuéramos como hermanos y hermanas no debería generar conflictos, pero la realidad es que los imperfectos humanos generan situaciones en las que los derechos se ven enfrentados, y salvaguardar el derecho a la vida puede implicar tomar decisiones en contra del derecho a la privacidad o viceversa, es decir, salvaguardar el derecho a la privacidad puede significar afectar al derecho a la vida. Esta diatriba recoge el famoso balance entre seguridad y privacidad que debemos solucionar. No es tarea baladí y exige responsabilidad y conocimiento de la ley para una aplicación justa de ese balance.
Para llegar a este balance, primero las personas elegidas por los ciudadanos deberán ser capaces de plasmar en un documento cuáles son los derechos que los ciudadanos de un país desean que sean protegidos, mediante la elaboración de leyes que reflejen la idiosincrasia de una sociedad. Después deberá haber personas en las instituciones que se encarguen de la difícil misión de aplicar, en cada situación, el balance entre seguridad y privacidad marcado por la legislación que los ciudadanos de una sociedad se han otorgado por medio del uso del sistema democrático de su país, y por último, habrá personas que tendrán la difícil misión de ejecutar los dictámenes tomados acorde de esos dictámenes.
Personas y organizaciones en la sociedad donde vivimos deberemos acatar y cumplir la ley para que prevalezca el bien común y la protección de derechos de la mejor manera posible, siempre según las leyes de las que cada país se dota para defenderlos. Y siempre podremos cambiar la ley. A lo largo de los años en los países hemos visto como gobernantes han puesto leyes atendiendo, según ellos, a lo que su pueblo quería, y luego hemos visto como se quitaban o se mantenían. En la democracia, los votos de los ciudadanos a unos partidos políticos u otros dirigen el rumbo del país que una ciudadanía quiere tener.
Leyes injustas, justas y las organizaciones supranacionales
Por supuesto, las creencias y/o ideologías de todas y cada una de las idiosincrasias nacionales que tenemos sobre este globo terráqueo no son iguales, y algunas de las leyes que tienen algunas sociedades son salvajes e incompresibles para gentes de otros idiosincrasias. Me costaría entender que mis conciudadanos llevaran armas por la calle, que se practicara la ablación a las mujeres de mi sociedad o que una mujer pudiera ser apedreada hasta morir por llevar la cara pintada o tener relaciones sexuales extra-maritales. No creo que protejan esas leyes los derechos en los que se funda mi concepto de ser humano.
Seguro que si dos países se intentan poner de acuerdo en todas las leyes no llegarían a un acuerdo en muchos años, pero en los derechos fundamentales y universales sí que nos hemos puesto de acuerdo en cosas básicas con organizaciones supranacionales como la ONU, donde se marcan con una X a aquellos países que tienen unas leyes que no los protegen. No solo se les pone en esa lista, sino que además se les sanciona como forma de reprobación.
Sobre el papel suena bien, pero por desgracia no todo funciona bien. Hay gobiernos totalitarios, personas corruptas en las organizaciones, intereses económicos que condicionan las sanciones, las ejecuciones de las leyes supranacionales y los resultados en los juicios nacionales. Estamos lejos de que el sistema sea perfecto. Muy lejos. Pero bajo mi entender nade de una premisa inicial que debemos seguir preservando. Son los ciudadanos los que dan origen a todo, con su participación en la democracia. Su voto. Su opinión sobre algo.
Empresas y leyes
Las empresas, y más las multinacionales con accionistas, no cuentan con un sistema democrático universal para la elección de sus presidentes. No pueden votar los ciudadanos de un país para elegir qué presidente va a "gobernar" Apple o Google o Twitter o Facebook. No, lo elige el poder del dinero. El poder de quienes controlan más o menos acciones de la compañía, o la suma de muchos pequeños "votos" en forma de acciones más minoritarias.
Tienen su propia democracia interna sí, pero no para preservar los derechos de los ciudadanos - que de eso se deben encargar los gobiernos - sino para conseguir que el valor de los accionistas crezcan. Son empresas con ánimo de lucro que toman decisiones amparadas en principios económicos. Buscan fiscalidades ventajosas, economías de escala, producción más económica, maximizar el margen de beneficio, etcétera. Todo ello, dentro de la ley que los ciudadanos de los países nos hemos dado. Que nos han dado nuestros padres, y los padres de nuestros padres.
Las empresas deben cumplir la ley, porque son parte de nuestras sociedades, pero las reglas del juego de las sociedades las hemos puesto nosotros los ciudadanos. Quienes deben escribir la ley, quienes deben discernir cómo aplicarla, y quienes deben garantizar que se aplique, deben ser instituciones gobernadas por personas que el pueblo pueda votar en democracia. Las personas y organizaciones - incluidas las empresas multinacionales - deben acatarlas.
Las multinacionales como Apple, Google, Twitter o Facebook no pueden erigirse en garantes de una nueva legislación al margen de la ley existente sin que haya sido refrendada por los los ciudadanos. Si la ley le marca a un juez que debe tomar una decisión para el cumplimiento de la ley, los ciudadanos y empresas debemos cumplirla.
Si la ley es injusta, los ciudadanos tenemos el derecho y obligación moral de cambiar la ley, y apoyar con nuestros votos a los políticos que representen mejor nuestro ideario como sociedad, para que reflejen con las leyes lo que nosotros queremos que sea nuestra sociedad. Una empresa no puede ser juez, jurado y ejecutor de las acciones en cada caso según su criterio.
Supongamos que un juez pide a Apple que dé la ubicación de un terminal porque el dueño tiene secuestrada a una niña de 6 años a la que se tiene certeza de que va a violar y matar en menos de 24 horas. ¿Debemos esperar a que Apple dé su beneplácito o debe ser el juez el que ? Supongamos que es necesario que de acceso a una forma de desbloquear el backup en iCloud de un terrorista que ha puesto una bomba en una estación de Metro de una ciudad que va a estallar a lo largo de la próxima semana. ¿Debemos esperar a que Apple se decida a colaborar?
Si no nos gusta la ley cambiemos la ley dentro de la ley
La ley no es el contrato de servicios que "firmamos" por el uso de iTunes, iCloud, iOS, etcétera. Esos contratos deben estar sometidos a la ley. Y si la ley de un país tercero al nuestro es injusta, lo debemos controlar a nivel supranacional con instituciones internacionales. Y si creemos que la ley de nuestra sociedad o país debe evolucionar porque tiene fallos y no se adapta a nuestra realidad o nuestra idiosincrasia actual, debemos cambiarla, pero lo debemos hacer los ciudadanos, y no los presidentes de compañías que no han sido elegidos democraticamente tomando decisiones desde sus puestos de CEO.
Por supuesto, Tim Cook y los CEOs de Twitter, Google o Facebook son tan personas y seres humanos como cualquiera de nosotros. Son tan ciudadanos como cualquiera y tienen todo su derecho a expresar sus opiniones, a apoyar un cambio de la ley, a defender lo que consideran que es justo, a defender el modelo de sociedad que quieren para su país e influir en el modelo de sociedad que quieren para el mundo.
Yo estoy totalmente de acuerdo en algunas de las opiniones que dan sobre el derecho a la privacidad, y he de confesar que comparto muchas de las ideas sobre otros temas sociales y otras acciones de Tim Cook personalmente, pero mi opinión es que no son quién para estar por encima de la legislación en democracia que se dan los ciudadanos de un país, y más cuando lo hacen no a titulo personal, sino a titulo empresarial.
La ley que nos hemos dado, permite que se cambie la ley, así que a los ciudadanos Tim Cook, Mark Zuckerberg, Jack Dorsey y Sundar Pichai hay que darles la oportunidad de que cambien las leyes de sus países e influyan en el cambio de sociedad mundial, que un solo hombre es capaz de motivar los grandes cambios, pero no me gustaría que fueran los garantes de mis derechos como ser humanos multinacionales en lugar de las instituciones de mi país y las instituciones supranacionales que hemos creado.
Sigue El lado del mal en Telegram
Chema Alonso en Mastodon
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
