2012년 3월 MS 정기 보안 업데이트에 포함된 원격 데스크탑 서비스 취약점에 관한 보충설명입니다. 해당 취약점을 악용한 웜이 빠른 시간내에 나타날 것으로 예상되므로, 해당 취약점에 대한 빠른 대응이 필요합니다.

요약

원격 데스크탑 서비스에 심각한 취약점이 발견되어, 공격자는 원격에서 조작된 패킷을 보내어 악성 코드를 실행한 후 시스템 권한을 획득할 수 있습니다.

윈도우 XP, 비스타, 7, 서버 2003, 2008, 2008 R2에 해당 취약점이 존재합니다.

취약한 OS 목록

윈도우 XP, 비스타, 7, 서버 2003, 2008, 2008 R2 에 해당 취약점이 있으며, 32, 64비트를 구분하지 않고 Itanium 플랫폼도 포함합니다.

취약점 대응 및 회피 방법

최선의 방법은 MS 정기 업데이트를 적용하는 것이나, 사정에 따라 업데이트를 하지 못하는 경우 다음과 같은 방법을 사용하여 취약점을 회피할 수 있습니다.

1. 원격 데스크탑 서비스가 필요하지 않은 경우 관련 서비스를 중지한다.
   해당 취약점은 원격 데스크탑과 관련된 서비스가 작동하는 경우에만 유효합니다. 그렇기 때문에, 원격 데스크탑 기능이 필요하지 않은 경우 원격 지원, 원격 데스크톱, 터미널 서비스, 원격 웹 워크플레이스 등 관련 기능을 중지합니다.
2. 방화벽에서 원격 데스크탑 서비스로 사용하는 TCP 3389번 포트를 차단한다.
   원격 데스크탑 서비스로 사용하는 TCP 3389번 포트를 차단하고, 인증된 IP만 사용하도록 하면 해당 취약점을 회피할 수 있습니다. 만약 원격 데스크탑 서비스를 3389번 아닌 다른 포트에서 사용하는 경우, 방화벽에 해당 포트에 대한 정책을 설정합니다.
3. 비스타, 7, 서버 2008, 2008 R2 에서 네트워크 수준 인증을 사용한다.
   네트워크 수준 인증을 사용하는 경우, 인증을 통과해야 악의적인 패킷으로 공격 할 수 있습니다. 네트워크 수준 인증을 사용하기 위해선 다음과 같은 조건을 만족해야 합니다.
   
   - 클라이언트는 원격 데스크탑 연결 6.0 이상을 사용해야 합니다.
   - 클라이언트는 CredSSP 프로토콜을 지원하는 윈도 XP(서비스 팩 3), 비스타 또는 7을 사용해야 합니다.
   
   * 윈도우 XP 서비스 팩 3는 CredSSP 기능이 포함되어 있으나, 기본적으로는 비활성화 되어 있습니다. CredSSP를 활성화 하는 방법은 Windows XP 서비스 팩 3 자격 증명 보안 지원 공급자 (CredSSP)에 나와있습니다. 

세부 내용

CVE-2012-0002로 명명된 취약점을 이용하면, 공격자는 원격 데스크탑 서비스가 동작하는 시스템을 공격하여 완전한 제어 권한을 획득할 수 있습니다. 

윈도우 XP, 서버 2003 의 경우, 공격자는 조작된 패킷을 보내어 원격에서 악성 코드를 실행할 수 있고, 이를 통해 시스템 권한을 획득할 수 있습니다.

윈도우 비스타, 7, 서버 2008, 2008 R2에서 네트워크 수준 인증을 사용하지 않는 경우, 공격자는 조작된 패킷을 보내어 원격에서 악성 코드를 실행할 수 있고, 이를 통해 시스템 권한을 획득할 수 있습니다.

윈도우 비스타, 7, 서버 2008, 2008 R2에서 네트워크 수준 인증을 사용하는 경우, 공격자는 인증을 거친 후 조작된 패킷을 보내어 원격에서 악성 코드를 실행할 수 있고, 이를 통해 시스템 권한을 획득할 수 있습니다.

이 취약점을 이용하면 Conficker 웜과 유사한 형태의 공격이 가능할 것이라 예상하고 있습니다. 

관련 정보

원격 데스크톱 서비스 연결을 위한 네트워크 수준 인증 구성

Windows XP 서비스 팩 3 자격 증명 보안 지원 공급자 (CredSSP) 에 대한 설명

Microsoft Security Bulletin MS12-020 원격 데스크탑 원격 코드 실행 취약점(2671387)

앞서 다룬 Fast-Flux 도메인을 탐지하기 위해서는 여러가지 방법이 있지만, 네임서버에서 DNS 쿼리 로그를 수집하여 분석하는 것이 가장 간단한 방법 중 하나일 것입니다. 

가장 대중적으로 사용하는 네임서버인 BIND의 경우, 기본적으로 DNS 쿼리를 로그로 남기지 않습니다. 그렇기 때문에 별도의 설정을 해야합니다. 일단 간단하게 쿼리를 로그로 남기게 설정해둔 named.conf 파일을 살펴보겠습니다.

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
        channel default_dnshit {
                file "data/dnshit.log";
                print-time yes;
        };
        category queries {
                default_dnshit;
        };
};

어떤 것인지 대충 감이 오나요? 

서버에 쿼리(category queries)가 오면, default_dnshit; 설정에 따라 로그를 남기라고 하는 것입니다.

channel default_dnshit은 dnshit.log라는 파일에 로그를 남기고(file "data/dnshit.log";), 시간을 남기도록(print-time yes;) 설정되어 있습니다.

이 설정에 따라 dnshit.log 에 남겨진 로그를 살펴보면 다음과 같습니다.

[root@******* data]# tail -f dnshit.log
19-Jan-2012 17:00:27.772 client 121.167.11.1#25401: query: nchovy.kr IN A -E
19-Jan-2012 17:00:36.320 client 121.138.224.7#15593: query: nchovy.kr IN A -E
19-Jan-2012 17:00:38.275 client 210.94.11.122#13063: query: xeraph.com IN A -E
19-Jan-2012 17:00:48.782 client 210.94.11.106#15154: query: ns2.nchovy.com IN A -E
19-Jan-2012 17:00:48.782 client 210.94.11.106#50051: query: ns3.nchovy.com IN A -E
19-Jan-2012 17:01:08.538 client 207.46.200.37#49745: query: ns1.nchovy.com IN A -

이런식으로 파일에 쿼리 로그를 남긴 후, 파싱하여 분석할 수 있습니다. 그러나 이렇게 한다면 매번 로그를 보기 위해 DNS 서버에 접속해서 별도의 파일을 살펴봐야 합니다.

그러나 bind 의 설정과 syslog 의 설정을 이용해 syslog로 남기거나, 외부의 syslog 서버로 보낼 수도 있습니다.

named.conf 에 아래와 같이 설정을 추가하였습니다. 굵게 표시된 부분이 추가된 부분입니다.

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
        channel default_dnshit {
                file "data/dnshit.log";
                print-time yes;
        };
        channel syslog {
                syslog local7;
        };
        category queries {
                default_dnshit;
                syslog;
        };
};

syslog에 로그 분류(facility) local7 으로 보내도록 설정이 추가되었습니다. 기본적으로 syslog 설정에는 local7 설정이 없기 때문에 아래에 나와있는 설정을 syslog.conf 에 추가합니다. syslog에서 시간을 기록하기 때문에 시간을 기록하는 옵션("print-time yes;")은 설정하지 않습니다.

local7.*                        /var/log/local7

이렇게 설정을 추가한 뒤 named 와 syslog를 재시작하고, /var/log/local7 파일을 보면 아래와 같이 로그가 기록됩니다.

[root@******* log]# tail -f local7
Jan 19 16:58:29 ******* named[12230]: client 202.188.1.27#36711: query: krakenapps.org IN A -
Jan 19 16:58:33 ******* named[12230]: client 208.78.69.150#58826: query: ns2.nchovy.com IN A -E
Jan 19 16:58:33 ******* named[12230]: client 208.78.69.150#18435: query: krakenapps.org IN A -E
Jan 19 16:58:33 ******* named[12230]: client 208.78.69.150#13351: query: ns3.nchovy.com IN A -E
Jan 19 16:58:37 ******* named[12230]: client 193.254.230.2#59556: query: ns2.nchovy.com IN A -E
Jan 19 16:58:37 ******* named[12230]: client 193.254.230.2#24909: query: ns4.nchovy.com IN A -E
Jan 19 16:58:37 ******* named[12230]: client 193.254.230.2#18610: query: ns3.nchovy.com IN A -E
Jan 19 16:58:37 ******* named[12230]: client 193.254.230.2#3692: query: ns1.nchovy.com IN A -E

이 로그를 원격으로 보내기 위해선 아래처럼 syslog.conf 를 수정하면 됩니다.

local7.*                        @100.100.100.100

그리고 해당 syslog 서버가 로그를 받도록 설정합니다.

레퍼런스

• 네임서버(bind 9)에서 로그 설정(logging)
• BIND 9 Configuration Reference
• Remote Host Logging with syslogd
• 원격 로그 서버 만들기 완벽 가이드

이 글에서는 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 집합의 유사성으로 각 악성 도메인 간의 연관 관계를 분석할 수 있다.

원문

• Xeraph@NCHOVY : Fast-Flux 도메인 탐지

레퍼런스

• Know Your Enemy: Fast-Flux Service Networks
• Stormcast: Fast Flux Hosting