Khi các nhóm Red Team cộng đồng phơi bày các lỗ hổng RCE SaaS nghiêm trọng

Điều gì đã xảy ra

Vào cuối năm 2025, một nền tảng cộng tác SaaS nổi bật, được các doanh nghiệp Fortune 100 áp dụng rộng rãi, đã phải đối mặt với một tiết lộ bảo mật nghiêm trọng. Trong một cuộc thi red-team cộng đồng, một nhà nghiên cứu bảo mật độc lập đã phát hiện ra một lỗ hổng thực thi mã từ xa (RCE) nghiêm trọng. Lỗ hổng này, sau đó được gán một CVE có mức độ nghiêm trọng cao, cho phép những kẻ tấn công không được xác thực thực thi mã tùy ý trên cơ sở hạ tầng của nền tảng, gây ra mối đe dọa hiện hữu đối với dữ liệu khách hàng và tính toàn vẹn của dịch vụ.

Phát hiện này đã gây ra làn sóng chấn động trong cộng đồng an ninh mạng, không chỉ vì mức độ nghiêm trọng mà còn vì sự dai dẳng của nó. Các cuộc kiểm toán bảo mật nội bộ, được thực hiện nghiêm ngặt trong hai năm trước đó, đã liên tục không phát hiện ra lỗ hổng cụ thể này. RCE bắt nguồn từ sự tương tác phức tạp giữa một điểm cuối API ít được sử dụng và một lỗ hổng deserialization, một chuỗi đã tỏ ra khó nắm bắt đối với các phương pháp quét và kiểm toán truyền thống.

Sự cố này nhấn mạnh một sự mất kết nối nghiêm trọng: sự khác biệt giữa các kiểm tra bảo mật theo định hướng tuân thủ và việc khai thác tập trung vào tác nhân đe dọa. Sự tham gia của cộng đồng đã mô phỏng các kịch bản tấn công trong thế giới thực, tận dụng các bộ kỹ năng đa dạng và các phương pháp tiếp cận độc đáo mà các nhóm nội bộ, thường bị giới hạn bởi phạm vi và phương pháp, thường bỏ qua.

Tại sao mô hình này cứ lặp lại

Kịch bản này không phải là một sự bất thường mà là một chủ đề lặp đi lặp lại trong bối cảnh mối đe dọa hiện đại. Các nhóm bảo mật doanh nghiệp, bất chấp những khoản đầu tư đáng kể, thường hoạt động trong một mô hình theo định hướng tuân thủ. Trọng tâm của họ có xu hướng là các lỗ hổng đã biết, cấu hình tiêu chuẩn và tuân thủ các khuôn khổ quy định như SOC 2, ISO 27001 hoặc NIST CSF.

Tuy nhiên, những kẻ tấn công trong thế giới thực hoạt động mà không có những ràng buộc đó. Chúng khai thác các đường tấn công mới, xâu chuỗi các lỗ hổng dường như vô hại và tận dụng các yếu tố con người để đạt được mục tiêu của mình. RCE trong nền tảng SaaS là một ví dụ điển hình về một vectơ tấn công phức tạp, nhiều giai đoạn không phù hợp với đầu ra máy quét tự động hoặc kiểm toán dựa trên danh sách kiểm tra.

Một yếu tố góp phần khác là quy mô và sự phức tạp tuyệt đối của phát triển phần mềm hiện đại. Kiến trúc microservices, tích hợp của bên thứ ba và các đường ống triển khai liên tục tạo ra một bề mặt tấn công ngày càng mở rộng. Một lỗi cấu hình nhỏ hoặc một lỗ hổng tinh vi trong một thành phần có thể, khi được xâu chuỗi với những thứ khác, dẫn đến các thỏa hiệp nghiêm trọng.

Hạn chế của các cuộc kiểm toán truyền thống

Các cuộc kiểm toán bảo mật truyền thống, mặc dù cần thiết cho vệ sinh cơ bản, thường bị giới hạn về phạm vi và thiếu tư duy đối đầu. Chúng được thiết kế để xác minh các biện pháp kiểm soát chống lại các mối đe dọa đã biết, chứ không phải để chủ động khám phá các chuỗi tấn công chưa biết. Các cuộc kiểm tra thâm nhập, mặc dù tích cực hơn, cũng có thể không đạt được hiệu quả nếu chúng bị giới hạn thời gian, có phạm vi quá hẹp hoặc được thực hiện bởi các nhóm thiếu chuyên môn sâu về các vectơ tấn công cụ thể.

"Tuân thủ là một sàn nhà, không phải là trần nhà. Chỉ dựa vào các cuộc kiểm toán tuân thủ để bảo vệ những tài sản quý giá nhất của bạn giống như xây một lâu đài không có mái nhà, hy vọng trời sẽ không bao giờ mưa." - CISO, Công ty Dịch vụ Tài chính Toàn cầu.

Kịch bản tấn công từng bước của kẻ tấn công

RCE được đề cập có thể đã tuân theo một chuỗi tấn công tinh vi, đặc trưng của các mối đe dọa dai dẳng nâng cao (APTs) hoặc các nhà nghiên cứu độc lập có kỹ năng cao. Điểm vào ban đầu được cho là một điểm cuối API không được xác thực, có lẽ chỉ dành cho mục đích nội bộ hoặc thiếu các kiểm soát truy cập thích hợp.

Kẻ tấn công trước tiên sẽ liệt kê các điểm cuối API có sẵn, thăm dò các phản hồi bất thường hoặc các hành vi không mong muốn. Giai đoạn trinh sát này, thường tận dụng các công cụ như Burp Suite hoặc các tập lệnh tùy chỉnh, rất quan trọng để xác định các liên kết yếu tiềm năng. Điều quan trọng ở đây là xác định một điểm cuối chấp nhận dữ liệu được tuần tự hóa.

Khi xác định được lỗ hổng deserialization, kẻ tấn công sẽ tạo ra một tải trọng độc hại. Tải trọng này, thường là một chuỗi gadget được xây dựng bằng các công cụ như YSOSerial, sẽ được thiết kế để thực thi các lệnh tùy ý trên máy chủ cơ bản. Thử thách nằm ở việc hiểu các thư viện và sự phụ thuộc của môi trường mục tiêu để đảm bảo chuỗi gadget hoạt động chính xác.

Cuối cùng, kẻ tấn công sẽ gửi đối tượng được tuần tự hóa độc hại đến điểm cuối API dễ bị tấn công. Việc thực thi thành công sẽ cấp cho chúng quyền kiểm soát máy chủ, cho phép trích xuất dữ liệu, di chuyển ngang hơn nữa hoặc thiết lập quyền truy cập dai dẳng. Toàn bộ quá trình này phản ánh các TTPs phổ biến được quan sát thấy trong các vụ vi phạm trong thế giới thực, thường bắt đầu bằng các lỗ hổng dường như nhỏ và leo thang thành tác động thảm khốc.

Những gì những người phòng thủ đã bỏ lỡ

Điểm mù hai năm đối với RCE quan trọng này làm nổi bật một số vấn đề hệ thống trong tư thế bảo mật của tổ chức phòng thủ. Thứ nhất, các cuộc kiểm toán bảo mật nội bộ của họ, mặc dù có lẽ toàn diện về bề rộng, nhưng lại thiếu chiều sâu và tư duy đối đầu cần thiết để khám phá các lỗi logic phức tạp và các lỗ hổng chuỗi. Phạm vi kiểm toán có lẽ tập trung vào các danh mục OWASP Top 10 một cách riêng lẻ, bỏ qua sự tương tác phức tạp giữa các thành phần.

Thứ hai, bản thân lỗ hổng deserialization là một rủi ro được ghi nhận rõ ràng (OWASP Top 10 A8:2017, A08:2021). Sự dai dẳng của nó cho thấy hoặc thiếu kiểm tra bảo mật ứng dụng tĩnh (SAST) và kiểm tra bảo mật ứng dụng động (DAST) toàn diện được điều chỉnh đặc biệt cho deserialization, hoặc thất bại trong việc khắc phục đúng cách các phát hiện từ các công cụ đó. Thông thường, các công cụ này tạo ra một lượng lớn cảnh báo, dẫn đến tình trạng mệt mỏi do cảnh báo và ưu tiên sai.

Thứ ba, tổ chức có thể đã quá tin tưởng vào các nguyên tắc bảo mật theo thiết kế mà không có xác thực mạnh mẽ. Mặc dù thiết kế cho bảo mật là tối quan trọng, nhưng nó đòi hỏi phải kiểm tra liên tục, tích cực để xác nhận hiệu quả của nó. RCE cho thấy một lỗ hổng trong các quy trình vòng đời phát triển an toàn (SDLC) của họ, đặc biệt là trong các giai đoạn thử nghiệm sau này và giám sát sau triển khai.

Cuối cùng, việc thiếu các hoạt động bảo mật tấn công liên tục, dựa trên mối đe dọa có nghĩa là tổ chức không chủ động kiểm tra các biện pháp phòng thủ của mình chống lại các TTPs đang phát triển của những kẻ tấn công tinh vi. Điều này tạo ra một cảm giác an toàn giả tạo, được xây dựng dựa trên sự vắng mặt của các lỗ hổng được báo cáo chứ không phải khả năng phục hồi đã được chứng minh chống lại các đối thủ kiên quyết.

Danh sách kiểm tra phòng thủ thực tế

Để ngăn chặn các sự cố tương tự, các CISO và kỹ sư bảo mật nên thực hiện một chiến lược phòng thủ đa diện vượt ra ngoài việc tuân thủ.

• Áp dụng Phòng thủ dựa trên mối đe dọa: Điều chỉnh các chiến lược phòng thủ và phương pháp thử nghiệm với các TTPs của kẻ tấn công trong thế giới thực, tận dụng các khuôn khổ như MITRE ATT&CK để ưu tiên các kiểm soát và mô phỏng các cuộc tấn công.
• Nâng cao kiểm tra bảo mật ứng dụng: Triển khai các giải pháp SAST và DAST mạnh mẽ, đặc biệt cấu hình chúng để phát hiện các lỗ hổng phức tạp như lỗi deserialization, tấn công tiêm nhiễm và lỗi logic. Tích hợp các công cụ này sớm vào đường ống CI/CD.
• Thực hiện xác thực đầu vào và mã hóa đầu ra: Thực thi xác thực đầu vào nghiêm ngặt tại tất cả các ranh giới tin cậy và mã hóa đúng cách tất cả đầu ra để ngăn chặn các cuộc tấn công tiêm nhiễm và lỗ hổng deserialization trên tất cả các API và giao diện người dùng.
• Nguyên tắc đặc quyền tối thiểu & Zero Trust: Áp dụng đặc quyền tối thiểu cho tất cả các tài khoản dịch vụ và quyền truy cập API. Xây dựng kiến trúc hệ thống với các nguyên tắc Zero Trust, liên tục xác minh danh tính và ủy quyền cho mọi nỗ lực truy cập, ngay cả trong phạm vi nội bộ.
• Giám sát bảo mật liên tục & Phản ứng sự cố: Triển khai các giải pháp EDR/XDR tiên tiến, SIEM mạnh mẽ và chủ động săn lùng các mối đe dọa. Phát triển và thường xuyên kiểm tra các kịch bản phản ứng sự cố cụ thể cho RCE và các kịch bản vi phạm dữ liệu nghiêm trọng.
• Red Teaming đối đầu, thường xuyên: Thực hiện các bài tập red team thường xuyên, không báo trước mô phỏng các kịch bản tấn công trong thế giới thực, bao gồm xâu chuỗi các lỗ hổng và khai thác các yếu tố con người. Các hoạt động này phải theo định hướng mục tiêu, không chỉ dựa trên danh sách kiểm tra.
• Kiểm tra an ninh chuỗi cung ứng: Kiểm tra nghiêm ngặt tất cả các thư viện, khuôn khổ và sự phụ thuộc SaaS của bên thứ ba. Thực hiện phân tích thành phần phần mềm (SCA) để xác định các lỗ hổng đã biết trong các thành phần mã nguồn mở và giám sát các tiết lộ mới.

Cách kiểm tra tấn công hiện đại sẽ phát hiện ra điều này

Các hoạt động bảo mật tấn công hiện đại, đặc biệt là những hoạt động áp dụng mô hình cạnh tranh, cộng đồng, được thiết kế để khám phá chính xác những loại lỗ hổng khó nắm bắt này. Không giống như các cuộc kiểm tra thâm nhập truyền thống, các hoạt động này khuyến khích một nhóm các nhà nghiên cứu chuyên gia đa dạng suy nghĩ như những kẻ tấn công thực sự, không bị ràng buộc bởi các phương pháp kiểm toán thông thường.

Bản chất cạnh tranh thúc đẩy các nhà nghiên cứu khám phá các đường tấn công độc đáo, xâu chuỗi nhiều phát hiện mức độ nghiêm trọng thấp thành các khai thác nghiêm trọng và khám phá các lỗi logic mà các công cụ tự động thường bỏ lỡ. Cách tiếp cận này phản ánh sự khéo léo và kiên trì của các đối thủ tinh vi, cung cấp một đánh giá chính xác hơn về tư thế bảo mật thực sự của một tổ chức. Đó là về việc tìm ra các chuỗi thực tế mà kẻ tấn công sẽ sử dụng, chứ không chỉ là kiểm tra các hộp.

Những điều cần theo dõi tiếp theo

Xu hướng các lỗ hổng nghiêm trọng được phát hiện bởi các nhà nghiên cứu độc lập hoặc trong các chương trình tìm lỗi nhận thưởng sẽ chỉ tăng tốc. Khi độ phức tạp của phần mềm tăng lên và bề mặt tấn công mở rộng, các tổ chức phải phát triển các chiến lược phòng thủ của mình từ tuân thủ phản ứng sang phòng thủ chủ động, dựa trên mối đe dọa.

Mong đợi sẽ thấy sự nhấn mạnh hơn vào các kỹ thuật fuzzing nâng cao, phát hiện lỗ hổng có sự hỗ trợ của AI và áp dụng rộng rãi hơn các mô hình bảo mật cộng đồng. Trọng tâm sẽ chuyển từ việc chỉ xác định các lỗ hổng riêng lẻ sang hiểu và phá vỡ toàn bộ chuỗi tiêu diệt tấn công. Các CISO phải ủng hộ một văn hóa kiểm tra đối đầu liên tục, nhận ra rằng RCE nghiêm trọng tiếp theo có lẽ đã ẩn nấp, chờ đợi một kẻ tấn công quyết tâm tìm ra nó.