Вариант задействования блокчейна криптовалют как среды передачи команд для элементов бот-сети

    Хотелось бы развить мысль, упомянутую в статье «Follow the money: как группировка RTM стала прятать адреса C&C серверов в криптокошельке», которая упаковывала их в количество перечисленных за две транзакции сатоши на определенный криптоадрес. Вредонос, запросив у блокчейн-обозревателя данные переводов на такой адрес, путем несложных манипуляций выделял IP нового C&C сервера.

    Опустим и осудим преступные намерения этой группировки и остановимся именно на принципах и процессе передачи команд элементам бот-сети (ЭБС).

    ИМХО, данный способ имеет определенные недостатки – пропускная способность данного метода (в отношении количества информации на один перевод) мала, а любой, кто знает такой криптоадрес, может отправить на него определенную сумму, и засинкхоллить бот-сеть, заставив ее обращаться к «доверенному» для них серверу.

    Однако скрытые команды ЭБС возможно отправлять не на отдельный, а с отдельного адреса А, априори доверенного для них. В этом случае никто (кроме лица, обладающего приватным ключом), не может провести такую операцию.

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

    При этом команда до 20 байт (буквы, цифры, спецсимволы) преобразуется (text to hex) в hex и далее – в валидный криптоадрес B. При этом сама команда может кодироваться/шифроваться.

    Приведу фантазийный пример. Для наглядности (PoC) пользовался рядом доступных онлайн-сервисов.

    1. С доверенного адреса А проводится перевод определенной суммы на сгенерированный валидный адрес B.

    Пример генерации адреса B: необходимо отправить для ЭБС информацию о сервере 82.192.95.175, с которого возможно получить команду на обновление с сервера модуля #68, время активации / деактивации модуля, а также ключ шифрования (или адрес дополнительного блокчейн-обозревателя, команду на выполнение не позднее передаваемой даты, новый доверенный криптоадрес, ключ и т.д. и т.п. (ключ возможно зашить в ПА и передавать только при необходимости его смены, тем самым сохранив 7 байт поля команд)).

    IP возможно преобразовать сотней способов, например 082.192.095.175 > 08.21.92.09.51.75 + 32 к каждому числу (избегаем нечитаемых символов ASCII).

    Итого 40.53.124.41.83.107 = (5|)Sk представляем в ASCII (6 байт);
    Команда 68 = D;

    Время активации модуля – 601234 = в Unix time, где старший разряд 1 избыточен, передавать его не будем (он по умолчанию, т.к. изменение на 2 будет только в 2033 году), младшие три разряда также по умолчанию 000, т.к. особого значения не имеют, это +- 15 минут.

    Время активации – 1601234000 = 27 сентября 2019 г. 19.13.20 GMT

    Далее четыре цифры, до какого времени выполнять работу модуля – 0365 (дней) от времени активации.

    То есть 6012340365 = 01665D088Dh = AAHpKn в ASCII. Также допустим, что прошлый ключ был Key0001.

    Итого (5|)SkDAAHpKnKey0002 с использованием RC4 и ключом Key0001 дает в hex: DD F6 B8 16 2A B6 71 97 0F 9F A2 68 79 11 8C B6 31 DA FE 43.

    Эту строку преобразуем hashtoaddress в legacy btc-адрес (можно в адреса других криптовалют dash, ltc, dogecoin и т.д., это не принципиально, алгоритмы формирования криптоадресов открыты, перевод будет дешевле и быстрее).

    Получаем адрес B (legacy) – 1MEdtjmGtqaGPaoYAQn43dkZxiSrSD8gmD.
    (напомню, что в нем спереди добавлен один «1» — байт-признак, в конце – контрольные 4 байта).

    Этот ресурс дает возможность воочию увидеть пошаговый процесс преобразования (вставляем DDF6… в строку 3 (RIPEMD-160 Hash of 2)).



    Однако, чтобы не выделяться из множества адресов уже ставшего стандартным segwit-формата, представим нашу строку как (смотрите здесь).



    Адрес B (segwit) – bc1qmhmts932kecewrul5f58jyvvkcca4ljrrgmpcd

    2. На данный адрес с доверенного A отправляем перевод в несколько сотен/тысяч сатоши. Сумма перевода также может нести информацию (например, доппроверку по согласованному признаку, командный символ на безусловное уничтожение/временное прекращение работы ботсети без необходимости чтения передаваемой в адресе команды и т.п.).
    Отдельно обращу внимание, что при отправке надо учитывать, что адрес для сдачи должен быть тем же, что и адрес отправки, либо записывать ЭБС адрес для сдачи, как новый доверенный.
    Транзакция подтверждается в среднем несколько минут (при условии оплаты достаточной суммы комиссии, плавающей в зависимости от нагрузки сети).

    Стоимость перевода суммы в 1 тыс. сатоши составит 7 руб. (плюс комиссия 2-3 руб.). Повторюсь, что с другими криптовалютами это может быть быстрее и дешевле в десятки/сотни раз.

    3. Со стороны ЭБС происходит периодичный опрос блокчейн-обозревателей (по API) из имеющегося списка (обозреватели представлены в широком ассортименте) о переводе с А.
    При выявлении факта отправки новой транзакции с А (и ее подтверждении) информация, содержащаяся в адресе-получателе, на который был проведен перевод, дешифруется (декодируется) полученным ключом и принимается к исполнению.

    Допустим, что доверенный адрес — bc1qsj0gm0r2c3hzq9yzfewl34yk2r760hy5za4x3q (segwit-формат).
    По этому адресу последняя исходящая транзакция (прим. — уже не последняя, а эта) проходила на два адреса — bc1qmhmts932kecewrul5f58jyvvkcca4ljrrgmpcd и сдачи, аналогичному адресу отправки.
    Перечисленная сумма – 666 сатоши – решим, что это условная команда на выполнение декодирования.



    Декодируем наш адрес обратно в DDF6….
    Преобразуем к виду (5|)SkD34,,+!Key0002 и дешифруем ключом Key0001 (ключ меняется на Key0002).

    Скачиваем модуль с сервера (доступ на сервер может быть реализован с использованием того же ключа) и ожидаем даты запуска модуля.

    Отмечу, что необходимо использовать как минимум несколько обозревателей (могут отключаться или ограничивать запросы из некоторых стран, как например bitflyer.jp, ограничивающий с российского и пускающий с японского IP).


    Полученную информацию возможно проверять как минимум еще на одном/двух. Выбор обозревателей велик, только в типовом списке Electrum присутствует более десятка – blockchair.com, smartbit.com.au, bitupper.com, chain.so и мн. др.



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

    Пример отправки с доверенного адреса в старом формате 186A8D7vdAHpFWdSAFHzZGfi44pPcwtZNc на сгенерированный legacy-адрес в raw



    и segwit-адрес



    Применением различных блокчейн-обозревателей подчеркиваю их разнообразие.
    Напомню, что скрытое сообщение в адресе из транзакции подделать, чтобы она была подтверждена, невозможно по определению.

    Плюсы алгоритма


    1. С2-сервер отсутствует, обращения идут к блокчейн-обозревателям.
    2. Команды для ЭБС являются безусловно доверенными.
    3. Средой передачи команд является блокчейн, что не позволяет заблокировать отправку/передачу команд.
    4. Блокчейн — крайне устойчивая система (это не касается волатильности криптовалют).
    5. Низкая стоимость обеспечения работы.
    6. Несложная реализация алгоритма (открытые исходные данные и код).
    7. Нет необходимости генерировать транзакции или скачивать блокчейн.

    Особенности алгоритма


    1. Симплексная связь.
    2. Зависимость от стабильности функционирования обозревателей.
    3. Определенные (хоть и минимальные) финансовые затраты.

    Полагаю, некоторые приведенные здесь моменты полезно учесть специалистам по ИБ.

    Интересно было бы для повышения устойчивости бот-сети, кроме обозревателей, привлекать возможности полных нод или нод популярных кошельков типа электрума, а также организовать дуплексную связь за счет генерации необходимых транзакций на стороне ЭБС. Буду признателен мыслям на этот счет, а также обоснованной критике и предложениям.
    • +10
    • 1,5k
    • 3
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 3

      +1
      Гораздо более логичным и простым вариантом кажется создание Ethereum смарт контракта, который принимает команды в чистом виде без особых заморочек с кодированием данных
        0

        Спасибо, Не исключаю, но для этого что должно быть в коде эбс? Типовые стандартные или демон/клиент ethereum?

          0
          Можно ведь делать запросы к api etherscan (или вообще просто парсить страничку) как это делает и автор в статье для запроса данных из биткоина. Или, например, воспользоваться одним из вариантов публичной ноды, например Infura, там достаточно уметь в WebSocket.

          Кстати, с учётом последнего варианта, можно для передачи команд использовать протокол Whisper из Ethereum или его аналог из других платформ

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

        Самое читаемое