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

페도라 버전부터 추가되는 보호기법들은 크게 세 가지입니다.1. ASLRRedhat 9(FTZ) 와는 달리 이제 정말 제대로 된 ASLR이 적용 됩니다.2. Ascii-Armor페도라 버전 부터는 공유라이브러리의 상위 1바이트 주소가 0x00 으로 바뀌었습니다.더 이상 기존의 RTL을 수행할 수 없습니다.3. NX-Bit스택과 힙 부분에서 더 이상 쉘코드를 실행할 수 없습니다.이번에는 간단히 페도라 3 링크만 걸어드리겠습니다 ~Fedora 3 LOB 서버다른 과정은 Redhat 에서 했던 것과 동일하게 하시면 됩니다.

20번 문제는 마지막 문제입니다. 그리고 가장 기초 Remote Buffer Overflow 문제이기도 합니다.소스코드를 한 번 살펴보죠. 는 파일로 첨부해놨습니다. 소켓이다보니 소스코드가 너무 기네요...;선언된 변수는 40 바이트 크기로 잡혀있는데, recv 함수로 256 바이트를 받음으로써 취약점이 발생하는 것입니다.또한, 제가 XInetd 데몬은 로컬 쉘코드를 사용해도 되지만, 사용자가 직접 소켓을 할당하고 사용하는 StandAlone 형식의 프로그램은 바인딩 쉘코드가 필요합니다.바인딩 쉘코드에 대한 것은 다음에 Writing the ShellCode 부분에 써보기로 하고... 여기서는 그냥 쉘코드를 사용하겠습니다.( Redhat 7.3에 강좌도 써야하는데 문제 푸는게 꿀잼...) death_kn..

후... 대망의 19번 문제입니다. 전 사실 20번 부터 풀어봤는데... 20번이 훨씬 쉬웠던 것 같습니다...아무튼 시작 !문제의 심각성을 깨닫게 해드리기 위해서 이번에는 엄청난 소스코드에도 불구하고 사진을 넣었습니다.처음 이 문제를 봤을 땐 정말 막막했습니다. 무슨 사용할 수 있는 곳이 하나도 없더군요.풀면서 이상하다고 생각했던 것이, 1. fgets 로 입력을 받는다.2. 라이브러리를 제한했지, 0x40 으로 시작하는 주소를 제한한 것이 아니다. 근데 사실 위의 두 가지만으로는 도저히 문제를 풀수가 없었습니다. 막 돌아다니다가 본 것이 흔히 쓰는 STDIN 이라는 것이 임시 입력 버퍼라고 하더군요 ?!?(분명 C언어에서 읽었던 것 같은데 이런데는 적용을 못함...)아무튼... 이런거 찾아내시는 분들..

이번 문제는 PLT(Precedure Linkage Table)에 관한 문제입니다.먼저 소스코드를 보시면,ret의 값이 strcpy의 주소(PLT)가 되어야하고, ret 뒤의 값이 0x41414141로 고정이 됩니다.즉, strcpy가 수행한 뒤에 ret 값을 바꿔서 원하는 것을 수행시켜야 합니다.하지만, memset으로 0x41414141로 고정시켜버리기 때문에 방법이 없는 듯 합니다... strcpy의 동작에 대해서 다시 한 번 생각해 볼 때가 됐습니다.strcpy(dst, src) -> src '주소 값'에 있는 문자열을 dst '주소 값'에 문자열을 씁니다. C언어를 공부할 때 당연시 해오셨을 수도 있지만 이 문제는 이 원리가 끝입니다... gdb로 살펴보죠.ret 에 strcpy를 넣고 뒤의 4..

OS: Redhat 6.2도구: gcc-2.91, gdb-???, dumpcode.h조건: calling functions continuously어렵게 생각해서 30분이나 걸렸네요. 일단 제가 풀어보니 풀이는 두 가지가 될 수 있습니다. 1. 제작자의 의도대로 푸는 방법2. 제작자의 의도를 무시하고 푸는 방법 RTL2 와 같은 맥락입니다.(14번 문제요. 14번도 의도를 무시하고 풀 수 있거든요. 정석으로 풀긴했지만요...)아무튼 전 여기서도 정석으로 풀겠습니다. 야매(?)로 푸는 것은 직접해보세요. 의도를 무시할 수 있는 이유는 두 문제들 모두 처음 값만 검증하기 때문입니다. 소스코드 첨부해놨습니다.(너무 길어서요...) 간단히만 설명드리면,전역변수 Check가 있는데 DO, GYE, GUL, YUT,..

대망의 Fake EBP 입니다 ! 말 그대로 EBP를 가짜로 만들어 주는 기법입니다 ~문제 바로 보겠습니다.전 문제와 달라진 부분은, 1. 버퍼를 초기화시키지 않는다.2. strcpy가 strncpy가 되면서 48 글자까지만 입력이 가능하다. 두 부분입니다. 이제 환경변수도 이용하지 못하는군요...남은 것은 leave 뿐입니다 ! 이 문제의 핵심은 leave로 다시 한 번 점프해서 자신이 원하는 곳을 EBP로 만들 수 있다는 것에 있습니다.gdb를 이용해서 EBP로 만든다는 것이 무슨 뜻인지 확인해보겠습니다.ebp의 값을 0xbfffa9c 로 조작하고, ret은 leave를 가리키도록 프로그램을 실행했습니다.(leave와 ret에만 브레이크포인트를 걸었습니다.)처음 ret가 수행되기 전에는 ebp는 0x..

이번에는 스택도 RTL도 이용할 수 없습니다.소스코드를 한 번 보시면,리턴주소의 맨 처음 바이트에 스택과 공유라이브러리 영역에 대한 것을 원천차단해놨군요...하지만 ! argv[1]와 환경변수 모두를 차단하지는 않았습니다. 즉, 두 개 모두 사용해야 풀 수 있는 것 같습니다.문제 12번을 제대로 이해하시고 직접 해보셨다면 풀면서 확 ! 떠오르는게 있으실 수도 있습니다만...바로 설명드리겠습니다.leave; ret 에 대한 내용은 모두 아신다고 가정하고 ret의 동작에 대해서만 다시 한 번 살펴보죠.ret: pop eip; jmp eip -> 와 같이 동작한다고 설명해드렸습니다. 또한, pop을 하므로 esp의 값이 4 바이트만큼 증가한다고 설명했었구요.뭔가 아이디어가 떠오르시지 않으시나요 ? 그렇습니다...

소스코드가 너무 길어서 중요한 부분만 캡처했습니다.(위에 권한을 해결하는 부분이 있는데 복사해서 코드만 위치만 바꿔주면 되므로...)결국 execve 함수를 이용해서 풀어보라는 것인데... 이게 또 생각없이 접근하면 머리가 아파지는 문제입니다. 먼저 execve 주소는 0x400a9d48 이곳입니다.(p execve로 구하거나 프로그램을 실행하면 그냥 주소를 출력해줍니다.)그렇다면 공격 코드는 ./giant `python -c 'print "A"*44 + "execve 주소" + "AAAA" + "인자1" + "인자2" + "인자3"'` 으로 구성되어야 합니다. 인자 1은 /bin/sh의 주소를 전달하면 되고, 인자 2는 {"/bin/sh", 0}으로 전달해야 하고, 인자 3의 경우는 4 바이트가 0인 ..

쉬운(?) RTL 문제를 풀어보겠습니다.조건도 그렇고 푸는 것 자체가 RTL이죠 ? 스택을 이용하려하면 스택이 널 배신했다고 나오네요.간단한만큼 빠르게 풀어보겠습니다. 일단 시스템 함수의 위치를 찾아보죠 ~시스템 함수의 위치는 0x40058ae0 입니다. 그런데 하나 필요한 것이 더 있죠 ? /bin/sh을 찾아보겠습니다 ~Redhat 7.3에서 했던 것을 우려먹어봅시다... 아무튼 결과적으로,그럼 공격코드는 로 구성되네요.바로 공격해보겠습니다.new divide !

앞에서 설명드린 개념을 이해하셨다면 이제 이 문제를 혼자서도 해결하실 수 있을 것입니다.그래도... 풀이는 해야하니... 소스코드는 (1)에서 보셨을테니 gdb로 바로 분석하면서 가보죠 !main 함수의 leave; ret 부분과 problem_child 함수의 leave; ret 부분에 브레이크포인트를 걸어줍니다.그리고 run `python -c 'print "B"*4 + "A"*36 + "\x40"'` 으로 실행해주세요.앞의 두 부분은 problem_child 함수의 leave; ret 부분인데요. (1)에서 해드렸던 대로 분석해보세요.(아마 제가 (1)에서 언급했던 것들에 대해서 알 수 있으실 겁니다.)아무튼 전 main 함수의 leave 전에 멈춰있습니다. leave 를 수행하기 전에 스택의 상황..