W2016-ITS: Difference between revisions
m (→Vorträge) |
|||
(69 intermediate revisions by 9 users not shown) | |||
Line 1: | Line 1: | ||
=Vorträge= |
|||
='''(Entwurf)''' Themenvorschläge für [https://sar.informatik.hu-berlin.de/teaching/2016-w/2016w_ITSecurityWorkshop/ IT-Security Workshop] 4. bis 14. Oktober [https://sar.informatik.hu-berlin.de/teaching/2016-w/2016w_ITSecurityWorkshop/ 2016]= |
|||
'''Freitag 14.10. 2016,''' Rudower Chaussee 25, Haus 3, '''Raum 3'101''' |
|||
{| class="wikitable" style="text-align: left; background: #cfc;" |
|||
|- style="background: #eef;" |
|||
| 10:00-10:45 || '''Location Sharing''' || Andreas, Fabio, Simon || [https://sar.informatik.hu-berlin.de/teaching/2016-w/2016w_ITSecurityWorkshop/talks/LocationSharing.pdf pdf] |
|||
|- style="background: #ddf;" |
|||
| 10:45-11:45 || '''Sichere Webserver(konfiguration)''' || Daniel, Florian, Oliver, Max || |
|||
[https://sar.informatik.hu-berlin.de/teaching/2016-w/2016w_ITSecurityWorkshop/talks/Sichere_Webserver_Konfiguration.pdf pdf] |
|||
|- |
|||
| 11:45-12:30 || '''Mittagspause''' || || |
|||
|- style="background: #eef;" |
|||
| 12:30-13:15 || '''LANGSEC''' || Marco, Jan, Arthur || |
|||
[https://sar.informatik.hu-berlin.de/teaching/2016-w/2016w_ITSecurityWorkshop/talks/langsec.pdf pdf] |
|||
|- style="background: #ddf;" |
|||
| 13:15-14:45 || '''Cold Boot Attack''' || Mike, Alex, Benni, Lucas || |
|||
[https://sar.informatik.hu-berlin.de/teaching/2016-w/2016w_ITSecurityWorkshop/talks/Cold_Boot_Attack_.pdf pdf] |
|||
|- |
|||
| 14:45-15:00 || '''Kekse / Getränke''' || || |
|||
|- style="background: #eef;" |
|||
| 15:00-15:30 || '''Smartcardemulation@Watch''' || Jan-Christopher ||[https://sar.informatik.hu-berlin.de/teaching/2016-w/2016w_ITSecurityWorkshop/talks/itsec_smartcardemulation_watch_.pdf pdf] |
|||
|- style="background: #ddf;" |
|||
| 15:30-16:15 || '''Installer für virtuellen Smartcardleser für Windows''' || Nick, Jens, Lennart || [https://sar.informatik.hu-berlin.de/teaching/2016-w/2016w_ITSecurityWorkshop/talks/Installer.pdf pdf] |
|||
|- style="background: #eef;" |
|||
| 16:15-16:30 || '''Zusammenfassung, Auswertung''' || [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller] || |
|||
|} |
|||
Pro Gruppe ist angedacht: Mindestens 30 Min und mindestens (#Mitglieder) * 15 Min (+ ggf. Demo) zwischen Redezeit und Diskussion und Umbaupause aufzuteilen. |
|||
=Themen für [https://sar.informatik.hu-berlin.de/teaching/2016-w/2016w_ITSecurityWorkshop/ IT-Security Workshop] 4. bis 14. Oktober [https://sar.informatik.hu-berlin.de/teaching/2016-w/2016w_ITSecurityWorkshop/ 2016]= |
|||
[mailto:Wolf.Mueller@informatik.hu-berlin.de?Subject=Enroll_to_ITSEWS_2016&Body=Ich%20melde%20mich%20hiermit%20f%C3%BCr%20den%20ITSEWS%20an%0A========================================%0AName:%0AVorname:%0AMatikelnummer:%0AThema:%0AE-Mail%20(INF): Enrollment] |
|||
==Sichere SSL/TLS-Konfiguration im Allgemeinen== |
==Sichere SSL/TLS-Konfiguration im Allgemeinen== |
||
Line 28: | Line 60: | ||
Mentor: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller] |
Mentor: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller] |
||
==Die Zukunft TLS 1.3== |
|||
==Sichere Webserver(konfiguration)== |
|||
Wo geht die Reise in der Standardisierung hin? Weniger Optionen, schnellerer Handshake, schneller Transport. |
|||
Gibt es bereits erste Implementierungen des neuen Standards? Was gibt OpenSSL 1.1.* her. |
|||
Links: |
|||
* [https://blog.cloudflare.com/introducing-tls-1-3/ Blog] |
|||
* [https://tools.ietf.org/html/draft-rescorla-tls13-new-flows-00 Idee: Zero Round Trip] |
|||
Mentor: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller] |
|||
==Post Quantum Crypto== |
|||
Praktische Implementierungen --> Google, Chrome |
|||
Mentor: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller] |
|||
==Sicheres OpenVPN== |
|||
OpenVPN ist eine gute Möglichkeit, seine Kommunikation durch öffentliche Netze abzusichern oder sich logisch in die HU oder in das Institut für Informatik zu begeben. Untersuchen Sie, wie diese Verbindungen ([https://www.cms.hu-berlin.de/de/dl/netze/vpn/openvpn/hu-berlin-win.ovpn hu-berlin.ovpn] und [https://www2.informatik.hu-berlin.de/rbg/Openvpn_SSL/ am Institut]) konfiguriert sind, und welche Verbindungen zwischen Server und Client ausgehandelt werden. Hierbei gibt es zu beachten, dass es OpenVPN eine Kontrollverbindung zur Authentisierung und Schlüsselvereinbarung und eine Datenverbindung zum sicheren Transport der eigentlichen Daten nutzt. Für einen aktuellen OpenVPN-Clienten kann man die die Möglichkeiten für eine TLS-Absicherung der Kontrollverbindung mit [[openvpn--show-tls-win|<code>openvpn --show-tls</code>]] und die Absicherungsmöglichkeiten der Datenverbindung mit [[openvpn--show-cipher-win|<code>openvpn --show-cipher</code>]] einsehen. Versuchen Sie eine effiziente, starke und auch möglichst interoperable Konfiguration zu erstellen, die mit aktueller Software den Zugriff unter Linux, Mac, Windows, iOS und Android gestattet. Verschaffen Sie sich einen Überblick. Welche Vor- / Nachteile haben die Modi CBC, CFB, CFB1, CFB8, OFB und was bewirken diese überhaupt? |
|||
Links: |
|||
* [https://openvpn.net/index.php/open-source.html OpenVPN] |
|||
* [https://www.wireshark.org/ Wireshark] |
|||
* [https://wiki.wireshark.org/OpenVPN Wireshark OpenVPN] |
|||
* [http://blog.dornea.nu/2015/11/17/openvpn-for-paranoids/ Blog] |
|||
Mentoren: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller], [https://www.informatik.hu-berlin.de/de/forschung/gebiete/sar/people/sombrutz Robert Sombrutzki] |
|||
==<span style="background:greenyellow">[[Sichere Webserver(konfiguration)]]</span>== |
|||
[Daniel, Florian, Oliver, Max] |
|||
Nachdem wir uns im Rahmen der obigen Themen Kenntnisse erworben haben, wie möglichst sichere SSL/TLS-Verbindungen erreicht werden können ist das Thema "sicherer Webserver" damit noch nicht erledigt, sondern es muss auch sichergestellt werden, dass möglichst alle Daten auch unter SSL/TLS ausgeliefert werden und das Zertifikat und damit der öffentliche Schlüssel authentisch sind. |
|||
Mozilla hat mit Observatory eine Test-Suite bereitgestellt, mit der viele Aspekte untersucht werden können. |
|||
Stichworte sind hier: |
|||
* CSP |
|||
* HTTP Public Key Pinning |
|||
* X-Frame-Options |
|||
* X-XSS-Protection |
|||
Testen Sie exemplarisch einige Webserver in der Informatik und versuchen Sie ein Konzept zur Beseitigung dieser Schwachpunkte zu erarbeiten. Dabei ist es sicher hilfreich, auch Tests nichtöffentlicher Server zu ermöglichen, was eine eigene lokale Installation der Testsuite erfordert. |
|||
Links: |
Links: |
||
* [https://observatory.mozilla.org/ Mozilla Observatory] |
* [https://observatory.mozilla.org/ Mozilla Observatory] |
||
* [https://github.com/mozilla/http-observatory Lokale Installation] |
* [https://github.com/mozilla/http-observatory Lokale Installation] |
||
* [https://raymii.org/s/articles/HTTP_Public_Key_Pinning_Extension_HPKP.html HPKP] |
|||
Mentoren: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller], [https://www2.informatik.hu-berlin.de/~kaempfer/ Petra Kämpfer] |
|||
==<span style="background:greenyellow">[https://sarwiki.informatik.hu-berlin.de/SmartcardleserInstaller Installer für virtuellen Smartcardleser für Windows]</span>== |
|||
[Nick, Jens, Lennart] |
|||
==Installer für virtuellen Smartcardleser für Windows== |
|||
Die Android-App [ https://frankmorgner.github.io/vsmartcard/remote-reader/README.html "Remote Smart Card Reader"] |
Die Android-App [ https://frankmorgner.github.io/vsmartcard/remote-reader/README.html "Remote Smart Card Reader"] |
||
erlaubt die Nutzung eines geeigneten NFC-Smartphones als kontaktlosen Kartenleser an einem PC. Die Aufgabe des Projektteams ist die Erstellung eines Windows-Installers für den dazugehörigen virtuellen Smartcard-Leser. |
erlaubt die Nutzung eines geeigneten NFC-Smartphones als kontaktlosen Kartenleser an einem PC. Die Aufgabe des Projektteams ist die Erstellung eines Windows-Installers für den dazugehörigen virtuellen Smartcard-Leser. |
||
Line 40: | Line 116: | ||
Mentor: [mailto:Frank.Morgner@BDr.de Frank Morgner] |
Mentor: [mailto:Frank.Morgner@BDr.de Frank Morgner] |
||
==<span style="background:greenyellow">[[Smartcardemulation@Watch]]</span>== |
|||
[Jan-Christopher] |
|||
==Smartcardemulation@Watch== |
|||
Im Android-Betriebssystem ist seit einigen Versionen die Möglichkeit der "host card emulation" HCE, also mit geeigneten Smartphones mit NFC-Schnittstelle eine kontaktlose Smartcard gegenüber einem Lesegerät zu emulieren, vorhanden. Noch bequemer wäre es, wenn bei der Nutzung das Telefon in der Tasche bleiben könnte und statt dessen eine HCE-fähige Smartwatch zur Präsentation gegenüber dem Leser verwendet wird. Konkret soll die eigentliche Emulation auf einem Android-Smartphone erfolgen, die Präsentation an einer über Bluetooth gekoppelten Samsungs "Gear S2" Uhr. |
Im Android-Betriebssystem ist seit einigen Versionen die Möglichkeit der "host card emulation" HCE, also mit geeigneten Smartphones mit NFC-Schnittstelle eine kontaktlose Smartcard gegenüber einem Lesegerät zu emulieren, vorhanden. Noch bequemer wäre es, wenn bei der Nutzung das Telefon in der Tasche bleiben könnte und statt dessen eine HCE-fähige Smartwatch zur Präsentation gegenüber dem Leser verwendet wird. Konkret soll die eigentliche Emulation auf einem Android-Smartphone erfolgen, die Präsentation an einer über Bluetooth gekoppelten Samsungs "Gear S2" Uhr. |
||
Line 53: | Line 130: | ||
Mentor: [mailto:Frank.Morgner@BDr.de Frank Morgner] |
Mentor: [mailto:Frank.Morgner@BDr.de Frank Morgner] |
||
==Portierung von vorhandenen Smartcard-Anwendungen auf Android== |
==Portierung von vorhandenen Smartcard-Anwendungen auf Android== |
||
Line 78: | Line 154: | ||
==Privacy@Home== |
|||
==Experimentell: Cold Boot Attack== |
|||
Das IoT steht vor der Tür. Zunehmend begehren technische Geräte (Fernseher, DVD-Player, Heizung, ...) Zugang zu unserem Heimnetzwerk. Auf der einen Seite lassen sich natürlich neue gewollte Komfortfunktionen realisieren auf der anderen Seite stellen diese Geräte aber eine potenzielle Bedrohung für unser Heimnetz und unsere Privatsphäre da. |
|||
Wie kann man diese Geräte in dem was sie tun können begrenzen. Versuchen Sie den Zugriff auf das Heimnetz von diesen Geräten aus und den Zugriff auf und aus dem Internet unter Beteiligung dieser zu limitieren. |
|||
Exemplarisch soll dazu eine Fritz!Box 7390 Verwendung finden. Sichworte: Gastnetz, Filter, .... Wie authentifizieren Sich Geräte gegenüber ihrem Netzwerk und wie verlässlich ist diese Information? |
|||
Welche URLs nutzen Ihre Heimgeräte legitim, welche waren unerwartet? |
|||
Links: |
Links: |
||
* [https://avm.de/service/fritzbox/fritzbox-7390/uebersicht/ 7390] |
|||
* [https://www.youtube.com/watch?v=JDaicPIgn9U Video] |
|||
* [http://www.gtkdb.de/index_15_1760.html IP-Capture] |
|||
Mentor: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller] |
Mentor: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller] |
||
==<span style="background:greenyellow">[[Location Sharing]]</span>== |
|||
==BSI TR-03108 Sicherer E-Mail-Transport== |
|||
[Andreas, Fabio, Simon] |
|||
Die Technische Richtlinie "Sicherer E-Mail-Transport" (BSI TR-03108) definiert konkrete Anforderungen an einen E-Mail-Diensteanbieter (EMDA). Ziel der Technischen Richtlinie ist die Erhöhung der Vergleichbarkeit und Verbreitung sicherer E-Mail-Kommunikation. Ziel bei diesem Thema ist es zu schauen, welche Schutzmaßnahmen für unseren Informatik-Mail-Server umgesetzt werden können. Hierbei geht es vor allem um technische Maßnahmen zur Absicherung eines authentischen und vertraulichen E-Mail-Transports. |
|||
Die Möglichkeit seinen eigenen Standort mit anderen zu teilen ist in einigen Szenarien praktisch, erfordert allerdings einen guten Schutz der sensiblen Daten vor Dritten. Dieses Thema beschäftigt sich mit dem Entwurf eines Systems, das zunächst die durch mobile Clients auf der Plattform iOS ermittelten Standortdaten ohne notwendiges Vertrauen an einen Server übermittelt. Der Server übernimmt die Weiterleitung dieser Daten an den Anfragenden. |
|||
Die im RFC 6698 beschriebene "DNS-Based Authentication of Named Entities (DANE)" scheint ein gutes Mittel zu sein, um jenseits von bestehenden PKI-Mechanismen eine starke Authentisierung eines Servers und spätere Absicherung der Verbindung über SSL/TLS ausgehend von dessen DNS-Namen zu erreichen. Versuchen Sie dieses Konzept für unseren Institutsmailserver umzusetzen. Bezüglich DANE gibt es bereits Vorarbeiten aus dem letzten Jahr [[DANE für unseren Mail-Server]]. |
|||
Interessant ist dabei die Sicherheit des Systems, insbesondere die durch Verschlüsselung erreichte Ende-zu-Ende-Vertraulichkeit der Übertragung. Ein weiterer Fokus wird darauf gelegt, keine identifizierende Daten erheben zu müssen, um eine Pseudonymität der Nutzer sicherzustellen und gleichzeitig die gewünschte Funktionalität zu gewährleisten. |
|||
Hinsichtlich der umsetzbaren organisatorischen und physischen Sicherheitsmaßnahmen wird es sicherlich Unterschiede zu gewerblichen E-Mail-Dienste-Anbietern geben, jedoch ist es sicherlich interessant, was sich an technischen Schutzmechanismen am Institut umsetzen lässt oder schon so in Betrieb ist. |
|||
'''''Ausblick''''' |
|||
Links: |
|||
* [https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr03108/index_htm.html TR-03108] |
|||
* [http://www.heise.de/ct/heft/2014-11-DANE-verbessert-sicheren-Transport-zwischen-Mailservern-2228494.html C't 11/14 Geleitschutz: DANE verbessert sicheren Transport zwischen Mailservern] |
|||
* [http://tools.ietf.org/html/rfc6698 RFC 6698 DANE] |
|||
* [http://www.ietf.org/rfc/rfc4033.txt RFC 4033 DNSsec] |
|||
Zur Erzielung einer weitgehenden Plattformunabhängigkeit wäre eine Implementation unter Android wünschenswert. |
|||
Mentor: [https://sar.informatik.hu-berlin.de/people/jan-peter_bell.htm Jan-Peter Bell], [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller] |
|||
Interessant wäre eine Untersuchung, inwieweit das Kommunikationsprotokoll so modifiziert werden kann, dass eine Auswertung der Standortinformationen in gewissem Maße für den Server möglich wird, ohne jedoch die angestrebten Schutzziele abschwächen zu müssen. Auf diese Weise wäre es beispielsweise möglich, Standortdaten von sich nah beieinander befindlichen Nutzern serverseitig proaktiv an die entsprechenden Clients zu pushen. |
|||
==<span style="background:greenyellow">Experimentell: Cold Boot Attack</span>== |
|||
==[[Email-Push-Notifikation]]== |
|||
[Mike, Alex, Benni, Lucas] |
|||
Ziel ist es eigentlich flüchtige Speicherinhalte durch die Nutzung von Kälte (in Gestalt von flüssigem Stickstoff) solange zu konservieren, dass sie bei unmittelbar an das Abschalten anschließenden Fremdbootvorgang noch (teilweise) ausgelesen werden können. |
|||
Zunehmend wird Email auch von unterwegs auf mobilen Geräten gelesen. Dabei ist es sicherlich interessant, wie ein Smartphone mitbekommt, dass es für seinen Besitzer eine oder mehrere neue Emails gibt. Die naive Lösung ist das über einen "pull"-Zugriff zu lösen. Das Smartphone würde also in regelmäßigen Abständen sich über SSL/TLS bei unserem Institutsserver mit dem Nutzeraccount einloggen und schauen, ob es für den Nutzer neue Email gibt. |
|||
Möchte ein Nutzer schnell erfahren, dass neue Email da sind, wir das Verfahren recht schnell aufwendig und nimmt die Batterie recht in Anspruch. |
|||
Etwas moderner ist sicherlich die Verwendung von imap-idle. Jedoch muss auch hier die Mail-App auf dem Telefon laufen und die TCP-Verbindung offen halten. Allerdings können mehrfache SSL/TLS-Handshakes vermieden werden. Schöner wäre es, wenn der Mailserver die Benachrichtigung via push-Nachricht über ein Gateway (Apple|Google) dem Betriebssystem des Smartphones mitteilt, dass neue Email da ist, also den für das jeweilige Mobile-OS gedachten Standardweg nutzt. |
|||
Links: |
|||
Wäre imap-notify eine Alternative? |
|||
* [https://sarwiki.informatik.hu-berlin.de/Cold_Boot_Attack CBA aka was wir vom IT-Sec-Workshop gelernt haben ] |
|||
* [https://www.usenix.org/legacy/event/sec08/tech/full_papers/halderman/halderman.pdf Paper] |
|||
* [https://www.youtube.com/watch?v=JDaicPIgn9U Video] |
|||
* [http://www.ingenieurdienst.de/res/dokumente/download/pdfs/gefd0108.pdf Sicherheitshinweise] |
|||
* [https://www.physik.hu-berlin.de/de/institut/mitarbeiter/56632/51550 Kontakt] |
|||
Mentor: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller] |
|||
Untersuchen sie die Möglichkeiten für die Umsetzung mit IMAP (dovecot) für iOS oder ggf. auch Android. |
|||
=="Grammatik"-basiertes Fuzzing== |
|||
Fuzzing ist eine nützliche Technik, um Bugs zu finden. In letzter Zeit |
|||
ist AFL sehr beliebt, vom Ansatz her ist es aber eher für Binärformate |
|||
als für Textformate geeignet. Eigene simple Tests zum |
|||
Grammatik-basierten Fuzzen von Lua mit Lua waren vielversprechend |
|||
((1), (2)), der erste Bug wurde in wenigen Minuten gefunden. (AFL lief |
|||
über eine Woche ohne einen einzigen Bug zu finden.) Durch Erweitern der |
|||
Grammatik & Generierung um etwas Semantik (außerhalb von Schleifen kein |
|||
"break" generieren usw.) und Beschreibung der Funktionen der stdlib in |
|||
der Grammatik konnte nochmal einiges mehr erreicht werden. ((3), (4) mit |
|||
Beispiel, (5)) |
|||
Hier könnte z.B. die Implementierung verbessert werden (mehr |
|||
Semantik-Infos tracken, besserer Zufall, ...) oder Grammatiken für |
|||
andere Sprachen oder Dateiformate gebaut & andere Programme getestet |
|||
werden. Auch eine Anleitung "Wie präpariere ich ein Programm zum |
|||
(relativ) sicheren & effektiven Fuzzen?" wäre vmtl. ein nützliches Resultat. |
|||
Links: |
Links: |
||
* [https:// |
* [https://www.lua.org/bugs.html#5.3.3-1 (1)] |
||
* [ |
* [https://www.lua.org/bugs.html#5.3.3-3 (2)] |
||
* [http://lua-users.org/lists/lua-l/2016-07/msg00369.html (3)] |
|||
* Pushbullet |
|||
* [http://lua-users.org/lists/lua-l/2016-07/msg00388.html (4)] |
|||
* [http://lua-users.org/lists/lua-l/2016-08/msg00047.html (5)] |
|||
Anleitung: |
|||
* [[PushNotification]] |
|||
==<span style="background:greenyellow">[[LANGSEC (language-theoretic security)]]</span>== |
|||
Mentor: [https://sar.informatik.hu-berlin.de/people/jan-peter_bell.htm Jan-Peter Bell], [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller] |
|||
[Marco, Jan, Arthur] |
|||
LANGSEC ((1), Kernthesen: (2)) ist eine aus Exploit-Praxis und |
|||
theoretischer Informatik motivierte Sicht auf Hacking. Im Kern steht |
|||
die Erkenntnis, dass der Eingaben verarbeitende Teil eines Programms |
|||
effektiv ein Interpreter ("weird machine") mit einer durch seine |
|||
Implementierung bestimmten Funktionalität ist. Die Eingabe eines |
|||
Programms (Dateien/Pakete) kann als "Programm" für dieses bzw. die durch |
|||
es implementierte "weird machine" aufgefasst werden. Das durch den |
|||
Parser zur Verfügung gestellte Berechnungsmodell (von Finite State |
|||
Machine über zusätzliche Stack(s) oder andere Erweiterungen bis hin zu |
|||
einem Turing-Maschinen-Äquivalent) ist in Verbindung mit Funktionalität, |
|||
die aus dem Parser heraus zugänglich ist (Speicherallokation, |
|||
öffnen/lesen/schreiben anderer Dateien, ...) durch geeignete |
|||
Konstruktion der Eingaben programmierbar. |
|||
In die eine Richtung lassen sich hieraus klare Richtlinien für das |
|||
==U2F (reloaded)== |
|||
Design von Datenformaten und Protokollen ablesen, die Hacking |
|||
Im letzen Jahr haben wir uns bereits mit der 2-Faktorauthentisierung gemäß [[U2F FIDO]] beschäftigt. Diese ist aus unserer Sicht eine sehr interessante Authentisierungstechnik, die ein hohes Maß an Anonymität, Sicherheit und Komfort miteinander verbinden kann. Der ursprüngliche Fokus von U2F lag in der Authentisierung gegenüber Webdiensten. Aber natürlich ist es auch denkbar U2F-Token zur Authentisierung in anderen Kontexten (PAM, SSH, ...) zu nutzen. |
|||
erschweren. In die andere Richtung ergibt sich eine interessante |
|||
Angriffsperspektive, die auch abseits von Dateiformaten interessante |
|||
Ergebnisse liefert. (Es stellte sich z.B. heraus, dass z.B. |
|||
ELF-Metadaten (3) oder auch die MMU (4) turing-complete sind.) |
|||
Hier wäre die Analyse weiterer Datenformate oder auch |
|||
Hardwarekomponenten interessant. Eine konkrete Idee wäre z.B. sich |
|||
einen Überblick über den Aufbau verschiedener Bildformate zu schaffen, |
|||
diese in Komplexitätsklassen einzuordnen und ggf. Implementierungen der |
|||
fehleranfälligeren Formate an den im ersten Schritt als interessant |
|||
identifizierten Stellen zu analysieren. |
|||
Links: |
|||
* [http://langsec.org/ (1)] |
|||
* [http://langsec.org/occupy/ (2)] |
|||
* [https://github.com/bx/elf-bf-tools (3)] |
|||
* [https://github.com/jbangert/trapcc (4)] |
|||
==FIDO UAF|U2F (reloaded)== |
|||
Im letzen Jahren haben wir uns bereits mit der 2-Faktorauthentisierung gemäß [[U2F FIDO]] beschäftigt. Diese ist aus unserer Sicht eine sehr interessante Authentisierungstechnik, die ein hohes Maß an Anonymität, Sicherheit und Komfort miteinander verbinden kann. Der ursprüngliche Fokus von U2F lag in der Authentisierung gegenüber Webdiensten. Aber natürlich ist es auch denkbar U2F-Token zur Authentisierung in anderen Kontexten (PAM, SSH, GIT, ...) zu nutzen. |
|||
Versuchen Sie einen Überblick zu gewinnen, für welche Protokolle oder Szenarien U2F genutzt werden können sollte und versuchen sie dies auch als "proof of concept" auch auszuprobieren. |
Versuchen Sie einen Überblick zu gewinnen, für welche Protokolle oder Szenarien U2F genutzt werden können sollte und versuchen sie dies auch als "proof of concept" auch auszuprobieren. |
||
Wie funktioniert UAF? Gibt es schon frei verfügbare Demo(apps)? |
|||
Links: |
Links: |
||
* [https://fidoalliance.org/specifications/download/ Specifications] |
|||
* [https://github.com/Yubico/pam-u2f pam-u2f] |
* [https://github.com/Yubico/pam-u2f pam-u2f] |
||
* [https://github.com/bluecmd/openssh-u2f openssh-u2f] |
* [https://github.com/bluecmd/openssh-u2f openssh-u2f] |
||
Mentor: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller] |
Mentor: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller] |
||
==Sichere Wiki-Konfiguration / Migration == |
|||
Ein Wiki ist seiner Natur nach ein offenes System, in welchem der "Mitmachgedanke" weit vorne steht. Leider gibt es dann doch häufig automatisierte Angriffe, die diese Eigenschaft ausnutzen. So fand sich auch in unserm Wiki viel SPAM. |
|||
Versuchen Sie eine Kopie unseres Wikis auf eine aktuelle Codebasis zu heben. Dokumentieren Sie Ihre einzelnen Schritte. Treffen Sie eine begründete Auswahl an Zusatzpaketen zur Integration von Formeln, Bildern, ... und versuchen Sie eine möglichst sichere Konfiguration zu erreichen. Ansatzpunkte könnten die Verwendung von Captchas, sowie Beschränkungen zum anlegen von Nutzeraccounts sein. |
|||
Mentor: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller], [https://sar.informatik.hu-berlin.de/people/wolfgang_gandre.htm Wolfgang Gandre] |
|||
Line 142: | Line 288: | ||
* [https://www.stunnel.org/index.html stunnel] |
* [https://www.stunnel.org/index.html stunnel] |
||
Mentoren: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller], [https://www.informatik.hu-berlin.de/de/forschung/gebiete/sar/people/sombrutz Robert Sombrutzki] |
|||
==BSI TR-03108 Sicherer E-Mail-Transport== |
|||
==Smartcards@SUNray== |
|||
Die Technische Richtlinie "Sicherer E-Mail-Transport" (BSI TR-03108) definiert konkrete Anforderungen an einen E-Mail-Diensteanbieter (EMDA). Ziel der Technischen Richtlinie ist die Erhöhung der Vergleichbarkeit und Verbreitung sicherer E-Mail-Kommunikation. Ziel bei diesem Thema ist es zu schauen, welche Schutzmaßnahmen für unseren Informatik-Mail-Server umgesetzt werden können. Hierbei geht es vor allem um technische Maßnahmen zur Absicherung eines authentischen und vertraulichen E-Mail-Transports. |
|||
Wie Sie ja vielleicht schon bemerkt haben, kann man gewisse Smartcards zur Identifizierung einer bestehenden Session auf einem SUNray nutzen und diese dann später wieder an einem anderen Terminal (oder auch dem gleichen) auf den Schirm holen (keine Sorge, Nutzername/Passwort werden noch zum Login benötigt). Dies funktioniert mit gewissen Kartentypen (Siehe condor:/etc/opt/SUNWut/smartcard). Versuchen Sie zusätzliche Konfigurationsfiles zu schreiben, die in Deutschland verbreitete kontaktbehaftete Smartcards (eGK, EC-Card) zu diesem Zweck nutzen. |
|||
Die im RFC 6698 beschriebene "DNS-Based Authentication of Named Entities (DANE)" scheint ein gutes Mittel zu sein, um jenseits von bestehenden PKI-Mechanismen eine starke Authentisierung eines Servers und spätere Absicherung der Verbindung über SSL/TLS ausgehend von dessen DNS-Namen zu erreichen. Versuchen Sie dieses Konzept für unseren Institutsmailserver umzusetzen. Bezüglich DANE gibt es bereits Vorarbeiten aus dem letzten Jahr [[DANE für unseren Mail-Server]]. |
|||
[https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller] |
|||
Hinsichtlich der umsetzbaren organisatorischen und physischen Sicherheitsmaßnahmen wird es sicherlich Unterschiede zu gewerblichen E-Mail-Dienste-Anbietern geben, jedoch ist es sicherlich interessant, was sich an technischen Schutzmechanismen am Institut umsetzen lässt oder schon so in Betrieb ist. |
|||
Links: |
|||
==Sichere Wiki-Konfiguration / Migration == |
|||
* [https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr03108/index_htm.html TR-03108] |
|||
Ein Wiki ist seiner Natur nach ein offenes System, in welchem der "Mitmachgedanke" weit vorne steht. Leider gibt es dann doch häufig automatisierte Angriffe, die diese Eigenschaft ausnutzen. So fand sich auch in unserm Wiki viel SPAM. |
|||
* [http://www.heise.de/ct/heft/2014-11-DANE-verbessert-sicheren-Transport-zwischen-Mailservern-2228494.html C't 11/14 Geleitschutz: DANE verbessert sicheren Transport zwischen Mailservern] |
|||
* [http://tools.ietf.org/html/rfc6698 RFC 6698 DANE] |
|||
* [http://www.ietf.org/rfc/rfc4033.txt RFC 4033 DNSsec] |
|||
Mentor: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller] |
|||
Versuchen Sie eine Kopie unseres Wikis auf eine aktuelle Codebasis zu heben. Dokumentieren Sie Ihre einzelnen Schritte. Treffen Sie eine begründete Auswahl an Zusatzpaketen zur Integration von Formeln, Bildern, ... und versuchen Sie eine möglichst sichere Konfiguration zu erreichen. Ansatzpunkte könnten die Verwendung von Captchas, sowie Beschränkungen zum anlegen von Nutzeraccounts sein. |
|||
Mentor: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller], [https://sar.informatik.hu-berlin.de/people/wolfgang_gandre.htm Wolfgang Gandre] |
|||
==[[Email-Push-Notifikation]]== |
|||
Zunehmend wird Email auch von unterwegs auf mobilen Geräten gelesen. Dabei ist es sicherlich interessant, wie ein Smartphone mitbekommt, dass es für seinen Besitzer eine oder mehrere neue Emails gibt. Die naive Lösung ist das über einen "pull"-Zugriff zu lösen. Das Smartphone würde also in regelmäßigen Abständen sich über SSL/TLS bei unserem Institutsserver mit dem Nutzeraccount einloggen und schauen, ob es für den Nutzer neue Email gibt. |
|||
==AeroFS überwachen== |
|||
Möchte ein Nutzer schnell erfahren, dass neue Email da sind, wir das Verfahren recht schnell aufwendig und nimmt die Batterie recht in Anspruch. |
|||
Der "nicht-Cloud-Speicher" AeroFS speichert im Gegensatz zu Diensten wie Dropbox oder Wuala die Daten ausschließlich auf den eigenen Rechnern und synchronisiert zwischen diesen via LAN oder Internet verschlüsselt. Jedenfalls wird das behauptet. Man könnte sich anschauen, inwiefern es möglich ist, dieses Versprechen zu überprüfen. |
|||
Etwas moderner ist sicherlich die Verwendung von imap-idle. Jedoch muss auch hier die Mail-App auf dem Telefon laufen und die TCP-Verbindung offen halten. Allerdings können mehrfache SSL/TLS-Handshakes vermieden werden. Schöner wäre es, wenn der Mailserver die Benachrichtigung via push-Nachricht über ein Gateway (Apple|Google) dem Betriebssystem des Smartphones mitteilt, dass neue Email da ist, also den für das jeweilige Mobile-OS gedachten Standardweg nutzt. |
|||
Wäre imap-notify eine Alternative? |
|||
* https://www.aerofs.com/ |
|||
Untersuchen sie die Möglichkeiten für die Umsetzung mit IMAP (dovecot) für iOS oder ggf. auch Android. |
|||
Links: |
|||
* [https://github.com/st3fan/dovecot-xaps-daemon xaps-daemon] |
|||
* [http://www.dovecot.org/ dovecot] |
|||
* Pushbullet |
|||
Anleitung: |
|||
* [[PushNotification]] |
|||
Mentor: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller] |
|||
==Smartcards@SUNray== |
|||
Wie Sie ja vielleicht schon bemerkt haben, kann man gewisse Smartcards zur Identifizierung einer bestehenden Session auf einem SUNray nutzen und diese dann später wieder an einem anderen Terminal (oder auch dem gleichen) auf den Schirm holen (keine Sorge, Nutzername/Passwort werden noch zum Login benötigt). Dies funktioniert mit gewissen Kartentypen (Siehe condor:/etc/opt/SUNWut/smartcard). Versuchen Sie zusätzliche Konfigurationsfiles zu schreiben, die in Deutschland verbreitete kontaktbehaftete Smartcards (eGK, EC-Card) zu diesem Zweck nutzen. |
|||
[https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller] |
|||
Latest revision as of 09:32, 22 September 2017
Vorträge
Freitag 14.10. 2016, Rudower Chaussee 25, Haus 3, Raum 3'101
10:00-10:45 | Location Sharing | Andreas, Fabio, Simon | |
10:45-11:45 | Sichere Webserver(konfiguration) | Daniel, Florian, Oliver, Max | |
11:45-12:30 | Mittagspause | ||
12:30-13:15 | LANGSEC | Marco, Jan, Arthur | |
13:15-14:45 | Cold Boot Attack | Mike, Alex, Benni, Lucas | |
14:45-15:00 | Kekse / Getränke | ||
15:00-15:30 | Smartcardemulation@Watch | Jan-Christopher | |
15:30-16:15 | Installer für virtuellen Smartcardleser für Windows | Nick, Jens, Lennart | |
16:15-16:30 | Zusammenfassung, Auswertung | Wolf Müller |
Pro Gruppe ist angedacht: Mindestens 30 Min und mindestens (#Mitglieder) * 15 Min (+ ggf. Demo) zwischen Redezeit und Diskussion und Umbaupause aufzuteilen.
Themen für IT-Security Workshop 4. bis 14. Oktober 2016
Sichere SSL/TLS-Konfiguration im Allgemeinen
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 und behalten Sie dabei auch die Performance im Auge. Könnte die Nutzung von ECC hier weiter helfen? Wenn noch Zeit ist stellen Sie ggf. "handshake"-Zeiten gegenüber.
Links:
Mentor: Wolf Müller
Sicheres SSL/TLS für Legacy
Während bei aktueller Software die Chancen recht gut sind, dass noch starke Ciphersuites zur Verfügung stehen, ist es mit Altanwendungen ungleich schwerer, diese zu ertüchtigen. Versuchen Sie beispielsweise für einen Microsoft IIS 6.0 nach außen eine starke Verschlüsselung nachzurüsten.
Links:
Mentor: Wolf Müller
Die Zukunft TLS 1.3
Wo geht die Reise in der Standardisierung hin? Weniger Optionen, schnellerer Handshake, schneller Transport. Gibt es bereits erste Implementierungen des neuen Standards? Was gibt OpenSSL 1.1.* her.
Links:
Mentor: Wolf Müller
Post Quantum Crypto
Praktische Implementierungen --> Google, Chrome
Mentor: Wolf Müller
Sicheres OpenVPN
OpenVPN ist eine gute Möglichkeit, seine Kommunikation durch öffentliche Netze abzusichern oder sich logisch in die HU oder in das Institut für Informatik zu begeben. Untersuchen Sie, wie diese Verbindungen (hu-berlin.ovpn und am Institut) konfiguriert sind, und welche Verbindungen zwischen Server und Client ausgehandelt werden. Hierbei gibt es zu beachten, dass es OpenVPN eine Kontrollverbindung zur Authentisierung und Schlüsselvereinbarung und eine Datenverbindung zum sicheren Transport der eigentlichen Daten nutzt. Für einen aktuellen OpenVPN-Clienten kann man die die Möglichkeiten für eine TLS-Absicherung der Kontrollverbindung mit openvpn --show-tls
und die Absicherungsmöglichkeiten der Datenverbindung mit openvpn --show-cipher
einsehen. Versuchen Sie eine effiziente, starke und auch möglichst interoperable Konfiguration zu erstellen, die mit aktueller Software den Zugriff unter Linux, Mac, Windows, iOS und Android gestattet. Verschaffen Sie sich einen Überblick. Welche Vor- / Nachteile haben die Modi CBC, CFB, CFB1, CFB8, OFB und was bewirken diese überhaupt?
Links:
Mentoren: Wolf Müller, Robert Sombrutzki
Sichere Webserver(konfiguration)
[Daniel, Florian, Oliver, Max]
Nachdem wir uns im Rahmen der obigen Themen Kenntnisse erworben haben, wie möglichst sichere SSL/TLS-Verbindungen erreicht werden können ist das Thema "sicherer Webserver" damit noch nicht erledigt, sondern es muss auch sichergestellt werden, dass möglichst alle Daten auch unter SSL/TLS ausgeliefert werden und das Zertifikat und damit der öffentliche Schlüssel authentisch sind. Mozilla hat mit Observatory eine Test-Suite bereitgestellt, mit der viele Aspekte untersucht werden können. Stichworte sind hier:
- CSP
- HTTP Public Key Pinning
- X-Frame-Options
- X-XSS-Protection
Testen Sie exemplarisch einige Webserver in der Informatik und versuchen Sie ein Konzept zur Beseitigung dieser Schwachpunkte zu erarbeiten. Dabei ist es sicher hilfreich, auch Tests nichtöffentlicher Server zu ermöglichen, was eine eigene lokale Installation der Testsuite erfordert.
Links:
Mentoren: Wolf Müller, Petra Kämpfer
Installer für virtuellen Smartcardleser für Windows
[Nick, Jens, Lennart]
Die Android-App [ https://frankmorgner.github.io/vsmartcard/remote-reader/README.html "Remote Smart Card Reader"] erlaubt die Nutzung eines geeigneten NFC-Smartphones als kontaktlosen Kartenleser an einem PC. Die Aufgabe des Projektteams ist die Erstellung eines Windows-Installers für den dazugehörigen virtuellen Smartcard-Leser.
Mentor: Frank Morgner
Smartcardemulation@Watch
[Jan-Christopher]
Im Android-Betriebssystem ist seit einigen Versionen die Möglichkeit der "host card emulation" HCE, also mit geeigneten Smartphones mit NFC-Schnittstelle eine kontaktlose Smartcard gegenüber einem Lesegerät zu emulieren, vorhanden. Noch bequemer wäre es, wenn bei der Nutzung das Telefon in der Tasche bleiben könnte und statt dessen eine HCE-fähige Smartwatch zur Präsentation gegenüber dem Leser verwendet wird. Konkret soll die eigentliche Emulation auf einem Android-Smartphone erfolgen, die Präsentation an einer über Bluetooth gekoppelten Samsungs "Gear S2" Uhr.
Die Aufgabe des Projektteams ist es, das emulierte Smartcard-Betriebssystem im Smart Card Emulator durch die NFC-Schnittstelle der Gear S2 zugreifbar zu machen, so dass die Smartwatch als "Antenne" für die Android-App fungiert. Wesentliche Vorarbeit wurde bereits in einem Branch geleistet.
Links:
Mentor: Frank Morgner
Portierung von vorhandenen Smartcard-Anwendungen auf Android
Mit SEEK for Android gibt es ein sehr umfangreiches Framework, um herkömmliche Smartcard-Anwendungen auf Android zu verwenden. Jedoch ist das Framework zu komplex und ressourcenhungrig für einfache Anwendungen. Aufgabe für die Projektgruppe ist das folgende Nutzungsszenario zu realisieren.
.-Smartphone-----------------------------------------------------------------. | | | Smartcard-Anwendung <--(PC/SC)--> libpcsclite <--(TCP)--> Android-App <--(NFC)-->Smartcard | | | | | `--------- | --------------------------- | ---------------------- | ---------' | | | |-----------------------------' | .----------|----------. .--------|-------------. | Geschrieben in C | | Geschrieben in Java | `---------------------' `----------------------'
Die Smartcard-Anwendung könnte z.B. OpenSC sein. libpcsclite ist aus diesem Projekt zu verwenden. Die Android App wäre zu erstellen und müsste eine kontaktlose Chipkarte ansprechen sowie die Schnittstelle zu o.g. libpcsclite implementieren
Links:
Mentor: Frank Morgner
Privacy@Home
Das IoT steht vor der Tür. Zunehmend begehren technische Geräte (Fernseher, DVD-Player, Heizung, ...) Zugang zu unserem Heimnetzwerk. Auf der einen Seite lassen sich natürlich neue gewollte Komfortfunktionen realisieren auf der anderen Seite stellen diese Geräte aber eine potenzielle Bedrohung für unser Heimnetz und unsere Privatsphäre da. Wie kann man diese Geräte in dem was sie tun können begrenzen. Versuchen Sie den Zugriff auf das Heimnetz von diesen Geräten aus und den Zugriff auf und aus dem Internet unter Beteiligung dieser zu limitieren. Exemplarisch soll dazu eine Fritz!Box 7390 Verwendung finden. Sichworte: Gastnetz, Filter, .... Wie authentifizieren Sich Geräte gegenüber ihrem Netzwerk und wie verlässlich ist diese Information? Welche URLs nutzen Ihre Heimgeräte legitim, welche waren unerwartet?
Links:
Mentor: Wolf Müller
Location Sharing
[Andreas, Fabio, Simon]
Die Möglichkeit seinen eigenen Standort mit anderen zu teilen ist in einigen Szenarien praktisch, erfordert allerdings einen guten Schutz der sensiblen Daten vor Dritten. Dieses Thema beschäftigt sich mit dem Entwurf eines Systems, das zunächst die durch mobile Clients auf der Plattform iOS ermittelten Standortdaten ohne notwendiges Vertrauen an einen Server übermittelt. Der Server übernimmt die Weiterleitung dieser Daten an den Anfragenden.
Interessant ist dabei die Sicherheit des Systems, insbesondere die durch Verschlüsselung erreichte Ende-zu-Ende-Vertraulichkeit der Übertragung. Ein weiterer Fokus wird darauf gelegt, keine identifizierende Daten erheben zu müssen, um eine Pseudonymität der Nutzer sicherzustellen und gleichzeitig die gewünschte Funktionalität zu gewährleisten.
Ausblick
Zur Erzielung einer weitgehenden Plattformunabhängigkeit wäre eine Implementation unter Android wünschenswert.
Interessant wäre eine Untersuchung, inwieweit das Kommunikationsprotokoll so modifiziert werden kann, dass eine Auswertung der Standortinformationen in gewissem Maße für den Server möglich wird, ohne jedoch die angestrebten Schutzziele abschwächen zu müssen. Auf diese Weise wäre es beispielsweise möglich, Standortdaten von sich nah beieinander befindlichen Nutzern serverseitig proaktiv an die entsprechenden Clients zu pushen.
Experimentell: Cold Boot Attack
[Mike, Alex, Benni, Lucas]
Ziel ist es eigentlich flüchtige Speicherinhalte durch die Nutzung von Kälte (in Gestalt von flüssigem Stickstoff) solange zu konservieren, dass sie bei unmittelbar an das Abschalten anschließenden Fremdbootvorgang noch (teilweise) ausgelesen werden können.
Links:
Mentor: Wolf Müller
"Grammatik"-basiertes Fuzzing
Fuzzing ist eine nützliche Technik, um Bugs zu finden. In letzter Zeit ist AFL sehr beliebt, vom Ansatz her ist es aber eher für Binärformate als für Textformate geeignet. Eigene simple Tests zum Grammatik-basierten Fuzzen von Lua mit Lua waren vielversprechend ((1), (2)), der erste Bug wurde in wenigen Minuten gefunden. (AFL lief über eine Woche ohne einen einzigen Bug zu finden.) Durch Erweitern der Grammatik & Generierung um etwas Semantik (außerhalb von Schleifen kein "break" generieren usw.) und Beschreibung der Funktionen der stdlib in der Grammatik konnte nochmal einiges mehr erreicht werden. ((3), (4) mit Beispiel, (5))
Hier könnte z.B. die Implementierung verbessert werden (mehr Semantik-Infos tracken, besserer Zufall, ...) oder Grammatiken für andere Sprachen oder Dateiformate gebaut & andere Programme getestet werden. Auch eine Anleitung "Wie präpariere ich ein Programm zum (relativ) sicheren & effektiven Fuzzen?" wäre vmtl. ein nützliches Resultat.
Links:
LANGSEC (language-theoretic security)
[Marco, Jan, Arthur]
LANGSEC ((1), Kernthesen: (2)) ist eine aus Exploit-Praxis und theoretischer Informatik motivierte Sicht auf Hacking. Im Kern steht die Erkenntnis, dass der Eingaben verarbeitende Teil eines Programms effektiv ein Interpreter ("weird machine") mit einer durch seine Implementierung bestimmten Funktionalität ist. Die Eingabe eines Programms (Dateien/Pakete) kann als "Programm" für dieses bzw. die durch es implementierte "weird machine" aufgefasst werden. Das durch den Parser zur Verfügung gestellte Berechnungsmodell (von Finite State Machine über zusätzliche Stack(s) oder andere Erweiterungen bis hin zu einem Turing-Maschinen-Äquivalent) ist in Verbindung mit Funktionalität, die aus dem Parser heraus zugänglich ist (Speicherallokation, öffnen/lesen/schreiben anderer Dateien, ...) durch geeignete Konstruktion der Eingaben programmierbar.
In die eine Richtung lassen sich hieraus klare Richtlinien für das Design von Datenformaten und Protokollen ablesen, die Hacking erschweren. In die andere Richtung ergibt sich eine interessante Angriffsperspektive, die auch abseits von Dateiformaten interessante Ergebnisse liefert. (Es stellte sich z.B. heraus, dass z.B. ELF-Metadaten (3) oder auch die MMU (4) turing-complete sind.)
Hier wäre die Analyse weiterer Datenformate oder auch Hardwarekomponenten interessant. Eine konkrete Idee wäre z.B. sich einen Überblick über den Aufbau verschiedener Bildformate zu schaffen, diese in Komplexitätsklassen einzuordnen und ggf. Implementierungen der fehleranfälligeren Formate an den im ersten Schritt als interessant identifizierten Stellen zu analysieren.
Links:
FIDO UAF|U2F (reloaded)
Im letzen Jahren haben wir uns bereits mit der 2-Faktorauthentisierung gemäß U2F FIDO beschäftigt. Diese ist aus unserer Sicht eine sehr interessante Authentisierungstechnik, die ein hohes Maß an Anonymität, Sicherheit und Komfort miteinander verbinden kann. Der ursprüngliche Fokus von U2F lag in der Authentisierung gegenüber Webdiensten. Aber natürlich ist es auch denkbar U2F-Token zur Authentisierung in anderen Kontexten (PAM, SSH, GIT, ...) zu nutzen. Versuchen Sie einen Überblick zu gewinnen, für welche Protokolle oder Szenarien U2F genutzt werden können sollte und versuchen sie dies auch als "proof of concept" auch auszuprobieren. Wie funktioniert UAF? Gibt es schon frei verfügbare Demo(apps)?
Links:
Mentor: Wolf Müller
Sichere Wiki-Konfiguration / Migration
Ein Wiki ist seiner Natur nach ein offenes System, in welchem der "Mitmachgedanke" weit vorne steht. Leider gibt es dann doch häufig automatisierte Angriffe, die diese Eigenschaft ausnutzen. So fand sich auch in unserm Wiki viel SPAM.
Versuchen Sie eine Kopie unseres Wikis auf eine aktuelle Codebasis zu heben. Dokumentieren Sie Ihre einzelnen Schritte. Treffen Sie eine begründete Auswahl an Zusatzpaketen zur Integration von Formeln, Bildern, ... und versuchen Sie eine möglichst sichere Konfiguration zu erreichen. Ansatzpunkte könnten die Verwendung von Captchas, sowie Beschränkungen zum anlegen von Nutzeraccounts sein.
Mentor: Wolf Müller, Wolfgang Gandre
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 es essenziell, dass sich bei dem mountenden Clienten wirklich um den beabsichtigten legitimen Rechner handelt. Der Normalfall ist eine simple Überprüfung der IP-Addresse, 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.
Links:
Mentoren: Wolf Müller, Robert Sombrutzki
BSI TR-03108 Sicherer E-Mail-Transport
Die Technische Richtlinie "Sicherer E-Mail-Transport" (BSI TR-03108) definiert konkrete Anforderungen an einen E-Mail-Diensteanbieter (EMDA). Ziel der Technischen Richtlinie ist die Erhöhung der Vergleichbarkeit und Verbreitung sicherer E-Mail-Kommunikation. Ziel bei diesem Thema ist es zu schauen, welche Schutzmaßnahmen für unseren Informatik-Mail-Server umgesetzt werden können. Hierbei geht es vor allem um technische Maßnahmen zur Absicherung eines authentischen und vertraulichen E-Mail-Transports.
Die im RFC 6698 beschriebene "DNS-Based Authentication of Named Entities (DANE)" scheint ein gutes Mittel zu sein, um jenseits von bestehenden PKI-Mechanismen eine starke Authentisierung eines Servers und spätere Absicherung der Verbindung über SSL/TLS ausgehend von dessen DNS-Namen zu erreichen. Versuchen Sie dieses Konzept für unseren Institutsmailserver umzusetzen. Bezüglich DANE gibt es bereits Vorarbeiten aus dem letzten Jahr DANE für unseren Mail-Server.
Hinsichtlich der umsetzbaren organisatorischen und physischen Sicherheitsmaßnahmen wird es sicherlich Unterschiede zu gewerblichen E-Mail-Dienste-Anbietern geben, jedoch ist es sicherlich interessant, was sich an technischen Schutzmechanismen am Institut umsetzen lässt oder schon so in Betrieb ist.
Links:
- TR-03108
- C't 11/14 Geleitschutz: DANE verbessert sicheren Transport zwischen Mailservern
- RFC 6698 DANE
- RFC 4033 DNSsec
Mentor: Wolf Müller
Email-Push-Notifikation
Zunehmend wird Email auch von unterwegs auf mobilen Geräten gelesen. Dabei ist es sicherlich interessant, wie ein Smartphone mitbekommt, dass es für seinen Besitzer eine oder mehrere neue Emails gibt. Die naive Lösung ist das über einen "pull"-Zugriff zu lösen. Das Smartphone würde also in regelmäßigen Abständen sich über SSL/TLS bei unserem Institutsserver mit dem Nutzeraccount einloggen und schauen, ob es für den Nutzer neue Email gibt. Möchte ein Nutzer schnell erfahren, dass neue Email da sind, wir das Verfahren recht schnell aufwendig und nimmt die Batterie recht in Anspruch. Etwas moderner ist sicherlich die Verwendung von imap-idle. Jedoch muss auch hier die Mail-App auf dem Telefon laufen und die TCP-Verbindung offen halten. Allerdings können mehrfache SSL/TLS-Handshakes vermieden werden. Schöner wäre es, wenn der Mailserver die Benachrichtigung via push-Nachricht über ein Gateway (Apple|Google) dem Betriebssystem des Smartphones mitteilt, dass neue Email da ist, also den für das jeweilige Mobile-OS gedachten Standardweg nutzt.
Wäre imap-notify eine Alternative?
Untersuchen sie die Möglichkeiten für die Umsetzung mit IMAP (dovecot) für iOS oder ggf. auch Android.
Links:
- xaps-daemon
- dovecot
- Pushbullet
Anleitung:
Mentor: Wolf Müller
Smartcards@SUNray
Wie Sie ja vielleicht schon bemerkt haben, kann man gewisse Smartcards zur Identifizierung einer bestehenden Session auf einem SUNray nutzen und diese dann später wieder an einem anderen Terminal (oder auch dem gleichen) auf den Schirm holen (keine Sorge, Nutzername/Passwort werden noch zum Login benötigt). Dies funktioniert mit gewissen Kartentypen (Siehe condor:/etc/opt/SUNWut/smartcard). Versuchen Sie zusätzliche Konfigurationsfiles zu schreiben, die in Deutschland verbreitete kontaktbehaftete Smartcards (eGK, EC-Card) zu diesem Zweck nutzen.
- Weitere kreative Vorschläge sind willkommen!
- Viel Erfolg!
- Kontakt: Wolf Müller