Qubole bị lợi dụng quyền truy cập AWS để xâm nhập tài khoản khách hàng

Công ty bảo mật đám mây Wiz cho biết một kẻ tấn công đã xâm nhập vào tài khoản AWS của nhiều khách hàng Qubole trong khoảng thời gian từ 14/10 đến 26/10, đánh cắp các thông tin bí mật được lưu trữ cùng dữ liệu. Kẻ tấn công sử dụng thông tin xác thực của một tài khoản AWS mà nền tảng Qubole dùng để truy cập vào các tài khoản khách hàng. Cách kẻ tấn công có được thông tin xác thực này chưa được công bố.

Qubole là nền tảng data lake thuộc sở hữu của Idera, hoạt động bên trong tài khoản AWS của khách hàng. Để được truy cập, khách hàng tạo một IAM role, tức một danh tính AWS có bộ quyền riêng. Chính sách tin cậy của role cho phép tài khoản AWS của Qubole đảm nhận role đó. Mỗi yêu cầu như vậy, gọi là AssumeRole, phải kèm một mã khớp do Qubole cung cấp gọi là External ID.

Theo các nhà nghiên cứu của Wiz, ngoài vụ tấn công, phần lớn các role mà kẻ tấn công đảm nhận đều không còn được sử dụng. Tuy nhiên mỗi role vẫn tin cậy tài khoản của Qubole nên các yêu cầu của kẻ tấn công vẫn thành công.

Dấu hiệu và phạm vi ảnh hưởng

Bất kỳ tổ chức nào từng kết nối Qubole với AWS, kể cả tổ chức không còn dùng, nên kiểm tra log CloudTrail từ ngày 1/10. Dấu hiệu cần tìm là yêu cầu AssumeRole từ tài khoản mà nền tảng Qubole sử dụng, số 805246085872, xuất phát từ một địa chỉ ngoài AWS. Các nhà nghiên cứu không cho biết thông tin xác thực đã bị vô hiệu hóa hay hoạt động này đã dừng lại chưa. Khi The Hacker News kiểm tra, cả Qubole và Idera đều chưa đăng tuyên bố về vụ tấn công trên website.

Vì sao các role cho phép kẻ tấn công xâm nhập

Theo phân tích kỹ thuật của nhóm nghiên cứu, mọi yêu cầu AssumeRole gắn với kẻ tấn công đều mang External ID và được chấp nhận. AWS chấp nhận yêu cầu AssumeRole cho role như vậy khi yêu cầu đến từ tài khoản được tin cậy và có đúng External ID. Theo hướng dẫn của AWS về external ID, mã này không được coi là bí mật và bất kỳ ai có quyền truy cập role đều có thể xem.

Sentra đã phát hiện hoạt động này trong môi trường của một số khách hàng và báo cho nhóm nghiên cứu. Trong các tài khoản được kiểm tra, kẻ tấn công tìm kiếm thông tin xác thực được lưu trữ: đọc biến môi trường của các hàm Lambda, lấy bí mật từ Secrets Manager và đọc giá trị từ SSM Parameter Store. Sau đó kẻ tấn công chạy các thông tin xác thực tìm được qua TruffleHog để kiểm tra xem có dùng được không, gồm access key AWS của chính nạn nhân, client secret Entra ID và thông tin xác thực client Okta.

Kẻ tấn công còn sao chép dữ liệu ra khỏi S3, lấy dữ liệu từ bất kỳ bucket nào mà role truy cập được thay vì tìm dữ liệu cụ thể, và đôi khi tải toàn bộ bucket trong một phiên. Nhóm nghiên cứu chưa liên kết chiến dịch này với hoạt động nào khác đã được báo cáo công khai và cho rằng mục tiêu không giống những gì các nhóm được nhà nước hậu thuẫn thường nhắm tới.

Qubole cũng cho phép khách hàng kết nối bằng access key AWS thay vì role. Từ ngày 8/10 đến 11/10, một kẻ tấn công đã dùng access key AWS của chính khách hàng, mà nhóm nghiên cứu tin là được thiết lập cho Qubole. Kẻ tấn công này sau đó xâm phạm một số môi trường đám mây của nạn nhân. Hoạt động này chưa được liên kết với việc lạm dụng AssumeRole.

Cách kiểm tra tài khoản

Hướng dẫn điều tra của Wiz bao quát log CloudTrail từ ngày 1/10 ở mọi tài khoản AWS có role Qubole. Cần tìm:

• Tài khoản: yêu cầu AssumeRole có userIdentity.accountId là 805246085872 và sourceIPAddress không phải địa chỉ AWS. Nhóm nghiên cứu thấy lưu lượng thật của Qubole chỉ đến từ AWS.
• IAM principal ID AIDA3W7DIFLYOLTK63SFS: mọi hoạt động từ người dùng IAM này cần được điều tra, vì chỉ kẻ tấn công dùng nó trong các tài khoản được kiểm tra.
• IAM principal ID AIDAJYRRH5Y3A7AAJM2HW khi địa chỉ nguồn nằm ngoài AWS. Kẻ tấn công dùng người dùng IAM này từ ngày 18/10, nhưng lưu lượng bình thường của Qubole cũng dùng nó.
• IP 57.129.54[.]120 và 2001:41d0:70d[:]7800::, địa chỉ do OVH lưu trữ mà kẻ tấn công đã dùng.
• IP 45.83.220[.]211, 185.209.199[.]73 và 89.37.63[.]175, là địa chỉ VPN Mullvad. Người dùng VPN khác cũng chia sẻ các địa chỉ này nên trùng khớp đơn thuần chưa phải bằng chứng.
• Tên phiên: các phiên role bắt đầu bằng quiam-, ví dụ quiam-enum.
• User agent: TruffleHog trên các lệnh gọi GetCallerIdentity từ một trong các địa chỉ IP trên. Cần tìm cùng user agent trong log đăng nhập của nhà cung cấp danh tính.

Với mỗi phiên đáng ngờ, cần xem lại mọi thứ phiên đó đã làm sau đó, đặc biệt ở Secrets Manager, SSM Parameter Store, Lambda và S3. Sự kiện quản lý của CloudTrail ghi lại từng yêu cầu AssumeRole và việc liệt kê bucket, nhưng không ghi object S3 nào bị đọc. Điều này cần sự kiện dữ liệu S3 hoặc log truy cập máy chủ S3. Một số nạn nhân thiếu log cần thiết nên lực lượng ứng cứu không xác định được object nào kẻ tấn công đã đọc.

Cách đóng lối xâm nhập

Nhóm nghiên cứu khuyến nghị các bước sau:

• Nếu kẻ tấn công đã đảm nhận một role Qubole của bạn, hãy xoay vòng mọi bí mật, tham số và biến môi trường Lambda mà role đó truy cập được, đồng thời thu hồi các phiên đang hoạt động của role. Xoay vòng thông tin xác thực không kết thúc các phiên đã được cấp trước đó.
• Xóa mọi role Qubole không còn cần, hoặc loại tài khoản Qubole khỏi chính sách tin cậy của role.
• Ở nơi Qubole hỗ trợ, thay principal :root toàn tài khoản trong chính sách tin cậy bằng principal IAM cụ thể mà Qubole dùng.
• Thêm điều kiện aws:SourceIp hoặc aws:SourceVpce giới hạn yêu cầu AssumeRole trong dải mạng được nhà cung cấp công bố. Theo nhóm nghiên cứu, trong vụ tấn công này, chỉ riêng điều kiện IP nguồn đã đủ chặn mọi lần đảm nhận role mà họ quan sát được.
• Coi như người khác có thể thấy External ID. Mã này được ghi dạng văn bản thuần trong CloudTrail, và các nhà cung cấp cùng tệp infrastructure-as-code thường lưu nó, nên đừng dùng nó làm biện pháp kiểm soát duy nhất. Sau sự cố như thế này, hãy đổi mã cho Qubole và dùng giá trị khác nhau cho từng role nếu có thể.
• Xem lại role của từng nhà cung cấp có thể truy cập được gì. Hướng dẫn thiết lập của Qubole có mẫu chính sách S3 cho phép role đọc mọi bucket trong tài khoản. Theo nhóm nghiên cứu, role của nhà cung cấp thường được cấp quyền truy cập cài đặt Lambda, Secrets Manager, tham số SSM và quyền đọc S3 rộng để thuận tiện.
• Đặt cảnh báo cho yêu cầu AssumeRole từ tài khoản nhà cung cấp đến qua VPN hoặc công ty lưu trữ mà nhà cung cấp chưa từng dùng.
• Ghi log mọi tài khoản và khu vực bằng organization trail, bật sự kiện dữ liệu S3 hoặc log truy cập máy chủ cho các bucket chứa dữ liệu nhạy cảm.

Nguồn: The Hacker News