ALAKEEL

Kryptographie für Pentester

Kryptographie ist für Pentester weniger ein mathematisches Thema als ein Fehler- und Missbrauchs-Thema. Die verwendeten Algorithmen sind fast immer sicher – die Implementierung ist es oft nicht.
Ziel eines Pentesters:
– Schwache Implementierung erkennen
– Falsche Konfigurationen angreifen
– Missbrauch testen (Keys, Nonces, Padding, RNG, Token usw.)

1. Symmetrische Kryptographie

Ein Schlüssel für alles. Derselbe geheime Key wird zum Verschlüsseln und Entschlüsseln benutzt (z. B. AES-256). Schnell, ideal für große Datenmengen (Festplatten, Datenbankfelder, Sessions).

  • Man unterscheidet:
    • Blockchiffren: arbeiten in Blöcken (z. B. AES mit 128 Bit Blockgröße)
    • Stromchiffren: generieren einen Schlüsselstrom (z. B. ChaCha20, früher RC4)
  • AES (insb. AES-GCM & AES-CTR) -> Standard und Sicher. Die Schwächen liegen fast immer in:
    • Wahl des Modus – Betriebsmodi (ECB, CBC, CTR, GCM)
    • Umgang mit IV/Nonce
    • Fehlen von Integritätsschutz
  • Betriebsmodi (ECB, CBC, CTR, GCM)
    • ECB (Electronic Codebook)
      • NIE verwenden.
      • Gleiche Klartextblöcke → gleiche Ciphertexte. Muster in Bildern und Daten.
      • Befund: In Code/Config taucht ECB auf → direkt Finding.
    • CBC (Cipher Block Chaining)
      • Jeder Block hängt vom vorherigen ab.
      • Braucht zufälligen IV pro Nachricht.
      • Typische Schwachstelle: Padding Oracles (wenn Fehler unterschiedlich „laut“ sind).
    • CTR (Counter Mode)
      • Blockchiffre wird zu einem Stream (wie XOR mit Key-Stream).
      • Sehr kritisch: Nonce/IV muss einzigartig pro Key sein.
        Nonce-Reuse → Angreifer kann XOR von Klartexten berechnen.
    • GCM (Galois/Counter Mode) = CTR + MAC
      • AEAD-Modus: Vertraulichkeit + Integrität.
      • Auch hier: Nonce-Reuse = Katastrophe, kann komplette Sicherheit brechen.
  • IV/Nonce-Handling
    • Gute Umsetzung:
      • IV/Nonce pro Verschlüsselung neu generiert (kryptographisch zufällig oder sicherer Zähler).
      • IV/Nonce wird mitgespeichert oder mitgesendet, ist nicht geheim.
      • Länge passend zum Modus (z. B. 96 Bit für GCM).
    • Typische Fehler:
      • Fester IV (z. B. 000000... oder hart codiert).
      • IV = Hash vom Passwort oder etwas Deterministisches.
      • IV bei GCM/CTR einfach von 0 hochzählen und beim Neustart reset → Nonce-Reuse.
  • MAC/HMAC & Authenticated Encryption (AEAD)
    • Symmetrische Verschlüsselung allein schützt nicht vor Manipulation.
    • Ein MAC stellt sicher:
      • Die Nachricht kommt von jemandem, der den geheimen Schlüssel kennt.
      • Die Nachricht wurde nicht verändert.
    • Beispiel: HMAC-SHA256
      • HMAC(K, message)
      • K ist geheim, message ist der Datenstrom.
    • AEAD (Authenticated Encryption with Associated Data). AEAD liefert:
      • Vertraulichkeit (Verschlüsselung der Nutzdaten),
      • Integrität und Authentizität (MAC integriert),
      • optional zusätzliche „Associated Data“ (z. B. Header), die nicht verschlüsselt, aber mitauthentifiziert wird.
    • Beispiele:
      • AES-GCM
      • ChaCha20-Poly1305
  • Pentest-Fehlerbilder
    • Nur Encryption ohne MAC/AEAD:
      • Ein Angreifer kann Ciphertext manipulieren und so kontrollierte Änderungen im Klartext erzeugen (Bitflipping, Padding-Angriffe).
    • Falsches Selbstbau-Konstrukt:
      • „Wir verschlüsseln und fügen dann irgendwie Hash an, aber vergleichen ihn unsicher (Timing, Truncation).“
    • MAC-Schlüssel hartkodiert im Code oder in Configs im Klartext.
    • Siehst du nur AES/CBC/PKCS5Padding ohne HMAC → Verdacht auf fehlenden Integritätsschutz.
    • Siehst du AES-GCM, aber im Code:
      • fester Nonce
      • oder Nonce aus Zeit + PID
      • -> Finding: Nonce-Reuse / unsichere Nonce-Generierung.
2. Asymmetrische Kryptographie
  • Es gibt ein Schlüsselpaar:
    • Public Key: darf jeder kennen.
    • Private Key: geheim.
  • Anwendungsfälle:
    • Verschlüsselung (Public Key encrypt -> Private Key decrypt)
      • Mit dem öffentlichen Schlüssel verschlüsseln, nur der Besitzer des privaten Schlüssels kann entschlüsseln.
    • Signaturen (Private Key sign ->ff Public Key verify)
      • Mit dem privaten Schlüssel signieren, jeder mit dem öffentlichen Schlüssel kann prüfen, ob die Signatur gültig ist.
    • Key Exchange (z. B. in TLS)
  • RSA (Verschlüsselung & Signaturen)
    • Problematisch wird es bei Padding:
      • PKCS#1 v1.5: alt, in Kombination mit schlechtem Error-Handling → Bleichenbacher-Angriffe.
      • OAEP: moderner für Verschlüsselung.
      • PSS: moderner für Signaturen.
    • Pentest-Perspektive:
      • Prüfe: Verwendet die App RSA mit PKCS#1 v1.5 für Encryption?
      • Protokolle: alte Protokolle oder Libraries → Bleichenbacher-Angriff evtl. denkbar.
  • ECC / ECDSA / Diffie-Hellman (DH, ECDH)
    • ECC = gleiche Sicherheit mit kleineren Schlüsseln.
    • ECDH: für Schlüsseltausch (TLS, SSH).
    • ECDSA/EdDSA: Signaturen (z. B. Ed25519).
    • Typische Befunde eher:
      • Falsche Implementierungen (z. B. Nonce-Reuse bei ECDSA).
  • Typische Pentest-Baustellen
    • Zu kurze Schlüssellängen (RSA 1024 Bit oder kleiner).
    • Verwendung veralteter Algorithmen (z. B. DSA mit schlechten Parametern).
    • Schlechte Key-Protection:
      • Private Keys im Repo, in der Webroot, in Config-Files im Klartext.
    • Fehlkonfiguriertes Certificate Management / PKI (falsche Vertrauensketten, selbstsigniert ohne Grund, etc.).
3. Hashfunktionen
  • SHA-2 / SHA-3
  • BLAKE2/BLAKE3
  • Unsichere Hashes: MD5, SHA-1
  • Kollisionen, Präbilder, Integrität
    • Integriätsschutz mit nur Hash. Beispiel: Download-Seite zeigt MD5(file).
      • Ein Angreifer, der Datei und Hash kontrolliert, kann beides austauschen -> Schutz sinnlos.
  • Pentest-Fehlerbilder
    • Passwörter mit MD5/SHA-1 (ggf. sogar ohne Salt).
    • Hash als Ersatz für MAC („Wir hängen einfach einen geheimen String dran und hashen“ – kann, wenn korrekt als HMAC implementiert, okay sein, aber DIY oft fehlerhaft).
    • Kein Salt bei Passwörtern → Rainbow-Table-Angriffe deutlich einfacher.
4. Passwort-Hashing & Cracking
  • Key Derivation Function (KDF) erzeugt aus einem oder mehreren Inputs (z. B. Master-Key, Salt) neue Schlüssel. Beispiel: HKDF, PBKDF2, scrypt, Argon2.
  • bcrypt, PBKDF2, scrypt, Argon2 -> mit Salt.
  • Salt = zufälliger Wert pro Passwort (verhindert Rainbow-Tables + gleiche Passwörter in DB unterschiedlich), Pepper (zusätzliche geheime Konstante (z. B. in App-Konfiguration oder HSM/KMS), nicht in der DB gespeichert)
  • Offline-Cracking (hashcat, JtR)
  • Hash-Misuse in Apps
    • Passwort-Hash ist MD5/SHA-1/sha256 ohne Salt -> kritischer Befund.
    • PBKDF2, aber nur 1000 Iterationen → veraltet. Nur einmaliger Hash ohne Iterationen (zu schnell → brute-force freundlich).
    • Client-side Hashing („wir schicken SHA-1(Passwort) übers Netz, ist sicherer“) -> nicht.
  • Als Pentester prüfst du (soweit möglich):
    • Welche Hash-Algorithmen?
    • Salt vorhanden?
    • Iterationszahl/Konfiguration (aus Code / Config / SAST)?
5. Digitale Signaturen & PKI

Digitale Signaturen sind der Baustein für „Diese Nachricht kommt wirklich von X.“

Ablauf grob:

  1. Sender bildet Hash der Nachricht.
  2. Signiert den Hash mit seinem privaten Schlüssel.
  3. Empfänger:
    • Hash der Nachricht selbst berechnen.
    • Signatur mit öffentlichem Schlüssel prüfen.
    • Stimmen beide überein → Integrität + Authentizität.

Beispiele:

  • TLS-Zertifikate, Code-Signing, Dokumentensignatur,
  • JWT mit RS/ES-Algorithmen (z. B. RS256, ES256).
  • RSA-PSS, ECDSA, EdDSA
    • RSA-PSS: moderner und sicherer Signaturmodus für RSA.
    • ECDSA/EdDSA: modernere Signaturen mit ECC.
  • X.509-Zertifikate
  • TLS-Zertifikatsvalidierung (z.B. Selbstsigniert? Abgelaufen? Falscher Hostname?)
  • Certificate Pinning (Web/Mobile)
6. TLS/SSL & SSH Kryptographie
  • TLS 1.2/1.3 Handshake
  • Cipher Suites
  • Perfect Forward Secrecy
  • SSH Key Exchange, Ciphers, MACs
  • Häufige Fehlkonfigurationen
7. Krypto-Misuse in Anwendungen
  • Hardcoded Keys (z.B. In Code, Konfigs, Mobile Apps)
  • Falsche Modi (z. B. ECB)
    • AES-ECB in Code:
      • Cipher.getInstance("AES/ECB/PKCS5Padding")
      • static IV bei CBC: new IvParameterSpec(new byte[16]);
  • Unsichere Randomness Für Tokens, Nonces, Session-IDs, CSRF-Tokens
    • möglich: Vorhersehbarkeit, Session Hijacking.
  • Nonce/IV Reuse
  • Custom Crypto
  • Fehlimplementierte JWT/Cookies
8. Krypto-Angriffe (praktisch für Pentester)
  • Padding Oracle Attacks
  • Bleichenbacher RSA
  • Replay & Downgrade Attacks
  • Weak Key/Short Key Attacks
  • Timing Attacks (High-Level)
  • JWT None-Exploit, Algorithm Switch
9. Token, API-Auth & Web-Kryptographie
  • JWT (HS256/RS256, kid-Parameter, JWK)
  • OAuth2/OIDC Signaturen
  • HMAC-gesicherte API-Requests
  • Signed Cookies
  • CSRF-Tokens (kryptographisch)
10. Cryptographic Storage in Apps
  • Secure Storage vs. Plaintext
  • Mobile App KeyStore/KeyChain
  • Datenbanken: TDE, Application-Level-Encryption
  • Secret Management (Vault, KMS)
11. Key Management & Lifecycle
  • Lebenszyklus eines Schlüssels
    • Generierung (genug Entropie? richtige Länge?)
    • Speicherung (HSM, KMS, Vault, verschlüsselte Config?)
    • Verteilung (wie kommt der Key zu den Systemen?)
    • Rotation (regelmäßiger Austausch)
    • Vernichtung (Key-Wipe bei Abschaltung/Leak)
  • Klassische Fehler (Befunde)
    • Keys in Git (z. B. .pem im Repo).
    • Keys in Logs.
    • Ein Key wird „für alles“ verwendet (JWT, API HMAC, DB Verschlüsselung).
    • Keine Rotation – Key seit 10 Jahren im Einsatz.
    • Nach Incident (z. B. GitHub-Leak) werden Keys nicht neu generiert.
12. Post-Quanten Kryptographie (nur Überblick)
  • Kyber (KEM)
  • Dilithium (Signatur)
  • Relevanz für TLS/SSH
  • Hybrid-Kex

In

, , , , , , , , , ,