Category Archive Vulnerabilidades

PorjLeonett

Un bug en WhatsApp obliga a borrar conversaciones

Dos investigadores indios han reportado un bug en WhatsApp que permite borrar en forma remota conversaciones de la plataforma. ¿Cómo? Enviando un mensaje con caracteres especiales de 2 mil palabras (que pesa 2 KB), el cual colapsa el funcionamiento de la aplicación en el dispositivo del receptor, obligándolo a borrar la conversación.

Indrajeet Bhuyan y Saurav Kar, ambos de 17 años, demostraron la vulnerabilidad a The Hacker News y explicaron que, una vez recibido este mensaje especial, el usuario tendrá que borrar la conversación y empezar una nueva con la persona en cuestión, ya que abrir el mensaje sólo hará que WhatsApp se siga deteniendo, hasta que el chat se borre.

whatsapp_error

Con esta lógica, cualquiera puede obligar a otro usuario a borrar una conversación, si no desea que haya registros, o enviar este mensaje especial a un grupo para que no quede otra que disolverlo y hacer que todos sus integrantes lo abandonen.

Según los jóvenes, el bug fue comprobado en Android Jelly Bean (4.2), KitKat (4.4) y todas las versiones anteriores, pero no ha sido probado en iOS, y no funciona en Windows Phone 8.1. Además, se encontró en todas las versiones de WhatsApp, incluyendo la 2.11.431 y 2.11.432.

Algunos usuarios ya habían estado experimentando problemas como este: iGeeksBlog reportó que WhatsApp se detenía repetidamente en iOS 8 Beta, y lo atribuyó a “ligaduras”. “Si una conversación o chat grupal en WhatsApp tiene palabras conteniendo las letras combinadas “ff”, “fi” o “tt”, abrir esa conversación hará que la aplicación se detenga. Extraño como suena, el problema persiste en iOS 8 beta 5 y versiones anteriores”, afirma el sitio.

Esto significaba que, ya sea recibiendo o enviando esa combinación de caracteres, la aplicación dejaría de funcionar. Por el momento no ha habido una respuesta oficial por parte de WhatsApp, propiedad de Facebook desde principios de año, aunque los investigadores indios creen que esta vulnerabilidad podría estar afectando a 500 millones de usuarios.

Hace poco, WhatsApp dio un paso adelante incorporando cifrado de punta a punta en sus mensajes, por lo que parece estar pendiente de posibles falencias y trabajando para revertirlas.

Créditos imagen: ©Barry Hoggard/Flickr

Autor Sabrina Pagnotta, ESET

Fuente> welivesecurity.com/la-es/

PorjLeonett

Hooks en la API de Windows y cómo se roba información

Hace unas semanas analizamos un caso práctico de inyección de código malicioso, pero nos había quedado pendiente entender qué hacía ese código inyectado. En esos detalles nos detendremos hoy, prestando atención a las técnicas de hooking de llamadas a la API de Windows utilizadas por este malware.

Recapitulando, en el Laboratorio de Investigación de ESET Latinoamérica recibimos una muestra que inyectaba código malicioso en todo proceso que hiciera uso de User32.dll, mediante la utilización de la llave de registro AppInit_DLLs. Si debuggeamos cualquier proceso con OllyDbg, podremos observar cómo se carga y ejecuta la DLL maliciosa antes del proceso en sí. Esta DLL se encuentra empaquetada con uPolyX y, si bien no nos detendremos en el análisis de este packer, podemos comentar que parte del proceso de carga del código desempaquetado en memoria se realiza con una llamada a memset y sucesivos memcpy:

unpacking upolyx

En la imagen vemos cómo las llamadas se realizan de manera dinámica, mediante el uso deGetProcAddress. En particular, se observa la copia de datos de una región de memoria a la otra, de contenido que parece estar cifrado. De hecho, si continuamos analizando el código, veremos la presencia de un bucle que descifra el contenido copiado, obteniendo un ejecutable a partir de la dirección de memoria 0x333130. Luego, si bien se realizan varias acciones tendientes a construir el ejecutable en memoria, en algún punto se transfiere el control a este código malicioso. A partir de aquí ya podemos enfocarnos en tratar de determinar qué roba este malware.

Entre las primeras instrucciones veremos que se crea un nuevo thread que ejecutará el código que se muestra en la imagen que sigue. Allí observamos una llamada a la subrutina 0x251084 y la posterior comparación contra una serie de constantes. Esa subrutina recibe como argumento elnombre del proceso en el que se ha inyectado el código y le calcula una función para obtener otra cadena.

Vemos que se está tratando de determinar si el proceso inyectado es un navegador; este malwareapunta al robo de datos durante la navegación. Si no es un navegador, se termina la ejecución.

check proceso navegador

Dado que estamos debuggeando Internet Explorer, la ejecución del código malicioso continúa. Lo próximo que observaremos es que el malware espera hasta que ws2_32.dll sea cargada en memoria. Adicionalmente, se descrifran unas strings en memoria, pero luego volveremos sobre esto. Lo que sí nos interesa ahora es el código que sigue en la imagen:

hooking ws2_32

Primero vemos una llamada a VirtualAlloc para reservar una porción de memoria. Luego, vemos el uso de GetProcAddress para obtener la dirección de cuatro rutinas de ws2_32.dll: getaddrinfo, gethostbyname, send y WSASend. Esas cuatro rutinas serán hookeadas para que, cada vez que sean utilizadas por iexplore.exe, la llamada sea interceptada y se ejecute código malicioso antes de la rutina en sí.

Esto se observa en las instrucciones posteriores, donde se llama a una subrutina que realiza estehooking y que he decidido renombrar como do_the_hook. Si ahora nos preguntamos qué hacedo_the_hook, lo vemos en la siguiente imagen:

construccion hook jmp

Si bien lo que vemos es solamente una pequeña parte del código de do_the_hook, quiero resaltar cómo se modifica cada rutina en la dirección que antes se había obtenido con GetProcAddress, de tal modo de construir un salto incondicional hacia otra ubicación. Así, se introduce un JMP en la primera instrucción de la rutina a ser hookeada. Además, vemos el uso de VirtualProtect para otorgar y revocar permisos de escritura sobre esa dirección de memoria, antes y después de realizadas las modificaciones.

sin hook vs con hook jmp
En la imagen anterior vemos cómo luce la rutina getaddrinfo antes y después de ser hookeada. Se observa que las primeas 3 instrucciones han sido remplazadas por el salto incondicional. ¿Qué hay en 0x2514CB, destino del salto? Lo vemos en la siguiente imagen:

malware hookeado

Si observamos cuidadosamente todas las direcciones de memoria involucradas, notaremos el siguiente flujo de ejecución: cuando se llama desde iexplore.exe a alguna de las rutinashookeadas, el salto JMP en la primera instrucción nos lleva a la subrutina maliciosa. Ésta tiene dos llamadas: la primera, en 0x2512C9, ejecuta el código malicioso de robo de información; la segunda lleva a una tabla en 0x2930000 que devuelve la ejecución al getaddrinfo luego de la primera instrucción de salto. Puede mencionarse entonces que aquella región de memoria que se había reservado con VirtualAlloc es la que corresponde a esta tabla de saltos en 0x2930000.

Ya sabemos cómo se hookean ciertas llamadas en los navegadores para la ejecución de código malicioso. Sin embargo, aún no hemos contestado qué hace este malware. ¿Qué intenta robar? Si vemos el código malicioso detrás del hook a WSASend, por ejemplo, encontraremos lo siguiente:

parseo host
Se observa el código que parsea la petición GET enviada por el navegador de tal modo de obtener el host. En el ejemplo vemos que el host es www.bing.com, la página de inicio que teníamos por defecto en Internet Explorer. ¿Y qué hace una vez que conoce el host? Veamos la siguiente imagen:

listado de servers

¿Se acuerdan que en un momento mencionamos que se descifraban unas strings en memoria? Esas strings son las que se observan en la imagen anterior; vemos diversos sitios de Rusia yUcrania como vk.com, google.ru y google.com.ua. Luego, si el sitio visitado por la víctima se encuentra en la lista, se realiza el robo de información; por ejemplo, de los archivos temporalesde la sesión.

Es importante notar que este tipo de ataque a usuarios de habla rusa ya lo hemos visto en nuestro Laboratorio, aunque con una menor complejidad, cuando estuvimos analizando una muestra que recorre Latinoamérica.

Más allá de este ejemplo, es claro que si el atacante logra introducir código aleatorio en un navegador podrá robar casi cualquier tipo de información, incluso antes de que sea cifrada, o alterar las peticiones de manera de conectarse a otros servidores o manipular la comunicación.

SHA-1 de la muestra analizada
1a3ca5b59632768dcb7c68d1b97d09750154bf22 – ctvqzym.exe
4e0f086030d7f5d3b21059bf6f313b879f130b5b – nqtbvce.dll (DLL inyectada)

Créditos imagen: ©Rob Gallop/Flickr

Autor Matías Porolli, ESET

Fuente> welivesecurity.com/la-es/

PorjLeonett

¿Deberías preocuparte por amenazas como Regin?

Desde que se descubrió a Stuxnet varios años atrás, ha habido un desfile de malware dirigido -como Flame, Duqu, Gauss y ahora Regin- que puede haber sido creado o sustentado por estados nacionales. Estas complejas amenazas tienen una gran parte de sus funcionalidades diseñadas para espiar a sus víctimas. Naturalmente, amenazas tan excepcionales y polémicas ganan mucha cobertura en los medios, pero, como una persona o compañía promedio, tú, ¿deberías prepocuparte por este asunto?

En líneas generales, a menos que tengas secretos de estado o proveas servicios financieros o de Internet a alguien que los tenga, no es probable que vayas a encontrar con amenazas notables como Regin y compañía.

Esto no significa que no hay potenciales amenazas para la persona promedio, ya que para la mayoría de los estudios, se descubren más de 200 mil nuevos malware cada día. Muchos de ellos son menos complejos, pero más prevalentes. Para aquellos que no son blanco de agencias gubernamentales, la protección es relativamente simple, y hay cosas que todos pueden hacer para estar seguros contra amenazas “regulares”:

1. Actualización

Siempre es importante actualizar tu software, incluyendo sistemas operativos, aplicaciones y plugins de navegadores. Hablando del tema, Adobe acaba de lanzar un parche de urgencia para Flash Player. Para un usuario promedio, esta vulnerabilidad constituye un riesgo mayor que el malwareRegin, así que asegúrate de instalar esta actualización tan pronto como sea posible.

2. Backup

Los accidentes suceden, y no solo hablamos de problemas de seguridad. Tener un buen backup (copias de respaldo) puede acelerar mucho la recuperación ante alguno de estos problemas, por lo que te será de utilidad revisar esta Guía de Backup con consejos prácticos. Los cibercriminales se han mostrado muy interesados en crear ransomware que secuestra archivos últimamente; si tienes una copia de seguridad actualizada, esta clase de malware se vuelve más una molestia menor que una amenaza seria.

3. Múltiples capas de defensa

Los productos de ESET detectan variantes de la familia de malware Regin, entre muchas otras. Todavía no se sabe cómo esta familia (o el malware en general) evolucionará en el futuro, por lo que es una buena idea usar múltiples capas de detección. Una solución anti-malware con firewall es algo útil de tener.

También puedes proteger tus datos cifrándolos al almacenarlos y al enviarlos a través de la red, por ejemplo en correos electrónicos o vía web. Además, podría ayudarte tener una pequeña (y saludable) cuota de paranoia en lo que respecta a interacciones online, ya que los ciberdelincuentes a menudo tratan de convencer a los usuarios para que dejen al malware pasar a través de las defensas. Y por supuesto, ten cuidado con las técnicas de Ingeniería Social.

4. Doble factor de autenticación

Asumo que, como lector recurrente de este sitio, sabes la importancia de usar contraseñas fuertes y seguras. Muchos sitios y servicios como Facebook y LinkedIn ahora ofrecen doble factor de autenticación, lo cual te ofrece una capa extra de protección aun en caso de que tu contraseña sea robada.

En esta era de la proliferación de malware complejo y dirigido, podría parecer que la batalla está perdida y que no podremos vencer la embestida. Si un adversario con determinación, los fondos y el respaldo suficiente como un estado nacional tiene como blanco a una compañía o individuo, la mejor esperanza será una rápida detección. Pero la mayoría de las personas alrededor del mundono son propensas a ser atrapadas en la mira de estas armas digitales.

Hay muchas cosas que podemos hacer para mejorar nuestra seguridad a un grado razonable, de manera que limitemos severamente la cantidad de malware que sea una verdadera amenaza para nosotros.

Autor Lysa Myers, ESET

Fuente: welivesecurity.com

PorjLeonett

Actualización crítica de Flash Player (Parchea!)

Adobe ha lanzado una actualización urgente fuera de ciclo para una vulnerabilidad crítica de ejecución remota de código en su popular reproductor Flash Player. La vulnerabilidad está siendo actualmente explotada in-the-wild.

La vulnerabilidad crítica (CVE 2014-8439) en Flash Player para Windows, Mac y Linux fue mitigada originalmente hace más de un mes en la versión del 14 de octubre de 2014, pero un investigador francés de Kafeine encontró un exploit activo en los Angler Exploit Kit y Nuclear Exploit Kit después de que Adobe publicara el parche.

Según F-Secure, a vulnerabilidad permite a un atacante ejecutar código arbitrario debido a una debilidad en la forma en que se maneja un puntero sin referencia a memoria. Un atacante podría crear un archivo Flash especialmente diseñado para activar la vulnerabilidad, que conduciría a la ejecución del código del atacante con el fin de tomar el control del sistema de la víctima.

En su boletín APSB14-26, Adobe clasificó la vulnerabilidad como crítica y por eso recomendados actualizar a la brevedad a Flash versión 15.0.0.239 en sistemas Windows, Mac OS X y Linux… o bien dejar de utilizar Flash Player.

Microsoft lanzará pronto actualizaciones de seguridad para Internet Explorer 10 y 11 y Google hará lo mismo para que Chrome. Para conocer su versión de Flash Player actual, visite esta página.

Cristian de la Redacción de Segu-Info