W2019-ITS

Enrollment für Thema

per E-Mail

DRAFT: Themen für IT-Security Workshop 30. September bis 11. Oktober 2019

$(Eigenes Thema)

Wie immer sind an dieser Stelle eigene Themen explizit sehr willkommen und bereichern den Workshop. Also nur Mut ...

Tock (Rust@IoT)

Tock ist ein Betriebssystem für Embeddedgeräte, welches helfen soll IoT-Anwendungen eine sicherere Platform zu bieten. Die Idee ist verschiedene Anwendungen (ggf. verschiedener Hersteller), die sich nicht vertrauen auf einer gemeinsamen Plattform zu betreiben. Schutz soll vor potenziell bösartigen Anwendungen als auch vor Gerätetreibern geboten werden. Dazu sind Kernel und Gerätetreiber in Rust geschrieben. Zusätzlich nutzt Tock Speicherschutzeinheiten, um Anwendungen und den Kernel möglichst effektiv von einander zu isolieren.

Wir freuen uns, dass knapp vor dem Workshopbeginn ein Hail "open source IoT development board" eingetroffen ist und nun von Ihnen ausprobiert werden kann. Versuchen Sie, mit dem Board zu kummunizieren und vielleicht eine erste Applikation dafür zu finden, zu kompilieren, zu installieren oder schließlich selbst zu programmieren. Berichten Sie uns über Ihre Erfahrungen und gewonnenen Erkenntnisse.

Links:

• Tock
• Hail

Mentor: Wolf Müller, Dorian Weber

ATtiny85@Keyboard

[Florian, Marvin]

Wir möchten einen ATtiny85 von Digispark in eine Tastatur einbauen. Diese soll weiterhin normal funktionsfähig sein. Extern (evtl. mittels Funk) soll dann auf den Digispark umgeschaltet werden können. Dieser meldet sich als Tastatur am System an (indem er sich als HID ausgibt) und kann so Schadcode platzieren und ausführen. Dabei wollen wir verschiedene Szenarien ausprobieren, wie z.B. das Auslesen von Passwörtern und versenden per E-Mail an uns.

Links:

• ATtiny85

Mentor: Wolf Müller

NTLM Relaying

NTLM Relayingist eine Standardklasse von Angriffen, die bei zugriffen auf das interne Netz möglich ist. Das Grundproblem ist, dass NTLM an sich keinen Schutz vor Relay-Angriffen liefert. Daraus lassen sich recht komplexe Angriffsketten bauen (z.B. der PrivExchange Angriff, bei dem das hochprivilegierte Computerkonto des Exchange-Servers weitergeleitet wird), aber auch vergleichsweise einfachere Angriffe sind häufig noch möglich. Es existieren zwei Standard-Tools für Relaying Angriffe:

• Responder und MultiRelay
• Impacket und NTLMRelayX

Die Projektaufgabe ist es zunächst den Angriff zu verstehen und einen Laboraufbau zu erstellen um diesen nachzuvollziehen. Anschließend können kleine Erweiterungen für die oben genannten (in Python geschriebenen) Werkzeuge programmiert werden:

• MultiRelayX erlaubt das filtern von weiterzuleitenden Nutzern mittels des Parameters -u. Hier wäre es nützlich wenn Wildcards unterstützt würden (z.B. -u adm*). Der Aufwand hierfür sollte gering sein
• NTLMRelayX fehlt bisher ein entsprechendes Filter-Feature. Dieses nachzurüsten sollte mit mittlerem Aufwand möglich sein.
• SMB Relaying zielt meist darauf ab Code auf dem Zielsystem auszuführen (über Zugriff auf den \\IPC$ Share auf dem Ziel und das Erzeugen und Starten eines Dienstes auf diesem Weg). Dies benötigt allerdings administrative Rechte auf dem Ziel. Ein Feature, welches es erlaubt stattdessen im Kontext der weitergeleiteten Verbindung die vorhandenen SMB-Shares zu enumerieren und zuzugreifen (z.B. über das in Impacket enthaltene smbclient.py) wäre häufig sehr nützlich. Der Aufwand dieses Feature zu implementieren dürfte hoch sein.

Mentoren: Wolf Müller, Dominik Oepen

Password cracking GUI

GPU-gestützte Wörterbuchangriffe auf Passwort-Hashes gehören mittlerweile zum Standard-Vorgehen bei Penetrationstests und Sicherheitsevaluationen. Das Standardwerkzeug hierfür ist das Kommandozeilentool hashcat (https://hashcat.net/hashcat/). In manchen Situationen (insbesondere paralleler Zugriff verschiedener Anwender auf dasselbe System) ist eine Weboberfläche zur Jobverwaltung nützlich. Es existieren verschiedene Open Source Anwendungen für diesen Anwendungsfall, unter anderem:

• WebHashcat
• wavecrack
• cracklord

Stellen Sie einen Vergleich der Funktionalitäten der verschiedenen Anwendungen auf und testen sie diese. Recherchieren sie nach weiteren Lösungen. Zur Evaluierung können zwei Nvidia GTX 980 Karten bereitgestellt werden.

Mentoren: Wolf Müller, Dominik Oepen

JavaCard (erste Schritte)

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 den vorhandenen USB Stick "SmartCafe Expert" zu installieren und dann zu verwenden.

Links:

• SmartCafe Expert
• JavaCard Plugin für Eclipse
• GP Shell
• GlobalPlatformPro
• JavaCardBuyersGuide

Mentor: Wolf Müller

Elektronische Siegel@{Bachelor,Master}urkunden

Es wäre schön zum Abschluss eine elektronisch gesiegelte oder unterschriebene Urkunde in den Händen zu halten. Aber wie kann das gehen? Entwickeln Sie erste Ideen und probieren Sie Dinge aus ...

Startpunkte/Ideen:

• Acrobat bietet das Unterschreiben an, das geht auch mit eigener Infrastruktur, wenn zuvor ein vertrauenswürdiges Zertifikat importiert ist.
• eIDAS sieht die Verwendung von elektronischen Siegeln vor
• Können die gesiegelten Informationen auch in einer leicht verifizierbaren Form auf dem Papierdokument aufgebracht werden? ((PDF-Signatur, QR-Code, OCR-Text, Hash-Wert in HEX, URI, Blockchain oder PGP-Signatur)
• Kann ein separates Gerät (z.B. Raspberry Pi, offline) zum Siegeln mit 2-Faktor-Authentisierung für ein Prüfungsbüro bereitgestellt werden?

Links:

• el. Signaturen, Siegel, Zeitstempel

Mentor: Wolf Müller

safer netboot

Es ist oft sehr bequem und schnell, einen Rechner aus dem Netzwerk zu booten. Oft geschieht dies durch Aktivierung im BIOS, unter Mitwirkung des DHCP-Servers der für den Folgeschritt mit next-server vorgibt, welcher Kernel über tftp geladen wird. Aus IT-Sicherheitssicht ist das natürlich sehr gewagt, da dabei weder der Server, noch der geladene Kernel noch der bootende Klient authentifiziert werden und die Übertragung der Informationen in der Regel unverschlüsselt erfolgt. Machen Sie es besser! Womit kann man hier Fortschritte erreichen? Hilft 'secure boot' hier weiter? Könnte iPXE einen Beitrag leisten?

Links:

• UEFI
• iPXE
• crypto
• romburning

Mentoren: Wolf Müller, Robert Sombrutzki

nftables

nftables ist die aktuelle Paketfilterimplementierung im Linux-Kernel, probieren Sie diese aus. Wie erfolgt eine Migration von iptables? Was ist neu, was ist besser? Gibt es auch Nachteile?

Links:

• Artikel(liegt vor)
• https://wiki.nftables.org

Mentoren: Wolfgang Gandre, Wolf Müller

Themen rund um den Nitrokey

Der Nitrokey ist eine Open Source Hardware- und Softwarelösung für einen USB-Stick mit integrierter Chipkarte zur hoch-sicheren Verschlüsselung von E-Mails und Daten, sowie zur Authentifizierung. Viele spannende Anregungen für weitere Features und mögliche Beiträge findet man im zugehörigen Git im Abschnitt Ideen.

Links:

• Nitrokey: Einleitung
• Git: Ideas

Absicherung NFS

Bei NFS-Freigaben sind hohe Anforderungen an die Integrität des NFS-Clienten gestellt, da allein dieser über die Einhaltung der im exportierten Dateisystem gesetzten Rechte entscheidet. Daher ist es essenziell, dass sich bei dem mountenden Clienten wirklich um den beabsichtigten legitimen Rechner handelt. Der Normalfall ist eine simple Überprüfung der IP-Adresse, die in der /etc/exports angegeben ist.

Untersuchen Sie, welche Verbesserungen hier möglich sind und welchen Aufwand, welche Komplexität die von Ihnen erarbeitenden Lösungen haben. Die verlässlichere Prüfung könnte auf verschiedenen Schichten angesetzt werden. Wünschenswert wäre zumindest eine starke und persistente Authentisierung (z.B. basierend auf privaten Schlüsseln). Denkbar wäre eine Absicherung über SSL/TLS vielleicht mit einem performanten Modus mindestens zur Integritätssicherung (TLS_RSA_WITH_NULL_SHA, TLS_RSA_WITH_NULL_SHA256, ..., TLS_RSA_WITH_AES_128_GCM_SHA256), womit zumindest aktive Angriffe unterbunden werden könnten. Alternativ könnte auch die Verwendung von NFS mit Kerberos helfen. Betrachten Sie das Verhältnis von Sicherheit und Performance.

Links:

• 802.1X
• stunnel
• chiphers
• Startpunkt

Mentoren: Wolf Müller, Robert Sombrutzki

Informatik-Sync-Server für Firefox

Die Authentisierung mittels (Name,Passwort) wird nach wie vor von vielen Diensten im Internet verwendet. Der Nutzer ist bei der Vielzahl der Dienste schlichtweg überfordert, sich all diese zu merken. Als Konsequenz wurden Lösungen wie Single Sign On oder Open ID vorgeschlagen. In der post-Snowden-Ära gibt es jedoch Bedenken, die Authentisierung an eine dritte Partei auszulagern, da diese auch im Namen des legitimen Nutzers ohne diesen eine erfolgreiche Authentisierung bewerkstelligen könnte.

Einen anderen Ansatz bieten Passwortmanager. Hier wird dem Benutzer angeboten, mit Hilfe (eines hoffentlich starken Masterpassworts) den Zugang zu den Authentisierungsdaten für die einzelnen Dienste abzusichern. Die Referenzdaten dazu können beispielsweise lokal verschlüsselt gespeichert werden. Allerdings ist es ggf. wünschenswert, den Passwortmanager auch auf verschiedenen Geräten nutzen zu können. Eine Lösung die auch die Synchronisierung zwischen verschiedenen Geräten vorsieht, ist Firefox Sync" was auch direkt im Firefox ohne zusätzliche Plugins oder Erweiterungen nutzbar ist.

Jedoch werden die (zwar verschlüsselten) Referenzdaten auf einem zentralen Server gespeichert. Hier wäre es wünschenswert, eine Lösung umzusetzen, die eine Speicherung auf unserem eigenen Informatik-Server zulässt.

Links:

• Run your own Sync-1.5 Server
• Run your own Firefox Accounts Server
• Ansible
• Eigener Sync-Server für Firefox

Mentoren: Wolf Müller, Robert Sombrutzki

DNSSEC@Informatik

Eigentlich wird schon lange über die sichere Variante von DNS gesprochen. Dennoch ist die HU und auch unser Institut noch nicht über DNS-SEC von außen validierbar. Für die Domain hu-berlin.de hat das CMS schon Grundlagen geschaffen, aber die Einbindung nach oben ist noch nicht erfolgt.

Erarbeiten Sie ein Konzept und versuchen Sie, exemplarisch einige Schritte umzusetzen. Welche Software wird benötigt, um eine Zone zu signieren. Wie können Schlüssel sicher aufbewahrt werden. Was ist mit dynamischen Einträgen?

Welche Vorteile bietet DNSSEC bei erfolgreicher Validierung? Mit DANE können auch weitere Felder über DNSSEC ausgeliefert werden. Denkbar wäre zum Beispiel auch SMTP mithilfe von DANE stärker zu machen oder auch SSH-Fingeprints von Informatikrechnern automatisch ausliefern zu lassen und so Trust-on-First-Use oder das manuelle Vergleichen mit unserer Liste zu überwinden.

Links:

• Heise: DNSSEC&DANE
• Golem
• Heise: aktuell

Mentoren: Robert Sombrutzki, Wolf Müller

DNS-over-HTTPS (DoH)

Das DNS-Protokoll stammt aus dem letzten Jahrtausend und weder Authentizität noch Vertraulichkeit der übertragenen Daten sind sichergestellt. Wenn man also in einem öffentlichen Netz unterwegs ist, kann eine recht genaues Profil erstellt werden, zu welchen Diensten man sich verbindet. Daher könnte es eine gute Idee sein, DNS-Anfragen durch HTTPS zu tunneln. Wenn wir dem Endpunkt Trusted Recursive Resolver (TRR) vertrauen, können Interessierte in der Mitte weniger über genutzte Dienste erfahren und insbesondere keine DNS-Antworten unbemerkt modifizieren. DoH ist bislang (kaum verwunderlich) vorwiegend für Browser angedacht. So unterstützt Firefox DoH ab Version 62 und verspricht eine verbesserte Privatsphäre durch Anwendung dieser Technik. Allerdings müssen die Nutzer dem TRR und insbesondere seine Policy zum Datenschutz stark vertrauen. Steht der TRR in einer anderen geografischen und damit oft juristischen Domain (Mozilla schlägt aktuell Cloudflare 1.1.1.1 vor), so gibt es ggf. für "Bedarfsträger" trotz der Policy rein praktisch die Möglichkeit zum Zugriff auf diese nun zentralisiert gewonnenen Daten. Daher wäre es interessant, einen eigenen DoH-Server zu betreiben und zu nutzen. Versuchen Sie einen eigenen Server zu etablieren, der idealer Weise (wo es möglich ist) bereits DNSSEC zur Beschaffung valider DNS-Antworten verwendet. Kann man diesen Service auch zuhause umsetzen? Könnte er auf einem WLAN-Raouter (OpenWRT oder Fritz!Box) untergebracht werden?

Links:

• Firefox: DoH
• Firefox: Einstellungen
• Golem
• Chrome

Mentoren: Wolf Müller

Absicherung KNXD

Der Zugriff auf KNX-Komponenten im Heimnetzwerk (KNX-Bus) kann mit Hilfe der Open Source Software knxd vom Netzwerk erfolgen. Sinnvoller Weise 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:

• KNXD (git)
• ETS (KNX Konfigurationssoftware
• KNXD_Tutorial
• OpenHAB_Tutorial

Mentoren: Wolf Müller

Sicherer und schneller SSL/TLS-Handshake

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-stampling
  • Was bringen die einzelnen Maßnahmen?

Links:

• BSI TR-02102-2
• Angriffe auf SSL/TLS
• (Web-)Server Test
• HOWTO OCSP stampling

Mentor: Wolf Müller