Research

First reported by Brian Krebs (as usual), security vendor Bit9 was compromised and used to infect their customers. But earlier today, Bit9 told a source for KrebsOnSecurity that their corporate networks had been breached by a cyberattack. According to the source, Bit9 said they’d received reports that some customers had discovered malware inside of their own Bit9-protected networks, malware that was digitally signed by Bit9’s own encryption keys. They posted more details on their site after notifying customers: In brief, here is what happened. Due to an operational oversight within Bit9, we failed to install our own product on a handful of computers within our network. As a result, a malicious third party was able to illegally gain temporary access to one of our digital code-signing certificates that they then used to illegitimately sign malware. There is no indication that this was the result of an issue with our product. Our investigation also shows that our product was not compromised. We simply did not follow the best practices we recommend to our customers by making certain our product was on all physical and virtual machines within Bit9. Our investigation indicates that only three customers were affected by the illegitimately signed malware. We are continuing to monitor the situation. While this is an incredibly small portion of our overall customer base, even a single customer being affected is clearly too many. No sh**. Bit9 is a whitelisting product. This sure is one way to get around it, especially since customers cannot block Bit9 signed binaries even if they want to (well, not using Bit9, at least). This could mean the attackers had good knowledge of the Bit9 product and then used the signed malware to only attack Bit9 customers. The scary part of this? Attackers were able to enumerate who was using Bit9 and target them. But this kind of tool should be hard to discover running in the first place, unless you are already in the front door. This enumeration could have been either before or after the attack on Bit9, and that’s a heck of an interesting question we probably won’t ever an answer to. This smells very similar to the Adobe code signing compromise back in September, except that was clearly far less targeted. Every security product adds to the attack surface. Every security vendor is now an extended attack surface for all their clients. This has happened before, and I suspect will only grow, as Jeremiah Grossman explained so well. All the security vendors now relishing the fall of a rival should instead poop their pants and check their own networks. Oh, and courtesy our very own Gattaca, let’s not forget this. Share:

Adobe just released a Flash update due to active exploitation on both Macs (yes, Macs) and Windows: Adobe is also aware of reports that CVE-2013-0634 is being exploited in the wild in attacks delivered via malicious Flash (SWF) content hosted on websites that target Flash Player in Firefox or Safari on the Macintosh platform, as well as attacks designed to trick Windows users into opening a Microsoft Word document delivered as an email attachment which contains malicious Flash (SWF) content. Instead of patching, do the following: Uninstall Flash from your computer (WIndows, Mac). Download Google Chrome. Profit! Use Chrome’s internal Flash sandbox, so you can uninstall Flash at the OS level. Not perfect, but much better than using Flash through other browsers and having it available on your system for things like those nasty embedded Word attachments. Share:

The PCI Security Standards Council released a Cloud Guidance (PDF) paper yesterday. Network World calls this Security standards council cuts through PCI cloud confusion. In some ways that’s true, but in several important areas it does the opposite. Here are a couple examples: SecaaS solutions not directly involved in storing, processing, or transmitting CHD may still be an integral part of the security of the CDE …the SecaaS functionality will need to be reviewed to verify that it is meeting the applicable requirements. … and … Segmentation on a cloud-computing infrastructure must provide an equivalent level of isolation as that achievable through physical network separation. Mechanisms to ensure appropriate isolation may be required at the network, operating system, and application layers; Which are both problematic because public cloud and SecaaS vendors won’t provide that level of access, and because the construction of the infrastructure cannot be audited in the same way in-house virtualization and private clouds can be. More to the point, under Logging and Audit Trails: CSPs should be able to segregate log data applicable for each client and provide it to each respective client for analysis without exposing log data from other clients. Additionally, the ability to maintain an accurate and complete audit trail may require logs from all levels of the infrastructure, requiring involvement from both the CSP and the client. And from the Hypervisor Access and Introspection section: introspection can provide the CSP with a level of real-time auditing of VM activity that may otherwise be unattainable. This can help the CSP to monitor for and detect suspicious activity within and between VMs. Additionally, introspection may facilitate cloud-efficient implementations of traditional security controls–for example, hypervisor-managed security functions such as malware protection, access controls, firewalling and intrusion detection between VMs. Good theory, but unfortunately with little basis in reality. Cloud providers, especially SaaS providers, don’t provide any such thing. They often can’t – log files in multi-tenant clouds aren’t normally segregated between client environments. Providing the log files to a client would leak information on other tenants. In many cases the cloud providers don’t provide customers any details about the underlying hypervisor – much less access. And there is no freakin’ way they would ever let an external auditor monitor hypervisor traffic through introspection. Have you ever tried negotiating with a vending machine? It’s like that. Put in your dollar, get a soda. You can talk to the vending machine all you want – ask for a ham sandwich if you like, but you will just be disappointed. It’s not going to talk back. It’s not going to negotiate. It’s self service to the mass market. In the vast majority of cases you simply cannot get this level of access from a public cloud provider. You can’t even negotiate for it. My guess is that the document was drafted by a committee, and some of the members of that committee don’t actually have any exposure to cloud computing it does not offer real-world advice. It appears to be guidance for private cloud or fully virtualized om-premise computing. Granted, this is not unique to the PCI Council – early versions of the Cloud Security Alliance recommendations had similar flaws as well. But this is a serious problem because the people who most need PCI guidance are least capable of distinguishing great ideas from total BS. And lest you think I regard the document as all bad, it’s not. The section on Data Encryption and Cryptographic Key Management is dead on-target. The issue will be ensuring that you have full control over both the encryption keys and the key management facility. And the guidance does a good job of advising people on getting clear and specific documentation on how data is handled, SLAs, and Incident Response. This is a really good guide for private cloud and on-premise virtualization. But I’m skeptical that you could ever use this guidance for public cloud infrastructure. If you must, look for providers who have certified themselves as PCI compliant – they take some of the burden off you. Share:

Evidently there aren’t any interesting software companies to buy, so Oracle just dropped a cool $2B (as in Billion, sports fans) on Acme Packet. These guys build session border controllers (SBC), VoIP telecom gear. As Andy Abramson says: This is an interesting grab by one of the tech world’s true giants because it sqaurely puts Oracle into a game where they begin to compete with the giants of telecom, many of whom run Oracle software to drive things including SBC’s, media gateways and firewall technology that’s sold. This is an interesting turn of events. Obviously Oracle dipped their feet into the hardware waters when they put Sun Microsystems out of its misery a few years back. But this is different. This isn’t directly related to their existing businesses, but instead subsuming a key technology for one of their major customer segments: telecom carriers. So how long will it be before Oracle decides they want a security technology? They have some identity management stuff – actually a bunch of it. Both their own and stuff they inherited from Sun. They don’t currently have security hardware or even core security software. But since security is important to pretty much every large enterprise segment Oracle plays in, you have to figure they’ll make a move into the market at some point. Clearly money isn’t an issue for these guys, so paying up for a high multiple security player seems within reach. Yes, I’m throwing crap against the wall. But the security investment bankers must be licking their chops thinking about another deep-pocketed buyer entering the fray. Photo credit: “straws” originally uploaded by penguincakes Share: