В конце октября Binance сообщила о взломе, в результате которого пострадали активы на значительную сумму. Цепочка атаки началась с заражённой установки Homebrew, найденной через поисковик, и фейкового собеседования с тестовым заданием. Этот случай — не единичный: злоумышленники всё чаще маскируют вредоносный код под легитимные задачи для разработчиков. В статье разберём, как устроена атака, где именно прячут угрозу в тестовых, и дадим практические чек-листы для соискателей и компаний.

Как работает атака через фейковое собеседование

Схема обычно выглядит так: разработчику приходит сообщение от «рекрутера» с предложением пройти собеседование в известную компанию. После короткого общения кандидату высылают тестовое задание — например, доработать небольшой проект или исправить баг в репозитории. Задание может выглядеть правдоподобно: используется реальный стек, есть описание требований и даже сроки. Однако в код или инструкции по установке зависимостей внедрён вредоносный скрипт.

В случае с Binance злоумышленники пошли дальше: они подготовили поддельный сайт с установщиком Homebrew, который находился через поисковик. Разработчик, следуя инструкции, скачивал и запускал заражённый пакет. В результате на машину попадал вредоносный код, который мог собирать данные или давать удалённый доступ. Ключевой момент — атака была нацелена именно на разработчика, у которого есть доступ к инфраструктуре и репозиториям.

Где прячут вредоносный код в тестовых заданиях

Вредоносный код может находиться в разных частях задания. Вот наиболее частые места:

  • Скрипты установки и сборки. В файлах package.json, Makefile, Dockerfile или shell-скриптах могут быть прописаны команды, загружающие и запускающие посторонние программы.
  • Зависимости. Злоумышленники могут добавить в проект пакет с похожим названием (тайпсквоттинг) или указать ссылку на вредоносный репозиторий.
  • Инструкции в README. Текст может содержать команды для установки инструментов, которые на самом деле ведут на фишинговый сайт или загружают malware.
  • Конфигурационные файлы. Например, .env с «тестовыми» ключами доступа, которые на самом деле являются рабочими токенами злоумышленника.
  • Скрипты в тестах. В коде тестов могут быть скрытые вызовы, выполняющиеся при запуске.

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

Чек-лист для разработчика: как проверить тестовое задание

Прежде чем запускать незнакомый код, выполните следующие шаги:

  • Изучите репозиторий. Просмотрите все файлы, особенно скрипты установки, конфигурации и зависимости. Ищите подозрительные команды: curl, wget, eval, exec, обращения к неизвестным доменам.
  • Проверьте источники. Убедитесь, что ссылки ведут на официальные сайты, а не на фишинговые клоны. Сравните домены с известными.
  • Используйте изолированную среду. Запускайте тестовые задания в виртуальной машине или контейнере, без доступа к вашим личным данным и рабочим аккаунтам.
  • Не устанавливайте зависимости вслепую. Проверяйте пакеты на наличие известных уязвимостей и подозрительных изменений. Используйте npm audit или аналоги.
  • Обращайте внимание на детали. Если задание требует отключить антивирус, запустить скрипт с правами администратора или ввести личные данные — это красный флаг.
  • Свяжитесь с компанией напрямую. Если вакансия вызывает сомнения, найдите официальный сайт компании и проверьте, есть ли там эта вакансия, или свяжитесь с HR по официальным каналам.

Эти меры не гарантируют полной безопасности, но значительно снижают риск.

Чек-лист для компании: как не стать инструментом атаки

Компании также должны защищать кандидатов и свою репутацию. Вот что стоит внедрить:

  • Публикуйте тестовые задания на официальных ресурсах. Например, в корпоративном репозитории или на платформе для собеседований, а не в случайных архивах.
  • Подписывайте задания. Указывайте контактное лицо и ссылку на официальную страницу вакансии, чтобы кандидат мог проверить подлинность.
  • Не требуйте запуска подозрительных скриптов. Если задание требует установки дополнительного ПО, предоставьте инструкции с официальных источников.
  • Обучайте рекрутеров. Они должны знать о фишинговых схемах и предупреждать кандидатов о возможных мошенничествах.
  • Используйте безопасные платформы для тестовых. Например, онлайн-песочницы, где код выполняется изолированно.

Кроме того, компаниям стоит мониторить упоминания своих имён в контексте фейковых вакансий и оперативно реагировать.

Типичные ошибки и примеры

Одна из главных ошибок соискателей — доверие к заданию без проверки. Например, разработчик получает ссылку на GitHub-репозиторий с тестовым заданием. В README написано: «Установите зависимости через npm install, затем запустите npm start». В package.json может быть прописан пост-инсталляционный скрипт, который скачивает и запускает исполняемый файл с неизвестного сервера. Если не проверить package.json, вредоносный код попадёт на машину.

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

Ещё одна ошибка — запуск тестового задания на рабочей машине с доступом к корпоративным ресурсам. Это может привести к компрометации всей инфраструктуры. Всегда используйте изолированное окружение.

В случае с Binance атака была сложной и многоступенчатой, но базовые меры предосторожности могли бы её остановить. Например, проверка источника установщика Homebrew или анализ скриптов в тестовом задании.

Помните: безопасность — это процесс, а не разовое действие. Регулярно повышайте осведомлённость, следите за обновлениями инструментов и не пренебрегайте проверками. Тогда риск стать жертвой подобной атаки снизится.