Semana 28 de Segurança: invadindo uma casa inteligente

Quais riscos corremos ao instalar o sistema “casa inteligente”? Aquele que aciona lâmpadas e chaleira a partir do aplicativo no smartphone, dentro da rede local e remotamente. Se o gerenciamento de segurança e bloqueio estiver vinculado a um sistema inteligente (como no caso do Amazon Key), ficará claro quais. Caso contrário, teoricamente é possível imaginar o perigo de falha de software de uma máquina de café com um incêndio subsequente. Mas é melhor não fantasiar, mas ter certeza.

Os especialistas da equipe do ICS CERT da Kaspersky Lab decidiram realizar um teste de campo na casa inteligente de um dos funcionários da empresa ( notícias , postagem em blog , artigo técnico). O hacking foi bem-sucedido: a cafeteira não sofreu, mas foi possível ganhar o controle do sistema, embora com algumas suposições (bastante realistas) durante o experimento. Uma das conseqüências desagradáveis ​​desse ataque foi o vazamento de dados pessoais: as coordenadas da casa e, mais triste, a geolocalização do smartphone. No entanto, o experimento terminou com uma nota positiva: o fabricante do sistema doméstico inteligente fechou com sucesso as vulnerabilidades.

Interpretação artística das consequências do hacking

Em um artigo técnico, bastante espaço é dedicado a pontos relativamente chatos, mas importantes: o que NÃO foi bem sucedido em hackers e como a análise do sistema doméstico inteligente foi direcionada a possíveis vulnerabilidades. Antes de iniciar o experimento, os pesquisadores já conheciam o fabricante do sistema. Acabou sendo o Fibaro , que produz uma variedade de dispositivos próprios para uma casa inteligente moderna, além de fornecer integração com dispositivos de terceiros. Além disso, o proprietário deu uma pista importante - um IP permanente para entrar no painel de administração. A propósito, o próprio Fibaro não recomenda abrir o acesso ao controlador via IP - apenas através do sistema em nuvem. Nesse experimento, essa brecha deixada deliberadamente pelo proprietário teve um papel.


Teoricamente, esse sistema pode ser atacado em três direções principais: tente invadir o dispositivo de controle de uma maneira ou de outra, procurar vulnerabilidades na parte da nuvem do serviço ou atacar os dispositivos IoT conectados ao próprio controlador. Neste último caso, é necessário estar próximo deles, para que as duas primeiras opções pareçam mais promissoras.

O próximo passo é analisar o firmware do dispositivo e a WebAPI. Geralmente, nessa análise, tudo termina e as notícias saem no estilo "uma senha com fio é detectada no dispositivo". Mas no caso do Fibaro, não havia falhas óbvias na segurança. Porém, informações úteis foram recebidas sobre a implementação de parte da lógica de controle em PHP. Sem autorização, o controlador fornece apenas o número de série do dispositivo e, para cortar um pedaço de ferro, essas informações são inúteis. Mas, como se viu, permite invadir a parte da nuvem do serviço.


O acesso à nuvem, por sua vez, permite obter backups do banco de dados SQLite contendo todas as configurações do dispositivo sem autorização e fazer upload dos seus. Teoricamente, ignorar a autorização tornou possível (antes de corrigir a vulnerabilidade) fazer o download de cópias de backup de todos os usuários do sistema em nuvem. A análise da base real do dispositivo atacado forneceu acesso a informações privadas, incluindo as coordenadas da casa e o smartphone no qual o aplicativo de controle está instalado. Esse já é um problema sério, pois (com algumas limitações) permite determinar quando o proprietário do sistema não está em casa.

Além disso, o banco de dados tinha informações completas sobre os dispositivos IoT conectados, além de uma senha para acessar as configurações, mas com a adição de "salt". A análise do firmware mostrou que o “sal” não é aleatório, mas é firmemente costurado no dispositivo. Teoricamente, uma senha muito simples pode ser quebrada, mas neste caso não funcionou. A base do SQLite também continha senhas abertas para conexão com outros dispositivos na rede: se essas senhas coincidissem com a principal, o controlador também poderia ser facilmente decifrado.

Mais uma vez, não deu certo: o proprietário do sistema estava familiarizado com as recomendações básicas de segurança e não usava a mesma senha para dispositivos diferentes. Portanto, eu tive que aplicar engenharia social. Uma vulnerabilidade no sistema em nuvem que permite que várias ações sejam executadas sem autorização, sabendo apenas o número de série do dispositivo (que é fornecido "de graça" se houver acesso ao painel de administração de fora), tornou possível o seguinte cenário. Um backup preparado do dispositivo no qual o script malicioso foi incorporado foi carregado na "nuvem". Uma mensagem sobre a necessidade de "atualizar" o dispositivo através dos recursos regulares do sistema em nuvem foi enviada ao proprietário (via email e SMS).

Como o proprietário do sistema sabia sobre o experimento, ele imediatamente percebeu que não era um patch real. Mas, em geral, esse é um cenário muito real quando um usuário recebe uma mensagem plausível por meio de um canal de comunicação familiar; portanto, uma cópia de backup foi instalada. O código malicioso foi executado com direitos do sistema devido a uma supervisão no código PHP, causando a execução do script bash:


Aqui, o parâmetro definido pelo usuário (em condições normais, mesmo o administrador do sistema não possui privilégios de superusuário no dispositivo) entra no argumento da linha de comando. A verificação insuficiente dos argumentos nos permitiu executar código arbitrário com privilégios de root e finalmente obter controle total sobre o dispositivo. Paralelamente, a possibilidade de injeção de SQL foi encontrada, mas não utilizada:


Os pesquisadores não planejavam quebrar uma cafeteira em uma casa real, então mudaram a melodia do despertador como um "olá". As vulnerabilidades mencionadas no sistema em nuvem e no código do controlador foram fechadas. Por razões óbvias, métodos específicos de contornar a proteção não são divulgados em um artigo técnico - para evitar o uso por invasores reais em dispositivos que ainda não foram atualizados. Mas neste experimento, o que geralmente é deixado de fora das manchetes é bem mostrado nesse experimento: existem muitas maneiras de investigar a proteção de dispositivos, a maioria das quais termina em nada. Na experiência real, o fabricante do dispositivo e seu proprietário conseguiram evitar os erros de segurança mais simples, como senhas incorporadas e reutilizáveis. No entanto, foi identificado um número suficiente de problemas que poderiam levar a pelo menos um vazamento de dados privados e, na pior das hipóteses, ignorar os sistemas de segurança.

Isenção de responsabilidade: as opiniões expressas neste resumo nem sempre coincidem com a posição oficial da Kaspersky Lab. Caros editores, geralmente recomendam tratar qualquer opinião com ceticismo saudável.