Kết quả điều tra kỹ thuật chính về việc thu được khóa của Storm-0558
(msrc.microsoft.com)- Tác nhân đe dọa có căn cứ tại Trung Quốc Storm-0558 đã giả mạo token bằng khóa ký consumer MSA bị đánh cắp để truy cập OWA và Outlook.com
- Một crash dump được tạo ra do hệ thống ký consumer bị crash vào tháng 4/2021 đã chứa khóa vì một điều kiện tranh chấp (race condition), và hệ thống không phát hiện được điều này
- Crash dump chứa khóa đã được chuyển từ mạng production cách ly sang môi trường gỡ lỗi trong mạng công ty có kết nối Internet, và cũng không bị phát hiện bởi quá trình quét thông tin xác thực
- Lý do có thể truy cập mail doanh nghiệp bằng khóa consumer là vì nhà phát triển hệ thống mail đã giả định sai rằng thư viện sẽ xác minh scope, nên không bổ sung xác minh issuer/scope
- Tất cả các lỗi đều đã được khắc phục, và các biện pháp tăng cường phòng thủ nhiều lớp như tự động hóa xác minh scope của khóa đã được áp dụng sau sự cố
Quá trình thu được khóa
- Microsoft vận hành một môi trường production cô lập và bị hạn chế, với kiểm tra lý lịch, tài khoản chuyên dụng, máy trạm truy cập bảo mật và xác thực đa yếu tố dựa trên hardware token
- Môi trường này chặn việc sử dụng các công cụ cộng tác như email, họp trực tuyến và nghiên cứu web để ngăn các đường xâm nhập tài khoản như lây nhiễm malware hay phishing
- Quyền truy cập hệ thống và dữ liệu bị giới hạn theo chính sách Just in Time / Just Enough Access
- Môi trường công ty (corporate environment) yêu cầu chứng thực bảo mật và thiết bị bảo mật, nhưng cho phép dùng email, họp và công cụ cộng tác nên dễ bị spear phishing, malware đánh cắp token, v.v.
- Theo nguyên tắc Zero-Trust và "assume breach", dữ liệu khóa không được rời khỏi môi trường production
- Vào tháng 4/2021, một vụ crash của hệ thống ký consumer đã tạo ra crash dump (ảnh chụp tiến trình bị crash)
- Crash dump lẽ ra không được chứa khóa ký vì có cơ chế che dữ liệu nhạy cảm, nhưng do điều kiện tranh chấp nên khóa đã bị đưa vào (đã sửa xong)
- Hệ thống cũng không phát hiện được sự hiện diện của khóa trong crash dump (đã sửa xong)
- Crash dump khi đó được cho là không chứa khóa đã được chuyển từ mạng production cách ly sang môi trường gỡ lỗi
- Việc này phù hợp với quy trình gỡ lỗi tiêu chuẩn, và quá trình quét thông tin xác thực cũng không phát hiện sự tồn tại của khóa (đã sửa xong)
- Sau khi khóa bị rò rỉ, tác nhân Storm-0558 đã xâm phạm tài khoản công ty của một kỹ sư Microsoft
- Tài khoản này có quyền truy cập vào môi trường gỡ lỗi nơi lưu crash dump chứa khóa
- Do chính sách lưu giữ log, không có log chứng minh cụ thể về vụ rò rỉ, nhưng đây là con đường có khả năng cao nhất dẫn đến việc thu được khóa
Vì sao có thể truy cập mail doanh nghiệp bằng khóa consumer
- Để đáp ứng nhu cầu khách hàng muốn hỗ trợ cả ứng dụng consumer lẫn doanh nghiệp, vào tháng 9/2018 Microsoft đã đưa vào endpoint công bố metadata khóa dùng chung
- Là một phần của việc hợp nhất này, tài liệu cũng được cập nhật để làm rõ yêu cầu xác minh scope của khóa theo từng loại tài khoản doanh nghiệp và consumer
- Microsoft cung cấp API để xác minh chữ ký về mặt mật mã, nhưng không cập nhật thư viện để tự động thực hiện xác minh scope (đã sửa xong)
- Hệ thống mail đã được cập nhật vào năm 2022 để sử dụng endpoint metadata dùng chung
- Nhà phát triển hệ thống mail đã giả định sai rằng thư viện thực hiện xác minh đầy đủ nên không bổ sung bước xác minh issuer/scope cần thiết
- Kết quả là hệ thống mail đã chấp nhận các yêu cầu mail doanh nghiệp bằng security token được ký bằng khóa consumer (đã sửa xong bằng thư viện đã cập nhật)
Rà soát sau sự cố và biện pháp cải thiện
- Xác định và xử lý điều kiện tranh chấp khiến khóa ký bị đưa vào crash dump
- Tăng cường phòng ngừa, phát hiện và ứng phó khi dữ liệu khóa bị đưa nhầm vào crash dump
- Tăng cường quét thông tin xác thực để phát hiện tốt hơn sự hiện diện của khóa ký trong môi trường gỡ lỗi
- Phát hành thư viện nâng cao để tự động hóa việc xác minh scope của khóa trong thư viện xác thực, đồng thời làm rõ tài liệu liên quan
Cập nhật bổ sung ngày 12/3/2024
- Giả thuyết cốt lõi rằng do lỗi vận hành, dữ liệu khóa đã rời khỏi môi trường ký security token và bị truy cập trong môi trường gỡ lỗi thông qua tài khoản kỹ sư bị xâm phạm vẫn được giữ nguyên; không có thay đổi về ảnh hưởng tới khách hàng/Microsoft hay hoạt động của tác nhân
- Dù từng nói rằng crash dump năm 2021 có thể là nguyên nhân khiến tác nhân truy cập được, nhưng không tìm thấy crash dump nào chứa dữ liệu khóa bị ảnh hưởng
- Điều kiện tranh chấp được nhắc đến không ảnh hưởng đến việc khóa có tồn tại trong crash dump hay không, mà ảnh hưởng đến việc crash dump có thể được đưa ra khỏi môi trường ký bảo mật hay không
- Cách diễn đạt rằng việc đưa crash dump ra ngoài phù hợp với quy trình gỡ lỗi tiêu chuẩn có nghĩa là trước đây điều đó không bị cấm; hiện nay quy trình gỡ lỗi tiêu chuẩn của Microsoft cấm đưa loại dữ liệu đó ra khỏi môi trường production
- Cuộc điều tra đang tiếp diễn đã cho thấy giới hạn của công nghệ quét thông tin xác thực, và các vấn đề sẽ được khắc phục ngay khi được phát hiện
1 bình luận
Ý kiến trên Hacker News
Có vẻ ở đây còn thiếu một mắt xích: việc khóa riêng tư vô tình lọt vào artefact gỡ lỗi do lỗi đồng thời hoặc lỗi an toàn bộ nhớ thì dễ hiểu, nhưng chẳng phải kẻ tấn công phải biết sự cố crash đã xảy ra, biết cấu trúc crash dump và đang chờ sẵn bên trong mạng nội bộ của Microsoft sao?
Phòng thủ với giả định đã bị xâm nhập là một chiến lược an ninh mạng tốt, nhưng không nên cứ thế chấp nhận tiền đề rằng thực sự đã bị xâm nhập
Dữ liệu kiểu này thường không được bảo quản đủ an toàn so với giá trị thực của nó. Từng làm ở FAANG, tôi thấy gần như mọi người mới chưa có kinh nghiệm về tài chính hoặc quy định doanh nghiệp đều nghĩ rằng có thể đính kèm crash data vào bug tracker. Vì vậy cần thay đổi thói quen để những thứ như crash dump được đưa vào một két an toàn đủ dễ dùng để mọi người không muốn lách qua
Nếu có một tài khoản kỹ sư bị xâm nhập, phải giả định ít nhất tài khoản đó có quyền truy cập bug tracker, và có lẽ cũng có thể lấy hoặc tạo debug symbol của binary. Phần còn lại chỉ là chờ một kỹ sư bất cẩn tải crash dump lên làm file đính kèm lỗi, rồi lấy nó trước khi ai đó nhận ra và xóa đi
Ngoài ra, công cụ quét thông tin xác thực của Microsoft đã không tìm thấy khóa, và họ nói vấn đề đó đã được sửa, nên có vẻ khóa ở dạng có thể bị phát hiện bằng quét
Nhìn chung, tình huống có vẻ là một kỹ sư đã chuyển dump chứa khóa sang tài khoản của mình rồi để đó một thời gian, sau đó kẻ tấn công đột nhập tài khoản, lấy toàn bộ các file có thể dùng được, rồi khi quét tìm khóa bằng công cụ tốt hơn Microsoft thì trúng lớn
Tức là kẻ tấn công đã ở trong mạng và tình cờ tìm thấy dump trong quá trình quét không bị phát hiện, hoặc ngay từ đầu đã nhắm vào chính tài khoản cụ thể này
Dù vậy, xét từ phía kẻ tấn công thì chuỗi sự kiện này có cảm giác quá may mắn đến khó tin
Có những lớp kỹ thuật hệ thống nói về quá trình các vấn đề nhỏ nối tiếp nhau theo một thứ tự nhất định và cuối cùng dẫn tới thất bại thảm họa. Vụ này có thể xem là thất bại thảm họa như vậy
Trước hết phải có race condition, và race condition đó phải dẫn tới kết quả ngoài dự kiến. Nếu code đã được kiểm thử và được dùng thường xuyên, thì khả năng xảy ra có lẽ đã dưới 10% ngay ở bước này. Tiếp đó, kỹ sư phải tình cờ quyết định rằng crash dump này là cần thiết, phần mềm quét thông tin xác thực phải không tìm ra đúng thông tin xác thực cụ thể này, một tài khoản phải bị xâm nhập để có quyền truy cập mạng và người dùng đó phải có thể truy cập dump này, rồi hacker phải tìm ra và lấy nó đi
Dù vậy, khóa đã cũ và lẽ ra chỉ dùng được để truy cập tài khoản email người tiêu dùng nên phải an toàn, nhưng lại còn có bug chấp nhận khóa cũ và bug không từ chối khóa ký này đối với token cho tài khoản email công ty
Đây là một bài học kỹ thuật hệ thống hay. Dù cố gắng đến đâu, cuối cùng nếu đủ nhiều thứ nhỏ nhặt tích tụ thì sẽ xảy ra sự cố lớn, nên phải thiết kế sao cho dù có nổ thì bán kính vụ nổ cũng bị giới hạn
Phân tích hậu kiểm thường trình bày như thể các sự kiện xui xẻo ngẫu nhiên chồng lên nhau. Như thể kẻ tấn công tình cờ nhắm vào Microsoft, tình cờ có race condition, tình cờ bị crash, và tình cờ tìm thấy crash dump ở đâu đó
Nhưng cũng phải nghĩ tới khả năng bug race condition ban đầu đã được cố ý cài vào. Crash có thể đã bị cố ý kích hoạt, kẻ tấn công có thể đã chờ dump xuất hiện ở một vị trí cụ thể, và cũng có thể đã có đồng phạm
Hệ sinh thái Microsoft trông như một chiếc xe Lego do đám trẻ con trong xóm mỗi đứa mang linh kiện từ nhà mình tới rồi lắp bừa lại với nhau
Khi gọi là race condition, mọi người sẽ nói “xác suất xảy ra dưới 10%”, nhưng thực tế có thể nó xảy ra với mọi crash lớn, chỉ là crash không diễn ra thường xuyên mà thôi
Vì sao không mask trước khi ghi xuống đĩa thì có trời mới biết
Cấu trúc mà hơn một nửa thế giới kinh doanh phương Tây phụ thuộc vào Outlook.com gần như là một trạng thái rất sai lệch, nhưng các động lực tài chính hiện nay không hướng tới khả năng phục hồi hay việc chia nhỏ những thực thể siêu tập trung như Outlook.com, nên có lẽ những chuyện như thế này sẽ còn tiếp diễn
Có những điểm chưa được giải thích rõ: nếu sự việc bị phát hiện vào ngày 11/7/2023 và bị nghi là đã xảy ra từ tháng 4/2021, điều đó có nghĩa là kẻ tấn công đã có thông tin xác thực này trong hơn 2 năm, và mất 2 tháng từ lúc phát hiện đến lúc công bố
Cũng thiếu thông tin về số lượng token bị giả mạo và mức độ truy cập đến đâu. Nếu không công bố thì người ta sẽ suy đoán theo hướng xấu
Cũng không có lịch trình từ khi phát hiện đến khi áp dụng bản sửa, chỉ nói rằng “vấn đề này đã được khắc phục”. Chỉ có thể hy vọng là họ đã sửa nhanh
Họ đã sửa 4 vấn đề trực tiếp, nhưng rõ ràng có vẻ tồn tại vấn đề mang tính hệ thống, mà cũng không thấy họ sẽ làm gì về điều đó
https://en.m.wikipedia.org/wiki/Adverse_inference
Một vụ xâm nhập kiểu này đòi hỏi hiểu biết rất sâu về hạ tầng nội bộ của Microsoft. Có thể an toàn khi xem đây là công việc có tổ chức của một nhóm hacker
Đây không phải việc rẻ tiền, nhưng phần thưởng thì khổng lồ. Siêu tập trung hóa khiến hacker dồn nỗ lực vào một số ít mục tiêu giá trị cao. Vì chỉ cần thành công là thu được rất nhiều
Tôi gần như chắc chắn rằng có các nhóm hacker được nhà nước hậu thuẫn đang nghiên cứu và phân tích sâu hạ tầng nội bộ của những nơi như Google, Microsoft, Amazon. Vụ xâm nhập này cho thấy họ đã hiểu rõ đến mức nào
Tôi nghĩ đã đến lúc phải phi tập trung hóa trong phạm vi ranh giới bảo mật rộng hơn
Nếu bỏ lớp ngôn từ thận trọng đi, thì ai đó đã tải minidump từ môi trường vận hành xuống workstation phát triển, rồi nó có lẽ nằm mục đâu đó trong OneDrive nội bộ của nhà phát triển đó cho đến khi tài khoản bị xâm nhập. Ai đó lấy được dump, tìm thấy key và trúng lớn
Cách diễn đạt “một vài lỗi mơ hồ đã bị khai thác tinh vi” có vẻ hơi lệch. Trông giống một chuỗi sai sót mà không hệ thống bảo mật nào làm đúng việc của mình hơn
Không hiểu tại sao họ không dùng HSM. Mục đích cốt lõi của phần cứng như vậy chẳng phải là ngăn rò rỉ vật liệu khóa sao
[1] https://www.futurex.com/download/excrypt-ssp-enterprise-v-2-...
Điều này có nghĩa là key không được lưu trong phần cứng không thể khôi phục, mà một tiến trình server thông thường — chỉ là code đã biên dịch chạy trong môi trường đặc quyền cao — có thể truy cập được
Cũng không có đề cập nào rằng hệ thống có thể truy cập key này nằm trong một môi trường riêng thay vì môi trường vận hành thông thường. Vì vậy có thể suy đoán rằng bất kỳ máy vận hành nào cũng có thể truy cập key, và bất kỳ ai có quyền truy cập môi trường đó đều có khả năng làm rò rỉ vật liệu khóa
Nhìn vào phần xác minh của https://learn.microsoft.com/en-us/azure/active-directory/dev..., nếu tôi không bỏ sót gì thì dường như vẫn thiếu điểm quan trọng là phải kiểm tra ngày của bên phát hành hoặc việc đã bị thu hồi hay chưa
Trong pseudocode cũng không có, nên rất có khả năng còn có các triển khai tin tưởng bất kỳ key nào từng được Microsoft công bố. Ý là như vậy, ngoại trừ các trường hợp ngoại lệ như xóa cache
Nếu ngay cả Microsoft còn không dùng đúng nền tảng định danh của chính mình trong sản phẩm chủ lực Outlook, thì những người khác còn có cơ hội gì
Về cơ bản họ chỉ kiểm tra xem nó có được Microsoft CA ký hay không. Đây là vấn đề rõ ràng đến khó tin trong code review
Một trong những lý do họ bị ảnh hưởng thật sự nặng có vẻ là vì không xoay vòng key. Nghe như đã có một khoảng thời gian khá dài giữa lúc key bị chuyển đến nơi không nên có nó và lúc nó thực sự bị đánh cắp
Nếu họ xoay vòng key thường xuyên, việc giả mạo token bằng key đó đã là bất khả thi
Mỗi khi đọc những bài kiểu này tôi đều có cảm giác rằng, chỉ vì cuộc tấn công là kỹ thuật số chứ không phải vật lý mà cấu trúc giao phó việc ứng phó với tấn công cấp quốc gia cho doanh nghiệp tư nhân thật sự rất kỳ lạ
Nếu một tiêm kích Trung Quốc bắn rơi máy bay FedEx trên Thái Bình Dương, việc đó sẽ bị xem là một cuộc tấn công vào chủ quyền Hoa Kỳ và chính phủ sẽ phản ứng thích đáng. Cũng sẽ không ai kỳ vọng FedEx phải tự sở hữu một phi đội tiêm kích để bảo vệ máy bay vận tải của mình. Cũng sẽ không ai nói “lỗi là ở FedEx vì không phòng không cho đàng hoàng”
Nhưng khi bước vào không gian số, bầu không khí lại thành ra chấp nhận rằng Microsoft phải tự phòng thủ trước Trung Quốc và Nga
Các chính phủ bắt giữ đặc vụ nước ngoài khá thường xuyên, nhưng những vụ bắt giữ như vậy không dẫn tới chiến tranh toàn diện
Thứ hai, Mỹ cũng luôn làm những việc như vậy, kể cả với các nước đồng minh, nên khó biện minh cho các biện pháp mạnh hơn
Phạm vi và số lượng các cuộc tấn công mạng là rất lớn, nhưng tôi hiểu rằng Mỹ cũng thực hiện nhiều cuộc tấn công đối ngoại ở quy mô tương ứng