Penetration Testing Step 3 – Tấn công access control theo phương ngang với horizontal privilege escalation

Như đã đề cập trong nội dung Penetration Testing Step 3 – Authorization và những ngả đường của vertical privilege escalation, horizontal privilege escalation thường liên quan đến tình huống người dùng giở trò để truy cập vào một tập con của cùng một loại tài nguyên hệ thống thuộc về người dùng khác. Về nguyên lý, các chiêu trò trong tình huống này cũng có nhiều điểm tương đồng với vertical privilege escaltion (tất nhiên, phương thức triển khai cụ thể để chấm mút sẽ có một số khác biệt như các nội dung demo minh họa bên dưới).

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. Kiểm soát user id thông qua request parameter

#1.1 Kiểm soát user id dạng dễ đoán

Không nói nhiều, tôi vào việc luôn. Với Burp Suite Intercept đã bật, tôi thử login vào hệ thống và truy cập vào my account page. Tại đây tôi có thể quan sát thấy user id (“wiener” trong trường hợp này) xuất hiện kiểu parameter trong URL như bên dưới.

Tôi túm cái request này quăng qua Burp Suite Repeater.

Sau đó, tôi đổi id parameter thành nạn nhân “carlos” và thử gửi lại request. Và thật không thể tin được, cứ như thế tôi xông vào tóm gọn API key của nạn nhân rồi tha hồ tung tóe.

#1.2 Kiểm soát user id dạng khó đoán

Tôi chuyển sang kịch bản đỡ thô bỉ hơn khi parameter không còn dễ đoán như kiểu user id ở trên. Lúc này, hệ thống có thể triển khai một số giải pháp như kiểu Globally Unique Identifiers – GUIDs (đại khái là kiểu chuỗi ký tự nhận diện độc nhất) để xác định người dùng. Và khi không thể đoán được user id, tôi sẽ thử chuyển hướng đào bới thông tin ở đâu đó để đút vào parameter như ví dụ sau đây.

Trong tình huống minh họa này, tôi lê la trên hệ thống để tìm và truy cập vào một bài blog của nạn nhân (tất nhiên, lại là “carlos”).

Với 1 cú click chuột vào tên nạn nhân, tôi đã nhanh chóng xác định được cái GUID tương ứng cho “carlos”: b33bf6e4-905a-4528-b984-2d39cb8a4cd9.

Quá trình tiếp theo tương tự như phần demo trước đó. Tôi truy cập vào hệ thống với account của mình để lấy cái request tương ứng đến my account page.

Rồi đẩy hàng qua Burp Suite Repeater và thay đổi cái GUID để hốt hàng API Key của nạn nhân như bên dưới.

#1.3 Kiểm soát user id dựa vào việc rò rỉ dữ liệu trong quá trình redirect

Tôi tiếp tục chuyển sang một tình huống xử lý tốt hơn. Lúc này ngay khi giở trò bẩn bựa giả danh người khác (thông qua việc thay đổi id parameter), tôi sẽ bị redirect (chuyển hướng) về vị trí login. Đây là bước xử lý hợp lý nếu không để xảy ra việc rò rỉ dữ liệu kiểu như ví dụ minh họa sau đây.

Trước hết, tôi cũng bật Burp Suite Interception lên và đăng nhập vào với credential chính chủ wiener:peter.

Sau đó, tôi cũng đẩy hàng sang Burp Suite Repeater.

Tại đây, tôi lại chơi trò giả danh bằng cách đổi id sang nạn nhân “carlos” và nhận response redirect về trang chủ. Vấn đề ở đây là mấy đại ca quản lý hệ thống quá rộng rãi khi kèm theo cho tôi cái API key của nạn nhận ngay trong cái response này.

#2. Đổi trắng thay đen từ horizontal sang vertical privilege escalation

Giờ tôi chuyển sang một kịch bản thú vị hơn khi sử dụng horizontal privilege escalation làm bàn đạp để chuyển sang vertical privilege escalation nhằm ăn các con mồi to béo hơn.

Vẫn dựa vào việc kiểm soát user id thông qua request parameter, với Burp Suite Interception bật sẵn, tôi truy cập vào hệ thống với credential chính chủ (wiener:peter). Tuy nhiên, lần này có một điểm thú vị xuất hiện ở trị trí update password với password đã được điền sẵn (nhưng đã bị che lại).

Tôi nhảy qua Burp Suite Proxy History xem thử và dễ dàng đọc được cái password đã bị che bên phía response (“peter” trong trường hợp này).

Đẩy hàng sang Burp Suite Repeater và lại giở trò mạo danh cán bộ với thiết lập id=administrator. Send request đi và soi kèo response, cái password của cán bộ administrator hiện ra chói lòa trong đôi mắt đầy dã tâm của tôi…

#3. Triển khai horizontal privilege escalation với Insecure Direct Object References

Insecure Direct Object References – IDOR (tạm dịch là phương thức tham chiếu kém bảo mật trực tiếp đến đối tượng) là nhánh con trong nhóm khai thác lỗ hổng của access control. IDOR có thể liên quan đến cả 2 dạng horizontal privilege escalation và vertical privilege escalation. Con hàng này có thể xuất hiện khi ứng dụng sử dụng user-supplied input (kiểu thông tin đầu vào do người dùng cung cấp) để truy cập trực tiếp vào các đối tượng. Và lúc này attacker có thể can thiệp chỉnh sửa input để giở trò truy cập trái phép. IDOR có thể có nhiều dạng, ví dụ:

• Direct reference to database objetcs: Kiểu này cho phép query để hốt thông tin từ back-end database với URL phù hợp ví dụ như https://insecure-website.com/customer_account?customer_number=132355. Lúc này, attack có thể thử vận may bằng cách thay đổi customer_number để thoát khỏi vòng kiểm soát của access control và truy cập trái phép vào dữ liệu của người dùng khác;
• Direct reference to static file: Với dạng này ứng dụng có thể lưu giữ các thông tin nhạy cảm trong static file phía server side filesystem và cho phép người dùng truy cập với URL phù hợp.

Rồi, giờ tôi vô phần minh họa dạng thứ 2 liền cho rõ. Lần này sẽ mới lạ hơn khi tôi bắt đầu thử với cái Live chat và gửi một cái message vớ vẩn như sau.

Với tùy chọn View transcript tôi soi cái text file xuất hiện với tên được đánh số (2.txt).

Điều này cho thấy có thể ứng dụng đánh số transcript cho các người dùng khác nhau và tôi có thể soi thử coi mấy cha user khác có mần ăn gì trong live chat không. Để làm việc này, tôi chọn lại View transcript với Burp Suite Interception đang bật và túm cái request tương ứng để download file. Kế đến, tôi thử chỉnh lại chỗ GET /download-transcript tương ứng sang 1.txt sau đó đẩy request đi.

Lúc này ứng dụng trả hàng về cho tôi file 1.txt đầy hứa hẹn.

Và không nằm ngoài mong đợi, nội dung file này chứa đựng thông tin nhạy cảm (password trong trường hợp này) của người dùng khác (tất nhiên, “carlos” chứ còn ai nữa) để cho phép thực hiện hành vi chiếm đoạt tài khoản của nạn nhân.