sang's IT sang's IT

이 문제는 FTZ의 마지막 문제이기도 하고 가장 어려운 문제라고 생각한다... 이 문제의 핵심은 바로 Format String 취약점 즉, FSB 취약점을 이용한 문제인데요. 먼저 Format String이란 무엇이냐 아마 내일 올라올 포스팅을 확인 해주시면 감사하겠습니다...그 포스팅에 정리해두었거든요,,ㅎ 아직 포스팅중이라,,ㅎ헤헤헤ㅔㅔㅔ 음,, 이 사진에 다 담았는데요,,하나 하나 설명을 해보자면 위의 코드에서 format string이 터지는 이유는 printf 함수를 보시면 알 수 있습니다. printf(bleh); 라고 코딩되어 있는데요. 바로 여기서 취약점이 터지게됩니다.. 왜 터지는지는 이 후 나올 포스팅을 확인하시구요,, (이 글을 적는 시간이 새벽 3시인 관계로 너무 피곤합니다.,,) ..

이번 문제는 이전 문제들과 다른 문제이다. 문제의 코드를 보면 setreuid()함수가 존재하지 않는다는 것을 볼 수 있다. 즉, 직접 setreuid()를 넣어줘야 하는데 직접 쉘을 짜도 되고 아니면 에그쉘을 통해서 풀 수 있는 문제이다. 먼저 쉘 코드를 만들기 전에 gdb로 attackme를 분석해보자. 총 스택 길이는 40byte로 buf가 20byte이니 더미값은 20byte이다,그림으로 보면 이다. 이 문제는 bash drop privileges policy 을 활용한 문제인것 같다..----------------------------------------------------------------------------------RedHat 7.0 이후 버전부터 bash drop privileg..

++ 다시 라업을 적을거니 이 글은 참고만,,, 제대로 다시 풀 예정이다.!!! ++--> 결국 다시 풀었다ㅑ,, 풀이 방법은 동일하나 코드 분석을 그나마 조금이라도 정확하게 해보고 싶었다,,ㅎㅎㅎ 음,, 이 문제는 코드만 분석하면 반은 할 수 있는 문제인 것 같다,, ++2018.11.17 다시 코드를 보면 FD_xxx 라는 코드가 있는 것을 볼 수 가 있는데fd는 File Descriptor 의 줄임말로 자신이 사용할 파일 또는 장치에 대한 고유 식별 값이며 리눅스에서 특정한 파일에 접근하기 위한 키라고 할 수 있다.소켓 프로그래밍을 할 때 socket 함수를 사용하여 socket 을 생성하면 정수 값이 반환되는데 이 값이 fd 이다.그리고 fd는 같은 프로그램 내에서 중복되지 않으므로 고유 값으로 ..

이 문제는 그냥 보자마자 setreuid만 있길래 환경변수 등록해서 쉘 따는거다 싶어서 했더니 맞았다....힌트의 코드들이고 attackme를 실행했을 때의 모습이다.코드는 이전 문제의 코드와 거의 동일하기 때문에 하지않겠다. main() 함수 모습printit()함수의 모습 총 스택이 56byte고 buf변수 부터 fgets함수까지 길이가 40byte그냥 환경변수를 등록하고 변수 주소 찾은 뒤에 익스하면 된다. 뭔가 되게 쉬웠던 문제다...

이 문제는 이전 문제들과 다르게 함수를 사용해서 코딩을 해놓았다.. 덕분에 황당함을 감추지 못했다고,,간단하게 코드분석부터 해보면 main() 함수부터 crap 변수를 int형(4) 로 선언해주고 printit()함수의 호출 주소를 call에 저장하고 buf 변수를 char형(20)으로 선언했다. 그리고 fgets 함수를 이용해 표준입력을 받는다. 그 후에는 call 을 불러와 printit()함수를 호출한 후 프로그램이 종료된다. 여기서 생각해볼 수 있는것이 printit함수의 호출 주소를 저장하는 변수가 있는데 이곳을 shell() 함수를 호출하는 주소로 오염시켜버리면? 쉘을 얻을 수 있을것이다.근데 지금 손목이 너무나도 아프다, 그렇다 이건 의식의 흐름이니 무시하고 gdb로 분석을 해보자. 함수가 ..

이 문제는 14번 문제와 90% 동일 하다. 다른 것이라고는 포인터라는게 추가됬는데변수의 메모리 주소값이 같으면 풀리는 문제이다. 이 코드가 문제코드!!!! 그렇다,, ㅇ,, 피곤해죽을거같다.. main+32을 보면 eax와 비교하는 부분이 있는데 0xdeadbeef의 값이 하드코딩되어 있으므로 여기서의 주소값을 잡아서 뽑아내다보면 0xdeadbeef의 주소ㅓ값이 나오는다. 그럼 이전 문제와 스택구조는 같을테니까 그대로 익스하면 된다.나도 내가 뭔말을 하는건지 모르겠다.. 오늘 오후에 다시 풀어봐야되겠다.. 그럼 20000 ++ 2018.11.14 오늘 새벽에 했는데 잠결에 문제를 풀었다.. 근데도 풀렸,,///check 변수의 메모리 주소값과 0xdeadbeef이 일치하면 문제가 풀린다.그럼 check..

이 문제는 그냥 간단하게 스택구조만 만들어 낼 수 있다면 풀 수 있는 문제였다, 문제는 다음과 같다. fgets 함수로 45byte 까지 표준입력으로 받는다.그 다음 if문에서 check의 변수를 0xdeadbeef와 같은지 다른지 검사한 후 /bin/sh를 띄어주는 형식이다. gdb로 분석을 해보면 오른쪽과 같이 스택구조를 그려낼 수 있다. x038 -> 56에서 4를 더 추가한다,그런 후 fgets 에서 입력을 받고 29에서 검사를 하는 구조이다.총 스택값은 56이다. 28byte는 선언된 변수 값이고 나머지 28은 더미값으로 봐도 무관하다. int 형은 각 4byte 이고 buf값은 20 그런데 입력값은 45 그럼 더미 값은 20~21?이라고 추측이 가능했다..(뭔,,)따라서 공격 코드는 아래와 같다.

이 문제는 이전 문제와 다르게 스택가드라는 개념이 추가된 문제이다.소스코드를 보면 아래와 같다. buf string value에 1024 byte 를 할당시켜주고 인자값을 buf 변수에 copy하는데 strcpy함수는 길이 체크를 하지 않기 때문에 취약점이 존재하므로 이곳을 노려야 한다.if문은 i 값이 0x1234567이 아니면 에러를 뿜는다. kill 함수를 보면 signal(11, SIGEGV)를 전달하므로 세그먼트 폴트를 반환한다.따라서 i 값 즉, 스택가드 부분은 건드리지 않은채 버퍼오버플로우를 일으켜야 한다는 말이다. 먼저 gdb로 분석을 해보자.. 빨간줄을 그어 놓은 곳이 바로 비교하는 어셈인데 이 곳을 브포로 잡은 후 실행을 시켜본다. 시작 지점은 0xbffff1c0 0x1234567이 있..