Solemos asociar que el llevar a cabo ataques contra entidades que consideramos seguras sólo puede ser realizado por atacantes altamente especializados y con profundos conocimientos sobre la temática. Aunque suele ser la norma, esto no siempre es así, y para ejemplo, la noticia que saltaba este verano de dos chicos que, movidos por el famoso juego "Pokemon Go", llegaron a introducirse en una zona de seguridad de un cuartel de la Guardia Civil de Las rozas en Madrid. Muchas veces no son necesarios unos amplios conocimientos técnicos, sino más bien dar en el clavo con ciertas técnicas o ideas medianamente diferentes que se nos ocurran.

En esta entrada vamos a comprobar cómo se comportan diferentes motores “antivirus” (AV) ante amenazas ya conocidas por ellos mismos pero que se encuentran empaquetadas por un software que creen conocer. No se busca hacer una comparativa de antivirus, sino analizar cómo se comportan y concienciar sobre la fe ciega que muchas veces se pone en ellos.

Para la creación del packer, en lugar de construir uno propio desde 0, lo que nos daría bastante ventaja pero complicaría su creación, se ha utilizado uno de los más famosos no por su poder de ocultación, sino por lo extendido de su uso y porque su código es libre, UPX. Los motores antivirus deberían ser capaces casi de ver "a través" del empaquetamiento. Para las pruebas y modificaciones que presentamos se ha utilizado versión 3.91 de UPX.

Antes de modificar el código fuente de UPX, es necesario estudiarlo ya que aun tratándose de un packer archi-conocido y de fácil extracción, no por ello lo es su código. UPX permite empaquetar diferentes formatos de ejecutables de distintas plataformas, cada formato con sus propias características únicas. Además, pueden aplicarse distintos tipos de compresión a cada muestra. Se trata de un código maduro y muy modularizado. Para crear nuestro UPX modificado tenemos que decidir qué tipo de modificación realizar y dónde. Las pruebas las vamos a llevar a cabo con ejecutables del formato PE32 ya que son los que, por cuestiones obvias e históricas, se encuentran mejor y más profundamente estudiados. Sólo nos centraremos en los códigos fuente implicados en su procesamiento, compresión y, no nos olvidemos, descompresión.

Pueden realizarse cientos de distintas modificaciones al empaquetador. Sin embargo, para simplificar el estudio en lugar de, por ejemplo, modificar alguno de los algoritmos de compresión, hemos optado por aplicar la "apenas conocida" operación de OR exclusivo (XOR) antes de proceder a la compresión. Navegando por el código que hemos descargado vamos a buscar el punto donde se comprime la información. Comprobamos que las modificaciones necesarias han de ser realizadas en el archivo "packer.cpp", que es el encargado, para todos los formatos de ejecutables, de empaquetar y desempaquetar la muestra.

El código que hemos añadido es básicamente un bucle que aplica el OR exclusivo usando el valor "0xA5" a todo el buffer antes de ser comprimido. De esta manera el resto del código del programa pensará que éste es el código original y nos evitaremos problemas con las diferentes comprobaciones de integridad que realiza UPX. El código añadido se encuentra comprendido entre las líneas 188 y 199.

Tenemos ya nuestra propia versión de UPX que antes de comprimir el ejecutable aplica XOR sobre él. Los ejecutables que intenten ser descomprimidos con otras versiones de UPX (UPX permite extraer/desempaquetar el ejecutable original) generarán un ejecutable no funcional ya que no aplican la operación de "unXOR" para obtener el código en él escondido. De igual manera, si intentamos ejecutar este programa empaquetado, no funcionará tampoco, ya que no le hemos “enseñado” a descifrarse antes de la ejecución para liberar la posible amenaza que podría encontrarse dentro de él.

Continuar leyendo fuente original SecurityArtWork