[asterisk-bugs] [JIRA] (ASTERISK-29476) res_stir_shaken: Blind SSRF vulnerabilities

Friendly Automation (JIRA) noreply at issues.asterisk.org
Thu Apr 14 15:32:57 CDT 2022


    [ https://issues.asterisk.org/jira/browse/ASTERISK-29476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=258775#comment-258775 ] 

Friendly Automation commented on ASTERISK-29476:
------------------------------------------------

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]

> res_stir_shaken: Blind SSRF vulnerabilities
> -------------------------------------------
>
>                 Key: ASTERISK-29476
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29476
>             Project: Asterisk
>          Issue Type: Security
>          Components: Resources/res_stir_shaken
>    Affects Versions: 18.4.0
>            Reporter: Clint Ruoho
>            Assignee: Benjamin Keith Ford
>            Severity: Blocker
>              Labels: security
>      Target Release: 16.25.2, 18.11.2, 19.3.2
>
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)



More information about the asterisk-bugs mailing list