Cómo evadir fácilmente el antivirus del correo de Yahoo! y varios IDS y otros antivirus

MIME describe el formato de transferencia de cualquier correo electrónico que contenga archivos adjuntos, imágenes incrustadas, etc. Este formato se remonta a los inicios de Internet y dado que los protocolos utilizados (UUCP y el actual SMTP) se basaban en texto ASCII, cualquier binario o mensaje no ASCII tenía que ser codificado previamente para el transporte.
Para especificar el tipo de codificación se utiliza la cabecera Content-Transfer-Encoding, sirva el siguiente ejemplo:
     From: foo
     To: bar
     Subject: foobar
     Mime-Version: 1.0
     Content-type: multipart/mixed; boundary=barfoot
   
     --barfoot
     Content-type: text/plain
   
     This is only ASCII text, but the attachment contains an image.
     --barfoot
     Content-type: image/gif
     Content-transfer-encoding: base64
   
     R0lGODlhHgAUAOMJAAAAAAgICAkJCRVVFSEhIfDw8PLy8vX19fj4+P//////////////////////
     /////yH5BAEKAA8ALAAAAAAeABQAAARaMMlJq7046827/2DoFQBQcKRJpWfCSm8Vw2VrzROOr/Xd
     57/YzvWjqYjHYarEZLaERWBz+vwZAgKD72isHg+DwWFrQ3pbCAIBQeYloxhdEH6Rv+/lrvusF3ki
     ADs=
     --barfoot--

Dado que para el transporte sólo es necesaria una única codificación la especificación permite el uso de un único encabezado. Pero ¿qué ocurre si se utilizan de todas formas varios encabezados?

Veamos un ejemplo con el virus de testing Eicar, donde añadiremos dos cabeceras Content-Transfer-Encoding headers, una para el típico base64 y otra para quoted-printable: 
 From: foo
     To: bar
     Subject: eicar - base64 cte header preceding quoted-printable
     Mime-Version: 1.0
     Content-type: multipart/mixed; boundary=barfoot

     --barfoot
     Content-Transfer-Encoding: base64
     Content-Transfer-Encoding: quoted-printable
     Content-Disposition: attachment; name=eicar.txt

     WDVPIVAlQEFQWzRcUFpYNTQoBF4pN0NDKTd9JEVJQ0FSLVNU
     QU5EQVJELUFOVElWSVJVUy1URVNULUZJTEUhJEgrSCo=
     --barfoot--

Resulta que la mayoría de clientes de correo y los interfaces web usarán el primer encabezado, mientras que los IDS como Bro y Snort y un montón de productos antivirus sólo usarán la última cabecera. Los resultados que se detallan a continuación se basan en pruebas realizadas a 9 de octubre:

Comportamiento observado: clientes de correo, Web mail, MTA, IDS

La primera cabecera Content-Transfer-Encoding es usada por:
  •     google MTA (bloquea virus directamente en la conversación SMTP)
  •     gmail Web interface
  •     GMX Web interface (bloqueará el correo si contiene virus, ver abajo)
  •     AOL Web interface
  •     Thunderbird
  •     Apple Mail
  •     Opera Mail
  •     Perl MIME::Tools, que es usado por amavisd
  •     KDE kmail
  •     horde Web interface
La última cabecera Content-Transfer-Encoding es usada por:
  •     mutt
  •     Outlook.de Web interface (Windows Live Mail)
  •     basado en el análisis del código fuente: snort 2.9.6.2. Interesante que solo acepta "Encoding" en lugar de "Content-Transfer-Encoding".
  •     basado en el análisis del código fuente: bro 2.3.1
Otros comportamientos:
  •    Al correo en Android parece que no le gusta el conflicto con varias cabeceras y no mostrará el archivo adjunto.
  •    GMX encuentra el virus sin importar el orden de los encabezados que utilizamos y reemplaza el correo afectado por un correo informativo acerca de la infección por el virus
  •    AOL MTA encuentra el virus también en ambos casos y bloquea el correo inmediatamente en el diálogo SMTP. Bien hecho!
  
Comportamiento observado: productos Antivirus

Los productos de antivirus muestran una gran variedad de comportamiento. Se han probado mediante virustotal.com con archivos en formato mbox o RFC822. Cualquier motor que no encontrara el virus Eicar en cualquiera de estas pruebas fue ignorado, ya que parece no entender estos formatos. resultados: 
  •     El escáner de virus Rising sólo encontrará el virus si se da una sola cabecera.
  •     7 productos antivirus sólo comprueban el primer encabezado y por lo tanto están en línea con la mayoría de los clientes de correo: Jiangmin, Kaspersky, Panda, Symantec, TrendMicro, TrendMicro-HouseCall, Zoner.
  •     12 productos antivirus sólo comprueban la última cabecera y se comportan de este modo contrario a la mayoría de clientes de correo, lo que hace posible el fraude: Agnitum, Avast, Avira, Comodo, Cyren, DrWeb, ESET NOD32-, Fortinet, F-Prot, NANO-Antivirus, Tencent, VBA32.
  •     11 productos detectan el virus independiente del orden de las cabeceras y por lo tanto no pueden ser evadidos de esta manera, no importa qde correo utilizado: BitDefender, ClamAV, a-squared, F-Secure, GData, Ícaro, McAfee, McAfee-GW-Edición , Microsoft, MicroWorld-eScan, Sophos.

El comportamiento más divertido: Correo Web de Yahoo!

El MTA de Yahoo parece no tener incorporado el análisis de virus, pero la interfaz de correo Web utiliza Norton de Symantec para escanear los archivos adjuntos antes de la descarga. El problema es que la interacción entre el antivirus y la descarga es totalmente independiente lo que permite la evasión inmediata del escáner antivirus:
  •      El antivirus analiza la última cabecera Content-Transfer-Encoding y por lo tanto no va a encontrar el virus en nuestro correo de ejemplo.
  •      La descarga de los datos adjuntos mirará la primera cabecera Content-Transfer-Encoding y por lo tanto el contenido (el virus) será descargado correctamente.
  •      La vista previa del correo usará de nuevo la última cabecera.
El problema se comunicó a Yahoo a través de hackerone en 09/10/2014, pero lo cerraron como "no se corregirá", porque dijeron "Ya estamos al tanto de esta funcionalidad en nuestro sitio y estamos trabajando en una solución.". No se recibió respuesta cuando le preguntaron si era buena idea publicar el fallo. La última vez que se comprobó (28/10/2014) el bug seguía allí.

Fuente: http://noxxi.de/research/content-transfer-encoding.html

Comentarios

Publicar un comentario