Набираете в гугле "какой завод сделал первый в россии телетрап для аэропорта". Получаете горы ссылок на Орелтекмаш. Забиваете Орелтекмаш в гуглокарты, получаете точку на карте. Включаете спутник и видите этот вот трап на заводской площадке.
Потому что завод там находится. Это Орёлтекмаш, он как раз делает всякие нестандартные железные штуки на колесиках. Опытный образец же не будет поставлен в реальный аэропорт, так что смотреть его важные гости будут на заводском дворе. Никаких проблем.
Впереди налогов стоят исполнительные листы по зарплате и выходным пособиям. Обычные такие перечисления зарплаты, когда задержка еще не вылилась в решение суда и исполнительнй лист, стоят в одной очереди с налогами и обрабатываются в хронологическом порядке.
На голый http современные браузеры ругаются и предупреждают.
Это расчитано на пользователей, которые навроде тех, кто переводит деньги на безопасный счет и сообщает мошенникам SMS коды от Госуслуг. Таким никакие предупреждения браузера не страшны. Live dangerously как говорится, чего мелочиться то.
HSTS никто не отменял, если этим браузером хоть раз заходили на этот сайт, атака бессмысленна.
Хехехе. С HSTS есть своя отдельная заковыка, которая в одном конкретном возможном сценарии делает его бесполезным. Предположим (ну или силось мне), что я Доктор Зло, вклинился в канал жертвы, запустил SSLStrip и с помощью социальной инженерии заставил юзера набрать в адресной строке bank.com без указания схемы https://. Если юзер раньше уже заходил на bank.com и получал от него заголовок Strict-Transport-Security, то мне ничего не светит.
Однако админ сайта мог забыть включить в заголовке Strict-Transport-Security опцию includeSubdomains. В таком случае действие заголовка распространяется только на основной домен но не распространяется на поддомены. Я беру на вооружение социальную инженерию и склоняю юзера к тому что бы он набрал в адресной строке браузера не bank.com а какой-нибудь subdomain.bank.com. Ответ DNS на запрос subdomain.bank.com я могу подделать (если только у юзера не настроен какой-то свой безопасный резолвер). Все последующие HTTP запросы к subdomain.bank.com я заверну в SSL Stripping, который просто транслирует запросы к http://subdomain.bank.com в запросы к https://bank.com и потом в ответах переписывает ссылки на поддомен, и вуаля, я только что обошел HSTS :-)
Это, конечно, overkill с технической точки зрения, т.к. социальной инженерией такого юзера проще направить на сайт-клон а не заниматься всей этой штукой с SSL Stripping.
Инструментарий знает об этом и просто удаляет заголовок из полученного трафика заголовок ответа, предписывающий браузеру сделать редирект. Кроме этого он в коде страниц еще и схему доступа в ссылках <a href> заменяет с https:// на http://.
На самом деле в страницу можно воткнуть JS скрипт, который анализирует location страницы и в случае обнаружения там http:// начинает дико вопить. Но хорошо замотивированный MitM в принципе может и до этого добраться.
Нет, эта атака вне лаборатории невозможна. Подозреваю что и в лаборатории навозможна.
Для этой атаки в Kali Linux уже давно есть готовый инструмент. Собственно я о ней и узнал когда мне на стенде это показали вживую. Я не в курсе того, как часто она встречается в полях.
Не большая, не большая, а значительная. Достаточно значительная для того, что бы разработчики браузеров до сих пор не отказались от поддержки доступа к HTTP-Only сайтам. Если вам не нравится то, что браузеры до сих пор работают по HTTP без TLS (и это делает возможным атаку SSL Strip в ряде случаев, но не всегда), ну так и обращайтесь к разработчикам браузеров а не ко мне.
Как это выглядит? Браузер будет слать HTTP-запросы на 443-й порт сервера и тот не выдаст ошибку "HTTP request on HTTPS port"? Ведь на серверах сейчас поголовно все ставят правило "на любой HTTP-запрос на 80-й порт редирект 301 на https://сайт/тот-же-самый-путь".
1) Создатели современных браузеров прекрасно знают о том, что значительная чась сайтов до сих пор работает только по HTTP. При этом в качестве протокола по умолчанию в браузерах используется HTTPS.
2) Когда юзер вводит в адресную строку браузера какое-то доменное имя, например example.com, не указав при этом в явном виде схему http:// или https://, браузер делает следующее (рассматривается самый простой случай):
а) определяет IP адрес сервера.
б) предпринимает попытку достучаться до этого сервера по HTTPS (порт 443). Если это удалось и сертификат валиден то браузер продолжает работать с этим сайтом.
в) если не удалось, тогда браузер предпринимает попытку достучаться до сервера по HTTP (порт 80). Если удалось, тогда браузер показывает юзеру предупреждение о работе по незащищенному HTTP и всё, если юзер не отказался от этой затеи то браузер так и продолжает работать с сайтом по HTTP.
3) Атакая SSL Stripping заключается в том, что злоумышленник активно вклинивается в трафик между браузером и сервером и принудительно сбрасывает попытку соединения на этапе 2-б). То есть браузер пытается достучаться до сервера по HTTPS и получает от злоумышленника TCP RST - сигнал о том, что никакого HTTPS на сервере якобы нет и не будет. Сервер об этой попытке вообще ничего не знает - до него запрос на соединение даже не доходит. После этого браузер переходит на HTTP. Злоумышленник начинает пропускать весь трафик юзера через себя - все запросы браузера, поступающие по HTTP, анализируются на предмет паролей и кукисов и только потом передаются настоящему серверу уже по HTTPS. Все ответы от настоящего сервера опять же приезжают по HTTPS злоумышленнику, который модифицирует их на лету под свои нужды и уже после этого выдает их юзеру уже по HTTP.
В результате:
настоящий сервер получает все запросы по HTTPS и думает, что это браузер их прислал
браузер присылает запросы на самом деле по HTTP и показывает юзеры плашку Not secure. Какой-то ненулевый процент юзеров эту плашку просто проигнорируют по разным причинам.
злодей посередине успешно получает юзерские логины, пароли, одноразовые пароли, коды из SMS, все кукисы и копии содержимое всех просмотренных юзером страниц. Злодей может отправлят серверу любые запросы и в принципе делать любые штуки на сайте от имени юзера под его логином.
На сайт с HTTPS при определенных условиях MitM может выполнить атаку SSL Stripping, заставив браузер работать по HTTP в то время, пока юзер думает, что работает по HTTPS.
От SSL Stripping спасают три вещи:
наличие доменного имени сайта в HSTS Static Preload List. Если домен есть в этом списке то браузер будет работать с этим сайтом только по HTTPS. В списке сейчас всего примерно 170 тысяч доменных имен, что как бы намекает, что защищена только малая часть сайтов.
включение режима HTTPS Only в браузере. В таком случае браузер в принципе бедет ругаться на сайт с HTTP. Для включения этого режима в настройках браузера есть специальная галочка в разделе Privacy and Security. Обычные такие люди туда никогда не аходят.
Маленькая надпись "Not secured" рядом с доменным именем в адресной строке браузера. Предполагается, что юзер сам разберется в том, хочет он продолжать работать с незащищенным трафиком или нет.
2FA и OTP от этой напасти не спасают.
PS Госуслуги, например, отсутсвуют в HSTS Static Preload.
Прикручивание ЕСИА не имее значания т.к. после 1 сентября работать с доменами .ru/.рф/.su смогут только юрлица из специального перечня, одним из учредителей которых является Российская Федерация. Перечень составляется правительством РФ. Там нигде не написано, что прикучивание ЕСИА автоматически добавляет существующего регистратора в этот вот перечень.
Они ее и не ломали. Полиция зашла через дверь в гараже, которая открывается кодом снаружи. Код бабушка сама же и предоставила оператору "Всё ли с вами в порядке?" как раз на этот случай.
В современных браузерах - да. Однако некоторый процент юзеров пользуются старыми смартфонами, в которых ничего не обновлено и старые браузеры пропускают mixed content по умолчанию.
Во первых браузер не станет его загружать по http если страница на https.
Станет, если браузер работает на смартфоне примерно 7-летней давности, который по какой-то причине больше не обновляют. Mixed content раньше не считался угрозой, запросы по http не блокировались и не редиректились на https.
Во вторых, кто вставит в запрос X-Forwarded-For, впн чтоли?
VPN и HTTP-прокси это разные вещи. X-Forwarded-For это изначальная фишка HTTP-прокси, которая раньше обычно на прокси была включена но потом ее стали выключать в пылу борьбы за приватность.
Короче говоря, пятый пункт в моем списке это такие отголоски прошлого, которые эксплуатировались во весь рост лет 6-8 назад, но к текущему времени встречаются очень и очень редко.
Это вот эта атака описана еще в 2018 году.
Он не выкатывается никуда. Это стационарная конструкция - она одним концом к земле прибита.
Набираете в гугле "какой завод сделал первый в россии телетрап для аэропорта". Получаете горы ссылок на Орелтекмаш. Забиваете Орелтекмаш в гуглокарты, получаете точку на карте. Включаете спутник и видите этот вот трап на заводской площадке.
Потому что завод там находится. Это Орёлтекмаш, он как раз делает всякие нестандартные железные штуки на колесиках. Опытный образец же не будет поставлен в реальный аэропорт, так что смотреть его важные гости будут на заводском дворе. Никаких проблем.
И еще РКНорио пусть добавят! Он будет ленты замедлять и резать в случайных местах.
Впереди налогов стоят исполнительные листы по зарплате и выходным пособиям. Обычные такие перечисления зарплаты, когда задержка еще не вылилась в решение суда и исполнительнй лист, стоят в одной очереди с налогами и обрабатываются в хронологическом порядке.
Основание - ст. 855 ГК РФ.
Это расчитано на пользователей, которые навроде тех, кто переводит деньги на безопасный счет и сообщает мошенникам SMS коды от Госуслуг. Таким никакие предупреждения браузера не страшны. Live dangerously как говорится, чего мелочиться то.
Хехехе. С HSTS есть своя отдельная заковыка, которая в одном конкретном возможном сценарии делает его бесполезным. Предположим (ну или силось мне), что я Доктор Зло, вклинился в канал жертвы, запустил SSLStrip и с помощью социальной инженерии заставил юзера набрать в адресной строке bank.com без указания схемы https://. Если юзер раньше уже заходил на bank.com и получал от него заголовок Strict-Transport-Security, то мне ничего не светит.
Однако админ сайта мог забыть включить в заголовке Strict-Transport-Security опцию includeSubdomains. В таком случае действие заголовка распространяется только на основной домен но не распространяется на поддомены. Я беру на вооружение социальную инженерию и склоняю юзера к тому что бы он набрал в адресной строке браузера не bank.com а какой-нибудь subdomain.bank.com. Ответ DNS на запрос subdomain.bank.com я могу подделать (если только у юзера не настроен какой-то свой безопасный резолвер). Все последующие HTTP запросы к subdomain.bank.com я заверну в SSL Stripping, который просто транслирует запросы к http://subdomain.bank.com в запросы к https://bank.com и потом в ответах переписывает ссылки на поддомен, и вуаля, я только что обошел HSTS :-)
Это, конечно, overkill с технической точки зрения, т.к. социальной инженерией такого юзера проще направить на сайт-клон а не заниматься всей этой штукой с SSL Stripping.
Инструментарий знает об этом и просто удаляет заголовок из полученного трафика заголовок ответа, предписывающий браузеру сделать редирект. Кроме этого он в коде страниц еще и схему доступа в ссылках <a href> заменяет с https:// на http://.
На самом деле в страницу можно воткнуть JS скрипт, который анализирует location страницы и в случае обнаружения там http:// начинает дико вопить. Но хорошо замотивированный MitM в принципе может и до этого добраться.
Для этой атаки в Kali Linux уже давно есть готовый инструмент. Собственно я о ней и узнал когда мне на стенде это показали вживую. Я не в курсе того, как часто она встречается в полях.
Вы там у себя сами с собой спорите что ли? Я не разработчик браузеров, вы меня перепутали с кем-то.
Не большая, не большая, а значительная. Достаточно значительная для того, что бы разработчики браузеров до сих пор не отказались от поддержки доступа к HTTP-Only сайтам. Если вам не нравится то, что браузеры до сих пор работают по HTTP без TLS (и это делает возможным атаку SSL Strip в ряде случаев, но не всегда), ну так и обращайтесь к разработчикам браузеров а не ко мне.
Вы что, не верите в существование сайтов HHTP-Only, ради которых браузеры до сих пор поддерживают HTTP без шифрования?
12sotok.spb.ru.
Про кремлинру я не понял, извините.
А зачем собственно? Атака SSL Stripping делается не на них.
1) Создатели современных браузеров прекрасно знают о том, что значительная чась сайтов до сих пор работает только по HTTP. При этом в качестве протокола по умолчанию в браузерах используется HTTPS.
2) Когда юзер вводит в адресную строку браузера какое-то доменное имя, например example.com, не указав при этом в явном виде схему http:// или https://, браузер делает следующее (рассматривается самый простой случай):
а) определяет IP адрес сервера.
б) предпринимает попытку достучаться до этого сервера по HTTPS (порт 443). Если это удалось и сертификат валиден то браузер продолжает работать с этим сайтом.
в) если не удалось, тогда браузер предпринимает попытку достучаться до сервера по HTTP (порт 80). Если удалось, тогда браузер показывает юзеру предупреждение о работе по незащищенному HTTP и всё, если юзер не отказался от этой затеи то браузер так и продолжает работать с сайтом по HTTP.
3) Атакая SSL Stripping заключается в том, что злоумышленник активно вклинивается в трафик между браузером и сервером и принудительно сбрасывает попытку соединения на этапе 2-б). То есть браузер пытается достучаться до сервера по HTTPS и получает от злоумышленника TCP RST - сигнал о том, что никакого HTTPS на сервере якобы нет и не будет. Сервер об этой попытке вообще ничего не знает - до него запрос на соединение даже не доходит. После этого браузер переходит на HTTP. Злоумышленник начинает пропускать весь трафик юзера через себя - все запросы браузера, поступающие по HTTP, анализируются на предмет паролей и кукисов и только потом передаются настоящему серверу уже по HTTPS. Все ответы от настоящего сервера опять же приезжают по HTTPS злоумышленнику, который модифицирует их на лету под свои нужды и уже после этого выдает их юзеру уже по HTTP.
В результате:
настоящий сервер получает все запросы по HTTPS и думает, что это браузер их прислал
браузер присылает запросы на самом деле по HTTP и показывает юзеры плашку Not secure. Какой-то ненулевый процент юзеров эту плашку просто проигнорируют по разным причинам.
злодей посередине успешно получает юзерские логины, пароли, одноразовые пароли, коды из SMS, все кукисы и копии содержимое всех просмотренных юзером страниц. Злодей может отправлят серверу любые запросы и в принципе делать любые штуки на сайте от имени юзера под его логином.
Я просто оставлю это здесь: Шибболет .
На сайт с HTTPS при определенных условиях MitM может выполнить атаку SSL Stripping, заставив браузер работать по HTTP в то время, пока юзер думает, что работает по HTTPS.
От SSL Stripping спасают три вещи:
наличие доменного имени сайта в HSTS Static Preload List. Если домен есть в этом списке то браузер будет работать с этим сайтом только по HTTPS. В списке сейчас всего примерно 170 тысяч доменных имен, что как бы намекает, что защищена только малая часть сайтов.
включение режима HTTPS Only в браузере. В таком случае браузер в принципе бедет ругаться на сайт с HTTP. Для включения этого режима в настройках браузера есть специальная галочка в разделе Privacy and Security. Обычные такие люди туда никогда не аходят.
Маленькая надпись "Not secured" рядом с доменным именем в адресной строке браузера. Предполагается, что юзер сам разберется в том, хочет он продолжать работать с незащищенным трафиком или нет.
2FA и OTP от этой напасти не спасают.
PS Госуслуги, например, отсутсвуют в HSTS Static Preload.
Прикручивание ЕСИА не имее значания т.к. после 1 сентября работать с доменами .ru/.рф/.su смогут только юрлица из специального перечня, одним из учредителей которых является Российская Федерация. Перечень составляется правительством РФ. Там нигде не написано, что прикучивание ЕСИА автоматически добавляет существующего регистратора в этот вот перечень.
Они ее и не ломали. Полиция зашла через дверь в гараже, которая открывается кодом снаружи. Код бабушка сама же и предоставила оператору "Всё ли с вами в порядке?" как раз на этот случай.
В современных браузерах - да. Однако некоторый процент юзеров пользуются старыми смартфонами, в которых ничего не обновлено и старые браузеры пропускают mixed content по умолчанию.
Станет, если браузер работает на смартфоне примерно 7-летней давности, который по какой-то причине больше не обновляют. Mixed content раньше не считался угрозой, запросы по http не блокировались и не редиректились на https.
VPN и HTTP-прокси это разные вещи. X-Forwarded-For это изначальная фишка HTTP-прокси, которая раньше обычно на прокси была включена но потом ее стали выключать в пылу борьбы за приватность.
Короче говоря, пятый пункт в моем списке это такие отголоски прошлого, которые эксплуатировались во весь рост лет 6-8 назад, но к текущему времени встречаются очень и очень редко.