'LOB'에 해당되는 글 20건

이번에도 규칙이 많다. 이번엔  argv[0]까지 초기화한다.

코드상 argv[1]과 buffer은 0으로 초기화 되고, 또 argv 길이제한까지 있으니 공략하기 힘들어 보인다.

그렇다면 argv[0]밖에 안남는데 이 코드는 // ultra argv hunter! 이라면서 argv를 전부다 지워버리니 어떻게 해야하는지 막막...하다.

그래도 일단 뭐라도 해봐야 할 것 같아서 argv[0] 즉 파일명을 심볼릭 링크로 바꿔보았다.

우선 코어를 떨구고, gdb로 열어보았다.

Cannot access memory ~~가 뜨기 직전에 90이 잔뜩 보인다. 이 언저리로 ret를 해보자

ret값을 조금씩 바꾸면서 넣어봤음에도 Segmentation fault가 뜨는것을 알 수 있다.

분명히 해당 주소에는 값이 들어있는데도 말이다.

원인이 뭘까 생각하다가 gdb를 켤때 뜨는 메시지를 보았다.

각각 어느 주소를 가리키는데 이 주소를 쫒아가보면 내가 넣은 쉘코드 중간 쯤 이었다.

그래서 파일명 뒤에 0x90을 넣어서 쉘코드를 약간 앞으로 더 밀면 효과가 있지 않을까? 라는 생각으로 뒤쪽에도 0x90을 넣었다.

기존 파일 지우는것도 꽤나 노동이었지만 어쨌던 바꿨다. 

(스샷에는 약간 잘렸다)

그럼에도 Segementation fault가 뜨는 것을 확인했다.

이번엔 뭐가 문제일까 core을 뜯어보자

당연하게 뒤로 바이트가 더 들어가면서 코드가 전반적으로 앞으로 왔다. 그 만큼 더 앞쪽으로 ret을 하여야 하였다.

core상으로는 c0부터 가능하지만, 실제 실행할때는 어떨지 모르니 넉넉하게 70정도로 잡아보았다.

그리고 쉘을 얻었다.

이번 문제는 제약이 많이 사라졌다

argv의 글자수 제한도 없고 buffer을 비우거나 argv를 비우지도 않는다.

그 대신 argv의 47번째 글자가 ff면 안되게 되어있다

스택의 구조를 생각해보면 생각보다 간단한 문제다. 버퍼를 계속 늘리면 스택은 위에서 아래로 자라기 때문에 bfffffff에서 점점 작아져 bffeffff까지 쭉 내려올 수 있을 것이다.

그만큼 가려면 글자가 얼마나 들어가야되는지 알 수 없어서 일일히 넣어보면서 확인했다.

15000자로는 터무니 없이 부족하길래 앞에 1을 하나 더 붙혔다.

이번에는 주소가 0xbffe3930까지 내려온것을 확인했다. 그래서 115000개를 넣기로 하고 코드를 짜 보았다. 0x90을 쫙 채우면 어차피 NOP슬라이드를 타고 쉘코드를 실행하게 될 것이므로 

이렇게 실행했더니 여전히 세폴이 뜨더라..

그래서 코어를 한번 더 보았다. 그랫더니 코드의 byte수가 바뀌어서 그런지 0xbffe3900까지 내려가있음을 볼 수 있다. 안전빵으로 0xbffe3910으로 설정하고 돌려보았다.

쉘을 획득했다.

Troll.c의 코드는 한결 더 빡세어졌다. 

우선 argc != 2로 agrv가 2가 아니면 exit하고,

환경변수를 모두 0으로 바꾸며,

argv[1][47]은 0xbf 여야 하고,

argv[1]의 길이는 48이하여야하며,

프로그램 전에 buffer을 초기화하고,

argv[1]도 초기화한다.

싸그리다 제한하고 초기화시켜버리니 BOF할 구석이 없어보인다.

하지만 유심히 보면 초기화 되지 않은 곳이 한구석 있다. 바로 argv[0]이다.

전 문제에서도 말했듯이 심볼릭 링크로 파일이름을 바꾸는게 가능하다.

따라서 이번엔 파일이름에 쉘코드를 넣어볼 생각이다.

만약 0x2f가 들어간 쉘코드를 사용하면 다음과 같이 된다.

따라서 새로운 쉘코드를 구해야 했다.

 이 쉘코드는 바이트 수로 봤을 땐 엄청난 크기를 자랑하지만 0x2f가 없다는 것만으로 감사해야한다.

이 쉘코드로는 링크 형성이 가능하다!

ls로 보면 매우 깨져보이지만 말이다.

그럼 이 파일을 실행하고 싶을 떈 어떡해야할까?

./???????~~~~~를 입력해서는 안되고

처럼 파일이름을 python으로 짜서 넘겨줘야 한다.

그럼 이제 쉘코드를 넣었으니 argv[0]의 주소를 구해야 한다.

먼저 temp에 troll을 복사한 후 core을 떨어뜨려 보았다.

보아하니 주소 맨 뒤쪽에 넣은 코드들이 보인다.

0xbfffffa0 정도부터 0x90이 보인다.

그래서 이 주소로 ret하면, 

세폴이 뜬다.

엥? 뭐가 문제지? 하고 코어를 다시한번 보았다.

앗 자세히 보니 0xbffffb10정도부터도 0x90이 있는것이 보인다.

이 주소로 ret해보자.

바로 쉘을 얻을 수 있었다.

orge.c 의 코드이다.  here is changed!라고 친절히 알려주는데 이번에는

strlen(argv[0]) != 77 인 경우 exit(0);하게 되었다. 

argv[0]은 파일명이다.

리눅스 터미널에선 실행파일을 

처럼 실행하는데 여기서 파일명이 argv[0]에 해당한다. 파일명을 바꾸는 가장 쉬운 방법은 당연히 mv [기존파일명] [바꿀파일명]이겠지만, 그 외에도 다른 방법이 있다.

바로 심볼릭 링크이다. 윈도우에서 사용하는 바로가기랑 비슷하다 보면된다.

사용법은

이다.

즉 

를 사용하면 기존 파일을 건드리지 않고 파일명을 바꿀 수 있다.

기존 코드와 다 똑같고 argv[0]만 바뀌었기 때문에 전에 사용한 코드를 비슷하게 사용하였다.

(gdb core을 뜨기 위해서 temp로 orge를 복사해서 사용하였다.)

세그멘테이션 폴트가 뜨고 코어가 떨어졌다.

gdb -c core로 코어를 열어 x/32x $esp로 스택을 보았다.

0xbffffb80 언저리부터 90이 시작하는 것을 볼 수 있다. 안전하게 0xbffffb90을 ret에 덮어쓰기로 하였다.

운이 좋았나보다. 한번에 쉘을 얻은 것을 확인할 수 있다.

이번엔 환경변수 금지, argv크기 제한,  buffer초기화 3스택이다.

우선 temp폴더를 만들어 darkelf를 복사했다.

GDB로 복사한 darkelf를 열어 0xbf를 48개 넣어보았다.

0xbffffc60정도부터 bf가 보인다

그 언저리로 ret을 바꿔보았지만 계속해서 Segmentation Fault가 뜨는 것을 확인 할 수 있다.

그래서 덤프를 떠 보았다.

대충 0xbffffc0a쯤부터 90이 보인다. 그래서 이 언저리로 ret을 오버플로우 해보았다.

0xbffffc0b일 때 쉘 획득에 성공했다.

wolfman의 코드이다. 다 똑같은데 //buffer hunter만 추가 되었다.

보아하니 buffer의 40byte를 모두 0으로 세팅한다는 것으로 보인다.

우선 orc와 코드가 똑같으니 똑같이 실행해 보았다.

보아하니 orc와 비슷한 모습이 보인다. 

우선 이번에도 bffffa80과 bffffc10 둘 모두에 한번씩 시도해 보았다.

응? 둘다 된다. 왠지는 모르겠다.... 어차피 buffer밖으로 ret해서 그런걸까?

memset으로 buffer을 0으로 설정해도 입력된것이 buffer을 이미 넘어버리니 상관없는 것 같다.

(이번 문제는 잘 이해가 안되서 반 질문식으로 쓴 라이트업이니 잘못 이해한 점 있으면 확실히 알려주세요~!)

orc.c의 코드이다. 입력을 argv[1]로 받아서 strcpy로 buffer에 넣는다.

살짝 보아하니 //egghunter이라며 memset으로 environ[i]를 다 0으로 설정하는 것을 볼 수 있다. 간단히 생각하면 환경변수를 모두 0으로 설정하는 것으로 보인다. 즉 지금까지 편하게 써왔던 환경변수로 ret하는 방법을 쓰지는 못한다.

그리고 그 밑에 보니 if(argv[1][47]!= '\xbf')로 입력의 48번째 글자가 \xbf가 아니면 

stack is still your friend. 라는 말과 함께 exit(0); 하는 것을 볼 수 있다.

우선 orc 그 자체를 사용해서는 gdb를 사용할 수 없으므로 temp라는 폴더를 만들어서 orc를 복사했다.

우선 GDB에서 \xbf를 48개 출력한 후 A를 100개 더 넣어보았다.

보다시피 bf가 반복된 후 41이 반복되는 것이 두개가 나온다.. 둘중 뭐가 버퍼고 뭐가 argv인지 잘 모르겠다.

그래서 둘 다 시도해 보았다.

먼저 0xbffffbe0로 ret을 두고 쉘코드를 넣었더니 Illegal instruction을 볼 수 있었다.

다음으로는 0xbffffa90으로 두고 실행해 보았더니 쉘을 얻을 수 있었다.

정리해보자면

argv에 값을 넣고 buffer에 그 값을 복사하는데, buffer의 ret값을 덮어쓴 후, argv의 메모리 중간으로 ret한다.  

argv에 0x90을 40개 넣었으니 그 중간으로 ret하면 NOP슬라이드를 타고 쉘코드를 실행하게 될것이다.

정도로 이해했다.

이번 문제도 비슷하다. 대신 이번엔 argv로 입력을 받지 않고 gets()로 받는다.

우선 이럴 경우 값을 넘기는 방법은

이란것을 알고 넘어가자.

더미값은 여전히 없다. 즉 버퍼 16만큼 할당 받았으며 SFP를 포함하면 20바이트 후 ret가 존재한다는 것을 알 수 있다.

이번에도 버퍼크기상 쉘코드를 넣기 힘드니 환경변수를 사용할 것이다.

쉘코드의 이름을 SHELLCODE라고 할것이기에 코드를 이리 짰다.

환경변수를 생성하고 주소를 알아보자.

주소가 0xbffffeba인 것을 확인했다.

이제 오버플로우 할 차례다.

위에서 말했듯이 SFP를 포함해 20바이트를 입력하고 ret값이 존재한다.

즉 20바이트를 입력하고 환경변수의 주소를 넣으면 쉘코드가 실행된다는 것이다.

그리고 글 처음에 언급한 대로 gets로 문자열을 받으므로 

로 코드를 짠다. 물론 주소는 스몰엔디안 형식으로 반대로 넣어야 한다.

실행 결과 Goblin의 비밀번호를 알아 낼 수 있다.

cobolt의 코드이다.

gremlin과 별다를 것 없이, 버퍼의 크기만 16이 되었다.

만약 gremlin을 버퍼 내에 쉘코드를 넣는 방식으로 풀었다면 이번엔 다르게 풀어야 겠지만 나는 애초에 환경변수를 사용해서 풀었었기 때문에 그대로 풀게 되었다.

가장 먼저 /bin/bash2를 실행한 후, gdb로 cobolt를 열어보았다.

0x10은 십진수로 16. 즉 이번에도 Dummy는 존재하지 않는다.

확인한 후, 환경변수를 만들고, getenv라는 프로그램을 만들어 환경변수의 주소를 가져왔다.

(실행결과)

즉 SFP포함 20바이트를 덮어쓴 후 환경변수의 주소를 넣어주면 ret이 오버플로우 되어 쉘코드가 실행될 것이다.

끄읏.

LOB의 첫번째 문제인 gate이다.

gremlin.c에 코드가 적혀있다.

딱봐도 strcpy에서 buffer이상의 값을 넘겨줘서 ret값을 바꾸면 되게 생겼다.

단, LOB에서는 /bin/bash에서 0xff를 0x00으로 인식하는 버그가 있어 /bin/bash2를 실행하여야 한다.

해당 쉘코드는 다음과 같다.

그럼 우선 환경변수에 이 쉘코드를 넣는다.

getenv의 코드는 다음과 같다

즉 내가 넣은 SHELL의 주소를 반환하는 코드이다.

실행결과 주소가 0xbfffff32인 것을 확인할 수 있다.

그럼 우선 더미값을 확인해 보자.

0x100은 십진수로 256이다. 즉 이 문제에는 dummy값이 없다.

그렇다면 argv[1]에 260바이트를 채운 뒤 환경변수의 주소를 넣으면 된다.