5.1 Medium
CVSS3
Attack Vector
LOCAL
Attack Complexity
HIGH
Privileges Required
NONE
User Interaction
NONE
Scope
UNCHANGED
Confidentiality Impact
NONE
Integrity Impact
HIGH
Availability Impact
NONE
CVSS:3.0/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
5.1 Medium
AI Score
Confidence
High
1.9 Low
CVSS2
Access Vector
LOCAL
Access Complexity
MEDIUM
Authentication
NONE
Confidentiality Impact
NONE
Integrity Impact
PARTIAL
Availability Impact
NONE
AV:L/AC:M/Au:N/C:N/I:P/A:N
0.001 Low
EPSS
Percentile
22.8%
In addition to letting users provide their own SSH keypairs for authentication, the Microsoft Azure platform relies on SSH keypairs to enable some features that are added to the virtual machine (VM) at deployment time. We recently discovered that, in some limited scenarios, the public keys from these Azure Platform certificates could be unexpectedly added to the .ssh/authorized_keys file. These scenarios are scoped only to a situation in which the VM is provisioned by using cloud-init and the user selects additional Azure features that rely on certificates, such as a system-managed service identity.This unexpected behavior occurs because of a change in the provisioning logic of specific operating systems. These are systems that use cloud-init and that inadvertently install the public key from _all _certificates that are available to the VM into ssh-authorized keys file during VM creation. To learn more, go to CVE-2019-0816.
The cloud-init logic that is mentioned in the βSummaryβ section is currently known to exist in Azure images for Ubuntu 18.04 in addition to the Public Preview RHEL 7.4/7.5/7.6 and CentOS 7.4 cloud-init images. It may also exist in custom images using these operating systems.
If you enable one of the following features while you provision one of the Linux images, you may see additional, unexpected keys in an .ssh/authorized_keys file, such as any of the following:
To check whether you have additional keys, review the authorized keys file (vi .ssh/authorized_keys file) to determine whether any additional keys that you didnβt intend to include have been added.It is safe to manually remove any additional ssh public keys that might have been added. This will notaffect the features that are deployed together with the VM. Also, it will not affect your specified SSH key pair for authentication.If you do not know or cannot differentiate which public keys in the .ssh/authorized_keys file you specified for authentication, follow these steps:
If you have identified additional certificates that you did not intend to deploy to the VM, you can remove these by erasing the corresponding line from the authorized_keys file.Run the remediation by connecting to the VM interactively, or use either the Custom Script Extension or the RunCommand across multiple VMs.
Use the following script to remove public keys from certificates in which the VM was deployed with extensions or managed identity. This will notremove keys that were specified when you deployed a VM, or if the VM was deployed with Key Vault keys.
**Important:**We recommend that you back up the authorized_keys file before you run this script.
`
#!/bin/bash
set -e
readarray -t CRT_FILES < <(grep -l -E β(Microsoft.ManagedIdentity|Windows Azure)β /var/lib/waagent/*.crt)
for ((i=0; i < ${#CRT_FILES[@]}; i++))
do
β― β― PUBKEY=$(openssl x509 -in β${CRT_FILES[$i]}β -pubkey -noout | ssh-keygen -f /dev/stdin -i -m PKCS8)
β― β― sed -i -e β@$PUBKEY@dβ $HOME/.ssh/authorized_keys
Done
`After the script has run, check the ssh/authorized_keys file to ensure only the known public key(s) are present.
To identify whether the key was added when deployed with Key Vault Keys, follow these steps:
The response will show the certificate name:
βcertificateUrlβ: βhttps://<keyVaultname>.vault.azure.net/secrets/<certName>/xxxxxxxxxxxxxβ
2. Download the certificate:
az keyvault certificate download --vault-name <keyVaultName> --name <certName> --encoding PEM --file public.pem
3. Extract the public key:
openssl x509 -in public.pm -pubkey -noout | ssh-keygen -f /dev/stdin -i -m PKCS8
4. Compare the output from the previous step to the remaining certs in the ssh/authorized_keys file.
vi .ssh/authorized_keys file
Fixes have been applied to cloud-init in the identified Azure images:
If you are using custom images that are provisioned by cloud-init for the known operating systems, you will have to update your source custom image.
To update a source custom image, you must make the following modifications:
/etc/cloud/cloud.cfg.d/90-azure.cfg
**Important:**The code must be added exactly as shown, including spaces.
`
datasource:
β―β― Azure:
agent_command: [service, walinuxagent, start]
`
If you previously created the RHEL/CentOS images by using these steps (or a similar method), you must update the source image from which you created the VMs. The following are additional steps that are required to add to your existing source VM image configuration:Step 1 Edit the following file:/etc/cloud/cloud.cfg.d/91-azure_datasource.cfg
**Important:**The code must be added exactly as shown, including spaces.
Add the following lines to the end of the file: `
datasource:
Azure:
agent_command: [systemctl, start, waagent, --no-block]
**Step 2**Update the Agent configuration as follows:
cp /lib/systemd/system/waagent.service /etc/systemd/system/waagent.service
sed -i βs/After=network-online.target/WantedBy=cloud-init.service\nAfter=network.service systemd-networkd-wait-online.service/gβ /etc/systemd/system/waagent.service
systemctl daemon-reload
`
All cloud-init packages that include a fix are in the process of being updated. Microsoft is researching this problem and will post more information in this article when the information becomes available.
A1: Encryption keys are used to manage identities and extensions are not designed for access by Microsoft employees. We have processes in place to monitor, log, and prevent this kind of access. As a safety precaution, we are reviewing all logs to make sure that no customer keys were inappropriately accessed. For certificates that are stored in Key Vault which are referenced in a VM or VMSS deployment, Microsoft employees do not have any access to the secrets.
A2: No. We have seen this extraneous key issue occur only in the identified operating systems. We have not seen it occur in older versions of Ubuntu. This is because those systems use a different mechanism to set public keys.
A3: We are working on adding the fixes to the packages for the affected versions and we will update this article when that work is completed.
A4: No. Microsoft will not change the contents of VMs that you have already provisioned.
A5: You can remove the offending line safely from the authorized_keys file. This wonβt affect either the SSH keypair that you created and control or the managed identity. You can do this manually or by running a custom script or custom command across any affected fleet.
5.1 Medium
CVSS3
Attack Vector
LOCAL
Attack Complexity
HIGH
Privileges Required
NONE
User Interaction
NONE
Scope
UNCHANGED
Confidentiality Impact
NONE
Integrity Impact
HIGH
Availability Impact
NONE
CVSS:3.0/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
5.1 Medium
AI Score
Confidence
High
1.9 Low
CVSS2
Access Vector
LOCAL
Access Complexity
MEDIUM
Authentication
NONE
Confidentiality Impact
NONE
Integrity Impact
PARTIAL
Availability Impact
NONE
AV:L/AC:M/Au:N/C:N/I:P/A:N
0.001 Low
EPSS
Percentile
22.8%