The VC Warehouse Helpdesk has received several calls from customers in the last couple of weeks reporting the following symptoms on their VC endpoint:

• Frequent unscheduled incoming calls

• H.323 protocol

• 64K bandwidth

• Unknown and constantly changing source IP address

• Source name often “Cisco”

This is caused by an H.323 scanning tool that is part of a penetration testing product called “Metasploit,” which has basically got in to the wrong hands.

The aim of this malicious activity is to carry out “toll-fraud” by forcing the receiving video endpoint to make a dial out call to the PSTN/ISDN network, frequently to a premium rate phone number, which not only costs the victim potentially a large amount of money in call costs but also lines the pockets of the fraudsters who also own the premium rate service. The secondary aim of this activity from less “dangerous” parties is just simply to annoy.

However, the good news is, other than the annoyance of receiving all these incoming calls there’s no way that the toll-fraud can be carried out on any Polycom video endpoint, even if it has a PSTN/ISDN network connection in addition to its IP connection, because it’s not possible to initiate an outgoing call from a Polycom video endpoint simply by calling it.

The following is a list of deployment scenarios and the steps that can be taken to mitigate against this malicious activity as well as a best practice recommendation to stop the malicious calling now and in the future.

VC endpoint directly on internet (with static public IP address)

This is the most vulnerable deployment of a Polycom VC endpoint because it sits directly on the internet so is completely exposed to the malicious activity. This is not a recommended deployment scenario by VC Warehouse.

• Turn off auto-answer – endpoint will still ring

• Switch on “Do not disturb” when the endpoint is not in use (remember to switch it off when it is to be used) this will stop the endpoint from ringing, i.e. all calls are blocked

• It is assumed the malicious activity will cease when the attackers realise they cannot conduct toll-fraud

VC endpoint NAT’ed (port forwarded) behind firewall

If your VC endpoint is behind a traditional firewall and is NAT’ed from a public IP address you are still vulnerable because the VC endpoint is effectively listening on the internet for an incoming call. As soon as the scanner picks up that you are listening, it will either attempt to call you or call you at a later time. If you have multiple VC endpoints NAT’ed to separate specific public IP addresses then each

one is vulnerable because each one is listening on the internet.

• Turn off auto-answer – endpoint will still ring

• Switch on “Do not disturb” when the endpoint is not in use (remember to switch it off when it is to be used) this will stop the endpoint from ringing, i.e. all calls are blocked

• Activate a “Whitelist” or a “Blacklist” on your firewall – this will enable you restrict or allow incoming calls to known IP addresses. You will need to engage with your firewall admins on this.

• Use ACLs (Access Control Lists) on your firewall to block the malicious incoming calls using various parameters contained in the payload. You will need to engage with your firewall admins on this.

• Introduce a VC security policy which only allows outgoing IP calls; incoming calls are blocked by the firewall, so the endpoints are not listening on the internet. This will stop the problem altogether but will obviously reduce functionality in that legitimate third-parties cannot call you, only you can call

• them. If you do this then you can disregard the four recommendations above. Your firewall will also need to be “SPI” which will open the incoming port (TCP 1720) when a connection is made outbound on the same port in the same session. Again, you will need to engage with your firewall admins on this.

• It is assumed the malicious activity will cease when the attackers realise they cannot conduct toll-fraud

The recommended best practice by Polycom/Imago is to deploy a firewall traversal device (“VBP” or “RPAD”) to protect your video endpoints which sit on the private network. The firewall traversal device listens on the internet for incoming calls just like a video endpoint. In general the malicious calls are dropped by the traversal device because the malicious caller does not know the internal E.164 extension of the video endpoint. At the time of writing we have had no reports of any customers with firewall traversal devices experiencing this malicious activity.