Tl;dr: Im Rahmen des DiVOC-Events hatten wir einen unberechtigten Login auf einer unserer virtueller Maschinen. Wir gehen davon aus, dass es ein Bot war und keine Nutzerdaten in fremde Hände gelangt sind. Wir haben so gehandelt, wie wir es uns von anderen in so einer Situation wünschen würden. Wir haben den Vorfall sehr genau analysiert und alle per E‑Mail informiert, für die es ein Risiko gegeben haben könnte. Wir sind zu dem Schluss gekommen, dass nur SIP-Userdaten des DiVOC-Events betroffen sein können. Wir haben entsprechende Maßnahmen ergriffen und ein neues Feature im GURU3 implementiert, mit dem ein neues randomisiertes SIP-Passwort generiert werden kann. (Extensions -> Schlüssel -> Regenerate Password)
Aus Transparenzgründen veröffentlichen wir hier den Vorfall komplett und hoffen, wir und ihr können daraus lernen. Wir entschuldigen uns bei allen Usern weil wir wissen, dass wir großes Vertrauen bei euch genießen. Mit dieser Aktion haben wir wirklich einen Bock geschossen und es ist uns sehr peinlich. Es war unser erster Versuch, das PoC komplett in der Cloud zu virtualisieren, und wir hatten beim Spielen die Technologie, ganz offensichtlich, nicht zu 100 Prozent unter Kontrolle. Es tut uns leid.
Es gab einen unberechtigten Login am 14.04.2020 gegen 4:30 Uhr auf unserem SIP Yate Server im Rahmen des DiVOC Events. Dies war möglich, weil:
- Das nano PoC Setup, welches wir für das DiVOC nutzen, mit Vagrant automatisch installiert wurde und
- die Konfiguration auf der Vagrant default Konfiguration basierte (in der Dokumentation steht: it is a general convention to set the password for the “vagrant” user to “vagrant”.) und
- die Maschine via SSH im Internet verfügbar war.
Wir erhielten um 4:51 Uhr und um 8:19 Uhr Abuse-Nachrichten, die wir überprüften. Auf dem betroffenen System wurden folgende laufende Prozesse identifiziert.
PID TTY STAT TIME COMMAND 19446 ? S 0:00 timeout 3h ./tsm -t 515 -f 1 -s 12 -S 10 -p 0 -d 1 p ip 19447 ? S 0:00 /bin/bash ./tsm -t 515 -f 1 -s 12 -S 10 -p 0 -d 1 p ip
Um 9:53 Uhr wurde die Maschine gestoppt und gegen eine neu installierte VM getauscht, um den Service nicht zu unterbrechen. Zwischen 04:00 und 10:00 Uhr sind 435 MB Netzwerk Traffic entstanden (240 MB rx / 194 MB tx). Dieser lässt aufgrund des Verhältnisses zwischen den Paketen pro Sekunde sowie der genutzten Bandbreite und damit der Paketgröße auf ausgehende Portscans schließen. Die analysierte Bandbreiten-Nutzung deutet nicht auf einen Upload oder Download von Daten hin.
Was wäre theoretisch möglich gewesen?
- Login auf dem SIP-Yate.
- Das ist passiert, von dort aus wurden nachweislich Portscans in das Internet durchgeführt.
- Login auf allen PoC-VMs, die zum DiVOC gehören.
- Ein Login auf weitere PoC-VMs des DiVOC wäre über das interne Netzwerk zwischen den VMs möglich gewesen.
- Es konnten keine Logins in den Logs der VMs festgestellt werden.
- Auf der Sip-Yate-VM liegen die Credentials für den SIP Account von Sipgate (dialin).
- Diese haben wir geändert.
- Die mgr (Manager) VM hat den Api-Key für den GURU3.
- Somit hätte der Angreifer die Möglichkeit, Superuser im GURU3 zu sein.
- Der GURU3 zeigt keine Passwörter oder Hashes an.
- Der API-Key wurde durch uns neu generiert und hat nun nur noch die notwendigen Berechtigungen im GURU3.
- Es konnten keine Logins mit den Vagrant-Credentials auf die MGR-VM festgestellt werden.
- Alle GURU3-Zugriffe auf Seiten mit relevantem Inhalt (Userliste + Admin), konnten ausschließlich auf IPs von PoC-Mitgliedern zurückgeführt werden.
- In den Yate-Datenbanken sind enthalten:
- Name der Extension,
- SIP-Nummer der Extension,
- SIP-Passwort der Extension,
- IP-Adresse des aktuell angemeldeten Endgeräts.
- Yate Log:
- Bei der Analyse des Zwischenfalls haben wir bemerkt, dass bei der DiVOC-Installation mehr Logs geschrieben wurden als nötig.
- Das Logfile enthält Metataten von Anrufen, bei denen die Verarbeitung der Nachricht länger als 10 ms gedauert hat.
- Dieses Logverhalten wurde abgestellt.
Der größte anzunehmende Schaden betrifft die insgesamt 484 SIP-Nutzer*innen im Rahmen des DiVOC-Events. Der Angreifer könnte in den Besitz der SIP-Credentials und eventuell an die im Yate Log geschriebenen Metadaten gekommen sein. Dafür gibt es keine Indizien, wenn der Angreifer jedoch Superuser-Berechtigungen erlangt hat, könnte er Logfiles manipuliert haben. In Anbetracht der kurzen Zeit und des abrupten Stoppens der Maschine ist dies unwahrscheinlich.
Die Analyse der Traffic-Patterns hat ergeben, dass es sehr wahrscheinlich ist, dass ein automatisierter Angriff stattgefunden hat, der die bekannte Vagrant Schwachstelle ausnutzte, und von der VM aus Portscans durchgeführt wurden.
Wir haben seit dem Vorfall die SIP-Loginvorgänge auf dem Server sehr genau im Monitoring beobachtet und konnten bisher keine Unregelmäßigkeiten feststellen.
Wir haben sehr viel gelernt. Sowohl durch den Vorfall als auch durch die Analyse. Wir haben die Anlage mit allen VMs komplett neu installiert und die entsprechenden Konfigurationen angepasst. User die betroffen sein könnten, haben eine E‑Mail erhalten. Im Zuge des Vorfalls haben wir im GURU3 die Möglichkeit geschaffen, das SIP Passwort für entsprechenden Nebenstellen neu zu generieren.
Wir entschuldigen uns für die Panne. Beim nächsten Event müssen wir wohl einen Tschunk ausgeben. #amazingfailtomarket
Das PoC / Eventphone Team
ST ist Künstler und seit 2003 Teil des Eventphone Teams.