본문 바로가기

Security Indicator/Insight

2009 DDos 분석과 대응

우려 했던 상황이 현실화 되었다. 이미 그 단초는 제공이 되어 있었다. 필자가 2007년경에 언급한 IT서비스의 현재 위험과 대응이라는 (첨부문서 참고)글에서 언급 되었던 내용이 많은 준비가 이루어지지 않은 현재 그대로 적용 되었다. 몇 가지 작은 부분에 있어서의 두드러진 특징들이 있으나 큰 범주를 벗어나지 않는다. 본 컬럼에서는 간략한 특징과 유형을 간결하게 정리하고 문제의 원인으로 추정되는 부분과 향후의 대책 부분에 대해서 언급한다. 보다 기술적인 부분은 전문 보안업체의 기술 보고서를 참고 하기 바란다.

 

- zdnet 컬럼 기고입니다.

 

일단 기본적인 IT 서비스 문제점 유형을 개인적인 관점에서 보면 다음과 같으며

정리하면 위험의 큰 목차는 다음과 같다.

 

l    웹서비스를 통한 악성코드 유포

l    악성코드를 이용한 DDos 공격 ( IDC , ISP , 대규모 Service Provider 등 모든 부분 영향)

l    Zeroday 위험 ( 신규 백도어를 이용한 정보 절취 및 기간 서비스 위험)

l    Botnet ( IRC Botnet과는 차별화된 HTTP를 이용한 Malware net이 현재의 집중적인 위험도 포함됨)

l    웹서비스 자체의 취약성 ( 악성코드 유포의 근본 요인으로 지목한다.)

 

먼저 2007년에 작성한 위험상황과 달라진 것이 특별히 없다. 그러나 4번 항의 Malware net 부분은 이슈가 되고 있다.

 

현재의 상황에 대한 개인적인 의견은 대규모, 조직적, 계획적, 오랜 기간 ( 최소 1~2개월 이상) 준비된 이라는 표현으로 간략히 언급하고자 한다.

 

 

 

현재 발생된 DDos 건에 대해서만 정리하면..

 

1.   공격자의 정체 확인 불가

 

l  악성코드가 개인 PC에 설치된 이후 관련 기록들을 다 제거하고 날짜까지 변경함. 추적 방지를 위한 증거인멸

l  증거가 없는 관계로 근본적인 추적이 되지 않음

l  악성코드내의 중요루틴 암호화 및 일부 분석 방지 ( Anti debugging) 기능

 

2.   공격정보를 C&C로부터 Command를 받는 것이 아니며 일부 접근 시도하는 IP를 통해서 추가적인 명령들의 실행이 가능한 상태로 보이며 미리 업데이트된 공격정보 이용하여 특정대상 및 공격형태를 지정함. 또한 스팸공격 및 TCP (HTTP), UDP Flooding, ICMP Attack을 병행하여 진행

 

l  IP 변조 발생되고 있음. 공격자 IP 숨기는 공격도 병행 발생

l  HTTP 에 대한 집중적인 DDos ( 정상 연결 유형으로 웹서버의 자원을 요청하도록 하여 리소스를 빠른 시간에 소모)

l  하나의 프로토콜이 아닌 다양한 형태의 DDos 공격 수행 ( 스팸 발송 있음)

l  공격정보를 정해진 시간에 받거나 업데이트 하는 유형으로 추적을 피하는 것으로 추정

l  감염 이후 해외의 최소 6 ( DDos Agent 3 IP , Spam Agent 6 IP) IP에 접속하여 명령을 받는 것으로 추정됨 공격리스트의 업데이트 혹은 Command 수행

l  기존의 Control 서버의 통제를 받는 것이 아닌 개인PC에 설치된 이후 해외 IP 연결을 통해 이후 Action을 진행하는 것으로 보임

 

3.   대규모 좀비 PC를 활용함.

l  C&C 서버가 없이 일정시간에 업데이트 혹은 내정된 URL로 정해진 사이즈와 일정형태의 패킷을 발송

l  소규모가 아닌 대량의 감염 시스템을 활용한 형태

l  변종들이 계속 나타나고 갱신되고 있으나 기존 감염 PC에서는 추가 변종 증세가 나타나지 않음

l  업데이트 통로가 다른 경로로 존재하지 않거나 별도의 공격리스트를 가진 좀비 PC 그룹이 존재하지 않는다면 분석된 리스트의 일자에 공격은 종료 될 것임.

 

4.  대규모 Malware Net 동원에 대한 개인의견

 

현재 규모와 같은 대규모 좀비PC 동원을 위해서는 두 가지 정도의 가능성이 존재함.

 

n  기존에 존재하는 Botnet 채널들을 활용하였을 가능성 ( 알려지지 않은 Bot 계열일듯)

 

l  전제조건: 기존에 알려진 유형의 Bot 계열이 아님, 이 경우 공격대상의 빠른 변동과 업데이트 가능.

l  Botnet 채널들을 활용해 이번 DDos 공격에 필요한 악성코드만을 별개로 설치한 유형 의심 할 수 있음.

l  여기에서 언급하는 Botnet은 기존에 알려진 Botnet이 아닐 것임 별도의 설치 채널 이나 통신채널 유지 가능성.

l  대규모의 Botnet 채널에 악성코드 설치 이후 채널 제거 혹은 비활성화 가능성도 있을 듯. 정체 은폐 및 공격 유형과 시간은 사전에 업데이트 해 놓은 상태로 유지

 

n  방문자가 많은 사이트를 통한 악성코드의 유포 가능성 (해킹 후 코드 변조를 통해 유포 했을 가능성)

l  전제조건: 일정기간의 준비기간 소요, 각 단계별 공격 기능과 1,2,3차에 걸친 공격대상의 확정이 필요하거나 업데이트 기능 필수적임

l  이 문제는 대부분의 좀비 PC가 일반사용자 PC라는 점에서도 추론이 가능하다.

l  방문자가 많은 웹 서비스를 통해 Zeroday 취약성을 이용해 악성코드를 유포하였을 가능성 있음. 최근의 Direct X 관련 취약성 연관 가능성 있을 수 있으나 준비 기간이 오래된 것으로 미루어 연관성 적을 것으로 예상

l  일반적으로 악성코드 설치 이후 바로 동작하는 것이 아니라 정해진 시간에 활성화 됨으로써 오랜 준비기간 동안에도 노출이 되지 않았을 가능성 있음

l  지난 3~4년 동안 국내의 주요 웹 서비스를 통해 사용자에게 유포된 악성코드의 유형과 종류는 알려지지 않은 유형들도 상당수 존재할 것으로 보임.  모든 악성코드를 백신에서 걸러내지는 못했을 것임. 이중 상당수에 공격코드를 올려 놓고 D-Day를 지정하여 실행 하였을 것임.

l  주기적으로 해외 Control 기능의 IP에 접속하여 올려진 새로운 명령을 체크하고 자체적인 업데이트 등으로 D-Day를 준비 하였을 것임

 

 

 

현 상황에서 취할 수 있는 대책

 

1.    긴밀한 협조 관계 구성 ( 백신 업체, ISP , Control Tower )

 

l  악성코드 유형 발견 시 즉시적인 공유 및 분석, 이후 일괄적인 백신 업데이트 요청 ( 최대한 빠른 시간에 진행 되어야 함) . 이 경우 단계별로 감소 시킬 수 있을 것으로 보임.

l  ISP 와의 협조 관계, 악성코드 공격이 확인될 경우 자료수집 조사, 대응방안 협의

l  Control Tower A,B 단계에서의 긴밀한 협력과 DDos 대상 기관 및 업체에 대한 가이드 및 지원 , Best Practice의 빠른 확산 및 적용 가이드 제공 할 것. 그 외 국내 사용자가 많은 백신을 기준으로 1~10위 이내에 일괄적인 업데이트 진행 요청 할 것. 가급적 일괄 대응 체제 구성

l  정보획득 -> 분석 -> 대응의 일괄적인 대응 체제 구성 할 것.

 

2.    분석 진행 시 유의 사항. 현재로서는 진행경로와 감염경로를 밝히는 것이 최우선임. 이점에 대해 각 기관별 분석된 정보의 빠른 공유 필요함  - 종합적인 분석과 현황파악이 가능하도록 주관 기관이나 단체의 Owner ship 필요.

 

3.    베스트 대응 케이스에 대한 대응 시나리오의 전체적인 확산 필요 ( 금전 소요를 최소화 하는 방향으로, 무조건적인 장비 도입은 그리 바람 직하지 않음)

 

장단기적으로 구성 되어야 하는 부분

 

1.   전역적인 대응체제 구성의 절대적 필요성

 

l  백신사, ISP, Control 기관의 유기적인 협조

l  그동안 무작위로 개인 PC에 설치된 악성코드에 대한 통합적인 분석과 일괄적인 제거

l  악성코드 유포를 위해 가장 많이 이용된 웹 서비스 취약성에 대한 대응

 

2.   개인 PC 환경에 대한 획기적인 보안성 강화 필요.

l  중앙통제 유형 보다는 개인 사용자 별로 확인이 가능한 체제 혹은 ISP 단에서 체크가 가능한 형태로 구성이 되어야 함.

l  과다 트래픽, 특정 대상을 향해 집중되는 트래픽 유형등을 위험시에 직접 접근 및 제어 가능해야 함.

 

3.   웹서비스의 취약성에 대한 직접적인 대응 필요

l  실효성 있는 웹 서비스 취약성 검증 유형 수립 필요 ( 실행기간의 단축, 비용의 문제 등등, 일정 규모 이상은 실효성 있는 서비스의 보안성 검토 필요)

l  실효적인 보안정책 가이드 필요 ( 개인정보보호 강화를 위해서는 실질적으로 기본적인 서비스 보안이 가장 우선 되어야 함. 그러나 현재는 그런 방향과는 거리가 있음)

l  개발자에 대한 보안 가이드 및 미래 개발자를 위한 서적, 교육, 개발자 커뮤니티 지원과 같은 실효적인 awareness 필요.

l  보안성 검수와 같은 개발 절차 이후 오픈 이전 단계의 보안 점검 프로세스 가이드 및 보급

l  단기적으로 거의 모든 Web Application에 대한 빠른 시일 내의 취약성 제거 필요 – 악성코드 유포에 많이 이용되는 SQL Injection 만이라도 반드시 제거 할 수 있도록 가이드.

 

 

이 정도로 정리가 된다. 소를 읽고 나서라도 외양간이라도 제대로 고쳐야 할 것이며 문제의 해결책은 장비의 추가가 될 수 없다는 것을 반드시 명심해야 한다. 근본적인 원인 제거가 꾸준히 있어야 하고 전역적인 대응이 가능한 효율적인 체제가 있어야만 할 것이다. 꾸준하게 유포되던 악성코드들의 위험성은 이미 2년 전에도 예정된 것과 다름 없다. 그 사이 얼마나 많은 준비를 하였고 고민들이 있었는지 심각하게 고민해야 할 때이다.

 

 

마지막으로 오랜 기간의 준비를 통해 계획된 공격들의 목적은 자신감이다. 전체를 흔들 수 있다는 자신감의 표현이다. 적극적인 대응만이 IT서비스를 살릴 수 있는 유일한 방법이다. 

                                 바다란 세상 가장 낮은 곳의 또 다른 이름