Identificando la distribución de Malware a través de ETags

7 de junio de 2011 Por

Recientemente en el blog de Lenny Zeltser, se ha publicado una entrada donde hace referencia a un documento realizado por “CompuCom”, donde se explicaba una prueba de concepto de una técnica para identificar la distribución de un malware mediante la cabecera HTTP ETags.

En estos momentos dos de las principales fuentes para poder filtrar y prevenir la distribución a los usuarios finales es mediante listas de IPs o listados de dominios maliciosos (ver MDL por ejemplo). Pero todos sabemos que tanto las IPs como los dominios van variando de una manera muy rápida, lo que hace muy difícil la tarea de filtrar y prevenir la distribución en base a estos listados.

Los investigadores de “CompuCom” proponen utilizar la cabecera http ETags a modo de “fingerprint”. La cabecera HTTP ETag es opcional y enviada por el servidor Web, que sirve para que el cliente pueda realizar una validación condicional de la caché, de manera que en el caso de que se haya servido ese objeto no volverlo a solicitar con lo que se produce un ahorro de ancho de banda entre cliente y servidor.

A continuación os mostramos nuestras impresiones del documento. Lo primero que debemos tener claro es que:

1. La cabecera ETag es opcional.
2. Por lo que hemos podido ver cada uno de los servidores Web, posee un formato diferente para la cabecera ETag. A continuación podemos ver un listado de ETags de servidores Web diferentes (en el artículo ponen como ejemplo un ETag como el cuarto del listado)

ETag: “ee83d8-436-40d5a603”
Server: Apache/1.3.41 (Unix)

ETag: “94e_4f_4c746125”
Server: N/A

ETag: “2185-401-3e1d8991”
Server: Microsoft-IIS/5.0

ETag: “100055cbca1:c716”
Server: Microsoft-IIS/6.0

ETag: “30d88cc73ffcb1:0″
Server: Microsoft-IIS/7.5

ETag: W/”2-1289833087000”
Server: nginx/0.7.65

ETag: “2798007-0-47a564046cac0”
Server: Apache/2.2.3 (CentOS)

ETag: “6f69-49f8eb6ce7a00”
Server: Apache/2.2.17

ETag: “-513799732”
Server: lighttpd/1.4.19

3. El cálculo depende de determinadas variables temporales, variables asociadas al sistema, etcétera. Por poner un ejemplo, en el caso de Apache tras visitar la URL “hxxp://192.168.1.40/file.exe”, que se trata de un fichero infectado, el servidor Web nos devuelve (véase http://httpd.apache.org/docs/current/mod/core.html):

HTTP/1.1 200 OK
Date: Wed, 01 Jun 2011 16:17:30 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Wed, 01 Jun 2011 01:06:03 GMT
ETag: “33b309-5400-4a49c1fd8d4c0”
Accept-Ranges: bytes
Content-Length: 21504
Connection: close
Content-Type: application/octet-stream

El Etag que nos envía el servidor se divide en:

  • 33b309: Inode, inodo en el sistema que tiene asociado.
  • 5400: Size, tamaño de fichero
  • 4a49c1fd8d4c0: Mtime, tiempo de la última modificación.

Este mismo binario en otro sistema sería servido con un ETag diferente (inodo y mtime cambiarán con una alta probabilidad). Podemos plantearlo como si tuviéramos tres variables:

  • V1=IP
  • V2=dominio
  • V3=sistema (englobamos sistema operativo, servidor web y binario)

En el caso de que V3 sea constante, podemos detectar el malware, dando igual el valor que tenga V1 y V2, dado que no se contemplan en su cálculo.

Estaremos atentos a la evolución de la investigación de “CompuCom”, pero por el momento pensamos que tienen un largo camino por recorrer, para ver su efectividad.