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 -- Dan _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users