Когда выполняются взломы?
Набор данных недостаточно велик, чтобы вывести значимые тенденции из распределения по времени. Но мы видим, что различные типы атак чаще происходят в разное время.
Май 2021 года стал рекордным по количеству экосистемных атак. В июле 2021 года было больше всего атак на логику протокола. В декабре 2021 года было больше всего атак на инфраструктуру. Трудно сказать, совпадают ли эти кластеры, или это случаи одного успешного удара, вдохновляющего одного и того же актера или других, чтобы сосредоточиться на определенных категориях.
Эксплойты на уровне языка смарт-контрактов были самыми редкими. Этот набор данных начинается в 2020 году, когда большинство эксплойтов в этой категории уже были хорошо известны и, скорее всего, были пойманы на ранней стадии.
Распределение похищенных средств во времени имеет четыре основных пика.
В августе 2021 года наблюдается пик, вызванный взломом Poly Network.
Еще один большой всплеск в декабре 2021 года вызван большим кластером инфраструктурных взломов, где были скомпрометированы закрытые ключи, например, 8ight Finance, Ascendex и Vulcan Forged.
Затем мы видим исторический максимум в марте 2022 года из-за взлома Ronin.
Последний всплеск вызван атакой на мост Binance.
Где осуществляются взломы?
Я сегментировал набор данных в зависимости от того, на какой цепочке был размещен контракт или кошелек, с которого были украдены средства. Наибольшее количество взломов пришлось на Ethereum - 45% от группы выборки. Смарт-цепочка Binance (BSC) была на втором месте с 20%.
Это объясняется рядом факторов:
Наибольший объем похищенных средств был у Ethereum ($2B). BSC заняла второе место ($878M). Взломы, в результате которых средства были похищены на Ethereum, BSC и Polygon в одном событии, заняли третье место ($689M). В основном это связано с атакой Poly Network.
Взломы, связанные с мостами или многоцепочечными приложениями (например, многоцепочечные свопы или многоцепочечное кредитование), оказали огромное влияние на набор данных. Несмотря на то, что на долю этих взломов пришлось всего 10% событий, на них пришлось $2,52 млрд похищенных средств.
Как предотвратить взломы?
Для каждого уровня стека угроз существуют инструменты, которые мы можем использовать для раннего выявления потенциальных векторов атак и предотвращения их использования.
Инфраструктура
Большинство крупных взломов инфраструктуры связаны с получением хакерами конфиденциальной информации, например, закрытых ключей. Следование хорошим практикам операционной безопасности (OPSEC) и регулярное моделирование угроз снижает вероятность этого. Команды разработчиков, использующие эффективные процессы OPSEC, будут:
Инструменты Fuzzing, такие как Echidna, проверяют, как смарт-контракт реагирует на широкий набор случайно сгенерированных транзакций. Это хороший способ обнаружить крайние случаи, когда определенные входные данные приводят к неожиданным результатам.
Статический анализ
Инструменты статического анализа, такие как Slither и Mythril, автоматически обнаруживают уязвимости в смарт-контрактах. Эти инструменты отлично подходят для быстрого выявления общих уязвимостей, но они могут выявить только набор заранее определенных проблем. Если в смарт-контракте есть проблема, которой нет в спецификации инструмента, она не будет замечена.
Формальная верификация
Инструмент формальной верификации, например Certora, сравнивает смарт-контракт со спецификацией, написанной разработчиками. В этой спецификации подробно описывается то, что должен делать код, и его желаемые свойства. Например, разработчик, создающий приложение для кредитования, может указать, что каждый кредит должен быть обеспечен достаточным залогом.
Если какое-либо из возможных действий смарт-контракта не соответствует спецификации, формальный верификатор выявит это нарушение.
Слабость формальной проверки заключается в том, что тест хорош настолько, насколько хороша спецификация. Если предоставленная спецификация не учитывает определенные модели поведения или слишком много разрешает, то процесс проверки не выявит всех ошибок.
Аудит и экспертная оценка
Во время аудита или экспертной оценки доверенная группа разработчиков тестирует и проверяет код проекта. Аудиторы пишут отчет с подробным описанием найденных уязвимостей и рекомендациями по устранению этих проблем.
Приглашение стороннего эксперта для проверки контрактов - это отличный способ выявить ошибки, которые были упущены первоначальной командой. Однако аудиторы тоже люди, и они никогда не смогут уловить все. Кроме того, вы должны верить, что если аудитор обнаружит проблему, он сообщит вам об этом, а не будет использовать ее самостоятельно.
Экосистемная атака
Несмотря на то, что экосистемные атаки являются наиболее распространенным и разрушительным вариантом, в арсенале средств безопасности не так много инструментов для предотвращения подобных эксплойтов.
Автоматизированные инструменты безопасности сосредоточены на поиске ошибок в одном контакте за раз. Аудит обычно не учитывает, как может быть использовано взаимодействие между несколькими протоколами в экосистеме.
Инструменты мониторинга, такие как Forta и Tenderly Alerts, могут дать раннее предупреждение, когда происходит атака на композитность, чтобы команда могла принять меры. Но во время атаки на флэш-кредитование средства обычно похищаются в ходе одной транзакции, поэтому любое предупреждение придет слишком поздно, чтобы предотвратить огромные потери.
Модели обнаружения угроз могут использоваться для поиска вредоносных транзакций в mempool, где транзакции находятся до того, как узел их обработает, но хакеры могут обойти эти проверки, отправляя свои транзакции напрямую майнерам с помощью таких сервисов, как flashbots.
Будущее безопасности
Имеется два прогноза относительно будущего криптобезопасности:
Лучшие команды перейдут от отношения к безопасности как к практике, основанной на событиях (тестирование -> экспертная оценка -> аудит), к отношению к ней как к непрерывному процессу. Они будут:
Набор данных недостаточно велик, чтобы вывести значимые тенденции из распределения по времени. Но мы видим, что различные типы атак чаще происходят в разное время.
Май 2021 года стал рекордным по количеству экосистемных атак. В июле 2021 года было больше всего атак на логику протокола. В декабре 2021 года было больше всего атак на инфраструктуру. Трудно сказать, совпадают ли эти кластеры, или это случаи одного успешного удара, вдохновляющего одного и того же актера или других, чтобы сосредоточиться на определенных категориях.
Эксплойты на уровне языка смарт-контрактов были самыми редкими. Этот набор данных начинается в 2020 году, когда большинство эксплойтов в этой категории уже были хорошо известны и, скорее всего, были пойманы на ранней стадии.
Распределение похищенных средств во времени имеет четыре основных пика.
В августе 2021 года наблюдается пик, вызванный взломом Poly Network.
Еще один большой всплеск в декабре 2021 года вызван большим кластером инфраструктурных взломов, где были скомпрометированы закрытые ключи, например, 8ight Finance, Ascendex и Vulcan Forged.
Затем мы видим исторический максимум в марте 2022 года из-за взлома Ronin.
Последний всплеск вызван атакой на мост Binance.
Где осуществляются взломы?
Я сегментировал набор данных в зависимости от того, на какой цепочке был размещен контракт или кошелек, с которого были украдены средства. Наибольшее количество взломов пришлось на Ethereum - 45% от группы выборки. Смарт-цепочка Binance (BSC) была на втором месте с 20%.
Это объясняется рядом факторов:
- Ethereum и BSC имеют наибольший показатель Total Value Locked (средства, размещенные в приложениях), поэтому размер приза для хакеров крупнее именно на этих цепочках.
- Большинство разработчиков криптовалют знают Solidity, язык смарт-контрактов, используемый на Ethereum и BSC, и существует более сложный инструментарий, поддерживающий этот язык.
Наибольший объем похищенных средств был у Ethereum ($2B). BSC заняла второе место ($878M). Взломы, в результате которых средства были похищены на Ethereum, BSC и Polygon в одном событии, заняли третье место ($689M). В основном это связано с атакой Poly Network.
Взломы, связанные с мостами или многоцепочечными приложениями (например, многоцепочечные свопы или многоцепочечное кредитование), оказали огромное влияние на набор данных. Несмотря на то, что на долю этих взломов пришлось всего 10% событий, на них пришлось $2,52 млрд похищенных средств.
Как предотвратить взломы?
Для каждого уровня стека угроз существуют инструменты, которые мы можем использовать для раннего выявления потенциальных векторов атак и предотвращения их использования.
Инфраструктура
Большинство крупных взломов инфраструктуры связаны с получением хакерами конфиденциальной информации, например, закрытых ключей. Следование хорошим практикам операционной безопасности (OPSEC) и регулярное моделирование угроз снижает вероятность этого. Команды разработчиков, использующие эффективные процессы OPSEC, будут:
- идентифицировать конфиденциальные данные (закрытые ключи, информация о сотрудниках, ключи API и т.д.)
- Определять возможные угрозы (социальные атаки, технические эксплойты, внутренние угрозы .и т.д.)
- Определять лазейки и слабые места в существующих средствах защиты.
- Определять уровень угрозы для каждой уязвимости
- Создавать и реализовать план по снижению угроз.
Инструменты Fuzzing, такие как Echidna, проверяют, как смарт-контракт реагирует на широкий набор случайно сгенерированных транзакций. Это хороший способ обнаружить крайние случаи, когда определенные входные данные приводят к неожиданным результатам.
Статический анализ
Инструменты статического анализа, такие как Slither и Mythril, автоматически обнаруживают уязвимости в смарт-контрактах. Эти инструменты отлично подходят для быстрого выявления общих уязвимостей, но они могут выявить только набор заранее определенных проблем. Если в смарт-контракте есть проблема, которой нет в спецификации инструмента, она не будет замечена.
Формальная верификация
Инструмент формальной верификации, например Certora, сравнивает смарт-контракт со спецификацией, написанной разработчиками. В этой спецификации подробно описывается то, что должен делать код, и его желаемые свойства. Например, разработчик, создающий приложение для кредитования, может указать, что каждый кредит должен быть обеспечен достаточным залогом.
Если какое-либо из возможных действий смарт-контракта не соответствует спецификации, формальный верификатор выявит это нарушение.
Слабость формальной проверки заключается в том, что тест хорош настолько, насколько хороша спецификация. Если предоставленная спецификация не учитывает определенные модели поведения или слишком много разрешает, то процесс проверки не выявит всех ошибок.
Аудит и экспертная оценка
Во время аудита или экспертной оценки доверенная группа разработчиков тестирует и проверяет код проекта. Аудиторы пишут отчет с подробным описанием найденных уязвимостей и рекомендациями по устранению этих проблем.
Приглашение стороннего эксперта для проверки контрактов - это отличный способ выявить ошибки, которые были упущены первоначальной командой. Однако аудиторы тоже люди, и они никогда не смогут уловить все. Кроме того, вы должны верить, что если аудитор обнаружит проблему, он сообщит вам об этом, а не будет использовать ее самостоятельно.
Экосистемная атака
Несмотря на то, что экосистемные атаки являются наиболее распространенным и разрушительным вариантом, в арсенале средств безопасности не так много инструментов для предотвращения подобных эксплойтов.
Автоматизированные инструменты безопасности сосредоточены на поиске ошибок в одном контакте за раз. Аудит обычно не учитывает, как может быть использовано взаимодействие между несколькими протоколами в экосистеме.
Инструменты мониторинга, такие как Forta и Tenderly Alerts, могут дать раннее предупреждение, когда происходит атака на композитность, чтобы команда могла принять меры. Но во время атаки на флэш-кредитование средства обычно похищаются в ходе одной транзакции, поэтому любое предупреждение придет слишком поздно, чтобы предотвратить огромные потери.
Модели обнаружения угроз могут использоваться для поиска вредоносных транзакций в mempool, где транзакции находятся до того, как узел их обработает, но хакеры могут обойти эти проверки, отправляя свои транзакции напрямую майнерам с помощью таких сервисов, как flashbots.
Будущее безопасности
Имеется два прогноза относительно будущего криптобезопасности:
Лучшие команды перейдут от отношения к безопасности как к практике, основанной на событиях (тестирование -> экспертная оценка -> аудит), к отношению к ней как к непрерывному процессу. Они будут:
- Выполнять статический анализ и fuzzing для каждого дополнения к основной - кодовой базе.
- Проводить формальную проверку при каждом крупном обновлении.
- Устанавливать системы мониторинга и оповещения с ответными действиями (приостановка всего приложения или конкретного модуля, который был затронут).
- Выделять несколько членов команды для создания и поддержки автоматических систем безопасности и планов реагирования на атаки.
Безопасность - это не набор галочек, которые нужно заполнить и отложить в сторону. Работа по обеспечению безопасности не должна заканчиваться после проведения аудита. Есть много случаев, таких как взлом моста Nomad, когда эксплойт был основан на ошибке, внесенной в обновление после аудита.
Процесс реагирования сообщества криптобезопасности на взломы станет более организованным и упорядоченным. Каждый раз, когда происходит взлом, участники наводняют групповые чаты криптозащиты, желая помочь, но отсутствие организации означает, что важные детали могут быть потеряны в хаосе.