Summary:	ASTERISK-27818: Username bruteforce is possible when using ACL with PJSIP
Reporter:	John (errentazaria)	Labels:	patch pjsip security
Date Opened:	2018-04-19 18:31:58	Date Closed:	2018-06-11 14:30:26
Priority:	Blocker	Regression?
Status:	Closed/Complete	Components:	Resources/res_pjsip
Versions:	13.19.2	Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) AST-2018-008.pdf ( 1) jira_asterisk_27818_v13.patch
Description:	When ACL rules block registration they respond with a 403 Forbidden when the username matches and with 401 Unauthorized when the username does not match. This essentially allows someone to constantly test usernames and see which ones are valid and which ones are not. I've only encountered this problem on my setup working with Realtime. Not sure what else is effected.
Comments:	By: Asterisk Team (asteriskteam) 2018-04-19 18:31:59.313-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Asterisk Team (asteriskteam) 2018-04-19 18:32:00.365-0500 This issue has been automatically restricted and set to a blocker due to being a security type issue. If this is not a security vulnerability issue it will be moved to the appropriate issue type when triaged. By: Kevin Harwell (kharwell) 2018-04-20 11:55:46.682-0500 ACL does indeed respond with a 403 if the endpoint falls within its deny range. It responds that way every time for me no matter what other authorization settings I have on the endpoint in question. However, if I allow the endpoint through (in the ACL's allow range)  and it fails to authorize, either because of a mismatch in username or password Asterisk responds with a 401. Is that the type of scenario you are referring to? If not then what's your endpoint, auth, and ACL configuration like for each case? Also please post a debug log with protocol specific debug captured at the time of the issue. Please see the following for more information on how to do that: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information Thanks! By: John (errentazaria) 2018-04-20 12:05:49.117-0500 No, let me clarify. You have an ACL rule that only allows a set of IPs (blocks everything else). Let's say 1.2.3.4 is NOT whitelisted and therefore BLOCKED. Say you have extensions '201,202,203' on your Asterisk and all 3 extensions are configured with that ACL rule. UA from 1.2.3.4 tries to register using '205' as the username. Response from server: 401 Unauthorized UA from 1.2.3.4 tries to register using '204' as the username. Response from server: 401 Unauthorized UA from 1.2.3.4 tries to register using '203' as the username. Response from server: 403 Forbidden UA from 1.2.3.4 tries to register using '202' as the username. Response from server: 403 Forbidden UA from 1.2.3.4 tries to register using '201' as the username. Response from server: 403 Forbidden UA from 1.2.3.4 tries to register using '200' as the username. Response from server: 401 Unauthorized So the UA that is blocked is able to test usernames and see which ones are available on the system. By: John (errentazaria) 2018-04-20 12:12:17.315-0500 I propose that when blocking with ACL the response send back should be 401 Unauthorized instead of the 403 Forbidden. By: Kevin Harwell (kharwell) 2018-04-20 13:15:58.542-0500 Okay that makes it more clear. However, I am still unable to duplicate the problem. I always get a 403. How are you configuring your ACL? Using the pjsip type=acl, setting it on an endpoint directly, or using _acl.conf_ and setting a named type? By: John (errentazaria) 2018-04-20 13:20:37.976-0500 I have the following in acl.conf [orange] deny=0.0.0.0/0.0.0.0 permit=5.5.5.5 Then under ps_endpoints in realtime I have acl=orange for all my endpoints. By: John (errentazaria) 2018-04-20 13:25:54.389-0500 Try it this way and for the UA make sure the username you are using doesn't exist and you will get a 401 response. By: Kevin Harwell (kharwell) 2018-04-20 13:29:20.338-0500 Okay yup that was it. I was not using named ACLs, but using res_pjsip configuration type=acl. It also appears to do the same thing when setting the 'deny=<some address>' endpoint option as well. By: John (errentazaria) 2018-04-20 13:48:43.630-0500 Okay so it looks like the only "fix" is to move the config to pjsip.conf with type=acl. But then you lose the ability to setup ACL rules on a per endpoint basis. I don't think there will ever really be a fix to this unless ACL blocking is changed to to respond with a 401 instead of a 403. By: Richard Mudgett (rmudgett) 2018-05-02 10:53:20.967-0500 [^jira_asterisk_27818_v13.patch] - This patch sends 401 Unauthenticated instead of 403 Forbidden when an endpoint specific ACL rule blocks access.  Global ACL rules still send 403 Forbidden because everything is blocked by that rule. [^AST-2018-008.pdf] is the security advisory. Please test the patch and look at the advisory. Thank you By: Friendly Automation (friendly-automation) 2018-06-11 14:30:27.522-0500 Change 9151 merged by Jenkins2: AST-2018-008: Fix enumeration of endpoints from ACL rejected addresses. [https://gerrit.asterisk.org/9151|https://gerrit.asterisk.org/9151] By: Friendly Automation (friendly-automation) 2018-06-11 14:34:53.981-0500 Change 9170 merged by Kevin Harwell: AST-2018-008: Fix enumeration of endpoints from ACL rejected addresses. [https://gerrit.asterisk.org/9170|https://gerrit.asterisk.org/9170] By: Friendly Automation (friendly-automation) 2018-06-11 14:35:02.881-0500 Change 9153 merged by Kevin Harwell: AST-2018-008: Fix enumeration of endpoints from ACL rejected addresses. [https://gerrit.asterisk.org/9153|https://gerrit.asterisk.org/9153] By: Friendly Automation (friendly-automation) 2018-06-11 14:35:11.377-0500 Change 9160 merged by Kevin Harwell: AST-2018-008: Fix enumeration of endpoints from ACL rejected addresses. [https://gerrit.asterisk.org/9160|https://gerrit.asterisk.org/9160] By: Friendly Automation (friendly-automation) 2018-06-11 14:35:19.808-0500 Change 9159 merged by Kevin Harwell: AST-2018-008: Fix enumeration of endpoints from ACL rejected addresses. [https://gerrit.asterisk.org/9159|https://gerrit.asterisk.org/9159] By: Friendly Automation (friendly-automation) 2018-06-11 14:35:27.567-0500 Change 9158 merged by Kevin Harwell: AST-2018-008: Fix enumeration of endpoints from ACL rejected addresses. [https://gerrit.asterisk.org/9158|https://gerrit.asterisk.org/9158] By: Friendly Automation (friendly-automation) 2018-06-11 14:35:34.920-0500 Change 9157 merged by Kevin Harwell: AST-2018-008: Fix enumeration of endpoints from ACL rejected addresses. [https://gerrit.asterisk.org/9157|https://gerrit.asterisk.org/9157] By: Friendly Automation (friendly-automation) 2018-06-11 14:35:44.001-0500 Change 9156 merged by Kevin Harwell: AST-2018-008: Fix enumeration of endpoints from ACL rejected addresses. [https://gerrit.asterisk.org/9156|https://gerrit.asterisk.org/9156] By: Friendly Automation (friendly-automation) 2018-06-11 14:35:52.511-0500 Change 9154 merged by Kevin Harwell: AST-2018-008: Fix enumeration of endpoints from ACL rejected addresses. [https://gerrit.asterisk.org/9154|https://gerrit.asterisk.org/9154] By: Friendly Automation (friendly-automation) 2018-06-11 15:54:26.401-0500 Change 9173 merged by Kevin Harwell: AST-2018-008: Fix enumeration of endpoints from ACL rejected addresses. [https://gerrit.asterisk.org/9173|https://gerrit.asterisk.org/9173] By: Friendly Automation (friendly-automation) 2018-06-11 16:20:41.199-0500 Change 9172 merged by Kevin Harwell: AST-2018-008: Fix enumeration of endpoints from ACL rejected addresses. [https://gerrit.asterisk.org/9172|https://gerrit.asterisk.org/9172]