OpenSSH phát hành bản vá khẩn cấp cho lỗ hổng cho phép mật khẩu dài vượt qua xác thực SSH trên Alpine Linux

Lỗ hổng nghiêm trọng trên Alpine Linux

OpenSSH vừa phát hành bản vá khẩn cấp 10.6p2 cho một lỗ hổng được đánh giá ở mức nghiêm trọng, cho phép kẻ tấn công đăng nhập vào các tài khoản không đặt mật khẩu trên một số máy chủ Alpine Linux chạy gói openssh-server tiêu chuẩn. Điều kiện cần là quyền truy cập mạng tới máy chủ, tên tài khoản và một mật khẩu dài từ 257 đến 1.024 byte. Alpine đã phát hành gói đã vá cho mọi phiên bản từ 3.16 trở đi.

Lỗ hổng phát sinh từ cách sshd tương tác với musl, thư viện C mà Alpine sử dụng. Các hệ thống không phải Linux, hệ thống Linux dựa trên glibc và hệ thống xác thực mật khẩu qua PAM không bị ảnh hưởng. Ông Damien Miller của dự án OpenSSH khuyến cáo những ai đang chạy hệ thống bị ảnh hưởng nên đặt PasswordAuthentication=no hoặc vô hiệu hóa SSH ngay lập tức. Chưa có báo cáo nào về việc lỗ hổng bị khai thác.

Điều kiện để bị tấn công

Theo khuyến cáo bảo mật của Alpine, máy chủ bị phơi nhiễm khi thỏa mãn đồng thời bốn điều kiện:

• Chạy gói openssh-server được build không có PAM, hoặc openssh-server-pam với UsePAM no
• PasswordAuthentication được đặt là yes (mặc định của OpenSSH)
• Có một tài khoản với trường mật khẩu là * (nghĩa là không đặt mật khẩu)
• Có ít nhất một tài khoản khác có hash mật khẩu bắt đầu bằng $5$ hoặc $6$

Kẻ tấn công cũng cần biết tên tài khoản không mật khẩu. Chỉ một tài khoản có mật khẩu là đủ để làm lộ mọi tài khoản không mật khẩu, và theo khuyến cáo, cuộc tấn công thành công ở mọi lần thử chỉ với một kết nối.

Trên Alpine, các tài khoản không mật khẩu bao gồm người dùng chỉ dùng khóa tạo bằng adduser không mật khẩu hoặc usermod -p '*', người dùng đến từ dịch vụ thư mục qua musl-nscd, tài khoản root (vốn là root:* trong image cơ sở từ khoảng Alpine 3.16) và tài khoản alpine trong các image cloud chính thức build bằng tiny-cloud. Root được bảo vệ bởi thiết lập mặc định PermitRootLogin prohibit-password, nhưng lớp bảo vệ này vô hiệu nếu tài khoản bị lộ có thể chuyển sang root, chẳng hạn qua doas. Các image tiny-cloud từ 3.18.11 đến 3.24.3 cấp cho người dùng alpine quyền doas không mật khẩu, an toàn ở lần khởi động đầu nhưng trở nên dễ bị tấn công khi xuất hiện bất kỳ hash $6$ nào trên máy.

Các container không chạy sshd, hệ thống đặt PasswordAuthentication no, image cloud cấu hình qua cloud-init, tài khoản bị khóa bằng ! trong /etc/shadow và máy không có tài khoản nào dùng hash mật khẩu kiểu $ đều không bị ảnh hưởng.

Không chỉ Alpine

Ông Özgün Kültekin, người báo cáo lỗ hổng, chỉ ra OpenWrt, Buildroot và Yocto là các hệ thống dựa trên musl khác cần kiểm tra. OpenWrt mặc định dùng Dropbear cho SSH và theo Kültekin, Dropbear không bị ảnh hưởng; trên OpenWrt, lỗ hổng chỉ có ý nghĩa khi quản trị viên đã cài máy chủ OpenSSH.

Cách khắc phục

Trên Alpine, cần cập nhật gói rồi khởi động lại vì việc nâng cấp không tự khởi động lại sshd đang chạy:

• Cập nhật gói: apk upgrade -U -a
• Khởi động lại máy chủ: rc-service sshd restart

Các bản 3.21.10, 3.22.8, 3.23.8 và 3.24.4 đã bao gồm gói đã vá. Các nhánh 3.16 đến 3.21 đã hết hỗ trợ nhưng cũng nhận được gói vá. Nếu tự build OpenSSH, phiên bản 10.6p2 đã chứa thay đổi. Nếu chưa thể cập nhật, tắt đăng nhập bằng mật khẩu cũng chặn được cuộc tấn công: trước tiên đảm bảo đăng nhập bằng khóa SSH hoạt động và giữ phiên hiện tại mở cho đến khi đăng nhập mới thành công, sau đó đặt PasswordAuthentication no, kiểm tra cấu hình bằng sshd -t rồi khởi động lại sshd. Khuyến cáo cũng đề nghị kiểm tra /var/log/messages để tìm các dòng sshd ghi Accepted password cho tài khoản không mật khẩu, đồng thời rà soát việc dùng doas, người dùng mới tạo, tệp và authorized keys. "Nếu không thể loại trừ khả năng đã có đăng nhập, hãy coi máy đã bị xâm phạm", khuyến cáo nêu.

Vì sao mật khẩu dài lại vượt qua được

Khi không có PAM, sshd tự kiểm tra mật khẩu bằng cách băm thử với crypt() rồi so sánh với trường lưu trữ. Tài khoản không mật khẩu chỉ có * trong trường này, quá ngắn để chứa salt, nên sshd mượn salt của tài khoản khác có hash thật. Với hash kiểu $5$ và $6$, crypt() của musl từ chối mật khẩu dài hơn 256 byte và trả về *, trùng với * đã lưu nên sshd chấp nhận đăng nhập; giới hạn trên 1.024 byte là của chính sshd. Hành vi này bắt nguồn từ thay đổi của musl ngày 9/8/2012 khiến lệnh crypt() thất bại trả về "hash không thể khớp" thay vì NULL, và giới hạn 256 byte được thêm ngày 29/8/2012. Việc mượn salt đến từ thay đổi của OpenSSH ngày 15/7/2016 nhằm xử lý CVE-2016-6210; theo Kültekin, vấn đề đã tồn tại từ đó. Bản 10.6p2 khiến sshd từ chối khớp khi trường lưu trữ ngắn hơn bốn ký tự, được OpenSSH gọi là biện pháp tạm thời vì nguyên nhân gốc nằm ngoài sshd. Gói ổn định của Alpine mang bản vá cho cùng vấn đề.

Vì sao bản vá ra đời chỉ sau một ngày

Nhóm của Miller biết về lỗ hổng đầu tuần này và phát hành bản vá nhanh nhất có thể. Trong thông báo phát hành, ông cho biết nhóm nay xem các thời gian cấm công bố dài là nguy hiểm và chủ yếu có lợi cho kẻ tấn công, vì gần đây họ thấy các AI agent tìm lại đúng những lỗi như vậy, có khi chỉ trong vài giờ. Tính đến hôm nay, lỗ hổng chưa được gán mã CVE.

Nguồn: The Hacker News