Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2025-02-16 22:18:27 +00:00
Code Issues Projects Releases Packages Wiki Activity

Translated ['macos-hardening/macos-security-and-privilege-escalation/mac

Browse source
This commit is contained in:
Translator 2024-04-29 10:24:00 +00:00
parent 0b66f5016f
commit ddfdb9ac0a
5 changed files with 529 additions and 197 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
SUMMARY.md
View file

@ -175,6 +175,7 @@
* [macOS Java Applications Injection](macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-java-apps-injection.md)
* [macOS Library Injection](macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-library-injection/README.md)
* [macOS Dyld Hijacking & DYLD\_INSERT\_LIBRARIES](macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-library-injection/macos-dyld-hijacking-and-dyld\_insert\_libraries.md)
* [macOS Dyld Process](macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-library-injection/macos-dyld-process.md)
* [macOS Perl Applications Injection](macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-perl-applications-injection.md)
* [macOS Python Applications Injection](macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-python-applications-injection.md)
* [macOS Ruby Applications Injection](macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-ruby-applications-injection.md)

82
macos-hardening/macos-security-and-privilege-escalation/macos-files-folders-and-binaries/README.md
View file

@ -2,15 +2,15 @@
<details>
<summary><strong>Erlernen Sie AWS-Hacking von Grund auf mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
<summary><strong>Erlernen Sie AWS-Hacking von Null auf Held mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Andere Möglichkeiten, HackTricks zu unterstützen:
* Wenn Sie Ihr **Unternehmen in HackTricks bewerben möchten** oder **HackTricks im PDF-Format herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen möchten** oder **HackTricks als PDF herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merch**](https://peass.creator-spring.com)
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repositories senden.
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegramm-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repositorys einreichen.
</details>
@ -41,11 +41,11 @@ Andere Möglichkeiten, HackTricks zu unterstützen:
* **Sandboxed**-Apps sind im `~/Library/Containers`-Ordner abgebildet. Jede App hat einen Ordner, der dem Bundle-ID der Anwendung entspricht (`com.apple.Safari`).
* Der **Kernel** befindet sich in `/System/Library/Kernels/kernel`
* **Apple-Kernelerweiterungen** befinden sich in `/System/Library/Extensions`
* **Kernelerweiterungen von Drittanbietern** werden in `/Library/Extensions` gespeichert
* **Kernelerweiterungen von Drittanbietern** sind im Ordner `/Library/Extensions` gespeichert
### Dateien mit sensiblen Informationen
MacOS speichert Informationen wie Passwörter an verschiedenen Orten:
macOS speichert Informationen wie Passwörter an verschiedenen Orten:
{% content-ref url="macos-sensitive-locations.md" %}
[macos-sensitive-locations.md](macos-sensitive-locations.md)
@ -79,19 +79,22 @@ MacOS speichert Informationen wie Passwörter an verschiedenen Orten:
### macOS-Bundles
Ein Bundle ist ein **Verzeichnis**, das wie ein Objekt im Finder aussieht (ein Beispiel für ein Bundle sind `*.app`-Dateien).
Ein Bundle ist ein **Verzeichnis**, das **wie ein Objekt im Finder aussieht** (ein Beispiel für ein Bundle sind `*.app`-Dateien).
{% content-ref url="macos-bundles.md" %}
[macos-bundles.md](macos-bundles.md)
{% endcontent-ref %}
## Dyld Shared Cache
## Dyld Shared Library Cache (SLC)
Auf macOS (und iOS) sind alle System-Freigabelibraries, wie Frameworks und Dylibs, in einer einzigen Datei namens **dyld Shared Cache** kombiniert. Dies verbessert die Leistung, da der Code schneller geladen werden kann.
Auf macOS (und iOS) sind alle System-Shared Libraries, wie Frameworks und Dylibs, in einer einzigen Datei namens **dyld shared cache** kombiniert. Dies verbessert die Leistung, da der Code schneller geladen werden kann.
Ähnlich dem dyld Shared Cache werden der Kernel und die Kernelerweiterungen auch in einem Kernelcache kompiliert, der beim Booten geladen wird.
Dies befindet sich in macOS in `/System/Volumes/Preboot/Cryptexes/OS/System/Library/dyld/` und in älteren Versionen finden Sie den **Shared Cache** möglicherweise in **`/System/Library/dyld/`**.\
In iOS finden Sie sie in **`/System/Library/Caches/com.apple.dyld/`**.
Um die Bibliotheken aus der einzelnen Datei des dylib Shared Cache zu extrahieren, war es möglich, das Binärprogramm [dyld\_shared\_cache\_util](https://www.mbsplugins.de/files/dyld\_shared\_cache\_util-dyld-733.8.zip) zu verwenden, das heutzutage möglicherweise nicht mehr funktioniert, aber Sie können auch [**dyldextractor**](https://github.com/arandomdev/dyldextractor) verwenden:
Ähnlich wie der dyld Shared Cache werden der Kernel und die Kernelerweiterungen auch in einem Kernel-Cache kompiliert, der beim Booten geladen wird.
Um die Bibliotheken aus der einzigen Datei des Dylib Shared Cache zu extrahieren, war es möglich, das Binärprogramm [dyld\_shared\_cache\_util](https://www.mbsplugins.de/files/dyld\_shared\_cache\_util-dyld-733.8.zip) zu verwenden, das heutzutage möglicherweise nicht mehr funktioniert, aber Sie können auch [**dyldextractor**](https://github.com/arandomdev/dyldextractor) verwenden:
{% code overflow="wrap" %}
```bash
@ -105,30 +108,47 @@ dyldex_all [dyld_shared_cache_path] # Extract all
```
{% endcode %}
In älteren Versionen könnten Sie den **gemeinsamen Cache** möglicherweise in **`/System/Library/dyld/`** finden.
In iOS finden Sie sie in **`/System/Library/Caches/com.apple.dyld/`**.
{% hint style="success" %}
Beachten Sie, dass selbst wenn das Tool `dyld_shared_cache_util` nicht funktioniert, Sie das **gemeinsame dyld-Binary an Hopper übergeben** können und Hopper alle Bibliotheken identifizieren und Sie **auswählen lassen kann, welche Sie untersuchen möchten**:
Beachten Sie, dass selbst wenn das `dyld_shared_cache_util`-Tool nicht funktioniert, Sie das **gemeinsame dyld-Binary an Hopper übergeben** können und Hopper alle Bibliotheken identifizieren und Sie **auswählen lassen kann**, welche Sie untersuchen möchten:
{% endhint %}
<figure><img src="../../../.gitbook/assets/image (1149).png" alt="" width="563"><figcaption></figcaption></figure>
Einige Extraktoren funktionieren nicht, da dylibs mit fest codierten Adressen vorverknüpft sind und daher möglicherweise zu unbekannten Adressen springen.
{% hint style="success" %}
Es ist auch möglich, den Shared Library Cache anderer \*OS-Geräte in macOS mithilfe eines Emulators in Xcode herunterzuladen. Sie werden innerhalb heruntergeladen: ls `$HOME/Library/Developer/Xcode/<*>OS\ DeviceSupport/<version>/Symbols/System/Library/Caches/com.apple.dyld/`, wie:`$HOME/Library/Developer/Xcode/iOS\ DeviceSupport/14.1\ (18A8395)/Symbols/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64`
{% endhint %}
### Zuordnung von SLC
**`dyld`** verwendet den Systemaufruf **`shared_region_check_np`**, um festzustellen, ob der SLC zugeordnet wurde (der die Adresse zurückgibt) und **`shared_region_map_and_slide_np`**, um den SLC zuzuordnen.
Beachten Sie, dass selbst wenn der SLC beim ersten Gebrauch verschoben wird, alle **Prozesse** die **gleiche Kopie** verwenden, was den ASLR-Schutz beseitigt, wenn der Angreifer in der Lage war, Prozesse im System auszuführen. Dies wurde tatsächlich in der Vergangenheit ausgenutzt und mit dem Shared-Region-Pager behoben.
Zweigpools sind kleine Mach-O-Dylibs, die kleine Zwischenräume zwischen Bildzuordnungen erstellen und es unmöglich machen, die Funktionen zu interponieren.
### SLCs außer Kraft setzen
Verwendung der Umgebungsvariablen:
* **`DYLD_DHARED_REGION=private DYLD_SHARED_CACHE_DIR=</path/dir> DYLD_SHARED_CACHE_DONT_VALIDATE=1`** -> Dadurch wird das Laden eines neuen Shared Library Cache ermöglicht
* **`DYLD_SHARED_CACHE_DIR=avoid`** und manuelles Ersetzen der Bibliotheken durch symbolische Links zum Shared Cache mit den echten (Sie müssen sie extrahieren)
## Besondere Dateiberechtigungen
### Ordnerberechtigungen
### Berechtigungen für Ordner
In einem **Ordner** erlaubt **lesen**, ihn **aufzulisten**, **schreiben**, Dateien darin zu **löschen** und **schreiben** erlaubt, Dateien darin zu **schreiben**, und **ausführen** erlaubt es, das Verzeichnis zu **durchsuchen**. So kann beispielsweise ein Benutzer mit **Leseberechtigung über eine Datei** in einem Verzeichnis, in dem er **keine Ausführungsberechtigung hat**, die Datei **nicht lesen**.
In einem **Ordner** erlaubt **lesen**, es **aufzulisten**, **schreiben** erlaubt es, **Dateien darin zu löschen** und **schreiben** erlaubt es, das Verzeichnis zu **durchqueren**. So wird beispielsweise ein Benutzer mit **Leseberechtigung über eine Datei** in einem Verzeichnis, in dem er **keine Ausführungsberechtigung hat**, **nicht in der Lage sein, die Datei zu lesen**.
### Flag-Modifikatoren
Es gibt einige Flags, die in den Dateien gesetzt werden können, um das Verhalten der Datei zu ändern. Sie können die Flags der Dateien in einem Verzeichnis mit `ls -lO /Pfad/Verzeichnis` überprüfen.
Es gibt einige Flags, die in den Dateien gesetzt werden können, um das Verhalten der Datei zu ändern. Sie können die Flags der Dateien in einem Verzeichnis mit `ls -lO /path/directory` überprüfen
* **`uchg`**: Bekannt als **uchange**-Flag wird jegliche Änderung oder das Löschen der **Datei verhindern**. Um es zu setzen, verwenden Sie: `chflags uchg datei.txt`
* **`uchg`**: Bekannt als **uchange**-Flag verhindert jegliche Änderung oder Löschung der **Datei**. Um es zu setzen, verwenden Sie: `chflags uchg file.txt`
* Der Root-Benutzer könnte das Flag **entfernen** und die Datei ändern
* **`restricted`**: Dieses Flag bewirkt, dass die Datei durch SIP geschützt wird (Sie können dieses Flag nicht zu einer Datei hinzufügen).
* **`Sticky-Bit`**: Wenn ein Verzeichnis mit dem Sticky-Bit versehen ist, können **nur** der **Verzeichniseigentümer oder Root** Dateien umbenennen oder löschen. Typischerweise wird dies im /tmp-Verzeichnis festgelegt, um normale Benutzer daran zu hindern, Dateien anderer Benutzer zu löschen oder zu verschieben.
* **`restricted`**: Dieses Flag macht die Datei durch SIP geschützt (Sie können dieses Flag nicht zu einer Datei hinzufügen).
* **`Sticky-Bit`**: Wenn ein Verzeichnis mit Sticky-Bit, können **nur** der **Verzeichniseigentümer oder Root** Dateien umbenennen oder löschen. Typischerweise wird dies im /tmp-Verzeichnis festgelegt, um normale Benutzer daran zu hindern, Dateien anderer Benutzer zu löschen oder zu verschieben.
Alle Flags finden Sie in der Datei `sys/stat.h` (finden Sie sie mit `mdfind stat.h | grep stat.h`) und sind:
@ -156,15 +176,15 @@ Alle Flags finden Sie in der Datei `sys/stat.h` (finden Sie sie mit `mdfind stat
Datei-**ACLs** enthalten **ACE** (Access Control Entries), mit denen verschiedenen Benutzern genauere Berechtigungen zugewiesen werden können.
Es ist möglich, einem **Verzeichnis** diese Berechtigungen zu gewähren: `auflisten`, `suchen`, `datei_hinzufügen`, `unterverzeichnis_hinzufügen`, `kind_löschen`, `kind_löschen`.\
Und einer **Datei**: `lesen`, `schreiben`, `anhängen`, `ausführen`.
Es ist möglich, einem **Verzeichnis** diese Berechtigungen zu gewähren: `list`, `search`, `add_file`, `add_subdirectory`, `delete_child`, `delete_child`.\
Und einer **Datei**: `read`, `write`, `append`, `execute`.
Wenn die Datei ACLs enthält, finden Sie ein **"+" beim Auflisten der Berechtigungen wie in**:
Wenn die Datei ACLs enthält, finden Sie ein "+" beim Auflisten der Berechtigungen wie in:
```bash
ls -ld Movies
drwx------+ 7 username staff 224 15 Apr 19:42 Movies
```
Du kannst die **ACLs der Datei** mit folgendem Befehl lesen:
Du kannst die ACLs der Datei mit folgendem Befehl lesen:
```bash
ls -lde Movies
drwx------+ 7 username staff 224 15 Apr 19:42 Movies
@ -183,8 +203,8 @@ Erweiterte Attribute haben einen Namen und einen beliebigen Wert und können mit
- `metadata:*`: MacOS: verschiedene Metadaten, wie z.B. `_backup_excludeItem` oder `kMD*`
- `com.apple.lastuseddate` (#PS): Datum der letzten Dateinutzung
- `com.apple.FinderInfo`: MacOS: Finder-Informationen (z.B. Farbmarkierungen)
- `com.apple.TextEncoding`: Legt die Textkodierung von ASCII-Textdateien fest
- `com.apple.logd.metadata`: Wird von logd auf Dateien in `/var/db/diagnostics` verwendet
- `com.apple.TextEncoding`: Legt die Textcodierung von ASCII-Textdateien fest
- `com.apple.logd.metadata`: Von logd auf Dateien in `/var/db/diagnostics` verwendet
- `com.apple.genstore.*`: Generationspeicher (`/.DocumentRevisions-V100` im Stammverzeichnis des Dateisystems)
- `com.apple.rootless`: MacOS: Wird von der System Integrity Protection verwendet, um Dateien zu kennzeichnen (III/10)
- `com.apple.uuidb.boot-uuid`: logd-Markierungen von Boot-Epochen mit eindeutiger UUID
@ -219,7 +239,7 @@ Das erweiterte Attribut `com.apple.decmpfs` zeigt an, dass die Datei verschlüss
Dieses Attribut kann mit `ls -lO` angezeigt werden, da komprimierte Dateien auch mit der Flagge `UF_COMPRESSED` markiert sind. Wenn eine komprimierte Datei entfernt wird, wird diese Flagge mit `chflags nocompressed </Pfad/zur/Datei>` entfernt. Das System wird dann nicht wissen, dass die Datei komprimiert war, und daher nicht in der Lage sein, die Daten zu dekomprimieren und darauf zuzugreifen (es wird denken, dass sie tatsächlich leer ist).
Das Tool `afscexpand` kann verwendet werden, um eine Datei zwangsweise zu dekomprimieren.
Das Tool afscexpand kann verwendet werden, um eine Datei zwangsweise zu dekomprimieren.
## **Universelle Binärdateien &** Mach-o-Format
@ -241,13 +261,13 @@ Das Verzeichnis `/System/Library/CoreServices/CoreTypes.bundle/Contents/Resource
* **LSRiskCategorySafe**: Dateien in dieser Kategorie gelten als **vollkommen sicher**. Safari öffnet diese Dateien automatisch nach dem Download.
* **LSRiskCategoryNeutral**: Diese Dateien werden ohne Warnungen geliefert und von Safari **nicht automatisch geöffnet**.
* **LSRiskCategoryUnsafeExecutable**: Dateien in dieser Kategorie lösen eine Warnung aus, die darauf hinweist, dass es sich um eine Anwendung handelt. Dies dient als Sicherheitsmaßnahme, um den Benutzer zu alarmieren.
* **LSRiskCategoryUnsafeExecutable**: Dateien in dieser Kategorie lösen eine Warnung aus, die darauf hinweist, dass die Datei eine Anwendung ist. Dies dient als Sicherheitsmaßnahme, um den Benutzer zu alarmieren.
* **LSRiskCategoryMayContainUnsafeExecutable**: Diese Kategorie ist für Dateien wie Archive vorgesehen, die eine ausführbare Datei enthalten könnten. Safari löst eine Warnung aus, es sei denn, es kann überprüft werden, dass alle Inhalte sicher oder neutral sind.
## Protokolldateien
* **`$HOME/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2`**: Enthält Informationen über heruntergeladene Dateien, wie z. B. die URL, von der sie heruntergeladen wurden.
* **`/var/log/system.log`**: Hauptprotokoll der OSX-Systeme. `com.apple.syslogd.plist` ist für die Ausführung des Syslogging verantwortlich (Sie können überprüfen, ob es deaktiviert ist, indem Sie nach "com.apple.syslogd" in `launchctl list` suchen).
* **`/var/log/system.log`**: Hauptprotokoll der OSX-Systeme. com.apple.syslogd.plist ist für die Ausführung des Syslog-Dienstes verantwortlich (Sie können überprüfen, ob er deaktiviert ist, indem Sie nach "com.apple.syslogd" in `launchctl list` suchen).
* **`/private/var/log/asl/*.asl`**: Dies sind die Apple-Systemprotokolle, die interessante Informationen enthalten können.
* **`$HOME/Library/Preferences/com.apple.recentitems.plist`**: Speichert zuletzt zugegriffene Dateien und Anwendungen über "Finder".
* **`$HOME/Library/Preferences/com.apple.loginitems.plsit`**: Speichert Elemente, die beim Systemstart gestartet werden sollen.

137
macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-function-hooking.md
View file

@ -1,30 +1,30 @@
# macOS Function Hooking
# macOS Funktion Hooking
<details>
<summary><strong>Lernen Sie AWS-Hacking von Grund auf mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
<summary><strong>Erlernen Sie AWS-Hacking von Grund auf mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Andere Möglichkeiten, HackTricks zu unterstützen:
* Wenn Sie Ihr **Unternehmen in HackTricks bewerben möchten** oder **HackTricks als PDF herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com)
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) Github-Repositories senden.
- Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen möchten** oder **HackTricks in PDF herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
- Holen Sie sich das [**offizielle PEASS & HackTricks-Merch**](https://peass.creator-spring.com)
- Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
- **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
- **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repositories einreichen.
</details>
## Funktionen Interposing
## Funktionsinterponierung
Erstellen Sie eine **dylib** mit einem **`__interpose`**-Abschnitt (oder einem Abschnitt mit dem Flag **`S_INTERPOSING`**), der Tupel von **Funktionszeigern** enthält, die auf die **ursprünglichen** und **Ersatz**-Funktionen verweisen.
Erstellen Sie eine **dylib** mit einem **`__interpose` (`__DATA___interpose`)** Abschnitt (oder einem Abschnitt, der mit **`S_INTERPOSING`** gekennzeichnet ist), der Tupel von **Funktionspointern** enthält, die auf die **ursprünglichen** und die **Ersatz**-Funktionen verweisen.
Dann **injizieren** Sie die dylib mit **`DYLD_INSERT_LIBRARIES`** (das Interposing muss vor dem Laden der Hauptanwendung erfolgen). Offensichtlich gelten hier auch die [**Einschränkungen**, die für die Verwendung von **`DYLD_INSERT_LIBRARIES`** gelten](macos-library-injection/#check-restrictions).
Dann **injizieren** Sie die dylib mit **`DYLD_INSERT_LIBRARIES`** (die Interponierung muss vor dem Laden der Haupt-App erfolgen). Offensichtlich gelten hier auch die [**Einschränkungen**, die für die Verwendung von **`DYLD_INSERT_LIBRARIES`** gelten](macos-library-injection/#check-restrictions).
### Interpose printf
### Interponieren von printf
{% tabs %}
{% tab title="interpose.c" %}
{% code title="interpose.c" %}
{% code title="interpose.c" overflow="wrap" %}
```c
// gcc -dynamiclib interpose.c -o interpose.dylib
#include <stdio.h>
@ -56,41 +56,10 @@ printf("Hello World!\n");
return 0;
}
```
{% endtab %}
```c
#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>
typedef int (*orig_open_type)(const char *pathname, int flags);
typedef FILE *(*orig_fopen_type)(const char *pathname, const char *mode);
int open(const char *pathname, int flags) {
orig_open_type orig_open;
orig_open = (orig_open_type)dlsym(RTLD_NEXT, "open");
printf("Opening file: %s\n", pathname);
return orig_open(pathname, flags);
}
FILE *fopen(const char *pathname, const char *mode) {
orig_fopen_type orig_fopen;
orig_fopen = (orig_fopen_type)dlsym(RTLD_NEXT, "fopen");
printf("Opening file: %s\n", pathname);
return orig_fopen(pathname, mode);
}
```
This code demonstrates how to use function hooking in macOS using the `dlsym` function from the `dlfcn.h` library. The `open` and `fopen` functions are hooked by defining new functions with the same name. The original functions are then obtained using `dlsym` and called within the hooked functions. In this example, whenever `open` or `fopen` is called, the pathname of the file being opened is printed to the console before the original function is executed.
To compile and run this code, use the following commands:
```bash
gcc -shared -o interpose2.dylib interpose2.c -ldl
DYLD_INSERT_LIBRARIES=interpose2.dylib ls
```
The `DYLD_INSERT_LIBRARIES` environment variable is used to specify the dynamic library to be loaded into the target process. In this case, the `interpose2.dylib` library is loaded into the `ls` command, causing the hooked functions to be used instead of the original ones.
{% tab title="interpose2.c" %}
{% code overflow="wrap" %}
```c
// Just another way to define an interpose
// gcc -dynamiclib interpose2.c -o interpose2.dylib
@ -114,9 +83,9 @@ return ret;
DYLD_INTERPOSE(my_printf,printf);
```
{% endcode %}
{% endtab %}
{% endtabs %}
```bash
DYLD_INSERT_LIBRARIES=./interpose.dylib ./hello
Hello from interpose
@ -124,25 +93,42 @@ Hello from interpose
DYLD_INSERT_LIBRARIES=./interpose2.dylib ./hello
Hello from interpose
```
{% hint style="warning" %}
Die **`DYLD_PRINT_INTERPOSTING`** Umgebungsvariable kann zum Debuggen von Interposing verwendet werden und gibt den Interpose-Prozess aus.
{% endhint%}
Beachten Sie auch, dass **Interposing zwischen dem Prozess und den geladenen Bibliotheken** stattfindet und nicht mit dem gemeinsamen Bibliotheks-Cache funktioniert.
### Dynamisches Interposing
Jetzt ist es auch möglich, eine Funktion dynamisch mit der Funktion **`dyld_dynamic_interpose`** zu interposen. Dies ermöglicht es, eine Funktion zur Laufzeit programmgesteuert zu interposieren, anstatt dies nur zu Beginn zu tun.
Es ist nur erforderlich, die **Tupel** der **zu ersetzenden Funktion und der Ersatzfunktion** anzugeben.
```c
struct dyld_interpose_tuple {
const void* replacement;
const void* replacee;
};
extern void dyld_dynamic_interpose(const struct mach_header* mh,
const struct dyld_interpose_tuple array[], size_t count);
```
## Method Swizzling
In ObjectiveC wird eine Methode wie folgt aufgerufen: **`[myClassInstance nameOfTheMethodFirstParam:param1 secondParam:param2]`**
In ObjectiveC wird ein Methodenaufruf wie folgt durchgeführt: **`[myClassInstance nameOfTheMethodFirstParam:param1 secondParam:param2]`**
Es werden das **Objekt**, die **Methode** und die **Parameter** benötigt. Wenn eine Methode aufgerufen wird, wird eine **Nachricht gesendet**, indem die Funktion **`objc_msgSend`** verwendet wird: `int i = ((int (*)(id, SEL, NSString *, NSString *))objc_msgSend)(someObject, @selector(method1p1:p2:), value1, value2);`
Es wird das **Objekt**, die **Methode** und die **Parameter** benötigt. Wenn eine Methode aufgerufen wird, wird eine **Nachricht gesendet**, indem die Funktion **`objc_msgSend`** verwendet wird: `int i = ((int (*)(id, SEL, NSString *, NSString *))objc_msgSend)(someObject, @selector(method1p1:p2:), value1, value2);`
Das Objekt ist **`someObject`**, die Methode ist **`@selector(method1p1:p2:)`** und die Argumente sind **value1** und **value2**.
Das Objekt ist **`someObject`**, die Methode ist **`@selector(method1p1:p2:)`** und die Argumente sind **value1**, **value2**.
Durch die Struktur der Objekte ist es möglich, auf ein **Array von Methoden** zuzugreifen, in dem die **Namen** und **Zeiger** auf den Methodencode **gespeichert** sind.
Durch die Objektstrukturen ist es möglich, ein **Array von Methoden** zu erreichen, in dem die **Namen** und **Zeiger** auf den Methodencode **gespeichert** sind.
{% hint style="danger" %}
Beachten Sie, dass Methoden und Klassen basierend auf ihren Namen abgerufen werden, daher werden diese Informationen in der Binärdatei gespeichert und können mit `otool -ov </path/bin>` oder [`class-dump </path/bin>`](https://github.com/nygard/class-dump) abgerufen werden.
Beachten Sie, dass da Methoden und Klassen anhand ihrer Namen zugegriffen werden, diese Informationen im Binärformat gespeichert sind. Daher ist es möglich, sie mit `otool -ov </path/bin>` oder [`class-dump </path/bin>`](https://github.com/nygard/class-dump) abzurufen.
{% endhint %}
### Zugriff auf die Rohmethoden
Es ist möglich, Informationen über die Methoden wie Namen, Anzahl der Parameter oder Adresse abzurufen, wie im folgenden Beispiel:
Es ist möglich, auf die Informationen der Methoden zuzugreifen, wie z.B. Name, Anzahl der Parameter oder Adresse, wie im folgenden Beispiel:
```objectivec
// gcc -framework Foundation test.m -o test
@ -208,15 +194,15 @@ NSLog(@"Uppercase string: %@", uppercaseString3);
return 0;
}
```
### Method Swizzling mit method\_exchangeImplementations
Die Funktion **`method_exchangeImplementations`** ermöglicht es, die **Adresse** der **Implementierung** einer **Funktion durch eine andere** zu **ändern**.
Die Funktion **`method_exchangeImplementations`** ermöglicht es, die **Adresse** der **Implementierung einer Funktion für eine andere** zu **ändern**.
{% hint style="danger" %}
Wenn eine Funktion aufgerufen wird, wird stattdessen die andere Funktion **ausgeführt**.
Daher wird beim Aufruf einer Funktion die **andere Funktion ausgeführt**.
{% endhint %}
{% code overflow="wrap" %}
```objectivec
//gcc -framework Foundation swizzle_str.m -o swizzle_str
@ -260,19 +246,21 @@ NSLog(@"Substring: %@", subString);
return 0;
}
```
{% endcode %}
{% hint style="warning" %}
In diesem Fall könnte der **Implementierungscode der legitimen** Methode, wenn er den **Methodennamen überprüft**, diese Swizzling erkennen und verhindern, dass sie ausgeführt wird.
In diesem Fall, wenn der **Implementierungscode der legitimen** Methode den **Methodennamen überprüft**, könnte er dieses Swizzling erkennen und verhindern, dass es ausgeführt wird.
Die folgende Technik hat diese Einschränkung nicht.
{% endhint %}
### Method Swizzling mit method\_setImplementation
Das vorherige Format ist seltsam, weil du die Implementierung von 2 Methoden änderst, eine von der anderen. Mit der Funktion **`method_setImplementation`** kannst du die Implementierung einer Methode für eine andere ändern.
Das vorherige Format ist seltsam, weil du die Implementierung von 2 Methoden gegeneinander austauschst. Mit der Funktion **`method_setImplementation`** kannst du die **Implementierung einer Methode durch eine andere** ändern.
Denke nur daran, die Adresse der Implementierung der Originalmethode zu speichern, wenn du sie aus der neuen Implementierung aufrufen möchtest, bevor du sie überschreibst, da es später viel komplizierter sein wird, diese Adresse zu finden.
Denke daran, die Adresse der Implementierung der Originalmethode zu speichern, wenn du sie aus der neuen Implementierung aufrufen möchtest, bevor du sie überschreibst, da es später viel komplizierter sein wird, diese Adresse zu finden.
{% code overflow="wrap" %}
```objectivec
#import <Foundation/Foundation.h>
#import <objc/runtime.h>
@ -324,19 +312,19 @@ return 0;
}
}
```
{% endcode %}
## Methodik des Hooking-Angriffs
## Hooking-Angriffsmethodik
Auf dieser Seite wurden verschiedene Möglichkeiten zum Hooken von Funktionen diskutiert. Allerdings erforderten sie das **Ausführen von Code innerhalb des Prozesses, um anzugreifen**.
Auf dieser Seite wurden verschiedene Möglichkeiten zum Hooken von Funktionen diskutiert. Allerdings beinhalteten sie **das Ausführen von Code innerhalb des Prozesses, um anzugreifen**.
Um dies zu erreichen, ist die einfachste Technik die Injektion eines [Dyld über Umgebungsvariablen oder Hijacking](macos-library-injection/macos-dyld-hijacking-and-dyld\_insert\_libraries.md). Allerdings denke ich, dass dies auch über [Dylib-Prozessinjektion](macos-ipc-inter-process-communication/#dylib-process-injection-via-task-port) möglich ist.
Um dies zu erreichen, ist die einfachste Technik die Injektion eines [Dyld über Umgebungsvariablen oder Hijacking](macos-library-injection/macos-dyld-hijacking-and-dyld\_insert\_libraries.md). Allerdings könnte dies auch über [Dylib-Prozessinjektion](macos-ipc-inter-process-communication/#dylib-process-injection-via-task-port) erfolgen.
Beide Optionen sind jedoch **auf ungeschützte** Binärdateien/Prozesse beschränkt. Überprüfen Sie jede Technik, um mehr über die Einschränkungen zu erfahren.
Beide Optionen sind jedoch **auf ungeschützte** Binärdateien/Prozesse **beschränkt**. Überprüfen Sie jede Technik, um mehr über die Einschränkungen zu erfahren.
Ein Funktion-Hooking-Angriff ist jedoch sehr spezifisch. Ein Angreifer würde dies tun, um sensible Informationen aus einem Prozess zu stehlen (sonst würde man einfach einen Prozessinjektionsangriff durchführen). Und diese sensiblen Informationen könnten sich in von Benutzern heruntergeladenen Apps wie MacPass befinden.
Der Angriffsvektor des Angreifers wäre also entweder eine Schwachstelle zu finden oder die Signatur der Anwendung zu entfernen und die **`DYLD_INSERT_LIBRARIES`** Umgebungsvariable über die Info.plist der Anwendung einzufügen, indem man etwas wie: einfügt.
Ein Funktion-Hooking-Angriff ist sehr spezifisch, ein Angreifer würde dies tun, um **sensible Informationen aus einem Prozess zu stehlen** (ansonsten würde man einfach einen Prozessinjektionsangriff durchführen). Und diese sensiblen Informationen könnten sich in von Benutzern heruntergeladenen Apps wie MacPass befinden.
Der Angriffsvektor des Angreifers wäre es also, entweder eine Schwachstelle zu finden oder die Signatur der Anwendung zu entfernen, die **`DYLD_INSERT_LIBRARIES`** Umgebungsvariable durch die Info.plist der Anwendung einzufügen und etwas Ähnliches hinzuzufügen:
```xml
<key>LSEnvironment</key>
<dict>
@ -344,8 +332,7 @@ Der Angriffsvektor des Angreifers wäre also entweder eine Schwachstelle zu find
<string>/Applications/Application.app/Contents/malicious.dylib</string>
</dict>
```
und dann **registrieren Sie die Anwendung erneut**:
und dann die Anwendung **neu registrieren**:
{% code overflow="wrap" %}
```bash
@ -356,11 +343,12 @@ und dann **registrieren Sie die Anwendung erneut**:
Fügen Sie in diese Bibliothek den Hooking-Code ein, um die Informationen zu exfiltrieren: Passwörter, Nachrichten...
{% hint style="danger" %}
Beachten Sie, dass in neueren Versionen von macOS, wenn Sie die Signatur der Anwendungsdatei entfernen und sie zuvor ausgeführt wurde, macOS die Anwendung nicht mehr ausführt.
Beachten Sie, dass in neueren Versionen von macOS, wenn Sie die Signatur der Anwendungsdatei entfernen und sie zuvor ausgeführt wurde, macOS die Anwendung nicht mehr ausführen wird.
{% endhint %}
#### Beispielbibliothek
#### Bibliotheksbeispiel
{% code overflow="wrap" %}
```objectivec
// gcc -dynamiclib -framework Foundation sniff.m -o sniff.dylib
@ -396,6 +384,7 @@ IMP fake_IMP = (IMP)custom_setPassword;
real_setPassword = method_setImplementation(real_Method, fake_IMP);
}
```
{% endcode %}
## Referenzen
@ -403,14 +392,14 @@ real_setPassword = method_setImplementation(real_Method, fake_IMP);
<details>
<summary><strong>Lernen Sie AWS-Hacking von Null auf Held mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
<summary><strong>Erlernen Sie AWS-Hacking von Null auf Held mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Andere Möglichkeiten, HackTricks zu unterstützen:
* Wenn Sie Ihr **Unternehmen in HackTricks bewerben möchten** oder **HackTricks als PDF herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen möchten** oder **HackTricks im PDF-Format herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com)
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repositories senden.
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repositories einreichen.
</details>

184
macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-library-injection/README.md
View file

@ -2,46 +2,54 @@
<details>
<summary><strong>Lernen Sie das Hacken von AWS von Grund auf mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
<summary><strong>Erlernen Sie AWS-Hacking von Grund auf mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Andere Möglichkeiten, HackTricks zu unterstützen:
* Wenn Sie Ihr **Unternehmen in HackTricks bewerben möchten** oder **HackTricks als PDF herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen möchten** oder **HackTricks in PDF herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com)
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegramm-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) Github-Repositories senden.
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repositories einreichen.
</details>
{% hint style="danger" %}
Der Code von **dyld ist Open Source** und kann unter [https://opensource.apple.com/source/dyld/](https://opensource.apple.com/source/dyld/) gefunden werden und kann über eine **URL wie** [https://opensource.apple.com/tarballs/dyld/dyld-852.2.tar.gz](https://opensource.apple.com/tarballs/dyld/dyld-852.2.tar.gz) heruntergeladen werden.
Der Code von **dyld ist Open Source** und kann unter [https://opensource.apple.com/source/dyld/](https://opensource.apple.com/source/dyld/) gefunden und als Tar unter Verwendung einer **URL wie** [https://opensource.apple.com/tarballs/dyld/dyld-852.2.tar.gz](https://opensource.apple.com/tarballs/dyld/dyld-852.2.tar.gz) heruntergeladen werden.
{% endhint %}
## **Dyld-Prozess**
Werfen Sie einen Blick darauf, wie Dyld Bibliotheken in Binärdateien lädt:
{% content-ref url="macos-dyld-process.md" %}
[macos-dyld-process.md](macos-dyld-process.md)
{% endcontent-ref %}
## **DYLD\_INSERT\_LIBRARIES**
Dies ist ähnlich wie das [**LD\_PRELOAD auf Linux**](../../../../linux-hardening/privilege-escalation/#ld\_preload). Es ermöglicht die Angabe eines Prozesses, der ausgeführt wird, um eine bestimmte Bibliothek von einem Pfad zu laden (wenn die Umgebungsvariable aktiviert ist).
Dies ist wie das [**LD\_PRELOAD unter Linux**](../../../../linux-hardening/privilege-escalation/#ld\_preload). Es ermöglicht, einem Prozess anzuzeigen, dass eine bestimmte Bibliothek aus einem Pfad geladen werden soll (wenn die Umgebungsvariable aktiviert ist).
Diese Technik kann auch als ASEP-Technik verwendet werden, da jede installierte Anwendung eine Plist namens "Info.plist" hat, die die Zuweisung von Umgebungsvariablen mit einem Schlüssel namens `LSEnvironmental` ermöglicht.
Diese Technik kann auch als ASEP-Technik verwendet werden, da jede installierte Anwendung eine sogenannte "Info.plist" hat, die das Zuweisen von Umgebungsvariablen mit einem Schlüssel namens `LSEnvironmental` ermöglicht.
{% hint style="info" %}
Seit 2012 hat **Apple die Macht von `DYLD_INSERT_LIBRARIES` drastisch reduziert**.
Seit 2012 hat **Apple die Macht des** **`DYLD_INSERT_LIBRARIES`** **drastisch reduziert**.
Gehen Sie zum Code und überprüfen Sie `src/dyld.cpp`. In der Funktion `pruneEnvironmentVariables` können Sie sehen, dass `DYLD_*`-Variablen entfernt werden.
Gehen Sie zum Code und überprüfen Sie `src/dyld.cpp`. In der Funktion **`pruneEnvironmentVariables`** können Sie sehen, dass **`DYLD_*`**-Variablen entfernt werden.
In der Funktion `processRestricted` wird der Grund für die Einschränkung festgelegt. Wenn Sie diesen Code überprüfen, können Sie sehen, dass die Gründe sind:
In der Funktion **`processRestricted`** wird der Grund für die Einschränkung festgelegt. Wenn Sie diesen Code überprüfen, sehen Sie, dass die Gründe sind:
* Die Binärdatei ist `setuid/setgid`
* Vorhandensein des Abschnitts `__RESTRICT/__restrict` in der Macho-Binärdatei.
* Die Software verfügt über Berechtigungen (gehärtete Laufzeit) ohne [`com.apple.security.cs.allow-dyld-environment-variables`](https://developer.apple.com/documentation/bundleresources/entitlements/com\_apple\_security\_cs\_allow-dyld-environment-variables) Berechtigung
* Überprüfen Sie die **Berechtigungen** einer Binärdatei mit: `codesign -dv --entitlements :- </path/to/bin>`
* Die Software verfügt über Berechtigungen (gehärtete Laufzeit) ohne die Berechtigung [`com.apple.security.cs.allow-dyld-environment-variables`](https://developer.apple.com/documentation/bundleresources/entitlements/com\_apple\_security\_cs\_allow-dyld-environment-variables)
* Überprüfen Sie die **Berechtigungen** einer Binärdatei mit: `codesign -dv --entitlements :- </Pfad/zur/Binärdatei>`
In neueren Versionen finden Sie diese Logik im zweiten Teil der Funktion `configureProcessRestrictions`. Was jedoch in neueren Versionen ausgeführt wird, sind die **Anfangsprüfungen der Funktion** (Sie können die mit iOS oder Simulation zusammenhängenden Bedingungen entfernen, da diese in macOS nicht verwendet werden).
In neueren Versionen finden Sie diese Logik im zweiten Teil der Funktion **`configureProcessRestrictions`.** Was jedoch in neueren Versionen ausgeführt wird, sind die **Anfangsprüfungen der Funktion** (Sie können die Bedingungen im Zusammenhang mit iOS oder Simulation entfernen, da diese in macOS nicht verwendet werden).
{% endhint %}
### Bibliotheksvalidierung
Auch wenn die Binärdatei die Verwendung der **`DYLD_INSERT_LIBRARIES`** Umgebungsvariable zulässt, wird sie keine benutzerdefinierte Bibliothek laden, wenn die Binärdatei die Signatur der Bibliothek überprüft.
Auch wenn die Binärdatei die Verwendung der **`DYLD_INSERT_LIBRARIES`**-Umgebungsvariable zulässt, wird eine benutzerdefinierte Bibliothek nicht geladen, wenn die Binärdatei die Signatur der Bibliothek überprüft.
Um eine benutzerdefinierte Bibliothek zu laden, muss die Binärdatei eine der folgenden Berechtigungen haben:
@ -50,11 +58,11 @@ Um eine benutzerdefinierte Bibliothek zu laden, muss die Binärdatei eine der fo
oder die Binärdatei darf nicht das gehärtete Laufzeitflag oder das Bibliotheksvalidierungsflag haben.
Sie können überprüfen, ob eine Binärdatei das **gehärtete Laufzeitflag** hat, indem Sie `codesign --display --verbose <bin>` ausführen und die Laufzeitflag in **`CodeDirectory`** überprüfen, z. B.: **`CodeDirectory v=20500 size=767 flags=0x10000(runtime) hashes=13+7 location=embedded`**
Sie können überprüfen, ob eine Binärdatei das **gehärtete Laufzeit** hat, mit `codesign --display --verbose <bin>` und das Laufzeitflag in **`CodeDirectory`** überprüfen, z. B.: **`CodeDirectory v=20500 size=767 flags=0x10000(runtime) hashes=13+7 location=embedded`**
Sie können auch eine Bibliothek laden, wenn sie mit demselben Zertifikat wie die Binärdatei signiert ist.
Sie können auch eine Bibliothek laden, wenn sie **mit demselben Zertifikat wie die Binärdatei signiert ist**.
Ein Beispiel, wie dies (miss)braucht werden kann, und die Einschränkungen finden Sie unter:
Finden Sie ein Beispiel, wie Sie dies (miss)brauchen können, und überprüfen Sie die Einschränkungen in:
{% content-ref url="macos-dyld-hijacking-and-dyld_insert_libraries.md" %}
[macos-dyld-hijacking-and-dyld\_insert\_libraries.md](macos-dyld-hijacking-and-dyld\_insert\_libraries.md)
@ -63,42 +71,56 @@ Ein Beispiel, wie dies (miss)braucht werden kann, und die Einschränkungen finde
## Dylib-Hijacking
{% hint style="danger" %}
Denken Sie daran, dass **die zuvor genannten Einschränkungen für die Bibliotheksvalidierung** auch für Dylib-Hijacking-Angriffe gelten.
Denken Sie daran, dass **frühere Einschränkungen der Bibliotheksvalidierung** auch für Dylib-Hijacking-Angriffe gelten.
{% endhint %}
Wie in Windows können Sie auch in MacOS **dylibs hijacken**, um Anwendungen zur Ausführung von beliebigem Code zu bringen (nun, tatsächlich könnte dies von einem normalen Benutzer aus nicht möglich sein, da möglicherweise eine TCC-Berechtigung erforderlich ist, um in ein `.app`-Bundle zu schreiben und eine Bibliothek zu hijacken).\
Die Art und Weise, wie **MacOS** Anwendungen Bibliotheken laden, ist jedoch **stärker eingeschränkt** als in Windows. Dies bedeutet, dass **Malware-Entwickler** diese Technik immer noch für **Tarnung** verwenden können, aber die Wahrscheinlichkeit, dass sie dies zur **Privileg-Eskalation missbrauchen können, ist viel geringer**.
Wie in Windows können Sie auch in MacOS **dylibs hijacken**, um **Anwendungen** dazu zu bringen, **beliebigen** **Code** auszuführen (nun, tatsächlich könnte dies von einem regulären Benutzer aus nicht möglich sein, da Sie möglicherweise eine TCC-Berechtigung benötigen, um in einem `.app`-Bundle zu schreiben und eine Bibliothek zu hijacken).\
Der Weg, wie **MacOS**-Anwendungen Bibliotheken **laden**, ist jedoch **stärker eingeschränkt** als in Windows. Dies bedeutet, dass **Malware**-Entwickler diese Technik immer noch für **Stealth** verwenden können, aber die Wahrscheinlichkeit, dies zu missbrauchen, um Berechtigungen zu eskalieren, ist viel geringer.
Zunächst ist es **häufiger**, dass **MacOS-Binärdateien den vollständigen Pfad** zu den zu ladenden Bibliotheken angeben. Und zweitens **sucht MacOS niemals** in den Ordnern des **$PATH** nach Bibliotheken.
Zunächst ist es **häufiger**, dass **MacOS-Binärdateien den vollständigen Pfad** zu den zu ladenden Bibliotheken angeben. Zweitens **sucht MacOS nie** in den Ordnern des **$PATH** nach Bibliotheken.
Der **Hauptteil des Codes**, der mit dieser Funktionalität zusammenhängt, befindet sich in **`ImageLoader::recursiveLoadLibraries`** in `ImageLoader.cpp`.
Der **Hauptteil** des **Codes** im Zusammenhang mit dieser Funktionalität befindet sich in **`ImageLoader::recursiveLoadLibraries`** in `ImageLoader.cpp`.
Es gibt **4 verschiedene Befehle im Header**, die eine Macho-Binärdatei zum Laden von Bibliotheken verwenden kann:
Es gibt **4 verschiedene Header-Befehle**, die eine Macho-Binärdatei verwenden kann, um Bibliotheken zu laden:
* Der Befehl **`LC_LOAD_DYLIB`** ist der übliche Befehl zum Laden einer dylib.
* Der Befehl **`LC_LOAD_WEAK_DYLIB`** funktioniert wie der vorherige, aber wenn die dylib nicht gefunden wird, wird die Ausführung ohne Fehler fortgesetzt.
* Der Befehl **`LC_REEXPORT_DYLIB`** leitet (oder re-exportiert) die Symbole aus einer anderen Bibliothek weiter.
* Der Befehl **`LC_REEXPORT_DYLIB`** leitet (oder reexportiert) die Symbole aus einer anderen Bibliothek weiter.
* Der Befehl **`LC_LOAD_UPWARD_DYLIB`** wird verwendet, wenn zwei Bibliotheken voneinander abhängen (dies wird als _upward dependency_ bezeichnet).
Es gibt jedoch **2 Arten von Dylib-Hijacking**:
* \*\*Fehlende schwach verknüpfte Bibliotheken
* Wenn **`LC_LOAD_DYLIB`** `@rpath/library.dylib` enthält und **`LC_RPATH`** `/application/app.app/Contents/Framework/v1/` und `/application/app.app/Contents/Framework/v2/` enthält. Beide Ordner werden verwendet, um `library.dylib` zu laden. Wenn die Bibliothek nicht in `[...]/v1/` existiert und der Angreifer sie dort platzieren kann, kann er den Ladevorgang der Bibliothek in `[...]/v2/` übernehmen, da die Reihenfolge der Pfade in **`LC_LOAD_DYLIB`** befolgt wird.
* **Finde rpath-Pfade und Bibliotheken** in Binärdateien mit: `otool -l </path/to/binary> | grep -E "LC_RPATH|LC_LOAD_DYLIB" -A 5`
* **Fehlende schwach verknüpfte Bibliotheken**: Dies bedeutet, dass die Anwendung versuchen wird, eine Bibliothek zu laden, die nicht existiert und mit **LC\_LOAD\_WEAK\_DYLIB** konfiguriert ist. Dann wird die Bibliothek geladen, **wenn ein Angreifer eine Bibliothek dort platziert, wo sie erwartet wird**.
* Die Tatsache, dass die Verknüpfung "schwach" ist, bedeutet, dass die Anwendung weiterhin ausgeführt wird, auch wenn die Bibliothek nicht gefunden wird.
* Der **Code** dazu befindet sich in der Funktion `ImageLoaderMachO::doGetDependentLibraries` in `ImageLoaderMachO.cpp`, wo `lib->required` nur `false` ist, wenn `LC_LOAD_WEAK_DYLIB` wahr ist.
* **Suchen Sie nach schwach verknüpften Bibliotheken** in Binärdateien (Sie haben später ein Beispiel, wie Sie Hijacking-Bibliotheken erstellen können):
* ```bash
otool -l </Pfad/zur/Binärdatei> | grep LC_LOAD_WEAK_DYLIB -A 5 cmd LC_LOAD_WEAK_DYLIB
cmdsize 56
name /var/tmp/lib/libUtl.1.dylib (offset 24)
time stamp 2 Wed Jun 21 12:23:31 1969
current version 1.0.0
compatibility version 1.0.0
```
* **Konfiguriert mit @rpath**: Mach-O-Binärdateien können die Befehle **`LC_RPATH`** und **`LC_LOAD_DYLIB`** haben. Abhängig von den **Werten** dieser Befehle werden **Bibliotheken** aus **verschiedenen Verzeichnissen** geladen.
* **`LC_RPATH`** enthält die Pfade einiger Ordner, die von der Binärdatei zum Laden von Bibliotheken verwendet werden.
* **`LC_LOAD_DYLIB`** enthält den Pfad zu spezifischen Bibliotheken zum Laden. Diese Pfade können **`@rpath`** enthalten, das durch die Werte in **`LC_RPATH`** ersetzt wird. Wenn mehrere Pfade in **`LC_RPATH`** vorhanden sind, werden alle verwendet, um die zu ladende Bibliothek zu suchen. Beispiel:
* Wenn **`LC_LOAD_DYLIB`** `@rpath/library.dylib` enthält und **`LC_RPATH`** `/application/app.app/Contents/Framework/v1/` und `/application/app.app/Contents/Framework/v2/` enthält. Beide Ordner werden verwendet, um `library.dylib` zu laden. Wenn die Bibliothek nicht in `[...]/v1/` existiert und ein Angreifer sie dort platzieren könnte, um das Laden der Bibliothek in `[...]/v2/` zu übernehmen, da die Reihenfolge der Pfade in **`LC_LOAD_DYLIB`** befolgt wird.
* **Suche rpath-Pfade und Bibliotheken** in Binärdateien mit: `otool -l </path/zur/binary> | grep -E "LC_RPATH|LC_LOAD_DYLIB" -A 5`
{% hint style="info" %}
**`@executable_path`**: Ist der **Pfad** zum Verzeichnis, das die **Hauptausführungsdatei** enthält.
**`@loader_path`**: Ist der **Pfad** zum **Verzeichnis**, das die **Mach-O-Binärdatei** enthält, die den Ladebefehl enthält.
**`@loader_path`**: Ist der **Pfad** zum **Verzeichnis**, das die **Mach-O-Binärdatei** enthält, die den Ladungsbefehl enthält.
* Wenn es in einer ausführbaren Datei verwendet wird, ist **`@loader_path`** effektiv dasselbe wie **`@executable_path`**.
* Wenn es in einer **dylib** verwendet wird, gibt **`@loader_path`** den **Pfad** zur **dylib** an.
* Wenn es in einer Ausführbaren verwendet wird, ist **`@loader_path`** effektiv das **gleiche** wie **`@executable_path`**.
* Wenn es in einem **dylib** verwendet wird, gibt **`@loader_path`** den **Pfad** zur **dylib** an.
{% endhint %}
Die Möglichkeit, Privilegien zu eskalieren, indem diese Funktion missbraucht wird, besteht im seltenen Fall, dass eine **Anwendung**, die von **root** ausgeführt wird, nach einer **Bibliothek in einem Ordner sucht, in dem der Angreifer Schreibberechtigungen hat**.
Der Weg zur **Privilegieneskalation** durch den Missbrauch dieser Funktionalität wäre im seltenen Fall, dass eine **Anwendung**, die von **root** ausgeführt wird, nach einer **Bibliothek in einem Ordner sucht, in dem der Angreifer Schreibberechtigungen hat.**
{% hint style="success" %}
Ein nützlicher **Scanner**, um **fehlende Bibliotheken** in Anwendungen zu finden, ist [**Dylib Hijack Scanner**](https://objective-see.com/products/dhs.html) oder eine [**CLI-Version**](https://github.com/pandazheng/DylibHijack).\
Ein nützlicher **Scanner** zum Auffinden von **fehlenden Bibliotheken** in Anwendungen ist [**Dylib Hijack Scanner**](https://objective-see.com/products/dhs.html) oder eine [**CLI-Version**](https://github.com/pandazheng/DylibHijack).\
Ein guter **Bericht mit technischen Details** zu dieser Technik finden Sie [**hier**](https://www.virusbulletin.com/virusbulletin/2015/03/dylib-hijacking-os-x).
{% endhint %}
@ -108,16 +130,15 @@ Ein guter **Bericht mit technischen Details** zu dieser Technik finden Sie [**hi
[macos-dyld-hijacking-and-dyld\_insert\_libraries.md](macos-dyld-hijacking-and-dyld\_insert\_libraries.md)
{% endcontent-ref %}
## Dlopen-Hijacking
## Dlopen Hijacking
{% hint style="danger" %}
Denken Sie daran, dass auch die **vorherigen Einschränkungen der Bibliotheksvalidierung** für Dlopen-Hijacking-Angriffe gelten.
Denken Sie daran, dass auch die **früheren Einschränkungen der Bibliotheksvalidierung** gelten, um Dlopen-Hijacking-Angriffe durchzuführen.
{% endhint %}
Aus **`man dlopen`**:
* Wenn der Pfad **kein Schrägstrich-Zeichen** enthält (d.h. es handelt sich nur um einen Blattnamen), sucht dlopen() nach der Bibliothek. Wenn **`$DYLD_LIBRARY_PATH`** beim Start festgelegt wurde, sucht dyld zuerst in diesem Verzeichnis. Anschließend sucht dyld in den Verzeichnissen, die vom aufrufenden Mach-O-Datei oder der Hauptausführungsdatei angegeben sind, wenn ein **`LC_RPATH`** vorhanden ist. Wenn der Prozess **unbeschränkt** ist, sucht dyld im **aktuellen Arbeitsverzeichnis**. Schließlich versucht dyld bei alten Binärdateien einige Fallbacks. Wenn **`$DYLD_FALLBACK_LIBRARY_PATH`** beim Start festgelegt wurde, sucht dyld in diesen Verzeichnissen. Andernfalls sucht dyld in **`/usr/local/lib/`** (wenn der Prozess unbeschränkt ist) und dann in **`/usr/lib/`** (diese Informationen stammen aus **`man dlopen`**).
* Wenn der Pfad **kein Schrägstrichzeichen enthält** (d.h. es handelt sich nur um einen Blattnamen), wird **dlopen() eine Suche durchführen**. Wenn **`$DYLD_LIBRARY_PATH`** beim Start festgelegt war, sucht dyld zuerst in diesem Verzeichnis. Als Nächstes, wenn die aufrufende Mach-O-Datei oder die Hauptausführbare eine **`LC_RPATH`** angeben, sucht dyld in diesen Verzeichnissen. Als Nächstes, wenn der Prozess **unbeschränkt** ist, sucht dyld im **aktuellen Arbeitsverzeichnis**. Schließlich versucht dyld für alte Binärdateien einige Ausweichmöglichkeiten. Wenn **`$DYLD_FALLBACK_LIBRARY_PATH`** beim Start festgelegt war, sucht dyld in **diesen Verzeichnissen**, andernfalls sucht dyld in **`/usr/local/lib/`** (wenn der Prozess unbeschränkt ist), und dann in **`/usr/lib/`** (diese Informationen stammen aus **`man dlopen`**).
1. `$DYLD_LIBRARY_PATH`
2. `LC_RPATH`
3. `CWD` (wenn unbeschränkt)
@ -126,48 +147,51 @@ Aus **`man dlopen`**:
6. `/usr/lib/`
{% hint style="danger" %}
Wenn kein Schrägstrich im Namen enthalten ist, gibt es 2 Möglichkeiten, ein Hijacking durchzuführen:
Wenn kein Schrägstrich im Namen vorhanden ist, gibt es 2 Möglichkeiten, ein Hijacking durchzuführen:
* Wenn ein **`LC_RPATH`** **beschreibbar** ist (aber die Signatur überprüft wird, daher muss die Binärdatei auch unbeschränkt sein)
* Wenn die Binärdatei **unbeschränkt** ist und dann etwas aus dem CWD geladen werden kann (oder indem eine der genannten Umgebungsvariablen missbraucht wird)
* Wenn ein **`LC_RPATH`** **beschreibbar** ist (aber die Signatur überprüft wird, daher benötigen Sie auch, dass die Binärdatei unbeschränkt ist)
* Wenn die Binärdatei **unbeschränkt** ist und dann etwas aus dem CWD geladen werden kann (oder durch den Missbrauch einer der genannten Umgebungsvariablen)
{% endhint %}
* Wenn der Pfad **wie ein Framework-Pfad aussieht** (z.B. `/stuff/foo.framework/foo`), sucht dyld zuerst in **`$DYLD_FRAMEWORK_PATH`**, wenn es beim Start festgelegt wurde, nach dem **Framework-Teilpfad** (z.B. `foo.framework/foo`). Anschließend versucht dyld den **angegebenen Pfad** (unter Verwendung des aktuellen Arbeitsverzeichnisses für relative Pfade). Schließlich versucht dyld bei alten Binärdateien einige Fallbacks. Wenn **`$DYLD_FALLBACK_FRAMEWORK_PATH`** beim Start festgelegt wurde, sucht dyld in diesen Verzeichnissen. Andernfalls sucht dyld in **`/Library/Frameworks`** (auf macOS, wenn der Prozess unbeschränkt ist) und dann in **`/System/Library/Frameworks`**.
* Wenn der Pfad **wie ein Framework-Pfad aussieht** (z.B. `/stuff/foo.framework/foo`), sucht dyld zuerst im Verzeichnis nach dem **Framework-Teilpfad** (z.B. `foo.framework/foo`), wenn **`$DYLD_FRAMEWORK_PATH`** beim Start festgelegt war. Als Nächstes versucht dyld den **angegebenen Pfad wie angegeben** (verwendet das aktuelle Arbeitsverzeichnis für relative Pfade). Schließlich versucht dyld für alte Binärdateien einige Ausweichmöglichkeiten. Wenn **`$DYLD_FALLBACK_FRAMEWORK_PATH`** beim Start festgelegt war, sucht dyld in diesen Verzeichnissen. Andernfalls sucht dyld in **`/Library/Frameworks`** (auf macOS, wenn der Prozess unbeschränkt ist), dann in **`/System/Library/Frameworks`**.
1. `$DYLD_FRAMEWORK_PATH`
2. angegebener Pfad (unter Verwendung des aktuellen Arbeitsverzeichnisses für relative Pfade, wenn unbeschränkt)
2. angegebener Pfad (verwendet das aktuelle Arbeitsverzeichnis für relative Pfade, wenn unbeschränkt)
3. `$DYLD_FALLBACK_FRAMEWORK_PATH`
4. `/Library/Frameworks` (wenn unbeschränkt)
5. `/System/Library/Frameworks`
{% hint style="danger" %}
Wenn es sich um einen Framework-Pfad handelt, besteht die Möglichkeit, ihn zu hijacken:
Bei einem Framework-Pfad wäre der Weg, es zu übernehmen:
* Wenn der Prozess **unbeschränkt** ist, indem der relative Pfad vom CWD oder die genannten Umgebungsvariablen missbraucht werden (auch wenn in der Dokumentation nicht angegeben ist, ob der Prozess beschränkt ist, werden DYLD\_\* Umgebungsvariablen entfernt)
* Wenn der Prozess **unbeschränkt** ist, Missbrauch des **relativen Pfads vom CWD** der genannten Umgebungsvariablen (auch wenn in den Dokumenten nicht gesagt wird, ob die Prozesse eingeschränkt sind, werden DYLD\_\* Umgebungsvariablen entfernt)
{% endhint %}
* Wenn der Pfad **einen Schrägstrich enthält, aber kein Framework-Pfad ist** (d.h. ein vollständiger Pfad oder ein Teilpfad zu einer dylib), sucht dlopen() zuerst in (falls festgelegt) **`$DYLD_LIBRARY_PATH`** (mit dem Blattnamen aus dem Pfad). Anschließend versucht dyld den angegebenen Pfad (unter Verwendung des aktuellen Arbeitsverzeichnisses für relative Pfade (aber nur für unbeschränkte Prozesse)). Schließlich versucht dyld bei älteren Binärdateien einige Fallbacks. Wenn **`$DYLD_FALLBACK_LIBRARY_PATH`** beim Start festgelegt wurde, sucht dyld in diesen Verzeichnissen. Andernfalls sucht dyld in **`/usr/local/lib/`** (wenn der Prozess unbeschränkt ist) und dann in **`/usr/lib/`**.
* Wenn der Pfad **ein Schrägstrich enthält, aber kein Framework-Pfad ist** (d.h. ein vollständiger Pfad oder ein Teilpfad zu einer dylib), sucht dlopen() zuerst (falls festgelegt) in **`$DYLD_LIBRARY_PATH`** (mit dem Blattteil des Pfads). Als Nächstes versucht dyld den angegebenen Pfad (verwendet das aktuelle Arbeitsverzeichnis für relative Pfade (aber nur für unbeschränkte Prozesse)). Schließlich versucht dyld für ältere Binärdateien einige Ausweichmöglichkeiten. Wenn **`$DYLD_FALLBACK_LIBRARY_PATH`** beim Start festgelegt war, sucht dyld in diesen Verzeichnissen, andernfalls sucht dyld in **`/usr/local/lib/`** (wenn der Prozess unbeschränkt ist), und dann in **`/usr/lib/`**.
1. `$DYLD_LIBRARY_PATH`
2. angegebener Pfad (unter Verwendung des aktuellen Arbeitsverzeichnisses für relative Pfade, wenn unbeschränkt)
2. angegebener Pfad (verwendet das aktuelle Arbeitsverzeichnis für relative Pfade, wenn unbeschränkt)
3. `$DYLD_FALLBACK_LIBRARY_PATH`
4. `/usr/local/lib/` (wenn unbeschränkt)
5. `/usr/lib/`
{% hint style="danger" %}
Wenn Schrägstriche im Namen enthalten sind und es sich nicht um einen Framework-Pfad handelt, besteht die Möglichkeit, ihn zu hijacken:
Wenn Schrägstriche im Namen vorhanden sind und es sich nicht um einen Framework-Pfad handelt, wäre der Weg, es zu übernehmen:
* Wenn die Binärdatei **unbeschränkt** ist und dann etwas aus dem CWD oder `/usr/local/lib` geladen werden kann (oder indem eine der genannten Umgebungsvariablen missbraucht wird)
* Wenn die Binärdatei **unbeschränkt** ist und dann etwas aus dem CWD oder `/usr/local/lib` geladen werden kann (oder durch den Missbrauch einer der genannten Umgebungsvariablen)
{% endhint %}
Hinweis: Es gibt **keine** Konfigurationsdateien, um die dlopen-Suche zu steuern.
{% hint style="info" %}
Hinweis: Es gibt **keine** Konfigurationsdateien, um die **dlopen-Suche zu steuern**.
Hinweis: Wenn die Hauptausführungsdatei ein **set\[ug]id-Binary oder mit Berechtigungen signiert** ist, werden **alle Umgebungsvariablen ignoriert** und es kann nur ein vollständiger Pfad verwendet werden (weitere Informationen finden Sie unter **Überprüfen der Einschränkungen von DYLD\_INSERT\_LIBRARIES**).
Hinweis: Wenn die Hauptausführbare eine **set\[ug\]id-Binärdatei oder mit Berechtigungen signiert** ist, werden **alle Umgebungsvariablen ignoriert**, und es kann nur ein vollständiger Pfad verwendet werden ([überprüfen Sie die Einschränkungen von DYLD\_INSERT\_LIBRARIES](macos-dyld-hijacking-and-dyld\_insert\_libraries.md#check-dyld\_insert\_librery-restrictions) für detailliertere Informationen)
Hinweis: Apple-Plattformen verwenden "universelle" Dateien, um 32-Bit- und 64-Bit-Bibliotheken zu kombinieren. Dies bedeutet, dass es **keine separaten Suchpfade für 32-Bit- und 64-Bit-Bibliotheken** gibt.
Hinweis: Apple-Plattformen verwenden "universelle" Dateien, um 32-Bit- und 64-Bit-Bibliotheken zu kombinieren. Dies bedeutet, dass es **keine separaten Suchpfade für 32-Bit und 64-Bit** gibt.
Hinweis: Auf Apple-Plattformen sind die meisten Betriebssystem-Dylibs in den dyld-Cache **kombiniert** und existieren nicht auf der Festplatte. Daher funktioniert der Aufruf von **`stat()`**, um vorab zu überprüfen, ob eine Betriebssystem-Dylib vorhanden ist, **nicht**. Die Funktion **`dlopen_preflight()`** verwendet jedoch die gleichen Schritte wie **`dlopen()`**, um eine kom
Hinweis: Auf Apple-Plattformen werden die meisten OS-Dylibs in den dyld-Cache **kombiniert** und existieren nicht auf der Festplatte. Daher funktioniert das Aufrufen von **`stat()`** zur Vorabprüfung, ob eine OS-Dylib existiert, **nicht**. Jedoch verwendet **`dlopen_preflight()`** die gleichen Schritte wie **`dlopen()`**, um eine kompatible Mach-O-Datei zu finden.
{% endhint %}
**Pfade überprüfen**
Lassen Sie uns alle Optionen mit dem folgenden Code überprüfen:
```c
// gcc dlopentest.c -o dlopentest -Wl,-rpath,/tmp/test
#include <dlfcn.h>
@ -210,33 +234,27 @@ fprintf(stderr, "Error loading: %s\n\n\n", dlerror());
return 0;
}
```
Wenn Sie es kompilieren und ausführen, können Sie sehen, **wo jede Bibliothek erfolglos gesucht wurde**. Außerdem könnten Sie **die FS-Protokolle filtern**:
```bash
sudo fs_usage | grep "dlopentest"
```
## Relative Path Hijacking
Wenn eine **privilegierte Binärdatei/App** (wie eine SUID oder eine Binärdatei mit mächtigen Berechtigungen) eine **relative Pfadbibliothek lädt** (zum Beispiel mit `@executable_path` oder `@loader_path`) und die **Bibliotheksvalidierung deaktiviert** ist, könnte es möglich sein, die Binärdatei an einen Ort zu verschieben, an dem der Angreifer die geladene relative Pfadbibliothek **ändern** und sie missbrauchen kann, um Code in den Prozess einzuspritzen.
Wenn ein **privilegiertes Binary/App** (wie ein SUID oder ein Binary mit leistungsstarken Berechtigungen) eine **relative Pfad**-Bibliothek lädt (zum Beispiel mit `@executable_path` oder `@loader_path`) und die **Library Validation deaktiviert** ist, könnte es möglich sein, das Binary an einen Ort zu verschieben, an dem der Angreifer die geladene relative Pfadbibliothek **modifizieren** und sie missbrauchen könnte, um Code in den Prozess einzuspeisen.
## Bereinigung der `DYLD_*` und `LD_LIBRARY_PATH` Umgebungsvariablen
## Bereinigen von `DYLD_*` und `LD_LIBRARY_PATH` Umgebungsvariablen
In der Datei `dyld-dyld-832.7.1/src/dyld2.cpp` befindet sich die Funktion **`pruneEnvironmentVariables`**, die alle Umgebungsvariablen entfernt, die mit `DYLD_` beginnen und `LD_LIBRARY_PATH=` enthalten.
In der Datei `dyld-dyld-832.7.1/src/dyld2.cpp` ist es möglich, die Funktion **`pruneEnvironmentVariables`** zu finden, die jede Umgebungsvariable entfernt, die mit `DYLD_` beginnt und `LD_LIBRARY_PATH=`.
Sie setzt auch speziell die Umgebungsvariablen **`DYLD_FALLBACK_FRAMEWORK_PATH`** und **`DYLD_FALLBACK_LIBRARY_PATH`** für **suid** und **sgid** Binärdateien auf **null**.
Diese Funktion wird aus der **`_main`** Funktion derselben Datei aufgerufen, wenn OSX als Zielplattform verwendet wird:
Es setzt auch explizit die Umgebungsvariablen **`DYLD_FALLBACK_FRAMEWORK_PATH`** und **`DYLD_FALLBACK_LIBRARY_PATH`** für **suid** und **sgid** Binaries auf **null**.
Diese Funktion wird aus der **`_main`** Funktion derselben Datei auf OSX abzielen, wie folgt aufgerufen:
```cpp
#if TARGET_OS_OSX
if ( !gLinkContext.allowEnvVarsPrint && !gLinkContext.allowEnvVarsPath && !gLinkContext.allowEnvVarsSharedCache ) {
pruneEnvironmentVariables(envp, &apple);
```
und diese booleschen Flags werden in derselben Datei im Code festgelegt:
und diese booleschen Flags werden im gleichen Codefile gesetzt:
```cpp
#if TARGET_OS_OSX
// support chrooting from old kernel
@ -267,15 +285,13 @@ gLinkContext.allowClassicFallbackPaths = !isRestricted;
gLinkContext.allowInsertFailures = false;
gLinkContext.allowInterposing = true;
```
Das bedeutet im Grunde genommen, dass wenn die Binärdatei **suid** oder **sgid** ist, oder ein **RESTRICT**-Segment in den Headern hat oder mit dem **CS\_RESTRICT**-Flag signiert wurde, dann ist **`!gLinkContext.allowEnvVarsPrint && !gLinkContext.allowEnvVarsPath && !gLinkContext.allowEnvVarsSharedCache`** wahr und die Umgebungsvariablen werden beschnitten.
Das bedeutet im Grunde genommen, dass wenn die Binärdatei **suid** oder **sgid** ist, einen **RESTRICT**-Segment in den Headern hat oder mit dem **CS\_RESTRICT**-Flag signiert wurde, dann ist **`!gLinkContext.allowEnvVarsPrint && !gLinkContext.allowEnvVarsPath && !gLinkContext.allowEnvVarsSharedCache`** wahr und die Umgebungsvariablen werden entfernt.
Beachten Sie, dass wenn CS\_REQUIRE\_LV wahr ist, die Variablen nicht entfernt werden, sondern die Bibliotheksvalidierung überprüft, ob sie dasselbe Zertifikat wie die ursprüngliche Binärdatei verwenden.
Beachten Sie, dass wenn CS\_REQUIRE\_LV wahr ist, dann werden die Variablen nicht beschnitten, aber die Bibliotheksvalidierung wird überprüfen, ob sie dasselbe Zertifikat wie die originale Binärdatei verwenden.
## Überprüfen von Einschränkungen
### SUID & SGID
```bash
# Make it owned by root and suid
sudo chown root hello
@ -286,26 +302,11 @@ DYLD_INSERT_LIBRARIES=inject.dylib ./hello
# Remove suid
sudo chmod -s hello
```
### Abschnitt `__RESTRICT` mit Segment `__restrict`
In macOS können Bibliotheken mit dem `__RESTRICT`-Segment verwendet werden, um die Ausführung von Code in bestimmten Prozessen einzuschränken. Dieses Segment kann verwendet werden, um die Sicherheit und Privilegien von Prozessen zu erhöhen.
Das `__RESTRICT`-Segment ermöglicht es, dass nur bestimmte Prozesse auf den Code in der Bibliothek zugreifen können. Dies kann nützlich sein, um die Ausführung von bösartigem Code in privilegierten Prozessen zu verhindern.
Um das `__RESTRICT`-Segment zu verwenden, muss der Code in der Bibliothek so konfiguriert werden, dass er nur in den gewünschten Prozessen ausgeführt wird. Dies kann durch Überprüfung der Prozess-ID oder anderer Prozessattribute erreicht werden.
Es ist wichtig zu beachten, dass das `__RESTRICT`-Segment allein nicht ausreicht, um die Sicherheit eines Prozesses zu gewährleisten. Es sollte als Teil eines umfassenden Sicherheitskonzepts verwendet werden, das andere Schutzmechanismen wie Sandboxing und Berechtigungsprüfungen umfasst.
Die Verwendung des `__RESTRICT`-Segments erfordert ein gründliches Verständnis der macOS-Systemarchitektur und der Prozessverwaltung. Es ist ratsam, sich mit den offiziellen Dokumentationen und Best Practices von Apple vertraut zu machen, um sicherzustellen, dass die Implementierung korrekt und sicher ist.
**Hinweis:** Das `__RESTRICT`-Segment ist eine fortgeschrittene Technik und erfordert spezifisches Wissen über macOS-Sicherheit und Privilegien-Eskalation. Es sollte nur von erfahrenen Entwicklern und Sicherheitsexperten verwendet werden.
```bash
gcc -sectcreate __RESTRICT __restrict /dev/null hello.c -o hello-restrict
DYLD_INSERT_LIBRARIES=inject.dylib ./hello-restrict
```
### Gehärtete Laufzeit
Erstellen Sie ein neues Zertifikat im Schlüsselbund und verwenden Sie es, um die Binärdatei zu signieren:
@ -333,31 +334,30 @@ DYLD_INSERT_LIBRARIES=inject.dylib ./hello-signed # Won't work
{% endcode %}
{% hint style="danger" %}
Beachten Sie, dass auch wenn es Binärdateien gibt, die mit den Flags **`0x0(none)`** signiert sind, sie das Flag **`CS_RESTRICT`** dynamisch erhalten können, wenn sie ausgeführt werden, und daher funktioniert diese Technik nicht bei ihnen.
Sie können überprüfen, ob ein Prozess dieses Flag hat, indem Sie (holen Sie sich [**hier csops**](https://github.com/axelexic/CSOps)):
Beachten Sie, dass auch wenn Binärdateien mit Flags **`0x0(none)`** signiert sind, sie das Flag **`CS_RESTRICT`** dynamisch erhalten können, wenn sie ausgeführt werden, und daher diese Technik bei ihnen nicht funktioniert.
Sie können überprüfen, ob ein Prozess dieses Flag mit (erhalten Sie [**hier csops**](https://github.com/axelexic/CSOps)):
```bash
csops -status <pid>
```
und überprüfen Sie dann, ob die Flagge 0x800 aktiviert ist.
{% endhint %}
## Referenzen
* [https://theevilbit.github.io/posts/dyld\_insert\_libraries\_dylib\_injection\_in\_macos\_osx\_deep\_dive/](https://theevilbit.github.io/posts/dyld\_insert\_libraries\_dylib\_injection\_in\_macos\_osx\_deep\_dive/)
* [**\*OS Internals, Band I: Benutzermodus. Von Jonathan Levin**](https://www.amazon.com/MacOS-iOS-Internals-User-Mode/dp/099105556X)
<details>
<summary><strong>Lernen Sie AWS-Hacking von Grund auf mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
<summary><strong>Erlernen Sie AWS-Hacking von Null auf Held mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Andere Möglichkeiten, HackTricks zu unterstützen:
* Wenn Sie Ihr **Unternehmen in HackTricks bewerben möchten** oder **HackTricks im PDF-Format herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com)
* Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen möchten** oder **HackTricks im PDF-Format herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merch**](https://peass.creator-spring.com)
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repositories senden.
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repositorys einreichen.
</details>

322
macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-library-injection/macos-dyld-process.md Normal file
View file

@ -0,0 +1,322 @@
# macOS Dyld Prozess
<details>
<summary><strong>Lernen Sie AWS-Hacking von Grund auf mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Andere Möglichkeiten, HackTricks zu unterstützen:
* Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen möchten** oder **HackTricks in PDF herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com)
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repositories einreichen.
</details>
## Grundlegende Informationen
Der eigentliche **Einstiegspunkt** eines Mach-o-Binärdatei ist der dynamische Linker, der in `LC_LOAD_DYLINKER` definiert ist und normalerweise `/usr/lib/dyld` ist.
Dieser Linker muss alle ausführbaren Bibliotheken lokalisieren, sie im Speicher abbilden und alle nicht-faulen Bibliotheken verknüpfen. Erst nach diesem Prozess wird der Einstiegspunkt der Binärdatei ausgeführt.
Natürlich hat **`dyld`** keine Abhängigkeiten (es verwendet Systemaufrufe und libSystem-Auszüge).
{% hint style="danger" %}
Wenn dieser Linker eine Sicherheitslücke aufweist, da er vor der Ausführung von Binärdateien (auch hochprivilegierten) ausgeführt wird, wäre es möglich, **Berechtigungen zu eskalieren**.
{% endhint %}
### Ablauf
Dyld wird von **`dyldboostrap::start`** geladen, der auch Dinge wie den **Stack-Canary** lädt. Dies liegt daran, dass diese Funktion im **`apple`**-Argumentvektor diesen und andere **sensible Werte** erhält.
**`dyls::_main()`** ist der Einstiegspunkt von dyld und seine erste Aufgabe besteht darin, `configureProcessRestrictions()` auszuführen, das normalerweise die **`DYLD_*`**-Umgebungsvariablen einschränkt, wie in erklärt:
{% content-ref url="./" %}
[.](./)
{% endcontent-ref %}
Dann wird der dyld-Shared-Cache abgebildet, der alle wichtigen Systembibliotheken vorverknüpft, und dann werden die Bibliotheken abgebildet, von denen die Binärdatei abhängt, und dies wird rekursiv fortgesetzt, bis alle benötigten Bibliotheken geladen sind. Daher:
1. beginnt es mit dem Laden eingefügter Bibliotheken mit `DYLD_INSERT_LIBRARIES` (falls erlaubt)
2. Dann die freigegebenen gecachten
3. Dann die importierten
1. &#x20;Dann weiterhin Bibliotheken rekursiv importieren
Sobald alle geladen sind, werden die **Initialisierer** dieser Bibliotheken ausgeführt. Diese sind mit **`__attribute__((constructor))`** codiert, definiert in `LC_ROUTINES[_64]` (jetzt veraltet) oder durch Zeiger in einem Abschnitt mit der Markierung `S_MOD_INIT_FUNC_POINTERS` (normalerweise: **`__DATA.__MOD_INIT_FUNC`**).
Terminatoren sind mit **`__attribute__((destructor))`** codiert und befinden sich in einem Abschnitt mit der Markierung `S_MOD_TERM_FUNC_POINTERS` (**`__DATA.__mod_term_func`**).
### Stubs
Alle Binärdateien in macOS sind dynamisch verknüpft. Daher enthalten sie einige Stub-Abschnitte, die der Binärdatei helfen, zum richtigen Code in verschiedenen Maschinen und Kontexten zu springen. Es ist dyld, wenn die Binärdatei ausgeführt wird, das Gehirn, das diese Adressen auflösen muss (zumindest die nicht-faulen).
Einige Stub-Abschnitte in der Binärdatei:
* **`__TEXT.__[auth_]stubs`**: Zeiger aus `__DATA`-Abschnitten
* **`__TEXT.__stub_helper`**: Kleiner Code, der das dynamische Verknüpfen mit Informationen zum aufzurufenden Funktion aufruft
* **`__DATA.__[auth_]got`**: Global Offset Table (Adressen zu importierten Funktionen, wenn aufgelöst, (während der Ladezeit gebunden, da er mit der Flagge `S_NON_LAZY_SYMBOL_POINTERS` markiert ist)
* **`__DATA.__nl_symbol_ptr`**: Nicht-faule Symbolzeiger (während der Ladezeit gebunden, da er mit der Flagge `S_NON_LAZY_SYMBOL_POINTERS` markiert ist)
* **`__DATA.__la_symbol_ptr`**: Lazy-Symbolzeiger (beim ersten Zugriff gebunden)
{% hint style="warning" %}
Beachten Sie, dass die Zeiger mit dem Präfix "auth\_" einen in-process-Verschlüsselungsschlüssel verwenden, um sie zu schützen (PAC). Außerdem ist es möglich, die arm64-Anweisung `BLRA[A/B]` zu verwenden, um den Zeiger vor dem Folgen zu überprüfen. Und das RETA\[A/B\] kann anstelle einer RET-Adresse verwendet werden.\
Tatsächlich wird der Code in **`__TEXT.__auth_stubs`** **`braa`** anstelle von **`bl`** verwenden, um die angeforderte Funktion aufzurufen, um den Zeiger zu authentifizieren.
Beachten Sie auch, dass aktuelle dyld-Versionen **alles als nicht-faul** laden.
{% endhint %}
### Lazy-Symbole finden
```c
//gcc load.c -o load
#include <stdio.h>
int main (int argc, char **argv, char **envp, char **apple)
{
printf("Hi\n");
}
```
Interessanter Disassembly-Teil:
```armasm
; objdump -d ./load
100003f7c: 90000000 adrp x0, 0x100003000 <_main+0x1c>
100003f80: 913e9000 add x0, x0, #4004
100003f84: 94000005 bl 0x100003f98 <_printf+0x100003f98>
```
Es ist möglich zu sehen, dass der Sprung zum Aufruf von printf zu **`__TEXT.__stubs`** führt:
```bash
objdump --section-headers ./load
./load: file format mach-o arm64
Sections:
Idx Name Size VMA Type
0 __text 00000038 0000000100003f60 TEXT
1 __stubs 0000000c 0000000100003f98 TEXT
2 __cstring 00000004 0000000100003fa4 DATA
3 __unwind_info 00000058 0000000100003fa8 DATA
4 __got 00000008 0000000100004000 DATA
```
Bei der Disassemblierung des **`__stubs`** Abschnitts:
```bash
objdump -d --section=__stubs ./load
./load: file format mach-o arm64
Disassembly of section __TEXT,__stubs:
0000000100003f98 <__stubs>:
100003f98: b0000010 adrp x16, 0x100004000 <__stubs+0x4>
100003f9c: f9400210 ldr x16, [x16]
100003fa0: d61f0200 br x16
```
Du kannst sehen, dass wir **zur Adresse des GOT springen**, die in diesem Fall nicht träge aufgelöst wird und die Adresse der printf-Funktion enthält.
In anderen Situationen könnte anstelle des direkten Springens zum GOT **`__DATA.__la_symbol_ptr`** verwendet werden, das einen Wert lädt, der die Funktion repräsentiert, die geladen werden soll. Anschließend wird zum **`__TEXT.__stub_helper`** gesprungen, der zum **`__DATA.__nl_symbol_ptr`** springt, der die Adresse des **`dyld_stub_binder`** enthält, der als Parameter die Nummer der Funktion und eine Adresse erhält.\
Diese letzte Funktion schreibt nach dem Auffinden der Adresse der gesuchten Funktion diese an die entsprechende Stelle in **`__TEXT.__stub_helper`**, um zukünftige Nachschlagen zu vermeiden.
{% hint style="success" %}
Beachte jedoch, dass aktuelle dyld-Versionen alles als nicht träge laden.
{% endhint %}
#### Dyld-Operationen
Schließlich muss **`dyld_stub_binder`** die angegebene Funktion finden und an die richtige Adresse schreiben, um nicht erneut danach suchen zu müssen. Dazu verwendet es Opcodes (eine endliche Zustandsmaschine) innerhalb von dyld.
## apple\[] Argumentvektor
In macOS erhält die Hauptfunktion tatsächlich 4 Argumente anstelle von 3. Das vierte wird apple genannt und jeder Eintrag hat die Form `key=value`. Zum Beispiel:
```c
// gcc apple.c -o apple
#include <stdio.h>
int main (int argc, char **argv, char **envp, char **apple)
{
for (int i=0; apple[i]; i++)
printf("%d: %s\n", i, apple[i])
}
```
Der folgende Inhalt ist aus einer Hacking-Buch über Hacking-Techniken. Der folgende Inhalt stammt aus der Datei macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-library-injection/macos-dyld-process.md. Übersetze den relevanten englischen Text ins Deutsche und gib die Übersetzung zurück, wobei genau die gleiche Markdown- und HTML-Syntax beibehalten wird. Übersetze keine Dinge wie Code, Hacking-Technikenamen, Hacking-Wörter, Cloud/SaaS-Plattformnamen (wie Workspace, aws, gcp...), das Wort 'leak', Pentesting und Markdown-Tags. Füge auch keine zusätzlichen Informationen hinzu, außer der Übersetzung und der Markdown-Syntax.
```
0: executable_path=./a
1:
2:
3:
4: ptr_munge=
5: main_stack=
6: executable_file=0x1a01000012,0x5105b6a
7: dyld_file=0x1a01000012,0xfffffff0009834a
8: executable_cdhash=757a1b08ab1a79c50a66610f3adbca86dfd3199b
9: executable_boothash=f32448504e788a2c5935e372d22b7b18372aa5aa
10: arm64e_abi=os
11: th_port=
```
{% hint style="success" %}
Zu dem Zeitpunkt, an dem diese Werte die Hauptfunktion erreichen, wurde bereits sensitive Information daraus entfernt oder es hätte zu einem Datenleck geführt.
{% endhint %}
Es ist möglich, all diese interessanten Werte beim Debuggen zu sehen, bevor sie in die Hauptfunktion gelangen:
<pre><code>lldb ./apple
<strong>(lldb) target create "./a"
</strong>Aktuelle ausführbare Datei auf '/tmp/a' gesetzt (arm64).
(lldb) process launch -s
[..]
<strong>(lldb) mem read $sp
</strong>0x16fdff510: 00 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 ................
0x16fdff520: d8 f6 df 6f 01 00 00 00 00 00 00 00 00 00 00 00 ...o............
<strong>(lldb) x/55s 0x016fdff6d8
</strong>[...]
0x16fdffd6a: "TERM_PROGRAM=WarpTerminal"
0x16fdffd84: "WARP_USE_SSH_WRAPPER=1"
0x16fdffd9b: "WARP_IS_LOCAL_SHELL_SESSION=1"
0x16fdffdb9: "SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.4.sdk"
0x16fdffe24: "NVM_DIR=/Users/carlospolop/.nvm"
0x16fdffe44: "CONDA_CHANGEPS1=false"
0x16fdffe5a: ""
0x16fdffe5b: ""
0x16fdffe5c: ""
0x16fdffe5d: ""
0x16fdffe5e: ""
0x16fdffe5f: ""
0x16fdffe60: "pfz=0xffeaf0000"
0x16fdffe70: "stack_guard=0x8af2b510e6b800b5"
0x16fdffe8f: "malloc_entropy=0xf2349fbdea53f1e4,0x3fd85d7dcf817101"
0x16fdffec4: "ptr_munge=0x983e2eebd2f3e746"
0x16fdffee1: "main_stack=0x16fe00000,0x7fc000,0x16be00000,0x4000000"
0x16fdfff17: "executable_file=0x1a01000012,0x5105b6a"
0x16fdfff3e: "dyld_file=0x1a01000012,0xfffffff0009834a"
0x16fdfff67: "executable_cdhash=757a1b08ab1a79c50a66610f3adbca86dfd3199b"
0x16fdfffa2: "executable_boothash=f32448504e788a2c5935e372d22b7b18372aa5aa"
0x16fdfffdf: "arm64e_abi=os"
0x16fdfffed: "th_port=0x103"
0x16fdffffb: ""
</code></pre>
## dyld\_all\_image\_infos
Dies ist eine Struktur, die von dyld mit Informationen über den dyld-Zustand exportiert wird und die im [**Quellcode**](https://opensource.apple.com/source/dyld/dyld-852.2/include/mach-o/dyld\_images.h.auto.html) gefunden werden kann, mit Informationen wie der Version, einem Zeiger auf das dyld\_image\_info-Array, auf dyld\_image\_notifier, ob der Prozess vom gemeinsamen Cache getrennt ist, ob der libSystem-Initializer aufgerufen wurde, einem Zeiger auf den eigenen Mach-Header von dyls, einem Zeiger auf die dyld-Version...
## dyld Umgebungsvariablen
### dyld debuggen
Interessante Umgebungsvariablen, die helfen zu verstehen, was dyld macht:
* **DYLD\_PRINT\_LIBRARIES**
Überprüfen Sie jede Bibliothek, die geladen wird:
```
DYLD_PRINT_LIBRARIES=1 ./apple
dyld[19948]: <9F848759-9AB8-3BD2-96A1-C069DC1FFD43> /private/tmp/a
dyld[19948]: <F0A54B2D-8751-35F1-A3CF-F1A02F842211> /usr/lib/libSystem.B.dylib
dyld[19948]: <C683623C-1FF6-3133-9E28-28672FDBA4D3> /usr/lib/system/libcache.dylib
dyld[19948]: <BFDF8F55-D3DC-3A92-B8A1-8EF165A56F1B> /usr/lib/system/libcommonCrypto.dylib
dyld[19948]: <B29A99B2-7ADE-3371-A774-B690BEC3C406> /usr/lib/system/libcompiler_rt.dylib
dyld[19948]: <65612C42-C5E4-3821-B71D-DDE620FB014C> /usr/lib/system/libcopyfile.dylib
dyld[19948]: <B3AC12C0-8ED6-35A2-86C6-0BFA55BFF333> /usr/lib/system/libcorecrypto.dylib
dyld[19948]: <8790BA20-19EC-3A36-8975-E34382D9747C> /usr/lib/system/libdispatch.dylib
dyld[19948]: <4BB77515-DBA8-3EDF-9AF7-3C9EAE959EA6> /usr/lib/system/libdyld.dylib
dyld[19948]: <F7CE9486-FFF5-3CB8-B26F-75811EF4283A> /usr/lib/system/libkeymgr.dylib
dyld[19948]: <1A7038EC-EE49-35AE-8A3C-C311083795FB> /usr/lib/system/libmacho.dylib
[...]
```
* **DYLD\_PRINT\_SEGMENTS**
Überprüfen Sie, wie jede Bibliothek geladen wird:
```
DYLD_PRINT_SEGMENTS=1 ./apple
dyld[21147]: re-using existing shared cache (/System/Volumes/Preboot/Cryptexes/OS/System/Library/dyld/dyld_shared_cache_arm64e):
dyld[21147]: 0x181944000->0x1D5D4BFFF init=5, max=5 __TEXT
dyld[21147]: 0x1D5D4C000->0x1D5EC3FFF init=1, max=3 __DATA_CONST
dyld[21147]: 0x1D7EC4000->0x1D8E23FFF init=3, max=3 __DATA
dyld[21147]: 0x1D8E24000->0x1DCEBFFFF init=3, max=3 __AUTH
dyld[21147]: 0x1DCEC0000->0x1E22BFFFF init=1, max=3 __AUTH_CONST
dyld[21147]: 0x1E42C0000->0x1E5457FFF init=1, max=1 __LINKEDIT
dyld[21147]: 0x1E5458000->0x22D173FFF init=5, max=5 __TEXT
dyld[21147]: 0x22D174000->0x22D9E3FFF init=1, max=3 __DATA_CONST
dyld[21147]: 0x22F9E4000->0x230F87FFF init=3, max=3 __DATA
dyld[21147]: 0x230F88000->0x234EC3FFF init=3, max=3 __AUTH
dyld[21147]: 0x234EC4000->0x237573FFF init=1, max=3 __AUTH_CONST
dyld[21147]: 0x239574000->0x270BE3FFF init=1, max=1 __LINKEDIT
dyld[21147]: Kernel mapped /private/tmp/a
dyld[21147]: __PAGEZERO (...) 0x000000904000->0x000101208000
dyld[21147]: __TEXT (r.x) 0x000100904000->0x000100908000
dyld[21147]: __DATA_CONST (rw.) 0x000100908000->0x00010090C000
dyld[21147]: __LINKEDIT (r..) 0x00010090C000->0x000100910000
dyld[21147]: Using mapping in dyld cache for /usr/lib/libSystem.B.dylib
dyld[21147]: __TEXT (r.x) 0x00018E59D000->0x00018E59F000
dyld[21147]: __DATA_CONST (rw.) 0x0001D5DFDB98->0x0001D5DFDBA8
dyld[21147]: __AUTH_CONST (rw.) 0x0001DDE015A8->0x0001DDE01878
dyld[21147]: __AUTH (rw.) 0x0001D9688650->0x0001D9688658
dyld[21147]: __DATA (rw.) 0x0001D808AD60->0x0001D808AD68
dyld[21147]: __LINKEDIT (r..) 0x000239574000->0x000270BE4000
dyld[21147]: Using mapping in dyld cache for /usr/lib/system/libcache.dylib
dyld[21147]: __TEXT (r.x) 0x00018E597000->0x00018E59D000
dyld[21147]: __DATA_CONST (rw.) 0x0001D5DFDAF0->0x0001D5DFDB98
dyld[21147]: __AUTH_CONST (rw.) 0x0001DDE014D0->0x0001DDE015A8
dyld[21147]: __LINKEDIT (r..) 0x000239574000->0x000270BE4000
[...]
```
* **DYLD\_PRINT\_INITIALIZERS**
Drucken, wann jeder Bibliotheksinitialisierer ausgeführt wird:
```
DYLD_PRINT_INITIALIZERS=1 ./apple
dyld[21623]: running initializer 0x18e59e5c0 in /usr/lib/libSystem.B.dylib
[...]
```
### Andere
* `DYLD_BIND_AT_LAUNCH`: Lazy-Bindungen werden mit nicht-lazy Bindungen aufgelöst
* `DYLD_DISABLE_PREFETCH`: Deaktiviert das Vorabladen von \_\_DATA- und \_\_LINKEDIT-Inhalten
* `DYLD_FORCE_FLAT_NAMESPACE`: Bindungen auf einer Ebene
* `DYLD_[FRAMEWORK/LIBRARY]_PATH | DYLD_FALLBACK_[FRAMEWORK/LIBRARY]_PATH | DYLD_VERSIONED_[FRAMEWORK/LIBRARY]_PATH`: Auflösungspfade
* `DYLD_INSERT_LIBRARIES`: Laden einer bestimmten Bibliothek
* `DYLD_PRINT_TO_FILE`: Schreibt dyld-Debug in eine Datei
* `DYLD_PRINT_APIS`: Druckt libdyld-API-Aufrufe
* `DYLD_PRINT_APIS_APP`: Druckt libdyld-API-Aufrufe, die von main gemacht wurden
* `DYLD_PRINT_BINDINGS`: Druckt Symbole beim Binden
* `DYLD_WEAK_BINDINGS`: Druckt nur schwache Symbole beim Binden
* `DYLD_PRINT_CODE_SIGNATURES`: Druckt Registrierungsvorgänge für Codesignaturen
* `DYLD_PRINT_DOFS`: Druckt D-Trace-Objektformatabschnitte beim Laden
* `DYLD_PRINT_ENV`: Druckt von dyld gesehene Umgebungen
* `DYLD_PRINT_INTERPOSTING`: Druckt Interposting-Vorgänge
* `DYLD_PRINT_LIBRARIES`: Druckt geladene Bibliotheken
* `DYLD_PRINT_OPTS`: Druckt Ladeoptionen
* `DYLD_REBASING`: Druckt Symbol-Rebasierungsoperationen
* `DYLD_RPATHS`: Druckt Erweiterungen von @rpath
* `DYLD_PRINT_SEGMENTS`: Druckt Zuordnungen von Mach-O-Segmenten
* `DYLD_PRINT_STATISTICS`: Druckt Zeitstatistiken
* `DYLD_PRINT_STATISTICS_DETAILS`: Druckt detaillierte Zeitstatistiken
* `DYLD_PRINT_WARNINGS`: Druckt Warnmeldungen
* `DYLD_SHARED_CACHE_DIR`: Pfad zur Verwendung des gemeinsamen Bibliothekscaches
* `DYLD_SHARED_REGION`: "use", "private", "avoid"
* `DYLD_USE_CLOSURES`: Aktiviert Closures
Es ist möglich, mehr mit etwas wie zu finden:
```bash
strings /usr/lib/dyld | grep "^DYLD_" | sort -u
```
Oder laden Sie das dyld-Projekt von [https://opensource.apple.com/tarballs/dyld/dyld-852.2.tar.gz](https://opensource.apple.com/tarballs/dyld/dyld-852.2.tar.gz) herunter und führen Sie es im Ordner aus:
```bash
find . -type f | xargs grep strcmp| grep key,\ \" | cut -d'"' -f2 | sort -u
```
## Referenzen
* [**\*OS Internals, Band I: Benutzermodus. Von Jonathan Levin**](https://www.amazon.com/MacOS-iOS-Internals-User-Mode/dp/099105556X)
<details>
<summary><strong>Erlernen Sie AWS-Hacking von Null auf Held mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Andere Möglichkeiten, HackTricks zu unterstützen:
* Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen möchten** oder **HackTricks im PDF-Format herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com)
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repositorys einreichen.
</details>