+6

Từ SQL Injection đến Admin Take Over

Sumary

Hôm bữa có một case khá hay, khi tìm lỗi trên hệ thống. Với lỗi ban đầu là SQL Injection sau đó ngụm lặn trong hệ thống thì tôi đã chiếm được quyền Admin của hệ thống.


Mở bài

Tôi dùng web như người dùng bình thường, rồi thực hiện đăng ký tài khoản, nhưng đăng ký xong, tôi cần Admin duyệt mới cho phép vào được. Trong lúc này, tôi thực hiện recon hệ thống cơ bản trên redacted.com Thực hiện cơ bản với các tool để recon:

  • Tìm thông tin của subdomain với subfinder và httpx:

image.png

  • Tìm thông tin các cổng dịch vụ của domain với Nmap:

image.png

  • Tìm thêm thông tin về các path có thể của hệ thống bằng dirsearch:

Kết quả trả về là một path giá trị nhất: /backup chứa thông tin của một file sql dump từ MySQL.

image.png

Sau một thời gian thì tài khoản được duyệt. Tôi sử dụng web như người dùng bình thường.

Thân bài

Đập vào mắt tôi khi lướt đến phần quản lý bài viết:

image.png

Nghĩa là người dùng trong hệ thống được phép đăng bài và admin sẽ duyệt bài viết. Tôi vội vã tìm ngay cho mình hướng đi nhanh nhất: Unrestricted File Upload để có thể upload shell. Nhưng tôi đã thất bại vì trong mục này, cơ bản framework dùng là tinyMCE version không bị lỗi nào liên quan đến upload file:

image.png

Chưa dừng lại ở đó, tôi quay lại phần quản lý bài viết, phát hiện ra rằng ở phần này url khi tìm kiếm sẽ có các key query:

image.png

Kinh nghiệm thì ai cũng sẽ thử SQL Injection ở đâu thôi và thành công khi trigger được lỗi này!

image.png

Phát hiện ra rằng param bị lỗi là status với payload: -1 UNION SELECT 1,@@version,3,4,5,6,7,8,9,1,2,3,4,5,6,7,8,9,1,2,3,4,5,6,7,8 -- -

Xác định được param tôi bắt tay vào thực hiện kiểm tra dữ liệu, nhưng bắt đầu phát hiện WAF của web cũng không đến nỗi tệ và không thể nào sử dụng payload thuần được, phải bypass WAF.

Bên cạnh đó tôi có sử dụng phương thức DIOS (Dump in on shot) của https://github.com/Rizsyad/diosqli nhằm bypass và tiết kiệm thời gian tìm kiếm thông tin của database.

image.png

Game bắt đầu hay khi tôi thấy ở trong các database này đều có thông tin liên quan đến các subdomain mà tôi tìm thấy ở bước recon. Data server chỉ login từ local và không có quyền hạn nào khác, bên cạnh đó với version MySQL này, thông tin password của user MySQL không thể dump ra được. Cộng thêm với các thông tin của user như trên, tôi hoàn toàn không thể dùng chain SQLi to RCE được (khá vô vọng).

Tiếp tục recon tôi đã sử dụng sqlmap nhằm tối ưu quá trình tìm kiếm dữ liệu nhạy cảm trong database. Tôi lần lượt cho sqlmap duyệt qua hết các table và column của các database có thể tìm thấy. Mục tiêu chính là các bảng chứa thông tin người dùng admin của hệ thống subdomain khác.

Duyệt từng cái thì cái nào cũng cho tôi cảm giác bất lực như thế này:

image.png

Bằng một niềm tin không lung lay, tôi dùng john để thử vận may của mình, rồi tiếp tục ngồi dump dữ liệu các database khác.

Kiếp nạn thứ 82 xảy ra, khi tôi lấy dữ liệu ra từ một bảng trong database bằng sqlmap không được. Tôi cũng không hiểu vì sao, thử đủ mọi cách cũng không chạy mà báo lỗi liên tục

image.png

Tôi đành ngồi nghiên cứu payload bằng tay để dump cho chính xác thử xem sao.

Payload tôi dùng như sau:

(SeLECT(@x)FrOM(SeLECT(@x:=0x00) ,(SeLECT(@x)FrOM(xxx.users) WHERE(@x)IN(@x:=CONCAT(0x20,@x,email,':',password,0x3c62723e))))x)

Và đúng là chăm chỉ quay tay, vận may sẽ đến. Tôi tìm được một thông tin đáng chú ý như thế này:

image.png

Tôi lập tức vào ngay subdomain abc.redacted.com với database cùng tên để kiểm chứng sự thực có đúng là như vậy không :v

image.png

Đúng thật là có thể sử dụng để login, mà tôi còn ngỡ ngàng khi thông tin password trang CMS còn được để dạng rõ @@

Đến bước này vẫn chưa đúng mục tiêu lắm. Tôi quyết định nghiên cứu thử thông tin trang này xem có khác trang kia không, có hướng nào leo lên thêm không. Mọi thứ vẫn là tinyMCE, vẫn là không có cách nào để tạo ra một đường lên tuyệt vời hơn. Tôi đã mất 2 ngày để đến được mốc này rồi. Vẫn không có một cách nào để lên cao hơn ư, nên tôi đành bỏ qua một chỗ và làm việc khác.

Kết bài

Ngay hôm sau, tôi chợt nhận ra một hướng có thể sử dụng, đó chính là Cookie. Tại sao vậy, bởi đây là một subdomain của một domain, bằng một cách kỳ lạ nào đó, dev cấu hình sai thì sao? Bên cạnh đó, CMS hai trang này cũng tựa tựa nhau. Khiến tôi nghĩ, hay là thử dùng Cookie admin của subdomain để dùng trên domain chính liệu được không ta?

Và dự đoán của tôi đã đúng, tôi có thể dùng cookie của subdomain trên domain chính. Tôi có gì? Tôi có full quyền Admin của CMS trên domain chính dưới tên của người dùng của subdomain??? Khá lạ lùng, tôi cũng chưa biết nó hoạt động thế nào nhưng khi view thông tin thì sẽ bị báo lỗi vì email đăng nhập của cookie này không tồn tại trong mục người dùng của domain chính. Ảnh dưới là thông tin nếu không tồn tại trong hệ thống, nhưng phần quyền vẫn là Admin???

image.png

Và còn user khác, tôi cũng thử luôn! Và bùm, user này có thể truy vấn thông tin một cách hoàn chỉnh trên domain chính! User này như tôi check thì có tồn tại email trên cả domain chính và subdomain:

image.png

Đến đây thì đã coi như lên cao nhất của hệ thống. Tôi đã thử cách này với các subdomain khác từ subdomain có thông tin đăng nhập, nhưng có vẻ không thành công, tôi dừng và báo cáo thông tin lỗi cho chủ trang web.


Bài học

Case này đi lên từ

File Backup Disclosure & SQL Injection --> Password Leak (từ trong database) --> Cookie Sử dụng được giữa domain và subdomain (Misconfiguration)


All rights reserved

Viblo
Hãy đăng ký một tài khoản Viblo để nhận được nhiều bài viết thú vị hơn.
Đăng kí