A diferencia de versiones anteriores de Fakebank, esta nueva variante es capaz de interceptar las llamadas entre el usuario y su entidad bancaria y viceversa. Para ello, el troyano recolecta en primer lugar información personal del usuario y la envía al servidor de C&C. Posteriormente, el C&C responde con varios parámetros de configuración, especificando entre otras cosas el número de teléfono que será usado en el fraude:

• phoneNum_ChangeNum: El número legítimo del banco, que será reemplazado por el número fraudulento cuando el usuario haga la llamada.
• phoneNum_To: El número de los atacantes que simulará ser el banco.
• phoneNum_Come: El número del atacante que llamará a la víctima. Se falsificará el ID de la llamada.
• phoneNum_ShowNum: El número legítimo del banco que se mostrará cuando los atacantes realizan la llamada.

Parámetros de configuración del malware. Fuente: https://www.symantec.com

Cuando el usuario llame a su entidad bancaria el malware interceptará la llamada y la redirigirá a los atacantes. Y al contrario, cuando los atacantes simulen una llamada de la entidad bancaria, suplantarán la identidad de ésta falsificando el ID de la llamada.

De este modo los atacantes tienen un mecanismo bastante efectivo para engañar a sus víctimas.

No solo esto, el malware también ha mejorado su sistema de permisos, ajustándose a las distintas versiones de Android para conseguir pasar más inadvertido:

• Versiones anteriores a Android 6 especificarán el permiso de ‘android.permission.SYSTEM_ALERT_WINDOW‘ en el ‘manifest’ de la aplicación, por lo que se notificará en la instalación.
• En Android 6 y 7 los permisos se conceden de forma silenciosa si se declaran en el ‘manifest’ y la aplicación proviene de Google Play.
• A partir de la versión 8 de Android ya no se permite superponer ventanas desde aplicaciones, por lo tanto el malware no funcionaría.

Como recomendaciones de seguridad se recomienda siempre instalar aplicaciones de repositorios oficiales y poner especial atención a los permisos que se solicitan.

Esta vulnerabilidad afecta a las versiones del kernel 3.0-37.10 y se encuentra en ‘net/core/sock_diag.c‘ donde la función ‘__sock_diag_rcv_msg’ no hace hace una comprobación de `bounds check` del array ‘sock_diag_handles’ provocando una ‘out-of-bounds exception’ y permitiendo a usuarios sin privilegios de root obtenerlo.En los sistemas Linux de 32 bits, cada proceso virtualizará 4GB de espacio de memoria, siendo 3GB de estos el espacio de usuario y 1GB el espacio del kernel. En este caso el rango de user-space es 00000000 a 0xBFFFFFFF y el espacio de kernel 0xC0000000 a 0xFFFFFFFF. El espacio del kernel es compartido por todos los procesos sin embargo, sólo pueden acceder los procesos que se estén ejecutando en kernel-mode. Los procesos a nivel de usuario pueden acceder a kernel-mode a través de `syscalls`. Si un proceso se ejecuta en kernel-mode, las direcciones generadas pertenecen al espacio del kernel.

Las funciones ‘commit_creds’ y ‘prepare_kernel_cred’ son funciones del kernel y para poder ejecutarlas tendríamos que pasar a kernel-mode; por tanto si la función ‘__sock_diag_rcv_msg’ se ejecuta en kernel-mode, podemos aprovecharla para ganar privilegios de root.

Se aplica un mmap al rango de memoria 0x10000-0x120000, incluyendo una serie de NOPs hasta poder colocar correctamente la payload que salta al código que pertenece a kernel-mode. En Ubuntu, no se puede obtener el valor de la variable ‘rehash_time’ de dicho rango de memoria, por lo que sólo es válido el siguiente método para obtenerla:

`sudo cat /boot/System.map-3.5.0-17-generic`
Tras conseguir toda esta información, el usuario puede obtener privilegios de root. Como contra, para poder ejecutar este exploit más de una vez, es necesario reiniciar el sistema operativo.

Más información:

Información

Impacto: ejecución de código
Explotable remotamente: Si
Explotable localmente: No
CVE: CVE-2018-7445

Vulnerabilidad

La vulnerabilidad de encuentra en el procesamiento de inicio de sesión de NetBIOS. Los atacantes pueden ejecutar código en el sistema a través de esta vulnerbailidad. El desbordamiento del buffer se produce antes de que se realice la autenticación por lo que un atacante puede explotar esta vulnerabilidad sin necesidad de estar logueado en el sistema.

La función que se encarga de comprobar los nombres de NetBIOS recibe dos buffers como parámetros. El primer byte del buffer de origen se lee y se usa como el tamaño para la operación de copia. Luego se copia esa cantidad de bytes en el buffer de destino. Esta operación se ejecuta hasta que el tamaño para copiar es 0.

No se realiza ninguna validación para garantizar que los datos se ajusten al buffer destino lo que produce el desbordamiento de la pila. Por lo que se recomienda actualizar el sistema a la versión más actual.

Versiones Vulnerables

Todas las arquitecturas y equipos que ejecuten versiones anteriores a la 6.41.3/6.42rc27 de RouterOS

Créditos

La vulnerabilidad ha sido descubierta por Juan Caillava y Maximiliano Vidal de Core Security Consulting Services

La vulnerabilidad se encuentra presente desde la primera versión de EXIM y afectaría al menos a 400 mil servidores que ejecutan este servidor de correo

Un investigador de Devco.re (Meh Chang) reportó el día 5 de febrero el descubrimiento de esta vulnerabilidad en las listas de correo de seguridad de EXIM, identificándose al día siguiente con el CVE-2018-6789, y lanzándose una versión ya parcheada (4.90.1) el día 10 del mismo mes. Según el mismo sitio web de Exim, todas las versiones anteriores a dicha versión deben considerarse obsoletas.

Exim es uno de los servidores de correo electrónico de código abierto más populares, estando disponible tanto para sistemas tipo UNIX como para Windows. Desarrollado por la Universidad de Cambridge en 1995, es en la actualidad el MTA por defecto de Debian y otras distribuciones GNU/Linux.

Fragmento del código vulnerable. Fuente: devco.re

El fallo descubierto se encontraría en la función ‘b64decode’, utilizada por métodos de autenticación como ‘CRAM-MD5’ (utilizado por defecto). Cualquier método de autenticación que haga uso de dicha función es vulnerable. El fallo sería explotable mediante un base64 inválido especialmente manipulado, el cual provocaría un desbordamiento en el buffer.

La vulnerabilidad se aprovecha del tamaño de buffer que asigna la función, el cual es de ‘3*(len/4)+1’. Normalmente esto no sería un problema, pero si se utiliza un base64 inválido de tamaño ‘4n+3’, la función asignará un tamaño de ‘3n+1’, pero utilizará ‘3n+2’. Esto acaba provocando que el buffer se desborde por un byte. Puede verse más información sobre la explotación de la vulnerabilidad en el artículo escrito por su descubridor.

A día de hoy, no hay una prueba de concepto que explote el fallo, y según puede leerse en la descripción de la vulnerabilidad en la web de EXIM, es difícil que pueda explotarse

Memcached es un sistema distribuido para caché de código abierto utilizado principalmente para mejorar la escalabilidad de las aplicaciones web. Memcached almacena pequeños datos mediante una funcionalidad de clave-valor. Los atacantes hacen uso de la funcionalidad clave-valor para crear un gran flujo con el que llevan a cabo el ataque.

Apenas hace dos meses de la presentación pública de Meltdown y Spectre, aquellas vulnerabilidades que han hecho historia en el mundo de la seguridad informática. Con consecuencias tan graves como poder leer la memoria reservada a otros procesos o incluso al sistema operativo, ocasionaron una gran polémica y consecuencias que durarán años. Tal y como analizamos en su día, ambas vulnerabilidades se deben a fallos de diseño en los procesadores, que con el objetivo de exprimir al máximo el silicio y aumentar el rendimiento, abrieron la puerta a una clase de vulnerabilidades que perdurarán años.

Precisamente, el ataque del que hablamos aprovecha estos fallos de diseño. Es una variación de Spectre (la que permitía leer memoria de los procesos con trozos de código vulnerables) orientada a leer memoria de enclaves SGX. ¿Y qué es un enclave SGX? Resumidamente, es una forma de ejecutar código en procesadores Intel que lo soporten, de forma que ni siquiera el sistema operativo o un hipervisor puedan acceder a la memoria involucrada en la ejecución. El objetivo más llamativo de SGX es ejecutar código sensible en un servidor remoto ejecutando software no confiable.

Superficie expuesta a ataques sin y con SGX. Extraída de software.intel.com.

Esto vendría a intentar solucionar el gran problema de la computación en la nube: El que un tercero procese datos sensibles por ti. Aunque lo cierto es que la implementacion deja un poco que desear. Desde que salió, unascuantas publicaciones han ido contándonos cómo básicamente SGX hace aguas por varios sitios, permitiendo leer del preciado enclave, que se presuponía privado. Por no hablar de que para convertirte en confiable y así poder ejecutar un enclave ajeno (de un cliente), hay que contactar con servidores propios de Intel como piezas imprescindibles del proceso de verificación… Pagando, por supuesto.

La familia de ataques SgxPectre no son una revolución conceptual. Tal y como dicen los autores de la publicación, los conceptos de estos ataques son básicamente los mismos en los que se fundamenta Spectre. De hecho, ni siquiera son una revolución en la aplicación de Spectre a SGX, ya que existen reportes sobre la vulnerabilidad de SGX a ataques derivados de Spectre publicados apenas unos días después de la publicación de éste último, incluyendo una prueba de concepto de un grupo de investigación del Imperial College de Londres. Esta publicación aporta una explicación exhaustiva de los ataques, y presenta un verificador de código para detectar los trozos de código vulnerables que permiten estos ataques.

Los usuarios de a pie apenas se verán afectados por estos ataques, ya que SGX se usa en extensiones del procesador relativamente modernas y sólo en procesadores Intel. Evidentemente un producto orientado al usuario final no se puede restringir a funcionar únicamente en procesadores Intel modernos.Aquellos que programen usando SGX deberán esperar al 16 de marzo, que es cuando Intel prometer publicar el SDK corregido (SDK: kit de desarrollo de software, que estaba produciendo los trozos de código vulnerables). Esto junto con las mitigaciones ya publicadas para Meltdown y Spectre, deberían neutralizar estos ataques.

Más información:

Internet Systems Consortium es una organización dedicada al desarrollo de software y consultoría orientada al soporte de la infraestructura de Internet. Entre otros, es conocida por el desarrollo de BIND, un servidor de nombres de dominio (DNS) y DHCP, una implementación cliente-servidor del protocolo con el mismo nombre. Ambos productos son muy usados en sistemas de todo el mundo y presentan vulnerabilidades que comentamos a continuación, todas ellas permitiendo denegación de servicio. Afortunadamente, a estas alturas no se tiene constancia de que estas vulnerabilidades se estén explotando en la red.

La primera de ellas, con identificador CVE-2018-5732, se produce en el cliente de DHCP, conocido como dhclient. Concretamente, tiene lugar al procesar una respuesta de un servidor DHCP, que si tiene una sección de opciones especialmente diseñada, puede ocasionar un desbordamiento de memoria y el consiguiente cierre inesperado del cliente. No se descarta la posiblidad de ejecutar código arbitrario en algunas circunstancias. Esta vulnerabilidad fue reportada por Felix Wilhelm, del equipo de seguridad de Google, y afecta a las versiones 4.1-ESV-R15-P1, 4.3.6-P1 y 4.4.1.

En segundo lugar, identificada como CVE-2018-5733, tenemos una vulnerabilidad en el servidor de DHCP, llamado dhcpd. Básicamente consiste en que el servidor tiene un contador en memoria almacenado en 32 bits, que tras recibir una gran cantidad de paquetes de un cilente (del orden de miles de millones) puede desbordarse, con la posiblidad de cierre inesperado del servidor. Esta vulnerabilidad también fue reportada por Felix Wilhelm, y afecta a las versiones que afecta CVE-2018-5732.

Por último, la vulnerabilidad con identificador CVE-2018-5734 se produce en el servidor BIND al procesar una petición malformada. Específicamente, BIND al recibir un tipo concreto de paquete malformado selecciona como código de respuesta SERVFAIL, en vez de FORMERROR (que es la respuesta que indica que la petición DNS está malformada). Eso provoca que la aplicación ejecute una parte del código diferente (la parte que maneja las respuestas con SERVFAIL), y si se encuentra habilitada la caché de esta funcionalidad, se termina produciendo un fallo que ocasiona un cierre inesperado. La buena noticia es que este fallo no ha salido en ninguna versión pública del producto, sino en versiones con soporte de pago.

Todas las vulnerabilidades han sido corregidas a la hora de escribir este artículo, y se pueden corregir descargando la última version del software correspondiente en la sección de descargas de la página oficial del ISC:

https://www.isc.org/downloads/

41 0 obj <<
>>
stream
this.docID;
endstream
endobj