<서론>
- 서론이 좀 길으니 급하면 아래 본론부터 읽자 -
쿠팡 개인정보 유출의 가장 큰 피해는 개인정보 유출이다.
그리고 이 유출 사건의 원인으로 가장 중요한 핵심은 직원들에게 제공된 인증키(서명키), 또는 토큰이 문제다.
이유는 인증키의 수명이 길게 설정하고 발급받기 때문이다.
아마 개발자들이라면 서버를 직접 접속하는 pem (ppk) 키 들도 발급 받아 공유되어 개발하고 있을 것이다.
퇴사자 또한 이 키를 가지고 있을 수도 있고 이 키는 서버에서 교체하기 전까지는 유효할 것이다.
접속 토큰들 또한 비슷할 것이다. 토큰을 매번 발급 받기 귀찮으니 토큰 만료일 자체를 9999와 같은 말도 안되는 긴 시간으로 설정해 두기 때문에 수명이 길었을 것이다.
물론 퇴사자들이 접근해서 무슨 짓을 하더라도 로그나 추적 끝에 찾아낼 순 있다.
하지만 털리고 난 뒤 조치해봐야 소용이 없다.
퇴사자가 전에 다니던 회사에 악감정을 갖고 있지 않는 한 대부분의 퇴사자들은 이런 보안이 발급된 키들은 스스로 폐기하거나 이용하지 않는다. (보안 서약서 및 기술에 대한 법에 위배되기 때문이다. 그리고 다 잡힌다.)
그런데 가끔 이 키가 외부로 유출되거나 탈취 당하면 서버에 쉽게 접근할 수 있다.
우리 또한 서버들 중에 가볍게 개발자들이 개발용으로 사용할 수 있는 테스트용 서버가 있는데 몇일전 여기에 외부에서 접근한 흔적을 찾아냈다.
물론 이 서버는 실제 플랫폼하고 연관성도 없고 DB도 없고 개인정보도 없는 그냥 날 것의 장난감 같은 서버이다. (뭔가 마루타처럼 쓰고 싶은 그런 실험용? 작업을 하기 위한 용도로 회사들마다 종종 가지고 있다.)
우리는 이걸 토이 서버라 쓰겠다.
이제 이 토이 서버에서 문제점을 발견하고 해결하고 방어하는 과정의 기록을 적으려고 한다.
물론, 가장 안전한 설정은 지금 회사에서 운영중인 서버들에 적용된 여러가지 보안 설정과 배포 설정대로 하면 뚫릴 일은 없지만 그 설정들을 다 쓰기엔 너무 내용이 많다. 그리고 비용도 나가기 때문에 오히려 중소기업에서 작은 플랫폼이나 어플리케이션을 운영중이라면 부담이 될 수 있다.
우선 이 내용은 아주 기본적인 웹서버를 운영하는 작업 기업들의 서버에 종종 비슷하게 해킹이 들어오고 피해가 발생하는 내용들이기에 이 조차 안해 놓으면 우리 토이 서버가 뚫린 것처럼 쉽게 해커에게 공격의 대상이 되고 이용된다.
물론 악감정이 있는 퇴사자에게도 이용이 될 수 있다.
<본론>
어느날 잘 사용하지 않는 서버(토이 서버)가 웹으로 접속이 안된다는 직원의 제보를 받았다.
서비스에 별 중요한 내용이 없는 그냥 정적인 페이지들만 있는 AWS EC2 서버다.
ssh로 접속해보니 웹서버를 위해 구동시켰던 pm2 나 node 들이 설치에서 사라졌다.
뭔가 서버에 이상이 있음을 감지하게 된다.
1. CPU 부터 상황 체크
먼저 AWS에서 이 서버의 CPU 내역을 확인해 봤다.
2시간전부터 CPU 사용률이 90%가 넘었다.
이 상태에서 유추된건 '아! 서버에 코인 체굴 심었다.' 부터 생각났다.
왜냐하면 비슷한 사례로 이커머스 플랫폼 회사에서 팀빌딩하고 플랫폼 만들어서 런칭하고 사람들이 몰렸을 때 비슷한 사례가 있었기 때문이다.
서버에서 top 를 실행해 봤다.
top - 15:07:33 up 31 min, 1 user, load average: 1.06, 1.06, 0.96
Tasks: 108 total, 1 running, 107 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.0 us, 0.3 sy, 97.7 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 957.3 total, 65.1 free, 500.2 used, 391.9 buff/cache
MiB Swap: 4096.0 total, 4070.0 free, 26.0 used. 298.7 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
405 root 30 10 104876 8224 32 S 97.7 0.8 30:33.17 dsminer
724 ubuntu 20 0 22.0g 160268 47360 S 2.0 16.3 0:07.52 next-server (v1
594 ubuntu 20 0 670284 66544 17152 S 0.3 6.8 0:03.09 node /home/ubun
1 root 20 0 166268 11648 8320 S 0.0 1.2 0:05.64 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:00.00 pool_workqueue_release
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/R-rcu_g
5 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/R-rcu_p
6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/R-slub_
어이구야~ dsminer 라는 프로세스가 cpu를 97% 이상을 사용하고 있었다.
저 프로세스를 바로 죽이기 보다는 이번이 기회라고 나는 이미지(AMI) 를 떠놨다. 지금 서버 상태를 그대로 백업해 두었다는 것이다. 해킹 시도 방법과 어떤 해킹 코드를 어떻게 구동시켰는 지 분석해 보는 것도 재미있을 것 같아서다.
하지만, 실제 서비스를 운영 중인 기업들은 꼭 저 프로세스를 죽이고 방어부터 하는 것을 추천한다.
나의 경우는 있으나 마나 한 서버였기 때문에 토이 서버라 리스크가 있는 것도 아니고 해커의 이런 시도를 미리 감지해서 사전에 분석하고 공부해 두는 것이 좋을 것 같기 때문에 여유있게 프로세스를 죽이지 않고 모니터링 한 것 뿐이다.
실제 이렇게 과다한 프로세스가 돌면 거의 코인 채굴 악성코드이다. 우선 이 프로세스부터 죽이자.
위 프로세스 목록의 dsminer 를 보면 PID가 405 이다.
바로 죽이지 말고 해당 프로세스가 돌고 있는 파일과 위치도 확인해 보자.
ps -ef | grep dsminer | grep -v grep
이렇게 실행하면 아래처럼 결과가 나온다.
root 405 1 98 14:36 ? 00:30:56 /home/ubuntu/.dspool/dsminer --config=/home/ubuntu/.dspool/config.json
PID 405 확인했고 /home/ubuntu/.dspool/dsminer 경로에 있는 파일이 돌고 있다.
아래처럼 프로세스를 죽이고 해당 파일을 삭제한다.
sudo kill 405 sudo rm /home/ubuntu/.dspool/dsminer
이렇게 하면 일단 프로세스는 죽었다.
파일도 지웠기 때문에 주기적으로 스케쥴을 돌리는 무언가가 해당 파일을 다시 돌릴 수 없겠지만 실제 서비스를 돌리던 코드들을 뒤져봐야 좀 더 정확히 아는 것이다.
여기까지 했다고 해결된 것이 아니다.
pem(ppk) 인증키가 해커에게 유출되었거나 퇴사자가 가지고 장난 칠 수 있기 때문에 이 키를 바꾸는게 안전하다.
하지만 이 교체하는 건 오래 걸리니까.
다음 단계부터 하자!
그리고 프로세스 명칭이 dsminer 아닐 수 있다. 해커들이 프로세스 명칭을 다르게도 만들 수 있으니 cpu 점유가 높다? 싶으면 의심하고 해당 파일을 역추적해야 한다. 실행 파일들의 설정 파일들을 보면 결국엔 채굴 코인을 넣는 지갑 주소를 찾을 수 있다.(이건 좀 후반부에 쓰겠다. 내용이 길다.)
2. SSH 인바운드 제한
인증키로 서버에 ssh 로 들어왔다는 가정하에 우선 ssh로 들어오는 골목을 제한한다.
보안그룹을 설정하면 되는데 인바운드 포트나 트래픽을 설정하면 된다.
다른 운영 서버들의 경우 VPC 안에서만 서로 통신하고 VPN과 인바운드 정책을 통해 외부에서 들어올 수 없지만 토이 서버의 경우 그런 설정들을 해놓지 않았다.
이렇게 IT 전문업체가 아닌 이상 서버에 하나하나 보안 설정을 안하는 것이기 때문에 쉽게 해커들이 접근할 수 있던 것이다.
서버의 네트워크 보안 설정에서 인바운드 규칙 편집에 가면 이렇게 SSH 유형에 0.0.0.0/0 으로 되어 있다면 그냥 모든 사람에게 어디서든 SSH를 접속할 수 있게 열어주는 것이다.
이 것부터 막자.
SSH 를 접속하는 사람 (거의 개발자나 유관 엔지니어) 들이 작업하는 곳의 IP만 허용해 주면 된다.
아마 다들 공유기를 쓸테니 정확한 IP를 모를 수도 있기 때문에 네이버에서 '내 아이피'라고 써주면 알려준다.
이렇게 아이피를 알게되면 아래처럼 이 아이피만 추가한다.
내아이피/32 라고 써주고 설명에 보안 문서(우리는 컨플루언스에 정리한다.) 안에 허용한 아이피와 누구의 것인지 날짜까지 적어서 현황을 꼭 공유한다.
이유는 AWS 계정에 들어와서 이 부분까지 수정하는 해커들이 있다. AWS 계정 자체를 탈취 당하는 경우다.
우리는 마스터부터 직원들까지 AWS 계정은 2차인증 MFA가 설정되어 있고 비밀번호와 토큰을 주기적으로 변경하기 때문에 AWS 계정이 탈취되지는 않는다.
AWS를 사용하는 기업이라면 꼭 2차인증 설정해 둬라!
이제 대망의 인증키 변경이다. 이건 좀 번거롭다.
그렇기 때문에 개발자들이 잘 안바꾸려고 하는 것이다.
그래도 분기별로 바꾸자.
스크립트 만들어두면 편하다.
아무튼 이건 좀 정리해서 다시 업데이트 하겠다.