I find the information on that site to be confusing because they lump multiple 
distinct problems under the same name as if they are a single issue. They also 
have some mistakes in their assertions.

So rather than address it from the point of view expressed on the site, let me 
explain what the possible problems are.

Mediaproxy 2 doesn't suffer from eavesdropping issues itself, because it learns 
the addresses of the participants and it will only forward traffic between 
those addresses, not to any listening 3rd party. However eavesdropping is a 
general issue for unencrypted RTP streams because any ISP in the path of those 
packets can listen to them without leaving any trace, no matter what relaying 
solution you use or if you use a relay at all.

Mediaproxy 2 can be affected by impersonation. Because the relay learns the 
addresses of the endpoints from the first RTP packets, if an attacker would 
send RTP first, it would take the place of one of the participants in the call 
and all further RTP traffic will be forwarded to this attacker instead of the 
original participant. This allows the attacker to pretend to be the person he 
tries to impersonate. However unlike the site you mentioned claims, the 
attacker needs to have a privileged position within the network to do so. In 
order for this kind of attack to succeed, the attacker needs to be in the SIP 
signaling path, in order to be able to see the SIP traffic and learn the RTP 
IP/port where to send his packets. The ports allocated by mediaproxy cannot be 
guessed otherwise. In addition to having this privileged position in the 
network, the attacker also need to be closer to the media relay than the 
participant he tries to impersonate, so his RTP traffic reaches the relay first 
and mediaproxy learns the attacker's address before the original participant's 
traffic has a chance to arrive at the relay.

In short impersonation can happen if the attacker can see the SIP traffic and 
learn the media IP/port and is closer to the relay to send its RTP first.

To prevent this you should use TLS for SIP signaling. But keep in mind that 
your SIP service provider and any other SIP service provider involved in the 
calls you make need to use TLS, as well as the other endpoint of the call needs 
to use TLS. Otherwise some SIP traffic will be sent in clear.

To prevent eavesdropping you should use encrypted media, but keep in mind that 
if you use SRTP, unless you use TLS end to end for SIP, the encryption keys 
will be leaked in the SIP signaling.

The best solution you have for both eavesdropping and impersonation is to use 
zRTP for media encryption. Not only it will prevent eavesdropping by encrypting 
the media, but it will also authenticate the other user preventing 
impersonation. If an attacker succeeds in impersonating a RTP endpoint you will 
know that you are not talking to who you expect to be talking. In addition zRTP 
negotiates the encryption in real time, so it doesn't suffer from the same 
problem SRTP suffers with leaked keys, so it works even if you do not use TLS 
for SIP signaling.

Hope this clarifies the subject a bit.

On 12 Mar 2018, at 12:58, Carlos Oliva wrote:

> Hi List:
> I have some questions about mediaproxy 2 ad rtpbleed vulnerability 
> https://www.rtpbleed.com/
> Is MediaProxy 2  vulnerable to this attack?
> If so, the media can be hijacked only at very begining or throughout the 
> entire call? 
> If an attacker hijacks the media the other party will stop hears the call or 
> the RTP will be send to both ends?
> Thanks for your help!
> thanks and Regards,
> Carlos Oliva
> _______________________________________________
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Users mailing list

Reply via email to