위협 행위자는 컨테이너를 어떻게 공격하고 활용합니까? 이것은 제가 끊임없이 생각하는 질문입니다. 저는 이 분야에서 XNUMX년 넘게 일해 왔으며 답이 있어야 한다고 생각합니다. 하지만 나는 그렇지 않다.
그 대신에 나는 많은 다른 생각을 가지고 있지만 그 중 어느 것도 옳다고 정확히 지적할 수 없습니다. 이러한 우유부단함의 일부는 내가 "레거시" 세계에서 보안을 배우는 데 보낸 모든 시간 때문입니다. 컨테이너에는 실제로 아날로그가 없습니다. 물론 VM(가상 머신)은 종종 컨테이너와 결합되지만 컨테이너처럼 확장할 수는 없었습니다. 또한 컨테이너와는 완전히 다른 용도로 사용됩니다. 내 생각을 조정하고 컨테이너가 실제로 공격 표면에 맞는 위치를 이해하는 데 시간이 걸렸습니다.
컨테이너화된 환경에 대한 공격의 공개 사례는 매우 제한적입니다. 위반은 거의 항상 크립토마이닝과 관련이 있으며 이는 심각한 공격이지만 사고 대응 담당자는 이를 감당할 수 없다고 생각합니다. 또 다른 공통점은 Kubernetes에 있든 클라우드 계정에 있든 대부분 잘못된 구성의 결과라는 것입니다. 동기와 전술의 조합은 지금까지 그다지 고무적이지 않았습니다.
올드 웨이
RCE(원격 코드 실행) 취약점은 오랫동안 컴퓨터 보안의 주요 관심사였습니다. 그들은 여전히 그렇지만 이러한 사고 방식이 컨테이너에 어떻게 적용됩니까? 주요 위협으로 즉시 RCE로 점프하는 것은 쉽지만 컨테이너에 접근하는 올바른 방법은 아닌 것 같습니다. 우선 컨테이너는 수명이 매우 짧은 경우가 많습니다. 컨테이너의 44%는 XNUMX분도 채 걸리지 않습니다. – 따라서 침입자는 빨라야 합니다.
이 접근 방식은 또한 컨테이너가 인터넷에 노출되어 있다고 가정합니다. 확실히 일부 컨테이너는 이러한 방식으로 설정되지만 종종 매우 단순하고 NGINX와 같이 잘 테스트된 기술을 사용합니다. 이러한 응용 프로그램에 대한 제로 데이가 있을 수 있지만 매우 가치 있고 구하기 어려울 것입니다. 내 경험에 따르면 많은 컨테이너가 내부적으로 사용되며 인터넷에 직접 연결되지 않습니다. 이 경우 RCE 시나리오는 훨씬 더 어려워집니다. 나는 언급해야한다 로그4j하지만 이러한 종류의 취약점은 취약한 시스템이 경계에 있지 않더라도 원격으로 악용될 가능성이 있습니다.
새로운 길
RCE가 컨테이너가 직면한 가장 큰 위협이 아니라면 무엇입니까? 위협 행위자의 레이더에 컨테이너가 있습니까? 예, 컨테이너와 이를 지원하는 인프라는 무시하기에는 너무 중요합니다. 컨테이너 오케스트레이션 소프트웨어를 통해 컨테이너화된 워크로드를 상상할 수 없을 정도로 확장할 수 있습니다. 사용 추세도 증가하고 있으므로 대상이 될 것이라고 확신할 수 있습니다. RCE 취약점을 통해 얻을 수 있는 서버처럼 생각할 수 없습니다.
대신 실제로는 그 반대입니다. 외부에서 내부로 컨테이너를 공격하는 대신 내부에서 외부로 공격해야 합니다. 이것이 본질적으로 공급망 공격이 하는 일입니다. 공급망은 컨테이너 구축 방법을 이해하기 시작할 때 컨테이너에 대한 매우 효과적인 공격 벡터입니다. 컨테이너는 실행될 때 컨테이너에 있을 모든 것을 정의하는 Dockerfile과 같은 정의 파일로 시작합니다. 일단 구축되면 이미지로 바뀌고, 그 이미지는 무수히 많은 시간 동안 워크로드로 만들어질 수 있는 것입니다. 해당 정의 파일의 어떤 것이 손상되면 실행되는 모든 단일 워크로드가 손상됩니다.
컨테이너는 항상 그런 것은 아니지만 종종 무언가를 수행하고 종료하는 애플리케이션으로 특수 제작됩니다. 이러한 응용 프로그램은 거의 모든 것이 될 수 있습니다. 이해해야 할 중요한 점은 다른 사람이 작성한 라이브러리(폐쇄 소스 또는 오픈 소스)를 사용하여 빌드된 것이 얼마나 되는지입니다. GitHub에는 수백만 개의 프로젝트가 있으며 거기에 있는 유일한 코드 저장소는 아닙니다. SolarWinds에서 보았듯이 폐쇄형 소스는 공급망 공격에도 취약합니다.
공급망 공격은 공격자가 대상의 컨테이너 환경에 침입할 수 있는 좋은 방법입니다. 손상이 눈에 띄지 않는 경우 고객의 인프라가 공격을 확장하도록 할 수도 있습니다. 이러한 유형의 시나리오는 이미 진행되고 있습니다. Codecov 위반. 그러나 이 모든 것이 얼마나 새롭고 우리의 생각이 여전히 과거의 문제에 뿌리를 두고 있는지 때문에 감지하기 어렵습니다.
방법 앞으로
대부분의 문제를 해결하는 것과 마찬가지로 가시성은 일반적으로 시작하기에 좋은 곳입니다. 눈에 보이지 않는 것은 수정하기 어렵습니다. 컨테이너를 보호하려면 컨테이너 자체는 물론 컨테이너를 빌드하는 전체 파이프라인에 대한 가시성이 있어야 합니다. 취약성 관리는 빌드 파이프라인에 통합되어야 하는 가시성 유형 중 하나입니다. 또한 유출된 비밀을 찾는 것과 같은 다른 정적 분석 도구도 포함할 것입니다. 공급망 공격은 실제로 예측할 수 없기 때문에 런타임 모니터링이 중요하므로 컨테이너가 수행하는 작업을 정확히 알 수 있습니다.
