В статье поговорим о проблемах безопасности блокчейн-проектов, пришедших из мира Web 2.0. В этой области отсутствует сложившаяся практика, поэтому в публичной плоскости крайне мало сведений о механизмах защиты, используемых этими проектами. Статья является более подробным вариантом доклада с прошедшего киберфестиваля Positive Hack Days 12 на эту же тему.

Опыт, накопленный при проведении пентестов, и понимание сетевых технологий помогли мне провести исследование атак на блокчейн-проекты, проведенных с использованием техник DNS hijacking и BGP hijacking. Вы узнаете, как перехват пользовательского трафика приводит к тому, что пользователи теряют криптовалюту. Кроме того, в этой статье:
разберем, как злоумышленники проводили атаки на сетевом уровне (благодаря открытым данным восстановим многие шаги атак буквально по минутам);
декомпилируем смарт-контракты атакующих;
выясним, какие публичные механизмы защиты внедрили пострадавшие проекты и что с ними не так;
попробуем улучшить механизмы обнаружения рассмотренных атак и защиты от них, а также рассмотрим обозреватели блокчейнов (выясним, как найти в блокчейне контракты злоумышленника, зная только один из них);
поговорим о том, какие шаги необходимо предпринять держателям криптовалют, чтобы не стать очередными жертвами.
Введение​
В 2022 году не менее 20 различных блокчейн-проектов стали целью атак DNS hijacking и BGP hijacking. Эти атаки приводили к перенаправлению трафика пользователей проектов (Allbrigde, Celer Network, Ribbon Finance, Convex Finance и других) на подконтрольные злоумышленникам серверы. Согласно статистике компании SlowMist, специализирующейся на безопасности блокчейн-технологий, ущерб от подобных инцидентов в 2022 году составил не менее 3 млн долларов (при поиске по ключевому слову DNS). В некоторых случаях ущерб пользователям возместили сами DeFi-компании, которые таким образом хотели минимизировать репутационные издержки.

Несмотря на различные нюансы, у всех рассматриваемых атак DNS hijacking и BGP hijacking есть общие черты. Во всех случаях:
производился несанкционированный выпуск SSL-сертификатов;
осуществлялась подмена адресов контрактов легитимных проектов, куда пользователи переводили средства, взаимодействуя с поддельным сайтом атакованного проекта;
средства на контрактах проектов не были затронуты.
Обычно адреса контрактов, к которым обращаются пользователи, указываются в коде веб-приложения (например, вот так).

Рисунок 1. Адрес контракта в коде веб приложения
Поэтому для подмены адресов злоумышленники создавали копии сайтов и вносили на них изменения в адреса контрактов.

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

Успешности атак способствовали следующие факторы:
плохой UX- и UI-дизайн криптокошельков (например, у MetaMask);
схожее написание адресов контрактов у легитимных проектов и у злоумышленников (в некоторых случаях);
медленная реакция атакованных компаний на инцидент.
Злоумышленники добиваются схожести сайтов, используя генераторы адресов (на основе технологии vanity address). С их помощью они могут создать адрес контракта, первые и последние символы которого соответствуют нужному шаблону.

В статье будем рассматривать браузерную версию MetaMask, так как он является одним из самых популярных браузерных криптокошельков. Здесь и далее будем говорить про плагин MetaMask для браузеров.

Из-за низкого качества UX и UI в MetaMask отображается лишь часть адреса. Рассмотрим на примере MetaMask версии, актуальной на время атак (версия 10.25.0). На картинке ниже (см. рис. 2) видно, что в поле отображается не весь адрес, а лишь несколько первых и последних символов. Учитывая возможности генерации злоумышленником нужного адреса при создании контракта, это окно будет выглядеть абсолютно так же, как и при использовании легитимного адреса.

Рисунок 2. При подтверждении транзакции MetaMask показывает адрес не полностью

При этом у пользователя есть возможность посмотреть в окне дополнительную информацию перед подтверждением своей транзакции. Нажав на кнопку (см. рис. 3) рядом с фрагментом адреса, пользователь может открыть сайт в блокчейн-обозревателе, где будет указан полный адрес и его принадлежность к проекту (см. рис. 4).
Рисунок 3. Кнопка рядом с фрагментом адреса
Рисунок 3. Кнопка рядом с фрагментом адреса

Рисунок 4. В блокчейн-обозревателе можно посмотреть полный адрес транзакции

При этом нажатие на кнопку View full transaction details в окне MetaMask (см. рис. 2), наоборот, путает пользователя: адрес контракта опять отображается не полностью и невозможно определить, совпадают ли адреса легитимного и вредоносного контрактов.

Рисунок 5. При нажатии View full transaction details показывается неполный адрес контракта

Изменение в современной версии MetaMask. В версии 10.30.4 интерфейс изменился: адрес снова отображается не полностью.

Но, если по нему кликнуть (хотя приложение никак не подсказывает эту возможность), мы увидим полный адрес

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

В большинстве рассматриваемых случаев атака оказывалась успешной благодаря изменению DNS-записей (подробнее про DNS hijacking можно почитать здесь), которое приводило к перенаправлению трафика пользователей, обращавшихся к атакованному доменному имени (сайту), на IP-адрес, контролируемый злоумышленником. Исключение составляли специфические атаки, основанные на использовании техники BGP hijacking. В этом случае менялся не сам IP-адрес, а маршрут к нему. Контроль над трафиком, связанным с DNS-записями, позволял выпустить несанкционированный сертификат через центры сертификации. Одна из проверок, выполняемых таким центром, основана на контроле доменного имени пользователем, запросившим выпуск подтверждающего документа. Сертификат, выпущенный таким способом, признавался браузерами легитимным, поэтому при посещении сайта атакованного проекта пользователям не показывались предупреждения.

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

Далее будут рассмотрены некоторые из пострадавших проектов и предложены рекомендации по усилению эффективности защиты.

Celer Network (cBridge)​
За пять дней до атаки (12.08.2022) злоумышленник создал контракты в разных блокчейн-сетях. Адреса этих контрактов впоследствии были опубликованы в телеграм-канале атакованной компании. Ниже приведены ссылки на контракты в обозревателях соответствующих блокчейнов:
Ethereum: 0x2A2aA50450811Ae589847D670cB913dF763318E8 (ликбез по использованию обозревателя Etherscan)
BSC: 0x5895da888Cbf3656D8f51E5Df9FD26E8E131e7CF
Fantom: 0x458f4d7ef4fb1a0e56b36bf7a403df830cfdf972
Polygon: 0x9c8b72f0d43ba23b96b878f1c1f75edc2beec9f9
Avalanche: 0x9c8B72f0D43BA23B96B878F1c1F75EdC2Beec9F9
Arbitrum: 0x9c8B72f0D43BA23B96B878F1c1F75EdC2Beec9F9
Astar: 0x9c8B72f0D43BA23B96B878F1c1F75EdC2Beec9F9
Aurora: 0x9c8b72f0d43ba23b96b878f1c1f75edc2beec9f9
Optimism: 0x9c8b72f0d43ba23b96b878f1c1f75edc2beec9f9
Metis: 0x9c8B72f0D43BA23B96B878F1c1F75EdC2Beec9F9
Адреса контрактов, использованных злоумышленником, совсем не похожи на адреса, используемые атакованным проектом.

17.08.2022 примерно в 19:25 (здесь и далее указано время UTC) произошел инцидент с использованием техники BGP hijacking. Время инцидента зафиксировано в сервисе bgplay (см. рис. 5). Этот сервис позволяет визуализировать информацию о распространении и удалении маршрутов через протокол BGP, а также изменение этой информации во времени. Длительность воздействия с применением BGP hijacking составила около четырех часов (примерно до 23:13, см. рис. 6).

Рисунок 6. Время завершения атаки BGP hijacking

Технические подробности использования BGP hijacking в данном инциденте можно найти в отчете компании SlowMist, которая специализируется на безопасности блокчейн-решений.

Изменение маршрута в результате инцидента позволило атакующему выпустить сертификат. С помощью сервиса crt.sh можно установить, что сертификат для домена cbridge-prod2.celer.network выпущен 17.08.2022 в 19:42:27 и отозван 18.08.2022 в 09:10:12. Таким образом, атакующий, используя BGP hijacking, перенаправлял посетителей сайта на свой веб-сервер. При этом благодаря сертификату, выпущенному злоумышленником, браузеры не показывали пользователям предупреждения о проблемах безопасности (подобные предупреждения выдаются, когда есть основания не доверять сертификату сайта).

С 22:33:30 17.08.2022 до 01:17:22 18.08.2022 в сети Ethereum атакующий вывел имеющиеся средства в криптомиксер Tornado Cash, совершив в общей сложности 15 транзакций, и перестал пользоваться кошельком с адресом 0xb0f5fa0cd2726844526e3f70e76f54c6d91530dd, так как использование криптомиксера позволяет злоумышленнику создать новый криптокошелек, в котором можно получить средства от криптомиксера в зачет ранее предоставленных средств (подробнее о работе криптомиксера Tornado Cash).

В обозревателе Etherscan можно декомпилировать байт-код контракта злоумышленника, размещенный в блокчейне Ethereum, нажав на соответствующую кнопку. В этом случае декомпилированный код будет представлен в синтаксисе языка Vyper. Мне больше нравится синтаксис Solidity, поэтому я декомпилировал код в сервисе dedaub.com. Можно увидеть, что в контракте злоумышленника присутствуют те же функции с тем же количеством и типом параметров, что и в контракте проекта cBridge, найденном через документацию проекта. В частности функции send() и sendNative(). В декомпилированном контракте не отображается значение переменной _addNativeLiquidity, так как оно задавалось в конструкторе при размещении контракта. Но, это значение можно увидеть, посмотрев изменение состояния после транзакции в сервисе Tenderly либо в обозревателе Etherscan. Значение совпадает с адресом лица, создавшего контракт: 0xb0f5fa0cd2726844526e3f70e76f54c6d91530dd.

Таким образом, в строке 12 декомпилированного байт-кода контракта видно, что при вызове sendNative() происходит перевод нативной валюты блокчейна (в данном случае — ETH) на адрес злоумышленника. Строка 37 и строка 62 показывают, что через функцию send() переводились токены.

В декомпилированном контракте злоумышленника также содержится функция 0x9c307de6(). Она нужна для перевода токенов с адреса жертвы, когда жертва ошибочно выдает разрешение контракту атакующего через Approve. В обозревателе Etherscan видно, что злоумышленник трижды вызывал эту функцию (один, два, три). Пострадавшие пользователи перед этими транзакциями выполняли Approve на адрес контракта злоумышленника (один, два). Самый первый вызов 0x9c307de6() произошел еще до атаки на проект, через две минуты после размещения контракта. Видимо, злоумышленник хотел убедиться, что контракт работает как задумано.

19.08.2022 компания Celer Network сообщила, что приняла меры защиты, не раскрывая подробностей: «Добавлены активные проверки целостности фронтенда и DNS для предотвращения подобных атак».

Компания SlowMist оценила ущерб в 128,4 ETH (запись от 18.08.2022). В отчете SlowMist указано, что многие проекты больше не подвержены подобной атаке, однако уязвимые проекты все еще остаются. При этом не приводится никаких подробностей о том, что позволило сделать такой вывод и какие меры защиты следует предпринять.

Mad Meerkat Finance​
В случае с Mad Meerkat Finance атакующий смог получить доступ к параметрам DNS провайдера и заменить IP-адрес доменного имени сайта на подконтрольный ему адрес. По оценке пострадавшей компании, ущерб составил 2 000 000 долларов США. Согласно отчету компании, инцидент произошел 04.05.2022 в 19:28. Вероятно, компания указала в качестве времени начала атаки время первой транзакции на адрес атакующего в блокчейне Cronos. Но, атака случилась несколько раньше. Ведь транзакция — это уже последствие атаки. В сервисе crt.sh можно выяснить, что сертификат был выпущен 04.05.2022 в 19:25 для домена mm.finance. Сертификат не был отозван и перестал быть доверенным лишь по истечении срока действия (02.08.2022).

Первое сообщение об атаке компания разместила в Твиттере 04.05.2022 в 10:51, то есть спустя 3,5 часа с момента атаки. Отчет об инциденте также был опубликован на rekt.news. Согласно этому отчету, атака продолжалась около трех часов, прежде чем атакованная компания выключила фронтенд. Я не нашел упоминания о выключении фронтенда — только твит о готовности его выключить. В любом случае по транзакциям видно, что 4 и 5 мая пользователи активно взаимодействовали с контрактом злоумышленника. А две последние транзакции были совершены 6 и 11 мая. При этом в отчете Mad Meerkat Finance от 05.05.2023 указано, что компания уже предприняла шаги по недопущению развития атаки злоумышленником. И транзакции 6 и 11 мая — наглядный пример неэффективности этих мер. Причина — в отсутствии отзыва сертификатов, выпущенных злоумышленником и в естественной задержке при обновлении DNS-записей (подробнее в разделе «Рекомендации по усилению эффективности защиты»).

Я декомпилировал байт-код контракта злоумышленника в сервисе dedaub.com. В контракте удалось найти те же функции с тем же количеством и типом параметров, что и в контракте проекта. В декомпилированном контракте не отображается значение переменной __addLiquidityETH, так как оно задавалось в конструкторе при размещении контракта. В обозревателе Cronoscan невозможно посмотреть изменение состояния при размещении. Это значение можно увидеть, посмотрев изменение состояния после транзакции в сервисе Tenderly: 0xb3065fe2125c413e973829108f23e872e1db9a6b.

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

Allbridge​
Инцидент произошел в результате несанкционированного доступа к DNS-записям провайдера Namecheap, услугами которого пользовалась компания Allbridge. Впоследствии CEO Namecheap Ричард Киркендалл признал проблему, сообщив, что компания выявила скомпрометированного агента по обслуживанию клиентов и удалила полномочия по изменению DNS-записей, ранее выданные этому сотруднику. Компания Allbridge не привела данные об ущербе, заявив только, что пострадало довольно мало пользователей. Несмотря на это, с технической точки зрения этот инцидент представляет интерес.

В сервисе сrt.sh можно выяснить, что 23.06.2022 в 08:09 злоумышленником был выпущен сертификат для домена app.allbridge.io. Cертификат не был отозван и перестал быть доверенным лишь по истечении срока действия (21.09.2022).

Пострадавшая компания сообщила в Твиттере, что об атаке им стало известно в 12:00, то есть примерно через четыре часа после выпуска сертификата злоумышленником (видимо, об этом шаге атакующего компания не догадывалась).

Злоумышленник создал контракты в разных блокчейнах (Ethereum, Binance Smart Chain, Polygon), адреса которых похожи на адрес контракта Allbridge. Некоторые адреса злоумышленника были приведены в посте в официальном телеграм-канале проекта.

Можно заметить, что адреса контрактов злоумышленником генерировались целенаправленно: чтобы первые и последние символы адреса совпадали с адресами контрактов проекта.
Адрес контракта проекта Allbridge в блокчейне Ethereum​
Адрес контракта злоумышленника в блокчейне Ethereum ​
0xBBbD1BbB4f9b936C3604906D7592A644071dE884​
0xbbbd2ed360dac9f6e005fc6a4398d7d6beabe884​
​
​
Адрес контракта проекта Allbridge в блокчейне Binance Smart Chain​
Адрес контракта злоумышленника в блокчейне Binance Smart Chain​
0xBBbD1BbB4f9b936C3604906D7592A644071dE884​
0xbbbd2ec2dc8c067b7e0dc403ecae865466d7e884​
​
​
Адрес контракта проекта Allbridge в блокчейне Polygon​
Адрес контракта злоумышленника в блокчейне Polygon​
0xBBbD1BbB4f9b936C3604906D7592A644071dE884​
0xbbbd2139ed16a4075df7c303d8d69e6413f3e884​

Контракт 0xbbbd2ed360dac9f6e005fc6a4398d7d6beabe884 в блокчейне Ethereum был создан 20.06.2022. Учитывая сходство адреса с адресом атакованного проекта, можно предположить, что злоумышленник начал готовиться к атаке с этого дня.

Команда пострадавшего проекта сообщила, что сменила провайдера DNS и внедрила новые протоколы безопасности, не раскрывая подробностей.

Один из пользователей в официальном телеграм-канале проекта Allbridge указал на транзакцию в сети Binance Smart Chain в день инцидента (через 2,5 часа после выпуска сертификата злоумышленником) с выдачей разрешения через Approve адресу, очень похожему на адрес контракта проекта — 0xbbbde5d09e0ac4c32938efa3cbc0cb55d5c7e884. Но на данный момент в обозревателе нет транзакций по этому адресу. Возможно, при атаке злоумышленник ошибся и указал на фронтенде неверный адрес. Было бы интересно узнать, какой адрес действительно был указан злоумышленником на фронтенде, например воспользовавшись сервисом онлайн-архива снапшотов сайтов WayBackMachine. Но на этом сервисе нет снапшота за интересующую нас дату (23.06.2022).

Самое интересное, что Approve не был отозван, в чем можно убедиться, обратившись к функции allowance в обозревателе по адресу токена USDC. Таким образом, если у адреса 0xbbbde5d09e0ac4c32938efa3cbc0cb55d5c7e884 в будущем появится владелец, теоретически он сможет вывести все USDC-токены с адреса 0x32ac4fd012f0d455e5bb9394d0355e571d86f022 (см. рис. 7). Но, для этого ему нужно будет как-то узнать, на каком токене выдан Approve: так как токены стандартов ERC20 и BEP20 никак не оповещают получателя о выданном ему через Approve полномочии.

Рисунок 7. Разрешение на использование токена USDC, выданное адресу, у которого нет владельца

Похожая ситуация возникла у пользователя 0x624301090700ea1e3c5b5224f89adfae405412c1: он выдал Approve контракту злоумышленника 23.06.2022, и почти через сутки злоумышленник воспользовался этим, забрав все доступные на тот момент токены ABR. При этом жертва до сих пор не отозвала Approve. Это означает, что этот пользователь может снова стать целью атаки, если на его счету будут токены ABR. В этом можно убедиться, обратившись к функции allowance в обозревателе по адресу токена ABR (см. рис. 8).

Рисунок 8. Выданное разрешение на использование токена ABR не отозвано жертвой

Мне не удалось определить, на какой IP-адрес злоумышленник поменял указание доменного имени (app.allbridge.io) и через сколько времени была устранена подмена, поскольку сервисы поиска по истории изменений IP-адреса DNS History, SecurityTrails, RiskIQ, VirusTotal, Censys не показали никаких изменений в соответствующем промежутке (второй половине июня 2022 года). Возможно, у этих сервисов такой же механизм наполнения истории, как у SafeDNS, и запись для доменных имен появляется не за каждый день: «The accuracy of the SafeDNS threat intelligence system is achieved through the company’s own technology for automatic categorization of internet resources and one for detection of botnets and malicious sites. To add data to Octopus we also use DNS requests collected via the SafeDNS cloud service, over 1B requests processed daily. By now the company has 180M domains in web crawler index and 1.2B records of passive DNS data».

Ribbon Finance​
Этот инцидент произошел вследствие несанкционированного доступа к DNS-записям провайдера Namecheap, услугами которого пользовалась компания Ribbon Finance. Компания сообщила, что количество пострадавших пользователей невелико. Один из них потерял 16,5 BTC.

Через сервис crt.sh можно выяснить, что 23.06.2022 в 06:28 злоумышленником был выпущен сертификат для домена app.ribbon.finance.

Сертификат не был отозван и перестал быть доверенным лишь по истечении срока действия (21.09.2022). Злоумышленник создал контракт, адрес которого похож на адрес контракта проекта. Адрес контракта атакующего найден через твит компании SlowMist, указавшей транзакцию атакующего. Злоумышленник вывел средства после того, как пострадавший выдал Approve его контракту.
Адрес контракта проекта Ribbon Finance в блокчейне Ethereum​
Адрес контракта злоумышленника в блокчейне Ethereum ​
0x65a833afDc250D9d38f8CD9bC2B1E3132dB13B2F​
0x65a8ec2c367a2d60efc1944c6eab614d73453b2f​
Какие методы предприняты компанией в целях своевременного обнаружения и защиты от подобных атак в будущем выяснить не удалось.

Convex Finance​
Этот инцидент произошел вследствие несанкционированного доступа к DNS-записям провайдера Namecheap, услугами которого пользовалась Convex Finance. Согласно отчету пострадавшей компании, потери от атаки составили 15,968 токена cvxCRV и 433 токена CRV. Компания сообщила, что атаке DNS hijacking подвергся домен convexfinance.com. На самом деле не только он. Через сервис crt.sh можно выяснить, что 23.06.2022 злоумышленник выпустил сертификаты для двух доменов: convexfinance.com в 00:58 и wwwconvexfinance.com в 01:15.

Сертификаты не были отозваны и перестали быть доверенными лишь по истечении срока действия (20 и 21 сентября 2022), несмотря на то, что один из пользователей указал на отсутствие отзыва сертификата в комментариях к твиту компании Convex Finance об инциденте.

В отчете Convex Finance указано, что компания узнала о контракте злоумышленника, адрес которого похож на адрес контракта проекта, из твита пользователя 23.06.2023 в 23:00 — спустя 10 часов с момента выпуска сертификата злоумышленником.
Адрес контракта проекта Convex Finance в блокчейне Ethereum​
Адрес контракта злоумышленника в блокчейне Ethereum​
0xf403a2c10b0b9fef8f0d4f931df5d86ad187ae31​
0xF403C135812408BFbE8713b5A23a04b3D48AAE31​
Контракт был создан злоумышленником за три дня до атаки (20.06.2022). Учитывая сходство адреса с адресом атакованного проекта, можно предположить, что злоумышленник готовился к атаке начиная с этого дня.
Компания сообщила, что начала «активно отслеживать изменение DNS» (вероятно, для того, чтобы вовремя обнаруживать несанкционированные изменения в будущем).

Общее в атаках Allbridge, Ribbon Finance и Convex Finance​
Помимо регистратора Namecheap, у этих атак есть и другие общие особенности. В процессе их изучения я решил поискать в обозревателе Etherscan контракты с одинаковыми байт-кодами. За основу взял один из уже известных контрактов (0xbbbd2ed360dac9f6e005fc6a4398d7d6beabe884), использованный злоумышленником при атаке на Allbridge. Удалось найти еще 15 таких контрактов. Все они созданы в промежутке с 20.06.2022 по 22.06.2022.
Адрес контракта в блокчейне Ethereum​
Примечание​
0x8014ae6574cace1f2435a86d4ea0472f466786ae
0x8014fb4882b1f99a3e60aece1d39400560d986ae
0xcf50193c27df08423bfe813676541b2268789332​
Похож на адрес контракта CRV Depositor из проекта Convex: 0x8014595F2AB54cD7c604B00E9fb932176fDc86Ae
Похож на адрес контракта CVX Rewards из проекта Convex: 0xCF50b810E57Ac33B91dCF525C6ddd9881B139332​
0xf403a2c10b0b9fef8f0d4f931df5d86ad187ae31​
Ранее рассматривался при описании атаки на проект Convex. Похож на адрес контракта Booster: 0xF403C135812408BFbE8713b5A23a04b3D48AAE31​
0x65a8135596ae13c0dd5c17ba1059c61bc42d3b2f
0x65a8e56ee6b549456fd8927db3fa526b8d143b2f​
Похож на адрес контракта из проекта Ribbon Finance: 0x65a833afDc250D9d38f8CD9bC2B1E3132dB13B2F​
0xbbbd2ed360dac9f6e005fc6a4398d7d6beabe884 (атака на Allbridge)​
Ранее рассматривался при описании атаки на проект Allbridge​
0xbbbd89e4cd6c0ac07f164b84546b6439d415e884​
Похож на адрес контракта из проекта Allbridge:
0xBBbD1BbB4f9b936C3604906D7592A644071dE884​
0x7d2740418e8dc4f8de88ead063f737b93d58c7a9
0x7d27e89cf5981cf6827a6195928169ebd885c7a9
0xccf4a3a9adf9b2cf594e02e3ef4929dfaa1edd6a
0x917598efb39ccd3271f0f8abf717d1d2bc3399b6
0x685bd1d8747c91151f0b98ea8e5c6275994293af
0x5d3ada4aa5bf6125a091b27ed8cbc94518633643
0x4da2ca63312464f675cb3d04a7a79e5c4f2270f5 0x7b85d24d2d0de912acadeaa019277ee0e7b6209c
Не встречались при анализе инцидентов​
В списке присутствуют контракты, фрагменты адресов которых (начало и конец) похожи на контракт, задействованный в атаке на Ribbon Finance. При этом тело контракта существенно отличается от тела контракта, использованного в той же самой атаке. Помимо этого, время операций с этими контрактами предшествует времени выпуска сертификатов. Возможно, злоумышленник таким образом репетировал будущую атаку.

Часть контрактов, например 0x8014ae6574cace1f2435a86d4ea0472f466786ae и 0x8014fb4882b1f99a3e60aece1d39400560d986ae, имеют характерный общий признак: первые и последние символы одинаковы. Они не встречались ранее в этой статье, так как, по-видимому, применялись в аналогичных атаках на другие криптопроекты, которые также пользовались услугами регистратора Namecheap. Эти атаки не рассматриваются в статье.

Я декомпилировал код контракта злоумышленника с помощью онлайн-утилиты Dedaub. Анализ декомпилированного кода показывает, что средства с вредоносного контракта переводились на адрес 0xcdc0f019f0ec0a903ca689e2bced3996efc53939 через функцию deposit() (см. рис. 9).

Рисунок 9. Функция deposit() декомпилированного кода контракта злоумышленника

Причем переводились те активы, которые стали доступны из-за невнимательности пользователей, разрешивших контракту злоумышленника распоряжаться своими средствами в MetaMask. Это невозможно определить в обозревателях транзакций, таких как Ethereum Blockchain Explorer, если смотреть по адресу злонамеренного контракта. В обозревателях можно увидеть лишь вывод средств с контракта, который злоумышленнику удалось произвести только благодаря разрешению на использование средств.

Рисунок 10. В обозревателях транзакций по адресу злонамеренного контракта не отображаются транзакции с разрешениями от жертв

Атакующий вывел бо́льшую часть средств (201 ETH) с кошелька 0xcdc0f019f0ec0a903ca689e2bced3996efc53939 в блокчейне Ethereum 24.06.2022 в Tornado Cash тремя разными транзакциями. Последней транзакцией от 27.06.2022 совершен перевод 17,39 ETH через мост Multichain на тот же адрес кошелька, но уже в блокчейне Binance Smart Chain. Затем средства с кошелька в Binance Smart Chain были снова переведены в Tornado Cash, после чего злоумышленник перестал пользоваться кошельками.

В рамках атаки на Allbridge 23.06.2022 в блокчейне Polygon был создан контракт (0xbbbd2139ed16a4075df7c303d8d69e6413f3e884), который не совпадает побайтово с вышеприведенными, хотя при декомпиляции он отличается всего лишь наличием одной неиспользуемой переменной (см. рис. 11)

Рисунок 11. Небольшое изменение приводит к невозможности поиска похожих контрактов в обозревателях транзакций
Тем не менее из-за этого незначительного изменения данный контракт не отображается в списке ранее найденных 15-и.

Недостатки общедоступных методов защиты​
Мне удалось найти всего 1 вариант решения проблемы. CEO deBridge Finance Алексей Смирнов предложил разработчикам два bash-скрипта для мониторинга изменений кода на фронтенде и записей DNS. Учитывая трудности в доступом к твиттеру в РФ, публикую код скриптов:

#!/bin/bash cd /tmp wget -r -k -l 7 -p -E -nc -nv https://$1/ 1>&2 2>/dev/null || true find $1 -type f | grep -v robots.txt | xargs md5sum | md5sum | cut -d\ -f1
#!/bin/bash date >> /tmp/dns_$1.log host $1 | grep address | awk '{print $NF}' | sort | uniq | xargs echo | tee -a /tmp/dns_$1.log > /tmp/dns_new_$1 if [ $? -eq 0 ] then cp /tmp/dns_new_$1 /tmp/dns_$1 else echo 'Resolve ERROR' >> /tmp/dns_$1.log fi cat /tmp/dns_$1

Эта связка может не сработать при атаке BGP hijacking: при ней DNS-записи не меняются, а скрипт мониторинга фронтенда не учитывает приоритет IPv6 над IPv4 по умолчанию во многих операционных системах. Если фронтенд расположен на целевом домене, имеющем адреса IPv6 и IPv4, и сервер, с которого будет запускаться скрипт, также имеет адреса IPv6 и IPv4, проверка всегда будет происходить только по адресу IPv6 (если этот адрес доступен). При этом в ходе атаки BGP hijacking маршрут мог быть перенастроен только для адресов IPv4.

Рисунок 12. Из-за приоритета IPv6 над IPv4 утилита Wget обращается к сайту только по IPv6

Если же использовать только скрипт мониторинга изменений фронтенда, можно пропустить не только BGP hijacking, но и DNS hijacking. Во-первых, это может произойти из-за приоритета IPv6 над IPv4 (если в DNS hijacking изменяются только DNS-записи для IPv4) (см. рис. 12). Во-вторых, из-за отсутствия опции --no-dns-cache будет происходить обращение к устаревшим закэшированным записям DNS.

Рекомендации разработчикам по усилению эффективности защиты​
Разработчикам необходимо следить за выпуском новых сертификатов, изменениями DNS-записей, а также за изменениями целостности файлов фронтенда в части адресов контрактов. Последнее нужно делать учитывая приоритет IPv6 над IPv4. Т.е. нужно 2 отдельных скрипта: один для IPv6, другой - для IPv4 (для wget это опции --inet4-only и --inet6-only).

Кроме того, разработчикам следует выбрать DNS-регистратора, поддерживающего CAA-запись. В частности, необходимо использовать CAA-запись с заданием account, если поставщик SSL-сертификата предоставляет такую возможность (см. RFC6844). В этом случае злоумышленник не сможет выпустить сертификат (если только у него не получится изменить CAA-запись). Эта мера обеспечивает защиту от атак с использованием техники BGP hijacking.

Рекомендуется выбирать DNS-регистратора, поддерживающего расширенные возможности защиты домена. Например, у некоторых регистраторов есть собственные SOC-команды, отслеживающие различные атаки, в том числе попытки BGP hijacking, и несанкционированное изменение записей DNS. При попытке смены параметров регистратор инициирует связь с владельцем по нескольким каналам.

В случае несанкционированного выпуска сертификата необходимо немедленно принять меры по его отзыву. Невыполнение этого предоставляет злоумышленнику дополнительное время на атаку. Эта рекомендация связана с кэшированием записей DNS как в браузерах, так и на роутерах (в т.ч. домашних) и DNS-серверах. Например, для домена itnan.ru одно из значений времени обновления записи в кэше DNS, полученное от DNS-сервера Яндекса (77.88.8.8) через утилиту dig, составляет около 20 часов (см. рис. 13).

Кроме того, даже малое время значений времени обновления записи в кэше DNS может привести к существенным задержкам распространения обновления для DNS записей (до нескольких дней). Подробнее об этом можно почитать в статьях:
«Подробное руководство по настройке TTL для записей DNS»;
«Что происходит, когда вы обновляете свой DNS».
Предположим, что владельцы домена стали жертвой атаки DNS hijacking, в ходе которой атакующие выпустили сертификат для домена. В какой-то момент владельцы домена обнаружили атаку и восстановили записи DNS, но не стали отзывать выпущенный злоумышленником сертификат. Это приведет к тому, что некоторые пользователи в течение нескольких часов (или даже нескольких дней) будут попадать на сайт злоумышленника. Браузер не будет предупреждать их о не доверенном сертификате. Очистка локального кэша DNS в операционной системе пользователя не решит проблему. Даже если значение TTL для записи DNS изначально было небольшим (например, несколько минут), все равно необходимо отозвать сертификат. Кроме того, получив доступ к панели управления DNS-записями, злоумышленники могут увеличить значение параметра TTL.

Помимо этого, существуют атаки, способные подменить запись о доменном имени. Например, DNS cache poisoning; периодически появляется информация об уязвимостях этого типа в сетевом оборудовании. Например, в 2019 году подобная уязвимость была найдена в операционной системе RouterOS 6.45.6, которая используется в роутерах MikroTik. Также возможна атака «человек посередине» на пользователей, которые не используют DNSSEC.

Для проверки выпуска новых сертификатов можно сделать следующее: сначала получить текущую хеш-сумму записей о сертификатах для домена (вместо DOMAIN вставить свое доменное имя). Лучше использовать формат JSON для уменьшения объема получаемых данных.

wget -O DOMAIN -nv "https://crt.sh/?CN=DOMAIN&output=json" 1>&2 2>/dev/null | md5sum DOMAIN >DOMAIN.md5

Далее необходимо сравнить значения с эталоном:

wget -O DOMAIN -nv "https://crt.sh/?CN=DOMAIN&output=json" 1>&2 2>/dev/null | md5sum DOMAIN|md5sum -c DOMAIN.md5

У этого способа есть нюансы. Во-первых, сервис crt.sh может периодически не работать. Во-вторых, опыт показал, что при выпуске нового сертификата на сайте появляется 2 записи. Сначала появляется запись типа precertificate и только через некоторое время, в дополнение к precertificate, появляется новая запись типа leaf certificate. Возможно, лучшим решением будет независимый мониторинг записей CT Logs.

Кроме того, нужно своевременно обновлять серверное ПО при угрозах несанкционированного изменения данных фронтенда или доступа к сертификатам HTTPS. Также отзывать сертифкаты при появлении угроз их компрометации. Для этого требуются специалисты, которые имеют навыки инвентаризации используемого серверного ПО и анализа угроз эксплуатации этого ПО. Например, разные уязвимости CVE-2014-0160 и CVE-2019-9621 приводят в т.ч. к компрометации сертификата (в первом случае из-за чтения памяти процесса, во втором - из-за возможности доступа к файлам сервера). Обновление ПО для устранения уязвимости не отменяет факта возможной утечки сертификата. Если для осуществления атаки не потребуется заново выпускать сертификат (из-за компрометации), задача атакующего упростится. Кроме того, методы мониторинга выпуска новых сертификатов пропустят такую атаку. Поэтому специалисты помимо обновления ПО в таких случаях должны в обязательном порядке отзывать сертификаты. По этой же причине разумно срок действия сертификата ограничить несколькими месяцами.

автор Игорь Агиевич aka shanker
Cпециалист по безопасности распред реестров в Positive Technologies