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

Seit 2015 engagieren wir Entwickler auf der ganzen Welt mit einem proaktiven, positiven Ansatz für Sicherheit. Wir helfen ihnen, die Fähigkeiten aufzubauen, um ihren Code zu sichern, Nacharbeiten und Nachbesserungen zu reduzieren und das Sicherheitsteam hoffentlich als etwas anderes als die Spaßpolizei zu sehen.

Wir sind immer noch bestrebt, Entwicklern bei der Sicherung von Code in der ganzen Galaxie zur Seite zu stehen, aber es ist an der Zeit, die Dinge zu verändern und unsere kampferprobten, sicherheitsbewussten Entwickler auf die nächste Stufe zu heben.

Wir freuen uns, eine brandneue Funktion auf der Plattform Secure Code Warrior ankündigen zu können: Missions. Diese brandneue Kategorie von Herausforderungen ist die nächste Phase des Sicherheitstrainings für Entwickler, bei dem die Benutzer vom Abrufen von Sicherheitswissen zur Anwendung in einer realen Simulationsumgebung übergehen. Dieser gerüstete Mikro-Lernansatz baut starke sichere Programmierfähigkeiten auf, die berufsrelevant und viel unterhaltsamer sind als das (vertikale) Anschauen endloser Schulungsvideos im Hintergrund eines Arbeitstages.

Unsere erste spielbare, öffentliche Mission ist eine Simulation des GitHub Unicode-Bruchs. Es mag täuschend einfach erscheinen, aber es ist eine wirklich clevere Sicherheitslücke, die zu sezieren Spaß macht. Der Sicherheitsforscher 0xsha hat eine umfassende Fallstudie darüber erstellt, wie derselbe Fehler genutzt werden kann, um Django über Groß-/Kleinschreibungstransformationen auszunutzen, wobei er auch aufzeigt, wie sich das Verhalten der Schwachstelle zwischen verschiedenen Programmiersprachen ändern kann. Es gibt noch viel mehr über dieses Sicherheitsproblem zu entdecken, und unsere Mission ist ein großartiger Ort, um damit zu beginnen.

GitHubs Frontalzusammenstoß (Case Mapping)

In einem Blogbeitrag vom 28. November 2019 berichtete die Sicherheitsforschungsgruppe Wisdom über einen Sicherheitsfehler, den sie auf GitHub entdeckt haben. Sie beschrieben, wie sie eine Case-Mapping-Kollision in Unicode ausnutzen konnten, um die Zustellung einer E-Mail zum Zurücksetzen des Passworts an eine falsche E-Mail-Adresse auszulösen (oder, wenn wir wie ein Angreifer denken, an eine E-Mail-Adresse nach Wahl des Bedrohungsakteurs).

Während eine Sicherheitslücke nie eine gute Nachricht ist, bieten Sicherheitsforscher, die als "Whitehat" arbeiten, eine gewisse Gnade - 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 irgendwie cool, etwas über eine neue Sicherheitslücke und ihre Funktionsweise zu erfahren.

Um die nächste Stufe der sicheren Codierung zu erreichen, ist es immens wichtig, nicht nur allgemeine Schwachstellen zu finden (vor allem keine coolen neuen - wir alle wissen, dass böswillige Bedrohungsakteure nach fruchtbarem Boden suchen werden, um mit diesen neuen Techniken einige Daten auszugraben), sondern auch eine sichere, praktische Umgebung zu haben, um zu verstehen, wie man sie auch ausnutzen kann.

Also, lassen Sie uns genau das tun. Lesen Sie weiter, um zu erfahren, wie eine Case-Mapping-Kollision in Unicode ausgenutzt werden kann, wie sie in Echtzeit aussieht und wie Sie sich in die Denkweise eines Sicherheitsforschers versetzen und es selbst ausprobieren können.

Sind Sie bereit, jetzt eine Case Mapping-Kollision zu übernehmen? Treten Sie vor:

Unicode: Komplex, unendlich anpassbar und mehr als nur Emojis

"Unicode" ist vielleicht nicht im Lexikon der Durchschnittsperson, aber die Chancen stehen gut, dass die meisten Menschen es in irgendeiner Form jeden Tag benutzen. Wenn Sie einen Webbrowser oder eine Microsoft-Software verwendet oder ein Emoji verschickt haben, dann sind Sie mit Unicode auf Tuchfühlung gegangen. Dabei handelt es sich um einen Standard für die einheitliche Kodierung und Handhabung von Text aus den meisten Schriftsystemen der Welt, der sicherstellt, dass sich jeder (digital) mit einem einzigen Zeichensatz ausdrücken kann. Derzeit gibt es über 143.000 Zeichen, so dass Sie abgedeckt sind, egal ob Sie das Isländische oder das Türkische ohne Punkte oder irgendetwas dazwischen verwenden.

Aufgrund der schieren Menge an Zeichen, die Unicode in seinem Satz hat, wird in vielen Fällen eine Möglichkeit benötigt, Zeichen in ein anderes "gleichwertiges" Zeichen zu konvertieren. Zum Beispiel scheint es sinnvoll, dass, wenn Sie eine Unicode-Zeichenkette mit einem Punkt ohne nach ASCII konvertieren, diese einfach in ein "i" umgewandelt werden sollte, richtig?

Ein großes Volumen an Zeichenkodierung birgt ein großes Potenzial für Katastrophen

Eine Case-Mapping-Kollision in Unicode ist ein Fehler in der Geschäftslogik und kann im Kern zu einer Kontoübernahme von Konten führen, die nicht durch 2FA geschützt sind. Zur Veranschaulichung der fraglichen Schwachstelle sehen wir uns ein Beispiel für diesen Fehler in einem echten Codeschnipsel 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 geht in etwa so:

1. Er akzeptiert die vom Benutzer angegebene E-Mail-Adresse und schreibt sie aus Gründen der Konsistenz in Großbuchstaben
2. Es wird geprüft, ob die E-Mail-Adresse bereits in der Datenbank vorhanden ist
3. Wenn dies der Fall ist, wird ein neues temporäres Kennwort festgelegt (dies ist übrigens keine optimale Vorgehensweise. Verwenden Sie stattdessen einen Link mit einem Token, der ein Zurücksetzen des Passworts ermöglicht)
4. Es sendet dann eine E-Mail an die in Schritt 1 ermittelte Adresse, die das temporäre Kennwort enthält (dies ist aus vielen Gründen eine sehr schlechte Praxis. Igitt.)

Schauen wir uns an, was mit dem Beispiel aus dem ursprünglichen Blogeintrag passiert, in dem ein Benutzer eine Kennwortrücksetzung für die E-Mail 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. Es schaut in der Datenbank nach und findet den Benutzer JOHN@GITHUB.COM.
3. Es generiert ein neues Passwort und sendet es an John@Gıthub.com.

Beachten Sie, dass bei diesem Vorgang die hochsensible E-Mail an die falsche E-Mail-Adresse gesendet wird. Ups!

Wie man diesen Unicode-Dämon austreibt

Der interessante Aspekt dieser speziellen Schwachstelle ist, dass es mehrere Faktoren gibt, die sie angreifbar machen:

1. Das tatsächliche Unicode-Gießverhalten
2. Die Logik, die die zu verwendende E-Mail-Adresse bestimmt, d. h. die vom Benutzer bereitgestellte E-Mail-Adresse anstelle der bereits in der Datenbank vorhandenen Adresse.

Theoretisch können Sie dieses spezielle Problem auf zwei Arten beheben, wie in dem Blogbeitrag von Wisdom beschrieben:

1. Konvertieren der E-Mail in ASCII mit Punycode-Konvertierung
2. Verwenden Sie die E-Mail-Adresse aus der Datenbank und nicht die vom Benutzer angegebene Adresse

Wenn es um die Absicherung von Software geht, ist es eine gute Idee, nichts dem Zufall zu überlassen und so viele Verteidigungsschichten wie möglich einzurichten. Nach allem, was wir wissen, könnte es noch andere Möglichkeiten geben, diese Verschlüsselung auszunutzen - wir sind uns nur noch nicht darüber im Klaren. Alles, was Sie tun können, um das Risiko zu verringern und Fenster zu schließen, die für einen Angreifer offen bleiben könnten, ist wertvoll.

Sind Sie bereit, dies selbst auszuprobieren?

Die meisten Entwickler sind sich bewusst, dass kompromittierte Daten schlecht für das Geschäft sind. Doch sicherheitsbewusste Ingenieure sind ein wirksames Gegenmittel gegen wachsende Schwachstellen, Sicherheitsverletzungen und Cybersecurity-Probleme.

Es ist an der Zeit, Ihre Fähigkeiten in Bezug auf sicheres Coding und Awareness auf die nächste Stufe zu heben. Erleben Sie diese GitHub-Schwachstelle in einer immersiven, sicheren Simulation, in der Sie die Auswirkungen von schlechtem Code sowohl im Frontend- als auch im Backend-Kontext sehen können. Angreifer haben einen Vorteil, also lassen Sie uns das Spielfeld ausgleichen und echte Fähigkeiten mit einem Whitehat-Gegenschlag anwenden.