Tài khoản thử nghiệm Microsoft bị hack từng có quyền quản trị

• Vụ xâm nhập Microsoft nghiêm trọng hơn một vụ chiếm đoạt tài khoản đơn thuần, vì một tài khoản thử nghiệm cũ không có MFA đã dẫn tới quyền truy cập email của các lãnh đạo cấp cao cùng đội ngũ bảo mật và pháp lý
• Nhóm có liên hệ với nhà nước Nga Midnight Blizzard đã lợi dụng thông tin đăng nhập yếu bằng password spraying để đăng nhập vào “legacy non-production test tenant account”
• Từ tenant thử nghiệm bị xâm phạm, kẻ tấn công dùng quyền của ứng dụng OAuth để giành vai trò full_access_as_app trong Office 365 Exchange Online
• Việc cấp full_access_as_app cần quyền quản trị, nên có ý kiến chỉ trích rằng tài khoản thử nghiệm này là một lỗi cấu hình khi có quyền quá mức trong môi trường production
• Tài khoản thử nghiệm đi ngược nguyên tắc đặc quyền tối thiểu và password spraying dựa trên proxy dân dụng khiến việc phát hiện dựa trên các chỉ dấu xâm nhập truyền thống trở nên khó khăn

---

Từ tài khoản thử nghiệm đến quyền truy cập email

• Tin tặc nhà nước Nga đã lợi dụng thông tin đăng nhập yếu bằng password spraying để đăng nhập vào “legacy non-production test tenant account”
• Tài khoản thử nghiệm này không được bảo vệ bằng xác thực đa yếu tố
• Sau đó, chúng giành được quyền có thể truy cập các tài khoản email của lãnh đạo cấp cao Microsoft và nhân viên đội ngũ bảo mật, pháp lý
• Nhóm tấn công Midnight Blizzard đã lạm dụng giao thức xác thực OAuth để duy trì quyền truy cập vào các tài khoản email đặc quyền
  • Tạo ứng dụng độc hại trong tenant thử nghiệm bị xâm phạm
  • Cấp cho ứng dụng quyền truy cập mọi địa chỉ email của dịch vụ email Microsoft Office 365
  • Dùng ứng dụng OAuth thử nghiệm hiện có để cấp vai trò full_access_as_app của Office 365 Exchange Online

Tài khoản thử nghiệm legacy có quyền quản trị

• Bản cập nhật của Microsoft có nội dung rằng “legacy test OAuth application” có quyền truy cập nâng cao trong Microsoft corporate environment
• Theo Kevin Beaumont, để cấp vai trò full_access_as_app cho ứng dụng OAuth, tài khoản phải có quyền quản trị
• Beaumont đánh giá cấu hình này là “một lỗi cấu hình khá lớn trong production”
• Có ý kiến chỉ trích rằng rất khó hình dung lý do hợp lý để cấp và duy trì quyền rộng như vậy cho một tài khoản thử nghiệm legacy cũ
• Microsoft từ chối giải thích vì sao tài khoản thử nghiệm ban đầu lại được thiết lập với cấu hình như vậy, và vì sao nó vẫn được duy trì sau khi đã trở thành legacy

Cấu hình đi ngược nguyên tắc đặc quyền tối thiểu

• Cấu hình này phá vỡ nguyên tắc đặc quyền tối thiểu, theo đó tài khoản chỉ nên có các quyền tối thiểu cần thiết để thực hiện công việc
• Vấn đề cốt lõi là khó hiểu vì sao một tài khoản thử nghiệm legacy lại cần có quyền quản trị
• Beaumont ví tình huống này như việc đặt một người dùng Domain Admin của hệ thống production trong một domain thử nghiệm không có bảo mật, MFA, tường lửa hay giám sát
  • Người dùng Domain Admin có toàn quyền quản trị đối với các thiết bị kết nối mạng, bao gồm domain controller và Active Directory
  • Vì đây là tài khoản mạnh nhất trong mạng, nó cần được cô lập và hiếm khi nên xuất hiện trong hệ thống production
  • Nếu một tài khoản như vậy bị bỏ mặc mà không có mật khẩu mạnh và các biện pháp bảo mật tiêu chuẩn, thiệt hại sẽ lớn hơn

Xâm nhập các tổ chức khác và password spraying âm thầm

• Microsoft phát hiện Midnight Blizzard cũng đã xâm nhập thêm các tổ chức khác và đã thông báo cho các tổ chức bị ảnh hưởng
• Hewlett-Packard Enterprises cũng cho biết mạng của họ đã bị Midnight Blizzard hack
  • Vụ xâm nhập xảy ra vào tháng 5
  • Việc phát hiện và chặn mãi đến tháng 12 mới được thực hiện
• Password spraying dùng để truy cập tài khoản thử nghiệm được thực hiện với số lần thử thấp trên mỗi tài khoản và trên một số lượng tài khoản hạn chế
• Kẻ tấn công dùng hạ tầng proxy dân dụng phân tán để khiến hoạt động độc hại ít bị lộ hơn
  • Truy cập từ các địa chỉ IP có uy tín tốt
  • Sử dụng địa chỉ IP nằm ở khu vực dự kiến
  • Khiến lưu lượng trông như hòa lẫn với lưu lượng của người dùng hợp pháp

Giới hạn của phát hiện dựa trên chỉ dấu xâm nhập truyền thống

• Cách dùng proxy dân dụng không phải kỹ thuật mới và cũng từng được dùng trong cuộc tấn công chuỗi cung ứng SolarWinds năm 2020
• Cuộc tấn công SolarWinds cũng được liên hệ là do Midnight Blizzard thực hiện
• Proxy dân dụng định tuyến lưu lượng qua rất nhiều IP người dùng hợp pháp, nên việc phát hiện truyền thống dựa trên chỉ dấu xâm nhập trên thực tế trở nên khó khăn
• Midnight Blizzard là nhóm mà chính phủ Mỹ và Anh cho biết hoạt động cho SVR, cơ quan tình báo đối ngoại của Nga
• Các tên khác được dùng để theo dõi cùng nhóm này gồm APT29, the Dukes, Cloaked Ursa, UNC2452, Dark Halo

[GN⁺]

Các ý kiến trên Hacker News

• Làm tôi nhớ đến một vụ hack Roblox cũ từng nghe. Họ có một trang staging không dùng cho production nhưng cho phép người dùng đăng ký, kèm banner ghi “những thứ ở đây không tồn tại vĩnh viễn”
  Một tài khoản admin mới được thêm vào môi trường production, rồi ai đó đăng ký trên trang staging với cùng tên người dùng, sau đó dùng cookie và token đó để chiếm tài khoản production và xâm nhập trang web
  Nếu tạo token mã hóa dựa trên tên người dùng hoặc ID người dùng mà không dùng secret khác nhau cho production/staging, hoặc nếu trang staging giao tiếp với dịch vụ bên ngoài rồi bị lẫn với cơ chế cấp quyền production, thì những vấn đề kiểu này có lẽ không hiếm lắm

  • Trước đây tôi từng triển khai API vận chuyển cho thương mại điện tử, tích hợp với những bên như DHL. Chúng tôi quên chuyển sang server production nên trong vài tháng đã gửi hàng bằng các nhãn in ra từ API thử nghiệm; hàng vẫn được giao và không bị tính phí
    Ngay khi phát hiện, chúng tôi đã báo thật ngay
  • Vì vậy token mới có trường đối tượng nhận

• Trong các tập đoàn lớn, ranh giới giữa phát triển/production thủng lỗ chỗ hơn rất nhiều so với điều mọi người muốn nghĩ
  Hãy nghĩ đến một ngày điển hình: đăng nhập vào PC, kiểm tra email, rồi dùng cùng thông tin xác thực đó để đăng nhập cổng Azure. Rốt cuộc tất cả đều nằm trong cùng một tenant, và tài khoản còn được liên kết với GitHub lẫn tài khoản cloud
  Groups và Teams được tạo khắp nơi, những thứ sinh ra để dùng Teams hay OneDrive với các quyền đáng ngờ gắn kèm vẫn nằm trong thư mục công ty và gần như không phân biệt được với các nhóm bảo mật
  Thỉnh thoảng có email tự động hỏi “còn cần cái này không”, nhưng thông điệp thì mù mờ, và ở một công ty rất lớn cũng chẳng biết hỏi ai cho phải. Helpdesk thì hai ngày sau mới trả lời, mà cũng không thể lên Twitter hỏi John Savill, nên cuối cùng chỉ bấm xác nhận rồi bỏ qua
  Sau cùng, tấm vải của tổ chức bắt đầu rách, và kẻ tấn công may mắn lọt vào ở điểm yếu rồi di chuyển ngang trong tenant để lấy thứ chúng muốn
  Như một CISO khôn ngoan từng nói, hacker không đột nhập, họ đăng nhập

  • Giả định “điển hình” ở đây khá táo bạo nên cũng thú vị
    Tất nhiên là theo kiểu ai cũng dùng Microsoft cloud, Skype, Twitter, OneDrive, rồi còn ném vào một cái tên người nghe có vẻ hợp lý

• Về nhận định của Kevin Beaumont rằng “chỉ tài khoản có quyền admin mới có thể cấp cho ứng dụng OAuth vai trò full_access_as_app gần như toàn quyền. Ai đó trong môi trường production đã mắc một lỗi cấu hình khá lớn”, nếu nhìn mà không biết chi tiết hệ thống thì đó có vẻ không phải vấn đề cốt lõi
  Lẽ ra không được có cách nào để mắc lỗi như vậy. Người thiết kế và người vận hành đáng lẽ phải khiến điều đó trở nên bất khả thi, và trách nhiệm cũng nằm ở đó
  Nếu bạn xây dựng và vận hành một nhà máy có một nút bấm làm giật điện tất cả người bên trong, rồi ai đó vô tình bấm nút đó, thì vấn đề nằm ở đâu là rất rõ

  • Khả năng cao đây không phải là vấn đề kỹ thuật. Hẳn đã có khoảng 20 best practice và cơ chế an toàn để chặn về mặt kỹ thuật, nhưng các guardrail như vậy chỉ có ý nghĩa khi tổ chức, lãnh đạo và bộ máy quan liêu chịu quan tâm
    Trong nhiều năm, tôi đã nhiều lần bị yêu cầu phớt lờ mọi chính sách, thủ tục, quy định và luật lệ để cấp quyền siêu quản trị/root cho các VIP hoàn toàn không cần những quyền đó
    Ngày nay mọi việc còn tệ hơn vì cái gì cũng thành kiêm nhiệm chéo, bán thời gian, vai trò kép, vai trò ba lớp
    Tôi từng thấy hệ thống kiểm soát truy cập dựa trên vai trò có số vai trò còn nhiều hơn số quyền thực tế có thể cấp. Khi đó mục đích của RBAC tự sụp đổ. Cấp quyền riêng lẻ thì nhanh hơn, nhưng lại không được phép vì trong báo cáo sẽ không thấy vai trò
    Những chuyện này không xuất phát từ người làm kỹ thuật mà từ lãnh đạo tồi
    Trước đây tôi từng thiết kế một phần mở rộng cho hệ thống phân quyền RBAC của ERP nội bộ để giảm nhẹ vấn đề này. Tôi thêm một loại gọi là “ngoại lệ quyền”, để những người cần quyền ngoài vai trò được gán theo cách đó, nhờ vậy có thể tạo báo cáo danh sách những người có thể làm việc ngoài vai trò công việc của họ
    Cuối cùng chỉ là thêm một flag vào quyền, nhưng hoạt động tốt. HR kiểm tra ngoại lệ quyền mỗi quý để xem có nên gỡ bỏ không, và thay vì helpdesk bán thời gian mò mẫm rồi nới tung quyền, người có thẩm quyền thực sự hiểu việc có thể kiểm soát
  • Tôi tò mò là làm thế nào để khiến lỗi cấu hình trở nên bất khả thi

• Thật buồn cười khi có đầy chứng nhận bảo mật hào nhoáng nói rằng chúng bảo vệ doanh nghiệp và ngành bằng rủi ro có thể định lượng, trong khi những best practice hợp lý, được suy nghĩ cẩn thận trong một cuốn sách 36 đô trên Amazon lại bị phớt lờ hoàn toàn
  Bảo mật trông như một kiểu chiến dịch ruy-băng vậy

  • Bảo mật là một quy trình, không phải sản phẩm
    Ai bán bảo mật như một sản phẩm là đang lừa đảo
  • Dù tôi có chứng chỉ bảo mật, 1.000 nhân viên khác có thể không có
    Nhân viên bình thường hầu như không quan tâm đến bảo mật, họ chỉ làm việc của mình
    Có quá nhiều server, ứng dụng và cấu hình, nên chỉ nhân viên có ý thức bảo mật thì không đủ để rà soát hết
    Nếu nhìn đủ lâu, ở bất kỳ công ty nào rồi cũng sẽ có thứ không nên mở nhưng lại đang mở. Việc của các nhóm hacker chính là liên tục tìm các kẽ hở
    Công ty phải liên tục tạo server mới và cấu hình mới trong quá trình vận hành, nên đây không phải vấn đề thiết lập một lần rồi xong
  • Tôi tò mò đó là cuốn sách nào

• Khi đến chỗ làm mới, tôi thật sự ghét việc ai đó cấp cho mình cả đống quyền chỉ vì “như vậy dễ hơn”. Không nên làm thế
  Việc đó không chỉ khiến công ty phơi mình trước nguy cơ bị xâm nhập, mà còn đẩy cho tôi trách nhiệm tôi không muốn. Tôi có thể vô tình phá hỏng thứ quan trọng, và khi có thứ gì đó bị hack, mọi người có thể nghi ngờ tôi chỉ vì tôi có quyền đó

  • Nếu nghĩ đến khối lượng phải quản lý toàn bộ tài khoản và quyền trên nhiều dịch vụ cho từng nhân viên, luồng đó cũng có cảm giác như một sự tiến hóa tự nhiên
    Thực chất chúng ta đang trải qua thứ giống popup bảo mật của Windows XP ở cấp độ dịch vụ. Ở mỗi bước của công việc, bạn lại bị yêu cầu xác thực với một thứ khác, và có thể mất vài ngày mới nhận được đúng thông tin xác thực với đúng quyền phù hợp
    Về mặt con người, cũng có thể hiểu được việc đội hỗ trợ bỏ cuộc và ném một loạt tài khoản cùng quyền cho nhân viên mới

• Phần còn thiếu trong bài này là nếu một tài khoản phi vận hành có quyền quản trị viên miền vận hành, thì các tác giả định nghĩa “vận hành” như thế nào

  • Tôi nghĩ đây là điểm cốt lõi. Bài viết và các trích dẫn gọi việc này là “sai sót”, nhưng trong một tổ chức lớn và phức tạp như Microsoft, tôi cho rằng việc phân quyền sai là không thể tránh khỏi
    Vì vậy, tập trung vào góc nhìn “ở một công ty 220 nghìn người, tại một thời điểm nào đó có ai đó mắc lỗi” thì không hữu ích lắm
    Nhưng ở hầu hết các công ty, thường có một ranh giới chắc chắn và dày giữa hệ thống vận hành và hệ thống thử nghiệm. Việc cấp quyền truy cập vận hành cho tài khoản thử nghiệm về thực tế phải là điều không thể, nên trọng tâm điều tra nên là vì sao chuyện đó lại xảy ra

• Tôi từng thấy trường hợp còn tệ hơn. Tôi làm ở một hãng luật, nơi họ cấp cho quản trị viên và các partner quyền truy cập quản trị viên đối với mọi thứ
  Sau khi đặt lại mật khẩu, mật khẩu mặc định là “passme”, vì mật khẩu ban đầu quá dài nên khó nhớ. Sau khi đăng nhập vào máy chủ thì họ phải đổi mật khẩu
  Hacker đã chiếm vài tài khoản của họ, táy máy đủ thứ và đánh cắp dữ liệu. Một số tài khoản thử nghiệm cũng có quyền quản trị viên
  May là tôi không còn làm ở đó nữa. Tôi là programmer analyst và chỉ có quyền quản trị viên trên PC của mình để chạy Visual BASIC 6.0

• Kiểu mẫu này trong toàn bộ hệ sinh thái Microsoft gần như là quy luật hơn là ngoại lệ, nhưng việc chính Microsoft làm như vậy thì đặc biệt mất mặt
  Đội bảo mật Microsoft đã bỏ khá nhiều công sức vào các công cụ và tài liệu best practice để ngăn những sự cố lớn kiểu này

  • Tôi tò mò tài khoản thử nghiệm đầu tiên đã bị chiếm như thế nào. Có lẽ là không có xác thực đa yếu tố, rồi sau password spraying qua luồng OAuth ROPC và tiếp đó là di chuyển ngang
    M365 khá tệ trong việc bắt buộc xác thực đa yếu tố. Nó được cấu trúc theo kiểu phải trả tiền
  • Những chuyện như thế này xảy ra khắp nơi. Cách thử nghiệm của rất nhiều người tôi từng làm cùng gần như lúc nào cũng là cấp quyền tối đa. Không rõ nữa, nhưng cảm giác giống kiểu debug bằng shotgun
    Vấn đề lớn hơn là mọi người quên mất. Họ tạo năm tài khoản thử nghiệm có quyền quản trị viên, rồi chúng không lộ ra cho đến khi có ai đó audit quyền người dùng toàn công ty

• Công ty trước đây tôi làm để tất cả mật khẩu của máy chủ và cơ sở dữ liệu vận hành trong một file văn bản trong kho mã nguồn. Lý do là kiến trúc sư trưởng không muốn phải nhớ mật khẩu
  Khi tôi nói với CTO chuyện đó ngu ngốc đến mức nào, câu trả lời tôi nhận được là “chúng tôi tin tưởng nhân viên” và “chúng tôi đã vượt qua kiểm toán bảo mật”
  Đến giờ tôi vẫn còn chịu hậu quả của cú úp mặt vào lòng bàn tay đó

  • Tôi cũng ghét mật khẩu cơ sở dữ liệu. Chúng bị crack quá nhanh
    Nó chỉ là thứ gây phiền toái chứ không phải tính năng bảo mật. Tôi không dùng mật khẩu kiểu “c00lz500”, mà dùng kiểu chuỗi rỗng luôn
    Thay vào đó tôi dùng tường lửa và mạng nội bộ