# Report 11/8/2025 | POCGEN: Generating Proof-of-Concept Exploits for Vulnerabilities in Npm Packages
>[name=Nguyen Da Vit]
>[time= Started on 24, July]

### 1. Motivation:
- PoC (Proof of Concept) rất hữu ích cho việc kiểm tra bản vá lỗi và ngăn sự cố trong tương lai. Tuy nhiên, một số CVE thiếu hoặc thậm chí không kèm theo PoC nào. Một số public PoC thì lại không đảm bảo tính tin cậy.
- Việc tạo PoC rất mất thời gian và yêu cầu coder hiểu sâu về codebase, lỗ hổng và cơ sở công nghệ được sử dụng.
- Đã có tool Explode.js để sinh payload nhưng một số lỗi lại không thể phát hiện
- Bài báo giải quyết các vấn đề trên bằng PoCGEN
### 2. PoCGEN:

- Dataset: SecBench.js (Chứa lỗ hổng đến 2022), các lỗ hổng mới lấy từ GitHub Advisory Database & Snyk Vulnerability Database
- Input: Vulnerability report, code base
- Output: Tạo ra PoC exploit
- Kiến trúc: Gồm 4 phần được thực hiện lặp đi lặp lại
- **Vulnerability Information Extraction**: Hiểu lỗ hổng và trích xuất được source-level information, sử dụng phân tích động để trích xuất các thông tin sau:
- ***Vulnerability Type***: Prompt cho LLM với vulnerability report và cung cấp danh sách gồm 5 loại lỗ hổng: Path traversal, prototype pollution, command injection, code injection và Regular Expression Denial of Service (ReDoS) và yêu cầu chọn loại lỗ hổng phù hợp nhất trong list
- ***Vulnerable Function***: Trích xuất động các function được export từ pakage. Prompt cho LLM với vulneability report và xác định hàm có nguy cơ lỗi trong số function được export và sắp xếp theo mức độ
- ***Taint Path Extraction***:
- Dùng phân tích tĩnh (CodeQL) để tìm các dòng code có nguy cơ gây ra lỗi (Từ các dòng nhận input đến các dòng thực thi, và bao gồm thêm 3 dòng trước và sau để bổ sung ngữ cảnh, gọi là taint path)
- Nếu không tìm được taint path từ lần đầu tiên, chuyển sang phân tích taint propagation rules và vulnerable sinks mà tác giả mở rộng. Nếu vẫn không được thì kết hợp phân tích động + tĩnh
- Nếu vẫn không tìm được, chuyển sang function tiếp theo trong danh sách vulnerable function, lặp lại hết danh sách mà vẫn không tìm được thì việc tìm taint path thất bại và không chuyển sang bước tiếp theo
- ***Usage Snippets***: Trích xuất các đoạn code khai báo/sử dụng các function dễ bị tấn công từ source code và documentation của pakage, đặt trong cặp ` ``` `. Prompt cho LLM để lọc ra đoạn code nào thật sự là đoạn code thể hiện function lỗi không. Nếu phải thì gọi LLM tóm tắt lại.

- **Exploit Generation**: Sử dụng LLM để tạo exploit
- Prompt sẽ bao gồm:
- `vulnerableFunction`: Tên hàm dễ bị tấn công
- `vulnerabilityType`: Loại lỗ hổng
- `vulnerabilityDescription`: Mô tả về lỗ hổng
- `usageSnippets`: Các đoạn code thể hiện việc sử dụng hàm dễ bị tấn công
- `exploitSkeleton`: Mẫu template exploit
- `similarExploits`: Các exploit của các lỗ hổng tương tự (Sử dụng BM25 tìm 3 example liên quan nhất theo vulnerable descriptions từ SecBench.js)

- **Exploit Validation**: Thực thi và xác thực lại exploit được tạo ra
- ***Xác định mục tiêu khai thác theo từng loại lỗ hổng***: Trích xuất động các function được export từ pakage. Prompt cho LLM với vulneability report và xác định hàm có nguy cơ lỗi trong số function được export và sắp xếp theo mức độ
- *Path Traversal*: truy cập được file flag.txt ở thư mục root.
- *Prototype Pollution*: thêm thuộc tính exploited vào Object.prototype mà không gán trực tiếp trong mã (`__proto__.exploited = ...`).
- *Command Injection*: thực thi lệnh `/usr/bin/genpoc`.
- *Code Injection*: gọi process.seteuid(42) nhưng phải thông qua hàm dễ bị tấn công, không gọi trực tiếp.
- *ReDoS*: làm regex chạy >1500 ms.
- Prompt lại cho LLM để kiểm tra lỗ hổng đó có thực sự được khai thác như đã mô tả trong báo cáo hay không
- **Prompt Refinement**: Nếu exploit không hợp lệ và chưa vượt quá số lần tinh chỉnh tối đa, sử dụng tập hợp các phương pháp tinh chỉnh để cung cấp các thông tin động/tĩnh cho phần 2 để cố gắng tạo ra một exploit hợp lệ
- ***Context Refiner:***
- Body refiner: Cung cấp toàn bộ thân hàm có chứa dòng trong taint path
- Missing declaration refiner: Cho phép LLM yêu cầu định nghĩa của biến/hàm trong taint path, PoCGEN sẽ cung cấp cho LLM
- ***Runtime refiner:*** Cung cấp thêm các thông tin lúc thực thi vào prompt, gồm:
- *Error refiner:* Cung cấp thông báo lỗi trong quá trình execute exploit
- *Coverage refiner:* Cung cấp thông tin coverage cho từng dòng trong taint path, chỉ ra đoạn nào chưa chạy
- *Debugger refiner:* Cho phép LLM yêu cầu giá trị runtime của các biểu thức, POCGEN sẽ chèn vào taint path dưới dạng comment
- *Vulnerability-specific refiners:* Cung cấp giá trị runtime tại các sink cụ thể
- Path Traversal: Giá trị được truyền vào tập tin thệ thống như `fs.readFile` và `fs.open`
- Command Injection: Giá trị truyền vào hàm `spawn`
- Injection vulnerabilities: Giá trị truyền vào `Function` constructor
- Sau mỗi lần tinh chỉnh, rút gọn bớt prompt bằng cách loại bỏ phần thông tin mà LLM đã dùng đúng ở lần trước
### 3. Evaluation

#### a. Dataset:

- SecBench.js, new dataset extract từ GitHub Advisory Database và Snyk Vulnerability Database, đặt tên là CWEBench.js
#### b. Experimental Setup
- OS: Ubuntu 22.04
- CPU: Intel Zeon(R) Silver 4214
- RAM: 256 GB
- Node.js version: 22.11.0
- CodeQL version: 2.20.4
- LLM Model: gpt-4o-mini-2024-07-18
- Số lần tinh chỉnh tối đa: 30 lần
- Số input token: 300k
- Số output token: 100k
- Time limit: 1h
#### c. Experimental Results
- Trên SecBench.js (560 lỗ hổng): thành công 77%, cao hơn Explode.js (32%) và AutoGPT (16%).
- Trên CWEBench.js (794 lỗ hổng mới, khó hơn): thành công 37%.
- Chi phí trung bình $0.02 mỗi PoC, thời gian trung bình 11 phút (7 phút với ca thành công).
- Tỉ lệ false positive thấp (5%).
- Các thành phần như usage snippet và few-shot example có ảnh hưởng lớn đến tỉ lệ thành công.