Стоящий за вредоносом Lurk преступник отказался от сделки с прокуратурой

Стоящий за вредоносом Lurk преступник отказался от сделки с прокуратурой

Стоящий за вредоносом Lurk преступник отказался от сделки с прокуратурой

Екатеринбургский суд рассматривает дело двух киберпреступников — Константина Мельника и Игоря Маковкина, которые похитили более 1,2 миллиарда рублей с помощью вредоносной программы, известной как Lurk. Обвиняемые в участии в ОПС, злоумышленники признали свою вину, согласившись пойти на сделку с Генпрокуратурой.

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

Маковкин и Мельник обвиняются в организации преступного сообщества и участии в нем (ч. 1 и ч. 2 ст. 210 УК РФ). Также следствие приписывает им семь эпизодов несанкционированного доступа к данным и использование и распространение вредоносных программ.

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

Участники киберпреступной группы, которая существует с 2013 года, похитили более 1,2 миллиарда рублей. Среди пострадавших компаний есть следующие: петербургская компания «Стройинвест», Ростовская снековая компания и три банка — сибирский филиал банка «Таата», «Гарант-инвест» и Металлинвестбанк.

Следствие утверждает, что наибольший ущерб был причинен именно Металлинвестбанку, сумма похищенных у него средств составляет 677 миллионов рублей.

Следующее заседание по делу запланировано на 3 октября, так как прокуратура не успела огласить обвинительные заключения, занимающие целый том.

Напомним, что согласно новой информации, возникшей вокруг деятельности киберпреступной группы Lurk, злоумышленники вывели крупные суммы денег со счетов лиц, руководящих партией ЛДПР.

Расширения Chrome могут слить секреты URL через атаку по стороннему каналу

Как оказалось, расширения Chrome можно использовать для слива кодов авторизации, сеансовых ID и других секретов из URL любой открытой вкладки. Никаких специальных разрешений для этого не понадобится, только доступ к declarativeNetRequest API.

Этот механизм, пришедший на смену webRequest API, позволяет расширениям сообщать браузеру, что следует изменить или заблокировать на загружаемой странице (заголовки, реклама, трекеры).

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

Исследователь Луан Эррера (Luan Herrera) обнаружил, что блокировку, диктуемую правилами, Chrome производит почти мгновенно, за 10-30 мс, а остальные запросы выполняются дольше (~50-100ms) — из-за сетевых подключений. Эту разницу во времени расширение может использовать для бинарного поиска с целью посимвольного слива URL.

// extensions/browser/api/web_request/extension_web_request_event_router.cc:1117-1127
case DNRRequestAction::Type::BLOCK:
  ClearPendingCallbacks(browser_context, *request);
  DCHECK_EQ(1u, actions.size());
  OnDNRActionMatched(browser_context, *request, action);
  return net::ERR_BLOCKED_BY_CLIENT;

Оракул для подобной тайминг-атаки строится с использованием chrome.tabs.reload для перезагрузки страницы и перехватчика chrome.tabs.onUpdated, помогающего отследить событие status === "complete". Замер времени между reload и завершением загрузки покажет, заблокирован запрос или успешно обработан.

Повторение проверок и бинарного поиска позволяет получить полный URL (с довеском после «?»), затратив на каждый знак строки несколько прогонов. Таким образом, можно незаметно для пользователя украсть включенные приложением в адрес секреты — токены OAuth и сброса пароля, API-ключи, ссылки на контент, закрытый для поисковых систем.

Проверка PoC проводилась на Windows 11 24H2 с использованием Chrome разных версий:

  • 144.0.7559.97 (Stable)
  • 145.0.7632.18 (Beta)
  • 146.0.7647.4 (Dev)
  • 146.0.7653.0 (Canary)

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

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