Wie Hacker denken: Hier – Filterumgehung.

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.

• %20 steht für ein Leerzeichen (URL-kodiert).
• /etc/passwd ist 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:

• echo wird auf ungewöhnliche Weise geschrieben: e\c\h\o → Das ist immer noch „echo“, aber mit Backslashes, die viele Filter nicht erkennen.
• $IFS ist 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 in cat /etc/passwd aufgelöst.
• | /???/\b**\h ist 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: $IFS statt Leerzeichen
• Backslashes oder alternative Schreibweisen: e\c\h\o statt echo
• 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!