Учётные данные от 1,3 млн RDP-серверов слили на торговую площадку UAS

Учётные данные от 1,3 млн RDP-серверов слили на торговую площадку UAS

Учётные данные от 1,3 млн RDP-серверов слили на торговую площадку UAS

Одна из крупнейших торговых площадок для киберпреступников разместила логины и пароли от 1,3 млн серверов Windows Remote Desktop, которые были скомпрометированы в ходе кибератак злоумышленников. Параллельно специалисты запустили специальный сервис, с помощью которого организации смогут проверить наличие своих учётных данных в базах утечек.

Эта массовая утечка логинов и паролей в очередной раз продемонстрировала экспертам в области кибербезопасности, насколько расчётливо преступники пользуются результатами предыдущих кибератак для получения прибыли.

Сотрудники компании Advanced Intel запустили сервис под названием RDPwned, позволяющий организациям проверить наличие своих учётных данных RDP в базах, которые продаются на площадке UAS.

Для тех, кто не знает: UAS является крупнейшей торговой площадкой для киберпреступников, специализирующейся на продаже логинов и паролей от RDP, а также номеров социального страхования и доступа к прокси-серверам SOCKS.

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

Функциональность UAS, по словам исследователей, чем-то напоминает eBay. Покупатель украденных RDP-аккаунтов может искать скомпрометированные устройства в определённой стране, городе и даже отобрать их по конкретной операционной системе.

 

Из 1 379 609 учётных записей, обнаруженных на площадке UAS, многие содержат слабые связки «имя пользователя-пароль». Специалисты привели топ-25 скомпрометированных логинов и паролей. Судите сами, насколько системные администраторы иногда халатны.

Топ-25 имён пользователей:

  1. Administrator — 303 702
  2. Admin — 59 034
  3. User — 45 096
  4. test — 30 702
  5. scanner — 20 876
  6. scan — 16 087
  7. Guest — 12 923
  8. IME_ADMIN — 9 955
  9. user1 — 8 631
  10. Administrador — 8 612
  11. Trader — 8 608
  12. postgres — 5 853
  13. IME_USER — 5 667
  14. Usuario — 5 236
  15. user2 — 4 055
  16. Passv — 3 989
  17. testuser — 3 969
  18. test1 — 3 888
  19. server — 3 754
  20. student — 3 592
  21. reception — 3 482
  22. backup — 3 356
  23. openpgsvc — 3 339
  24. info — 3 156
  25. VPN — 3 139

Топ-25 паролей:

  1. 123456 — 71 639
  2. 123 — 50 449
  3. P@ssw0rd — 47 139
  4. 1234 — 34 825
  5. Password1 — 27 007
  6. 1 — 24 955
  7. password — 19 148
  8. 12345 — 16 522
  9. admin — 15 587
  10. ffff-ffc0M456x (дефолтный для MailEnable) — 15 114
  11. Admin@123 — 13 572
  12. User — 13 437
  13. scanner — 13 193
  14. scan — 10 409
  15. test — 10 169
  16. Aa123456 — 9 399
  17. Password123 — 8 756
  18. 12345678 — 8 647
  19. Admin123 — 8 214
  20. Passw0rd — 7 817
  21. admin,.123!@#$%^ — 7 027
  22. 1qaz@WSX — 6 248
  23. Welcome1 — 5 962
  24. P@ssword64 — 5 522
  25. abc@123 — 4 958

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