Search the Community

A Apple disponibilizou o macOS Big Sur 11.4, e a recomendação é que os usuários de MacBook façam uma atualização o mais rápido possível. Isso porque um malware que faz capturas de tela secretamente foi detectado explorando uma séria falha na segurança do macOS. A falha pode ser explorada para gravação de vídeo ou acesso a arquivos, tornando a correção mais urgente. A descoberta foi feita pela empresa de segurança cibernética Jamf durante a pesquisa sobre o malware XCSSET, descoberto pela Trend Micro em 2020. "Descobrimos que esse desvio está sendo explorado ativamente durante a análise adicional do malware XCSSET, após notar um aumento significativo de variantes detectadas por aí. A equipe de detecção observou que, uma vez instalado no sistema da vítima, o XCSSET estava usando esse desvio especificamente com o objetivo de tirar capturas de tela da área de trabalho do usuário sem exigir permissões adicionais", diz a empresa. A Jamf destaca que o malware foi escrito em AppleScript, uma linguagem de script desenvolvida pela Apple, facilitando o controle sobre aplicativos Mac. Na maior parte do tempo, o autor do malware aproveita AppleScripts em sua cadeia de ataque devido à facilidade com que lida com muitos comandos bash, até mesmo baixando e/ou executando scripts Python, tentando sempre ofuscar suas intenções usando várias linguagens de script. A empresa traz mais detalhes de como funciona o malware, e alerta para que usuários atualizem seus sistemas, já que a Apple corrigiu recentemente esse problema, evitando que o XCSSET abuse dessa vulnerabilidade no futuro.

Atacantes estavam explorando um bug grave no sistema operacional da Apple, o macOS, conseguindo contornar a maioria dos mecanismos de segurança do sistema. Segundo a Vice, o bug era, até então, desconhecido e foi utilizado para invadir um número não identificado de computadores Mac. O problema foi relatado à Apple em 25 de março, e a empresa já lançou um patch na versão mais recente do MacOS Big Sur, corrigindo a falha. Pesquisadores de segurança que encontraram a vulnerabilidade e a analisaram dizem que a falha permitia que os atacantes criassem um malware que poderia assumir o controle do computador da vítima, contornando as proteções de segurança da Apple no macOS, como Gatekeeper, Quarentena de Arquivos e requisitos de autenticação de aplicativos. Em teoria, esses mecanismos bloqueiam o acesso de arquivos baixados da Internet aos arquivos do usuário, a menos que sejam assinados por desenvolvedores conhecidos e tenham sido verificados pela Apple. Um pesquisador independente especializado em macOS afirmou à Vice que esse é o pior ou potencialmente o mais impactante bug para os usuários diários do macOS. Apesar da vítima em potencial ter que clicar duas vezes em um arquivo malicioso para infectar seu computador, o sistema não mostra nenhum alerta, prompt, nem bloqueia a execução do aplicativo, de acordo com os pesquisadores. Um porta-voz da Apple disse que a empresa implantou regras para detectar malwares que abusam desse bug em seu aplicativo antivírus XProtect. Essas regras são instaladas automaticamente em segundo plano, o que significa que todos os dispositivos macOS, incluindo os que executam versões anteriores, também terão essa proteção.

Em todos os sistemas operacionais existem arquivos estruturados. Imagine um bloco segmentado em diversas partes e cada uma sendo uma área que armazena um tipo de dado específico (ex.: cabeçalho, área de código, área de dado inicializado, área de dado estático, área de dado não inicializado, área de referência de definições externas/outros objetos) servindo de referência para resguardar determinada classe de dado do respectivo arquivo binário para serem usados durante a execução do software ou até mesmo para fornecer informações que ajudam no processo de debugging. O conceito dessa formatação do arquivo (file format) é presente em todos os sistemas operacionais populares como Windows e Unix-like – isso inclui o macOS. Sabendo que o macOS é um sistema operacional do Unix é de se esperar que seus arquivos binários também tenham um “formato”, e estes são conhecidos como “arquivos de objeto do Mac” ou simplesmente Mach-O. Com esse entendimento o propósito deste artigo é dar uma visão técnica geral sobre a estrutura de arquivos construídos com este formato. Por que é importante conhecer o formato Mach-O? Algumas pessoas acreditam que o sistema operacional macOS (atualmente na versão denominada Catalina) é mais seguro que outros sistemas operacionais existentes pelo fato de não ser afetado por malware. Grande engano! Atualmente, vemos muitas publicações de vulnerabilidades relacionadas ao macOS, o que demonstra que este sistema operacional é, sim, um alvo em potencial. A grande pergunta que sempre faço é: “O que é mais interessante para um criminoso?”. Neste contexto, por “criminoso” me refiro à qualquer indivíduo que se utiliza dos meios eletrônicos para cometer fraudes. Deixando dispositivos móveis de lado, minha opinião é que hajam duas alternativas principais: Infectar o maior número de hosts possível (Windows ou Linux); Infectar um número mais restrito de hosts, porém algo mais direcionado a usuários, em geral, de cargos executivos, por exemplo: Diretores, CSO, etc. ou usuários domésticos, que muitas vezes permitem que softwares de fonte desconhecida sejam executados livremente em seu sistema operacional, ao desativar mecanismos de segurança como o gatekeeper; Se eu fosse um criminoso, optaria pela segunda opção; pois, atualmente o MacBook está se tornando cada vez mais popular. A imagem abaixo nos mostra a grande quantidade de arquivos Mach-O que foram analisados no VirusTotal nos últimos 7 dias desde a escrita deste artigo: Estes são os tipos de arquivos submetidos ao VirusTotal nos últimos 7 dias, obtidos em 25/julho/2020. Repare que a imagem não reporta arquivos infectados, mas sim os binários de cada tipo analisados. Bom, é perceptível que Mach-O está ganhando uma certa predominância hoje em dia, embora ainda seja bem inferior ao número do arquivo executável do Windows (Win32.exe). Apenas a título de curiosidade, o Mach-O tem um formato multi arquitetura, também conhecido como “fat binary” (conforme podemos ver na imagem abaixo) aonde ele suporta 3 tipos de arquiteturas diferentes: x86_64, i386 e ppc7400: Aqui temos uma tabela com todos os “Magic Number” (valor numérico de texto usado para identificar um formato de arquivo) referentes à binários do tipo Mach-O: Ainda nesta linha de pesquisa, a técnica utilizada para gerar um binário suportado com várias plataformas (cross-compiling) é demonstrada na imagem abaixo utilizando o compilador gcc: Usando o comando file do macOS vemos o tipo do arquivo e a arquitetura da plataforma que é suportado: O formato Mach-O de 64-bits Conforme observado anteriormente os binários Mach-O tem três regiões principais: Cabeçalho (Header); Comandos de carregamento (Load Commands); e, Dados (Data). A imagem abaixo representa a estrutura básica dos arquivos Mach-O 64-bit: No Header, encontram-se especificações gerais do binário, como seu magic number e a arquitetura alvo. Podemos encontrar este header em /usr/include/mach-o/loader.h: Conhecendo um pouco mais a estrutura do mach header podemos notar que ela é composta por 8 membros, cada um possuindo 4 bytes, ou seja: 4 * 8 = 32. Podemos ver os primeiros 32 bytes do binário, isto é, os valores do header abaixo: A região Load Commands especifica a estrutura lógica do arquivo e informações para que o binário possa ser carregado em memória e utilizado pelo sistema. Ela é composta por uma sequência de diversos modelos de commands numa tupla, por exemplo: “[load_command, specific_command_headers]” -- definindo as diferentes “seções lógicas” (commands) do binário. Cada command necessita de um ou mais cabeçalhos específicos, por isso, o segundo membro da tupla (specific_command_headers) pode variar de acordo com o tipo de command da mesma em questão: A título de exemplo, podemos ver também o command LC_SEGMENT_64 do cabeçalho do binário Mach-O: Neste mesmo contexto, podemos ver que as bibliotecas dinâmicas (dylib) "libncurses" e "libSystem" foram carregadas nos commands 12 e 13, que pertencem ao cabeçalho LC_LOAD_DYLIB. Deste jeito, o kernel consegue mapear as informações do executável para um espaço de memória que pode ser acessado simultaneamente por múltiplos programas na finalidade de prover comunicação entre eles ou para evitar compartilhamento de dados supérfluos – tal conceito é conhecido como memória compartilhada: Podemos ver também que a section __text contém o segmento __TEXT: E por fim temos a Data, onde temos instruções armazenadas logo após a região LOAD_Commands. Na região Data é que são definidas as permissões de leitura e gravação. Dependendo do tipo de Mach-O a maneira como essa região é usada varia. Quando analisamos um binário um dos primeiros pontos para o início dos testes é a inspeção do binário em um debugger a partir de seu entrypoint. No caso do deste Mach-O que estamos analisando percebemos que o código é colocado na seção __TEXT, as bibliotecas são carregadas no cabeçalho LC_LOAD_DYLIB e o LC_MAIN é o cabeçalho que aponta para o ponto de entrada (entrypoint) : Por enquanto já temos uma noção básica da estrutura dos binários Mach-O. Em um próximo artigo, iremos detalhar melhor este binário com foco em engenharia reversa para identificar ações de software malicioso. Para ajudar, recomendo a você artigos da H2HC Magazine sobre pilhas, registradores etc., dos colegas Fernando Mercês, Ygor da Rocha Parreira, Gabriel Negreiros, Filipe Balestra e Raphael Campos nas edições 7, 8, 9, 10 e 11. Outra referência para auxiliar nesta análise é o artigo "Montando sua máquina virtual para engenharia reversa em macOS"[11]. Até lá! Referências Palestra H2HC University Vídeo Demo Malware Keranger Mach-O Vídeo Demo Crackme Mach-O Calling Conventions OS X ABI Mach-O File Format Revista H2HC ed7 Revista H2HC ed8 Revista H2HC ed9 Revista H2HC ed10 Revista H2HC ed11 Montando sua máquina virtual para engenharia reversa em macOS