Handheld Interagency Identity Detection Equipment

Verschiedene Quellen berichten, dass die Taliban Geräte zur biometrischen Datenerfassung und Identifikation des US-Militärs, sog. HIIDE (Handheld Interagency Identity Detection Equipment), erbeutet haben. Solche Geräte wurden zuvor genutzt, um potentiell gefährliche Personen und auch Verbündete oder Beschäftigte über einen Abgleich mit biometrischen Datenbanken identifizieren zu können. Dazu können die Geräte Iris, Fingerabdrücke und Gesichter erfassen. Der Vorfall zeigt, wie gefährlich biometrische Überwachung ist: Wenn gesammelte Daten in falsche Hände geraten, können die Betroffenen ihre biometrischen Daten kaum verändern. Ehemalige Angehörige der afghanischen Nationalarmee, die biometrisch registriert wurden, könnten nun Schwierigkeiten haben, ihre frühere Tätigkeit zu verbergen.

Die HIIDE wurden nicht nur in Afghanistan eingesetzt, sondern auch im Irak. Dort wurde schon früh wurde auf die Gefahren biometrischer Datenbanken hingewiesen. 2007 warnte ein Lieutenant Colonel des fingerprint and retina scanning center in Bagdad:

This database… essentially what it becomes is a hit list if it gets in the wrong hands.

Zu den Problemen und den möglichen Nachteilen für Leib und Leben äußerte sich damals auch die NGO Electronic Privacy Information Center in einem offenen Brief an das US-Verteidigungsministerium.

In den von Wikileaks veröffentlichten Afghanistan und Iraq War Logs finden sich verschiedene Hinweise auf Einsätze von HIIDE:

  • 26.04.2007: […] Before leaving we took photos of the 14 policemen present and documented them in the HIIDE system as well. […]
  • 07.01.2008: […] The team made several inputs of the present ANP soldiers into the HIIDE system. […]
  • 12.12.2008: […] HIIDE results came back negative and the trucks were allowed to proceed. […]
  • 13.12.2009: […] ABP RECEIVED CONTACT. ABP CAPTURED 2 SUSPECTS. SUSPECTS WILL BE ENROLLED INTO HIIDE SYSTEM. NO U.S. OR ABP INJURIES […]

Bilder vom Einsatz von HIIDE und anderer Geräte zur Erfassung biometrischer Merkmale hat die Biometrics Task Force in mehreren Jahren veröffentlicht. Auch ein Handbuch der HIIDE Series 4, verschiedene Fortbildungsmaterialien und ein Überblick über HIIDE und noch andere Geräte können im Internet gefunden werden.

Die HIIDE Series 4 hat 4 GB Speicher, verschiedene kabelgebundene Schnittstellen und erlaubt eine lokale Watch List von 22.000 Personen. Das Nachfolgemodell, die mehr als zehn Jahre alte HIIDE Series 5, hat internen und erweiterbaren Speicher von bspw. 80 GB + 120 GB, dazu WLAN sowie Schnittstellen für Mobil- und Satellitenfunk. Die Series 5 erlaubt eine lokale Watch List von 500.000 Personen und einen Abgleich mit entfernten Datenbanken. Die Architektur der biometrischen Datenbank(en) des US Militärs wird gerade verbessert.

Bei Matthias Monroy gibt es außerdem einen Artikel zu verschiedenen biometrischen Datenbanken und Watch Lists von NATO, US-Verteidigungsministerium und anderen.

Tor-Knoten an Universitäten

Während Universitäten mit ihrer Infrastruktur und Kompetenz ideale Bedingungen für den Betrieb von Tor-Knoten bieten, ist ihr Anteil am Tor-Netz erstaunlich gering. Wir berichten über unsere Erfahrungen beim Betrieb von zwei Exit-Knoten an der TU Berlin und an der Uni Hamburg. Dazu gibt es Empfehlungen zum Betrieb. Der Artikel ist auf Deutsch und auf Englisch verfügbar. Einen Vortrag dazu gibt es hier.

Hausdurchsuchung dank Tor?

Wer Tor-Exit-Knoten betreibt, wird unter Umständen von der Polizei besucht. Hier habe ich Links zu diversen Vorträgen, Medienberichten und weiterem Infomaterial gesammelt.

Vorträge
Presse
weiteres Infomaterial

Schutzranzen

Am 22.01.2018 hat Digitalcourage einen Artikel über das Tracking von Kindern und Schulranzen veröffentlicht. Dies haben wir zum Anlass genommen, die Schutzranzen-App der Coodriver GmbH einmal näher anzuschauen. Nach kurzer Suche sind wir auf eine API gestoßen, über die sie unter anderem IMEIs, Telefonnummern oder Zeitstempel der letzten bekannten Positionen abrufen konnten. Laut Coodriver GmbH war der ausgenutzte API-Endpunkt nur zu Testzwecken aktiv.

Details

Zuerst wurde mit Packet Capture der Datenverkehr der Schutzranzen-App mitgeschnitten. Dadurch konnten die URL einer API und dazugehörige HTTP Basic Auth Zugangsdaten in Erfahrung gebracht werden.

Anschließend wurde die apk mit apktool entpackt und nach Schlagwörtern wie http oder api gesucht. So wurden 14 verschiedene Funktionen identifiziert, die die API über HTTP GET oder PUT zur Verfügung stellte.

Eine dieser Funktionen lieferte eine Liste aller registrierten Tracker curl 'https://<http basic auth Zugangsdaten>@<URL der API>/.../trackers'. Die Liste enthielt für jeden Tracker die IMEI, die Telefonnummer, einen Namen (“… Test …”), den Zeitstempel des letzten Positionsupdates und den Zeitstempel der letzten Aktivität, den Batteriestatus (niedrig oder nicht), sowie eine Flag, ob der Tracker Eltern akzeptiert.

Für Regionen sectors?latitude=%.6f&longitude=%.6f&radius=%d konnte abgefragt werden, welche Tracker sich in diesem Sektor befinden. Durch einen sehr großen Radius, etwa radius=900000000, konnten Daten zu fast 100 Trackern abgerufen werden.

      {
         "id":"<IMEI>",
         "phone":"<TELEFONNR>",
         "name":"Test Internal 7",
         "lastSeen":1515187629000,
         "lastPositionUpdate":1515187634000,
         "visible":false,
         "acceptingParents":true,
         "batteryLow":false
      },

Mit den IMEIs der Tracker und über eine andere Funktion der API konnten die Eltern, die einem Tracker zugeordnet waren, abgerufen werden. Die Antwort der API enthielt mehrere IDs und einen Namen.

  {
      "tracking":true,
      "name":"Papa",
      "server":"<API>",
      "slot":"UNKNOWN",
      "primaryId":5,
      "appId":"12345-1234-1234-1234-12345678"
   },

Hier gibt es eine Stellungnahme von Coodriver zur gefundenen Lücke. heise online berichtete über die Einstellung des Projekts.

Disclosure Timeline

  • 22.01.2018
    • Telefonat mit Coodriver
    • Technische Details der Lücke per E-Mail an Coodriver gesendet
    • Nachfrage per E-Mail von Coodriver zu weiteren Details
    • Telefonat mit Coodriver zu weiteren Details
  • 23.01.2018
  • 06.02.2018
    • Nachfrage, ob Lücke geschlossen wurde, da für Ende Januar eine neue Version angekündigt worden war
    • Coodriver teilt mit, dass die neue Version voraussichtlich Ende Februar erscheinen wird
  • 22.02.2018
    • Nachfrage, ob die Lücke geschlossen wurde, da die API-Zugangsdaten nicht mehr funktionieren
    • Coodriver teilt mit, dass die Lücke noch nicht dauerhaft geschlossen wurde
  • 05.03.2018
  • 06.03.2018
    • Coodriver teilt mit, dass die Lücke geschlossen wurde und die Ortungsfunktion entfernt wurde

Kreditech

Das Fintech-Startup Kreditech vergibt Kredite und bewertet die Kreditwürdigkeit der Kreditnehmerinnen durch Analyse von Nutzerinnendaten in sozialen Netzwerken. Die Firma hat ein Nexus Repository offen zugänglich am Internet betrieben. Diese Software erlaubte den Zugang zu Quelltext und Konfigurationsdaten, einschließlich Zugangsdaten und API-Keys.

Die Schwachstelle

Nexus Repositories werden oft unter einer „nexus.“-Subdomain bereitgestellt. Dies macht es Angreiferinnen leicht, potentielle Ziele zu identifizieren. Hinzu kommt, dass die Software standardmäßig einen anonymen Zugang gestattet.

By default, the user interface as well as the repositories and the contained components are available to unauthenticated users for read access

sonatype documentation

Bei einem Blick auf die Kreditech-Subdomains ist eine solche Subdomain aufgefallen:

 - www.mail.kreditech.com
 - vpn.kreditech.com
 - kreditech.com
 - nexus.kreditech.com
 - cloud.kreditech.com
 - ...

Dort befand sich also das Nexus Repository mit diversen Verzeichnissen. In einem dieser Verzeichnisse befand sich ein Archiv kredito-core-XX.jar mit Quelltext und den Dateien staging.properties und production.properties. Diese enthielten u.a. Zugangsdaten für externe Validierungs-, SMS-, Geolokalisierungs- und Postdienste sowie weitere Details der Konfiguration des Systems zur Zahlungsabwicklung. Ich habe die Schwachstelle am 31. Januar 2018 gemeldet und noch am gleichen Tag wurde die Schwachstelle geschlossen.

Update 1: Sonatype Update

Da neben Kreditech auch viele andere Unternehmen übersehen, dass Nexus Repository OSS und Nexus Repository Pro mit einem standardmäßig aktivierten Gast-Account daherkommen und solche Systeme leicht über Certificate Transparency Logs oder Google Dorks gefunden werden können, habe ich im Juli 2019 den Hersteller Sonatype kontaktiert. Dieser bestätigte das grundsätzliche Problem und erklärte, dass sie das Problem bereits angehen würden. Mit Version 3.17 werden (neue) Nutzerinnen explizit gefragt, ob sie den anonymen Zugang aktivieren möchten. Aus Legacy-Gründen wurden bestehende Installationen nicht angefasst. D.h., ältere Systeme können weiterhin gefunden werden.

Update 2: Insolvenz

Im März 2020 wurde Kreditech in Monedo umbenannt. Im September 2020 ging Monedo insolvent. Die Firma wurde zum Ende des Jahres liquidiert.

Telekom Austria

Die Telekom Austria schrieb auf Twitter, dass sie Kundenpasswörter im Klartext speichern würden. Das haben manche als Einladung verstanden, sich die Dienste der Telekom einmal näher anzuschauen.

What if this doesn’t happen because our security is amazingly good? ^Käthe

Unter blog.t-mobile.at, kids.t-mobile.at und newsroom.t-mobile.at lagen .git-Verzeichnisse mit MySQL-Zugangsdaten. Ein öffentlich zugängliches phpMyAdmin gab es auch. Hanno Böck ist ebenfalls darüber gestolpert und fand via Twitter schneller als ich den richtigen Ansprechpartner bei der Telekom 🙂 Bei golem gibt es einen ausführlichen Artikel.