Lỗ hổng SSH trên Alpine Linux cho phép đăng nhập không cần mật khẩu bằng chuỗi dài

Alpine Linux đã phát hành một cảnh báo bảo mật khẩn cấp về lỗ hổng nghiêm trọng trong triển khai máy chủ OpenSSH của hệ thống này. Lỗi này cho phép kẻ tấn công từ xa bỏ qua hoàn toàn xác thực mật khẩu và truy cập shell vào các hệ thống bị ảnh hưởng mà không cần biết bất kỳ thông tin đăng nhập nào. Quản trị viên đang chạy các phiên bản Alpine từ 3.16 đến 3.24 cần cập nhật gói openssh và khởi động lại daemon SSH ngay lập tức để khắc phục rủi ro này.

Chuyện gì đã xảy ra

Lỗ hổng ảnh hưởng đến daemon sshd khi nó được xây dựng mà không có Các mô-đun xác thực cắm được (Pluggable Authentication Modules - PAM), đây là cấu hình mặc định của gói openssh-server chuẩn trên Alpine. Kẻ tấn công có thể tiếp cận cổng SSH có thể đăng nhập với tư cách bất kỳ tài khoản người dùng nào chưa đặt mật khẩu, miễn là hệ thống có ít nhất một tài khoản cục bộ khác chứa hash mật khẩu tiêu chuẩn. Cuộc tấn công chỉ yêu cầu một lần thử kết nối duy nhất và thành công đáng tin cậy mà không cần thử lại hay sử dụng kỹ thuật brute-force.

Vấn đề này tác động đến nhiều phiên bản Alpine, bao gồm các phiên bản được hỗ trợ từ 3.21 đến 3.24 và các phiên bản cũ hơn không còn được hỗ trợ trở về trước đến 3.16. Nó nhắm mục tiêu cụ thể vào các hệ thống nơi PasswordAuthentication được bật, vốn vẫn là mặc định của OpenSSH trừ khi được tắt rõ ràng. Các kịch bản phổ biến bao gồm tài khoản root được cấu hình với PermitRootLogin yes, người dùng chỉ dùng khóa được tạo mà không có mật khẩu, và người dùng được quản lý qua các dịch vụ thư mục như SSSD hoặc Winbind thiếu các mục shadow cục bộ.

Các hình ảnh tiny-cloud chính thức đặc biệt dễ bị tổn thương nếu chúng đã được sửa đổi sau lần khởi động đầu tiên. Mặc dù các hình ảnh này đi kèm với các thiết lập mặc định an toàn, việc thêm bất kỳ người dùng nào có hash mật khẩu hoặc đặt mật khẩu console sẽ tạo ra điều kiện cần thiết cho cuộc khai thác. Một khi được kích hoạt, kẻ tấn công có thể đăng nhập với tư cách người dùng alpine mặc định và leo thang quyền lên root bằng cách sử dụng doas, vốn được cấu hình để sử dụng không cần mật khẩu trong các môi trường này.

Cách thức hoạt động

Nguyên nhân gốc rễ nằm ở cách OpenSSH xử lý xác minh mật khẩu khi được biên dịch mà không có hỗ trợ PAM. Trong chế độ này, sshd sử dụng hàm thư viện C crypt() để băm mật khẩu được cung cấp và so sánh nó với hash lưu trữ trong /etc/shadow. Đối với các tài khoản không có mật khẩu, trường lưu trữ chứa một dấu hoa thị (*). Thông thường, crypt() yêu cầu một salt từ hash lưu trữ để xử lý đầu vào, nhưng các tài khoản có * không có salt.

Khi gặp phải tài khoản như vậy, sshd mượn salt từ một tài khoản khác trên hệ thống có hash $5$ hoặc $6$ hợp lệ. Lỗ hổng được kích hoạt khi kẻ tấn công gửi một chuỗi mật khẩu có độ dài từ 257 đến 1024 byte. Thư viện C musl, được Alpine sử dụng, trả về * như một chỉ báo lỗi khi xử lý các khóa dài hơn 256 byte. Vì trường lưu trữ cho tài khoản mục tiêu cũng là *, phép so sánh khớp nhau và xác thực thành công.

Chi tiết chính

• Phiên bản bị ảnh hưởng: Alpine 3.16 đến 3.24, bao gồm cả edge và các bản phát hành không còn được hỗ trợ.
• Điều kiện tiên quyết: sshd được xây dựng không có PAM (hoặc UsePAM no), PasswordAuthentication yes, và ít nhất một tài khoản có hash $5$ hoặc $6$.
• Tài khoản mục tiêu: Người dùng có * trong trường mật khẩu, chẳng hạn như người dùng chỉ dùng khóa hoặc người dùng alpine mặc định.
• Gói đã sửa lỗi: Có sẵn cho tất cả các nhánh, bao gồm 9.9_p2-r1 cho 3.21 và 10.6_p2-r0 cho edge.
• Phát hiện: Kiểm tra /var/log/messages cho các mục nhập Accepted password for liên kết với các tài khoản không có mật khẩu.
• Rủi ro đám mây: Hình ảnh tiny-cloud trở nên dễ bị khai thác nếu bất kỳ hash mật khẩu nào được thêm sau khi khởi động.

Tại sao điều này quan trọng

Đối với các kỹ sư hạ tầng và đội ngũ DevOps, lỗ hổng này phá vỡ giả định cơ bản rằng các tài khoản SSH chỉ dùng khóa là an toàn trước các cuộc tấn công dựa trên mật khẩu. Nhiều tổ chức dựa vào Alpine cho các container và VM nhẹ, thường cho rằng việc vô hiệu hóa đăng nhập mật khẩu root là đủ. Tuy nhiên, lỗi này vượt qua các biện pháp bảo vệ đó bằng cách khai thác sự tương tác giữa các trường mật khẩu trống và sự hiện diện của các mật khẩu đã băm khác trên hệ thống. Nó làm nổi bật rủi ro của các cấu hình mặc định trong các bản phân phối tối giản nơi PAM không được sử dụng.

Sự dễ dàng trong khai thác khiến điều này đặc biệt nguy hiểm. Không giống như các cuộc tấn công brute-force tạo ra tiếng ồn và có thể bị chặn bởi fail2ban, phương pháp này chỉ yêu cầu một gói tin và không để lại dấu vết ngay lập tức của các lần thử thất bại. Nếu kẻ tấn công giành được quyền truy cập vào một instance đám mây, họ có thể nhanh chóng leo thang quyền hạn và di chuyển ngang trong mạng. Các đội ngũ phải xác minh không chỉ rằng họ đã cập nhật các gói, mà còn rằng daemon đang chạy thực sự đã được khởi động lại, vì các trình quản lý gói không luôn tự động khởi động lại các dịch vụ.

Bạn có thể làm gì

• Cập nhật hệ thống của bạn ngay lập tức bằng cách sử dụng apk upgrade -U -a và đảm bảo bạn cài đặt phiên bản đã sửa lỗi cho nhánh của mình.
• Khởi động lại daemon SSH một cách tường minh bằng rc-service sshd restart sau khi nâng cấp, vì bản thân việc cập nhật không nạp lại tiến trình đang chạy.
• Nếu bạn không thể cập nhật ngay lập tức, hãy vô hiệu hóa xác thực mật khẩu bằng cách đặt PasswordAuthentication no trong cấu hình SSH của bạn và khởi động lại dịch vụ.
• Xác minh cấu hình của bạn bằng sshd -T | grep -i passwordauthentication để đảm bảo thay đổi đã có hiệu lực.
• Kiểm toán nhật ký của bạn để tìm các mục nhập Accepted password không mong muốn cho các tài khoản lẽ ra không nên có mật khẩu.
• Xem xét các instance đám mây để tìm bất kỳ hash mật khẩu người dùng nào được thêm vào có thể đã vô tình kích hoạt lỗ hổng.