Explotación del mecanismo de subaplicación de SteelSeries para la escalada de privilegios
Resumen ejecutivo
Tomer Peled, investigador de seguridad de Akamai, descubrió recientemente dos vulnerabilidades en la aplicación SteelSeries.
SteelSeries es una empresa de hardware que fabrica periféricos informáticos y que cuenta con más de 9 millones de clientes en todo el mundo.
A las vulnerabilidades se les asignaron los números de CVE CVE-2023-31461 y CVE-2023-31462. SteelSeries actuó rápidamente para aplicar parches a fin de corregir estas vulnerabilidades en mayo de 2023.
Estas vulnerabilidades permiten a un atacante ejecutar código con mayores privilegios que los obtenidos inicialmente y, posiblemente, con privilegios de ADMIN. Para explotar estas vulnerabilidades, el atacante debe enviar dos paquetes locales a un servidor IPC de escucha. A continuación, el servidor ejecutará la carga útil del atacante con privilegios elevados.
La causa raíz de estas vulnerabilidades reside en una gestión de permisos insegura en el listener IPC del servicio y en la falta de protección frente al cruce de rutas.
El grupo de inteligencia sobre seguridad (SIG) de Akamai reveló de forma responsable las vulnerabilidades a los equipos de asistencia e ingeniería de SteelSeries y las envió a MITRE para la asignación de los CVE.
El SIG detectó el servicio vulnerable en varios centros de datos que supervisamos e informó a los clientes del riesgo y sobre cómo mitigarlo.
- Proporcionamos un ataque de prueba de concepto (PoC) y un osquery para detectar máquinas con el servicio vulnerable.
Introducción
SteelSeries es una empresa de hardware especializada en dispositivos periféricos informáticos, como teclados, ratones, auriculares, etc. Para personalizar estos dispositivos, SteelSeries ofrece a sus usuarios una aplicación, SteelSeries GG, que puede descargarse de su sitio web.
Esta aplicación, compuesta por el módulo principal SteelSeries GG y varias subaplicaciones, es un mecanismo que SteelSeries utiliza para mejorar la experiencia del usuario.
En nuestra investigación, hemos detectado dos formas de registrar nuestra propia subaplicación y de especificar qué código ejecutar a través de ella, lo que posiblemente conduce a la ejecución de código con permisos más elevados. En esta entrada del blog, proporcionamos los detalles técnicos de las vulnerabilidades, así como una PoC de explotación.
Datos técnicos
SteelSeries GG se ejecuta de forma predeterminada en un nivel de integridad medio y normalmente en el contexto de administrador. Por lo tanto, puede ejecutarse en un contexto de alta integridad en determinadas circunstancias. Este detalle, combinado con el hecho de que SteelSeries GG es un proceso de escucha (Figura 1), lo convierte en un buen objetivo para la investigación de vulnerabilidades.
Fig. 1: Process Hacker y netstat muestran la aplicación de escucha SteelSeries GG
El mecanismo de subaplicación y la API de comunicación entre procesos
El mecanismo de subaplicaciones se utiliza para administrar las funciones opcionales de SteelSeries y mejorar la experiencia del usuario. Un ejemplo de tal subaplicación es Sonar, "un conjunto avanzado de herramientas de software de audio para juegos que dota a cualquier usuario de la capacidad de ajustar el sonido del juego, el chat en equipo y el micrófono por separado", tal como lo define SteelSeries. Las subaplicaciones se ejecutan en segundo plano y se comunican con el módulo principal de la aplicación a través de una API de comunicación entre procesos (IPC).
La API de IPC de SteelSeries GG expone varios tipos de operaciones que un usuario puede solicitar, incluyendo cambios de en la configuración, acciones administrativas, ediciones de perfil de usuario, etc. Lo más interesante es los siguiente: La API expone una interfaz para gestionar subaplicaciones, desde la creación y eliminación hasta la activación y la desactivación.
La funcionalidad de enrutamiento de API (es decir, cómo gestionar cada solicitud de API) se implementa mediante la biblioteca de código gorilla/mux . Sabiendo esto, podemos explorar más fácilmente la superficie de ataque. La función de enrutamiento en sí es muy amplia, pero básicamente es una simple recopilación de sentencias if para cada una de las opciones de API disponibles (Figura 2).
Fig. 2: Implementación del enrutamiento HTTP en SteelSeries GG
Estas llamadas de API están disponibles para cualquiera que inicie una conexión con el servidor de escucha ("SteelSeriesGG.exe") y no requiera autenticación.
Decidí centrarme en los controladores de eventos de subaplicación, ya que tenían el mayor potencial de impacto. Después de reorganizar el código desensamblado en IDA, descubrimos que los controladores de enrutamiento para subaplicaciones tienen el prototipo que se muestra en la figura 3.
Fig. 3: Prototipo de función de controlador en el código gorilla/mux
Explotación del mecanismo de subaplicación
Una de las llamadas de API que podemos realizar es crear una nueva subaplicación. Este proceso se realiza enviando una solicitud POST a la ruta /subApps con una carga útil JSON que contiene varios parámetros, cuatro de los cuales son de interés para nosotros: "name", "executableName" , "isEnabled" y "shouldAutoStart".
Mediante estos campos, podemos crear una nueva subaplicación prácticamente como usuario sin privilegios, dirigirla a un ejecutable en una ubicación sin privilegios y, posiblemente, programarla con cada inicio de aplicación.
SteelSeries GG crea la ruta de acceso completa al archivo ejecutable de la subaplicación de la siguiente manera:
<StellSeriesGG install location>\Apps\<name>\<executableName>.exe
Como los campos "name" y "executableName" se concatenan de esta manera, pensamos que podríamos intentar un ataque de cruce de rutas. Como parece, SteelSeries GG no es resistente a los cruces de rutas, y se aceptó la anteposición de “../../../../” a la ruta, como se muestra en la Figura 4.
Fig. 4: Se acepta el cruce de rutas al crear una nueva subaplicación
Cuando se crea una subaplicación, su información se almacena en la base de datos de SteelSeries GG. ¿Existe otra manera de controlar las subaplicaciones a través de esta base de datos? Así es, ya que la base de datos se encuentra en una ubicación no segura. Esto significa que incluso sin acceso a la API de subaplicación, podemos agregar una subaplicación directamente a la base de datos. Sin embargo, los atacantes tendrán que encontrar una vulnerabilidad para aprovechar este defecto de diseño, que de por sí no es explotable y, por lo tanto, no supone un riesgo inmediato.
Puede que piense que crear una subaplicación en una ubicación controlada significa que hemos conseguido una escalada de privilegios (después de ejecutar un binario de esa ruta), pero al intentarlo, hemos descubierto que hay otra restricción: la validación de certificados. SteelSeries se asegura debidamente de que los archivos ejecutables de subaplicación están firmados y aprobados. Para ejecutar nuestra propia carga útil, tendremos que omitir el proceso de verificación.
La función de verificación llama a la función WinVerifyTrust y, a continuación, llama a una cadena de funciones de WinAPI para comparar determinados campos del certificado con cadenas codificadas de la aplicación.
Esta validación es un poco difícil de omitir, pero se puede conseguir de dos maneras:
Secuestro de DLL
TOCTOU (del tiempo de comprobación al tiempo de uso)
Vector de secuestro de DLL
Con la técnica de secuestro de DLL, podemos basarnos en el hecho de que SteelSeries confía en varios binarios existentes; uno de ellos es SteelSeriesEngine.exe, que carga la biblioteca SSEDEVICE.dll. Compilaremos nuestra propia biblioteca con el mismo nombre para que se cargue nuestra biblioteca en lugar de la DLL SSEDEVICE original. Las funciones exportadas de nuestra propia DLL llamarán a las funciones genuinas de la DLL.
Sin embargo, la función llamada al cargar nuestra DLL implementará nuestra lógica maliciosa (Figura 5). La técnica se explica más detalladamente en la publicación de blogDLL proxying de itm4n’s.
Fig. 5: Secuestro de DLL de SSEDEVICE
La animación de la Figura 6 muestra el proceso de envío del paquete inicial para ejecutar la carga útil del atacante (en nuestro caso, abrir una instancia cmd) con privilegios elevados.
Fig. 6: Proceso de envío del paquete inicial para ejecutar la carga útil del atacante con privilegios elevados
El vector TOCTOU
En este caso, aprovechamos la diferencia de tiempo entre la verificación del certificado y la ejecución real del binario (Figura 7). Es decir, intentamos ganar una condición de carrera cambiando rápidamente el archivo legítimo por uno malicioso mediante la herramienta BaitAndSwitch de James Forshaw. Queremos reemplazarlo inmediatamente después de la verificación del certificado. De esta forma, la verificación se realiza en un archivo legítimo, pero después se ejecuta un archivo malicioso no verificado.
Por diseño, no se garantiza que las condiciones de carrera funcionen. Para estabilizar esta explotación, podemos intentar ganar más tiempo para la sustitución y ampliar nuestra ventana de oportunidad.
Fig. 7: Ilustración del vector TOCTOU
Recuerde que la verificación del certificado se basa en dos pruebas: una llamada a WinVerifyTrust y una comprobación entre varios campos del certificado y una cadena codificada de la aplicación. Podemos implantar un certificado con estos valores exactos en nuestro ejecutable. Esta mejora permite al atacante ganar la condición de carrera incluso si el cambio se produce entre las dos pruebas, ya que nuestro binario malicioso cumple todos los criterios para la segunda prueba.
La animación de la Figura 8 muestra el proceso desde la espera para el inicio del proceso de verificación con BaitAndSwitch hasta la ejecución del binario del atacante (en este caso, cmd.exe).
Fig. 8: Proceso desde la espera para el inicio del proceso de verificación con BaitAndSwitch hasta la ejecución del binario del atacante
Detección y mitigación
Para ayudar en la detección de activos vulnerables en la red, proporcionamos una osquery para buscar instancias de SteelSeries GG y su versión instalada actualmente:
SELECT name,version from programs where name LIKE '%SteelSeries%' |
Los clientes de Guardicore Segmentation de Akamai pueden utilizar esta consulta con Insight para localizar aplicaciones que requieran parches.
SteelSeries actualiza su aplicación con cada nuevo parche. Esto puede reducir las posibilidades de que sus dispositivos se vean afectados por estas vulnerabilidades, pero recomendamos a los defensores que actualicen su versión de SteelSeries a una superior a la 39.
Conclusión
SteelSeries es una gran empresa con una gran base de usuarios de más de 9 millones de clientes en todo el mundo. Cualquier vulnerabilidad de sus productos tiene un impacto inherente. Las consecuencias se agravan si tenemos en cuenta la facilidad de explotación de estas vulnerabilidades y su efecto en la máquina; es decir, la posibilidad de obtener la ejecución de binarios en el contexto de ADMIN.
El alcance del impacto no se limita a la máquina que pertenece al usuario; las empresas también pueden verse afectadas. El portátil de un empleado que se conecta a un dispositivo vulnerable o ejecuta una aplicación vulnerable puede conectarse posteriormente a la red de la empresa e "importar" riesgos a la organización. Por este motivo, es importante que las empresas consideren la posibilidad de implementar una política "traiga su propio dispositivo" (BYOD) y de educar a los empleados sobre los peligros que conlleva el uso de dichos dispositivos.
Hemos analizado las redes de los clientes de Akamai para buscar instancias de la aplicación vulnerable e informado a los clientes correspondientes.
Como parte de nuestros esfuerzos continuos para proteger a nuestros clientes y a la comunidad, seguiremos analizando parches y otros sistemas en busca de vulnerabilidades. Para mantenerse al día con las últimas investigaciones de seguridad de Akamai, síganos en Twitter.
Tiempo de divulgación
27/4/2023: solicitud de CVE enviada a MITRE
1/5/2023: correo electrónico enviado al servicio de atención al cliente de SteelSeries
2/5/2023: CVE asignadas por MITRE
3/5/2023 – 4/6/2023: conversaciones con el equipo de ingeniería de SteelSeries
31/5/2023: correcciones publicadas
17/7/2023: borrador del blog revisado por SteelSeries
18/7/2023: entrada de blog publicada
