전체 글
main 함수에 인자로 'void'가 들어갔다는 것은 아무것도 받지 않겠다는 뜻이죠. 그 외에 gets 함수 빼고는 level11과 똑같은 문제네요. 다른 점은 main 함수의 '인자'가 아닌 '변수'로 값을 받는다는 거겠죠? 그렇다면 여기서는 확실히 환경변수를 이용해야겠네요. 전에 말했다시피 ASLR로 인해 main 함수의 주소가 변하기 때문이에요!! 전에도 썼던 쉘코드를 사용하겠습니다. \x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89 \xe1\x89\xc2\xb0\x0b\xcd\x80 출처 - https://xerxes-break.tistory.com/212 유용한 쉘코드(x86 Shellcode 로컬) 0x01. 가장..
실행파일 하나, hint에는 strcpy 함가 눈에 띄네요. 또한, main 함수로 인자가 들어가는군요. attackme라고 이름이 지어진 것을 보니 이 실행파일의 소스코드인가 봅니다. BOF 취약점이 발생할 수 있는, 입력 값을 검증하지 않는 함수들을 많습니다. 그 중에 하나가 strcpy이죠. str 변수의 크기를 생각하지 않고 그냥 복사만 수행합니다. 그렇게 되면 ret 주소를 덮을 수 있겠죠. 일단 tmp 파일로 복사해서 gdb를 통해 디버깅해보겠습니다. intel을 선호하기에 setting 해주고. 이게 이 소스코드의 어셈블리어입니다. str 변수가 256바이트인 반면, main+3에서 공간 264바이트를 할당하는 것을 보면 8바이트가 dummy인 것을 확인할 수 있습니다. 그러고는 main+4..
shmget int shmget(key_t key, int size, int shmflg) key : 시스템에서 식별하는 공유 메모리 번호 size : 공유메모리 크기 shmflg : 동작 옵션 공유메모리를 생성하는 함수이다. 반환값으로는 공유메모리 식별자를 내뱉는다. 만약 실패시 -1을 내뱉는다. 헤더파일로는 sys/ipc.h, sys/shm.h를 include 해야한다. shmflg IPC_CREAT : key에 해당하는 공유메모리가 존재 X시, 생성과 동시에 접근 권한도 부여한다. 만약 공유메모리가 있다면 이 옵션은 무시해도 좋다. IPC_EXCL : 공유메모리가 있으면 실패로 -1을 반환한다. 이 값이 설정되지 않으면 기존 공유 메모리에 접근해 식별자를 반환한다. shmat void *shmat(..
보면 C 소스코드가 나옵니다. Buffer Overflow 문제입니다. buf 변수를 통해 Overflow를 발생시켜 buf2에 앞 두글자가 "go"라는 변수가 저장되게 하면 됩니다. level9 디렉터리에는 쓰기권한이 없으므로 쓰기권한이 있는 tmp 디렉터리로 가서 bof.c 파일에 저 내용을 옮겨보겠습니다. 정상적으로 옮기는데 성공했고, 이제 gcc를 통해 컴파일한 후 gdb를 통해 살펴보겠습니다. 기본적인 세팅을 해주고 여기까지가 main이네요. 잘 보면 fgets 함수 call 이전에 lea를 통해 eax에 ebp-40의 주소값을 넣고 push하는것을 볼 수 있습니다. 이는 fgets의 인자로 ebp-40이 들어간다는 소리이므로 $ebp-0x40 == buf와 같다고 생각할 수 있습니다. 또 st..
Stack Oveflow를 공부할 때 사용하는 gcc 옵션을 정리해보겠다. -m32 32비트 모드로 컴파일하는 옵션이다. 64비트로 하고싶다면 -m64를 주면 된다. -no-pie PIE를 끄는 옵션이다. PIE를 통해 컴파일을 하게 되면 실제 주소에 상대 주소가 매핑되어 실행할 때마다 주소 값이 바뀌며 단순하다는 특징을 가지고 있다. -z norelro RELRO는 Relocation Read-Only의 약자로 바이너리의 symbol 및 got 등에 보호기법을 거는 것을 말한다. NO RELRO는 ELF 기본헤더, 코드영역을 제외한 거의 모든 부분에 Read, Write 권한을 준다. Partial RELRO는 NO RELRO에서 _DYNAMIC 섹션에 Write 권한이 없다. FULL RELRO는 b..
shadow 파일은 /etc/passwd 파일의 계정정보를 암호화하여 저장한 파일 형태를 말하죠. 이 파일의 용량이 2700이라네요. 그러면 find / -size 2700c 2> /dev/null 명령을 입력해줘서 찾아보죠. 다음과 같이 나오네요. 아무래도 의심스러운 이름인 found.txt를 찾아가보죠. 파일 정보도 알아보겠습니다. 그냥 root가 파일의 소유자이고 읽기 권한이 level8 계정에 주어져있네요. 내용을 보겠습니다. 똑같은 문장이 엄청나게 많이 나오네요. 근데 생각해보니 이거 shadow 파일이었죠. shadow 파일의 저장방식을 분석해보겠습니다. level9:$1$vkY6sSlG$6RyUXtNMEVGsfY7Xf0wps.:11040:0:99999:7:-1:-1:134549524 1. 계..
흠 ㅋㅋ.. /bin 디렉터리로 가서 level7 파일을 확인해보겠습니다. level8이 파일 소유자이고 setuid가 설정되어있군요. level7 파일을 실행해보겠습니다. /bin 디렉터리에 wrong.txt 파일이 없다고 나오네요. 틀렸다면 틀렸다, 맞았다면 맞았다고 해야할텐데.. 출력 방향도 못바꾸니 어떡할까요? 답답한 마음에 찾아보니 로컬 환경에서 구축한 경우에 wrong.txt 파일이 누락될 수도 있다고 하네요 ㅋㅋ wrong.txt의 내용 --_--_- --____- ---_-__ --__-_- 위를 참고해 풀이를 보지말고 한 번더 도전해보는걸 추천합니다. 힌트를 생각해봅시다. 1. 패스워드는 가까운곳에... 2. 상상력을 총동원하라. 3. 2진수를 10진수로 바꿀 수 있는가? 4. 계산기 설..
