Автор: Андрій Михалюк, CEO CoreWin
Минула п’ятниця закінчилась начебто непомітно, але лише на перший погляд. В когось “підглючував” Linkedin, у когось “вилітав” поштовий клієнт, постійно втрачаючи з’єднання, але загалом більшість з нас списали це на звичайні незручності та спокійно відправились на вихідні. Log4Shell – найбільша вразливість року. В кінці статті я поділюсь власними напрацюваннями для перевірки сервісу на вразливість.
Суботу ж частина з нас, шановні колеги, зустріла з важким серцем, оскільки світом почали нестись новини про нову вразливість – log4shell. Дехто вже в суботу аварійно виїхав в офіс, хтось занурився у проблему вже у п’ятницю, але для всіх у світі ІТ стало зрозуміло — під ялиночку зловмисники нам всім поклали дуже неприємний подаруночок: безсонні ночі та необхідність в ударних дозах заспокійливих.
Щоб зрозуміти чому новина про вразливість у бібліотеці log4j наробила стільки шуму варто трошки зануритись у суть цієї бібліотеки, чи навіть фреймворку.
Перший фактор:
Бібліотека розповсюджується за ліцензією Apache, тобто вона безплатна.
Другий фактор:
Це рішення для Java розробок.
Третій фактор:
Ця бібліотека потрібна для журналювання, тобто запису системних і не тільки дій програми.
Розберемо по пунктах чому кожен з цих факторів привів до БАБАХу!
1. Ліцензія Apache
Ця ліцензія дозволяє використовувати бібліотеку вільно, для будь-яких цілей, розповсюджуючи необмежену кількість копій. На додаток — ліцензія не ставить умовою незмінність ліцензії розповсюдження програмного забезпечення і не наполягає навіть на збереженні його безоплатного та відкритого статусу. Єдиною умовою, що накладається Apache ліцензією, є інформування одержувача про факт використання початкового коду, що ліцензований під ліцензією Apache. Перекладаючи простою мовою — можна взяти цю бібліотеку, використати у своєму рішенні та спокійно застосувати пропрієтарну ліцензію на результат та отримувати з нього чесно зароблені кошти.
2. Це інструмент Java розробки
Java – це негласний лідер на ринку великих підприємств. Ось декілька причин:
- це стара мова і дуже багато корпоративних систем написані на ній, оскільки так склалось (так звані legacy системи), а значить написані на Java рішення мають перевагу перед іншими
- Java має велику кількість відкритих і не тільки готових до використання бібліотек (так-так, саме таких, як log4j), а значить не доведеться вигадувати велосипед і можна зосередитись на інноваціях
- зрештою Java дуже добре себе зарекомендувала на великих масштабах, що і є, по суті, визначенням корпоративного клієнта
3. Журналювання
Щоб не писали ваші розробники, який би застосунок не був — там будуть логи. Без логів практично неможливо проводити дебагінг, софт без журналу — це машина без фар на нічній сільській дорозі. Наче їде, але всі розуміють що рано чи пізно вріжеться у дерево.
Наразі немає статистики скільки корпоративних сервісів мають у своєму складі цю бібліотеку. Однак, будьте певні, ми говоримо про те, що ледь не кожна велика організація стикнулась з цією проблемою в ці вихідні.
Приміром за одним із досліджень 10 000 серверів були визнані вразливими. Більшість з них в США, які історично використовують багато legacy технологій.
Трохи мемів
На додаток, ця бібліотека виявилась вживаною в дуже популярних компонентах, таких як Apache Struts чи ElasticSearch, тому поверхня атаки була і досі залишається неймовірною. Найкраще цю ситуацію ілюструє один вдалий мем з минулого.
Тепер зануримось трохи у технологію
З відомих причин у цій статті я не буду детально розписувати технологію і причини вразливості, так само і те, як її можна використати у зловмисних цілях. Але, розгляньмо деякі особливості цієї вразливості.
1. Ця вразливість є дуже простою для використання
По суті для того, щоб використати не потрібно нічого окрім ноутбука з будь-якою ОС, доступ в Інтернет та базові вміння використовувати консоль (чи то cmd, чи то shell – немає різниці). До того, на момент суботи навіть знання були не потрібні. На YouTube вже були відео з використання вразливості (на момент публікації статті — вже заблоковані) на GitHub готові jar пакети для використання в одну команду (на момент публікації статті — вже видалені).
2. Ця вразливість надає ДУЖЕ глибокий доступ до сервера
Об’єктивно при вмілому використанні можна надіслати будь-яку команду на рівень операційної системи та вона буде виконана.
3. Ця вразливість є дуже гнучкою
По суті на її базі можна зробити з сервером що завгодно. Можна заразити його, долучити до ботнету, тихенько закинути шпигунський софт, зашифрувати дані, використати як проміжну ланку для отримання подальшого доступу — що завгодно.
Нам відомо що ця вразливість була відома хакерам принаймні з 1 грудня. Але у своєму дослідженні я зустрічав готові до атаки пакети, з поміткою що вони завантажені ще 2 роки тому. Не берусь судити наскільки вони “робочі”, але факт залишається фактом.
Отже, в п’ятницю відбулась успішна атака на сервер Minecraft і світова спільнота як професійних хакерів, так і любителів кинулись перевіряти свої сили в новому інструменті. В неділю ми вже отримали повідомлення про те, що організовані злочинці додали цю вразливість як у свої сканери, так і в віруси. Тобто з розділу таємних знань для обраних, ці атаки додались в сірий шум постійних масових атак. БАБАХ! Бо значна частина корпорацій виявилась просто не готовою до цієї атаки, а тому ми і досі отримуємо інформацію про нові успішні атаки.
І так, що робити?
- Потрібно оперативно (якщо не зроблено досі) провести детальний аудит не тільки сервісів компанії, але і зробити аналіз всіх їх компонентів. Скласти список в яких з них є log4j.
- Провести оперативну ручну перевірку найбільш критичних сервісів і black-box сканування всіх вебсервісів, що мають доступ в інтернет.
- Оновити або іншим чином закрити цю вразливість (благо наразі всі поширені рішення чи компоненти вже мають hotfix і готують bugfix).
- Переглянути та почистити всі сервіси де була бібліотека. Можливо ви вже атаковані та не знаєте цього.
- Розробити чи скористатись платформою, яка аналізуватиме бібліотеки та компоненти корпоративних рішень на вразливості хоча б наявні, а в ідеалі мати команду яка б аналізувала вразливості хоча б Github. Приміром у цьому випадку ви знали б про вразливість ще з грудня і могли вжити заходів до масових атак.
Додаткові матеріали
В допомогу колегам, ділюсь також відкритим безкоштовним інструментом перевірки на вразливість та інструкцією для відтворення вразливості в тестовому середовищі. Перевірені власноруч як робочі.
