Уязвимости в цепочке поставок программного обеспечения вновь дают о себе знать: злоумышленники нацелились на процесс обновления OpsShield.
На этой неделе злоумышленники использовали скомпрометированные учетные данные для распространения вредоносных обновлений среди клиентов cPGuard. Затем они получили доступ к данным, хранящимся на серверах поставщика и в его биллинговых порталах, а также сделали копии как минимум трех облачных серверов OpsShield.
Компания заявила в уведомлении, что «заблокировала злоумышленника во всех системах, до которых, как нам известно, он добрался, и… восстанавливает те, которым мы не можем полностью доверять». Компания также выпустила обновления и настоятельно рекомендует клиентам обновить cPGuard до последней версии, сменить пароли и сгенерировать новые SSH-ключи.
В конечном итоге, широкий спектр несанкционированного доступа подчеркивает сохраняющуюся хрупкость цепочки поставок программного обеспечения, а также уязвимость самих инструментов безопасности.
«Настоящая опасность заключается в том, что злоумышленники смогли превратить доверенный механизм обновления безопасности в вектор для взлома серверов», — сказал Эрик Авакиан, технический консультант Infotech. «Программное обеспечение, которое должно было защищать эти серверы, стало источником их компрометации».
Анатомия атаки
OpsShield специализируется на программном обеспечении для защиты серверов и веб-безопасности. Продукт cPGuard представляет собой пакет безопасности, сканер вредоносных программ и межсетевой экран, предназначенный для серверов веб-хостинга Linux.
Компания сообщила, что с 1 по 2 ноября злоумышленники получили несанкционированный доступ к инфраструктуре распространения обновлений OpsShield и в течение примерно 70 минут распространяли вредоносное обновление.
Злоумышленники начали с изучения биллингового портала OpsShield, зарегистрировав учетную запись клиента под вымышленным именем и заказав бесплатную пробную версию cPGuard. Затем они отправили специально сформированные запросы, которые позволили им получить возможность выполнять команды на сервере для сбора данных. Они использовали украденные ключи доступа для публикации поддельных обновлений, которые выполнялись от имени root (высший уровень административных привилегий), а также для копирования конфиденциальных файлов и создания копий трех облачных серверов OpsShield.
Примерно 2950 клиентских серверов установили поддельное обновление, что привело к раскрытию хешей паролей, root SSH-ключей, паролей MySQL root и истории командной строки, сообщила OpsShield. Злоумышленники также получили доступ примерно к 7900 учетным записям биллингового портала, содержащим имена клиентов, адреса, электронные письма и хеши паролей.
OpsShield заявляет, что все еще анализирует точный запрос, который предоставил доступ, и исправила два возможных точки входа, а также проверила связанные компоненты поставщика «строка за строкой». Компания закрыла учетную запись злоумышленника, отозвала украденный ключ хранения обновлений, а также «все токены облачных API и ключи доступа в нашей учетной записи».
Компания также удалила защищенную оболочку (SSH) злоумышленника; удалила клоны своих серверов, созданные злоумышленником, а также любые снимки; включила более надежную защиту входа и заменила все SSH-ключи и пароли; сбросила все сеансы входа в биллинговый портал и ротировала все ключи; и начала перестраивать свои серверы биллинга, лицензирования и внутреннего управления с более строгими настройками PHP и межсетевого экрана.
Компания также опубликовала чистые обновления: v5.88.26, которое удаляет скрытую оболочку root; а также последующее обновление, которое удаляет запланированную задачу, оставленную злоумышленником. Кроме того, компания начала перевыпускать все закрытые и открытые ключи лицензий cPGuard, чтобы скомпрометированные злоумышленником копии перестали работать.
Компания посоветовала администраторам:
- Обновить cPGuard до последней версии, затем убедиться, что файлы /etc/cron.d/i93677, /var/tmp/.i93677/ и /var/tmp/.cpg91511_sh удалены; удалить их, если они не удалены;
- Сменить пароли root и все локальные пароли пользователей на сервере;
- Сгенерировать новые SSH-ключи root и удалить старые со всех серверов, которые им доверяли; до смены ключей считать серверы скомпрометированными;
- Сменить пароли MySQL root и любые пароли баз данных, а также ротировать любые пароли, ключи API или токены, существующие в истории командной строки;
- Сбросить пароли в биллинговом портале OpsShield и включить двухфакторную аутентификацию.
- Наконец, компания заявила: «если мы сообщили вам, что злоумышленник вручную вошел на ваш сервер, перестройте его из чистой резервной копии, сделанной до 1 ноября».
OpsShield проявляет прозрачность, но последствия реальны
«Честно говоря, немногие поставщики публикуют такие откровенные уведомления об утечках», — сказал Фрэнк Диксон из Dickson Research. «OpsShield заслуживает большой похвалы за это».
Однако, отметил он, самый опасный тип взлома — это тот, который осуществляет инструмент безопасности. Каналы обновлений намеренно оставляют открытыми, а инструменты безопасности работают от имени root, потому что им нужно видеть все, «поэтому поддельное обновление также выполнялось от имени root».
Для хостинг-провайдера один сервер может содержать сотни клиентских веб-сайтов и баз данных. Пароль MySQL root открывает доступ ко всем ним, а root SSH-ключ предоставляет доступ ко всем другим серверам, которые ему доверяют. История командной строки также часто содержит введенные пароли и токены.
Конечный клиент может пострадать больше всего, зная меньше всего, отметил Диксон, поскольку большинство владельцев веб-сайтов понятия не имеют, какой агент безопасности использует их хостинг-провайдер. Каждый сервер, который обновляется автоматически, доверяет конвейеру поставщика.
OpsShield описывает себя как небольшую команду, продающую услуги небольшим хостам по низкой цене, что является неприятной правдой цепочки поставок, сказал Диксон. «Ваша подверженность риску определяется самым мелким поставщиком, имеющим права root на ваших серверах, а не самым крупным».
Авакиан согласился, что это служит напоминанием о том, что цепочка поставок программного обеспечения предприятия безопасна настолько, насколько безопасны системы, идентификаторы и процессы, стоящие за ней. «Вы можете сделать все возможное для защиты своей собственной инфраструктуры и все равно подвергнуться компрометации через доверенного стороннего поставщика».
Особенно тревожит то, что злоумышленникам не пришлось атаковать тысячи клиентов по одному; им нужно было скомпрометировать всего один механизм распространения, чтобы использовать доверенную инфраструктуру поставщика против его клиентов, отметил он.
Сторонние поставщики увеличивают риск, что является фактом, который организации по-прежнему недооценивают, сказал он. «Предприятия должны уделять гораздо больше внимания управлению рисками, связанными со сторонними поставщиками и цепочками поставок».
Нулевое доверие — обязательное условие
Авакиан также отметил, что последствия для конечных клиентов могут выйти далеко за рамки первоначальной компрометации, поскольку украденные учетные данные могут быть использованы для проведения дальнейших атак. Предприятия должны применять подход нулевого доверия, который включает их поставщиков программного обеспечения и обновления, на которые они полагаются.
«Только потому, что обновление поступает из доверенного источника, нельзя считать его безопасным», — сказал он. Предприятия должны более внимательно изучать риски, связанные с поставщиками, защищать привилегированные учетные данные и проверять целостность программного обеспечения. Кроме того, необходимо постоянно отслеживать неожиданное поведение после обновления и быть готовыми быстро изолировать системы, если что-то пойдет не так.
«Вы должны планировать возможность того, что даже доверенный поставщик может быть скомпрометирован», — подчеркнул он. «И вам нужно отрабатывать такие сценарии в рамках регулярной программы настольных учений».
Диксон посоветовал начать с инвентаризации и выяснить, какие агенты поставщиков работают с привилегиями root или администратора, поскольку каждый из них является каналом обновления. Клиенты должны спрашивать поставщиков, где хранятся ключи публикации обновлений и что отделяет их от клиентских систем, отслеживать исходящий трафик с серверов, хранить секреты вне истории командной строки и относиться к SSH-ключам как к учетным данным с истекающим сроком действия. Конечные клиенты должны напрямую спросить своего хостера, использует ли он cPGuard, а затем сменить собственные пароли.
«Самое опасное программное обеспечение на вашем сервере — это, вероятно, программное обеспечение, которому вы доверяете обновление самого себя», — сказал он. «Выбирайте этих поставщиков так, как будто они имеют права root, потому что так оно и есть».
Эта статья изначально была опубликована на NetworkWorld.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Taryn Plumb
