mgrube/cve-2019-17633RCE로 이어지는 Eclipse Che CSRF
이 버그는 사용자가 웹 페이지를 방문할 때, 버전 7.3.0 및 7.4.1 이전의 Che를 실행 중인 머신에서 원격 웹사이트가 임의의 도커 컨테이너를 생성하고 시작할 수 있게 합니다.
이것은 CSRF 버그로, 원격 웹사이트가 독립 실행 모드로 Eclipse Che를 실행하는 모든 사용자의 머신에서 도커 컨테이너를 생성하고 시작할 수 있게 합니다. 공격자가 제어하는 많은 매개변수를 통해 정밀한 수준의 제어가 가능합니다. 일부 개발자는 로컬 도커 컨테이너를 관리하는 편리한 방법으로 독립 실행 모드의 Che를 사용합니다.
이것은 Che가 기본적으로 CORS를 활성화했기 때문에 가능했습니다. 이 문제는 이것이 무엇을 의미하는지 이해하는 사람들에게는 상당히 명백하지만, 기본적으로 Che는 모든 출처의 요청에 응답했습니다. 브라우저가 CORS 공격을 어렵게 만들기 위해 최선을 다하지만, 서버가 CORS를 허용하면 원격 사이트에서 로컬로 실행 중인 Che 서비스에 성공적인 POST 요청을 생성하는 것이 가능합니다.
기본적으로, 이것은 독립 실행 모드로 Che를 실행 중인 컴퓨터가 웹사이트를 방문할 때 인증되지 않은 모든 API 메서드를 호출할 수 있음을 의미합니다. 여기에는 새로운 Docker/OpenShift 컨테이너를 생성하고 실행하는 것도 포함됩니다.
간단한 POC가 이 README에 포함되어 있지만, 로컬 Che 서비스에 POST된 JSON을 살펴보면 제어할 수 있는 여러 흥미로운 매개변수(이미지, 시작 시 실행할 명령어, 컨테이너에서 시작할 서버 등)와 다른 상당히 흥미로운 특성들이 드러납니다.
이 취약점을 악용하려면 컴퓨터에서 Eclipse Che를 실행 중인 대상을 목표로 해야 합니다. 대상이 HTTP를 통해 제어하는 페이지를 방문하도록 해야 합니다. 그런 다음 XMLHttpRequest가 작동하여 원하는 대로 할 수 있습니다. 이 취약점을 완전히 이해하려면 Che 소스 코드를 살펴보고 API를 배우거나 이 저장소에 있는 POC를 간단히 사용해 보세요. 기본적으로 원하는 발판을 제공할 수 있도록 새로 시작한 컨테이너에서 컨테이너 또는 명령을 생성하려는 것입니다. 원하는 서버를 설정하거나 시작 시 명령이 실행되어 페이로드를 다운로드하고 거기서부터 작동하도록 할 수 있습니다. 이 공격은 기회주의적 공격이나 표적 공격 모두에 적합합니다.
더 자세한 논의는 여기에서 추적된 버그를 확인하세요. 대부분은 이 게시물을 반복하는 내용입니다.
이 공격을 성공적으로 실행하려면 페이지가 HTTP(HTTPS 아님) 서버에서 제공되어야 합니다. 로컬 Che 서버는 HTTP로 실행되고 널리 사용되는 브라우저는 HTTP와 HTTPS 콘텐츠를 혼합하는 것을 좋아하지 않기 때문에 이는 필요합니다.
이 문제를 해결하기 위해 Che 팀은 기본적으로 CORS를 비활성화했습니다. 이렇게 하면 적어도 향후 이러한 종류의 공격을 상당히 어렵게 만들어야 합니다. 로컬에서 Che를 실행하여 도커 이미지를 관리하고 있다면 업그레이드를 고려하세요.
