Einführung von Missions: Die nächste Phase der entwicklerzentrierten Sicherheitsschulung

Seit 2015 begeistern wir Entwickler weltweit mit einem proaktiven, positiven Ansatz für Sicherheit. Wir helfen ihnen dabei, die Fähigkeiten zu entwickeln, ihren Code abzusichern, Nachbesserungen und Fehlerbehebungen zu reduzieren und das Sicherheitsteam hoffentlich nicht mehr als „Spaßbremsen“ zu sehen.

Wir stehen Entwicklern weiterhin zur Seite, während sie Code in der gesamten Galaxie absichern. Aber es ist an der Zeit, neue Wege zu gehen und unsere kampferprobten, sicherheitsbewussten Entwickler auf das nächste Level zu heben.

Wir freuen uns, eine brandneue Funktion auf der Secure Code Warrior-Plattform ankündigen zu können: Missions. Diese völlig neue Kategorie von Herausforderungen ist der nächste Schritt in der entwicklerorientierten Sicherheitsschulung und führt die Nutzer von der reinen Wissensabfrage hin zur Anwendung in einer realitätsnahen Simulationsumgebung. Dieser strukturierte Microlearning-Ansatz baut fundierte Fähigkeiten für sicheres Programmieren auf, die praxisrelevant und deutlich unterhaltsamer sind, als während des Arbeitstages endlos lange Schulungsvideos anzusehen.

Unsere erste spielbare, öffentliche Mission ist eine Simulation der GitHub Unicode-Sicherheitslücke. Sie mag täuschend einfach erscheinen, aber es ist eine wirklich raffinierte Schwachstelle, deren Analyse Spaß macht. Der Sicherheitsforscher 0xsha hat eine umfassende Fallstudie darüber verfasst, wie derselbe Fehler genutzt werden kann, um Django mittels Case-Transformationen anzugreifen, und zeigt zudem, wie sich das Verhalten der Schwachstelle je nach Programmiersprache unterscheiden kann. Es gibt noch viel mehr über dieses Sicherheitsproblem zu entdecken, und unsere Mission ist der ideale Ausgangspunkt.

GitHubs Frontalzusammenstoß (Case Mapping)

In einem Blogbeitrag vom 28. November 2019 berichtete die Sicherheitsforschungsgruppe Wisdom über einen Sicherheitsfehler, den sie auf GitHub entdeckt hatten. Sie legten dar, wie sie eine Case Mapping Collision in Unicode ausnutzen konnten, um eine E-Mail zur Passwortzurücksetzung an die falsche E-Mail-Adresse zu senden (oder, aus der Sicht eines Angreifers, an eine E-Mail-Adresse nach Wahl des Akteurs).

Auch wenn eine Sicherheitslücke nie eine gute Nachricht ist, erweisen Sicherheitsforscher mit „Whitehat“-Absichten einen großen Dienst – ganz zu schweigen von der Möglichkeit, eine Katastrophe abzuwenden –, wenn sie potenziell ausnutzbare Fehler in einer Codebasis entdecken. Ihre Blogs und Berichte sind oft sehr lesenswert, und es ist faszinierend zu erfahren, wie eine neue Schwachstelle funktioniert.

Um das nächste Level an Kompetenz im sicheren Programmieren zu erreichen, ist es enorm hilfreich, nicht nur gängige Schwachstellen zu finden (insbesondere coole neue – wir wissen alle, dass böswillige Akteure nach fruchtbarem Boden suchen, um mit diesen neuen Techniken Daten zu erbeuten), sondern auch eine sichere, praktische Umgebung zu haben, um zu verstehen, wie man sie ausnutzt.

Genau das wollen wir tun. Lesen Sie weiter, um zu erfahren, wie eine Case Mapping Collision in Unicode ausgenutzt werden kann, wie sie in Echtzeit aussieht und wie Sie die Denkweise eines Sicherheitsforschers einnehmen und es selbst ausprobieren können.

Bereit, sich jetzt einer Case Mapping Collision zu stellen? Dann legen Sie los:

Unicode: Komplex, unendlich anpassbar und weit mehr als nur Emojis

„Unicode“ gehört vielleicht nicht zum Wortschatz des Durchschnittsbürgers, aber die Wahrscheinlichkeit ist groß, dass die meisten Menschen es täglich in irgendeiner Form nutzen. Wenn Sie einen Webbrowser oder eine Microsoft-Software verwendet oder ein Emoji gesendet haben, sind Sie bereits mit Unicode in Berührung gekommen. Es ist ein Standard für die konsistente Kodierung und Verarbeitung von Text aus den meisten Schriftsystemen der Welt und stellt sicher, dass sich jeder (digital) mit einem einzigen Zeichensatz ausdrücken kann. Aktuell gibt es über 143.000 Zeichen – Sie sind also bestens versorgt, egal ob Sie Isländisch, das punktlose türkische „i“ oder irgendetwas dazwischen verwenden.

Aufgrund der schieren Menge an Zeichen, die Unicode umfasst, ist in vielen Fällen eine Möglichkeit erforderlich, Zeichen in ein anderes „äquivalentes“ Zeichen umzuwandeln. Zum Beispiel erscheint es sinnvoll, dass ein Unicode-String mit einem punktlosen „i“ bei der Konvertierung in ASCII einfach zu einem „i“ wird, oder?

Mit einer großen Menge an Zeichenkodierung kommt ein großes Potenzial für Katastrophen

Eine Case Mapping Collision in Unicode ist ein Geschäftslogik-Fehler und kann im Kern zur Übernahme von Konten führen, die nicht durch 2FA geschützt sind. Um die fragliche Schwachstelle zu veranschaulichen, schauen wir uns ein Beispiel dieses Fehlers in einem echten Code-Schnipsel an:

app.post(/api/resetPassword, function (req, res) {
  var email = req.body.email;
  db.get(SELECT rowid AS id, email FROM users WHERE email = ?, [email.toUpperCase()],
      (err, user) => {
          if (err) {
              console.error(err.message);
              res.status(400).send();
          } else {
              generateTemporaryPassword((tempPassword) => {
                  accountRepository.resetPassword(user.id, tempPassword, () => {
                      messenger.sendPasswordResetEmail(email, tempPassword);
                      res.status(204).send();
                  });
              });
          }
      });
});

Die Logik sieht in etwa so aus:

1. Sie akzeptiert die vom Benutzer bereitgestellte E-Mail-Adresse und wandelt sie zur Konsistenz in Großbuchstaben um.
2. Sie prüft, ob die E-Mail-Adresse bereits in der Datenbank existiert.
3. Falls ja, wird ein neues temporäres Passwort festgelegt (das ist übrigens keine bewährte Methode; verwenden Sie stattdessen einen Link mit einem Token, der eine Passwortzurücksetzung ermöglicht).
4. Anschließend wird eine E-Mail an die in Schritt 1 abgerufene Adresse gesendet, die das temporäre Passwort enthält (dies ist aus vielen Gründen eine sehr schlechte Praxis. Oh je.)

Schauen wir uns an, was mit dem Beispiel aus dem ursprünglichen Blogbeitrag passiert, bei dem ein Benutzer ein Passwort-Reset für die E-Mail-Adresse John@GıtHub.com anfordert (beachten Sie das türkische punktlose i):

1. Die Logik wandelt John@Gıthub.com in JOHN@GITHUB.COM um.
2. Sie sucht diesen Eintrag in der Datenbank und findet den Benutzer JOHN@GITHUB.COM.
3. Sie generiert ein neues Passwort und sendet es an John@Gıthub.com.

Beachten Sie, dass diese E-Mail mit den hochsensiblen Daten am Ende an die falsche Adresse gesendet wird. Hoppla!

So vertreiben Sie diesen Unicode-Dämon

Das Interessante an dieser speziellen Schwachstelle ist, dass mehrere Faktoren sie anfällig machen:

1. Das tatsächliche Verhalten bei der Unicode-Umwandlung.
2. Die Logik zur Bestimmung der zu verwendenden E-Mail-Adresse, d. h. die vom Benutzer angegebene Adresse anstelle der bereits in der Datenbank vorhandenen.

Theoretisch lässt sich dieses spezifische Problem auf zwei Arten beheben, wie im Blogbeitrag von Wisdom beschrieben:

1. Konvertierung der E-Mail in ASCII mittels Punycode-Umwandlung.
2. Verwendung der E-Mail-Adresse aus der Datenbank anstelle der vom Benutzer bereitgestellten.

Bei der Härtung von Software ist es ratsam, nichts dem Zufall zu überlassen und so viele Verteidigungsebenen wie möglich einzubauen. Wir wissen nicht, ob es noch andere Wege gibt, diese Kodierung auszunutzen – wir kennen sie nur noch nicht. Jeder Schritt zur Risikominimierung und zum Schließen potenzieller Sicherheitslücken ist wertvoll.

Bereit, es selbst auszuprobieren?

Die meisten Entwickler wissen, dass kompromittierte Daten geschäftsschädigend sind. Sicherheitsbewusste Ingenieure sind jedoch ein wirksames Gegenmittel gegen zunehmende Schwachstellen, Sicherheitsverletzungen und Cyber-Bedrohungen.

Es ist an der Zeit, Ihre Fähigkeiten im Bereich Secure Coding auf die nächste Stufe zu heben. Erleben Sie diese GitHub-Schwachstelle in einer immersiven, sicheren Simulation und sehen Sie die Auswirkungen von fehlerhaftem Code im Frontend und Backend. Angreifer sind im Vorteil – gleichen wir das Spielfeld aus und setzen wir echte White-Hat-Fähigkeiten ein.