Skip to content

Security

Azure Defender for DevOps – First Impressions

The recent batch of high profile security incidents at various companies in Australia highlights the need for appropriate security measures across all components of an organisation’s infrastructure. Defender for DevOps is a new functional addon (in preview) to Defender for Cloud. It provides security functionality for your code respositories and associated components.

Setup

When navigating to the Defender for Cloud interface, a new option will appear under the “Cloud Security” heading.

Image

Once we click on this, we are presented with an intro splash page with steps to getting started. The first step is to connect to the environments. Both Azure DevOps and Github repositories are supported environments.

Developing a Bicep Validation Pipeline

Azure’s Bicep is Microsoft’s newer format for defining Azure resources as code. In terms of look and feel, it’s very similar to Terraform.. If one considers Bicep files as code, then it would be a natural step to ensure that code meets a certain level of quality. In addition to that level of quality, because Bicep is deploying infrastructure, we would want to ensure that infrastructure is well designed and has a chance of successfully deploying.

When Bicep started to be adopted by the team I was working in, I became involved in designing a process to meet those quality goals as well as reduce the number of deployment issues.

VMSA-2022-0007 – VMware Tools vulnerability

VMware have published a new security advisory relating to VMware Tools for Windows. It affects v10 and 11 of the Tools. The vulnerability allows a user with local admin rights in the guest OS to acquire system privileges.

The version with the fix for this vulnerability is 12.0.0. While this is a major version jump, from the release notes there doesn’t appear to be any major breaking changes. It still supports Windows as far back as 7 SP1/2008 R2 SP1.

VMSA-2021-0020 – 19 vulnerabilities on vCenter

VMware published a new security advisory overnight (VMSA-2021-0020) and it’s a big one. In total, it lists 19 vulnerabilities affecting multiple versions of vCenter. The most serious of the vulnerabilities is the first one – CVE-2021-22005. This vulnerability allows an attacker to upload files to vCenter. This vulnerability could then be used as an avenue to execute code. It’s been giving a CVSS score of 9.8

The second most worrying item on the list (CVE-2021-21991) allows an attacker to escalate their priveleges to Administrator level in the vSphere web interface. This vulnerability has been scored at 8.8.

The resolution for all these vulnerabilities is to update vCenter to the appropriate version. The advistory lists these, and I’ve produced a condensed version below.

Product/Version Update To Notes
vCenter 7.0 7.0 U2d The majority of issues are fixed by going to U2c. U2d resolves CVE-2021-22011 and CVE-2021-22018
vCenter 6.7 6.7 U3o This version will resolve all the associated issues with 6.7
vCenter 6.5 6.5 U3q This version will resolve all the associated issues with 6.5

Given the nature of some of these vulnerabilities, this would be one to get onto ASAP.

Remediating VMSA-2021-0002 – Potential Issues

In late February, VMware published their second security advisory for 2021. It contained contained three items:

  • CVE-2021-21972 – A remote code execution vulnerability in vCenter that has a CVSS score of 9.8
  • CVE-2021-21974 – A vulnerablity in OpenSLP, which is used in ESXi. This one has a CVSS score of 8.8
  • CVE-2021-21973 – Another vCenter vulnerability that was rated with a CVSS score of 5.3

Given the product versions affected, most organisations with relatively up to date virtualisation infrastructure would be at risk from these items. While testing and simulating the update process, I ran into some issues that might be worth publishing for a broader audience.