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