🔭Alibaba 클라우드, 해킹되다?!

안녕하세요, 최신 DevOps 소식을 알기 쉽게 공유하는 DevOps 여행을 위한 소식지입니다.

2024년 새해 아침이 밝았습니다. DevOps 여행을 위한 소식지를 읽고 계신 여러분 모두 새해 복 많이 받으세요 :)

3주 전 네이티브 클라우드 컨퍼런스 'KubeCon + CloudNativeCon'에서 흥미로운 발표가 있었습니다. Alibaba 클라우드 해킹 사례로 보는 인사이트라는 이름의 세션에서 Alibaba 클라우드의 특정 서비스의 취약점을 통해 해당 Kubernetes 클러스터에 대한 침투가 가능했다는 사례를 소개한 것인데요.😨

이번 소식지에서는 그 내용을 간단히 정리하고, 보안 관점에서 짚어볼만한 점을 함께 살펴보겠습니다.

본 소식지에서 소개한 세션은 아래 출처 링크를 통해 CNCF 공식 유튜브 채널에서 시청 가능합니다.

세션 발표자였던 클라우드 보안 회사 Wiz는 Alibaba 클라우드 서비스에서 Kubernetes 클러스터 내 특정 노드를 공격할 수 있는 취약점과, Alibaba 내부 이미지 저장소에 악성 이미지를 배포할 수 있는 취약점을 발견했다고 합니다.

또한 본 사례로 발견된 모든 이슈는 Alibaba 클라우드에 이미 보고되었고, Alibaba에서는 보고된 취약점 수정, 내부 컨테이너 보안 기술 적용 등으로 즉각 대응했다고 하네요🧐

그렇다면 각 취약점은 어떻게 발견되었고, 그 취약점이 의미하는 바는 무엇일지 먼저 살펴보겠습니다 :)

⚠노드에 대한 취약점은 어떻게 발견했을까?

사용자의 컨테이너와 관리용 컨테이너는 SSH로 연결이 가능한 상태였기에 취약점이 발생했습니다.

Wiz는 Alibaba의 웹 콘솔에서 SSL Encryption Enable 버튼 클릭 시 사용자의 컨테이너 홈 경로에 새로운 인증서 파일이 생성되고, 그 파일이 scp 명령어를 통해 Alibaba의 관리용 컨테이너로 복사되는 프로세스를 발견합니다.

이는 사용자의 컨테이너와 Alibaba 관리용 컨테이너 간의 SSH 연결이 가능하다는 뜻이었고, 이윽고 Wiz는 Alibaba의 관리용 컨테이너로 접속하는 Shell 커맨드도 발견하게 되죠😮

Alibaba의 관리용 컨테이너로 접속하자 그곳엔 docker.sock 파일이 있었는데, 이는 관리용 컨테이너에서 Docker API 호출을 가능하게 해주는 것이었습니다.

관리용 컨테이너가 동작하는 노드 위에 Docker API 호출로 새로운 컨테이너 이미지를 실행시킬 수 있기 때문에, 만약 이 상태에서 노드 침투를 위한 컨테이너를 실행한다면 해당 노드를 공격할 수 있음을 확인한 것입니다.💥

🔐내부 이미지 저장소에 대한 취약점은 어떻게 발견했을까?

내부 이미지 저장소에 대한 침투가 허용되면 클러스터 내 모든 노드가 위협을 받게 됩니다.

Kubernetes 클러스터의 모든 노드는 서로 연결되어 있기 때문에, Wiz는 Alibaba의 관리용 컨테이너 내에서 kubectl로 컨테이너 이미지 리스트와 이미지를 Alibaba 내부 저장소에서 Pull할 때 사용하는 Secret을 조회할 수 있었습니다.

게다가 해당 Secret은 Pull 권한과 Push 권한을 모두 가지고 있었고, 만약 취득한 Secret으로 악성 컨테이너 이미지를 Alibaba 내부 저장소에 Push한다면, 그 이미지는 모든 노드에 배포되어 공격 및 데이터 탈취가 가능함을 확인한 것입니다.

🔎보안 측면에서의 시사점

위와 같은 클라우드 해킹 사례에서 우리가 짚어봐야 할 점을 정리해보면 아래와 같습니다.

노드에 대한 취약점은 결국 컨테이너 간의 격리가 제대로 이루어지지 않고 다른 컨테이너로의 접근을 허용하면서 발생한 것입니다. 이러한 취약점을 미리 방지하려면 컨테이너 간의 격리가 보장되어야 할 것입니다.
내부 이미지 저장소에 대한 취약점은 앞서 살펴본 것처럼 접근 권한과 관련이 있었습니다. 그렇기 때문에 이미지 저장소에 대한 접근 권한은 철저한 관리가 중요하다는 것을 이번 사례를 통해 알 수 있었습니다.