Am Freitag wurde ich über einen Tweet auf eine Lücke im Trackingsystem von DHL aufmerksam. Wenn man die Website für den “Sendungsstatus” aufrief, so bekam man zwei Eingabefelder angezeigt (Sendungsnummer und Referenznummer). Fügte man eine Postleitzahl in das Feld für die Referenznummer ein und klickte auf “Suchen”, so kam man zu einer zweiten Seite, auf der der Hinweis “Es liegen nicht eindeutig nationale und internationale Sendungen vor” angezeigt wurde. Wenn man auf der zweiten Seite in das PLZ-Feld die gleiche PLZ noch einmal einfügte und wieder auf “Suchen” klickte, so wurden meist mehrere Vorgänge angezeigt, inkl. Name des Empfänger und evtl. auch der Name der Person die die Sendung angenommen hatte.

In verschiedenen Blogs wurde über dieses Datenleck berichtet:
“Datenpanne bei der DHL? Sendungsverfolgung für fremde Pakete” (netzrecht.org)
“DHL gibt Auskunft über fremde Pakete” (lawblog.de)
“Datenschutz: Paketverfolgung bei der DHL für jeden möglich” (nachgeblogt.com)

Gestern wurde dann der Praktikant der DHL-EiTea-Abteilung aus seinem wohlverdienten Wochenende gerissen. Erst schaltete er den Wartungsmodus ein, damit niemand mehr auf den Sendungsstatus zugreifen konnte. Irgendwann war er dann mit seinem Gefrickel fertig und aktivierte das System wieder für die Öffentlichkeit.

Nun kann man nur noch die Sendungsnummer eingeben, es gibt kein Feld mehr für die Referenznummer. Da man ja genau in dem jetzt fehlenden Feld die PLZ eingeben mußte… könnte man… aber nein, es war doch nur der Praktikant. :O)

Die Lücke besteht nach wie vor, man kann noch immer die Daten auslesen.

Nur ein Hinweis von mir: Lieber DHL-EiTea-Praktikant, es reicht nicht aus, nur ein Formularfeld aus einem Template zu entfernen, um die Lücke zu schließen.

Update: 13.07.2009 – 11:50 Uhr
Liebe DHL-EiTealer, ihr braucht nicht meinen ganzen Blog durchkämmen – wie ihr die Lücke schließen könnt habe ich nirgends geschrieben, fragt mich einfach, geht schneller. :O)

Update: 14.07.2009 – 17:04 Uhr
DHL hat nun die Lücke endlich geschlossen. Ob meine beiden Hinweisen (per E-Mail und per Kontaktformular) mit Beispiellinks dazu geführt haben weiß ich nicht, da sie mir natürlich nicht geantwortet haben.


Was bei DHL noch fehlt, die vollständige Adresse des Empfängers, da kann ein anderer Paketdienst aushelfen. Auch bei DPD waren EiTea-Frickler am Werk, denn anders ist es nicht zu erklären, dass man nur mit der Paketscheinnummer bewaffnet, jeden Zustellbeleg, inkl. Postanschrift des Empfängers und Name und Unterschrift des Menschen der die Sendung angenommen hat, runterladen kann:

DPD nutzt fortlaufende Paketscheinnummern, was das Abgreifen der Daten per Script sehr vereinfacht:

Im Moment fällt mir noch kein sinnvoller Betrugsversuch ein, bei dem ein Angreifer die gewonnenen Daten nutzen könnte, aber: DPD, muß das so sein? Oder verstehe ich nur mal wieder dieses Feature nicht?

(Ich habe ganz bewusst nur mit alten Paketscheinnummern die Screenshots erstellt. Die verfügbaren Zustellbelege sind tagesaktuell abrufbar.)

“E-Gesundheitskarte: Datenverlust mit Folgen” (heise.de)

Nach dem Ausfall eines Hardware Sicherheitsmoduls (HSM), auf dem das private Schlüsselmaterial der Root Certificate Authority (Root-CA) für Karten der Generation 1 gespeichert war, stellte sich heraus, dass es kein Backup dieser Daten gab.

Die Projektgesellschaft Gematik wusste was fehlende Backups bedeuten:

PKI für CV-Zertifikate Grobkonzept

Version: 1.5.0
Stand: 16.06.2008

Seite 26

4.4.1 Sicherheitsanforderungen und Schutzbedarf
(…)
Tabelle 3 – Schutzbedarf
(…)
Sicherheitsziel
Verfügbarkeit der privaten Root-Schlüssel

Schutzbedarf
hoch [gemSiKo#C2.87] (siehe Anmerkung nach der Tabelle)

Erläuterung
Es könnten sonst keine weiteren CVZertifikate für CAs der zweiten Ebene ausgestellt werden.

Aufwand
mittel: Backup HSM für die Root-CA oder zweites HSM mit eigenem Schlüsselpaar mit Cross CV-Zertifikaten.
(…)
Anmerkung: (…) Der private Schlüssel der Root-CA MUSS mit hoher Zuverlässigkeit wiederhergestellt werden können. Ansonsten könnte bei einem Verlust des Root-Schlüssels die Situation eintreten, dass aktuell im Feld befindliche Chipkarten mit zukünftig neu produzierten Chipkarten keine C2CAuthentisierung mehr durchführen können.

Quelle: http://www.gematik.de/ upload/ gematik_PKI_CV-Zertifikate_Grobkonzept_V1.5.0_3822.pdf

Und weiter im Heise-Artikel:

“Die Gematik hat entschieden, ‘Wir verzichten auf das Backup’. Das haben wir als Dienstleister zu akzeptieren,” erklärte Merx, (D-Trust Geschäftsführer)
(…)
Die Erklärung, dass man beim Dienstleister auf einen Test ohne Backup der privaten Schlüssel der Root-CA bestanden habe, verweist Gematik-Sprecher Daniel Poeschkens gegenüber heise online in das Reich der Legende: “Wir haben uns nicht gegen einen Backup-Dienst entschieden. …”

In den Richtlinien von Gematik kann man nachlesen das zwingend Backups vorgeschrieben sind:

- Certificate Policy -
Gemeinsame Zertifizierungs- Richtlinie für Teilnehmer der gematik-TSL zur Herausgabe von X.509-ENC/AUT/OSIG-Zertifikaten

Version: 1.3.0
Stand: 16.06.2008

Seite 41/42

Es MUSS ein Backup-HSM existieren. HSM und Backup-HSM MÜSSEN die gleichen Sicherheitsanforderungen erfüllen. Zwischen HSM und Backup-HSM MUSS ein kryptographisch gesicherter Transportkanal hergestellt werden können, um den privaten Schlüssel des Root-TSP aus dem HSM gesichert zu exportieren und in das Backup-HSM zu importieren. Alternativ KANN in dem Backup-HSM auch ein eigenes Schlüsselpaar generiert werden. In diesem Fall MUSS ein entsprechendes Paar an Cross-Zertifikaten erstellt werden.

Quelle: http://www.gematik.de/ upload/ gematik_PKI_X_509-Certificate_Policy_ENC+AUT+OSIG_V1.3.0_3851.pdf

D-Trust wird sich den Verzicht auf Backups, in der Testphase, doch sicher schriftlich von Gematik bestätigen lassen haben?


Mich würde jetzt mal interessieren wo der (Kosten)Vorteil ist, einen Test durchzuführen, der kein wirklicher Test ist. Warum verzichtet man in einer Testphase auf Backups?


Lustig finde ich auch dies aus dem Heise-Artikel:

In deren Trustcenter passierte offenbar nach einem Spannungsabfall das, was D-Trust Geschäftsführer Matthias Merx gegenüber heise online als etwas beschrieb, was schonmal vorkommt: “Das HSM hat eigenständig die Daten gelöscht, weil es einen Angriff vermutete.”

Wie war das noch bei Terminator 3? “Können wir nicht den Strom abschalten? Nein, dies würde Skynet als Angriff interpretieren und selbständig alle Raketen abfeuern.” So oder so ähnlich war es doch?! :O)