Blocked WAN REGISTER attempt — is it possible to see what password was used?

[tech3x]

Hi Everyone,

I’m running V20 Update 7 with an SBC on-prem and the PBX hosted in a private cloud.

I’m seeing the following log entry on our 3CX system and wanted to sanity-check my understanding and ask about logging depth.

Event ID: 12291

SIP request (REGISTER) from 103.108.63.155 was rejected. Reason: Block WAN requests is ON. . Message:. REGISTER sip:[MYSERVERIP]:5060 SIP/2.0. Via: SIP/2.0/UDP 103.108.63.155:50643;branch=z9hG4bK-b87543-3556911174524-1--d87543-;rport=50643. Max-Forwards: 70. Contact: <sip:[email protected]:50643>. To: <sip:206@[MYSERVERIP]>. From: <sip:206@[MYSERVERIP]>;tag=e5f4f2912606117451EBC. Call-ID: e5f4f291260713117450c4f7a. CSeq: 2 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. Proxy-Authorization: Digest username="206",realm="3CXPhoneSystem",nonce="414d5359008ebb2s44:b4d54ff442983e32b47b8fb31dad9312",uri="sip:[MYSERVERIP]:5060",response="98fa64f413de70776efed4d0scb9fd88",algorithm=MD5. User-Agent: 3CX Phone System. Content-Length: 0

From what I can tell, this was a direct WAN SIP REGISTER attempt that was correctly blocked because Block WAN Requests is enabled (phones register via SBC/VPN only).

What caught my attention is that the request includes valid authentication headers for extension 206, which suggests either a guessed or previously known credential.

My questions:

1. Are there any logs (event log, activity log, SIP traces, etc.) that would show what password or hash was attempted during this REGISTER?
2. Or does 3CX intentionally not log credential details beyond what’s shown here?
3. Aside from rotating the extension password (already planned), are there any additional logs or checks you’d recommend to confirm there was no successful authentication attempt elsewhere?

To be clear, the registration was blocked and no calls were placed, I just want to confirm whether deeper inspection is possible or expected.

Thanks in advance for any insight.

 

[Charles_3CX]

This is a registration of a phone to ext 206, but the message is cut off so one cannot see which or what firmware level. This, however, was a registration attempt from a remote device that is not being done via an SBC, but is intended to be done directly (local LAN) from the WAN.

 

[Kevin Attard Compagno]

3CX logs will not log credentials, for what should be obvious reasons. If you have some deep legal/forensic reasons to investigate this matter, there are tools one could use for this, but going deeper into that is out of scope for this channel.

 

[Alphabetic]

As Charles suggested, this can be typical (if legit) when you've set up a phone for "Connect directly" with the intent of using it as a router phone (But not at the required firmware level) or "local LAN" attempting to use it in STUN and the option to block non-tunnel connections is on.

 

[fxbastler]

Are there any logs (event log, activity log, SIP traces, etc.) that would show what password or hash was attempted during this REGISTER?

You get the hash and the required nonce via sip trace (or activity log in verbose mode) but no decrypted password. Look in RFC3261 about the procedere and algorithms:

The first anonymous register request is answered with a 407 proxy auth required error. A nonce and realm are included, along with instructions on how to encrypt the data (here: digest and MD5). Using this 3CX nonce, the realm and the requesting client's own credentials, the client constructs a hash and sends it to the 3CX with the second register request for authentication. The 3CX cannot decrypt the hash. The hash generation process uses a cryptographic one-way function. However, the 3CX can construct its own hash using its own data and compare it to the incoming hash. If they match the client is successfully authenticated. This is the way.

The login process, including how credentials and the nonce are combined, and the encryption method are all documented. The nonce, realm and hash can be seen in the SIP traces. The rest can only be broken by brute force. With MD5, this is at least conceivable - provided you have sufficient computing power (and we're talking here about a lot of ...) or a sufficiently large quantum computer. Rainbow tables won't get you anywhere.

So: no, no foreign password decrypt possible in our world.

Or does 3CX intentionally not log credential details beyond what’s shown here?

see above, 3CX has only it's own credentials and don't has to decrypt the incoming, the hashes should match

Aside from rotating the extension password (already planned), are there any additional logs or checks you’d recommend to confirm there was no successful authentication attempt elsewhere?

Counter-question: Why are the 3CX SIP ports accessible to everyone, including for such requests?
Only direct STUN and direct SIP authentication require this and both should no longer be used.

The recommendation is to make the SIP ports accessible only to the provider - if at all. All other access should be blocked in the firewall before the 3CX.

 

[tech3x]

Regarding the firewall, our 3CX instance was installed with the DigitalOcean Marketplace deployment as documented here (https://www.3cx.com/docs/pbx-digital-ocean-marketplace/). No additional modifications have been made to the DO VPS.