[OpenSIPS-Users] question about rtpbleed and MediaProxy by Ag-Projects

[Carlos Oliva]

Hi!

Many thanks Bodgan and Dan for the analysis.

I made some attack tests in our MediaProxy installation and this
impersonation is possible, but very difficult to success. You must be
quicker than the legitimate user sending RTP 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 MediaProxy. 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 UDP packets is very cheap. I used
rtpnatscan utility (with few modifications) to do the tests.

I think RTP 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 SRTP or ZRTP where
possible.

I only found a possible improvement to MediaProxy. It allocates ports in
consecutive and very predictable way and maybe a future improvement could
be to randomize the selected ports to mitigate the possibility of a
successful attack. Just my 2 cents.

very grateful for your response,

Carlos Oliva




2018-03-13 11:20 GMT+01:00 Dan Pascu <dan at ag-projects.com>:

> 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 at lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> --
> Dan
>
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180314/bec59b15/attachment.html>