Der Security-Adventskalender

Türchen Nummer 24: Die Weihnachtsfeier

Christoph: Hmmh, eigentlich haben wir jetzt gar nichts vorbereitet. Was machen wir denn jetzt da?

Lucas: Ja, ist ja Weihnachten. Da könnten wir ja was verschenken. Oder, Christoph?

Christoph: Das wäre aber etwas zu einfach. Außerdem haben wir so viele Hörerinnen und Hörer. Da können wir jetzt nicht jedem was schenken. Da sind wir ja pleite. Vielleicht sollten wir eine kleine Hacker-Challenge machen.

Lucas: Das ist eine gute Idee.

Christoph: Ja, dann aber mehr so wie in den Filmen, ein bisschen spektakulärer. Und nicht so, wie es in echt läuft.

Christoph: Dann starten wir die Challenge jetzt doch einfach. Und zwar mit einem Gedicht.

Anja: Von draus vom Internet komm ich her, ich muss Euch sagen, ein Rätsel muss her! Allüberall von Berlin bis nach Bitzen, seh ich fleißige Rätsler:innen sitzen. Und nun hört alle aufmerksam zu, dann löst Ihr dies Rätsel fast im Nu.

Lisa: Die URL so muss es sein, ist eine INNOQ-Subdomain. Doch welche, das gilt es zu enthexen, bevor wir lustig mit Gewinnen klecksen. 61 63 32 30 32 31 0a, ist das nicht einfach unglaublich super und wunderbar?

Sonja: Doch auf der Seite angekommen, ist der Berg noch nicht erklommen. Am 29. November ist eine Folge erschienen, sie wird Euch beim Lösen des Rätsels dienen. Eine App, die wurde dort genannt, habt sie am besten gleich zur Hand.

Stefanie: Doch die App ist nicht Euer einziger Favorit, dort ist ein Code, den man nicht gleich sieht, QR - so heißt er ganz genau, ihn scannen wäre jetzt sehr schlau! Tragt die einmaligen Zahlen geschwind ein, vielleicht wird der Gewinn dann bald Euer sein.

Robert: Das war doch ein herzerwärmendes Gedicht von meinen lieben Kollegys. Hier ist gerade der Schnee geschmolzen. Wenn Ihr es bis hierhin geschafft habt – wir hoffen, dass Ihr es geschafft habt – dann gibt es auch etwas zu gewinnen für Euch. Jetzt aufpassen: Und zwar verlosen wir zum Jahresende und mit dem Schließen des letzten Türchens, einen Platz in unserer Online-Schulung, nämlich dem iSAQB Advanced Level Web-Security. Wenn Ihr teilnehmen möchtet, dann guckt mal in die Shownotes. Da stehen alle Teilnahmebedingungen und da steht genau, was Ihr tun müsst. Außerdem findet Ihr dieses herzerwärmende Gedicht auch nochmal in den Shownotes, falls Ihr es Euren Verwandten vorlesen möchtet am Heiligen Abend.

Christoph: Das war’s von uns für dieses Jahr.

Lucas: Wir gehen jetzt in die Winterpause.

Anja: Wir versuchen uns in dieser Zeit gut zu erholen,

Lisa: um nächstes Jahr wieder für Euch da zu sein.

Sonja: Wir wünschen Euch erholsame und ruhige Feiertage

Stefanie: und einen guten Rutsch ins neue Jahr.

Robert: Tschüss

Türchen Nummer 23: Nichts ist so wie es scheint

Die Cineasten unter Euch haben es vielleicht schon erkannt. Heute geht es um Filme, Serien und Dokumentationen, die sich mit Hacking oder der Hacking-Subkultur befassen. Den Profis auf diesem Gebiet, aber oft auch schon den interessierten Laien, sträuben sich die Nackenhaare, wenn sie sehen, wie dort Hacking dargestellt wird. Wer kennt nicht die Szenen, bei denen eine Häckse oder ein Hacker vor einem Bildschirm mit einer Login-Maske sitzt, auf der Tastatur rumhämmert und nach wenigen Sekunden „Ich bin drin“ oder ähnliches rufen. Was soll das darstellen? Einen Brute-Force-Angriff, bei dem die Häckse/der Hacker Passwörter ausprobiert, mit einer Tippgeschwindigkeit von einer Billion Wörtern pro Sekunde? Mit der Realität hat das nicht viel zu tun. Die Film- und Serienmacher:innen greifen auf sowas zurück, weil echtes Hacking schwer in einem Bewegtbildmedium darstellbar ist und auch schnell öde und fad wirken kann. Das muss jedoch nicht zwangsläufig so sein. Spannende und realistische Darstellungen sind möglich. So taucht der Portscanner Nmap, den ihr aus Türchen 19 kennt, immer wieder in Filmen auf: von Matrix Reloaded, über Dredd oder das Bourne Ultimatum, bis hin zu Snowden. Andere Filme sind voll von Referenzen auf die Hackerkultur, wie z. B. „Hackers - Im Netz des FBI“. In diesem Film werden u.a. Teile des Hackermanifest rezitiert, welches erstmalig im Phrack-Magazin, Ihr erinnert euch an Türchen 11, veröffentlicht wurde und einer der bedeutendesten Texte der Hacking-Subkultur ist.

Glaubhafte Darstellung von Hacking und der Hacking-Subkultur ist natürlich kein Garant für einen guten Film oder eine gute Serie. Umgekehrt ist es auch nicht so, dass ein Film oder eine Serie, bei der Hacking völlig realitätsfern gezeigt wird, unbedingt schlecht sein muss. Ein guter Indikator ist das aber schon. Gerade für ein Publikum mit etwas Vorbildung in diesem Bereich.

In der Weihnachtszeit und zwischen den Jahren hat man oft ein wenig mehr Zeit, um Filme und Serien zu schauen. Deshalb haben wir für Euch jeweils 3 Tipps für Filme, Serien und Dokumentationen zusammengestellt. Diese und noch ein paar mehr wie auch einige Negativbeispiele findet Ihr in den Shownotes.

Zuerst unsere Tipps für Filme:

• 23 - Nichts ist so, wie es scheint
• Sneakers - Die Lautlosen
• The Social Network

Jetzt unsere Tipps für Serien:

• Mr. Robot
• Halt and Catch Fire
• The Billion Dollar Code

Zum Schluss noch unsere Tipps für Dokumentationen:

• Alles ist eins. außer der 0.
• Citizenfour
• We Steal Secrets: The Story of WikiLeaks

Türchen Nummer 22: Shodan

Hast Du Dich auch schon mal gewundert, woher die Zahl X kommt, wenn du in der einschlägigen IT-Presse Meldungen liest – etwa, dass X ungesicherte MongoDB Instanzen im Netz zu finden sind. In vielen Fällen ist die Antwort: die Zahl kommt aus der Suchmaschine Shodan.

In Türchen 19 hast du Portscanning kennengelernt. Bei Shodan ist Portscanning ein Teil des Geschäftsmodells. Shodan sammelt Daten über Systeme die mit dem Internet verbunden sind. Neben den Daten, die mittels Portscans gefunden werden können, auch noch vieles mehr, z. B. den geografische Standort, verbundene Organisationen wie den Hoster, oder um welche Art von System es sich handelt: Server, Webcam oder Atomkraftwerk. Wegen der teils spektakulären Ergebnisse, in welcher Suchmaschine findet man sonst Ampeln, Kraftwerke und Herzmonitore, ist Shodan auch immer wieder selbst Thema der Berichterstattung.

Shodan ist die ideale Suchmaschien für Sicherheitsforscher:innen. Begonnen hatte sie als Hobbyprojekt, inzwischen ist sie allerdings vollständig professionalisiert. Die meisten Funktionen sind nur in den verschiedenen Abo-Modellen verfügbar. Als Nebeneffekt bietet das einen kleinen Schutz gegen Script-Kiddies, die den finanziellen Aufwand zumeist scheuen.

Unser Tipp heute: Shodan ist die einzige Suchmaschine, für die du kein SEO betreiben solltest. Denn: in deren Trefferliste willst Du nicht weit oben landen.

Türchen Nummer 21: Loveletter

Heute möchten wir uns mit einer fast vergessenen Spezies befassen… dem Kettenbrief. Wer im Jahr 2000 eine E-Mail mit dem liebevollen Betreff „ILOVEYOU“ erhalten hat, bekam den ersten Computerwurm, über den weltweit berichtet wurde, per Mail zugestellt. Neben dem Namen „Loveletter“, wurde in den Medien auch von „I-love-you“ oder dem „Love Bug“ berichtet. Der Wurm war technisch nicht besonders ausgefeilt. Er war in Visual Basic Script geschrieben, einer von Microsoft entwickelte Skriptsprache, die es auch weniger computeraffinen Personen erlauben sollte zu Programmieren. Die Person hinter dem Wurm hat dies verschleiert, und die VBS-Datei „LOVE-LETTER-FOR-YOU.TXT.vbs“ genannt, was in den meisten Mailprogrammen dazu führte, das die Endung „vbs“ bei der Anzeige entfiel, sodass Mailempfänger:innen getäuscht wurden und dachten, es handele sich um eine harmlose Textdatei. Einmal geöffnet, machte der Wurm das, was Würmer so tun - er verbreitete sich rasant und verschickte sich von diesem infizierten Mailkonto an alle in der Kontaktliste befindlichen Personen - da hilft nicht einmal mehr die Warnung: „Öffne keine Mails von unbekannten Sender:innen“, denn die Sender:in war ja bekannt. Außerdem - und das war der entscheidene Faktor bei der explosionsartigen Verbreitung - wer öffnet nicht gerne einen Liebesbrief?

Doch die Weiterverbreitung via Mail war nicht das einzige Unheil, das der Wurm auf einem infizierten System anrichtete. Er versendete sich außerdem auch via IRC, dazu suchte er auf dem infizierten System nach dem IRC-Client mIRC, wurde er fündig, überschrieb er das „script.ini“ und sorgte damit dafür, dass alle, die den Channel betraten, in dem sich die infizierte Nutzer:in aufhielt, sogleich den Wurm zugesendet bekamen. War das schon alles, was der Wurm trieb? Nein! Auf der Festplatte und Netzlaufwerken tauschte er munter Dateien mit Dateiendungen wie beispielsweise JPEG oder PNG gegen sich selber aus, dabei behielt er den eigentlichen Dateinamen bei, änderte allerdings die Dateiendung auf „.vbs“. Du kannst dir vorstellen, wie viele Daten auf diese Weise verloren gingen und vermutlich auch, wie oft der Wurm dann erneut ausgeführt wurde. Doch das ist nicht genug des Übels. Beispielsweise wurde der Internet Explorer so manipuliert, dass er beim nächsten Start ein Trojanisches Pferd heruntergeladen und installiert hat, so wurden zahlreiche Daten des infizierten Rechners ausgespäht, unter anderem Passwörter und IP-Adresse. Neben den enormen persönlichen Schäden für die Nutzer:innen, wurden außerdem zahlreiche Mailserver überlastet, wegen der exponentiellen Ausbreitung von Loveletter.

Einen kleinen Lichtblick gab es nichtsdestotrotz, jedenfalls für Apple- und Linux-Nutzer:innen. Denn zur vollen Entfaltung von Loveletter waren einige Vorbedingungen von Nöten: es musste ein Windows-Rechner sein, am besten mit Microsoft Outlook, denn früher führte Outlook Anhänge automatisch aus. Zudem brauchte Loveletter die Installation des Windows Scripting Host, der jedoch in Windows 98 SE und Windows 2000 grundsätzlich enthalten war. Sollte ein System doch nicht alle Voraussetzungen erfüllen und noch ein fehlendes ActiveX-Steuerelement benötigen, so fragte der Wurm höflich danach, dies doch bitte nachzuinstallieren - wenn die Nutzer:in hier ablehnte, so kam die Meldung einfach sofort wieder. Loveletter wurde von Onel de Guzmán alias Spider, einem philippinischen Informatikstudenten, auf die Welt losgelassen. Trotz eines Schadens von geschätzten 10 bis 15 Milliarden Dollar wurde er weder angeklagt noch verurteilt, es gab auf den Philippinen einfach keine entsprechenden Gesetze. Höchstens Sachbeschädigung, aber dazu bedurfte es Vorsatz und Guzmán sagte einfach das, was wir bisher bei jedem Wurm-Türchen gehört haben: „Es war ein Versehen“. Zwei Monate später wurde ein Gesetz gegen das Programmieren von Malware erlassen. Viel später, im Jahr 2019, gab de Guzmán zu, dass er schlichtweg Passwörter stehlen wollte.

Zum Schluss noch eine vorweihnachtliche Botschaft an euch: WE LOVE YOU. Unsere vollständigen Grüße findest Du unter dem We-Love-You Link in den Shownotes. Evt. aufploppende Warnungen kannt Du einfach wegklicken. Ehrlich.

Türchen Nummer 20: Zero-Click-Angriffe

Ein Zero-Click-Angriff ist etwas, was dir besser nicht passieren sollte. Es handelt sich dabei um einen Angriff, bei dem keine Interaktion des Opfers nötig ist, wie es zum Beispiel beim Öffnen eines Anhangs in einer Phishing-Mail der Fall wäre. Dadurch, dass keine Interaktion nötig ist, und der Angriff im Regelfall gegen Endgeräte von Nutzer:innen wie etwa Mobiltelefone gerichtet ist, die in den seltensten Fällen auf Sicherheitsvorfälle überwacht werden, bleiben die Angriffe oft lange Zeit unentdeckt. Meistens werden die Endgeräte dabei trojanisiert, um das Opfer zu überwachen. Ein Zero-Click-Angriff beruht im Regelfall auf Sicherheitslücken in Komponenten des Netzwerkstacks oder in Parsern, die automatisch durchlaufen werden, wenn das System des Opfers eine Mail, eine SMS, eine Videonachricht o.ä. zugestellt bekommt. Da bekannt ist, dass diese Komponenten sicherheitskritisch sind und durchgängig nicht vertrauenswürdige Daten verarbeiten, laufen diese normalerweise abgesichert, z. B. in einer Sandbox. Deshalb sind für Zero-Click-Angriffe zumeist weitere Exploits für Sicherheitslücken in der Absicherung nötig, um die volle Kontrolle über die Systeme zu erlangen. Dieses Vorgehen wird Exploit-Chaining genannt. Weil mehrere Exploits gebraucht werden, die am besten alle auch noch – die aus Türchen Nummer 10 bekannten – Zero-Days sind, sind Zero-Click-Angriffe sehr teuer. Sie werden in der Regel nur von Akteuren, die über erhebliche finanzielle Mittel verfügen, eingesetzt, also z. B. von Staaten bzw. deren Geheimdiensten, aber auch von kriminellen Organisationen wie mexikanischen Drogenkartellen. In letzter Zeit war immer wieder die israelische NSO Group und ihre Spyware Pegasus in den Schlagzeilen. NSO stellt ausgefeilte Überwachungssoftware her und macht dabei ausgiebigen Gebrauch von Zero-Click-Angriffen. Nach eigenen Angaben sollen ihre Produkte nur für die Verhinderung von Terroranschlägen und schweren Verbrechen und unter Wahrung der Menschenrechte benutzt werden. Journalist:innen und zivilgesellschaftliche Organisationen wie das Citizenlab fanden allerdings heraus, dass Software von der NSO auch an repressive Regime verkauft wurde, welche diese dazu nutzten, Menschrechtsaktivist:innen, Journalist:innen und Politiker:innen anderer Staaten zu überwachen. Auch der ermordete Journalist Jamal Khashoggi und sein Umfeld soll mit NSO-Software ausspioniert worden sein. Arbeitest Du selber an Überwachungssoftware? Dann schau in dein Innerstes, und frage dich, ob du das wirklich verantworten kannst. Nicht jede:r muss ein Whistleblower wie Edward Snowden werden, es reicht schon, den Job zu wechseln und künftig Software zu schreiben, die das Gewissen nicht so belastet. Mit deinen Talenten brauchst du sicher nicht lange nach einem Job suchen.

Türchen Nummer 19: Klopf, Klopf. Wer lauscht dort? Portscanning und Portknocking

Eins der ersten Dinge, die eine Angreifer:in oder eine Penetrations-Tester:in machen wird, um verwundbare Systeme zu finden, ist ein Portscan. Was bedeutet das eigentlich? Ein Portscan ist das systematische Absuchen der Ports eines Hosts, um herauszufinden, ob diese offen sind, und wenn ja, welche Programme dort lauschen. Dazu wird ein sogenannter Portscanner verwendet, ein Programm welches diesen Vorgang automatisiert, indem es TCP und/oder UDP Pakete an die Ports schickt und die Antworten, soweit diese erfolgen, auswertet. Aktuelle Portscanner haben meistens darüber hinausgehende Funktionen. Beispielsweise kann das Programm ermittelt werden, welches auf einem Port lauscht, inklusive dessen genauer Version und der bekannten Sicherheitslücken dieser Version. Eine weitere Funktion ist das Auffinden und Identifizieren aller Hosts in einem Netzwerk, inklusive den darauf laufenden Betriebssystemen. Viele Portscanner lassen sich darüber hinaus skripten, sodass sie sich problemlos in andere Tools oder CI/CD-Pipelines einbinden lassen. Einer der ältesten, aber immer noch populärsten Portscanner, ist NMAP. Das liegt nicht nur daran, dass er vollgepackt mit Features ist, sondern auch extrem portabel und obendrein unter einer Open-Source Lizenz verfügbar ist. NMAP wurde erstmalig in dem, aus Türchen 11 bekannten, Phrack-Magazin vorgestellt. Der heute immer noch lesenswerte Artikel „The Art of Port Scanning“ aus dem Jahr 1997 über die verschiedenen Portscanning-Techniken hatte sogar den Quellcode zum Selbstkompilieren angehängt. Die Gründung von Plattformen wie Github & Co., auf denen man heute den Quellcode verteilen würde, lagen dort noch in weiter Zukunft. Selbst SourceForge, der Urahn von Github & Co, wurde erst zwei Jahre später gegründet. Portscans kann man heute kaum entgehen, sie laufen ständig und überall und sind wie eine Art Hintergrundrauschen im Netz. Mit auf Geschwindigkeit ausgelegten Portscannern wie ZMap kann der gesamte IPv4-Adressraum in knapp 5 Minuten gescannt werden – eine Leitung mit ausreichend Bandbreite vorausgesetzt. Eine Möglichkeit, dem Portscanning zu entgehen, ist das Portknocking. Hier öffnet ein Host erst den Port, wenn eine bestimmte Anzahl von Paketen in einem bestimmten Abstand dort ankommen. Wie ein geheimes Klopfzeichen. Um Replay-Angriffe durch passives Abhören zu verhindern, können auch kryptografisch gesicherte Informationen zur anfragenden Entität mitgeschickt werden, damit nur dieser Port geöffnet wird. Eine der bekanntesten Implementierungen ist knockknock von Moxie Marlinspike, dem Gründer von Signal und einer der Entwickler:innen des Signal-Protokolls. In dem lesenswerten README des Projekts, das leider nicht mehr gepflegt wird, werden die Probleme von einfachen Portknocking-Schemata und die Schwierigkeiten, die bei der Implementierung von Portknocking lauern, leicht verständlich beschrieben. Für den breiten Einsatz ist Portknocking nicht geeignet: Es gibt weder gängige Standards noch wird es in üblicher Netzwerk-Software unterstützt. Zudem brauchen die Kommunikationspartner:innen für sicheres Portknocking, gemeinsames geheimes kryptografisches Schlüsselmaterial. Falls du noch nie einen Portscan deiner Infrastruktur gemacht hast, dann wird es Zeit. In deine CI/CD-Pipeline eingebaut, ist es ein preiswerter, aber nicht zu verachtender Sicherheitsgewinn. Besser du erfährst es als erste Person, wenn eines deiner im Internet exponierten Systeme verwundbar ist.

Türchen Nummer 18: Creeper und Reaper - Fressen und gefressen werden

Was ein Wurm ist, hast Du schon bei Türchen Nummer 4 erfahren und einen der ersten Vertreter bei Türchen 14 kennen gelernt - den Morris-Wurm. Heute lernst Du das erste Anti-Wurmprogramm kennen. Wozu brauchte man ein Anti-Wurmprogramm? Na wegen des ersten Computerwurms. Dieser verbreitete sich bereits Anfang der 1970er Jahre im ARPANET, dem Vorfahren des heutigen Internets, und hieß Creeper. Dieser gilt als erste bekannte Malware überhaupt, die sich unkontrolliert im Netz ausbreitete. Creeper wurde, und das steht im Gegensatz zu den zweifelhaften Behauptungen des Morris-Wurm Schöpfers über selbigen, ziemlich sicher nicht aus böswilligen Absichten heraus entwickelt. Es sollte ein Sicherheitstest sein, der prüfen sollte, ob es möglich ist, ein Programm zu erzeugen, welches sich selbst vervielfältigt. Spoiler - es war möglich! Um schlimmeres zu verhindern, wurde ein Mechanismus eingebaut, der Creeper vom vorherigen Rechner löschte, wenn eine erneute Infizierung mit einem weiteren Rechner geglückt war. Leider hat das wegen eines Bugs nicht so funktioniert wie eigentlich geplant - ähnlich wie es später beim Morris-Wurm war. 1971 verbreitete sich Creeper erst im internen Firmennetz der Entwicklungsfirma und kurz darauf quer durch das ARPANET. Befallene Rechner ließen sich leicht identifizieren, denn auf dem Monitor wurde die Nachricht „I’m the Creeper: Catch me if you can!“ angezeigt. Um Creeper wieder los zu werden, wurde Reaper entwickelt. Das erste Malware-Bekämpfungsprogramm der Computergeschichte. Ironischerweise war Reaper, wie Creeper, auch ein Wurm. Allerdings kein bösartiger, sondern ein gutartiger, ein sogenannter helpful worm, oder auch, Achtung Nerd-Angeberwissen, Nematode genannt. Reaper verbreitete sich durch das Netzwerk, suchte nach Creaper, entfernte diesen vom infizierten System und entfernte wenig später auch sich selbst - zum Glück hatte Reaper keine Bugs wie Creeper oder Morris. Der Entwickler von Reaper, Ray Tomlinson, wurde später als Erfinder der E-Mail bekannt. Bis nach diesem Vorfall wieder ein Wurm sein Unwesen trieb, dauerte es ganze 16 Jahre. Im Jahr 1987 verbreitete sich der Wurm XMAS EXEC großflächig, ein Jahr später der Morris-Wurm. Wenn Du heute einen Wurm entwickelst, achte darauf, dass er dir nicht entwischt. Denn auch wenn du gute Absichten hegst und es ein Nematode sein sollte, ist es dennoch strafbar, da er ohne Erlaubnis in andere Computersysteme eindringt. Der Hackerparagraph aus Türchen Nummer 7 lässt grüßen.

Türchen Nummer 17: log4shell - der Security Super-Gau des Jahres

Vor genau einer Woche ist ein Zero-Day in der weit verbreiteten Java-Logging-Bibliothek log4j bekannt geworden: log4shell. Was ein Zero-Day ist, habt ihr bei Türchen Nummer 10 erfahren. Es ist der Security Super-Gau des Jahres, und wahrscheinlich die schlimmste Sicherheitslücke seit Heartbleed, die ihr in Türchen Nummer 2 kennengelernt habt. Höchstwahrscheinlich ist log4shell sogar schlimmer. Im Industriestandard für die Bewertung von Sicherheitslücken, dem Common Vulnerability Scoring System (CVSS), erhält log4shell eine 10 von 10. Worin besteht die Lücke? log4j unterstützt in Log-Nachrichten einen Lookup von Properties. Dabei werden Platzhalter, ein Dollarzeichen gefolgt von dem Namen der Property in geschweiften Klammern, durch den Wert einer Property ersetzt. Die Properties können dabei aus allen möglichen Quellen kommen. Auch das Java-Verzeichnissystem JNDI ist eine mögliche Quelle. Beim Lookup über JNDI wird vom angegebenen Endpunkt eine Java-Klasse als Property geladen. Hierbei wird der Deserialisierungs-Code der Klasse im selben Prozess wie log4j ausgeführt. Kann eine Angreifer:in die geladene Klasse kontrollieren, ist die Ausführung beliebigen Codes bei der Deserialisierung möglich. Wie kann aber eine Angreifer:in die geladenen Klassen kontrollieren? Das ist relativ einfach. Dazu muss die Angreifer:in lediglich einen Platzhalter mit einer Referenz auf einen, von ihr kontrollierten, Endpunkt in eine Log-Nachricht schmuggeln. Der Endpunkt liefert dann die kontrollierten Klassen aus. Und wie kann die Angreifer:in die Referenz in die Log-Nachrichten schmuggeln? Auch das ist meistens relativ simpel. Viele Daten, die ein Server entgegennimmt, werden geloggt. Und auch wenn die Daten vom Server abgelehnt werden, weil er sie nicht validieren kann, landen sie trotzdem oft im Log, da Validierungsfehler und die Daten, die dazu führten, typischerweise geloggt werden. Da die Logdaten normalerweise nicht direkt in einen Interpreter, sondern in einer Datei landen, durchlaufen sie auch kein Output Encoding bei dem z.B. der Platzhalter mit den passenden Escape-Zeichen versehen werden würde. Eine Angreifer:in muss nun einfach alle möglichen Daten, die an den Server gehen und von ihr manipuliert werden können, mit Platzhaltern versehen, in dem ein von ihr kontrollierter Endpunkt steht. Solche Daten gibt es zuhauf: Cookies, Pfade in URLs, HTTP-Header oder Formulare sind nur einige Beispiele, die in Webanwendungen vorkommen. Diese Sicherheitslücke ist besonders schlimm, da log4j so verbreitet ist. Nutzer:innen sind z.B. Apple, Amazon, Cloudflare, Cisco, Twitter, Tesla, Steam, Redhat und viele weitere mehr. Angriffe konnten im Nachhinein schon seit dem 1. Dezember identifiziert werden. Es ist davon auszugehen, dass schon auf einer Reihe von Servern Backdoors installiert wurden, die erst in nächster Zeit ausgenutzt werden, beispielsweise für Ransomware. Das BSI hat die Alarmstufe Rot ausgerufen. Die amerikanische Cybersecurity and Infrastructure Security Agency (CISA) hat mit dem FBI und der NSA eine Arbeitsgruppe gebildet, um die Lücke zu adressieren. Diese Lücke wird die IT-Welt noch eine ganze Zeit beschäftigen. Was könnt ihr tun? Entweder auf die abgesicherte Version 2.16.0 aktualisieren oder, falls das nicht möglich ist, den Lookup, der standardmäßig aktiviert ist, per Konfiguration abschalten. Wart ihr für die Lücke anfällig, solltet ihr zusätzlich eure Systeme sorgfältig auf eventuelle Kompromittierung hin analysieren. Habt ihr noch nicht log4j auf eine abgesicherte Version aktualisiert oder den Lookup per Konfiguration abgeschaltet, ist die Gefahr groß, dass ihr bereits gehackt wurdet oder in Kürze gehackt werdet, wenn ihr nicht sofort handelt. Worauf wartet ihr noch?

Türchen Nummer 16: Vorsicht Kamera! Daktylogramme in Gefahr

Du nutzt einen Fingerabdruck statt eines Passworts, um dein Smartphone oder deinen Rechner zu schützen? Du findest das bequem und sicher? Dann solltest du heute besonders gut zuhören. Fingerabdrucksensoren lassen sich zwar heutzutage nicht mehr durch einfache Fingerabdruckkopien täuschen, aber es gelingt immer wieder, Attrappen herzustellen, mit denen auch moderne Sensoren überlistet werden. Oft ist dafür der Aufwand nur sehr gering, wenn es erstmalig gelungen ist, einen Sensor zu überlisten und klar ist, wo dessen Schwachstellen liegen. Die Frage ist nur noch, wie kommt man an die Fingerabdrücke. Bereits 2008 hat der Chaos Computer Club ein Wasserglas des damaligen Bundesinnenministers Wolfgang Schäuble genutzt, um den darauf vorhandenen Fingerabruck sicherzustellen und in ihrem Hausmagazin „Datenschleuder“ zu veröffentlichen. Doch mittlerweile ist die Technik so weit, dass nicht einmal mehr ein physischer Gegenstand mit perfektem Abdruck von Nöten ist, um an den Fingerabdruck einer Zielperson zu kommen. In einem Vortrag auf der 31c3 in 2014 zeigte der Hacker Starbug, dass es möglich ist, von Fotografien aus bis zu sieben Metern Entfernung Fingerabdrücke zu rekonstruieren. Bei Ursula von der Leyen wurde bei einer Bundespressekonferenz ein Fingerabdruck durch eine Fotografie aus drei Metern Entfernung gewonnen. Bedenkt man, dass dies bereits sieben Jahre zurück liegt, sollte man sich klar darüber sein, dass mittlerweile mit Sicherheit größere Entfernungen möglich sind. Im selben Vortrag berichtete Starbug außerdem von hochauflösenden Iris-Bildern oder anderen Aufnahmen, um andere biometrische Verfahren wie Iriserkennung oder Gesichtserkennung zu überlisten. Gerade Personen des öffentlichen Lebens sind dabei in Gefahr, denn von ihnen stehen meistens zahlreiche hochauflösende Fotografien öffentlich zur Verfügung. Du bist keine Person des öffentlichen Lebens, postest keine Selfies auf Instagram und trägst ab jetzt immer Handschuhe? Deine Fingerabdrücke sind trotzdem nicht sicher. Denn denk daran, während manche staatliche Stelle dich dazu zwingen kann, deinen Rechner oder Smartphone zu entsperren, indem sie physische Gewalt anwendet, um deinen Finger auf den Fingerabdrucksensor zu bekommen, schneidet die Mafia deinen Finger einfach direkt ab. Beides keine schönen Aussichten und als Methoden auch nicht notwendigerweise auf staatliche Stellen oder die Mafia begrenzt, sondern von jederman leicht nachzumachen. Passwörter sind vielleicht doch nicht so schlecht, wie du immer dachtest. Davon stehen dir sogar unendlich viele zur Verfügung, während du nur maximal 10 Fingerabdrücke hast.

Türchen Nummer 15: Dateien sicher übertragen mit Magic Wormhole:

Ihr kennt das: Ihr möchtet gerne eine größere Datei sicher an eine andere Person übermitteln. Für eine Email ist sie zu groß. Auf euren FTP-Server, falls ihr sowas noch nutzt, hat die andere Person keinen Zugriff. Auf eure Cloudlösung, wie z.B. Owncloud auch nicht. Und falls doch, dann müsst ihr die Datei erst verschlüsseln, bevor ihr sie irgendwo hochladet, dann der anderen Person Bescheid geben, damit diese sie wieder runterladen und entschlüsseln kann. Zu guter Letzt müsst ihr die Datei wieder vom Server löschen. Alles ziemlich umständlich. Gibt’s da nicht eine einfachere Lösung? Die gibt es mit dem Programm Magic-Wormhole. Damit könnt ihr direkt Dateien, die während der Übertragung automatisch verschlüsselt werden, von einem Rechner zu einem anderen übertragen. Konkret: Ihr ruft einfach auf dem Rechner des Senders das Programm Magic-Wormhole mit dem Parameter SEND gefolgt von dem Pfad der zu übertragenden Datei auf. Magic-Wormhole präsentiert euch dann eine Phrase, die aus einer Zahl und zwei Wörtern besteht. Diese Phrase müsst ihr dem Empfänger mitteilen. Sie ist so gestaltet, dass sie sich leicht über einen Audiokanal, wie z.B. ein Telefon übermitteln lässt. Alternativ kann die Phrase auch über einen sicheren Instant Messenger, wie z.B. Signal oder per verschlüsselter Email übertragen werden, wobei unsere Empfehlung klar ein sicherer Instant Messenger ist. Auf dem Rechner des Empfängers ruft ihr nun Magic-Wormhole mit dem Parameter RECEIVE auf. Magic-Wormhole wird euch nun nach der Phrase fragen. Wenn ihr diese eingegeben habt, und sie mit der des Senders übereinstimmt, beginnt der Transfer. Was passiert dabei hinter den Kulissen? Damit die Rechner sich gegenseitig finden, wird ein Mailbox Server benötigt, der manchmal auch als Rendezvous-Server bezeichnet wird. Dahin verbindet sich Magic-Wormhole zuerst, sowohl beim Senden als auch beim Empfangen. Mittels einer übereinstimmenden Phrase werden nun Sender und Empfänger zusammengebracht. Diese versuchen danach zunächst eine direkte Verbindung zueinander aufzubauen, um die Datei zu übertragen. Sollte dies nicht möglich sein, weil z.B. Sender oder Empfänger hinter einem NAT stehen und nicht direkt erreichbar sind, kommt das Transit Relay ins Spiel. Dorthin bauen Sender und Empfänger eine Verbindung auf, wenn eine direkte Verbindung nicht möglich ist. Das Relay leitet dann einfach die Pakete von der einen Verbindung an die andere Verbindung weiter. Das Magic-Wormhole Projekt betreibt sowohl einen Mailbox Server als auch ein Transit Relay. Wenn ihr diesen, trotz der Verschlüsselung der Datei während der Übertragung nicht traut, könnt ihr auch beides selbst aufsetzen und betreiben. Alle Komponenten von Magic-Wormhole sind Open-Source. Um eure eigenen Server zu nutzen, müsst ihr lediglich deren URLs als weiteren Parameter angeben. Fortgeschrittene Nutzer:innen können auch Magic-Wormhole mit den eigenen Servern als Standardeinstellung selbst kompilieren. Das in Python geschriebene Magic-Wormhole ist für die gängigen Betriebssysteme macOS, Windows und Linux verfügbar. Es gibt auch noch eine kompatible Implementierung in Go, die besonders einfach zu installieren ist, da sie nur aus einem statisch gelinktem Binary besteht. Also, warum probiert ihr das nicht einfach mal aus?

Türchen Nummer 14: Der Computerwurm Morris

Heute haben wir eine kleine Geschichtslektion für euch. Man schrieb das Jahr 1988, als der amerikanische Student Robert T. Morris einen Wurm auf das Internet losließ. Laut Morris eigenen Aussagen war das nicht mal böswillig, das eigentliche Ziel des Programms war es, die Rechner innerhalb des Netzwerks zu zählen - doch dank eines Bugs wurde das kleine Programm zu einem sich schnell verbreitenden Wurm. Damals waren bis zu zehn Prozent der Kommunikation im Internet eben auf diesen Wurm zurück zuführen. Eine Untersuchungskommission inspizierte die Entwicklungshistorie des Computerprogramms und entschied, dass der Autor eine gezielt destruktive Absicht während der Entwicklung gehegt haben muss, da in den Code-Kommentaren Wörter wie „Steal“ oder auch „Attack“ auftauchten, sodass Morris angeklagt wurde. Nach einem Jahr Universitätsausschluss folgten eine drei-jährige Haftstrafe auf Bewährung, eine Geldstrafe, gemeinnützige Arbeit und das Tragen der Gerichtskosten. Setzt man sich mit der genaueren Funktionweise des Programms auseinander, so kann man die Gerichtsentscheidung von damals durchaus nachvollziehen. Um sich zu verbreiten, nutzte der Wurm Sicherheitslücken in den Programmen FINGERD und SENDMAIL aus, sowie ungesicherte REMOTE SHELLS und wiederverendete Passwörter. Für letzteres hatte der Wurm eine Funktion an Board, um per Brute-Force die Passwörter der Useraccounts eines infizierten Rechners zu knacken, und diese dann auf anderen Rechnern auszuprobieren, um dort eine eigene Shell zu starten. Der Wurm selbst hat einiges versucht, um sich zu tarnen. Die enthaltenen Zeichenketten waren verschlüsselt, die für die Infektion notwendigen Dateien wurden nach einer erfolgreichen Infektion gelöscht und der Name des ausführenden Prozesses in SH umbenannt, damit man ihn für einen harmlosen Shell-Prozess hielt. Eigentlich gab es im Code einen Sicherheitsmechanismus, der den Wurm beenden sollte, wenn ein System bereits infiziert war. Der Sicherheitsmechanismus war jedoch fehlerhaft, sodass ein Rechner auch mehrfach infiziert werden konnte. Bei jeder neuen Infektion wurden weitere Ressourcen verbraucht, was in der Praxis einem Denial-of-Service Angriff glich. War es wirklich nur ein Versehen oder doch eine Malware, die mit voller Absicht in die Welt hinaus gelassen wurde? Das wird man wohl nicht mehr klären können. Manche Sicherheitsforscher vermuten, dass der Wurm wirklich aus Versehen frei gelassen wurde. Er hätte nämlich noch viel mehr Dateien nachladen können, als er es beim Ausbruch letztendlich getan hat. Das deutet darauf hin, dass der Wurm vielleicht noch gar nicht fertig war. D.h. jedoch nicht, dass es sich nicht trotzdem um Malware gehandelt hat, auch den Autor:innen von Malware passieren Fehler. Falls du den Morris-Wurm einmal in Echt bewundern möchtest, so ist das leicht möglich, denn im Computer History Museum in Mountain View, Kalifornien ist eine Computer-Diskette mit dem Virus ausgestellt.

Türchen Nummer 13: Git Commits mit SSH-Schlüsseln signieren

Manche von euch wissen wahrscheinlich, dass Git Commits und Tags signiert werden können. Wenn der Server passend konfiguriert ist, können sogar Pushes signiert werden. Dazu brauchte man bisher entweder ein PGP oder ein S/MIME Schlüsselpaar. Generell ist es empfehlenswert, Commits und Tags zu signieren, in der Praxis passiert das leider eher selten. Woran liegt das? Manchmal scheuen Entwickler:innen den zusätzlichen Konfigurationsaufwand. Oft liegt es jedoch daran, dass keine passenden PGP-Schlüssel oder S/MIME-Schlüssel vorhanden sind, mit denen signiert werden kann. Selbst in Entwickler:innen-Kreisen sind PGP oder S/MIME nicht weitläufig verbreitet. S/MIME-Zertifikate kosten Geld und sind deshalb, wenn überhaupt, eher im Enterprise-Umfeld zu finden. Aber auch dort ist es längst nicht Standard, ein S/MIME-Zertifikat zu haben. PGP ist in den Augen vieler kompliziert und Programme wie GPG schwer zu bedienen – trotz gegenteiliger Beteuerungen der PGP-Befürworter:innen. Und auch wenn PGP oder S/MIME vorhanden sind, ist es für Andere schwierig, an den passenden öffentlichen Schlüssel zu kommen, um die Signaturen zu überprüfen. In der jüngst veröffentlichten Git-Version 2.34.0 können nun auch SSH-Schlüssel zur Signierung von Commits und Tags genutzt werden. Pushes werden momentan noch nicht unterstützt. Der Vorteil von SSH-Schlüsseln ist, dass fast jede Git-Nutzer:in bereits einen besitzt, da die meisten Git-Hosting Plattformen SSH-Schlüssel zur Authentifizierung des Git-Clients unterstützen und diese auch gegenüber einem Passwort bevorzugen. Zudem können die öffentlichen SSH-Schlüssel der Nutzer:innen bei den großen Plattformen Gitlab und Github einfach unter einer bestimmten URL abgerufen werden. Damit ist die Verteilung wesentlich leichter als bei PGP oder S/MIME und ermöglicht eine Überprüfung der Signaturen, ohne dass vorher die Schlüssel über einen anderen Kanal ausgetauscht werden müssen. Solltest Du noch keinen SSH-Schlüssel für die Authentifizierung von Git benutzen, dann richte Dir das besser gleich ein. Ein Passwort ist die deutlich schlechtere Alternative. Danach kannst du ja einfach mal probieren, deine Commits mit dem SSH-Schlüssel zu signieren. Einmal eingerichtet ist das gar nicht so schwer. Und vergiß nicht, deinen privaten SSH-Schlüssel zu schützen, wie du es schon bei Türchen Nummer 8 gelernt hast.

Türchen Nummer 12: Der Algorithmus NONE im JWT

Vielleicht hast Du auch schon einmal mit JSON Web Tokens, kurz JWTs in Deinem Arbeitsalltag zu tun gehabt. Die laut RFC empfohlene Aussprache ist übrigens jot, wir bleiben hier bei JWT. JWTs werden oft für Authentifizierungs- und/oder Autorisierungszwecke benutzt, z.B. auch bei OpenID Connect. Damit sie nicht manipuliert werden können, haben JWTs als drittes und letztes Element eine Signatur oder einen Message Authentication Code zur Integritätssicherung über die ersten beiden Elemente: den Header und den Payload. Im Header wird der Signatur- oder MAC-Algorithmus angegeben, so dass der Empfänger weiß, wie er die Integrität des Tokens validieren soll. Neben den verschiedenen Signatur- und MAC-Verfahren ist als Algorithmus auch NONE erlaubt. D.h. das dritte Element ist einfach ein leerer String und es gibt keinen Integritätsschutz. Laut RFC kann NONE benutzt werden, wenn die Integrität schon auf anderem Wege sichergestellt wird. In der Praxis hat das schon zu großen Sicherheitsproblemen geführt. Angreifer:innen mussten einfach die Algorithmusangabe im Header auf NONE ändern und die vorhandene Signatur oder den MAC entfernen, dann konnten sie den Payload beliebig manipulieren. Wurde dieser Token nun validiert, sagten die meisten JWT-Bibliotheken, es sei alles in Ordnung. Nachdem dieses Verhalten und die damit einhergehende Sicherheitsproblematik breiter bekannt wurden, haben die meisten Bibliotheken ihr Verhalten geändert. Entweder haben sie Token mit NONE einfach abgelehnt, oder sie haben die Validierungsfunktion so erweitert, dass sie einen weiteren Parameter neben dem Token selbst erfordern, in dem die erlaubten Algorithmen stehen bzw. ob NONE erlaubt ist oder nicht. Manche Bibliotheken überlassen diese Prüfung allerdings auch weiterhin den Nutzer:innen. Solltest Du JWTs nutzen, achte immer darauf, dass Du nur Tokens akzeptierst, deren Algorithmus Du auch erwartest. Und falls Du selbst auf NONE prüfst, achte darauf, dass die Groß-/Kleinschreibung keine Rolle spielt: Ein Sicherungsmechanismus gegen Tokens mit NONE Algorithmus einer bekannten Authentifizierungs- und Autorisierungsplattform konnte noch Jahre, nachdem die allgemeine Problematik mit NONE bekannt war, durch unterschiedliche Groß-/Kleinschreibung von NONE ausgehebelt werden. Kleiner Fun Fact zum Schluss: wie bei den Cookies – ihr erinnert euch sicher noch an Türchen Nummer 5 – wird auch bei JWTs oft fälschlicherweise von Signaturen gesprochen, wenn ein MAC zum Einsatz kommt.

Türchen Nummer 11: Das Phrack-Magazin

Das Phrack-Magazin ist eines der ältesten Hacker-Magazine. Der Name setzt sich aus den Begriffen Phreaking und Hacking zusammen und es erscheint in unregelmäßigen Abständen seit 1985; aktuell ist die Ausgabe 70. Während in der Anfangszeit der Schwerpunkt mehr auf dem Phone-Phreaking lag, änderte sich, auch weil Phone-Phreaking immer mehr an Bedeutung verlor, der Fokus zur Jahrtausendwende immer mehr in Richtung IT-Sicherheit. Neben den rein technischen Themen werden auch immer wieder andere Themen behandelt wie Anarchie und Gegenkultur, mit der Hacker-Kultur als Manifestation von beidem. Gerade die technischen Artikel haben oftmals eine exzellente Qualität und haben Meilensteine wie Smashing The Stack For Fun And Profit hervor gebracht. Wenn Du auch mal in die Tiefen der Hacker-Subkultur eintauchen willst, ist das Phrack-Magazin ein guter Einstieg. Du darfst Dich allerdings weder vom Slang, der für Dich wahrscheinlich zum größten Teil unverständlich ist, oder davon, dass Du bei den technischen Artikeln maximal 10% verstehen wirst, abschrecken lassen. Eine Subkultur zu erforschen ist keine leichte Aufgabe und braucht Zeit und Geduld - genau so wie richtiges Hacking.

Türchen Nummer 10: Was bedeutet eigentlich Zero-Day?

Im Zusammenhang mit Sicherheitslücken liest man immer wieder von genannten Zero-Days. Was bedeutet das eigentlich? Zero-Days sind Sicherheitslücken, von denen die Betroffenen bzw. die Herstellenden des Produktes noch nichts wissen. Der Name rührt daher, dass er angibt wie viele Tage Zeit waren, um die Sicherheitslücke zu schließen: 0 Tage. Ursprünglich kommt der Begriff aus der Warez-Szene, und gab an, wie alt eine Raubkopie im Vergleich zum Veröffentlichungsdatum war. Zero-Day hieß, die Kopie war schon vor dem offiziellen Veröffentlichungsdatum verfügbar. So etwas passiert heute immer noch gelegentlich z.B. bei Filmen, bei denen Kopien schon vor dem Kinostart kursieren. Der Begriff Zero-Day wird dabei aber nur noch sehr selten benutzt. Zero-Days sind äußerst begehrt: bei Kriminellen, bei Herstellenden von Spionage- und Überwachungssoftware und bei Geheimdiensten. Sicherheitslücken, für die es keinen Patch gibt, bieten eine Gelinggarantie für Ransomware, Spionage- und Überwachungssoftware und Hacking-Operationen. Es gibt spezialisierte Unternehmen, die Zero-Days und passende Exploits aufkaufen, um diese dann weiter zu verkaufen, z.B. an Geheimdienste oder Herstellende von Spionage- und Überwachungssoftware. Oft zahlen diese Unternehmen mehr als die betroffenen Herstellenden als Belohnung, wenn man ihnen die Lücke meldet. Wenn bemerkt wird, dass es Zero-Days gibt und diese ausgenutzt werden, dann bricht oft Hektik aus. Sowohl bei potentiell Betroffenen als auch bei den Herstellenden. Diese müssen schnellstens Patches entwickeln, welche oft auch außerhalb der üblichen Patch-Zyklen veröffentlicht werden. Die potentiell Betroffenen müssen bis zum Einspielen der Patches, wenn überhaupt vorhanden, Workarounds nutzen, damit die Lücke nicht ausgenutzt wird oder schlimmstenfalls Dienste vom Netz nehmen, um sich zu schützen. Was kannst Du tun? Wenn Du einen Zero-Day findest, dann natürlich dem herstellenden Unternehmen melden. Neben der Verbesserung deines Karmas werden Herstellende dich auch finanziell dafür entlohnen. Als potentiell Betroffene lohnt es sich Notfallpläne zu machen, in denen z.B. geregelt wird, wer einen Dienst unter welchen Umständen abschalten darf und wie das kommuniziert wird – damit im Falle eines Falles die Hektik nicht zur Panik wird. Bist Du Herstellende, solltest Du immer eine security.txt unter dem .well-known Pfad auf deiner Webseite haben, damit Sicherheitsforschenden klar ist, wie sie dir Sicherheitslücken melden können.

Türchen Nummer 9: Verschlüsseltes UDP - DTLS, SRTP und QUIC

Verschlüsselte Netzverbindungen sollten heutzutage eigentlich Standard sein. Bei TCP ist die Sache ziemlich klar, man nimmt einfach TLS. Doch bei UDP ist es nicht so einfach. TLS ist zwar grundsätzlich agnostisch gegenüber dem unterliegenden Protokoll, dieses muss jedoch zwei Eigenschaften erfüllen: es muss erstens zuverlässig sein, d.h. keine Pakete dürfen verloren gehen, und zweitens müssen die Pakete in der richtigen Reihenfolge übertragen werden. UDP hat keine der beiden Eigenschaften, daher kommt TLS nicht in Frage. Als Alternative bietet sich DTLS an, das Datagramm Transport Layer Security Protokoll. DTLS wurde erstmals 2004 in einem Paper vorgeschlagen, passenderweise direkt mit einer Implementierung in OpenSSL. DTLS Version 1.0 wurde 2006 in RFC 4347 standardisiert, 2012 folgte mit RFC 6347 die Version 1.2. Eine Version 1.1 gab es nicht. DTLS entspricht weitestgehend TLS, es wurden nur einige wenige Änderungen vorgenommen, die wegen der fehlenden Zuverlässigkeit von UDP nötig sind. Obwohl es DTLS schon lange gibt und auch der Bedarf an verschlüsseltem UDP da ist, ist es in der Praxis nur wenig verbreitet. Hier haben sich eher spezialisierte Varianten von Protokollen auf der Anwendungsebene, wie z.B. SRTP, das Secure Real-Time Transport Protokoll, durchgesetzt. SRTP ist die verschlüsselte Variante von RTP, das vor allem beim Streaming von Medieninhalten oder bei WebRTC zum Einsatz kommt. Immer weiter verbreitet sich fast unbemerkt das QUIC-Protokoll, da es von fast allen modernen Browsern unterstützt wird. Ursprünglich von Google entwickelt, jetzt in RFC 9000 von der Internet Engineering Task Force, kurz IETF, standardisiert, soll es als Ersatz für TCP dienen und einige Unzulänglichkeiten, wie beispielsweise das head-of-line-blocking, beheben um eine bessere Performance zu erzielen. QUIC nutzt dazu UDP und setzt darauf eine eigene Flusskontrolle für die Zuverlässigkeit, congestion control im Userspace zur Vermeidung von head-of-line-blocking sowie Multiplexing für höhere Protokolle auf. Zur Verschlüsselung setzt QUIC auf TLS, da es trotz UDP Zuverlässigkeit und die richtige Reihenfolge der Pakete garantieren kann. Dafür müssen viele TLS-Bibliotheken angepasst werden, da diese typischerweise bei TLS von TCP ausgehen, und gar kein anderes Transport-Protokoll nutzen können, obwohl TLS laut Spezifikation eigentlich protokollagnostisch ist.

Türchen Nummer 8: Das BSI verschickt einen privaten Schlüssel

Sicher hast du schon einmal von asymmetrischen Verschlüsselungsverfahren gehört, hier gibt es einen privaten und einen öffentlichen Schlüssel. Wie der Name schon verrät, ist der öffentliche Schlüssel öffentlich einsehbar und kann von jedem zur Verschlüsselung von Nachrichten an dich und zur Prüfung deiner digitalen Signaturen genutzt werden. Im Gegensatz zum öffentlichen gibt es noch den privaten Schlüssel - wann immer du Nachrichten entschlüsseln oder signieren möchtest, kommt dieser zum Einsatz. Dieser Schlüssel ist privat und sollte es auch bleiben, diesen solltest du auf keinen Fall an andere Personen weitergeben. Genau hier beginnt unser Türchen so richtig, denn asymmetrische Verschlüsselung und die Frage „Welchen Schlüssel kann ich nach außen geben“ verwirrt nicht nur IT-ferne Menschen gelegentlich…

Erst dieses Jahr passierte dem BSI ein Schlüssel-Fauxpax: Per Mail bat eine Person um den öffentlichen Schlüssel zur verschlüsselten Mail-Kommunikation via OpenPGP mit dem BSI. Anstelle des öffentlichen Schlüssels erhielt die genannte Person allerdings den privaten PGP-Schlüssel der Behörde. Glücklicherweise war dieser mit einem Passwort geschützt. Der Sicherheitsgrad des gewählten Passworts ist nicht bekannt. Nach Versand des Schlüssels wurde dieser allerdings nicht umgehend geändert, er wurde noch mehrere Monate weiter verwendet.

Denk immer dran: Versende niemals deinen privaten Schlüssel - geschieht es dir doch einmal aus Versehen, ändere dein Schlüsselpaar am besten sofort. Und sichere den privaten Schlüssel immer mit einem Passwort. So gut wie alle Programme, mit denen du ein Schlüsselpaar erzeugen kannst, bieten das standardmäßig an. Auch wenn das einen kleinen Komfortverlust bedeutet, weil du jedesmal, wenn du den privaten Schlüssel verwendest, das Passwort eingeben musst. Noch besser ist es, wenn du den privaten Schlüssel auf einem externen Datenträger aufbewahrst und diesen nur anschließt, wenn der private Schlüssel gebraucht wird. Am besten nutzt du dazu spezielle Hardware, die sich nicht kopieren oder ohne Authentifizierung auslesen lässt.

Türchen Nummer 7: Hackerparagraph

Bereits im dritten Türchen unseres Adventskalenders haben wir ihn erwähnt - den Hackerparagraphen. Doch, was verbirgt sich eigentlich genau dahinter?

Der Paragraph 202c „Vorbereiten des Ausspähen und Abfangen von Daten“ des Strafgesetzbuchs wird umgangssprachlich auch als Hackerparagraph bezeichnet. Verabschiedet wurde dieser im Mai 2007 und trat dann im August desselben Jahres in Kraft. Aber was genau steht hier unter Strafe und warum war es bereits Thema beim Kali Linux-Türchen?

Strafbar sind nach Paragraph 202c nicht nur die eigentliche Beschaffung und Verbreitung von Passwörtern oder anderen Sicherheitscodes, mit denen man sich Zugang zu Daten beschaffen kann, sondern auch die Implementierung von Computerprogrammen, die dafür gedacht sind, ebendiese Daten zu beschaffen. Und Kali Linux ist voll mit Programmen solcher Art.

Viele Sicherheitsexpert:innen sind über die sehr schwammige und ungenaue Formulierung des zweiten Teils des Hackerparagraphen verärgert, denn aus diesem geht nicht klar hervor, welche Tools genau hierzu zählen. Da die meisten dieser Tools Dual-Use sind, das heißt, sie können für Sicherheitstests, aber auch für kriminelles Hacking eingesetzt werden, befürchten viele Sicherheitsexpert:innen eine Kriminalisierung und damit praktisch ein Berufsverbot. Um dies zu klären, gab es nach dem In-Kraft-Treten eine Reihe von Selbstanzeigen von Sicherheitsexpert:innen.

In einem Urteil des Bundesverfassungsgerichts wurde dann festgestellt, dass beim Einsatz solcher Dual-Use Tools eine Strafbarkeit nur gegeben ist, wenn der Vorsatz zu einer strafbaren Handlung vorliegt. Die Nutzung zur Ausübung der beruflichen Tätigkeit ist in der Regel straffrei. Problematisch ist jedoch, dass die Weiterverbreitung immer noch strafbar sein kann, nämlich, so das Bundesverfassungsgericht, „sobald die betreffenden Programme durch Verkauf, Überlassung, Verbreitung oder anderweitig auch Personen zugänglich gemacht werden, von deren Vertrauenswürdigkeit nicht ausgegangen werden kann.“ Die Vertrauenswürdigkeit von Personen, die ein Projekt von einer Webseite runterladen, ist wohl schwerlich feststellbar. Dual-Use Tools als Open-Source zu entwickeln ist somit so gut wie unmöglich.

Nicht umsonst mahnt der Chaos Computer Club an, dass durch den Hackerparagraphen in Deutschland Hersteller:innen und Nutzer:innen von Dual-Use Tools kriminalisiert werden, dass das Sicherheitsniveau des Landes sinkt und es einen Standortnachteil für Forschung und Wirtschaft erfährt.

Kleiner Fun-Fact: Das BSI veröffentlichte einst den Link zur Webseite der Software „John the Ripper“, was als Vergehen gegen den Paragraph 202c erachtet wurde - das Ermittlungsverfahren wurde allerdings eingestellt. Wenn Ihr also solche Tools nutzt, solltet ihr immer sicherstellen, dass ihr das Einverständnis derjenigen habt, gegen deren Systeme ihr die Tools einsetzt, z.B. bei einem Pen-Test. Entwickelt ihr selbst solche Tools, dann, so traurig es ist, stellt sie lieber nicht auf eurer Webseite oder GitHub und Co der Öffentlichkeit zur Verfügung.

Türchen Nummer 6: Security Engineering von Ross Anderson

Heute haben wir einen Buchtipp für euch: „Security Engineering - A Guide To Building Dependable Distributed Systems“ von Ross Anderson, im November 2020 in der dritten überarbeiteten Auflage erschienen. Ein - wenn nicht das Standardwerk - in Sachen Security. Mit über 1000 Seiten schon ein dicker Brocken, dabei aber auch für Anfänger:innen in Sachen Security nicht völlig unzugänglich. Neben den Grundlagen wie Kryptografie, Protokollen oder Angriffsklassifikationen werden auch Themen wie die Rolle von Psychologie und UX in der Security bis hin zu gesellschaftlichen Themen wie Überwachung und Zensur besprochen. Vielfach mit Beispielen aus der realen Welt illustriert. So ein breites Spektrum an Security-Themen, welches dabei nicht nur an der Oberfläche, sondern oft sehr tiefgehend behandelt wird, findet man sonst nirgendwo. Aber nicht nur wir finden das Buch gut, auch anerkannte Security-Experten wie Bruce Schneier oder Gary McGraw sind begeistert. Und das beste ist, ausgewählte Kapitel und die komplette vorige, zweite Auflage gibt es kostenlos auf der Homepage von Ross Anderson im Netz. Den Link findet ihr in den Shownotes. Dort könnt ihr euch selbst ein Bild machen, ob das Buch etwas für euch ist.

Wenn ihr euch also mit dem Thema Security tiefer auseinandersetzen wollt und noch was für euren Wunschzettel braucht, dann packt doch einfach die Buch- oder E-Book-Variante von Security Engineering drauf.

Türchen Nummer 5: Signierte Cookies

Damit Cookies nicht unbemerkt auf der Client-Seite manipuliert werden können, wird oft geraten, die Cookies zu signieren. Auch in API-Beschreibungen wie z.B. beim populären Node.js Webframework Express oder im INNOQ Podcast über Cookies wird von signierten Cookies gesprochen. Dabei werden Cookies in der Regel gar nicht signiert.

Wenn sie nicht signiert werden, was dann? Normalerweise werden Manipulationsversuche durch eine Integritätsprüfung mittels eines MAC, das steht für Message Authentication Code, aufgedeckt. Meistens kommt dabei ein HMAC, ein auf einer Hash-Funktion basierender Message Authentication Code, zum Einsatz. Zum Berechnen eines HMAC brauchen wir die Daten, deren Authentizität und Integrität wir sicherstellen wollen und einen geheimen Schlüssel. Wird eines von beiden geändert, ändert sich auch der berechnete HMAC. Um Manipulationen an Cookies zu erkennen, berechnen wir beim Setzen eines Cookies den HMAC über die Nutzdaten des Cookies und hängen den berechneten HMAC an die Nutzdaten an. Wird der Cookie wieder an den Server gesendet, berechnen wir erneut den HMAC über die Nutzdaten und vergleichen ihn mit dem HMAC, der an die Nutzdaten angehängt wurde. Sind die beiden HMACs unterschiedlich, wurde der Cookie manipuliert. Ohne den geheimen Schlüssel kann kein valider HMAC für geänderte Nutzdaten erstellt werden. Der Cookie ist somit vor Manipulation geschützt.

Was ist nun der Unterschied zu signierten Cookies? Auch bei signierten Cookies wird die Authentizität und Integrität der Cookies geschützt. Im Unterschied zu einem MAC kommt hier aber ein asymmetrisches kryptografisches Verfahren mit öffentlichem und privatem Schlüssel zum Einsatz. Die Nutzdaten werden mit dem privaten Schlüssel signiert, und die errechnete Signatur wird, genauso wie beim MAC-Verfahren, an die Nutzdaten im Cookie angehängt. Da die Verifizierung der Signatur mit dem öffentlichen Schlüssel erfolgt, kann nun jeder die Authentizität und Integrität der Nutzdaten überprüfen, der im Besitz desselbigen ist.

Macht das für euch in der Praxis einen Unterschied, und solltet ihr statt einen MAC lieber eine richtige Signatur einsetzen? In vielen Fällen wird die Antwort wohl nein lauten. Ein MAC ist nämlich, im Gegensatz zur Signatur, in der Regel sowohl schneller zu berechnen als auch kleiner, und verbraucht somit nicht soviel Platz in den ohnehin schon auf 4 Kilobyte begrenzten Cookies. Normalerweise müsst ihr die Integrität und die Authentizität auch nur euch selbst beweisen und niemand anderem, sodass die Verifizierung mittels öffentlichem Schlüssel, den ihr, anders als den geheimen Schlüssel beim MAC-Verfahren, beliebig weitergeben könnt, auch keinen Vorteil bringt. Einzig wenn die Cookies nur von wenigen Servern gesetzt werden, aber von vielen verifiziert werden müssen, bieten signierte Cookies einen Vorteil. Zum Beispiel wenn Authentifizierungscookies nur von einem oder wenigen Authentifizierungs-Servern gesetzt werden, aber alle anderen Server im System diese verifizieren können sollen. Dann muss der geheime Schlüssel nur den Authentifizierungs-Servern bekannt sein, was einen Sicherheitsvorteil gegenüber dem MAC-Verfahren bietet, bei dem alle Server den geheimen Schlüssel kennen müssen.

Türchen Nummer 4: Malware

Virus - Wurm - Trojaner: Nichts davon möchte man haben. Doch, wo liegt eigentlich der Unterschied zwischen den dreien?

Alle drei sind Programme, die unerwünschte und für die Nutzer:innen schädliche Dinge auf dem Computer machen, beispielsweise Daten manipulieren, exfiltrieren oder löschen. Sie firmieren alle, mit noch einigen anderen Typen von schädlicher Software, unter dem Oberbegriff Malware, der sich aus den Wörtern malicious und software zusammensetzt.

Ein Computervirus kann sich selbst weiterverbreiten, indem es sich z.B. selbst in den Bootsektor eines Datenträgers oder den Programmcode von ausführbaren Dateien schreibt und diese als Wirt benutzt. Werden die infizierten Datenträger oder die infizierten Programme nun weitergegeben und auf anderen Computern eingelesen bzw. gestartet, kann sich der Virus auch auf diesen Systemen ausbreiten.

Computerwürmer haben nicht so viel Geduld wie Computerviren. Zwar replizieren auch sie sich weiter, doch brauchen sie dafür keinen Wirt, der versehentlich oder absichtlich durch Anwender:innen weitergegeben wird. Sie nutzen Sicherheitlücken aus, um sich aktiv z.B. über das Netzwerk oder per E-Mail zu verbreiten.

Trojaner sind im Gegensatz zu den ersten beiden erstmal unauffällig anmutende Programme, die allerdings im Hintergrund Funktionen ausführen, von denen Anwender:innen nichts wissen. Häufig werden bei der Installation des Trojaners im Hintergrund Schadprogramme wie beispielsweise Keylogger mitinstalliert. Trojaner können zwar auch durch Viren oder Würmer verbreitet werden, häufig installieren die Anwender:innen diese jedoch unwissentlich selbst, indem sie z.B. Office-Dateien mit ausführbaren Inhalten aus nicht vertrauenswürdigen E-Mails öffnen oder Links folgen, die auf Web-Seiten führen, die versuchen Sicherheitslücken im Browser für die Installation ausnutzen.

Wenn Ihr Euch vor Viren, Würmern und Trojanern schützen wollt, ist eine Möglichkeit, eine Anti-Viren-Software zu benutzen. Entgegen ihres Namens schützt diese normalerweise auch vor anderen Arten von Malware. Jedoch vergrößert eine Anti-Viren-Software die Angriffsoberfläche auf euer System ungemein und ist nicht selten selbst von Sichherheitslücken geplagt. Deshalb ist unser Tipp: haltet euer System immer auf dem neusten Stand, klickt nicht auf Links und öffnet keine Programme oder Dokumente, die aus nicht vertrauenswürdigen Quellen stammen, dann braucht ihr auch keine extra Anti-Viren-Programme.

Türchen Nummer 3: Kali Linux

Du hast Lust auch mal mit „Hackertools“ zu spielen oder in das Ethical Hacking einzusteigen? Vielleicht hast du schon von der Linux-Distribution „Kali“ gehört, die dir als Boardmittel über 600 Tools dafür mitbringt. Die Distribution kannst du dir einfach runterladen und sie einrichten, sie ist Open Source. Kali basiert auf Debian, weil man laut Aussage von einem der Hauptentwickler, eine qualitativ hochwertige und stabile Distribution als Unterbau verwenden wollte, mit einer Vielfalt bereits verfügbarer Software. Begonnen hat die Entwicklung an Kali Linux im Jahr 2012 als Nachfolger von BackTrack Linux, die erste Version wurde dann im März 2013 veröffentlicht. Diese beinhaltete bereits hunderte Applikationen, die für Penetration Testing eingesetzt werden konnten. Ein graphisches Menü wurde übrigens erst in Kali Linux 2.0 im August 2015 als Feature hinzugefügt. Seit Version 2016.1 wird Kali als „rolling distribution” angeboten, es wird also jeden Tag geprüft, ob neue Updates verfügbar sind. Seit dieser Zeit basiert Kali auf Debian Testing.

Kali Linux bietet einen großen Werkzeugkasten mit Tools für die verschiedensten Aufgaben: Systemüberwachung, forensische Analyse, Penetrationtesting und vieles mehr. Seit der Einführung des zuvor erwähnten „Application Menu” in 2015 sind all die verschiedenen Tools nach Aufgabenbereichen gegliedert über die Menüzeile erreichbar.

Einige der bekannteren Tools, die in Kali Linux zur Verfügung gestellt werden, sind zum Beispiel Wireshark, OWASP ZAP, aircrack-ng, BeEF, kismet, John the Ripper und Metasploit. Hinter dieser Linux Distribution steckt maßgeblich das Unternehmen Offensive Security.

Worauf wartest du noch, such dir ein Tutorial im Netz und entdecke die vielen Werkzeuge, die in Kali Linux enthalten sind. Aber Vorsicht: einige der Tools fallen in Deutschland unter den sogenannten „Hackerparagraphen“ und dürfen nicht für das Ausspähen von Daten benutzt werden.

Türchen Nummer 2: Heartbleed

Heartbleed ist wohl eine der schwerwiegensten und bekanntesten Sicherheitslücken der Internetgeschichte. Und nicht nur das: Heartbleed ist außerdem die erste Sicherheitslücke mit einer eigenen Webseite und einem eigenen Logo.

Was ist Heartbleed genau? Ein Implementierungsfehler, genauer gesagt eine fehlende Input-Validierung, bei der Heartbeat-Extension des TLS und DTLS-Protokolls, in der bekannten und weit verbreiteten OpenSSL Bibliothek. Heartbleed ermöglicht es einer Angreifer:in mit einer manipulierten Heartbeat-Message vom Client bis zu 64 Kilobyte Speicher des Servers auszulesen. Auf diese Weise kann die Angreifer:in an sensible und vertrauliche Informationen gelangen, zum Beispiel den privaten Schlüssel des Serverzertifikats. Mit diesem ist es den Angreifer:innen möglich, die Inhalte der TLS-Verbindung zu entschlüsseln.

In die Codebasis eingeflossen ist der Fehler, trotz eines Codereviews durch einen der OpenSSL-Maintainer, an Silvester 2011, und wurde mit der Version 1.0.1 von OpenSSL am 14. März 2012 veröffentlicht. Die Entdeckung und Behebung des Fehlers erfolgte erst zwei Jahre später im April 2014 mit der Version 1.0.1g. Heartbleed hatte erhebliche Nachwirkungen. Da die Sicherheitslücke solange unentdeckt blieb, mussten unzählige TLS-Zertifikate und die zugehörigen Schlüssel zurückgezogen werden, da diese grundsätzlich als kompromittiert angesehen werden mussten. Dabei sind einige Unzulänglichkeiten in den Mechanismen und der Infrastruktur für das Zurückziehen von Zertfikaten zu Tage getreten, welche zum Teil bis heute nicht zufriedenstellend gelöst sind. Desweiteren sind in Folge Heartbleeds weitere Qualitätsmängel in OpenSSL gefunden worden, die zum größten Teil einer heillosen Unterfinanzierung des Projekts geschuldet waren. Als Konsequenz daraus wurde OpenSSL zweimal geforkt, einmal als LibreSSL vom OpenBSD Projekt und einmal als BoringSSL von Google, die beide zum Ziel haben, OpenSSL zu entschlacken und qualitativ zu verbessern. OpenSSL selbst hat danach eine Finanzierung durch die neu gegründete Core Infrastructure Initiative der Linux Foundation bekommen.

Obwohl Heartbleed den fürchterlichen Zustand von OpenSSL aufgedeckt hat, kannst du es heute mit gutem Gewissen einsetzen. Heartbleed mit all seinen Konsequenzen hat dafür gesorgt, dass OpenSSL heute in einem besseren Zustand denn je ist.

Türchen Nummer 1: CIA

Hinter dem Kürzel CIA verbirgt sich nicht nur der bekannte US-Geheimdienst, sondern auch ein Kernkonzept der Informationssicherheit. CIA steht hierbei für Confidentiality, Integrity und Availability. Auf Deutsch: Vertraulichkeit, Integrität und Verfügbarkeit. Was verbirgt sich dahinter? Damit sind die allgemeinen Schutzziele der Informationssicherheit gemeint.

Vertraulichkeit beschreibt, dass während des Zugriffs auf oder der Übertragung von Daten diese nur von autorisierten Nutzern gelesen werden können dürfen. Dies wird z.B. durch Verschlüsselung erreicht.

Als zweites haben wir die Integrität. Die Integrität von Daten muss jederzeit gewährleistet sein. Um Integritätsverletzungen aufzudecken, dürfen Änderungen nur durchgeführt werden, wenn diese nachvollziehbar sind. Dieses Schutzziel kann zum Beispiel durch digitale Signaturen oder Audit-Logs erreicht werden.

Das letzte der drei Schutzziele ist die Verfügbarkeit. Daten müssen immer dann verfügbar sein, wenn sie gebraucht werden. Um dies zu gewährleisten, können unter anderem Hochverfügbarkeitssysteme eingesetzt werden.

Von den allgemeinen Schutzzielen können weitere, spezielle Schutzziele abgeleitet werden, beispielsweise Resilienz, Anonymität oder Authentizität.

Also, in Zukunft am besten die eine CIA rein, um die andere CIA aus euren Softwareprojekten rauszuhalten - Schutzziele erreichen, Geheimdiensthintertüren schließen.