Приблизно 38% програм, які використовують бібліотеку Apache Log4j, використовують вразливу до проблем безпеки версію, включно з Log4Shell. Критична вразливість, ідентифікована як CVE-2021-44228, має максимальний рейтинг серйозності, незважаючи на те, що виправлення доступні понад 2 роки. Про це повідомляє Bleeping Computer.
Log4Shell – це помилка неавтентифікованого віддаленого виконання коду (RCE), яка дає змогу отримати повний контроль над системами з Log4j 2.0-beta9 і до 2.15.0.
10 грудня 2021 року було виявлено вразливість нульового дня, яка активно використовувалася. Її широке поширення, легкість використання та величезні наслідки для безпеки послугували відкритим запрошенням для суб’єктів загрози.
Ця обставина спонукала до широкомасштабної кампанії сповіщення відповідальних за програму підтримки та системних адміністраторів. Але, незважаючи на численні попередження, значна кількість організацій продовжувала використовувати вразливі версії ще довго після того, як стали доступними виправлення.
Через 2 роки після розкриття вразливості та випуску виправлень існує багато цілей, які все ще вразливі до Log4Shell.
У звіті компанії з безпеки застосунків Veracode, заснованому на даних, зібраних у період із 15 серпня до 15 листопада, підкреслюється, що старі проблеми можуть зберігатися протягом тривалого часу.
Зміцнена поверхня атаки
Veracode збирав дані протягом 90 днів від 3866 організацій, які використовують 38 278 програм, що покладаються на Log4j, із версіями від 1.1 до 3.0.0-alpha1.
З цих програм 2,8% використовують варіанти Log4J від 2.0-beta9 до 2.15.0, які безпосередньо вразливі до Log4Shell.
Інші 3,8% використовують Log4j 2.17.0, який, хоча і не вразливий до Log4Shell, чутливий до CVE-2021-44832, недоліку віддаленого виконання коду, який було виправлено у версії 2.17.1 фреймворку.
Водночас 32% використовують Log4j версії 1.2.x, підтримка якої закінчилася з серпня 2015 року. Ці версії вразливі до кількох серйозних уразливостей, опублікованих до 2022 року, включно з CVE-2022-23307, CVE-2022-23305 і CVE-2022-23302.
Загалом Veracode виявив, що близько 38% застосунків у його видимості використовують незахищену версію Log4j.
Це близько до того, що повідомляють експерти з управління ланцюгом поставок програмного забезпечення в Sonatype на своїй інформаційній панелі Log4j: 25% завантажень бібліотеки минулого тижня стосувалися вразливих версій.
Погана практика безпеки
Постійне використання застарілих версій бібліотек вказує на проблему, яку Veracode приписує розробникам, що хочуть уникнути непотрібних ускладнень.
Відповідно до отриманих висновків, 79% розробників вважають за краще ніколи не оновлювати бібліотеки сторонніх розробників після їх початкового включення у базу коду, щоб уникнути порушення функціональності. Навіть якщо 65% оновлень бібліотеки з відкритим кодом містять незначні зміни та виправлення, які навряд чи можуть спричинити функціональні проблеми.
Крім того, дослідження показало, що для усунення серйозних недоліків у 50% проєктів потрібно 65 днів. Щоб виправити половину невиконаних завдань за умов браку персоналу, потрібно у 13,7 разів більше часу, ніж зазвичай, і понад 7 місяців, щоб обробити 50% за відсутності інформації.
На жаль, дані Veracode показують, що Log4Shell не став тривожним дзвіночком, на який сподівалися багато представників галузі безпеки.
Натомість Log4j сам по собі продовжує залишатися джерелом ризику в 1 із 3 випадків і одним із багатьох способів, якими зловмисники можуть скористатися для компрометації певної цілі.
Рекомендація для компаній полягає в тому, щоб просканувати своє середовище, знайти версії бібліотек із відкритим кодом, які використовуються, а потім розробити план екстреного оновлення для всіх них.
Раніше ProIT повідомляв, що хакери почали використовувати критичну вразливість ownCloud.
Підписуйтеся на ProIT у Telegram, щоб не пропустити жодну публікацію!
