Реинкарнация вымогателя Cerber использует уязвимости Confluence и GitLab

Реинкарнация вымогателя Cerber использует уязвимости Confluence и GitLab

Реинкарнация вымогателя Cerber использует уязвимости Confluence и GitLab

В стане шифровальщиков объявился плагиатор: новая находка ИБ-экспертов заимствует некогда грозное имя Cerber, но атакует не только Windows, но и Linux. В частности, для проникновения на серверы зловред использует недавно опубликованные RCE-уязвимости в Atlassian Confluence и GitLab.

Изначальный Cerber появился на интернет-арене в 2016 году и начал быстро набирать обороты. Через пару лет его активность стала снижаться и к концу 2019 года практически угасла.

В прошлом месяце ИБ-исследователи обнаружили в дикой природе новые образцы вымогательской программы, именуемой Cerber. Вредонос способен шифровать файлы и в Windows, и в Linux; к итогу он добавляет расширение .locked и оставляет на машине записку __$$RECOVERY_README$$__.html с требованием выкупа в размере от $1000 до $3000.

Анализ кода показал, что новобранец не похож на прежних представителей семейства Cerber, которые к тому же не имели шифратора для Linux. Тем не менее, авторы новоявленного зловреда позаимствовали не только имя, но также заголовок обращения к жертве и сайт для приема платежей в сети Tor.

Для внедрения шифровальщика на сервер злоумышленники используют уязвимость CVE-2021-26084 в Confluence или CVE-2021-22205 в GitLab. Обе допускают удаленный эксплойт без аутентификации и позволяют выполнить сторонний код в системе. Производители уже выпустили патчи, и PoC-коды стали достоянием общественности.

Образец, подвергнутый анализу в BleepingComputer, был нацелен на такие папки:

  • C:\Program Files\Atlassian\Application Data
  • C:\Program Files\Atlassian\Application Data\Confluence
  • C:\Program Files\Atlassian\Application Data\Confluence\backups

Операторы нью-Cerber проводят свои атаки по всему миру, уделяя особое внимание мишеням в США, Германии и Китае (совокупно более половины инцидентов, зафиксированных исследователями из Tencent). В BleepingComputer удалось также подтвердить большое количество заражений в России.

 

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

В Google Chrome усложнили кражу cookie — новая защита от угона сессий

Google перевела функцию Device Bound Session Credentials (DBSC) в общую доступность для пользователей Chrome на Windows. Теперь эта защита работает в Chrome 146 и должна заметно осложнить жизнь тем, кто крадёт сессионные cookies, чтобы потом входить в чужие аккаунты без пароля.

Принцип работы DBSC кроется в том, что браузер не просто хранит cookie, а криптографически привязывает сессию к конкретному устройству.

Даже если зловред украдёт cookie из браузера, использовать их на другой машине будет уже гораздо труднее — по сути, они быстро потеряют ценность для атакующего.

Особенно актуально это на фоне популярности так называемых инфостилеров. Такие вредоносные программы собирают с заражённых устройств всё подряд: пароли, данные автозаполнения, токены и, конечно, cookie. Этого бывает достаточно, чтобы злоумышленник зашёл в учётную запись жертвы, даже не зная её пароль. Потом такие данные нередко перепродают другим участникам киберпреступного рынка.

 

DBSC должна ломать именно такой сценарий. На Windows технология опирается на Trusted Platform Module, а на macOS — на Secure Enclave. С их помощью создаётся уникальная пара ключей, причём закрытый ключ не покидает устройство. Когда сайту нужно выдать новую короткоживущую cookie, Chrome должен доказать, что у него есть нужный закрытый ключ. Если ключ не на том устройстве, схема просто не срабатывает.

При этом Google подчёркивает, что технология задумана с упором на конфиденциальность. По данным компании, DBSC не должна превращаться в новый механизм слежки: сайт получает только тот минимум данных, который нужен для подтверждения владения ключом, без передачи постоянных идентификаторов устройства или дополнительных данных аттестации.

Есть и важная оговорка: если устройство не поддерживает безопасное хранение ключей, Chrome не ломает аутентификацию и просто откатывается к обычной схеме работы. То есть пользователи не должны столкнуться с внезапными сбоями входа только потому, что их железо не подходит под новую модель защиты.

Пока публичный запуск ограничен Windows-пользователями Chrome 146, но Google уже подтвердила, что поддержку macOS добавят в одном из следующих релизов. Компания также заявила, что после начала внедрения DBSC уже заметила заметное снижение случаев кражи сессий.

RSS: Новости на портале Anti-Malware.ru