느리지만 꾸준히 하는 나는 거부기

소스코드 바로 보겠습니다.보시면 빨간색으로 네모친 부분에서 strncpy 함수로 할당한 버퍼보다 1 바이트 더 큰 값을 입력받습니다.gdb를 이용해서 공격해보겠습니다.ebp 값을 유지하기 위해서 39 바이트만 넣어봤습니다.(마지막 널값.)그랬더니 0x42424242로 리턴해버리네요 ?? 왜 그럴까요 ? 왜 이와같은 결과가 나오는지 알기 위해서는 leave; ret 에 대해서 알 필요가 있습니다.프로그램의 프롤로그 부분인 push ebp; mov esp, ebp(인텔기준)은 많이 보셨겠지만, leave; ret은 생소한(?) 분들도 계실겁니다.(사실 leave가 생소하죠...)문제를 풀기 전에 leave; ret의 동작을 파악해보도록 하겠습니다.(그만큼 중요하고 앞으로는 설명안합니다.)위와 같이 브레이크포..

소스 코드 먼저 보고 시작해보죠 !정말 어마어마한 코드입니다. 스택을 모조리 0으로 초기화시켜버리네요...(RET 빼고서요.)일단, buffer 보다 높은 주소는 절대 사용할 수 없습니다.그렇다면 일단 이곳을 보고 오세요... 와... 정말 감탄스럽습니다 !그래서 그냥 한 번 질러봤습니다.절대 stdio.h를 포함하지 마세요.이후에 URL에 나와있는대로 컴파일 옵션을 주어 컴파일 한후, export LD_PRELOAD=./printf.so로 등록합니다.등록이 완료되었습니다. 먼저 복사한 gole1 을 실행해보겠습니다.오... 마이 갓... 쉘이 따였습니다 ! 이제 실제 golem에 적용해보죠.안되네요 ... ? 이유는 바로... setuid가 걸려있어서 그렇습니다.권한이 바뀌어서 실행되면서 LD_PREL..

풀긴 풀었습니다만.... 조건이 어려운게 아니라 쉘코드가 왜 안먹히는지 이해가 잘 안되네요 -_-;;추측컨데 전에 썻던 \x2f가 없는 쉘코드에는 특수문자가 존재하는데,argv[0]에 특문이 포함되면 원래 기계어가 실행이 안되는건지... 흠... 모르겠습니다.알게 되면 다시 쓰겠습니다. 풀긴 풀었는데 깨름직 하네요...물론 이번 문제도 디렉토리를 생성해서 25 Bytes 쉘코드로 풀 수 있습니다.9번까지 따라해보셨다면 왜 제가 이번 문제를 쉽게 풀었다는지 알 수 있으실겁니다.Hint: 스택의 끝부분에는 왜인지는 모르겠지만 argv[0]의 값이 존재합니다...P.S. 찾아보니 스택 자체의 형태가 원래 그렇다네요 ~ 여기

이번에는 꼭 소스코드를 봐야하기에 첨부합니다.이번에 추가된 조건은 0xbfff를 사용하지 못하게 되었습니다.그러다보니 기존에 존재하던 필터들도 모두 사라졌군요... 하지만 ! 프로그램이 스택에 어떤식으로 올라가는지 아신다면, 꽤나 쉬운 문제일 수도 있습니다. 간단한 예제를 준비했습니다.차이가 느껴지시나요 ??왜 이런 현상이 일어나는 걸까요 ? 이유는 환경변수의 크기는 고정되어 있기 때문입니다.그래서 환경변수를 침범 할 정도로 많은 값이 들어가면 스택이 점점 위로 이동하면서 크기를 줄입니다.이제 문제를 어떻게 푸실지 감이 오시나요 ?이래도 안오신다면 아래 그림을 보세요.뒤의 A의 갯수를 10만으로 줬을 때의 값입니다.스택의 주소가 어떤가요 ? 이제 어떻게 풀지 감 오시죠 ?바로 풀어보겠습니다.공격코드는 ...

휴... 가면 갈수록 보호하는 종류가 많아지네요.이번엔 상황의 심각성(?)을 깨닫기 위해 소스코드를 한 번 보도록 하죠.보시면 이제 argv[1]까지만 사용가능하며, 그나마 memset으로 argv[1]를 초기화시켜버리네요...하지만 ! argv[0] 필터링이 없어져서 argv[0]를 이용해야 한다는 감이 딱! 왔습니다.그래서 전과 같이 '링크'를 이용해서 풀려고 했으나...계속 오류가 발생하여 찾아보니, '링크'는 '\x2f'(/)가 들어가면 원래 존재하는 디렉토리가 아닌 이상 링크를 안시킨다고 합니다.생각해보면 당연한거죠. 디렉토리가 없는데 그걸 생성하고 그 밑에 또 파일을 생성한다는 것이요.생각을해보다가 그냥 mkdir -p 명령으로 부모디렉토리를 생성하면서 그 밑에 '링크'를 걸고 Exploit을..

너무 길어져서 더 이상의 소스코드를 올리기는 좀 힘들 것 같네요.앞으로는 추가되는 부분이나 새로운 부분만 올리겠습니다.프로그램을 실행할 때 길이가 77글자가 안되면 종료되네요...이 부분은 리눅스의 '링크'를 이용하면 우회할 수 있습니다. 오히려 그 전 문제들에서 추가되는 트릭보다 더 쉬웠던 것 같기도 합니다.일단 orge.c 를 org1.c로 복사한 후에 소스코드에 dumpcode.h를 추가시키고 argv[2]를 이용해서 풀겠습니다.org1.c 에 아래와 같이 추가해주세요.(buffer가 아니라 argv[2]를 보겠습니다.)지금까지와 구조는 똑같으니 RET가 어디있는지는 아실겁니다.그리고나서 프로그램의 길이는 gcc를 이용해서 조작해줍시다.(전 orgeorge... 해서 77자로 만들었어요.)강조하면 ..

문제 6번에는 조건이 하나 더 붙었네요.이번에는 바로 복사해서 dumpcode.h 를 추가하고 밑에 dumpcode(~)를 추가해주세요.여러분들이 어떻게 생각하실지는 모르겠지만 전 아래와 같이 생각했습니다. 1. 기존의 조건이 있으니 환경변수와 버퍼는 제외.2. argv[1]의 길이를 제한.- argv[1]를 이용하지 말자.- 어차피 argv의 값들은 **(이중 포인터)이니 어딘가에 저장이 스택 높은 주소 어딘가에 존재한다.(위의 부분은 프로그램을 자세히 분석 안해보셨다면 처음 아시는 분들도 있을 겁니다.) 그래서 ! 결론적으로 dumpcode(buffer, 1000)으로 스택의 끝까지 살펴보았습니다.사진이 크지만 제가 네모 친 부분만 보세요. argv는 주소를 두 번 참조하기 때문에 결국에는 맨 아래에..

문제 5번부터 약간씩 어려워지기 시작합니다.여기서 어렵다는 의미는 지금까지와는 달리 창의적(?)인 생각이 필요하다는 의미입니다 ^^.일단 Egg Hunter, Buffer Hunter 때문에 환경변수와 버퍼는 이용할 수가 없습니다.그런데도 스택은 여전히 당신의 친구라는 문구가 있네요...제가 처음 위의 문제를 봤을 때에는 완전 멘붕 속에 빠져서 몇 시간을 생각했었습니다.근데 막상 드는 생각은 참 허무맹랑(?)하면서도 될 법한 것이었습니다. 여러분도 한 번 생각해보세요. 이번 문제를 어떻게 해결할 수 있을지 말이죠. 분명 생각하신다면 창의력(?)이 확 ! 올라가는 것을 느낄 수 있습니다.(과연 ?)중요한 포인트를 짚어보겠습니다. 1. 환경변수를 사용할 수 없다.- 이는 4번에서도 그랬으니 가볍게 생각할 수..

dumpcode.h는 첨부해놨습니다. 문제 바로 보시죠.extern char **environ 전역 선언과 memset을 이용해서 프로그램이 실행될 때 환경변수를 모두 0으로 만듭니다.그러니 지금까지 사용했던 환경변수를 이용한 Exploit은 불가능하고, argv[1][47]로 \xbf를 검증하는 것으로 보아 전통적인(?) BOF를 사용해서 공격해야 하는 것 같습니다.Redhat 6.2는 Random Stack이 적용되어 있지 않아 주소가 고정되므로 dumpcode.h를 삽입한 새로운 코드를 작성해서 주소를 살펴보겠습니다.orc.c를 or1.c로 바꿔서 컴파일 했습니다. 저희가 RET에 넣어야하는 주소 값이 0xbffffae0 이라는 것을 알 수 있습니다. 위의 공격코드대로 구성해서 다시 공격해 보겠습니..

사실 LOB 문제들이 BOF의 개념을 잘 이해만 하고있다면 20문제 모두 그렇게 어렵지 않게 풀 수 있는 문제들 입니다.그러니 화이팅 !3번은 small buffer + stdin 이라는 조건이 걸려있네요.제가 항상 strcpy와 썻으니 여기서 gets는 어떻게 공략해야하는지 알아보겠습니다.보통 저희가 argv를 이용해서 값을 전달할 때에는 " 프로그램 `python -c 'print ~~'` "와 같은 형식으로 공격합니다만,gets는 " (python -c 'print ~~';cat) | 프로그램 "과 같은 형식으로 공격합니다. 여러운건 없으니 바로 공격해보겠습니다.해커가 침입했다는 것을 증명했다네요... P.S. 사실 모든 워게임이 그렇겠지만, 특히 BOF는 어떻게 푸는지 감이오면 정말 쉽게 공격할 ..