5. Viết báo cáo cho người kiểm tra thâm nhập

Chúng ta sẽ đề cập đến các Đơn vị học tập sau trong Mô-đun này:

• Hiểu về việc ghi chép
• Viết báo cáo kiểm tra thâm nhập kỹ thuật hiệu quả

Mô-đun này được thiết kế để giúp Người kiểm tra xâm nhập hiểu cách cung cấp báo cáo hiệu quả cho khách hàng của họ.

Lưu ý : Để theo học PreOSCP các bạn cần hoàn thành khóa học Hacking Với Kali Linux Căn Bản tại https://elearning.security365.vn/ehacking-voi-kali-linux , sau đó đăng kí thi OSCP tại IPMAC. Các bạn sẽ được cung cấp khóa học chính thức và môi trường lab cùng Exam Voucher với khả năng đạt cao nhất.

5.1. Hiểu về việc ghi chép

Trong Đơn vị học tập này, chúng ta sẽ đề cập đến các Mục tiêu sau:

• Xem xét các mục tiêu giao cho các cam kết thử nghiệm thâm nhập
• Hiểu được tầm quan trọng của tính di động của ghi chú
• Xác định cấu trúc chung của tài liệu kiểm thử thâm nhập
• Chọn công cụ ghi chú phù hợp
• Hiểu được tầm quan trọng của việc chụp ảnh màn hình
• Sử dụng công cụ để chụp ảnh màn hình

5.1.1. Các sản phẩm thử nghiệm thâm nhập

Bài kiểm tra thâm nhập hoặc bài tập nhóm đỏ rất khó để lập kịch bản trước. Điều này là do người kiểm tra không thể dự đoán chính xác loại máy hoặc mạng nào mà khách hàng muốn được kiểm tra.

Mặc dù kết quả đánh giá của chúng tôi thường không thể đoán trước, nhưng chúng tôi thường khuyến nghị nên xác định phạm vi chi tiết trong các cuộc họp sơ bộ với khách hàng. Quy trình này đặc biệt hữu ích khi ưu tiên các mục tiêu quan trọng của doanh nghiệp trong các mạng lớn.

Trong khi kế hoạch thực hiện chung cho một bài kiểm tra thâm nhập thường sẽ tuân theo một mô hình cụ thể, thì hầu hết các bài kiểm tra thâm nhập có xu hướng tuân theo câu châm ngôn "không có kế hoạch nào tồn tại sau lần tiếp xúc đầu tiên với kẻ thù"  . Điều này có nghĩa là bất kỳ hoạt động cụ thể nào mà chúng ta có thể mong đợi thực hiện trong quá trình giao tranh có thể không thực sự xảy ra, vì thực tế của môi trường thử nghiệm gần như chắc chắn khác với những ý tưởng và giả thuyết ban đầu của chúng ta về nó. Do đó, rất khó để báo cáo về các bài kiểm tra thâm nhập bằng các biểu mẫu được điền sẵn. Điều này đặc biệt đúng khi quá trình thử nghiệm được thực hiện mà không có nhiều thảo luận trước với khách hàng, ví dụ, nếu khách hàng muốn gây bất ngờ cho các đội phòng thủ của họ theo một cách nào đó.

Do đó, thay vì chuẩn bị báo cáo trước, thử nghiệm thâm nhập được thực hiện và ghi chú được thực hiện trong quá trình tiến hành để đảm bảo có hồ sơ chi tiết về những gì đã thực hiện. Điều này đảm bảo rằng:

• thử nghiệm thâm nhập có thể được lặp lại nếu cần thiết để chứng minh rằng vấn đề là có thật.
• có thể lặp lại thử nghiệm thâm nhập sau khi khắc phục để xác nhận rằng sự cố đã được khắc phục.
• nếu có lỗi hệ thống trong thời gian thử nghiệm thâm nhập, khách hàng và người thử nghiệm có thể xác định xem thử nghiệm có phải là nguyên nhân gây ra lỗi hay không.

Trong quá trình kiểm tra thâm nhập, một số hoạt động có thể không được phép. Chúng ta phải rất rõ ràng về Quy tắc giao chiến (RoE) mà theo đó việc kiểm tra được thực hiện. Khi tiến hành kiểm tra nhóm đỏ, một người thường được giao vai trò "trọng tài" để đảm bảo rằng các quy tắc giao chiến được tuân thủ. Có thể có những hạn chế được áp dụng đối với việc kiểm tra như không thực hiện các cuộc tấn công từ chối dịch vụ hoặc không tham gia vào kỹ thuật xã hội. Hơn nữa, công việc kiểm tra có thể là để đáp ứng các yêu cầu tuân thủ quy định của khách hàng và có thể cần tuân theo một phương pháp cụ thể như Tiêu chuẩn thực hiện kiểm tra thâm nhập OWASP . Bất kỳ hạn chế nào như vậy đều cần phải rất rõ ràng ngay từ đầu.

5.1.2. Lưu ý tính di động

Tính di động của ghi chú kiểm tra thâm nhập có nghĩa là có thể chuyển những ghi chú đó cho người khác. Viết ghi chú ngắn gọn và mạch lạc là một phần không thể thiếu của việc ghi chú thành công và cho phép ghi chú được sử dụng không chỉ bởi chính chúng ta mà còn bởi những người khác. Ngoài ra, ghi chú ngắn gọn có thể nhanh chóng được điều chỉnh để báo cáo kỹ thuật.

Nhu cầu về tính di động đặc biệt được nhấn mạnh khi một người kiểm tra thâm nhập phải rời khỏi một nhiệm vụ vì bệnh tật, ốm đau hoặc các vấn đề khác. Việc có sự hiểu biết chung về cách ghi chép là đặc biệt quan trọng đối với các nhóm kiểm tra thâm nhập lớn, nơi các cá nhân cần có khả năng hiểu chi tiết về các nhiệm vụ của các thành viên khác trong nhóm theo ý muốn.

5.1.3. Cấu trúc chung của Ghi chú kiểm tra thâm nhập

Chúng ta cần áp dụng cách tiếp cận có cấu trúc để ghi chép vừa ngắn gọn vừa chính xác. Có vô số cách để chúng ta có thể sắp xếp ghi chép của mình và sẽ vô ích nếu cố gắng đưa ra một bộ khuyến nghị phù hợp với tất cả mọi người. Tuy nhiên, sau đây là một số nguyên tắc thường hữu ích để xem xét:

• Thay vì ghi chép chung chung với suy nghĩ rằng chúng ta sẽ nhớ cách thực hiện một số hành động nhất định vào lần sau, chúng ta nên ghi lại chính xác những gì mình đã làm.
• Điều này có nghĩa là mọi lệnh chúng ta gõ, mọi dòng mã chúng ta sửa đổi và thậm chí mọi nơi chúng ta nhấp vào trong GUI đều phải được ghi lại để chúng ta có thể tái tạo các hành động của mình.
• Ngay cả khi chúng ta đã ghi chép rất nhiều, nếu việc xem lại sau đó không giúp chúng ta nhớ chính xác những gì đã xảy ra trong quá trình đánh giá, thì chúng cũng không thực sự hữu ích với chúng ta.
• Các ghi chú cần phải có cấu trúc và đủ chi tiết để loại bỏ mọi sự mơ hồ.
• Để viết một báo cáo kỹ thuật thuyết phục và có căn cứ sau này, chúng ta cần cung cấp đầy đủ thông tin chi tiết kỹ thuật trong ghi chú của mình.
• Nếu các ghi chú không được viết một cách mạch lạc, người khác sẽ khó có thể làm lại bài kiểm tra và đạt được kết quả tương tự.

Cấu trúc mà chúng tôi đề xuất ở đây để ghi chú đủ trừu tượng để cho phép sở thích cá nhân. Theo nguyên tắc chung, chúng tôi muốn các ghi chú nhắc nhở chúng tôi về những gì đã xảy ra và cho phép chúng tôi sao chép các vấn đề mà chúng tôi xác định. Một cấu trúc ghi chú bắt đầu rộng và đi sâu vào từng phần là một phương pháp ghi chú dễ dàng và có thể mở rộng. Phương pháp tiếp cận từ trên xuống hướng dẫn chúng tôi bắt đầu với hoạt động rộng nhất, sau đó thu hẹp trọng tâm và mở rộng mức độ chi tiết cho đến khi chúng tôi có mọi thứ cần thiết để sao chép chính xác những gì đã xảy ra.

Bây giờ chúng ta hãy xem một ví dụ về các ghi chú mà chúng ta có thể thực hiện đối với lỗ hổng web mà chúng ta phát hiện ra:

• Tên ứng dụng : Điều này rất quan trọng trong bài kiểm tra nhiều ứng dụng và là thói quen tốt cần có. Tên ứng dụng cũng giúp xây dựng cấu trúc thư mục và tệp tự nhiên khá tốt.
• URL : Đây chính xác là URL sẽ được sử dụng để xác định lỗ hổng mà chúng tôi phát hiện.
• Request Type : Điều này biểu thị cả loại yêu cầu (ví dụ: GET, POST, OPTIONS, v.v.) đã được thực hiện, cũng như bất kỳ thay đổi thủ công nào chúng tôi thực hiện đối với yêu cầu đó. Ví dụ, chúng tôi có thể chặn tin nhắn yêu cầu POST và thay đổi tên người dùng hoặc mật khẩu trước khi chuyển tiếp.
• Chi tiết sự cố : Đây là tổng quan về lỗ hổng sẽ được kích hoạt bởi các hành động của chúng tôi. Ví dụ, chúng tôi có thể chỉ ra CVE mô tả lỗ hổng nếu có và/hoặc giải thích tác động mà chúng tôi quan sát được. Chúng tôi có thể phân loại tác động là từ chối dịch vụ, thực thi mã từ xa, leo thang đặc quyền, v.v.
• Tải trọng bằng chứng khái niệm : Đây là một chuỗi hoặc khối mã sẽ kích hoạt lỗ hổng. Đây là phần quan trọng nhất của ghi chú, vì nó sẽ đưa vấn đề về nhà và cho phép nó được sao chép. Nó phải liệt kê tất cả các điều kiện tiên quyết cần thiết và cung cấp mã hoặc lệnh chính xác cần được sử dụng để kích hoạt lỗ hổng một lần nữa.

Chúng ta hãy đi sâu hơn và xem xét ví dụ về việc kiểm tra lỗ hổng Cross-Site Scripting (XSS). Mục tiêu mà chúng tôi đã kiểm tra có một trang web có tên là XSSBlog.html . Khi chúng ta điều hướng đến trang web đó, chúng ta có thể nhập một mục nhập blog.

Khi chúng tôi đọc lại bài viết trên blog, chúng tôi nhận được cảnh báo sau:

Trong quá trình thực hiện những yêu cầu này, chúng tôi sẽ ghi lại các hành động của mình như được hiển thị bên dưới.

Testing for Cross-Site Scripting 

Testing Target: 192.168.1.52 
Application:    XSSBlog
Date Started:   31 March 2022

1.  Navigated to the application
    http://192.168.1.52/XSSBlog.html
    Result: Blog page displayed as expected
    
2.  Entered our standard XSS test data: 
    You will rejoice to hear that no disaster has accompanied the
    commencement of an enterprise which you have regarded with such
    evil forebodings.<script>alert("Your computer is infected!");</script> 
    I arrived here yesterday, and my first task is to assure my dear
    sister of my welfare and increasing confidence in the success of
    my undertaking. 

3.  Clicked Submit to post the blog entry.
    Result: Blog entry appeared to save correctly.

4.  Navigated to read the blog post
    http://192.168.1.52/XSSRead.php
    Result: The blog started to display and then the expected alert popped up.

5.  Test indicated the site is vulnerable to XSS.

PoC payload: <script>alert(‘Your computer is infected!')</script>

Danh sách 1 - Ví dụ về Ghi chú thử nghiệm.

Bây giờ chúng ta có một cách đơn giản, nhanh chóng và có thể mở rộng để ghi chú mạch lạc và toàn diện mà một người kiểm tra khác có thể làm theo. Cần nhắc lại rằng các ghi chú không phải là báo cáo mà chúng ta sẽ gửi cho khách hàng, nhưng chúng sẽ vô cùng hữu ích khi chúng ta cố gắng tổng hợp báo cáo sau này.

5.1.4. Chọn công cụ ghi chú phù hợp

Hiện nay có rất nhiều công cụ ghi chú miễn phí và trả phí. Để quyết định công cụ phù hợp cho một hoạt động cụ thể, điều quan trọng là phải hiểu một số yêu cầu. Trong nhiều trường hợp, chúng ta muốn giữ tất cả thông tin cục bộ trên máy tính thay vì tải thông tin lên bất kỳ nơi nào khác, do đó một số công cụ nhất định bị loại trừ khỏi việc sử dụng. Tương tự như vậy, nếu hoạt động có nhiều mã nguồn thì một công cụ không cho phép chèn khối mã sẽ không phù hợp.

Mặc dù không thể liệt kê hết danh sách đầy đủ các đặc điểm đáng mơ ước cần lưu ý, nhưng một số điều quan trọng cần nhớ là:

• Ảnh chụp màn hình : Nếu cần nhiều ảnh chụp màn hình, hãy cân nhắc sử dụng công cụ cho phép chèn ảnh chụp màn hình trực tuyến.
• Khối mã : Khối mã cần được định dạng để có thể hiểu đúng và nhanh chóng.
• Tính di động : Một thứ gì đó có thể sử dụng trên nhiều hệ điều hành hoặc dễ dàng chuyển sang nơi khác nên được ưu tiên hàng đầu.
• Cấu trúc thư mục : Trong quá trình tương tác với nhiều miền hoặc ứng dụng, việc duy trì cấu trúc mạch lạc là cần thiết. Mặc dù có thể thiết lập cấu trúc thủ công, nhưng một công cụ có thể tự động thực hiện việc này sẽ giúp mọi việc dễ dàng hơn.

Bây giờ chúng ta đã có cơ sở tốt về các yêu cầu, hãy cùng xem xét việc sử dụng một số công cụ ghi chú cụ thể.

Sublime là một trình soạn thảo văn bản khá chuẩn, bổ sung nhiều tính năng và chức năng hữu ích. Một trong những tính năng quan trọng nhất mà nó cung cấp là tô sáng cú pháp linh hoạt. Tô sáng cú pháp cho phép chúng ta đặt các khối mã vào một tệp và các khối mã đó sẽ được tô sáng theo các quy tắc cú pháp cụ thể của ngôn ngữ lập trình. Tuy nhiên, điều này thường đi kèm với những hạn chế. Không thể tô sáng hai ngôn ngữ bằng một tệp. Trong quá trình tương tác với một loại mã duy nhất, đây không phải là vấn đề, nhưng đối với những người khác, chúng ta có thể thích sử dụng các tùy chọn khác nhau. Ngoài ra, hiện tại không thể nhúng ảnh chụp màn hình vào dòng tại thời điểm viết bài.

Một công cụ khác mà chúng ta có thể cân nhắc là CherryTree . Công cụ này có sẵn trong Kali. Nó chứa nhiều tính năng cần thiết cho việc ghi chú. Nó sử dụng cơ sở dữ liệu SQLite để lưu trữ các ghi chú mà chúng ta ghi lại và có thể xuất chúng dưới dạng HTML, PDF, văn bản thuần túy hoặc dưới dạng tài liệu CherryTree. CherryTree có nhiều định dạng tích hợp sẵn và cung cấp cấu trúc cây để lưu trữ tài liệu, được gọi là "node" và "subnode".

Dưới đây là ví dụ về việc sử dụng CherryTree để lưu trữ ghi chú thử nghiệm thâm nhập bằng cấu trúc cây khá đơn giản.

Công cụ cuối cùng chúng ta sẽ xem xét là trình chỉnh sửa markdown Obsidian , chứa tất cả các tính năng mà chúng ta cần để ghi chú. Chúng ta có thể cài đặt Obsidian dưới dạng ứng dụng nap hoặc dưới dạng ứng dụng Flatpak . Nó cũng có dạng AppImage , nghĩa là tất cả những gì chúng ta cần làm là sao chép nó vào hệ thống của mình, đánh dấu là có thể thực thi và chạy nó.

kali@kali:~$ wget https://github.com/obsidianmd/obsidian-releases/releases/download/v0.14.2/Obsidian-0.14.2.AppImage
....
2022-03-31 15:38:53 (1.28 MB/s) - 'Obsidian-0.14.2.AppImage' saved [113102744/113102744]
kali@kali:~$ chmod +x Obsidian-0.14.2.AppImage
kali@kali:~$ ./Obsidian-0.14.2.AppImage

Danh sách 2 - Nhận và chạy Obsidian

Khi thực thi AppImage, chúng ta sẽ nhận được màn hình chào mừng cho phép chúng ta mở kho lưu trữ Obsidian hoặc tạo kho lưu trữ mới.

Obsidian lưu trữ thông tin trong Vault , là một thư mục trên hệ thống của chúng tôi. Chúng tôi có thể tạo cả tệp và thư mục markdown trong Vault. Các tính năng của Obsidian bao gồm bản xem trước trực tiếp văn bản markdown, vị trí hình ảnh trong dòng, khối mã và nhiều tiện ích bổ sung như tiện ích mở rộng CSS do cộng đồng xây dựng.

Một ví dụ về cách nhập trực tiếp ghi chú trong markdown được hiển thị bên dưới:

Sau đó, nó có thể được xem trước trực tiếp bởi Obsidian.

Có thể di chuyển kho lưu trữ Obsidian sang máy tính khác và mở từ menu Welcome. Các tệp Markdown có thể được thả vào thư mục Vault, Obsidian sẽ tự động nhận dạng các tệp này.

Việc sử dụng markdown có nghĩa là chúng ta có thể cung cấp cú pháp và định dạng có thể dễ dàng sao chép vào hầu hết các công cụ tạo báo cáo và có thể tạo PDF trực tiếp từ Obsidian.

Lựa chọn công cụ là sở thích cá nhân và tùy theo tình huống. Một số công cụ tốt hơn trong một số tình huống nhất định so với các công cụ khác, nhưng không có công cụ nào là hoàn hảo. Bạn nên dành thời gian và dùng thử các công cụ chúng tôi đã đề cập, đọc tài liệu, làm quen với chúng và sau đó quyết định công cụ nào phù hợp với bạn. Một số công cụ bổ sung có thể được tìm thấy trong tài liệu tham khảo trên trang web của nil0x42 .

5.1.5. Chụp ảnh màn hình

Ảnh chụp màn hình là một phần quan trọng của việc ghi chép và báo cáo kỹ thuật. Một ảnh chụp màn hình tốt có thể giải thích vấn đề đang được thảo luận một cách nhanh chóng và chi tiết hơn so với mô tả bằng văn bản. Ảnh chụp màn hình đặc biệt hữu ích để giúp trình bày một phần phức tạp về mặt kỹ thuật hoặc nhiều chi tiết của báo cáo. Như câu nói, một hình ảnh có giá trị bằng 1000 từ. Ngược lại, một ảnh chụp màn hình tệ có thể làm lu mờ và thu hút sự chú ý khỏi vấn đề.

Ảnh chụp màn hình là một cách quan trọng để truyền đạt tác động trực quan của một phát hiện và có thể hiệu quả hơn nhiều so với văn bản đơn thuần. Ví dụ, sẽ hiệu quả hơn khi hiển thị ảnh chụp màn hình của hộp cảnh báo bật lên từ tải trọng XSS thay vì mô tả nó bằng lời. Tuy nhiên, sẽ khó hơn khi sử dụng ảnh chụp màn hình để mô tả chính xác những gì đang xảy ra khi chúng ta sử dụng thứ gì đó như tải trọng tràn bộ đệm. Giống như chúng ta muốn sử dụng đúng công cụ để thực hiện một số cuộc tấn công nhất định, chúng ta cũng muốn sử dụng đúng công cụ để hiển thị một số kết quả nhất định (chẳng hạn như văn bản so với hình ảnh).

Chúng ta có thể sử dụng ảnh chụp màn hình để bổ sung cho ghi chú của mình hoặc đưa chúng vào báo cáo để minh họa các bước chúng ta đã thực hiện, điều này sẽ giúp người kiểm tra khác tái tạo các vấn đề. Tuy nhiên, chúng ta cần phải ý thức được đối tượng. Trong khi một người kiểm tra thâm nhập có thể coi cửa sổ cảnh báo để chứng minh XSS là hoàn toàn tự giải thích, thì các nhà phát triển không quen thuộc với lỗ hổng này có thể không hiểu nguyên nhân hoặc tác động thực sự của nó. Thực hành tốt là luôn hỗ trợ ảnh chụp màn hình bằng văn bản.

Ảnh chụp màn hình có một mục tiêu cụ thể, đó là truyền tải thông tin cần nhiều câu để mô tả hoặc tạo ra tác động. Với mục tiêu này, ảnh chụp màn hình phải chứa đủ thông tin để không sử dụng văn bản, nhưng không nên có quá nhiều thông tin khiến ảnh chụp màn hình trở nên khó hiểu.

Quay lại ví dụ nêu trên trong phần ghi chú, chúng tôi đã tìm thấy XSS phản ánh trong trường tên người dùng của thông tin đăng nhập ứng dụng. Chúng tôi sẽ giải thích đúng về tác động của XSS trong báo cáo thực tế. Tuy nhiên, tác động của XSS dễ thể hiện hơn nhiều so với việc giải thích mà không có tham chiếu trực quan làm cơ sở. Chúng tôi phải đưa vào bằng chứng về việc thực thi JavaScript tùy ý, cũng như các thành phần trực quan của trang web (tức là URL trong cửa sổ trình duyệt). Nếu cần, cũng có thể ghi lại các bước thứ cấp hoặc dẫn đến.

Một ảnh chụp màn hình được xây dựng tốt sẽ dễ dàng phân tích trực quan. Người đọc có thể hiểu trực quan hình ảnh và chú thích mà không cần bất kỳ câu hỏi nào. Nếu cần nhiều bối cảnh xung quanh hơn, có thể thêm vào đoạn văn ở trên hoặc dưới hình ảnh, nhưng bản thân hình ảnh phải được hiểu.

Một lần nữa, sử dụng ví dụ về XSS trong biểu mẫu đăng nhập của chúng tôi, chúng tôi sẽ bao gồm các thành phần sau trong ảnh chụp màn hình, thay đổi kích thước cửa sổ nếu cần. Lý tưởng nhất là chúng tôi sẽ bao gồm URL cũng như một số thương hiệu và logo cụ thể của công ty trên biểu mẫu. Điều này cho phép họ biết trang web chính xác và liên kết lỗ hổng với hình ảnh công ty của họ.

Cửa sổ bật lên thực tế được thực hiện trong bằng chứng khái niệm cũng cần thiết, thay thế cho bất kỳ tải trọng nâng cao nào khi bằng chứng khái niệm được đưa ra dần dần. Cuối cùng, chúng tôi muốn đảm bảo rằng tất cả đều dễ đọc. Một ảnh chụp màn hình cần được phóng to để xem đúng cách sẽ làm gián đoạn dòng chảy của người đọc. Một ảnh chụp màn hình tốt sẽ dễ đọc ngay lập tức, như được hiển thị bên dưới.

Có một số cạm bẫy mà chúng ta nên tránh khi sử dụng ảnh chụp màn hình. Chúng ta đã thảo luận về việc đảm bảo ảnh chụp màn hình dễ đọc. Chúng ta cũng phải đảm bảo không có nhiều hơn một khái niệm được minh họa trong mỗi ảnh chụp màn hình. Một ảnh chụp màn hình chứa hai thông tin có liên quan không dễ hiểu ngay từ cái nhìn đầu tiên. Chúng ta cũng phải đảm bảo tác động được đóng khung đúng cách trong ảnh chụp màn hình. Việc để mục tiêu của ảnh chụp màn hình lệch tâm ở bên cạnh cũng làm lu mờ ý định. Cuối cùng, chú thích cho ảnh chụp màn hình không nên quá dài.

Ảnh chụp màn hình ở trên che mất thông tin quan trọng bằng một thông tin không liên quan, khiến người đọc không hiểu được toàn bộ tác động của ảnh chụp màn hình.

Tóm lại, một ảnh chụp màn hình tốt phải có những đặc điểm sau:

• có thể đọc được
• chứa một số dấu hiệu trực quan cho thấy nó áp dụng cho khách hàng
• chứa đựng tài liệu đang được mô tả
• hỗ trợ mô tả của vật liệu
• đóng khung đúng nội dung tài liệu đang được mô tả

Mặt khác, một ảnh chụp màn hình xấu là ảnh:

• không thể đọc được
• mang tính chung chung hơn là dành riêng cho khách hàng
• chứa thông tin không rõ ràng hoặc không liên quan
• được đóng khung không đúng cách

Bên dưới ảnh chụp màn hình, chúng tôi bao gồm một chú thích. Chú thích không nhằm mục đích cung cấp thêm ngữ cảnh cho bức ảnh. Chú thích có mục đích mô tả bức ảnh trong một vài từ. Bất kỳ ngữ cảnh bổ sung nào cần thiết đều có thể được cung cấp trong một đoạn văn riêng. Trong hầu hết các trường hợp, tám đến mười từ là mức tối đa phù hợp cho một chú thích.

5.1.6. Công cụ chụp ảnh màn hình

Chúng ta có thể chụp ảnh màn hình bằng các chức năng của hệ điều hành gốc. Windows, Linux và macOS đều cung cấp các công cụ để chụp ảnh màn hình. Chúng ta cũng có thể sử dụng các công cụ chuyên dụng.

Đối với Windows, phím PrintScreen cho phép chúng ta sao chép toàn màn hình và Alt/PrtSc chụp ảnh màn hình của cửa sổ đang hoạt động. Sau đó, có thể dán ảnh này vào tài liệu Paint, Word hoặc PowerPoint và chỉnh sửa theo yêu cầu. Chúng ta thường muốn cắt ảnh để loại bỏ bất kỳ phần không mong muốn nào và chúng ta có thể thực hiện điều đó trong các ứng dụng này.

Chúng ta cũng có thể gọi Windows Snipping Tool bằng cách nhấn phím Windows cùng với Shift/S.

Công cụ Snipping cho phép chúng ta đánh dấu và chụp ảnh màn hình bất kỳ vùng nào trên màn hình mà chúng ta chọn.

MacOS cung cấp khả năng chụp ảnh màn hình bằng cách sử dụng tổ hợp phím Shift/Command với các phím số 3, 4 hoặc 5. Để chọn và lưu toàn bộ màn hình, chúng ta có thể sử dụng F + B + 3. Để làm nổi bật và chọn một vùng cụ thể trên màn hình, chúng ta chỉ cần sử dụng F + B + 4 hoặc F + B + 5 .

Chúng ta có thể chụp ảnh màn hình trong Linux bằng phím PrintScreen. Phím này sẽ chụp và lưu toàn bộ màn hình vào thư mục Images/ của người dùng . B +PrintScreen sẽ cho phép tô sáng và chọn vùng. Trong Kali Linux, chúng ta cũng có thể sử dụng công cụ Screenshot được cài đặt theo mặc định và đi kèm với nhiều tùy chọn như chọn cửa sổ đang hoạt động, chọn vùng, thêm độ trễ trước khi chụp ảnh màn hình thực tế, v.v.

Flameshot là một công cụ chụp màn hình mã nguồn mở, không phụ thuộc vào hệ điều hành, giàu tính năng. Nó đi kèm với cả giao diện dòng lệnh và GUI và có các công cụ vẽ tích hợp để thêm điểm nổi bật, điểm ảnh, văn bản và các sửa đổi khác vào hình ảnh đã chụp.

Phòng thí nghiệm

1. Người kiểm tra xâm nhập và khách hàng phải hoàn toàn đồng ý về những gì trước khi bắt đầu hợp tác?

Trả lời

2. Hai từ nào kết thúc bằng "cise" là những đặc tính mong muốn của cấu trúc chung của ghi chú kiểm tra thâm nhập? Nhập câu trả lời của bạn vào biểu mẫu A and B.

Trả lời

3. Định dạng ghi chú của chúng tôi cho bài kiểm tra ứng dụng web phải bao gồm tên ứng dụng, URL, chi tiết sự cố và tải trọng bằng chứng khái niệm. Chúng tôi nên bao gồm những gì nữa?

Trả lời

4. Có bao nhiêu khái niệm quan trọng nên được hiển thị trong một ảnh chụp màn hình?

Trả lời

5.2. Viết báo cáo kiểm tra thâm nhập kỹ thuật hiệu quả

Trong Đơn vị học tập này, chúng ta sẽ đề cập đến các Mục tiêu học tập sau:

• Xác định mục đích của báo cáo kỹ thuật
• Hiểu cách điều chỉnh nội dung cụ thể
• Xây dựng một bản tóm tắt điều hành
• Tính đến các cân nhắc cụ thể về môi trường thử nghiệm
• Tạo bản tóm tắt kỹ thuật
• Mô tả các phát hiện và khuyến nghị kỹ thuật
• Nhận biết khi nào nên sử dụng phụ lục, tài nguyên và tài liệu tham khảo

5.2.1. Mục đích của Báo cáo kỹ thuật

Là nhà cung cấp dịch vụ kiểm tra thâm nhập, chúng tôi muốn cung cấp cho khách hàng của mình nhiều giá trị nhất có thể. Báo cáo là cơ chế cung cấp giá trị và là hiện vật chính cho phép khách hàng thực hiện hành động tiếp theo. Khả năng tìm ra hai mươi lỗ hổng trong ứng dụng web của chúng tôi sẽ không tạo ra tác động kinh doanh nếu chúng tôi không thể cung cấp bản trình bày về cả lỗ hổng và các khuyến nghị của chúng tôi về biện pháp khắc phục tiềm năng. Nếu không có định hướng rõ ràng về phía trước, khách hàng sẽ không nhận được giá trị đầy đủ cho thời gian và tiền bạc của họ.

Để chuẩn bị báo cáo đúng cách cho khách hàng, chúng ta phải hiểu hai điều:

1. Mục đích của báo cáo.
2. Làm thế nào chúng tôi có thể truyền tải thông tin đã thu thập theo cách mà khán giả có thể hiểu được.

Khi khách hàng trả tiền cho một cam kết kiểm tra thâm nhập, người ta thường (hiểu nhầm) rằng họ "chỉ" trả tiền cho một hacker đạo đức để tấn công hợp pháp vào cơ sở hạ tầng của họ nhằm tìm và khai thác điểm yếu. Mặc dù về mặt kỹ thuật, điều đó có thể cần thiết để mang lại kết quả mong muốn, nhưng đó không phải là mục đích cơ bản của cam kết. Thậm chí có một số trường hợp khách hàng không muốn cơ sở hạ tầng của họ bị tấn công!

Vậy, mục đích của một công ty thuê một người kiểm tra thâm nhập là gì? Mục tiêu cuối cùng là để khách hàng được trình bày một lộ trình tiến về phía trước phác thảo và nêu bật tất cả các lỗi hiện có trong hệ thống của họ trong phạm vi của hợp đồng, các cách để khắc phục các lỗi đó ngay lập tức và các mục tiêu chiến lược sẽ ngăn chặn các lỗ hổng đó xuất hiện trong tương lai. Đầu ra này thường được cung cấp dưới dạng báo cáo kiểm tra thâm nhập. Đối với khách hàng, báo cáo (thường) là sản phẩm duy nhất thực sự quan trọng của hợp đồng.

Chúng ta có thể tự hỏi làm thế nào chúng ta nên báo cáo về các phần trong cam kết của mình mà chúng ta chưa tìm thấy bất kỳ lỗ hổng nào. Trong nhiều trường hợp chúng ta không tìm thấy lỗ hổng, chúng ta nên tránh đưa quá nhiều chi tiết kỹ thuật về những gì chúng ta đã làm vào báo cáo. Một tuyên bố đơn giản rằng không tìm thấy lỗ hổng nào thường là đủ. Chúng ta nên đảm bảo rằng chúng ta không làm khách hàng nhầm lẫn với các chi tiết kỹ thuật về những nỗ lực của chúng ta, vì điều này sẽ làm giảm giá trị của các vấn đề mà chúng ta thực sự tìm thấy. Nhiệm vụ của người kiểm tra là trình bày thông tin đó theo cách dễ hiểu và dễ hành động. Tuy nhiên, một số khách hàng có thể thích các báo cáo kỹ thuật dài dòng và sâu sắc ngay cả về những vấn đề không phải là vấn đề, điều này dẫn đến một cân nhắc khác: đối tượng.

Khách hàng nhận được báo cáo là một chuyên gia trong ngành cụ thể của họ. Họ thường (mặc dù không phải lúc nào cũng vậy) nhận thức được các mối quan ngại về bảo mật của ngành đó và sẽ mong đợi chúng tôi đã làm bài tập về nhà để cũng nhận thức được chúng. Trong thực tế, điều này có nghĩa là phải hiểu sâu sắc về những gì sẽ gây lo ngại cho khách hàng trong trường hợp bị tấn công. Nói cách khác, hiểu được các mục tiêu và mục đích kinh doanh chính của họ. Đây là một lý do khác tại sao việc hiểu rõ về Quy tắc giao chiến lại quan trọng đến vậy, vì nó giúp chúng tôi có cái nhìn sâu sắc về các mối quan tâm cốt lõi của khách hàng.

Tất cả các vấn đề phát hiện được trong quá trình thử nghiệm phải được ghi lại nhưng chúng tôi sẽ muốn nêu bật bất kỳ vấn đề nào chúng tôi tìm thấy có thể ảnh hưởng đến các lĩnh vực chính này. Ví dụ về các lĩnh vực chính cụ thể của khách hàng có thể bao gồm HIPAA , một khuôn khổ quản lý dữ liệu y tế tại Hoa Kỳ và PCI , một khuôn khổ quản lý thẻ tín dụng và xử lý thanh toán.

Hãy xem xét tình huống sau. Giả sử rằng Khách hàng A là một bệnh viện và Khách hàng B là một ngân hàng, và chúng tôi được thuê để thực hiện thử nghiệm trên từng cơ sở hạ tầng nội bộ của họ. Chúng tôi có thể đưa ra kết quả tương tự cho cả hai và mặc dù chúng có thể có cùng mức độ nghiêm trọng về mặt kỹ thuật, chúng tôi không nhất thiết phải ghi lại các phát hiện với cùng mức độ rủi ro và mức độ ưu tiên để khắc phục.

Vì Khách hàng A là bệnh viện có các thiết bị y tế được kết nối với mạng của họ, nên các bác sĩ và bệnh nhân cần hành động nhanh chóng để phản hồi cảnh báo giám sát rất có thể sẽ lo lắng về thời gian hoạt động của mạng và mức độ sẵn sàng của máy. Các thiết bị y tế được kết nối với mạng thường chạy trên các máy cũ có phiên bản phần mềm nhúng lỗi thời. Nhu cầu hoạt động liên tục có thể khiến các thiết bị này không được nâng cấp và vá lỗi. Trong khi báo cáo, các lỗ hổng mà chúng tôi tìm thấy nên được nêu bật và sau đó chúng tôi có thể đưa ra đề xuất cô lập các máy trên mạng con logic của riêng chúng vì không thể áp dụng các bản nâng cấp hoặc vá lỗi kịp thời.

Mặt khác, cùng một kịch bản chính xác này trên mạng của Khách hàng B có thể là thảm họa. Nếu một máy chủ hoặc thiết bị trong ngân hàng bị thiếu bản vá, thì đó có thể là một chỗ đứng vững chắc trong mạng. Vì các hệ thống sẽ cần giao tiếp với các hệ thống khác trên mạng, nên việc phân đoạn hoàn toàn có thể không khả thi. Do đó, việc thiếu bản vá là mối quan tâm lớn hơn nhiều và có thể cần được báo cáo là một vấn đề nghiêm trọng.

Khi chúng tôi bắt đầu ghi lại những phát hiện của mình, chúng tôi sẽ cần ghi nhớ tình huống mà lỗ hổng có thể bị khai thác và tác động tiềm ẩn của nó. Đăng nhập HTTP dạng văn bản rõ trên internet được coi là cực kỳ không an toàn. Trên mạng nội bộ, mặc dù vẫn không an toàn, nhưng ít đáng lo ngại hơn vì phải thực hiện nhiều bước hơn để khai thác đúng cách. Tương tự như vậy, một bệnh viện có thể không quan tâm đến việc cổng thông tin đăng nhập hướng ra Internet của họ chấp nhận mã hóa TLS 1.0. Một trang web thương mại điện tử có thể sẽ quan tâm nhiều hơn, vì vi phạm PCI mà việc chấp nhận TLS 1.0 tạo ra.

Với tư cách là người viết báo cáo, chúng tôi phải trình bày thông tin hữu ích, chính xác và có thể thực hiện được cho khách hàng mà không đưa vào thành kiến ​​của riêng mình.

5.2.2. Điều chỉnh nội dung

Chúng tôi phải cung cấp nội dung phù hợp với kỹ năng cho tất cả người đọc báo cáo của chúng tôi. Nội dung này có thể được đọc bởi các giám đốc điều hành, người đứng đầu bộ phận an ninh và các thành viên kỹ thuật của nhóm an ninh. Điều này có nghĩa là chúng tôi không chỉ muốn cung cấp tổng quan đơn giản về các vấn đề cho các giám đốc điều hành mà còn muốn cung cấp đủ thông tin chi tiết về kỹ thuật cho những người đọc có nhiều hiểu biết hơn về kỹ thuật.

Chúng ta có thể thực hiện điều này bằng cách chia nội dung thành cấu trúc phù hợp của các phần và tiểu phần. Số lượng đối tượng mà chúng ta có cho một cam kết cụ thể phụ thuộc rất nhiều vào mối quan hệ của chúng ta với khách hàng, quy mô, ngân sách và mức độ trưởng thành của họ. Đối với Mô-đun này, chúng ta sẽ xem xét một cam kết mà chúng ta chỉ có hai đối tượng mục tiêu. Đầu tiên, và có thể nói là quan trọng hơn, là cấp quản lý. Đây thường là cấp mà nhiều hợp đồng cam kết bên ngoài được ký kết và là nơi cần nhấn mạnh giá trị của việc đầu tư vào thử nghiệm. Tùy thuộc vào doanh nghiệp, đây có thể là các chức năng cấp C (CISO, CSO, CFO, v.v.) hoặc trưởng phòng CNTT hoặc an ninh.

Tuy nhiên, hầu hết các giám đốc điều hành và giám đốc cấp cao không nhất thiết phải có khả năng kỹ thuật để theo dõi một giải thích kỹ thuật chi tiết. Chúng ta nên cung cấp cho họ một phần nêu bật kết quả và tác động của sự tham gia theo cách báo cáo chính xác về các lỗ hổng được tìm thấy trong khi không bị quá tải với các chi tiết kỹ thuật.

Đối tượng thứ hai mà chúng tôi sẽ xem xét bao gồm các nhân viên kỹ thuật có kiến ​​thức kỹ thuật để hiểu báo cáo và triển khai các biện pháp khắc phục được nêu trong báo cáo cho các lỗ hổng đã được xác định. Đối tượng này phải được cung cấp đủ thông tin chi tiết về kỹ thuật để họ có thể hiểu được lỗi, tác động của từng phát hiện và cách khắc phục. Ngoài ra, đối tượng này sẽ được hưởng lợi rất nhiều khi chúng tôi có thể cung cấp lời khuyên về cách ngăn ngừa các loại sự cố tương tự xảy ra trong tương lai.

5.2.3. Tóm tắt nội dung

Phần đầu tiên của báo cáo phải là Tóm tắt điều hành. Điều này cho phép ban quản lý cấp cao hiểu được phạm vi và kết quả của thử nghiệm ở mức đủ để hiểu được giá trị của thử nghiệm và phê duyệt biện pháp khắc phục. Chúng tôi bắt đầu bằng những thông tin ngắn gọn cung cấp bức tranh toàn cảnh và tiếp theo là Tóm tắt điều hành đầy đủ.

Tóm tắt điều hành nên bắt đầu bằng việc phác thảo phạm vi của cam kết. Việc có một phạm vi rõ ràng được thống nhất trước khi thử nghiệm sẽ xác định ranh giới của những gì sẽ được đề cập. Sau đó, chúng tôi muốn rất rõ ràng về những gì chính xác đã được thử nghiệm và liệu có bất kỳ điều gì bị loại khỏi phạm vi hay không. Các vấn đề về thời gian, chẳng hạn như thời gian thử nghiệm không đủ do tìm thấy quá nhiều lỗ hổng để báo cáo đầy đủ, nên được đưa vào để đảm bảo rằng tuyên bố phạm vi cho bất kỳ thử nghiệm tiếp theo nào là phù hợp. Việc đưa tuyên bố phạm vi vào báo cáo sẽ bảo vệ người kiểm tra thâm nhập khỏi bất kỳ gợi ý nào về việc không hoàn thành thử nghiệm bắt buộc. Nó cũng cung cấp cho khách hàng một mô hình chính xác hơn về những gì thực tế với ngân sách và hạn chế thời gian đã được thiết lập ban đầu.

Thứ hai, chúng tôi muốn đưa vào khung thời gian của bài kiểm tra. Điều này bao gồm thời gian dành cho bài kiểm tra, ngày tháng và có thể là cả giờ kiểm tra nữa.

Thứ ba, chúng ta nên tham khảo Quy tắc giao chiến và tham khảo báo cáo của trọng tài nếu trọng tài là thành viên của nhóm thử nghiệm. Nếu thử nghiệm từ chối dịch vụ được phép hoặc kỹ thuật xã hội được khuyến khích, điều đó nên được ghi chú ở đây. Nếu chúng ta tuân theo một phương pháp thử nghiệm cụ thể, chúng ta cũng nên chỉ ra điều đó ở đây.

Cuối cùng, chúng ta có thể bao gồm cơ sở hạ tầng hỗ trợ và tài khoản. Sử dụng ví dụ về ứng dụng web, nếu chúng ta được khách hàng cung cấp tài khoản người dùng, hãy bao gồm chúng ở đây cùng với địa chỉ IP mà các cuộc tấn công xuất phát (tức là máy thử nghiệm của chúng ta). Chúng ta cũng nên ghi chú bất kỳ tài khoản nào mà chúng ta đã tạo để khách hàng có thể xác nhận rằng chúng đã bị xóa. Sau đây là ví dụ về cấu trúc cấp cao này:

Executive Summary:

- Scope: https://kali.org/login.php
- Timeframe: Jan 3 - 5, 2022
- OWASP/PCI Testing methodology was used
- Social engineering and DoS testing were not in scope
- No testing accounts were given; testing was black box from an external IP address
- All tests were run from 192.168.1.2

Liệt kê 3 - Chi tiết liên quan

Tiếp theo, chúng tôi sẽ chuẩn bị Tóm tắt điều hành dạng dài. Đây là bản tóm tắt bằng văn bản về thử nghiệm cung cấp tổng quan cấp cao về từng bước của quá trình tương tác và thiết lập mức độ nghiêm trọng, bối cảnh và "kịch bản xấu nhất" cho những phát hiện chính từ thử nghiệm. Điều quan trọng là không được hạ thấp hoặc hạ thấp các lỗ hổng. Chúng tôi muốn mô hình tinh thần của khách hàng về thế trận bảo mật của họ phải chính xác. Ví dụ: nếu chúng tôi phát hiện ra một lỗi SQL injection cho phép đánh cắp thông tin thẻ tín dụng, thì điều đó thể hiện mức độ nghiêm trọng rất khác so với khi chúng tôi phát hiện ra lỗi bỏ qua xác thực trên hệ thống lưu trữ dữ liệu công khai. Chúng tôi chắc chắn sẽ nhấn mạnh vào trường hợp trước trong Tóm tắt điều hành, nhưng chúng tôi có thể không nêu bật trường hợp sau trong phần này.

Chúng ta nên ghi chú lại bất kỳ xu hướng nào được quan sát thấy trong quá trình thử nghiệm để đưa ra lời khuyên chiến lược. Giám đốc điều hành không cần được cung cấp đầy đủ thông tin chi tiết kỹ thuật trong phần này và nhân viên kỹ thuật sẽ có thể tìm thấy chúng vì mỗi lỗ hổng sẽ được mở rộng trong các phần sau của báo cáo. Tuy nhiên, những gì chúng ta có thể làm là mô tả các xu hướng mà chúng ta đã xác định và xác thực mối quan tâm của mình bằng bản tóm tắt của một hoặc hai phát hiện liên quan quan trọng hơn.

Để làm nổi bật xu hướng, chúng tôi muốn nhóm các phát hiện có lỗ hổng tương tự. Nhiều lỗ hổng cùng loại thường cho thấy lỗi trong khu vực cụ thể đó. Ví dụ, nếu chúng tôi tìm thấy XSS được lưu trữ và phản ánh, cùng với lỗ hổng SQL injection và tải tệp lên, thì đầu vào của người dùng rõ ràng không được khử trùng đúng cách trên toàn bộ hệ thống. Điều này phải được khắc phục ở cấp độ hệ thống. Phần này là nơi thích hợp để thông báo cho khách hàng về lỗi hệ thống và chúng tôi có thể đề xuất các thay đổi quy trình cần thiết như biện pháp khắc phục. Trong ví dụ này, chúng tôi có thể khuyến khích khách hàng cung cấp đào tạo bảo mật phù hợp cho các nhà phát triển của họ.

Việc đề cập đến những điều mà khách hàng đã làm tốt là rất hữu ích. Điều này đặc biệt đúng vì trong khi ban quản lý có thể trả tiền cho sự tham gia, mối quan hệ làm việc của chúng tôi thường là với các nhóm bảo mật kỹ thuật. Chúng tôi muốn đảm bảo rằng họ không bị coi thường về mặt cá nhân. Ngay cả những cuộc kiểm tra thâm nhập tìm thấy các lỗ hổng nghiêm trọng cũng có khả năng xác định một hoặc hai lĩnh vực đã được củng cố. Việc bao gồm các lĩnh vực đó sẽ làm giảm tác động đến mọi người và khiến khách hàng chấp nhận báo cáo hơn.

Tóm tắt nội dung có thể được chia nhỏ như sau:

Đầu tiên chúng tôi đưa vào một vài câu mô tả sự tham gia:

- "The Client hired OffSec to conduct a penetration test of
their kali.org web application in October of 2025. The test was conducted
from a remote IP between the hours of 9 AM and 5 PM, with no users
provided by the Client."

Liệt kê 4 - Mô tả sự tham gia

Tiếp theo, chúng tôi thêm một số câu nói về một số quá trình củng cố hiệu quả mà chúng tôi đã quan sát được:

- "The application had many forms of hardening in place. First, OffSec was unable to upload malicious files due to the strong filtering
in place. OffSec was also unable to brute force user accounts
because of the robust lockout policy in place. Finally, the strong
password policy made trivial password attacks unlikely to succeed.
This points to a commendable culture of user account protections."

Liệt kê 5 - Xác định những điểm tích cực

Lưu ý ngôn ngữ ở đây. Chúng tôi không nói điều gì đó như "Không thể tải lên các tệp độc hại", vì chúng tôi không thể đưa ra tuyên bố tuyệt đối mà không có bằng chứng tuyệt đối. Chúng tôi được cấp một ngân sách thời gian và nguồn lực hạn chế để thực hiện cam kết của mình và bản thân chúng tôi cũng có thể mắc lỗi. Chúng tôi phải cẩn thận để đảm bảo ngôn ngữ của mình không loại trừ khả năng chúng tôi chỉ đơn giản là không thể tìm ra một lỗi thực sự tồn tại và vẫn chưa bị phát hiện.

Tiếp theo, chúng tôi sẽ thảo luận về các lỗ hổng đã phát hiện:

- "However, there were still areas of concern within the application.
OffSec was able to inject arbitrary JavaScript into the browser of
an unwitting victim that would then be run in the context of that
victim. In conjunction with the username enumeration on the login
field, there seems to be a trend of unsanitized user input compounded
by verbose error messages being returned to the user. This can lead
to some impactful issues, such as password or session stealing. It is
recommended that all input and error messages that are returned to the
user be sanitized and made generic to prevent this class of issue from
cropping up."

Liệt kê 6 - Giải thích về lỗ hổng

Có thể cần nhiều đoạn văn loại này, tùy thuộc vào số lượng và loại lỗ hổng mà chúng tôi tìm thấy. Sử dụng nhiều đoạn văn nhất có thể để minh họa các xu hướng, nhưng cố gắng không tạo ra các xu hướng không tồn tại.

Cuối cùng, phần Tóm tắt nội dung nên kết thúc bằng phần tóm tắt về cam kết:

"These vulnerabilities and their remediations are described in more
detail below. Should any questions arise, OffSec is happy
to provide further advice and remediation help."

Liệt kê 7 - Kết luận ngắn gọn

Chúng tôi xin đề cập ở đây rằng không phải tất cả các kiểm thử viên thâm nhập đều sẽ đưa ra lời khuyên khắc phục và không phải tất cả khách hàng đều mong đợi điều đó. Tuy nhiên, chúng tôi tin rằng mối quan hệ hiệu quả nhất là mối quan hệ giữa khách hàng và nhà cung cấp cùng làm việc ở cấp độ đó.

5.2.4. Cân nhắc về môi trường thử nghiệm

Phần đầu tiên của báo cáo đầy đủ phải nêu chi tiết mọi vấn đề ảnh hưởng đến quá trình thử nghiệm. Đây thường là một phần khá nhỏ. Đôi khi, có những sai sót hoặc tình tiết giảm nhẹ xảy ra trong quá trình thực hiện. Mặc dù những người trực tiếp tham gia đã biết về chúng, chúng ta nên ghi lại chúng trong báo cáo để chứng minh rằng chúng ta đã minh bạch.

Nhiệm vụ của chúng tôi là những người kiểm tra thâm nhập và tư vấn là thông báo cho khách hàng về mọi hoàn cảnh và hạn chế ảnh hưởng đến quá trình hợp tác. Điều này được thực hiện để họ có thể cải thiện lần thử nghiệm tiếp theo và nhận được giá trị cao nhất cho số tiền họ bỏ ra. Điều quan trọng cần lưu ý là không phải mọi vấn đề đều cần được nêu bật và bất kể hoàn cảnh của cuộc thử nghiệm như thế nào, chúng tôi cần đảm bảo báo cáo là chuyên nghiệp.

Chúng ta sẽ xem xét ba tình huống tiềm ẩn liên quan đến các tình tiết giảm nhẹ:

• Kết quả tích cực : "Không có hạn chế hoặc tình tiết giảm nhẹ nào trong quá trình thực hiện. Thời gian phân bổ là đủ để kiểm tra kỹ lưỡng môi trường."
• Kết quả trung lập : "Không có thông tin xác thực nào được phân bổ cho người thử nghiệm trong hai ngày đầu tiên của cuộc thử nghiệm. Tuy nhiên, phạm vi tấn công nhỏ hơn nhiều so với dự kiến. Do đó, điều này không ảnh hưởng đến toàn bộ cuộc thử nghiệm. OffSec khuyến nghị rằng việc truyền đạt thông tin xác thực diễn ra ngay trước khi bắt đầu hợp đồng cho các hợp đồng trong tương lai, để chúng tôi có thể cung cấp nhiều cuộc thử nghiệm nhất có thể trong thời gian được phân bổ."
• Kết quả tiêu cực : "Không có đủ thời gian dành cho hoạt động này để tiến hành đánh giá kỹ lưỡng đơn đăng ký và phạm vi trở nên lớn hơn nhiều so với dự kiến. Nên dành nhiều thời gian hơn cho các hoạt động trong tương lai để có phạm vi bao phủ toàn diện hơn."

Những cân nhắc mà chúng tôi nêu ra trong phần này sẽ cho phép cả chúng tôi và khách hàng học hỏi từ những sai lầm hoặc thành công trong bài kiểm tra này và áp dụng chúng vào những lần thực hiện trong tương lai.

5.2.5. Tóm tắt kỹ thuật

Phần tiếp theo sẽ là danh sách tất cả các phát hiện chính trong báo cáo, được viết kèm theo bản tóm tắt và khuyến nghị để người có chuyên môn, như kiến ​​trúc sư bảo mật, có thể biết ngay những việc cần làm.

Phần này nên nhóm các phát hiện vào các khu vực chung. Ví dụ, tất cả các vấn đề về mật khẩu tài khoản yếu đã được xác định sẽ được nhóm lại, bất kể mốc thời gian thử nghiệm. Một ví dụ về cấu trúc của phần này có thể là:

• Quản lý người dùng và quyền hạn
• Ngành kiến ​​​​trúc
• Ủy quyền
• Quản lý bản vá
• Tính toàn vẹn và chữ ký
• Xác thực
• Kiểm soát truy cập
• Kiểm toán, Quản lý Nhật ký và Giám sát
• Giao thông và mã hóa dữ liệu
• Cấu hình bảo mật không đúng

Sau đây là ví dụ về bản tóm tắt kỹ thuật cho Quản lý bản vá:

4. Patch Management

Windows and Ubuntu operating systems that are not up to date were
identified. These are shown to be vulnerable to publicly-available
exploits and could result in malicious execution of code, theft
of sensitive information, or cause denial of services which may
impact the infrastructure. Using outdated applications increases the
possibility of an intruder gaining unauthorized access by exploiting
known vulnerabilities. Patch management ought to be improved and
updates should be applied in conjunction with change management.

Liệt kê 8 - Ví dụ tóm tắt kỹ thuật

Phần này nên kết thúc bằng một bản đồ nhiệt rủi ro dựa trên mức độ nghiêm trọng của lỗ hổng được điều chỉnh cho phù hợp với bối cảnh của khách hàng và theo thỏa thuận với đại diện rủi ro bảo mật của khách hàng nếu có thể.

5.2.6. Phát hiện kỹ thuật và khuyến nghị

Phần Phát hiện và Khắc phục Kỹ thuật là nơi chúng tôi đưa vào các chi tiết kỹ thuật đầy đủ liên quan đến bài kiểm tra thâm nhập của chúng tôi và những gì chúng tôi coi là các bước thích hợp cần thiết để giải quyết các phát hiện. Mặc dù đây là phần kỹ thuật, chúng tôi không nên cho rằng đối tượng là những người kiểm tra thâm nhập.

Không phải ai, ngay cả những người làm việc trong các công nghệ đang được thử nghiệm, cũng sẽ hiểu đầy đủ các sắc thái của lỗ hổng. Mặc dù không phải lúc nào cũng cần phải đào sâu kỹ thuật vào nguyên nhân gốc rễ của một cuộc khai thác, nhưng thường thì nên cung cấp tổng quan rộng về cách thức nó có thể diễn ra. Tốt hơn là nên cho rằng khán giả có ít kiến ​​thức nền tảng hơn và cung cấp quá nhiều thông tin, thay vì ngược lại.

Phần này thường được trình bày dưới dạng bảng và cung cấp đầy đủ thông tin chi tiết về các phát hiện. Một phát hiện có thể bao gồm một lỗ hổng đã được xác định hoặc có thể bao gồm nhiều lỗ hổng cùng loại.

Điều quan trọng cần lưu ý là có thể cần có một tường thuật về cuộc tấn công. Tường thuật này mô tả, theo định dạng câu chuyện, chính xác những gì đã xảy ra trong quá trình thử nghiệm. Điều này thường được thực hiện cho một cuộc giao tranh đe dọa được mô phỏng, nhưng đôi khi cũng hữu ích để mô tả các bước khai thác phức tạp hơn cần thiết cho một cuộc thử nghiệm thâm nhập thông thường. Nếu cần thiết, thì việc viết ra đường dẫn tấn công từng bước, với các ảnh chụp màn hình phù hợp, thường là đủ. Một tường thuật mở rộng có thể được đưa vào Phụ lục và tham chiếu từ bảng phát hiện.

Dưới đây là ba mục nhập ví dụ:

Tham khảo	Rủi ro	Mô tả vấn đề và ý nghĩa	Khuyến nghị
1	H	Quản lý Tài khoản, Mật khẩu và Quyền hạn không đầy đủ. Quản lý tài khoản là quá trình cung cấp tài khoản mới và xóa tài khoản không còn cần thiết. Các vấn đề sau đây đã được xác định bằng cách thực hiện phân tích 122.624 tài khoản người dùng sau khi xâm phạm: 722 tài khoản người dùng được định cấu hình để không bao giờ hết hạn; 23.142 người dùng chưa bao giờ đăng nhập; 6 người dùng là thành viên của nhóm quản trị viên miền; mật khẩu ban đầu mặc định được sử dụng cho 968 tài khoản.	Tất cả các tài khoản phải có mật khẩu được thực thi theo chính sách nghiêm ngặt. Tất cả các tài khoản có mật khẩu yếu phải bị buộc phải thay đổi. Tất cả các tài khoản phải được đặt tự động hết hạn. Các tài khoản không còn cần thiết phải bị xóa.
2	H	Thông tin được liệt kê thông qua phiên SMB ẩn danh. Một kết nối phiên SMB ẩn danh đã được thực hiện và thông tin thu được sau đó được sử dụng để có được quyền truy cập của người dùng trái phép như được nêu chi tiết trong Phụ lục E.9.	Để ngăn chặn việc thu thập thông tin qua các phiên SMB ẩn danh: Quyền truy cập vào các cổng TCP 139 và 445 phải được hạn chế dựa trên vai trò và yêu cầu. Việc liệt kê các tài khoản SAM phải được vô hiệu hóa bằng cách sử dụng Chính sách bảo mật cục bộ > Chính sách cục bộ > Tùy chọn bảo mật
3	Tôi	Mã JavaScript độc hại có thể được chạy để âm thầm thực hiện hoạt động độc hại. Một dạng của điều này là phản xạ mã lệnh chéo trang (XSS), xảy ra khi một ứng dụng web chấp nhận dữ liệu đầu vào của người dùng với mã hoạt động được nhúng và sau đó xuất nó vào một trang web sau đó được hiển thị cho người dùng. Điều này sẽ khiến mã do kẻ tấn công chèn được thực thi trên trình duyệt web của người dùng. Các cuộc tấn công XSS có thể được sử dụng để đạt được các kết quả như truy cập trái phép và đánh cắp thông tin xác thực, trong một số trường hợp có thể dẫn đến thiệt hại về uy tín và tài chính do công khai xấu hoặc tiền phạt. Như được thể hiện trong Phụ lục E.8, ứng dụng [khách hàng] dễ bị lỗ hổng XSS vì giá trị tên người dùng được hiển thị trên màn hình khi nỗ lực đăng nhập không thành công. Bằng chứng về khái niệm sử dụng tên người dùng được tạo độc hại được cung cấp trong Phụ lục E.	Xử lý tất cả dữ liệu đầu vào của người dùng như có khả năng bị nhiễm và thực hiện vệ sinh đúng cách thông qua lọc ký tự đặc biệt. Mã hóa đầy đủ tất cả đầu ra do người dùng kiểm soát khi hiển thị trên một trang. Không bao gồm tên người dùng trong thông báo lỗi của ứng dụng đăng nhập.

Bảng 1 - Phát hiện và khuyến nghị

Điều quan trọng là phải hiểu rằng những gì chúng ta xác định là mức độ nghiêm trọng của một vấn đề dựa trên điểm dễ bị tổn thương của nó không phải là rủi ro kinh doanh theo ngữ cảnh cụ thể. Nó chỉ đại diện cho mức độ nghiêm trọng về mặt kỹ thuật, ngay cả khi chúng ta điều chỉnh nó dựa trên khả năng xảy ra. Chúng ta có thể phản ánh điều này trong các phát hiện của mình là mức độ nghiêm trọng về mặt kỹ thuật hoặc chúng ta có thể làm việc với nhóm rủi ro của khách hàng để hiểu được mức độ rủi ro kinh doanh phù hợp bằng cách bao gồm việc xem xét tác động kinh doanh riêng biệt đối với khách hàng.

Chúng ta có thể bắt đầu mô tả phát hiện của mình bằng một hoặc hai câu mô tả lỗ hổng là gì, tại sao nó nguy hiểm và kẻ tấn công có thể thực hiện được gì với nó. Điều này có thể được viết theo cách cung cấp cái nhìn sâu sắc về tác động tức thời của một cuộc tấn công. Sau đó, chúng tôi mô tả một số chi tiết kỹ thuật về lỗ hổng. Thường không cần phải đi sâu vào chi tiết; chỉ cần giải thích ở mức cơ bản về lỗ hổng là gì và cách khai thác nó. Mục đích là mô tả một khai thác phức tạp theo cách mà hầu hết các đối tượng kỹ thuật có thể hiểu được.

Chúng tôi cũng cần đưa vào bằng chứng để chứng minh lỗ hổng được xác định là có thể khai thác được, cùng với bất kỳ thông tin liên quan nào khác. Nếu điều này đơn giản, nó có thể được đưa vào trực tuyến theo mục đầu tiên ở trên. Nếu không, nó có thể được ghi lại trong phần phụ lục như được hiển thị trong mục thứ hai.

Sau khi giải thích chi tiết về lỗ hổng, chúng tôi có thể mô tả phát hiện cụ thể mà chúng tôi đã xác định được trong hệ thống hoặc ứng dụng. Chúng tôi sẽ sử dụng các ghi chú mà chúng tôi đã ghi lại trong quá trình thử nghiệm và ảnh chụp màn hình hỗ trợ chúng để cung cấp một bản tường trình chi tiết. Mặc dù đây là nhiều hơn một vài câu, chúng tôi sẽ muốn tóm tắt trong bảng và tham chiếu đến phần phụ lục để có mô tả đầy đủ.

Thực hành tốt là sử dụng ghi chú và ảnh chụp màn hình của chúng tôi để hướng dẫn người đọc cách chúng tôi đạt được kết quả từng bước. Ảnh chụp màn hình phải có lời giải thích ngắn gọn về những gì nó hiển thị. Chúng ta không nên dựa vào ảnh chụp màn hình để tự nói lên điều đó. Chúng ta nên trình bày tác động của lỗ hổng theo cách đóng khung mức độ nghiêm trọng của nó đối với khách hàng theo cách phù hợp và có liên quan trực tiếp đến doanh nghiệp hoặc ứng dụng.

Lời khuyên khắc phục phải đủ chi tiết để cho phép quản trị viên hệ thống và ứng dụng triển khai mà không có sự mơ hồ. Biện pháp khắc phục phải rõ ràng, súc tích và toàn diện. Biện pháp này phải đủ để loại bỏ lỗ hổng theo cách mà khách hàng có thể chấp nhận được và phù hợp với ứng dụng. Việc đưa ra biện pháp khắc phục quá mức, tốn kém không thể chấp nhận được hoặc không phù hợp về mặt văn hóa (ví dụ: không cho phép đăng nhập từ xa cho môi trường làm việc từ xa) sẽ dẫn đến việc bản sửa lỗi không bao giờ được triển khai. Cần phải hiểu rõ nhu cầu của khách hàng ở đây.

Có một số mục quan trọng khác cần ghi nhớ. Đầu tiên, nên tránh các giải pháp chung chung, thay vào đó là những giải pháp đi sâu vào chi tiết cụ thể của ứng dụng và doanh nghiệp. Thứ hai, các giải pháp lý thuyết không hiệu quả trong việc chống lại lỗ hổng. Đảm bảo rằng bất kỳ giải pháp nào được đưa ra đều có triển khai cụ thể và thiết thực. Cuối cùng, không nên xếp nhiều bước vào một giải pháp được đề xuất. Mỗi bước riêng biệt phải là giải pháp riêng của nó.

Phần Phát hiện và khuyến nghị kỹ thuật có thể sẽ là phần chính của báo cáo và thời gian cũng như công sức đầu tư vào việc viết phần này phải phản ánh được tầm quan trọng của nó.

Khi mô tả các phát hiện, chúng tôi sẽ trình bày phương tiện sao chép chúng, trong phần nội dung của báo cáo hoặc trong phần phụ lục. Chúng tôi cần chỉ ra chính xác ứng dụng bị ảnh hưởng ở đâu và cách kích hoạt lỗ hổng. Một bộ đầy đủ các bước để sao chép phát hiện nên được ghi lại bằng ảnh chụp màn hình. Điều này bao gồm các bước mà chúng tôi coi là hiển nhiên (chẳng hạn như chạy với quyền quản trị), vì những điều này có thể không rõ ràng đối với người đọc.

Chi tiết nên được chia thành hai phần:

1. URL/điểm cuối bị ảnh hưởng
2. Một phương pháp kích hoạt lỗ hổng

Nếu nhiều khu vực bị ảnh hưởng bởi lỗ hổng, chúng ta nên bao gồm tham chiếu đến từng khu vực. Nếu có nhiều vấn đề tương tự, thì thường có thể chấp nhận cung cấp các mẫu với lưu ý rằng đây không phải là những khu vực duy nhất xảy ra sự cố. Trong trường hợp sau, chúng tôi sẽ đề xuất biện pháp khắc phục có hệ thống.

5.2.7. Phụ lục, Thông tin bổ sung và Tài liệu tham khảo

Phần cuối cùng của báo cáo là phần Phụ lục . Những thứ nằm ở đây thường không phù hợp với bất kỳ nơi nào khác trong báo cáo hoặc quá dài hoặc quá chi tiết để đưa vào nội tuyến. Điều này bao gồm danh sách dài những người dùng bị xâm phạm hoặc các khu vực bị ảnh hưởng, các khối mã bằng chứng khái niệm lớn, phương pháp luận mở rộng hoặc các bài viết kỹ thuật, v.v. Một quy tắc tốt cần tuân theo là nếu cần thiết cho báo cáo nhưng sẽ làm gián đoạn dòng chảy của trang, hãy đưa nó vào phần phụ lục.

Chúng tôi có thể muốn đưa vào phần Thông tin bổ sung . Trong phần này, chúng tôi sẽ đưa vào những thứ có thể không cần thiết cho bài viết chính nhưng có thể cung cấp giá trị hợp lý cho khách hàng. Ví dụ bao gồm các bài viết mô tả lỗ hổng sâu hơn, các tiêu chuẩn cho khuyến nghị khắc phục mà khách hàng cần tuân theo và các phương pháp khai thác khác. Nếu không có gì có thể tạo ra đủ giá trị, thì không có lý do gì để nhất thiết phải đưa vào phần này.

Tài liệu tham khảo có thể là một cách hữu ích để cung cấp thêm thông tin chi tiết cho khách hàng trong các lĩnh vực không liên quan trực tiếp đến thử nghiệm mà chúng tôi đã thực hiện. Khi cung cấp tài liệu tham khảo, chúng tôi cần đảm bảo chỉ sử dụng các nguồn có thẩm quyền nhất và chúng tôi cũng nên đảm bảo trích dẫn chúng một cách chính xác.

Trong Module này, chúng tôi đã thảo luận về nhiều công cụ và phương pháp hữu ích khi chúng tôi viết báo cáo kiểm tra thâm nhập. Tuy nhiên, cũng giống như trong lĩnh vực kiểm tra thâm nhập, không có "một công cụ nào có thể thống trị tất cả" để viết báo cáo. Với số lượng lớn các công cụ báo cáo và ghi chú, chúng tôi khuyên bạn nên thử nghiệm chúng để tìm ra công cụ phù hợp với bạn và/hoặc khách hàng. Về lâu dài, điều này sẽ giúp việc viết báo cáo thoải mái và hiệu quả hơn cùng một lúc.

Có nhiều khía cạnh chúng ta cần ghi nhớ trong quá trình kiểm tra thâm nhập và ghi chú có thể được coi là một trong những khía cạnh quan trọng nhất. Chúng ta có thể làm việc với hàng nghìn máy tính, người dùng, ứng dụng, v.v. và việc ghi nhớ mọi thứ khi chúng ta tiến hành mà không có tài liệu là điều gần như không thể. Dành thời gian để ghi lại từng bước một cách kỹ lưỡng sẽ giúp chúng ta viết báo cáo tốt hơn vào cuối cùng. Nó cũng sẽ giúp bài kiểm tra thâm nhập của chúng ta hiệu quả hơn, cho phép chúng ta xem tài liệu trong khi thực hiện để xem những gì chúng ta đã làm thay vì lặp lại các bước.

Cuối cùng, chúng ta cần ghi nhớ ai sẽ đọc báo cáo. Mục tiêu là làm cho báo cáo hữu ích cho tất cả các đối tượng tiềm năng trong một tổ chức, cả kỹ thuật và không kỹ thuật. Chúng ta có thể làm điều này bằng cách chia báo cáo thành nhiều phần khác nhau, sử dụng các cấp độ ngôn ngữ kỹ thuật khác nhau trong mỗi phần. Điều này sẽ đảm bảo rằng mọi người đều có ý tưởng về kết quả thực sự của bài kiểm tra thâm nhập.

Phòng thí nghiệm

1. Chúng tôi thường viết Báo cáo kiểm tra xâm nhập cho ai?

A. The Head of Cybersecurity
B. The CIO
C. The Security Operations Center Analysts
D. All of the above

Trả lời

2. Báo cáo kiểm tra xâm nhập thường nên bắt đầu bằng phần nào?

Trả lời

3. Từ còn thiếu trong câu này là gì: Đảm bảo rằng bất kỳ giải pháp nào đưa ra đều có cách thực hiện cụ thể và _________.

Trả lời