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
> 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 mailing list