Trinh sát máy chủ IIS: vui thì có vui, nhưng cũng dễ vào tù

 (mll.sh)
1 điểm bởi GN⁺ 3 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Màn hình mặc định của IIS không phải ngõ cụt mà là điểm khởi đầu cho trinh sát bug bounty; có thể thu hẹp các máy chủ lộ ra ngoài và vhost ẩn bằng Shodan, Google dork và header phản hồi
  • Yêu cầu HTTP/1.0, HTTPAPI 2.0 404, chứng chỉ SSL và brute force header Host là manh mối ban đầu để tìm IP nội bộ, hostname Exchange và virtual host
  • Tilde shortname enumeration dựa trên DOS 8.3 của IIS có thể làm lộ tên file/thư mục ngắn ngay cả khi đã tắt directory listing; sau đó dùng GitHub search, BigQuery, LLM và crunch để suy đoán tên đầy đủ
  • Fuzzing chuyên biệt cho IIS/.NET nên ưu tiên nhắm vào các đường dẫn và phần mở rộng giá trị cao như web.config, trace.axd, elmah.axd, appsettings.*.json, .aspx/.ashx/.asmx/.config
  • Lộ web.config, chuẩn hóa đường dẫn của cookieless session, reverse proxy path confusion, NTFS alternate data stream, bypass phần mở rộng upload và HPP cho thấy lỗi cấu hình và hành vi legacy có thể trực tiếp mở ra bề mặt tấn công

Cách trinh sát để tìm máy chủ IIS

  • Mục tiêu IIS có thể được tìm thấy trước tiên qua công cụ tìm kiếm và các dịch vụ tìm kiếm tài sản Internet
  • Truy vấn Shodan thu hẹp máy chủ IIS bằng cách kết hợp chứng chỉ SSL của domain mục tiêu, tên tổ chức và http.title:"IIS"
    • Ví dụ mục tiêu có thể gồm máy chủ staging, bảng quản trị bị lãng quên và công cụ nội bộ bị lộ ra Internet
    • Ngoài Shodan còn có fofa, censys, netlas và odin cung cấp các chỉ mục Internet khác nhau
  • Google dorking được dùng để tìm các trang đã được index có dấu vết IIS
    • Thư mục aspnet_client và _vti_bin được xem là tín hiệu của IIS
    • ext:aspx giúp tìm các trang ASP.NET và ngụ ý bên dưới là IIS
    • Tìm kiếm wildcard dạng site:*.target.com, site:*.*.target.com được dùng để tìm các subdomain lồng nhau mà quá trình liệt kê subdomain cơ bản bỏ sót
  • Header phản hồi là manh mối dễ thấy nhất để nhận diện IIS
    • Server: Microsoft-IIS/10.0
    • X-Powered-By: ASP.NET
    • Với kiểm tra quy mô lớn, có thể dùng httpx hoặc nuclei để tạo danh sách mục tiêu IIS

Manh mối ban đầu sau khi xác nhận IIS

  • Một số cấu hình IIS, đặc biệt là frontend Exchange hoặc OWA, có thể làm lộ thông tin nội bộ khi nhận yêu cầu HTTP/1.0
  • Header Location có thể chứa IP nội bộ như https://192.168.5.237/owa/
  • Header X-FEServer có thể làm lộ hostname nội bộ của máy chủ Exchange
  • Những thông tin này có thể dẫn đến rò rỉ thông tin hữu ích cho các bước sau

Tự động hóa và tìm virtual host ẩn

  • Sau khi có danh sách mục tiêu IIS, có thể chạy nuclei với các tag như microsoft, windows, asp, aspx, iis, azure, config, exposure để giảm bớt thao tác lặp lại
  • HTTPAPI 2.0 404 không hẳn có nghĩa là thực sự không có gì ở đó
    • Có thể instance IIS được bind vào một virtual host cụ thể và do header Host trong yêu cầu không khớp nên trả về 404
  • Có hai cách tìm vhost ẩn
    • Tìm hostname cần thiết trong subject hoặc SAN của chứng chỉ SSL
    • Nếu chứng chỉ không hữu ích, brute force vhost bằng ffuf và wordlist cho header Host
  • Khi tìm được hostname đúng, ứng dụng thật có thể phản hồi thay vì trả về 404 thông thường

IIS tilde shortname enumeration

  • IIS có thể cho phép liệt kê tên ngắn của file và thư mục bằng các yêu cầu đặc biệt do hành vi kế thừa từ quy tắc tên file DOS 8.3 cũ
  • Ngay cả khi directory listing bị vô hiệu hóa, vẫn có thể lộ các mảnh như WEB~1.CON, GLOBAL~1.ASA, SITEBA~1.ZIP, ADMIN~1
  • shortscan được dùng làm công cụ liệt kê shortname cho IIS
  • burp’s IIS Tilde Enumeration Scanner cũng có thể dùng như một lựa chọn thay thế
  • Có nhiều cách để chuyển tên ngắn thành tên file đầy đủ
    • LLM: sinh các ứng viên tên file có thể chứa mảnh shortname
    • GitHub code search: tìm tên file thực tế dựa trên 6 ký tự đầu trước ~1 và phần mở rộng
    • GSNW: nhận mảnh shortname và thu thập các tên file khớp từ GitHub code search
    • GitHub-IIS-Shortname-Generator: tạo wordlist theo cách tương tự
    • shortnameguesser: truy vấn nhiều nguồn từ output của scanner để tạo wordlist theo mục tiêu
  • Cách tiếp cận BigQuery tìm các đường dẫn file khớp mẫu shortname trong bộ dữ liệu GitHub công khai của Google BigQuery
  • Nếu LLM, GitHub và BigQuery đều thất bại, có thể dùng crunch để tạo wordlist từ các tổ hợp ký tự còn lại rồi thử bằng ffuf
    • Nên kiểm tra cả các biến thể tên file như dấu gạch nối, gạch dưới, khoảng trắng được URL-encode và không có ký tự phân tách
    • Windows cho phép khoảng trắng trong tên file và IIS cũng có thể phục vụ các file như vậy

Fuzzing chuyên biệt cho IIS/.NET

  • Chỉ dùng wordlist thông thường có thể bỏ sót các file và endpoint đặc trưng của hệ sinh thái IIS/.NET
  • Các mục tiêu giá trị cao nên kiểm tra trước gồm có
    • /web.config, /web.config.bak, /web.config.old, /web.config.txt
    • /global.asax
    • /trace.axd
    • /elmah.axd
    • /connectionstrings.config
    • /appsettings.json, /appsettings.Development.json, /appsettings.Staging.json, /appsettings.Production.json, /appsettings.Local.json
    • /secrets.json
    • /WS_FTP.LOG
    • /_vti_pvt/service.cnf
  • trace.axd là ASP.NET trace viewer; nếu được bật, nó có thể làm lộ log request/response gồm header, cookie và đôi khi cả thông tin xác thực
  • elmah.axd có thể còn sót lại như một debug endpoint mà nhà phát triển quên tắt và hiển thị log lỗi
  • Các phần mở rộng nên fuzz riêng cho IIS gồm .asp, .aspx, .ashx, .asmx, .wsdl, .wadl, .config, .xml, .zip, .txt, .dll, .json
  • Một số wordlist hữu ích gồm
    • secLists IIS.txt: gồm các đường dẫn IIS cơ bản, handler phổ biến và file legacy
    • orwa’s iis.txt: được giới thiệu là danh sách IIS dùng trong các chương trình bug bounty thực tế
    • orwa’s aspx.txt: tập trung vào các endpoint .aspx
    • wfuzz iis.txt: danh sách nhỏ tập trung vào các đường dẫn IIS đã biết là dễ lỗi
    • dirbuster-ng iis.txt: danh sách gọn nhắm vào các điểm yếu đặc thù của IIS
    • Assetnote wordlists: được tự động tạo từ dữ liệu crawl thực tế, cập nhật hàng tháng và khuyến nghị dùng các danh sách ASP và ASPX
    • OneListForAll: onelistforallshort.txt phù hợp cho chạy theo mục tiêu, còn danh sách đầy đủ phù hợp cho các lượt chạy dài
  • IIS không phân biệt chữ hoa chữ thường, nên wordlist mixed-case có thể tạo ra các request trùng lặp
    • Có thể dùng danh sách lower-case hoặc chuẩn hóa bằng tr '[:upper:]' '[:lower:]' | sort -u

Lộ web.config và mã nguồn

  • Nếu có thể đọc web.config thông qua path traversal, file backup bị lộ hoặc phát hiện dựa trên shortname, tác động trên mục tiêu IIS có thể rất lớn
  • web.config của IIS có thể chứa machine keys dùng để ký và mã hóa ViewState
  • Nếu có machine keys, có thể giả mạo payload ViewState deserialization độc hại và dẫn tới thực thi mã từ xa qua deserialization
  • ysoserial.net là công cụ hỗ trợ tạo payload khi đã có key
  • Nếu có tham số tải file hoặc đọc file, quy trình thường sẽ thử ../../web.config và các biến thể URL-encoded của nó
  • Tính năng cookieless session legacy của ASP.NET có thể đưa token phiên dạng (S(X)) vào đường dẫn URL
    • Khi IIS loại bỏ segment đó trong quá trình chuẩn hóa đường dẫn, có thể bypass chặn truy cập tới thư mục /bin
    • Bản thân Newtonsoft.Json.dll là thư viện phổ biến nên có thể không chứa bí mật của ứng dụng
    • Nhưng nếu lấy được DLL ứng dụng thực tế, có thể decompile bằng dotPeek hoặc dnSpy để xem thông tin xác thực hardcode, API key, logic endpoint nội bộ và cơ chế xác thực tùy biến

Chuẩn hóa đường dẫn, NTFS, upload, bypass WAF

  • Khi IIS nằm sau reverse proxy hoặc chính nó đóng vai trò reverse proxy, khác biệt trong chuẩn hóa đường dẫn có thể dẫn đến bypass kiểm soát truy cập
    • Proxy có thể coi đường dẫn đã encode là một tài nguyên khác và chuyển tiếp nó, trong khi IIS giải mã %2f thành / và diễn giải traversal để phục vụ đường dẫn được bảo vệ
  • IIS 7.5 và các phiên bản tương tự có thể bị bypass basic authentication thông qua hành vi của NTFS alternate data streams và index allocation
    • Module xác thực có thể không nhận ra đây là đường dẫn được bảo vệ, nhưng hệ thống file lại diễn giải thành thư mục thực
  • Trong tính năng upload file, ngay cả khi .aspx và .asp bị chặn, vẫn có thể có stored XSS qua các phần mở rộng mà IIS mặc định phục vụ dưới dạng HTML
    • Ví dụ phần mở rộng render HTML: .cer, .hxt, .htm
    • Ví dụ phần mở rộng có thể tạo XSS dựa trên XML: .dtd, .mno, .vml, .xsl, .xht, .svg, .xml, .xsd, .xsf, .svgz, .xslt, .wsdl, .xhtml
  • IIS có hành vi loại bỏ dấu chấm ở cuối tên file, nên có thể bypass bộ lọc upload bằng shell.aspx., shell.aspx.., shell.aspx...
  • Các phần mở rộng được nêu cho server-side includes gồm .stm, .shtm, .shtml
  • Khi WAF chặn payload, có thể dùng HTTP Parameter Pollution để chia payload vào các tham số trùng lặp
    • IIS và ASP.NET mặc định nối các giá trị tham số trùng bằng dấu phẩy, nên payload có thể được tái lắp ráp phía sau WAF

Bài học và tài liệu còn lại từ bug bounty trên IIS

Bài viết liên quan

1 bình luận

 
GN⁺ 3 giờ trước
Ý kiến trên Hacker News

  • Lý do đặt một trang đích IIS trước mọi honeypot chính là để dụ đám mũ đen vào
    Chỉ cần nghĩ tới việc chúng đã lãng phí hàng giờ để tự đuổi theo cái đuôi của mình là đã thấy vui rồi

    • Không nên dừng ở đó, sẽ còn thú vị hơn nếu đặt một máy chủ IIS thật ở lớp ngoài, rồi lồng các honeypot kiểu búp bê Matryoshka để xem chúng chui vào được tới đâu
    • Nếu không chạy honeypot trong dải IP của một tổ chức sẵn có thì rốt cuộc chỉ nhận được lưu lượng bot mà thôi
      Đám mũ đen hạng cao nhắm tới mục tiêu lớn, còn hạng thấp thì tập trung vào mồi dễ kiếm tìm được trên Shodan hoặc zero-day ứng dụng mà chúng tự phát hiện ra
    • Nhiễu thực sự là một lớp bảo mật bị đánh giá thấp
    • Tôi mở cổng Plex và Nintendo Switch ra thì bị quét điên cuồng
      Nếu có cách nào chơi khăm đám máy quét cổng thì tôi rất muốn biết thêm
    • Tạo các URL như aspnet_client/admin.php rồi cấu hình để trả về header WebObjects cũng có vẻ là một thú vui hay ho

  • Câu “IIS có hành vi kế thừa từ quy tắc tên tệp DOS 8.3 cũ” khiến tôi tự hỏi liệu điều đó có nghĩa là hành vi của hệ điều hành nền bị lộ ra, nhất là khi document root mặc định của IIS là C:\Inetpub
    Trên Windows 10/11, tên tệp 8.3 mặc định được bật trên ổ C nhưng mặc định tắt trên các ổ khác
    PS> (Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').DisplayVersion → 24H2
    fsutil 8dot3name query C: cho ra 8dot3 name creation is ENABLED, còn fsutil 8dot3name query U: cho ra DISABLED

  • Văn phong của bài này khá kỳ lạ

    • Tôi đã vài lần nghĩ là do Claude viết

  • Ôi, cái này gợi nhớ hẳn về ngày xưa
    Có thời máy quét IIS nhiều đến mức log máy chủ gần như vô dụng
    Từng có một lỗ hổng directory traversal mà chỉ cần URL-encode ../ là xong, và nó đã thiêu rụi cả Internet suốt nhiều tháng

    • Những nỗ lực traversal kiểu đó đến giờ vẫn xuất hiện rất thường xuyên, ngang hàng với các cuộc tấn công script kiddie nhắm vào PHP/WordPress

  • Vẫn còn nơi nào dùng IIS sao?

    • Có chứ. Khi dùng Windows Server và IIS thì đó là máy đã join domain, và thường có SPN dạng HOST/MACHINE.DOMAIN
      Windows service và IIS App Pool Identity đăng nhập bằng (g)MSA hoặc tài khoản ảo (NT Service*), nên môi trường Kerberos được quản lý sẽ vận hành đúng nghĩa mà không phải tự xử lý chuyện đổi mật khẩu 30/60/90 ngày
      Đăng nhập vào MS SQL Server bằng Kerberos, rồi vào luồng OAuth2 của các ứng dụng web khác cũng bằng Kerberos, mọi thứ đều hoạt động rất tự nhiên
      Ngay trong shell Windows mặc định, WinRM cũng dùng được mà gần như không cần cấu hình gì thêm, và về mặt kỹ thuật thì còn có thể vượt qua cả 2FA, bởi vì nó thực sự hoạt động theo kiểu đó
      Trên Linux cũng làm được, nhưng khả năng được cấu hình tử tế còn tùy môi trường làm việc, và theo kinh nghiệm của tôi từ trước tới nay thì xác suất đó không cao
    • Bộ phận IT doanh nghiệp vẫn dùng rất nhiều
    • Tôi thường xuyên nói chuyện với những người vẫn đang chạy IIS trên Windows Server
      Có rất nhiều ứng dụng cũ, và khá nhiều trong số đó cực kỳ quan trọng
    • Một số ngân hàng vẫn dùng IIS
      Nếu là tập đoàn đủ lớn để vận hành intranet, thì ở đâu đó, thậm chí có thể là ở khắp nơi, vẫn đang chạy IIS
      Nó tích hợp tốt với AD nên những việc cực kỳ phức tạp lại trở nên đơn giản đến phi lý
      Thế giới đang chuyển sang AWS nên mức sử dụng có giảm, nhưng như thế cũng chỉ là trói mình vào thêm một sản phẩm độc quyền của một nhà cung cấp khác (Amazon), và điều đó cũng ngớ ngẩn y như vậy. Chỉ khác là lần này bạn còn chẳng sở hữu cả phần cứng
      IT khu vực công rất thích IIS. Nếu nhìn vào các website thuế địa phương hay bất động sản, khả năng cao sẽ thấy đầy script .aspx
      Tôi cũng đã thấy nó ở các ứng dụng web khu vực công tại châu Âu, nơi các ứng dụng .NET tùy biến với backend SQL Server thường vận hành cả bộ máy chính quyền địa phương
      Châu Á, đặc biệt là Trung Quốc và Đài Loan, dường như rất chuộng IIS và dùng nó để host đủ mọi thứ
      Đúng là phần lớn thế giới đã chuyển đi, nhưng vẫn còn một lượng mã legacy khổng lồ chạy trên IIS để vận hành các thành phố và tổ chức quan trọng, và điều đó sẽ không thay đổi
      Nếu bạn nghĩ như vậy đã là tệ, thì vẫn còn những nơi chạy AS/400, Lotus Notes và Novell GroupWise trên web
    • Đúng vậy. Và hỏi từ góc nhìn của người không rành lắm thì bây giờ nên dùng gì?
      Hãy hình dung một công ty nhỏ viết mã .NET Framework cho doanh nghiệp, mọi thứ đều là Windows, khách hàng không chấp nhận cloud, SOAP vẫn là chủ đạo, và người IT duy nhất còn chẳng có thời gian để quan tâm xem từ sau năm 2010 đã xảy ra chuyện gì
      Việc viết lại toàn bộ là bất khả thi trong thực tế, họ vẫn muốn có lợi ích về bảo mật nhưng không có nguồn lực để đào sâu cấu hình, và cũng không thể đặt cược vào thứ phức tạp như Kubernetes

  • Tôi muốn thấy một bài phân tích như thế này về nginx nữa

  • Xét theo tiêu chuẩn trình duyệt desktop nói chung thì thiết kế thật sự rất ổn, và nội dung cũng xuất sắc

    • Tôi không rõ bạn có đang mỉa mai không, nhưng trên trình duyệt desktop của tôi thì sidebar chồng lên panel nội dung, thành ra chữ đè lên chữ
      Dù vậy, ngoài chuyện đó ra thì phần trình bày vẫn khá hợp ý tôi
    • Gọi là “xuất sắc” thì có phần rộng tay đối với nội dung ở mức script kiddie đầu những năm 2000
      Có lẽ tác giả vẫn cần học thêm xem nền văn minh phụ thuộc đến mức nào vào việc con người không vô cớ cư xử tệ với nhau

  • Tôi không hiểu chuyện gì đang xảy ra khi sidebar bên trái lại chồng lên phần văn bản nội dung