Re: [OpenSIPS-Users] question about rtpbleed and MediaProxy by Ag-Projects
On 16 Mar 2018, at 11:15, Carlos Oliva wrote: > Hi Dan: > > If you spray all ports in the range you still can cause a DOS, I thought the exercise was about eavesdropping and impersonation. I would argue that if an attacker wants to eavesdrop or impersonate someone they would probably attempt to be as stealthy as possible and not cause a ruckus that would draw attention to them. If one wants to cause DoS they can do it at any level 9IP/SIP/RTP), there is nothing particularly special about the media relay. I could even argue that given that the RTP relaying happens at the kernel level, it could deal with a lot more traffic before being overloaded than a user space forwarding solution. > 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. -- Dan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] question about rtpbleed and MediaProxy by Ag-Projects
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 : > > 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 > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] question about rtpbleed and MediaProxy by Ag-Projects
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
Re: [OpenSIPS-Users] question about rtpbleed and MediaProxy by Ag-Projects
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 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. -- Dan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] question about rtpbleed and MediaProxy by Ag-Projects
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 : > 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
Re: [OpenSIPS-Users] question about rtpbleed and MediaProxy by Ag-Projects
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
Re: [OpenSIPS-Users] question about rtpbleed and MediaProxy by Ag-Projects
Hi Carlos, See inline Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit 2018 http://www.opensips.org/events/Summit-2018Amsterdam On 03/12/2018 12:58 PM, 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? Not 100% sure, but given the way mediaproxy worsk, I would say yes. If so, the media can be hijacked only at very begining orthroughout the entire call? only at the beginning when the other end of the media leg is learned based on the incoming traffic. If an attacker hijacks the media the other party will stop hears the call or the RTP will be send to both ends? IF the hijack is done, the regular user will not send / receive any more RTP traffic as the media server will talk only to the hijacker . 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 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
