• XSS.stack #1 – первый литературный журнал от юзеров форума

Статья Пишем ратник с нуля и навека

Отслеживать
Пожалуйста, обратите внимание, что пользователь заблокирован
X-Shar сказал(а):
Почему, не будет никаких детектов.)
В последний раз когда я хешировал все апишки, оставляя без таблицы импорта - статика прост орала на свежеприготовленную малварь. А добавив левые - уже фуд
X-Shar сказал(а):
Не сложно, всё относительно легко выводится, но при условии относительно небольших сумм и редкой частоты выводов, иначе легко может обратить внимание наоговая служба, как минимум и придется объяснять от куда эти средства.)
Да много схем есть кста) ты прост не в курсах же)
X-Shar сказал(а):
Хрен его знает, так-то думаю большинство селлеров этого форума, даже это не юзает.)
К сожалению качество софта оставляет желать лучшего, не знаю как-там у супер-команд, но никто не заморачивается в блеке, главное продать.
Да лан, не сравнивай то, что в паблике и то, что в привате. Я видел неплохие боты в привате, там максимум хешируют апи. Не больше. Про сисколы вообще не видел нигде (только один раз). (мб мало че видел я своей жизни)
X-Shar сказал(а):
но не думаю что это критично.)
Для VNC как раз и критично. Если будете использовать например rsa 2048 с ассиметричным ключом, то фпс будет у Вас максимум 10. Как вариант только симетричное шифрование.
 
heybabyone сказал(а):
Для VNC как раз и критично. Если будете использовать например rsa 2048 с ассиметричным ключом, то фпс будет у Вас максимум 10. Как вариант только симетричное шифрование.
А для чего нужна такая криптостойкость в внц, что использовать то 2048 бит ключ?) Этот ключ что брутить кто-то будет чтоб расшифровать?
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Так стоп. Чего то уже бред пошел. Обменялись публичными ключами RSA, зашифровали на них сеансовые ключи (там AES или ARC4 не важно), обменялись ими и дальше стримите данные зашифрованные на сеансовых ключах. Никто в здравом уме не будет RSA шифровать данные, только ключи, хеши и подписи данных. И кстати RSA как минимум 4096 должен быть в 2020 году.
 
DildoFagins сказал(а):
И кстати RSA как минимум 4096 должен быть в 2020 году.
Не ну это хорошо конечно, что мы по стандартам все делаем, но зачем малваре внц такая криптостойкость то нужна?)
 
Пожалуйста, обратите внимание, что пользователь заблокирован
DildoFagins сказал(а):
Так стоп. Чего то уже бред пошел. Обменялись публичными ключами RSA, зашифровали на них сеансовые ключи (там AES или ARC4 не важно), обменялись ими и дальше стримите данные зашифрованные на сеансовых ключах. Никто в здравом уме не будет RSA шифровать данные, только ключи, хеши и подписи данных. И кстати RSA как минимум 4096 должен быть в 2020 году.
Далëк от криптографии. А чем RSA плох? Медленный?
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Jeffs сказал(а):
А чем RSA плох? Медленный?
Он не создавался для шифрования массивов данных, для этого есть всякие AES, DES, ARC4 и тд. Да, RSA медленный, как и все ассиметричные алгоритмы.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
ficker сказал(а):
Не ну это хорошо конечно, что мы по стандартам все делаем, но зачем малваре внц такая криптостойкость то нужна?)
Это вопрос из серии: зачем ходить в интернет по HTTPS, если только мемчики смотришь?
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Jeffs сказал(а):
Далëк от криптографии. А чем RSA плох? Медленный?
симметричные алгоритмы быстрее (когда одним ключом можно зашифровать/дешифровать), а ассиметричные я думаю ты знаешь как работает. Как Рел сказал они нужны, чтоб малые объемы криптить под типу ключ от AES (в основном лохеры юзают).

Но зачем таким образом криптить шифрование особенно у VNC/HVNC. Попробуйте зайти на дедик по тому самоу же rdp. Думаю, у вас тоже все зависает. Банально можно поксорить или использовать менее жесткий алгоритм.
ficker сказал(а):
Не ну это хорошо конечно, что мы по стандартам все делаем, но зачем малваре внц такая криптостойкость то нужна?)
Я прост ребятам на будущее так-то хотел сказать) Я и об этом же, что такая криптостойкость не нужна.

DildoFagins сказал(а):
Это вопрос из серии: зачем ходить в интернет по HTTPS, если только мемчики смотришь?
4096 для внц эт слишком жестко.

Лучше юзать какой-нибудь симметричный с мин., ключом (банально чтоб защита была).
А так при написании vnc предстанет выбор: безопасность или скорость.
 
DildoFagins сказал(а):
Это вопрос из серии: зачем ходить в интернет по HTTPS, если только мемчики смотришь?
Так мы малварь вроде бы пишем, а не белый софт, чтоб заботится о безопасности конечного юзера. Тут шифрование нужно только для того, чтоб аверам усложнить жизнь и все, а самая главная задача в внц малваре - стабильность и качественность коннекта, чтоб отрисовывало на всех индуских машинах с ужасным инетом и плохим железом. Речь же не про локеры, чтоб вообще говорить о крипостойкости
 
Пожалуйста, обратите внимание, что пользователь заблокирован
heybabyone сказал(а):
Лучше юзать какой-нибудь симметричный с мин., ключом (банально чтоб защита была).
А так при написании vnc предстанет выбор: безопасность или скорость.
О хоспаде, ARC4 очень быстро шифровать и расшифровывать, реализация AES уже скоро будет у всех на аппаратном уровне - https://ru.m.wikipedia.org/wiki/Расширение_системы_команд_AES (и занимает чет типа 4 такта для одного блока, если не путаю ничего). У вас будет больше связь просаживать, чем шифрование потока видео.

ficker сказал(а):
Так мы малварь вроде бы пишем, а не белый софт, чтоб заботится о безопасности конечного юзера. Тут шифрование нужно только для того, чтоб аверам усложнить жизнь и все, а самая главная задача в внц малваре - стабильность и качественность коннекта, чтоб отрисовывало на всех индуских машинах с ужасным инетом и плохим железом. Речь же не про локеры, чтоб вообще говорить о крипостойкости
Ну ради Бога чего, потом в отчетах прочитаете, как вирусные аналитики вам на ваших ботов команды на самоудаление ставят. Я как бы не настаиваю ни на чем.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
heybabyone сказал(а):
4096 для внц эт слишком жестко
Вообще в плане шифрования и дешифровки размер ключа RSA особо не имеет значения в плане производительности. Только при генерации ключей, чем длиннее ключ - тем существенно дольше генерируется ключевая пара. И потом вам надо будет сделать шифрования/дешифрование RSA один раз за сеанс. И это будет происходить до того, как вы что-то там стримить начнете. Что значит жестко?
 
DildoFagins сказал(а):
Ну ради Бога чего, потом в отчетах прочитаете, как вирусные аналитики вам на ваших ботов команды на самоудаление ставят. Я как бы не настаиваю ни на чем.
А как это к шифрованию относится? Это уязвимость веб панели тогда, если имея доступ к одному боту, авер может удалить всех остальных ботов
 
Пожалуйста, обратите внимание, что пользователь заблокирован
DildoFagins сказал(а):
О хоспаде, ARC4 очень быстро шифровать и расшифровывать, реализация AES уже скоро будет у всех на аппаратном уровне - https://ru.m.wikipedia.org/wiki/Расширение_системы_команд_AES (и занимает чет типа 4 такта для одного блока, если не путаю ничего). У вас будет больше связь просаживать, чем шифрование потока видео.
Ну это еще протестировать надо.
DildoFagins сказал(а):
Вообще в плане шифрования и дешифровки размер ключа RSA особо не имеет значения в плане производительности. Только при генерации ключей, чем длиннее ключ - тем существенно дольше генерируется ключевая пара. И потом вам надо будет сделать шифрования/дешифрование RSA один раз за сеанс. И это будет происходить до того, как вы что-то там стримить начнете. Что значит жестко?
Имел ввиду не сеансовая генерация ключа.

DildoFagins сказал(а):
Ну ради Бога чего, потом в отчетах прочитаете, как вирусные аналитики вам на ваших ботов команды на самоудаление ставят. Я как бы не настаиваю ни на чем.
Мы же про внц, а не веб сплойт какой-нибудь
 
Пожалуйста, обратите внимание, что пользователь заблокирован
heybabyone сказал(а):
Ну это еще протестировать надо.
Вот вывод cryptsetup benchmark на моей машине (без AES-NI):
Код: 
#      Алгоритм |      Ключ |      Шифрование |     Расшифровка
        aes-cbc        128b      1124,7 MiB/s      3332,5 MiB/s
    serpent-cbc        128b        97,6 MiB/s       737,7 MiB/s
    twofish-cbc        128b       214,7 MiB/s       393,5 MiB/s
        aes-cbc        256b       878,5 MiB/s      2711,9 MiB/s
    serpent-cbc        256b        99,6 MiB/s       738,8 MiB/s
    twofish-cbc        256b       217,7 MiB/s       393,1 MiB/s
        aes-xts        256b      1997,6 MiB/s      2051,6 MiB/s
    serpent-xts        256b       710,2 MiB/s       700,5 MiB/s
    twofish-xts        256b       389,4 MiB/s       390,9 MiB/s
        aes-xts        512b      1801,8 MiB/s      1848,3 MiB/s
    serpent-xts        512b       711,6 MiB/s       700,8 MiB/s
    twofish-xts        512b       390,3 MiB/s       390,9 MiB/s

ficker сказал(а):
А как это к шифрованию относится? Это уязвимость веб панели тогда, если имея доступ к одному боту, авер может удалить всех остальных ботов
Ну если одна и та же симметричная шифра, то да.
 
DildoFagins сказал(а):
Ну если одна и та же симметричная шифра, то да.
Так это вообще какая должна быть архитектура панели то, чтоб бот сам себе или уж кому-то другому мог дать команду на самоудаление? Есть аккаунт админа в веб панели с лог + пасс, есть его сессия в куках, и только по этой сессии можно сделать запрос на рест апи в админке на добавление боту с определенным ID какой-либо команды, сам же бот лонг пуллит админку со своим айди раз в N сек, и оттуда получает команды которые ему надо исполнить, если там команда start_vnc, то он подключается к нужному серверу и начинает протокол общения vnc с этим клиентом передевая сжатые пиксели, а клиент их обрабатывает. Даже если вообще убрать шифрование на лонг пуллинге и на внц, то при нормальной архитектуре, у аверов и ни у кого другого не будет возможности выдать боту команду на самоудаление. Самое худшее, что может произойти это атака MITM между клиентом и ботом, но кого это волнует вообще и какой ущерб такая атака может принести?
 
Пожалуйста, обратите внимание, что пользователь заблокирован
ficker сказал(а):
Самое худшее, что может произойти это атака MITM между клиентом и ботом, но кого это волнует вообще и какой ущерб такая атака может принести?
Перехватить передающийся https трафик исходящий от бота, вместо логов залить шелл, который на целевой машине экспулатирует 0day сплойт и даст реверс шелл, через который зальем LPE зиродей под ту систему, а в итоге получив рут права перегоним все боты к себе...
Какие еще сказки знаете?)
 
Пожалуйста, обратите внимание, что пользователь заблокирован
В принципе панель на сайте в интернете, или как там это у вас называется, это уязвимое место. Я уже писал об этом (X-Shar выше давал ссылку на мое сообщение). Логику управления из нее лучше исключить, а использовать только для проксирования данных между клиентом и серверами. Подробнее более менее хорошо написано в том сообщении.

Ну как бы я вам говорю, как сделать хорошо и безопасно, если вам на безопасность насрать, ну ради бога, я не против. Это не та тема, из которой нужно разводить полемику на десятки страниц.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
DildoFagins сказал(а):
В принципе панель на сайте в интернете, или как там это у вас называется, это уязвимое место. Я уже писал об этом (X-Shar выше давал ссылку на мое сообщение). Логику управления из нее лучше исключить, а использовать только для проксирования данных между клиентом и серверами. Подробнее более менее хорошо написано в том сообщении.
Навел на определенные мысли) Я делал так же, пробрасывал через один сервер данные, при этом на каждом генерируется отдельный RSA. Но понял, что половина логов теряется из-за нестабильности (на самом деле руки кривые). Сейчас же я отправляю логи через ассиметричный ключ. Для каждого потока генерирую пару ключей приват/открытый (ну скажем для 1000 инсталов). Не вижу смысла для каждого бота. Как сказал ficker, это так уж сильно наполдить надо.
DildoFagins сказал(а):
Ну как бы я вам говорю, как сделать хорошо и безопасно, если вам на безопасность насрать, ну ради бога, я не против. Это не та тема, из которой нужно разводить полемику на десятки страниц.
Да лан Рел, дискуссия же. Изначально речь шла про передачу данных через ВНЦ, а именно шифрование трафика, чтоб холдер не подвисал и чтоб реверсерам жизнь усложнить)
 
DildoFagins сказал(а):
В принципе панель на сайте в интернете, или как там это у вас называется, это уязвимое место. Я уже писал об этом (X-Shar выше давал ссылку на мое сообщение). Логику управления из нее лучше исключить, а использовать только для проксирования данных между клиентом и серверами. Подробнее более менее хорошо написано в том сообщении.

Ну как бы я вам говорю, как сделать хорошо и безопасно, если вам на безопасность насрать, ну ради бога, я не против. Это не та тема, из которой нужно разводить полемику на десятки страниц.
Я так и не услышал ни одного реального аргумента, что в случае слабого шифрования можно как-то повлиять на работу панели или выдать команду другим ботам. В внц малваре - на безопасность конечного юзера, по моему очевидно - что насрать. В моей схеме выше комуникации бота, при отсутствии очевидных уязвимостей в админке, никаких атак быть не может, что с криптостойким шифрованием, что без. Звучит все почему-то на уровне нереальных зиродеев для всего этого дела.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
ficker сказал(а):
Я так и не услышал ни одного реального аргумента, что в случае слабого шифрования можно как-то повлиять на работу панели или выдать команду другим ботам
Ну не услышал, значит не услышал.
 
admin


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх