Archivo

Archive for 14 septiembre 2017

Evadiendo no-exec stacks con técnicas ret2libc

septiembre 14, 2017 1 comentario

Desde aquellos días en los que comenzaron a aparecer las primeras vulnerabilidades en programas ejecutables, que típicamente se aprovechaban de un desbordamiento de memoria, se han implementado varios mecanismos de defensa que impiden que los programas vulnerables y potencialmente peligrosos para el sistema puedan ser una amenaza, obviamente la fuente del problema siempre se encuentra fallos de diseño e implementación, una situación difícil de controlar. En el caso de los sistemas más populares hoy en día, existen varias características interesantes que impiden que un programa que presenta condiciones de Stack o Heap overflow puedan “campar a sus anchas”, así nos encontramos con cosas como Stack Cookies o Canaries, DEP, ASLR, etc. Son mecanismos muy potentes que añaden un nivel de complejidad considerable al proceso de explotación, ya que ahora el atacante no solamente se debe preocupar por detectar y explotar vulnerabilidades, sino también de evadir esos mecanismos de protección que no le permiten montar en el sistema atacado su propia “fiesta”. Aún así, existen técnicas que el atacante puede llevar a cabo para saltarse esas medidas de protección y conseguir sus objetivos.

En éste artículo vamos a hablar de una técnica muy interesante que se puede aplicar sobre un programa vulnerable ejecutándose en un sistema GNU/Linux y que debido a su simplicidad y efectividad, la convierte en una técnica muy potente ante aquellos programas que implementan el “No-Exec”, es decir, que marcan la Stack como un espacio de sólo lectura sin la posibilidad de que el procesador interprete los bytes que podemos insertar en ella como instrucciones ejecutables. Hablamos del archiconocido “ret2libc”.

El origen del mal.

El origen de prácticamente todas las vulnerabilidades tiene su base en una mala implementación, errores en diseño y programación que le permiten a un atacante hacer de las suyas. Esto la mayoría de las veces sucede simplemente por descuidos o desconocimiento del programador, aunque también a veces, aunque el programador conoce las consecuencias negativas de cara a la seguridad de ciertas prácticas de desarrollo, por desidia/pereza, simplemente decide ignorarlas y quedarse con la típica frase de: “En mi local funciona”.

Como decía antes, estas cosas son difíciles de controlar, a menos claro, que a ese programador perezoso lo mandes a Corea del Norte a servir al amado “lidel”, en ese caso seguro que se espabila y revisa 20 veces cada una de las líneas de código de su programa.

Ahora bien, como comentaba anteriormente, las Stacks “No exec” impiden que algunas áreas de la memoria (Stack o Heap) puedan ser interpretadas por el procesador como secciones con instrucciones ejecutables. Dado que no se puede inyectar o ejecutar código malicioso en el programa, aunque sea vulnerable, el atacante debe sobrepasar esta barrera antes de poder continuar y para ello puede utilizar la técnica de “ret2libc” o Return To Libc.

Antes de explicar en qué consiste, vamos a partir de un programa vulnerable, el cual contiene el siguiente código:

Explotando el programa con No-Exec habilitado

Es fácil darse cuenta que el programa anterior, además de ser muy simple no realiza ningún tipo de verificación sobre los limites del buffer

En un sistema GNU/Linux, el programa anterior se puede compilar con GCC de la siguiente manera.

gcc -ggdb -fno-stack-protector -o programa programa.c

Por defecto, los programas compilados en la mayoría de versiones del GCC generan un binario con la característica “no-exec” habilitada, lo que significa que si encontramos una vulnerabilidad en el programa y seguimos el procedimiento clásico de sobreescribir el EIP para que realice un salto hacia la stack, lugar en donde tendremos nuestro shellcode, el resultado será una violación de acceso.

Dicho lo anterior, vamos a comenzar a inspeccionar el programa y analizar su comportamiento ante un desbordamiento de pila.

En primer lugar, se carga el programa con el depurador (GDB) y se establece un punto de interrupción en la dirección de memoria en donde se realiza una invocación a la función “tevasacorea”.

El segundo y último punto de interrupción se establece en la instrucción “ret”, justo al final de la función “tevasacorea” para poder ver el contenido de la Stack antes de que se produzca el desbordamiento.

Como se puede apreciar en la última imagen, se ejecuta un programa externo al depurador y en dicho programa, simplemente se crea una entrada de 512 caracteres (concretamente, 512 As). Se pasa por ambos breakpoints y antes de retornar de la función “tevasacorea”, se consulta el estado de la Stack que tal como se puede apreciar, ha quedado en la posición perfecta para sobreescribir el valor del registro EIP con una dirección de memoria arbitraria. Esto significa simplemente, que se debe ejecutar el programa con una entrada que contenga 512 caracteres más una dirección de retorno arbitraria que nos permita manipular el programa y llegados a éste punto, comenzamos a hablar de Ret2Libc.

Aplicando la técnica Ret2Libc para eludir el “No-Exec”

Esta técnica recibe el nombre de Ret2Libc por dos motivos, el primero de ellos es que se basa en el hecho de que en la dirección de retorno de cualquier cualquier función, se puede establecer una dirección de memoria arbitraria que puede hacer parte del programa o de los objetos compartidos y librerías que son necesarias para el correcto funcionamiento del programa, lo que significa que en el caso de no poder utilizar la Stack para nuestro propósito, siempre se puede intentar invocar a otros espacios de memoria o instrucciones ejecutables ubicadas en otra librería. Por otro lado, la librería Libc es muy habitual en programas que se ejecutan sobre sistemas GNU/Linux y en la mayoría de los casos se trata de una dependencia obligatoria, por éste motivo es posible buscar funciones interesantes en dicha librería que nos puedan resultar útiles en el proceso de explotación del programa. Las funciones que se utilizarán en este ejemplo son “system” y “exit”, la primera recibe una cadena como primer argumento, la cual representa un programa a ejecutar y la segunda, permite finalizar un proceso limpiamente. Ambas funciones se pueden concatenar en la cadena de invocaciones gracias a la técnica “ret2libc”, únicamente hay que tener en cuenta que es necesario obtener las direcciones de memoria de cada una de las funciones a invocar y posteriormente, meterlas en la stack en el mismo orden en el que se desea invocarlas. Por último, pero no menos importante, se debe tener en cuenta el tipo de vulnerabilidad que se está explotando, por ejemplo, en el caso de que la vulnerabilidad se base en el overflow de un buffer de cadenas (con el ejemplo del programa anterior con la función strcpy), se debe evitar a toda costa utilizar direcciones de memoria que contengan “null terminators” (\x00) ya que esto haría que se corte el payload y no sea posible obtener los resultados deseados.

Dicho lo anterior, es el momento de buscar las direcciones de memoria correspondientes a las funciones “system” y “exit”.

Como se puede apreciar de la imagen anterior, simplemente con el comando “print” y la función deseada, se puede obtener información sobre la librería y dirección de memoria donde se encuentra cargada dicha función.

Ahora bien, el siguiente paso consiste en especificar el parámetro adecuado a la función “system” con una cadena como “/bin/bash” sería suficiente, pero hay un pequeño problema y es que dicho parámetro no lo espera la función como una cadena simple, espera la referencia de una dirección de memoria que apunta a una cadena de texto con el nombre del binario a ejecutar, lo que se conoce coloquialmente en programación en C/C++ como un puntero. Por lo tanto, simplemente hay que buscar una dirección de memoria que apunte a una cadena que tenga el programa deseado. Afortunadamente, en las variables de entorno existen varias entradas que contienen valores de configuración y entre otras cosas, suele haber una variable llamada “SHELL” que define el programa que preferiblemente se debe de lanzar cuando se invoque a una shell en el sistema. Ahora, cómo se consigue acceso a las variables de entorno del sistema desde un programa en ejecución? La respuesta es simple, gracias a la Stack. Como seguramente ya sabreis, la Stack de un programa no solamente almacena parámetros y las variables locales correspondientes a cada Stack Frame o función invocada en un programa, también incluye todas las variables de entorno que hay en el sistema por si alguno de los Stack Frames del programa necesita acceder a cualquiera de dichas variables. Con esto en mente, basta simplemente con inspeccionar la Stack para obtener la dirección exacta donde se encuentra la variable de entorno “SHELL”.

Tal como se puede ver en el programa anterior, después de buscar los contenidos de la Stack con un comando como “x/5000s $exp” desde el depurador, se puede encontrar la variable de entorno SHELL y una dirección de memoria que puede ser útil para enviar como primer argumento de la función “system”.

Ahora que ya se cuenta con todo lo necesario para aplicar la técnica de Ret2Libc, es el momento de componer el payload que tendrá los siguientes valores:

“A”*512 + Dirección de memoria system + Dirección de memoria exit + Dirección de memoria del programa a ejecutar por system.

Por último, a diferencia de los valores que normalmente se suelen encontrar en tráfico de red, cuando se habla de programas y direcciones de memoria, se utiliza el formato “little endian”, por lo tanto es necesario establecer cada dirección de memoria en sentido inverso.

Después de lanzar nuevamente el programa con el payload adecuado, utilizando la técnica ret2libc, se puede apreciar que se ha conseguido ejecutar el programa “/bin/bash” y ahora se cuenta con una consola plenamente funcional, solamente ha bastado con indicar las direcciones de memoria adecuadas y concatenar cada una de las invocaciones con sus correspondientes parámetros. Una técnica que puede ser sencilla de implementar y muy potente, os animo a que lo probéis.

Un saludo y Happy Hack.

Adastra.

Vuelve el patito low cost, ahora grazna como un USB Rubber Ducky original

septiembre 5, 2017 8 comentarios

Sobre los autores: Ernesto Sánchez (@ernesto_xload) y Joel Serna (@JoelSernaMoreno) son consultores en seguridad informática que han participado en eventos como: Navaja Negra, MorterueloCON y Eastmadhack.

 

 

Buenos días a todos!

Hace un tiempo, os contábamos como hacer un dispositivo BadUSB por alrededor de 1 euro, lo podéis leer aquí , en él, a efectos prácticos, explicábamos como montar un dispositivo similar a un USB Rubber Ducky, en el sentido de que se comporta como un teclado automático y pre-programado para hacer unas funciones concretas, pero puede quedarse algo corto en algunas ocasiones, sobre todo por el limitado almacenamiento y memoria ram de su microcontrolador ATTINY85: 8KB de flash y 512 bytes de ram.

Como no podía ser de otra forma, hemos estado pensando es éste asunto y ofreceros algo más funcional y, sobre todo, más fácil de utilizar. Una de las opciones deseables que nos parecia mas útil, era que se pudiesen utilizar directamente scripts del USB Rubber Ducky sin tenerlos que adaptar de ninguna forma, debido a su amplia expansión, conocimientos y ejemplos que existen en internet.

Como mencionamos en el artículo anterior, y aunque sea repetirlo, un BadUSB es un dispositivo USB con apariencia de otro dispositivo distinto (para confundir al usuario normalmente) que al conectarlo a cualquier ordenador realiza “otras cosas”, en el caso mas general emula un teclado que de forma automática “teclea” lo que le hayamos programado a gran velocidad sin que el usuario se percate, normalmente, de lo realizado.

Cuando hablamos de BadUSB, así en general, se cubren muchos dispositivos , desde algunos hackeados a tal efecto como los pendrives con el controlador Phison 2251-03 (2303), los dispositivos de desarrollo genérico como Teensy (en cualquiera de sus variantes) o Arduino Leonardo / Micro o dispositivos específicos orientados a auditorias de seguridad como el Phoenix Ovipositor o el USB Ruber Ducky, siendo éste último el mas famoso entre la comunidad hacker (entiéndase siempre en el buen sentido de la palabra, para más información sobre la comunidad hacker visitar este link).

Aunque solo sea por ser el mas famoso, y porque vamos a acabar usando su lenguaje de scripting, vamos a hacer una reseña sobre el USB Rubber Ducky: es un dispositivo desarrollado y comercializado por la empresa estadounidense Hak5 que una vez conectado al ordenador se comporta como un teclado virtual, programable a través de un sistema de scripting relativamente simple (scripts que una vez escritos han de ser compilados y almacenados en formato binario en su tarjeta micro SD).

Como ejemplo: el clásico “Hola Mundo”:

DELAY 3000
GUI r
DELAY 500
STRING notepad
DELAY 500
ENTER
DELAY 750
STRING Hello World!!!
ENTER

El código hace lo siguiente:

Delay 3000: Espera “x” milisegundos (en este caso se produce una pausa larga al inicio para la instalación de drivers en el equipo, aunque también se utiliza para dar un tiempo prudencial a que se abra un programa u otras tareas)

GUI r: Pulsa las teclas Windows (GUI) y “R” simultáneamente para abrir la ventana “Ejecutar” en un sistema operativo Windows

STRING notepad: Manda una cadena de caracteres, en este caso Notepad (editor de textos de windows)

ENTER: Envia la tecla Enter, en este caso para ejecutar el programa Notepad

STRING Hello World!!!: Manda una cadena de caracteres, en este caso Hello World!!!

ENTER: Envía la tecla Enter, en éste caso para introducir el carácter de nueva línea.

La referencia completa al lenguaje de scripting se puede encontrar aquí, algunos scrips de ejemplo aquí (La mayoría de dichos scripts pueden encontrarse debidamente revisados para Windows 10 en el github de Joel).

Una vez explicado para que sirve el dispositivo y mostrado un payload de ejemplo, algunas personas se pueden encontrar con una barrera: el precio, cuesta unos 45 US$ (mas 12US$ de envío) que está muy bien para algunos sectores profesionales o semiprofesionales, pero puede estar fuera de alcance de algunas personas que solo les apetece “cacharrear”.

Por eso, después de buscar mucho, valorar opciones y un montón de horas de picar código, os presentamos como hacer un clon perfecto del USB Rubber Ducky, que interpreta sus scripts a la perfección sin siquiera tener que compilarlos, por unos 10€ o menos.

El dispositivo en concreto que vamos a utilizar es éste:

Se puede encontrar fácilmente en aliexpress buscando badusb.

NOTA IMPORTANTE: Aunque en los resultados salen otros dispositivos, en éste artículo nos referimos ÚNICAMENTE al mostrado en la fotografía

El dispositivo presenta las siguientes características de hardware:

  • Microcontrolador ATmega32u4 (32KB de flash y 2,5KB de ram) con bootloader de Arduino Leonardo

  • Tarjeta microSD

  • Circuitería auxiliar varia (circuitería discreta, oscilador a 16mhz, regulador de tensión a 3,3v y conversor de niveles)

Vamos al meollo de la cuestión:

Instalación y configuración:

Para poder hacer este BadUSB, necesitaremos:

  • Tener el dispositivo mencionado anteriormente.

  • IDE de Arduino (Descargable de https://www.arduino.cc/en/Main/Software)

    • Una vez instalado debemos asegurarnos de que las librerías estén actualizadas.

    • En caso de usar Linux debemos asegurarnos que nuestro usuario pertenece al grupo dialout

    • En el caso de usar Windows deberemos tener correctamente instalados los drivers de Arduino Leonardo

  • Librería de teclado multi idioma (https://github.com/ernesto-xload/arduino_keyboardlib) ya que por defecto la de arduino solo soporta teclados con el layout en_US

  • Firmware del interpretador: Descargable desde aquí

Una vez todo correctamente instalado, ejecutamos el IDE de Arduino y abrimos el código del interpretador: Archivo > Abrir

Tenemos que asegurarnos que todo está configurado para la placa compatible con Arduino Leonardo, para ello vamos a la opción de herramientas -> Placa -> “Arduino Leonardo”. Posiblemente nos asignará el puerto, si no, seleccionamos el correspondiente.

Conectamos el dispositivo.

Compilamos y subimos el código con el botón correspondiente.

En la parte inferior del IDE de Arduino veremos si se ha grabado correctamente:

Con ésto ya tenemos el clon del USB Rubber Ducky listo, a partir de aquí sólo hay que copiar el script de USB Rubber Ducky correspondiente en una microsd formateada en fat16 o fat32 con el nombre “script.txt” y una vez insertado en un ordenador procederá a su ejecución.

Por supuesto el código fuente del interpretador es software libre y podemos modificarlo a nuestro gusto, añadiendo nuevos comandos o personalizando los ya existentes, de hecho existen dos comandos extra a modo de ejemplo: led_on y led_off (en minúsculas) que encienden y apagan el led presente.

Como ejemplo vamos a probar el payload You got quaqued!, del propio repositorio de Hak5.

NOTA: Algunos payloads hechos para el USB Rubber Ducky disponibles en al repositorio de Hak5, están preparados para Windows 7, y necesitan ser modificados para versiones posteriores de éste sistema operativo (se pueden encontrar ya modificados en éste enlace como hemos dicho anteriormente). En este caso concreto, lo hemos modificado para poder utilizarlo en Windows 10 y no tengamos ningún error:

DELAY 1000
GUI d
DELAY 500
GUI r
DELAY 500
STRING chrome
DELAY 500
ENTER
DELAY 5000
STRING https://i.imgflip.com/1dv8ac.jpg
DELAY 500
ENTER
DELAY 3000
CTRL s
DELAY 1000
STRING %userprofile%\Desktop\QUACKED
ENTER
DELAY 500
GUI d
DELAY 500
GUI r
DELAY 500
STRING %userprofile%\Desktop\QUACKED.jpg
ENTER
DELAY 1000
MENU
DELAY 500
DOWNARROW
DELAY 500
DOWNARROW
DELAY 500
ENTER
ALT F4
DELAY 500
GUI d
DELAY 500
MENU
DELAY 500
STRING v
DELAY 500
STRING d

Como somero resumen: lo que hace el payload es abrir Chrome, entrar a un enlace donde encontramos una imagen del USB Rubber Ducky, la descarga, la pone de fondo de pantalla del escritorio y, por último, oculta todos los iconos del escritorio.

Podemos ver que el lenguaje que utiliza este payload, es exactamente el mismo que utiliza el USB Rubber Ducky. De ésta forma, podemos usar cualquier payload existente para el Rubber Ducky, crear nuestros propios payloads con el mismo lenguaje o utilizar alguna de las múltiples herramientas que los genera automáticamente como Metasploit.

Bonus track:

En la búsqueda que hemos hecho anteriormente en aliexpress hemos podido ver como aparecen otros dispositivos, algunos basados en el Attiny85 que cubrimos en la entrada BadUSB Ultra Low Cost, y otros basados en el Atmega32U4 como el que ha ocupado éste articulo, pero sin zócalo para tarjeta micro SD, son los que se pueden ver a continuación:

Llama especialmente la atención el que se comercializa directamente con el factor de forma de un pendrive acabado en aluminio, en caso de querer realizar un pentesting seria el mas indicado para dejar abandonado en las inmediaciones del objetivo y esperar a que alguien lo conecte. No podemos olvidar la prueba realizada por Elie Bursztein en abril del 2016 plasmada en “Concerns about USB security are real: 48% of people do plug-in USB drives found in parking lots, las cifras hablan por si mismas, y son simplemente apabullantes.

En éste caso no podemos hacer de script kiddies o usar alguna herramienta de “botón gordo” y vamos a tener que programar el código que queremos que ejecute el microcontrolador directamente, cosa no muy complicada debido a toda la documentación existente, pero amigos… el hacking implica fundamente aprender y conocer, por eso nunca os damos todo hecho, perdería toda la gracia.

A continuación mostramos un ejemplo, muy básico que abre un bloc de notas y escribe la cadena “hola mundo” (es válido tanto para Windows como para Linux con Gnome o derivados comentando y/o descomentando las líneas correspondientes):

#include "Keyboard.h"

void setup() {
	// Inicializamos el teclado
	Keyboard.begin();

}

void loop() {
	delay(20000); // Espera 20 segundos (20000 milisegundos) 	
        CommandAtRunBarMSWIN("notepad"); 
        // Abre notepad en Windows 	
        //CommandAtRunBarGnome("gedit"); // Abre gedit en Gnome
	Keyboard.println("hola mundo"); // Enviá “hola mundo”
	while(1); // Detiene la ejecucion del programa.

} 

void CommandAtRunBarMSWIN(char *SomeCommand { 
	Keyboard.press(KEY_LEFT_GUI);
	Keyboard.press('r');
	delay(100);
	Keyboard.releaseAll();
	delay(1500);
	Keyboard.print(SomeCommand);
	Keyboard.press(KEY_RETURN);
	Keyboard.releaseAll();

}

void CommandAtRunBarGnome(char *SomeCommand){
	Keyboard.press(KEY_LEFT_ALT);
	Keyboard.press(KEY_F2);
	delay(100);
	Keyboard.releaseAll();
	delay(1500);
	Keyboard.print(SomeCommand);
	Keyboard.press(KEY_RETURN);
	Keyboard.releaseAll(); }

Las funciones CommandAtRunBarMSWIN y CommandAtRunBarGnome han sido extraídas de la librería phukdlib de IronGeek que aunque originalmente está preparada para dispositivos Teensy podéis descargarla modificada para Arduino Leonardo y compatibles aquí.

Para cualquier duda o sugerencia podéis contactar con nosotros a través de los enlaces que hemos proporcionado de Twitter y Github o bien el canal de Telegram de The Hacker Way.

¡Hasta la próxima!

Get back the low cost duck, now squawks like an original USB Rubber Ducky

septiembre 5, 2017 Deja un comentario

About the authors: Ernesto Sánchez (@ernesto_xload) and Joel Serna (@JoelSernaMoreno) are computer security consultants who have participated in events such as: Black Knife, MorterueloCON and Eastmadhack.

 

 

Hi everyone!

Long time ago, we show you how to make a BadUSB device so cheap (around 1 euro), you can read it here. To practical effects, we explained how to mount a Rubber Ducky USB device, in the matter that it behaves like an automatic keyboard and pre-programmed to do some specific functions. but may be some short sometimes, especially by the limited storage and RAM memory of your ATTINY85 microcontroller: 8KB flash and 512 bytes of ram.

As it not be otherwise, we have been thinking this matter and offer something more functional and, above all, easier to use. One of the desirable options, that seemed to us most useful, was that you could directly use USB Rubber Ducky scripts without having to adapt them in any way, due to its extensive expansion, knowledge and examples that exist on the internet.

As we mentioned in the previous article, a BadUSB is a USB device with the appearance of another device (for confuse the user) that when is connected to any computer does “other things”, The more usual fact, emulates a keyboard that automatically “types” what we have programmed at high speed without the user realizing what we have done.

When we talk about BadUSB, overall, we talk about many devices, from some hacked devices, to such effect as the pendrives with the controller Phison 2251-03 (2303), generic development devices such as Teensy (in any of its variants), Arduino Leonardo / Micro or specific devices oriented to Security audits such as the Phoenix Ovipositor or the USB Ruber Ducky, being this last one the most famous among the hacker community (always be understood in the good meaning of the word, for more information about hacker community visit this link).

Not only because it is the most famous, and because we will end up using its scripting language, we are going to review the USB Rubber Ducky: it is a device developed and marketed by the US company Hak5 that once connected to the computer, it behaves like a virtual keyboard, programmable through a relatively simple scripting system (scripts that once written must be compiled and stored in binary format on your micro SD card).

As an example: the classic “Hello World”:

DELAY 3000
GUI r
DELAY 500
STRING notepad
DELAY 500
ENTER
DELAY 750
STRING Hello World!!!

ENTER

The code does the following things:

DELAY 3000: Wait “x” milliseconds (in this case a long pause occurs at driver installation on the computer, but it is also used to a reasonable time to open a program or other tasks)

GUI r: Press the Windows (GUI) and “R” keys simultaneously to open the window

“Run” on a Windows operating system

STRING notepad: Sends a characters string, in this case Notepad (editor texts of windows)

ENTER: Send the Enter key, in this case to execute the program Notepad

STRING Hello World!!!: Send a character string, in this case Hello World!!!

ENTER: Send the Enter key, in this case to enter the new line character.

The full reference to the scripting language can be found here, some scripts here (Most scripts can be found revised for Windows 10 in Joel’s github).

Once explained for what the device serves are used and showed an example payload, some people may find a problem: the price, it costs about 45 US $ (Plus $ 12 shipping cost) which is fine for some professional sectors, but for “normal people like us” maybe that price is outside the budget if we only want to “play a little”

That is why, after searching, view differents options and a lot of hours of itching code, we show you how to make a perfect USB Rubber Ducky clone, which interprets their scripts perfectly without even having to compile them, for only 10 € or less.

The device which we are going to use is this:

It can be easily found on aliexpress, searching for badusb


EXPLANATORY NOTE: Although other devices are output in the results article we refer ONLY to that shown in the photograph

The device has the following hardware features:

  • ATmega32u4 microcontroller (32KB flash and 2.5KB ram) with Bootloader by Arduino Leonardo

  • MicroSD card

  • Auxiliary circuitry varies (discrete circuitry, oscillator at 16mhz, Voltage to 3.3v and level converter)

Installation and configuration:

To be able to do this BadUSB, we will need:

  • Have the device mentioned above.
  • Arduino IDE (Downloadable from https://www.arduino.cc/en/Main/Software)
    • Once installed we must make sure that the libraries are updated.
    • In case of using Linux we must make sure that our user belongs to the dialout group
    • In case of using Windows we must have correctly installed the Arduino Leonardo drivers

Once everything is properly installed, run the Arduino IDE and open the Interpreter code: File > Open

We have to make sure everything is set up for the board compatible with Arduino Leonardo, for this we go to the option of tools -> Board -> “Arduino Leonardo “. Possibly we will assign the port, if not, select the port corresponding.

We connect the device.

We compile and upload the code with the corresponding button.

At the bottom of the Arduino IDE we will see if it has been recorded correctly:

With this instructions, we already have the USB Rubber Ducky clone ready for use,now er need copy the corresponding Rubber Ducky USB script into a microsd formatted in fat16 or fat32 with the name “script.txt” and once inserted in a computer shall, it begin to run it.

Of course, the source code of the interpreter is free software and we can modify it to our liking, adding new commands or customizing them exist, there are, in fact, two extra commands by way of example: led_on and led_off (In lower case) that turn on and off the present LED.

As an example we will test the payload You got quaqued!, from the repository itself Hak5.

NOTE: Some payloads made for USB Rubber Ducky , they are available at Hak5 repository, are prepared for Windows 7, and need to be modified for latest versions of this operating system (you can find modified in this link as we have said previously). In this matter, we have modified it to be able to use it in Windows 10 and we have no error:

DELAY 1000
GUI d
DELAY 500
GUI r
DELAY 500
STRING chrome
DELAY 500
ENTER
DELAY 5000
STRING https://i.imgflip.com/1dv8ac.jpg
DELAY 500
ENTER
DELAY 3000
CTRL s
DELAY 1000
STRING %userprofile%\Desktop\QUACKED
ENTER
DELAY 500
GUI d
DELAY 500
GUI r
DELAY 500
STRING %userprofile%\Desktop\QUACKED.jpg
ENTER
DELAY 1000
MENU
DELAY 500
DOWNARROW
DELAY 500
DOWNARROW
DELAY 500
ENTER
ALT F4
DELAY 500
GUI d
DELAY 500
MENU
DELAY 500
STRING v
DELAY 500
STRING d

As a summary: what payload does is open Chrome, enter a link where we find an image of the USB Rubber Ducky, download it, puts it as Desktop wallpaper, and finally, it hides all the icons on the desktop.

We can see that the language that uses this payload, is exactly the same used by USB Rubber Ducky. In this way, we can use any existing payload for Rubber Ducky, create our own payloads with the same language or use one of the multiple tools that automatically generates them as Metasploit.

Bonus track:

In the search we have done previously in aliexpress, we have been able to see how other devices appear, some based on the Attiny85 that we covered in the entry BadUSB Ultra Low Cost, and others based on the Atmega32U4 like the one we talked in this article, but without socket for Micro SD card, are the ones that can be seen below:

Its curious the fact that it is directly marketed with the shape of a finished pendrive (covered with aluminium), If you want to realize a pentesting, this would be the most suitable to leave in the surroundings of the objective, and wait for someone to connect it. We can not forget the test done by Elie Bursztein in April 2016 expressed in “Concerns about USB security are real: 48% of people do plug-in USB drives found in parking lots” the rates speak for themselves, and they are overwhelming.

In this case we can not do script kiddies or use any tool “Fat button”and we will have to program the code that we want to run on the Microcontroller directly, thats not a very complicated task because there are a lot of documentation for it, but, my dear friends … hacking involves learning and Knowing, that’s why we never give you everything done,It loses its appeal.

Here is an example, very basic that opens a notebook and write the string “hello world” (it is valid for both Windows and Linux with Gnome or derivatives commenting and / or uncommenting the corresponding lines):

#include "Keyboard.h"

void setup() {
	// Inicializamos el teclado
	Keyboard.begin();

}

void loop() {
	delay(20000); // Espera 20 segundos (20000 milisegundos) 	CommandAtRunBarMSWIN("notepad"); // Abre notepad en Windows 	//CommandAtRunBarGnome("gedit"); // Abre gedit en Gnome
	Keyboard.println("hola mundo"); // Enviá “hola mundo”
	while(1); // Detiene la ejecucion del programa.

} 

void CommandAtRunBarMSWIN(char *SomeCommand { 
	Keyboard.press(KEY_LEFT_GUI);
	Keyboard.press('r');
	delay(100);
	Keyboard.releaseAll();
	delay(1500);
	Keyboard.print(SomeCommand);
	Keyboard.press(KEY_RETURN);
	Keyboard.releaseAll();

}

void CommandAtRunBarGnome(char *SomeCommand){
	Keyboard.press(KEY_LEFT_ALT);
	Keyboard.press(KEY_F2);
	delay(100);
	Keyboard.releaseAll();
	delay(1500);
	Keyboard.print(SomeCommand);
	Keyboard.press(KEY_RETURN);
	Keyboard.releaseAll(); }

The CommandAtRunBarMSWIN and CommandAtRunBarGnome functions have been from IronGeek’s phukdlib bookstore which were originally created for Teensy devices. You can download it modified for Arduino Leonardo and compatible here.

For any doubt or suggestion you can contact us by the Links we have provided from Twitter and Github, or the Telegram channel from The Hacker Way.

See you soon!

A %d blogueros les gusta esto: