Автор: Андрей Михалюк, CEO CoreWin
Прошлая пятница закончилась вроде бы неприметно, но только на первый взгляд. У кого-то “подглючивает” Linkedin, у кого-то “вылетал” почтовый клиент, постоянно теряя соединение, но в целом большинство из нас списали это на обычные неудобства и спокойно отправились на выходные. Log4Shell – самая большая уязвимость года. В конце статьи я поделюсь собственными наработками для проверки сервиса на уязвимость.
Субботу же часть из нас, уважаемые коллеги, встретила с тяжелым сердцем, поскольку по миру начали нестись новости о новой уязвимости — log4shell. Кое-кто уже в субботу аварийно выехал в офис, кто-то погрузился в проблему уже в пятницу, но для всех в мире IT стало понятно — под елочку злоумышленники нам всем положили очень неприятный подарочек: бессонные ночи и необходимость ударных доз успокоительных.
Чтобы понять, почему новость об уязвимости в библиотеке 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. К примеру, в этом случае вы знали бы об уязвимости еще с декабря и могли принять меры до массовых атак.
Дополнительные материалы
В помощь коллегам делюсь открытым бесплатным инструментом для проверки на уязвимость и инструкцией по воспроизведению уязвимости в тестовой среде. Проверены собственноручно как рабочие.
