Entradas - Cybers on the Storm

Liderazgo cuántico

by Carlos Benitez | Sep 25, 2022 | Actualidad, CiberSeguridad, Computación cuántica, qubit

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.

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.

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

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

by Carlos Benitez | Nov 22, 2021 | CiberSeguridad, Hardware

…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:

entrar con algún usuario no privilegiado al que tenegamos acceso,
comprobar los parches y actualizaciones aplicadas,
encontrar vulnerabilidades,
copiar o descargar algunas herramientas de seguridad o exploits,
con ellas, escalar privilegios, romper protecciones,
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.

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!

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

Binary file injection via USB Rubber Ducky

by Carlos Benitez | Nov 20, 2021 | Tutoriales

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

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

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

Remove the micro SD from the auxiliary machine and plug it back into the USB Rubber Ducky.
Insert the USB Rubber Ducky in a USB socket of the target machine
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:

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.

Copy the binary file to a Linux machine.

Through the network, USB, etc.

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

Encode the created file and generate USB Rubber Ducky injection file
```
$ducktools.py -e inj.hostname.exe -l mx inj.hostname.exe.bin
```
Insert the USB Rubbar Ducky micro SD in the auxiliary machine

Copy the injection file on the micro SD

$cp inj.hostname.exe.bin /media/.../inject.bin

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

Unmount the micro SD
```
$umount /dev/sdX1
```
Remove the micro SD and insert it into the USB Rubber Ducky
Go to the target machine
Start a Windows command window (Win+r, Start > Run > cmd.exe, etc.)
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:

Fig. 2. inject.bin execution.

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.

Fig. 3. Target machine binary file creation.

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

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!

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

Inyección de binarios vía USB Rubber Ducky

by Carlos Benitez | Sep 5, 2021 | Tutoriales

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

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“

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

Retirar la micro SD de la máquina auxiliar y conectarla de nuevo en la USB Rubber Ducky
Insertar la USB Rubber Ducky en el conector USB de la máquina de destino.
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:

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.

Copiar el ejecutable a un equipo Linux

Por red, USB, etc.

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

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
```
Insertar la micro SD de la USB Rubber Ducky en la máquina auxiliar

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

Desmontar la micro SD
```
$umount /dev/sdX1
```
Retirar la micro SD e insertarla en la USB Rubber Ducky
Ir al sistema de destino
Iniciar una ventana de comandos de Windows (Win+r, Inicio > Ejecutar > cmd.exe, etc.)
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:

Fig. 2. Ejecución del inject.bin.

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.

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

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.

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!

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

Y otra vez el ganador es: Signal!

by Carlos Benitez | Jul 24, 2021 | Actualidad, CiberSeguridad, Privacidad, Vulnerabilidades, WhatsApp

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:

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.

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

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

by Carlos Benitez | Jun 13, 2021 | Actualidad, CiberDefensa, Filtraciones, Infraestructuras Criticas, Ransomware, REvil

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:

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

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

Kali 2021.2 + RPi 4: una pareja perfecta

by Carlos Benitez | Jun 6, 2021 | Actualidad, CiberSeguridad, Hardware, Kali, Pentest, Raspberry Pi, Tecnologías

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

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…

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:

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:

Fig. 5 – Plataformas de Kali.

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

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.

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!

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

Eludiendo al Hermano Mayor

by Carlos Benitez | May 30, 2021 | CiberSeguridad, Privacidad, Vulnerabilidades, WhatsApp

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:

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.

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.

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

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

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…?

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

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

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.

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

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.

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!

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

Dark waters

by Carlos Benitez | Feb 13, 2021 | Actualidad, Ciberprotección, CiberSeguridad, Industria, Infraestructuras Criticas, Noticias, Vulnerabilidades

Un ciberatacante intentó envenenar el agua de una planta de distribución en Florida interceptando Teamviewer.

La noticia sobre un hecho con el que hace rato se viene fantasando pero hasta ahora no se había concretado es del 8 de Febrero pasado. Un ciberatacante, aparentemente tratando simplemente de probar una vulnerabilidad, incrementó los niveles de Hidróxido de Sodio (para los del barrio, soda cáustica), de 100 partes por millón (100 ppm) a 11.100 partes por millón.

La acción fue descubierta por un operador que veía azorado cómo el cursor de la pantalla se movía “solo”. El sistema atacado fue el de control de los productos químicos que se les agrega al agua para mantener su nivel de potabilidad. En este caso, el Hidróxido de Sodio en bajas cantidades se utiliza para estabilizar el pH del agua a distribuir. Sin embargo, en las proporciones con las que el atacante configuró el sistema, en 24 a 36 hs hubiera llegado a la población produciendo serias lesiones en quienes estuvieran en contacto.

Sobre este incidente me parece oportuno hacer algunos comentarios. Uno de ellos es que de la lectura de la información, estoy de acuerdo con los analistas que coinciden en que fue alguien que simplemente se encontró con un sistema abierto y jugando pasó un valor de 100 a 11.100. Esto lo debe haber hecho simplemente agregando algunos unos delante del valor preseteado. Por esto me inclino a pensar (quiero creer) que no tenía idea de lo que estaba haciendo.

Por el otro lado, oooootra vez tenemos que hablar de TeamViewer. Es obvio que siempre hay un balance entre seguridad y facilidad de uso. A los que trabajamos en seguridad muchas veces nos odian por exagerar en las medidas de seguridad que hace que algunas aplicaciones sean engorrosas de utilizar. TeamViewer viene a facilitar la operación de una máquina que tenemos en la LAN de nuestra empresa, desde nuestra casa, sin usar VPN’s… Hay empresas en las que se utilizan sistemas de control de contenido o sistemas de protección de endpoints (EDR’s) para bloquear los accesos a herramientas de este tipo. Pero lo que más llama la atención es que sea la propia empresa la que haya decidido utilizar esta peligrosísima herramienta para una aplicación tan crítica como la distribución de agua.

Los responsables de la planta de distribución de agua de la ciudad de Oldsmar, indicaron que ya habían dejado de utilizar la aplicación. Sin embargo, al parecer, una máquina habia permanecido conectada y un atacante logró hacerse del acceso para ingresar a la misma.Y ¿cómo lo hizo?, bueno, no hacía falta ser un 1337 para esto. Hace poco, una enorme lista publicada de usuarios y contraseñas conocida como COMB incluía usuarios de la planta de Oldsmar. Eso significa que si el atacante tuvo acceso a la lista, le fue muy fácil probar contraseñas hasta entrar.

Para probarlo, lo que se puede hacer es usar (por ejemplo) theHarvester para buscar correos electrónicos de la planta de Oldsmar de esta forma:

$ theHarvester -d oldsmar.fl.us -l 500 -b all

Esto va a traer, entre otras, direcciones de email del dominio que se pasó como parámetro. Esas direcciones se pueden ingresar en el sitio que cybernews creó para verificar si la dirección de email se encuentra dentro de los registros de COMB. En el caso de las direcciones obtenidas por theHarvester, el resultado es este:

Como puede verse, la dirección de email que se encontró con theHarvester, está en la base de datos ‘leakeados’ de COMB.

Cabe aclarar que otra falla muy común en las empresas, es la de dejar instalados sistemas legacies no inventariados, antiguos y vulnerables. Estos sistemas suelen ser fácilmente hallados por los atacantes y logran ingresar a los sistemas a través de ellos. En este caso en particular, se informó que la planta tiene instaladas versiones de Windows 7, sistema operativo vulnerable y obsoleto.

Tomando en cuenta esto último, vaya uno a saber cuántos de nuestros sistemas críticos están montados sobre sistemas vulnerables… Y cuántos de ellos son accedidos remotamente por los operadores via TeamViewer… Y cuánto falta para que un atacante genere un verdadero desastre a través de estos sistemas….

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

The Insider

by Carlos Benitez | Jul 16, 2020 | Actualidad, Bitcoin, Blockchain

La masiva apropiación de cuentas de alto perfil de Twitter para robar Bitcoins sucedida el día de ayer… fue obra de un empleado interno de la compañía?

El día de ayer las redes y portales de noticias explotaban con la información de que fueron comprometidas cuentas de Twitter de personajes reconocidos mundialmente como Joe Biden, Bill Gates, Elon Musk, Barack Obama o Kim Kardashian . El uso que se les dio a esas cuentas fue el de publicar tweets para generar una estafa con Bitcoins.

Como puede verse, el tweet fraudulento consistió en invitar a los incautos a depositar U$S 1000 en bitcoins en la dirección de una billetara específica, para recibir U$S 2000 a cambio. Por más absurda que suene esta invitación, hubo mucha gente que realizó la transferencia. La publicación por parte de una figura reconocida hizo que mucha gente creyera que el scam era verdadero.

La dirección de la billetera donde se debían depositar los aproximadamente BTC 0.1 es: bc1qxy2kgdygjrsqtzq2n0yrf2493p83kkfjhx0wlh. Hasta el momento de escribir esta nota, la cantidad de transacciones en bitcoins recibida en dicha cuenta es de 377 con un total de BTC 12.86597065. Dado que la cotización del BTC es en este momento de U$S 9.207,70, el total de la suma recibida fue de unos U$S 118.466,-. Obviamente, así como ingresaron los fondos, los mismos fueron transferidos a otras billeteras por lo que el saldo actual es de sólo 1.251.874 satoshis (unos U$S 115).

Existen dos versiones sobre la causa del compromiso de las cuentas. La primera es la versión oficial de Twitter en la que se indica que un grupo de ciberdelincuentes atacaron cuentas o sistemas de los empleados de la compañía y utilizaron sistemas y herramientas internas para tomar control de las cuentas y enviar los tweets fraudulentos.

Pero hay una segunda versión por parte de Motherboard, quien publicó que el grupo de ciberdelincuentes convenció a empleados internos de Twitter a darles acceso a dichas herramientas. Como prueba de ésto, publicó una serie de captura de pantallas de las herramientas internas de Twitter actuando durante el fraude, tomando control de las cuentas y, aún más, modificando las direcciones de email asociadas.

Un efecto secundario indeseado de este fraude, es que los usuarios de Twitter no pueden cambiar sus contraseñas hasta tanto el problema haya sido resuelto. Curioso efecto teniendo en cuenta que una de las primeras medidas que se suelen tomar en el caso de compromisos de cuentas de usuarios, es el de recomendar a todos los usuarios de la plataforma que cambien sus credenciales de acceso.

Como sea, el ataque parece haber sido generado desde adentro. Ya sea que algún empleado haya sido convencido por una buena cantidad de Bitcoins, o ya sea que se haya comprometido la cuenta y los accesos de algún empleado. Al respecto caben destacar 2 aspectos.

El primero es que el empleado objeto del ataque/soborno fue uno con acceso a los sistemas de administración de Twitter. También cabe considerar la posibilidad de que el empleado atacado/sobornado no tuviera privilegios de administrador, pero que una vez dentro, y por movimiento lateral , los atacantes hayan podido obtener accesos a cuentas con privilegios de administrador.

El segundo aspecto es que seguramente el empleado a través de quien se efectuó el fraude, se encuentra como casi todos nosotros, operando desde su casa debido a la pandemia del COVID-19. Y en este caso me pregunto: las medidas de ciberseguridad que tienen implementadas, son las apropiadas?

Twitter no informó si el fraude fue descubierto por sistemas de detección internos o por denuncias de los dueños de las cuentas. Pero aquí aparece otra vez la importancia de usar herramientas de análisis de comportamiento de usuarios. Siempre es pertinente hacer este análisis, pero ahora que los empleados se encuentran trabajando desde sus casas, es crucial. Y sobre las cuentas con privilegios de administrador, es vital. Es que ahora como administradores estamos menos seguros que nunca, de si quien está accediendo a los sistemas es el verdadero administrador o alguien que comprometió su cuenta.

UPDATE 17-Jul-2020:

Twitter está en este momento en una búsqueda desesperada tratando de determinar cómo fue la intrusión sufrida. Por el momento, oficialmente afirman que fueron aproximadamente 130 las cuentas de usuarios comprometidas.

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

« Older Entries

QKD:

USB Rubber Ducky

Introducción

DISCLAIMER

USB Rubber Ducky

Binary Powershell files

Creation of an injection file

Tutorial

Summary

Acknowkedgements

Introducción

DISCLAIMER

USB Rubber Ducky

Archivos binarios Powershell

Creación del archivo de inyección

Tutorial

Resumen

Agradecimientos

MTProto

Criptoanálisis

Vuln #1: crime-pizza

Vuln #2: cliente o servidor?

Vuln #3: descifrar mensajes

Vuln #4: MITM

Whatsapp vs. Telegram vs. Signal

Westech y Sol Oriens

Experimentos

Openvas

Raspberri Pi 4 Model B

El lado oscuro

Kali 2021.2

A probar!

El Hermano Mayor

Eludiendo al Hermano Mayor

Whatsapp vs. Telegram vs. Signal

La Privacidad

La Seguridad

Whatsapp

Telegram

Signal

Comparación

Entradas recientes

Categorías