Jump to content

Search the Community

Showing results for tags 'apple'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Supporter area
    • Tools of the Trade
    • Finance transparency
  • MBConf
    • MBConf v1
    • MBConf v2
    • MBConf v3
  • Mente Binária
    • General
    • Computer Architecture
    • Certifications
    • Quantum computing
    • Cryptography
    • Challenges and CTF
    • Hardware Hacking
    • Electronics
    • Conferences
    • Forensics
    • Games
    • Data privacy and laws
    • Code breaking
    • Networking
    • Pentest
    • Speak to us!
    • Software releases
  • Career
    • Study and profession
    • Jobs
  • Reverse Engineering
    • General
    • Malware Analysis
    • Firmware
    • Linux and UNIX-like
    • Windows
  • Programming
    • Assembly
    • C/C++
    • Python
    • Other languages
  • Operating Systems
    • GNU/Linux and UNIX-like
    • Windows
  • Segurança na Internet's Discussão

Categories

  • Portal Mente Binária
  • Specials

Categories

  • Tech basics
    • Text comprehension
    • English
    • Mathematics
  • Computing Basics
    • Lógica de Programação
    • Computers Architecture
    • Cryptography
    • Data Structures
    • Network
    • Operating Systems
  • Specifics
    • SO Internals
    • Web
    • Python
    • Javascript
    • Infrastructure
    • Go
    • Reverse Engineering
    • DevOps
    • C/C++
    • Log Analysis

Categories

  • Crackmes
  • Documentation
  • Debuggers
  • PE tools
  • Books
  • Util
  • Packers
  • Unpackers
  • Virtual Machines

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


GitHub


Twitter


LinkedIn


Website

Found 7 results

  1. Este artigo objetiva demonstrar, de maneira simplificada, diferentes abordagens para interceptação e captura de dados de tráfego de rede originários de um dispositivo iPhone, da Apple. Na verdade o iPhone não é o único dispositivo sujeito a estas abordagens, assim como as estratégias aqui apresentadas não são as únicas capazes de realizar tais interceptações, então é possível usar este conteúdo para muitas outras aplicações, mas vou focar no iPhone por agora. 🙂 A maneira mais simples de capturar o tráfego de rede de um iPhone é utilizando um servidor proxy. Na primeira parte deste artigo, adotaremos o Burp Suite para exemplificar este funcionamento. Após a coleta dos dados, analisaremos os pacotes de uma aplicação específica e a suas conexões com serviços web. Caso o objetivo seja uma análise mais detalhada do tráfego de uma aplicação que utilize outras tipos de comunicação que não somente requisições web, podemos diversificar a estratégia e utilizar uma interface de rede virtual (RVI), conforme demonstraremos na segunda parte deste artigo. Parte 1 - Utilizando um servidor proxy - Burp Suite Quando mencionamos a utilização de um servidor proxy, estamos basicamente nos referindo a interceptar e analisar solicitações relacionadas ao protocolo HTTP (HyperText Transfer Protocol), seja este com a camada de segurança TLS (Transport Layer Security) ou não. Algumas das aplicações que temos em nossos smartphones ainda utilizam somente o protocolo HTTP, o que significa dizer que os dados trafegam na forma de texto puro, ou seja, sem qualquer criptografia, fazendo com que informações sensíveis fiquem totalmente expostas a qualquer atacante que adotar técnicas de interceptação. Para configuração de nosso proxy o primeiro passo é abrirmos o Burp Suite. Por padrão, a interface em que ele escuta é a local (127.0.0.1) na porta 8080, conforme podemos verificar na imagem abaixo: Figura 1 - Interface padrão de escuta do Burp Suite No Burp Suite, toda captura está por padrão relacionada a máquina local, porém para executarmos nossa estratégia de interceptação dos dados que chegarão ao nosso servidor por meio do iPhone, precisaremos adicionar o IP interno da máquina local no campo Specific address: Figura 2 - Mudando a interface de escuta do Burp Suite Veja que neste caso adotamos o endereço IP 192.168.1.102 e a porta 8081. Uma vez o Burp Suite configurado, vamos ao iPhone: Figura 3 - Habilitando o uso de um servidor proxy no iPhone Perceba que o endereço IP associado ao iPhone não tem relação alguma com o servidor proxy, porém é óbvio que terão que estar na mesma rede para que o tráfego possa ser capturado. 😉 Figura 4 - Configurações de proxy no iPhone Assim que finalizamos a configuração do iPhone para utilizar o Burp Suite como o nosso servidor proxy, já podemos ver alguns pacotes. Isso ocorre pois diversas aplicações ficam rodando em background, normalmente atualizações, updates de e-mails, entre outros. Abaixo temos um exemplo de pacote interceptado com o método POST do HTTP em conexão com o office365.com para atualização de e-mail. Reparem que o DeviceType já é identificado como sendo um iPhone. Figura 5 - Tráfego recebido pelo Burp Suite Para demonstração foi utilizado um aplicativo real da área da saúde, mais precisamente de uma empresa de assistência médica. Por questões éticas, ocultei os dados. Podemos analisar que quando abrimos o aplicativo em nosso smartphone, já são executadas chamadas à API num servidor para troca de informações e com isto já visualizamos os pacotes conforme imagem abaixo: Figura 6 - Chamadas à API capturadas pelo Burp Suite Apesar de ser uma aplicação de necessidade de alto nível de sigilo de informações, os dados são trafegados em texto puro, ou seja, sem nenhuma criptografia envolvida. 😞 Conforme podemos verificar na imagem abaixo, não estamos ainda falando de credenciais de acesso, mas de todo modo são dados sensíveis, como por exemplo o número de beneficiário e telefone. Figura 7 - Dados sensíveis exibidos no Burp Suite Infelizmente, nesta aplicação não só os dados sensíveis anteriormente destacados são trafegados em texto plano, mas as credenciais de acesso (usuário e senha) também. Veja: Figura 8 - Credenciais em texto plano capturadas pelo Burp Suite Isso significa dizer que se um atacante estiver na conectado na mesma rede que nós, por exemplo uma rede wifi aberta (sem criptografia) de aeroporto, cafeteria e afins, e estivesse rodando um analisador de tráfego como este, poderia ter acesso à nossas credenciais como nome de usuário e senha. 😬 Parte 2 - Utilizando uma interface de rede virtual (RVI) - Wireshark Uma outra abordagem que pode ser as vezes mais interessante é poder analisar todo o tráfego de rede que ocorre entre o dispositivo iPhone e os servidores das aplicações, agora não mais focado somente em aplicações e requisições web (HTTP), mas sim em diferentes protocolos, como por exemplo o bom e velho MSN para fins de aprendizagem, onde é possível analisar os pacotes MSNP trafegando pela rede, bem como conexões com outros dispositivos mais simples que utilizam o protocolo SNMP, por exemplo. Não há limites. 🙂 Iniciamos com a conexão do nosso iPhone via USB ao computador que rodará o Wireshark para a coleta dos dados. Na sequência, realizaremos a criação da RVI (Remote Virtual Interface) onde necessitaremos passar como parâmetro o UUID (Universal Unique Identifiers) do iPhone. Vale lembrar que é possível obter o UUID com qualquer sistema operacional, já para criar a RVI executei o teste somente em macOS. Deixo para você verificar se é possível fazê-lo em outros sistemas, caso queira. Pelo próprio Finder do macOS é possível descobrir o UUID do aparelho, basta clicar no nome do dispositivo conectado e surgirá a informação conforme imagem abaixo: Figura 9 - UUID exibido no Finder Tendo o UUID do aparelho e estando este conectado, se faz necessário ativar a interface virtual (RVI), através do seguinte comando: Figura 10 - Criando uma RVI no shell do macOS Após recebermos a mensagem de sucesso como acima, estamos com a interface ativada e então poderemos seguir para a abertura do analisador de tráfego de rede Wireshark e selecionar a interface rvi0. Figura 11 - Escolha da interface para captura no Wireshark (no macOS) Nesta abordagem, e até para fins de comparação com a anterior, adotamos o mesmo aplicativo da área da saúde e aplicamos um filtro básico ip.src == 192.168.1.23 para facilitar a visualização somente de pacotes que têm o IP de origem do iPhone. É possível visualizarmos protocolos de diferentes camadas do modelo OSI. Neste exemplo, temos protocolos da camada de transporte (TCP) como também da camada de aplicação (HTTP) como pode ser visto na imagem abaixo: Figura 12 - Pacotes capturados pelo Wireshark Analisando somente os pacotes HTTP, é possível analisar as mesmas informações que visualizamos anteriormente no Burp Suite. Portanto, se abrirmos o conteúdo de nosso pacote selecionado, teremos também todas as informações de credenciais anteriormente demonstradas, conforme imagem abaixo: Figura 13 - Credenciais em texto plano capturadas pelo Wireshark Conclusão Pudemos verificar que existem diferentes abordagens em relação a captura de tráfego de dados de um iPhone. Na primeira parte, demonstramos a técnica com a adoção de um servidor proxy (Burp Suite), onde foi possível analisar os pacotes relacionados a requisições web. Esta técnica é de mais fácil implementação, porém muitas vezes limitada, pois como discutimos anteriormente trabalha basicamente com protocolos HTTP/HTTPS. Já na segunda parte, demonstramos uma análise de maior amplitude onde foi possível verificar que protocolos de diferentes camadas também podem ser analisados, portanto, a depender do objetivo almejado e/ou da forma de comunicação da aplicação, esta abordagem pode ser mais adequada. Vale lembrar que ambas as técnicas são complementares, portanto, dependendo do objetivo final de análise da aplicação, ambas podem ser combinadas. O caminho das pedras para a configuração do ambiente de captura está aí, agora é contigo em seguir para a análise aprofundada de suas aplicações. 🤗 Stay Safe!
  2. A Apple corrigiu duas vulnerabilidades 0-Day, aparentemente exploradas ativamente, e que afetavam o motor WebKit do navegador Safari. Segundo o BleepingComputer, as falhas no iOS podem ter sido usadas para invadir dispositivos antigos de iPhone (iPhone 5s, iPhone 6, iPhone 6 Plus), iPads (iPad Air, iPad mini 2, iPad mini 3), e iPod touch 6ª geração. Os dois bugs são causados por corrupção de memória e uso após problemas livres no motor do navegador WebKit, mecanismo de renderização de navegador usado por navegadores e aplicativos da Apple para renderizar conteúdo HTML em plataformas de desktop e móveis, incluindo iOS, macOS, tvOS e iPadOS. Os invasores podem explorar as duas vulnerabilidades usando conteúdo da Internet criado com códigos maliciosos, o que acionaria a execução arbitrária de códigos depois de serem carregados pelos alvos em dispositivos sem patch (correção). A Apple divulgou comunicado sobre as atualizações de segurança, disponibilizadas aqui.
  3. No mês passado, a Apple lançou o AirTag, localizador que tem como objetivo ajudar os usuários a encontrarem objetos do dia a dia, como chaves ou mochila. E pesquisadores já saíram hackeando o novo device para encontrar possíveis falhas de segurança. Segundo reportagem da Vice, os AirTags usam beacons Bluetooth para compartilhar sua posição com qualquer iPhones próximo, transmitindo a posição AirTag para seu proprietário por meio do aplicativo Find My, da Apple. As desmontagens detalhadas foram publicadas pelo pesquisador de hardware Colin O'Flynn e por um pesquisador da empresa de reparos iFixIt. Um dos pesquisadores da Stacksmashing também publicou um vídeo no YouTube onde analisa as entranhas da AirTag. No vídeo, ele explica como ele encontrou uma maneira de modificar o firmware no AirTag – essencialmente desbloqueando-o – para enviá-lo a um URL malicioso para um iPhone que faz a varredura com NFC (comunicação por campo de proximidade, ou near-field communication). Esse pode ser o primeiro passo para permitir que as pessoas façam pesquisas de segurança no AirTag e no chip U1, segundo o pesquisador. Um pesquisador de segurança da Positive Security também descobriu que é possível transmitir dados arbitrários para dispositivos Apple próximos por meio do protocolo Find My. Segundo o pesquisador, ele fez isso "falsificando muitos AirTags e codificando dados nos quais o AirTag está ativo". Em seguida, ele fez o dispositivo carregar os dados como parte do relatório da localização do AirTag. A Vice informa que as descobertas não mostram nenhum risco imediato, mas é interessante ver o trabalho de pesquisadores de segurança, que têm como objetivo ajudar os fabricantes a manterem seus dispositivos seguros!
  4. O AirDrop, recurso que permite que usuários de Mac e iPhone transfiram arquivos sem fio entre dispositivos da Apple, está com uma falha que permite o vazamento de e-mails e números de telefone dos usuários. Segundo o Ars Technica, o AirDrop, que usa Wi-Fi e Bluetooth para estabelecer conexões diretas com dispositivos próximos e transferir fotos, documentos, etc., entre um dispositivo iOS ou macOS para outro, funciona em três modos: um que permite que apenas contatos se conectem, um segundo que permite que qualquer pessoa se conecte, e o terceiro, que não permite nenhuma conexão. Para determinar se o dispositivo de um possível remetente deve se conectar a outros dispositivos próximos, o AirDrop transmite anúncios Bluetooth que contêm um hash criptográfico parcial do número de telefone e endereço de e-mail do remetente. Se qualquer um dos hashes truncados corresponder a qualquer número de telefone ou endereço de e-mail no catálogo de endereços do dispositivo receptor, ou se o dispositivo estiver configurado para receber de qualquer pessoa, os dois dispositivos entrarão em autenticação mútua via Wi-Fi, trocando os hashes SHA-256 completos dos números de telefone e endereços de e-mail dos usuários. O Ars Technica explica que atacantes conseguem descobrir os hashes executando um ataque de força bruta, que lança um grande número de suposições e espera por aquele que gera o hash procurado. Quanto menor a imprevisibilidade ou força no texto não criptografado, mais fácil de adivinhar ou quebrar o hash. "Esta é uma descoberta importante, pois permite que os invasores obtenham informações bastante pessoais dos usuários da Apple que, em etapas posteriores, podem ser abusadas para ataques de spear phishing, golpes, etc. ou simplesmente serem vendidos", diz ao Ars Technica um dos pesquisadores na Universidade Técnica de Darmstadt, na Alemanha, que encontrou as vulnerabilidades, Christian Weinert. Os pesquisadores dizem que notificaram a Apple em particular sobre suas descobertas em maio de 2019. Um ano e meio depois, eles apresentaram o "PrivateDrop", um AirDrop reformulado que desenvolveram e que usa interseção de conjuntos privados, uma técnica criptográfica que permite que as duas partes façam contato sem revelar hashes vulneráveis. A implementação do PrivateDrop está publicamente disponível no GitHub. Segundo o Ars Technica, até o momento, a Apple não indicou se tem planos de adotar o PrivateDrop ou empregar alguma outra forma de corrigir o vazamento.
  5. Os operadores do ransomware REvil estão exigindo que a Apple pague um pedido de resgate para evitar que informações confidenciais da empresa vazem na dark web. Segundo a empresa de segurança Recorded Future, a equipe do REvil afirma que tem a posse dos dados de produtos da Apple após violar a Quanta Computer, empresa taiwanesa fabricante de laptops e uma das empresas que montam produtos oficiais da Apple. A Recorded Future teve acesso a uma mensagem publicada em um portal da dark web onde a gangue do ransomware geralmente ameaça as vítimas e vaza seus dados. Na mensagem, a gangue do REvil diz que a Quanta se recusou a pagar para obter seus dados roubados de volta e, como resultado, o próximo alvo será o cliente principal da empresa. A gangue publicou ainda 21 screenshots falando sobre o novo MacBook da Apple, ameaçando publicar novos dados todos os dias até que a própria companhia ou a Quanta pagassem o resgate. Além disso, há possibilidade de que dados de outras empresas também vazem online. Os clientes conhecidos da Quanta Computer incluem, além da Apple, a HP, a Dell, a Microsoft, a Toshiba, a LG, a Lenovo, entre outros, diz a Recorded Future. O resgate pedido à Quanta foi de US$ 50 milhões, mas não está claro quanto dinheiro a gangue está tentando extorquir da Apple agora. A tentativa de extorsão também foi planejada para ter máxima visibilidade coincidindo com o evento Spring Loaded, realizado no dia 20 de abril, onde a Apple anunciou novos produtos e atualizações de software. Ainda segundo a Recorded Future, a gangue do REvil disse que a Apple tem até o dia 1º de maio para tentar obter seus arquivos de volta por meio do pagamento de resgate.
  6. Um pesquisador encontrou uma falha no Editor de Texto, aplicativo de edição de texto pré-instalado em Macs, que poderia revelar o endereço IP do usuário a um hacker. Segundo a Vice, o bug, que já foi corrigido pela Apple, potencialmente permitia que um atacante enganasse o Mac de uma vítima para revelar seu endereço IP apenas baixando um arquivo .txt e abrindo-o com o Editor de Texto. A falha fazia com que o aplicativo analisasse e interpretasse automaticamente o código HTML. Para acionar essa vulnerabilidade, o atacante teria que inserir algum código HTML malicioso no arquivo de texto para fazer o Editor de Texto acessar um servidor remoto controlado pelo atacante. O pesquisador disse também que o bug encontrado poderia ter sido usado junto com outras falhas para causar muito mais danos do que apenas revelar o endereço IP da vítima, podendo inclusive assumir o controle da máquina da vítima. Ele revelou ainda que o Editor de Texto tinha recursos como chamar para outros arquivos e pastas locais no disco rígido e até fazer uma solicitação para um servidor remoto, podendo fazer com que um atacante tirasse proveito desses recursos com algum código HTML escondido em um arquivo de texto aparentemente inocente. Além disso, o sistema de proteção contra malware da Apple basicamente tratava todos os arquivos .txt baixados como seguros. Para evitar ser afetado por este bug basta manter o sistema macOS atualizado, mas o pesquisador afirma que possivelmente existem outras falhas no Editor de Texto que estão sendo analisadas e serão relatadas à Apple.
  7. Pesquisadores da Universidade Técnica de Darmstadt, na Alemanha, publicaram artigo sobre duas vulnerabilidades encontradas em um sistema de rastreamento de localização que ajuda os usuários a localizarem dispositivos Apple mesmo quando eles estão offline. A análise dos pesquisadores avalia a segurança e a privacidade do Offline Finding (OF), um sistema de rastreamento de localização por crowdsourcing para dispositivos offline lançado pela Apple em 2019. A ideia básica por trás do OF é que os chamados dispositivos localizadores possam detectar a presença de outros dispositivos offline perdidos usando o Bluetooth Low Energy (BLE) e sua conexão de Internet para relatar uma localização aproximada de volta ao proprietário. Os pesquisadores afirmam, contudo, que duas vulnerabilidades distintas de design e implementação podem ter consequências graves para os usuários. Eles explicam que o design OF permite que a Apple correlacione diferentes localizações de proprietários se suas localizações forem relatadas pelo mesmo localizador. Assim, ao fazer upload e download de relatórios de localização, dispositivos localizadores e proprietários revelam sua identidade para a Apple. Além disso, os aplicativos macOS maliciosos podem recuperar e descriptografar os relatórios de localização OF dos últimos sete dias para todos os seus usuários e dispositivos. As descobertas foram compartilhadas com a Apple por meio de divulgação responsável, que corrigiu o problema por meio de uma atualização do sistema operacional (CVE-2020-9986).
×
×
  • Create New...