Đám mây đã thay đổi đáng kể cách chúng ta tiếp cận lưu trữ dữ liệu, thiết kế, triển khai và quản lý ứng dụng web. Với các dịch vụ từ các nền tảng như AWS, Azure và Google Cloud, cả doanh nghiệp và nhà phát triển cá nhân đều có thể hưởng lợi từ khả năng thích ứng và quy mô của đám mây để nâng cao các giải pháp kỹ thuật số của họ.

Tuy nhiên, bên cạnh những lợi ích, đám mây giới thiệu những thách thức bảo mật độc đáo. Các ứng dụng web, API và hơn thế nữa, đặc biệt là những ứng dụng được lưu trữ trong môi trường đám mây, liên tục có nguy cơ bị tổn thương, từ cấu hình sai trong cài đặt đám mây đến các lỗ hổng cấp ứng dụng nội tại hơn. Trong bối cảnh này, tôi bắt đầu xây dựng hai kịch bản để kiểm tra lỗ hổng ứng dụng, nhằm thể hiện tầm quan trọng và hiệu quả của các kỹ thuật phát hiện lỗ hổng trong một thế giới dựa trên đám mây.

Mặc dù chúng tôi muốn giải quyết các lỗ hổng trước khi chúng được triển khai để sản xuất và tiếp xúc với bên ngoài, đôi khi các chiến lược phòng thủ trên các lĩnh vực này có thể thiếu ý nghĩa trong thế giới thực của việc buộc một số chức năng lại với nhau. Đó là nơi thử nghiệm bên ngoài đi vào vị trí.

Trong bài viết này, tôi sẽ thảo luận về cách tôi xây dựng các kịch bản này và cách chúng ta có thể phát hiện các lỗ hổng của chúng.
Để giúp chúng tôi phát hiện các lỗ hổng này, chúng tôi đã sử dụng Nuclei, một công cụ quét mã nguồn mở giúp hợp lý hóa việc xác định các lỗ hổng ứng dụng web thông qua một loạt các mẫu được xác định trước. Chúng tôi cũng sử dụng AI để giúp chúng tôi tạo mẫu nhanh chóng và dễ dàng. Các mẫu này rất quan trọng vì chúng nhắm mục tiêu các lỗ hổng, cấu hình sai và các vấn đề cụ thể mà chúng tôi đang tìm kiếm.

Các kịch bản sau đây có nghĩa là dễ bị tổn thương và bị phơi bày công khai, để giới thiệu cách kẻ tấn công bên ngoài sẽ cố gắng phát hiện và khai thác chúng – mà không có kiến thức trước về tổ chức.

Xây dựng các kịch bản dễ bị tổn thương

Đối với việc khám phá an ninh của chúng tôi, tôi tập trung vào hai kịch bản riêng biệt, nhưng không kém phần hướng dẫn. Tôi đã thiết lập hai máy chủ dễ bị tấn công, một trong số chúng có lỗ hổng giả mạo yêu cầu phía máy chủ (SSRF) do xác thực và vệ sinh các giá trị tiêu đề không đúng cách có thể khó phát hiện và máy chủ còn lại có lỗ hổng đã biết có thể được phát hiện nội bộ dựa trên phiên bản gói.

Tình huống 1: Lỗ hổng ứng dụng web

1. Thiết lập: Ứng dụng được lưu trữ trên Azure Blob Storage. Nó gửi các yêu cầu API RESTful đến backend thông qua Application Gateway của Azure.
2. Khám phá lỗ hổng: Thông qua các API RESTful được tích hợp vào trang web, tôi đã mô phỏng một lỗ hổng SSRF. Điều này cho phép chứng minh khả năng gửi yêu cầu trái phép đến phần phụ trợ, khai thác dịch vụ siêu dữ liệu của phiên bản.

Tình huống 2: Lỗ hổng máy chủ CI/CD

1. Thiết lập: Tôi đã cấu hình một máy chủ CI/CD TeamCity, dự định sao chép một môi trường tích hợp liên tục trong thế giới thực.
2. Trọng tâm lỗ hổng: Mục tiêu chính là mô phỏng lỗ hổng Authentication Bypass mới được phát hiện trong TeamCity – CVE-2024-27198.

Các kịch bản này được thiết kế để phản ánh các lỗ hổng trong thế giới thực, làm nổi bật tiềm năng của chúng để dễ dàng phát hiện và khai thác trong môi trường không đủ bảo mật. Cách tiếp cận này nhấn mạnh nhu cầu quan trọng đối với các hoạt động bảo mật thận trọng và các biện pháp bảo vệ mạnh mẽ.

Tự động phát hiện lỗ hổng bảo mật bằng mẫu Nuclei

Nuclei sử dụng các mẫu, về cơ bản là các yêu cầu HTTP được xác định trước được tạo ra để xác định các vấn đề bảo mật cụ thể hoặc cấu hình sai trong các ứng dụng web và API. Các mẫu này chứa hướng dẫn chi tiết về những yêu cầu gửi và cách diễn giải các phản hồi để phát hiện các lỗ hổng như SSRF, XSS, CVE và hơn thế nữa. Bằng cách chạy một cách có hệ thống các mẫu này đối với các điểm cuối mục tiêu, nó tự động hóa quá trình đánh giá bảo mật, cho phép dễ dàng xác định các điểm yếu tiềm ẩn trong tài sản.

Cũng cần lưu ý rằng vì Nuclei là một công cụ mã nguồn mở, nó có thể được sử dụng bởi các chuyên gia bảo mật cũng như những kẻ tấn công để tìm ra các lỗ hổng có thể khai thác. Vì lý do này, điều quan trọng là có thể phát hiện và bảo vệ chống lại các loại lỗ hổng và vấn đề bảo mật này bằng cách sử dụng quét bên ngoài.

1. Sử dụng AI để tạo mẫu: Các công cụ AI đẩy nhanh việc phát hiện lỗ hổng và giúp tạo các mẫu phát hiện nhanh hơn và dễ dàng hơn bằng cách xử lý các yêu cầu nhất định, do đó giảm nỗ lực thủ công và nâng cao độ chính xác của việc phát hiện các vấn đề như SSRF. Ảnh chụp màn hình sau đây từ trang web Nuclei cung cấp minh họa rõ ràng về cách chúng tôi nhập văn bản để xây dựng mẫu YAML, hợp lý hóa quy trình phát hiện lỗ hổng.

   

2. Tạo mẫu tùy chỉnh: Các mẫu tùy chỉnh, được tạo bởi các chuyên gia bảo mật, sử dụng các mẫu được xác định trước để xác định và bảo vệ chống lại các lỗ hổng đã biết bằng cách tìm kiếm các chữ ký hoặc chỉ báo thỏa hiệp cụ thể. Kho lưu trữ projectdiscovery, trong số những kho lưu trữ khác, lưu trữ một loạt các mẫu này, cung cấp một loạt các tùy chọn được xây dựng sẵn đa dạng nhằm giải quyết nhiều nhu cầu và lỗ hổng bảo mật.

Tình huống 1: Lỗ hổng SSRF trên ứng dụng web được lưu trữ trên Azure

SSRF (Server-Side Request Forgery) là một lỗ hổng cho phép kẻ tấn công thực hiện các yêu cầu đến tài nguyên nội bộ, thường bỏ qua tường lửa, bằng cách lừa máy chủ thực hiện các yêu cầu đó thay mặt chúng.

Kiến trúc và quy trình làm việc

Trang web này được thiết lập dưới dạng trang web tĩnh được lưu trữ trong bộ chứa lưu trữ Azure. Trang web này giới thiệu trang web của một công ty hư cấu và được thiết kế để gửi các yêu cầu API thông qua Cổng ứng dụng của Azure, thực hiện phân tích khách hàng và chuyển tiếp lưu lượng truy cập đến các hệ thống phụ trợ để xử lý. Ở đây, tiêu đề X-Forwarded-Host trong các yêu cầu API trình bày một mối quan tâm bảo mật tiềm ẩn, bởi vì nó có thể bị khai thác nếu không được xác thực và quản lý đúng cách.

Tiêu đề X-Forwarded-Host thường được sử dụng trong các ứng dụng web như một phương pháp để xác định máy chủ gốc được yêu cầu bởi máy khách trong tiêu đề yêu cầu HTTP của máy chủ. Khi lưu lượng truy cập được định tuyến qua proxy hoặc cân bằng tải, như Cổng ứng dụng của Azure, tiêu đề này sẽ tự động được thêm vào yêu cầu HTTP mà người dùng thậm chí không nhận ra. Để hiểu chi tiết hơn, bài viết này cung cấp cái nhìn toàn diện về cách hoạt động của Cổng kết nối ứng dụng Azure.

Trong ngữ cảnh của chúng tôi, khi một khách hàng khởi tạo một yêu cầu đến trang web của chúng tôi, Application Gateway sẽ nhận được nó và chuyển tiếp yêu cầu đến máy chủ phụ trợ.

Khai thác lỗ hổng SSRF tiềm ẩn

Nếu không được xác thực và quản lý đúng cách, kịch bản của chúng tôi có thể cho phép kẻ tấn công thực hiện các hành động sau:

• Vượt qua tường lửa: Vì các yêu cầu độc hại đến từ máy chủ đáng tin cậy, chúng có thể vượt qua các hạn chế tường lửa, cung cấp đường dẫn để truy cập hoặc khai thác hệ thống nội bộ.
• Thao tác tiêu đề: Những kẻ tấn công có thể giả mạo tiêu đề X-Forwarded-Host được thêm tự động (và các tiêu đề không nhìn thấy được thêm tự động khác), sử dụng nó để hướng dẫn các yêu cầu phụ trợ đến các đích ngoài ý muốn.
• Tương tác với tài nguyên nội bộ và dịch vụ đám mây: Khai thác SSRF, kẻ tấn công có thể định tuyến lại các yêu cầu đến tài nguyên nội bộ hoặc tương tác với các dịch vụ đám mây, có khả năng truy cập dữ liệu nhạy cảm, thao túng tài nguyên hoặc truy xuất siêu dữ liệu đám mây trong mạng Azure.

Luồng tấn công khai thác SSRF

Hành vi mặc định trong đó tiêu đề tự động được thiết kế để duy trì tính nhất quán điều hướng bằng cách bảo toàn dữ liệu quan trọng thông qua tiêu đề X-Forwarded-Host, có thể vô tình tạo ra một tuyến đường có khả năng khai thác nếu không được cấu hình an toàn. Điều này sau đó có thể đóng vai trò là vectơ tấn công tiềm năng cho các lỗ hổng SSRF, cho phép kẻ tấn công yêu cầu máy chủ phụ trợ đưa ra yêu cầu cho chúng, có thể truy cập siêu dữ liệu đám mây, hệ thống nội bộ hoặc nền tảng độc hại bên ngoài, gây rủi ro bảo mật đáng kể.

Phơi bày dữ liệu nhạy cảm: Khám phá thực tế

Trong khám phá cụ thể này về lỗ hổng SSRF trong trang web được lưu trữ trên Azure, tôi tập trung vào việc khai thác tiêu đề X-Forwarded-Host, nhận ra một kịch bản rủi ro khi các máy chủ phụ trợ tin tưởng tiêu đề được thêm tự động này. Tôi đã thay đổi tiêu đề X-Forwarded-Host để nhắm mục tiêu điểm cuối API siêu dữ liệu phiên bản Azure đã biết: , do đó có quyền truy cập vào siêu dữ liệu phiên bản nhạy cảm. **<http://169.254.169.254/metadata/instance?api-version=2021-02-01**>

Phương pháp này có khả năng cho phép kẻ tấn công truy xuất dữ liệu quan trọng, chẳng hạn như dữ liệu tùy chỉnh máy ảo hoặc mã thông báo dịch vụ, sau đó có thể được sử dụng để truy cập trái phép hoặc thao túng các dịch vụ và tài nguyên Azure, dẫn đến nhiều sự cố bảo mật, bao gồm vi phạm dữ liệu hoặc truy cập và sửa đổi dữ liệu trái phép.

Vi phạm thực tế này nhấn mạnh nhu cầu thiết yếu để thực thi các biện pháp bảo mật mạnh mẽ và kiểm tra thường xuyên các điểm cuối API. Điều này bao gồm xác thực kỹ lưỡng và vệ sinh đầu vào và tiêu đề của người dùng trong giao tiếp API, đặc biệt là khi tương tác với môi trường đám mây chứa dữ liệu nhạy cảm và quan trọng.

Phát hiện lỗ hổng SSRF bằng mẫu

Để khai thác lỗ hổng này bằng một mẫu, chúng ta sẽ cần những thứ sau:

• Khai thác các tiêu đề đã biết: Tạo một mẫu gửi yêu cầu một cách có hệ thống với các tiêu đề đã thay đổi, đặc biệt kết hợp danh sách các tiêu đề thường được khai thác như X-Forwarded-Host và các tiêu đề khác, cố gắng truy xuất thông tin từ các đường dẫn trái phép hoặc gây ra hành vi không mong muốn.

Phương pháp này, sử dụng một mẫu bao gồm một loạt các tiêu đề được biết đến với khả năng khai thác của chúng, nhằm mục đích chủ động phát hiện và sau đó bảo vệ chống lại các lỗ hổng SSRF tiềm ẩn, do đó nâng cao vị thế an ninh mạng của trang web được lưu trữ trong Azure.

Mẫu đơn giản sau đây được tạo bằng nền tảng Nuclei AI bằng cách viết một lời nhắc cụ thể để thao tác với tiêu đề “X-Forwarded-Host” và “X-Forwarded-For” và cố gắng truy cập dịch vụ siêu dữ liệu phiên bản Azure:

id: ssrf-azure-metadata

info:
  name: SSRF Vulnerability Detection in Azure Instance Metadata
  author: pdteam
  severity: high

http:
  - method: GET
    path:
      - "{{BaseURL}}"

    headers:
      X-Forwarded-For: "http://169.254.169.254/metadata/instance?api-version=2021-02-01"
      Metadata: true
    matchers:
      - type: word
        part: body
        words:
          - compute
          - azEnvironment
          - resourceGroupName
        condition: or

  - method: GET
    path:
      - "{{BaseURL}}"

    headers:
      X-Forwarded-Host: "http://169.254.169.254/metadata/instance?api-version=2021-02-01"
      Metadata: true
    matchers:
      - type: word
        part: body
        words:
          - compute
          - azEnvironment
          - resourceGroupName
        condition: or

Tình huống 2: Lỗ hổng TeamCity Authentication Bypass

Kiến trúc và quy trình làm việc

Kịch bản này liên quan đến một máy chủ CI/CD TeamCity dễ bị tấn công, cụ thể là phiên bản trước 2023.11.4, được thiết lập trên phiên bản EC2 trong AWS để mô phỏng môi trường phát triển phần mềm trong thế giới thực. TeamCity, theo mặc định, hiển thị máy chủ web của mình qua HTTP trên cổng 8111. Trong thiết lập này, máy chủ được cấu hình để xử lý các cam kết mã, tự động hóa các bản dựng và quản lý triển khai. Tuy nhiên, quy trình được sắp xếp hợp lý này có thể trở thành trách nhiệm pháp lý nếu có lỗ hổng Authentication Bypass, vì nó có thể cho phép truy cập trái phép vào quy trình phát triển quan trọng.

Xác thực bỏ qua khai thác lỗ hổng bảo mật

Luồng tấn công của lỗ hổng này như sau:

• Tạo URL độc hại: Những kẻ tấn công có thể gửi một yêu cầu thủ công cho một tài nguyên không tồn tại (ví dụ: /hax), với một tham số truy vấn có tên jsp nhắm mục tiêu đến một điểm cuối được xác thực (ví dụ: ?jsp=/app/rest/server) và đảm bảo yêu cầu kết thúc bằng .jsp (ví dụ: ;. JSP). Điều này thao tác máy chủ xử lý các yêu cầu như thể chúng được xác thực.
• Đạt được quyền truy cập trái phép và sự tồn tại: Bằng cách bỏ qua cơ chế đăng nhập của máy chủ TeamCity, kẻ tấn công có thể truy cập trực tiếp vào các tính năng quản trị và tạo người dùng mới để truy cập trái phép liên tục.
• Toàn quyền kiểm soát nội lực: Một kẻ tấn công từ xa, chưa được xác thực khai thác lỗ hổng này có khả năng chiếm quyền kiểm soát máy chủ TeamCity, dẫn đến những tác động nghiêm trọng, bao gồm giả mạo cơ sở mã hoặc gián đoạn đường ống.

Phơi bày dữ liệu nhạy cảm: Khám phá thực tế

Để chứng minh việc khai thác lỗ hổng TeamCity Authentication Bypass, chìa khóa là gửi một yêu cầu HTTP crafted đến máy chủ TeamCity. Yêu cầu nhắm vào một tài nguyên không tồn tại, gây ra lỗi 404, nhưng chính thao tác tiếp theo đã khai thác lỗ hổng. Bằng cách thêm một tham số truy vấn đặc biệt ?jsp=/app/rest/users.jsp vào yêu cầu, nó thao tác phản hồi của máy chủ để coi yêu cầu của tôi là được xác thực.

Tôi đã gửi yêu cầu tạo người dùng quản trị mới trên máy chủ TeamCity:

Yêu cầu POST này khai thác lỗ hổng để tương tác với điểm cuối /app/rest/users mà không cần xác thực, tạo ra một người dùng có tên “hacker” với đặc quyền quản trị viên hệ thống.

Thực hiện thành công các bước này không chỉ cho phép chúng tôi tạo quản trị viên mới mà còn chứng minh những tác động nghiêm trọng của lỗ hổng. Nó cung cấp cho chúng tôi một cổng trái phép để thao túng đường ống CI / CD, truy cập dữ liệu nhạy cảm và có khả năng đưa mã độc hại.

Điều này nhấn mạnh tầm quan trọng của sự cảnh giác trong việc bảo mật môi trường CI / CD. Sự cần thiết phải xác thực nghiêm ngặt tất cả các đầu vào và URL của người dùng, đảm bảo rằng các cơ chế xác thực không thể bị bỏ qua và các máy chủ được cập nhật các bản vá bảo mật mới nhất để ngăn chặn việc khai thác.

Xác thực TeamCity Bỏ qua phát hiện lỗ hổng bảo mật bằng cách sử dụng mẫu

Để khai thác lỗ hổng này bằng một mẫu, chúng ta sẽ cần những thứ sau:

• Khai thác các phiên bản đã biết: Tạo một mẫu nhắm mục tiêu điểm cuối đăng nhập TeamCity để phát hiện lỗ hổng bằng cách kiểm tra thông tin phiên bản cụ thể. Mẫu này sẽ tạo các yêu cầu truy cập trang đăng nhập của máy chủ TeamCity, sau đó phân tích phản hồi cho các chi tiết phiên bản cho biết trạng thái chưa được vá, dễ bị tấn công.
• Gửi yêu cầu crafted: Tạo một mẫu để thăm dò truy cập điểm cuối trái phép trên máy chủ TeamCity bằng cách sử dụng kỹ thuật URL crafted đã nêu trước đó. Mẫu này sẽ gửi các yêu cầu nhằm tiếp cận các khu vực được bảo vệ của máy chủ TeamCity bằng cách sử dụng URL được tạo riêng để bỏ qua các cơ chế xác thực. Sự thành công của việc khai thác này được xác định bằng cách phân tích phản hồi của máy chủ đối với các yêu cầu này (ví dụ: xác minh mã trạng thái 200).

Mẫu sau đây được phát triển bằng Nuclei AI, được thiết kế riêng để xác định các trường hợp lỗ hổng TeamCity Authentication Bypass bằng cách kiểm tra phản hồi của máy chủ để biết thông tin phiên bản cho thấy trạng thái chưa được vá. Việc sử dụng Nuclei AI này thể hiện sức mạnh của nó trong việc tạo ra các mẫu tập trung để xác định và giải quyết hiệu quả các lỗ hổng bảo mật.

id: CVE-2024-27198
info:
  name: TeamCity Authentication Bypass Vulnerability
  author: pdteam
  severity: high

http:
  - method: GET
    path:
      - "{{BaseURL}}/login.html"

    matchers:
      - type: regex
        part: body
        regex:
          - '<span class="greyNote version"><span class="vWord">Version</span> (20[0-2][0-3]\.(0[1-9]|10|11\.[1-3])|(200[0-9]|201[0-9]|202[0-2]).*).*<\/span>'
        condition: and

Phát hiện và kết luận

Thông qua việc đi sâu vào hai kịch bản lỗ hổng cụ thể – chúng tôi biết rằng việc kiểm tra các ứng dụng web và API là rất quan trọng để bảo vệ tổ chức. Cách tiếp cận truyền thống liên quan đến việc xác định các lỗ hổng trước khi triển khai vào sản xuất, khi chúng chỉ đơn thuần là mã. Tuy nhiên, sự hiện diện của các ứng dụng đối mặt với internet cũng đòi hỏi phải kiểm tra chúng thông qua quan điểm của kẻ tấn công.

Cách tiếp cận này rất cần thiết bởi vì, như đã chứng minh, các lỗ hổng như vậy có thể gây ra hậu quả tàn phá cho một tổ chức. Bằng cách sử dụng cả phương pháp do AI điều khiển và tạo mẫu thủ công để phát hiện hiệu quả và dễ dàng, chúng tôi đã cho thấy tầm quan trọng của việc bảo mật và kiểm tra nghiêm ngặt các yêu cầu HTTP và điểm cuối API:

• Khai thác thực tế: Các thao tác thực hành của chúng tôi đối với các yêu cầu HTTP đã tiết lộ các con đường dẫn đến siêu dữ liệu nội bộ và đám mây, làm nổi bật các rủi ro SSRF và khai thác lỗ hổng đã biết trong các môi trường đám mây khác nhau.
• Khai thác các mẫu để phát hiện: Việc triển khai cả các mẫu Nuclei được tăng cường AI và tạo thủ công cho phép xác định chính xác các lỗ hổng, cho thấy hiệu quả của việc thăm dò điểm cuối có phương pháp trong việc phát hiện các lỗ hổng bảo mật trên các môi trường khác nhau.
• Tích hợp phòng thủ tự động trong Orca: Nền tảng Orca hiện kết hợp quét và cảnh báo tự động, đảm bảo rằng cả các mẫu được hỗ trợ bởi AI và được tạo thủ công không chỉ bảo vệ chống lại các lỗ hổng được công nhận mà còn củng cố khả năng phòng thủ của chúng tôi chống lại các mối đe dọa mới nổi bằng cách liên tục phân tích và thích ứng với các mô hình tấn công mới. Cách tiếp cận kép này tích hợp độ chính xác của chuyên môn thủ công với bản chất thích ứng, có thể mở rộng của AI, củng cố vị thế bảo mật của chúng tôi chống lại một loạt các lỗ hổng và vấn đề bảo mật khác nhau.

Khám phá này nhấn mạnh rằng việc bảo mật cơ sở hạ tầng kỹ thuật số, từ các ứng dụng web đến đường ống CI / CD, là rất quan trọng. Nắm bắt các công cụ phát hiện lỗ hổng tự động, được hỗ trợ bởi AI và được bổ sung bởi đầu vào của chuyên gia, là điều cần thiết để duy trì tính toàn vẹn và bảo mật trong thời đại kỹ thuật số ngày nay.

Nền tảng bảo mật đám mây Orca có thể trợ giúp như thế nào

Orca Security khai thác sức mạnh của các mẫu Nuclei để thực hiện quét rộng rãi các mạng tổ chức, tập trung vào việc tiếp xúc với bên ngoài. Cách tiếp cận này phát hiện ra các lỗ hổng trong các hệ thống sản xuất, trong các đường ống CI/CD như TeamCity, ứng dụng web và điểm cuối API.

Bằng cách tạo ra một kho tài sản đám mây toàn diện, Orca cung cấp khả năng hiển thị rõ ràng về các phiên bản phần mềm được triển khai, tiếp xúc với mạng của chúng và các lỗ hổng bảo mật liên quan. Cái nhìn sâu sắc chi tiết này cho phép xác định cả các lỗ hổng phổ biến và tối nghĩa, đảm bảo một cơ chế phòng thủ mạnh mẽ được áp dụng.

Trong cảnh báo này, Orca hiển thị lỗ hổng TeamCity được phát hiện bên ngoài bằng cách sử dụng mẫu Nuclei

Quá trình quét được sử dụng bởi Orca được thiết kế để không chỉ phát hiện ra các lỗ hổng mà còn để đánh giá mức độ rủi ro của mỗi phát hiện. Bằng cách phân tích các yếu tố như tiếp xúc với mạng, sử dụng danh tính đặc quyền và quyền truy cập vào dữ liệu nhạy cảm, Orca ưu tiên các lỗ hổng dựa trên tác động tiềm năng của chúng.

Sự ưu tiên này cho phép phân bổ hiệu quả các nguồn lực để giảm thiểu những rủi ro quan trọng nhất trước tiên, đặc biệt là những rủi ro đang được khai thác tích cực. Thông qua việc sử dụng chiến lược các mẫu Nuclei và quét toàn diện, Orca trao quyền cho các tổ chức chủ động bảo vệ môi trường của họ trước các mối đe dọa mới nổi.
Nếu bạn muốn tìm hiểu thêm về Nền tảng Orca, hãy lên lịch trình diễn 1: 1 với một trong những chuyên gia của chúng tôi để xem cách chúng tôi có thể giúp bạn nâng cấp bảo mật đám mây của mình.

Theo: Using Nuclei Templates for Vulnerability Scanning | Orca Security