HACKER MEDICINE

I know you have been waiting for this and it’s finally here!  May 17th is Voice Telecommunication day! One of the most common subjects raised, year after year, is how do we secure our telecommunication channels?

In the past, where telephone calls were placed over a land line (PSTN), the only security issue was to worry about surveillance by the telephone company, and anyone who physically intercepted the line between you and the person you are talking to.

While there are hardware devices and actual crypto-phones that can be used to safeguard your conversation, the devices come at a high price and with the move to mobile and internet communication, the effort & costs involved to install can be considered unnecessary.

The advance in telecommunication networks and the Internet have made communicating easier and more cost effective, but unfortunately have also made the interception of calls more rampant than it has ever been. Without taking extra steps to protect your privacy, every phone call is vulnerable to eavesdroppers.

If you’re using a mobile phone, your conversation is conducted over a broadcast channel, which is easier to intercept than a physical line. There are numerous protocols involved in mobile technology with the most common being GSM.

One thing that makes GSM special is its call encryption capability: it is designed to encrypt calls in between the handset and the local tower. Your GSM SIM card stores an encryption key, which is authenticated by your service provider (who has a copy of your key), at the nearest tower. The main problem with GSM is that the tower doesn’t check back, which means that anyone can create a ‘fake’ tower and intercept your call.

The GSM protocol dates back 30 years and the technology behind it, while still useful, is somewhat outdated. Fortunately Smart Phones support improved 3G or LTE standards, offering improved encryption and mutual authentication between your device and tower.

If you’re planning to deploy VoIP (Voice over Internet Protocol), or are already using it within your company, you firstly need to ensure that the data network you are using is secure. VoIP is vulnerable to all of the intrinsic security problems associated with IP and because VoIP transmits digitized voice as a stream of data, there is a risk of theft of private information by a hacker.

There are many technologies, hardware and software involved in a VoIP system (depending on your requirements), such as

• IP Phones- the end points that create and receive calls
• Communication server/router – responsible for provisioning, monitoring & administering
• Voice/Media Gateways  – contains protocols that interconnect your VoIP system and facilitate calls between IP and analogue

Ensuring that they are secure is critical to keeping your network safe.

VoIP uses the Session Initiation Protocol (SIP) and the Real-time Transport Protocol (RTP) for call signaling and voice-message delivery, these protocols do not encrypt the data

Installing a Symantec SSL certificate on your VoIP server greatly enhances the security by encrypting the signals and securing the voice streams between your devices, preventing MITM (Man in the Middle) attacks and other compromises.

Secure your communications with a Symantec Premium SSL certificates and implement an additional layer of protection with its free malware and vulnerability scanning services.

Frequent scans of your server will help protect your networks from unwanted intrusions and help you proactively mitigate vulnerabilities.

In addition to the Malware and Vulnerability services that Symantec Premium SSL certificates offer, it also includes a free an ECC (Elliptic Curve Cryptography) certificate alternative at no additional cost. ECC certificates provide stronger security and increased server performance due to the shorter key lengths (e.g. 256 bit ECC key provides the same level of security as 3,072 RSA key). It also reduces computational overhead on the server’s resources. Enjoy the flexibility of being able to use a single SSL certificate that can secure multiple domain names by simply adding them onto the same certificate. These types of certificates are known as SAN certificates or Unified Communications (UC) certificates and are commonly used with Microsoft server products (MS Exchange Server, MS Lync server etc.).

Recently, we read about lots of SSL/TLS-related vulnerabilities found in mobile apps, which should come as no surprise. We were warned about this back in 2012 (see my previous blog). More warnings came in 2014 from CERT and FireEye. The Open Web Application Security Project (OWASP) listed “insufficient transport layer protection” as number three in its top 10 list of mobile security problems of 2014.

One recent study found that thousands of mobile apps still used an old version of the OpenSSL library that was vulnerable to the FREAK attack. A similar problem was revealed by the creators of a popular mobile networking library called AFNetworking, when they disclosed a serious bug in their library that bypassed all SSL/TLS security checks. Although this bug and the one in OpenSSL were quickly corrected, thousands of mobile apps remain vulnerable until their developers recompile with the fixed version of AFNetworking or OpenSSL, and users upgrade to the fixed version of each app. Because these bugs were in application libraries and not in the operating system, phone vendors cannot automatically apply a patch. Given the slow rate at which users upgrade mobile apps, these vulnerable apps are likely to be with us for a long time.

Failure to properly write and test SSL/TLS-related code might be due to ignorance or an assumption that the platform or library will “get it right”.  Sometimes SSL/TLS checks are disabled during development and debugging. App creators intend to re-enable the checks before the app is shipped, but they forget. That’s apparently what happened with Fandango and Credit Karma, who were cited last year by the FTC for SSL/TLS failures in their mobile apps.

Developers don’t have to use blind faith; some good tools are now available for testing how an app works in the presence of a Man-in-the-Middle (MITM) like CERT’s Tapioca.

In addition to the SSL/TLS certificate validation tests described in the white paper linked by my earlier blog, developers might also consider Public Key Pinning, defined in a relatively new RFC from the Web Security working group at the Internet Engineering Task Force (IETF). Developers need to apply caution, however, since one study pointed out the difficulty of building it correctly and the consequences of mistakes.