Project Glasswing: Bài học từ việc sử dụng Mythos để săn lùng lỗ hổng bảo mật

Trong vài tháng qua, Cloudflare đã tích cực thử nghiệm các mô hình ngôn ngữ lớn (LLM) chuyên về bảo mật trên cơ sở hạ tầng của riêng mình. Mục tiêu là giúp xác định các lỗ hổng tiềm ẩn trong hệ thống để khắc phục sớm, đồng thời dự đoán những kẻ tấn công có thể làm được gì với các mô hình mới nhất.

Trong số các LLM được thử nghiệm, Mythos Preview từ Anthropic đã tạo ra sự chú ý đặc biệt thông qua dự án Glasswing. Chúng tôi đã áp dụng nó vào hơn năm mươi kho lưu trữ mã nguồn (repository) để đánh giá khả năng thực tế. Bài viết này sẽ chia sẻ những quan sát, điểm mạnh, điểm yếu và cách kiến trúc cũng như quy trình cần thay đổi để có thể sử dụng mô hình này ở quy mô lớn.

Mythos Preview AI Model

Mythos Preview mang lại sự thay đổi gì?

Thẳng thắn mà nói, Mythos Preview là một bước tiến lớn. Sự nhảy vọt từ các mô hình biên giới (frontier models) đa dụng trước đây sang Mythos Preview ngày nay không chỉ là một sự tinh chỉnh, mà là một loại công cụ hoàn toàn khác thực hiện một loại công việc khác biệt.

Hai tính năng nổi bật nhất mà chúng tôi nhận thấy bao gồm:

Xây dựng chuỗi khai thác (Exploit chain construction): Một cuộc tấn công thực tế hiếm khi chỉ sử dụng một lỗi duy nhất. Nó thường xâu chuỗi nhiều lỗi nhỏ (attack primitives) lại với nhau. Ví dụ, biến lỗi use-after-free thành khả năng đọc/ghi bộ nhớ tùy ý, chiếm quyền kiểm soát luồng và sử dụng chuỗi ROP để kiểm soát hoàn toàn hệ thống. Mythos Preview có khả năng kết hợp các nguyên thủy này và lập luận cách kết hợp chúng thành một bằng chứng hoạt động. Cách tư duy này trông giống như công việc của một nhà nghiên cứu cấp cao hơn là đầu ra của một máy quét tự động.

Tạo bằng chứng (Proof generation): Tìm lỗi và chứng minh nó có thể khai thác được là hai việc khác nhau. Mythos Preview có thể làm cả hai. Nó viết mã để kích hoạt lỗi nghi ngờ, biên dịch mã đó trong môi trường tạm thời và chạy thử. Nếu chương trình hoạt động như mong đợi, đó là bằng chứng. Nếu không, mô hình sẽ đọc thông báo lỗi, điều chỉnh giả thuyết và thử lại. Vòng lặp này quan trọng không kém việc tìm lỗi, bởi một lỗ hổng nghi ngờ mà không có bằng chứng hoạt động chỉ là sự phỏng đoán.

Vấn đề từ chối trong nghiên cứu bảo mật hợp pháp

Mặc dù phiên bản Mythos Preview được cung cấp trong Project Glasswing không có các biện pháp bảo vệ bổ sung như các mô hình phổ thông (như Opus 4.7 hay GPT-5.5), nó vẫn tự nhiên "đẩy lùi" một số yêu cầu nhất định.

Tuy nhiên, những sự từ chối này không nhất quán. Cùng một nhiệm vụ nhưng được trình bày khác nhau hoặc trong bối cảnh khác có thể tạo ra kết quả hoàn toàn trái ngược. Ví dụ, mô hình ban đầu từ chối nghiên cứu lỗ hổng trên một dự án, nhưng sau đó đồng ý thực hiện cùng một nghiên cứu trên mã đó sau một thay đổi không liên quan trong môi trường của dự án.

Điều này quan trọng vì các rào chắn tự phát của mô hình là có thật nhưng chưa đủ nhất quán để đóng vai trò là ranh giới an toàn hoàn chỉnh. Đó là lý do tại sao bất kỳ mô hình an ninh mạng nào được phát hành rộng rãi trong tương lai đều cần phải bao gồm các biện pháp bảo vệ bổ sung bên trên hành vi cơ bản này.

Giải quyết vấn đề tín hiệu trên nhiễu

Một trong những phần khó khăn nhất của việc phân loại (triage) lỗ hổng bảo mật là quyết định lỗi nào là thật, lỗi nào có thể khai thác và lỗi nào cần khắc phục ngay. AI đã làm vấn đề này trở nên phức tạp hơn với hàng loạt báo cáo dương tính giả.

Hai yếu tố chi phối tỷ lệ nhiễu là:

Ngôn ngữ lập trình: C và C++ cho phép kiểm soát bộ nhớ trực tiếp và đi kèm với các lớp lỗi như tràn bộ đệm (buffer overflows) mà các ngôn ngữ an toàn bộ nhớ như Rust loại bỏ ở giai đoạn biên dịch. Chúng tôi thấy nhiều dương tính giả hơn từ các dự án sử dụng ngôn ngữ không an toàn bộ nhớ.

Thiên kiến của mô hình: Các mô hình thường tìm ra lỗi dù mã có thực sự lỗi hay không, với các từ ngữ né tránh như "có thể", "tiềm năng". Điều này gây lãng phí sự chú ý của con người.

Mythos Preview thể hiện sự cải thiện rõ rệt ở đây, đặc biệt là khả năng cung cấp PoC đi kèm. Một phát hiện có PoC là phát hiện có thể hành động ngay, giúp giảm thiểu thời gian đặt câu hỏi "lỗi này có thật không?".

Harness Architecture

Tại sao tác nhân lập trình chung không hiệu quả?

Ban đầu, chúng tôi thử pointing một tác nhân lập trình (coding agent) chung vào một kho lưu trữ và yêu cầu nó tìm lỗ hổng. Cách tiếp cận này thất bại trong việc bao phủ mã nguồn có ý nghĩa vì hai lý do chính:

Bối cảnh (Context): Tác nhân lập trình được tinh chỉnh cho một luồng công việc tập trung như xây dựng tính năng hoặc sửa lỗi. Nó giữ một giả thuyết tại một thời điểm. Điều này sai cho nghiên cứu bảo mật, vốn mang tính hẹp và song song. Một nhà nghiên cứu con người sẽ nhìn vào một lớp lỗi cụ thể hàng nghìn lần trên toàn bộ mã nguồn, trong khi một tác nhân đơn lẻ có thể chỉ bao phủ một phần nhỏ bề mặt trước khi cửa sổ ngữ cảnh bị đầy.

Thông lượng (Throughput): Một tác nhân luồng đơn làm một việc tại một thời điểm, nhưng các cơ sở mã thực tế cần nhiều giả thuyết đối với nhiều thành phần cùng lúc.

Cấu trúc của hệ thống phát hiện lỗ hổng (Harness)

Chúng tôi nhận ra rằng cần một hệ thống "harness" để quản lý việc thực thi tổng thể. Bốn bài học rút ra là: phạm vi hẹp tạo ra phát hiện tốt hơn, xem xét đối kháng (adversarial review) giảm nhiễu, tách chuỗi tác vụ qua các tác nhân tạo ra lập luận tốt hơn, và các tác vụ hẹp song song tốt hơn một tác nhân toàn diện.

Dưới đây là quy trình harness của chúng tôi giai đoạn từng giai đoạn:

• Recon (Trinh sát): Một tác nhân đọc kho lưu trữ, tạo tài liệu kiến trúc bao gồm lệnh build, ranh giới tin cậy, điểm nhập và bề mặt tấn công.
• Hunt (Săn lùng): Mỗi nhiệm vụ là một lớp lỗi kết hợp với gợi ý phạm vi. Các "thợ săn" chạy song song (khoảng 50 cái cùng lúc), mỗi cái có công cụ để biên dịch và chạy mã PoC.
• Validate (Xác thực): Một tác nhân độc lập đọc lại mã và cố gắng bác bỏ phát hiện ban đầu để bắt nhiễu.
• Gapfill: Các khu vực đã chạm tới nhưng chưa bao phủ kỹ sẽ được xếp hàng lại để chạy thêm lần nữa.
• Dedupe: Các phát hiện trùng nhau sẽ được gộp thành một bản ghi.
• Trace (Truy vết): Đối với mỗi lỗ hổng đã xác nhận trong thư viện dùng chung, một tác nhân truy vết sẽ quyết định xem đầu vào của kẻ tấn công có thực sự chạm được đến lỗi từ bên ngoài hệ thống hay không. Đây là giai đoạn quan trọng nhất.
• Feedback: Các dấu vết có thể tiếp cận trở thành nhiệm vụ săn lùng mới trong các kho lưu trữ tiêu thụ nơi lỗi thực sự bị phơi bày.
• Report: Một tác nhân viết báo cáo có cấu trúc và gửi tới API tiếp nhận.

Ý nghĩa đối với các đội ngũ bảo mật

Phản ứng lớn nhất từ các lãnh đạo bảo mật về Mythos Preview là tốc độ - quét nhanh hơn, vá nhanh hơn. Tuy nhiên, chỉ tốc độ thôi là chưa đủ. Vá lỗi nhanh hơn không thay đổi được hình dạng của quy trình tạo ra bản vá. Nếu kiểm thử hồi quy (regression testing) mất một ngày, bạn không thể đạt được SLA 2 giờ mà không bỏ qua nó, và việc bỏ qua kiểm thử thường dẫn đến lỗi tồi tệ hơn.

Câu hỏi khó hơn là kiến trúc xung quanh lỗ hổng nên trông như thế nào. Nguyên tắc là làm cho việc khai thác khó khăn hơn cho kẻ tấn công ngay cả khi lỗi tồn tại. Điều này có nghĩa là các biện pháp phòng thủ đứng trước ứng dụng để chặn việc tiếp cận lỗi, thiết kế ứng dụng sao cho lỗi ở một phần không cho kẻ tấn công quyền truy cập vào các phần khác, và khả năng triển khai bản vá cùng lúc ở mọi nơi mã đang chạy.

Security Defense

Cloudflare nhận thấy chủ đề này có hai mặt. Những khả năng giúp chúng tôi tìm lỗi trong mã của mình cũng sẽ, nếu rơi vào tay sai, tăng tốc phía tấn công chống lại mọi ứng dụng trên Internet. Chúng tôi sẽ chia sẻ thêm về điều này có ý nghĩa gì đối với khách hàng trong những tuần tới.