cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2328
Views
5
Helpful
10
Replies

Call Manager Express Vulnerability

connectone
Level 4
Level 4

Hello All.

I have a small UC500 with Call manager Express. Today, I noticed a bunch of calls to Ukraine and Cuba etc, 011 international calls.

I have no idea how this happened, but the show sip-ua calls shows that the originating IP is the IP address of the UC500.

does anyone know of an exploit in CCME that is letting people into the system to dial out.

Any help is greatly appreciated

10 Replies 10

Michael Owuor
Cisco Employee
Cisco Employee

Here are a couple of documents that describe possible exploits and help mitigate toll fraud in your CUCME installation.

Unified Communications Manager Express Toll Fraud Prevention

http://www.cisco.com/en/US/products/sw/voicesw/ps4625/products_tech_note09186a00809dc487.shtml

Cisco Unified CallManager Express Security Best Practices

http://www.cisco.com/en/US/partner/docs/voice_ip_comm/cucme/srnd/design/guide/security.html

Hope this helps.

Regards,

Michael.

I am not able to get this to block outgoing 011 calls. I think I followed the instructions right in the toll fraud document but I am not so sure now. Seems as though it never reached the call-block statement for outbound calls and the first translation profile that matches the 9 for the secondary dialtone is matched and the call is allowed out.

I attached my rules.

dial-peer voice 1001 voip

description ** Outgoing call to SIP trunk (Generic SIP Trunk Provider) **

translation-profile outgoing PSTN_Outgoing

call-block translation-profile incoming BLOCK

destination-pattern 9T

voice-class codec 1

voice-class sip dtmf-relay force rtp-nte

session protocol sipv2

session target sip-server

dtmf-relay rtp-nte

ip qos dscp cs5 media

ip qos dscp cs4 signaling

no vad

voice translation-rule 999

rule 1 reject /^9011/

rule 2 reject /^91900.$/

rule 3 reject /^91976.$/

voice translation-rule 1112

rule 1 reject /^9011/

rule 2 reject /^91900/

rule 3 reject /^91976/

rule 4 reject /^9976/

rule 10 /^9/ //

voice translation-profile BLOCK

translate called 999

voice translation-profile PSTN_Outgoing

translate calling 1111

translate called 1112

translate redirect-target 410

translate redirect-called 410

When I do a test of the translation rule 1112, it seems to block the call. In action though, the debug statments show it is going to skip the first rule and use the last rule and does not block the call.

Jul 24 15:25:51.162: //-1/164E617A8914/RXRULE/regxrule_profile_translate_internal: number=90115342210926 type=unknown plan=unknown numbertype=called

Jul 24 15:25:51.162: //-1/164E617A8914/RXRULE/regxrule_match: Skipping a call block rule; number=90115342210926 rule precedence=1

Jul 24 15:25:51.162: //-1/164E617A8914/RXRULE/regxrule_profile_match_internal: Matched with rule 10 in ruleset 1112

Jul 24 15:25:51.162: //-1/164E617A8914/RXRULE/regxrule_match: Skipping a call block rule; number=90115342210926 rule precedence=1

Jul 24 15:25:51.162: //-1/164E617A8914/RXRULE/regxrule_profile_match_internal: Matched with rule 10 in ruleset 1112

Jul 24 15:25:51.162: //-1/164E617A8914/RXRULE/regxrule_match: Skipping a call block rule; number=90115342210926 rule precedence=1

Jul 24 15:25:51.162: //-1/164E617A8914/RXRULE/sed_subst: Successful substitution; pattern=90115342210926 matchPattern=^9 replacePattern= replaced pattern=0115342210926

What would you suggest. I do not want to do International calls. What would be the preferrable solution is to block all international calls (011) unless you put in a code or it prompts for international code before letting the call out.

Thanks

FRank Auciello

Hi, the most effective measure, put an ACL on the internet inteface that allows SIP only for trusted addresses.

The reason why the voice translation-rules are not blocking the test calls is because the only option for call blocking is in the incoming direction from the perspective of the voice gateway. In this configuration dial-peer 1001 is handling outbound calls. It would be effective in blocking those calls if they were originating from outside your network and coming in via the SIP trunk.

While recognizing that threats may be both internal or external, Paolo gives good advice (+5 Paolo) about using ACLs to restrict the traffic that is allowed to communicate with your router. Leverage the IOS firewall feature as described here:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/srnd/design/guide/security.html#wp1077429

The dial-peer in use also has 9T as its destination pattern, effectively allowing any and all calls to be dialed through this one dial-peer, including international calls. You can get some control and granularity by creating separate dial-peers to handle calls to different destinations such as local, long distance, emergency and international, then leveraging features such as Class of Restriction (COR) to restrict which phones can place calls through the different dial-peers.

COR is the capability to deny certain call attempts based on the incoming and outgoing class of restrictions provisioned on the dial peers. COR specifies which incoming dial peer can use which outgoing dial peer to make a call. Each dial peer can be provisioned with an incoming and an outgoing COR list. COR functionality provides flexibility in network design by allowing users to block calls (for example, calls to international or 900 numbers) and allowing different restrictions to call attempts from different originators

Class of Restriction - CME Admin Guide

http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/admin/configuration/guide/cmeblock.html#wp1014179

Configuring Class of Restrictions (COR)

http://www.cisco.com/en/US/tech/tk652/tk90/technologies_configuration_example09186a008019d649.shtml

If prompting the caller for a code before allowing the call to be placed is also a desired solution, the option does exists as described in the following link:

https://www.myciscocommunity.com/docs/DOC-1400#Can_UC500CME_be_configured_to_prompt_a_caller_for_a_PIN_before_placing_a_call

Hope this helps.

Regards,

Michael.

Adrian Saavedra
Level 7
Level 7

Hi,

Read about this, should help if you don't have some kind of security in your UC500.

http://www.cisco.com/en/US/products/sw/voicesw/ps4625/products_tech_note09186a00809dc487.shtml

Hope it helps, please rate if it does.

Best regards,

- Adrián.

pcameron
Cisco Employee
Cisco Employee

There are several 'port scanning' tools that probe IP address ranges with SIP invites messages and build up a list of 200 OK responses. This way they determine SIP capable devices and can then concentrate on determining dial plans. .

To prevent the unauthorised SIP and H323 calls, the simplest fix is to add an access list that blocks access via UDP port 5060 and TCP port 1720/5060 on any public facing interface.

In terms of basic security for a VOIP router, there are some well known security holes that can be easily exploited -

 

    Connection of an ethernet interface to the public internet without any form of firewalling or access blocking

    Basic passwords (do you know how many people use 'cisco'!) used for login access

Using Telnet for access instead of SSH - password as sent in the clear with telnet

    Using a destination pattern of '.T' for outgoing POTS dial peers

 

There are three simple way of blocking SIP or H323 unauthorised traffic. Some of these recommendations include blocking MGCP port numbers as well, but this is generally less of of a risk because of the complex external call processing required for MGCP control -

 

1) Using standard access lists and applying them to the interface  

 

access-list 128 deny tcp any eq 5060 any

access-list 128 deny tcp any any eq 5060

access-list 128 deny udp any eq 5060 any

access-list 128 deny udp any any eq 5060

access-list 128 deny tcp any eq 1720 any

access-list 128 deny tcp any any eq 1720

access-list 128 permit ip any any

 

interface FastEthernet 0/0 

 ip access-group 128 in 

 

2) Turning off SIP transport.

 

sip-ua

 no transport upd

 no transport tcp

 

(When applying this workaround to devices that are processing MGCP or H.323 calls, the device will not allow SIP processing to stop while active calls are being processed. As a result, the workaround should be implemented during a maintenance period when active calls can be stopped)

 

3) Using control plane policing and policy maps

 

access-list 111 deny tcp any any eq 5060

access-list 111 deny tcp any any eq 5061

access-list 111 deny udp any any eq 5060

access-list 111 deny udp any any eq 5061

access-list 111 deny udp any any eq 2427

access-list 111 deny tcp any any eq 1720

access-list 111 deny tcp any any eq 11720

access-list 111 deny udp any any range 16384 32767

access-list 111 permit ip any any

 

class-map match-all drop-voice-class

  match access-group 111

policy-map drop-voice-traffic

  class drop-voice-class

  drop

control-plane

  service-policy input drop-voice-traffic

You can also use some of the other CME call blocking features described in the other posts. The best solution is to prevent the unauthorised trafffic from reaching the gateway in the first place.

Hi,

I'm also have some quite same scenario in my network. I've 2821 router with old IOS. (c2800nm-entservicesk9-mz.123-14.T.bin). I've turn off SIP transport. so when i issue "show ip sockets" the port is not showing. But when i scan using nmap or telnet to 1720 its opening. I applied the control place policy map the router got struck. Any help on this.

Hi pcameron,

I think the access-list should be other way around otherwise it will drop all the packets...

access-list 111 permit tcp any any eq 5060

access-list 111 permit tcp any any eq 5061

access-list 111 permit udp any any eq 5060

access-list 111 permit udp any any eq 5061

access-list 111 permit udp any any eq 2427

access-list 111 permit tcp any any eq 1720

access-list 111 permit tcp any any eq 11720

access-list 111 permit udp any any range 16384 32767

access-list 111 deny ip any any

You are right - it has been a while since I played with CPP and it seems my notes are a bit messed up.

Following is a note on CCO that explains more about CPP. It highlights how you need to 'deny' traffic you want to permit and 'permit' the traffic you want to deny -

http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/ctrl_plane_policng_ps6350_TSD_Products_Configuration_Guide_Chapter.html

Thanks for the link.

Regards,