Kreditkarten sind anfällig für Brute-Force-artige Angriffe

(metin.nextc.org)

1 Punkte von GN⁺ 2 시간 전 | Noch keine Kommentare. | Auf WhatsApp teilen

PCI DSS beschränkt die Speicherung und Anzeige von Kartendaten, aber selbst mit erlaubten Informationen wie BIN, den letzten 4 Ziffern und dem Ablaufdatum lassen sich bei anderen Händlern weitere Zahlungsversuche fortsetzen
Über ein kompromittiertes Konto erhielt der Angreifer über die 3D Secure-Seite der Bank Informationen darüber, ob die Karte noch nutzbar ist, den Namen der Bank, die maskierte Kartennummer und das vollständige Ablaufdatum; etwa 6 Stunden später löste er bei mehreren Händlern Authentifizierungsversuche aus
Eine Payment card number (PAN) besteht aus IIN, Konto-Identifikator und Luhn-Prüfziffer; wenn Antworten des Payment Gateways erkennen lassen, welcher Wert falsch ist, werden Vermutungen zu PAN, Ablaufdatum und CVV deutlich einfacher
Die tatsächliche Testrate lag bei 6 Versuchen pro Sekunde, etwa 2 pro Sekunde und API; durch Proxys änderte sich die IP-Adresse ständig, und auch die Kartennummer wechselte fortlaufend, sodass Brute Force aus Sicht des Händlers schwer zu erkennen ist
Der Angreifer nutzte Händler mit 3D Secure-Ausnahme, um das auf einen niedrigen Betrag gesetzte Kartenlimit vollständig in ein E-Wallet zu verschieben; das Geld wurde per Chargeback zurückgeholt, aber die CVC2-Rate-Limits der Bank blockierten nur für einige Minuten

Was PCI DSS verhindert – und was offenbleibt

PCI DSS ist ein Industriestandard, der die minimalen Sicherheitsmaßnahmen für den Umgang mit sensiblen Bankdaten wie Kreditkartendaten definiert, und beschränkt Speicherung und Anzeige so, dass selbst bei einer Kontoübernahme oder Weitergabe von Kartendaten an Dritte nicht alle Informationen offengelegt werden
Nach PCI DSS 4 dürfen auf Bildschirmen oder Belegen eine maskierte PAN, der Name des Karteninhabers, der Servicecode und das Ablaufdatum angezeigt werden; bei der PAN dürfen BIN und die letzten 4 Ziffern sichtbar sein
Nicht angezeigt werden dürfen vollständige Track-Daten, der Kartenprüfcode sowie PIN/PIN-Block
Sowohl E-Commerce-Websites als auch physische Belege können von demselben Problem betroffen sein; teilweise können Kartendaten nicht nur durch kompromittierte Konten, sondern auch durch nicht vernichtete Belege offengelegt werden

Das Opfer nutzte eine virtuelle Kreditkarte mit Limit, hatte 3D Secure als Zwei-Faktor-Authentifizierung aktiviert und verwendete die gespeicherte Karte nur bei bekannten Händlern
Nachdem ein vor langer Zeit erstelltes Konto kompromittiert worden war, traf eine SMS über einen Kaufversuch auf einer Website mit gespeicherter Karte ein; das Opfer loggte sich sofort ein, änderte das Passwort, prüfte, ob ein Kauf erfolgt war, und senkte dann das Limit der virtuellen Karte stark ab
Die Karte wurde nicht vollständig deaktiviert, weil davon ausgegangen wurde, dass die vollständigen Kartendaten nicht kompromittiert worden waren
Etwa 6 Stunden nach der ersten Kompromittierung gab es bei mehreren ungenutzten Händlern 3 bis 4 3D Secure-SMS-Versuche; alle scheiterten, wurden aber später zu einem wichtigen Hinweis auf die Angriffsmethode
Einige Minuten später rief das Opfer bei der Bank an, um die Karte vollständig zu deaktivieren; in dieser Zeit nutzte der Angreifer andere Händler ohne 3D Secure, um das gesenkte Limit durch mehrere Zahlungen vollständig auszuschöpfen
Das Geld wurde in das E-Wallet eines Marktplatzes verschoben, von dem aus eine Barauszahlung möglich war; nach einem Chargeback erhielt das Opfer das Geld von der Bank zurück

Der Angreifer versuchte über das kompromittierte Konto eine Zahlung und sah anschließend die 3D Secure-Seite der Bank, brach dann die Bestellung ab und verließ die Seite
Dabei erhielt er die Information, dass die Karte noch nutzbar ist, den Namen der Bank, die maskierte Kartennummer und das vollständige Ablaufdatum
Üblicherweise sind für eine vollständige Kartenzahlung die 16 Stellen der PAN, das Ablaufdatum, die CVC2-Nummer und Informationen wie die für 3D Secure verwendete Mobiltelefonnummer erforderlich
Im realen Angriff reichten jedoch schon einige dieser Informationen aus, um bei anderen Händlern weitere Versuche zu unternehmen

Eine Payment card number (PAN) ist ein Kartenidentifikator für Kreditkarten, Debitkarten, Stored-Value-Karten und Geschenkkarten
Die PAN folgt nach ISO/IEC 7812 einem gemeinsamen Nummernschema und hat intern die folgende Struktur
- 6- oder 8-stellige Issuer Identification Number (IIN)
- ein individueller Konto-Identifikator mit bis zu 12 Stellen
- eine 1-stellige Prüfziffer, berechnet mit dem Luhn-Algorithmus
Die Bank des Opfers erlaubte keine Zahlung nur mit der Kartennummer, sondern verlangte PAN, Ablaufdatum und CVV gemeinsam
Einige Banken und Payment Gateways können Zahlungen bereits nur anhand der Kartennummer verarbeiten; genau das war für das Opfer besonders schwer zu glauben

Die Bank des Opfers lehnte Zahlungen mit fehlenden oder falschen Pflichtwerten ab, teilte aber per Response-Code mit, welcher Teil falsch war
Beispielhafte Antworten waren:
- „Keine gültige Kreditkarte“
- „Karte abgelaufen“
- „Alle anderen Angaben stimmen, aber der CVV ist falsch“
Solche Antworten können vom Angreifer genutzt werden, um zu unterscheiden, welche Werte bei Kartennummer, Ablaufdatum und CVV richtig oder falsch sind
Im realen Angriff testete der Angreifer mit 6 Versuchen pro Sekunde, etwa 2 pro Sekunde und API
Für Händler ist diese Geschwindigkeit schwer zu erkennen, weil sich die Ursprungs-IP durch Proxys ändert, die Kartennummern bei Brute Force nicht identisch sind und die Anfragerate insgesamt sehr niedrig bleibt

Die Bank führt eine Liste von Händlern mit 3D Secure-Ausnahme; diese gelten als vertrauenswürdig und können Zahlungen und Abonnements ohne 3D Secure entgegennehmen
Bei einem Chargeback tragen diese Händler die Haftung
Der Angreifer nutzte Händler ohne 3D Secure, um innerhalb des Kartenlimits Geld in ein E-Wallet zu verschieben

Das Geld wurde per Chargeback schnell zurückerstattet
Dem betreffenden Händler wurde mitgeteilt, dass ein System zur Umwandlung von Kartenzahlungen in Bargeld für unbefugte Abbuchungen missbraucht wurde, doch der Händler antwortete nur, man solle sich an die Bank wenden
Einer E-Commerce-Website wurde mitgeteilt, dass die Anzeige von 10 Stellen der Kartennummer zusammen mit dem Ablaufdatum den Angriff erleichtere, doch die Website erkannte dies nicht als Schwachstelle an und erklärte, das Verhalten sei absichtlich gemäß PCI DSS 3 und 4 umgesetzt worden
Menschen, die Payment APIs bauen oder in der Zahlungsbranche arbeiten, waren darüber nicht überrascht; einige Händler antworteten sogar, dass Transaktionen teils auch ohne Ablaufdatum möglich seien
Seit dem Vorfall verarbeitet der betreffende Dienstleister, der Kreditkartenzahlungen in Bargeld umwandelte, dies nicht mehr ohne 3D Secure
Die Bank des Opfers verwendet weiterhin vergleichsweise großzügige Rate-Limits gegen CVC2-Brute-Force; wenn das Limit greift, wird die betreffende Karte nur für einige Minuten vorübergehend gesperrt