Непропатченная критическая уязвимость в библиотеке, используемой во многих Java-продуктах, существует уже около десяти месяцев, однако до недавних пор создатели PoC-эксплойтов почему-то обходили ее стороной.

В начале ноября исследователи из NTT Com Security исправили это упущение, обнародовав PoC, использующий баг в библиотеке Apache Commons Collections. Показательный эксплойт призван привлечь общее внимание к уязвимости, над устранением которой уже трудится Apache Commons. Данная брешь присутствует в многочисленном промежуточном ПО, в том числе в Oracle WebLogic, IBM WebSphere, JBoss производства Red Hat, сервере непрерывной интеграции Jenkins, а также в OpenNMS — открытой платформе мониторинга систем и сетей, использующей Java.

Ошибку в функции unserialize() библиотеки Commons Collections первыми изучили Гэбриел Лоуренс (Gabriel Lawrence) и Крис Фрохофф (Chris Frohoff); результаты были доложены на январской конференции AppSecCali 2015. По свидетельству исследователей, данную брешь можно использовать для проведения удаленной атаки на библиотеку с помощью специально созданного пакета, что позволит исполнить код под используемой операционной системой. Эту концепцию позднее доработали Стивен Брин (Stephen Breen) и Джастин Кеннеди (Justin Kennedy) из NTT Com Security; им удалось создать рабочий эксплойт, который был опубликован на прошлой неделе.

Представители Apache Commons сообщили Брину и Кеннеди, что патч находится в разработке, однако в самом Java-сообществе пока нет единого мнения о том, кто должен закрывать эту брешь — Apache Commons, заинтересованные вендоры или, может быть, Oracle. По словам исследователей, они направили отчет в Oracle еще в июле, а Apache Commons узнала о баге лишь недавно. Платформа Jenkins уже пропатчена.

«Я решился [на публикацию] исходя из таких соображений: положим, я узнал о бреши в понедельник и написал эксплойты для пяти продуктов к среде, — поясняет свое решение Брин. — Поскольку эта всем понятная информация была в открытом доступе на протяжении девяти месяцев и никто ничего не предпринял, мы не видели смысла держать свои разработки в тайне».

По свидетельству Брина, эксплуатация данной уязвимости довольно проста. «Мы говорили со многими специалистами по Java, и никто из них даже не обмолвился [об уязвимости], — сетует исследователь. — Баг был представлен на конференции, презентация появилась онлайн, однако никого это не заинтересовало. Вероятно, те, кто использует эту библиотеку, просто думали, что их эта проблема не затрагивает. Допустим, вам скажут, что в Apache Commons обнаружен дефект десериализации, — вы вряд ли поймете, о чем идет речь. В то же время баги в JBoss, Jenkins и WebSphere, позволяющие удаленно исполнить код без аутентификации, понятны многим. Все дело в том, что данная брешь была изначально представлена как уязвимость десериализации в Commons».

Сериализация — это процесс, который в данном случае библиотека использует для преобразования информации, вводимой пользователем, в последовательность битов, которую можно сохранить или передать по сети. Десериализация, как поясняют Брин и Кеннеди в блоге, — это обратный процесс, преобразование статичной формы в руководство к действию для пользователя. Уязвимость была привнесена из-за того, что библиотека некорректно санирует вводимые пользователем данные. Атакующий может добавить вредоносный код, и он будет принят и выполнен.

«Это позволит совершать любые действия под штатной операционной системой, — комментирует Брин. — Данная библиотека много где используется, и разработчики Java-продуктов давно воспринимают десериализацию как данность. Этот баг особенно опасен для внутренних сетей компаний. Как показало исследование, большинство сервисов в результате атаки могут потерять внешний доступ. Java-сериализацию также используют сотни других продуктов, и те из них, которые доступны из Интернета, могут оказаться уязвимыми к подобным атакам».

Исследователи предупреждают, что ставить патчи по мере готовности будет нелегко. Если Commons Collections кастомизирована для работы в конкретных приложениях, то, как и в случае с Shellshock, придется просматривать все взаимосвязи, отыскивая нужные приложения и обновляя их вручную.

«Shellshock-уязвимость в Bash можно было устранить простым апдейтом оболочки, однако на тот момент никто не сказал, что баг присутствует в Apache и сотнях других продуктов, использующих Bash, — констатируют разработчики Jenkins. — Проблема в том, что осуществить обновление не так-то просто».

Похоже, что атаку на Apache Commons также трудно обнаружить. «Для разных серверов приложений сценарий атаки неодинаков, — подтвердил Брин. — Вы просто отправляете [особый] пакет, и он исполняется в оперативной памяти, без обращения к жесткому диску. По этой причине крайне маловероятно, что его обнаружат СОВ или система предотвращения вторжений. Он закодирован в Java-объекте, так что вряд ли будет виден».

Категории: Главное, Уязвимости