Select Page
Dia mundial de la contraseña

Dia mundial de la contraseña

En el marco del Día Mundial de la Contraseña 2025, resulta crucial reflexionar sobre dos desafíos persistentes en el ámbito de la ciberseguridad: la permanencia de las contraseñas como principal método de autenticación y el agotamiento de los usuarios frente a las crecientes exigencias de seguridad.

Primero, las contraseñas siguen siendo la norma. A pesar del empuje de nuevas tecnologías, más del 58% de los usuarios aún utiliza combinaciones de nombre de usuario y contraseña para sus cuentas personales, y el 54% en entornos corporativos, según el informe global de Yubico 2024. A esto se suma que el 60% de las personas admite reutilizar contraseñas en distintos servicios, y un preocupante 13% declara usar la misma en todas sus cuentas, como señala una encuesta de JumpCloud. Este patrón de comportamiento se mantiene a pesar de los reiterados avisos de seguridad y los incidentes de filtraciones masivas que afectan a millones de usuarios cada año.

Segundo, la mayoría de los usuarios comunes se ven superados por las exigencias y recomendaciones de seguridad. Pedirles que creen claves únicas, largas, alfanuméricas, que las cambien regularmente y activen factores múltiples de autenticación termina siendo, en muchos casos, contraproducente. La sobrecarga cognitiva los empuja a adoptar prácticas poco seguras como escribir contraseñas en papel o usar combinaciones fácilmente adivinables. Un estudio de Security.org muestra que el 70% de los estadounidenses se siente abrumado por la cantidad de contraseñas que debe gestionar, y apenas un 36% ha adoptado gestores de contraseñas, a pesar de su efectividad.

En medio de esta discusión, aparece como solución definitiva el salto al modelo passwordless, con tecnologías específicas como passkeys. Sin embargo, a pesar del creciente entusiasmo por esta tecnología como alternativa segura y sin contraseñas, la realidad actual muestra que su adopción aún está en etapas iniciales. Según un informe de la FIDO Alliance, aunque el 74% de los consumidores están familiarizados con las passkeys, solo el 38% las habilita siempre que es posible. Además, aunque el 93.43% de los dispositivos son técnicamente compatibles con passkeys, su implementación efectiva en plataformas y servicios sigue siendo limitada. ​

Por otro lado, en el ámbito empresarial, un estudio de HID Global revela que el 87% de las organizaciones han implementado o están en proceso de implementar passkeys. Sin embargo, este despliegue se centra principalmente en usuarios con acceso a datos sensibles, y solo el 21% de las empresas planea una implementación total. Las principales barreras incluyen la complejidad, los costos y la falta de claridad sobre cómo proceder. ​

Esto significa que, la implementación de mecanismos de passwordless como passkeys, depende de que los responsables de las aplicaciones lo adopten e implementen. Pero….

Desde el punto de vista de los usuarios, mientras tengan que acceder a sitios o aplicaciones que usen las contraseñas tradicionales están obligados a utilizar el antiguo método.

En resumen, aunque las passkeys representan un avance significativo hacia una autenticación más segura y conveniente, su adopción masiva aún enfrenta desafíos técnicos y de usabilidad. Por lo tanto, en los próximos cinco años, es probable que las contraseñas sigan siendo una parte integral de la autenticación digital.

Por eso, se considera que durante el período de transición hacia el “passwordless total”, la solución de compromiso más efectiva hoy consiste la utilización de gestores de contraseñas pero pensados para usuarios finales. Es decir, con un alto nivel de seguridad pero lo más transparente posibles. Estos sistemas alivian la carga del usuario, permiten generar claves robustas y únicas, y pueden integrarse fácilmente con navegadores y dispositivos móviles. Lo importante es que cuenten con altos estándares de seguridad, como cifrado de extremo a extremo, autenticación biométrica y arquitectura de conocimiento cero y almacenamiento seguro que evite un único punto de falla. En un contexto donde las amenazas se automatizan y la fatiga del usuario es cada vez mayor, hacer de la seguridad algo invisible pero robusto es el mejor camino posible.

El futuro indudablemente va a ser passwordless, pero en el presente, gestionar bien las contraseñas sigue siendo esencial.

Ciberataque a SMS

Ciberataque a SMS

pasó desapercibida interceptación de 30.000 mensajes de textos

Los atacantes lograron interceptar en tiempo real más de 30.000 mensajes de textos y permitieron la apropiación masiva de cuentas.

Un reciente ciberataque a la empresa internacional Sondeos Global, un proveedor de servicios SMS en Argentina, Chile y Uruguay, dejó en evidencia una de las debilidades más graves en los sistemas actuales de autenticación: la utilización de mensajes de texto como segundo factor de autenticación.

Los atacantes comprometieron los servidores que manejan el protocolo SMPP (Short Message Peer-to-Peer) un protocolo de nivel de aplicación que se utiliza para intercambiar mensajes de texto (SMS) entre aplicaciones y centros de mensajes (SMSCs).

De esta forma, los atacantes lograron interceptar en tiempo real más de 30.000 mensajes, muchos de ellos conteniendo códigos de segundo factor de autenticación del tipo OTP (One-Time-Password) enviados por empresas de tecnología, banca, servicios públicos y redes sociales.

Entre las plataformas afectadas se encuentran Google, Apple, Telegram, Facebook, Instagram, WhatsApp, Mercado Libre, Microsoft y muchas más. Estos servicios suelen enviar códigos por SMS como segundo factor de autenticación como parte de sus procesos de autenticación en dos pasos.

Sin embargo, existen dos factores que hacen que este esquema sea especialmente vulnerable. El primero es que la arquitectura del sistema hace que el mensaje de texto (SMS) atraviese múltiples intermediarios antes de llegar al usuario final. El segundo, que el mensaje se envía en texto plano, es decir sin cifrar.

En el caso de Sondeos Global, el ataque no solo fue efectivo, sino que pasó desapercibido durante semanas, permitiendo la apropiación masiva de cuentas sin necesidad de que las víctimas hicieran clic en enlaces o instalarán malware.

Un grupo de investigadores especializados detectaron incluso bots que automatizaban la interceptación de estos códigos y facilitaban el acceso a cuentas personales, especialmente de Telegram. Lo más preocupante es que muchas de las víctimas aplicaban buenas prácticas de seguridad: no tenían dispositivos infectados ni utilizaban contraseñas débiles, lo que demuestra que la falla estaba en el canal de comunicación mismo.

Como conclusión, queda claro que el uso de SMS como segundo factor de autenticación debe considerarse obsoleto y peligroso. Existen métodos mucho más seguros y fáciles de usar, como las aplicaciones de autenticación (Google Authenticator, Microsoft Authenticator, IBM Verify, etc.), dispositivos físicos de seguridad tipo FIDO o la utilización de passkeys basadas en biometría implementadas en dispositivos de confianza.

Todos estos métodos se basan en un concepto fundamental del que el SMS carece, no viajan por la red, sino que se generan en el dispositivo de confianza, usualmente el celular del usuario. De esta forma es imposible interceptar miles de contraseñas de segundo factor de forma centralizada como ocurrió con el ataque a Sondeos Global.

En todos los casos, el mensaje es el mismo: proteger los accesos con un segundo factor sigue siendo fundamental, pero el canal elegido para ese segundo factor debe ser robusto. Hoy, el SMS claramente no lo es.

Nota: Gracias Ámbito Financiero por darle un espacio a mi columna de opinión.

Liderazgo cuántico

Liderazgo cuántico

Sorprende el avance en tecnologías cuánticas en China. Esto ha puesto a dicho país en posición de liderazgo cuántico, específicamente en lo que se refiere a distribución de claves por medios cuánticos.

En notas anteriores (Jugando con qubits parte 1, parte 2 y parte 3) hablaba sobre los avances en computación cuántica en los últimos años, y de cómo las principales empresas tecnológicas de Estados Unidos se están sacando los ojos por lograr la Supremacía Cuántica.

En la charla de la Eko 2020 (Keep calm and play with qubits) nos preguntábamos con Luciano qué estarían haciendo los chinos en la materia. En ese momento se contaba con poca información sobre el grado de desarrollo de la cuántica china.

Sin embargo, de acuerdo con las últimas noticias, hoy podemos decir que están mucho más avanzados que el resto del mundo en algunas de las ramas cuánticas, específicamente en comunicación y distribución de claves por medios cuánticas. En occidente, compañías como IBM, Google o Microsoft están invirtiendo enormes sumas de dinero en tecnologías cuánticas. Esto no es diferente en el caso de China, donde empresas como Alibaba, Baidu y Tencent son los principales inversores en cuántica en el gigante de oriente.

QKD:

Ya mencionamos QKD en Jugando con qubits parte 1. La sigla significa Quantum key distribution, o Distribución de claves por medios cuánticos. Esta tecnología permite distribuir a emisor y receptor de un mensaje una clave codificada en qubits que hace casi imposible que un interceptor pueda intentar leerla sin que sea detectado.

Dos de las limitaciones más importantes de esta tecnología son: 1) la distancia a la que se pueden enviar las claves y 2) el costo del equipamiento que pueda lograrlo.

Es en el punto 1) donde los chinos parecen estar muy por delante del resto del mundo. El 29 de julio pasado, China anunció que su último nano satélite cuántico había sido lanzado y se encuentra en órbita y  operativo. El propósito de dicho satélite, desarrollado por la Universidad de Ciencia y Tecnología de China (USTC) es el de llevar a cabo experimentos de QKD con estaciones en tierra.

Los desarrollos de QKD hasta el momento, dependen del medio en el que se efectúe la transmisión. Respecto a las distancias, se logró una comunicación a 300m al aire libre en un experimento llevado a cabo en 2021 por el Indian Space Research Organization. Por otra parte, con el predecesor del nanosatélite chino denominado Micius, se lograron comunicaciones hasta 7500 km. Con el Micius se efectuó la primer video llamada “cuántica segura” en 2016.

Liderazgo cuántico

Fig 1. – Diagrama del satélite Micius (cortesía http://www.china.org.cn)

Es importante aclarar lo que esto significa. La denominada “llamada cuántica” no es más que una llamada de video convencional encriptada con algún algoritmo de cifrado simétrico, normalmente AES. Sólo que con una clave generada por medios cuánticos y enviada desde los satélites a emisor y receptor (Alice y Bob…) volviéndose imposible para quien quiera interceptar esa clave (Eve) hacerlo sin alterar la misma, y sin que Alice y Bob se den cuenta.

Debido a la decoherencia, es muy difícil que una vez que se entrelazan qubits, éstos permanezcan en ese estado por mucho tiempo o a lo largo de grandes distancias si lo hacen en instalaciones en tierra. Esto se debe a la contaminación de radiación y a la presencia de átomos con los que chocan los qubits en su camino.

Uno de los avances chinos en esta tecnología, consiste en utilizar satélites para generar qubits a base de fotones, que son altamente resistentes a la decoherencia. De esta forma, se envían qubits enlazados desde el espacio, con mucha menor interferencia y donde sólo sus estados se degradan al ingresar en la atmósfera. De esta forma, los chinos dieron un importante paso en la creación de lo que llaman una “Internet segura”, que se logra enviando desde el espacio, claves generadas cuánticamente a emisor y receptor de un mensaje.

La tecnología cuántica se china se viene desarrollando muy fuertemente desde la llegada de quien se considera el padre de la cuántica en dicho país, Jian-Wei Pan. quien ha predicho que en los próximos 5 años se producirá un avance disruptivo en estas tecnologías.

Nota por Carlos Benitez

Carlos Benitez es un reconocido experto en seguridad de la información.

Hackeando máquinas air-gapped con la USB Rubber Ducky

Hackeando máquinas air-gapped con la USB Rubber Ducky

 …cuando no nos queda otra…

Supongamos que tenemos acceso físico por unas cuantas horas a un equipo Windows hardenizado que queremos ownear. Un ejemplo de esto es cuando el equipo es del tipo air-gapped. Eso significa que está en modo stand-alone sin conexión a ninguna red. El plan habitual de pruebas, sería:

  1. entrar con algún usuario no privilegiado al que tenegamos acceso,
  2. comprobar los parches y actualizaciones aplicadas,
  3. encontrar vulnerabilidades,
  4. copiar o descargar algunas herramientas de seguridad o exploits,
  5. con ellas, escalar privilegios, romper protecciones,
  6. y convertirse en admin… bingo!

Pero ¿qué se puede hacer si el equipo está mucho más hardenizado de lo esperado? Por ejemplo, con todas esta condiciones: 

    • Hardware: OTS
    • Gabinete: Cerrado y sellado
    • Dispositivos de red: deshabilitados
    • Dispositivos de almacenamiento USB: deshabilitados
    • Dispositivos de red USB: desactivados
    • Dispositivo de booteo externo: desactivado
    • BIOS: protegida con password (que no tenemos)
    • Sistema operativo: Windows 10 (aunque también podrían ser otros…)
    • Servicios de red: deshabilitados

¿Qué es lo que sí tenemos?

    • Acceso físico al equipo por varias horas
    • Se puede bootear el sistema en Safe Mode
    • El usuario que bootea en Safe Mode tiene powershell habilitado
    • Dispositivos USB HID: habilitados

En estas condiciones, no es posible copiar nada, ni desde un pendrive ni por red. Entonces, en teoría no se podría ejecutar nada fuera de lo que ya está instalado en la máquina.

Ok, pero lo que sí se puede hacer es tipear…

Digamos que se descubre que el sistema es vulnerable. Y se está en posesión de un archivo .exe (recuerden que en este caso estamos en Windows) de un exploit de esa vulnerabilidad para ejecutarlo dentro de la máquina. ¿Cómo se pasa el archivo .exe a la máquina hardenizada para que se pueda ejecutar? ¿y sólo tipeando…?

 

 

USB Rubber Ducky

Bueno, aquí es donde entra la USB Rubber Ducky.
Con este dispositivo es posible programar y emular miles de tecleos en lugar de tipearlos manualmente.
Pero lo que en teoría no se puede escribir en forma directa con un teclado, es un archivo binario.

USB RUbber Ducky
Fig. 1. USB Rubber Ducky

Bueno, después de investigar un poco y probar mucho, se logró usar la USB Rubber Ducky para transferir ejecutables y otros binarios a una máquina en la que sólo es posible tipear.

En la seccion Tutoriales les dejo las dos versiones del tutorial para que jueguen, en Castellano y en Inglés.

Si lo hacen, por favor cuenten cómo les fue @ch4r1i3b.

Espero que les sirva.

Hasta la próxima!

 

 

Nota por Carlos Benitez

Carlos Benitez es un reconocido experto en seguridad de la información.

Binary file injection via USB Rubber Ducky

Binary file injection via USB Rubber Ducky

Is it possible to inject binary files using a USB Rubber Ducky? The device created years ago by Hack5 has the ability to enter a large number of keystrokes into a computer in a short time, but is it possible to enter binary files from the keyboard?

Yes, it is. I tell you how.

 

Introducción

I have posted something about keyboard related security before, but this time it is different. The purpose of this post is to explain how to inject binary files into a Windows 10 system using the “USB Rubber Ducky” keyboard emulator. While there are several alternative projects, the original USB Rubber Ducky from Hack5 was used to simulate the keyboard keys.

In the image above you can see how Angela from Mr. Robot is using the USB Rubber Ducky. She did that because she has physical access to the computer to be breached but only for 15 seconds. This is the main use for which the USB Rubber Ducky was designed. That of injecting thousands of keys in a few seconds or minutes as if someone is typing at super speed.

The goal was to test if, in addition to typing commands or scripts, binary files could also be injected through the USB Rubber Ducky. Googling around, only a few posts were found commenting that it would be feasible to do, but that it would be very difficult. I could not find any post from someone who had really done it.

What was developed then, was a procedure that allows to inject any arbitrary binary file, in this case, into a Windows 10 machine with Powershell enabled, by simply using the Ducky keyboard emulation.

 

DISCLAIMER

All information contained in this publication is for educational purposes only. The author or his collaborators are not responsible for any unlawful action that may be taken on the basis of such information.

 

USB Rubber Ducky

As the vendor states, “The USB Rubber Ducky injects keystrokes at superhuman speeds, violating the inherent trust computers have in humans by posing as a keyboard.

 

 

USB RUbber Ducky
Fig. 1. USB Rubber Ducky

The device looks like a USB flash drive. However, it is in fact a keyboard emulator. This means that it reads the key codes from a micro SD device and sends them to the computer as if it were a human typing. There are a lot of information online of how to use the Ducky and there are lot of published scripts too. In order to use the device you need to follow the next steps:

    1. Download any USB Rubber Ducky injection coder.

    There are several, but in this case the Duck Toolkit was used because it has the language coding that we needed.

  1.  

    1. Create the appropriate script in Rubber Ducky USB language

    The USB Rubber Ducky language is quite simple, and tells the processor what to do sequentially. Here is a simple example of a script:

REM The next three lines execute a command prompt in Windows
GUI r
DELAY 100
STRING cmd
ENTER

In this example, the commands used behave as follows:

REM: is a comment line, nothing will be done
GUI: is the Windows Key that will be holded with the next key. In this example ‘GUI r’ means, WindowsKey+r (it will popup the windows run… prompt)
DELAY: the system will wait for the tens of milliseconds that follows. In this example, ‘DELAY 100’ means delay 1000 milliseconds, that is 1 second.
STRING: means that the string that follows will be typed as is (in this case it will type ‘cmd’)
ENTER: the Enter key will be pressed

There are more commands in this language, nevertheless, for our purpose, we will use only these ones. This injection script can be saved in a text file, for example: “test.inject.txt“.

  1. Encode the script with the encoder

Once the script file is created, it needs to be encoded so that the Ducky understands it. It is very important to take into account the keyboard language that the target Windows has configured. It is also convenient to do some tests since the keymap may not match exactly with the encoding sent by the Ducky. Once the encoding is determined, a command like this is executed:

$ducktools.py -e test.inject.txt -l us test.inject.txt.bin
    1. Remove the micro SD card from the USB Rubber Ducky and plug it to a auxiliary machine. In this case the auxiliary machine was Linux.
    2. Copy the .bin file from the auxiliary machine to the micro SD card
$cp test.inject.txt.bin /media/.../inject.bin
    1. Remove the micro SD from the auxiliary machine and plug it back into the USB Rubber Ducky.
    2. Insert the USB Rubber Ducky in a USB socket of the target machine
    3. The Ducky will start typing…

Binary Powershell files

There are several ways of creating binary files from an integer string in Powershell. After making several tests, the following option was selected:

[io.file]::WriteAllBytes('<binary file>',$bytecode)

 

This command line will create a a file named ‘<binary file>‘ based on the bytecode sequence contained in the $bytecode variable.

Therefore, the $bytecode variable must be previously created and filled with the original binary file bytecode sequence. The variable can be created with this simple Powershell command:

$bytecode = <byte 1>,<byte 2>,<byte 3>,...,<last byte>

The original file bytecode sequence can be extracted in a Linux machine with a command like this:

$od -An -tu1 -w1 -v test.exe > test.exe.txt

Nevertheless, in this case, in order to make things easier, a python script was developed.

 

Creation of an injection file

A small python script named bin2duck was created in order to read the bytecode sequence of the original binary file, and create an USB Rubber Ducky script file. The python script can be downloaded here.
In the following section, the tutorial of the complete process of injecting a binary file to a Windows 10 machine with Powershell enabled via Rubber Ducky USB is described.

 

Tutorial

 

The main goal of this technique is to inject binary files (such as executables) to a Windows 10 machine with Powershell enabled.

For the whole process, in addition to the Ducky, a second machine is also needed. Surely the procedure can be run on a Windows with python, but in this case we used Linux.
The complete inventory is:

 

    • The Windows 10 target machine.
    • The auxiliary Linux machine.
    • The USB Rubber Ducky.

For the example in this tutorial, a legitimate Windows 10 executable extracted from another machine running the same version of Windows was used.

Here are the steps:

  1. Choose the binary file you want to inject, for example: hostname.exe
C:WindowsSystem32hostname.exe

For the first test, it is recommended that the executable file should be one extracted from other machine with the same  Windows version of the target machine.

  1. Copy the binary file to a Linux machine.

Through the network, USB, etc.

  1. On the Linux machine, run the python script (bin2duck) that reads the binary file and creates the script file in the USB Rubber Ducky language:
$bin2duck.py -i hostname.exe -m 2

a text file named ‘inj.hostname.exe‘ will be created. The file will have a format similar to this one:

DELAY 2000
STRING # Reading xxx bytes
ENTER
STRING $start=date
ENTER
STRING # Progress: 0%, 0 bytes
ENTER
STRING $bytecodetemp = $bytecodetemp + 77,90,144,0,....
ENTER
DELAY 200
STRING # Progress: 3%, 512 bytes
ENTER
STRING $bytecodetemp = $bytecodetemp + 128,18,0,0,....
ENTER
.
.
.
STRING # Progress: 100%, xxx bytes
ENTER
STRING $end=date
ENTER
STRING $start
ENTER
STRING $end
ENTER
STRING [byte[]] $bytecode = $bytecodetemp
ENTER
DELAY 200
STRING [io.file]::WriteAllBytes('inj.hostname.exe',$bytecode)
ENTER
  1. Encode the created file and generate USB Rubber Ducky injection file
    $ducktools.py -e inj.hostname.exe -l mx inj.hostname.exe.bin
  2. Insert the USB Rubbar Ducky micro SD in the auxiliary machine
  3. Copy the injection file on the micro SD
    $cp inj.hostname.exe.bin /media/.../inject.bin

Note: The target filename MUST be ‘inject.bin’.

    1. Unmount the micro SD
      $umount /dev/sdX1
    2. Remove the micro SD and insert it into the USB Rubber Ducky
    3. Go to the target machine
    4. Start a Windows command window  (Win+r, Start > Run > cmd.exe, etc.)
    5. With the cursor in the command window, insert the USB Rubber Ducky into the target Windows 10 system. The USB Rubber Ducky will start ‘typing’ as indicated in the inject.bin:

USB RUbber Ducky
Fig. 2. inject.bin execution.

      1. Wait until the process is finished and the file is created, in this case: hostname.exe.
        This process will take several minutes depending on the file size. According to our tests, the speed is between 30 and 60 bytes/second. This means that injecting a 1MB file would take, with this technique, between 5 and 10 hours… But if there is no other way to do it and the equipment is available for more than 5 hours, it is worth it…

Warning: During the process you can NOT touch the mouse or the keyboard, because if you change the focus, the Ducky will continue typing where the focus is and can ruin the variable generation process (besides typing anything in another application). It must be remembered that the device is emulating a typing person.

USB RUbber Ducky
Fig. 3. Target machine binary file creation.

    1. Run the newly created executable file. In this case both were tested: the original hostname command, and the injected file: inj.hostname.exe file.

USB RUbber Ducky
Fig. 4. Target machine binary file execution.

If the file is too large you can compress it (e.g. as a .zip file), send the .zip file as a binary via the USB Rubber Ducky, and then unzip it on the target machine.

 

Summary

Attacks to isolated or air-gapped machines are very limited. The limit is even worse if the machine has USB storage devices and external booting disabled. So, the only way to carry out an attack is by the keyboard port.

A procedure and a script to inject binary files into a Windows 10 machine via the keyboard emulator USB Rubber Ducky were created. Different binary files e.g. .exe and .zip files were successfully injected. Executable injected files were successfully executed.

 

Acknowkedgements

I would like to thank the Platinum Ciber technical team that participated in this initiative. They are: Alejandro Diaschi, Facundo Keller, Santiago Sarchetti and I want to specially mention Maykel Camargo who gave me the idea of using the USB Rubber Ducky to inject “stuff” inside a machine by unconventional means.

 

I hope you enjoy it!

See you next time!

 

 

Post by Carlos Benitez

Carlos Benitez es un reconocido experto en seguridad de la información.

Binary file injection via USB Rubber Ducky

Inyección de binarios vía USB Rubber Ducky

¿Es posible inyectar binarios usando una USB Rubber Ducky? El dispositivo creado hace años por Hack5 tiene la posibilidad de ingresar a un equipo una gran cantidad de teclas en corto tiempo, ¿pero es posible ingresar desde el teclado archivos binarios?

Sí es posible, aquí les cuento cómo.

 

Introducción

Ya alguna vez publiqué algo sobre seguridad relacionada con los teclados, pero esta vez es diferente. El propósito de este post es explicar cómo se pueden inyectar archivos binarios en un Windows 10 utilizando el emulador de teclado “USB Rubber Ducky“. Si bien existen varios proyectos alternativos, para simular las teclas del teclado en este proyecto se utilizó la USB Rubber Ducky original de Hack5. 

En la imagen de arriba se ve cómo Angela de Mr. Robot usa la USB Rubber Ducky porque cuenta con acceso físico al equipo a vulnerar, pero sólo disponiendo de 15 segundos para interactuar. Ese es el principal uso para el que fue diseñada la USB Rubber Ducky. El de inyectar miles de teclas en pocos segundos o minutos como si se tipeara a super velocidad. ¿Y por qué es posible? Normalmente porque es muy poco probable que se deshabilite o blacklistee en los equipos la interfaz de teclado. Y al conectarla Ducky así se presenta ante el sistema, como un teclado.

El objetivo fue probar si además de tipear comandos o scripts, también se podian inyectar binarios a través de la Ducky. Googleando sólo se encontraron  algunos post comentando que sería factible inyectar binarios, pero que sería muy difícil… No pude encontrar ninguna publicación de alguien que lo hubiera hecho.

Lo que se desarrolló entonces, fue un procedimiento que permite inyectar cualquier archivo binario arbitrario, en este caso, en una máquina con Windows 10 simplemente usando la emulación de teclado de la Ducky.

 

DISCLAIMER

Toda la información incluida en esta publicación se hace únicamente con carácter educativo. El autor o sus colaboradores no se hacen responsables por cualquier acción ilícita que se pueda realizar a partir de dicha información.

 

USB Rubber Ducky

Como afirma el vendedor, “La USB Rubber Ducky inyecta teclas a velocidades sobrehumanas, violando la confianza inherente que las computdoras tienen en los humanos al hacerse pasar por un teclado.

USB RUbber Ducky
Fig. 1. USB Rubber Ducky

El dispositivo parece un pendrive USB. Sin embargo, es en realidad un emulador de teclado. Esto significa que lee los códigos de las teclas de una memoria micro SD y los envía al equipo como si fuera un humano escribiendo. Hay mucha información en Internet de cómo usar el Ducky y también hay muchos scripts publicados. Para utilizar el dispositivo se deben que seguir los siguientes pasos:

    1. Descargar cualquier codificador de inyección de USB Rubber Ducky.

    Hay varios, pero para este caso se utilizó el Duck Toolkit porque tiene la codificación del lenguaje que se necesitaba.

    1. Crear el script apropiado en lenguaje USB Rubber Ducky

    El lenguaje USB Rubber Ducky es bastante sencillo, y le indica al procesador lo que debe hacer en forma secuencial. Este es un ejemplo sencillo de un script:

REM Las siguientes tres líneas ejecutan un prompt de comando en Windows
GUI r
DELAY 100
STRING cmd
ENTER

En este ejemplo, los comandos utilizados se comportan de la siguiente manera:

REM: es una línea de comentario, no se hará nada
GUI: es la tecla de Windows que se mantendrá apretada con la siguiente tecla indicada. En este ejemplo ‘GUI r’ significa, WindowsKey+r (hará aparecer el prompt de Windows Run…)
DELAY: el sistema esperará las decenas de milisegundos siguientes. En este ejemplo, ‘DELAY 100’ significa retrasar 1000 milisegundos, es decir, 1 segundo.
STRING: significa que el string que sigue se escribirá tal cual; en este caso escribirá ‘cmd’
ENTER: se pulsará la tecla Enter

Hay más comandos en este lenguaje, sin embargo, para el propósito de este post, sólo se utilizarán los indicados. Este script de inyección se puede salvar en un archivo de texto, por ejemplo: “test.inject.txt

  1. Codificar el script con el codificador

Una vez creado el archivo de script, se necesita codificarlo para que la Ducky lo entienda. Es muy importante tener en cuenta el lenguaje del teclado que tiene configurado el Windows de destino. También conviene hacer pruebas ya que puede ser que el mapa de teclas no coincida exáctamente con la codificación que envía la Ducky. Una vez determinada la codificación, se ejecuta un comando como este:

$ducktools.py -e test.inject.txt -l us test.inject.txt.bin
    1. Quitar la micro SD de la USB Rubber Ducky y conectarla a una máquina auxiliar (en este caso, la máquina auxiliar tenía Linux).
    2. Copiar el archivo .bin de la máquina auxiliar a la micro SD
$cp test.inject.txt.bin /media/.../inject.bin
    1. Retirar la micro SD de la máquina auxiliar y conectarla de nuevo en la USB Rubber Ducky
    2. Insertar la USB Rubber Ducky en el conector USB de la máquina de destino.
    3. La Ducky comenzará a escribir…

Archivos binarios Powershell

Hay varias formas de crear archivos binarios a partir de un string de enteros en powershell. Después de hacer varias pruebas, se decidió utilizar la siguiente opción:

[io.file]::WriteAllBytes('<archivo binario>',$bytecode)

En esta línea, se crea un archivo de nomnre ‘<archivo binario>’ basado en la secuencia de bytecodes contenida en la variable $bytecode.

Por lo tanto, previamente se debe crear y llenar con la secuencia de bytecodes del archivo de origen, la variable de tipo Byte $bytecode. La variable se puede crear simplemente con el siguiente comando de powershell:

$bytecode = <byte 1>,<byte 2>,<byte 3>,...,<último byte>

La secuencia de bytes del archivo original se puede extraer (por ejemplo) en una máquina Linux con el siguiente comando:

$od -An -tu1 -w1 -v test.exe > test.exe.txt

Pero en este caso, para facilitar el proceso, se desarrolló un script en python.

 

Creación del archivo de inyección

Para leer todos los bytes del archivo binario original, y crear el archivo de inyección para la USB Rubber Ducky, se creó un pequeño script en python: bin2duck. El mismo se puede descargar aquí.
En la siguiente sección, se describe el tutorial del proceso completo para inyectar un archivo binario a un Windows 10 con Powershell habilitado a través de la USB Rubber Ducky.

 

Tutorial

El objetivo principal de esta técnica es el de inyectar archivos binarios (como por ejemplo ejecutables) a una máquina con Windows 10.

Para el proceso completo, además de la Ducky, también se necesita una segunda máquina. Seguramente el procedimiento se podrá ejecutar en un Windows con python, pero en este caso se utilizó Linux.
El inventario completo es:

    • La máquina de destino (con Windows 10).
    • Una máquina auxiliar (con Linux).
    • La USB Rubber Ducky.

Para el ejemplo de este tutorial, se utilizó un ejecutable legítimo de Windows 10 extraido desde otra máquina con la misma versión de Windows que la máquina destino.

Estos son los pasos:

  1. Buscar el binario que se quiere inyectar, por ejemplo el ejecutable: hostname.exe
C:\Windows\System32\hostname.exe

Para la primera prueba conviene que el ejecutable sea uno extraído de la misma versión de Windows de la máquina de destino.

  1. Copiar el ejecutable a un equipo Linux

Por red, USB, etc.

  1. En la máquina Linux, ejecutar el script de python que lee el binario y crea el archivo script en el lenguaje de la USB Rubber Ducky:
$bin2duck.py -i hostname.exe -m 2

se creará un archivo de texto llamado ‘inj.hostname.exe‘ con un formato similar a éste:

DELAY 2000
STRING # Reading xxx bytes
ENTER
STRING $start=date
ENTER
STRING # Progress: 0%, 0 bytes
ENTER
STRING $bytecodetemp = $bytecodetemp + 77,90,144,0,....
ENTER
DELAY 200
STRING # Progress: 3%, 512 bytes
ENTER
STRING $bytecodetemp = $bytecodetemp + 128,18,0,0,....
ENTER
.
.
.
STRING # Progress: 100%, xxx bytes
ENTER
STRING $end=date
ENTER
STRING $start
ENTER
STRING $end
ENTER
STRING [byte[]] $bytecode = $bytecodetemp
ENTER
DELAY 200
STRING [io.file]::WriteAllBytes('inj.hostname.exe',$bytecode)
ENTER
  1. Codificar el archivo creado y generar el archivo de inyección USB Rubber Ducky
    $ducktools.py -e inj.hostname.exe -l mx inj.hostname.exe.bin
  2. Insertar la micro SD de la USB Rubber Ducky en la máquina auxiliar
  3. Copiar el archivo de inyección en la micro SD
    $cp inj.hostname.exe.bin /media/.../inject.bin

Nota: El nombre del archivo de destino DEBE ser ‘inject.bin’.

    1. Desmontar la micro SD
      $umount /dev/sdX1
    2. Retirar la micro SD e insertarla en la USB Rubber Ducky
    3. Ir al sistema de destino
    4. Iniciar una ventana de comandos de Windows (Win+r, Inicio > Ejecutar > cmd.exe, etc.)
    5. Con el cursor en la ventana de comandos, insertar la USB Rubber Ducky en el sistema Windows 10 de destino. La USB Rubber Ducky comenzará a ‘tipear’ de acuerdo a lo indicado en el inject.bin:

USB RUbber Ducky
Fig. 2. Ejecución del inject.bin.

      1. Esperar a que el proceso termine y se cree el archivo, en este caso: hostname.exe.
        Este proceso tardará varios minutos dependiendo del tamaño del archivo. Según las pruebas realizadas, la velocidad es de entre 30 y 60 bytes/segundo. Eso significa que inyectar un archivo de 1MB, demoraría, con esta técnica, entre 5 y 10 horas… Pero si no hay otra forma de hacerlo y se dispone del equipo por más de 5 horas, vale la pena…

Nota: Durante el proceso NO se puede tocar ni mouse ni teclado, ya que si se cambia el foco, la Ducky sequirá tipeando donde esté el foco y puede arruinar el proceso de generación de la variable (además de escribir cualquier cosa en otra aplicación). Se debe recordar que el dispositivo está emulando a una persona tipeando.

USB RUbber Ducky
Fig. 3. Creación del binario en la máquina de destino.

    1. Ejecutar el archivo binario recién creado. En este caso se probaron los 2: el comando original hostname, y el archivo inyectado: inj.hostname.exe.

USB RUbber Ducky
Fig. 4. Ejecución del binario de destino.

Si el archivo es demasiado grande se puede comprimir (por ejemplo, como archivo.zip), enviar el archivo.zip como binario a través de la USB Rubber Ducky y luego descomprimirlo en la máquina de destino.

 

Resumen

Los ataques a las máquinas aisladas o air-gapped son muy difíciles de lograr. Estas restricciones son aún mayores si la máquina tiene tanto los dispositivos de almacenamiento USB y de booteo externo desactivados. Por lo tanto, la única forma de llevar adelante un ataque en estos equipos es a través del teclado.

Se creó un procedimiento y un script para inyectar archivos binarios en una máquina Windows 10 a través del emulador de teclado USB Rubber Ducky. Se inyectaron con éxito en dicha máquina diferentes archivos binarios, por ejemplo, archivos .exe y .zip. Los archivos ejecutables inyectados fueron ejecutados con éxito.

Agradecimientos

Me gustaría agradecer al equipo técnico de Platinum Ciber que participó en esta iniciativa. Ellos son: Alejandro Diaschi, Facundo Keller, Santiago Sarchetti y quiero mencionar especialmente a Maykel Camargo quien me dio la idea de usar la USB Rubber Ducky para inyectar “cosas” dentro de una máquina por medios no convencionales.

 

Espero que les sirva.

Hasta la próxima!

 

 

Nota por Carlos Benitez

Carlos Benitez es un reconocido experto en seguridad de la información.

Y otra vez el ganador es: Signal!

Y otra vez el ganador es: Signal!

Un conjunto de vulnerabilidades descubiertas en Telegram recientemente, vuelve a demostrar que Signal es el mensajero más seguro.

Hace unos dos meses, escribí esta nota en la que analizaba la privacidad y la seguridad de las tres aplicaciones de mensajería más populares:Whatsapp, Telegram y Signal. Se ve que el análisis gustó, ya que 3 días después Clarín publico esta nota.

Mi veredicto en ese momento fue que Signal se llevaba todos los premios. Lo que ocurre de nuevo, es que un grupo de investigadores de la ETH Zürich (Escuela Politécnica Federal de Zúrich), más precisamente el Grupo de Criptografía Aplicada de dicha universidad, descubrió 4 vulnerabilidades en el protocolo de transmisión de Telegram. Esto agrega serias vulnerabilidades a una de las aplicaciones analizadas y refuerza la idea de que Signal sigue siendo el ganador de la batalla… al menos por ahora.

 

MTProto

El protocolo en cuestión es el MTProto. un protocolo de cifrado tanto de datos como de transmisión creado para Telegram por Nikolái Dúrov. Este protocolo fue creado para mejorar la seguridad del protocolo XMPP incorporando capacidades multisesión y multiplataforma. El protocolo es abierto. fue anunciado en 2013 y forma parte de la aplicación Telegram.

 

Criptoanálisis

El grupo mencionado de la universidad ETH Zúrich, efectuó un análisis del mismo que fue publicado durante el presente mes. En el mismo anuncian ‘buenas’ y ‘malas’ noticias. Las buenas son que demostraron que “(el protocolo) consigue seguridad en un modelo de canal seguro bidireccional adecuado, aunque bajo supuestos no estudiados“. Indica demás que “…este modelo en sí mismo avanza el estado del arte de los canales seguros.

Las malas son que hallaron 4 vulnerabilidades mediante las cuales se puede atacar la comunicación de Telegram de diferentes formas, algunas triviales y algunas muy complejas de implementar.

Vuln #1: crime-pizza

Esta vulnerabilidad consiste en alterar la secuencia de los mensajes enviados. Se la llamó crime-pizza porque utilizaron como ejemplo burdo el que un usuario haya enviado el mensaje {“I say yes to”, “all the pizza”, “I say no to”, “all the crimes”} y si alguien alterara su secuencia, el receptor podría leer {“I say yes to”, “all the crimes”, “I say no to”, “all the pizza”}.

Vuln #2: cliente o servidor?

Otra de las vulnerabilidades consiste en descubrir, dados dos  mensajes, cuál fue cifrado en el server y cuál en el cliente.

Vuln #3: descifrar mensajes

Esta vulnerabilidad es casi imposible de explotar. Sin embargo, de poder hacerse permitiría en teoría descifrar mensajes enviados por Telegram.

Vuln #4: MITM

Otra vulnerabilidad casi imposible de explotar como la anterior ya que requiere (como la anterior) enviar millones de mensajes y analizar las respuesta. Sin embargo, otra vez en forma teórica, sería posible interceptar la negociación de claves entre cliente y servidor y hacerse pasar por el servidor.

 

Whatsapp vs. Telegram vs. Signal

Las vulnerabilidades halladas no tienen aún CVEs que se sumarían a Telegram. De hecho no son estrictamente de Telegram, sino del protocolo con el que funciona Telegram, es decir MTProto. Sin embargo, podríamos regenerar el gráfico de la nota anterior, agregando 4 vulnerabilidades nuevas a Telegram. Por lo que quedaría de esta forma:

 

Vulnerabilidades Whatsapp vs. Telegram vs. Signal

 

Y desde el punto de vista de seguridad… el ganador es…… otra vez Signal!

 

Update del 6-sept-2021

Como para seguir en esta linea, Kaspersky acaba de publicar en su blog una nota con los mismos conceptos.

 

 

Nota por Carlos Benitez

Carlos Benitez es un reconocido experto en seguridad de la información.

La suma de todos los miedos II: esta vez fue Sol Oriens

La suma de todos los miedos II: esta vez fue Sol Oriens

La empresa Sol Oriens*, que trabaja con tecnología de armamento nuclear, fue atacada por el ransomware REvil en mayo pasado.

Hace un año hablamos del ataque sufrido por la empresa Westech International, una pequeña compañía que posee contratos con el Departamento de Defensa de Estados Unidos y da soporte al sistema de misiles balísticos intercontinentales Minuteman III.

Y hoy tenemos que hablar de Sol Oriens, otra PyME que da servicios a la defensa de Estados Unidos. Y como si pareciera coincidencia, esta empresa también trabaja en tecnología de armas nucleares.

*Por el momento, es imposible entrar al sitio de Sol Oriens LLC, pero como la máquina del tiempo hacia atrás sí funciona, les dejo cómo se veía el sitio el 30 de agosto de 2018:

 Fig. 1 – Sito de Sol Oriens al 30 de agosto de 2018

La información que salió a la luz este viernes en varios medios como The Threatpost y CNBC. Según un thread de twitter de un periodista de CNBC, la empresa fue atacada por el conocido grupo de RaaS (Ransomware as a Service) REvil también conocido como Sodinokibi, Bluebackground o Sodin. REvil viene pegando fuerte desde hace años, habiendo sido hace poco su víctima el mismísimo Apple. Si bien, según dice la empresa, la información que robó/cifró esta vez no era tan valiosa. Lo que si trascendió, es que esa información podría haber sido del personal de la empresa, ya que los equipos víctimas del ransomware, mostraban un mensaje en la pantalla como el siguiente:

Nos reservamos el derecho (sic) de transmitir toda la documentación y los datos pertinentes a los organismos militares de nuestra elección (sic), incluidos todos los datos personales de los empleados.

¿Y cómo sabemos que es una PyME? bueno, ellos mismos lo dicen en su sitio y cuando definen su propio perfil de linkedin. Según las notas de referencia, no estaba muy claro en qué proyectos trabaja Sol Oriens. Lo que si se sabe es cuáles son sus clientes:

 

 Fig. 2 – Clientes de Sol Oriens al 30 de agosto de 2018

 

 

Evidentemente la NNSA (National Nuclear Security Administration) y el DoD (Department of Defense) de Estados Unidos, contrataron a Sol Oriens para determinados proyectos o servicios.

Por otra parte, por una búsqueda laboral publicada en Lensa (no sé por qué no usaron linkedin… si ahí estamos todos…) se descubrió que trabajan en armamento nuclear. Específicamente en la cabeza nuclear W80-4. Esto se debe a que en la publicación, solicitan un especialista Senior en ese tipo de armas, tal como se puede ver en el texto de la misma:

 

 Fig. 3 – Solicitud en Lensa de un experto en armas nucleares.

 

 

Westech y Sol Oriens

Un pequeño análisis al final. ¿Por qué pongo a estas dos empresas juntas? ¿qué piensan ustedes que tienen en común ambas?. Lo primero que surge es que son dos PyMEs que manejan proyectos muy grandes e importantes. Eso es cierto, pero hay muchas PyMEs en el mundo que manejan proyectos y clientes muy grandes e importantes, y lo hacen muy bien. Lo segundo es que son dos empresas tercerizadas que dan servicios relacionados con el armamento nuclear de Estados Unidos. Es decir, terceros que desarrollan tareas de alto valor estratégico y que manejan información altamente sensible y confidencial.

Entonces me pregunto si estas empresas, no deberían cumplir los mismos requerimientos de ciberseguridad que su contratista. Es muy probable que cumplan con medidas de seguridad nuclear y ambiental en general ya que trabajan con material muy peligroso. Pero, ¿se les exige también medidas de protección relacionadas con ciberseguridad?

Ya que estamos, voy a comentarles una buena que tenemos por casa. Existe una circular del BCRA (la A6374) que obliga a los bancos de Argentina que tercericen servicos, a obligar a su vez a sus tercerizados a cumplir con una gran cantidad de requisitos de ciberseguridad.

El uso de dispositivos propios (BYOD), la movilidad, las conexiones remotas (en especial con la pandemia) ya diluyeron el viejo perímetro hace años. Pero además, las empresas tercerizadas en las que confiamos, que manejan nuestra información, la mayor parte de las veces, ingresan a nuestros mismos sistemas. Es por eso que nuestra red es hoy nuestra red, más todas las redes de nuestros terceros… y los suyos…

Creo que es crucial que se controlen y auditen las medidas de ciberseguridad que estos terceros aplican. Ya vimos que hoy en día no basta con protegernos sólo a nosotros mismos.

Y en lo que respecta a las empresas que manejan armamento nuclear de Estados Unidos que fueron víctimas de ciberataques, ya van dos. Las balas van pegando cerca.

 

 

Nota por Carlos Benitez

Carlos Benitez es un reconocido experto en seguridad de la información.

Kali 2021.2 + RPi 4: una pareja perfecta

Kali 2021.2 + RPi 4: una pareja perfecta

La unión de la última versión de Kali (2021.2) con la última versión de la Rapsberry Pi (4 Model B) crean la pareja perfecta para tener un dispositivo portátil de pentest.

Todos los profesionales de seguridad necesitamos, en algún momento, desplegar un dispositivo portátil que nos permita probar o analizar vulnerabilidades. Una de las opciones más lógicas es la de usar mini motherboards. Hoy en día existen muchas SBC’s (Single Board Computers) en el mercado. La mayoría de ellas se basan en procesadores ARM. Para la gran mayoría de ellas, existen diferentes distros de Linux, incluyendo Kali.

 

Experimentos

Si bien he experimentado con algunas otras, la placa que más suelo usar es la Raspberry Pi. Ya escribí sobre algunos experimentos que hice basándome en la RPi. Además de este trabajo, experimenté probando diferentes usos.

Uno de ellos fue el de reemplazar la notebook en un viaje, con algún dispositivo más pequeño y liviano que pudiera entrar el el bolsillo de la mochila. Este es uno de los kits que usé.

 

Kit de viaje con la RPi3

Fig. 1 – Mini set de viaje con la RPi3 😉

Ustedes dirán que falta el display, si! obvio! pero hoy en día no encontré hoteles donde no hay aun televisor con entrada HDMI… Así que si bien sólo la podía usar en el hotel, tenía toda la potencia de un Linux en el bolsillo.

Otro de mis experimentos fue el de instalar el Kali completo en la RPi 3. Bueno, se puede, pero no es muy fácil de usar. Recuerden que esta versión, aún la Model B, viene con un máximo de 1GB de RAM. Esto hace que sea algo difícil hacer correr las X. Entonces, si además cargamos alguna aplicación pesada, se vuelve imposible. Memory exhaust por todos lados o, en el mejor de los casos, tiempos de respuesta larguísimos. En especial si la dejamos conectada en un sitio remoto, y queremos acceder a las X vía VNC.

 

Openvas

Ustedes se preguntarán, qué aplicación necesito sí o sí correr en este hardware sobre las X? Bueno, una de ellas es el Openvas. Los que lo instalaron saben lo quisquilloso que es respecto al acceso remoto. Y si tienen que resolver algo rápido, no pueden estar días instalando, desinstalando y cambiando configuraciones para que funcione.

Por si les interesa, les paso una alternativa para no utilizar el Openvas desde un browser en la misma RPi, sino usando por SSH los comandos de línea del Openvas: el OMP. Como verán, correr un scan desde OMP es un chino. Pero si no hay otra forma de hacerlo, es una solución posible.

 

Raspberri Pi 4 Model B

Respecto a las limitaciones de hardware, todo se solucionó con la Raspberri Pi 4. El modelo salió a fines de 2018 y con una característica fundamental, la máxima configuración de RAM pasó de los humildes 1GB a 4GB. Además de muchas otras mejoras, en este modelo sí se podían correr aplicaciones un poco más pesadas. Y como verán, mi kit de viaje no cambió mucho…

Kit de viaje con la RPi3

Fig. 2 – Mini set de viaje con la RPi4 😉

El salto final, hasta hoy, obvio… se dió con la Raspberry Pi 4 Model B. En este caso, la máxima configuración de RAM con la que se puede comprar la placa es de 8GB. Ahora sí!

La empresa, además, apostó a una nueva mejora con la Raspberry Pi 400. Un modelo en el que implantan la RPI4 Model B en un case de teclado logrando esto:

Kit de viaje con la RPi3

Fig. 3 – Nuevo modelo: RPi400

El lado oscuro

Dependiendo de cómo la vayamos a usar y dónde la vayamos a instalar físicamente, una característica que obligatoriamente debemos tener en cuenta para esta versión es la temperatura. En términos simples, la RPi4 calienta. Es que es pura lógica, una gran velocidad viene con un gran consumo de energía, por lo tanto de disipación de calor.

Es por eso que los mejores gabinetes incluyen coolers, además de ser de aluminio para poder disipar mejor el calor. Yo tengo una Flirc case que, la verdad que disipa bastante bien. En la ofi también probamos la Argon One, que además de disipar bien, viene con un adaptador para sacar todos los conectores por detrás y convierte las 2 salidas de video de mini HDMI a HDMI.

 

Kali 2021.2

Es muy interesante que este año, todavía no llegamos a la mitad, y ya se liberaron dos versiones, Kali 2021.1 en febrero pasado y Kali 2021.2 el 1 de junio último.

Siendo la distro de seguridad más usada, se puede encontrar que hay versiones de Kali para muchas plataformas:

Kit de viaje con la RPi3

Fig. 5 – Plataformas de Kali.

 

La que ahora nos interesa en particular es la de ARM:

Kit de viaje con la RPi3

Fig. 6 – Descargar Kali para ARM.

Esta versión viene con muchas mejoras en general, pero particularmente las que me interesan son las relacionadas con la RPi.

Kit de viaje con la RPi3

Fig. 7 – Mejoras de Kali 2021.2 relacionadas con la Raspberry Pi.

 

Una de las que quiero destacar es la de kalipi-config. Si bien hasta ahora existía un raspi-config portado a Kali, estaba bastante limitado y se perdían muchas configuraciones del hardware en esta herramienta. El haber incorporado el raspi-config en forma nativa, nos da muchas más posibilidades.

La otra mejora que incorporan, es la configuración para displays TFT. No se si usar este tipo de displays es muy útil en este tipo de aplicaciones, pero bueno, la posibilidad está.

 

A probar!

Lo que yo veo como más interesante es que ahora la RPi tiene verdaderamente una potencia superior. Por un lado, la Raspberry Pi 4 Model B es bastante más rápida que la Raspberry Pi 3 Model B. Acá pueden ver los benchmarks. Por otro lado, el incremenetar la memoria máxima de 1GB a 8GB ya va dando otras posibilidades interesantes.

Por el lado de Kali 2021.2 para ARM, al mejorar los drivers para el hardware, juran que su performance sobre RPi subió 1500%… y que el booteo inicial pasó de 20 minutos a 15 segundos…

Bueno, esta pareja parece prometer, así que no queda otra que probar. Trataré de hacer algunas pruebas y pasaré los resultados como update de esta nota.

Hasta la próxima!

 

Nota por Carlos Benitez

Carlos Benitez es un reconocido experto en seguridad de la información.

Eludiendo al Hermano Mayor

Eludiendo al Hermano Mayor

Respondiendo nuevamente a la pregunta: ¿cuál es la aplicación de mensajería instantánea que mejor cuida nuestra privacidad? ¿Whatsapp, Telegram o Signal?

Por ser especialistas en seguridad, no podemos evitar que quienes nos conocen, o nos acaban de conocer, nos hagan una serie de preguntas casi de manual. Por ejemplo: ¿cuál es el mejor antivirus? o… ¿dónde guardo mis contraseñas? o… ¿cuál es la app de mensajería que más cuida mi privacidad? ¿Whatsapp, Telegram o Signal?

Dada la insistencia con la que me han preguntado esto últimamente, sumo mi análisis a todos los que ya están online.

 

El Hermano Mayor

George Orwell en ‘1984’, imaginó un futuro distópico, con gobiernos dictatoriales y reescritores dinámicos de la historia, que necesitaban mantener ese poder controlando a la gente. En ese futuro, aparecía la figura del ‘Hermano Mayor‘*, una organización estatal que, mediante dispositivos instalados en todos lados, vilgilaba constantemente a los ciudadanos, de forma absolutamente autoritaria y coercitiva. En la novela, a los ciudadanos no les queda otra que aceptar esa vigilancia. Y algunos rebeldes la resisten, pero hasta a costa de sus propias vidas.

Es extraño decirlo, pero parte de las predicciones de Orwell se cumplieron. La vigilancia existe hoy en día y de muchas formas. Lo que él nunca imaginó, es que no sólo todos nosotros la aceptamos felices, sino que los dispositivos capaces de vigilarnos no nos están impuestos a la fuerza. Sino que los buscamos, los compramos y a veces pagamos fortunas por ellos.

Me refiero al dispositivo que llevamos todo el tiempo en nuestro bolsillo, permanentemente conectado. Y que además, está equipado con un GPS, una cámara (bueno, más de una!) y un micfrófono. Y nosotros mismos nos bajamos, instalamos y usamos felices aplicaciones ‘gratuitas’ que recolectan nuestros datos personales y los almacenan en masa vaya uno a saber para qué. El Hermano Mayor perfeccionado.

En nuestra realidad, el Hermano Mayor no es un conjunto de estados totalitarios mundiales como en la novela, sino que son diferentes organizaciones de algunos Estados, algunas empresas o alguna corporaciones. La vigilancia actual está diluida, distribuida, sin un fin único. Pero es vigilancia al fin.

 

Eludiendo al Hermano Mayor

A todos nos gusta disfrutar de las ventajas y facilidades que nos da la tecnología y de estar siempre conectados. Sin embargo, no creo que a ninguno de nosotros nos guste que nos vigilen. Pero el contrato implícito que todos firmamos cuando le damos al botón de “Acepto” sin leer, es que usamos las aplicaciones sin pagar con dinero, pero pagando con nuestros datos. Es el modelo que se ha instalado, y no podemos hacer mucho… o si?

Hay algunas cosas que sí podemos hacer para que la injerencia de la vigilancia sea menor. Existe una gran cantidad de prácticas de privacidad que podemos implementar, como la de restringir permisos en las aplicaciones que tenemos instaladas, usar VPNs cuando sea posible, navegar a través de TOR, etc.

Pero otra de las medidas que podemos tomar, es la de tratar de no utilizar herramienas que sabemos positivamente que recolectan nuestros datos y reemplazarlas por otras menos invasivas… si las encontramos.

 

Whatsapp vs. Telegram vs. Signal

El tema de la privacidad de los datos personales lo traté varias veces en este blog [1, 2, 3]. Particularmente, sobre este punto posteé también en linkedin algún comentario hace tiempo. Pero como la pregunta de cuál de las 3 aplicaciones usar me la siguen haciendo, quise escribir un breve análisis sobre los tres servicios.

Si lo googlean, van a ver una interesante cantidad de entradas que tiene esta pregunta. Lo más interesante es que las respuestas de todas las notas son las mismas. [Spoiler Alert!] …que es Signal es el que más mantiene la privacidad, la que recolecta menos datos, muy diferente que las otras. Sin embargo, la cantidad de usuarios al día de hoy de cada plataforma es la siguiente:

Cantidad de Usuarios

 Fig. 1 – en las tres plataformas al 30/mayo/2021. Fuente: Google.

Como pueden ver, la adopción de Signal es la menor de todas. Una aclaración sobre el gráfico. No hice la versión de torta porque llevaría a confusión. La cantidad de usuarios de cada plataforma no es mutualmente excluyente. Hay usuarios que están registrados en 2 o en 3 servicios al mismo tiempo (como es mi caso). Por eso creí que era mejor el gráfico de barras.

 

La Privacidad

Existen muchas notas online donde se describen la características de privacidad de ambas plataformas. Por ejemplo en esta de Iván Ramírez, en esta de Tetiana Hanchar, o la de Luis Miguel Paredes, o la de Cecilia Pastorino, o la directa recomendación de The Guardian. Se suma también la decisión de varias organizaciónes de la Unión Europea sobre dejar de usar Whatsapp y reemplazarlo por Signal.
Les doy mis 5 centavos y les hago un resumen.

 

Datos personales recolectados

Tabla 1 – Datos personales que recolecta cada plataforma.

Como podrán ver, si de privacidad se trata, no hay absolutamente ningina duda. Signal se lleva todos los premios.

 

La Seguridad

Respecto a los diferentes aspectos de seguridad, se podrían considerar entre otros estos tres: los permisos de las diferentes aplicaciones, los protocolos de comunicación y cifrado y las vulnerabilidades de cada sistema.

Respecto a los permisos en los smartphones, los tres requieren permisos similares.

Respecto al cifrado, algunas de las referencias que les pasé analizan esto bastante.

Lo que no encontré que nadie analice, es una comparativa sobre las vulnerabilidades que las tres aplicaciones tienen publicadas. Les paso el análisis, obviamente, sacado de la lista de CVE’s de MITRE.

 

Whatsapp

Estas son las vulnerabilidades reportadas de Whatsapp, por año y por tipo.

Vulnerabilidades de Whatsapp

Fig. 2 – Vulnerabilidades reportadas de Whatsapp. Fuente: MITRE.

Vulnerabilidades de Whatsapp por tipo

Fig. 3 – Distribución de vulnerabilidades reportadas por tipo de Whatsapp. Fuente: MITRE.

Como pueden ver, para Whatsapp, están reportadas 30 vulnerabilidades en total, de las cuales el 65% son graves. Esto lo pueden comprobar viendo que 24 de ellas está calificadas con el CVSS en 7.5. El año en el que más vulnerabilidades se encontraron, fue el 2020… habrá tenido algo que ver el Covid…?

Telegram

Estas son las vulnerabilidades reportadas de Telegram, por año y por tipo.

Vulnerabilidades de Telegram

Fig. 4 – Vulnerabilidades reportadas de Telegram. Fuente: MITRE.

 

Vulnerabilidades de Telegram

Fig. 5 – Distribución de vulnerabilidades reportadas por tipo de Telegram. Fuente: MITRE.

Telegram parece estar un poco mejor. Sólo se reportaron 19 Vulnerabilidades de Telegram por tipo y la gravedad no es tanta como en el caso de Whatsapp. La de mayor score CVSS es de 5.0.

 

Signal

Estas son las vulnerabilidades reportadas de Signal, por año y por tipo.

Vulnerabilidades de Signal

Fig. 6 – Vulnerabilidades reportadas de Signal. Fuente: MITRE.

Vulnerabilidades de Signal por tipo

Fig. 7 – Distribución de vulnerabilidades reportadas por tipo de Signal. Fuente: MITRE.

Es raro ver esto. La aplicación casi soñada para los especialistas en ciberseguridad, casi sin defectos de seguridad! Sólo 3 vulnerabilidades reportadas, 2 locales, 2 remotas y en este caso también, la de mayor score CVSS es de 5.0. Nada mal.

 

Comparación

Para cerrar el tema de vulnerabilidades, les dejo la comparativa entre las tres aplicaciones.

Vulnerabilidades Whatsapp vs. Telegram vs. Signal

Fig. 8 – Vulnerabilidades reportadas para los tres servicios. Fuente: MITRE.

 

Los números hablan. Supongo que no hay dudas sobre quién gana la pulseada esta vez. Signal, la aplicación que menos datos privados recolecta y la que tiene menos vulnerabilidades. ¿Alguna duda de cuál elegirían?

Espero que este pequeño análisis les sirva. Nos vemos en la próxima.

 

* Hermano Mayor:

En ‘1984’, Orwell nombra a la figura que vigila a todos los ciudadanos como “Big Brother”. La traducción correcta de Big Brother es “Hermano Mayor”. Esto es porque este término posee la connotación referida a que el hermano mayor de una familia tenía tácitamente una misión: la de cuidar a los hermanos menores ya que, éstos, por ser más chicos, no saben, no tienen experiencia, no entienden, son más vulnerables. Alguien tradujo hace años incorrectamente Big Brother al castellano como “Gran Hermano”. Como en muuuuchos otros casos, esa traducción incorrecta se difundió, instaló y perduró y hoy se acepta como correcta. Pero no lo es.

Permítanme en esta nota, utilizar entonces el término correcto. Gracias!

 

Nota por Carlos Benitez

Carlos Benitez es un reconocido experto en seguridad de la información.