- Регистрация
- 24.11.2016
- Сообщения
- 706
- Репутация
Хорошая статья, оригинал тут:
Создание анонимного двустороннего канала связи — постоянная головная боль для разработчиков вредоносного ПО. В этой статье мы на примерах разберем, как сервисы, разработчики которых используют недостаточно сильную защиту, могут превратиться в такой канал.
Как только не изворачиваются злоумышленники, чтобы скрытно передавать данные между малварью и командным центром (C&C, или, как их теперь модно называть на военный лад, C2). Сторонние сервисы здесь зачастую представляются самым удобным вариантом. В ход идут твиты, коммиты на GitHub или отдельные репозитории; даже комменты к видео на YouTube могут оказаться тайными посланиями между машинами. Использование таких сервисов открывает для оператора ботнета новые возможности. В частности, он может не беспокоиться о смене адресов управляющих серверов — достаточно просто оставить твит, в приложенной к которому картинке будет содержаться актуальная информация.
У одностороннего канала связи есть свои недостатки. Во-первых, такого бота легче выявить по образцу трафика. Во-вторых, аккаунт на сервисе могут заблокировать или он может попасть в поле зрения исследователей. Это сильно затруднит дальнейшие операции.
Создание безопасного двустороннего канала связи с использованием сторонних сервисов — задача нетривиальная. Если не прибегать к каким-либо хакам, то все, что можно предпринять в таком случае, — это раздать ботам учетные данные, которые те будут использовать для связи с командным сервером. То есть построить что-то вроде такой схемы.
Этот вариант накладывает целый ряд ограничений на проводимые операции. Так, необходимо обеспечить боту возможность оперативно обновлять учетные данные от сервиса, если старые заблокируют. Это не так сложно организовать с помощью одностороннего канала связи. Но проблема выходит на новый уровень, когда число ботов начинает расти. Большое количество запросов с разных IP к одному аккаунту будет как минимум подозрительным. Можно попытаться замести следы, реализовав систему распространения учетных записей среди ботов — чтобы они передавали их друг другу. Это значительно сложнее и создает дополнительные статьи расходов для киберкриминального бизнеса.
Но что, если поискать возможность обходиться без учетных записей? В таком случае из диаграммы выше можно было бы убрать все, что связано с логинами и паролями. И это приводит нас к анонимным сервисам.
Анонимные сервисы вопросов и ответов
Один из привлекательных вариантов — использовать сервисы анонимных вопросов и ответов типа Ask.fm, Sprashivai.ru и прочих. Вот почему они так хорошо годятся:
В последнем пункте мне довелось убедиться лично. В феврале 2017 года я отправил сотрудникам техподдержки сервиса Sprashivai.ru информацию о том, что их защита от спама не работает, а предпринятые после слива меры безопасности эту самую безопасность подрывают. Для меня не стало неожиданностью то, что они полностью проигнорировали мой репорт. Не думаю, что ситуация с другими сервисами кардинально отличается.
Как именно реализуется двусторонний канал связи на основе таких сервисов? Эту задачу можно разбить на два этапа:
Канал связи «оператор — бот»
На этом этапе ничего особенно сложного. Большая часть малвари, которая использует какие-либо сервисы для обеспечения одностороннего канала связи, работает именно по этой схеме. В контексте сервисов вопросов и ответов это реализуется, например, следующим образом:
Это приводит разработчика вредоноса к следующей проблеме: чтобы автоматизировать регистрацию аккаунтов (да и авторизации тоже), скорее всего, потребуется найти метод обхода капчи. Рассмотрим эти методы на примерах выбранных нами сервисов.
Регистрация
Sprashivai.ru использует ReCaptcha, поэтому для автоматической регистрации аккаунтов нужно будет озаботиться обходом такой защиты.
POST-запрос на регистрацию аккаунта Sprashivai.ru выглядит так.
Ask.fm же не содержит вообще никакой защиты от авторега. Форма регистрации не требует ввода капчи, а итоговый запрос имеет следующий вид.
Единственный момент, который здесь нужно учесть, состоит в отправке на сервер параметра authenticity_token, который включен в код страницы регистрации и выглядит примерно так:
В общем, с автоматической регистрацией для Ask.fm нет никаких проблем, достаточно сделать два запроса: один — для получения токена, сессии и прочей информации, другой — с целью регистрации аккаунта.
Авторизация
Оператору нужно иметь возможность автоматизировать, кроме регистрации, процесс авторизации с зарегистрированными учетками. Ни Sprashivai.ru, ни Ask.fm не используют капчу при аутентификации пользователя, что существенно упрощает задачу.
При этом Sprashivai.ru вычисляет хеш пароля на стороне клиента и отсылает серверу уже его, а не сам пароль в открытом виде.
Вот так выглядит запрос на авторизацию в сервисе Sprashivai.ru.
И для Ask.fm соответственно.
Опять-таки на Ask.fm мы видим, что в коде страницы с вопросом содержится параметр authenticity_token.
Публикация информации для ботов
Тут все так же просто. Первый запрос оператора должен собирать имеющиеся вопросы, а второй — отвечать на них так, чтобы сам ответ или приложенная информация несла в себе полезную нагрузку для ботов.
Я не буду прикладывать сюда скриншоты запросов, поскольку они выглядят аналогично. Если есть желание, можешь взять Burp Suite и самостоятельно убедиться, что в запросах нет никакой магии.
Канал связи «бот — оператор»
Этот канал связи реализуется через отправку анонимных ответов.
Сервис Sprashivai.ru, если мне не изменяет память, всегда поддерживал такую возможность без авторизации пользователя, а вот на Ask.fm она появилась сравнительно недавно.
Анонимный вопрос пользователю Ask.fm в виде запроса выглядит примерно так.
Производится POST-запрос к /<account_name>/ask, содержащий уже знакомый нам authenticity_token из кода страницы и сам вопрос.
Интересно, что задаваемый вопрос дублируется в Cookie, отправляемой в запросе, — это нужно учесть при автоматизации процесса.
Для Sprashivai.ru картина немного иная.
В параметрах видно имя аккаунта, флаг, означающий, что вопрос будет задан анонимно, а также сам вопрос и два странных хеша. В процессе авторизации мы уже встречали нечто подобное — похоже, разработчики Sprashivai.ru просто питают нездоровую тягу к хешированию.
Хорошая новость состоит в том, что значение параметра hash присутствует в коде страницы, с которой мы и пытаемся отправить вопрос пользователю.
Отсюда вытекает и вторая новость, но уже плохая — значения параметра sig на странице нет. По всей видимости, оно вычисляется в ходе работы какого-то скрипта.
А это значит, что для восстановления алгоритма генерации этого параметра нам нужно реверсить обфусцированный
JavaScript.
Дебаггер Firefox позволяет определить функцию, которая генерирует значение sig. Как видно, значение этого параметра формируется функцией hash_ask с двумя параметрами.
Сама функция hash_ask() описана в скрипте
С помощью отладочных средств, встроенных в Firefox, мне удалось узнать, что параметр r функции hash_ask равен значению переменной hash, которая передается в запросе и содержится в коде страницы, а e — имени пользователя, которому задается вопрос.
Проблема в том, что нам нужно найти значение, которое возвращает функция secr(). Ее определение отсутствует и в этом файле, и во всех остальных.
Тут я совершил промашку, которая стоила мне лишних трудов. В secure.min_2015_06_26.js содержится какой-то скрытый обфускацией код, и я решил его отладить и деобфусцировать. Спустя несколько часов кропотливой работы с Rhino я обнаружил, что этот код, по сути, считает SHA-256 от входной строки.
На самом деле это не нужно. Если прогнать значение sid через hashid, то мы узнаем, что это 256-битный хеш от некой строки.
А в коде скрипта можно заметить отсылки к SHA-224, что, видимо, указывает на алгоритм хеширования. Проверка этой теории сэкономила бы мне уйму времени и нервов. Также мне удалось нагуглить несколько страниц с этим же кодом на разных форумах. Не исключено, что это занятие привело бы к нужному результату еще скорее.
Но вернемся к решению изначального вопроса. Чтобы сгенерировать значение параметра sig, нам нужно взять строку hash из кода страницы, имя пользователя и еще несколько строк и сформировать хеш SHA-256 от этого значения.
Почти год назад я доложил создателям сервиса Sprashivai.ru, что такая защита как минимум не работает, и создал
Выводы
Как мы убедились, анонимные сервисы вопросов и ответов можно без проблем использовать для управления вредоносным софтом. У Ask.fm нет никакой защиты от этого, а Sprashivai.ru в качестве защиты использует некорректную методику. Наверняка многие другие анонимные сервисы тоже подойдут.
Тем не менее у такого метода есть ряд существенных проблем. Во-первых, при передаче данных от бота к сервису нужно как-то кодировать передаваемые данные для того, чтобы избежать лишних подозрений. Во-вторых, стихийное возрастание количества посетителей некоторых аккаунтов также может привлечь к себе внимание администрации ресурсов. Как снизить эти риски — решать не нам.
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
Создание анонимного двустороннего канала связи — постоянная головная боль для разработчиков вредоносного ПО. В этой статье мы на примерах разберем, как сервисы, разработчики которых используют недостаточно сильную защиту, могут превратиться в такой канал.
Как только не изворачиваются злоумышленники, чтобы скрытно передавать данные между малварью и командным центром (C&C, или, как их теперь модно называть на военный лад, C2). Сторонние сервисы здесь зачастую представляются самым удобным вариантом. В ход идут твиты, коммиты на GitHub или отдельные репозитории; даже комменты к видео на YouTube могут оказаться тайными посланиями между машинами. Использование таких сервисов открывает для оператора ботнета новые возможности. В частности, он может не беспокоиться о смене адресов управляющих серверов — достаточно просто оставить твит, в приложенной к которому картинке будет содержаться актуальная информация.
У одностороннего канала связи есть свои недостатки. Во-первых, такого бота легче выявить по образцу трафика. Во-вторых, аккаунт на сервисе могут заблокировать или он может попасть в поле зрения исследователей. Это сильно затруднит дальнейшие операции.
Создание безопасного двустороннего канала связи с использованием сторонних сервисов — задача нетривиальная. Если не прибегать к каким-либо хакам, то все, что можно предпринять в таком случае, — это раздать ботам учетные данные, которые те будут использовать для связи с командным сервером. То есть построить что-то вроде такой схемы.
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
Этот вариант накладывает целый ряд ограничений на проводимые операции. Так, необходимо обеспечить боту возможность оперативно обновлять учетные данные от сервиса, если старые заблокируют. Это не так сложно организовать с помощью одностороннего канала связи. Но проблема выходит на новый уровень, когда число ботов начинает расти. Большое количество запросов с разных IP к одному аккаунту будет как минимум подозрительным. Можно попытаться замести следы, реализовав систему распространения учетных записей среди ботов — чтобы они передавали их друг другу. Это значительно сложнее и создает дополнительные статьи расходов для киберкриминального бизнеса.
Но что, если поискать возможность обходиться без учетных записей? В таком случае из диаграммы выше можно было бы убрать все, что связано с логинами и паролями. И это приводит нас к анонимным сервисам.
Анонимные сервисы вопросов и ответов
Один из привлекательных вариантов — использовать сервисы анонимных вопросов и ответов типа Ask.fm, Sprashivai.ru и прочих. Вот почему они так хорошо годятся:
- они работают по HTTP и как минимум поддерживают HTTPS;
- адреса сервисов анонимных вопросов и ответов известны вендорам security-решений и присутствуют в белых списках модулей Application Control & URL Filtering;
- разработчикам таких сервисов не интересна безопасность собственных решений, а техподдержка пассивна.
В последнем пункте мне довелось убедиться лично. В феврале 2017 года я отправил сотрудникам техподдержки сервиса Sprashivai.ru информацию о том, что их защита от спама не работает, а предпринятые после слива меры безопасности эту самую безопасность подрывают. Для меня не стало неожиданностью то, что они полностью проигнорировали мой репорт. Не думаю, что ситуация с другими сервисами кардинально отличается.
Как именно реализуется двусторонний канал связи на основе таких сервисов? Эту задачу можно разбить на два этапа:
- Формирование устойчивого канала связи для передачи данных в направлении от бота к оператору.
- Формирование канала связи для передачи данных от оператора к ботам.
Канал связи «оператор — бот»
На этом этапе ничего особенно сложного. Большая часть малвари, которая использует какие-либо сервисы для обеспечения одностороннего канала связи, работает именно по этой схеме. В контексте сервисов вопросов и ответов это реализуется, например, следующим образом:
- оператор «отвечает» на вопрос и прикладывает к ответу изображение, содержащее в закодированной форме команды для ботов;
- бот проверяет, не появились ли новые данные в используемом оператором аккаунте, и выполняет необходимые действия.
Это приводит разработчика вредоноса к следующей проблеме: чтобы автоматизировать регистрацию аккаунтов (да и авторизации тоже), скорее всего, потребуется найти метод обхода капчи. Рассмотрим эти методы на примерах выбранных нами сервисов.
Регистрация
Sprashivai.ru использует ReCaptcha, поэтому для автоматической регистрации аккаунтов нужно будет озаботиться обходом такой защиты.
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
POST-запрос на регистрацию аккаунта Sprashivai.ru выглядит так.
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
Ask.fm же не содержит вообще никакой защиты от авторега. Форма регистрации не требует ввода капчи, а итоговый запрос имеет следующий вид.
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
Единственный момент, который здесь нужно учесть, состоит в отправке на сервер параметра authenticity_token, который включен в код страницы регистрации и выглядит примерно так:
Код:
<input type="hidden" name="authenticity_token" value="KljYiKgJAeDD6L0RDjh/kuvdelt2UmtML90xBs7D4vGfK3UkdW8o+Men4tzhYmgWBrj4kGqw25ERdf9Mg9eK5Q==" />В общем, с автоматической регистрацией для Ask.fm нет никаких проблем, достаточно сделать два запроса: один — для получения токена, сессии и прочей информации, другой — с целью регистрации аккаунта.
Авторизация
Оператору нужно иметь возможность автоматизировать, кроме регистрации, процесс авторизации с зарегистрированными учетками. Ни Sprashivai.ru, ни Ask.fm не используют капчу при аутентификации пользователя, что существенно упрощает задачу.
При этом Sprashivai.ru вычисляет хеш пароля на стороне клиента и отсылает серверу уже его, а не сам пароль в открытом виде.
Вот так выглядит запрос на авторизацию в сервисе Sprashivai.ru.
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
И для Ask.fm соответственно.
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
Опять-таки на Ask.fm мы видим, что в коде страницы с вопросом содержится параметр authenticity_token.
Публикация информации для ботов
Тут все так же просто. Первый запрос оператора должен собирать имеющиеся вопросы, а второй — отвечать на них так, чтобы сам ответ или приложенная информация несла в себе полезную нагрузку для ботов.
Я не буду прикладывать сюда скриншоты запросов, поскольку они выглядят аналогично. Если есть желание, можешь взять Burp Suite и самостоятельно убедиться, что в запросах нет никакой магии.
Канал связи «бот — оператор»
Этот канал связи реализуется через отправку анонимных ответов.
Сервис Sprashivai.ru, если мне не изменяет память, всегда поддерживал такую возможность без авторизации пользователя, а вот на Ask.fm она появилась сравнительно недавно.
Анонимный вопрос пользователю Ask.fm в виде запроса выглядит примерно так.
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
Производится POST-запрос к /<account_name>/ask, содержащий уже знакомый нам authenticity_token из кода страницы и сам вопрос.
Интересно, что задаваемый вопрос дублируется в Cookie, отправляемой в запросе, — это нужно учесть при автоматизации процесса.
Для Sprashivai.ru картина немного иная.
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
В параметрах видно имя аккаунта, флаг, означающий, что вопрос будет задан анонимно, а также сам вопрос и два странных хеша. В процессе авторизации мы уже встречали нечто подобное — похоже, разработчики Sprashivai.ru просто питают нездоровую тягу к хешированию.
Хорошая новость состоит в том, что значение параметра hash присутствует в коде страницы, с которой мы и пытаемся отправить вопрос пользователю.
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
Отсюда вытекает и вторая новость, но уже плохая — значения параметра sig на странице нет. По всей видимости, оно вычисляется в ходе работы какого-то скрипта.
А это значит, что для восстановления алгоритма генерации этого параметра нам нужно реверсить обфусцированный
JavaScript.
Дебаггер Firefox позволяет определить функцию, которая генерирует значение sig. Как видно, значение этого параметра формируется функцией hash_ask с двумя параметрами.
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
Сама функция hash_ask() описана в скрипте
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
и выглядит следующим образом:
Код:
function hash_ask(r,e){
var t="2O889rz3A5K30hxi8cazk7UcJY8623tBNGMLW49R" +
e + r +
"bDM808Lt8g647vlGhDtbCRhvxBkJyNkmjn8574zT";
return secr(t)
}С помощью отладочных средств, встроенных в Firefox, мне удалось узнать, что параметр r функции hash_ask равен значению переменной hash, которая передается в запросе и содержится в коде страницы, а e — имени пользователя, которому задается вопрос.
Проблема в том, что нам нужно найти значение, которое возвращает функция secr(). Ее определение отсутствует и в этом файле, и во всех остальных.
Тут я совершил промашку, которая стоила мне лишних трудов. В secure.min_2015_06_26.js содержится какой-то скрытый обфускацией код, и я решил его отладить и деобфусцировать. Спустя несколько часов кропотливой работы с Rhino я обнаружил, что этот код, по сути, считает SHA-256 от входной строки.
На самом деле это не нужно. Если прогнать значение sid через hashid, то мы узнаем, что это 256-битный хеш от некой строки.
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
А в коде скрипта можно заметить отсылки к SHA-224, что, видимо, указывает на алгоритм хеширования. Проверка этой теории сэкономила бы мне уйму времени и нервов. Также мне удалось нагуглить несколько страниц с этим же кодом на разных форумах. Не исключено, что это занятие привело бы к нужному результату еще скорее.
Но вернемся к решению изначального вопроса. Чтобы сгенерировать значение параметра sig, нам нужно взять строку hash из кода страницы, имя пользователя и еще несколько строк и сформировать хеш SHA-256 от этого значения.
Почти год назад я доложил создателям сервиса Sprashivai.ru, что такая защита как минимум не работает, и создал
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
c кодом, который позволяет автоматически задавать вопросы конкретному пользователю. Уверен, что этот код позволит желающим разобраться в теме в том случае, если я что-то непонятно описал.Выводы
Как мы убедились, анонимные сервисы вопросов и ответов можно без проблем использовать для управления вредоносным софтом. У Ask.fm нет никакой защиты от этого, а Sprashivai.ru в качестве защиты использует некорректную методику. Наверняка многие другие анонимные сервисы тоже подойдут.
Тем не менее у такого метода есть ряд существенных проблем. Во-первых, при передаче данных от бота к сервису нужно как-то кодировать передаваемые данные для того, чтобы избежать лишних подозрений. Во-вторых, стихийное возрастание количества посетителей некоторых аккаунтов также может привлечь к себе внимание администрации ресурсов. Как снизить эти риски — решать не нам.
