TechTalk - 서버를 해킹 당했습니다
•Download as PPTX, PDF•
0 likes•157 views
사내 Technical Talk 시간 때 발표한 내용. 보안그룹 설정을 Any로 둔채로 세팅 하다 공격 당한 사례를 설명합니다. 2022. 04.
TechTalk - 서버를 해킹 당했습니다
- 1. 서버를 해킹 당했습니다. 선행개발Lab 박대성 1
- 2. 요약 • 22년 4월 25일 월요일 오전. • AWS 버지니아 리전에 신규로 구축 중인 Spark Cluster Worker의 Root 권한이 탈취되어 채굴 머신으로 이용됨. 2
- 3. 장애 회고 • 어떤 일이 있었는지 • 어떻게 파악 했는지 • 어떻게 파훼 했는지 • 어떻게 보완 했는지 경험과 노하우를 공유 3 우리 함께 개발자로 진화를 해봅시다!
- 4. 중점 사항 • “CPU 사용량은 높은데, 사용량을 유발하는 프로세스가 없다?” 4
- 5. 어떤 일이 있었는지 • AWS 버지니아 리전 EC2 인스턴스 3개 생성 • Apache Spark 2.4.8 Standalone Cluster 구성 • Master 1대, Worker 2대로 구성 • FMS (관제서비스) Stream Engine Job 을 실행 5
- 6. 어떤 일이 있었는지 • Streaming UI 에서 Scheduling Delay 가 감지. 처리 지연이 확인. 6
- 7. 어떤 일이 있었는지 • Worker 노드의 CPU 사용량이 100% 7
- 8. 어떤 일이 있었는지 8 내 코드를 의심하기 시작
- 9. 어떤 일이 있었는지 9 • 이런 저런 시도를 했지만, 여전히 성능은 떨어졌습니다. • 하지만 작업을 중단해도, CPU 사용량이 줄어들지 않았습니다. • top 명령으로 상태를 확인하였으나, 부하를 발생 시키는 프로세스를 찾을 수 없음. • load average 100%. iowait 정상.
- 10. 어떻게 파악했는지 • 시스템 로그를 확인 • dmesg • /var/log/message • /var/log/secure • /var/log/cron 10
- 11. 어떻게 파악했는지 11 • Cron 로그에 비정상 로그를 발견
- 12. 어떻게 파악했는지 12 • Cron 로그에 비정상 로그를 발견 • crontab -e 해당 라인을 지우고 재부팅 하였으나 증상은 여전
- 13. 어떻게 파악했는지 13 • Spark Cluster Master UI 에서 비정상 작업 실행 확인
- 14. 어떻게 파훼 했는지 14
- 15. 어떻게 파훼 했는지 • 밀어버리고 새로 깔아도 됐지만, 흔하지 않은 상황이라 궁금증을 해소하고 싶었습니다. 15 “CPU 사용량은 높은데, 사용량을 유발하는 프로세스가 없다?” “내일 권수 팀장님한테 물어봐야지~ㅎㅎ” 서버를 종료해두고 내일을 기다립니다.
- 16. 어떻게 파훼 했는지 • “CPU 사용량은 높은데, 사용량을 유발하는 프로세스가 없다?” • 프로세스를 숨길 수 있답니다. • 재부팅을 했는데 현상이 지속되면, 부팅 스크립트에 존재할 것 • rc.local • systemd • cron • … 16 숨기도록 하는 녀석이 있다.
- 17. 어떻게 파훼 했는지 • /usr/lib/system 디렉토리 내 변경 사항이 있는지 체크 17
- 18. 어떻게 파훼 했는지 • 알 수 없는 bot.service 발견 18
- 19. 어떻게 파훼 했는지 • /etc/kinsing 에 해당 바이너리가 존재하지 않는데 실행되고 있음 19 (보이지 않는데)
- 20. 어떻게 파훼 했는지 • /etc/ 디렉토리 밑에 변경사항이 있는지 체크 20 libsystem.so 파일과 ld.so.preload 파일의 변경을 발견
- 21. 어떻게 파훼 했는지 • libsystem.so • .so 파일은 lib 디렉토리에 위치하지 /etc 디렉토리엔 없어야 정상 • ld.so.preload • 선적재(preload) 라이브러리를 명시하는 방법 중 하나. • 다른 공유 라이브러리보다 우선순위를 가지고 실행되는 라이브러리. • LD_PRELOAD 값을 설정 또는 ld.so.preload 파일에 명시하는 방법으로 사용 • 이를 통해 특정 함수에 대한 후킹을 하거나 so를 Injection 할 수 있음. 21
- 22. 어떻게 파훼 했는지 • 실제 ld.so.preload 파일 내 libsystem.so 가 기록되어 있었음. • libsystem.so 파일의 이름을 바꿔버리니, 그제서야 /etc/kinsing 파일이 보임 • 그리고 CPU를 사용하는 프로세스도 확인이 가능해짐 22
- 23. 어떻게 파훼 했는지 • 관련 내용을 조합하니 이미 유명한 Kinsing Malware로 확인. • 다양한 방법으로 침입 • Log4j Log4shell exploit • PostgreSQL (5432 Port) • Docker REST API (2375/2376 Port) • Hadoop Yarn (8088 Port) • Apache Spark Cluster (7077 Port) 23
- 24. 어떻게 파훼 했는지 • 아래 파일들을 삭제 후 재부팅 • /etc/libsystem.so • /etc/ld.so.preload • bot.service • /tmp/kdevtmpfsi 24
- 25. 어떻게 보완 했는지 25
- 26. EC2 보안그룹 설정 • default 보안그룹이 0.0.0.0 Any로 열려 있을 수 있음. • 이번 케이스의 경우 신규 리전을 세팅하는 과정에서 보안그룹 설정을 모든 세팅이 끝난 후에 진행하려고 하였음 • 접속이 필요한 IP 대역에 대해서 사용하는 Port 만 Whitelist 형태로 설정. 26
- 27. 재발 방지 • Any로 설정된 보안그룹은 사용 금물 • AWS 환경 구축 시, 가장 우선적으로 VPC-보안그룹 설정부터 진행. • 가능한 한 알려진 기본 포트를 변경 하는 것을 권장 27
- 30. Spark Cluster Architecture 30 CLIENT MODE My Program (Job) spark-submit
- 31. Spark Cluster Architecture 31 CLIENT MODE My Program (Job) My Program (Job) My Program (Job) My Program (Job)
- 32. 상황 재현 32 CLIENT MODE Malware (Job) bin/spark-submit --master spark://host:7077 --executor-memory 10g my_script.py 7077 Port (Any) Attacker (AWS Lambda)
- 33. 상황 재현 33 CLIENT MODE Malware (Job) bin/spark-submit --master spark://host:7077 --executor-memory 10g my_script.py 7077 Port (Any) Attacker (AWS Lambda) Malware (Job) Malware (Job) Malware (Job)
- 35. Q&A 35
- 36. 관련 자료 • Log4j Kinsing Linux Stealth Malware in the Wild • 도커를 타겟으로 한 악성코드 - 보안 이슈 | AhnLab • kinsing malware 치료기 - 채윤이네집 • Analysis of Kinsing Malwares Use of Rootkit - Trend Micro • Threat Actors Exploit Misconfigured Apache Hadoop YARN 36