APSI H22

Authentifizierungen, die aus mehreren, unabhängigen Quellen die
Authentifizierungs-Merkmale beziehen, nennt man “federiert”.

Eine einzelne Authentifizierungsquelle (z.B. alle Benutzername/Passwort-Tupel eines
LDAP-Servers) bezeichnet man typischerweise als “Realm”.

Eine Information, die es erlaubt einen Benutzer unabhängig von der
Authentifizierungs-Quelle anzumelden, nennt man ein “Authentifizierungs-Token”.

Eine Datenstruktur oder ein Service, der es erlaubt Benutzer zweifelsfrei zu identifizieren
nennt man eine Authentifizierungs-Quelle (manchmal auch Identitäts-Provider).

Eine Datenstruktur oder ein Service, der es erlaubt identifizierten Benutzern Rechte
zuzuweisen oder zu entziehen wird als Authorisierungs-Quelle bezeichnet.

▸ Hart codierte Logins (NEIN!)
▸ Lokale Files
▸ SQL-Datenbanken
▸ LDAP-Server (z.B. Active Directory, OpenLDAP, OpenDJ)

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

Authentifizierungsquellen können auf verschiedene Weisen zusammengeführt werden:
▸ Konsolidierung in einem einzelnen Authentisierungsraum (Metaverse der
Authentisierungsquellen)
▸ Federation (Delegation) auf Authentisierungsquellen

▸ 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.
 

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.

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.

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.

Es gibt verschiedene Arten von Upgrades, die unabhängig voneinander und selektiv
eingespielt werden können müssen
▸ Sicherheits-Upgrades
▸ Bugfixes
▸ Feature-Upgrades

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.

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

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)

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 sind kein Schutz für die Vertrauenswürdigkeit eines Upgrades. Sie gewährleisten nur
die Integrität der Übertragung.

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.

Ja die Normalisierung wird so gestarltet, dass sie fehlschlägt oder leer zurückgibt, wenn die Validierungs-Kriterien nicht erfüllt sind.

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 

Nein, 

Die statische Codeanalyse kann in der Regel keine (kompillierten) Librarys prüfen. 

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.

Ja, es kann gesehen werden wenn der Preis verändert wurde. 

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. 

Nein. 
SOP verhindert, dass die Applikation Responses von einer anderer Domain lesen. (Browser Feature) 

Es verhindert nicht, dass Requests dorthin gesendet werden. 

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)

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

Stuergerät: 

• Einwurf von Geld
• Auswahl Dose
• Ausgabe von Dose
• Auslösen Bestandes update & Anfrage

Webserver: 

• Web Zugriff Log
• Bestandes Update gemacht
• Bestand abgefragt

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.

Nein. 
Wenn der Passwortcheck aufgrund einer falschen Eingabe fehlschlägt ist das die Funktion des Passwortchecks.

Es geht wenn die Entrope nciht nur ausschliesslich von diesem Generator kommt. Er sollte gemeinsam mit anderen generatoren verwendet werden.

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. 

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

Mögliche Kombinationen (26+10)¹⁰

Zeichensatz a: 26 Kleinbuchstaben + 10 Ziffern = 36

Anzahl Stellen b: 10

 Enthropie = b*log2(a): 

10 * log₂(36) = 51.7 bit

Die Möglichkeit eines Individums oder einer Gruppe sich selbst oder INformationen über sich selbst abzugrenzen und sich somit seleketiv zu offenbaren.

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.