Программирование[10]

besteady написал 3 минуты назад:

Что ты будешь делать с перехваченным зашифрованным траффиком?

Ты вообще понимаешь суть MITM?

https://ru.wikipedia.org/wiki/Атака_посредника

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

Ну и офк могу создавать новые запросы на бек от лица пользователя интернет-банкинга написанного на электроне с отключенной проверкой сертификатов. 

Index написал 1 минуту назад:

besteady написал 7 минут назад:

Что ты будешь делать с перехваченным зашифрованным траффиком?

Ты вообще понимаешь суть MITM?

https://ru.wikipedia.org/wiki/Атака_посредника

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

И что ты будешь делать с зашифрованным траффиком банковского приложения, которое не передает никаких ключей, а шифрует по каким-нибудь данным пользователя. Как ты его будешь читать?

besteady написал 5 минут назад:

И что ты будешь делать с зашифрованным траффиком банковского приложения, которое не передает никаких ключей, а шифрует по каким-нибудь данным пользователя. Как ты его будешь читать?

Я просто буду слать пост запрос на перевод средств зная структуру этого пост запроса. Всё что мне надо это JWT/куксиы/вотевер используемое для аутентификации.

Какое блять шифрование по данным пользователя?

Если есть шифрование, то значит есть и дешифрование в приложении.

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

Index написал 6 минут назад:

 

besteady написал 11 минут назад:

И что ты будешь делать с зашифрованным траффиком банковского приложения, которое не передает никаких ключей, а шифрует по каким-нибудь данным пользователя. Как ты его будешь читать?

 

Я просто буду слать пост запрос на перевод средств зная структуру этого пост запроса. Всё что мне надо это JWT/куксиы/вотевер используемое для аутентификации.

Какое блять шифрование по данным пользователя?

Если есть шифрование, то значит есть и дешифрование в приложении.

 

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

 

Какой бля алгоритм

Ты не знаешь ключ шифрования

У тебя нет доступа к приложению

У тебя нет доступа к хосту (серверу)

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

Придурок, в MITM атаке 2 соединения. Для меня трафик расшифрован и я его контролирую.

Index написал 9 минут назад:

 

Я просто буду слать пост запрос на перевод средств зная структуру этого пост запроса. Всё что мне надо это JWT/куксиы/вотевер используемое для аутентификации.

Он о том, что этот пост запрос должен быть зашифрован так, как это ожидает и может сервер с приложением. Что это не хттп запрос с открытым джосн телом 

{"money": "999999dalarov", "komu":"defrel", "from":"zenitchik", "comment":"za krishu"}

И что https является контейнером для этого зашифрованного траффика.

Я придерживаюсь мнения, что если бы это просто так все скамилось, то мы бы все об этом знали. Бэкдоры, баги, ошибки, да. Но не такого уровня проеб.

А ну опять же, если ты про end-to-end шифрование, то когда был произведён обмен ключами? Обычно обмен ключами идёт в момент установки сессии и я просто делаю MITM ещё на слое end-to-end

GoldRobot написал Только что:

Index написал 9 минут назад:

 

Я просто буду слать пост запрос на перевод средств зная структуру этого пост запроса. Всё что мне надо это JWT/куксиы/вотевер используемое для аутентификации.

Он о том, что этот пост запрос должен быть зашифрован так, как это ожидает и может сервер с приложением. Что это не хттп запрос с открытым джосн телом 

{"money": "999999dalarov", "komu":"defrel", "from":"zenitchik", "comment":"za krishu"}

Ну тут вопрос как он шифруется, если end-to-end ключом полученным до компрометации, то ничего не сделать.

Если ключом который получается/генерится в момент установки сессии, то я просто буду дешифроват, модифицировать и  шифровать обратно полученным/сгенеренным ключом.

Index написал 5 минут назад:

Придурок, в MITM атаке 2 соединения. Для меня трафик расшифрован и я его контролирую.

Откуда он у тебя расшифрован, если у тебя нет ключа? 

Ты понимаешь что это https передает ключи, потому что там задача между двумя рандомами в рандомной ситуации установить защищенное соединение

Причём тут банковское приложение

Ты пересылаешь на ремоут сервер один раз ключ и при некст соединении тебе не надо ничего делать

besteady написал Только что:

Ты пересылаешь на ремоут сервер один раз ключ и при некст соединении тебе не надо ничего делать

Значит ты про end-to-end с ключом полученным до компрометации, ну ок, такую систему не получится атаковать.

Index написал 45 минут назад:

будет ли она в прилажке интернет-банкинга написанного индусом или оно проглотит подмененный сертификат это уже хуй знает как говорится.

можно так рассуждать - а не решит ли очередной клерк банка перевести все твои деньги на счет в офшорах

че за бред та

Index написал 2 минуты назад:

А ну опять же, если ты про end-to-end шифрование, то когда был произведён обмен ключами? Обычно обмен ключами идёт в момент установки сессии и я просто делаю MITM ещё на слое end-to-end

Множество протоколов шифрования есть с которыми тебе это не поможет. Если я тебе дам свой публичный ключ от ssh, то тебе это ничем не поможет, что бы прикинуться мною.

Index написал 7 минут назад:

Придурок, в MITM атаке 2 соединения. Для меня трафик расшифрован и я его контролирую.

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

Пиздец вы наверное парня напугали, он теперь кроме как в кассе в провереном главном филиале банка не будет свои деньги снимать.

Index написал 2 минуты назад:

besteady написал 4 минуты назад:

Ты пересылаешь на ремоут сервер один раз ключ и при некст соединении тебе не надо ничего делать

Значит ты про end-to-end с ключом полученным до компрометации, ну ок, такую систему не получится атаковать.

Ну очевидно банковские приложения как раз к этому относятся

Случайно обмен ключами при каждом соединении не наговнокодишь

Index написал 3 минуты назад:

besteady написал 4 минуты назад:

Ты пересылаешь на ремоут сервер один раз ключ и при некст соединении тебе не надо ничего делать

Значит ты про end-to-end с ключом полученным до компрометации, ну ок, такую систему не получится атаковать.

слава богу разобрались

GoldRobot написал 2 минуты назад:

Пиздец вы наверное парня напугали, он теперь кроме как в кассе в провереном главном филиале банка не будет свои деньги снимать.

так и есть оочень ссыкотно в тинькофф инвестициии заходить, чекнул цены акций через сайт биржи

чет не понял, что за хуйню вы тут развели

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

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

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

по крайней мере это крайне алогично

а каким образом приложение передает ключи и сколько они действуют ты не знаешь

мне даже интересно, а где ты видел такие приложения?

чуваки разрабатывающие банковские приложения, неожиданно стали свои транспортные протоколы писать?

земля пухом пользоваться таким банком в таком случае

хттпс не умеет работать по "хранящимся" ключам, это дефолтный ссл, там нет никакого хранения ключей, каждое соединение свой хэндшейк делает, где этими ключами и обменивается

а, ну ладно, вы может имеете ввиду вариант, что они еще внутри тлса хуярят е2е, но это обычно предполагает реальное шифрование данных с обоих сторон, чего очевидно банк  не делает, у него на сервере всё просто лежит