# [NETSec101] ASPX file handling và một số vector tấn công

## Nguồn tham khảo:
Bài viết được tham khảo và dịch lại hoàn toàn từ nguồn dưới đây:
https://blog.viettelcybersecurity.com/deep-understand-aspx-file-handling-and-some-related-attack-vector/

## Một vài khái niệm cơ bản

IIS server chứa nhiều website, mỗi website có:
* Site ID: Mỗi website được host trên IIS đều có một site id riêng
* Physical webroot path: Thư mục public của website
* Bindings: port kết nối của website
* Root application (và các application con ở trong)


Ví dụ, như ở trên hình thì web **filehandling** có `siteid = 2`, physical path: `C:\FileHandle`, bindings `http:*:81;`

Mỗi website thì có thể chứa nhiều application

Mỗi application được host bởi một AppPool

### AppPool là gì?

AppPool là viết tắt của Application Pool (google dịch thì là "Nhóm ứng dụng")

Theo định nghĩa của microsoft và mình dịch lại thì:

AppPool là một container nhóm một hoặc nhiều website worker process lại với nhau.

Mỗi AppPool có:
* AppPool Name
* Identity:
* LocalSystem, NetworkService, LocalService
* ApplicationPoolIdentity (IIS apppool\<apppool_name> - virtual account)
* AppPool chạy `C:\windows\system32\inetsrv\w3wp.exe` dưới quyền đã được định danh


Quy trình xử lí file của `w3wp.exe`:
1. Bước 1: User truy cập vào **http://domainname:81:/index.aspx**
2. Bước 2: website1 sẽ xử lí bindings https:*:81 -> website1
3. Bước 3: Virtual path /index.aspx được xử bởi **Root Application**
4. Bước 4: Root application sẽ chạy dưới Website1 AppPool -> chạy **w3wp.exe** của website1 dưới quyền "IIS AppPool/website1"
5. Bước 5: Các bước xử lí của **w3wp.exe**
* Từ virtual path `index.aspx` w3wp.exe lấy physical path `C:/website1/index.aspx` và đọc nội dung file aspx
* Từ nội dung file aspx dịch nó thành sourcecode C#
* Chạy **csc.exe** để build dll từ sourcecode c# đó
* load dll -> khởi tạo một page instance và call Page.Onload()

Quá trình build file aspx trên chỉ xảy ra khi file aspx đó được truy cập lần đầu tiên hoặc file có sự thay đổi.

File dll sẽ được cache ở đâu đó. Thuật toán cache như sau:


Folder lưu file cache:

Cace file của virtual path `/default.aspx` sẽ lưu ở file`default.aspx.cdcab7d2.compiled` thuộc folder `C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\2a157c5c\41a9fdba`

Nội dung file cache sẽ có chứa tên file dll sẽ được load

Ngoài ra, folder cache có nhiều thông tin mà chúng ta cần quan tâm hơn:

### "Code gen dir"

Đây là thuật toán được sử dụng để tạo ra đường dẫn folder cache (để tính toán được đường dẫn folder cache cần phải biết physical path và appid)

Đây là đoạn code tính toán đường dẫn folder:

Ví dụ: website1 có site id là 2 và nó chứa 2 applications:
* Root application (physical path = C:\website1\ , appid = /LM/W3SVC/2/ROOT)
* admin application (physical path = C:\website1\admin , appid = /LM/W3SVC/2/ADMIN)

### Top level file hash
w3wp sẽ tính hash của tất cả các file config (web.config, machine.config,...)
Nếu giá trị hash này thay đổi có nghĩa là một file config nào đó đã bị thay đổi, lúc này tất cả các file trong "code gen dir" sẽ bị xóa và build lại

Bên cạnh đó, file hash\hash.web được monitor realtime, nếu hash bị thay đổi, AppDomain sẽ tắt.

### preStartInitList.web

Load tất cả assembly trong file file này, tìm và chạy các method được list trong file.

File này mô tả những thứ cần khởi tạo trước khi app chạy.


### Cache key

Cache key là phần quan trọng nhất. Ví dụ cache key của file **default.aspx** là **cdcab7d2** (w3wp.exe sẽ tìm cache file default.aspx.cdcab7d2 trong folder "code gen dir" để load thông tin, assembly, type)

Thuật toán tạo cache key phụ thuộc vào virtualpath:


Ví dụ:


Dựa trên những điều trên thì chúng ta có một vài vector tấn công khả thi:

1. Persistent Webshell
2. Đọc và upload file tùy ý
3. Bypass AppPool Isolation
4. Bypass URL filtering

## Attack01 - Persistent Webshell


Có thể thấy thông tin của cache file có chứa dll được load. Attacker hoàn toàn có thể uploads một dll độc hại vào folder này và chỉnh sửa assembly hoặc type để inject vào các function bình thường. Kĩ thuật này còn có tên gọi là `Dll Hijacking` hay `DLL Side Loading`

### DLL Hijacking

DLL Hijacking là phương pháp inject mã độc vào file DLL, thường được sử dụng để khai thác lỗ hổng trong việc load DLL của ứng dụng.
Bằng cách thay thế tệp DLL legit được load bằng một file DLL bị nhiễm mã độc

Để có thể Hijacking thì bắt buộc attacker phải upload được file DLL vào thư mục mà ứng dụng sẽ load DLL.

Trong hoàn cảnh của bài viết này thì việc upload file dll vào folder "code gen dir" qua đường file upload chỉ khả thi khi web bị lỗi upload file tùy ý vào bất kỳ folder nào (thường là sẽ không có quyền, hoặc không thể path traversel để up folder tùy ý).
Nên thường DLL Hijacking được tận dụng khi attacker đã upload file shell thành công lên folder upload, RCE thành công sau đó upload file dll vào folder "code gen dir" để persistent.

Việc bulid Malicious DLL có rất nhiều cách, bạn có thể tham khảo ở đây:
https://sec.vnpt.vn/2023/04/dll-proxying-for-persistence/

Trong khuôn khổ bài mình sẽ chỉ build DLL từ C# với Visual studio

## Attack02 - Đọc và upload file tùy ý đối với các server giới hạn quyền

Ý tưởng của vector này là khi bạn không thể đọc hoặc ghi file ở webroot folder, nhưng bạn có thể đọc hoặc ghi file ở cache folder.

Ví dụ: Nếu web có chưa vuln upload file nhưng server không cho phép ghi ở path `C:/website1` nên attacker không thể up shell ở folder đó. Thường thì attacker sẽ tìm cách ghi file vào cache folder

Ví dụ khác là, một số application sẽ compile source code trước và tắt autocompile nên nếu attacker có up được shell thì shell này cũng không được compile nên attacker sẽ thường nghĩ đến hướng ghi vào cache folder để tấn công với các kỹ thuật về DLL

Nhưng cái khó nhất của vector tấn công này là phải biết physical path và appid của application.

## Attack03 - Bypass AppPool Isolation

Trên một IIS server có thể sẽ có nhiều website cùng được host (shared hosting)

Tác giả có đề cập đến ý tưởng nếu có thể chiếm được website1 có thể tấn công ngang sang các website khác trong cùng IIS host không?

Dưới đây là quyền của các foler trong `C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\`


Có thể thấy ngay vấn đề ở đây nằm ở quyền của **BUILTIN\IIS_IUSERS**


IIS_IUSERS: có quyền Modify + Delete content

Có thể thấy BUILTIN\IIS_IUSERS có thể sửa và xóa nội dung trong cache folder của các user khác

## Attack04 - Bypass URL filtering

Ý tưởng của vector này nằm ở thuật toán gen cache key có thể bị trùng lặp. Ở phần trên mình đã có đề cập đến thuật toán gen cache key. Đuôi file sẽ là 4 bytes (8 hex characters)

Không gian sinh cache key là `4,294,967,295`. Có vẻ lớn nhưng vẫn rất dẽ để bị collision.

-> Tìm virtual path gây ra collision

Từ virutual path có được, nếu WAF filter, chặn không cho phép truy cập `/admin/index.aspx` chúng ta có thể truy cập vào `/a583524842/index.aspx`