Сигурност на крипто борси: 25 контрола от реални кражби
Alexander Sverdlov
Основател и главен консултант по киберсигурност - CISSP, CEH, CHFI, Mandiant
25 контрола, извлечени от документирани кражби
Опазването на частния ключ не стига, ако нападателят може да накара оторизиран подписващ да одобри грешната транзакция. Почти всяка голяма загуба на борса през последните четири години опира до това изречение.
Крипто индустрията прекара десетилетие в решаване на проблема с пазенето на ключове и го реши сравнително добре. HSM устройства, прагово подписване, мулти-сиг портфейли, церемонии на изолирани машини: криптографията в общи линии издържа. И парите пак излязоха.
Излязоха, защото атаката се премести. Вместо да краде ключ, нападателят се научи да кара легитимния притежател на ключа да подпише грешното нещо. Подписът е валиден. Кворумът е изпълнен. Одитният лог показва трима оторизирани души, одобрили транзакция. А средствата ги няма, защото това, което тримата са видели на екрана, не е това, което са подписали.
По-долу са 25 технически контрола, подредени по частта от бизнеса, която пазят. Извлечени са от документирани инциденти при борси, кустодиани, производители на портфейли, мостове и търговски фирми. Където причината още се оспорва, описан е наблюдаваният провал, без да се вменява вина. Няма публичен източник, който покрива всеки пробив, така че приемете това за видимия модел, а не за пълния списък.
Основната идея
Допускането, което се счупи
Портфейл 3 от 5 доказва, че три ключа са произвели подписи. Не доказва, че трима души независимо са проверили накъде отиват парите. Ако и тримата четат транзакцията от един и същ интерфейс и този интерфейс е компрометиран, портфейлът работи точно както е проектиран, докато се изпразва.
Точно това се случи при Bybit, където разследващите откриват подменен JavaScript, сервиран през инфраструктурата на Safe. Същото описват подписващите при Radiant, където компрометирани устройства показват легитимни детайли, докато се подписват зловредни транзакции. WazirX съобщава за разминаване между показаното и подписаното съдържание, макар отговорността там да остава оспорвана.
Подписът никога не беше слабото място. Екранът беше.
Общата нишка през Bybit, Radiant и оспорваната хронология на WazirX
Доказателствата
Шест начина, по които парите излязоха
Подреждането на инцидентите по нападател или по блокчейн не казва почти нищо. Подреждането по път на провала казва какво да тествате. Шест пътя покриват документираните загуби.
| Път на провала | Какво се обърка | Документирани инциденти |
|---|---|---|
| Подписващи одобриха зловредни действия | Показаното и полезният товар се разминаха | Bybit, WazirX (оспорвано), Radiant |
| Доставчик стигна до контрола над активите | Трета страна можеше да подмени транзакция или събитие | DMM Bitcoin (308 млн. USD), JumpCloud, KelpDAO |
| Ключове или права стигаха твърде далеч | Идентификационни данни пазеха власт извън предназначението си | Binance (7 000 BTC), Wintermute, Ronin (пет от девет ключа) |
| Дистрибуцията на софтуер се счупи | Публикуваният код или API тайните не бяха това, което клиентите очакваха | Ledger Connect Kit, 3Commas |
| Валидни действия създадоха невалидна стойност | Веригата прие съобщения, които не биваше да съществуват | Nomad, BNB bridge, Resolv |
| Счетоводни или пазарни допускания паднаха | Балансите, цените или финалността не бяха това, което системата вярваше | QuadrigaCX, Mango Markets, Ethereum Classic |
Източниците са публикуваните post-mortem доклади, регулаторни решения и доклади на разследващи, актуални към септември 2026 г.
Контроли 1 до 8
Съхранение и власт над транзакциите
1. Сложете твърд лимит на загубата за всяко ниво
Определете горещ, топъл и студен по максималната стойност, която всеки може да загуби, а не по име или мрежова свързаност. Налагайте баланси по актив, тавани на транзакция, лимит на изходящите за 24 часа и скорост на зареждане извън приложението на портфейла. Ако горещ портфейл бъде компрометиран, балансът плюс позволеното зареждане трябва да е максималната правдоподобна загуба.
Тествайте: Опитайте се да изпразните портфейл с много малки преводи от различни акаунти.
2. Дръжте подписващите ключове в независимо контролирани граници
Използвайте неекспортируеми HSM ключове или прегледан дизайн за прагово подписване. Разпределете дяловете при различни администратори, устройства, мрежи и процедури за възстановяване. Три дяла, контролирани през един доставчик на идентичност или един облачен администратор, са един домейн на компрометиране с маскировка. NIST SP 800-57 описва жизнения цикъл на ключовете.
Тествайте: Може ли един облачен администратор, CI акаунт или доставчик да събере достатъчно власт, за да подпише.
3. Разделете кворума за подписване от кворума за ауторизация
Независима услуга за политики трябва да одобри бизнес намерението, преди подписващ изобщо да получи заявка. Не позволявайте подателят, администраторът на политиката и подписващите да споделят една привилегирована среда.
Тествайте: Компрометиране на доставчика на идентичност, който удостоверява и трите роли.
4. Проверявайте байтовете за подпис с отделен декодер
От неподписания полезен товар извлечете независимо chain ID, адрес на портфейла, nonce, тип операция, to, value, селектор на функция, декодирани аргументи и хеш на транзакцията. Сравнете ги с отделно одобрена инструкция за превод. Покажете това тълкуване на доверено устройство или независим канал, никога само на сайта, който предлага транзакцията. Отхвърляйте непознат calldata, вложени извиквания и всеки изглед, който не може да покаже съществените ефекти. EIP-712 описва обвързване с домейн чрез полета като chainId и verifyingContract.
Тествайте: Подмяна на calldata зад изглед, който изглежда идентичен.
5. Дайте на трежъри портфейлите ограничителна политика
Рутинен превод от студен към топъл трябва да позволява само очаквания токен контракт, селектора transfer, одобрен получател, диапазон на сумата, верига и времеви прозорец. Третирайте DELEGATECALL, произволни групови извиквания, одобрения на токени, промени на модули, смяна на собственици и ъпгрейди като отделни управленски операции. Симулирайте точната сурова транзакция преди подпис.
Тествайте: Подмяна на рутинен превод с ъпгрейд на портфейла или одобрение на токен.
6. Забавете опасните промени така, че подписващите да не могат да го заобиколят
Сложете timelock и отделен път за одобрение върху ъпгрейди на имплементацията, смяна на подписващи, модули, guards, одобрения за харчене на токени и смяна на верификатори на мостове. Наблюдавайте както събитията за ъпгрейд, така и самия EIP-1967 слот за имплементация. Guard на портфейла не стига, ако същите собственици могат да го изключат.
Тествайте: Може ли съществуващият кворум да изключи guard-а и да изпразни трезора в една транзакция.
7. Тествайте възстановяването на ключове така внимателно, както генерирането
Генерирайте ключове с прегледани източници на ентропия; забранете генератори на vanity адреси и внесени ключове с неизвестен произход. Wintermute е предупредителният случай: вероятно слаб vanity ключ, който все още държеше права върху трезора. При смяна на съмнителен ключ премахнете и ролите и разрешенията му в контрактите, не само парите.
Тествайте: Може ли старият адрес още да администрира трезор, след като балансът му е нула.
8. Ползвайте отделни устройства за подписване с малко софтуер
Дръжте инструменти за разработка, лична поща, чат, разширения за браузър и изтеглен код извън устройствата за подписване. Ограничете изходящите връзки, изисквайте управляван firmware и наблюдение, и алармирайте при нови процеси, разширения, сесии за отдалечен контрол и промени в софтуера на портфейла.
Тествайте: Работна станция, която показва легитимен превод, но подава различен calldata.
Контроли 9 до 16
Хора, доставчици и доставка на софтуер
9. Третирайте фронтенда като част от границата на подписване
Фиксирайте прегледани билдове и скриптове на трети страни за оперативно подписване; проверявайте хеша на доставения артефакт извън облачния акаунт, който го сервира. Алармирайте при промени в обектното хранилище, CDN, DNS, JavaScript бъндъли и самоличностите, на които е позволено да публикуват. Легитимен URL и валидна HTTPS връзка не спряха зловредния код, сервиран на подписващите в Bybit.
Тествайте: Може ли облачна сесия, която променя активите на сайта, да промени и това, което вижда екипът.
10. Одитирайте какво може да причини доставчикът, не какво твърди, че пази
Картографирайте всеки доставчик с достъп до създаване на транзакции, изгледи за подписване, RPC отговори, администрация на идентичности, управление на портфейли или деплой. Питайте дали компрометиран служител или сесия може да подмени транзакция или да върне фалшиво събитие от веригата. KelpDAO е примерът: компрометирани RPC възли и един верификатор, приел фалшифицирано събитие.
Тествайте: Зловреден, но коректно удостоверен отговор от всеки доставчик.
11. Правете привилегированите сесии кратки и отменяеми
Изисквайте устойчив на фишинг WebAuthn за облак, идентичност, CI, съхранение и публикуване на пакети. Обвържете рисковите сесии с управлявани устройства и ползвайте роли при поискване. Смяната на парола или добавянето на MFA не изгонва нападател с активна сесия. Репетирайте отнемането на сесии; вижте NIST SP 800-63B за устойчивост на фишинг.
Тествайте: Отнемане на всички активни сесии под напрежение и доказване, че е подействало.
12. Ограничете атаките през фалшиви обяви за работа и тестови задачи
Разработчиците и операторите на портфейли трябва да отварят непоискани репозитории, интервю задачи и търговски инструменти само в еднократни среди без корпоративни сесии, идентификационни данни, SSH agent, софтуер за портфейли или маршрут към продукция. Това не е теория: ФБР приписва кражбата от 308 млн. USD от DMM Bitcoin на служител на доставчик на портфейли, компрометиран през фалшив тест за работа.
Тествайте: Реакцията при компрометирана браузър сесия на разработчик.
13. Изисквайте контролирани и възпроизводими релийзи към пакетните регистри
Билдвайте от прегледани комити, заключвайте зависимостите, проверявайте произхода на билда и публикувайте през CI самоличност с краткотрайни данни. Премахвайте напускащите от npm и други външни услуги още при офбординга: инцидентът с Ledger Connect Kit започва с акаунт на бивш служител, публикувал зловредни версии.
Тествайте: Може ли сесия на бивш служител още да публикува нова версия.
14. Ограничете API ключовете на клиенти и партньори
Разделете обхватите за четене, търговия, превод и теглене; по подразбиране ключовете за търговия на трети страни да нямат право на теглене. Добавете кратък срок, бързо отнемане, разрешени IP диапазони и лимити по обем и пазар. Засичайте самотъргуване и рязка концентрация в неликвидни двойки: ключ само за търговия пак може да извлече стойност през нарочно лоши сделки.
Тествайте: Може ли изтекъл ключ само за търговия да изнесе стойност през неликвиден пазар.
15. Проектирайте поддръжката за подкупен вътрешен човек
Давайте на агентите маскирани баланси и минимума лични данни, нужни за случая. Заключвайте пълните снимки на документи, историята на акаунта и масовите заявки зад достъп по конкретен случай с кратък срок. Поддръжката не бива да може сама да маха задържане на теглене или да ресетва фактор с висока сигурност.
Тествайте: Колко данни може да събере един агент за една смяна.
16. Направете възстановяването на акаунт неспособно да движи активи веднага
Смяна на парола, устройство, passkey, създаване на API ключ или възстановяване с помощ от поддръжката трябва да задейства задържане на тегленията и известие по предварително регистрирани канали. Изисквайте по-строги проверки за нов получател, отколкото за повтарящ се.
Тествайте: Превземане на акаунт веднага след възстановяване с помощ от поддръжката.
Контроли 17 до 21
Депозити, баланси и търговия
Тук борсата спира да прилича на портфейл и започва да прилича на банка. Провалите в тази част не са криптографски. QuadrigaCX не загуби ключ от нападател; записваше баланси, които никога не са били покрити. Това е провал на счетоводен контрол и завърши с доклад на регулатора в Онтарио, а не с форензичен доклад.
17. Ползвайте append-only двустранно счетоводство за клиентите
Всеки депозит, сделка, такса, вътрешен превод и теглене трябва да създава балансирани записи с уникален ID на събитието. Администратор на база данни или търговска услуга не бива да може да създаде похарчим клиентски баланс, редактирайки един ред. Твърдете, че задълженията към клиенти плюс собствените баланси са равни на контролираните активи след чакащите движения.
Тествайте: Неоторизирани кредити през админ интерфейса, базата и консуматора на събития.
18. Изравнявайте задължения и активи независимо и често
Възстановявайте балансите от журнала на събитията и сравнявайте по актив и верига с независимо заявени баланси, чакащи тегления, извлечения от кустодиани и известни тежести. Алармирайте при несъответстващи транзакции, отрицателни сметки, остаряло изравняване и всеки ръст на задълженията без ауторизиран входящ актив. Снимка за proof of reserves без пълни и актуални задължения не установява нищо за покритието.
Тествайте: Дали изключенията ги преглежда отделен екип, или екипът, който ги създава.
19. Обвържете кредитирането на депозити с финалността на конкретната верига
Не ползвайте един фиксиран брой потвърждения за всички активи. Следете каноничния блоков хеш и позицията на транзакцията, засичайте реорганизации, отменяйте временни кредити и блокирайте тегления срещу депозити, загубили финалност. Ethereum Classic е референтният случай: дълбоки реорганизации с двойно харчене.
Тествайте: Дълбок реорг срещу депозити, вече изтъргувани в други активи.
20. Разпознавайте активите по верига и контракт, не по тикер
Процесорът на депозити трябва да изисква очакваното chain ID, токен контракт, финализирана транзакция, успешно изпълнение и реален ефект върху баланса. Обработвайте изрично токени с такса при превод, rebase, прокси контракти, десетични знаци и специфики на веригата. Третирайте всеки нов листван актив като нов код с отделен лимит на загубата, докато не бъде тестван.
Тествайте: Дублирани събития, премахнати логове, неуспешни извиквания и два токена с един символ.
21. Допуснете, че ценовият източник може да отчете реална сделка на манипулирана цена
За маржин, кредитиране и деривати ползвайте независими площадки, проверки за свежест, тегло по ликвидност, ленти на отклонение и лимити колко бързо може да расте стойността на обезпечението. В случая Mango Markets сделки на три източникови борси докарват отчетено поскъпване над тринайсет пъти за 30 минути. Всяка отделна сделка е била истинска.
Тествайте: Състезателен тест, в който един търговец движи всички пазари, които подават цената.
Контроли 22 до 25
Вериги, контракти и реакция
22. Проверявайте събитията от мостове независимо, преди да освободите стойност
Обвържете всяко съобщение с източниковата и целевата верига, излъчващия контракт, събитието, nonce, сумата, получателя и финализирания блок; наложете еднократна консумация. Изисквайте независима верификаторска инфраструктура и проверявайте инварианта на стойността. Nomad пропуска недоказани съобщения през проверка с нулев корен; BNB bridge приема фалшифициран Merkle proof.
Тествайте: Верификатор, който подава правдоподобни, но несъществуващи блокове от източниковата верига.
23. Тествайте финансовите инварианти, включително в старите контракти
За всеки път на mint, burn, swap, дял в трезор или такса напишете свойства като assets_out <= assets_available. Fuzz-вайте максимални цели числа, активи с малко десетични знаци, прах по сметките, посока на закръгляне, reentrancy и операции, финансирани с flash loan. Truebit е препълване на цяло число в по-стар контракт; Balancer V1 е дефект в закръглянето на неподдържан пул. Инвентаризирайте наследените контракти дори когато никой не ги поддържа.
Тествайте: Същите свойства срещу байткод, за който вече нямате изходния билд.
24. Наблюдавайте промените във властта извън системата, която наблюдавате
Ползвайте независими възли и доставчици на данни, за да следите собственици на портфейли, модули, guards, слотове за имплементация, одобрения на токени, роли за mint, верификатори на мостове и изходящи потоци по актив. Съпоставяйте ги със заявките и вътрешния счетоводен журнал. Подписана транзакция без одобрено намерение трябва да задейства автоматично задържане.
Тествайте: Работи ли наблюдението, след като основният кустодиан или RPC клъстер е компрометиран.
25. Репетирайте спирането на кражба, докато нападателят още има достъп
Поддържайте тествани превключватели за тегления, депозити, търговия по актив, API ключове, зареждане на горещи портфейли, освобождаване от мостове и функции на контракти. Проведете учение, което започва с компрометирана сесия: отнемете сесиите, спрете подписването, запазете логовете и суровите данни, сменете ролите, изравнете балансите и рестартирайте по един актив. Уговорете предварително контакти с кустодиани, големи борси и органите.
Тествайте: Времето от първата неоторизирана транзакция до наложеното ограничаване. Запишете числото.
Приоритети
Откъде да започнете и защо точно тези шест
Двайсет и пет контрола са програма, не спринт. Тествайте първо 4, 5, 9, 17, 18 и 24. Заедно те отговарят на най-съществения въпрос пред една борса: може ли някой да накара привидно оторизирано действие да движи или създава активи, без независима система да докаже, че действието отговаря на реално задължение към клиент или на трежъри операция?
Логиката на групата си струва да се каже изрично. Контроли 4 и 5 карат подписващия да вижда истината и ограничават какво приема трежъри портфейлът. Контрол 9 маха допускането, че интерфейсът, който доставя транзакцията, е доверен. Контроли 17 и 18 значат, че ако стойност все пак се движи, книгите не могат тихо да се нагласят. Контрол 24 значи, че алармата не зависи от системите, които нападателят вече контролира.
Неудобното следствие: ако в момента не можете да отговорите на този въпрос с доказателства, останалите деветнайсет контрола намаляват риск върху основа, която не сте проверили. Пак си струва. Но не е същото като да знаете.
Регулация
Как това изглежда под MiCA и DORA
За доставчиците на услуги за криптоактиви в ЕС голяма част от горното спря да е по избор. MiCA вкарва лицензираните CASP в надзорен режим с изрични изисквания за съхранение и разделяне на клиентските активи. DORA слага отгоре правилата за оперативна устойчивост на финансовия сектор: рамка за управление на ИКТ риска, регистър на информацията за ИКТ доставчиците, класификация и докладване на инциденти по часовник и тестване с водене от заплахи за субектите, които попадат в критериите.
Съответствието е по-близко, отколкото повечето екипи очакват. Контрол 10, одитът какво може да причини доставчикът, е управление на риска от трети страни по DORA с по-остър въпрос. Контрол 18 е това, което изглежда задължението за разделяне на клиентски активи, когато е внедрено, а не декларирано. Контрол 25 е изискването за тестване на реакцията, но измерено.
Разглеждаме регулаторната страна отделно в материалите за изискванията по DORA и изискванията по NIS2, а тестовата страна в услугата ни за тестове за проникване.
Въпроси
Най-често задаваните въпроси
Ползваме известен кустодиан. Това важи ли и за нас?
Да, и контрол 10 става най-важният. Кустодианът намалява риска от управление на ключове и добавя доставчик, който, ако бъде компрометиран, може да влияе какво подписвате или какво вярвате, че е отчела веригата. DMM Bitcoin загуби 308 млн. USD през служител на доставчик, не през счупен ключ.
Мулти-сиг достатъчен ли е?
Мулти-сиг отговаря на един въпрос: колко ключа са подписали. Не отговаря дали подписващите са видели истинския получател, дали споделят компрометиран интерфейс и дали същият кворум може да изключи собствения си guard. Контроли 3, 4 и 6 съществуват, защото отговорът и на трите многократно е бил не.
Колко време отнема внедряването на всичките 25?
За борса със съществуваща инфраструктура очаквайте три до шест месеца, докато контроли 4, 5, 9, 17, 18 и 24 бъдат реално тествани, и дванайсет до осемнайсет месеца за целия набор заедно с инвариантите в контрактите и ученията.
Кой от тези би спрял кражбата при Bybit?
Основно контрол 4, с контрол 9 като подкрепящ. Независим декодер, който показва истинския получател на устройство, до което предлагащият интерфейс няма достъп, чупи пътя на атаката, защото подписващият сравнява два източника.
Не сме борса, а фонд или трежъри. Отнася ли се за нас?
Разделът за съхранение, почти изцяло. Контроли от 1 до 8 и 24 важат за всеки, който държи активи под кворум за подписване. Разделите за депозити и счетоводство имат значение само ако държите баланси на други хора.
Коя е най-честата пропусната мярка?
Подписващи, които четат транзакцията от същия интерфейс, който я е предложил, без независимо декодиране никъде по пътя. Среща се в повечето първи оценки и е точно пропускът, който всички инциденти от първия ред на таблицата са използвали.
Започнете от въпроса, не от списъка
Може ли привидно оторизирано действие да движи активите ви, без независима система да докаже, че трябва?
Тестваме точно този въпрос: пътя на подписване, политиката на трежъри портфейлите, границата на фронтенда, счетоводния журнал и наблюдението, което трябва да оцелее при компрометиран доставчик. Над 200 оценки на сигурността в 14 държави от 2013 г.
Говорете с нас за преглед на съхранениетоили вижте как тестваме
Александър Свердлов
Основател на Atlant Security, сертифициран по CISSP, CEH, CHFI и Mandiant. Автор на 2 книги за информационна сигурност, лектор по киберсигурност на най-големите конференции по киберсигурност в Азия и панелист на конференция на ООН. Бивш член на екипа за консултации по сигурността на Microsoft, външен консултант по киберсигурност в Емиратската корпорация за ядрена енергия.