В августе этого года в ssh(1) (клиент OpenSSH) внесено изменение с поддержкой обфускации тайминга нажатий клавиш, то есть интервалов между временем нажатия клавиш на клавиатуре.
Спрашивается, почему разработчики озаботились такими нюансами информационной безопасности? Но причина есть. И на самом деле такие меры должны предпринять все программы, которые допускают ввод паролей в интернете (или вообще любого конфиденциального текста). В первую очередь, браузеры и мессенджеры.
Тайминг нажатий клавиш в консоли — известный вектор атаки ещё с 80-х. Грубо говоря, по паттерну появления звёздочек на экране можно примерно определить нажатые клавиши, что на порядок сокращает количество вариантов для брутфорса. Например, рядом стоящие клавиши обычно нажимаются медленнее, чем дальние, если человек работает двумя руками. Или быстрее, если пользователь обучен профессиональным методам набора (но таких меньшинство), см. диаграмму внизу.
Распределение времени между нажатиями клавиш v-o (слева) и v-b (справа), источник
Абсолютно для всех буквенных пар есть среднее время между нажатиями:
Гауссово распределение для 142 символьных пар английского языка (слева) и количество бит информации, которые мы можем извлечь, наблюдая каждый конкретный тайминг (справа)
Кроме того, в 90-е годы появились программы, которые с высокой точностью идентифицировали человека по таймингу нажатий, а сейчас это вообще тривиальная задача, тем более когда можно обучить ИИ-модель именно для этой задачи. Теперь любой школьник может взять нейросетку, скормить ей звуки нажатий целевых личностей, а потом легко распознать этого человека по таймингу буквенных пар, на какой бы клавиатуре он ни работал, и даже удалённо через интернет — просто наблюдая, как человек набирает текст на экране (или перехватывая пакеты его трафика).
То есть утечка информации через интервал между нажатиями несёт как минимум двойной риск:
- Деанонимизация пользователя.
- Распознавание пароля (помощь в брутфорсе).
Угроза конкретно для SSH была описана в далёком 2001 году в научной статье «Анализ тайминга нажатий клавиш и соответствующие атаки на SSH» авторства учёных из Калифорнийского университета в Беркли.
После этого в 2008 году разработчики развернули обсуждение той научной статьи. Дело в том, что в качестве примера она приводила протокол SSH1, который к моменту обсуждения уже вывели из использования. Некоторые из разработчиков предположили, что этот факт в значительной степени аннулирует слабое место. Но топикстартер парировал, что «нет никаких оснований полагать, что такие атаки будут невозможны против второй версии протокола там, где они работают против первой. Просто могут немного усложниться».
На самом деле очень много информации можно собрать, просто просматривая записи зашифрованных сессий, особенно если вы накопили достаточное их количество. В некоторых странах запись таких сессий поставлена на поток. В интерактивных сеансах связи есть достаточно чёткие закономерности, которые можно извлечь и использовать вместе с информацией о времени между нажатиями клавиш (то есть между соответствующими пакетами). Специфические скачки трафика позволяют понять, что пользователь набрал команду куда-то подключиться, а потом — пароль.
▍ Что конкретно внедрили в ssh(1)
Чтобы скрыть промежуток между нажатиями,
ssh
в случае малого количества трафика отправляет его по сети с фиксированными интервалами 20 мс, а также добавляет «фальшивые» нажатия.В документации появилась опция ObscureKeystrokeTiming:
Аргументом для опции может быть
yes
, no
или спецификатор интервала в виде interval:milliseconds
(например, interval:80
). Несложно догадаться, что это фиксированный интервал времени между пакетами, как и было описано выше.▍ Какой интервал выбрать?
Указано, что по умолчанию используется интервал между пакетами 20 мс. При этом чем меньше интервал, тем больше будет фальшивых пакетов и тем больше объём трафика. По идее, любое значение обладает одинаковой защитной функцией, кроме чрезмерно больших, когда наблюдатель сможет примерно угадать количество символов в пароле.
Скажем, чем отличается 20 мс от 50 мс, если вы всё равно не способны набирать пароль со скоростью больше десяти символов в секунду. А если у вас реально набор с такой скоростью, то при интервале 50 мс это даёт десять фальшивых и десять настоящих нажатий в секунду, что вполне эффективно скрывает длину пароля. И дополнительный паддинг (набивка) в конце даже не требуется.
Размер пакета с одним символом составляет 61 байт, так что при интервале 50 мс у нас генерируется 1,2 КБ трафика в секунду (4,19 МБ в час), а при 20 мс — 3 КБ в секунду (10,47 МБ в час). Возможно, для кого-то эта разница существенна. Если что, функцию можно отключить.
В общем, значение параметра можно устанавливать в зависимости от вашей скорости набора пароля. Учтите, что обычно скорость набора пароля гораздо выше, чем скорость набора обычного текста. Комбинация просто проникает в мышечную память и набивается на клавиатуре автоматически.
▍ Буфер и звёздочки
Некоторое время существовал богатый выбор приложений, принимающих пароли в небуферизованном режиме. То есть нажатия откликаются на экране эхом как звёздочки (*) по мере ввода пользователем, символ за символом. Эта простая функция выглядит красиво и даёт интерактивный фидбек… Но в таком случае происходит утечка данных не только о тайминге нажатий, но и о количестве клавиш, что соответствует длине пароля. Понятно, что это критически важная информация.
Поэтому большинство терминальных приложений сменили эту порочную практику и начали использовать буферизованный ввод/вывод для ввода пароля, что является важной функцией безопасности. В этом режиме компьютер ничего не отправляет по сети, пока пользователь не нажмёт
Enter
. То есть предполагаемый злоумышленник MiTM видит только один пакет, независимо от того, что происходило на стороне клиента, сколько он клавиш нажимал и с каким таймингом, а из-за набивки «пустыми» символами пакет до стандартного размера злоумышленник не сможет определить длину пароля.Ещё одна мера защиты: всегда выводить на экран одинаковое количество звёздочек, независимо от длины пароля, чтобы защитить экран от постороннего наблюдателя, который может узнать длину пароля. Это, конечно, смущает некоторых пользователей. Тогда практически теряется смысл этих звёздочек.
Буфер — очень важная функция безопасности, и он лучше обфускации, которую делает
ssh
. Но в ssh
буфер по неким причинам не добавляют. Видимо, чтобы сохранить консистентный интерфейс. Иначе на картинке с сервера, которую вы видите, в поле пароля не будет отображаться вообще ничего, пока со стороны клиента набор пароля не завершится — и он не нажмёт кнопку Enter
(а потом какой смысл отображать что-то в этом поле, если мы уже увидим ответ сервера на введённый пароль?). Наверное, отсутствие звёздочек на экране — не самый логичный UI, ведь все мы привыкли, что ssh
точно транслирует события на экране, то есть с одной стороны всё выглядит точно так же, как с другой.Поэтому пока не существует SSH-клиентов с поддержкой буфера.
Так что внедрение обфускации — это очень полезное и приятное событие, так что можно понять восторг пользователей в комментариях к этой новости в OpenBSD Journal. Там пишут, что это ещё один отличный пример «безопасности через обман» (security by trickery), по примеру «безопасность через неясность» (security by obscurity).
Кстати, даже при наличии буфера обфускация тоже важна для защиты содержимого, которое не может быть буферизовано, например, вывод из командной строки или редактора. То есть это в любом случае полезная функция, есть там буфер или нет.
▍ Вывод
Итак, известная с 80-х годов атака была конкретно описана против SSH в 2001 году, затем в 2008 году начали обсуждать возможность защиты от таких атак, а в 2023 году наконец-то вышел патч. Приятно, что разработчики SSH всё-таки умеют доводить дело до конца, пусть и спустя десятилетия.
Если отвлечься от брутфорса паролей, то распознавание литературной речи по времени между нажатиями клавиш вообще почти тривиальная задача, потому что энтропия связного текста крайне низкая: для английского это 0,6−1,3 бита на символ (Клод Шеннон «Прогнозирование и энтропия литературного английского»), а наша атака позволяет извлечь 1,2 бита на символ. То есть чисто по времени между пакетами в сети можно свободно распознавать весь текст пользователя, и никакое шифрование не поможет. Возможно, злоумышленники уже пользуются этой возможностью.
Отсюда вывод: не нужно набирать тексты в интернете. Лучше набрать сообщение в офлайновой программе (в «Блокноте», например), а в браузер/мессенджер вставить копипастом.
Узнавайте о новых акциях и промокодах первыми из нашего Telegram-канала ????
Комментарии (109)
vasilijmooduckovic
01.11.2023 11:14-8так там ничего и не видно пока не нажмёш ентер что эсэсаш что су/судо
sleirsgoevy
01.11.2023 11:14+10Зато в исходящем трафике вводимые байты прекраснейшим образом видны. Клиент тупой, и не понимает что прямо сразу их можно не отправлять.
vasilijmooduckovic
01.11.2023 11:14+4суть статьи в одном предлажении), ато они там начали затирать про visual feedback ("звёздочки") которых нет (по умолчанию)
kvazimoda24
01.11.2023 11:14+17Статья какая-то смесь из современного и 90-х.
По крайней мере, отображение звёздочек в консоли не видел с момента начала пользования линуксом, т.е. с конца нулевых.
А в плане SSH лучше использовать авторизацию по ключу. Так и пароль пересылаться не будет, и в принципе ключ подобрать сложнее.
Aldrog
01.11.2023 11:14+4По крайней мере, отображение звёздочек в консоли не видел с момента начала пользования линуксом, т.е. с конца нулевых.
Опция отображать звёздочки у su/sudo есть, у некоторых левых приложений это поведение по умолчанию (а иногда даже единственное). Но конечно да, это всё относительная экзотика. Остаётся анализ частотности нажатий клавиш.
А в плане SSH лучше использовать авторизацию по ключу. Так и пароль пересылаться не будет, и в принципе ключ подобрать сложнее.
SSH и не должен пересылать каждое нажатие на этапе ввода пароля к нему, так что описанный в статье вектор атаки тут не применим в любом случае (и в статье обратное не утверждается). То, что авторизация по ключу неплохо защищает от брутфорса правда, но к обсуждаемому тексту это отношения не имеет.
sleirsgoevy
01.11.2023 11:14+3Некоторые сервера вместо штатной авторизации по паролю применяют авторизацию keyboard-interactive, которая как бы... интерактивная. Ну и даже если сервер нормальный и таким не страдает, при вводе пароля в том же sudo байты всё равно будут идти интерактивно.
Aldrog
01.11.2023 11:14+1Некоторые сервера вместо штатной авторизации по паролю применяют авторизацию keyboard-interactive
Интересно, впервые слышу о такой опции.
при вводе пароля в том же sudo байты всё равно будут идти интерактивно
Так я о том же говорю:
Опция отображать звёздочки у su/sudo есть, ... (без неё) Остаётся анализ частотности нажатий клавиш.
maximw
01.11.2023 11:14+3А в плане SSH лучше использовать авторизацию по ключу. Так и пароль пересылаться не будет, и в принципе ключ подобрать сложнее.
Речь идет не про установление SSH соединения, а про передачу секретов через уже установленное соединение.
kvazimoda24
01.11.2023 11:14+1Но тогда какое отношение имеет отображение звёздочек к SSH, если эти самые звёздочки (не)отображает приложение, с которым в данный момент работаешь на сервере?
И вообще, сложилось ощущение, что речь про обфускации только во время ввода пароля, но тогда непонятно, откуда SSH знает, что сейчас вводят пароль, если речь о сторонних приложениях?
raamid
01.11.2023 11:14+1Как я понимаю, если найросети передать в большом количестве тайминги нажатия то она потенциально сможет восстановить текст, а взломщик уже потом будет разбираться пароль это или не пароль.
mayorovp
01.11.2023 11:14-1Отображение "звёздочек" тут относится не к SSH, а к браузерам и другим программам где есть поля ввода пароля.
kvazimoda24
01.11.2023 11:14+1Отлично, теперь ещё и браузер появился. И какое отношение браузер имеет к SSH? Или мы про X11Forward? Тогда надо вообще все каналы внутри SSH обфусцировать. Но не уверен, что это понравится тем, кто использует SSH как VPN.
mayorovp
01.11.2023 11:14Никакого отношения нет, просто суть атаки та же самая. Да, статья написана странно и постоянно прыгает с одного на другое.
kvazimoda24
01.11.2023 11:14-1Вот под этим подпишусь. Читаю тут комментарии, и вижу, что не я один не понял большую часть статьи.
unreal_undead2
01.11.2023 11:14По идее если я ввожу в браузере логин/пароль, а потом жмакаю кнопку, пароль отсылается одним реквестом. Разве что какая то новомодная страничка вмешивается в процесс ввода пароля Javascript'ом и отсылает что то на сервер в процессе - но за такое руки отрывать...
mayorovp
01.11.2023 11:14Так речь и не про сеть, тут речь о том, что если кто-то стоит у вас за спиной и считает "звёздочки" на экране - он может значительно сократить сложность подбора пароля если запомнит ещё и интервалы между этими "звёздочками".
unreal_undead2
01.11.2023 11:14+1Вроде в статье речь именно про передачу по сети и MITM. Из за спины и нажимаемые кнопки можно подсмотреть.
saboteur_kiev
01.11.2023 11:14если есть поле ввода пароля, то пароль передается не по буквам, а целиком, после того как ты нажал submit / enter
А отображение звездочек относится не к ssh а к tty, видимо
eri
01.11.2023 11:14-1ключ обычно подходит к нескольким дверям. ключ сложно поменять при компроментации
alexxisr
01.11.2023 11:14+4Зачем использовать один ключ к нескольким сервисам? Как вы используете сэкономленные килобайты?
И в чем сложность замены ключа по сравнению со сменой пароля?
uuger
01.11.2023 11:14+3сложно раскатать .sshd/authorized_keys ? у большинства админов это вообще автоматизировано
domix32
01.11.2023 11:14Единственное что надо отслеживать у кого куда есть доступы чтобы все эти ключи на разных хостах стирать после компрометации.
mayorovp
01.11.2023 11:14+2Стереть ключ проще чем сменить пароль.
iig
01.11.2023 11:14-1Стереть - не сильно проще. Нужно зайти на каждый хост, где есть ваш публичный ключ, и сделать некоторые действия.
saboteur_kiev
01.11.2023 11:14Как раз пароль поменять сложнее, так как подразумевается, что паролем может пользоваться несколько человек, и его смена аффектит еще кого-то.
Ключи изначально более гибкий механизм, и каждый может свой индивидуальный ключ делать, чтобы точечно отключать тех, кому доступ уже закрыт
saboteur_kiev
01.11.2023 11:14формат публичного ключа позволяет положить туда комментарий, чтобы знать чей он и откуда приехал
domix32
01.11.2023 11:14Я про ситуацию когда на Х машин есть доступ по ключу K. Этот ключ честно угнали и теперь мы хотим на всех хостах выпилить этот самый ключ. Ручками ходить на N (> X) машин и искать на каких из них прописан этот ключ как минимум неудобно и потенциально уязвимо к человеческому фактору.
iig
01.11.2023 11:14+1Если ключ честно угнали, то одно из первых действий угонщика - зайти с этим ключом на все ваши сервера и подбросить туда свой.
saboteur_kiev
01.11.2023 11:14+2Если у вас адванцед секурити, то ключи не должны лежать в $HOME
Раскладывайте их админом в /etc/ssh/keys и пользователи не смогут сами ключи ложить, только через админа.
А у админа какой-нить скрипт или ансибл
И все.
Это в любом случае проще чем с паролями, ибо скомпроментированный пароль ты подсмотреть не можешь и распознать не можешь
Johan_Palych
01.11.2023 11:14По крайней мере, отображение звёздочек в консоли не видел с момента начала пользования линуксом, т.е. с конца нулевых.
echo -e "Defaults\tpwfeedback" | sudo tee -a /etc/sudoers.d/0pwfeedback Выйти-войти в сессию cat /etc/sudoers.d/0pwfeedback Удалить звездочки sudo rm /etc/sudoers.d/0pwfeedback
kvazimoda24
01.11.2023 11:14Но зачем?
Так то, я sudo везде настраивают, чтобы не спрашивал пароль, ибо безопасности не сильно добавляет, а бесит неимоверно. Да и на большинстве машин у моего пользователя просто нет пароля. А там где есть, этот пароль вставляется из менеджера паролей через буфер обмена, т.е. тоже фиг отследишь по сетевым пакетам.
Ну и не одним sudo полон мир. А как же clickhouse-client или passwd? Или вот я захожу по SSH на BMC контроллер сервера, оттуда в консоль сервера, там стандартное приветствие для ввода логина и пароля. Там тоже предлагаете включать звёздочки?
Т.е. я про то, что по крайней мере в мире Линукс не отображение звёздочек в консоли является стандартом де-факто. И чтоб это глобально по всей системе изменить, надо довольно много усилий.
Johan_Palych
01.11.2023 11:14В некоторых дистрибутивах Linux звёздочки в терминале отображаются по умолчанию. Обычная свисто......ка
Ну и не одним sudo полон мир. А как же clickhouse-client или passwd?
passwd - изменяет пароль пользователя
https://manpages.ubuntu.com/manpages/jammy/ru/man1/passwd.1.html
Может sshpass?
Non-interactive ssh password authentication
https://packages.ubuntu.com/jammy/sshpasskvazimoda24
01.11.2023 11:14И чем вас смутил passwd? Вы никогда пароль не меняли?
А вот как раз sshpass'у я не понял, как поможет обфускация времени между пакетами. Он и так одним пакетом пароль отправляет.
arheops
01.11.2023 11:14Не совсем понятно, какую опастность это влечет для SSH
В протоколе давно используются динамические ключи для каждой сессии, а в пределах сессии вы не наберете нужную для дешифрации информацию.
Опознания пользователя? Ну так он отправляет свой ключ в начале сессии, всегда одинаковый.
ps звездочки видел только в интерфейсах мейнфреймов и в 1200бод соединениях.
sleirsgoevy
01.11.2023 11:14+3Это нужно не для дешифрации сессии. Идея в том, что если я, например, захожу на SSH-сервер и ввожу там пароль от sudo, чтобы обновить пакеты, то по таймингам пакетов с буквами пароля можно попытаться восстановить сам пароль — а так как он такой же, как и пароль самого пользователя, то с ним можно сразу же наведаться на сервер, и ничего расшифровывать не надо.
arheops
01.11.2023 11:14-4Врядли. Дело в том, что пароль судо вы будете вводить как "устоявшуюся конфигурацию", тоесть с одинаковой скоростью. а елси пароль для вас новый - то вы будете его вводить по буквам и тут вообще не угадаешь с длительностью.
Плюс вам надо как-то узнать где вы тут пароль судо вводите во всей сессии.
Исследования явно проводилося не для рандомного пароля, а для слов языка.
saboteur_kiev
01.11.2023 11:14+9Ну вот в статье как раз и утверждается, что даже устоявшаяся конфигурация все равно имеет свой рисунок тайминга, и то что для вас "одинаковая скорость", для компа - "дактилактический отпечаток".
arheops
01.11.2023 11:14-3отпечаток - да. ибо оно устоявшееся. но кореляция с другими командами - неа.
Но блин. отпечаток ваш хост ид. вы его шлете каждый раз вообще без вопросов.
valera5505
01.11.2023 11:14+1Еще одна причина отключить аутентификацию в SSH по паролю
RH215
01.11.2023 11:14+1Не панацея: пароль может быть и от третьих ресурсов.
valera5505
01.11.2023 11:14Еще одна причина использовать двухфакторку для доступа к третьим ресурсам :)
sdore
01.11.2023 11:14+3Опознания пользователя? Ну так он отправляет свой ключ в начале сессии, всегда одинаковый.
Это ключ одинаковый. А пользователь (человек!) может работать с разных машин в разных концах мира, и его всё равно можно будет опознать по таймингам. Это может сыграть ключевую роль в идентификации и поимке киберпреступников, к примеру.
nikhotmsk
01.11.2023 11:14+5Наконец то, кто-то написал про это. Теперь я не буду выглядеть дураком когда попытаюсь объяснить что такое тайминг атака на ssh. Это даже глазом видно, по индикации на ethernet разъеме.
Vilos
01.11.2023 11:14+4Ой! Я вас умоляю! Вы кому-то объясняете "что такое тайминг атака на SSH"??? Да куче людей нужно объяснять, что пароли не нужно писать на стикере и клеить на мониторе!
Был свидетелем когда у одного крупного провайдера в телеграмм группе, видел как инженеры друг дружке пересылали пароли от доступа к магистральному оборудованию....у меня аж глаз дергаться стал.
xenon
01.11.2023 11:14+2А самое смешное - что при этом этот провайдер вполне себе работает, деньги крутятся, прибыль идет. Убытки от проблем в защите информации - или нулевые или терпимые...
Более того, если подумать - то сверхсложный пароль, который надо получать по какой-то сложной процедуре (придти в три кабинета, собрать три подписи) - это уже угроза безопасности, так как пароль-то не просто так нужен, для развлечения, а для исправления реальной проблемы. И нет доступного пароля = вполне себе угроза безопасности "недоступность ресурса". Как бы сами себя паранойей заDoSили...
Xenos_rus
01.11.2023 11:14+7Эти вечные качели между безопасностью и удобством. Если не позволять инженерам пользоваться менеджерами паролей - будут пересылать в телеге или в файлике на гуглодоках. Если юзера пережать с политикой длины и частоты смены пароля - актуальный пароль будет написан на стикере и приклеен на монитор или снизу к клаве. Основано на реальных событиях (с)
intet
01.11.2023 11:14+2Вопрос где писать пароли, кроме как на стикере монитора? Я вот не могу запомнить 3 разных меняющихся каждый месяц 12 значных пароля, а менеджеры паролей запрещены по безопасности.
Vilos
01.11.2023 11:14+1Когда у меня был такой адовый ад на работе, то я для себя выработал логику обновления паролей, согласно этой логике забыть пароль сложно.
В вашем случае могу порекомендовать запомнить 3 пароля а в конце(/начале) каждого из них добавлять предыдущий месяц в текстовом формате. Ну както так...включите фантазию. Или например добавлять номер месяца в 16-тиричной (8-ми\ двоичной) системе. В этом случае пароль запоминать каждый месяц необязательно, достаточно запомнить систему.
intet
01.11.2023 11:14Так они проверяют пароли, что новые не должны быть слишком похожи на старые. То есть просто добавлять/менять часть пароля нельзя.
Да и плюс некоторые пароли генерируются из вне, их нельзя сменить самому на то что хочешь.
Vilos
01.11.2023 11:14+9Если "они" проверяют пароли на "похожесть", значит они их хранят не в виде хешей с солью, а в виде текста - НАРУШЕНИЕ БЕЗОПАСНОСТИ.
-
Если "они" генерируют пароли, а не вы из своей головы - НАРУШЕНИЕ БЕЗОПАСНОСТИ.
Безопасники у вас так себе, только создают вид работы и параллельно создают сложности для людей, ничего общего с безопасностью тут нет.
mayorovp
01.11.2023 11:14+1Да нет никаких нарушений безопасности (если не считать нарушением само существование тупой политики паролей).
Хранить в виде текста нельзя актуальные пароли, а вот запрета хранения устаревших и более не работающих я в рекомендациях не видел. Откуда они возьмутся? Очень просто, при смене пароля же надо ввести старый!
Кстати, если сравнивать не с N последними, а просто с последним паролем - то и вовсе хранить ничего не надо.
Про генерацию то же самое, в большинстве случаев пароль до сервера всё равно идёт в открытом виде по шифрованному соединению, в чём проблема один раз передать его в том же виде по тому же соединению в обратную сторону? Никакой разницы.
intet
01.11.2023 11:14Они проверяют как понимаю текущий и прошлый пароль. Их можно сравнить так как в момент смены требуется оба.
Проблема в генерации паролей - то что одним пользователем пользуется несколько человек и соотвественно просто менять пароль нельзя.
А так абсолютно согласен, что у нас в крупнейшем банке страны безопасники в основном заняты созданием сложностей для людей и ухудшением безопасности.
iig
01.11.2023 11:14+2одним пользователем пользуется несколько человек
О_о
mayorovp
01.11.2023 11:14Постоянная ситуация на самом деле. Большинство b2b-сервисов даже не догадываются что у их клиентов может быть несколько сотрудников или даже подрядчиков: дают всего одну учётку на клиента.
intet
01.11.2023 11:14+1У нас все из-за дурацких требований безопасности, что на стендах ближе к прому пользователей заводят только из расчета один человек - одна учетка. А если надо проверять под разными ролями, то пользуйся учеткой от коллеги.
iig
01.11.2023 11:14значит они их хранят не в виде хешей с солью, а в виде текста
Не значит. Они могут ваш новый пароль несколько (сотен) раз менять и смотреть не совпал ли хеш с предыдущим(и) ;)
Firsto
01.11.2023 11:14Не понял, куда менять, как менять, как они поймут, что старый пароль jun23MahSup4rP@ssw0rd слишком похож на новый dec23MahSup4rP@ssw0rd ?
mayorovp
01.11.2023 11:14Новый пароль известен, генерируем все похожие на него пароли, хешируем и сравниваем со старым. Да, тоже вариант.
iig
01.11.2023 11:14+1Не понял, куда менять, как менять
John the ripper как-то понимает же.
В вашем пароле просматриваются такие лексемы:
-- слова из словаря
-- числа
-- слова из словаря с очевидными подстановкамиРаспарсить новый парол на лексемы. Нетривиально, да.
Составить правило для перебора - можно и автоматически, да.
Прогнать несколько (сотен, или тысяч..) итераций подбора пароля. Тривиально, да.Но я уверен, что так никто не будет заморачиваться ;)
iig
01.11.2023 11:14+1Вопрос где писать пароли, кроме как на стикере монитора?
На стикере монитора и под клавой. Часть пароля там, часть там. Символ между частями пароля запомнить ;)
selivanov_pavel
01.11.2023 11:14В этом случае можно использовать какое-нибудь мнемоническое правило, в зависимости от номера месяца и названия ресурса.
Но, вообще, если запрещают менеджеры паролей и требуют смены раз в месяц - то стикеры закономерный итог такой политики.
Earthsea
01.11.2023 11:14К этому оборудованию обычно нет доступа из интернета. И даже если получить доступ к внутренней сети, то можно оказаться не в том VLAN. Возможно, что те пароли вообще временные, на время настройки и ввода в эксплуатацию, а потом их поменяют. Скажу больше, особенно в телефонии много на каком оборудовании вообще telnet используется, ssh в принципе нет. Где-то мало того что telnet, так еще и без пароля, даже так. Где-то к любой циске подходи, тыкай консоль и делай что хочешь, порой даже дверца шкафа не то что на ключ не закрыта, а снята и убрана подальше. Кого попало в машинный зал не пускают, но есть подрядчики и арендаторы со своими собственными стойками в зале, а это практически кто попало ходит, можно сказать.
artem-phys
01.11.2023 11:14+6Интересная тема. Где-то видел статью про распознавание пин-кода в банкомате по звуку клавиш с помощью очень точного направленного микрофона
splatt
01.11.2023 11:14+2Интересно, как на вектор атаки влияет TCP_NODELAY 0 ? Разве несколько нажатых клавиш по умолчанию не будут батчится в один пакет, что в разы усложнит реализацию подобной атаки?
NutsUnderline
01.11.2023 11:14-2Пользователя нужно очень сильно хотеть деанонимизировать даже таким ненадежным способом, который в целом остается "хайли лайкли". Пока такой фигерпринт не введут в уловный кодекс можно БЫ спать спокойно, но ведь такая же толпа доброхотов все всегда кого то хочет деанонить. они не понимают что эти старания приведут к поимке максимум одного злодея на 100ню вообще непричастных.
Что качается пароля - а зачем в пароле английские слова вообще? Не научены ееще рандомные пароли? более того я не понимаю: чем временной паттерн пароля QWERTY отличается от паттерна ASDFGH, разница будет микроскопическая - брут будет не 100 лет а 50, ага.
Arkasha
01.11.2023 11:14+2а потом легко распознать этого человека по таймингу буквенных пар, на какой бы клавиатуре он ни работал
У одного человека на qwerty и dvorak совсем разные характеры набора
firehacker
01.11.2023 11:14+4Предлагаю всем желающим угадать мой 8-символьный пароль. Паузы такие:
137 мс
136 мс
137 мс
136 мс
136 мс
137 мс
136 мс
iig
01.11.2023 11:14+5Либо месье пианист
Либо месье шутит
Так то по одному эпизоду, конечно же, ничего угадать нельзя. Но, если представить, что товарищи не поленились записать траффик за год, и они умеют отличать ssh от торрентов, да еще и это повсеместное увлечение нейросетями.. Не время улыбаться.
saboteur_kiev
01.11.2023 11:14у вас моторика среднего пальца развита хуже, чем указательного.
QDeathNick
01.11.2023 11:14+1Как вы по этим таймингам определили, что он пальцами набирал? Может у него тентакли.
saboteur_kiev
01.11.2023 11:14+1А это не тайминги, это условия задачи - набирать пароль пальцами =)
ну и очень большие и равные промежутки - я бы сказал, использует два пальца разных рук, неторопясь.Тут ногами можно быстрее наклацать.
iig
01.11.2023 11:14+3ну и очень большие и равные промежутки
137 мс большой промежуток? Это 8 равномерных нажатий за секунду. С вероятностью 1/50 пароль 8 звездочек (или других одинаковых символов) ;)
Aldrog
01.11.2023 11:14Подтверждаю, у меня для реального пароля, набираемого машинально десятью пальцами, средний промежуток между нажатиями порядка 170мс, а при отсчитывании нужного количества нажатий одной клавиши - как раз около 130.
vviz
01.11.2023 11:14Сервер ssh в одном городе, клиент ssh в другом. Между этими двумя точками штук пять промежуточных маршрутизаторов, принадлежащих разным провайдерам.
Внимание, вопрос - кто, кроме сотрудника одного из провайдеров, может перехватить трафик для анализа?mpa4b
01.11.2023 11:14Любой кто на соседнем этаже незаметно подключится к ethernet кабелю от вас к провайдеру, например.
saboteur_kiev
01.11.2023 11:14+1кроме сотрудника одного из провайдеров, может перехватить трафик для анализа?
Еще один сотрудник провайдера. Устроиться в сотрудники провайдера с доступом в домовые свитчи - задача для джуниор админа несложная.
Было бы что красть...
Sap_ru
01.11.2023 11:14тут было заявление про Nagel's algorithm, но оно было неверным, а верное стало писать лень ;)
Но суть в том, что в SSH автоматически включается Nagel's и передаваемые символы начинают группироваться и объединяться, что портит хакерам весь праздник.
dmitry78
01.11.2023 11:14-2"Любой кто на соседнем этаже незаметно подключится к ethernet кабелю от вас к провайдеру, например. " - веселый у вас провайдер - у мну (на меди) (витая, не кокс) при смене вин-дров надо было звонить провайдеру , и как минимум сказать на кого договор, что-бы сменить MAC . с оптикой веселей - мигры из подьезда удивлялись "что медь перестала работать" (пару раз слушал набор номера по треньканью на телефоне) про ссш глумился - на своем самосборном роутере (I atom, gentoo) вломил 31 значный пароль и 4096 ключ, что-бы не городить периферию для коробки (- su по ssh для дженты - ну за год выучил как не компилировать систему раз в квартал :-) ) а на работе - в одном прекрасном месте "РеклАгентсво" админ (сапог) учюдил менять пароли (и для дезигнеров) раз в мес - пароли были и под клавой, и на экране, гемора много, толку мало
mpa4b
01.11.2023 11:14Не понял причём тут MAC, во1 можно пассивно слушать трафик (иголки в кабель), во2 можно в разрыв воткнуть 2 сетевушки, каждая в promiscuous mode (т.е. ловит вообще все пакеты, а не только те, где DSTMAC с её собственным совпадает или бродкасты).
vviz
01.11.2023 11:14-2Это только Ваши фантазии. В реальности такое не реально сделать - выйдите на лестничную клетку и попробуйте подцепится, а потом фоточки нам представьте.
Всё это просто страшилки - в бытовых условиях многоквартирного дома отзеркалить трафик - требуется конкретно попотеть, и скоро ждать привета от провайдера.
NutsUnderline
01.11.2023 11:14-1И у провадера нет группы быстрого реагирования, у него только монтажники (очень) медленного реагирования
Можно купить книжку почитать в конце концов
vviz
01.11.2023 11:14-2Это - лабороторные условия. И фотошоп никто не отменял. Еще раз говорю - выйдите на лестничную клетку и попытайтесь такое повторить.
NutsUnderline
01.11.2023 11:14+2А кто сказал что это будет делать я или скажем сосед-кулххакер, с сетевухой за 5 баксов. Сделать это может кто то более компетентный и оснащенный каким нить монитором трафика промышленным. "не реально сделать " и "конкретно попотеть " это две большие разницы, факт в том что технически это возможно.
Витая провайдера ведущая в принадлежащее мне помещение проходит через абсолютно не закрытую клемную коробку, там даже иголок не надо, но я боюсь трогать - как бы совсем не развалилось.
vviz
01.11.2023 11:14Итак, у меня есть потребность заломать Вас. Я выяснил в какой квартире вы находитесь. Часов в 6 утра я сажусь на лавочку рядом с Вашим подъездом и жду выйдите ли Вы. Скажем до 10 часов Вы не вышли - я делаю вывод, что вы остались дома. Я достаю из своей машины стремянку и тех. средства. Поднимаюсь на ваш этаж, подхожу к этажной коробке и вижу что в направлении двери тамбура, за которой находится Ваша квартира идет две витые пары (не оптика - смысла тогда вообще нет). Какая же витая пара Ваша?
Я подкинул монетку и решил к какой подключаюсь. Прицепил крокодилы и начал дампить трафик. Какова вероятность что Вы введете критичные данные в ближайший час или через два часа или через три? Вероятность отлова будет повышаться с течением времени, поэтому, что бы существенно повысить вероятность нужно продержаться существенное время. Было бы неплохо оставить оборудование и уйти и забрать через сутки или сидеть рядом с подъездом и перегонять трафик непосредственно себе. Если коробка металлическая - удаленно снимать не выйдет. Если коробки нет - тем более не выйдет. Если срослось и какая то коробка осталась значит нужно мне оставить свое оборудование и уйти. И какова гарантия, что оборудование будет на месте, когда я вернусь?Далее, вот мой провайдер использует L2TP с шифрованием - нужно будет вскрыть ключ, что бы декапсулировать пакеты. Возможно у Вас не так - но все одно вероятность блакополучной добычи критичных данных стремительно падает.
Далее, если органам нужны Ваши данные они по любому их добудут, но вот вариант с хакером-одиночкой и перехват Вашего трафика по кабелю ничтожно вероятен.
Все имеет свою вероятность - человек может выпасть из окна 11 этажа и остаться жив. Так же и с перехватом трафика вне локальной сети.
NutsUnderline
01.11.2023 11:14+2Как я уже подсказал выше: увидеть и подключиться к моим парам - вообще не проблема, стремянки не надо (если рост не метр с шапкой). Проблема скорее домофон но мы прекрасно знаем что она решаема. Коробка пластиковая, вообще не закрытая, можно туда засунуть роутер или малинку - и если кто их и заметит то только я сам. Собственно именно эти факты несколько и будят мою фантазию именно в этой области, когда гляжу на эту коробку. Но вообще, меня зовут Неуловимый Джо - могу скинуть скан паспорта (нет конечно) :) :) :)
iig
01.11.2023 11:14+1выйдите на лестничную клетку и попытайтесь такое повторить.
Нужно одеть спецовку, желательно с логотипом какого-нибудь местного провайдера, и взять ящик с какими-то инструментами. И никто вам ни слова не скажет.
vviz
01.11.2023 11:14Посмотрите на обложку книги из поста NutsUnderline - человек в капюшоне. Кто в трезвом разуме будет торчать в подъезде в спецовке провайдер в капюшоне на голове? Ибо разумный хакер (преступник) будет пытаться скрыть лицо, поскольку любопытных пенсионеров полно и это сразу вызовет любопытство - а чего это он торчит в подъезде целый день и лицо прячет?
iig
01.11.2023 11:14+4Зачем торчать весь день и
с парашютом за спинойв капюшоне? Пришел, повозился 5 минут, подключил что нужно, ушел. Бдительным пенсионерам сказал про плановые работы. Через пару дней забрал.
Или же просто устроился на работу к провайдеру.
NutsUnderline
01.11.2023 11:14Ну нет тут извините, че прям во всем книжки следовать. Самое ржачное - у емня есть черное худи, может вообще это я там на обложке :) :) :)
Но доля истины есть в обоих случаях: да логично одеть спецовку, да есть именно такие люди (конкретно в моем подьзде) которые докопаются и до человека в спецовке (проверенный факт). Именно поэтому я за это не особо беспокоюсь :)
saboteur_kiev
01.11.2023 11:14борода,усы, немного грима.
Вы ж понимаете, что подобный случай взлома явно делается в условиях, когда планируется с этого взлома получить сумму которая явно покрывает подобные мелочи?
relgames
01.11.2023 11:14Кто-то ещё вводит пароли сам? Уже лет 10 пользуюсь KeePassXC, пароль набирается автоматически либо вставляется из буфера.
director-rentv
Возможно, я что-то не так понял, но почему прямо таки необходимо отправлять по сети каждый символ по мере набора?
13werwolf13
потому что существуют интерактивные TUI интерфейсы
но проблема уже не актуальна ибо патч с фиксом уже релизнулся
dark991
возможно я что-то не так понял, но почему бы на экран удаленного терминала не выводить сразу то, что вводишь?
Arkasha
Потому что кто-нибудь увидит как минимум количество символов, а это на порядки облегчает брутфорс. А можно упороться и обучить модель на видимом тексте, который вы на этом же звонке вводили
dark991
так скрывать визуальное отображение символов не дело ssh.
ссш передает то, что вводишь. функция командной оболочки - скрыть символы, их количество и все что угодно.
получается, каждое нажатие кнопки удаленно - это отдельный запрос внутри потока. либо отдельный пакет от удаленного компа к целевому, не важно.
поэтому и ввели на транспортном уровне группировку, тайм-лаг и шифровку данных внутри ssh канала. разве нет?
p.s. прошлый мой вопрос неверно сформулировал. вернее должно быть так: "почему бы на удаленный терминал не передавать сразу то, что вводишь?"
так и было сделано. но это уязвимость, т.к. канал можно захватить, и пароли от нажатия клавиш - перехватить внутри канала