Posts Tagged ‘myths’

Since posting our series on SSL myths, some people have asked how these SSL vulnerabilities apply to mobile phones. While mobile phones and other handheld devices are mistakenly considered relatively safe, this misnomer does not qualify as an SSL myth. It does, however, require addressing, as the consumerization of IT forces CIOs and network security architects to integrate these devices into the VPN structure.

Beyond the recent consumer-oriented, high profile hacks to celebrity address books, the danger to enterprises is being laid bare in a more subtle manner. In May 2011, Juniper Networks published a study that found risks to mobile phone security at an all time high, and cited a 400% rise in malware against the Android, for example. In 2008, critical mobile SSL VPN vulnerabilities were discovered by Christophe Vandeplas, as a laboratory example of the man-in- the-middle (MITM) exploit.

In mid-March 2011, after Comodo issued nine fraudulent certificates affecting several domains, Microsoft issued updates for its PC platforms to fix the vulnerabilities, but the company’s patch for Windows Phone 7 was  not immediately available. More details surrounding this attack were outlined in Myth 1. But clearly, the priority is not currently on the mobile platform, creating an undeniable threat.

We all know that employees’ use of Skype  whether for personal or business use is exploding. The service reported  an average of 145 million connected users per month in the fourth quarter of 2010, before the Facebook rollout of Skype-powered group video chat service to 750 million users worldwide by August  2011, or the Verizon 4G LTE mobile broadband network deal to integrate Skype on all phones took effect. Not to mention other Skype-empowered deals that have since emerged, like the OnStar Skype-enabled system on its GM cars.

Skype uses SSL and Advanced Encryption Standard (AES) hashed with the RSA security algorithm for its public key cryptography. The details of how this combination is dismantled as a security model are explained in Myth 3 and Myth 6 in our series on debunking SSL myths. Suffice it to say that Skype is not nearly as secure as people think. As we saw in Myth 5, the public key cryptography is susceptible to the infamous MITM attack. As a result of these revelations, Skype and Facebook users need to be very concerned about what they disclose in their personal and business conversations.

The net effect of attacks against the trust model for mobile certificates and use of Skype should leave CIOs and network security architects uneasy about SSL and using it to secure mobile devices and Skype within their network ecosystems. Employees are using them, and policies restricting mobile devices and Skype use are no longer effective or logical.

What do you think? Is Skype a secure communication channel for the enterprise?

For the final myth in our series isn’t just about SSL – it’s about security. The prevailing attitude at organizations – no matter the size – is that the responsibility for security falls in the court of someone with a job title related to security, like application security specialist, cyber security guru or chief security officer, and so forth.  As a result, the well-known SSL vulnerability announcements (and any security alert for that matter) are often overlooked and ignored by the development staff.

But in reality, when employees use SSL technology, as provided by their company’s VPN client vendor to remotely log in to use sensitive company resources, they should bear some responsibility for ensuring security. Yet, few of these employees ever realize that effective security should be everyone’s concern.

Of course, this mentality is not entirely the fault of employees. The companies themselves and their executive leadership are ultimately responsible for ensuring all personnel have adequate security training. Legal statutes and regulatory regimes in every industry require companies to create a culture of awareness and security knowledge through effective training programs. When organizations lack definitive security policies, this type of thinking is more pervasive.

But in today’s world, the stakes are far too high for a single department to shoulder the full responsibility for securing an organization. All employees, no matter where they sit in the organization, should have some degree of security training.


Copyright (c)

Today’s myth is about the security of thick-client SSL VPNs. Some believe that thick-client SSL VPNs are more secure than thin-client ones, but this is actually untrue. Thick client is defined as an application client that processes data in addition to rendering. An example of a thick client application can be a Visual Basic, JAVA or VB.NET application that communicates with a database. And as you might already know, all of these have are vulnerable to security gaps.

The risks observed in thick-client applications generally include information disclosures, unauthorized access, authentication bypass, application crashes, unauthorized, high privilege transactions or privilege escalations. With the single exception of cross-site scripting, the vulnerabilities of thick clients are the same as the Top 10 OWASP Vulnerabilities of Web Applications. So there you go, another myth gone the way of the 8-track.

One more myth to go…stay tuned.

Today’s SSL myth tackles the topic of RSA SecurID. The prevailing myth is that RSA SecurID provides a secure connection – but of course, this isn’t so.  The RSA SecurID token authentication system is a two-factor authentication method, which is the most common secure access method in the U.S. with 40 million users. The RSA SecurID token authentication method uses the RSA ACE Server, which is a clock synchronization key scheme. It works on a timing frequency that changes the token keys so that they never seem to be the same. The frequency and the seed key were both found on the RSA ACE Server, which was hacked by perpetrators on March 18, 2011.

Here is the way one inventor describes the scheme in his patent granted in 2008: “The pseudorandom token codes are only valid during a short time that they are displayed (e.g. 30 seconds). A hash function that generates the pseudo-random token code takes a current time and a secret key as inputs. The secret key is provided to the token by the manufacturer and then provided to the authentication server. ”

This scheme makes the authentication system very time sensitive. If an authentication server and
token have clocks that diverge, the system quickly breaks. Also, the security of the leading hash function has been called into question.” The inventor is referring to a detailed cryptanalysis study by Springer-Verlag, 2003. These researchers found that the block cipher at the heart of the RSA SecurID hash function can be broken in a few milliseconds using a 2003-vintage PC.  Once again, myth debunked.

Source: EMC Corporation