IT Security #2

* Malware, die aus der Ferne steuerbar ist * Ausführung über festen Befehlssatz (Commands)

* Kollektiv gesteuerte Sammlung von Bots * Benötigt Kommunikationskanal für Command & Control (C2/C&C)

* A) Bots entfernen: Maschine (remote) säubern/wipen * B) Von C2 trennen: Empfang von Befehlen verhindern

* „Was der Bot weiß, weiß der Verteidiger" * Analyse offenbart C2, Protokoll, Killswitch

* + einfach, effizient, skalierbar * – Single Point of Failure

* Domain Generation Algorithm * Bot & Botmaster erzeugen mit gleichem Algorithmus dynamische Rendezvous-Punkte (Domains)

* + Blacklisting/Sinkholing aller Domains kaum möglich, mischt legit. Domains * – Monitoring/Honeypot möglich, auffällige Traffic-Muster

* Verteidiger könnten C2 übernehmen & „uninstall" senden * Gegenmaßnahme: Botmaster signiert C2-Nachrichten kryptographisch

* DNS A-Records der C2-Domain wechseln schnell * Optional: gutartige IPs einmischen zur Tarnung

* + resilienter (kein SPOF) * – mehr Koordination nötig

* Nutzen bestehendes P2P-Protokoll (z.B. Filesharing) * Bots per File-Advertisement identifiziert * Befehle per Datei-Suche gepusht/gepullt

* Schutz vor unbefugtem Zugriff/Nutzung/Offenlegung/Störung/Änderung/Zerstörung * Alt.: Ziel erreichen trotz Gegner

* Fehler/Schwäche/unbeabsichtigtes Verhalten, das Sicherheitsrichtlinie verletzbar macht

* Code/Daten/Befehlsfolge/Technik, die eine Schwachstelle ausnutzt

* Vector: Pfad/Mittel des Zugriffs für Exploit * Surface: Summe aller Vektoren/Schnittstellen/Eintrittspunkte

* Nur autorisierte Personen greifen auf Daten zu * Bedroht durch: Eavesdropping, Sniffing

* Daten nicht unbefugt verändert/manipuliert * Bedroht durch: Abfangen & Verändern von Nachrichten

* Quellidentität ist echt * Bedroht durch: Nachrichten unter falscher Identität senden

* Zuverlässiger, zeitnaher Zugriff für Autorisierte * Bedroht durch: Netz überlasten, Dienste crashen

* Least Privilege * Defense in Depth * Fail Secure * Compartmentalization * Separation of Duties * Keine Security-by-Obscurity (Kerckhoffs)

* Mehrere unabhängige Schutzschichten * Bei Ausfall einer bleiben andere * Erhöht Angriffskosten/-komplexität

* „Nichts vertrauen, alles explizit verifizieren" * Annahme: System bereits kompromittiert

* Spoofing * Tampering * Repudiation * Information Disclosure * Denial of Service * Elevation of Privilege * (von Microsoft)

* Tactics: Highlevel-Ziele (z.B. Initial Access) * Techniques: Methode (z.B. Supply-Chain) * Procedures: konkrete Umsetzung (z.B. Infostealer)

* Common Vulnerability Scoring System * Bewertet techn. Schwere, Score 0.0–10.0

* HW-/SW-System, das Zugriff zwischen zwei Netzen beschränkt * Teil des Verteidigungsperimeters

* Kann: Traffic filtern/loggen, Zugriff schützen, Compliance * Kann nicht: Insider-Bedrohungen abwehren, nach Payload filtern

* Filtert nach aktiven Verbindungen (Sessions) * + einfacher, weniger Regeln, sicherer, kleinere Tabellen * – ressourcenlastig, teuer

* Filtert pro Paket, kein State * Nutzt TCP/ACK-Flag für Flow * – komplex, viele Regeln, poröser * + leichtgewichtig, günstig

* Anwendungsspezifisch, protokollspezifisch, hält State * Deep Packet Inspection (Payload-Filter) * + sicherer * – CPU-intensiv, teuer

* Intrusion Detection System: passiver Beobachter * Nicht in-line, keine Latenz * Loggt & alarmiert bei Malicious Activity

* Intrusion Prevention System: aktiv in Echtzeit * In-line, blockt/dropt Verbindungen * Etwas Latenz

* High-Interaction: echtes OS, hohes Risiko, für Forschung * Low-Interaction: nur Basisdienste, leicht deploybar, für Produktion

* Demilitarized Zone: Subnetz schützt Intranet vor untrusted externem Netz * Barriere trusted ↔ untrusted

* Static: 1:1 fest * Dynamic: aus Pool zufällig * PAT: viele:1 über Ports * NAT64: IPv6-only ↔ IPv4-Internet

* Opfer besucht bösartige Website (JS), umgeht NAT * Voraussetzung: ALG (Application Layer Gateway) Proxy-FW

1. Aufruf: Das Opfer geht auf die präparierte Webseite (JavaScript startet).

2. Täuschung: Das Script sendet speziell strukturierte Netzwerk-Pakete an das Internet.

3. Fehlinterpretation: Das ALG des Routers liest diese Pakete mit und glaubt, es müsse einen Port freischalten.

4. Treffer: Der Router öffnet den eingehenden Port. Der Angreifer hat nun direkten Zugriff von außen auf ein Gerät im internen Netz.

* Sammlung von Präfixen, von einer Entität verwaltet * Jedes AS hat eindeutige ASN

* Border Gateway Protocol, Path-Vector-Protokoll * Läuft auf Routern, für Inter-AS-Routing * Routing um Präfixe, nicht IPs

* Longest Prefix Match > Shortest Path Route * Zuerst spezifischstes Präfix, dann kürzester Pfad

* Basiert auf Vertrauen, keine Sicherheit * Keine Integrität/Authentizität/Ownership-Prüfung/Freshness * Anfällig für Replay & Hijacking

* Beide: falsche Ziel-AS/AS_PATH * Hijack: absichtlich * Route Leak: versehentliche Fehlkonfiguration

* Angreifer announced längeres (spezifischeres) Präfix * Betrifft ALLE Netze im Internet (Longest Prefix Match)

* Angreifer announced identische Route * Betrifft Netze näher am Angreifer als am echten Ziel

* Resource Public Key Infrastructure * Bindet Präfixe kryptographisch an Owner-ASN * Schützt v.a. gegen Origin-Hijacks & Route Leaks

* Route Origin Authorization * Krypt. signiertes Objekt * Legt fest, welche ASN welches Netz besitzt (nur Origin)

* Route Origin Validation * Router nutzt RPKI-Daten zur Routen-Prüfung * Valid→Route, Invalid→No Route, Not Found→Route

* Draft gegen AS_PATH-Poisoning * Jeder Hop signiert, in BGPSEC_Path * Router validieren Signaturen in Echtzeit * Kombinierbar mit RPKI

* Domain Name System = „Telefonbuch" des Internets * Mappt Hostnamen ↔ IP-Adressen * Client-Server-Modell

* A: IPv4 * AAAA: IPv6 * CNAME: Alias * TXT: Textinfo * NS: Nameserver * MX: Mailserver * SOA: Zonen-Admininfo

* Rekursiv: Resolver fragt Root → .com NS → Domain NS → A-Record * Ergebnis wird gecached

* Off-Path: nicht auf Kommunikationspfad * Kann nur senden, nicht abhören/ändern/löschen * Kann Resolver-Cache vergiften

* Angreifer braucht korrekte TXID/Identification (16 Bit) zum Poisoning

* Source-Port zusätzlich randomisieren * Angreifer bräuchte dann Tbps

* Resolver akzeptiert nur RRs der angefragten Domain & ihrer Subdomains * „Bailiwick" = Zuständigkeitsbereich * Andere Domains = out-of-bailiwick

* Verdeckte Daten-Exfiltration via DNS * Möglich, weil UDP Port 53 immer offen * Daten (base64) als Subdomain kodiert

* Angreifer spooft Opfer-IP in Queries * Resolver-Antworten viel größer (bis 50x) → Ressourcenerschöpfung (DDoS) * Nutzt „ANY"-Query & DNSSEC

* Security Extension von DNS * Bietet: Authentizität, Integrität, Authenticated Denial of Existence (begrenzt)

* KSK (Key Signing Key): vom Parent/Trust Anchor authentifiziert * ZSK (Zone Signing Key): von KSK signiert, signiert die RRs

* „Schlimmste je gefundene DNS-Lücke" * Protokoll-Level DoS: Resolver muss alle krypt. Materialien durchprobieren * 1 Paket → 100% CPU

* 1 Wissen (Passwort, PIN) * 2 Besitz (Smartphone, Token) * 3 Inhärenz (Iris, Fingerabdruck) * (inoffiziell: 4 Ort/Geolocation)

* Angreifer nutzt geleakte User/PW-Kombis, loggt sich bei vielen Diensten ein (Botnets) * Funktioniert wg. PW-Wiederverwendung

* Riesige vorberechnete Lookup-Tabellen für Reverse-Lookup von Hashes * Nutzen Ketten aus Hash H() & Reduktion R()

* Klartext: Leak = alle Passwörter * Verschlüsselung: Key muss existieren/gespeichert * Hashing: deterministisch (Rainbow) * Gesalzen: korrekt

* Zufälliger Wert pro User * Verhindert, dass gleiches PW gleichen Hash ergibt (gegen Rainbow/Wörterbuch) * Gespeichert in DB

* Geheimer Wert, allen Passwörtern hinzugefügt * NICHT in DB, idealerweise im HSM * Shared über System

* Key Derivation Function: absichtlich langsame Hashfunktion * Input variabler Länge → feste Länge

* Unterstützt Passkeys, native via WebAuthn API * Phishing- & Replay-resistent (Challenge einzigartig) * Dienst-spezifische Key-Paare

* Multi-Factor Authentication: ≥2 Faktoren aus unabhängigen Kategorien * „Defense in Depth" * Schützt trotz PW-Diebstahl

* MFA Fatigue (Prompt-Bombing) * Social Engineering (OTP entlocken) * Interception (unsicheres SMS/E-Mail)

* Reverse Proxy zwischen Opfer & Ziel * Phishing-Seite proxied echten Login * Stiehlt Passwort UND umgeht MFA

* Bug in TLS-Heartbeat-Extension (OpenSSL) * Client deklariert falsche Länge, Server prüft nicht → leakt Speicher * Fehlende Boundary Checks (C)

* Nicht memory-/typsicher, anfällig für Memory-Corruption * Manuelles Speichermanagement (Leaks, Overflows, Segfaults)

* gets() liest bis Newline/EOF, ignoriert Buffergröße → Overflow * fgets() liest nur sizeof(buffer)-1 Zeichen

* Input > Buffergröße überschreibt Stackframe (inkl. Return Address) * Bricht Programmfluss

* Segfault (Crash) * Return Address → Shellcode = RCE (Shell spawnen) * Return Address → Maschinencode (auto-ausgeführt)

* ASLR (Adressen randomisieren) * Stack Canaries (Cookie vor Return prüfen) * Non-Executable Stack (Stack als Daten)

* Viele zufällige Inputs ans Programm, Verhalten beobachten * Ziel: Crashes / Abweichung vom Standard * + kein Source nötig, kaum False Positives * – nur Crashes, Setup

* Black-box: nur Spezifikation, externes Verhalten * White-box: Source + Coverage, Symbolic Execution, Taint * Grey-box: leicht, primär Coverage-Feedback

* Umfasst alle Tools/Dependencies (Code, Libs, Compiler, Repos) * Infektion einer Komponente infiziert alle Upstream-Nutzer

* Vendor-Policies (regelm. Audits fordern) * SCA (Software Composition Analysis) * SBOM (Software-Bill-of-Materials, teils gesetzlich)

* Open Worldwide Application Security Project * Liste der Top-10 (Web-)App-Schwachstellen, alle 4 Jahre

* Nutzer greifen ohne Berechtigung auf Funktionen/Daten zu * Häufigste Form: IDOR

* Insecure Direct Object Reference * App nutzt User-Input für direkten Objektzugriff * Folgen: horizontale/vertikale Eskalation, unbefugter DB-Zugriff

* Bösartiger User-Input in SQL-Queries eingefügt * Bei unsicherer Konfiguration werden Statements verändert

* Prepared Statements (beste Abwehr) * Trennen Daten von Query, feste Query mit Platzhaltern (?), gebundener Typ

* Cross-Site Request Forgery: zwingt eingeloggten User zu ungewollter Aktion * Browser hängt Session-Cookie automatisch an

* CSRF-Tokens (geheim, einzigartig, pro Session) * SameSite-Cookie (Lax/Strict/None) * Header/Origin-Validierung (Origin/Referer prüfen)

* Server-Side Request Forgery: Angreifer missbraucht Server-Funktion, um interne Ressourcen zu lesen/ändern

* Cross-Site Scripting: bösartige (JS-)Skripte in vertrauenswürdige Website injiziert * Stiehlt z.B. Cookies

* Output Encoding (Sonderzeichen als Text) * HTML-Sanitization (DOMPurify) * Safe Sinks (textContent, setAttribute, value)

* Domain-Owner löscht Cloud-Ressource, vergisst DNS-Record (dangling) * Angreifer erhält gleiche Cloud-IP/Hostname → übernimmt Subdomain

* Verdeckt eingeschleuste Programme * Zerstören Daten, führen destruktive Programme aus oder kompromittieren C/I/A

* Infizierte Hardware (USB) * Phishing (Anhänge/Links) * Unseriöse Software * Bösartige Websites (Drive-by Download) * Supply-Chain

* Ransomware: sperrt Ressourcen gegen Lösegeld * Fileless: nur im RAM * Virus: repliziert via User-Interaktion * Worm: selbst-replizierend über Netze

* Trojan: als legit. SW getarnt * Spyware: sammelt Infos verdeckt * Keylogger: zeichnet Tastatur auf * Rootkit: Kontrolle über Maschine * Adware: unerwünschte Werbung

* Portable Executable: Win-Standardformat * .exe (Apps), .dll (Libs), .sys (Treiber) * Portabel über alle Win-Systeme

* Misst Zufälligkeit in Datei/Sektion * High Entropy ↔ Obfuskation/Packing * Low <3, Moderat 3–7, High >7

* Verschlüsselung * Packing (z.B. UPX) * Dead Code * Superfluous Branches * Polymorphismus (ändert Aussehen pro Run) * generische Namen

* „Pattern-Matching Swiss Knife" für Malware * Identifiziert binäre & textbasierte Muster * Condition-basierte Regeln für IOCs

* Verhalten der Malware im Host beobachten (was statisch nicht sichtbar) * Braucht isolierte VM (REMnux) & Sandbox