Chaves Públicas do SSH extraneou adicionadas ao arquivo Chaves Autorizadas em Linux VM

Resumo

Além de permitir que os usuários forneçam seus próprios keypairs SSH para autenticação, a plataforma microsoft Azure depende de keypairs SSH para habilitar alguns recursos que são adicionados à máquina virtual (VM) no momento da implantação. Descobrimos recentemente que, em alguns cenários limitados, as chaves públicas desses certificados Azure Plataforma poderiam ser adicionadas inesperadamente ao arquivo .ssh/authorized_keys. Esses cenários são escopo apenas para uma situação em que a VM é provisionada usando cloud-init e o usuário seleciona recursos adicionais Azure que dependem de certificados, como uma identidade de serviço gerenciada pelo sistema.

Esse comportamento inesperado ocorre devido a uma alteração na lógica de provisionamento de sistemas operacionais específicos. São sistemas que usam cloud-init e que instalam inadvertidamente a chave pública de todos os certificados disponíveis para a VM no arquivo de chaves autorizado por SSH durante a criação da VM.  

Para saber mais, acesse CVE-2019-0816.

Mais informações

Detalhes do cenário

A lógica de cloud-init mencionada na seção "Resumo" é atualmente conhecida por existir em Azure imagens do Ubuntu 18.04, além das imagens de entrada em nuvem RHEL 7.4/7.5/7.6 e CentOS 7.4. Também pode existir em imagens personalizadas usando esses sistemas operacionais. 
 
Se você habilitar um dos seguintes recursos enquanto provisiona uma das imagens Linux, poderá ver chaves adicionais e inesperadas em um arquivo .ssh/authorized_keys, como qualquer uma das seguintes:

• Identidade gerenciada
• Extensões com configurações protegidas
• Implantar uma VM com Key Vault Chaves em uma VM

Identificar e corrigir VMs existentes

Identificar o

Para marcar se você tem chaves adicionais, examine o arquivo de chaves autorizadas (vi .ssh/authorized_keys arquivo) para determinar se alguma chave adicional que você não pretendia incluir foi adicionada.

É seguro remover manualmente todas as chaves públicas adicionais que possam ter sido adicionadas. Isso não afetará os recursos implantados junto com a VM. Além disso, ele não afetará o par de chaves SSH especificado para autenticação.

Se você não souber ou não conseguir diferenciar quais chaves públicas no arquivo .ssh/authorized_keys especificado para autenticação, siga estas etapas:

1. Examine seus modelos de implantação:

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

2. Recupere as chaves ssh implantadas no momento da criação de dentro da VM, se você tiver acesso sudo/raiz. Para fazer isso, siga estas etapas:

   1. Verifique a configuração de cloud-init que foi passada no CustomData: sudo cat /var/lib/waagent/ovf-env.xml | grep "<ns1:CustomData>"
      Use o valor CustomData e use o decodificado base64 para obter as chaves públicas implantadas:

eco "<customData value>" | base64 -D 2. Como alternativa, marcar o IMDS (Serviço de Metadados de Instância) para ver a chave pública ssh que foi passada na propriedade ssh public key da VM Create: curl -H Metadados:true "http://169.254.169.254/metadata/instance/compute/publicKeys?api-version=2018-04-02&format=json"

corrigir

Se você tiver identificado certificados adicionais que não pretende implantar na VM, poderá removê-los apagando a linha correspondente do arquivo authorized_keys.

Execute a correção conectando-se à VM interativamente ou use a Extensão de Script Personalizado ou o RunCommand em várias VMs.

VMs implantadas usando extensões que têm configurações protegidas ou uma identidade gerenciada

Use o script a seguir para remover chaves públicas de certificados nos quais a VM foi implantada com extensões ou identidade gerenciada. Isso não removerá as chaves especificadas quando você implantou uma VM ou se a VM foi implantada com Key Vault chaves.

 

#!/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 

Depois que o script for executado, marcar o arquivo ssh/authorized_keys para garantir que apenas as chaves públicas conhecidas estejam presentes.

VMs implantadas com Key Vault Segredos

Para identificar se a chave foi adicionada quando implantada com Key Vault Chaves, siga estas etapas:

1. Obtenha o nome do certificado Key Vault implantado usando a VM, examine o código de implantação Az CLI ou modelos arm ou execute esta CLI do Az:
    az vm show --resourceGroupName> do grupo <de recursos --name <vmName> | grep certificateUrl

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

2. Baixe o certificado:
    download do certificado az keyvault --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 a saída da etapa anterior com os certificados restantes no arquivo ssh/authorized_keys.
    vi arquivo .ssh/authorized_keys

Resolução

Azure MarketPlace Images

As correções foram aplicadas 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 você estiver usando imagens personalizadas provisionadas por cloud-init para os sistemas operacionais conhecidos, precisará atualizar sua imagem personalizada de origem.

Imagens do Ubuntu 18.04

Para atualizar uma imagem personalizada de origem, você deve fazer as seguintes modificações:

• Edite o seguinte arquivo:

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

• Adicione o código a seguir ao final do arquivo.

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

Imagens RHEL 7.4/7.5/7.6 e CentOS 7.6

Se você criou anteriormente as imagens RHEL/CentOS usando essas etapas (ou um método semelhante), deverá atualizar a imagem de origem da qual você criou as VMs. Veja a seguir as etapas adicionais necessárias para adicionar à configuração de imagem da VM de origem existente:

Etapa 1 

Edite o seguinte arquivo:

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

Adicione as seguintes linhas ao final do arquivo:

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

Etapa 2

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

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 de cloud-init

Todos os pacotes de cloud-init que incluem uma correção estão em processo de atualização. A Microsoft está pesquisando esse problema e irá publicar mais informações neste artigo assim que estiverem disponíveis. 

Perguntas frequentes

P1: A Microsoft ganhou acesso à minha VM?

A1: As chaves de criptografia são usadas para gerenciar identidades e extensões não foram projetadas para acesso por funcionários da Microsoft. Temos processos em vigor para monitorar, fazer log e impedir esse tipo de acesso. Como precaução de segurança, estamos revisando todos os logs para garantir que nenhuma chave de cliente tenha sido acessada de forma inadequada. Para certificados armazenados em Key Vault que são referenciados em uma implantação de VM ou VMSS, os funcionários da Microsoft não têm acesso aos segredos.

P2: todos os OSs e versões implantados na nuvem foram afetados?

A2: Não. Vimos esse problema de chave extraneous ocorrer apenas nos sistemas operacionais identificados. Não vimos isso ocorrer em versões mais antigas do Ubuntu. Isso ocorre porque esses sistemas usam um mecanismo diferente para definir chaves públicas.

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

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

Q4: A Microsoft atualizará automaticamente as VMs afetadas?

A4: Não. A Microsoft não alterará o conteúdo das VMs que você já provisionou.

P5: Nossas políticas de segurança me impedem de operar uma VM Linux com conteúdo extraneous em authorized_keys. O que posso fazer sobre isso hoje?

A5: Você pode remover a linha ofensiva com segurança do arquivo authorized_keys. Isso não afetará nem o keypair SSH que você criou e controla nem a identidade gerenciada. Você pode fazer isso manualmente ou executando um script personalizado ou um comando personalizado em qualquer frota afetada.