"Hành hạ" máy chủ IIS: Hướng dẫn khai thác lỗ hổng và kỹ thuật tấn công chuyên sâu

Một người bạn từng nói với tôi rằng: "Nếu bạn bắt gặp màn hình xanh mặc định của IIS, đừng dừng lại ở đó; chắc chắn có gì đó ẩn giấu đằng sau."

Quả thực, ông ấy nói đúng. Trang chào mừng xanh đặc trưng của IIS (Internet Information Services) không phải là một ngõ cụt. Đằng sau cửa sổ xanh đó là một trong những máy chủ web thường xuyên bị cấu hình sai nhất trên World Wide Web, và nó đang "cầu cứu" bạn hãy tìm hiểu sâu hơn.

Hãy cùng tôi đi qua quy trình tiếp cận các mục tiêu IIS trong các chương trình săn lỗi (bug bounty) và kiểm thử xâm nhập (pentest).

Tìm kiếm máy chủ IIS

Trước khi khai thác, chúng ta cần phải tìm thấy mục tiêu. Dưới đây là một số kỹ thuật tôi sử dụng để định vị các máy chủ IIS.

Sử dụng Shodan

Shodan là kho tàng dữ liệu về các thiết bị kết nối internet. Bạn có thể sử dụng các câu truy vấn sau để tìm các hộp IIS liên quan đến tổ chức mục tiêu hoặc chứng chỉ SSL của họ:

ssl:"target.com" http.title:"IIS"
ssl.cert.subject.CN:"target.com" http.title:"IIS"
org:"target" http.title:"IIS"

Các truy vấn mẫu này sẽ liệt kê các máy chủ IIS gắn liền với tổ chức hoặc chứng chỉ SSL của mục tiêu. Bạn sẽ đôi khi tìm thấy các máy chủ staging (đ staging), bảng quản trị bị quên và các công cụ nội bộ mà không ai nhận ra là chúng đang tiếp xúc với internet.

Bạn cũng có thể kết hợp Shodan với các nền tảng khác như Fofa, Censys, Netlas, Odin, v.v.

Google Dorking

Google có thể tìm thấy các máy chủ IIS cho bạn trước cả khi bạn bật máy quét lên. Các "dork" sau đây tập trung vào việc định vị các mục tiêu IIS trong phạm vi:

site:target.com intitle:"IIS Windows Server"
site:target.com inurl:aspnet_client
site:target.com ext:aspx | ext:ashx | ext:asmx
site:target.com intext:"Microsoft-IIS" | intext:"X-Powered-By: ASP.NET"
site:target.com inurl:_vti_bin

Thư mục aspnet_client và _vti_bin (phần mở rộng FrontPage) là dấu hiệu nhận biết rõ ràng của IIS. Dork ext:aspx sẽ bắt bất kỳ trang ASP.NET nào đã được lập chỉ mục, nghĩa là IIS đang chạy bên dưới.

Nhận diện dấu vân tay công nghệ (Active Tech Fingerprinting)

Cách dễ nhất để biết bạn đang nhìn thấy IIS là qua các header phản hồi. Hãy gửi một yêu cầu thô:

nc -v target.com 80

Hoặc nếu là TLS:

openssl s_client -connect target.com:443

Những gì bạn cần tìm trong header phản hồi sẽ trông giống như sau:

Server: Microsoft-IIS/10.0 X-Powered-By: ASP.NET

Để làm việc này với quy mô lớn, bạn có thể sử dụng công cụ như httpx hoặc nuclei.

Khi đã tìm thấy IIS, làm gì tiếp theo?

Đầu tiên, hãy xác nhận những gì chúng ta đang đối mặt và thu thập càng nhiều thông tin miễn phí càng tốt từ máy chủ.

Tiết lộ địa chỉ IP nội bộ

Đây là một món quà mà nhiều người bỏ lỡ. Gửi một yêu cầu HTTP/1.0 đến một số thiết lập IIS nhất định (đặc biệt là Exchange hoặc OWA) và máy chủ đôi khi sẽ đưa cho bạn một IP nội bộ trong header Location:

curl -v --http1.0 http://example.com

Bạn có thể nhận được phản hồi như:

HTTP/1.1 302 Moved Temporarily Location: https://192.168.5.237/owa/ Server: Microsoft-IIS/10.0 X-FEServer: NHEXCHANGE2016

IP nội bộ và header X-FEServer đó vừa tiết lộ cho bạn tên máy chủ nội bộ của máy chủ Exchange. Hãy ghi nhớ thông tin này.

Khai thác lỗ hổng

Đã đủ thời gian do thám, giờ hãy đến với những phần "thịt bò".

Tự động hóa với Nuclei

Khi bạn có danh sách các mục tiêu IIS, hãy "bắn" chúng bằng nuclei sử dụng các thẻ liên quan:

nuclei -l iis-targets.txt -tags microsoft,windows,asp,aspx,iis,azure,config,exposure -silent

Vùng chết HTTPAPI 2.0

Bạn sẽ gặp nhiều máy chủ IIS phản hồi lỗi 404 chung chung của HTTPAPI 2.0. Đa số mọi người thấy điều này và nghĩ "không có gì ở đây". Sai.

Thực tế, điều này có nghĩa là máy chủ không nhận được tên miền đúng trong header Host. Phiên bản IIS ở đó, nó đang chạy thứ gì đó, nhưng nó được ràng buộc với một máy chủ ảo cụ thể. Bạn cần tìm ra máy chủ nào.

Hai cách tiếp cận:

1. Kiểm tra chứng chỉ SSL. Trường subject hoặc SAN thường chứa tên máy chủ bạn cần.
2. Nếu chứng chỉ không giúp ích, hãy brute-force các máy chủ ảo bằng công cụ như ffuf.

Liệt kê tên file ngắn IIS (Tilde Enumeration)

Đây là một trong những kỹ thuật bị đánh giá thấp nhất. IIS có hành vi kế thừa từ quy ước tên file DOS 8.3 cũ. Bằng cách gửi các yêu cầu được tạo đặc biệt, bạn có thể liệt kê các tên ngắn của file và thư mục trên máy chủ ngay cả khi tính năng liệt kê thư mục bị tắt.

Công cụ bạn muốn sử dụng là shortscan:

shortscan https://target.com/ -F -p 1

Thao tác này sẽ trả về các đoạn tên ngắn như: File: WEB~1.CON File: GLOBAL~1.ASA File: SITEBA~1.ZIP Dir: ADMIN~1

Vấn đề là: WEB~1.CON rõ ràng là web.config. Nhưng SITEBA~1.ZIP là gì? Là sitebackup.zip? sitebase.zip? Nếu chúng ta đoán đúng tên đầy đủ, chúng ta có thể thử tải nó xuống.

Sử dụng GitHub để giải mã shortname IIS

Giải mã tên ngắn (Shortnames)

Có một số cách để giải quyết các đoạn tên này:

Sử dụng GitHub Dorks: Tìm kiếm mã của GitHub về các tên file khớp với mẫu của bạn. Ví dụ, nếu shortname là siteba, hãy tìm các file bắt đầu bằng chuỗi này.

Sử dụng BigQuery: Kỹ thuật này lấy cảm hứng từ nghiên cứu của Assetnote. Sử dụng tập dữ liệu GitHub công khai của Google BigQuery để tìm kiếm toàn bộ kho lưu trữ mã của GitHub để tìm các tên file khớp với mẫu shortname của bạn.

Bruteforce với Crunch: Khi các phương pháp thông minh khác thất bại, hãy dùng cách "thô sơ". crunch tạo danh sách từ của mọi kết hợp có thể có cho một độ dài ký tự nhất định. Sau đó sử dụng ffuf để thử các biến thể khác nhau (dấu gạch nối, dấu gạch dưới, khoảng trắng, v.v.).

Fuzzing: Danh sách từ dành riêng cho IIS

Các danh sách từ (wordlist) chung chung thì tốt cho các máy chủ chung chung, nhưng IIS thì không. Bạn cần fuzz những thứ chỉ tồn tại trong hệ sinh thái IIS/.NET.

Các mục tiêu có giá trị cao cần fuzz:

• /web.config
• /web.config.bak
• /trace.axd
• /elmah.axd
• /connectionstrings.config

Ví dụ, trace.axd là trình xem theo dõi ASP.NET. Nếu được bật, bạn nhận được nhật ký yêu cầu/phản hồi đầy đủ bao gồm header, cookie và đôi khi là thông tin đăng nhập.

Web.config: Chìa khóa của vương quốc

Nếu bạn có thể đọc web.config thông qua lỗi duyệt đường dẫn (path traversal), file sao lưu bị cấu hình sai, hoặc phát hiện hỗ trợ từ shortname, bạn có thể đã thắng toàn bộ cuộc đánh giá.

Tại sao? Các file web.config của IIS thường chứa machine keys. Đây là các khóa mật mã dùng để ký và mã hóa ViewState. Nếu bạn có các khóa này, bạn có thể tạo một payload ViewState độc hại đã được ký và đạt được thực thi mã từ xa (RCE) thông qua deserialization.

Tiếp xúc DLL thư mục Bin

Ngay cả khi không có path traversal, có một cách tinh vi để kéo các DLL thẳng từ thư mục bin. Tính năng phiên không dùng cookie (cookieless session) cũ của ASP.NET cho phép nhúng mã thông báo phiên trực tiếp vào đường dẫn URL bằng cú pháp (S(X)).

Điều tuyệt vời là: bạn có thể lạm dụng điều này để gây nhầm lẫn cho việc phân giải đường dẫn của IIS và truy cập thư mục bin ngay cả khi nó bị chặn:

GET /(S(X))/b/(S(X))in/Newtonsoft.Json.dll

IIS diễn giải các đoạn (S(X)) là mã thông báo phiên không dùng cookie, loại bỏ chúng trong quá trình chuẩn hóa đường dẫn và cuối cùng phân giải đường dẫn thành /bin/Newtonsoft.Json.dll.

Tải những file này xuống, ném vào JetBrains dotPeek hoặc dnSpy, và bạn sẽ đọc được toàn bộ mã nguồn đã được biên dịch ngược: thông tin đăng nhập được mã hóa cứng, khóa API, logic endpoint nội bộ.

Bypass xác thực và Upload

Nhầm lẫn đường dẫn Reverse Proxy

Khi IIS ngồi sau một reverse proxy, bạn đôi khi có thể khai thác sự khác biệt trong chuẩn hóa đường dẫn để truy cập các đường dẫn không được phép. Ví dụ: nếu /admin/ trả về 403, hãy thử:

/anything/..%2fadmin/

Proxy thấy /anything/..%2fadmin/ và nghĩ bạn đang yêu cầu /anything/. Nó chuyển tiếp yêu cầu. Nhưng IIS giải mã %2f thành /, giải quyết path traversal và phục vụ /admin/.

Thủ thuật tải lên file

Nếu bạn tìm thấy chức năng tải lên trên mục tiêu IIS, các nhà phát triển gần như chắc chắn đã chặn danh sách .aspx và .asp. Tuy nhiên, IIS phục vụ một số lượng đáng ngờ các phần mở rộng dưới dạng text/html theo mặc định, có nghĩa là XSS được lưu trữ thông qua tải lên file.

Các phần mở rộng hiển thị dưới dạng HTML: .cer, .hxt, .htm.

Hơn nữa, IIS có một đặc điểm kỳ lạ với các dấu chấm ở cuối tên file. Nếu bộ lọc tải lên chặn shell.aspx, hãy thử:

shell.aspx. shell.aspx..

IIS sẽ loại bỏ các dấu chấm ở cuối và phục vụ file bình thường.

Kết luận

Như chúng ta đã thấy, bề mặt tấn công của IIS trong bug bounty khá rộng nhưng nhất quán bị thiếu kiểm thử. Mọi người đều đang đi theo đuổi lỗ hổng mới nhất của các framework JS trong khi những chiếc máy chủ Windows này ngồi đó, rò rỉ IP nội bộ, phục vụ các file cấu hình của chính chúng và chạy với tính năng liệt kê tên ngắn rộng mở.

Vì vậy, đừng bỏ qua màn hình xanh đó. Hãy do thám kỹ hơn.