VENOM (Virtualized Environment Neglected Operations Manipulation)

If you are currently utilizing Xen, KVM or QEMU virtualization products you need to apply patches. VMware and Microsoft Hyper-V virtualization products are not affected.

This blog post was updated to reflect the now-assigned CVSS score of 7.7 (High).

A security researcher from Crowdstrike has discovered a software flaw in the virtual floppy drive code in QEMU’s virtual floppy disk controller.  This vulnerable code is present by default on Windows, Linux and OSX hosts running the virtualization products Xen, KVM (Kernel-Based Virtualization not Keyboard-Video-Mouse) and the QEMU client whether or not virtual floppy drives are used. This vulnerability has been present since 2004 and affects both x86 and x86-64 guest instances.  In order to exploit this vulnerability, an attacker must have gained access to the virtual machine guest.  This is not remotely exploitable, instead an attacker would have to first compromise the guest virtual machine.

If successfully exploited, this vulnerability could allow an attacker to escape from the virtual environment and execute code on the host system.  Theoretically, a successful attack could also allow access to other systems on the host’s network. 

At the time of this advisory, there have been no reports of successful attacks and there is no publicly available exploit code.  Vendors have begun releasing patches for this.  Please see the links section below.

This vulnerability has been assigned a 7.7 (High) CVSS score.  In this case a 7.7 CVSS score means that the impact of the vulnerability if high, however, the exploitability is much lower due to not being remotely exploitable.  Learn more at https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3456 and https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3456.
CVSS, the Common Vulnerability Scoring System, is an industry standard mechanism used to assess the severity of computer security vulnerabilities and works with a scale from 1 -10. More information about the CVSS system can be found at https://www.first.org/cvss/faq.

Next Steps

• How do I know if it affects us?

  • If you are using one of the affected products (At this time the known affected products are Xen, QEMU and KVM)
  • Many cloud based providers use virtualization products and may be affected.  For customers using such services, check with your vendor.  For example, Amazon has stated that AWS customers are not vulnerable http://aws.amazon.com/security/security-bulletins/XSA_Security_Advisory_CVE_2015_3456/

• How serious is this vulnerability?

  • This issue has been receiving a good deal of attention and is potentially serious. There is no known exploit code available at this time, however, the vulnerable code sections have been identified so an exploit could be published soon.
  • Since vendors are releasing patches quickly and because this is not remotely exploitable, NWG considers this a high severity vulnerability as opposed to a critical vulnerability.

• What should we do next?

  • Apply patches as they become available (see links below).
  • Check with your cloud provider (if applicable) to determine if they have applied the appropriate patches.
  • If you have any of the affected products and have questions regarding next steps please contact us using the contact information below.
  • As details regarding this vulnerability emerge, NWG will also offer Vulnerability Management customers proactive scanning to determine if they are affected by this issue.

Links

• Xen Advisory (contains patches)
  http://xenbits.xen.org/xsa/advisory-133.html
• About the vulnerability
  http://venom.crowdstrike.com/
  http://www.forbes.com/sites/thomasbrewster/2015/05/13/venom-vulnerabilit...
• Notice from Amazon
  http://aws.amazon.com/security/security-bulletins/XSA_Security_Advisory_...
• List of vulnerable Linux distributions
  http://www.cyberciti.biz/faq/cve-2015-3456-patch-venom-on-debian-ubuntu-fedora-centos-rhel-linux/
• https://blog.linode.com/2015/05/13/venom-cve-2015-3456-vulnerability-and-linode/
• Citrix security advisory
  http://support.citrix.com/article/CTX201078
• Redhat blog post
  https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitten/
• FireEye Vulnerability Summary
  https://www.fireeye.com/content/dam/fireeye-www/support/pdfs/fireeye-venom-vulnerability.pdf
• NetWorks Group updates regarding this vulnerability
  https://www.networksgroup.com/blog

If you have questions regarding this notice or about this vulnerability please call us at 734-827-1400, option 3 or email support@networksgroup.com.   

In March 2015, the PCI Council released their Information Supplement for Penetration Testing Guidance.  This is a fantastic move as previous guidelines were centered on the completion of penetration tests and left the methodology for completing those up to the auditor.  With this guidance in place, we now have a clear definition to what qualifies as a penetration test in the eyes of the Council.  There isn’t a need to rehash the document for you here, and I encourage everyone to read it.  I would like to focus on a few key highlights that I’m happy to see added.

In section 2.2, scope is explained in depth.  Traditionally, the cardholder data environment (CDE) has been the primary scope for penetration testers.  Companies like NetWorks Group would educate clients on the need to expand testing to include systems that could impact the CDE.  We are now fortunate enough to have it spelled out in the PCI guidance.

“To be considered out of scope for PCI DSS, a system component must be isolated (segmented) from the CDE, such that even if the out of scope system component was compromised it could not impact the security of the CDE. Therefore, the penetration test may include systems not directly related to the processing, transmission or storage of cardholder data to ensure these assets, if compromised, could not impact the security of the CDE.”

This is great news for penetration testers in the community.  If we can identify that there is a threat to the CDE residing in adjacent networks then we can target them as part of PCI penetration tests.  From the client side, this gives you a very real picture of the threat that your user networks, or other adjacent networks, provide to your card holder data.

In section 4.2.5, they cover the topic of “post-exploitation”.  A thorough and well define post exploitation process has been something NetWorks Group has long incorporated into their penetration testing process.  It refers to the actions taken after the initial compromise of a system or device.  Often we come into environments where penetration tests have been previously conducted and they stop at the device itself without evaluating the value of that device inside of the environment or as it relates to the CDE.

The PCI counsel has included VERY helpful charts in the guidance that I think business who are evaluating their environment will find the most helpful.  The first one is in section 2.1 which helps organizations distinguish between vulnerability scans and penetration tests.  NetWorks Group has assisted numerous organizations understand the differences between these two.  Unfortunately, we often times end up helping them after they have received what appears to be a vulnerability report when they actually paid for a penetration test.

Section 5.4 helps organizations to evaluate the penetration testing reports they receive from vendors.  I personally love this about the new guidance.  As a penetration tester, the “deliverable” that we present to the client is the most important part about our business.  It needs to contain information that is most relevant to the client to help them assess the risk an attacker poses to their environment.  The reports that NetWorks Group puts out have been long admired by auditors to meet the criteria they look for when auditing the organizations.  This new section now gives folks receiving penetration testing reports from other companies a yard stick to measure the quality of the reports they are getting.

In the end, I feel this is a great step forward for PCI guidance and NetWorks Group has been in line with these changes for some time now.  This should absolutely raise the bar for other companies and force them to give the quality penetration tests that merchants have needed for a very long time.

Last week, I wrote an article for a popular online journal regarding the similarities between cyber security agility and militant warfare.  It was an exhaustive piece, and geared toward high level strategic planning (see full article here: http://redteamjournal.com/2015/01/red-teams-scale-terrorism-cybersecurity-agility/)

I want to write a separate article here that talks about how to actually apply the concept of “red teams” in your enterprise.  First, and foremost, red teaming for cyber security refers to the concept of a small team of hackers reviewing an organization to determine if they can gain access to critical assets.  This may not sound much different than a penetration test, but one crucial piece is almost non-existent in a red team exercise:  scope.  A red team will utilize a web application, mobile platform, physical, social engineer, and network tester as part of a team whose goal is to profile the organization and gain access.

Let me be the first to say that I am not stating that every organization needs to hire or employ a red team.  As with any security assessment, the right amount of intelligence gathering must be performed to determine if your organization is even a potential target for a red team test.  I want to highlight how to help determine if a red team test is right for you.

First thing that every organization should determine is who is targeting them.  This is a critical and often overlooked step.  Organizations will sometimes default to the answer of “everyone” which is not always the case.  This is often time referred to as “threat intelligence” and involves reviewing several non-technical aspects of the organization.  Threat intelligence is a beast in itself, and outside the scope of this conversation.  Some easy questions that you can ask yourself are:

• What is valuable in my organization?
  • Do we influence financial market places?
  • Do we provide technical details on any market spaces?
  • Do we employ personnel whose knowledge can be used against us?
• Does my organization affect other organizations?
  • Do we provide strategic, technical, or monetary advantages for larger corporations or conglomerates?
  • Do we have technical connections (VPNs or other secure connections) or other vendors who may have ties with other corporations?
• Is our organization a political ally/enemy of someone?
  • Would success or failure of the enterprise or its partners provide positive or negative influence over the regional or global landscape?

As you can see these are not overly technical questions, but they can help you to evaluate the types of threats that could face your organization.  After we have performed our own threat intelligence, we can then look to determine the “Levels of Hackers” that might be interested in our organization.  If you are unfamiliar with our levels or hackers, then I encourage you to read my previous article.  In a nutshell, Level 1 represents our least sophisticated hackers, while Level 3 represents our most sophisticated hackers.  Believe it or not, red teams can be employed by all levels of hackers in our model.  Organizations that are not as fluent in their security posture as they should be can easily find themselves victim to very unsophisticated attacks but hacker groups that do not possess the operation doctrine employed by cybercriminal or state sponsored attackers.  However, the tactics employed by these attackers can resemble red teaming activities.

After your organization has determined its threat, and the types of attacker that could be targeting it, finally it’s time to allow your security team to go to work.  This is the easiest part.  Your security teams should be employed with the people and resources they need to conduct testing in the same fashion your attackers are.  As an organization, you should strive to allow your testing entity the freedom of movement throughout your organization as they see fit.  If the organization attempts to limit the scope of a red team test, you run the risk of negatively isolating segments of your organization that pose the greatest risk.

If you consistently outsource your testing to a third party (such as NetWorks Group), then that organization has to do steps 1 and 2 above before they test your organization, and the good ones will.  After all, the success of the red team helps to push organizational security farther.

Whether you are a veteran security executive who has received hundreds of penetration testing reports, or a part-time security manager whose primary roles lay in traditional business management, it can be difficult to decipher the encrypted text held within some penetration testing reports.  The problem exists because there is not a standard for penetration testing reporting inside of the industry.  I’ve seen literary works that range anywhere from Dr. Seuss to William Shakespeare.  I have peer reviewed reports for associates whose bad grammar could make a first grader wince.  The goal here is to identify what makes a penetration test report good, how to interpret the results, and finally how to put them to use in your strategic planning to improve organizational security.

There are many frameworks for the penetration testing report, and this is not a discussion of which ones are best.  However, an important conversation to have is what elements make a report valuable to the people reading it.  As penetration testers, we have to remember we could potentially have every level of an organization reading our reports, from the tactical level where technicians will fix our findings to the leadership level where they need to take responsibility for the security of their organization.  First and foremost, the report you receive should tell you the impact a breach on your network would cause.  We, as penetration testers, MUST speak to the business impact a breach would have on an organization.  A well-conducted penetration test, that simulates an attackers attempt to breach your network, should tell you the data and information that was successfully compromised.  This information should be directly relevant to your business.  For example, if your organization stores payment card information then this should indicate what, if any, payment card data was compromised.  This should also include how many systems were compromised as part of the penetration test.

A second, critical, section of any penetration report should be the very detailed “kill chain” on how your organization was compromised, how the data was accessed, and how that information was used to perpetuate additional compromises.  This section can be more tactical and should speak to the organizations technicians who would be tasked with remediating the compromise.  This section should be riddled with screenshots used as validation of the compromise.  We oftentimes joke about how all executives can understand are pictures.  However, a far more practical reason for showing pictures in this section is to illustrate the compromise so that technicians at the tactical level cannot “snowball” leadership with confusing jargon.

The two elements outlined above represent what I feel are the “must haves” to a good penetration testing report.  It is important to point out that other elements may be included, and you should weigh them equally for how they will directly help your organization.  It is also important to remember that a penetration test is a “demonstration of exploitability”.  This means that if you receive a penetration test report that lists your vulnerabilities, but doesn’t have any demonstrative examples or validation you should challenge those who conducted your penetration test.

Now that you have your penetration testing report, you need to be able to execute on your organizations strategic goals for security, using those results as direction.  Remember, a penetration test is a “demonstration of exploitability” and you should utilize the results that come out of a test to show the immediate need for security changes.  Well rounded organizations that are conducting regular vulnerability management, and patching, should consider those security measures as the “good hygiene” efforts of security.  The successful results of a penetration test should immediately highlight security issues that fall outside the identification capabilities of your vulnerability scanner, or assist with identifying issues in your current vulnerability management process.  This helps you to prioritize the penetration test results ahead of your normally identified vulnerabilities.

Penetration testing can be an integral part of your organizations security strategy when the results are presented in a way that helps your organization visualize and prioritize.  Never be afraid to challenge the results of your penetration testing vendor if you do not understand or feel the information is presented in a way that helps your organization strategically.  You paid for this information, and should be able to utilize it.