[보안] FTZ 문제 Write-Up

최근 북한이 해킹 등을 통해 많은 정보 및 재화를 탈취하는 것처럼 나중에 개발하게 될 프로그램 및 서버에 보안 위협이 있을 것을 대비해, 컴퓨터 구조 및 리눅스 OS에 대해 직접 모의 해킹을 하여 배워보기로 했다.준비한 문제들은 꽤 오래된 문제들이지만, 후반부의 문제는

가장 먼저 ls를 입력해 현재 디렉토리에 무슨 파일이 있는지 확인한다.hint 파일이 하나 있다. cat으로 확인한다.setuid란, 특정 사용자의 uid를 통해 그 사용자의 권한으로 프로그램이 실행되도록 하는 것이다. 프로그램이 만약 지금 계정의 권한보다 상위의 권한

hint 파일이 있어 확인했더니 다음과 같이 나온다.이게 무슨 뜻일까?텍스트 파일 편집이라고 했으니 이번에는 텍스트 에디터 파일을 찾아야 할 것 같다.find 명령어를 통해 setuid가 걸린 level3 소유의 실행 파일을 찾는다.딱 봐도 에디터처럼 보이는 실행 파일

이번에도 hint 파일이 있어 확인해 보았다.autodig라는 프로그램의 소스 코드가 나왔다.코드를 해석해 보니, argc가 2가 아니라면 버전 및 사용법이 표시되고, 그 이외의 경우 dig이라는 명령어를 실행하는 코드이다.dig은 DNS 정보를 표시하는 명령어이기 때

이번에도 hint를 확인해 보았다./etc/xinetd.d에 백도어가 있다고 한다. xinetd는 리눅스 슈퍼 데몬으로, 인터넷 서비스의 연결 및 프로세스 제어를 담당한다.해당 디렉토리로 이동해서 파일들을 확인해 보자.대놓고 backdoor라는 파일이 있다.한 번 ca

hint를 확인해 보았다.그렇다고 한다.먼저 /usr/bin/level5에 level6 권한으로 setuid가 걸려 있는지 확인한다.setuid가 걸려 있는 것을 볼 수 있다. 내가 예상하기로는, /usr/bin/level5를 실행한 뒤에 생성되는 level5.tmp

level6으로 접속했더니 다음과 같은 힌트가 나왔다.인포샵이 뭔지도 잘 모르겠다.인터넷에 검색해 보니 PC통신 시절에 쓰이던 BBS라는 것 같다.엔터를 치고 아무런 BBS에나 접속을 해 보았다.될 리가 없다. 이미 다 없어진 BBS일테니 말이다.3개 다 어디서 들어본

hint는 다음과 같다.한 번 /bin/level7을 실행해 보자.패스워드를 입력하라고 하길래 아무렇게나 입력했더니 이상한 문자열이 출력되고 종료된다.딱 봐도 2진수다.\-가 1이고, \_가 0인 것 같다. 중간에 공백도 있으니 구간 하나 당 문자열 하나를 뜻할 것이다

hint를 확인해 보았다.shadow 파일은 리눅스 사용자들의 암호화된 패스워드를 담고 있는 파일이다.shadow 알고리즘은 해시 함수이기 때문에 일반적인 방법으로는 복호화할 수 없고, 브루트포스(무차별 대입)을 사용해서 복호화해야 한다.주어진 힌트는 용량이 2700이

hint는 다음과 같다.본격적으로 버퍼 오버플로우 문제가 나온다.먼저 개념에 대해 설명한다.버퍼 오버플로우란, 프로그램의 정해진 버퍼 사용량을 넘치게 만들어 의도되지 않은 동작을 일으키는 기법이다. 컴퓨터 구조와 관련된 문제이기 때문에 어셈블리어 등의 로우레벨 지식이

hint는 다음과 같다.공유 메모리란, 다수의 프로세스에서 동시에 접근 가능한 메모리이다.C언어에는 이 공유 메모리에 접근 가능한 함수로 shmget이 있다.key_t는 공유 메모리를 구별하는 식별 번호이기 때문에 shmget을 이용할 수 있다.먼저 ipcs 명령어를

hint는 다음과 같은 소스 코드다.attackme의 소스 코드인 것 같다.attackme는 level12 권한으로 setuid가 걸려 있다.attackme에 대한 권한이 없으므로 힌트에 나온 소스 코드를 gcc로 새로 컴파일 후 gdb로 역어셈블한다.<main+

hint는 다음과 같다.문자열을 프로그램 실행 인자에서 가져오던 것이 gets 함수로 바뀐 것을 빼면 Level 11과 별다른 점이 없다.소스 코드를 다시 컴파일하고 gdb로 뜯어 보았다.<main+0>, <main+1>에서 스택의 기본 프레임을 만들고 &l

hint는 다음과 같다.이번에는 버퍼 오버플로우를 방지하기 위한 장치가 있는 것을 볼 수 있다.i가 변조될 경우 버퍼 오버플로우로 인식해 프로그램을 강제로 종료한다.argc가 1보다 클 때 strcpy 함수가 실행되기 때문에 이번 문제는 실행 인자를 통해 입력을 받는다

hint는 다음과 같다.이번에는 실행 인자가 아니라 fgets로 입력을 받는다.Level 9와 비슷하게 길이 제한이 buf보다 25바이트나 크기 때문에 버퍼 오버플로우가 발생할 수 있다.그리고 Level 13과 비슷한 check라는 변수가 있는데, 변수의 값이 0xde

hint는 다음과 같다.이번에는 check 변수가 포인터로 선언되었다.포인터가 가지는 값은 특정한 주소가 가리키는 값이기 때문에 0xdeadbeef를 직접 넣으면 0xdeadbeef가 가리키는 값을 찾아가게 된다. 이 문제에서는 포인터에 들어간 주소가 가리키는 값이 0

hint는 다음과 같다.이번에는 함수가 3개다. main 함수를 보면 call이라는 void형 포인터에 printit 함수의 주소를 넣고, fgets 함수가 실행된 이후에 호출하는 것을 볼 수 있다.20바이트의 buf에 48바이트만큼의 입력을 허용하고 있기 때문에 버퍼

hint는 다음과 같다.Level 16의 소스 코드와 비슷하지만, 이번에는 shell 함수가 없고 setreuid 함수가 main 함수 안에서 호출되고 있다. system 함수를 통한 쉘 실행이 없기 때문에 쉘코드를 사용해야 한다.printit 함수의 시작 주소가 ca

hint의 코드가 상당히 길고 어려워서 아래에 따로 옮기고 주석을 붙였다.해석이 어렵지만, 초반의 변수 선언 부분을 보면 이전까지와는 다르게 check가 string보다 나중에 선언되고 있기 때문에 check를 일반적인 방법으로 변조할 수 없다. 그러나 switch문의

hint는 정말 짧다.Level 18에서 엄청나게 긴 코드를 주더니 이번 문제에서는 달랑 5줄이다.gets 함수를 사용하므로 문자열 길이를 체크하지 않고, 버퍼 오버플로우가 발생할 수 있다.그러나 이전 문제와는 다르게 setreuid 함수조차 없다. 그러므로 setre

대망의 마지막 문제다.hint는 다음과 같다.fgets를 이용한 표준 입력을 받고 있다. 그러나 이번에는 길이 제한이 bleh보다 작기 때문에 버퍼 오버플로우가 일어나지 않는다.하지만 printf를 보니 포맷 스트링 버그가 발생하는 부분이 있다.포맷 스트링 버그에 대해

Level 8 정도까지는 OS 사용에 대한 문제가 나와서 쉬웠지만 그 이후로 어셈블리어를 통한 버퍼 오버플로우 문제가 나와서 처음에는 이해가 힘들었다.그러나 스택이 어떻게 형성되는지만 이해하면 살짝씩만 바꿔 놓은 문제들은 쉽게 공격법을 파악할 수 있었다.Red Hat