Skip to main content

Please hold your call is being transferred to a phreak...(the insecurity of voice)

Information security largely focuses on data communications, and voice is often ignored. Every successful hack or extortion has a phone involved somewhere in the process, but in most cases the phone is a silent and overlooked component in the forensics. The hacking of telecommunications is usually termed phreaking as opposed to the more common term, hacking, which is related to data systems. An extraordinary culture has developed around phreaks, whereby they are treated with less severe persecution as hackers. As an example, Steve Jobs, is a revered business leader but Kevin Mitnick is a hacker. However, Jobs participated in dubious activities that were no less serious than Mitnick's contraventions. Society lets the guy who abuses a phone off the hook, but alternatively want to lock the hacker up and throw away the key. Neither activity should be condoned and both should be treated with equal disdain.
An impression exists that phreaking is an activity of a bygone age. This is not true and it continues, even more intensely to this day! The ignorance is bliss to such an extent that the forensics pertaining to the actual commercial losses related to phone fraud are not readily available. Many companies have been unknown victims of fraud by phreaks, and the service providers have billed these companies without any further due diligence. The company pays, the service provider receives revenue and the phreak walks the street freely.
Many companies do not secure their voice and almost all voice systems are inherently insecure. There are very few voice systems that are authenticated even at a rudimentary level. Companies need to establish their own voice security measures as service provider and regulator measures are lacking.
The reasons is that people and regulators are ignorant and in transient. Take for example, Caller ID Spoofing. This is a malicious action by an individual but it has not yet been criminalized. People who spoof caller IDs are crooks and companies who supply the service are the equivalence of technology brothels, pimping illicit services.
Many companies and individuals also withhold caller ID. When I see a withheld caller ID, I often ignore it. Withheld caller ID should go into a holding pattern DMZ and not permitted to use direct inward dial. A company that programs it's systems or PBX to withhold caller ID is up to no good. The motives for this type of configuration are highly questionable!
Caller ID like IP addresses would form the basis of any voice firewalling. Most hijacked phone calls made by phreaks in this neck of the Kalahari are made to Cuba, Nigeria, India, Russia and Pakistan, so a voice firewall would stop this in its tracks. The voice firewall, like a data firewall would as default deny all traffic. Based on originating caller ID and destination called ID a rule would permit the call. The rule could be granular to country, network, city, company or individual destination number! In would also be possible to group calls into categories, i.e. internal, external, business, emergency, personal, mobile, residential, etc. In addition rules can be defined around call type, i.e. voice, modem, fax, and IVR (via DTMF).
Many voice vendors ship their equipment with shoddy security. The defaults are well know and no forced process exists for an installer to change these defaults when taking a system live. This problem exists with all manner of PBXs, modems, voice gateways, video conferencing equipment, IVRs and voice mail systems. Ironically, you will find many companies with large investments in data security systems and nothing in voice security systems. In actual fact, I doubt that any vendor, especially the 800 pound gorillas have put any research or effort into voice security. Often their investment in data security is put forward as their offering which is inappropriate.
Not only is the equipment vulnerable but the processes are flawed. The three blind mice, highlighted service provider process flaws but I doubt that to this day any lessons have been learned and the exploits continue on a daily basis. Mitnick make the point about social engineering, and just as we have the ability to use voice firewalls as described above, we can also have voice IDS/IPS. There are social engineering signatures and phreaking profiles that can be created and triggered via scanning mechanisms. Such as:
  • Profiling: A voice IPS would use speaker recognition to associate profiles to phone numbers. A profile not associated with a valid phone number raises an alert.
  • Voice filtering: A phone call that that is made to an invalid phone location is either blocked, or goes into a queue where a password/pin is required to proceed. (similar to url filtering for the web).
  • War or demon dialing: When the system detects sequential dialing from a common phone location, then that location is blocked.
  • Vulnerability signatures: Similar to antivirus signatures the system detects any sequence of activity that attempts to exploit a known vulnerability and blocks the phone location. This includes the use of known equipment default passwords or a sequence of known DTMF vulnerabilities.
  • Spikes: If a level of activity occurs to resource, e.g. voice mail system, that is above the normal mean an alert is raised.
It is thus my opinion that any security threat manager or dashboard without a visible voice component is only a half baked job. Visibility into voice abuse, will provide a strong measure to supplement and enhance information security. It will go towards the mitigations of one of the root causes of problems in security.
The level of sophistication in the above mentioned approach will allow companies to nail insider or rogue traders and call centre leaks. The reason is that there are detectable patterns around phone calls, transactions and emails (including IM) when fraud is being committed. These patterns become visible when viewed together, but are not identifiable when investigated in isolation. These patterns can be predefined to trigger alerts when they happen. A truly unified threat management solution would have stopped Jerome Kerviel of Société Générale in his tracks, as well as being able to prevent the loss of many credit card leaks.

* I wonder how much of this the CIA does - like in the movie "Zero Dark Thirty" - with tradecraft.


Popular posts from this blog

Why Madge Networks, the token-ring company, went titsup

There I was shooting the breeze with an old mate. The conversation turned to why Madge Networks which I wrote about here went titsup. My analysis is that Madge Networks had a solution and decided to go out and find a problem. They deferred to more incorrect strategic technology choices. The truth of the matter is that when something goes titsup, its not because of one reason only, but a myriad of them all contributing to the negative consequence. There are the immediate or visual ones, which are underpinned by intermediate ones and finally after digging right down, there are the root causes. There is never a singular root cause for anything but I'll present my opinion and encourage everyone else to chip in. All of them together are more likely the reason the company went titsup. As far as technology brainfarts go there is no better example than Kodak . They invented the digital camera that killed them. However, they were so focused on milking people in their leg

Flawed "ITIL aligned"​ Incident Management

Many "ITIL aligned" service desk tools have flawed incident management. The reason is that incidents are logged with a time association and some related fields to type in some gobbledygook. The expanded incident life cycle is not enforced and as a result trending and problem management is not possible. Here is a fictitious log of an incident at PFS, a financial services company, which uses CGTSD, an “ITIL-aligned” service desk tool. Here is the log of an incident record from this system: Monday, 12 August: 09:03am (Bob, the service desk guy): Alice (customer in retail banking) phoned in. Logged an issue. Unable to assist over the phone (there goes our FCR), will escalate to second line. 09:04am (Bob, the service desk guy): Escalate the incident to Charles in second line support. 09:05am (Charles, technical support): Open incident. 09:05am (Charles, technical support): Delayed incident by 1 day. Tuesday, 13 August: 10:11am (Charles, technical support): Phoned Alice.

Updated: Articles by Ron Bartels published on iot for all

  These are articles that I published during the course of the past year on one of the popular international Internet of Things publishing sites, iot for all .  These are articles that I published during the course of the past year on one of the popular international Internet of Things publishing sites, iot for all . Improving Data Center Reliability With IoT Reliability and availability are essential to data centers. IoT can enable better issue tracking and data collection, leading to greater stability. Doing the Work Right in Data Centers With Checklists Data centers are complex. Modern economies rely upon their continuous operation. IoT solutions paired with this data center checklist can help! IoT Optimi