재미와 징역형을 부르는 IIS 서버 정찰

 (mll.sh)
1P by GN⁺ | ★ favorite | 댓글 1개
  • IIS 기본 화면은 막다른 길이 아니라 버그 바운티 정찰의 출발점이며, Shodan·Google dork·응답 헤더로 노출 서버와 숨은 vhost를 좁혀갈 수 있음
  • HTTP/1.0 요청, HTTPAPI 2.0 404, SSL 인증서, Host 헤더 브루트포싱은 내부 IP·Exchange 호스트명·가상 호스트를 찾는 초기 단서가 됨
  • IIS의 DOS 8.3 기반 tilde shortname enumeration은 디렉터리 리스팅이 꺼져 있어도 짧은 파일·디렉터리 이름을 드러낼 수 있고, GitHub 검색·BigQuery·LLM·crunch로 전체 이름 후보를 추정함
  • IIS/.NET 특화 퍼징은 web.config, trace.axd, elmah.axd, appsettings.*.json, .aspx/.ashx/.asmx/.config 같은 고가치 경로와 확장자를 먼저 겨냥함
  • web.config 노출, cookieless session 경로 정규화, reverse proxy path confusion, NTFS alternate data stream, 업로드 확장자 우회, HPP는 설정 오류와 레거시 동작이 공격면으로 이어질 수 있음을 보여줌

IIS 서버를 찾아내는 정찰 방법

  • IIS 대상은 검색 엔진과 인터넷 자산 검색 서비스에서 먼저 찾을 수 있음
  • Shodan 쿼리는 대상 도메인의 SSL 인증서, 조직명, http.title:"IIS" 조합으로 IIS 서버를 좁히는 방식임
    • 예시 대상에는 staging 서버, 잊힌 관리자 패널, 인터넷에 노출된 내부 도구가 포함됨
    • Shodan 외에 fofa, censys, netlas, odin도 서로 다른 인터넷 인덱스를 제공함
  • Google dorking은 IIS 흔적이 인덱싱된 페이지를 찾는 데 쓰임
    • aspnet_client 폴더와 _vti_bin은 IIS 신호로 다뤄짐
    • ext:aspx는 ASP.NET 페이지를 찾고, 그 아래에 IIS가 있음을 암시함
    • site:*.target.com, site:*.*.target.com 형태의 와일드카드 검색은 기본 서브도메인 열거가 놓친 중첩 서브도메인을 찾는 데 쓰임
  • 응답 헤더는 IIS 식별의 가장 쉬운 단서임
    • Server: Microsoft-IIS/10.0
    • X-Powered-By: ASP.NET
    • 대규모 확인에는 httpx나 nuclei로 IIS 대상 목록을 만들 수 있음

IIS 확인 뒤 얻는 초기 단서

  • 일부 IIS 구성, 특히 Exchange 또는 OWA 프런트는 HTTP/1.0 요청에 내부 정보를 노출할 수 있음
  • Location 헤더에 https://192.168.5.237/owa/ 같은 내부 IP가 담길 수 있음
  • X-FEServer 헤더는 Exchange 서버의 내부 호스트명을 드러낼 수 있음
  • 이런 정보는 이후 단계에서 활용 가능한 정보 노출로 이어짐

자동화와 숨은 가상 호스트 찾기

  • IIS 대상 목록을 확보한 뒤 nuclei를 microsoft, windows, asp, aspx, iis, azure, config, exposure 같은 태그로 실행해 반복 작업을 줄일 수 있음
  • HTTPAPI 2.0 404는 실제로 아무것도 없다는 뜻이 아닐 수 있음
    • IIS 인스턴스가 특정 가상 호스트에 바인딩돼 있고, 요청의 Host 헤더가 맞지 않아 404가 나올 수 있음
  • 숨은 vhost를 찾는 방식은 두 가지임
    • SSL 인증서의 subject 또는 SAN 필드에서 필요한 호스트명을 찾음
    • 인증서가 도움이 되지 않으면 ffuf와 Host 헤더 wordlist로 vhost를 브루트포싱함
  • 맞는 호스트명을 찾으면 일반 404 대신 실제 애플리케이션이 응답할 수 있음

IIS tilde shortname enumeration

  • IIS는 오래된 DOS 8.3 파일명 규칙에서 이어진 동작 때문에 특수 요청으로 파일과 디렉터리의 짧은 이름을 열거할 수 있음
  • 디렉터리 리스팅이 비활성화돼 있어도 WEB~1.CON, GLOBAL~1.ASA, SITEBA~1.ZIP, ADMIN~1 같은 조각이 드러날 수 있음
  • shortscan은 IIS shortname 열거 도구로 사용됨
  • burp’s IIS Tilde Enumeration Scanner도 대안으로 활용할 수 있음
  • 짧은 이름을 전체 파일명으로 바꾸는 방법은 여러 가지임
    • LLM: shortname 조각을 포함하는 가능한 파일명 후보를 생성함
    • GitHub code search: ~1 앞의 첫 6글자와 확장자를 기준으로 실제 파일명을 검색함
    • GSNW: shortname 조각을 받아 GitHub code search에서 매칭 파일명을 수집함
    • GitHub-IIS-Shortname-Generator: 유사한 방식으로 단어 목록을 생성함
    • shortnameguesser: scanner 출력에서 여러 소스를 질의해 타깃 wordlist를 만듦
  • BigQuery 방식은 Google BigQuery의 공개 GitHub 데이터셋에서 shortname 패턴과 맞는 파일 경로를 찾음
  • LLM, GitHub, BigQuery가 실패하면 crunch로 남은 문자열 조합 wordlist를 만들고 ffuf로 시도함
    • 하이픈, 언더스코어, URL 인코딩된 공백, 구분자 없음 같은 파일명 변형을 함께 확인함
    • Windows는 파일명 공백을 허용하고 IIS도 이를 제공할 수 있음

IIS/.NET 특화 퍼징

  • 일반 wordlist만으로는 IIS/.NET 생태계의 고유 파일과 엔드포인트를 놓칠 수 있음
  • 우선 확인할 고가치 대상에는 다음이 포함됨
    • /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는 ASP.NET trace viewer이며, 활성화돼 있으면 헤더·쿠키·때로는 자격 증명을 포함한 요청/응답 로그가 노출될 수 있음
  • elmah.axd는 개발자가 끄지 않은 디버그 엔드포인트로 남아 오류 로그를 보여줄 수 있음
  • IIS 특화 확장자 퍼징 대상에는 .asp, .aspx, .ashx, .asmx, .wsdl, .wadl, .config, .xml, .zip, .txt, .dll, .json이 포함됨
  • 활용할 만한 wordlist는 다음과 같음
    • secLists IIS.txt: 기본 IIS 경로, 일반 핸들러, 레거시 파일을 포함함
    • orwa’s iis.txt: 실제 버그 바운티 프로그램에서 사용된 IIS 목록으로 소개됨
    • orwa’s aspx.txt: .aspx 엔드포인트 중심 목록임
    • wfuzz iis.txt: 알려진 취약 IIS 경로에 초점을 둔 작은 목록임
    • dirbuster-ng iis.txt: IIS 특화 약점을 겨냥한 compact 목록임
    • Assetnote wordlists: 실제 크롤링 데이터에서 자동 생성되고 매월 갱신되며, ASP와 ASPX 목록을 권장함
    • OneListForAll: onelistforallshort.txt는 타깃 실행에, 전체 목록은 장시간 실행에 쓰임
  • IIS는 대소문자를 구분하지 않으므로 mixed-case wordlist는 중복 요청을 만들 수 있음
    • lower-case 목록을 쓰거나 tr '[:upper:]' '[:lower:]' | sort -u로 정규화하는 방식이 쓰임

web.config와 코드 노출

  • web.config를 path traversal, 잘못 노출된 백업 파일, shortname 기반 발견으로 읽을 수 있으면 IIS 대상에서 영향이 커질 수 있음
  • IIS web.config에는 ViewState 서명과 암호화에 쓰이는 machine keys가 들어 있을 수 있음
  • machine keys가 있으면 악성 직렬화 ViewState payload를 위조해 deserialization 기반 원격 코드 실행으로 이어질 수 있음
  • ysoserial.net은 key가 있을 때 payload 생성을 돕는 도구임
  • 파일 다운로드나 파일 읽기 파라미터가 있으면 ../../web.config 및 URL 인코딩 변형을 시도하는 흐름으로 이어짐
  • ASP.NET의 레거시 cookieless session 기능은 (S(X)) 형태의 세션 토큰을 URL 경로에 넣을 수 있음
    • IIS가 해당 세그먼트를 경로 정규화 중 제거하면서 /bin 디렉터리 접근 차단을 우회할 수 있음
    • Newtonsoft.Json.dll 자체는 기본 라이브러리라 애플리케이션 비밀을 담지 않을 수 있음
    • 실제 애플리케이션 DLL을 받으면 dotPeek이나 dnSpy로 디컴파일해 하드코딩된 자격 증명, API 키, 내부 엔드포인트 로직, 커스텀 인증 구현을 볼 수 있음

경로 정규화, NTFS, 업로드, WAF 우회

  • IIS가 reverse proxy 뒤에 있거나 reverse proxy 역할을 할 때 경로 정규화 차이가 접근 제어 우회로 이어질 수 있음
    • proxy는 인코딩된 경로를 다른 리소스로 보고 전달하지만, IIS는 %2f를 /로 디코딩하고 traversal을 해석해 보호 경로를 제공할 수 있음
  • IIS 7.5와 유사 버전은 NTFS alternate data streams와 index allocation 동작으로 basic authentication 우회가 가능할 수 있음
    • 인증 모듈은 보호 경로로 인식하지 못하지만 파일 시스템은 실제 디렉터리로 해석할 수 있음
  • 파일 업로드 기능에서는 .aspx, .asp가 차단돼도 IIS가 기본적으로 HTML로 제공하는 확장자를 통해 stored XSS가 가능할 수 있음
    • HTML 렌더링 확장자 예: .cer, .hxt, .htm
    • XML 기반 XSS 벡터 확장자 예: .dtd, .mno, .vml, .xsl, .xht, .svg, .xml, .xsd, .xsf, .svgz, .xslt, .wsdl, .xhtml
  • IIS는 파일명 끝의 점을 제거하는 동작이 있어 shell.aspx., shell.aspx.., shell.aspx... 같은 업로드 필터 우회가 가능할 수 있음
  • server-side includes 대상으로 .stm, .shtm, .shtml 확장자가 제시됨
  • WAF가 payload를 막을 때 HTTP Parameter Pollution으로 중복 파라미터에 payload를 나눠 담을 수 있음
    • IIS와 ASP.NET은 기본적으로 중복 파라미터 값을 쉼표로 연결하며, WAF 뒤에서 payload가 재조립될 수 있음

IIS 버그 바운티에서 남는 교훈과 자료

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 모든 허니팟 앞에 IIS 랜딩 페이지를 세워두는 이유가 바로 블랙햇들을 끌어들이기 때문임
    그들이 자기 꼬리를 쫓느라 몇 시간을 낭비했다고 생각하면 그렇게 기쁠 수가 없음

    • 거기서 멈출 게 아니라 진짜 IIS 서버를 앞단에 두고, 허니팟을 마트료시카처럼 겹겹이 만들어서 어디까지 들어오는지 보면 재미있겠음
    • 기존 조직의 IP 대역에서 허니팟을 돌리는 게 아니라면 결국 받는 건 봇 트래픽뿐임
      상위권 블랙햇은 큰 표적을 노리고, 하위권은 Shodan에서 찾은 쉬운 먹잇감이나 자신들이 찾은 애플리케이션 제로데이에 집중함
    • 노이즈는 정말 과소평가된 보안 계층임
    • Plex와 Nintendo Switch 포트를 열었더니 스캔이 미친 듯이 들어왔음
      포트 스캐너들을 엿먹일 방법이 있으면 더 알고 싶음
    • aspnet_client/admin.php 같은 URL을 만들고 WebObjects 헤더를 반환하게 해두는 것도 좋은 취미가 될 듯함

  • “IIS가 오래된 DOS 8.3 파일명 규칙에서 물려받은 레거시 동작을 갖고 있다”는 말은, IIS 문서 루트가 기본적으로 C:\Inetpub인 점과 결합해 기저 운영체제 동작이 노출된다는 뜻인지 궁금함
    Windows 10/11에서는 8.3 파일명이 C 드라이브에서는 기본 활성화지만 다른 드라이브에서는 기본 비활성화임
    PS> (Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').DisplayVersion → 24H2
    fsutil 8dot3name query C:는 8dot3 name creation is ENABLED, fsutil 8dot3name query U:는 DISABLED로 나옴

  • 글의 문체가 꽤 특이함

    • 몇 번이나 Claude가 쓴 건가 싶었음

  • 와, 이건 옛날 생각이 확 남
    한때는 IIS 스캐너가 너무 많아서 서버 로그가 사실상 못 쓸 수준이었음
    ../를 URL 인코딩하기만 하면 되는 디렉터리 순회 취약점이 있었고, 몇 달 동안 인터넷 전체를 불태웠음

    • 그런 순회 시도는 지금도 PHP/WordPress 스크립트 키디 공격과 나란히 정말 흔하게 보임

  • 아직도 IIS를 쓰는 곳이 있나?

    • 씀. Windows Server와 IIS를 쓰면 도메인에 가입된 머신이고, 보통 HOST/MACHINE.DOMAIN 형태의 SPN이 있음
      Windows 서비스와 IIS App Pool Identity는 (g)MSA나 가상 계정(NT Service*)으로 로그인하므로, 30/60/90일 비밀번호 교체를 직접 다루지 않고도 관리되는 Kerberos 환경이 제대로 돌아감
      MS SQL Server에 Kerberos로 로그인하고, 다른 웹앱의 OAuth2 흐름에도 Kerberos로 로그인하는 식으로 전부 자연스럽게 작동함
      기본 Windows 셸에서 WinRM도 별다른 설정 없이 쓸 수 있고, 기술적으로는 2FA도 우회할 수 있는데 실제로 그런 식으로 동작하기 때문임
      Linux에서도 가능하냐면 가능하지만, 제대로 설정될 가능성은 근무 환경에 따라 다르고 지금까지의 경험상 높지 않았음
    • 기업 IT 부서에서는 아직 너무 많이 씀
    • Windows Server에서 IIS를 계속 돌리는 사람들과 자주 이야기함
      오래된 앱이 정말 많고, 그중에는 매우 중요한 것도 꽤 있음
    • 일부 은행은 아직 IIS를 씀
      인트라넷을 운영할 만큼 큰 대기업이라면 어딘가에는, 어쩌면 전부에 IIS가 돌아가고 있음
      AD와 잘 통합돼서 아주 복잡한 작업도 말도 안 되게 단순해짐
      세상이 AWS로 옮겨가며 사용량은 줄고 있지만, 그것도 다시 한 벤더의 독점 제품(Amazon)에 묶이는 일이라 똑같이 어리석음. 이번에는 하드웨어도 소유하지 않는다는 차이만 있음
      공공 부문 IT는 IIS를 좋아함. 지방자치단체 세금이나 부동산 웹사이트를 보면 .aspx 스크립트가 잔뜩 있을 가능성이 큼
      유럽 공공 부문 웹앱에서도 봤고, SQL Server 백엔드를 둔 맞춤형 .NET 애플리케이션이 지방정부 전체를 굴리는 경우가 많음
      아시아, 특히 중국과 대만은 IIS를 좋아해서 온갖 것을 호스팅하는 데 쓰는 것처럼 보였음
      세상이 대체로 넘어간 건 맞지만, 도시와 중요한 조직을 굴리는 레거시 코드가 IIS 위에 엄청나게 남아 있고 바뀌지 않을 것임
      그게 나쁘다고 생각한다면, 아직도 웹에서 AS/400, Lotus Notes, Novell GroupWise를 돌리는 곳도 있음
    • 맞음. 그리고 잘 모르는 입장에서 묻자면, 요즘은 뭘 써야 하는 건가?
      작은 회사가 기업용 .NET Framework 코드를 만들고, Windows가 전부이며, 고객이 클라우드를 받아들이지 않고, SOAP가 여전히 주류이고, 유일한 IT 담당자는 2010년 이후 무슨 일이 있었는지 신경 쓸 겨를도 없는 상황을 생각해보면 됨
      전체 재작성은 현실적으로 불가능하고, 보안상 이득은 얻고 싶지만 설정을 깊게 파볼 여력도 없고 Kubernetes 같은 복잡한 것에 베팅할 수도 없음

  • nginx에 대해서도 이런 분석 글을 보고 싶음

  • 전체 데스크톱 브라우저 기준으로는 디자인이 정말 잘 되어 있고, 내용도 훌륭함

    • 비꼬는 건지 모르겠지만, 내 데스크톱 브라우저에서는 사이드바가 본문 패널과 겹쳐서 텍스트 위에 텍스트가 올라감
      그래도 그 외의 프레젠테이션은 마음에 듦
    • “훌륭하다”는 말은 2000년대 초반 스크립트 키디 수준의 내용에는 좀 후한 평가임
      작성자는 문명이 별 이유 없이 서로에게 못되게 굴지 않는 사람들에 얼마나 의존하는지 아직 배워야 할 듯함

  • 왼쪽 사이드바가 본문 텍스트와 겹치는 건 무슨 일인지 모르겠음

답변달기