본문 바로가기
정보보호 (Security)

해킹 공격기법과 대응 방안

by 날으는물고기 2009. 3. 31.

해킹 공격기법과 대응 방안

① 서비스 거부 공격


생활의 모든 부분에서 인터넷을 이용하고 있으며, 모든 것이 빠른 속도로 변해 가고 있다. 이런 점을 이용하여 인터넷을 통한 공격도 다양해져서 사용자들이 곤란에 빠지기도 한다. 그런데 이 기법이 나날이 고도로 지능화 되고, 순식간에 전 세계로 퍼질 수 있으므로, 각 기업 보안담당자들은 이런 현상에 대해 정확히 대비할 수 있는 지식을 갖추는데 좀 더 많은 노력을 기울여야 할 필요가 있다.

앞으로 약 6회에 걸쳐, 가장 일반적이며 이슈가 되고 있는 해킹 기법과 대응방법에 대해 알아보도록 하자.

1. 서비스 거부 공격(Denial of Service Attack)

차 를 몰아본 경험이 없는 사람이라 하여도, 출퇴근길 뿐만 아니라 시도 때도 없이 막히는 서울의 교통체증은 누구나 다 아는 이야기이다. 이러한 체증의 원인 중에 하나가 "병목현상"이란 단어로 설명될 수 있는데, 이 현상은 쉴새 없이 수많은 정보들을 전세계로 이어 주고 있는 인터넷이란 교통구간에서도 동일하게 적용되고 있다.

최근 1.25 대란 사태에도 인터넷의 주소지 역할을 하는 DNS(Domain Name Server)가 처리할 수 있는 용량을 크게 넘는 요청이 쇄도하여 서비스가 중지됨으로써 하루동안 인터넷을 사용하지 못하는 대형사고가 발생하였던 경험을 가지고 있다. 다행이 업무시간을 피해 주말에 일어난 사고라 개개인들이 직접 피부로 느끼지는 못하였지만 일부 중요 서비스의 중단만으로도 사회 곳곳에서 많은 불편을 겪어야만 했다.

서 비스 거부 공격이라 함은, 시스템의 정상적인 서비스를 방해할 목적으로 대량의 데이터를 보내 대상 네트워크나 시스템의 성능을 급격히 저하시켜 대상 시스템에서 제공하는 서비스들을 사용하지 못하게 하는 공격으로 해킹 수법중의 가장 일반적인 방법이다.

인 터넷 사용자가 많지 않았던 초기의 서비스 거부 공격은 단일 시스템이나 서비스를 목표로 하는 공격자에 대한 피해자의 1:1 유형이 주류를 이루고 있었다. 그러나 최근에는 분산 서비스 거부공격이란 이름으로 N개의 불특정 시스템이 단일 네트워크를 대상으로 공격을 시도하는 N:1 유형이 주류를 이루고 있다.

이러한 공격은 사전에 공격을 받아 감염된 불특정 다수의 시스템으로부터 동시에 공격이 시도됨으로써 그 피해는 단일 시스템 뿐만 아니라 전체 네트워크까지 마비시킬 수 있는 파괴력을 가지고 있다. N:1 유형의 공격방법은 수작업으로는 많은 시간이 소요되기 때문에 주로 웜(Worm)
과 같은 자동화된 공격도구가 사용되는 경우가 많다. 따라서 공격도구의 특성을 제대로 파악하면 이에 대한 대응방법도 마련될 수 있기 때문에 이러한 연구활동도 전세계적으로 활발하게 진행되고 있다.


기술적인 대응방법뿐만 아니라 가장 중요한 것은 사전에 증후 발견이다. 이러한 공격은 대규모 네트워크를 이용하기 때문에 비정상적인 네트워크 흐름을 유발하여 초기에 이상징후를 탐지한다면 이에 대한 빠른 대응이 가능하게 된다.

이 를 위하여 기본적인 보안솔루션을 구축하는 것은 물론, 적절한 관리와 운영이 병행해야 할 것이다. 또는 전세계적인 망을 가지고 있는 침해 사고 대응팀, 혹은 보안서비스 전문업체와 긴밀한 관계를 유지하여 기업보안 대책을 지속적으로 업데이트 시켜 주는 것이 무엇 보다 중요하다 하겠다.


② 버퍼 오버플로우(Buffer overflow)


보안에 관심 있는 사람이라면 "버퍼 오버플로우"란 용어가 낯설지 않을 것이며, 그 중 적극적인 관리자라면 인터넷에 널려있는 다양한 버퍼 오버플로우 exploit(공격코드)을 다운로드 받아서 테스트도 해 봤을 것이다. 그 결과는 어떠했나? Exploit 코드가 지시하는 컴파일 옵션과 대상 서버가 적절했다면 손쉽게 root 권한을 획득했을 것이다. 물론 공격에 성공했다고 '버퍼 오버플로우"에 대해서 모든 것을 안다고 자신 있게 말할 수 있는 사람은 그리 많지 않을 것이다.

본 문서에서 "버퍼 오버플로우"의 A~Z까지를 설명할 필요는 없을 것이며(이미 뛰어난 문서들이 발표되어 있기 때문에) "버퍼 오버플로우"의 개념 이해를 목적으로 설명하겠다.

"버퍼 오버플로우"란?

말 그대로 버퍼를 넘치게(overflow) 하는 것을 의미하며, 풀어서 설명하면 메모리에 할당된 버퍼의 양을 초과하는 데이터를 입력하여 프로그램의 복귀 주소(return address)를 조작, 궁극적으로 해커가 원하는 코드를 실행하는 것이다. 여기에서 "버퍼(buffer)"란 프로그램 처리 과정에 필요한 데이터가 일시적으로 저장되는 공간으로 메모리의 스택(stack) 영역과 힙(heap) 영역이 여기에 속하며, "버퍼 오버플로우"가 이 두 가지 영역 중 어떤 것을 이용하느냐에 따라서 두 가지로 분류할 수 있다. 본 문서에서는 그 개념이 잘 알려져 있고 스택 기반의 버퍼 오버플로우에 초점을 맞춰서 설명하겠다. 이처럼 버퍼 오버플로우의 개념을 이해하기 위해서는 프로그래밍에 대한 기초 지식이 필요하며 이로 인하여 고급 해킹 기법으로 분류되고 있다.

"버퍼 오버플로우"의 역사

버퍼 오버플로우는 해킹 기법이 아닌 단순한 프로그램상의 문제로 처음 소개되었는데 1973년경 C언어의 데이터 무결성 문제로 그 개념이 처음 알려졌다.
이 후 1988년 모리스웜(Morris Worm)이 fingerd 버퍼 오버플로우를 이용했다는 것이 알려지면서 이 문제의 심각성이 인식되기 시작했으며, 1997년에는 온라인 보안잡지로 유명한 Phrack(7권 49호)에 Aleph One이 "Smashing The Stack For Fun And Profit"란 문서를 게재하면서 보다 널리 알려지게 됐다. 이 문서는 다양한 "버퍼 오버플로우" 공격을 유행시키는 계기가 됐으며 현재까지 해커 지망생들의 필독 문서로 자리잡아 오고 있다. 이후 "버퍼 오버플로우"는 SANS(www.sans.org)

에서 매년 발표하는 TOP20 공격기법 가운데 상당수를 차지하면서 해커들의 꾸준한 사랑을 받아오고 있다.


"버퍼 오버플로우"는 어떻게 이루어지는가?

버퍼 오버플로우의 정확한 동작원리를 이해하기 위해서는 프로그램에 의해 데이터가 어떻게 저장되는가를 우선 이해해야 한다. 하나의 프로그램은 수많은 서브 루틴들로 구성되는데 이런 서브 루틴이 프로그램에 의해 호출될 때, 함수 변수와 서브 루틴의 복귀 주소(return address) 포인터를 스택(stack)이라는 논리적 데이터 구조에 저장하게 된다. 스택은 실행중인 프로그램이 필요로 하는 정보를 저장하는 메모리 영역이다. 서브 루틴이 종료될 때 운영체제는 그것을 호출한 프로그램에 제어권을 반환해야 하기 때문에, 복귀 포인터를 통해서 프로그램이 서브 루틴의 실행을 마치고 나서 되돌아갈 주소를 가리키게 된다.

버퍼는 할당된 메모리 공간의 높은 주소에서 낮은 주소로 채워지며, 스택 영역에 마지막으로 들어가 데이터가 제일 먼저 빠져 나오는 LIFO(Last in, First out) 특정을 가지고 있다. 이런 LIFO 특성에 의해 가장 먼저 들어가 것(복귀 포인터)이 스택에서 가장 나중에 제거된다는 것을 기억해야 한다. 서브 루틴이 실행을 마치면 가장 나중에 행해지는 것은 복귀 포인터를 스택에서 제거하여 서브 루틴을 호출한 함수로 반환하는 것인데, 만약 이 포인터가 사용되지 않는다면 서브 루틴이 실행을 마쳤을 때 프로그램은 더 이상 어디로 진행해야 할지를 알 수 없을 것이다.

포인터(pointer)는 메모리의 위치를 저장하는 변수이다. 프로그램 실행을 위한 목적으로 다른 코드로 이동할 때 어디에서 떠났는지를 기억하기 위해 포인터를 사용해야 하며, 만약 포인터를 사용하지 않는다면 서브 루틴의 실행이 끝나고 어디로 돌아와야 할지를 알 수 없을 것이다.

이 제 스택을 조작하게 되면 어떤 일이 일어나는지를 살펴 보겠다. 프로그램이 변수의 할당된 공간에 저장될 데이터의 크기를 검사하지 않고 크기에 제한을 두지 않는다면, 변수 공간은 넘치게 될 것이다. 즉, 버퍼에 오버플로우가 발생하면 저장된 데이터는 인접한 변수 영역도 침범할 것이며 결국에는 포인터 영역까지 침범하게 될 것이다. 해커는 이러한 데이터의 길이와 내용을 적절히 조정함으로써 버퍼 오버플로우를 일으키고 운영체제의 스택을 붕괴시켜 특정 코드가 실행되도록 한다. 해커가 보낸 데이터는 대개의 경우 특정 시스템에서 실행될 수 있는 기계어 코드와 복귀 포인터에 저장될 새로운 주소로 구성되어 있으며, 복귀 포인터에 저장될 새로운 주소는 다시 메모리의 스택 영역을 가리켜서 프로그램이 서브 루틴에서 반환될 때 해커가 작성한 명령어를 실행하게 되는 것이다.

이때 고려해야 할 것은 공격 대상이 되는 프로그램이 무엇이든 간에 해커가 공격 코드는 프로그램이 실행되고 있는 권한으로 실행될 것이라는 점이다. 따라서 해커는 공격을 성공시켰을 경우에 시스템에 대한 최상위 권한을 얻기 위해, root 또는 administrator 권한으로 실행 중인 프로그램을 공격 대상으로 삼을 것이다.

이론상으로는 매우 직관적인 것 같지만 실제로 이 공격을 실행하는 것은 간단한 작업이 아니다. 하지만 이런 과정이 어떻게 이뤄지는지 제대로 이해하지 못 하는 스크립트 키디(script kiddie)도 쉽게 공개된 공격 코드를 이용하여 버퍼 오버플로우 공격을 시도할 수 있으니 보안 관리자들에게 보다 많은 업무를 주는 상황이라고 할 수 있다.


"버퍼 오버플로우" 취약성이 많은 이유는?

많은 프로그램이 취약성을 갖는 중요한 이유는 오류 검사를 제대로 수행하지 않기 때문이다. 오류 검사를 수행하지 않는 큰 이유 중의 하나는 개발자가 근거 없는 특수한 가정을 하기 때문이며, 정상적인 환경에서 변수에 할당된 메모리의 크기가 충분하다고 과신하는 것도 문제가 된다. 취약한 프로그램일지라도 사용자들이 올바르게 사용하여 발표된 지 수 년이 지나도 아무런 문제 없이 동작해온 경우도 있다. 그러던 중 누군가가 갑자기 "만일 프로그램에 원래와 다른 종류의 정보를 넣으면 어떤 일이 생길까?", "프로그램에 기대되는 크기보다 더 많은 데이터를 넣으면 어떤 일이 일어날까?"하는 식의 궁금증을 갖게 되었고 오류 검사를 수행하지 않는 프로그램들은 그런 궁금증의 실험대상이 되어 해킹의 목표가 되고 있다.

이 글을 마무리하며

"버퍼 오버플로우" 공격은 취약한 프로그램을 대상으로 공격자가 원하는 코드를 실행시킬 수 있다는 측면에서 매우 위험하며, 그 결과로 얻는 피해 범위는 시스템을 중지시키는 것에서부터 관리자 권한을 얻는 것까지 다양하다.
보 안 관리자는 "버퍼 오버플로우"가 어떻게 동작하는지 이해하고, 평상시에 벤더에서 제공하는 소프트웨어 관련 패치 적용, 최소 권한으로의 프로그램 실행, 불필요한 서비스 제거, 침입차단시스템을 통한 유해 트래픽 차단을 통해 공격 피해 가능성을 최소화해야 한다.
오늘 아무런 문제가 없었다 하더라고 내일 역시 안전할 것이라는 맹신을 버려야 한다. 지금 이 시간에도 지구 저편에서는 열심히 공격코드를 테스트하는 누군가가 있을 테니까….


③ 웹 애플리케이션 해킹 (Web Application Hacking)


최근까지 주류를 이루던 해킹은 운영체제나 프로토콜 설계상의 버그, 또는 개발자들의 본래 의도와는 다르게 보안상 심각한 결과가 초래될 있는 취약성들을 이용한 기법들이 대부분이었다. 전문 해커들에 의해 익스플로잇(해킹 코드)이 발표될 때 까지는 해킹 지식이 적은 사람(Script Kiddy)들에 의해 무분별하게 악용될 가능성은 적었지만 일단 발표가 되고 나면 쉽게 악용되어 취약한 시스템을 운영하는 기업이나 기관에 많은 악영향을 미쳐왔다. 그러나 이러한 취약성들은 패치를 적용하고 구성 설정을 변경하거나 외부로부터의 접근을 적절히 통제할 수 있는 보안 솔루션(라우터, 방화벽 등)에 의해 비교적 쉽게 해결이 가능했다.

최근 해킹의 화두는 웹 애플리케이션의 취약성을 이용하는 것이다. 그러한 이유를 위에서 언급된 내용을 토대로 말하자면 요즘 대부분의 기업이나 기관들은 시스템의 패치나 구성설정 변경을 제대로 하고 있지 못하더라도 접근 통제 솔루션을 하나 이상은 갖추고 있어서 외부로부터 유입되는 부적절한 접근으로부터 내부의 시스템을 보호할 수 있는 장치를 마련하고 있다. 그러나 이러한 솔루션이 갖추어져 있더라도 필수 불가결하게 서비스해야 하는 것이 바로 웹 서비스이다. 접근 통제 솔루션은 웹 서비스로 접근하는 패킷을 통제하지 않고 내부로 유입시키기 때문에 만약 통과되는 패킷에 악의적으로 패킷을 조작해서 보낸다면 정상 패킷으로 간주하여 적절한 통제를 하지 못하게 된다.


[그림 1] 최근 해킹 경향(발췌: SPI Dynamics)


이러한 배경을 토대로 이제까지 발표되어 악용되었던 웹 애플리케이션 취약성 유형을 크게 10가지로 나눌 수 있는데 이번 호에는 그 중 3 가지 취약성에 대해 설명하고 간략하게나마 취약성을 예방할 수 있는 방법을 소개하겠다. 좀더 자세한 내용을 원한다면 코코넛 시큐리티 레터 8월호의 참고 자료를 참조하면 된다.

  • 검증되지 않은 파라미터의 허용(Unvalidated Parameters)
  • 부적절한 접근 통제(Broken Access Control)
  • 부적절한 계정과 세션 관리(Broken Account and Session Management)
  • 크로스 사이트 스크립팅 허점(Cross-Site Scripting(XSS) Flaws)
  • 버퍼 오버플로우(Buffer Overflows)
  • 시스템 명령어 삽입 허용(Command Injection Flaws)
  • 잘못된 오류 처리(Error Handling Problems)
  • 안전하지 않은 암호화 메커니즘 사용(Insecure Use of Cryptography)
  • 원격 관리 허점(Remote Administration Flaws)
  • 웹과 애플리케이션 서버의 구성 설정상의 오류(Web and Application Server Misconfiguration)

  • 1. 검증되지 않은 파라미터의 허용(Unvalidated Parameters)

    클 라이언트로부터 웹 애플리케이션이 요청을 받았을 때 그 요청이 적절한 값인지 여부를 검증하지 않음으로 인해 백엔드에 존재하는 허가되지 않은 자원에 접근할 수 있는 취약성이다. url, 쿼리 문, HTTP 헤더, 폼 필드, 쿠키, 그리고 숨겨진 필드 등의 웹 요청(HTTP request) 들을 강제로 브라우징 한다거나 명령어 삽입, SQL 문 삽입, 쿠키 위/변조등을 통해서 보안 메커니즘을 우회할 수 있게 된다.

    [예방 방법]

    웹 요청에 대한 잘못된 예외 규칙을 다음과 같이 정하여 소스 코드에서 철저하게 검증을 하는 것이다.

    - 데이터 형식(문자, 정수, 실수 등)
    - 허용되는 문자셋
    - 최소, 최대 허용 길이
    - NULL 값의 허용 여부
    - 파라미터의 허용 여부
    - 허용되는 숫자 범위
    - 정규 표현식 등


    2. 부적절한 접근 통제(Broken Access Control)

    인 증되지 않은 사용자가 시스템에 접근하여 중요한 파일 읽거나 권한 없는 기능들을 수행할 수 있는 취약성이다. 예를 들자면 허가되지 않은 사용자가 웹 요청을 통해서 유닉스 시스템의 /etc/passwd 파일을 읽거나 윈도우 시스템의 웹 루트 디렉터리를 읽을 수 있는 등의 경로 유출(Path Traversal)을 허용하는 것이다. 이러한 취약성은 웹 컨텐츠와 기능에 적절한 접근 통제를 하지 못하는 것이 원인이다.

    [예방 방법]

    다음과 같은 접근 통제를 점검한다.

    - 안전하지 않은 ID 점검
    - 절대 경로를 통한 인증 회피 가능 점검
    - Path Traversal 가능 점검
    - 웹 컨텐츠의 퍼미션 점검
    - 클라이언트 측의 케싱 점검


    3. 부적절한 계정과 세션 관리(Broken Account and Session Management)

    계정에 대한 증명(Account Credential)

    과 세션 토큰이 적절히 보호되지 못함으로 인해 패스워드나 키, 세션 쿠키, 그리고 다른 토큰 등을 악용하여 인증 메커니즘을 무력화 시키거나 다른 사용자의 아이디를 추측할 수 있는 취약성이다. 예를 들자면 사용자의 패스워드 변경, 패스워드 분실, 사용자 정보 수정 등을 포함하는 증명서와 동적 세션 관리가 적절히 개발되지 않아서 다른 사용자에 의해 추측되거나 가로채기를 당하는 것이다.

    [예방방법]

    다음과 같은 항목들에 대해 보안 정책을 강화한다.

    - 패스워드 변경 통제
    - 패스워드 복잡성
    - 패스워드 저장
    - 전송 중인 증명서 보호
    - 세션 아이디 보호
    - 계정 목록
    - 신뢰 관계
    - 백엔드 인증


    ④ 스프핑 공격(spoofing attack)


    우리는 스파이 첩보 영화에서 주인공이 자신을 노출시키지 않기 위해 남의 신분으로 위장하는 경우를 자주 볼 수 있다. 이때 주로 사용하는 방법이 주민등록증, 운전면허증 등의 신분증을 위조하거나 신체적인 특징인 얼굴, 지문, 목소리 등을 변조하는 것이다. 이 모든 것들이 특정 사람을 인식하는 방법을 우회 통과하기 위한 방법이다.

    마찬가지 로 네트워크 상에서도 악의적인 혹은 비밀스러운 활동을 시도하려는 사람들은 먼저 자기 자신을 감추는 방법을 생각하게 된다. 다만 네트워크 상에서 해당 사용자(혹은 해당 호스트)를 식별하는 정보는 IP 주소, DNS 이름, Mac 주소, 이메일 주소 등을 사용한다.

    스프핑 공격(Spoofing Attack)은 바로 자기 자신의 식별 정보를 속여 다른 대상 시스템을 공격하는 기법이다. 네트워크 상의 공격자는 TCP/IP 프로토콜 상의 취약성을 기반으로 해킹 시도시 자신의 시스템 정보(IP 주소, DNS 이름, Mac 주소 등)를 위장하여 감춤으로써 역추적이 어렵게 만든다. 이러한 스프핑 공격은 패킷 스니퍼링이나 서비스 거부 공격, 세션 하이재킹(Session Hijacking)
    등의 다른 여러가지 공격을 수행 가능하게 한다.


    이번 회에서는 스프핑 공격의 종류를 알아보고, 해당 공격이 어떤 것인지 간략하게 알아보도록 하겠다. 스프핑 공격의 종류를 알아보면 다음과 같다. 어떤 정보를 속이느냐에 따라 세분화될 수 있다.

    스프핑 공격의 종류
    ① IP 스프핑
    ② APR 스프핑
    ③ 이메일 스프핑
    ④ DNS 스프핑

     


    ① IP 스프핑

    IP 스프핑은 말 그대로 IP 정보를 속여서 다른 시스템을 공격하는 것이다. IP 스프핑을 통해 서비스 거부 공격(TCP Syn flooding, UDP flooding, ICMP flooding)을 수행할 수도 있으며, 공격대상 컴퓨터와 서버 사이의 연결된 세션에 대해서 세션 끊기도 가능하다. TCP/IP 상의 프로토콜 취약성은 1985년 Robert T. Morris의 논문 “A Weakness in the 4.2 BSD Unix TCP/IP Software”에 업급이 되었으며, 특히 희대의 해커 케빈미트닉은 실제 해킹에서 IP 스프핑 공격을 통해 모토롤러, 선마이크로시스템즈, NEC, 노벨 등의 컴퓨터 전산망에 침투, 소프트웨어 및 각종 자료 등을 훔친 혐의로 1995년 체포되었다.

    케빈 미트닉은 정확하게는 TCP Syn flooding + TCP 순서 번호 예측(TCP Sequence Nubmer Guessing)

    + IP 스프핑을 사용하였다. 이는 클라이언트와 서버와의 통신 사이에 해커 컴퓨터가 끼어들어 클라이언트를 TCP Syn flooding 서비스 거부 공격으로 전혀 반응하지 못하게 한 후, 해커가 이 클라이언트인 것으로 가장하여 서버와 통신하는 기법이다. 이러한 공격은 TCP/IP 프로토콜의 문제점인 TCP 순서 번호 생성이 매초당 일정하게 증가한다는 것과 호스트에 대한 인증시 IP의 소스 주소만을 사용한다는 것으로 인하여 가능하였다.

    순 서 번호는 연결 지향형 프로토콜인 TCP 프로토콜에서 두 호스트 간의 패킷 전달이 손실 없이 이루어졌는지 체크하기 위한 일종의 패킷 번호표이다. 해커는 일단 클라이언트를 TCP Syn flooding 공격으로 봉쇄한다. 이후 서버의 순서번호를 예측하여 IP 스프핑된 위조 패킷을 발송함으로써 서버를 속여 침투하는 것이다. IP 기반의 인증만을 제공하는 Unix의 rlogin, rsh 등의 r 계열 서비스들은 이러한 IP 스프핑 공격에 취약할 수 밖에 없다.


    ② APR 스프핑

    ARP 프로토콜은 32bit IP 주소를 48bit의 네트워크 카드 주소(Mac Address)로 대응시켜 주는 프로토콜이다. 우리가 실제로 IP 주소를 통해 네트워크 연결을 시도하면 TCP/IP에서는 해당 IP에 해당하는 네트워크 카드 주소를 찾아 연결하게 된다. 이러한 IP 주소와 네트워크 카드 주소의 대응 테이블은 스위치나 기타 네트워크 장비 및 사용자 컴퓨터에서 arp cache 테이블이라는 곳에 위치하게 된다.

    해커가 이 테이블 상의 정보를 위조하게 되면 공격 대상 컴퓨터와 서버 사이의 트래픽을 해커 자신의 컴퓨터로 우회시킬 수 있다. 우회된 트래픽으로부터 해커는 패스워드 정보 등 유용한 정보를 마음껏 획득할 수 있다.

    ③ 이메일 스프핑

    이 메일 발송시 송신자의 주소를 위조하는 것이다. 간단한 방법으로는 이메일 송신자 From 필드에 별칭(alias) 필드를 사용할 수 있다. 이메일 발송시 별칭을 설정한 경우에는 별칭 주소로 이메일이 발송된다. 이러한 경우 메일을 받아보는 사람은 실제 이메일 송신자가 아닌 별칭 필드만을 확인하는 경우에는 이메일의 송신자가 별칭 필드에서 온 것으로 알게 된다.

    요즘 들어서 극성인 대량의 스팸 메일과 바이러스 감염 메일은 송신자의 주소가 아예 존재하지 않는 이메일 주소를 사용한다. 또한 이메일을 발송한 메일 서버 또한 직접적인 메일 발송 서버가 아닌 중계 서버이므로 메일을 발송한 자를 추적하기란 쉽지 않다.

    ④ DNS 스프핑

    DNS 프로토콜은 인터넷 연결시 도메인 주소를 실제 IP 주소로 대응시켜 주는 프로토콜이다. 인터넷 연결시 사용하는 DNS 서버가 IP 주소를 찾아달라는 요청을 받았을 때, 자기 자신의 도메인이 아닌 주소에 대해서는 보다 상위 단의 DNS 서버로부터 재귀적(recursive)인 방식으로 IP 주소를 찾아 알려준다.

    만약 해커가 어떤 도메인의 DNS 컴퓨터를 장악하여 통제하고 있다면 최종적으로 얻어진 IP 주소는 원래 사용자가 찾아가고자 하였던 홈페이지가 아닌 다른 홈페이지로 연결되게 된다. 이는 요청을 발송했던 DNS와 응답을 주는 DNS 사이의 트래픽을 해커가 스니퍼링함으로써 Query ID라는 값을 통해 해커의 사이트 IP를 최종 응답으로 넘겨주도록 하는 것이다.

    사용자가 쇼핑몰을 이용하고자 하였다면 해커에 의해 조작된 홈페이지 내에서 자신의 아이디와 필드, 신용 카드 정보를 기입함으로써 개인 정보를 탈취당할 수 있다. 위와 같은 스프핑 공격들은 실제로 인터넷 상의 툴로써 공개가 되어 있으며 여러가지 다른 복합적인 공격과 같이 사용될 수 있다.

    그러나 각각의 공격 방법에 있어서 제약 및 전제 사항이 있으므로 모두 완벽하게 성공되지는 않는다. 스프핑 공격은 패킷 필터링 접근 제어와 IP 인증 기반 접근제어, 취약점 서비스 사용의 제거, 암호화 프로토콜의 사용을 통해서 방어가 가능하다. 인터넷 상에 떠돌아다니는 정보는 항상 안전한 것이 아니므로 스프핑 공격과 같은 것을 통해 언제라도 위조되었을 가능성도 있을 수 있음을 간과해서는 안되겠다.


    ⑤ 스니핑 (sniffing)


    스니핑 공격 도구들과 스니핑 방어에 대해 알아보도록 하겠다.

    스니핑 도구들

    OS 이름 설명
    Windows 기반 Ethereal UNIX 용 Ethereal을 Windows로 포팅한 것으로 오픈 소스
    Windump Tcpdump를 Windows 용으로 포팅한 것.
    NAI Sniffer 스니핑 뿐 아니라, 다양한 통계 기능 등 제공(상용)
    EtherPeek 스니핑 뿐 아니라, 다양한 통계 기능 등 제공(상용)
    AiroPeek EtherPeek를 제조한 WildPackets 사의 제품으로 무선 네트워크 상의 스니핑 도구(상용)
    Cain&Abel 스니핑 기능 외에도 패스워드 크래킹 등 다양한 기능이 포함된 통합 툴. 스위칭 환경에서의 스니핑 및 각종 프로토콜에 대한 디코드 기능을 가지고 있음.(상용)
    UNIX 기반 tcpdump Command-line 툴로 해킹보다는 트러블슈팅의 용도로 가장 많이 사용되는 툴
    Ethereal GUI 기반으로 UNIX 용 GUI 스니핑 도구로서 매우 훌륭한 기능을 가지고 있음
    snoop Sun Solaris 시스템 등에서 기본적으로 제공하는 스니핑 도구
    Sniffit 연결된 세션 내용 정보 등을 쉽게 볼 수 있음
    AiroPeek EtherPeek를 제조한 WildPackets 사의 제품으로 무선 네트워크 상의 스니핑 도구(상용)
    dsniff 송덕준 (Dug Song)

    이 개발한 스위칭 환경에서의 해킹 도구. 스니핑 툴만 포함된 것이 아니라 SSH나 SSL에 대한 Man-in-the-Middle-Attack 툴이 포함되어 있음. 각종 프로토콜에 대한 사용자ID, 암호 정보를 쉽게 수집해 줌.

    LinSniff 각종 프로토콜에 대한 사용자 ID, 암호 정보를 쉽게 수집합니다만 dsniff보다는 적은 프로토콜을 지원합니다. 하지만 좀 더 가볍습니다.
    esniff Phrack Magazine에 소개된 툴
    ettercap 스위칭 환경에서의 스니핑 툴
    snmpsniff SNMP 전용 스니핑 툴

    스니핑에 취약한 프로토콜

    앞서 말한 바와 같이 일단 패킷을 악의적인 사용자가 가로채어 보는 것은 그리 어려운 일이 아니다. 이런 시도를 탐지하는 방법도 알려져 있기는 하지만 일단 이런 시도 자체를 완전 봉쇄하는 것은 불가능하다고 볼 수 있다.

    하 지만 이렇게 얻어낸 패킷이 모두 유용한 것은 아니며, 암호화되지 않거나 암호화되더라도 너무도 간단한 방법으로 되어 쉽게 복호화 해낼 수 있는 그런 프로토콜에서 사용되는 패킷이 공격자에 의해 사용될 수 있다. 그런 종류의 프로토콜을 스니핑에 취약한 프로토콜이라 할 수 있는데 스니핑에 취약한 프로토콜을 몇 가지 예로 든다.

    (1) Telnet, Rlogin

    Telnet, Rlogin의 사용자 ID, 패스워드를 비롯한 모든 통신의 내용은 암호화되지 않아 모든 통신 내용을 쉽게 볼 수 있다.

    (2) HTTP

    HTTP의 사용자 인증으로 많이 사용되는 Basic Authentication 방법은 아주 기본적인 방법으로 encode되기 때문에 쉽게 사용자 ID, 패스워드 정보를 얻어낼 수 있다.

    (3) SNMP

    SNMP 프로토콜은 단순 네트워크 관리 프로토콜(Simple Network Management Protocol)이라는 이름과 같이 보안을 거의 고려하지 않았다. SNMP 프로토콜은 SNMPv1, SNMPv2, SNMPv3로 나뉘어 뒤로 갈수록 보안은 강화되었지만 아직도 가장 많이 사용되는 것은 SNMPv1 프로토콜이다. SNMP의 패스워드와 같은 역할을 하는 커뮤니티 이름을 비롯한 모든 통신 내용이 암호화 되지 않는다.

    (4) 기타

    NNTP, POP, FTP, IMAP, SMTP 등


    스니핑의 방어

    스 위치에 브로드캐스트 도메인, MAC 주소 수동 설정 등을 함으로 패킷을 가로채는 시도를 줄일 수는 있으나 앞서 말한 바와 같이 다른 사용자가 패킷을 가로채는 시도를 원천 봉쇄하는 것은 불가능하다. 따라서 패킷을 가로채더라도 그것의 내용을 가지고 어떠한 행동조차 할 수 없도록 암호화 기법을 이용하는 것이 가장 일반적이고 중요한 스니핑의 방어 기법이라고 할 수 있다.

    (1) SSL 적용

    HTTP, IMAP, POP, SMTP, Telnet 등은 SSL을 적용하여 HTTPS, IMAPS, POPS, SMTPS, Telnets 등으로 할 수 있다. SSL은 물론 HTTP에 가장 많이 활용되며 이를 적용하여 사용자 이름, 패스워드 및 전자 상거래 결재 정보 등 웹 서핑의 내용을 암호화 할 수 있다.

    (2) PGP, S/MIME

    SMTP 상으로 보내지는 메일은 기본적으로 암호화 되지 않기 때문에 스니핑하여 그 내용을 쉽게 얻어낼 수 있다. PGP, S/MIME 등을 이용하여 메일에 대한 암호화 기능을 제공할 수 있다.

    (3) SSH

    암호화 통신을 제공하여 Telnet, FTP, RCP, Rlogin 등을 대치할 수 있다.

    (4) 사설망 혹은 가상사설망(VPN)

    스니핑이 우려되는 네트워크 상에 전용선(leased line)

    으로 직접 연결함으로 중간에 도청되는 것을 막는 것이 사설망이다. 하지만 이는 거리가 멀어질수록 인터넷을 이용하는 것에 비해 비용이 매우 비싸질 수 밖에 없다. 인터넷 회선을 이용하며 사설망의 효과를 줄 수 있는 것이 VPN입니다. VPN 장비 간의 암호화를 통해 도청을 막을 수 있다.


    결론

    스니핑은 다양한 형태로 네트워크 상에서 이루어질 수 있으며 다음과 같은 두 가지 단계로 볼 수 있다.

    - 패킷 가로채기
    - 가로챈 패킷 디코딩을 통해 주요 정보 획득

    패킷을 가로채는 시도는 차단하기 매우 어려우며 디코딩을 통해 주요 정보를 얻어내는 것을 막기 위해 SSL, SSH, VPN, PGP 등 다양한 기법이 이용될 수 있다.


    ⑥ 백도어와 트로이목마


    트로이 목마는 신화 속에 나오는 그리스와 트로이 사이의 전쟁에서 사용된 목마에서 유래된 것이다. 약 3,000여년전 그리스와 트로이 사이의 전쟁이 있었으며, 당시 세계의 패권을 노리는 강대국 그리스와 견고한 난공불락의 요새를 가지고 있는 트로이와의 전쟁은 서로에게 매우 힘에 겨운 싸움이었다.

    그리스는 무력으로 트로이를 점령할 수 없음을 알고 지혜와 모략으로 전쟁을 승리로 이끌었다. 이때 사용된 것이 난공불락의 요새를 공략하기 위해 만든 트로이 목마였다. 트로이 목마에 병력을 숨겨 전쟁에서 승리했던 것에서 바로 유래하여 그대로 그 말이 사용되고 있는 것이다.

    1. 백도어와 트로이 목마

    1) 백도어

    크 래커가 시스템에 침입한 후 자신이 원할 때 침입한 시스템을 재침입하거나 권한을 쉽게 획득하기 위하여 만들어 놓은 일종의 비밀 통로를 말한다. 이는 초기에는 주로 시스템에 문제가 생겼을 경우, 쉽게 시스템에 접속하기 위해서 시스템 관라자나 프로그래머등의 관리자가 의도적으로 만들어 놓은 비밀 통로였는데, 이후 크래커들에 의해 악의적인 목적으로 사용되고 있다.

    2)

    Trojan Horse

    호감이 가는 유용한 프로그램으로 가장하고, 실제적으로는 악의적인 프로그램이나 코드를 포함하고 있는 프로그램을 말한다. 이는 정상적인 동작을 하는 것으로 보이거나 사용자가 쓰는 프로그램등으로 사용자를 현혹시킴으로써 특권을 획득한다.

    2. 백도어와 트로이 목마의 차이점

    트 로이 목마의 경우, 특정 사용자 또는 프로그램이 실행에 의한 수동적인 방법에 의존한 것이며, 이는 사용자의 직간접적인 도움을 통해서 설치되거나 Bind되어진 프로그램이 실행되어 설치된다. 백도어의 경우 예전에는 관리의 목적으로 사용하기도 하였으나, 대부분 크래커들에 의해 권한이 획득된 후, 해당시스템에 추후 접속을 용이하게 하기 위하여 서비스 데몬 등을 수정하여 사용하고 있다.

    3. 백도어의 유형

    - 네트워크 데몬이나 시스템 유틸리티를 수정한 백도어
    - TCP/UDP프로토콜을 이용한 Shell binding 백도어
    - Kernel 모듈을 수정한 백도어
    - 방화벽을 우회하는 백도어

    4. 트로이 목마의 유형

    - 인터넷의 자료실이나 warez 사이트 등을 통한 정상적이고 유용한 프로그램, 불법적인 크랙파일 이나 누드 사진 등의 사용자의 관심을 끄는 프로그램에 바인드되어 네트워크를 통한 원격제어
    - Hidden Setuid shell
    - UDP Bind Shell

    4. 트로이 목마의 위험성

    최근 들어서도 웜바이러스, 트로이목마형 바이러스등이 많은 부분을 차지 하고 있음을 아래 그림에서 알 수 있다.


    [그림1] 2003년 침해사고 통계(참조 : CERTCC)


    [그림2] 2003년 침해사고 공격 수법별 통계(참조 : CERTCC)

    ⑦ HTTP Session Hijacking


    앞서 해킹기법에서 스니핑(sniffing)에 대해서 살펴보았다. telnet, ftp, pop3 등의 비암호화 프로토콜 어플리케이션은 스니핑 공격을 통하여 사용자 계정 및 암호 도용에 취약할 수 있음을 알게 되었다. 마찬가지로 우리가 웹 브라우징시 사용하는 HTTP 프로토콜도 이러한 도용에 취약할 수 있다.

    HTTP Session Hijacking(혹은 Session ID Hijacking)이라는 공격 기법은 웹 브라우징시 세션 관리를 위해 사용되는 Session ID를 스니핑이나 무작위 추측 공격(brute-force guessing)을 통해서 도용하는 기법이다. 먼저 이러한 공격에 대한 기초적인 배경지식으로 HTTP 프로토콜의 특성 및 Session ID에 대해 이해해보도록 하겠다.


    HTTP 프로토콜의 특성

    HTTP 는 기본적으로 비연결유지(stateless) 프로토콜이다. 반면, telnet과 ftp와 같은 프로토콜은 클라이언트와 서버 사이에 하나의 연결(session)이 성립되어 통신하는 프로토콜이다. 따라서, 우리가 보통 웹 브라우저를 열어 URL을 입력하고 해당 홈페이지에 들어간다는 것은 해당 홈페이지에 포함되어 있는 페이지(html), 그림(jpg, gif 등), 자바스크립트(js) 등을 다운받기 위해 개별적인 여러 개의 80 요청(request)을 발송한 후 서버로부터 각각의 응답(reply)
    을 받는 것을 의미한다.


    이러한 일련의 요청과 응답이 이루어진 후 해당 서버와의 통신은 다시 종료된다. 위와 같은 기본적인 지식을 알고 있다면 다음과 같은 질문을 할 수 있다. HTTP는 비연결유지 프로토콜이라고 하였는데 Session Hijacking 이란 공격은 어떻게 가능한 것인가? 이는 HTTP 세션 관리를 위해 사용되는 Session ID를 통해서 가능하다.


    Session ID란 무엇인가?

    웹 서버는 다수의 웹 페이지 요청자를 구별하기 위하여 각각의 사용자의 세션에 대해서 임의의 긴 문자열 값인 Session ID를 부여한다. 사용자가 홈페이지 방문시 혹은 인증 로그인시에 생성된다. 이러한 Session ID는 사용자의 계정, 암호, 그 밖의 IP 주소, timestamp 등의 여러 파라미터들을 조합하여 생성할 수 있다.


    Session ID는 사용자와 일련의 웹 서핑 동작을 연결시켜줌으로써 웹 사이트 로그인 후 다른 페이지 방문시마다 매번 로그인을 하지 않아도 되는 편리함을 제공해준다.

    우 리가 신문 홈페이지나 포털 사이트에 들어갈 때 광고 배너가 자동으로 바뀐다던지, 쇼핑몰이나 인터넷 서적몰에서 구매 카트의 목록이 유지되는 것은 모두 이러한 원리이다. 즉, Session ID를 통해 인증과 인가(authentication
    & authorization)라는 세션 관리를 수행할 수 있다.


    Session ID는 어디에 존재하는가?

    Session ID는 우리가 흔히 듣는 쿠키(cookie)라는 곳에 저장되는 것이 일반적이다. 그러나 가끔은 웹 브라우저 주소창 URL이나 HTML 페이지 폼 소스 상의 hidden 필드에 포함되어 드러나기도 한다.

    1)

    쿠키


    2)

    웹 브라우저 주소창의 URL


    3)

    웹 페이지 폼 소스 상의 hidden field



    Session ID의 취약성은 무엇인가?

    웹 서버에서의 Session ID 생성 기법 및 관리 기법에 따라서 다음과 같은 취약점이 존재할 수 있다.

  • 강력하지 못한 알고리즘(Weak Algorithm)

    : session ID 스트링 값을 생성함에 있어서 공격자가 reverse 엔지니어링이 가능한 쉬운 알고리즘으로 생성될 경우 cracking이나 brute-force guessing 공격의 위험이 있다.

  • 길이가 짧은 Session ID : 강력한 암호 알고리즘을 사용하더라도 그 길이가 충분하지 않고 짧은 경우에는 cracking이나 brute-force guessing 공격의 위험이 있다.

  • 계정 잠금 기능 미비 : 로그인 패스워드의 특정 회수 실패에 대해서는 보통 계정잠금 기능이나 해당 IP 차단 기능을 구현하고 있습니다. 그러나 보통 Session ID에 대한 무결성 침해나 특성 회수 실패에 대해서는 이러한 잠금 기능 구현이 미비하다. 따라서, brute-force guessing 공격의 위험이 있다.

  • 무한 만료의 Session ID : 사용자의 로그 아웃 이후에도 서버측에서 해당 세션 ID값을 폐기하지 않고 무한정 유효 인정한다면 cookie sniffing이나 프락시 서버의 로그 취득을 통하여 session ID 공격이 가능하다.

  • 평문으로 전달되는 Session ID : 서버에서 클라이언트로의 session ID 쿠키 전달 방식이 비암호화 방식일 경우에는 sniffing을 통하여 해당 값이 노출되어 공격 받을 수 있다. 특히 Session ID 값 자체가 사용자명이나 암호 등의 평문으로 구성되어 있는 경우에는 직접적인 공격이 가능하다.

    위와 같은 취약성에 대한 Session ID 공격의 유형은 다음과 같다.


    Session ID 공격유형

  • 직접적인 Cookie Sniffing을 통한 Session ID 도용
  • 간접 우회 공격을 통한 Session ID 도용
  • Brute-force guessing을 통한 Session ID 도용

    지금까지 Session ID가 무엇인지, 어떤 형태로 존재하는지, 왜 취약한지에 대해서 알아보았다. 다음에는 실제 공격 유형에 대해 살펴보고, 대응 방안에 대해서도 논의해 보도록 하겠다.


  • 출처 : 코코넛 시큐레터

    728x90

    댓글