fedora 원정대 core3 gate -> iron_golem

fedora 원정대 core3 gate -> iron_golem

iron_golem, iron_golem.c

문제에 들어가기에 앞서 redhat원정대와 fedora원정대의 환경의 차이점을 알아보자.

[환경 요약]
Stack Dummy : O
Down privileage of bash : O
Random Stack : O
Random Library : X
Random Program Binary Mapped : X
ASCII Armor : O
Non-Executable Stack : O
Non-Executable Heap : O
Stack Carany : X
Stack Smashing Protector : X

fedora에서는 1. 스택의 주소가 랜덤이여서 스택의 주소를 입력으로 넣어주기 힘들고 2. 스택에 실행 권한이 없기 때문에 스택안에 심어논 쉘코드를 실행이 불가하다. 그리고 3. ASCII amor가 걸려있어서(함수주소의 처음에 NULL을 삽입) 함수를 연속적으로 호출 할 수 없다.


코드를 보면 간단해 졌지만 환경에 제약조건이 많이 걸려있기 때문에 bof문제들보다 더 어렵다.

먼저 취약점은 strcpy에서 argv[1]을 버퍼로 복사하는 과정에서 발생한다.
버퍼의 크기가 256이므로 4바이트를 더 넣어 sfp를 덮을 수 있고 추가로 4바이트를 덮어서 ret까지 쉽게 조작 할 수 있다.
스택에 실행 권한이 없기 때문에 쉘을 입력으로 넣어 스택에서 실행하기는 힘들어 보인다. 그래서 쉘을 주는 프로그램을 작성하고 메모리중 고정값인 GOT를 이용해서 fakeEBP를 사용하여 공격 할 것이다. 리눅스는 윈도우에서의 IAT테이블같이 프로세스를 메모리에 로딩시 함수 주소를 얻어오지 않고 함수를 호출할때 plt, got테이블을 거쳐서 함수의 주소를 얻어온다.

쉘을 얻어오는 간단한 프로그램을 작성해본다.


이 함수를 실행하면 프로그램실행한 권한으로 쉘이 떨어진다.

공격은 ret를 execl의 주소로 덮고 execl의 인자로 위의 쉘을 주는 프로그램을 넣어 execl이 쉘을 주는 프로그램을 상승된 권한으로 실행하게되어 쉘을 딸 것이다.

이 공격은 leave, ret을 이용하여 공격을 하는것이다.
leave는 move esp,ebp/pop ebp로 동작하는데 pop ebp를 실행하면 fakeEBP에 의해서 GOT-8을 ebp가 가리키게 된다.(esp는 leave의 pop ebp에 의해서 메인스택의 ret를 가리킨다, 메인스택의 ret를 execl로 덮어 씌울 것이다.) 그리고 ret(pop eip, jmp eip)가 실행 되면서 메인스택의 ret인 execl함수를 콜하게 되고 심볼릭링크로 argv[1]자리에 쉘을 주는 프로그램을 걸어놓아서 쉘을 주는 프로그램이 상승된 권한으로 실행되게 된다.

여기서 주의해야할 점은 프롤로그에 의해서 ebp가 움직이면 심볼릭링크가 걸린 쉘을 주는 프로그램을 제대로 참조 할 수 없게 된다.
그렇기 때문에 execl의 프롤로그의 맨처음인 push ebp다음인 move esp,ebp부터 실행하게 하여 원하는 인자를 제대로 참조 할 수 있도록 해야한다.

got테이블의 주소를 확인한다.


GOT의 주소를 알 수 있다.


GOT의 처음주소엔 0x01이 들어가있고 두번째에는 0x0이 들어가있는 것을 볼 수 있다.
GOT-8을 ebp로 설정해줌으로 고정값인 0x1이 인자로 들어가고 0x1을 심볼릭링크로 쉘을 주는 프로그램과 이어준다. 그렇게되면 execl의 함수가 실행될때 argv[1]을 쉘을 주는 프로그램으로 사용하게 된다.
(ln -s systemf `python -c 'print "\x01"'`)

페이로드는
[버퍼][fakeEBP][execl]
로 구성하고 공격을 시도하면


쉘을 얻을 수 있다.
쉘코드 :
./iron_golem `python -c 'print "A"*264 + "\x10\x96\x04\x08" + "\x23\x57\x7a\x00"'`
Read more

windows xp kernel debugging

windows xp kernel debugging

윈도우 디버거는 크게 유저모드 디버거와 커널모드 디버거로 나눌수 있다.
유저모드 디버거는 유저권한으로 윈도우 프로그램을 디버깅 할수 있고 커널모드 디버거는 ring0 권한으로 윈도우 커널까지도 디버깅 할 수 있다.
윈도우를 공부하거나 루트킷등을 공부하다 보면 커널영역의 메모리를 확인해야 할 필요가 있다.

이번엔 커널모드 디버깅을 할 수 있는 환경을 구성해보겠다.
프로세스를 디버깅하게되면 프로세스는 동작을 안하고 eip가 잡혀있다. 커널모드는 윈도우자체를 디버깅 하는 것이기 때문에 윈도우가 멈춰있는다. 그렇기 때문에 2대의 컴퓨터가 필요하다. vm ware으로 가상머신을 실행하여 2대의 컴퓨터 환경을 구성하고 시리얼통신을 통해서 vm의 윈도우를 디버깅 할 수 있는 환경을 만들 수 있다.
디버거 컴퓨터에는 WDK(+symbols)를 설치하고 windbg를 사용하여 vm의 윈도우를 디버깅 할 것이다.

먼저 vm의 windows xp에 디버깅이 가능한 부트스위치를 추가해 주어야한다.
xp의 경우에 c:\boot.ini파일을 수정하여 부트스위치를 추가 할 수 있다.
boot.ini파일에

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect /debug /debugport=COM1

를 써넣어 시리얼포트로 디버깅을 가능한 디버그모드를 추가 할 수 있다.
vm의 소프트웨어적인 설정은 완료되었고 이제 시리얼포트를 꽃는 작업을 해주어야 한다.


호스트로 vm을 디버깅 할 것이기 때문에 named pipe를 선택하여 dafault값인 \\.\pipe\com_1을 추가해 준다.
vm에 부트모드를 추가해 주고 가상으로 시리얼포트를 꽃음으로 vm의 디버깅 할 환경 구성은 완료되었다.

이제 호스트컴퓨터의 windbg를 이용해서 vm을 디버깅해보자.


file -> kernel debug를 클릭하고 vm에 설정한 pipe의 이름을 적어준다.
호스트와 vm이 시리얼통신을 할 수 있게 연결이 되었다. 확인을 누르고 vm을 실행 시키면


boot.ini파일을 수정하여 추가한 디버그모드가 뜨게 된다. 디버그모드를 선택하면 커널 디버깅을 할 수 있다.
이제 디버깅을 할 수 있는 환경이 구성되어 있지만 함수이름,구조체,변수이름등을 포함하는 심볼파일이 없기 때문에 디버깅이 매우 힘들다. 심볼파일을 받아 와야한다.

File -> Symbol file path를 선택하고
SRV*.*http://msdl.microsoft.com/download/symbols
를 입력하여 마이크로소프트 심볼서버로부터 심볼을 받아올수 있다.


커널 디버깅을 할 수 있는 환경이 구성되었다.
Read more

BOF redhat 원정대 xavius -> death_night

BOF redhat 원정대 xavius -> death_night

death_night, death_night.c

코드를 보면 remote BOF라는 것을 알 수 있다. 소켓통신을 하기 위해서 소켓구조체들에 값을 넣어주고 bind, listen, accept를 거치는 기초적인 서버 코드이다.
클라이언트와 서버의 tcp연결이 맺어지면 fork로 자신과 같은 프로세스를 낳고 문자열을 보내고 recv에서 클라이언트의 입력을 대기하게 된다.
recv과정에서 40사이즈의 버퍼에 256을 받아오기 때문에 이를 이용해서 RET를 이동하게 할 수 있다.


6666포트로 클라이언트의 연결을 리슨하고 있는 것을 확인 할 수 있다.

페이로드는
[놉][RET][놉+쉘코드]
로 구성 하고 스택의 주소를 알 수 없기 때문에 0xbfff0000 ~ 0xbfffffff까지 주소를 브루트포싱해서  쉘을 얻을 것이고 쉘코드는 리버스쉘을 이용하여 포크된 자식프로세스가 내 컴퓨터에 접속하여 쉘을 넘기는 방법으로 공격을 할 것이다.
*쉘코드는 msfpayload를 사용하여 만들었다.


놉 개수와 메모리 증가 값을 적절히 수정하다 보면 공격에 성공하여 쉘을 얻을수 있다.

Read more