Chi tiết ban đầu về nguyên nhân sự cố va chạm của CrowdStrike CSAgent.sys
(twitter.com/patrickwardle)- Sự cố Windows trên toàn cầu ban đầu được phân tích là do CSAgent.sys của CrowdStrike đi theo một luồng tham chiếu đến địa chỉ bộ nhớ sai
- Lệnh gây vấn đề là
mov r9d, [r8], và trongR8có địa chỉ chưa được ánh xạ được lấy ra làm chỉ số từ một mảng con trỏ - Các tệp
C-00000291-...xxx.syscó vẻ không phải là driver kernel mà là dữ liệu bị làm rối mà CSAgent.sys đọc, và CrowdStrike xác nhận đây là các tệp cấu hình Channel Files - CrowdStrike cho biết
C-00000291-đã gây ra lỗi logic dẫn đến sự cố sập hệ điều hành, đồng thời bác bỏ suy đoán rằng nguyên nhân là null byte bên trong Channel File - Đợt phát hành lần này được xử lý như cập nhật nội dung chứ không phải cập nhật phiên bản, nên đã có trường hợp vượt qua kiểm soát staging của một số client, và crash report trở thành manh mối then chốt trong việc phân tích nguyên nhân
Luồng va chạm của CSAgent.sys
- Phân tích ban đầu là phân tích tĩnh được thực hiện bằng cách đảo ngược CSAgent.sys của CrowdStrike và dựa trên một crash dump duy nhất
- Khi đó người viết đang chia sẻ tài liệu và đề nghị điều tra thêm mà không có hệ thống Windows hay VM
- CSAgent.sys được phân tích dựa trên tệp được tải lên VirusTotal: Mẫu VirusTotal
- Điểm xảy ra va chạm là lệnh
mov r9d, [r8]R8là một địa chỉ chưa được ánh xạ- Giá trị này là địa chỉ được lấy từ mảng con trỏ trong
RAXbằng chỉ sốRDX(0x14 * 0x8)
- Các tệp
.syskhác nhưC-00000291-...32.syscó vẻ không phải driver thực sự mà giống dữ liệu bị làm rối- Có dấu hiệu cho thấy CSAgent.sys tham chiếu hoặc đọc các tệp này
- Vì việc xóa các tệp này có thể giải quyết sự cố va chạm, nên có khả năng nội dung tệp đã ảnh hưởng đến sự cố của CSAgent.sys
- Cũng có ghi chú rằng nếu debug thì có thể xác nhận dễ hơn
- Tệp
.zipđược chia sẻ bao gồm nhiều phiên bản CSAgent.sys, IDB và nhiều tệpC-....sys- Có mô tả rằng một trong các tệp mới nhất dường như chứa “fix”
- Liên kết chia sẻ: Google Drive zip
Channel Files và các xác nhận từ CrowdStrike
- Kevin Beaumont viết rằng các tệp
.sysgây ra sự cố là channel update files, và định dạng sai đã làm sập driver CS cấp cao hơn- Liên kết: Bài đăng của Kevin Beaumont
- Phần giải thích kỹ thuật của CrowdStrike xác nhận hướng phân tích ban đầu
- Tệp
C-...syskhông phải driver kernel mà là các tệp cấu hình Channel Files C-00000291-đã kích hoạt lỗi logic, và kết quả là hệ điều hành bị sập thông qua CSAgent.sys- Liên kết: Giải thích kỹ thuật của CrowdStrike
- Tệp
- Một số người suy đoán nguyên nhân là Channel File rỗng
0x0, nhưng CrowdStrike phủ nhận rằng vấn đề liên quan đến null byte trong Channel File- Malware Utkonos chỉ ra kiểm tra rằng tệp phải bắt đầu bằng
0xaaaaaaaa: Bài đăng liên quan
- Malware Utkonos chỉ ra kiểm tra rằng tệp phải bắt đầu bằng
- Đã được xác nhận rằng channel update được triển khai theo cách vượt qua kiểm soát staging của một số client
- Một số nhân sự IT xác nhận rằng họ đã cấu hình chính sách CrowdStrike để bỏ qua phiên bản mới nhất, nhưng bản cập nhật lần này đã vượt qua vì đó không phải cập nhật phiên bản mà là cập nhật nội dung
- Bài đăng liên quan: Chủ đề trên ResetEra
- Trong các bằng sáng chế của CrowdStrike cũng nhiều lần xuất hiện cụm từ channel files
- Ví dụ có nhắc đến US11822515B2 và US11645397B2
- Từ khóa tìm kiếm là
channel file assignee:(Crowdstrike, Inc.)
crash report và manh mối về macOS System Extensions
- crash report là phương tiện để hiểu sự cố của CrowdStrike, đồng thời cũng từng được dùng để phơi bày một 0day khác trên macOS
- Tên bài trình bày Black Hat liên quan là “The Hidden Treasure of Crash Reports?”
- Liên kết: Trang bài trình bày Black Hat
- Việc Apple loại bỏ kext của bên thứ ba và chuyển sang System Extensions ở chế độ người dùng được đánh giá tích cực
- Tuy nhiên cũng có ghi nhận rằng trong quá trình chuyển đổi này đã xuất hiện các vấn đề như kernel panic, leo thang đặc quyền và gỡ bỏ công cụ bảo mật
- Trong mã kernel hỗ trợ user-mode System Extensions trên macOS có nhiều lỗi, và từng có trường hợp công cụ bảo mật đã chuyển sang chế độ người dùng nhưng lại gây kernel panic diện rộng cho các kext cốt lõi của Apple
- Vấn đề leo thang đặc quyền trong framework System Extension cốt lõi của macOS có nhắc đến CVE-2019-8805
- Bài trình bày liên quan: Endpoint Security and Insecurity
- Do lỗi xử lý System Extensions, mã không có đặc quyền hoặc malware có thể gây ra việc gỡ bỏ công cụ bảo mật
- Ví dụ được nêu là ngay cả trên macOS mới nhất cũng có thể chấm dứt LuLu, một firewall chạy như System Extension đáng tin cậy
- Lỗi này không chỉ áp dụng riêng cho LuLu
1 bình luận
Ý kiến trên Hacker News
Ngay khi thấy câu “đây là bản cập nhật nội dung gây BSOD, xóa đi là giải quyết được”, tôi đã nghĩ mình có thể cược £100 rằng đó là sự kết hợp giữa dữ liệu nhị phân bị hỏng và một parser viết kém
Tôi đã làm máy tính khá nghiêm túc khoảng 10 năm qua và hoàn toàn không làm an ninh mạng, nhưng tôi cho rằng gần như mọi CVE, crash, bug, suy giảm hiệu năng và nỗi khổ đều đến từ quá trình giải tuần tự hóa dữ liệu nhị phân trở lại thành cấu trúc dữ liệu mà máy có thể đọc
Vì lập trình viên con người bỏ sót các edge case, và ngôn ngữ mệnh lệnh cho phép điều đó. Bao gồm tất cả: thuật toán giải nén, bộ đọc đường viền phông chữ, parser ảnh/video/audio, parser dữ liệu game, parser XML/HTML, parser chứng chỉ/chữ ký/khóa của OpenSSL, cho đến parser nội dung của CrowdStrike EDR lần này
Có thể tôi còn đặt thêm £50 cho giả thuyết thứ hai
File hỏng hoặc đã vượt qua kiểm thử nội bộ, hoặc không hề có kiểm thử nội bộ; có vẻ các thiết lập riêng về thời điểm áp dụng cập nhật cũng bị phớt lờ. Ngoài ra, họ phát hành đồng thời trên toàn thế giới nên không giới hạn được thiệt hại, và hiện vẫn chưa biết vì sao file bị hỏng ngay từ đầu
Giải tuần tự hóa dữ liệu không đáng tin cậy (CWE-502) đứng thứ 15, còn vị trí số 1 là ghi ngoài biên (CWE-787), vị trí số 4 là use-after-free (CWE-416). Các điểm yếu xuất hiện trong danh sách mọi lần kể từ năm 2019 được tổng hợp tại https://cwe.mitre.org/top25/archive/2023/2023_stubborn_weaknesses.html
Nhân tiện, tôi đã làm trong lĩnh vực an toàn thông tin hơn 30 năm
Ngược lại, một biến thể Scheme tôi dùng 20 năm trước là ngôn ngữ hàm nhưng không kiểm tra xem đã bao phủ mọi trường hợp chưa, và ghc của Haskell vài năm trước cũng không bật kiểm tra đó mặc định. Không biết giờ đã đổi chưa
Một số quản trị viên IT xác nhận rằng dù họ đặt chính sách CS là bỏ qua phiên bản mới nhất, bản này vẫn vượt qua vì không phải “cập nhật phiên bản” mà là “cập nhật nội dung”. Nếu cập nhật nội dung có thể làm hỏng client, nó không được phép vượt qua kiểm soát staging hay chính sách
Việc có thực sự cần phần mềm giám sát endpoint dựa trên rootkit như CS hay không là chuyện khác, nhưng để đưa lĩnh vực này sang các chuẩn mực đạo đức hơn, phương án mã nguồn mở có thể rất mạnh
Nếu công cụ cốt lõi là mã nguồn mở, mọi người sẽ minh bạch biết nó làm chính xác những gì, và công chúng có thể kiểm toán xem có backdoor hay bug nghiêm trọng không. Trong khi đó, cách đội bảo mật cung cấp chữ ký malware vẫn có thể là mô hình kinh doanh
Ở góc nhìn người dùng, tôi không thể yên tâm rằng một rootkit giám sát mã nguồn mở được kiểm thử và phát triển tốt hơn, hoặc có tính đến lợi ích của tôi. Vấn đề là toàn bộ phạm trù phần mềm giám sát. Nó không nên tồn tại. Công ty nào dùng thứ này là không hiểu bảo mật, không tin nhân viên, và cũng không phải nơi tốt để làm việc
Nó có trên mọi thiết bị client của Google
Những công cụ này cung cấp lớp bảo vệ thiết yếu trước các mối đe dọa tinh vi và thực sự phát hiện được chúng. Nếu bài test có máy Windows, khi không có EDR thì công việc của tôi dễ hơn 90%
Cũng có EDR mã nguồn mở như OpenEDR, nhưng đã cũ và chất lượng telemetry kém: https://github.com/ComodoSecurity/openedr. Gom các loại mã proof-of-concept trên GitHub để làm EDR vận hành thực tế là không khả thi và không an toàn
Bản thân sensor EDR trở thành mục tiêu tấn công. Với kẻ tấn công, EDR thường là trở ngại duy nhất, nên nếu mở mã nguồn thì nguy cơ làm chậm phát triển bằng các đóng góp mã độc hoặc cài lỗ hổng sẽ tăng lên. Phát triển sensor bảo mật là một môi trường cực kỳ đối địch, nơi bạn không thể chắc chắn đối phương là ai
Thực tế gần như ngược lại. Các quy tắc heuristic malware mã nguồn mở có tồn tại, như quy tắc phát hiện của Elastic Security: https://github.com/elastic/detection-rules. Elastic cũng cung cấp EDR gồm cả kernel driver, và theo kinh nghiệm thì thuộc loại khó vượt hơn. Nếu làm EDR không driver trên Windows thì công việc của tôi sẽ dễ hơn
Sensor EDR vốn đã được các nhà nghiên cứu bảo mật và kẻ tấn công “kiểm toán”. Việc reverse engineering và debug để tìm điểm yếu vẫn diễn ra liên tục. Nếu phát hiện vấn đề ở mức EDR nhận rồi chạy nguyên kernel-mode shellcode, tất nhiên họ sẽ công bố
Nó phức tạp hơn rất nhiều so với một chương trình tra cứu hash đơn giản
Khó hiểu vì sao không bắt được trong triển khai thử nghiệm. Tò mò không biết khác biệt nào đã khiến vấn đề chỉ phát sinh khi triển khai ra thế giới bên ngoài
Khó tin là họ không kiểm thử trước khi triển khai, và các doanh nghiệp cũng nên có môi trường kiểm thử trước khi triển khai thành phần bên thứ ba. Trong quá trình phát triển, việc cài gói rồi thất bại hoặc gây lỗi là chuyện thường, nhưng không ai nghĩ đưa thẳng vào môi trường vận hành mà không kiểm thử là ý hay. Không rõ vì sao trường hợp này lại khác
Ở pipeline 1, các bản cập nhật mã phần mềm có lẽ được xem là thay đổi quan trọng, đi qua môi trường phi vận hành và kiểm thử canary rồi mới triển khai “phiên bản” mới trên toàn cầu
Ở pipeline 2, có thể họ xử lý các bản cập nhật nội dung/kênh theo cách khác. Vì đường này chỉ phân phối những thứ như chữ ký mã độc mới, nên có lẽ họ giả định tệp mới là tệp dữ liệu theo định dạng chuẩn, không được “thực thi” mà chỉ được đọc
Bản thân pipeline này ban đầu hẳn đã được kiểm thử và được đánh giá là hoạt động đạt yêu cầu, nhưng có lẽ không có bước kiểm thử để xác minh tính toàn vẹn của tệp dữ liệu được tạo ra, hoặc quan trọng hơn là kiểm tra xem khi triển khai tới phiên bản phần mềm đang dùng mới nhất thì có hoạt động không lỗi hay không
Phần mềm agent đọc tệp channel hằng ngày có lẽ đã được kiểm thử “kỹ lưỡng” trong pipeline 1 với mọi kích thước tệp dữ liệu có thể và nội dung mô phỏng. Dù vậy, tệp dữ liệu sai đáng ra tất nhiên phải bị từ chối như một lỗi
Kịch bản chính xác lần này có thể là pipeline hỏng ở đường thứ hai đã tạo ra một tệp dữ liệu sai ở dạng đặc biệt, và trường hợp cụ thể đó chưa từng được hình dung hoặc kiểm thử trong pipeline phát triển/kiểm thử/triển khai của phiên bản phần mềm
Nếu đúng như vậy thì bài học rất rõ ràng. Dù chỉ là triển khai dành cho “dữ liệu”, pipeline có chuẩn hóa và ổn định đến đâu thì vẫn bắt buộc phải kiểm thử trước khi triển khai quy mô lớn. Chi phí và độ trễ sẽ tăng, nhưng phải chấp nhận. Cũng giống như lý do ban đầu người ta trả tiền cho phần mềm “bảo mật”
Khách hàng doanh nghiệp cũng tương tự: cần kiểm thử các gói triển khai mới ở khu vực phi vận hành của môi trường IT, hoặc có triển khai canary trước khi cho phép trên toàn bộ fleet vận hành
Khi công ty tìm cách bước vào mảng bảo mật endpoint và phát hiện bất thường mạng, nhiều khách hàng tiềm năng yêu cầu SLA 4 giờ cho nhiều loại CVE và mức độ nghiêm trọng khác nhau. Nghĩa là cần kỹ sư bảo mật trực on-call 24/7 và tạo/triển khai định nghĩa trong dưới 4 giờ, và 4 giờ đó phải đủ để triển khai tới 100% mục tiêu
Việc viết và triển khai định nghĩa chất lượng cao cho zero-day trong 4 giờ đã khó, đưa nó qua pipeline kiểm thử còn khó hơn, chưa nói đến việc viết các bài kiểm thử mới thực sự bao phủ được. Trong lĩnh vực đó, điều này được xem là “bình thường”, nên đã nhanh chóng bỏ cuộc. Cũng không ngạc nhiên nếu CS đang làm việc theo cách tương tự ở đây
Dù vậy vẫn rất tệ, nhưng nếu phát hành mà không kiểm thử gì thì đó thật sự là mức độ cẩu thả gây sốc
Điều tôi không hiểu là phần ít kỹ thuật hơn nhiều nhưng quan trọng hơn. Không rõ vì sao phạm vi ảnh hưởng lại lớn đến vậy
Tôi từng triển khai những dịch vụ kém quan trọng hơn nhiều với giám sát tự động và rollback, theo tốc độ chậm hơn nhiều. Đầu tiên triển khai lên beta không có traffic khách hàng, nếu không có vấn đề thì triển khai tới một phần nhỏ của fleet, rồi từ từ tăng tỷ lệ host nhận cập nhật
Với cách này, vấn đề lẽ ra đã dừng lại ngay lập tức; tôi cứ nghĩ đây là thông lệ phổ biến
Khi biết về một virus mới thì nó đã lan ngoài thực tế rồi, nên từng phút đều quan trọng. Bạn không muốn trì hoãn một ngày rồi mới biết rằng máy chủ đã bị xâm nhập từ 20 giờ trước
Kỳ vọng có lẽ là dù không muốn các thay đổi có khả năng gây lỗi, người dùng vẫn luôn muốn các quy tắc phát hiện virus mới nhất. Edge case bị bỏ sót là việc cấu hình chưa được kiểm thử làm hỏng mã hiện có
Nguồn là suy đoán thuần túy, nên đừng trích dẫn trong bài báo
Có rất nhiều cách để tránh vấn đề này, hoặc ít nhất giảm rủi ro xảy ra, nhưng như mọi khi lợi nhuận được đặt trước con người
Điều đáng ngạc nhiên là vai trò của Microsoft gần như không được bàn tới trong sự cố lần này. Microsoft không phải bên chịu trách nhiệm cho lỗi trực tiếp gây crash, nhưng họ đã tạo ra một môi trường thiếu động lực — tức lợi ích và cạnh tranh — để khiến Windows có khả năng chống chịu linh hoạt trước những tình huống như thế này
Microsoft gần như giữ vị thế độc quyền trong lĩnh vực điện toán workstation, và giờ đã gần giống hạ tầng, nên họ có nghĩa vụ cẩn trọng trong việc bảo đảm bảo mật, độ tin cậy và chức năng của sản phẩm
Vì không có cạnh tranh, Microsoft đã buông tay khỏi đổi mới Windows, và một phần trong số đó có thể đã ngăn được sự cố lần này. Ví dụ, CrowdStrike chạy ở user space trên macOS và Linux, vậy Windows không thể cung cấp các chức năng để CrowdStrike chạy ở user space sao?
Liệu những đổi mới về sandboxing ứng dụng có thể làm giảm nhu cầu về mức quyền kiểm soát mà CrowdStrike đòi hỏi không?
Microsoft thực tế đang nắm chìa khóa của hạ tầng điện toán toàn cầu mà gần như không có cạnh tranh và cũng hầu như không bị giám sát. Windows từng chiếm hơn 80% doanh thu của Microsoft, nhưng nay đã giảm xuống khoảng 10%
Doanh nghiệp tư nhân chạy theo tiền không có gì sai, nhưng nếu sản phẩm là thiết yếu cho vận hành bệnh viện, hãng hàng không và hạ tầng trọng yếu, thì không thể chỉ bám vào trợ lý AI và quảng cáo để tăng lợi nhuận
Tôi cho rằng Microsoft đã bỏ lỡ nghĩa vụ cẩn trọng đối với người tiêu dùng, và CrowdStrike là một triệu chứng của điều đó. Chính phủ nên nghiêm túc khuyến khích cạnh tranh trong thị trường desktop workspace, hoặc nếu không thì phải quản lý sản phẩm Microsoft Windows
Một điểm tích cực của việc tỷ trọng doanh thu Windows giảm là MS có thể sẽ không còn coi Windows như một vùng thánh địa không thể đụng tới nữa
Tôi không trực tiếp dùng CrowdStrike, và theo tôi biết thì cũng chưa từng cài nó trên hệ thống của mình. Thiết bị công ty gần nhất của tôi hình như có chạy thứ gì đó tương tự, nên nếu tôi sai thì xin sửa
Driver CS được cài trước và không thể gỡ, có lẽ được bộ giám sát từ xa phát hiện, và vì là driver đã ký nên dường như họ đã bỏ nhiều công sức để khiến việc sửa đổi cũng khó hơn
Nhưng driver đó lại load tệp dữ liệu chưa ký mà người dùng cuối có thể tùy ý xóa sao? Người dùng cuối có thể tùy ý thêm những tệp như vậy để khiến driver hoạt động theo cách không nên làm không?
Tôi thắc mắc điều gì ngăn tác nhân độc hại dùng tệp dữ liệu độc hại để gây ra một sự cố quy mô lớn khác, hoặc tệ hơn là giành quyền kernel
Chỉ có thể làm bằng cách mount filesystem từ hệ điều hành khác, nhưng thường thì BitLocker sẽ ngăn điều đó
Khách hàng của CrowdStrike có tiếng nói nào về việc các bản cập nhật như thế này được phát hành không, hay họ chỉ chấp nhận để CrowdStrike có khả năng thực thi mã từ xa hoàn toàn trên mọi máy trong doanh nghiệp
Ít nhất thì tôi hy vọng các tổ chức chứng thực và những người làm về mật mã có thể loại những thứ như thế này khỏi hệ thống của họ
Việc CrowdStrike tự động hóa phần đó chính là cốt lõi của sản phẩm
Có lẽ chúng ta sẽ không được chứng kiến điều đó. Vì chính chúng ta có thể là một trong số hàng triệu người ấy
Tôi tự hỏi có ai biết liệu “channel file” này có được driver CS ký và xác minh hay không. Nếu không thì trông như một lỗ hổng lớn dẫn tới rootkit ring 0
Việc cài channel file cần có quyền, nhưng một khi làm được thì nó có thể ẩn sâu hơn nhiều trong hệ thống. Nếu channel file có thể gây segmentation fault thì có lẽ nó cũng có thể làm được nhiều việc hơn
Mọi đầu vào đi vào thứ chạy ở mức quyền cao như vậy tối thiểu phải được kiểm tra tính toàn vẹn. Đây là điều cơ bản. Chỉ riêng việc có thể xóa channel file đã gợi ý rằng thậm chí không có cơ chế chống sửa đổi