개인 서버 채굴 해킹 사례 및 분석

올해 2022년 6월 5일 서버의 GPU가 100% 가동되는 상황 목격했습니다. nvidia-smi 명령어로 어떤 프로세스가 돌아가고 있는 지 확인 해 보왔습니다.

참고

[Linux] GPU 채굴 방지

서버 침해사고 사례: root 계정 SSH 무작위대입공격과 채굴 스크립트

 

1. GPU를 사용하고 있는 프로세스 확인

위에서 보면 PID(프로세스 ID)가 9268 이고 process 이름은 python3.7인 프로세스가 돌아 가고 있습니다. 저는 다음 명령어로 프로세스 종류를 좀 더 확인 해보았습니다. 

ps [프로세스 ID]
# ps 9268

원래는 9268를 입력해야 되는 데, 캡쳐를 못해서 다른거 찍어서 올렸습니다.  ps 명령어로 출력한 프로세스 내용의 위와 같습니다. 확인 결과 해당 프로그램에 실행 인수 -a 에는 ethash 그리고 -o에는 ethproxy+ssl://xxx....... 입력되어 실행 되고 있습니다. ethash를 인터넷에 확인해 본 결과 이더리움의 작업 증명 알고리즘 이라고 나와 있네요. 저는 이때 부터 이거 설마 채굴 해킹 당한건가 느끼고 인터넷에서 계속 찾아 보니깐 실제로 저 말고도 GPU가 달린 컴퓨터에서 악성 채굴 웜이 발견된다고 나와 있네요.(저 당시에 저는 멘붕 왔답니다....)

리눅스 OS 노리는 모네로 채굴 악성코드 발견 | 블록미디어

 

1.2 로그인 성공 및 실패 로그 확인

last # 이전에 서버에 로그인한 이력을 출력 해주는 명령어 

lastb # 이전에 서버에 로그인 실패한 이력을 출력 해주는 명령어

• 로그인 로그(last)를 확인 해 본 결과 내부망 또는 한국 통신망 빼고는 외부 접속은 보이지 않았습니다. 
• 로그인 실패 로그(lastb)를 확인 해 본 결과 출력 결과 중국 및 미국 ip 접속 시도 확인 되었습니다. 
• 사실 last, lastb 의 명령어는 각각 /var/log/wtmp /var/log/btmp 의 파일 내용을 출력 하는 명령어 이기 때문에 해커가 해당 파일을 조작했다면 해커가 서버 접속했다는 기록은 없앴을 수 있습니다.

 

2. 실행중인 악성 프로세스 pid로 현재 네트워크 Listen 중인지 확인

netstat -antlp | grep 9268

확인 결과 해당 프로세스가 외부로 부터 Listen 하고 있지 않고 있습니다. 외부로 부터 수신을 받는 프로그램이 아니면 대체 무슨 프로그램 인지 이해가 안됬습니다. 저는 일단 악성 프로세스가 어느 디렉토리에 위치하는 지 확인했습니다. 

 

3. 실행중인 악성 프로세스 pid로 실행파일 및 현재 디렉토리 확인

실행 파일이 존재하는 tmp 디렉토리로 이동 해 봤습니다. 

cd /tmp
ls -al

tmp 디렉토리 확인 해봤는데, python3.7 이름의 파일은 존재 하지 않았습니다(진짜 뭐지?...). 저는 결국 해당 프로세스의 최상위 프로세스가 누구인지 확인해 보았습니다.

 

4. 실행중인 프로세스의 pid를 통해 ppid 확인하기 (실행중인 프로세스 계층 보기)

ps -ef | grep [프로세스 id]

파란색 박스는 프로세스 바로 위에 있는 부모 프로세스를 의미 하며, 이런식 으로 다음 부모 프로세스를 찾아 가면서 최종으로 최상위 부모 프로세스를 찾으려고 했습니다. 최상위 부모 프로세스를 확인 하면서 동시에 문제의 구간을 찾았습니다. 위에 빨간 색 박스는 악성 프로세스가 주피터 노트북에서 실행된다는 것을 나타냅니다. 저는 주피터 노트북을 docker를 통해서 실행하고 있어서 호스트 영역에서 프로세스가 발견 되지 않은 거 같습니다. 그러면 일단 주피터 노트북에 접속해서 악성 프로세스가 실행 중인지 확인 해보겠습니다. 

 

5. jupyter notebook 접속 및 실행중인 터미널 확인

주피터 노트북 터미널 확인해 보니 제가 실행 하지 않은 터미널이 생성되고 실행 중 이였습니다. 터미널을 확인 해 보겠습니다. 

 

6. 실행중인 터미널 내용 확인

위에는 해커가 저의 터미널을 탈취해 터미널에 입력한 명령어 입니다.  여기서 nohup은 해커가 로그아웃을 해 터미널을 빠져나가도 실행중인 프로그램이 종료되지 않고 계속 수행될 수 있게 하는 명령어 입니다. 또한 nohup 명령어는 nohup.out파일을 생성해 프로세시 실행시 출력되는 내용을 이 파일에 기록하게 됩니다. 

그러면 주피터 노트북이 실행 중인 docker 컨테이너에 접속해 보겠습니다. 

 

7. tensorflow 서버 docker 컨테이너  접속

docker exec -it [컨테이너 이름] bash

 

8. 실행중인 악성 프로세스 현재 디렉토리로 이동

cd /tmp
ls -al

확인 결과 위와 같이 악성 프로그램이 발견 되었습니다. 저는 악성 해커의 IP를 확인해서 어느 나라 사람인지 확인 해 보았습니다. 

 

 

9 로그인 파일 확인 및 기록 확인

wtmp : 성공한 로그인/로그아웃 정보를 담고 있는 로그파일, /var/log/wtmp에 위치

btmp : 실패한 로그인 정보를 담고 있는 로그파일, /var/log/btmp

cat 명령어로 기록을 확인해 보았는데, 기록 자체가 사라져 있었습니다. 저는 마지막으로 HOST 영역에서 도커 컨테이너 로그를 확인 해 보았습니다. 

 

10. Host 에서 주피터 노트북 서버 컨테이너 로그 확인

docker logs [컨테이너 이름]

확인 결과 GPU가 멋대로 돌아간 시간 때 중국 ip에서 접속 된 것이 확인 되었습니다. 

 

문제 확인

주피터 노트북 서버를 비밀번호 생성 없이 운영 한 것때문에 이번 서버 해킹을 당하게 되었습니다. 

느낀 점 

• 자신의 컴퓨터 프로세스를 외부에 Listen 해 놓는 다면 사용할 포트만 풀어 놓고 나머지는 막아 두어야 된다는 것을 알게 되었습니다. 
• 쉘을 장악할 수 있는 포트는 반드시 비밀번호를 설정해야 된다는 것을 알게 되었습니다. 
• docker 컨테이너를 통해 주피터 노트북 서버를 구현 했기 때문에, 호스트 영역을 해킹 당하지 않았습니다. 이번 경험을 통해 docker가 보안 면에서 좋다는 것을 느꼈습니다. 
• 중국에 악성 해커들이 참 많은 거 같습니다. (나쁜 놈들 ㅠㅠ)

이후 이루어진 작업 

공유기에 중국 ip 차단, 방화벽 설정, 비밀번호 변경, 주피터 노트북 암호화, 포트 재구성, Fail2Ban 설정, 서버 도메인 이름 변경이 이루어 졌습니다.