Kapitel 3: technische Schwachstellen & Angriffe

-       Vertraulichkeit (unberechtigter Zugriff auf Daten) und/oder

-       Integrität (Modifikation von Daten) und/oder

-       Verfügbarkeit (Löschen von Daten, Stören von Diensten)

-       Ziel des Angriffs: C, I und/oder A?

-       Aktiv oder passiv (z.B. remote exploit vs. sniffing)

-       Direkt oder indirekt (z.B. Manipulation einer Datenbank betrifft WebApp)

-       Ein- oder mehrstufig (z.B. kompromittierter Webserver als Sprungbrett)

Ansatz: Angreifer versucht Zielsystem/Netz für berechtigte Anwender nutzbar zu machen, durch:

-       Überlastung

-       Herbeiführen von Fehlersituationen

-       Ausnutzen von Programmierfehlern

Beispiel: Überlasten eines Web-Servers durch massive Anfragen

-       Angreifer sendet Strom von ping Paketen (ICMP) mit gefälschter Absender-Adresse (alice.victim.com) (Adressfälschung wird auch als IP-Spoofing bezeichnet) an IP- Broadcast Adresse von stooge.com

-       Alle Rechner aus dem Netz von stooge.com antworten an alice.victim.com (Amplification attack)

Mögliche Gegenmaßnahmen:

Entweder: Überkompensation -> teuer

Besser: Server so konfigurieren, dass sie nicht auf Broadcastpings antworten, oder von außen gerichtete Boradcast Nachrichten nicht weiterleiten

Grundprinzip: sehr kleines UDP-Paket zur Abfrage des DNS Servers mit gefälschter Absenderadresse, bei dem die Antwort sehr groß werden kann

Hier Verstärkungsfaktor bis 50 möglich

Gegenmaßnahmen:

-       Keine rekursiven Anfragen von außen beantworten

-       Schwellenwerte für identische anfragen vom selben client

SYN-flooding:

Grundprinzip: Halboffene TCP-Verbindungen so lange aufbauen, bis Ressourcen von Bob erschöpft  -> Bob kann dann keine weiteren Verbindungen mehr aufbauen

Gegenmaßnahmen:

-       Timer definieren, der offenen Verbindungen nach Timeout beendet

-       Falls alle Ressourcen belegt: zufällig eine halboffene Verbindung schließen

-       Maximale Anzahl halboffener Verbindungen pro Quell-Adresse festlegen

-       Best: SYN-Cookies: Seq.Nr von Bob kodiert die relevante Adressinfo von Mallet, Ressourcen werden erst bei stehender Verbindung allokiert und Adressdaten aus wieder aus Seq.Nr „herausgerechnet“

1. Intruder findet Maschine(n), die kompromittiert werden können; Hacking-Werkzeuge, Scanner, Rootkits, DoS/DDoS-Tools werden installiert; -> Maschine wird Master

1. Master versucht automatisiert, weitere Maschinen zu kompromittieren, um DDoS- Software (Daemon) zu installieren, bzw. schiebt anderen Nutzern Malware unter.

1. Intruder startet Programm auf Master, das allen Daemonen mitteilt, wann und gegen wen der Angriff zu starten ist.-> Zum vereinbartem Zeitpunkt startet jeder Daemon DoS-Angriff

Gegenmaßnahmen:

Pauschaler Schutz praktisch unmöglich aber:

-       Softwareupdates machen und Konfigurationsanpassungen

-       Schutz gegen Brute-Force-(D)DoS-Angriffe

-       Firewall-Regeln, ggf. basierend auf Deep-Packet-Inspection

-       Aussperren von Angreifern möglichst schon beim Uplink

-       Zusammenarbeit mit den Internet-Providern der Angriffsquellen

Definition:

-       Befehlsfolge; benötigt Wirtsprogramm zur Ausführung

-       Kein selbstständig ablauffähiges Programm

-       Selbstreplikation (Infektion weiterer Wirte (Programme))

Aufbau:

Infektion:

Definition:

-       Eigenständig lauffähiges Programm - benötigt keinen Wirt!

-       Selbstreplikation (z.B. über Netz oder USB-Sticks (mit „Autorun“))

-       Einzelne infizierte Maschinen werden als Wurm-Segmente bezeichnet

Definition:

Ein Programm, dessen Ist-Funktionalität nicht mit der angegebenen Soll-Funktionalität übereinstimmt:

-       Sinnvolle oder attraktive „Nutzfunktionalität“

-       Versteckte (Schad-) Funktionalität

-       Keine selbständige Vervielfältigung

Gegenmaßnahmen:

Auf allen Systemen (Desktop + Server):

-       Anti-Viren-Software installieren und aktuell halten

-       Keine Software zweifelhafter Herkunft installieren

-       Getrennt gelagerte, regelmäßig erstellte Daten-Backups

Auf Desktop-Systemen:

-       Funktionen wie automatische Makro-Ausführung, Autorun etc. deaktivieren

-       Ggf. virtuelle Maschinen zum „Surfen“ und Ausprobieren von Software verwenden (Isolation, Sandboxing)

(Primär) auf Server-Systemen:

-       Integrity-Checker einsetzen (→ Host Intrusion Detection Systeme)

-       Schreibrechte sehr restriktiv vergeben (Need-to-know-Prinzip)

Erkennung durch Whitelist bzw. Blacklist:

-       Nicht mehr zielführend, da Ransomware-Angriffe zunehmend „intelligenter“ werden. Schadcodes ändern nicht mehr die Dateiendungen in Werte wie .crypto oder .locky.

-       Funktioniert nicht im universitären Umfeld. Sehr viele Dateiendungen vorhanden, die in Blacklist stehen.

-       Automatischer Update der Listen führen zu vielen „false positive“ Meldungen.

Erkennung durch Behaviour Analyzer:

-       Überwacht Verhaltensmuster der Benutzer in Bezug auf alle Zugriffe.

-       Jede Transaktion wird in Echtzeit analysiert, ohne merkbare Performanceeinbußen.

-       Bei einer Anomalie wird Alarm ausgelöst und blockiert den Angreifer, um eine weitere Ausbreitung zu verhindern.

-       Der geblockte User hat keinen Zugriff mehr.

-       Alle anderen User arbeiten ohne jegliche Unterbrechung weiter.

-       Es ist Fine-Tuning des Algorithmus notwendig um nicht zu viele „false positive“ Meldungen zu haben.

CryptoSpike liefert dem Administrator alle relevanten Informationen

-       User und Rechner

-       Pfad und Anzahl der betroffenen Dateien

-       Administrator kann Transaktionen analysieren

-       Die SW unterstützt mittels Integration in Snapshots den single file restore

-       Nur die betroffenen/manipulierten Dateien werden wiederhergestellt

Speicherbereiche begrenzen

-       Je kleiner, desto weniger wird verschlüsselt

-       Backup/Restore hängt von Größe ab

Organisationsstruktur setzen Grenzen

-       Personal Storage

-       Institutional Storage

o   Fakultäten

o   Lehrstühle

o   weitere Projekte

Zugriffsrechte

-       Je enger, desto besser!

Snapshots (Read-Only)

-       Können nicht verschlüsselt werden

Software zum Schutz gegen Ransomware

-       Erkennt und unterbindet Verschlüsselung

Funktionsweise: gefälschte Email mit Link auf gefälschte Website: hier wird Dateneingabe gefordert

Gegenmaßnahmen:

Spamfilter = Software, die eingehende Mails nach Spam durchsucht

Arten von Spam-Filtern:

1.     Blacklist / Whitelist Ansatz: Aussperren von Mail-Servern und Mail-Domänen, die üblicherweise von Spammer benutzt werden.

2.     Regelbasiert: Nachricht wird inhaltlich nach Spam-Merkmalen durchsucht; sowohl im Header als auch im Body der Mail.

3.     Filtersoftware lernt aus Beispielen: Neuronale Netze oder Bayes-Filter bewerten Mailinhalte.

Vor- u. Nachteile dieser Spam-Filter:

1.     Effizient zu implementieren; aber grobgranular, keine inhaltliche Prüfung.

2.     Sehr hohe Erkennungsraten; aber E-Mail muss vollständig entgegen genommen werden, kontinuierlicher Aufwand für Konfigurationspflege.

3.     Gut in Mail-Clients zu integrieren; aber Erkennungsrate abhängig von Training (NN) bzw. Modellierung (Bayes).

Policy für Spambehandlung:

-       Spam-Mail löschen und Empfänger ggf. benachrichtigen

-       Spam-Mail markieren und dann ausliefern

-       Welche Variante bevorzugen (unter Beachtung der Fehlerarten)?

GreyListing:

Ziel: Ausführen von Code auf fremden Rechnern unter fremden Rechten

Vorgehen:

-       Auswahl des Ziels:

o   Lokal: Programm, das z.B. mit SUID (Set User ID)-Bit, d.h. mit Rechten des Eigentümers (meist root), läuft.

o   Remote: Netzdienst, z.B. Samba- Fileserver

-       Überschreiben interner Programmpuffer, z.B. durch überlange Eingabe

-       Dabei Manipulation z.B. der Rücksprungadresse, dadurch Ausführen von bestimmter Programmsequenz des Angreifers; z.B. Code zum Starten einer Shell

Hürden beim Stack-Smashing:

-       Rücksprungadresse ist absolut (nicht relativ) anzugeben. Lösung: NOPs vor eigentlichem Schadcode

-       Das Stacksegment bietet nur wenig Platz für eingschleusten Code Lösung: Shellcode kompakt in Assembler programmieren, dynamisches Nachladen

Shellcode:

Ziele:

-       Nachbildung des Funktionsaufrufs system(“/bin/sh“);

-       Shellcode darf keine Nullbytes (0x00) enthalten, damit u.a. strcpy nicht abbricht.

Schutz/Gegenmaßnahmen:

-       Sicheres Programmieren, z.b. strncpy statt strcpy

-       Stack-Guarding: Beim Aufruf einer Unterfunktion wird hinter der Rücksprungadresse ein Kontrollzeichen („Canary“) abgelegt. Vor dem Rücksprung wird geprüft, ob das Kontrollzeichen noch intakt ist. Variante: Mehrere Kopien der Rücksprungadresse.

-       Nicht ausführbarer Stack: Code auf dem Stack wird vom Betriebssystem generell nicht ausgeführt, damit auch kein eingeschleuster Shellcode. -> Schützt jedoch nicht vor Shellcode auf dem Heap

-       Adress space layout randomization: Speicherbereiche u.a. für Stack werden zufällig gewählt. Angreifer hat es schwerer, die richtige Rücksprungadresse anzugeben.

Weitere Aspekte:

-       Heap Corruption: Überschreiben von programminternen Datenstrukturen mit vom Angreifer vorgegebenen Werten

-       Int Überlauf

-       Schleifen mit Abbruchkriterien, die vom Angreifer nicht erfüllt werden

-       Multi-byte character encodings (Unicode)

Varianten:

-       Brute-Force Angriff

-       Dictionary Attack (Wörterbuchangriff)

-       Brechen des Hash-/Verschlüsselungsalgorithmus für das Passwort

-       Social Engineering

UNIX-Authentifikation: User/Password

1.     Benutzer wählt Passwort Passwort wird mit sich selbst als Schlüssel verschlüsselt und verschlüsselt gespeichert in /etc/passwd: Auch root kennt Passwort nicht Authentisierung:

2.     Eingegebenes Passwort wird mit sich selbst verschlüsselt und mit dem in /etc/passwd verglichen.

3.     Verschlüsselungsalgorithmus crypt(pwd,salt)bekannt

Angriff: Dictonary Attack

-       Angreifer verschlüsselt Wörter aus Wörterbuch und vergleicht Ergebnisse mit Einträgen in /etc/passwd

-       Verhinderung: zus. Parameter salt in crypt:

12 Bit Zahl: 0 <= salt < 4096 Bei Initialisierung zufällig gewählt Die ersten 2 Zeichen im Passwort String sind salt

Ziel: Angreifer will dauerhaften Zugang (Hintereingang) zu einer bereits kompromittierten Maschine

-       An der Betriebssystem-Authentisierung vorbei

-       Detektion durch Integritäts-Checks:

Mechanismen:

-       „Verstecktes“ eigenes SUID-root Programm mit „shellcode“.

-       SUID-root Systemprogramm durch eigene Version mit versteckter Funktionalität austauschen.

-       Installation eines “versteckten” Netzdienstes, der zu bestimmten Zeiten einen Netz-Port öffnet und auf Kommandos wartet.

Detektion durch Integritäts-checks:

-       Kryptographische Prüfsumme aller Programme, aller Konfigurationsdateinen, regelmäßige Überprüfung

-       Überprüfung der offenen Ports

-       Suche nach unewöhlichen SUID/SGID-Programmen

Reaktion bei erkannten Hintertüren:

-       Vollständiges Entfernen der Schadsoftware nicht immer möglich

-       Ggf. Maschine neu oder aus sauberem Backup aufsetzen

-       Verwundbarkeit muss behoben werden

Ursprünglich Bezeichnung für zueinander komplementäre UNIX-Systemprogramme mit eingebauten Backdoors (1. Generation Rootkits)

Typischer Ablauf:

-       Angreifer komprimitiert Maschine und erlangt Root-Berechtigungen

-       Angreifer installiert Rootkit

o   Werkzeuge aus dem Rootkit bereinigen Spuren u.a. in Logfiles

o   Backdoors ermöglichen kontinuierlichen root-Zugang

-       Rootkits der 1. Generation bestehen aus eigenen Varianten von Kommandos und Programmen

Rootkits 2. Generation:

-       Motivation: Alle Systemprogramme einzeln auszutauschen ist aus Angreifersicht aufwendig und fehleranfällig.

-       Neuer Lösungsansatz: Betriebssystemkern (Kernel) modifizieren → Dateien, Prozesse etc. des Angreifers werden vor allen Systemprogrammen versteckt

Grundproblem:

-       Anwendung prüft Benutzereingaben nicht ausreichend

-       JavaScript kann u.a. HTML-Formulare automatisch ausfüllen und abschicken; wurde missbraucht z.B. für

o   Sofort-Kauf von Ebay-Angeboten

o   Beleidigende oder Spam-artige Einträge in Internet-Foren

o   Generieren von URLs, die Benutzer auf fremde Webseiten umleiten und dabei sensible Daten als Parameter übergeben.

3 Arten des XSS:

1.     DOM-basiertes (lokales) XSS:

Lokal = ohne Beteiligung des Webservers

Auslöser: JavaScript Funktion prüft übergebene Parameter nicht

2.     Reflexives XSS:

Webserver liefert Webseite mit Inhalt aus, der vom Benutzer übergebene (und somit nicht-persistente) Parameter (inkl. JavaScript-Code) enthält.

Mallet bringt Alice dazu, einen Link mit entsprechenden Parametern anzuklicken

3.     Persistentes XSS

Schadcode wird vom Webserver gespeichert und bei jeder Anfrage ausgeliefert

Dadurch sehr breit gestreuter Angriff

Gegenmaßnahmen:

-       Webapplikation muss Script-Code aus Benutzereingaben entfernen oder „ungefährlich“ machen.

-       Script-Code kann anhand der Meta-Zeichen, z.B. <, erkannt werden.

-       Client-seitig: JavaScript deaktivieren oder Plugins wie NoScript verwenden

-       Content-Security-Policy - Spezifikation vertrauenswürdiger Script-Quellen, alles andere wird nicht ausgeführt

Vorgehen: statt erwartetem SQL-Aufruf wird Befehl in Aufruf versteckt

Hauptziel: Priorisierung von Schwachstellen

1 Common Vulnerability Scoring System (CVSS)

Dreiteilung in unveränderliche bzw. zeitlich und räumlich variable Charakteristika.

Drei Gruppen von Bewertungskennzahlen:

-       Base Metrics: Grundlegende Eigenschaften der Verwundbarkeit

-       Temporal Metrics: Zeitabhängige Eigenschaften der Verwundbarkeit

-       Environmental Metrics: Anwenderspezifische Eigenschaften der Verwundbarkeitund

Idee:

Input: einfache Bewertung von Schwachstellen durch vorgegebene Fragen und Antwortmöglichkeiten

Outputs:

1.     CVSS-Score (= Zahl) zwischen 0,0 (harmlos) und 10,0 (Katastrophe)

2.     CVSS-Vektor = kompakter String, Kurzfassung des gesamten Inputs

Base Metrics:

bewerten die intrinsischen, konstanten Eigenschaften von Schwachstellen

-       Exploitability metrics (technische Aspekte der Schwastelle)

o   Attack vector: Physisch, auf dem Rechner, vom LAN aus, via Internet?

o   Attack complexity: Trivial, anspruchsvoll?

o   Privileges required: Jeder, reg. User, Admin?

o   User interaction: Angreifer braucht User?

-       Impact metrics (Auswirkungen)

-       Scope (Auswirkungen auf andere Systeme)

Temporal Metrics:

bewerten den jeweils (zeitlich) aktuellen und damit variablen Stand der Schwachstelle.

-       Exploit code maturity

-       Remediation level

-       Report confidence

Enviromental Metrics

bewerten die Schwachstelle im Hinblick auf das Einsatzgebiet des betroffenen Systems; sie unterscheiden sich also z.B. je nach Organisation.

-       C, I ,A Requirements

-       Modified Base Metrics

è Zusammenspiel der 3 Gruppen, meist wird Base Score als CVSS-Score angegeben

2 Zero day Exploits

Frage seit wann neu bekannte Schwachstelle bereits ausgenutzt wurde -> Durchschnitt liegt bei 312 Tagen

Auswirkungen der Veröffentlichung einer Sicherheitslücke -> Malware-Varianten steigen um 85.000 fache, Angriffe steigen um das 100.000 fache