A security scanner tripped on Brekeke

1. Brekeke Product Name and Version: 3.9.4.3/517-1

2. Java version: 1.8.0_231

3. OS type and the version: Windows 2012 R2 64-bit

4. UA (phone), gateway or other hardware/software involved: None

5. Your problem:

We had a security scan trip on something for Brekeke SIP Proxy.
The Qualys Scanner reports that - SIP Users Information Disclosure

38435 - SIP Users Information Disclosure

Solution:

Enable proxy authorization at the SIP proxy server, enable authentication at the SIP register server, and configure the SIP client to not respond if it receives the INVITE message from a different URL.

SI-02 Flaw Remediation (NIST SP 800-53 Rev. 3)
(Definition of actual problem)
An attacker can gather information about existing users. When a user sends an INVITE message to the SIP server, it usually verifies whether the client exists and sends back a response. If the server is a proxy server and does not have any sort of session management or authentication enabled, an attacker can send an INVITE request and determine whether the user exists based on the response.


So for the SIP configuration page I have some settings that I think they want us to change. I just don't know what to change.

SIP Exchanger
Session Limit: -1
Local Port: 5060
B2B-UA mode: Off << I think they want this turned on
Check Maximum UDP packet size: Off
Meximum UDP packet size: 1500

Authentication settings as follows:

Register: On
Invite: Off
Message: Off
Subscribe: off

Realm: Blank
Auth-user=user in "To." (Register): Yes
Auth-user=user in "From.": Yes


has anybody else dealt with this before?
Thank you!

To enable both proxy and register authorizations, set the following settings at [Configuration]->[SIP] page -> [Authentication].

REGISTER = on
INVITE = on

They are On in the default but it seems you set "Off" for INVITE.
The B2B-UA mode is not related .

Anyway let you change INVITE Authentication to "On".

Note that SIP caller clients must support INVITE Authentication.
If they don't, configure SIP Server's DialPlan to disable INVITE Authentication to them exclusively.

Thank you!
I'm assuming much in the way I don't have B2B-UA turned on system-wide but in the rules I have $b2bua=true defined, there is a way to define $INVITE=false or something of that nature in the same rules?

Yes. It is the variable $auth.
so let you set $auth=false in the DeployPattern of the rule.
If so, the SIP Server doesn't require an INVITE to send an authentication.

FYI:
https://docs.brekeke.com/sip/auth

So we made our changes as suggested and the Qualys Scanner still came back with the same issue. I'm unsure how to continue at this point.

Has anybody ever dealt with Qualys before?

Have you set REGISTER and INVITE Authentication in [Configuration]->[SIP] page??

snuyzm wrote:Have you set REGISTER and INVITE Authentication in [Configuration]->[SIP] page??

Yep!
Both Register and Invite are Yes with each individual rule having $auth=false in the deploy pattern.

> each individual rule having $auth=false in the deploy pattern.

It is the issue... you should not put $auth=false in the DialPlan rule which matches the Qualys's INVITE.

or... add another new DialPlan rule which matches only an INVITE sent from the Qualys.

You can check the remote IP address or User-Agent header to distinguish Qualys's INVITE from others.

With $auth=false, the SIP Server doesn't require authentication at matched INVITE. so $auth=false should be used for INVITE sent from SIP entities other than Qualys.

snuyzm wrote:> each individual rule having $auth=false in the deploy pattern.

It is the issue... you should not put $auth=false in the DialPlan rule which matches the Qualys's INVITE.

or... add another new DialPlan rule which matches only an INVITE sent from the Qualys.

You can check the remote IP address or User-Agent header to distinguish Qualys's INVITE from others.

With $auth=false, the SIP Server doesn't require authentication at matched INVITE. so $auth=false should be used for INVITE sent from SIP entities other than Qualys.

OK, so please don't misunderstand this but what I heard was "if Qualys's scan is a problem, bypass Qualys's scan."

In other words, the point is to shore up what they believe is a critical issue but we're just faking out the scanner pointing out the issue.

Would it be safer to say perhaps that if an invite comes from a trusted source (for instance, our actual dialer or their actual PBX) then we do $auth=false but everything else that doesn't match those two IP addresses doesn't have that rule?

That way we basically get to the heart of the matter -- if you're not one of two trusted sources, you're going to bomb out.

> but what I heard was "if Qualys's scan is a problem, bypass Qualys's scan."

Right. If all of SIP clients which access to your SIP Server support INVITE/REGISTER authentication, simply remove $auth=false from all DialPlan rules.


> Would it be safer to say perhaps that if an invite comes from a trusted source (for instance, our actual dialer or their actual PBX) then we do $auth=false but everything else that doesn't match those two IP addresses doesn't have that rule?

Yes. You can check the source IP address with $addr or $addrrange variable in Matching Pattern.
https://docs.brekeke.com/sip/addr
https://docs.brekeke.com/sip/addrrange

so... let you write a DialPlan rule like.. if $addr indicates a trusted IP address, disable the authentication with $auth=false.

I'm sorry to come back to this one, but we did exactly what you described. Anything coming from two specific IP addresses do not require authorization.

However, I wonder one thing -- is it possible that if we do not have a rule in place to deal with invites or traffic from OTHER IP addresses at all, that Brekeke would still technically allow for a kind of "$auth = false" action?

Their scanner still trips on this and said that the ^INVITE it sent didn't require authorization.

> that Brekeke would still technically allow for a kind of "$auth = false" action?

It depends on Authentication settings in [Configuration]->[SIP] page.


> Their scanner still trips on this and said that the ^INVITE it sent didn't require authorization.

Do you want to enable Authorization to an INVITE sent from the scanner?
Generally, set the $addr with the scanner's IP address and
put $auth=true in DeployPatterns.

If these IP addresses are unknown, find a way to detect such an INVITE for example User-Agent header.

I found something out pretty important:

The IP 10.22.38.223 is the scanner IP.
But 10.23.38.17 is the IP of the Brekeke Server which also happens to be one of our dialing chassis where SIP Invites come from.


Below is the handshake that the sweeper is doing.

SIP/2.0 100 Trying
Via: SIP/2.0/udp 10.22.38.223:5060;branch=z9hG4bKnashds7;rport=5060
From: Test<sip:test@10.23.38.17>;tag=a73kszlfl
To: Test<sip:test@10.23.38.17>;tag=a73kszlfl
Call-ID: jkSqk5RiXO8lb5Om@10.22.38.223
CSeq: 26925 INVITE
Server: Brekeke SIP Server rev.466
Content-Length: 0

The dial plan rules we have in place all have to do with the 10.23.38.17 address, so am I right in thinking the scanner (at a different IP) is just spoofing the From field and therefore will ALWAYS be sent to a rule where $auth = false ?

Who is using 10.23.38.17? a network gateway? or another SIP proxy?

If 10.22.38.223 is the scanner's IP address, you might catch a SIP packet by monitoring Via header because it indicates the same IP address.

For example
[Matching Patterns]
$request = ^INVITE
Via = ^10.22.38.223

[Deploy Patterns]
$auth = true
$continue = true

So that worked like a charm!
We blocked the scanner from tripping. Which is dandy but what we really want to do is ensure that ONLY two specific IPs will not need authorization and EVERYTHING else will.

So while your rule did block the scanner, I'm hoping something like this would block EVERYTHING.


[Matching Patterns]
$request = ^INVITE
To = $sip:1(.+)@
$addr = Wanted IP 1| Wanted IP 2
Via = ^Wanted IP1 | Wanted IP 2

So basically if you do not match the IP address in both the $addr and the Via, you're going to skip the rules that let $auth = false

In fact, if you do not match the $addr and Via, and you skip this rule, I'd like to have no other rules so Brekeke won't even acknowledge it.

Am I on the right track?

If all SIP packets are always forwarded from 10.23.38.17, $addr condition doesn't work (as you experienced when you tried to pick an INVITE sent from the scanner 10.22.38.223)

so if you want to catch an INVITE sent from <Wanted IP>, checking Via header might be enough and you don't need $addr.

It turns out the client was looking at the wrong scan.
The rule that included Via = ^IPtoBlock did not work.

So back to the drawing board.

If you are sure that the SIP entity running on the specific IP can reach to the SIP Server directly, you can catch an INVITE sent from the SIP entity with $addr condition. In that case, you don't have to have Via condition together.

[Matching Patterns]
$request = ^INVITE
To = $sip:1(.+)@
$addr = Wanted IP 1| Wanted IP 2

OK, so I have been through it with our client and I just want to be absolutely 100000% sure of what I tell you and what has not worked.

This is the actual invite (as much as was given to me) that is still tripping the security violation:

SIP/2.0 100 Trying
Via: SIP/2.0/udp 10.22.38.223:5060;branch=z9hG4bKnashds7;rport=5060
From: Test<sip:test@10.23.38.17>;tag=a73kszlfl
To: Test<sip:test@10.23.38.17>;tag=a73kszlfl
Call-ID: jkSqk5RiXO8lb5Om@10.22.38.223
CSeq: 26925 INVITE
Server: Brekeke SIP Server rev.466
Content-Length: 0

The IP address 10.23.38.17 is a trust IP address, in terms of this is exactly the piece of equipment that should be sending invites.

10.22.38.223 is the scanner server. It's the one I want to block.

I can tell you that I have already tried

[Matching Patterns]
$request = ^INVITE
To = $sip:1(.+)@
$addr = Wanted IP 1| Wanted IP 2

EXCEPT -- mine was To = sip:1(.+)@

You have $sip -- does that matter?

oh... It is a syntax error. You should not put '$' there because '$' means the end of line.

To = $sip:1(.+)@
it should be
To = sip:1(.+)@

So you all will love this.

In Configuration, under SIP, I enabled REGISTER, INVITE, and then all the "auth" stuff I could find. All of it was turned on.

I then REMOVED all the "$auth = false" stuff on each of my individual dial plan rules.

The scanner STILL tripped a positive on the vulnerability PLUS all my inbound and about calls quit working (Because our system can't do Auth stuff).

So here's my last question on the matter and if this doesn't work I think we have to call this a false positive and try to explain we've literally done everything we know to do in order to stop this vulnerability from trigger.

When this test happens, it is From: Test<sip:test@10.23.38.17>

Can I set a specific rule that says if it's from test@10.23.38.17 to completely ignore the invite?

How do I completely ignore invites?

Thank you!

Do you want to ignore an INVITE if its From header indicates sip:test@10.23.38.17?

Put the rule below in [Dial Plan] -> [Preliminary].
Matching Patterns
$request = ^INVITE
From = sip:test@10.23.38.17

Deploy Pattern
$accept = false

AWESOME, THANK YOU!!

If this doesn't work, by the way, I'm convinced literally nothing will.

OK, so I put this rule first and the Qualsys Scanner still found the same vulnerability.

So at this point we are ready to call this a False Positive.

Is there anything Brekeke can provide to show that despite all our attempts it still doesn't block / stop the Invite?

Are you sure the DialPlan rule which filters sip:test@10.23.38.17 was executed?
If there are any other DialPlan rules above the rule, your plan will not be accomplished.
Check the DialPlan History to confirm the rule was executed.

Also are you sure that Qualsys Scanner's INVITE reached the SIP Server directly?
Are there any other SIP entities such as a SBC located between the Scanner and the SIP Server?

Hello!
Sorry to take so long to get back this.
I wanted to let you know we did a WireShark capture where our live filter was to check for ip.addr == 10.22.38.223

So the whole thing captures a lot more but we could see exactly when (or if) the scanning server hit our contact platform where Brekeke SIP Proxy is at.

It definitely hits the server and the scanner knows Brekeke is there because the vulnerability shows that is where the problem is.

We definitely have the right rule listed first and yet we have no logs anywhere from Brekeke that show the IP 10.22.38.223 hit it. Or that sip:test@10.23.38.17 hit it.

I don't know where to go from here. I know they are not on the absolute latest version of Brekeke but we're really close (3.9.4.3 vs 3.9.5..

I'm sorry to give a stream of thought here, but I just looked and I do see this:

^REGISTER (from scanner)
401 Unauthorized (from our server)
^OPTIONS (scanner)
404 Not Found (us)
^INVITE (scanner)
100 Trying (us)
481 Call Leg/Transaction Does Not Exist (us)


So we're still in the boat where nothing is logged (no rule trip, no error) but....this looks like it's answering the ^INVITE with something.

Thoughts?

If you want to block REGISTER and OPTIONS too, remove "$request = ^INVITE" from the DialPlan rule for blocking the scanner.

Matching Patterns
$addr = 10.22.38.223

Deploy Patterns
$accept = false

Note the above rule should be in [Dial Plan] -> [Preliminary].

Good day!
putting that rule in the Preliminary Dial Plan rule worked like a charm!

We blocked the scanner, finally!

Now I have a different angle on this same thing.

We noticed that there is a Filtering Policy tab in the same general vicinity of "Blocked IP Address"

In the Filtering Policy is the ability to Block / Allow the IP address as an Exact Match / Regular Expression / IP Address Range.

If we were to tell Brekeke to ALLOW address from two or three specific IP addresses, would it by default BLOCK everything else?

If not, would I set Policy 1 (priority 1) to allow the first IP, Policy 2 (priority 2) to allow the second IP and then Policy 3 (priority 3) to Block some IP range that is EVERYTHING else?

Thank you!

> If we were to tell Brekeke to ALLOW address from two or three specific IP addresses, would it by default BLOCK everything else?

No. An IP address marked "Allow" should not be blocked even if the BlockList detects malicious activities from the IP address.

If an IP address is marked "Block", the BlockList always blocks packets sent from the IP address.

For other IP addresses which are not listed in Filtering Policy, the BlockList accepts their packets but blocks automatically if a malicious activity is detected.