คีย์สาธารณะ SSH เพิ่มเติมที่เพิ่มลงในไฟล์คีย์ที่ได้รับอนุญาตบน Linux VM

นำไปใช้กับ
Virtual Machine running Linux

สรุป

นอกจากจะให้ผู้ใช้มี Keypair ของ SSH ของตนเองสําหรับการรับรองความถูกต้องแล้ว แพลตฟอร์ม Microsoft Azure ใช้ Keypairs SSH เพื่อเปิดใช้งานฟีเจอร์บางอย่างที่เพิ่มลงในเครื่องเสมือน (VM) ในขณะปรับใช้ เราเพิ่งค้นพบว่า ในบางสถานการณ์ที่จํากัด คีย์สาธารณะจากใบรับรองแพลตฟอร์ม Azure เหล่านี้อาจถูกเพิ่มลงในไฟล์ .ssh/authorized_keys โดยไม่คาดคิด สถานการณ์เหล่านี้จะถูกกําหนดขอบเขตไว้เฉพาะกับสถานการณ์ที่ VM ถูกเตรียมใช้งานโดยใช้ cloud-init และผู้ใช้เลือกคุณลักษณะ Azure เพิ่มเติมที่ใช้ใบรับรอง เช่น ข้อมูลประจําตัวของบริการที่จัดการโดยระบบ

ลักษณะการทํางานที่ไม่คาดคิดนี้เกิดขึ้นเนื่องจากการเปลี่ยนแปลงตรรกะการเตรียมใช้งานของระบบปฏิบัติการเฉพาะ ระบบเหล่านี้เป็นระบบที่ใช้ cloud-init และติดตั้งคีย์สาธารณะโดยไม่ได้ตั้งใจจากใบรับรอง ทั้งหมด ที่พร้อมใช้งานสําหรับ VM ในไฟล์คีย์ ssh ที่ได้รับอนุญาตในระหว่างการสร้าง VM  

หากต้องการเรียนรู้เพิ่มเติม ไปที่ CVE-2019-0816

ข้อมูลเพิ่มเติม

รายละเอียดสถานการณ์สมมติ

ตรรกะในระบบคลาวด์ที่ระบุไว้ในส่วน "สรุป" เป็นที่รู้จักกันในปัจจุบันในรูป Azure สําหรับ Ubuntu 18.04 นอกเหนือจากรูปภาพสําหรับตัวอย่างสาธารณะ RHEL 7.4/7.5/7.6 และ CentOS 7.4 บนระบบคลาวด์ และอาจมีอยู่ในรูปแบบกําหนดเองที่ใช้ระบบปฏิบัติการเหล่านี้ 
 
ถ้าคุณเปิดใช้งานหนึ่งในฟีเจอร์ต่อไปนี้ในขณะที่คุณเตรียมใช้งานหนึ่งในรูป Linux คุณอาจเห็นคีย์เพิ่มเติมที่ไม่คาดคิดในไฟล์ .ssh/authorized_keys เช่น รายการใดๆ ต่อไปนี้:

  • ข้อมูลประจําตัวที่มีการจัดการ
  • ส่วนขยายที่มีการตั้งค่าที่ได้รับการป้องกัน
  • ปรับใช้ VM กับ Key Vault Keys ใน VM

ระบุและแก้ไข VM ที่มีอยู่

ระบุ

เมื่อต้องการตรวจสอบว่าคุณมีคีย์เพิ่มเติมหรือไม่ ให้ตรวจสอบไฟล์คีย์ที่ได้รับอนุญาต (ไฟล์ vi .ssh/authorized_keys) เพื่อตรวจสอบว่ามีการเพิ่มคีย์เพิ่มเติมที่คุณไม่ได้ตั้งใจใส่เข้าไปหรือไม่

คุณสามารถเอาคีย์สาธารณะ ssh เพิ่มเติมที่อาจถูกเพิ่มเข้าไปออกด้วยตนเองได้อย่างปลอดภัย ซึ่ง จะไม่ ส่งผลกระทบต่อฟีเจอร์ที่ปรับใช้ร่วมกับ VM นอกจากนี้ จะไม่ส่งผลกระทบต่อการจับคู่คีย์ SSH ที่ระบุของคุณสําหรับการรับรองความถูกต้อง

ถ้าคุณไม่ทราบหรือไม่สามารถแยกความแตกต่างของคีย์สาธารณะในไฟล์ .ssh/authorized_keys ที่คุณระบุสําหรับการรับรองความถูกต้อง ให้ทําตามขั้นตอนเหล่านี้:

  1. รีวิวเทมเพลตการปรับใช้ของคุณ:

    1. คีย์สาธารณะ ssh
    2. แป้น ssh ในการกําหนดค่า cloud-init

  2. เรียกใช้แป้น ssh ที่ปรับใช้ในเวลาการสร้างจากภายใน VM ถ้าคุณมีการเข้าถึง sudo/root เมื่อต้องการทำสิ่งนี้ ให้ทำตามขั้นตอนเหล่านี้:

    1. ตรวจสอบการกําหนดค่า cloud-init ที่ส่งผ่านใน CustomData: sudo cat /var/lib/waagent/ovf-env.xml | grep "<ns1:CustomData>"
      ใช้ค่า CustomData แล้วใช้การถอดรหัส base64 เพื่อรับคีย์สาธารณะที่คุณปรับใช้:

echo "<customData value>" | base64 -D 2 อีกวิธีหนึ่งคือ ตรวจสอบอินสแตนซ์ Meta Data Service (IMDS) เพื่อดูคีย์สาธารณะ ssh ที่ส่งผ่านในคุณสมบัติคีย์สาธารณะ ssh ของ VM Create: curl -H Metadata:true "http://169.254.169.254/metadata/instance/compute/publicKeys?api-version=2018-04-02&format=json"

การแก้ไข

ถ้าคุณได้ระบุใบรับรองเพิ่มเติมที่คุณไม่ได้ตั้งใจปรับใช้กับ VM คุณสามารถเอาใบรับรองเหล่านี้ออกได้โดยการลบบรรทัดที่สอดคล้องกันออกจากไฟล์ authorized_keys

เรียกใช้การแก้ไขโดยการเชื่อมต่อกับ VM แบบโต้ตอบ หรือใช้ Custom Script Extension หรือ RunCommand ข้าม VM หลายเครื่อง

VM ที่ปรับใช้โดยใช้ส่วนขยายที่มีการตั้งค่าที่ได้รับการป้องกันหรือข้อมูลประจําตัวที่มีการจัดการ

ใช้สคริปต์ต่อไปนี้เพื่อนําคีย์สาธารณะออกจากใบรับรองที่ VM ถูกปรับใช้ด้วยส่วนขยายหรือข้อมูลประจําตัวที่มีการจัดการ การดําเนินการนี้จะไม่ลบคีย์ที่ระบุเมื่อคุณปรับใช้ VM หรือ VM ถูกปรับใช้กับคีย์ Key Vault

สำคัญ

เราขอแนะนําให้คุณสํารองแฟ้ม authorized_keys ก่อนที่จะเรียกใช้สคริปต์นี้

 


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

หลังจากที่สคริปต์ทํางานให้ตรวจสอบไฟล์ ssh/authorized_keys เพื่อให้แน่ใจว่ามีเฉพาะคีย์สาธารณะที่รู้จักเท่านั้น

VM ที่ปรับใช้ด้วย Key Vault Secrets

เมื่อต้องการระบุว่าคีย์ถูกเพิ่มหรือไม่เมื่อปรับใช้ด้วยแป้น Key Vault ให้ทําตามขั้นตอนต่อไปนี้:

  1. ดูชื่อของใบรับรอง Key Vault ที่คุณปรับใช้โดยใช้ VM ตรวจสอบรหัสการปรับใช้ Az CLI หรือเทมเพลต ARM หรือเรียกใช้เทมเพลต Az CLI นี้:
     az vm show --resource-group <resourceGroupName> --name <vmName> | grep certificateUrl

    การตอบกลับจะแสดงชื่อใบรับรอง:
     "CertificateUrl": "https://< keyVaultname.vault.azure.net/secrets/><certName>/xxxxxxxxxxxx"

  2. ดาวน์โหลดใบรับรอง:
     ดาวน์โหลดใบรับรอง az keyvault --vault-name <keyVaultName> --name <certName> --encoding PEM --file public.pem

  3. แยกคีย์สาธารณะ:
     opensl x509 -in public.pm -pubkey -noout | ssh-keygen -f /dev/stdin -i -m PKCS8

  4. เปรียบเทียบผลลัพธ์จากขั้นตอนก่อนหน้ากับใบรับรองที่เหลือในไฟล์ ssh/authorized_keys
     vi .ssh/authorized_keys file

การแก้ปัญหา

Azure MarketPlace รูปภาพ

การแก้ไขถูกนําไปใช้กับ cloud-init ในรูปภาพ Azure ที่ระบุ:

  • 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

รูปแบบกําหนดเอง

ถ้าคุณกําลังใช้อิมเมจแบบกําหนดเองที่เตรียมใช้งานโดย cloud-init สําหรับระบบปฏิบัติการที่รู้จัก คุณจะต้องอัปเดตอิมเมจแบบกําหนดเองของแหล่งข้อมูลของคุณ

รูป Ubuntu 18.04

เมื่อต้องการอัปเดตอิมเมจแบบกําหนดเองของแหล่งข้อมูล คุณต้องทําการปรับเปลี่ยนต่อไปนี้

  • แก้ไขไฟล์ต่อไปนี้:

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

  • เพิ่มรหัสต่อไปนี้ลงในส่วนท้ายของไฟล์

สำคัญ

ต้องเพิ่มรหัสให้ตรงตามที่แสดง ซึ่งรวมถึงช่องว่างด้วย


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

รูป RHEL 7.4/7.5/7.6 และ CentOS 7.6

หากก่อนหน้านี้คุณสร้างอิมเมจ RHEL/CentOS โดยใช้ขั้นตอนเหล่านี้ (หรือวิธีที่คล้ายกัน) คุณต้องอัปเดตรูปภาพต้นฉบับที่คุณสร้าง VM ต่อไปนี้เป็นขั้นตอนเพิ่มเติมที่จําเป็นในการเพิ่มไปยังการกําหนดค่าอิมเมจ VM ต้นทางที่มีอยู่ของคุณ:

ขั้นตอนที่ 1 

แก้ไขไฟล์ต่อไปนี้:

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

สำคัญ

ต้องเพิ่มรหัสให้ตรงตามที่แสดง ซึ่งรวมถึงช่องว่างด้วย

เพิ่มบรรทัดต่อไปนี้ลงในส่วนท้ายของไฟล์: 


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

ขั้นตอนที่ 2

อัปเดตการกําหนดค่าเอเจนต์ดังนี้:


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

แพคเกจ Cloud-init

แพคเกจ Cloud-init ทั้งหมดที่มีการแก้ไขจะอยู่ในระหว่างการอัปเดต Microsoft กำลังค้นคว้าเกี่ยวกับปัญหานี้ และจะโพสต์ข้อมูลเพิ่มเติมในบทความนี้เมื่อมีข้อมูลเพิ่มเติม 

คำถามที่ถามบ่อย

คําถามที่ 1: Microsoft มีสิทธิ์เข้าถึง VM ของฉันหรือไม่

A1: คีย์การเข้ารหัสลับใช้ในการจัดการข้อมูลประจําตัวและส่วนขยายไม่ได้ออกแบบมาเพื่อการเข้าถึงโดยพนักงานของ Microsoft เรามีกระบวนการตรวจสอบ บันทึก และป้องกันการเข้าถึงประเภทนี้ เพื่อเป็นการป้องกันความปลอดภัย เรากําลังตรวจสอบบันทึกทั้งหมดเพื่อให้แน่ใจว่าไม่มีการเข้าถึงคีย์ลูกค้าอย่างไม่เหมาะสม สําหรับใบรับรองที่เก็บอยู่ใน Key Vault ที่อ้างอิงในการปรับใช้ VM หรือ VMSS พนักงาน Microsoft จะไม่มีสิทธิ์เข้าถึงความลับใดๆ

คําถามที่ 2: OS และเวอร์ชันที่ปรับใช้บนระบบคลาวด์ทั้งหมดได้รับผลกระทบหรือไม่

A2: ไม่ใช่ เราได้เห็นปัญหาคีย์ที่ไม่เกี่ยวข้องนี้เกิดขึ้นเฉพาะในระบบปฏิบัติการที่ระบุเท่านั้น เราไม่เห็นมันเกิดขึ้นใน Ubuntu เวอร์ชันที่เก่ากว่า ทั้งนี้เนื่องจากระบบเหล่านั้นใช้กลไกที่แตกต่างกันในการตั้งค่าคีย์สาธารณะ

คําถามที่ 3: แพคเกจ Cloud-init ที่ได้รับผลกระทบสําหรับการแจกจ่าย Linux มีการแก้ไขหรือไม่

A3: เรากําลังดําเนินการเพิ่มการแก้ไขลงในแพคเกจสําหรับเวอร์ชันที่ได้รับผลกระทบ และเราจะอัปเดตบทความนี้เมื่องานเสร็จสมบูรณ์

คําถามที่ 4: Microsoft จะอัปเดต VM ที่ได้รับผลกระทบโดยอัตโนมัติหรือไม่

A4: ไม่ใช่ Microsoft จะไม่เปลี่ยนแปลงเนื้อหาของ VM ที่คุณได้เตรียมใช้งานไว้แล้ว

คําถามที่ 5: นโยบายความปลอดภัยของเราป้องกันไม่ให้ฉันใช้งาน VM Linux ที่มีเนื้อหาที่ไม่เกี่ยวข้องใน authorized_keys วันนี้ฉันสามารถทําอะไรได้บ้าง

A5: คุณสามารถเอาบรรทัดที่ผิดออกจากไฟล์ authorized_keys ได้อย่างปลอดภัย ซึ่งจะไม่มีผลกับ Keypair ของ SSH ที่คุณสร้างและควบคุมหรือข้อมูลประจําตัวที่มีการจัดการ คุณสามารถทําได้ด้วยตนเองหรือโดยการเรียกใช้สคริปต์แบบกําหนดเองหรือคําสั่งแบบกําหนดเองข้ามกองเรือที่ได้รับผลกระทบ