Công bố trường hợp thứ ba và thứ tư của lỗ hổng bypass nhật ký đăng nhập Azure Entra ID

 (trustedsec.com)
1 điểm bởi GN⁺ 2026-03-22 | 1 bình luận | Chia sẻ qua WhatsApp
  • Kể từ năm 2023, đã phát hiện tổng cộng 4 lỗ hổng bypass nhật ký đăng nhập Azure Entra ID; hai lỗ hổng gần đây nhất được xác nhận là vấn đề nghiêm trọng có thể phát hành token hợp lệ
  • GraphGoblin bypass việc tạo log bằng cách lặp lại tham số scope trong luồng OAuth2 ROPC, còn Graph**** khiến log bị thiếu hoàn toàn bằng chuỗi User-Agent dài hơn 50.000 ký tự
  • Cả hai lỗ hổng đều được cho là bắt nguồn từ thất bại khi ghi log do vượt quá độ dài cột SQL, và Microsoft đã khắc phục sau khi nhận báo cáo
  • Microsoft phân loại vấn đề lần này ở mức “Medium” và âm thầm vá mà không có thưởng hay công nhận chính thức; theo thang CVSS, mức độ được đánh giá là High (7.5~8.7 điểm)
  • Do các lỗi do thất bại trong việc kiểm chứng đầu vào lặp đi lặp lại vẫn tiếp diễn, đối chiếu chéo log và tăng cường quy tắc phát hiện dựa trên KQL được chỉ ra là nhiệm vụ thiết yếu đối với đội ngũ bảo mật

Công bố lỗ hổng bypass nhật ký đăng nhập Azure Entra ID

  • Kể từ năm 2023, đã phát hiện tổng cộng 4 lỗ hổng bypass nhật ký đăng nhập Azure Entra ID
    • Hai trường hợp đầu chỉ có thể xác minh tính hợp lệ của mật khẩu, nhưng hai trường hợp gần đây là vấn đề nghiêm trọng hơn khi có thể phát hành token hợp lệ
    • Tất cả các lỗ hổng hiện đã được Microsoft vá xong

  • Tóm tắt GraphNinja và GraphGhost

    • GraphNinja: khi chỉ định endpoint của tenant khác để thử đăng nhập, có thể biết mật khẩu có hợp lệ hay không nhưng không tạo log
      • Kẻ tấn công có thể gửi yêu cầu xác thực tới tenant bên ngoài và kiểm tra qua phản hồi để biết mật khẩu có đúng hay không
      • Sau đó Microsoft đã bổ sung logging để khắc phục vấn đề này
    • GraphGhost: nếu dùng Client ID sai, luồng xác thực sẽ thất bại sau bước kiểm tra mật khẩu và trong log chỉ hiển thị là thất bại
      • Thông tin cho biết mật khẩu là đúng sẽ không được ghi lại trong log quản trị
      • Microsoft đã vá bằng cách thêm trạng thái kiểm tra mật khẩu vào nhật ký đăng nhập

  • Lỗ hổng GraphGoblin

    • GraphGoblin bypass việc tạo log bằng cách lặp lại tham số scope trong luồng OAuth2 ROPC
      • Khi nhập lặp hàng nghìn lần theo dạng "openid openid openid ...", token hợp lệ vẫn được phát hành nhưng không để lại bất kỳ bản ghi nào trong nhật ký đăng nhập Entra ID
    • Nguyên nhân được cho là INSERT thất bại do vượt quá độ dài cột SQL
      • Có suy đoán rằng việc lưu log thất bại vì chuỗi scope lặp lại vượt quá độ dài trường trong cơ sở dữ liệu
    • Microsoft gặp khó khăn khi tái hiện lỗi, nhưng sau khi được cung cấp bằng chứng video thì đã hoàn tất vá lỗi

  • Graph****** (bypass dựa trên User-Agent)

    • Nếu nhập chuỗi dài hơn 50.000 ký tự vào trường User-Agent, log sẽ không được tạo
      • Yêu cầu xác thực vẫn được xử lý bình thường và token được phát hành, nhưng log bị thiếu hoàn toàn
      • Được cho là thất bại ghi log do vượt quá độ dài cột SQL
    • Được phát hiện vào ngày 2025-09-28 và đến 2025-10-08 Microsoft đã vá xong trước cả khi có báo cáo

  • Tóm tắt timeline

    • 2025-09-20: Phát hiện ban đầu GraphGoblin
    • 2025-09-26: Báo cáo GraphGoblin cho Microsoft
    • 2025-09-28: Phát hiện Graph******
    • 2025-10-08: Hoàn tất vá Graph******
    • 2025-11-21: Microsoft tái hiện thành công GraphGoblin và bắt đầu vá

Phản ứng và đánh giá của Microsoft

  • Microsoft phân loại lỗ hổng lần này ở mức “Medium” và không đưa ra thưởng hay công nhận công khai
    • Hai trường hợp trước đó (2023~2024) đã từng được thưởng và công nhận
    • Lần này, dù là vấn đề nghiêm trọng có thể phát hành token hợp lệ, Microsoft vẫn đánh giá là không quan trọng
  • Theo CVSS v3.1, mức đánh giá là 7.5 điểm (High); theo v4.0 là 8.7 điểm (High)
    • Điểm số cao xuất phát từ thiệt hại về Integrity (tính toàn vẹn)
    • Việc thiếu log được xem là làm tổn hại trực tiếp tới thành phần bảo mật
  • Microsoft đã vá xong chỉ trong 2 tuần sau khi tái hiện được lỗi
    • Trước đây, việc vá GraphNinja mất 7 tháng, còn GraphGhost mất 5 tháng

Cách phát hiện bypass log

  • Có thể dùng truy vấn KQL để so sánh Session ID hoặc UniqueTokenIdentifier giữa Graph Activity log và Sign-In log
    • Các session xuất hiện trong Graph Activity nhưng không có trong Sign-In log có thể được xem là đăng nhập đã bypass
    • Tuy nhiên, cần có license E5 mới có thể thu thập Graph Activity log
  • Ví dụ truy vấn KQL: 
    MicrosoftGraphActivityLogs
| where TimeGenerated > ago(8d)
| join kind=leftanti (union isfuzzy=true
SigninLogs,
AADNonInteractiveUserSignInLogs,
AADServicePrincipalSignInLogs,
AADManagedIdentitySignInLogs,
MicrosoftServicePrincipalSignInLogs
| where TimeGenerated > ago(90d)
| summarize arg_max(TimeGenerated, *) by UniqueTokenIdentifier
)
on $left.SignInActivityId == $right.UniqueTokenIdentifier
    • Khi cần, có thể so sánh theo SessionId
    • Dựa trên kết quả phát hiện, có thể thiết lập Azure Log Search Alert Rule

Tóm tắt bốn kiểu bypass nhật ký đăng nhập

Thời điểm phát hiện Phương thức Có phát hành token hay không Microsoft công nhận hay không
2023-08 / 2024-05 Chỉ định tenant ID bên ngoài để không tạo log xác minh mật khẩu X X
2024-12 / 2025-04 Dùng Client ID sai để dẫn tới thất bại xác thực X X
2025-09-20 Lặp scope để gây tràn cột SQL O X
2025-09-28 Dùng chuỗi User-Agent dài để gây tràn cột SQL O N/A

Chỉ trích quy trình bảo mật của Microsoft

  • Phát hiện lỗi ở nhiều tham số trong tính năng ghi log đăng nhập Entra ID

    • Các lỗ hổng lặp lại xuất hiện ở những trường cốt lõi như tenant ID, client ID, scope, user-agent
    • Đây không phải là tấn công phức tạp mà là vấn đề do thất bại đơn giản trong kiểm chứng đầu vào
    • Có ý kiến chỉ ra Microsoft thiếu rà soát bảo mật và kiểm soát chất lượng
    • Các lỗi tương tự đã lặp lại trong cùng khu vực suốt nhiều năm
    • Cũng có nghi vấn về khả năng liên quan đến việc áp dụng AI tạo mã hoặc sự thiếu sót trong quy trình quản lý mã

  • Thiếu minh bạch trong công bố

    • Cả bốn trường hợp đều không được cấp CVE và không có thông báo chính thức
    • Microsoft với tư cách CNA đang độc quyền quyết định có công bố lỗ hổng của chính mình hay không

Kết luận

  • Nhật ký đăng nhập của Azure Entra ID là dữ liệu cốt lõi để phát hiện xâm nhập của các tổ chức trên toàn thế giới
    • Nếu log bị thiếu, toàn bộ hệ thống phát hiện tấn công có thể bị vô hiệu hóa
  • Cả bốn lỗ hổng được phát hiện đều ở mức có thể tìm ra chỉ bằng fuzzing đầu vào đơn giản
  • Microsoft cần có giải thích công khai và tăng cường quy trình rà soát bảo mật minh bạch đối với các lỗi lặp lại này
  • Quản trị viên và đội ngũ bảo mật cần củng cố hệ thống phòng vệ bằng đối chiếu chéo log và quy tắc phát hiện dựa trên KQL

Bài viết liên quan

1 bình luận

 
GN⁺ 2026-03-22
Ý kiến trên Hacker News

  • Khiến tôi nhớ đến báo cáo về vụ xâm nhập Microsoft do CISA công bố
    Đó là vụ hacker được nhà nước hậu thuẫn xâm nhập Microsoft rồi thâm nhập vào nhiều cơ quan như Bộ Ngoại giao Mỹ
    Điều đáng kinh ngạc là không phải Microsoft mà là một quản trị viên hệ thống của Bộ Ngoại giao đã phát hiện bất thường trong log mail và tìm ra vụ xâm nhập
    Liên kết báo cáo CISA

  • Trong bài viết chỉ trích trực diện Azure của ProPublica và ArsTechnica, có nói rằng các chuyên gia an ninh mạng liên bang đã mô tả cloud của Microsoft là “tệ hại”
    Liên kết bài viết

    • Thực ra có vẻ một chuyên gia đã dùng cách nói đó để chỉ chất lượng tài liệu, còn ProPublica thì diễn giải rộng ra cho toàn bộ Azure
    • Ars chỉ đơn giản là đăng lại theo giấy phép
    • Những kỹ sư bảo mật Azure mà tôi biết gần như đang sụp đổ tinh thần. Trong khoảng 12 người thì một nửa bị burnout, số còn lại năng lực quá thấp
    • Bloomberg hay CNBC đã không đưa tin về vụ này. Giá mà ai đó báo cho họ qua mạng lưới liên hệ báo chí

  • Tình trạng an ninh mạng hiện nay quá lỏng lẻo so với việc đây là hệ thống mà cả nền văn minh đang phụ thuộc
    Chẳng khác nào lấy băng keo quấn kín một con tàu thủng lỗ chỗ rồi lao ra đại dương

    • Điều còn tệ hơn là ngành này phản ứng kiểu muốn bịt các lỗ thủng đó bằng cách dựng thêm tháp súng máy

  • Trong thảo luận về log SQL, có vẻ kẻ tấn công đã gửi đầu vào quá dài khiến vượt quá độ dài cột, làm câu lệnh INSERT thất bại
    Kết quả là không có bản ghi nào về lần thử đăng nhập được lưu lại

    • Đây là cấu trúc gồm hai dịch vụ hoạt động tách biệt. Dịch vụ xác thực phát hiện thất bại và yêu cầu dịch vụ log ghi lại, nhưng dù dịch vụ log lỗi thì dịch vụ xác thực vẫn trả về phản hồi như cũ
      Có vẻ đây là vấn đề cấu trúc do luồng xác thực được thiết kế quá phức tạp

  • Tôi từng gặp trường hợp audit log của Azure được ghi khác với hành vi thực tế
    Tôi xóa client secret, UI thì hiển thị là xóa B nhưng API lại hoạt động theo kiểu chỉ giữ lại A
    Cuối cùng log ghi như thể đó là hành động của tôi, nhưng thực tế là lỗi hệ thống
    Sau trải nghiệm này, niềm tin của tôi không chỉ với log Azure mà còn với audit log nói chung đã bị lung lay
    Tôi cho rằng dùng chúng làm bằng chứng trước tòa là rất rủi ro

    • Vì thế tôi thích UI có bước xác nhận bắt buộc trước khi thay đổi. Những giao diện tự động lưu kiểu ‘trò chơi điện tử’ quá nguy hiểm
    • Cổng Azure (cả bản mới lẫn bản cũ) đầy lỗi nên cũng chẳng có gì đáng ngạc nhiên. Có lúc chỉ bấm nhầm một nút là đối tượng khác bị thay đổi
    • Đây là ví dụ giáo dục rất hay về rủi ro của phép set so với phép delete trong môi trường chỉnh sửa đồng thời. Log thì chính xác, nhưng thiết kế UI mới là vấn đề
    • Cuối cùng người dùng chỉ đang thể hiện ý định, còn việc thực thi thực tế lại do frontend kiểm soát, điều đó khiến tôi thấy đáng sợ

  • So với các lỗ hổng EntraID gần đây thì việc né log có vẻ ít quan trọng hơn

    • Nhưng nếu log xác thực cốt lõi chỉ hoạt động theo kiểu ‘best-effort’, thì đó là vấn đề nghiêm trọng nếu lấy làm căn cứ cho kiểm toán bảo mật
    • Suy cho cùng, một cuộc tấn công thành công và kín đáo luôn được tạo nên từ sự phối hợp của nhiều lỗ hổng

  • Microsoft từng đưa cả lỗ hổng nghiêm trọng vào Notepad, nên chuyện này cũng chẳng có gì lạ

  • Khi trước tôi từng đánh giá Azure VPN, và hoàn toàn không có log nào về việc kết nối thành công/thất bại
    Khi tôi nêu vấn đề, Microsoft bảo tôi hãy đăng nó thành yêu cầu tính năng mới
    Từ lúc đó tôi mất hoàn toàn niềm tin vào Azure. Theo thời gian nó không khá lên mà còn có cảm giác tệ hơn

  • Lý do các quản trị viên IT vẫn tiếp tục dùng Microsoft là vì không có lựa chọn nào khác

    • Trong môi trường như tôi, phải quản lý ứng dụng LOB dựa trên .NET và đủ loại SaaS, thì giải pháp Microsoft vẫn là lựa chọn thực tế nhất
      Ngân sách ít, nhân lực cũng thiếu, nên chỉ duy trì ở mức nhận lương rồi tan ca được là cùng
    • Các quản trị viên trẻ có xu hướng ghét Microsoft khá rõ. Có thể là khác biệt thế hệ
    • Giống câu “Không ai bị sa thải vì chọn mua X”, chọn Microsoft có ít rủi ro cho sự nghiệp hơn

  • Khi Microsoft không thể tái hiện lỗ hổng Azure và yêu cầu bằng chứng video, điều gây ấn tượng là người ta đã chứng minh chỉ bằng đúng một dòng lệnh curl
    Đúng là một khoảnh khắc cực kỳ hả hê