Chaves públicas SSH estranhas adicionadas ao arquivo de chaves autorizadas em VM Linux

Resumo

Além de permitir que os usuários forneçam seus próprios pares de chaves SSH para autenticação, a plataforma Microsoft Azure depende de pares de chaves 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 da Plataforma do Azure podem ser adicionadas inesperadamente ao arquivo .ssh/authorized_keys. Esses cenários têm como escopo apenas uma situação na qual a VM é provisionada usando cloud-init e o usuário seleciona recursos adicionais do 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. Esses são sistemas que usam cloud-init e que instalam inadvertidamente a chave pública de todos os certificados que estão disponíveis para a VM no arquivo .ssh/authorized_keys durante a criação da VM.  

Para saber mais, consulte a 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 nas imagens do Azure para Ubuntu 18.04, além de nas imagens cloud-init do Public Preview RHEL 7.4/7.5/7.6 e CentOS 7.4. Ela também pode existir em imagens personalizadas usando esses sistemas operacionais. 
 
Se você habilitar um dos seguintes recursos enquanto provisiona uma das imagens do 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 chaves de cofre de chaves em uma VM

Identificar e remediar VMs existentes

Identificar

Para verificar se você tem chaves adicionais, revise o arquivo de chaves autorizadas (arquivo vi .ssh/authorized_keys) para determinar se as chaves adicionais que você não pretendia incluir foram adicionadas.

É seguro remover manualmente quaisquer chaves públicas SSH adicionais que possam ter sido adicionadas. Isso não afetará os recursos que são implantados junto com a VM. Isso também não afetará seu par de chaves SSH especificado para autenticação.

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

  1. Revise seus modelos de implantação:

    1. chaves públicas ssh

    2. chaves ssh na configuração cloud-init

  2. Recupere as chaves ssh implantadas no momento da criação de dentro da VM se tiver acesso sudo/root. Para fazer isto, siga as seguintes etapas:

    1. Verifique a configuração de cloud-init que foi passada em CustomData: sudo cat /var/lib/waagent/ovf-env.xml | grep "<ns1:CustomData>"
      Use o valor CustomData e, em seguida, use a decodificação base64 para obter as chaves públicas que você implantou: echo "<customData value>" | base64 -D

    2. Como alternativa, verifique o IMDS (Serviço de Metadados de Instância) para ver a chave pública ssh que foi passada na propriedade da chave pública ssh de criação da VM: curl -H Metadata: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 pretendia implantar na VM, poderá removê-los apagando a linha correspondente do arquivo authorized_keys.

Execute a correção conectando-se à VM de forma interativa ou use a extensão de script personalizada ou 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á chaves que foram especificadas quando você implantou uma VM ou se a VM tiver sido implantada com chaves do Cofre de Chaves.

Importante

Recomendamos que você faça backup do arquivo authorized_keys antes de executar esse script.

 

#!/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 arquivo ssh/authorized_keys para garantir que apenas as chaves públicas conhecidas estejam presentes.

VMs implantadas com segredos do Cofre de Chaves

Para identificar se a chave foi adicionada quando implantada com chaves do Cofre de Chaves, siga estas etapas:

  1. Obtenha o nome do certificado do Cofre de Chaves que você implantou usando a VM, revise o código de implantação de modelos de CLI do Az ou ARM ou execute este 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. Baixe 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 a saída da etapa anterior com os certificados restantes no arquivo ssh/authorized_keys.
      vi .ssh/authorized_keys file

Resolução

Imagens do Azure MarketPlace

Correções foram aplicadas a cloud-init nas imagens do Azure identificadas:

  • Canonical:UbuntuServer:18.04-LTS:18.04.201902190

Observação

Uma atualização será adicionada às seguintes imagens em uma data posterior.

  • Canonical:UbuntuServer:18.10:x

  • RedHat:RHEL:7-RAW-CI (imagem Public Preview)

  • OpenLogic:CentOS:7-CI (imagem Public Preview)

Este artigo será atualizado depois que as imagens se tornarem disponíveis.

Imagens personalizadas

Se você estiver usando imagens personalizadas provisionadas por cloud-init para os sistemas operacionais conhecidos, terá que 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 seguinte código ao final do arquivo.

Importante

O código deve ser adicionado exatamente conforme mostrado, incluindo os espaços.

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

Imagens do RHEL 7.4/7.5/7.6 e CentOS 7.6

Se você tiver criado anteriormente as imagens do RHEL/CentOS usando estas etapas (ou um método semelhante), deverá atualizar a imagem de origem da qual criou as VMs. Veja a seguir as etapas adicionais que devem ser adicionadas à sua configuração de imagem de VM de origem existente:

Etapa 1 

Edite o seguinte arquivo:

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

Importante

O código deve ser adicionado exatamente conforme mostrado, incluindo os espaços.

Adicione a seguinte linha 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 cloud-init

Todos os pacotes 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 obteve acesso à minha VM?

R1: Chaves de criptografia são usadas para gerenciar identidades e extensões não são projetadas para acesso por funcionários da Microsoft. Temos processos em vigor para monitorar, registrar e evitar esse tipo de acesso. Como precaução de segurança, estamos revisando todos os logs para certificar-se de que nenhuma chave de cliente tenha sido acessada inapropriadamente. Para certificados armazenados no Cofre de Chaves 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 de cloud-init implantados são afetados?

R2: Não. Temos visto esse problema de chaves estranhas ocorrer apenas nos sistemas operacionais identificados. Não identificamos sua ocorrência em versões mais antigas do Ubuntu. Isso acontece porque esses sistemas usam um mecanismo diferente para definir chaves públicas.

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

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

P4: A Microsoft atualizará automaticamente todas as VMs afetadas? 

R4: 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 estranho em authorized_keys. O que posso fazer sobre isso hoje?

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

Precisa de mais ajuda?

Expanda suas habilidades
Explore o treinamento
Obtenha novos recursos primeiro
Ingressar no Microsoft Insider

Estas informações foram úteis?

Obrigado por seus comentários!

Agradecemos pelos seus comentários! Parece que pode ser útil conectar você a um de nossos agentes de suporte do Office.

×