클라우드 보안 오답 노트

ASEC(AhnLab SEcurity intelligence Center)은 실제 침해 사례를 분석하던 중, 온프레미스 환경에서 관리가 미흡했던 서비스를 클라우드 환경으로 이전하면서, 기존 취약한 설정들이 그대로 클라우드 환경으로 이전되어 침해를 당한 사례를 확인했다.

이번 글에서는 해당 내용의 보고서 주요 내용을 소개한다. 보고서 전문은 안랩의 위협 인텔리전스 플랫폼 ‘AhnLab TIP’ 구독 서비스를 통해 확인할 수 있다. 

개요

침해된 시스템에서는 아파치 톰캣(Apache Tomcat, 이하 Tomcat) 서비스가 운영되고 있는데, 해당 서비스는 관리자 페이지가 외부에 노출된 상태였다. 또한, 관리자 페이지에 잘 알려진 계정명(admin)과 유추 가능한 패스워드를 사용하는 등 설정이 취약했다. 이로 인해, 관리자 페이지가 침해되었고 배포 기능을 이용한 웹 셸(Web Shell) 업로드가 발생했다. 웹 셸은 온프레미스 환경에서 업로드 되었는데, 클라우드 전환 후에도 동일한 방법으로 웹 셸 업로드가 발생했다.

[그림 1] 침해 흐름도

CSP에서 사용하는 IP 대역은 공격자들에게 많이 알려져 있어 다양한 스캔 공격 대상이 되고 있다. 따라서, 동일한 서비스를 제공하는 서버라도 온프레미스 환경보다 클라우드 환경에서 공격에 더 많이 노출될 수 있다.

즉, 관리가 취약한 클라우드 환경은 온프레미스보다 피해가 발생할 가능성이 높다. 클라우드 환경에 대한 이해도를 높이고, CSP가 제공하는 보안 서비스와 마켓 플레이스에서 제공하는 보안 벤더의 솔루션을 적극 활용한다면, 보다 안전한 클라우드 환경을 구성할 수 있다.

다음으로, 침해되었던 환경에서 구체적으로 무엇이 잘못되어 있었는지 살펴보자. 

취약하게 관리되어 온 Tomcat 서비스

1. Tomcat 관리자 페이지 접근 제어 미설정

Tomcat은 서버 관리를 위한 관리자 페이지를 제공한다. 관리자 페이지처럼 중요한 페이지는 스캔 공격 대상이 되므로 관리자만 접근할 수 있도록 접근 제한 정책을 적용해야 한다. Tomcat의 접근 제한 정책은 'tomcat-user.xml' 파일에서 정의할 수 있다.

[그림 2] Tomcat 관리자 페이지 접근 제한 설정 예시

하지만 피해 시스템은 관리자 페이지에 접근 가능한 IP가 설정이 되어 있지 않았다. 또한, 외부 서비스 용도로 노출되어 있어 외부 IP에서 관리자 페이지 접근이 가능했다.

2. 취약한 설정의 Tomcat 관리자 계정 정보

Tomcat은 관리자 계정 기능이 여러 역할로 구분되어 있고, 'tomcat-user.xml' 파일에서 관리자 계정명, 패스워드, 역할 등을 정의할 수 있다. 또한, 관리자 웹 페이지에 접근 가능하더라도, 실질적인 사용을 위해서는 'manager-gui' 역할이 정의된 Tomcat 관리자 계정으로 로그인해야 한다.  

[그림 3] "tomcat-user.xml" 파일 중 계정 설정 부분

피해 시스템의 'tomcat-user.xml' 파일에는 Tomcat 설치 시 생성되는 기본 계정이 비활성화 되어 있었고, 관리자가 생성한 'manager-gui' 역할의 관리자 계정 한 개만 사용 중이었다. 해당 관리자 계정은 잘 알려진 계정명(admin)과 취약한 패스워드를 사용했다. 알려진 계정명과 단순한 패스워드를 사용하면 무차별 대입(brute forcing), 사전 대입(dictionary attack) 등 스캔성 공격에 취약해진다.

3. Tomcat 관리자 페이지를 이용한 WAR 배포 설정

외부 노출된 관리자 페이지에 관리자 계정(admin)으로 로그인에 성공한 공격자들은 Tomcat의 ‘배치’ 기능 중 ‘WAR 파일 업로드’ 기능을 이용해 웹 셸을 업로드했다. 배치는 로컬 또는 원격지의 “.WAR” 확장자 파일을 서버에 업로드하고 서비스로 제공할 수 있는 기능이다.

[그림 4] Tomcat 서비스 관리자 페이지(manager/html) 화면 중 일부

배포 기능을 이용한 웹 셸 업로드 공격은 "Server.xml" 파일의 자동 압축 해제(unpackWARs)와 자동 서비스 배포(autoDeploy) 설정에 영향을 받는다. 피해 시스템에서는 두 개 설정 값이 모두 'True'로 설정되어 있었다. 

[그림 5] [그림] 취약하게 관리된 "Server.xml"의 설정

unpackWARs 설정이 'True'면, 서비스 시작 시 Tomcat 설치 경로의 WAR 파일을 appbase 경로에 압축 해제한다. autoDeploy 설정이 'True'면 appBase 경로에 위치한 파일들이 자동으로 서비스에 등록된다. 두 개의 설정에 따라 관리자 페이지에서 업로드한 WAR 파일이 appbase 경로에 압축 해제되고, 자동으로 배포되어 웹 셸이 동작했다.

4. Tomcat 서비스 로그 모니터링 미흡

피해 시스템은 온프레미스 환경에서 동일한 설정으로 오랜 기간 서비스를 운영했고, 서비스 기간 동안 다수의 외부 공격 시도가 있었다. 

 

[그림 6] 침해 시스템의 클라우드 전환 이전 관리자 페이지 로그인 공격시도 횟수

[그림 6]의 클라우드 전환 전 최근 1년 이벤트 로그 통계를 보면, 관리자 페이지 로그인 시도가 다수 발생했고 이 중 실제 로그인에 성공한 이력도 있었다.

 

[그림 7] 온프레미스 환경에서 관리자 페이지 로그인 성공 이력 및 웹 셸 배포 흔적

 

[그림 8] 다수의 웹 셸 파일(*.war)가 배포된 흔적

Tomcat에 대한 공격 관련 이상 로그는 지속적으로 기록되고 있었으며, 웹 셸 파일 또한 시스템에 잔존해 있었다. 하지만, 피해 시스템은 로그 모니터링 부재로 인해 과거부터 발생한 다수의 웹 셸 침해를 인지하지 못했다.

5. 지원 종료된 버전의 Tomcat 사용

침해 시스템에서 사용하던 Tomcat은 2021년 3월 서비스 종료(EoS)된 Tomcat 7 버전이었다. EoS된 제품 사용 시 아래와 같이 취약점들에 대한 업데이트 지원을 받을 수 없다.

    - 해당 버전에 영향이 있는 버그 및 취약점 해결되지 않음

    - 보안 취약점 보고서에 해당 버전에 대한 내용이 다뤄지지 않음

 

[그림 9] Tomcat 7 서비스 종료(EoS) 공지

사용자들이 유념해야 할 것은 기업 및 기관이 자체적으로 설치해 운영하는 애플리케이션, 라이브러리 등 솔루션 형태의 서비스는 그 내부에 애플리케이션과 라이브러리 등이 존재한다. 솔루션을 업데이트 해 최신 버전으로 유지하더라도 해당 솔루션이 사용하는 애플리케이션 혹은 라이브러리가 취약한 버전이거나 지원이 종료되었을 수 있으므로 이에 대한 점검 절차가 필요하다.

안전하지 않은 클라우드 환경 구성

다음으로, 이번 사례를 클라우드 전환 및 서비스 운영 관점에서 살펴보자.

1. 취약한 서비스를 클라우드로 이전

보통 온프레미스에서 클라우드로 전환할 때, 서비스 장애 가능성을 낮추고자 기존 환경과 최대한 동일하게 전환하는 경우가 많다. 하지만, 보안 관점에서는 이처럼 환경을 그대로 옮기는 ‘lift and shift’ 접근은 보안 위협을 초래할 수 있다. 물론, 서비스 전환 대상에 대해 온프레미스 환경에서부터 취약점 점검, 보안 패치 적용, 모니터링 등을 지속적으로 수행해 왔다면 침해 가능성이 낮아진다. 하지만, 보안이 소홀했던 서비스를 온프레미스와 본질적으로 다른 클라우드 환경에 그대로 이전하는 것은 다양한 측면에서 위험 요소를 내포한다. 

본 문서에서 다룬 피해 시스템은 클라우드 환경으로 서비스를 이전하기 위해 온프레미스에서 서비스 중이던 Tomcat 폴더를 그대로 복사해 클라우드 환경으로 이전했다.

[그림 10] 온프레미스 및 클라우드 환경의 Tomcat 서비스 주요 설정 파일의 비교

온프레미스 환경에서부터 취약했던 관리자 계정 패스워드 설정, 기본 관리자 페이지 경로 사용, 관리자 페이지 접근 제한 정책 미적용 등의 문제가 있었다. 또한, Tomcat 폴더를 그대로 복사하면서 기존의 취약한 설정들이 클라우드 환경에 그대로 옮겨왔다. 

클라우드로의 전환을 계획 중인 기업들은 클라우드 환경을 재구성하는 과정에서 기존 서비스에서 취약하게 관리되어 왔던 부분들을 식별해 조치하는 작업을 선행해야 한다. 

2. 네트워크 인터페이스 관리 미흡

CSP들은 클라우드 환경에서 접근 제어를 손쉽게 할 수 있도록 네트워크 접근 제어 관련 서비스들을 제공하고 있다. 

구축 단계에서는 여러 애플리케이션 설치를 위해 접근 제어를 임시로 해제하거나, 접근 제어가 적용되지 않은 별도 네트워크 인터페이스를 연결하여 환경을 구축하곤 한다. 구축 이후 접근 제어 적용을 누락하거나, 구축 시 사용한 별도 네트워크 인터페이스를 제거하지 않은 채 사용하는 등 사용자 실수에 의해 네트워크 접근 정책에 허점이 생길 수 있다. 

따라서 클라우드 환경으로 전환 이후 서비스 외 불필요한 부분이 외부에 노출되지 않는지 테스트 및 모니터링이 필요하다.

3. 네트워크 인터페이스 변경 후 로그 모니터링 미흡

클라우드 전환은 시스템 뿐만 아닌 네트워크 환경에서도 변화를 발생시킨다.

클라우드로 전환 시, 기존 온프레미스를 기준 네트워크 구성 변경으로 인해 이벤트 로깅이 정상적으로 되지 않거나, 이벤트 로그는 기록되지만 로그에 기록되는 내용이 바뀌면서 중요한 정보가 기록되지 않을 수 있다.

본 문서의 피해 시스템은 클라우드 환경에서 로드 밸런서(load balancer) 서비스를 이용했다. 로드 밸런서 도입 후, Tomcat의 접근 로그(access log)에 기록되는 출발지 IP는 실제 서비스를 호출한 출발지 IP가 아닌 로드 밸런서 IP가 기록됐다. 이 때문에, 실제 공격자의 IP를 식별하지 못하는 문제가 발생했다. 

피해 시스템에서 다수의 공격 시도를 Access Log에서 확인할 수 있었으나, 출발지 IP가 모두 로드밸런서 IP로 기록돼, 실제 공격자의 IP를 식별할 수 없었다.

 

[그림 11] 온프레미스 환경 - 외부 출발지 IP가 기록된 Tomcat 접근 로그

 

[그림 12] 클라우드 환경 – 로드 밸런서 IP만 기록된 Tomcat 접근 로그

온프레미스에서 클라우드 전환 시, 애플리케이션에 따라 추가적인 문제들이 발생할 가능성도 있다. 따라서, 기업들은 클라우드 전환 후 이벤트 로그가 정상적으로 기록되는지 필히 확인해야 한다. 

4. 클라우드 보안 서비스 및 솔루션 미사용

피해 시스템은 CSP에서 제공하는 기본 모니터링 서비스 외에는 별도 보안 서비스를 사용하지 않았다. 해당 시스템에 궁극적으로 코인 마이너(Coin Miner) 감염이 발생했는데, 감염 이전에 발생한 스캔 시도 및 웹 셸 통신 행위 등을 탐지하지 못했다. 따라서, 사용하던 모니터링 서비스에 코인 마이닝 트래픽이 탐지되기 전까지 침해 사실을 인지할 수 없었다. 

대부분의 CSP는 기본적인 보안 모니터링 서비스를 무료로 제공한다. 하지만 해당 서비스는 최소한의 기능들만 지원한다. 현재의 고도화된 위협들을 고려했을 때, 안전한 클라우드 환경 조성을 위해서는 CSP가 제공하는 추가적인 보안 서비스나 마켓 서비스에 등록되어 있는 보안 벤더들의 보안 솔루션을 사용하는 것이 효과적이다. 

안랩은 자사 클라우드 보안 플랫폼 ‘AhnLab CLOUD PLUS’를 중심으로, 클라우드 워크로드 보안 플랫폼(AhnLab CPP), 차세대 클라우드 방화벽(AhnLab vTrusGuard), 클라우드 IPS(AhnLab vAIPS) 등 하이브리드 클라우드 환경에 최적화된 보안 솔루션들을 제공하고 있다. 자사 클라우드 보안 솔루션들은 주요 CSP들의 마켓 플레이스에 등록되어 있다.

안랩의 하이브리드 클라우드 보안 플랫폼에 관한 보다 자세한 내용은 안랩 홈페이지를 통해 확인할 수 있다. 

►안랩 하이브리드 클라우드 보안 소개 페이지 바로가기

결론 - 클라우드 전환 후 점검 사항

많은 기업들이 디지털 트랜스포메이션의 일환으로 온프레미스 환경에서 운영하던 서비스를 클라우드로 이전했거나 혹은 이전을 계획하고 있다. 클라우드 환경으로 이전 후, 미흡한 보안으로 인한 침해 사고를 방지하기 위해 다음 사항들을 점검해보자. 이를 통해, 더 많은 기업들이 클라우드 기반 비즈니스를 보다 안전하게 운영하길 바란다. 

분류	점검 항목	세부 내용
클라우드 시스템 점검	서비스 중인 시스템 점검	WEB/WAS/DB 등 애플리케이션 설치 경로 내 파일 점검 ● 서비스 목적 파일 외에 의도하지 않거나 불필요한 파일 존재 여부 서비스 접근 로그 점검 ● 애플리케이션 기본 페이지 스캔 이력 점검     - (내부 서비스) 내부 시스템으로부터 스캔 공격이 발생한적 있는지     - (외부 서비스) 접근 성공 로그가 발생했는지 – 스캔 공격 자주 발생 ● 서비스 페이지 외 호출 이력 점검     - 정상적으로 호출되는 페이지 외에 호출된 페이지가 존재하는지
	서비스 기본 페이지 노출 여부 점검	사용 중인 서비스의 기본 페이지가 노출되는지 점검 ● 서비스 기본 페이지가 외부에 노출되지 않도록 경로 및 파일명 수정 ● 기본 페이지의 경우 제거하거나, 관리자만 접근 가능하도록 정책 적용
	서비스 취약점 점검	사용 중인 서비스에 취약점 존재 여부 확인 ● 취약점이 조치된 최신 버전으로 업데이트 ● 클라우드 전환 시 취약점이 조치된 최신 버전 적용
	서비스 계정 보안성 점검	계정명과 패스워드가 스캔 공격에 취약한 조합을 사용하지 않도록 변경 ● (계정명) Brute Forcing 공격에 노출되지 않도록 일반적인 단어 지양 ● (패스워드) 복잡성 설정에 따라 일정 길이 이상으로 영문(대소문자), 숫자, 특수문자 혼합 관리 용도의 시스템에서만 접근이 가능하도록 접근 제한 정책 적용
	서비스 로그 점검	서비스 로그 모니터링 진행 ● 로드 밸런서로 인해 출발지 IP가 변경될 수 있어, 로그 출발지 IP에 실제 출발지 IP 기록되는지 확인     - Source IP 항목 변경으로 출발지 식별 불가 시, x-forwarded-for 항목이 기록되도록 설정 파일 수정
클라우드 관리자 콘솔 점검	네트워크 인터페이스 목록 점검	시스템 구축 및 점검 목적의 인터페이스의 연결 지속 여부 점검 ● 서비스 용도 외 불필요한 네트워크 인터페이스는 제거 조치
	네트워크 접근 제한 설정	관리 목적의 포트는 제한된 대상에게만 허용 ● 해당 포트는 점검 기간 중 제한된 대상에게만 허용하도록 정책 운영 서비스 포트에 대해서만 접근 허용 정책 적용 ● 접근 가능한 대상 지정
	보안 서비스 강화	보안 가이드라인 준수 여부 점검 ● 클라우드 가이드라인 자료를 참고하여 보안성 강화     - 클라우드 컴퓨팅 보안 가이드라인(국가정보원, 국가보안기술연구소)     - 금융 분야 클라우드 컴퓨팅서비스 이용 가이드(금융보안원) 클라우드 서비스 제공자의 보안 제품을 활용한 보안성 강화 ● 기본 제공되는 모니터링 상품 외 추가 보안 제품 적용     - 운영 중인 서비스 유형에 적합한 보안 제품 선택 ● 시스템 취약점 점검 제품 활용 ● 로그 모니터링 서비스 제품 활용 CSP 마켓 플레이스에 등록된 보안 벤더의 솔루션 활용 ● 마켓 플레이스에서 지원하는 추가 보안 제품을 이용한 보안성 강화     - 워크로드 보안     - 네트워크 보안 (모니터링, 침입방지 등)     - 시스템 취약점 점검

본 문서에서 다룬 내용에 관한 보다 자세한 사항은 보고서 전문을 통해 확인할 수 있다. 보고서 전문은 자사 위협 인텔리전스 플랫폼 ‘AhnLab TIP’ 구독 서비스를 통해 접근 가능하다. 

►TIP 포털 바로가기