오늘날 우리들은 홈페이지를 통해서 뉴스를 보고 메일을 확인하는 일들이 일상 화 되었으며, 자신의 개인 블로그 운영을 통하여 많은 정보들을 교환하고 서로의 의견을 주고받고 있습니다. 또한 홈페이지 사용자를 위한 차세대 웹인 Web 2.0에 대한 다양한 논의가 활발히 이루어지고 있어, 대형 포탈 사이트는 관리자만 운영하 는 사이트가 아닌 많은 사용자들이 참여하여 관리되는 사이트로 탈바꿈 하고 있습 니다.
이러한 시점에서 웹 서버와 그 위에서 동작하는 웹 어플리케이션에 대한 보안성 을 높이기 위하여 우리들은 많은 노력을 기울이고 있으며, 특히 많은 사용자가 참 여한다는 점에서 그 중요성도 매우 높다고 할 수 있습니다.
그러나 대부분의 홈페이지들은 디자인을 예쁘게 하고 내용에만 충실하여 보안 은 고려되지 않는 상태에서 개발되고 있는 실정이여서, 일반 해킹보다 쉽고 별도의 해킹도구를 활용하지 않고도 쉽게 공격할 수 있는 웹 해킹이 급증하고 있는 실정입 니다.
이에 과학기술정보보호센터(S&T-SEC)는 최근 일어난 침해시도 사례를 분석하 고, 최신 해킹 기법 연구를 통하여 과학기술분야의 특성에 적합한 주요 웹 취약점 항목(총17개)을 분류하였으며, 취약점 존재에 따른 위험성과 취약점 진단 방법 및 대응 방안을 제시하고자 합니다.
2007. 11. 30 과학기술정보보호센터장
황 일 선
2007년 11월 30일
주관연구기관명 : 한국과학기술정보연구원
주관연구책임자 : 황일선 (고성능연구망사업단 단장) 참 여 연 구 원 : 이혁로(선임기술원) 박학수(선임연구원)
이행곤(선임연구원) 정기문(연 구 원) 최상수(연 구 원) 이호선(연 구 원) 김주범(연 구 원)
웹 취약점 별 대응 매뉴얼
1. 개요 10
가. 개요 10
나. 적용범위 11
다. 활용방법 11
라. 용어정의 11
2. 관리자페이지 노출 취약점 13
가. 설명 13
나. 진단방법 14
다. 대응방안 15
3. 디렉토리 나열 취약점 21
가. 설명 21
나. 진단방법 22
다. 대응방안 31
4. 시스템 관리 취약점 38
가. 설명 38
나. 진단방법 39
다. 대응방안 40
5. WebDAV 취약점 46
가. 설명 46
나. 진단방법 47
다. 대응방안 50
6. 불필요한 Method 허용 취약점 60
가. 설명 60
나. 진단방법 61
다. 대응방안 61
7. 취약한 파일 존재 취약점 64
가. 설명 64
나. 진단방법 64
다. 대응방안 66
8. 계정 관리 취약점 67
가. 설명 67
나. 진단방법 67
다. 대응방안 68
9. 실명인증 취약점 70
가. 설명 70
나. 진단방법 70
다. 대응방안 74
10. 전송 시 개인정보 노출 취약점 75
가. 설명 75
나. 진단방법 77
다. 대응방안 77
11. 파일다운로드 취약점 80
가. 설명 80
나. 진단방법 82
다. 대응방안 90
12. 파일업로드 취약점 91
가. 설명 91
P
Pa arrtt IIIIII 웹 웹 취 취약 약점 점 별 별 대 대응 응 매 매뉴 뉴얼 얼
13. 소스코드 내 중요정보 노출 취약점 96
가. 설명 96
나. 진단방법 96
다. 대응방안 97
14. 공개용 웹 게시판 취약점 98
가. 설명 98
나. 진단방법 99
다. 대응방안 100
15. 크로스사이트스크립트 취약점 101
가. 설명 101
나. 진단방법 101
다. 대응방안 105
16. SQL Injectio(구문삽입) 취약점 106
가. 설명 10 6
나. 진단방법 109
다. 대응방안 110
17. 권한인증 취약점 113
가. 설명 113
나. 진단방법 113
다. 대응방안 117
18. 에러처리 취약점 118
가. 설명 118
나. 진단방법 118
다. 대응방안 119
표 1 설정별 제공되는 헤더 정보 41
표
표 목 목차 차
그림 1 관리자페이지 노출 화면 13
그림 2 관리자 페이지 IP 접근 제한 설정 19
그림 3 디렉토리 리스팅 취약점이 존재하는 웹 페이지(예제) 21 그림 4 기본 웹 사이트 등록 정보의 홈 디렉토리 설정 23 그림 5 웹 루트 디렉토리의 하위 디렉토리 확인(예시) 24 그림 6 디렉토리 리스팅 취약점이 존재하지 않는 웹 페이지(예제) 25 그림 7 디렉토리 리스팅 취약점이 존재하는 웹 페이지(예제) 25 그림 8 URL 주소에서 디렉토리까지만 입력 시 index.html로 자동 연결 26
그림 9 http.conf 파일 내용 27
그림 10 웹루트의 하위 디렉토리 검색 28
그림 11 디렉토리 리스팅 취약점이 존재하지 않는 웹 페이지(예제) 29 그림 12 디렉토리 리스팅 취약점이 존재하는 웹 페이지(예제) 30
그림 13 기본 웹 사이트 등록 정보 창 31
그림 14 기본 웹 사이트 등록 정보에서 디렉토리 검색 불가 설정 화면 32
그림 15 httpd.conf 파일 내용 33
그림 16 hrrp.conf 파일에서 Indexes 설정을 삭제한 화면 34 그림 17 기본 웹 사이트 등록 정보에서 디렉토리 검색 불가 설정 화면 36
그림 18 httpd.conf 파일 내용 37
그림 19 httpd.conf 파일에서 Indexes 설정을 삭제한 화면 37
그림 20 phpinfo 정보 39
그림 21 Error Message 숨기기 43
그림 22 WebDAV를 이용하여 원격에서 웹 페이지를 변경(예제) 46 그림 23 httpext.dll 위치 및 속성 확인 47 그림 24 “httpext.dll 등록 정보”창 48
그림 25 인터넷 정보 서비스 창 49
그림 26 기본 웹 사이트 등록 정보 창 49
그림 27 WebDAV를 중지시키기 위한 1단계 50
그림 28 DWORD 타입의 값을 생성 51
그림 29 DisableWebDAV 파일 51
그림 30 DisableWebDAV 파일의 DWORD 값 편집 52 그림 31 DisableWebDAV의 값을 1로 수정 52
그림 32 httpext.dll 위치 및 속성 53
그림 33 httpext.dll 등록 정보 53
그림 34 인터넷 정보 서비스 창 54
그림 35 기본 웹 사이트 등록 정보 창 55
그림 36 WebDAV를 중지시키기 위한 1단계 55
그림 37 DWORD 타입의 값을 생성 56
그림 38 DisableWdbDAV 파일의 DWORD 값 편집 56 그림 39 DisableWebDAV의 값을 1로 수정 57 그림 40 httpext.dll 위치 및 속성 확인 57
그림 41 httpex.dll 등록 정보 창 58
그림 42 인터넷 정보 서비스 창 58
그림 43 기본 웹 사이트 등록 정보 창 59
그림 44 레지스트리 추가 62
그림 45 WS_FTP의 로그파일(WS_FTP.LOG) 존재로 인하여 서버 절대경로 노출 65 그림 46 테스트 디렉토리에 menu.asp 파일이 불필요하게 존재 65 그림 47 테스트 디렉토리에 불필요한 파일 업로드 write.asp 파일이 존재 66
그림 48 관리자 계정의 취약한 암호 사용 67
그림 49 실명 인증 화면 71
그림 50 실명인증 처리페이지에 대하여 Proxy 툴을 사용하여 소스를 점검 71 그림 51 실명인증 처리를 우회하여 해당 사이트에 접근을 한 화면 72
그림 52 실명인증 화면 73
그림 53 주민등록번호가 아닌 특정 번호 입력 화면 73 그림 54 실명인증 처리 우회하여 해당 페이지 접근한 화면 73
그림 55 회원정보변경 페이지 화면 및 소스 75
그림 56 Paros 툴을 이용한 hidden form 내용 변경 76 그림 57 Paros 툴을 이용하여 ID 및 이름으로 변경된 화면 76 그림 58 공격대상자의 비밀번호 변경을 성공한 화면 77
그림 59 파일 다운로드 경로 입력 화면 80
그
그림 림 목 목차 차
그림 63 상태표시줄에 링크 표시(예제) 83 그림 64 상태표시중에 링크가 나타나지 않는 경우 링크 주소 알아내기 84 그림 65 etc/passwd 파일이 직접 웹 브라우저 화면에 든 모습 89 그림 66 다운로드 스크립트를 통해 파일을 다운받아 읽은 모습 89 그림 67 악성 파일업로드 성공 후 이를 통한 원격 명령 수행(예시) 91 그림 68 게시판에 asp 확장자를 갖는 악성 스크립트 파일 첨부(예제) 93 그림 69 asp확장자를 갖는 악성 스크립트 파일의 첨부 성공(예제) 93 그림 70 asp등과 같은 실행 파일의 업로드가 불가능한 게시판(예제) 94
그림 71 실행 파일 업로드 제한을 위한 경고창 95
그림 72 백업 파일 노출로 인한 소스 코드 열람 96 그림 73 변조된 홈페이지 화면(제로보드 취약점 이용) 99
그림 74 게시판에 스크립트 문장 게시(예제) 102
그림 75 XSS 취약점 존재하는 웹 페이지 103
그림 76 XSS 취약점 존재하는 웹 페이지(변형된 형태) 103 그림 77 XSS 취약점 존재하는 웹 페이지(예제 1) 104 그림 78 XSS 취약점 존재하는 웹 페이지(예제 2) 104 그림 79 관리자 모드 로그린 화면(SQL Injection 취약점 이용) 107
그림 80 정상적인 인증과정을 수행한 화면 107
그림 81 개인정보가 노출된 관리자 모드 화면 108
그림 82 SQL Injection 쿼리를 통한 고객정보 획득 화면 108 그림 83 SQL Injection을 통한 테이블 정보 획득 화면 109 그림 84 에러 메시지를 통한 DB 정보 획득 화면 110
그림 85 홈페이지 자료실 게시글 읽기 114
그림 86 홈페이지 자료실 수정 페이지 접근 114
그림 87 홈페이지 자료실 수정 완료 화면 115
그림 88 게시물 임의적으로 조작(삭제)을 시도하려는 페이지 115
그림 89 해당 쿼리값에 삭제 명령어를 실행 116
그림 90 게시물 삭제 성공 117
그림 91 에러페이지에서 Apache Tomcat의 버전정보 노출 화면 118
홈
페
이
지
보
안
가
이
드
1. 개요
가. 개요
지난 ’04년 말부터 대량으로 발생 했던 홈페이지 침해사고는 국내에서 개발되어 무 료로 배포중인 일부 홈페이지 제작 프로그램의 보안 결함 등을 악용한 것으로 ’05년 1 월 7일에 사이버위협‘주의’경보가 발령된 바 있다. 동 경보는 2월 1일 해제되었지만 이 후에도 동일 원인으로 사고가 빈번하게 발생하고 있다.
위 침해사고에서 보듯이 대부분 홈페이지 해킹사고는 개발 또는 운영 중에 보안 사 항을 소홀히 한 것에서 비롯되는 것으로 많은 개발자가 보안관련 중요도 인식과 전문성 이 부족 하여 보안을 고려한 코딩을 하지 못하고 있기 때문에 발생 한 것이다.
또한, 컨텐츠 관리 등 서비스에만 치중하고 반면 전문성 및 시간부족으로 보안취약 점에 대한 대책을 즉시 강구하지 않는 등 보안 관리를 소홀히 하는 것도 그 원인이라고 할 수 있다.
Ⅲ
.웹
취
약
점
별
대
응
매
뉴
얼
나. 적용범위
과학기술부 산하 정보보호 대상기관에서 기 구축 운영중인 홈페이지와 향후 개편 및 재개발 예정인 홈페이지를 대상으로 한다.
다. 활용방법
본 장에서는 아래와 같이 최근 침해사고 사례 분석을 통하여 주요 웹 취약점 항목(총 17개) 을 분류하였으며, 취약점 존재에 따른 위험성과 취약점 진단 방법 및 대응 방안을 제시 한다.
라. 용어정의
1) WebDAV : Web-based Distributed Authoring and Versioning(웹기반 분산 형 저작 및 버전관리)의 약자로 웹을 통하여 웹서버에 파일을 관리(목록 조회, 수 정, 삭제, 이동 등)할 수 있는확장된 HTTP 프로토콜을 말한다.
2) 소스코드(Source code) : 원시코드라고도 한다. 컴퓨터 프로그램을 기록하고 있 는 텍스트 파일.
3) 제로보드(Zeroboard) : 아이디 zero가 개발하여 무료 배포하는 게시판으로써 PHP와 MySQL이 지원되는 서버에 설치하여 사용하는 게시판
4) 크로스사이트스크립트(Cross Site Scripting) : 게시물에 실행 코드와 태그의 업 로드가 규제되지 않는 경우 이를 악용하여 열람한 타 사용자의 개인용 컴퓨터 (PC)로 부터 정보를 유출할 수 있는 보안 취약점. 게시판에 새 게시물을 작성하여 구분
1 2 3 4 5 6 7 8 9
취약점 명 관리자페이지 노출 취약점 디렉토리 나열 취약점 시스템 관리 취약점 WebDAV 취약점 불필요한 Method 취약점 취약한 파일 존재 취약점 계정 관리 취약점 실명인증 취약점
전송 시 개인정보 노출 취약점
구분 10 11 12 13 14 15 16 17
취약점 명 파일다운로드 취약점 파일업로드 취약점
소스코드 내 중요정보 노출 취약점 공개용 웹 게시판 취약점
크로스사이트스크립트 취약점 SQL Injection(구문삽입) 취약점 권한인증 취약점
에러처리 취약점
홈
페
이
지
보
안
가
이
드
등록할 때와 같이 사용자의 입력을 받아 처리하는 웹 응용 프로그램에서 입력 내 용에 대해 실행 코드인 스크립트의 태그를 적절히 필터링하지 않을 경우에 악의 적인 스크립트가 포함된 게시물을 등록할 수 있어 해당 게시물을 열람하는 일반 사용자의 PC로부터 개인 정보인 쿠키를 유출할 수 있는 등의 피해를 초래할 수 있다. 예를 들어 글쓰기 본문에 다음과 같은 스크립트 문장을 입력했을 때 'XSS 취약점 존재' 경고창이 뜨면 스크립트가 수행된 것이므로 취약점이 있는 것이다.
< script>alert‘( XSS 취약점 존재’) ; < /script>
5) SQL Injection : 웹 클라이언트의 반환 메시지를 이용하여 불법 인증 및 정보를 유출하는 공격. 웹 응용 프로그램에 강제로 구조화 조회 언어(SQL) 구문을 삽입 하여 내부 데이터베이스(DB) 서버의 데이터를 유출 및 변조하고 관리자 인증을 우회할 수도 있다. 이 공격은 MS SQL 서버뿐만 아니라 모든 관계형 데이터베이 스 관리 시스템(RDBMS)에서 가능하다.
Ⅲ
.웹
취
약
점
별
대
응
매
뉴
얼
2. 관리자페이지 노출 취약점
가. 설명
일반적으로 추측하기 쉬운 URL(ex: /admin, /manager)을 사용하고 있어, ID/패 스워드에 대한 크랙 또는 접근 허가 정책에 대해 요청하는 부분의 정보를 변경함으로써 접근이 가능한 경우가 존재한다.
웹 관리자의 권한이 노출될 경우 홈페이지의 변조뿐만 아니라 취약점 정도에 따라서 웹 서버의 권한까지도 노출될 위험성이 존재한다.
◆ 관리자 페이지는 웹 서비스의 사용자나 데이터, 컨텐츠를 손쉽게 관리하 기 위한 목적으로 다양한 기능과 권한을 갖고 있다.
◆ 홈페이지의 운영에 매우 중요한 역할을 하고 있어서 일반사용자는 인증 을 통과하지 못하도록 할 뿐 아니라 일반사용자가 관리자 페이지를 볼 수 없도록 해야 한다.
취
취 약약 점점 요요 약약
[그림 1] 관리자페이지 노출 화면
홈
페
이
지
보
안
가
이
드
나. 진단방법
◆추측 가능한 관리자 페이지를 사용하는지 확인한다.
◆외부망(별도망)에서 관리자 페이지에 접근이 가능한지 확인한다.
(1) Apache의 경우
httpd.conf 환경파일에서 Directory 섹션의 AllowOverride 지시자에서 AuthConfig 또는 All 추가하여 .htaccess를 통하여 인증을 수행하고 있는지 점검한다.
관리자 페이지와 같이 인증이 필요한 디렉토리에 .htaccess 파일을 만들고 admin 계정의 패스워드가 설정되어 있는지 점검한다.
<httpd.conf>
<Directory "/usr/local/apache/KISTIAdmin">
AllowOverride AuthConfig (또는 All) …….
Order Allow,Deny
Allow from 211.111.111.111 111.111.111.111/24
……….
……….
</Directory>
<.htaccess>
AuthType Basic
AuthName "인증이 필요한 관리자 페이지 입니다."
AuthUserFile "/usr/local/apache/auth/.htadmin_pwd"
Require user valid-user
/usr/local/apache/bin/htpasswd -c /usr/local/apache/auth/.htadmin_pwd daumadmin
Ⅲ
.웹
취
약
점
별
대
응
매
뉴
얼
다. 대응방안
(1) 웹 서버 설정 조치 방법
◆관리자 웹 페이지를 분리하여 운영할 시에는 네트워크 범위로 IP 레벨의 접근 권 한을 설정하여 웹 관리자 메뉴 접근을 제한하고, 웹 관리자의 웹 페이지는『SSL』
기술을 이용하여 HTTP over SSL과 같은 데이터 트랜젝션(Transaction)암호화 를 적용한다.
◆『VPN』같은 네트워크 차원의 별도 보안시스템 설치를 권고한다.
◆관리자 계정으로는 외부 사이트에서 접근하는 것을 허용하지 않는 것이 바람직하다.
◆관리자 페이지 경우 원내『IP』에서만 접근이 가능하도록 설정하고, 만일 외부 관 리자의 접근이 반드시 필요한 경우라면, 사이트 관리 권한을 외부로 열어주지 않 고도 가능한 VPN 기술을 사용하면 외부 관리자가 회사 내부(혹은 사이트)네트워 크로 접근가능, 관리자는 보호된 백엔드 연결을 통해 사이트에 접근 가능하다.
◆admin, manager 등과 같이 추측하기 쉬운 디렉토리 및 파일명을 금지한다.
◆관리자 페이지의 경우, 관리자 호스트『IP』만 접근 가능하도록 설정한다.
http://www.abc.com/admin.html http://www.abc.com/admin_main.html http://www.abc.com/admin/index.html http://www.abc.com/admin/login.html http://www.abc.com/master.html http://www.abc.com/master/index.html
홈
페
이
지
보
안
가
이
드
1) 관리자 페이지 접근 통제(IIS)
2) 관리자 페이지 접근통제(Apache)
관리자페이지는 가장 보호되어야 할 페이지로 매우 제한적으로 접근을 허용하여야 한다. 기본적으로 특정 IP Address에서만 접근을 허용하고 그 외의 모든 접근은 차 단하는 것이 바람직하다. 이를 위해 httpd.conf 파일에서 다음과 같이 설정한다.
...
<Directory "/usr/local/www/admin/">
order deny,allow deny from all
allow from 100.100.1000.100 ← 100.100.1000.100에서만 접근 허용
</Directory>
...
다음과 같은 방법으로 [관리자 페이지] 접근을 제한
[설정] → [제어판] → [관리도구] → [인터넷 서비스 관리자] 선택
해당 관리자 페이지 폴더를 선택하고 [등록정보] → [디렉토리 보안] → [IP 주소 및 도메인 이름 제한] → [편집] 선택
액세스 거부를 선택하고 추가 버튼을 선택하여 관리자 호스트IP 또는 서브 넷을 등록
Ⅲ
.웹
취
약
점
별
대
응
매
뉴
얼
(2) 웹 어플리케이션 조치 방법(ASP)
◆웹 관리자 메뉴의 접근을 특정 네트워크 대역으로 제한하여, IP Address까지도 인증요소로 체크하도록 웹 관리자 사용자인터페이스를 개발
◆관리자 인증 후 접속할 수 있는 페이지의 경우 해당 페이지 주소를 직접 입력하여 들어가지 못하도록 관리자 페이지 각각에 대하여 관리자 인증을 위한 세션관리를 해야한다.
접근 통제 정책을 구현하고 있는 코드는 구조화, 모듈화가 되어 있어야 한다.
접근제어가 필요한 모든 페이지에 통제수단(로그인 체크 및 권한 체크)을 구현 특히, 하나의 프로세스가 여러 개의 페이지 또는 모듈로 이루어져 있을 때 권한 체크가 누락되는 경우를 방지하기 위해서 공통 모듈을 사용하는 것을 권장 인증 과정을 처리하는 부분에 Client Side Script(Javascript, VBScript 등)을 사용하면 사용자가 임의로 수정할 수 있으므로 Server Side Script를 통하여 인증 및 필터링 과정이 수행
1) 언어별 안전한 프로그래밍 예(ASP)
<%
If myfunc_userauth(userid, userpw) <> 1 Then // DB에서 사용자 인증 Response.write “인증 실패”
Else
If Request.ServerVariables("REMOTE_ADDR") <> "10.10.1.1" Then // 관리자 IP 확인 Response.write “관리자 IP가 아닙니다.”
Response.write “인증실패”
LogSave(userid, user_ip, 0) // 접속에 실패한 ID 및 IP 기록 Else
Session("logged_in") = 1 // 인증에 성공했을 경우 logged_in 에 1의 값을 셋팅 Session("userid") = userid
Session("user_ip") = Request.ServerVariables("REMOTE_ADDR") LogSave($userid, $user_ip) // 접속에 사용한 ID 및 IP 기록
... 중략 ...
End If End If
%>
홈
페
이
지
보
안
가
이
드
2) 언어별 안전한 프로그래밍 예(PHP)
3) 언어별 안전한 프로그래밍 예(JSP)
<?PHP
@session_start(); // 세션 데이터를 초기화
if(!myfunc_userauth($userid, $userpw) || $_SERVER["REMOTE_ADDR'] != "10.10.1.1") // DB 에서 사용자 인증을 처리, 관리자 IP인지 확인
print "인증 실패";
LogSave(userid, user_ip, 0) // 접속에 실패한 ID 및 IP 기록 exit; // 인증 실패 시 종료
// 인증에 성공한 경우 처리 해야 되는 부분 if (!session_is_registered("logged_in"))
$logged_in = 1; // 인증에 성공했을 경우 logged_in 에 1의 값을 셋팅
$user_ip = $_SERVER["REMOTE_ADDR"];
session_register("logged_in"); // 인증 결과 저장 session_register("userid"); // 사용자 ID를 저장 session_register("user_ip"); // 사용자 IP를 저장
LogSave($userid, $user_ip); // 접속한 사용자 ID 및 IP 기록 ... 중략 ...
<%@ page contentType="text/html;charset=euc-kr" %>
<%@ page import="java.util.* " %>
<%@ page import="java.sql.* " %>
<%
// HttpSession session = request.getSession(true);
String user_ip = request.getRemoteAddr();
// form 에서 사용자 id와 사용자 password를 아래 변수로 전달 if(!myfunc_userauth(userid, userpw) || !user_ip.equals("10.10.1.1")) // DB 에서 사용자 인증을 처리, 관리자 IP인지 확인
out.println "인증 실패";
LogSave(userid, user_ip, 0) // 접속에 실패한 ID 및 IP 기록 else
Ⅲ
.웹
취
약
점
별
대
응
매
뉴
얼
(1) 웹서버 설정 조치방법
◆admin, manager 등과 같이 추측하기 쉬운 디렉토리 및 파일명을 금지
◆관리자 웹 페이지를 분리하여 운영할 시에는 네트워크 범위로 IP 레벨의 접근 권 한을 설정
① 관리자 페이지 접근통제(IIS)
[설정] [제어판] [관리도구] [인터넷 서비스 관리자] 선택
해당 관리자 페이지 폴더를 선택하고 [등록정보] [디렉토리 보안] [IP 주소 및 도메인 이름 제한] [편집] 선택
액세스 거부를 선택하고 추가 버튼을 선택하여 관리자 호스트IP 또는 서브넷을 등록
② 관리자 페이지 접근통제(Apache)
관리자페이지는 가장 보호되어야 할 페이지로 매우 제한적으로 접근을 허용하여야 한다. 기본적으로 특정 IP Address에서만 접근을 허용하고 그 외의 모든 접근은 차 단하는 것이 바람직하다. 이를 위해 httpd.conf 파일에서 다음과 같이 설정한다.
요
요 약 약
http://www.abc.com/admin.html http://www.abc.com/admin_main.html http://www.abc.com/admin/index.html http://www.abc.com/admin/login.html http://www.abc.com/master.html http://www.abc.com/master/index.html
[그림 2] 관리자 페이지 IP 접근 제한 설정
홈
페
이
지
보
안
가
이
드
(2) 웹 어플리케이션 조치 방법
① 웹 관리자 메뉴의 접근을 특정 네트워크 대역으로 제한하여, IP Address까지도 인증요소로 체크하도록 웹 관리자 사용자인터페이스를 개발
...
<Directory "/usr/local/www/admin/">
order deny,allow deny from all
allow from 100.100.1000.100 ← 100.100.1000.100에서만 접근 허용
</Directory>
...
Ⅲ
.웹
취
약
점
별
대
응
매
뉴
얼
3. 디렉토리 나열 취약점
가. 설명
[그림 3]은 디렉토리 리스팅 취약점이 존재하는 웹 페이지의 예시이다. 웹 브라우저 에서 URL 입력란에 파일명 이하를 삭제하고 바로 디렉토리에 접근을 시도하였을 경우 에러 화면이 뜨지 않고 디렉토리의 하위 내용이 보여지면 디렉토리 리스팅 취약점이 존 재하는 것이다. [그림 3]과 같이 하위 디렉토리는 물론 내부의 모든 파일들이 보이게 되 어 공격자는 웹 어플리케이션의 구조를 파악, 민감한 정보가 포함된 설정 파일을 조회,
[그림 3] 디렉토리 리스팅 취약점이 존재하는 웹 페이지(예제)
◆ 홈페이지 속성을 설정하는‘웹사이트 등록정보’에 특정디렉토리에 대하 여‘디렉토리 검색’항목이 체크되어 있거나(IIS 웹서버), ‘httpd.conf 파일’에서‘Indexes’옵션이 ON되어 있는 경우(아파치 웹서버)에
◆ 인터넷 사용자에게 모든 디렉토리 및 파일 목록이 보여지게 되고, 파일 의 열람 및 저장도 가능하게 되어 비공개 자료가 유출될 수 있다.
취
취 약약 점점 요요 약약
홈
페
이
지
보
안
가
이
드
웹에 게시하지 않은 각종 파일을 유출하게 된다.
나. 진단방법
◆웹 브라우저를 통해 직접 웹 페이지에 접속하여 웹 루트(WebRoot)의 하위 디렉 토리를 입력해서 점검한다.
※
※ 주주의의: 하위 디렉토리 중 하나를 골라서 테스트 해 보는 것으로 점검을 끝내는 것 이 아니라 될 수 있으면 여러 하위 디렉토리에 대해 점검한다
(웹 서버 설정에 따라 디렉토리 별로 설정을 달리 하는 것이 가능).
◆각 하위 디렉토리를 입력하기 위해서는 우선 웹 루트 밑에 어떤 하위 디렉토리들 이 존재하는지를 알아야 한다.
◆디렉토리 리스팅 취약점을 확인하기 위해 우선 웹 루트(WebRoot) 디렉토리를 찾 고 그 밑의 각 하위 디렉토리 리스트를 파악하고 각각의 디렉토리에 대해 점검을 해야 한다.
(1) 윈도우 웹 서버
예제 : http://www.sample.co.kr/이란 웹 서버의 웹 루트 밑에 file/이란 디렉토 리가 있다면 웹 브라우저의 URL 주소 입력란에, http://www.sample.co.kr/file/이 라고 입력해 본다. 이 때 file/ 디렉토리의 하위 내용이 모두 화면에 출력된다면 디렉 토리 리스팅 취약점이 존재하는 것이다(반드시 맨 끝에‘/’까지 입력)
하
하위 위 디 디렉 렉토 토리 리 리 리스 스트 트 확 확인 인 방 방법 법
Ⅲ
.웹
취
약
점
별
대
응
매
뉴
얼
◆웹 루트 디렉토리를 확인하기 위해‘기본 웹 사이트 등록 정보’에서‘홈 디렉토리’
부분을 클릭한다.
◆[그림 4]에서‘로컬 경로’란 항목이 웹 루트 디렉토리를 설정하는 부분이다 ([그림 4]의 예에서는‘c:\inetpub\wwwroot’로 되어 있음).
◆IIS 웹 서버를 설치하면 기본적으로‘c:\inetpub\wwwroot’가 웹 루트 디렉토리 로 설정된다. 웹 구축 시 다른 디렉토리로 웹 루트를 설정하였을 수도 있으므로 반드시 이‘홈 디렉토리’항목을 통해 웹 루트 디렉토리를 확인해야 한다.
◆웹 루트 디렉토리 확인이 끝났으면 윈도우 탐색 창을 통해 해당 디렉토리로 이동 하여 웹 루트의 하위 디렉토리들을 확인해 가면서 웹 브라우저를 통해 디렉토리 리스팅 여부를 확인한다
([그림 5]은 웹 루트 디렉토리의 하위 디렉토리를 확인하는 예).
[그림 4] 기본 웹 사이트 등록 정보의 홈 디렉토리 설정
홈
페
이
지
보
안
가
이
드
◆[그림 5]의 예시를 보면, c:\inetpub\wwwroot 밑에 data, images, statistics, viewer 등의 하위 디렉토리가 존재하고 또 각각 하위 디렉토리 밑에 Temp, aggregator, correlator, situator, thread 등의 디렉토리가 존재하는 것을 확 인할 수 있다. 따라서 디렉토리 리스팅 취약점 점검을 위해서 다음과 같은 주소를 웹 브라우저에 차례로 입력하며 확인한다
(반드시 맨 끝에‘/’까지 입력).
[그림 5] 웹 루트 디렉토리의 하위 디렉토리 확인(예시)
웹 서버 URL : http://servername.com일 경우, http://servername.com/data/
http://servername.com/data/Temp/
http://servername.com/images/
http://servername.com/statistics/
http://servername.com/viewer/aggregator/
http://servername.com/viewer/correlator/.
Ⅲ
.웹
취
약
점
별
대
응
매
뉴
◆[그림 6]는 디렉토리 리스팅 취약점이 존재하지 않는 경우의 모습이다.
얼
◆웹 서버에 디렉토리 리스팅 취약점이 존재하지 않으면 [그림 6]의 화면과 같이 에 러 메시지를 표시하게 된다.
◆[그림 7]는 디렉토리 리스팅 취약점이 존재하는 화면 모습이다.
[그림 7] 디렉토리 리스팅 취약점이 존재하는 웹 페이지(예제) [그림 6] 디렉토리 리스팅 취약점이 존재하지 않는 웹 페이지(예제)
홈
페
이
지
보
안
가
이
드
[그림 7]에서 보는 바와 같이 data 디렉토리 밑에 몇 개의 html 파일이 보이고 그 안 에 Temp 디렉토리 그리고 몇 개의 주요 문서가 보인다.
※ 주의: 디렉토리 명까지만 입력하였을 때 어떤 웹 페이지(html 문서)가 자동으 로 화면에 표시될 경우에는 취약점이 존재하지 않는다.
웹 서버 설정에 따라 차이가 있지만 보통 index.html(index.jsp, index.php, index.asp, index.htm 등) 혹은 main.html(main.jsp, main.php, main.asp, main.htm 등) 등이 존재할 경우, URL 입력란에 디렉토리명까지만 입력해도 바로 index.html 및 main.html로 리다이렉트(자동 연결)되는 경우가 있다.
즉, http://www.sample.com/file/을 입력하였을 때 http://www.sample.
com/file/index.html의 웹 페이지 화면이 뜨게 되는 경우에는 취약점이 존재한다고 할 수 없다. [그림 8]은 그 예이다.
[그림 8] URL 주소에서 디렉토리까지만 입력 시 index.html로 자동 연결
Ⅲ
.웹
취
약
점
별
대
응
매
뉴
얼
(2) 리눅스 및 유닉스 웹 서버
◆리눅스 및 유닉스 계열의 운영체제는 주로 아파치(apache) 웹 서버 프로 그램을 통해 웹 서비스를 제공한다. 아파치 서버의 모든 설정은 httpd.conf 파일을 통해 가능하며 httpd.conf 파일의 위치는 운영체제 및 아파치 버전에 따라서 다양하 나 주로 다음 디렉토리 중에 존재한다.
◆파일 위치가 조금 다를 수 있으므로 위 5가지 디렉토리 주변 디렉토리들을 찾아 보면 apache의 httpd.conf 파일을 찾을 수 있다. 초기 설치 시 옵션을 주어 사용 자 임의의 디렉토리에 설치될 수도 있으므로 경우에 따라 설치한 사람에게 문의 해 보는 것이 필요할 수도 있다.
◆httpd.conf 설정 파일에서 DocumentRoot 부분이 바로 웹 루트 디렉 토리를 설 정하는 부분이며, 이 부분을 찾아서 웹 루트 디렉토리를 확인한다 ([그림 9]참조).
※ 참고 : httpd.conf 파일에서‘#’주석이다.
/etc/httpd/conf/httpd.conf /etc/apache/httpd.conf /usr/apache/conf/httpd.conf /usr/local/apache/conf/httpd.conf /usr/lib/apache/conf/httpd.conf
[그림 9] http.conf 파일 내용
홈
페
이
지
보
안
가
이
드
◆[그림 9]을 보면 DocumentRoot 부분에 /var/apache/htdocs라고 적혀 있는 것 을 확인할 수 있다. 즉, 웹 페이지의 모든 파일 및 하위 디렉토리는 /var/apache/htdocs/ 디렉토리에 존재해야 한다는 의미이다.
◆웹 루트로 가서‘ls’명령어를 통해 하위 파일 및 디렉토리 내용을 확인한다.
디렉토리 내용을 리스팅하는 ls 명령어에 _F 옵션을 주면, 하위 디렉토리는‘/’붙어서 리스팅된다. 이를 이용하여 [그림 10]과 같이 웹 루트 디렉토리 구조를 확인할 수 있다.
◆[그림 10]과 같이 웹 루트로 가서(cd /var/apache/htdocs), -F 옵션을 준 ls 명 령어를 입력한다. ls 명령어의 결과를 보면 하위 디렉토리는 디렉토리명 끝에‘/’
붙어서 출력된다.
◆[그림 10]에서는 data, images, statistics 3개의 하위 디렉토리가 존재함을 알 수 있으며, 그리고 하위 디렉토리 중 하나인 data 디렉토리로 가서 역시 ls -F 를 입력 하면 old_data, 문서자료, 보고서, 임시파일 하위 디렉토리가 존재함을 알 수 있다.
[그림 10] 웹루트의 하위 디렉토리 검색
Ⅲ
.웹
취
약
점
별
대
응
매
뉴
얼
◆위의 예시 경우, 디렉토리 리스팅 취약점 점검을 위해서는 다음과 같은 주소들을 웹 브라우저에 차례로 입력하며 확인한다(반드시 맨 끝에‘/’입력).
◆[그림 11]는 디렉토리 리스팅 취약점이 존재하지 않는 경우이다.
◆웹 서버에 디렉토리 리스팅 취약점이 존재하지 않으면 [그림 11]의 화면과 같이 에러 메시지를 표시하게 된다.
웹 서버 URL : http://servername.com이라면, http://servername.com/data/
http://servername.com/images/
http://servername.com/statistics/
http://servername.com/data/old_data/
http://servername.com/data/문서자료/
[그림 11] 디렉토리 리스팅 취약점이 존재하지 않는 웹 페이지(예제)
홈
페
이
지
보
안
가
이
드
◆[그림 12]은 디렉토리 리스팅 취약점이 존재하는 경우이다.
※ 주의 : 디렉토리 명까지만 입력하였을 때 어떤 웹페이지(html 문서)가 화면에 표시될 경우에는 취약점이 존재하지 않는다.
웹 서버 설정에 따라 차이가 있지만 보통 index.html(index.jsp, index.php, index.asp, index.htm 등) 혹은 main.html(main.jsp, main.php, main.asp, main.htm 등) 등이 존재할 경우, URL 입력란에 디렉토리명까지만 입력해도 바로 index.html 및 main.html로 리다이렉트(자동 연결)되는 경우가 있다.
즉, http://www.sample.com/file/을 입력하였을 경우 http://www.
sample.com/file/index.html의 웹 페이지 화면이 뜨게 되는 경우에는 취약 점이 존재 한다고 할 수 없다([그림 8]을 참고).
[그림 12] 디렉토리 리스팅 취약점이 존재하는 웹 페이지(예제)
Ⅲ
.웹
취
약
점
별
대
응
매
뉴
얼
다. 대응방안
취약점이 발견된 경우 아래의 설명에 따라 취약점을 제거하면 된다.
(1) 윈도우 웹 서버
◆[제어판] [관리도구]의[인터넷 서비스 관리자](혹은 [인터넷 정보 서비스]) 메뉴 에서[기본 웹 사이트]의 마우스 오른쪽 클릭, ‘속성’부분을 보면‘기본 웹 사이트 등록 정보’가 나온다.
◆‘기본 웹 사이트 등록 정보’에서‘홈 디렉토리’부분을 클릭하면 [그림 13]과 같은 화면이 나타난다.
[그림 13] 기본 웹 사이트 등록 정보 창
홈
페
이
지
보
안
가
이
드
◆[그림 13]에서 중간에‘디렉토리 검색(B)’이란 옵션이 있는데 바로 이 부분이 웹 브라우저를 통해 디렉토리 리스팅을 가능케 하는 부분이며,
[그림 14]와 같이 이 부분의 체크를 해지한다.
※ 주의 : 옵션 설정을 변경한 후에는 그 내용이 즉시 적용되기 위해서는 위의 [그림 14]에서 화면 아래쪽에 있는‘적용’버튼을 클릭해야 한다.
(2) 리눅스 및 유닉스 웹 서버
◆아파치 서버의 모든 설정은 httpd.conf라는 파일을 통해 가능하다.
httpd.conf 파일은 운영체제 및 아파치 버전에 따라서 다양하나 주로 다음 디렉 토리 중에 존재한다.
[그림 14] 기본 웹 사이트 등록 정보에서 디렉토리 검색 불가 설정 화면
Ⅲ
.웹
취
약
점
별
대
응
매
뉴
얼
◆파일 위치가 조금 다를 수 있으므로 위 5가지 디렉토리 주변 디렉토리들을 찾아 보면 apache의 httpd.conf 파일을 찾을 수 있다. 초기 설치 시 옵션을 주어 사용 자 임의의 디렉토리에 설치될 수도 있으므로 경우에 따라 설치한 사람에게 문의 해 보는 것이 필요할 수도 있다.
◆[그림 15]의 중간에 보면 Options 항목 뒤에 Indexes 옵션이 바로 디렉토리 리스 팅을 가능하게 하는 옵션이다. Indexes 설정을 끄기 위해 Indexes 단어를 지워주 고 파일을 저장하고 설정을 적용하기 위해 웹 서버 데몬을 다시 띄워주어야 한다.
/etc/httpd/conf/httpd.conf /etc/apache/httpd.conf /usr/apache/conf/httpd.conf /usr/local/apache/conf/httpd.conf /usr/lib/apache/conf/httpd.conf
[그림 15] httpd.conf 파일 내용
홈
페
이
지
보
안
가
이
드
※ 주의 : Options 항목은 특정 디렉토리 별로 설정할 수 있게 되어 있기 때문 에 항상 그 설정이 적용될 디렉토리를 명시해 주어야 한다. 현재〔그림 15〕에 서는 Directory “/var/apache/htdocs”같이 웹 루트 디렉토리 필드 안에 Options 항목이 위치되어 있다. 다른 특정 디렉토리 설정에도 Options 항목 을 통해 Indexes가 설정되어 있을지도 모르므로 그러한 부분들을 찾아 확인 하고 지워주어야 한다.
※ 참고 : httpd.conf 설정 파일을 수정한 후에는 웹 데몬을 다시 띄워주어야만 설정이 적용된다. 다음과 같은 방법으로 설정을 다시 띄워줄 수 있다.
◆리눅스 웹 서버의 경우,
/etc/rc.d/init.d/httpd restart [그림 16] http.conf 파일에서 Indexes 설정을 삭제한 화면
Ⅲ
.웹
취
약
점
별
대
응
매
뉴
얼
◆유닉스 웹 서버의 경우,
우선 현재 띄어져 있는 웹 데몬들을 모두 kill시켜야 한다. ‘ps-ef | grep httpd’명 령어를 통해 현재 동작중인 데몬들의 PID를 확인하고 kill 명령어를 통해 모두 kill시킨 다. 그 다음 rc 디렉토리에서 실행 스크립트를 실행시킨다.
다음은 한 예이다.
유닉스 시스템은 벤더별로, 버전별로 다소 차이가 있을 수 있으므로 실행 스크립트 의 위치가 조금씩 다르다. rc 디렉토리들을 직접 찾아 보거나 시스템 관리자에게 문의하 면서 데몬을 띄워주면 된다.
(1) 윈도우 웹 서버
①〔제어판〕⇒〔관리도구〕의〔인터넷 서비스 관리자〕(혹은〔인터넷 정보 서비스〕) 메 뉴에서〔기본 웹사이트〕의 마우스 오른쪽 클릭, ‘속성’부분 ⇒‘기본 웹사이트 등 록 정보’가 나온다.
②‘기본 웹사이트 등록 정보’에서‘홈 디렉토리’부분을 클릭한다.
/etc/rc3.d/S50apache stant
요
요 약 약
홈
페
이
지
보
안
가
이
드
③‘디렉토리 검색(B)’옵션이 체크되어 있으면 [그림 17]와 같이 이 부분의 체크를 해지한다.
④‘적용’버튼을 클릭한다.
⑤ 취약점을 제거한 후, 웹 브라우저를 통해 디렉토리 리스팅을 시도 및 취약점이 제 거된 후의 결과(디렉토리를 입력하였을 때 웹 브라우저에 에러가 뜨는 모습)를 확 인한다.
(2) 리눅스 및 유닉스 웹 서버
① httpd.conf 파일을 찾는다(주로 다음 디렉토리 또는 주변에 존재).
[그림 17] 기본 웹 사이트 등록 정보에서 디렉토리 검색 불가 설정 화면
/etc/httpd/conf/httpd.conf /etc/apache/httpd.conf /usr/apache/conf/httpd.conf /usr/local/apache/conf/httpd.conf
Ⅲ
.웹
취
약
점
별
대
응
매
뉴
얼
② httpd.conf 설정 파일에서 Options 항목에서 Indexes 단어를 지워주고 파일을 저장한다.
③ 설정을 적용하기 위해 웹 서버 데몬을 다시 띄워준다.
[그림 18] httpd.conf 파일 내용
[그림 19] httpd.conf 파일에서 Indexes 설정을 삭제한 화면
홈
페
이
지
보
안
가
이
드
4. 시스템 관리 취약점
가. 설명
일반적으로 웹 애플리케이션을 설정하기 위해 위치하는 파일들은 시스템이나 DB에 관련한 많은 정보를 포함하고 있다. 이런 파일들이 공격자에게 노출될 경우 공격자에게 시스템의 많은 정보를 제공하게 된다. 이것은 보안상 매우 위험한 일이다.
일례로 PHP를 사용하는 시스템에는 기본적으로 phpinfo.php 라는 파일이 웹 서버 root 에 설치하거나 또는 개발 시 시스템 환경을 참조하기 위해 직접 작성하여 사용한 다. 이 phpinfo.php는 시스템이 정상적으로 설치 되었는가와 환경변수에 대한 정보를 포함하고 있다.
◆ 테스트 파일이나 sample 파일, 웹 서버 설치 시 기본적으로 설치되는 파일 또는 관리자나 운영자가 임시로 만들어 놓은 파일들이 아무런 접근 권한 없이
◆ 웹 홈 디렉토리에 놓여 있을 경우 일반 사용자가 이 파일명을 직접 입력 하여 디렉토리 정보, 시스템정보 및 중요한 파일 정보를 획득할 수 있다.
취
취 약약 점점 요요 약약
Ⅲ
.웹
취
약
점
별
대
응
매
뉴
얼
대부분의 웹 서버나 웹 애플리케이션의 경우 이를 관리하기 위한 설정파일이 존재한 다. 특히 웹 애플리케이션의 경우 웹에서 관리를 하는 경우 이에대한 설정파일이 외부 에 공개되기 쉽다. 이러한 설정파일의 경우 최소한 외부에 공개될 수 있는 것은 줄이는 것이 좋다. 파일의 권한 설정을 통해 이를 막을 수 있다.
부적절한 환경 설정이란 웹 애플리케이션을 운영하는데 있어서 개발자와 시스템 관 리자들이 자주 실수로 놓치게 되어 발생하는 문제들을 말한다.
나. 진단방법
먼저 웹 서버의 종류를 파악하고 이 웹 서버에서 기본적으로 설치되어 있는 파일명 을 입력하여 중요한 시스템 정보, 디렉토리 정보 등이 있는지 조사한다. 웹 취약점 점검 도구를 이용하여 기본적으로 설치되어 있는 테스트 파일이 존재하는지 조사한다.
[그림 20] phpinfo 정보
홈
페
이
지
보
안
가
이
드
다. 대응방안
(1) Apache의 경우
1) 불필요한 파일 관리
홈페이지 서버에 테스트 파일과 같은 불필요한 파일을 삭제하고 홈페이지 서비스 와 관련 없는 디렉토리(백업디렉토리 등)는 일반사용자가 접근이 불가능하도록 적절 한 권한(디렉토리 또는 파일 접근권한)을 설정한다.
2) 심볼릭 링크 사용 설정 제거
유닉스 계열의 시스템인 경우 심볼릭 링크 기능(ln -s / system.html)을 사용하 여 다른 위치의 파일이나 디렉토리와 연결하여 사용할 수 있는데 이런 경우 웹에서 허용하는 디렉토리 외에 다른 디렉토리를 참조하는 링크가 존재하는 경우 해당 링크 를 엑세스할 수 있는 위험성이 존재한다. 이 위험성을 제거하기 위해서는 디렉토리 리스트와 마찬가지로 httpd.conf 파일에서 DocumentRoot 항목을 아래와 같이 수 정한다.
3) 헤더 정보 숨기거나 최소화
<Files ~"\.bak$">
Order allow,deny Deny from all
</Files>
...
<Directory "/usr/local/www">
Options FollowSymLinks ← 제거한다
</Directory>
...
Ⅲ
.웹
취
약
점
별
대
응
매
뉴
얼
이 정보는 공격자에 의해 Apache 웹 서버 버전별 또는 구동되고 있는 응용프로그 램에 잘 알려진 취약점을 공격하는데 유용하게 이용되기 때문에 공격자에게 웹 서버 의 버전과 같은 banner 정보를 숨기는 것이 안전하다.
Apache 웹 서버에서는 httpd.conf 내용에 ServerTokens 지시자를 삽입하여 헤 더에 의해 전송되는 정보를 최소화 할 수 있다.
ServerTokens Minimal|ProductOnly|OS|Full
※ 위 내용은 httpd.conf에서 기본적으로 설정되어 있지 않으며 내부적인 기본 설정은 Full 이다.
[root@ conf]# telnet xxx.xxx.xxx.xxx 80 Trying xxx.xxx.xxx.xxx...
Connected to xxx.xxx.xxx.xxx.
Escape character is ']' GET / HTTP/1.1
HTTP/1.1 400 Bad Request
Date : Tue, 15 Oct 2002 11:25 : 10 GMT
Server : Apache/1.3.19 (Unix) PHP/4.0.4pl1 ← 서버 버전 정보
[표 1] 설정별 제공되는 헤더 정보
키워드 제공하는 정보 예
Prod[uctOnly] 웹 서버 종류 Server : Apache
Min[imal] Prod 키워드 제공 정보 +
Server : Apache/1.3.0 웹 서버 버전
OS Min 키워드 제공 정보 +
Server : Apache/1.3.0 (Unix) 운영체제
Full OS 키워드 제공 정보 + Server : Apache/1.3.0 (Unix) 설치된 모듈(응용프로그램) 정보 PHP/3.0 MyMod/1.2
홈
페
이
지
보
안
가
이
드
4) 특정 파일의 내용 보기 방지
임의의 사용자가 웹 브라우저에서 특정 파일을 입력함으로서 파일 내용을 볼 수 있 는데 이를 방지하기 위하여 환경 설정화일(httpd.conf)에서 아래와 같이 설정한다.
◆아파치 웹 서버의 경우
위에서 AddType application/x-httpd-php는 뒷부분의 확장자 타입(.php .php3 .inc .html .phtml)에 대하여 실행을 시키는 실행파일을 알려 주는 것이다.
따라서 이 부분에 .inc, .bak와 같이 확장자를 입력 시 application/x-httpd-php 을 통하여 동작시키므로 파일 내용을 보여주지 않게 되는 것이다.
◆CGI의 경우
httpd.conf에서 다음과 같이 설정한다.
◆PHP의 경우
PHP를 사용하여 개발하는데 있어 Error나 Warning 메시지를 자주 접하게 되는 데 이 메시지는 오류메시지가 발생된 CGI의 물리적인(또는 시스템상의) 위치와 에러 부분을 표시하여 준다. 이를 이용하여 공격자는 /lib, /inc, /admin등 보여 지지 말아야할 정보가 노출되는 위험성을 가지고 있다. 이를 제거하기 위해서는 php.ini내의 설정 중에서 display_errors 값을 Off로 설정 하여 준다.
AddType application/x-httpd-php .php .php3 .inc .html .phtml .bak AddType application/x-httpd-php-source .phps
<Directory "CGI를 허용하고자 하는 디렉토리">
...
Options ExecCGI ...
</Directory>
AddHandler cgi-script .cgi .pl
Ⅲ
.웹
취
약
점
별
대
응
매
뉴
얼
않는 방법을 제공한다.
5) 주요 파일시스템 설정 변경
최근 많이 발생한 웹 해킹의 경우, 악성 프로그램을 /tmp, /dev/shm등의 디렉토 리에 악성 프로그램을 업로드 하는 경우가 많으므로 /etc/fstab의 내용을 수정하여 해당 디렉토리의 실행권한을 제거하도록 한다.
변경 후에는 mount 명령을 실행하여 변경 내용을 적용한다.
$abc = @mysql_connect($connect, $id, $pw);
@$abc = mysql_connect($connect, $id, $pw);
[그림 21] Error Message 숨기기
/dev/hda5 on / type ext3 (rw) none on /proc type proc (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620) /dev/hda1 on /boot type ext3 (rw)
n
noonnee oonn //ddeevv//sshhmm ttyyppee ttmmppffss ((rrww,,nnooeexxeecc))
//ddeevv//hhddaa99 oonn //ttmmpp ttyyppee eexxtt33 ((rrww,,nnooeexxeecc,,nnoossuuiidd,,nnooddeevv)) /dev/hda6 on /var/lib type ext3 (rw,nosuid)
/dev/hda7 on /var/log type ext3 (rw,noexec,nosuid,nodev) /dev/hda8 on /var/spool type ext3 (rw,noexec,nosuid,nodev)
mount -o remount /dev/shm mount -o remount /dev/tmp
홈
페
이
지
보
안
가
이
드
또한, apache 웹 서버의 설정파일이 위치하는 디렉토리의 권한을 700으로 변경하 여 하도록 한다 (예:chmod 700 /usr/local/apache/conf)
(1) Apache 보안강화 설정
1) 불필요한 파일 관리
홈페이지 서버에 테스트 파일과 같은 불필요한 파일을 삭제하고 홈페이지 서비스 와 관련 없는 디렉토리(백업디렉토리 등)는 일반사용자가 접근이 불가능하도록 적절 한 권한(디렉토리 또는 파일 접근권한)을 설정한다.
2) 심볼릭 링크 사용 설정 제거
유닉스 계열의 시스템인 경우 심볼릭 링크 기능(ln -s / system.html)을 사용하 여 다른 위치의 파일이나 디렉토리와 연결하여 사용할 수 있는데 이런 경우 웹에서 허용하는 디렉토리 외에 다른 디렉토리를 참조하는 링크가 존재하는 경우 해당 링크 를 엑세스할 수 있는 위험성이 존재한다. 이 위험성을 제거하기 위해서는 디렉토리 리스트와 마찬가지로 httpd.conf 파일에서 DocumentRoot 항목을 아래와 같이 수 정한다.
요
요 약 약
...
<Directory "/usr/local/www">
Ⅲ
.웹
취
약
점
별
대
응
매
뉴
얼
3) 헤더 정보 숨기거나 최소화
Apache 웹 서버에서는 httpd.conf 내용에 ServerTokens 지시자를 삽입하여 헤 더에 의해 전송되는 정보를 최소화 할 수 있다.
4) 주요 파일 시스템 설정 변경
최근 많이 발생한 웹 해킹의 경우, 악성 프로그램을 /tmp, /dev/shm등의 디렉토 리에 악성 프로그램을 업로드 하는 경우가 많으므로 /etc/fstab의 내용을 수정하여 해당 디렉토리의 실행권한을 제거하도록 한다.
홈
페
이
지
보
안
가
이
드
5. WebDAV 취약점
가. 설명
웹데브(WebDAV)는“Web Distributed Authoring and Versioning”의 약자로 원 격지에서 웹 서버의 컨텐츠를 추가하고 관리할 수 있도록 만든 확장 기능이다.
마이크로소프트 사에서 제공하는 윈도우 시스템의 웹 서버 프로그램인 IIS 설치 시
◆ 윈도우 서버 컴퓨터에서 기본으로 설치되는 원격관리기능인 WebDAV가 계속 사용가능하도록 설정되어 있고, WebDAV 라이브러리 파일의 속성 및 홈페이지 디렉토리에 쓰기 권한이 모두 허용되어 있는 경우에
◆ 해커가 WebDAV 도구를 사용, 원격에서 홈페이지 디렉토리에 임의의 파일을 삽입하여 화면을 변조할 수 있다.
취
취 약약 점점 요요 약약
[그림 22] WebDAV를 이용하여 원격에서 웹 페이지를 변경(예제)
Ⅲ
.웹
취
약
점
별
대
응
매
뉴
얼
웹 페이지를 변경하는 모습이다.
나. 진단방법
(1) WebDAV 관련 라이브러리 파일의 보안 권한 확인
◆윈도우에는 웹데브 서비스를 지원하는 httpext.dll이란 동적 라이브러리 파일이 존재한다. 이 파일은 /winnt/system32/inetsrv/httpext.dll에 존재하거나 혹은 /windows/system32/inetserv/httpext.dll에 존재 한다. 이 파일에 대한 보안 속성을 확인한다.
◆우선 웹 서버의 해당 디렉토리로 이동한다. [그림 23]과 같이 파일을 선택한 후에 마우스 오른쪽 클릭을 하여‘속성’메뉴를 클릭한다.
◆[그림 24]과 같이‘httpext.dll 등록 정보’창이 뜨는데, 이때‘보안’이라는 항목에
‘그룹 또는 사용자 이름’부분에‘Everyone’이란 그룹이 존재하면 문제가 된다.
[그림 23] httpext.dll 위치 및 속성 확인
홈
페
이
지
보
안
가
이
드
※ 참고 : Everyone이 존재하지 않을 수도 있고 아예 httpext.dll 파일이 존재 하지 않을 수도 있으며, 이 경우 취약하지는 않으나 조치방법에서 소개하는 추가 조치가 요구된다.
(2) 웹 서버 설정 확인
일부 웹 서버는 홈 디렉토리 메뉴에서‘쓰기’권한을 부여함으로써 인터넷을 통해 누구나 쓸 수 있도록 구성하는 실수를 범하고 있다. 다음과 같은 과정을 통해 설정을 확 인할 수 있다.
◆[제어판] [관리도구]의 [인터넷 서비스 관리자](혹은 [인터넷 정보 서비스]) 메 뉴에서[기본 웹 사이트]의 마우스 오른쪽 클릭한다. ‘속성’부분을 보면([그림 25]
[그림 24] “httpext.dll 등록 정보”창
Ⅲ
.웹
취
약
점
별
대
응
매
뉴
얼
◆‘기본 웹 사이트 등록 정보’에서‘홈 디렉토리’부분을 클릭한다. 여기서‘로컬 경 로’항목의‘쓰기’부분을 확인한다. [그림 26]과 같이‘쓰기’항목이 체크되어 있다 면 문제가 된다.
[그림 25] 인터넷 정보 서비스 창
[그림 26] 기본 웹 사이트 등록 정보 창
홈
페
이
지
보
안
가
이
드
정리하면, ‘WebDAV 취약점’앞서 살펴 본 httpext.dll 파일의 접근 권한 설정의 문 제점과 웹 관리자의 인터넷 사용자 쓰기 권한 할당으로 인해 발생되는 것이다.
다. 대응방안
(1) 웹데브(WebDAV) 중지
만약 귀 기관에서 원격 웹 서버 관리를 하지 않는다면 반드시 웹데브 기능을 중지시 켜야 한다. 웹데브는 앞서 설명한 취약점 외에도 버퍼오버플로 취약점 등이 존재하여 단지 웹데브 기능이‘사용가능’상태로 되어 있는 것만으로도 문제가 될 수 있다.
◆웹데브를 중지시키기 위해서는‘레지스트리’를 편집해야 한다. 윈도우 화면의 왼 쪽 하단에 있는‘시작’메뉴의‘실행’부분을 클릭한다. 그러면 [그림 27]과 같이
‘실행’창이 뜨는데 이곳에‘regedit’라고 입력한 후‘확인’버튼을 누른다.
◆‘regedit’를 실행하면 [그림 28]와 같이‘레지스트리 편집기’창이 뜬다. 이곳에 서‘ H K E Y _ L O CA L _ M AC H I N E \ S Y S T E M \ C u r r e nt C o nt r ol S et\Services\W3SVC\Parameters’디렉토리로 이동한다. [그림 44]는 Parameters 디렉토리로 이동해 들어간 모습이다. 이 디렉토리에 웹데브를 중지 시키는 파일(값)을 하나 생성해야 한다.
◆디렉토리 안에서 마우스 오른쪽 버튼을 클릭한 후, ‘새로 만들기’의‘DWORD
[그림 27] WebDAV를 중지시키기 위한 1단계
Ⅲ
.웹
취
약
점
별
대
응
매
뉴
얼
◆[그림 29]은 이런 식으로 생성된‘DisableWebDAV’파일 (값)의 모습 이다.
[그림 28] DWORD 타입의 값을 생성
[그림 29] DisableWebDAV 파일
홈
페
이
지
보
안
가
이
드
◆다음으로 [그림 30]와 같이‘DisableWebDAV’파일을 선택하고 마우스 오른쪽 버튼 클릭, ‘수정’메뉴를 클릭한다.
◆‘수정’메뉴를 열면[그림 31]와 같이’DWORD 값 편집’이란 창이 뜬다.
‘값 데이터(V)’항목에‘1’을 입력한 후‘확인’버튼을 클릭한다.
◆레지스트리 편집을 통한‘웹데브 중지’를 즉시 적용하기 위해서는 윈도우 시스템 을 리부팅해야 한다.
[그림 30] DisableWebDAV 파일의 DWORD 값 편집
[그림 31] DisableWebDAV의 값을 1로 수정
Ⅲ
.웹
취
약
점
별
대
응
매
뉴
얼
(2) httpext.dll 파일의 Everyone 권한 삭제
◆Httpext.dll 파일은 \winnt\system32\inetsrv\httpext.dll에 존재하거나
\windows\system32\inetserv\httpext.dll에 존재한다. 우선 웹 서버의 해당 디렉토리로 이동한다. [그림 32]과 같이 파일을 선택한 후에 마우스 오른쪽 클릭,
‘속성’메뉴를 클릭한다.
[그림 33] httpext.dll 등록 정보 [그림 32] httpext.dll 위치 및 속성
홈
페
이
지
보
안
가
이
드
◆[그림 33]과 같이‘httpext.dll 등록 정보’창의‘보안’메뉴로 들어 간다. 여기서
‘그룹 또는 사용자 이름’항목의 Everyone을 선택한다. 그리고‘제거’버튼을 눌 러 Everyone을 제거한다.
(3) 홈 디렉토리 메뉴의‘쓰기’권한 삭제
웹 서버 설정의 홈 디렉토리 메뉴에서‘쓰기’권한이 있을 경우 이를 삭제 해야 한다.
◆[제어판] [관리도구]의 [인터넷 서비스 관리자](혹은 [인터넷 정보 서비스]) 메 뉴에서 [기본 웹 사이트]의 마우스 오른쪽 클릭, ‘속성’부분을 보면([그림 34]참 조) ‘기본 웹 사이트 등록 정보’가 나온다.
[그림 34] 인터넷 정보 서비스 창
Ⅲ
.웹
취
약
점
별
대
응
매
뉴
얼
◆‘기본 웹사이트 등록 정보’에서‘홈 디렉토리’부분을 클릭한다. 여기서‘로컬 경 로’항목의‘쓰기’부분을 해제하고‘확인’및‘적용’버튼을 누른다.
(1) 웹데브(WebDAV) 중지(원격 웹 서버 관리를 하지 않을 경우)
① 윈도우 화면의 왼쪽 하단에 있는‘시작’메뉴의‘실행’부분을 클릭, [그림 36]과 같이‘실행’창에‘regedit’라고 입력한 후‘확인’버튼을 누른다.
[그림 35] 기본 웹 사이트 등록 정보 창
[그림 36] WebDAV를 중지시키기 위한 1단계
요
요 약 약
홈
페
이
지
보
안
가
이
드
②‘ regedit’를 실 행 하 면 ‘ 레 지 스 트 리 편 집 기 ’ 창 이 뜬 다 . 이 곳 에 서
‘HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SV C\Parameters’디렉토리로 이동한다.
③ 디렉토리 안에서 마우스 오른쪽 버튼을 클릭한 후, ‘새로 만들기’의 ‘DWORD 값’을 클릭한다( [그림 37]참조). ‘DWORD’타입의‘값’이 하나 생기는데, 이 생 성된 값을 선택한 후 오른쪽 마우스 버튼을 클릭, ‘이름 바꾸기’를 클릭하여 값의 이름을 DisableWebDAV로 변환한다 (대소문자 구분 주의). [그림 38]와 같이 DisableWebDAV 파일을 선택하고 마우스 오른쪽 버튼 클릭, ‘수정’메뉴를 클릭 한다.
[그림 37] DWORD 타입의 값을 생성
[그림 38] DisableWebDAV 파일의 DWORD 값 편집
Ⅲ
.웹
취
약
점
별
대
응
매
뉴
얼
④ [그림 39]과 같이’DWORD 값 편집’이란 창에서‘값 데이터(V)’항목에‘1’적은 후‘확인’버튼을 클릭한다.
⑤‘웹데브 중지’를 즉시 적용하기 위해 윈도우 시스템을 리부팅한다.
WebDAV를 반드시 사용해야 하는 경우라면, 다음 소개되는 2개의 조치 사항을 모두 수행해야 한다.
(2) httpext.dll 파일의 Everyone 권한 삭제
① Httpext.dll 파일은 \winnt\system32\inetsrv\httpext.dll에 존재 하거나
\windows\system32\inetserv\httpext.dll에 존재한다. 우선 웹 서버의 해당 디렉토리로 이동한다. [그림 40]와 같이 파일을 선택한 후에 마우스 오른쪽 클릭 을 하여‘속성’메뉴를 클릭한다.
[그림 39] DisableWebDAV의 값을 1로 수정
[그림 40] httpext.dll 위치 및 속성 확인
홈
페
이
지
보
안
가
이
드
② [그림 41]와 같이‘httpext.dll 등록 정보’창의‘보안’들어간 다. ‘그룹 또는 사용자 이름’항목의 Everyone을 선택, 그리고‘제거’버튼을 눌러 Everyone을 제거한다.
(3) 홈 디렉토리 메뉴의‘쓰기’권한 삭제
① [제어판] [관리도구]의 [인터넷 서비스 관리자](혹은 [인터넷 정보 서비스]) 메 뉴에서[기본 웹사이트]의 마우스 오른쪽 클릭, ‘속성’부분을 보면( [그림 42]참 조) ‘기본 웹사이트 등록 정보’가 나온다.
[그림 41] httpext.dll 등록 정보 창
[그림 42] 인터넷 정보 서비스 창
Ⅲ
.웹
취
약
점
별
대
응
매
뉴
얼
②‘기본 웹사이트 등록 정보’에서 홈 디렉토리’부분을 클릭, ‘로컬 경로’항목의
‘쓰기’부분을 해제해 주시고‘확인’및‘적용’버튼을 클릭한다 ([그림 43] 참조).
[그림 43] 기본 웹 사이트 등록 정보 창
홈
페
이
지
보
안
가
이
드
6. 불필요한 Method 취약점
가. 설명
불필요한 메소드가 허용되어 있을 때 악의적인 사용자가 이를 이용해 웹 서버 변조 및 시스템권한을 획득 하는 공격 취약점으로,
사용자로부터 중요 정보를 받을 때는 POST Method를 사용해야 하며, 그 중요도에 따라 SSL을 사용한 암호화 통신을 적용해야 한다. SSL은 자료 전송 시 암호화를 지원 하므로, 민감한 정보는 애플리케이션 레벨의 암호화를 고려해야 한다.
◆ 불필요한 메소드가 허용되어 있을 때 악의적인 사용자가 이를 이용해 웹 서버 변조 및 시스템권한을 획득 하는 공격 취약점이다.
취
취 약약 점점 요요 약약
아래와 같이 명령어를 입력하여 웹 서버에 허용되어 있는 HTTP 메소드 (Method)를 확인 하였다.
위와 같이 PUT, DELETE등의 메소드가 허용된 것을 확인 하고, 아래 그림
Ⅲ
.웹
취
약
점
별
대
응
매
뉴
얼
나. 진단방법
HTML 소스에서 FORM 필드 확인 후, 해당 값이 어떻게 사용되는지를 소스에서 확 인해야 한다.
중요 정보 전달 FORM ACTION에 사용된 프로토콜이 "HTTPS"로 되어 있는지 확인한다.
다. 대응방안
(1) 서버 조치 방법
◆HTTP 메소드중 필요한 메소드(OPTIONS, TRACE, GET, POST, HEAD)외에 는 제거를 해야된다.
1) 불 필요한 메소드 제거(IIS)
아래 그림과 같이 웹 홈 디렉토리의 쓰기 권한을 제거 하고, PUT, DELETE 등의 불필요한 메소드를 제거 하기 위해서는 원격지에서 웹 서버의 컨텐츠를 추가 하고
그 결과 아래 그림과 같이 put.asp 파일이 업로드 된 것을 확인 할 수 있으 며, 만일 이 put.asp 파일이 아닌 WebShell을 업로드 하면, 웹 서버의 임의의 명령어를 실행 가능하다.
