 Ankommen. Gut, damit fangen wir jetzt an. Ein Applaus für Stefan Grönke, der jetzt mit dem Vortrag anfängt. Also, hallo zusammen. Ich heiße Stefan Grönke. Ich bin Software Entwickler seit ca. 15 Jahren. Ich arbeite an größeren und kleineren Projekten in verschiedenen Teamgrößen. Mein Entwicklungsdeck war lange JavaScript und ihr werdet tatsächlich einige Tools, die ich mir angeschaut habe, aus dieser Welt kennen. Aber ich stelle auch durchaus noch andere Projekte vor. Hier ist mein GPG Key und mein liebster Social Network Account. Ja, worum geht es heute? Ich rede darüber, wie man den Entwicklungsprozess selbst kapern kann, wie man ihn selbst angreifen kann. Das heißt, wenn ihr Software schreibt, kann es sein, dass das allein während ihr Software schreibt, schon Code of Eurer Maschine ausgeführt wird. Und ja, vielleicht habt ihr auch schon mal solche Probleme gehabt oder könnt dann hier aus diesem Vortrag Dinge mitnehmen, die ihr auf euren eigenen Entwicklungsprozess anwenden könnt. Ja, schauen wir uns mal den Software-Entwicklungsprozess an, wie es normalerweise aussieht. Ihr habt normalerweise ein Betriebssystem. Ihr braucht ein Computer, um eures Software zu schreiben und dass es allein schon von der harte Welt was, dem ihr vertrauen müsst. Ja, also zum Betriebssystem. Euer Betriebssystem beinhaltet Schlüsse, Zugangsdaten usw., die Tools, den Source Code, den ihr entwickelt. Und die Risikos an dieser Stelle sind, dass die Tools für verschiedene Exploits angreifbar sind oder dass euer System auf dem entwickelt bereits kompromittiert ist. Nachdem ihr dann den Code eigentlich drin schreibt, ist ja der Editor drin. Das sind ja tatsächlich relativ komplexe Programme. Ich finde, Editorinnen an sich relativ komplex. Viele Editorinnen kommen mit Paketmanagern und das ist quasi nur ein Symptom für die Komplexität, die diese Programme mitbringen. Es gibt dann auch so Geschichten wie Code-Lintern und Autocompleters und so weiter, die sehr nutzliche und wichtige Werkzeuge sind. Auf der anderen Seite kann das aber ein Problem sein, weil diese Module Code ausführen können, obwohl ihr vielleicht gar nicht denkt, dass die denn ausführen. Mit die Gelschen an dieser Stelle, also Abschärchung von den Risiken, da wäre eine Möglichkeit, dass man den Editor in eine virtualisierte Umgebung ausführt und dass man tatsächlich das ganze System sich anschaut, während man den Code ausführt. Nach dem Editor kommt dann wahrscheinlich noch eine Shell-Integration und das heißt, wenn ihr euer Repository aufmacht, dann seht ihr zum Beispiel, auf welchen Branche er arbeitet, welche Dateien verändert wurden und so weiter. Das ist sehr bequem, wenn ihr arbeitet, aber das ist möglicherweise auch ein secured Risiko. Meine Meinung zu den ganzen Shell-Integrationen ist, dass die Softwareentwicklungen auf eurem eigenen System gemacht sind. Also das heißt, wenn ihr den ganzen Code vertrauen könnt, dann ist das alles kein Problem. Aber sobald ihr Code von extern bekommt, dann kann das tatsächlich ein Problem sein. Schaut dabei, also achtet dabei drauf, dass ihr nicht einfach irgendwelchen Code runterladet. Das ist auch eine sehr gute Idee, den Code zu committen. Ja, Git kann Execute Hooks ausführen. Zum Beispiel, wenn man einen neuen Code auscheckt, wenn man einen Code eincheckt. Und wenn ihr ein Repository ausführt, das bedeutet, dass das, was unter Punkt Git gespeichert ist, in den Hooks im Zweifelsfall sofort ausgeführt wird. Und das funktioniert auch mit Subversion. Und die Shell-Integration weiß im Zweifelsfall nicht, was da gerade passiert ist. Und das Neuste ist, dass das Code, das man in den Hooks ausführt, jetzt support Git Hooks, das ist ein tolles Feature. Und das Neuste ist, dass Visual Studio auch diese Git Integration unterstützt und die Hooks damit, und damit hat man dann eben auch diese Schwierigkeit. Und wichtig ist, dass man als erstes dafür sorgt, dass diese Git Hooks nicht ausgeführt werden. Nachdem ihr den Code committed habt und gepusht habt, werdet ihr wahrscheinlich euren Code automatisch bauen lassen, so was wie Travis CI. Da wird ein Test laufen gelassen, es wird der Code kompiliert, es wird paketiert und im Zweifelsfall auch gleich deployt. Und das Problem, es wird ein Problem, sobald man die Ergebnisse nicht mehr reproduzieren kann, sobald man die binären Ergebnisse bekommt, man muss prüfen, was man da wirklich vor sich hat. Sonst, wenn man das nicht auditieren kann, dann weiß man nicht, was da wirklich passiert ist. Und man möchte, dass dieser ganze Prozess sehr schnell abläuft, man möchte, dass man das Caching nutzen kann. Oder durch das Caching gibt es das Problem, dass wenn es einen Angreifer schafft, die Inhalte des Caches auszutauschen, dann hat er da natürlich weitreichende Möglichkeiten, in dem er seinen eigenen Code da unterbringen kann. Und sobald für solche Bildtools muss man im Zweifelsfall Keys hinterlegen und sobald jemand Schreibzugrufe auf das Repo hat, kann man prinzipiell an den Key herankommen. Gucken wir uns mal ein Beispiel an. Bei Travis CI meldet man sich an und verbindet das Repo mit Travis und die beste Option hier ist, reproduzable Builds durchzuführen. Das heißt, wenn man die Build mehr herausführt, kommt immer genau das selbe Ergebnis raus und wenn es sich ändert, weiß man, dass es ein Problem gibt. Und bauen und testen der Software ist natürlich was ganz anderes, als die Software zu deployen oder zu paketieren und eine Möglichkeit zur Sicherheit beizutragen ist, das Ganze in unterschiedliche Systeme unterzubringen. Nachdem er die Software dann kopiert hat, müsste die irgendwie verteilen, das heißt entweder benutzt er einen eigenen Server oder benutzt einen CDN oder so. Das heißt, aber User werden von dort die Software runterladen und sie dann ausführen. Und das Problem dabei ist, wenn man tatsächlich Spanner hat, ist es schwierig zu beweisen, dass es tatsächlich vom echten Maintainer kam. Das heißt, wenn das irgendwie kompromittiert ist, dann ist es schwierig für Leute, den Unterschied dazu erkennen. Und die Lösung dafür ist, dass man einfach seine ganzen Artefakte signiert und den öffentlichen Schüssel hierfür veröffentlicht. So, dass es für User möglich ist, die Artefakte zu überprüfen. Der nächste Teil ist, dass man aktiv seine Nutze erreicht und den User sagt, das ist der nächste Schritt im Entwicklungsprozess, dass man seinen Projekt irgendwie bekannt macht, dass man die Librarian Package Registries oder so weiter registriert und die Package Manager, die ich mir da genauer angeschaut habe, waren hauptsächlich NPM. Da gab es zum Beispiel ein Vorfall, wo es ein Projekt gab, das Kick hieß. Und die Firma Kick hat dann dieses Modul löschen lassen. Und in der Konsequenz davon hat der Entwickler alle seine Liberis von NPM zurückgezogen. Und das hat zu sehr viel Problemen geführt bei Projekten, die diese Liberis von den Benutzer verwendet haben. Und tatsächlich ist meiner Meinung nach die beste Idee hierbei, dass man das Projekt nicht nur nach einem einzigartigen Identifier identifiziert, sondern tatsächlich auch so, was für eine Geodie oder eine Checksumme, dass man tatsächlich da Änderungen feststellen kann. Das müssen die Package Registries implementieren, also die Package Manager. Aber ein anderes Problem ist, dass man tatsächlich Offline-Backups von jedem Paket, dass man zum Bauen seiner Software braucht, Offline-Speich hat. Denn wenn man das nicht tut, dann kann es sein, dass Abstream die Liberi schon gelöscht hat und man dann nicht mehr an den Code rankommt, den man braucht, um seine Software zu bauen. Ein weiterer Schritt oder Bedürfnis von Software-Entwicklern ist, dass ihr Tooling in der Regel fast sein sollte, damit sie produktiv sind. Ich möchte, dass meine Tools fast sind und nicht, dass es durch eine VM oder so was entschleunigt wird, dadurch, dass es in der VM läuft. Und es kann auch sein, dass der eigene Manager bestimmte Antworten hat, dass man einigermaßen schnell arbeitet. Das heißt, man kann sich dann nicht den ganzen Tag mit beschäftigen. Ein anderer Faktor für mich ist Zuverlässigkeit. Denn sobald eure Software crashed oder der Server down ist oder sowas, dann soll es möglich sein, obwohl ich im Urlaub bin, das ist anders aus dem Team. Die Situation lösen kann. Und auch so was wie der Busfaktor ist im Prinzip das Schlagwort für Convenience. Ist natürlich auch ein großes Thema. Robion Rates zum Beispiel hat da sehr viel vorgelegt. Und was ich tatsächlich auch eher nerviger als nützlich finde, dann ist es tatsächlich immer relativ schwer, die Ressourcen mit anderen Entwicklern zu teilen, wenn man nicht genau im selben Raum ist. Das heißt, per Programming ist relativ schwierig. Ein anderes Problem, das ich gesehen habe, ist, wenn man jemandem Code unterjubeln möchte, dann ist es relativ schwer, wenn man irgendwelchen Codes im Internet auscheckt, dass man sich nicht unbedingt immer sicher sein kann, ob das jetzt tatsächlich böswürdiger Code ist oder nicht, oder ob jemand Code in ein Repository initiieren will, dass man selber maintained. Schauen wir zum Beispiel mal Fishing an als Angriffsmöglichkeit. Ihr seht vielleicht den Cursor auf der linken Seite. Das hier ist kein voller Pfad, sondern nur ein Domainname. Die Slashes hier drin sind spezielle UTF-8-Zeichen. Das heißt, das blüht es tatsächlich auf einen Hostname auf. Das könnte jetzt sein, dass wir tatsächlich hier einfach irgendwas anderes ausdiefern, als das, was wir erwarten. Ich habe hier zum Beispiel auf dem Host einen ... Ich habe hier ... Ja, ein etc. Hosts-File tatsächlich diese Domain eingetragen. Es ist tatsächlich ein bisschen komisch, dass dort eine Domain ist, aber das würde prinzipiell funktionieren. Also ich habe es nur in etc. Hosts eingetragen, damit ich die Domain nicht kaufen muss. Das heißt, die Anfrage nach der Datei, dieser aussieht, als ob wir das .zip-File herunterladen würden, leitet eigentlich direkt auf unseren lokalen Webserver oder im Angriffsfall auf den Angreiferserver. Das heißt, hier könnten wir jetzt irgendwelche büsartigen Code auf den Entwicklerrechner schleusen. Dann gibt es zum Beispiel die Situation, dass man irgendwo im Internet ein Stück Code sieht, den nützlich findet und den dann kopiert. Und auf der linken Seite seht ihr den Code in HTML und auf der rechten Seite seht ihr das Ergebnis. Und wenn man das dann kopiert, dann zeigt euch das Ergebnis, etwas ist, das man gar nicht erwartet hat. Das könnte, wenn ihr da jetzt nicht genau hinschaut, euer Projekt kompromittieren. Also, ja, jetzt geht es weiter. Ein anderes Beispiel ist, wie man Ascii-Zeichen, Kontrollzeichen verwenden kann, um Sachen ... Wie man Sachen verstecken kann, von der Ausgabe auf den Terminal. Was man oben sieht, Harmless Script SH ist ein kleines bisschen länger, als man vielleicht im ersten Moment erwarten würde. Aber man vielleicht bemerkt man das nicht. Und wenn man das beim Hex-Editor sich anguckt, dann sieht man, dass da mehr passiert, als nur ein Echo-Fu. Und wie man sieht, es wird ja eine Datei-Port.txt angelegt. Und das könnte natürlich auch was deutlich gefährlicherer sein. Ein weiteres Beispiel, was ich online gefunden habe, man kann eine ... wenn man die richtige Byte-Sequenz kennt, dann kann man das sogar mit Git benutzen. Man kriegt vielleicht noch nicht mal mit, dass das überhaupt passiert ist. Ich habe ein leeres Getreepo angelegt, habe das Skript hinzugefügt, und dann habe ich eine kleine Verbesserung dem Skript hinzugefügt. Das ist der bösartige Komet. Und wenn ich mir den Diff angucke, dann ... dann sehe ich, dass der böse Code gar nicht sichtbar ist. Und das ist natürlich sehr gefährlich. So, was können wir dagegen tun? Das Beste, was man machen kann, ist, das für den Angreifer möglichst teuer zu machen. Wenn man das rausbekommt, dann, wenn man zumindest hinterher herausfindet, was schiefgegangen ist, dann kann man zumindest ... Gegenmaßnahmen zumindest nachträglich einbauen. Da können andere davon lernen. Was man auch machen kann, ist, die Software durch externe Services testen lassen. Zum Beispiel hat GitHub kürzlich eingeführt, dass man seine Pakete testen kann gegen bekannte Schwachstellen. Und das Beste, was man auf seinem eigenen System machen kann, ist, einzelne Einheiten zu bilden, Compartments in denen dann die gefährlichen Sachen auszuführen. Und das ganz wichtig natürlich, unveränderliche Backups, damit, wenn irgendwas schiefgeht, dass man hinterher entweder die richtigen Daten wieder herstellen kann, aber eben auch rausfinden kann, was da eigentlich genau passiert ist. Es gibt ein paar gute Tools, um einen Angriff festzustellen. Mein Lieblings-Tool ist Detrace. Und man kann ein paar spezifische Regeln setzen, um sein Projekt zu schützen. Ich kann euch hier keine Beispiele geben, aber man kann zum Beispiel prüfen, ob auf ITC PassWD zugegriffen wird. Und es ist sehr wichtig, davon Backups zu haben, denn im Moment des Angriffs könnte das natürlich sofort verändert werden. Wenn man eine VRM pro Projekt hat, die man ein halbes Jahr lang laufen lässt, dann hat man eigentlich nichts gewonnen. Dann vergisst man viele Sachen, und dadurch wird es sehr gefährlich. Das Beste ist, wenn man jedes Mal, wenn man anfängt zu arbeiten, einfach wieder alles neu von vorne aufbaut. Wenn man virtualisierte Server-Umgebung hat, dann kann man sehr viel mehr Monitoring machen, dass den Speicher des Netzwerks, und man kann die VRM auch einfach anhalten und mit einem früheren Snapshot vergleichen, um zu sehen, was sich tatsächlich getan hat. Sehr wichtig, es ist sehr wichtig, die Accounts voneinander getrennt zu halten. Zum Beispiel gibt es Leute, die seit vielen Jahren Contributions ganz vielen Systemen machen. Wenn man zu viele Projekte vom selben System aus modifiziert, zum Beispiel hat GitHub kein Zukunftsschutz für den SSH-Schlüssel. Deshalb kann man dann mit einem SSH-Schlüssel an ganz vielen Projekten Änderungen vornehmen. Das Beste ist, man hat ein GitHub-Account für ein Projekt oder ganz wenige Projekte und man benutzt dann jeweils den richtigen Account für das jeweilige Projekt. Wenn einer dieser Schlüssel komprimitiert wird oder eine dieser Umgebungen komprimitiert wird, dann können zumindest an den anderen Projekten keine Schäden durchgeführt werden. Ein besseres Zukunftsmodell wäre, deshalb ist einem erlaubenwürde, den Zugriff feingannularer zu steuern. Eine Möglichkeit ist auf jeden Fall, eine Organisation anzulegen, weil da man sehr viel mehr Rechte konfigurieren kann. Nächster Schritt ist es wichtig, die verantwortliche Position für die Sicherheit zu definieren. Wenn man eine Sicherheitslücke findet, dann ist die Frage, wie man damit umgeht. Man macht nicht einfach ein Issue auf, weil jeder sofort wüsste, dass es ein Sicherheitsproblem gibt, sondern mit wem redet man dann. Es gibt eine ganze Reihe von Projekten, die entweder keine Adresse haben oder zwar eine haben, aber auf E-Bails an dieser Adresse gar nicht antworten. Okay, und das war es soweit. Ich habe euch jetzt gerade meine Erfahrungen gezeigt, was ich so in verschiedenen Projekten, an denen ich gearbeitet gesehen habe. Das war meine Zusammenfassung, was für euer Projekt schädlich oder gut sein könnte. Danke, wir haben Zeit für Fragen. Bitte kommen wir zum Schluss. Wir haben eine Frage aus dem Internet. Wie sieht es aus mit Git Signed Comments? Ja, sobald man signierte Comments hat und tatsächlich auch eine E-Mail existiert mit dem selben PGB-Key, dann ist das für mich ein Zeichen, dass euer PGB-Key auf dem selben Host ist, wie die Githo, die vielleicht diesen GPGB-Key dann liegen und euren Rechner angreifbar machen. Das heißt, ich finde zwar viele, ich finde es grundsätzlich gut, Comments zu signieren, aber ihr müsst dann darauf schauen, dass der GPGB-Key nicht durch euer Development-Setup kompromittiert werden kann. In diesem Fall von GitDiv schiebt Git die Daten nicht durch lesdurch und lesdfiltert die Daten aus. Wir können uns auch mal, also grundsätzlich passiert es nicht, aber wir können mal auf dem Blog-Post schauen und sehen, ob man das Video darf. Wir können uns auch mal, also grundsätzlich passiert es nicht, aber wir können mal auf dem Blog-Post schauen und sehen, ob man das Video da findet. So, wir sehen hier das Video. Ja, es ist tatsächlich vielleicht besser, das aus der Video-Animation zu sehen, weil das einfach einfacher zu verstehen ist, als von der HTML-Folie. Also meistens, wenn man hier ein Les anschaut oder Review zu machen, dann würde man das sehen. Ich denke, wenn ich, also vielleicht ist es auch nur, wenn man längere Diffs hat und dann wird er es les ausgeführt. Du hast erwähnt, dass Travis Zugriff auf Variablen hat und dass pull requests diese Daten gelegt werden können. Gibt einfach Leuten oder irgendwelchen externen Parteien keinen Schreibzugriff auf eure Projekte, nicht mal auf irgendwelche Branches oder so. Also ich mag dieses Security-Modell schon lang deswegen, weil weil dann niemand von außerhalb der einen Auto-Bild triggern kann oder sowas, aber er im Projekt schaden kann. Also wenn er von außen kommt und das nicht im selben Repo ist, dann sind die Ganzen nicht verschlüsselt. Und das heißt, man würde niemals direkt, also man sollte es so einrichten, dass man niemals direkt von einem fremden Branch deployen kann. Das ist ein Problem mit unterschiedlichen Compartments erwähnt. Das Problem wurde bereits mit Vagrant und Ansible gelöst. Hast du Erfahrung damit, wie man die Ergebnisse der Provisionierung von solchen VirtualBox-VMs überprüfen kann? Vielleicht mit Hashing oder ob die Maschine genau gleich aufgesetzt wurde. Man kann das dann auf verschiedenen Leveln betrachten. Also das Grundsätzlichste, was wäre das wenigste Problem in der Environment, man kann zum Beispiel einfach jedes Mal den Speicherdampen, das hat nochmal genau deine Frage. Möchtest du checken, dass die Umgebung dir da gestaltet hat, wie man das jetzt überprüfen kann, wie man so eine Umgebung darauf überprüfen kann, ob die so ist, wie sie sein soll. Ich habe solche Umgebungen benutzt und ich habe zuerst versucht, eine volle Verschlüsselung für die Vagrant-Box, aber das Problem ist, man muss dafür immer den selben Schlüssel verwenden und das funktioniert. Über ein Memory-Dump kann man natürlich auch die Schlüssel auslesen und es gibt keine Möglichkeit, eine Vagrant-Box aufzusetzen, an der man nicht hinterher Veränderungen vornehmen kann. Es muss eine Möglichkeit geben, die Ergebnisse miteinander zu vergleichen. Wenn du ein reproduzierbarer Bild hast, zum Beispiel in den Skript-Sprachen, dann ist es einfacher, wenn man da direkt die Dateis-Themen-Direktories diffen kann. Was ich in dem Fall machen würde, ist, dass man mehrere Server laufen lassen kann und die Ergebnisse vergleichen lassen kann. Das heißt, wenn man reproduzierbare Bilds hat, dann kann man einfach mehrere Server aufsetzen und alle das bauen und vergleicht man die Ergebnisse und kann dann daraus erkennen, ob etwas kompromittiert ist. Um Credentials in Firewalls zu managen, man braucht in Spring Boot und anderen solchen Systemen die Möglichkeit, Username und Passwort zu hinterlegen. Wie geht man damit am besten um? Kann man das explizit verschlüsseln in der Applikation? Dann braucht man weitere Schlüssel. Enzybil kommt zum Beispiel mit dem Enzybil Vault-Mechanismus, der die Secrets mit einer interaktiv eingegebenen Passphrase verschlüsselt. Das heißt, wenn alle Entwickler dieses Passwort kennen, dann hat jeder Entwickler Zugriff auf jeden Schlüssel. Mir wäre es allerdings lieber, jedem Gerät einen anderen Schlüssel zu geben, wenn das irgendwie möglich ist. Im Prinzip ist das dasselbe mit den GitHub-Accounts. Man benutzt nicht ein GitHub-Account, sondern man benutzt viele. Einige deiner Empfehlungen sind, wenn man die Low-Hanging-Fruit einfach umzusetzen. Benutzt du alle jeden Tag oder nur einige davon? Das hängt vom Projekt ab. Was ich auf meinem Entwicklungssystem versuche, ist, dass ich zumindest diese Compartments habe, dass ein Common-Begits-Projekt die anderen nicht angreifen kann. Ich bin eben nicht der einzige, der zu diesen Projekten Code beiträgt. Das heißt, der kann dann nicht mal reviewt werden. Ich kann natürlich nicht jeden Code anschauen, der auf meinem System läuft, reviewen. Aber ich kann das zumindest abschleichen, den Effekt, den das haben kann. Welches Tool würdest du für die Untersuchung des Dateisystems empfehlen? Diff einfach. Also für mich funktioniert das. Wo ist genau das Problem? Vielleicht möchte ich nur sehen, ob sich welche Hashes geändert haben. Also kann man die Verzeichnisse haschen oder so. Aber im Prinzip, sobald ich ein Indikator habe, dass irgendetwas falsch ist, dann würde ich einfach die Tools nehmen, die ich verfügbar hab, zum Beispiel auch ein Ex-Editor oder so was. Vielen Dank. Und damit verabschieden.