Grandstream UCM 6202 mit 1und1 und Fritzbox in Betrieb genommen und gleich "gehackt" worden?

[Covos]

Ich habe vorgestern nach lamgem Hin und Her endlich die Grandstream Telefonanlage UCM 6202 hinter einer Fritzbox so eingerichtet bekommen, dass sie eine über einen 1und1-DSL-Vertrag geschaltete Telefonnummer verwenden kann (Thread). Nun fiel auf, dass direkt in derselben Nacht zwischen ca. 3:40 Uhr und 5:50 Uhr diverse Vorgänge in der Anlage gestartet wurden. Schaut man sich den Bereich CDR (Call Detail Record) an, fällt auf, dass hier etliche Male auf verschiedene Versionen der Nummer "angerufen" wurde. In der darauf folgenden Nacht ging es gegen 20 Uhr los und dauerte erneut bis ca. 6 Uhr an. Diesmal wurden aber verschiedene Nummern angewählt und auch diverse Gespräche angenommen. Hier zwei Screenshots aus dem CDR:
1und1 hat diese Zugriffe registriert und automatisch entsprechende Sperrungen vorgenommen.

Wenn ich mir nun die Logs anschaue, werden hier die verschiedenen Abgangsquellen "Call from" angezeigt. Alle Anrufe, die durchgegangen sind, wurden von der 1000 getätigt - eine "Extension" (also ein Anlagennutzer = in unseren Fall ein Telefon), die wirklich in der Anlage geschaltet ist. Darüber hinaus wurden offensichtlich Brute-Force-mäßg einfach weitere Logins versucht. Ob nun 100000 oder Admin oder Test usw. Da alle diese nicht vorhanden sind, war hier kein Durchkommen. Die 1000 hingegen schon. Hier ist kein einfaches Passwort vergeben, sondern ein komplexes mit > 10 Stellen und Sonderzeichen, Groß- und Kleinschreibung, Zahlen...

Nun stelle ich mir folgende Fragen:

1. Wie kann es sein, dass nur kurze Zeit nachdem ich die Anlage aktiv geschaltet habe, bereits die ersten Angriffe gelaufen sind? Es sollte ja eigentlich kein öffentliches Register geben aus dem man neue Anlagen so einfach auslesen kann.
2. Ich habe auf der einen Seite natürlich sofort das Passwort der Extension 1000 geändert und noch komplexer gemacht, aber wie kann ich verhindern, dass einfach weiter solche Angriffe auf die Anlage laufen?
3. Ist es "nur" die einzelne Extension, die angegriffen wird und geschützt werden muss oder müsste ich auch andere Passwörter (Telefonanlage, 1und1-Nummern-Einwahl etc.) berücksichtigen?
4. Um die Extensions etwas mehr zu schützen, könnte ich mir vorstellen, dass es sicherer wäre zusätzlich zur "Nebenstellen-ID" (also hier aktuell z.B. die 1000), die wohl standardmäßig vergeben und genutzt werden eine optional zu vergebende Auth-ID zu nutzen, die wie das Passwort aus Zeichen-Salat bestehen könnte wie bespielsweise . Das würde zwar an den Brute-Force-Angriffen auf die Anlage nichts ändern aber würde wohl den Zugriff auf die Extensions deutlich erschweren. Ist der Ansatz nachvollziehbar?

Danke im Voraus für Eure Unterstützung!

 

[koyaanisqatsi]

Moinsen


Nach meinen Verständnis dürfte ein Wahlplan/Misskonfiguration das Loch sein.
Dann ging der Anruf nicht an die 1000 sondern über die 1000.
Wenn dies dann nicht über 1&1 sondern direkt als SIP URI Call auf deine fürs Internet freigegebene UCM passiert und die das erlaubt, kann 1&1 logischerweise nichts dafür.

Wie siehts denn mit SIP Logs von deiner Seite aus?

 

[Covos]

Hi @koyaanisqatsi - fast wie im Chat. Danke für den ersten Ansatz!
Ja, ich denke auch, dass die 1000 genutzt wurde, um die Anrufe zu tätigen (s.a. Screenshots, die ich so interpretiert habe). Für mich wäre also die Schlussfolgerung, dass jemand sich als "Client" an meiner UCM mit der 1000 anmelden konnte. So als ob ich die SIP-Proxy-URL (in dem Fall durch die MyFritz-Funktion zur Verfügung gestellt) zusammen mit dem Port (hier 5070) dem Zugangsuser 1000 und dem dazugehörigen Passwort verwendet hätte.
1und1 kann selbstverständlich nichts dafür, ich bin sehr froh, dass die das gemerkt haben, da doch einige Anrufe erfolgreich und somit kostenpflichtig in dei ganze Welt gegangen sind.

Mit den SIP-Logs bzw. deren Auswertung komme ich bislang noch nicht wirklich klar. Ich habe mir die Daten in Wireshark gezogen, bin aber beim Filtern bzw. Verstehen der Daten noch nicht wirklich weit.

 

[chrsto]

Du schreibt in deinem anderen Beitrag, dass du die Anlage auf Port 5070 betreibst und diesen über die Fritzbox von außen erreichbar gemacht hast.

Damit hängt die Anlage "mit dem nackten Arsch" im Internet und ist erreichbar. Dann ist es natürlich ein Leichtes die Extensions - 1000 ist nun wirklich ziemlich einfach - durchzuprobieren. Wenn dann, wie häufig üblich, das Passwort für die 1000 auch noch 1000 war, ist es passiert.

 

[Covos]

Hi @chrsto - ist meine erste Anlage, daher bitte ich Anfängerfragen zu entschuldigen: Muss eine VOIP- / SIP-Telefonanlage nicht von außen über das Internet (auf irgendeinem - meist 5060 bei UDP) erreichbar sein? Ich will ja damit nicht nur innerhalb meines Netzwerkes telefonieren.
Wie o.g. war das Passwort nicht "1000" sondern komplex zusammengewürfelt und über 10 Stellen lang - daher wundert es mich wenn dieses so schnell gehackt werden konnte. Dies und wie die Anlage so schnell als "nackter Arsch" identifiziert werden konnte.

 

[chrsto]

Es gibt Suchmaschinen, z.B. shodan, die auf sowas spezialisiert sind. Und der "nackte Arsch" war keine Bewertung deiner Person, sondern eine Verdeutlichung, dass Portfreigaben wohl überlegt sein sollen

 

[kleinkariert]

Entgegen der hier im Forum oft geäußerten Meinung gebe ich für keine meiner "richtigen" VoIP-TK-Anlagen außer den RTP/UPD-Ports entsprechend Providervorgaben was frei. Anders schaut es natürlich aus, wenn man externe VoIP-Telefone ohne VPN anbinden will, was ich aber strikt vermeide.

P.S. Die Nummer kann man hier finden: http://www.networksystemssolutions.eu/voipblocklist.php

 

[Covos]

@chrsto Danke für den Hinweis mit shodan. Das war mir nicht mehr bewusst.
Du meinst es würde einen Unterschied machen, ob ich Port 5070 oder 5044 oder einen anderen verwende?
Wenn ja, wäre es ja ein Ansatz
1. den Port zu wechseln
2. jeweils eine kryptische Auth-ID pro Extension zu verwenden
3. (selbstverständlich) ein sicheres Passwort zu verwenden

Wie gesagt: Ich bin sehr verwundert, dass das komplexe PW des 1000er Users so schnell gehackt werden konnte. Wenn im CDR wirklich alle Vorgänge drin wären, hätte der Angreifer das PW in unter 500 Zugriffen "erraten". Ich gehe daher davon aus, dass man über das SIP-Log noch weitere Zugriffe sehen könnte.

Ich habe mich mal mit den Sicherheitsmöglichkeiten der Anlage beschäftigt und gesehen, dass sie hier einige Möglichkeiten zur Verfügung stellt, die ich bislang nicht aktiviert hatte. Unter System Settings > Security Settings gibt es einige Dinge, die man nutzen kann und die ich nun aktiviert habe:
Einige Infos habe ich HIER gefunden und umgesetzt.

1. Dynamic Defense
2. Fail2ban
3. Local Settings

Da ich die Notwendigkeit habe auch von Softphones mit wechselnder IP zur arbeiten, kann ich die Anlage nicht ganz dicht machen aber dichter.
Ich habe nun den SIP-Trunk deaktiviert, das Passwort für die 1000 geändert und werde noch eine Auth-ID hinterlegen. Mal sehen was die nächste Nacht bringt. Kosten sollten ja keine mehr entstehen können, da der Trunk deaktiviert ist.
Ich werde berichten

 

[chrsto]

Den Port zu wechseln macht keinen Sinn. Das ist security by obscurity und bringt nichts.

Ich halte prizipiell nichts davon Dienste von außen erreichbar zu machen. Auch "sichere" Benutzer und Passwörter bringen im Zweifelsfall nichts. Sobald eine Sicherheitslücke existiert, bist du wieder fällig.

Wenn du unbedingt von außerhalb drauf zugreifen willst, dann bitte mit VPN und wie Olaf Ligor zuvor schon richtig geschrieben hat, ist eine Portweiterleitung für funktionierendes VoIP nicht nötig.

 

[koyaanisqatsi]

Was die Sicherheit angeht.
Um darüber was sagen zu können, wäre ein Pentest vonnöten.
Hat wenig mit Schreibgeräten zu tun, Pen steht hier für Penetration oder Eindringen.
Für Asterisk PBXe gibts was Feines in Python, nennt sich...
https://github.com/EnableSecurity/sipvicious/wiki

Apropos Asterisk
Der registriert sich bei mir nirgendwo extern.
...auch nicht lokal an FRITZ!Box Registraren.
Aber, wenn eine FRITZ!Box ( als DSL-Router ) eine Nummer am Asterisk registriert, ist diese auch aus dem Internet erreichbar*.
Deswegen sollten Asterisk Wahlpläne für User/Peer Kontexte wo sich diese Nummer tummelt penibel auf "unerwünschte Weiterleitungen" geprüft/getestet werden.


* Via SIP URI Call ohne Internettelefoniedienstanbieter (hechel, hechel)

 

[Covos]

@chrsto Wenn du meinst "von außen erreichbar zu machen". Ich als Neuling in dem Thema sehe zwei Aspekte bzgl "von außen erreichbar".

1. Extensions (also Endgeräte / Clients) sollen sich an der Anlage anmelden können, um zu telefonieren
2. Die Anlage verbindet sich mit dem VOIP-Anbieter und andersrum

Ich hatte ja (wie im anderen Thread zu sehen) das Problem, dass ich zwar raustelefonieren konnte aber keine eingehenden Anrufe bekam. Das wurde dann damit erreicht, dass ich in der FB den Port 5070 für die Anlage geöffnet habe. Ohne dies ging es nicht.

Parallel wird die Anlage übrigens wieder stark angegriffen
Im SIP-Log konnte ich sehen, dass IPs geblockt zu werden scheinen auch wenn es in der Liste unterhalb der Fail2ban-Einstellungen im Bereich der geblockten IPs keine Einträge gibt. Hört sich so ein wenig an wie in dem benannten Thread aus Beitrag 8 wobei es hier ja hieß, dass dies mit einem Update behoben worden wäre. Ich würde mich ja sehr freuen, wenn hier bald mal ein paar geblockte IPs auftauchen würden.
In dem SIP-Log taucht die IP 192.168.1.83 häufig auf - keine Ahnung woher die kommt. Lokal haben wir solche IPs nicht. Die 192.168.178.5 ist übrigens die Anlage.

Das mit der VPN-Verbindung wäre sicherlich die sicherste Variante aber hätte in meinem Fall ziemlich viele Einschränkungen weswegen ich nach Möglichkeit darauf verzichten will.

Der Pentest sieht sehr interessant aus, ich bezweifle jedoch, dass ich das aktuell hinbekommen würde. Merke ich mir aber mal für später.

 

[chrsto]

Ich habe mal kurz Google bemüht, zum Thema 1&1, Router und IP Telefonanlage dahinter. Es scheint tatsächlich so zu sein, dass dieses Setup nur mit Portweiterleitung funktioniert. Jedenfalls, habe ich bisher 3 Beiträge dazu gefunden.

Unter https://forum.opnsense.org/index.ph...ve3jgo3emog57r7r&topic=4712.msg18404#msg18404 gibt es eine Liste mit IP Adressen der VoIP Server von 1und1.

Ich kenne die Grandstream nicht und weiß auch nicht, ob die Liste aktuell ist. Aber ggf. kannst du die Anlage so einstellen, dass 192.168.178.0/24, also dein lokales Netz, und die Adressen von 1und1, oder *.1und1.de sich mit der Anlage verbinden dürfen (Whitelist) und der Rest geblockt wird. Jedenfalls sah die Funktion Dynamic/Static Defense so aus.

EDIT: Allerdings würde ich, bevor ich mir so ein Setup zurechtpuzzle, lieber die Rufnummern in der FritzBox registrieren und dort entsprechende IP Telefone anlegen, bei denen sich dann wieder die Telefonanlage registriert.

Mit dem externen Zugriff habe ich dich vielleicht missverstanden. Ich meinte damit, dass du von Unterwegs über eine HandyApp via VoIP über die Anlage telefonieren willst, aber es sind wohl nur lokale Telefone, richtig?

 

[Covos]

Guten Morgen @chrsto . Danke für die Rückmeldung. Ich werde gleich nochmal kurz zusammenfassen was der Hintergrund des ganzen Aufwands ist. Als kleines Update bzgl. Angriffen auf die Anlage: Seit gestern Abend 18 Uhr bis jetzt wurde laut CDR insgesamt knapp 1150 mal versucht sich als Extension anzumelden und zu telefonieren. Ich habe das CDR-Log einmal teilanonymisiert als Excel (gepackt mit Passwort "ip-phone-forum") angehängt wenn es interessiert. Leider ist in der Übersicht die Quell-IP nicht zu entnehmen. Hier muss ich mal schauen, ob man die aus einem anderen Log bekommt.

Warum mache ich den ganzen Aufwand und verwende nicht einfach die FB? Ich hatte HIER den Hintergrund kurz zusammengefasst. Es sind mittlerweile einfach zu viele Nummern und Telefone geworden, so dass die FB das nicht mehr verwalten kann.
Wenn es hingegen möglich wäre, dass die FB die Nummern registriert, die komplette Verwaltung der eigentlichen Telefonie (also Registrierung der Endgeräte, In- und Outbound Routes, Klingelfolgen, Regeln.....) aber über die Grandstream UCM liefe, wäre das ein Ansatz, wobei ich dann weiterhin das Problem mit der Notwendigkeit der externen Anmeldung (Homeoffice, Dienstreise, Notfallerreichbarkeit) hätte.
Soweit ich das gesehen habe, kann man aber in der FB nicht sagen "registriere die Nummern aber überlass' alles andere der Telefonanlage auf IP XY". Man müsste m.E. für jede Nummer (mind.) ein Ziel definieren, welches dann die Anlage sein würde. Nur kann diese dann die komplette Differenzierung der eingehenden Nummern mit den entsprechenden Funktionen noch anbieten?

Ich werde mich mal mit Deinem Verweis bzgl. opnSense auseinandersetzen und ich denke, dass die Idee mit dem Blocking ein Ansatz ist. Auffällig ist übrigens, dass die Angriffe immer früher anfingen aber immer pünktlich um kurz vor 6 (Berlin Zeit) aufhörten.

 

[chrsto]

Muss es denn eine Fritzbox sein? Die Funktion eines SBC/Mediagateways/Routers könnte ja auch eine bintec be.ip plus übernehmen.

 

[Covos]

Aktuell könnte wohl -wenn es sein müsste- darauf verzichten, da es bald aber Glasfaser gibt, muss es dann (zumindest zur Zeit mangels erschwinglicher Alternative) die FB 5490 sein. Weiterhin haben wir bereits einiges an Hardware von Grandstream (Hand- und Tischtelefone, DECT-Station), deren Rückgabefrist leider abgelaufen ist.
Was wäre denn Dein Ansatz? Die GS und die FB rauswerfen und z.B. die bintec verwenden? Was würde die anders machen als die GS? Müsste die nicht auch von außen erreichbar sein für die SIP-Provider und die Endgeräte?

 

[chrsto]

Nein, ich meine damit, die Fritzbox rauswerfen und dafür die be.ip plus. Diese ist dann ein SBC für deine Grandstream Anlage. Wie das geht, ist beispielhaft bei youtube erklärt:

Wenn dann Glas kommt, hat der Anbieter evtl. auch ein reines Modem/ONT im Angebot, dann kann auch die be.ip plus bleiben.

 

[Covos]

Danke für den Hinweis. Dann weiß ich was noch möglich wäre. Aktuell will ich aber an der Grandstream-Lösung festhalten.
Für das Wochenende habe ich nun einmal die Security Einstellungen extrem hoch gesetzt und das zeigt auch schon eine Wirkung. Ich erhalte bei jedem Block eine Mail und die werden immer mehr ;-)

Weiterhin habe ich für die Extensions nun Auth-IDs vergeben bei denen wahrscheinlich das ein und andere Passwort blass würde. Beispiel 1C!O!MN!#TA4TyBf1LJn - wird bei der GS eine Auth-ID für eine Extension vergeben, muss auch diese und nicht mehr die Nebenstellennummer (1000 o.ä.) für die Registrierung verwendet werden. Das Passwort zu dieser Auth-ID habe ich ebenfalls neu vergeben nach demselben Muster. Da würde es mich schon sehr wundern, wenn einer das hackt - vor allem in Kombination mit den Block-Einstellungen.

Aus anderen Threads habe ich entnommen, dass die Angriffe -wenn es einmal geklappt hat- sehr stark zunehmen und wenn es dann nicht mehr klappt nach einigen Tagen bis Wochen dann auf ein "normales" Maß abnehmen. Mal schauen. Weiterhin sind aber alle SIP-Trungs sowie Outbound-Routes zusätzlich deaktiviert, so dass hier auch nichts passieren kann.

Nächste Woche werde ich berichten.

 

[koyaanisqatsi]

Du kannst auch mal die SIP Logs aus der FRITZ!Box ziehen.
Log dich dafür ein...
http://fritz.box/support.lua
...und lass dir dort die erweiterten Support-Daten erstellen.
Nach dem Download der mehrere Megabyte grossen Textdatei im Webbrowser oder Texteditor öffnen und suche nach: SIP Log
Da habe ich gerade eben den hier...

2020-05-29 19:51:47.299 - IN: my=192.168.178.1%16:5060 peer=77.247.110.58 port=5786 UDP, sipiface=none:
OPTIONS sip:[email protected] 2.0
Via: SIP/2.0/UDP 77.247.110.58:5786;branch=z9hG4bK-4074907591;rport
From: "sipvicious" <sip:[email protected]>;tag=32653865303030343133633401393038343037353534
To: "sipvicious" <sip:[email protected]>
Call-ID: 719504108870230204880473
CSeq: 1 OPTIONS
Contact: <sip:[email protected]:5786>
Max-Forwards: 70
User-Agent: friendly-scanner
Accept: application/sdp
Content-Length: 0

...gefunden.
Die FRITZ!Box beantwortet OPTIONS negativ, aber die Antwort reicht um zu Wissen dass es ein SIP-Server ist.
So ein Scan wurde aus dem Internet mit SipVicious durchgeführt.
( Und Nein, icke war dat nich )

Unter dem "SIP Log" kommt noch das...

##### BEGIN SECTION invite SIP INVITE messages
SIP INVITE log

...welches die eingehenden Anrufe repräsentiert.
Diese Logs sind ein so genannter "Shrinkbuffer".
Haben eine feste Grösse und alte Einträge fallen deshalb "hinten runter".
Bei Verdächtigen Aktivitäten sollten Support-Daten sehr Zeitnah erstellt werden.
Sonst verschwindet der übeltätrige Eintrag ins Nirwana, /dev/null ist des Blackhats Freund.

Noch was
Ich hab zwar keine Ahnung von SBCs.
Aber meiner FRITZ!Box vertraue ich soweit, dass ich meinen "Asterisk zum Üben" niemals nicht zur Internetseite direkt freigeben würde.
Eine registrierte Asterisknummer in der DSL FRITZ!Box kann schon brandgefährlich werden.
Die Wahlpläne sollten wasserdicht sein.
Ich versuch sowas mit einer einfachen Datenbankanfrage, wenn vorhanden, dann wird das komplette Dial() Kommando aus der Datenbank geholt und gewählt, ansonsten wird direkt wieder aufgelegt.
Hört sich vielleicht kompliziert an, aber ist ein simpler Einzeiler...

ExecIf($[${DB_EXISTS(${CONTEXT}/${EXTEN})}]?${DB_RESULT}:Hangup(17))

Das Gegenteil einer schwarzen Liste ist eine: Whitelist

 

[PBXservice]

Hallo liebe IPPF Gemeinde,

ich bin ganz neu hier, im Bereich der professionellen VoIP-Anlagen aber schon länger unterwegs. Gerade mit der UCM hab ich einige Erfahrung.

Absolut notwendig um die Anlage sicher zu halten:
- "Allow Guest Calls" muss deaktiviert sein! Zu finden unter: WebGUI->PBX Settings ->SIP Settings -> General
- Portforwarding nur einrichten, wenn eine professionelle Firewall (PFsense, Ubiquiti USG, etc.) zum Einsatz kommt
- Wenn in der FritzBox keine Rufnummern hinterlegt und Endgeräte angemeldet sind, routet die SIP Anfragen meistens auch durch, hängt aber immer auch vom Modell und der Firmware ab (hab da noch kein Muster erkannt)
- Zur Not lieber die Rufnummern auf der FritzBox registrieren und jede einzelne Nummer dann als Trunk in der UCM anmelden (funktioniert, ist nicht schön, aber besser als hohe Telefoniekosten)
- Die AKTUELLSTE Firmware installieren. Auch aus aktuellem Anlass extrem wichtig, da die vorherigen Firmwares mit einem fettem Exploit daherkommen.
- Wenn Remote Nebenstellen ohne VPN genutzt werden, UNBEDINGT SIPS (SIP TLS) einrichten. Ist zwar ein Haufen Arbeit, aber super wichtig und wird auch vom GSWave Softphone unterstützt.
- Und natürlich alle Security Funktionen im Webinterface der Anlage voll ausnutzen

Hier auch nochmal einige dieser Punkte zusammengefasst:

http://www.grandstream.com/sites/default/files/Resources/UCM_Security_Manual.pdf

 

[chrsto]

- Portforwarding nur einrichten, wenn eine professionelle Firewall (PFsense, Ubiquiti USG, etc.) zum Einsatz kommt

Weil sich ein Angreifer dann denkt: "Shit! PFsense/Ubiquiti, da dreh ich lieber um"?