Summary:	ASTERISK-29476: res_stir_shaken: Blind SSRF vulnerabilities
Reporter:	Clint Ruoho (ruoho)	Labels:	security
Date Opened:	2021-06-10 15:47:31	Date Closed:	2022-04-14 14:31:44
Priority:	Blocker	Regression?
Status:	Closed/Complete	Components:	Resources/res_stir_shaken
Versions:	18.4.0	Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	If a PJSIP endpoint is configured with stir_shaken = yes, then the Asterisk server will retrieve the content of the URL provided in the info parameter in the Identity header from INVITEs. Consider a scenario where the victim is also running an AMI interface over HTTP only on localhost, and receives the following Identity header in an INVITE: Identity: eyJhbGciOiJFUzI1NiIsInBwdCI6InNoYWtlbiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cDovL3Rlc3RpbmcxMjMifQ==.eyJvcmlnIjp7InRuIjoiMTIzNDU2NyJ9LCJhdHRlc3QiOiJCIiwib3JpZ2lkIjoiYXN0ZXJpc2siLCJpYXQiOjE1OTA1ODgzODV9.MEUCIQCmINlklk+fCxEEjgbbwE5X7DAEy19aPRfLvypXrKUwpwIgaDtEzKZoGRa/Omof9iC6tPQPzsKazN1hygDWOc9uWXQ=;info=<http://127.0.0.1/some_unauthenticated_localhost_enpoint?action=evil>alg=ES256;ppt=shaken In this scenario, an external attacker can force the Asterisk server to send arbitrary GET requests to the AMI, even though the AMI is only bound on the localhost interface of the Asterisk server and would be otherwise inaccessible. An attacker could also send arbitrary HTTP GET requests through the Asterisk server to other localhost and LAN resources. More elaborate non-HTTP requests can be sent through other protocols supported by libcurl (Gopher is particularly extensible here). From my very limited testing, this appears to be a blind attack from a network perspective. An AMI running on Asterisk probably is not the only type of service of interest to an attacker (consider an internal Jenkins server, embedded network device that accepts unauthenticated requests, etc). The impact of this issue is dependent on specific deployment environments. Also res_stir_shaken also parses non-{http, https} URLs in the info parameter such as file, scp and gopher. These could allow for more interesting attack scenarios. Consider strict {http, https} protocol enforcement of the info URL. I would suggest implementation of customer-defined IP whitelists or blacklists of the resolved address with reasonable defaults.
Comments:	By: Asterisk Team (asteriskteam) 2021-06-10 15:47:41.247-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. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed. 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]. Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur. Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/]. By: Asterisk Team (asteriskteam) 2021-06-10 15:47:41.649-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. Please DO NOT put a code review up for this change at this time. Attach any applicable patches to this issue. By: George Joseph (gjoseph) 2021-06-10 17:39:50.495-0500 We've already plugged the hole where arbitrary schemes can be sent in the public_cert_url.  We only accept the request if the url starts with "http".   Also, the caller has to be authenticated at the SIP level before we even reach the point where we're looking at the identity header.   The problem with a whitelist mechanism might be that the public cert url in an incoming Identity header _could_ belong to a provider that we didn't know about _behind_ the immediate peer.  It would be hard to whitelist those.   A blacklist of known addresses or networks might work but that'd require us to do a DNS lookup on every incoming hostname and we can't do those synchronously.  That'd make the process very complex and slow down call processing. Your concerns are legitimate though so let us talk it over internally and with our industry counterparts and see what we can do to mitigate the attack surface. Thanks! By: George Joseph (gjoseph) 2021-06-11 08:37:07.179-0500 [~bford] Do you want to chime in? By: Benjamin Keith Ford (bford) 2021-06-11 09:48:21.205-0500 100% agree with George here. The attack vector is valid, though how to handle that is going to be a little more complicated. I don't think whitelisting or blacklisting is the correct approach, since that's sort of what STIR/SHAKEN is doing for you already, in a way. Eventually there will be a CA that will tell you which places are trusted sources for fetching the public certificate, and that in theory should resolve this problem entirely. It's just not implemented yet, as there were no details on it at the time of writing the STIR/SHAKEN module for Asterisk. But we'll need to discuss is further to find a good solution. By: Joshua C. Colp (jcolp) 2021-06-11 09:50:35.947-0500 The CA won't help with this specific case because regardless, you do the HTTP request to get the public certificate. That is the problem, not whether the entity is trusted or whether the certificate is trusted. By: Friendly Automation (friendly-automation) 2022-04-14 14:31:45.634-0500 Change 18394 merged by Michael Bradeen: AST-2022-002 - res_stir_shaken/curl: Add ACL checks for Identity header. [https://gerrit.asterisk.org/c/asterisk/+/18394|https://gerrit.asterisk.org/c/asterisk/+/18394] By: Friendly Automation (friendly-automation) 2022-04-14 15:21:44.992-0500 Change 18395 merged by Michael Bradeen: AST-2022-002 - res_stir_shaken/curl: Add ACL checks for Identity header. [https://gerrit.asterisk.org/c/asterisk/+/18395|https://gerrit.asterisk.org/c/asterisk/+/18395] By: Friendly Automation (friendly-automation) 2022-04-14 15:31:17.989-0500 Change 18396 merged by Michael Bradeen: AST-2022-002 - res_stir_shaken/curl: Add ACL checks for Identity header. [https://gerrit.asterisk.org/c/asterisk/+/18396|https://gerrit.asterisk.org/c/asterisk/+/18396] By: Friendly Automation (friendly-automation) 2022-04-14 16:58:59.742-0500 Change 18403 merged by Joshua Colp: AST-2022-002 - res_stir_shaken/curl: Add ACL checks for Identity header. [https://gerrit.asterisk.org/c/asterisk/+/18403|https://gerrit.asterisk.org/c/asterisk/+/18403] By: Friendly Automation (friendly-automation) 2022-04-14 16:59:10.356-0500 Change 18404 merged by Joshua Colp: AST-2022-002 - res_stir_shaken/curl: Add ACL checks for Identity header. [https://gerrit.asterisk.org/c/asterisk/+/18404|https://gerrit.asterisk.org/c/asterisk/+/18404] By: Friendly Automation (friendly-automation) 2022-04-14 16:59:20.052-0500 Change 18405 merged by Joshua Colp: AST-2022-002 - res_stir_shaken/curl: Add ACL checks for Identity header. [https://gerrit.asterisk.org/c/asterisk/+/18405|https://gerrit.asterisk.org/c/asterisk/+/18405] By: Friendly Automation (friendly-automation) 2022-04-14 16:59:29.044-0500 Change 18406 merged by Joshua Colp: AST-2022-002 - res_stir_shaken/curl: Add ACL checks for Identity header. [https://gerrit.asterisk.org/c/asterisk/+/18406|https://gerrit.asterisk.org/c/asterisk/+/18406] By: Friendly Automation (friendly-automation) 2022-04-15 15:01:40.801-0500 Change 18407 merged by Joshua Colp: AST-2022-002 - res_stir_shaken/curl: Add ACL checks for Identity header. [https://gerrit.asterisk.org/c/asterisk/+/18407|https://gerrit.asterisk.org/c/asterisk/+/18407]