CPU 과다 점유 이슈

확인 및 프로세스 킬

회사 서비스 500 에러 이슈에 대한 확인 요청이 왔습니다.

 

 

$top

postgres 유저이름으로 돌아가는 프로세스 두 개(kdevtmpfsi , kswapd0)가 cpu 400% 가까이 올라가는것을 확인했습니다.

Cpu 가동율도 99퍼센트, load average 도 16 까지 올라가 있습니다.

(load everage : n , n, n : 최근 1분, 5분, 15분 동안 CPU 자원을 할당받기를 기다리는 프로세스의 평균적 수를 의미합니다.)

 

kdevtmpfsi 는 찾아보니 malware 라고 합니다 ( kinsing 이라는 놈도 찾아야 한다고 합니다)

 

kinsing 도 postgres 유저로 프로세스중입니다.

 

두개 다 /tmp 위치에 있네요

 

kinsing 및 kdevtmpfsi 프로세스 킬

 

 

두 프로세스를 종료한 후 다시 확인해 보니 load average가 줄어들고 있지만 kswapd0(리눅스의 가상메모리를 담당하는 프로세스로, 메모리가 부족해서 SWAP 메모리를 사용할때 생성되는 프로세스)은 800% 로 올라가 있습니다

( 메모리를 많이 먹는 프로세스를 킬하면 된다고 하였지만, 저는 이미 두 프로세스를 종료했기 때문에 다른 원인이 있을수도 있다고 생각했습니다)

 

kswapd0 킬

 

로드평균 및 cpu 점유율 정상화 확인

 

 

의심 디렉토리/파일 삭제

/tmp 디렉토리 안의 kinsing, kdevtmpfsi 를 삭제해 주었습니다

그리고 /var/tmp 에도 있을수 있다고 합니다.

 

$sudo rm -rf /tmp/kinsing
$sudo rm -rf /tmp/kdevtmpfsi
$sudo rm -rf /var/tmp/kinsing

 

postgresql 재시작

$service postgresql restart

 

재시작 후 서비스 정상 확인

 

 

에러 재발생/ malware 확인

잘 되는가 싶더니 일정 시간 이후 다시 서버 500 에러가 났는데,

 

postgresql 로그를 보니 “/tmp/kinsing exists” kinsing이 존재한다고 되어있고 db 를 shut down 한 것을 확인하였습니다.

/tmp로 가보니 삭제한 kinsing 이 다시 생성되어있었습니다.

아마 다른 스크립트가 kinsing으로 어떤 행동을 하도록 실행중인것으로 보입니다

kinsing이 다시 생겨 있습니다

 

 

서치해 보니 이 malware 는 /tmp/.x25-unix 또는 /dev/shm 의 위치에 설치된다고 합니다.

저희 서버의 경우 /dev/shm 디렉토리 안에 디렉토리가 있었고

 

.X09 로 들어가 보니 문제의 근원인 dota3.tar.gz 파일 및 .rsync 디렉토리를 발견하였습니다

 

dota3.tar.gz 는 아래와 같은 컴포넌트들을 포함한 아키텍처구조로 되어있습니다

 

멀웨어 구조

 

1.영속/지속화

init 및 init2 스크립트는 다른 잠재 감염요소를 정리하고, 사용자 홈 폴더의 .configrc 디렉토리에 자신을 복사하고 cronjobs 를 추가 한다고 합니다. 이 단계가 완료되면 Crypto Miner, IRC bot, SSH Brute-forcer 가 트리거 한다고 합니다.

2. Cryptominer

a 폴더에 있는 Cryptominer 는 XMRig 라는 모네로 채굴기의 한 버전이라고 합니다.

CPU 정보를 확인하여 다양한 최적화를 수행하고 CPU 아키텍처가 64비트일 경우 kswapd0 이라는 채굴 바이너리를 실행합니다.

 

a 디렉토리

 

a 스크립트

 

XMRig 채굴기는 일반적으로 서버 세부 정보를 저장하는 구성파일을 가지고 있다고 합니다. kswapd0 도 바이너리 안에 config.json 형태로 구성파일을 내장하고 있다고 합니다.

역어셈블러(disassembler)로 바이너리를 분석하여 채굴 풀 ( mining pool ) 세부 정보와 자격 증명을 추출할 수 있다고 합니다. (Ghidra -기드라 를 사용했다고 하여 똑같이 사용하였습니다)

 

Ghidra 설치 및 사용방법

gui에서 돌아간다고 하는데 서버는 cli 이기 때문에, 로컬에 설치를 한후 kswapd0 바이너리를 로컬로 복사해서 실행해 주었습니다.

 

kswapd0 바이너리를 drag and drop 하여 진행

 

분석 후 Search > For Strings 를 통해 검색 할 수 있습니다

 

monero로 검색해 보았습니다

 

해당부분의 디컴파일 된 내용이 보입니다

 

json 뷰어를 통해 pools 항목을 확인해 보면

45.9.148.118:80 및

45.9.148.118:443

user : 483fmPjXwX75xmkaJ3dm4vVGWZLHn3GDuKycHypVLr9SgiT6oaZgVh26iZRpwKEkTZCAmUS8tykuwUorM3zGtWxPBFqwuxS

password : x

로 접속하고 있었고, 이런식으로 8개가 더 있었습니다.

이 구성 요소는 .ssh/authorized_keys 에 ssh 키를 추가하여 SSH 백도어를 추가 한다고 하며, 이것을 통해 몰래 들어올 수 있다고 합니다.

저희 서버에도 확인 해 보니 추가가 되어 있었습니다. ㅠㅠ

 

 

3. IRC Bot

b 디렉토리에는 IRC Bot 이 있으며

IRC Bot 이라고 알려진 ShellBot 이라고 합니다. Perl 언어로 작성되어 b 폴더에 압축되고 인코딩된 포맷으로 b에 들어있다고 합니다.

이 구성 요소가 실행되면 파일을 삭제하고 이전 감염 가능성이 있는 실행중인 프로세스를 제거하는 정리 프로세스를 다시 수행합니다.

그런 다음 동일한 SSH 키를 다시 추가하여 동일한 SSH 백도어를 설치하고 Perl로 작성된 페이로드를 언팩/디코딩하여 실행하는 run이라는 bash 스크립트를 트리거합니다.

tsm bash 스크립트는 CPU 아키텍처에 따라 tsm32 또는 tsm64 ELF 이진 파일을 실행하는 래퍼입니다.

 

4. SSH Brute - force

c 디렉토리에는 SSH Brute - force 가 있으며

얘네들은 다시 이전 감염을 정리하고 CPU 아키텍처 기반으로 스레드 수를 구성하고 두 단계로 구성된 Brute-force binary를 실행한다고 합니다

 

 

조치

흔적 체크

최근 서버 접속 기록 체크를 해봤을때

$last -n 1000

외부 침입 흔적은 없었으며. 위에서 살펴본 컴포넌트들이 훨씬 더 예전에 설치되어 지속적으로 마이닝을 시도 한 것으로 보입니다.

 

컴포넌트들을 구동하는 스크립트가 숨어있다고 하여 찾아보았습니다.

저희 서버는 postgres 유저로 감염이 됐기 때문에 잡 스케줄러인 crontab 을 postgres 유저로 확인해 보았고 아래와 같이 스크립트가 실행중임을 확인하였습니다.

 

sudo -i
crontab -u postgres -e

 

 

pg.sh 는 malware 스크립트 다운로드 파일 이라고 합니다.

curl IP 185.122.204.197 주소를 확인해 보니 러시아주소로 뜨고있습니다.

 

 

Crontab 삭제

malware 스크립트를 다운받도록 설정된 계정의 crontab(크론 유틸리티가 작업을 설정하는 파일)을 삭제하였습니다.

crontab list 확인

$sudo crontab -l -u postgres

crontab 삭제

$sudo crontab -r -u postgres

삭제 후 확인

 

malware 삭제

$sudo rm -rf /tmp/kinsing
$sudo rm -rf /tmp/kdevtmpfsi
$sudo rm -rf /var/tmp/kinsing
$sudo rm -rf /dev/shm/.X09

 

추가 고려 사항

PostgreSQL 운영 포트 (5432)를 운영에 반드시 필요한 특정 IP 및 대역에서만 접근할 수 있도록 방화벽의 inbound 설정을 변경하는것을 고려하라고 합니다.

"inbound"/"outbound" 방화벽 정책을 좀 더 철저하게 설정해 놓으면, 위와 같은 문제들을 미연에 방지할 수 있다고 합니다.

외에도 20,21,22,3389번 같은 다른 포트 들도 제한을 걸어 특정 IP 에서만 접근 할 수 있도록 하여야 한다고 합니다.

이 부분은 팀 내부 회의 후 적용을 해야 할 것 같습니다

정리

어떤 이유로 침투했는지 알 수 없어 답답하였고 서버보안에 대한 중요성, 필요성을 더 느꼈습니다.

아직 inbound, outbound 방화벽 정책은 설정하지 않아서 며칠 더 모니터링을 해야 겠습니다.

 

---

reference

https://hbesthee.tistory.com/1731

http://aodis.egloos.com/5964233

https://brycematheson.io/how-to-permanently-kill-and-remove-kdevtmpfsi-kinsing/

https://jwchoi1224.tistory.com/269

https://www.oguzhantopgul.com/2020/06/outlaw-botnet-xmrig-miner-and-shellbot.html

https://www.makeuseof.com/how-to-install-ghidra-linux/

https://sysdig.com/blog/zoom-into-kinsing-kdevtmpfsi/

https://velog.io/@qlgks1/리눅스-작업-예약-스케쥴러-cron-crond-crontab