DiVOC - EVENTPHONE - Blog https://eventphone.de/blog/ stay informed Mon, 01 Mar 2021 16:40:25 +0000 en-US hourly 1 https://wordpress.org/?v=6.8.3 https://eventphone.de/blog/wp-content/uploads/2018/02/cropped-logophone_color-1-32x32.png DiVOC - EVENTPHONE - Blog https://eventphone.de/blog/ 32 32 DiVOC – Reboot to Respawn https://eventphone.de/blog/2021/03/01/divoc-reboot-to-respawn/ Mon, 01 Mar 2021 16:30:13 +0000 https://eventphone.de/blog/?p=499 Continue reading "DiVOC – Reboot to Respawn"

]]>
English Version below

Nun ist es genau ein Jahr her, dass uns die Pandemie in die Party gegrätscht ist. Das Digital Verteilte Online-Chaos (DiVOC) Jährt sich zum ersten Mal unter dem Motto Reboot to Respawn (R2R) und ermöglicht es uns einen Ort im Netz zu haben, um uns zu treffen und uns auszutauschen. Gerahmt wird das Ganze von Karfreitag bis Ostermontag (02.04. – 05.04.2021) mit einem Programm aus Vorträgen, Kunst und Musik.  🙂


Damit ihr wie gewohnt ungestört und unüberwacht kommunizieren könnt wird es auch wieder eine Telefoninfrastruktur geben, die technisch der des rC3 entsprechen wird. Die Registrierung der Nebenstellen ist bereits geöffnet.

Es werden SIP, Announcement und Eventphone Decentralized DECT Infrastructure (EPDDI) zur Verfügung stehen.

Für Chaos Studios, Hackerspaces & Chaostreffs stellen wir eine kleine Anzahl an RFPs (Antennen) zur Verfügung. Wie immer brauchen wir dafür zuverlässige Ansprechpartner*innen die sich um den Versand kümmern und sicherstellen, dass wir die Antennen auch nach dem Event sicher zurückbekommen. Wenn du eine EPDDI Zelle betreiben möchtest, lies dir die EPDDI Doku durch und stelle einen passenden Router bereit.  Wenn das der Fall ist, melde dich unter poc ‘at’ eventphone.de. Der Versand findet am 22.03.2021 statt.

Ab 22.03.2021 wird auch spätestens die Telefoninfrastruktur laufen.

Schwankungen im Betriebsablauf kommunizieren wir wie gewohnt via Twitter.

Viel Spaß an den Geräten und bleibt gesund,
euer Eventphone Team

DiVOC – Reboot to Respawn

It’s been exactly one year since the pandemic crashed our party. The DiVOC (german: Digital Verteiltes Online-Chaos, means Digital Distributed Online Chaos) will be celebrating its first anniversary under the motto Reboot to Respawn (R2R) and will allow us to have a place on the net to meet and exchange ideas. Framed from Good Friday to Easter Monday (02.04. – 05.04.2021) with a program of talks, art and music.  🙂

To ensure that you can communicate undisturbed and unwatched as usual, there will be again a telephone infrastructure, which will technically correspond to that of the rC3. The registration of extensions is already open.

SIP, Announcement and Eventphone Decentralized DECT Infrastructure (EPDDI) will be available.

For Chaos Studios, Hackerspaces & Chaostreffs we provide a small number of RFPs (antennae). As always, we need reliable contact persons to take care of the shipping and to make sure that we get the antennas back safely after the event. If you want to run an EPDDI cell, please read the EPDDI documentation (currently only in german) and provide a suitable router. Than contact us at poc ‘at’ eventphone.de. The shipment will take place on 22.03.2021.

From 22.03.2021 at the latest, the telephone infrastructure will also be up and running.

We will communicate fluctuations in the operating process via Twitter.

Have fun  and stay healthy,
your Eventphone Team

]]>
DiVOC: Sicherheitsproblem / unberechtigter Login https://eventphone.de/blog/2020/04/15/divoc-sicherheitsproblem-unberechtigter-login/ Wed, 15 Apr 2020 18:00:27 +0000 https://eventphone.de/blog/?p=398 Continue reading "DiVOC: Sicherheitsproblem / unberechtigter Login"

]]>
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.

Regenerate Password

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

]]>