Reverse Heartbleed – Protect Vulnerable Mobile Clients

There’s no question that the Heartbleed vulnerability introduced a major vector of risk to companies around the world. Given that an attacker could exploit Internet-facing servers and access privileged information, it is clear why these measures were necessary.

However, with the widespread coverage focusing on the exploitation of web sites, one might be misled into thinking that Heartbleed is solely a server security problem. It’s not. OpenSSL is widely used in a variety of products, and it’s not limited to web servers. In fact, it’s also used as the cryptographic library for clients connecting to a web server, which introduces another set of security issues. Clients that are using affected versions of OpenSSL are vulnerable to reverse-Heartbleed, which reveals the contents of memory on the client rather than the server.

In this scenario, the attacker would set up a malicious web server that would be used to send the exploit against the Heartbleed vulnerability to the client, rather than the other way around. Security teams need to think about a different set of problems, namely how to intercept the exploit while patching applications and operating systems on endpoints and mobile devices.

The attack surface is quite large with these conditions, because OpenSSL is used fairly extensively in many different types of products. With respect to mobile devices, the good news is that Heartbleed does not affect iOS itself, and does not affect the majority of Android versions. The bad news, however, is that Android 4.1.1 is vulnerable, and depending on which set of statistics that you look at, it could affect anywhere from 10% to 34% of Android mobile devices in use today.

Endpoints and mobile devices are considerably different in terms of rolling out patches and updates. Managed endpoints typically have updates pushed out through system management software, and even unmanaged endpoints often receive updates by the software publisher to protect the public at large. However, mobile devices are not updated as frequently and there are questions about whether some of the affected devices will ever be patched, because the device manufacturer is typically responsible for pushing out the patch, and may not be actively doing so.

Heartbleed exposes a set of mobile device security challenges that many organizations had not previously considered: How do you safely provide access to applications using mobile devices that may not be (and may never be) patched?

Determine Platform Use

One of the biggest problems that companies face right now is that they have no idea what types of devices are being used, especially in light of BYOD. Are people using older operating systems that are vulnerable?  Being able to firmly establish which devices are being used with company applications, and the ability to exclude ones that are not properly secure, is the first step to dealing with the problem of platform fragmentation and the availability of patches.

Manage Mobile Devices

Managing the mobile device is a critical step for protecting it and understanding what applications are in use. Gauging the use of applications is necessary in order to take the proper steps to secure the traffic from potential threats.

Protect Users with Threat Prevention

Palo Alto Networks next-generation security platform identifies exploits, harmful websites, malware and mobile exploits. GlobalProtect can be used to automatically establish a tunnel to the next-generation security platform and keep users behind a gateway for threat prevention.

Use Device Criteria for Policy

Organizations may want to classify specific mobile devices for use in their organization. For example, if the company decides to phase out the use of older operating systems, the organization might establish policies that govern which platforms can be used with corporate applications.

source: http://researchcenter.paloaltonetworks.com/2014/04/protecting-vulnerable-clients-from-reverse-heartbleed/#more-5331

Advertisement

Gartnet Report on Enterprise Network Firewalls – Q1-2014

http://www.gartner.com/technology/reprints.do?id=1-1T607HL&ct=140415&st=sb

OpenID, OAuth Vulnerability Affects Facebook, Google, and Others

Account hijacking is all too common in social networking, but a wider-spread problem has affected almost all major OAuth 2.0 and OpenID providers, such as Facebook, Google, Yahoo, LinkedIn, Microsoft, GitHub, QQ, Taobao, Weibo, VK, Mail.Ru and Sohu, have been affected by a serious covert redirect vulnerability.

The vulnerability could lead to open redirect attacks to both clients and providers of OAuth 2.0 or OpenID, according to Jing Wang, a doctorate student in mathematics at the Nanyang Technological University in Singapore.

“For OAuth 2.0, these attacks might jeopardize the token of the site users, which could be used to access user information,” he wrote in a blog. “In the case of Facebook, the information could include the basic ones, such as email address, age, locale, work history, etc. If the token has greater privilege (the user needs to consent in the first place though), the attacker could obtain more sensitive information, such as mailbox, friends list and online presence, and even operate the account on the user’s behalf.”

For OpenID, the attackers may get user’s information directly, Jing said.

“Compounded by the large number of companies involved, this vulnerability could lead to huge consequences if left unresolved,” he said.

Because the vulnerability is opened by way of third-party applications, fixing the vulnerability presents a conundrum: Who should be responsible? “If all the third-party applications strictly adhere to using a whitelist, then there would be no room for attacks,” he said. “However, in the real world, a large number of third-party applications do not do this due to various reasons. This makes the systems based on OAuth 2.0 or OpenID highly vulnerable.”

Facebook concurred, Jing said, telling him that “Short of forcing every single application on the platform to use a whitelist, which isn’t something that can be accomplished in the short term, do you have any recommendations on actions we can take here?”

Jing responded: “In my reply, I suggested, ‘For any URL, it has a particular value &h. If the URL is changed, there is no permission any more. That means the modified URL will not get any &h, Because it is illegal.”

Facebook replied: “As you mentioned, that’s how our Linkshim system works. As I said, that doesn’t seem to be a feasible solution for an OAuth endpoint where the URL needs to be provided by a third-party site to arbitrary random users.”

LinkedIn is taking a whitelist approach, and has asked its developers to register their applications’ redirect URLs with the site. “By confirming that the redirect_uri in your OAuth 2 authorization request matches a URL you’ve provided to us in advance, we are better able to protect you from people who may try to abuse your API key,” it wrote in a blog.

Other tech giants responded in varying ways, Jing said: “Google said that it is aware of the problem and are tracking it at the moment. Microsoft answered after they did an investigation and concluded that the vulnerability exists in the domain of a third-party, different from the one reported by me (login.live.com). They recommended me to report the issue to the third-party instead,” Jing said. “Weibo said that they thought this vulnerability was serious and would ask their developers to deal with this situation as soon as possible. Taobao closed my report without providing a reason. Yahoo did not reply.”

“They have little incentive to fix the problem,” Jing wrote. “One concern is the cost and the other is that in their view, the host company is responsible for making the attacks appear more credible; therefore, it is not solely their problem.”

PayPal is however not affected, it said in an online statement. “We have carefully investigated this situation and can tell you that this vulnerability has no impact on PayPal and your PayPal accounts remain secure,” James Barrese, the CTO of PayPal said. The payments company has “engineered additional security measures” against the OAuth2.0/OpenID vulnerability, he said.

http://www.infosecurity-magazine.com/view/38272/openid-oauth-vulnerability-affects-facebook-google-and-others/

 

Heartbleed Bug – Biggest flaw in Internet history

Heartbleed appears to be one of the biggest flaws in the Internet’s history, affecting the basic security of as many as two-thirds of the world’s websites. Its discovery and the creation of a fix by researchers prompted consumers to change their passwords, the Canadian government to suspend electronic tax filing and computer companies including Cisco Systems Inc. to Juniper Networks Inc. to provide patches for their systems.

It is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).

The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.

Immediately change your password if you are using any of the listed services http://mashable.com/2014/04/09/heartbleed-bug-websites-affected/, popular affected websites include facebook, linkedin, google (gmail), yahoo etc., further details about the bug can be fount at http://www.heartbleed.com.

Top Security Techniques That Work For The Masters

Author: Robert Siciliano CEO of IDTheftSecurity.com

Banks know security just about better than anyone. Find out what they can teach you about safeguarding your small business.

Security is a journey, not a destination. This is a security industry axiom that means we can strive for security, and by making this effort, we can put ourselves on a path to security. But while we may achieve a relative degree of security, our businesses will never be 100 percent secure—the destination we all strive for. Even Fort Knox, the White House and the New York Stock Exchange are vulnerable.

But that doesn’t mean we shouldn’t strive to reach our destination. In order to protect our businesses, we can apply strategies that significantly reduce our risk level. One of the best security techniques is layering. Layers of security make a criminal’s job more difficult, as they are forced to address all the vulnerabilities in our business.

Helen Keller once said, “Security is an illusion; life is either a daring adventure or nothing at all.” Her quote has significance, although it’s not entirely accurate. That’s because security is part illusion and part theater. The illusion, like a magic act, seems believable in many cases.

Security theater, on the other hand, refers to security intended to provide a sense of security while not entirely improving it. The theater gives the illusion of impact. Both play a role in deterring criminals, but neither can provide 100 percent security, as complete security is unattainable. Hence, security is a journey, not a destination.

Banks know security, both the illusion and the theater. They have to, because robbers target these buildings daily. Because banks want to promote a friendly and inviting environment, consumers are mostly oblivious to the various layers of security that financial institutions utilize to protect their bank accounts. And that’s not a bad model to follow.

What Banks Know About Security

Banks have multiple layers of security. The perimeter of most banks are often designed to include large windows, so passersby and law enforcement can easily see any problems occurring inside. The bank’s doors also have locks. There is, of course, an alarm system, which includes panic buttons, glass-break detectors and motion sensors. These are all layers, as are the security cameras, bulletproof glass and armed guards. Ideally, the tellers and members of management should have robbery-response training. Many banks also use dye packs or GPS devices to track stolen cash.

All banks have safes, because banks know that a well-constructed safe is the ultimate layer of security. A safe not only makes it extremely difficult for a bank robber to steal the bank’s money, but it also protects the cash in the event of a fire.

And then there are the multiple layers of computer security. The basics include antivirus, antispyware, antiphishing and firewalls. However, there are numerous additional layers of protection that monitor who is accessing data and why, and numerous detectors that look for red flags which indicate possible identity theft.

Banks also recognize that a simple username/password is insufficient, so they require their clients to adopt multifactor authentication. Multifactor authentication is generally something the user knows, such as a password or answers to knowledge-based questions, plus something the user has, such as a smart card, token or additional SMS password, and/or something the user is, such as identification through a biometric fingerprint, facial recognition, hand geometry or iris scan. In its simplest forms, multifactor authentication occurs when a website asks for a four-digit security code from a credit card or installs a cookie on your machine, or when a bank requires a client to add a second password to his or her account. Some institutions also offer or require a key fob that provides a changeable second password (a one-time password) to access accounts, or it might require a reply to a text message in order to approve a transaction.

Every layer of protection the bank adds is designed to make it harder for a criminal to get paid.

Consider a layered approach for your small-business security plan. Think about the current layers of business protection you have in place, and then consider how many more layers you might want to install to ensure a seamless customer experience and a security-minded culture.

Secuirty through Obscurity

Security through obscurity is an attempt to use secrecy of design or implementation to provide security. A system relying on security through obscurity may have theoretical or actual security vulnerabilities, but its owners or designers believe that if the flaws are not known, then attackers will be unlikely to find them.

It is analogous to a homeowner leaving the rear door open, because it cannot be seen by a would-be burglar.

Security through obscurity has never achieved engineering acceptance as an approach to securing a system, as it contradicts the principle of “keeping it simple”. The United States National Institute of Standards and Technology (NIST) specifically recommends against security through obscurity in more than one document. Quoting from one, “System security should not depend on the secrecy of the implementation or its components.”

A simple Example:

Suppose you have a vulnerable Web server, for example, that can be attacked over TCP port 80 using a public exploit. To close that particular vector, you can patch the Web server or you can turn it off; either action would completely stop this vector. You could partially stop the attack vector by using a firewall or IPsec to close port 80 to all but a few select computers. This wouldn’t completely block the attack vector, but it would significantly mitigate the problem.

Security by obscurity, on the other hand, involves taking some measure that does not stop the attack vector but merely conceals it. For example, you may decide to move the Web server to port 81 instead of 80 so only those who know where to find your Web server will be able to do so. Or so that argument goes. In reality, moving your Web server to port 81 stops only some attacks, and mostly just inconveniences the end user. A competent intruder would simply run a port scanner and a Web banner grabber against a large number of ports to discover Web servers on non-standard ports. As soon as he finds one, he can fire off the exploit against your server because you did not actually eliminate the attack vector, you merely (temporarily) obscured it.