Исследователи из компании SEC Consult опубликовали новую технику спуфинга, вызванную расхождениями в следовании спецификации в различных реализациях протокола SMTP. Предложенная техника атаки позволяет расщепить одно сообщение на несколько разных сообщений при его передаче исходным SMTP-сервером на другой SMTP-сервер, по иному трактующий последовательность для разделения писем, передаваемых через одно соединение. Метод может использоваться для отправки фиктивных писем от имени других отправителей в почтовых сервисах, верифицирующих исходного отправителя...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60329
>для обеспечения совместимостикакой-то булшит, гнать из профессии
Согласен. Законодательно применить \n и закрыли тему.
А заголовок Content-Length сделать обязательным.
Тогда и "." ждать не нужно.
Не Content-Length, не разбирает SMTP сам по себе никаких заголовков.
Добавить DATALEN <x> в протокол и забыть.
(ну и естественно без DATALEN больше одного сообщения за заход не пускать)
Поддерживаю, раз на парсют письмы.
Кто-нить займити джуна какого-нить пщай оформит RFC-у и иму профит в карму и старикам приятно =)
+1
Даже шокирует то, что "диды", пися всё на Сях, так ТУПО спроектировали протокол. Очевидно же, что Сишная программа убога по возможностям прокидывания больших объёмов - в них каждый байт на счету, malloc/free и всё такое. Поэтому ЗАРАНЕЕ знать размер получаемых данных - это ОГРОМНЫЙ плюс при обработке! Но нет, эти кретины придумали текстовую точку(!!!!!!!!!) для окончания текста, в котором самом полно точек!!! *фэйспалм.ави 500ГБ*
Да, надо было на жабоскриптах писать, желательно всё с нпмочки стянув.
Но вот проблема - ни жабоскрипта, ни нпм у них не было. Да и мозгов было побольше.
На самом деле этот протокол никто долго не проектировал - его слепили из того, что было, чтобы хоть как-то работало. Заря интернетиков, фтн, гнилой ууцп, все дела. А потом оно просто уже стало везде, и поменять что-то стало сложно. Тут лучше поблагодарить тех, кто не стал следовать стандарту, а начал пихать нестандартные варианты терминаторов так, что под них пришлось адаптироваться.
Давно есть chunking и BDAT, но опционально.
Ух ты, пропустил это расширение.
Ну вот его и оставить, причём запретив пайплайнинг множества сообщений, до окончания данных и получения ответа новых команд слаться не должно, хотя это в RFC описать забыли.
А для DATA оставить возможность отправки только одного сообщения за сеанс.
Тогда передача между почтовыми серврами и gw-ями будет тормозить
Это было актуально при модемах.
На текущих скоростях и делеях сотню соединений вместо одного для передачи почты просто не заметишь.
(это я тебе как сидящий возле достаточно большого почтовика вещаю, сквозь который миллионы писем в сутки проходят... у меня между gw и серверами как раз выставлено максимум 1 сообщение, но немножко по-другим околотехническим причинам)
>гнать из профессиипокажи свой smtp-сервер, который сделан строго по стандарту (u-блюдочному кстати и размазанному по десятку рфц) и которым пользуется хотя бы миллион человек?
ой, кармадрючеры обиделись.... много тут писателей smtp серверов-то? на расте, кстати, их за 15 лет ноль нормальных родили ) samotop глююкалово и тормозилово.
А зачем кому-то писать такую скучную вещь как smtp сервер?
Ты первый.
Прекрасный стандарт. Можно и так трактовать и эдак, удобненько.
А главное все просто plain text, а не ваши новомодные json-чики.
Нельзя.
Просто в отдельные почтовые сервера зачем то доложили совместимостей никого не спросив.
Я бы просто это выкинул и не вспоминал, старые клиенты мертвы, это их проблемы./n./n - это похоже для тех кто из консоли руками отправляет.
> Просто в отдельные почтовые сервера зачем то доложили совместимостей никого не спросив.потому что "почта должна ходить". И "принимать все, отправлять - соблюдая стандарты".
А если бы этого не сделали - ты бы до сих пор пользовался прекрасной x.400
Вот там - все было по правилам. И доставка за считанные часы. Что? Часы! Оно так работало.
Предполагалось что хакеры ссущие в солонки - забота полиции, а не владельца солонки.
x.400
Почитал, интересно
Если бы к CRLF.CRLF не понагородили алиасов - ничего бы не случилось, лишь пара странных типов пишущих письма из терминала через телнет/неткат пострадала бы.
smtp как стандарт почты - не случилось бы. Именно потому что тогда ВСЕ типы были "странные". А одна почта где шаг вправо-шаг влево - ошибка ОШИБКА и твоя почта отправляется в помойку - уже была.sendmail с его мега-языком для исключительно переписывания адресов - тоже порожден тем же временем. Сейчас его конфиг кажется нелепой архаикой, а тогда это позволяло почте - доходить до адресатов. При том что и адресаты и отправители могли быть в совершенно вычурном виде. И вот то что оно все же доходило - и решило вопрос в пользу smtp и sendmail.
В стандарте чётко оговорено, какой разделитель. Это всё ещё отголоски войны carriage return и line feed в качестве конца строк, ну и костыли в конкретных реализациях почтовиков.
JSON-чики это тоже plain text. Нужно делать как сделали с HTTP/2, т.е. делать нормальный бинарный протокол на фреймах
Бинарные протоколы очень плохо заходят в индустрию.
Есть с десяток основных бинарных протоколов, но всё что бегает в TCP - в основном текстовое, потому что отлаживать проще.
Регулярно подвергаюсь кенселенгу на опенет за то что ругаю бинарные протоколы, поэтому скажу так: ну и зря! Был не прав! Очень хорошие бинарные протоколы! Побольше бы таких протоколов в индустрию!
Я не говорил что они плохие, я говорил что бинарные протоколы очень сложно заходят.
Взять хотя бы HTTP1 vs HTTP2+.
Для HTTP1 особо и прогать не надо чтобы файл скачать: кое как сгенерить запрос, немного распарсить ответ и всё.
Для HTTP2+ нужно нагородить кучу кода и ещё отладить его, полагаю потребуются дополнительные утилиты, которые возможно тоже нужно написать.
Для HTTP/1 очень даже нужно прогать на серверной части, и довольно долго и аккуратно. Тем более где это ты програешь HTTP/1 руками в наши дни? Поти во всех ЯП есть уже готовые либы, которые для разработчика отдают простой API. Утилиты для HTTP/1 тоже как-бы присутствуют, например curl и wget. Так будет и для HTTP/2 в базовом варианте. В конце концов на коленке создать и разобрать HTTP/2 запрос-ответ на питоновских struct в общем случе будет проще, чем полноценно разбирать HTTP/1 ответ.
》питоновских structЯсно, уносите этого в 10-ю палату.
> 》питоновских struct
> Ясно, уносите этого в 10-ю палату."В мусоропровод!" (с)
Я писал про клиента, но и серверу для простых вещей много ума не надо.Не знаю никаких питоновских структов.
Я много разных протоколов реализовывал.
Все текстовые протоколы всегда можно потыкать через простой терминал, я вот себе написал: https://netlab.dhis.org/wiki/software:win:net:tcp_term это уже где 5+ итерация.
Я писалпростые клиенты на перле для DynDNS, где надо просто подключится и заслать фиксированный запрос и получить какой то примитивный ответ. Это всё легко делается на сокет+базовые функции.Но каждый раз когда я писал бинарный протокол это занимало намного больше времени чтобы накорябать хидер со всеми структурами, всеми константами и потом ещё накорябать сборку/разборку этого всего.
Те я толкую именно про входной барьер от начала до первого рабочего прототипа, а не полноценную реализацию всех стандартов целиком.
Да, с полной реализацией стандартов у бинарных протоколов легче тк вариативность ниже.
Важное преимущество этих протоколов состоит также в том, что их много. Если раньше для того чтобы написать программу с кнопкой, которая скачивает файл по ссылке, нужно было поддерживать HTTP1/1.1, то сейчас нужно добавлять поддержку HTTP2 и HTTP3, а это почти в три раза лучше того что было и требует, например от мобильных/встроенных устройств, где это может быть критично, большего размера бинарника и оперативной памяти. Это в свою очередь будет стимулировать производителей создавать устройства, с более лучшими характеристиками, а пользователей - заменять всё старое на новое, тоже более лучшее. Я очень воодушевлённо рад наблюдаемому прогрессу в развитии протоколов, и надеюсь что в скором времени мы увидим хотя бы ещё один.
То то программы в индустрии все не бинарники, процессоры прямо текст исполняют)))
В индустрии прогают люди, людям проще прочитать текст и написать текст а не заниматся кодированием битов и слежением за порядком байт.
Это было справедливо в какие-то 80-ые, когда ещё можно было попробовать глазами посмотреть трафик. Сейчас ситуация поменялась из-за увеличения объёма данных и отлаживать так просто глазами уже сложно, сейчас нужны автоматизированные аналитические инструменты. К тому же для всего есть pretty-printer-ы, например, см. wireshark. Выбор между текстовым форматом и бинарным примерно стоит в наличии времени на разработку вспомогательного инструмента и объёмов данных. Небольшие метаданные чаще удобнее представлять в текстовых форматах. Но есть проблемы...И эти проблемы заключаются в кажущейся простоте текстовых форматов. А на самом деле они значительно сложнее бинарных, например, из-за эскейпинга (см. проблему из новости, что такое SQL injection и т.д.). Делать корректные парсеры для текста сложно и в особенности если речь про древний хлам из 80-ых, который к настоящему оброс кучей отклонений от стандартов.
Бинарные протоколы заходят в индустрию отлично. Почти всё своё внутри корпораций работает на бинарных протоколах, тот же protobuf. А текст остаётся в основном для совместимости с внешним миром. Теперь наконец начали пробовать закапывать HTTP/1.x, в сети в основном он и бегает если убрать торрент и ~RTP. Остались ещё местами последователи BDSM церкви свидетелей вездесущего XML, еретики в виде секты читабельного JSON-а и новое эзотерическое течение YAMLлогов. Но это всё постепенно уходит в категорию маргинальщины и рукозадства.
Тем не менее бинарные протоколы всё ещё плохо заходят.
Тот же nginx имеет реализацию proxy protocol 1 - который текстовый и не имеет версию 2 которая бинарная. (на самом деле обе реализованы там так себе).Эскейпинг нужен не везде.
Привидите примеры костылей :)
Можешь сколько угодно САМ СЕБЯ убеждать, что бинари - рулез, но практика (и моя в т.ч.) показывает, что текстовый протокол - наше всё. Конечно, ты как бравый русский программист готов "переписать всё за неделю", но вот нахрен ты не нужен со своими байтами. Потому что далеко не всегда и везде можно влезать и "парсить бинарь". А текст - он даже в отладчике прекрасно видится. Более того - всякие проблемы мисформаттинга в ТЕКСТЕ ловятся на раз. А в бинаре - ну да, попрыгай по байтам, угадай, кто из переменных напортачил и вместо byte записал int, от чего ВСЯ бинарная шняга съехала по смещениям.
Короче, ты просто студент ещё (по кр. мере по уровню скилов) и большой работы по протоколам не делал, потому тебе всё легко. Я сам писал кучу серверов - для IRC, SMTP/POP3, HTTP... И когда ты видишь текстовую вещь, да ещё которую можно легко парсить регэкспами, наступает нирвана. А ипасса с байтиками и угадывать значения - ну если нравится просирать время - ради бога!
Согласился бы, не будь таких же приколов с JSON из-за разницы в стандартах.
> Postfix, Sendmail, MS Exchange OnlineЭто примерно половина почтовых серверов? Из крупных похоже только exim оказался незатронут.
Exim топчик
> Exim топчикAxa...
https://www.cvedetails.com/vulnerability-list/vendor_id-1091...
Error 1009
Access deniedчто за говно?
УМВР, наверное ты с неправильного интернета смотришь)На попробуй другую ссылку
nvd.nist.gov/vuln/detail/CVE-2022-37452
Exim before 4.95 has a heap-based buffer overflow for the alias list in host_name_lookup in host.c when sender_host_name is set.
Нацональностью не вышел.
> Нацональностью не вышел.паспортом. Дискриминация по национальному признаку - позапрошлый век и уже немодно.
Вот по гражданству а еще лучше месту рождения в неправильной стране - самое то!
> Вот по гражданству а еще лучше месту рождения в неправильной стране - самое то!Ты еще скажи, что паспорта и разрешение на вьезд (а не на выезд) - это плохо.
exim топовое шерето
Астрологи объявляют неделю расщеплений. сначала Terrapin, теперь ещё и Smuggling, смурфики какие-то.
> Астрологи объявляют неделю расщеплений.И самое главное ведь как всегда - к праздничкам подарунчик... пока админы бухают
A Sec Consult козлики... могли бы сперва оповестить вендоров, как это принято, но очень сильно козлиную медаль хотелось наверное
Они то предупредили. Все претензии к автору перевода, который поленился об этом упомянуть.
> Они то предупредили.Предупредили?
> Timeline
> Dec 18 SEC Consult publishes an attack that involves the composition of two different email service behaviors.Прям перед праздниками, в то время когда любая нормальная секьюрити компания оповещает вендоров и ждет как миниум месяца 3 перед тем как опубликовывать.
Козлы - это очень мягко ИМО...
А, ну конечно нужно было подождать с критической проблемой - разрабам же обязательно побухать на кристмас и нг.
> А, ну конечно нужно было подождать с критической проблемой - разрабам же
> обязательно побухать на кристмас и нг.Не, нет, что-ты? Они должны пахать, (как ты?), с испорченным настроением на праздники.
> 2023-10-16: SMTP smuggling in Exchange Online is fixedНа самом деле они подождали, пока уважаемые люди (тм) пофиксили, проблемы остальных индейцев никого не волнуют
>> 2023-10-16: SMTP smuggling in Exchange Online is fixed
> На самом деле они подождали, пока уважаемые люди (тм) пофиксили, проблемы остальных
> индейцев никого не волнуютВот поэтому - и козлы
Wietse Venema, очередной раз - респект !https://www.postfix.org/smtp-smuggling.html
В двух словах, для тех кто продакшн:
> With all Postfix versions:
>smtpd_data_restrictions = reject_unauth_pipelining
>
> Postfix 3.8.1, 3.7.6, 3.6.10 and 3.5.20 include the same feature:
>smtpd_forbid_unauth_pipelining = yes
>smtpd_data_restrictions = reject_unauth_pipeliningЭто частичное решение, которое при должной настойчивости можно обойти. А менно, злоумышленнику достаточно подобрать размер первого сообщения так, чтобы начало второго сообщения пришлось на новый сетевой пакет.
This will block misuse of SMTP command pipelining, when one network packet contains multiple lines with smuggled SMTP commands and message content. It will not block message pipelining (multiple MAIL transactions per session), *nor will it block a malformed end of line*. Malformed line endings are addressed with the long-term solution.
Какой нахрен пакет в TCP?(Для нудных: да, TCP разбивается на пакеты при отправке, но для отправителя и получателя это прозрачно.)
>>smtpd_data_restrictions = reject_unauth_pipelining
> Это частичное решениеЛучше, - чем ничего
кортинге нигрузяца
Заглянул на почтовики, reject_unauth_pipelining добавлено с какого-то там бородатого года. Зевнул и пошёл спать дальше.
Заглянул на почтовики, увидел что хоть reject_unauth_pipelining присутствует с какого-то бородатого года, но "smtpd_forbid_unauth_pipelining = yes" отсутствует
Добавил smtpd_forbid_unauth_pipelining, перезапустил postfix.
Только после этого зевнул и пошёл спать дальше.
А смысл? Пока достаточно предотвращения pipelining в процессе обработки данных.
Посплю до затычки, а потом обновлюсь, наплевав на все празднества.
Мне кажется, что эти директивы все-таки немного разного назначения
Одна проверяет не посылает ли подключившийся SMTP команды там, где их не должно быть, а вторая разрывает соединения если клиент "violate RFC 2920 (or 5321) command pipelining constraints"
согласно "man 5 postconf"
Или я ошибаюсь?
В любом случае обе можно обойти, авторизовавшись и выровняв пайплайн по границе пакета.
Поэтому до затычки частично поможет любое из... но только частично.
Первая запрещает слать DATA в пайплайн, вместе с другими командами, не отдельным пакетом.
Это по сути то, что и останавливает указанный вариант.
Вторая запрещает пайплайнить вообще не по границе пакета.
Обе обходятся грамотным выравниванием контента.
Там да, надо, чтобы звёзды сошлись, но можно поэкспериментировать и подобрать для конкретной пары.
Всегда использовали \0 и не было никаких проблем, зачем придумали эту абракадабру с точкой?
Правда что ли? \0 не текст, что является проблемой для текстового протокола, да и когда в telnet набираешь могут быть "сложности".
> Всегда использовали \0 и не было никаких проблем, зачем придумали эту абракадабру с точкой?... в hello, world'ах? Там да, там и повезти могло. А в индустрии решения хуже null-terminating string - еще поискать.
Испытываю странные ощущения - настоящим почтовиком занимался в 10-е годы, сейчас все больше все лезут в сторонние почтовые сервисы (но я бы сгородил что-то свое, косое, но свое), стало быть, реальных админов почтовых серверов мало же сейчас? Или все же больше 500 на страну?Ну так пусть идут и занимаются всей этой пургой (:
Вопрос, собственно, один - кому массово эта история важна?
Да всем.
Потому что разосланный этим способом спам и тебе придёт, в том числе.
> Да всем.
> Потому что разосланный этим способом спам и тебе придёт, в том числе.С такой точки зрения - действительно так и есть (:
Уж сколько раз твердили миру:
"in-band signalling - смертельный грех".
Но только всё не впрок.
И в столовой хакер
Всегда отыщет с солонкой уголок.
Не уловил в чём проблема. Ну один сервак считает это одним письмом, второй считает за два. Что мешало сразу два письма послать на второй сервак? Результат тот же был бы.
Неа.
Основная проблема вот в чем "второе письмо может быть отправлено от имени пользователя, не аутентифицированного через "AUTH LOGIN", но выглядеть как корректное на стороне получателя"Т.е первое письмо делаем от васи пупкина и оно отправляется пользователем в мусорку/спам, а второе о гугла или сбера с просьбой срочно сменить пароль
Посмотри какие на картинках заголовки и адреса.
Так а сервак почему не проверяет от кого второе письмо? Он проверяет только первое письмо в в соединении?
Тогда ничто не мешает хакеру также подключиться и через \r\n отправить два письма.
Какому хакеру? Куда подключиться?
Допустим ты подключаешься на сервер, проходишь аутентификацию, тебе разрешено отправить 10 писем в течении одной секунды, что бы не спамил почём зря, ты отправляешь одно письмо но с этими "неправильными" символами разделения которых в письме у тебя тысяча штук, и после каждого разные команды на отправку с разными адресами, по стандарту твоё письмо корректное и сервер обработает его как единое, и отправит дальше, а сл. сервер "туповатый", подумает что пришло 1000 писем с предыдущего сервера, который тебя проверил и всё норм. Ну и отправит 1000 писем на разные адреса.
И так ещё 10 раз по 1000 в течении секунды, и потом каждую секунду так по 10000 писем от тебя.
Вуаля, халявная рассылка. Пойди найди откуда оно летит.
Это же smtp. поднимите у себя сервер и отправляйте хоть по миллиону писем в секунду. Зачем вам это делать через чей то сервер?
> поднимите у себя серверТы либо троллишь, либо никогда не поднимал такой "сервер".
> Отмечается, что отключение поддержки альтернативных разделителей может нарушить работу некоторых редких почтовых клиентов, не полностью соответствующих спецификации SMTP.Ну так проблема у несоответствующих клиентов, зачем поддерживать несоответствие, это больной парадокс.
то есть проблема в том что в этом случае подделывается поле не только From: , но и mail FROM:Однако, тут возникает вопрос: ну и что?
Что мешает вам на собственном smtp сервере сделать так? и слать что угодно кому угодно от чьего угодно имени?
> Что мешаетSPF
> Что мешает вам на собственном smtp сервере сделать так? и слать что
> угодно кому угодно от чьего угодно имени?п-дюли, как ни странно.
А в этом случае - все следы закончатся на ТВОЕМ сервере.
И очень интересно не эта ли технология использовалась для спама с гугля.