viernes, 30 de enero de 2015

INetSim, virtualizando network para Análisis Dinámico de Malware.

Estos últimos días estuve trabajando en unos análisis de Malware, y sin dudas un software que me ayuda bastante para la etapa Dinámica del análisis es INetSim. (Internet Services Simulation Suite). 

Este software lo que hace es simular servicios de internet. Entre otras cosas como se le conocería en términos de ingles: "Faking Network". Muchas veces, cuando se intenta analizar un malware mediante análisis dinámicos, con un poco de experiencia es suficiente para darnos cuenta mediante librerias y funciones que importa o strings que sale a buscar a internet o reportar información, y a veces preferimos realmente estudiar su funcionalidad y su comportamiento de manera controlada y bajo nuestro dominio. 

A veces no queremos que el malware realmente salga a internet, o reporte a sus creadores de nosotros, es por eso que en ciertas circunstancias optamos por 'hacer una faking network' y menos ruido con sus creadores.. Una tool excelente es sin dudas InetSim, la cual permite ejecutar el malware y hacerle creer que esta conectandose a el mundo exterior cuando en realidad no hace otra cosa que interactuar con nosotros mismos, o mejor dicho con nuestro amigo inetsim y sus servicios.

Dejare una breve reseña de como funciona, y como puede sernos util, a la hora de realizar como dije un analisis dinamico de malware.

Mi red para esta ocasion esta compuesta de la siguiente manera, 2 SO's:

A - 192.168.0.102 -> PC Linux con Debian/Ubuntu donde estara corriendo el InetSim.
B - 192.168.0.107 -> VMWARE corriendo un Windows XP.. (Nuestro entorno con malware). Este es un entorno controlado, y el malware a ejecutar no es realmente maligno, es solo para simularlo, así que asegurense de tener un entorno controlado y seguro siempre que hagan pruebas.

> Instalando INetSim (Linux):

# Para usuarios Debian/Ubuntu Linux: http://www.inetsim.org/packages.html
# Para el resto de mortales:  http://www.inetsim.org/downloads/inetsim-1.2.5.tar.gz

Una vez instalado, usarlo es demasiado facil. Pero antes hay que revisar y editar algunas cosas de configuracion. Ustedes luego podran editar e ir metiendo mano y modificar a su gusto sin romper nada. Iniciar mas o menos servicios, etc. Pero en este caso edito estas lineas para la prueba:

$> sudo nano /etc/default/inetsim

Buscamos la siguiente linea y ponemos el ENABLED en '1', salvamos el cambio y salimos:

# Whether or not to run the internet simulation suite; set to 0 to disable.
ENABLED=1

Lo siguiente sera ir al archivo de configuracion:

$> sudo nano /etc/inetsim/inetsim.conf

Buscamos la siguiente linea, la descomentamos y asignamos la IP del Linux donde corre InetSim, mi caso era la siguiente IP:

service_bind_address    192.168.0.102

Luego buscamos la siguiente linea y si bien dice 127.0.0.1, que seria la del linux mismo, descomentamos y editamos por la IP que tiene asignada:

dns_default_ip          192.168.0.102

Con esto ya podria funcionar tranquilamente para la prueba.
Lo iniciamos:

$> sudo /etc/init.d/inetsim start

Abrimos otra terminal, verificamos con nmap que esto es asi..

$> nmap 192.168.0.102 -vv

Y como resultado se darán cuenta si todo funciona bien que ya tenemos como 20 puertos y servicios abiertos corriendo :O.. no se asusten, solo 'simulan' muy bien serlo ;).

Nos dirigimos ahora a la maquina virtual que corre Windows XP y antes de 'ejecutar el malware' editamos su configuracion de red, para que apunte a nuestra ip con inetsim. Le decimos que su gateway a internet vamos a ser Nosotros (inetsim) y que su DNS por ende tambien :).





Una vez que configuramos esto, optamos por ejecutar el malware.. y veremos que pasa. Los reportes que genera inetsim se guardan en /var/log/inetsim/report

Una vez que se ejecuta el malware luego de pasado unos minutos, detenemos el inetsim y vemos el reporte que nos genero. En mi caso quedo algo así:


















1) Vemos como en el primer recuadro de la imagen, se realiza una consulta DNS bastante rara..
"0kxwuhostingmax.iprisid.com"... 

2) En el segundo resaltado vemos como dos minutos después realiza una petición via HTTP GET para descargar de un dominio bastante raro "http://0xhosting01.aknoid.com/176867868754/autodwn.exe".
¿que sera? ;p

3) Y en el 3 resaltado, vemos como realiza una similar petición pero ahora baja una librería llamada ashid.dll.

Como ultimo comentario, me gustaría resaltar como ven en la imagen el InetSim "responde" ante la petición del malware (GET) y le envía un 'fake file'. 

Esto es demasiado útil, ya que supongamos si un Malware que estamos analizando donde no tenemos mucho conocimiento de su comportamiento sale a internet a buscar algún tipo de archivo ya sea un .exe o .dll o cualquier otro, y no lo logra, posiblemente el malware quede inoperativo, o quizás no demuestre mas comportamientos hasta que su tarea de bajar otro archivo le permita poder completar todos los pasos de su infección y explotación.

Espero sea útil, personalmente, cumple un rol fundamental como tool en mis primeras etapas de análisis dinámico de malware en mis trabajos.

Saludos.

miércoles, 28 de enero de 2015

Vulnerabilidad Ghost + PoC (Remote Linux Vulnerability Glibc)


Sin dudas una de las noticias de estos dias es el descubrimiento de la vulnerabilidad -CVE-2015-0235-. 
Afecta a la libreria "glibc". La gente de Qualys descubrio un interesante desbordamiento de buffer en una funcion de glibc llamada "the_nss_hostname_digits_dots()". Se puede tomar ventaja remotamente de esta vulnerabilidad desde la funcion gethostbyname() de glibc.

Al parecer las versiones de glibc-2.17 y glibc-2.18 se encuentran parcheadas. De hecho lo estaban desde el 2013 pero no se considero de mayor prioridad y se paso por alto en muchos desarrolladores, por ende los modulos de ciertas distribuciones siguen siendo aun vulnerabilides.

Algunas app conocidas que dependen de esta libreria son Apache, GnuPG, OpenSSH, entre otras.

A continuacion adjunto un PoC hecho por vpetkov, para que puedan testear la vulnerabilidad localmente.  Primero dense una idea de que libreria tienen instalada con el siguiente comando, desde mi debian/ubuntu:

$> ldd --version

Desde Redhat y CentOS:

$> rpm -q glibc


El PoC para verificar si es vulnerable o no el sistema, peguenlo en un editor de texto, guardenlo como ghost.c. Luego lo deben compilar con gcc de la siguiente manera:

$> gcc ghost.c -o ghost (compilan)

$> chmod +x ghost (le dan permisos de ejecucion).

$> ./ghost (ejecutan)


#------------CODIGO-----------#
#include 
#include 
#include 
#include 
#include 

#define CANARY "in_the_coal_mine"

struct {
  char buffer[1024];
  char canary[sizeof(CANARY)];
} temp = { "buffer", CANARY };
 
int main(void) {
  struct hostent resbuf;
  struct hostent *result;
  int herrno;
  int retval;
 
  /*** strlen (name) = size_needed - sizeof (*host_addr) - sizeof (*h_addr_ptrs) - 1; ***/
  size_t len = sizeof(temp.buffer) - 16*sizeof(unsigned char) - 2*sizeof(char *) - 1;
  char name[sizeof(temp.buffer)];
  memset(name, '0', len);
  name[len] = '\0';
 
  retval = gethostbyname_r(name, &resbuf, temp.buffer, sizeof(temp.buffer), &result, &herrno);
 
  if (strcmp(temp.canary, CANARY) != 0) {
    puts("vulnerable");
    exit(EXIT_SUCCESS);
  }
  if (retval == ERANGE) {
    puts("not vulnerable");
    exit(EXIT_SUCCESS);
  }
  puts("should not happen");
  exit(EXIT_FAILURE);
}

#------------FIN DEL CODIGO-----------#

Si es vulnerable, saldria "vulnerable" je je.
Sino, lo contrario.

Para fixear esto desde Debian/Ubuntu vamos a enfocar solamente en actualizar la libc.

$> apt-get update
$> apt-get install --only-upgrade libc6 -y

(reiniciemos, y luego volver a verificar con el PoC si sigue siendo vulnerable).
El resto de distribuciones, favor de verificar y tratar de actualizar el modulo a la ultima version, y no seria mala idea el kernel tambien. 

Mas informacion detallada directo desde Qualys Community:
https://community.qualys.com/blogs/laws-of-vulnerabilities/2015/01/27/the-ghost-vulnerability
http://blog.vpetkov.net/

domingo, 18 de enero de 2015

Instalando VMware Player en Ubuntu 14.04 // Fixeando issues.

Volviendo a jugar con mi Linux y actualizando el ubuntu a la ultima version 14.04, experimente que el VMware Player (6.0.1 build-1379776), en mi caso el que tomo como ejemplo y uso, tenia ciertos inconvenientes y no bastaba con la instalación desde cero para que funcionara. (Idea basada en la de Garrett Skjelstad's)

Al iniciarlo, el VMware Player arrojaba el siguiente cartel:

"Before you can run vmware several modules must be compiled and loaded into the running kernel"

Por lo que vamos a optar a resolverlo de la siguiente manera.
Una vez bajamos el bundle desde la pagina lo instalamos normalmente:

$> chmod +x VMware-Player-6.0.1-1379776.i386.bundle
$> sudo ./VMware-Player-6.0.1-1379776.i386.bundle

Luego que finaliza la instalación satisfactoria, nos damos cuenta de este error, por lo tanto vamos a crear un archivo "patch" para resolver esto, lo copiamos y pegamos en un archivo de texto y lo guardaremos asi: "filter.c.diff":


> #if LINUX_VERSION_CODE < KERNEL_VERSION(3, 13, 0)
206a208,210
> #else
> VNetFilterHookFn(const struct nf_hook_ops *ops,        // IN:
> #endif
255c259,263
<    transmit = (hooknum == VMW_NF_INET_POST_ROUTING);
---
>    #if LINUX_VERSION_CODE < KERNEL_VERSION(3, 13, 0)
>       transmit = (hooknum == VMW_NF_INET_POST_ROUTING);
>    #else
>       transmit = (ops->hooknum == VMW_NF_INET_POST_ROUTING);
>    #endif


En mi caso lo deje en la carpeta temporal /tmp/filter.c.diff.

Vamos a proceder a aplicar dicho parche sobre un archivo que se encuentra comprimido en la carpeta de modulos del vmware. Hacemos lo siguiente en un terminal:

Nos hacemos root:
$> sudo su

Nos dirigimos al modulo comentado:
$> cd /usr/lib/vmware/modules/source/

Realizamos un backup por las dudas del tar que contiene el archivo a modificar:
$> cp vmnet.tar vmnet.tar.backup

Extraemos del archivo comprimido vmnet.tar el archivo filter.c que vamos a fixear con nuestro filter.c.diff:
$> tar xvf vmnet.tar vmnet-only/filter.c

Fixeamos el archivo filter.c con nuestro archivo que habíamos creado en /tmp/filter.c.diff:
$> patch vmnet-only/filter.c < /tmp/filter.c.diff

Por ultimo, volvemos a compactar el archivo ya fixeado:
$> tar -uvf vmnet.tar vmnet-only/filter.c

Limpiamos la carpeta creada..
$>rm -rf vmnet-only/

Volvemos a ejecutar el VMware-Player y deberia estar resuelto el inconveniente.