A security scanner tripped on Brekeke

ajlindy · Post by **ajlindy** » Tue Apr 28, 2020 8:38 am

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!

snuyzm · Post by **snuyzm** » Tue Apr 28, 2020 10:07 am

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.

ajlindy · Post by **ajlindy** » Tue Apr 28, 2020 10:52 am

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?

snuyzm · Post by **snuyzm** » Tue Apr 28, 2020 3:59 pm

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

ajlindy · Post by **ajlindy** » Tue May 12, 2020 7:53 am

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?

snuyzm · Post by **snuyzm** » Tue May 12, 2020 9:15 am

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

ajlindy · Post by **ajlindy** » Tue May 12, 2020 9:19 am

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.

snuyzm · Post by **snuyzm** » Tue May 12, 2020 10:01 am

> 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.

ajlindy · Post by **ajlindy** » Tue May 12, 2020 10:08 am

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.

snuyzm · Post by **snuyzm** » Tue May 12, 2020 5:59 pm

> 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.

ajlindy · Post by **ajlindy** » Fri Jul 24, 2020 12:44 pm

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.

Niloc · Post by **Niloc** » Fri Jul 24, 2020 10:40 pm

> 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.

ajlindy · Post by **ajlindy** » Mon Jul 27, 2020 5:23 am

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 ?

Niloc · Post by **Niloc** » Mon Jul 27, 2020 9:18 am

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

ajlindy · Post by **ajlindy** » Tue Jul 28, 2020 9:57 am

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?

Niloc · Post by **Niloc** » Tue Jul 28, 2020 1:46 pm

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.

ajlindy · Post by **ajlindy** » Wed Jul 29, 2020 12:29 pm

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.

Niloc · Post by **Niloc** » Wed Jul 29, 2020 1:07 pm

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

ajlindy · Post by **ajlindy** » Tue Aug 18, 2020 1:25 pm

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?

Niloc · Post by **Niloc** » Wed Aug 19, 2020 11:14 am

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(.+)@

ajlindy · Post by **ajlindy** » Wed Sep 02, 2020 5:07 am

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!

Niloc · Post by **Niloc** » Thu Sep 03, 2020 4:53 pm

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

ajlindy · Post by **ajlindy** » Fri Sep 04, 2020 5:08 am

AWESOME, THANK YOU!!

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

ajlindy · Post by **ajlindy** » Wed Sep 09, 2020 7:55 am

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?

Niloc · Post by **Niloc** » Wed Sep 09, 2020 8:08 pm

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?