2.4K 182 90

Đã đăng vào thg 12 6, 2022 8:55 SA 10 phút đọc

650

Access control vulnerability - Lỗ hổng kiểm soát truy cập (phần 2)

III. 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 dọc (Vertical access controls)

Nếu một người dùng thông thường có khả năng truy cập các chức năng mà vốn họ không được phép truy cập thì chúng ta sẽ gọi đó là lỗ hổng trong dạng kiểm soát theo chiều dọc (Vertical access controls). Chúng ta có thể hiểu cụm từ "theo chiều dọc" ở đây có nghĩa là dọc theo quyền truy cập, vai trò thấp có khả năng truy cập chức năng của vai trò cao hơn.

1. Thông qua thay đổi giá trị các tham số khiến người dùng bình thường có thể truy cập vào trang quản trị

Các ứng dụng web thường bao gồm các chức năng khác nhau dành cho tài khoản có vai trò khác nhau. Thông thường, tài khoản administrator là tài khoản có quyền cao nhất và có thể truy cập tất cả các tính năng trong hệ thống. Đối với người dùng thông thường sẽ không được phép truy cập một số tính năng nâng cao như xem cơ sở dữ liệu, thực hiện xóa tài khoản người dùng khác, ...

Ví dụ, một ứng dụng web có chức năng trang quản trị dành cho tài khoản administrator được truy cập qua URL như sau:

https://insecure-website.com/admin

Người dùng thông thường cũng có thể biết tới đường link này (Vô tình đoán được, hoặc dùng một số tools như Dirsearch, Gobusster, ...). Nếu lập trình viên không cài đặt quyền truy cập hợp lí, dẫn đến tất cả người dùng đều có thể truy cập đường dẫn này sẽ xảy ra hậu quả khó lường, bởi khi đó ai cũng là administrator!

Phân tích lab Unprotected admin functionality

Lab này có một trang quản trị admin không được bảo vệ chắc chắn, chúng ta cần truy cập và thực hiện xóa tài khoản carlos.

Một trong những việc làm đầu tiên khi thực hiện Pentest một trang web là tìm kiếm các thông tin hữu ích liên quan tới mục tiêu. Và một trong những tệp tin thường được đọc đầu tiên là robots.txt (Khi thực hiện quét các đường dẫn cũng có tệp tin này). Tệp robots.txt chủ yếu dùng để quản lý lưu lượng truy cập của trình thu thập dữ liệu vào trang web và thường dùng để ẩn một tệp khỏi Google. Đôi khi nó cũng chứa một số thông tin hữu ích.

Đọc file robots.txt của trang web bằng cách thêm /robots.txt vào sau URL:

Trang web hạn chế các bot crawl tới link nhạy cảm /administrator-panel - là đường dẫn tới trang quản trị admin.

Truy cập tới /administrator-panel:

Chúng ta thấy rằng hệ thống không thực hiện cài đặt quyền tốt tới từng vai trò của người dùng, dẫn đến bất kì ai đều có quyền truy cập vào đường dẫn này và thực hiện vai trò quản trị!

Xóa tài khoản carlos thôi:

Một số trang web thực hiện bảo vệ đường dẫn tới trang quản trị admin bằng việc không để lộ trong tệp robots.txt và đặt tên đường dẫn theo một cách khó đoán, chẳng hạn:

https://insecure-website.com/administrator-panel-somerandomcharacters_ah27ds7d

Với cách này kẻ tấn công sẽ không thể sử dụng các công cụ quét đường dẫn tìm ra trang này. Tuy nhiên, nếu đường dẫn được sử dụng trong một số code sẽ hiển thị cho người dùng trong source code (chẳng hạn Javascript), thông tin quan trọng vẫn có thể tiết lộ tới người dùng. Xem xét đoạn code sau:

<script>
var isAdmin = false;
if (isAdmin) {
	...
	var adminPanelTag = document.createElement('a');
	adminPanelTag.setAttribute('https://insecure-website.com/administrator-panel-somerandomcharacters_ah27ds7d');
	adminPanelTag.innerText = 'Admin panel';
	...
}
</script>

Cách hoạt động của đoạn code trên: Kiểm tra vai trò người dùng có phải quản trị viên hay không thông qua giá trị biến isAdmin, nếu đúng sẽ tạo và hiển thị từ Admin panel trên giao diện - đường dẫn tới trang quản trị. Và vô tình cũng đã để lộ đường dẫn này tới người dùng.

Phân tích lab Unprotected admin functionality with unpredictable URL

Lab này có một trang quản trị admin không được bảo vệ chắc chắn. Tuy đường dẫn được đặt tên để không thể bị quét ra nhưng nó bị lộ ở một nơi nào đó xung quanh trang web, chúng ta cần truy cập và thực hiện xóa tài khoản carlos.

Xem mã nguồn trang web bằng cách bấm tổ hợp phím Ctrl+U hoặc chuột phải và bấm chọn View page source:

Phát hiện đoạn code Javascript hoạt động để lộ đường dẫn tới trang quản trị là /admin-pwyhr4.

Truy cập trang quản trị:

Xóa tài khoản carlos thôi:

Một số trang web thực hiện kiểm tra vai trò quản trị của người dùng thông qua các tham số được truyền lên hệ thống. Ví dụ:

https://insecure-website.com/login/home.jsp?admin=true
https://insecure-website.com/login/home.jsp?roleAdmin=1

Tuy nhiên kẻ tấn công có thể thực hiện chỉnh sửa các tham số này qua các công cụ, chẳng hạn với Burp Suite.

Phân tích lab User role controlled by request parameter

Miêu tả đề bài cho biết trang quản trị tại /admin và hệ thống xác định vai trò quản trị thông qua tham số trong cookie. Chúng ta cần nâng quyền người dùng wiener:peter lên quyền admin và thực hiện xóa tài khoản carlos.

Đăng nhập với tài khoản wiener:peter, quan sát request qua Burp Suite ta có:

Hệ thống xác định vai trò quản trị của người dùng qua tham số Admin trong Cookie. Chúng ta có thể sửa đổi giá trị này thành Admin=true:

Truy cập tới /admin:

Xóa tài khoản carlos:

Có thể xem trực tiếp trên giao diện web bằng cách bấm chuột phải, chọn Show response in browser:

Ngoài ra, chúng ta xem xét thêm một trường hợp tương tự trong đó kẻ tấn công có thể thay đổi tham số truyền tới hệ thống quyết định vai trò quản trị của tài khoản người dùng.

Phân tích lab User role can be modified in user profile

Miêu tả đề bài cho biết trang quản trị tại /admin và nó chỉ cho phép các người dùng có giá trị roleid bằng 2 truy cập. Chúng ta cần nâng quyền người dùng wiener:peter lên quyền admin và thực hiện xóa tài khoản carlos.

Đăng nhập với tài khoản wiener:peter, quan sát request qua Burp Suite ta có:

Khác với lab trước, request không chứa các tham số cụ thể xác định vai trò quản trị viên.

Cũng không thể truy cập tới trang quản trị:

Do đề bài cho biết hệ thống sử dụng tham số roleid để xác định vai trò người dùng, nên ta cần tìm cách "gửi kèm" giá trị này tới hệ thống với tài khoản wiener. Một cách tự nhiên, chúng ta sẽ lựa chọn thời điểm gửi tại thời điểm đăng nhập.

Quay lại request login, gửi tới Repeater (Ctrl+R), thêm tham số roleid=2 vào sau các tham số username và password:

Chọn Follow redirection:

Và ... chúng ta vẫn không thể trở thành admin. Tức là giá trị roleid cần truyền ở nơi khác. Tiếp tục thử một số cách truyền:

Truyền trực tiếp trong URL (phương thức GET):

Truyền trong Cookie:

Đều thất bại! Và chỉ còn chức năng Update email chúng ta chưa sử dụng tới. Thực hiện update một email mới và quan sát request:

Ohhhh, các bạn có thấy điều tôi thấy chứ! Email được POST lên hệ thống bằng kiểu định dạng JSON (hiểu đơn giản thì dữ liệu được định dạng theo từng cặp key:value, tìm hiểu thêm tại https://en.wikipedia.org/wiki/JSON). Và dữ liệu trả về cũng theo định dạng JSON và chứa cặp giá trị roleid:1. Mong muốn của chúng ta là thay giá trị roleid kia thành 2. Đơn giản, "cài cắm" nó vào giá trị email và gửi tới hệ thống thôi!

Thành công! Follow redirection ta có:

Truy cập trang quản trị:

Xóa tài khoản carlos:

Có thể xem trực tiếp trên giao diện web bằng cách bấm chuột phải, chọn Show response in browser:

2. Một số cách khác cho phép người dùng truy cập vào trang quản trị

Một số trang web sử dụng các framework cho phép các HTTP header nguy hiểm hoạt động như X-Original-URL, X-Rewrite-URL. Các header này cho phép ghi đè lên URL truy cập, từ đó có thể vượt qua lớp bảo vệ khỏi người dùng thông thường truy cập các chức năng cao hơn của hệ thống.

Ví dụ:

POST / HTTP/1.1
X-Original-URL: /administrater/some_sensitive_path
...

Khi hệ thống nhận được request này, do chấp nhận tiêu đề X-Original-URL nên sẽ thực hiện ghi đè và khiến người dùng truy cập trái phép tới /administrater/some_sensitive_path.

Một số web frameworks chịu ảnh hưởng từ lỗ hổng này có thể kể đến như: Symfony 2.7.0 đến 2.7.48, 2.8.0 đến 2.8.43, 3.3.0 đến 3.3.17, 3.4.0 đến 3.4.13, 4.0.0 đến 4.0.13 và 4.1.0 đến 4.1.2 , zend-diactoros từ 1.8.4 trở về trước, zend-http từ 2.8.1 trở về trước, zend-feed từ 2.10.3 trở về trước.

Phân tích lab URL-based access control can be circumvented

Miêu tả tình huống cho phép trang web có trang quản trị administrator với đường dẫn /admin. Hệ thống front-end đã thực hiện ngăn chặn các hành vi truy cập trái phép tới đường dẫn này, tuy nhiên, back-end server sử dụng framework cho phép tiêu đề X-Original-URL hoạt động. Nhiệm vụ của chúng ta là khai thác lỗ hổng này, truy cập tới trang quản trị hệ thống và xóa đi tài khoản của người dùng carlos.

Sau khi truy cập vào trang web, chúng ta nhận thấy giao diện home có dòng chữ Admin Panel dẫn tới trang quản trị tại đường dẫn /admin.

Khi truy cập chúng ta nhận được thông báo lỗi Access denied.

Xét về giao diện trả về khi chúng ta truy cập tới /admin, thử so sánh với một số lab chúng ta đã phân tích, chẳng hạn lab User role controlled by request parameter

Rõ ràng phần giao diện trả về khác nhau hoàn toàn, chúng ta sẽ cùng phân tích kĩ hơn qua giao diện response trong Burp Suite, đôi với lab User role controlled by request parameter, Response trả về như sau:

Đối với lab hiện tại URL-based access control can be circumvented, Response trả về qua Burp Suite (khi truy cập /admin):

Với hai status code khác nhau:

401 Unauthorized: Người dùng chưa xác thực.
403 Forbidden: Người dùng không được phân quyền.

Từ những dấu hiệu này chúng ta có thể dự đoán rằng phản hồi Access denied trong lab này có thể được đưa ra từ hệ thống front-end.

Kiểm tra một số tiêu đề có được cho phép hay không. Tiêu đề X-Original-URL:

Với status code trả về là 404 Not Found, điều này chứng tỏ hệ thống back-end đang xử lý yêu cầu tìm kiếm nội dùng tới /some_path của chúng ta, tức là hệ thống cho phép tiêu đề X-Original-URL hoạt động.

Thực hiện ghi đè nội dung URL bằng tiêu đề X-Original-URL:

Status code trả về 200 OK chứng tỏ chúng ta đã thành công truy cập được trang quản trị.

Thực hiện xóa tài khoản người dùng carlos:

Bên cạnh đó, khi hệ thống không thực hiện kiểm tra một số phương thức HTTP Request từ người dùng cũng có thể mang đến một số rủi ro. Một method được coi là safe - an toàn khi nó không làm thay đổi trạng thái "sate" của server. Nói cách khác, an toàn là chỉ đọc mà không làm thay đổi bất kì điều gì.

Phân tích lab Method-based access control can be circumvented

Chúng ta được cung cập một tài khoản có vai trò administrator là administrator:admin giúp thu thập các thông tin hữu ích liên quan tới upgrade một tài khoản lên quyền quản trị viên. Chúng ta cần khai thác lỗ hổng trong HTTP reuqest method để upgrade tài khoản wiener:peter lên quyền admin.

Đăng nhập với tài khoản administrator:admin và quan sát trang quản trị Admin panel:

Tính năng cho phép chúng ta có thể upgrade hoặc downgrade vai trò của bất kì người dùng nào. Thử upgrade vai trò của của người dùng carlos và quan sát request trong Burp Suite:

Hệ thống gọi tới path /admin-roles và truyền lên hai tham số username=carlos&action=upgrade bằng phương thức POST. Lưu ý giá trị tại header Cookie session=gyIyALKqa3VgPiAYZobuGlCHj3SUt1yN được sử dụng để xác thực người dùng.

Mở một trình duyệt ẩn danh, đăng nhập với tài khoản wiener:peter để lấy seesion hiện tại của wiener:

Thay giá trị session của wiener vào session trong request upgrade role:

Chúng ta thu được thông báo "Unauthorized". Do hệ thống không thực hiện kiểm tra các HTTP request method từ người dùng, nên chúng ta có thể vượt qua lớp bảo vệ này bằng cách sử dụng HTTP request method POSTX:

Chúng ta thấy rằng hệ thống trả về thống báo "Missing parameter 'username'", điều này chứng tỏ chúng ta đã vượt qua cơ chế xác thực session. Thêm tham số username gửi tới hệ thống bằng cách sử dụng HTTP request method GET và thay giá trị username=wiener: