Conferencia DEFCON 27. Buttplug: Pruebas de penetración real. Parte 2

Los analistas creen que actualmente hay alrededor de 10 mil millones de dispositivos del mundo de Internet de las cosas (IoT). A veces, estos dispositivos ganan su lugar en el mercado, literalmente escalando culos humanos. Resultó que los chips de radio baratos y de baja potencia no solo son excelentes para la automatización del hogar, sino que también cambian la forma en que las personas interactúan con los juguetes sexuales. En este informe, nos sumergiremos en el mundo de la televisión dildonics, la tecnología del sexo a una distancia en la cual las sensaciones táctiles, de temperatura y otras se transmiten entre las parejas a través de una línea de comunicación bidireccional. El orador le dirá que la seguridad de los juguetes electrónicos de sexo anal electrónicos de Buttplug se puede oponer a un atacante que encuentra y explota vulnerabilidades en cada nivel de la pila. En última instancia, esto permite que los juguetes sexuales se vean comprometidos,y los dispositivos a los que se conectan.



Un hacker con el apodo smea, o Smealum, comenzó su carrera como desarrollador de videojuegos para consolas de juegos como la Nintendo DS, tratando simultáneamente de descifrarlos. En algún momento, las consolas adquirieron serios sistemas de seguridad, y Smea cambió del software interno al desarrollo de técnicas para romperlo. Smea es conocido por su "trabajo" en Nintendo 3DS y Wii U, aunque también contribuyó al desarrollo de exploits para los navegadores web y las pilas de virtualización más populares. Probablemente, ahora se interesó en irrumpir en tapones anales "inteligentes".

Conferencia DEFCON 27. Buttplug: Pruebas de penetración real. Parte 1



Por supuesto, puede administrar los mensajes entrantes incluso con una longitud de línea tan corta. Por ejemplo, 30 caracteres son suficientes para ejecutar JavaScript malicioso. Esta diapositiva muestra una etiqueta de ejemplo con una longitud de 30 caracteres para una imagen de una fuente inexistente <img src = a onerror = 'alert (1)'>, lo que hace que la aplicación muestre un mensaje de error. Este mensaje se mostrará cuando la carga de imágenes sea realmente imposible. La captura de pantalla muestra que conectarse a través de un dongle comprometido le permite ejecutar JavaScript malicioso.



El límite de 32 caracteres es molesto porque es difícil darse cuenta de la carga útil del volumen, pero es bastante posible. Entonces, verá que hemos comprometido con éxito la aplicación usando una llave USB y ahora estamos a mitad de camino para revertir el pirateo, es decir, comprometer la aplicación usando un bootplag de pirata informático. La piratería en un sitio de dongle-computer puede ocurrir de dos maneras: a través de una computadora, puede comprometer un dongle, y a través de un dongle, puede comprometer una computadora.

El dongle actúa como un pequeño puente entre el conector de arranque y la aplicación. Surge la pregunta: ¿es posible utilizar la misma vulnerabilidad para comprometer una aplicación en una computadora directamente a través del bootplag? Desafortunadamente, la respuesta a esta pregunta es negativa, y la razón es que hay otra limitación en la longitud de los caracteres del mensaje que provienen del complemento de arranque de la aplicación.



El dongle simplemente empaqueta los mensajes del complemento de arranque y los envía a la aplicación, y en este paso puede insertar su código HTML en ellos. Sin embargo, a la vez puede recibir un mensaje de no más de 20 bytes, que no es suficiente para llevar a cabo un ataque XSS. Sin embargo, hay un error en el firmware del dongle: no se verifica el terminador nulo al final de la línea. Por lo tanto, si puede colocar algunos datos no inicializados después del final de una cadena de 20 caracteres, podrá enviar a la aplicación más de 20 caracteres. Desafortunadamente, no encontré una manera de usar esta vulnerabilidad en la práctica, pero vale la pena tener en cuenta esa oportunidad.

Entonces, el problema es que probablemente no pueda usar esta vulnerabilidad para forzar a la aplicación a ejecutar el código recibido directamente desde el complemento de arranque. Es triste, pero aún más triste que si observa el firmware del dongle, puede ver que, en principio, no hace nada con los datos recibidos, sino que simplemente los copia en una nueva línea y los envía más. Por lo tanto, no podremos usar su vulnerabilidad al ataque desbordando el búfer de memoria. Sin embargo, si es imposible hackear la aplicación directamente desde el complemento de arranque, ¿tal vez sea posible hacerlo a través de la cadena de computadora de plug-dongle de arranque?
Lo bueno es que el chip dongle le permite colocar mucho más código del que se requiere para el programa original de desarrolladores Lovense Hush.



La memoria flash del dongle contiene un área reservada para el cargador DFU, un área para la aplicación Lovense y un área cerrada de SoftDevice para el controlador de hardware para el chip BLE de Nordic Semiconductor. Aquí es donde se procesa el protocolo BLE. Por ejemplo, cuando una aplicación quiere enviar un mensaje BLE a un juguete, accede a SoftDevice a través de una llamada SVC. Además de estas 3 áreas, el dongle tiene un área no utilizada de memoria flash de un volumen suficientemente grande.
Para encontrar la vulnerabilidad en la pila de BLE SoftDevice, debe usar ingeniería inversa, ya que no es de código abierto. Hice lo mismo para encontrar la vulnerabilidad del complemento de firmware. En este caso, es muy fácil seguir el flujo de datos, porque tampoco hay ASLR allí, y es fácil determinar el código que procesará estos mensajes.



A la derecha de la diapositiva, verá el controlador de paquetes entrantes GATTC (un perfil de atributos comunes), que, en esencia, es un dongle. En particular, es un controlador de lectura por tipo de paquetes de respuesta. No soy especialista en dispositivos Bluetooth, pero creo que el punto aquí es que el dongle lee el tipo de dispositivo periférico y usa controladores para todas las variantes de los atributos asociados con este tipo. Esto significa que, de hecho, puede obtener más de 1 atributo a la vez, y el tamaño de cada controlador de un par de datos de atributos se codifica como un campo dentro del paquete, lo que le permite administrarlos.



La diapositiva muestra una muestra de dicho paquete. Los clientes GATT pueden enviar un paquete de solicitud de lectura por tipo que contiene el tipo y el rango de descriptores para leer. Los servidores que responden a la solicitud de lectura por tipo devuelven los datos asociados con los controladores dentro del rango correspondiente a este tipo. El número de pares de descriptor / datos se determina dividiendo la longitud del paquete restante por la longitud del campo del par de descriptor / datos, y este campo siempre es 0x7 o 0x15.



La diapositiva muestra el funcionamiento de la función que nos interesa: puede ver cómo se llena el paquete con datos de una matriz de atributos y se les asigna una longitud de búfer fija. Aquí es donde se coloca el valor del descriptor, y luego el puntero asociado con él. Una matriz de atributos son datos binarios que se colocan dentro del búfer en formato hexadecimal. Los datos se resaltan en azul, y al lado está el descriptor 0D y su puntero asociado 00, se resalta en naranja. El paquete del segundo y tercer controlador se ve similar.

La vulnerabilidad es la siguiente. Si lee el código de la derecha, puede ver el parámetro attribute_data_length ubicado en el marco púrpura: la longitud del mensaje entrante, cuyo valor está completamente controlado por un atacante potencial. Si colocamos un valor cero allí, obtenemos un bucle infinito.



El bucle se vuelve infinito porque el código no verifica si los datos que escribe en el búfer de salida están dentro de este búfer de salida. Como resultado, obtenemos un desbordamiento de búfer de pila clásico, ya que el dispositivo no tiene ASLR o DEP, y el código se ejecuta inmediatamente.

Asignando un valor de cero y obteniendo un bucle infinito, en realidad reemplaza todos los datos de RAM con basura. Sin embargo, esta es una solución fallida, ya que es probable que cause una falla del dispositivo. Pero si usa un valor de 1, entonces limitará el número de bytes que están dentro del mensaje entrante. Esto significa lo siguiente: puede sobrellenar ligeramente este búfer, y luego el búfer, que se basa en la pila, podrá dañar todo lo que está al lado.



Veamos cómo se ve la pila antes del desbordamiento. El conjunto de atributos de búfer del que hablamos se resalta en amarillo, los registros guardados en azul y la dirección de retorno en naranja. Al establecer la longitud del atributo en 0x01, podemos causar un desbordamiento de muchos pares de punteros de manejador / datos. Los descriptores consisten en 2 bytes, pero los dos primeros bytes del descriptor DWORD no se borran. El búfer que estamos desbordando está en la pila sin cookies, sin ASLR, sin DEP.



A continuación, probamos el sistema: envíe un paquete lleno de bytes 0xDA con una longitud de atributo de 0x01. Resulta que reescribimos la dirección de retorno con un puntero a nuestros datos de atributos. Como no hay DEP, esto significa que cada vez que la función regrese, se ejecutará el código que está dentro de nuestro paquete. La única limitación es que necesitamos la dirección de retorno para tener el LSB configurado en el bit menos significativo, por lo que el código se ejecuta en modo Thumb, porque el procesador Cortex M0 no admite el modo ARM.



También reescribimos varias variables locales, mientras nos aseguramos de no reescribir nada usado en el camino de regreso. Básicamente, obtenemos un paquete clásico de puerta trasera. Si prestas atención a esta pila, verás que la reescrita no corresponde al borde, lo que hará que el programa se bloquee.

Hay otro requisito con respecto a los registros almacenados. Estas son variables locales que también se sobrescriben cuando la función regresa.



Uno de ellos se usa para desreferenciar un borde de 32 bits, y la falta de coincidencia de contenido con el borde hará que el programa se bloquee. Por lo tanto, debe asegurarse de que saved_arg_3 = 0, saved_arg_4 corresponde a DWORD, es decir, está dentro del borde y LSB está configurado.

Por lo tanto, debemos asegurarnos de que este paquete funcione. Afortunadamente, esto es realmente fácil, porque la forma en que SoftDevice distribuye estos paquetes entrantes es un buffer de anillo sin ningún requisito de alineación forzada. Whiteshark hizo posible verificar que la alineación del paquete posterior se puede controlar cambiando la longitud del paquete anterior.



El amarillo y el azul resaltaron 2 paquetes que se envían antes de que se envíe el paquete exploit. Esto me permite controlar la alineación del último paquete y hacer que no cause un bloqueo del programa, que es a lo que apuntamos.

Observo que hay un cierto obstáculo de ingeniería: Nordic SoftDevice no proporciona una interfaz para enviar paquetes BLE sin procesar. Para evitarlo, puede usar 2 opciones: implementar su propia pila BLE o romper algunos ganchos en los paquetes originales. Como soy flojo, elegí la opción 2.

Estos ganchos son bastante simples, pero requieren algo de ingeniería inversa. Los métodos de pirateo se pueden encontrar en github, la interfaz está bastante "sucia" y no hay garantías de que esto funcione, pero lo hice. Aún estás mejor usando BTLEJack.

void ble_outgoing_hook(uint8_t* buffer, uint8_t length);

Este puntero de SoftDevice se llama cada vez que se envía un paquete BLE, por lo que se puede modificar de antemano:

int ble_incoming_hook(uint8_t* buffer, uint16_t length);

Este enlace SoftDevice llama cada vez que se recibe un paquete BLE. El valor de retorno determina si se debe omitir el procesamiento normal de SoftDevice.

int send_packet(void* handle, void* buffer, uint16_t length);

Así es como se ve la función de enviar el paquete sin formato a esta conexión BLE.

¿Cómo puedo procesar más de 4 bytes de código a la vez? ¡Necesito enviar algunos paquetes! A la derecha, verá el búfer en anillo de los paquetes BLE entrantes. El primer paquete se muestra en verde: el código de shell que ejecuta una llamada de función con parámetros controlados y luego devuelve "clean". El segundo paquete se muestra en amarillo: este es un búfer de datos que puede ser utilizado por una llamada de función. El tercer paquete se muestra en azul, un búfer que contiene los valores de los parámetros de llamada de función, y naranja, el paquete que inicia la vulnerabilidad utilizando la instrucción C1 E7.



Después de devolver la función pura, podemos reenviar este paquete. El envío de estos 4 paquetes ejecuta cualquier pieza arbitraria de código dentro del dongle, y esto se puede hacer una y otra vez.



Esto es conveniente porque de esta manera realmente puedo llamar a memcpy varias veces para copiar el código binario de shell más grande en la RAM. Luego llamamos a esta función para parchear el código original del dongle en la memoria y usarlo para comprometer la aplicación instalada en la computadora. Como la carga útil de XSS es grande, no la enviamos, sino que la generamos en el código de shell en el dongle. El código de shell es el siguiente.



Como resultado de estas manipulaciones, se obtiene lo siguiente: si podemos controlar la aplicación, entonces podemos controlar el dongle y el bootplag.



Hay dos formas de hackear la sección dongle de buttplag: el dongle puede comprometer el juguete y el buttplag puede comprometer tanto el dongle como la computadora. La ventaja es que la vulnerabilidad Nordic BLE está presente no solo en los productos Lovense, sino también en cualquier dispositivo que use SoftDevise S110, S120 o S130 para el lado del cliente de BLE.

Entonces, tenemos la oportunidad de comprometer la aplicación usando el bootplag. ¿Cómo se puede usar esto? Todavía estamos ejecutando código JavaScript dentro de la aplicación Lovense, y la pregunta es, ¿qué nos da esto? Resulta que la aplicación lovense.exe se ejecuta en Medium IL y funciona en Windows, ofrece posibilidades verdaderamente ilimitadas: incluso sin privilegios de administrador, puede acceder a archivos en su computadora, puede ejecutar código arbitrario, puede implementar XSS, acceder a la red etc.



La siguiente pregunta: si puede crear un programa de ransomware que no solo infecte el bootplag, sino también la computadora del usuario, ¿hay alguna manera de extenderlo aún más haciéndolo viral? Ahora tenemos un hack a nivel local, pero para un hacker sería mucho más útil obtener el control de muchas computadoras de usuario a través de Internet. Cómo hacemos esto? Las funciones sociales del juguete, como el video chat, el chat de texto, la transferencia de imágenes y el control remoto en sí, expanden significativamente la superficie de ataque.

El control remoto es un objetivo excelente, porque si un desarrollador quiere usar un programa propietario, definitivamente tendrá errores y vulnerabilidades. ¿Cómo usarlo? Por ejemplo, puede enviar a un socio un objeto JSON que contenga comandos, por ejemplo, el comando "Vibrar: 10":

{
cate: "id",
id: {
DEADBABEBEEF: {
v: 10
}
}
}

En este caso, el receptor analiza el JSON entrante, genera un comando para el juguete y lo envía más, y aquí hay 2 modos. El primer modo "id:" envía un comando a un juguete sexual específico, el segundo modo "all:" envía un comando a todos los juguetes remotos.
¿Los datos entrantes se validan correctamente? Como JSON es muy flexible, el código, que espera un número, puede obtener una cadena completa. Si podemos controlar los comandos enviados al juguete, entonces probablemente podamos usar el error del analizador de dongle. En la siguiente diapositiva, el marco naranja muestra dónde se usan los datos de entrada y el azul muestra dónde se verifica.
Este error es que la aplicación no verifica correctamente que la entrada para un comando como vibrar sea en realidad un número entero. En este caso, en el modo "id:", solo se verifica que el índice de intensidad de vibración sea n> = 0, y si pasa un número entero 12 que es mayor que cero, este parámetro pasará la prueba. Incluso si pasa una cadena, es decir, el número entre comillas "12", el sistema lo aceptará. No aceptará solo una cadena en forma de una combinación de números y letras, por ejemplo, "12test".



Como puede ver, esta verificación no nos permite ingresar un comando de texto. Sin embargo, si observa la parte inferior del código, verá la misma verificación, solo que esta vez la aplicación verifica la condición n <0. Ahora, si ingresamos "12test", no pasaremos la prueba, porque la aplicación considerará que la expresión dada como una cadena no es menor que 0. ¡Pero si ingresamos una cadena con una comprobación de desigualdad de la forma! ("12test" <0), el sistema lo considerará verdadero , a pesar de que no es un número entero ni un número, sino una combinación alfanumérica. En esencia, esto significa que podemos ingresar en este comando una cadena arbitraria que se enviará al dongle. Esto nos permite enviar el código de explotación de la misma manera que lo hicimos antes para comprometer el dongle a través del analizador JSON. La única diferencia es que ahora se puede hacer a través de Internet.



Entonces, gracias a un error en la implementación del filtro para verificar los datos entrantes, tuvimos la oportunidad de comprometer remotamente el dongle a través de la aplicación Lovense, a través de la cual, a su vez, podemos romper la computadora del usuario. Piratear un dongle es una gran cosa, pero la condición para el éxito es el consentimiento del compañero para transferir el control remoto sobre el juguete al atacante disfrazado. Esto es conveniente para un ataque dirigido, pero completamente inadecuado para un ataque viral.

Sin embargo, el chat de texto y las imágenes no requieren ningún permiso, lo que permite un ataque XSS clásico mediante el envío de código HTML malicioso en un mensaje de texto de chat. La distribución del virus se vuelve trivial: solo cree la función JavaScript correcta y envíe spam a sus amigos.



En esta etapa, podemos ejecutar el código solo enviando un mensaje y básicamente logramos nuestro objetivo. La carga útil final de XSS funciona así:

  1. Haga todo lo que debería suceder en la máquina de la víctima.
  2. Tome un objeto JavaScript que le permita acceder al chat.
  3. Envíe una carga útil XSS que descargue este script a las computadoras de todos sus amigos.


Por lo tanto, comprometimos cada nodo de la red desde el complemento de arranque a Internet. Ahora puede comprometer cualquier dispositivo desde cualquier dispositivo: creamos un gusano trasero o un virus llamado "gusano anal".



Como prometí, ahora te mostraré un video en vivo. Lo primero que mostraré es usar el conector BTLE para interceptar la conexión entre el complemento de arranque y la máquina virtual de Windows normal a la que está conectado el dongle. Ahora intentaré encender el bootplag. ¡Espero que todos escuchen los sonidos de vibración! (la risa). Así que funcionó, ahora intentaré agregar mi juguete al panel de control de la aplicación. ¡Mira que el programa encontró a Hush, pero espera un minuto! Olvidé iniciar el proceso de jack BTLE. La única razón por la que necesita usar el conector BTLE en este modo es porque facilita la demostración en vivo, pero en la práctica, puede interceptar una conexión existente sin la necesidad de oler. Así que estoy lanzando esto solo para simplificar el experimento. Vamos a repetir todo de nuevo. Ves que la conexión con el juguete está establecida.



El sniffer a la izquierda muestra que encontró esta conexión. Entonces, tenemos una aplicación que está asociada con nuestro juguete sexual. No sé si escuchas que realmente puedo controlar el complemento de arranque (smea mueve el control deslizante hacia arriba, después de lo cual se escucha un sonido amplificador de vibración). Ahora apago esta cosa (mueve el control deslizante hacia abajo, el sonido de la vibración desaparece). Ahora necesito hackear esta conexión. Para hacer esto, copio varios parámetros, los pego en la línea smea @ ubuntu y al final ingreso el parámetro t, un comando para interceptar la conexión.



Si esto funciona, entonces cerrará la conexión con la aplicación. Como puede ver, apareció un mensaje en la ventana de la aplicación que indica que se perdió la conexión con el dispositivo. ¡Gracias BTLE jack por una gran herramienta! El bootlog se desconectó de la aplicación y ahora se controla a través de la máquina virtual de ubuntu. Teóricamente, deberíamos poder hacer que vibre de forma remota. Escribo el equipo Vibrate 20 y, como pueden ver, todo funciona: pudimos controlar de forma remota el bootplag sin la ayuda de la aplicación oficial (aplausos de la audiencia). Ahora lo voy a poner en modo DFU, y si eso funciona, tendré que detener esto. Entro en el comando apropiado y la vibración se detiene.



Ahora tomo mi teléfono inteligente y compruebo si puedo volver a conectar el juguete a través de la aplicación. Entre mis aplicaciones, encuentro la actualización del complemento de firmware y selecciono el DfuTarg de destino, el dispositivo en el que es necesario actualizar el firmware, pero de hecho, introduzco una vulnerabilidad maliciosa en él.



Ya ves cómo va el proceso de actualización. Aparece un mensaje en la pantalla que el firmware del dispositivo se ha actualizado correctamente. Ahora volveré a intentar conectar el bootplag a la aplicación instalada en mi computadora, y verá lo que sucede: ¡el protector de pantalla de ransomware aparece en la pantalla (aplausos de la audiencia)!



“¡Vaya, tu tapón trasero está encriptado! Pague la restauración del acceso a este importante juguete con $ 50 bitcoins en 3 días, de lo contrario, en una semana lo perderá para siempre ”. ¡Así es como funciona!

Entonces, ejecutó el código en el dongle, luego en la computadora y a través de Internet llegó al enchufe de arranque. Como puede ver, en términos de seguridad, este tapón trasero es muy débil, probablemente fue fabricado por Corea del Norte. Viste que tenía una máquina virtual instalada que ejecutaba la aplicación sin estar conectada a un dispositivo de seguridad u otro hardware. Esta máquina virtual acababa de conectarse a Internet y parecía estar conectada a la computadora de mi amigo. Por lo tanto, hemos logrado con éxito la propagación viral del ransomware.

Creo que de todo lo que se ha dicho, se pueden aprender un par de lecciones útiles. Usando este dispositivo como ejemplo, examinamos cuán vulnerable puede ser el mundo de Internet de las cosas. Algunos dispositivos se utilizan como soporte vital, y las personas no se dan cuenta de cuán vulnerables son estas nuevas tecnologías. Hackeando una cosa "inteligente", puede conectar otros dispositivos "inteligentes" en su hogar a través de Internet. Espero que el resultado de mi investigación sea aplicable no solo a los juguetes sexuales. Además, tengo la intención de aprender todo el código de esta cosa, así que únete a mí en Twitter. También voy a publicar mis herramientas en GitHub hoy en caso de que quieras comenzar a hackear tus propios bootloops.



Quiero agradecer a todos mis amigos que me ayudaron en el pentesting y me presentaron al mundo de los enchufes de batalla, siendo homosexuales extremos. No daré nombres, pero Aaron, tú mismo sabes quién eres (risas). Gracias chicos, ¡eso fue increíble!


Un poco de publicidad :)


Gracias por estar con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más materiales interesantes? Apóyenos haciendo un pedido o recomendando a sus amigos, VPS en la nube para desarrolladores desde $ 4.99 , un análogo único de servidores de nivel básico que inventamos para usted: toda la verdad sobre VPS (KVM) E5-2697 v3 (6 núcleos) 10GB DDR4 480GB SSD 1Gbps desde $ 19 o cómo dividir el servidor? (las opciones están disponibles con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).

Dell R730xd 2 veces más barato en el centro de datos Equinix Tier IV en Amsterdam? ¡Solo tenemos 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV desde $ 199 en los Países Bajos!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ¡desde $ 99! Lea sobre Cómo construir un edificio de infraestructura. clase c con servidores Dell R730xd E5-2650 v4 que cuestan 9,000 euros por un centavo?

All Articles