저번 포스팅에 있었던 핸들러 문제를 해결해 봅시다..
위와 같은 메시지가 출력되며 아무런 패킷을 발생시키지 않았습니다.
현재 핸들러에서 reverse_tcp 페이로드를 사용중이었으나, exploit 코드 확인시 default 는 bind_tcp를 사용하는 것으로 확인되어 기본설정값으로 설정해보았습니다.
추가로 혹시나 exploit시 설정된 payload값이 실행되어, Multi Handler에서 설정된 페이로드와 중복되어 실행이 안되는것인가 싶어 Multi Handler를 꺼보았습니다.
또한 exploit 시에 HTTP Request를 보냈을때의 Response를 보내줄 웹서버를 구동시켰습니다.
winxp에서는 지원되는 APM이 없어서... CentOS(192.168.142.133)를 새로 깔았습니다.
준비를 다시 마친뒤, exploit을 해보았습니다.
Port : 7547로 접근하는 과정에서 이후 진행이 안되는 것 같습니다.
와이어샤크로 어떤패킷이 오갔는지 확인해봅시다.
7547로 따로 서비스 하고있는게 없어서 응답값이 아예 없는것같네요.
RPORT를 80으로라도 아쉬운김에 바꿔봅시다.
다시 exploit!
똑같이 접근이 안되네요. 와이어샤크로 확인해봅시다.
?!? 이번엔 뭔가 가긴했네요 404응답을 받으면서 이후에 있는 exploit 코드를 실행하지 않고 끝내는 것 같습니다.
상세 분석을 위해선 exploit 코드를 확인해봐야 할것 같습니다.
exploit 코드를 확인해보겠습니다.
우선 우선적으로 실행되는 check 메소드를 확인해봅시다.
/globe 경로를 탐색해서 response 값이 있고, 응답코드가 404이며, home_wan.htm이 body값에 포함되어 있으면 Appears로 Exploit Code를 설정하는 것으로 확인됩니다.
(루비에서 =~가 뜻하는게 뒤에오는 문자열 /<문자열>/이 있으면 매칭이 시작되는 인덱스값을 리턴한다고 함. 여기서는 문자열을 찾을 용도로 쓰인 것같다.)
body 값에 home_wan.htm은 포함되어 있지 않네요. 아마 해당 라우터에서의 응답값을 표기할때 주는 응답값인 것으로 추정됩니다. 하여 여기서 더이상 exploit 코드가 동작하지 않는 것으로 판별됩니다.
이후 진행이 불가능하나, 라우터를 살수는 없으므로 코드라도 분석해보자..
이후 실행되는 메소드는 execute_command 이다. 함수를 살펴보겠습니다.
URI = /UD/act?1 로 POST 방식으로 헤더값에 SOAPAction 값을 보내는 것으로 확인되네요.
SOAPAction은 SOAP 요청의 의도를 뜻한다고 합니다. 두번째 필드가 식별자라는데요 SetNTPServers 로보아 NTP서버를 앞에있는 urn(dslforum-org:service:Time:1)으로 지정하는것 같네요.
(SOAP란 ? Simple Object Access Protocol의 약자로, xml을 이용해서 분산처리환경에서 정보교환을 쉽게할 수 있도록 도와주는 거라고 하네요. http나 https, smtp등을 통해서 xml 기반의 메시지를 교환하는 프로토콜이라고 합니다.)
data_cmd에는 @data_cmd_template 인스턴스 변수 안의 1번 NTP서버 설정 xml 코드에 %s 부분에 iptables -I INPUT -p tcp --dport 80 -j ACCEPT 라는 시스템 명령어를 삽입해서 80번 포트를 열어놓는 것으로 보이며,
Mozi Botnet에서의 해당 취약점으로의 RCE 중에선 해당 부분에 시스템 명령어를 주입하는 것으로 확인됩니다.
이후 동작하는 메소드를 확인해보면 get_wifi_key 메소드를 통해 패스워드를 알아낸뒤, execute_command 메소드에 Eir 라우터의 원래 NTP 서버 tick.eircom.net 로 재등록하여 자취를 지우는 것으로 확인됩니다.
해당 취약점이 공개된 exploit 에서는 iptables를 수정하는 시스템 명령어를 사용한뒤, 패스워드를 알아내는 목적으로 사용하였지만, Mozi-botnet에서 해당 취약점을 이용할 때는 wget 을 통한 악성 파일을 다운로드 하는 전파성 공격으로 사용된 것이 확인됩니다.
해당 취약점으로만의 공격을 막기 위해선 request에 body 값에서 iptables를 막으면 될것같으나, kali에서 실제 exploit을 edit을 통해서 코드를 확인해보면 공격시 사용되는 코드는 iptables를 통한 공격이 아닌 inject_staged_data 메소드인 것으로 확인됩니다.
해당 메소드를 살펴보니
이렇게 되어있는데요.. flavor 인자값에 wget을 집어넣는것을 보니,, Exploit DB 사이트에 나와있는 iptables를 이용한 공격이 아닌, kali로 제대로 공격이 되었을 때는 wget을 통한 어떤 동작을 하는것 같습니다. 아마도 평소 업무를 하면서 자주보이는 형태의 wget을 통한 파일 다운로드 공격으로 추측되는데.. 찾아보니 인스턴스 메소드라고는 하는데..자세한건 execute_cmdstager 메소드에 대해서 좀더 찾아봐야겠습니다....
우선 이번꺼는 여기까지...
참조
www.exploit-db.com/exploits/40740
'cert' 카테고리의 다른 글
| jenkins login 페이지 스캔 (1) | 2021.03.01 |
|---|---|
| Mozi Botnet 에서의 Command Injection Attack - (4) (2) | 2021.03.01 |
| Mozi Botnet 에서의 Command Injection Attack - (2) (1) | 2021.02.14 |
| Mozi Botnet 에서의 Command Injection Attack - (1) (3) | 2021.02.14 |
| 보안인의 길 (2) | 2021.02.14 |
