Отчет об инциденте 25 апреля в io.net
Злоумышленники смогли изменить метаданные устройств, такие как названия устройств и их статусы (например, изменение статуса устройства с “включено” на “выключено”). Это было визуально подтверждено через передний интерфейс отображения устройств.
Фактическое аппаратное обеспечение графических процессоров осталось защищенным. Злоумышленники не могли получить доступ к основным ресурсам, поскольку выполнение вычислительных задач на аппаратном обеспечении пользователей крайне защищено и охраняется несколькими уровнями разрешений.
Полная детализация инцидента:
23 апреля 2024 года, за 26 часов до инцидента, мы внедрили механизм доказательства выполнения работы с целью выявления поддельных графических процессоров, продолжая непрерывное улучшение наших мер безопасности еженедельно. Агрессивные обновления безопасности, которые мы выпустили, вызвали значительное усиление методов, используемых злоумышленниками, что привело к непрерывному обзору и улучшению наших протоколов безопасности.
В этом инциденте атакующие аутентифицировались в workers-api с использованием устройства, которое предоставляло пользователю действительный универсальный токен аутентификации, который исторически был идентичен для всех распознанных графических процессоров.
Ранее наша система защищала от несанкционированных изменений путем обеспечения того, что модификации метаданных (включая идентификатор пользователя и идентификатор устройства) могли выполняться только законным пользователем, связанным с этим идентификатором устройства.
Как это произошло:
- Уязвимость в другом API, предназначенном для отображения контента в IO Explorer, случайно обнаружила идентификаторы пользователей при поиске по идентификаторам устройств. Злоумышленники использовали эту утечку, собрав эту информацию в свою собственную базу данных несколько недель назад, до того как мы ее обнаружили и исправили. Причиной сохранения данных было выявление тех, кто имел наибольшее количество графических процессоров для аирдропа.
- Позднее они обнаружили, что в другом API, ‘worker-api’, который используется/вызывается из кронов рабочего режима, можно обновить любые метаданные устройства, передав только идентификатор пользователя в заголовке, без необходимости аутентификации на уровне пользователя.
- Примерно за 26 часов до инцидента мы активировали системы доказательства выполнения работы и другие проверки, блокирующие поддельные графические процессоры от сети.
- Когда некоторые из их учетных записей/устройств были заблокированы из-за проверок доказательства выполнения работы, они использовали утечку данных, чтобы изменить метаданные устройств, принадлежащих другим пользователям, в качестве акта мести за блокировку. Важно отметить, что мы еще не закончили очистку поддельных графических процессоров, поэтому мы ожидаем еще больше атак по мере завершения очистки.
Обнаружение проблемы:
25 апреля в необычно высоком темпе производились операции записи в наше API метаданных графического процессора, что вызвало тревогу в 1:05 ночи по PST. Наш дежурный связался с нашей разработчической командой в 1:16 ночи по PST, и мы немедленно начали расследование проблемы.
Предпринятые действия:
Мы начали исправлять проблему в течение 10 минут после выявления проблемы. Несмотря на блокировку исходного IP, злоумышленник обошел это, перепрыгивая IP, и использовал ранее собранные идентификаторы пользователей и идентификаторы устройств. Как немедленный ответ, мы временно приостановили возможность обновления метаданных, таких как изменение имен хостов, чтобы предотвратить их злоупотребление. Эти изменения не были критическими для бизнеса, и доступ к графическим процессорам всегда был безопасным. Однако эта остановка была необходима, поскольку она вызвала некоторое беспокойство в сообществе из-за изменений в отображаемой информации на переднем конце, отсюда и источник FUD. Параллельно мы ускорили внедрение решения аутентификации для каждого пользователя, используя Auth0 с OKTA. Мы работали с OKTA три недели, и это внедрение было запланировано совпадать с запуском новой платформы в то же время, что и TGE. Мы завершили это за несколько часов, опередив график, и устранили уязвимость, связанную с универсальным токеном авторизации.
Мы также перенесли существующие данные аутентификации пользователей в новую систему, процесс, который занял шесть часов с нашей инфраструктурой базы данных SaaS (Supabase Postgres).
Дополнительные улучшения безопасности:
Мы провели проверки на инъекции SQL в наших API для усиления безопасности. Все изменения в общедоступных конечных точках API теперь подлежат обзору командой безопасности и проходят тестирование на проникновение, чтобы предотвратить излишнюю экспозицию чувствительных данных. Мы также улучшили ведение журналов несанкционированных попыток инициировали разработку модели для обнаружения и реагирования на такие аномалии более оперативно.
Команда безопасности будет проводить тщательные обзоры и тестирование на проникновение всех будущих изменений в любой общедоступной конечной точке, чтобы обеспечить надежную защиту от утечки информации, инъекции SQL и других уязвимостей. Наши текущие усилия направлены на обнаружение и нейтрализацию угроз на ранних этапах, укрепляя наше общее положение в области безопасности.
Отчет от: Гаурав Шарма | Главный технический директор
Перевод от: m4lka | Админ русского твитер аккаунта
