Aus beruflichen Gründen hatte ich heute Kontakt zu einem Hersteller von Photovoltaik Software in der Schweiz. Eigentlich™ ging es dabei nur mal eben™ darum, die Beschaffung eines Updates mit einer unklaren Vorlizenz und alten Kundennummer zu klären.
Ich registrierte also auf der Unternehmenswebsite einen neuen Account per Emailadresse. Im Eingabeformular fand ich ein Feld zur Vorgabe einer bereits vorhandenen „CustomerID”.
So eine ID hatten wir, jedoch lag da unser Problem – wir wollten klären wer da wann wie welche Registrierung vorgenommen hatte. Die Eingabe der Nummer wurde live nach jeder Ziffer geprüft (Javascript), und unsere ID hatte offenbar Gültigkeit – denn ein grüner Haken erschien. Aha. Und die Nummer wurde bei der Registrierung einfach „geschluckt”.
Nach dem ersten Login wurden die Augen groß. Die ID gehörte zu einer komplett anderen Firma, und sämtliche Adressdaten und Lizenzen dieser Firma wurden mir neben unseren Daten angezeigt.
(Die Registrierung funktioniert ganz nebenbei bemerkt sauber anonym, ohne Bestätigungslink und Adressprüfung. Auch sehr sicher. Nicht.)
Was war denn da los? Das weckt ja dann doch Sorge und Neugier.
Die Registrierung und der spätere Login zum Kauf sind Teil eines Shopsystems, und dieses wird auf der Website des Anbieters per iframe eingebettet.
Nach Analyse der „echten” URL aus dem iframe via Firebug (mehr braucht es nicht) wurde relativ schnell klar, dass die „Prüfung” der Kundennummer tatsächlich echt und live ist, und auch ohne das Form bei der Registrierung nutzbar ist.
Ironischerweise läuft die URL des iframes mit https://. Der gesamte Link enthält ein Verzeichnis namens „/secure/”.
Die Funktion zur Prüfung einer gültigen Kundennummer lässt sich einfach der index.php mitgeben, auch OHNE saubere Session:
https://[...]secure/[...]index.php?page=check_customer_id&cid=XXXXXXXX
XXXXXXXX steht dabei für die achtstellige Kundennummer zur Prüfung. Ein Test mit unserer ID ergab einen Treffer. Hinten eins hochgezählt, Treffer. Nochmal plus eins, wieder Treffer.
Die manuellen Aufrufe geben einen JSON String im Browser aus, welcher bis auf das Passwort oder Zahlungsdaten alle relevanten Infos des Kunden enthält. Namen, Ansprechpartner, Adressen, Mail Adressen, Anzahl der Lizenzen, Aktivierungscodes, interne Notizen, etc.
Ein einfach Hochzählen funktionierte nur bedingt, allerdings wurde nach kurzer Ansicht einer Ausgabe klar, wie die CustomerID „verschlüsselt” wurde.
Es gibt ein Feld „Datum der Registrierung”. Beispiel: „2005-08-14”. Die Kundennummer dazu lautet 25140800. Merkt Ihr was? Erneute Tests mit diesen Kombinationen führten wie erwartet zu Treffern. Die Kundennummer ist also das Datum der Registrierung gefolgt von 2 Stellen, die für diesen Tag bei mehrfachen Anmeldungen einfach hochgezählt werden.
Damit endet mein Versuch einer Klärung bzw. Registrierung zunächst mal mit einem mühelosen und offenen Zugriff auf den gesamten Kundenstamm des Herstellers per Browser. Ohne Hürden oder echten Aufwand.
Hätte ich hier weiter gemacht, hätten 3-4 verschachtelte FOR Schleifen mit cURL ausgereicht um gemütlich an die gesamte Kundendatenbank zu kommen. Und das bash script dient dabei nur der Faulheit, so viele URLS tippt man ja nicht mit der Hand.
Ein Blick auf die Serverumgebung des Anbieters zeigt jedoch noch ganz andere „Lücken”. Ein völlig veralteter Apache 2.2.x Webserver mit ebenso bärtigem PHP 5.3.10-1. Die Buglists dieser Versionen lesen sich so in etwa wie „Komm rein, bist herzlich eingeladen, lass die Schuhe ruhig an”.
Auch der Rest des index.php und der gesamten „Shopsoftware” scheint zum weiter probieren einzuladen. Es gibt nirgendwo Absicherungen, alle Prüfungen erfolgen sofort auf Echtdaten. Das Passwort Zurücksetzen Formular sagt einem z.B. brav ob eine Adresse in der Datenbank vorhanden ist, oder eben nicht.
Da man das natürlich alles nicht macht, nicht darf, und vor allem das Ganze technisch und zum Schutze der Kunden gar nicht möglich sein sollte, informierte ich den Hersteller per Telefon.
Da erlebte ich eine Überraschung. Die Antwort vom anderen Ende lautete frei zitiert in Etwa:
„Nobody else is playing around with that […] it is safe enough because you can’t change anything there […]“
Mein Hinweis auf die Direktabfrage und die Möglichkeiten per cURL wurden nicht verstanden und direkt am Telefon quasi negiert.
Wir haben erst Januar, aber für mich ist dieser Anbieter schon jetzt ein heißer Anwärter für den „Balls Of Steel Award 2016”. Der ebenfalls passende „Customer-Care-Privacy Award” müsste wohl noch erfunden werden.