Chaves Públicas SSH Desnecessárias adicionadas ao ficheiro Chaves Autorizadas na VM Linux

Resumo

Além de permitir que os utilizadores forneçam os seus próprios porta-chaves SSH para autenticação, a plataforma microsoft Azure baseia-se em porta-chaves SSH para ativar algumas funcionalidades que são adicionadas à máquina virtual (VM) no momento da implementação. Detetámos recentemente que, em alguns cenários limitados, as chaves públicas destes certificados Azure Plataforma poderiam ser adicionadas inesperadamente ao ficheiro .ssh/authorized_keys. Estes cenários estão confinados apenas a uma situação em que a VM é aprovisionada através do cloud-init e o utilizador seleciona funcionalidades adicionais Azure que dependem de certificados, como uma identidade de serviço gerida pelo sistema.

Este comportamento inesperado ocorre devido a uma alteração na lógica de aprovisionamento de sistemas operativos específicos. Estes são sistemas que utilizam o cloud-init e que, inadvertidamente, instalam a chave pública a partir de todos os certificados que estão disponíveis para a VM no ficheiro de chaves autorizadas por ssh durante a criação da VM.  

Para saber mais, aceda a CVE-2019-0816.

Mais informações

Detalhes do cenário

Sabe-se que a lógica cloud-init mencionada na secção "Resumo" existe atualmente em Azure imagens para o Ubuntu 18.04, além das imagens cloud-init da Pré-visualização Pública RHEL 7.4/7.5/7.6 e CentOS 7.4 cloud-init. Também pode existir em imagens personalizadas com estes sistemas operativos. 
 
Se ativar uma das seguintes funcionalidades enquanto aprovisiona uma das imagens Linux, poderá ver chaves adicionais e inesperadas num ficheiro .ssh/authorized_keys, como qualquer uma das seguintes:

• Identidade gerida
• Extensões com definições protegidas
• Implementar uma VM com chaves de Key Vault numa VM

Identificar e remediar VMs existentes

Identificar

Para verificar se tem chaves adicionais, reveja o ficheiro de chaves autorizadas (ficheiro vi .ssh/authorized_keys) para determinar se foram adicionadas chaves adicionais que não pretendia incluir.

É seguro remover manualmente quaisquer chaves públicas ssh adicionais que possam ter sido adicionadas. Isto não afetará as funcionalidades implementadas em conjunto com a VM. Além disso, não afetará o par de chaves SSH especificado para autenticação.

Se não souber ou não conseguir diferenciar as chaves públicas no ficheiro .ssh/authorized_keys que especificou para autenticação, siga estes passos:

1. Reveja os modelos de implementação:

   1. chaves públicas ssh
   2. chaves ssh na configuração cloud-init

2. Obtenha as chaves ssh implementadas no momento da criação a partir da VM, se tiver acesso sudo/raiz. Para fazê-lo, siga estes passos:

   1. Verifique a configuração do cloud-init que foi transmitida em CustomData: sudo cat /var/lib/waagent/ovf-env.xml | grep "<ns1:CustomData>"
      Utilize o valor CustomData e, em seguida, utilize o descodificador base64 para obter as chaves públicas que implementou:

eco "<customData value>" | base64 -D 2. Em alternativa, verifique o Instance Meta Data Service (IMDS) para ver a chave pública ssh que foi transmitida na propriedade da chave pública ssh da VM Create: curl -H Metadata:true "http://169.254.169.254/metadata/instance/compute/publicKeys?api-version=2018-04-02&format=json"

Remediar

Se tiver identificado certificados adicionais que não pretendia implementar na VM, pode removê-los ao apagar a linha correspondente do ficheiro authorized_keys.

Execute a remediação ao ligar-se à VM interativamente ou utilize a Extensão de Script Personalizado ou o Comando Executar em várias VMs.

VMs implementadas com extensões que têm definições protegidas ou uma identidade gerida

Utilize o seguinte script para remover chaves públicas de certificados nos quais a VM foi implementada com extensões ou identidade gerida. Esta ação não removerá as chaves especificadas quando implementou uma VM ou se a VM tiver sido implementada com chaves Key Vault.

 

#!/bin/bash
set -e

# /var/lib/waagent has *.crt files that include the crt files corresponding to 
# the user provided public keys and one additional .crt file from MSI.
# This script converts the content of the .crt file into the ssh public key and
# remove it from the authorized_keys file
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 

Após a execução do script, verifique o ficheiro ssh/authorized_keys para garantir que apenas as chaves públicas conhecidas estão presentes.

VMs implementadas com segredos do Key Vault

Para identificar se a chave foi adicionada quando implementada com Key Vault Chaves, siga estes passos:

1. Obtenha o nome do certificado de Key Vault que implementou com a VM, reveja o código de implementação Az CLI ou modelos do ARM ou execute esta CLI do Az:
    az vm show --resource-group <resourceGroupName> --name <vmName> | grep certificateUrl

   A resposta mostrará o nome do certificado:
    "certificateUrl": "https://< keyVaultname.vault.azure.net/secrets/><certName>/xxxxxxxxxxxxx"

2. Transfira o certificado:
    az keyvault certificate download --vault-name <keyVaultName> --name <certName> --encoding PEM --file public.pem

3. Extraia a chave pública:
    openssl x509 -in public.pm -pubkey -noout | ssh-keygen -f /dev/stdin -i -m PKCS8

4. Compare o resultado do passo anterior com os restantes certificados no ficheiro ssh/authorized_keys.
    ficheiro vi .ssh/authorized_keys

Resolução

Imagens do Azure MarketPlace

Foram aplicadas correções ao cloud-init nas imagens de Azure identificadas:

• Canonical:UbuntuServer:18.04-LTS:18.04.201902190
• Canonical:UbuntuServer:18.10-DAILY:18.10.201903200
• RedHat:RHEL:7-RAW-CI:7.6.2019030421
• OpenLogic:CentOS-CI:7-CI:7.6.20190306

Imagens Personalizadas

Se estiver a utilizar imagens personalizadas que são aprovisionadas pelo cloud-init para os sistemas operativos conhecidos, terá de atualizar a imagem personalizada de origem.

Imagens do Ubuntu 18.04

Para atualizar uma imagem personalizada de origem, tem de efetuar as seguintes modificações:

• Edite o seguinte ficheiro:

  /etc/cloud/cloud.cfg.d/90-azure.cfg

• Adicione o seguinte código ao final do ficheiro.

datasource:
   Azure:
     agent_command: [service, walinuxagent, start]

Imagens RHEL 7.4/7.5/7.6 e CentOS 7.6

Se criou anteriormente as imagens RHEL/CentOS com estes passos (ou um método semelhante), tem de atualizar a imagem de origem a partir da qual criou as VMs. Seguem-se passos adicionais que são necessários para adicionar à configuração da imagem da VM de origem existente:

Passo 1 

Edite o seguinte ficheiro:

/etc/cloud/cloud.cfg.d/91-azure_datasource.cfg

Adicione as seguintes linhas ao final do ficheiro:

datasource:
   Azure:
     agent_command: [systemctl, start, waagent, --no-block]

Passo 2

Atualize a configuração do Agente da seguinte forma:

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

pacotes cloud-init

Todos os pacotes cloud-init que incluem uma correção estão em vias de ser atualizados. A Microsoft está a pesquisar este problema e vai publicar mais informações neste artigo quando as informações ficarem disponíveis. 

Perguntas mais frequentes

T1: A Microsoft obteve acesso à minha VM?

A1: As chaves de encriptação são utilizadas para gerir identidades e as extensões não foram concebidas para acesso por funcionários da Microsoft. Temos processos implementados para monitorizar, registar e impedir este tipo de acesso. Como precaução de segurança, estamos a rever todos os registos para garantir que nenhuma chave de cliente foi acedida de forma inadequada. Para certificados armazenados em Key Vault referenciados numa implementação de VM ou VMSS, os funcionários da Microsoft não têm acesso aos segredos.

Q2: Todos os SOs e versões implementados no cloud-init são afetados?

A2: Não, não. Vimos este problema de chave estranho ocorrer apenas nos sistemas operativos identificados. Não o vimos ocorrer em versões mais antigas do Ubuntu. Isto deve-se ao facto de estes sistemas utilizarem um mecanismo diferente para definir chaves públicas.

T3: Os pacotes cloud-init afetados para as distribuições de Linux incluem a correção?

A3: Estamos a trabalhar para adicionar as correções aos pacotes para as versões afetadas e atualizaremos este artigo quando esse trabalho estiver concluído.

T4: A Microsoft atualizará automaticamente as VMs afetadas?

A4: Não, não. A Microsoft não alterará o conteúdo das VMs que já aprovisionou.

P5: As nossas políticas de segurança impedem-me de operar uma VM Linux com conteúdo estranho no authorized_keys. O que posso fazer hoje?

A5: Pode remover a linha ofensiva em segurança do ficheiro authorized_keys. Isto não afetará o keypair SSH que criou e controlou ou a identidade gerida. Pode fazê-lo manualmente ou ao executar um script personalizado ou um comando personalizado em qualquer frota afetada.