Retire o certificado do firmware de um robô aspirador Shark RV2320EDUS e será possível executar comandos com privilégios de root em aspiradores Shark de outras pessoas na mesma região da AWS.
Com isso, é possível ativar a câmera, conduzir o robô, ler o mapa da casa e capturar a senha do Wi-Fi em texto puro.
O pesquisador, que publica sob o apelido tokay0, divulgou o método na segunda-feira, após testá-lo apenas em aspiradores que comprou por conta própria.
Na época, a falha ainda não tinha patch.
Segundo o pesquisador, a SharkNinja, empresa por trás das marcas Shark e Ninja, recebeu seu relatório em março.
A política vinculada a esse certificado nunca foi limitada ao dispositivo que o carregava.
Ao apresentá-la ao broker de nuvem da Shark, o sistema aceita qualquer conteúdo publicado, desde que endereçado a qualquer dispositivo atendido por ele.
Não houve corrupção de memória, elevação de privilégios nem senha para adivinhar.
O comando executado é um campo comum no shadow do dispositivo, o documento de estado por dispositivo que a AWS mantém na nuvem.
Usando o certificado de um RV2320EDUS, o pesquisador se inscreveu em $aws/things/# e monitorou o tráfego que passava pelo broker, coletando números de série ao longo do caminho.
O envio funciona da mesma forma.
O shadow traz um campo Exec_Command, que o daemon de gerenciamento appd lê e repassa para uma função chamada execute_command, responsável por executar qualquer comando com menos de 1.000 bytes por meio de popen.
Basta enviar uma atualização de shadow com esse campo para o tópico de um dispositivo.
Se esse dispositivo implementar o tratador, o comando é executado.
Ele comprovou o caminho entre modelos ao obter uma shell reversa em um AV1102ARUS que comprou apenas como alvo e, em seguida, usar essa shell para acessar a transmissão ao vivo da câmera embarcada enquanto o robô se movia pela casa.
O certificado pode ser removido com uma chave de fenda.
A placa-mãe expõe pinos UART, o console do U-Boot não pede senha e o parâmetro init=/bin/sh nos argumentos de boot leva a uma shell de root, onde a chave e o certificado por dispositivo ficam em /mnt/res/vapp/certs/, como arquivos comuns.
Os certificados são vinculados à região da AWS, o que aqui funciona como o limite mais próximo de uma restrição.
Uma chave obtida em uma região só alcança os dispositivos daquela região.
Para atingir outra região, é preciso outro certificado, provisionado lá, com a mesma política defeituosa.
A Amazon tem uma verificação de auditoria para esse tipo exato de política.
O Device Defender, serviço de auditoria de frotas IoT da AWS, sinaliza políticas de dispositivo que concedem publish ou subscribe em $aws/things/* em vez de limitar o tópico ao dispositivo que se conecta, usando ${iot:Connection.Thing.ThingName}.
O alerta aparece como IOT_POLICY_OVERLY_PERMISSIVE_CHECK, e a AWS o classifica como crítico.
Na documentação, a empresa adverte que um certificado comprometido com esse tipo de política permite a um atacante “ler ou modificar shadows, jobs ou execuções de jobs de todos os seus dispositivos”.
Nem todo certificado é uma chave-mestra.
Um aspirador cujo certificado carrega a política defeituosa torna-se a chave do atacante.
Qualquer aspirador que execute Exec_Command é um alvo, independentemente de seu próprio certificado estar corretamente limitado.
O AV1102ARUS é um alvo, e não uma chave: seu certificado estava corretamente restrito e não podia fazer wildcard subscribe.
Seu firmware também era vários anos mais novo.
Na leitura de tokay0, isso indica uma correção no processo de provisionamento que nunca chegou aos certificados da frota mais antiga.
Foi por isso que a shell entre modelos funcionou, e é também por isso que a afirmação de que todo aspirador Shark conectado à internet está vulnerável precisa ser dividida em duas partes.
O título da publicação fala em milhões.
O número que ele conseguiu verificar é mais estreito.
Ao observar uma região da AWS por 24 horas, tokay0 contou 1.517.605 números de série exclusivos da Shark, dos quais 673.816, ou 44%, emitiram um Exec_Response, o que ele interpreta como confirmação de que o dispositivo executa o tratador de comandos.
Esses são dispositivos observados respondendo, não dispositivos testados ou comprometidos, e ele afirma que o total real provavelmente é maior.
Quatro meses e contando
Segundo o relato de tokay0 sobre a troca de mensagens, ele contatou a SharkNinja em 1º de março e enviou detalhes em 11 de março.
A empresa confirmou o recebimento no dia seguinte, disse em 27 de abril que o relatório estava em análise e, em 3 de julho, afirmou que enviaria até sexta-feira, 10 de julho, uma data confirmada de conclusão.
Nenhum e-mail chegou.
Ele publicou em 13 de julho.
Diz que a fornecedora minimizou a gravidade e questionou se “um CVE é apropriado”.
Nos relatos sobre IoT, a política pública de divulgação responsável da SharkNinja prevê que a empresa “fornecerá atualizações regulares até que a vulnerabilidade relatada seja resolvida”.
A mesma política pede que os pesquisadores mantenham silêncio até que a empresa confirme uma correção ou autorize a divulgação por escrito.
Até a quinta-feira, a SharkNinja não havia publicado nada sobre a falha.
Também não há CVE.
Ele pediu um identificador em 11 de junho à CNA de último recurso da MITRE, responsável por atribuir vulnerabilidades que não tenham cobertura de uma CNA do fornecedor, e não tinha recebido resposta até a publicação.
Sem identificador, sem CVSS, sem comunicado: nada para um programa de gestão de vulnerabilidades acompanhar.
A correção é no lado do servidor
A correção não depende do usuário instalar nada.
Ela fica na conta AWS da SharkNinja, e não no firmware do robô.
De acordo com a orientação de remediação da AWS, uma política fora de conformidade é substituída pela publicação de uma versão com escopo correto usando CreatePolicyVersion e o sinalizador setAsDefault, o que torna essa versão a ativa para todos os certificados que usam a política.
Não é necessário atualizar firmware.
Reemitir os certificados da forma correta, algo que tokay0 recomendou em março, é o trabalho mais demorado por trás disso.
Até que a SharkNinja faça uma coisa ou outra, a única mitigação disponível para o dono é desconectar o aspirador do Wi-Fi.
Isso encerra o controle pelo app, os agendamentos e os mapas, e devolve ao produto sua função básica de aspirar.
Tokay0 reteve seus scripts enquanto a falha continuar ativa.
Ele considerou suas outras descobertas pouco relevantes para publicação.
Ele também não examinou o restante da linha conectada da SharkNinja, incluindo grelhas inteligentes e termômetros sem fio, que, segundo ele, provavelmente também são vulneráveis.
Esses produtos vêm da mesma empresa cuja política promete atualizações regulares até a resolução de uma falha.
Quatro meses depois, esta ainda não foi resolvida.
Publicidade
Vibecoding cria 10x mais sistemas, 20x mais vulneráveis. E quem ganha com isso é a galera do hacking ético e pentest. Quer ser pago para invadir sistemas? Então você tem que aprender com a Solyd que são os melhores do Brasil. Saiba mais...