W2024-ITS: Difference between revisions

From
Jump to navigation Jump to search
Line 10: Line 10:


|- style="background: #eef;"
|- style="background: #eef;"
| 11:40-12:10 || '''[[Qubes Windows Tools Seamless Mode zurückbringen]]''' || KG || [[File:Qubes windows seamless mode.pdf|Präsentation (PDF)]]
| 11:40-12:10 || '''[[Qubes Windows Tools Seamless Mode zurückbringen]]''' || KG || [[File:Qubes windows seamless mode.pdf | pdf]]


|- style="background: #ddf;"
|- style="background: #ddf;"

Revision as of 12:00, 11 October 2024

Organisatorisches und Anmeldung für IT-Security Workshop vom 30. September bis 11. Oktober 2024

Wenn Sie die unten genannten Themen interessant finden und in den ersten beiden Oktoberwochen Lust und Zeit haben sich damit auseinanderzusetzen, so finden Sie hier den angestrebten Zeitplan sowie die Möglichkeit sich und (optional) ein spannendes eigenes Thema anzumelden.

Vorträge

Freitag 11.10. 2024, Rudower Chaussee 25, Haus 3, Raum 3'328 (dritte Etage)

11:40-12:10 Qubes Windows Tools Seamless Mode zurückbringen KG File:Qubes windows seamless mode.pdf
12:10-13:10 CSP: Umwandlung von Inline / Internal CSS, JS und DATA in externe Ressourcen EF, AS
13:10-13:15 Pause: Snack & Schnack
13:15-14:15 Sicherer und schneller SSL/TLS-Handshake GS, FO
14:15-15:15 JavaCard: Secure Channel VW, LM
15:15-15:20 Zusammenfassung & Dank Wolf Müller
15:20-15:30 Pause: Snack & Schnack
15:30-16:30 Verteidigung: "FIDO2 TLS 1.3 Extension: Strong EAP-TLS Authentication for 802.1X Networks" Jonas Panizza

Themen

Qubes Windows Tools Seamless Mode zurückbringen

[KG]

QubesOS ist ein Betriebssystem, das Sicherheit durch Isolierung schafft. Verschiedene Kontexte können mittels Virtualisierung über den Typ-1-Hypervisor Xen voneinander isoliert werden. Nutzer*innen erstellen verschiedene "Qubes" (virtuelle Maschinen) für die jeweiligen Kontexte (z. B. "Persönlich", "Arbeit", "Passwortspeicher", "Webbrowsing" etc.). Wenn eine Nutzer*in dann zum Beispiel im "Webbrowsing"-Qube auf einen verdächtigen Link klickt und den Qube mit Schadsoftware infiziert, bleiben die Daten in den Qubes "Arbeit" oder "Persönlich" sicher, solange die Angreifer*in keinen VM-Escape im Xen Hypervisor gefunden hat.

QubesOS liefert verschiedene Werkzeuge zur Inter-VM-Kommunikation mit. Zum Beispiel gibt es ein Clipboard, das zum sicheren Datenaustausch zwischen Qubes verwendet werden kann. Ein wichtiges Feature von Qubes ist, dass die Anwendungsfenster der verschiedenen Qubes gemeinsam in einer grafischen Nutzeroberfläche benutzt werden können, wobei Nutzer*innen Farben zur Unterscheidung der Fenster festlegen können (z.B. Webbrowsing=rot, Passwortspeicher=schwarz etc.). Dieses Feature namens "Seamless Mode" funktioniert aktuell jedoch nur mit Linux-Qubes.

Screenshot von QubesOS mit zwei offenen Anwendungsfenstern verschiedener Qubes.

Für Windows-Qubes gibt es die Qubes Windows Tools, die bis zu Windows 7 auch den Seamless Mode anboten. Seit Windows 8 funktioniert das jedoch nicht mehr. Wie können wir den Seamless Mode für aktuelle Windows-Versionen (10 oder 11) zurückbringen?

Links:

JavaCard: Secure Channel

[VW, LM]

Für viele sicherheitskritische Anwendungen werden SmartCards als Sicherheitskern verwendet. Für viele Anwendungsfälle (E-Mail Signatur, QES, nPA, eGK, SIM...) gibt es bereits komplette Lösungen die die Karte als Plattform und eine fertige Anwendung enthalten. Will man jedoch eine eigene SmartCard-Anwendung schreiben, ist oft die Verwendung einer JavaCard und die Erstellung einer eigenen Applikation ein denkbarer Weg. Doch wie geht das konkret? Finden Sie es heraus und versuchen Sie eine eigene Smartcardanwendung in Java zu entwickeln und diese gemäß des Global Platform Standards auf der hoffentlich dann vorhandenen Javacard zu installieren und dann zu verwenden. JavaCard (erste Schritte)

Um eine sichere Verbindung zwischen der SmartCard und der Anwendungauf dem Rechner zu gewährleisten (was bei Mehrbenutzersystemen (Zugriff via USB oder insbesondere bei kontaktlosen Karten) wird das "Secure Channel Protokoll" verwendet. Unsere Smartcard J3R180 unterstützt SCP in der Version 03. Versuchen Sie ein Beispiel für eine sichere Kommunikation einer Anwendung auf dem Rechner mit einem von Ihnen geschriebenen JavaCardApplet zu erstellen.

Links:

Im nächsten Schritt könnte man hier auch nach einer konkreten Anwendung suchen und PIV-Implementierung mit Support für Secure Messaging nach NIST-Vorgaben zu bauen. Dafür kämen aus unser Sicht zwei Basisprojekte infrage:

  • [1], welches bereits SCP03 (aus GlobalPlatform) für die Personalisierung nutzt und damit leider nicht in einer rein virtuellen open-source Umgebung mit JCardSIM läuft.
  • [2], welches bisher keinen Support für E2E hat, aber sehr flexibel einsetzbar ist, z.B. im Moment im CI-Testing von OpenSC. Bisher gibt es nur proprietäre Implementierungen von PIV mit Secure Massaging(SM), d.h. damit könnte man einen echten Mehrwert schaffen...

Mentor: Wolf Müller, Frank Morgner

Umsetzung eines PQC-Verfahrens im Rahmen des CNG Frameworks

(spannend, aber anspruchsvoll)

Post-Quanten-Kryptografie befindet sich derzeit im Prozess der Standardisierung und es werden viele Demo-Anwendungen umgesetzt. Statt jede Anwendung einzeln zu modifizieren und Support für diese neuen Verfahren einzubauen, bietet das MS CNG Framework die Möglichkeit, Module global im Betriebssystem zu ergänzen. Anwendungen, die die entsprechenden System-Routinen verwenden, erhalten werden damit PQC-fähig ohne modifiziert werden zu müssen.

Aufgaben:

  • Einarbeitung in das CNG-Framework
  • Analyse des Beispielcodes (C++)
  • Auswahl eines geeigneten PQC-Verfahrens (z.B. Dilithium https://pq-crystals.org/index.shtml)
  • Implementierung von CNG Cryptographic Algorithm Provider sowie Signature/Encryption Provider

Links:

Mentoren: Wolf Müller, Frank Morgner, Holger Eble

POC@FIDO2

Auch wenn FIDO2 ein Verfahren zur starken Authentisierung ist und somit nicht durch das "store now, decrypt later"-Szenario bedroht ist, so ist es sicher eine gute Idee auch an dieser Stelle bereits über die Verwendung von quantenresistenten verfahren nachzudenken. So sind ist der Plan ja die FIDO-Sticks eine lange Zeit als hardwaresichere Platform zu nutzen. Konkret wurde mit OpenSK einer in Rust geschriebenen Open-Source-Implementierung ein Prototyp vorgelegt, der die Signaturalgorithmen (klassisch) ECDSA und (PQC) Dilithium zu einer Hybridsignatur kombiniert, wobei die Signaturerstellung in einem akzeptablen Zeitrahmen auf dem FIDO-Stick erfolgt. Versuchen Sie diese Implementierung auf der Plattform Nordic nRF52840-DK zum laufen zu bringen, wie es in dem Abstract des Papers angeregt wird: "We publish an open-source implementation of our scheme at hybrid-pqc so that other researchers can reproduce our results on a nRF52840 development kit." Hierzu sollten Sie vielleicht erst einmal versuchen die klassische OpenSK-Version mit CTAP zu testen, um dann zu verstehen, wie man auf dem Stick das Erzeugen eines Schlüsselpaars anstößt. Erst im nächsten Schritt wird der Testaufbau dann auf die hybride Version erweitert.

Links:

Mentoren: Wolf Müller

FIDO2 TLS 1.3 Erweiterung

FIDO2 Security Keys bieten eine starke, datensparsame, standardisierte und zunehmend verbreitete Methode zur Clientauthentifizierung in Webanwendungen. Sie bieten hohe Sicherheit, Phishing-Resistenz, Privatsphäre und gute Benutzbarkeit. Die Authentifikatoren werden in anderen Protokollen, die eine Client-Authentifizierung erfordern, kaum verwendet, da sie ursprünglich für Webumgebungen entwickelt wurden. Das Projekt "FIDO2 TLS1.3 Extension" von Jonas Panizza implementiert TLS-Erweiterung in OpenSSL, die sowohl FIDO-Authentifizierung und -Schlüsselregistrierung direkt in TLS integriert und so für Nicht-HTTP(S)-Anwendungen verfügbar macht. Die Erweiterung wird für OpenSSL als zusätzliche C-Bibliothek bereitgestellt.

Eine eindrucksvolle Demonstration des Potenzials liefert Jonas gleich mit, indem er die Erweiterung in hostapd und wpa-Supplicant integriert, um ein 802.1X EAP-TLS-WLAN-Netzwerk einzurichten, das FIDO-Hardware-Authentifikatoren verwendet und herkömmliche X.509-Client-Zertifikate ersetzt.

Um die im TLS (Version 1.3) Handshake ausgetauschten Nachrichten besser verstehen können und damit langfristig dem Ziel von Interoperabilität zwischen "FIDO2 TLS1.3 Erweiterungen" für verschiedenen TLS-Implementierungen (zusätzlich zu OpenSSL) näher zu kommen, wäre eine Möglichkeit zum Logging/Debugging (vielleicht später sorag in Wireshark) wünschenswert. Da TLS v1.3 bereits große Teile des ServerHello verschlüsselt, sollte hier ein Mechanismus geschaffen werden, der dies, wenn vom Nutzer gewünscht, gestattet, indem Wireshark in einer Datei in standardisierter Weise die Sitzungsschlüssel zur Verfügung gestellt werden. Konkret gibt man mittels der Umgebungsvariablen SSLKEYLOGFILE an, dass dieser Mechanismus aktiv ist und in welche Datei die Schlüssel exportiert werden sollen.

Links:

Mentoren: Wolf Müller

WireGuard@Informatik

WireGuard ist ein auf modernen kryptografischen Algorithmen basierendes, in den Linux-Kernel gut integriertes und sehr performantes VPN. Die Konfiguration für einzelne Peers ist sehr übersichtlich. Jedoch ist es nicht vorgesehen, dynamische IP-Adressen nach etablierter Verbindung zu nutzen, sondern diese werden direkt in der Konfigurationsdatei gesetzt. Das reduziert die Komplexität und erhöht die Geschwindigkeit. Wie könnte aber eine komfortable Konfiguration für sehr viele Nutzer (die potenziell auch noch mehrere Geräte haben) aussehen? Gibt es hier bestehende Ansätze, wie (z.B. über einen Webdienst für authentisierte Institutsmitglieder) Konfigurationsdateien (die vielleicht auch einen QR-Code beinhalten) für die Geräte generiert und an die berechtigten Nutzer ausgeliefert werden, so dass potenziell alle Benutzer all Ihre Geräte konfliktfrei mit dem VPN verbinden können? Auch hierbei ist es sicherlich sinnvoll bereits über eine hohe Sicherheit gegen zukünftige Angreifer mit Quantencomputer nachzudenken man:

"PresharedKey — a base64 preshared key generated by wg genpsk. Optional, and may be omitted. This option adds an additional layer of symmetric-key cryptography to be mixed into the already existing public-key cryptography, for post-quantum resistance."

Ein interessantes Projekt könnte vielleicht wg-dynamic sein. Aber suchen Sie getrost nach besseren Ideen oder Ansätzen.

Etwas moderner wäre headscale "An open source, self-hosted implementation of the Tailscale control server".


Links:

Mentor: Wolf Müller

OpenVPN: performant & sicher

OpenVPN ist ein sehr etabliertes und auch historisch gewachsenes VPN, welches viele Konfigurationsmöglichkeiten bietet. Das ist einerseits natürlich fantastisch, andererseits auch eine Herausforderung. Im Vergleich zu WireGuard, welches aufgrund seiner schlanken und "state of the art"-Kryptografie bereits Einzug in den Kernel gefunden hat, ist OpenVPN häufig signifikant langsamer und nicht immer sicher konfiguriert.

Können Sie hier weiterhelfen?

  • So wäre es wünschenswert bereits jetzt etwas gegen Angreifer zu unternehmen, die den VPN-Verkehr aufzeichnen und später mit einem Quantencomputer entschlüsseln wollen. Weiterhin ist es wünschenswert, die Sicherheitsreserven zu erhöhen. Da Sie bei einer Authentifizierung mittels TLS-Client-Zertifikaten eine eigene PKI verwenden können, bietet es sich an, hier ECC-Schlüssel mit >400 Bit zu wählen. Weiterhin sind die Optionen --tls-crypt oder besser --tls-crypt-v2 interessant. Versuchen Sie, einen schnellen und sicheren TLS-Handshake zur Authentifizierung und Schlüsselableitung zu etablieren.
  • Im zweiten Schritt müssen dann noch die eigentlichen Nutzdaten ver-/entschlüsselt werden. Um dies performant und dennoch sicher umzusetzen, können Sie zum einen versuchen, die Hardwareunterstützung für AES zu aktivieren. Aber selbst wenn Ihnen das gelingt, wird WireGuard wahrscheinlich immer noch weitaus performanter sein. Das Problem ist, dass bislang bei OpenVPN in der Regel zwischen Versenden und Empfang und der Ver-/Entschlüsselung ein aufwendiger Wechsel zwischen User- und Kernelspace erfolgt, der in WireGuard nicht erforderlich ist. Doch auch hier gibt es Hoffnung in Gestalt von "OpenVPN Data Channel Offload", welches unter Linux ein Kernelmodul "openvpn-dco" nutzt um hier die Performance deutlich zu steigern. Konkret werden die AEAD Verschlüsselungen AES-GCM-256, AES-GCM-128 und CHACHA20POLY1305 unterstützt.
  • Im dritten Schritt wäre eine möglichst performante Umsetzung zum Einsatz unter den im Institut gegebenen Rahmenbedingungen wünschenswert. Hier könnte der OpenVPN-Server unter Proxmox mit möglichst Hardwareunterstützung für AES in Kombination mit DCO laufen, der Handshake sollte sicher, schnell und kompakt laufen, die Authentisierung gegen einen LDAP-Server erfolgen.

Motivation: Bei meinem OpenVPN unter Windows 10 hat sich der Downstream von 48 Mbit/s auf 182 Mbit/s (exemplarisch, nicht repräsentativ) verbessert.

Links:

Mentoren: Wolf Müller

WebAuthn / FIDO2

WebAuthn ist ein browserübergreifender Standard zur Authentisierung im Web. Die meisten modernen Browser Firefox, Chrome, Safari, Opera unterstützen die Verwendung von Sicherheitstoken zur Authentisierung gegenüber von besuchten Webdiensten ohne die Installation von weiterer Software oder Treibern. Während auch in WebAuthn aufgenommenen Standard FIDO-U2F ursprünglich dazu verwendet wurde, um eine Nutzername/Passwort-basierte Authentisierung durch die Nutzung eines universellen zweiten Faktors gegen automatisierte Angriffe entfernter Angreifer zu härten, ist es mit FIDO2 möglich, sich ganz ohne die Verwendung von Passwörtern zu authentisieren.

Probieren Sie es aus! Wo kann man sich mit FIDO2 authentisieren? (Interessante Webdienste). Versuchen Sie, einen Web-Service mit FIDO2-Authentisierung aufzusetzen! Obwohl WebAuthn/FIDO2 primär zur Nutzung mit Webdiensten entworfen wurde, sind ggf. auch andere Nutzungen (lokales Login, Windows Hello, Linux PAM, SSH, SCP, ...) denkbar. Was geht (schon)?

Mentor: Wolf Müller

CSP: Umwandlung von Inline / Internal CSS, JS und DATA in externe Ressourcen

[EF, AS]

Unser Institutswebserver verwendet aus Sicherheitsgründen Content Security Policies, um Angriffe wie CrosssiteScripting oder Ähnliches zu erschweren. Daher ist "unsafe-inline" dort verboten. In Praxis wird zwar die HTML-Seite mit dem potenziell unsicheren Inhalt ausgeliefert, jedoch wird der Client über die CSP-Wünsche des Servers im HTTP-Header informiert. 

curl -I -H "" https://www2.informatik.hu-berlin.de/~wolfm/InternalInline.html
HTTP/1.1 200 OK
Date: Tue, 01 Oct 2024 12:45:34 GMT
Server: Apache/2.4.58 (Ubuntu)
Last-Modified: Mon, 25 Sep 2023 14:35:59 GMT
ETag: "15e2-6062fe076a49c"
Accept-Ranges: bytes
Content-Length: 5602
Vary: Accept-Encoding
Content-Security-Policy: default-src 'self'
Age: 102
Content-Type: text/html

Nach dieser Information ignoriert der Browser die entsprechenden potenziell unsicheren Anteile. Wenn Sie also die das Beispiel in Ihrem Browser aufrufen, sieht es recht schlicht aus und der JavaScript-Code wird nicht interpretiert. Wenn Sie die Seite aber lokal herunterladen und dann über file:./InternalInline.html öffnen, so sind die CSP-Header nicht mehr aktiv und die Seite zeigt ein Bild und hat Farben.

Aus Sicherheitssicht gibt es gute Gründe gegen eingebettete Styles, Javascript und die Nutzung von DATA. Jedoch erzeugen viele Programme (z.B. MS Office Word) beim HTML-Export HTML, was die Separierung der Anteile nicht konsequent umsetzt. Damit sehen solche Dokumente über den Webserver ausgeliefert eher unerwartet (schlecht) aus.

Schreiben oder finden Sie ein oder mehrere Skripte, die eine für den Anwender komfortable möglichst Konvertierung ermöglichen, also alle Style-Informationen in CSS-Dateien, alles JavaScript in JS-Dateien und möglichst alle CDATA ggf. expandiert (so sie base64-kodiert sind) und diese in separate Dateien ausgliedert, die CSP-kompatibel in die konvertierte Datei dann regulär eingebunden werden. Optional können die CSS- und JS-Dateien noch kompakter dargestellt werden.

Links:

Mentoren: Wolf Müller

Absicherung KNXD

Der Zugriff auf KNX-Komponenten im Heimnetzwerk (KNX-Bus) kann mithilfe der Open Source Software knxd vom Netzwerk erfolgen. Sinnvollerweise wird der Dienst so konfiguriert, dass er nur im Heimnetzwerk (also in der Regel in einem privaten Netzwerk) verfügbar ist. Dennoch eröffnet sich damit die Möglichkeit, ohne eine weitere Authentisierung auf KNX-Komponenten zuzugreifen. So könnte ein bösartiges Gerät (Fernseher, Staubsauger, Smarter Lautsprecher) die mit meinem Heim-IP-Netzwerk verbunden sind, diese Möglichkeit ausnutzen, um Zugriff auf beispielsweise die Heizungssteuerung oder Türschlösser zu erlangen. Wünschenswert wäre hier eine stärkere Authentisierung. Ideen/Priobleme:

  • TLS mit Clientzertifikaten statt TCP-Socket?
  • Geht da was mit Wireguard?
  • TLS könnte in den Code von knxd integriert werden.
  • ETS 5 kann nicht modifiziert werden, geht da was mit stunnel?
  • Alternativ könnte man auch versuchen, eine Authentisierung gemäß KNX-IP-Secure Standard umzusetzen, was aber eher für eine Masterarbeit geeignet ist.

Links:

Mentoren: Wolf Müller

USB-Pentesting

USB-Geräte, welche leichtfertig angesteckt werden können ein beachtliches Risiko für die Sicherheit des jeweiligen Rechners darstellen. Was kann man mit solchen Geräten erreichen, welche Abwehrmechanismen gibt es? Probieren Sie es aus, zwei Geräte haben wir für unseren Workshop beschafft:

Links:


Mentoren: Wolf Müller

Sicherer und schneller SSL/TLS-Handshake

[GS, FO]

Nach den Enthüllungen von Edward Snowden haben wir verstanden, warum authentische und vertrauliche Kommunikation wichtig ist. Naiv betrachtet, könnte man denken, es ist ausreichend "s"-Protokolle wie https, imaps, pops ... zu verwenden und alles ist gut. Es ist in Praxis jedoch wesentlich komplexer eine unter dem gegenwärtigen Angreifermodell hinreichend starke SSL/TLS-Verbindung zu erzwingen.

In der Vergangenheit wurden zahlreiche teils sehr originelle Angriffe auf SSL/TLS entwickelt, die Seitenkanäle oder auch Probleme im Protokollentwurf oder der Implementierung adressieren. Weiterhin ist es wünschenswert, "forward secureness" zu nutzen, da auch nicht für jeden Server der private Schlüssel immer privat bleiben muss.

Versuchen Sie für einen aktuellen SSL/TLS-Server (z.B. Apache oder NGINX) eine möglichst sichere Konfiguration zu erstellen. Eine gute Orientierung bietet die Technische Richtlinie "BSI TR-02102-2" Behalten Sie dabei auch die Performance für den Handshake im Auge:

  • Könnte die Nutzung von ECC hier weiter helfen?
  • DH oder ECDH?
  • Was muss ein sorgsamer Client alles prüfen, wie kann ihn der Server dabei unterstützen?
    • Kann man die gesamte Zertifikatskette auch ECC-signiert bekommen?
    • Was ist OCSP-stapling
    • Was bringen die einzelnen Maßnahmen?
  • Kann Kernel-Level-TLS helfen?
  • Wie kann eventuell die Hardwareunterstützung für AES (oder gar ChaCha20) aktiviert werden?

Links:

Mentor: Wolf Müller

Retrieved from "https://sarwiki.informatik.hu-berlin.de/index.php?title=W2024-ITS&oldid=14566"