보안글2009.12.30 14:00

 많은 보안관련 사이트에서 IIS 의 파일확장자 우회를 통한 취약점에 대한 이야기가 많습니다.
IIS 6(window2003) 이하 버전 에서만 이러한 현상이 벌어진다고 하는데, 테스트를 해보니 그렇지않았습니다.

IIS5 (window 2000) 버전에서는 이러한 증상이 해당되지 않았습니다.[각주:1]
IIS 5 파일확장자 우회취약점 캡춰


하지만 IIS 6 에서는 tt.asp 의 파일명을 tt.asp;.jpg 로 변경하더라도 ASP 파일처럼 동작을 합니다. [각주:2] 닷넷파일은 확장자를 인식하지 못하였습니다.


참조



추가.
2010.01.02 기능상의 버그일뿐 취약점은 아니라고 합니다.
참조
Public disclosure of IIS security issue with semi-colons in URL - IIS 블로그
URL에 세미콜론이 있는 경우 IIS 6.0의 처리 문제 - Secre Korea 블로그
  1. 기본 OS 설치에 IIS 만 올린 상태인데 ASP 파일처럼 사용되기는 커녕 텍스트파일처럼 사용이 됩니다. [본문으로]
  2. IIS5 버전과 IIS6 버전의 ASP.dll 파일이 버전이 다릅니다. IIS5의 asp.dll 버전은 5.0.2195.6672 이며, IIS6의 asp.dll 버전은 6.0.3790.3050 입니다. [본문으로]
Posted by Zasfe
보안글2009.02.04 14:00

홈페이지 보안 강화 도구 캐슬(CASTLE, 이하 캐슬) 에 의해 접근이 차단이 되는 경우, 특정 이미지를 포함하는 페이지를 보여주거나 경고창을 띄우도록 되어 있습니다.

지난번 포스트에서 이야기했듯이 특정 이미지가 포함되어서 캐슬설치 경로가 노출이 될 가능성이 있었습니다.
메세지모드로 탐지를 할경우 다음 이미지와 같은 메세지가 표시가 됩니다.

홈페이지 보안강화 도구 캐슬 - 차단 메세지

차단 메세지

저 이미지의 경로가 어디로 되어 있는지 확인해보면 [캐슬설치폴더/img/sorry.gif] 로 되어 있습니다.

차단 메세지

캐슬공개된 홈페이지 보안 강화 도구 입니다. 다운을 받아서 누구나 내용을 분석할수 있으며, 캐슬의 있을지모를 버그를 발견할수도 있습니다. 버그는 논의로 치더라도 설정파일이 어디에 있는지는 바로 확인이 가능합니다.

설정파일은 [캐슬 설치폴더/castle_policy.asp] 입니다. 물론 캐슬설치 전제조건인 CAPICOM.Utilities 를 이용해서 base64로 인코딩되어 있기때문에 사람이 알아볼수 있는 내용으로 변경하는 디코딩을 해야합니다. 다만, 직접적인 페이지접근으로는 인증때문에 내용이 보이지 않습니다.[주:내용자체가 인코딩된 내용이기때문에 디코딩하기전까지는 확인하기 어렵습니다.]

그렇기 때문에 메세지 모드으로 사용할 경우, 캐슬의 기본 이미지가 아닌 사용자가 임의로 이미지로 변경하는 편이 보다 나은 보안을 유지하실수가 있습니다.

  1. 캐슬 설치폴더/castle_referee.asp 를 좋아하는 편집기(예: Acroedit )로 연다.
  2. 이 파일중 136번째줄의 부분을 원하는 경로의 이미지로 변경한다
    변경전
    136:        Response.Write("<center><br><br><br><img src=" & error_img & "></center>")

    변경후
    136:        Response.Write("<center><br><br><br><img src=/img/error.gif></center>")
관련 링크
    [tag]홈페이지 보안 강화도구|10|date|asc[/tag]
Posted by Zasfe
보안글2009.01.30 16:05

이전에 배포하던 웹쉘 탐지 프로그램(Whistl)[주:물론 사용자동의는 구하지만 검색된 웹쉘로 추측되는 정보를 추후 동의 사용자동의 없이 타서버로 전송된다는것은 그다지 유쾌하지 않은 기억이였습니다.]에 대해서 안좋은 기억이 있었는데,지난 1월 20일에 인터넷침해사고대응센터(http://www.krcert.or.kt) 에서는 홈페이지 보안 강화 도구(CASTLE) 를 보급하기 시작했습니다.

많은 분들이 설치가이드나 FaQ, 등을 참고하여서 포스팅을 하고 있기때문에 많은 분들이 이런게 있다라는 것에 대해서는 보안에 관심이 있는 관련업계분들은 들어보셨으리라 생각합니다.

그래서 설치되는 부분의 소스를 분석해보고 설치후 약간의 악의적인 접근을 시도하면서 몇가지 겪은점에 대해서 이야기를 해보겠습니다.

홈페이지 보안 강화도구(CASTLE)

CASTLE 다운로드(ASP, PHP, JSP)
CASTLE 사용자 설명서 다운로드
CASTLE 설치 가이드 다운로드
CASTLE FAQ 다운로드

□ CASTLE의 주요기능
o 보안성 강화
- OWASP 10대 주요 취약점 해결
- 소스코드 수준의 웹 어플리케이션 보안성 강화

o 사용자 편리성 강화
- 관리기능으로 편리한 정책 설정 지원
- 운영 중인 프로그램 소스의 최소 수정으로도 적용 가능
o 높은 호환성 지원

- 다양한 웹 서버 환경과 웹 어플리케이션에서 동작할 수 있는 호환성 지원

□ 기대효과
o CASTLE 확산으로 국내 웹 어플리케이션의 보안성 향상
o 개발자들은 개발 단계에서부터 CASTLE 통합적으로 적용하여 보안성 강화
o 서버 관리자들은 편리한 사용과정을 통해 기존 웹 어플리케이션 수정용이

일단 제가 직접 실행해보고 느낀점은 편하기는 한데, 사용중인 사이트가 개별적인 단일파일로 이루어진 구조라면 사용이 좀 어렵지 번거롭다는 것입니다. 왜냐하면 설치 가이드를 보시면 아시겠지만, CASTLE 소스로 연결(include)를 하는 부분이 있는데, 몇개의 파일을 연결(include) 하는 는 구조일경우에는 정말 편하게 소스몇줄 추가하는 것으로 가능하여서 손쉬운 적용이 가능하지만 그렇지 않은 사이트는 어쩔수 없이 모든 소스를 수정하는 번거로운 작업을 감수해야 하기 때문입니다.

<%
' 설치시 추가되어야 하는 소스 예제
' 설치 디렉토리가 castle-asp 인 경우
Application("CASTLE_ASP_VERSION_BASE_DIR") = "castle-asp"
Server.Execute(Application("CASTLE_ASP_VERSION_BASE_DIR") & "/castle_referee.asp")
%>

차라리 소스파일들이 각기 다른 파일로 이루어져있다면 그나마 사이트내 모든 asp 파일을 찾은 다음, 최상단에 위의 코드를 추가하는 방법으로 처리할수도 있습니다.

(테스트를 해보니 중복으로 CASTLE에 연결되어 있어도 사용상에는 문제가 없습니다. 2번 중복으로 CASTLE에 연결하는 테스트를하면서 우려했던 로그 2방찍기도 발견되지 않았습니다. 원래 되어야 하는거 아닌가요.? ;; )

- 차후 소스분석후 이부분에 대한 내용을 올리도록 하겠습니다.

간단요약

홈페이지 보안 강화도구(CASTLE)
  1. 장점
    1. 웹페이지로 이루어진 간단한 관리자 페이지.
    2. 모드설정을 통한 사용시 발생할수 있는 문제에 대한 정책적용결과에 대한 예측 가능.
    3. Webknight 처럼 서버관리자를 통하지 않고 직접적인 설정을 통한 빠른 대처가능.
    4. 서비스의 중단없는 빠른 차단효과
  2. 단점
    1. 소스를 연결(include)를 사용하지 않을 경우, 일괄적으로 모든 웹페이지소스에 코드추가를 하여야 하는 불편함.
    2. txt 파일로의 로그 기록을 통한 통계의 어려움.
    3. 정규식을 통한 차단이기때문에 추가적인 정책설정을 위해서는 반드시 정규식에 대한 이해가 필요.
    4. GET, POST, COOKIE(쿠키) 에 대한 개별 설정 불가.
  3. 추가 개선되어야할 부분
    1. 문제발생에 대한 경고문구의 수정불가. ( 소스수정을 통해서만 가능 )
    2. 에러메시지를 표시하는 부분에서 캐슬의 설치경로 노출가능성 있음. ( 텍스트등의 문자로만 표시할수 있는 기능이필요)

관련 링크
    [tag]홈페이지 보안 강화도구|10|date|asc[/tag]
Posted by Zasfe
보안글2009.01.02 17:23

웹해킹 파일을 분석할때에는 반드시 외부 네트워크와는 분리된 테스트 서버에서 작업을 하시기 바랍니다. 예전에 발견한 웹해킹파일에서 내용을 분석하던 중에 iframe 태그를 삽입시키는 경우가 있기때문입니다.  Virtual PC, VirtualBox, Vmware 등을 이용한 가상화 머신을 이용하시는 방법을 권장하여 드립니다.

제가 확인한 소스의 주요은 다음과 같습니다.

  1. 파일 브라우징 및 특정 파일 검색
  2. 네트워크 정보 출력
  3. 프로세스 정보 출력
  4. 서비스 정보 출력
  5. 컴퓨터 이름 출력
  6. 컴퓨터 계정정보 출력
  7. DB 접속 및  SQL 쿼리
  8. 디스크 용량 / 이름 / 타입 정보 출력
  9. IIS 버젼 및 스크립트 버젼정보 출력
  10. FileSystemObject 등의 개체 생성 테스트
  11. 터미널서비스 포트번호 / 자동로그인 정보 출력
  12. 서버내 스크립트 실행
  13. 파일 업로드 / 수정 / 삭제
  14. 포트 스캔
  15. 네트워크정보(dns, gateway, nameserver, TCP/UDP 접속허용 포트정보)
  16. Serv-U 계정생성
  17. 외부사이트 내용의 웹서버내 저장
  18. 계정 생성 및 패스워드 변경
  19. 사이트소스에 iframe 태그 추가

위의 기능은 최근에 발견된 하나의 웹쉘(webshell) 에서 발견한 내용입니다. 물론 인코딩되어 있기때문에 문자열로 검색하여도 찾을수 없는 파일입니다.

암호화되어 있는 웹쉘소스

암호화되어 있는 웹쉘소스

막을수 있는 가장 좋은 방법은 IIS 내에서 실행권한을 제한하는 것입니다.

IIS 실행권한 제한

IIS 실행권한 제한


Posted by Zasfe
보안글2008.11.04 20:39

내 웹사이트가 있는 서버 관리자는 보안을 모른다?

일단 보안의 정의부터 간단히 알아보면 다음과 같습니다.

위키백과
보안
위키백과 ― 우리 모두의 백과사전.

보안(保安)은 위험이나 손실로부터 보호 받는 상태를 가리킨다. 일반적으로 보안은 안전과 비슷한 개념을 가진다. 이 두 용어는 밖의 위험으로부터 보호된다는 것을 강조하는 느낌을 준다. 보호 상태에 있는 개인이나 활동은 보안 파괴에 책임을 진다.
보안이 안전과 동의어로 쓰이기도 하지만, 보안이라는 기술적 용어는 무언가가 안전하지 않으나 안전해야 함을 뜻한다. 전자 통신에서, 보안이라는 용어는 다음과 같이 정의한다:
- 불의의 행위나 영향으로부터 침입 상태를 보증하는 보호 기준의 확립과 유지 보수의 결과를 낳는 상태
- 권한이 없는 사람들이 국제 보안을 지키는 공식 정보에 접근하지 못하도록 하는 상태

보안은 권한이 없는 사람들로부터 정보를 접근하지 못하게 하고 상태를 보호하는것 으로 간단히 말하면 내 소중한 자료에 허락하지 않은 사람이 손대지 못하는 것입니다. 이렇듯 보안이란것은 권한이 있고 없고를 분명히 정해야 하며, 그에따라서 허용할지, 말아야 할지 조치를 취해야 합니다.

웹서비스에서의 보안은 어떨까요..

일단 웹서비스라는것에 대해서 관련된 사람들을 그룹지어보면 서버를 운영하는 서버관리자, 웹사이트를 운영하는 사이트운영자, 웹사이트를 개발하는 개발자 등이 있습니다. ( 그룹지어지지 못한 분들은 이글의 논외부분이고 보안보다는 아리따움이나 독특한 사이트를 만드시는 분들이기때문에 제외하였습니다. ) 그리고 사이트를 몇년 운영하신 분들은 개발자가 없는 형태로 서버관리자와 사이트운영자만 있는 곳도 있습니다. 이들은 각자에 맞는 웹서비스에서의 역활 충실할때 웹서비스에서도 서로가 만족할만한 결과가 나타나게 됩니다. 물론 웹서비스 보안도 마찬가지 입니다. 서버관리자의 정기적인 서버보안설정과 신속한 패치, 웹사이트 운영자의 내부정보관리, 개발자의 웹서비스 유지보수 및 입력값등의 데이터검증 등이 이루어질때 만족할만한 웹서비스 보안이 이루어졌다라고 말할수 있을것입니다.

하지만 요즘 유행하는 'SQL 인젝션' 을 당해서 데이터가 변조되거나 정상적인 사이트 운영이 어려울때, 사이트 운영자는 서버관리자에게 변경한것이 없는데 문제가 생겼다며 클레임을 합니다. 하지만 서버관리자는 서버의 상태나 네트워크접근에 관련된 부분까지 확인해도 별문제가 없다는 결과를 사이트 운영자에게 설명합니다. 사이트 운영자는 머리로는 이해를 해도(못하는 분들도 상당히 많다는것에 놀란적은 있습니다.) 답답함에 비용지불에 대한 대가를, 서버관리자는 서버상의 문제점이 아니고 특정사이트만의 문제라는것을 이야기하게 됩니다. 그냥 보기에도 완전 다른 이야기입니다.

그런데 이와중에 빠진 분들이 있습니다. 사이트를 만든 개발자들입니다.
물론 사이트 운영에 필요한 유지보수라고 하면서 아무것도 안하고 돈만 잡아먹는 비용이 아까워서 해고를 한경우도 있을수 있고, 나름대로의 사정에 의해서 업무인계도 못한 경우도 있을수 있습니다. 그리고 정말 소수라고 생각하고 싶은 보안은 생각하기엔 너무 바쁜 개발자일수도 있습니다.

'SQL 인젝션' 은 웹서비스의 취약점을 이용한 공격입니다.웹사이트를 접근하는 어떠한 의도를 가진 누군가가 인위적으로 수정을 가한 값을 정상적인 값으로 사용하기때문에 발생하는 것입니다. 웹서비스를 하는 이상 웹사이트로의 접근을 제한하는것은 소비자를 제한하는 결과와 같아질수 있고, 이는 매출 창출을 위한 행동이라고 볼수 없습니다. 그렇다면 웹서비스를 이용해서 매출을 창출하는 소비자들과 웹사이트 운영자/개발자가 의도하지 않은 접근을 시도하는 사용자를 어떻게 구분하시겠습니까?

" 의도하지 않는 접근을 제한하면 될것입니다. "
이부분은 웹사이트 개발자들이라면, 아니시더라도 조금만 고민해보면 생각해낼수 있는 문제입니다. 바로 입력되는 값의 검증만 되어도 이러한 사용자는 걱정하지 않아도 될것입니다.

그렇다면 서버관리자는 아무런 조치를 하지 않는 것일까요?
제가 아는한 많은 분들도 이러한 문제로 서버상의 보안에 대해서 고민을 하고, 여러가지 방법으로 이를 차단하기 위해 노력을 합니다. 하지만 개발자의 취향과 형식을 모두 갖춘 많은 웹사이트들을 서버관리자가 의도하지 않은 사용자의 접근을 제한하는것은 한계가 있기 마련입니다. 즉, 보다 근본적인 원인을 찾아서 제거해야 안전한 웹서비스를 운영할수가 있게 되는것입니다.

Mass SQL Injection 이라는것이 있습니다. 올해 이전만 하더라도 바로 확인이 가능한 방법을 이용했습니다. 요근래는 정확히는 10월 19일정도 부터 cookie 를 이용해서 웹사이트에 특정 스크립트를 추가하는 추세로 변경되었습니다. 사용자로부터 입력받는 값을 항상 A=A 라는 식으로 생각하고 제작된 사이트의 대다수가 이러한 취약점을 이용해서 사이트에 스크립트가 추가되었고, 그것을 모르고 방문한 소비자들의 PC에 악성코드를 설치하는 것은 결코 서버관리자도, 사이트운영자도, 사이트개발자도 원하는 일은 아닐것입니다.


Posted by Zasfe

티스토리 툴바