IIS 물결표 취약점 수정


9

IIS 서버 중 하나 (IIS 7.5, Server 2008 R2)는 간단한 파일 이름 공개 문제에 대해 "취약성"인 것 같습니다 .

그러나 실제로 문제를 해결하는 데 어려움을 겪고 있습니다. 지금까지

  • 8.3 파일 이름 비활성화, 웹 서버 중지, 사이트 디렉토리 재 작성 및 서비스 다시 시작

  • URL에 물결표에 대한 필터 규칙을 추가했습니다.

여기에 이미지 설명을 입력하십시오

  • 물결표에 대한 필터 규칙을 추가했습니다.

여기에 이미지 설명을 입력하십시오

  • IISRESET 몇 번

  • web.config관련 필터 규칙이 추가 되었는지 확인

.. 그러나 여전히, 나는 내 사이트가 테스트 를 통과하도록 할 수 없습니다 :

java -jar ~/temp/IIS-ShortName-Scanner-master/IIS_shortname_scanner.jar http://www.example.com

[...SNIP...]

Testing request method: "TRACE" with magic part: "/webresource.axd" ...
Testing request method: "DEBUG" with magic part: "" ...
Testing request method: "OPTIONS" with magic part: "" ...
Testing request method: "GET" with magic part: "" ...
Reliable request method was found = GET
Reliable magic part was found = 
144 requests have been sent to the server:

<<< The target website is vulnerable! >>>

이 문제를 해결하려면 어떻게해야합니까?

편집 : 여기 DIR /x에는 8.3 파일 이름을 표시하지에 나타나는 :

여기에 이미지 설명을 입력하십시오

다음은 사이트의 앱 풀입니다 (서버의 다른 모든 사이트는 동일 함).

여기에 이미지 설명을 입력하십시오

EDIT2 : 확인 8.3 파일 이름이 남아 있지 않습니다.

여기에 이미지 설명을 입력하십시오


디렉토리에 8.3 이름이 있는지 다시 확인하는 빠른 방법은 dir /x입니다. 사이트에 여전히 자동 생성 된 8.3 이름이 포함 된 디렉토리에 대한 심볼릭 링크가있을 수 있습니다.
Brian

8.3 파일 이름의 흔적이 없습니다. (
KenD

이 문제에 취약하지 않은 .NET 4.0을 설치하는 것도이 문제의 일반적인 해결 방법입니다. 아직 해봤 어?
HopelessN00b

.Net 4가 설치되고 서버의 모든 응용 프로그램 풀이 사용하도록 설정되어 있습니다 ( .NET Framework v4.0.30319위의 편집에서 스크린 샷 참조).
KenD

4
와. 아마도 여기서 빨대를 잡을지 모르지만 사용중인 취약점 스캐너가 신뢰할 만하다고 확신하십니까? 다른 도구를 사용해 보거나 수동으로 공격을 실행하여 표시되는 내용을보십시오.
HopelessN00b

답변:


6

다음을 사용하여 기존의 짧은 파일 이름을 스캔하십시오 fsutil.

  • fsutil 8dot3name scan /s /v E:\inetpub\wwwroot

그리고 발견되면 제거하십시오.

  • fsutil 8dot3name strip /s /v E:\inetpub\wwwroot

또한 빈 마술 부분 ( magic part: "") 이있는 로그를 보면 POC의 버그 일 수 있습니다. config.xml 의이 줄은 다음에 쉼표가 추가 된 것 같습니다 /webresource.axd.

<entry> key="magicFinalPartList">
 <![CDATA[\a.aspx,\a.asp,/a.aspx,/a.asp,/a.shtml,/a.asmx‌​,/a.ashx,/a.config,/a.php,/a.jpg,/webresource.axd,,/a.xxx]]>
</entry>

나는 dev에게 물었다. 그것에 대해 트위터를 통해 그는 대답했다.

드문 경우이지만 확장이 필요하지 않은 경우 그러나 최근에는 더 많은 문제가 발생했습니다! 이제 제거하겠습니다.

구성 파일에서 제거했습니다. 이번이 두 번째 불만 이었으므로 이번 변경에 적절한시기였습니다.

그래서, 당신은 지금 안전하다고 보입니다 :)


변경 사항이없는 것을 두려워합니다. 원래 게시물의 "EDIT2"를 참조하십시오. (
KenD

1
빈 마법 부분 ( magic part: "")이 있는 로그를 보면 POC의 버그 일 수 있습니다. config.xml 의이 줄은 다음에 쉼표가 추가 된 같습니다 /webresource.axd.<entry key="magicFinalPartList"><![CDATA[\a.aspx,\a.asp,/a.aspx,/a.asp,/a.shtml,/a.asmx,/a.ashx,/a.config,/a.php,/a.jpg,/webresource.axd,,/a.xxx]]></entry>
beatcracker

그건 매우 흥미로운 - "이중 쉼표"잠시 동안 코드에 있었던 것을, 개정을 통해 다시 찾고 있지만. 그것을 제거한다는 것은 명백한 오류없이 테스트가 실행된다는 것을 의미합니다.
KenD

하, 당신은 안전합니다, 업데이트를 참조하십시오!
beatcracker

그 모든 작업과 우리는 모두 안전했습니다 :) 당신의 도움에 감사하고 개발자에게 연락하십시오!
KenD

1

또한 "참고 : NtfsDisable8dot3NameCreation 레지스트리 항목을 변경하면 변경 후 만들어진 파일, 폴더 및 프로필에만 영향을줍니다. 이미 존재하는 파일은 영향을받지 않습니다."

참고 : 8.3 파일 이름 생성을 비활성화하면 Windows에서 파일 성능이 향상되지만 일부 응용 프로그램 (16 비트, 32 비트 또는 64 비트)은 파일 이름이 긴 파일 및 디렉토리를 찾지 못할 수 있습니다.


0

불행히도 이것을 실제로 처리하는 유일한 방법은 Windows 버전에 따라 짜증나는 gyration 세트로 8.3 이름을 생성하는 기능을 비활성화합니다.

사용중인 Windows 버전 :

모든 NTFS 파티션에서 8.3 이름 생성을 비활성화하려면 관리자 권한 명령 프롬프트에서 fsutil.exe behavior set disable8dot3 1을 입력 한 다음 Enter 키를 누릅니다.

출처 : http://support.microsoft.com/kb/121007


링크 한 기사에서는 8.3 파일 이름 생성을 비활성화하는 방법이 아니라 문제를 해결하는 이유를 설명합니다.
Michael Hampton

이미 8.3 파일 이름을 사용 중지 dir /x했으며 사이트 디렉토리에 짧은 파일 이름이 표시되지 않음
KenD

켄,이게 네가 그랬던 방법 이었 니?
Dave Holland

네; 레지스트리 설정에 대한 참조도 보았지만 fsutil명령은 해당 키를 설정하는 것으로 보입니다.
KenD

0

스크립트가 제대로 작동하고 네트워크가 어떻게 설정되어 있는지 정확히 알지 못하지만 IIS 서버 앞에서 무언가를 필터링하는 방법 (가상 컴퓨터의 가상 장치 일지라도)은 어떻습니까? 즉, 특정 문제와 관련된 트래픽을 구체적으로 삭제하는 규칙으로 IPS를 설정 했습니까?

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.