<div dir="ltr"><div><div><div><div><div>Hi!<br><br></div>Many thanks <span id="m_2528786622455445735:2b8.19">Bodgan</span> and Dan for the analysis.<br><br></div>I made some attack tests in our <span id="m_2528786622455445735:2b8.20">MediaProxy</span> installation and this impersonation is possible, but very difficult to success. You must be quicker than the legitimate user sending <span id="m_2528786622455445735:2b8.21">RTP</span> to the right ports. Other relays are continuously learning the media destination from the last received packet, it not seems to be the case of <span id="m_2528786622455445735:2b8.22">MediaProxy</span>. I think is not needed to be in the signalling path, you can spray the port range of media relay with packets randomly because send 
<span id="m_2528786622455445735:2b8.24">UDP</span> packets is very cheap. I used rtpnatscan utility (with few modifications) to do the tests.<br><br>I think <span id="m_2528786622455445735:2b8.25">RTP</span> with NAT involved can not be authenticated in any way, is a problem of the protocol itself and we can do nothing about that. I agree with Dan the only thing we can do for privacy is to use <span id="m_2528786622455445735:2b8.26">SRTP</span> or <span id="m_2528786622455445735:2b8.27">ZRTP</span> where possible. <br><br></div>I only found a possible improvement to <span id="m_2528786622455445735:2b8.28">MediaProxy</span>. It allocates ports in consecutive and very predictable way and maybe a future improvement could be to <span id="m_2528786622455445735:2b8.30">randomize</span> the selected ports to mitigate the possibility of a successful attack. Just my 2 cents.<br><br><span id="m_2528786622455445735gmail-result_box" class="m_2528786622455445735gmail-short_text" lang="en"><span class="m_2528786622455445735gmail-">very grateful for your response</span></span>,<br><br></div><div>Carlos Oliva<br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span><font style="font-size:12px" color="#808080" face="Arial, Tahoma, sans-serif"><br></font></span></div></div></div></div></div></div></div>
<br><div class="gmail_quote">2018-03-13 11:20 GMT+01:00 Dan Pascu <span dir="ltr"><<a href="mailto:dan@ag-projects.com" target="_blank">dan@ag-projects.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
So rather than address it from the point of view expressed on the site, let me explain what the possible problems are.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Hope this clarifies the subject a bit.<br>
<div><div class="h5"><br>
On 12 Mar 2018, at 12:58, Carlos Oliva wrote:<br>
<br>
> Hi List:<br>
><br>
> I have some questions about mediaproxy 2 ad rtpbleed vulnerability <a href="https://www.rtpbleed.com/" rel="noreferrer" target="_blank">https://www.rtpbleed.com/</a><br>
><br>
> Is MediaProxy 2  vulnerable to this attack?<br>
><br>
> If so, the media can be hijacked only at very begining or throughout the entire call?<br>
><br>
> If an attacker hijacks the media the other party will stop hears the call or the RTP will be send to both ends?<br>
><br>
><br>
> Thanks for your help!<br>
><br>
> thanks and Regards,<br>
><br>
> Carlos Oliva<br>
</div></div><span class="">> ______________________________<wbr>_________________<br>
> Users mailing list<br>
> <a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.opensips.org/cgi-<wbr>bin/mailman/listinfo/users</a><br>
<br>
<br>
</span>--<br>
Dan<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.opensips.org/cgi-<wbr>bin/mailman/listinfo/users</a><br>
</div></div></blockquote></div><br></div></div>