Practical Malware Analysis

(#14 Network_Signature)

01. 개요

1. 교재 Practical Malware Analysis 14장의 악성코드 기반 네트워크 시그니처에 대하여 학습한다.

2. 악성코드의 네트워크 대책에 대하여 학습한다.

3. 스노트를 활용한 악성코드 기반 네트워크 시그니처를 생성하고 실습한다.

02. 본론

1. 악성코드 기반 네트워크 시그니처

• 효과적인 네트워크 대책을 개발하는 방법을 알아본다.

  대책은 위협에 대응하거나 악의적인 행위를 탐지하고 예방하기 위해 취해지는 행위이다.

  효과적인 대책을 마련하려면 악성코드가 네트워크를 사용하는 방법과 활용하는 방법을 반드시 이해해야 한다.

   

  1-1. 네트워크 대책

• 네트워크 활동(IP주소, TCP/UDP포트, 도메인 이름, 트래픽 콘텐츠)의 기본 속성은 방어를 위한 네트워킹과

  보안 장비에서 사용한다. 방화벽과 라우터는 IP주소와 포트를 이용해 네트워크에 대한 접근을 제한하는데

  사용할 수 있다. DNS 서버는 알려진 악의적인 도메인을 싱크홀(Sinkhole)로 알려진 내부 호스트로 경로 변환을

  하게 설정할 수 있다.

  침입탐지 시스템(IDS), 침입방지 시스템(IPS), 그리고 이메일과 웹 프록시 같은 다른 보안 장비는 콘텐츠

  기반의 대책을 적용할 수 있다. 콘텐츠 기반 방어 시스템은 트래픽의 심층검사(Deeper inspection)가 가능하며,

  IDS에서 사용하는 네트워크 시그니처와 스팸을 탐지하기 위해 메일 프록시에서 사용하는 알고리즘을 포함한다.

  IP주소와 도메인 이름 같은 기본 네트워크 표시자 들은 대부분의 방어 시스템에서 지원되므로, 악성코드

  분석가가 주시하는 첫 번째 아이템이 된다.

• 실제 환경에서 악성코드 관찰

  샌드박스 환경에서 악성코드를 실행하거나 강제로 악성코드를 열어 디스어셈블된 코드 분석을 하는 것이 분석의 첫 번째 단계가 되는 것보다는 악성코드에 대해 사전에 갖고 있는 데이터를 먼저 리뷰하는 것이 바람직하다. 경우에 따라 분석가는 악성코드 샘플이나 의심스러운 실행 파일을 어떠한 정보도 없이 받기도 하지만, 대부분의 경우 추가적인 데이터를 받는다. 네트워크 중점을 둔 악성코드 분석을 시작하는 가장 좋은 방법은 악성코드가 이미 생성한 로그, 경고, 캡처된 패킷 등을 탐색하는 것이다.

+ 샌드박스 환경이 아닌 실제 네트워크에서 생성된 정보는 다음과 같은 주요 이점을 가진다.

• 라이브 환경에서 캡처된 정보는 악의적인 애플리케이션의 실제 행위에 대한 가장 정확한 모습을 제공한다.

  악성코드는 샌드박스 환경을 탐지하게 프로그래밍될 수 있다.

• 활성화된 악성코드에 존재하는 정보는 분석을 가속화하는 훌륭한 통찰력을 제공할 수 있다.

  실제 트래픽은 엔드 포인트 양측(클라이언트와 서버)에 존재하는 악성코드 관련 정보를 제공하는데 반해,

  샌드박스 환경에서 일반적으로 분석가는 엔드 포인트 중 하나에서 존재하는 정보에만 접근 할 수 있다.

  악성코드로부터 전달받은 콘텐츠 분석(파싱 루틴)은 일반적으로 악성코드가 생성하는 콘텐츠의 분석보다 더 어렵다. 그러므로 양방향 샘플 트래픽은 분석가가 착수한 악성코드의 파싱 루틴 분석에 성과를 맺을 수

  있도록 도움을 준다.

• 또한 소극적으로 정보를 리뷰했을 때 공격자에게 분석 활동이 노출될 수 있는 위험이 없다.

  해당 이슈는 아래에서 설명하는 'OPSEC = 작전 보안' 절에서 상세히 설명한다.

   

• 악의적인 행위의 표시자

  분석할 악성코드 실행 파일을 전달받아 샌드박스 환경에서 실행한 후 네트워크 이벤트를 주목하고 있다고 가정하자. 악성코드가 'www.badsite.com' 에 대한 DNS 요청을 한 후 DNS 레코드에 있는 반환된 IP 주소의

  80 포트로 HTTP GET 요청을 한다는 사실을 발견했다. 30초 후에 DNS 질의 없이 외부에 있는 특정 IP 주소로

  신호 발신을 시도한다. 이 시점에서 악의적인 행위의 세가지 잠재적 표시자(indicator)를 가진다.

<표 1-1 악의적인 행위의 샘플 네트워크 표시자>

이 표시자에 대한 추가적은 연구 할 수 있다. 인터넷 검색을 통해 악성코드가 생성된 지 어느 정도 시간이 흘렀

으며, 언제 첫 번째로 발견됐는지, 어떻게 유포됐는지, 누가 작성했는지, 공격자의 목적이 무엇인지를 찾을 수도

있다. 표적 공격의 존재성이나 새로운 작전을 의미할 수 있기 때문에 정보 부족 또한 이 점에선 유익할 수 있다.

하지만 좋아하는 검색 엔진을 무작정 사용하기 전에 온라인 연구활동과 관련된 잠재적 위험을 이해하는 것 이

중요하다.

• OPSEC = 작전보안

  인터넷을 이용한 악성코드 연구를 할 때 작전보안(OPSEC, Operations Security)의 개념을 이해하는 것이

  중요하다. OPSEC은 정부기관이나 군 에서 사용하는 단어로, 적이 민감 정보를 획득하지 못하는 하는 과정을

  의미한다. 악성코드를 조사하는 과정에서 일어나는 특정 행동은 악성코드 제작자에게 우리가 악성코드를 인지했음을 알려줄 수 있다. 예를 들어 이메일을 통해 회사 네트워크로 전달된 악성코드를 집에서 분석하고

  있는 중이라면 공격자는 DNS 요청이 회사의 IP 주소 영역의 바깥에 있는 IP 주소에서 이뤄졌음을 알 수 있다.

   

  + 다음과 같이 공격자가 조사 활동을 인지할 수 있는 잠재적 방법이 많이 있다.

  • 특정 개인에게 링크가 포함된 스피어 피싱 이메일을 보낸 후 예상했던 지역 외부의 IP 주소에서 해당 링크에 접속을 시도하는지 살펴본다.
  • 블로그 코멘트(인터넷 접근이 가능하고 자유롭게 수정이 가능한 사이트 등)에 인코딩된 링크를 생성하는 익스플로잇을 설계한다. (효과적으로 개별 정보를 생성하면서 공개적으로 전염 감사 추적이 가능함.)
  • 악성코드에 사용하지 않는 도메인을 삽입하고 도메인을 해석하는 시도를 지켜본다.

     

  1-2. 온라인에서 공격자를 안전하게 조사

  가장 안전한 방법은 공격자를 조사할 때 인터넷을 전혀 사용하지 않는 것이지만, 사실 이것은 비현실 적이다.

  인터넷 검색엔진에 있는 검색을 사용하는 경우라면 다음과 같인 두 가지 주의사항이 포함된다.

  • 도메인 쿼리 엔진에서 인지하지 못한 도메인 이름이 포함된다면 크롤러의 활동을 유할 할 수 있다.
  • 캐싱된 결과라고 하더라도 검색 엔진의 결과를 클릭하면 해당 사이트와 연관된 두 번째 링크나 이후 링크를 여전히 활성화할 수 있다.

     

• 인터넷을 사용한다면 공자의 잠재적인 감시망을 피하기 위해 우회적인 방법을 사용해야 한다.

  우회 방법은 다양하다. Tor, 오픈 프록시, 웹 기반 익명화와 같이 익명성 제공을 위해 설계된 서비스나

  메커니즘을 사용하는 것이다. 이런 종류의 서비스는 자신의 개인정보를 숨기는 데 도움을 줄 수 있지만,

  은닉을 시도하는 것을 드러내는 단서를 제공해 공격자의 의심을 자극할 수 있다.

  또 다른 방법은 연구를 위한 전용 가상 머신을 사용하는 것이다.

  + 다음과 같은 여러 방법을 통해 전용 머신의 정확한 위치를 숨길 수 있다.

  • 핸드폰(Cellular) 연결을 사용하는 방법
  • Secure Shell(SSH)이나 가상 사설 네트워크(VPN)을 이용해 원격 인프라에 연결을 터널링하는 방법
  • 아마존 일래스틱 컴퓨트 클라우드(Amazon EC2)같은 클라우드 서비스에서 실행되는 임시 머신 원격사용.

   

• IP 주소와 도메인 정보 얻기

  인터넷 환경을 구성하는 두 가지 기본 요소는 IP 주소와 도메인 네임이다.

  DNS는 'www.yahoo.com' 같은 도메인 네임을 IP주소로 변환한다. (역으로 IP주소를 도메인으로도 변환)

  당연히 악성코드 역시 일반적인 트래픽처럼 보이게 하고, 악의적인 활동을 호스팅할 때 유연성과 견고성을

  유지하기 위해 DNS를 사용한다. 도메인 네임이 등록되면, 도메인 네임서버, 관련 일자, 연락 정보 같이 등록자에 대한 등록 정보를 도메인 등록기관에 저장한다. 인터넷 주소는 대륙별 인터넷 등록기관(RIRs)이라고

  불리는 등록기관을 소유하고 있다. 등록기관은 IP 주소 블록, 블록의 조직 할당, 여러 유형의 연락처 정보를 저장한다. DNS 정보는 도메인 네임과 IP주소 사이의 매핑을 나타낸다. 게다가 블랙리스트(IP 주소 또한 도메인 네임에 적용 가능)와 지리적 정보(IP 주소에만 적용)를 포함한 메타 데이터를 사용할 수 있다.

   

   

  해당 정보는 다수의 무료 웹사이트가 존재하며 웹사이트를 통한 질의를 하면 다음과 같은 정보를 얻을 수 있다. 도메인 검색 사이트를 통한 질의는 다음과 같은 이점을 제공한다.

  • 다수의 후속 검색이 자동으로 이뤄진다.
  • 한 단계의 익명성을 제공한다.
  • IP주소에 대한 블랙리스트와 지역적 정보를 포함해 이력에 대한 정보나 다른 정보의 원천에 대한 질의에 기반을 둔 추가 정보를 신속하게 제공한다.

   

  다음 그림은 표적 공격에 사용된 백도어의 C&C 서버로 사용된 도메인 에 대한 두개의 whois 요청 예다.

  두개의 백도어 파일이 요청하는 C&C 서버의 도메인네임은 다르지만, 두 도메인의 등록(registration)에 나열된 이름은 동일하다.

  

  <그림 1-1 두 개의 다른 도메인에 대한 whois요청 결과의 예>

   

1-3. 콘텐츠 기반 네트워크 대책

IP 주소와 도메인 네임과 같은 기본 표시자(base indicator)는 특정 버전의 악성코드에 대한 방어를 하는 데 가치가 있을 수 있지만, 그 가치는 오래 지속되지 않을 수 있다. 공격자들이 다른 주소나 도메인으로 이동해 빠르게 변화하기 때문이다. 반연 콘텐츠를 기반으로 한 표시자는 좀 더 기본적인 특성을 이용해 악성코드를 식별하기 때문에 더 가치가 있으며, 일반적으로 오래 지속된다.

시그니처 기반 IDS는 가장 오래됐고 악의적인 활동을 탐지하기 위해 가장 일반적으로 배치되는 시스템이다.

IDS의 탐지는 악의적인 활동이 네트워크 트래픽에서 어떻게 보이는지에 대한 지식에 의존한다.

탐지에는 악의적인 트래픽을 정확히 탐지(ture positive)와, 악의적인 것처럼 보이지만 실제적으로는 정상적인 오탐(false positive), 악의적이지만 탐지하지 못하는 미탐(false negative)이 있다.

가장 이상적인 탐지는 정탐이 높고, 오탐과 미탐이 적을수록 좋지만, 일반적으로 시그니처

정책을 타이트하게 생성하여 정탐률 을 높이게 되면, 오탐은 적을 수 있으나 미탐이 높아지게 되고.

반대로 타이트하지 않은 방향으로 시그니처 생성하면 미탐이 낮아 지겠지만 오탐이 높아지게 된다.

이처럼 트레이드오프[trade off]가 존재하며, 최대한 두 개의 정책 목표의 밸런스를 맞추려 노력 해야 한다.

• 스노트를 이용한 침입 탐지 예

  가장 대중적인 IDS중 하나는 스노트(Snort)이다. 스노트는 룰이 적용되기 전에 반드시 참이어야 하는 일련의 요소들을 함께 연결한 시그니처나 룰을 생성하는 데 사용된다. 기본 룰 옵션은 콘텐츠를 식별하는 옵션(룰 옵션이라 불림)과, 콘텐츠와 연관이 없는 요소들을 식별하는 옵션(non payload 룰 옵션이라 불림)으로 나뉘어 있다. 넌 페이로드 룰 옵션의 예는 특정 플래그, TCP 또는 IP 헤더의 특정 값, 패킷 페이로드의 크기를 포함한다. 예를 들어 룰 옵션 flow:estableished,to_client는 서버에서 출발해 클라이언트로 향하는 TCP 세션의 한 부분이다. 다른 예는 dsize:200으로, 200바이트의 페이로드를 가진 패킷을 탐지한다.

   

• 특정 악성코드를 가정하여 기본적은 스노트 룰을 만들어 보면 다음과 같다.

  이 악성코드는 HTTP GET 요청을 만들 때 요청을 위해 사용되는 애플리케이션과 커뮤니케이션을 하기 위해 User-Agent 헤더 필드를 삽입한다. 일반적인 브라우저의 User-Agent는 문자열 Mozilla(역사적 규악에 의해)로 시작하고 Windows7에서 크롬을 사용할 경우 Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36 과 같이 표현된다. 이 User-Agent는 브라우저와 운영체제의 버전 정보를 제공한다.

  이 악성코드에서 사용한 User-Agent 는 Wefa7e로, 독특하며 악성코드가 생성하는 트래픽을 식별하는 데 유용하게 사용할 수 있다.

  alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"TROJAN Malicious User-Agent";

  content:"|0d 0a|User-Agent\: Wefa72"; classtype:trojan-activitry; sid:2000001; rev:1;)

   

  스노트 룰은 두 부분(룰 헤더와 룰 옵션)으로 구성된다.

  룰 헤더는 룰 액션(일반적으로 alert), 프로토콜, 출발지와 목적지의 IP 주소, 그리고 출발지와 목적지의 포트를 포함한다. 규약에 따라 스노트 룰은 환경별 최적화를 할 수 있는 변수를 사용한다.

  $HOME_NET과 $EXTERNAL_NET 변수는 내부와 외부늬 네트워크 IP 주소 범위를 지정하는 데 사용됐으며, $HTTP_PORTS는 HTTP 트래픽으로 해석돼야 하는 포트를 정의한다. 이번 경우 헤더에 있는 -> 가 단방향으로만 가는 트래픽에 적용되게 룰이 정의됐기 때문에 HTTP 포트를 목적지로 하는 아웃바운드 트래픽에 매치된다.

   

  룰 옵션 섹션은 룰의 발동 여부를 경정하는 요소를 포함한다. 점검 요소들은 일반적으로 순서대로 평가되고, 모든 요소가 참이어야 룰이 발동된다. 다음 표는 앞의 룰에 사용된 키워드를 설명한다.

<표 1-2 위 스노트 룰 키워드>

위 룰의 content 조건 내에서 파이프 심볼(|)은 16진수 표기의 시작과 같을 나타내기 위해 사용한다.

두 개의 파이프 심볼 사이에 포함돼 있는 내용은 원시(raw)값이 아닌 16진수(hex)값으로 해석된다. 따라서 |0d 0a|는 HTTP 헤더들 사이의 구분(개행 문자)을 나타낸다. 샘플 시그니처에서 content룰 옵션은 HTTP 헤더 필드 User-Agent: wefa7e와 일치한다. HTTP 헤더가 두개의 문자 0d와 0a로 구분돼 있기 때문이다.

위와 같이 원본 표시자와 시그니처를 갖게 되면 대개 샌드박스 같은 자동화 분석 기반과 함께 네트워크 기반의 표시자 분석은 이 시점에서 완료됐다고 간주한다. 방화벽에서 차단할 IP 주소와 프록시에서 차단할 도메인 네임, 그리고 IDS 로딩할 네트워크 시그니처를 알아냈지만, 여기서 분석을 멈추는 것은 실수이다.

• 더 자세한 스노트를 이용한 탐지 예

  악성코드 분석가는 신속한 조치와 정확성 사이의 균형을 잡기 위해 노력한다. 네트워크 기반 악성코드 분석의 경우 신속한 조치는 샌드박스에서 악성코드를 실행한 후 그 결과가 충분하다고 가정하는 것이다. 정확한 방법은 순차적으로 악성코드의 함수를 완벽하게 분석하는 것이다.

  예제 정책은 이머징 스릿(Emerging Threat) 프로젝트에서 스노트(Snort) 규칙을 작성해 등록한 실제 악성코드 콘텐츠 기반의 룰 이다. 시그니처 생성자는 실제 트래픽에서 User-Agnet에 대해 두개의 값(Wefa72와 Wee6a3)을 확인했다고 언급했다.

   

  alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS

  (msg:"ET TROJAN WindowsEnterpriseSuite FakeAV Dynamic User-Agent";

  flow: established,to_server; content:"|0d 0a|User-Agent\: We"; isdataat:6,relative; content: "|0d 0a|";

  distance:0; pcre:"/User-Agent\: We[a-z0-9]{4}\x0d\x0a/";

  classtype: trojan-activity; reference:url,www.threatexpert.com/report.aspx?md5=d9bcb4e4d650a5ed4402fab8f9ef1387; sid:2010262; rev:1;)

   

<표 1-3 위 스노트 룰 키워드>

룰이 다소 길긴 하지만, 룰의 핵심은 단순하게 We의 뒤를 잇는 네 자리의 영문자와 숫자 조합 문자(We[a-z0-9]{4}로 이뤄진 User-Agent 문자열이다.

스노트에서 사용한 펄 호환 정규 표현식(pcre) 표기범에서 다음과 같은 문자들이 사용됐다.

<그림 1-2 정규식 도형화: http://regexper.com/#We%5Ba-z0-9%5D%7B4%7D>

- 대괄호([ ])는 사용 가능한 문자들의 집합을 나타낸다.

- 중괄호 ({ })는 문자의 개수를 나타낸다.

- 바이트를 위한 16진수 표기법은 \xHH 형태로 나타낸다.

앞서 언급했듯이 룰 헤더는 IP주소, 포트, 프로토콜 같은 기본 정보를 제공한다.

스노트는 TCP 세션을 추적하기 때문에 TCP 협상(handshake)을 바탄으로 한 클라이언트나 서버 트래픽에 특정된 룰을 작성할 수 있다. 이번 룰에서 flow 키워드는 연결된 TCP 세션 중 클라이언트 측에서 생선된 트래픽에 대해서만 탐지되도록 한다. 어느 정도 사용된 후에 이룰은 대중적인 Webmin 소프트웨어의 사용으로 발생하는 오탐을 제거하기 위해 약간 수정되었다. 다음은 수정된 최신 룰이다.

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS

(msg:"ET TROJAN WindowsEnterpriseSuite FakeAV Dynamic User-Agent";

flow: established,to_server; content:"|0d 0a|User-Agent\: We"; isdataat:6,relative; content: "|0d 0a|";

distance:0; content:!"User-Agent|3a| Webmin|0d 0a|";

pcre:"/User-Agent\: We[a-z0-9]{4}\x0d\x0a/"; classtype: trojan-activity;

reference:url,www.threatexpert.com/report.aspx?md5=d9bcb4e4d650a5ed4402fab8f9ef1387;

reference:url,doc.emergingthreats.net/2010262;

reference:url,www.emergingtheats.net/cgi-bin/cvsweb.cgi/sigs/VIRUS/TROJAN_WindowsEnterpriseFakeAV;

sid:2010262; rev:4;)

content 표현(content:!"User-Agent|3a| Webmin|0d 0a|")에서 사용된 느낌표(!)는 논리적으로 반대되는 선택(즉, not)을 나타낸다. 따라서 해당 룰은 표현된 content 가 나타나지 않는 경우에만 발동된다.

하지만, not content 사용시 해당 content가 유니크하지 않을 경우 IDS 장비에 무리를 줄 수 있다.

위 예제는 시그니처의 개발 프로세스의 일반적인 몇 가지 특성을 보여준다.

• 첫째, 시그니처 대부분은 트래픽을 생성한 악성코드에 대한 분석보다는 네트워크 트래픽 분석을 바탕으로 생성된다.
• 둘째, 오탐(false positive)이 발생하지 않게 시그니처에 특화된 패턴의 고유성을 테스트 한다.

실제 트래픽을 대상을 시그니처를 생성한 후 오탐이 발생하는지를 확인함으로써 테스트를 수행한다.

이번의 경우 원본 시그니처는 실제 트래픽을 대상으로 적용됏으며, User-Agent Webmin을 포함한 정상 트래픽에 대해 오탐을 발생하였다. 그 결과 시그니처는 정상 트래픽에 대해 예외 처리를 하게 재정의 됐다.

앞서 언급한 바와 같이 악성코드가 활동 중일 때 캡처된 트래픽은 연구실 환경에서 재현하기 어려운 상세한 정보를 제공한다. 다른 한편으로는 실제 환경에서 사용 가능한 샘플을 수가 작을 수 있다. 풍부한 샘플을 갖고 있음을 확인할 수 있는 한가지 방법은 악성코드에 대한 동적 분석을 반복하는 것이다. 샘플 악성코드를 여러 번 실행한 후 다음과 같은 User-Agent 문자열 목록이 생성 됐다고 가정하자.

위 결과와 같이 User-Agent에 특정 문자열을 확인한 결과, 악성코드가 생성하는 트래픽의 램덤 요소를 파악할

수 있었다. 위 리스트는 4개의 문자가 영문자와 숫자 집합이고, 문자들이 무작위로 분산돼 있음을 나타낸다.

하지만 기존 룰의 PCRE를 보면 User-Agnet\: We[a-z0-9]{4}\x0d\x0a/로 정의 했지만, 문자열의 랜덤요소는

a-z보다 a-f로 문자가 한정되어 있음을 알 수 있다. 따라서 이 문자의 랜덤요소의 바이너리 값이 16진수

표현법으로 직접적으로 변환될때 자주 사용한다고 판단할 수 있다. 이런 식으로 좀더 깊이 트래픽을 관찰하여

룰을 더 정교하고 정확하게 재 수립하는 것을 실무에서는 "룰 고도화" 또는 "정책 고도화" 라고도 한다.

• 추가적인 학습을 위해 악성코드를 여러 번 실행해 다음과 같은 User-Agent 문자열을 얻었다고 가정해 본다.

위 User-Agent 문자열이 나왔다고 가정하면, 기존 시그니처가 일부 결과를 잡을 수 있겠지만,

We에 더해 Wf와 W1을 생성하는 트래픽에 대해 분명히 이상적인 상태는 아니다. 또한 샘플을 통해 User-Agent가 일반적으로 6개의 문자로 구성되지만, 7개의 문자가 될 수 있음을 할 수 있다.

악성코드가 나열된 결과를 만들기 위해 정확히 어떤 작업을 하는지 모르기는 하지만, 이제 우리는 좀더 나은 추측을 할 수 있다. 악성코드는 시스템 정보를 외부 전송의 입력 값으로 이용할 수 있다는 사실을 기억하자.

최소한 두 개의 시스템에서 샘플 트래픽을 생성하는 것이 발신신호(beacon)의 어떤 부분이 고정되는지에 대해 잘못 가정하지 않게 도움을 준다. 고정되는 내용은 특정 시스템에 대해 고정적이지만, 호스트별로는 달라진다.

예를 들어 단일 시스템에서 악성코드를 여러 번 실행한 후 다음과 같은 결과를 얻었다고 가정해보자.

교차 점검을 할 수 있는 라이브 트래픽을 갖고 있지 않다는 가정하에 앞의 단일 User-Agent를 탐지하는 룰을 작성하는 실수를 할 수 있다. 하지만 악성코드를 실행한 다른 호스트에서는 다음과 같은 결과를 얻을 수 있었다.

시그니처를 제작할 때 대상 콘텐츠의 반화되는 요소를 파학해 그것이 실수로 시그니처에 포함되지 않게 하는 것이 중요하다.

시도를 할 때마다 달라지는 콘텐츠는 일반적으로 데이터의 근원이 무작위 속성을 갖고 있음을 나타낸다. 임의의 호스트에서는 고정적이나 다른 호스트에서 달라지는 콘텐츠는 해당 콘텐츠가 호스트의 속성으로부터 유래했음을 나타낸다. 운이 좋은 경우 호스트 속성에서 유래되는 콘텐츠가 네트워크 시그니처에 정의할수 있을 만큼 충분히 예측 가능할 수도 있다.

1-4. 동적 분석 기법과 정적 분석 기법의 조합

지금까지 시그니처 생성 방법을 알리기 위해 존재하는 데이터나 동적 분석의 결과를 사용했었다.

이런 방법은 편리하고 정보를 빠르게 생성할 수 있지만, 때때로 좀 더 정확하고 좀더 지속적인 시그니처 이끌어

낼 수 있는 악성코드의 깊은 특성을 파악하는 데 실패할 수도 있다.

+ 일반적으로 상세 분석(deeper analysis)은 다음과 같은 두 가지 목적을 가진다.

- 기능의 전체 범위(coverage)

첫 단계는 동적 분석을 이용해 코드의 이해 범위를 넓히는 것이다.

악성코드가 수신 받고자 하는 입력이 무엇인지를 파악하기 위해 일반적으로 새로운 입력을 제공함으로써 코드가 사용되지 않는 경로(path)를 계속적으로 실행하게 한다.

일반적으로 INetSim(http://lamalama.tistory.com/5) 이나 자체 제작한 스크립트 같은 도구를 이용해 이런 작업을 수행한다. 이 프로세스는 실제 악성코드 트래픽이나 정적 분석을 통해 도움을 받을 수 있다.

- 입력과 출력을 포함해 기능을 이해하기

정적 분석은 콘텐츠가 어디서, 그리고 어떻게 생성되는지를 알아보는 것은 물론 악성코드의 행위를 예상하고자 할 때도 사용된다. 그 후 동적 분석을 통해 정적 분석에서 예상한 기대 행위가 발생하는지를 확인할 수 있다.

• 탐지 우회

  탐지 우회는 백도어를 조작하는 사람들의 근본 목적 중 하나다. 탐지되면 시스템에 대한 접근 권한을 잃을 뿐 아니라 향후 감염시킨 모든 시스템에 대한 접근 세션이 차단될 우려가 있다. 악성코드는 여러 기법들을 이용해 눈에 띄지 않는 곳에 숨어드는 형태로 탐지를 우회하기 위해 진화를 계속하고 있다.

   

• 공격자는 기존의 프로토콜로 가장한다

  공격자가 눈에 띄지 않게 숨어드는 한 가지 방법은 가장 대중적은 통신 프로토콜을 사용하는 것으로, 공격자의 악의적인 행위가 정상적은 통신속에 묻혀버리기 때문이다.

  한때 인터넷 릴레이 챗(IRC)가 1990년대에 인기 있었을 때 공격자는 IRC 프로토콜을 매우 많이 사용했다.

  하지만 정상적인 IRC 트래픽이 줄어듦에 따라 방어자들은 IRC 트래픽을 주의 깊게 살펴보기 시작했고, 공격자들은 은닉이 쉽지 않자 오늘날 가장 많이 사용하는 HTTP, HTTPS, DNS로 프로토콜을 주로 사용하기 시작했다. 이렇게 대규모의 트래픽을 모니터링 하는 것이 매우 어렵기 때문에 이들 프로토콜은 자세하게 살펴보기 어렵다. 또한 다량의 정상 트래픽을 실수로 차단할 경우 발생하는 잠재적 위험성(가용성)으로 인해 함부로 차단하기 어려운 점을 악용한다.

   

  위처럼 근래 공격자는 정상적은 트래픽과 유사한 방법으로 대중적인 프로토콜을 사용해 숨어드는데, 공격자는 신호 발신을 위해 HTTP를 자주 사용한다. 신호(beacon)가 기본적으로 추가 명령을 위한 요청이며, 통신의 속성과 의도를 숨기기 위해 HTTPS 암호화를 사용한다. 또한 DNS는 정보의 빠르고 짧은 교환을 제공하는 의도지만, 정보를 인코디한 후 프로토콜의 원래 의도와는 다른 목적으로 DNS 필드에 삽입해 DNS를 통해

  긴 스트림의 정보를 숨기기도 한다. 공격자는 전달하고자 하는 데이터를 DNS 이름으로 만들 수 있다. 사용자의 패스워드 전달을 시도하는 악성코드는 도메인 'www.thepasswordisflapjack.maliciousdomain.com'에 대한 DNS 요청을 수행할 수 있다.

  공격자는 또한 HTTP 표준을 악용하여, 요청 메소드의 User-Agent 같은 필드에 호스트 정보를 삽입시켜 전송하거나 할 수도 있다. 이는 방어자가 요청된 URL만 검사할 경우나, 또는 HTTP 세션 본문에서 콘텐츠를 검색할 경우 의심스러운 트래픽을 발견하지 못하게 하기 위함이다.

  이처럼 악성코드 제작자들은 악성코드가 더욱 정상처럼 보이게 하기 위해 자신들의 기술을 발전시켜 왔다.

   

• 기존 인프라를 사용하는 공격자

  공격자는 악성코드를 숨기기 위해 기존의 정상적인 자원을 이용한다.

  서버의 유일한 목적이 악성코드 요청을 서비스하는 것이라면 정상적인 목적으로 사용되는 서버보다

  더 쉽게 탐지할 수 있다. 따라서 공격자는 정상적인 서버를 해킹하여 악성코드와 통신하기 위한 명령어를 삽입하는 경우가 있다. 다름은 공격자가 조작한 샘플 페이지의 첫 몇 라인이다.

  

  <그림 1-3 악성코드의 명령어가 삽입된 html 페이지 샘플>

   

  위 붉은 네모박스의 adsrv?bG9uZ3NsZWVw 구문은 악성코드가 체크를 다시 하기 전에 오랜 시간동안 대기(sleep)하도록 하는 삽입된 명령어다(bG9uZ3NsZWVw의 Base64 디코딩 값은 longsleep이다).

  악성코드는 이 명령어를 읽고 악성코드 프로세스를 잠재우기(sleep)위해 sleep명령어를 호출한다. 방어자의 입장에서 실제 웹 페이지를 위한 정상적인 요청과 동일한 요청이지만, 웹 페이지의 일부가 명령어로 해석되는 악성코드 사이의 차이점을 말하기가 극히 어렵다.

   

   

   

   

• 주변 코드의 이해의 필요성

  악성코드는 데이터 전송과 데이터 수신의 네트워크 활동이 있다. 외부로 전송되는 데이터의 분석은 일반적으로 쉽다. 악성코드가 실행될 때마다 분석에 필요한 샘플을 편리하게 생산하기 때문이다. 하지만 수신되는 데이터의 의미를 정확히 파악하려면 네트워크 발신을 생성하는 주변코드의 이해가 필요하다.

   

  예를 들기 위해 악성코드 샘플을 살펴본다.

  다음은 실제 네트워크 에서 악성코드 활동으로 가정된 부분을 트래픽 로그에서 발췌한 것이다.

  이 트래픽 로그에서 악성코드는 다음의 GET 요청을 만드는 것을 확인했다.

다음은 실제 네트워크가 아닌, 샌드박스에서 테스트한 결과이다.

인터넷 익스플로러를 이용해 웹 페이지를 브라우징한 결과,

실제 테스트 시스템의 표준 User-Agent가 다음과 같음을 확인했다.

위에서 주어진 User-Agent 문자열을 통해 이 악성코드의 User-Agent 문자열이 하드 코딩 됐음을 알 수 있다.

하지만 악성코드는 매우 일반적인 User-Agent 문자열을 사용하며, 이는 고정 User-Agent 문자열만으로

시그니처를 생성한 경우 다수의 오탐을 초래할 수 있음을 의미한다. 긍정적은 측면은 고정된 User-Agent 문자열이 효과적인 시그니처를 생성하는 데 다른 요소와 함께 결합할 수 있다는 점이다.

위에서 설명한 바와 같이 다음 단계로 악성코드를 좀 더 여러 번 실행시켜 악성코드에 대한 동적 분석을 실시한다. 이 과정에서 매번 달라지는 URI을 제외하고 GET 요청은 동일했다. 전체 URI 결과는 다음과 같다.

이 문자열의 중간에 일부 공통된 문자열(5848)이 있긴 하지만, 패턴을 쉽게 식별하긴 어렵다.

정적 분석을 통해 요청이 어떻게 생성됐는지를 정확하게 파악할 수 있다.

• 네트워킹 코드 찾기

네트워크 통신을 파악하기 위한 첫 번째 단계는 통신을 수행하기 위해 사용되는 실제적인 시스템 호출을 찾는 것이다.

가장 일반적인 하위 레벨의 함수는 윈도우 소켓(Winsock) API의 한 부분이다. 이 API를 사용하는 악성코드는 일반적으로 WSAStartup, getaddrinfo, socket, connect, send, recv, WSAGetLastError 같은 함수를 사용한다. 악성코드가 윈도우 인터넷(WinINet)을 호출하는 상위 레벨의 API를 사용할 수도 있다.

WinINet API를 사용하는 악성코드는 일반적으로 InternetOpen, InternetConnect, InternetOpenURL,

HTTPOpenRequest, HTTPQueryInfo, HTTPSendRequest, InternetReadFile, InternetWriteFile 같은 함수를 사용한다.

이 상위 레벨 API는 일반 브라우징에 사용되는 동일한 API이기 때문에 악성코드가 좀 더 효율적으로 정상 트래픽에 숨을 수 있게 한다. 네트워크에 사용할 수 있는 다른 상위 레벨 API는 COM(Component Object Model)인터페이스다. URLDownloadToFile 같은 함수를 통해 COM을 간접 사용하는 것은 매우 일반적이지만, COM의 직접 사용은 아직 찾아보기 드물다. COM을 직접적으로 사용하는 악성코드는 일반적으로 ConInitialize, CoCreateInstance, Navigate 같은 함수를 사용한다.

예를 들어 브라우저를 생성하고 사용하기 위한 COM의 직접 사용은 의도한 바와 같이 브라우저가 실제적으로

사용하는 것이기 때문에 악성코드가 정상 트래픽에 숨어들 수 있게 하며, 악성코드의 활동과 네트워크 트래픽

연결이 효율적으로 발견되지 않게 한다. 다음 표는 네트워킹 기능을 구현하기 위해 악성코드가 생성할 수 있는

API 호출의 개요이다.

<표 1-4 악성코드가 생성할 수 있는 API 호출의 개요>

다시 위의 샘플 악성코드로 돌아가서 악성코드의 임포트 함수는 InternetOpen과 HTTPOpenRequest를 포함하며,

이는 악성코드가 WinINet API를 사용함을 의미한다. HTTPOpenRequest의 파라미터를 조사할 때 악성코드에

하드 코딩된 User-Agent문자열을 볼 수 있다. 또한 HTTPOpenRequst는 수용 가능한 파일 유형을 지정하는

파라미터를 가지며, 이 파라미터 또한 하드 코딩된 콘텐츠를 가짐을 알 수 있다.

HTTPOpenRequst의 다른 파라미터는 URI 경로로, URI의 콘텐츠는 GetTickCount, Random, gethostbyname의

호출에서 생성됐음을 알 수 있다.

• 네트워크 콘텐츠 출처

시그니처 생성에서 가장 의미 있는 요소는 악성코드의 하드 코딩된 데이터다.

악성 코드가 전송한 네트워크 트래픽은 근본 출처(original source)의 제한된 집합으로 구성된다.

효과적인 시그니처의 생성은 네트워크 콘텐츠의 개별적인 근원에 대한 파악이 중요하다.

다음은 콘텐츠의 기본 출처의 예이다.

- 랜덤 데이터(예를 들어 의사난수 pseudorandom 값을 생성하는 함수의 호출을 통해 반환 받은 데이터)

- 표준 네트워킹 라이브러리의 데이터 (예를 들어 HTTPSendRequest 호출을 통해 생성한 GET)

- 악성코드에 하드 코딩된 데이터(예를 들어 하드 코딩된 User-Agent 문자열)

- 호스트와 호스트의 설정에 대한 데이터(예를 들어 호스트명, 시스템 시간의 현재 시간, CPU 스피드)

- 원격 서버나 파일 시스템 같은 다른 출처로부터 전달받은 데이터(예를 들어 암호화를 위한 전달되는 넌스otp,

로컬파일, 그리고 키 스트로크 로거로 캡처한 키 스트로크)

악성코드가 네트워크를 사용하기 전까지 데이터에 적용되는 다양한 레벨의 인코딩이 존재할 수 있지만,

이 글에서 강조하고자 기본적인 내용은 악성코드 탐지 시그니처 생성이다.

• 하드 코딩된 데이터와 임시 데이터

  윈속(Winsock) 같은 하위 레벨의 네트워킹 API를 사용하는 악성코드는 COM 인터페이스 같은 상위 레벨의 네트워킹 API를 사용하는 악성코드에 비해 정상 트래픽을 모방하기 위해 수작업으로 생성하는 콘텐츠가 더 많이 필요하다. 수작업이 더 필요한 콘텐츠란 하드 코딩된 데이터를 의미하는 것으로, 시그니처 제작에 사용할 수 있는 실수를 악성코드 제작자가 할 가능성을 증가 시킨다.

  이런 실수는 Mozilla에 대한 철자 실수(Mozila)와 같이 명확하거나, 특정 공백을 빠뜨리는 것과 같이 미묘할 수도 있다.

  샘플 악성코드에서는 하드 코딩된 Accept 헤더 문자열에 실수가 존재한다. 문자열은 정상적인 */* 가 아닌

  * / *와 같이 하드 코딩되어 있다. 이 경우는 시그니처 생성에 주요한 포인트가 되기에는 무리가 있으나,

  충분히 참고하거나 다른 콘텐츠와 함께 사용 할만한 가치가 있다.

  샘플 악성코드에서 생성된 URI가 다음과 같은 형식을 가짐을 떠올려보자.

  /14856205865810997108584848485355525551

   

  URI 생성 함수는 getTickCount, Random, gethostbyname을 호출한 후 문자열을 함께 합칠 때 악성코드는 콜론(:) 문자를 사용한다. 하드 코딩된 Accept 문자열과 하드 코딩된 콜론 문자는 시그니처에 포함시키기에 적합하다. Random을 호출한 결과는 어떤 랜덤 값이 반환이 되더라도 시그니처에 반영돼야 한다. GetTickCount와 gethostbyname 호출의 결과는 그 결과가 얼마나 고정적인지에 기반을 두고 포함 여부를 판단해야 한다.

   

  샘플 악성코드의 콘텐츠 생성 코드를 디버깅하는 동안 해당 함수는 문자열을 생성한 후 인코딩 함수로 전달한다. 전달되기 전에 문자열의 포맷은 다음과 같다.

  <랜덤한 4 바이트>:<호스트명의 첫 3 바이트>:<16진수로 표현된 GetTickCount의 시간>

   

  각 바이트를 얻은 후 ASCII 10진수 형태(예를들어 문자 a는 97이 된다)로 변환하는 단순한 인코딩 함수란 사실을 알 수 있다. 이제 동적 분석을 통해 URI의 의미를 알아내기 힘든 이유가 명확해진다. 무작위 성, 호스트 속성, 시간, 그리고 문자에 따라 길이가 변화하는 인코딩 함수를 사용하기 때문이다. 따라서 이 정보와 정적 분석을 통해 얻을 정보를 바탕으로, URI에 대한 효과적인 정규 표현 식을 쉽게 개발할 수 있다.

   

• 인코딩 단계 파악과 활용

  인코딩 단계를 정확히 파악하지 않는다면, 고정적이거나, 하드 코딩된 콘텐츠라고 하더라도 악성코드가 발신하는 트래픽 콘텐츠의 의미를 정확히 파악하기는 힘들다. 예를 들어 예제 악성코드에서는 GetTickCount 명령 결과과 두 단계의 인코딩을 거치는 것을 확인했다. 첫 단계로 바이너리 DWORD값을 8바이트 16진수 표현으로 변경한 후 각 바이트를 10진수의 ASCII값으로 변환했다. 따라서 10진수의 ASCII 콘텐츠만 가지고는 악성코드가 발신하는 데이터의 의미를 유추하기란 쉽지 않다. 인코딩 단계를 명확히 파악한다면 다음과 같은 정규 표현식으로 시그니처를 생성할 수 있다.

다음 표는 변환 과정을 설명하기 위해

위 예제의 일부를 사용해 파악된 데이터 원본과 최종 정규식 사이의 일치 성을 보여준다.

<표 1-5 발신 데이터 원본과 정규식의 일치성>

각 요소들이 정규 표현식에 어떻게 매칭되는지 설명하면 다음과 같다.

• 3개의 다른 요소를 구분 짓는 2개의 고정된 콜론은 표현에 중요한 역할을 하며, 콜론의 바이트 값은 위 표의 2번째와 4번째 열에서 확인 할 수 있다. 각 콜론은 ASCII 10진수 표현으로 58이다. 콜론은 시그니처 제작에 매우 중요한 원시 고정 데이터다.
• 앞쪽에 있는 랜덤 4바이트는 최종적으로 10진수 0에서 255로 변환될 수 있다.

정규 표현식 ([1-9]|1[0-9]|2[0-5]){0,1}[0-9])는 0에서 259까지의 범위를 나타내며, {4}는 해당 패턴이 4번

존재함을 나타낸다. 대괄호([])는 찾는값을 포함하며, 중괄호({})는 앞 심볼의 개수를 나타내는 나타낸다.

• PCRE에서 파이프 심볼(|)은 논리적 OR을 표현하기 때문에 괄호 안에 있는 조건중 하나는 일치하는 표현식을 위해 사용할 수 있다.
• 또한 이 경우에는 이전 정규 표현식보다 더 복잡하지 않게 하기 위해 살짝 허용 값을 259로 확장했다.

<그림 1-4 정규식 도형화:

http://regexper.com/#((%5B1-9%5D%7C1%5B0-9%5D%7C2%5B0-5%5D)%7B0%2C1%7D%5B0-9%5D)%7B4%7D%0A >

• 처리과정이나 인코딩 과정에 대한 지식은 하드 코딩되거나 고정된 요소를 파악하는 것 이상을 제공한다.
• 인코딩은 악성코드가 전송하는 특정 문자 집합과 필드의 길이를 제한할 수 있기 때문에 시그니처를 생성하는데 유용하게 사용된다.
• 예를 들어 첫 콘텐츠가 랜덤이지만 특정 길이를 알고 있으며, 문자 집합과 최종 인코딩 레이어의 전체 길이에 제한이 있음을 알 수 있다
• 58사이에 있는 중간 값 [0-9]{6,9}는 ASCII 10진수로 변환된 호스트명의 첫 세 문자다. 이 PCRE 표현은 6에서 9개의 10진수 문자열과 일치한다. (0= A=65, a=97처럼 10진법이 시작한다.)

• 호스트명은 한자리 ASCII 값(0-9)을 포함하지 않으며, 프린트할 수 있는 문자도 아니기 때문에 최소 묶음을 3이 아닌 6(10진수 값의 길이가 2인 문자 3개)으로 설정했다.

  이처럼 하드 코딩된 데이터를 포함하는 것만큼이나 시그니처에 임시요소를 포함시키지 않는 것도

중요 하다. 동적 분석에 대한 앞에서 살펴봤듯이 감염된 시스템의 호스트명은 해당 호스트에서는 일관돼

보일 수 있지만, 해당 요소를 사용하는 시그니처는 다른 감염된 호스트에 대해서는 유효하지 않다.

• 정규 표현식 세번째 부분 (4[89]|5[0-7]|9[789]|10[012]){8} 은 GetTickCount 호출을 통해 수집하는 시스템의 가동시간(uptime)을 나타내는 문자의 가능 값을 포괄한다. GetTickCount 명령어의 결과는 DWORD이며, 16진수로 변환된 후 ASCII 10진수로 표현된다. 그러므로 GetTickCount 명령의 값이 268404824(약 3일간의 uptime)라면 16진수 표현으로 0x0fff8858이 된다. 따라서 ASCII 10진수로 표현되는 숫자는 48 ~ 57이며, 소문자(a에서 f까지 제한)는 ASCII 10진수 97에서 102로 표현된다. 이 정규 표현식에서 알 수 있듯이 8은 16진수 문자의 개수와 일치하며, 논리적 OR을 사용하여 필요한 숫자의 범위를 포괄하도록 한다.

<그림 1-5 정규식 도형화:

http://regexper.com/#(4%5B89%5D%7C5%5B0-7%5D%7C9%5B789%5D%7C10%5B012%5D)%7B8%7D>

• 이처럼 악성코드가 발신하는 네트워크 데이터가 처음에는 무작위 하게 나타나 사용할 수 없는 것처럼 보일 수 있지만, 데이터의 일부는 사실적으로 예측이 가능한 경우가 많다.
• 시간은 이런 예 중 하나다. 상위(high-order) 비트는 상대적으로 고정되며, 때에 따라서는 시그니처로 쓸 수 있을 만큼 충분히 안정적인 데이터의 출처가 될 수 있다.
• IDS 장비의 성능(performance)과 정확성(accuracy) 사이에는 트레이드오프(trade-off))가 존재한다.

  이번 예에서 정규 표현식은 IDS의 성능 부하를 고려한 정책 테스트는 아니다.

  성능과 정확성을 향상시키기 위해서는 유일한 고정 콘텐츠 문자열이 콘텐츠 기반 검색을 크게 개선 시킬 수 있지만, 이번 예제의 경우 유일한 고정 콘텐츠인 58이 짧기 때문에 쉽지 않았다.

• 위 예에서는 정확성과 범위에 예를 들기 위해 PCRE를 강조 하였다. 악성코드에서 발생시키는 특정 문자열(User-Agent, Aceept, Referer 등)이나, PCRE를 조금 러프하게 잡고, 제한된 바이트에 대해서만 검색하거나, 검색할 범위를 지정하여 시그니처를 생성 할 수도 있다.

• 공격자 관점의 이해

탐지 시그니처 전략을 설계할 때 공격자의 관점을 이해하려는 노력이 필요하다.

그들의 의도는 정상 트래픽에 섞여 들어 탐지되지 않고 침해 시스템에 대한 주도권을 계속 유지하는 것이다.

여느 다른 소프트웨어 개발자들처럼 현재 상태를 유지하고 변화하는 시스템의 호환성을 유지하기 위해

공격자도 악성코드를 업데이트하기 위해 노력한다. 당연히 방어자의 입장에서도 끊임없는 노력이 필요하다.

해당 악성코드의 다중 시그니처를 생성함으로써 공격자가 코드의 일부분을 수정하여 배포하더라도 여전히 악성코드를 성공적으로 탐지할 수 있다.

다음은 공격자의 약점을 고려해 활용할 수 있는 세가지 규칙이다.

• 양측 엔드포인트(end point)의 일부인 프로토콜 요소(element)에 집중하라.
• 클라이언트의 코드나 서버의 코드를 개별적으로 변경하는 것은 양측을 함께 변경하는 것보다 쉽다.

  클라이언트와 서버 측 모두에서 사용하는 코드가 사용자는 프로토콜 요소를 찾아 이 요소들을 기반으로 시그니처를 만들자. 공격자가 이런 종류의 시그니처를 무력화시키려면 다수의 추가적인 작업을 해야 한다.

핵심 요소로 알려진 프로토콜 요소에 초점을 맞춰라.

종종 프로토콜의 하드코딩 된 일부 컴포넌트가 핵심 요소로 사용될 수 있다. 예를 들어 공격자는 특정

User-Agent 문자열을 인증 키로 사용하여 탐지하는 경우, 공격자가 이런 시그니처를 우회하려면 양측 엔드

포인트의 코드를 변경해야 한다.

알려진 탐지 시그니처는 미탐을 초래할 수 있다.

다른 방어자가 공격자에 대해 충분히 유효한 시그니처를 생성하여 공개했다면, 공격자는 해당 시그니처를

우회하기 위해 악성코드를 수정할 것이다. 따라서 알려진 동일한 시그니처에 의존한다면 공격자가 악성코드를

수정할 경우 우리의 시그니처도 무력하게 만들 수 있다.

따라서 우리는 다른 방어자가 초점을 맞출 가능성이 낮은 악의적인 행위 특징을 파악하게 노력해야 한다.

악성코드를 주의 깊게 관찰해 얻은 지식은 좀더 강력한 시그니처를 개발하는 데 도움을 줄 수 있다.

또한 이 시그니처는 외부에 공개하는 순간 사실상 무력화 되는 것임을 유의하여야 한다.

일반적으로 IDS제품을 구입하더라도 탐지 시그니처는 해당 제품 기업의 기업 비밀로 공개되지 않는다.

03. 정리

1. 학습 정리

본 14장 학습문서에서는 악성코드가 네트워크를 사용해 명령과 통제를 하는 방법을 설명했다.

또한 악성코드가 자신의 활동을 일반 네트워크 트래픽 처럼 가장하기 위해 사용하는 일부 기법도 다뤘다. 악성코드 분석은 시그니처 생성과정에서 통찰력을 제공함으로써 네트워크 방어의 효율성을 개선시킬 수 있다.

기존 트래픽 캡처의 표면적 분석이나 샌드박스 기반의 악성코드 분석에 비해 상세 악성코드 분석에 기반을 둔 네트워크 시그니처가 가진 여러 이점을 설명했다.

악성코드 분석에 기반을 둔 시그니처는 좀 더 정확하며, 오탐을 줄이기 위해 필요한 시도와 에러를 줄일 수 있다. 본 학습에서는 기본적인 악성코드 분석의 최종 목표(악성코드를 탐지할 수 있는 효율적인 대응 방안의 개발)가 무엇인지를 설명하였다.

하지만, 일부 악성코드 제작자는 효과적인 분석을 방해하는 고도화된 대응 방안을 갖고 있다.

우리는 본 학습을 통해 악성코드를 탐지하는 효과적인 네트워크 기반 대응 방안을 학습하였고,

이 학습을 기초로 좀더 고도화되고, 좀더 효율적인 탐지 방안을 연구해야 할 필요가 있다.

이후의 학습에서는 악성코드 제작자가 분석을 방해하기 위해 사용하는 기법과 악성코드를 완벽하게 분해하고

이해하기 위해 어떤 단계를 취해야 하는지에 대해 설명하도록 하겠다.

05. 참고문헌

[1] Practical Malware Analysis Capter#14

[2] REGEXPER: http://regexper.com

[3] nextree: http://www.nextree.co.kr/p4327/

[4] KT한: http://kthan.tistory.com

WMIC를 이용한 원격관리 및 탐지 시그니처 생성

1.  

   WMI(Windows Management Instrumentation)란?

   WMI는 엔터프라이즈 네트워크에서 관리 정보를 액세스하고 공유하는 표준을 만들기 위하여 Microsoft에서 구현한 것이다.

    

   WMIC(Windows Management Instrumentation Command-line)란?

   WMI에 대한 간단한 명령 줄 인터페이스를 제공하므로 WMI를 사용하여 Window를 실행하는 컴퓨터를 관리할 수 있다. Shell 및 유틸리티 명령과 상호 작용하여 한 컴퓨터부터 다수의 컴퓨터까지 원격으로 관리할 수 있으며, 관리 스크립팅 을 통하여 자동화까지 가능하다.

   WMIC는 기본적으로Window XP 이상에서만 로드 된다.

    

   WMIC를 이용한 시스템 관리

   WMIC의 기능을 살펴보면, Cmd.exe 커맨드에서 볼 수 없었던 상세한 기능들을 사용할 수 있다.

   기능은 사용자계정관리, 시스템관리, 프로세스관리, 이벤트로그관리, 서비스관리, 네트워크관리 등등 수 많은 기능이 있다.

    

   대표적인 기능은 아래와 같다. (참고: http://211.56.237.23/ex2comp/9037)

   

   위 캡처 이미지와 같이 "wmic startup startup list brief" 를 입력하면, 시스템의 시작프로그램 목록이 간략히(brief)나열 된다.

    

    

   

   또한, WMIC의 OUTPUT을 htm, html, txt, csv 등으로 저장하여 볼 수도 있다.

위 캡처 이미지와 같이 htm으로 출력하면 보면 커맨드 라인보다 깔끔히 볼 수 있다.

WMIC를 이용한 원격 시스템 관리

WMIC를 이용하여 원격으로 시스템에 접근 및 관리할 수 있다.

단, 해당 계정의 HOST명 또는 IP주소를 알아야 하고, User명과 Password 도 아는 상황에서 원격 시스템관리가 진행 가능하다.

"Wimc /node:[HOST IP] /user:[계정명] /passwoard:[패스워드] bios list /format" 명령어 입력 시,

로컬 계정에서 명령어를 입력하는 결과와 같이, 원격 호스트를 관리 할 수 있다.

Wimc /node:[HOST IP] /user:[계정명] /passwoard:[패스워드] process call create "cmd.exe /c ipconfig >>

\\172.30.1.10\share\result.txt" 입력시, cmd.exe 프로세스를 생성과 동시에 ipconfig를 실행하고, 172.30.1.10의 공유폴더

\Share\result.txt로 결과를 저장한다.

(참고: http://blog.commandlinekungfu.com/2009/05/episode-31-remote-command-execution.html)

WMIC 관련 탐지 시그니처 생성

WMIC 커맨드는 일반 유저들은 잘 사용하지 않고, NT계열의 서버 관리자들이 주로 사용하는 원격/로컬 관리 도구이다.

따라서, 일반적으로 원격으로 관리하지 않는다면, 해당 서비스는 차단/탐지가 필요하다. 또한, 원격제어에 있어 해당 시스템의

계정과/비밀번호를 알고 있는 상태에서 가능하다. 만약 다수의 계정과 비밀번호를 가지고 있다면, 동시에 다수컴퓨터를 원격으로 관리 할

수 있다. 다시 말해서, 동시에 다수의 시스템에게 명령을 하달 할 수 있다는 것은, 용도에 따라서는 악의적인 DDoS 공격에 사용될 수

있다.

해당 패킷은 A -> B 로 WMIC 원격, B -> A 로 WMIC 원격을 수행한 패킷중 SYN패킷만(접속시도) 필터링 한 패킷들이다.

공통점은 Port와 WindowsSize 이다. 이미 연결이 시작된 후 가 아닌, 연결을 시도하는 패킷을 추출하는 Rule은 다음과 같다.

alert tcp any any -> any 135 (msg: "Tcp_Syn_WMIC_winSize_8192_Port:135;Connection"; flags: S; window:8192;)

alert tcp any any -> any 1328 (msg: "Tcp_Syn_WMIC_winSize_8192_Port:1328;Connection"; flags: S; window:8192;)

PR_Snort for windows & HSC

01. 개요

1. Snort란 무엇 인가부터, Windows 기반 Snort 환경 구축에 대해 알아본다.

2. Snort 옵션 별 Rule 설정 방법 및 탐지에 대해 알아본다.

3. Snort Rule Content의 PCRE를 적용하여, 탐지 Rule 고도화 방안에 대해 알아본다.

02. 본론

1. Snort for windows

• Snort란 무엇인가?

  Snort는 "sniffer and more"라는 말에서 유래되었는데,

  처음 공개되었을 때는 코드도 얼마 되지 않는 단순한 Packet Sniffer 프로그램이었다.

  그러나 이후 현재의 IDS와 같이 rule을 이용한 분석 기능이 추가되고,

  보완과 향상을 통해 지금과 같이 다양한 기능과 탁월한 성능을 갖춘 프로그램이 되었다.

   

  현재 많은 침입탐지시스템 솔루션 제품에서 Snort 룰 기반으로 정책을 설계하고,

  전 세계에서 IDS 룰 이라 함은 Snort Rule을 비 공식적으로 통용화되고 있는 실정이다.

  

Snort는 공식 홈페이지인 http://www.snort.org 를 통해 지속적인 업그레이드를 제공하고 있으며,

Snort 홈페이지에서 Source를 다운 받아 IDS를 설치할 수 있고, Rule을 다운받을 수 도 있다.

• Snort는 일종의 침입탐지시스템(IDS:Intrusion Detection System)으로

  + 실시간 트래픽 분석, 프로토콜 분석, 내용검색/매칭, 침입탐지 Rule에 의거하여 오버플로우,

  포트스캔, CGI공격, OS확인 시도, DoS등의 다양한 공격과 스캔을 탐지할 수 있다.

  + 침입탐지 Rule은 보안 커뮤니티를 통해 지속적으로 업데이트되고 또한 사용자가 직접

  Rule을 작성하여 추가할 수 있도록 설계되어 최신공격에 대한 적응에 빨리 대처할 수 있다.

• Snort의 개발자인 Marty Roesch의 말에 의하면

  "Snort는 실시간 트래픽 분석과 IP 네트워크 상에서 패킷 로깅이 가능한 가벼운(lightweight) 네트워크 침입탐지시스템" 이라고 한다.

  1-1. Snort for windows 구축

• 다음은 Windows기반 에서 Snort를 구축하는 방법에 대해서 알아본다.

  

▲[그림 1-1] 구축환경 (VMware)

1. Mysql-essential 설치

Mysql-essential Installer 5.1.38 for windows (32bit): https://drive.google.com/file/d/0B6N5okuxlzbpT05UQ3pITEcyNUk/view?usp=sharing

다음 그림 순서에 따라서, 설치를 진행한다.

▲[그림 1-2] Mysql-essential 설치과정 (Default는 다음으로 넘김)

▲[그림 1-3] Mysql-essential 설치과정

▲[그림 1-4] Mysql-essential 설치과정

▲[그림 1-5] Mysql-essential 설치과정

▲[그림 1-6] Mysql-essential 설치과정

▲[그림 1-7] Mysql-essential 설치과정

▲[그림 1-8] Mysql-essential 설치과정

▲[그림 1-9] Mysql-essential 설치과정 (계정: root / 패스워드 입력)

▲[그림 1-10] Mysql-essential 설치과정

1. Snort & HSC Schema Download

• Mysql Schema: https://drive.google.com/file/d/0B6N5okuxlzbpYjJuUFY1UVBaWUU/view?usp=sharing

  HSC DB Dump: https://drive.google.com/file/d/0B6N5okuxlzbpd0ZHdTBqYVZ6RlU/view?usp=sharing

  위 두 파일을 Mysql이 설치된 경로(C:\Program Files\MySQL\MySQL Server 5.5\bin)에 저장한다.

   

   

1. Snort Database 및 Schema 생성

   c:\Program Files\MySQL\MySQL Server 5.1\bin>mysqladmin -u root -p create snortdb

   Enter password: Mysql 설치시 입력했던 패스워드 입력

   

▲[그림 1-11] Snortdb database 생성

c:\Program Files\MySQL\MySQL Server 5.1\bin> mysql -D snortdb -u root -p < create_mysql

Enter password: Mysql 설치시 입력했던 패스워드 입력

▲[그림 1-12] Snortdb Schema 생성

1. HSC Database 및 Schema 생성

   C c:\Program Files\MySQL\MySQL Server 5.1\bin>mysqladmin -u root -p create aw_hsc

   Enter password: Mysql 설치시 입력했던 패스워드 입력

   

▲[그림 1-13] HSC database 생성

c:\Program Files\MySQL\MySQL Server 5.1\bin> mysql -u root -p aw_hsc < dump_aw_hsc.sql

Enter password: Mysql 설치시 입력했던 패스워드 입력

▲[그림 1-14] HSC DB Dump 쓰기

C:\Program Files\MySQL\MySQL Server 5.5\bin> mysql -u root -p

Enter password: Mysql 설치시 입력했던 패스워드 입력

▲[그림 1-15] Mysql Login 화면

mysql> show databases; (데이터 베이스 확인)

mysql> use aw_hsc; (데이터 베이스 진입)

mysql> show tables; (데이터 베이스 테이블 확인)

▲[그림 1-16] aw_hsc 와 snortdb가 정상적으로 생성된 화면

1. WinPcap 설치 (기본설치)

   WinPcap Download: http://www.winpcap.org/install/bin/WinPcap_4_1_3.exe

    

2. Snort(2.8.4.1 ver) 설치

   Snort Download: https://drive.google.com/file/d/0B6N5okuxlzbpUzJVbllMQjA1VkE/view?usp=sharing

    

• 설치 후 C:\Snort\etc\snort.conf 파일을 열어 다음과 같이 수정 한다.

1. 수정 전: dynamicpreprocessor directory /usr/local/lib/snort_dynamicpreprocessor/

수정 후: dynamicpreprocessor directory c:\snort\lib\snort_dynamicpreprocessor

1. 수정 전: dynamicengine /usr/local/lib/snort_dynamicengine/libsf_engine.so

   수정 후: dynamicengine c:\snort\lib\snort_dynamicengine\sf_engine.dll  

    

2. 수정 전: var RULE_PATH ../rules

   수정 후: var RULE_PATH c:\snort\rules

    

3. 수정 전: var PREPROC_RULE_PATH ../preproc_rules

   수정 후: var PREPROC_RULE_PATH c:\snort\preproc_rules

    

4. 수정 전: include classification.config

   수정 후: include c:\snort\etc\classification.config

    

5. 삽입: output alert_fast: alert.ids  

    

6. 삽입:

   output database: log, mysql, user=root password=DB 패스워드 dbname=snortdb host=127.0.0.1 port=3306 sensor_name=snortsensor

   output database: alert, mysql, user=root password=DB 패스워드 dbname=snortdb host=127.0.0.1 port=3306 sensor_name=snortsensor

   (설치한 Mysql의 계정과, 패스워드를 기입하여 삽입한다.)

    

7. 수정 전: include $RULE_PATH/local.rules

   수정 후: #include $RULE_PATH/local.rules (해당 룰 아래의 모든 rules 에 대해 "#"주석 처리 한다.)

    

8. 삽입: include $RULE_PATH\user.rules

   

▲[그림 1-17] Snort.conf의 user.rules 설정 화면

1. 생성: 1개의 사용자 룰 파일을 C:\Snort\rules\ user.rules 생성

User.rules 내용: alert icmp any any -> any any (msg:"Detected ICMP Protocol"; sid:0; rev:1;)

1. 실행 테스트: 1개의 사용자 룰 파일을 C:\Snort\rules\ user.rules 에 생성

   C:\Snort\bin> Snort -W (Sniffing 할 Network Interface 번호 확인)

   C:\Snort\bin> snort -v -c c:\snort\etc\snort.conf -l c:\snort\log -i 2 -k none

   (-k none옵션은 checksum 검사를 하지 않기 위함.)

   

▲[그림 1-18] Snort Sniffing 동작화면

1. HSC(Honeynet Security Console) v.2.6.0.4 설치

   HSC Download: https://drive.google.com/file/d/0B6N5okuxlzbpUnpvWjF5czJ5eVE/view?usp=sharing

    

   

▲[그림 1-19] HSC 로그인 화면 (DB 계정정보를 입력 후 로그인)

HSC(Honeynet Security Console) 는 Snort의 3rd Party 솔루션으로써,

Snort 기반으로 탐지되는 이벤트를 GUI로 확인 할 수 있는 프로그램이다.

이 외에도 3rd Party 솔루션은 다양하며, https://snort.org/downloads 에서 확인 할 수 있다

▲[그림 1-20] Snort 3^rd Party 솔루션들

Windows7기반 BASE(IDS)(참고): http://redkreuz.tistory.com/156

1. IDS 탐지 테스트

   Snort Start: C:\Snort\bin>snort -v -c c:\snort\etc\snort.conf -l c:\snort\log -i 2 -k none

   발생 Event: 실행창 -> cmd.exe /s /k Ping 8.8.8.8 /t

   탐지 Rules: alert icmp any any -> any any (msg:"Detected ICMP Protocol"; priority:0; sid:0; rev:1; )

▲[그림 1-21] 정상적으로 HSC에서 보여지는 Event 화면

위와 같이 정상적으로 Windows에 Snort와 GUI로 탐지된 결과를 확인할 수 있는 HSC를 설치하여,

IDS 구축을 완료 하였다.

해당 문서는 따라 하기만 하면 쉽게 설치하고 테스트 할 수 있도록 초점을 맞추었기 때문에,

그대로 따라 하면 문제없이 설치 할 수 있을 것이라 판단됩니다.

잘 되지 않거나 할 때에는 질문 남겨 주세요. ^^

CryptoPHP(CMS Backdoor)

01. 개요

1. ISSUE 정보

• CryptoPHP Backdoor In Plugins and Themes

   

• 최근 각종 정보보안 포럼, 뉴스 등에 기재된 기사에 따르면, 2만 3,000개 이상의 웹서버가 CryptoPHP라는 이름의 Backdoor에 감염되었다고 보도 되었다. Fox-IT Security의 위협보고서에 따르면, 최근 2014년 11월 12일 WordPress, Joomla, Drupal 과 같은 콘텐츠 관리 시스템(CMS)을 대상으로 하는 Backdoor로써 인기 콘텐츠 관리시스템(CMS)용 테마 및 플러그인 해적판에 내장돼 확산된 것으로 관측된다.
• 해당 Backdoor는 CMS의 Theme나 Plug-in에 심어지고 적용할 시 동작한다. 이때 활용되는 멀웨어의 이름이 CryptoPHP(CryptoPHP)라고 한다. CryptoPHP는 처음 2014년 9월 25일 처음 발견되었으며, 당시 버전은 0.1 이었고, 현재 발견된 버전은 1.0a로 업그레이드 된 것을 확인 할 수 있었다.
• 한국에서는 그리 사용자가 많지는 않은 서비스라 다행이지만 외국에서는 이들의 플랫폼을 활용한 사이트들이 굉장히 많아 여파가 큰 이슈로 확인되었다. 지역별 감염 순위는 미국(8,657 IP 어드레스), 독일(2,877), 프랑스(1,231), 네덜란드(1,008), 터키(749) 순이었다

   

• CryptoPHP는 일종의 악성 스크립트로, 공격자가 원격에서 악성 코드를 실행할 수 있게 한다. 또 감염 웹 서버 상의 웹사이트에 악성 콘텐츠를 노출할 수 있게 해준다.
• 이번 Backdoor가 주로 사용된 용도가 있다. 블랙 햇 검색 엔진 최적화(BlackHat SEO)가 그것이다. 악성 키워드와 페이지를 감염 사이트에 주입함으로써 감염 사이트의 검색 엔진 순위를 가로채 악성 콘텐츠를 검색 결과 상위에 올려놓는 용도였다.
• (참고 1: http://www.blackhatworld.com/blackhat-seo/f1-black-hat-seo/ )
• (참고 2: http://www.infosecurity-magazine.com/news/cryptophp-offers-free-cms-plugins/ )

   

  CryptoPHP가 다른 웹사이트 백도어와 차별화되는 특징은 취약점을 통해 설치된 것이 아니라는 사실이다. 공격자들은 줌라(Joomla), 워드프레스( WordPress), 드루팔(Drupal)용 플러그인 및 테마 상용 제품 해적판을 만들고 웹서버 관리자들이 이를 다운로드 하도록 기다렸다. 해적판이 설치되면 여기에 내장된 CryptoPHP가 동작을 개시했다.

  CryptoPHP에 감염된 웹 서버들은 봇넷으로도 기능했다. 공격자들이 운영하는 통제 서버과 암호화된 소통 채널을 통해 연결됐다.

   

  Fox-IT Security 측은 지난 주 대응 방안을 다룬 보고서를 발간함에 따라 공격자들이 감지를 피하기 위해 백도어 신버전을 배포했다고 전했다. 회사는 웹마스터들이 서버와 사이트를 스캔해 CryptoPHP 감염을 확인할 수 있는 파이썬 스크립트 2종을 깃허브에 게재한 상태다.

   

  

  (감염여부 스캔 스크립트 배포 깃 허브 참고: https://github.com/fox-it/cryptophp/tree/master/scripts )

   

   

    

   

  2. ISSUE 관련 위험성

  

• 해당 ISSUE의 위험성은 대중적인 CMS의 신규 취약점이나, 새로운 해킹기술을 사용하여 침투 및 악성코드를 배포하는 방식이 아닌,

  CMS의 테마, 플러그인 등의 해적판(유료 테마, 플러그인 등을 불법적으로 무료 또는 저렴한 금액으로 배포하는 버전)을 제공하는 사이트를 구축하고 테마나, 플러그인에 악성코드를 심고, 해당 플랫폼 사용자로 하여금 본인 스스로 해적판을 다운받게 하는 사람의 "공짜" 심리를 악용, 요혹하는 방법이다. 따라서, 그 피해 규모를 모두 파악할 순 없지만 피해자의 수가 2만 3,000개의 이상의 웹서버 라는 걸 예측 한다면 감염된 웹 서버를 통해 DDoS공격이나, 2차 3차 침투 공격 등등 위험성의 지수는 기하 급수적으로 늘 것으로 관측된다.

   

   

  3. ISSUE Report: Fox-IT Security

• 해당 ISSUE를 처음 발견하고 보고한 네덜란드의 보안기업 Fox-IT Security 보고서의 내용에 따르면 다음과 같다.

  

  (CryptoPHP Whitepaper: https://foxitsecurity.files.wordpress.com/2014/11/cryptophp-whitepaper-foxsrt-v4.pdf )

   

• Fox-IT Security 의 연구원이 몇 달전 의심스러운 트래픽을 생성하는 고객의 웹 서버를 발견했다.

  CMS를 호스팅하는 웹서버가 외부 서버로 HTTP POST 요청을 수행하기 시작했다.

   

  해당 웹서버 로그를 확인한 결과 다음과 같은 로그를 확인 할 수 있었다.

  

   

   

• 해당 웹서버를 좀더 자세히 관찰하기 위하여 네트워크 트래픽을 확인한 결과 의심스러운 트래픽을 확인 할 수 있었다.

  

  위 패킷에서 의심스러웠던 점은 다음과 같다.

1. No referrer
2. No User Agent
3. HTTP POST is toward a BIZ domain

웹 서버는 때때로 외부 서버에 POST 요청을 수행하지만, 이러한 요청은 정상적인 HTTP 헤더를 결여해서 보내는 것은 드문 일이었다.

더 흥미로운 점은 패킷 스트림을 확인해 보니, 암호화 된 데이터를 포함하는 모양의 POST 데이터 였다.

Fox-IT Security 연구원은 이런 의심스러운 트래픽이 왜 발생하는지에 대한 의문점을 가지고, 현재 발생하는 이전 트래픽 에서

어떠한 실마리를 찾으려 했지만, 특이사항은 없었던 것으로 확인되었다.

일반적으로 이런식의 의심스러운 트래픽을 발생시키는 웹서버에는 특이 취약점이나, 해킹의 흔적이 있기 마련인데, 이번 Case는 달랐다.

해당 웹서버 추가 검사를 통해서 HTTP POST 요청이 발생하기 전에, 관리자가 Joomla Instance의 플러그인을 정상적으로 설치한 것을 확인하였다. 해당 설치과정 중 로그인은 합법적이었고, 도난된 자격증명도 아니었음을 확인했다. 다시 말해 정상적인 플러그인 설치다.

네트워크 데이터에서 플러그인 파일을 추출 한 뒤, 요청 된 HTTP POST와의 관계를 알고자 분석하였다.

분석결과 관리자가 설치한 해당 플러그인 에서 Backdoor가 확인되었다.

• 해당 Backdoor가 어떠한 위협을 가하는지 좀더 심층적인 분석을 수행한 결과 해당 Backdoor의 이름을 찾을 수 있었다.

  이 Backdoor는 통신을 암호화 하기 위해 RSA공개키 암호화를 사용하는 CryptoPHP라는 것을 알 수 있었다.

   

  해당 플러그인을 다운받은 사이트를 찾을수 있었고, 해당 플러그인 아카이브 ZIP파일의 URL을 찾을 수 있었다.

  ZIP파일 내에 는 다음과 같은 코멘트가 있었다.

  

  이는 Joomla의 공식적인 서비스공급자 에서 다운받는 것이 아니며, 불법 복제, 해적판 라이선스임을 확인 할 수 있었다.

   

     

• 확인된 악성프러그인 배포 사이트를 확인 한 결과, 플러그인이 해당 웹사이트로부터 무료로 다운 받을 수 있었고,

  Backdoor가 심어진 줌라(Joomla)뿐 아니라 워드프레스( WordPress), 드루팔(Drupal)용 플러그인 및 테마를 확인 할 수 있었다.

  

  (악성 테마, 플러그인 유포지: hxxp://nulledstylez.com/ )

  위 URL은 hxxp로 입력 하였기 때문에, 하이퍼텍스트 기능은 없습니다.

  해당 사이트에서 학습목적으로 다운받아 분석하는 것은 자유지만 주의 하시기 바랍니다.

    

• 다운받은 플러그인 ZIP파일 내부에서 타임 스탬프(생성일자)가 다른 2개의 파일을 확인할 수 있었다.

  

   

    

  

  위 두개의 파일 생성일자가 다른 파일과 달리 최근에 생성되었다는 것을 기초로 분석을 한 결과,

  Jsecure.php의 코드 가장 하단에 social.png 라는 이미지 파일을 Include시키는 것을 확인 할 수 있었고,

  

   

    

  Social.png 파일을 확인 한 결과, 정상적인 png 이미지 헤더가 아닌 php파일의 소스코드를 담고 있었다.

  즉 Social.png가 CryptoPHP Backdoor로 동작하는 것을 확인 할 수 있다.

  

   

  해당 nulledstylez 사이트 에서 악성 플러그인, 테마 들을 다운받아 조사 하던 중, ZIP파일 내부에서 nulledstylez 뿐 아니라

  다른 악성코드 유포지로 의심가는 문구를 확인 하였고, "nulledstylez.com" 라는 도메인 사이트 또한 악성코드 유포지로 확인할 수 있었다.

  

   

   

  해당 dailynulled.com 사이트 역시 조사결과,

  nulledstylez.com 와 아주 유사한 사이트 이었고, 업로드 된 파일의 다운로드 사이트 또한 동일한 사이트로 확인되었다.

  

• 이와 2개의 사이트와 함께 CryptoPHP 관련되어 배포하는 약 20개의 사이트를 확인 할 수 있었다.

  

   

• 위 20개의 사이트를 통해 다운로드 되는 링크 사이트는 2곳임을 확인 할 수 있었다.

  

  

   

   

  

• CryptoPHP Backdoor 특징

1. CMS Framework의 기능을 사용 (영향 받는 CMS: Joomla, WordPress, Drupal)
2. CMS Database를 사용(탈취)
3. C2(CnC) 서버와의 공개키 기반 암호화 통신을 사용
4. 단순히 하나의 C2서버와의 통신이 아닌 대량의 C2서버를 이용
5. 오래된 버전의 Email 통신의 현태로, 백업 메커니즘을 포함
6. 감염된 웹 서버에 대하여 자동적인 악성행위 외에도, 수동 제어기능
7. 원격으로 C2 서버들의 업데이트 기능
8. 자동으로 업데이트 할 수 있는 기능
9. 웹 페이지에 내용을 주입(Backdoor의 실행을 위한 php페이지 내의 Content injection)
10. 코드 실행(social.png 파일의 코드실행)

     

• CryptoPHP Backdoor 파일 기본 구조

  "dailynulled.com"에서 다운받은 WordPress의 Plugin인 "WooCommerce Advance Order Status v1.1(주문 현황 뷰어 플러그인)"을

  분석 해 본 결과는 다음과 같다.

   

  해당 플러그인의 첫 번째 ZIP파일 압축을 풀어보면,

  다음과 같이 사용설명서, 라이선스 와 함께 정상적인 플러그인 파일과 동일한 구조를 가진다.

  

   

  해당 플러그인의 두 번째 ZIP파일 압축을 풀어보면,

  다음과 같이 초기 사건에서 발견할 수 있는 파일의 타임스탬프가 다른 두 개의 파일을 확인 할 수 있었다.

  

   

  "dhwc-product-lavels.php" 파일을 열어보면 보통 WordPress 플러그인 파일의 구성과 동일한 모습을 볼 수 있었다.

  

   

   

  하지만, 맨 아래의 코드를 보면 다음과 같이 일반적인 WordPress 플러그인 메인 php파일에는 없는 내용을 확인할 수 있었다.

  

   

  이는 플러그인이 실행될 때, social.png라는 파일을 include시키는데,

  Social.png 파일을 editor프로그램으로 열어보면 Backdoor 버전까지 확인 할 수 있다.

  

   

  이를 통해, 해당 Backdoor의 버전이 1.0a라는 것을 확인하였고, 검색을 통한 탐지를 회피하기 위해, 등록된 User가아닌 방문자가 해당 WordPress 웹 사이트를 방문할 시에 동작하는 것을 확인 할 수 있었다.

   

  CMS 통합 기능: Joomla, WordPress, Drupal와 같은 CMS의 기능은 모두 다르다, 따라서 Backdoor는 어떠한 CMS에서도 작동하기 위해서 3개의 CMS환경에 모두 적용이 가능하게끔 설계되어있다.

  예를들어 해당 Backdoor는 WordPress의 add_action 기능을 이용한 echo injection을 사용 함을 코드에서 확인 할 수 있다.

  

   

  Joomla의 경우에는 JResponse:getBody()와 JResponse:setBody() 함수를 사용하는 코드가 모두 함께 내포되어 있다.

  

   

  CMS 통합 기능: Joomla, WordPress, Drupal와 같은 CMS의 기능은 모두 다르다, 따라서 Backdoor는 어떠한 CMS에서도 작동하기위해서 3개의 CMS환경에 모두 적용이 가능하게끔 설계되어있다.

  예를들어 해당 Backdoor는 WordPress의 add_action 기능을 이용한 echo injection을 사용 함을 코드에서 확인 할 수 있다.

   

  하지만, Drupal 같은 경우는 워낙 코드의 복잡성과 WordPress와 Joomla와는 다른 구조이므로 해당 CryptoPHP Backdoor의 기능이 제한적일 것으로 판단된다.

    

   

• CryptoPHP Backdoor 관리자 계정 생성

  Backdoor가 WordPress 플러그인이나, 테마와함께 설치가 되면, 별도의 관리자 계정을 추가 생성 한다.

  이는, Backdoor를 제거 할 것 웹 사이트에 대한 액세스를 유지하기 위한 것으로 판단된다.

  기본적으로 별도의 생성되는 관리자 계정명은 'System' 이지만 이름이 해당 계정이 있을 경우는, 'System'뒤에 번호를 붙여

  등록이 될 때까지 while문을 돌린다. 이와 같이 관리자 계정 명뿐 아니라 등록할 Email 주소에도 같은 로직으로 짜여 있다.

  

   

    

• CryptoPHP Backdoor 암호화 통신

  CrtyptoPHP는 임베디드 RSA 공개 키를 사용하여 C2(CnC)서버와 통신한다. 통신 암호화는 PHP Openssl_seal의 RC4 암호화 한뒤, RSA 공개 키를 생성한다.

  Backdoor의 첫 번째 버전 (0.1)은 1024bit RSA Key 이었지만, 최근 발견된 버전(1.0a)에서는 2048 bit RSA 키를 생성하도록 업그레이드 된 모습을 확인 할 수 있었다.

  Backdoor는 C2서버와 통신 할 수 있도록 첫번째 초기화 시에 임의의 10문자 Server Key와, 추가 RSA 키 쌍을 생성 하고,

  공개 Key는 C2 서버로 전송된다. 이를 통해 C2서버는 감염된 서버를 조종 할 수 있는 일종의 Token이 생기게 된다.

   

  해당 C2서버로 전송될 때에, Backdoor가 설치된 날짜, 마지막 접속일자, 버전 정보, 접속 횟수 등의 정보를 함께 보낸다.

  

   

  만약, C2 서버와 성공적으로 연결되면, C2 서버측에서는 Server Key의 MD5 Hash 값을 리턴한다.

  이를 통해 Backdoor는 성공적으로 연결됨을 인지하는 구조이다. 이런 방법으로 C2서버와 통신을 체크하는 주기는 1일로 설정되어 있지만,

  위에서 언급 했던 Server Key를 사용하여 수동제어를 강제적으로 할 수 있다.

    

• CryptoPHP Backdoor Domain Randomized

  CryptoPHP는 하드코딩된 Domain List가 있는데,

  감염된 서버의 도메인 List를 다음 코드와 같이 램덤 화 시키고, 도메인 명을 MD5로 단방향 암호화 시켜 추적을 피한다.

  

    

    

• CryptoPHP Backdoor Manual Control

  서버 키를 생성하여 수동으로 Backdoor를 조작하는 것 또한 가능하며, 현재는 "update"와 "reset"명령어를 지원한다.

  예를 들면, C2 Server에서 감염된 웹 사이트로 다음과 같은 HTTP 요청을 통해 새로운 Check-In을 수동으로 할 수 있다.

  

   

  또는, 다른 C2 Server로의 연결을 수동으로 요청할 수도 있다.

  

   

   

• CryptoPHP Backdoor Configuration

  C2 Server는 Backdoor의 설정 또한 다음 코드와 같이 변경 / 업데이트 할 수 있다. (retrun JSON)

  

   

  Backdoor에서는 이와 같이 로컬 설정을 변경한다.

  

  설정을 업데이트 한 후에, 생성한 RSA Key 쌍을 이용하여 각각의 CMS에 맞게 암호화 하여 저장된다.

    

• CryptoPHP Backdoor Backup communication

  기존의 Crypto Backdoor와 최근 발견된 Backdoor는 암호화 된 데이터를 curl_exec 함수를 사용하여 전송한다.

  또한, curl_exec 함수를 사용할 수 없을 경우에, fsokopen함수를 이용하며, C2 Server와의 연결이 여러 번 실패 할 경우,

  이메일을 통해 암호화된 데이터를 전송 할 수 있도록 설계되어 있다. 하지만 이 기능은 최신 버전 1.0a 에서는 제거 되었다.

   

• CryptoPHP Backdoor 의 목적 : Blackhat SEO

  침해(감염)된 웹 서버에서 eval, echo 함수들을 사용하여 주입된 Link와 text들을 확인하여 해당 Backdoor의 최종 목적을 알 수 있었다.

  아래의 소스코드를 보면, User Agent, Hostname 등을 기반으로 방문자가 Web Crawler 일 경우에만, True를 반환 한다.

  (이해를 돕기 위한 구글 동영상 참고: https://www.youtube.com/watch?v=lG5lOix9b9k )

   

  다시 말해, 일반 사용자가 방문 할 경우에는 정상 사이트처럼 아무 반응이 없지만, Web Crawler가 해당 침해된 사이트를 방문 할 경우에는

  Bot이 작동한다. 즉, 주입된 Link나 Text를 보여주게 된다. 이렇게 되면 사용자나, 침해 웹 서버 관리자는 검색 엔진이나 웹사이트 방문을 통해서는 해당 웹 서버가 침해를 당했는지에 대한 여부를 육안으로 식별하기 힘들다.

  또한 이렇게 Web Crawler가 방문 하였을 때만 주입된 Link, text를 보여주는 이유는, 해커가 주입한 URL등의 검색 엔진 결과에서 나오는 순위를 올리기 위함이다. 만일, 유명하고 인기 있는 사이트를 해킹하여 이러한 기법을 이용한다면 참조되는 Link는 Web Crawler에 의해 좋은 순위를 얻을 수 있고, 이런 결과를 통해서 사업적 이득이나 또 다른 파밍 사이트로 유도 할 수 있게 된다.

  이러한 사기성 기법은 클로킹 이라고도 하며, BlackhatSEO(Search Engine Optimization)으로도 알려졌다.

   

  페이지 순위를 결정짓는 요소 중 하나는 페이지로 연결되는 수신 링크의 수와 품질이다. 이는, 페이지의 신뢰성과 권리를 높이는데, 그 이유는 외부 리소스로 연결되는 링크가 추가되는 것이 콘텐츠를 보증하는 것과 같기 때문이다.

   

  사이버범죄자가 좋은 웹사이트를 해킹한 다음 자신의 사이트로 연결되는 링크를 추가하여 순위 신호를 조작하는데,

  이 CryptoBackdoor의 소스코드 분석결과 이와 같은 궁극적인 목적을 확인 할 수 있었다.

    

  클로킹 된 사이트의 페이지 결과를 보면 다음과 같다.

  

  좌측은 일반적인 Default페이지 이며, 일반 사용자가 방문 하였을 때 보이는 페이지 이다.

  우측은 Web 크롤러가 방문했을 경우, 보이는 웹 페이지이며 룰렛, 겜블 사이트 등의 Hyperlink가 다수 포함되어있다.

  이런 방식으로 사용자에겐 숨기면서, 크롤러 검색 결과를 통해 해당 link들의 검색 엔진 순위를 올리는 SEO Bot의 작동 결과이다.

   

   

• CryptoPHP Backdoor 의 제작자 유추

  Backdoor 소스 중, 위에서 설명하였듯이 user-agent 와 hostnames 기반으로 Google, MSNBot, Yahoo, Twiiter 또는 Yandex등의

  클로러를 탐지하여 일반사용자가 방문하였을 때와 다르게 내포된 Link등을 보여준다.

   

  하지만, 흥미로운 점이 발견되었다. 소스에 보면 "chishijen12"라는 user-agent일 경우에도 크롤러가 방문하였을 때처럼 return값이 반환되어 Link등을 볼 수가 있도록 짜여 있었다. "chishijen12"라는 user-agent가 확인될 경우, 디버깅을 위해서 브라우저에 모든 PHP 오류를 출력한다. 해당 user-agent 조사결과 몰도바 공화국의 수도에서 사용되고 있는 IPv4에 대해서 사용되는 (2013년 12월부터) user-agent에서 이 문자열을 사용하는 것을 확인하였다.

  

  

  

     

• CryptoPHP Backdoor C2(Command and control) Server

  총 45개의 고유 IP와, 191개의 고유 도메인을 확인 할 수 있었다.

  아래 의 그림은 해당 IP와 도메인을 플로팅 그래프로 표현한 그림이다..

  

  위 플로팅 그래프에서 볼 수 있듯이, 각 노드들의 하나의 IP는 3-6개의 도메인을 포함하고 있고,

    

  C2 Server들은 네덜란드, 독일, 미국, 폴란드 순으로 위치 하고 있었다.

  

    

• Checking for CryptoPHP Backdoor IN Plug-ins and Themes

  플러그인 이나, 테마설치 시 다운받는 ZIP파일이나, Backdoor 내부 형태가 변하기 때문에 Hash값으로 매칭하여 찾기란 쉽지않다.

   

  가장 간단한 방법은 현재까지 조사한 바로 알려진 "social.png"파일을 찾고, 해당 파일이 정상적인 PNG 파일 포멧 헤더인지부터 조사하는 것이 가장 간단한 방법으로 생각된다.

   

  또한, 플러그인 이나 테마 설치 시 사용되는 function.php PHP페이지 가장 하단에 다음과 같은 코드가 있는지 조사 할 수 있다.

  

  위와 같은 방법은, Wordpress 포함, Joomla, Drupal 또한 동일하다.

   

  해당 Backdoor를 찾는 도구를 깃 허브에 업로드 한 상태이니 다운받아 사용할 수 있다.

  

   

  또한, 감염 서버에서 C2서버로의 Post 요청을 하는 트래픽에 대한 시그니처를 탐지하는 IDS 룰을 만들었으니, 참고하면 된다.

  

    

  • C2서버 IP 및 도메인 List, 파일 Hash List는 아래의 문서를 참고하시기 바랍니다.

  https://foxitsecurity.files.wordpress.com/2014/11/cryptophp-whitepaper-foxsrt-v4.pdf

   

02. ISSUE 실습

1. 실습

• 해당 ISSUE를 테스트 하기 위해 APM설치 후, Worepress 4.0.1-ko 버전을 설치하였다.
• 테스트를 위한 구성환경 정보는 다음과 같다.
  • OS & 3^rd Party

    + CentOS6.2(32bit) Lunux Kernel 2.6.32-220 (VMware)

    + Apache 2.2.15

    + Mysql 14.14

    + PHP 5.3.3

  • WordPress CMS

    + wordpress-3.7-ko_KR

  

   

  Nulled styles 에서 다운 받은 CryptoPHP가 내포된 해적판 테마를 수동으로 설치.

  

   

  해당 테마.Zip 파일 Virustotal 의 검사결과. (Zip파일 안의 내포된 파일에 따라 시그니처가 변하기 때문에 큰 의미는 없다.)

  

  

  위와 같이 "autodealer171.zip" WordPress 테마 안에는, social.png 라는 php코드가 삽입된 CryptoPHP Backdoor가 있음을 확인.

   

  

  수동으로 업로드한 ZIP파일을 통해서, 테마가 정상적으로 설치됨을 확인.

    

  업로드 직후(테마적용), 패킷 캡처를 하여 네트워크 트래픽을 확인 결과.

  감염된 Web Server에서 C2 Server로 Server Key를 전송하고, C2서버는 다시 개인키를 전송하는 것을 확인했다.

  

  위 패킷 스트림을 통해 알 수 있듯이. 감염된 Web Server의 요청에는 User-Agent, Referrer가 없었다.

  Pic2takes.biz라는 도메인에, SSL통신이 아닌 80포트로 POST요청으로 Server Key와 암호화된 데이터, 암호화 Key 값을 전송하고,

  해당 도메인에서는 MD5 Hash값을 담은 200OK Response가 오는 것을 확인 할 수 있었다.

   

  

  해당 도메인은 VirusTotal 검사결과에서 봇 네트워크, 악성코드 C2 Server로 확인 할 수 있었다.

    

  감염된 서버의 이후 행위를 계속 분석하기 위해서 패킷 덤프를 1시간 가량 건 뒤 확인 한 결과.

  2개의 IP로(다수 도메인) 반복된 GET 요청을 보내는 것을 확인 할 수 있었다.

  하지만, 모든 도메인에 대한 결과는 Google로 Redirect되었고, 결국 C2서버에 직접적인 접근을 할 수 없음을 확인 할 수 있었다.

    

  트래픽을 타임테이블로 정리한 결과 행위는 다음과 같았다.

1. BackDoor에 하드코딩된 모든 Domain중 하나의 Domain에 Post로 Server Key를 전달.
2. Backdoor에 하드코딩된 모든 Domain에 Get / 요청을 진행.
3. 요청한 Get의 응답으로, "www.google.com"로 Redirect 되는 것을 확인.
4. Wev Server는 Redirect된 구글 "www.google.com" 으로 다시 Get 요청을 하게 되고,

   "www.google.com"의 Respone 에는 다시 302 Redirect "www.google.co.kr"응답. (gfe_rd=cr, ei값의 파라메터가 붙은 URL로 Redirect)

5. 결국 모든 GET 요청은 구글의 gfe(google front end)로 연결된 후 구글 검색 메인화면의 Response(200OK)값을 받는다.

※gfe_rd 파라메터는 요청 URL에서 구글측에서 검색엔진 메인화면_리다이렉트(gfe_rd=cr),

Cr은 Country약자로 해당 국가의 구글 검색 메인 화면으로 Redirect 하도록 해준다.

따라서, 실습에서는 모든 악성 Domain요청이 2개의 단일 IP이었으며, 해당 도메인들은 구글로 Redirect 되므로,

직접적인 연결이 이루어 질 수 없음을 확인했다. Google이 싱크홀 작용을 하고 있는 것이다.

결론적으로, 실습에 사용된 테마의 Backdoor는 영향력이 없었지만,

만약 새로 코딩된 Domain이나 IP라면 반듯이 영향력이 있을 것이며, 클로킹(BlackhatSEO)의 목적을 이루기에는 충분하리라 생각한다.

악성 Domain 으로 Get 요청 -> www.google.com으로 Redirect -> www.google.co.kr로 다시 Redirect -> google.co.kr에서의 200OK 응답.

위 과정을 반복 진행하고 있으므로, 많은 트래픽이 발생하게 되지만, 백도어 감염으로 인한 실습에서 원격 조종은 불가 하였다.

확인결과, 수많은 도메인은 단일 2개의 C2 Server IP로 확인되었다.

Google을 제외한 모든 http Request의 도메인은 악성 C2 Server로 확인되었고, 해당 요청이 다시 Google.co.kr로 Redirect 되었다.

위와 같이 악성 Domain을 Web Browser로 요청 할 경우,

www.google.com으로 Redirect되고 -> 다시 google.co.kr으로 Redirect되며, 최종적으로 사용자는 Google.co.kr의 메인 화면에 접속된다.

03. ISSUE 대응방안

1. ISSUE 탐지 정책

해당 ISSUE는 취약한 3^rd Party, 업데이트 미흡, 악성테마 다운로드 등의 조건이 성립되어야만 가능하다.

Backdoor를 다운로드 하였더라도, png파일의 코드를 실행하지 않도록 3^rd Party업데이트, Wordpress 업데이트, 서버 백신등으로 대응 가능하며,

이번 ISSUE의 보고서를 작성한 Fox-IT Security에서 제공하는 python파일을 다운로드 하여, 해당 Backdoor 유무를 검사 할 수 있겠다.

당연한 말이지만, 가장 기본적인 보안 설정 적용 및 불법적인 CMS 테마 다운로드를 하지 말아야 한다.

Fox-IT에서 제시하는 정책을 Snort IDS에 적용 할 수 있겠지만, 자신만의 정책을 만들고 실습 해 본다.

아래와 같이, 감염된 Web Server는 CnC Server와 암호화 통신을 하기위한 Server Key 및 감염 Server의 Data를 전송한다.

그 외에 발생하는 Get 요청으로 지속적으로 발생하는 악성 Domain List 등은, DQ 정책으로 설정하면 될 것 같다.

alert tcp any any -> any any (msg:"UDS_XXX_CryptoPHP_CnC_Key_OutBound"; flow:established,to_server; pcre:"/Content\x2DDisposition\x3A\x20form\x2Ddata\x3B\x20name\x3D\x22serverKey\x22/i"; pcre:"/Content\x2DDisposition\x3A\x20form\x2Ddata\x3B\x20name\x3D\x22data\x22/iR"; pcre:"/Content\x2DDisposition\x3A\x20form\x2Ddata\x3B\x20name\x3D\x22key\x22/iR"; sid:5;)

# 정책설명: CryptoPHP의 감염직후 내부 -> 외부 POST 요청 (Server Key, Data, Key) -> C2 Server 로 전송을 탐지.

IDS 탐지 테스트 결과,

<IDS Log>

<Raw-Data>

04. 결론

1. 보고서를 작성하며 느낀 점

• 이번 CryptoPHP Backdoor는 국내에선 다행히도, 사용되는 서비스나 사람들의 분포도가 적어서 피해가 크진 않겠지만,

  피해가 없다는 것 또한 아니다. 또한 사람들의 무료를 원하는 심리를 악용한 악성코드 배포는 새로운 배포기술은 아니다.

  하지만, 플러그인 이나 테마의 해적판 버전의 완성도가 높고, 22개나 되는 도메인에서 배포하여 제법 피해가 큰 Issue였다.

   

  이번 ISSUE의 CryptoPHP를 조사하면서, 정말 놀라운 것은 여느 WebShell 보다 정교하고, 잘 짜인 코드였다.

  해당 Backdoor의 목적이 BlackhatSEO처럼 클로킹 기법은 사용함에 있어, 몰랐던 기법도 알게 되었다.

   

  검색엔진순위를 불법적으로 조작하는 것이 궁극적 목적이라 볼 수 있는데, 이 부분이 아주 흥미로웠다.

  몇 만개 이상의 정상적은 Web Server에 사용자는 볼 수 없고, 크롤러 들만 해당 페이지를 확인 한다면,

  검색엔진 순위 신호가 상승하게 될 것이고, 그에 따른 불법적 혜택을 받을 것이다.

   

  이런 검색엔지순위 조정을 위해서 뭘 할 수 있을까?

  생각해보면 단순히 한 두개의 Web Server를 해킹하여 개인정보를 탈취하는 것 이상의 이득이 발생할 수 있다고 판단된다.

  사업 목적의 Site 홍보나, 정치적인 홍보 수단으로 까지 활용 할 수 있다고 생각된다.

   

  이러한 Backdoor는 반듯이 제거되어야 하며, 포털사이트 에서도 이러한 클로킹 기법에 대한 대응방안 등을 제시해야 한다고 생각한다.

   

    

05. 참고문헌

•    블로그(hostpair): http://blog.hostpair.com/how-to-clear-cryptophp-php-malware/

•    CIO Korea: http://www.ciokorea.com/news/23162

•    보안뉴스: http://www.boannews.com/media/view.asp?idx=44242&kind=4

•    Infosecurity magazine: http://www.infosecurity-magazine.com/news/cryptophp-offers-free-cms-plugins/

•    Foxitsecurity Report: https://foxitsecurity.files.wordpress.com/2014/11/cryptophp-whitepaper-foxsrt-v4.pdf

•    BlackHat SEO: http://www.blackhatworld.com/blackhat-seo/f1-black-hat-seo/

•    Google Hacked: https://support.google.com/webmasters/answer/2600721?hl=en#preparation

PR_CVE-2014-6271(Shell Shock)

01. 개요

1. CVE-2014-6271 취약점 정보, 관련조사, 취약한 대상 등에 대해 알아본다.

2. 취약점 발현 시나리오(웹 서비스대상)에 대해 알아 보고 실제 공격을 통해 원리를 이해한다.

3. 취약점 대응방안과, 작성하며 느낀 점에 대하여 이야기 해 본다.

02. 본론

1. CVE-2014-6271(Shell Shock) 취약점 정보

• CVE-2014-6271 / CVE-2014-7169: Remote code execution through bash

  9월 24일, GNU Bash 원격코드 인젝션 ZeroDay 취약점이 공개 되었다.

   

• 해당 취약점은 GNU Bash의 환경변수를 통한 코드 인젝션 가능 취약점이다.

  Bash의 환경 변수에 함수정의를 이용해서 원하는 코드를 추가 할 수 있고, 다음 Bash가 사용될 때 추가된 코드가 실행되는 취약점.

  CGI의 경우, HTTP Request 헤더가 환경변수에 저장이 되는 특성을 이용하여 원격 코드 인젝션이 가능하다.

   

• Bash는 Shell 변수뿐만 아니라 Shell 함수도 다른 Bash 인스턴스로 Exporting 하는 것이 가능하다.

그렇게 하기 위해, Environment 를 통해 새롭게 추가된 함수정의(definition)를 전파하기 위해 함수 이름으로

환경변수를 만들고 그 변수 안에 '() { 로 시작하는 함수 내용을 정의한다.

• 그런데, 취약한 버전의 Bash구현의 경우, 다음과 같이 함수정의 뒤에 임의의 명령을 추가하면 Bash 프로세스에서 해당 환경변수를

  Import 할 때 끝에 추가된 명령까지 같이 실행하게 된다.

   

  

   

• 취약한 GNU Bash를 확인할 수 있는 방법은 다음과 같다.

  터미널에서 env x='() { :;}; echo vulnerable' bash -c "echo this a test" 명령어를 입력 하였을 때에,

  

  취약한 경우 다음과 같이 vulnerable 과 this is a test 가 표시된다.

   

  

  취약하지 않은 경우 다음과 같이 this is a test 만 표시된다.

   

  

  ※테스트 환경 : CentOS release 4.4 / GNU bash , version 3.00.15(1)-release (i686-redhat-linux-gnu)

   

• 위와 같은 취약점(CVE-2014-6271)은 리눅스, 레드햇, GNU에서 패치 적용되었지만 문제를 완벽히 해결하지 못하였다.

  Bash는 여전히 우회를 통한 취약점(CVE-2014-7169)을 가지고 있다. 이 취약점은 다음과 같은 명령어로 테스트해 볼 수 있다.

  터미널에서 env X='() { (a)=>\' sh -c "echo date"; cat echo 명령어를 입력 하였을 때에,

  

  취약한 경우 다음과 같이 echo 파일 생성된다.

  실제 생성 파일명을 결정하는 부분은 "echo date" 이고, 취약한 경우 "echo" 라는 파일생성과 날짜정보 출력.

  뒤에 cat echo 부분은 취약점이 성공한 결과 확인을 위해 생성된 파일명 echo 파일을 읽는 추가코드.

   

  

  취약하지 않은 경우 다음과 같이 echo라는 파일이 생성되지 않는다.

1-1. 취약점 위험성

• 해당 취약점은 CVSS (Common Vulnerability Scoreing System)에서 10점(HIGH)을 받은 만큼

  위험도가 상당히 높은 취약점이다.

  

▲[그림 1-1] CVSS 평가표

※CVSS(Common Vulnerability Scoring System) 이란,

"취약점 공동 평가 시스템" 이며 취약점을 DB로 관리하고, 취약점 마다 점수를 매겨, 위험도를 마련하고 있다.

• 현 시점 해외에서도 Bash 취약점 때문에 소란이 일고 있다. Trend Micro는 지금 하트블리드 보다 여러 면에서 더 심각한 것으로 속속 드러나고 있는 '전염병'이라고 표현했다. 이미 5억 개에 달하는 웹 서버와 인터넷에 연결된 기기들이 감염되어 있다는 결과와 함께였다.

   

• 공격에 성공한다면 공격자는 Linux 및 Unix 기반의 시스템에 대한 제어 권한을 갖게 된다. 그렇기 때문에 전문가들은 공격 벡터가 어마어마하게 클 수밖에 없을 것이라고 예상 중이다. (예상 벡터: 맥 OSX, Android, OpenBSD, DHCP Client, SSH Server, CGI나 Apache를 사용하는 Web Server, 가정용 Router(공유기), BitCoin Core, Embeded System 등 전부)

   

   

• 이번 취약점의 가장 큰 위험성은 사용방법의 난이도에 문제가 있다는 지적이 있다. SQL Injection 과는 다르게 WebShell 업로드에 성공한 결과처럼 공격자입장에서는 취약한 사이트를 찾고, PoC에 공개된 Exploit을 활용하여 하고자 하는 명령어만 입력하는 되는 것이다.

  따라서 평소에 조금이라도 해킹에 관심이 있었다면, 해당 취약점을 통해 다수의 공격자가 발생할 우려가 있다고 판단된다.

   

• 무선랜 공유기는 사용자들의 기기가 접속신호를 보내면 자동으로 IP를 배정해 주는 DHCP서비스를 제공한다. 공유기 혹은 이와 연결된 DHCP Server가 해킹될 가능성도 배제할 수 없다.

1-2. 취약점 관련 조사

• Bash는 자유소프트웨어 진영인 그누(GNU) 프로젝트가 개발한 프로그램(Shell)으로 출시 25년이 되었다.

  Shell은 리눅스는 물론 유닉스가 기반인 맥 OS X등 운영체제(OS)에서 기본 설정으로 활용되고 있다.

• 이 Shell은 윈도우 CMD를 입력하면 뜨는 도스(DOS)창과 유사한 기능을 한다.

  명령어를 입력하면 네트워크가 제대로 작동하고 있는 지를 확인하는 Ping 테스트, IP주소 확인, 해당 Server내 파일 검색,

  및 실행 등 기능으로 무한히 활용할 수 있다.

• Bash는 오래 사용된 만큼 많은 Server관리자들에게 가장 인기 있는 Shell이며, Web Server에 대한 설정을 변경, 분석, 복구, 업그레이드 등 Command 기능을 수행 할 수 있다.
• Bash Shell 공통게이트웨이인터페이스(CGI)로 프로그래밍을 할 때 주로 사용되는 것으로 리눅스 Server의 경우 별다른 설정을 하지 않았다면 기본적으로 이 Shell을 사용하고 있다.
• CGI는 Web Server와 외부 프로그램 사이에 정보를 주고 받기 위한 표준화된 프로그래밍 방식이다. 현재 대부분 웹사이트가 자바 스크립트를 기반으로 작성됐기 때문에 주로 과거에 만들어진 웹사이트 등이 CGI를 활용하고 있다.

   

   

  1-3. 취약한 대상

• 해당 취약점이 존재하는 Bash software 의 Version은 아래의 URL Link를 통해 확인 가능하다.

  NVD: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271

   

• 해당 취약점이 존재하는 Products 의 Version은 아래의 URL Link를 통해 확인 가능하다.

  OSVDB: http://osvdb.org/show/osvdb/112004

03. 실습 및 구현

1. 취약점 발현 시나리오

• 이 취약점의 발현 시나리오는 다음과 같다.

  출처: MITRE의 CVE(Common Vulnerabilities and Exposures)

1. Open SSH의 Force Command 기능을 우회하는데 사용할 수 있다.

   Force Command 는 SSH로 접근하는 사용자가 제한된 명령어만 실행하도록 만든다.

   하지만 이 취약점으로 허가되지 않은 명령을 실행할 수 있다.

   Force Command를 사용하더라도 사용자 계정을 알아야 하므로 제한적인 상황에서 사용 가능하다.

   (공격방법 참조 Link: http://forensic.n0fate.com/?p=1256)

    

2. Apache Web Server가 mod_cgi, mod_cgid 모듈을 사용하는 경우,

   CGI 스크립트를 이용하여 bash 명령어를 실행하거나, 서브 쉘(subshell)을 띄울 수 있다.

   C, Python, Perl로 구현된 CGI의 경우에도 시스템 명령어를 사용하는 경우(system, open) 공격이 가능하다.

   (공격방법 참조 Link: http://hacksum.net/uncategorized/cve-2014-6271-gnu-bash-%EC%9B%90%EA%B2%A9%EC%BD%94%EB%93%9C-%EC%9D%B8%EC%A0%9D%EC%85%98-%EC%B7%A8%EC%95%BD%EC%A0%90/)

    

3. DHCP 클라이언트가 악의적인 DHCP 서버로부터 획득한 값을 쉘 스크립트로 실행할 수 있다. 이 명령어는 루트 권한으로 실행된다.

   (공격방법 참조 Link: https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/)

    

4. 그 외에 권한을 가지는 데몬에서 Shell 스크립트를 실행할 수 있는 경우,

   이 취약점을 이용하여 데몬의 권한으로 임의의 명령을 실행할 수 있다.

2. 취약점 구현 및 실습

2-1.     EXPLOIT-DB Code 활용 테스트 (공격 대상: 발현 시나리오 2. 웹 서비스)

• 아래의 URL에서 다운로드 받아서 활용 테스트를 할 수 있다.
  • PHP Script: http://www.exploit-db.com/exploits/34766/
  • MSF Ruby: http://www.exploit-db.com/exploits/34777/

     

• 이번 활용 테스트에서 MSF Console을 사용, 2번째파일 bashcgi.rb를 exploit 폴더에 위치 시킨다.

  

   

• MSF Console을 활용하여 bashcgi 모듈에서 적절한 옵션값을 설정한다. ( ls –al )

  

   

• 공격 후, WireShark를 활용하여 실제로 어떤 식으로 패킷이 전송되며 어떤 응답이 오는지 확인한다.

  

  Exploit 명령으로 공격을 실행하면, Server 측에서 200응답(요청 성공)이 수신된다.

   

  

  요청한 패킷을 보면 User-Agent 헤더가 Bash의 환경변수로 저장되게끔 변조된 것을 확인 할 수 있다.

  수신한 패킷을 보면 hello.txt, nit.cgi, nit.sh, test.sh 파일들이 확인된다.

   

• 다음은 위와 같은 방법으로 몇 가지 명령어를 변경해서 더 테스트를 진행한다.

  

  Netstat 명령어 옵션으로 설정 후 공격 결과

  

  Cat /etc/passwd 명령어 옵션으로 설정 후 공격 결과

   

  

  Netcat의 Reverse 연결 요청 옵션 설정 후 공격 결과

• 위 테스트 결과와 같이, 취약점을 이용해서 임의의 코드 실행이 가능하다.

  해당 테스트 공격 시연에서는 Bash로 짜여진 CGI를 사용하였으나, 이 외에도 다음과 같은 경우에도 공격은 성공한다.

   

  • Bash로 짜여진 CGI페이지 외 스크립트 페이지 ( nit.sh )
  • C, Python,PHP으로 짜여진 CGI 는 system/popen(os.system/os.popen, system/exec) 을 사용하는 경우.
  • Perl 로 짜여진 CGI는 Bash Shell을 통해 open/system 함수를 사용하는 경우.

     

또한, 위 공격에서 User-Agent Herder를 변조하여 Bash 환경 변수를 사용하였으나,

이 외에도 환경변수에 저장되는 헤더들은 모두 공격에 활용이 가능하다.

• HTTP_USER_AGENT
• HTTP_HOST
• ACCEPT_LANGUAGE
• ACCEPT_ENCODING
• CACHE_CONTROL

04. 결론

1. 취약점 대응방안

• 방법은 간단하게 말하자면 Bash(Bourne Again Shell) Version 업데이트 이다.
  • RedHat Enterprise 4(els), 5, 6, 7 – https://access.redhat.com/solutions/1207723
  • 우분투 10.04(lts), 12.04(lts), 14.04(lts) – http://www.ubuntu.com/usn/usn-2362-1/
  • CentOS 5,6,7 – http://lists.centos.org/pipermail/centos/2014-September/146099.html

• 시스템 바이너리를 빌드하여 업데이트 하는 방법. (OS X 사용자)

  참고: http://apple.stackexchange.com/questions/146849/how-do-i-recompile-bash-to-avoid-shellshock-the-remote-exploit-cve-2014-6271-an homebrew나 macport와 같은 repository를 사용하지 않는 경우 적용 가능한 방법으로 최신 bash를 다운로드하여 xcode로 빌드하는 방법이다. 애플 오픈소스 사이트에서 bash 소스 코드를 다운로드 받고, 여기에 gnu에 올라온 bash 패치를 적용하여 빌드한다.

  그리고 bash와 sh를 교체한다.

  

   

1. 마지막으로 기존 bash 명령어에 실행 권한을 제거한다.

   

    

• Homebrew 활용

1. Homebrew에는 이 취약점이 패치 된 bash가 등록되어 있다. 간단하게 두 명령어로 패치를 진행할 수 있다.

   

    

      

    

2. 취약점 대응 탐지(Snort Rule)정책

Zero Day 취약점은 무한정 패치를 기다릴 수도 없고, 연관 공격이 발생할 우려가 있어, 보안 업무에 있어서 해당 취약점 공격을 탐지하는 패턴(Rule)과 정책을 적용 시켜서 주의 깊게 모니터링 및 차단대응을 해야 한다.

공격 테스트시 캡처한 pcap 파일을 HEX-Editor를 활용하여 드래그 한 모습이다.

일반적인 통신에서는 발생하지 않고, 해당 취약점 공격에서 발생하는 HEX값을 이용하여 정책을 설정한다.

※Snort Rule 참고: http://kthan.tistory.com/136, http://neospring_.blog.me/50176482644

위 사진처럼 상위 3개와, ping, nc, wget, curl 을 활용하여 4개의 정책을 생성한다.

1. alert tcp any any -> any any (msg:" Bash_code_injection_ping"; content:"|28 29 20 7b|"; content:"|48 6f 73 74 3a 20|"; content:"|55 73 65 72 2d 41 67 65 6e 74 3a 20|"; content:"|70 69 6E 67|"; nocase; )
2. alert tcp any any -> any any (msg:"Bash_code_injection_nc"; content:"|28 29 20 7b|"; content:"|48 6f 73 74 3a 20|"; content:"|55 73 65 72 2d 41 67 65 6e 74 3a 20|"; content:"|6E 63|"; nocase;)
3. alert tcp any any -> any any (msg:"Bash_code_injection_wget"; content:"|28 29 20 7b|"; content:"|48 6f 73 74 3a 20|"; content:"|55 73 65 72 2d 41 67 65 6e 74 3a 20|"; content:"|77 67 65 74|"; nocase;)
4. alert tcp any any -> any any (msg:"Bash_code_injection_curl"; content:"|28 29 20 7b|"; content:"|48 6f 73 74 3a 20|"; content:"|55 73 65 72 2d 41 67 65 6e 74 3a 20|"; content:"|63 75 72 6C|"; nocase;)

3. 해당취약점을 조사하며 느낀 점

• 항상 대단히 크게 이슈가 되는 취약점 들의 공통점은 Open Source로 정리된다.

  Open Source의 장점은 무수히 많지만, 최근 하트블리드(OpenSSL)취약점이나, 이번 쉘쇼크(GNU Bash)취약점 같은 경우 일반적으로 상용 제품 안에서만 사용되는 것이 아니라, 모든 IOT기기를 아우른다. 이번 보고서에 특정 제품을 테스트한 기록은 담지 않았으나, 카페, 학교, 집 에서 흔히 쓰는 IP-Txxx 의 공유기 또한 해당 취약점이 존재한다. 이 뿐만 아니라 IP-TV 모바일 기기 등 이제는 실생활에서 쓰이는 IOT기기가 점점 많아질수록 모듈 단의 취약점의 리스크 는 상상외로 심각하다.

   

  또한 OSX와 리눅스 사건들을 보면 윈도우가 제일 취약 하다는 편견도 깨게 된 셈이다.

  IOT시대에 이르러 이제 리눅스, OSX의 안정성이 더 부각되어야 된다고 생각한다.

   

  마지막으로 우리는, 오픈소스 커뮤니티의 마인드가 가진 고질적인 문제 "내가 아니라면 누군가 하겠지" 라고 생각하는 수동적인 태도를 버리고, 내가 먼저 보안 조치를 하면 어떨까, 사물인터넷(IOT)세상에서 우리는 정말 안전한가 에 대한 경각심을 키워야 한다고 생각한다.

   

    

   

   

05. 참고문헌

[1]보안뉴스: http://www.boannews.com/media/view.asp?idx=43170

[2] hacksum: http://hacksum.net/vuln/cve-2014-6271-gnu-bash-%EC%9B%90%EA%B2%A9%EC%BD%94%EB%93%9C-%EC%9D%B8%EC%A0%9D%EC%85%98-%EC%B7%A8%EC%95%BD%EC%A0%90/

[3] NVD: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169

[4] OSVDB: http://osvdb.org/show/osvdb/112004

[5] CVE: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7169

[6] Exploit-DB: http://www.exploit-db.com/exploits/34766/    

[7] Sec.Blog: https://securityblog.redhat.com/2014/09/26/frequently-asked-questions-about-the-shellshock-bash-flaws

[8] TrustedSec: https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/

[9] n0fate: http://forensic.n0fate.com/?p=1256

[10] Seclists: http://seclists.org/oss-sec/2014/q3/690