Ihr seid toll. Das erleben wir Tag für Tag, seid inzwischen fast zehn Jahren. Ob ihr euch mit einer Frage an uns wendet oder mit einem Tipp, wie wir mite verbessern könnten: Wir erleben viel Köpfchen und Erfahrung, viel Freundlichkeit und Verständnis. Und vor allem Hilfsbereitschaft. Dafür möchten wir uns heute einmal ganz grundsätzlich bedanken.

Ganz besonders geht unser Dank heute allerdings an Marcel Eichner. Er hat uns vergangenen Donnerstag auf eine Sicherheitslücke aufmerksam gemacht. Dank seiner exakten Beschreibung konnten wir diese sofort nachvollziehen und drei Stunden später schließen. Merci für deine Unterstützung, Marcel!

Erstens haben wir keine Indizien, dass die Lücke ausgenutzt wurde. Zweitens hätten keine personenbezogenen Daten ausgelesen oder gar modifiziert werden können. Trotzdem möchten wir euch natürlich detailliert informieren.

Der Fehler hatte sich in unsere offene Datenschnittstelle, die mite.api, eingeschlichen. Jedes Projekt in mite hat eine eindeutige Identifikationsnummer (ID) und ist optional einem Kunden zugeordnet. Über unsere API kann man Zeiteinträge für ein Projekt erstellen. Das Projekt wählt man über dessen ID aus. mite überprüft dann, ob ein Projekt mit dieser ID existiert und ob es zum eigenen Account gehört. Schlägt diese Prüfung fehl, wird die Projekt-ID in der Serverantwort auf „null“ zurückgesetzt.

Aus Performance-Gründen gibt mite bei Erstellung eines Zeiteintrags nicht nur die Projekt-ID zurück, sondern, falls vorhanden, auch die ID, den Namen sowie ggf. den Stundensatz des dem Projekt zugehörigen Kunden. Hier versteckte sich der Fehler, und zwar in der Reihenfolge der Prüfung. Gehörte die ID zu dem Projekt eines fremden Accounts, wurde die Projekt-ID zwar wie beschrieben zuerst zurückgesetzt, jedoch wurden dennoch die genannten Daten des zugehörigen Kunden soweit vorhanden zurückgegeben.

Die Serverantwort enthielt jedoch nicht die Information, zu welchem Account dieser Kunde gehört. Man hätte ergo aufgrund dieser Lücke zwar erfahren können, dass irgendein Unternehmen, das mite einsetzt, für einen Kunden XYZ arbeitet, nicht jedoch, welches Unternehmen. Und dass irgendein nicht definiertes Team auf der Welt für einen Kunden XYZ arbeitet, ist glücklicherweise keine hochsensible Information.

Die Lücke war also keine superkritische, und nun ist sie dicht. Doch sie hatte sich eingeschlichen, so ernst wir das Thema nehmen. Daher sind wir Marcel auch so dankbar für seinen Hinweis. Und möchten das zum Anlass nehmen, euch alle darum zu bitten, euch sofort direkt bei uns zu melden, falls ihr in Zukunft auf eine Schwachstelle aufmerksam werden solltet.

E-Mail ist der geschickteste Kanal in solch Fällen. Alle Kommunikationskanäle sowie unseren PGP-Key zur verschlüsselten Kommunikation findet ihr hier. Bitte beschreibt uns möglichst genau, wie ihr vorgeht, wie mite sich verhält und wie mite sich eurer Meinung nach verhalten sollte. Schickt gerne Code-Beispiele mit, Screenshots, Infos zur von euch eingesetzten Technik – alles, was wichtig sein könnte, um das Problem nachzuvollziehen und möglichst rasch zu beheben. Bitte unterstützt uns dabei, mite fehlerfrei zu halten. Für euch alle.

Julia in Maschinenraum