Взломанный сторонний скрипт вывел $2,6 млн у пользователей Polymarket. Вот что нам известно об этой атаке и как мы защищаем скрипт Fathom.

29 октября международная биржа Polymarket подверглась взлому, в результате которого у 700 учетных записей пользователей было похищено около $2,6 млн. Причиной стал скомпрометированный сторонний скрипт мониторинга от DebugBear. Я расскажу о том, что нам известно об этой атаке, и о том, как Fathom защищается от подобных угроз.

Как был взломан Polymarket?

Polymarket подключил сторонний файл JavaScript от DebugBear, и этот файл был заменен вредоносным. Что интересно, целью был только Polymarket. DebugBear предоставил специальный файл JavaScript именно для Polymarket, и именно его злоумышленники заменили.

Нам пока неизвестны точные детали, но это могло произойти через фишинговую атаку на сотрудника DebugBear, утечку ключей доступа к CDN/хранилищу, компрометацию учетной записи CDN/хостинга (например, кражу учетных данных), перехват DNS, уязвимость в коде приложения DebugBear, взлом CI/процесса развертывания или потенциально через инсайдера (подрядчика/сотрудника). Существует множество потенциальных векторов атак, и я надеюсь, что вскоре мы узнаем подробности.

Как Fathom защищает скрипт аналитики?

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

Мы ограничиваем доступ к продакшну

Это нетипично, и мы, вероятно, единственная аналитическая компания в мире, которая так поступает. Наши окружения настроены так, что я — единственный человек, который может отправлять код в продакшн. Остальные могут вносить свой вклад только через пулл-реквесты. Обратная сторона того, что я единственный обладаю доступом к продакшну, заключается в том, что я должен быть на связи 24/7. Это осознанный выбор, который отлично работает уже восемь лет в Fathom и в моей предыдущей компании. На случай моего ухода из жизни у нас предусмотрен регламент передачи дел.

Годами мне указывали на «риск ключевого сотрудника», но на практике мы с этим не сталкивались. Даже когда мы подверглись DDoS-атаке, я разбирался с ней напрямую через службу поддержки AWS. Если мы когда-нибудь расширим доступ к продакшну за пределы моей учетной записи, это будет ограниченный, аудируемый доступ исключительно для чрезвычайных ситуаций, а не для повседневных задач.

Мы защищаем домен и DNS

Наш домен и DNS размещены в Route 53, в выделенном аккаунте AWS. Опять же, намеренно доступ к нему имеет только один человек. Для домена включена блокировка передачи (transfer lock), поэтому его нельзя перенести к другому регистратору без нашего ведома.

Мы защищаем доступ к нашему CDN

У нашего провайдера CDN есть API, которым мы не пользуемся, но мы все равно регулярно меняем ключ API. Только один аккаунт имеет доступ к нашему CDN, и он защищен уникальным, случайно сгенерированным паролем и двухфакторной аутентификацией (2FA). Наш CDN загружает файл script.js исключительно с наших собственных серверов. На нем не настроено файловое хранилище или пограничный код (edge code), которые могли бы использоваться для раздачи чего-то еще.

У нас статическая файловая система

Наш файл script.js упаковывается в пакет развертывания, а файловая система, с которой он раздается, доступна только для чтения во время выполнения. Ничто работающее в продакшене не может изменить его. Единственный способ изменить его — это новое развертывание, а я — единственный человек, который может санкционировать развертывания. Кроме того, наше окружение приема данных (где мы собираем аналитику и раздаем скрипт) размещено полностью отдельно от нашего основного приложения, поэтому все, что происходит в основном приложении, не может его затронуть.

Каждый клиент получает один и тот же скрипт

DebugBear предоставил Polymarket собственный кастомный файл, что позволило злоумышленникам незаметно атаковать одну компанию. Мы раздаем один и тот же файл script.js каждому клиенту. Если бы в него когда-либо были внесены изменения, это затронуло бы все сайты, использующие Fathom одновременно, и наша система мониторинга обнаружила бы это в течение нескольких минут. Кроме того, наш скрипт никогда не скачивает и не запускает никакой дополнительный код, поэтому наш эндпоинт приема данных может только принимать данные и никогда не отправляет инструкции.

Мы круглосуточно следим за файлом script.js

Мы используем стороннего провайдера для мониторинга содержимого нашего файла скрипта из нескольких точек по всему миру каждые 5 минут. Если меняется хотя бы один символ, срабатывает тревога, и мы немедленно переходим к действиям: развертываем заново заведомо исправный файл, обновляем учетные данные и уведомляем клиентов.

Что дальше

Мы не собираемся раскрывать здесь весь наш подход к безопасности, но хочу еще раз подчеркнуть, что мы всегда серьезно относились к безопасности нашего скрипта аналитики. Мы продолжим работу над улучшением защиты, включая рассмотрение вариантов с размещением скриптов на собственных серверах, целостностью подресурсов (SRI) и многим другим. Но мы хотели дать понять, что всегда защищали этот аспект.

Джек Эллис (Jack Ellis), основатель

Узнайте об опыте Джека Эллиса — технического автора, преподавателя и инженера-программиста с богатым опытом создания программного обеспечения.