Dieses Meme zeigt auf humorvolle Weise ein häufiges Thema im Bereich Web-Security und Bug Bounty Hunting – nämlich, wie Angreifer versuchen, Web Application Firewalls (WAFs) oder andere Sicherheitssysteme zu umgehen, um trotzdem an sensible Daten zu kommen. Hier ist die Erklärung Schritt für Schritt – auf „Halbexperten“-Niveau:
🐻❄️ 1. Oben: Der „einfache“ Angriff – und warum er blockiert wird
Im oberen Bild versucht jemand über eine URL-Parameter-Eingabe:
/submit?param=cat%20/etc/passwd
👉 Das bedeutet: Die Anwendung soll den Linux-Befehl cat /etc/passwd ausführen – eine klassische Technik, um an das Passwortverzeichnis eines Systems zu kommen.
%20steht für ein Leerzeichen (URL-kodiert)./etc/passwdist eine bekannte Systemdatei auf Unix-/Linux-Systemen, die Benutzernamen und Shell-Zugänge enthält.
✅ Ergebnis:
Die Firewall erkennt diesen Angriff sofort – es ist ein klarer, bekannter Pattern einer „Command Injection“. Deshalb kommt nur:
Access Denied
🧠 2. Unten: Der „clevere“ Angriff – mit Evasion-Techniken
Im unteren Bild ist derselbe Angriff verschleiert (obfuskierter):
/submit?param=e\c\h\o$IFS- e$IFS'\x63\x61\x74\x20\x2F\x65\x74\x63\x2F\x70\x61\x73\x73\x77\x64' | /???/\b**\h
🔍 Was hier passiert, ist komplexer, aber mit ein wenig Hintergrundwissen verständlich:
echowird auf ungewöhnliche Weise geschrieben:e\c\h\o→ Das ist immer noch „echo“, aber mit Backslashes, die viele Filter nicht erkennen.$IFSist eine Shell-Variable für „Internal Field Separator“ (normalerweise ein Leerzeichen). Wird oft genutzt, um Leerzeichen zu umgehen, da viele WAFs auf" "filtern.'\x63\x61\x74\x20...'ist eine Hex-Darstellung von ASCII-Zeichen. Sie wird zur Laufzeit incat /etc/passwdaufgelöst.| /???/\b**\hist ein Junk-Befehl, der WAFs durcheinanderbringen kann, weil er wie ein Teil einer Pipe aussieht. Viele Firewalls können nicht korrekt parsen, ob der Payload gefährlich ist.
✅ Ergebnis:
Die WAF erkennt die Befehle nicht mehr zuverlässig und lässt die Anfrage durch. Ergebnis: Die Datei /etc/passwd wird tatsächlich ausgegeben.
🧩 Warum das funktioniert
WAFs und Sicherheitssysteme arbeiten oft mit Signaturen – also Mustern bekannter Angriffe.
👉 Wenn man diese Muster verändert, ohne die Funktion zu verändern, kann man die Erkennung austricksen. Typische Techniken sind:
- Encoding: Befehle in Hex oder Unicode schreiben
- Variablenersatz:
$IFSstatt Leerzeichen - Backslashes oder alternative Schreibweisen:
e\c\h\ostattecho - Rauschen einfügen: scheinbar sinnlose Zeichen oder Pipes
- Kombination mehrerer Methoden
⚠️ Sicherheitshinweis
Das Ganze ist ein klassisches Beispiel aus dem Bereich Command Injection oder WAF-Evasion.
✅ Für Sicherheitsforscher (Bug Bounty Hunter) ist es wichtig, solche Techniken zu verstehen, um Schwachstellen zu entdecken und zu melden.
❌ Für Angreifer ist es ein Mittel, Systeme auszunutzen – was illegal ist, wenn man keine ausdrückliche Erlaubnis hat.
💡 Merke:
Ein „dummer“ Angriff wird geblockt. Ein „intelligenter“, gut verschleierter Angriff kann durchkommen – wenn die WAF nicht ausreichend intelligent oder aktuell ist.
Hier kommt eine praxisnahe Übersicht der Top 10 WAF-Evasion-Techniken, wie sie Bug-Bounty-Jäger, Pen-Tester und Security-Auditoren kennen sollten.
Ich erkläre sie bewusst didaktisch und legal – also nicht zum Nachmachen auf fremden Systemen, sondern damit man erkennt, wie Angreifer vorgehen könnten und wie man sich dagegen schützt.
🔟 Top 10 WAF-Evasion-Techniken (für Schulungs- und Audit-Zwecke)
1. 🧬 URL-Encoding & Double-Encoding
➡️ Idee: Zeichen wie Leerzeichen (%20) oder Schrägstriche (%2F) werden kodiert, um Filter zu umgehen.
Beispiel:
/submit?param=cat%20/etc/passwd
oder doppelt kodiert:
/submit?param=cat%2520/etc/passwd
✅ Gegenmaßnahme: Eingaben mehrfach decodieren, bevor sie geprüft werden.
2. 🧪 Hex- oder Unicode-Encoding
➡️ Angreifer kodieren Schlüsselwörter wie cat oder /etc/passwd in Hex oder Unicode, um Signaturen zu verschleiern.
Beispiel:
\x63\x61\x74 /etc/passwd
✅ Gegenmaßnahme: Eingaben normalisieren, bevor sie analysiert werden.
3. 🔁 Variable Injection (z. B. $IFS)
➡️ $IFS steht in Bash für das „Internal Field Separator“ (normalerweise ein Leerzeichen). Wird es verwendet, erkennen viele WAFs das Kommando nicht mehr.
Beispiel:
cat$IFS/etc/passwd
✅ Gegenmaßnahme: Shell-Metazeichen wie $ oder IFS blockieren oder escapen.
4. 📜 Backslash- oder Tab-Obfuscation
➡️ Backslashes oder Tabulatoren zwischen Buchstaben stören String-Erkennung, der Befehl funktioniert aber trotzdem.
Beispiel:
c\a\t /etc/passwd
✅ Gegenmaßnahme: Eingaben aufgelöst („canonicalisiert“) prüfen.
5. 🧩 Ketten mit Pipes oder Semikolons
➡️ Angreifer hängen Befehle an scheinbar harmlose Eingaben an, z. B. mit |, ;, &&.
Beispiel:
echo hello;cat /etc/passwd
✅ Gegenmaßnahme: Shell-Metazeichen blockieren oder Kontext-Escaping erzwingen.
6. 🪄 Kommentar-Injection / Dummy-Code
➡️ Kommentare oder „Rauschen“ einfügen, um Erkennung zu stören.
Beispiel:
ca#anything#t /etc/passwd
✅ Gegenmaßnahme: Kommentare vor Analyse entfernen oder erkennen.
7. 🧠 Case-Obfuscation / Keyword-Splitting
➡️ Groß-/Kleinschreibung oder Aufsplittung wird genutzt, um Signaturen zu umgehen.
Beispiel:
CaT /EtC/PaSsWd
✅ Gegenmaßnahme: Eingaben case-insensitive prüfen.
8. 🛠️ Alternative Shell-Aufrufe oder Pseudo-Kommandos
➡️ Statt cat z. B. head, more, awk, sed usw. nutzen – oft mit gleichem Ergebnis.
Beispiel:
awk 'BEGIN{system("cat /etc/passwd")}'
✅ Gegenmaßnahme: Zulässige Kommandos whitelisten statt nur „gefährliche“ blockieren.
9. 🔀 Encodierte Pipes & verschachtelte Befehle
➡️ Pipes (|) oder Umleitungen (>, <) verschachteln, um Signaturen zu zerstören.
Beispiel:
echo d2hvYW1p | base64 -d | sh
✅ Gegenmaßnahme: Shell-Aufrufe isolieren oder unterbinden.
10. 🧰 Kombination mehrerer Techniken (Multi-Layer-Evasion)
➡️ Profis kombinieren mehrere der obigen Methoden, z. B. Encoding + Variablen + Backslashes.
Beispiel:
e\c\h\o$IFS- e$IFS'\x63\x61\x74\x20\x2F\x65\x74\x63\x2F\x70\x61\x73\x73\x77\x64'
✅ Gegenmaßnahme: Tiefgehende Input-Validierung + Runtime-Security (z. B. eBPF-basierte Überwachung).
🧠 Fazit
🔐 Für Sicherheitsteams:
- Filter sind nur so gut wie ihre Normalisierung und Kontextanalyse.
- Kombinierte Prüfmechanismen (Signatur + Verhalten + Sandbox) sind deutlich robuster als reine Regex-WAFs.
- Prinzip „Deny by default“: Nur erlaubte Eingaben zulassen („Whitelist“), nicht versuchen, alle bösen Varianten zu erraten.
💡 Merke: Gute Angreifer denken nicht in „Kommando + Blockliste“, sondern in „wie kann ich dieselbe Semantik auf 100 Arten ausdrücken?“. Je besser du diese Denkweise verstehst, desto besser kannst du Systeme absichern.
Mehr hier:
-> Chefsache Cybersecurity <- Jetzt auf Amazon!
