컴퓨터를 다루다

level16의 ID와 PW는 아래와 같습니다.

ID : level16

PW : about to cause mass

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

hint 파일을 살펴보면 다음과 같습니다.

[그림 1] level16 hint파일

힌트파일에서 attackme의 소스를 [그림 1]과 같이 보여주고 있습니다.

이 소스를 요약하면 다음과 같은 특징을 가집니다.

01. int 형으로 crap선언

02. *call에 printit이라는 함수의 주소를 저장

03. char형으로 버퍼 20byte 선언

04. 버퍼를 48byte 읽음

05. call 함수를 불러들임

06. shell이라는 함수에서 다음 권한으로 /bin/sh이 실행됨

우리는 먼저 fgets()함수로 불러오는 부분의 메모리를 살펴보고, call()이 왜 불러지는지를 살펴봐야 할 것 같습니다.

attackme를 atm으로 카피하여 분석해봅시다.

[그림 2] atm 파일을 gdb로 열어본 모습

main+39를 보니 call() 함수의 주소를 적어놓는 것 같습니다.

call()에는 printit()이라는 함수의 주소가 들어가 있습니다.

그리고, eax에 저장된 함수의 주소는 main+6를 보니 ebp에서 -0x10 떨어진 곳에 call() 함수의 주소를 저장하는 것 같습니다.

eax에 shell()이라는 함수의 주소를 적어주면 printit()이라는 함수 대신 shell()이 실행될 것입니다.

그럼 우리는 shell()함수의 주소를 확인할 필요가 있습니다.

[그림 3] shell함수의 실행주소 및 실행코드

shell() 함수의 주소는 0x080484d0입니다.

이제 eax에다가 저장하면 될 것 같습니다.

현재 eax에는 printit의 함수 주소, 0x8048500이 들어 있을 것입니다.

[그림 4] printit() 함수가 ebp-0x10에 있는 모습

ebp의 주소는 0xbfffde68로 0xbfffde88이라는 값을 가지고 있습니다.

그리고 ebp-0x10에는 printit()함수의 주소가 들어가 있는 것을 확인할 수 있습니다.

[그림 5] A*40개 + B*4개로 확인한 위치

A 40개와 B 4개를 입력하여 위치를 확인해보면 [그림 5]와 같은 상태를 확인할 수 있습니다.

즉, 40Byte의 더미값과 4Byte의 shell()함수의 주소를 넣어 shell()함수를 실행시키면 될 것 같습니다.

입력위치(/home/level15)

코드 : (python -c 'print "A"*40 + "\xd0\x84\x04\x08"';cat)| ./attackme

[그림 6] 문제 해결

leve15의 ID와 PW는 아래와 같습니다.

ID : level15

PW : guess what

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

hint 파일을 살펴보면 다음과 같습니다.

[그림 1] level15 hint파일

힌트파일에서 attackme의 소스를 [그림 1]과 같이 보여주고 있습니다.

이 소스를 요약하면 다음과 같은 특징을 가집니다.

01. int 형으로 crap선언

02. int 형으로 check선언

03. char형으로 20Byte만큼의 buf 선언

04. (level14와의 차이) *check가 가리키고 있는 곳의 Hex값이 0xdeadbeef라면 문제가 해결됨

우리는 먼저 이 check라는 변수가 어디에 위치하는지 알아야 합니다.

attackme를 역시나 atm으로 복사하여 gdb로 파일을 열어보도록 합시다.

[그림 2] atm 파일을 gdb로 열어본 모습

main+3을 보면 0x38만큼 스택의 장소를 마련하고, 이는 level14와 다르지 않다는 것을 알 수 있습니다.

그렇다면, level14와 마찬가지로 check의 위치를 알아낼 수 있을 것으로 추측됩니다.

main+32를 보면 0xdeadbeef와 %eax가 가리키고 있는 값을 비교하고 있는 것을 볼 수 있습니다.

그리고 main+29는 %eax에 0xfffffff0(%ebp)의 값을 넣고 있는 것을 알 수 있습니다.

그럼 우리는 (ebp-0x10)에 우리가 원하는 값을 넣어줘야 한다는 걸 추측할 수 있을 것입니다.

이 문제는 포인터와 어셈블리에서 값을 말하는지 포인터를 말하는지에 대해 구분할 필요가 있습니다.

level14와 level15에서는 ebp-0x10과 0xdeadbeef를 바로 비교하지 않고, ebp-0x10을 가리키는 어떠한 포인터를 한 번 더 붙이는 것을 볼 수 있습니다.

요약하면 [그림 3]과 같습니다.

[그림 3] level14와 level15를 비교한 그림

[그림 3]의 위는 level14의 풀이를 간단히 요약한 그림이고, 아래의 그림은 level15에서의 풀이를 간단히 요약한 그림입니다.

level15의 그림에서 0xdeadbeef의 Address를 넣어야 한다는 것을 의미합니다.

즉, 이는 0xdeadbeef라는 값을 가지고 있는 주소를 가리키면 된다는 의미입니다.

TIP을 살펴보면 0xdeadbeef의 address는 main함수 내에 있을 수 있다, 고 합니다.

이 말은 main함수에서 0xdeadbeef를 비교할 때 사용하기 때문에 0xdeadbeef는 메인함수의 어느 부분에 존재할 것이라는 의미입니다.

또한, 우리는 buffer에 0xdeadbeef를 쓰고, 그곳을 가리키면 될 것이라는 다른 접근 방법도 있을 것입니다.

작성자는 후자를 먼저 해보았지만... 안 되더군요.. 왜 안 되는지는 이론상으로는 알 수 없어, 전자로 풀었습니다.

그렇다면 우리는 ebp-0x10에는 0xdeadbeef를 넣어야 하는 게 아니라 0xdeadbeef를 가리키는 주소값을 넣어야 한다는 것을 알 수 있습니다.

main내에서 0xdeadbeef를 찾아보도록 합시다.

gdb atm -q를 통해 main함수를 열어보면 main+32에서 0xdeadbeef와 비교하는 모습을 볼 수 있습니다.

그렇다면 우리는 main+29~main+32 내에 0xdeadbeef가 숨어있을 것으로 생각할 수 있습니다.(물론 저는 풀다가 겨우 알았습니다....)

[그림 4]는 main+30부터 쭉 열어본 모습입니다.

[그림 4] main+30부터 열어본 모습

0x80484ae~ 0x80484ee까지 열어보았습니다. 0x80484b2에 0xdeadbeef가 있는 것을 볼 수 있습니다.

그렇다면 우리는 ebp-0x10에 0x80484b2의 값을 넣어주는 것이 해답일 것입니다..!!(헉헉)

입력위치 (/home/level15)

코드 : (python -c 'print "A"*40 + "\xb2\x84\x04\x08"';cat) | ./attackme

[그림 5] level16 비밀번호(my-pass 입력)

level14의 ID와 PW는 아래와 같습니다.

ID : level14

PW : what that nigga want?

(작성자는 이 Password를 좋아하지 않습니다.)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

hint 파일을 살펴보면 다음과 같습니다.

[그림 1] level14 hint파일

힌트 파일에서 attackme의 소스를 [그림 1]과 같이 보여주고 있습니다.

이 소스를 요약하면 다음과 같은 특징을 가집니다.

01. int형으로 crap선언

02. int형으로 check선언

03. char형으로 20Byte만큼의 buf 선언

04. buf[0]~buf[45]까지의 문자열을 읽어들임

05. check에는 비록 아무것도 없지만 check라고 선언된 부분의 Hex값이 0xdeadbeef라면 문제가 해결됨

우리는 먼저 이 check라는 변수가 어디에 위치하는지를 알아야 합니다.

attackme를 atm으로 복사하여 gdb로 파일을 열어보도록 합시다.

[그림 2] atm 파일을 gdb로 열어본 모습

main+3을 보아하니 0x38만큼 스택의 장소를 마련하는 것이 보입니다. 이는 십진수로 56, 즉 56Byte만큼 먼저 스택을 잡아준 것입니다.

아마 crap, check, buf의 변수를 모두 잡아준 것 같습니다.

이제 우리는 check의 위치를 보도록 합시다.

main+29를 보시면 0xdeadbeef와 0xfffffff0(%ebp)를 비교하는 것을 볼 수 있습니다.

0xfffffff0(%ebp)는 해석하면 $ebp-0x10과 같습니다. 즉, ebp에서 16바이트 위에 있는 값을 말하는 것입니다.

우리는 0xdeadbeef와 비교하는 곳이 check일 것이라는 추측을 할 수 있습니다.

x/x $ebp-0x10을 해보면 그 위치의 값이 나올 것입니다.

[그림 3] x/x $ebp-0x10을 한 모습

자 이제 이 녀석을 얼마나 입력해야 하는지 계산해보기 위해 스택을 살펴봅시다.

[그림 4] check의 위치 확인

check의 위치를 확인해보면 우리가 40바이트를 Dummy로 입력해준 후 그 위치에 0xdeadbeef를 입력하면 되는 것을 알 수 있습니다.

다음과 같이 코드를 입력하면 되겠습니다.

입력위치 (/home/level14)

코드 : (python -c 'print "A"*40 + "\xef\xbe\xad\xde"';cat) | ./attackme

[그림 5] level15 비밀번호(my-pass 입력)

level13의 ID와 PW는 아래와 같습니다.

ID : level13

PW : it is like this

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

hint 파일을 살펴보면 다음과 같습니다.

[그림 1] level13 hint 파일

힌트 파일에서 attackme의 소스를 [그림 1]과 같이 보여주고 있습니다.

level11, level12와는 다르게 다른 것들이 정의되어 있습니다.

특징을 살펴보도록 합시다.

01. long형으로 선언된 변수에 0x01234567이 들어가 있습니다.

02. char형으로 1024바이트의 배열을 선언합니다.

03. argv로 입력을 받고, argc(입력 값의 수)가 1개 이상(argv값이 입력되면)이면 buf 변수에 문자열을 복사합니다.

04. 만약 long형으로 선언된 변수의 값이 0x01234567에서 변조되면 " Warnning : Buffer Overflow !!!"를 프린트합니다. 그리고 바로 종료합니다.

long형이 먼저 선언됐으니까 RTL로 하기 위해서는 0x01234567의 위치도 알아야 이를 변조하지 않도록 할 수 있습니다. 먼저 스택의 형태를 보기 전에 gdb로 열어보도록 합시다.

이번 분석도 마찬가지고 /tmp에 atm이라는 이름으로 attackme를 복사하여 분석을 진행하도록 해봅시다.

[그림 2] atm 파일을 gdb로 열어본 모습

gdb로 열어보았을 때, 이전보다는 꽤 긴 모습을 볼 수 있습니다.

먼저 [그림 2]를 요약해보면 특징에서 나타난 내용과 같다는 것을 알 수 있습니다.

그렇다면, 우리는 0x01234567의 위치와 버퍼가 어디에서 시작되는지를 알 필요성이 있습니다.

작성자는 1024바이트만큼 입력하고 이를 살펴보았습니다.

gdb 명령어 :

01. r `python -c 'print "A"*1024'`

02. x/300x $esp

이제 Stack을 살펴보면 [그림 3]과 같습니다.

[그림 3] 1024개의 A를 넣어본 Stack의 모습

저렇게 A가 1024개나 밖혀있는 모습을 볼 수 있습니다.

우리는 이제 RET와 long i를 찾아야 하는데, 먼저 0xbffff4b0의 마지막 줄을 보면, 0xbffff4bc부터 0x01234567이 있다는 것을 알 수 있습니다.

그리고 RET는 0xbffff4cc으로 예상할 수 있습니다.

작성자는 argc와 argv를 통해 알아내는데, argv는 address가 들어가기 때문에 0xbffffd4를 4바이트만큼 열어보면 또 다시 주소가 나올 것입니다.

이는 argv의 값을 가지고 있는 위치이며 이를 string으로 프린트하면 /home/level13/tmp/atm으로 나올 것입니다.

즉, argv 앞은 argc, 그리고 그 앞은 RET라는 예측을 할 수 있습니다.

따라서 우리는 A*1036 + "0x01234567" + "A"*12 + "system address" + "AAAA" + "/bin/sh addreess"와 같은 방법으로 풀이가 가능합니다.

입력 위치(/home/level13)

코드 : ../attackme `python -c 'print "A"*1036 + "\x67\x45\x23\x01" + "A"*12 + "\xc0\xf2\x03\x42" + "AAAA" + "\xa4\x7e\x12\x42"'`

[그림 4] my-pass로 얻어낸 모습

level12의 ID와 PW는 아래와 같습니다.

ID : level12

PW : it is like this

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

hint 파일을 살펴보면 다음과 같습니다.

[그림 1] level12 hint 파일

힌트 파일에서 attackme의 소스를 [그림 1]과 같이 보여주고 있습니다.

level11과의 차이점은 gets() 함수로 문자열을 입력받는 점입니다. 우리는 argv로 값을 넘겨주는 것이 아닌 파일을 실행한 후 값을 넘겨줘야 합니다.

우리가 사용할 기법은 Return To Library로 사용할 것입니다.

여기서 필요한 요소는 총 세 가지로 다음과 같습니다.

(1) 프로그램 내에서 사용하는 Library 중 system 함수의 주소

(2) system 함수 내의 '/bin/sh'의 주소

(3) 우리가 이용할 Return의 주소

이제 gdb를 이용하여 소스코드를 자세하게 분석하여 봅시다.

gdb로 run이 되지 않으면 tmp 디렉토리에 파일을 카피하여 카피한 파일로 열어보도록 합니다.

설명 : level11_FTZ_RTL기법 참고

작성자는 tmp파일에 atm이라는 이름으로 attackme를 복사하여 분석을 진행하였습니다.

[그림 2] gdb로 열어본 atm의 모습

atm은 다음과 같이 나타나 있습니다.

요약하면 0x108만큼 공간을 마련한 후 이곳에 gets()함수로 받은 문자열을 0x108에 저장하고 이를 print합니다.

[그림 3] system 내의 /bin/sh의 주소를 프린트하는 소스

system의 주소는 main에 breakpoint를 걸어준 후 p system을 하면 주소가 나오게 됩니다.

이후 shell 부분에 system 주소를 HEX 값으로 입력하면 그 주소로부터 1바이트씩 옮겨가며 8바이트씩 비교하여 '/bin/sh'인지 체크를 합니다.

level11과의 차이는 gets()함수로 받기 때문에 argv처럼 입력받는다 하여도 해결할 수 없게 됩니다.

때문에 우리는 code를 다르게 만들어 풀어야 할 것입니다.

작성자는 다음과 같은 방법으로 풀었습니다.

(python -c 'print "A"*268 + "system addr" + "AAAA 혹은 Return address" + "/bin/sh address") | cat > Data

와 같이 Data에 우리가 쓸 코드를 만들었습니다.

완성된 문장 : (python -c 'print "A"*268 +"\xc0\xf2\x03\x42" +"AAAA"+ "\xa4\x7e\x12\x42"') | cat > data

GDB에서는 'r < Data'와 같이 프로그램을 실행하여 비교를 진행하였고, 제대로 작동될 것이 예상되면 tmp 디렉토리에서

(cat Data;cat) | ../attackme 와 같이 명령어를 실행해줍니다.

[그림 4] 문제 해결

level11의 ID와 PW는 아래와 같습니다.

ID : level11

PW : what!@#$?

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

먼저 hint 파일을 살펴보면 다음과 같습니다.

[그림 1] level11 hint 파일

힌트 파일의 내용은 attackme의 프로그램 소스코드로 추정되고 이를 토대로 exploit을 시켜야 함을 암시하는 것 같습니다.

우리가 사용할 기법은 Return To Library입니다.

여기서 필요한 요소는 총 세 가지 입니다.

(1) 프로그램 내에서 사용하는 Library 중 system 함수의 주소

(2) system 함수 내에 '/bin/sh'의 주소

(3) 우리가 이용할 Return의 주소

이제 GDB를 이용하여 소스코드를 자세하게 분석하여 봅시다.

[그림 2] gdb run Error

때문에 우리는 attackme 파일을 tmp에 복사하여 그것으로 분석해야 합니다.

작성자는 tmp에 atm라는 이름으로 복사하여 분석을 진행하였습니다.

[그림 3] atm를 gdb로 열어본 모습

(1) 메인을 요약해보면 0x108만큼 스택의 공간을 마련합니다.

(2) 기타적인 작업...

(3) 우리가 입력한 값을 strcpy의 인자값으로 넣어 실행시키고, (ebp-0x108)의 값을 eax에 넣어 push해주는 것을 볼 수 있습니다.

(4) 이후 이를 print해줍니다.

먼저 main에 break point를 걸어주고 run을 해준 후, p system 을 입력하여 프로그램 내에서 사용하는 library 내의 system 주소를 가져올 수 있습니다. 우리는 system 함수의 주소가 0x4203f2c0임을 알 수 있습니다.

[그림 4] system 함수의 주소

system 함수의 주소를 알아냈으니 우리는 이제 /bin/sh 의 주소를 알아낼 소스코드를 작성하여 봅시다.

우리가 system 함수의 주소가 0x4203f2c00 이므로 그 주소로부터 1 Byte 씩 하나씩 shift하여 8 Byte씩 비교하여 hex로 "/bin/sh"를 찾아냅니다. 이 주소를 print 하는 프로그램입니다.

[그림 5] /bin/sh의 위치를 찾아내는 C 코드

이제 이 소스코드를 실행시키면 atm 실행파일 내의 system 함수에서 사용하는 /bin/sh의 주소를 찾아내어 프린트 해줍니다.

/bin/sh의 주소는 [그림 6]과 같습니다.

[그림 6] system 함수에서 하용하는 /bin/sh 주소

이제 다음으로 우리는 사용할 ret 주소를 찾아내야 합니다.

[그림 7]에서는 main에서 strcpy 실행 이후에 break point를 잡아 esp에서부터 300Byte의 값을 나타낸 것입니다.

A를 256개를 채운 그림입니다.

[그림 8] main+53에서 멈춘 Stack 모습

[그림 8]에서 RET은 main 함수의 return 0의 RET으로 추정됩니다.

이를 추측한 계기는, RET 앞의 (1)번이 argc일 것으로 추정하였고, argc가 2일 것으로 추정되었습니다.

그렇다면 (2)번은 argv[0]일 것으로 추측하여 한 번 살펴보았습니다. 살펴본 결과는 [그림 9]와 같습니다.

[그림 9] argv[0]임을 확인

현재 [그림 9]에서 보듯이 argv[0]이고 이 다음 주소의 값은 argv[1]의 값입니다.

그렇다면 우리가 덮어써야 할 부분은 A가 256개가 아닌 3칸(4Byte씩)을 더 한 268Byte 떨어진 부분임을 알 수 있습니다.

필요한 세 가지 요소를 모두 찾았습니다. 그럼 이제 Exploit을 해야 하는데, 이를 더 간편하게 하기 위해서는 python 코드로 하는 것도 나쁘지 않아 보입니다. [그림 10]은 SecuMaster 동아리 현 부회장(2016년)의 도움을 받아 작성한 소스입니다.

[그림 10] exploit python 코드

sysaddr는 system 함수의 주소, binsh_addr는 /bin/sh의 주소를 저장하는 변수입니다.

그리고 이를 struct.pack을 이용하여 리틀 엔디언으로 저장합니다.

페이로드는 268개의 A(혹은 nop, \x90) + system address + "4Byte 쓰레기 값 혹은 다른 리턴 값" + binsh address

로 작성하면 됩니다.

[그림 11] exploit 코드를 실행한 모습

jump

Jump

jump