Cracking Windows Password Hash with Kali linux Live Booting
Kali linux USB Live Booting #blkid ;를 통하여 장치확인 #mkdir /media/hdd ; 임시로 마운트 시킬 디렉터리를 생성 #mount /dev/sda1 /media/hdd ; 이 경우 장치 이름이 sda1 // NTFS 라는 단어를 통해 찾으면 된다. ophcrack > Load > Encrypted SAM > C:\Windows\System32\config Open NT Hash 값을 따로 메모장에 적어주고 *.hash 라고 저장해준다. ex)win.hash #hashcat -m 1000 -a 3 win.hash ?a?d?l?s?a?a?a 자세한 사용방법은 --help를 통해 확인하는 것이 좋다. 출처https://www.youtube.com/watch?v=4EgYRx..
2015.08.22
FTZ Level20 //FSB
문제확인Hint를 확인할 경우 아래와 같이 간단한 소스를 확인 할 수가 있다. 하지만 여기서 보아야 할것은 bleh[80]인데 fgets로는 79byte 까지만 입력을 받는 것을 볼 수 있으며 이를 통하여 BOF는 할 수 없다는 것을 알 수가 있다. 그렇다면 다른 부분을 보아야 하는데 바로 printf(bleh)이다. 여기에는 포멧 스트링이 존재 하지 않기 때문에 이를 통하여 공격을 할 수가 있다. gdb로 확인을 할려 했으나 확인이 되지 않기에 직접 hint의 소스를 통하여 같은 프로그램을 컴파일 하였다. 역시 BOF는 불가능 한것을 확인 할 수가 있다. 우선 문제를 직접 실행하여보자. AAAA %8x %8x %8x %8x를 할 경우에 AAAA가 저장된 곳이 출력이 되는 것을 확인 할 수가 있다. 따라..
2015.05.31
no image
FTZ Level19 //Chaining RTL Calls
문제확인우선 문제는 아래와 같이 단순한 형태를 띄고 있다. 하지만 여기에서 주의 해야할 것은 기존과는 다르게도 setreuid가 존재 하지 않는 것을 유의 하여야 한다. 이제 아래와 같이 GDB를 통하여 스택을 확인해보면 40바이트가 할당이 되어 있는 것을 확인 할 수가 있다. 이는 buf[20] - Dummy[20] - SFP - RET의 형태로 존재하는 것을 확인 할 수가 있다. RTL - 실패우선 RTL을 통하여 공격을 하여보자. 기존과 같이 system( ) 함수를 이용한 공격을 할 경우 권한 상승이 이루어지지 않은 것을 확인 할 수가 있다. 바로 setreuid가 존재하지 않기 떄문이다. 따라서 system()함수를 이용한 공격은 현재 이 자체만으로는 효력이 부족하다는 것을 알 수 있다. 따라서..
2015.05.28
no image
FTZ Level18
문제확인우선 바로 hint를 확인하여 소스코드를 보면 아래와 같이, 지금까지의 소스보다 긴 것을 확인 할 수가 있다. 하지만 여기서 잡아야 할 것은 난잡한 다른 코드가 아닌 count의 값을 감소시켜주는 swith문을 확인 할 수가 있어야한다. 아래 코드에서 보는 것과 같이 "\x08"이 입력될 경우 count의 1 감소하는 것을 확인 할 수가 있다. 스택의 구조를 아래와 같이 확인을 해볼 경우 fds[132] - count[4] - x[4] - Check[4] - string[0] ~ string[100] - SFP -RET 이러한 형태로 나타나는 것을 확인 할 수가 있다. 여기서 우리가 알아야할 것은 기존의 string과 같은 역할을 하는 변수의 위치가 Low 쪽에 위치하기에 우리는 버퍼를 덮어 씌울..
2015.05.25
no image
FTZ Level17
문제 확인이제 벌써 17번 문제이다. 끝이 보이고 있으니 마저 풀이를 계속하여보자. 아래의 소스와 같이 16번 문제와는 다르게 Shell()이라는 함수가 존재하지 않고 main()에 setreuid가 존재하고 있는 것을 확인 할 수가 있다. 따라서 우리는 *call 포인터변수를 통하여 printit()가 아니라 우리가 쉘코드를 메모리에 올려 그 메모리의 주소를 가리키도록 해야 이 문제에서 쉘을 획득 할 수가 있다. GDB를 통하여 디스어셈블링을 해본다면 우선 main()에서 0x38만큼의 스택이 할당 되는 것을 확인 할 수가 있다. 또한 이전의 문제들을 통하여 우리는 스택의 구조를 짐작 할 수가 있다. 우선 Buf[20] - Dummy[20] - *Call[4] - Crap[4] - Dummy[8] - ..
2015.05.24
no image
FTZ Level16
문제확인바로 문제를 확인하여 보자. main()에서와 보는 것과 같이 printit를 호출한다. 하지만 여기서 shell()을 호출하도록 유도를 해야 쉘을 획득 할 수 있다는 것을 알 수가 있다. 여기서 *call 은 포인터 변수임을 잊지 말아야 한다. 우선 GDB를 통하여 프로그램을 분석해본다면 아래와 같이 shell() , printit(), main()의 순으로 되어있는 것을 확인 할 수가 있다. 여기서 확인 할 것은 main() 함수에 0x38만큼 스택이 할당 되는 것을 확인 할 수가 있다. 정확한 위치를 확인 하기 위하여 아래와 같이 입력을 하여 새로운 attackme_2를 만들어주자. 여기서 달라진 것이라 함은 crap에 "AAAA"라는 값을 주는 것으로 정확한 crap의 위치를 확인하기 위하..
2015.05.22
no image
FTZ Level15 //Hard Coding, EGG
문제확인우선 문제를 확인하여 보자. 레벨14와 비슷하지만 check 변수가 포인터 변수임에서 차이가 난다. 여기서 중요한 것은 포인터 변수는 그 변수가 메모리의 주소를 가리키고 있으며 그 주소의 값이 0xdeadbeef를 나타내어야 쉘을 획득 할 수 가 있는 문제이다. GDB를 통하여 확인을 해본다면, 스택에 0x38( = 56 ) 만큼이 할당 되는 것을 확인 할 수가 있다. 이를 통해 우리는 어느정도 유추를 할 수가 있지만 정확한 *check변수의 위치를 알아야 한다. 아래와 같이 코딩을 한 후에 실행을 하면 Buf[20] - Dummy[20] - Check[4] - Crap[4] - Dummy[8] - SFP[4] - RET[4] 가 스택에 놓여있는 것을 확인 할 수가 있다. 여기서 우리는 더 명확하..
2015.05.21
no image
FTZ Level14 //Distance
문제확인우선 hint 파일을 먼저 확인을 해보면 buf[20]과 check, crap이 스택에 할당 되는 것을 확인 할 수가 있다. 그리고 check의 값이 0xdeadbeef 일 경우에 쉘을 획득 할 수 있는 소스이다. 이또한 fgets를 통하여 45바이트 만큼만 전달이 될 수 있기에 BOF를 방지하고 있다. 이제 GDB를 통하여 메모리를 확인 하여 보자. DIsas을 통하여 확인 하였을때 0x38 == 50 바이트 만큼이 스택에 할당 되는 것을 확인 할 수가 있다. 하지만 여기서 우리는 Check라는 정확한 위치를 찾아야 하기 떄문에 우리는 더미가 얼마나 할당이 되는 지를 확인 할 수가 있어야 한다. 그렇기에 distance.c라는 프로그램을 우리가 작성하여 확인을 해보자. 아래와 같이 컴파일을 한 ..
2015.05.17

Kali linux USB Live Booting


#blkid    ;를 통하여 장치확인

#mkdir /media/hdd                         ; 임시로 마운트 시킬 디렉터리를 생성
#mount /dev/sda1 /media/hdd    ;  이 경우 장치 이름이 sda1 // NTFS 라는 단어를 통해 찾으면 된다.


ophcrack > Load > Encrypted SAM > C:\Windows\System32\config  Open

NT Hash 값을 따로 메모장에 적어주고 *.hash 라고 저장해준다. ex)win.hash

#hashcat -m 1000 -a 3 win.hash ?a?d?l?s?a?a?a
자세한 사용방법은 --help를 통해 확인하는 것이 좋다.


출처

https://www.youtube.com/watch?v=4EgYRxeFxbY     // 스무디 TV

'Hacking > System Hacking' 카테고리의 다른 글

FTZ Level20 //FSB  (0) 2015.05.31
FTZ Level19 //Chaining RTL Calls  (0) 2015.05.28
FTZ Level18  (0) 2015.05.25
FTZ Level17  (0) 2015.05.24
FTZ Level16  (0) 2015.05.22

문제확인


Hint를 확인할 경우 아래와 같이 간단한 소스를 확인 할 수가 있다. 하지만 여기서 보아야 할것은 bleh[80]인데 fgets로는 79byte 까지만 입력을 받는 것을 볼 수 있으며 이를 통하여 BOF는 할 수 없다는 것을 알 수가 있다. 그렇다면 다른 부분을 보아야 하는데 바로 printf(bleh)이다. 여기에는 포멧 스트링이 존재 하지 않기 때문에 이를 통하여 공격을 할 수가 있다.


gdb로 확인을 할려 했으나 확인이 되지 않기에 직접 hint의 소스를 통하여 같은 프로그램을 컴파일 하였다. 역시 BOF는 불가능 한것을 확인 할 수가 있다. 


우선 문제를 직접 실행하여보자. AAAA %8x %8x %8x %8x를 할 경우에 AAAA가 저장된 곳이 출력이 되는 것을 확인 할 수가 있다. 따라서

출력물 - 4f - 4212ecc - 42087a75 - 41414141 - 과 같은 순서로 구성이 되는 것을 확인 할 수가 있다. 따라서 우리는 인자로 DTOR_END의 주소를 주어서 그 주소에 새로운 값을 쓰도록 할 것이다. 공격 방법은 아래에서 구체적으로 설명을 하겠다. 이 41414141이 나오기 전의 3가지의 값을 우리는 버릴값이라고 임의로 정하자.


nm 명령어가 통하지 않기에 우리는 objdump -h attackme를 통하여 dtor_LIST의 주소를 찾는다. 그 후 이 LIST+4가 바로 DTOR_END의 주소임을 우리는 알아야 한다. 따라서 DTOR_END의 주소는 0x08049598 이다. 




공격


공격에 앞서 우리는 환경변수를 통하여 DTOR_END를 대체할 주소를 마련해야하며 이를 위하여 아래와 같이 환경변수를 등록을 한다. 그리고 공격에 쓰일 환경변수의 주소는 0xbffffc9d이다.


이제 Payload를 작성하면 아래와 같다. 이 페이로드에 대하여 설명을 하자 우선 FSB 공격의 경우에 흔히 "AAAA낮은주소BBBB높은주소"와 같은 형태로 쓰인다. 여기서 주목해야할 것은 바로 가운데에 있는 " + "를 기준으로 가독성을 위하여 일부러 나누어서 공격을 시도하였다. 우선 앞부분의 경우 인자로 "AAAA+DTOR_END(low)+BBBB+DTOR_END(high)"의 주소를 주고 있다. 낮은 주소와 높은 주소를 나누는 이유는 환경변수의 주소를 한 곳에 담을 수가 없기에 낮은주소에 2byte만큼을 그리고 높은주소에 2byte만큼을 입력하기 위함이다. 

그리고 뒤의 세번의 %8x를 통하여 우리는 앞에서 본것과 같이 버릴값을 지나친다. 세번의 포인터가 이동하기 떄문이다. 그리고 이 세번의 %8x 후에 포인터는 이제 인자가 나타내는 주소 "0x41414141"을 나타내고 있다. 이제 여기에 우리는 %(64629)c를 통하여 "AAAA낮은주소BBBB높은주소"로 이동을 하고 그 낮은 주소가 가르키는 주소에 %n을 통하여 값을 씌운다. 그리고 값을 씌운 이후 "AAAA낮은주소BBBB높은주소"에 위치하는데 여기에 %(50018)c를 통하여 한번더 이동하므로 "AAAA낮은주소BBBB높은주소"로 이동을 하게 되고 여기에 이제 %n을 통하여 값을 씌운다. 

이제 %64629c와 %50018c에 대하여 설명을 하자면 바로 환경변수의 주소를 나타내는 것이다. 환경변수의 주소는 0xbffffc9d인데 2byte씩 나누어서 값을 씌워야한다. 우선 FC9D의 값을 10진수로 변환하고 " + " 이전에 쓰인 16+ %8x*3 까지 포함하여 40Byte를 뺄셈한다. 그 값이 바로 64629이다. 이를 통하여 \x9d\xfc를 덮어 쓴것이다. 그리고 1BFFF-FC9D를 통하여 50018이란 값이 나오고 이를 통하여 \xff\xbf의 값을 씌우므로 우리는 결국 \x9f\xfc\xff\xbf 의 주소를 DTOR_END에 덮어 씌울수가 있다. 


이를 통하여 공격을 실행하여 우리는 쉘을 획득 할 수가 있다.

'Hacking > System Hacking' 카테고리의 다른 글

Cracking Windows Password Hash with Kali linux Live Booting  (1) 2015.08.22
FTZ Level19 //Chaining RTL Calls  (0) 2015.05.28
FTZ Level18  (0) 2015.05.25
FTZ Level17  (0) 2015.05.24
FTZ Level16  (0) 2015.05.22

문제확인


우선 문제는 아래와 같이 단순한 형태를 띄고 있다. 하지만 여기에서 주의 해야할 것은 기존과는 다르게도 setreuid가 존재 하지 않는 것을 유의 하여야 한다. 이제 아래와 같이 GDB를 통하여 스택을 확인해보면 40바이트가 할당이 되어 있는 것을 확인 할 수가 있다. 이는 buf[20] - Dummy[20] - SFP - RET의 형태로 존재하는 것을 확인 할 수가 있다.





RTL - 실패


우선 RTL을 통하여 공격을 하여보자. 기존과 같이 system( ) 함수를 이용한 공격을 할 경우 권한 상승이 이루어지지 않은 것을 확인 할 수가 있다. 바로 setreuid가 존재하지 않기 떄문이다. 따라서 system()함수를 이용한 공격은 현재 이 자체만으로는 효력이 부족하다는 것을 알 수 있다.


따라서 이번에는 execl() 함수를 통한 공격을 해보려 했다. 하지만 깔끔하게 Segmentation fault가 발생 한 것을 확인 할 수가 있다. //사실 이 방법은 첫 시도 였는데...실패..





Chaining RTL Calls


위 와 같이 그냥 공격으로는 공격이 성공하지 않는 다는 것을 확인 했다. 그래서 RTL과는 비슷하면서도 좀더 고급기법인 ROP를 공부하던 도중에 Chaining RTL Calls 라는 방식을 알게 되었다. 이는 RTL을 체인처럼 이어 여러 함수를 호출 하게 하는 것이고 그것을 가능하게 하는것이 바로 POP-RET 이다. 

대략적인 페이로드는 아래와 같이 구성을 하면 된다. 여기서 pop-pop-ret를 통하여 argv1,argv2를 Setreuid()함수에 인자로 전달을 해주고 마지막의 ret를 통하여 다시 system() 함수를 이어서 호출하게 된다. 그렇게 호출된 system()함수는 4바이트의 Exit()를 지나 "/bin/sh"를 인자로 전달 받게 되면서 결국 RTL을 통하여 한개가 아닌 함수를 호출하는 것을 볼 수가 있다. 


아래와 같이 연속된 주소로 구성된 지점을 찾아야 한다. objdump를 통하여 찾을 수가 있으며 여기서 우리는 setreuid가 인자를 2개 전달받아야 하기 떄문에 붉은 테두리 안에 표시한 지점을 사용 할 것이다. 만약 인자 수가 더 많으면 pop-pop-pop-ret를 사용하면 되고 더 여러개의 함수를 사용하고자 할 경우에는 exit()의 위치에 다시 pop-ret를 넣어주면 된다. 저 붉은 상자에서 맨위의 pop주소가 우리가 사용할 주소가 되는 것이다.








EGG


Shell Code에 setreuid를 추가한 새로운 쉘코드이다. 기존의 쉘코드에 Setreuid(3100,3100)만 추가하면 되는 것으로 이 부분의 쉘코드는 아래와 같다. 쉘 코드는 다른 블로그를 찾다가 발견한 것 >> http://geundi.tistory.com/132 

"\x31\xc0\x31\xdb\x31\xc9\x66\xbb\x1c\x0c\x66\xb9\x1c\x0c\xb0\x46\xcd\x80"

따라서 여기에 기존의 25바이트 코드를 추가하면 된다. (붉게 표시한 부분이 해당 uid의 번호인 것 같다.)

"\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"

따라서 최종 쉘코드는 다음과 같다.

"\x31\xc0\x31\xdb\x31\xc9\x66\xbb\x1c\x0c\x66\xb9\x1c\x0c\xb0\x46\xcd\x80\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"



'Hacking > System Hacking' 카테고리의 다른 글

Cracking Windows Password Hash with Kali linux Live Booting  (1) 2015.08.22
FTZ Level20 //FSB  (0) 2015.05.31
FTZ Level18  (0) 2015.05.25
FTZ Level17  (0) 2015.05.24
FTZ Level16  (0) 2015.05.22

FTZ Level18

Kail-KM
|2015. 5. 25. 01:30

문제확인


우선 바로 hint를 확인하여 소스코드를 보면 아래와 같이, 지금까지의 소스보다 긴 것을 확인 할 수가 있다. 하지만 여기서 잡아야 할 것은 난잡한 다른 코드가 아닌 count의 값을 감소시켜주는 swith문을 확인 할 수가 있어야한다. 아래 코드에서 보는 것과 같이 "\x08"이 입력될 경우 count의 1 감소하는 것을 확인 할 수가 있다.


스택의 구조를 아래와 같이 확인을 해볼 경우 <Low>  fds[132] - count[4] - x[4] - Check[4] - string[0] ~ string[100] - SFP -RET  <High> 이러한 형태로 나타나는 것을 확인 할 수가 있다. 여기서 우리가 알아야할 것은 기존의 string과 같은 역할을 하는 변수의 위치가 Low 쪽에 위치하기에 우리는 버퍼를 덮어 씌울 수가 있었지만 여기서는 string이 Check보다 위쪽에 있기에 덮어 씌울 수가 없다. 하지만 우리가 알아야 할 것은 바로 포인터 변수의 이동이다. 바로 count-1을 통하여 우리는 버퍼를 이동 시킬 수가 있고 바로 그 조건이 위의 붉은 상자 안에 있는 값이다. 




공격


따라서 우리는 count의 값을 4번 이동 시켜 check에 0xdeadbeef의 값을 주어야 한다. 따라서 페이로드는 아래와 같다.




참고 : http://geundi.tistory.com/131

'Hacking > System Hacking' 카테고리의 다른 글

FTZ Level20 //FSB  (0) 2015.05.31
FTZ Level19 //Chaining RTL Calls  (0) 2015.05.28
FTZ Level17  (0) 2015.05.24
FTZ Level16  (0) 2015.05.22
FTZ Level15 //Hard Coding, EGG  (2) 2015.05.21

FTZ Level17

Kail-KM
|2015. 5. 24. 15:59

문제 확인


이제 벌써 17번 문제이다. 끝이 보이고 있으니 마저 풀이를 계속하여보자. 아래의 소스와 같이 16번 문제와는 다르게 Shell()이라는 함수가 존재하지 않고 main()에 setreuid가 존재하고 있는 것을 확인 할 수가 있다. 따라서 우리는 *call 포인터변수를 통하여 printit()가 아니라 우리가 쉘코드를 메모리에 올려 그 메모리의 주소를 가리키도록 해야 이 문제에서 쉘을 획득 할 수가 있다.


GDB를 통하여 디스어셈블링을 해본다면 우선 main()에서 0x38만큼의 스택이 할당 되는 것을 확인 할 수가 있다. 또한 이전의 문제들을 통하여 우리는 스택의 구조를 짐작 할 수가 있다. 우선 Buf[20] - Dummy[20] - *Call[4] - Crap[4] - Dummy[8] - SFP - RET 의 순으로 할당이 되는 것을 알 수가 있다. 하지만 여기선 fgets를 통하여 48바이트 만큼만 전달을 할 수가 있기에 우리는 RET를 통한 공격을 할 수가 없다.


우선 브레이크지점을 형성 한 후 메모리의 상태를 확인 하여 보자. 아래와 같이 0xbfffe080에서부터 buf가 시작이 되며 그 후에 0xbfffe0a8에 *call과 crap이 순차적으로 있는 것을 확인 할 수가 있다. 





공격


환경변수를 통하여 공격을 진행하여 보자. 아래와 같이 페이로드를 입력한 후에 공격을 시도하면 공격에 성공하는 것을 확인 할 수가 있다.


Shell_Code[25Byte] : 

"\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"





의문점


아래와 같이 메모리를 확인할떄 A를 40개 만큼 줄경우 *call 위치에 0x804000a가 들어가는 것을 확인 할 수가 있으며, 만약 44만큼 A를 줄경우 Crap으ㅢ 위치에 0x804000a가 들어가므로 인하여 세그먼트 폴트를 일으켜 실행을 할 수가 없었다.




'Hacking > System Hacking' 카테고리의 다른 글

FTZ Level19 //Chaining RTL Calls  (0) 2015.05.28
FTZ Level18  (0) 2015.05.25
FTZ Level16  (0) 2015.05.22
FTZ Level15 //Hard Coding, EGG  (2) 2015.05.21
FTZ Level14 //Distance  (0) 2015.05.17

FTZ Level16

Kail-KM
|2015. 5. 22. 16:50

문제확인


바로 문제를 확인하여 보자. main()에서와 보는 것과 같이 printit를 호출한다. 하지만 여기서 shell()을 호출하도록 유도를 해야 쉘을 획득 할 수 있다는 것을 알 수가 있다. 여기서 *call 은 포인터 변수임을 잊지 말아야 한다.


우선 GDB를 통하여 프로그램을 분석해본다면 아래와 같이 shell() , printit(), main()의 순으로 되어있는 것을 확인 할 수가 있다. 여기서 확인 할 것은 main() 함수에 0x38만큼 스택이 할당 되는 것을 확인 할 수가 있다. 


정확한 위치를 확인 하기 위하여 아래와 같이 입력을 하여 새로운 attackme_2를 만들어주자. 여기서 달라진 것이라 함은 crap에 "AAAA"라는 값을 주는 것으로 정확한 crap의 위치를 확인하기 위하여 일부러 넣어 준 것이다.


gdb를 통하여 확인을 한 결과 우선 buf에 20만큼의 "A"를 넣어준다. 그리고 우리는 buf[20]이 할당 될 경우 dummy가 20만큼 추가로 할당 되는 것을 이미 여러 문제에서 확인을 할 수가 있었다. 이제 여기서 buf[20] + Dummy[20] + 호출주소값[4] - Crap[4] - Dummy[8] - SFP - RET 가 할당 되는 것을 알 수가 있다. 이제 호출주소값이 전달되는 위치에 shell()의 주소를 넘겨주면 된다

<Uttackme에서의 메모리>


<실제 Attackme에서의 메모리>

공격



'Hacking > System Hacking' 카테고리의 다른 글

FTZ Level18  (0) 2015.05.25
FTZ Level17  (0) 2015.05.24
FTZ Level15 //Hard Coding, EGG  (2) 2015.05.21
FTZ Level14 //Distance  (0) 2015.05.17
FTZ Level13 //RTL, EGG  (0) 2015.05.13

문제확인


우선 문제를 확인하여 보자. 레벨14와 비슷하지만 check 변수가 포인터 변수임에서 차이가 난다. 여기서 중요한 것은 포인터 변수는 그 변수가 메모리의 주소를 가리키고 있으며 그 주소의 값이 0xdeadbeef를 나타내어야 쉘을 획득 할 수 가 있는 문제이다. 


GDB를 통하여 확인을 해본다면, 스택에 0x38( = 56 ) 만큼이 할당 되는 것을 확인 할 수가 있다. 이를 통해 우리는 어느정도 유추를 할 수가 있지만 정확한 *check변수의 위치를 알아야 한다.


아래와 같이 코딩을 한 후에 실행을 하면 Buf[20] - Dummy[20] - Check[4] - Crap[4] - Dummy[8] - SFP[4] - RET[4] 가 스택에 놓여있는 것을 확인 할 수가 있다.


여기서 우리는 더 명확하게 Buf주소를 *check의 주소에 올리는 방법을 통하여 공격을 할 수 있는 지를 확인해보자. 아래와 같이 &buf의 주소를 보면 계속 변화하는 ASLR의 형태를 띄고 있는 것을 확인 할 수가 있다. 따라서 우리는 환경변수를 이용하거나 하드코딩의 방법을 이용하여야 한다.





Hard Coding


하드코딩이란 코딩시에 그 숫자나 문자열이 그대로 입력이 되어있는 것으로 이러한 방법을 통하여 풀 수 있는 문제가 은근히 많다는 것을 유의하여야 한다. 아래와 같이 GDB를 통하여 x/16x main을 확인하면 main+34의 부분에 키 값이 그대로 하드코딩 되어 있는 것을 확인 할 수가 있다.




EGG Shell


환경변수를 이용한 방법은 사실 여러번 실패를 하였다. 기존의 export EGG=`python -c 'print "\xef\xbe\xad\xde"'`를 이용한 방법의 경우는 실패 하였지만, 아래와 같은 방법으로 환경변수를 입력해 주었을때는 쉘을 획득 하는데에 성공을 하였다. 구체적인 이유는 알지 못하지만 일단 페이로드를 첨부한다.




'Hacking > System Hacking' 카테고리의 다른 글

FTZ Level17  (0) 2015.05.24
FTZ Level16  (0) 2015.05.22
FTZ Level14 //Distance  (0) 2015.05.17
FTZ Level13 //RTL, EGG  (0) 2015.05.13
FTZ Level12 //BOF,RTL,EGG,Backdoor  (0) 2015.05.10

문제확인


우선 hint 파일을 먼저 확인을 해보면 buf[20]과 check, crap이 스택에 할당 되는 것을 확인 할 수가 있다. 그리고 check의 값이 0xdeadbeef 일 경우에 쉘을 획득 할 수 있는 소스이다. 이또한 fgets를 통하여 45바이트 만큼만 전달이 될 수 있기에 BOF를 방지하고 있다. 이제 GDB를 통하여 메모리를 확인 하여 보자.


DIsas을 통하여 확인 하였을때 0x38 == 50 바이트 만큼이 스택에 할당 되는 것을 확인 할 수가 있다. 하지만 여기서 우리는 Check라는 정확한 위치를 찾아야 하기 떄문에 우리는 더미가 얼마나 할당이 되는 지를 확인 할 수가 있어야 한다. 그렇기에 distance.c라는 프로그램을 우리가 작성하여 확인을 해보자.


아래와 같이 컴파일을 한 후에 실행을 하였을 경우 Buf[20] + Dummy[20] + Check[4] + Crap[4] + Dummy[20] + SFP + RET 라는 것을 확인 할 수가 있다. 이제 이를 통하여 우리는 공격을 시도 할 수가 있다.



공격


Buf[20]과 Dummy[20]을 무작위 값으로 채운후에 Checkdp 0xdeadbeef를 씌어준다면 공격은 성공한다. 그리고 여기서 또한 cat을 붙여줌으로 인하여 입출력을 유지 하여야 한다는 것에 유의하여야 한다.


'Hacking > System Hacking' 카테고리의 다른 글

FTZ Level16  (0) 2015.05.22
FTZ Level15 //Hard Coding, EGG  (2) 2015.05.21
FTZ Level13 //RTL, EGG  (0) 2015.05.13
FTZ Level12 //BOF,RTL,EGG,Backdoor  (0) 2015.05.10
FTZ Level11 //BOF,EGG,Format String  (0) 2015.05.09