Как уязвимости Chromium и слабые пароли приводят к компрометации Kaspa‑NG — технический разбор

Коротко: в 2024–2025 годах были зафиксированы несколько высоко‑приоритетных уязвимостей в компонентах Chromium (WebRTC, V8, ANGLE/Dawn и др.), которые позволяли атакующему выполнить код в контексте браузера или прочитать чувствительные объекты с сессии. В сочетании с тем, что десктопные кошельки (включая сборки Kaspa‑NG/аналогичные клиенты) по умолчанию хранят локальные файлы с кошельками и часто не шифруют их полностью, это создавало рабочий эксплойт‑вектор: drive‑by‑компрометация → доступ к локальным RPC/файлам → кража приватных ключей.

Технический слой: что именно ломали в Chromium

1) Use‑after‑free в WebRTC / ANGLE / Dawn. Такие баги дают возможность атакующему, подготовив специально сформированную HTML/JS‑страницу, коррумпировать куки и в дальнейшем выполнить произвольный код в адресном пространстве процесса браузера (remote code execution). На практике это означает, что браузер, оказавшийся на вредоносной странице, мог раскрывать сессионные данные и привилегированные объекты. Примеры таких записанных CVE включают инциденты с WebRTC use‑after‑free, исправлённые в экстренных патчах Chromium.

2) V8 / JIT эксплуатация. Уязвимости V8 (движка JavaScript) позволяли обходить границы памяти и получить доступ к объектам, которые браузер считал «безопасными» — cookie, localStorage, IndexedDB и иногда фрагменты рантаймной памяти, где могли храниться результаты криптографических операций. Эксплуатация таких уязвимостей в дикой природе фиксировалась и патчилась срочно.

Как это перекладывается на кошельки (путь атаки)

1. Браузер посещает вредоносный сайт (drive‑by). Эксплоит использует WebRTC/V8/ANGLE и получает выполнение кода в браузере.

2. Злоумышленник сканирует локальные интерфейсы (localhost) на стандартные порты — многие десктоп‑кошельки или ноды слушают RPC на 127.0.0.1: например, Kaspa‑нод/каспа‑клиент может иметь локальный RPC. Успешный эксплойт позволяет посылать запросы на локальный RPC в контексте пользователя (CORS/CSRF обходится эксплоитом).

3. Через RPC или прямое чтение файлов (если браузер/эксплойт получает доступ к файловой системе) атакующий получает либо доступ к расшифровывающим операциям, либо к самим wallet‑файлам/фрагментам памяти, где хранятся приватные ключи/seed. Результат — экспорт ключей или подписание транзакций без ведома пользователя.

Почему это особенно опасно для Kaspa‑NG и подобных десктоп‑кошельков

• Десктоп‑кошельки часто создают локальные файлы (папка .kaspa, %APPDATA% и т.д.) с wallet‑state и wallets, которые при отсутствии дополнительного шифрования легко доступны процессам пользователя.
• Если пользователь импортирует сид‑фразу в софт‑кошелёк и не выставляет сильный пароль/шифрование, приватные ключи остаются на диске в виде, который злоумышленник может прочитать и расшифровать. (supply‑chain и filesystem‑leak риски).
• Комбинация: браузерный 0‑day + локальный RPC/файлы = практически стопроцентный шанс компрометации при удачном эксплойте.

Практическая демонстрация в словах специалиста (что именно делают злоумышленники)

— Этап «сбор разведки»: эксплойт запускает скрипт, который ищет слушающие порты 127.0.0.1, отвечает ли там JSON‑RPC, проверяет версию ноды/кошелька и доступные методы.

— Этап «эксплуатация»: при наличии небезопасного метода (например, метод, который подписывает транзакции без пароля или доступен локально без аутентификации) атакующий может вызвать подпись транзакции, подставив туда свой адрес получателя.

— Альтернативный путь: чтение файлов кошелька (.db, .json) и отправка их через HTTP(S) на контролируемый сервер. Если сид‑фраза хранится в памяти или в файле — она попадает в руки злоумышленника.

Как снизить риск — технические и организационные меры

1. Не хранить seed в софт‑кошельке на обычном компьютере. Seed‑фразу — только офлайн: бумага/металл/аппаратный кошелёк. Никогда не загружать сид в ОС, где есть активный браузер. 🔐
2. Аппаратные кошельки (hardware wallets). Использование Tangem, Ledger, Keystone и т.д. удаляет приватные ключи из среды хоста: подпись транзакции происходит в устройстве, приватный ключ никогда не покидает чип. Для Kaspa рекомендуется выбирать устройства/провайдеры, которые прямо заявляют поддержку Bech32m/SECP256k1 либо интеграцию через совместимый интерфейс.
3. Закрыть локальный RPC/привязать его к localhost и установить аутентификацию. Если кошелёк/нода слушает порт — ограничить доступ, использовать firewall, либо завести password/IPC‑сокет вместо открытого HTTP.
4. Всегда ставить последние апдейты браузера и ОС. Многие эксплойты закрываются патчами — в 2024–2025 Google выходил с экстренными исправлениями для WebRTC/V8; своевременное обновление закрывает этот вектор.
5. Хранение wallet‑файлов под шифрованием. Если используется десктоп‑кошелёк — обязательно включать шифрование паролем (strong passphrase) и не оставлять ключи в виде открытого файла. Если перемещаешь `.kaspa` на зашифрованный диск — убедись, что бэкапы/синхронизация (OneDrive/Google Drive) не копируют эти файлы в облако.
6. Изоляция операций. Создавай кошелёк/импорт с чистой машины (air‑gapped) или используй hardware wallet; не открывай браузер во время операций с seed и не переходи по неизвестным ссылкам.
7. Аудит релизов и контрольные суммы. Скачивая кошелёк с GitHub, сравнивай SHA256/PGP‑подписи релизов — это защищает от подложенных сборок.

Рекомендации по использованию аппаратных кошельков (конкретика)

Почему hardware wallet? Аппаратный ключ генерирует приватный ключ в защищённом чипе, предоставляет интерфейс только для операций подписи и обычно защищён от извлечения ключа. Даже если хост‑машина полностью скомпрометирована, злоумышленник не увидит приватный ключ и не сможет подписать транзакцию без физического подтверждения (tap/подпись/phrase).

Практические советы при выборе и использовании:

• Покупать только с официального сайта/авторизованных реселлеров.
• Проверять совместимость с Kaspa (Bech32m) у производителя (Tangem прямо указывает поддержку ряда монет и интеграции).
• Включать PIN/защиту карты, использовать дополнительные passphrase (если поддерживается) для создания «псевдо‑кошельков» (passphrase‑derived accounts).
• Держать резервную копию seed (или recovery card) отдельно и офлайн в двух физических местах, защищённых от огня/влаги/кражи.

Как вести себя постфактум (если есть подозрение компрометации)

1. Считать все импорты на скомпрометированном устройстве утраченными — создать новые ключи на «чистой» машине или hardware wallet.
2. Перевести оставшиеся средства (если они есть на иных адресах) на новые адреса, созданные офлайн/на hardware.
3. Собрать артефакты: хэши бинарников, логи (.kaspa timestamps), сетевые логи — на случай обращения в правоохранительные органы или для рассылки разработчикам.
4. Сообщить разработчикам клиента (GitHub issue) и сообществу — иногда вредоносные сборки распространяются через сторонние сайты/форки.

Итог — ключевые мысли для читателя

1) Уязвимости браузера — реальная и эксплуатируемая угроза; своевременные патчи и аккуратная работа с локальным RPC критичны.

2) Софт‑кошельки, которые оставляют wallet‑файлы на диске без сильного шифрования, рискуют быть сведены в цель для атак «через браузер» или через локальные утечки.

3) Лучшее практическое средство защиты для непрофессионалов — аппаратный кошелёк (Tangem, Ledger, Keystone и т.д.), правильное резервирование и обновляемый софт.