TaCode Tuesdays: Fraud Control in Voice and SMS Applications

Posted by Alex Misevski on November 8, 2016

TaCode_Image_New.jpg

Welcome back to TaCode Tuesdays! This is the only place you can find snippets of code for use in your very own text/voice apps, along with a weekly dose of taco puns. I’m a developer here at Zang and not only am I a big fan of tacos (if that wasn’t already apparent), I’m also a fan of open source. My goal is to share a new app idea each week that you're free to use “as is” or modify and use as the basis for your next app.

In the last few weeks, I began detailing how to build an interactive voice response system (IVR) using Zang—you can check out PART 1 here, PART 2 here, and as always, if you’d like to learn how to get started on Zang, take a look at our very first post.

This week I’m going to talk about Fraud Control within your own iOS SMS and voice apps—this week I'll introduce the topic and show you some code, then I'll be back next week to finish it off, so let's get into it!

Phreaking is a type of fraud where hackers use computers, random number generators, and password-cracking programs to attack voice and data networks. Once successful, phreaks overload telephone system through unauthorized outbound calls that are often forwarded to continents with high call rates such as Europe and Africa. In doing so, phreaks caused significant loss in income and productivity – in fact global telecoms revenue lost due to fraud is at $38.1 billion. A recent study conducted by Smart IPX showed that 43 percent of wholesale fraud destinations are in the Balkan States like Bosnia, Serbia, Azerbaijan, and Albania. This is closely followed by Africa (25 percent) and South America and the Caribbean (20 percent.) Throughout the years, phreaks have exploited the system through PB/IP hacking, application subscription fraud, dealer fraud, and identity subscription fraud.

The rise of cloud computing – more particularly unified communications solution offered as platform as a service (PaaS) -- makes voice and SMS applications more challenging. In this blog, we will give you an idea how to prevent fraud for applications created through a PaaS VoIP in three ways: securing your PBX, implementing a trunk line, and hardening network security.

PBX Security

Cloud-based private branch exchanges (PBX) are easy to implement, but keeping them secure is a challenge. Because soft PBX can initiate an unlimited number of chargeable calls, it has become a target of organized crime, causing losses that range from $5,000 to almost half a million dollars.

If your voice or messaging applications are using cloud based PBX, note that securing it can be difficult,
especially if it’s maintained on premise and managed internally – unless of course you have engineers who are experts in fraud control. The best and most cost efficient approach is to subscribe to PaaS offering hosted VoIP because it performs routine checks that could flag any threats or vulnerabilities which include:

  • Checking of new vulnerabilities and implementation of fixes
  • Review of firewall logs
  • Flagging of unexpected surge in call traffic
  • Review of network graphs for unexpected call traffic

Another option for preventing fraud in your VoIP PBX is preventing voicemail trunk-to-trunk transfers or at least making sure that voicemail passwords aren’t automatically generated or saved so that they can’t be hacked. Although meant to be a premium feature, enabling customers to transfer their voicemail to another voicemail are now exploited by hackers to automatically transfer a call to an international destination with higher rates. Implementing off-switch transfer restrictions can prevent that.

Voice applications can also be developed to prevent calling premium-rate telephone numbers (ex. toll-free numbers, masked numbers, adult chat lines, directory enquiries, etc.). Premium numbers have long been used by criminals to exploit unsuspecting users to call a sort of a 1-800 number charging them higher than usual phone rates. In the US, consumers are protected by Federal Trade Commission laws. This gives them the right to block dialing premium numbers, a three-second hang-up grace period, prohibition on accepting marketing calls from children, and the right to contest billing errors.

Trunk Line Security

Subscribing to a VoIP PaaS such as Zang can allow developers to implement some safeguards to protect their SMS and voice applications from fraud though the use of their application programming interface (API). This is a quick tutorial showing you how to do that.

Requirements:

  1. Swift 2.0 knowledge
  2. Zang Account that includes AccountSid and AuthToken
  3. Familiarity with HTTPS

When using Zang's built-in Fraud Control API you can tailor your web service call by tapping into the new iOS 9 Apple App Transport Security (ATS) functionality. Enabled by default, ATS improves privacy and data integrity by ensuring mobile application network connections employ industry standard protocols and ciphers. This fraud control feature of iOS 9 works by having all representational state transfer (REST) requests done over HTTPS.

There are three major steps in using Zang's Fraud Control API:

  1. Create your custom Country code in a ISO2 JSON format
  2. Setup your ATS enabled networking code
  3. Setup your RESTful API call

Let’s start!

Step 1: Create your custom country code in a ISO2 JSON format file. Below are examples in creating a look-up of your country codes.


1.1 ISO2 country codes to ISO2 continent codes
{...
"US": "NA",
"UY": "SA",
...}
1.2 ISO2 country codes to country names
{...
"AQ": "Antarctica",
"AR": "Argentina",
...}
1.3 ISO2 country codes to ISO3 country codes
{...
"US": "USA",
"VC": "VCT",
...}
1.4 ISO2 country codes to city names
{...
"US": "Washington",
"UY": "Montevideo",
"UZ": "Tashkent"
...}
1.5 ISO2 country codes to ISO2 country phone codes
{...
"US": "1",
"VA": "379",
"VC": "+1-784"
...}

 

Step 2: Setup your ATS enabled networking code.

2.1 Add some keys into the info.plist in your Xcode project, add a row in that dictionary, and input the URL for your web service API. For instance, if your domain is set as "http://mycompany.com/api", change the new row to a dictionary and change it to "mycompany.com/api". Trailing slashes and prefixes 'http' and 'https' are removed in this step.

2.2 Under the new dictionary entry, add a Boolean data type "NSThirdPartyExceptionAllowsInsecureHTTPLoads" with "YES" as the default value.
The following are the list of exceptions exclusive for iOS9:

NSTemporaryExceptionMinimumTLSVersion
NSTemporaryThirdPartyExceptionAllowsInsecureHTTPLoads
NSTemporaryThirdPartyExceptionMinimumTLSVersion
NSTemporaryExceptionAllowsInsecureHTTPLoads
NSTemporaryExceptionRequiresForwardSecrecy
NSTemporaryThirdPartyExceptionRequiresForwardSecrecy

Take note that while most security features for ATS are enabled by default, certificate transparency is not - hence requiring opt-in. There's always a room for third party certificates of your choice to support transparency that you can enable through NSRequiresCertificateTransparency key.


3.Setup your RESTful API call

3.1 Create a Swift method for HTTP 'POST' using 'NSURLSession'. 'NSURLConnection' was already deprecated in iOS 9 and has been replaced by 'NSURLSessionDataTask [[NSURLSession sharedSession] dataTaskWithURL:completionHandler: NSURLResponse. Note that NSError' is not required if you target iOS 8.

// Zang API: Block Destination
// URL: https://api.zang.io/v2/Accounts/:{AccountSid}/Fraud/Block/:CountryCode.json
// Where: CountryCode.json - is your list of restricted items for outbound calls and SMS to some destination


func postData() {
// Initialise session with Zang
let postEndpoint: String = "{https://api.zang.io/v2/Accounts/:{AccountSid}/Fraud/Block/:CountryCode.json}" <-- call to Zang
let url = NSURL(string: postEndpoint)!
let session = NSURLSession.sharedSession()


//Fill up the necessary parameters
let postParams : [String: AnyObject] = ["MobileEnabled": "true",
LandlineEnabled: "true",
SmsEnabled: "true"
]

// Make the request
let request = NSMutableURLRequest(URL: url)
// Set type of method in this its http POST
request.HTTPMethod = "POST"
request.setValue("application/json; charset=utf-8", forHTTPHeaderField: "Content-Type")
//swift error handling using do-catch, be mindful that pedantic type of error handling //similar to ‘Java’ is not recommended.
//the idea behind defining your own error types is to let you centralize things on your //code.
do {
request.HTTPBody = try NSJSONSerialization.dataWithJSONObject(postParams, options: NSJSONWritingOptions())
print(postParams)
} catch {
print("bad things happened")
} catch Default { print(“ unrecoverable error”)}

// We fetched the information from the web service and wanted to be notified when //it finished. Swift provides the 'completionHandler'


session.dataTaskWithRequest(request, completionHandler: { ( data: NSData?, response: NSURLResponse?, error: NSError?) -&gt; Void in
// ensure we get the response
guard let realResponse = response as? NSHTTPURLResponse where
realResponse.statusCode == 200 else {
print("Not a 200 response")
return
}

// Parse the JSON thats been fetch coming from the RESTful API
if let postString = NSString(data:data!, encoding: NSUTF8StringEncoding) as? String {
// prints out the response data coming from the Zang API
print("POST: " + postString)
self.performSelectorOnMainThread("updatePostLabel:", withObject: postString, waitUntilDone: false)
}

}).resume()
}

3.2 Below is the expected result of a successful web service call to Zang 'Block destination' API

{
"blocked": {
"is_lock": false,
"mobile_enabled": true,
"landline_enabled": true,
"date_updated": "Wed, 05 Nov 2014 15:14:34 -0000",
"country_code": "HR",
"sid": "FRbf8890849dc9b288ff6540bebYzLnD823jLmn",
"country_name": "Philippines",
"date_created": "Wed, 05 Nov 2014 15:14:34 -0000",
"sms_enabled": true,
"country_prefix": "+63"
}
}

Other than this, you can also code your application to have an outbound call threshold upon reaching a certain monthly spend. The threshold can be in a form of an alert wherein an in-app notification or an email can be sent informing the customer that their account is close to consuming its full credit line. Outbound calls can also be automatically cut once the pre-defined threshold has been reached. But this is another topic for a future blog – subscribe to Zang to be notified when this tutorial comes out.

 

Network Security

Hardening network security through voice and data firewalls, penetration testing, and adoption of industry standards in security is our last recommendation to protect your voice and SMS applications from fraud. 


Voice firewalls logs monitor and control all inbound and outbound activities on a per call basis through a call access control (CAC) that is user-defined. Through this solution, data and network penetration, attacks on telephony systems and other infrastructure, unauthorized internet sessions, long distance abuse, and other forms of line disruption can be prevented. The diagram below shows how this is implemented.
Network-Architecture.png

Figure 1: Network Architecture - Voice and Data Firewall

This network architecture shows how Voice and Data firewall can be implemented together with Zang PaaS to securely run a voice and messaging application – or any application for that matter which makes use of Zang APIs. Essentially, the Voice and Data firewall works as an additional layer of protection to perform real-time security for voice/unified communications (UC) and modem connection backdoors through unsecured phone lines. According to Gartner 2016 magic quadrants, industry leaders in Voice firewalls are: AhnLab, Check Point Software Technologies, Cisco, and Dell SonicWALL.

Protection is Crucial

Protecting voice and messaging applications from fraud can be challenging most especially at the age of cloud computing. There are generally three ways to secure your systems and applications: through PBX, trunk line, and network hardening. Some of the safeguards can be acquired from PaaS or software as a service (SaaS) offerings such as network and data firewalls; but some security measures have to be native to your application, like block listing or white listing through certain APIs like those offered by Zang. Another thing that you can do is establish secure application business rules like preventing calls from premium numbers and disallowing switch-to-switch voice mail transfer. Regardless of the method, it’s crucial that you take the steps to protect your voice and SMS applications from fraud.


Topics: Communication Apps, Ideas, TaCode Tuesday, cPaaS