Более 100 тыс. паролей хакеров попали в Сеть из-за неосторожности

Более 100 тыс. паролей хакеров попали в Сеть из-за неосторожности

Более 100 тыс. паролей хакеров попали в Сеть из-за неосторожности

Исследователи выявили 120 тысяч систем, содержащих учётные данные участников различных форумов для киберпреступников. Интересно, что многие скомпрометированные аккаунты принадлежат именно злоумышленникам.

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

Всего эксперты компании Hudson Rock изучили около ста форумов киберпреступной тематики. Вся штука в том, что некоторые «хакеры» случайно заразили свои устройства вредоносными программами, что и привело к сливу учётных данных.

Представленная Hudson Rock статистика говорит о том, что злоумышленникам принадлежали 100 тысяч скомпрометированных компьютеров. А число утёкших связок «логин-пароль» с хакерских форумов превысило 140 тыс.

Помимо анализа публично доступных БД, исследователи изучили логи вредоносных программ, заточенных под кражу информации. Как правило, такие зловреды воруют пароли из браузеров.

Как удалось выяснить, что взломанные устройства принадлежали киберпреступникам (прежде всего начинающим и малоквалифицированным)? Дело в том, что специалисты нашли на этих устройствах дополнительные сведения:

  • Набор других учётных данных (адреса электронной почты, юзернеймы и т. п.);
  • Данные автозаполнения (имена, адреса, телефонные номера);
  • Информацию о системе (имена компьютеров, IP-адреса).

Более 57 тыс. аккаунтов было слито с комьюнити Nulled[.]to. Также в утечках засветились Raidforums, Hackforums и пр.

 

Самые сложные пароли были у участников сообщества BreachForums: более 40% комбинаций состояли как минимум из 10 символов. Однако киберпреступники часто использовали и слабы связки.

Расширения 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