Как подключить SSLstrip к новой кали и актуально ли это? :)

[Xe0n]

Здравствуйте, совсем не давно стал писать свой криворукий софт на питоне. После просмотренных уроков написал свой ARP_sniffer, используя модуль scapy . Разумеется моя софтина сниффит только пакеты с уровнем защиты HTTP. Почитал в интернете , что бы сниффить сайты HTTPS , нужно понизить их уровень защиты до HTTP с помощью SSLstrips. Не могу запустить SSLstrips в Kali Linux(новая версия). Как видно, кали не видит этот инструмент. Подскажите как это можно исправить или как в реалиях текущего времени сниффить трафик . Всем заранее спасибо

 

[romero_4h]

не создавай много одинаковых тем, карается..

 

[Xe0n]

Случайно создал не в том разделе)

 

[seidziwhitehat]

Случайно создал не в том разделе)

Ты опоздал лет так на 10, sslstrip не обновляется ещё с 12-13 года, не помню точно, да и в данный момент митм имеет смысл разве что в каких-то корп. сетях, где нет прелоад листа и сам hsts мисконфигурен. В обходе https есть несколько подводных камней:
1)hsts-preload list - список доменов которые будут устанавливать соединение только по https, даже если явно указать http схему. Этот список зашивается в современный firefox и chrome браузер(обычно в список входят домены крупных сервисов различных корпораций. Например facebook, twitter, и т.д. Свои домены тоже можно добавлять, это прерогатива не только крупных компаний) Это самая большая проблема для обхода https. Да, домены которых нет в прелоад листе все ещё уязвимы при первом подключении, либо после очистки данных сессии, но все интересные с точки зрения атакующего ресурсы находятся в этом прелоад листе.
2) HSTS. При первом посещении домена жертвой открывается http версия приложения, если пользователь не указал 'https' протокол явно и владелец не внёс его в прелоад лист, это то самое уязвимое окно во время которого можно провести атаку - редирект на фишинг домен, инжект js, или чё там делают в таких ситуациях обычно, но все это при условии отсутствия механизма безопасности из п.1. После первого подключения сервер ответит хедером 'Strict-Transport-Security' с конфигурацией правила по которому жертва будет в дальнейшем обращаться только по https версии, даже если лна будет пытаться явно обращаться по http. Все это актуально когда и сервер, и сам механизм - правильно сконфигурирован, но судя по моей практике это иногда абсолютно не так. Иногда натыкаюсь на мисконфиг этого заголовка в своих проектах, часто он либо просто отсутствует, либо выдаётся не там где нужно из-за того что девопс чет намудрил с прокси-сервером, либо выдаётся с коротким сроком действия. Советую почитать про это более подробно для понимания того как это работает, а практическую реализацию оставить где-то позади, году эдак в 10-15, ибо не особо актуально.

 

[Xe0n]

Ты опоздал лет так на 10, sslstrip не обновляется ещё с 12-13 года, не помню точно, да и в данный момент митм имеет смысл разве что в каких-то корп. сетях, где нет прелоад листа и сам hsts мисконфигурен. В обходе https есть несколько подводных камней:
1)hsts-preload list - список доменов которые будут устанавливать соединение только по https, даже если явно указать http схему. Этот список зашивается в современный firefox и chrome браузер(обычно в список входят домены крупных сервисов различных корпораций. Например facebook, twitter, и т.д. Свои домены тоже можно добавлять, это прерогатива не только крупных компаний) Это самая большая проблема для обхода https. Да, домены которых нет в прелоад листе все ещё уязвимы при первом подключении, либо после очистки данных сессии, но все интересные с точки зрения атакующего ресурсы находятся в этом прелоад листе.
2) HSTS. При первом посещении домена жертвой открывается http версия приложения, если пользователь не указал 'https' протокол явно и владелец не внёс его в прелоад лист, это то самое уязвимое окно во время которого можно провести атаку - редирект на фишинг домен, инжект js, или чё там делают в таких ситуациях обычно, но все это при условии отсутствия механизма безопасности из п.1. После первого подключения сервер ответит хедером 'Strict-Transport-Security' с конфигурацией правила по которому жертва будет в дальнейшем обращаться только по https версии, даже если лна будет пытаться явно обращаться по http. Все это актуально когда и сервер, и сам механизм - правильно сконфигурирован, но судя по моей практике это иногда абсолютно не так. Иногда натыкаюсь на мисконфиг этого заголовка в своих проектах, часто он либо просто отсутствует, либо выдаётся не там где нужно из-за того что девопс чет намудрил с прокси-сервером, либо выдаётся с коротким сроком действия. Советую почитать про это более подробно для понимания того как это работает, а практическую реализацию оставить где-то позади, году эдак в 10-15, ибо не особо актуально.

Спасибо, в целом уже понял это, что не актуально НО за единственный ответ, тебе +

 

[HackLiLBITCH]

Ты опоздал лет так на 10, sslstrip не обновляется ещё с 12-13 года, не помню точно, да и в данный момент митм имеет смысл разве что в каких-то корп. сетях, где нет прелоад листа и сам hsts мисконфигурен. В обходе https есть несколько подводных камней:
1)hsts-preload list - список доменов которые будут устанавливать соединение только по https, даже если явно указать http схему. Этот список зашивается в современный firefox и chrome браузер(обычно в список входят домены крупных сервисов различных корпораций. Например facebook, twitter, и т.д. Свои домены тоже можно добавлять, это прерогатива не только крупных компаний) Это самая большая проблема для обхода https. Да, домены которых нет в прелоад листе все ещё уязвимы при первом подключении, либо после очистки данных сессии, но все интересные с точки зрения атакующего ресурсы находятся в этом прелоад листе.
2) HSTS. При первом посещении домена жертвой открывается http версия приложения, если пользователь не указал 'https' протокол явно и владелец не внёс его в прелоад лист, это то самое уязвимое окно во время которого можно провести атаку - редирект на фишинг домен, инжект js, или чё там делают в таких ситуациях обычно, но все это при условии отсутствия механизма безопасности из п.1. После первого подключения сервер ответит хедером 'Strict-Transport-Security' с конфигурацией правила по которому жертва будет в дальнейшем обращаться только по https версии, даже если лна будет пытаться явно обращаться по http. Все это актуально когда и сервер, и сам механизм - правильно сконфигурирован, но судя по моей практике это иногда абсолютно не так. Иногда натыкаюсь на мисконфиг этого заголовка в своих проектах, часто он либо просто отсутствует, либо выдаётся не там где нужно из-за того что девопс чет намудрил с прокси-сервером, либо выдаётся с коротким сроком действия. Советую почитать про это более подробно для понимания того как это работает, а практическую реализацию оставить где-то позади, году эдак в 10-15, ибо не особо актуально.

а днс хакинг актуальный ?

 

[seidziwhitehat]

а днс хакинг актуальный ?

Не совсем, стоит учитывать что в любом случае все последние браузеры высрут предупреждение пользователю про mitm атаку(сейчас уже может даже заблочат, не тестил данный вектор).
Также стоит учитывать что сейчас повсеместно вводят такие штуки как DNSSec, DoH, и т.д., и т.п, подмена днс в таком случае не будет работать.