1. 개요
전통적인 인터넷 침해사고에서는 특정 공개 소프트웨어에 대한 취약점이 공개되면서부터 공격이 시작되었다. 일단 공격자가 취약점 정보를 입수하게 되면, 이 취약점을 가지고 있는 버전의 서버를 찾아 수동으로 하나씩 값을 대입해보면서 공격 가능성을 확인하는 패턴을 보여 왔었다. 이러한 전통적인 공격은 사이트 초기페이지를 공격자가 임의적으로 조작하여 자신의 실력을 과시하거나 정치적인 의미를 전달하고자 주로 이용되어 왔었다. 하지만 최근 공격자들은 공개된 취약점에 대한 공격뿐 아니라 스스로 연구하여 개발자도 미처 생각하지 못한 오류를 찾아내어 공격하고, 발견된 공격에 대해서는 일련의 공격패턴을 성립하여 자동화 툴을 이용하는 등 좀 더 세밀한 공격이 이뤄지고 있다.
이렇게 발전하는 공격의 대상이 되지 않기 위해서는 개발하는 모든 코드들이 정확한 요청과 목적에 의해서만 동작되도록 작성해야 되나, 모든 경우의 수를 고민하고 작성하기에는 결코 쉬운 일이 아니다.
아무리 많은 비용과 노력을 들이더라도 사소한 실수로 인해 치명적인 사고로 이어질 수 있기 때문에 주기적으로 웹로그를 확인하는 등의 꾸준한 관리자의 관심이 절대적으로 필요하다.
본 보고서에서는 최근 대량 웹 변조를 일으킨 취약점으로 미처 프로그래머가 예상하지 못한 요청으로 인하여 공격자가 원하는 스크립트가 동작하도록하는 Remote File Inclusion 공격에 대한 심각성을 살펴보고, 운영되는 홈페이지 내에서 취약점을 찾는 방법과 대처하는 방법에 대하여 설명한다.
2. Remote File Inclusion 보안 취약성 분석
Remote File Inclusion 취약점을 이용한 공격은 공격자가 악의적인 코드를 실제 서버에 전달하여 취약한 페이지를 통하여 악성코드(스크립트)를 실행하는 형식이다. 아래 그림은 최근 사고에서 발견된 전형적인 Remote File Inclusion 취약점이 있는 코드이다. 실제 홈페이지 메인으로 사용되 “index.php3” 파일은 “in_url”의 값을 인자로 넘겨받는다. 인자로 넘어오는 값을 변수화 시키는 특징을 갖는 PHP는 인자로 넘어오는 “in_url”의 값을 “$in_url” 변수 값으로 설정하고, 이에 지정된 값을 그대로 “index.php3”에 포함하여 PHP 스크립를 실행하는 구조를 가지고 있다.
<?php if (!$in_url) {
include “./lib/index_main.html”;}
else {
include “$in_url”;
}
?>
(그림)“ Remote File Inclusion 취약점”에 취약한 코드
이러한 취약한 코드의 문제점은 인자로 넘어오는 “in_url”의 값이 항상 정상적일 경우만을 생각하고 작성된 코드에서 비롯된 것으로“, $in_url”에 의하여 “include”되는 파일에 대한 검증 작업을 하지 않는 것에 있다.
이보다 더 큰 문제점은 이런 취약점을 가진 코드들이 보편적으로 널리 사용하는 공개용게시판에 존재한다는 것이다. 지난 9월 중순에 발생한 대량 웹변조 사고가 그 대표적인 예라고 할 수 있겠다. 이는 T사에서 배포하는 공개용 게시판으로 취약점들을 게시하는 해외 커뮤니티 사이트에서 해당 취약점을 공개하면서 이를 이용하는 국내의 많은 홈페이지들이 변조되는 사고가 발생했었다. 공격자는 취약점을 발견하면 바로 자동화 도구를 만들어 손쉽게 공격대상을 찾을 뿐 아니라, 공격 대상 목록을 별도로 관리하여 언제든지 다양한 공격을 할 수 있다. 이문서를 통하여 반드시 취약점에 대한 위협을 인지하고 반드시 해당코드를 수정하기를 바란다.
3. Remote File Inclusion 취약점을 이용한 공격 사례 분석
가. 취약한 웹서버의 정보수집
공격자는 항상 공격대상을 찾는 일과 공격대상에 실제 공격을 수행하는 취약한 서버와 PC를 찾는다.
검색된 서버와 PC들은 별도의 데이터베이스로 구축되어 실제 공격대상이 발생하였을 때 언제든지 공격이 가능하도록 취약한 서버들을 주기적으로 관리ㆍ점검한다. 서버들의 상태들을 점검하는 방법으로 Remote File Inclusion 취약점을 이용하면 쉽게 확인이 가능하다. 최근에 사고 분석한 웹서버에서도 Remote File Inclusion 취약점을 이용하여 취약한 서버에 대한 정보를 얻어가는 것을 확인할 수 있다.
(그림)“ Remote File Inclusion 취약점”을 이용해 서버 정보를 획득했던 로그
위 그림의 웹로그를 살펴보면 로그의 User-Agent의 값이 “libwww-perl/5.811”인 것으로 보아 일반적인 사용자가 접근하는 웹브라우져가 아닌“perl 스크립트”를 이용한 취약점 전용 공격툴에 의한 접근 이었음을 추정할 수 있다.
※웹로그에서 Remote File Inclusion 취약점을 접근한 흔적 찾기
1. 웹서버의 로그 위치 확인
o Windows - IIS
컴퓨터 관리(compmgmt.msc)→해당 웹사이트 등록정보→웹사이트 - 로깅사용- 등록정보
→ 일반속성 - 로그파일 디렉터리
파일위치는 “%WinDir%\System32\LogFiles\W3SVC4\”안에 날짜별로 기록이 되어 있다.
o Linux - 아파치
httpd.conf 파일
510 # 511 # For a single logfile with access, agent, and referer information
512 # (Combined Logfile Format), use the following directive:
513 #
514 CustomLoglogs/access_logcombined
파일위치는/var/log/httpd/access_log 또는 아파치가 설치된 디렉토리의 logs 폴더에 웹로그 파일 존재
2. 문자열을 이용한 Remote File Inclusion 공격 흔적 찾기
해당 디렉토리에서 다음과 같은 명령어를 통하여 요청되는 페이지의 인자값이“=http://”또는
“=http%3A%2F%2F”로 설정되어 있는 것을 찾아, 이에 해당하는 페이지들이 실제로 취약점이 존재하는지를 점검하기 바란다.
findstr “=http://” *.log |
find . -name “=http://” access_log* |
< Windows > |
< Linux > |
사고분석 로그에서 확인할 수 있듯이 취약한 서버의 정보를 알기 위해 특정 서버에 정보를 획득할 수 있는 스크립트 파일을 업로드하고, 이 파일의 URL을 인자값으로 설정하여 페이지를 요청한다. 지정하는 파일들은 “.html”“, .txt”등 다양한 형태로 존재하며 “, .jpg” “, .gif” 같은 확장자만 이미지 파일형태를 갖는 경우도 살펴볼 수 있었다. 인자값으로 설정된 URL들의 내용을 살펴본 결과, 주로 다음과 같은항목들을 확인하는 스크립트로 구성되었다.
- 서버의 OS 및 업데이트 정보
- 서버 도메인 및 IP 정보
- 서버의 하드웨어 정보
- 웹어플리케이션의 종류
- 웹서버 경로
- 웹 스크립트 버전 및 모듈 정보
웹서버 관리자는 웹로그를 주기적으로 확인함으로써 위와 같은 정보들을 공격자에게 노출하지 않아야 한다.
나. IRC 좀비 클라이언트
공격자는 일단“Remote File Inclusion 취약점”을 확인하면 웹쉘들을 이용하여 웹서버의 모든 파일들을 수정∙삭제 할 수 있으며 악성코드를 업로드해서 실행할 수 있다. 하지만 웹쉘을 이용하여 추가적인 공격을 진행하는 것은 기존에 많이 설명이 되었으므로, 본장에서는 IRC(Internet Relay Chat) 좀비클라이언트 프로그램이 구동되는 현상을 살펴보기로 한다.
(그림) 웹쉘 구동 화면
웹 스크립트 또한 네트워크 프로그램이 가능하므로 얼마든지 서버-클라이언트 형태의 IRC 프로그램이 가능하다. 실행되는 IRC 좀비 클라이언트 프로그램은 특정 IRC서버를 접근하여 공격자의 명령을 대기하다가 공격자에 의해 임의의 공격명령을 전달받으면 이에 맞는 공격이 수행되는 형태를 지니고 있다. 사고분석 당시“Remote File Inclusion 취약점”을 이용해 실행되는 코드는 다음 그림과 같다. 수행되는 행위를 살펴보면“, /tmp”에 특정 URL로부터 IRC 클라이언트 프로그램을 다운받아 실행시킨 동시에 해당 파일을 삭제 한다.
(그림) IRC 클라이언트 실행 스크립트
이렇게 되면 “/tmp” 밑에 생성되는 “l”파일은 생성과 동시에 실행되어 메모리에 적제되고 바로 삭제가 되므로 서버 관리자는 직접 실행되고 있는 악성 코드를 확인할 수는 없지만, 아래 그림처럼 어딘가로 네트워크 통신을 시도하는 흔적을 발견할 수가 있다.
(그림) IRC 클라이언트가 구동된 이후 네트워크 상태 정보
위 그림에서 살펴보듯이 현재는 IRC 서버가 구동되지 않아 접속을 시도하는 상태인“SYN_SENT”에서 머물러 있지만, 만약에 서버가 구동이 된다면 특정 Channel에 접속하여 공격자의 제어 및 조정을 받아 임의의 동작을 실행할 수 있도록 작성되어 있었다.
4. 대 책
가. PHP 환경 설정
본 문서에서 설명한“Remote File Inclusion 취약점”은 PHP 환경설정만으로도 취약점을 해결할 수 있다.
PHP 환경 설정은 기본적으로“php.ini”파일에서 한다.
Version 4.x 이하
allow_url_fopen = Off
PHP Version 4.x이하에서는 위와 같이 “allow_url_fopen”이 기본적으로“On”으로 설정되어 있어 “Remote File Inclusion 취약점” 공격이 가능하다. 이 값을 “Off”로 설정하면 취약점을 차단 할 수 있다.
Version 5.x 이상
PHP Version 5.x이상에서는 fopen API등을 이용한 원격 파일 열기와 include, require을 이용하여 원격 파일 여는 것을 나누어 설정하게 되어있다. 이는 아래와 같이 기본적으로 설정되어 있으며, 이러한 기본 설정으로 관리자가 특별한 설정없이도 “Remote File Inclusion취약점”을 막을 수 있다.
allow_url_fopen = On
allow_url_include = Off
나. 아파치 환경설정 (httpd.conf)
아파치의 환경설정파일인 httpd.conf에 아래와 같이 추가함으로서도 취약점을 해결할 수 있다.
php_admin_flag allow_url_fopen off
하지만 지금까지 설명한 서버상의 설정은 기존에 서버에서 운영되고 있은 모든 페이지들이 영향을 받으므로, 인위적으로 외부의 파일을 접근하는 스크립트들은 문제를 유발시킬수 있으므로 쉽게 적용하기에는 쉬운일이 아니다. 이러한 관리자라면 다음에서 설명하는 직접 코드를 수정하여 취약점을 해결하길 바란다.
다. “Remote File Inclusion 취약점” 발견하여 소스 수정
웹서버를 운영하는 개인이나 웹호스팅 업체에서는 서버상에 수많은 페이지들이 연동하여 운영되고 있으므로 취약점이 존재하는지를 하나씩 살펴보는 것에는 한계가 있다. 이를 해결할 수 있는 가장 좋은 방법으로 웹로그를 확인하여 기존에 공격시도가 있었던 페이지를 우선으로 통보하여 점검하고, 나아가 “include”나 “require”라는 키워드를 사용하는 파일을 추출하여 실제 홈페이지 제작자와 조율을 통해서 수정/보완해야 한다. 코드를 수정하여 취약점을 해결하는 방법에는 다양한 방법이 있을 수 있겠지만, 본 장에서는 아래와 같은 방법을 통하여 취약점 해결을 제안해 본다.
<TR> <TD valign=“top”align=“center”> <?php if (!$in_url) { include“ ./lib/index_main.html”; } else { include“ $in_url”; } ?> |
<TR> <TD valign=“top”align=“center”> <?php if(!$in_url) { include“ ./lib/index_main.html”; } else { if(substr($in_url,0,2)!=“ ./”) $in_url = ./”.$in_url; include“ $in_url”; } ?> |
<취약한 소스코드> |
<취약점을 해결한 소스코드> |
이는 임시적인 처리이며, 완벽한 조치가 이뤄지기 위해서는 넘어오는 인자값이 서비스상으로 꼭 필요한 페이지로만 설정되었는지 확인하는 것이다. 추가적으로 코드를 위와같이 설정하게 되었을때는 잘못된 접근일 경우 경고(Warning)가 띄게 되는데, 이 또한 공격자에게 정보를 제공하는 것이므로 특별히 디버깅하는 기간이 아니라면 “php.ini”의 내용 중 “display_errors”의 값을 “Off”로 설정하길 바란다.
display_errors = Off
5. 결 론
지금까지 “Remote File Inclusion 취약점”에 대해서 살펴보고, 이에 대한 해결점에 대해서 살펴보았다. 기존의 악성코드(바이러스, 봇넷)들의 명령 채널들은 IRC와 같이 특정 포트를 이용하여 채널을 형성 하였으므로 이에 대한 탐지가 비교적 쉬웠으나, 최근 들어 웹(HTTP)을 통하여 공격 명령을 하달하거나 감염된 서버/PC들의 정보를 수집하는 사례들이 발견되고 있으나 이에 대한 탐지가 매우 힘든 실정이다. 웹을 이용한 공격 채널 형성이 많아지면서 웹취약점에 대한 관심이 더욱 높아져 관리자들 또한 운영되는 시스템에 대한 보안패치나 업데이트에 항상 관심을 가져야 하겠다. 또한 주기적으로 웹로그를 확인하여 미발표된 공격이나 자신의 서비스에 특화된 취약점에 대해서도 미리 방지할 수 있도록 해야 할 것이다.
'Working > IT Security' 카테고리의 다른 글
정 익스플로러를 쓰셔야 한다면 보안은 이렇게... (0) | 2008.12.18 |
---|---|
ISO27001 Control Objective Checklist (0) | 2008.12.11 |
무선랜 WEP 인증 해킹시연 및 방어대책 (1) | 2008.03.19 |
Security Checklists (0) | 2008.03.02 |
Guideline on Network Security Testing (0) | 2007.03.08 |