Penetration Testing Step 3 – Authorization và những ngả đường của vertical privilege escalation

Kết thúc nội dung Penetration Testing Step 3 – Bypass hệ thống xác thực với chức năng reset password, tôi xin tạm gác lại câu chuyện về Authentication (xác thực). Và như tôi đề cập trong nội dung Penetration Testing Step 3 – Tấn công vào Authentication mechanisms liệu có khả thi?, sau khi qua ải Authentication, người dùng sẽ được cấp các quyền hạn phù hợp dựa vào kết quả của quá trình Authorization (thật ra sẽ có một phần đệm là Session Management để quản lý phiên “mần ăn” của người dùng đã vượt qua bước xác thực với hệ thống).

Authorization (phân quyền) hay Access control (kiểm soát truy cập) có thể hiểu (kiểu mì ăn liền) là quá trình kiểm soát hành động hoặc khả năng truy cập của các đối tượng vào tài nguyên của hệ thống. Và Access control có thể được phân chia thành các thể loại:

• Vertical access controls: Với dạng này, các loại người dùng khác nhau sẽ có khả năng truy cập vào chức năng khác nhau của ứng dụng. Ví dụ admin có quyền trảm user thường nếu thấy ngứa mắt và user thường có quyền chửi admin (bằng mồm) sau đó chấp nhận số phận;
• Horizontal access controls: Với dạng này, các người dùng khác nhau sẽ có quyền truy cập vào một tập con của một loại tài nguyên hệ thống nhất định. Ví dụ bạn có thể đăng nhập vào ứng dụng ngân hàng và xem chi tiết các giao dịch của mình nhưng (hiển nhiên) không được phép xem thông tin của người dùng khác;
• Context-dependent access controls: Dạng này tương đối phức tạp hơn vì tùy thuộc vào tình trạng của ứng dụng hoặc hành động của người dùng. Ví dụ dễ hình dung nhất của dạng này là với các ứng dụng shopping, bạn sẽ bị khóa khả năng chỉnh sửa đơn hàng một khi đã chốt đơn và thanh toán.

Như bạn thấy ở trên, câu chuyện về Authorization hay Access control khá dài. Do vậy, trong nội dung kỳ này, tôi sẽ chỉ tập vào phần thứ nhất của câu chuyện – các chiêu trò đâm thọc vào giải pháp Vertical access controls – nhằm đạt ý đồ vertical privilege escalation (tạm dịch là “leo thang đặc quyền theo phương thẳng đứng”).

Lưu ý:

• Chi tiết về việc triển Access control bạn có thể xem thêm trong Access control security models | Web Security Academy (portswigger.net);
• 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. Câu chuyện thứ 1 – Chủ nhà quên khóa cửa

#1.1 Khóa cửa chính mà quên cửa hậu

Kịch bản thô bỉ nhất của tình huống này là ứng dụng cho phép người dùng sử dụng các chức năng nhạy cảm của hệ thống (ví dụ chức năng quản lý người dùng của admin) chỉ bằng cách truy cập vào URL tương ứng (ví dụ dummytip.com/admin).

Cũng cần nói rõ thêm, việc bảo vệ các chức năng nhạy cảm bằng cách giấu đi URL liên quan cũng không phải là phương pháp an toàn vì attacker có thể triển khai các giải pháp dò tìm (cái này kiểu như trổ cửa ra vị trí bất thường và hi vọng kẻ trộm chỉ cắm đầu phá cửa chính mà không đi vài vòng để tìm cửa hậu).

Ngoài ra, một số nguồn (như file robots.txt) cũng có thể tiết lộ các URL thú vị khác. Ví dụ với tình huống minh họa sau, bạn có thể thấy file robots.txt tiết lộ vị trí admin panel.

Và với thông tin này, tôi dễ dàng truy cập vào để “tạm” chiếm quyền admin và ra tay hạ sát các user khác.

#1.2 Đào hầm trổ cửa hậu lên núi nhưng vẫn quên khóa

Nếu cho rằng cái admin URL ở trên quá lộ liễu và bạn có thể tăng độ ngẫu nhiên cho nó để gia cố bảo vệ thì cũng nên suy nghĩ lại. Với phương án này, attacker vẫn có thể dò tìm thông tin ví dụ soi kèo page source để xác định admin URL kiểu như sau.

Và công việc sau đó chỉ mang tính thủ tục.

#2. Câu chuyện thứ 2 – Chủ nhà khóa cửa nhưng quên rút chìa

Sau khi nhận thấy các phương án trên méo ổn, bạn có thể thử chuyển sang sử dụng giải pháp parameter-based access control. Về cơ bản, giải pháp này sẽ lưu trữ thông tin xác định quyền hạn của người dùng vào các vị trí như hidden fields (các trường thông tin ẩn), cookie, query string parameter thiết lập trước. Và nếu người dùng có thể kiểm soát thông tin ở các vị trí nói trên thì cách này thật ra cũng tệ không thua gì các phương án ở Mục 1.  Tình huống này cũng tương tự như khi bạn khóa cửa xong rồi cứ cắm chìa ở đó và cắp đít bỏ đi. Và lúc này hiển nhiên không có cách gì bảo đảm người khác không “ngứa tay” mở thử xem bên trong có gì hot!

#2.1 Thao túng cookie để mạo danh chủ nhà

Trong kịch bản này, khi tôi thử truy cập vào vị trí của nhạy cảm (/admin) thì nhận được thông báo yêu cầu login với administrator credential.

Đến đây mọi việc vẫn ổn. Nhưng nếu tôi thử thực hiện việc login đồng thời bật Burp Suite Interception và kích hoạt response interception như bên dưới thì bắt đầu có chuyện.

Lúc này con hàng response sẽ xuất hiện Set-Cookie. Và tôi có thể táy máy thử thay đổi Admin=false sang Admin=true.

Và chuyện lại đâu vào đấy khi tôi có thể ung dung truy cập vào trang của ông admin với các đặc quyền ác chiến.

#2.2 Thao túng roleid để mạo danh chủ nhà

Tiếp tục chuyển sang một kịch bản khác. Lần này tôi triển khai việc đăng nhập với credential chính chủ như mọi khi (wiener:peter).

Mọi việc cũng có vẻ bình thường cho đến khi tôi sử dụng chức năng Update email ở trên (tất nhiên với Burp Suite Interception đang bật). Lúc này, từ Burp Suite History, quan sát respone, bỗng đâu tôi thấy phọt ra cái thằng roleid với giá trị “1”.

Như lẽ thường tình, có “1” thì chắc phải có “2”, “3” và …Tay nhanh hơn não, tôi đẩy hàng sang Burp Suite Repeater và đút thêm roleid với giá trị “2” vào resquest rồi send thử. Và ngạc nhiên chưa, lúc này phía respone, tôi thấy cái roleid của tôi đã được cập nhật tương ứng mà không có lỗi lầm gì sất.

Với thay đổi này, khi duyệt lại vị trí /admin ban đầu, tôi đã thấy các tùy chọn đặc quyền của admin với đám user thường tội nghiệp.

#3. Câu chuyện thứ 3 – Chủ nhà xài khóa vân tay cho nhà vách lá

Sau khi nhận thấy 2 phương án đầu đều đổ bể, bạn có thể thử chuyển sang giải pháp khá khẩm hơn là sử dụng rule để kiểm soát. Với giải pháp này, việc truy cập vào các URL và HTTP method cụ thể có thể bị kiểm soát dựa vào user role và triển khai thông qua rule kiểu như:

DENY: POST, /admin/deleteUser, managers (Rule từ chối việc sử dụng POST method và truy cập vào URL /admindeleteUser để xóa các user thuộc manager group)

Cách này trông có vẻ chuẩn mực nhưng thực tế cũng có thể phát sinh vấn đề nếu không triển khai giải pháp bảo vệ đồng bộ trên cả phần front-end (tương tác phía client) và back-end (tương tác phía server). Kịch bản này tương tự như khi bạn chơi sang xài khóa bảo mật vân tay cực gắt cho phần cửa (tương ứng việc thiết lập rule kiểm soát truy cập chặt chẽ phí front-end) nhưng lại quên mất nhà bạn vẫn chơi vách lá (tương ứng phần back-end thả trôi nổi không kiểm soát).

Rồi tôi đi vào phần demo cụ thể. Trong tình huống này, tôi bật Burp Suite interception lên và thử truy cập vào vị trí /admin. Hiển nhiên, tôi nhận ngay cái kết đắng “Access denied”.

Với phương châm còn thở còn gỡ, tôi đâu dễ dàng gì từ bỏ. Tôi thử đẩy con hàng request sau qua Burp Suite Repeater.

Tại đây, tôi đổi thử /admin thành / (vị trí / tương ứng với trang chủ nên trong đại đa số trường hợp sẽ không bị khóa truy cập như /admin) và đút thêm HTTP header “X-Original-URL: /invalid” (cái URL /invalid là ví dụ page vớ vẩn không tồn tại để tôi minh họa thôi). Điểm thú vị nằm ở cái response “Not found” trả về. Điều này cho thấy ứng dụng đã “ăn” cái X-Original-URL tôi đút vào.

Lưu ý: Với ứng dụng sử dụng các framework hỗ trợ non-standard HTTP header (ví dụ X-Original-URL, X-Rewrite-URL,…) có khả năng ghi đè URL trong request gốc, việc triển khai giải pháp kiểm soát từ front-end để chặn truy cập vào URL cụ thể sẽ có thể mất hiệu lực

Với logic đó, tôi cập nhật lại “X-Original-URL: /admin” và thử lại.

Và búm chíu, cái thông báo “Access denied” đã “chim cút” ra khỏi tầm mắt của tôi. Lúc này tôi hoàn toàn nắm quyền bính trong tay để thao túng các user thường tùy thích (ví dụ trảm user carlos tội nghiệp như bên dưới).

Câu chuyện về vertical privilege escalation tất nhiên còn rất dài (ví dụ vấn đề thao túng request method) nhưng thời gian có hạn nên tôi xin phép tạm dừng vấn đề này ở đây. Kỳ tới tôi sẽ chuyển sang phần kế tiếp – Horizontal access controls.