Группа исследователей из нескольких университетов Германии разработала новый метод MITM-атаки на HTTPS, дающий возможность извлечь Cookie с идентификаторами сеанса и другие конфиденциальные данные, а также добиться выполнения произвольного кода JavaScript в контексте другого сайта. Атака получила название ALPACA и может быть применена к TLS-серверам, реализующим разные протоколы прикладного уровня (HTTPS, SFTP, SMTP, IMAP, POP3), но использующим общие TLS-сертификаты...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=55307
Оригинально. Из категории идей, которые кажутся очевидными после того как кто-то обратит на них внимание.Но ещё больше удивило, что нашлось больше 40 тысяч сайтов, использующий один SSL-сертификат с FTP-серверами, от которых как казалось уже все кто можно отказался.
ftp - дрянь-протокол, но зато его все знают.
Не забудьте то же самое сказать про email (SMTPS, POP3S, IMAPS).
"Почтовые" протоколы дрянь и ужас.
К ним же в кучу nfs3 и всякие сипы и прочие аудио видео звонки которым не хватает одного соединения на один порт.
> всякие сипы и прочие аудио видео звонки которым не хватает одного соединения на один порт.Итак давай представим себе ситуацию, что есть группа людей из 4-х человек, которые общаются в голосовом/видео чате. Первый второму перекидывает файл, третий пишет им всем сообщения, а четвертый слушает что они все говорят, находясь в мобильной сети, переключаясь между wcdma/hsdpa/hspa+/lte сетями, потому что едет в машине. Ну так вот потом четвертый пришел домой и попал в Wi-Fi сеть и тут же добавил в разговор пятого.
Вот для организации всего этого достаточно SIP в сочетании с теми протоколами, которые идут вместе с ним =)
А теперь, умник, попробуй мне построить то же самое на клиент-серверной сети с одним соединением на порт. Я посмотрю на тебя. Было уродство под названием XMPP, да сплыло, когда оказалось, что нужно 80% SIP портировать в него чтобы голос добавить. Вот и получился XMPP Jingle, который сдох. Пиринговая сеть рядышком с клиент-серверным XMPP, и, нет, через один порт не получилось. Ни у кого не получится.
Дрянь и ужас - это уровень твоего образования. Тех у кого нет жизни вне одной клиент-серверной TCP-сессии лучше держать подальше от проектирования протоколов. И если внутри FTP еще можно было бы как-то обойтись, то медиа...
А что НЕ "дрянь и ужас", я стесняюсь спросить? Ну кроме HTTP. Или только на вебне жить прикажешь? Ой. А как же в этой самой вебне делается медиа? Ты не поверишь. ICE+SDP+STUN+TURN+SRTP поверх вебсокетов, которые идут "вторыми" портами. Ой всё...
>умникСпасибо.
>попробуй мне
>Я посмотрю на тебя
>Дрянь и ужас - это уровень твоего образованияМне это саморазоблачение ненужно в общем комментировать.
>Ой. А как же в этой самой вебне делается медиа? Ты не поверишь. ICE+SDP+STUN+TURN+SRTP поверх вебсокетов, которые идут "вторыми" портами
Да, это дрянь и ужас абсолютная, тут разве что согласен.
>XMPP
Смешались люди кони у вас в кучу одну.
Если ты осуждаешь реализации с множеством соединений, значит у тебя есть рабочие кейсы с одним на все?
Есть реализации? Есть что предложить? Рабочее, для всего медиа.
Просто надо задаться вопросом: а что такое "порт"? ;)
Пример протокольного Ада:https://www.opennet.dev/opennews/art.shtml?num=54058
https://www.opennet.dev/opennews/art.shtml?num=54480
Сразу видно что ты новости читать умеешь, а про что они написаны не знаешь. Не имел дело, видимо...Специально для таких как ты я подробно объяснял в чем там проблема. Открой каждую из этих новостей и в комментах найди гигантскую телегу (моё авторство) с объяснением о проблемах ALG и что оно не имеет никакого отношения к стандартам SIP. Это истории про отсутствие стандартов на NAT и как неосиляторы-сетевики не могут ни черта сделать дальше TCP-сессии.
Готовься. Надвигается QUIC-транспорт, не HTTP/3 а именно QUIC, смотри не перепутай. Он уже есть, но будет больше. Оно выглядит как один порт, но там куча разномастных данных внутри UDP-потока. Ох чую неграмотные сетевики, горя хапнут снова. Черновики на RTP over QUIC уже публиковали вроде бы.
И чем больше ты будешь узнавать, работать, понимать тем больше тебе будет мешать твоя категоричность вокруг протоколов. Избавься от нее до того как диплом сдашь. Проще будет =)
Чел, мне твои индюшачии петушения ни к чему.
У тебя серьезные проблемы с чувством собственной важности.
Меня сокращения из 3х и 4х букв не пугают и не впечатляют, это элементарные вещи знание которых не должно по идее раздувать индюка до размеров дирижабля.
Не пойму, если я индюк, и меня раздуло до размеров дирижабля, то почему лопнул именно ты? XD
А сейчас мы выслушаем как должен выглядеть стандарт ната на удп конечно?
Да хоть как. Но как-то должен.
Сейчас же их пять (в Википедии они описаны, в английской, конечно. С чУдными картинками и большими буквами, прямо как азбука у Буратино), и каждый раз приходится гадать, с чем имеем дело.
> Не забудьте то же самое сказать про email (SMTPS, POP3S, IMAPS).У SMTP, POP3 и IMAP есть STARTTLS, с которым этот фокус не пройдёт.
> Не забудьте то же самое сказать про email (SMTPS, POP3S, IMAPS).не согласен как минимум про первых два и отчасти про imap.
во-первых используется один порт и одно соединение (а не два навстречу друг другу).
дальше продолжать ?
FTP отличный протокол. Это руки дрянь у тех кто его не осилил и везде всунул HTTP
Попробуйте запостить этот же комментарий через FTP, а то как-то голословно.
А ты стрелки не переводи. FTP не для того чтобы коменты постить и javascript запускать. А для передачи фалов. И сравляется он с этим куда лучше HTTP и/или HTTPS.
О дааа.. Одна проблема с буквой "я" чего стоит, а про классику в виде отсутствия понятия кодировки имен файлов (и невозможности договориться о ней), работу через два независимых порта, что создает свои неприятности (ну-ка попробуйте с пол-тычка завернуть ftp в ssh туннель, аналогично http) и неопределенность даты файлов уж и не говорим..
FXP покажи через http.
FXP покажи через ftp, шутник.
rfc959 пункт 2.3.
> rfc959 пункт 2.3.Ты б ещё на man сослался, как его включить.
Только его никто не включает. Угадаешь, почему?
Да я сразу понял что ты афедроном повертеть сюда зашёл. Не надо было это лишний раз доказывать.
Ну ты сразу понял, что был неправ.
> Ну ты сразу понял, что был неправ.Он понял я думаю. Куда лучше читать маны и rfc, чем общаться с эпичными неосиляторами.
Поэтому куда успешнее и продуктивнее потратил своё время.
>> rfc959 пункт 2.3.
> Ты б ещё на man сослался, как его включить.
> Только его никто не включает. Угадаешь, почему?Я угадаю, ты маны читать не умеешь, как и мноние, куда там до rfc
> Я угадаю, ты маны читать не умеешь, как и мноние, куда там
> до rfcКонечно. Ты же мне покажешь сервер в интернете с работающим FXP, теоретик, читавший маны и RFC? Я поучусь, куда нам.
Сложно придумать для чего оно может быть, но так и быть. Поднял. Нужнее мне оно от этого не стало.> Конечно. Ты же мне покажешь сервер в интернете с работающим FXP
Конечно. А теперь ты мне покажи FXP на http и вообще где это может понадобиться. Знаток.
> FXP покажи через http.Да никому нафиг не сдался тот FXP.
У FTP было три киллер-фичи:
1. Скорость. Роутер с подключенным жёстким диском отдаёт по FTP в локалку файлы на скорости этого жёсткого диска. Без гигагерцевого процессора и гигабайта оперативки.
2. Поддержка upload-а и download-а каталогов.
3. Работает в любой ОС из коробки, прямо в браузере.П.3. старательно пытаются выпилить.
Но даже без него альтернатив банально нет.Никакой протокол не совмещает в себе эти две возможности.
> О дааа..Именно, да.
> Одна проблема с буквой "я" чего стоит, а про классику
> в виде отсутствия понятия кодировки имен файлов (и невозможности договориться о
> ней),Интересно, почему у меня нет этой проблемы? А? Может маны почитать не?
> работу через два независимых порта, что создает свои неприятности
А почему у меня работает через 1? Магия?
> (ну-ка
> попробуйте с пол-тычка завернуть ftp в ssh туннель, аналогично http)sftp это не ftp с ssl. Это на секунду часть ssh и заводится на ура с пол оборота. Но мы же iPony style, неосиляторы.
> и
> неопределенность даты файлов уж и не говорим..Откуда вы берёте все эти проблемы. Десятилетиями весят публичные репозитории и ни у кого нет проблем. Одни только неосиляторы ноют.
>> Одна проблема с буквой "я" чего стоит, а про классику
>> в виде отсутствия понятия кодировки имен файлов (и невозможности договориться о
>> ней),
> Интересно, почему у меня нет этой проблемы? А? Может маны почитать не?И какими же манами вы добавите поддержку передачи кодировки?
И какими манами почините букву я в cp1251 в сервере, соответствующем RFC?
>> работу через два независимых порта, что создает свои неприятности
> А почему у меня работает через 1? Магия?Наверное, вы ходите на сервер типа https://ftp.coolserver.com/ и думаете, что это ftp. Ан нет!
>> (ну-ка
>> попробуйте с пол-тычка завернуть ftp в ssh туннель, аналогично http)
> sftp это не ftp с ssl. Это на секунду часть ssh и
> заводится на ура с пол оборота. Но мы же iPony style,
> неосиляторы.Причем тут sftp вообще? Я про типичную ситуацию когда сервер открыт только для локалхоста, или для внутренней сети, но VPN нет возможности открыть и тп. ssh -L - работает очевидно для http, пускаете и натравливаете браузер на локалхост. Для ftp.. внезапно.. все сложно.
>> и
>> неопределенность даты файлов уж и не говорим..
> Откуда вы берёте все эти проблемы. Десятилетиями весят публичные репозитории и ни
> у кого нет проблем. Одни только неосиляторы ноют.Ну расскажите тогда, вот вы в TZ=MSK, а сервер например где-то в США. Как обеспечивается корректная дата у скаченного файла в случае FTP? Опаньки... Когда FTP придумавали, вообще не задумывались о не-ASCII, временных зонах, стандартиризации формата листинга и тп. Другой несколько мир был, ага.
FTP был хорош в 80-ые в рамках использования внутри США. Агитировать за него сейчас могут только маразматики, вот точно...
> И какими же манами вы добавите поддержку передачи кодировки?
> И какими манами почините букву я в cp1251 в сервере, соответствующем RFC?Не спорю, была такая проблема. Где-то в конце 90-х начале 2000-х. Но она давным давно решена. Называется UTF
> Наверное, вы ходите на сервер типа https://ftp.coolserver.com/ и думаете, что это ftp.
> Ан нет!Прикинь. ftp://ftp.coolserver.com
> Причем тут sftp вообще? Я про типичную ситуацию когда сервер открыт только
> для локалхоста, или для внутренней сети, но VPN нет возможности открыть
> и тп. ssh -L - работает очевидно для http, пускаете и
> натравливаете браузер на локалхост. Для ftp.. внезапно.. все сложно.1) Нет не сломано
2) Если у тебя уже есть ssh внутрь то ни http ни ftp тебе не нужен. Пробрось всю сеть через ssh тунель + vpn> Ну расскажите тогда, вот вы в TZ=MSK, а сервер например где-то в
> США. Как обеспечивается корректная дата у скаченного файла в случае FTP?
> Опаньки... Когда FTP придумавали, вообще не задумывались о не-ASCII, временных зонах,
> стандартиризации формата листинга и тп. Другой несколько мир был, ага.А вы просто путаете и подменяете понятия. Если вы о дате создания файла к примеру. То скачав файл его дата создания логично должна быть той датой когда вы его скачали себе, а не когда он был выложен на сервер. И это логично.
Еже ли вы скачав файл в 2021 году получаете дату создания файла 2019 то это како-то бред. И вся система отслеживания устаревших файлов летит впень.
> FTP был хорош в 80-ые в рамках использования внутри США. Агитировать за
> него сейчас могут только маразматики, вот точно...FTP хорош и сейчас. У него есть своя ниша и да, я знаю о действительных недостатках FTP а не то высасоное из пальца что тут все любят приводить, он не панацея от всего да и не должен быть. У него своё назначение и в этом он превосходен. Я не агитирую за FTP везде. Мне не нравятся неосиляторы которые выпиливают отличные технологии просто потому что они их не поняли.
А вот за полный отказ от отличного протокола для локальных файловых помоек, публичных глобальных файловых помоек и за превод всего и вся на HTTP вот точно могут только маразматики и эпичные неосиляторы вроде iPony
> Еже ли вы скачав файл в 2021 году получаете дату создания файла
> 2019 то это како-то бред. И вся система отслеживания устаревших файлов
> летит впень.Чувааааак. Ты теоретик. Признайся в этом и перестань это показывать в каждом посте.
Спасибо заранее.
> Чувааааак. Ты теоретик. Признайся в этом и перестань это показывать в каждом
> посте.Чувак. Признайся, ты эпичный неосилятор из армии iPony и такой-же нытик как Fracta1L. И это видно в каждом посте. Ну и бухаешь заметно что не слабо.
У меня какраз всё работает. И пользуется каждый день. А ты вцепился в этот FXP как буд-то это край технологий и прямо киллерфича что без неё жить нельзя. Вот это и называется теоретик.
Так что не подменяй понятия и начни уже работать с реальными задачами а не высасаными из пальца с теоретической нужностью двум землекопа.
> Спасибо заранее.
Пожалуйста.
Молодец. Признался таких что нытик и неосилятор.Признание это первый шаг к выздоровлению.
Жаль не поможет, в твоём случае последний.
> sftp это не ftp с ssl. Это на секунду часть ssh и
> заводится на ура с пол оборота. Но мы же iPony style,
> неосиляторы.Обожаю опеннетовский комментаторов. Ты даже не понял, что у тебя спросили.
Про FXP ты тоже не понял.
Но апломбу выше крыши, учить всех заявился.
> Обожаю опеннетовский комментаторов. Ты даже не понял, что у тебя спросили.Обожаю эпичных неосиляторов. Которые не в состоянии уже даже дерево сообщение проследить. Один только гулоконвесейшены понимают.
> О дааа.. Одна проблема с буквой "я" чего стоит, а про классику в виде отсутствия понятия кодировки имен файлов (и невозможности договориться о ней),А зачем кодировки, когда всё в UTF-8?
> работу через два независимых порта, что создает свои неприятности (ну-ка попробуйте с пол-тычка завернуть ftp в ssh туннель, аналогично http)
Для ssh не нужен ftp. Но если очень хочется, то можно 3мя способами (протокол позволяет задавать фиксированные порты, а у ssh есть -D).
> и неопределенность даты файлов уж и не говорим..
Определена не хуже чем в http.
И делает он это слишком сложно. Например делать дополнительное соединение, чтобы передать данные -- это вызывает огромное количество неполадок при использовании FTP.
> И делает он это слишком сложно. Например делать дополнительное соединение, чтобы
> передать данные -- это вызывает огромное количество неполадок при использовании FTP.Эпичные неосиляторы, когда же вы научитесь доки читать. Нормально ходит и через один порт.
> Эпичные неосиляторы, когда же вы научитесь доки читать. Нормально ходит и через один порт.Именно FTP ходит? Или какой-нибудь SFTP, который вообще другой протокол?
> А для передачи фалов.фаллов. и даже местами фаллловъ (чтобы выглядели подлиннее и потверже).
>> А для передачи фалов.
> фаллов. и даже местами фаллловъ (чтобы выглядели подлиннее и потверже).Это чтобы неосиляторам было чем перед дефачками хвастаться. Своего то тю....
ну через telnet на bbs сидели, а то целый фтп!
> ну через telnet на bbs сидели, а то целый фтп!было дело. но я уже забыл как там фаллы и ваагины передавали.
то ли клиент telnet запускал ZModem и отдавал ему поток, то ли как-то еще.
Ужасный он. Использует нетривиальную схему соединений вместо одного TCP стрима.
Из за чего его ненавидели уже 20лет назад.Фаерволить подобное сущий ад.
Contrack не пробывал, не?
?
> Contrack не пробывал, не?https://www.opennet.dev/opennews/art.shtml?num=54058
https://www.opennet.dev/opennews/art.shtml?num=54480анона-фанатика SIP выше по треду тоже касается.
вот на этот коммент особое внимание
https://www.opennet.dev/openforum/vsluhforumID3/122380.html#119
> вот на этот коммент особое внимание
> https://www.opennet.dev/openforum/vsluhforumID3/122380.html#119В коменте пишут, что производители роутеров ленивые.
Я думаю дело не просто в том, что ленивые, а в том, что это реально сложно, особенно для бытовых железок с ограниченной памятью и железом.
И опять таки встаёт вопрос совместимости с обратной стороны софта, который уже вероятно ожидает конкретную реализацию ната.Ну и не только в НАТе дело, попробуйте такого монстра протокольного банально разрешить или запретить в фаерволле.
А так да, протокольный Ад хорошо описан.
> Я думаю дело не просто в том, что ленивые, а в том, что это реально сложно, особенно для бытовых железок с ограниченной памятью и железом.Обыкновенный SIP-телефон стоит не сильно дороже роутеров и памяти в нём меньше, а половину цены составляют лицензии на всякие кодеки G729 и прочий проприетарный AMR. Так что враки.
> И опять таки встаёт вопрос совместимости с обратной стороны софта, который уже вероятно ожидает конкретную реализацию ната.
Совместимость может быть только со стандартами. Ни у NAT, ни у ALG нет стандарта. Они все вендороспецифичные и не совместимые друг с другом. Но ты этого не знаешь, потому что для того чтобы увидеть насколько хреново сделан NAT нужно воспользоваться чем-то сложнее клиент-серверной TCP-сессии. А у тебя проблема в стиле все что не могу зафаерволить с натом всё плохое.
> Ну и не только в НАТе дело, попробуйте такого монстра протокольного банально разрешить или запретить в фаерволле.
Этот протокол так устроен, потому что его вечно ломают косорылые бараны, которые по ошибке называют себя сетевыми администраторами. Запретить его можно только если он нешифрованый. TLS для сессий и DTLS для медиа и плакала ваша блокировка фаерволом, разве что "по IP вычислять". По DPI можете точечно гадать по хостнеймам в сертификатах. Опять же удачи с TLS1.3 и ESNI. А разрешить его клиентам просто берёте и просто выключаете ALG. На внешний современный SIP-сервер ваши клиенты подключатся из-под любого ната. А свой сервак "прокидывать" не рекомендую, лучше сразу обратитесь к системному администратору.
>Обыкновенный SIP-телефон стоит не сильно дороже роутеров и памяти в нём меньшеРечь шла о роутерах.
Очевидно создавать богомерзкий сложный трафик и работать с ним - задачи разные.
Ну, это мое предположение.Так-же, ничего хорошего сложность протокола не делает и для него самого, как в плане банальной реализации так и в плане безопасности.
>а половину цены составляют лицензии на всякие кодеки G729 и прочий проприетарный AMR
Еще и платить за бекдоры.
Жуть тьма и мрак.>А у тебя проблема в стиле все что не могу зафаерволить с натом всё плохое.
У меня нет таких проблем.
>Этот протокол так устроен, потому что его вечно ломают косорылые бараны, которые по ошибке называют себя сетевыми администраторами.
Ну понятно, протокол чудесный это интернет плохой а протокол то-же плохой хоть и чудесный но плохой потому что интернет плохой. А интернет плохой потому что "косорылые бараны, которые по ошибке называют себя сетевыми администраторами" неспособны понять всю чудесность чудесного протокола который чудесный но из за баранов плохой.
>>> Я думаю дело не просто в том, что ленивые, а в том, что это реально сложно, особенно для бытовых железок с ограниченной памятью и железом.
>> Обыкновенный SIP-телефон стоит не сильно дороже роутеров и памяти в нём меньше
> Речь шла о роутерах.Среднестатистический телефон слабее роутера. Сильно.
> Очевидно создавать богомерзкий сложный трафик и работать с ним - задачи разные.
> Ну, это мое предположение.Предположение в корне не верное. В случае с SIP безопасность, балансировка нагрузки и вообще любое управление с точностью до пакета делается на SIP-сервере или B2BUA (back to back user agent) в зависимости от нужд, опять же. B2BUA это роль топологии SIP. Так как это пиринговый протокол, то в нем один и тот же условный сервер может выполнять разные роли в зависимости от соединения. То сервер, то клиент, то прокси, то B2BUA. B2BUA нужны если нужно терминировать сессии. На базе этой роли строят то, что называют модным словом SBC (Session Border Controller) или Application Firewall. Балансируют же сервера и прокси.
А теперь возьмем абсолютно бесплатный и свободный Kamailio, который на небольшом устройстве не толще неттопа будет играючи менеджить 10000 сессий в секунду.Этот трафик "сложный" только в инженерном смысле. То есть это траффик пиринговой сети, которая может быть еще и децентрализирована до определенной степени. В одном соединении сессия с метаданными о другой сессии, и другая сессия отдельная. Чтобы менеджить вторую нужно её понимать, чтобы понимать целиком и контролировать, нужно реализовать SIP на промежуточном устройстве. SIP это протокол утсановки ДРУГИХ сессий. Там не только медиа. Там любую пиринговую сеть на уровне приложения можно построить. По это даже есть RFC, что траффик и топология второй сессии может быть любым. Например, через него RDP легко пролазит =)
> Еще и платить за бекдоры.
> Жуть тьма и мрак.Кодеки это обычные кодеки, для аудио. Ну то есть с тем же успехом нельзя слушать ничего кроме Ogg и смотреть только AOM/VP8-9. Там проблема отчислений при патентованных алгоритмах. Шапочку из фольги можно снять.
> У меня нет таких проблем.
Есть. "Протокольный Ад", "богомерзкий траффик" и прочая предосудительность к тому в чем не разбираешься - вот настоящее мракобесие. Лечится образованием.
> Ну понятно, протокол чудесный это интернет плохой а протокол то-же плохой хоть и чудесный но плохой потому что интернет плохой...
Вообще в целом да, но лучше поубавить максимализм и перестать делить мир на белое и черное.
Задачи по медиа, особенно по телефонам традиционно развиваются отдельно от вендоров сетевого оборудования и зачастую вне интернета. Медиа существовало еще до интернета и прекрасно жило и без него. Есть задачи и эти задачи сложные, особенно когда дело касается видео-конференцсвязи на много человек (больше восьми).
И да, сетевое оборудование исторически имеет костыли с ALG. И да многие сетевые администраторы, которые дальше Олифера в институте ничего не читали вырастают неграмотными в вопросах пиринговых сетей. А потом когда что-то пару раз не получилось вместо того чтобы разобраться ноют на форумах дескать все протоколы плохие, а я дартаньян... такое себе.
Самое пожалуй уморительное было увидеть, как такой админ ставит сипофон в офис, фиксирует ренджи портов, пробрасывает порты на роутере. И жалуется, дескать, вот какой гадкий SIP, несекурный. Боты звонят на телефон и молчат, тётенька жалуется у него. Ну и как такому объяснить, что этот телефон для бота то же самое что сервер? Что это ОДНОРАНГОВАЯ СЕТЬ. Что они пытаются деньги со счетов украсть через платные номера зареганные где-то в Африке, но не могут, потому что это просто телефон, а не шлюз или сервер... Классический фродинг, кстати, который был еще до VoIP. У него видите ли телефон не звонит, поэтому он решил порты пробросить... А на роутере стоит ALG, которое ломает ему всю связь.
Вот кстати интересно, как собственно решается вопрос безопасности, ну хоть с тёткой этой.
Есть несколько вариантов, которые лучше комбинировать1) ACL до нужных SIP-серверов и их медиапроксикластеров (уточнять у провайдеров перечень IP) и хоть что угодно пробрасывайте себе, но суть в том, что телефон сейчас не обязан смотреть в интернет напрямую.
Если там вдали какой-то SIP-сервер не релеит траффик и не пишет разговоры, а соединяет напрямую, то белый список ACL не поможет, потому что медиа-соединение пойдет напрямую вообще на другие IP клиентов. Вот если бы заранее знать перечень возможных IP... Для таких задач и нужен SIP-сервер/SBC, чтобы разрешать оперативно.2) Самый простой способ для обычного телефона в 2021-ом году, когда SIP-сервер в публичном интернете - это NAT любого рода, кроме Fullcone при выключенном UPnP вообще без DST-NAT.
SIP его обойдет, а роутер не даст установить входящее соединение. На сервере и на телефоне при этом может быть просто rport ну или накрайняк STUN/TURN. Если удаленный сервер пишет разговоры, то даже STUN не надо, потому что траффик и тай пойдет через него как через relay. Так работают АТС-ки построенные поверх B2BUA вроде asterisk.
3) Не пользоваться старым китайским телефоном, который принимает анонимные звонки.
Телефония это не сам SIP. Телефония строится поверх SIP. В ней есть понятие DID (Direct Inward Dial) и диалплана. Самые дешевые китайские телефоны могут не иметь поддержки диалплана вовсе. В идеале при поступлении входящего звонка он должен поступить на корректную "учетку", под которую в диалплане телефона появится DID. Это защита на уровне телефона. Благо, анонимных телефонов сейчас не так много.
В зависимости от возможностей/подконтрольности роутера можно выбрать любую комбинацию. Вообще защиты там должно быть всегда 2. Одна на фаерволе, а вторая по смыслу сессий. В случае с телефонией лучше не брать телефоны, которые всегда зазвонят если позвонить на IP:порт. Это отключать надо по-возможности, что опять же не спасет тех у кого номер телефона 101. В зависимости от реализации есть некий endpoint, которому должен предназначаться звонок. Если его нет, то и звонок такой телефон должен отсечь.Если страшно сидеть с такой динамикой можно поставить B2BUA, прицепить телефон к нему, а его к вышестоящему SIP-серверу. Вообще, если мы говорим о серверах к которым прицепляются телефоны с неизвестно каких публичных сетей, то нужно поднять Fail2Ban... как всегда. Если DPI-скриптиком не обойтись, ставьте Kamailio желательно на отдельном IP и проверяйте на нем входящие пакеты. Он на себя может и регистрацию взять сильно разгрузив внутрикорпоративные АТСки. Кстати, DPI-скриптик с телефоном, когда сервер во вне не прокатит.
Астериски, кстати, лучше защищать через ACL, потому что они вообще не очень умеют в защиту от DoS. Это разнопротокольная АТС-ка, она даже не полноценный SIP-сервер. Дальше B2BUA она не умеет... да ей и не надо. Опять же, перед ней нужно ставить Kamailio с конфигами собственного приготовления или любую SBC по вкусу, если нужно выставить её напрямую в интернет. Вообще когда-то во FreePBX ваяли фаервол с автобаном, но помнится потом в очередном PHP-модуле нашлась очередная уязвимость и всех поломали. Астериск и безопасность в одном предложении трудно располагать из-за его технических ограничений. Он же SIP до конца не поддерживает и не стремится. Узкоспециализированное ПО.
А ну и да, пароли на 16 символов минимум, а лучше с TLS, если можете себе позволить =)
SIP для аутентификации использует Digest, а это, мягко говоря, устаревший метод аутентификации.
Спасибо, сохраню на случай если придётся таким заниматься.
Надеюсь конечно что нет :)
> Медиа существовало еще до интернета и прекрасно жило и без негоPOTS сдох. ISDN сдох. ATM ("another terrible mistake") сдох.
все что приходит от телефонистов - сдохнет.
и SIP этот ваш ...ps: по некоторым данным, DOCSIS тоже сдох.
> анона-фанатика SIP выше по треду тоже касается.Предлагаешь анону фанатику SIP читать его собственный коммент?
А ты смешной =)
>>если FTP-сервер интерпретирует запрос как файлОчевидно? Мне не очевидно как мой браузер вдруг вместо HTTP начнёт говорить на языке FTP
Передавай внутри POST-данных любые команды FTP/SMTP/POP3/IMAP, предшествующие HTTP-заголовки просто игнорируются как ошибочные команды.
>Передавай внутри POST-данных любые командынаписано же "Для успешной атаки злоумышленнику требуется затем каким-то образом извлечь сохранённое содержимое.", а каким - не сказано. Ибо так просто взять и отправить пост от имени bank.com не получится.
Далее они предлагают, чтобы заманить жертву на подконтрольный левый сайт и там уже пытаться что-то сделать, но тут может не сработать из-за CORS."Например, при открытии пользователем страницы, подконтрольной атакующим, с этой страницы может быть инициирован запрос ресурса с сайта, на котором у пользователя имеется активная учётная запись (например, bank.com)."
Инициация этого запроса под вопросом.
Каким-то образом извлечь данные это понятно как. Запрос из браузера идёт на FTP сервер и там сохраняется в виде файла. Дальше файл уже можно скачать если это позволено настройками FTP сервера.
У меня вопрос как заставить браузер послать нужный запрос. Это выходит надо на страницу банка сперва что-то заинжектить.
> Каким-то образом извлечь данные это понятно как. Запрос из браузера идёт на
> FTP сервер и там сохраняется в виде файла. Дальше файл уже
> можно скачать если это позволено настройками FTP сервера.с каких пор фпт будет понимать хттп-ешный запрос и еще умудриться это сохранить в виде файла?
я могу только в логах фтп увидеть некорректные команды в виде хттп запроса в которых вероятно и кукисы засветятся> У меня вопрос как заставить браузер послать нужный запрос. Это выходит надо
> на страницу банка сперва что-то заинжектить.инжектить не нужно, можно же заманить человека на evil.vom а там уже можно тупо допустим прописать
<img src="https://bank.com"> и браузер инициирует запрос на bank.com:443. Но нам же нужен пейлоад, а для этого нужно всякие post запросы формировать и чтобы браузер это еще и инициировал в контексте bank.com:443. CORS куда смотреть будет?
> CORS куда смотреть будет?Никуда. Есть запросы, на которые он не реагирует.
CORS вообще одна сплошная профанация.
В статье же расписано как заставить послать - заставить зайти на свою страницу и с неё инициировать запрос к цели.
И как-то случайно моя страница будет подписана тем же сертификатом, что и FTP сервер.
перечитай статью.
Не совсем так.
После X ошибочных команд обычно что клиент, что сервер - дисконнектятся.
Не у всех есть такая защита, но мы говорим о серверах (раз POST) - там она в большинстве случаев есть.
После того, как поддержку FTP убрали, для современного браузера все является HTTP.
Точнее - из категории идей, про которые все давно знают (без шифрования это таки было ещё проще) и давно уже перестрахованы где надо.
> ...при наличии контроля над сетевым шлюзом...
> ...атакующий может разместить данные в сервисе...Простите, у вас там совсем <сосуд со множеством дырочек>?! С таким сосудом любая альпака - как мелкая шалость.
Ну вот взять вайфай, например. Даже запароленный. Владелец кафешки или отеля может атаковать.
> FTP-сервер ... журналирует входящие запросы. Для успешной атаки злоумышленнику требуется затем каким-то образом извлечь сохранённое содержимое.... каким-то образом попасть на FTP-сервер. Да каждый владелец кафешки имеет доступ на сервер твоего банка!
Доступ на FTP бывает и анонимным. А роутер кафешки может быть уже взломан каким-то другим злоумышленником.
Анонимный FTP под сертификатом твоего банка?
Это про сбербанк что ли?
Это, вообще говоря, и не обязательно банк. Это может быть ваш хостер, например.
> Это, вообще говоря, и не обязательно банк. Это может быть ваш хостер, например.Не может. У этого "FTP" должен быть тот же сертификат, что и у банка. Откуда у хостера возьмётся сертификат банка?
Или банк на шаред-хостинге сидит?
> Простите, у вас там совсем <сосуд со множеством дырочек>?!так в этом же и суть MiTM атак?
С такими дырами хром может убирать из чёрного списка тот набор номеров портов, которые они захардкодили для защиты от NAT slipstreaming. Потому что по факту данная уязвимость как раз и обходит эту защиту, перенаправляя запрос с 443 на уязвимый порт.
митм форвардинг одного порта на другой, тут браузер будет думать, что подключается именно к 443.
Интерес эта атака имеет больше теоретический, так как для проведения требуется MITM. Но авторы обещают на USENIX Security Symposium раскрыть способ, работающий без MITM, а это уже совершенно другой уровень опасности.
> использующим общие TLS-сертификаты
> при наличии контроля над сетевым шлюзом или точкой беспроводного доступаА зачем мудрить с точкой доступа, если у атакующего уже есть "общие TLS-сертификаты" с имитируемым сервером?
Нет. Общие тут имеется в виду что есть например сайт и есть SFTP сервер, использующие общие сертификаты. Например yandex.ru и ftp.yandex.ru могли бы использовать общий условно *.yandex.ru сертификат. Атакующий при помощи точки доступа перенаправляет запрос вашего браузера с HTTPS на SFTP сервер.
>Атакующий при помощи точки доступа перенаправляет запрос вашего браузера с HTTPS на SFTP сервер.а дальше что?
SFTP футболит с ошибкой, попутно делая эхо этой ошибки, которая вовсе не ошибка, а нужные данные, переданные через POST. А твой наивный браузер всё это ловит и думает, что это ответ с bank.com и начинает выполнять скрипты в контексте bank.com.
> SFTP футболит с ошибкой, попутно делая эхо этой ошибки, которая вовсе не
> ошибка, а нужные данные, переданные через POST. А твой наивный браузер
> всё это ловит и думает, что это ответ с bank.com и
> начинает выполнять скрипты в контексте bank.com.так так, а как открывается контекст с bank.com?
Твой браузер и открывает, только запрос немного не туда уходит.
И сбрасывается, потому что protocol violation.
> Твой браузер и открывает, только запрос немного не туда уходит.хмммммммммм
Условия:
1) evil.com страничка замануха атакующего.
2) атакующий может делать митм и перенаправлять соединения bank.com:443 -> mx.bank.com:465 (postfix tls wrapper mode) и собственно в обоих случаях используется вайлдкард tls сертификат *.bank.comАтака:
1) Жертва переходит на страничку evil.com
2) В контексте странички evil.com пытаемся инициировать отправку POST запроса с пейлоадом на bank.com:443
3) В момент инициации необходимо перенаправить прозрачно соединение с bank.com:443 на mx.bank.com:465
4) В итоге mx.bank.com:465 вернет наш пейлоад, и исполнит его в контексте bank.com, а пейлоад может тупо украсть сессионные куки самого bank.com и отправить на evil.com.Вопрос такой, второй шаг возможен разве? CORS позволит это проделать?
Да и да. Некоторые запросы не заставляют срабатывать CORS.
> Да и да. Некоторые запросы не заставляют срабатывать CORS.ok, ясно, а как же быть с protocol violation, когда браузер ожидает
HTTP/1.1 200 OK
но в замен получает нечто такое
220 1237cfa6400d ESMTP Postfix
HELO example.com
250 1237cfa6400d
MAIL FROM: example <script>alert(1);</script>
555 5.5.4 Unsupported option: <script>alert(1);</script>
> ok, ясно, а как же быть с protocol violation, когда браузер ожидаетможете не отвечать, Internet Explorer - ясно все, удивляться нечему.
Is my browser/client vulnerable?
Internet Explorer and Edge Legacy (i.e., those not based on Chrome) are "more" vulnerable than other browsers, because they block fewer ports and perform content-sniffing. Content-sniffing is dangerous, because it enables JavaScript code execution in server responses that are noisy due to error messages by the application server that implements a protocol different from HTTP. This means that the pure web attacker variant of ALPACA is more dangerous for users of such browsers than for other users.However, no browser protects the user against all possible ALPACA attacks. In particular, all browsers can be compromised by a Man-in-the-Middle attacker who has write-access to an error-tolerant FTP server presenting a certificate compatible with a target web server under attack. Although the FTP server can in theory protect against this particular attack by detecting HTTP POST requests and/or terminating the connection after a small number of errors, this attack variant shows that this is not a bug in the browser, the web server, or the application server, but an emergent property of the TLS landscape.
Тут правильнее было написать"no browser protects the user against all possible attacks"
И ведь не поспоришь.
> Нет. Общие тут имеется в виду что есть например сайт и есть
> SFTP сервер, использующие общие сертификаты. Например yandex.ru и ftp.yandex.ru могли
> бы использовать общий условно *.yandex.ru сертификат. Атакующий при помощи точки доступа
> перенаправляет запрос вашего браузера с HTTPS на SFTP сервер.В любом случае, предполагается, что у атакующего есть закрытый ключ, соответствующий этому сертификату. С ним можно сделать что угодно просто подняв свой веб-сервер.
Нет, ключ от сертификата тут не нужен. Атакующий не вмешивается в сам трафик, не читает его и не видоизменяет.
Ванька путает ftp и sftp? Ванька не знает, что это разные протоколы?
Мораль: держите FTP, SMTP, IMAP и прочие сервисы на отдельных поддоменах со своими собственными сертификатами благо сейчас стало проще автоматизировать их обновление.
не поможет
> Мораль: держите FTP, SMTP, IMAP и прочие сервисы на отдельных поддоменах со своими собственными сертификатами благо сейчас стало проще автоматизировать их обновление.Полагаю, отказ от "сразу шифрованных" соединений в пользу STARTTLS тоже вполне прокатит.
угу
Мораль не пользовать браузер
Как же вы тогда оправили это сообщение сюда?
Мораль в том что FTP, SMTP, IMAP оказались совершенно не причём. А проблема вылезла вообще в HTTPS и браузерах.У нормальных людей через ftp, smtp, imap javascript не выполняется.
И никого не смутило:
<при наличии контроля над сетевым шлюзом или точкой беспроводного доступа>т.е. ломаем шлюз (не суть как) и только потом манипулируем с перенаправлением.
на "лошарике" можно подплыть и к кабелю подключиться :)
ха)
Реалии таковы, что точки беспроводного доступа и домашние маршрутизаторы дырявые как pешето, ломай не хочу. Или можно урожай собирать на выходных узлах Tor и создавая открытые wifi-сети.
какие у тебя там реалии
на выходных нодах tor?
Сказочник былиный, ты наш )))
+ ещё и к сервису доступ, чтобы логи читать.
а тебя не смущают миллионы admin:admin роутеров, торчащие голой жопой в интернет? и всякие захардкоденные аккаунты "oelinux123" на случай, если дофига умный лаовай сменит дефолтный пароль?
И что из этого можно поиметь?Как я понимаю это же скорее всего домашний роутер тарчит, а за ним пару хостов
А за домашним рутером сидит какой нить инженер из конторы ABB. Оппа и тейковер какой-то электростанции.
А если серьёзно?
> А если серьёзно?а если серьёзно, то гуглите "казино взломали через аквариум", или термометр, не помню точно.
за admin:admin девайсами порой скрывается много интересного, как минимум это доступ в локальную сеть таргета.
А если не торчит, то что дает
этот профиль "oelinux123" ?
Там прямо в заголовке написано: MITM.
Не смутило:
1. Об MITM написано аж в заголовке статьи.
2. Куча дырявых роутеров вокруг или роутеров с admin/admin (что равносильно дырявости).
3. Атакующий может быть тем самым настоящим провайдером "точки беспроводной связи": кафешка / гостиница / etc. со своей точкой доступа. И ничего ломать не надо.
3.2. да ты сам можешь в кафешке или рядом сесть, включить раздачу вайфая с именем сети Free WiFi (или даже название кафешки вписать) и ловить всех подключившихся.Короче, тут куча вполне себе реальных прикладных сценариев.
>Атакующий может быть тем самым настоящим провайдером "точки беспроводной связи": кафешка / гостиница / etc. со своей точкой доступа. И ничего ломать не надо.Ну или просто обычный провайдер, любой проводной или безпроводной.
Да это просто тупость. Все об этой фигне знали. Много лет
Суть в том что вы доверяете сертификату, который рассполагается у разных админов на разных службах.
Почему "у разных админов"? Проблема не в "разных админах", а в том, что админ рассматривает HTTP и FTP -- как две независимых службы, которые друг на друга не влияют и не вредят. Что позволяет открыть анонимный доступ на FTP, например.
FTP? Ну очень вовремя,особенно на фоне полного удаления поддержки этого протокола из браузеров.
Кроме того, FTPS вообще всегда был изрядной редкостью.
Твой любимымй гавняный HTTP там первый в списке
Для этой атаки не нужна поддержка FTP в браузере. После удаления ФТП браузер всё так же остаётся уязвим.
> Для этой атаки не нужна поддержка FTP в браузере. После удаления ФТП
> браузер всё так же остаётся уязвим.Хахашечки, но уже закрыли - https://bugzilla.mozilla.org/show_bug.cgi?id=1715684
Грязный хак, конечно, но "правильный" фикс https://bugzilla.mozilla.org/show_bug.cgi?id=1683710 пока в работе.
Нереал. Тчк.
Протоколы настолько между собой несовместимы, что подставить ложный ответ без модфикации софта на сервере не получится. А если есть такой доступ - собственно уже все ключи сертификатов есть, и не надо извращаться.
Если кто невдогнал, то:
1. "Upload": для успешной атаки злоумышленнику требуется затем каким-то образом извлечь сохранённое содержимое. Ключевое слово - "каким-то". Давай, до свидания.
2. "Download": атакующий в результате каких-то отдельных манипуляций может разместить данные в сервисе - ага, да ещё так, чтобы они вместе с обёрткой исходный протокол сымитировали. "Каких-то" - ключевое слово. Давай, до свидания.
3. Метод основан на возвращении клиенту части запроса, в котором содержится отправленный атакующим JavaScript-код. Вот только проблемка, снова надо в протокольчик обернуть. Туда же.
Я нашел уязвимость в замке входной двери! Если злоумышленник каким-то образом зайдет внутрь квартиры и вынесет оттуда запасной ключ, то замок можно будет легко открыть извне!
> Вот только проблемка, снова надо в протокольчик обернуть. Туда же.ну да, ток не понятно как у них вот это работает
220 1237cfa6400d ESMTP Postfix
HELO example.com
250 1237cfa6400d
MAIL FROM: example <script>alert(1);</script>
555 5.5.4 Unsupported option: <script>alert(1);</script>
Только на говносерверах, которые отдают невалидированные данные.
Dovecot и Exchange мимо, остальные в топку.
я вот тоже нехрена не понялу меня есть 3 сервиса на разных портах, например SMTP, POP3, HTTP
все на одном домене, и на одном и том же сертификате
каким образом можно скормить браузеру ответ от моего SMTP сервера?
ну он же не сожрет это, потому что протокол невалидный, несовместимые командыне? я что-то не понял?
Ну и блин, браузер, который это отобразит - надо закапывать первым.
Потому что перед <script>...</script> должны быть HTTP/1.1 200 OK, корректные хедеры, и двойной CRLF.
> Ну и блин, браузер, который это отобразит - надо закапывать первым.Internet Explorer - может все :) в оригинале статьи все расписано и все вопросы отпадают.
Короче, то, что они смогли <script> выдать - ещё не значит, что он где-то обработается.
О чём и речь. Свистопляска вокруг потенциальной шкуры сферического медведя Шрёдингера в вакууме.
shared-хостинги и дыры в них вот это вот отлично включают, т.е. это утилитарная атака, дополняющая уже существующие дыры и их расширяющая
Тот случай, когда никнейм соответствует персонажу.
> 1. "Upload": для успешной атаки злоумышленнику требуется затем каким-то образом извлечь сохранённое содержимое. Ключевое слово - "каким-то". Давай, до свидания.если у злоумышленника есть права на аплоад, то вроде бы всё выглядит реальным.
1. иницируем под СВОИМ логином/паролем (или анонимно) в пассивном режиме аплоад через tls, сервер говорит на какой порт к нему подключаться;
2. рвём соединение клиента по https, он 99.99% попробует переподключиться, новое соединение пробрасываем на указанный в первом пункте порт.браузер клиента проверяет сертификат — валидный, начинает слать запрос, сервер записывает его в файл, после чего клиент отваливается по таймауту.
3. идём на ftps-сервер и читаем свежезалитый файл. по мнению сервера его залили мы, поэтому нет причин не дать нам его прочитать.
в этом файле должны быть куки, профит
P. S. сертификат необязательно должен быть один, главное, чтобы тот сертификат, что используется на ftps-сервере, подходил для https-адреса.
аналогично, похоже, можно подсунуть браузеру нужный ответ (с js, например).
С ответом уже сильно сложнее, вплоть до нереалистичности.В теории да, можно залить подготовленный файл с хедерами и телом, но надо точно знать, на какой запрос отвечать, иначе MITM сразу же спалится.
Сущая мелочь:
1) Надо иметь права на FTP-сервере, именно том, что необходимо "подсмотреть", в том числе на аплоад
2) Надо иметь возможность MITM для соединения клиента, рвать соединение не обязательно, можно проксировать в нужную сторону
3) Надо ещё как-то определить конкретный запрос, который перенаправлять, тут открытость SNI конечно поможет, SNI давно надо закрыватьПо сути комбинация п.1 и п.2 - это сложно, разные зоны ответственности разных лиц.
А если (1) получено путём лома сервера - скорее всего смысла в (2-3) уже нет.
Но да, ваше описание атаки таки куда более реалистично, нежели "подмена ответа".Это хотя бы действительно сработает, хоть и имеет высокую сложность и малый шанс реализации.
Простите в чём суть атаки - в контроле над шлюзом? А как на счёт в контроле над провайдером.. или выше..
Магистальные провайдеры давно беспардонно вмешиваются в трафик. Про местячковых я бы особо не переживал -- ты им деньги несёшь.
Суть атаки - в попытке с самого клиента послать то, что хочется получить в ответ той софтиной, откуда послано.
В наших условиях это сервисная функция ПО стоящего за HTTP, судя по возможностям закладываемых при программировании как клиентов, так и серверов. Будут "чудесней" программировать, будет "чудастей" результат.
Никогда не пользовались WiFi в кафешке или аэропорту?
Нет ни чего нового в данной атаке, если им нужно захватить контроль над сегментом. С таким же успехом "мамкин хакер" расшаривает свой wifi дома.
Новое то, что можно обойти буковки "S" в HTTPS обладая доступом лишь к роутеру.
Нет :D
Кроме того, к внедрению в чужой трафик это отношения не имеет.
Там суть в получении назад кусков отправленного запроса, который в теории позволил бы CORS обойти.
Но толку нет, потому что чтобы запрос отправить - надо УЖЕ внедриться.
А кто-то ещё пользуется браузерами для работы с почтой и разрешёнными скриптами?
iPony и Fracta1L
Хаха. Хвалёный HTTPS
Какой ещё SFTP - это часть SSH, речь об FTPS.
Ну кто-же читает?
> перенаправить на почтовый сервер, в котором используется общий с bank.com TLS-сертификат.Ага, только для этого нужно ещё захватить контроль над этим почтовым сервером. Только причём тут высосанная из пальца "уязвимость" в TLS, когда для реализации требуется захват контроля надо сервером?
"We could confirm that this is indeed the case for Internet Explorer and Edge Legacy, while all other tested browsers do not perform content-sniffing and thus do not execute JavaScript in noisy responses."Атаковать MSIE есть способы и попроще :)
Про эту уязвимость знали уже давно, поэтому и убралли ftp mixed content еще год назад
https://www.cisco.com/c/dam/global/ru_ru/training-events/202...
Только все упомянутые в той презентации методы "взлома" TLS сводятся к фразе "Устанавливаем корневой сертификат на клиентское устройство". Там описано как получить доступ к TLS-трафику имея полный контроль над инфраструктурой и всеми рабочими станциями. Это для организации сканирования трафика на предприятиях.
https://media.defense.gov/2019/Dec/16/2002225460/-1/-1/0/INFO SHEET%20 MANAGING RISK FROM TRANSPORT LAYER SECURITY INSPECTION.PDF
Смекалочка. Люблю хакеров.
Ещё одну вишенку на торте забыли.
Если обсуждать применение из браузера, то чтобы отправить что-то из выданного сайтом кода на соседний порт того же сервера - надо сначала каким-то образом вклиниться в выданный сайтом код, собственно.
Любители тянуть кучу чужого говна с CDN'очек могут пострадать, конечно, но так им и надо.
Ну и да, если мы уже вклинились в выданный сайтом код - на хрена нам эта "атака" для вклинивания? :D
Кто на куче рекламмы сидит им вообще пофиг ломают их или нет, главное бабло да и ваши данные продадут
bank.com под замком, заходить - ишаком, станешь битым мужиком, а не - просто му-ком
А не удалили бы www - такой бы фигни не было.
Куки не храним, JS блокируем.
Куета.
>JS блокируем.К сожалению, в окне браузера может оказаться пусто.
<script>alert(1);</script> ничего в этом мире не меняется и вот опять :)
>В ходе MITM-атаки этот запрос, адресованный web-сайту bank.com, можно перенаправить на почтовый сервер, в котором используется общий с bank.com TLS-сертификатМинуточку, т.е. вам нужен рутовый доступ к самому серверу, чтобы на нём перенастроить скажем SMTP и выдавать вредоносный код вместо ошибки... Вопрос, зачем вообще вся эта чушь, когда подразумевается, что у атакующего уже есть полный доступ к серверу на котором есть нужные сертификаты? зачем доступ к шлюзу, если можно прямо на сервере порт форварднуть... да блин, доступ уже рутовый, зачем весь этот бред, в чём вообще суть атаки?
P.S. ощущение, что кто-то шикарно пошутил...
>доступ уже рутовый, зачем весь этот бред, в чём вообще суть атаки?Ну, типа для того, что бы манагерам пришла мысль, у админов отобрать еще больше прав! А то будут перехватывать чужие куки на почтовом сервере!
Нет, рутовый доступ не нужен. Достаточно иметь возможность влиять на трафик пользователя, например с помощью DNS направить bank.com на свой $evilserver, который перенаправляет $evilserver:443 на mx.bank.com:465. А затем дать пользователю ссылку на https://bank.com/<script.../>, а после установки соединения направлять последующие запросы из этого <script/> уже на настоящий bank.com:443.
ну апупеть - всего-то нужно иметь корневой сертификат... Опять же зачем все эти пляски с подстановкой других сервисов, если мы уже можем тупо перехватывать трафик и проксировать запросы?
Не можем, потому что у нас нет корневого сертификата. Это расширенный вариант атаки, где на стороне сервера есть скрипт echo.cgi?q=12345, возвращающий строку 12345. Только теперь это делает не веб-сервер, а ftps- или почтовый сервер, находящийся на другой (но тоже принадлежащий тому же владельцу) машине. А злоумышленник подставляет вместо безопасного https-сервера другой сервер, который разговаривает по другому (но тоже завёрнутому в tls) протоколу, ответы которого браузер пользователя ошибочно интерпретирует, как http-ответы.
Вы кажется забыли, что почтовый сервер, чтобы тупо открыть соединение должны поручкаться с клиентом по TLS, а это значит что сертификат на сервере должен соответствовать адресу атакуемого сервера. Ну что за наркомания...
В этом и смысл атаки - они хотят передать в SMTP HTTP и получить его назад.
Вот только невозможно это.Более реальную атаку мне тут выше обрисовали - да, в теории с помощью этой атаки можно залить куки на FTP, это действительно сработает. В теории.
На практике там понадобится иметь аккаунт R/W на этом самом FTP, что для того же bank.com крайне маловероятно, и _одновременно_ MITM на клиенте, что вдвойне маловероятно.
Прикольно. Но ни один банк не делает голых html интернет-банкингов и не рекомендует пользователям отключить яваскрипт. Ибо программисты работы лишатся.
Ведь реально скрипты там нах не нужны...
> Суть атаки в том, что при наличии контроля над сетевым шлюзом или точкой беспроводного доступа ...Опять рут нужен?
да, но теперь знаем зачем рут (и всякие *.* серты)
Так, стоп! Какой FTP?
Его еще несколько лет назад обещали "выпилить" из браузеров!
Если его поддержки нет в браузере - как он может что то там куда то отправлять, по протоколу "ftp://" ?😨
> Так, стоп! Какой FTP?
> Его еще несколько лет назад обещали "выпилить" из браузеров!
> Если его поддержки нет в браузере - как он может что то
> там куда то отправлять, по протоколу "ftp://" ?
> 😨
>на другой сетевой порт и организовать установку соединения с FTP или почтовым сервером, поддерживающими TLS-шифрование и использующими общий с HTTP-сервером TLS-сертификатНикак не вкурю, у атакующего должен быть тру сертификат http сервера или он может свой подпихнуть? Если первое, то в чем проблема. Имея серт и так с трафиком можно обращаться как с не зашифрованным.
у атакующего никакого серт-а нет.
Спасибо Анон, перечитал и с твоим комментом вкурил. Пусть Джа тебе только внятные маны заворачивает.
А на сервере, который будет принимать соединение и выдавать вредоносный код, от куда тогда сертификат должен взяться?
Хватит людей путать - вся эта атака полная чушь, подразумевающая, что админ должен профукать сертификат.
>т куда тогда сертификат должен взяться?И я не пойму, держатель серта в любом случае контралирует траффик
Нет, для успешного проведения атаки достаточно ленивого админа, который вместо выписывания отдельных сертов для www.bank.com и mx.bank.com либо выпишет один на все имена, либо вообще сделает *.bank.com.
И? Злоумышленник в этом случае должен иметь доступ либо к инфраструктуре днс имен *.bank.com либо администрировать один из сайтов *.bank.com.То есть паршивой овцой окажется кто-то из команды bank.com. Ну как один из админов яндекс-почты...
Не обязательно, можно атаковать сетевую инфраструктуру. Способов полно - злоумышленник может поднять свою wifi AP, свой DHCP, сделать ARP spoofing на местный рекурсивный DNS, стать IPv6-роутером в IPv4-only сети, автосконфигурировать всем http-прокси с помощью wpad, владеть или атаковать какой-нибудь из маршрутизаторов между пользователем и bank.com.
И как это все даст ему доступ к внутренним логам сервиса зактытого TLS?
Напрямую никак. Это даст ему возможность запустить js-код в браузере пользователя в контексте пользовательской авторизованной сессии.
>Это даст ему возможность запустить js-кодТоварищ, мне кажется что вы окончательно запутались. Перечитайте ещё раз - мы опять упираемся в необходимость иметь на руках сертификат для совершения этой атаки.
Нет, нужен не сертификат, а наличие другого сервиса с сертификатом, соответствующим атакуемому домену.Предположим, что я - админ bank.com, и у меня есть почтовый сервер, mx.bank.com. Я законным путём получил сертификат сразу на два домена: "bank.com" и "mx.bank.com". Или на *.bank.com. Или на почтовом сервере у меня используется тот же сертификат, что и на веб-сервере - любой из этих вариантов подойдёт для атакующего. Важно лишь то, что сертификат, которым пользуется mx.bank.com, годится и для bank.com.
Есть жертва. Она приходит в кафе поесть, но оказывается, что денег на карте не хватает, чтобы расплатиться, и приходится заходить на bank.com, чтобы перекинуть немного с накопительного счёта на карточный. Хорошо, что рядом есть wifi ap, ведь в этом месте мобильная сеть плохо работает.
И есть злоумышленник. Который поднял эту wifi ap. Он уже давно пытается перехватить сессию пользователей на bank.com. Сначала он просто заворачивал трафик на свой nginx, но админы настроили https, и пользователь пугается и закрывает браузер, видя большое красное предупреждение. Поэтому злоумышленник стал действовать хитрее. Он стал подсовывать жертве ссылку на свой сайт, который из js делает POST-запрос на https://bank.com/transfer.cgi?to=eviljoe123&amount=100500. Разработчики банка узнали про этот трюк, и стали в веб-формы вставлять случайные CSRF-токены, которые злоумышленник угадать не может, а в обработчике transfer.cgi проверять их наличие.
Теперь появилась вот эта новая атака. Злоумышленник подсовывает ссылку на evil.com/switchdns.cgi. Когда жертва переходит по ссылке, switchdns.cgi перенастраивает сеть так, чтобы трафик до bank.com попадал на mx.bank.com, а потом отдаёт редирект на bank.com/<script.../>. Браузер жертвы подключается туда (TLS), проверяет сертификат (с ним всё ок) и отправляет ничего не подозревающему почтовому серверу HTTP-запрос. Почтовый сервер отвечает "я не знаю, что такое <script.../>". Браузер интерпретирует это, как HTTP-ответ с тегом <script/> внутри, и начинает выполнять этот скрипт в контексте bank.com. А дальше злоумышленник возвращает всё обратно - пускает трафик по обычному пути до bank.com, а в своём скрипте делает запрос веб-формы, парсит оттуда CSRF-токен и делает POST на перевод денег - всё это из браузера пользователя, исполняющего его скрипт.
Нигде во время атаки злоумышленнику не нужно ни владеть никакими сертификатами, ни находиться в сговоре с админами bank.com.
Через mx.bank.com ты никакой редирект не отдашь - нормальный браузер его не схавает, хедеры нужны корректные.Через ftp.bank.com - можно - edo выше приводит рабочую схему атаки, но для этого надо на нём r/w доступ.
У меня например есть под рукой живой шаред хостинг, и меня эта проблема не парит совсем, потому что мы сразу разделили FTP и клиентские серты, FTPS работает с нашим собственным сертом - это нормальная практика. Клиентскому серту - только клиентское, инфраструктура отдельно.
(и возможность FTP hijacking меня тоже не парит, потому что соединения данных разрешены только от IP соединения управления)
Вы кстати как-то вот легкомысленно говорите про ленивость админа который выписывает отдельные сертификаты...Это возможно если вы бесплатные сертификаты с летскрипта выписываете. А вот если вы покупаете нормальные сертификаты, заверенные, с повышенным доверием - то разница в ценнике между *.bank.com и десятком "чтототам".bank.com будет заметная. И тем более если админ имеет возможность САМ выписывать эти сертификаты, там ценник вообще отрывается на порядок... Для конкретно банка- эти суммы может и не в тягость...но "*.bank.com" ведь для примера приведен. Это ведь может быть и не банк а просто предприятие. Которому все эти траты могут быть и не очень приятны.
Согласен, дело может быть не только в лени, но и в желании сэкономить.> может быть и не банк а просто предприятие. Которому все эти траты могут быть и не очень приятны.
Небольшое предприятие скорее всего воспользуется бесплатным letsencrypt, чтобы избежать трат.
Разве проблема тут не в том, что разным сервисам раздают одинаковые серты, да еще и от банка?
Значит после взлома маршрутизатора, предполагается взломать еще и ftp
> Разве проблема тут не в том, что разным сервисам раздают одинаковые серты, да еще и от банка?Именно в этом.
> Значит после взлома маршрутизатора, предполагается взломать еще и ftp
Нет, не придётся. Достаточно направить на другой сервер с тем же сертификатом http-запрос, содержащий контролируемую злоумышленником строку, которую тот вернёт в виде "ошибка: неизвестная команда: GET /строка...". А в случае ftp можно ещё воспользоваться тем, что данные передаются по отдельному соединению (тоже с tls), и тогда не придётся расчитывать на то, что браузер правильно угадает Content-Type.
Недостаточно.
Ответ надо ещё в HTTP обернуть. А то и в HTTP/2.
Веб должен оставаться просто вебом, и не пытаться стать платформой.
Как будто проблема только в TLS. Там еще как бы и JavaScript нужен.