(при участии исследователя безопасности Марка Литчфилда)

Введение

В PayPal безопасный жизненный цикл продукта (SPLC) представляет собой процесс обеспечения безопасности, позволяющий с течением времени уменьшать и устранять уязвимости безопасности в наших продуктах путем создания воспроизводимых/устойчивых упреждающих методов обеспечения безопасности, внедряя их в процесс разработки наших продуктов.

Ключевым принципом SPLC является включение уроков, извлеченных из устранения уязвимостей безопасности, обратно в наши процессы, инструменты и обучение, чтобы поддерживать цикл непрерывного совершенствования.

История уязвимости десериализации Java

Сообщество безопасности знало об уязвимостях десериализации в течение нескольких лет, но они считались теоретическими и сложными для использования. Крис Фрохофф (@frohoff) и Габриэль Лоуренс (@gebl) разрушили это представление еще в январе 2015 года своим выступлением на AppSecCali — они также выпустили свой генератор полезной нагрузки (ysoserial) в то же время.

К сожалению, их выступление не получило должного внимания в основных технических СМИ. Многие назвали ее самой недооцененной и недооцененной уязвимостью 2015 года. Так не было после ноября 2015 года, когда исследователи безопасности из FoxGlove Security опубликовали свои эксплойты для многих продуктов, включая WebSphere, JBOSS, WebLogic и т. д.

Это привлекло наше внимание, и мы начали разветвлять несколько рабочих потоков, чтобы оценить влияние на нашу инфраструктуру приложений.

Обзор ошибки десериализации Java

Пользовательский метод десериализации в общих коллекциях Apache содержит логику отражения, которую можно использовать для выполнения произвольного кода. Любое Java-приложение, которое принимает ненадежные данные для десериализации (т. н. маршалинга или деконсервации) и имеет общие коллекции в своем пути к классам, может быть использовано для запуска произвольного кода.

Очевидное быстрое решение состояло в том, чтобы исправить jar commons-collections, чтобы он не содержал эксплуатируемый код. Быстрый поиск в нашем внутреннем репозитории кода показал нам, насколько сложным может быть этот процесс — многие разные библиотеки и приложения используют множество разных версий общих коллекций, и переходный характер того, как это вызывается, делает его еще более болезненным.

Кроме того, мы быстро поняли, что речь идет не только о коллекциях общих ресурсов или даже о Java, но и о целом классе уязвимостей, которые могут возникнуть в любом из наших других приложений, выполняющих отбраковку произвольных типов объектов. Мы хотели подойти к этому хирургически, поскольку исправление сотен приложений и сервисов было поистине гигантским усилием.

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

Заявка на получение вознаграждения за обнаружение ошибок

Марк Литчфилд, один из ведущих исследователей безопасности нашей программы Bug Bounty, представил удаленное выполнение кода (RCE) с использованием вышеупомянутого генератора эксплойтов 11 декабря 2015 года. Марк является активным членом сообщества PayPal Bug Bounty с 2013 года. отправил 17 действительных ошибок и был отмечен на нашей стене славы.

Как оказалось, эта ошибка была обнаружена в одном из наших приложений, которого не было в наших основных средах Java. Как только мы проверили ошибку, команды разработчиков продукта и безопасности быстро перешли к исправлению приложения за пару дней, несмотря на мораторий на праздники.

Ниже приведены заметки Марка об этом представлении, сделанные его собственными словами:

  • Это была уязвимость десериализации Java.
  • Ошибки десериализации (по состоянию на месяц назад) привлекали большое внимание, так как их не замечали как настолько серьезные, насколько они были
  • В приложении было девять различных векторов атак

В то время как было девять различных экземпляров основной причины, основная уязвимость была только в одном месте, и исправление позаботилось об устранении всех экземпляров.

Исправление — в масштабе

В следующие несколько дней многие группы безопасности PayPal (AppSec, служба реагирования на инциденты, судебная экспертиза, управление уязвимостями, Bug Bounty и другие) и наши группы по разработке продуктов и инфраструктуре были в вихре активности.

Ниже приводится краткое изложение основных выводов, которые, по нашему мнению, будут полезны другим специалистам по безопасности.

Когда у вас есть несколько стеков приложений, основных и дополнительных приложений, готовых коммерческих продуктов, дочерних компаний и т. д., которые вы считаете потенциально уязвимыми, с чего начать?

Пусть реальный риск определяет ваши приоритеты. Вы должны убедиться, что активы с критическим риском получают первоочередное внимание. Вот различные «этапы» действий, которые помогут создать некоторую структуру при устранении такой крупномасштабной и сложной уязвимости.

Инвентарь

  • Если в вашей организации есть хороший инвентарь приложений, это упрощает вашу жизнь.
  • Если нет, начните искать продукты с известным кодом эксплойта, такие как WebSphere, WebLogic, Jenkins и т. д.
  • Подтвердите ручную инвентаризацию с помощью автоматического сканирования и убедитесь, что у вас есть надежный список серверов, которые нужно исправить.
  • Для пользовательского кода используйте инструменты статического и динамического анализа, чтобы определить воздействие.
  • Если у вас есть централизованное хранилище кода, это определенно упрощает задачу.
  • Убедитесь, что вы не пропустите одноразовые приложения, которых нет в ваших основных платформах Java.
  • Кроме того, обратитесь к контактам по безопасности и продуктам во всех ваших дочерних компаниях (если они не полностью интегрированы) и попросите их повторить описанные выше шаги.

Инструментарий

Вот несколько инструментов, которые полезно иметь в своем арсенале:

  • Сериализакиллер
  • Расширение Burp от DirectDefense
  • Коммерческие инструменты, которые у вас уже могут быть внутри компании, такие как инструменты статического/динамического анализа и сканеры. Если у ваших поставщиков нет пакета правил для сканирования, подтолкните их к его быстрому внедрению.

Кроме того, не стесняйтесь запачкать руки и написать свои собственные инструменты, которые помогут вам ориентироваться в вашей уникальной инфраструктуре.

Мониторинг и криминалистика

  • Внедряйте мониторинг до тех пор, пока не можно будет применить полноценный патч.
  • Сигнатуры для десериализации Java можно создавать, анализируя индикаторы уязвимости.
  • В этом случае элементарным индикатором является анализ сетевого трафика на наличие шестнадцатеричной строки «AC ED 00 05» и в формате с кодировкой base64 «rO0».
  • Независимо от того, используете ли вы IDS с открытым исходным кодом или коммерческие, вы должны иметь возможность реализовать правило для обнаружения этого. Обратитесь к бесплатным правилам Snort, выпущенным Emerging Threats.
  • Учитывая, что эта уязвимость существует уже некоторое время, проведите тщательный криминалистический анализ всех потенциально уязвимых систем.

Краткосрочное исправление

  • Во-первых, исправляйте свои системы с высоким уровнем риска, подключенные к Интернету, особенно продукты COTS, которые опубликовали эксплойты.
  • Для пользовательских приложений, использующих коллекцию Apache commons, вы можете либо удалить уязвимые классы, если они не используются, либо выполнить обновление до последней версии.
  • Если владельцы этих систем разные, многое можно сделать параллельно.

Долгосрочное исправление

  • Опять же, эта уязвимость не ограничивается общими коллекциями или Java как таковой. Это целый класс уязвимостей наподобие XSS. Соответственно, ваш подход должен быть целостным.
  • Лучше всего полностью отключить сериализацию объектов везде.
  • Если это невозможно, этот пост от Terse Systems содержит хорошее руководство по работе с пользовательским кодом.

Сводка

В заключение, мы понимаем, что современная инфраструктура приложений сложна, и вы не владеете/контролируете весь код, который работает в вашей среде. Эта конкретная уязвимость десериализации намного серьезнее, чем кто-либо из нас изначально предполагал, — она распространяется на компоненты с открытым исходным кодом, сторонние коммерческие инструменты и наш собственный код. Другим организациям следует относиться к этому серьезно, поскольку это может привести к удаленному выполнению кода и внедрению средств управления безопасностью для долгосрочного исправления, а не ограничиваться только исправлением библиотеки commons-collections. Обобщить:

  • Мы развернулись, чтобы быстро исправить известные уязвимости, чтобы защитить наших клиентов.
  • Мы инвестируем в инструменты и технологии, которые помогают инвентаризировать наши приложения, библиотеки и их зависимости гораздо быстрее и эффективнее.
  • Мы оптимизируем процесс обновления нашего приложения, чтобы быть еще более гибкими в реагировании на такие крупномасштабные угрозы.
  • Мы изменили нашу политику исправления ошибок безопасности во время моратория — теперь мы предписываем исправлять не только ошибки P0 и P1, но и ошибки P2 (например, внутренние приложения, которые не доступны в Интернете).