APSI H22
APSI Prep FHNW
APSI Prep FHNW
Federation
Authentifizierungen, die aus mehreren, unabhängigen Quellen die
Authentifizierungs-Merkmale beziehen, nennt man “federiert”.
Realm
Eine einzelne Authentifizierungsquelle (z.B. alle Benutzername/Passwort-Tupel eines
LDAP-Servers) bezeichnet man typischerweise als “Realm”.
Authentifizierungs-Token
Eine Information, die es erlaubt einen Benutzer unabhängig von der
Authentifizierungs-Quelle anzumelden, nennt man ein “Authentifizierungs-Token”.
Authentifizierungs-Quelle
Eine Datenstruktur oder ein Service, der es erlaubt Benutzer zweifelsfrei zu identifizieren
nennt man eine Authentifizierungs-Quelle (manchmal auch Identitäts-Provider).
Authorisierungs-Quelle
Eine Datenstruktur oder ein Service, der es erlaubt identifizierten Benutzern Rechte
zuzuweisen oder zu entziehen wird als Authorisierungs-Quelle bezeichnet.
Typische Quellen für Authentifizierungen
▸ Hart codierte Logins (NEIN!)
▸ Lokale Files
▸ SQL-Datenbanken
▸ LDAP-Server (z.B. Active Directory, OpenLDAP, OpenDJ)
Authentifizierungs Beispiel Frameworks
Es gibt an vielen Orten Authentifizierungs-Frameworks (im Web, aber auch anderswo):
▸ Microsoft Active Directory Federation Services (AD FS)
▸ Shibboleth
▸ Keycloak
▸ SAML/OIDC/OAuth2 (eigentlich Protokolle)
▸ PAM
Zusammenführen von mehreren Authentisierungs-Quellen
Authentifizierungsquellen können auf verschiedene Weisen zusammengeführt werden:
▸ Konsolidierung in einem einzelnen Authentisierungsraum (Metaverse der
Authentisierungsquellen)
▸ Federation (Delegation) auf Authentisierungsquellen
Authentisierungs-Beispiel -> Ablauf
Das erste Vertrauen -> Arten von CA's
▸ Ein vertrauenswürdiger Schlüssel (sehr starr)
▸ Eine eigene CA
▸ Eine öffentliche CA (nur selten empfehlenswert)
Sie brauchen immer einen Vertrauensanker, mit dem Sie ein Vertrauen aufbauen können.
Im extremen Fall ist ein Vertrauensanker ein Schlüssel, dem Sie direkt vertrauen. Dies wird beispielsweise
bei den Linux-Repositories so gelöst. Das Verfahren ist extremm starr.
Viel besser und effizienter ist es aber einen generischen Vertrauensanker im Sinne einer eigenen CA
aufzubauen.
Bitte Beachten Sie: Eine eigene CA hat nichts(!) mit einem eigenen Kryptoalgorithmus zu tun. Es ist nur
der Vertrauensanker für Ihre Applikation. Es hat nichts mit “Weisheit” zu tun, hier anstelle der eigenen
CA oder des eigenen Schlüssels ein öffentlich signierten Schlüssel zu verwenden.
Kryptoagilität
Unter Kryptoagilität einer Applikation versteht man die Fähigkeit, die Kryptografischen Algorithmen
auszutauschen (ohne Update natürlich) sollte sich ein Algorithmus als unsicher erweisen.
Bei einer Kryptoagilen-Applikation werden typischerweise für jedes Kryptografische Primitiv (Asymmetrische
Verschlüsselung, symmetrische Verschlüsselung, Hashing, Signatur usw.) eine Alternative zur
Verfügung, die mathematisch auf einem anderen Problem basiert (also beispielsweise RSA und eine Elliptische
Kurve oder eine elliptische Kurve und ein gitterbasierter Algorithmus usw.).
Eine Variation der Schlüssellänge wird nicht als ausreichend für Kryptoagilität betrachtet. Unter Umständen
müssen auch Dinge wie das Padding oder der Cipher-Mode für eine ausreichende Kryptoagilität
berücksichtigt werden.
Suply Chain Attacke
Von einer Supply Chain Attacke spricht man in der Cyber Security, wenn über ein
Update-Kanal oder über eine sonstige Vertrauenswürdige Quelle, Schadsostware (Malware)
eingeschleust wird.
Dependency Hijacking
Von Dependency Hijacking (oder auch Dependency Confusion) spricht man, wenn eine
eigene Abhängigkeit in einem Projekt, durch eine öffentlche Abhängigkeit übernommen wird
bei automatischer Auflösung von Abhängigkeiten.
Arten der Upgrades
Es gibt verschiedene Arten von Upgrades, die unabhängig voneinander und selektiv
eingespielt werden können müssen
▸ Sicherheits-Upgrades
▸ Bugfixes
▸ Feature-Upgrades
Upgrade Mechanismen
Ein ideales Upgrade einer idealen Applikation erfüllt folgende Kriterien:
▸ Verfügbar
Upgrade ist immer möglich (typ. online und offline)
▸ Sicher
Es ist unmöglich dass Informationen oder Programme durch Dritte über den Upgrade
eingeschleust werden können.
▸ Vertraulich
Es ist unmöglich, dass Informationen über den Upgrade-Mechanismus exfiltriert
werden können. (Datenschutz)
▸ Selbstheilend
Fehler in den Upgrades und deren Mechanismen können zuverlässig behoben werden.
Kryptoagilität
Wenn ein Programm oder Protokoll in der Lage ist auf mehrere unterschiedliche Arten von
kryptografischem Schutz aufzubauen, dann spricht man von “Kryptoagilität”.
▸ Verschiedene Asymmetrische Verschlüsselungen (z.B.
Zahlenkörper/Kurven/Gitterbasierte-Algorithmen)
▸ Verschiedene Symmetrische Chiffren (Feistel-Chiffren oder “Substitutions und
Permutationsnetzwerke”)
▸ Verschiedene Hashes
Dependency Adoption und Hijacking
Damit der Buildprozess vertrauenswürdig ist, müssen alle Quellen, also auch alle Quellen der
direkten und indirekten Abhängigkeiten kontinuierlich geprüft und überwacht werden.
Die zwei primären Gefahren hierbei sind:
▸ Dependency Adoption
▸ Dependency Hijacking (auch Dependency Confusion)
Signatur von Upgrades
Signierte Upgrades können gewährleisten, dass ein Upgrade aus einer Vertrauenswürdigen
Quelle stammt. Da es sich hier um eine sehr überschaubare Anzahl von Quellen handelt, ist
die Verwendung einer reduzierten Trust-Store (oder besser noch: einer eigenen CA für
Upgrades) sehr empfehlenswert
Hashes zur Überwachung von Upgrades
Hashes sind kein Schutz für die Vertrauenswürdigkeit eines Upgrades. Sie gewährleisten nur
die Integrität der Übertragung.
Secured DNS (DNSSEC)
Secured DNS (DNSSEC) kann verwendet werden um DNS-Einträge signiert über unsichere
Netze zu übertragen. Das bedeutet, dass die Root-Einträge mit einem, auf dem Client
hinterlegten, Root-Schlüssel signiert werden. Diese signieren die Schlüssel der
Top-Level-Domäne, welche die Schlüssel der Second-Level-Domäne (und so weiter) signieren,
bis es einen Schlüssel gibt, der den endgültigen Eintrag signiert.
DNSSEC schützt vor DNS-Spoofing-Attacken. Es kann dies aber nur tun, wenn alle
involvierten Teildomänen vertrauenswürdig sind.
OS Schutz:
Ist bei einem System mit nur einem Benutzer eine Trennung zwischen "user"-Mode und "root"-Mode noch sinnvoll? Warum/warum nicht?
Ja
Der Root-Modus erlaubt alles was im User-Mode verboten ist.
Die meisten Root-Funktionalität wird nur selten und für spezifische Aufgaben benötigt.
Input Validierung und Normalisierung:
Kann Input Normalisierung als Ersatz für Input Validierung benutzt werden? (Ob das sinnvoll ist, ist eine andere Frage...)
Erklären Sie, wie das geht oder warum das nicht geht.
Ja die Normalisierung wird so gestarltet, dass sie fehlschlägt oder leer zurückgibt, wenn die Validierungs-Kriterien nicht erfüllt sind.
Java:
Wenn sie in Java programmieren, sind sie dann prinzipell sicher vor Buffer-Overflows?
Begründen sie warum, oder geben sie 2 Beispiele an wo dies nicht gegeben ist.
1) Java (die JVM) verwendet Basisbibliotheken, die in C geschrieben sind. Und diese Können Buffer-Oberflows beinhalten. (z.B. Regex auswertung)
2) Die JVM slebst kann Bugs haben die Buffer-Overflows ermöglichen.
3) JNI ist enbefalls anfällig für Buffer-Overflows
Code Analyse:
Können Code-Analysetools alle tatsächlich möglcihen Buffer-Overflows fonden? Warum, bzw. warum nicht?
Nein,
Die statische Codeanalyse kann in der Regel keine (kompillierten) Librarys prüfen.
Cloud Storage:
Nennen Sie 2 prinzipielle Probleme der Datenablage in der Cloud.
1) Verschlüsselung: Sollen die Daten verschlüsselt werden braucht der Cloud Anbieter auch den Schlüssel, wenn alle Cloud Funktionen genutzt werden.
2) Wenn der Cloud Anbieter den Schlüssel nicht hat muss ich den Schlüssel auf allen Geräten die auf die Daten zugreifen wollen haben.
Logging:
Nehmen Sie an, Sie konfigurieren das Logging für einen Web-Shop. Spielt der Preis der Einkäufe eine Rolle für das Loggen zum Zweck der Angriffserkennung?
Warum / warum nicht?
Ja, es kann gesehen werden wenn der Preis verändert wurde.
Passwort-Sicherheit
Nehem Sie an, eine Passworteingage zeigt dem Benutzer den Argon2-Hash eines gerade eingegebenen Passwortes an. Ist das ein Sicherheitsrisiko?
Ja, Es gibt öffentliche Tabellen mit denen aus de Hash evt. auf den Klartext geschlossen werden kann. Ein Angreifer der die Session des Benutzers übernommen hat kann so den Hash ebenfalls auslesen.
Same Origin Policy (SOP)
Sie möchten verhindern, dass Kunden Opfer eines erfolgreichen CSRF-Angriffs auf ihre Website siteA.com werden. Nutzt Ihnen SOP dabei und wiese / wieso nicht?
Nein.
SOP verhindert, dass die Applikation Responses von einer anderer Domain lesen. (Browser Feature)
Es verhindert nicht, dass Requests dorthin gesendet werden.
Buffer-Overflow: Eingabe Validierung
Nehmen sie an, Sie können sich darauf verlassen, dass Web-Browser nie URLs länger als 4kB an Web-Server schicken. Können Sie dann auf die EIngabe Validierung bezüglich Länge im Web-Server verzichten und einfach direkt einen 4kB grossen Buffen benutzen?
Nein es gibt neben Webrowesern noch andere möglichkeiten Requests zu senden.:
- Mobile Clients, andere Server-Applikatonen.
Diese könnten immernoch grössere Request schicken.
Ein Angreifer kann den Server mit 4KB grossen URLs bombardieren und so so möglichst viel Speicher blockieren. (DoS)
Wo wird hier Input Validierung benötigt?
Wo wird Input Normalisierung benötigt?
Validierung:
- Gültiges Geld eingeworfen (3)
- Gültiges Produkt gwählt (2)
- Webserver & Steuergerät Daten zu Bestand (7) (2)
- Webserver zu Internet (9)
Normalisierung
Webserver Daten vo Stuergerät
Steuergerät Daten vom Webserver
Welche Logs schreiben sie bei diesem Gerät sinnvollerweise und welche Komponenten machen das?
Zeichnen sie entsprechende Pfeile ein und beschreiben sue kurz was jeweils geloggt wird.
Stuergerät:
- Einwurf von Geld
- Auswahl Dose
- Ausgabe von Dose
- Auslösen Bestandes update & Anfrage
Webserver:
- Web Zugriff Log
- Bestandes Update gemacht
- Bestand abgefragt
Ist Fuzzing geeignet um die Verwundbarkeiten gegenüber Angriffen die algorithmische Komplexität ausnutzen zu ermitteln?
Um die algoritmische Komplexität auszunutzen werden spezifische Daten benötigt, die den Worstcase des Algorithmus ausnutzen. Mit Fuzzing werden aber viele zufällige Daten gesendet.
Fuzzing kann aber als Ablenkung eingesetzt werden, wenn gleichzeitig mit dem Angriff auf die algoritmsche Komplexität Fuzzing gemacht wird.
Ist ein falsches Passwort ein Fehler im Sinne der Fehlerbehandlung?
Nein.
Wenn der Passwortcheck aufgrund einer falschen Eingabe fehlschlägt ist das die Funktion des Passwortchecks.
Zufallserzeugung:
Nehmen Sie an, Sie haben einen Hardware-Zufallsgenerator mit einem kompromittierten Design (z.B. Intel RDRAND) zur Verfügung. Können Sie diesen trozdem sinnvoll und sicher einsetzen? Wie geht das, bzw warum geht das nicht?
Es geht wenn die Entrope nciht nur ausschliesslich von diesem Generator kommt. Er sollte gemeinsam mit anderen generatoren verwendet werden.
Testen von Sicherheit:
Ist ein Pen-Test ausreichend um die Sicherheit einer Server-Software zu beurtelen?
Nein, ein Pentests ist meist nur oberflächlich und eingeschränkt (aufgrund limittierter Zeit)
Werden bei einem Pentest keine Schwachstellen gefunden heisst das noch nicht das es auch keine gibt.
Zusatz:
Welche weiteren Massnahmen sind langfristig sinnvol?
Einen eigenen Wrapper um die Library-Methode bauen welcher die Parameter-Grösse prüft und so einen Buffer-Overflow verhindert.
Zusatz:
- Code auf weitere Fehler prüfen
- Nach einer ERsatz-Library suchen die noch weiterentwickelt wird
- selber bauen
- Erwarte '['
- Erwarte beliebig Space
- Erwarte optional '-'
- Erwarte beliebig Nummern, mind 1x
- Erwarte beliebig Space
- Erwarte Komma oder ']'
- wenn Komma: starte bei 1
- wenn ']' fertig
Entropie:
Nehmen Sie an, Passworte besteh aus 10 zufälligen Ziffern und Kleinbuchstaben.
Berechnen Sie die ENtrope eines Passworts.
Mögliche Kombinationen (26+10)10
Zeichensatz a: 26 Kleinbuchstaben + 10 Ziffern = 36
Anzahl Stellen b: 10
Enthropie = b*log2(a):
10 * log2(36) = 51.7 bit
Was ist Privatsphäre?
Die Möglichkeit eines Individums oder einer Gruppe sich selbst oder INformationen über sich selbst abzugrenzen und sich somit seleketiv zu offenbaren.
Was sind parktische Gründe für die Privatsphäre?
Moderene gesellschaften investieren viel in die Ausbildung von Induvidien. Darum ist das Wohlbefinden des Individums wichtig für den gesamten Wohlstand der Gesellschaft.
Moderene Gesellschaften sind abhängig von ihren Besten und Klügsten. Und diese können an überaschenden Orten zu finden sein.
Indivuen welche Freiheiten geniessen sind weniger gestresst, krank etc. -> Je mehr Repressionen und Überwachung desto geringer die wirtschaftliche Leistung.
-
- 1 / 103
-
Cartes-fiches
OS Schutz:
Ist bei einem System mit nur einem Benutzer eine Trennung zwischen "user"-Mode und "root"-Mode noch sinnvoll? Warum/warum nicht?
Ja
Der Root-Modus erlaubt alles was im User-Mode verboten ist.
Die meisten Root-Funktionalität wird nur selten und für spezifische Aufgaben benötigt.
Input Validierung und Normalisierung:
Kann Input Normalisierung als Ersatz für Input Validierung benutzt werden? (Ob das sinnvoll ist, ist eine andere Frage...)
Erklären Sie, wie das geht oder warum das nicht geht.
Ja die Normalisierung wird so gestarltet, dass sie fehlschlägt oder leer zurückgibt, wenn die Validierungs-Kriterien nicht erfüllt sind.
Java:
Wenn sie in Java programmieren, sind sie dann prinzipell sicher vor Buffer-Overflows?
Begründen sie warum, oder geben sie 2 Beispiele an wo dies nicht gegeben ist.
1) Java (die JVM) verwendet Basisbibliotheken, die in C geschrieben sind. Und diese Können Buffer-Oberflows beinhalten. (z.B. Regex auswertung)
2) Die JVM slebst kann Bugs haben die Buffer-Overflows ermöglichen.
3) JNI ist enbefalls anfällig für Buffer-Overflows
Code Analyse:
Können Code-Analysetools alle tatsächlich möglcihen Buffer-Overflows fonden? Warum, bzw. warum nicht?
Nein,
Die statische Codeanalyse kann in der Regel keine (kompillierten) Librarys prüfen.
Cloud Storage:
Nennen Sie 2 prinzipielle Probleme der Datenablage in der Cloud.
1) Verschlüsselung: Sollen die Daten verschlüsselt werden braucht der Cloud Anbieter auch den Schlüssel, wenn alle Cloud Funktionen genutzt werden.
2) Wenn der Cloud Anbieter den Schlüssel nicht hat muss ich den Schlüssel auf allen Geräten die auf die Daten zugreifen wollen haben.
Logging:
Nehmen Sie an, Sie konfigurieren das Logging für einen Web-Shop. Spielt der Preis der Einkäufe eine Rolle für das Loggen zum Zweck der Angriffserkennung?
Warum / warum nicht?
Ja, es kann gesehen werden wenn der Preis verändert wurde.
Passwort-Sicherheit
Nehem Sie an, eine Passworteingage zeigt dem Benutzer den Argon2-Hash eines gerade eingegebenen Passwortes an. Ist das ein Sicherheitsrisiko?
Ja, Es gibt öffentliche Tabellen mit denen aus de Hash evt. auf den Klartext geschlossen werden kann. Ein Angreifer der die Session des Benutzers übernommen hat kann so den Hash ebenfalls auslesen.
Same Origin Policy (SOP)
Sie möchten verhindern, dass Kunden Opfer eines erfolgreichen CSRF-Angriffs auf ihre Website siteA.com werden. Nutzt Ihnen SOP dabei und wiese / wieso nicht?
Nein.
SOP verhindert, dass die Applikation Responses von einer anderer Domain lesen. (Browser Feature)
Es verhindert nicht, dass Requests dorthin gesendet werden.
Buffer-Overflow: Eingabe Validierung
Nehmen sie an, Sie können sich darauf verlassen, dass Web-Browser nie URLs länger als 4kB an Web-Server schicken. Können Sie dann auf die EIngabe Validierung bezüglich Länge im Web-Server verzichten und einfach direkt einen 4kB grossen Buffen benutzen?
Nein es gibt neben Webrowesern noch andere möglichkeiten Requests zu senden.:
- Mobile Clients, andere Server-Applikatonen.
Diese könnten immernoch grössere Request schicken.
Ein Angreifer kann den Server mit 4KB grossen URLs bombardieren und so so möglichst viel Speicher blockieren. (DoS)
Wo wird hier Input Validierung benötigt?
Wo wird Input Normalisierung benötigt?
Validierung:
- Gültiges Geld eingeworfen (3)
- Gültiges Produkt gwählt (2)
- Webserver & Steuergerät Daten zu Bestand (7) (2)
- Webserver zu Internet (9)
Normalisierung
Webserver Daten vo Stuergerät
Steuergerät Daten vom Webserver
Welche Logs schreiben sie bei diesem Gerät sinnvollerweise und welche Komponenten machen das?
Zeichnen sie entsprechende Pfeile ein und beschreiben sue kurz was jeweils geloggt wird.
Stuergerät:
- Einwurf von Geld
- Auswahl Dose
- Ausgabe von Dose
- Auslösen Bestandes update & Anfrage
Webserver:
- Web Zugriff Log
- Bestandes Update gemacht
- Bestand abgefragt
Ist Fuzzing geeignet um die Verwundbarkeiten gegenüber Angriffen die algorithmische Komplexität ausnutzen zu ermitteln?
Um die algoritmische Komplexität auszunutzen werden spezifische Daten benötigt, die den Worstcase des Algorithmus ausnutzen. Mit Fuzzing werden aber viele zufällige Daten gesendet.
Fuzzing kann aber als Ablenkung eingesetzt werden, wenn gleichzeitig mit dem Angriff auf die algoritmsche Komplexität Fuzzing gemacht wird.
Ist ein falsches Passwort ein Fehler im Sinne der Fehlerbehandlung?
Nein.
Wenn der Passwortcheck aufgrund einer falschen Eingabe fehlschlägt ist das die Funktion des Passwortchecks.
Zufallserzeugung:
Nehmen Sie an, Sie haben einen Hardware-Zufallsgenerator mit einem kompromittierten Design (z.B. Intel RDRAND) zur Verfügung. Können Sie diesen trozdem sinnvoll und sicher einsetzen? Wie geht das, bzw warum geht das nicht?
Es geht wenn die Entrope nciht nur ausschliesslich von diesem Generator kommt. Er sollte gemeinsam mit anderen generatoren verwendet werden.
Testen von Sicherheit:
Ist ein Pen-Test ausreichend um die Sicherheit einer Server-Software zu beurtelen?
Nein, ein Pentests ist meist nur oberflächlich und eingeschränkt (aufgrund limittierter Zeit)
Werden bei einem Pentest keine Schwachstellen gefunden heisst das noch nicht das es auch keine gibt.
Zusatz:
Welche weiteren Massnahmen sind langfristig sinnvol?
Einen eigenen Wrapper um die Library-Methode bauen welcher die Parameter-Grösse prüft und so einen Buffer-Overflow verhindert.
Zusatz:
- Code auf weitere Fehler prüfen
- Nach einer ERsatz-Library suchen die noch weiterentwickelt wird
- selber bauen
- Erwarte '['
- Erwarte beliebig Space
- Erwarte optional '-'
- Erwarte beliebig Nummern, mind 1x
- Erwarte beliebig Space
- Erwarte Komma oder ']'
- wenn Komma: starte bei 1
- wenn ']' fertig
Entropie:
Nehmen Sie an, Passworte besteh aus 10 zufälligen Ziffern und Kleinbuchstaben.
Berechnen Sie die ENtrope eines Passworts.
Mögliche Kombinationen (26+10)10
Zeichensatz a: 26 Kleinbuchstaben + 10 Ziffern = 36
Anzahl Stellen b: 10
Enthropie = b*log2(a):
10 * log2(36) = 51.7 bit
Was ist Privatsphäre?
Die Möglichkeit eines Individums oder einer Gruppe sich selbst oder INformationen über sich selbst abzugrenzen und sich somit seleketiv zu offenbaren.
Was sind parktische Gründe für die Privatsphäre?
Moderene gesellschaften investieren viel in die Ausbildung von Induvidien. Darum ist das Wohlbefinden des Individums wichtig für den gesamten Wohlstand der Gesellschaft.
Moderene Gesellschaften sind abhängig von ihren Besten und Klügsten. Und diese können an überaschenden Orten zu finden sein.
Indivuen welche Freiheiten geniessen sind weniger gestresst, krank etc. -> Je mehr Repressionen und Überwachung desto geringer die wirtschaftliche Leistung.
Warum kann Angst ausgenutzt werden?
Menschen in Angst sind nicht mehr in der lage Bedrohungen rational zu analysen.
Sie werden leichte beute für diejenigen die Behaupten die Antworten zu haben (z.B. Vorratsdatenspeicherung nützt gegen Terrorismus)
Nenne Beispiele für scheinbar Harmlose Daten und wie sie problematisch werden können.
Kundendaten über Narhungsmittel.
-> Ein exponat eines Landes tut etwas "böses"
-> Finde jeden der Nahrungsmittel aus diesem Land gekauft hat als potentiellen Sypathisanten.
Mausbewungen einer Person die ein Spiel spielt.
-> Es können Tremor Stadien und Rauschpegel ermitellt werden. Das kann z.B. Auswirkungen auf die Krankenkasse haben.
Was sind relevante Daten für die Privatsphäre?
Alle Daten die sich auf eine Einzelperson oder eine Personengruppe beziehen.
z.B. Cumuls Karten: HIV Schnelltest in der Apotheke, Schwangerschaftstests oder Essensgewohnheiten
Grundsätzliche Prinzipen des Datenschutzes
- Nur die kleiste Menge an Daten anfragen und speichern die notwendig ist.
- Daten so schnell wie möglich löschen
- Sicherstellen das aufgezeichnete Daten korrekt sind
- Meschen darüber informieren wenn Daten aufgezeichnet werden oder weitergegeben werden und um Erlaubniss Fragen
Data Pseudonymit vs Anonymity
Anonymity:
- Niemand sollte in der lage sein individuele Persönliche Daten wieder herzustellen
- Schwer bis unmöglich mit Big Data analysen
- Auch aggregationen können problematisch sein.
- Statistiken und Data Analysen können schwer oder bedeutungslos werden,
Peudonymity (Peseudo - Anonymity)
- Daten bleiben Intakt
- Wiederherstellung der Daten benötigt nur einen "Key"
- Statistiken und Anaylsen sind überhaubt nicht betroffen
Was sind schwierigkeiten bei der Pesudomization?
Schutz gegen direkte, indirekte und quasi Identifiers zusammen mit charakterstiken und Verhalten
Schutz auf EIntrag und Datensatzt Ebene
Schutz gegen re-Identifikation via Mosaic Effekt
Eine Firma bietet Services für Geld an. Die relevanten Kundendaten müssen 10 Jahre gespeichert und danach gelöscht werden.
Annahme:
- Das Live System wird jeden Monat auf ein Tape backuped.
- Jedes Jarh werden die Tapes von Januar und Juli archiviert.
- Archivierte Tapes werden nach 10 Jahren gelöscht
- Die Daten werden nach 10 Jahren aus dem Live System nach der letzten Transaktion gelöscht.
Wie lange dauert es bis de Kundendaten nach der letzten Transaktion gelöscht werden?
20 Jahre
Was ist die Idee von Kryptoshredding?
- Einen Key für jeden Kunden erstellen und sicher speichern
- Alle DSGVO relevanten Daten werden mit dem Key verschlüsselt in allen Sorages (Live, Backup, archive)
- Wenn daten gelöscht werden müssen, wird der Key gelöscht.
Was sind typische OS-Level Massnahmen gegen Bufferoverflows und wie können diese umgangen werden?
Memory-layout randomization:
Idee: Stack und Heap werden an zufällige stellen gelegt so das der Angreifer nicht weiss wo der eingeschleuste Angriffscode ist und wohin er springen muss.
Gegenmassnahme:
- NOP-Slide / Jump Cater: Grosse Bereiche an validen eintrittspunkten im Angriffscode.
- Springe an zufälligen Ort (Die Catch Area kann sehr gross gemacht werden)
NX-Bit:
Idee: Verhindere das Code auf dem Stack, Heap und anderen non-code Areas ausgeführt wird.
Gegenmassnahme: "return-oriented programming"
- Sprünge zu legitimen Library Funktionen und Code Fragmenten
- Wenn einer returned wird der nächste aufgerufen
- Diese technik ist Turing-Complete
Beschreibe die Angriffstechnik Fuzzing
Generelle Technik um Schwachstellen wie Buffer-Overflows zu finden.
Idee:
- Wirf zufällige werte oder zufällig Strukturierte Werte (z.B valides XML oder JSON) auf ein Interface
- Sieh ob etwas kaputt geht oder sich unerwartet verhaltet.
Eigenschaften:
- Einfach zu automatisieren
- Findet buffer overflows und schlechtes Errorhandling sehr schnell
- Eingeschränkt nützlich für Komplexere Interaktionen (wie Login)
Was sind die Probleme bei der Fehlerbehandlung?
Fehlerbehandlung ist eine Schwachstelle wenn das Fehlerverhalten problematisch ist.
- DoS über Resourcen erschöpfung (RAM, CPU, I/O, etc)
- Datenlecks (User Name, Account Nummern, etc.
- Leack von Software oder OS Versionen
- ....
Was sind Algoritmische Komplexität Attacken?
Nenne ein typischen beispiel.
- Nutzen die worst-case komlexität eines Algoritmuses aus, der sonst gut performt.
- Viele heutige verwendete Alogritmhen haben dieses Problem
- Zielt auf unverfügbarkeit oder massive Verzögerung ab.
Quicksort:
- Average space und time Complexity O(n log n)
- Worst Case O(n2)
- Worst Case ist sehr einfach zu treffen: Vorsortierte Daten
Regex
Können exponentielle Laufzeit auf die Input länge haben.
(a+)+ -> greedy matching, "aaaa...........aaaaab" als Input string tut weh.
Input Validierung vs Input Normalisierung
Normalisierung ist ein Verarbeitungsschritt, Validierung testet und resultiert in OK oder NOK
Validierung:
- Test before Use Prinzip
- Alle annahmen über Input testen
- Input länge (Buffer overflow)
- Character set, encoding, keine Escapes und keine Spezial Zeichen wie \0
- Valid XML, valid JSOn, valid HTML etc.
- Config Files
Normalisierung :
Die Variation von Input verkleinern (Vereinfachung der weiteren Prozessierung)
- Dekomprimieren von daten oder bildern für mehrere Kompressoren und neu kompromieren mit einem spezifischen
- Jeden Text auf UTF-8 encoden
- Virtuell ein Dokument Drucken und OCR benutzen um den Text wieder zu extrahieren.
What about Least Privilige
Gib einem Angreifer so wenig Rechte wie möglich.
Rechte können über die Zeit ändern, sollten aber immer weniger werden
- Privilege Drop
- Laufender Prozess kann rechte aufgeben.
- Immer befor einer interkation mit Ausserhalb durchführen (config files lesen, user input)
- Chroot
- Root Directry auf ein Subdir einschrönken
- Funktioniert nur mit Privilige Drop, weil root wieder ausbrechen kann
- Sandboxes
- Isolierte umgebungen
- Limmitiert den Schaden der angerichtet werden kann
- Angriffscode hat mittlerweile häufig Sandbox-Detection und verhält sich darum artig.
- VM's
- Keine Echte HW Virtualisierung
- Interaktionen zwischen VMs ist möglich
- Kein echtes Secuirty Werkzeug, mehr ein Management tool
Defense in Depth
Idee: Mehrere Security mechanismen so das einer genügt um immer noch sicher zu sein wenn andere gebrochen wurden
Defense in Depth: Privilege Separation
Kombination aus Least privilege und Test Before Use
- Code läuft in Modulen mit minimalen Rechten
- Trennung von
- Input Normalisierung
- Netzwerk und System Zugang
- User Interaktionen
- Module im Datenfluss sind nicht direkt zugänglich
- Wenn Datenformat zu einem späteren Zeitpunkt ungültig ist, wird abgebrochen
Kommunikations Mechanismen (Privilege Separation)
Gut geeignet:
- Anonyme und Named Pipes
- Lokale Sockets
- Signals
- Files im Dateisystem (mit korrekten Berechtigungen)
Weniger gut geeignet
- RPC (Remote Procedure Calls): Schelchte Security vergangenheit
- Shared Memory: Bufferoverflow kann verbreitet werden
- Serialisierte Objekte: Könnte kompromitierte Objekte senden
- Netzwerksockets: Interene Kommunikation wird dem Netzwerk zugänglich gemacht.
Wie schützt man sich wirklich gegen Buffer Overflows?
Explizite grössen Checks bei jeder Buffer-Insertion
Problem: Das verlangsamt prozesse immer, manchmal drastisch
Erstellung Kryptografischer Keys
Benötigt hoch qualitativen "zufall" -> Nicht vorhersagbare Daten
- CPRNG (Cryptographic Pseudo Random Number Generator)
- Es darf nicht möglich sein nach einer endlichen Anzahl Outputs den State des Generators zu kennen und somit die Zukunft vorherzusagen.
- Werden geseedet (mit mind. 256 Bit Entropie)
Was bedeutet eine Implementierung ist "Trusted"
"Trusted" = "can break your security" = "you have to trust it...."
