Treu el certificat del flaix d'un robot aspirador Shark RV2320EDUS i podràs executar ordres de root als aspiradors Shark d'altres persones a la mateixa regió d'AWS: observar la càmera, conduir el robot, llegir el mapa de la casa i anotar la contrasenya del Wi-Fi en text sense format.

Un investigador que publica sota el pseudònim tokay0 va posar el mètode en línia dilluns, després d'haver-ho provat només amb aspiradores que ell mateix va comprar. L'error no es va solucionar llavors.

Diu que SharkNinja, l'empresa darrere de les marques d'electrodomèstics Shark i Ninja, té el seu informe des de març.

La política adjunta a aquest certificat mai no s'ha limitat al dispositiu que el conté. Si el presentes al broker al núvol de Shark, el broker acceptarà tot el que publiquis, adreçat a qualsevol dispositiu al qual serveixi.

Sense corrupció de memòria, sense escalada de privilegis, sense contrasenya per endevinar. L'ordre que s'executa és un camp normal a l'ombra del dispositiu, que és el document d'estat per dispositiu que AWS guarda al núvol.

Mitjançant el certificat d'un RV2320EDUS, l'investigador es va subscriure a $aws/things/# i va observar el trànsit que creuava el broker, que recollia números de sèrie a mesura que avançava. La publicació funciona de la mateixa manera. L'ombra porta un camp Exec_Command que el daemon de gestió appd llegeix i lliura a una funció anomenada execute_command, que executa qualsevol cosa inferior a 1.000 bytes a través de popen.

Envia una actualització ombra que porti aquest camp al tema d'un dispositiu. Si aquest dispositiu implementa el controlador, executa l'ordre.

Va demostrar la ruta creuada del model, que aterrava una shell inversa en un AV1102ARUS que va comprar només com a objectiu, i després, mitjançant aquesta shell, podia obtenir una transmissió en directe de la càmera integrada al model mentre el robot funcionava.

El certificat es treu amb un tornavís. La placa base exposa els pins UART, la consola U-Boot no demana contrasenya i init=/bin/sh als arguments d'arrencada et porta a una shell root, on la clau i el certificat per dispositiu es troben a /mnt/res/vapp/certs/ com a fitxers normals.

Els certificats estan fixats a la seva regió d'AWS, aquí el més semblant a una limitació és que una clau obtinguda en una regió només arriba als dispositius d'aquesta regió. Arribar a una altra regió requereix un altre certificat, proporcionat allà, i que porta la mateixa política trencada.

Amazon té una comprovació d'auditoria per a aquesta forma de política exacta. Device Defender, el servei d'auditoria de la flota d'IoT d'AWS, marca les polítiques de dispositiu que concedeixen publicació o subscripció a $aws/things/* en lloc de fixar el tema al dispositiu que es connecta amb $.

Apareix com a IOT_POLICY_OVERLY_PERMISSIVE_CHECK i AWS el qualifica de crític, i adverteix en la seva documentació que un certificat compromès que porta aquesta política permet que un atacant «llegeixi o modifiqui shadows, tasques o execucions de tasques per a tots els vostres dispositius.»

No tots els certificats són codi maliciós. La clau de l'atacant és un buit, el certificat del qual porta la política trencada. Qualsevol buit que executi Exec_Command és un objectiu, tant si l'abast del seu propi certificat està correctament definit com si no. L'AV1102ARUS és un objectiu i no una clau: el seu certificat estava correctament definit i no podia subscriure's amb comodí. El seu microprogramari era diversos anys més recent.

L'investigador interpreta aquest fet com una correcció de subministrament que mai va arribar als certificats de la flota més antiga. Això explica per què l'intèrpret d'ordres (shell) entre models va funcionar i per què cal matisar la seva afirmació que tots els aspiradors Shark connectats a Internet són vulnerables.

Tot i que el titular de la seva publicació parla de milions, la xifra verificada és més reduïda. Després d'observar una regió d'AWS durant 24 hores, tokay0 va comptabilitzar 1.517.605 números de sèrie únics de Shark; d'aquests, 673.816 (el 44 %) van emetre un Exec_Response, fet que ell considera una confirmació que el dispositiu executa el controlador d'ordres. Es tracta de dispositius observats, no provats ni compromesos, i l'investigador adverteix que la xifra real podria ser superior.

Quatre mesos d'espera

Segons el relat de tokay0, va contactar amb SharkNinja l'1 de març i va enviar els detalls el dia 11. L'empresa va confirmar la recepció l'endemà i, el 27 d'abril, va informar que l'informe estava en revisió. El 3 de juliol van prometre una data de finalització confirmada per al divendres 10 de juliol però, en no rebre cap correu, l'investigador va decidir publicar les seves troballes el 13 de juliol.

Diu que el venedor va minimitzar la gravetat del problema i va qüestionar si era apropiat assignar-hi un identificador CVE.

Pel que fa als informes d'IoT, la política de divulgació de vulnerabilitats de SharkNinja compromet l'empresa a «proporcionar actualitzacions periòdiques fins que es resolgui la vulnerabilitat informada». Alhora, la mateixa política demana als investigadors que mantinguin silenci fins que la companyia confirmi una solució o autoritzi la divulgació per escrit.

Fins dijous, SharkNinja no havia publicat res sobre la fallada. The Hacker News s'ha posat en contacte amb l'empresa per conèixer l'estat del pedaç i el calendari de divulgació, i actualitzarà la informació tan bon punt rebi resposta.

Tampoc hi ha cap CVE. Va demanar un ID al CNA de MITRE d'últim recurs, l'assignador que gestiona vulnerabilitats que cap CNA del proveïdor cobreix, l'11 de juny i no havia rebut res quan va publicar. Ni identificador, ni CVSS, ni avís: res que pogués servir per a un programa de gestió de vulnerabilitats.

La solució és del costat del servidor

La solució no la pot instal·lar el propietari. Es troba al compte d'AWS de SharkNinja, no al microprogramari del robot. Segons la guia de remediació d'AWS, una política no conforme se substitueix mitjançant l'enviament d'una versió amb àmbit CreatePolicyVersion i el senyalador setAsDefault, cosa que fa que aquesta versió sigui operativa per a tots els certificats que utilitzen la política.

No cal desplegar cap microprogramari. La tasca més llarga que hi ha darrere és tornar a emetre els certificats correctament, cosa que tokay0 va recomanar al març.

Fins que SharkNinja no faci una cosa o l'altra, l'única solució que té el propietari és desconnectar l'aspiradora del wifi. Això posa fi al control de les aplicacions, la programació i els mapes, i converteix el producte de nou en una aspiradora.

tokay0 va retenir els seus scripts mentre la falla estava activa. Va considerar que les seves altres troballes eren massa menors per escriure-les per escrit.

Tampoc va examinar mai la resta de la línia connectada de SharkNinja, les graelles intel·ligents i els electrodomèstics de cuina sense fil, que diu que probablement també són vulnerables. Aquests productes provenen de la mateixa empresa, la política de la qual promet actualitzacions periòdiques fins que es resolgui una falla. Quatre mesos després encara no ha arribat.

Resposta de SharkNinja

Després de la publicació d'aquest article, SharkNinja va emetre una declaració. «SharkNinja coneix l'informe de l'investigador sobre alguns dels nostres aspiradors robotitzats i hem solucionat completament la vulnerabilitat identificada», va dir un portaveu. «Ens prenem la privadesa i la seguretat de les dades molt seriosament, i continuem compromesos amb la protecció de la privadesa i la seguretat de les dades dels nostres consumidors.»

L'empresa no va dir quan es va implementar la correcció, si va tornar a emetre els certificats afectats o només va redefinir l'abast de la política que hi havia darrere, ni quants dispositius van quedar exposats mentrestant. Com que la correcció és del costat del servidor, el canvi no porta cap senyal públic que permeti que un tercer en confirmi l'abast o el moment. The Hacker News ha preguntat a tokay0 si encara pot reproduir la ruta d'ordres entre dispositius amb els certificats que té i actualitzarà aquesta història amb el que trobi.