В общем-то, пишу малварьку, встал вопрос шифрования трафика между сервером и клиентом. Многие засрали реализацию шифрования трафика в нашем с X-Shar боте, как реализовать лучше? Смотрю в сторону RSA-2048: генерируется пара ключей (public + private), паблик-ключом на клиенте криптуются данные, на сервере расшифровываются с помощью private-ключа. Но если нужно будет расшифровать сообщение от сервера, как быть? Грузить на клиент private-ключ? Не безопасно. Генерировать две пары ключей: для сервера и клиента? В криптографии не шарю, разбираюсь по ходу. Буду благодарен, если кто-нибудь разжуёт этот момент.
-
XSS.stack #1 – первый литературный журнал от юзеров форума
Шифрование трафика
- Автор темы Jeffs
- Дата начала
Какая разница, чем шифровать траффик, и о какой безопасности ты говоришь? Если бинарь попадет на руки, расшифровывать что-то смысла не будет, т.к останется тупо крутить стек в поисках заветного запроса в голом виде. Шифрование делается для невозможности/усложнения установления сигнатурного детекта на трафик твоего зверька.
- Автор темы
- Добавить закладку
- #3
В случае с реализацией алгоритма крипта трафик нашего бота - достаточно один раз расковырять бинарник и можно будет расшифровывать весь трафик на автомате. Хотелось бы исключить подобную возможность.
Это невозможно исключить. Шифрование является неодносторонним процессом, следовательно, чего бы ты не делал, можно будет составить обратный алгоритм и расшифровать весь входящий/исходящий трафик.
Бот генерирует себе ключевую пару, приватный сохраняет, публичный посылает панели. Используй комбинацию RSA (для шифоования сессионного ключа AES) и AES (для шифрования данных). По хорошему все пересылаемые данные должны быть подписаны на приватных ключах (как минимум каким-нить HMAC-MD5). И длина RSA ключа должна быть больше 4096.
Если ты сможешь по публичному ключу RSA достаточной длины вскрыть приватный ключ, ты как минимум станешь легендой криптографии, а как максимум получишь нобелевскую премию по математике.
Больше или равна 4096.
Я говорю не про ручную расшифровку. В процессе отладки из бинарника можно достать любые интересующие данные, например, эмулируя реализованную систему шифрования, или просматривая стек. Я говорил именно о первом методе. А желание ТС по факту бессмысленно, для его запросов хватит и самого простого алгоритма.
Задачи примерно одинаковые по сложности потому что нобелевки по математике не существует
я вот когда делал было так (да, это тупо и жестко). Криптуем файл aes и отправляем на гейт. Ключ по которому зашифровали является либо айпи жертвы, либо юзер агент и т.д. (т.е. то что попадает в http). После на панели брутиться этот файл разным способом (айпи или юзер агент например). Но как понять, шо мы правильно дешифровали, все прост, в файл наш малварь запишет предварительно либо айпи, либо юзер агент. И когда мы будем дешифровывать файл, то будем искать в файле на совпадение ключа. Да, это жестко и тупо...
А как выдавать параметры от командного пункта?
Опять же посылает наш малварь get запрос, на серваке php по алгоритму aes (а ключ является айпи) составляется уникальный заголовок. После малварь получает эти данные, и при помощи своего айпи декриптит aes'ом данные.
А как выдавать параметры от командного пункта?
Опять же посылает наш малварь get запрос, на серваке php по алгоритму aes (а ключ является айпи) составляется уникальный заголовок. После малварь получает эти данные, и при помощи своего айпи декриптит aes'ом данные.
Как сказать, для скриптскидисовского бота возможно и хватит.
Чего выдавать?
- Автор темы
- Добавить закладку
- #12
В голову пришла ещё такая идея:
Шлём на сервер уникальный идентификатор машины, там же генерируем ключ (пишем его, к примеру, в БД), отправляем клиенту в ответе. На клиенте шифруем данные этим ключём, шлём на сервер. На сервере достём из БД нужный ключ, декриптим данные.
Какие минусы вы видите в этом алгоритме?
Шлём на сервер уникальный идентификатор машины, там же генерируем ключ (пишем его, к примеру, в БД), отправляем клиенту в ответе. На клиенте шифруем данные этим ключём, шлём на сервер. На сервере достём из БД нужный ключ, декриптим данные.
Какие минусы вы видите в этом алгоритме?
Почему? А зачем шифровать трафик? Это делается сугубо для предовтращения установки сигнатур. Можно поподробнее?
у меня почти тоже самое кста, выше описал
ну дофига операций, прям ну оч много. Попробуй уложиться в два запроса. Получить данные параметра и отправить файл
Давай подробнее, как я бы делал, если бы был блекушником. У нас есть в сети три точки: компьютер жертвы (А), условная панель или гейт (Б), компьютер ботовода (В). На А бот генерирует себе ключевую пару, приватный хранит у себя, публичный отправляет на Б. На Б никаких ключей не хранится, это только тупой скрипт, который просто передает шифр-контейнеры между А и В. У В есть своя ключевая пара, публичный ключ из которой вшит в бота на А. Чтобы отправить боту команду, мы на В с помощью полученного публичного ключа бота на А формируем крипто-контейнер и подписываем своим приватным ключом, затем отправляем этот шифр-контейнер на Б. Б соотвественно отдает его боту на А. Бот забирает шифр-контейнер у Б, расшифровывает на своем приватном ключе и проверяет цифровую подпись, затем, если все норм, исполняет. Возвращает результат команды аналогично в обратную сторону. Что мы с этого имеем? Во-первых, на канале передачи данных летают только криптоконтейнеры, нельзя понять, какие команды ставились боту и какие данные он отсылал. Во-вторых, взломав нашу панель/гейт/точку Б злоумышленник или же авер например не может увести ботнет, тк не имеет приватных ключей. В третьих, мы всегда можем проверить корректность передаваемых данных по их цифровой подписи.
Выдавать параметры для проги например. Когда стиле обрщается к гейту, то он получает данные через http. Об этом речь (С&C сервак)