Lợi dụng Entra OAuth để truy cập ứng dụng nội bộ Microsoft
(research.eye.security)- Nhóm nghiên cứu xác nhận rằng có thể lợi dụng quy trình đồng ý và ủy quyền của Entra OAuth để tiếp cận các ứng dụng nội bộ của Microsoft
- Lỗ hổng này là mối đe dọa mới đối với bảo mật hệ thống nội bộ, mở ra khả năng người dùng bên ngoài có thể có đường vào các dịch vụ nội bộ
- Cơ chế đồng ý mặc định và các cấu hình quyền chưa đầy đủ là nguyên nhân chính
- Kết quả nghiên cứu cho thấy, chỉ dựa vào kiểm soát bảo mật hiện có thì vẫn tồn tại điểm yếu trong yêu cầu đồng ý OAuth và kiểm soát truy cập
- Doanh nghiệp và tổ chức nhận thấy cần tăng cường quản lý đồng ý và quyền OAuth
Tổng quan nghiên cứu và bối cảnh
- Microsoft Entra OAuth là một hệ thống xác thực/ủy quyền trong đó nhiều ứng dụng có thể nhận quyền truy cập vào các dịch vụ khác nhau dựa trên sự đồng ý của người dùng
- Nhóm nghiên cứu phát hiện trong môi trường mục tiêu, các ứng dụng Microsoft vốn chỉ có thể truy cập từ nội bộ có thể bị truy cập từ bên ngoài khi kẻ tấn công khai thác kịch bản ủy quyền đồng ý và quyền cụ thể
Phân tích nguyên nhân
- Lỗ hổng xuất hiện do việc lợi dụng quá trình yêu cầu đồng ý OAuth
- Nếu ứng dụng không được giới hạn đúng cách, kẻ tấn công có thể kích hoạt người dùng đồng ý để lấy được mã thông báo tài nguyên nội bộ
- Cơ chế đồng ý và cấp quyền mặc định không đủ mức chi tiết để phân tách, khiến một số dịch vụ nội bộ đối mặt với rủi ro bị lộ ra bên ngoài
Tác động và rủi ro
- Kẻ tấn công có thể dùng lỗ hổng này để tiếp cận hệ thống nội bộ của Microsoft và các ứng dụng
- Nếu quyền truy cập được cho phép, có thể xảy ra rò rỉ dữ liệu nhạy cảm hoặc lạm dụng sai chức năng nội bộ
Ứng phó và khuyến nghị
- Các tổ chức cần xem xét lại khung quản trị OAuth và kiểm soát chặt chẽ toàn bộ quá trình đồng ý và cấp quyền
- Dựa trên nguyên tắc quyền tối thiểu, cần giới hạn rõ ràng phạm vi tài nguyên và quyền đã được đồng ý
- Cần thiết lập quy trình kiểm toán ứng dụng OAuth và quản lý đồng ý thường xuyên để tăng cường quản lý
1 bình luận
Ý kiến trên Hacker News
Tài liệu của Microsoft đúng là một ác mộng, nên việc có lỗ hổng hoàn toàn không còn gì phải ngạc nhiên. Gần đây mình đã xây dựng đăng nhập SSO bằng Entra ID (may mắn là đơn tenant), và gần như phải thử ngẫu nhiên cho đến khi đặt đúng scope cùng các trường trả về bổ sung cho access token. Khi tìm hướng dẫn bắt đầu, chỉ thấy hàng đống trang con, toàn thuật ngữ rườm rà kiểu Microsoft và các link tài liệu không giúp được bao nhiêu.
Kết quả này không có gì bất ngờ. Cấu hình OAuth2 của Entra và tài liệu của họ hoàn toàn lộn xộn. Rối đến mức chắc chắn ngay cả Microsoft cũng không thể khiến nó chạy đúng. Cách xử lý vấn đề của họ là “thêm thêm tài liệu”, trong khi tài liệu spaghetti đã có sẵn đã rất khó đọc rồi.
Mình đã gặp đúng vấn đề này vài tuần trước. Theo tài liệu chính thức thì không thể thực hiện authorization code flow với các scope nhắm tới nhiều resource server. Nhưng nếu request
openid $clientid/.defaultthì lại chạy được. Cuối flow nhận được ID token và access token, trong đó ID token cho thấy scope OIDC đã áp dụng. Tuy nhiên access token lại không còn “openid”. Thực tế là không thể gọi Microsoft Graph (với vai trò UserInfo endpoint). Mình không tìm thấy tài liệu nào giải thích rõ vì sao lại như vậy.Cấp quyền ứng dụng đa tenant liên tục sinh ra các vấn đề không mong đợi. Mình là PM (đã nghỉ việc) tại Microsoft, từng làm patch sau kết quả nghiên cứu của Wiz. Trong một đề xuất sửa bài, có ghi rằng khi cấp quyền app đa tenant thì chỉ cần kiểm tra claim “iss” hoặc “tid”. Khuyến nghị thực tế phức tạp hơn một chút. Chỉ kiểm tra tenant có thể cho phép bất kỳ service principal nào nhận được quyền truy cập được cấp quyền. Luôn phải xác thực thêm subject ngoài tenant. Ví dụ kiểm tra token bằng cặp tid+oid, hoặc trước khi cấp quyền phải kiểm tra cả tenant lẫn subject. Chi tiết trong tài liệu claims validation chính thức.
Cách tiếp cận xem mọi token đều có thể bị giả mạo là rất đúng. Thiết kế mặc định phải an toàn tuyệt đối. Dù CPU có tốn hơn, vẫn phải validate toàn bộ các trường. Chữ ký chỉ có ý nghĩa khi có bước verify signature. Nếu có thể, nên đối chiếu thêm với identity database. Mình đã dạy dev rằng tenant, user, group, resource đều phải được kiểm tra kỹ trước khi cho phép.
Nói đúng 100%. Thực ra kỹ sư nên đọc kỹ hướng dẫn chính thức. Tài liệu liên quan có thể xem tại đây.
Mình cũng tò mò có “hướng dẫn rõ ràng cần check cái gì” hay không. Nguyên tắc này đáng lẽ phải là dạng Yes/No. Chưa bao giờ mình thấy checkbox kiểu “Người dùng nhóm này có quyền đọc ghi chú cá nhân của tất cả mọi người không?”
Dù bỏ qua sự rườm rà của Entra, đặc biệt khi bên trong Microsoft có vô số tenant nội bộ phải hỗ trợ trộn với tenant khách hàng 3P, rất dễ không thấy lỗi. Tệ hơn cả là niềm tin rằng chỉ cần một “authentication token” là giải quyết xong bảo mật. Một site như vậy không nên public ra internet (giờ đã không còn public nữa). Bảo mật mạng thường bị đẩy ra sau, nhưng đó mới là lớp phòng thủ hiệu quả nhất.
Bảo mật mạng cũng chỉ là một lớp phòng thủ. Quan trọng là có nhiều lớp (defense-in-depth).
Họ nói chuyển lên cloud vì nó an toàn hơn intranet, nói đội ops không cần duy trì... Mình đã già rồi, đầu đã cứng, không thể hiểu nổi cách một ứng dụng nội bộ của Microsoft lại có thể truy cập từ bên ngoài.
Mười năm nay, kể từ Google, xu hướng là bỏ hẳn VPN nhờ Zero Trust. Ai cũng vào được qua VPN thì rất khó chặn quyền truy cập dữ liệu quan trọng. Vì thế giờ dịch vụ “nội bộ” cũng được expose ngoài, và quyền phân tầng (permissions) là bắt buộc. Hệ quả là tấn công kiểu “đâm xuyên qua nhiều service” trở nên khó hơn nhiều. Giới thiệu khái niệm Zero Trust
Theo mình, điều đáng lo không phải việc app bị phơi ngoài mạng công cộng (nghĩa là không còn intranet). Vấn đề là app này (Entra ID) là multi-tenant. Thông tin auth quan trọng được lưu trữ và chia sẻ trong cùng cơ sở dữ liệu với nhiều tenant (kể cả tenant tấn công), nên vi phạm multi-tenant xảy ra dễ. Dù Entra ID có tenant-checking tốt đến đâu, lỗ hổng vẫn còn. Ví dụ như trong blog, request qua 2 tenant trở lên (multi-tenant request) cơ bản rất khó ủy quyền và một sai sót nhỏ đã có thể gây rủi ro toàn diện. Với app đơn tenant, kẻ tấn công phải là user trong tenant đó nên tấn công trước auth khó khăn hơn nhiều.
Lời kêu gọi “đi cloud, an toàn hơn nội bộ, không cần team vận hành” nghe hấp dẫn, nhưng điều cốt lõi như blog chỉ ra là dev làm auth cho resource server vẫn không kiểm tra claim cơ bản như issuer, audience, subject trong token. Nếu sai sót kiểu này cứ lặp lại thì có intranet cũng vô dụng. Cuối cùng, bản chất không phải cloud hay on-prem, mà bảo mật vốn khó và vòng lặp cải tiến thường chưa tốt khi chưa có sự cố thật. Đặt trên intranet hay VPN thì sai lầm bảo mật này cũng không biến mất.
Có phải khái niệm “Defence in depth” giờ đã hết thời rồi không?
Đa số công ty, tự vận hành server vẫn là lời khuyên hợp lý. Ngay cả nhà thầu sửa mái nhà tốt nhất trong khu vực của mình, bạn cũng không muốn giao luôn website, email, hệ thống đặt lịch cho họ. Người dùng ở forum này có thể dựng, vận hành server được, nhưng họ không phải “người dùng phổ thông”.
Việc phát hiện bug RCE trong Windows build server mà thưởng 0$ là quá vô lý. Ngay cả khi đó chỉ là issue cấu hình chứ không phải zero-day, nếu có thể cài backdoor DLL làm ô nhiễm môi trường build thì có thể gây thảm họa toàn cầu.
Dù Microsoft có rất nhiều người giỏi, nhìn qua vụ rò rỉ master key gần đây, kỹ sư nhờ GPT viết PR, và CEO nói không cần backend engineer nữa, mình không thể đặt niềm tin vào công ty đó. Tất nhiên phần lớn mọi người thừa nhận không có lựa chọn nào khác. Thế mà còn ở đó thì cũng thiếu trách nhiệm.
Ý kiến của mình rất đơn giản: Entra* (hay Azure AD dù đổi tên thế nào cũng không sao) không nên dùng cho AuthZ (authorization). Nó dùng được cho AuthN (authentication), nhưng AuthZ phải tự implement. Chỉ cần tự làm AuthZ thì có thể né được mớ lỗi này khá dễ.
Mình cũng không biết vì sao họ đổi tên. Có vẻ có một ông quản lý Microsoft mang tư tưởng “tôi đổi tên nên tôi tồn tại”.
Tên “Azure AD” vẫn khiến người ta hiểu sai là chỉ là AD host trên Azure. Thực tế thì giờ đã nhiều hơn rất nhiều.
Dùng Entra để thực hiện AuthZ thì vẫn được. Chỉ cần tích chọn “Require users to be assigned” rồi tự assign trực tiếp [1]. Nhưng đây là tính năng AuthZ duy nhất mà Entra cung cấp. Nếu không bật AuthZ, kỳ vọng Entra sẽ tự động quản lý ủy quyền là sai. Lưu ý: authz kiểu cho phép/từ chối đơn giản chỉ phù hợp ứng dụng cực đơn giản mà mọi user có cùng quyền. Ứng dụng phức tạp thường có user với nhiều mức truy cập khác nhau, nên authorization cần implement trong app. [1] Cách gán quyền cho người dùng hoặc nhóm trên cổng quản trị
Vấn đề là ở đa tenant app của Entra ID, không thể blacklist/whitelist theo tenant cụ thể. Hơn nữa, MSAL cũng không hoạt động cho browser extension, nên người dùng phải tự implement thêm cơ chế bảo mật để giao tiếp với Entra ID. Tạo nên chuyện này, lỗi cứ tiếp tục phát sinh là điều dễ hiểu.
Azure thực sự là một hỗn loạn. Okta cũng có vấn đề của họ, nhưng tài liệu của họ rõ hơn nhiều và dù đắt hơn, bạn có thể tách hẳn bảo mật khỏi dịch vụ Azure. Mình nghĩ cái đó đáng giá.