'spoofing'에 해당되는 글 5건

  1. 2012.04.03 Nmap – Techniques for Avoiding Firewalls
  2. 2010.01.08 OTP and OPIE (2)
  3. 2009.10.27 DNSSEC(DNS Security Extensions)
2012. 4. 3. 19:34

Nmap – Techniques for Avoiding Firewalls

As a penetration tester you will come across with systems that are behind firewalls and they are blocking you from getting the information that you want.So you will need to know how to avoid the firewall rules that are in place and to discover information about a host.This step in a penetration testing called Firewall Evasion Rules.

Nmap is offering a lot of options about Firewall evasion so in this article we will explore these options.

Fragment Packets

This technique was very effective especially in the old days however you can still use it if you found a firewall that is not properly configured.The Nmap offers that ability to fragment the packets while scanning with the -foption so it can bypass the packet inspection of firewalls.

Fragment Packets - Nmap


In the next image we can see that Nmap is sending packets 8-bytes size when we are doing a scan with the -foption.

Capture a fragment packet

Specify a specific MTU

Nmap is giving the option to the user to set a specific MTU (Maximum Transmission Unit) to the packet.This is similar to the packet fragmentation technique that we have explained above.During the scan that size of the nmap will create packets with size based on the number that we will give.In this example we gave the number 24 so the nmap will create 24-byte packets causing a confusion to the firewall.Have in mind that the MTU number must be a multiple of 8 (8,16,24,32 etc).  You can specify the MTU of your choice with the command –mtu number target.

Specify a specific MTU to the packets


Use Decoy addresses

In this type of scan you can instruct Nmap to spoof packets from other hosts.In the firewall logs it will be not only our IP address but also and the IP addresses of the decoys so it will be much harder to determine from which system the scan started.There are two options that you can use in this type of scan:

  1. nmap -D RND:10 [target] (Generates a random number of decoys)
  2. nmap -D decoy1,decoy2,decoy3 etc. (Manually specify the IP addresses of the decoys)

Scanning with decoy addresses


In the next image we can see that in the firewall log files exist 3 different IP address.One is our real IP and the others are the decoys.

Log Files flooded with decoy addresses


You need to have in mind that the host that you will use as decoys must be online in order this technique to work.Also using many decoys can cause network congestion so you may want to avoid that especially if you are scanning the network of your client.

Idle Zombie Scan

This technique allows you to use another host on the network that is idle in order to perform a port scan to another host.The main advantage of this method is that it very stealthy because the firewall log files will record the IP address of the Zombie and not our IP.However in order to have proper results we must found hosts that are idle on the network.

Metasploit framework has a scanner that can help us to discover hosts that are idle on the network and it can be used while implementing this type of scan.

Discover Zombies


As we can see from the above image the scanner has discovered that the IP addresses and are idle on the network and are potential candidates for use on an Idle Zombie Scan.In order to implement an Idle Zombie scan we need to use the command nmap -sI [Zombie IP] [Target IP]

Executing an Idle Scan


We can see the effectiveness of this scan just by checking the firewall logs.As we can see the log files record the IP address of the Zombie host (SRC= and not our IP address so our scan was stealthy.

Firewall Log Files - Idle Scan

Source port number specification

A common error that many administrators are doing when configuring firewalls is to set up a rule to allow all incoming traffic that comes from a specific port number.The –source-port option of Nmap can be used to exploit this misconfiguration.Common ports that you can use for this type of scan are: 20,53 and 67.

Source port scan

Append Random Data

Many firewalls are inspecting packets by looking at their size in order to identify a potential port scan.This is because many scanners are sending packets that have specific size.In order to avoid that kind of detection you can use the command –data-length to add additional data and to send packets with different size than the default.In the image below we have changed the packet size by adding 25 more bytes.

Adding random data to avoid detection


The size of a typical packet that nmap sends to the target is 58 bytes as you can see in the image below.

Typical packet from nmap scan


With the command that we have used –data-length 25 we changed that value to 83 in order to avoid being discovered by firewalls that will check for the default packet size that nmap generates.

A sample of a packet that we have add 25 more bytes to avoid detection


Scan with Random Order

In this technique you can scan a number of hosts in random order and not sequential.The command that you use to instruct Nmap to scan for host in random order is –randomize-hosts.This technique combined with slow timing options in nmap command can be very effective when you don’t want to alert firewalls.

Scan hosts in random order

MAC Address Spoofing

Another method for bypassing firewall restrictions while doing a port scan is by spoofing the MAC address of your host.This technique can be very effective especially if there is a MAC filtering rule to allow only traffic from certain MAC addresses so you will need to discover which MAC address you need to set in order to obtain results.

Specifically the –spoof-mac option gives you the ability to choose a MAC address from a specific vendor,to choose a random MAC address or to set a specific MAC address of your choice.Another advantage of MAC address spoofing is that you make your scan more stealthier because your real MAC address it will not appear on the firewall log files.

Specify MAC address from a Vendor —-> –spoof-mac Dell/Apple/3Com

Generate a random MAC address —-> spoof-mac 0

Specify your own MAC address —-> spoof-mac 00:01:02:25:56:AE

MAC address Spoofing

Send Bad Checksums

Checksums are used by the TCP/IP protocol to ensure the data integrity.However sending packets with incorrect checksums can help you to discover information from systems that is not properly configured or when you are trying to avoid a firewall.

You can use the command nmap –badsum IP in order to send packets with bad checksums to your targets.In the image below we didn’t get any results.This means that the system is suitable configured.

Sending packets with bad checksum


You can see below a sample of a packet with bad checksum that we have sent:

A packet with bad checksum



We have seen that Nmap offers a variety of methods that it can be used to avoid a firewall that exists on the network that we are scanning and to get proper results from the target host.The problem in many of the cases that we have seen is the bad configuration of Firewalls that allowed us to get results from the target.So in a network that have IDS and firewalls properly configured many of the techniques may not work.Every situation is different so you need to decide which one will work for you.

출처 : pentestlab.wordpress.com

Trackback 0 Comment 0
2010. 1. 8. 19:46


by Hye Jin Youn & Security KAIST
Sponsored by Initech.

Copyright (C) Jan 2000, Hye Jin Youn and Security KAIST

You may freely redistribute or republish this article, provided the following conditions are met as long as it is for non-commercial purposes. Otherwise permissions should be granted:

1. This article is left intact.

2. Proper credit is given to its authors; Hye Jin Youn and the Security KAIST

  • I. Background of OTP
  • II. Introduction is OTP
    • OTP란?
    • OTP의 여러가지 이용
    • 국내 기술 동향

  • III. S/Key 란?
  • IV. Let's Use OPIE!
    • How to install an OPIE server
    • How to login to an OPIE system
    • OPIE Command and man pages

  • V. References
  • VI. Down load( opie )
  • Whatis?

Background of OTP

  • 현재의 userid , password를 인증기반으로 하고 있는 unix system 은 password를 누출 시키는 경우 위험함

  • TCP/IP protocol은 desine당시 보안 문제는 고려하지 않았기 때문에 sniffing과 IP spoofing 등을 이용한 해킹이 많이 이용되고 있다.

  • 국내에서 발생된 대부분의 해킹 사례는 ID와 password도용 사례가 주류를 이루고 있다.

Introduction to OTP

  1. OTP란?

      OTP( one time password )란 말 그대로 한번 쓰고 password를 버리는 일회용 password이므로 기존의 password가 sniffing 등으로 가로채여도 새로 생성된 password를 사용하므로 안전할 수 있다. 이러한 otp를 구현하기 위한 방법으로는 다음과 같은 것들이 있다.
    • 동기화된 시간을 유지하여 Time-Stamp를 사용
    • server와 client의 임의의 패스워드 리스트 내의 위치이용
    • Challenge-Response Schemes이용

  2. OTP의 여러가지 사용

    1. S/Key 방식
      S/Key 인증 시스템은 passive attack에 대해 사용자의 패스워드를 보호하기 위한 간단한 스킴이다.

      더 자세한 것은 뒤에 설명하도록 할것이다.

    2. Challenge-Response 방식
      user가 login하면, server는 Challenge message를 보낸다.
      user는 PIN( Personal Identification Number )와 Challenge 를 이용하여, OTP를 생성하여 Response를 한다.
      서버는 동일한 Challenge와 등록된 사용자의 정보을 이용해 OTP를 생성한 후 user의 Response와 비교하여 사용자 인증을 해주는 방식이다

    3. Time-Synchoronous 방식
      난수생성 알고리즘은 관리가가 정한 시간(t)마다 64bit의 비밀키가 생성되어 진다.
      각각의 사용자에게는 특정키가 할당되어지고, 지능형 토큰과 인증서버 데이터 베이스에 이것들이 저장되어진다.
      사용자가 login을 할때 PIN과 6개의 숫자로 된 난수를 전달하면, (이 난수는 토큰으로 생성되어 짐)

      난수는 토큰안에 저장되어 있던 비밀키와 t를 초기값으로 하여 토큰안의 알고리즘을 통해 만들어진다.

      이렇게 만들어진 10개의 숫자가 서버로 가면 서버는 PIN을 인덱스로 하여 해당 비밀키를 찾고, 생성된 6개의 랜덤 숫자들을 수신 것과 일치하는 지를 확인한다.

  3. 국내의 기술 동향.

    • 반도체 장비 전문업체인 미래 상업은 사용때마다 결과치가 다른 해쉬함수를 기반으로 구현되어 추론및 재현 공격을 봉쇄할 수 있고 발생기에 고유 ID 를 부여, 분실시 오용되는 것을 원천적으로 방지할 수 있는 공중망 인증 시스템을 개발 ('97.3)

    • 케신 시스템에서 미국 브이원사의 SmartGate제품을 수입하여 판매중

    • internet security korea secure card, secure server, securid ( Time-Synchoronous 방식 )을 개발 판매중임

    • 한국 엑시스

    • 그외의 여러 단체에서 연구중임

    • ( 자신의 회사에서 연구중인 분은 저에게 연락을 주세요 :) )

III. S/Key 란?

  • 특징

    • 기본 otp의 특징을 가지고 있다.
    • 사용하기에 간단하다.
    • 비밀 패스워드를 기억하도록 한다.
    • 자동화가 되어질수 있다.
    • 알고리즘이 공개되어 있다.
      - MD4 또는 MD5 one-way hash 함수를 사용한다.
      ( 8byte 입력 8byte 출력 )
    • 어떤 비밀 정보도 호스트에 보관되어지지 않는다.

  • 알고리즘

    • 기본적인 알고리즘은 one-way hash 함수를 여러번 적용함으로 계속해서 생성되어진다.

    • 착안 : f(x) = y 에서 x를 알고 y 를 알면 구해질수 있으나 y를 알고 x를 알아내기란, 즉 x = f~(y) 는 거의 불가능하다.
      ( * MD4와 MD5참고 )

    • 첫 번째 OTP는 user의 비밀 패스워드(S)를 정해진 특정수 (N) 만큼의 one-way hash 함수를 수행함으로 생성되어진다.

      P(1) = f(f(f(f(S))))

      다음번에는 n-1번을 수행함으로 생성되어지는 P를 쓸것이다.

      P(2) = f(f(f(S)))

      그렇기 때문에 도청자가 P(i)를 알게 되더라도, 다음 password, P(i+1)을 알아낸다는 것이 불가능하게 된다.

    • 처음에 호스트 컴퓨터는 OTP의 복사본을 저장한다. 그리고 그것을 one-way hash 함수로 계산하여, 복사본과 비교한다.
      만약 일치하게 된다면, system password file의 사용자의 엔트리는 OTP의 복사본으로 갱신되어진다.

  • 사용자에 의해 one-way hash 함수의 수가 하나씩 줄어들게 되므로 어느 시점에 다다르면 초기화를 시켜주어야 한다.

  • user의 OTP는 노트북이나 palm-top등을 포함하는 다양한 기종의 pc에서 수행되어진다. 또는 플로피 디스크에 저장되어지고 수행되어질수 있다. 또는 미리 계산을 하여 프린트를 하여 사용할수 있다.

    예를 들어 이런 token card가 있을수 있다.

    IV. Let's Use opie!

    • What is OPIE( OneTime Password in Everything ) ?
        OPIE 버전 2.32을 기반으로 구현했다.
        OPIE 원타임 패스워드 시스템은 공개버전으로 Bellcore S/Key 시스템과 상호 운용성이 있으며, RFC 1938에서 기술하고 있는 원타임 패스워드 시스템을 구현한 것이다.

    • 이문서의 기준은 OPIE Software Distribution, Release 2.32의 버전을 가지고 다루었습니다.
      test server는 linux 6.0입니다.

    • How to 'Install' an OPIE server

        1. Read the OPIE README file

        2. OPIE system requirement

        • A UNIX-like operating system
        • An ANSI C compiler and run-time library
        • POSIX.1- and X/Open XPG-compliance(including termios)
        • The BSD sockets API
        • Approximately five megabytes of free disk space

        3. download the OPIE

        4. Unpack the software( 압축풀기 )

          %> gunzip opie-2.32.tar.gz
          %> tar xfv opie-2.32.tar

        5. Read INSTALL readme file( 제 나름대로 요약하면 )

          i) configure을 실행시킴
          ii) Makefile을 나름대로 필요한 것을 고칩니다. ( 사실 안고쳐도 대충됨 )
          iii) make라고 치면됩니다( client만 깔기위해서는 make client, 서버만 깔기위해서는 make server 라고 치세요 ) iv) make install( client는 make client-install )

        6. file 확인 

        7. Install test

        여기서 otp-md5는 md5를 쓴다는 이야기고, key는 497이고, seed는 en3197이다

        8. 지우기 위해서

          %>make uninstall

    • How to login to an OPIE system

        1. 처음에는 admin에게 passphrase를 물어봐야한다.

        2. passphrase 만들고, 바꾸기

          %>INSTALLDIR/opiepasswd -f -c

          INSTALLDIR 은 opiepasswd 라는 명령어가 있는 모든 경로를 말한다.
          예를 들면, 보통 /usr/local/bin 가 되겠다.

          -f : 강제적으로 만듬을 의미한다.
          -c : console mode로 만들어서 secure한 접속이게끔 만든다.

    • Key generator

      • In Linux

        'opiekey' 명령어가 해준다.  

      • In Windows  

    • OPIE Command and man pages

      • In Linux

        opiegen :

          passphrase를 가지고 key를 generate시켜줌
          vici%> opiegen otp-md5 495 wi01309
          Secret Pass Phrase:

        opieinfo :
          다음의 sequence number와 seed 값을 출력

          %> opieinfo
          495 wi01309

          %> opiekey -n 42 `opieinfo`
          이런 식으로 이용하면 좋다.

          정보는 /etc/opiekeys에서 얻어오는 것들이다.

        opiesu :
          su 명령어 대신을 하는 것이다.

          %> opiesu vici
          otp-md5 498 wi910502
          (OTP response required)
          vici's password: (echo on)
          vici's password: RARE GLEN HUGH BOYD NECK MOLL
          # ( root shell )

      • In Windows

    V. Reference

    VI. Download

    What is ?

    • Sniffing
        TCP/IP desine 이 보안을 고려하지 않았기 때문에 network상의 packet을 모아 재배열시키면 원래의 data를 복제할수 있다.
    • Spoofing
        network상에서는 상대방을 어떻게 인증할 것인가가 중요하다. 보통 password나 IP , hostname등에 의해 인증을 하는데 전자는 sniffing에 의해 노출이 가능하며 후자는 spoofing에 의해 공격이 가능하다.
      • IP Spoofing : 해커의 host가 target host가 trust하는 host인척하기
      • DNS spoofing : rlogin , rsh을 사용하고 DNS server에 많은 packet을 보낸다. 그럼 host는 잠시 마비가 되며 그틈을 타서 target host로 하여금 자신의 host를 믿는 정보를 보낸다.
      • IP hijacking : 일단 connection이 일어난 두 host간에 connection을 변조하는 것을 말함

    출처 : http://sparcs.kaist.ac.kr/~vici/

    Trackback 0 Comment 2
    1. FreeBSD Handbook 2010.01.08 19:54 address edit & del reply


    2. OPIE 2010.01.08 19:56 address edit & del reply

      How to setup OPIE with pam On Linux

      jsotp: JavaScript OTP Calculator

    2009. 10. 27. 14:39

    DNSSEC(DNS Security Extensions)


    DNSSEC은 도메인 네임 시스템(DNS)이 갖고 있는 보안 취약점을 극복하기 위한 DNS 확장 표준 프로토콜이다.
    "DNS Security Extentions(DNS 보안성 확장)"을 축약하여 DNSSEC이라 부른다.

    DNS 프로토콜은 데이터 위-변조 침해공격의 위협에 취약하다는 문제점을 가지고 있었다.

    DNS 데이터의 위-변조 침해공격은 진짜 사이트와 동일한 모습으로 위장하고 있는 가짜 사이트로 사용자들이 접속하게끔 유도할 수 있다.

    자신이 접속하고 있는 사이트가 가짜 사이트인 줄 모르는 사용자는 자신의 로그인 계정과 암호, 그리고 신용카드 비밀번호와 같은 개인정보를 가짜 사이트의 웹 페이지에서 입력하게 되어, 개인 정보가 악의를 가진 공격자에게 노출되는 사고가 발생할 수 있다.

    DNS 데이터 위-변조 공격, DNS 캐시 포이즈닝

    DNS 데이터를 위-변조하는 공격 형태를 "DNS 캐시 포이즈닝(DNS Cache Poisoning)"이라 하며, 혹은 "파밍(Pharming)"이라고도 한다.

    예로써, 온라인 뱅킹 서비스를 이용하기 위해 은행 웹 사이트 www.a-bank.co.kr에 접속하는 경우를 상정해 보자.
    그림에서와 같이, www.a-bank.co.kr의 진짜 주소는이지만, 악의의 공격자는 이 www.a-bank.co.kr의 주소가인 것처럼 위변조할 수 있다.

    사용자는 PC에서 웹 브라우저의 주소창에 "http://www.a-bank.co.kr"을 입력하고 접속을 시도한다.
    웹 브라우저는 접속 사이트의 IP 주소를 알아야 해당 서버에 접근할 수 있으므로, 도메인 네임 www.a-bank.co.kr의 IP 주소를 파악하는 절차를 먼저 수행한다.

    그림에서와 같이, PC 호스트 시스템은 리커시브 네임서버에 대해 www.a-bank.co.kr에 대한 IP 주소를 질의한다.
    PC 호스트는 DNS 응답 패킷에서 www.a-bank.co.kr 사이트의 웹 접속에 필요한 IP 주소를 얻게 된다.

    리커시브 네임서버는 PC 호스트로부터의 질의에 응답할 때, DNS 데이터를 임시로 저장하는 캐시에서 해당 데이터로서 응답한다.

    문제는 이 캐시에 저장된 DNS 데이터가 위-변조된 데이터일 경우에 발생한다.
    www.a-bank.co.kr 은행사이트의 진짜 IP 주소는인데, 누군가가 위-변조된 DNS 응답 메시지로 리커시브 네임서버를 속여 www.a-bank.co.kr의 IP 주소가인 것으로 믿게 하여 이를 캐시에 저장하는 경우가 이에 해당한다.

    이렇게 되면 이 리커시브 네임서버를 사용하고 있는 모든 PC 호스트는 www.a-bank.co.kr 사이트에 접속을 하려 할 때, 주소의 서버가 아니라의 서버에 접속하게 된다.

    이 과정은 PC 호스트와 네임서버 간에 일어나는 절차에 의한 것이므로, 사용자는 자신이 가짜 웹 사이트에 접속하고 있다는 것을 알 수가 없다.

    특히 이런 경우의 가짜 웹 사이트는 www.a-bank.co.kr 사이트와 동일한 모습으로 위장된 웹 사이트이게 된다.
    공격자가 사용자의 개인정보를 입력받기 위해서 미리 준비한 위장된 웹 사이트이다.

    사용자는 이 접속된 사이트가 www.a-bank.co.kr의 은행 사이트인 것으로 착각하고 아무런 의심 없이 자신의 로그인 정보와 계좌 비밀번호를 입력하게 된다.

    악의의 공격자는 사용자가 입력하는 개인정보를 저장하여 금융범죄에 사용하거나 수집된 정보를 다른 악의를 가진 이에게 판매할 수 있다.

    이러한 형태의 공격을 "DNS 캐시 포이즈닝(DNS cache Poisoning)"이라 부른다.
    리커시브 네임서버가 관리하는 캐시(cache)에 위-변조된 데이터를 저장하도록 유도하기 위한 공격 형태이다.

    이와 유사하게 "파밍(Pharming)"이라 하는 공격형태가 있다.

    파밍(Pharming)은 사이트 접속 트래픽을 진짜 사이트처럼 위장된 사이트로 전환시키는 것을 목적으로 하는 모든 다양한 형태의 공격을 가리킨다.
    파밍(Pharming)은 리커시브 네임서버의 DNS 캐시 포이즈닝 뿐만 아니라, 도메인 등록기관의 네임서버 위임등록 정보를 변경하여 도메인을 가로채는 공격형태, 호스트에 존재하는 hosts 파일의 설정 데이터를 변조하는 공격 형태까지를 모두 포괄한다.

    파밍(Pharming)의 위험성은 주로 피싱(Phishing)과 비교된다.

    피싱(Phishing)은 사용자로 하여금 접속하는 도메인 네임과 철자기 유사한 도메인 네임을 사용하여 부주의하게 위장된 사이트로 접속하게 한다.
    피싱(Phishing)은 사용자가 도메인 네임과 URL 등을 충분히 주의깊게 살피면 그 피해를 예방할 수 있다.

    그러나 파밍(Pharming)은 사용자가 올바른 도메인 네임을 확인하는 등의 충분한 주의를 기울이더라도 이 도메인 네임의 IP 주소가 이미 위-변조된 주소로 매핑되어 있어서, 위장된 서버에 접속하는 것을 피할 수가 없다.
    이 점에서 위협적인 공격 형태로 인식되고 있다. 사용자가 아무리 주의하더라도 자신이 가짜 IP 주소를 갖는 사이트에 접속하고 있다는 사실을 사용자는 쉽게 알아챌 수 없다.

    파밍(Pharming)은 DNS 캐시 포이즈닝 공격으로 유발될 수 있다.

    특히 DNS 캐시 포이즈닝의 경우, 공격 대상인 리커시브 네임서버를 사용하고 있는 수많은 호스트들이 모두 동시에 이 공격의 피해자가 될 수 있다는 점에서 심각한 위협요인을 가지고 있다.

    DNS 보안 확장(DNSSEC) 표준의 개발

    도메인 네임 시스템(DNS) 표준은 이와 같은 침해공격의 가능성을 고려하지 않던 시대에 정해진 표준 프로토콜이다.
    인터넷이 상업적으로 이용되기 시작하면서, 이러한 침해공격으로부터 DNS 데이터를 보호해야 할 필요성이 점차 중요하게 인식되고 있다.

    DNSSEC은 도메인 네임 시스템(DNS)이 제공하는 다양한 DNS 데이터가 데이터 위-변조 침해공격에 의해 위-변조되어 호스트 PC의 어플리케이션으로 전달되는 사태를 방지하기 위해 DNS 표준 프로토콜을 확장하고 보완하는 표준 프로토콜이다.

    DNSSEC의 도입적용은 DNS 데이터의 위-변조 공격을 원천적으로 불가능하게 하여 DNS 캐시 포이즈닝 공격을 불가능하게 만든다.

    현재 추진되고 있는 차세대 인터넷은 높은 수준의 보안 안전성을 필요로 한다.
    차세대 인터넷 환경에서의 DNS에 대해서도 그 근본적 보안 취약점을 극복함으로써 신뢰할 수 있는 데이터를 차세대 인터넷 응용 어플리케이션에 제공할 수 있는 안전한 기반 인프라 시스템으로의 진화가 요청되고 있다.

    DNSSEC은 안전하고 신뢰성을 보장할 수 있는 DNS를 구현하기 위한 표준 프로토콜이다.

    궁극적으로 인터넷 전체에 DNSSEC 기반의 DNS 체계가 완성된다면, DNS의 보안 안전성 향상은 단지 DNS의 안전성 향상에 그치는 것이 아니라, 모든 인터넷 어플리케이션의 보안기능을 보다 널리 적용할 수 있게 되어 인터넷 전체의 보안성을 전반적으로 향상, 강화시키는 효과를 기대할 수 있게 한다.

    예를 들면, DNSSEC이 적용된 DNS 환경을 대비하여, IPSec의 경우는 IPSec 메커니즘에서 필요로 하는 공개키 데이터를 DNS 시스템에 DNS 데이터로 설정 저장할 수 있도록 IPSECKEY RR을 표준 정의해 두고 있기도 하다.

    DNSSEC의 필요성

    전 세계적으로 발생하고 있는 상위의 루트 네임 서버(이하 루트서버)들에 대한 공격으로 인해 인터넷 기반시설에 대한 보호가 이슈가 되었다.

    DNS는 인터넷주소자원관리의 핵심 시스템으로서, 전 세계에 분산되어 있는 많은 네임 서버들 간의 계층적 상호 연동을 통해 사용자들에게 인터넷 접속을 위해 필수적인 주소 사상(mapping) 서비스를 제공한다. 하지만, 계층 구조상 최상단의 루트서버가 공격을 받아 피해를 입거나, 혹은 상위 레벨 네임서버의 데이터가 위·변조된다면, 특히 공공 및 금융 등 인터넷 가상세계의 여러 분야에서 큰 혼란을 가져올 수 있다. 서비스 거부 공격(DoS, DDoS) 등 네임서버의 기능을 마비시키기 위한 공격들은 기존의 분산 DNS 구조 자체의 특성과 필터링 기술 등을 통해 적절한 대응 방안의 도출이 가능하지만, 네임서버 데이터의 위·변조 발생 시 이에 대한 적절한 대응방안은 없는 상태이다.

    도메인 네임 시스템의 데이터 위-변조는 리졸버 기능을 갖는 리커시브 네임서버가 응답된 DNS 데이터를 캐시에 저장하고 이 저장된 데이터로 수많은 호스트에게 응답한다는 점을 악용한다. 공격자는 위-변조된 DNS 데이터를 갖는 응답 메시지를 사용하여 리커시브 네임서버를 속이고 캐시에 저장하도록 하여 호스트들이 위-변조된 데이터를 응답받아 어플리케이션이 이에 따른 접속을 하도록 유도한다. 공격자가 금융 사이트로 모방하여 미리 마련한 위장된 서버에 사용자 호스트가 접속하도록 유도하고, 사용자가 아무 의심 없이 자신의 계정 정보 등 개인정보를 입력하도록 함으로써 개인정보를 획득하는 방식의 범법행위가 가능하다.

    이를 DNS 캐시 포이즈닝(cache poisoning) 공격이라고도 한다. 이러한 공격으로써 대표적인 것은 1997년 11월 당시 인터넷 최상위 도메인을 관리하던 InterNIC 사이트에 접속하는 웹 트래픽이 InterNIC 사이트가 아닌 Alternic 사이트에 접속되는 일이 미국에서 발생했다. 이는 유진 카쉬푸레프(Eugene Kashpureff)가 도메인 네임 시스템의 데이터를 위-변조하여 리커시브 네임서버의 캐시에 반영토록 하는 조작에 의해 발생하였다. 그는 Alternic의 설립자로써 당시 인터넷 최상위 도메인을 독점 관리하고 있던 InterNIC에 대한 반발을 표시하기 위해 그러한 공격을 시도했다고 알려지고 있다.
    이외에 비교적 최근인 2005년 상반기에 리커시브 네임서버의 캐시 포이즈닝(cache poisoning) 공격이 이루어져 많은 수의 네임서버가 이 공격에 의해 피해를 입는 일이 발생했었다.

    사용자가 충분한 주의를 기울이면 피할 수 있는 피싱(phishing)과는 달리, 이러한 DNS 캐시 포이즈닝(cache poisoning)은 사용자가 정상적인 도메인 네임을 입력하여 서비스 접속을 시도하더라도 이미 네임서버 캐시에 저장된 위-변조된 주소 데이터가 응답되어 오기 때문에 사용자로서는 이에 대응하거나 이를 방지할 수단이 없다. 따라서 이러한 공격에 대해서는 네임서버 시스템 관리자에 의한 DNS 캐시 포이즈닝(cache poisoning) 방지를 위한 철저한 감시와 관리가 요구된다. 그러나 이 공격을 감지하거나 모니터링하기란 용이하지 않으며, 이러한 공격은 은밀하게 국지적으로 이루지기 때문에 공격이 있었다는 것을 알지 못하고 지나칠 수도 있다.

    도메인 네임 시스템에서의 DNS 캐시 포이즈닝(cache poisoning)과 같은 데이터 위-변조 위험으로부터 네임서버를 보호하기 위한 확장 표준이 DNSSEC이다. DNSSEC 표준은 보안측면에 평가할 때, 데이터 위-변조 방지가 원천적으로 불가능한 아주 강력한 보안적용 체계로 평가되고 있다. 그러나 그만큼 그 적용과 관리가 복잡하고 어렵다고 평가되고 있기도 하다.

    DNSSEC 적용의 효과는 데이터 위-변조를 방지한다는 측면에만 그치는 것은 아니다. 일단 DNSSEC의 적용에 의해 데이터 위-변조가 불가능하게 된 도메인 네임 시스템 그 자체가 안전하고 보안 신뢰성이 큰 개방형의 분산구조 데이터베이스로써 기능하게 된다. 이는 보안기능을 가진 응용 어플리케이션 프로토콜에서 필요로 하는 시스템 차원의 시스템 공개키 정보를 안심하고 도메인 네임 시스템에서 리소스 레코드(resource record)로 설정할 수 있게 된다는 것을 의미한다. 널리 사용되고 있는 공개키 암호 방식에서의 공개키는 누구에게나 널리 공개하여 배포하는 것을 필요로 하는데, 이는 인터넷의 개방형 시스템인 도메인 네임 시스템의 특성에 적합하다. DNSSEC의 적용으로 데이터 자체의 위-변조 위험이 사라질 때, 도메인 네임 시스템은 이러한 시스템 간 통신에 필요한 공개키의 배포와 같은 용도로 활용될 수 있다. 이는 특히 인터넷 인프라 차원에서의 보안 메커니즘이 보다 안정적이고 강력한 보안체계를 구성하는데 활용될 수 있을 것으로 예상된다. 이미 IPSec 표준사항 중에는 IPSec에 필요한 공개키를 DNSSEC 적용 환경 하에서 DNS의 IPSECKEY 리소스 레코드에 설정하여 사용할 수 있는 방안을 정의하고 있기도 하다. SSH 접속의 경우에는 SSHFP RR을 정하여 DNSSEC 적용 환경에서 접속 대상 호스트의 공개키에 대한 핑거프린트(fingerprint) 값을 DNS에 저장하고 참조할 수 있는 방안을 표준으로 정의하고 있기도 하다.

    이와 같이, DNSSEC의 도입적용은 도메인 네임 시스템의 데이터에 대한 위-변조 위험에 대한 네임서버 보호라는 측면과 함께 적극적으로는 안전하고 신뢰성 있는 도메인 네임 시스템을 구축함으로써 인터넷 전반의 보안기능 적용이 용이한 인터넷 기반 환경을 제공할 수 있다는 측면을 함께 지니고 있다.

    DNSSEC 구성

    DNSSEC은 전자서명과 서명검증 절차를 지원하기 위한 신규 리소스 레코드를 정의하였다.
    이에는 RRSIG RR, DNSKEY RR, NSEC RR, DS RR의 4 가지가 있다.

    리소스 레코드 각각의 주요 용도는 다음과 같다.

    RRSIG(Resource Record Signature) RR은 도메인 네임 시스템의 각 리소스 레코드 데이터에 대한 전자서명 데이터를 저장하기 위한 리소스 레코드이다. RRSIG은 서명 데이터만 단순하게 제공하는 것은 아니며 전자서명에 관련된 여러 가지 정보 필드를 함께 정의하고 있다. RRSIG은 DNS 응답 메시지에 그 서명 대상 리소스 레코드와 함께 응답된다.

    DNSKEY(DNS Public Key) RR은 도메인 존(zone)의 공개키(public key) 데이터를 저장하여 제공하기 위한 리소스 레코드이다. RRSIG RR에서 제공되는 리소스 레코드별 전자서명에 대한 서명검증 절차는 이 서명에 사용된 개인키(private key)에 상응하는 공개키(public key)를 필요로 한다. 이 공개키의 소유자는 도메인 존(zone)이며, 도메인 존(zone)의 공개키(public key)는 DNSKEY RR에 저장되어 DNS 질의응답을 통해 배포된다.
    하나의 도메인 존에는 두 가지 공개키 암호화 방식의 키 쌍(key pair)이 존재한다.
    하나는 도메인 존(zone)의 소유하고 있는 모든 리소스 레코드 각각을 서명하기 위한 키 쌍(key pair)이다. 이 키 쌍 중에서 공개키(public key)를 “ZSK(Zone Singing Key)”라고 한다. 곧, 존을 서명하는 데에 사용된 개인키에 대응하는 공개키임을 의미한다.

    다른 한 쌍은 존을 서명하는 데에 사용된 개인키의 대응 공개키인 ZSK 자체를 서명하기 위한 키 쌍(key pair)이다. 이 중에서 공개키(public key)를 “KSK(Key Signing Key)”라 한다. 곧, 공개키인 ZSK를 서명하는 데에 사용된 개인키의 대응 공개키임을 의미한다.

    DS(Delegation Signer) RR은 DNS 고유의 위임체계에 따라 보안측면의 인증된 위임체계를 구성하기 위한 데이터를 저장한다. 여기에 저장되는 데이터는 자식 도메인 존(zone)의 공개키 중에서 KSK(Key Signing Key)에 대한 다이제스트(digest) 데이터이다. 이 다이제스트(digest) 값은 KSK 공개키 데이터에 대한 지문(fingerprint) 역할을 한다. 곧, 하위 자식 도메인 존(zone)의 KSK를 확증할 수 있는 수단을 제공함으로써, 부모 도메인 존(zone)의 인증된 권한에 의해 자식 도메인의 KSK를 인증할 수 있게 한다. 이를 통해 부모 도메인과 자식 도메인 간에 인증사슬(authentication chain)을 형성한다. 이 DS RR은 부모 도메인 존(zone)이 소유하는 리소스 레코드이며, 따라서 부모 도메인 존(zone)의 ZSK(Zone Signing Key)의 대응 개인키로 서명한 RRSIG RR이 DS RR에 대하여 생성되어 제공된다.

    NSEC(Next Secure) RR은 DNSSEC이 제공하는 보안 기능 중 “DNS 데이터의 부재 인증(authenticated denial of existence of DNS data)”을 위해 정의된 리소스 레코드이다. 특정 리소스 레코드가 존재하지 않음을 전자서명을 통해 인증할 수 있는 메커니즘을 제공하기 위한 리소스 레코드 타입이다. 이는 도메인 존에서 설정하여 존재하고 있는 도메인 네임이 존재하지 않는 것으로 위-변조하여 응답되는 경우, 또는 존재하고 있는 리소스 레코드를 존재하지 않는 것으로 위-변조하여 응답되는 경우에 대하여 실제로 그 도메인 네임이나 리소스 레코드의 존재여부를 서명검증을 통해 확인할 수 있는 수단을 제공하기 위함이다.

    NSEC RR은 DNSSEC의 적용상에서 문제점을 유발하는 요소로 인식되고 있다.
    NSEC RR의 목적이 “DNS 데이터의 부재인증”을 위한 것이지만, 이는 역으로 도메인 존에 설정되어 있는 전체 도메인 네임 리스트와 리소스 레코드 리스트를 쉽게 파악할 수 있는 도구로 활용될 수 있다. 이 문제는 존 목록화(zone enumeration) 이슈로 알려져 있다. 이 문제 외에 .COM이나 .NET, .KR과 같이 위임설정 정보만 갖는 도메인 존에서 NSEC RR이 존재함으로 인해, 도메인 존의 서명된 데이터가 급증하고, 일반 도메인에 대한 대량의 위임설정 정보 각각에 대한 서명처리로 인해 DNSSEC 적용이 곤란하고 비용이 과다하게 발생한다는 문제점이 있다. 이 문제를 해소하기 위해 IETF DNSEXT 워킹그룹에서는 NSEC RR의 기능을 대신할 수 있는 NSEC3 RR에 대한 표준화 작업이 진행 중에 있다.

    DNSSEC은 리졸버에서의 신뢰할 수 있는 서명검증이 가능하도록 설계된 표준이다. DNSSEC 표준의 RRSIG RR과 DNSKEY RR, DS RR을 사용하여 리커시브 네임서버의 리졸버는 응답된 리소스 레코드 데이터에 대한 서명검증을 수행한다. 서명검증 대상 데이터는 기존의 리소스 레코드 데이터이며, 서명은 RRSIG RR에서 얻을 수 있고, 이 서명에 대한 검증에서 필요한 공개키 데이터는 도메인 존의 DNSKEY RR에 대한 질의응답으로 얻는다. DNSKEY RR 자체에 대한 위-변조 위험 가능성이 존재하므로 이에 대한 검증 또한 필요하다. 그 부모 도메인 존에서 서명된 위임설정의 DS RR과 이 DS RR에 대한 서명을 갖는 RRSIG RR, 그리고 부모 존의 공개키를 갖는 DNSKEY RR을 질의응답으로 조회하여 서명 검증을 수행한다. 이러한 검증은 상위 도메인으로 지속되며, 결국에는 리커시브 네임서버에 미리 설정된 신뢰앵커(Trust Anchor)를 사용한 검증이 가능하게 되면 그 검증은 신뢰할 수 있게 된다.

    DNS 보안 취약점

    도메인 네임 시스템(DNS)은 인터넷 초기에 보안을 고려하지 않고 설계된 프로토콜이다.

    시간이 지남에 따라 인터넷은 급속히 확장되었고, 인터넷을 사용하는 시스템과 서비스에 대한 침해공격 시도가 증가하였다. 도메인 네임 시스템에 대해서도 역시 이러한 침해공격 시도가 발생하였다. 도메인 네임 시스템은 인터넷의 기반 인프라 시스템으로써, 침해공격에 의해 서비스 불안정 또는 서비스 중단 사태가 발생할 경우, 도메인 네임 시스템에 의존하는 많은 인터넷 서비스가 함께 서비스 장애발생 사태를 맞게 된다는 점에서 문제의 심각성을 인식하게 되었다.

    DNS에 대한 위협은 크게 세 가지 정도로 분류할 수 있다.
    서비스거부(DoS) 취약점, 프로그램 취약점, 속이기(spoofing) 취약점이 그것이다.

    ‘서비스거부(Denial of Service)’ 공격은 공격자가 불필요한 질의를 대량으로 발생시켜 목표 네임서버가 해당 질의를 처리하는 동안 다른 정상 서비스요청에 대해서는 응답을 못하게 하는 방법으로서 2002년 10월 전 세계 최상위에 있는 13개 루트서버에 대해 이 공격이 시도된 바 있다. 당시 약 1시간 동안 진행된 공격에 의해 전 세계의 9대 정도의 서버가 접속지연 등 일시적으로 영향을 받았으나 공격시간이 1시간으로 지속적이지 못했고 이상발견 즉시 각 루트서버 관리자들이 적절한 네트워크 트래픽 필터링을 실시하여 일반 인터넷 사용자가 어떤 영향을 느낄 정도로 파급효과가 크지는 않았다. 하지만 이 사건은 의외로 단순한 기술로 인터넷 역사상 유례가 없는 13개 루트서버에 대한 전면적인 공격을 감행했다는 점에서 인터넷 기반시설에 대한 대규모 위협이 현실화하고 있다고 볼 수 있다.
    ‘프로그램 취약점’은 네임서버 프로그램 버그에 의한 취약점을 의미하며 이 취약점에 의해 네임서버 프로그램이 중지되거나 시스템 전체가 장악될 수도 있다. 현재는 네임서버 프로그램의 버그 발생 시 그 파급효과를 우려하여 이른 시간 안에 수정용 패치 프로그램이 만들어지고 있다.

    ‘속이기(이하 ‘스푸핑’) 취약점’은 말 그대로 네임서버가 주고받는 정보를 악의의 공격자가 임의로 조작하여 인터넷상에 퍼뜨리는 일로서 경우에 따라서는 공격을 받았는지 여부를 발견하기 어려워서 그에 따른 피해도 매우 커질 수도 있다.

    이상의 취약점들이 모두 큰 위협이 될 수 있지만 궁극적으로 가장 위험한 취약점은 일명 ‘스푸핑(spoofing)’으로 알려진 네임서버 정보에 대한 위변조 위협이다. 예를 들어 우리가 인터넷 뱅킹을 이용할 때 사용하는 특정 도메인네임이 공격자에 의해 위변조 되었다면 해당 사이트가 아닌 악의의 공격자가 실제 사이트와 동일하게 제작한 가짜 사이트에 들어가 별다른 의심 없이 로그인을 하는 등 자신의 개인정보를 그대로 노출시킬 수도 있다.

    도메인 네임 시스템이 제공하는 데이터에 대한 위-변조 공격시도가 있어 초기의 대표적인 사건으로는 1997년 11월 당시 인터넷 최상위 도메인을 관리하던 InterNIC 사이트에 접속하는 웹 트래픽이 InterNIC 사이트가 아닌 Alternic 사이트로 접속이 전환된 사건이다. 이는 유진 카쉬푸레프(Eugene Kashpureff)가 도메인 네임 시스템의 데이터를 위-변조하여 리커시브 네임서버의 캐시에 반영토록 하는 조작에 의해 발생하였다. 그는 Alternic의 설립자로써 당시 인터넷 최상위 도메인을 독점 관리하고 있던 InterNIC에 대한 반발을 표시하기 위해 그러한 공격을 시도했다. 그는 처음에는 주말 동안 트래픽을 전환시켜 놓고 다시 원상태로 복구했으나, InterNIC 등의 반응태도에 반발하여 다시 그 다음 주 주말 동안 트래픽을 전환시켜 버림으로써, 사실상 그의 의도대로 언제든지 네임서버의 데이터 위-변조를 통해 접속 트래픽을 원하는 곳으로 전환시켜 버릴 수 있다는 것을 보여주었다.

    이외에 비교적 최근인 2005년 3월경 리커시브 네임서버의 캐시 포이즈닝(cache poisoning)에 의한 공격이 이루어져 캐시 포이즈닝 검출 기능이 적용되지 않은 많은 수의 네임서버를 통해 피해가 발생했었다. 이에 대한 구체적인 내용은 SANS 사이트의 분석자료 http://isc.sans.org/presentations/dnspoisoning.php에서 확인할 수 있다.

    DNS 캐시 포이즈닝 공격방법은 다양하게 진화하고 있는 것으로 관측되고 있으며, 최근에는 “Birthday Attack”의 공격방법으로 DNS 캐시 포이즈닝 공격이 이루어질 수 있음이 보고되었다. 이는 위-변조된 DNS 응답 메시지로 리커시브 네임서버를 속이기 위해서는 DNS 메시지의 트랜잭션 ID를 리커시브 네임서버가 질의 시에 사용하는 랜덤 ID 값과 일치하는 값을 사용할 필요성이 있는데, “Birthday Paradox”라는 수학적 확률 명제를 응용하면 그 ID를 일치시킬 확률이 크게 증가하도록 할 수 있고 이를 응용한 “Birthday Attack”가 DNS 공격에 사용될 수 있다는 내용이다. 아직까지는 이런 “Birthday Attack”에 의해 피해가 발생한 사례는 보고되고 있지 않다. 그러나 BIND DNS의 경우에는 BIND 8 버전의 DNS를 사용하는 리커시브 네임서버가 이 공격에 취약할 수 있다. 반면에 BIND 9 버전 DNS의 경우에는 이 공격이 효과적으로 적용되지 않는다고 알려져 있다.

    최근 2006년 상반기에는 “Reflector Attack”이라는 새로운 형태의 공격이 발생한 바 있다. 이 공격은 네임서버를 공격대상으로 삼는 것이 아니라 네임서버를 제3의 공격대상 서버를 공격하는 데에 동원하는 방식이었다는 점에서 특이하다. 비록 DNS 네임서버를 공격하는 것은 아니지만, 그 공격에 사용된 방식은 DNS 프로토콜의 특성을 악용했다는 점에서 주목을 받았다. 이 공격방식은 DNS 질의에 사용되는 패킷이 통상 약 70바이트 크기를 갖는데 비해 그 응답 메시지의 패킷은 최대 4196바이트 크기를 갖는 경우를 만들 수가 있어, 질의 트래픽 대비 약 60배로 증폭된 응답 트래픽을 유발하는 것이 가능하다는 점을 공격에 응용하였다. 결과적으로 이 공격의 대상이 된 서버 호스트에게 DNS 응답 메시지로 구성된 1Gbps 이상의 트래픽이 집중하여 서비스 불능 상태에 빠졌다. 이에는 자신에게 질의할 수 있는 호스트 클라이언트를 제한하지 않은 설정을 가지고 있어서 누구나 이에 질의하여 응답을 받을 수 있는 리커시브 네임서버가 악의적인 공격에 동원되고 있었다. 이러한 설정의 리커시브 네임서버를 이른바 “개방된 DNS(Open DNS)”이라 한다.

    출처 : http://dnssec.nida.or.kr/

    Trackback 0 Comment 0