DiVOC: Sicherheitsproblem / unberechtigter Login

Tl;dr: Im Rah­men des DiVOC-Events hat­ten wir einen unbe­rech­tig­ten Log­in auf einer unse­rer vir­tu­el­ler Maschi­nen. Wir gehen davon aus, dass es ein Bot war und kei­ne Nut­zer­da­ten in frem­de Hän­de gelangt sind. Wir haben so gehan­delt, wie wir es uns von ande­ren in so einer Situa­ti­on wün­schen wür­den. Wir haben den Vor­fall sehr genau ana­ly­siert und alle per E‑Mail infor­miert, für die es ein Risi­ko gege­ben haben könn­te. Wir sind zu dem Schluss gekom­men, dass nur SIP-User­da­ten des DiVOC-Events betrof­fen sein kön­nen. Wir haben ent­spre­chen­de Maß­nah­men ergrif­fen und ein neu­es Fea­ture im GURU3 imple­men­tiert, mit dem ein neu­es ran­do­mi­sier­tes SIP-Pass­wort gene­riert wer­den kann. (Exten­si­ons -> Schlüs­sel -> Rege­ne­ra­te Pass­word)

Aus Trans­pa­renz­grün­den ver­öf­fent­li­chen wir hier den Vor­fall kom­plett und hof­fen, wir und ihr kön­nen dar­aus ler­nen. Wir ent­schul­di­gen uns bei allen Usern weil wir wis­sen, dass wir gro­ßes Ver­trau­en bei euch genie­ßen. Mit die­ser Akti­on haben wir wirk­lich einen Bock geschos­sen und es ist uns sehr pein­lich. Es war unser ers­ter Ver­such, das PoC kom­plett in der Cloud zu vir­tua­li­sie­ren, und wir hat­ten beim Spie­len die Tech­no­lo­gie, ganz offen­sicht­lich, nicht zu 100 Pro­zent unter Kon­trol­le. Es tut uns leid.

Regenerate Password

Es gab einen unbe­rech­tig­ten Log­in am 14.04.2020 gegen 4:30 Uhr auf unse­rem SIP Yate Ser­ver im Rah­men des DiVOC Events. Dies war mög­lich, weil:

  • Das nano PoC Set­up, wel­ches wir für das DiVOC nut­zen, mit Vagrant auto­ma­tisch instal­liert wur­de und
  • die Kon­fi­gu­ra­ti­on auf der Vagrant default Kon­fi­gu­ra­ti­on basier­te (in der Doku­men­ta­ti­on steht: it is a gene­ral con­ven­ti­on to set the pass­word for the “vagrant” user to “vagrant”.) und
  • die Maschi­ne via SSH im Inter­net ver­füg­bar war.

Wir erhiel­ten um 4:51 Uhr und um 8:19 Uhr Abu­se-Nach­rich­ten, die wir über­prüf­ten. Auf dem betrof­fe­nen Sys­tem wur­den fol­gen­de lau­fen­de Pro­zes­se iden­ti­fi­ziert.

  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 wur­de die Maschi­ne gestoppt und gegen eine neu instal­lier­te VM getauscht, um den Ser­vice nicht zu unter­bre­chen. Zwi­schen 04:00 und 10:00 Uhr sind 435 MB Netz­werk Traf­fic ent­stan­den (240 MB rx / 194 MB tx). Die­ser lässt auf­grund des Ver­hält­nis­ses zwi­schen den Pake­ten pro Sekun­de sowie der genutz­ten Band­brei­te und damit der Paket­grö­ße auf aus­ge­hen­de Port­scans schlie­ßen. Die ana­ly­sier­te Band­brei­ten-Nut­zung deu­tet nicht auf einen Upload oder Down­load von Daten hin.

Was wäre theo­re­tisch mög­lich gewe­sen?

  • Log­in auf dem SIP-Yate.
    • Das ist pas­siert, von dort aus wur­den nach­weis­lich Port­scans in das Inter­net durch­ge­führt.
  • Log­in auf allen PoC-VMs, die zum DiVOC gehö­ren.
    • Ein Log­in auf wei­te­re PoC-VMs des DiVOC wäre über das inter­ne Netz­werk zwi­schen den VMs mög­lich gewe­sen.
    • Es konn­ten kei­ne Log­ins in den Logs der VMs fest­ge­stellt wer­den.
  • Auf der Sip-Yate-VM lie­gen die Creden­ti­als für den SIP Account von Sip­ga­te (dialin).
    • Die­se haben wir geän­dert.
  • Die mgr (Mana­ger) VM hat den Api-Key für den GURU3.
    • Somit hät­te der Angrei­fer die Mög­lich­keit, Super­user im GURU3 zu sein.
    • Der GURU3 zeigt kei­ne Pass­wör­ter oder Hash­es an.
    • Der API-Key wur­de durch uns neu gene­riert und hat nun nur noch die not­wen­di­gen Berech­ti­gun­gen im GURU3.
    • Es konn­ten kei­ne Log­ins mit den Vagrant-Creden­ti­als auf die MGR-VM fest­ge­stellt wer­den.
    • Alle GURU3-Zugrif­fe auf Sei­ten mit rele­van­tem Inhalt (User­lis­te + Admin), konn­ten aus­schließ­lich auf IPs von PoC-Mit­glie­dern zurück­ge­führt wer­den.
  • In den Yate-Daten­ban­ken sind ent­hal­ten:
    • Name der Exten­si­on,
    • SIP-Num­mer der Exten­si­on,
    • SIP-Pass­wort der Exten­si­on,
    • IP-Adres­se des aktu­ell ange­mel­de­ten End­ge­räts.
  • Yate Log:
    • Bei der Ana­ly­se des Zwi­schen­falls haben wir bemerkt, dass bei der DiVOC-Instal­la­ti­on mehr Logs geschrie­ben wur­den als nötig.
    • Das Log­file ent­hält Meta­ta­ten von Anru­fen, bei denen die Ver­ar­bei­tung der Nach­richt län­ger als 10 ms gedau­ert hat.
    • Die­ses Log­ver­hal­ten wur­de abge­stellt.

Der größ­te anzu­neh­men­de Scha­den betrifft die ins­ge­samt 484 SIP-Nutzer*innen im Rah­men des DiVOC-Events. Der Angrei­fer könn­te in den Besitz der SIP-Creden­ti­als und even­tu­ell an die im Yate Log geschrie­be­nen Meta­da­ten gekom­men sein. Dafür gibt es kei­ne Indi­zi­en, wenn der Angrei­fer jedoch Super­user-Berech­ti­gun­gen erlangt hat, könn­te er Log­files mani­pu­liert haben. In Anbe­tracht der kur­zen Zeit und des abrup­ten Stop­pens der Maschi­ne ist dies unwahr­schein­lich.

Die Ana­ly­se der Traf­fic-Pat­terns hat erge­ben, dass es sehr wahr­schein­lich ist, dass ein auto­ma­ti­sier­ter Angriff statt­ge­fun­den hat, der die bekann­te Vagrant Schwach­stel­le aus­nutz­te, und von der VM aus Port­scans durch­ge­führt wur­den.

Wir haben seit dem Vor­fall die SIP-Log­invor­gän­ge auf dem Ser­ver sehr genau im Moni­to­ring beob­ach­tet und konn­ten bis­her kei­ne Unre­gel­mä­ßig­kei­ten fest­stel­len.

Wir haben sehr viel gelernt. Sowohl durch den Vor­fall als auch durch die Ana­ly­se. Wir haben die Anla­ge mit allen VMs kom­plett neu instal­liert und die ent­spre­chen­den Kon­fi­gu­ra­tio­nen ange­passt. User die betrof­fen sein könn­ten, haben eine E‑Mail erhal­ten.​​​​​​ Im Zuge des Vor­falls haben wir im GURU3 die Mög­lich­keit geschaf­fen, das SIP Pass­wort für ent­spre­chen­den Neben­stel­len neu zu gene­rie­ren.

Wir ent­schul­di­gen uns für die Pan­ne. Beim nächs­ten Event müs­sen wir wohl einen Tschunk aus­ge­ben. #ama­zing­fail­to­mar­ket

Das PoC / Event­pho­ne Team