FP Lazy State Restore: nueva vulnerabilidad en los procesadores Intel Core

Intel ha publicado una nueva vulnerabilidad que afecta a sus procesadores la cual aprovecha debilidades en la ejecución especulativa, al igual que Meltdown y Spectre.

Extraída de betanews.com

Era de esperar: una vez que los investigadores han puesto el ojo sobre los microprocesadores, era solo cuestión de tiempo que fueran descubriéndosemás vulnerabilidades y con mayor frecuencia. Desde el descubrimiento de Spectre y Meltdown, hemos asistido a un desfile de fallos de seguridad relacionados con la ejecución especulativaHoy tratamos FP Lazy State Restore.

Aunque no se han dado muchos detalles técnicos de la vulnerabilidad, a la que se ha asignado el identificador CVE-2018-3665, se ha publicado que el error está relacionado con la forma de guardar y restaurar los registros de estado de la unidad de coma flotante (Floating Point Unit, FPU, y de ahí el nombre de la vulnerabilidad: ‘Floating Point Lazy State Restore’).

¿Y por qué el “lazy“? La FPU guarda el estado de las operaciones que está realizando. Cuando se da un cambio de contexto en el procesador, este puede indicar a la FPU que este estado sea guardado automáticamente o de forma “vaga”. En este último caso, el estado no se guarda hasta que el nuevo proceso ejecute una operación de punto flotante que requiera salvar datos en los registros de la unidad. Es decir, en esta modalidad la FPU no realiza salvado ni recuperación de estados a no ser que realmente se necesite, ahorrando varios ciclos de computación.

Al igual que las dos vulnerabilidades antes mencionadas, el error está efectivamente relacionado con la ejecución especulativa, pero en este caso es el software el que puede elegir entre el guardado inmediato o “vago” de contexto, por lo que los fabricantes de sistemas operativos podrán corregir esta vulnerabilidad a través de una actualización de software.

Aunque no existen muchos detalles más allá de estos, parece ser similar a la variante 3A de Spectre (Rogue System Register Read). Este error podría permitir la obtención de información sensible almacenada por distintas aplicaciones, incluyendo claves de cifrado, lo que la convierte en una vulnerabilidad con un fuerte impacto.

Actualmente la vulnerabilidad no afecta a los procesadores AMD, tampoco a las últimas versiones de OpenBSD, DragonflyBSD, Linux con kernel 4.9 o las versiones de Windows más modernas, aunque Microsoft no ha dado muchos detalles al respecto más allá de confirmar un parche en julio.

También se sabe que Intel está trabajando con el equipo de Red Hat para dar solución a este problema con la máxima celeridad.

New ‘Lazy FP State Restore’ Vulnerability Found in All Modern Intel CPUs:

https://thehackernews.com/2018/06/intel-processor-vulnerability.html

 

RedHat. Lazy FPU Save/Restore

MysteryBot, el nuevo troyano “todo en uno” para Android

Por si fuera poco el nivel de malware existente en los dispositivos Android en estos tiempos, ahora se le suma la propia evolución de LokiBot, que supone una nueva familia de malware denominada como MysteryBot.

El malware ha sido detectado por investigadores de ThreatFabric durante uno de sus análisis rutinarios de la familia Lokibot, de la cual hereda ciertos comportamientos. Concretamente, ha sido detectado gracias a que MysteryBot tiene el mismo servidor de control que Lokibot.

Podemos corroborar esta información utilizando la plataforma Koodous, en la cual en este momento ya existen muestras clasificadas como MysteryBot:

Las novedades que trae este malware es la combinación de varias vías de ataque que pasamos a desgranar a continuación:

Registro de pulsaciones: El malware guarda las pulsaciones que realiza el usuario en la pantalla, aunque además tiene algunas novedades: también detecta si el teléfono está en horizontal o vertical, datos que utiliza para calcular qué se ha pulsado en el teléfono teniendo en cuenta las dimensiones del dispositivo. Tiene módulos de las familias CryEye yAnubis y, según el código analizado por ThreatFabric, parece estar aún en desarrollo.

RansomwareEste comportamiento resulta ya familiar en el malware móvil, y trata en cifrar el dispositivo para posteriormente pedir un rescate monetario a cambio de su descifrado. En este caso la muestra no cifra datos, sino que los comprime en un archivo zip con contraseña, la cual actualmente no tiene mucha robustez (solo 8 caracteres).

Ataques de superposición: La característica más novedosa de este malware, no tanto por lo que hace si no por su ejecución. Este comportamiento permitía qué, cuando un usuario abre una aplicación legítima, el malware aprovechará para mostrar una interfaz superpuesta, engañando al usuario de forma poco sospechosa. Sin embargo, tras la introducción de Android 7 y 8 ya no era posible realizar ataques de superposición, lo que ha llevado a los creadores de malware a buscar nuevas técnicas. Esta familia abusa del permiso ‘PACKAGE_USAGE_STATS’, que junto con el uso de la claseAccessibilityService y un cálculo correcto de tiempos le permite realizar ataques de superposición con éxito.

Sin duda el malware es novedoso y aprovecha las últimas técnicas de ataque en Android. Actualmente se desconoce si los atacantes tienen alguna campaña de promoción, pero lo que sí podemos observar en la captura facilitada anteriormente es que la intención eshacerse pasar por la aplicación Adobe Flash Player.

Desde Hispasec recomendamos siempre instalar en Android aplicaciones desde repositorios oficiales, pero además que se realicen unas comprobaciones mínimas como verificar al desarrollador de la aplicación o que sea enlazada desde la página oficial de la compañía.

Más información:

MysteryBot; a new Android banking Trojan ready for Android 7 and 8:

Detectados contenedores maliciosos distribuidos a través de Docker Hub para cryptojacking

544.74 Monero, lo que al cambio son unos 67.863€ a la hora de escribir este artículo. Es la cantidad que el atacante detrás de la cuenta de Docker Hub “docker123321” ha sido capaz de minar a lo largo de un año a través de imágenes maliciosas distribuidas a sistemas expuestos y, lo que es peor, usando la propia plataforma de Docker.

 

Durante el último año, investigadores de varias empresas (Kromtech, Fortinet y Sysdig) han estado siguiendo de cerca este caso, hasta que finalmente el pasado 10 de mayo Docker Hub cerró la cuenta maliciosa. Detrás deja un total de 17 imágenes Docker maliciosas que habían sido descargadas en más de 5 millones de ocasiones.
Linea de tiempo del ataque. Obtenida de Kromtech Security Center.


¿Cómo funciona Docker Hub?

Para explicar qué es Docker Hub, primero tenemos que ver algunos conceptos básicos de Docker. Sabemos que se basa en la ejecución de contenedores que aíslan, o al menos lo intentan, un proceso particular del sistema operativo base (ojo, no se trata de virtualización). La especificación de estos contenedores corre a cargo de las llamadas imágenes, que son plantillas donde se define qué hace exactamente un contenedor. En definitiva, un contenedor es una instancia en ejecución de una imagen.

Aunque se puede construir una imagen desde cero, lo ideal es basarse en otra ya definida  y personalizarla. Por ejemplo, se puede crear una imagen que ejecute Apache 2 basándose en una imagen del sistema operativo Debian, instalando paquetes y configuraciones, ya sea a mano o a través de un Dockerfile. Este fichero contiene un conjunto de directivas que va a definir exactamente como queremos que se comporte el contenedor que genera esa imagen. Se pueden definir, entre otras, la imagen en la que se basa, los puertos que queremos que el contenedor abra, los paquetes que va a tener instalados o el comando que va a ejecutar.

Una vez configurada y construida la nueva imagen, se pueden distribuir utilizando repositorios. Docker Hub es el repositorio oficial y, de hecho, está totalmente integrado en el motor Docker. Hagamos una prueba y ejecutemos ‘sudo docker run -ti hello-world’:

La ejecución de este contenedor nos dice exactamente que ocurre entre bambalinas: en resumen, se busca la imagen local del contenedor que queremos ejecutar. De no existir, se busca automáticamente en Docker Hub, se descarga y se ejecuta.

¿Y quién puede publicar imágenes en Docker Hub? Cualquiera
, siempre que tengamos una cuenta cuya creación es gratuita. De hecho, es el principal distribuidor de imágenes para Docker.

Medidas de seguridad en Docker Hub

Existen con ciertos “peros”. Por un lado, desde Docker 1.8 se implementa el firmado de imágenes, que nos permite asegurar que la imagen que estamos descargando es precisamente la que queremos. Sin embargo, esta medida debe configurarse en el cliente y no está activada por defecto.

En segundo lugar, hasta hace poco se realizaban análisis automatizados de seguridad para las imágenes subidas a Docker Hub, aunque solo estuvo disponible para los contenedores propios. Desde hace unos meses la funcionalidad no está disponible. En la descarga, ahora mismo, no hay ningún sistema ni señal que te indique si la imagen que descargas puede tener un comportamiento malicioso o no.

Pero los usuarios de Docker no ejecutan una imagen desde Docker Hub así como así…

No deberían. Al final, es como ejecutar un proceso desconocido en nuestro equipo y, lo que es peor, con permisos de superusuario y acceso a nuestro sistema base. Por ejemplo, una de las imágenes maliciosas que se han encontrado montaba como volumen el directorio ‘/etc’ del sistema base y añadía entradas en el fichero crontab para ganar persistencia. Pero por supuesto, un usuario sin experiencia podría encontrar una imagen que se promete interesante y ejecutarla sin una revisión de lo que hace en realidad.

Más allá de las posibles estrategias de ingeniería social, lo que sí señalan los investigadores mencionados es que existen gran cantidad de sistemas Docker y Kubernetes (una plataforma de orquestación para Docker) que presentan fallos de configuración y están totalmente expuestos, permitiendo que reciban comandos de administración externos.

En resumen, ¿qué ha ocurrido?

Un señor con no muy buenas intenciones ha creado un repositorio en Docker Hub y ha ido publicando varias tandas de imágenes maliciosas, algunas para minar criptomonedas, a lo largo de un año.

Aunque la distribución en este caso concreto no está clara, los investigadores manejan datos de otros ataques en los que se buscaban sistemas Docker y Kubernetes expuestos a Internet (a través de escaneos automatizados y/o mediante plataformas como Shodan) y con una configuración de autenticación pobre. Una vez localizados, se les lanzaba automáticamente comandos de gestión que permitieran la descarga desde Docker Hub de las imágenes maliciosas en el sistema.

Detalle de uno de los scripts utilizados para desplegar los contenedores maliciosos. Obtenida de Kromtech Security Center.

Los contenedores se hacían pasar por sistemas como Tomcat o MySQL para pasar desapercibidos. Además de aquellos que minan Monero, otros contenedores publicados buscaban tomar el control de la máquina base a través de la apertura de shells inversas o añadiendo las claves de acceso SSH del atacante a las permitidas para el usuario root.

Con este esquema, el usuario “docker123321” ha conseguido más de 5 millones de descargas de sus contenedores, minando un total de 544.74 Monero a lo largo de un año. Después de varias notificaciones de particulares y empresas de seguridad, el usuario ha sido finalmente eliminado.

Más información:

Cryptojacking invades cloud. How modern containerization trend is exploited by attackers:

MirageFox, otra APT de procedencia china

La reutilización de código entre distintas familias  de malware, ha permitido identificar un nueva variante compuesta por código de Mirage y Reaver, APT’s viejas conocidas y asociadas a la organización APT15, presuntamente vinculada al gobierno chino.
Configuración de MirageFox, que hace referencia a Mirage. Extraída de intezer.com.
Reutilizar código es lo más natural del mundo. De hecho, es lo que debes hacer si quieres escribir buen código, ya que escribir código reutilizable no tiene como única ventaja que sea reutilizable. Al tener la reutilización como meta final, debes esforzarte en que el código sea modular y legible, por lo que básicamente tienes que escribir código reutilizable aunque no tengas pensado utilizarlo de nuevo en otro sitio. Para empezar, porque te puedes equivocar y quizá termines reusándolo, y por supuesto por las ventajas adicionales ya comentadas que acarrean esta buena práctica.
No es de extrañar que sea una práctica extendida entre los programadores demalware. Al fin y al cabo, la creciente complejidad del malware ha hecho que el esfuerzo estimado para producir un único malware se incremente, aproximadamente, en un orden de magnitud cada década. Por tanto, la creación de código reutilizable es imperativa a estas alturas. El término malware no significa otra cosa que “software malicioso”, que únicamente hace referencia a la intención del software. No nos pueden sorprender por tanto cosas como que el malware comparte con el goodware (software benigno) un nivel de calidad del código similar, o el tamaño de los equipos dedicados a la programación de éstos.
Y reutilizar código es lo que parece que ha hecho APT15, un grupo conocido por sus acciones de espionaje informático contra compañías y organizaciones de distintos países, atacando a diversos sectores como la industria del petróleo, contratistas de gobiernos, los militares… Una empresa israelí llamada Intezer, que basa su modelo de negocio en la identificación de reutilización de código en malware, ha sido la que ha reconocido esta evolución de Mirage que ha bautizado como MirageFox.
En resumen, las características técnicas de esta nueva versión no son algo a destacar. Es una herramienta de administración remota (RAT) que recopila información del equipo infectado y espera órdenes de un servidor central (C&C). Lo que llama la atención de esta versión es que las muestras encontradas hacen referencia a un servidor central en la misma red local del equipo infectado. Basándose en el modus operandi deAPT15 en un ataque anterior, los investigadores de Intezer han concluido que probablemente esta muestra fue configurada especialmente para ejecutarse en una red ya comprometida, concretamente una VPN (red virtual privada) cuya clave privada fue robada previamente por APT15.
Probablemente lo más interesante de esta noticia es que pone el foco de atención sobre métodos alternativos de detección de malware, por contraposición a las clásicas firmas que identifican muestras de familias concretas. Detectar nuevas muestras que han reutilizado código de malware anterior precisamente por detectar la reutilización de código parece una aproximación bastante buena, debido a la tendencia a reutilizar código por parte de los programadores de malware.

 
MirageFox: APT15 Resurfaces With New Tools Based On Old Ones
https://www.intezer.com/miragefox-apt15-resurfaces-with-new-tools-based-on-old-ones/

A Look into 30 Years of Malware Development from a Software Metrics Perspective
https://cosec.inf.uc3m.es/~juan-tapiador/papers/2016raid.pdf

Esto es código firmado por Apple… ¿o no?

Múltiples programas de terceros para macOS no hacen un uso correcto de la funcionalidad proporcionada por el sistema operativo para comprobar código firmado, y permite a atacantes hacer pasar cualquier código por código de Apple.

Pasa todos los días. El sistema operativo te permite usar cierta funcionalidad a través de una API (interfaz de programación de aplicaciones) para realizar una tarea… Pero la usas mal y la acabas liando. Lo cierto es que a veces no ayuda la documentación, ya que algunas escriben lo justo para que entiendas el ejemplo que viene incluido. Hay días que incluso te ves echando un vistazo rápido al código fuente de la librería (si es que es de código abierto), a ver cómo cierta función maneja un argumento en particular. Y es quealgo que parece tan sencillo como decir si un ejecutable está firmado por Apple o no se puede complicar…

Y en este caso se ha complicado. Múltiples programas de terceros, realizados por empresas con nombres tan sonados como FacebookGoogle o F-Secureno hacen un uso correcto de la API que proporciona macOS para comprobar código firmado. Básicamente permite que un atacante introduzca código no firmado en un ejecutable firmado, sin que suenen las alarmas y haciendo que se ejecute el código no firmado en lugar del firmado. ¿Cómo es posible esto?

En primer lugar, tenemos que tener en cuenta que macOS todavía permite ejecutar código no firmado (tiempo al tiempo), con lo que como mucho, lo que nos llevamos a día de hoy es una advertencia (y eso si lo ejecutas desde la interfaz gráfica y no desde consola). Por tanto, la ejecución puede darse igualmente. El problema viene cuando herramientas de seguridad (software antivirus, herramientas forenses…) utilizan la firma de los ejecutables para marcarlos como confiables y no procesarlos… Que si no realizas esta verificación exhaustivamente, se te puede colar uno que al ejecutarse, termine corriendo código no firmado.

Concretamente, para que esto pase debe crearse un ejecutable con ciertas características que no detallamos por no pasarnos de técnicos. Aunque sí detallamos las más importantes, siendo la que más que debe ser un ejecutable Fat (también llamado Universal), que es un contenedor de múltiples ejecutables. Este formato se pensó originalmente para contener el mismo código pero compilado para distintas arquitecturas (PowerPCi386, y x86_64).

Ejecutable Fat en el que se aprecian dos ejecutables de distintas arquitecturas. Extraído de okta.com.

Sabiendo esto, ya podemos empezar a entender cómo se construye este ejecutable malicioso. Lo primero es empaquetar en un ejecutable Fat un ejecutable original firmado por Apple junto con el ejecutable malicioso que pretendemos terminar ejecutando. Este último debe tener ciertas características por sí mismo y compartir alguna que otra con el ejecutable de Apple, pero no las detallamos por ser triviales de cumplir.

El problema está en que un ejecutable así construido pasa la verificación más sencilla proporcionada por la API del sistema operativo y usada por programas de terceros. Esto se debe a que exceptuando el primer ejecutable contenido, no se verifica la entidad certificadora raíz de los ejecutables. Esto permite que el segundo ejecutable sea autofirmado (cosa que se puede hacer sin problema), y el ejecutable Fat se siga considerando firmado por Apple en su totalidad.

Por último, y para que la parte responsable del sistema operativo de cargar los ejecutables en memoria no cargue el primer ejecutable (que es lo natural siempre y cuando la arquitectura sea compatible), se usa un pequeño truco: malformar a propósito la cabecera del primer ejecutable que indica la arquitectura, para que el cargador del sistema operativo vea un valor no válido y salte a ejecutar el segundo ejecutable malicioso.

Todas las empresas detrás de las herramientas afectadas conocidas lo han reconocido y corregido, y se ha asignado un CVE por cada herramienta.


Más información:

 
Creating Fat (Universal) Binaries on MacOS
https://community.perforce.com/s/article/1226

Cuidado con Cortana… ¡Podría llegar a desbloquear tu ordenador!

Este asistente IA podría ayudar a los atacantes a desbloquear la contraseña de un sistema objetivo.

Resultado de imagen de cortana hacked

Este martes, Microsoft ha lanzado una actualización para corregir una vulnerabilidad que permitía a un usuario malintencionado entrar en un sistema Windows 10 bloqueado y ejecutar comandos maliciosos con privilegios de usuario.

Esta vulnerabilidad de elevación de privilegios, conocida como CVE-2010-8140, existe debido a una mala verificación de entradas de comandos de Cortana.

Cedric Cochin, del equipo de investigación de amenazas avanzadas de McAfee, ha publicado los detalles técnicos del fallo y una prueba de concepto en la que muestra como secuestró un ordenador con Windows 10 bloqueado llevando a cabo un restablecimiento de contraseña usando a Cortana.

Vídeo demostrativo del fallo:

Se recomienda a todos los usuarios desactivar Cortana en la pantalla de bloqueo y aplicar el parche que lanzó Microsoft el pasado martes para corregir el fallo.

Más información:
 
Detalles técnicos del fallo:

Error “El controlador de pantalla dejó de responder y se recuperó” en Windows 7 o Windows Vista

Resultado de imagen para El controlador de pantalla dejó de responder y se recuperó

Solución


Para resolver este problema, siga los pasos de los métodos empezando con el método 1 y continuando con los métodos 2 y 3 si las soluciones no resuelven el problema.

Método 1: actualizar al controlador de pantalla más reciente

Para actualizar al controlador de pantalla más reciente de hardware de gráficos mediante Windows Update, haga clic en el vínculo específico a su versión de Windows y siga los pasos que se indican en ese artículo:

Actualizar un controlador de hardware que no funciona correctamente en Windows 7

Actualizar un controlador de hardware que no funciona correctamente en Windows Vista

Si la instalación de las actualizaciones más recientes no resuelve el problema, continúe con el método 2.

Método 2: ajustar los efectos visuales para un mejor rendimiento

Si tiene varios programas, ventanas de explorador o mensajes de correo electrónico abiertos al mismo tiempo, se puede agotar la memoria y provocar problemas de rendimiento. Pruebe a cerrar todos los programas y ventanas que no se usen.

También puede ajustar su PC para obtener un rendimiento más óptimo si deshabilita algunos de los efectos visuales. A continuación se indica cómo ajustar todos los efectos visuales para mejorar el rendimiento:

  1. Seleccione  Inicio > Panel de control para abrir Información y herramientas de rendimiento. En el cuadro e búsqueda, escriba Información y herramientas de rendimiento y luego, en la lista de resultados, haga clic en Información y herramientas de rendimiento.
  2. Seleccione  Ajustar efectos visuales. Si se le pide una contraseña de administrador o que confirme la acción, escriba la contraseña o proporcione confirmación.
  3. Seleccione Efectos visuales  > Ajustar para obtener el mejor rendimiento > Aceptar.
    Nota Si desea una opción menos drástica, seleccione Dejar que Windows elija la configuración más adecuada para el equipo.
Si este método no resuelve el problema, continúe con el método 3.

Método 3: modificar la entrada del Registro para aumentar el tiempo de procesamiento de la GPU

La función de detección de tiempo de espera y recuperación es una característica de Windows que puede detectar el momento en el que el hardware del adaptador de vídeo o un controlador de su PC ha tardado más tiempo del esperado en completar una operación. Cuando esto sucede, Windows intenta recuperar y restablecer el hardware de gráficos. Si la GPU es incapaz de recuperar y restablecer el hardware de gráficos en el tiempo permitido (dos segundos), el sistema podría dejar de responder y mostrar el mensaje de error “El controlador dejó de responder y se ha recuperado”.
Resultado de imagen para El controlador de pantalla dejó de responder y se recuperó
Este problema se puede resolver dando a la característica de detección del tiempo de espera y recuperación más tiempo para completar esta operación, para lo cual es necesario ajustar el valor del Registro.

Para ello, siga estos pasos:

  1. Cierre todos los programas basados en Windows.
  2. Seleccione  Inicio, escriba regedit en el cuadro Buscar y luego haga doble clic en regedit.exe en la lista de resultados. Si se le pide una contraseña o confirmación de administrador, escriba la contraseña o proporcione la confirmación.
  3. Busque la subclave del Registro siguiente:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers
  4. En el menú Edición, seleccione Nuevo y luego seleccione el siguiente valor del Registro del menú desplegable específico de su versión de Windows (32 o 64 bits):
    Para Windows de 64 bits

    1. Seleccione el valor QWORD (64 bits).
    2. Escriba TdrDelay como Nombre y presione Entrar.
    3. Haga doble clic en TdrDelay y agregue 8 para Información del valor y haga clic en Aceptar.
  5. Cierre el editor del Registro y reinicie el equipo para que los cambios surtan efecto.

Importante En esta sección, método o tarea se incluyen pasos para modificar el Registro. Sin embargo, se pueden producir problemas graves si modifica el Registro incorrectamente. Por tanto, asegúrese de que sigue estos pasos cuidadosamente. Para mayor protección, realice una copia de seguridad del Registro antes de modificarlo. De esta manera podrá restaurar el Registro en caso de que se produzca un problema. Para obtener más información sobre cómo realizar una copia de seguridad del Registro en Windows 7, consulte Realizar una copia de seguridad del Registro.

Más información


Este comportamiento puede ocurrir por uno o varios de los siguientes motivos:

  • Es posible que tenga que instalar las actualizaciones más recientes del controlador de vídeo
  • Efectos visuales o la ejecución en segundo plano de demasiados programas pueden estar ralentizando su PC
  • La GPU tarda más tiempo del permitido en mostrar gráficos para el monitor

Nota Si utiliza una tarjeta de vídeo antigua, puede que no haya un controlador de vídeo que sea totalmente compatible con su versión de Windows.

Para obtener más información sobre la característica de detección del tiempo de espera y recuperación, consulte Detección del tiempo de espera y recuperación de GPU mediante WDDM.

Inyección SQL en RSA Web Threat Detection

Se ha hecho pública una vulnerabilidad de inyección SQL en RSA Web Threat Detection que podría comprometer el sistema afectado.



RSA Web Threat Detection es un software que analiza en tiempo real la actividad y tráfico de aplicaciones web para detectar anomalías, amenazas, fraudes, abusos y otras actividades maliciosas basándose en las diferencias de comportamientos y patrones de uso de un usuario legítimo y un atacante.

RSA Web Threat Detection es utilizado, entre otras, por empresas de comercio electrónico y entidades bancarias para obtener seguridad y protección contra el delito cibernético.

Se ha detectado una incorrecta validación de las entradas proporcionadas por el usuario en las aplicaciones ‘Administration’ y ‘Forensics’, que permitiría realizar inyecciones SQL. Esta vulnerabilidad ha sido identificada como CVE-2018-1252 y gravedad alta.

Un usuario con bajos privilegios podría explotar este fallo de seguridad para ejecutar comandos SQL en la base de datos subyacente y comprometer la confidencialidad, integridad y disponibilidad del sistema afectado, logrando acceso no autorizado a, por ejemplo, la información de usuario y la supervisión de la herramienta.

Se encuentran afectadas por esta vulnerabilidad las versiones 6.3 y anterioresLa versión 6.4 de RSA Web Threat Detection se encuentra disponible y se recomienda a los clientes de este software actualizar tan pronto como sea posible.

Más información:
 
DSA-2018-085: RSA Web Threat Detection SQL Injection Vulnerability:

Fallo de seguridad en OnePlus 6 permite iniciar cualquier imagen

Fallo de seguridad en OnePlus 6 permite iniciar cualquier imagen

Es posible iniciar imágenes incluso con el gestor de arranque bloqueado

Resultado de imagen de one plus 6

Se ha descubierto una vulnerabilidad grave en el gestor de arranque del OnePlus 6 que hace posible que alguien arranque imágenes arbitrarias o modificadas para tomar el control total de su teléfono, incluso si tenemos el gestor bloqueado.

El gestor de arranque es parte del firmware incorporado del teléfono y al bloquearlo impide que los usuarios reemplacen o modifiquen el sistema operativo del teléfono con ROM de terceros no certificadas, lo que garantiza que el sistema arranque en el sistema operativo correcto.

Este fallo ha sido descubierto por el investigador de seguridad Jason Donenfeld de Edge Security:

El gestor de arranque en OnePlus 6 no está completamente bloqueado, lo que permite a cualquier persona flashear cualquier imagen de arranque modificada en el teléfono y tomar el control total del mismo.

Además, el propio investigador demostró en vídeo como es posible que un atacante físico pueda iniciar cualquier imagen maliciosa en OnePlus 6.

 

La marca OnePlus ha reconocido el problema y ha prometido lanzar una actualización de software en breve. Hasta entonces, si tienes este modelo, te recomendamos que no lo pierdas de vista.

https://www.xda-developers.com/oneplus-6-bootloader-protection-exploit-physical-access/

InvisiMole: el malware espía que convierte tu ordenador en un sistema de vigilancia

InvisiMole es un spyware utilizado en ataques dirigidos que convierte el dispositivo infectado en una cámara de video vigilancia, permitiendo al operador del malware ver y oir las actividades de la víctima.

 

Un dato curioso es que este malware lleva activo casi 5 años hasta que fue detectado por primera vez por los investigadores de ESET.

Como comentábamos antes los ataques son muy específicos y no hay un gran número de dispositivos afectados.

El malware se compone de dos módulos con múltiples funcionalidades que permiten extraer toda la información posible de las víctimas. Estos módulos se encuentran empaquetados en una DLL que le permite obtener la persistencia “secuestrando” una DLL legítima (DLL Hijacking). Estos dos módulos son cargados al inicio por alguno de los procesos ‘rundll32.exe‘, ‘explorer.exe‘ o ‘svchost.exe‘. Una vez cargados, los procesos continúan su ejecución de forma normal para evitar levantar sospechas.

Los dos módulos ejecutados por el malware: ‘RC2FM‘ y ‘RC2CL‘ cumplen diferentes propósitos:


RC2FM

Introduce una puerta trasera que implementa hasta 15 comandos para realizar tareas de espionaje o hacer cambios en el sistema. Este módulo se comunica con el servidor de C&C que se encontraba hardcodeado en las muestras analizadas por el equipo de ESET.

Comunicación con el C&C. Fuente: www.welivesecurity.com

Listado de los comandos implementados (ID, descripción)

  • 0   Muestra información sobre los discos, ficheros y directorios y carpetas compartidas.
  • 2   Operaciones de creación, modificación y borrado de ficheros y directorios.
  • 4   Abre un fichero y posiciona el puntero de fichero al inicio.
  • 5   Cierra un fichero abierto anteriormente.
  • 6   Escribe un fichero abierto anteriormente.
  • 7   Cambia la fecha del fichero.
  • 8   Posiciona el puntero de fichero al final.
  • 10  Modifica la fecha del fichero/Elimina el fichero
  • 12  Busca ficheros especificando una máscara de búsqueda.
  • 13  Toma una captura de pantalla.
  • 14  Sube o modifica algún fichero con datos internos.
  • 15  Graba el sonido de los dispositivos de audio disponibles.
  • 16  Comprueba si hay algún fichero abierto.
  • 17  Actualiza la lista de servidores de C&C
  • 19  Crea, modifica o elimina el registro.

RC2CL

Este módulo también introduce otra puerta trasera que permite al operador del malware recopilar toda la información posible sobre la víctima, desde información sobre el sistema hasta listados de procesos activos, servicios en ejecución, drivers disponibles, información sobre la red, etc. No sólo eso, el malware permite deshabilitar el control de acceso a usuarios (UAC) para poder manipular ficheros protegidos sin tener permisos de administrador. Tomar capturas de la webcam o grabaciones desde el micrófono.

Para evitar ser detectado, el malware cifra todos sus strings, ficheros internos, configuraciones y comunicaciones.

Algunos IOCs:
SHA1- 5EE6E0410052029EAFA10D1669AE3AA04B508BF9
SHA1- 2FCC87AB226F4A1CC713B13A12421468C82CD586
SHA1- B6BA65A48FFEB800C29822265190B8EAEA3935B1
SHA1- C8C4B6BCB4B583BA69663EC3AED8E1E01F310F9F
SHA1- A5A20BC333F22FD89C34A532680173CBCD287FF8
Más información:
 
InvisiMole: surprisingly equipped spyware, undercover since 2013
https://www.welivesecurity.com/2018/06/07/invisimole-equipped-spyware-undercover/InvisiMole — Indicators of Compromise
https://github.com/eset/malware-ioc/tree/master/invisimole