diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/README.md b/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/README.md index d17137198..bf04c441b 100644 --- a/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/README.md +++ b/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/README.md @@ -27,13 +27,13 @@ El **núcleo** XNU también **incorpora** una cantidad significativa de código - Pila TCP/IP y sockets - Cortafuegos y filtrado de paquetes -Entender la interacción entre BSD y Mach puede ser complejo, debido a sus diferentes marcos conceptuales. Por ejemplo, BSD utiliza procesos como su unidad fundamental de ejecución, mientras que Mach opera en función de hilos. Esta discrepancia se reconcilia en XNU **asociando cada proceso BSD con una tarea Mach** que contiene exactamente un hilo Mach. Cuando se utiliza la llamada al sistema fork() de BSD, el código de BSD dentro del núcleo utiliza funciones de Mach para crear una tarea y una estructura de hilo. +Entender la interacción entre BSD y Mach puede ser complejo, debido a sus diferentes marcos conceptuales. Por ejemplo, BSD utiliza procesos como su unidad fundamental de ejecución, mientras que Mach opera en función de hilos. Esta discrepancia se reconcilia en XNU **asociando cada proceso BSD con una tarea Mach** que contiene exactamente un hilo Mach. Cuando se utiliza la llamada al sistema fork() de BSD, el código BSD dentro del núcleo utiliza funciones Mach para crear una tarea y una estructura de hilo. -Además, **Mach y BSD mantienen cada uno diferentes modelos de seguridad**: el modelo de seguridad de **Mach** se basa en **derechos de puerto**, mientras que el modelo de seguridad de BSD opera en función de **la propiedad del proceso**. Las disparidades entre estos dos modelos han resultado ocasionalmente en vulnerabilidades de escalada de privilegios locales. Aparte de las llamadas al sistema típicas, también hay **trampas de Mach que permiten a los programas en espacio de usuario interactuar con el núcleo**. Estos diferentes elementos juntos forman la arquitectura híbrida y multifacética del núcleo de macOS. +Además, **Mach y BSD mantienen diferentes modelos de seguridad**: el modelo de seguridad de **Mach** se basa en **derechos de puerto**, mientras que el modelo de seguridad de BSD opera en función de **la propiedad del proceso**. Las disparidades entre estos dos modelos han resultado ocasionalmente en vulnerabilidades de escalada de privilegios locales. Aparte de las llamadas al sistema típicas, también hay **trampas Mach que permiten a los programas en espacio de usuario interactuar con el núcleo**. Estos diferentes elementos juntos forman la arquitectura híbrida y multifacética del núcleo de macOS. ### I/O Kit - Controladores -El I/O Kit es un marco de **controladores de dispositivos** de código abierto y orientado a objetos en el núcleo XNU, que maneja **controladores de dispositivos cargados dinámicamente**. Permite que se agregue código modular al núcleo sobre la marcha, soportando hardware diverso. +El I/O Kit es un marco de **controladores de dispositivos** orientado a objetos y de código abierto en el núcleo XNU, que maneja **controladores de dispositivos cargados dinámicamente**. Permite que se agregue código modular al núcleo sobre la marcha, soportando hardware diverso. {{#ref}} macos-iokit.md diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-ipc-inter-process-communication/README.md b/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-ipc-inter-process-communication/README.md index 15faaea0c..0adbb0eb2 100644 --- a/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-ipc-inter-process-communication/README.md +++ b/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-ipc-inter-process-communication/README.md @@ -26,11 +26,11 @@ Los derechos de puerto, que definen qué operaciones puede realizar una tarea, s - **Derecho de conjunto de puertos**, que denota un _conjunto de puertos_ en lugar de un solo puerto. Desencolar un mensaje de un conjunto de puertos desencola un mensaje de uno de los puertos que contiene. Los conjuntos de puertos se pueden usar para escuchar en varios puertos simultáneamente, muy parecido a `select`/`poll`/`epoll`/`kqueue` en Unix. - **Nombre muerto**, que no es un derecho de puerto real, sino simplemente un marcador de posición. Cuando un puerto es destruido, todos los derechos de puerto existentes al puerto se convierten en nombres muertos. -**Las tareas pueden transferir derechos de ENVÍO a otras**, permitiéndoles enviar mensajes de vuelta. **Los derechos de ENVÍO también pueden ser clonados, por lo que una tarea puede duplicar y dar el derecho a una tercera tarea**. Esto, combinado con un proceso intermediario conocido como el **servidor de arranque**, permite una comunicación efectiva entre tareas. +**Las tareas pueden transferir derechos de ENVÍO a otros**, permitiéndoles enviar mensajes de vuelta. **Los derechos de ENVÍO también pueden ser clonados, por lo que una tarea puede duplicar y dar el derecho a una tercera tarea**. Esto, combinado con un proceso intermediario conocido como el **servidor de arranque**, permite una comunicación efectiva entre tareas. ### Puertos de Archivo -Los puertos de archivo permiten encapsular descriptores de archivo en puertos Mac (utilizando derechos de puerto Mach). Es posible crear un `fileport` a partir de un FD dado usando `fileport_makeport` y crear un FD a partir de un fileport usando `fileport_makefd`. +Los puertos de archivo permiten encapsular descriptores de archivo en puertos Mac (utilizando derechos de puerto Mach). Es posible crear un `fileport` a partir de un FD dado utilizando `fileport_makeport` y crear un FD a partir de un fileport utilizando `fileport_makefd`. ### Estableciendo una comunicación @@ -41,11 +41,11 @@ Como se menciona, para establecer el canal de comunicación, el **servidor de ar 1. La tarea **A** inicia un **nuevo puerto**, obteniendo un **derecho de RECEPCIÓN** en el proceso. 2. La tarea **A**, siendo la titular del derecho de RECEPCIÓN, **genera un derecho de ENVÍO para el puerto**. 3. La tarea **A** establece una **conexión** con el **servidor de arranque**, proporcionando el **nombre del servicio del puerto** y el **derecho de ENVÍO** a través de un procedimiento conocido como el registro de arranque. -4. La tarea **B** interactúa con el **servidor de arranque** para ejecutar una búsqueda de arranque **para el nombre del servicio**. Si tiene éxito, el **servidor duplica el DERECHO DE ENVÍO** recibido de la Tarea A y **lo transmite a la Tarea B**. -5. Al adquirir un DERECHO DE ENVÍO, la Tarea **B** es capaz de **formular** un **mensaje** y enviarlo **a la Tarea A**. -6. Para una comunicación bidireccional, generalmente la tarea **B** genera un nuevo puerto con un **DERECHO DE RECEPCIÓN** y un **DERECHO DE ENVÍO**, y otorga el **DERECHO DE ENVÍO a la Tarea A** para que pueda enviar mensajes a la TAREA B (comunicación bidireccional). +4. La tarea **B** interactúa con el **servidor de arranque** para ejecutar una búsqueda de arranque **para el nombre del servicio**. Si tiene éxito, el **servidor duplica el DERECHO DE ENVÍO** recibido de la tarea A y **lo transmite a la tarea B**. +5. Al adquirir un derecho de ENVÍO, la tarea **B** es capaz de **formular** un **mensaje** y enviarlo **a la tarea A**. +6. Para una comunicación bidireccional, generalmente la tarea **B** genera un nuevo puerto con un **DERECHO DE RECEPCIÓN** y un **DERECHO DE ENVÍO**, y otorga el **DERECHO DE ENVÍO a la tarea A** para que pueda enviar mensajes a la TAREA B (comunicación bidireccional). -El servidor de arranque **no puede autenticar** el nombre del servicio reclamado por una tarea. Esto significa que una **tarea** podría potencialmente **suplantar cualquier tarea del sistema**, como falsamente **reclamando un nombre de servicio de autorización** y luego aprobando cada solicitud. +El servidor de arranque **no puede autenticar** el nombre del servicio reclamado por una tarea. Esto significa que una **tarea** podría potencialmente **suplantar cualquier tarea del sistema**, como falsamente **reclamar un nombre de servicio de autorización** y luego aprobar cada solicitud. Luego, Apple almacena los **nombres de los servicios proporcionados por el sistema** en archivos de configuración seguros, ubicados en directorios **protegidos por SIP**: `/System/Library/LaunchDaemons` y `/System/Library/LaunchAgents`. Junto a cada nombre de servicio, también se **almacena el binario asociado**. El servidor de arranque creará y mantendrá un **DERECHO DE RECEPCIÓN para cada uno de estos nombres de servicio**. @@ -53,9 +53,9 @@ Para estos servicios predefinidos, el **proceso de búsqueda difiere ligeramente - La tarea **B** inicia una búsqueda de arranque **para un nombre de servicio**. - **launchd** verifica si la tarea está en ejecución y, si no lo está, **la inicia**. -- La tarea **A** (el servicio) realiza un **check-in de arranque**. Aquí, el **servidor de arranque** crea un derecho de ENVÍO, lo retiene y **transfiere el derecho de RECEPCIÓN a la Tarea A**. -- launchd duplica el **DERECHO DE ENVÍO y lo envía a la Tarea B**. -- La tarea **B** genera un nuevo puerto con un **DERECHO DE RECEPCIÓN** y un **DERECHO DE ENVÍO**, y otorga el **DERECHO DE ENVÍO a la Tarea A** (el svc) para que pueda enviar mensajes a la TAREA B (comunicación bidireccional). +- La tarea **A** (el servicio) realiza un **registro de arranque**. Aquí, el **servidor de arranque** crea un derecho de ENVÍO, lo retiene y **transfiere el derecho de RECEPCIÓN a la tarea A**. +- launchd duplica el **DERECHO DE ENVÍO y lo envía a la tarea B**. +- La tarea **B** genera un nuevo puerto con un **DERECHO DE RECEPCIÓN** y un **DERECHO DE ENVÍO**, y otorga el **DERECHO DE ENVÍO a la tarea A** (el svc) para que pueda enviar mensajes a la TAREA B (comunicación bidireccional). Sin embargo, este proceso solo se aplica a tareas del sistema predefinidas. Las tareas no del sistema aún operan como se describió originalmente, lo que podría permitir potencialmente la suplantación. @@ -76,7 +76,7 @@ mach_msg_id_t msgh_id; ``` Los procesos que poseen un _**derecho de recepción**_ pueden recibir mensajes en un puerto Mach. Por el contrario, a los **remitentes** se les concede un _**derecho de envío**_ o un _**derecho de envío-una-vez**_. El derecho de envío-una-vez es exclusivamente para enviar un solo mensaje, después del cual se vuelve inválido. -Para lograr una **comunicación bidireccional** fácil, un proceso puede especificar un **puerto mach** en el **encabezado del mensaje** mach llamado el _puerto de respuesta_ (**`msgh_local_port`**) donde el **receptor** del mensaje puede **enviar una respuesta** a este mensaje. Las banderas de bits en **`msgh_bits`** se pueden usar para **indicar** que un **derecho de envío-una-vez** debe ser derivado y transferido para este puerto (`MACH_MSG_TYPE_MAKE_SEND_ONCE`). +Para lograr una **comunicación bidireccional** fácil, un proceso puede especificar un **puerto mach** en el **encabezado del mensaje** mach llamado el _puerto de respuesta_ (**`msgh_local_port`**) donde el **receptor** del mensaje puede **enviar una respuesta** a este mensaje. Los bits en **`msgh_bits`** se pueden usar para **indicar** que un **derecho de envío-una-vez** debe ser derivado y transferido para este puerto (`MACH_MSG_TYPE_MAKE_SEND_ONCE`). > [!TIP] > Tenga en cuenta que este tipo de comunicación bidireccional se utiliza en mensajes XPC que esperan una respuesta (`xpc_connection_send_message_with_reply` y `xpc_connection_send_message_with_reply_sync`). Pero **generalmente se crean diferentes puertos** como se explicó anteriormente para crear la comunicación bidireccional. @@ -234,9 +234,9 @@ printf("Sent a message\n"); - **Puerto de tarea** (también conocido como puerto del kernel)**:** Con permiso de Enviar sobre este puerto es posible controlar la tarea (leer/escribir memoria, crear hilos...). - Llama a `mach_task_self()` para **obtener el nombre** de este puerto para la tarea que llama. Este puerto solo se **hereda** a través de **`exec()`**; una nueva tarea creada con `fork()` obtiene un nuevo puerto de tarea (como un caso especial, una tarea también obtiene un nuevo puerto de tarea después de `exec()` en un binario suid). La única forma de generar una tarea y obtener su puerto es realizar el ["baile de intercambio de puertos"](https://robert.sesek.com/2014/1/changes_to_xnu_mach_ipc.html) mientras se realiza un `fork()`. - Estas son las restricciones para acceder al puerto (de `macos_task_policy` del binario `AppleMobileFileIntegrity`): -- Si la aplicación tiene el **derecho `com.apple.security.get-task-allow`**, los procesos del **mismo usuario pueden acceder al puerto de tarea** (comúnmente agregado por Xcode para depuración). El proceso de **notarización** no lo permitirá en lanzamientos de producción. +- Si la aplicación tiene el derecho **`com.apple.security.get-task-allow`**, los procesos del **mismo usuario pueden acceder al puerto de tarea** (comúnmente agregado por Xcode para depuración). El proceso de **notarización** no lo permitirá en lanzamientos de producción. - Las aplicaciones con el derecho **`com.apple.system-task-ports`** pueden obtener el **puerto de tarea para cualquier** proceso, excepto el kernel. En versiones anteriores se llamaba **`task_for_pid-allow`**. Esto solo se concede a aplicaciones de Apple. -- **Root puede acceder a los puertos de tarea** de aplicaciones **no** compiladas con un **runtime** **endurecido** (y no de Apple). +- **Root puede acceder a los puertos de tarea** de aplicaciones **no** compiladas con un tiempo de ejecución **endurecido** (y no de Apple). ### Inyección de Shellcode en hilo a través del Puerto de Tarea diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-kernel-extensions.md b/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-kernel-extensions.md index 6c6db8df7..92186a4aa 100644 --- a/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-kernel-extensions.md +++ b/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-kernel-extensions.md @@ -17,17 +17,17 @@ Obviamente, esto es tan poderoso que es **complicado cargar una extensión del k - La extensión del kernel debe estar **firmada con un certificado de firma de código del kernel**, que solo puede ser **otorgado por Apple**. Quien revisará en detalle la empresa y las razones por las que se necesita. - La extensión del kernel también debe estar **notarizada**, Apple podrá verificarla en busca de malware. - Luego, el usuario **root** es quien puede **cargar la extensión del kernel** y los archivos dentro del paquete deben **pertenecer a root**. -- Durante el proceso de carga, el paquete debe estar preparado en una **ubicación protegida no root**: `/Library/StagedExtensions` (requiere el permiso `com.apple.rootless.storage.KernelExtensionManagement`). -- Finalmente, al intentar cargarla, el usuario [**recibirá una solicitud de confirmación**](https://developer.apple.com/library/archive/technotes/tn2459/_index.html) y, si se acepta, la computadora debe ser **reiniciada** para cargarla. +- Durante el proceso de carga, el paquete debe estar preparado en una **ubicación protegida no root**: `/Library/StagedExtensions` (requiere el otorgamiento `com.apple.rootless.storage.KernelExtensionManagement`). +- Finalmente, al intentar cargarlo, el usuario [**recibirá una solicitud de confirmación**](https://developer.apple.com/library/archive/technotes/tn2459/_index.html) y, si se acepta, la computadora debe ser **reiniciada** para cargarlo. -### Proceso de carga +### Proceso de Carga -En Catalina fue así: Es interesante notar que el proceso de **verificación** ocurre en **userland**. Sin embargo, solo las aplicaciones con el permiso **`com.apple.private.security.kext-management`** pueden **solicitar al kernel que cargue una extensión**: `kextcache`, `kextload`, `kextutil`, `kextd`, `syspolicyd` +En Catalina fue así: Es interesante notar que el proceso de **verificación** ocurre en **userland**. Sin embargo, solo las aplicaciones con el otorgamiento **`com.apple.private.security.kext-management`** pueden **solicitar al kernel que cargue una extensión**: `kextcache`, `kextload`, `kextutil`, `kextd`, `syspolicyd` 1. **`kextutil`** cli **inicia** el proceso de **verificación** para cargar una extensión -- Se comunicará con **`kextd`** enviando usando un **servicio Mach**. +- Hablará con **`kextd`** enviando usando un **servicio Mach**. 2. **`kextd`** verificará varias cosas, como la **firma** -- Se comunicará con **`syspolicyd`** para **verificar** si la extensión puede ser **cargada**. +- Hablará con **`syspolicyd`** para **comprobar** si la extensión puede ser **cargada**. 3. **`syspolicyd`** **preguntará** al **usuario** si la extensión no ha sido cargada previamente. - **`syspolicyd`** informará el resultado a **`kextd`** 4. **`kextd`** finalmente podrá **decirle al kernel que cargue** la extensión @@ -58,7 +58,7 @@ En mi caso en macOS lo encontré en: #### IMG4 -El formato de archivo IMG4 es un formato contenedor utilizado por Apple en sus dispositivos iOS y macOS para **almacenar y verificar de manera segura** componentes de firmware (como **kernelcache**). El formato IMG4 incluye un encabezado y varias etiquetas que encapsulan diferentes piezas de datos, incluyendo la carga útil real (como un kernel o cargador de arranque), una firma y un conjunto de propiedades de manifiesto. El formato admite verificación criptográfica, permitiendo que el dispositivo confirme la autenticidad e integridad del componente de firmware antes de ejecutarlo. +El formato de archivo IMG4 es un formato contenedor utilizado por Apple en sus dispositivos iOS y macOS para **almacenar y verificar de manera segura** componentes de firmware (como **kernelcache**). El formato IMG4 incluye un encabezado y varias etiquetas que encapsulan diferentes piezas de datos, incluyendo la carga útil real (como un kernel o bootloader), una firma y un conjunto de propiedades de manifiesto. El formato admite verificación criptográfica, permitiendo que el dispositivo confirme la autenticidad e integridad del componente de firmware antes de ejecutarlo. Generalmente está compuesto por los siguientes componentes: diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-system-extensions.md b/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-system-extensions.md index 0e86b9a86..a935d31d2 100644 --- a/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-system-extensions.md +++ b/src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-system-extensions.md @@ -18,11 +18,11 @@ DriverKit es un reemplazo para las kernel extensions que **proporcionan soporte Las Network Extensions proporcionan la capacidad de personalizar comportamientos de red. Hay varios tipos de Network Extensions: -- **App Proxy**: Esto se utiliza para crear un cliente VPN que implementa un protocolo VPN personalizado orientado a flujos. Esto significa que maneja el tráfico de red basado en conexiones (o flujos) en lugar de paquetes individuales. -- **Packet Tunnel**: Esto se utiliza para crear un cliente VPN que implementa un protocolo VPN personalizado orientado a paquetes. Esto significa que maneja el tráfico de red basado en paquetes individuales. -- **Filter Data**: Esto se utiliza para filtrar "flujos" de red. Puede monitorear o modificar datos de red a nivel de flujo. -- **Filter Packet**: Esto se utiliza para filtrar paquetes individuales de red. Puede monitorear o modificar datos de red a nivel de paquete. -- **DNS Proxy**: Esto se utiliza para crear un proveedor DNS personalizado. Puede usarse para monitorear o modificar solicitudes y respuestas DNS. +- **App Proxy**: Se utiliza para crear un cliente VPN que implementa un protocolo VPN personalizado orientado a flujos. Esto significa que maneja el tráfico de red basado en conexiones (o flujos) en lugar de paquetes individuales. +- **Packet Tunnel**: Se utiliza para crear un cliente VPN que implementa un protocolo VPN personalizado orientado a paquetes. Esto significa que maneja el tráfico de red basado en paquetes individuales. +- **Filter Data**: Se utiliza para filtrar "flujos" de red. Puede monitorear o modificar datos de red a nivel de flujo. +- **Filter Packet**: Se utiliza para filtrar paquetes individuales de red. Puede monitorear o modificar datos de red a nivel de paquete. +- **DNS Proxy**: Se utiliza para crear un proveedor DNS personalizado. Puede usarse para monitorear o modificar solicitudes y respuestas DNS. ## Endpoint Security Framework @@ -32,16 +32,16 @@ Este marco proporciona una **colección de APIs para monitorear y controlar la a El núcleo de este marco está implementado en el kernel, como una Kernel Extension (KEXT) ubicada en **`/System/Library/Extensions/EndpointSecurity.kext`**. Este KEXT está compuesto por varios componentes clave: -- **EndpointSecurityDriver**: Actúa como el "punto de entrada" para la extensión del kernel. Es el principal punto de interacción entre el sistema operativo y el marco de Endpoint Security. +- **EndpointSecurityDriver**: Actúa como el "punto de entrada" para la extensión del kernel. Es el principal punto de interacción entre el OS y el marco de Endpoint Security. - **EndpointSecurityEventManager**: Este componente es responsable de implementar ganchos del kernel. Los ganchos del kernel permiten que el marco monitoree eventos del sistema interceptando llamadas al sistema. - **EndpointSecurityClientManager**: Este gestiona la comunicación con los clientes del espacio de usuario, manteniendo un registro de qué clientes están conectados y necesitan recibir notificaciones de eventos. - **EndpointSecurityMessageManager**: Este envía mensajes y notificaciones de eventos a los clientes del espacio de usuario. Los eventos que el marco de Endpoint Security puede monitorear se clasifican en: -- Eventos de archivos -- Eventos de procesos -- Eventos de sockets +- Eventos de archivo +- Eventos de proceso +- Eventos de socket - Eventos del kernel (como cargar/descargar una extensión del kernel o abrir un dispositivo de I/O Kit) ### Arquitectura del Endpoint Security Framework diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/README.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/README.md index 4b319b516..fc2d791a6 100644 --- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/README.md +++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/README.md @@ -124,7 +124,7 @@ Los parámetros que esta función espera son: - El primer parámetro (**self**) es "un puntero que apunta a la **instancia de la clase que debe recibir el mensaje**". O más simplemente, es el objeto sobre el cual se invoca el método. Si el método es un método de clase, esto será una instancia del objeto de la clase (en su totalidad), mientras que para un método de instancia, self apuntará a una instancia instanciada de la clase como un objeto. - El segundo parámetro, (**op**), es "el selector del método que maneja el mensaje". Nuevamente, más simplemente, esto es solo el **nombre del método.** -- Los parámetros restantes son cualquier **valor que requiera el método** (op). +- Los parámetros restantes son cualquier **valor que sea requerido por el método** (op). Vea cómo **obtener esta información fácilmente con `lldb` en ARM64** en esta página: @@ -137,12 +137,12 @@ x64: | **Argumento** | **Registro** | **(para) objc_msgSend** | | ----------------- | -------------------------------------------------------------- | ------------------------------------------------------ | | **1er argumento** | **rdi** | **self: objeto sobre el cual se invoca el método** | -| **2do argumento** | **rsi** | **op: nombre del método** | -| **3er argumento** | **rdx** | **1er argumento al método** | -| **4to argumento** | **rcx** | **2do argumento al método** | -| **5to argumento** | **r8** | **3er argumento al método** | -| **6to argumento** | **r9** | **4to argumento al método** | -| **7mo+ argumento** |

rsp+
(en la pila)

| **5to+ argumento al método** | +| **2do argumento** | **rsi** | **op: nombre del método** | +| **3er argumento** | **rdx** | **1er argumento al método** | +| **4to argumento** | **rcx** | **2do argumento al método** | +| **5to argumento** | **r8** | **3er argumento al método** | +| **6to argumento** | **r9** | **4to argumento al método** | +| **7mo+ argumento** |

rsp+
(en la pila)

| **5to+ argumento al método** | ### Volcar metadatos de ObjectiveC @@ -236,7 +236,7 @@ Su plist se encuentra en `/System/Library/LaunchDaemons/com.apple.sysdiagnose.pl MacOS genera muchos registros que pueden ser muy útiles al ejecutar una aplicación tratando de entender **qué está haciendo**. -Además, hay algunos registros que contendrán la etiqueta `` para **ocultar** información **identificable** de **usuario** o **computadora**. Sin embargo, es posible **instalar un certificado para divulgar esta información**. Siga las explicaciones de [**aquí**](https://superuser.com/questions/1532031/how-to-show-private-data-in-macos-unified-log). +Además, hay algunos registros que contendrán la etiqueta `` para **ocultar** información **identificable** del **usuario** o **computadora**. Sin embargo, es posible **instalar un certificado para divulgar esta información**. Siga las explicaciones de [**aquí**](https://superuser.com/questions/1532031/how-to-show-private-data-in-macos-unified-log). ### Hopper @@ -254,7 +254,7 @@ Al hacer clic derecho en un objeto de código, puede ver **referencias a/desde e
-Además, en la **parte inferior del medio puede escribir comandos de python**. +Además, en la **parte media inferior puede escribir comandos de python**. #### Panel derecho @@ -262,7 +262,7 @@ En el panel derecho puede ver información interesante como el **historial de na ### dtrace -Permite a los usuarios acceder a aplicaciones a un nivel **muy bajo** y proporciona una forma para que los usuarios **rastreen** **programas** e incluso cambien su flujo de ejecución. Dtrace utiliza **probes** que están **colocados a lo largo del kernel** y están en ubicaciones como el inicio y el final de las llamadas al sistema. +Permite a los usuarios acceder a aplicaciones a un nivel **muy bajo** y proporciona una forma para que los usuarios **rastreen** **programas** e incluso cambien su flujo de ejecución. Dtrace utiliza **probes** que están **colocadas a lo largo del kernel** y están en ubicaciones como el inicio y el final de las llamadas al sistema. DTrace utiliza la función **`dtrace_probe_create`** para crear un probe para cada llamada al sistema. Estos probes pueden activarse en el **punto de entrada y salida de cada llamada al sistema**. La interacción con DTrace ocurre a través de /dev/dtrace que solo está disponible para el usuario root. @@ -343,14 +343,14 @@ Es una herramienta de trazado del kernel. Los códigos documentados se pueden en Herramientas como `latency`, `sc_usage`, `fs_usage` y `trace` la utilizan internamente. -Para interactuar con `kdebug`, se usa `sysctl` sobre el espacio de nombres `kern.kdebug` y los MIBs que se pueden usar se encuentran en `sys/sysctl.h`, teniendo las funciones implementadas en `bsd/kern/kdebug.c`. +Para interactuar con `kdebug`, se usa `sysctl` sobre el espacio de nombres `kern.kdebug` y los MIBs que se pueden encontrar en `sys/sysctl.h`, teniendo las funciones implementadas en `bsd/kern/kdebug.c`. Para interactuar con kdebug con un cliente personalizado, estos son generalmente los pasos: - Eliminar configuraciones existentes con KERN_KDSETREMOVE -- Establecer trazado con KERN_KDSETBUF y KERN_KDSETUP +- Establecer traza con KERN_KDSETBUF y KERN_KDSETUP - Usar KERN_KDGETBUF para obtener el número de entradas del búfer -- Obtener el propio cliente del trazado con KERN_KDPINDEX +- Obtener el propio cliente de la traza con KERN_KDPINDEX - Habilitar el trazado con KERN_KDENABLE - Leer el búfer llamando a KERN_KDREADTR - Para emparejar cada hilo con su proceso, llamar a KERN_KDTHRMAP. @@ -438,7 +438,51 @@ settings set target.x86-disassembly-flavor intel > [!WARNING] > Dentro de lldb, volcar un proceso con `process save-core` -
(lldb) ComandoDescripción
run (r)Iniciar la ejecución, que continuará sin interrupciones hasta que se alcance un punto de interrupción o el proceso termine.
process launch --stop-at-entryIniciar la ejecución deteniéndose en el punto de entrada
continue (c)Continuar la ejecución del proceso depurado.
nexti (n / ni)Ejecutar la siguiente instrucción. Este comando omitirá las llamadas a funciones.
stepi (s / si)Ejecutar la siguiente instrucción. A diferencia del comando nexti, este comando entrará en las llamadas a +
(lldb) ComandoDescripción
run (r)Iniciar la ejecución, que continuará sin interrupciones hasta que se alcance un punto de interrupción o el proceso termine.
process launch --stop-at-entryIniciar la ejecución deteniéndose en el punto de entrada
continue (c)Continuar la ejecución del proceso depurado.
nexti (n / ni)Ejecutar la siguiente instrucción. Este comando omitirá las llamadas a funciones.
stepi (s / si)Ejecutar la siguiente instrucción. A diferencia del comando nexti, este comando entrará en las llamadas a funciones.
finish (f)Ejecutar el resto de las instrucciones en la función actual (“frame”) y detenerse.
control + cPausar la ejecución. Si el proceso ha sido ejecutado (r) o continuado (c), esto hará que el proceso se detenga ...donde sea que esté ejecutándose actualmente.
breakpoint (b)

b main #Cualquier función llamada main

b <binname>`main #Función principal del bin

b set -n main --shlib <lib_name> #Función principal del bin indicado

breakpoint set -r '\[NSFileManager .*\]$' #Cualquier método de NSFileManager

breakpoint set -r '\[NSFileManager contentsOfDirectoryAtPath:.*\]$'

break set -r . -s libobjc.A.dylib # Romper en todas las funciones de esa biblioteca

b -a 0x0000000100004bd9

br l #Lista de puntos de interrupción

br e/dis <num> #Habilitar/Deshabilitar punto de interrupción

breakpoint delete <num>

help

help breakpoint #Obtener ayuda del comando de punto de interrupción

help memory write #Obtener ayuda para escribir en la memoria

reg

reg read

reg read $rax

reg read $rax --format <formato>

reg write $rip 0x100035cc0

x/s <reg/dirección de memoria>Mostrar la memoria como una cadena terminada en nulo.
x/i <reg/dirección de memoria>Mostrar la memoria como instrucción de ensamblador.
x/b <reg/dirección de memoria>Mostrar la memoria como byte.
print object (po)

Esto imprimirá el objeto referenciado por el parámetro

po $raw

{

dnsChanger = {

"affiliate" = "";

"blacklist_dns" = ();

Nota que la mayoría de las APIs o métodos de Objective-C de Apple devuelven objetos, y por lo tanto deben ser mostrados a través del comando “print object” (po). Si po no produce una salida significativa, usa x/b

memorymemory read 0x000....
memory read $x0+0xf2a
memory write 0x100600000 -s 4 0x41414141 #Escribir AAAA en esa dirección
memory write -f s $rip+0x11f+7 "AAAA" #Escribir AAAA en la dirección
disassembly

dis #Desensamblar función actual

dis -n <funcname> #Desensamblar función

dis -n <funcname> -b <basename> #Desensamblar función
dis -c 6 #Desensamblar 6 líneas
dis -c 0x100003764 -e 0x100003768 # Desde una dirección hasta la otra
dis -p -c 4 # Comenzar en la dirección actual desensamblando

parrayparray 3 (char **)$x1 # Verificar array de 3 componentes en el registro x1
image dump sectionsImprimir mapa de la memoria del proceso actual
image dump symtab <library>image dump symtab CoreNLP #Obtener la dirección de todos los símbolos de CoreNLP
+ +> [!NOTE] +> Al llamar a la función **`objc_sendMsg`**, el registro **rsi** contiene el **nombre del método** como una cadena terminada en nulo (“C”). Para imprimir el nombre a través de lldb haz: +> +> `(lldb) x/s $rsi: 0x1000f1576: "startMiningWithPort:password:coreCount:slowMemory:currency:"` +> +> `(lldb) print (char*)$rsi:`\ +> `(char *) $1 = 0x00000001000f1576 "startMiningWithPort:password:coreCount:slowMemory:currency:"` +> +> `(lldb) reg read $rsi: rsi = 0x00000001000f1576 "startMiningWithPort:password:coreCount:slowMemory:currency:"` + +### Análisis Dinámico Anti + +#### Detección de VM + +- El comando **`sysctl hw.model`** devuelve "Mac" cuando el **host es un MacOS** pero algo diferente cuando es una VM. +- Jugando con los valores de **`hw.logicalcpu`** y **`hw.physicalcpu`**, algunos malwares intentan detectar si es una VM. +- Algunos malwares también pueden **detectar** si la máquina está basada en **VMware** según la dirección MAC (00:50:56). +- También es posible encontrar **si un proceso está siendo depurado** con un código simple como: +- `if(P_TRACED == (info.kp_proc.p_flag & P_TRACED)){ //proceso siendo depurado }` +- También puede invocar la llamada al sistema **`ptrace`** con la bandera **`PT_DENY_ATTACH`**. Esto **previene** que un depurador se adjunte y rastree. +- Puedes verificar si la función **`sysctl`** o **`ptrace`** está siendo **importada** (pero el malware podría importarla dinámicamente) +- Como se señala en este informe, “[Defeating Anti-Debug Techniques: macOS ptrace variants](https://alexomara.com/blog/defeating-anti-debug-techniques-macos-ptrace-variants/)” :\ +“_El mensaje Process # exited with **status = 45 (0x0000002d)** es generalmente una señal reveladora de que el objetivo de depuración está usando **PT_DENY_ATTACH**_” + +## Volcados de Núcleo + +Los volcados de núcleo se crean si: + +- `kern.coredump` sysctl está configurado en 1 (por defecto) +- Si el proceso no era suid/sgid o `kern.sugid_coredump` es 1 (por defecto es 0) +- El límite `AS_CORE` permite la operación. Es posible suprimir la creación de volcados de núcleo llamando a `ulimit -c 0` y reactivarlos con `ulimit -c unlimited`. + +En esos casos, el volcado de núcleo se genera de acuerdo con `kern.corefile` sysctl y se almacena generalmente en `/cores/core/.%P`. + +## Fuzzing + +### [ReportCrash](https://ss64.com/osx/reportcrash.html) + +ReportCrash **analiza procesos que fallan y guarda un informe de fallos en el disco**. Un informe de fallos contiene información que puede **ayudar a un desarrollador a diagnosticar** la causa de un fallo.\ +Para aplicaciones y otros procesos **que se ejecutan en el contexto de launchd por usuario**, ReportCrash se ejecuta como un LaunchAgent y guarda informes de fallos en `~/Library/Logs/DiagnosticReports/` del usuario.\ +Para demonios, otros procesos **que se ejecutan en el contexto de launchd del sistema** y otros procesos privilegiados, ReportCrash se ejecuta como un LaunchDaemon y guarda informes de fallos en `/Library/Logs/DiagnosticReports` del sistema. + +Si te preocupa que los informes de fallos **se envíen a Apple**, puedes desactivarlos. Si no, los informes de fallos pueden ser útiles para **averiguar cómo se cayó un servidor**. ```bash #To disable crash reporting: launchctl unload -w /System/Library/LaunchAgents/com.apple.ReportCrash.plist @@ -456,7 +500,7 @@ Mientras se realiza fuzzing en MacOS, es importante no permitir que el Mac entre - pmset, Preferencias del Sistema - [KeepingYouAwake](https://github.com/newmarcel/KeepingYouAwake) -#### Desconexión SSH +#### Desconexión de SSH Si estás realizando fuzzing a través de una conexión SSH, es importante asegurarte de que la sesión no se desconecte. Así que cambia el archivo sshd_config con: @@ -496,7 +540,7 @@ lldb -o "target create `which some-binary`" -o "settings set target.env-vars DYL #### [AFL++](https://github.com/AFLplusplus/AFLplusplus) -Funciona para herramientas de CLI +Funciona para herramientas de línea de comandos #### [Litefuzz](https://github.com/sec-tools/litefuzz) diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md index f1f12bc95..32441a53b 100644 --- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md +++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md @@ -23,7 +23,7 @@ El uso de estos niveles permite una forma estructurada y segura de gestionar dif ## **Registros (ARM64v8)** -ARM64 tiene **31 registros de propósito general**, etiquetados de `x0` a `x30`. Cada uno puede almacenar un valor de **64 bits** (8 bytes). Para operaciones que requieren solo valores de 32 bits, los mismos registros se pueden acceder en un modo de 32 bits utilizando los nombres w0 a w30. +ARM64 tiene **31 registros de propósito general**, etiquetados de `x0` a `x30`. Cada uno puede almacenar un valor de **64 bits** (8 bytes). Para operaciones que requieren solo valores de 32 bits, los mismos registros se pueden acceder en un modo de 32 bits usando los nombres w0 a w30. 1. **`x0`** a **`x7`** - Estos se utilizan típicamente como registros temporales y para pasar parámetros a subrutinas. - **`x0`** también lleva los datos de retorno de una función. @@ -40,14 +40,14 @@ ARM64 tiene **31 registros de propósito general**, etiquetados de `x0` a `x30`. - Si la función actual va a llamar a una nueva función y, por lo tanto, sobrescribir `lr`, lo almacenará en la pila al principio, este es el epílogo (`stp x29, x30 , [sp, #-48]; mov x29, sp` -> Almacenar `fp` y `lr`, generar espacio y obtener nuevo `fp`) y lo recuperará al final, este es el prólogo (`ldp x29, x30, [sp], #48; ret` -> Recuperar `fp` y `lr` y retornar). 9. **`sp`** - **Puntero de Pila**, utilizado para hacer un seguimiento de la parte superior de la pila. - El valor de **`sp`** siempre debe mantenerse con al menos una **alineación de cuádruple palabra** o puede ocurrir una excepción de alineación. -10. **`pc`** - **Contador de Programa**, que apunta a la siguiente instrucción. Este registro solo puede ser actualizado a través de la generación de excepciones, retornos de excepciones y saltos. Las únicas instrucciones ordinarias que pueden leer este registro son las instrucciones de salto con enlace (BL, BLR) para almacenar la dirección **`pc`** en **`lr`** (Registro de Enlace). -11. **`xzr`** - **Registro Cero**. También se llama **`wzr`** en su forma de registro de **32** bits. Puede ser utilizado para obtener fácilmente el valor cero (operación común) o para realizar comparaciones utilizando **`subs`** como **`subs XZR, Xn, #10`** almacenando los datos resultantes en ningún lado (en **`xzr`**). +10. **`pc`** - **Contador de Programa**, que apunta a la siguiente instrucción. Este registro solo puede ser actualizado a través de generaciones de excepciones, retornos de excepciones y saltos. Las únicas instrucciones ordinarias que pueden leer este registro son las instrucciones de salto con enlace (BL, BLR) para almacenar la dirección **`pc`** en **`lr`** (Registro de Enlace). +11. **`xzr`** - **Registro Cero**. También se llama **`wzr`** en su forma de registro de **32** bits. Puede ser utilizado para obtener fácilmente el valor cero (operación común) o para realizar comparaciones usando **`subs`** como **`subs XZR, Xn, #10`** almacenando los datos resultantes en ningún lado (en **`xzr`**). Los registros **`Wn`** son la versión de **32 bits** del registro **`Xn`**. ### Registros SIMD y de Punto Flotante -Además, hay otros **32 registros de 128 bits** que se pueden utilizar en operaciones optimizadas de datos múltiples de una sola instrucción (SIMD) y para realizar aritmética de punto flotante. Estos se llaman registros Vn, aunque también pueden operar en **64** bits, **32** bits, **16** bits y **8** bits y luego se llaman **`Qn`**, **`Dn`**, **`Sn`**, **`Hn`** y **`Bn`**. +Además, hay otros **32 registros de 128 bits** que pueden ser utilizados en operaciones optimizadas de múltiples datos de instrucción única (SIMD) y para realizar aritmética de punto flotante. Estos se llaman registros Vn, aunque también pueden operar en **64** bits, **32** bits, **16** bits y **8** bits y entonces se llaman **`Qn`**, **`Dn`**, **`Sn`**, **`Hn`** y **`Bn`**. ### Registros del Sistema @@ -62,7 +62,7 @@ A menudo se utilizan para almacenar la **dirección base de la región de almace ### **PSTATE** -**PSTATE** contiene varios componentes del proceso serializados en el registro especial visible para el sistema operativo **`SPSR_ELx`**, siendo X el **nivel de permiso** **de la excepción** desencadenada (esto permite recuperar el estado del proceso cuando la excepción termina).\ +**PSTATE** contiene varios componentes del proceso serializados en el registro especial visible para el sistema operativo **`SPSR_ELx`**, siendo X el **nivel de permiso** **del** excepción desencadenada (esto permite recuperar el estado del proceso cuando la excepción termina).\ Estos son los campos accesibles:
@@ -70,7 +70,7 @@ Estos son los campos accesibles: - Las **banderas de condición `N`**, `Z`, `C` y `V`: - **`N`** significa que la operación produjo un resultado negativo. - **`Z`** significa que la operación produjo cero. -- **`C`** significa que la operación tuvo acarreo. +- **`C`** significa que la operación llevó. - **`V`** significa que la operación produjo un desbordamiento con signo: - La suma de dos números positivos produce un resultado negativo. - La suma de dos números negativos produce un resultado positivo. @@ -85,7 +85,7 @@ Estos son los campos accesibles: - La **bandera de paso único** (**`SS`**): Utilizada por depuradores para realizar un paso único configurando la bandera SS a 1 dentro de **`SPSR_ELx`** a través de una excepción. El programa ejecutará un paso y emitirá una excepción de paso único. - La **bandera de estado de excepción ilegal** (**`IL`**): Se utiliza para marcar cuando un software privilegiado realiza una transferencia de nivel de excepción inválida, esta bandera se establece en 1 y el procesador desencadena una excepción de estado ilegal. - Las **banderas `DAIF`**: Estas banderas permiten a un programa privilegiado enmascarar selectivamente ciertas excepciones externas. -- Si **`A`** es 1, significa que se desencadenarán **abortos asíncronos**. La **`I`** configura la respuesta a las **Solicitudes de Interrupción** (IRQ) de hardware externas. y la F está relacionada con las **Solicitudes de Interrupción Rápida** (FIR). +- Si **`A`** es 1, significa que se desencadenarán **abortos asíncronos**. La **`I`** configura la respuesta a las **Solicitudes de Interrupción de Hardware** (IRQ). y la F está relacionada con las **Solicitudes de Interrupción Rápida** (FIR). - Las **banderas de selección de puntero de pila** (**`SPS`**): Los programas privilegiados que se ejecutan en EL1 y superiores pueden alternar entre usar su propio registro de puntero de pila y el de modelo de usuario (por ejemplo, entre `SP_EL1` y `EL0`). Este cambio se realiza escribiendo en el registro especial **`SPSel`**. Esto no se puede hacer desde EL0. ## **Convención de Llamadas (ARM64v8)** @@ -108,14 +108,14 @@ Las instrucciones ARM64 generalmente tienen el **formato `opcode dst, src1, src2 - Ejemplo: `ldr x0, [x1]` — Esto carga un valor de la ubicación de memoria apuntada por `x1` en `x0`. - **Modo de desplazamiento**: Se indica un desplazamiento que afecta al puntero de origen, por ejemplo: - `ldr x2, [x1, #8]`, esto cargará en x2 el valor de x1 + 8. -- `ldr x2, [x0, x1, lsl #2]`, esto cargará en x2 un objeto del array x0, desde la posición x1 (índice) * 4. +- `ldr x2, [x0, x1, lsl #2]`, esto cargará en x2 un objeto del array x0, desde la posición x1 (índice) \* 4. - **Modo pre-indexado**: Esto aplicará cálculos al origen, obtendrá el resultado y también almacenará el nuevo origen en el origen. - `ldr x2, [x1, #8]!`, esto cargará `x1 + 8` en `x2` y almacenará en x1 el resultado de `x1 + 8`. - `str lr, [sp, #-4]!`, Almacena el registro de enlace en sp y actualiza el registro sp. - **Modo post-indexado**: Esto es como el anterior, pero se accede a la dirección de memoria y luego se calcula y almacena el desplazamiento. - `ldr x0, [x1], #8`, carga `x1` en `x0` y actualiza x1 con `x1 + 8`. - **Dirección relativa al PC**: En este caso, la dirección a cargar se calcula en relación con el registro PC. -- `ldr x1, =_start`, Esto cargará la dirección donde comienza el símbolo `_start` en x1 en relación con el PC actual. +- `ldr x1, =_start`, Esto cargará la dirección donde comienza el símbolo `_start` en x1 relacionado con el PC actual. - **`str`**: **Almacenar** un valor de un **registro** en **memoria**. - Ejemplo: `str x0, [x1]` — Esto almacena el valor en `x0` en la ubicación de memoria apuntada por `x1`. - **`ldp`**: **Cargar Par de Registros**. Esta instrucción **carga dos registros** desde **ubicaciones de memoria** consecutivas. La dirección de memoria se forma típicamente sumando un desplazamiento al valor en otro registro. @@ -130,7 +130,7 @@ Las instrucciones ARM64 generalmente tienen el **formato `opcode dst, src1, src2 - Xn3 | #imm -> Operando 2 (registro o inmediato) - \[shift #N | RRX] -> Realizar un desplazamiento o llamar a RRX. - Ejemplo: `add x0, x1, x2` — Esto suma los valores en `x1` y `x2` y almacena el resultado en `x0`. -- `add x5, x5, #1, lsl #12` — Esto es igual a 4096 (un 1 desplazado 12 veces) -> 1 0000 0000 0000 0000. +- `add x5, x5, #1, lsl #12` — Esto equivale a 4096 (un 1 desplazado 12 veces) -> 1 0000 0000 0000 0000. - **`adds`** Esto realiza un `add` y actualiza las banderas. - **`sub`**: **Restar** los valores de dos registros y almacenar el resultado en un registro. - Verifique la **sintaxis de `add`**. @@ -143,7 +143,7 @@ Las instrucciones ARM64 generalmente tienen el **formato `opcode dst, src1, src2 - **`lsl`**, **`lsr`**, **`asr`**, **`ror`, `rrx`**: - **Desplazamiento lógico a la izquierda**: Agrega 0s desde el final moviendo los otros bits hacia adelante (multiplica por n veces 2). - **Desplazamiento lógico a la derecha**: Agrega 1s al principio moviendo los otros bits hacia atrás (divide por n veces 2 en sin signo). -- **Desplazamiento aritmético a la derecha**: Como **`lsr`**, pero en lugar de agregar 0s si el bit más significativo es un 1, se agregan 1s (divide por n veces 2 en con signo). +- **Desplazamiento aritmético a la derecha**: Como **`lsr`**, pero en lugar de agregar 0s, si el bit más significativo es un 1, se agregan 1s (divide por n veces 2 en con signo). - **Rotar a la derecha**: Como **`lsr`** pero lo que se elimina de la derecha se agrega a la izquierda. - **Rotar a la derecha con extensión**: Como **`ror`**, pero con la bandera de acarreo como el "bit más significativo". Así que la bandera de acarreo se mueve al bit 31 y el bit eliminado a la bandera de acarreo. - **`bfm`**: **Movimiento de Campo de Bits**, estas operaciones **copian bits `0...n`** de un valor y los colocan en posiciones **`m..m+n`**. El **`#s`** especifica la **posición del bit más a la izquierda** y **`#r`** la **cantidad de rotación a la derecha**. @@ -157,17 +157,17 @@ Las instrucciones ARM64 generalmente tienen el **formato `opcode dst, src1, src2 - **`SBFX X1, X2, #3, #4`** Extrae 4 bits comenzando en el bit 3 de X2, extiende el signo y coloca el resultado en X1. - **`UBFIZ X1, X2, #3, #4`** Extiende a cero 4 bits de X2 e inserta en X1 comenzando en la posición de bit 3, poniendo a cero los bits de la derecha. - **`UBFX X1, X2, #3, #4`** Extrae 4 bits comenzando en el bit 3 de X2 y coloca el resultado extendido a cero en X1. -- **Extender Signo a X:** Extiende el signo (o solo agrega 0s en la versión sin signo) de un valor para poder realizar operaciones con él: +- **Extender Signo a X:** Extiende el signo (o simplemente agrega 0s en la versión sin signo) de un valor para poder realizar operaciones con él: - **`SXTB X1, W2`** Extiende el signo de un byte **de W2 a X1** (`W2` es la mitad de `X2`) para llenar los 64 bits. - **`SXTH X1, W2`** Extiende el signo de un número de 16 bits **de W2 a X1** para llenar los 64 bits. - **`SXTW X1, W2`** Extiende el signo de un byte **de W2 a X1** para llenar los 64 bits. - **`UXTB X1, W2`** Agrega 0s (sin signo) a un byte **de W2 a X1** para llenar los 64 bits. -- **`extr`:** Extrae bits de un **par de registros concatenados** especificados. +- **`extr`:** Extrae bits de un **par de registros especificados concatenados**. - Ejemplo: `EXTR W3, W2, W1, #3` Esto **concatena W1+W2** y obtiene **desde el bit 3 de W2 hasta el bit 3 de W1** y lo almacena en W3. - **`cmp`**: **Comparar** dos registros y establecer banderas de condición. Es un **alias de `subs`** estableciendo el registro de destino en el registro cero. Útil para saber si `m == n`. - Soporta la **misma sintaxis que `subs`**. - Ejemplo: `cmp x0, x1` — Esto compara los valores en `x0` y `x1` y establece las banderas de condición en consecuencia. -- **`cmn`**: **Comparar** el operando negativo. En este caso, es un **alias de `adds`** y soporta la misma sintaxis. Útil para saber si `m == -n`. +- **`cmn`**: **Comparar el operando negativo**. En este caso, es un **alias de `adds`** y soporta la misma sintaxis. Útil para saber si `m == -n`. - **`ccmp`**: Comparación condicional, es una comparación que se realizará solo si una comparación anterior fue verdadera y establecerá específicamente los bits nzcv. - `cmp x1, x2; ccmp x3, x4, 0, NE; blt _func` -> si x1 != x2 y x3 < x4, salta a func. - Esto se debe a que **`ccmp`** solo se ejecutará si la **anterior `cmp` fue un `NE`**, si no lo fue, los bits `nzcv` se establecerán en 0 (lo que no satisfará la comparación `blt`). @@ -178,17 +178,17 @@ Las instrucciones ARM64 generalmente tienen el **formato `opcode dst, src1, src2 - **`b`**: Salto incondicional. - Ejemplo: `b myFunction`. - Tenga en cuenta que esto no llenará el registro de enlace con la dirección de retorno (no es adecuado para llamadas a subrutinas que necesitan regresar). -- **`bl`**: **Branch** con enlace, utilizado para **llamar** a una **subrutina**. Almacena la **dirección de retorno en `x30`**. +- **`bl`**: **Salto** con enlace, utilizado para **llamar** a una **subrutina**. Almacena la **dirección de retorno en `x30`**. - Ejemplo: `bl myFunction` — Esto llama a la función `myFunction` y almacena la dirección de retorno en `x30`. - Tenga en cuenta que esto no llenará el registro de enlace con la dirección de retorno (no es adecuado para llamadas a subrutinas que necesitan regresar). -- **`blr`**: **Branch** con enlace a registro, utilizado para **llamar** a una **subrutina** donde el objetivo está **especificado** en un **registro**. Almacena la dirección de retorno en `x30`. +- **`blr`**: **Salto** con enlace a registro, utilizado para **llamar** a una **subrutina** donde el objetivo está **especificado** en un **registro**. Almacena la dirección de retorno en `x30`. - Ejemplo: `blr x1` — Esto llama a la función cuya dirección está contenida en `x1` y almacena la dirección de retorno en `x30`. - **`ret`**: **Retornar** de **subrutina**, típicamente usando la dirección en **`x30`**. - Ejemplo: `ret` — Esto retorna de la subrutina actual usando la dirección de retorno en `x30`. - **`b.`**: Saltos condicionales. -- **`b.eq`**: **Branch si es igual**, basado en la instrucción `cmp` anterior. +- **`b.eq`**: **Salto si es igual**, basado en la instrucción `cmp` anterior. - Ejemplo: `b.eq label` — Si la instrucción `cmp` anterior encontró dos valores iguales, esto salta a `label`. -- **`b.ne`**: **Branch si no es igual**. Esta instrucción verifica las banderas de condición (que fueron establecidas por una instrucción de comparación anterior), y si los valores comparados no eran iguales, salta a una etiqueta o dirección. +- **`b.ne`**: **Salto si no es igual**. Esta instrucción verifica las banderas de condición (que fueron establecidas por una instrucción de comparación anterior), y si los valores comparados no eran iguales, salta a una etiqueta o dirección. - Ejemplo: Después de una instrucción `cmp x0, x1`, `b.ne label` — Si los valores en `x0` y `x1` no eran iguales, esto salta a `label`. - **`cbz`**: **Comparar y saltar si es cero**. Esta instrucción compara un registro con cero, y si son iguales, salta a una etiqueta o dirección. - Ejemplo: `cbz x0, label` — Si el valor en `x0` es cero, esto salta a `label`. @@ -210,8 +210,8 @@ Las instrucciones ARM64 generalmente tienen el **formato `opcode dst, src1, src2 - `csetm Xd, Xn, Xm, cond` -> Si es verdadero, Xd = \, si es falso, Xd = 0. - **`adrp`**: Calcular la **dirección de página de un símbolo** y almacenarla en un registro. - Ejemplo: `adrp x0, symbol` — Esto calcula la dirección de página de `symbol` y la almacena en `x0`. -- **`ldrsw`**: **Cargar** un valor **32 bits** con signo de la memoria y **extenderlo a 64** bits. -- Ejemplo: `ldrsw x0, [x1]` — Esto carga un valor de 32 bits con signo de la ubicación de memoria apuntada por `x1`, lo extiende a 64 bits y lo almacena en `x0`. +- **`ldrsw`**: **Cargar** un valor **firmado de 32 bits** de la memoria y **extenderlo a 64** bits. +- Ejemplo: `ldrsw x0, [x1]` — Esto carga un valor firmado de 32 bits de la ubicación de memoria apuntada por `x1`, lo extiende a 64 bits y lo almacena en `x0`. - **`stur`**: **Almacenar un valor de registro en una ubicación de memoria**, utilizando un desplazamiento de otro registro. - Ejemplo: `stur x0, [x1, #4]` — Esto almacena el valor en `x0` en la dirección de memoria que es 4 bytes mayor que la dirección actualmente en `x1`. - **`svc`** : Realizar una **llamada al sistema**. Significa "Supervisor Call". Cuando el procesador ejecuta esta instrucción, **cambia de modo usuario a modo núcleo** y salta a una ubicación específica en memoria donde se encuentra el **código de manejo de llamadas al sistema del núcleo**. @@ -246,7 +246,7 @@ ldp x29, x30, [sp], #16 ; load pair x29 and x30 from the stack and increment th Armv8-A soporta la ejecución de programas de 32 bits. **AArch32** puede ejecutarse en uno de **dos conjuntos de instrucciones**: **`A32`** y **`T32`** y puede cambiar entre ellos a través de **`interworking`**.\ Los programas **privilegiados** de 64 bits pueden programar la **ejecución de programas de 32 bits** al ejecutar una transferencia de nivel de excepción al de 32 bits de menor privilegio.\ -Tenga en cuenta que la transición de 64 bits a 32 bits ocurre con una disminución del nivel de excepción (por ejemplo, un programa de 64 bits en EL1 que activa un programa en EL0). Esto se hace configurando el **bit 4 de** **`SPSR_ELx`** registro especial **a 1** cuando el hilo de proceso `AArch32` está listo para ser ejecutado y el resto de `SPSR_ELx` almacena el CPSR de los programas **`AArch32`**. Luego, el proceso privilegiado llama a la instrucción **`ERET`** para que el procesador transicione a **`AArch32`** ingresando en A32 o T32 dependiendo de CPSR\*\*.\*\* +Tenga en cuenta que la transición de 64 bits a 32 bits ocurre con una disminución del nivel de excepción (por ejemplo, un programa de 64 bits en EL1 activando un programa en EL0). Esto se hace configurando el **bit 4 de** **`SPSR_ELx`** registro especial **a 1** cuando el hilo de proceso `AArch32` está listo para ser ejecutado y el resto de `SPSR_ELx` almacena el CPSR de los programas **`AArch32`**. Luego, el proceso privilegiado llama a la instrucción **`ERET`** para que el procesador transicione a **`AArch32`** ingresando en A32 o T32 dependiendo de CPSR\*\*.\*\* El **`interworking`** ocurre utilizando los bits J y T de CPSR. `J=0` y `T=0` significa **`A32`** y `J=0` y `T=1` significa **T32**. Esto se traduce básicamente en establecer el **bit más bajo a 1** para indicar que el conjunto de instrucciones es T32.\ Esto se establece durante las **instrucciones de rama de interworking**, pero también se puede establecer directamente con otras instrucciones cuando el PC se establece como el registro de destino. Ejemplo: @@ -299,9 +299,9 @@ La instrucción **`SEL`** utiliza estas banderas GE para realizar acciones condi #### Registros de Estado de Ejecución - Los bits **`J`** y **`T`**: **`J`** debe ser 0 y si **`T`** es 0 se utiliza el conjunto de instrucciones A32, y si es 1, se utiliza el T32. -- **Registro de Estado del Bloque IT** (`ITSTATE`): Estos son los bits del 10 al 15 y del 25 al 26. Almacenan condiciones para instrucciones dentro de un grupo con prefijo **`IT`**. +- **Registro de Estado del Bloque IT** (`ITSTATE`): Estos son los bits del 10-15 y 25-26. Almacenan condiciones para instrucciones dentro de un grupo con prefijo **`IT`**. - Bit **`E`**: Indica el **endianness**. -- Bits de Modo y Máscara de Excepción (0-4): Determinan el estado de ejecución actual. El **5to** indica si el programa se ejecuta como 32 bits (un 1) o 64 bits (un 0). Los otros 4 representan el **modo de excepción actualmente en uso** (cuando ocurre una excepción y se está manejando). El número establecido **indica la prioridad actual** en caso de que se desencadene otra excepción mientras se está manejando esta. +- Bits de Modo y Máscara de Excepción (0-4): Determinan el estado de ejecución actual. El **quinto** indica si el programa se ejecuta como 32 bits (un 1) o 64 bits (un 0). Los otros 4 representan el **modo de excepción actualmente en uso** (cuando ocurre una excepción y se está manejando). El número establecido **indica la prioridad actual** en caso de que se desencadene otra excepción mientras se está manejando esta.
@@ -693,7 +693,7 @@ mov x2, xzr mov x16, #59 svc #0x1337 ``` -#### Reverse shell +#### Shell inversa Desde [https://github.com/daem0nc0re/macOS_ARM64_Shellcode/blob/master/reverseshell.s](https://github.com/daem0nc0re/macOS_ARM64_Shellcode/blob/master/reverseshell.s), revshell a **127.0.0.1:4444** ```armasm diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/introduction-to-x64.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/introduction-to-x64.md index 7809208c4..5da9e4ae8 100644 --- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/introduction-to-x64.md +++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/introduction-to-x64.md @@ -17,7 +17,7 @@ x64 se expande sobre la arquitectura x86, presentando **16 registros de propósi 5. **`rbp`** - **Puntero base** para el marco de pila. 6. **`rsp`** - **Puntero de pila**, que mantiene el seguimiento de la parte superior de la pila. 7. **`rsi`** y **`rdi`** - Utilizados para índices de **origen** y **destino** en operaciones de cadena/memoria. -8. **`r8`** a **`r15`** - Registros de propósito general adicionales introducidos en x64. +8. **`r8`** a **`r15`** - Registros adicionales de propósito general introducidos en x64. ### **Convención de Llamadas** @@ -34,11 +34,11 @@ Swift tiene su propia **convención de llamadas** que se puede encontrar en [**h ### **Instrucciones Comunes** -Las instrucciones x64 tienen un conjunto rico, manteniendo la compatibilidad con las instrucciones x86 anteriores e introduciendo nuevas. +Las instrucciones x64 tienen un conjunto rico, manteniendo la compatibilidad con instrucciones x86 anteriores e introduciendo nuevas. - **`mov`**: **Mover** un valor de un **registro** o **ubicación de memoria** a otro. - Ejemplo: `mov rax, rbx` — Mueve el valor de `rbx` a `rax`. -- **`push`** y **`pop`**: Empujar o sacar valores de/a la **pila**. +- **`push`** y **`pop`**: Empujar o sacar valores de/la **pila**. - Ejemplo: `push rax` — Empuja el valor en `rax` a la pila. - Ejemplo: `pop rax` — Saca el valor superior de la pila en `rax`. - **`add`** y **`sub`**: Operaciones de **suma** y **resta**. @@ -50,7 +50,7 @@ Las instrucciones x64 tienen un conjunto rico, manteniendo la compatibilidad con - Ejemplo: `cmp rax, rdx` — Compara `rax` con `rdx`. - **`je`, `jne`, `jl`, `jge`, ...**: Instrucciones de **salto condicional** que cambian el flujo de control basándose en los resultados de un `cmp` o prueba anterior. - Ejemplo: Después de una instrucción `cmp rax, rdx`, `je label` — Salta a `label` si `rax` es igual a `rdx`. -- **`syscall`**: Utilizado para **llamadas al sistema** en algunos sistemas x64 (como Unix moderno). +- **`syscall`**: Utilizado para **llamadas al sistema** en algunos sistemas x64 (como Unix modernos). - **`sysenter`**: Una instrucción de **llamada al sistema** optimizada en algunas plataformas. ### **Prologo de Función** diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-files-folders-and-binaries/README.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-files-folders-and-binaries/README.md index 984589a60..f357d3f8d 100644 --- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-files-folders-and-binaries/README.md +++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-files-folders-and-binaries/README.md @@ -12,7 +12,7 @@ - **/Library**: Se pueden encontrar muchas subcarpetas y archivos relacionados con preferencias, cachés y registros aquí. Una carpeta Library existe en la raíz y en el directorio de cada usuario. - **/private**: No documentado, pero muchas de las carpetas mencionadas son enlaces simbólicos al directorio privado. - **/sbin**: Binarios esenciales del sistema (relacionados con la administración) -- **/System**: Archivo para hacer funcionar OS X. Aquí deberías encontrar principalmente archivos específicos de Apple (no de terceros). +- **/System**: Archivo para hacer funcionar OS X. Aquí deberías encontrar principalmente solo archivos específicos de Apple (no de terceros). - **/tmp**: Los archivos se eliminan después de 3 días (es un enlace simbólico a /private/tmp) - **/Users**: Directorio personal para usuarios. - **/usr**: Configuración y binarios del sistema @@ -23,9 +23,9 @@ ### Carpetas de Aplicaciones - **Las aplicaciones del sistema** se encuentran en `/System/Applications` -- **Las aplicaciones instaladas** generalmente se instalan en `/Applications` o en `~/Applications` +- **Las aplicaciones instaladas** suelen estar en `/Applications` o en `~/Applications` - **Los datos de la aplicación** se pueden encontrar en `/Library/Application Support` para las aplicaciones que se ejecutan como root y `~/Library/Application Support` para aplicaciones que se ejecutan como el usuario. -- Los **demonios** de aplicaciones de terceros que **necesitan ejecutarse como root** generalmente se encuentran en `/Library/PrivilegedHelperTools/` +- Los **demonios** de aplicaciones de terceros que **necesitan ejecutarse como root** suelen estar en `/Library/PrivilegedHelperTools/` - Las aplicaciones **sandboxed** están mapeadas en la carpeta `~/Library/Containers`. Cada aplicación tiene una carpeta nombrada de acuerdo con el ID del paquete de la aplicación (`com.apple.Safari`). - El **núcleo** se encuentra en `/System/Library/Kernels/kernel` - **Las extensiones del núcleo de Apple** se encuentran en `/System/Library/Extensions` @@ -80,7 +80,7 @@ En macOS (y iOS) todas las bibliotecas compartidas del sistema, como frameworks Esto se encuentra en macOS en `/System/Volumes/Preboot/Cryptexes/OS/System/Library/dyld/` y en versiones anteriores podrías encontrar la **caché compartida** en **`/System/Library/dyld/`**.\ En iOS puedes encontrarlas en **`/System/Library/Caches/com.apple.dyld/`**. -Similar a la caché compartida de dyld, el núcleo y las extensiones del núcleo también se compilan en una caché de núcleo, que se carga al inicio. +Similar a la caché compartida de dyld, el núcleo y las extensiones del núcleo también se compilan en una caché del núcleo, que se carga al inicio. Para extraer las bibliotecas del único archivo de caché compartido de dylib, era posible usar el binario [dyld_shared_cache_util](https://www.mbsplugins.de/files/dyld_shared_cache_util-dyld-733.8.zip) que puede que no funcione hoy en día, pero también puedes usar [**dyldextractor**](https://github.com/arandomdev/dyldextractor): ```bash @@ -104,7 +104,7 @@ Algunos extractores no funcionarán ya que las dylibs están preenlazadas con di ### Mapeo de SLC -**`dyld`** utiliza la syscall **`shared_region_check_np`** para saber si el SLC ha sido mapeado (lo que devuelve la dirección) y **`shared_region_map_and_slide_np`** para mapear el SLC. +**`dyld`** utiliza la llamada al sistema **`shared_region_check_np`** para saber si el SLC ha sido mapeado (lo que devuelve la dirección) y **`shared_region_map_and_slide_np`** para mapear el SLC. Ten en cuenta que incluso si el SLC se desliza en el primer uso, todos los **procesos** utilizan la **misma copia**, lo que **elimina la protección ASLR** si el atacante pudo ejecutar procesos en el sistema. Esto fue explotado en el pasado y se solucionó con el paginador de región compartida. @@ -121,7 +121,7 @@ Usando las variables de entorno: ### Permisos de Carpeta -En una **carpeta**, **leer** permite **listar** su contenido, **escribir** permite **eliminar** y **escribir** archivos en ella, y **ejecutar** permite **traversar** el directorio. Así que, por ejemplo, un usuario con **permiso de lectura sobre un archivo** dentro de un directorio donde **no tiene permiso de ejecución** **no podrá leer** el archivo. +En una **carpeta**, **leer** permite **listar** su contenido, **escribir** permite **eliminar** y **escribir** archivos en ella, y **ejecutar** permite **traversar** el directorio. Por ejemplo, un usuario con **permiso de lectura sobre un archivo** dentro de un directorio donde **no tiene permiso de ejecución** **no podrá leer** el archivo. ### Modificadores de Bandera @@ -196,7 +196,7 @@ Los atributos extendidos tienen un nombre y cualquier valor deseado, y se pueden ### Recursos Forks | macOS ADS -Esta es una forma de obtener **Flujos de Datos Alternativos en MacOS**. Puedes guardar contenido dentro de un atributo extendido llamado **com.apple.ResourceFork** dentro de un archivo guardándolo en **file/..namedfork/rsrc**. +Esta es una forma de obtener **Flujos de Datos Alternativos en máquinas MacOS**. Puedes guardar contenido dentro de un atributo extendido llamado **com.apple.ResourceFork** dentro de un archivo guardándolo en **file/..namedfork/rsrc**. ```bash echo "Hello" > a.txt echo "Hello Mac ADS" > a.txt/..namedfork/rsrc diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-files-folders-and-binaries/macos-installers-abuse.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-files-folders-and-binaries/macos-installers-abuse.md index 17191250a..b9bd2e228 100644 --- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-files-folders-and-binaries/macos-installers-abuse.md +++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-files-folders-and-binaries/macos-installers-abuse.md @@ -61,7 +61,7 @@ Si un script de pre o post instalación está, por ejemplo, ejecutándose desde ### AuthorizationExecuteWithPrivileges -Esta es una [función pública](https://developer.apple.com/documentation/security/1540038-authorizationexecutewithprivileg) que varios instaladores y actualizadores llamarán para **ejecutar algo como root**. Esta función acepta la **ruta** del **archivo** a **ejecutar** como parámetro, sin embargo, si un atacante pudiera **modificar** este archivo, podrá **abusar** de su ejecución con root para **escalar privilegios**. +Esta es una [función pública](https://developer.apple.com/documentation/security/1540038-authorizationexecutewithprivileg) que varios instaladores y actualizadores llamarán para **ejecutar algo como root**. Esta función acepta la **ruta** del **archivo** a **ejecutar** como parámetro; sin embargo, si un atacante pudiera **modificar** este archivo, podría **abusar** de su ejecución con root para **escalar privilegios**. ```bash # Breakpoint in the function to check wich file is loaded (lldb) b AuthorizationExecuteWithPrivileges @@ -77,13 +77,13 @@ Un ejemplo de esto es **CVE-2021-26089** que logró **sobrescribir un script per ## pkg como malware -### Carga útil vacía +### Payload vacío -Es posible generar un **`.pkg`** solo con **scripts de pre y post-instalación** sin ninguna carga útil real aparte del malware dentro de los scripts. +Es posible generar un **`.pkg`** archivo con **scripts de pre y post-instalación** sin ningún payload real aparte del malware dentro de los scripts. ### JS en xml de distribución -Es posible agregar etiquetas **`