Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-24 13:43:24 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-dirty-nib.md

8.6 KiB
Raw Blame History

macOS Dirty NIB

Aprenda hacking no AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks:

Esta técnica foi retirada do post https://blog.xpnsec.com/dirtynib/

Informações Básicas

Arquivos NIB são usados no ecossistema de desenvolvimento da Apple para definir elementos da interface do usuário (UI) e suas interações dentro de um aplicativo. Criados com a ferramenta Interface Builder, eles contêm objetos serializados como janelas, botões e campos de texto, que são carregados em tempo de execução para apresentar a UI projetada. Embora ainda em uso, a Apple tem recomendado a transição para Storyboards para uma representação mais visual do fluxo de UI de um aplicativo.

{% hint style="danger" %} Além disso, arquivos NIB também podem ser usados para executar comandos arbitrários e se um arquivo NIB for modificado em um App, o Gatekeeper ainda permitirá executar o app, então eles podem ser usados para executar comandos arbitrários dentro de aplicativos. {% endhint %}

Injeção Dirty NIB

Primeiro precisamos criar um novo arquivo NIB, usaremos o XCode para a maior parte da construção. Começamos adicionando um Objeto à interface e definimos a classe para NSAppleScript:

Para o objeto, precisamos definir a propriedade source inicial, o que podemos fazer usando Atributos de Tempo de Execução Definidos pelo Usuário:

Isso configura nosso gadget de execução de código, que vai simplesmente executar AppleScript sob solicitação. Para realmente acionar a execução do AppleScript, vamos apenas adicionar um botão por enquanto (você pode, claro, ser criativo com isso ;). O botão será vinculado ao objeto Apple Script que acabamos de criar e irá invocar o seletor executeAndReturnError::

Para testes, vamos apenas usar o Apple Script de:

set theDialogText to "PWND"
display dialog theDialogText

E se executarmos isso no depurador do XCode e clicarmos no botão:

Com nossa capacidade de executar código AppleScript arbitrário a partir de um NIB, precisamos em seguida de um alvo. Vamos escolher o Pages para nossa demonstração inicial, que é claro, é um aplicativo da Apple e certamente não deveria ser modificável por nós.

Primeiro faremos uma cópia do aplicativo em /tmp/:

cp -a -X /Applications/Pages.app /tmp/

Então, lançaremos o aplicativo para evitar quaisquer problemas com o Gatekeeper e permitir que as coisas sejam armazenadas em cache:

open -W -g -j /Applications/Pages.app

Após iniciar (e encerrar) o aplicativo pela primeira vez, precisaremos substituir um arquivo NIB existente pelo nosso arquivo DirtyNIB. Para fins de demonstração, vamos simplesmente substituir o NIB do Painel Sobre para que possamos controlar a execução:

cp /tmp/Dirty.nib /tmp/Pages.app/Contents/Resources/Base.lproj/TMAAboutPanel.nib

Uma vez que tenhamos sobrescrito o nib, podemos desencadear a execução selecionando o item de menu About:

Se olharmos mais de perto para o Pages, vemos que ele tem um entitlement privado que permite o acesso às Fotos do usuário:

Então, podemos colocar nosso POC à prova modificando nosso AppleScript para roubar fotos do usuário sem solicitação:

{% code overflow="wrap" %}

use framework "Cocoa"
use framework "Foundation"

set grabbed to current application's NSData's dataWithContentsOfFile:"/Users/xpn/Pictures/Photos Library.photoslibrary/originals/6/68CD9A98-E591-4D39-B038-E1B3F982C902.gif"

grabbed's writeToFile:"/Users/xpn/Library/Containers/com.apple.iWork.Pages/Data/wtf.gif" atomically:1

{% endcode %}

{% hint style="danger" %} Exemplo de arquivo .xib malicioso que executa código arbitrário. {% endhint %}

Crie seu próprio DirtyNIB

Restrições de Lançamento

Elas basicamente impedem a execução de aplicações fora de seus locais esperados, então se você copiar uma aplicação protegida por Restrições de Lançamento para /tmp, você não conseguirá executá-la.
Encontre mais informações neste post.

No entanto, analisando o arquivo /System/Volumes/Preboot/*/boot/*/usr/standalone/firmware/FUD/StaticTrustCache.img4 você ainda pode encontrar aplicações que não estão protegidas por Restrições de Lançamento e ainda pode injetar arquivos NIB em locais arbitrários nessas (verifique o link anterior para aprender como encontrar esses aplicativos).

Proteções Extras

A partir do macOS Somona, existem algumas proteções que impedem a escrita dentro de Apps. No entanto, ainda é possível contornar essa proteção se, antes de executar sua cópia do binário, você mudar o nome da pasta Contents:

  1. Faça uma cópia de CarPlay Simulator.app para /tmp/
  2. Renomeie /tmp/Carplay Simulator.app/Contents para /tmp/CarPlay Simulator.app/NotCon
  3. Execute o binário /tmp/CarPlay Simulator.app/NotCon/MacOS/CarPlay Simulator para armazenar no cache do Gatekeeper
  4. Substitua NotCon/Resources/Base.lproj/MainMenu.nib pelo nosso arquivo Dirty.nib
  5. Renomeie para /tmp/CarPlay Simulator.app/Contents
  6. Execute CarPlay Simulator.app novamente

{% hint style="success" %} Parece que isso não é mais possível porque o macOS impede a modificação de arquivos dentro dos pacotes de aplicativos.
Então, após executar o aplicativo para armazená-lo no cache do Gatekeeper, você não poderá modificar o pacote.
E se você mudar, por exemplo, o nome do diretório Contents para NotCon (conforme indicado no exploit), e depois executar o binário principal do aplicativo para armazená-lo no cache do Gatekeeper, isso disparará um erro e não executará. {% endhint %}

Aprenda hacking no AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras maneiras de apoiar o HackTricks: