Threatpost for B2B

Syndicate content
The First Stop For Security News
Updated: 21 hours 35 min ago

Threatpost News Wrap, April 11, 2014

Fri, 04/11/2014 - 12:06

Dennis Fisher and Mike Mimoso discuss–what else–the OpenSSL heart bleed vulnerability and the doings at the Source Boston conference this week.

http://threatpost.com/files/2014/04/digital_underground_1491.mp3

BlackBerry, Cisco Products Vulnerable to OpenSSL Bug

Fri, 04/11/2014 - 07:37

Vendors are continuing to check their products for potential effects from the OpenSSL heartbleed vulnerability, and both Cisco and BlackBerry have found that a variety of their products contain a vulnerable version of the software.

BlackBerry on Thursday said that several of its software products are vulnerable to the OpenSSL bug, but that its phones and devices are not affected. The company said its BBM for iOS and Android, Secure Workspace for iOS and Android and BlackBerry Link for Windows and OS X all are vulnerable to the OpenSSL flaw.

“BlackBerry is currently investigating the customer  impact of the recently announced OpenSSL vulnerability. BlackBerry customers can rest assured that while BlackBerry continues to investigate, we have determined that BlackBerry smartphones, BlackBerry Enterprise Server 5 and BlackBerry Enterprise Service 10 are not affected and are fully protected from the OpenSSL issue. A list of known affected and unaffected products is supplied in this notice, and may be updated as we complete our investigation,” the company’s advisory says.

Meanwhile, the list of Cisco products affected by the heartbleed vulnerability is much longer.

The company said in its advisory that many of its products, including its TelePresence Video Communications Server, WebEx Meetings Server, many of its Unified IP phones and several others, are vulnerable. Cisco also said that a far larger list of products are potentially vulnerable and are under investigation.

Cisco’s Sourcefire Vulnerability Research Team did some testing on the vulnerability and found that on vulnerable systems it could retrieve usernames, passwords and SSL certificates.

“To detect this vulnerability we use detection_filter (“threshold”) rules to detect too many inbound heartbeat requests, which would be indicative of someone trying to read arbitrary blocks of data. Since OpenSSL uses hardcoded values that normally result in a 61 byte heartbeat message size, we also use rules to detect outbound heartbeat responses that are significantly above this size. Note: you can’t simply compare the TLS record size with the heartbeat payload size since the heartbeat message (including the indicated payload size) is encrypted,” Brandon Stultz of Cisco wrote in a blog post.

 

Cyber Intelligence Asia 2014: CERTs and Industrial Security

Thu, 04/10/2014 - 20:47

In March I spoke at Cyber Intelligence Asia 2014, where CERTs from most Asians countries were presented.

The fact is that only a few CERTs are now dealing in some way with industrial security, ICS and SCADA matters. One of the best of those is CERT of Japan, which is doing a great job here, and Jack YS Lin provided a nice overview of their activities and experience. Japan has a national ICS Test Bed, somewhat similar to Idaho National Lab, and is the only country besides the US that has an ISASecure certification entity. However, not all Japanese CNIs (Critical National Infrastructures) or even Industrial Automation vendors are doing enough in the security space.

The other countries seem to me much less advanced than Japan in understanding the ICS security domain, its problems and pursuing country-wide enhancements.

During the conference, we discussed the government role in enhancing critical infrastructure protection, and found that it is not about putting more compliance toward the CNI operators (we all know that compliance is not security). Instead, it is more about educating, creating actionable awareness by using engaging techniques and tools so CNI operators will be involved in developing their own solutions for strengthening security.

My personal take is that the regulator’s role is mainly to do what business/market won’t do by itself. So in my opinion, the list includes (but surely not limited to):

  • Enhancing intelligence & law enforcement in the cyber space;

  • Following both short and long-term security strategies, targeted both for CNI operators and automation vendors;

  • Engaging CNI management in security decisions by raising awareness in tangible form, and not just developing cybersecurity frameworks;

  • Imposing the need to pass Cyber Resilience tests at ICS commissioning;

  • Including cyber security as a mandatory part of industrial safety/liability programs;

  • Investing in CNI professional trainings and certifications;

  • Creating ICS-CERTs, ICS honeypots and industrial cyber drills.

PS: and, as always, people at Cyber Intelligence Asia enjoyed practicing with the Kaspersky Industrial Protection Simulation. There were moderate results, compared with other security professionals we played with in north America and Europe. This might be correlated with a certain lack of understanding of ICS specifics as stated above. I hope, however, that the things will change sooner, than later.

Does your country have an ICS CERT or ICS activity in its CERT already? What’s working best in favor of Industrial Security in your area?

Cisco Patches Vulnerabilities, Looking Into Heartbleed Impact

Thu, 04/10/2014 - 16:32

Cisco patched four different vulnerabilities this week in one of its core operating systems and is now is beginning to look into the potential impact of this week’s Heartbleed vulnerability in at least 60 of its other products.

The patches, released yesterday, fix problems in the company’s Adaptive Security Appliance (ASA) software that could have led to privilege escalation, authentication bypass, and opened products running ASA to a denial of service attack. ASA is a family of security devices, firewalls and other apps.

If exploited, an attacker could combine the first two vulnerabilities – a Privilege Escalation vulnerability in its Adaptive Security Device Manager (ASDM) and a SSL VPN Privilege Escalation vulnerability – to gain administrative access to the affected system.

Another VPN bug, an authentication bypass vulnerability, could allow an attacker to access the internal network via SSL VPN.

The last and perhaps most serious bug affects ASA’s Session Initiation Protocol (SIP). Dug up by researchers from Trustwave’s SpiderLabs and Dell’s SecureWorks, the bug could allow an attacker to exhaust the system’s memory. If SIP’s inspection engine is enabled – and it is by default on systems – an attacker could send a  handcrafted packets to the system, make it unstable, force it to reload and trigger a denial of service (DoS) condition.

According to a security advisory the company posted Wednesday, a series of firewalls, routers and other Cisco appliances that run ASA are affected. The full list can be found here.

Cisco makes a point to note that on the whole, ASA is not one of the products it manufactures that is affected by this week’s much-buzzed-about OpenSSL Heartbleed vulnerability.

Cisco does acknowledge however that its ASDM product – which comes bundled with ASA – may be affected by the vulnerability. The company is now reportedly in the beginning stages of evaluating its entire product line to determine Heartbleed’s potential impact.

Ultimately however, when it comes to vulnerable software, it sounds as if it’s not going to be a “is it or isn’t it?” question but a “how many?” question.

In an advisory yesterday the company claimed that “multiple” Cisco products incorporate a version of the OpenSSL package that’s affected by Heartbleed, something that could “allow an unauthenticated, remote attacker to retrieve memory in chunks of 64 kilobytes from a connected client or server.”

In a list updated today, there are apparently only 25 or so products that are not affected by Heartbleed but 11 that definitely are. Cisco is still looking into an extensive list of remaining products, 60+ in all, that may or may not be affected. It eventually plans to remediate the issues by releasing updates, along with workarounds if possible, in the near future.

The internet-wide Heartbleed bug stems from the way OpenSSL handles heartbeat extensions for TLS and was disclosed Monday but now speculation is rampant that it may have been exploited as far back as last November.

Heartbleed: A Bug With A Past and A Future

Thu, 04/10/2014 - 15:16

Bruce Schneier stood on the Source Boston keynote stage yesterday and used the word “ginormous” to describe the severity of the OpenSSL heartbleed bug.

“My guess is that when heartbleed became public, the top 20 governments in the world started exploiting it immediately,” Schneier said.

That’s assuming, of course, that those top 20 governments didn’t already have heartbleed and haven’t been exploiting it all along. The vulnerability in OpenSSL is an Internet-wide bug, one that’s kept a lot of people busy the last two days patching servers, revoking certificates, updating new ones, and changing a whole lot of passwords. And as Schneier said, governments may be slow in adopting new technologies, but when they do, they generally have the resources to do it well.

So is it equally ginormously dangerous to think the NSA, the Chinese or take-your-pick hacktivist group hasn’t been exploiting heartbleed since close to the time it was introduced into OpenSSL on New Year’s Eve 2011?

Ars Technica reported yesterday that MediaMonks of the Netherlands had evidence of exploit attempts going back to last November. Electronic Frontier Foundation technology projects director Peter Eckersley said inbound packets to MediaMonks contained TCP payload bytes that match those used by a proof-of-concept exploit.

Eckersley said the source IP addresses for those bytes belong to a botnet that’s been recording Freenode and other IRC activity.

“This is an activity that makes a little more sense for intelligence agencies than for commercial or lifestyle malware developers,” Eckersley said.

The EFF is asking network operators to check logs not only for the IP addresses in question, but for the TCP payload.

“A lot of the narratives around heartbleed have viewed this bug through a worst-case lens, supposing that it might have been used for some time, and that there might be tricks to obtain private keys somewhat reliably with it,” Eckersley said. “At least the first half of that scenario is starting to look likely.”

Heartbleed is so dangerous not only because it’s everywhere OpenSSL 1.0.1 to 1.0.1f is deployed, but also because attacks leave no trace. Everyone must assume they’re compromised. As expert Dan Kaminsky wrote today: “It’s a significant change, to assume the worst has already occurred.”

Kaminsky’s comment appears in a wide-ranging article on heartbleed, and the most salient point is that while OpenSSL may be the most prevalent TLS library and stands to reason that it’s among the most coveted technologies for compromise by intelligence agencies, it’s run by only a handful of competent and undercompensated people. A Wall Street Journal article points out that OpenSSL Project which funds OpenSSL development received less than $1 million from donations and consulting contracts.

“We are building the most important technologies for the global economy on shockingly underfunded infrastructure,” Kaminsky said. “We are truly living through Code in the Age of Cholera.”

Johns Hopkins professor and crypto expert Matthew Green said OpenSSL supports more than 80 platforms and reviews code contributions and changes from numerous sources, all with a fairly impressive record of not falling down on itself until this week.

“Maybe in the midst of patching their servers,” Green wrote this week, “some of the big companies that use OpenSSL will think of tossing them some real no-strings-attached funding so they can keep doing their job,”

Google Adds Continuous Monitoring of Android Apps

Thu, 04/10/2014 - 14:41

Google is adding a new security feature to Android designed to scan installed apps on a device and ensure that they’re not acting maliciously or taking unwanted actions. The system is built on Google’s existing app-verification model, which warns users if there’s a potential problem with an app they’re installing.

The addition to Android’s security system is meant to augment the Bouncer tool that Google uses to scan apps in the Play store for malicious functionality. That feature has been in place since 2012 and has enabled the company to help stem the tide of malicious apps making their way into the app store and onto users’ devices. Bouncer looks for known malware and other malicious behavior.

Android also has a feature that will verify apps during installation and may block them or warn the user of a problem.

Now, Google is adding the ability for Android to monitor the behavior of apps while they’re on a device.

“Building on Verify apps, which already protects people when they’re installing apps outside of Google Play at the time of installation, we’re rolling out a new enhancement which will now continually check devices to make sure that all apps are behaving in a safe manner, even after installation. In the last year, the foundation of this service—Verify apps—has been used more than 4 billion times to check apps at the time of install. This enhancement will take that protection even further, using Android’s powerful app scanning system developed by the Android security and Safe Browsing teams,” Rich Cannings, an android security engineer, wrote in a blog post.

Most Android users likely haven’t seen the warnings that the Verify apps system throws, but Cannings said that the new system provides an extra meausre of defense against malicious apps. Researchers have found that developers will sometimes send updates to installed apps, adding malicious or otherwise unwanted functionality.

“Because potentially harmful applications are very rare, most people will never see a warning or any other indication that they have this additional layer of protection. But we do expect a small number of people to see warnings (which look similar to the existing Verify apps warnings) as a result of this new capability,” Cannings said.

What Have We Learned: OpenSSL Heartbleed Bug

Thu, 04/10/2014 - 12:19

There’s nothing the Internet loves more than a fat, juicy story that it can sink its sharpened, yellowing canines into. And for the security community, the OpenSSL heartbleed vulnerability has been the equivalent of a 72-ounce steak. But an Internet-breaking vulnerability like this one is no good unless we can learn something from it (or at least give it a clever hashtag).

So let’s have a look at what’s gone down in the last few days and see what lessons we can take from all this.

The Internet is brittle. Actually, this isn’t a new lesson. The people who think about these things for a living have been saying this for years, or decades, in some cases. But they’ve probably been too kind. The Internet is a fish shack in the Florida Keys propped up on stilts, and the constant battering from the waves and erosion of the sea floor are taking their toll. It’s sort of listing to one side and there’s some barnacles growing on the pilings, but it’s still standing. For now. The infrastructure that supports the Internet is fragile and it’s dependent upon a small handful of old protocols. And that kind of prey rarely escape the notice of predators for long.

The long-term effects may be silent but deadly. OpenSSL is everywhere. Everywhere. By some estimates, it’s implemented on about two-thirds of Web sites, large ones, small ones, in-between ones. A  good number of the owners of the sites that use OpenSSL likely have no idea that their sites are affected, because they rely on hosting providers. And let’s not forget about the untold number of embedded devices that may have OpenSSL implemented in their firmware. Those devices are much harder to locate, test and patch than a typical Web server is.The really bad news, though, is that we may not know the ultimate effect of this vulnerability for some time, as it’s difficult to know whether an attacker has exploited the bug on a given target. We may see data breaches months from now that involve an attack on the OpenSSL vulnerability. And it is also difficult to determine how many sites have patched their systems, without a massive scan.

Breaking crypto–don’t do that. There’s been no shortage of speculation about the possibility of the NSA having an unspecified capability to break an encryption system such as SSL. But much of what we’ve seen from the leaked documents has shown that the agency, like most attackers, relies on implementation flaws and vulnerabilities in the code. They don’t need to build a supercomputer in a cave in North Dakota to break a cryptosystem when they can rely on someone making a mistake and get the same result. Human error is much more common than the ability to break an encryption algorithm.

The disclosure debate is still a thing. Well, sort of. News of the OpenSSL vulnerability first appeared Monday when the OpenSSL Project posted an advisory with a short description of the problem. Quickly, the scope of the vulnerability began to sink in and researchers realized how many sites, systems and devices could be vulnerable. Then people began wondering why some companies and vendors apparently had early warning about the vulnerability and others didn’t get the same courtesy. That discussion went downhill rather quickly. Large-scale vulnerabilities like the OpenSSL bug, by their nature, make it almost impossible to warn every company, site owner or vendor that’s potentially affected. This isn’t a flaw in a product with four customers. It’s the whole Internet. Neel Mehta, the researcher who discovered the bug, reported it to OpenSSL, which produced a patch and alerted users. That’s how things should work.

Internet-wide bugs still happen. Vulnerabilities like this one are, thankfully, relatively rare. Major bugs in ubiquitous software happen on a regular basis (see: Web browsers). We’ve seen serious problems in Apache, the DNS system, Microsoft IIS and other software that run large parts of the Internet in the past, and they’ve caused major problems in some cases. The OpenSSL vulnerability has all the makings of that level of vulnerability, given the package’s ubiquity and the potential consequences of a successful exploit against it. We think of systems such as utilities, SCADA and others as critical infrastructure, but, as Dan Kaminsky points out in his essay on heartbleed, there is entirely separate class of software that qualifies for that description. And that’s where the big fish still lie. “The answer is that we need to take Matthew Green’s advice, start getting serious about figuring out what software has become Critical Infrastructure to the global economy, and dedicating genuine resources to supporting that code.  It took three years to find Heartbleed.  We have to move towards a model of No More Accidental Finds,” Kaminsky wrote.

Image from Flickr photos of Dorothy Finley

Ensnare Attack Detection Tool Hopes to Frustrate Hackers, Too

Thu, 04/10/2014 - 07:13

BOSTON – Two engineers from Netflix this week released to open source a security tool that detects attacks against web applications—and also reacts to those attacks with responses they hope will flummox a hacker to the point that he moves on to his next target.

The utility is called Ensnare and is available on Github. It is a Ruby on Rails gem plug-in and once added to a Web application, it will add steps to requests browsers make to a web application server that will quickly detect attacks, characterize them, and send responses back to the browser that range from error messages, to security alerts, to agonizing delays. What makes Ensnare noteworthy is that it’s customizable and doesn’t interject itself with legitimate site users and affect their experience.

“We wanted to build something that was easy to use, that you could get running on a real application in 15 minutes and does advanced response handling,” said Scott Behrens, a senior application security engineer at Netflix, during his talk Wednesday at Source Boston. “We wanted to make it extensible too so that you could contribute to the project. We hope to collect metrics, learn about attacks and use that data to extend Ensnare to be more effective.”

Behrens said Ensare sits alongside an application and examines requests looking for bad behavior such as SQL injection or cross-site scripting attempts, and logs those. It can also be configured in the application layer to set booby-traps, or honey traps as they call them, that will be triggered by malicious activities in areas where legitimate users would never browse.

Behrens’s colleague Andy Hoernecke said when those traps are triggered, customizable responses can be sent to the attacker’s browser based on the aggregate number of violations and their severity. Legitimate requests, in the meantime, aren’t subjected to this experience.

“You can modify the response that comes back from the server; you can send a 404 message or send a message that says ‘We know what you’re doing,” or send an alert to the security team,” Hoernecke said. “It can send a message to you and hopefully it’s enough to move you on to something else.”

The first step Ensnare takes is to check for violations in requests; it determines whether they are malicious by matching them to a signature, for example.

“Violations are bad behavior tracked over time and aggregated. They are triggered by things like bad paths or exploit strings in request,” Hoernecke said. “They’re based on a particular configuration and weighted.”

It then determines a threshold for the requestor, who is logged via IP address, session ID or user ID in a database.

“By aggregating all three, Ensnare is more robust,” Hoernecke said. “We can track things if an attacker is doing tricky stuff to get around our protections that are in place.”

Thresholds are established through a number of attributes, including the number of violations that have occurred and how long the user is put into a trap.

“This is powerful state handling. We can do a lot of things to get the attacker to go away such as confusing them, distracting them or slowing them down,” Hoernecke said.

For example, if a user racks up five violations, the threshold can be configured to delay by 20 percent the time it takes to make a request and delaying the response by as long as 15 to 20 seconds. If the number of violations climbs to 20, the attacker could see delays climb into minutes—all without affecting site performance for legitimate users.

“If an attacker is testing the site, and the site starts delaying or redirecting, it gets frustrating,” Hoernecke said. “The responses are techniques that prevent an attacker from being successful in finding vulnerabilities or attacking the site. We hope to slow them down, block them, alert them or even annoy them.”