ㅋㅋㅋㅋ 그분의 추천으로 시작해본다
일단 파일을 보았다
ㅎㅎㅎㅎ;;;;
4개나있다고 ??ㅎㅎㅎㅎ
cpio는 처음보는 거라 봤더니 그냥 압축파일이라고 보면 된다.
lemonkit.ko 는 흔히보던 ELF파일이고
cpio는 무슨 압축파일이고
run.sh는 shell cript
vmlinuz는 부크 이미지 파일?이라고한다.
ko?파일만 분석하면 된다고 하시지만 또 내 호기심상 그게 안돼!!ㅋㅋㅋㅋ
.ko파일은 커널 모듈이라고 한다.
insmod lemonkit.ko -> 커널모듈 lemonkit.ko를 커널에 올린다.
mmod lemonkit.ko -> 커널모듈 lemonkit.ko를 커널에서 제거한다.
/lib/modules 에 보면 커널 소스를 버전별로 확인할 수 있다.
검색해보니 vmlinuz 뭐시기는 리눅스 커널이라고 한다.
뭐하는 코든지는 모르겠는데;;;;
DAV라는 거에 힌트가 있따고 한다.
WebDAV라는 취약점인데 2018년 까지도 여전히 있나보다.
국가정보원 8대 취약점에도 있는 것이다.
웹을 통해서 웹서버에 파일을 관리(목록 조회, 수정, 삭제 이동 등)핤 수 있는 확장된 HTTP 프로토콜을 말한다고 한다.
흠......................
WebDAV취약점 예방방법은
1. 불필요한 경우 WebDAV 서비스 중지
2. 운영체제 및 IIS버전 업그레이드
3. HJttpex. dii 파일의 Eveyone 권한 삭제
4. 홈 디렉토리 메뉴의 쓰기 권한 삭제
| codeengn - malware - 1 (0) | 2019.09.11 |
|---|
network 공격의 종류
1. 스니핑(도청), 스푸핑, 세션 하이재킹
2. DOS(Denial Of Service) -> SYN Flooding, UDP Flooding
3. Land, Ping of Death, Smurf, Tear Drop, Tiny Fragment
4. Fragment Overlap, IP Fragmenttation을 이용한 서비스 거부공격
1. 스니핑은 사용자 모르게 다가가서 사용자의 패킷을 훔쳐 정보를 들여다 보는 행위
2. 스푸핑은 mac이나 ip주소, port를 속여서 피해자가 정상적으로 패킷을 줘야하는 pc에 패킷을 주지 못하고 패킷을 크래커 피시로 보내버리게 되는 특징.
- ARP스푸핑
- DNS스푸핑
- IP스푸핑
3. DOS란 서비스 거부 공격, 크래커가 시스템의 ㅣ하드웨어나 소프트웨어 등을 무력하게 만들어 시스템이 정상적인 수행을 하지 못하게 방해하는 것.
- SYN Flooding : 3wayhandshacking이 진행되기 위한 과정을 정상적으로 이행하지 못하여 생기는 문제점
- UDP Flooding
- LAND : 출발지 ip와 도착지 ip가 같은 것을 의미한다. 즉, 너무 많은 재귀함수같은 작동의 반복으로 시스템의 자원이 너무 많이 낭비되어 자원을 할당하지 못함으로서 시스템이 뻗어버리는 증상이 생긴다.
- Ping of Death : 무수히 많은 ping을 미사일 처럼 쏴대는 공격을 의미. 수신 측 pc는 반드시 요청되는 ping을 다 응답받는 일을 해야한다. 이를 악용하여 너무 많은 ping은 받지 못하는 것을 이용.
- smurf attack : 희생자의 스푸핑된 원본 IP를 가진 수많은 인터넷 제어 메시지 프로토콜(ICMP) 패킷들이 IP 브로드캐스트 주소를 사용하여 컴퓨터 네트워크로 브로드캐스트하는 분산 서비스 거부 공격이다. 네트워크의 대부분 장치들은 기본적으로 원본 IP주소에 응답을 보냄으로써 이에 응답한다. 이 패킷에 응답하고 패킷을 수신하는 네트워크의 기계 수가 매우 많다면 희생자의 컴퓨터는 트래픽으로 넘쳐나게 된다. 이로 인해 희생자의 컴퓨터는 동작이 불가능해질 정도로 느려지게 될 수 있다.
- Tear Drop : 데이터가 송수신하는 과정에서 데이터의 송신한계를 넘어버리면 MTU(1500byte)로 나누어져 fragment number를 붙여 송신하고 수신측에는 fragment number로 재조합하여 분석하는 방법인데, fragment 내 나누어진 byte정보(framentation offset)을 위조하여 offset을 중복되게하거나 작은 공간을 만들어 두어 수신측에서 재조합을 하기 어렵게 만들어 시스템을 다운시킨다. TCP 헤더(일반적으로 20바이트)가 2개의 fragment에 나뉘어질 정도로 작게 쪼개서 목적지 TCP 포트번호가 첫 번째 fragment에 위치하지 않고 두 번째 fragment에 위치하도록 한다. 패킷필터링 장비나 침입탐지시스템은 필터링을 결정하기 위해 포트번호를 확인하는데 포트번호가 포함되지 않을 정도로 아주 작게 fragment된 첫 번째 fragment를 통과시킨다. 다음으로 들어오는 fragment의 경우 포트번호가 포함되어 있지만 필터링을 거치지 않고 통과시킨다.
- Tiny Fragment : 최초의 fragment를 아주 작게 만들어서 네트워크 침입탐지시스템이나 패킷 필터링 장비를 우회하는 공격. 해당 공격 기법은 nmap을 통해서도 공격이 가능하다(-f 옵션을이용)
- Fragment Overlap : 공격자는 공격용 IP 패킷을 위해 두 개의 fragment를 생성한다. 첫 번째 fragment에서는 필킷 필터링 장비에서 허용하는 http(TCP 80) 포트와 같은 포트번호를 가진다. 그리고, 두 번째 fragment에서는 offset을 아주 작게 조작해서 fragment들이 재조합될 때 두 번째 fragment가 첫 번째 fragment의 일부분을 덮어쓰도록 한다. 일반적으로 공격자들은 첫 번째 fragment의 포트번호가 있는 부분까지 덮어씌운다. IDS에서는 첫 번째 fragment는 허용된 포트번호이므로 통과시키고, 두 번째 fragment는 이전에 이미 허용된 fragment의 ID를 가진 fragment이므로 역시 통과시킨다. 이 두 개의 fragment가 목적지 서버에 도달하여 재조합되면 첫 번째 fragment의 포트번호는 두 번째 fragment의 포트번호로 overwrite되고 TCP/IP 스택은 이 패킷을 필터링 되어야할 포트의 응용프로그램에 전달한다.
- IP Framentation을 이용한 서비스 거부공격 : 이미 많이 알려져 패치가 완료 되었음.
이제 코드를 보면
ipHeader.ttl = 128
// time to live 에서 128값은 보통 윈도우즈 환경에서 라우터를 몇번 거쳤는지 알 수 있고 (홉 수라고도 하고) 디폴트 값으로 알려져있다.
ITimerCount=GetTickCount() : 시간 부여 받기
while(g_cMainCtrl, mcDDOS, m_bDDOSing) : DDOS 분산 서비스 공격, 많은 패킷을 쏜다.
tcpHeader.th_sum=0; tcpHeader.th_dport=htons(TargetPort); : 희생자의 포트를 넣고
ipHeader.sourceIP=htonl(ISpoofIP); : spoof하는 ip가 있다.
psdHeader.saddr=ipHeader.sourceIIP; : 출발지 ip를 대입.
memcpy(szSendBuf, &psdHeader, sizeof(psdHeader));
memcpy(szSendBuf+sizeof(psdHeader), &tcpHeader, sizeof(tcpHeader));
tcpHeader.th_sum=checksum((unsigned short *)szSendBuf,sizeof(psdHeader)+sizeof(tcpHeader));
: 변수명으로 보아 보내는 버퍼들이고, psdHeader의 크기만큼 복사, 마지막에 체크섬(중복)을 확인함
memcpy(szSendBuf, &ipHeader, sizeof(ipHeader));
memcpy(szSendBuf+sizeof(ipHeader), &tcpHeader, sizeof(tcpHeader));
memset(szSendBuf+sizeof(ipHeader)+sizeof(tcpHeader), 0, 4);
ipHeader.checksum=checksum((unsigned short *)szSendBuf, sizeof(ipHeader)+sizeof(tcpHeader));
: ipHeader만큼 크기를 복사하는 것이고, 마지막에 체크섬을 확인.
rect=sendto(sock, szSendBuf, sizeof(ipHeader)+sizeof(tcpHeader),0,(struct sockaddr*)&addr_in, sizeof(addr_in));
: sendto() 함수는 UDP/IP 통신에서 소켓으로 데이터를 전송하는 함수이다.
: int sendto(소켓 디스크립터, 전송할 데이터, 데이터의 바이트 단위 길이, 전송을 위한 옵션, 목적지 주소정보, 목적지 주소 정보의 크기) 순이다.
: 반환 값은 -1이외 : 실제 전송한 바이트 수, -1은 실패다.
if((GetTickCount()-lTimerCount)/1000>len) break;
: GetTickCount함수를 사용하여 이 코드가 실행된 만큼에서 1000을 나누었을 때 주어진 len보다 크게되면 작업을 중단.
if(bRandPort) { TargetPort=brandom(1000, 10000); }
: 희생자 pc의 포트를 1000~10000사이에 아무거나 선택하게 한다.
: 즉 알려지지 않은 포트를 이용한 취약점 혹은 악성코드를 노린것으로 보인다.
szSpoofIP[0]=(char)brandom(0, 255); szSpoofIP[1]=(char)brandom(0, 255);
szSpoofIP[2]=(char)brandom(0, 255); szSpoofIP[3]=(char)brandom(0, 255);
: 실제 IP에 대한 정보를 담는 것으로 추정.
while에 있는 것으로 보아 매크로 값은 무한루프를 위한 '1'값이라고 볼 수 있다.
무수히 많은 패킷을 던져주고도 그 패킷을 온전하게 수신측이 전달받지 못하는 기법은 SYN Flooding기법이다.
정확한 SYN Flooding 기법은 다음과 같다.
tcp 통신에서 세션 연결을 위해 서버에서 SYN패킷을 보내면 서버는 SYN+ACK로 응답을 하면서 자연스레 SYN_RECV 상태가 되고 클라이언트에게 응답을 "받기 전"까지 시간을 일정하게 유지한다.
(문제에서 Sleep(delay)는 이 시간을 일정하게 유지하는 역할)
또한 다른 일정 시간 유지할 떄를 프로세스 상태로 보았을 때 대기상태라고 가정을 하게 된다면 다른 작업이 가능하다고도 볼 수 있다.
이렇게 하나 툭 던져두고 시스템이 쉴때 크래커는 재빠르게 다른 아이피와 포트를 이용해서 "출발지"를 계속 바꾸어버리고 이 출발지에 대한 정보를 서버는 고스란히 받게된다.
이때 너무 많은 세션이 생겨버리면, 서버입장에서 "이 많은 애들을 어떻게 다 받아들여야해??" 하면서 멘붕에 빠지게 되면서 자신(서버)의 자원을 소모하게 되다가 결국 소진되어버리면서 다른 사용자가 tcp통신을 못하게 막는다.
SYN Flooding을 방어하는 방법은?
차단하는 방법 1. SYN Cookie
방화벽 단에서 SYN을 먼저 받고, SYN Cookie를 포함한 SYN+ACK를 보내는 방법이 있다. 일정 시간동안 SYN Cookie에 대한 정상적인 응답패킷이 들어오지 않으면 방화벽에서 차단해버리고, 정상적인 패킷이 들어오면 통신이 가능하게끔 해주는 방식이다. 이런식으로 작동됨.
1) SYN이 들어오면, syn_cookie가 포함된 SYN+ACK를 보낸다.
2) 그리고 syn_cookie에 적절히 대응하는 정상적은 ACK패킷이 들어오면, 세션을 새로 연다.
즉, 처음 방화벽과 3-way-handshake가 이루어진 것은 없는 셈 치고, 방화벽은 새로운 3-way-handshake 패킷을 서버에 연결해 주는 것이다.
따라서 Client는 첫 접속에 실패하는 것처럼 보일 수도 있다.(Cliend의 재접속 요청은 순식간에 이루어지기 때문에, 사용자로서 체감상으로 느낄 수는 없다.)
2. SYN PROXY
방화벽 단에서 정상적인 3-way-handshake과정이 이루어지면, 그 연결을 다시 서버에서 재현해주는 방식이다.
3-way-handshake 연결이 이루어지지 않은 경우에는 방화벽에서 쳐낸다.(차단한다)
SYN PROXY도 역시, syn_cookie를 이용해서 정상적인 3-way-handshake인지를 확인한다.
syn_proxy는 세션을 새로 열 필요가 없다. client와 방화벽 사이에 맺은 3-way-handshake를 방화벽이 서버에게 다시 재현해주기 떄문에, 세션을 새로 맺을 필요가 없다.
Proxy Server를 중간에 하나 둔다고 생각하면 마음이 편할 것이다.
| codeengn - malware - 2 (0) | 2019.09.12 |
|---|