Ở SVATTT 2021 năm nay thì team mình không vượt qua vòng lại, tuy nhiên cá nhân mình vẫn solve đc 2 bài web Script Kiddie và OProxy, coi như là một kỉ niệm lần đầu đi thi SVATTT có vui lẫn buồn.
Script Kiddie
1. Initial reconaissance:
Như mô tả ta có thể biết rằng web có chứa lỗ hổng SQL-injection với cơ sở dữ liệu được dùng ở đây là Microsoft SQL Server. Câu query như hình dưới
2. Exploit and get the flag:
- Payload:
1
(CASE WHEN (ascii(substring(db_name(), 1, 1)) =115) THEN 99 ELSE 1*'name' end)
Bạn có thể dùng Intruder của Burp Suite để brute force, hoặc tự viết script, các response trả về status 200 OK đồng nghĩa với payload trả về 99 –> true –> kí tự valid thuộc database name (lấy từ hàm
db_name
của payload).Tham khảo bài viết sau về các dùng Intruder của Burp Suite: https://portswigger.net/burp/documentation/desktop/tools/intruder/using.
- Flag:
ASICS{ssalchtiwesmihcueymorf}
OProxy
1. Initial reconnaissance:
Đầu tiên chúng ta cần tạo account để login vào:
Sau khi xem qua sơ bộ thì ta có thể tóm tắt web app của challenge này có những chức năng như sau:
/proxy
: khi nhập vào một URL bất kì (vd như https://stackoverflow.com) rồi bấm nút “Go!” thì web app sẽ tự động redirect đến URL đó.
/history?key=<key>&memcache=<memcache>
: tất cả những URL mà web app này redirect đến thông qua chức năng/proxy
sẽ được ghi lại tại đây. Parameterkey
có lẽ là để xác định mỗi trang history riêng biệt cho từng user, cònmemcache
thì không rõ là để làm gì, nhưng khi gánmemcache
1 giá trị bất kì thì ô thuộc cột Cached trong bảng history thay đổi.
2. Find the vulnerabilities:
- Như đã nói về parameter
key
thuộc chức năng/history
, chúng ta sẽ tạo thêm một account nữa, sau đó thử lấy key của userhoangnch
thay cho key của user đó để check xem web app này có bị IDOR không.
Hmm, như vậy không bị dính IDOR. Có lẽ chức năng history
không phải là mấu chốt để giải được bài này.
- Chúng ta lại test tiếp chức năng
/proxy
. Sẽ ra sao nếu chúng ta không nhập vào đấy một URL bình thường nhưhttps://github.com
mà là một cái link của Burp Collaborator client nhỉ?
Web app này vẫn gửi request tới Collaborator client của chúng ta mà không hề validate URL. Điều này chứng tỏ nó đã bị dính Server Side Forgery Request.
Oke, vậy sẽ ra sao nếu URL là http://127.0.0.1/register
(127.0.0.1
đồng nghĩa với localhost, là chính nó luôn) nhỉ?
OMG, cũng được luôn. Tuy nhiên, vì chúng ta sủ dụng URL có protocol là HTTP, do đó chắc chắn chỉ có thể nhìn nhận web app này dưới dạng HyperText. Thử sửa http
thành file
xem sao, cụ thể là file://127.0.0.1/etc/passwd
:
Tuyệt vời, điều này có nghĩa là chúng ta có thể path traversal thông qua FILE protocol, sau đó thoải mái đọc file trên localhost của web app này!
3. Exploit and get flag:
Còn một trở ngại cuối cùng nữa, đó là chúng ta không biết flag này ở chỗ nào :v. Nếu bài này mà lại đi đoán đường dẫn thì unintended vl :(. Sau một hồi brute force tìm đường dẫn đến tuyệt vọng thì chợt nhận ra là Linux lưu trạng thái của tất cả mọi thứ dưới dạng file (đọc tại đây), kể cả các process đang chạy trên máy. /proc/self
là một trong những magic đó của Linux, nó là folder chứa context của process hiện tại. Trong /proc/self
đó lại chứa rất nhiều file và folder lưu nhiều thông tin khác nhau của process hiện tại, trong đó cái thú vị nhất là /proc/self/cwd
chứa directory hiện tại mà process đang chạy trên đó (current working directory):
Để dễ hiểu hơn thì ta sẽ thử chạy một cái app php tại đường dẫn /home/kali/Documents/php_basic
trên linux rồi check xem bên trong /proc/self/cwd
có gì:
Vậy chắc chắn flag sẽ nằm trong current working directory của process đang chạy cái web app này. Do đó, payload của cuối cùng sẽ là: file://127.0.0.1/proc/self/cwd/flag.txt
Flag: ASCIS{SSRF_M3mcached_inj3cti0n}