Load of Buffer Overflow 문제풀이

20문제로 보는
버퍼오버플로우
이무송
fromitive@gmail.com
해커스쿨 LOB 문제 풀이

문제 분석 풀이 제시 풀이 결과 느낀점
각 문제들이
어떤 형태를 띠고 있는지
분석을 합니다.
문제를 파악한 후
풀이 과정을
제시하겠습니다.
풀이 과정데로
풀어서 결과를 확인하는
시간을 갖겠습니다.
각 문제별로
어떤 취약점이 있었는지
한번 되집어 보겠습니다.

gate
문제 분석
setuid가 안걸려 있는것같아 ls -al 을 했는데 gemlin에 걸려있었다.

gate
문제 분석
버퍼의 주소가 [ebp-256]이고 간단하게 쉘코드를 작성하면 쉽게 풀릴 것이다.

gate
풀이 제시
버퍼의 크기가 256 이고 ebp +4 + 리턴 주소를 변조하여 쉘코드를 실행시키면
될것 같다.
buffer [ebp - 256]
AAAAAA.....
ebp
AAAA
return value
new return value
0xbffffXXX
nop + shell code
.....
nop(0x90) ....
nop(0x90) ....
nop(0x90) ....
nop(0x90) ....
shell code start

gate
풀이 결과
공격 코드를 작성하였고 시도해 보니 간단하게 쉘을 얻을 수 있었다.

gremlin
문제 분석
이번엔 버퍼의 공간이 줄어들었지만 gate와 마찬가지로 풀면 될것 같다

gremlin
풀이 제시
될것 같다.
buffer [ebp - 16]
AAAAAA.....
ebp
AAAA
return value
new return value
0xbffffXXX
nop + shell code
.....
nop(0x90) ....
nop(0x90) ....
nop(0x90) ....
nop(0x90) ....
shell code start

gremlin
풀이 결과
gate의 쉘 공격코드를 변조해서 공격했더니 간단하게 cobolt 쉘을 얻을 수 있었다.

cobolt
문제 분석
이번엔 gets 의 stdin 으로 입력값을 받는다. 지난 ftz에서 어떻게
공격코드를 넣었는지 봤으니 간단하게 풀 수 있을 것이다.

cobolt
풀이 제시
gremlin과 똑같이
될것 같다.
buffer [ebp - 16]
AAAAAA.....
ebp
AAAA
return value
new return value
0xbffffXXX
nop + shell code
.....
nop(0x90) ....
nop(0x90) ....
nop(0x90) ....
nop(0x90) ....
shell code start

cobolt
풀이 결과
gremlin에서 사용하던 공격코드 변조 없이 파이프라이닝 하여
goblin 쉘을 획득했다!

goblin
문제 분석
환경변수를 이용한 쉘 공격이 소용 없게 되었다.
지금까지 스택의 주소를 추측한 nop +shell code 공격을 해왔기 때문에
이전에 사용하던 코드를 활용하면 풀 수 있다.

goblin
풀이 제시
될것 같다.
buffer [ebp - 40]
AAAAAA.....
ebp
AAAA
return value
new return value
0xbffffXXX
nop + shell code
.....
nop(0x90) ....
nop(0x90) ....
nop(0x90) ....
nop(0x90) ....
shell code start

goblin
풀이 결과
매우 간단하게 orc의 쉘을 획득하였다.

goblin
느낀점
환경변수가 막히면 brute forcing 으로 스택의 주소값을 대략 맞춰야 한다.

orc
문제 분석
이제 환경변수 도 막히고 버퍼 앞의 값도 막혔다.
하지만, 지금까지 썼던 풀이 처럼 다시 공격하면 성공할 수 있을 것같다.

orc
풀이 제시
될것 같다.
buffer [ebp - 44]
AAAAAA.....
ebp
AAAA
return value
new return value
0xbffffXXX
nop + shell code
.....
nop(0x90) ....
nop(0x90) ....
nop(0x90) ....
nop(0x90) ....
shell code start

orc
풀이 결과
이전에 썼던 공격 쉘코드로 간단하게 wolfman의 쉘을 획득하였다!

wolfman
문제 분석
앗! 이제는 함수의 argument1의 길이를 확인한다.
나머지는 orc때와 같은 조건이다.

wolfman
풀이 제시
argv[1]을 이용할 수 없으면 argv[2]를 이용할 수 있다..
이를 통해 쉘을 획득 할 수 있다. 공격코드는
program arg1 arg2 스타일이 되어야하니까 공백을 추가해줫다.

wolfman
풀이 제시
실제로 프로그램을 복사하여 디버깅해보니까 입력값의 길이를 검증안한다.
이를 이용하자.

wolfman
풀이 제시
간단하게 darkelf의 쉘을 습득할 수 있다.

wolfman
느낀점
이번 문제는 함수의 argument의 개수를 철저히 검사를 안하면
어디서든 쉘이 들어갈 수 있다는걸 물어본 것 같다.

darkelf
문제 분석
이번 문제는 기존 wolfman코드에서
argv[0] 의 길이가 77개가 되야한다는 조건이 추가되었다.

darkelf
문제 분석
이게 무슨뜻인지 잘 몰라 printf 를 추가해 argv[0]의 길이를 구해봤다.

darkelf
문제 분석
argv[0]은 프로그램의 이름 길이 ("./" 포함) 이란걸 볼 수 있다.

darkelf
풀이 결과
프로그램의 이름의 길이를 77개로 맞춘뒤 wolfman에서 쓴 공격코드를
삽입 한 결과 쉘을 획득하였다!

orge
문제 분석
troll 소스코드를 보면 arguement가 2개로 고정되어있고,
환경변수 초기화,buffer 값 초기화, argv[1]가 초기화가 됬다.

orge
풀이 제시
troll 파일에 쉘코드 이름으로 된 심볼릭 링크를 걸어놓아서 프로그램을 실행할
때 그 위치로 리턴값을 변경하면 쉘을 얻을 수 있다!
shellcode
troll
buffer [ebp - 44]
A(40자)
ebp
AAAA
return value
new return value
program name
argv[0]
argc

orge
풀이 제시
프로그램의 이름을 바꾸는 스크립트를 짜 보았고, 실행해 본 결과 메모리에
계속 남아있는 것을 확인했다.

orge
풀이 결과
여러 시도의 끝에 결국에 troll의 쉘을 획득하게 되었다!

orge
느낀 점
argv[0]이 초기화 안된점을 노린 신선한 공격이였다.

troll
문제 분석
리턴 값을 조작할때 xbf 대역은 허용하지만 xbfff 대역은 허용 안한다.

troll
풀이 제시
문제를 복사하여 리 턴값을 0xbfbfbfbf 으로 설정하여 쉘코드의 크기를
조절하니까 padding 에따라 버퍼 주소 대역이 달라진것을
확인했고, ret값을 0xbffe 대역으로 수정할 수 있게 되었다!

troll
풀이 제시
버퍼의 크기가 40 이고 ebp +4 + 리턴 주소를 변조하여 패딩이 큰 쉘코드를
집어 넣으면 쉘코드가 실행 될 것이다.
buffer [ebp - 40]
AAAAAA.....
ebp
AAAA
return value
new return value
0xbffffXXX
nop + shell code
.....
nop*0x10000
nop(0x90) ....
nop(0x90) ....
nop(0x90) ....
nop(0x90) ....
shell code start

troll
풀이 결과
0xbffe 번대로 주소를 넣을 수 있었고 vampire의 쉘을 획득 했다!

troll
느낀점
쉘코드가 길어지면 자동으로 프로그램이 데이터를 다 수용할 수 있게
주소 값이 낮아지는 것을 깨달았다.

vampire
문제 분석
argument 1개만 받을 수있고,환경 변수 초기화 , arugment 길이 고정
버퍼값 초기화,argv 전체 초기화.. 이 문제는 제한된 상황이 많다.

vampire
문제 분석
0xbf 로 시작되는 주소는 허용 하는것 같다

vampire
문제 분석
버퍼값을 끝가지 확인해 보니 여전히 프로그램 이름값은 남아있다!

vampire
풀이 제시
orge 때와 마찬가지로
skeleton 파일에 쉘코드 이름으로 된 심볼릭 링크를 걸어놓아서 프로그램을 실행할
때 그 위치로 리턴값을 변경하면 쉘을 얻을 수 있다!
shellcode
skeleton
buffer [ebp - 44]
A(40자)
ebp
AAAA
return value
new return value
program name
argv[0]
argc

vampire
풀이 제시
쉘코드 이름으로 된 파일을 실행하여 덤프된 파일을 분석했더니 쉘코드가
역시 삽입될 수 있었다! 이를 이용하자

vampire
풀이 결과
쉘코드 이름의 심볼릭파일 생성후 공격을 시도하여 skeleton 권한의
쉘을 획득할 수 있었다!

vampire
느낀점
프로그램이 컴파일 될 때, 그대로 기계어로 반영 안되는 것을 알게해 주었다

skeleton
문제 분석
이번 문제는 버퍼대역의 값을 완전히 초기화 시키는 문제이다.

skeleton
문제 분석
버퍼가 초기화 된것을 확인해봤다 버퍼가 싹 0으로 초기화 되었다.

skeleton
문제 분석
프로그램을 실행하기 전에 LD_PRELOAD 변수에 so 파일을 등록 시켜 주면
다른 so 파일이 실행되기 전에 그 so파일을 먼저 불러와 후킹할 수 있게 도와준다고 한다.
후킹에 성공한 모습

skeleton
문제 분석
LD_PRELOAD의 값이 여전히 남아있는지 확인하기위해 메모리를 분석한 결과
0xbffff542 대부터 남아 있는것을 확인했다.

skeleton
풀이 제시
LD_PRELOAD 변수에 쉘코드를 삽입하면 원하는 쉘을 획득 할 수 있을 것이다.
buffer [ebp - 44]
A(40자)
ebp
AAAA
return value
new return value
LD_PRELOAD=
shellcode
argc
nop(0x90) ....
nop(0x90) ....
nop(0x90) ....
nop(0x90) ....
shell code start

skeleton
풀이 제시
쉘코드 이름의 so 파일을 만들고,
LD_PRELOAD를 쉘코드 이름으로 올려두었고 ,
메모리에 남아있는것 까지 확인했다.

skeleton
풀이 결과
안정적으로 golem의 쉘을 획득 할 수 있었다!

skeleton
느낀점
LD_PRELOAD로 버퍼가 초기화 되어도,
쉘코드를 불러올 수 있음을 보여준 문제였다.

golem
문제 분석
이번 문제는 problem_child 안에서 41개로 제한된 버퍼로 공격을 해야한다
다른 제약 조건은 안걸려 있다.

golem
문제 분석
프로그램을 복사해 메모리를 덤프해보면서 관찰을 했더니,
problem child의 끝 esp 주소를 변경 가능해 보인다.

golem
문제 분석
마지막으로 main 함수는 problem_child를 호출한 뒤 함수가 종료가 된다.

golem
풀이 제시
프로그램 함수는 leave 와 ret 으로 종료가 되는데
leave는 mov esp ebp / pop ebp 이고 ret는 pop eip 이다.
problem_child의
stack
buffer[40]
ebp
[main ebp pointer]
return value
call problem_child
이후 주소
main 의 stack
ebp
[old esp pointer]
return value
return code
실행
leave
ret
leave
ret

golem
풀이 제시
ebp의 값을 조작할 수 있으면 함수가 leave ret으로 끝날 때
원하는 주소의 코드를 실행할 수 있다!
problem_child의
stack
buffer[40]
ebp
[FAKE ebp pointer]
return value
call problem_child
이후 주소
main 의 stack
fake ebp
[JUNK pointer]
조작된
return address
조작된
return address의
code 실행
leave
ret
leave
ret

golem
풀이 제시
ebp의 마지막 비트를 이용해 esp-4 값을 저장시켜 shellcode를 실행하게 해보자!
problem_child의
stack
shellcode의 주소
(4 byte)
x90*36
ebp
[problem_child의
esp-4 값]
return value
call problem_child
이후 주소
main 의 stack
problem_child
의 esp-4 값
shellcode의
주소 값
shell code 실행
leave
ret
leave
ret

golem
풀이 제시
shellcode를 환경변수에 올리고 덤프시켜보았다.
마지막 bit를 0x50로 하고 0x90909090을 쉘코드의 주소값으로 바꾸면 된다.

golem
풀이 제시
쉘 코드의 주소값은 다음과 같다.

golem
풀이 결과
여러번 시도한 끝에 성공했다!

golem
느낀점
fake ebp는 환경변수에다 쉘 코드를 넣으면
공격이 성공할 확률이 줄어드는것 같다.

darkknight
문제 분석
이번엔 0xbf번대의 주소로 리턴 값을 불러올 수 없으므로 스택을 이용한
버퍼오버플로우가 불가능하다..

darkknight
풀이 제시
프로그램이 로드 될때 필요한 외부 함수의 주소값을 불러오게 되는데
이 주소값을 리턴 주소값으로 하여 원하는 함수를 호출 할 수 있다.
이걸 return to libc 라고 한다.
buffer [ebp - 44]
A(40자)
ebp
AAAA
return value
new return value
system()
AAAA
address of
'/bin/bash'
system("/bin/bash") 실행

darkknight
풀이 제시
system 함수의 주소값은 어느 프로그램과 똑같으므로 주소값을 얻어보았다.

darkknight
풀이 제시
/bin/bash의 주소값은 환경변수가 초기화가 안됐으므로 쉽게 구할 수 있다.

darkknight
풀이 결과
성공적으로 bugbear의 쉘을 획득하였다!

darkknight
느낀점
버퍼의 주소를 우회하여 쉘코드를 획득 할 수 있다는 것을 알았다.

bugbear
문제 분석
이번 문제는 상당히 어렵다 소스코드를 분석하면 다음과 같다.
execve의 주소값을 불러와
ret변수와 비교하고 있다.
strcpy를 사용하고 있어
버퍼오버플로우가 가능하다

bugbear
문제 분석
이번 문제는 execve를 이용한 return to libc 이므로
execve의 parameter를 조사하였다.

bugbear
문제 분석
execve의 주소값은 공통이므로 이걸 쓰겠다.

bugbear
풀이 제시
풀이 방법은 다음 과 같다.
buffer [ebp - 44]
A(40자)
ebp
AAAA
return value
new return value
execve()
BBBB
address of
'/bin/bash'
address of
address of 'bash'
address of
'null'
/bin/bash의 주소값은 환경 변수가 초기화가 안됫으므로
환경변수를 가리키는 주소값을 사용하면 될것같다.
문제는 바로 이것인데 심볼릭 링크를 이용하여
환경변수 안에 있는 bash를 가리키는 주소값을 넣는다
이 역시 마찬가지로 환경변수의 null을 가리키는 주소값
아무거나 넣으면 된다.

bugbear
풀이 결과
조금 어려웠지만 giant의 쉘을 획득할 수 있었다!

bugbear
느낀점
bash 를 가리키는 주소값의 주소값을 아까 썼던 심볼릭 링크의 이름을
주소값으로 가리키는건 신선했었다.

giant
문제 분석
이번 문제는 조금 머리를 써야 할 것이다.
라이브러리 함수를 사용 못하고 스택공간도 사용할 수 없다.

giant
풀이 제시
메인 함수의 ret을 두번 호출하면 다음과 같은 결과가 나온다
main의
stack
buffer[40]
ebp
[main ebp pointer]
return value
ret의 주소값
main 의 stack
return value
ret 의 주소값
return value
shell code
....
shell code
실행
ret
ret

giant
풀이 제시
leave ret 의 주소값은 0x080 대여서 사용가능하다(0x804851d) 이를 이용해
공격 코드를 작성해보자

giant
풀이 결과
assasin의 쉘을 획득할 수 있었다!

giant
느낀점
0x080 대의 code garget을 이용하여
함수를 조작할 수 있는법을 배운시간이였다.

assassin
문제 분석
이번 문제는 함수의 리턴값으로만 함수를 조작해야 한다.

assassin
풀이 분석
golem 에서 썼던 방식을 응용하여 프로그램을 실행해보았다.
main의
stack
buffer[40]
ebp
[FAKE ebp pointer]
return address
leave
ret 주소값
main 의 stack
fake ebp
[JUNK pointer]
조작된
return address
조작된
return address의
code 실행
leave
ret
leave
ret

assassin
풀이 분석
leave ret 의 주소값은 main코드에 있는걸 사용하였다.

assassin
풀이 분석
fake ebp 값은 환경변수를 초기화 하지 않았으므로 심볼릭 링크로 대체했다.
그리고 환경변수에 쉘코드를 삽입하였다.

assassin
풀이 분석
그럼 다음과 같은 공격 설계가 가능하다.
main 의 stack
buffer[40]
ebp
[FAKE ebp 를 가리키
는 주소]
return address
main 의
leave ret
main 의 stack
FAKE EBP
shellcode 주소
shell code 실행
leave
ret
leave
ret

assassin
풀이 결과
성공적으로 zombie_assain의 쉘코드를 획득 할 수 있었다.

zombie_assasin
문제 분석
LD_PRELOAD 도막혔고, 스택값 초기화 , 라이브러리 함수 사용이 불가능하다.

zombie_assasin
문제 분석
이번 문제는 MO 함수를 이용해야 할 것 같고 각 함수를 도개걸윷모 순서로
연속으로 호출해야한다.

zombie_assasin
문제 분석
DO 함수를 호출하여 MO함수까지 접근을 해야할 것 같다.

zombie_assasin
문제 분석
DO 함수의 주소값은 다음과 같다

zombie_assassin
풀이 결과
main 의 stack
buffer[40]
ebp
[FAKE ebp 를 가리키
는 주소]
DO's address
GYE
GUL
YUT
MO
JUNK
'/bin/bash's 의
address
'/bin/bash'
main 의
stack
FAKE EBP
GYE
system() 실행
after
ret
main 의
stack
FAKE EBP
GUL
main 의
stack
FAKE EBP
YUT
main 의
stack
FAKE EBP
MO
그럼 다음과 같은 공격 설계가 가능하다.

zombie_assassin
풀이 제시
/bin/bash의 주소값은 ADDR에 삽입하면 될것 같다.

zombie_assassin
풀이 결과
공격에 성공하여 succubus의 쉘을 획득하였다!

succubus
문제 분석
코드를 분석해보자!
strcpy 의 함수 포인터를
이용해야 할 것 같다.
argc 값까지
초기화가 이루어진다
왜?

succubus
문제 분석
strcpy 함수를 호출할때 매개변수 는 이렇게 들어간다
지금 ebp+4 값(return 주소값)이 41414141로 채워저있는 것을 확인 했다.
old ebp값
리턴 주소값
(0x41414141)
목적지 주소값
[ebp+8]
출발지 주소 값
[ebp+0xc]

succubus
풀이 과정
리턴주소값은 main 함수중에 덮어 쓰므로 출발지 주소값에 shellcode의 주소값을
쓰고 목적지 주소값을 리턴 주소값을 가리키는 주소값(ebp+4)에 덮어쓰면 된다!
old ebp값
리턴 주소값
(0x41414141)
목적지 주소값
[ebp+8]
[ebp+0x4]
출발지 주소 값
[ebp+0xc]

succubus
풀이 결과
쉘코드는 환경변수에 올려놓고 출발지 주소를 그 주소값으로 하고
목적지 주소값은 덤프파일로 주소값을 추출했더니,
nightmare의 쉘을 획득할 수 있었다!

nightmare
문제 분석
계정명처럼 정말 절망적인 제한조건이다. 지금까지 했던 모든 우회 방법을
쓸 수 없게 되었다.

nightmare
문제 분석
다만 , fgets의 argument로 사용하는 stdin으로 뭔가를 할 수 있다고 한다.

nightmare
문제 분석
stdin이 구조체란걸 처음 알았다..
_IO_write_ 부분의 주소값을 조회해보자

nightmare
풀이 제시
return 주소를 버퍼 주소값으로 지정해놓으면 입력했던 shellcode가 실행 될
것이다!
shellcode
(40byte)
oldebp
(4byte) shellcode
return address
(0x40105000)
shell code
실행

nightmare
풀이 제시
xavius의 쉘을 획득할 수 있었다!

xavius
문제 분석
6666/TCP 포트를 열어 요청을 받는것 같다.

xavius
문제 분석
클라이언트에서 서비스를 요청하면 Death Knight가 무얼 말하고서
입력값 256자(recv(256))를 받게 한다 --> 그걸 받는 buffer값은 길이가 40이다.

xavius
풀이 제시
attacker
"A" * 40
임의의 스택 주소 값
(reverse shell code
주소값)
reverse shell code
server
"A" * 40
임의의 스택 주소 값
(reverse shell code
주소값)
reverse shell code
reverse shell 실행
reverses shell을 위한
포트 개방
공격코드
전송
shell 획득
공격 구성도는 다음과 같다

xavius
풀이 제시
쉘코드는 shell storm에서 구할 수 있었고, 공격 코드를 작성하였다.
우분투를 사용했고 공격 서버는 lob 서버의 주소이다.
http://shell-storm.org/shellcode/files/shellcode-833.php

xavius
풀이 결과
port 4444로 요청을 받았더니 쉘을 습득할 수 있었다!

xavius
풀이 결과
이로서 lob를 모두 풀어보았다

Load of Buffer Overflow 문제풀이

More Related Content

What's hot

Similar to Load of Buffer Overflow 문제풀이

Load of Buffer Overflow 문제풀이