Access control vulnerability - Lỗ hổng kiểm soát truy cập (phần 3)
IV. Phân tích và khai thác các lỗ hổng trong dạng kiểm soát truy cập theo chiều ngang (Horizontal privilege escalation)
Nếu một người dùng thông thường A có khả năng truy cập vào các chức năng X dưới vai trò là người dùng thông thường B, chúng ta sẽ gọi đó là lỗ hổng trong dạng kiểm soát theo chiều ngang (Horizontal privilege escalation). Chúng ta có thể hiểu cụm từ "theo chiều ngang" ở đây có nghĩa là ngang hàng theo quyền truy cập, hai vai trò có quyền hạn bằng nhau (thường là hai người dùng thông thường) có khả năng truy cập chức năng dưới vai trò của người kia.
1. Lỗ hổng trong dạng kiểm soát truy cập theo chiều ngang qua các tham số xác định duy nhất người dùng
Bên cạnh cookie, session để xác thực danh tính người dùng, các hệ thống thường sử dụng các tham số với những giá trị duy nhất xác định duy nhất một người dùng. Bởi vậy, khi đã hiểu được quy luật hoạt động của các tham số này, kẻ tấn công có thể thay đổi giá trị của chúng để tìm kiếm lỗ hổng trong dạng kiểm soát truy cập theo chiều ngang. Chẳng hạn, xét URL sau:
https://insecure-website.com/my-account?id=123
Trang web chưa thực hiện phân quyền người dùng chặt chẽ, giá trị id ở đây hiển thị giao diện hồ sơ của người dùng mang số id là 123. Do giá trị này có thể thay đổi bởi người dùng nên kẻ tấn công có thể thay đổi giá trị của id chẳng hạn bắt đầu từ 1 đến 1000 để truy cập trái phép vào hồ sơ cá nhân của người dùng khác.
Phân tích lab User ID controlled by request parameter
Miêu tả đề bài cho biết lab này chứa lỗ hổng trong dạng kiểm soát truy cập theo chiều ngang. Mỗi người dùng có một giá trị API duy nhất, nhiệm vụ của chúng ta sẽ dựa vào lỗ hổng này để thu thập giá trị API của carlos và submit. Chúng ta được cung cấp một tài khoản hợp lệ wiener:peter.
Đăng nhập với tài khoản wiener:peter, hệ thống dẫn chúng ta tới hồ sơ người dùng chứa giá trị API:
Hiện tại thì URL chỉ tới path /my-account:
Click vào tùy chọn My account:
Chúng ta phát hiện URL có thêm tham số id=wiener. id mang giá trị là username của người dùng. Khi truyền lên hệ thống sẽ trả về giao diện hồ sơ tương ứng với giá trị tham số id. Bởi vậy chúng ta có thể thay đổi giá trị này thành id=carlos để xem thông tin trang cá nhân của carlos (chứa giá trị API key):
Submit giá trị API key tại Submit solution để hoàn thành lab này.
Thông thường, các tham số id sẽ mang giá trị ngẫu nhiên, chẳng hạn là một chuỗi gồm chữ số và chữ cái được sinh ngẫu nhiên xác định duy nhất người dùng. Ví dụ:
https://insecure-website.com/my-account?id=shfj794wjb124sh2j312
Chúng ta khó có thể đoán được hoặc thực hiện tấn công vét cạn giá trị id này. Tuy nhiên, chúng cũng có thể vô tình bị tiết lộ đâu đó tại trang web.
Phân tích lab User ID controlled by request parameter, with unpredictable user IDs
Miêu tả đề bài cho biết lab này tồn tại lỗ hổng trong dạng kiểm soát truy cập theo chiều ngang. Mã định danh người dùng GUIDs là một giá trị không thể đoán được, tuy nhiên chúng có thể được tìm thấy đâu đó xung quanh trang web. Chúng ta cần truy cập vào hồ sơ carlos là lấy được giá trị API key của anh ấy. Chúng ta được cung cấp một tài khoản hợp lệ wiener:peter.
Đăng nhập với tài khoản wiener:peter, hệ thống dẫn chúng ta tới hồ sơ người dùng chứa giá trị API:
Hiện tại thì URL chỉ tới path /my-account:
Click vào tùy chọn My account:
Chúng ta thấy giá trị id=bafcddab-be1b-4975-8789-d2bd2da08037 tương ứng với người dùng wiener. Đây là một giá trị sinh ngẫu nhiên hoặc được định nghĩa để người dùng không thể dự đoán được giá trị id của người dùng khác.
Khi truy cập vào cụ thể trang blog của người dùng khác, chúng ta có thể truy cập để xem danh sách các blog của tác giả:
Quan sát URL nhận thấy tham số userId có cùng dạng với id trong cá nhân của chúng ta. Có thể dự đoán id và userId có cùng giá trị. Nghĩa là điều này đã vô tình để lộ giá trị id của tác giả đó:
Như vậy, nếu người dùng carlos có đăng tải blog chúng ta có thể truy cập và thu thập giá trị id của anh ấy. Chúng ta thu được giá trị id của carlos là:
userId=id=c8d4e21f-4c7c-4313-b522-92d3d1060d59
Thay đổi giá trị tại trang cá nhân của chúng ta id=c8d4e21f-4c7c-4313-b522-92d3d1060d59 để truy cập vào hồ sơ carlos:
Submit giá trị API key tại Submit solution để hoàn thành lab này.
Trong một số trường hợp khi thực hiện tấn công lỗ hổng trong dạng truy cập kiểm soát theo chiều ngang, chúng ta có thể được redirect tới trang chủ hoặc trang login. Trong nhiều trường hợp thì chúng ta đã tấn công thành công dù bị chuyển hướng tới trang khác (Do các response vẫn được "bắt" thành công trong HTTP history của Burp Suite).
Phân tích lab User ID controlled by request parameter with data leakage in redirect
Miêu tả đề bài cho biết lab chứa lỗ hổng kiểm soát truy cập, trong đó một số thông tin nhạy cảm bị lộ trong phần thân của phản hồi chuyển hướng (redirect response). Chúng ta được cung cấp một tài khoản hợp lệ wiener:peter và cần tìm ra giá trị API key của người dùng carlos.
Đăng nhập với tài khoản wiener:peter, hệ thống dẫn chúng ta tới hồ sơ người dùng chứa giá trị API:
Hiện tại thì URL chỉ tới path /my-account:
Click vào tùy chọn My account:
Tương tự lab User ID controlled by request parameter, thay giá trị id=carlos. Tuy nhiên, chúng ta bị chuyển hướng tới trang login:
Quan sát HTTP history trong Burp Suite, request /my-account?id=carlos vẫn được hệ thống thực hiện và trả về response thành công.
Và chúng ta có được giá trị API key của carlos:
Submit giá trị API key tại Submit solution để hoàn thành lab này.
Sau khi phân tích ba tình huống trên, chắc chắn các bạn cũng nhận ra rằng lỗ hổng trong dạng truy cập kiểm soát theo chiều ngang dễ dàng xảy ra và phương thức tấn công cũng rất đơn giản phải không? Những giá trị id thực sự nguy hiểm nếu để người dùng có thể đoán được quy tắc định nghĩa của nó. Và nếu trong các giá trị được kẻ tấn công thay đổi, chứa giá trị id thuộc người dùng có vai trò quản trị, hoặc chứa những thông tin nhạy cảm có thể được lợi dụng, thì cuộc tấn công này có thể leo thang thành truy cập kiểm soát theo chiều dọc! Kẻ tấn công lập tức có thêm rất nhiều quyền hạn, càng làm tăng độ sức ảnh hưởng của dạng lỗ hổng này.
Phân tích lab User ID controlled by request parameter with password disclosure
Miêu tả đề bài cho biết trang cá nhân của người dùng trực tiếp chứa mật khẩu hiện tại ở dạng ẩn. Chúng ta cần khai thác lỗ hổng kiếm soát truy cập, thu thập mật khẩu tài khoản administrator và thực hiện xóa tài khoản người dùng carlos. Lab cung cấp một tài khoản hợp lệ là wiener:peter.
Đăng nhập với tài khoản wiener:pater, click vào tùy chọn My account, chúng ta được đưa tới trang cá nhân người dùng, trong đó chức năng đổi mật khẩu chứa mật khẩu người dùng ở dạng ẩn.
Tuy nhiên chúng ta có thể thấy được giá trị này bằng cách sử dụng công cụ Devtools của Google Chromes hoặc xem mã nguồn trang web.
Trong URL chứa tham số id=wiener. id mang giá trị là username của người dùng. Khi truyền lên hệ thống sẽ trả về giao diện hồ sơ tương ứng với giá trị tham số id. Thay đổi giá trị id=administrator trong URL và truyền lên hệ thống, kết quả hiển thị trang cá nhân của administrator và chúng ta thu được mật khẩu tài khoản admin.
Đăng nhập với tài khoản administrator:mrixl9l6yohau2e5r9mr và thực hiện xóa tài khoản carlos.
2. Lỗ hổng trong dạng kiểm soát truy cập theo chiều ngang - IDOR (Insecure direct object references)
IDOR (Insecure direct object references) - Tham chiếu đối tượng trực tiếp không an toàn, là một lỗ hổng bảo mật mà trong đó người dùng có thể truy cập và thay đổi dữ liệu của bất kỳ người dùng nào khác có trong hệ thống. IDOR từng xuất hiện tại OWASP 2007 Top 10 và bị đông đảo các hacker khai thác, IDOR cũng được xếp thứ 4 trong danh sách OWASP Top 10 lỗ hổng bảo mật web từ năm 2013. Tấn công này có thể xảy ra khi không có bất kỳ cơ chế xác thực nào cho phép attacker có thể sử dụng các tham chiếu này để đọc, thay đổi hay sử dụng dữ liệu trái phép. Có thể nói lỗ hổng IDOR là một hệ quả từ các lỗ hổng kiểm soát truy cập theo chiều dọc và theo chiều ngang.
Bên cạnh cách tấn công thay đổi giá trị tham số giống như các labs chúng ta đã phân tích trên. Lỗ hổng IDOR cũng có thể được khai thác bằng cách thay đổi giá trị trong các đường dẫn tĩnh (static) khi hệ thống không thực hiện phân quyền chặt chẽ. Chẳng hạn một số dữ liệu, thông tin tệp của người dùng được đặt tên một cách có quy luật, ví dụ:
https://insecure-website.com/static/12345.txt
Khi đó kẻ tấn công có thể thay đổi tên tệp để đọc được những nội dung thông tin thuộc quyền sở hữu từ người dùng khác.
Phân tích lab Insecure direct object references
Miêu tả đề bài cho biết trang web lưu trữ các lịch sử trò chuyện của người dùng và có thể truy cập thông qua các đường dẫn tĩnh. Chúng ta cần thu thập thông tin nhạy cảm từ các tệp dữ liệu này, tìm kiếm mật khẩu và truy cập vào tài khoản của người dùng carlos.
Giao diện trang web chứa chức năng Live chat.
Trong đó có thể tải về tệp lịch sử cuộc trò chuyện qua tùy chọn View transcript.
Click tùy chọn View transcript và quan sát request qua Burp Suite.
Đường dẫn tải về tệp lịch sử chat có tên 3.txt. Chúng ta có thể thay đổi giá trị tệp này để xem thông tin cuộc trò chuyện các tệp lịch sử khác. Cụ thể, tệp 1.txt chứa thông tin mật khẩu của người dùng carlos:
Truy cập vào tài khoản carlos:87f0piooi1u7gydkyzh4 để hoàn thành lab:
Các tài liệu tham khảo
©️ Tác giả: Lê Ngọc Hoa từ Viblo
All rights reserved
