IP PBX Toll Fraud - Everyone Is At Risk

It seems no one is safe. Every IP Telephony Service Provider [ITSP] I have talked to has suffered an IP PBX hack. End Users of VoIP phones most commonly do not remember or know how to change the password on their PBX or voicemail account. Default passwords for a PBX are usually the last four digits of the phone extension so hackers can easily cycle though to determine a weak or discoverable password. Once into the PBX, they can originate calls from anywhere on the Internet and pump traffic volume to numbers that will realize them fraudulent revenues

Voicemail can be configured to dial out eg when you hear the greeting “please wait while we attempt to reach your party”, of course the voicemail system is making an outbound call which is setup by the hacker to redirect to their intended destination.

The fraudster can resell such phone capacity. One of the nice advantages of VoIP is its built in features for Moves, Adds and Changes. When the time comes to move office, you can just pack you VoIP phone and take it with you. Plug it into the internet or your companies IP cloud and it will register with your IP PBX and you can make calls. If you travel, you can take your VoIP phone with you and plug it into the internet in your hotel room and makes calls as if from your desk. So The PBX has no concept of your physical location or who is using the phone and so fraudsters, once they hack your PBX can make calls from anywhere, using your account.

The Telecommunications industry has annual revenues of $2.1 Trillion. Telecom fraud is calculated to cost the telecom industry $40 Billion each year.

The calls come out of your IP PBX, to your ITSP, offering a SIP Trunking service (i.e. a service that routes calls from a VoIP environment to the PSTN and therefore to any expensive international destination offered. So your ITSP receives an invoice from the International carrier for all these international calls. Fraudsters often choose weekends or other times outside business hours to attack. This way, the attack goes unnoticed and the account is beaten to death whilst no one notices or cuts it off.

“How to lose your year’s profits in 15 minutes!” was the way one of our customers described Toll Fraud. The ITSP receives this rather large bill from the international carrier. If he demands payment from the enterprise which has allowed their IP PBX to be hacked, he will surely loose a customer. Small companies who typically have small telecom bills can afford suddenly to pay up for a $20,000 to $30,000 bill. Many events run into the hundreds of thousands.

Although the ITSP caught in the middle may be to share some of the costs with their customer and the international or long distance carrier, they cannot afford to lose customers and will not often impose the charges on their client. So this is a loss the ITSP usually has to take on the chin.

How can we detect it in real-time and turn it off in real-time to prevent the cost leakage? Advanced monitoring systems are now available which will not only detect the fraud attack in real-time but will also turn if off.

11 Million Euro Loss - 1 Million in Profits - VoIP Fraud

Recent Voice over IP fraud attackers made over 1 million Euro in profits. 
It seems that they simply were scanning for PBX servers with phone extensions that have weak passwords. Then they abused these accounts to make phone calls for "free", except that free has the price of 11 million EUR for the service provider victims!

Apparently, originally they used these accounts for their own personal phone calls. However they got greedy and between October 2009 to February 2010, they made 23500 calls / 315000 minutes to premium numbers. Then (from what I understood), they got even more greedy and used a Shadow Communication Company and prices for premium numbers that then linked to another site further obfuscating their "business." Using this scheme they recruited other people to make  1,541,187 fraudulent calls or 11,094,167 minutes of talk time.

They used other premium numbers affiliate networks at first and then, when they realized the potential, they set up a company in the UK - Shadow Communications Inc. - through which they were able to sign a  contract on their own with a premium rate number provider and offer their own affiliates service, basically taking their "business" to a whole new level.

One of the original articles on this can be found here.

Storming SIP - VoIP Systems Are The New Target

You Will Be Attacked - Reduce Exposure


When implementing a VoIP infrastructure or any kind of net­work technology, it is best to reduce the exposure to attack. The fact that the VoIP infrastructure is typically sitting next to other network entities makes the SIP network elements reachable and possibly vulnerable to an attack coming from the other network serv­ers. The number of VoIP phones and PBXs on the Internet is constantly growing, and if the infrastructure does not require exposure to the Internet, then avoid it. To help you separate the VoIP network from the rest, various network switch vendors allow you to set up a VLAN specifically for VoIP. However, be aware that VLANs are not a panacea, and tools like VoIPhop­per make it easy to demonstrate the fact that VLAN is not enough. Cisco published a white paper called VLAN Security, where they describe how to protect against a number of attacks aimed at VLAN technology. Segregat­ing the VoIP network can also be done through the use of firewalls or physical separation. VPN tunneling has also been previously suggested because it provides both encryption and can also be used to separate the VoIP traffic from the normal traffic.

However, these solutions might not always be feasible – especially since one major advantage of VoIP is that it integrates with other network elements on the Internet. In fact, various VoIP vendors market the fact that you can use your existing network infrastruc­ture without having to lay new cables. Whether or not this is a good idea depends on a large number of factors. When designing a VoIP infrastructure, it is therefore important to understand the requirements and mitigate depending on the case. For example, a hotel VoIP network will have different require­ments than a corporate IP phone net­work, and therefore a systems designer can apply different security precautions during the planning stage. Some other suggestions and observations:

• It is of course good to make use of encryption mechanisms such as TLS and SRTP. Unfortunately, the encryption for SIP and RTP is not yet widely supported. Zfone by the creator of PGP is particularly interesting. We shall not be going through this subject in depth since it is not within the scope of the attacks described within this article, but it definitely deserves a mention.

• The importance of good pass­words for IP Phones should not be underestimated. If the system does not require that end users set their own pass­word, then do not allow this functionality. Instead, make use of some kind of password man­agement and set their password to one that is unique and hard to guess. Applications such as KeePass, which is open-source and free, allow you to generate strong random passwords for you, as well as manage such passwords in a relatively secure manner.

• OpenSER, which is an open-source SIP server, has a module named pike. This module is able to block requests that exceed a given limit. This can allow for blocking of both extension guessing and password cracking. However one has to be cautious with such solutions. Attackers can make use of IP spoofing to intentionally block legitimate traf­fic. It might also unintentionally block legitimate traffic if its not properly conFigured.

• SIP allows extension lines which do not require authentica­tion. If there is no justification for unauthenticated extensions, then make sure NOT to use this feature.

• Hardphones will get security fixes in the form of a firmware update, while softphones will get a new software release. Keeping up to date with the latest versions can be a pain, but it is certainly one way of making sure your system does not fall victim to attackers exploiting a security vulnerability in your SIP phone.

You Are Under Attack

Detection is a very important step in a security solution. A network IDS such as Snort, when placed at the right location, can be of great help when trying to detect that an attack is underway. Snocer, which describes themselves as providing Low Cost Tools for Secure and Highly Available VoIP Communication Services, has previously published some Snort rules for public consumption. These rules are also available in the latest Snort community rules. In this section we will describe some of them and explain how they can be effective in catching the attacks mentioned previously. We will also provide some new Snort rules which can also detect activity de­scribed in this article and not caught by the current Snort community rules.

The Snort rules by Snocer are quite easy to understand, and are able to provide generic detection. Each of the rules looks out for an excessive number of SIP messages coming from a single IP address over a short period of time. The different SIP messages are INVITE and REGISTER requests, and 401 Unauthorized mes­sages.

The INVITE and REGISTER flood attacks catch svwar and svcrack be­ing run with default options against a SIP proxy. To be able to catch a default svmap scan, we need to be looking out for SIP messages with an OPTIONS request, spanned over different hosts in a short time. Listing 20 shows one such rule that triggers an alert if the rule is infringed 30 times in 3 seconds. One should probably adjust this rule depending on the ad­dress space being watched by Snort. If Snort is watching a /29 mask, i.e. only 6 hosts, then one should change the count to 6 and number of seconds to 1 or less. On larger networks, in­crease the count number to decrease the chance of a false positive.

The rule on excessive number of SIP 4xx Responses attempts to catch the majority of attacks outlined in this article. What it effectively does is match responses which contain a client error. This may be a 404 not found response like the one given by an Asterisk box when running svwar to identify SIP extensions or users. It will also match a password crack­ing attempt on an Axon PBX, or an extension enumerating attack on a Brekeke PBX when using svwar with the OPTIONS method. Of course, it will not catch a network scan for SIP devices on one which does not have a lot of devices, simply because the number of responses would be low.

The ghost phone call can also be easily detected since it generates a large number of ringing messages. Of course a payload of this attack is audible, and therefore the benefits of adding this rule might not be immedi­ately apparent since it makes itself so obvious. However, a Snort rule at this stage might be very useful during in­cident response, when trying to deter­mine things such as the source of the attack. The rule should be modified depending on the network. For exam­ple, it does not make sense to deploy this Snort rule on a calling center that takes 50 calls every minute.

Snort is not the only tool to monitor your VoIP infrastructure for attacks. In fact, Snort would very likely NOT detect any attacks passing through encrypted traffic. On the other hand, monitoring the logs on your IP PBX might be a good way of detecting some attacks destined to the SIP gateway. J. Oquendo posted a BASH script called astrap which monitors the Asterisk log entries for exces­sive number of failed authentication attempts. This small tool will list the offender's IP address, the number of password failures, and the extensions that were targeted on the Asterisk.

A host intrusion detection system such as OSSEC can be equally useful in detecting and automatically mitigat­ing attacks. At the time of writing, OS­SEC does not come preconFigured to support Asterisk log files, but this functionality can be easily added. Listing 21 includes a sample rule file for OSSEC to show how it can be conFigured to detect username enu­meration and password attacks on an Asterisk system such as Trixbox. List­ing 22 shows the changes required to enable this new Asterisk rule. We in­clude a decoder entry so that OSSEC will be able to extract the attacker's IP address and then use that to au­tomatically block the attack by adding the appropriate firewall rule.

References

• http://www.ietf.org/rfc/rfc3261.txt – RFC 3261

• http://www.iptel.org/sip/intro/purpose – Purpose of SIP

• http://www.wormulon.net/ – smap

• http://sipvicious.org/ – SIPVicious tool suite

• http://tinyurl.com/rtjl8 – SIP peers external authentication in Asterisk/OpenPBX

• http://www.hackingvoip.com/ – SIPSCAN

• http://www.oxid.it – Cain and Abel

• http://tinyurl.com/yph6jy – Interview with Robert Moore

• http://tinyurl.com/56bwd – VLAN Security White Paper

• http://www.snocer.org/Paper/sip-rules.zip – Snocer, snort rules

• http://www.infiltrated.net/scripts/astrap – astrap

• http://www.ossec.org/ – OSSEC

• http://www.trixbox.org/ – Trixbox

Hat Tip - Sandro Gauci

SIP Peering KPI’s - How to Measure Answer Seize Ratio

Service providers have for many decades measured key performance indicators for their SS7 interconnects with long-distance or international operators or peering partners. Such measurements are defined in ITU-T Recommendation E.411 "International Network Management – Operational Guidance" and E.422 "Quality of Service for Outgoing International Calls" and include Answer Seize Ratio [ASR], Post Dial Delay [PDD] and Network Efficiency Ratio [NER].

Name	Description
Counted	Number of calls
ASR	Answered calls (percent)
SSB	Subscriber busy (percent)
CGC	Circuit Group Congestion (percent)
SEC	Switching Equipment Congestion (percent)
CFL	Call Failure (percent)
RSC	Reset Circuit Signal (percent)
UNN	Unallocated Number (percent)
ADI	Address Incomplete (percent)
CLF	Clear Forward (percent)
LOS	Line Out of Service (percent)
rt	Response time (average)
wt	Wait time with answer (average)
wna	Wait time with no answer (average)
ct	Call time (average)
ht	Hold time (average)
Minutes	Total Call time in minutes

Table 1

Answer Seize Ratio [ASR] is used as a measure of network quality although the measurement also includes user behavior. In other words, if the call was not answered, the network could not be faulted, although the ASR measurement would be reduced by the uncompleted call, indicating lower quality. However, because for a given hour within a day, unanswered calls would always represent the same percentage, from day-to-day, this offset would be normalized out and carriers are able to monitor the trend of ASR and treat it as a relative measurement

Network Efficiency Ratio was designed to eliminate user behavior as a factor and better represent pure network performance.

Network Efficiency Ratio [NER] is defined as:

User Answers or Normal call clearing      -       Cause code: 16

+ User Busy                       -       Cause code: 17

+ Ring No Answer               -       Cause code: 18 & 19

+ Terminal Rejects)            -       Cause code: 21

NER = -------------------------------------------------------x 100

     (Total # of Call Attempts i.e. IAM’s)

SIP is a more flexible protocol and has wider uses than simple call control. Therefore, use cases differ widely and systems such as voicemail and call forwarding skew expected behavior for answered calls

Furthermore, SIP is a more flexible protocol and has wider range of response messages which can be used to specifically indicate certain types of failures from either servers, network devices or the movement or absence or other behavior of users. Accordingly, IETF has defined KPI's equivalent to Answer Seize Ratio and Network Efficiency Ratio. These are described under SIP End-to-End Performance Metrics draft ietf-pmol-sip-perf-metrics-04. For example, the equivalent of ASR is Session Establishment Ratio (SER)

Session Establishment Ratio (SER) is defined as follows, to quote the IETF

   “This metric is used to detect the ability of a terminating UA or

   downstream proxy to successfully establish sessions per new session

   INVITE requests.  SER is defined as the number of new session INVITE

   requests resulting in a 200 OK response, to the total number of

   attempted INVITE requests less INVITE requests resulting in a 3XX

   response.  This metric is similar to Answer Seizure Ratio (ASR)”

The SER is calculated using the following formula:

                 # of INVITE Requests w/ associated 200 OK

  SER = --------------------------------------------------------- x 100

     (Total # of INVITE Requests)-(# of INVITE Requests w/ 3XX Response)

Here is the message flow which defines the basic SER. if the session INVITE request results in an interim response, such as a 302 Redirect response, this should be subtracted from the denominator.

                           UA1                 UA2

                            |                   |

                            |INVITE             |

               +----------->|------------------>|

               |            |                180|

               |            |<------------------|

      Session Established   |                   |

               |            |                   |

               |            |                200|

               +----------->|<------------------|

                            |                   |

In SS7, the fate of the call is determined by the RELEASE message which ends the call. The fate of a SIP call is determined by the Response to each Request for each transaction within the SIP call. For example as above, session establishment is determined by a successful outcome from the call session establishment phase

The SIP Peering KPI’s RFC 6076 also defines Session Establishment Effectiveness Ratio (SEER) which is similar to Network Efficiency Ratio [NER] in the SS7 ISUP circuit switched world.

This metric is complimentary to SER, but excludes the effects of the terminating UAS or endpoint i.e. it excludes user behavior from the metric and therefore more closely reflects the performance of the network.  SEER is defined as the number of INVITE requests resulting in a 200 OK response and INVITE requests resulting in a 480, 486 (Busy Here i.e. that endpoint is busy), or 600 (Busy Everywhere; i.e. the interconnecting network is busy or congested or down) to the total number of INVITE attempts less the 3xx, interim responses.

In order to simplify the formula, the following variable ‘a’ is used to summarize multiple SIP responses:

   a = 3XX, 401, 402, and 407

The SEER is calculated using the following formula:

             # of INVITE Requests w/ associated 200 OK, 480, 486, or 600
SEER = -------------------------------------------------------- x 100
            (Total # of INVITE Requests)-(# of INVITE Requests w/ 'a' Response)

 SIP response codes

• 2xx—Successful Responses
• Eg 200 OK
• 4xx—Client Failure Responses
• 401 Unauthorized (Used only by registrars or user agents. Proxies should use proxy authorization 407)
• 402 Payment Required (Reserved for future use)
• 480 Temporarily Unavailable
• 486 Busy Here
• 6xx—Global Failure Responses
• 600 Busy Everywhere
• 603 ADD
• 
  

Another very useful measurement defined by the IETF here is Session Defects Ratio (SDR), also graphed by Palladion by checking a box. ‘503’ SIP Response messages commonly indicate a route to one of your peering partners is failing due to congestion of the Gateway or SoftSwitch.

Session Defects Ratio (SDR) is the percentage of call attempts receiving the following responses, in relation to total call attempts or INVITES:

o    500 Server Internal Error

o    503 Service Unavailable

o    504 Server Timeout

The SDR is calculated using the following formula:

  

                      # of INVITE Requests w/ associated 500, 503, or 504
     SDR = ----------------------------------------------------- x 100
                             Total # of INVITE Requests

In addition to this, some carriers like to plot Post Dial Delay, [PDD] and to generate an alert when this measurement exceeds a certain time threshold. PDD is defined as the time interval between transmission of the INVITE and reception of the ‘180 Ringing’ response message. The RFC prefers to define Successful Session Setup [SRD], the SIP equivalent of Post-Selection Delay (defined in E.721). This is an early indication of congestion soon to or about to occur on a given route and is a very useful KPI. Palladion can be configured to provide an SNMP trap or other notification to the Network Operations Center [NOC] of this imminent congestion so preemptive action can be taken.

Here is a table listing all the new RFC 6076 KPI’s with their SS7 or circuit switched equivalent:

SIP Peering KPI’s RFC 6076	SIP Definition	ISUP Equivalent	ISUP Definition
Registration Request Delay (RRD)	Time of final response – time of REG attempt	N/A Note *
Ineffective Registration Attempts	# IRA/total REG attempts	N/A
Session Request Delay (SRD)	Time of response – Time of INVITE
Successful Session Setup [SRD]	Time of response – Time of INVITE                eg  INVITE            to      180	Post-Selection Delay (defined in E.721)	IAM to ACM (or ALERTING)
Failed Session Setup  [SRD] and	INVITE to response indicating failure eg 4XX (excluding 401, 402, and 407 non-failure challenge response codes), 5XX, or 6XX message.	N/A	IAM to REL with a cause code indicating a failure
Successful Session Disconnect Delay [SDD]	BYE, to 2XX Ack	Time to Clear a good Call or CIC	REL to RLC
Failed Session Disconnect Delay [SDD]	BYE, to Timer F Expires	essage	Missing RLC i.e. expiry of ISUP T1 timer
Session Duration Time [SDT]	Time of BYE or time out – Time of 200 OK	Time of REL - Time of ANS	Average Call Hold Time (ACHT)
Successful Session Duration Time	200 OK response to an INVITE to BYE	See note below *
Failed session duration SDT	200 OK response to an INVITE, and the resulting Timer F expiration.	“awaiting Answer timer”	SS7 ISUP timer T9 (no response to ACM)
Session Establishment [SER ] Ratio	# of “good call” INVITEs ---------------------------------- X % Total INVITEs – interim 3xx Responses	Calls which connect Calls which fail	Answer Seize Ratio (ASR)
Session Establishment Effectiveness Ratio (SEER)	(# of INVITE Requests w/ associated 200 OK, 480, 486, or 600) ------------------------------ X % (Total # of INVITE Requests)-(# of INVITE Requests w/ 'a' Response)	NER = Answers (cc 16) +UserBusy-cc 17 + Ring No Answer (cc 18, 19 & 21) + Terminal Rejects) _____________ Total call attempts	Network Efficiency Ratio (NER) ITU E.411.
Ineffective Session Attempts (ISA) Invites resulting in:- o  408 Request Timeout o  500 Server Internal Error o  503 Service Unavailable o  504 Server Timeout	# of ISA x 100 -----------------------------               Total # of Session Requests		Ineffective Machine Attempts (IMA) in telephony    applications of SIP, and was adopted from Telcordia GR-512-CORE    [GR-512].
Session Completion Ratio (SCR) (a Session Completion is any SIP dialog that receives a valid response)	# of Successfully Completed Sessions x 100 ------------------------------------------ Total # of Session Requests	Call Completion Ratio (CCR)

Notes:

·         * REGISTRATIONs are rare across SIP peering points as these interconnects are typically between two trusted environments. In addition SBC’s are used to protect the sanctity of each network. Similarly an interconnect between two SS7 networks is a trusted and secure interface, so accordingly, no equivalent of REGISTRATIONs exists in SS7, although the MTP3 protocol is used to establish routing between Signaling Point Codes and ISUP control messages to set up voice trunks

·         ** Monitoring for short duration Successful calls in a circuit switched network has not been as important and for a VoIP network as speech quality is not so much of an issue in circuit switched networks. In a VoIP network, short calls are important to monitor because if speech quality is so bad, the callers hang up immediately and call back, ….hopefully. 

References

·         Basic Telephony SIP End-to-End Performance Metrics Request for Comments: 6076

·         ITU-T Recommendation E.411 : International network management - Operational guidance

·         ITU-T Recommendation E.422 : Observations on international outgoing telephone calls for quality of service

·         Telcordia GR-512-CORE  - LSSGR: Reliability, Section 12