Lỗ hổng từ địa chỉ email tạo issue trên GitLab: Nguy cơ bị chiếm quyền đẩy code và chạy CI/CD

Các chuyên gia bảo mật từ Aikido Security vừa cảnh báo về một cơ chế bảo mật tiềm ẩn rủi ro cao trên GitLab liên quan đến tính năng tạo issue qua email. Vấn đề nằm ở chỗ, địa chỉ email mà GitLab cung cấp cho người dùng để tạo issue thực chất là một loại credential (thông tin xác thực) có quyền hạn đáng kể.

Cơ chế tấn công

Mỗi người dùng GitLab được cấp một địa chỉ email riêng biệt để gửi yêu cầu tạo issue hoặc merge request. Tuy nhiên, chuỗi ký tự trong địa chỉ này chứa một token cố định, không có thời hạn hết hiệu lực và áp dụng cho tất cả các dự án mà tài khoản đó có quyền truy cập. Điều nguy hiểm là GitLab không xác thực người gửi email; bất kỳ ai nắm giữ địa chỉ này đều có thể mạo danh chủ tài khoản để thực hiện các hành động sau:

• Đẩy code trái phép: Bằng cách thay đổi hậu tố của email từ -issue thành -merge-request, kẻ tấn công có thể gửi các bản vá (patch) đính kèm. GitLab sẽ tự động áp dụng các thay đổi này vào nhánh mục tiêu, kể cả nhánh main, dưới danh nghĩa của chủ tài khoản.
• Thực thi CI/CD: Nếu bản vá chỉnh sửa file .gitlab-ci.yml, kẻ tấn công có thể kích hoạt các job CI/CD chạy với quyền hạn của người dùng bị lộ token.

Đáng chú ý, cơ chế này hoàn toàn bỏ qua các hạn chế về IP và không yêu cầu xác thực hai yếu tố (2FA), ngay cả khi hệ thống đã được cấu hình bảo mật nghiêm ngặt.

Phạm vi ảnh hưởng

Mức độ thiệt hại phụ thuộc vào vai trò của người dùng bị lộ token. Nếu một tài khoản có quyền Maintainer bị lộ địa chỉ email, kẻ tấn công có thể truy cập vào các nhánh được bảo vệ và các biến môi trường (secrets) của CI/CD. Mặc dù GitLab yêu cầu kẻ tấn công phải biết đường dẫn dự án (project path) và ID, nhưng thông tin này thường dễ dàng tìm thấy đối với các dự án công khai (public).

Cách phòng tránh

Hiện tại, GitLab chưa cung cấp tùy chọn để người dùng cá nhân vô hiệu hóa tính năng này. Để tự bảo vệ, người dùng và quản trị viên nên thực hiện các biện pháp sau:

• Reset token: Truy cập vào trang quản lý Personal Access Tokens trong hồ sơ cá nhân để reset lại token email. Lưu ý rằng hành động này sẽ vô hiệu hóa tất cả các địa chỉ email cũ trên mọi dự án.
• Rà soát thông tin công khai: Kiểm tra kỹ các file README, hướng dẫn đóng góp (contributing guides) hoặc các trang hỗ trợ để đảm bảo địa chỉ email này không bị vô tình công khai trên các kho lưu trữ mã nguồn.
• Đối với quản trị viên (Self-managed): Có thể tắt hoàn toàn tính năng nhận email (incoming email) cho toàn bộ instance nếu không thực sự cần thiết.

Phía GitLab cho biết họ đang xem xét việc chỉ chấp nhận email từ các địa chỉ đã được xác thực, tuy nhiên tính năng này vẫn đang trong giai đoạn nghiên cứu và chưa được triển khai.

Nguồn tham khảo: The Hacker News