tabbysable/poc-2020-8558Информация о Kubernetes CVE-2020-8558, включая эксплойт доказательства концепции.
CVE-2020-8558 — это уязвимость Kubernetes, опубликованная из-за того, что kube-proxy неожиданно делает службы хоста, привязанные к localhost, доступными другим узлам в сети. Я делаю акцент на "неожиданно", потому что эта уязвимость является следствием ошибки проектирования (недосмотра), а не ошибки реализации (бага). Код делает именно то, что заявлено, но мы все не смогли осознать последствия этого решения для безопасности.
Чтобы разрешить процессам хоста доступ к службам NodePort через адрес 127.0.0.1 (localhost), kube-proxy устанавливает sysctl параметр net.ipv4.conf.all.route_localnet=1. Согласно документации ядра, этот параметр заставляет ядро "не рассматривать адреса loopback как марсианские" — следствием чего является то, что они могут быть доступны другим узлам в сети. Это большая проблема, если у вас есть чувствительные службы без аутентификации, единственной защитой которых является привязка к localhost!
На момент написания сообщество Kubernetes всё ещё ищет наилучший способ решения CVE-2020-8558. Два очевидных варианта: перестать устанавливать sysctl route_localnet с самого начала или блокировать неправильно маршрутизированные пакеты localnet с помощью iptables. Исправление, использующее вторую стратегию, уже выпущено в kubelet >= 1.18.4, 1.17.7 или 1.16.11. Вы также можете применить его самостоятельно, обратившись к соответствующей проблеме Kubernetes для данной CVE, ссылка ниже.
Почему установка net.ipv4.conf.all.route_localnet=1 заслуживает идентификатора CVE? Прежде всего, потому что это нарушает нашу интуицию о IP-сетях.
По крайней мере с RFC 1122 от 1989 года пакеты из сети localhost 127.0.0.1/8 обрабатываются особым образом, им запрещено появляться "за пределами хоста". (Пожалуйста, свяжитесь со мной в Twitter, если вам известно о более раннем упоминании особых свойств 127/8.) Любой хост, соответствующий RFC, по сути имеет неявное, неудаляемое правило брандмауэра, блокирующее внешний доступ к службам, привязанным к 127.0.0.1 (и другим IP в этой сети — попробуйте пропинговать 127.127.127.127, если никогда этого не делали!). Мы привыкли полагаться на такое поведение и ожидать его. Мы часто запускаем чувствительные службы без аутентификации или шифрования и привязываем их к localhost для безопасности. Например, бэкенды HTTP в открытом виде, хранилище ключей-значений redis и пережиточный небезопасный порт Kubernetes api-server обычно защищены от вторжения таким образом. Мы настолько привыкли к этому поведению, что оно стало неотъемлемой частью нашего интуитивного понимания того, что значит быть IP-хостом. В таком свете понятно, почему многочисленные эксперты могли так долго упускать этот недостаток.
Как это работает?
Назовём любую сущность с IP-адресом "узлом". IP-пакеты отправляются от одного узла к другому, идентифицируясь по исходному и целевому IP-адресу в заголовке пакета. Каждый IP-узел является либо маршрутизатором (называемым шлюзом в RFC1122), либо хостом. Основное различие в том, что когда хост получает пакеты, предназначенные для чужого адреса, он игнорирует их. Маршрутизатор обращается к своей таблице маршрутизации и ретранслирует (пересылает) пакеты, пытаясь доставить их ближе к конечному адресату. Хост знает о некоторых локально подключённых узлах; для доступа к другим узлам он должен отправлять свои пакеты локально подключённому маршрутизатору. Эти локальные соединения могут быть типа «точка-точка» (например, PPP-соединение или некоторые виртуальные сети) или с общей средой (например, Ethernet).
Ваш почтовый ящик можно представить как соединение «точка-точка» между вашим домом и местным почтовым отделением. Чтобы маршрутизировать пакет по соединению «точка-точка», хосту нужно лишь указать правильный адрес назначения и передать пакет. (Это происходит на 3-м уровне модели OSI.) Чтобы маршрутизировать пакет по среде с общим доступом, хост должен сначала построить виртуальную цепь «точка-точка» через общую среду. В сетях Ethernet/IP это делается с помощью ARP на 2-м уровне модели OSI. По сути, если вы можете передать ARP-пакет, вы можете сказать другому хосту «Эй, я здесь», и он поверит вам. (Когда это делается неподобающим образом, это называется отравлением ARP-кэша.) Затем вы можете общаться, указывая соответствующие исходный и целевой Ethernet-адреса в своих пакетах.
Нормальный узел никогда не передаст пакет с адресом назначения 127.0.0.1 из-за RFC 1122. Если нормальный узел получает пакет с адресом назначения 127.0.0.1, он проигнорирует (отбросит) его, опять же из-за RFC 1122. Установка net.ipv4.conf.all.route_localnet=1 меняет это — она позволяет отправлять и получать пакеты с адресом 127.0.0.1, как если бы они не были особенными.
Итак, если злоумышленник имеет локальное соединение с целевым узлом, на котором установлен net.ipv4.conf.all.route_localnet=1, он может отправить ему пакет с адресом 127.0.0.1 в качестве адреса назначения, и целевой узел ответит соответствующим образом, как если бы 127.0.0.1 был совершенно обычным адресом. Два наиболее распространённых способа иметь локальное соединение с целевым узлом сегодня — находиться в той же Ethernet-сети (домене широковещания), что и цель, или быть контейнером, работающим на цели.
Обратите внимание, что при нормальной конфигурации Linux не позволит узлу злоумышленника передавать обычные пакеты, предназначенные для 127.0.0.1. Это можно обойти, перенастроив Linux-узел злоумышленника (если у них есть root-доступ) или подделав пакеты с помощью raw-сокета. Raw-сокеты требуют только возможности ядра Linux CAP_NET_RAW, которая по умолчанию предоставляется непривилегированным контейнерам. Это означает, что непривилегированный контейнер, контролируемый злоумышленником, способен эксплуатировать CVE-2020-8558.
Короче говоря, если вы используете kube-proxy или делаете хитрые вещи с net.ipv4.conf.*.route_localnet, вы подвержены риску. Вам следует потратить некоторое время на моделирование угроз, чтобы определить, насколько рискованна для вас эта подверженность, и спланировать соответствующую стратегию смягчения.
По сути, каждый Linux-хост с установленным net.ipv4.conf.all.route_localnet=1 уязвим. Заинтересует ли эта уязвимость злоумышленника, зависит от нескольких факторов:
Для оценки CVE-2020-8558 вы должны представить злоумышленников с различными возможностями и ответить на эти вопросы с их точки зрения. (Книга Адама Шостака «Моделирование угроз: проектирование для безопасности» описывает этот процесс очень подробно.) Два актуальных злоумышленника, которых вы обязательно должны рассмотреть: злоумышленник с узлом в вашей Ethernet-сети и злоумышленник, который может запускать код в непривилегированном pod на вашем хосте. Могут быть и другие интересные злоумышленники, которых вам также следует рассмотреть в зависимости от вашей среды и потребностей.
Для иллюстрации вот частично проработанный пример:
Хост, безусловно, доступен обоим злоумышленникам; мы это предположили в каждом случае.
Пакеты могут быть отфильтрованы, а могут и не быть. Вам нужно проверить. Во многих облачных средах и строго управляемых локальных сетях пакеты блокируются, если IP-адрес назначения не совпадает с ожидаемым сетью Ethernet-адресом. Само по себе это может стать концом игры для злоумышленника с узлом. Если на всех ваших узлах есть соответствующие локальные правила брандмауэра (например, предоставленные обновлённым kubelet), это приведёт к неудаче обоих злоумышленников.
