(при участии исследователя безопасности Марка Литчфилда)
Введение
В 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 (например, внутренние приложения, которые не доступны в Интернете).