Strategien für die Praxis
Sind trivialen Fälle wie beim Miniatur Wunderland abgehakt, wird klar: Das Hauptproblem fast aller digitaler Zufallszahlengeneratoren ist ihre Pseudozufälligkeit. Die Berechnung von Pseudozufallszahlen zu verstehen setzt eine Portion Neugier und mathematisches Interesse voraus. Man muss aber nicht Träger der Fields-Medaille sein, um zu kapieren, dass eine 148-Bit-Zufallszahl für eine Session-ID besser sein muss, als eine mit 64 Bit, die aus vorhersagbaren Werten kombiniert ist.
Beim verwendeten Seed lohnt es sich zu überlegen, woher die Zufallsdaten stammen. Folgt der Zufall einem Muster, dann wiegt der Generator seine Anwender in falscher Sicherheit. (Ein Beispiel aus einem Gebiet beleuchtet der Kasten "Kreditkartennummer erraten".) Viele Kryptoalgorithmen erzeugen aber ihre Schlüssel mit Zufallszahlen. Sind die (in Teilen) vorhersagbar, lässt sich die Verschlüsselung leicht(er) knacken.
Für die Praxis heißt das: Wer seinen Zufallszahlengenerator sicher seeden will, der sollte auch echt zufällige Daten verwenden. Bevor man jedoch selbst versucht das Rad neu zu erfinden, lohnt sich das Beschäftigen mit »/dev/random«
. Der erzeugt seine Zufallszahlen aus dem "Rauschen" des Systems und ist so nicht vorhersagbar. Außerdem gibt es nur so lange Daten, wie auch ausreichend Umgebungsrauschen vorhanden ist. Initialisiert man mit einem solchen Zufallswert einen kryptographisch sicheren Zufallszahlengenerator, ist es mit der Vorhersagbarkeit vorbei.
Außerdem lohnt es sich, auf bessere Zufallszahlenalgorithmen als LCG zurückzugreifen. Neben »lcg_rand()«
bietet PHP die Funktionen »mt_rand()«
, im Wesentlichen eine schnellere LCG-Implementation, und »rand()«
, die sich auf den Zufallszahlengenerator des verwendeten C-Compilers stützt. (jk)
Kreditkartennummer erraten
Laut einer Google-Suche, also der landläufigen Meinung, lassen sich Kreditkartennummern nicht erraten. Diner's Club vergibt 14-stellige Kartennummern, American Express 15-stellige und Visa und Mastercard nur noch 16-stellige. Damit ergeben sich 1014 bis 1016 Möglichkeiten für Kartennummern – theoretisch.
In der Praxis schränkt die Anatomie der Nummernvergabe den Wertebereich ein: Die erste Ziffer gibt den Schwerpunkt der Industriebranche an, der die Karte angehört. So sind Visa und Mastercard echte Banken und starten mit den Ziffern 4 und 5, während American Express aus der Reisebranche stammt und die 3 trägt.
Die ersten sechs Stellen einer Kreditkartennummer geben an, welche Bank die Karte ausgegeben hat. Zudem enthalten sie oft einen Hinweis auf die Kartenart. So lässt sich bei American Express an den ersten Ziffern ablesen, aus welcher Region die Karte stammt und welcher Kartenlevel assoziiert ist. Eine deutsche American Express beginnt mit 3750 [10], eine Platinum mit 37508. Bei Lufthansa sind in der Banknummer meinen Informationen zufolge der Status des Kunden und die Art der Karte (mit/ohne Businesspaket) kodiert.
Die darauf folgenden Positionen, mit Ausnahme der letzten, geben die bankinterne Kundennummer wieder. Eine Besonderheit konnte ich bei American Express beobachten: Dort markieren die Stellen 12 bis 14, ob es sich um die Partner- oder Hauptkarte handelt. Hauptkarten scheinen, sofern es Partnerkarten gibt, stets 300 als Wert zu haben. Partnerkarten tragen den Wert »10Fortlaufende_Nummer_der_Partnerkarte«
. Andere Banken vergeben die interne Kundennummer offenbar auch nach einem Schema, das einfachste dürften aufsteigende Nummern sein.
Die Prüfsumme
Die letzte Zahl der Kreditkartennummer ist eine Prüfziffer, um Übertragungsfehler zu entdecken. Sie errechnet sich nach dem sehr einfachen Luhn-Algorithmus, der von rechts kommend jede zweite Stelle mit 2 multipliziert. Sollte das Ergebnis größer 9 sein, wird 9 subtrahiert. Aus diesen Ziffern und den verbleibenden Stellen entsteht die Summe. Ist sie durch 10 restlos teilbar, ist die Kartennummer gültig.
Durch die Gewichtung der benachbarten Stellen sind Zahlendreher sofort offensichtlich, die Sicherheit einer kryptographischen Prüfsumme ist jedoch nicht zu erreichen. Die Prüfsumme eignet sich für einen Schnellcheck, ob eine Kreditkartennummer gültig ist. Darum überrascht es nicht, dass es im Netz eine Vielzahl von Kreditkartengeneratoren gibt, die für diesen ersten Test plausible Nummern erzeugen.
Sternchen an verschiedenen Stellen
Onlineshops verkürzen eine Kreditkartennummer bei der Ausgabe, um den Klau der Kartendaten zu erschweren. Amazon gibt nur die letzten vier Stellen und den Typ der Karte aus, American Express nennt in Kunden-E-Mails und beim Onlinebanking die letzten fünf. Samsonite schreibt in die Bestellbestätigung die ersten vier und letzten beiden Ziffern. Bei Sixt finden sich die ersten vier und die letzten vier Stellen. Auf Tankbelegen sehe ich eigentlich alle weiteren Varianten. Einen Hochgenuss bereitete mir neulich ein Onlineshop, der alle – bis auf die letzte Stelle der Kartennummer – offen listet.
Aller Anfang ist leicht
In Kenntnis dieser Umstände kommen Angreifer wieder ein Stück weiter: Ist die letzte Ziffer bekannt, begrenzt sie den Wertevorrat aller anderen Stellen. Wäre nur eine Stelle unkenntlich, so lässt sich die sofort herleiten. Bei zwei versternten Stellen erwartet man 100 Ratemöglichkeiten, tatsächlich sind es nur neun. Beispiel American Express: Die Kartennummer hat 15 Stellen, die letzten fünf Stellen, verrät American Express freiwillig, lauten 71047. Die ersten vier sind auch bekannt: 3750. Damit bleiben noch sechs zu ratende Stellen.
Wer den Kartennutzer mal beobachtet hat, kennt die Farbe der Karte und damit deren Level. Alternativ lässt sich an der 104 erkennen, dass es sich um eine Partnerkarte handeln könnte – und es gibt nur wenige Kartenlevel, die vier Partnerkarten erlauben. Damit bleiben fünf offene Stellen. Statt der spontan zu erwartenden 100 000 Möglichkeiten gibt es hier nur 5904 gültige Kartennummern. Das lässt sich logisch herleiten oder auch empirisch bestimmen.
In einem Restaurant neulich tarnte der Beleg des Bezahlterminals gerade mal die letzten drei Stellen von American Express. Die viertletzte macht klar, dass es sich um eine Partnerkarte handelt. Damit sind die Werte der beiden vorletzten Stellen begrenzt. Die letzte Stelle errechnet sich nach Luhn. Damit sinken die Variationsmöglichkeiten von den sowieso schon mageren 103 auf eine (Partnerkarten sind durchnummeriert). Hier wird jeder Schuss ein Treffer.
Wer es selbst probieren möchte, findet in Listing 3 ein kleines Programm, das abhängig von den bekannten, also fixierten Stellen (»1«
im Array »fixed«
) einer beliebigen Kartennummer alle möglichen gültigen Kartennummern mit der gleichen Prüfsumme ermittelt. Der Algorithmus ist bewusst simpel gestaltet und iteriert rekursiv durch alle Kombinationen.
Etwas Mathematik
Mit mehr Energie lässt sich erkennen, dass aufgrund der Struktur der Prüfsumme bestimmte Permutationen über einen Treffer auch Treffer sein müssen. Die Nummern darf ein weiterer Durchlauf ausblenden. Außerdem lassen sich zwei benachbarte Ziffern tauschen, wenn man sie geeignet verdoppelt oder halbiert. Mathematisch handelt es sich eigentlich um ein (stark) unterbestimmtes, nicht homogenes lineares Gleichungssystem. Darum lassen sich aus einer Lösung weitere direkt herleiten.
Die Konsequenz
Gelingt es einem Angreifer, über mehrere Shops, Belege oder E-Mails verschiedene Teile einer Kreditkartennummer zu ermitteln, reduziert er so die Anzahl der möglichen Varianten. Kennt er zudem den Kartentyp (siehe oben), schränkt das den Wertevorrat weiter ein. Besonders effektiv sind die Akzeptanzstellen, die die letzte Ziffer, die Prüfziffer, nicht ausblenden, was für fast alle Onlineshops gilt.
Die beste Lösung wäre, wenn alle Shops die Prüfziffern "versternen" würden. Angreifern macht es zudem das Leben schwer, wenn Zahlen aus dem mittleren Bereich, also nach der sechsten Ziffer, getarnt bleiben. Für weiter vorne stehende Ziffern lohnt der Aufwand nicht, die sind sowieso leicht ermittelbar.
Für einige Karten konnte ich schon Informationen zum Aufbau ermitteln, doch ist das nur ein überschaubarer Vorrat. Um weiter zu recherchieren, würde ich mich freuen, wenn an dem Thema Interessierte mir von eigenen Erkenntnissen berichten. Insbesondere interessieren mich bankinterne BIN-Konstruktionen analog zu den Beispielen Lufthansa und American Express sowie Besonderheiten innerhalb der Kundennummer, wie bei Amex-Partnerkarten.
Listing 3
Kartennummer raten
01 #!/bin/perl
02 @cc = (3,7,5,0,8,1,2,3,4,5,7,1,0,0,7);
03 @fixed = (1,1,1,1,1,1,0,0,0,0,1,1,1,1,1);
04
05 sub test_rekursiv
06 { my ($stelle, @ccnum) = @_;
07 my ($val, $pos, $summe);
08 if ($stelle < $#ccnum)
09 { if ($fixed[$stelle] == 1)
10 { test_rekursiv($stelle + 1, @ccnum);
11 }
12 else
13 { for ($val = 0; $val < 9; $val++)
14 { $ccnum[$stelle]=$val;
15 test_rekursiv($stelle +1, @ccnum);
16 }
17 }
18 }
19 else
20 { for ($summe=0, $pos=0; $pos <= $#ccnum; $pos++)
21 { $summe+= (($pos % 2) == 0) ? $ccnum[$pos] : (($ccnum[$pos]*2>9) ? $ccnum[$pos]*2-9 : $ccnum[$pos]*2);
22 }
23 if (($summe % 10) == 0 )
24 { print "Gueltige Nr: @ccnum\n";
25 }
26 }
27 }
28
29 test_rekursiv(0, @cc);
Infos
- Miniatur Wunderland: http://www.miniatur-wunderland.de
- Seite von Samy Kamkar: http://www.samy.pl
- Samy Kamkar, "Phpwn: Attacking sessions and pseudo-random numbers in PHP": Blackhat US 2010
- Firebug: http://www.getfirebug.com
- Phpwn, "Attack on PHP sessions and random numbers": Http://samy.pl/phpwn/
- GCC-Patch "Use urandom to get random seed": http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01769.html
- Amit Klein, Open BSD DNS Cache Poisoning: http://www.trusteer.com/sites/default/files/OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP_ID_Vulnerability.pdf
- Debian-Sicherheitsankündigung für Open SSL: http://www.debian.org/security/2008/dsa-1571
- Debian-Open-SSL-Lücke: http://digitaloffense.net/tools/debian-openssl/
- Bank-Identifikationsnummern: http://en.wikipedia.org/wiki/List_of_Bank_Identification_Numbers
Diesen Artikel als PDF kaufen
Express-Kauf als PDF
Umfang: 6 Heftseiten
Preis € 0,99
(inkl. 19% MwSt.)
Als digitales Abo
Weitere Produkte im Medialinx Shop »
Versandartikel
Onlineartikel
Alle Rezensionen aus dem Linux-Magazin
- Buecher/07 Bücher über 3-D-Programmierung sowie die Sprache Dart
- Buecher/06 Bücher über Map-Reduce und über die Sprache Erlang
- Buecher/05 Bücher über Scala und über Suchmaschinen-Optimierung
- Buecher/04 Bücher über Metasploit sowie über Erlang/OTP
- Buecher/03 Bücher über die LPI-Level-2-Zertifizierung
- Buecher/02 Bücher über Node.js und über nebenläufige Programmierung
- Buecher/01 Bücher über Linux-HA sowie über PHP-Webprogrammierung
- Buecher/12 Bücher über HTML-5-Apps sowie Computer Vision mit Python
- Buecher/11 Bücher über Statistik sowie über C++-Metaprogrammierung
- Buecher/10 Bücher zu PHP-Webbots sowie zur Emacs-Programmierung
Insecurity Bulletin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...





