Author |
Message |
ajlindy Brekeke Talented
Joined: 12 Sep 2017 Posts: 53
|
Posted: Tue Apr 28, 2020 8:38 am Post subject: 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! |
|
Back to top |
|
snuyzm Brekeke Talented
Joined: 11 Feb 2015 Posts: 97
|
Posted: Tue Apr 28, 2020 10:07 am Post subject: |
|
|
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. |
|
Back to top |
|
ajlindy Brekeke Talented
Joined: 12 Sep 2017 Posts: 53
|
Posted: Tue Apr 28, 2020 10:52 am Post subject: |
|
|
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? |
|
Back to top |
|
snuyzm Brekeke Talented
Joined: 11 Feb 2015 Posts: 97
|
Posted: Tue Apr 28, 2020 3:59 pm Post subject: |
|
|
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 |
|
Back to top |
|
ajlindy Brekeke Talented
Joined: 12 Sep 2017 Posts: 53
|
Posted: Tue May 12, 2020 7:53 am Post subject: |
|
|
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? |
|
Back to top |
|
snuyzm Brekeke Talented
Joined: 11 Feb 2015 Posts: 97
|
Posted: Tue May 12, 2020 9:15 am Post subject: |
|
|
Have you set REGISTER and INVITE Authentication in [Configuration]->[SIP] page?? |
|
Back to top |
|
ajlindy Brekeke Talented
Joined: 12 Sep 2017 Posts: 53
|
Posted: Tue May 12, 2020 9:19 am Post subject: |
|
|
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. |
|
Back to top |
|
snuyzm Brekeke Talented
Joined: 11 Feb 2015 Posts: 97
|
Posted: Tue May 12, 2020 10:01 am Post subject: |
|
|
> 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. |
|
Back to top |
|
ajlindy Brekeke Talented
Joined: 12 Sep 2017 Posts: 53
|
Posted: Tue May 12, 2020 10:08 am Post subject: |
|
|
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. |
|
Back to top |
|
snuyzm Brekeke Talented
Joined: 11 Feb 2015 Posts: 97
|
Posted: Tue May 12, 2020 5:59 pm Post subject: |
|
|
> 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. |
|
Back to top |
|
ajlindy Brekeke Talented
Joined: 12 Sep 2017 Posts: 53
|
Posted: Fri Jul 24, 2020 12:44 pm Post subject: |
|
|
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. |
|
Back to top |
|
Niloc Brekeke Talented
Joined: 19 Sep 2017 Posts: 70
Location: NL
|
Posted: Fri Jul 24, 2020 10:40 pm Post subject: |
|
|
> 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. |
|
Back to top |
|
ajlindy Brekeke Talented
Joined: 12 Sep 2017 Posts: 53
|
Posted: Mon Jul 27, 2020 5:23 am Post subject: |
|
|
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 ? |
|
Back to top |
|
Niloc Brekeke Talented
Joined: 19 Sep 2017 Posts: 70
Location: NL
|
Posted: Mon Jul 27, 2020 9:18 am Post subject: |
|
|
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
|
|
|
Back to top |
|
ajlindy Brekeke Talented
Joined: 12 Sep 2017 Posts: 53
|
Posted: Tue Jul 28, 2020 9:57 am Post subject: |
|
|
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? |
|
Back to top |
|
Niloc Brekeke Talented
Joined: 19 Sep 2017 Posts: 70
Location: NL
|
Posted: Tue Jul 28, 2020 1:46 pm Post subject: |
|
|
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. |
|
Back to top |
|
ajlindy Brekeke Talented
Joined: 12 Sep 2017 Posts: 53
|
Posted: Wed Jul 29, 2020 12:29 pm Post subject: |
|
|
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. |
|
Back to top |
|
Niloc Brekeke Talented
Joined: 19 Sep 2017 Posts: 70
Location: NL
|
Posted: Wed Jul 29, 2020 1:07 pm Post subject: |
|
|
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
|
|
|
Back to top |
|
ajlindy Brekeke Talented
Joined: 12 Sep 2017 Posts: 53
|
Posted: Tue Aug 18, 2020 1:25 pm Post subject: |
|
|
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? |
|
Back to top |
|
Niloc Brekeke Talented
Joined: 19 Sep 2017 Posts: 70
Location: NL
|
Posted: Wed Aug 19, 2020 11:14 am Post subject: |
|
|
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(.+)@ |
|
Back to top |
|
ajlindy Brekeke Talented
Joined: 12 Sep 2017 Posts: 53
|
Posted: Wed Sep 02, 2020 5:07 am Post subject: |
|
|
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! |
|
Back to top |
|
Niloc Brekeke Talented
Joined: 19 Sep 2017 Posts: 70
Location: NL
|
Posted: Thu Sep 03, 2020 4:53 pm Post subject: |
|
|
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 Patterns | $accept = false
|
|
|
Back to top |
|
ajlindy Brekeke Talented
Joined: 12 Sep 2017 Posts: 53
|
Posted: Fri Sep 04, 2020 5:08 am Post subject: |
|
|
AWESOME, THANK YOU!!
If this doesn't work, by the way, I'm convinced literally nothing will. |
|
Back to top |
|
ajlindy Brekeke Talented
Joined: 12 Sep 2017 Posts: 53
|
Posted: Wed Sep 09, 2020 7:55 am Post subject: |
|
|
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? |
|
Back to top |
|
Niloc Brekeke Talented
Joined: 19 Sep 2017 Posts: 70
Location: NL
|
Posted: Wed Sep 09, 2020 8:08 pm Post subject: |
|
|
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? |
|
Back to top |
|
|