Cuộc tấn công chuỗi cung ứng của Qubole làm lộ các bí mật AWS thông qua các vai trò IAM được tin cậy

Từ ngày 14 đến ngày 26 tháng 10 năm 2026, một kẻ tấn công đã xâm phạm nhiều tài khoản AWS thuộc về khách hàng của Qubole, một nền tảng data lake do Idera sở hữu. Công ty an ninh đám mây Wiz báo cáo rằng kẻ xâm nhập đã sử dụng thông tin đăng nhập bị đánh cắp từ chính tài khoản AWS của Qubole để vượt qua các biện pháp kiểm soát bảo mật và truy cập vào môi trường của khách hàng.

Việc vi phạm này làm nổi bật một lỗ hổng nghiêm trọng trong cách các nhà cung cấp bên thứ ba được cấp quyền truy cập vào cơ sở hạ tầng đám mây. Bằng cách khai thác các vai trò Identity and Access Management (IAM) được tin cậy, kẻ tấn công đã có thể trích xuất các bí mật nhạy cảm và sao chép khối lượng lớn dữ liệu mà không cần phải phá vỡ mật khẩu người dùng riêng lẻ hay khai thác các lỗi ở cấp độ ứng dụng.

Chuyện gì đã xảy ra

Qubole hoạt động trong các tài khoản AWS của khách hàng bằng cách giả mạo các vai trò IAM mà khách hàng tạo riêng cho nền tảng. Các vai trò này bao gồm một chính sách tin cậy cho phép tài khoản AWS của Qubole tiếp nhận các quyền hạn của vai trò đó. Để xác thực các yêu cầu này, AWS yêu cầu một External ID, một mã do Qubole cung cấp. Kẻ tấn công đã lấy được thông tin đăng nhập cho tài khoản AWS trung tâm của Qubole và sử dụng chúng để gửi các yêu cầu AssumeRole tới các tài khoản của khách hàng.

Các nhà nghiên cứu của Wiz lưu ý rằng nhiều vai trò bị xâm phạm không được khách hàng sử dụng nhưng vẫn còn hoạt động trong cấu hình của họ. Vì mối quan hệ tin cậy vẫn còn hiệu lực, các yêu cầu của kẻ tấn công đã được chấp nhận miễn là chúng bao gồm External ID chính xác. Điều này cho phép kẻ xâm nhập di chuyển ngang qua nhiều môi trường khách hàng trong khoảng thời gian hai tuần.

Ngoài cuộc xâm nhập dựa trên vai trò, một hoạt động riêng biệt nhưng không liên quan đã diễn ra từ ngày 8 đến ngày 11 tháng 10. Trong giai đoạn này, một kẻ tấn công đã sử dụng các khóa truy cập AWS được cho là thiết lập cho Qubole để xâm phạm một số môi trường đám mây. Wiz chưa kết nối sự kiện sớm hơn này với chiến dịch chính liên quan đến việc lạm dụng AssumeRole.

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

Cơ chế cốt lõi của cuộc tấn công này dựa trên mẫu truy cập giữa các tài khoản tiêu chuẩn của AWS. Khi một nhà cung cấp như Qubole cần quản lý tài nguyên trong tài khoản của khách hàng, khách hàng sẽ tạo một vai trò IAM với chính sách tin cậy trỏ tới ID tài khoản của nhà cung cấp. Sau đó, nhà cung cấp sử dụng lệnh gọi API AssumeRole để tạm thời có được các quyền hạn đó. External ID nhằm mục đích ngăn chặn các vấn đề deputy bị nhầm lẫn, nhưng nó không phải là một bí mật. Nó hiển thị trong nhật ký CloudTrail và thường được lưu trữ trong các tệp cơ sở hạ tầng dưới dạng mã (infrastructure-as-code).

Sau khi xâm nhập, kẻ tấn công không cần đoán mật khẩu. Họ ngay lập tức bắt đầu thu thập các thông tin đăng nhập hiện có. Kẻ xâm nhập đọc các biến môi trường từ các hàm Lambda, rút các bí mật từ AWS Secrets Manager và truy cập các giá trị trong SSM Parameter Store. Để xác minh những thông tin đăng nhập nào hợp lệ, kẻ tấn công đã sử dụng TruffleHog, một công cụ mã nguồn mở để phát hiện bí mật, nhằm thử nghiệm các khóa truy cập AWS, bí mật khách hàng Entra ID và thông tin đăng nhập khách hàng Okta.

Việc đánh cắp dữ liệu mang tính chất rộng rãi thay vì nhắm mục tiêu cụ thể. Kẻ tấn công sao chép dữ liệu từ bất kỳ bucket S3 nào mà vai trò giả mạo có thể truy cập. Trong một số trường hợp, toàn bộ các bucket đã được tải xuống trong một phiên duy nhất. Vì các vai trò thường có quyền đọc rộng rãi cho sự tiện lợi, kẻ tấn công có thể truy cập lượng lớn thông tin được lưu trữ mà không cần leo thang đặc quyền thêm.

Chi tiết chính

• Tài khoản tấn công: Các yêu cầu AssumeRole độc hại bắt nguồn từ ID tài khoản AWS 805246085872, thuộc về Qubole.
• Khung thời gian: Cuộc tấn công chính dựa trên vai trò diễn ra từ ngày 14 đến ngày 26 tháng 10 năm 2026.
• Chỉ dấu xâm phạm: Tìm kiếm các yêu cầu AssumeRole từ tài khoản 805246085872 với địa chỉ IP nguồn nằm ngoài AWS, đặc biệt là từ các dải VPN OVH hoặc Mullvad.
• Người dùng IAM cụ thể: Điều tra hoạt động từ các ID chính IAM AIDA3W7DIFLYOLTK63SFS và AIDAJYRRH5Y3A7AAJM2HW nếu chúng bắt nguồn từ các IP không thuộc AWS.
• Công cụ: Kẻ tấn công đã sử dụng TruffleHog để xác thực các thông tin đăng nhập bị đánh cắp, có thể nhận diện qua user agent trong các lệnh gọi GetCallerIdentity.
• Khoảng trống ghi log: Nhiều nạn nhân thiếu các sự kiện dữ liệu S3 hoặc nhật ký truy cập máy chủ, khiến việc xác định chính xác những đối tượng nào đã được đọc trở nên bất khả thi.

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

Đối với các nhóm kỹ thuật, sự cố này nhấn mạnh rủi ro từ quyền truy cập của nhà cung cấp đang ngủ đông. Ngay cả khi một dịch vụ không còn được sử dụng tích cực, các vai trò IAM và chính sách tin cậy thường vẫn còn tồn tại. Những kết nối bị lãng quên này tạo ra một bề mặt tấn công rộng lớn mà kẻ tấn công có thể khai thác nếu thông tin đăng nhập trung tâm của nhà cung cấp bị xâm phạm. Nó chuyển gánh nặng bảo mật từ việc chỉ bảo vệ chu vi của chính bạn sang việc xác minh vệ sinh của mọi tích hợp bên thứ ba.

Cuộc tấn công cũng chứng minh những hạn chế của External ID như một biện pháp kiểm soát bảo mật. Vì chúng không phải là bí mật, chúng không thể ngăn chặn truy cập trái phép nếu thông tin đăng nhập của tài khoản tin cậy bị đánh cắp. Các kỹ sư phải đối xử với các vai trò của nhà cung cấp với cùng mức độ giám sát chặt chẽ như các vai trò quản trị nội bộ, áp dụng các điều kiện mạng nghiêm ngặt và nguyên tắc đặc quyền tối thiểu (least-privilege). Việc dựa vào các hướng dẫn thiết lập mặc định, vốn thường cấp quyền đọc S3 rộng rãi, có thể dẫn đến mất dữ liệu thảm khốc khi các vai trò đó bị lạm dụng.

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

• Kiểm toán nhật ký CloudTrail từ ngày 1 tháng 10 năm 2026 trở đi để tìm các yêu cầu AssumeRole từ tài khoản 805246085872 bắt nguồn từ các địa chỉ IP không thuộc AWS.
• Xoay vòng tất cả các bí mật, tham số và biến môi trường Lambda có thể truy cập bởi bất kỳ vai trò Qubole nào có dấu hiệu bị xâm phạm, và thu hồi các phiên hoạt động.
• Xóa bất kỳ vai trò IAM Qubole nào không còn cần thiết hoặc cập nhật chính sách tin cậy để loại bỏ ID tài khoản của Qubole nếu dịch vụ bị ngừng.
• Thêm các điều kiện aws:SourceIp hoặc aws:SourceVpce vào chính sách tin cậy của vai trò nhà cung cấp để hạn chế quyền truy cập vào các dải mạng đã được tài liệu hóa của nhà cung cấp.
• Bật các sự kiện dữ liệu S3 hoặc nhật ký truy cập máy chủ cho tất cả các bucket chứa dữ liệu nhạy cảm để đảm bảo khả năng hiển thị tương lai đối với quyền truy cập cấp độ đối tượng.
• Thay thế principal :root toàn tài khoản trong các chính sách tin cậy bằng các principal IAM cụ thể nơi được hỗ trợ, và sử dụng các External ID duy nhất cho mỗi vai trò.