TaCode Tuesdays: Fraud Control in Voice and SMS Applications [Part 1] DUP
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 come from areas 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.
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.
- Swift 2.0 knowledge
- Zang Account that includes AccountSid and AuthToken
- 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:
- Create your custom Country code in a ISO2 JSON format
- Setup your ATS enabled networking code
- Setup your RESTful API call
Now, Let’s Get Started!
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.
Step 2: Setup your ATS (App Transport Security) 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:
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.
Continued Next Week…
Well, that’s it for now! If you have any thoughts about the app or just want to share your own taco-related thoughts, you can comment below. I’ll be back in next week with another installment of TaCode Tuesday and the final part of this “Fraud Control in Voice and SMS Applications” series.