Netop Vision Pro: el software de aprendizaje a distancia es 20/20 en retrospectiva


El equipo de investigación avanzada de amenazas de McAfee Labs se compromete a descubrir problemas de seguridad tanto en el software como en el hardware para ayudar a los desarrolladores a ofrecer productos más seguros para empresas y consumidores. Recientemente, investigamos el software instalado en las computadoras que se utilizan en los distritos escolares K-12. El enfoque de este blog está en Netop Vision Pro producido por Netop. Nuestra investigación sobre este software condujo al descubrimiento de cuatro problemas críticos previamente no reportados, identificados por CVE-2021-27192, CVE-2021-27193, CVE-2021-27194 y CVE-2021-27195. Estos hallazgos permiten la elevación de privilegios y, en última instancia, la ejecución remota de código, que podría ser utilizado por un atacante malintencionado, dentro de la misma red, para obtener un control total sobre las computadoras de los estudiantes. Informamos de esta investigación a Netop el 11 de diciembre de 2020 y nos entusiasmó que Netop pudiera entregar una versión actualizada en febrero de 2021, parcheando de manera efectiva muchas de las vulnerabilidades críticas.

Netop Vision Pro es un sistema de monitoreo de estudiantes para que los maestros faciliten el aprendizaje de los estudiantes mientras usan las computadoras de la escuela. Netop Vision Pro permite a los profesores realizar tareas de forma remota en las computadoras de los estudiantes, como bloquear sus computadoras, bloquear el acceso a la web, controlar de forma remota sus escritorios, ejecutar aplicaciones y compartir documentos. Netop Vision Pro se usa principalmente para administrar un salón de clases o un laboratorio de computación en un entorno K-12 y no está dirigido principalmente para eLearning o dispositivos personales. En otras palabras, el software Netop Vision Pro nunca debería ser accesible desde Internet en la configuración estándar. Sin embargo, como resultado de estos tiempos anormales, se están prestando computadoras a los estudiantes para que continúen el aprendizaje a distancia, lo que resulta en que el software escolar se conecte a una amplia gama de redes, lo que aumenta la superficie de ataque.

Reconocimiento inicial

Netop ofrece todo el software como prueba gratuita en su sitio web, lo que facilita que cualquiera pueda descargarlo y analizarlo. A los pocos minutos de descargar el software, pudimos configurarlo y ejecutarlo sin complicaciones.

Comenzamos configurando el software Netop en una configuración y un entorno normales. Colocamos cuatro máquinas virtuales en una red local; tres se establecieron como estudiantes y uno como profesor. Las tres máquinas de los estudiantes se configuraron con cuentas que no son de administrador en nuestro intento de emular una instalación normal. El profesor primero crea un "aula" que luego puede elegir qué PC de los estudiantes deben conectarse. El maestro tiene el control total y puede elegir a qué "aula" se conecta el estudiante sin la participación del estudiante. Una vez que se ha configurado un aula, el maestro puede iniciar una clase que inicia la sesión haciendo ping a cada estudiante para que se conecte al aula. Los estudiantes no tienen ninguna entrada si quieren conectarse o no, ya que el maestro lo impone. Una vez que los estudiantes se han conectado al aula, el maestro puede realizar un puñado de acciones para toda la clase o para estudiantes individuales.

Durante esta configuración, también tomamos nota de los niveles de permiso de cada componente. La instalación del estudiante debe ser a prueba de manipulaciones y persistente para evitar que los estudiantes deshabiliten el servicio. Esto se logra instalando el agente de NetOp como un servicio del sistema que se inicia automáticamente al arrancar. La instalación del profesor se ejecuta como un usuario normal y no se inicia al arrancar. Esta diferencia en el contexto de ejecución y el comportamiento de inicio nos llevó a apuntar a las instalaciones de los estudiantes, ya que un atacante tendría una mayor probabilidad de obtener permisos elevados del sistema si estuviera comprometido. Además, la proporción de estudiantes por maestros en un entorno escolar normal garantizaría que cualquier vulnerabilidad encontrada en las máquinas de los estudiantes se extendiera más ampliamente.

Con la instalación inicial completa, tomamos una captura de red en la red local y tomamos nota del tráfico entre el profesor y el alumno. Se puede ver una descripción general de los primeros paquetes de red en la Figura 1 a continuación y cómo comienza la transacción del profesor y el estudiante.

Figura 1: Tráfico de red capturado entre profesor y alumno

Nuestra primera observación, ahora clasificada como CVE-2021-27194, fue que todo el tráfico de la red estaba sin cifrar y no había opción para activar el cifrado durante la configuración. Notamos que incluso la información que normalmente se considera confidencial, como las credenciales de Windows (Figura 2) y las capturas de pantalla (Figura 4), se enviaban en texto sin formato. Se observaron las credenciales de Windows en la red cuando un maestro emitía un comando "Iniciar sesión" para el estudiante. Esto podría ser utilizado por el maestro o el administrador para instalar software o simplemente ayudar a un estudiante a iniciar sesión.

Figura 2: Credenciales de Windows pasadas en texto plano

Además, observamos un comportamiento predeterminado interesante en el que un estudiante que se conecta a un aula inmediatamente comienza a enviar capturas de pantalla al maestro del aula. Esto le permite al maestro monitorear a todos los estudiantes en tiempo real, como se muestra en la Figura 3.

Figura 3: Profesor viendo todas las máquinas de los estudiantes a través de capturas de pantalla

Dado que no hay cifrado, estas imágenes se enviaron sin cifrar. Cualquiera en la red local podría escuchar estas imágenes y ver el contenido de las pantallas de los estudiantes de forma remota. Se enviaba una nueva captura de pantalla cada pocos segundos, lo que proporcionaba al maestro y a los espías un flujo casi en tiempo real de la computadora de cada alumno. Para capturar y ver estas imágenes, todo lo que teníamos que hacer era configurar nuestra tarjeta de red en modo promiscuo (https://www.computertechreviews.com/definition/promiscuous-mode/) y use una herramienta como Driftnet (https://github.com/deiv/driftnet). Estos dos pasos nos permitieron capturar las imágenes pasadas a través de la red y ver la pantalla de cada estudiante mientras estaban conectados a un aula. La imagen de la Figura 4 muestra una captura de pantalla capturada de Driftnet. Esto nos llevó a presentar nuestra primera vulnerabilidad divulgada como CVE-2021-27194, haciendo referencia a “CWE-319: Transmisión de texto sin cifrar de información confidencial” para este hallazgo. Como se señaló anteriormente, el profesor y los estudiantes clientes se comunicarán directamente a través de la red local. La única forma en que un fisgón podría acceder a los datos no cifrados sería rastreando el tráfico en la misma red local que los estudiantes.

Figura 4: Imagen del escritorio del alumno capturada de Driftnet a través de la red

Difuminar los mensajes de difusión

Con el objetivo de la ejecución remota de código en las computadoras de los estudiantes, comenzamos a diseccionar el primer paquete de red, que el maestro envía a los estudiantes, diciéndoles que se conecten al aula. Este fue un mensaje UDP enviado por el maestro a todos los estudiantes y se puede ver en la Figura 5.

Figura 5: Captura de Wireshark del mensaje UDP del profesor

El propósito de este paquete es que el software cliente del estudiante sepa dónde encontrar la computadora del maestro en la red. Debido a que este mensaje UDP se envía a todos los estudiantes en un estilo de transmisión y no requiere apretón de manos o configuración como TCP, este fue un buen lugar para comenzar.

Creamos una capa Scapy personalizada (https://scapy.readthedocs.io/en/latest/api/scapy.layers.html) (Figura 6) del mensaje UDP que se ve en la Figura 5 para comenzar a diseccionar cada campo y elaborar nuestros propios paquetes. Después de unos días de fuzzing con paquetes UDP, pudimos identificar dos cosas. En primer lugar, observamos una falta de comprobaciones de longitud en las cadenas y, en segundo lugar, los valores aleatorios enviados por el fuzzer se escribían directamente en el registro de Windows. El efecto de estas pruebas se puede ver fácilmente en la Figura 7.

Figura 6: Mensaje de transmisión UDP del profesor

Incluso con estas entradas mal formadas en el registro (Figura 7), nunca observamos que la aplicación fallara o respondiera inesperadamente. Esto significa que, aunque la aplicación no estaba manejando nuestro paquete mutado correctamente, nunca sobrescribimos nada de importancia ni cruzamos un límite de búfer de cadena.

Figura 7: Caracteres no desinfectados que se escriben en el Registro

Para ir más allá, necesitábamos enviar los siguientes paquetes que observamos desde nuestra captura de red (Figura 8). Después del primer mensaje UDP, todos los paquetes posteriores fueron TCP. Los mensajes TCP negociarían una conexión entre el alumno y el profesor y mantendrían el enchufe abierto durante la conexión del aula. Este intercambio de negociación de TCP fue una transferencia de 11 paquetes, que llamaremos apretón de manos.

Figura 8: Captura de Wireshark de una clase de inicio de profesor

Invertir el protocolo de red

Para responder adecuadamente a la solicitud de conexión TCP, necesitábamos emular cómo respondería un profesor válido al apretón de manos; de lo contrario, el estudiante interrumpiría la conexión. Comenzamos a aplicar ingeniería inversa al tráfico de la red TCP e intentamos emular el tráfico real de "profesores". Después de capturar un puñado de paquetes, las cargas útiles comenzaron a ajustarse aproximadamente al mismo formato. Cada uno comenzaba con el tamaño del paquete y la cadena "T125". Había tres paquetes en el apretón de manos que contenían campos que cambiaban entre cada conexión de clase. En total, se identificaron cuatro campos cambiantes.

El primer campo fue session_id, que identificamos en IDA y se muestra en el paquete UDP de la Figura 6. De nuestro ejercicio de fuzzing con el paquete UDP, aprendimos que si el mismo session_id se reutilizaba varias veces, el estudiante aún respondería normalmente, a pesar de que el tráfico de red real que capturamos a menudo tendría un session_id único.

Esto nos dejó tres campos dinámicos restantes que identificamos como un token de maestro, un token de estudiante y un DWORD desconocido único (8 bytes). Identificamos dos de estos campos estableciendo múltiples aulas con diferentes computadoras para maestros y estudiantes y monitoreando estos valores. La ficha de maestro era estática y única para cada maestro. Descubrimos que lo mismo sucedía con la ficha de estudiante. Esto nos dejó con el campo DWORD único que era dinámico en cada apretón de manos. Este último campo al principio parecía aleatorio, pero siempre estaba en el mismo rango relativo. Lo etiquetamos como "Token3" para gran parte de nuestra investigación, como se ve en la Figura 9 a continuación.

Figura 9: Salida de la secuencia de comandos de Python que identifica "Token3"

Finalmente, mientras usaba WinDbg para realizar análisis dinámicos, el valor de Token3 comenzó a resultar familiar. Notamos que coincidía con el rango de memoria que se asigna al montón. Esto se puede ver en la Figura 10.

Figura 10: Análisis del espacio de direcciones de WinDbg desde la PC de un estudiante

Al combinar nuestra comprensión previa del tráfico de transmisión UDP con nuestra capacidad para responder adecuadamente a los paquetes TCP con campos dinámicos, pudimos emular con éxito la estación de trabajo de un profesor. Demostramos esto modificando nuestro script de Python con esta nueva información y enviando una solicitud para conectarnos con el estudiante. Cuando un alumno se conecta a un profesor, muestra un mensaje que indica que se ha realizado una conexión satisfactoria. A continuación se muestran dos imágenes que muestran a un profesor conectándose (Figura 11) y nuestro script Python conectándose (Figura 12). Con fines puramente de demostración, hemos denominado a nuestra máquina de ataque "hacker" y a nuestro salón de clases "hacker-room".

Figura 11: Emulación de un maestro exitoso

Figura 12: Conexión de profesor emulada desde la secuencia de comandos de Python

Para comprender el proceso de ingeniería inversa del tráfico de red con más detalle, los investigadores de McAfee Douglas McKee y Ismael Valenzuela han publicado una charla en profundidad sobre cómo hackear protocolos propietarios como el que utiliza Netop. Su webinar es mucho más detallado que este blog y se puede ver aquí.

Reproducir una acción de comando

Dado que hemos emulado con éxito la conexión de un profesor utilizando Python, para mayor claridad nos referiremos a nosotros mismos como el atacante y a una conexión legítima realizada a través de Netop como el profesor.

A continuación, comenzamos a analizar algunas de las acciones que pueden realizar los profesores y cómo podríamos aprovecharlas. Una de las acciones que puede realizar un profesor es iniciar aplicaciones en las PC de los estudiantes remotos. En la suite de profesores, se le solicita al profesor el conocido indicador Ejecutar de Windows, y cualquier aplicación o comando configurado para ejecutarse se ejecuta en las máquinas de los estudiantes (Figura 13).

Figura 13: El mensaje "Ejecutar aplicación" del profesor

Al observar el tráfico de la red (que se muestra en la Figura 14), esperábamos encontrar un campo en el paquete que nos permitiera desviarnos de lo que era posible con el cliente del profesor. Como mencionamos anteriormente, todo está en texto plano, lo que hace que sea bastante fácil identificar qué paquetes se estaban enviando para ejecutar aplicaciones en los sistemas remotos buscando dentro de Wireshark.

Figura 14: Ejecute el paquete "calc"

Antes de comenzar a modificar el paquete que ejecuta aplicaciones en las máquinas de los estudiantes, primero queríamos ver si podíamos reproducir este tráfico con éxito. Como puede ver en el video a continuación, nuestro script de Python pudo ejecutar PowerShell seguido de la Calculadora de Windows en cada uno de los puntos finales de los estudiantes. Esto demuestra que incluso las acciones válidas de los profesores pueden ser útiles para los atacantes.

(incrustar) https://www.youtube.com/watch?v=5NS3syvksGs (/ incrustar)

La capacidad de un atacante de emular a un profesor y ejecutar comandos arbitrarios en las máquinas de los estudiantes nos lleva a nuestro segundo CVE. CVE-2021-27195 se presentó para "CWE-863: Autorización incorrecta" ya que pudimos reproducir el tráfico de red local modificado.

Cuando el maestro envía un comando al estudiante, el cliente cedería los privilegios al estudiante que inició sesión y no conservaría los privilegios originales del sistema. Esto significaba que si un atacante deseaba tener acceso sin restricciones al sistema remoto, no podía simplemente reproducir el tráfico normal, sino que tendría que modificar cada campo en el tráfico y observar los resultados.

En un intento por encontrar una forma de evitar la reducción de privilegios durante la ejecución del comando, continuamos borrando todos los campos ubicados dentro del paquete "ejecutar comando". Esto resultó infructuoso, ya que no pudimos encontrar una estructura de paquete que impidiera que el comando redujera los privilegios. Esto requirió una inmersión más profunda en el código en el manejo de la ejecución remota del comando procesada en el punto final del estudiante. Al rastrear la ruta de ejecución dentro de IDA, descubrimos que, de hecho, había una ruta que permitía ejecutar comandos remotos sin perder privilegios, pero requería un caso especial, como se muestra en la Figura 15.

Figura 15: Vista de gráfico IDA que muestra rutas alternativas de ejecución de código

Figura 16: Imagen ampliada de la ruta del código ShellExecute

La ruta del código que pasa por alto la reducción de privilegios y va directamente a "ShellExecute" estaba verificando una variable que tenía su valor establecido durante el inicio. No pudimos encontrar ninguna otra ruta de código que actualizara este valor después de que se inició el software. Nuestra teoría es que este valor puede usarse durante la instalación o desinstalación, pero no pudimos forzar legítimamente la ejecución a la ruta "ShellExecute".

Esta ruta de código a “ShellExecute” nos hizo preguntarnos si había otras ramas similares como esta a las que se pudiera acceder. Comenzamos a buscar el código desensamblado en IDA para las llamadas que no estaban envueltas en código, lo que resultaba en privilegios más bajos. Encontramos cuatro casos en los que los privilegios no se redujeron, sin embargo, ninguno de ellos fue accesible a través de la red. Independientemente, todavía podrían ser potencialmente útiles, por lo que investigamos cada uno. El primero se usó al abrir Internet Explorer (IE) con una URL precargada. Esto resultó estar relacionado con el sistema de apoyo. Al examinar la interfaz de usuario en la máquina del estudiante, descubrimos un botón de "Soporte técnico" que se encontraba en el menú "Acerca de" de NetOp.

Cuando el usuario hace clic en el botón de soporte, abre IE directamente en un formulario web de soporte. Sin embargo, el problema es que los privilegios nunca se eliminan, lo que hace que el proceso de IE se ejecute como Sistema porque el cliente de Netop para estudiantes también se ejecuta como Sistema. Esto se puede ver en la Figura 11. Presentamos este problema como nuestro tercer CVE, CVE-2021-27192 haciendo referencia a “CWE-269: Asignación de privilegios incorrecta”.

Figura 17: Internet Explorer ejecutándose como sistema

Hay un puñado de formas bien documentadas de obtener una elevación local de privilegios (LPE) utilizando solo el mouse cuando el usuario tiene acceso a una aplicación que se ejecuta con privilegios más altos. Usamos una técnica antigua que usa el botón "Guardar como" para navegar a la carpeta donde se encuentra cmd.exe y ejecutarlo. El proceso CMD resultante hereda los privilegios del sistema del proceso principal, lo que le da al usuario un shell de nivel de sistema.

Si bien este LPE fue emocionante, todavía queríamos encontrar algo con un vector de ataque remoto y utilizar nuestro script de Python para emular el tráfico de profesores. Decidimos profundizar en el tráfico de la red para ver qué podíamos encontrar. Simulando un atacante, emulamos con éxito lo siguiente:

  • Ejecución remota de CMD
  • Pantalla en blanco del estudiante
  • Reiniciar Netop
  • Apaga el ordenador
  • Bloquear el acceso web a sitios web individuales
  • Desbloquear las propiedades de Netop (en la computadora del estudiante)

Durante la emulación de todas las acciones anteriores, realizamos un fuzzing rudimentario en varios campos de cada uno y descubrimos seis fallas que causaron que la instalación del estudiante de Netop fallara y reiniciara. Pudimos encontrar dos violaciones de ejecución, dos violaciones de lectura, una excepción de escritura y una excepción del kernel. Después de la investigación, determinamos que estos accidentes no eran fáciles de explotar y, por lo tanto, tenían una menor prioridad para una investigación más profunda. Independientemente, los informamos a Netop junto con todos los demás hallazgos.

Explorando complementos

Netop Vision Pro viene con un puñado de complementos instalados de forma predeterminada, que se utilizan para separar diferentes funcionalidades del ejecutable principal de Netop. Por ejemplo, para permitir que el profesor y el alumno se envíen mensajes instantáneos (IM) entre sí, se utiliza el complemento MChat.exe. Con un paradigma similar al ejecutable principal, los estudiantes no deberían poder detener estos complementos, por lo que también se ejecutan como Sistema, lo que hace que valga la pena explorarlos.

Imitando nuestro enfoque anterior, comenzamos a buscar llamadas "ShellExecute" dentro de los complementos y, finalmente, descubrimos tres escaladas de privilegios más, cada una de las cuales se llevó a cabo de una manera comparable utilizando solo el mouse y omitiendo los filtros de archivos restrictivos dentro de las ventanas "Guardar como". . Las ventanas MChat.exe, SSView.exe (Screen Shot Viewer) y la página Acerca de "Información del sistema" tenían un botón "Guardar como" similar, cada uno de los cuales resultaba en LPE simples sin necesidad de código o exploit. Agregamos cada uno de estos complementos en el campo de versiones afectadas en nuestro tercer CVE, CVE-2021-27192, mencionado anteriormente.

Todavía estábamos buscando un método para lograr la ejecución remota de código y ninguna de las llamadas "ShellExecute" utilizadas para los LPE eran accesibles a través de la red. Comenzamos a reducir los complementos que pasan datos proporcionados por el usuario a través de la red. Esto dirigió nuestra atención de nuevo al complemento MChat. Como parte de nuestro reconocimiento inicial para proyectos de investigación, revisamos los registros de cambios en busca de cambios de seguridad relevantes. Durante esta revisión, notamos un registro interesante relacionado con el cliente MChat como se ve en la Figura 13.

Figura 18: Cambio de registro de Netop.com

La función Chat se ejecuta como Sistema, como todos los complementos, y puede enviar texto o archivos a la computadora remota del estudiante. Un atacante siempre puede utilizar esta funcionalidad en su beneficio, ya sea sobrescribiendo archivos existentes o incitando a una víctima a hacer clic en un ejecutable eliminado. Al investigar cómo funciona la función de chat y, específicamente, cómo se envían los archivos, descubrimos que los archivos se envían a las computadoras de los estudiantes sin ninguna interacción por parte del estudiante. Todos los archivos enviados por un profesor se almacenan en un "directorio de trabajo", que el alumno puede abrir desde la ventana de mensajería instantánea. Antes de la última versión, se habría abierto como Sistema; esto se corrigió como se indica en la Figura 18. Profundizando en la funcionalidad de la aplicación de chat, encontramos que el maestro también tiene la capacidad de leer archivos en el "directorio de trabajo" del estudiante y eliminar archivos dentro de él. Debido a nuestros hallazgos demostrados con CVE-2021-27195, podemos aprovechar nuestro código de emulación como atacante para escribir, leer y eliminar archivos dentro de este "directorio de trabajo" desde un vector de ataque remoto en la misma red local. Esta capacidad para leer y escribir archivos representó el último CVE que presentamos, CVE-2021-27193 que hace referencia a “CWE-276: Permisos predeterminados incorrectos”, con la puntuación CVSS más alta general de 9.5.

Para determinar si el complemento MChat potencialmente nos daría acceso a nivel del sistema, necesitábamos investigar si las operaciones del archivo del complemento estaban restringidas a los permisos del estudiante o si el complemento heredó los privilegios del sistema del contexto de ejecución. Al examinar el código desensamblado del complemento MChat, como se muestra en la Figura 14, aprendimos que todas las acciones de archivos en la computadora del estudiante se ejecutan con privilegios del sistema. Solo después de que finalice la operación del archivo, los permisos se establecerán para permitir el acceso para todos, esencialmente el efecto de usar el comando "chmod 777" de Linux, para hacer que los archivos sean de lectura / escritura universal.

Figura 19: captura de pantalla de IDA de las operaciones del archivo MChat que cambian el acceso a todos

Para validar esto, creamos varios archivos de prueba usando una cuenta de administrador y restringimos los permisos para no permitir que el estudiante modifique o lea los archivos de prueba. Procedimos a cargar el paquete de profesores y, a través de una sesión de MChat, confirmamos que pudimos leer, escribir y eliminar estos archivos. Este fue un descubrimiento emocionante; sin embargo, si el atacante está limitado al "directorio de trabajo" predeterminado, el efecto que podría tener en el objetivo remoto sería limitado. Para investigar si podíamos cambiar el "directorio de trabajo", comenzamos a investigar en la suite de profesores. Escondido en unas pocas capas de menús (Figura 20), encontramos que un profesor puede, de hecho, configurar el "directorio de trabajo" del estudiante remoto y actualizarlo de forma remota. Saber que podemos emular fácilmente el comando de cualquier profesor significa que podríamos modificar el "directorio de trabajo" en cualquier parte del sistema del estudiante. En base a esto, un atacante que aproveche esta falla podría tener acceso al sistema para modificar cualquier archivo en la PC remota.

Figura 20: Cambio de la ruta del alumno remoto desde el cliente de un profesor

Invertir el tráfico de la red MChat

Ahora que sabíamos que el profesor podía sobrescribir cualquier archivo del sistema, incluidos los ejecutables del sistema, queríamos automatizar este ataque y agregarlo a nuestro script de Python. Al automatizar esto, queremos mostrar cómo los atacantes pueden usar problemas como este para crear herramientas y scripts que tengan impactos en el mundo real. Para que comenzara una sesión de chat, tuvimos que iniciar el protocolo de enlace de 11 paquetes que discutimos anteriormente. Una vez que el estudiante se conectó a nuestra máquina de ataque, necesitábamos enviar una solicitud para iniciar una sesión de chat con el estudiante objetivo. Esta solicitud haría que el estudiante respondiera usando TCP, pero esta vez, en un puerto separado, iniciando un protocolo de enlace de siete paquetes de MChat. Esto nos obligó a aplicar ingeniería inversa a este nuevo formato de protocolo de enlace con un enfoque similar al descrito anteriormente. A diferencia del primer apretón de manos, el apretón de manos de MChat tenía un único identificador único para cada sesión y, después de la prueba, se determinó que el ID podía codificarse con un valor estático sin efectos negativos.

Finalmente, queríamos sobrescribir un archivo que pudiéramos asegurarnos de que se ejecutaría con privilegios del sistema. Con el exitoso apretón de manos de MChat, necesitábamos enviar un paquete que cambiara el "directorio de trabajo" al de nuestra elección. La Figura 21 muestra el paquete como una capa Scapy que se usa para cambiar el directorio de trabajo en la PC del estudiante. El directorio de complementos de Netop era un directorio de destino perfecto para cambiar, ya que cualquier cosa ejecutada desde este directorio se ejecutaría como System.

Figura 21: Cambiar el directorio de trabajo en la PC del estudiante

El último paso para obtener la ejecución a nivel del sistema fue sobrescribir y ejecutar uno de los complementos con un binario "malicioso". A través de las pruebas, descubrimos que si el archivo ya existe en el mismo directorio, la aplicación de chat es lo suficientemente inteligente como para no sobrescribirlo, sino que agrega un número al nombre del archivo. Esto no es lo que queríamos ya que el complemento original se ejecutaría en lugar de nuestro "malicioso". Esto significó que también tuvimos que aplicar ingeniería inversa a un paquete que contiene comandos que se utilizan para eliminar archivos. La capa Scapy utilizada para eliminar un archivo y guardar uno nuevo se muestra en la Figura 22.

Figura 22: Capas de Python Scapy para "eliminar" (MChatPktDeleteFile) y "escribir" (MChatPkt6) archivos

Con estas capas de Scapy pudimos reemplazar el complemento de destino con un binario de nuestra elección, manteniendo el mismo nombre que el complemento original. Elegimos el complemento "SSView.exe", que es un complemento que se utiliza para mostrar capturas de pantalla en la computadora del alumno. Para ayudar a visualizar todo este proceso, consulte la Figura 23.

Figura 23: Un flujo de ataque utilizando el complemento MChat para sobrescribir un ejecutable

Ahora que se ha sobrescrito el complemento SSView.exe, activar este complemento ejecutará nuestro código proporcionado por el atacante. Esta ejecución heredará los privilegios del sistema Netop, y todo puede realizarse desde un vector de ataque remoto no autenticado.

Impacto

No es difícil imaginar un escenario en el que la culminación de estos problemas pueda conducir a varios resultados negativos. El mayor impacto es la ejecución remota de código arbitrario con privilegios del sistema desde cualquier dispositivo de la red local. Este escenario tiene el potencial de ser manipulable, lo que significa que el binario arbitrario que ejecutamos podría diseñarse para buscar otros dispositivos y promover la propagación. Además, si se configura la opción "Inscripción abierta" para un aula, el cliente de estudiante Netop Vision Pro transmite su presencia en la red cada pocos segundos. Esto se puede utilizar en beneficio de un atacante para determinar las direcciones IP de todos los estudiantes conectados en la red local. Como se ve en la Figura 24, nuestra secuencia de comandos Python buscó mensajes de difusión de los estudiantes durante 5 segundos y encontró las tres computadoras de los estudiantes en la misma red. Debido a que estos mensajes de transmisión se envían a toda la red local, esto podría muy bien escalar a todo un sistema escolar.

Figura 24: Encontrar a todos los estudiantes en la red local.

Con una lista de computadoras que ejecutan el software del estudiante, un atacante puede enviar comandos a cada una individualmente para ejecutar código arbitrario con privilegios del sistema. En el contexto del aprendizaje híbrido y electrónico, es importante recordar que este software en la computadora del estudiante no se apaga. Debido a que siempre está funcionando, incluso cuando no está en uso, este software asume que cada red a la que se conecta el dispositivo podría tener un maestro y comienza a transmitir su presencia. Un atacante no tiene que comprometer la red de la escuela; todo lo que necesitan es encontrar cualquier red en la que se pueda acceder a este software, como una biblioteca, una cafetería o una red doméstica. No importa dónde se vea comprometida una de las PC de estos estudiantes, ya que un malware bien diseñado podría permanecer inactivo y escanear cada red a la que se conecta la PC infectada, hasta que encuentre otras instancias vulnerables de Netop Vision Pro para propagar aún más la infección.

Una vez que estas máquinas se han visto comprometidas, el atacante remoto tiene el control total del sistema, ya que heredan los privilegios del sistema. Nada en este punto podría evitar que un atacante que se ejecuta como System acceda a los archivos, finalice cualquier proceso o cause estragos en la máquina comprometida. Para profundizar en los efectos de estos problemas, podemos proponer algunos escenarios. Un atacante podría usar la capacidad de detección de estas máquinas para implementar ransomware en todas las computadoras de la escuela en la red, paralizando la escuela o todo el distrito escolar. Un atacante más sigiloso podría instalar silenciosamente un software de registro de teclas y monitorear capturas de pantalla de los estudiantes, lo que podría llevar a que las redes sociales o las cuentas financieras se vean comprometidas. Por último, un atacante podría monitorear las cámaras web de los estudiantes, reduciendo la brecha entre el software comprometido y el ámbito físico. Como prueba de concepto, el siguiente video mostrará cómo un atacante puede juntar CVE-2021-27195 y CVE-2021-27193 para encontrar, explotar y monitorear las cámaras web de cada computadora que ejecuta Netop Vision Pro.

(incrustar) https://www.youtube.com/watch?v=runQ2en9PNU (/ incrustar)

La adaptación segura del software es mucho más fácil de lograr cuando la seguridad se integra desde el principio, en lugar de una ocurrencia tardía. Es fácil de reconocer cuando el software está diseñado para entornos "seguros". Si bien Netop Vision Pro nunca tuvo la intención de estar orientado a Internet o salir de una red escolar administrada, sigue siendo importante implementar funciones de seguridad básicas como el cifrado. Al diseñar software, no se debe asumir lo que será un lugar común en el futuro. Por ejemplo, cuando este software se desarrolló originalmente, el concepto de aprendizaje remoto o aprendizaje híbrido era una idea lejana, pero ahora parece que será una norma. Cuando las decisiones de seguridad se integran desde el inicio, el software puede adaptarse a nuevos entornos mientras mantiene a los usuarios mejor protegidos de futuras amenazas.

Divulgación y mitigaciones recomendadas

Revelamos todos estos hallazgos a Netop el 11 de diciembre de 2020 y escuchamos de ellos poco después. Nuestra divulgación incluyó recomendaciones para implementar el cifrado de todo el tráfico de la red, agregar autenticación y verificación de maestros a los estudiantes, y filtros de análisis de paquetes más precisos. En Netop Vision Pro 9.7.2, lanzado a finales de febrero, Netop corrigió las escaladas de privilegios locales, cifró las credenciales de Windows que antes eran de texto sin formato y mitigó las lecturas / escrituras arbitrarias en el sistema de archivos remoto dentro del cliente MChat. Las escaladas de privilegios locales se solucionaron ejecutando todos los complementos como estudiante y ya no como System. De esta forma, los botones "Guardar como" se limitan a la cuenta del alumno. Las credenciales de Windows ahora se cifran mediante RC4 antes de enviarse a través de la red, lo que evita que los espías recopilen las credenciales de la cuenta. Por último, dado que todos los complementos se ejecutan como estudiante, el cliente MChat ya no puede eliminar y reemplazar los ejecutables del sistema, lo que mitiga con éxito el ataque que se muestra en la sección de impacto. El tráfico de la red aún está sin cifrar, incluidas las capturas de pantalla de las computadoras de los estudiantes, pero Netop nos ha asegurado que está trabajando para implementar el cifrado en todo el tráfico de la red para una futura actualización. Nos gustaría reconocer la excelente respuesta de Netop y el rápido desarrollo y lanzamiento de una versión de software más segura y alentar a los proveedores de la industria a tomar nota de esto como un estándar para responder a las divulgaciones responsables de los investigadores de la industria.





Enlace a la noticia original