출처 : 와우해커팀



스푸핑은 하나의 문장으로 요약될 수 있다. 그것은 신뢰받은 소스 주소로부터 패킷을 조작함으로서 다른 하나에게 하나의 머신을 인증하게 하는 복잡한 테크닉이다. 이 정으로부터 스푸핑이란 복잡한 과정이라고 결론내릴 수 있다.

하지만 이 장의 끝까지 당신은 스푸핑과 그것에 대한 방어법을 분명하게 이해하게 될 것이다.





인터넷 보안의 기초

인터넷 보안에는 두 가지 되풀이해서 나오는 주제가 있다.



∙ 신뢰

∙ 인증



신뢰란 서로서로를 연결하기 위해 인증된 컴퓨터 사이의 관계이다. 인증이란 그 컴퓨터들아 서로를 확인하기 위해 그 컴퓨터들이 사용하는 과정이다.

신뢰와 인증은 일반적으로 역의 관계를 가지고 있다. 그래서, 만약 컴퓨터 사이의 높은 수준의 신뢰가 존재하면 엄정한 인증은 서로를 연결하는데 요구되지 않는다. 반면에 만약 신뢰관계과 조금도 없거나 존재하지 않는다면 더욱더 엄격한 인증이 요구된다.

만약 당신이 그것에 대해 생각한다면 인간은 비슷한 규칙들을 실행하는 것이다. 예를 들어, 만약 당신의 최고의 침구가 당신의 현관 입구에 오면 당신은 그를 즉시 들어오게 할 것이다. 당신은 그를 신뢰하는 것이다. 하지만, 만약 완전히 낯선 사람이 노크를 하면 당신은 그의 신분을 밝히라고 요구할 것이다.





인증 방법

비록 당신이 그것을 깨닫지 못할지라도, 당신은 지속적으로 인증되고 있다. 예를 들어 당신은 다음 서비스 중의 어느 것이라도 사용하기 위해 사용자명과 패스워드를 제공해야만 할 것이다.



∙ 인터넷 연결

∙ FTP 사이트

∙ 텔넷 서비스 그리고 쉘 어카운트





사실, 오늘날 대부분의 가입을 기초로 하는 웹사이트들은 사용자명과 패스워드를 요구한다. 당신은 매일 높은 수준의 인증을 받아야 한다. 그것이 무엇을 의미하는지 알고 있는가? 인터넷은 단순히 당신을 신뢰하지 않는다는 것이다.

그러므로 사람을 인증하는 것은 패스워드 설계를 포함하고 있다. 어떤 모델들은 단순히 사용자명/패스워드 구도를 도입하고 있는 반면, 다른 모델들은 이전의 패스워드에 바탕을 둔 도전-응답 시스템과 같이 더 복잡할 수 있다. 비록 그 사용자가 정확한 패스워드를 가지고 있던 아니면 가지고 없던 종국의 결과는 같다.

컴퓨터들은 그들의 신뢰 관계에 따라 다른 방식으로 인증받을 수 있다. 예를 들어, 어떤 컴퓨터는 그것의 호스트나 IP 주소에 의해 인증받을 수 있다. RHOSTS 엔터리를 사용하는 것이 이것을 설정하는 일반적인 절차이다.





RHOSTS

RHOSTS 시스템은 컴퓨터들 사이의 신뢰관계를 확립하는데 사용될 수 있다. 그것은 솔라리스 맨페이지에 다음과 같이 기술되어 있다.



/etc/hosts.equiv와 .rhosts 파일은 rlogin(1), rsh(1), rcp(1), 그리고 rcmd(3N)를 위해 “원격지 인증” 데이터베이스를 제공한다. 그 파일들은 “신뢰받는” 것으로 생각되는 원격지 호스트와 사용자를 지정한다. 신뢰받은 사용자들은 패스워드를 제공하지 않고 로컬 시스템에 접근하는 것이 허용되어 있다.





hosts.equiv 파일은 전체 시스템의 .rhosts 설정에 필수적이다. 이것들은 루트에 의해 설정되고 호스트와이드(hostwide)를 제공한다. 대조적으로 .rhosts 파일들은 사용자 기반이며, 특별한 사용자 그리고 디렉토리에만 단지 적용된다. 이것이 왜 사용자들은 그들 자신의 .rhosts 파일을 만드는 것으로부터 제한되어야하는 이유이다. 이 작은 허점이 시스템 전체의 허점이 될 수도 있다.





.rhosts 파일의 보기는 다음과 같다.



node1.sams.hacker.net hickory

node2.sams.hacker.net dickory

node3.sams.hacker.net doc

node4.sams.hacker.net mouse



이 파일들은 신뢰받는 네 개의 컴퓨터(hickory , dickory , doc , 그리고 mouse라는 사용자)를 지정하고 있다. 이것들은 패스워드 인증 절차를 거치지 않고 r 서비스를 통해 로컬 컴퓨터에 접근할 수 있다.

그 프로세스를 완료하기 위해 그리고 양방향 신뢰관계를 구축하기 위해 네 개의 컴퓨터 모두가 rhost 엔터리를 역시 유지해야만 한다.





r 서비스는 다음의 어플리케이션으로 구성되어 있다.

∙ rlogin - 원격 로그인(remote login). 이것은 텔넷과 아주 유사하게 작동하고, 원격 로그인 세션을 제공한다.

∙ rsh - 원격 쉘(remote shell). 이것은 사용자로 하여금 원격지 컴퓨터에 쉘 명령을 실행하게 할 수 있다.

∙ rcp - 원격 파일 복사(remote file copy). 이것은 사용자로 하여금 원격지 컴퓨터의 파일을 복사하게 한다. 그 역도 마찬가지다.

∙ rcmd - 원격 명령(remote command). 이것은 원격지 호스트에 특정 사용자에게 명령을 실행하는 것을 가능하게 한다.



네가지 r 서비스 모두 신뢰 목적을 위해 /etc/hosts.equiv 또는 .rhosts allow/deny를 사용한다. 만약 이 파일들이 비어있거나 존재하지 않는다면 신뢰관계는 존재하지 않고, 그러므로 스푸핑 공격은 일어날 수 없다.





연결시 일어나는 인증절차는 단지 IP 주소에만 기초로 하고 있다. 이것은 Steve M. Bellovin이 그의 논문 Security Problems in the TCP/IP Protocol Suite에서 설명하고 있듯이, 결함을 가진 모델로 알려져 있다.



만약 이용 가능하다면 악용하기에 가장 쉬운 기법은 IP 소스 라우팅이다. 목표 호스트가 반환 트래픽에 대한 TCP dvms 리퀘스트에서 제공된 소스 라우터의 반전을 사용한다고 가정해보자. 그와 같은 행동은 아주 이성적이며; 만약 그 연결을 한 사람이 어떤 이유 때문에 특정한 통로를 지정하기를 원한다면(자동 라우터가 죽었기 때문에) 응답은 만약 다른 통로가 뒤따른다면 그 originator에게는 도착하지 않을 수도 있다.

그 공격자는 그때 목표지 로컬 네트워크의 신뢰받은 컴퓨터의 ip 주소를 포함해 바라는 어떤 IP 주소라도 선택할 수 있다. 그와 같은 컴퓨터에 사용 가능한 어떤 설비도 공격자에게 이용가능해진다.







▶ Security Problems in the TCP/IP Protocol Suite by Steve M. Bellovin,

ftp://ftp.research.att.com/dist/internet_security/ipext.ps.Z



다음의 요점이 지금으로서는 분명해졌다.

1. 신뢰와 인증은 역관계를 가지고 있으며, 더 많은 신뢰는 더 적은 엄정한 인증이란 결과를 낳는다.

2. 초기 인증은 신뢰관계에서 출처 IP 주소에 바탕을 둔다.

3. IP 출처 주소 인증은 IP 주소와 IP의 헤더의 대부분의 필드가 조작될 수 있기 때문에 믿을 수 없다.

4. 어떤 종류의 신뢰관계는 스푸핑 공격이 이루어지기 위해 존재해야만 한다.



이것으로부터 당신은 왜 IP 스푸핑이 크래커 공동체에서 예찬을 받았는지 그 이유들 중의 하나를 추측할 수 있을 것이다. 대부분의 크래킹 공격들은 역사적으로 패스워드 구조에 의존해왔다. 즉, 크래커는 /etc/passwd 파일을 훔쳐 그것을 크랙하는 것이다. 그들은 루트의 패스워드나 적어도 한 사용자의 로그인/패스워드를 획득한 후 그것을 크랙하는 것이다. 하지만 스푸핑에서는 사용자이름이나 패스워드는 공격동안에는 지나가지 않는다. 보안이 깨지는 것은 아주 별개의 차원에서 일어난다.

IP 스푸핑이 악명을 얻게된 것의 또 다른 이유는 공격의 다른 형태의 주요 요소로서 사용될 수 있다는 것이다. 이것의 한 예가 다음 장에서 섹션에서 서술된 “세션 하이재킹”(session hijacking)이다.





스푸핑 공격의 역학

소스 주소 인증이 결함을 가지고 있다는 단순한 사실이 그 자체가 IP 스푸핑을 만들지는 않는다. 그 이유는 연결 과정이 올바른 IP 주소 이상을 요구하기 때문이다. 그것은 컴퓨터 사이의 완벽하고 지속적인 대화를 요구한다. 당신은 더 쉽게 그 과정을 단계별로 이해할 수 있다.



∙ IP는 패킷 전송에 책임이 있다. IP에의해서 수행된 패킷전송은 신뢰할 수 없다. 이것은 패킷이 손상을 입지 않고 본래대로 도착할 것인지에 대해 절대적인 보장이 없다는 뜻이다. 예를 들어, 패킷은 상실될 수도 있고, 손상을 입을 수도 있다. 주 요점은 IP는 단순히 A 지점에서 B 지점으로 패킷의 경로를 지정한다. 그래서, 연결을 시작하는 첫 단계는 패킷이 적절한 호스트에 손상을 입지 않고 도착하는 것이다.



∙ 그 패킷이 정말로 도착한 후 TCP가 이어받는다. TCP는 더 신뢰할 수 있으며, 그 패킷이 손상을 입지 않고 적절히 전송되었는지를 확인할 기능을 가지고 있다. 각각은 검증을 받아야 한다. 예를 들어, TCP는 먼저 패킷을 받았는지를 인정하고, 그런 다음 그 패킷이 제대로 도착해 올바르게 절차를 밟고 있다는 것을 확인하는 메시지를 보낸다.





TCP의 패킷 에러 검사의 절차는 순차적으로 수행된다. 만약 다섯 개의 패킷이 보내지면 패킷 1, 2, 3, 4, 그리고 5가 그들이 받아진 순서대로 처리된다. 각각의 패킷은 식별표로서 번호가 부여된다. 양쪽 호스트 둘 다 이 숫자를 에러확인과 보고를 위해 이 번호를 사용한다.

Rik Farrow는 그의 글 Sequence Number Attacks에서 츠토무 시모무라의 컴퓨터를 공격할 때 케빈 미트닉에 의해 사용된 시퀀시 번호 처리 과정을 설명하고 있다.



시퀀시 번호는 데이터의 수신을 인정하는데 사용된다. TCP 연결이 시작될 때, 클라이언트는 TCP 패킷을 초기 시퀀시 번호와 함께 TCP 패킷을 보내지만 아무런 인정도 없다. 만약 연결되는 다른 끝에 실행되고 있는 서버 어플리케이션이 있다면, 그 서버는 클라이언트의 패킷에 1을 더한 초기 시퀀시 번호와 인정을 함께 TCP 패킷을 되돌려보낸다. 클라이언트 시스템이 이 패킷을 받을 때 그것은 그 자신의 인정을 돌려보내야 하는데, 그것은 서버의 초기 시퀀시 번호에 1을 더한 것이다. 이처럼 TCp 연결을 완성하기 위해서는 세 개의 패킷이 필요하다.





▶ Rik Farrow이 쓴 Sequence Number Attacks는 http://www.nwc.com/unixworld/security/001.txt.html에서 찾을 수 있다.



공격자의 문제는 두 가지로 특징지을 수 있다. 먼저 그는 소스 주소를 조작해야하고, 두 번째는 목표와 연속적인 대화를 유지해야한다. 공격을 복잡하게 만드는 두 번째 일이다. 이유는 그 연속적인 대화는 임의적이지 않기 때문이다. 목표는 초기 시퀀시 번호를 설정하고, 공격자는 정확한 응답으로 반격해야 한다.

이것은 그 공격을 복잡하게 만드는데, 이유는 공격자는 목표로부터 패킷을 실제로 결코 받지 않기 때문에 정확한 시퀀시 응답을 추측해야한다. Robert Morris는 A Weakness in the 4.2 BSD UNIX TCP/IP Software라는 글에서 다음과 같이 설명하고 있다.



4.2 BSD는 전 세계적 초기 시퀀시 번호를 유지하고 있으며, 그것은 각각의 연결이 이루어진 후에 매 초별 128씩, 그리고 64씩 증가된다. 각각의 새로운 연결은 이 번호와 시작된다. 조작된 소스와 함께 SYN 패킷이 호스트로부터 보내질 때, 목적지 호스트는 조작하는 호스트가 아니라 추정된 소스 호스트로 대답을 보낼 것이다. 조작하는 호스트는 그 패킷을 인정하고 “확립된”(ESTABLISHED) 상태에서 목적지 TCP 포트를 넣기 위해 그 잃어버린 패킷의 시퀀시 번호가 무엇인지 알아내거나 추측해야 한다.



▶ Morris의 글은 ftp://ftp.research.att.com/dist/internet_security/117.ps.Z에서 찾을 수 있다.



혼란스러울지 모르겠으니 개념에 대해 더욱더 분명하게 실례를 들어 설명하겠다. 다음을 가정해보자.



∙ 크래커는 호스트 207.171.0.111과 199.171.190.9가 신뢰관계를 가지고 있다는 것을 알고 있다.

∙ 그는 207.171.0.111를 칩입하려고 한다.

∙ 그렇게 하기 위해, 그는 199.171.190.9인체 해야 한다.

∙ 199.171.190.9인체 하기 위해 그는 그 주소를 조작한다.



문제는 207.171.0.111로부터의 모든 응답은 크래커의 컴퓨터가 아니라 실제로 199.171.190.9로 경로가 정해져야 한다. 이것 때문에 크래커는 패킷 트래픽을 볼 수 없다. 그는 눈먼 상태로 일을 추진하고 있다. 응답으로 오는 패킷 트래픽을 볼 수 없기 때문에 이런 스푸핑 방법은 “눈먼 스푸핑”(blind spoofing)이라고 알려져 있다. “눈멀지 않은” 스푸핑은 그 패킷 트래픽이 공격자가 볼 수 있는 네트워크 세그먼트를 따라서 일어나기 때문에 그 응답이 보일 수 있을 때 일어난다.

“눈먼 스푸핑” 상황은 훨씬 더 심각한 장애물을 던진다. 크래커가 그의 공격을 수행중일 동안에 199.171.190.9가 만약 목표로부터 패킷에 응답을 할 경우 어떻게 되겠는가? 이것은 전체 공격시도를 날려버린다. 그러므로, 크래커는 공격을 실제로 수행하기 전에 하나의 마지막이자 추가 단계를 수행해야 한다. 그는 199.171.190.0가 실행되지 않고 있거나, 199.171.190.9를 잠자는 상태로 만들을 때 스푸핑 공격을 수행해야 한다.





199.171.190.9를 죽이는 것은 간단하다. 그렇게 하기 위해 크래커는 syn-flood 공격에 199.171.190.9를 노출시켜야 한다. 이것은 199.171.190.9의 연결 큐(queue)를 넘쳐흐르게 하여, 일시적으로 그 컴퓨터가 들어오는 연결 요구를 처리할 수 없도록 한다. 이것은 연결 요구가 처리되는 방법 때문에 성공한다. 연결 요구가 들어올 때마다 공격 목표는 쓰리 웨이 핸드 쉐이크를 완수하려고 시도한다. 결국 그 목표는 그 연결 요구에 대해서는 타임 아웃되고, 다음 것을 처리하려고 시도한다. 모든 연결요구는 그들이 받아진 순서대로 처리된다. 그러므로, 만약 목표가 많은 그런 연결 요구로 넘쳐흘러 상당한 시간이 지나서야 syn-flood 공격을 받은 호스트는 연결 요구를 다시 처리할 수 있다.





이쯤에서 여때까지 제시된 모드 것을 되짚어보자.



성공적인 스푸핑 공격의 요인

다음은 스푸핑 공격을 할 때 취해야할 필수적인 단계이다.



1. 크래커는 그의 공격 목표를 확인하여야 한다.

2. 크래커는 속이려고 하는 호스트를 마비시켜야 한다.

3. 크래커는 그가 속이고 있는 주소를 조작해야 한다.

4. 마비된 호스트로서 가장하여 목표에 연결해야 한다.

5. 크래커는 목표에 의해 요구된 정확한 시퀀시 번호를 정확하게 추측해야 한다.

처음 4단계는 쉽다. 어려운 부분은 정확한 시퀀시 번호를 추측하는 것이다. 그렇게 하기 위해 크래커는 사전 실행을 해야 한다.



∙ 그는 연결을 요구하는 의도한 목표에 접촉한다.

∙ 그 목표는 시퀀시 번호로 응답한다.

∙ 크래커는 이 시퀀시 번호를 기록하고 연결을 끊는다.



크래커는 목표로부터 받은 시퀀시 번호의 기록을 관찰한다. 그의 분석에서 어떤 패턴을 확인한다. 예를 들어, 그는 이 시퀀시 번호가 이 목적을 위해 특별히 고안된 어떤 알고리즘에 의해 한결같이 구현되고 있음을 알았다. 그의 일은 그 알고리즘을 확인하는 것이며, 또는 적어도 그 번호가 구현되는 숫자값을 확인해야 한다. 그가 이것을 알고 있을 때, 그는 어떤 시퀀시 번호가 인증을 위해 요구되는지 확실히 예측할 수 있다.

그는 지금 스푸핑 공격을 수행할 준비가 되었다. 이처럼 스푸핑은 놀라운 테크닉이다. 하지만 더욱 놀라운 것은 이것이다. 1985년 이후, 보안 공동체는 스푸핑이 가능하다는 것을 알고 있었다는 것이다.



더 적절한 허점 열기

연결이 되고 인증 절차가 완료되면 크래커는 시스템을 장악할 수 있는 더욱 더 적절한 취약점을 만들어야 한다. 그는 그가 연결하고 싶을 때마다 스푸핑을 할 필요는 없다. 그러므로, 그는 관례가 된 취약점을 만들어야 한다. 가장 쉬운 방법은 .rhosts 파일을 다시 써 추가적의 인증에 대한 요구 없이 어느 곳에서라도 접속 요구를 시스템이 받아들이도록 만드는 것이다.

이것을 끝내면 크래커는 연결을 끊고 재접속한다. 그는 이제 패스워드 없이도 로그인 할 수 있고, 그 시스템을 통제할 수 있다.





누가 스푸핑을 당할 수 있는가?

IP 스푸핑은 어떤 서비스를 실행시키고 있는 어떤 특정 컴퓨터에 대해서만 구현될 수 있다. 많은 종류의 유닉스가 실행 가능한 목표가 될 수 있다. 그러나 이것이 비유닉스 계열 시스템이 스푸핑 공격에 취약점을 보이지 않는다는 인상을 주어서는 안된다. 이 장의 뒤에서 더 많은 것을 알아보기로 하자.

다음 설정과 서비스가 취약하다고 알려져 있다.



∙ Sun RPC를 실행하고 있는 디바이스

∙ IP 주소 인증을 사용하는 네트워크 서비스

∙ MIT의 XWindow 시스템

∙ r 서비스



그것을 올바로 이해하기 위해 이것을 고려해보자. 대부분의 네트워크 서비스는 IP 기반의 인증을 사용하고 있다. 그리고 RPC, X, 그리고 r 서비스가 유닉스 기반의 운영체계에 내재되어 있는 문제들을 가지고 있지만 다른 운영체계들이 취약점이 없는 것이 아니다.

예를 들어, 윈도우 NT는 시퀀시 번호 공격에 취약하다. 세션이 TCP 시퀀시 번호 추측을 통해 하이재킹 당할 수 있다. 문제는 스푸핑이다. 그것은 단지 RPC 만이 아니라 많은 네트워크에 영향을 미친다. 사실, 그것은 NetBIOS와 SMB 연결에도 영향을 미친다. 스푸핑 공격을 위한 익스플로잇 코드는 http://www.engarde.com/software/seqnumsrc.c에서 찾을 수 있다.





▶ Sun RPC는 Sun Microsystem의 RPC의 표준인데, 그것은 사용자들로 하여금 그 작업이 네트워크를 통해 투명하게 작동하는 시스템 호출을 가능하게 만든다. RPC에 대해 말하고 있는 RFC 문서 RPC : Remote Procedure Call Protocol Specification는 http://www.netsys.com/rfc/rfc1057.txt에서 찾을 수 있다.





스푸핑 공격은 얼마나 흔한가?

스푸핑 공격은 예전에는 아주 드물었다. 하지만, 그것은 1995년 1월 이후로 훨씬 더 흔해졌다. 1995년 DDN(Defense Data Network)의 권고문을 고려해보자.



ASSIST는 국제적으로 인터넷 사이트에 방향이 맞춰진 최근의 IP 스푸핑 공격에 대한 정보를 받았다. IP 스푸핑 공격에 목표가 된 많은 시스템은 네임서버, 라우터, 그리고 다른 네트워크 운영체계이며, 그 공격은 대부분 성공했다.



▶ 이것에 대한 DDN의 게시판을 보려면 http://csrc.ncsl.nist.gov/secalert/ddn/1995/sec-9532.txt를 참고하라.



1995년 이전에는 스푸핑은 아주 grass-root한 공격이었다. 스푸핑을 시도하는 사람은 TCP/IP, 소켓, 그리고 네트워크 프로그래밍에 대한 강력한 배경지식을 가지고 있어야 했다. 그런데 지금은 더 이상 그렇지 않다.

이전에는 이론적인 개념만으로 존재했던 스푸핑이 실제로 작동한다는 것이 발혀진 이후로 스푸핑 코드가 즉시 표면으로 떠오르기 시작했다. 오늘날, 이미 만들어진 스푸핑 유틸리티가 광범위하게 사용 가능하다. 다음 섹션은 몇가지 스푸핑 유틸리티를 제시하고 있다.



스푸핑/하이재킹 유틸리티





1644

제작자: Vasim V

언어: C Build

플랫폼: FreeBSD

목표 플랫폼: UNIX

필요조건: C compiler , IP header files , FreeBSD

URL: http://www.insecure.org/sploits/ttcp.spoofing.problem.html





Hunt

제작자: Pavel Krauz

언어: C Build

플랫폼: Linux

목표 플랫폼: Linux

필요조건: C compiler , Linux

URL: http://lin.fsid.cvut.cz/~kra/index.html



ipspoof

제작자: Unknown

언어: C Build

플랫폼: UNIX

목표 플랫폼: UNIX

필요조건: C compiler , IP Header Files , UNIX

URL: http://www.rootshell.com/archive-j457nxiqi3gq59dv/199707/ipspoof.c



Juggernaut

제작자: route

언어: C Build

플랫폼: UNIX

목표 플랫폼: UNIX

필요조건: C compiler , IP Header Files , UNIX

URL: http://staff.washington.edu/dittrich/talks/qsm-sec/P50-06.txt



rbone

제작자: Unknown

언어: C Build

플랫폼: Linux

목표 플랫폼: UNIX

필요조건: C compiler , IP header files , Linux

URL: http://www.net-security.sk/network/spoof/rbone.tar.gz



Spoofit

제작자: Brecht Claerhout

언어: C Build

플랫폼: Linux

목표 플랫폼: UNIX

필요조건: C compiler , IP header files , Linux 1.3 or later

URL: http://rootshell.com/archive-j457nxiqi3gq59dv/199707/IP-spoof.txt.html



synk4.c (Syn Flooder by Zakath)

제작자: Zakath

언어:C

플랫폼: 리눅스

목표 플랫폼: 유닉스

필요조건: C compiler , IP header files , Linux

URL: http://rootshell.com/arcive-j457nxiqi3gq59dv/199707/synk4.c.html





UDP 스푸핑 유틸리티도 역시 사용 가능하다. 그것을 사용 해보려면

http://www.deter.com/unix/software/arnudp.c에서 다운받아라.





IP 스푸핑 관련 문서

IP 스푸핑에 대해 말하고 있는 문서는 온라인 상으로 많이 있다. 다음은 괜찮은 문서들 중 몇 가지이다.



A Weakness in the 4.2BSD UNIX TCP/IP Software. Robert T. Morris. Technical Report, AT&T Bell Laboratories.

ftp://research.att.com/dist/internet_security/117.ps.Z



Sequence Number Attacks. Rik Farrow. (UnixWorld.)

http://www.nwc.com/unixworld/security/001.txt.html



Security Problems in the TCP/IP Protocol Suite. Steve Bellovin.

ftp://research.att.com/dist/internet_security/ipext.ps.Z



Defending Against Sequence Number Attacks. S. Bellovin; Request for Comments: 1948. AT&T Research. May 1996.

http://andrew2.andrew.cmu.edu/rfc/rfc1948.html



A Short Overview of IP Spoofing. Brecht Claerhout.

http://rootshell.com/archive-j457nxiqi3gq59dv/199707/IP-spoof.txt.html



Internet HolesEliminating IP Address Forgery. Management Analytics.

http://all.net/journal/netsec/9606.html



Ask Woody about Spoofing Attacks. Bill Woodcock from Zocalo Engineering.

http://www.netsurf.com/nsf/v01/01/local/spoof.html



IP-Spoofing Demystified Trust-Relationship Exploitation. route@infonexus.com (Michael Schiffman).

http://www.fc.net/phrack/files/p48/p48-14.html







IP 스푸핑 공격 방어법

당신의 네트워크를 로컬 주소로부터 패킷을 생성하는 것을 요구하는 네트워크로부터 온 패킷을 거부하도록 설정하는 것은 IP 스푸핑 공격을 좌절시킬 수 있다. 이것은 라우트 차원에서 이루어진다. 역으로 외부의 어떤 호스트로부터 들어오려고 요구하는 당신의 네트워크 내부에서 생성되는 패킷을 거부하는 것도 일반적으로 좋은 방책이다.





비록 라우터가 일반적인 스푸핑 문제에 대한 해결책이기는 하지만 소스 주소를 확인함으로서 역시 스푸핑 문제를 해결할 수도 있다. 그러므로 그것들은 단지 당신의 내부 네트워크 안에서부터 발생한 것처럼 하며 들어오는 패킷들에 대해서만 보호할 수 있다. 만약 당신의 네트워크가 어떤 불가해한 이유 때문에 외부 호스트를 신뢰한다면 라우터는 그 호스트로부터 발생한 것처럼 하는 스푸핑 공격을 방어하지 못할 것이다.





일반적인 구성에 반 스푸핑 기술을 조합한 제품들이 몇 가지 있다.



∙ NetVision Synchronicity(Windows NT용): Synchronicity의 제품으로, NDS와 NT의 객체, 그리고 시스템을 동시에 관리하며, 스푸핑을 막는 기능도 포함되어 있다.

http://www.netvision.com/products/synchronicity.html



∙ Cisco PIX Firewall: PIX는 Cisco의 첫 번째 Internet BXsecurity 제품이다. 방화벼과 스푸핑을 막는 기능을 가지고 있다.

http://www.cisco.com/warp/public/cc/pd/fw/sqfw500







<주의>

만약 당신이 방화벽을 실행하고 있다고 해도, 이것이 자동적으로 스푸핑 공격으로부터 당신을 보호하지는 않는다. 만약 방화벽의 외부를 통해 내부 주소로 접근하는 것을 허용한다면 여전히 취약점을 가지고 있는 것이다. 더욱이, 만약 당신의 방화벽이 프록시를 실행하고, 그 프록시가 IP 소스 주소에 기초를 두고 그들의 인증절차를 실행한다면 당신은 문제를 가지고 있는 것이다. 필수적으로 이런 형태의 인증은 IP 기반의 인증과 다를 바 없다.





당신의 네트워크를 면밀히 감시하는 것은 또다른 하나의 예방책이다. 당신의 네트워크 내부에서 발생한 것처럼 하는 패킷을 확인하도록 노력해라. 하지만 유선상에서 만나는 첫 번째 네트워크 인터페이스나 방화벽에 들어가도록 시도해라. 다음 문단은 Defense Information System Network Security Bulletin #95-32에서 발췌한 것이다. 이것은 http://csrc.ncsl.nist.gov/secalert/ddn/1995/sec-9532.txt에서 볼 수 있다.



당신이 지켜볼 수 있는 몇몇 패킷의 종류가 있다. 가장 기본적인 것이 네트워크 부분이 출발지와 목적지 주소가 같지만 당신의 로컬 네트워크에서 나온 것이 아닌 어떤 TCP 패킷이다. 이 패킷들은 만약 추가로 조사할 가치가 있는 라우팅 문제가 없다면 또는 그 패킷이 당신의 네트워크 외부에서 원래 생성되었다면 출발지 네트워크 외부로 일반적으로 가지 않을 것이다. 후자가 유동성 IP 테스트와 더불어 발생할 수 있지만 그 출발지 주소를 스푸핑하는 공격자가 더 많을 것이다.





글을 마치면서 만약 당신이 resource overhead의 여유가 있다면 심지어는 실시간으로 로그인 과정을 통해 스푸핑을 탐지할 수 있다. 신뢰받은 호스트들 사이의 연결에 대해 비교를 하는 것도 좋은 출발일 것이다. 예를 들어, 신뢰받은 호스트 A와 B는 살아있는 세션을 가지고 있다고 가정해보자. 양쪽은 그 세션이 진행중임을 나타내는 처리과정을 보여줄 것이다. 만약 그들 중의 하나가 활동을 나타내지 않으면 스푸핑 공격이 진행중이다.





다른 스푸핑 공격들

IP 스푸핑은 단지 스푸핑의 한가지 형태일 뿐이다. ARP 그리고 DNS 스푸핑을 포함해 다른 스푸핑 테크닉도 존재한다. 그것들을 간단히 살펴보자.



ARP 스푸핑

ARP 스푸핑은 ARP 캐시를 변경시키는 테크닉이다. 다음이 작동원리이다. ARP는 하드웨어와 IP간의 매핑 정보를 포함하고 있다. 중요한 것은 하드웨어 주소를 지키는 것이지만, 신뢰받은 호스트의 IP 주소를 추정하기 위한 것이다. 이 정보는 동시다발적으로 목표와 캐시로 보내진다. 그 순간부터 목표로부터 오는 패킷은 당신의 하드웨어 주소로 경로를 잡게 된다. 그러면 그 목표는 당신의 컴퓨터가 신뢰받은 호스트라고 “믿게”된다.

이런 형태의 공격에는 엄격한 제한사항들이 있다. 하나는 성능이 뛰어난 허브와 라우터를 교차할 때 그 계략이 실패할 수도 있다는 것이다. 그러므로, ARP 캐시 스푸핑은 단지 어떤 조건 하에서만 가능하며, 심지어는 로컬 네트워크 세그먼트에 제한될 수도 있다. 더욱이 캐시 엔트리는 아주 빨리 소멸된다. 그러므로, 주기적으로 뒤를 쫓아야하고, 그 공격을 구현할 동안 캐시 항목을 업데이트해야 한다.

ARP 스푸핑은 막을 수 있는가? 절대적으로 막을 수 있다. 한가지가 돌에 당신의 주소를 쓰는 것이다. 하지만 이것은 약오를 전망이 높다. Paul Buis는 그의 논문 Names and Addresses에서 다음과 같이 설명하고 있다.



많은 운영체계들은 ARP 캐시를 “정적”인 것으로 만들기 위한 대비를 하고 있어서 매 순간마다 타임아웃을 하지 않는다. 나는 ARP 스푸핑을 막기 위해 이 특징을 사용할 것을 추천한다. 하지만 하드웨어 주소가 변할 때마다 수동으로 캐시를 업데이트 하는 것이 요구된다.

- http://www.cs.bsu.edu/homepages/peb/cs637/nameadd



또다른 하나의 선택은 ARPWATCH를 사용하는 것이다. ARPWATCH는 당신의 IP와 이더넷 매핑의 변화를 감시하는 유틸리티이다. 만약 변화가 탐지되면 경고 이메일을 받게된다. 또한 그 정보가 기록될 것이고 침입자를 추적하는데도 도움이 된다.



▶ ARPWATCH 구하는 곳: ftp://ftp.ee.lbl.gov/arpwatch.tar.gz





ARPWATCH를 사용하기 위해 UNIX, C, 그리고 AWK가 필요하다. 배포본은 소스만 공개되어 있다.







DNS 스푸핑

DNS 스푸핑에서 크래커는 DNS 서버를 공략하여, 호스트네임-IP 주소 테이블을 노골적으로 바꿔버린다. 이 변경사항은 DNS 서버에 있는 변환 테이블 데이터베이스에 쓰여진다. 그래서 클라이언트가 lookup을 요구할 때, 가짜 주소를 주게된다. 이 IP 주소는 완전히 크래커가 통제하는 컴퓨터의 주소이다. 이런 일이 일어날 가능성은 별로 없지만 만약 그 일이 일어난다면 광범위한 노출이 발생할 수 있다. 이 공격이 드문 것이 우리가 위안을 삼을 수 있는 것으로 받아들어져서는 안된다. 이 장의 앞에서 나는 DNS 서버에 대한 무분별한 공격을 기록한 DDN 권고문을 인용한바 있다. 더욱이 중요한 CIAC 권고문은 다음 문제를 말하고 있다.



비록 당신이 지금으로서는 이 서비스들을 사용하는 것과 관련된 위험들을 기껏이 받아들일 수 있을지 모르지만, 당신은 스푸핑 당한 DNS 정보가 가지고 있을지도 모르는 영향을 고려할 필요가 있다. 침입자가 정확하지 않은 네임 데이터를 제공하는데 BIND를 스푸핑하는 것이 가능하다. 어떤 시스템과 프로그램은 인증을 위해 이 정보에 의존한다. 그래서 그런 시스템을 스푸핑하고 불법적인 접근권한을 획득하는 것이 가능하다.



▶ 위의 글은 CIAC 권고문 DNS 취약점(Domain Name Service Vulnerabilities)에서 발췌한 것이며,

http://ciac.llnl.gov/ciac/bulletins/g-14.shtml에서 볼 수 있다.



DNS 스푸핑은 적어도 몇몇 플랫폼에서는 지금 자동화되어 있다. Nimrood에 의해 제작된 Jizz라는 유틸리티가 있다.(이것은 Johannes Erdfelt 의 코드에 기초를 두고 있다.) 이것을 사용해보려면 다음에서 다운받아라.



http://packetstorm.securify.com/Exploit_Code_Archive/jizz.c



Drew Dean , Edward W. Felten , 그리고 Dan S. Wallach에 의해 쓰여진 Java Security : From HotJava to Netscape and Beyond라는 DNS 스푸핑에 대해 말하고 있는 흥미로운 문서가 있다. 이 논문은 크랙 당한 DNS 서버에 반복적으로 호출하는 기법에 대해 설명하고 있다. 이와 같이 기본 네임서버로부터 신뢰받지 않은 서버로 DNS 질의를 하는 것이 궁극적으로 가능하다. 거기서부터 공격자는 클라이언트의 컴퓨터 또는 네트워크를 해킹할 수 있다.(이 버그는 1.02에서 고쳐졌다.)



▶ Java Security : From HotJava to Netscape and Beyond 는

http://www.cs.princeton.edu/sip/pub/oakland-paper-96.pdf에서 볼 수 있다.



하지만 DNS 스푸핑은 탐지하기에 아주 쉽다. 만약 당신이 DNS 서버들 중의 하나를 의심한다면 그 네트워크상의 신뢰할 수 있는 DNS 서버를 검사해라. 만약 원래 침범된 서버가 얼마동안 손상을 입지 않았다면 그것이 스푸핑 당했다는 증거를 즉시 겉으로 보여줄 것이다. 다른 신뢰할 수 있는 서버들은 크랙된 DNS 서버에 보내진 것과는 다르다는 결과를 보고할 것이다.

만약 원래 스푸핑 당한 서버가 얼마동안 손상을 입었다면 DNS 서버를 검사하는 것만으로는 충분하지 않을 것이다. 가짜 주소와 호스트 네임 테이블은 그 네트워크의 다른 DNS 서버로 전달되었을지도 모른다. 만약 네임 서버가 변경되었다는 것을 목격한다면 DOC(domain obscenity control)이라는 스크립트 유틸리티를 도입하기를 원할지도 모른다. DOC에 대한 것은 그 유틸리티 문서에 명확하게 설명되어 있다.



DOC는 적절한 도메인 네임 서버에 질의를 함으로서, 그리고 이 질의에 대한 결과에 일련의 분석을 수행함으로서 오류를 범하고 있는 도메인을 진단하는 프로그램이다.



▶ DOC는 ftp://coast.cs.purdue.edu/pub/tools/unix/sysutils/doc/doc.2.0.tar.Z에서 구할 수 있다.



DNS 스푸핑을 막는 다른 테크닉의 하나는 역 DNS 구조(reverse DNS scheme)를 사용하는 것이다. 즉, 호스트 이름 - IP 주소, IP 주소 - 호스트 이름이라는 역 관계를 테스트해보는 것이다. 이 기술은 제한된 값을 가질지도 모른다. 마찬가지로 크래커는 forward(호스트 이름-IP 주소)와 reverse(IP 주소-호스트 이름) 테이블을 변경했을 것이다. DNS 서버 설정에 대한 더 많은 정보는 다음에서 찾아보아라.

∙ http://www.dns.net/dnsrd/

∙ http://www.cert.org/advisories/CA-1999-14.html