Tóm tắt
Ngoài việc cho phép người dùng cung cấp bộ khóa SSH của riêng mình để xác thực, nền tảng Microsoft Azure dựa vào bộ khóa SSH để cho phép một số tính năng được thêm vào máy ảo (VM) tại thời điểm triển khai. Gần đây, chúng tôi đã phát hiện ra rằng, trong một số trường hợp hạn chế, khóa công khai từ các chứng chỉ Nền tảng Azure này có thể bất ngờ được thêm vào tệp .ssh/authorized_keys. Những kịch bản này được giới hạn chỉ trong một tình huống trong đó máy ảo được cung cấp bằng cách sử dụng đám mây-init và người dùng chọn tính năng bổ sung Azure dựa vào chứng chỉ, chẳng hạn như một hệ thống quản lý dịch vụ nhận dạng.
Hành vi này không mong muốn xảy ra vì một sự thay đổi trong logic cung cấp hệ điều hành cụ thể. Đây là những hệ thống sử dụng đám mây init và vô tình cài đặt khóa công cộng từ tất cả các chứng chỉ có sẵn cho máy ảo vào ssh-ủy quyền khóa tập tin trong quá trình tạo máy ảo.
Để tìm hiểu thêm, hãy đi tới CVE-2019-0816.
Thông tin khác
Chi tiết kịch bản
Logic cloud-init được đề cập trong phần "Tóm tắt" hiện được biết đến là tồn tại trong Azure hình ảnh cho Ubuntu 18.04 ngoài xem trước công cộng RHEL 7.4/7.5/7.6 và hình ảnh đám mây init CentOS 7.4. Nó cũng có thể tồn tại trong hình ảnh tùy chỉnh bằng cách sử dụng các hệ điều hành.
Nếu bạn bật một trong các tính năng sau trong khi cung cấp một trong các hình ảnh Linux, bạn có thể thấy các phím bổ sung không mong muốn trong tệp .ssh/authorized_keys, chẳng hạn như bất kỳ thao tác nào sau đây:
- Danh tính được quản lý
- Tiện ích mở rộng có cài đặt được bảo vệ
- Triển khai máy ảo với Kho lưu trữ khóa phím trong máy ảo
Xác định và khắc phục các máy ảo hiện có
Xác định
Để kiểm tra xem bạn có khóa bổ sung hay không, hãy xem lại tệp khóa được ủy quyền (tệp vi .ssh/authorized_keys) để xác định xem có khóa bổ sung nào mà bạn không chủ định thêm hay không.
Bạn có thể an toàn để loại bỏ thủ công bất kỳ khóa công cộng ssh bổ sung nào có thể đã được thêm vào. Điều này sẽ không ảnh hưởng đến các tính năng được triển khai cùng với máy ảo. Ngoài ra, việc này cũng sẽ không ảnh hưởng đến cặp khóa SSH được chỉ định để xác thực.
Nếu bạn không biết hoặc không thể phân biệt khóa công khai nào trong tệp .ssh/authorized_keys xác thực, hãy làm theo các bước sau:
Xem lại mẫu triển khai của bạn:
- ssh khóa công cộng
- phím ssh trong cấu hình cloud-init
Truy xuất các phím ssh đã triển khai tại thời điểm tạo từ bên trong máy ảo, nếu bạn có quyền truy cập sudo/root. Để thực hiện điều này, hãy làm theo các bước sau:
- Kiểm tra cấu hình cloud-init được truyền trong CustomData: sudo cat /var/lib/waagent/ovf-env.xml | grep "<ns1:CustomData>"
Sử dụng giá trị CustomData rồi sử dụng giải mã cơ sở64 để nhận khóa công khai mà bạn đã triển khai:
- Kiểm tra cấu hình cloud-init được truyền trong CustomData: sudo cat /var/lib/waagent/ovf-env.xml | grep "<ns1:CustomData>"
echo "<customData value>" | base64 -D 2. Ngoài ra, hãy kiểm tra Phiên bản Dịch vụ Dữ liệu Siêu dữ liệu (IMDS) để xem khóa công khai ssh đã được chuyển vào thuộc tính khóa công khai ssh của VM Create: curl -H Metadata:true "http://169.254.169.254/metadata/instance/compute/publicKeys?api-version=2018-04-02&format=json"
Khắc phục
Nếu bạn đã xác định chứng chỉ bổ sung mà bạn không có ý định triển khai máy ảo, bạn có thể loại bỏ chúng bằng cách xóa dòng tương ứng từ tệp authorized_keys.
Chạy khắc phục bằng cách kết nối tương tác với máy ảo hoặc sử dụng Phần mở rộng Tập lệnh Tùy chỉnh hoặc RunCommand trên nhiều máy ảo.
Máy ảo được triển khai bằng cách sử dụng tiện ích mở rộng có cài đặt được bảo vệ hoặc danh tính được quản lý
Sử dụng tập lệnh sau để loại bỏ khóa công cộng khỏi chứng chỉ trong đó máy ảo đã được triển khai với phần mở rộng hoặc danh tính được quản lý. Thao tác này sẽ không loại bỏ các khóa đã được chỉ định khi bạn triển khai máy ảo hoặc nếu máy ảo đã được triển khai bằng các Kho lưu trữ khóa phím.
Quan trọng
Chúng tôi khuyên bạn nên sao lưu tệp authorized_keys trước khi chạy tập lệnh này.
#!/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
Sau khi tập lệnh đã chạy, hãy kiểm tra tệp ssh/authorized_keys để đảm bảo chỉ có (các) khóa công khai đã biết hiện diện.
Máy ảo được triển khai với Kho lưu trữ khóa mật
Để xác định xem khóa đã được thêm vào khi được triển khai bằng Phím Kho lưu trữ khóa, hãy làm theo các bước sau:
Nhận tên của chứng chỉ Kho lưu trữ khóa mà bạn đã triển khai bằng cách sử dụng máy ảo, xem lại mã triển khai mẫu Az CLI hoặc ARM hoặc chạy Az CLI này:
az vm show --resource-group <resourceGroupName> --name <vmName> | grep certificateUrlCâu trả lời sẽ hiển thị tên chứng chỉ:
"certificateUrl": "https://< keyVaultname.vault.azure.net/secrets/><certName>/xxxxxxxxxxxxx"Tải xuống chứng chỉ:
tải xuống chứng chỉ az keyvault --vault-name <keyVaultName> --name <certName> --encoding PEM --file public.pemTrích xuất khóa công khai:
openssl x509 -in public.pm -pubkey -noout | ssh-keygen -f /dev/stdin -i -m PKCS8So sánh đầu ra từ bước trước đó với các chứng chỉ còn lại trong tệp ssh/authorized_keys.
vi tệp .ssh/authorized_keys
Giải pháp
Azure hình ảnh MarketPlace
Các bản sửa lỗi đã được áp dụng cho cloud-init trong tệp được Azure hình ảnh:
- 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
Hình ảnh Tùy chỉnh
Nếu bạn đang sử dụng hình ảnh tùy chỉnh được cung cấp bởi cloud-init cho các hệ điều hành đã biết, bạn sẽ phải cập nhật hình ảnh tùy chỉnh nguồn của bạn.
Ubuntu 18.04 hình ảnh
Để cập nhật ảnh tùy chỉnh nguồn, bạn phải thực hiện sửa đổi sau đây:
Chỉnh sửa tệp sau:
/etc/cloud/cloud.cfg.d/90-azure.cfg
Thêm mã sau đây vào cuối tệp.
Quan trọng
Mã phải được thêm vào chính xác như được hiển thị, bao gồm khoảng trắng.
datasource:
Azure:
agent_command: [service, walinuxagent, start]
Hình ảnh RHEL 7.4/7.5/7.6 và CentOS 7.6
Nếu trước đây bạn đã tạo hình ảnh RHEL/CentOS bằng cách sử dụng các bước này (hoặc một phương pháp tương tự), bạn phải cập nhật hình ảnh nguồn mà bạn đã tạo máy ảo từ đó. Sau đây là các bước bổ sung cần thiết để thêm vào cấu hình hình ảnh máy ảo nguồn hiện có của bạn:
Bước 1
Chỉnh sửa tệp sau:
/etc/cloud/cloud.cfg.d/91-azure_datasource.cfg
Quan trọng
Mã phải được thêm vào chính xác như được hiển thị, bao gồm khoảng trắng.
Thêm các dòng sau vào cuối tệp:
datasource:
Azure:
agent_command: [systemctl, start, waagent, --no-block]
Bước 2
Cập nhật cấu hình Tác nhân như sau:
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
gói cloud-init
Tất cả các gói cloud-init bao gồm bản sửa lỗi đang được cập nhật. Microsoft đang nghiên cứu sự cố này và sẽ đăng thêm thông tin trong bài viết này khi có thông tin mới.
Câu hỏi thường gặp
Câu hỏi 1: Microsoft có được quyền truy cập vào máy ảo của tôi không?
A1: Khóa mã hóa được sử dụng để quản lý danh tính và phần mở rộng không được nhân viên Microsoft thiết kế để truy nhập. Chúng tôi có các quy trình tại chỗ để theo dõi, ghi nhật ký và ngăn chặn loại truy cập này. Để phòng ngừa an toàn, chúng tôi đang xem xét tất cả các bản ghi để đảm bảo rằng không có khóa khách hàng nào bị truy cập không phù hợp. Đối với chứng chỉ được lưu trữ trong Kho lưu trữ khóa được tham chiếu trong triển khai máy ảo hoặc VMSS, nhân viên Microsoft không có bất kỳ quyền truy cập nào vào các bí mật.
Câu hỏi 2: Có phải tất cả OS và phiên bản được triển khai trên đám mây đều bị ảnh hưởng không?
A2: Không. Chúng tôi đã thấy sự cố quan trọng không liên quan này chỉ xảy ra trong hệ điều hành được xác định. Chúng tôi đã không nhìn thấy nó xảy ra trong các phiên bản cũ hơn của Ubuntu. Điều này là do các hệ thống đó sử dụng cơ chế khác để đặt khóa công khai.
Câu hỏi 3: Các gói cloud-init bị ảnh hưởng đối với phân phối Linux có bao gồm bản sửa lỗi không?
A3: Chúng tôi đang nỗ lực thêm bản sửa lỗi vào gói dành cho các phiên bản bị ảnh hưởng và chúng tôi sẽ cập nhật bài viết này khi công việc đó hoàn tất.
Câu hỏi 4: Microsoft có tự động cập nhật bất kỳ máy ảo bị ảnh hưởng nào không?
A4: Không. Microsoft sẽ không thay đổi nội dung của máy ảo mà bạn đã cung cấp.
Q5: Các chính sách bảo mật của chúng tôi ngăn tôi vận hành một máy ảo Linux với nội dung không liên quan authorized_keys. Hôm nay tôi có thể làm gì?
A5: Bạn có thể xóa dòng vi phạm một cách an toàn khỏi authorized_keys đó. Điều này sẽ không ảnh hưởng đến bộ khóa SSH mà bạn đã tạo và kiểm soát hoặc danh tính được quản lý. Bạn có thể thực hiện việc này theo cách thủ công hoặc bằng cách chạy một tập lệnh tùy chỉnh hoặc lệnh tùy chỉnh trên bất kỳ hạm đội bị ảnh hưởng nào.