Máy chủ chưa vá lỗ hổng GitLab CVE-2023-7028
- Lỗ hổng nghiêm trọng CVE-2023-7028 của GitLab vẫn chưa được vá trên hơn 5.300 máy chủ tính đến thứ Ba, có thể dẫn đến việc tài khoản của các nhà phát triển phần mềm bị chiếm đoạt từ xa.
- Lỗi này nhận điểm CVSS tối đa là 10 và đã được GitLab công bố lần đầu cũng như phát hành bản vá vào ngày 11 tháng 1.
- Do lỗ hổng trong hệ thống đăng nhập GitLab, kẻ tấn công có thể gửi liên kết đặt lại mật khẩu đến một địa chỉ email chưa được xác thực mà không cần bất kỳ tương tác nào từ nạn nhân.
Thông tin bản vá và kết quả kiểm thử lỗ hổng
- Các bản cập nhật bảo mật đã được phát hành cho GitLab phiên bản 16.5.6, 16.6.4, 16.7.2, đồng thời được backport sang các phiên bản 16.1.6, 16.2.9, 16.3.7, 16.4.5.
- Một nhà nghiên cứu đã kiểm thử lỗi trên GitLab Community Edition phiên bản 16.6.1 và chia sẻ trên AttackerKB rằng nó "rất hiệu quả và dễ khai thác".
Phát hiện các instance dễ bị tấn công và xu hướng sụt giảm
- Gần 2 tuần sau khi bản vá được cung cấp, Shadowserver Foundation đã phát hiện 5.379 instance GitLab dễ bị tấn công trên toàn cầu.
- Mỹ và Đức là hai nước có số lượng instance dễ bị tấn công nhiều nhất, lần lượt là 964 và 730.
- Công cụ dashboard của Shadowserver cho thấy số instance dễ bị tấn công đã giảm xuống còn 4.652 vào ngày 24 tháng 1.
- Trong xác nhận với SC Media, người phát ngôn của Shadowserver cho biết việc số instance dễ bị tấn công giảm là một tín hiệu tích cực, nhưng cần thêm thời gian để xác định liệu đây là xu hướng hay chỉ là biến động tạm thời.
Chỉ dấu xâm nhập của GitLab CVE-2023-7028
- Khách hàng GitLab đang vận hành các instance self-managed của GitLab Community Edition và GitLab Enterprise Edition nên rà soát log để kiểm tra xem CVE-2023-7028 có bị khai thác hay không.
- Cần kiểm tra các yêu cầu HTTP đến đường dẫn /users/password trong
gitlab-rails/production_json.log, và xác minh liệu params.value.email có được tạo thành từ một mảng JSON chứa nhiều địa chỉ email hay không.
- Cần kiểm tra trong
gitlabs-rails/audit_json.log các mục có meta.caller.id là PasswordsController#create và target_Details được tạo thành từ một mảng JSON chứa nhiều địa chỉ email.
- Trên GitLab.com hoặc các instance GitLab Dedicated, chưa phát hiện việc khai thác lỗi này.
- GitLab cũng khuyến nghị bật xác thực hai yếu tố (2FA); biện pháp này có thể ngăn chặn việc chiếm đoạt tài khoản thông qua CVE-2023-7028, nhưng người dùng các instance chưa vá vẫn có nguy cơ bị khóa khỏi tài khoản nếu kẻ tấn công lợi dụng lỗ hổng để đặt lại mật khẩu.
Ý kiến của GN⁺
- Bài viết này cung cấp thông tin quan trọng liên quan đến lỗ hổng bảo mật nghiêm trọng của GitLab. CVE-2023-7028 có thể trở thành mối đe dọa trực tiếp đối với an toàn tài khoản của các nhà phát triển phần mềm và cần có biện pháp phù hợp.
- Dù bản vá đã được cung cấp, vẫn còn rất nhiều máy chủ trên toàn thế giới ở trạng thái dễ bị tấn công, qua đó nhấn mạnh tầm quan trọng của nhận thức bảo mật và việc cập nhật kịp thời.
- Bài viết làm nổi bật tầm quan trọng của xác thực hai yếu tố (2FA) và khuyến nghị người dùng tận dụng thêm các biện pháp bảo mật, qua đó góp phần nâng cao nhận thức về an ninh.
1 bình luận
Ý kiến trên Hacker News
"Tôi muốn nói về mức độ rủi ro của tính năng 'liên kết địa chỉ email với tài khoản' trong các ứng dụng web dựa trên tài khoản. Đây là một trong những thứ mà pentester sẽ lập tức tìm cách khai thác, và lỗ hổng kiểu này đã được phát hiện từ đầu những năm 2000. Vấn đề này cũng tái diễn ở GitLab. GitLab có một đội ngũ bảo mật rất giỏi, nhưng dường như những lỗi như thế này rất khó tránh khỏi. Nếu bạn là một độc giả Hacker News bình thường quan tâm đến câu chuyện này, hãy kiểm tra chức năng đặt lại mật khẩu của chính mình, đặc biệt là logic liên kết email."
"Tôi chia sẻ liên kết tới commit nơi lỗ hổng này được phát hiện trong codebase Rails: liên kết commit GitLab"
"Tôi đã bị ảnh hưởng bởi lỗi này. Muốn tấn công thì phải biết email của người dùng, nhưng có các địa chỉ email ẩn được gắn với GitLab user ID (các số tăng dần từ 1). ID 1 hoặc 2 nhiều khả năng là quản trị viên, nên là mục tiêu tốt. Định dạng email là '1-user@mail.noreply.<gitlabhost>'. Có vẻ như đây là một cuộc tấn công tự động, và 2FA đã cứu chúng tôi."
"Đặt lại mật khẩu qua email là một cơn ác mộng về bảo mật, ngay cả khi được triển khai đúng cách. Ở hầu hết dịch vụ, bạn không thể vô hiệu hóa tính năng này, và lựa chọn thay thế thường chỉ là SSO doanh nghiệp. Một số dịch vụ cho phép thiết lập số điện thoại để nhận mã token qua SMS, nhưng tôi chưa từng thấy tùy chọn yêu cầu cả email lẫn mã token SMS cùng lúc."
"Tôi từng phát hiện một lỗi cho phép brute-force tài khoản bằng cách nhập một mảng mật khẩu vào form đăng nhập. Đó là một giao diện web rất tệ cho một thiết bị chống spam, và tôi không chắc đó là chủ ý hay do một người mới học PHP viết ra. Một người dùng khi đó đang dùng mật khẩu có ký tự đặc biệt đã phát hiện ra điều này."
"Điều này nhắc lại rằng các dịch vụ nội bộ như GitLab tốt nhất nên được vận hành sau một VPN, nơi chỉ người dùng đáng tin cậy mới có thể truy cập."
"Tự động hóa cập nhật GitLab rất dễ. Chỉ cần dùng GitLab trên Docker+Compose và cập nhật hằng ngày qua Watchtower hoặc công cụ tương tự. Tôi đã vận hành máy chủ GitLab theo cách này hơn 7 năm và không gặp vấn đề gì. Nhìn xung quanh vẫn thấy nhiều GitLab chạy phiên bản cũ; các quản trị viên đang làm gì vậy?"
"Tôi có nguyên tắc là không để bất kỳ loại máy chủ nội bộ nào lộ ra Internet công cộng. Chỉ cho phép truy cập qua VPN để tạo thêm một lớp phòng thủ thứ hai."
"Lại thêm một lời nhắc rằng luôn nên dùng SSO và đừng quên bật 2FA."
"Hãy thôi nghĩ rằng Ruby/Rails là lựa chọn phù hợp cho phần mềm cần phải an toàn. Tôi hiểu vì sao GitLab phải xử lý tình huống này, nhưng về lâu dài, chúng ta cần thừa nhận rằng thứ gì đó đơn giản hơn sẽ tốt hơn các ngôn ngữ và framework ưu tiên luồng điều khiển thông minh nhưng khó nhìn thấy. Tôi đang làm việc với một codebase Ruby chạy production, và tôi hoàn toàn có thể thấy những vấn đề tương tự xảy ra vì ai đó nghĩ rằng nhiều tầng abstraction đã làm cho code trở nên rất dễ mở rộng."