Heute, am 19.12.2020 haben wir eine neue Version des GURU3 deployed, bei der es zu einem Sicherheitsproblem kam, wenn zwei Nutzer*innen zum selben Zeitpunkt eine beliebige Seite im GURU aufgerufen haben. Es ist reproduzierbar zu der Situation gekommen, dass eine Nutzer*in eine Seite anforderte und einen Timeout bekam, während die Seite an eine andere Nutzer*in ausgeliefert wurde. Es konnte somit z. B. eine fremde Nutzer*in die Übersicht der Extensions einer anderen Nutzer*in sehen und somit auch an die SIP Zugangsdaten und / oder die DECT-Tokens gelangen. Wer heute zwischen 18:34 und 19:49 Uhr im GURU eingeloggt war und einen Timeout bekommen hat muss unbedingt seine SIP Kennwörter von aktiven Events (aktuell rC3 und EPVPN) ändern, um sicherzugehen, dass diese nicht missbraucht werden. Dies ist mit dem “Regenerate Password” Knopf beim Schlüsselsymbol in der Extensions-Übersicht zu bewerkstelligen. Bereits genutzte DECT-Tokens sind “invalid”. Wer ein neues nicht benutztes DECT-Token möchte, meldet sich bei poc at eventphone.de oder meldet sein DECT Gerät an, dadurch wird der Token unbrauchbar. Eine DECT Extension in SIP ändern und dann wieder zurück in DECT, löst das Problem auch, da ein neues Token generiert wird.

Analyse

Die Ursache lag in einem Update der Django Channels Komponente von kleiner 3 auf Version 3.0.2. In den Release Notes wird erwähnt, dass die bisherige Konfiguration nicht mehr unterstützt wird und es sollte auch eine Warnung ausgegeben werden, was in unserem Setup jedoch nicht passierte.

./manage.py runserver
Performing system checks...

Libdtmx not found. Barcodes not available!
System check identified no issues (0 silenced).
December 19, 2020 - 17:44:34
Django version 3.0.11, using settings 'guru3.settings'
Starting ASGI/Channels version 3.0.2 development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
Performing system checks...

Im Daphne GitHub Repository gibt es auch ein geschlossenes Issue das den Fehler und eine Lösung beschreibt.

Zeitlicher Ablauf

2020-12-19 18:34 Deployment der problematischen Konfiguration
2020-12-19 19:28 PoC Mitglieder bemerken das Problem
2020-12-19 19:44 Vermutung, dass die Reponse an andere User ausgeliefert wird
2020-12-19 19:49 Abschaltung des GURU3
2020-12-19 20:45 Reaktivierung des GURU3

Was haben wir gelernt?

1. Bei allen Updates immer die Release Notes genau durchlesen.
2. Nicht unter Zeitdruck auf das Livesystem deployen.
3. Immer Vier-Augen-Prinzip.
4. Im Testsystem ausgiebig testen und dann erst auf Live deployen.

Bei Fragen wendet euch an uns via poc at eventphone.de.

Wir entschuldigen uns für die Panne und arbeiten daran, unsere Abhängigkeiten von Komponenten zu verringern, bei denen wir keine Kontrolle über die Qualität haben, um das Risiko solcher Vorfälle zu minimieren.

Euer PoC / Eventphone Team

ST

ST ist Künstler und seit 2003 Teil des Eventphone Teams.

www.kambor-wiesenberg.de/

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

ST ist Künstler und seit 2003 Teil des Eventphone Teams.

www.kambor-wiesenberg.de/