Conferência DEFCON 27. Buttplug: True Penetration Testing. Parte 2

Os analistas acreditam que atualmente existem cerca de 10 bilhões de dispositivos do mundo da Internet das Coisas (IoT). Às vezes, esses dispositivos ganham seu lugar no mercado, literalmente subindo no traseiro humano. Como se viu, chips de rádio baratos e de baixa potência não são ótimos apenas para automação residencial - eles também mudam a maneira como as pessoas interagem com brinquedos sexuais. Neste relatório, mergulharemos no mundo das dildônicas da televisão, a tecnologia do sexo a uma distância na qual tátil, temperatura e outras sensações são transmitidas entre os parceiros através de uma linha de comunicação bidirecional. O orador lhe dirá que a segurança dos brinquedos sexuais anal eletrônicos eletrônicos Buttplug pode se opor a um invasor que encontra e explora vulnerabilidades em cada nível da pilha. Por fim, isso permite que os brinquedos sexuais sejam comprometidos,e os dispositivos aos quais eles se conectam.



Um hacker com o apelido smea, ou Smealum, iniciou sua carreira como desenvolvedor de videogames para consoles de jogos como o Nintendo DS, tentando simultaneamente decifrá-los. Em algum momento, os consoles adquiriram sistemas de segurança sérios, e Smea passou do software doméstico para o desenvolvimento de técnicas para quebrá-lo. Smea é conhecido por seu "trabalho" no Nintendo 3DS e no Wii U, embora também tenha contribuído para o desenvolvimento de explorações para os mais populares navegadores da Web e pilhas de virtualização. Provavelmente, agora ele se interessou em invadir plugues anal "inteligentes".

Conferência DEFCON 27. Buttplug: True Penetration Testing. Parte 1



Obviamente, você pode gerenciar as mensagens recebidas mesmo com um comprimento de linha tão curto. Por exemplo, 30 caracteres são suficientes para executar JavaScript malicioso. Este slide mostra um exemplo de tag com um comprimento de 30 caracteres para uma imagem de uma fonte inexistente <img src = a onerror = 'alert (1)'>, que faz com que o aplicativo exiba uma mensagem de erro. Esta mensagem será exibida sempre que o carregamento da imagem for realmente impossível. A captura de tela mostra que a conexão através de um dongle comprometido permite executar JavaScript malicioso.



O limite de 32 caracteres é irritante porque é difícil perceber a carga útil do volume, mas é bem possível. Então, você percebe que comprometemos o aplicativo com sucesso usando uma chave USB e agora estamos no meio do caminho para reverter os hackers, ou seja, comprometer o aplicativo usando um bootplag de hacker. O hacking em um site de computador com dongle pode ocorrer de duas maneiras: através de um computador, você pode comprometer um dongle e, através de um dongle, pode comprometer um computador.

O dongle atua como uma pequena ponte entre o plug de inicialização e o aplicativo. Surge a pergunta: é possível usar a mesma vulnerabilidade para comprometer um aplicativo em um computador diretamente através do bootplag. Infelizmente, a resposta a esta pergunta é negativa e o motivo é que há outra limitação no tamanho dos caracteres da mensagem que vêm do plug-in de inicialização para o aplicativo.



O dongle simplesmente empacota as mensagens do plug-in de inicialização e as envia para o aplicativo, e nesta etapa você pode inserir seu código HTML nelas. No entanto, por vez, ele pode receber uma mensagem com tamanho não superior a 20 bytes, o que não é suficiente para executar um ataque XSS. No entanto, há um erro no firmware do dongle: não há verificação do terminador nulo no final da linha. Portanto, se você puder colocar alguns dados não inicializados após o final de uma sequência de 20 caracteres, poderá enviar ao aplicativo mais de 20 caracteres. Infelizmente, não encontrei uma maneira de usar essa vulnerabilidade na prática, mas vale a pena lembrar essa oportunidade.

Portanto, o problema é que você provavelmente não pode usar esta vulnerabilidade para forçar o aplicativo a executar o código recebido diretamente do plug-in de inicialização. É triste, mas ainda mais triste, se você olhar para o firmware do dongle, poderá ver que, em princípio, ele não faz nada com os dados recebidos, mas simplesmente copia-o para uma nova linha e envia-o ainda mais. Portanto, não poderemos usar sua vulnerabilidade para atacar por meio do transbordamento do buffer de memória. No entanto, se for impossível hackear o aplicativo diretamente do plug-in de inicialização, talvez seja possível fazer isso através da cadeia de plug-dongle-computador de inicialização?
O bom é que o chip dongle permite que você coloque muito mais código do que o necessário para o programa de desenvolvedor Lovense Hush original.



A memória flash do dongle contém uma área reservada para o carregador DFU, uma área para o próprio aplicativo Lovense e uma área SoftDevice fechada para o driver de hardware do chip Nordic Semiconductor BLE. É aqui que o próprio protocolo BLE é processado. Por exemplo, quando um aplicativo deseja enviar uma mensagem BLE para um brinquedo, ele acessa o SoftDevice através de uma chamada SVC. Além dessas três áreas, o dongle possui uma área não utilizada de memória flash com um volume suficientemente grande.
Para encontrar a vulnerabilidade na pilha do BLE SoftDevice, você precisa usar a engenharia reversa, pois ela não é de código aberto. Fiz o mesmo para encontrar a vulnerabilidade do plug-in de firmware. Nesse caso, é muito fácil acompanhar o fluxo de dados, porque também não existe ASLR e é fácil determinar o código que processará essas mensagens.



À direita, no slide, você vê o manipulador de pacotes de entrada GATTC (um perfil de atributos comuns), que, em essência, é um dongle. Em particular, é um manipulador de leitura por tipo de pacotes de resposta. Não sou especialista em dispositivos Bluetooth, mas acho que o ponto aqui é que o dongle lê o tipo de dispositivo periférico e usa manipuladores para todas as variantes dos atributos associados a esse tipo. Isso significa que, de fato, você pode obter mais de um atributo por vez, e o tamanho de cada manipulador de um par de dados de atributo é codificado como um campo dentro do pacote, o que permite gerenciá-los.



O slide mostra uma amostra desse pacote. Os clientes GATT podem enviar um pacote de solicitação de leitura por tipo que contém o tipo e o intervalo de descritores para leitura. Os servidores que respondem à solicitação de leitura por tipo retornam dados associados aos manipuladores dentro do intervalo correspondente a esse tipo. O número de pares de descritores / dados é determinado dividindo o comprimento do pacote restante pelo comprimento do campo do par de descritores / dados, e esse campo é sempre 0x7 ou 0x15.



O slide mostra a operação da função na qual estamos interessados: você vê como o pacote é preenchido com dados de uma matriz de atributos e um tamanho de buffer fixo é alocado para eles. É aqui que o valor do descritor é colocado e o ponteiro associado a ele. Uma matriz de atributos são dados binários que são colocados dentro do buffer em formato hexadecimal. Os dados são destacados em azul e, ao lado, o descritor 0D e o ponteiro associado 00, destacado em laranja. O pacote do segundo e terceiro manipulador é semelhante.

A vulnerabilidade é a seguinte. Se você ler o código à direita, poderá ver o parâmetro attribute_data_length colocado no quadro roxo - o comprimento da mensagem recebida, cujo valor é completamente controlado por um invasor em potencial. Se colocarmos um valor zero, obteremos um loop infinito.



O loop se torna infinito porque o código não verifica se os dados que ele grava no buffer de saída estão dentro desse buffer de saída. Como resultado, obtemos um estouro clássico de buffer de pilha, pois o dispositivo não possui ASLR ou DEP e o código é executado imediatamente.

Atribuindo um valor zero e obtendo um loop infinito, você realmente substitui todos os dados da RAM por lixo. No entanto, esta é uma solução malsucedida, pois é provável que cause uma falha no dispositivo. Mas se você usar o valor 1, isso limitará o número de bytes que estão dentro da mensagem recebida. Isso significa o seguinte - você pode sobrecarregar levemente esse buffer e, em seguida, o buffer, que é baseado na pilha, poderá danificar tudo o que estiver ao lado dele.



Vamos ver como é a pilha antes do estouro. A matriz de atributos do buffer sobre os quais falamos é destacada em amarelo, os registros salvos em azul e o endereço de retorno em laranja. Ao definir o comprimento do atributo como 0x01, podemos causar um estouro de muitos pares de ponteiros de identificador / dados. Os descritores consistem em 2 bytes, mas os dois primeiros bytes do descritor DWORD não são limpos. O buffer que estamos transbordando está na pilha sem cookies, sem ASLR, sem DEP.



Em seguida, testamos o sistema: envie um pacote cheio de bytes 0xDA com um comprimento de atributo 0x01. Acontece que reescrevemos o endereço de retorno com um ponteiro para nossos dados de atributo. Como não há DEP, isso significa que sempre que a função retornar, o código que está dentro do nosso pacote será executado. A única limitação é que precisamos que o endereço de retorno tenha o LSB definido para o bit menos significativo, para que o código seja executado no modo Thumb, porque o processador Cortex M0 não suporta o modo ARM.



Também reescrevemos várias variáveis ​​locais, garantindo que não reescrevemos nada usado no caminho de volta. Basicamente, temos um pacote backdoor clássico. Se você prestar atenção a essa pilha, verá que a reescrita não corresponde à borda, o que causará uma falha no programa.

Há outro requisito em relação aos registros armazenados. Essas são variáveis ​​locais que também são substituídas quando a função retorna.



Um deles é usado para desreferenciar uma borda de 32 bits, e a incompatibilidade de conteúdo com a borda fará com que o programa trave. Portanto, você precisa garantir que save_arg_3 = 0, saved_arg_4 corresponda a DWORD, ou seja, esteja dentro da borda e LSB esteja definido.

Portanto, precisamos garantir que este pacote esteja funcionando. Felizmente, isso é realmente fácil, porque a maneira como o SoftDevice distribui esses pacotes recebidos é um buffer de anel sem requisitos de alinhamento forçado. O Whiteshark tornou possível verificar se o alinhamento do pacote subsequente pode ser controlado alterando o tamanho do pacote anterior.



Amarelo e azul destacaram 2 pacotes enviados antes do envio do pacote de exploração. Isso permite que eu controle o alinhamento do último pacote e faça com que ele não cause uma falha no programa, que é o nosso objetivo.

Percebo que há um obstáculo de engenharia: o Nordic SoftDevice não fornece uma interface para o envio de pacotes BLE brutos. Para contornar isso, você pode usar 2 opções: implementar sua própria pilha BLE ou quebrar alguns ganchos nos pacotes originais. Como sou preguiçoso, escolhi a opção 2.

Esses ganchos são bastante simples, mas requerem alguma engenharia reversa. Os métodos de hackers podem ser encontrados no github, a interface é bastante "suja" e não há garantias de que isso funcione, mas eu fiz. Você ainda está melhor usando o BTLEJack.

void ble_outgoing_hook(uint8_t* buffer, uint8_t length);

Esse ponteiro do SoftDevice é chamado sempre que um pacote BLE é enviado, para que possa ser modificado antecipadamente:

int ble_incoming_hook(uint8_t* buffer, uint16_t length);

Este SoftDevice do gancho chama sempre que um pacote BLE é recebido. O valor de retorno determina se o processamento normal do SoftDevice deve ser ignorado.

int send_packet(void* handle, void* buffer, uint16_t length);

É assim que a função de enviar o pacote bruto para esta conexão BLE se parece.

Como posso processar mais de 4 bytes de código por vez? Precisa enviar alguns pacotes! À direita, você vê o buffer de anel dos pacotes BLE recebidos. O primeiro pacote é mostrado em verde: o código do shell que executa uma chamada de função com parâmetros controlados e depois retorna "clean". O segundo pacote é mostrado em amarelo - este é um buffer de dados que pode ser usado por uma chamada de função. O terceiro pacote é mostrado em azul - um buffer que contém os valores dos parâmetros de chamada de função e laranja - o pacote que inicia a vulnerabilidade usando a instrução C1 E7.



Depois de retornar a função pura, podemos reenviar este pacote. O envio desses 4 pacotes executa qualquer parte arbitrária do código dentro do dongle, e isso pode ser feito repetidamente.



Isso é conveniente porque, dessa maneira, posso realmente chamar o memcpy várias vezes para copiar o binário maior do código do shell na RAM. Em seguida, chamamos essa função para corrigir o código do dongle original na memória e usá-lo para comprometer o aplicativo instalado no computador. Como a carga útil do XSS é grande, não a enviamos, mas a geramos no código do shell no próprio dongle. O código do shell é o seguinte.



Como resultado dessas manipulações, é obtido o seguinte: se podemos controlar o aplicativo, podemos controlar o dongle e o bootplag.



Existem duas maneiras de hackear a seção do dongle de etiqueta: o dongle pode comprometer o brinquedo, e o tag de violação pode comprometer o dongle e o computador. O bônus é que a vulnerabilidade do Nordic BLE está presente não apenas nos produtos Lovense, mas também em todos os dispositivos que usam o SoftDevise S110, S120 ou S130 para o lado do cliente do BLE.

Portanto, temos a oportunidade de comprometer o aplicativo usando o bootplag. Como isso pode ser usado? Ainda estamos apenas executando o código JavaScript dentro do aplicativo Lovense, e a pergunta é: o que isso nos dá? Acontece que o aplicativo lovense.exe roda no Medium IL e no Windows, oferece possibilidades verdadeiramente ilimitadas: mesmo sem privilégios de administrador, você pode acessar arquivos no seu computador, executar código arbitrário, implementar XSS, acessar a rede etc.



A próxima pergunta: se você pode criar um programa de ransomware que não apenas infecte a etiqueta de inicialização, mas também o computador do usuário, existe uma maneira de divulgá-la ainda mais, tornando-a viral? Agora, temos um hack no nível local, mas para um hacker, seria muito mais útil obter controle sobre muitos computadores de usuários via Internet. Como vamos fazer isso? As funções sociais do brinquedo, como bate-papo por vídeo, bate-papo por texto, transferência de imagens e o próprio controle remoto, expandem significativamente a superfície de ataque.

O controle remoto é um excelente objetivo, porque se um desenvolvedor quiser usar um programa proprietário, ele definitivamente terá bugs e vulnerabilidades. Como usá-lo? Por exemplo, você pode enviar a um parceiro um objeto JSON contendo comandos, por exemplo, o comando "Vibrar: 10":

{
cate: "id",
id: {
DEADBABEBEEF: {
v: 10
}
}
}

Nesse caso, o receptor analisa o JSON recebido, gera um comando para o brinquedo e o envia mais adiante, e aqui existem 2 modos. O primeiro modo "id:" envia um comando para um brinquedo sexual específico, o segundo modo "all:" envia um comando para todos os brinquedos remotos.
Os dados recebidos são validados corretamente? Como o JSON é muito flexível, o código, esperando um número, pode obter uma sequência inteira. Se conseguirmos controlar os comandos enviados ao brinquedo, provavelmente poderemos usar o bug do analisador de dongle. No próximo slide, o quadro laranja mostra onde os dados de entrada são usados ​​e o azul mostra onde estão marcados.
Esse erro é que o aplicativo não verifica adequadamente se a entrada para um comando como vibrar é realmente um número inteiro. Nesse caso, no modo "id:", apenas se o índice de intensidade de vibração for n> = 0 será verificado e se você passar um número inteiro 12 maior que zero, esse parâmetro será aprovado no teste. Mesmo se você passar uma string, ou seja, o número entre aspas "12", o sistema a aceitará. Ele não aceitará apenas uma string na forma de uma combinação de números e letras, por exemplo, "12test".



Como você pode ver, essa verificação não nos permite inserir um comando de texto. No entanto, se você olhar na parte inferior do código, verá a mesma verificação, só que desta vez o aplicativo verifica a condição n <0. Agora, se inserirmos "12test", não passaremos no teste, porque o aplicativo considerará que a expressão fornecida como uma string não é menor que 0. Mas se inserirmos uma string com uma verificação de desigualdade no formulário! ("12test" <0), o sistema considerará verdadeiro , apesar de não ser um número inteiro e nem um número, mas uma combinação alfanumérica. Em essência, isso significa que podemos inserir neste comando uma sequência arbitrária que será enviada ao dongle. Isso nos permite enviar o código de exploração da mesma maneira que fizemos antes para comprometer o dongle através do analisador JSON. A única diferença é que agora isso pode ser feito via Internet.



Portanto, graças a um erro na implementação do filtro para verificar os dados recebidos, tivemos a oportunidade de comprometer remotamente o dongle por meio do aplicativo Lovense, através do qual, por sua vez, podemos quebrar o computador do usuário. Hackear um dongle é ótimo, mas a condição para o sucesso é o consentimento do parceiro em transferir o controle remoto do brinquedo para o atacante disfarçado. Isso é conveniente para um ataque direcionado, mas completamente inadequado para um ataque viral.

No entanto, o bate-papo e as imagens de texto não exigem nenhuma permissão, o que permite perfeitamente um ataque clássico ao XSS enviando código HTML malicioso em uma mensagem de texto do bate-papo. A distribuição do vírus se torna trivial: basta criar a função JavaScript correta e enviar spam a seus amigos.



Nesse estágio, podemos executar o código apenas enviando uma mensagem e basicamente alcançamos nosso objetivo. A carga útil final do XSS funciona assim:

  1. Faça tudo o que deve acontecer na máquina da vítima.
  2. Pegue um objeto JavaScript que permita acessar o bate-papo.
  3. Envie uma carga XSS que baixa esse script para os computadores de todos os seus amigos.


Assim, comprometemos todos os nós da rede, desde o plug-in de inicialização até a Internet. Agora você pode comprometer qualquer dispositivo a partir de qualquer dispositivo - criamos um butt worm ou um vírus chamado "ass worm".



Como prometi, agora vou mostrar um vídeo ao vivo. A primeira coisa que mostrarei é usar o conector BTLE para interceptar a conexão entre o plug-in de inicialização e a máquina virtual normal do Windows à qual o dongle está conectado. Agora vou tentar ativar o bootplag - espero que todos vocês ouçam os sons da vibração! (riso). Então, funcionou, agora vou tentar adicionar meu brinquedo ao painel de controle do aplicativo. Veja que o programa encontrou o Hush, mas espere um minuto! Esqueci de iniciar o processo do conector BTLE. O único motivo pelo qual você precisa usar o conector BTLE nesse modo é porque facilita a demonstração ao vivo, mas, na prática, você pode interceptar uma conexão existente sem a necessidade de farejar. Então, estou lançando essa coisa apenas para simplificar o experimento. Vamos repetir tudo de novo. Você vê que a conexão com o brinquedo está estabelecida.



O farejador à esquerda mostra que encontrou essa conexão. Portanto, temos um aplicativo associado ao nosso brinquedo sexual. Não sei se você sabe que eu realmente posso controlar o plug-in de inicialização (smea move o controle deslizante para cima, após o qual um som amplificado de vibração é ouvido). Agora desligo essa coisa (move o controle deslizante para baixo, o som da vibração desaparece). Agora eu preciso invadir essa conexão. Para fazer isso, copio vários parâmetros, colo-os na linha smea @ ubuntu e, no final, insiro o parâmetro t - um comando para interceptar a conexão.



Se isso funcionar, ele eliminará a conexão com o aplicativo. Como você pode ver, uma mensagem apareceu na janela do aplicativo informando que a conexão com o dispositivo foi perdida. Obrigado jack BTLE por uma ótima ferramenta! O log de inicialização desconectou-se do aplicativo e agora é controlado pela máquina virtual do ubuntu. Teoricamente, devemos ser capazes de fazê-lo vibrar remotamente. Eu digito a equipe Vibrate 20 e, como você pode ver, tudo funciona - fomos capazes de controlar remotamente o bootplag sem a ajuda do aplicativo oficial (aplausos da platéia). Agora vou colocá-lo no modo DFU e, se funcionar, terei que parar com isso. Entro no comando apropriado e a vibração para.



Agora pego meu smartphone e verifico se consigo reconectar o brinquedo através do aplicativo. Entre meus aplicativos, encontro a atualização do plug-in de firmware e seleciono o DfuTarg de destino - o dispositivo no qual é necessário atualizar o firmware, mas de fato - introduzo uma exploração maliciosa nele.



Você vê como é o processo de atualização. Uma mensagem aparece na tela informando que o firmware do dispositivo foi atualizado com sucesso. Agora vou tentar novamente conectar o bootplag ao aplicativo instalado no meu computador, e você vê o que acontece: o protetor de tela ransomware aparece na tela (aplausos da platéia)!



“Opa, seu plug anal está criptografado! Pague pela restauração do acesso a este importante brinquedo com US $ 50 bitcoins em 3 dias; caso contrário, em uma semana você o perderá para sempre. ” Veja como funciona!

Então, você executou o código no dongle, depois no computador e pela Internet chegou ao plug-in de inicialização. Como você pode ver, em termos de segurança, esse plug anal é muito fraco, provavelmente foi fabricado pela Coréia do Norte. Você viu que eu tinha uma máquina virtual instalada que executava o aplicativo sem estar conectada a um dongle ou outro hardware. Esta VM estava conectada à Internet e parecia estar conectada ao computador do meu amigo. Portanto, conseguimos com sucesso a disseminação viral do ransomware.

Penso que com tudo o que foi dito, algumas lições úteis podem ser aprendidas. Usando este dispositivo como exemplo, examinamos o quão vulnerável o mundo da Internet pode ser. Alguns dispositivos são usados ​​para suporte à vida e as pessoas não percebem o quão vulneráveis ​​são essas novas tecnologias. Ao invadir uma coisa “inteligente”, você pode conectar outros dispositivos “inteligentes” em sua casa via Internet. Espero que o resultado da minha pesquisa seja aplicável não apenas aos brinquedos sexuais. Além disso, pretendo aprender todo o código para isso, então junte-se a mim no Twitter. Também vou publicar minhas ferramentas no GitHub hoje, caso você queira começar a invadir seus próprios bootloops.



Quero agradecer a todos os meus amigos que me ajudaram nos penteados e me apresentaram o mundo dos plugues de batalha, sendo gays extremos. Eu não vou dar nomes, mas Aaron, você mesmo sabe quem é (risos). Obrigado pessoal, isso foi incrível!


Um pouco de publicidade :)


Obrigado por ficar com a gente. Você gosta dos nossos artigos? Deseja ver materiais mais interessantes? Ajude-nos fazendo um pedido ou recomendando aos seus amigos o VPS baseado em nuvem para desenvolvedores a partir de US $ 4,99 , um analógico exclusivo de servidores básicos que foi inventado por nós para você: Toda a verdade sobre o VPS (KVM) E5-2697 v3 (6 núcleos) 10GB DDR4 480GB SSD 1Gbps de 10GB de US $ 19 ou como dividir o servidor? (as opções estão disponíveis com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).

Dell R730xd 2 vezes mais barato no data center Equinix Tier IV em Amsterdã? Somente nós temos 2 TVs Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV a partir de US $ 199 na Holanda!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de US $ 99! Leia sobre como construir infraestrutura classe c usando servidores Dell R730xd E5-2650 v4 que custam 9.000 euros por um centavo?

All Articles