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

[Carlos Oliva]

Hi Dan:

If you spray all ports in the range you still can cause a DOS, but giving
preference to the address of sip signaling this kind of attack can be
mitigated in 99.9% of the cases. I think you've got a great idea that
should make MediaProxy even harder.

thank you so much











*Carlos Olivaadministrador de sistemas Tel: 902 02 02 97 - 935475858 *

2018-03-15 14:38 GMT+01:00 Dan Pascu <dan at ag-projects.com>:

>
> On 15 Mar 2018, at 9:31, Dan Pascu wrote:
>
> >
> > On 14 Mar 2018, at 18:55, Carlos Oliva wrote:
> >
> >> 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.
> >
> > Mediaproxy is a distributed solution, where you can run multiple media
> relays. If you are not in the signaling path, you will need to spray
> multiple IPs and port ranges since you do not know which media relay was
> chosen. This complicates things because you now have to send a lot of RTP
> packets before you can trigger the attack, which reduces your chances as
> this will make you a lot slower.
>
> I just realized something regarding this. It won't really work to spray
> all the ports in the range, because the media relay can be waiting on
> multiple calls to setup, which means that the attacker will end up with
> multiple RTP streams from different calls being forwarded to him and he
> won't know which is the one he wants to hijack. In the end he still needs
> to be in the signaling path to know for sure the IP/port.
>
> >
> >> 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.
> >
> > Not sure how this would help if you spray the whole port range. Besides
> port allocation is predictable if you have access to the relay, otherwise
> it depends on all other calls made which are random and out of the
> attacker's control. Plus the relay doesn't necessarily allocate
> consecutively. It takes the first available port, which is only consecutive
> in the beginning after the relay was started. After that, as calls are made
> and dropped, the available ports will have gaps and holes in them given by
> the active calls.
>
>
> Since the attacker needs to be in the signaling path, he will know the
> IP/port, so randomizing doesn't help. A better solution is to have the
> relay prefer RTP packets coming from the signaling IP of the endpoint. The
> signaling IP of the endpoint is already passed onto the relay, but at the
> moment is not used for anything (it was used by mediaproxy 1 to guess the
> endpoint, since mediaproxy 1 only listened on a single media port for both
> endpoints). Using this information, the relay can learn the IP from the 1st
> RTP packet, but if it later receives media from the signaling IP it can
> forget the previous address and lock onto the signaling IP. That way if an
> attacker tries to hijack a stream, he will get a few RTP packets from the
> other endpoint in the beginning, until the user sends its own RTP packets
> from the same IP as the SIP signaling and overrides the attacker, cutting
> him out. This should work for the vast majority of users that are behind
> NAT and only expose users to impersonation attacks if their signaling and
> media come from different IP addresses.
>
> --
> 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/20180316/b15d8575/attachment.html>