Angriffe auf 3CX-Anlagen

[die-itler]

Hallo zusammen,

wir haben letzte Nacht Angriffe auf die von uns betreuten Telefonanlagen beobachtet. Diese stehen überall verteilt (3CX hosted, on-premise, Rechenzentrum).

Die Angriffe kamen von folgenden 3 IP-Adressen:
172.86.77.110
154.205.155.182
104.194.132.192

Hat noch jemand etwas ähnliches beobachten können?
In einem Fall wurde erfolgreich das Passwort eine Nebenstelle gekapert und Anrufe ins Ausland getätigt. Der Provider hat daraufhin alles gesperrt.

 

[mbehrens]

Hat noch jemand etwas ähnliches beobachten können?
In einem Fall wurde erfolgreich das Passwort eine Nebenstelle gekapert und Anrufe ins Ausland getätigt. Der Provider hat daraufhin alles gesperrt.

Nein.

Dies deutet regelmäßig auf eine Fehlkonfiguration der Firewall hin. Warum sind solche Zugriffe überhaupt erlaubt?

 

[die-itler]

Vielen Dank für die Antwort!

Aber wenn es ja an falschen Firewallkonfigurationen liegt... wieso passiert das dann auch bei 3CX Hosted Anlagen?

So fragend...

 

[fxbastler]

Aber wenn es ja an falschen Firewallkonfigurationen liegt... wieso passiert das dann auch bei 3CX Hosted Anlagen?

Die rhetorische Gegenfrage ist eher: Warum nicht? Das liegt in der Natur der Sache, einfach mal nachdenken: Ursache und Wirkung.

Dort ist das nicht falsch weil du es nicht ändern kannst. Dort ist es für dich evtl. suboptimal, aber im richtigen Rahmen (Passwortrichtlinien, Sperrregeln usw.) annehmbar.

Bei den eigenen Anlagen sollte man sich selber darum kümmen - auch weil man es kann:
https://www.3cx.de/forum/threads/3cx-android-app-automatische-aktivierung-video-bei-einem-videoanruf-möglich.122631/post-445604

 

[FredRa]

Hallo,
solche Angriffe wären uns nicht aufgefallen, dafür aber ein massiver Versuch per SIP intrusion Anrufe zu tätigen:
Mehrere Anfragen über sämtliche Telefonanlagen hinweg wie solche:

Unidentified Incoming Call. Review INVITE and adjust source identification: INVITE sip:***305@***.***.***.241 SIP/2.0 Via: SIP/2.0/UDP ***.***.***.73:5070;branch=***ccf9e0ccc3efabee428c5b645763b441;rport=5070 Max-Forwards: 70 Contact: <sip:test@***.***.***.73:5070> To: ***305<sip:***305@***.***.***.241> From: test<sip:test@***.***.***.241>;tag=675c042a Call-ID: ***ccf9e0ccc3efabee428c5b645763b441 CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, BYE Content-Type: application/sdp User-Agent: FreePBX 1.8 Content-Length: 284 v=0 o=sipcli-Session 109502462 1295092553 IN IP4 ***.***.***.73 s=sipcli c=IN IP4 ***.***.***.73 t=0 0 m=audio 5072 RTP/AVP 18 0 8 101 a=fmtp:101 0-15 a=rtpmap:18 G729/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=ptime:20 a=sendrecv

Bei einem ging es sogar soweit, dass Anrufe getätigt werden konnten. Wieso die 3CX hier diesen zugelassen hat ist noch fraglich.
Logs prüfen und jedenfalls darauf achten, dass SIP Anfragen nur vom SIP Provider kommen dürfen!

Es gibt auch einen Reddit Thread über möglichen Zero Day:

https://www.reddit.com/r/3CX/comments/1hrwp3x/some_customer_extensions_hacked_zero_day

Eigenartig auch, dass Aktivitätsprotokolle wie diese im Log erscheinen: 12.05.2025 10:26:56.479 [EC100009]: External application [3cx:0/PbxConfigTool] is disconnected: (Dashboard Aktivitätsprotokolle)

Ticket bei 3CX ist offen.

 

[bitn]

Hallo,
solche Angriffe wären uns nicht aufgefallen, dafür aber ein massiver Versuch per SIP intrusion Anrufe zu tätigen:
Mehrere Anfragen über sämtliche Telefonanlagen hinweg wie solche:

Unidentified Incoming Call. Review INVITE and adjust source identification: INVITE sip:***305@***.***.***.241 SIP/2.0 Via: SIP/2.0/UDP ***.***.***.73:5070;branch=***ccf9e0ccc3efabee428c5b645763b441;rport=5070 Max-Forwards: 70 Contact: <sip:test@***.***.***.73:5070> To: ***305<sip:***305@***.***.***.241> From: test<sip:test@***.***.***.241>;tag=675c042a Call-ID: ***ccf9e0ccc3efabee428c5b645763b441 CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, BYE Content-Type: application/sdp User-Agent: FreePBX 1.8 Content-Length: 284 v=0 o=sipcli-Session 109502462 1295092553 IN IP4 ***.***.***.73 s=sipcli c=IN IP4 ***.***.***.73 t=0 0 m=audio 5072 RTP/AVP 18 0 8 101 a=fmtp:101 0-15 a=rtpmap:18 G729/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=ptime:20 a=sendrecv

Bei einem ging es sogar soweit, dass Anrufe getätigt werden konnten. Wieso die 3CX hier diesen zugelassen hat ist noch fraglich.
Logs prüfen und jedenfalls darauf achten, dass SIP Anfragen nur vom SIP Provider kommen dürfen!

Es gibt auch einen Reddit Thread über möglichen Zero Day:

https://www.reddit.com/r/3CX/comments/1hrwp3x/some_customer_extensions_hacked_zero_day

Eigenartig auch, dass Aktivitätsprotokolle wie diese im Log erscheinen: 12.05.2025 10:26:56.479 [EC100009]: External application [3cx:0/PbxConfigTool] is disconnected: (Dashboard Aktivitätsprotokolle)

Ticket bei 3CX ist offen.

Ist die Anlage bei 3CX gehosted? Wenn nicht habt Ihr denn den SIP Port eingehend geöffnet ? Wir begrenzen den eingehend auf den Provider.

Beste Grüße

 

[FredRa]

Hi Bitn, danke für die Rückmeldung. Ja Anlage ist gehostet SIP Port war in diesem Fall eingehend geöffnet, nun hat der Kunde es aber nachgezogen.
Jedenfalls wurde der Anruf von "Test" getätigt, keine Extension trägt diesen Namen, von einem gehackten Account geht ich also nicht aus.

 

[die-itler]

Bei uns sah es übrigens genauso aus - es wurden auf allen Anlagen versuche unternommen, Anrufe zu tätigen.
Also gleiches Bild wie bei FredRa.

 

[FredRa]

Danke für die Antwort. SIP-Invites für offene Ports sind keine Seltenheit, ich ging nur davon aus, dass eine Art Authentifizierung stattfindet.
Stattdessen wird anscheinend der Inhalt des eingehenden SIP "From" Feldes nicht mit den Werten der Nebenstellen verglichen, worauf es einfach gespooft werden kann. Ich war mir dessen Umstand nicht bewusst. Auch, dass es keine Möglichkeit gibt dies anzupassen.

Der Eintrag [EC100009]: External application [3cx:0/PbxConfigTool] is disconnected: (Dashboard Aktivitätsprotokolle) ist allen Anschein nach ein Relikt von älteren Zeiten.

Damit ist es aber nun klar, danke für die Antworten!

 

[avraammich_3CX]

Hi,

IPs welche erwähnt wurden

172.86.77.110
154.205.155.182
104.194.132.192

Stehen schon in der Globalen Sperrliste.

Daher ist es empfehlenswert unter Admin Ansicht->Erweitert->Anti Hacking Optionen-> Option ->Automatische globale IP Sperrliste Option zu aktivieren(falls nicht aktiviert)
Option ist bei einer neu Installation einer 3CX Anlage bei default aktiviert.

 

[die-itler]

Guten Morgen,

ist bei allen Anlagen aktiviert (auch schon gewesen).

 

[avraammich_3CX]

somit schon mal auf der richtigen Seite.

Hier handelt es sich um klassische Scan/Brute Force Angriffe.

Don’t be “THAT” Guy Vol.1: Keep Complex Credentials

Our recent blog post “3CX Global IP Blacklist: Security By Default” highlighted the importance that we place on security and how we endeavor to combat

www.3cx.com

Don’t be “THAT” Guy Vol.2: Call Fraud

This blog post is the second of a series discussing the latest call fraud and hacking schemes we have observed. We spoke previously about the use of weak

www.3cx.com

Don’t be “THAT” Guy Vol.3: Top 4 PBX Security Tips

Following our last conversation about call fraud, it's time for another installment of our blog series ‘Don't be “THAT” Guy’. In this third edition, we’ve

www.3cx.com

Don’t be “THAT” Guy Vol.4: Monitor Your Instance

This is the 4th and final edition of our blog series. Last time we highlighted our top 4 security tips in Don’t be that guy Vol.3. In this edition, we

www.3cx.com

 

[M.Klaussner]

Die SIP Angriffsversuche finden immer wieder statt, und auch wir stellen fest, dass sich bestimmte IPs meist Nachts durch den kompletten Bestand an 3CX Systemen durchpflügen. Die werden dann auch der Reihe nach sauber gesperrt.
Nicht verstehen kann ich, wie man den Port 5060 denn kommend auf den Provider beschränken soll. Alle großen Netzbetreiber verwenden einen ganzen Pool an an IP Adressen, die auch nicht statisch bleiben und schon gar nicht veröffentlicht werden.

Wir haben zwischenzeitlich den Port 5060 für kommende Verbindungen gänzlich gesperrt.
Zwar meckert der Firewall Check, aber die SIP Verbindung wird ja von der 3CX initiiert und nie vom Netzbetreiber. Die Firewall muss also nur den Rückwärts Trafik durchlassen für eine Verbindung, die Sie selbst zum Provider initiiert hat.
Seither ist Ruhe. Identisch ist das bei klassischen OnPrem Anlagen. Der SIP Port muss nie kommend geöffnet werden. Warum der Firewall Check das möchte weiss ich nicht.

 

[fxbastler]

Nicht verstehen kann ich, wie man den Port 5060 denn kommend auf den Provider beschränken soll. Alle großen Netzbetreiber verwenden einen ganzen Pool an an IP Adressen, die auch nicht statisch bleiben und schon gar nicht veröffentlicht werden.

Der Pool ist i.d.R. durch den Betreiber dokumentiert. Dafür gibt es technischen Leistungsbeschreibungen. Mit geeigneten Mitteln kann man das auf Grund der verwendeten Kommunikation auch selber herausfinden. Wir betreiben - würde ich sagen - alle unsere Anlagen so.

Wir haben zwischenzeitlich den Port 5060 für kommende Verbindungen gänzlich gesperrt.

Auch das ist möglich wenn es kein IP basierender SIP Trunk ist. und div. andere möglichen (aber nicht gern gesehenen) Leistungsmerkmale einer PBX nicht benötigt werden.

Zwar meckert der Firewall Check

Dafür kann man den kurz öffnen oder Ausnahmen in der Firewall hinterlegen. Die Gegenstellen der Tests sind bekannt.

aber die SIP Verbindung wird ja von der 3CX initiiert und nie vom Netzbetreiber.

grds. richtig - außer (s.o.) es ist ein IP basierender SIP Trunk

Identisch ist das bei klassischen OnPrem Anlagen

nicht nur dort ...

 

[M.Klaussner]

Also bei Telekom weiss ich, dass es einen IP Pool gibt, der allerdings auch regional variieren kann. Selbst bei den DNS der Telekom ändert sich immer wieder was. Wir mussten uns schon mehrfach telefonisch DNS Adressen geben lassen, weil bei B nicht funktioniert, was bei A problemlos klappt. Sprich Company Flex Registrierung...

Das mit dem Firewall Check ist soweit klar. Kurz öffnen, dann bekommt man sein grünes Häkchen und gut ist es.

 

[patrickb]

Zwar meckert der Firewall Check,

Kurz öffnen, dann bekommt man sein grünes Häkchen und gut ist es.

Wenns euch nur um die Kosmetik im Dashboard geht: Global Property -> FIREWALL_CHECKER_RESULT -> 1 dann siehts wieder schick aus.

 

[bitn2]

Also bei Telekom weiss ich, dass es einen IP Pool gibt, der allerdings auch regional variieren kann. Selbst bei den DNS der Telekom ändert sich immer wieder was. Wir mussten uns schon mehrfach telefonisch DNS Adressen geben lassen, weil bei B nicht funktioniert, was bei A problemlos klappt. Sprich Company Flex Registrierung...

Das mit dem Firewall Check ist soweit klar. Kurz öffnen, dann bekommt man sein grünes Häkchen und gut ist es.

Ich kenne kaum einen Anbieter wo die Netze nicht bekannt sind. Gerade Telekom ist nun wirklich einfach: 217.0.0.0/13

 

[mbehrens]

Nicht verstehen kann ich, wie man den Port 5060 denn kommend auf den Provider beschränken soll. Alle großen Netzbetreiber verwenden einen ganzen Pool an an IP Adressen, die auch nicht statisch bleiben und schon gar nicht veröffentlicht werden.

Dann beschäftige Dich mit den Grundlagen der IP/VoIP Kommunikation und hänge nicht einfach Anlagen ins öffentliche Internet oder lebe mit den Folgen.
VoIP Anbieter haben in der Regel eine technische Dokumentation.