Aspiradores robôs Shark podem ser controlados remotamente por falha ainda sem correção

Uma vulnerabilidade ainda sem correção em aspiradores robôs da Shark pode permitir que invasores controlem dispositivos de outros usuários na mesma região da AWS, acessem a câmera embarcada, movimentem o robô, leiam o mapa da residência e obtenham a senha da rede Wi-Fi em texto claro.

A falha foi divulgada pelo pesquisador que publica sob o nome tokay0, que afirma ter testado o método apenas contra aspiradores comprados por ele. Segundo o pesquisador, a SharkNinja, empresa responsável pelas marcas Shark e Ninja, recebeu o relatório técnico em março, mas a vulnerabilidade continuava sem correção quando os detalhes foram publicados.

O problema está relacionado à forma como certificados de dispositivos eram autorizados no ambiente de nuvem usado pela Shark. Em vez de limitar o certificado ao próprio aspirador que o possuía, a política associada permitia publicar e assinar mensagens destinadas a outros dispositivos atendidos pelo mesmo broker de nuvem.

Na prática, isso transforma certos certificados em uma espécie de chave de acesso regional. Ao extrair o certificado de um Shark RV2320EDUS e apresentá-lo ao broker da Shark na AWS, o pesquisador conseguiu interagir com tópicos de outros aspiradores na mesma região, sem explorar corrupção de memória, sem escalar privilégios no sistema remoto e sem adivinhar senhas.

O ataque explora um erro de autorização em infraestrutura IoT. Em arquiteturas baseadas em AWS IoT, cada dispositivo se comunica com a nuvem por meio de tópicos MQTT e documentos de estado conhecidos como device shadows. Esses documentos armazenam informações de estado e comandos que podem ser sincronizados entre o dispositivo físico e a nuvem.

No caso analisado, o comando executado no aspirador é enviado como um campo comum dentro do shadow do dispositivo. O campo, chamado Exec_Command, é lido pelo daemon de gerenciamento appd e repassado para uma função chamada execute_command. Essa função executa comandos de até 1.000 bytes por meio de popen, uma chamada que permite iniciar processos no sistema operacional.

Com isso, basta publicar uma atualização de shadow contendo o campo Exec_Command no tópico de um dispositivo vulnerável. Se aquele modelo implementar o manipulador do comando, o aspirador executa a instrução recebida.

Segundo tokay0, o certificado pode ser extraído com acesso físico simples ao dispositivo. No modelo Shark RV2320EDUS, a placa principal expõe pinos UART, o console U-Boot não exige senha e a modificação dos argumentos de inicialização com init=/bin/sh permite obter um shell root.

A partir desse acesso local, o pesquisador encontrou a chave e o certificado do dispositivo armazenados como arquivos comuns no diretório /mnt/res/vapp/certs/.

Depois de obter o certificado, ele se inscreveu no tópico $aws/things/# e passou a observar o tráfego que circulava pelo broker, coletando números de série dos aspiradores conectados. O mesmo mecanismo permitia publicar mensagens para outros dispositivos.

A limitação mais relevante identificada foi regional. Os certificados são vinculados à região AWS em que foram provisionados. Assim, uma chave extraída em uma região permite alcançar dispositivos daquela mesma região, mas não aspiradores conectados a outras regiões. Para atingir outra região, seria necessário obter um certificado provisionado ali e associado à mesma política excessivamente permissiva.

O tipo de falha descrito pelo pesquisador corresponde a um problema conhecido em ambientes AWS IoT. O AWS IoT Device Defender, serviço de auditoria de frotas IoT da Amazon, possui uma verificação específica para políticas que concedem permissões amplas demais para publicar ou assinar tópicos como $aws/things/*.

A checagem aparece como IOT_POLICY_OVERLY_PERMISSIVE_CHECK e é classificada como crítica pela AWS. A documentação da Amazon alerta que um certificado comprometido com esse tipo de política pode permitir que um invasor leia ou modifique shadows, jobs ou execuções de jobs de todos os dispositivos cobertos pela permissão.

A mitigação recomendada pela AWS é restringir a política ao próprio dispositivo conectado, usando variáveis como ${iot.Thing.ThingName}. Dessa forma, um aspirador só poderia publicar e assinar tópicos relacionados à sua própria identidade, e não interagir com toda a frota.

No caso da Shark, o problema não está necessariamente em todos os certificados. A análise indica uma diferença importante entre dispositivos que funcionam como “chave” e dispositivos que funcionam como “alvo”.

Um aspirador cujo certificado possui a política incorreta pode ser usado por um invasor para acessar outros dispositivos na mesma região. Já qualquer aspirador que implemente o campo Exec_Command pode ser alvo da execução remota de comandos, mesmo que seu próprio certificado esteja configurado corretamente.

Tokay0 comprovou essa condição ao usar o certificado extraído de um RV2320EDUS para comprometer um AV1102ARUS adquirido por ele como alvo. O certificado do AV1102ARUS estava restrito corretamente e não permitia assinatura curinga de tópicos, mas o firmware do modelo ainda executava comandos recebidos via Exec_Command.

Com essa cadeia, o pesquisador obteve uma reverse shell no aspirador alvo e acessou um feed ao vivo da câmera embarcada enquanto o robô se movimentava pelo ambiente.

O título da publicação original menciona milhões de dispositivos, mas os dados verificados pelo pesquisador são mais específicos.

Durante 24 horas de observação em uma única região AWS, tokay0 contou 1.517.605 números de série únicos de aspiradores Shark. Desse total, 673.816 dispositivos, cerca de 44%, emitiram uma resposta Exec_Response, interpretada por ele como confirmação de que o dispositivo executa o manipulador de comandos.

Esses números não significam que todos os aparelhos tenham sido testados ou comprometidos. Eles representam dispositivos observados respondendo no ambiente monitorado. O pesquisador afirma que o número real de aparelhos afetados pode ser maior, já que a medição ficou limitada a uma região e a uma janela de 24 horas.

A combinação de câmera, mapeamento residencial, controle remoto e exposição de senha Wi-Fi torna a falha particularmente sensível do ponto de vista de privacidade. Aspiradores robôs modernos podem armazenar mapas internos das casas, rotas de limpeza, nomes de redes sem fio e dados operacionais usados pelo aplicativo do fabricante.

Em um cenário de abuso, essas informações poderiam revelar detalhes sobre a residência, hábitos dos moradores e características da rede doméstica. A possibilidade de controlar o movimento do equipamento e acessar imagens ao vivo amplia o risco além de uma falha comum de dispositivo conectado.

De acordo com a linha do tempo publicada por tokay0, o contato inicial com a SharkNinja ocorreu em 1º de março. Os detalhes técnicos foram enviados em 11 de março, e a empresa acusou recebimento no dia seguinte.

Em 27 de abril, a SharkNinja informou que o relatório estava em análise. Em 3 de julho, segundo o pesquisador, a companhia disse que enviaria uma data confirmada de conclusão até sexta-feira, 10 de julho. Nenhum e-mail teria chegado.

Tokay0 publicou os detalhes em 13 de julho. Ele afirma que a fabricante minimizou a gravidade do problema e questionou se a atribuição de um CVE seria apropriada.

A política pública de divulgação de vulnerabilidades da SharkNinja afirma que a empresa fornecerá atualizações regulares até que uma falha reportada seja resolvida. A mesma política pede que pesquisadores mantenham sigilo até que a companhia confirme uma correção ou autorize a divulgação por escrito.

Até a publicação do relato original, a SharkNinja não havia divulgado comunicado público sobre a falha. O The Hacker News informou que entrou em contato com a empresa para obter comentários sobre o status da correção e a linha do tempo de divulgação.

Também não havia CVE atribuído à vulnerabilidade. Tokay0 disse ter solicitado um identificador à CNA of Last Resort da MITRE em 11 de junho, mas não recebeu retorno antes da publicação. Sem CVE, pontuação CVSS ou advisory oficial, equipes de gestão de vulnerabilidades ficam sem um identificador padronizado para rastrear o problema.

Um ponto central da falha é que a correção principal não depende do usuário final nem exige, inicialmente, atualização de firmware no aspirador.

A medida imediata está no ambiente AWS da SharkNinja. Segundo a orientação da AWS para esse tipo de problema, uma política não conforme pode ser substituída por uma versão mais restrita usando CreatePolicyVersion com o parâmetro setAsDefault, tornando a nova política padrão para todos os certificados que a utilizam.

Essa mudança reduziria o alcance dos certificados excessivamente permissivos sem exigir uma atualização local nos robôs. A reemissão correta dos certificados, recomendada por tokay0 em março, seria uma etapa mais longa e estrutural.

Enquanto a SharkNinja não aplicar uma dessas medidas, a única mitigação disponível para donos dos aspiradores é desconectar o equipamento da rede Wi-Fi. Isso impede controle pelo aplicativo, agendamentos e uso de mapas, fazendo o produto operar apenas como um aspirador comum.

Tokay0 afirmou que não publicou seus scripts enquanto a falha permanece ativa. Ele também disse que outros achados eram menores e não justificavam uma publicação separada.

O pesquisador não analisou o restante da linha conectada da SharkNinja, como grills inteligentes e termômetros sem fio para carne, mas afirmou que esses produtos também podem estar vulneráveis. Essa possibilidade não foi confirmada no material divulgado, mas indica que a exposição pode não se limitar aos aspiradores robôs se a mesma arquitetura de provisionamento e autorização tiver sido reutilizada em outros dispositivos IoT da empresa.