• Buffer overflow en Poison Ivy

  • Sección libre del foro. Puedes presentarte, comentar temas actuales del mundo informático o lo que sea de tu agrado.
Sección libre del foro. Puedes presentarte, comentar temas actuales del mundo informático o lo que sea de tu agrado.
 #171277  por BoneThugz
 22 Abr 2010, 02:24
El analista Andrzej Dereszowski estaba investigando el robo de datos en una empresa y descubrio que se habia llevado a cabo a traves del Poison Ivy. Esto le hizo pensar mucho sobre el hecho de que muchos analistas usan tecnicas de fuzzing para encontrar vulnerabilidades en aplicacions como Intenet Explorer o Adobe Reader, entonces penso: Por que no usar las mismas técnicas para encontrar vulnerabilidades en Poison Ivy? El analista ha descubierto un Buffer Overflow en el Poison Ivy. La victima puede explotar la vulnerabilidad y atacar el atacante a traves del servidor inyectando en el Poison Ivy shellcode y espiarlo a el con sus propias tecnicas. Digamos que se revierte el proceso y el servidor pasa a cliente con lo que el hacker es hackeado. El analista desvela unos cuantos secretos del Poison Ivy durante su analisis. El tamaño tan pequeño del server es debido a que el cliente manda el codigo al servidor para ser ejecutado algo muy complejo de llebar a cabo. Tambien desvela varias jugadas que el autor dejo en el codigo para no ser destripado. El analista terminó admirado del trabajo tan brillante que hizo Shapeless y termina demostrando que este ataque es explotable aunque no lo ha hecho publico por seguridad.

En el blog de F-Secure lo comentan brevemente: [ Debe registrarse para ver este enlace ]

Aqui el detallado informe del analista Andrzej Dereszowski : [ Debe registrarse para ver este enlace ]

Ya cayo Bifrost y ahora el Poison Ivy... Y dudo veamos a sus respectivos autores regresar a la escena... Que habra sido de ksv y Shapeless...
 #171280  por depuniet
 22 Abr 2010, 02:37
Gracias por la noticia te dejo un enlace de algo al hilo sobre este tema rats y compañias av que nos brindo su experiencia en alguunos casos de users de nuestro foro..

[ Debe registrarse para ver este enlace ]

Es realmente curios y parece ser que esto lo usan las compañias por lo que entendi, bueno es mi enfoque no el enfoque...Saludos
 #171281  por BoneThugz
 22 Abr 2010, 02:47
depuniet escribió:Gracias por la noticia te dejo un enlace de algo al hilo sobre este tema rats y compañias av que nos brindo su experiencia en alguunos casos de users de nuestro foro..

[ Debe registrarse para ver este enlace ]

Es realmente curios y parece ser que esto lo usan las compañias por lo que entendi, bueno es mi enfoque no el enfoque...Saludos
LOL jajaja Si que es curioso si
No sabia de estos casos gracias por pasarme la info. Resulta bastante interesante e inquietante al mismo tiempo el tema.
Saludos bro
 #171340  por 4n0nym0us
 22 Abr 2010, 10:17
uuh que buena noticia! malo que en un futuro si esto se emprende en las empresas antivirus no habrá cura hasta identificar el troyano exactamente y sus variantes… es difícil para estos tiempos que esta técnica se lleve como Anti-hacker.
 #171344  por tk68
 22 Abr 2010, 11:14
[...]
El tamaño tan pequeño del server es debido a que el cliente manda el código al servidor para ser ejecutado algo muy complejo de llevar a cabo
[...]

Técnica explotada por los mejores, si tengo tiempo hago un ejemplo

 #171382  por p0is0n-123
 22 Abr 2010, 13:28
Podria hacer un ejemplo facil en VB6 con winsock no?
ws.senddata

Salu2
 #171384  por BoneThugz
 22 Abr 2010, 13:32
tk68 escribió:[...]
El tamaño tan pequeño del server es debido a que el cliente manda el código al servidor para ser ejecutado algo muy complejo de llevar a cabo
[...]

Técnica explotada por los mejores, si tengo tiempo hago un ejemplo
tk68 master estoy con muchas ganas de saber mas del tema y saber como trabajan los grandes te tomo la palabra aver si haces un ejemplo donde se vea claro como funciona cuando puedas bro.
Saludos bro y mastah y enhorabuena por el merecido VIP
 #171439  por DSR!
 22 Abr 2010, 17:34
recien ahora se enteran como funciona el poison ivy? xDDDD
no habia que ser muy despierto para saberlo
 #171485  por FroZenFeW
 22 Abr 2010, 19:55
yo hace como un año le encontre el bof al sever pero nunca lo explote se crasheaba mi pc
 #171515  por raulrl
 22 Abr 2010, 20:34
Jajaja que el poison-ivy funcionaba con el codigo que recibia del servidor era un "secreto" a gritos, es más, tenia que ser necesariamente asi dado el pequeño servidor que tiene
Sin embargo, me encantaria que tk68 postearía un ejemplo del funcionamiento de esta manera de operar ya que nunca vi nada parecido y creo que es algo sumamente interesante

Saludos
 #171521  por sod
 22 Abr 2010, 20:53
tk68 escribió: Técnica explotada por los mejores, si tengo tiempo hago un ejemplo
¿Seria como cargar una shellcode ?
Saludos
 #171534  por BoneThugz
 22 Abr 2010, 21:30
Vaya pues a mi me ha sorprendido jajajj Aunque a algunos no os haya sorprendido tanto seguro que os interesa saber como funciona como a mi. He buscado mas info sin exito por lo visto este metodo se llama func-in. Usando este metodo el server se conecta con el cliente y todas las funciones son inyectadas en el servidor. He buscado mas info y por lo que dicen muchos es algo muy complejo de hacer que solo usan y dominan los mejores. Poca gente domina esta tecnica entre ellos Shapeless. He oido que la gente que trabaja en el Cerberus RAT desecho usar esta tecnica dada su complejidad.
Aver si tk68 nos hace el tuto jajajaj
Saludos brothaz
 #171958  por tk68
 23 Abr 2010, 22:15
Revisando mis apuntes encontré esta joya que parte de dos tutoriales:

El método usado es la de inyección directa de código en memoria, es decir no se
hace a través de dll, para esto hay que ponerse al día con la API que hacen el
manejo de memoria, aquí os pongo un pequeño resumen de lo que hace cada una:

VirtualAllocEx: Localiza memoria en el espacio de direcciones de un proceso
VirtualFreeEx: Libera la memoria localizada con VirtualAllocEx
WriteProcessMemory: Permite escribir en un bloque de memoria de otro proceso que hemos localizado con VirtualAllocEx
GetProcAddress: Nos da la dirección de una función exportada de una dll
CreateRemoteThread: Crea un hilo en un proceso remoto

Como veis son muy conocidas por todos nosotros y mucho más por las compañías
de AVs que nos la marcan en muchos de nuestros RunPE

Porque todo hay que decirlo, es "casi" lo mismo que haremos, inyectar código en
memoria para ejecutarlo, pero no vamos a inyectar todo un dll o ejecutable con
su código y variables como hacemos en nuestros crypters
, no eso no

Cuando un RunPE inyecta nuestro ejecutable en memoria el Sistema Operativo se
encarga en darnos el espacio necesario para la ejecución del proceso, esto nos
facilita las cosas, pero con la inyección directa lo vamos a hacer manualmente
ya que necesita subir al espacio de direcciones del proceso anfitrión los datos
así como la del código que debemos ejecutar.

Lo primero que haremos será definir la estructura de datos que contendrá todo el
código necesario para que pueda ejecutarse.

Después lo subiremos al espacio de direcciones del proceso anfitrión con
VirtualAllocEx y WriteProcessMemory

La estructura la vamos a definir así:
Código: [ Debe registrarse para ver este enlace ]
struct TParamFL
{
   PGetModuleHandleA GetModuleHandleA; // Puntero a la API GetModuleHandleA
   PFreeLibrary FreeLibrary;           // Puntero a la API FreeLibrary
   char DllName[256];                  // Cadena que contiene el nombre de la dll a liberar
};
Los datos de la estructura deben ser inicializados para luego copiarlos al
espacio de direcciones del proceso remoto:

Código: [ Debe registrarse para ver este enlace ]
DWORD __stdcall InjFreeLibrary(TParamFL* P)
{
  // Devuelve true si el módulo no existe en el proceso, de lo contrario el modulo sigue cargado
  HMODULE hModule = P->GetModuleHandleA(P->DllName); // Localiza el HMODULE de la dll
  P->FreeLibrary(hModule);                           // Libera La DLL
  return (P->GetModuleHandleA(P->DllName)==0);       // Si el modulo no existe, se descargó
}
Esta función lo que hace es recibir como parámetro un puntero a nuestra estructura
que llamará a las APIs por sus direcciones contenidas en dicha estructura

Solo falta subir el código al espacio de direcciones de nuestro proceso anfitrión

Para hacer esto hay que calcular su tamaño en bytes cuando sea compilado y enlazado
y su dirección de memoria.

Todo esto lo haremos en tiempo de ejecución y para ello utilizaremos lo que habíamos
escrito antes para calcular el tamaño.

Si Func1 y Func2 son punteros a sendas funciones escritas consecutivamente, el
tamaño binario de Fun1 sería este:

Código: [ Debe registrarse para ver este enlace ]
(UINT)Func2 - (UINT)Func1;
Esas funciones no se pueden cambiar de sitio en nuestros fuentes porque sino
seria desastroso.

Vamos al lío. Inyectaremos el código necesario en el espacio de direcciones del
proceso remoto lo ejecutaremos y limpiaremos los restos.

El código para hacer esto sería el siguiente:
Código: [ Debe registrarse para ver este enlace ]
BOOL FarFreeLibrary(DWORD Pid, char* DllName)
{
  DWORD    ExitCode;
  HANDLE   hThread = 0;
  HANDLE   hProc;      // El handle del proceso en el que inyectaremos
  TParamFL Param;      // El tipo de dato de la estructura
  UINT     TamFun;     // El tamaño de la función a inyectar
  void*    BFunc;      // Lugar de memoria donde copiaremos nuestra función
 
  //Metemos la dirección de las apis en la estructura
  Param.FreeLibrary = (PFreeLibrary)GetProcAddress(GetModuleHandle("KERNEL32.DLL"), "FreeLibrary");
  Param.GetModuleHandleA = (PGetModuleHandleA)GetProcAddress(GetModuleHandle("KERNEL32.DLL"), "GetModuleHandleA");
  strcpy(Param.DllName, DllName);
 
  //Abrimos el proceso en el que nos inyectaremos
  hProc = OpenProcess(PROCESS_ALL_ACCESS, false, Pid);
 
  //Reservamos espacio para nuestra estructura en el proceso a inyectar y la escribimos
  void* BParam = VirtualAllocEx(hProc, 0, sizeof(TParamFL), MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE);
  WriteProcessMemory(hProc, BParam, &Param, sizeof(TParamFL), NULL);
 
  //Calculamos el tamaño de la función a inyectar
  TamFun = (UINT) FarFreeLibrary - (UINT)InjFreeLibrary;
 
  //Reservamos espacio para la función, escribimos en él y creamos un hilo
  BFunc = VirtualAllocEx(hProc, 0, TamFun, MEM_RESERVE | MEM_COMMIT, PAGE_EXECUTE_READWRITE);
  WriteProcessMemory(hProc, BFunc, InjFreeLibrary, TamFun, NULL);
  hThread = CreateRemoteThread(hProc, NULL, 0, (LPTHREAD_START_ROUTINE)BFunc, BParam, 0, NULL);
  if(hThread){
    // Labores de limpieza...
    WaitForSingleObject(hThread, INFINITE ); // Espero a que se termine de ejecutar el Thread
    GetExitCodeThread(hThread, &ExitCode);   // Recojo el resultado
    CloseHandle(hThread);                    // Cierro el Handle hThread
    VirtualFreeEx(hProc, BParam, 0, MEM_RELEASE); // Libero memoria de parámetros
    VirtualFreeEx(hProc, BFunc,  0, MEM_RELEASE); // Libero memoria del código
  }
 
  CloseHandle(hProc);
 
  return (BOOL)ExitCode;
}
En resumen solo inyectamos la función que deseamos ejecutar.

Aquí buenas referencias:

De Escafandra:
[ Debe registrarse para ver este enlace ]
[ Debe registrarse para ver este enlace ]

Y de Rolandj:
[ Debe registrarse para ver este enlace ]

Espero que os sea de utilidad

Tengo realizada una implementación en VB6 que realicé en noviembre del año pasado
en cuanto lo encuentre os lo posteo pero en la sección de fuentes, que por cierto es
más complejo de entender pues con VB para hacer lo mismo hay que hacer muchas
más piruetas, con lo "fácil" que es con C++ , Delphi y ASM...

Última edición por tk68 el 23 Abr 2010, 22:38, editado 3 veces en total.
 #171965  por BoneThugz
 23 Abr 2010, 22:28
Grandeee tk68!!!!!
Buah no tengo palabraaas!!
Hay cosas en el codigo se me escapan lo estudiare a fondo, muchisimas gracias bro y mastah tremendo aportee!