Nós hackeamos a Apple por 3 meses: Veja o que encontramos

Views: 727

Entre o período de 6 de julho a 6 de outubro, eu mesmo, Brett Buerhaus, Ben Sadeghipour, Samuel Erb e Tanner Barnes trabalharam juntos e hackearam o programa de recompensa de bugs da Apple.

• Sam Curry (@samwcyo)
• Brett Buerhaus (@bbuerhaus)
• Ben Sadeghipour (@nahamsec)
• Samuel Erb (@erbbysam)
• Tanner Barnes (@_StaticFlow_)

Durante nosso engajamento, encontramos uma variedade de vulnerabilidades em partes centrais de sua infraestrutura que teriam permitido que um invasor comprometesse totalmente os aplicativos de clientes e funcionários, lançasse um worm capaz de assumir automaticamente a conta do iCloud da vítima, recuperasse o código fonte para projetos internos da Apple, comprometesse totalmente um software de armazém de controle industrial usado pela Apple e assumisse as sessões dos funcionários da Apple com a capacidade de acessar ferramentas de gerenciamento e recursos sensíveis.

Foram descobertas 55 vulnerabilidades com 11 gravidades críticas, 29 de alta gravidade, 13 de média gravidade e 2 de baixa gravidade. Essas gravidades foram avaliadas por nós para fins de resumição e dependem de um mix de CVSS e nossa compreensão do impacto relacionado ao negócio.

A partir de 6 de outubro de 2020, a grande maioria desses achados foram corrigidos e creditados. Eles eram normalmente remediados dentro de 1-2 dias úteis (com alguns sendo fixados em apenas 4-6 horas).

Introdução

Enquanto rolava pelo Twitter por volta de julho, notei um post no blog sendo compartilhado onde um pesquisador recebeu US$ 100.000 da Apple por descobrir um bypass de autenticação que lhes permitiu acessar arbitrariamente qualquer conta de cliente da Apple. Isso foi surpreendente para mim, pois entendi anteriormente que o programa de recompensa de bugs da Apple apenas concedia vulnerabilidades de segurança que afetavam seus produtos físicos e não pagava por problemas que afetavam seus ativos na Web.https://platform.twitter.com/embed/index.html?dnt=true&embedId=twitter-widget-0&frame=false&hideCard=false&hideThread=false&id=1266755207402143746&lang=en&origin=https%3A%2F%2Fsamcurry.net%2Fhacking-apple%2F&theme=light&widgetsVersion=ed20a2b%3A1601588405575&width=550px

Depois de terminar o artigo, fiz uma rápida pesquisa no Google e encontrei sua página de programa onde detalhava que a Apple estava disposta a pagar por vulnerabilidades “com impacto significativo para os usuários” independentemente de o ativo estar ou não explicitamente listado no escopo.

Isso me chamou a atenção como uma oportunidade interessante para investigar um novo programa que parecia ter um amplo escopo e funcionalidade divertida. Na época eu nunca tinha trabalhado no programa de recompensa de bugs da Apple, então eu realmente não tinha ideia do que esperar, mas decidi por que não tentar a minha sorte e ver o que eu poderia encontrar.

Para tornar o projeto mais divertido, enviei algumas mensagens para hackers com quem trabalhei no passado e perguntei se eles gostariam de trabalhar juntos no programa. Mesmo que não houvesse garantia sobre pagamentos nem compreensão de como o programa funcionava, todos disseram que sim, e começamos a hackear a Apple.

Reconhecimento

O primeiro passo para hackear a Apple foi descobrir o que realmente visar. Ben e Tanner eram os especialistas aqui, então eles começaram a descobrir o que toda a Apple possuía que era acessível para nós. Todos os resultados de sua digitalização foram indexados em um painel que incluía o código de status HTTP, cabeçalhos, corpo de resposta e captura de tela dos servidores web acessíveis sob os vários domínios de propriedade da Apple a que nos referiríamos durante o contrato.

Para ser breve: a infraestrutura da Apple é enorme.

Eles possuem toda a gama de IP 17.0.0.0/8, que inclui 25.000 servidores web com 10.000 deles sob apple.com, outros 7.000 domínios únicos, e para completar tudo, seu próprio TLD (dot apple). Nosso tempo foi gasto principalmente na faixa ip 17.0.0.0/8, .apple.com e .icloud.com desde então foi onde a funcionalidade interessante parecia estar.

Depois de fazer uma listagem de todos os servidores web, começamos a executar diretórios brutos forçando os mais interessantes.

Algumas das descobertas imediatas da varredura automatizada foram…

• Servidores VPN afetados pelo Cisco CVE-2020-3452 Local File Read 1day (x22)
• Token de acesso do Spotify vazado dentro de uma mensagem de erro em uma página quebrada

As informações obtidas por esses processos foram úteis para entender como a autorização/autenticação funcionava na Apple, quais aplicativos de cliente/funcionário existiam, quais ferramentas de integração/desenvolvimento eram usadas e vários comportamentos observáveis, como servidores web consumindo certos cookies ou redirecionando para determinados aplicativos.

Depois que todos os scans foram concluídos e sentimos que tínhamos um entendimento geral da infraestrutura da Apple, começamos a direcionar servidores web individuais que se sentiam instintivamente mais propensos a serem vulneráveis do que outros.

Isso começou uma série de descobertas que continuaram ao longo de nosso engajamento e aumentaram progressivamente nossa compreensão do programa da Apple.

Vulnerabilidades Descobertas

programa 102550100 EntradasBusca:

ID do relatório	Data	Título	Gravidade
741765282	7/26/2020	Execução remota de código via bypass de autorização e autenticação	Crítico
747008210	9/17/2020	O bypass de autenticação via Permissões Mal configuradas permite acesso ao administrador global	Crítico
743305978	8/11/2020	Injeção de comando via argumento de nome de arquivo não oficializado	Crítico
744391544	8/21/2020	Execução remota de código via ferramenta de administrador secreta e exposta vazada	Crítico
741014809	7/18/2020	O Vazamento de Memória leva ao Compromisso de Conta de Funcionários e Usuários, permitindo acesso a vários aplicativos internos	Crítico
742879257	8/6/2020	Injeção vertica SQL via parâmetro de entrada não-nitizado	Crítico
742693737	8/5/2020	Wormable Armazenado XSS permite que o invasor comprometa totalmente a conta do iCloud da vítima	Crítico
743695576	8/14/2020	Wormable Armazenado XSS permite que o invasor comprometa totalmente a conta do iCloud da vítima	Crítico
742909161	8/7/2020	Resposta completa O SSRF permite que o Invasor leia o código fonte interno e os recursos protegidos de acesso	Crítico
745400606	9/1/2020	Blind XSS permite que o invasor acesse o portal de suporte interno para rastreamento de problemas de clientes e funcionários	Crítico

VEJA A LISTA COMPLETA NO SITE DE ORIGEM

Write-ups de vulnerabilidade

Não podemos escrever sobre todas as vulnerabilidades que descobrimos, mas aqui está uma amostra de algumas das vulnerabilidades mais interessantes.

1. Compromisso total do Programa de Educadores Distintos da Apple via Autenticação e Bypass de Autorização
2. Compromisso completo do aplicativo DELMIA Apriso via Bypass de Autenticação
3. Vulnerabilidades de script de sites cross-site armazenadas wormable permitem que o invasor roube dados do iCloud através de um e-mail modificado
4. Injeção de Comando no ePublisher do autor
5. SSRF de resposta completa no iCloud permite que o Atacante recupere o Código Fonte da Apple
6. Acesso ao painel de depuração de nova administração via vazamento de erro de DESCANSO
7. Chaves secretas AWS via PhantomJS iTune Banners e Título do Livro XSS
8. Heap Dump no Apple eSign permite que o invasor comprometa várias ferramentas externas de gerenciamento de funcionários
9. Processamento de entidade externa XML para SSRF cego na API de Gerenciamento Java
10. Injeção GBI Vertica SQL e API GSF Exposta
11. Várias vulnerabilidades do IDOR
12. Várias vulnerabilidades cegas xss

Compromisso total do Programa de Educadores Distintos da Apple via Autenticação e Bypass de Autorização

Um dos primeiros serviços que passamos o tempo hackeando foi o site “Apple Distinguished Educators”. Este foi um fórum Jive somente para convites onde os usuários poderiam autenticar usando sua conta apple. Algo interessante sobre este fórum foi que algumas das principais funcionalidades Jive para se registrar no aplicativo foram portadas através de uma página personalizada de middleware construída pela Apple, a fim de conectar seu sistema de autenticação (IDMSA) ao fórum Jive subjacente que normalmente usava autenticação de nome de usuário/senha.

Isso foi construído para permitir que os usuários usem facilmente sua conta apple já existente para autenticar no fórum e não ter que lidar com a criação de uma conta de usuário adicional. Bastaria usar o “Sign In With Apple” e estar logado no fórum.

A página de desembarque para usuários que não tinham permissão para acessar o fórum era um portal de aplicativos onde você forneceu informações sobre si mesmo que foram avaliadas pelos moderadores do fórum para aprovação.

Quando você enviou um pedido para usar o fórum, você forneceu quase todos os valores da sua conta como se estivesse se inscrevendo no fórum Jive normalmente. Isso permitiria que o fórum Jive soubesse quem você era baseado no seu cookie IDMSA, uma vez que vinculou seu endereço de e-mail pertencente à sua conta da Apple ao fórum.

Um dos valores que estava escondido na página dentro do aplicativo para se cadastrar para usar o fórum era um campo de “senha” com o valor “###INvALID#%!3“. Quando você enviou seu aplicativo que incluía seu nome de usuário, nome e sobrenome, endereço de e-mail e empregador, você também estava enviando um valor de “senha” que foi então secretamente vinculado à sua conta originada de um campo de entrada oculto na página.

<div class="j-form-row">
<input id="password" type="hidden" value="###INvALID#%!3">
<div id="jive-pw-strength">
...

Depois de observar o campo de senha padrão oculto, imediatamente tivemos a ideia de encontrar uma maneira de autenticar manualmente o aplicativo e acessar uma conta aprovada para o fórum em vez de tentar fazer login usando o sistema “Faça login com a Apple”. Investigamos isso porque a senha era a mesma para cada um de nós em nossos registros separados.

Se alguém tivesse se aplicado usando este sistema e existisse funcionalidade onde você pudesse autenticar manualmente, você poderia simplesmente fazer login em sua conta usando a senha padrão e ignorar completamente o login “Entrar com a Apple”.

De uma rápida olhada, não parecia que você poderia autenticar manualmente, mas depois de algumas pesquisas no Google identificamos um ponto final “cs_login” que era destinado ao login com um nome de usuário e senha para aplicativos Jive. Quando formamos manualmente a solicitação HTTP de teste para autenticar no aplicativo Apple Distinguished Developers, descobrimos que ele tentou nos autenticar exibindo um erro de senha incorreto. Quando usamos nossas próprias contas que tínhamos aplicado anteriormente, o aplicativo errou e não nos permitiu autenticar, pois ainda não estávamos aprovados. Teríamos que encontrar o nome de usuário de um membro já aprovado se quiséssemos autenticar.

Neste ponto, carregamos a solicitação HTTP no intruso do Burp Suite e tentamos forçar nomes de usuário entre 1 e 3 caracteres através do login e senha padrão.

Depois de cerca de dois minutos recebemos uma resposta 302 indicando um login bem-sucedido para um usuário com um nome de usuário de 3 caracteres usando a senha padrão que encontramos anteriormente. Nós estávamos dentro! A partir deste ponto, nosso próximo objetivo era autenticar como alguém com permissões elevadas. Tiramos algumas capturas de tela do nosso acesso e clicamos na lista “Usuários” para ver quais usuários eram administradores. Entramos na primeira conta que vimos na lista na tentativa de provar que poderíamos alcançar a execução remota de código através da funcionalidade administrativa, no entanto, ainda havia alguns bloqueios à frente.

Ao tentar navegar para “/admin/” (o console administrador Jive) como a conta de administração, o aplicativo redirecionou para o login como se ainda não estivéssemos autenticados. Isso foi estranho, pois era um comportamento personalizado para a aplicação jive e nenhum de nós tinha observado isso antes. Nosso palpite era que a Apple havia restringido o console de administração com base no endereço IP para garantir que nunca houvesse um compromisso total do aplicativo.

Uma das primeiras coisas que tentamos foi usar o cabeçalho X-Forwarded-For para contornar a restrição hipotética, mas infelizmente isso falhou. A próxima coisa que tentamos foi carregar uma forma diferente de “/administrador/” caso o aplicativo tivesse listas negras específicas de caminho para acessar o console administrador.

Depois de apenas mais alguns pedidos HTTP, descobrimos que “GET /admin;/” permitiria que um invasor acessasse o console de administração. Automatizamos esse bypass configurando uma regra do Burp Suite que alterou automaticamente “GET/POST /admin/” para “GET/POST /admin;/” em nossos pedidos HTTP.

Quando finalmente navegamos e carregamos o console de administração, ficou imediatamente claro que algo não estava certo. Não tivemos acesso à funcionalidade normal que demonstraria a execução remota de código (não havia templating, upload de plugin, nem a funcionalidade de depuração administrativa padrão).

Neste ponto, paramos para pensar onde estávamos e percebemos que a conta a que autenticamos pode não ser o administrador “núcleo” do aplicativo. Fomos em frente e autenticamos para mais 2-3 contas antes de finalmente autenticar como o administrador principal e ver funcionalidade que permitiria a execução remota de código.

Um invasor poderia (1) contornar a autenticação autenticando manualmente usando uma funcionalidade de login padrão oculto, então (2) acessar o console de administração através do envio de um caminho HTTP modificado na solicitação e, finalmente(3), comprometer completamente o aplicativo usando a de muitas funcionalidades “assadas em RCE” como upload de plugin, templating ou gerenciamento de arquivos.

No geral, isso teria permitido que um atacante…

• Execute comandos arbitrários no webserver ade.apple.com
• Acesse o serviço LDAP interno para gerenciar contas de usuário
• Acesse a maior parte da rede interna da Apple

Neste ponto, terminamos o relatório e submetemos tudo.

Compromisso completo do aplicativo DELMIA Apriso via Bypass de Autenticação

Algo que tínhamos pensado muito enquanto hackeávamos a Apple era se eles tinham ou não algum serviço acessível relacionado à fabricação e distribuição de seus produtos. Como se vê, havia um aplicativo chamado “DELMIA Apriso” que era uma “Global Manufacturing Suite” de terceiros que forneceu o que parecia ser várias soluções de armazém.

Infelizmente, não parecia haver muita interação disponível para a tecnologia, pois você só poderia “login” e “redefinir senha” das interfaces disponíveis.

Depois de tentar encontrar vulnerabilidades no número limitado de páginas, algo estranho aconteceu: fomos autenticados como um usuário chamado “Apple No Password User” com base em uma barra que apareceu na parte superior direita do site.

O que aconteceu foi que, clicando em “Redefinir senha”, fomos temporariamente autenticados como um usuário que tinha “Permissão” para usar a página.

O modelo de autenticação do aplicativo funcionou enquanto os usuários tinham permissões específicas para usar páginas específicas. A página “redefinir senha” contava como uma página em si, então, para nos permitir usá-la, o aplicativo nos registrou automaticamente em uma conta capaz de usar a página.

Tentamos uma variedade de coisas para elevar nossas permissões, mas não chegamos a lugar algum por muito tempo. Depois de um tempo, enviamos uma solicitação HTTP para um ponto final da OAuth na tentativa de gerar um portador de autorização que poderíamos usar para explorar a API. Isso foi um sucesso!

Nossa conta de usuário, mesmo que suas permissões fossem destinadas a ser limitadas à autorização e redefinição de nossa senha, poderia gerar um portador que tinha permissão para acessar a versão API do aplicativo.

Agora conseguimos explorar a API e esperamos encontrar algum problema de permissão que nos permita comprometer alguma parte do aplicativo. Felizmente, durante nosso processo de reconhecimento, encontramos uma lista de pedidos de API para o aplicativo.

Infelizmente não tivemos acesso à maioria das chamadas de API, mas algumas seções como “Operações” divulgaram um número maciço de funcionalidades disponíveis.

Se você atingir o ponto final “/Apriso/HttpServices/api/platform/1/Operations”, ele retornará uma lista de quase 5.000 chamadas diferentes de API. Nenhum deles exigiu autenticação além do portador de autorização inicial que enviamos inicialmente. As operações aqui divulgadas incluíam coisas como…

• Criando e modificando remessas
• Criando e modificando os dias de pagamento dos funcionários
• Criando e modificando informações de inventário
• Validação de crachás de funcionários
• Centenas de operações relacionadas a armazéns

O que mais prestamos atenção foi “APL_CreateEmployee_SO”.

Você pode enviar uma solicitação GET para as operações específicas e receber os parâmetros esperados usando o seguinte formato:

GET /Apriso/HttpServices/api/platform/1/Operations/operation HTTP/1.1
Host: colormasters.apple.com

Com a seguinte resposta HTTP:

{
  "InputTypes": {
    "OrderNo": "Char",
    "OrderType": "Integer",
    "OprSequenceNo": "Char",
    "Comments": "Char",
    "strStatus": "Char",
    "UserName": "Char"
  },
  "OutputTypes": {},
  "OperationCode": "APL_Redacted",
  "OperationRevision": "APL.I.1.4"
}

Demorou um pouco, mas depois de um tempo percebemos que para realmente chamar a API você tinha que enviar uma solicitação POST com dados JSON no seguinte formato:

{
  "inputs": {
    "param": "value"
  }
}

O formato acima (após o fato) parece muito simples e fácil de entender, mas no momento do hacking não tínhamos absolutamente nenhuma ideia de como formar essa chamada. Eu até tentei enviar e-mails para a empresa que forneceu o software perguntando como você deveria formar essas chamadas de API, mas eles não responderam ao meu e-mail porque eu não tinha uma assinatura do serviço.

Passei quase 6 horas tentando descobrir como formar a chamada acima da API, mas depois que descobrimos, foi uma navegação muito suave. A função “criar funcionário” exigia vários parâmetros que dependiam de UUIDs, mas conseguimos recuperá-los através das outras “Operações” e preenchê-los à medida que avançamos.

Cerca de duas horas a mais, finalmente formamos o seguinte pedido de API:

POST /Apriso/HttpServices/api/platform/1/Operations/redacted HTTP/1.1
Host: colormasters.apple.com
Authorization: Bearer redacted
Connection: close
Content-Type: application/json
Content-Length: 380
{
  "inputs": {
    "Name": "Samuel Curry",
    "EmployeeNo": "redacted",
    "LoginName": "yourloginname123",
    "Password": "yourpassword123",
    "LanguageID": "redacted",
    "AddressID": "redacted",
    "ContactID": "redacted",
    "DefaultFacility": "redacted",
    "Department": "",
    "DefaultMenuItemID": "redacted",
    "RoleName": "redacted",
    "WorkCenter": ""
  }
}

Depois que enviamos esta chamada de API, agora podemos autenticar como um administrador global para o aplicativo. Isso nos deu total supervisão ao software de gerenciamento de armazéns e provavelmente RCE através de alguma funcionalidade aceita.

Havia centenas de funcionalidades diferentes que teriam causado a divulgação maciça de informações e sido capazes de interromper o que parecia ser uma aplicação um tanto crucial usada para o inventário e gerenciamento de armazéns.

Vulnerabilidades de script de sites cross-site armazenadas wormable permitem que o invasor roube dados do iCloud através de um e-mail modificado

Uma das partes centrais da infraestrutura da Apple é sua plataforma iCloud. Este site funciona como um mecanismo de armazenamento automático para fotos, vídeos, documentos e dados relacionados a aplicativos para produtos Apple. Além disso, esta plataforma fornece serviços como Mail e Find my iPhone.

O serviço de e-mail é uma plataforma de e-mail completa onde os usuários podem enviar e receber e-mails semelhantes ao Gmail e ao Yahoo. Além disso, há um aplicativo de e-mail tanto no iOS quanto no Mac que é instalado por padrão nos produtos. O serviço de e-mail está hospedado em “www.icloud.com” ao lado de todos os outros serviços, como armazenamento de arquivos e documentos.

Isso significava, do ponto de vista dos atacantes, que qualquer vulnerabilidade de script de sites entre sites permitiria que um invasor recuperasse qualquer informação que quisesse do serviço iCloud. Começamos a procurar por problemas de scripting entre sites neste momento.

A forma como o aplicativo de correio funciona é muito simples. Quando o serviço recebe um e-mail e um usuário o abre, os dados são processados em uma bolha JSON que é higienizada e separada pelo JavaScript e, em seguida, exibida ao usuário.

Isso significa que não há processamento lateral do servidor dos e-mails em termos de saneamento de conteúdo, e que toda a funcionalidade real para renderizar e processar o corpo de e-mail está dentro do JavaScript onde é feito o lado do cliente. Isso não é necessariamente uma coisa ruim, mas simplifica o processo de identificação do XSS entendendo o que especificamente precisaremos quebrar dentro do código fonte.

XSS armazenado via confusão de tag de estilo

Ao testar essa funcionalidade, uma das coisas com as quais eu eventualmente mexi foi a tag “<style>”. Esta tag é interessante, pois o DOM só cancelará este elemento com uma tag final “</style>”. Isso significa que se escrevemos “<style><script>alert(1)</script></style>” e ele foi totalmente renderizado no DOM, não haveria alerta, pois o conteúdo da tag é estritamente CSS e a tag de script foi recheada dentro da tag e não além da tag de fechamento.

Do ponto de vista da higienização, as únicas coisas com que a Apple precisaria se preocupar aqui seria uma tag de estilo final, ou se houvesse informações confidenciais na página, injeção de CSS via chaining de importação.

Decidi focar em tentar sair da tag de estilo sem que a Apple percebesse, já que seria um XSS muito simples, se possível.

Eu brinquei com isso por um tempo tentando várias permutações e eventualmente observei algo interessante: quando você tinha duas tags de estilo dentro do e-mail, o conteúdo das tags de estilo seria concateado em uma tag de estilo. Isso significava que se pudéssemos colocar “</sty” na primeira tag e “le>” na segunda tag, seria possível enganar a aplicação para pensar que nossa tag ainda estava aberta quando realmente não estava.

Enviei a seguinte carga para testar se funcionaria:

<style></sty</style>
<style>le><script>alert(1)</script></style>

O e-mail apareceu na minha caixa de entrada. Eu cliquei nele. Houve um alerta! Tinha funcionado!

O DOM da página incluiu o seguinte:

<style></style><script>alert(1)</script></style>

Uma vez que o aplicativo de e-mail está hospedado em “www.icloud.com” isso significava que tínhamos permissões do navegador para recuperar as respostas HTTP para as APIs correspondentes para o serviço iCloud (se pudéssemos entrar no JavaScript para alcançá-los).

Uma explicação da carga acima é a seguinte:

Neste ponto decidimos que a prova mais legal do conceito seria algo que rouba todas as informações pessoais da vítima (fotos, informações do calendário e documentos) e encaminha a mesma exploração para todos os seus contatos.

Construímos um PoC puro que devolveria os URLs de fotos da API do iCloud, as colocaria em tags de imagem e, em seguida, anexaria uma lista de contatos para a conta do usuário abaixo delas. Isso demonstrou que era possível recuperar os valores, mas para exfiltrar eles teríamos que contornar um CSP, o que significava que não havia pedidos HTTP de saída fáceis para nada além de “.apple.com” e alguns outros domínios.

Felizmente para nós, o serviço é um cliente de correio. Podemos simplesmente usar o JavaScript para invocar um e-mail para nós mesmos, anexar os URLs e contatos de fotos do iCloud do iCloud e, em seguida, disparar todas as URLs de fotos e documentos do iCloud assinados pela vítima.

O vídeo a seguir demonstra uma prova de conceito, enquanto as fotos da vítima são roubadas. Em um cenário de exploração completa realizado por uma parte maliciosa, um invasor poderia silenciosamente roubar todas as fotos, vídeos e documentos da vítima, em seguida, encaminhar o e-mail modificado para a lista de contatos da vítima e worm a carga de scripts cross-site contra o serviço de correio iCloud.

https://youtube.com/watch?v=jclY-s2kJ7E%3Ffeature%3Doembed

XSS armazenado via Hyperlink Confusion

Mais tarde, encontrei uma segunda vulnerabilidade de scripting entre sites afetando o e-mail de forma semelhante.

Uma coisa que eu sempre vou verificar com este tipo de aplicativos semi-HTML é como eles lidam com hiperlinks. Parece intuitivo transformar automaticamente uma URL não marcada em um hiperlink, mas pode ficar bagunçada se não estiver sendo higienizada corretamente ou for combinada com outras funcionalidades. Este é um lugar comum para procurar xss devido à dependência de regex, innerHTML, e todos os elementos aceitos que você pode adicionar ao lado da URL.

A segunda peça de funcionalidade interessante para este XSS é a remoção total de determinadas tags como “<script>” e “<iframe>”. Este é limpo porque certas coisas dependerão de caracteres como espaço, guias e novas linhas, enquanto o vazio deixado pela tag removida pode fornecer esses caracteres sem dizer ao analisador JavaScript. Essas indiferenças permitem que os atacantes confundam o aplicativo e se esgueiram em caracteres maliciosos que podem invocar XSS.

Brinquei com essas duas funcionalidades por um tempo (hiperlinking automático e a remoção total de determinadas tags) até decidir combinar as duas e tentar ver como elas se comportavam juntas. Para minha surpresa, a sequência seguinte quebrou a funcionalidade de hiperlinking e confundiu o DOM:

https://www.domain.com/abc#<script></script>https://domain.com/abc

Depois de enviar o acima por si só dentro de um e-mail, o conteúdo foi analisado para o seguinte:

<a href="https://www.domain.com/abc#<a href=" https:="" www.domain.com="" abc="&quot;" rel="noopener noreferrer">https://www.domain.com/abc</a>

Isso foi muito interessante de ver inicialmente, mas explorá-lo seria um pouco mais difícil. É fácil definir os atributos dentro da tag (por exemplo, src, onmouseover, onclick, etc.) mas fornecer os valores seria difícil, pois ainda tínhamos que combinar o regex url para que ele não escapasse da funcionalidade automática de hiperlinking. A carga que eventualmente funcionou sem enviar cotações únicas, cotações duplas, parênteses, espaços ou backticks foi o seguinte:

https://www.icloud.com/mail/#<script></script>https://www.icloud.com/onmouseover=location=/javascript:alert%28document.domain%29/.source;//

A carga produziu isso no DOM:

<a href="https://www.icloud.com/mail#<a href=" https:="" www.icloud.com="" onmouseover="location=/javascript:alert%28document.domain%29/.source;//&quot;">https://www.icloud.com/onmouseover=location=/javascript:alert%28document.domain%29/.source;//</a>

E nos deu este belo alerta:

Esta carga era de uma solução CTF por @Blaklis_. Eu pensei originalmente que poderia ser um XSS inexplorado, mas parece sempre haver uma solução em algum lugar para o caso de borda XSS.https://platform.twitter.com/embed/index.html?dnt=true&embedId=twitter-widget-1&frame=false&hideCard=false&hideThread=false&id=1125663871056928769&lang=en&origin=https%3A%2F%2Fsamcurry.net%2Fhacking-apple%2F&theme=light&widgetsVersion=ed20a2b%3A1601588405575&width=550px

Minha melhor explicação aqui é que (1) ao carregar a URL inicial os caracteres dentro do “<script></script>” eram aceitáveis dentro do processo de hiperlinking automático e não o quebraram, em seguida (2) a remoção das tags de script criou um espaço ou algum tipo de vazio que redefiniu a funcionalidade automática de hiperlinking sem fechar a funcionalidade inicial de hiperlinking, e por último (3) o segundo hiperlink adicionou a cotação adicional que foi usada para sair do href e criar o manipulador de eventos onmouseover.

O impacto para o segundo XSS foi o mesmo do primeiro, exceto por este que o usuário teria que acionar o manipulador de eventos onmouseover através de colocar seu mouse em algum lugar dentro do corpo de e-mail, mas esta parte poderia ser simplificada para disparar mais facilmente fazendo o hiperlink de todo o e-mail.

No geral, um atacante poderia ter abusado disso para…

• Crie um worm que tenha a capacidade de exfiltrar/modificar silenciosamente informações da conta do iCloud, incluindo fotos e vídeos
• Execute silenciosamente HTML e JavaScript arbitrários dentro do navegador da vítima

Injeção de Comando no ePublisher do autor

Uma das principais características da Apple é a capacidade de carregar e vender livros, filmes, programas de TV e músicas. Os arquivos que você carrega são propagados para vários serviços da Apple, como o iTunes, onde as pessoas podem baixá-los ou comprá-los. Este parecia um bom vetor para o cliente XSS e XSS cego contra funcionários.

Para carregar arquivos, primeiro tivemos que solicitar acesso ao serviço no iTunes Connect.

Tivemos um problema interessante onde não tínhamos acesso a um iPad ou iPhone, mas continuamos procurando maneiras de usar esse serviço ainda. Depois de algumas investigações, descobrimos uma ferramenta chamada Transporter.

Transporter é um aplicativo Java que pode ser usado para interagir com uma API jsonrpc para upload em massa de arquivos utilizando alguns serviços de arquivos diferentes.

Ao mesmo tempo, também estávamos olhando através dos documentos de ajuda do iTunes Connect Book e encontramos uma página que explicava algumas maneiras diferentes de carregar livros, incluindo um serviço web online: https://itunespartner.apple.com/books/articles/submit-your-ebook-2717

Isso nos levou ao seguinte serviço, Apple Books for Authors.

Este serviço só tem alguns recursos:

• Login / Registro
• Enviar imagens para a capa do livro
• Carregar arquivo ePub do livro
• Enviar o livro Sample ePub file

A primeira coisa que fizemos foi baixar os arquivos epub de amostra e carregá-los. Engraçado o suficiente, o primeiro arquivo epub que pegamos foi um formato epub versão 1 com xhtml inválido. A ferramenta de publicação cuspiu uma enorme parede de texto de erros para nos informar por que ele falhou em carregar/validar.

Solicitação HTTP:

POST /api/v1/validate/epub HTTP/1.1
Host: authors.apple.com
{"epubKey":"2020_8_11/10f7f9ad-2a8a-44aa-9eec-8e48468de1d8_sample.epub","providerId":"BrettBuerhaus2096637541"}

Resposta HTTP:

[2020-08-11 21:49:59 UTC] <main> DBG-X:   parameter TransporterArguments = -m validateRawAssets -assetFile /tmp/10f7f9ad-2a8a-44aa-9eec-8e48468de1d8_sample.epub -dsToken **hidden value** -DDataCenters=contentdelivery.itunes.apple.com -Dtransporter.client=BooksPortal -Dcom.apple.transporter.updater.disable=true -verbose eXtreme -Dcom.transporter.client.version=1.0 -itc_provider BrettBuerhaus2096637541

Como você provavelmente pode adivinhar neste momento, tudo o que tínhamos que fazer era uma simples injeção de comando no valor provderId JSON.

Interceptamos o pedido no upload seguinte e substituímos por:

"providerId":"BrettBuerhaus2096637541||test123"

E temos a seguinte saída:

/bin/sh: 1: test123: not found

A seguir, uma captura de tela mostrando a saída de “ls /“:

No geral, um atacante poderia ter abusado disso para…

• Execute comandos arbitrários no webserver authors.apple.com
• Acesse a rede interna da Apple

Este foi um bom exercício para garantir que você explore completamente o que está testando. Muitos dos grandes nomes da pesquisa de reconhecimento falam sobre a criação de mapas mentais e este é um exemplo disso. Começamos com o iTunes Connect, começamos a explorar livros e continuamos a nos ramificar até entendermos completamente quais serviços existem em torno desse único recurso.

Também é um bom lembrete de que você precisa encontrar o máximo de informações possível antes de começar a descer buracos de coelho durante o teste. Sem explorar os documentos de ajuda, você pode ter perdido totalmente o aplicativo epub web, pois é um único link em uma página.

SSRF de resposta completa no iCloud permite que o Atacante recupere o Código Fonte da Apple

O bug mais evasivo durante o hacking na Apple foi a resposta completa do SSRF. Encontramos quase uma dúzia de SSRFs cegos ou semi-cegos, mas tivemos muito dificuldade em tentar encontrar qualquer maneira de recuperar a resposta. Isso foi incrivelmente frustrante, pois durante nosso processo de reconhecimento encontramos toneladas de referências ao que parecia ser aplicativos internos incríveis para gerenciamento de código fonte, gerenciamento de usuários, pesquisa de informações e suporte ao cliente.

Foi só no final do nosso noivado quando finalmente nos deparamos com um que parecia ter um grande acesso interno à rede.

Durante o teste do aplicativo do iCloud, notamos que você poderia abrir certos anexos do aplicativo de e-mail do iCloud no aplicativo de páginas do iCloud através da funcionalidade “Abrir em Páginas”. Quando você enviou o formulário para fazer isso, ele enviou uma solicitação HTTP contendo um parâmetro de URL que incluía a URL do anexo do arquivo de e-mail na solicitação. Se você tentasse modificar essa URL para algo arbitrário, a solicitação falharia e daria um erro “400 Má Solicitação”. O processo criaria um “trabalho” onde a resposta da solicitação HTTP foi convertida em um documento do Apple Pages e, em seguida, aberta em uma nova guia.

Ele parecia permitir apenas URLs do domínio “p37-mailws.icloud.com”, não converteria páginas com nada além de uma resposta HTTP de 200 OK, e adicionalmente seria um pouco difícil de testar, pois o processo de conversão foi feito através de várias solicitações HTTP e uma fila de trabalho.

O que funcionou para explorar isso foi anexar “@ourdomain.com” após o domínio listado em branco que apontaria a solicitação em nosso domínio. O processo converteria o HTML bruto em um arquivo de páginas da Apple e o exibiria para nós em uma nova janela. Isso foi um pouco irritante para fuzz com, então Brett acabou lançando um script python para automatizar o processo.

https://gist.github.com/samwcyo/f8387351ce9acb7cffce3f1dd94ce0d6

Nossa prova de conceito para este relatório foi demonstrar que poderíamos ler e acessar o repositório interno da Apple. Não tivemos acesso a nenhum código fonte nem isso foi explorado por outros atores.

Se o arquivo fosse muito grande para ser salvo em um arquivo Pages, ele seria armazenado para a unidade em um arquivo zip para download que nos permitiria extrair arquivos grandes como frascos e zips.

Encontramos a URL maven interna divulgada em um repositório do Github.

Havia muitos outros aplicativos internos que poderíamos ter puxado, mas como demonstramos acesso ao repositório Maven com acesso ao código-fonte, reportamos o problema imediatamente.

No geral, um atacante poderia ter abusado disso para…

• Leia os vários arquivos de código-fonte do iOS dentro do repositório maven
• Acesse qualquer outra coisa disponível na rede interna da Apple
• Comprometa totalmente a sessão de uma vítima através de uma vulnerabilidade de script de site entre sites devido aos cookies http divulgados apenas dentro da solicitação HTTP

O processo completo que teve que ser seguido ao escrever é o seguinte:

Acesso ao painel de depuração de nova administração via vazamento de erro de DESCANSO

Ao passar por uma lista de todos os subdomínios da Apple um de cada vez, descobrimos algumas funcionalidades interessantes de “concierge.apple.com”, “s.apple.com” e “events.apple.com”.

Com um pouco de dorking do Google, descobrimos que um pedido específico para “s.apple.com” o levaria a “events.apple.com” com um token de autenticação.

Solicitação HTTP:

GET /dQ{REDACTED}fE HTTP/1.1
Host: s.apple.com

Resposta HTTP:

HTTP/1.1 200
Server: Apple
Location: https://events.apple.com/content/events/retail_nso/ae/en/applecampathome.html?token=fh{REDACTED}VHUba&a=1&l=e

Executando nossas técnicas de reconhecimento padrão, pegamos os arquivos JavaScript e começamos a procurar pontos finais e rotas de API.

Descobrindo um ponto final /serviços/público/conta, começamos a brincar com ele. Descobrimos rapidamente que a passagem em um parâmetro de marketCode inválido resultou no retorno do servidor de um erro de exceção REST.

Solicitação HTTP:

Resposta HTTP:

A partir da mensagem de erro podemos ver que o servidor está encaminhando uma solicitação de API para o seguinte local:

https://nova-admin.corp.apple.com/services/locations/searchLocation?locationName=t&rtm=1

Também podemos ver que ele vazou alguns cabeçalhos de solicitação/resposta, incluindo um cookie de nova administração e um token de autorização que o servidor está enviando para fazer solicitações para nova-admin.corp.apple.com solicitações de API.

Também interessante é que o /serviços/ ponto final é semelhante aos /serviços/públicos/ pontos finais da API para o aplicativo de eventos. Não conseguimos acertar os pontos finais no aplicativo do evento e não tivemos acesso a nova-admin.corp.apple.com. Voltando aos nossos dados de reconhecimento, notamos que há um nova.apple.com.

Tentando usar o token e o cookie adquiridos, notamos que as credenciais eram válidas, pois não estávamos mais sendo redirecionadas para o idsmac auth, mas ainda era 403 proibido.

Com um pouco de fuzzing, descobrimos que fomos capazes de bater /services/debug.func.php.

Mesmo que não fosse um site com extensões PHP, parecia que adicionar qualquer extensão à rota de depuração contornaria as restrições de rota que eles construíram, uma vez que a autorização era separada da própria funcionalidade.

Solicitação HTTP:

Resposta HTTP:

Este portal continha dezenas de opções, também continha várias centenas de parâmetros de configuração e valores.

Um dos valores também continha uma chave secreta AWS, outro continha crontabs de servidor. Ter a capacidade de atualizar esses valores foi suficiente para provar a injeção de comando.

No geral, um atacante poderia ter abusado disso para…

• Execute comandos arbitrários no webserver nova.apple.com
• Acesse a rede interna da Apple

Neste ponto, decidimos que tínhamos provado impacto suficiente e paramos. O fluxo total de cima é o seguinte:

Chaves secretas AWS via PhantomJS iTune Banners e Título do Livro XSS

Descobrimos o site do criador de banners do iTunes algumas semanas antes de encontrar essa vulnerabilidade. Foi só quando adicionamos um livro via iTunes Connect que descobrimos uma característica interessante no criador de banners.

Existem vários formatos de imagem de banner com base na altura e largura especificadas. Descobrimos que a imagem do banner “300×250” incluía o nome do livro.

Também notamos que ele era vulnerável ao Scripting cross-site porque o nome do livro foi sublinhado com o nosso elemento injetado “<u>” que tínhamos definido enquanto registramos o livro no iTunes connect.

URL da imagem:

https://banners.itunes.apple.com/bannerimages/banner.png?pr=itunes&t=catalog_black&c=us&l=en-US&id=1527342866&w=300&h=250&store=books&cache=false

Anteriormente já tínhamos descoberto que havia travessia de caminho e injeção de parâmetros em alguns dos parâmetros de solicitação, como “pr”. Por exemplo:

https://banners.itunes.apple.com/bannerimages/banner.png?pr=itunes/../../&t=catalog_black&c=us&l=en-US&id=1527342866&w=300&h=250&store=books&cache=false

Resultados em uma imagem da página de erro AWS S3:

A partir daqui, assumimos que eles estavam usando um cliente de navegador sem cabeçalho para tirar capturas de tela de arquivos HTML dentro de um balde S3. Então o próximo passo foi criar um livro com <script src=””> no nome para começar a brincar com o XSS no processo de geração de imagens.

A primeira coisa que notamos foi no registro de solicitação quando ele atingiu nosso servidor:

54.210.212.22 - - [21/Aug/2020:15:54:07 +0000] "GET /imgapple.js?_=1598025246686 HTTP/1.1" 404 3901 "http://apple-itunes-banner-builder-templates-html-stage.s3-website-us-east-1.amazonaws.com/itunes/catalog_white/index.html?pr=itunes&t=catalog_white&c=us&l=en-US&id=1528672619&w=300&h=250&store=books&cache=false" "Mozilla/5.0 (Unknown; Linux x86_64) AppleWebKit/538.1 (KHTML, like Gecko) PhantomJS/2.1.1 Safari/538.1"

Este é o balde /imagem S3 que estava batendo para gerar a imagem:

http://apple-itunes-banner-builder-templates-html-stage.s3-website-us-east-1.amazonaws.com/itunes/catalog_white/index.html?pr=itunes&t=catalog_white&c=us&l=en-US&id=1528672619&w=300&h=250&store=books&cache=false

E este é o Usuário-Agente:

PhantomJS/2.1.1

Felizmente para nós, Brett tinha explorado exatamente isso alguns anos antes:https://platform.twitter.com/embed/index.html?dnt=true&embedId=twitter-widget-2&frame=false&hideCard=false&hideThread=false&id=880498767551541248&lang=en&origin=https%3A%2F%2Fsamcurry.net%2Fhacking-apple%2F&theme=light&widgetsVersion=ed20a2b%3A1601588405575&width=550px

A primeira coisa foi escrever nossa carga JS XSS para executar ataques de falsificação de solicitações do lado do servidor. Um bom método para fazer isso e renderizar dados é com o elemento <iframe>

https://gist.github.com/ziot/ef5297cc1324b13a8fae706eeecc68a5

Já que sabemos disso na AWS, tentamos atingir metadados AWS URI:

https://banners.itunes.apple.com/bannerimages/banner.png?pr=itunes&t=catalog_black&c=us&l=en-US&id=1528672619%26cachebust=12345%26url=http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance%26&w=800&h=800&store=books&cache=false

Isso tornou uma nova imagem de banner com as chaves secretas completas do AWS para um papel ec2 e iam:

A maior parte da infraestrutura interessante da Apple parece estar no CIDR IP de 8008 que eles possuem apelidado de “Applenet”, mas eles têm um pouco de hosts e serviços no AWS ec2/S3. Sabíamos que o SSRF não seria super interessante com o reconhecimento que realizamos como a maioria dos alvos corp interessantes estão na Applenet e não na AWS.

No geral, um atacante poderia ter abusado disso para…

• Leia conteúdos do ambiente interno da Amazon Web Services da Apple
• Acesse e use as chaves AWS ec2 divulgadas dentro da página de metadados internos

Heap Dump no Apple eSign permite que o invasor comprometa várias ferramentas externas de gerenciamento de funcionários

Durante nossa fase inicial de recon coleta de sub-domínios e descobrindo a superfície voltada para o público da Apple, encontramos um monte de servidores “esign”.

• https://esign-app-prod.corp.apple.com/
• https://esign-corpapp-prod.corp.apple.com/
• https://esign-internal.apple.com
• https://esign-service-prod.corp.apple.com
• https://esign-signature-prod.corp.apple.com
• https://esign-viewer-prod.corp.apple.com/
• https://esign.apple.com/

Ao carregar o subdomínio, você é imediatamente redirecionado para uma pasta /viewer. Quando você passa pelo fluxo de autenticação do Apple idmsa, você é devolvido a um erro “você não está autorizado”.

Não temos acesso a links ou arquivos js interessantes desta página, então tentamos algumas listas básicas de palavras para ver se encontramos pontos finais para o aplicativo. A partir daqui descobrimos que /viewer/atuador respondeu com todos os pontos finais do atuador, incluindo mapeamento e heapdump.

Não conseguimos fazer alterações enviando solicitações de mudança de Estado para atuadores em uma tentativa de execução remota de código, então tivemos que encontrar uma rota alternativa para provar o impacto.

Os mapeamentos expuseram todas as rotas da Web para nós, incluindo pastas adicionais na raiz do host que tinham heapdumps adicionais de atonte. Foi neste ponto que percebemos que os pontos finais do atuador eram vulneráveis em cada pasta de aplicativo em todos os subdomínios esign. Daqui pegamos um monte de alferes internos.

Carregamos o heapdump usando o Eclipse Memory Analyzer e exportamos todas as cordas para csv para peneirar com grep.

A partir daí aprendemos que o cookie de autenticação do aplicativo é “acack”. Procuramos por acack no heapdump até encontrarmos um biscoito de sessão válido. Neste ponto estávamos certos de que era um token de funcionário da Apple e não um cliente, caso contrário não o teríamos testado. Ao carregá-lo, pudemos acessar o aplicativo.

Não há muito que possamos mostrar, mas aqui está um trecho mostrando a visão autenticada da página:

Isso nos deu acesso a mais de 50 pontos finais de aplicativos, incluindo alguns pontos finais administrativos, como “setProxy” que provavelmente teria sido facilmente escalado para um SSRF ou RCE interno. Também notamos que o cookie acack estava nos autenticando para outros aplicativos também.

Tendo provado impacto suficiente, paramos aqui e reportamos.

Atuadores expondo heapdumps voltados para o público não são nada de novo e é uma constatação relativamente baixa que a maioria dos listas de palavras vai pegar. É importante lembrar que só porque você não está encontrando eles comumente, eles ainda estão lá fora e em grandes alvos apenas esperando para ser encontrado por um atacante.

Processamento de entidade externa XML para SSRF cego na API de Gerenciamento Java

Durante o teste, descobrimos uma API com múltiplas funções não autenticadas que consumiam “aplicativo/xml” depois de encontrar um “aplicativo.wadl” exposto em um dos muitos hosts 17.0.0.0/8.

Um arquivo application.wadl define os pontos finais usados por este serviço. Esta foi uma instância de teste de um serviço que normalmente é bloqueado e inacessível.

Fomos capazes de usar uma carga xxe cega para demonstrar um SSRF cego.

Infelizmente, não fomos capazes de explorar totalmente isso para ler arquivos nesta máquina ou obter uma resposta de volta de um SSRF devido à versão Java usada nesta máquina (totalmente corrigida, impedindo uma carga XXE cega de 2 estágios). Além disso, não sabíamos a estrutura de formato XML esperada (impedindo uma exploração XXE não cega).

Essa vulnerabilidade foi interessante, pois a Apple é fortemente dependente de XML e parecia que teríamos encontrado mais instâncias de XXE com quantas solicitações tínhamos visto usando-a. Foi surpreendente explorar este porque para alcançar XXE cego como era muito simples comparado com todas as maneiras complicadas que tentamos identificá-lo ao longo do tempo.

Se alguma vez explorássemos isso com sucesso para alcançar a leitura de arquivo local ou a resposta completa do SSRF, provavelmente seria através da localização do formato XML adequado para a própria API, a fim de refletir o conteúdo do arquivo diretamente versus alcançar a exfiltração cega.

No geral, um atacante poderia ter abusado disso para…

• Obtenha o que são essencialmente chaves para várias aplicações internas e externas de funcionários
• Divulgue vários segredos (credenciais de banco de dados, segredos do OAuth, chaves privadas) dos vários aplicativos esign.apple.com

Injeção GBI Vertica SQL e API GSF Exposta

Nossos esforços iniciais de reconhecimento envolveram a captura de capturas de tela de todos os domínios e endereços IP da Apple que responderam com um banner HTTP. Encontramos alguns servidores que se pareciam com isso:

A partir daqui começamos a mexer com alguns dos aplicativos, como “/depReports”. Poderíamos autenticar a eles e acessar alguns dados através de solicitações de API a uma API na rota “/gsf/”. Todos os aplicativos que acessamos neste host encaminharam solicitações através desse serviço GSF.

O pedido parecia o seguinte:

POST /gsf/partShipment/businessareas/AppleCare/subjectareas/acservice/services/batch HTTP/1.1
Host: gbiportal-apps-external-msc.apple.com
{
    "executionType": "parallel",
    "requests": [{
        "queryName": "redacted",
        "filters": {
            "redacted_id": ["redacted"],
            "redacted": [""]
        }
    }, {
        "queryName": "redacted",
        "filters": {
            "redacted_id": ["redacted"],
            "redacted": [""],
            "redacted": [""],
            "redacted": [""],
            "redacted": [""],
            "redacted": [""],
            "redacted": ["service_notification_number"],
            "redacted": ["desc"]
        }
    }, {
        "queryName": "redacted",
        "filters": {
            "redacted_id": ["redacted"],
            "redacted": [""],
            "redacted": [""],
            "redacted": [""],
            "redacted": [""],
            "redacted": [""],
            "redacted": ["service_notification_number"],
            "redacted": ["desc"],
            "redacted": ["100"],
            "redacted": ["0"]
        }
    }]
}

Você pode ver quase imediatamente que existem alguns indicadores realmente fortes aqui que eles estão interagindo com SQL. Palavras-chave: consulta, limite, deslocamento, nomes de coluna, filtro, etc. Fazendo uma pequena mudança para ver o que acontece, temos o seguinte:

(Fortemente redigido, encobrindo o erro de consulta que inclui nomes de coluna, nome da tabela, nome do banco de dados, etc). A parte importante é:

exception is java.sql.SQLException: java.sql.SQLSyntaxErrorException: [Vertica][VJDBC](4856) ERROR: Syntax error at or near \"adesc\""}]}]}

Eventualmente, temos uma injeção sindical funcionando. Algumas partes importantes foram os comentários finais extras “*/*/” no limite devido a consultas de empilhamento. Também tivemos que usar /**/ entre FROM e table como vSQL tem algumas proteções incorporadas nele contra a injeção SQL.

Não há vSQLMap, então muito esforço manual foi para obter uma injeção de trabalho:

Uma vez que temos que funcionar, decidimos roteirizar para torná-lo mais fácil. Nós carregamos uma essência dele no Github aqui:

https://gist.github.com/ziot/3c079fb253f4e467212f2ee4ce6c33cb

Se alguém estiver interessado na injeção vertica SQL, recomendo verificar seus documentos SQL. Existem algumas funções interessantes que podem ser aproveitadas para levar a injeção mais adiante, por exemplo.

https://www.vertica.com/docs/9.2.x/HTML/Content/Authoring/SQLReferenceManual/Functions/VerticaFunctions/s3export.htm

Se configurado com teclas AWS, você pode usar a injeção SQL para retirar as chaves secretas AWS do servidor. No nosso caso, isso não foi configurado para AWS, então não fomos capazes de fazer isso.

Tínhamos informações suficientes para relatar a injeção sql neste momento. Decidimos explorar a API “/gsf/” um pouco mais, pois imaginamos que eles poderiam tirar esse host e não seria mais voltado para o público.

Rapidamente ficou evidente que a API GSF teve acesso ao módulo “GSF” que expôs muitas informações sobre maçãs GSF. Isso incluiu alguns pontos finais da API para puxar dados de cluster, dados de aplicativos e, possivelmente, até mesmo implantar novos clusters e aplicativos.

Especulamos neste momento que teríamos sido capazes de implantar APIs internas para o “/gsf/ “em público, dando-nos acesso a dados confidenciais. No entanto, não provamos isso devido ao risco. Nós reportamos e paramos aqui.

No geral, um atacante poderia ter abusado disso para…

• Provavelmente comprometer as várias aplicações internas através do portal GSF exposto publicamente
• Execute consultas arbitrárias vertica SQL e extraia informações de banco de dados

Várias vulnerabilidades do IDOR

Durante os testes na Apple descobrimos uma variedade de IDORs afetando diferentes partes da Apple. O primeiro foi encontrado dentro do aplicativo app store connect que foi usado para gerenciar aplicativos na loja de aplicativos.

App Store Connect

Depois de se inscrever no serviço de desenvolvedor, a primeira coisa que fizemos foi explorar o aplicativo App Store Connect que permite que os desenvolvedores gerenciem seus aplicativos que eles tinham ou planejavam lançar para a loja de aplicativos.

Escondido atrás de alguns hiperlinks da página de configurações estava uma configuração para habilitar o Game Center para o aplicativo. Isso permitiria que você criasse placas de líder e gerenciasse locais para sua aplicação. Se você habilitou isso, você foi redirecionado para uma página mais antiga que usou um novo conjunto de identificadores para gerenciar as novas configurações de centro/local do jogo que você pode adicionar ao seu aplicativo.

Havia um parâmetro “itemId” sendo enviado na URL que era um valor numérico que definia quais configurações de aplicativo você estava modificando. Modificando o número, poderíamos acessar e modificar os quadros de líderes de qualquer aplicativo. Isso permitiria que um invasor desfigurasse ou removesse inteiramente as configurações do centro de jogo do aplicativo.

No geral, um atacante poderia ter abusado disso para…

• Exibir e modificar metadados de quaisquer aplicativos na loja de aplicativos
• Alterar dados na página de informações do Game Center de qualquer aplicativo

iCloud Encontre meus Amigos IDOR

O serviço iCloud tem uma funcionalidade onde os pais podem criar e gerenciar contas infantis através de sua conta principalmente Apple. Esse comportamento foi super interessante por causa da relação pai/filho e modelo de permissão dentro do aplicativo.

Se um pai criou ou adicionou uma conta infantil, ele teria acesso imediato para executar determinadas ações contra a sub-conta, como verificar a localização do dispositivo da criança, limitar o uso do dispositivo e visualizar fotos e vídeos armazenados. O gerenciamento do usuário foi feito principalmente através do aplicativo iOS que você não foi capaz de interceptar sem encontrar um bypass de fixação SSL, então decidimos olhar para os outros aplicativos como Find my Friends and Photos que integravam a subfuncionalidade para a relação pai/filho.

Havia funcionalidades em “Encontre meus Amigos” onde você poderia selecionar seus membros da família e clicar em “Compartilhar minha localização” e, como era uma relação confiável entre os membros da família, imediatamente compartilhar sua localização com o membro da família sem que eles tenham que aceitar o pedido e sem a capacidade de remover sua presença compartilhada de seu aplicativo. Felizmente para nós, este pedido http para realizar a ação foi interceptável e pudemos ver como eram os argumentos.

O parâmetro JSON “dsIds” foi usado como uma matriz de IDs de usuário para compartilhar sua localização. Dentro da resposta HTTP, o e-mail dos membros da família foi devolvido. Fui em frente e modifiquei esse valor para a identificação de outro usuário e para minha surpresa recebi seu e-mail.

Este IDOR nos permitiria enumerar o identificador principal das contas da Apple para recuperar e-mails de clientes e compartilhar irrevogavelmente nossa localização com os IDs de usuário da vítima, nos quais poderíamos enviar notificações e solicitar acesso à sua localização. Uma vez que o parâmetro foi enviado através de uma matriz JSON, você pode solicitar centenas de identificadores de cada vez e facilmente enumerar uma enorme quantidade de IDs de usuário pertencentes aos clientes da Apple.

No geral, um atacante poderia ter abusado disso para…

• Recupere qualquer endereço de e-mail dos usuários da Apple através de um identificador numérico incremental permanentemente vinculado à sua conta
• Associe a conta apple do invasor com a da vítima para que o invasor possa enviar-lhes notificações, mostrar sua própria localização dentro do telefone da vítima e não ser excluído de sua página Find my Friends

Caso de suporte IDOR

Uma das partes mais desafiadoras de descobrir o que hackear foi interceptar o tráfego HTTP do iOS. Havia muitos aplicativos e APIs realmente interessantes no dispositivo real, mas muitos dos domínios pertencentes à Apple eram SSL fixados e nenhum de nós tinha um fundo móvel forte o suficiente nem a quantidade significativa de tempo necessária para separar o dispositivo iOS real.

As pessoas conseguiram isso no passado e foram capazes de interceptar todo o tráfego HTTP, mas felizmente para nós, uma grande parte do tráfego ainda era interceptável dentro de vários aplicativos se você configurasse seu proxy de uma certa maneira.

A maneira como fizemos isso foi configurar o proxy Burp, instalar o certificado, em seguida, conectar-se ao WiFi que tinha o Proxy Burp ativado sempre que chegamos a uma página que queríamos tentar interceptar. Um exemplo disso seria a falha em carregar a App Store principal enquanto proxyia todas as solicitações HTTP, mas a capacidade de carregar a loja de aplicativos enquanto não estiver proxyando, navegando para a sub-página correta que deseja interceptar e, em seguida, habilitando o proxy nesse ponto.

Isso nos permitiu capturar muitas chamadas de API para os aplicativos de propriedade da Apple que foram instalados por padrão no iPhone. Um deles era um aplicativo de suporte para agendamento de suporte ou falar com um agente de bate-papo ao vivo.

A partir de interceptar estes, havia alguns IDORs muito óbvios de vários pontos finais que revelariam metadados sobre detalhes do caso de suporte. Você foi capaz de recuperar informações sobre os detalhes do caso de suporte da vítima (que suporte eles haviam solicitado, seu número de série do dispositivo, seu ID de usuário) e, adicionalmente, um token que parecia ser usado ao solicitar chat ao vivo com agentes de suporte.

No geral, um atacante poderia ter abusado disso para…

• Metadados de caso de vazamento, como número de série do dispositivo e informações de suporte para todos os casos de suporte da Apple

IDOR em mfi.apple.com

Outra aplicação em que passamos muito tempo foi “mfi.apple.com”. Este serviço foi projetado para funcionários de empresas que produziram acessórios eletrônicos de terceiros que interagiram com o iPhone para recuperar documentação e suporte para seu processo de fabricação.

Após o preenchimento do aplicativo, observamos uma solicitação HTTP sendo enviada para “getReview.action” com um parâmetro de identificação numérica. Fomos em frente e incrementamos o parâmetro via menos um e observamos que poderíamos acessar o aplicativo de outra empresa.

O aplicativo devolveu quase todos os valores fornecidos para o aplicativo da empresa, incluindo nomes, e-mails, endereços e chaves de convite que poderiam ser usadas para ingressar na empresa. Uma estimativa simples com base no nosso ID mais recente e no ID base indicou cerca de 50.000 aplicativos diferentes recuperáveis através dessa vulnerabilidade.

No geral, um atacante poderia ter abusado disso para…

• Vaze todas as informações da conta para quem se inscreveu para usar o portal MFi da Apple

Várias vulnerabilidades cegas xss

Com quase todos os aplicativos encontrados, fizemos questão de pulverizar o maior número possível de cargas XSS cegas. Isso leva a algumas vulnerabilidades muito interessantes que afetam aplicações como…

• Acesso à sessão dos funcionários dentro de um aplicativo interno para gerenciar informações de endereço do Apple Maps
• Acesso à sessão dos funcionários dentro de um aplicativo interno para gerenciar informações de editores da Apple Books
• Acesso à sessão de funcionários dentro de um aplicativo interno para gerenciar apple store e bilhetes de suporte ao cliente

Essas descobertas foram xss muito típicas cegas como as encontramos enviando cargas dentro de um campo de endereço, título de submissão de livros da Apple Books e, por último, nosso primeiro e sobrenome.

Os aplicativos internos eram muito interessantes e todos pareciam ter um nível confortável de acesso, uma vez que eles dispararam dentro do contexto das ferramentas de gestão de funcionários da Apple. Fomos capazes de agir em nome de alguém que deveria estar logado de uma VPN ou de um local no local para gerenciar informações de usuários e sistemas.

As capturas de tela a seguir mostram os painéis redigidos que fomos capazes de exfiltrar através de capturas de tela HTML5 DOM através do caçador XSS:

Como as aplicações eram internas e não éramos atacantes de verdade, paramos aqui em cada achado. Esses aplicativos teriam permitido que um invasor exfiltrasse, no mínimo, uma grande quantidade de informações confidenciais sobre a logística interna da Apple e funcionários/usuários.

Conclusão

Quando começamos este projeto, não tínhamos ideia de que passaríamos um pouco mais de três meses trabalhando para sua conclusão. Isso era originalmente para ser um projeto paralelo que trabalharíamos de vez em quando, mas com todo o tempo livre extra com a pandemia cada um acabou colocando algumas centenas de horas nele.

No geral, a Apple foi muito sensível aos nossos relatórios. A volta para nossos relatórios mais críticos foi de apenas quatro horas entre o tempo de submissão e o tempo de remediação.

Como ninguém sabia muito sobre o programa de recompensa de insetos, estávamos entrando em território não fretado com um investimento tão grande. A Apple tem um histórico interessante trabalhando com pesquisadores de segurança, mas parece que seu programa de divulgação de vulnerabilidades é um passo maciço na direção certa para trabalhar com hackers na proteção de ativos e permitir que os interessados encontrem e denunciem vulnerabilidades.

Escrever este post no blog tem sido um processo interessante, pois não tínhamos certeza de como realmente fazê-lo. Para ser honesto, cada bug que encontramos provavelmente poderia ter sido transformado em uma gravação completa com quanta informação aleatória havia. O sistema de autenticação que a Apple usa era bastante complexo e para referenciá-lo com 1-2 frases senti como se estivéssemos enganando alguém com informações. A mesma coisa poderia ser dita sobre muitos elementos dentro da infraestrutura da Apple, como o iCloud, a loja da Apple e a plataforma Developer.

Até agora, 8 de outubro, recebemos 32 pagamentos que totalizaram US$ 288.500 para várias vulnerabilidades.

No entanto, parece que a Apple faz pagamentos em lotes e provavelmente pagará por mais problemas nos meses seguintes.

Obtivemos permissão da equipe de segurança da Apple (product-security@apple.com) para publicar isso e estamos fazendo isso a seu critério. Todas as vulnerabilidades aqui divulgadas foram corrigidas e retestadas. Por favor, não divulgue informações relativas à segurança da Apple sem a sua permissão.

Recursos de apoio

• https://developer.apple.com/security-bounty – Página de informações sobre recompensas de segurança da Apple
• https://support.apple.com/en-us/HT201536 – Notificações de Segurança Web da Apple
• https://support.apple.com/en-us/HT201222 – Apple Security Updates
• http://lists.apple.com/mailman/listinfo/security-announce/ – Lista de Discussão de Segurança da Apple

Adenda

Enorme agradecimento às seguintes pessoas:

• Nick Wright (@FaIIenGhouI) para a foto de capa
• Cabo Jack
• Dan Ritter
• Redelômero Nathanial
• Jasraj Bedi
• Justin Rhinehart
• Todos na equipe de segurança de produtos da Apple que foram incrivelmente responsivos e envolvidos com nossas submissões

FONTE: SAMCURRY