choiys

textbox에 있는 내용은 search 파라미터를 통해 post로 전송되며, single quotation과 함께 전송하면 SQLi를 유발시킬 수 있다.

이 때 에러 메시지를 통해 쿼리문 전체를 알아낼 수 있다.

SELECT news.*,text.text,text.title FROM level7_news news, level7_texts text WHERE text.id = news.id AND (text.text LIKE '%a'%' OR text.title LIKE '%a'%')

like문에서 SQLi가 발생하며, parentheses를 열고 닫음으로 구문을 마무리 후 union을 통해 원하는 컬럼을 추출해낼 수 있다.

이 중 TestUserforg00gle이 username이 되며, 이를 입력하면 플래그를 얻을 수 있다.

[Problem]

중간 부분의 명암이 다른 것으로 보아, 해당 부분에 플래그가 있을 것이다.

[Scenario]

python PIL 라이브러리를 이용하여 해당 부분의 rgb 값을 찾아내어 ascii 변환을 통해 flag를 도출해낸다.

[Payload]

#coding: utf-8
from PIL import Image

with Image.open("oxygen.png") as im:
    rgb_im = im.convert('RGB')
    width, height = im.size
    res = ""
    for x in range(0, width,7):
        r, g, b = rgb_im.getpixel((x, 45))
        res += chr(r)
    print res

payload.py

#coding: utf-8

data = [105, 110, 116, 101, 103, 114, 105, 116, 121]

res = ""
for d in data:
    res += chr(d)

print res

flag.py

flag : integrity

page 파마리터에서 터집니다

힌트대로

SuNiNaTaS

Web Level7

7번째 문제입니다. 들어오자마자 아이유가 반겨주네요... 좋습니다.

아래로 조금 내려보니 YES라는 버튼이 있는데... 한번 눌러보도록 하죠.

버튼을 눌러보니

느리답니다...

YES 버튼이 아래 있기 때문에 손으로는 누르기 어려울 것 같습니다.

소스를 한번 확인 해 보도록 하죠.

js로 Tab과 F5를 막아놓았네요. 두 번째의 else if는 컨트롤R, N을 막고 있습니다. 컨트롤R은 F5와 동일한 기능을 하고, 컨트롤N은 새 창 띄우기를 막아 놓은 듯 합니다.

아무튼 탭과 새로고침을 통해 YES버튼을 누르는 것은 포기하는 편이 좋을 것 같습니다.

아래의 힌트를 보니 Faster and Faster, 최대한 빠르게 눌러보라고 합니다. 우리 손으로는 힘들 것 같으니, 프로그램의 도움을 받아보도록 하죠.

header에 referer를 넣어 web07.asp를 거치지 않고 바로 web07_1.asp로 들어가보았지만, 결국 실패하여.. web07.asp를 거쳐 web07_1.asp로 들어가는 코드를 작성했습니다.

(작성 하고 나서 수정하다보니 알게 된 것인데, 굳이 POST 요청을 때리지 않아도 키 값은 나오는 듯 합니다. req2에서 param 데이터는 굳이 넣지 않아도 무방합니다.)

짠! 키값을 뱉어내주었습니다.

level7의 소스입니다. 이전 레벨에서 볼 수 있었던 snprintf 함수의 취약성을 이용한 FSB와 비슷한 듯 합니다.

차이점으로는 main 함수에서 직접 처리하는 것이 아닌 vuln 함수에서 처리한다는 점 빼곤 없어 보입니다. 아, 또 다른 점으로는 buffer 변수의 결과 값을 출력 해 주지 않는다는 점이 있겠습니다. 자, 그럼 실행하면서 어떤식으로 풀어야 할 지 찾아보도록 하죠.

prtf() = 0x80486e0 (0xffffd64c) 부분을 확인 해 보면 괄호 안에 있는 부분은 ptrf 포인터 변수의 주소이고, 왼쪽의 값은 goodfunction 함수의 주소입니다. 이 값을 hackedfunction의 주소인 0x8048706으로 변경하여 shell을 띄우는 게 이번 레벨의 목표인 것 같습니다.

하지만 이전 레벨과 달리 buffer의 변수를 printf로 출력 해 주지 않기 때문에 얼마나 %x 서식문자를 입력 해 주어야 buffer 변수에 접근 할 수 있는지 알 수가 없습니다. 따라서 gdb를 이용해 스택 값을 확인하여 0xffffd64c의 값의 변화를 직접 확인하는 쪽으로 풀이하였습니다. 노가다죠.

vuln 함수에서 snprintf를 한 직후에 breakpoint를 걸어주고 실행하였습니다. 여기서 FSB를 위해 측정한 거리는 다음과 같습니다.

34542 = 0x8706(34566) - 16 - 8

33046 = 0x10804(67588) - 34542

위와 같이 거리를 구한 후 대입 해 주었으나, gdb 상에서 실행하였기에 파일명이 절대경로로 들어가 argv[0]이 변해서 ptrf의 주소 값이 바뀌었습니다. 그래서 그대로 대입을 해 주었으나, ptrf의 값이 바뀌지 않은 것을 보니 %8x를 한 번 사용했을 때는 buffer 변수에 접근을 못하는 듯 합니다. %8x와 거리 값들을 바꿔주변서 계속 시도하다 보면 아래와 같이 ptrf 포인터의 값이 변하는 부분을 찾을 수 있습니다.

%8x를 총 5번 사용했을 때 buffer 변수에 접근 할 수 있다는 것을 확인 할 수 있는데, 이상한 게 한 가지 있습니다.

예상대로라면 buffer 변수에 접근했을 때 ptrf 포인터의 값은 0x08048706이 되어야 하는데, 0x8706은 정상적으로 overwrite 된 반면 0x0804는 0x083c로 들어가 있는 것을 확인 할 수 있었습니다. 원인은 공부가 부족하여 찾지는 못했습니다. 계산법이 틀린건지, 놓친 부분이 있는 것인지는 잘 모르겠습니다. 혹시 아시는 분이 있다면 댓글로 지적 부탁드립니다. :D

일단 답을 찾아내기 위해... 3c에서 04까지의 거리인 0x38(56)을 빼주고 실행해봅시다.

어떻게든 답은 찾아냈습니다. :D

Level7입니다. Narnia도 끝이 다가오네요.

코드를 보면 처음에 fp라는 이름의 int형 포인터에 puts함수의 주소를 넣어줍니다.

이는 곧 fp를 함수포인터로 사용한다는 의미가 되겠네요. 인자는 puts와 동일한 (char *)형입니다.

그리고 환경변수와 argv[3] 이후의 값들을 모두 제거하네요.

다음으로 취약점이 발생하는 strcpy문이 2번 호출됩니다. b1와 b2에 argv[1]와 argv[2]를 덮어씌워주는데, b2가 b1보다 나중에 선언되기 때문에 b1이 high address가 되겠네요. 따라서 b2에서 buffer를 overflow 시키게 된다면 b1의 값에도 영향을 미칠 것입니다.

그리고 esp의 값을 0xff000000과 and 시켜 결국 fp의 값이 스택 영역일 경우 프로그램을 종료시킵니다. 이는 스택에 쉘코드를 직접 넣어 실행 시킬 경우를 막아놓은 장치인듯 합니다.

마지막으로 b1을 인자로 fp(puts) 함수를 호출시킵니다.

대충 감이 오지 않나요? 일단 한번 실행을 해 보겠습니다.

b1과 b2의 값을 변경시켜가면서 출력을 해 봤더니 b1의 값이 8바이트 이상 입력 될 시 segmentation fault가 나타나는 것을 확인 할 수 있습니다.

b2의 값은 overflow 시켰을 때 16바이트를 입력하면 segmentation fault가 일어나는 것으로 보아, b1과 b2 사이에 dummy byte는 따로 없는 것 같습니다.

그렇다면 여기서 생각 할 수 있는 것은 b1[8]의 상위 스택에 바로 sfp, ret가 있거나 다른 경우의 수가 있다는 것입니다.

하지만 이 코드의 경우 gdb로 분석 해봤을 때 exit(1)로 끝나는 코드이기 때문에 leave;ret이 없는 것으로 보아 첫 번째 경우는 제외하였습니다.

그럼 두 번째 경우를 알아봐야 하는데, gdb를 통해 알아보도록 하겠습니다.

main 함수를 disassemble 한 상태입니다. 코드의 처음 부분에서 지역변수를 위해 0x30만큼 esp를 확보 해 준 이후 곧바로 esp+0x28의 값에 0x80483f0를 넣어줍니다.

????? 왜죠? 분명 선언은 b1, b2, fp, i 순으로 했는데...

아직 시스템에 대한 공부가 부족해서 정확하게 이해는 하지 못했습니다. 정황상으로는 선언과는 별개로 값을 직접 입력 해 줄 때에는 순서와 상관 없이 직접 입력 해 준 변수가 가장 상위의 스택에 쌓이는 듯 합니다.

아, 그리고 0x80483f0의 값은 puts@plt의 주소입니다. 결국 i, b2, b1, fp 의 순서로 스택이 나열되어 있다는 뜻이 되겠습니다.

그림에는 따로 나와있지 않지만 b1의 주소는 esp+0x20, b2의 주소는 esp+0x18입니다.

드디어 두 번째 경우의 수를 찾아냈습니다.

제가 생각하지 못했던 스택 시스템에 따라 b1 이후에 fp가 저장되어 있기 때문에 b1에 8byte를 입력했을 경우 fp에 NULL이 입력되어 마지막에 fp를 호출 할 때 segmentation fault가 나타났던 것입니다.

그렇다면 puts가 저장 되어 있는 fp에 system 함수의 주소를 꽂아주고, b1에는 b2를 이용해 /bin/sh를 넣어준다면 system("/bin/sh")라는 완벽한 결과가 나타나겠습니다.

자, 갑시다!

address of system : 0xf7e63cd0

system 함수가 정상적으로 실행되는 것을 확인 할 수 있습니다.

b2에 값을 더 추가하여 b1에 /bin/sh를 넣어주도록 합시다.

payload :

./narnia6 'A'*8 + 0xf7e63cd0 + 'B'*8 + '/bin/sh'

짜잔! 깔끔하게 쉘을 얻어냈습니다.

OverTheWire_Wargame Leviathan

[ level7 ]

OverTheWire Leviathan 끝

이번 레벨에도 어김없이 setuid bit가 걸려 있는 바이너리가 버티고 있습니다. 실행을 해 보니 사용 방법을 친절하게 알려줍니다. 사용법대로 입력 해 보니, 값이 틀렸다고 오류 메시지를 출력해주고 프로그램을 종료시킵니다. 아마 지금까지의 leviathan 문제를 풀어본 결과 gdb로 까보면 바로 답이 있을 것 같습니다.

자, 일단 main 함수를 disassemble 한 상태입니다. 맨 처음 esp+0x1c에 0x1bd3을 집어 넣어주네요. 이게 답인듯 합니다. 0x1bd3 = 7123

그리고 바로 아래에서 argc가 2가 아닐 경우 오류 메시지(사용법)를 출력하고 프로그램을 종료시키네요.

그 다음 입력받은 값을 int형으로 바꿔주는 atoi 함수를 호출하고, 그 값과 [esp+0x1c](0x1bd3)을 비교하고, 값이 다를 경우 오류 메시지(Wrong)를 출력하고 프로그램을 종료시키네요.

만약 옳은 패스워드를 입력 했을 경우에는 system 함수를 호출하여 쉘을 띄워주는 것 같습니다.

상수 값을 확인해보니 /bin/sh으로, system 함수는 쉘을 떨어뜨려주는 것으로 확인이 되었습니다.

그럼 우리가 확인한 0x1bd3(7123)을 프로그램으로 집어 넣어줍시다.

깔끔하게 쉘이 떨어졌고, 패스워드를 출력 해줍니다.

OverTheWire_Wargame Bandit

[ level7 -> level8 ]

이번 문제도 힌트부터 확인하도록 하죠!

이번 레벨의 목표는 data.txt 파일 안에 다음 레벨로 갈 수 있는 패스워드가 저장되어 있다고 합니다.

그러나 'millionth' 라는 단어 옆에 있다고 하네요.

직접 확인해보도록 합시다.

ls -al 명령어로 해당 파일의 크기를 확인 해 보니 4000kb가량 되는 걸 보니... 아마 사전 데이터같은 값들이 저장되어있는 것 같습니다.

이런 다량의 데이터 속에서 원하는 값을 찾아내기 위해서는 grep 명령어를 사용해야하죠. bash에서는 파이프(|)를 사용하여 두 개 이상의 명령어를 동시에 사용 할 수 있습니다.

확실히 말하자면 동시에 실행하는 것은 아니고, 파이프라인 뒤에 있는 명령어를 실행하는데 그 입력값으로 파이프라인 앞에 있는 명령어의 실행 결과를 던져주는거죠.

millionth 뒤에 있는 key값이 바로 우리가 찾고자 하는 키값입니다!

OverTheWire_Wargame Bandit

[ level6 -> level7 ]

자, 벌써 6레벨까지 도달했습니다. 힌트부터 확인하도록 하죠.

이번 레벨의 목표는 서버 어딘가에 저장되어있는 다음 단계로의 패스워드를 찾으라는 것입니다.

bandit7의 유저권한, bandit6의 그룹권한, 그리고 33byte의 크기를 가지고 있다는 것을 알려주고 있네요.

이전 레벨과 동일하게 find 명령어로 한방에 찾아주도록 합시다.

짜잔.