🔏Access control vulnerabilities and privilege escalation

Server Side Vul

Access control là gì ?

Access control hay có thể gọi là authorization( cấp quyền) là cấp quyền cho ai hoặc cái gì thể thực các hành động riêng biệt hoặc truy cập tài nguyên mà họ yêu cầu. Thông thường ứng dụng web, access control phụ thuộc vào authentication và quản lý session:

Authentication: Nhận biết user và confirm rằng họ chính là họ
Quản lý Session: Nhận biết các HTTP request tiếp theo nào đang được yêu cầu bởi user đó
Accesss control: Xác định user được phép tiến hành 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à nghiêm trọng, nó phá vỡ quyền điều khiển vượt qua các kiểm soát từ đó có thể xem các thông tin nhạy cảm.

Vertical access controls

Nó có nghĩa là kiểm soát truy cập dọc.....có nghĩa là từ trên xuống dưới, từ cao nhất xuống thấp nhất.

Vertical access controls là cơ chế hạn chế quyền truy cập vào chức năng nhạy cảm không có sẵn cho các kiểu người dùng khác.

Với vertical access controls, các kiểu người dùng khác nhau có quyền truy cập vào các chức năng ứng dụ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 từ trên xuống có thể là cách 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ư tách biệt các nhiệm vụ và ít đặc quyền nhất.

Horizontal access controls

Nó có nghĩa là kiểm soát truy cập ngang...nghĩa là kiểm soát những quyền được cấp với những accout cùng cấp với mình như bạn không thể xem một vài thông tin private của người dùng khác.

Horizontal access controls là 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 đó.

Với điều khiển truy cập 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 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.

Context-dependent access controls

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 không đúng 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.

Broken access control

Vertical privilege escalation

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 người dùng không phải quản trị trên thực tế 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.

Unprotected functionality

Unprotect chức năng là cái cơ bản nhất mà kẻ tấn công có tấn công, leo thang đặc quyền theo chiều dọc phát sinh khi ứ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 của quản trị viên nhưng không được liên kết từ 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ụ như URL sau:

https://insecure-website.com/admin

Như ta đã thấy người dùng có thể truy cập tới admin mà không bị ngăn chặn bởi chức năng nào.

Điều này trên thực tế có thể được truy cập bởi bất kỳ người dùng nào, không chỉ những người dùng quản trị có liên kết đến chức năng trong giao diện người dùng của họ. Trong một số trường hợp, URL quản trị có thể được tiết lộ ở các vị trí khác, chẳng hạn như file robots.txt:

https://insecure-website.com/robots.txt

Lab: Unprotected admin functionality

Trong một số trường hợp, các function nhạy cảm không được bảo vệ mạnh nhưng nó được giấu đi bằng cách cung cấp cho một url khó đoán hơn, bởi vậy được gọi là bảo mật bằng cách che khuất. Thật ra chỉ ẩn đi các chức năng nhạy cảm chứ không cung cấp các quyền access thì người dùng vẫn có thể tìm ra được url bằng nhiều cách.

Ví dụ như một url sau có lưu trữ các function của admin:

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

Kẻ tấn công có thể không đoán được trực tiếp điều này. Tuy nhiên, ứng dụng vẫn có thể làm rò rỉ URL cho người dùng.

Ví dụ: URL có thể được tiết lộ trong JavaScript tạo giao diện người dùng dựa trên vai trò của người dùng- có nghĩa các file được load cùng giao diện người dùng:

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

Lab: Unprotected admin functionality with unpredictable URL

Parameter-based access control methods

Một số ứng dụng xác định quyền truy cập người dùng hoặc vai trò trong login và sau đó lưu trữ thông tin ở vị trí người dùng có thể control ( controllable) như là các trường ẩn, cookie hoặc các truy vẫn tham số hiện tại. Ứng dụng đưa ra các quyết định access control tiếp theo dựa trên giá trị đã gửi.

Ví dụ:

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

Cách tiếp cận này về cơ bản thì không an toàn bởi vì người dùng có thể chỉ cần sửa đổi giá trị và giành được quyền truy cập các function mà họ không được phép như là function admin.

Trong hai lab này thì lab thứ nhất khá dễ chúng ta chỉ cần thay đổi giá trị cookie của admin là true nhưng thực tế ngoài đời rất hiếm có trường hợp này, trong lab 2 thì khi mình gửi tài khoản và mật khẩu thì trường mỗi tài khoản sẽ có một roleid, nó là id của vai trò thì nếu có thể hãy thử từng id một để ra id của admin thì lúc đó chúng ta sẽ như một admin, hãy gửi các các như thay đổi email, đổi pass... để xem response là gì và từ đó khai thác nó.

Broken access control resulting from platform misconfiguration

Một số ứng dụng thực thi các access control ở layer nền tảng bằng cách restrict truy cập đến các URL và phương thức HTTP đặc biệt dựa trên vai trò của người dùng.

Ví dụ về một ứng dụng có câu hình như sau:

DENY: POST, /admin/deleteUser, managers

Quy tắc này từ chối quyền truy cập vào POST phương thức trên URL /admin/deleteUser, đối với người dùng trong nhóm người quản lý. Nhiều thứ có thể xảy ra sai trong tình huống này, dẫn đến việc bỏ qua kiểm soát truy cập.

Một số khung ứng dụng hỗ trợ các tiêu đề HTTP không chuẩn khác nhau có thể được sử dụng để ghi đè URL trong yêu cầu ban đầu, chẳng hạn như X-Original-URLvà X-Rewrite-URL.

Thường thì truy cập của người dùng vào những file như này nó sẽ báo lỗi 403 có nghĩa deny access. Nếu một trang web sử dụng các điều khiển front-end 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 đè URL qua tiêu đề yêu cầu, thì có thể bỏ qua các điều khiển truy cập bằng cách sử dụng một yêu cầu như sau:

POST / HTTP/1.1
X-Original-URL: /admin/deleteUser
...

Hoặc như này sẽ trả về status 403

GET /.git/ HTTP/1.1
Host: example.com

Nỗ lực bỏ qua này cũng sẽ trả về 403, vì URI không thay đổi và quy tắc vẫn áp dụng:

GET /.git/ HTTP/1.1
Host: example.com
X-Rewrite-URL: /.git/

Điều này sẽ bỏ qua hạn chế:

GET / HTTP/1.1
Host: example.com
X-Rewrite-URL: /.git/

Lab: URL-based access control can be circumvented

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 request. Các điều khiển giao diện người dùng ở trên hạn chế quyền truy cập dựa trên URL và phương thức HTTP. Một số trang web có thể 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. Nếu kẻ tấn công có thể sử dụng GET(hoặc một phương thức khác) để thực hiện các hành động trên một URL bị hạn chế, thì chúng có thể phá vỡ kiểm soát truy cập được triển khai ở lớp nền tảng.

Lab: Method-based access control can be circumvented

Horizontal privilege escalation

Sự 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, thay vì tài nguyên của chính họ thuộc loại đó. Ví dụ: nếu một nhân viên chỉ có thể truy cập hồ sơ việc làm và bảng lương của họ, nhưng trên thực tế cũng có thể truy cập hồ sơ của các nhân viên khác, thì đây là sự 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ự để leo thang đặc quyền theo chiều dọc. Ví dụ: thông thường người dùng có thể truy cập trang tài khoản của họ bằng URL như sau:

https://insecure-website.com/myaccount?id=123

Bây giờ, nếu kẻ tấn công sửa đổi id giá trị tham số 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, với dữ liệu và chức năng được liên kết.

Cái này thường xảy ra ở những trang web trường học nếu không được xác thực id, cái này thật sự là một lỗ hổng lớn...

Lab: User ID controlled by request parameter

Một số ứng dụng khác, tham số có thể khai thác không có giá trị có thể dự đoán được.

Ví dụ: thay vì một số tăng dần, một ứng dụng có thể sử dụng số nhận dạng duy nhất trên toàn cầu (GUID) để xác định người dùng. Ở đây, kẻ tấn công có thể không đoán hoặc dự đoán được mã định danh cho người dùng khác. Tuy nhiên, các GUID của người dùng khác có thể được tiết lộ ở nơi khác trong ứng dụng nơi người dùng được tham chiếu, chẳng hạn như tin nhắn hoặc bài đánh giá của người dùng.

/?studentID=ss343i-k80kg-hf54-80d2-0489dedc

Lab: User ID controlled by request parameter, with unpredictable user IDs

Một số trường hợp, ứng dụng phát hiện khi nào người dùng không được phép truy cập tài nguyên và trả về chuyển hướng đến trang đăng nhập. Tuy nhiên, response có chứa chuyển hướng vẫn có thể bao gồm một số dữ liệu nhạy cảm thuộc về người dùng được nhắm mục tiêu, vì vậy cuộc tấn công vẫn thành công.

Lab: User ID controlled by request parameter with data leakage in redirect

Horizontal to vertical privilege escalation

Thông thường, một cuộc tấn công leo thang đặc quyền theo chiều ngang có thể được chuyển thành một cuộc tấn công leo thang đặc quyền theo chiều dọc, bằng cách làm ảnh hưởng đến người dùng có đặc quyền hơn. Ví dụ: leo thang theo chiều ngang có thể cho phép kẻ tấn công đặt lại hoặc lấy mật khẩu của người dùng khác. Nếu kẻ tấn công nhắm mục tiêu người dùng quản trị và xâm phạm tài khoản của họ, thì họ có thể có quyền truy cập quản trị và do đó thực hiện leo thang đặc quyền theo chiều dọc.

Ví dụ: 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 bằng cách sử dụng kỹ thuật giả mạo tham số đã được mô tả cho việc leo thang đặc quyền theo chiều ngang:

https://insecure-website.com/myaccount?id=456

Nếu người dùng mục tiêu là quản trị viên ứng dụng, thì kẻ tấn công sẽ có quyền truy cập vào trang tài khoản quản trị. Trang này có thể tiết lộ mật khẩu của quản trị viên hoặc cung cấp phương tiện thay đổi mật khẩu hoặc có thể cung cấp quyền truy cập trực tiếp vào chức năng đặc quyền.

Lab: User ID controlled by request parameter with password disclosure

Insecure direct object references (IDOR)

Tham chiếu đối tượng trực tiếp không an toàn (IDOR) là một loại lỗ hổng kiểm soát truy cập phát sinh khi ứng dụng sử dụng đầu vào do người dùng cung cấp để truy cập trực tiếp các đối tượng. Thuật ngữ IDOR đã được phổ biến khi nó xuất hiện trong Top 10 OWASP 2007. Tuy nhiên, đó chỉ là một ví dụ về nhiều sai lầm khi triển khai kiểm soát truy cập có thể dẫn đến việc kiểm soát truy cập bị phá vỡ. Các lỗ hổng IDOR thường liên quan đến việc leo thang đặc quyền theo chiều ngang, nhưng chúng cũng có thể phát sinh liên quan đến leo thang đặc quyền theo chiều dọc.

Lỗ hổng IDOR với tham chiếu trực tiếp đến các đối tượng cơ sở dữ liệu

Hãy xem xét một trang web sử dụng URL:

https://insecure-website.com/customer_account?customer_number=132355

Nếu không có các biện pháp kiểm soát nào khác, kẻ tấn công có thể chỉ cần sửa đổi giá trị customer_number, bỏ qua các kiểm soát truy cập để xem hồ sơ của các khách hàng khác. Đây là một ví dụ về lỗ hổng IDOR dẫn đến leo thang đặc quyền theo chiều ngang.

Lỗ hổng IDOR với tham chiếu trực tiếp đến các tệp tĩnh

Các lỗ hổng IDOR thường phát sinh khi các tài nguyên nhạy cảm nằm trong các tệp tĩnh trên hệ thống tệp phía máy chủ. Ví dụ: một trang web có thể lưu các bản ghi tin nhắn trò chuyện vào đĩa bằng cách sử dụng tên tệp tăng dần và cho phép người dùng truy xuất các bản ghi này bằng cách truy cập vào một URL như sau:

https://insecure-website.com/static/121.txt

Khi đó kẻ tấn công có thể chỉ cần sửa đổi tên tệp để truy xuất bản ghi do người dùng khác tạo và có khả năng lấy được thông tin đăng nhập của người dùng và dữ liệu nhạy cảm khác.

Lab: Insecure direct object references

Access control vulnerabilities in multi-step processes

Nhiều trang web thực hiện các chức năng quan trọng qua một loạt các bước.

Ví dụ: chức năng quản trị để cập nhật chi tiết người dùng có thể bao gồm các bước sau:

Tải biểu mẫu có chứa thông tin chi tiết cho một người dùng cụ thể.
Gửi các thay đổi.
Xem lại các thay đổi và xác nhận.

Đôi khi, một trang web sẽ thực hiện các biện pháp kiểm soát truy cập nghiêm ngặt đối với một số bước này, nhưng lại bỏ qua những bước khác.

Ví dụ: giả sử các điều khiển truy cập được áp dụng chính xác cho bước đầu tiên và bước thứ hai, nhưng không áp dụng cho bước thứ ba. Về mặt hiệu quả, trang web giả định rằng người dùng sẽ chỉ đạt được bước 3 nếu họ đã hoàn thành các bước đầu tiên, được kiểm soát đúng cách. Tại đây, kẻ tấn công có thể truy cập trái phép vào chức năng bằng cách bỏ qua hai bước đầu tiên và trực tiếp gửi yêu cầu cho bước thứ ba với các tham số bắt buộc.

Lab: Multi-step process with no access control on one step

Referer-based access control

Một số trang web kiểm soát quyền truy cập dựa trên Refererheader được gửi trong HTTP requesr. Referer header thường được thêm vào các yêu cầu của trình duyệt để cho biết trang mà từ đó một yêu cầu được bắt đầu.

Ví dụ: giả sử một ứng dụng thực thi mạnh mẽ quyền kiểm soát truy cập đối với trang quản trị chính tại /admin, nhưng đối với các trang phụ, chẳng hạn như /admin/deleteUser chỉ kiểm tra Referer Header. Nếu Referer Header chứa /adminURL chính, thì yêu cầu được cho phép.

Trong tình huống này, vì Refererkẻ tấn công có thể kiểm soát hoàn toàn header, chúng có thể giả mạo các yêu cầu trực tiếp đến các trang con nhạy cảm, cung cấp Refererheader bắt buộc và do đó có được quyền truy cập trái phép.

Lab: Referer-based access control

Cách ngăn chặn các lỗ hổng access control

Các lỗ hổng access control nói chung có thể được ngăn chặn bằng cách thực hiện cách tiếp cận chuyên sâu về phòng thủ và áp dụng các nguyên tắc sau:

Không bao giờ chỉ dựa vào obfuscation để kiểm soát truy cập.
Trừ khi một tài nguyên được thiết kế để có thể truy cập công khai, hãy từ chối quyền truy cập theo mặc định.
Bất cứ khi nào có thể, hãy sử dụng một cơ chế toàn ứng dụng để thực thi các biện pháp access control.
Ở cấp độ code, bắt buộc các nhà phát triển phải khai báo quyền truy cập được phép cho mỗi tài nguyên và từ chối quyền truy cập theo mặc định.
Kiểm tra kỹ lưỡng và thử nghiệm các biện pháp kiểm soát truy cập để đảm bảo chúng đang hoạt động như thiết kế.

Tổng kết

Cảm ơn các bạn đã đọc bài viết của mình! Những bài viết trên mình đều vừa học và dựa theo PortSwign.

PreviousFile upload vulnerabilities NextBusiness logic vulnerabilities

Last updated 1 year ago