ALERT RTP stream security risk

[atsak]

http://seclists.org/fulldisclosure/2017/Aug/43

I wonder how hard this is to exploit?

 

[wardmundy]

Not very hard apparently...

https://www.theregister.co.uk/2017/09/03/asterisk_rtp_bug_allows_intercepted_calls/?mt=1504615175011

3CX is looking better and better.

 

[wardmundy]

We're seriously considering adding the RTP ports to the IPtables WhiteList methodology, i.e. only authorized IP addresses could access the RTP ports. This would eliminate the vulnerability regardless of your version of Asterisk.

Comments??

 

[billsimon]

I don't see why this bug even exists, and why Asterisk devs had to do this RTP hacking in the first place. What am I missing? If the SDP in the INVITE or subsequent re-INVITE contains routable IP addresses, then use them for media. If the SDP contains non-routable IP addresses, then the client is behind a NAT and not using any NAT traversal techniques like SIP ALG, ICE/STUN, so send to the originating IP. Why are we making allowances here for media to come from anywhere?

I think you can probably clamp down your firewall as much as you want, because symmetric RTP should allow media to get through by way of establishing an outbound stream (inbound stream comes back on the same path).

 

[jerrm]

I think you can probably clamp down your firewall as much as you want, because symmetric RTP should allow media to get through by way of establishing an outbound stream (inbound stream comes back on the same path).

I would tend to agree. I have to dig into this further, but have trouble seeing how this would impact my setups.

RTP ports are blocked by default in my rules. Packets from a random address never make it past iptables.

I have RTP ports allowed in my "endpoint" and "trunk" whitelist rule sets, but mostly just to cut down on the few dropped packets that are logged during call setup. I originally had an "rtp.media" ruleset, but found it unnecessary.

Direct media providers like Anveo Direct (majority of our calls) would be impossible to white list. A few packets are dropped at the beginning of call setup, but symmetric RTP ultimately opens up the path and the user is unaware.

If the IPBX rules open up RTP to everyone, that probably is not needed (at least in most situations - never say never).

 

[atsak]

It's rare but sometimes I've seen media proxies change IP mid stream. I don't even know how it was done because I can't figure out how it is possible (but I'm not really versed in that low level protocol behaviour), but the IP address of the RTP packets changed during a call (no packets lost either, which I figured at least there would be something, but there was a SIP reinvite message IIRC). Certainly media doesn't always come from the same IP as the SIP SBC of course, but

 

[wardmundy]

@billsimon and @jerrm: By gosh, you're right. I closed UDP 10000-20000 in IPtables and everything still works for incoming and outgoing calls. And now the bad guys don't have a port to play with. I suppose this patch was for folks that either don't have a firewall or that pass UDP 10000-20000 thru their NAT-based router to the Asterisk server. Just another case of "we've always done it that way."

 

[wardmundy]

Here's the patch procedure... (1) install it and then (2) don't forget to: iptables-restart

REPORT ANY PROBLEMS AND WE CAN DEAL WITH THE OUTLYING ISSUES!

For Incredible PBX for Issabel:

sed -i 's|/usr/sbin/iptables -A INPUT -p udp -m multiport --dports 10000:20000 -j ACCEPT|\#/usr/sbin/iptables -A INPUT -p udp -m multiport --dports 10000:20000 -j ACCEPT|' /usr/local/sbin/iptables-custom

For Incredible PBX for Wazo and Incredible PBX 13 for Ubuntu 14:

sed -i 's|-A INPUT -p udp -m multiport --dports 10000:20000 -j ACCEPT|\#-A INPUT -p udp -m multiport --dports 10000:20000 -j ACCEPT|' /etc/iptables/rules.v4
sed -i 's|-A INPUT -p udp -m multiport --dports 10000:20000 -j ACCEPT|\#-A INPUT -p udp -m multiport --dports 10000:20000 -j ACCEPT|' /etc/iptables/rules.v4.ubuntu14

For Incredible PBX 13 for CentOS:

sed -i 's|-A INPUT -p udp -m multiport --dports 10000:20000 -j ACCEPT|\#-A INPUT -p udp -m multiport --dports 10000:20000 -j ACCEPT|' /etc/sysconfig/iptables
sed -i 's|-A INPUT -p udp -m multiport --dports 10000:20000 -j ACCEPT|\#-A INPUT -p udp -m multiport --dports 10000:20000 -j ACCEPT|' /etc/sysconfig/rules.v4.ubuntu14

For Incredible PBX for Raspbian:

sed -i 's|-A INPUT -p udp -m udp --dport 10000:20000 -j ACCEPT|\#-A INPUT -p udp -m udp --dport 10000:20000 -j ACCEPT|' /etc/iptables/rules.v4
sed -i 's|-A INPUT -p udp -m udp --dport 10000:20000 -j ACCEPT|\#-A INPUT -p udp -m udp --dport 10000:20000 -j ACCEPT|' /etc/iptables/rules.v4.ubuntu14

 

[Sylvain Boily]

Asterisk 14.6.1 with security fix will be in the next wazo version. Release 17.13 is for the 18/09/2017.

 

[wardmundy]

The problem is that the "security fix" itself has a problem:

Note that as for the time of writing, the official Asterisk fix is vulnerable to a race condition. An attacker may continuously spray an Asterisk server with RTP packets. This allows the attacker to send RTP within those first few packets and still exploit this vulnerability.

As documented above, the only reliable fix is to remove UDP 10000-20000 access in your firewall.

 

[KUMARULLAL]

@wardmundy
I tried doing that on iptables on centos running travelinman. I get oneway audio. Others can hear me, I cannot hear outsiders.I have selected NAT=no and gsm and ulaw codes. the server is on cloud with public IP.
What Am I doing wrong.

 

[dhoppy]

@wardmundy
II tried doing that on iptables on centos running travelinman. I get oneway audio. Others can hear me, I cannot hear outsiders.I have selected NAT=no and gsm and ulaw codes. the server is on cloud with public IP.
What Am I doing wrong.

Also having a problem on a centos system. Audio is fine on inbound calls, no audio on outbound calls. Also, no audio on calls between extensions.

The iptables fix on the ubuntu systems I have work fine.

 

[billsimon]

It could be a problem if both endpoints are outside the firewall and Asterisk is inside. Then who pokes the holes through the firewall for media? Both endpoints are blocked until Asterisk generates or relays some media. If Asterisk generates early media like ringback tones then problem solved. Otherwise, I don't know. @dhoppy , @KUMARULLAL , perhaps do some tcpdump or wireshark on your servers and see what's going on.

 

[anthony rubio]

should i worry of this on the 3cx system?

 

[pbxinaflash]

should i worry of this on the 3cx system?

3CX is not Asterisk based so it's not affected.

 

[wardmundy]

@wardmundy
I tried doing that on iptables on centos running travelinman. I get oneway audio. Others can hear me, I cannot hear outsiders.I have selected NAT=no and gsm and ulaw codes. the server is on cloud with public IP.
What Am I doing wrong.

Have you tried it with nat=yes and leaving 10000-20000 blocked? I know it sounds crazy on a cloud server, but we've never had much luck with any calls with nat=no regardless of the location of the server.

 

[KUMARULLAL]

Yes, tried nat=yes with no luck

 

[wardmundy]

Then you probably need to load one of the patches or update to the latest version of Asterisk.

 

[hawk#1]

@wardmundy
do you plan on including the change in your snapshots for new installs, or will we need to remember to change Travelin’ Man on clean installs?

 

[wardmundy]

@wardmundy
do you plan on including the change in your snapshots for new installs, or will we need to remember to change Travelin’ Man on clean installs?

Already modified in the new installs. Also just finished a refresh on Incredible PBX 13 for CentOS 6.x that includes latest Asterisk 13.17.1 fix.