Penetration Testing Step 3 – Thủ thuật chọc ngoáy HTTP/WebSockets message với Burp Suite Repeater

Kết thúc nội dung Penetration Testing Step 3 – Chi tiết về Proxy tab, trái tim của Burp Suite, coi như tôi đã giới thiệu xong các vị trí để bố trí và quan sát trận địa. Từ kỳ này trở đi, tôi sẽ bắt đầu mò mẫm với các vị trí tấn công của Burp Suite, hay cụ thể hơn là Repeater trong nội dung kỳ này.

Như tôi đã giới thiệu trong kỳ trước, từ vị trí Proxy tab, bạn sẽ có thấy có 2 nhóm đối tượng là HTTP history bao gồm lịch sử chấm mút với các HTTP message và WebSockets history tương ứng cho WebSockets message. Hôm nay tôi sẽ bàn về nguyên tắc xử lý 2 nhóm message này tại Repeater tab (phần demo tấn công cụ thể tôi sẽ sắp xếp trình bày sau).

Ngoài ra, một phần quan trọng khác cũng cần được đề cập là Repeater menu với các tùy chọn cho phép bạn tinh chỉnh cách hành xử liên quan của Burp Suite.

#1. Xử lý HTTP message với Repeater của Burp Suite

#1.1 Đẩy hàng HTTP request sang cho Repeater

Với HTTP message, để tấn công bằng Repeater, cách phổ biến nhất là chuột phải lên một item cụ thể (ví dụ item trong Proxy/HTTP history) để gọi Context Menu sau đó chọn Send to Repeater (hoặc dùng hot keys Ctrl-R).

Lúc này bạn sẽ thấy giao diện Burp Suite báo có hàng đến ở Repeater tab. Di chuyển sang đấy, bạn sẽ thấy giao diện kiểu như sau.

Với mỗi Repeater tab (ví dụ cái tab số 1 ở trên), bạn sẽ có thể:

• Kiểm soát việc chạy request và xem request history;
• Thay đổi target server để gửi request đến;
• Dùng HTTP message editor để chỉnh sửa request (parameters, method);
• Dùng HTTP message editor thể hiện response nhận được từ cái request cuối cùng.

Cụ thể, trong Request panel, bạn sẽ có thể thấy các tab con như Pretty/Raw phục vụ phần hiển thị, Params liên quan đến các thông số của request có thể thêm/xóa/sửa, Headers thể hiện các thông tin header mặc định gửi kèm theo request cũng cho phép thêm/xóa/sửa.

Ngoài việc sử dụng Context Menu để chuyển item từ HTTP history sang như nói trên, bạn cũng có thể mở một Repeater tab thủ công với “…” button rồi chọn HTTP (hoặc WebSocket) message option rồi nhập liệu request vào luôn.

Với phương án này, bạn sẽ cần cấu hình chi tiết thông tin (Host và Port đối với tùy chọn HTTP) bằng cách click edit button ở góc trên bên phải (vị trí ghi chú Target: Not specified).

#1.2 Mông má HTTP message request và xử lý các tab con trong Repeater

Bàn kỹ thêm về vấn đề mông má lại request, Repeater cho phép bạn chỉnh sửa thủ công từng HTTP message (hoặc WebSocket message) – ví dụ thay đổi parameters – rồi replay (chạy lại thông qua việc bấm Send button) để phân tích các response tương ứng nhằm xác định các input-based vulnerability hoặc xác nhận lại các vấn đề ghi nhận được từ quá trình thu thập thông tin/ scan trước đó.

Ngoài ra, bạn cũng cần lưu ý một nội dung khá thú vị trong Repeater là thay đổi request method cho HTTP request (ví dụ POST sang GET, lúc này toàn bộ paramaters trong request body sẽ tự động chuyển sang query string cho phép bạn đẩy đám này sang các tool khác có thể xử lý HTTP request). Chi tiết cụ thể như sau.

Chi tiết hơn về vấn đề replay, đúng như tên gọi, bạn có thể chạy lại bao nhiêu lần tùy thích (tất nhiên mỗi lần với một combo mông má khác nhau, chứ ai rỗi hơi đâu mà chạy lại 1 cái request hoài?!).

Khi chơi replay, Repeater cho phép bạn bố trí mỗi HTTP (hoặc WebSocket) message ở từng tab riêng và cho phép các thao tác sắp xếp và rà soát bao gồm:

• Mặc định, Burp Suite sẽ đặt tên các tab con trong Repeater theo thứ tự tăng dần là 1, 2, 3… Bạn có thể đặt tên tùy ý cho các tab con bằng cách double click vô tab header rồi cập nhật tương ứng (ví dụ tôi sửa thành 3^rd tab như minh họa bên dưới). Việc này sẽ giúp bạn nhanh chóng xác định tab liên quan trong các bước kiểm tra về sau (tất nhiên bạn phải rename hợp lý thì mới rà soát nhanh được);
• Cho phép di chuyển qua lại các tab con bằng “<” và “>” button;
• Cho phép Reorder các tab con bằng cách drag tab tương ứng (ví dụ khi bạn muốn nhóm các replay có tính chất tương tự nhau lại để dễ theo dõi);

#1.3 Có gì trong HTTP message response?

Sau khi chỉnh sửa lại request đáp ứng mưu đồ đen tối, bạn có thể bấm Send để chơi replay request đã chỉnh sửa và nhận lại thông tin response tương ứng.

Tại Respone panel, tùy thuộc kết quả trả về, bạn có thể thấy định dạng hiển thị Pretty/Raw, render bằng browser tích hợp của Burp Suite, và đôi khi có tùy chọn Follow redirection với response status code 302.

Nếu cần xem bằng extenal browser, bạn có thể chuột phải lên response tương ứng để gọi context menu sau đó chọn Show response in browser và lấy link tương ứng mở trên extenal browser.

#2. Xử lý WebSocket message với Repeater của Burp Suite

#2.1 WebSocket message vs HTTP message

Như tôi đã lưu ý ở trên, bạn có thể thấy việc xử lý WebSocket message có rất nhiều điểm tương đồng với HTTP message. Tuy nhiên, do bản chất khác nhau, việc xử lý WebSocket message cũng sẽ có một số điểm khác biệt.

Về cơ bản, WebSocket cũng được khởi tạo qua HTTP nhưng có khả năng duy trì kết nối với asynchronous communication theo cả 2 hướng. Vấn đề Synchronous communication và Asynchronous communication có thể tóm lược sơ bộ như sau:

• Synchronous communication: Tạm dịch là giao tiếp đồng bộ, yêu cầu bạn phản hồi gần như tức thời với thông tin nhận được để quá trình giao tiếp có thể tiếp tục. Ví dụ dễ hình dung là kiểu bạn giao tiếp bằng mồm với người khác. Sau khi nhận được câu hỏi của đối tác, nếu là vấn đề khó, bạn có thể ngâm đến khoảng 15 giây để suy nghĩ trước khi phản hồi. Nhưng nếu bạn cứ ngồi đực mặt ra không trả lời thì tình thế sẽ rất quái dị. Lúc này, cha kia sẽ nghĩ bạn không nghe rõ câu hỏi hoặc đang khinh ổng ra mặt. Và để tiếp tục cuộc trao đổi, tùy tình hình thực tế, có thể ổng sẽ nhắc lại câu hỏi một lần nữa hoặc tương dép vào mồm bạn. Quay lại vấn đế chính, cái HTTP nói trên sẽ theo kiểu Synchronous communication, trong đó khi client hỏi (request), server sẽ trả lời (response). Dựa trên thông tin phản hồi, client lại đưa ra request hoặc thông tin kế tiếp để có thể tiếp tục quá trình giao tiếp với server;
• Asynchronous communication: Tạm dịch truyền thông bất đồng bộ với hình dung đơn giản là kiểu email/tin nhắn cho phép bạn nhận rồi để đó trả lời sau, không nhất thiết phải phản hồi ngay như ví dụ giao tiếp bằng mồm 1 kèm 1 của Synchronous communication. Và đây cũng sẽ là kiểu WebSocket làm việc, nghĩa là nó cho phép duy trì kết nối kể cả trong tình huống cả 2 phía tạm thời không giao tiếp gì cả.

#2.2 Xử lý WebSocket message với Repeater

Cũng như HTTP message, bạn có thể chọn 1 WebSocket message (ví dụ từ Proxy/Websockets history) rồi chuột phải mở Context Menu và chọn Send to Repeater.

Và sau đó nhận hàng bên Repeater để thực hiện các đòn tấn công.

Tất nhiên, bạn cũng có thể dùng cách thứ 2 là bạn mở một Repeater tab thủ công (bằng “…” button) với WebSocket option rồi nhập liệu request vào luôn.

Với WebSocket message, tại mỗi Repeater tab, bạn sẽ có thể:

• Dùng WebSocket message editor để chỉnh sửa request;
• Dùng WebSocket connection để gửi message;
• Dùng History để xem tất cả message đã gửi và nhận.

Lưu ý: Để gửi WebSocket request, bạn cũng bấm Send button nhưng với điều kiện connection phải còn đang mở thông qua Burp Proxy (Tôi sẽ quay lại vấn đề này khi demo để dễ hình dung).

#3. Repeater options của Burp Suite

Ngoài các phần xử lý nói trên, Burp Suite cũng cho phép bạn thiết lập một số tùy chọn từ Repeater menu như sau.

Repeater menu cho phép bạn kiểm soát các thứ:

• Update Content-Length: Kiểm soát việc Burp Suite tự động cập nhập Content-Length header của request khi cần, đặc biệt hữu ích khi request message bao gồm body;
• Unpack GZIP / deflate: Kiểm soát việc Burp Suite tự động giải nén các nội dung GZIP nhận được trong respone;
• Follow redirections: Kiểm soát việc tự động theo dấu redirection response như tôi đề cập trong Mục 1.3. Nếu bạn không thiết lập tự động thì sẽ thấy xuất hiện Follow redirection button cho phép tùy chọn thủ công để xem xét kỹ từng request/response. Với lựa chọn manual redirection này, các cookies mới sẽ được xử lý với phần thiết lập Process cookies in redirections đề cập ngay bên dưới;
• Process cookies in redirections: Tùy chọn này cho phép bất kỳ cookies nào được thiết lập trong redirection response sẽ được resubmitted mỗi khi redirection target bị theo dấu;
• Enforce protocol choice on cross-domain redirections: Mặc định, Repeater sẽ thỏa thuận protocol với redirected cross-domain. Khi option này được chọn, Repeater sẽ follow cross-domain redirections với cùng protocol xác định trong Inspector > Request Attributes. Tùy chọn này sẽ rất hữu ích cho các bài test HTTP/2-specific vulnerabilities với cross-domain requests;
• Normalize HTTP/1 line endings: Mặc định, Repeater sẽ normalize (chuẩn hóa) HTTP/1 line endings bằng cách tự động thêm newline character (\n) vô các lines kết thúc bằng standalone carriage return (\r) để giảm rủi ro vô tình gửi invalid request. Khi test một số vulnerabilities ví dụ như request smuggling cần loại bỏ newline, bạn sẽ cần tắt tùy chọn này;
• Enable HTTP/2 connection reuse: Mặc định, Repeater sẽ sử dụng lại cùng connection cho multiple HTTP/2 requests. Trong tình huống server xử lý first request khác subsequent requests, bạn sẽ cần tắt tùy chọn này;
• Strip Connection header over HTTP/2: Mặc định, HTTP/2 request bao gồm một Connection header, Burp Suite sẽ cắt cái này trước khi gửi request đến server vì phần lớn HTTP/2 servers sẽ từ chối nếu request vẫn còn header này. Trường hợp bạn muốn thăm dò phản ứng của server thì có thể thử tắt thử option này;
• Action: Bao gồm các tùy chọn tương tự như context menu của request/response message editor.

Vâng tôi biết, ở đâu phọt ra cả đống thứ thuật ngữ trời ơi đất hỡi, đọc chả hiểu mịa gì. Tạm thời bạn cứ đọc qua rồi nhớ mang máng là được rồi. Khi vào đụng trận thực tế đụng mấy thứ liên quan tôi sẽ đề cập lại cho dễ hình dung hơn. Còn bữa nay thì nghỉ tại đây được rồi.