GITBOOK-3936: change request with no subject merged in GitBook
This commit is contained in:
CPol
gitbook-bot
parent
acd6b7b1e3
commit
d30ce4e500
|
|
@ -142,7 +142,7 @@
|
|||
* [macOS Dyld Hijacking & DYLD\_INSERT\_LIBRARIES](macos-hardening/macos-security-and-privilege-escalation/macos-dyld-hijacking-and-dyld\_insert\_libraries.md)
|
||||
* [macOS Architecture](macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/README.md)
|
||||
* [macOS Bundles](macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-bundles.md)
|
||||
* [macOS IPC](macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-ipc.md)
|
||||
* [macOS IPC - Inter Process Communication](macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-ipc-inter-process-communication.md)
|
||||
* [macOS Function Hooking](macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-function-hooking.md)
|
||||
* [Universal binaries & Mach-O Format](macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/universal-binaries-and-mach-o-format.md)
|
||||
* [macOS MDM](macos-hardening/macos-security-and-privilege-escalation/macos-mdm/README.md)
|
||||
|
|
|
|||
|
|
@ -84,8 +84,8 @@ kextunload com.apple.iokit.IOReportFamily
|
|||
|
||||
### IPC - Inter Process Communication
|
||||
|
||||
{% content-ref url="macos-ipc.md" %}
|
||||
[macos-ipc.md](macos-ipc.md)
|
||||
{% content-ref url="macos-ipc-inter-process-communication.md" %}
|
||||
[macos-ipc-inter-process-communication.md](macos-ipc-inter-process-communication.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
## Apple Propietary File System (APFS)
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ DYLD_INSERT_LIBRARIES=./interpose.dylib ./hello
|
|||
[+] Hello from interpose
|
||||
```
|
||||
|
||||
### Method Swizzling
|
||||
## Method Swizzling
|
||||
|
||||
In ObjectiveC this is how a method is called: `[myClassInstance nameOfTheMethodFirstParam:param1 secondParam:param2]`
|
||||
|
||||
|
|
@ -72,7 +72,11 @@ The object is **`someObject`**, the method is **`@selector(method1p1:p2:)`** and
|
|||
|
||||
Following the object structures, it's possible to reach an **array of methods** where the **names** and **pointers** to the method code are **located**.
|
||||
|
||||
#### Accessing the raw methods
|
||||
{% hint style="danger" %}
|
||||
Note that because methods and classes are accessed based on their names, this information is store in the binary, so it's possible to retrieve it with `otool -ov </path/bin>` or [`class-dump </path/bin>`](https://github.com/nygard/class-dump)
|
||||
{% endhint %}
|
||||
|
||||
### Accessing the raw methods
|
||||
|
||||
It's possible to access the information of the methods such as name, number of params or address like in the following example:
|
||||
|
||||
|
|
@ -142,7 +146,7 @@ int main() {
|
|||
}
|
||||
```
|
||||
|
||||
#### Method Swizzling with method\_exchangeImplementations
|
||||
### Method Swizzling with method\_exchangeImplementations
|
||||
|
||||
The function method\_exchangeImplementations allows to change the address of one function for the other. So when a function is called what is executed is the other one.
|
||||
|
||||
|
|
@ -190,7 +194,7 @@ int main(int argc, const char * argv[]) {
|
|||
}
|
||||
```
|
||||
|
||||
#### Method Swizzling with method\_setImplementation
|
||||
### Method Swizzling with method\_setImplementation
|
||||
|
||||
The previous format is weird because you are changing the implementation of 2 methods one from the other. Using the function **`method_setImplementation`** you can **change** the **implementation** of a **method for the other one**.
|
||||
|
||||
|
|
@ -248,6 +252,28 @@ int main(int argc, const char * argv[]) {
|
|||
}
|
||||
```
|
||||
|
||||
## Hooking Attack Methodology
|
||||
|
||||
In this page different ways to hook functions were discussed. However, they involved **running code inside the process to attack**.
|
||||
|
||||
In order to do that the easiest technique to use is to inject a [Dyld via environment variables or hijacking](../macos-dyld-hijacking-and-dyld\_insert\_libraries.md). However, I guess this could also be done via [Dylib process injection](macos-ipc-inter-process-communication.md#dylib-process-injection-via-task-port).
|
||||
|
||||
However, both options are **limited** to **unprotected** binaries/processes. Check each technique to learn more about the limitations.
|
||||
|
||||
However, a function hooking attack is very specific, an attacker will do this to **steal sensitive information from inside a process** (if not you would just do a process injection attack). And this sensitive information might be located in user downloaded Apps such as MacPass.
|
||||
|
||||
So the attacker vector would be to either find a vulnerability or strip the signature of the application, inject the **`DYLD_INSERT_LIBRARIES`** env variable through the Info.plist of the application adding something like:
|
||||
|
||||
```xml
|
||||
<key>LSEnvironment</key>
|
||||
<dict>
|
||||
<key>DYLD_INSERT_LIBRARIES</key>
|
||||
<string>/Applications/MacPass.app/Contents/malicious.dylib</string>
|
||||
</dict>
|
||||
```
|
||||
|
||||
Add in that library the hooking code to exfiltrate the information: Passwords, messages...
|
||||
|
||||
## References
|
||||
|
||||
* [https://nshipster.com/method-swizzling/](https://nshipster.com/method-swizzling/)
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# macOS IPC
|
||||
# macOS IPC - Inter Process Communication
|
||||
|
||||
<details>
|
||||
|
||||
|
|
@ -12,9 +12,7 @@
|
|||
|
||||
</details>
|
||||
|
||||
## IPC - Inter Process Communication
|
||||
|
||||
### Ports
|
||||
## Mach messaging via Ports
|
||||
|
||||
Mach uses **tasks** as the **smallest unit** for sharing resources, and each task can contain **multiple threads**. These **tasks and threads are mapped 1:1 to POSIX processes and threads**.
|
||||
|
||||
|
|
@ -699,6 +697,81 @@ gcc -framework Foundation -framework Appkit dylib_injector.m -o dylib_injector
|
|||
./inject <pid-of-mysleep> </path/to/lib.dylib>
|
||||
```
|
||||
|
||||
## XPC
|
||||
|
||||
### Basic Information
|
||||
|
||||
XPC, which stands for XNU (the kernel used by macOS) inter-Process Communication, is a framework for **communication between processes** on macOS and iOS. XPC provides a mechanism for making **safe, asynchronous method calls between different processes** on the system. It's a part of Apple's security paradigm, allowing for the **creation of privilege-separated applications** where each **component** runs with **only the permissions it needs** to do its job, thereby limiting the potential damage from a compromised process.
|
||||
|
||||
XPC uses a form of Inter-Process Communication (IPC), which is a set of methods for different programs running on the same system to send data back and forth.
|
||||
|
||||
The primary benefits of XPC include:
|
||||
|
||||
1. **Security**: By separating work into different processes, each process can be granted only the permissions it needs. This means that even if a process is compromised, it has limited ability to do harm.
|
||||
2. **Stability**: XPC helps isolate crashes to the component where they occur. If a process crashes, it can be restarted without affecting the rest of the system.
|
||||
3. **Performance**: XPC allows for easy concurrency, as different tasks can be run simultaneously in different processes.
|
||||
|
||||
The only **drawback** is that **separating an application is several processes** making them communicate via XPC is **less efficient**. But in todays systems this isn't almost noticeable and the benefits are much better.
|
||||
|
||||
An example can be seen in QuickTime Player, where a component using XPC is responsible for video decoding. The component is specifically designed to perform computational tasks, thus, in the event of a breach, it wouldn't provide any useful gains to the attacker, such as access to files or the network.
|
||||
|
||||
### Application Specific XPC services
|
||||
|
||||
The XPC components of an applications are **inside the application itself.** For example, in Safari you can find them in **`/Applications/Safari.app/Contents/XPCServices`**. They have extension **`.xpc`** (like **`com.apple.Safari.SandboxBroker.xpc`**) and are **also bundles** with the main binary inside of it: `/Applications/Safari.app/Contents/XPCServices/com.apple.Safari.SandboxBroker.xpc/Contents/MacOS/com.apple.Safari.SandboxBroker`
|
||||
|
||||
As you might be thinking a **XPC component will have different entitlements and privileges** than the other XPC components or the main app binary. EXCEPT if an XPC service is configured with [**JoinExistingSession**](https://developer.apple.com/documentation/bundleresources/information\_property\_list/xpcservice/joinexistingsession) set to “True” in its **Info.plist** file. In this case, the XPC service will run in the same security session as the application that called it.
|
||||
|
||||
XPC services are **started** by **launchd** when required and **shut down** once all tasks are **complete** to free system resources. **Application-specific XPC components can only be utilized by the application**, thereby reducing the risk associated with potential vulnerabilities.
|
||||
|
||||
### System Wide XPC services
|
||||
|
||||
**System-wide XPC services** are accessible to all users. These services, either launchd or Mach-type, need to be **defined in plist** files located in specified directories such as **`/System/Library/LaunchDameons`**, **`/Library/LaunchDameons`**, **`/System/Library/LaunchAgents`**, or **`/Library/LaunchAgents`**.
|
||||
|
||||
These plists files will have a key called **`MachServices`** with the name of the service, and a key called **`Program`** with the path to the binary:
|
||||
|
||||
```xml
|
||||
cat /Library/LaunchDaemons/com.jamf.management.daemon.plist
|
||||
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
|
||||
<plist version="1.0">
|
||||
<dict>
|
||||
<key>Program</key>
|
||||
<string>/Library/Application Support/JAMF/Jamf.app/Contents/MacOS/JamfDaemon.app/Contents/MacOS/JamfDaemon</string>
|
||||
<key>AbandonProcessGroup</key>
|
||||
<true/>
|
||||
<key>KeepAlive</key>
|
||||
<true/>
|
||||
<key>Label</key>
|
||||
<string>com.jamf.management.daemon</string>
|
||||
<key>MachServices</key>
|
||||
<dict>
|
||||
<key>com.jamf.management.daemon.aad</key>
|
||||
<true/>
|
||||
<key>com.jamf.management.daemon.agent</key>
|
||||
<true/>
|
||||
<key>com.jamf.management.daemon.binary</key>
|
||||
<true/>
|
||||
<key>com.jamf.management.daemon.selfservice</key>
|
||||
<true/>
|
||||
<key>com.jamf.management.daemon.service</key>
|
||||
<true/>
|
||||
</dict>
|
||||
<key>RunAtLoad</key>
|
||||
<true/>
|
||||
</dict>
|
||||
</plist>
|
||||
```
|
||||
|
||||
The ones in **`LaunchDameons`** are run by root. So if an unprivileged process can talk with one of these it could be able to escalate privileges.
|
||||
|
||||
### XPC Event Messages
|
||||
|
||||
Applications can **subscribe** to different event **messages**, enabling them to be **initiated on-demand** when such events happen. The **setup** for these services is done in l**aunchd plist files**, located in the **same directories as the previous ones** and containing an extra **`LaunchEvent`** key.
|
||||
|
||||
\
|
||||
|
||||
|
||||
## References
|
||||
|
||||
* [https://docs.darlinghq.org/internals/macos-specifics/mach-ports.html](https://docs.darlinghq.org/internals/macos-specifics/mach-ports.html)
|
||||
Loading…
Reference in New Issue