소개
앞서 소개한 K8SLANPARTY 3 – Data Leakage 풀이에 이어 4 – Bypassing Boundaries 풀이를 공유해보려 합니다.
이번 문제는 Service Mesh 인 istio 에서 istio-proxy 네트워킹과 관련된 문제입니다.
4 – Bypassing Boundaries
문제
문제에서 아래 정보들을 제공해주고 있습니다.
- Service Mesh 기술은 root user들에게 유니크한 매력을 제공합니다.
- 이 권한을 남용하지 말고 주의해서 사용하세요.
Kubernetes 의 Service Mesh 와 관련된 문제인 것으로 보입니다.
필요 사전 지식
- Kubernetes 의 Service Mesh 를 위한 프로젝트로는 istio, linkerd, consul 등이 존재합니다.
- 그 중에서 istio 는 istio-proxy 를 통해 네트워크 트래픽을 모니터링합니다.
- istio-proxy 는 iptables 를 기반으로 Pod 의 트래픽을 라우팅합니다.
- istio-proxy 에서는 envoy 프로세스가 트래픽을 받아 프록시 합니다.
풀이
문제에서 Service Mesh 에 대해 언급하였으니, 쉘을 통해 해당 container 가 Service Mesh 환경에서 구동되고 있는지, 있다면 어떤 Service Mesh 를 사용하고 있는지 확인을 해봅니다.
이를 확인할 수 있는 방법은 아래와 같이 2가지가 있을 듯합니다.
- env 확인
- 앞 문제에서 사용하였던 dnscan 을 이용하여 Service Mesh 관련 리소스 존재여부 확인
1. env 확인
env 명령어를 통해 확인해봅니다.
특별히 Service Mesh 관련 환경변수가 보이진 않네요.
2. dnscan 을 이용한 Service Mesh 관련 리소스 존재여부 확인
istio 관련 리소스가 확인되는 것으로 보아, istio 를 Service Mesh 로 사용되고 있는듯합니다.
발견 된만큼 이 서비스가 무슨 서비스인지 한번 확인해 봅니다.
istio AuthorizationPolicy 관련 에러가 발생하네요.
왠지 이 문제를 처리해야할 듯합니다.
그러나 현재 container 내부에서는 AuthorizationPolicy 관련 설정상태를 알 수 없습니다.. 음..
그런데 다시 보니 이번 문제에서 다른 이전 문제들과 다르게 계정이 root 이네요.. 무언가 이상함을 느낍니다…
Pod 에 부여된 권한과 관련하여 우회하기 위해서는 container 내부에서는 kubernetes api 요청 권한이 없는한 방법이 없을텐데..
iptables 명령어도 사용할 수 없는 환경이네요..
user 와 관련한것이라면… 🤔
만약 문제의 shell 이 istio-proxy container 라면 좀 말이 달라집니다.
istio 를 설치하게 되면 sidecar 로 istio-proxy 를 배포하게 됩니다. istio-proxy 는 조정된 Pod iptables 를 통해 모든 트래픽을 받아 프록시 및 모니터링을 합니다.
아래는 일반적으로 istio 가 사용설치된 환경에서 sidecar 가 배포되면서 istio-init container 가 어떻게 Pod 의 iptables 을 조정하는지 확인할 수 있는데요.
위의 iptables 를 보면 모든 트래픽은 uid/gid 가 1337 인 user 소유의 envoy 프로세스(인바운드는 15006 리스닝하여 받음)로 인입되어 프록싱된 후 목적지로 가게 되어있습니다.
그리고 uid/gid 가 1337 인 user 소유의 envoy 프로세스에서의 트래픽은 루프 방지를 위해 프록시 라우팅에서 제외가 되어있습니다.
이를 이용하면 우회가 가능하겠네요!
1337 uid 계정으로 트래픽을 만들면 istio proxy 를 타지 않고, authorizationPolicy 도 우회가 가능할듯합니다.
uid 1337 이 존재하는지 확인해봅니다.
여기 있네요. istio 계정으로 있습니다.
istio 계정으로 다시 curl 요청을 해봅니다.
나왔네요. 🤑