[CASE STUDY] 웹 서버를 조종하는 '보이지 않는 손'

웹 서버 해킹을 통한 스팸 메일 발송 사례

 

받은 편지함을 열 때마다 지우기 힘들 정도로 많은 스팸 메일들이 쌓여 있는 걸 볼 수 있다. 이 메일들은 보통 악성코드를 포함하고 있거나 불법 광고인 경우가 많다. 도대체 이런 메일들은 누가, 어떻게 보내는 것일까? 웹쉘(Webshell) 업로드를 통해 웹 서버를 해킹하면 별도의 메일 발송 서비스를 이용하지 않고도 대량의 스팸 메일을 발송할 수 있다. 웹쉘은 웹 서버에서 실행되는 스크립트 중 시스템 명령어를 수행할 수 있는 코드를 말한다. 기본적인 시스템 명령어를 수행하는 것 외에도 웹쉘은 데이터베이스 탈취, 백도어 생성, 파일 업로드와 다운로드 등 다양한 기능을 한다. 공격자는 운영 중인 웹 서비스의 게시판에 접근해 웹쉘을 업로드할 수 있다. 이 웹쉘을 이용해 파일 업로드가 가능한 스팸 메일 발송 기능을 가진 여러 코드들을 업로드했다. 이후 대량의 좀비PC를 이용해 스팸 메일 발송 코드로 접속해 메일을 보낸 것이다. 실제 사례를 통해 웹쉘 업로드 양태를 자세히 살펴보고 그 대응책을 마련해본다.

  

2011년 8월, 웹 서비스를 제공하고 있는 한 업체가 자사의 서버에서 스팸 메일을 대량 발송하는 사건이 일어났다며, 안철수연구소 A-FIRST(AhnLab Forensic & Incident Response Service Team)에 분석을 의뢰했다. 이 업체는 자사의 서버가 스팸 메일을 발송하고 있다는 사실도 스스로 인지한 것이 아니라, 스팸 메일을 수신한 포털 사이트 메일 사용자들이 항의해서 알게 됐다. [그림 1]은 해당 업체가 받은 경고 메일이다.

 

[그림 1] 스팸 메일 발송 경고문

이 사례는 공격자가 웹쉘 업로드를 통해 웹 서버를 해킹한 경우다. 각 단계에서 공격자가 수행한 내용을 자세하게 살펴보자.
 

[그림 2] 공격 구조도

 

1. 공격의 시작

침해당한 대부분의 웹 서버들은 파일 업로드 취약점을 갖고 있다. 이 취약점을 이용해 웹쉘 파일을 업로드하는 것이 공격자가 서버의 제어권을 획득하는 가장 쉬운 방법이다. 이 방법은 다른 취약점들에 비해 보안 장비를 사용해 방어하기 어렵고, 보안성에 적합하지 않은 게시판 코드 구현이 많아 주로 사용된다.

 

[그림 3] 웹쉘 접근 화면

공격자는 웹쉘 파일을 업로드한 후에 해당 웹 서버에서 명령어를 실행시킬 수도 있고, 추가 공격에 사용될 여러 파일들을 올릴 수도 있다. 공격자가 웹쉘 파일 업로드 및 실행에 성공하면, 웹 서비스를 운영 중인 계정의 권한을 획득하게 된다. 이때 사용되는 계정은, 시스템마다 다르지만, 루트(root) 권한이 아니라 대부분 노바디(nobody) 권한이다. 따라서 웹쉘을 사용해 처음으로 업로드하는 파일은 공격자의 권한을 루트로 높여야 하므로 시스템의 취약점을 공격할 수 있는 취약점 공격 코드(exploit)인 경우가 많다.

하지만 이번 스팸 메일 발송 사건에서 공격자는 루트 권한을 획득하지 않고 웹 서비스가 운영 중인 노바디 권한까지만 획득한 후 공격을 감행했다. 스팸 메일 발송 기능이 있는 코드를 업로드한 후 다수의 좀비PC에서 이 코드에 접근해 스팸 메일을 발송하는 방식을 사용한 것이다. 이 경우 별도의 권한 상승이나 악성코드가 없더라도 아파치 데몬만을 사용해 메일 발송이 가능하다. [그림 4]에서 확인할 수 있듯이 프로세스 정보상 특이 사항은 발견되지 않았다.

 

[그림 4] 아파치 서비스 프로세스 정보

프로세스에 악성코드가 포함돼 있는지 여부를 조사하기 위해서 가장 많이 사용되는 명령어는 lsof(List Open File)다. 이 명령어는 현재 실행되고 있는 프로세스에서 사용되는 파일들의 목록은 물론, 프로세스와 연관된 네트워크 커넥션 정보도 보여주기 때문에 침해 사고 대응 시에 많이 사용된다.

[그림 5]는 lsof 명령어 실행 결과의 일부다.

 

 
[그림 5] 아파치 서비스 프로세스에 대한 lsof 실행 결과

lsof 명령어 결과에 의하면, 현재 작업 중인 디렉터리(cwd : Current Working Directory)는 /home/virtual/easy/htdocs/push이며 가장 하단에 외부와 네트워크 커넥션이 생성된 것을 볼 수 있다. 이 디렉터리에는 [그림 6]과 같은 파일이 존재하는데, notice_notice.txt 파일을 제외하고는 아파치 데몬 운영 권한인 노바디로 생성된 파일들이다.

 

[그림 6] 스팸 메일 발송 코드가 위치한 디렉터리

그럼 이러한 파일들이 어떻게 생성됐는지 살펴보자.

 

 

2. 파일 업로드 취약점 이용

방화벽, 침입탐지시스템, 웹 방화벽 등을 사용하더라도 파일 업로드 취약점에 대한 공격을 방어하는 데에는 어려움이 있다. 특히 사용자들의 의견을 접수하고 상호 소통하기 위해서 만든 통로인 게시판은 공격자들에게 중요한 공격 포인트가 된다.

 

[그림 7] 주요 공격 대상 – 게시판

공격자는 [그림 7]처럼 쓰기 버튼이 있거나 첨부 파일을 업로드할 수 있는 페이지를 공략한다. 쓰기 버튼을 누르면 로그인 화면이 나오고, 공격자는 정상적인 사용자 계정을 통해 로그인한다. 사용자 계정은 SQL 인젝션 공격을 통해 획득할 수 있으며, 대량으로 유출된 개인 정보를 이용해서 가입하는 경우도 있다. 공격자는 계정 로그인을 한 후 글을 등록할 수 있는 페이지로 이동하고, 정상적으로 웹쉘 파일 업로드를 완료한다.

어떻게 웹쉘 파일을 업로드하고 실행할 수 있었을까? 이 서버에는 두 가지 취약점이 있었기 때문이다.

 

첫째, 파일 업로드가 금지된 확장자 정의에 php가 누락돼 있었다. 이는 관리자가 작업을 편리하게 하고자 고의로 삭제한 것일 수도 있고, 공격자가 최초 침해에 성공했을 때 나중에 다시 접근할 수 있도록 확장자 제어를 풀어놓은 것일 수도 있다.

 

둘째, 파일이 업로드되는 디렉터리에 실행 권한이 있었다. 파일이 업로드되는 위치에 실행 권한이 있으면 웹쉘이나 스팸 메일 발송 코드 같은 악의적인 행위를 하는 php, php3 파일을 업로드해 공격자가 원하는 작업을 수행할 수 있다.

 

각각의 내용에 대해서 살펴보자.

첫째, 애초 게시판 소스에는 config.qna.php라는 파일이 $prohibited_ext라는 변수로 업로드하지 못하도록 제어하고 있었다. 하지만 [그림 8]에서 확인할 수 있듯이 php 파일을 금지하는 내용이 빠져 있다. 이는 공격자가 다른 루트를 통해 접근한 다음에 php 정의 부분을 제거했을 수도 있고, 관리자가 다른 목적으로 허용했을 수도 있다.

 

[그림 8] 업로드 가능 파일의 확장자 제어

공격자는 이 취약점을 이용했다. 게시판을 통해 php로 작성된 웹쉘 파일을 업로드하고 이후 업로드에 사용할 Iist.php를 업로드했다. Iist.php 파일명은 얼핏 list.php처럼 보여 사고 대응 분석가로 하여금 정상 파일의 이름과 헷갈리도록 했다. Iist.php 파일의 내용은 한글로 작성돼 있어 정상 파일처럼 보이지만, 자세히 살펴보면 확장자 제한 없이 파일 업로드가 가능한 소스가 포함돼 있다. 공격자는 이 코드를 사용해 푸쉬(push) 디렉터리에 스팸 메일 발송 기능이 있는 파일을 업로드했으며 좀비PC를 통해 1만여 통 이상의 스팸 메일을 발송할 수 있었다.

 

[그림 9] 공격자가 업로드한 코드(파일 업로드 기능)

공격자가 웹쉘 파일들을 실행할 수 있었던 둘째 이유는 업로드 디렉터리 실행 권한이 있었기 때문이다([그림 10]). 공격자는 업로드 디렉터리(권한 : rwx---rwx)에 웹쉘 파일을 업로드한 후 웹쉘을 이용해 푸시 디렉터리의 권한을 777(rwxrwxrwx)로 설정했다. 이와 같이 설정돼 있는 경우 노바디 계정으로도 푸시 디렉터리와 업로드 디렉터리에 파일을 업로드하고 실행하는 것이 가능하다.

 

[그림 10] 업로드 디렉터리의 실행 권한

따라서 반드시 필요하지 않은 한, 업로드 디렉터리의 실행 권한은 제거하는 것이 좋으며, 실행 권한이 있을 경우에는 확장자 검사 수행 및 업로드되는 파일에 대해 모니터링하는 것이 필요하다.

 

 

3. 스팸 메일 발송 방법

앞서 살펴본 것처럼, 파일 업로드 취약점을 이용해 공격자는 스팸 메일 발송 기능이 있는 코드를 다수 업로드했다. [그림 6]의 each.php, corp.php, skan.php 파일은 모두 스팸 메일 발송 기능이 있다.

해당 파일의 내용에 대해서 간략하게 알아보자.
[그림 11]에서 $_POST[“helo”], $_POST[“mailFrom”], $_POST[“mailFrom”], $_POST[“dongbo”], $_POST[“mailTo”] 등은 공격자가 POST의 파라미터로 내용을 지정할 수 있는 부분을 의미한다. mailFrom 파라미터를 이용해 메일 송신지를, mailTo 파라미터로 스팸 메일 수신자를 지정할 수 있다.

 

[그림 11] 스팸 메일 발송 코드

스팸 메일은 스팸 메일 발송 기능이 있는 URL에 접근해 POST 방식으로 수신자와 내용을 지정한 후 발송됐다.

 

 

 

 

4. 대책

이번 사고는 파일 업로드 취약점을 이용한 웹 서버 침해가 스팸 메일 발송으로 이어진 사례였다. 이런 경우 아래와 같은 대책을 마련할 수 있다.

 

1) 업로드 디렉터리 실행 권한 제거
웹쉘 파일이나 기타 실행 가능한 파일을 업로드했더라도, 해당 디렉터리에 대한 실행 권한이 있어야 실행할 수 있다. 따라서 운영 목적에 맞도록 권한을 설정하고 다른 사용자(-rwxrwxrwx에서 마지막 3글자)에게 실행 권한이 부여됐는지 점검하는 것이 필요하다.

 

2) 업로드 파일 확장자 제어 및 파일 업로드 페이지에 대한 점검
이번 사건은 파일 확장자 제어가 올바르게 이루어지지 않아 발생했다(prohibited_ext 변수에서 php 확장자 누락). 따라서 현재 운영 중인 웹 애플리케이션 소스 코드에서 파일 확장자 필터링이 정상적으로 이루어지고 있는지 검사해야 한다. 또한 파일 업로드 페이지에 대해서 적절한 권한을 가진 사용자만 업로드할 수 있도록 돼 있는지 확인하고, 이러한 인증이 우회가 가능한지에 대해서도 점검해야 한다.

 

3) 주기적인 웹쉘 파일 검사
가장 중요한 것은 업로드가 가능한 확장자를 제어하는 것이지만, 관리가 잘 되지 않고 방치된 게시판이 많다면 웹쉘 탐지 솔루션을 사용하는 것도 한 가지 방법이다. 추천할 만한 웹쉘 탐지 솔루션 두 가지를 소개한다.

먼저, KISA에서 개발한 ‘WHISTL 2010’. 이 도구는 KISA에 신청(http://toolbox.krcert.or.kr/MMVF/MMVFView_V.aspx?MENU_CODE=14&PAGE_NUMBER=15)해 내려받을 수 있다. 로컬 디스크 드라이브의 웹쉘 파일 존재 및 악성코드 URL 삽입 여부를 검사할 수 있다. WHISTL 2010은 리눅스 2.4, 2.6 커널 버전과 윈도우 운영체제에서 실행 가능하다.

 

[그림 12] Whistl 2010 실행 화면

둘째, 안철수연구소에서 관제 서비스 형태로 제공하는 ‘쉘모니터(ShellMonitor)’ 솔루션이다. 이 솔루션은 윈도우, 유닉스, 리눅스, 솔라리스, HP-UX 계열에서 설치 및 운영이 가능하다.

 

[그림 13] 쉘모니터 탐지 화면

4) 주기적인 모의 해킹 및 취약점 점검
침해 사고가 발생하는 기업들의 공통된 특징은 오랫동안 관리되지 않고, 방치돼 있는 게시판이 많다는 점이다. 공격자는 이러한 게시판을 이용해 웹쉘 파일을 업로드한 후에 악성 행위를 수행한다. 그러므로, 보안 업체의 컨설팅 등을 통해 사내 혹은 IDC 인프라에 대해서 모의 해킹을 수행하고 보안 안정성을 주기적으로 점검하는 것이 중요하다. 네트워크 및 웹 애플리케이션 취약점 점검은 전용 툴이 있으므로 이러한 툴을 사용해 주기적으로 점검하는 것도 보안성 향상에 큰 도움이 될 수 있다.

 

5) 취약점이 존재하는 공개용 에디터 사용시 주의
공개용 에디터의 경우 다수의 취약점이 발견되고 쉽게 공개된다. 이런 취약점이 발표되는 경우 패치되기 이전에 공격당하기 쉽다. 이미 알려진 여러 가지 취약점이 있지만 이번 호에서는 FCKEditor에 존재하는 파일 업로드 취약점에 대해 간략히 살펴보겠다.
FCKEditor의 경우, /fckeditor/editor/filemanager/connectors/asp/connector.asp 위치에 파일 업로드 및 폴더 생성이 가능한 취약점이 존재한다. 아래 로그에서 공격자는 이 취약점을 이용해 특정 디렉터리에 파일을 업로드하고 해당 폴더에 접근한다. 이와 같은 공개용 에디터의 취약점은 해커들의 주요 목표가 된다.

 

공개용 에디터의 취약점을 제거하기 위해서는 배포 사이트에서 취약점 정보를 확인하고, 가능한 패치를 빨리 적용하는 것이 중요하다. 위 예제에서는 /fckeditor/editor/filemanager/connectors/asp/connector.asp을 사용하지 않는 경우에 삭제하는 것을 권고하고 있다.

아래는 해당 내용에 대한 참고 링크다.

 http://www.ocert.org/advisories/ocert-2009-007.html
 http://eidelweiss-advisories.blogspot.com/2010/05/hustoj-fckeditor-remote-arbitrary-file.html

 

 

5. 결론

이상으로 웹 서버 침해를 통해 스팸 메일을 발송하는 사례에 대해서 살펴보았다.
이 업체의 경우 한 대의 웹 서버에서 여러 웹 사이트를 운영하고 있어, 각 사이트의 게시판이 제대로 관리되지 않고 있었다. 공격자는 이러한 취약한 게시판을 이용해 웹쉘 및 파일 업로드 기능을 가진 코드와 스팸 메일 발송 코드를 업로드했다.
이런 취약점을 제거하기 위해서는 네트워크 및 시스템, 그리고 웹 애플리케이션에 대한 주기적인 점검이 필요하다.

 

먼저, 네트워크 및 시스템을 위해서는 방화벽(Firewall)과 침입탐지/차단시스템(IDS/IPS)을 설치해야 한다. 방화벽을 설치한 후에는 접근 제어 리스트(ACL)가 운영 목적에 맞게 올바르게 설정돼 있는지 주기적으로 검토해야 한다. 침입탐지/차단시스템으로 웹 애플리케이션의 취약점을 공격하는 SQL 인젝션이나 XSS(Cross-site Scripting) 등에 대해서 어느 정도 탐지가 가능하지만 완벽한 탐지 및 방어가 가능한 것은 아니다.

둘째, 파일 업로드 취약점을 제거하기 위해서는 웹 페이지를 개발할 때 시큐어 코딩을 하는 것이 매우 중요하다. 사이트를 오픈하기 전에 보안성 테스트를 반드시 거쳐 추후 발생할 수 있는 위협에 대비해야 하며, 일반적인 공격에 대해 폭넓게 방어해주는 웹 방화벽도 설치 및 운용하는 것이 좋다.

 

셋째, 시스템 및 웹 사이트 운영 시 가장 중요한 것은 감사 로그를 남기는 것이다. 침해를 당하더라도 로그가 남아 있지 않으면 분석 자체가 불가능하고 침해 원인을 밝힐 수 없는 경우도 있다.

안전한 웹 서비스 제공을 위해서는 보안 담당자와 시스템 운영 담당자의 보안에 대한 꾸준한 관심과 투자가 필요하다.@