도커는 컨테이너 기술 기반의 가상화 플랫폼이다. 가상화란 물리적 자원인 하드웨어를 효율적으로 활용하기 위해서 하드웨어 공간 위에 가상의 머신을 만드는 기술로, 가상화 방법에 따라 가상머신(Virtual Machine)과 컨테이너(Container)로 구분된다. 컨테이너(Container) 기술은 호스트 OS의 기능을 그대로 사용하면서 프로세스를 격리해 독립된 환경을 만드는 기술을 말한다.
컨테이너 기반 가상화 플랫폼으로써 사실상 업계 표준처럼 사용되는 도커는 많이 사용되는 만큼 보안 취약점 발생 시 큰 피해가 발생할 수 있다. 이번 글에서는 공격 표면 노출로 인해 발생할 수 있는 도커 컨테이너의 심각한 보안 이슈와 OSINT 검색엔진을 활용해 도커 컨테이너의 공격 표면을 탐지하는 방법에 대해 다룬다.
도커 컨테이너 보안 문제, 핵심은 Private Docker Registry
도커 컨테이너는 도커 클라이언트, 도커 호스트, 저장소(Registry)로 구성된다. 이 중 특히 보안 문제가 될 수 있는 것은 ‘도커 저장소(Docker Registry)‘다. 도커 저장소에는 도커에서 관리되는 각종 중요한 정보가 담겨 있으며, 외부 공개 여부에 따라 ‘Public Registry’, ‘Private Registry’로 구분된다. ‘Public Registry’는 도커의 공식 레지스트리인 도커 허브(Docekr Hub)나 기타 벤더 업체들의 레지스트리와 같이 외부에 공개된 저장소이다. 반대로, ‘Private Registry’는 사용자가 Private하게 구축해 내부망에서 사용하며, 제한된 사용자(회사 또는 팀원)만 접근 가능하도록 하는 것이 일반적이다. 외부 접근이 불가능하기 때문에 민감한 정보 등이 담겨있는 경우가 많으며, 그렇기 때문에 ‘Private Registry’에 설정 미흡 등의 이슈가 생긴다면 곧바로 보안 문제로 연결될 수 있다. 게다가 간혹 편하게 이용하려는 목적으로 도커 저장소를 외부 인터넷에 연결해 놓거나 클라우드에 설치해 놓고 잊어버리는 경우도 있다. 이러한 보안 이슈로 외부 비인가자 접근이 가능해지며, 개발 소스 유출 등의 보안 사고가 발생할 수 있다.
Criminal IP Asset Search 에서Title 필터에 아래 쿼리를 입력하면 공격 표면에 노출된 Private Registry 를 탐지할 수 있다.
Search Query : Title: Docker Registry
Search Query : Title: Docker Registry UI
Search Query : Title: Docker Registry Browser

[Criminal IP Search 101 – 해킹에 노출된 도커 컨테이너 레지스트리]
물론 이렇게 외부에 노출된 Docker Registry라고 해도 접근했을 때 아래 이미지와 같이 로그인 인증코드(401 코드)가 출력 된다면 최소한의 로그인 인증 장치는 되어있는 저장소이다. 이러한 저장소는 패스워드가 노출되지 않는 한 완전히 위험한 상태라고 보기는 어렵다. (물론 궁극적으로는 이와 같은 로그인 페이지조차 보이지 않도록 외부망 접근을 원천 차단해야 한다)


탐지된 Registry 중에는 로그인 인증 없이 접근이 가능한 것들도 발견된다. 접속해 보면 아래와 같은 Repositories 화면이 보이게 되며, 저장소 내부의 중요한 파일들이 완전히 노출되어 있다.
해커, 일반인 누구나 인증 없이 소스코드가 담긴 이미지 파일을 쉽게 내려받을 수 있다.

도커 API 서버로 인한 공격 표면 노출
앞에서 다룬 Registry들은 웹페이지가 존재하기 때문에 OSINT 검색엔진으로 페이지의 Title 명을 검색해 탐지했다.
그러나, 웹페이지가 존재하지 않더라도 API 서버를 통해 도커 컨테이너 내의 정보가 노출될 수도 있다. ‘Docker Registry HTTP API’는 도커의 이미지 배포를 편리하게 관리하기 위한 REST API로, 도커 레지스트리와 같은 역할을 한다. 때문에, 외부에 로그인 인증 시스템이 없는 Docker Registry HTTP API 서버가 노출되어 있다면 도커 레지스트리에 인증 없이 접근 가능한 상태와 같다.
Criminal IP Asset Search로 노출된 도커 API 서버를 탐지하려면 도커 레지스트리의 API 서버의 헤더 문구인 ‘Docker-Distribution-Api-Version’ 를 검색하면 된다.
Search Query : Docker_Distribution_Api_Version

도커 레지스트리 API 서버에 접속해 보면, 아래 화면에 보이는 것처럼 헤더 정보 외에는 어떤 Body 정보도 보이지 않는다.
이 상태로는 특별한 보안 문제가 없어 보이지만, 추가 동작으로 API 서버에서 도커 레지스트리에 대한 구체적인 정보를 획득할 수 있다.

아래 이미지와 같이 API 서버에 접속 후 ‘/v2/_catalog’ 명령어를 추가하면 Repositories 전체 리스트가 나오는 충격적인 결과가 나타난다.


도커 컴포즈(Docker Compose) 의 설정 파일 보안 문제
도커 컴포즈(Docker Compose)는 여러 개의 컨테이너를 유기적으로 묶어서 사용할 수 있는 기능이다. 이 기능을 사용하면 여러 가지 시스템을 연동할 때 마치 하나의 어플리케이션처럼 쓸 수 있기 때문에 개발자는 복잡한 작업 없이 간편하고 유용하게 작업할 수 있다.
예를 들어, 웹 어플리케이션을 서비스할 때 웹 서버(Apache, IIS, Nginx)와 Database(Oracle, Mysql, PosgressSql)를 동시에 설정해야 한다.
이 때 도커를 사용한다고 해도 개별적으로 컨테이너를 생성해야 한다. 하지만 도커 컴포즈(Docker-compose)를 사용하면 여러 컨테이너를 하나의 서비스로 묶을 수 있기 때문에 작업이 매우 간편해진다.
하지만 도커 컴포즈에서 사용되는 YAML 환경 설정 파일에 보안 문제가 발생할 수 있다. YAML 파일에 접근할 수 있다면, 도커로 만들어진 웹 서버나 DB 서버의 계정을 탈취할 수 있으며, 도커 컴포즈로 사용되는 서버가 디렉토리 리스팅 취약점을 그대로 둔 상태라면 YAML 파일에 쉽게 접근하여 계정을 탈취할 수 있다.
Criminal IP Asset Search에 아래 필터와 키워드 조합으로 도커 컴포즈 YAML 파일이 있는 웹사이트를 탐지할 수 있다.
Search Query : Docker-compose.yml title: Index of /

검색 결과는 총 430개로, 그 중 접속이 가능한 서버에 접속해보니 디렉터리가 인덱싱된 웹 사이트에 노출되어 있는 Docker-Compose.yml 설정 파일을 찾을 수 있다.


노출된 Docker-Compose.yml 설정 파일을 자세히 살펴보면 인증 관련 환경 변수(environment)에 Username과 Password가 기재되어 있다.

도커 스웜(Docker Swarm) 의 보안 문제
도커 스웜(Docker Swarm)은 여러 개의 도커 호스트를 하나의 클러스터로 묶어 주는 컨테이너 오케스트레이션 관리 도구로, 도커 컴포즈와 마찬가지로 작업의 편의성을 위해 사용된다. Criminal IP Asset Search에 Title: Docker Swarm 필터로 검색하면 노출된 도커 스웜을 찾을 수 있다.
Search Query : Title: Docker Swarm

검색된 도커 스웜(Docker Swarm) 은 총 24개로, 실제 매니저 노드에 접속한 화면은 아래와 같다.
이 매니저 노드를 외부에서 접근할 수 있게 된다면, 상상하기도 싫은 수 많은 보안 문제가 발생할 수 있다.

결론
효율적인 개발 환경 구축과 배포를 위해 사용되는 도커는 이제 필수불가결한 플랫폼으로 자리 잡았다. 항상 그렇듯 해커들은 많이 사용되고 사용할 수 밖에 없는 서비스를 공격 대상으로 삼기 때문에 도커 역시 작은 보안 결함으로도 심각한 피해를 초래할 수 있다. 하지만 도커 컨테이너를 사용한다고 해서 이러한 보안 결함이 발생하는 것은 아니며, 오히려 공식적으로 발표된 취약점들은 빠른 보안 패치와 점검 가이드로 조치할 수 있다.
하지만 앞에서 다룬 도커 컨테이너 보안 문제들은 안타깝게도 플랫폼 자체의 보안 문제가 아닌 사용자의 설정 미흡, 공격 표면 관리 미흡으로 인해 발생한다. 그리고 도커 뿐 만 아니라 개인 또는 기업에서 사용되는 모든 어플리케이션이 공격 표면 노출로 인해 보안 문제가 발생한다. 클라우드 시대에 앞으로 더 많은 제품과 서비스가 사용될 것이며, 그럴수록 해커의 타겟이 되는 공격 표면 역시 증가할 것이라고 많은 보안 분석가들이 말하고 있다. 이 문제를 해결하는 방법은 오로지 노출된 자산을 빠르게 탐지하고 인지하여 조치하는 것 밖에 없다. 공격 표면을 줄이기 위해 Criminal IP 와 같은 OSINT 검색엔진 또는 Criminal IP ASM 과 같은 공격 표면 관리 자동화 시스템을 통해 주기적인 자산 관리를 하는 것을 추천한다.
관련하여 API 키의 공격 표면 노출로 인해 정보 유출과 조작이 가능한 Django 웹 어플리케이션에 대한 글을 참고하면 좋다.
데이터 출처 : Criminal IP (https://www.criminalip.io)
관련 글 :
댓글 남기기