Sicherheitslücke im MIGS-Hash-Algorithmus

Mit dem Aufkommen von Kreditkarten und dem Internet ist das Einkaufen viel einfacher und sicherer geworden. Nur ein paar Klicks und das Produkt, das Sie benötigen, ist bereits auf dem Weg zu Ihnen nach Hause. Es sind jedoch nicht alle Systeme ideal oder es gibt keine. Sie können immer einen Fehler finden, eine Lücke, die es Angreifern ermöglicht, ihre schmutzige Tat zu vollbringen. Heute möchte ich Ihre Aufmerksamkeit auf die Studie eines sehr talentierten Programmierers Yohanes Nugroho lenken, der über Schwachstellen im MIGS-System sprach.

Dieser Text ist eine Übersetzung der Worte des Vulnerabilitätsforschers Yohanes Nugroho. Hab eine schöne Zeit.

Sicherheitslücke im MIGS-Hash-Algorithmus

Letztes Jahr habe ich einen Fehler im MD5-basierten Hash-Algorithmus entdeckt, der von MIGS (Mastercard Internet Gateway Service) verwendet wird. Sie konnten Änderungen an der Größe der Transaktion vornehmen. Das Unternehmen hat mich für die Entdeckung dieses Problems belohnt. Im selben Jahr wechselte MIGS zur Verwendung des HMAC-SHA256, es gab jedoch einige Sicherheitslücken.

Was ist MIGS?

Wenn Sie auf einer Website bezahlen, verbinden die Eigentümer ihr System normalerweise mit einem Zwischenzahlungs-Gateway (es gibt einen Übergang zu einer anderen Seite). Dieses Zahlungsgateway ist dann mit mehreren in einem bestimmten Land verfügbaren Zahlungssystemen verbunden. Bei Kreditkarten stellen viele Gateways eine Verbindung zu anderen Gateways her (eines davon ist MIGS), die mit vielen Banken zusammenarbeiten, um 3DSecure bereitzustellen.

Wie funktioniert es

Wenn Sie MIGS verwenden, sieht die Zahlungssequenz normalerweise folgendermaßen aus:

1. Sie wählen ein Produkt auf der Website aus.
2. Geben Sie Ihre Kreditkartennummer ein.
3. Die Kartennummer, die Zahlungsgröße und andere Parameter werden signiert und an den Browser zurückgegeben, der automatisch eine POST-Anforderung an das Zwischenzahlungs-Gateway generiert.
4. Dieses Gateway konvertiert Informationen in ein von MIGS unterstütztes Format, signiert mit einem MIGS-Schlüssel und gibt sie an den Browser zurück. Danach generiert der Browser eine weitere POST-Anfrage an den MIGS-Server.
5. Wenn 3DSecure nicht aktiviert ist, wird dieser Schritt übersprungen. Andernfalls leitet MIGS die Anfrage an die Bank weiter, die die Karte ausgestellt hat. Die Bank fordert OTP an und generiert HTML, das eine POST-Anforderung für den MIGS-Server generiert.
6. MIGS gibt die signierten Daten an den Browser zurück und erstellt eine POST-Anforderung für das Zwischenzahlungs-Gateway.
7. Validierung von Daten und Signatur durch ein Zwischenzahlungs-Gateway. Wenn die Daten falsch sind, wird eine Fehlerseite generiert.
8. Basierend auf der MIGS-Antwort überträgt das Zahlungsgateway den Zahlungsstatus an den Verkäufer.

Sicherheitslücke im MD5-Hashing-Algorithmus

Dieser Fehler ist sehr einfach. Die Hash-Methode verwendet die folgende Formel:

MD5 (Geheimnis + Daten)

Es gibt jedoch keine Sicherheitsanfälligkeit für Hash-Erweiterungen (einige Überprüfungen wurden durchgeführt, um dies zu verhindern). Daten werden auf diese Weise gebildet: Alle Anforderungsparameter, die mit vpc_ beginnen, werden sortiert, wonach die Werte ohne Trennung verbunden werden. Zum Beispiel haben wir die folgenden Daten:

Name: Joe
Betrag: 10000
Karte: 1234567890123456

vpc_Name = Joe & Vpc_Amount = 10000 & vpc_Card = 1234567890123456

Sortierung anwenden:

vpc_Amount = 10000
vpc_Card = 1234567890123456
vpc_Name = Joe

Wir verbinden die Werte:

100001234567890123456Joe

Beachten Sie, wenn ich die Parameter ändere:

vpc_Name = Joe & Vpc_Amount = 1 & vpc_Card = 1234567890123456 & vpc_B = 0000

Sortierung anwenden:

vpc_Amount = 1
vpc_B = 0000
vpc_Card = 1234567890123456
vpc_Name = Joe

Wir verbinden die Werte:

100001234567890123456Joe

Dieser MD5-Wert ist der gleiche. Das heißt, wenn die Daten an MIGS übertragen werden, können wir nach der Zahlungsgröße einen zusätzlichen Parameter hinzufügen, um die letzte Ziffer zu entfernen, oder davor - um die erste zu entfernen. Und Sie können 2 statt 2000 US-Dollar für ein MacBook bezahlen.

Fortgeschrittene Gateways und Händler können diese Sicherheitsanfälligkeit vermeiden, indem sie immer prüfen, ob der von MIGS zurückgegebene Zahlungsbetrag dem angeforderten entspricht.

MasterCard belohnte mich für die Identifizierung dieses Fehlers mit einer Prämie von 8500 USD.

HMAC-SHA256 Hash-Sicherheitsanfälligkeit

Der neue HMAC-SHA256 weist eine Sicherheitsanfälligkeit auf, die ausgenutzt werden kann, wenn falsche Werte in das Gateway für Zwischenzahlungen eingefügt werden. Ich habe auf einem der Zahlungsgateways (Fusion Payments) nach diesem Fehler gesucht. Sie zahlten mir dafür einen Bonus von 500 Dollar. Diese Sicherheitsanfälligkeit kann sich auch auf andere mit MIGS verbundene Zahlungsgateways auswirken.

In der neuen Version wurden Trennzeichen (&) zwischen Feldern, Feldnamen (nicht nur Werte) und natürlich HMAC-SHA256 hinzugefügt. Für die gleichen Daten wie zuvor sieht die Hash-Zeile folgendermaßen aus:

Vpc_Amount = 10000 & vpc_Card = 1234567890123456 & vpc_Name = Joe

Wir können nichts bewegen, alles in diesem Plan ist in Ordnung. Aber was ist, wenn der Wert die Zeichen & oder = oder einen anderen enthält?

Nachdem ich das Referenzdokument zur Integration des MiGS Virtual Payment Client gelesen hatte, stellte ich fest:

"Hinweis: Der Wert in allen Name / Wert-Paaren darf zum Zwecke des Hashings KEINE URL-Zeichen enthalten."

Ich konzentriere mich auf NICHT . Dies bedeutet, wenn wir die folgenden Felder haben:

Betrag = 100
Karte = 1234
CVV = 555

Das Hashing sieht folgendermaßen aus: HMAC (Betrag = 100 & Karte = 1234 & CVV = 555)

Und wenn die Felder so sind (mit & und =):

Betrag = 100 & Karte = 1234
CVV = 555

Dieser Hash sieht folgendermaßen aus: HMAC (Betrag = 100 & Karte = 1234 & CVV = 555)

Genau so. Aber bisher kein solches Problem.

Natürlich dachte ich, dass es ein Problem in der offiziellen Dokumentation geben könnte, vielleicht sollten noch URL-Zeichen verwendet werden. Aber ich habe das Verhalten des MIGS-Servers überprüft, alles war wie im Dokument. Vielleicht möchten sie nicht mit einer anderen Codierung arbeiten (wie + anstelle von% 20).

Es scheint, dass es keine Probleme geben sollte. Falsche Werte werden von MIGS überprüft und geben einen Fehler aus (z. B. wird die falsche Zahlungsgröße abgelehnt).

Ich habe jedoch festgestellt, dass in einigen Zahlungsgateways die eingegebenen Daten nicht auf der Serverseite überprüft werden, sondern einfach alles signiert und an MIGS umgeleitet wird. Es ist viel einfacher, JavaScript-Überprüfungen auf der Clientseite durchzuführen, die Daten auf der Serverseite zu signieren und dann MIGS entscheiden zu lassen, ob die Kartennummer korrekt ist, ob CVV aus 3 oder 4 Ziffern bestehen soll, ob die Karte korrekt abläuft usw. Die Logik lautet wie folgt: MIGS überprüft die Daten noch einmal und verbessert sie.

Bei Fusion Payments habe ich herausgefunden, dass dies der Fall ist: Sie können beliebig lange CVV-Codes eingeben (die Überprüfung erfolgt nur in JavaScript), die Anforderung signieren und an MIGS senden.

Ausnutzen

Um diese Sicherheitsanfälligkeit auszunutzen, müssen wir eine Zeichenfolge erstellen, die die richtige Anforderung darstellt und die richtige Antwort vom MIGS-Server erhält. Wir müssen nicht mit dem MIGS-Server kommunizieren, sondern lassen den Client nur die richtigen Daten signieren.

Grundlegende Anfrage:

vpc_AccessCode = 9E33F6D7 & vpc_Amount = 25 & vpc_Card = Visa & vpc_CardExp = 1717 & vpc_CardNum = 4599777788889999 & vpc_CardSecurityCode = 999 & vpc_OrderInfo = vdcurecure

Die grundlegende Antwort des Servers lautet wie folgt:

vpc_Message = Genehmigt & vpc_OrderInfo = ORDERINFO & vpc_ReceiptNo = 722819658213 & vpc_TransactionNo = 2000834062 & vpc_TxnResponseCode = 0 & vpc_SecureHash = THEHASH & vp25_ec

Bei Fusion Payment wird der Exploit durch Implementierung von vpc_CardSecurityCode (CVV) implementiert.

vpc_AccessCode = 9E33F6D7 & vpc_Amount = 25 & vpc_Card = Visa & vpc_CardExp = 1717 & vpc_CardNum = 4599777788889999 & vpc_CardSecurityCode = 999% 26vpc_Message% 3DApproved% 26vpc_OrderInfo% 3DORDERINFO% 26vpc_ReceiptNo% 3D722819658213% 26vpc_TransactionNo% 3D2000834062% 26vpc_TxnResponseCode% 3D0% 26vpc_Z% 3DA & vpc_OrderInfo = Order & vpc_SecureHash = THEHASH & vpc_SecureHashType = SHA256

Das Client / Zahlungs-Gateway generiert den richtigen Hash für diese Zeile.

Jetzt können wir diese Daten in den Client selbst eingeben (ohne in irgendeiner Weise mit dem MIGS-Server zu interagieren), aber wir werden sie ein wenig ändern, damit der Client die erforderlichen Variablen erkennt (die meisten Clients überprüfen nur vpc_TxnResponseCode und vpc_TransactionNo):

vpc_AccessCode = 9E33F6D7% 26vpc_Amount% 3D25% 26vpc_Card% 3DVisa% 26vpc_CardExp% 3D1717% 26vpc_CardNum% 3D4599777788889999% 26vpc_CardSecurityCode% 3D999 & vpc_Message = Approved & vpc_OrderInfo = Order & vpc_ReceiptNo = 722819658213 & vpc_TransactionNo = 2000834062 & vpc_TxnResponseCode = 0 & vpc_Z = a% 26vpc_OrderInfo% 3DORDERINFO & vpc_SecureHash = THEHASH & vpc_SecureHashType = SHA256

Hinweis:

Das Hashing ist das gleiche wie bei den vorherigen Daten.
Der Client ignoriert vpc_AccessCode und seinen Wert.
Der Client verarbeitet vpc_TxnResponseCode usw., sofern die Transaktion korrekt ist.

Es kann gesagt werden, dass dies ein MIGS-Clientfehler ist, aber die von MasterCard verwendete Hash-Methode lässt diesen Fehler zu. Wenn die Werte codiert wären, wäre diese Sicherheitsanfälligkeit nicht vorhanden.

Antwort von MIGS

MasterCard hat auf diesen Fehler im HMAC-SHA256 nicht reagiert. Ich habe mehrere Personen kontaktiert, die ich zuvor wegen einer früheren Sicherheitsanfälligkeit kontaktiert hatte. Es gibt keine Antwort. Sogar das Abbestellen im Stil von "Wir testen es". Sie haben mein Facebook, wenn sie mich kontaktieren wollen (seit der Korrespondenz über MD5).

Einige tun anscheinend so, als hätten sie meinen Bericht nicht gesehen, aber ich habe dem Brief ein Passwort gegeben. Es gab mindestens 3 Ansichten von der MasterCard-IP-Adresse. Gleichzeitig sind dies keine zufälligen Klicks ohne Lesen, da Sie das Passwort bewusst eingeben müssen. Ich schreibe ihnen jede Woche.

Meine Erwartung war, dass sie jeden, der eine Verbindung zu ihrem System herstellt, warnen würden, eingebettete Daten zu überprüfen und herauszufiltern.

Lücken in Zahlungsgateways

Darüber hinaus möchte ich sagen: Trotz der Tatsache, dass Zahlungsgateways mit Geld umgehen, sind sie nicht so sicher, wie es scheint. Während meiner Pentests (Penetrationstests) entdeckte ich mehrere Schwachstellen in den Zahlungsprotokollen in mehreren Zwischen-Gateways. Leider kann ich die Details nicht mitteilen (wenn ich "Pentest" sage, fällt dies unter die Geheimhaltungsvereinbarung).

Ich habe auch Implementierungsfehler gefunden. Zum Beispiel Hash-Erweiterungsangriffe, XML, Fehler bei der Signaturüberprüfung usw. Einer der einfachsten Fehler, den ich in Fusion Payments gefunden habe. Der erste Fehler, den ich gefunden habe, war: Sie überprüfen nicht einmal die Signaturen von MIGS. Dies bedeutet, dass wir einfach die von MIGS zurückgegebenen Daten ändern und die Transaktion als erfolgreich markieren können. Dies bedeutet nur, ein Zeichen zu ändern: von F (nicht erfolgreich) auf 0 (erfolgreich).

Das heißt, wir können eine beliebige Kartennummer eingeben, eine falsche Antwort von MIGS erhalten, diese ändern und plötzlich wird die Zahlung erfolgreich. Dies ist ein Unternehmen mit einem Budget von 20 Millionen, und ich habe 400 Dollar von ihnen erhalten. Dies ist nicht das einzige Zahlungsgateway mit einer solchen Sicherheitsanfälligkeit. Während meines Pentests habe ich dies in anderen Gateways gefunden. Trotz der geringen Belohnung ist Fusion Payments derzeit das einzige Zahlungsgateway, mit dem ich Kontakt aufgenommen habe. Dies wird in seinem Belohnungsprogramm für gefundene Fehler sehr deutlich. Sie haben sehr schnell auf meine Nachrichten reagiert und ihre Fehler schnell behoben.

Fazit

Zahlungsgateways sind nicht so sicher wie Sie denken. Bei solch geringen Belohnungen (und in einigen Fällen habe ich 0 US-Dollar erhalten) frage ich mich, wie viele Leute diese Sicherheitslücken bereits in Zahlungsgateways ausgenutzt haben.

Bemerkung des Übersetzers

Von mir selbst möchte ich den Schlussfolgerungen des Autors der Studie einige Worte hinzufügen. Zuallererst ist diese Studie eine Warnung und ein Aufruf zur Vorsicht für Verkäufer, da die gefundenen Sicherheitslücken sie zu Opfern von Eindringlingen machen. Es gibt jedoch viele andere Fehler, die für Kunden schädlich sein können (Karteninhaber, Benutzer von Zahlungssystemen usw.). Seien Sie vorsichtig, wenn Sie Ihre persönlichen Rechnungsinformationen auf einer nicht verifizierten Website eingeben. Besser noch, Sie haben eine separate Bankkarte zur Verfügung, auf der genau der Betrag angegeben ist, den Sie für einen Kauf im Internet benötigen.

Haben Sie Fehler in Zahlungssystemen festgestellt oder waren Sie sogar Opfer solcher Fehler? Teilen Sie Ihre Erfahrungen, Meinungen und Tipps, wie Sie sich schützen können, in den Kommentaren mit. Ich wünsche Ihnen einen schönen Tag und sichere Einkäufe.

Als Werbung. Förderung! Erst jetzt können Sie VPS (KVM) mit dedizierten Laufwerken in den Niederlanden und den USA bis zu 4 Monate kostenlos nutzen (Konfigurationen von VPS (KVM) - E5-2650v4 (6 Kerne) / 10 GB DDR4 / 240 GB SSD oder 4 TB HDD / 1 Gbit / s 10 TB - 29 USD / Monat und höher, Optionen mit RAID1 und RAID10 sind verfügbar) , ein vollwertiges Analogon dedizierter Server. Wenn Sie für einen Zeitraum von 1-12 Monaten bestellen, sind die Bedingungen der Aktion hier, bestehende Abonnenten können 2 Monate als Bonus erhalten!

Wie man die Infrastruktur des Gebäudes baut. Klasse mit Dell R730xd E5-2650 v4 Servern für 9.000 Euro für einen Cent?