홈페이지 취약점 분석 이야기 파일 지도 사진 깨알






>> 목록보이기
#ssh #방화벽 #취약한 비밀번호 #무작위대입공격 #네트워크 해킹 #brute-force attack #ssh brute-force #root권한 탈취 #서비스거부공격 #DoS #대용량 네트워크 트래픽 #로그분석 #/var/log/secure #/var/log/auth.log #침해사고 조사 #A5-Security Misconfiguration #DDoS #Xor DDoS #악성코드

서버 침해사고 사례: root 계정 SSH 무작위대입공격과 DoS 공격 (Xor DDoS)

침해사고 조사는 역사소설을 쓰는 것과 같다. 남겨진 자료(로그)를 바탕으로 어떠한 일이 있었는 지를 재구성하는 일이다. 자료가 부족할 때는 - 공격자가 가능한 흔적을 모두 지웠다면 - 밖으로 드러난 현상을 보고 가장 그럴듯한 시나리오를 만들어내야 하는 작업이기도 한다. 이 침해사고 조사 사례에서는 공격자가 침입 흔적을 지운 것을 발견하였지만 - 공격자의 실수로 - 남겨진 로그를 이용하여 침해사고를 재구성하였다.

침해사고 조사에서 사용한 SSH 접속 로그와 해커가 생성한 파일들을 묶어서 www-incident-ssh-brute-force.tgz에 저장해두었다. 직접 확인해보길 바란다.

[재구성한 침해사고 요약]

  • 2016.09.10: 회사 방화벽 노후로 신규 방화벽 교체작업 수행
    • 신규 방화벽 규칙을 재구축하는 과정에서 침해서버에 대한 외부로부터의 접근 규칙이 any로 변경되는 상황이 발생함 (2016년 9월 23일에 확인)
  • 2016.09.11: 다수의 외부 IP주소에서 SSH 포트(22/tcp)에 대한 무작위대입공격이 시작됨
  • 2016.09.12: 중국/홍콩의 2개 IP 주소에서 root 계정으로 접속 성공
  • 2016.09.13: 2종 이상의 Xor.DDoS Trodjan 악성코드를 설치하여 내부네트워크 공격
    • 내부에서 비정상적으로 최대 88MBps에 달하는 트래픽 발생(평상시: 1~3Mbps)
    • 트래픽 발원지가 해당 서버인 것을 확인하고, 침해 서버를 네트워크에서 분리 후 자체 조사 시작
  • 2016.09.22: 침해 서버를 네트워크에 연결하자 동일한 현상이 발생하여 다시 네트워크를 차단하고 외부에 침해사고 조사를 요청함
  • 2016.09.23: 외부 전문가에 의한 침해사고 조사 수행
    • 악성코드 발견 및 SSH 접속로그에서 (비밀번호가 취약한) root 탈취 과정 파악
    • 침해 서버를 외부에서 접속한 상황을 분석하고 방화벽 규칙을 수정하여 외부에서의 접근을 차단
  • 2016.10.xx: 침해서버 포맷 및 운영체제 재설치, 서비스 환경 재구성 후 서비스 복귀

침해사고가 발생한 회사는 100MBps 네트워크 대역폭으로 인터넷에 연결되어 있었다. 평상시에는 네트워크 트래픽이 1~3Mbps였으나 사고 당일에 최대 88Mbps까지 치솟았다고 한다. 내부 네트워크가 거의 사용 불가능한 DoS(서비스거부) 상태에 빠졌다고 한다.

DoS Traffic
[ 비정상적인 대용량 네트워크 트래픽 발생(9월13일) - 서비스거부 공격 ]

위의 그림은 당시의 네트워크 상황을 보여준다. 9월 13일 경에 네트워트 트래픽이 폭증한 것을 볼 수 있다. 30분 평균이 최대 87.94Mbps(그림 상단), 2시간 평균이 최대 62.98Mbps(그림 하단)인 것을 볼 수 있다. 네트워크 대역폭이 100Mbps이므로 일반 사용자들은 네트워크가 거의 차단되는 상황에 처하게 되었다고 한다. 자체적으로 네트워크 트래픽을 분석한 결과, 비정상적으로 네트워크 트래픽을 발생하는 해당 서버를 확인하였다고 한다.

침해사고 조사

9월 23일, 대용량 트래픽을 발생시킨 침해 서버는 네트워크에서 물리적으로 분리했으며 다른 사무실로 옮기면서 재부팅한 지 얼마되지 않은 상태였다. 콘솔의 터미널에서 root로 로그인하여 다음과 같이 비정상적인 프로세스를 확인하였다. 서버의 운영체제는 CentOS 리눅스였다.

ps aux

비정상적인 프로세스를 발견하지 못하였다.

netstat -anp

비정상적으로 개방된 네트워크 포트를 발견하지 못하였다.

9월 22일에 네트워크에 연결했을 때도 대용량 트래픽이 발생한 것을 탐지하였으므로, find 명령어로 지난 3일간 생성되거나 수정된 파일을 탐색하였다.

root@www:/# find / -mtime -3 | head
/
/bin
/bin/cqwvfx
/bin/cqwvfx.sh
/usr/bin
/usr/bin/tkasxjedbb
/usr/bin/dqnwnblpqp
/media
/media/.hal-mtab
/.autofsck
root@www:/# 

수 만개의 파일이 출력된다. 이중 /proc/, /sys/devices/ 등의 디렉토리에서 찾아지는 파일 목록을 제거하고 특이한 파일들을 찾아보았다. 그 중 일부는 다음과 같다.

/bin/cqwvfx
/bin/cqwvfx.sh
/usr/bin/tkasxjedbb
/usr/bin/dqnwnblpqp
/etc/rc.d/rc5.d/K74ipmi
/etc/rc.d/rc5.d/S90cqwvfx
/etc/rc.d/rc5.d/S90yjwpowcple
/etc/rc.d/rc2.d/K74ipmi
/etc/rc.d/rc2.d/S90cqwvfx
/etc/rc.d/rc2.d/S90yjwpowcple
/etc/rc.d/rc4.d/K74ipmi
/etc/rc.d/rc4.d/S90cqwvfx
/etc/rc.d/rc4.d/S90yjwpowcple
/etc/rc.d/rc1.d/K74ipmi
/etc/rc.d/rc1.d/S90cqwvfx
/etc/rc.d/rc1.d/S90yjwpowcple
/etc/rc.d/rc6.d/K74ipmi
/etc/rc.d/rc6.d/K90yjwpowcple
/etc/rc.d/rc0.d/K74ipmi
/etc/rc.d/rc0.d/K90yjwpowcple
/etc/rc.d/rc3.d/K74ipmi
/etc/rc.d/rc3.d/S90cqwvfx
/etc/rc.d/rc3.d/S90yjwpowcple
/etc/rc.d/init.d/cqwvfx
/etc/rc.d/init.d/yjwpowcple
/etc/cron.hourly/gcc.sh
/etc/cron.hourly/cqwvfx.sh

/bin/cqwvfx, /usr/bin/dqnwnblpqp 등과 같이 알기어려운 문자열을 가지는 파일들이 생성되어 있었다. 또한 부팅시 서비스 구동에 사용하는 스크립트들이 생성되어 있다(/etc/rc.d/ 디렉토리의 파일들). 그리고 crontab을 이용하여 특정 프로그램을 실행하는 스크립트들도 발견된다(/etc/cron.hourly/ 디렉토리의 파일들).

/bin/ 디렉토리에서 가장 최근에 생성된 순서로 파일들을 확인하였다.

root@www:/# ls -alsrt /bin/
합계 9212
   8 drwxr-xr-x  2 root root    4096  9월 23 09:00 .
 552 -rwxr-xr-x  1 root root  557810  9월 22 16:32 cqwvfx
   4 -rwxr-xr-x  1 root root     143  9월 22 16:32 cqwvfx.sh
   8 drwxr-xr-x 27 root root    4096  9월 22 16:32 ..
 552 -rwxr-xr-x  1 root root  557810  9월 13 01:15 xfvwqc
 616 -rwxr-xr-x  1 root root  625611  9월 13 01:02 yjwpowcple
   4 lrwxrwxrwx  1 root root       4  1월 14  2008 mailx -> mail
   4 lrwxrwxrwx  1 root root       4  1월 14  2008 csh -> tcsh
   4 lrwxrwxrwx  1 root root       8  1월 14  2008 dnsdomainname -> hostname
   4 lrwxrwxrwx  1 root root       8  1월 14  2008 domainname -> hostname
   4 lrwxrwxrwx  1 root root       2  1월 14  2008 ex -> vi
   4 lrwxrwxrwx  1 root root       3  1월 14  2008 gtar -> tar
   4 lrwxrwxrwx  1 root root       8  1월 14  2008 nisdomainname -> hostname
   4 lrwxrwxrwx  1 root root       2  1월 14  2008 rvi -> vi
   4 lrwxrwxrwx  1 root root       2  1월 14  2008 rview -> vi
   4 lrwxrwxrwx  1 root root       2  1월 14  2008 view -> vi
   4 lrwxrwxrwx  1 root root       8  1월 14  2008 ypdomainname -> hostname
   4 lrwxrwxrwx  1 root root      10  1월 14  2008 tcptraceroute -> traceroute
   4 lrwxrwxrwx  1 root root      10  1월 14  2008 traceroute6 -> traceroute
   4 lrwxrwxrwx  1 root root      10  1월 14  2008 tracert -> traceroute
   4 lrwxrwxrwx  1 root root       2  1월 14  2008 red -> ed
   4 lrwxrwxrwx  1 root root       4  1월 14  2008 awk -> gawk
   4 lrwxrwxrwx  1 root root       4  1월 14  2008 egrep -> grep
   4 lrwxrwxrwx  1 root root       4  1월 14  2008 fgrep -> grep
   4 lrwxrwxrwx  1 root root       4  1월 14  2008 sh -> bash
   8 -rwxr-xr-x  1 root root     576  3월 29  2007 redhat_lsb_init
  68 -rwxr-xr-x  3 root root   62132  3월 29  2007 gunzip
  68 -rwxr-xr-x  3 root root   62132  3월 29  2007 gzip
  68 -rwxr-xr-x  3 root root   62132  3월 29  2007 zcat
...... 이하 생략 ......
root@www:/#

/bin/ 디렉토리의 cqwvfx는 9월 22일에 생성되었으며 원본은 9월 13일에 생성된 xfvwqc이다(파일이름을 거꾸로 쓰면 cqwvfx). 9월 13일에는 yjwpowcple이라는 파일이 생성되어 있는 것도 확인할 수 있다. 두 파일을 바이러스토탈(virtustotal.com)에서 분석하였다.

VirusTotal.com cqwvfx scan result
[ 바이러스토탈.com의 cqwvfx 스캔 결과 - XOR.DDoS Trojan ]

21개의 백신 소프트웨어가 /bin/xfvwqc(/bin/cqwvfx)를 Linux용 XOR-DDoS Trojan 악성코드로 탐지하였다 (바이러스토탈의 cqwvfx 분석결과 참조).

VirusTotal.com yjwpowcple scan result
[ 바이러스토탈.com의 yjwpowcple 스캔 결과 - XOR.DDoS Trojan 변종 ]

35개의 백신 소프트웨어가 /bin/yjwpowcple(/lib/libudev.so도 동일한 파일임)를 Linux용 XOR-DDoS Trojan 악성코드의 변종으로 탐지하였다 (바이러스토탈의 yjwpowcple 분석결과 참조).

Xor DDoS
XOR DDoS는 트로이목마 계열의 리눅스용 악성코드이며 Xor DDoS Botnet 구축에 사용된다. 중국 해커들의 소행으로 의심하고 있다. C&C 서버와 좀비 서버가 대부분 아시아에 위치하고 있다. 또한 이 봇넷의 주요 공격 대상도 아시아이다. 이 봇넷은 150Gbps 이상의 네트워크 트래픽을 발생시켜서 분산서비스거부(DDoS) 공격을 실행할 수 있다고 한다. Xor 공격자들은 SSH(Secure Shell) 서비스를 무작위대입으로 공격하여 root 권한을 얻는다. root 권한을 탈취하면 Xor DDoS 악성코드를 설치한다. 이 악성코드는 ARM과 X86 시스템의 바이너리만 발견되었으며 C/C++로 개발한 것으로 추정하고 있다.
- 참고자료: https://en.wikipedia.org/wiki/Xor_DDoS

서버 접속 기록 분석

서버에 접속한 기록을 살펴보자. 가장 간단하게 확인할 수 있는 명령어는 last이다. 이 명령어는 /var/log/wtmp 파일에 저장된 계정 로그인 기록을 보여준다.

root@www:/# last
root     pts/1        :0.0             Fri Sep 23 08:34   still logged in   
root     :0                            Fri Sep 23 08:33   still logged in   
reboot   system boot  2.6.18-8.el5     Thu Sep 22 16:32          (16:21)    
root     pts/1        172.16.3.49      Tue Sep 13 17:25 - 17:42  (00:17)    
root     pts/2        172.16.1.14      Tue Sep 13 16:52 - 16:53  (00:00)    
root     pts/1        172.16.3.49      Tue Sep 13 16:52 - 17:10  (00:18)    
root     pts/1        172.16.1.14      Tue Sep 13 13:12 - 13:13  (00:00)    
root     pts/1        172.16.3.11      Sat Sep 10 16:16 - 16:17  (00:00)    
root     pts/1        172.16.1.14      Thu Sep  1 17:23 - 17:27  (00:03)    
root     pts/1        172.16.1.14      Thu Sep  1 13:42 - 14:14  (00:31)    

wtmp begins Thu Sep  1 13:42:35 2016
root@www:/#

현재 root가 콘솔(:0.0)에서 직접 접속하고 있다. 그 외에 9월에 접속한 IP주소는 모두 172.16 대역이다. 회사 내부의 사설IP 주소들이다. 특이한 사항을 발견할 수 없다.
* 참고: 인터넷을 검색해보면 /var/wtmp 파일의 접속 기록을 지우는 많은 도구들이 있음을 알 수 있다. 아마도 공격자가 자신의 접속 기록을 지웠을 것으로 추정된다.

Linux 운영체제에서 SSH로 접속한 기록은 /var/log/secure 파일에 기록된다. 최신 리눅스 운영체제에서는 /var/log/auth.log 파일이다. 이 서버의 /var/log/secure 파일들을 확인해보자.

root@www:/# ls -als /var/log/secure*
   4 -rw------- 1 jinsuk jinsuk     436  9월 23 08:33 secure
3136 -rw------- 1 jinsuk jinsuk 3210803  9월 13 17:42 secure.1
  16 -rw------- 1 jinsuk jinsuk   14737  9월 11 03:37 secure.2
   4 -rw------- 1 jinsuk jinsuk     756  9월  1 17:27 secure.3
   4 -rw------- 1 jinsuk jinsuk     160  8월 25 14:31 secure.4
root@www:/#

8월과 9월초의 secure.4, secure.3은 수백 바이트이다. 그런데 9월 11일의 로그(secure.2)가 갑자기 14.7kb 급증했다. 또한 9월 13일의 로그(secure.1)가 3.2mb로 폭증한 것을 발견할 수 있다. 주로 SSH에 대한 무작위대입공격이 있을 때 이러한 현상이 발견된다.

SSH 접속에서 계정 인증에 성공한 기록을 살펴보자. 리눅스의 grep 명령어를 사용하여 /var/log/secure* 파일들에서 Accepted password 또는 Accepted라는 문자열을 포함하는 로그만 뽑는다.

root@www:/# grep Accepted /var/log/secure*
/var/log/secure.1:Sep 12 22:54:11 www sshd[17190]: Accepted password for root from 119.249.54.88 port 40395 ssh2
/var/log/secure.1:Sep 12 22:56:57 www sshd[17196]: Accepted password for root from 103.228.130.35 port 46742 ssh2
/var/log/secure.1:Sep 13 13:12:17 www sshd[7807]: Accepted password for root from 172.16.1.14 port 46992 ssh2
/var/log/secure.1:Sep 13 16:52:48 www sshd[28235]: Accepted password for root from 172.16.3.49 port 53748 ssh2
/var/log/secure.1:Sep 13 16:52:52 www sshd[28374]: Accepted password for root from 172.16.1.14 port 47058 ssh2
/var/log/secure.1:Sep 13 17:25:04 www sshd[8432]: Accepted password for root from 172.16.3.49 port 53784 ssh2
/var/log/secure.2:Sep 10 16:16:12 www sshd[28435]: Accepted password for root from 172.16.3.11 port 2252 ssh2
/var/log/secure.3:Sep  1 13:42:35 www sshd[27023]: Accepted password for root from 172.16.1.14 port 46341 ssh2
/var/log/secure.3:Sep  1 17:23:56 www sshd[27418]: Accepted password for root from 172.16.1.14 port 46352 ssh2
root@www:/#

9월에 회사 내부의 172.16. 대역에서 root 계정으로 7번 로그인에 성공하였다. 이는 last 명령의 결과와 동일하다. (네트워크 담당자가 대용량 네트워크의 발원지가 이 서버인 것을 인지한 것이 13일 오후 1시 12분 경이라는 것을 추정해 볼 수 있다.)

그런데 외부의 공인 IP주소 2개에서 root 계정으로 인증에 성공한 것을 볼 수 있다. 각각 9월 12일 오후 10시 54분과 56분의 일이다. 119.249.54.88는 북경 근처의 중국 하북성으로 파악되며, 103.228.130.35는 홍콩 또는 중국 광동성/산동성 소재 IP 주소인 것으로 나타난다.

119.249.54.88의 마지막 접속 기록을 살펴보자.

root@www:/# grep 119.249.54.88 var/log/secure* | grep -v disconnect | grep -i -v pam | tail
var/log/secure.1:Sep 12 22:53:04 www sshd[17170]: Failed password for root from 119.249.54.88 port 42983 ssh2
var/log/secure.1:Sep 12 22:53:12 www sshd[17172]: Failed password for root from 119.249.54.88 port 37672 ssh2
var/log/secure.1:Sep 12 22:53:19 www sshd[17174]: Failed password for root from 119.249.54.88 port 37344 ssh2
var/log/secure.1:Sep 12 22:53:27 www sshd[17176]: Failed password for root from 119.249.54.88 port 35348 ssh2
var/log/secure.1:Sep 12 22:53:34 www sshd[17178]: Failed password for root from 119.249.54.88 port 36584 ssh2
var/log/secure.1:Sep 12 22:53:42 www sshd[17180]: Failed password for root from 119.249.54.88 port 35078 ssh2
var/log/secure.1:Sep 12 22:53:50 www sshd[17184]: Failed password for root from 119.249.54.88 port 38719 ssh2
var/log/secure.1:Sep 12 22:53:57 www sshd[17186]: Failed password for root from 119.249.54.88 port 37444 ssh2
var/log/secure.1:Sep 12 22:54:05 www sshd[17188]: Failed password for root from 119.249.54.88 port 41585 ssh2
var/log/secure.1:Sep 12 22:54:11 www sshd[17190]: Accepted password for root from 119.249.54.88 port 40395 ssh2
root@www:/#

위에서 보듯이 119.249.54.88는 6~8초 간격으로 일정하게 로그인을 시도하는 데 지속적으로 실패한다. 그리고 9월 12일 22시 54분 11초에 root로 로그인하는 것을 볼 수 있다.

103.228.130.35의 마지막 접속 기록을 살펴보자.

root@www:/# grep 103.228.130.35 var/log/secure*
var/log/secure.1:Sep 12 22:56:57 www sshd[17196]: Accepted password for root from 103.228.130.35 port 46742 ssh2
var/log/secure.1:Sep 12 23:02:27 www sshd[17196]: Received disconnect from 103.228.130.35: 11: 
root@www:/#

103.228.130.35는 단번에 로그인에 성공였으며 약 10분 정도 서버에 접속한 것을 볼 수 있다. 119.249.54.88와 같은 해커그룹이거나 VPN 또는 토르 네트워크를 사용한 것으로 추정된다.

이제 로그인에 실패한 로그를 살펴보자. 이를 통해 무작위 대입 공격의 기록을 확인할 수 있다.

root@www:/# grep Failed var/log/secure* | head
var/log/secure.1:Sep 11 05:32:24 www sshd[4365]: Failed password for root from 119.249.54.77 port 47271 ssh2
var/log/secure.1:Sep 11 05:32:36 www sshd[4369]: Failed password for root from 119.249.54.77 port 38798 ssh2
var/log/secure.1:Sep 11 05:32:43 www sshd[4371]: Failed password for root from 119.249.54.77 port 37426 ssh2
var/log/secure.1:Sep 11 05:32:51 www sshd[4373]: Failed password for root from 119.249.54.77 port 41127 ssh2
var/log/secure.1:Sep 11 05:42:13 www sshd[4389]: Failed password for root from 221.194.47.249 port 36965 ssh2
var/log/secure.1:Sep 11 05:42:20 www sshd[4391]: Failed password for root from 221.194.47.249 port 39025 ssh2
var/log/secure.1:Sep 11 05:42:27 www sshd[4393]: Failed password for root from 221.194.47.249 port 36670 ssh2
var/log/secure.1:Sep 11 05:42:34 www sshd[4397]: Failed password for root from 221.194.47.249 port 40637 ssh2
var/log/secure.1:Sep 11 05:42:42 www sshd[4399]: Failed password for root from 221.194.47.249 port 40041 ssh2
var/log/secure.1:Sep 11 05:42:49 www sshd[4401]: Failed password for root from 221.194.47.249 port 36864 ssh2
root@www:/#

9월 11일 오전 05:32:24에 무작위 대입 공격이 시작되었다. 동일 IP주소에서는 거의 7초 간격으로 균일하게 SSH 로그인을 시도하고 있다.

로그인에 실패한 횟수를 세어보자.

root@www:/# grep Failed var/log/secure* | wc -l
10217
root@www:/#

중국 공격자들은 1만여 번의 무작위대입 공격을 시도하였다. 무작위 대입 공격이 시작된 시간은 Sep 11 05:32:24이었다. 최초로 로그인에 성공한 시간이 Sep 12 22:54:11이었다. 이로부터 중국 해커들이 39시간 22분 동안 1만 번의 로그인 시도를 하여 root 권한 탈취에 성공한 것으로 결론을 내릴 수 있다.

로그인 시도 1만 번이면 매우 적은 시도이다. 그럼에도 불구하고 root권한을 탈취당한 것은 비밀번호 자체가 매우 취약했다는 것을 의미한다. 실제로 이 서버의 root 비번은 보안업계에서 가끔씩 사용되는 영어 단어였다. root 계정의 비밀번호가 복잡했다면 - 지속적으로 SSH brute-force 공격을 당할 가능성은 있겠지만 - 서버가 장악되는 사태는 막을 수 있었을 것이다.

/var/log/secure*에서 무작위 대입 공격에 사용된 IP 주소들을 뽑아보자. IP주소를 가장 많이 공격한 순서대로 나열하면 다음과 같다.

root@www:/# grep authentication var/log/secure* | cut -d'=' -f7 | cut -d' ' -f1 | sort | uniq -c | sort -r
   1302 ma67.snapdealmail.in
   1207 221.194.47.208
    974 221.194.47.249
    801 221.194.47.224
    768 119.249.54.66
    716 119.249.54.68
    625 119.249.54.77
    615 221.194.47.229
    599 119.249.54.88
    541 119.249.54.80
    488 119.249.54.86
    382 119.249.54.83
    191 119.249.54.75
     28 113.190.209.11
     26 ns330698.ip-37-187-120.eu
     19 221.210.200.245
     19 111.207.111.7
     19 103.244.59.205
      5 u19200789.onlinehome-server.com
      5 61.178.42.242
      4 37.48.77.131
      4 193.254.226.226
      3 103.243.107.193
      3 103.207.36.59
      2 gvo23669.gvodatacenter.com
      2 37.187.120.22
      2 210.204.166.9
      2 172.16.1.14
      1 catv-213-222-180-201.catv.broadband.hu
      1 77.75.133.212
      1 71.119.113.80
      1 5-90-184-177.redewsp.com.br
      1 37.255.128.78
      1 210.195.22.95.dynamic.jazztel.es
      1 210.105.122.222
      1 202.19.222.228
      1 183179188194.ctinets.com
      1 175.202.82.235
      1 172.16.3.49
      1 16-88-184-177.redewsp.com.br
      1 1.212.32.221
      1 
root@www:/#

SSH 무작위 대입 공격에 제법 많은 수의 IP 주소가 동원된 것을 볼 수 있다. 주요 IP주소들은 대부분 중국에 위치하고 있었다.

마지막으로 공격자들이 설치하고 나가는 스크립트 파일을 살펴보자.

root@www:/# cat etc/cron.hourly/gcc.sh 
#!/bin/sh
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/X11R6/bin
for i in `cat /proc/net/dev|grep :|awk -F: {'print $1'}`; do ifconfig $i up& done
cp /lib/libudev.so /lib/libudev.so.6
/lib/libudev.so.6
root@www:/#

위의 스크립트는 /etc/cron.hourly/gcc.sh 파일의 내용이다. Crontab을 이용하여 매 시간 실행된다. 먼저 /proc/net/dev에서 네트워크 장치를 모두 찾아서 활성화시킨다(ifconfig). 그리고 /lib/libudev.so 파일을 /lib/libudev.so.6으로 복사한 후에 실행하도록 한다.

이 외에도 /etc/rc.d/rc5.d/S90cqwvfx/etc/rc.d/rc5.d/S90yjwpowcple 등의 파일은 서버가 재부팅되더라도 악성코드를 다시 실행하도록 한다.

중국 해커들은 다양한 경로에 악성코드를 숨겨두고 있었다. 이들을 하나씩 찾아서 지우면 서버를 복구할 수 있을 것이다. 하지만 모든 은닉된 악성코드를 제거했다는 확신이 없는 경우에는 운영체제를 재설치하는 것이 바람직하다.

마무리

웹서버를 비롯한 많은 서버들이 ssh 무작위대입공격을 받고 있다. 외부로 22번 포트가 열려 있다면 항상 주의하여야 한다. 가능한 root 계정의 비밀번호는 추정하기 어렵게 설정해야 한다.

이 사례에서 - 방화벽 교체 과정에서 일부 실수가 있었다고 하더라도 - root 암호가 강력했다면 이러한 사고를 방지할 수 있었을 것이다. 취약한 비밀번호 하나 때문에 담당자들은 사고 원인을 분석하기 위해서 많은 시간을 소비해야 했고 결국 서버 운영체제를 재설치해야 하는 부담까지 안게 되었다.

이 침해사고 조사에서 사용한 일부 자료는 www-incident-ssh-brute-force.tgz에 서 확인할 수 있다. 압축을 풀어서 여기서 사용한 조사 방법을 적용해 볼 수 있다. 다만, 리눅스용 악성코드가 포함되어 있으므로 실행하지 않도록 주의하여야 한다.

[처음 작성한 날: 2017.01.12]    [마지막으로 고친 날: 2017.01.13] 


< 이전 글 : WH-ImgShell-01 라이브 ISO: 이미지에 덧붙인 웹쉘 취약점 웹해킹훈련장 (2017.01.13)

> 다음 글 : WH-IllInst-WordPress 워드프레스 웹해킹훈련장 소개 (2017.01.10)


크리에이티브 커먼즈 라이선스 이 저작물은 크리에이티브 커먼즈 저작자표시 4.0 국제 라이선스에 따라 이용할 수 있습니다.
잘못된 내용, 오탈자 및 기타 문의사항은 j1n5uk{at}daum.net으로 연락주시기 바랍니다.
문서의 시작으로 컴퓨터 깨알지식 웹핵 누리집 대문

.. -- -- | - .. .... | ... / .. .../ ... {] . .. .. .. ..| ...... .../ .../ .. ...... ... ... ] .. [ .../ ..../ ......./ .. ./// ../ ... .. ... .. -- -- | - .. .... | ... / .. .../ ... {] . .. .. .. ..| ...... .../ .../ .. ./// ../ ... .. ... ...| ..../ ./ ... / ..| ....| ........ / ... / .... ...... ... ... ] .. [ .../ ..../ ......./ .....| ..../ ./ ... / ..| ....| ........ / ... / .... ...| ..../ ./ ... / ..| ....| ........ / ... / .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .