[cisco-voip] Fraud calls to Cuba - Please read

Fri Jan 9 13:58:43 EST 2009

Not to beat a dead horse, but I thought you might find this interesting. A new customer was just turned up on my network and there were some install problems, so my team was involved into trying to find the root cause. While we were running the "debug ccsip messages", we noticed some unexpected traffic. This is on a router that has not even been on the internet for more than a day or so. It is absolutely amazing to see how fast something like this can happen. Someone doing "voip wardialing" international numbers on a brand new customer install.

Jan  9 18:40:41.629 GMT: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:011380442010102 at 64.206.168.14 SIP/2.0
Via: SIP/2.0/UDP 66.197.138.69:5060;branch=z9hG4bK7d8c5757;rport
Max-Forwards: 70
From: "BenQ Telecom" <sip:BenQ Telecom at 66.197.138.69>;tag=as700507be<mailto:Telecom at 66.197.138.69>;tag=as700507be>
To: <sip:011380442010102 at 64.206.168.14>
Contact: <sip:BenQ Telecom at 66.197.138.69<mailto:Telecom at 66.197.138.69>>
Call-ID: 59f021193ae6eb9506735ee36691969b at 66.197.138.69<mailto:59f021193ae6eb9506735ee36691969b at 66.197.138.69>
CSeq: 102 INVITE
User-Agent: BenQ Telecom
Date: Sat, 10 Jan 2009 02:41:29 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 266

v=0
o=root 1121455329 1121455329 IN IP4 66.197.138.69
s=Asterisk PBX 1.6.0.3-rc1
c=IN IP4 66.197.138.69
t=0 0
m=audio 12860 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

________________________________
From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Corbett Enders
Sent: Thursday, January 08, 2009 3:31 PM
To: 'VOIP Group'
Subject: Re: [cisco-voip] Fraud calls to Cuba - Please read

Well List, thank you for the assistance.  I have run the following commands to all of my routers to block SIP:

voip-gateway(config)#sip-ua
voip-gateway(config-sip-ua)#no transport udp
voip-gateway(config-sip-ua)#no transport tcp

I have not acted on H.323 as it doesn't appear to be listening on that port.

From: Pender, James [mailto:James.Pender at PAETEC.com]
Sent: Thursday, January 08, 2009 12:35 PM
To: Ryan West; Mark Holloway; Corbett Enders; 'Ahmed Elnagar'
Cc: 'VOIP Group'
Subject: RE: [cisco-voip] Fraud calls to Cuba - Please read

Don't forget TCP/5060. I assist my companies fraud team from time to time in VoIP fraud, and when we find an open CME/CUBE or the like and we ask for it to be secured, most people forget that SIP can run on both UDP and TCP and they leave themselves vulnerable.

________________________________
From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Ryan West
Sent: Thursday, January 08, 2009 2:11 PM
To: Mark Holloway; 'Corbett Enders'; 'Ahmed Elnagar'
Cc: 'VOIP Group'
Subject: Re: [cisco-voip] Fraud calls to Cuba - Please read
Yeah, just allow UDP/5060 to the proxy, deny all other SIP traffic and allow the UDP ranges above 1024.  Most SIP providers do not use the 16384 - 32767 range for RTP streams.

-ryan

From: Mark Holloway [mailto:mh at markholloway.com]
Sent: Thursday, January 08, 2009 14:07
To: 'Corbett Enders'; Ryan West; 'Ahmed Elnagar'
Cc: 'VOIP Group'
Subject: RE: [cisco-voip] Fraud calls to Cuba - Please read

What is the proposed solution if CME is using a SIP Trunk to an ITSP?   I assume an ACL would be the best way to secure the router.

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Corbett Enders
Sent: Thursday, January 08, 2009 10:37 AM
To: Ryan West; Ahmed Elnagar
Cc: VOIP Group
Subject: Re: [cisco-voip] Fraud calls to Cuba - Please read

So it turns out SIP 5060 is open, after running show ip sockets.

Interestingly enough, the hacker is connected to me right now (though we've blocked international calls at the telco level).

His IP is 124.217.250.240.

If you read this article, http://www.honeynor.no/, it describes the attack in detail. I found the article by searching the phone number initially dialed,  52555169000.

From: Ryan West [mailto:rwest at zyedge.com]
Sent: Wednesday, January 07, 2009 9:50 PM
To: Ahmed Elnagar; Corbett Enders
Cc: VOIP Group
Subject: RE: [cisco-voip] Fraud calls to Cuba - Please read

If the router is connected to the Internet, both H323 TCP/1720 and SIP UDP/5060 need to blocked.  I don't remember the command offhand, but on some versions of code it is show ip sockets.  Check this out to actually disable default SIP and H323 processing:

https://supportwiki.cisco.com/ViewWiki/index.php/How_to_disable_H.323_and_Session_Initiation_Protocol_(SIP)_services_on_TCP_ports_1720_and_5060_of_a_IOS_gateway_router
-ryan

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Ahmed Elnagar
Sent: Wednesday, January 07, 2009 23:13
To: cenders at homesbyavi.com
Cc: VOIP Group
Subject: Re: [cisco-voip] Fraud calls to Cuba - Please read

Wow...exaclty the same problem I had...but with PRI...I have a site in Egypt that the user called us one day and informed that he has a bill from the Teleco for 100,000$ for a period of 3 months and they never produce this amount of calls...all calls were for random numbers and the call never exceeded 1 minute and these random numbers happen to be starting with 00 which is the internationl prefix here in Egypt.

After long nights of troubleshootting...I found that the gateway was configured to register SIP phones from the internet and I found an IP address from Mexico city that is trying this random calls so frequent, the strange thing is that the gateway was accepting these calls and route it to H323 side which relay the call to the PRI.

I did the following to ensure that it will not happen again...removed SIP at all from the gateway...converted the gateway to MGCP so that every call that will pass the gateway will need signalling from Callmanager and will leave a record in the CDR. But the strange thing the problem contiuned...

During troubleshooting we noticed something strange...alot of incoming calls coming to the PRI from a certain local number...and it was 3 AM in the morning we called this number and he told us that he know no one in this site and he has a problem that he got high invoices from the Teleco too...so we come up with this conculsion...seems that the CO. equipments has some problems and it is generating calls on behalf of the user to random numbers...a strange thing I know but till now this company still going to discussions with the teleco to solve this problem.

I suggest to do the followin...try to review CDR files and have a detailed bill from your Teleco and try to compare these calls with the CDR calls maybe this would help you...also try to activate some debugs and show commands "there is some tools that can automate show command every 5 mins or so" to know exactly when these calls happen and what is the source of it.

Good luck with this strange issue.
Thanks,
Ahmed Elnagar
________________________________
From: cenders at homesbyavi.com
To: cisco-voip at puck.nether.net
Date: Wed, 7 Jan 2009 20:26:56 -0700
Subject: [cisco-voip] Fraud calls to Cuba - Please read
Hello List,

I've got a situation with 2 remote sites.  Over the course of several days in late November, somehow the analog POTS line in the site (which we use for SRST backup) proceeded to make approx 4,940 calls to Cuba.  There wasn't really a pattern to the calls.  It started with a couple of repeated calls to the same number and from that point, the dialed number changed (not dialed in any sort of sequential pattern either).  Calls varied in duration from 0 seconds to many minutes long.  Sometimes the next call would happen right away and other times there would be several minutes delay between calls.  This proceeded to occur over the course of about a day and a half until the POTS provider called us and we blocked the line.

The analog line in the show home serves 2 purposes.  It is connected to the SRST FXO port on the Cisco 2801 router and also connects to the analog fax machine.

At this point, the POTS provider feels that somehow the 2801 router has been compromised and is being used to route calls out the FXO port.  We have a cordless phone on an ATA, and at first they felt this was the source but I indicated that any calls from the cordless phone would leave through our PRI in the main office, through the phone line on the FXO port.

Even if someone had managed to guess our admin password for the console of the router, I don't believe that person sitting on the Internet would be able to get a call to connect from their computer, through the Internet, and leave out our FXO port in our site.

I'm wondering if anyone on the list has some thoughts as to how the system could have been compromise or if it just isn't possible.  The POTS line is actually a digital line provided by Shaw (a local cable/telco in Alberta).  I feel that their "digital" phone terminal has been compromised though it isn't connected to the Internet in any way.  One other possibility is old school phone phreaking where someone has actually tapped into the physical line but they would have been sitting outside in the cold for a very long time making these crazy calls.

I look forward to any insight the collective brain power of this list can provide. The bill for these calls is over $6000.

Regards,
Corbett Enders.

Corbett Enders
Network Manager
Homes by Avi - 2007 Canadian Builder of the Year.
Tel: (403) 536-7170
Fax: (403) 536-7171
www.homesbyavi.com<http://www.homesbyavi.com/>

________________________________
check out the rest of the Windows Live(tm). More than mail-Windows Live(tm) goes way beyond your inbox. More than messages<http://www.microsoft.com/windows/windowslive/>

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.176 / Virus Database: 270.10.4/1880 - Release Date: 1/7/2009 8:49 AM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20090109/3666e309/attachment.html>