Ofuscación de malware en macros de MS Office

Ofuscación de malware en macros de MS Office (II)

La “última” moda en la distribución de malware viene en forma de documentos de MS Office con macros que llegan a tu bandeja de entrada. Si estas macros se llegan a ejecutar, intentaran descargar un ejecutable y lanzarlo para infectar el sistema. Para dificultar el trabajo de los analistas, los autores de estas macros ponen distintos obstáculos. En este post voy a continuar donde lo dejé en mi anterior post. Veamos qué métodos de ofuscación utilizan los escritores de Malware para dificultar el trabajo de los analistas.

Ofuscación

El primer tipo de ofuscación es el más sencillo. Se utilizan cadenas de caracteres normales intercaladas con caracteres representados en su codificación decimal. A continuación un ejemplo:

Estás concatenaciones de ChrS quedan como se muestra a continuación al pasar las cadenas a su interpretación en ASCII:

Como podéis ver, las cadenas siguen sin ser especialmente legibles, pero si se analiza el script, o si se ha visto antes qué pinta tiene una cadena codificada en base64, se puede llegar a la conclusión de que la función ggSFhCPeLdOSshe lo único que hace es descodificar las cadenas en base64. Limpiando todo el código quedaría así:

En esta misma línea de ofuscación utilizando distintas codificaciones, algunas muestras utilizan la representación hexadecimal. Un ejemplo a continuación:

Si lo pasamos de hexadecimal a ASCII la cadenas quedarían así:

Estas cadenas. En principio, tampoco tienen mucho sentido, pero si analizamos la función XORI, encontramos el primero de los cifrados que vamos a analizar.

Cifrado

XOR
En el trozo de código anterior, la función XORI realiza un cifrado XOR sobre la primera cadena y utilizando la segunda cadena como clave. Este es un cifrado muy simple, una de las implementaciones que se pueden encontrar en la siguiente:

Este código que puede parecer complicado, se puede entender más fácil si lo traducimos a python:

Este código es el mismo código que publiqué hace unos meses en mi blog personal, pero un poco más limpio.
Básicamente se está “xoreando” la cadena en la variable a usando como clave la variable b.
Cifrado de Cesar
El cifrado de César es un cifrado de sustitución en el que cada letra se sustituye por la letra que se encuentra X posiciones después de esta, donde X es la clave de cifrado. Por ejemplo para un cifrado de César con clave 5, la tabla de sustitución sería la siguiente:

Screen Shot 2015-04-19 at 9.00.01 PM

En el ejemplo que aparece a continuación, podemos ver un ejemplo de ROT13, o lo que es lo mismo, un cifrado de César con clave 13.

Esta función recorre la cadena que recibe carácter a carácter y le resta 13. Es decir, se trata de un cifrado de Cesar de clave 13, desplazaría 13 posiciones hacia el inicio para descifrar, pero en lugar del abecedario, utiliza la tabla ASCII.

La cadena presente en la muestra analizada quedaría descifrada de la siguiente manera:

Conclusión

Los escritores de malware se las ingenian para hacernos la vida más difícil cada vez a los analistas. Estas protecciones que utilizan están en constante evolución, de forma que herramientas como oledump.py deben actualizarse constantemente a la misma velocidad que el malware evoluciona.
Hay muchos más trucos que se están utilizando para ofuscar estas macros (renombrar funciones, dividir la funcionalidad en distintas macros, etc.) y por eso mismo os invito a coger alguno de estos documentos y analizarlo para que veáis hasta donde llegan realmente los autores de estas macros para ofuscar el comportamiento malicioso.

contrasenas-fuertes

Hablemos de contraseñas fuertes, ¿lo tenemos claro?

Durante el desarrollo de servicios y aplicaciones nos topamos con el dichoso asunto de gestionar contraseñas de usuario. Queremos que el acceso y uso de nuestra solución sea sencillo sin descuidar la seguridad de la información, es el eterno dilema de usabilidad vs seguridad…

Definir una buena política de contraseñas es vital, pero habitualmente el usuario no lo ve como algo positivo. Todos queremos que nuestra contraseña sea sencilla y rápida de escribir, pero no nos sienta nada bien descubrir un día que alguien ha entrado en nuestra cuenta y nos ha hecho la puñeta…

Leer más

Logotipo de la certificación GIAC

Cómo preparar un examen de certificación GIAC a través de SANS

Los exámenes de certificación GIAC son famosos por su dificultad, al no contar con material oficial para preparar certificaciones con un nivel técnico muy alto, y por ser exámenes a libro abierto. Sin embargo, SANS pensó en ello convirtiéndose hoy en día en un gran aliado a través de sus cursos de formación.

Leer más

malware-money

Malware is Money

En muchas ocasiones hemos escuchado el termino “Malware” pero en realidad sabemos que es? cual es su finalidad?  y como nos protegemos?

¿Que es el malware?

“El malware (del inglés malicious software), también llamado badware, código maligno, software malicioso o software malintencionado, es un tipo de software que tiene como objetivo infiltrarse o dañar una computadora o sistema de información sin el consentimiento de su propietario. El término malware es muy utilizado por profesionales de la informática para referirse a una variedad de software hostil, intrusivo o molesto.1 El término virus informático suele aplicarse de forma incorrecta para referirse a todos los tipos de malware, incluidos los virus verdaderos.”

Fuente: Wikipedia http://es.wikipedia.org/wiki/Malware

Se puede decir que la finalidad principal del malware es desarrollar software malicioso con el fin de “obtener dinero” basándose básicamente en desarrollar una aplicación con el único objetivo de bloquear sistemas operativos o neutralizar un computador y/o servidor.

El Malware no distingue de sistema operativo ni tampoco de dispositivos puede desarrollarse tanto para un gran servidor como para un Smartphone de cualquier fabricante.

De por si en el área de dispositivos móviles es donde mas se ve el desarrollo de código malicioso, tanto para obtener control del equipo a través de aplicaciones gratuitas que no pasan ningún tipo de control por parte de los fabricantes “destacando que unos menos que otros”.

¿Cual es la finalidad?

La finalidad el Malware puede ser variante pero esta claro que su objetivo principal es de robar información, daño o perjuicio del equipo o simplemente obtener dinero fácil.

Uno de los casos mas recientes famosos casos de Malware y que tuvo un impacto bastante importante es el Criptolocker que cifra el disco duro del ordenador y luego pide te pagues con dinero para enviarte las claves para descifrarlo.

https://www.osi.es/gl/actualidad/avisos/2013/09/criptolocker-virus-que-cifra-los-ficheros-del-ordenador

Es importante destacar que el malware se propagaba a través del correo electrónico utilizando como “sebo” un envió urgente de la casa de Correos (Empresa Española de entrega de mensajería y paquetes)

Aunque el Criptoloker ha tenido algunas variantes o mutaciones como los detalle el report advisory de McAfee (Intel Security), aunque va enfocada a su solución EPO:

https://kc.mcafee.com/resources/sites/MCAFEE/content/live/PRODUCT_DOCUMENTATION/24000/PD24786/en_US/McAfee_Labs_Threat_Advisory_Ransom_Cryptolocker.pdf

image

¿Como nos protegemos?

En este sentido no es mucho lo que nos toca hacer para protegernos del fulano Malware siguiendo estos simples consejos podemos estar un poco tranquilos porque en Seguridad Informática nada es “imposible” en el buen sentido de la palabra.

  1. Si tienes sospechas de que tu ordenador tiene un malware puedes extraerlo con un fichero comprimido .zip y subirlo a la pagina de virustotal.com  https://www.virustotal.com/ es una comunidad que investiga y trabaja codo a codo con los fabricantes para prevenir, detectar y eliminar códigos maliciosos con una muy buena reputación ganada desde hace muchos años. (http://tecnologia.elpais.com/tecnologia/2012/09/10/actualidad/1347276010_539192.html)
  2. Mantener nuestros sistemas independientemente de la casa fabricantes en los últimos updates (parches)
  3. Si tu ordenador o servidor es Windows es conveniente que lo revises periódicamente con la herramienta Malicious Software Removal Tool http://www.microsoft.com/es-es/download/malicious-software-removal-tool-details.aspx en un porcentaje muy elevado elimina los malware que afectan a los sistemas Microsoft
  4. Estar atento a las publicaciones de organismos e instituciones como por ejemplo INCIBE https://www.incibe.es
  5. NO ABRIR CORREOS ELECTRONICOS “FRAUDULENTOS” O DESCONOCIDOS Y TAMPOCO INSTALAR NO EJECUTAR SOFTWARE NO LEGITIMO, principalmente en los ordenadores y Smartphone.
  6. No tener ordenador ni conectarse a Internet (es un chiste!!)

HSTS, una defensa contra MITM y sslstrip

Siempre escuchamos que debemos, al menos,  asegurarnos que nuestra navegación viaja sobre HTTPs cuando debemos introducir contraseñas y/o acceder a sitos de información confidencial. Pero…¿Es HTTPs una garantía absoluta de que nuestras comunicaciones son realmente seguras?. En las tecnologías de la información nunca podremos hablar de un 100% de seguridad, y siempre debemos estar atentos a multiples circunstancias que pudieran ser aprovechadas para vulnerar nuestras comunicaciones. En este artículo introducimos un ataque clásico y eficaz contra conexiones seguras (sslstrip) y un mecanismo relativamente reciente que lo mitiga (hsts). ¿Puede considerarse HSTS el final de SSLStrip? Veamos.

Ataques Man in the Middle y SSLStrip

El ataque de hombre en el medio o MITM (del inglés Man in the Middle) es una de las técnicas mas frecuentemente utilizadas por su implementación, relativamente sencilla, y por la eficacia de sus resultados. No obstante el uso de SSL/TLS y el uso de criptografía  en las comunicaciones ha puesto siempre en jaque este tipo de interceptación de tráfico. Ante esta dificultad los ataques han tratado de sacar partido de debilidades en las suites de cifrado negociadas en una conexión segura, como BEAST, CRIME o BREACH o en vulnerabilidades SSL como Heartbleed. Actualizaciones, parches y otros condicionantes hacen que estas circunstancias no sean, en general, sencillas de explotar.

Otra técnica muy conocida y utilizada ampliamente durante un buen periodo de tiempo es SSLStrip. SSLstrip fue presentado por Moxie Marlinspike en la Black Hat 2009, y demostraba una genial idea para interceptar conexiones HTTPS  donde, en lugar de atacar el cifrado entre el cliente y el servidor se engaña al cliente, interponiéndose en mitad de la conexión. De este modo, SSLStrip hace de pasarela, intercepta el tráfico HTTP, evita que llegue un mensaje de redirección a HTTPS por parte del servidor y a continuación establece y mantiene dos conexiones: una HTTP sin cifrar con el cliente (víctima) y otra con el servidor HTTPS, manejando las cookies y la sesión para hacer creer a la víctima que está bajo una conexión segura cuando en realidad todo el tráfico va sin cifrar.

Durante un buen periodo de tiempo esta técnica dio excelentes frutos puesto que, para el servidor todo era correcto (conexion segura) y para también para el cliente, el cual no es consciente de que la conexión no es cifrada. Algunas contramedidas contra este ataque pasaban por utilizar plugins de navegador para forzar HTTPS hasta que apareció una mejora en el protocolo denominada HSTS.

HSTS: HTTP Strict Transport Security

HSTS, acrónimo para HTTP Strict Transport Security, nace con el objetivo de evitar  ataques de interceptación en conexiones HTTPS. La idea principal es introducir una nueva cabecera HTTP denominada Strict-Transport-Security, la cual puede ser enviada por un servidor al navegador cliente para fijar una política que obligue a usar únicamente conexiones seguras SSL/TLS y de como manejar las mismas con el servidor. En una política HSTS hay dos parámetros principales:

  • max-age, seguida de un número que representa el tiempo en segundos en que un navegador debe utilizar siempre HTTPS para la conexión con el dominio concreto incluso si se escribe específicamente “http://” en el barra de direcciones. Pasado ese tiempo el navegador recupera el comportamiento habitual.
  • IncludeSubdomains es otro parámetro opcional, que indicaría además al cliente que todo subdominio debe ser accedido igualmente estrictamente bajo HTTPS. Esta opción ha de ser utilizada con cuidado para evitar dejar fuera de contexto posibles alias o hospedajes bajo un CDN.

Un ejemplo de la cabecera de respuesta HSTS de conexión  con un servidor web puede ser  el siguiente:

Este campo de la cabecera establece que ,durante un año (max-age=31556926) tanto el dominio solicitado como todos sus subdominios (includeSubDomains) han de ser accedidos únicamente utilizando HTTPs.

Adicionalmente, una política HSTS también previene que un usuario pueda aceptar un certificado autofirmado o cualquier irregularidad al registrarse y recordarse la CA que firma un dominio ya visitado.

Un aspecto importante a tener en cuenta es, que cuando se visita por primera vez un servidor con HSTS se recibirán la cabecera Strict-Transport-Security y los parámetros fijados, momento desde el cual  el navegador reconocerá el sitio y aplicará la política HSTS hasta su expiración. Esta primera visita es un punto vulnerable puesto que aún el navegador no tiene información sobre el sitio en concreto. Lo mismo ocurre cuando la política caduca.

De este modo al igual que hace SSLStrip con el manejo de una  sesión HTTPs, en un ataque man in the middle se podrían eliminar las cabeceras HSTS en la primera visita (vulnerabilidad Bootstrap man in the middle)  y así de este modo evitar que el navegador reciba esta notificación y aplique una política estricta. Sin embargo del mismo modo que en la parte servidora, también es posible  establecer en el navegador (parte cliente) “listas precargadas” de dominios, a los que se aplicará una política estricta independientemente de que sea la primera vez que se visita el sitio HTTPS. Este mecanismo evitaría el Bootstrap man in the middle. En algunos navegadores se pueden consultar y/o añadir elementos de estas listas, por ejemplo en Chrome accediendo a la URI: chrome://net-internals/#hsts

 

hsts

– HSTS: Configuración de listas precargadas en Chrome –

 Consideraciones de seguridad en HSTS

Entonces…. ¿podemos considerar HTTP Strict Transport Security el mecanismo que acaba definitivamente con los ataques SSLStrip y similares?. No, y tal y como se describe en el propio RFC de HSTS existen diversos vectores de ataque entre ellos ataques basados en NTP o DNS poisoning y que convenientemente explotados pueden servir para evitar la protección ofrecida por HSTS.

En un próximo artículo echaremos un vistazo a algunas aproximaciones que hacen uso de esos vectores como por ejemplo, SSLStrip+ o Delorean.