Современная децентрализация - вопрос жизни и смерти? Проектируя DeFi-протоколы, разработчики привыкли просчитывать множество рисков: ошибки в смарт-контрактах, рыночные потрясения, компрометацию ключей, атаки на инфраструктуру. Но, похоже, в этот список приходится добавлять ещё один сценарий:
что, если вооружённые преступники придут домой к разработчику и под угрозой его жизни заставят совершить действия против собственного протокола?И мы не уверены, что у криптоиндустрии сегодня есть исчерпывающий ответ на вопрос, как защититься от подобной угрозы.
Что произошло с DSFСегодня наш коллега Андрей, технический директор DSF, подвергся вооружённому нападению в собственном доме во Вьетнаме.
Под угрозой причинения тяжкого вреда жизни ему и его семье, злоумышленники вынудили передать удаленный доступ к его компьютеру на котором находились средства доступа к инфраструктуре и ключи управления смарт-контрактами. В ходе нападения был также похищен телефон Андрея. Впоследствии он потерял сознание, предположительно вследствие воздействия неизвестного вещества, которое его вынудили выпить. Обстоятельства произошедшего продолжают устанавливать.
Получив доступ, злоумышленники провели серию операций, в результате которых из протокола были выведены пользовательские средства. Для этого они воспользовались предусмотренной в архитектуре функцией экстренного вывода активов, изначально предназначенной для реагирования на чрезвычайные ситуации и угрозы безопасности.
При этом атакующим не потребовалось преодолевать существовавшие механизмы мультиподписи (3 мультиподписи которыми был защищен смарт-контракт (причем с нескольких устройств, у двух фаундеров): критическая цепочка полномочий позволяла выполнить эти операции другим путём.
По предварительным данным, общая сумма потерь составляет около $500 000. Примерно половина похищенных средств уже была проведена через криптовалютный миксер. Перемещение остальных активов мы продолжаем отслеживать совместно со специалистами по блокчейн-расследованиям, пытаясь установить полную картину произошедшего и определить возможности ограничения дальнейшего движения средств.
К расследованию подключились правоохранительные органы. Наши коллеги во Вьетнаме взаимодействуют со следствием и предоставляют необходимую информацию.
Как устроена безопасность DSFДля тех, кто не знаком с нашим проектом, хотим дать немного контекста.
На протяжении почти четырёх лет мы развивали DSF как инструмент для относительно консервативного размещения капитала в DeFi. Нашим приоритетом всегда была устойчивость стратегии, а не погоня за максимальной доходностью. В основе подхода лежали диверсификация активов, использование децентрализованных протоколов и снижение зависимости от отдельных участников финансовой инфраструктуры.
До сегодняшнего инцидента нам удавалось сохранять капитал пользователей на протяжении разных фаз рынка, включая периоды серьёзных потрясений в криптоиндустрии.
Эти принципы отражались и в технической архитектуре DSF. Средства размещались через смарт-контракты в пулах Curve, а не хранились на счетах команды. Ликвидность распределялась между несколькими пулами и стейблкоинами разных эмитентов, чтобы снизить концентрацию рисков. Пользователи могли взаимодействовать со смарт-контрактами напрямую, независимо от доступности сайта. Для ряда административных операций использовались мультиподписи с распределением доступа между участниками команды и устройствами.
Все эти решения были направлены на снижение разных категорий рисков. Однако, как показало произошедшее, наличие нескольких механизмов защиты ещё не означает, что все критические сценарии действительно перекрыты.
Где обнаружилась архитектурная проблема, и почему она шире кейса одного протоколаПривилегированный доступ, в том числе функции экстренного реагирования -
распространённая практика в DeFi-протоколах. Он необходим потому, что далеко не все решения можно поручить автоматике: чем сложнее финансовый протокол, тем больше ситуаций, в которых заранее запрограммированных правил может оказаться недостаточно.
Административные функции позволяют оперативно реагировать на угрозы, менять параметры работы системы и устранять обнаруженные уязвимости.
Однако чем больше таких полномочий, тем выше потенциальные риски в случае их компрометации. Поэтому разработчики применяют различные механизмы защиты, которые использовали и мы: мультиподписи, разделение прав доступа, архитектурные ограничения, призванные исключить единую точку отказа. Поиск баланса между управляемостью протокола и его безопасностью - острие на котором всегда балансируют разработчики DeFi-систем.
Тем не менее произошедшее выявило критический недостаток архитектуры: одна из цепочек административных полномочий позволяла получить контроль над выводом активов через доступ, сосредоточенный у одного человека.
Безусловно, это архитектурная проблема. Подобные полномочия не должны зависеть от безопасности одного человека. Мы признаём это и не считаем, что обстоятельства нападения снимают с нас ответственность за принятые технические решения.
Но есть и другая сторона произошедшего, которую мы считаем принципиально важным подчеркнуть.
Когда техническая уязвимость становится угрозой человеческой жизни,
которую нужно просчитать заранееDeFi-индустрия уже сталкивалась с множеством инцидентов, в том числе привилегированного доступа: ошибками в смарт-контрактах, инсайдерскими злоупотреблениями, компрометацией ключей, социальной инженерией.
Но в
нашем случае речь идёт о вооружённом нападении на человека. Злоумышленники не обнаружили ошибку в коде и не обманом получили доступ к системе. Они применили физическое насилие и угрозы жизни, чтобы принудить CTO выполнить их требования.
И нам кажется недопустимым воспринимать произошедшее просто как очередной инцидент безопасности DeFi-протокола, который можно объяснить недостатками архитектуры и закрыть рекомендацией использовать дополнительные технические ограничения.
Можно исключить критические административные функции.
Можно распределить полномочия между десятками независимых участников.
Можно сделать так, чтобы ни один человек, даже под угрозой собственной жизни, технически не мог выполнить требования нападающих.
Что произойдёт, если преступники не знают об этих ограничениях или не поверят, что человек действительно не способен выполнить их требования? Мы не можем знать, как они поведут себя в такой ситуации.
Получается, что даже техническое решение, способное защитить средства, не обязательно обеспечивает защиту людей, отвечающих за работу протокола.
Разработчики финансовых технологий должны иметь возможность создавать и развивать проекты, не подвергая свою жизнь и жизнь близких опасности из-за доступа к финансовой инфраструктуре. И как этого добиться? Разве подобные инциденты в отношении разработчиков должны становиться
нормальным риском работы в криптоиндустрии? Или чтобы создавать финансовые продукты нужно обеспечивать себе физическую охрану / жестко сохранять анонимность или противостоять вооружённым преступникам?
Мы считаем, что у индустрии пока нет универсального ответа на эти вопросы. И что искать его исключительно в архитектуре смарт-контрактов недостаточно.И, возможно, произошедшее - ещё один аргумент в пользу полноценной интеграции децентрализации в правовое поле. Важно, чтобы такие проекты могли легально работать и развиваться, сохраняя свои ключевые принципы: независимость от посредников, прозрачность и распределённый контроль, но иметь доступ к тем же механизмам защиты, которыми пользуются участники традиционного финансового рынка
