Resumo

Para além de permitir que os utilizadores a fornecer o seu próprio keypairs SSH para autenticação, a plataforma Microsoft Azure baseia-se em SSH keypairs para permitir que algumas funcionalidades que são adicionadas à máquina virtual (VM) no momento da implementação. A Microsoft descobriu recentemente que, em alguns cenários limitados, as chaves públicas destes certificados de plataforma Azure poderiam ser inesperadamente adicionadas ao ficheiro .ssh/authorized_keys. Estes cenários são no âmbito apenas para uma situação em que a VM é aprovisionada utilizando cloud init e o utilizador selecciona funcionalidades Azure adicionais que dependem de certificados, tais como uma identidade de serviço gerido pelo sistema.

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

Para obter mais informações, vá para o CVE-2019-0816.

Mais informações

Detalhes do cenário

A lógica de nuvem init mencionada na secção "Sumário" chama-se actualmente a existir em imagens Azure Ubuntu 18.04 além das RHEL de pré-visualização pública 7.4/7.5/7.6 e CentOS 7.4 nuvem init imagens. Podem também existir em imagens personalizadas utilizando estes sistemas operativos.    Se activar uma das seguintes funcionalidades enquanto aprovisionar a uma das imagens do Linux, poderá ver chaves adicionais inesperadas num ficheiro .ssh/authorized_keys, tal como qualquer um dos seguintes procedimentos:

  • Identidade gerida

  • Extensões com definições protegidas

  • Implementar uma VM com chaves de Cofre de palavras chave numa VM

Identificar e rectificar VMs existentes

Identificar

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

Manualmente é seguro remover suplementar ssh público teclas que poderá ter sido adicionado. Isto irá não afectam as funcionalidades que são implementadas em conjunto com a VM. Além disso, não afectará o par de chaves SSH especificado para autenticação.

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

  1. Reveja os modelos de implementação:

    1. SSH chaves públicas

    2. SSH chaves na configuração de inicialização de nuvem

  2. Obter o implementado ssh teclas no momento de criação de dentro da VM, se tiver acesso sudo/root. Para tal, siga estes passos:

    1. Verifique a configuração de inicialização de nuvem que foi transmitida CustomData: sudo cat /var/lib/waagent/ovf-env.xml | grep "<ns1:CustomData>"Utilize o valor de CustomData e, em seguida, utilizar base64 descodificar para obter as chaves públicas que é implementado: echo "<customData value>" | base64 -D

    2. Em alternativa, verifique a instância Meta dados serviço (IMDS) para ver o ssh chave pública que foi transmitido o ssh propriedade de chave pública da VM para criar: curl -H Metadata:true "http://169.254.169.254/metadata/instance/compute/publicKeys?api-version=2018-04-02&format=json"

Rectificar

Se tiver identificado certificados adicionais que não pretendia para implementar a VM, pode remover estes apagando linha correspondente do ficheiro authorized_keys.

Executar a reparação através da ligação para a VM interactivamente ou utilizar a extensão de Script personalizado ou o ExecutarComando através de vários VMs.

VMs implementadas através de extensões que protegeu definições ou uma identidade gerida

Utilize o seguinte script para remover as chaves públicas dos certificados em que a VM foi implementada com extensões ou geridos identidade. Esta acção irá remover não chaves que foram especificadas quando tiver implementado uma VM ou se a VM foi implementada com chaves de Cofre de palavras chave.

Importante

Recomendamos que crie uma cópia de segurança do ficheiro de authorized_keys antes de executar este 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 

Depois da execução do script, consulte o ficheiro de ssh/authorized_keys para garantir que apenas das chaves públicas conhecidas estão presentes.

VMs implementados com segredos de Cofre de palavras chave

Para identificar se a chave foi adicionada quando implementado com chaves de Cofre de palavras chave, siga estes passos:

  1. Obter o nome do certificado de Cofre de palavras chave que é implementado utilizando a VM, reveja o código de implementação Az CLI ou modelos ARM ou executar este CLI Az: az vm show --resource-group <resourceGroupName> --name <vmName> | grep certificateUrlA resposta mostrará o nome do certificado: "certificateUrl": "https://<keyVaultname>.vault.azure.net/secrets/<certName>/xxxxxxxxxxxxx"

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

  3. Extrai 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 para os restantes certs no ficheiro ssh/authorized_keys. vi .ssh/authorized_keys file

Resolução

Imagens dos serviços electrónicos Azure

Correcções foram aplicadas ao cloud-init nas imagens 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 forem aprovisionadas por cloud-inicialização para os sistemas operativos conhecidos, terá de actualizar a imagem personalizada de origem.

Imagens de Ubuntu 18.04

Para actualizar uma imagem personalizada de origem, tem de efectuar as seguintes alterações:

  • Edite o ficheiro seguinte: /etc/cloud/cloud.cfg.d/90-Azure.cfg

  • Adicione o seguinte código para o fim do ficheiro.

Importante

O código tem de ser adicionado exactamente como é mostrado, incluindo espaços.

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

RHEL 7.4/7.5/7.6 e CentOS 7.6 imagens

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

Passo 1

Edite o ficheiro seguinte:

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

Importante

O código tem de ser adicionado exactamente como é mostrado, incluindo espaços.

Adicione as seguintes linhas no fim do ficheiro:

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

Passo 2

Actualize a configuração do agente do seguinte modo:

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 inicialização de nuvem

Todos os pacotes de inicialização de nuvem que incluem uma correcção estarem a ser actualizados. A Microsoft está a investigar este problema e publicará mais informações neste artigo quando a informação fica disponível.

Perguntas mais frequentes

P1: Ganhou Microsoft access para a VM?

A1: Chaves de encriptação são utilizadas para gerir identidades e extensões não são concebidas para acesso por empregados da Microsoft. Temos de processos para monitorizar, iniciar sessão e impedir este tipo de acesso. Como precaução de segurança, a Microsoft está a rever todos os registos para se certificar de que não existem chaves de cliente acedeu inapropriadamente. Para os certificados que estão armazenados no Cofre de palavras chave que são referenciados numa implementação VM ou VMSS, os empregados da Microsoft não tem acesso para os segredos.

P2: São todas as versões afectadas e OSs cloud-init implementado?

A2: N. º Observámos este problema chave estranho ocorrer apenas nos sistemas operativos identificados. Não observámos que ocorrem em versões mais antigas do Ubuntu. Esta é uma vez que esses sistemas utilizam um mecanismo de diferente para definir as chaves públicas.

P3: Os nuvem-init afectado pacotes para as distribuições de Linux incluem a correcção?

A3: Estamos a trabalhar sobre como adicionar as correcções para os pacotes para as versões afectadas e este artigo será actualizado quando esse trabalho for concluído.

P4: Microsoft actualiza automaticamente quaisquer VMs afectados?

A4: N. º Microsoft não alterará o conteúdo do VMs que já tenham aprovisionado.

P5: Nossas políticas de segurança impedem-me uma VM Linux com conteúdo estranho na authorized_keys de funcionamento. O que posso fazer isto hoje?

A5: Pode remover a linha infractor com segurança do ficheiro authorized_keys. Isto não afecta o par de chaves SSH que criou e o controlo ou a identidade gerida. Pode fazê-lo manualmente ou através da execução de um script personalizado ou um comando personalizado através de qualquer frota afectada.

Precisa de mais ajuda?

Aumente os seus conhecimentos
Explore as formações
Seja o primeiro a obter novas funcionalidades
Aderir ao Microsoft insiders

As informações foram úteis?

Quão satisfeito está com a qualidade do idioma?
O que afetou a sua experiência?

Obrigado pelo seu feedback!

×