[해킹 기법] ① 서비스 거부 공격
생활의 모든 부분에서 인터넷을 이용하고 있으며, 모든 것이 빠른 속도로 변해 가고 있다. 이런 점을 이용하여 인터넷을 통한 공격도 다양해져서 사용자들이 곤란에 빠지기도 한다. 그런데 이 기법이 나날이 고도로 지능화 되고, 순식간에 전 세계로 퍼질 수 있으므로, 각 기업 보안담당자들은 이런 현상에 대해 정확히 대비할 수 있는 지식을 갖추는데 좀 더 많은 노력을 기울여야 할 필요가 있다.
앞으로 약 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) 1
최근까지 주류를 이루던 해킹은 운영체제나 프로토콜 설계상의 버그, 또는 개발자들의 본래 의도와는 다르게 보안상 심각한 결과가 초래될 있는 취약성들을 이용한 기법들이 대부분이었다. 전문 해커들에 의해 익스플로잇(해킹 코드)이 발표될 때 까지는 해킹 지식이 적은 사람(Script Kiddy)들에 의해 무분별하게 악용될 가능성은 적었지만 일단 발표가 되고 나면 쉽게 악용되어 취약한 시스템을 운영하는 기업이나 기관에 많은 악영향을 미쳐왔다. 그러나 이러한 취약성들은 패치를 적용하고 구성 설정을 변경하거나 외부로부터의 접근을 적절히 통제할 수 있는 보안 솔루션(라우터, 방화벽 등)에 의해 비교적 쉽게 해결이 가능했다.
최근 해킹의 화두는 웹 애플리케이션의 취약성을 이용하는 것이다. 그러한 이유를 위에서 언급된 내용을 토대로 말하자면 요즘 대부분의 기업이나 기관들은 시스템의 패치나 구성설정 변경을 제대로 하고 있지 못하더라도 접근 통제 솔루션을 하나 이상은 갖추고 있어서 외부로부터 유입되는 부적절한 접근으로부터 내부의 시스템을 보호할 수 있는 장치를 마련하고 있다. 그러나 이러한 솔루션이 갖추어져 있더라도 필수 불가결하게 서비스해야 하는 것이 바로 웹 서비스이다. 접근 통제 솔루션은 웹 서비스로 접근하는 패킷을 통제하지 않고 내부로 유입시키기 때문에 만약 통과되는 패킷에 악의적으로 패킷을 조작해서 보낸다면 정상 패킷으로 간주하여 적절한 통제를 하지 못하게 된다.
이러한 배경을 토대로 이제까지 발표되어 악용되었던 웹 애플리케이션 취약성 유형을 크게 10가지로 나눌 수 있는데 이번 호에는 그 중 3 가지 취약성에 대해 설명하고 간략하게나마 취약성을 예방할 수 있는 방법을 소개하겠다. 좀더 자세한 내용을 원한다면 코코넛 시큐리티 레터 8월호의 참고 자료를 참조하면 된다.
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)과 세션 토큰이 적절히 보호되지 못함으로 인해 패스워드나 키, 세션 쿠키, 그리고 다른 토큰 등을 악용하여 인증 메커니즘을 무력화 시키거나 다른 사용자의 아이디를 추측할 수 있는 취약성이다. 예를 들자면 사용자의 패스워드 변경, 패스워드 분실, 사용자 정보 수정 등을 포함하는 증명서와 동적 세션 관리가 적절히 개발되지 않아서 다른 사용자에 의해 추측되거나 가로채기를 당하는 것이다.
[예방방법]
다음과 같은 항목들에 대해 보안 정책을 강화한다.
- 패스워드 변경 통제
- 패스워드 복잡성
- 패스워드 저장
- 전송 중인 증명서 보호
- 세션 아이디 보호
- 계정 목록
- 신뢰 관계
- 백엔드 인증
4. 크로스 사이트 스크립팅 허점(Cross-Site Scripting(XSS) Flaws)
Cross-site Scripting 취약점은 공격자가 웹 애플리케이션을 사용해서 다른 최종 사용자에게 자바스크립트와 같은 악성 데이터를 보낼 때 발생한다. 그 데이터는 클라이언트에서 실행되는 Java스크립트, VB스크립트, ActiveX, Flash등을 실행하는 코드들이 존재하게 된다. 최종 사용자들은 이렇게 악성 코드들이 포함된 웹 사이트의 링크를 클릭하거나 이메일에 포함된 내용을 읽거나 BBS에 게시된 게시물을 클릭하는 것만으로도 사용자의 환경 설정사항을 변경하거나, 쿠키(cookie)를 가로채고 잘못된 광고들 게시하는 등의 일들을 할 수 있다.
[예방 방법]
해당 취약점을 예방할 수 있는 최선의 방안은 모든 코드들을 상세히 검증하는 것이다. 즉, 헤더, 쿠키, 질의문, 폼 필드와 숨겨진 필드등과 같은 모든 파라미터들을 엄격한 규칙에 의해서 검증한다. 또한 다음과 같이 왼쪽의 필드의 입력 데이터를 오른쪽의 필드로 변환해서 필터링한다.
| From | To |
| < | & l t; |
| > | & g t; |
| ( | & # 4 0; |
| ) | & # 4 1; |
| # | & # 3 5; |
| & | & # 3 8; |
5. 버퍼 오버플로우(Buffer Overflows)
버퍼오버플로우의 자세한 내용은 코코넛 시큐레터 6월호의 "해킹기법 제2회 버퍼오버플로우"를 참조하기 바란다.
[예방 방법]
운영하고 있는 웹 서버 버전을 가장 최신버전으로 업그레이드 하거나 알려진 취약점을 제거할 수 있는 패치를 적용한다. 정기적으로 취약점 스케너를 통해서 취약점 여부를 점검하여 발견된 취약점에 대해서는 구성 설정을 변경하거나 패치를 적용하여 취약점을 제거한다.
6. 시스템 명령어 삽입 허용(Command Injection Flaws)
웹 애플리케이션에서 HTML 형식이나 쿠키, URL 파라미터 형식으로 시스템 명령어를 삽입 허용함으로써 웹 상에서도 시스템 명령을 실행할 수 있는 취약점이다. SQL 쿼리문을 삽입 허용하게 되면 DB인증 메커니즘을 무력화시켜서 중요한 데이터베이스 정보를 외부로 유출할 수 있다. 또한 데이터베이스의 DML(Data Manipulation Language), DDL(Data Definition Language) 언어가 모두 사용 가능하므로 데이터베이스의 유출뿐만이 아니라 무결성을 파괴할 수도 있다.
다음은 시스템 명령 삽입 허용 취약점을 악용할 수 있는 스크립트, 프로그래밍 언어의 함수들이다.
PHP
- require()
- include()
- eval()
- preg_replace() (/e 옵션과 함께 사용)
- exec()
- passthru()
- `` (backticks)
- system()
- popen()
Shell Scripts
- 모두 실행 가능
Perl
- open()
- sysopen()
- glob()
- system()
- '' (backticks)
- eval()
Java(Servlets, JSP s)
- System.* (특별히 System.Runtime)
C,C++
- system()
- exec**()
(strcpy strcat sprintf vsprintf gets strlen (특별히 null 바이트와 함께 사용될 경우) scanf() fscanf sscanf vscanf vsscanf vfscanf realpath getopt getpass streadd strecpy strtrns)
Python
- exec()
- eval()
- execfile()
- compile()
- input()
[예방 방법]
- 반드시 필요하다면 모든 시스템 명령을 사용하는 모든 사용자의 입력값을 점검한다.
- 점검되지 않은 사용자 입력을 시스템 명령으로 전달하지 않는다.
- 점검되지 않은 사용자 입력을 파이프(|)로 전달하지 않는다.
- 점검되지 않은 사용자 입력을 perl의 open() 명령으로 전달하지 않는다.
- 점검되지 않은 사용자 입력을 C 언어와 PHP의 popen() 명령으로 전달하지 않는다.
- 점검되지 않은 사용자 입력을 ``(backticks)과 함께 사용하지 않는다.
- 운영체제의 시스템 명령이 사용자 입력에 존재하는지 점검한다.
- 모든 웹 애플리케이션엔 쉘 스크립트를 허용하지 않는다.
7. 잘못된 오류 처리(Error Handling Problems)
적절하지 못한 오류 처리는 웹 사이트에서 다양한 보안 문제를 야기한다. 가장 보편적인 문제는 데이터베이스 덤프, 에러 코드등과 같은 상세한 내부 메시지들이 사용자에게 노출된다는 것이다. 이러한 정보들은 바로 악용 가능하지는 않지만 향후 발생할 수 있는 공격에 정보를 제공하게 된다. 이러한 문제를 야기하는 원인은 다음과 같다.
- 스크립팅 엔진의 설정 오류
- Servlet/JSP Runner의 설정 오류
- 웹 서버의 설정 오류
- 데이터베이스의 설정 오류
이러한 문제를 통해 유출될 수 있는 정보들은 다음과 같다.
- 애플리케이션의 흐름
- 추가적인 웹 서버 정보
- 데이터베이스 형식 및 버전
- 운영체제 형식 및 버전
- Scripting/Programming 언어의 형식 및 버전
- 물리적인 경로
- 변수 이름과 값
- 변수 형식
- 변수의 사용 목적
- 스크립트 소스 코드의 세그먼트
- SQL 쿼리의 세그먼트
- 데이터베이스와 테이블의 구조
[예방 방법]
웹 애플리케이션이 잘못된 요청을 받았을 때 자체 제작한 오류 페이지로 이동하도록 설정한다.
8. 안전하지 않은 암호화 메커니즘 사용(Insecure Use of Cryptography)
대부분의 웹 애플리케이션은 패스워드, 신용카드 번호, 계정 기록과 같은 중요한 정보나 데이터베이스를 저정하고 있기 때문에 암호화 기술을 이용하여 보호하고 있다. 이러한 암호화 기술이 웹 애플리케이션에 적용될 때 다음과 같은 구현상의 오류로 인하여 보안 허점들을 내포하게 된다.
- 안전하지 않은 키, 인증서와 패스워드 저장
- 적절하지 못한 메모리상의 기밀 저장
- 잘못된 난수 소스
- 중요 데이터 암호화 실패
- 새로운 암호화 알고리즘 개발 시도
- 암호화 키 변경과 같은 추가적인 지원 부재
[예방 방법]
이러한 취약점을 예방하기 위해서는 암호화 사용을 최소화 해야한다. 즉, 신용카드 번호와 그와 관련된 정보와 같이 중요하다고 판단되는 정보만을 암호화한다. 또한 저장된 암호화된 패스워드를 사용하는 대신 단방향 함수인 SHA-1과 같은 해쉬함수를 사용한다.
9. 원격 관리 허점(Remote Administration Flaws)
웹 애플리케이션을 관리하기 위해 강력한 기능을 갖는 원격 관리 도구들이 많이 존재한다. 그러한 기능들은 사용자들, 데이터, 그리고 웹 사이트의 컨텐츠들을 관리 가능하게 한다. 이러한 강력한 기능 때문에 원격 관리 도구들은 내/외부에서 공격자들의 주요 목표가 된다. 가장 일반적인 문제점은 원격 관리에 접근할 수 있는 강력한 인증 메커니즘이 갖춰져 있지 못한 이유로 인해 허가되지 않는 사용자에 의해서 웹 애플리케이션의 기밀성과 무결성, 그리고 가용성이 파괴될 수 있다.
[예방 방법]
ACL(Access Control List)을 이용하여 원격 관리 도구에 접근할 수 있는 대상을 엄격히 제한한다. 또한 VPN를 사용하여 관리자와 원격 관리 도구간에 암호화 통신을 한다.
아래 그림은 단계별 방어가 적용되기 전(그림 1)과 단계별 방어가 수립된 후(그림 2)의 네트워크 구성을 나타낸 것이다. 그림 2처럼 단계적으로 방어 대책이 수립된다면 관리자와 일반 사용자의 네트워크가 분리되며 시스템 용도별로 네트워크가 분리되어 단계별로 보안 대책이 수립되기 때문에 안전한 네트워크 운영이 가능하게 된다.
10. 웹과 애플리케이션 서버의 구성 설정상의 오류(Web and Application Server Misconfiguration)
웹 서버와 애플리케이션의 구성 설정은 보안 측면에서 중요한 의미를 가진다. 그러한 구성 설정들이 다음과 같은 여러 가지 요인들로 인해 보안 문제를 야기할 수 있다. 이러한 보안 문제들은 자동화된 스케닝 도구에 의해 공격자들에 의해 공격 당할 가능성이 매우 높다.
- 서버 소프트웨어에 있는 패치되지 않은 보안 취약점들
- 디렉터리 리스팅과 디렉터리 경로 유출을 허용하는 잘못된 서버 구성 설정
- 스크립트, 애플리케이션 환경 설정 파일과 웹 페이지가 포함된 불필요한 기본 파일, 백업 파일, 샘플 파일들
- 부적절한 파일, 디렉터리 권한 설정
- 컨턴츠 관리와 원격 관리가 가능한 불필요한 서비스 활성화
- 기본 패스워드로 설정된 기본 계정
- 관리와 디버깅 목적의 기능들
- 정보가 유출될 수 있는 잘못된 에러 처리
- 잘못 설정된 SSL 인증서와 암호화 설정
- 기본 인증서 사용 등
[예방 방법]
① 여러 보안 관련 사이트(SANS institute, OWASP, CERT)나 자료 등에 언급되어 있는 보안 가이드라인을 참고하여 다음과 같은 조치들을 취한다.
- 고려할 수 있는 모든 보안 메커니즘들 구성
- 모든 불필요한 서비스 중지
- 역할(roles), 퍼미션(permissions), 계정(accounts) 설정
- 로깅과 경고
② 1번과 같이 보안 가이드라인이 만들어졌다면 다음과 같은 작업들을 주기적으로 실시한다.
- 가장 최근에 발표된 보안 취약점 모니터링
- 가장 최신의 보안 패치 적용
- 보안 가이드라인의 업데이트
- 정기적인 내/외부 취약점 스캐닝
이 글을 마무리 하며
서두에도 언급했듯이 최근의 해킹 동향은 웹 애플리케이션을 이용한 해킹이 전체 피해 건수의 약 3/4를 상회하고 있다. 이러한 배경으로 인해 기업에서는 추가적인 보안 솔루션(웹 애플리케이션 취약점 스캐너, 웹 애플리케이션 방화벽 등)을 도입하고 있거나 도입 계획을 세우고 있다. 그러나 모든 보안이 그렇듯이 솔루션을 도입한다고 해결되는 것도 아니고 사람이 뛰어나다고 해결되는 것도 아니다.
도입된 솔루션이 제대로 운영되기 위해 끊임없이 관리자들은 노력해야 할 것이며 웹을 개발하는 개발자들은 만들어진 보안 가이드라인을 준수하여 개발해야 하며 일반 사용자들 또한 보안 가이드라인에 준하는 행동으로 발생할 수 있는 인지된 사고를 미연에 방지해야 한다. 이처럼 기업의 모든 구성요소들이 적절하게 조화를 이뤄 야지만이 투자된 비용만큼의 보안 수준을 유지할 수 있게 된다.
[참고 자료]
The Ten Most Critical Web Application Security Vulnerabilities (http://www.owasp.org/asac)
A Guide to Building Secure Web Applications (http://www.owasp.org)
Security at the Next Level (http://www.spidynamics.com/whitepapers.html)
Information Security (http://infosecuritymag.techtarget.com/2002/jun/insecurity.shtml)
CERT (http://www.cert.org)
SANS Institute (http://www.sans.org)
Hacking Exposed - Web Applications
[해킹기법] ④ 스프핑 공격(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) (1)
스니핑이란?
사전적인 의미로 스니핑(Sniffing)이란 ‘코를 킁킁거리다’, ‘냄새를 맡다’ 등의 뜻이 있다. 사전적인 의미와 같이 해킹 기법으로서 스니핑은 네트워크 상에서 자신이 아닌 다른 상대방들의 패킷 교환을 엿듣는 것을 의미한다. 간단히 말하여 네트워크 트래픽을 도청(eavesdropping)하는 과정을 스니핑이라고 할 수 있다. 이런 스니핑을 할 수 있도록 하는 도구를 스니퍼(Sniffer)라고 하며 스니퍼를 설치하는 과정은 전화기 도청 장치를 설치하는 과정에 비유될 수 있다.
TCP/IP 프로토콜은 학술적인 용도로 인터넷이 시작되기 이전부터 설계된 프로토콜이기 때문에 보안은 크게 고려하지 않고 시작되었다. 대표적으로 패킷에 대한 암호화, 인증 등을 고려하지 않았기 때문에 데이터 통신의 보안의 기본 요소 중 기밀성, 무결성 등을 보장할 수 없었다. 특히 스니핑은 보안의 기본 요소 중 기밀성을 해치는 공격 방법이다.
인터넷은 말 그대로 광범위한 네트워크이며 공개된 네트워크이다. 패킷이 송수신될 때, 패킷은 여러 개의 라우터를 거쳐서 지나가게 되며 중간 ISP 라우터에 접근 권한을 가지는 사람이라면 해당 패킷을 쉽게 잡아낼 수 있다. 그런데 문제는 이렇게 쉽게 얻어낼 수 있는 많은 패킷의 내용은 암호화 되지 않는다는 것이다.
물론 xDSL, 케이블 모뎀 등을 사용하는 일반 가정 사용자가 이러한 패킷을 아주 쉽게 볼 수 있는 것만은 아니다. 그러기 위해서는 패킷이 흘러가는 네트워크의 중간 경로를 얻어내야 한다. 전화에 도청기를 설치하는 과정을 연상하면 이해하기 쉬울 것이다. 직접 도청하고자 하는 전화기에 도청기를 설치하는 방법, 그리고 중계 회선에 도청기를 설치하는 방법이 있을 것이다.
두 가지의 차이는 직접 도청하고자 하는 전화기에 설치한다면 그 전화기의 내용만 도청할 수 있다는 것, 중계 회선에 설치한다면 그 중계 회선을 통해 연결된 모든 전화기의 내용을 도청할 수 있다는 것이 될텐데 스니핑 역시 마찬가지이다.
대표적인 시나리오는 다음과 같다.
(1) 다양한 공격 기법을 통해 실제 공격 대상 시스템에 관리자 권한을 얻어낸 후 스니핑 도구를 설치하여 스니핑
(2) 공격 대상 기업의 다른 호스트에 대한 접근 권한을 얻어내서 그 호스트를 이용하여 스니핑
(3) ISP 장비에 대한 시스템 권한을 얻어내어 스니핑 도구를 설치하여 스니핑
다음은 이러한 스니핑 기법을 통하여 FTP 접속을 스니핑함으로 사용자 ID와 패스워드를 얻어낸 화면이다. 이 경우, Ethereal이라는 툴을 이용한 것으로 쉽게 해당 서버에 hackme라는 peace! 패스워드를 사용하는 사용자가 존재한다는 사실을 알았다.
물론 스니핑은 이와 같은 공격만을 위해 사용되는 것은 아니다. 네트워크 트래픽 분석이나 트러블슈팅 등에 사용되며 그 외에도 네트워크 상에 이루어지는 공격을 탐지하는 침입탐지시스템에 쓰일 수 있다. 이 문서에서는 공격 기법으로서의 스니핑을 이야기하고자 한다.
실질적인 스니핑 공격의 예
(1) 허브 환경에서의 스니핑
허브(Hub)는 기본적으로 들어온 패킷에 대해 패킷이 들어온 포트를 제외한 모든 포트에 대해 패킷을 보내는 리피터(Repeater) 장비이다. 사실 여러분의 기업에서 허브를 사용하고 있고 여러분의 시스템이 그 허브에 연결되어 있다면 여러분은 원하던 원치 않던 간에 계속하여 다른 사람의 패킷들을 받아보고 있었던 것이다.
물론 네트워크 드라이버, OS 커널 등의 수준에서 MAC 주소를 보아 자신이 아닌 다른 이들의 패킷은 버려지기 때문에 그것을 쉽게 느낄 수는 없었을 것이다. 하지만 여러분 시스템의 NIC를 promiscuous 모드로 동작하게 한다면 다른 이들의 패킷 또한 버리지 않고 받아볼 수 있다. 이제 스니핑 도구를 통해 해당 패킷을 저장하고 분석하기만 하면 된다.
다음 그림은 이 내용을 설명한 것이다. 모든 패킷은 실제 수신 대상이 아닌 호스트에게도 전달되며 Promiscuous 모드로 동작하는 호스트는 다른 수신 대상의 패킷 또한 볼 수 있다.
[그림 1] 허브 환경에서의 패킷 송신
(2) 스위치 환경에서의 스니핑
스위치는 기본적으로 Layer 2 헤더 정보인 MAC 주소 정보를 이용하여 패킷이 어떤 목적지로 보내질지를 결정한다. 따라서 허브 환경에서와 달리 패킷은 실제 수신 대상에게만 보내지게 되며 공격 대상이 아무리 인터페이스를 Promiscuous 모드로 셋팅하였다 하더라도 그 내용을 훔쳐 볼 수는 없다.
[그림 2] 스위칭 환경에서의 패킷 송신
그렇다면 이 경우 정말 안전한 것일까… 아쉽게도 그렇지 않다. 이와 같이 스위치를 사용하는 스위칭 환경에서의 스니핑 기법이 공개되어 있다. 그 중 몇 가지 공격 기법은 다음 원고에서 소개를 하겠다.
[해킹기법] ⑤ 스니핑 (sniffing) (2)
지난 원고에 이어서 스위치를 사용하는 스위칭 환경에서의 스니핑 기법 중 몇가지 공격 기법에 대해 소개를 하도록 하겠다.
1) Switch Jamming
스위치는 원래 앞서 말한 바와 같이 실제 수신 대상으로만 패킷을 보내는 브리지 장비이다. 그러나 엉뚱한 MAC 주소를 가진 패킷을 계속하여 보냄으로써 스위치가 허브처럼 동작하도록 만들 수 있다. 많은 종류의 스위치가 주소 테이블이 가득 차게 되었을 때 패킷을 모든 포트로 브로드캐스팅하는 성질을 이용한 것이다.
2) ARP Redirect
대표적인 툴로 Dsniff와 같은 툴이 이 방법에 의한 스니핑을 제공한다. 네트워크 상에서 패킷이 보내질 때 목적지의 IP 주소를 갖고 해당 목적지가 어떤 MAC 주소를 사용하는지를 요청하는데 이를 ARP request라고 한다. 쉽게 말해서 교실에 선생님이 들어와서 '이 반에 코코넛이라는 학생이 누구인지 손들어 봐요' 하는 것과 같다.
ARP request는 네트워크 상에 브로드캐스팅되어 모든 호스트가 그 패킷을 받게 되고 해당 IP를 가진 호스트는 그런 IP를 사용하는 것은 나라고 ARP reply를 주게 된다. 코코넛 학생이 '저요!'하고 손드는 것과 마찬가지이다. 하지만 코코넛 학생 대신 오렌지라는 학생이 '저요!' 하고 손든다 해도… 그렇다. 순진한 선생님은 그대로 믿게 되는 것이다.
[그림 1] ARP request 과정
[그림 2] ARP reply 과정
하지만 공격자는 arpspoof 등의 툴을 이용하여 거짓된 ARP reply를 계속하여 보낼 수 있다.
[그림 3] 조작된 ARP reply 과정
위와 같은 경우 두 개의 Reply를 받게 된다. 이 경우, 패킷이 도달한 순서에 따라 그리고 구현에 따라 10.1.1.1의 응답 혹은 10.1.1.3의 응답을 믿게 될 것이다. 만약 10.1.1.3의 응답을 믿었다면 패킷은 10.1.1.1로 보내지는 것이 아니라 10.1.1.3으로 보내지게 될 것이다.
그런데 문제는 ARP Request가 오기 전에 ARP reply가 위와 같은 식으로 보내지게 되었을 때 공격 대상이 되는 시스템의 ARP cache에 그런 내용이 저장이 되고 ARP cache에 10.1.1.1에 대한 정보가 있다면 굳이 ARP request를 하지는 않는다는 것이다. 이 점을 이용하여 공격자는 위와 같은 거짓 응답을 주기적으로 계속하여 보내게 된다. 물론 ARP request가 있기 전부터...
10.1.1.1로 가게 될 패킷은 10.1.1.3으로 가게 된다. 물론 10.1.1.1 입장에서는 통신이 제대로 되지 않게 되므로 이런 시도를 금방 알아차릴 수 있을 것 같지만 10.1.1.3은 해당 패킷의 내용을 받고 저장한 후 바로 아무 일 없었다는 듯이 10.1.1.1로 포워딩하므로 통신에는 문제 없다.
공격 대상 시스템이 라우터였다면 치명적이다. LAN 상의 시스템이 인터넷으로 주고 받는 모든 패킷을 훔쳐 볼 수 있다는 것이다.이 방법에서 공격자는 10.1.1.1에 대한 ARP Reply를 속였기 때문에 이를 ARP Spoofing이라고 하기도 한다.
3) ICMP Redirect
Ping 프로그램을 사용할 때 ICMP Echo 메시지와 ICMP Echo Reply 메시지가 사용된다는 것은 많은 분이 알고 계실 것이다. 이처럼 ICMP 프로토콜은 네트워크 상의 오류 메시지 전송, 트러블슈팅 등을 위해 사용되는데 그 중 ICMP Redirect 메시지를 이용한 스니핑 방법이며 일단 기본적으로는 ARP Redirect의 경우와 마찬가지로 공격 대상 시스템으로 패킷이 오도록 만드는 것이다.
네트워크 상에 라우터가 여러 대 존재할 때 비효율적인 라우팅 경로가 존재한다면(즉 1 hop 만으로 보낼 수 있는데 3 hop으로 보내게 설정되었다든지) 라우터에 대해 이를 수정할 것을 권고하는 ICMP Redirect 메시지가 보내진다. 공격자는 이를 악용한 ICMP Redirect 메시지를 보냄으로써 패킷이 자신으로 보내지도록 한다.
4) ICMP Router Advertisement
ICMP Redirect와 비슷한 방법이나 ICMP Router Advertisement 메시지는 특정 호스트가 자신이 라우터라고 다른 호스트들에 대해 알리는 메시지이다. 공격자는 이를 악용하여 다른 호스트들이 자신을 라우터로 생각하게 하여 패킷이 자신으로 보내지도록 한다.
5) MAC 스푸핑
앞서 스위치는 기본적으로 MAC 주소를 통해 패킷이 어떤 목적지로 보내질지를 결정한다고 하였는데 이런 MAC 주소를 학습하는 방법은 다음과 같다. 특정 목적지 MAC 주소를 갖는 패킷을 보내고자 할 때,
① 해당 MAC 주소가 자신의 MAC 주소 테이블에 존재하는지 확인
② 존재한다면 테이블에 등록된 포트로 패킷을 보냄
③ 존재하지 않는다면 패킷이 유입된 VLAN과 동일한 모든 VLAN으로 패킷을 일단은 보냄
그리고 MAC 주소 테이블을 갱신하는 방법은 패킷이 유입되었을 때, 해당 패킷의 출발지 MAC 주소를 참고하여 해당 패킷이 들어오게 된 포트와 MAC 주소 정보를 테이블에 등록하는 방법으로 한다.
따라서 위와 같은 경우 응답으로 패킷이 오게 되면 MAC 주소 테이블에 해당 정보가 입력되어 다음부터는 응답이 오게 된 포트로 보내게 된다. 그러나 공격자가 공격 대상 시스템의 MAC 주소를 가지는 패킷을 출발지 MAC 주소로 하는 패킷을 계속하여 보내면 스위치의 MAC 주소 테이블에는 그러한 내용이 등록된다. 따라서 스위치는 패킷을 공격자에게 보내게 된다.
6) 스위치에서의 SPAN/Monitor port 설정
대다수의 스위치는 port monitoring 기능을 가지고 있는데, 이는 특정 포트(들)로 주고 받아지는 패킷을 또 다른 모니터 포트로 전송해주는 옵션이다. 공격자가 스위치에 접근 권한을 얻어내어 위와 같은 설정을 적용함으로 공격자 시스템에 연결된 포트로 보낼 수 있다.
이는 매우 어려운 일이 될 것 같지만 디폴트로 설정된 스위치의 경우에는 매우 쉬운 일이다. 왜냐하면 해당 스위치의 사용자 ID, 패스워드는 인터넷 검색 사이트를 통해 쉽게 얻어낼 수 있기 때문이다.
[해킹기법] ⑤ 스니핑 (sniffing) (3)
스니핑 기법의 최종편인 (3)편에서는 스니핑 공격 도구들과 스니핑 방어에 대해 알아보도록 하겠다.
스니핑 도구들
| 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 등 다양한 기법이 이용될 수 있다.
[해킹기법] ⑥ 백도어와 트로이목마 (1)
트로이 목마는 신화 속에 나오는 그리스와 트로이 사이의 전쟁에서 사용된 목마에서 유래된 것이다. 약 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)
[해킹기법] ⑥ 백도어와 트로이목마 (2)
1. UNIX 시스템
1) 패스워드 크래킹 백도어
가장 고전적인 침입 방법으로 백도어들은 패스워드 크래커를 실행하여 취약한 패스워드를 가진 계정을 알아 내고, 이 계정의 패스워드를 어려운 계정으로 바꾸어 버려 취약한 패스워드를 찾아 변경할 수 없는 상태로 만든다.
2) Rhosts + + 백도어
네트워크에 연결된 유닉스 시스템에서 사용 편의성 때문에 사용하고 있는 R Command(rsh,rlogin)등의 서비스를 많이 사용하는데 호스트 이름과 사용자 명에 대한 추가적인 패스워드를 묻지 않는 보안 취약성을 내재 하고 있어 이를 이용한 "rhosts" 파일에 파일에 "+ +"를 넣어 어떤 호스트의 어떤 사용자라도 해당 사용자로 패스워드 없이 들어올 수 있도록 한다.
3) Checksum과 Timestamp 백도어
침입자들이 실행파일을 자신의 트로이목마 버전으로 교체시키는 경우가 있다. 많은 시스템 관리자들은 타임 스탬프와 유닉스의 sum 프로그램 등과 같은 체크섬 값에 의해 실행파일의 변경유무를 진단할 수 있다. 하지만 트로이목마 프로그램의 타임 스탬프를 원래 파일의 타임 스탬프 값으로 생성시킬 수 있고, CRC 체크섬 값도 원래의 체크섬 값으로 가장할 수 있다.
4) Login 백도어
유닉스 시스템에서 login 프로그램은 사용자가 텔넷을 통해 시스템에 접속할 경우 패스워드 인증을 수행한다. 침입자들은 login.c 프로그램을 수정하여 특정한 백도어 패스워드가 입력될 경우 관리자가 어떤 패스워드를 설정해 놓든지에 상관없이 로그인을 허용하고, utmp나 wtmp와 같은 로그파일에 기록도 하지 않도록 한다.
침입자는 침입한 흔적을 남기지 않고 시스템에 로그인하여 쉘을 획득할 수 있다. 시스템 관리자는 "strings"라는 명령어를 사용하여 login 실행 프로그램에 백도어 패스워드의 유무를 점검하기도 하지만, 침입자들은 백도어 패스워드를 암호화하여 저장함으로써 이러한 명령어에 의한 발견을 피할 수 있다.
5) Telnetd 백도어
사용자가 시스템에 텔넷 접속을 할때, inetd 서비스가 그 포트를 리슨하고 있다가 in.telnetd에 연결시켜 주고, in.telnetd는 login 프로그램을 구동한다. ( in.telnetd를 수정하는 경우도 있다.) 침입자는 터미널 종류가 "letmein" 등 특수하게 설정되어 있을 경우 인증과정 없이 쉘을 부여하도록 in.telnetd를 수정할 수 있다. 침입자는 어떤 서비스에 백도어를 설치하여 특정 소스 포트로 부터 오는 연결에 대해서는 쉘을 부여하도록 할수 있다.
6) Services 백도어
대부분의 네트워크 서비스들 즉, finger, rsh, rexec, rlogin, ftp 심지어 inetd 등은 백도어 버전이 존재한다. 이 프로그램들은 uucp와 같이 전혀 사용되지 않는 서비스를 백도어 프로그램으로 교체하여 inetd.conf 파일에 등록하는 경우도 있다.
7) Cronjob 백도어
침입자는 백도어 쉘 프로그램을 cronjob에 추가하여 특정 시간에 구동 되도록 할 경우 이 시간 동안 침입자는 시스템에 접속 할 수 있다. 침입자는 cronjob에서 전형적으로 구동되는 합법적인 프로그램인 것처럼 가장한다.
8) Library 백도어
대부분의 유닉스 시스템에서는 공유 라이브러리를 사용한다. 공유 라이브러리는 같은 루틴들을 재사용하여 프로그램의 크기를 줄이기 위해 사용한다. 어떤 침입자들은 crypt.c나 _crypt.c 프로그램 같은 루틴들에 백도어 프로그램을 넣어 두기도 한다. login.c는 crypt() 루틴을 사용하게 되는데 백도어 패스워드가 사용될 경우 바로 쉘을 부여하게 된다.
9) Kernel 백도어
Library에서 사용되었던 같은 방법으로 MD5 체크섬을 우회할 수 있으며 이 백도어가 설치된 커널은 관리자가 찾기 가장 어려운 백도어일 것이다. 다행히 커널 백도어 스크립트들은 널리 쓰이고 있지는 않지만 아무도 실제 얼마나 배포되어 쓰이고 있는지 모른다.
10) 파일 시스템 백도어
침입자는 특정 디렉토리나 특정 파일을 숨기기 위해 "ls", "du" 그리고 "fsck"와 같은 시스템 명령어들을 수정한다. 그렇지 않으면, 숨기려는 부분을 "bad" 섹트로 보이게 하고, 침입자는 숨겨진 파일을 오직 특수한 도구를 통해서만 보이게 할 수도 있다.
11) Bootblock 백도어
일반 PC에서는 바이러스가 bootblock에 자신을 숨기고 대부분의 바이러스 백신은 bootblock이 바뀌어졌는지를 감시한다. 유닉스 시스템에서는 부트 블록을 점검할 수 있는 소프트웨어가 거의 없어, 침입자들이 부트 블럭 공간에 백도어를 숨겨두기도 한다.
12) 프로세스 은닉 백도어
침입자들은 자신들이 설치하여 실행중인 프로그램들 숨기려고 한다. 일반적으로 스니퍼 프로그램이나 키로거, 패스워드 크랙 프로그램과 같은 것들을 보이지 않도록 한다.
13) 네트워크 트래픽 백도어(Network traffic backdoors)
침입자들은 시스템에서 자신들의 흔적을 숨기려고 할 뿐더러 가능하면 자신들의 네트워크 트래픽까지 숨기기를 원한다. 이러한 네트워크 트래픽 백도어들은 간혹 침입차단시스템(firewall)을 거쳐서 침입할 수 있는 것들도 있다.
14) TCP 쉘 백도어
침입자는 침입차단시스템이 막지 않는 높은 TCP 포트에 TCP 쉘 백도어들을 설치할 수 있다. 관리자들은 netstat를 통해서 어느 포트들이 연결을 기다리고 있고, 어느 포트가 연결되어 있는지를 점검할 수 있다. 이러한 백도어들은 SMTP 포트 상에서 구동될 수도 있어, e-mail을 허용한 침입차단 시스템을 통과할 수 있다.
15) UDP 쉘 백도어
관리자들이 TCP 연결에 대해서는 관리를 잘하고 이상한 행위를 알아차리기가 쉽지만, UDP 쉘 백도어는 유닉스 시스템에 접속한 상태를 netstat 등으로 알기가 쉽지 않다. 많은 침입차단시스템에서 DNS 서비스등을 위해 UDP 패킷들을 허락하도록 설정되어 있어 침입자는 UDP 백도어를 설치하여 침입차단 시스템을 무사히 통과할 수 있다.
16) ICMP 쉘 백도어
많은 침입차단시스템들이 외부로부터 내부 시스템에 대한 ping을 허락한다. 침입자는 ping ICMP 패킷에 데이터를 추가하여 ping을 하고있는 시스템과 쉘을 제공받을 수 있도록 한다. 시스템 관리자는 다량의 ping 패킷들을 발견하겠지만 패킷 속의 데이터를 보지 않는 이상 침입 사실을 알수 없다.
17) 암호화된 링크
관리자가 스니퍼를 설치하여 쉘에 접근하려는 사람을 찾으려고 할 수 있다. 하지만 침입자는 네트워크 트래픽 백도어를 암호화하여 실제 두 시스템 간에 어떤 데이터가 전송되고 있는지를 숨길 수 있다.
2. Windows 시스템
1) BackOrifice
대표적인 트로이목마 프로그램이다. 백오리피스는 'Cult of Dead Cow(죽은 소에 대한 숭배)'라는 해커 그룹의 일원인 Sir Dystic이 제작 발표한 MS 윈도 95/98 및 윈도 NT 해킹 툴로, 마이크로소프트(MS) 네트워크 관리 프로그램 백오피스를 패러디해 붙여진 이름이다.
백오리피스는 MS Back Office와 마찬가지로 원격지에서 윈도용 PC의 모든 프로그램 파일을 관리할 수 있는 도구이기 때문에, 원격지에 있는 타인의 PC에 저장된 파일에의 접근은 물론이고 파일 삭제, 생성, 실행 등 PC 이용자 모르게 프로그램 및 파일에 대한 조작을 할 수 있다. 또한 실행 중인 프로그램의 제거 및 정지, 사용자 키보드 입력 자료의 모니터링, 현재 실행중인 화면캡처, 비밀번호 빼내기, 레지스트리 편집 등이 가능하다.
위와 같은 기능들을 수행하는 대표적인 트로이목마 프로그램으로는 SubSeven, Netbus, SchoolBus등으로 현재까지 많은 수의 프로그램이 존재 한다. 주요 트로이 목마의 사용 포트는 아래와 같다.
| 포트번호 | 트로이목마명 |
| 777 | AimSpy |
| 1080 | SubSeven 2.2, WinHole |
| 1243 | BackDoor-G, SubSeven |
| 5880 | Y3K RAT |
| 6000 | The Thing |
| 6666 | Dark Connection Inside, NetBus |
| 6667 | Dark FTP, ScheduleAgent, SubSeven, Subseven 2.1.4 DefCon 8, Trinity, WinSatan |
| 6669 | Host Control, Vampire |
| 9400 | InCommand |
| 12345 | Fat Bitch trojan, GabanBus, NetBus, NetBus Toy, Whack Job, X-bill |
| 20034 | NetBus 2 Pro, NetBus 2.0 Pro Hidden, NetRex, Whack Job |
| 21554 | GirlFriend, Exploiter, Kid Terror, Schwindler, Winsp00fer |
| 27374 | SubSeven, Bad Blood, Ttfloader, Webhead |
| 31337 | Netpatch, Back Orifice, Baron Night, BO client, BO spy |
| 50766 | Fore, Schwindler |
| 54321 | Backorifice 2000, School bus |
[해킹기법] ⑥ 백도어와 트로이목마 (3)
탐지 및 예방
백도어나 트로이목마를 탐지하는 것은 매우 많은 설정(변수)들이 있기 때문에 매우 어렵다. 이에 대한 권고책으로 네트웍 상에서의 공격을 인식하기 위한 침입탐지 소프트웨어와 취약점 검사(네트웍상의 시스템에 백오리피스가 설치되었는지를 탐지하기 위한)를 하는 업데이트된 백신 소프트웨어 버전을 사용해야 한다.
외부에서의 네트웍 연결시도뿐 아니라 시스템상에서 백도어 프로그램 출현을 탐지하는 것은 기존의 백신소프트웨어의 한계를 넘어섬에 따라 네트웍 취약점 및 침입탐지 가능성은 백도어 프로그램을 확인하여 제거 시키는데 있어 매우 중요하다.
사용자 및 관리자들은 다음과 같은 주의사항을 염두하여 컴퓨터 안전예방책을 취해야 한다.
1) 불법적인 사이트 방문 자제
- P2P , 와레즈 사이트 , 불법적인 자료, 외설 음란 자료 열람 자제
2) 바이러스 백신 프로그램 사용
- 지속적인 최신 버전 업그레이드(실시간 감시 설정)
3) 개인 방화벽(HOST Based IPS) 시스템 사용
- Zone Alarm, ISS Remote Desktop Protector 등 사용
4) 정품 S/W 사용
- KeyGen, Program Crack 프로그램 사용 금지
5) 비정상적인 실행 파일이나 첨부 파일 실행 금지
- 메일의 첨부물은 함부로 개봉하지 않음(EXE 등 파일 실행 금지)
- Internet Chat Systems로부터 실행 파일이나 링크를 열지 않음
- 인터넷, PC 통신 등을 통한 외부 소프트웨어 다운시 바이러스 진단
- 파일이나 폴더 공유시 쓰기 권한 제한
6) 네트워크 침입 탐지 시스템
- 침입탐지는 시스템에 대한 접속을 통제하는 것과 마찬가지로 중요하다. 예전의 대부분의 침입탐지 기술들은 로그를 기반으로 하였지만 최근의 침입탐지 기술은 실시간 스니핑과 네트워크 트래픽 보안 분석에 기반으로 하고 있다. 많은 네트워크 트래픽 백도어들을 쉽게 탐지할 수 있다.
7) 네트워크 침입 방지 시스템
- 침입탐지시스템에서 탐지된 알려진 트로이목마나 백도어 등의 시그네쳐 기반의 Blocking 설정
8) 침입 차단 시스템
- 잘 알려진 트로이목마나 백도어의 포트 설정
- 시스템 파일의 무결성 점검
- 트로이 목마와 백도어에 의한 불법적인 프로그램의 수정 및 변경 사실을 감시 하기 위해서는 파일 시스템의 무결성을 점검하는
도구의 필요
9) 무결성 점검 시스템
- Tripwire 등과 같은 시스템 무결성 도구를 사용한 시스템 파일의 변경 사실 감지
10) 취약점 점검 도구
- 네트워크 베이스, 호스트 베이스 취약점 점검 도구를 사용한 지속적인 점검을 통한 백도어 및 트로이 목마 사용 및 취약점 점검
실시
마지막으로, 새로운 취약성들이 매일 발표 되고 있고 침입자들이 새로운 공격기술과 백도어 기술을 만들어 가고 있기 때문에, 지속적으로 바이러스 백신을 업데이트하고 신뢰 하지 않는 사이트로부터의 다운로드 및 실행 하지 않는 등 주의를 기울이지 않는다면 어떠한 보안 기술도 효과적이지 못하다는 것을 명심하여야 한다.
[해킹기법] ⑦ HTTP Session Hijacking (1)
앞서 해킹기법에서 스니핑(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 생성 기법 및 관리 기법에 따라서 다음과 같은 취약점이 존재할 수 있다.
위와 같은 취약성에 대한 Session ID 공격의 유형은 다음과 같다.
Session ID 공격유형
지금까지 Session ID가 무엇인지, 어떤 형태로 존재하는지, 왜 취약한지에 대해서 알아보았다. 다음에는 실제 공격 유형에 대해 살펴보고, 대응 방안에 대해서도 논의해 보도록 하겠다.
[해킹기법] ⑦ HTTP Session Hijacking (2)
지난 회에서 기본적으로 Session ID가 무엇인지, 어떤 형태로 존재하는지, 왜 취약한지에 대해서 설명했다. 이번 회에는 취약한 Session ID에 대한 공격이 어떤 방식으로 일어나는지 살펴보고, 대응 방안에 대해서 살펴보도록 하겠다.
Session ID 공격 유형
Session ID에 대한 공격은 크게 2 단계로 이루어진다. 1단계는 Session ID 취득 단계이고 2단계는 취득한 Session ID 공략 단계이다.
[그림1] HTTP Session Hijacking 공격 흐름도
공격자는 Session ID를 취득하기 위하여 웹 서버와 웹 클라이언트의 트래픽을 직접적으로 스니핑하거나, 웹 서버 상에 공격 코드를 삽입하여 두고 사용자가 클릭할 때 Cookie, Session ID 값을 전송받을 수 있도록 한다. 웹 서버와 웹 클라이언트 사이의 트래픽을 직접적으로 스니핑하는 방법은 일반적인 네트워크 트래픽 스니핑 기법을 통해 가능하다.
| POST /xxxxxx HTTP/1.1Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, */*Referer: http://xxx.xxx..comAccept-Language: koContent-Type: application/x-www-form-urlencodedAccept-Encoding: gzip, deflateUser-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)Host: ibn.kbstar.comContent-Length: 297Connection: Keep-AliveCache-Control: no-cacheCookie: Session=QJ48621878865 |
[그림2] 네트워크 트래픽 스니핑을 통한 HTTP 요청 헤더 안의 쿠키값
웹 서버 상의 HTML 코드 삽입이 가능한 페이지는 주로 사용자가 글을 게시할 수 있는 게시판이나 자료실 등에 존재한다. 정상적인 글을 게재하는 대신 공격자는 HTML 코드 및 스크립트를 심어 넣는다. 일반 사용자는 해당 게시물을 열람하게 될 때 자신도 모르는 사이 Cookie, Session ID 정보가 제 3 의 공격자 서버나 이메일로 전송되게 된다. (이러한 공격 기법을 Cross-Site Scripting이라고 부른다.)
| <form name=f method=POST action="http//host/hello.php"><input type=hidden name="name"value="<script>alert(document.cookie)</script>"></form><script>f.submit()</script> |
[그림3] 쿠키값 탈취를 위한 HTML 삽입 코드 예
결과적으로 공격자는 취득한 타인의 Session ID 값을 웹 서버에 요청함으로써 HTTP Session Hijacking 공격을 시도할 수 있다. 물론 이 공격이 성공하려면 Session ID 값이 유효해야 하므로, 사용자가 로그온 한 상태에서 공격이 이루어져야 하거나 Session ID 값의 유지 시간이 긴 경우라는 제한 사항이 필요하다.
그러나, 기본적으로 잘못 설계된 세션 관리 기법을 사용하고 있는 웹 서버는 이러한 Hijacking 공격에 취약할 수 밖에 없다. 굳이 타인의 Session ID 값을 직.간접적으로 취득하지 않고도 무작위 추측 대입(Brute-force Guessing)함으로써 공격이 가능하다. 공격자는 정상적인 로그인 과정시 분석한 자신의 Cookie 값, 웹 브라우저의 주소창의 URL, 웹 페이지 폼 소스 hidden field 내에 노출된 Session ID 값 자체를 분석한다.
Session ID 생성 방식의 취약점을 파악한 후, 공격자의 컴퓨터에서 로컬 프록시 툴이나 웹 브라우저 창 URL 주소창에서 직접 Sessioion ID 값 단일 대입을 시도한다. 더 나아가 자동적인 Session ID 대입 스크립트를 작성하여 공격할 수도 있다.
| http://mmail.xxx.co.kr/mletter1/read_mail.asp?id=2266&tableName=musicMail1927&fromEmail=xxx@xxx.co.kr http://www.xxx.co.kr/view/UID2305670410000 http://www.xxx.co.kr/view/UID2305670410341 http://www.xxx.co.kr/view/UID2305670411302 |
[그림4] 정상적인 Session ID 값
| http://mmail.xxx.co.kr/mletter1/read_mail.asp?id=3734&tableName=musicMail1927&fromEmail=xxx@xxx.co.kr http://www.xxx.co.kr/view/UID2305670410001 http://www.xxx.co.kr/view/UID2305670410002 http://www.xxx.co.kr/view/UID2305670419999 |
[그림5] 무작위 추측 대입된 Session ID 값
대응 방안
HTTP Session Hijacking 공격에 대하여 웹 어플리케이션 개발자는 다음과 같은 점을 고려하여 세션 관리 기법을 구현하여야 한다.
| 1. Session ID 생성 범위값을 사용자 수에 대비하여 충분히 큰 값으로 설정한다. 2. Session ID는 가능한 한 추측 불가능(random)하게 생성한다. 무작위 추측 대입 공격을 할 때 공격자는 그만큼 더 많은 시간을 투입하여야 하며 현재 연결되어 활성화 되어 있는 유효한 Session ID 값을 찾는 확률은 낮아진다. 3. Session Timeout 기능과 Session ID 재생성 기능을 사용한다. 일정 시간 동안 활동이 없는 사용자는 새로운 Session ID로 재로그인하도록 하고, 사용자 로그 아웃 시에는 Session ID 값을 폐기한다. 장시간 접속이 필요한 어플리케이션의 경우에는 일정 주기마다 Session ID값을 자동으로 재생성하여 세션을 유지하도록 한다. 4. 무작위 추측 대입(Brute-force Guessing)에 대비하여 일정 회수 이상의 인증 실패시에는 사용자 잠금 기능을 구현한다. 5. 로그인 이후에도 중요한 서비스 이용시에는 사용자 인증을 통하여 인가된 사용자만이 해당 서비스를 이용할 수 있도록 통제한다. 6. Cookie 내용 안의 Session ID와 기타 변수값 자체를 암호화한다. 7. 웹 서비스 자체의 중요성에 따라 Cookie가 전달되는 방식을 SSL로 구현함으로써 스니핑 공격에 대응할 수도 있다. 8. 웹 서비스 상에 공격자가 HTML 공격 코드 삽입이 가능한 페이지가 있는지 점검한다. 직접적인 공격 코드 삽입을 차단할 수 있도록 특수 문자 및 스크립트 코드를 필터링하여야 한다. |
지금까지 HTTP Session Hijacking 공격 기법에 대해서 알아보았다. 대부분이라고 말할 수는 없지만 요즘 인터넷에 서비스되고 있는 인기 있는 웹 컨텐츠 서버는 기본적으로 안전한 세션 관리 기법으로 구현되어 있다. 그러나, 웹 컨텐츠의 인지도와는 별도로 이러한 공격 기법에 대한 인지 없이 비보안적으로 구현된 e-메일 카드 서비스, 전자 앨범 서비스 사이트 등이 다수 존재하는 것 또한 현실이다.
HTTP Session Hijacking공격에 대한 대비는 안전한 웹 어플리케이션 구축을 위한 여러가지 항목 중에 필수적인 한 가지 사항이며, 기획 및 개발구현 단계에서 반드시 고려되어야 한다.
'보안' 카테고리의 다른 글
| 정보보호 개요 (0) | 2013.07.06 |
|---|---|
| 정보보안 용어 (0) | 2013.06.21 |
| 경쟁조건을 이용한 해킹기법[안천수 연구소 펌] (0) | 2013.06.21 |
| 해킹과 크래킹 (0) | 2013.06.21 |
| 트로이 목마[네이버 캐스트 펌] (0) | 2013.06.21 |
