침해사고 분석 절차 가이드[3] - 주요 해킹 사고별 분석 사례

제 4 장  주요 해킹 사고별 분석 사례

제1절 악성코드 은닉 사이트 분석 사례

  2005년 중순경부터 시작된 중국 할당 IP로부터의 공격은 이제 일반화되었으며, 국내 웹 환경의 가장 심각한 문제 중의 하나로 대두되었다. 악성코드 은닉 사고는 KISA에서 자체 탐지한 건수만 해도 월 500여건에 이르고 있다. 하지만, 악성코드가 은닉된 해킹 피해 기관에서는 해당 악성코드만 삭제하여 십 여회 이상 악성코드가 재 삽입되는 경우를 종종 볼 수 있다. 이는 체계적인 사고분석과 대응절차를 거치지 않고 단순히 홈페이지의 악성코드만을 삭제하였기 때문이다.

  악성코드 삽입 사이트의 경우 홈페이지에 포함된 악성코드를 찾아내어 삭제하는 것은 물론이고, 웹서버에 존재하는 웹쉘(Webshell)과 같은 백도어 프로그램들을 찾고, 이 웹서버가 침해당한 원인(취약점)을 로그파일 등을 통해 확인하여 근본적인 침해 원인을 제거하는 것이 중요하다.

  본 절에서는 악성코드 은닉 사이트에 대한 분석과 대응절차를 살펴보고 국내에서 유사사고 발생시 활용할 수 있도록 한다.

  홈페이지 악성코드 은닉사고에 대한 대응절차를 요약하면 다음과 같다. 다만 여기에서 언급하는 절차는 일반적으로 해킹 피해기관에서 자체적으로 사고처리를 하기 위한 기본적인 절차이며, 법적 증거물로 활용하기 위해 시스템에 대한 무결성 보장이 필요한 경우는 체계적인 포렌식 절차를 따라야만 한다.

  ① 악성코드 삽입사실 인지 및 삭제
    홈페이지에 은닉된 악성코드는 홈페이지 방문자를 감염시킬 수 있으므로 해당 부분을신속하게 제거하여야 한다.

  ② 웹로그 및 이벤트로그 분석
    웹로그 및 이벤트로그 분석을 통해 공격에 악용된 취약점, 피해 규모 등을 분석한다.

  ③ 백도어 등 해킹 프로그램 제거
    로그분석 및 파일시스템 분석을 통하여 백도어 등 각종 해킹프로그램을 발견하고 이를 제거한다.

  ④ 주변 시스템 분석
    웹서버가 해킹당했을 경우 DB 서버 등 주변 서버도 이미 해킹당했을 가능성이 있다.
    웹 취약점에 의한 SQL Injectin 공격시 실제 명령실행이 DB서버에서 실행된다. 따라서, 웹서버와 연동하고 있는 DB서버의 해킹가능성을 특히 의심해 볼 필요가 있다.

  ⑤ 취약점 제거 및 보안강화
    해킹에 악용된 취약점을 포함하여 전반적인 보안 취약점을 점검하고 이를 제거하여 해킹 재발을 방지하여야 한다.

  ⑥ 서비스 재개 및 모니터링
  모든 조치가 완료된 이후에도 일정기간 공격 모니터링을 강화할 필요가 있다. 해커들은 대부분 한번 해킹한 사이트를 다시 이용하여 해킹을 하고자 한다. 따라서 웹로그및 트래픽 분석을 통해 이러한 공격시도를 확인할 필요가 있다.

  각 단계에서 취해야 하는 상세 활동내역은 다음과 같다.

1. 악성코드 삽입 사실 인지 및 악성코드 삭제
  홈페이지에 악성코드가 삽입되는 유형은 대단히 다양하고 교묘하게 발전하고 있어 웹 관리자에 의한 발견이 쉽지 않다. 관리하고 있는 사이트에서 악성코드 삽입사실을 인지할 수 있는 것은 다음과 같은 경우가 있다.

  - 홈페이지 관리자가 웹 소스 분석을 통해 분석
  - 홈페이지 방문자가 바이러스 백신의 경고창에 의한 발견
  - KISA 등 제3의 기관으로 부터의 악성코드 삽입사실 통보

  홈페이지에 악성코드가 삽입될 경우 홈페이지 방문자들의 PC가 감염되고 바이러스 백신이 이를 탐지하여 경고창을 PC 사용자에게 보여줄 수 있다. 이러한 이유로 홈페이지 방문자의 전화문의 또는 게시판에 홈페이지의 이상현상과 관련된 글들이 게시될 수 있으므로 홈페이지 관리자는 이들의 목소리에 귀를 기울일 필요가 있다.

  일반적으로 다음과 같은 방법으로 악성코드를 삽입하고 있으므로 웹 관리자는 아래 사항들에 대해 유심히 살펴볼 필요가 있다.

  가. 웹 페이지에 iframe 또는 object 코드 삽입
    - 초기화면 등 접속자 방문이 많은 웹 페이지에 악성코드를 삽입하며, 대부분의 경우사이즈 크기를 0×0로 하여 홈페이지 상에서는 유관으로 확인할 수 없는 iframe 또는 object 코드를 삽입한다.

  나. 인코딩 코드 삽입
    - 악성코드의 은닉사실 및 내용을 숨기기 위해 코드를 인코딩하여 삽입하기도 한다.

  다. 오류 정보 표시 페이지에 삽입
    - 웹서버의 오류정보 페이지에 일반 웹 페이지에 삽입하는 방법과 마찬가지로 악성코드를 삽입한다.

  라. 자바스크립트 코드 삽입
    - 방문자수를 카운트하는 자바 스크립트 등 많은 페이지에서 참조하는 js 또는 css 파일등에 악성코드를 삽입하기도 한다.

  마. 바이너리 형태의 객체 삽입
    - 플래시파일(swf)과 같은 외부 객체파일에 악성코드를 삽입하여, 변조한 객체를 사용하는 페이지 접속자들에게 악성 프로그램을 유포한다.

  바. 데이터베이스내의 자료 값 변조
  - 일반적인 파일 변조와는 달리, 데이터베이스에 저장되어 있는 자료 값에 악성프로그램 유포용 코드를 삽입하기도 한다.

  위와 같이 다양한 방법에 의해 삽입된 악성코드를 발견할 경우 즉시 이를 제거하여 홈페이지 방문자들의 감염을 최소화하여야 한다.

  그리고, 전통적인 분석절차에 따라 시스템 내의 휘발성 정보를 분석한다. 구동중인 프로세스 리스트, 네트워크 상태, 레지스트리 상태 등을 분석하여 악성 프로그램이 구동 중일 경우 해당 프로세스나 네트워크 세션을 차단하여 추가적인 피해 확산을 차단한다.

2. 웹로그 및 이벤트로그 분석
  일차적으로 홈페이지 방문자들을 감염시킬 수 있는 악성코드를 제거한 후에는 악성코드가 삽입된 원인 및 피해규모를 파악할 필요가 있다. 이는 웹로그 및 이벤트로그 분석을 통해확인이 가능하다.

  가. IIS 웹로그 분석
  지금까지 분석된 악성코드 은닉 사고는 SQL Injection 또는 업로드 취약점으로 인한 경우가 많았는데, 이러한 공격은 웹로그 분석을 통해 가능하다.

  아래는 공격자가 SQL Injection 취약점을 이용한 공격 흔적이다.

  위의 로그는 new_detail.asp 게시판 프로그램의 id라는 인자가 입력값을 검증하지 않아 공격용 SQL Query를 필터링 없이 받아들였음을 보여주고 있다. 첫 번째 라인의 로그는 공격자가 취약점을 확인하기 위한 것이며, 두 번째 라인은 실제 공격을 하여 공격이 성공(상태 코드 200)한 것을 확인할 수 있다. 웹 관리자는 웹로그를 통해 공격자가 이용한 웹 프로그램의 취약점을 확인하고 이를 보완할 필요가 있다.

  일반적으로 IIS 웹서버의 SQL Injection 공격은 중국 자동화된 해킹도구에 의해 이루어지고 있는데, 이 도구에 의한 공격시에 위와 같은 공격 로그가 수백~수천라인이 생성되므로 공격 사실을 쉽게 알 수가 있다.

  SQL Injection 공격과 함께 악성코드 은닉 사고에 많이 사용되는 방법은 다운로드 공격이다. 다음은 공격자가 다운로드 취약점을 공격한 흔적이다.

  위의 로그는 공격자가 해킹 프로그램(svnge.asa)을 첨부파일로 업로드 하고, 해당 해킹프로그램을 웹 브라우져를 통해 실제 실행해 본 것을 보여주고 있다.

  웹로그 분석은 해킹에 이용된 취약점을 파악하는 것 뿐만 아니라 웹쉘(WebShell)과 같은 백도어 탐지도 가능하게 한다.

  다음은 공격자가 웹쉘을 통해 접근하여 피해시스템의 파일을 리스팅하고 특정 파일을 업로드하고, 또한 특정 파일을 편집한 흔적이다.

  이처럼 악성코드 은닉사고에서는 SQL Injection, 업로드 공격 등 공격에 이용된 취약점 및 웹쉘 실행 등 공격 이후의 행위를 웹로그 분석을 통해 확인할 수 있다. 하지만, 대규모 웹사이트의 경우 엄청난 량의 웹로그가 생성되어 공격로그를 찾아내기 어려운 경우가 많다. 따라서, 모든 로그를 한 라인씩 분석하기 보다는 공격시 발생되는 특정 키워드를 찾는 것이 효율적일 수 있다. 다음은 일반적으로 웹 공격시 웹로그에 나타날 수 있는 스트링들이다.

  물론 이러한 스트링들이 웹로그에 나타났다고 모두 공격이라고 단정지을 수는 없다. 이러한 스트링이 나타날 경우 공격 가능성이 높으므로 좀 더 자세한 분석이 필요하다. 리눅스환경에 익숙한 관리자의 경우 윈도우즈에서 리눅스 환경(vi 편집기, grep 등)을 사용할 수 있도록 해 주는 Cygwin을 사용하면 보다 편리하게 분석할 수 있다.

  나. 이벤트 로그 분석
  이벤트 로그는 시스템 로그, 어플리케이션 로그, 보안 로그 등 3가지 종류가 있다. 이벤트 로그는“시작 -> 프로그램 -> 관리도구(공용) -> 이벤트 뷰어”를 통해 확인할 수 있다.

  MS-SQL 확장 저장 프로시저인 xp_cmdshell은 MS-SQL 서버를 통해 임의의 커맨드 명령을 실행할 수 있는 것으로 정상적인 웹 프로그램에서 사용할 수도 있으나 일반적으로 공격자에 의해 많이 사용된다. 다음은 xp_cmdshell의 실행기록이 이벤트 로그에 남은 것이다.

  그 외에도 로그온 성공/실패 관련 로그(보안 이벤트 로그가 enable되어 있을 경우), 바이러스 백신에 의한 악성코드 관련 검출 로그 등 공격에 관련된 유용한 정보들을 이벤트 로그분석을 통해 얻을 수 있다.

3. 백도어 등 악성 프로그램 제거
  홈페이지에 악성코드가 은닉된 사이트들의 경우 공격사실을 숨기기 위해 여러 공격도구를 설치하지 않고 반드시 필요한 도구만 설치하기도 한다. 하지만, 공격자는 웹서버를 해킹한 후 시스템을 원격 제어하기 위한 백도어나 다른 시스템을 공격하기 위한 해킹 프로그램을 설치하는 경우도 흔히 볼 수 있다. 악성코드 은닉사고에서 일반적으로 볼 수 있는 해킹프로그램은 웹쉘로 알려진 백도어 프로그램이다. 악성코드 은닉 사이트에서 발견된 웹쉘은일반적으로 ASP 프로그램으로 제작되고 있으며, 파일 추가/삭제/변경, 원격 명령 실행 등 원격에서 해당 시스템을 완벽하게 제어할 수 있는 기능을 가지고 있다.

  다음은 웹브라우져를 통해 접속한 웹쉘의 화면이다.

  공격자가 웹쉘을 통해 피해 시스템에 침입하여 악의적인 행위를 하는 경우 웹로그에 그 흔적이 남는다. 따라서, 웹로그 분석과정에서 웹쉘 사용 유무를 유심히 살펴볼 필요가 있다. 웹쉘은 다양한 곳에 위치할 수 있는데 파일을 업로드한 폴더에서 종종 발견된다.

  이외에도 \WINNT\system32 또는 \Windows\system32 폴더, 휴지통(Recycle) 폴더 등에서도 일반 악성프로그램들이 종종 발견된다. 이러한 악성 프로그램들은 윈도우 탐색기를 통해 공격 발생시점을 전후하여 생성 또는 변경된 파일들을 찾는 방법을 사용할 수도 있다.
  그리고, 특정 중국 공격도구로 해킹 당했을 경우, t_Jiaozhu, jiaozhu, comd_list, xiaopen 등과 같은 임의의 테이블이 DB에 생성되기도 한다. 악성코드 은닉사고의 사고분석시 DB 테이블을 점검하여 아래와 같은 이름의 비정상적인 테이블이 있는지 분석하고 삭제하여야 한다.

  일반적으로 공격자들은 방화벽을 통과하여 한 대의 서버에 해킹을 성공하게 되면 이 서버를 통해 내부망의 다른 서버들까지 장악하려 한다. 방화벽 외부에서의 공격보다는 내부에서의 공격이 훨씬 용이하고, 공개된 웹서버 이외에도 좀 더 가치있는 정보들이 내부망에 존재할 가능성이 높기 때문이다. 따라서, 웹서버 해킹 피해시 웹서버와 연동된 시스템들에 대한 분석도 병행할 필요가 있다. 특히, 웹서버에 악성코드가 은닉되어 있고, 웹서버와 DB 서버가 분리되어 운영되고 있는 환경인 경우, DB서버가 이미 해킹당했을 가능성이 높다. 중국에서 제작된 SQL Injection 공격도구를 사용할 경우 DB서버에서 1차적인 해킹이 이루어진다. DB서버에서는 대부분 공격 로그가 적절하게 남지 않으므로 로그분석보다는 DB 테이블에 비정상적인 테이블이 숨겨져 있는지, 파일 시스템에 해킹 프로그램이 숨겨져 있는지를 중점적으로 볼 필요가 있다. DB서버의 파일 시스템 분석시에는 시스템 폴더(\WINNT\system32 또는 \Windows\system32 폴더)를 중점적으로 점검한다.

5. 취약점 제거 및 보안강화
  악성코드와 시스템에 숨겨진 백도어 등 해킹 프로그램을 제거하였다고 하더라도, 며칠 후 다시 해킹을 당하는 경우가 많다. 이는 해킹 프로그램만 제거하고 근본적인 취약점을 제거하지 않았기 때문이다.

  따라서, 해당 시스템에 어떠한 보안 취약점이 있는지 분석할 필요가 있다. 가장 우선적으로 하여야 할 부분은 공격자가 이미 공격에 이용한 취약점을 확인하는 것으로, 웹로그 분석 과정에서 공격자가 어느 프로그램의 어느 인자의 취약점을 이용하여 공격하였는지, 어느 게시판에서 파일 업로드 취약점이 존재하는지를 확인할 수 있다. 공격에 이미 이용되었던 취약점은 공격자가 다시 공격할 가능성이 상당히 높으므로 반드시 취약점을 제거하여야 한다. 이외에도 전반적으로 웹 프로그램상에서 사용자의 입력을 받아들이는 모든 부분, 즉, URL
인자, 쿼리 문자열, HTTP 헤더, 쿠키, HTML 폼 인자 등 입력 값에 대한 검증이 필요하다. KrCERT/CC 홈페이지(http://www.krcert.or.kr)에서「홈페이지 개발 보안 가이드」와「웹어플리케이션 보안 템플릿」을 제공하고 있으므로 취약한 부분의 웹 프로그램을 보완할 필요가 있다.

  안전한 웹 프로그램이 재해킹을 예방하기 위한 최선의 방법이지만, 이미 운영중인 시스템에서 프로그램을 수정하기가 쉽지 않은 경우도 있다. 이 경우에는 웹방화벽의 도입도 검토해 볼 필요가 있다. 중소기업과 같이 웹 트래픽 양이 많지 않은 경우 공개 웹방화벽을 사용하는 것도 바람직하다. 공개 웹방화벽에는 IIS 웹서버용으로 WebKnight, Apache 웹서버용으로 ModSecurity가 있다. 이들 툴들에 대한 설치∙운영 가이드와 프로그램도 http://www.krcert.or.kr 홈페이지를 통해 다운로드 받을 수 있다. 충분한 최적화 과정 없이 웹방화벽을 적용할 경우 정상적인 웹요청도 차단될 수 있으므로 자신의 웹환경에 맞도록 Rule을 커스터마이징하여야 한다.

6. 서비스 재개 및 보니터링
  만약 사고분석을 위해 서비스를 중지하였다면 백도어 제거, 취약점 제거 및 보안강화 과정 이후에 다시 서비스를 재개한다.
  한 가지 주의할 점은 공격자는 이미 악성코드를 은닉한 사이트에서 악성코드가 제거되어도 다시 공격하여 악성코드를 삽입하고자 하는 경우가 많다. 실제 어떤 사이트는 십 여회 이상 재공격을 당하기도 하였다. 그리고, 이미 해킹을 당한 사이트이므로 웹 페이지의 취약점을 재공격하지 않고 사전에 만들어 놓은 백도어를 통해 접근할 수도 있다. 따라서, 서비스 재개 이후에 당분간 트래픽이나 로그 등의 분석을 통해 해당 시스템에 대한 이상징후를 모니터링하고, 이에 대해 적절히 대응할 필요가 있다.


제2절 악성 Bot C&C 분석 사례

  국내의 서버가 악성 봇들의 명령∙제어서버(악성 봇 C&C 서버)로 악용하는 경우가 지속적으로 발견되고 있다. 수십~수천 개의 봇에 감염된 시스템들이 접속하는 악성 봇 C&C 서버의 특성상 빠른 네트워크를 필요로 하기 때문에, 인터넷 인프라 환경이 우수한 국내의 서버를 해킹하여 악용하려는 시도가 계속되고 있는 것으로 보인다.

  이번 절에서는 사례를 위주로 악성 봇 C&C 서버의 분석방법에 대해 알아보자.

1. 사전 준비사항

  가. 네트워크 패킷 분석 도구
  악성 봇 C&C 서버는 외부의 봇 감염시스템과 통신하기 때문에 해당 시스템에서 네트워크 패킷을 캡쳐(capture)하여 분석하는 일은 기본적인 분석과정이다. 네트워크 패킷 분석도구는 상용제품인 sniffer, etherpeek, 공개제품인 ethereal 등이 있다.

  나. 포트, 프로세스 확인 도구
  악성 봇C&C서버에 어떤 포트가 오픈되어 있고 이 포트를 오픈한 프로세스가 어떤 것인지 확인을 하기 위해 필요하다. 윈도우나 리눅스 운영체제에서 제공하는 기본 도구들이 한계가 있기 때문에 별도의 도구를 준비하는 것이 좋다.

  프로세스와 포트 점검에는 fport, tcpview와 같은 공개 프로그램이 많이 사용된다.

  다. 기타 분석도구

  경우에 따라 우리가 찾고자 하는 프로세스가 루트킷 등에 의해 숨겨진 경우가 있다. 이럴때를 대비하여 루트킷을 발견할 수 있는 도구를 추가적으로 준비하는 것이 좋다. 루트킷 발견 도구는 Rootkit Hook Analyzer, RootkitRevealer 등이 있다.

  악성 봇 C&C 서버 현장 조사 결과, 해당 시스템에 프록시서버, 원격제어프로그램, 악성봇 클라이언트 등이 함께 발견되는 경우가 많았는데, 이들을 발견하고 치료하기 위한 최신버전의 백신프로그램도 함께 준비하는 것이 좋다. 하지만, 악성 봇 C&C 서버가 사용하는 IRC(Internet Relay Chatting)프로그램 자체는 악성프로그램이 아니기 때문에 백신프로그램이 잡아내지 못하며, 변종 악성봇의 경우 최신 버전의 백신프로그램도 검출하지 못하는 경우가 있다.

2. 악성 봇 C&C 서버로 많이 사용되는 프로그램
  악성 봇 C&C 서버는 주로 IRC라는 프로그램을 설치하여 운영한다. IRC 프로그램은 원래 인터넷 사용자 간 대화를 목적으로 만들어졌지만, 사용자 간의 파일전송 뿐 아니라 원격 명령 제어 등도 가능한 프로그램이다.

  IRC프로그램 중에서도 많이 쓰이는 Unreal IRC는 리눅스 및 윈도우 버전 모두 존재하여 기본값으로 6667/tcp 포트를 사용한다.

  최근 많이 발견되는 MS Exchange Chat Server는 마이크로소프트사가 개발한 채팅프로그램으로 MS Exchange Server CD에 포함되어 배포되고 있다. 기본포트는 7000/tcp이다.

3. 분석과정

  악성 봇C&C서버로 의심되는 서버에서 우리가 취해야 할 행동은 다음의 네 가지이다.

  - 악성 봇C&C서버로 악용되고 있는지 여부
  - 공격자는 누구이며, 시스템에 어떤 행위를 하였는지 여부
  - 악성 봇C&C서버에 접속한 봇감염시스템들이 어떤 행위를 하는지 여부
  - 사고조사를 마치고 시스템을 원상 복구

  가. 악성 봇C&C서버 판별

  1) 악성 봇C&C서버 사용포트에 접속
  악성 봇C&C서버로 해당포트번호를 알고 있다면 IRC클라이언트 프로그램으로 접속해봄으로써 실제로 악성 봇C&C서버가 운영되고 있는지 여부와 배너 등을 통해 도메인명이나 접속자 수 등의 정보를 얻을 수 있다.

  아래의 그림은 해커가 시스템의 권한을 탈취한 후 IRC서버 프로그램을 설치하여 봇 C&C 서버로 만든 시스템에 ZeroIRC라는 IRC 클라이언트로 접속한 화면이다. 현재의 접속자 수와 가장 많았을 때의 접속 자 수 등을 접속 시 나타나는 메시지를 통해 확인할 수 있다.

  위의 방법으로부터 별다른 정보를 얻어내지 못했다면 ethereal 같은 프로그램을 이용하여 악성 봇 C&C 서버의 네트워크 패킷을 캡쳐하여 해당 포트를 확인하는 방법이 있다.

  아래 그림은 악성 봇 C&C 서버에서 ethereal로 캡쳐한 네트워크 패킷 기록이다. 패킷을 점검해 보면 외부에서 해당 서버로 6667포트 접속시도가 많은 것을 알 수 있다. ethereal의 “Follow TCP stream”기능을 통해 접속 시도 IP와의 tcp패킷 중 텍스트 데이터 부분을 별도로 발췌하여 확인한 내용이 작은 팝업창의 내용이다. 이 팝업창의 내용을 보면 NICK, USER, JOIN 등과 같은 IRC에서 사용되는 명령어가 보인다. 그 뿐 아니라 악성 봇 C&C 서버의 도메인 이름, IRC 프로그램의 버전, 현재 접속자 수, 최대 접속자 수 등의 다양한 정보도 함께 나타난다.

  하지만 악성 봇C&C서버가 항상 봇 감염시스템과 통신하고 있지 않은 경우가 많다. 몇 달 정도 악용된 후 버려진 악성 봇 C&C 서버의 경우도 많이 발견되었기 때문에 네트워크 패킷을 분석하는 방법이 100% 성공할 수는 없다는 것을 명심하기 바란다.

  2) 해당 프로세스 확인
  사용하는 포트를 확인한 다음, fport나 tcpview를 이용하여 해당 포트를 오픈한 프로세스와 파일의 위치를 추적한다.

  아래의 예제 그림은 또 다른 악성 봇 C&C 서버에서 tcpview를 이용하여 실행중인 프로세스와 해당 프로세스가 오픈한 포트를 감지한 화면이다. 이 시스템에서는 pdate.exe라는 의심스러운 파일이 113번 포트를 오픈하고 있는 것을 발견할 수 있다. 해당 프로세스를 선택하고 마우스 오른쪽 버튼을 클릭하면 파일의 정확한 위치도 파악할 수 있다.

  보통 공격자는 IRC를 시스템 부팅 시 자동 시작되도록 레지스트리나 시작프로그램에 해당 프로그램을 등록하는 경우가 많다. 따라서, 이곳을 확인함으로써 IRC프로그램을 찾아볼 필요도 있다.

  아래의 그림은 시작 서비스에 등록되어 있는 IRC 프로그램의 화면이다. 왼쪽에 있는 화면은 unreal IRC를 그대로 등록명에 사용한 경우로 쉽게 발견이 가능하지만, 오른쪽에 있는 화면의 경우처럼 해당 파일의 이름과 서비스명을 변경하여 마치 윈도우 기본 서비스나 반드시 필요한 서비스인 것 처럼 가장하는 경우도 많다.

  마지막으로 레지스트리의 점검도 필요한데, 아래의 그림과 같이 부팅 시 자동으로 시작될 수 있는 레지스트리 위치를 검색하여 의심스러운 파일이 등록되어 있는지를 확인할 필요가 있다.

  부팅시 자동 실행되도록 등록하는 레지스리는 일반적으로 다음과 같다.

    HKLM\Software\Microsoft\Windows\CurrentVersion\Run
    HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce
    HKLM\Software\Microsoft\Windows\CurrentVersion\RunServices
    HKLM\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce
    HKLM\Software\Microsoft\Windows\CurrentVersion\Windows\Load
    HKLM\Software\Microsoft\Windows\CurrentVersion\Windows\Run
    HKLM\Software\Microsoft\Windows\CurrentVersion\Userinit

  나. 공격로그 분석
  공격로그 분석에 대해서는 이미 앞의 장에서 자세히 설명하였기 때문에 이번 절에서는 생략하기로 한다. 다만, IRC프로그램을 직접 설치하는 경우는 없기 때문에 공격자는 먼저 취약점을 악용하여 시스템의 접근권한을 얻어내고 그 후 IRC프로그램을 복사해 왔을 것이므로 이점을 참조하여 로그기록(시스템의 기본 로그파일 및 ircd.log 등)과 IRC 설정파일(ircd.conf 등)을 찾아 추가적으로 분석할 필요가 있다.

  또한, 공격자를 찾기 위해 해당 시스템을 24시간 정도 모니터링할 필요가 있다. ircd를 다운시키고 기다리면 공격자가 다시 들어와 해당 ircd를 다시 시작하려는 경우도 발견되었다. 이때 공격자는 자신이 만들어놓은 백도어를 통해 들어오는 경우가 많다.

  아래 그림은 공격자가 다운된 악성 봇C&C서버를 되살리기 위해 TsInternetUser계정(사전에 공격자는 이 계정을“admin”그룹으로 변경해 두었다)으로 접속한 화면이다.

  다. 봇 감염시스템 분석
  악성 봇C&C서버에 접속해 있는 봇 감염시스템이 있는 경우 해당 트래픽의 모니터링을 통해 악성 봇 C&C 서버가 봇 감염시스템에게 어떠한 행위를 하는가 파악한다. 봇 감염시스템에서 직접 분석을 하는 것이 가장 좋은 방법이나 여의치 않은 경우 악성 봇C&C서버와의 네트워크 패킷을 분석해본다.

  아래 그림은 봇 감염시스템이 악성 봇 C&C 서버와 통신한 기록을 악성 봇 C&C 서버쪽에서 캡쳐한 것이다. 아래의 내용을 보면 봇 감염시스템은 악성 봇 C&C 서버에 접속하여 명령을 받는데, 또 다른 시스템에 접속하여 악성파일을 다운받고 실행하도록 되어 있다.

  라. 시스템 원상복구
  시스템에 대한 점검을 마치고, 악성 봇C&C서버를 삭제하고자 하는 경우 안전을 위해 시스템을 안전모드(윈도우의 경우)나 run level S(리눅스의 경우)와 같이 네트워크가 사용되지 않는 모드로 변경한 후 해당 파일을 삭제한다. 또한, 레지스트리나 시작서비스도 함께 삭제해야 한다.

  해당 파일을 삭제한 후 다시 서비스를 개시하기 전에 운영체제에 대한 보안 강화를 시행한다. 특히 공격자가 이용한 취약점은 반드시 보완해야 한다. 추가적으로 운영체제 보안패치를 최신버전까지 설치하고, 불필요한 서비스를 종료하는 등의 작업을 수행해야 한다.

  참고로, 악성 봇 C&C 서버를 다운시켰더라도 공격자가 배포한 봇(bot)에 해당 ip나 도메인이 들어있기 때문에 봇들의 접속시도가 당분간은 지속될 수 있다.


제3절 ARP Spoofing 기법 분석 사례

1. 개요
  최근 해외로부터의 홈페이지 해킹 후 악성코드를 삽입하는 사건들이 다수 발생되고 있는데, 이 사고들은 대부분 해당 웹서버가 직접 해킹당한 후 악성코드가 삽입되어졌다. 하지만, 올 초 해당 웹서버는 전혀 해킹을 당하지 않았음에도 불구하고 해당 웹서버로부터 악성코드가 다운로드 되는 사건이 발생했다. 이 사건은 공격자가 동일한 IP 세그먼트 내의 다른 서버를 해킹한 후 ARP Spoofing을 이용하여 특정 웹서버와 관련된 웹 트래픽을 가로채어 악성코드를 삽입한 사례였다.

  지금까지는 사용자들이 접속 회수가 높은 웹서버를 대상으로 같은 IP 세그먼트 내의 다른 서버를 해킹하여 ARP Spoofing 공격을 했었다. 하지만 이번에 소개할 사례는 웹서버가 대상이 아닌 보안패치가 되지 않은 개인 사용자 PC에 ARP Spoofing 행위를 하는 악성코드를 감염시켜 동일 세그먼트에 접속해 있는 다른 사용자들을 공격 및 악성코드를 감염/전파하는 사례를 소개하고자 한다.

  위의 사고 분석 결과 ARP Spoofing을 수행했던 PC는 1대가 아니라 여러 대였다. 같은 서브네트워크 PC들은 최초 감염된 PC의 ARP Spoofing 공격으로 인해 공격자가 유도한 악성코드 삽입페이지에 접속되었다. 그러한 PC 중 윈도우즈 미 보안 패치 사용자들은 ARP Spoofing 공격하는 googleons.exe에 또 감염되고 새롭게 감염된 PC는 네트워크를 대상으로 ARP Spoofing 공격을 다시 하게 되므로 네트워크 장애가 발생하게 되었다.

2. 상세분석
  분석 대상 PC들이 있었던 OO 기업 네트워크 환경은 아래와 같았다.
  ● 서비스 업체 : OOO (www.OOOO.net)
  ● 네트워크 환경: OOO ISP 회선 사용
  ● IP 대역 : 21x.9x.14x.0, 21x.x8x.21x.0

  가. ARP Spoofing 악성코드(googleons.exe) 감염 경로
  아파트인터넷 사용자 중 윈도우 보안 패치를 하지 않아 아래와 같은 사이트에 접속되어 ARP Spoofing 공격을 하는 악성코드에 감염이 되었다.

  ● 사이트 : down.onlinexxxxx.net
  ● 아이피 : 22x.2xx.139.12
  ● 근원지 : 중국
  ● 접속 페이지 :

  down.onlinexxxxx.net 사이트 악성페이지 구조는 위와 같으며 zzt.html 페이지는 공격 스크립트가 있는 페이지들로 유도하는 역할을 한다. 첫 번째 css.js 악성스크립트를 통해 MDAC MS06-014 취약점을 공격하여 악성코드인 down.exe를 설치한다. 하지만 보안 업데이트와 같은 이유로 공격에 성공하지 못하면 또 다른 취약점들인 MS05-25 의 png 취약점 공격과 MS07-017 ANI 취약점 공격을 통해 down.exe 프로그램 설치를 시도한다. 마지막으로는 공격 성공 여부에 상관없이 iframe으로 삽입되어 있는 top2.html 코드를 통해 최근 취약점인 MS07-027 공격까지 시도하게 된다.
  윈도우즈 보안 미 패치 사용자는 down.exe 악성코드를 공격스크립트들에 의해 사용자 계정 Temp 하위 디렉터리에 autoexebc.bat로 복사 및 실행하게 된다.

  ●위치: C:\Documents and Settings“\ 사용자계정”\Local Settings\Temp

  실행된 autoexecbc.bat는 아래 그림과 같이‘down.onlinexxxxx.net’사이트에서 googleons.exe 악성코드를 다운로드 및 실행하고 연속해서 악성 프로그램들을 다운, 생성, 실행하게 된다.

  나. down.exe (autoexebc.bat) 악성코드 분석

  IE 취약점으로 인해 사용자 PC에 다운로드된 down.exe는 사용자 폴더의 Temp 디렉터리에 autoexebc.bat 파일로 복사된다. autoexebc.bat의 주요 기능은 아래와 같다.

  ● ARP Spoofing을 하는 googleons.exe 다운로드 및 실행

  ● 시스템 시간 변경 : 2001년

  ● 방화벽 서비스 중지 및 각종 바이러스 백신 종료

  다. googleons.exe 악성코드 분석
  googleons.exe 는 ARP Spoofing 공격을 하는 악성코드로 또 다른 악성코드를 다운로드 및 생성하여 추가적인 행위를 하게 된다. 주요 기능은 아래와 같다.

  ● 감염된 PC와 같은 서브네트워크(브로드캐스팅 도메인) 대상으로 아래와 같이 ARP Spoofing 공격을 한다.

  ● 동일 네트워크에서 인터넷을 사용하는 사용자의 HTTP 네트워크 패킷에 아래와 같이 “<html”문자열이 들어가면 악성 iframe을 삽입한다.

  ● 공격자가 유도한 악성페이지 접속으로 인한 윈도우 미패치 PC들 악성코드 감염
    - googleons.exe 감염

  ● USB를 통한 악성코드 전파
    감염된 PC 드라이브 중 USB 타입을 갖는 드라이브에 아래와 같은 파일을 생성하게 되며 사용자가 컴퓨터에 다시 삽입할 경우 악성코드가 자동으로 실행되게 한다.
    - wsnctfy.exe 생성 (googleons.exe 복사)
    - AutoRun.inf

  ● 시스템에 존재하는 .html, tml, asp, php, jsp 확장자를 갖는 파일에 "<body" 문자열이 있으면 아래와 같은 iframe 을 삽입

  ● 재시작 레지스트리에 등록하여 재 부팅 후에도 시작

  ● 리소스에 저장되어 있는 Pcap 라이브러리 파일 및 악성코드 생성

  다. ARP Spoofing 공격으로 인한 네트워크 장애
  googleons.exe에 감염된 사용자 PC는 처음엔 1대지만 이후에 ARP Spoofing 공격으로 인해 아래와 같이 감염 PC가 계속 증가하게 된다. googleons.exe 감염 PC가 많아져 동일 네트워크 상에 ARP Spoofing 공격하는 PC들이 6~7대 까지 증가하게 되므로 정상적인 네트워크 서비스를 할 수가 없게 된다.

3. 결론 및 대책

  이제까지는 공격하고자 하는 웹서버와 동일 네트워크에 존재하는 보안에 취약한 웹서버를 공격하여 ARP Spoofing 공격을 시도하여 정상적인 서버의 지나가는 패킷들을 가로채서 악성코드를 삽입했었다. 하지만 이번 사고에서는 일반 사용자 PC 네트워크 대역을 공격하는 신종 악성코드가 등장 해 앞으로도 이와 같은 악성코드들의 감염 및 전파로 인하여 네트워크 가 다운되는 현상이 발생할 것으로 예상된다.
  ARP spoofing에 대응할 수 있는 대책으로는, 네트워크 관리자가 스위칭 장비에서 각 포트별 정적인 MAC 모니터링을 강화할 필요가 있다. 그리고 만약 특정 호스트로부터 지속적인 ARP 패킷이 수신된다면 비정상적인 호스트일 가능성이 높으므로 주의해야 한다. ARP cache를 감독하기 위한 도구도 있는데, 예를 들면 arpwatch라는 프로그램은 ARP cache를 모니터링하여 변경되는 경우에는 관리자에게 알린다. 자세한 내용은 krcert 홈페이지에서 다운받을 수 있는“ARP Spoofing 공격 분석 및 대책”기술 문서를 활용하기 바란다.

  최종적으로 악성코드 삽입으로 인한 피해를 줄이기 위해서는, PC의 올바른 관리와 서버들의 보안수준 강화로 사고를 예방해야 할 것이다.




출처 :