Lỗ hổng nghiêm trọng trong Azure API Connections: Năm vụ xâm phạm chéo đối tượng thuê

Một nhà nghiên cứu bảo mật vừa công bố chuỗi lỗ hổng nghiêm trọng trong Azure API Connections — thành phần thuộc Azure Logic Apps — có thể bị lợi dụng để chiếm quyền truy cập vào bất kỳ kết nối nào trên toàn cầu, kể cả của các đối tượng thuê (tenant) khác.

Những lỗ hổng này cho phép kẻ tấn công đọc và ghi trực tiếp vào Key Vault, Azure SQL Database cũng như các dịch vụ bên ngoài như Jira hay Salesforce thông qua token đã được cấu hình sẵn. Tổng cộng, nhà nghiên cứu nhận được 200.000 USD tiền thưởng từ chương trình Bug Bounty của Microsoft.

Kiến trúc đằng sau API Connections

Theo tài liệu của Microsoft, luồng hoạt động của API Connections khá đơn giản: một Logic App gọi đến một phiên bản Azure API Management (APIM) dùng chung; APIM kiểm tra định nghĩa OpenAPI của loại connector rồi thực hiện trao đổi token — thay thế khóa đầu vào bằng token đã cấu hình cho dịch vụ backend — trước khi hoàn tất lời gọi đến backend.

Kiến trúc connector của API Connections

Điểm mấu chốt mà nhà nghiên cứu phát hiện: nếu đánh lừa được APIM vận hành trên một kết nối không thuộc sở hữu của mình, kẻ tấn công có thể sử dụng token đã cấu hình của nạn nhân trên chính backend của họ. Đặc biệt, thông qua các endpoint DynamicInvoke hoặc /extensions/proxy/ của ARM REST API, người dùng có thể truy vấn trực tiếp dịch vụ APIM qua ARM — nơi về bản chất có toàn quyền truy cập vào mọi tài nguyên.

Cần lưu ý rằng người thiết lập kết nối hoàn toàn có thể giới hạn phạm vi quyền của token hoặc API key để API Connection chỉ có đặc quyền tối thiểu trên backend. Tuy nhiên trên thực tế, điều này hiếm khi được thực hiện — kể cả bởi chính Microsoft.

Khai thác ban đầu bằng path traversal

Cách khai thác đầu tiên là một lỗ hổng path traversal kinh điển. Bằng cách gửi yêu cầu đến endpoint DynamicInvoke của kết nối do mình sở hữu nhưng chèn chuỗi ../ để trỏ sang kết nối của nạn nhân, kẻ tấn công đọc được bí mật trong Key Vault của đối tượng thuê khác.

Mô tả phản hồi của đường dẫn bị chặn động

Lỗ hổng này cho thấy khi yêu cầu được gửi từ ARM đến APIM, nó có quyền trên mọi kết nối, bất kể kết nối đó thuộc về ai. Microsoft đã vá bằng cách chặn các đường dẫn độc hại, nhưng đây chỉ là biện pháp đối phó bề mặt.

Bốn endpoint ẩn không được tài liệu hóa

Sau khi vá lỗi đầu tiên, nhà nghiên cứu tạo một Standard Logic App để có máy chủ chuyên dụng, SSH vào và trích xuất mã nguồn của dịch vụ. Tại đây, ông phát hiện không chỉ một mà bốn hàm công khai nằm cùng đường dẫn với DynamicInvoke, hoàn toàn không có tài liệu: DynamicInvoke, DynamicList và hai hàm khác.

Kiểm tra định nghĩa API được quản lý

Bản vá chặn đường dẫn trước đó chỉ áp dụng cho DynamicInvoke, nên các endpoint còn lại vẫn dính lỗi tương tự. Với DynamicList, kẻ tấn công có thể thực thi truy vấn SQL tùy ý trên cơ sở dữ liệu của nạn nhân — ví dụ chèn dữ liệu vào bảng bằng câu lệnh INSERT sau khi vượt qua path traversal. Khi báo cáo, nhà nghiên cứu cố tình chỉ nêu DynamicList với hy vọng Microsoft vá nó giống DynamicInvoke, để có thể tiếp tục báo cáo hai endpoint còn lại. Tuy nhiên, Microsoft đã chặn toàn bộ các endpoint này ngay lập tức.

Lỗ hổng trong tham số RuntimeUrl

Bước đột phá tiếp theo đến từ việc so sánh luồng tạo kết nối giữa hai loại Logic App. Consumption Logic App chạy chung hạ tầng và tạo kết nối phiên bản 1, trong khi Standard Logic App có máy chủ riêng tạo kết nối phiên bản 2 và xác thực bằng managed identity.

Hệ quả là mọi Consumption Logic App dường như có quyền truy cập ngầm vào mọi API Connection phiên bản 1 — và rào cản duy nhất là các lớp kiểm tra đầu vào. Sau khi tìm hiểu mã nguồn, nhà nghiên cứu phát hiện tham số host.api.RuntimeUrl, cho phép ghi đè địa chỉ runtime được ghi cứng trong kết nối, miễn là host kết thúc bằng azure-apihub.net.

Microsoft đã vá bằng cách yêu cầu RuntimeUrl khớp chính xác với endpoint mong đợi — nhưng kiểm tra diễn ra trước khi chuẩn hóa đường dẫn. Kết quả là chỉ cần thêm các chuỗi ../ khéo léo, quá trình kiểm tra thấy URI hợp lệ trong khi APIM lại hiểu theo cách khác. Một lỗ hổng nghiêm trọng nữa ra đời.

Định nghĩa Dynamics trong hệ thống

Trớ trêu thay, khi Microsoft vá lỗ hổng path traversal mới này, họ lại vô tình làm hỏng bản vá kiểm tra RuntimeUrl trước đó — khiến cuộc tấn công ban đầu hoạt động trở lại.

Bài học cho doanh nghiệp Việt Nam

Sự việc là lời cảnh tỉnh cho các tổ chức đang sử dụng Azure tại Việt Nam:

• Áp dụng nguyên tắc đặc quyền tối thiểu cho token và API key của mọi kết nối, kể cả khi điều này tốn thêm công sức cấu hình.
• Rà soát các Logic App và API Connection đang hoạt động, đặc biệt là các kết nối Consumption dùng chung hạ tầng.
• Coi trọng các lớp kiểm tra đầu vào nhưng không tin tưởng tuyệt đối vào chúng — các lỗi kiểu path traversal và thứ tự kiểm tra sai luôn là điểm yếu phổ biến.

Nhà nghiên cứu kết luận rằng dù có một số bất đồng với MSRC trong quá trình xử lý, toàn bộ lỗ hổng đều được khắc phục trong thời gian hợp lý. Tuy nhiên, ông cũng cảnh báo: nếu các endpoint Dynamic từng bị chặn lại được mở trở lại, chúng gần như chắc chắn vẫn còn lỗ hổng.