Access control vulnerabilities and privilege escalation
Trong phần này, thảo luận về lỗ hổng kiểm soát truy cập, miêu tả leo thang đặc quyền và các lỗ hổng phát sinh với loại lỗ hổng này,...
What is access control?
Access control (or authorization) là việc áp dụng các ràng buộc về việc ai đó hoặc cái gì đó có thể thực hiện các hành động truy cập tài nguyên mà họ đã yêu cầu. Trong ngữ cảnh của các ứng dụng web, kiểm soát truy cập phụ thuộc vào xác thực và quản lí phiên:
Xác thực đúng người dùng và xác nhận rằng họ đúng như họ nói.
Quản lí phiên, xác định những yêu cầu HTTP tiếp theo nào được thực hiện bởi người dùng đó.
Kiểm soát truy cập, xác định xem người dùng có được phép thực hiện hành động mà họ đang cố gắng thực hiện hay không.
Broken access controls là một lỗ hổng bảo mật thường gặp và thường nghiêm trọng. Thiết kế và quản lí các kiểm soát truy cập là một vấn đề phức tạp. Các quyết định kiểm soát truy cập do con người đưa ra chứ không phải do công nghệ và khả năng xảy ra lỗi rất cao.
Từ góc độ người dùng, các kiểm soát truy cập có thể được chia thành các loại sau:
Kiểm soát truy cập dọc
Kiểm soát truy cập ngang
Kiểm soát truy cập thuộc vào ngữ cảnh
Kiểm soát truy cập dọc
Kiểm soát truy cập theo chiều dọc là các cơ chế hạn chế quyền truy cập vào chức năng nhạy cảm không sẵn có của người dùng khác.
Kiểm soát truy cập theo chiều dọc, những loại người dùng khác nhau có quyền truy cập vào các chức năng khác nhau. Ví dụ: quản trị viên có thể sửa đổi hoặc xóa tài khoản của bất kì người dùng nào, trong khi người dùng bình thường không có quyền truy cập vào các hành động này. Kiểm soát truy cập theo chiều dọc có thể là triển khai chi tiết hơn của các mô hình bảo mật được thiết kế để thực thi các chính sách kinh doanh như phân chia nhiệm vụ và đặc quyền.
Kiểm soát truy cập ngang
Kiểm soát truy cập theo chiều ngang là các cơ chế hạn chế quyền truy cập vào tài nguyên đối với những người dùng được phép truy cập cụ thể vào các tài nguyên đó.
Kiểm soát truy cập theo chiều ngang, những người dùng khác nhau có quyền truy cập vào một tập hợp con các tài nguyên cùng loại. Ví dụ: một ứng dụng ngân hàng sẽ cho phép người dùng xem các loại giao dịch và thực hiện thanh toán từ tài khoản của chính họ chứ không phải tài khoản của bất kỳ người dùng nào khác.
Kiểm soát truy cập phụ thuộc vào ngữ cảnh
Kiểm soát truy cập phụ thuộc vào ngữ cảnh hạn chế quyền truy cập vào chức năng và tài nguyên dựa trên trạng thái của ứng dụng hoặc tương tác của người dùng với nó.
Kiểm soát truy cập phụ thuộc vào ngữ cảnh ngăn người dùng thực hiện các hành động sai thứ tự. Ví dụ: một trang web bán lẻ có thể ngăn người dùng sửa đổi nội dung trong giỏ hàng của họ sau khi họ đã thanh toán.
Leo thang đặc quyền theo chiều dọc
Nếu người dùng có thể có quyền truy cập vào chức năng mà họ không được phép truy cập thì đây là sự leo thang đặc quyền theo chiều dọc. Ví dụ: nếu trên thực tế, một người dùng không phải quản trị viên có thể có quyền truy cập vào trang quản trị nơi họ có thể xóa tài khoản người dùng, thì đây là sự leo thang đặc quyền theo chiều dọc.
Chức năng không được bảo vệ
Về bản chất, sự leo thang đặc quyền theo chiều dọc phát sinh khi một ứng dụng không thực thi bất kì biện pháp bảo vệ nào đối với chức năng nhạy cảm. Ví dụ: các chức năng quản trị có thể được liên kết từ trang chào mừng quản trị viên chứ không phải trang chào mừng của người dùng. Tuy nhiên, người dùng có thể chỉ cần truy cập các chức năng quản trị bằng cách duyệt trực tiếp đến URL quản trị có liên quan.
Ví dụ: một trang web có thể lưu trữ chức năng nhạy cảm tại : https://example.com/admin
Trên thực tế, điều này có thể được truy cập bởi bất kì người dùng nào. Trong một số trường hợp, URL này có thể được tiết lộ tại robots.txt hoặc, kẻ tấn công có thể sử dụng danh sách sẵn có để fuzzing.
Trong một số trường hợp, chức năng nhạy cảm không được bảo vệ mạnh sẽ mà được che giấu bằng cách cung cấp cho nó một URL khó dự đoán hơn, ví dụ : /admin-panel-xyz123. Tuy nhiên, ứng dụng vẫn có thể rò rỉ URL cho người dùng. Ví dụ: URL có thể được tiết lộ trong JS để xây dựng giao diện người dùng dựa trên vai trò của người dùng.
Thực hành lab: (Apprentice)
Nội dung lab: Unprotected admin functionality with unpredictable URL. Trang quản trị viên không được kiểm soát truy cập. Nhưng URL không thể đoán được, nhưng nó xuất hiện ở đâu đó trong ứng dụng.
Thực hiện lab:
Tìm hiểu chức năng của trang web. Nhận thấy đây là một trang web bán hàng, cho phép bạn xem chi tiết một sản phẩm.
Xem source code của trang web có đoạn code sau:
Đây là một URL dẫn đến trang quản trị admin, truy cập và xóa tài khoản để hoàn hành lab.
Parameter-based access control methods
Một số ứng dụng xác định vai trò hoặc quyền truy cập của người dùng khi đăng nhập, sau đó lưu trữ thông tin này ở vị trí do người dùng kiểm soát, chẳng hạn như trường ẩn, cookie hoặc tham số chuỗi truy vấn đặt trước. Ví dụ:
Cách tiếp cận này về cơ bản là không an toàn vì người dùng có thể chỉ cần sửa đổi giá trị và có quyền truy cập vào chức năng mà họ không được phép, chẳng hạn như các chức năng quản trị.
Thực hành lab: (Apprentice)
Nội dung lab 1: User role controlled by request parameter. Lab này có trang quản trị /admin, xác định quản trị viên bằng cách sử dụng cookie. Xóa người dùng carlos khi bạn có quyền truy cập trang admin để hoàn thành lab.
Thực hiện lab:
Khi truy cập URL /admin từ người dùng bình thường, bạn không có quyền truy cập. Bởi vì trang web quản trị người dùng bằng cách xác thực cookie:
Người dùng bình thường được set cookie Admin: false. Vậy đặt ra tình huống, sẽ ra sao nếu giá trị cookie này có thể thay đổi thành true ?
Thay đổi giá trị Admin: true. và xem kết quả:
Từ người dùng bình thường, giờ đây có thể truy cập vào trang quản trị admin. Xóa người dùng carlos để hoàn thành lab.
Nội dung lab 2: User role can be modified in user profile. Phòng thí nghiệm này có trang quản trị người dùng. Nhưng nó chỉ có thể truy cập đối với người dùng đăng nhập có roleid là 2.
Thực hiện lab:
Sử dụng Burp suite để bắt và sửa đổi request khi sửa đổi update email người dùng. Nhận thấy rằng những nội dung cập nhật được sửa đổi trong JSON. Vậy sẽ ra sao nếu ta thêm trường roleid:2 vào request.
Như vậy, ban đầu, người dùng wiener có roleid là 1 bây giờ được update thành 2. Và người dùng này bây giờ trở thành quản trị viên.
Broken access control resulting from platform misconfiguration
Một số ứng dụng thực thi kiểm soát truy cập ở lớp nền tảng bằng cách hạn chế quyền truy cập vào các URL và phương thức HTTP cụ thể dựa trên vài trò của người dùng. Ví dụ:
DENY: POST, /admin/deleteUser, managers
Quy tắc này từ chối quyền truy cập vào phương thức POST trên URL /admin/deleteUser đối với người dùng trong nhóm người quản trị. Một số khung ứng dụng hỗ trợ các tiêu đề HTTP khác nhau có thể được sử dụng để ghi đè URL trong yêu cầu ban đầu, chẳng hạn X-Original-URL và X-Rewrite-URL. Nếu một trang web sử dụng các biện pháp kiểm soát giao diện người dùng nghiêm ngặt để hạn chế quyền truy cập dựa trên URL, nhưng ứng dụng cho phép ghi đè UEEL thông qua tiêu đề thì có thể bypass access control trong TH này.
Thực hành lab :(Practitioner)
Nội dung lab: URL-based access control can be circumvented. Trang web này không xác thực người dùng truy cập đến trang /admin, nhưng hệ thống giao diện người dùng đã được cấu hình để chặn quyền truy cập bên ngoài đường dẫn đó. Nhưng back-end được xây dựng hỗ trợ tiêu đề X-Original-URL.
Thực hiện lab:
Truy cập trang /admin thì thấy bị từ chối không thể truy cập.
Gửi yêu cầu đến Repeater. Vì đề bài có gợi ý là back-end hỗ trợ tiêu đề
X-Original-URL. Vậy sẽ ra sao nếu chúng ta thêm tiêu đề này vào yêu cầu với URL là /admin ?
Vậy là ta có thể truy cập vào trang /admin bằng cách thêm tiêu đề
X-Original-URL. Tiến hành xóa người dùng carlos để hoàn thành lab
Một cuộc tấn công thay thế có thể phát sinh liên quan đến phương thức HTTP được sử dụng trong yêu cầu. Một số trang web chấp nhận các phương thức yêu cầu HTTP thay thế khi thực hiện một hành động. Vì vậy, kẻ tấn công có thể thay thế phương pháp HTTP để thực hiện hành động trên một URL bị hạn chế.
Thực hành lab: (Practitioner)
Nội dung lab: Method-based access control can be circumvented. Phòng thí nghiệm này triển khai biện pháp kiểm soát truy cập dựa trên phương thức HTTP. Nâng người dùng wiener từ người dùng lên quản trị viên để hoàn thành lab.
Thực hiện lab:
Đăng nhập với tư cách là quản trị viên. Thực hiện upgrade user và gửi request đến Repeater.
Đăng nhập với tư cách là người dùng bình thường : wiener. Copy cookie và dán vào yêu cầu upgrade user ở bước 1 và gửi yêu cầu.
Trang web trả về "Unauthorized". Thay đổi phương thức HTTP, và gửi lại request, trang web trả về "Missing parameter 'username'". Tiếp tục thay đổi sang phương thức GET bằng cách chọn Change request method. và gửi yêu cầu.
Broken access control resulting from URL-matching discrepancies
Khi định tuyến các yêu cầu đến thì các trang web có sự khác nhau về độ nghiêm ngặt của đường dẫn phải khớp với một điểm cuối đã xác định. Ví dụ: trang web có thể chấp nhận cách viết không nhất quán, do đó, /ADMIN/DELETEUSER vẫn có thể được ánh xạ tới /admin/deleteUser.
Leo thang đặc quyền theo chiều ngang
Leo thang đặc quyền theo chiều ngang phát sinh khi người dùng có thể có quyền truy cập vào tài nguyên thuộc về người dùng khác. Ví dụ: đáng lẽ một người dùng chỉ có thể truy cập vào trang cá nhân của họ, nhưng trên thực tế, người dùng đó lại có thể truy cập hồ sơ cá nhân của người dùng khác =>Đây là hành vi leo thang đặc quyền theo chiều ngang.
Các cuộc tấn công leo thang đặc quyền theo chiều ngang có thể sử dụng các loại phương pháp khai thác tương tự như theo chiều dọc. Ví dụ: người dùng có thể truy cập thông thường vào trang thài khoản của họ bằng cách sử dụng một URL sau:
Bây giờ, kẻ tấn công có thể sửa đổi giá trị tham số id thành giá trị của người dùng khác thì kẻ tấn công có thể có quyền truy cập vào trang tài khoản của người dùng khác.
Trong một số ứng dụng, tham số có thể khai thác có giá trị không thể dự đoán trước được. Tuy nhiên, nó lại có thể được tiết lộ ở nơi khác trong ứng dụng nơi người dùng được tham chiếu (thông báo, comment)
Trong một số trường hợp khác, ứng dụng sẽ phát hiện người dùng khi truy cập tài nguyên mà không được phép truy cập và trả về một chuyển hướng đến trang đăng nhập. Tuy nhiên, phản hồi chứa chuyển hướng vẫn có thể bao gồm một số dữ liệu nhạy cảm.
Last updated