NỘI DUNG
Tiếp theo nội dung Penetration Testing Step 3 – Tấn công access control theo phương ngang với horizontal privilege escalation, kỳ này tôi sẽ chuyển sang các kịch bản còn lại trong công cuộc khai thác lỗ hổng của phần Authorization/Access Control với multi-step processes (đại khái là các quá trình xử lý có nhiều bước).
Với kịch bản này, cơ sở để giở trò đâm thọt thành công là hệ thống sẽ “quên” (hoặc có nhớ nhưng sử dụng giải pháp không đủ mạnh) bảo vệ, che chắn một trong số các step (bước) của multi-step processes, từ đó tạo điều kiện cho tôi tìm và “gãi đúng chỗ ngứa” của mục tiêu.
Với tinh thần nói trên, nội dung tôi giới thiệu hôm nay cũng sẽ tương đối nhẹ nhàng hơn các kỳ trước đó. Thay vì giới thiệu lê thê bối cảnh lịch sử, động cơ và quá trình gây án từ đầu đến đít, tôi sẽ chơi cheat code dựa vào nguồn tin mật để có dữ liệu cần thiết rồi xả đạn chính xác vào đúng yếu điểm của hệ thống.
Lưu ý:
- Như mọi khi, tôi cũng sẽ tận dụng các bài Lab dựng sẵn của ông PortSwigger để tiết kiệm thời gian dàn cảnh;
- Thông tin liên quan đến Burp Suite bạn có thể xem nội dung Penetration Testing Step 3 – 6 điều bạn nên biết trước khi xài tool khủng Burp Suite;
- Chi tiết việc sử dụng Burp Suite Repeater bạn có thể xem trong nội dung Penetration Testing Step 3 – Thủ thuật chọc ngoáy HTTP/WebSockets message với Burp Suite Repeater;
#1. Hệ thống “quên” triển khai access control cho một bước trong multi-step proceses
Trong kịch bản này, hệ thống tồn tại Admin panel với tính năng thay đổi user role theo kiểu multi-step processes. Vấn đề ở đây là ở bước gửi request thay đổi user role, mấy cụ quản lý hệ thống quen béng việc triển khai access control để kiểm tra coi mấy con hàng user gửi request có đủ thầm quyền không hay chỉ là đám giả danh cán bộ (admin) để giở trò bẩn bựa.
Và như giới thiệu ở phần đầu, tôi sẽ chơi cheat code để có admin credential phục vụ quá trình demo mì ăn liền.
Rồi, tôi vào việc đây. Với credential admin chính chủ, tôi xông vào tham quan địa bàn thử. Tại Admin panel, tôi thử tính năng Upgrade user để buff cho ông “carlos” từ user thường lên boss thử.
Sau đó, tôi túm cái request thay đổi user role tương ứng quăng qua Burp Suite Repeater để chuẩn bị cho bước tiếp theo.
Trong một diễn biến khác, tôi mở thêm một private/incognito browser window và login với credential hạng ruồi (“wiener:peter” như mọi khi).
Với các session cookie của user thường (“wiener”) thu được bên phần response ở trên, tôi thử giở trò bằng cách cập nhật cookie và username vào cái request bên Burp Suite Repeater.
Ý tưởng cơ bản của tôi ở đây là kiểm tra xem với session cookie của user thường và cái request “văn mẫu” để upgrade user có sẵn bên Burp Suite Repeater, liệu tôi có thể tự lăng xê nâng cấp cho bản thân lên user “không thường” hay không.
Và ngạc nhiên chưa, response 302 trả về nuột nà không tì vết cho biết tôi đã thành công với mưu đồ nâng cấp “lậu” user role.
#2. Điểm huyệt hệ thống sử dụng referer-based access control
Chuyển sang tình huống tươi sáng hơn một tí khi hệ thống không quên access control trong bất kỳ bước nào của multi-step processes. Tuy nhiên, đâu đó bên trong quá trình xử lý, hệ thống triển khai access control dựa vào Referer header (dùng để cho biết request được khởi tạo từ page nào) của request. Và việc này có thể sẽ dẫn đến lỗ hổng chết người như phần demo minh họa sau đây.
Tương tự như phần trên, tôi cũng login bằng admin credential để thám thính Admin panel và thử chức năng Upgrade user.
Tôi cũng đẩy con hàng này sang Burp Suite Repeater để chuẩn bị cho các mưu đồ sắp tới.
Tiếp tục, tôi cũng mở private/incognito browser window và đăng nhập với credential của user thường (“wiener:peter”). Tại browser window này, nếu thử truy cập vô cái URL để thực hiện âm mưu lạm quyền Upgrade user (cái /admin-roles?username=carlos&action=upgrade
như ví dụ bên dưới), tôi sẽ bị mắng xối xả như sau.
Sau khi bình tâm xem xét, tôi quay trở lại cái request đã đẩy sang Burp Suit Repeater ở trên và nhận thấy sự khác biệt khi có xuất hiện Referer. Và với cái request mẫu này, tôi lại tiếp tục thử nghiệm thay đổi username và cái session cookie của user thường rồi chạy lại.
Và “Yes, again”, tôi lại thành công một lần nữa khi triển khai việc Upgrade user “lậu” trót lọt.
Trong trường hợp bạn còn thấy rối với tình huống trên thì để tôi tua chậm lại và diễn giải tóm lược cho rõ:
- Hệ thống bảo vệ chức năng Upgrade user role (với URL /admin-roles?username=carlos&action=upgrade) dựa vào Referer. Nếu request có Referer kiểu …/admin như trên thì được xem là “hợp vệ sinh” và hệ thống sẽ cho chạy Upgrade thả cửa (còn thiếu thì ăn chửi “Unauthorized” như bạn thấy ở phần trên);
- Để phá vỡ phương án bảo vệ này, tôi chôm cái request mẫu có sẵn Referer rồi điền vào chỗ trống các thông tin liên quan (Cookie, username) rồi tấn công hệ thống với request Upgrade user đểu.
Đến đây tôi cũng xin khép lại loạt bài giới thiệu sơ bộ về các phương án khai thác lỗ hổng của Authorization/Access Control. Hy vọng trong tương lai gần, tôi sẽ có thể quay lại chủ đề này với các nội dung demo ác chiến hơn khi tung combo phối hợp với các chiêu thức khác.
1 thought on “Penetration Testing Step 3 – Chọc ngoáy lỗ hổng access control trong multi-step processes”