Metasploit code on Github gives remote access to BigIP By Richard Chirgwin • Get more from this author Posted in Security, 13th June 2012 00:30 GMT Free whitepaper – Enabling Datacenter and Cloud Service Management for Mid-Tier Enterprises A vulnerability in F5 kit first announced in February may be in the wild, with code posted to Github purporting to be an exploit. The original advisory stated that vulnerable installations of F5’s BigIP and other systems allowed an attacker to log in as root, because the vulnerability exposed the device’s SSH private key. F5 responded earlier this month. Since it’s only seven days since F5 issued its advisory – and the patch – it’s likely that unpatched systems still exist. F5 describes the issue as “A platform-specific remote access vulnerability has been discovered that may allow a remote user to gain privileged access to affected systems using SSH. The vulnerability is caused by a configuration error, and is not the result of an underlying SSH defect.” Today, exploit code has been posted to Github. That code purports to gain remote access to some of the affected F5 systems – its BigIP devices. The vulnerability can be addressed either by users upgrading to a non-vulnerable version, or reconfiguring SSH access (instructions are provided at the F5 link). The Register has sought comment from F5. ®

MORE FROM GARTNER: Top 10 emerging infrastructure trends
To adapt to virtualized networks, some security vendors are coming up with software products they say are specialized for certain environments, such as VMware. But it was surprising to hear McAfee in announcing its latest antivirus software, Management for Optimized Virtual Environments (MOVE) 2.5, which support the VMware vShield security technology, which calls for an agentless approach, complain that the agentless approach is inadequate. They’d like VMware to change their views on agentless for vShield, saying agent-based is better. There seems to be industry tension over that right now. What’s this all about?
McAfee came out and said it’s not as good as running an agent inside the virtual machine (VM). And there’s some truth to this. Buffer overflow protection, memory protection — all the things they do inside, they can’t do that with agentless. They lose all behavior heuristics. They can open the file and close the file. With MOVE 2.5, McAfee adds the agentless process. But McAfee is supporting both agent and agentless, and it’s hypervisor-neutral.
So what’s the issue with running agent-based antivirus software and virtual machines?
It’s called “A/V storms,” and it creates new amounts of traffic. Suppose they’re all set to kick off at noon. You can set it as the admin, you say “randomize between 12 and 2.” It’s an answer, but not the best answer. Why do we keep scanning the same image and again? These VMware APIs let you scan it once. Kaspersky is supporting that but Symantec, not yet; they use a different architecture with Symantec Endpoint Protection 12.
VMware’s work with these vShield security APIs over the years seems to be a contentious process. VMware now seems inclined to work only with specific security vendors. What do you think about it?
VMware created the first set of APIs on their own without going to the vendors. But they did work directly with Trend Micro. What Trend and VMware have done with their model is innovative. For Trend, it worked out well. They closed a lot of deals. APIs by committee generally don’t work well. By focusing on a few vendors, they’ve been more successful. There are pros and cons to this agentless approach. There’s new or offline VM protection with improved resource utilization. On the “cons” side, it requires a hypervisor extension, it’s VMware-only and need licensing, it’s Windows only and not really “agentless,” and there’s only anti-malware scanning. You can’t do host-based intrusion prevention or behavior monitoring.

The vShield APIs give VMware a firewall capability. What’s the view now on use of physical and virtual firewalls for security purposes when a network is virtualized?
Today, people use separate interface cards for each workload. You trust VMware to separate memory but for network traffic, you send it out separately to physical firewalls. The next logical step is, why not just virtualize the firewall? The VMware firewall could do that. For basic segmentation, it works fine. Check Point, Juniper and Cisco also have virtual firewalls. The Check Point firewall does IPS, which VMware doesn’t do. VMware is partnering on that. In virtualization, this all means I’ve taken a security control and sucked it in. And the question is, who’s responsible for that? You have to maintain separation of duties. VMware has role-based access to do this. So does HyTrust. We don’t necessarily want that all in one person’s hands — the network is firewalled by the security administrator, the rest by the VMware administrator. But the future is hybrid, with some firewalls virtualized, some hardware. What’s held back Palo Alto Networks is they use a lot of proprietary hardware. The Palo Alto firewall is not virtualized today but it will be. [Editor’s note: Palo Alto confirms this, anticipating the fall time frame for public announcement.]
Ellen Messmer is senior editor at Network World, an IDG publication and website, where she covers news and technology trends related to information security.
Read more about security in Network World’s Security section.