Belkin Wemo Smart Plug V2: el desbordamiento de búfer que no se parcheará

Belkin Wemo Smart Plug V2: el desbordamiento de búfer que no se parcheará

Sello de tiempo: 16 de mayo de 2023 1:59 p.m.
Nodo de origen: 2657924
by

Investigadores de la empresa de seguridad IoT Sternum excavado en un popular enchufe de red de domótica de la conocida marca de dispositivos Belkin.

El modelo que miraron, el Mini enchufe inteligente Wemo (F7C063) aparentemente está llegando al final de su vida útil, pero encontramos muchos de ellos a la venta en línea, junto con consejos e instrucciones detallados en el sitio de Belkin sobre cómo configurarlos.

Por antiguos (en el sentido moderno a corto plazo) que puedan ser, los investigadores notaron que:

Nuestro interés inicial en el dispositivo provino de tener varios de estos en nuestro laboratorio y usarlos en nuestros hogares, por lo que solo queríamos ver cuán seguros (o no) eran para usarlos. [… E]ste parece ser un dispositivo de consumo bastante popular[; basándonos en estos números, es seguro estimar que las ventas totales solo en Amazon deberían ser de cientos de miles.

En pocas palabras, hay muchas personas que ya compraron y enchufaron estas cosas, y las están usando ahora mismo para controlar los enchufes eléctricos en sus hogares.

Un "enchufe inteligente", en pocas palabras, es una toma de corriente que se conecta a una toma de pared existente y que interpone un interruptor controlado por Wi-Fi entre la toma de corriente en la parte frontal de la toma de pared y una toma de corriente de aspecto idéntico en la parte delantera del enchufe inteligente. Piense en ello como un adaptador de corriente que, en lugar de convertir, digamos, un enchufe europeo redondo en uno triangular del Reino Unido, convierte, digamos, un enchufe estadounidense conmutado manualmente en un enchufe estadounidense conmutado electrónicamente que se puede controlar de forma remota a través de una aplicación o una interfaz de tipo web.

La S en IoT…

El problema con muchos de los llamados dispositivos de Internet de las cosas (IoT), como dice el viejo chiste, es que la letra "S" en "IoT" significa seguridad...

… lo que significa, por supuesto, que a menudo no hay tanta seguridad cibernética como cabría esperar, o incluso ninguna.

Como puede imaginar, un dispositivo de automatización del hogar inseguro, especialmente uno que podría permitir que alguien fuera de su casa, o incluso en el otro lado del mundo, encienda y apague los aparatos eléctricos a voluntad, podría generar muchos problemas.

Hemos escrito antes sobre la inseguridad de IoT en una amplia gama de productos diferentes, desde teteras de internet (sí, en serio) que podría filtrar la contraseña de Wi-Fi de su hogar, a las cámaras de seguridad que los delincuentes pueden usar para mantener su ojo en ti en lugar de al revés, a unidades de disco conectadas a la red en riesgo de obtener salpicado por ransomware directamente a través de Internet.

En este caso, los investigadores encontraron un agujero de ejecución remota de código en el Wemo Mini Smart Plug en enero de 2023, lo informaron en febrero de 2023 y recibieron un número CVE en marzo de 2023 (CVE-2023-27217).

Desafortunadamente, aunque es casi seguro que muchos de estos dispositivos están en uso activo en el mundo real, Belkin aparentemente ha dicho que considera que el dispositivo está "al final de su vida útil" y que, por lo tanto, no se reparará el agujero de seguridad.

(No estamos seguros de qué tan aceptable sería este tipo de despido por "final de la vida útil" si el dispositivo tuviera una falla en su circuito eléctrico de 120 V CA o 230 V CA, como la posibilidad de sobrecalentamiento y emisión de químicos nocivos o configuración en llamas, pero parece que las fallas en la electrónica digital de bajo voltaje o en el firmware del dispositivo pueden ignorarse, incluso si pueden provocar que un atacante cibernético encienda y apague el interruptor de alimentación del dispositivo repetidamente a voluntad).

Cuando los nombres amistosos son tu enemigo

El problema que los investigadores descubrieron era un buen viejo desbordamiento del búfer de pila en la parte del software del dispositivo que le permite cambiar el llamado FriendlyName del dispositivo: la cadena de texto que se muestra cuando se conecta a él con una aplicación en su teléfono.

De forma predeterminada, estos dispositivos se inician con un nombre descriptivo similar a Wemo mini XYZ, Donde XYZ denota tres dígitos hexadecimales que suponemos que se eligen de forma pseudoaleatoria.

Eso significa que incluso si posee dos o tres de estos dispositivos, es casi seguro que comenzarán con nombres diferentes para que pueda configurarlos fácilmente.

Pero probablemente querrá cambiarles el nombre más adelante para que sea más fácil distinguirlos en el futuro, asignándoles nombres descriptivos como TV power, Laptop charger y Raspberry Pi server.

Los programadores de Belkin (o, más precisamente, los programadores del código que terminó en estos dispositivos de la marca Belkin, que también podrían haber suministrado software de enchufe inteligente a otras marcas) aparentemente reservaron 68 bytes de almacenamiento temporal para realizar un seguimiento de la nuevo nombre durante el proceso de cambio de nombre.

Pero se olvidaron de verificar que el nombre que proporcionó encajaría en esa ranura de 68 bytes.

En cambio, asumieron que usaría su aplicación de teléfono oficial para realizar el proceso de cambio de nombre del dispositivo y, por lo tanto, podrían restringir la cantidad de datos enviados al dispositivo en primer lugar, para evitar cualquier desbordamiento de búfer que de otro modo podría surgir.

Irónicamente, tuvieron mucho cuidado no solo para mantenerlo en el límite de 68 bytes requerido para que el dispositivo se comporte correctamente, sino incluso para restringirlo a escribir solo 30 caracteres.

Todos sabemos por qué dejar que el lado del cliente realice la verificación de errores, en lugar de verificar (o, mejor aún, también) en el lado del servidor, es una idea terrible:

  • El código del cliente y el código del servidor pueden perder la conformidad. Las futuras aplicaciones cliente podrían decidir que los nombres de 72 caracteres serían una buena opción y comenzar a enviar más datos al servidor de los que puede manejar de manera segura. Los futuros codificadores del lado del servidor podrían notar que nadie parecía usar los 68 bytes completos reservados, y decidir de forma unilteral que 24 deberían ser más que suficientes.
  • Un atacante podría optar por no molestarse con la aplicación. Al generar y transmitir sus propias solicitudes al dispositivo, pasarían por alto cualquier control de seguridad que dependa solo de la aplicación.

Los investigadores rápidamente pudieron probar nombres cada vez más largos hasta el punto de que podían bloquear el dispositivo Wemo a voluntad al escribir sobre el final del búfer de memoria reservado para el nuevo nombre y corromper los datos almacenados en los bytes que siguieron inmediatamente.

Corrompiendo la pila

Desafortunadamente, en un sistema operativo basado en pilas, la mayoría del software termina con sus búferes de memoria temporal basados ​​en pilas dispuestos de manera que la mayoría de estos búferes son seguidos de cerca por otro bloque vital de memoria que le dice al programa adónde ir cuando haya terminado lo que está haciendo ahora mismo.

Técnicamente, estos fragmentos de datos de "dónde ir después" se conocen como direcciones de retorno, y se guardan automáticamente cuando un programa llama a lo que se conoce como funcióno subrutina, que es un fragmento de código (por ejemplo, "imprime este mensaje" o "aparece un cuadro de diálogo de advertencia") que desea poder usar en varias partes de su programa.

La dirección de retorno se registra mágicamente en la pila cada vez que se usa la subrutina, de modo que la computadora puede "desenrollar" automáticamente su ruta para volver al lugar desde donde se llamó a la subrutina, que podría ser diferente cada vez que se activa.

(Si una subrutina tuviera una dirección de retorno fija, solo podría llamarla desde un lugar en su programa, lo que haría inútil molestarse en empaquetar ese código en una subrutina separada en primer lugar).

Como puede imaginar, si pisotea esa dirección de retorno mágica antes de que la subrutina termine de ejecutarse, cuando termine, se "desenrollará" con confianza pero sin saberlo en el lugar equivocado.

Con un poco (o quizás mucha) suerte, un atacante podría ser capaz de predecir de antemano cómo pisotear la dirección de retorno de forma creativa y, por lo tanto, desviar el programa de forma deliberada y maliciosa.

En lugar de simplemente fallar, el programa mal dirigido podría ser engañado para que ejecute el código elegido por el atacante, causando así lo que se conoce como un ejecución remota de código explotar o RCE.

Dos defensas comunes ayudan a proteger contra vulnerabilidades de este tipo:

  • Aleatorización del diseño del espacio de direcciones, también conocido como ASLR. El sistema operativo carga deliberadamente programas en ubicaciones de memoria ligeramente diferentes cada vez que se ejecutan. Esto hace que sea más difícil para los atacantes adivinar cómo desviar los programas defectuosos de una manera que finalmente obtenga y retenga el control en lugar de simplemente bloquear el código.
  • apilar canarios, llamado así por las aves que los mineros solían llevar consigo bajo tierra porque se desmayaban en presencia de metano, proporcionando así una cruel pero efectiva advertencia temprana del riesgo de una explosión. El programa inserta deliberadamente un bloque de datos conocido pero aleatorio justo delante de la dirección de retorno cada vez que se llama a una subrutina, de modo que un desbordamiento del búfer sobrescribirá de manera inevitable y detectable el "canario" primero, antes de que se desborde lo suficiente como para pisotear en la importantísima dirección del remitente.

Para que su hazaña funcione de manera rápida y confiable, los investigadores necesitaban forzar el enchufe Wemo para apagar ASLR, lo que los atacantes remotos no podrían hacer, pero con muchos intentos en la vida real, los atacantes podrían tener suerte, adivinar correctamente. en las direcciones de memoria en uso por el programa, y ​​obtenga el control de todos modos.

Pero los investigadores no necesitaban preocuparse por el problema del canario de pila, porque la aplicación con errores se había compilado a partir de su código fuente con la función "insertar instrucciones de seguridad para verificar el canario" desactivada.

(Los programas protegidos por Canary suelen ser un poco más grandes y lentos que los no protegidos debido al código adicional necesario en cada subrutina para realizar las comprobaciones de seguridad).

¿Qué hacer?

  • Si es propietario de Wemo Smart Plug V2, asegúrese de no haber configurado el enrutador de su hogar para permitir que se acceda al dispositivo desde "afuera", a través de Internet. Esto reduce lo que se conoce en la jerga como su superficie de ataque.
  • Si tiene un enrutador compatible con Universal Plug and Play, también conocido como UPnP, asegúrese de que esté apagado. UPnP hace que sea notoriamente fácil que los dispositivos internos se abran inadvertidamente a personas externas.
  • Si eres programador, evite desactivar las funciones de seguridad del software (como la protección de pila o la comprobación de control de pila) solo para ahorrar unos pocos bytes. Si realmente se está quedando sin memoria, busque reducir su huella mejorando su código o eliminando funciones en lugar de disminuir la seguridad para poder incluir más.

Sello de tiempo:

Mas de Seguridad desnuda