| |
| 2.6, arfh (?), 23:23, 04/07/2020 [^] [^^] [^^^] [ответить]
| +6 +/– |
Эта уязвимость касается всех. При чём здесь FreeBSD? Тем более, некуда обновляться. Исправленной версии нет.
| | |
| |
| 3.20, бублички (?), 02:31, 05/07/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
или el coño, или la chimba, т.к. в PuTTY легко проследить отзыв к pussy
| | |
| |
| 4.38, Аноним (38), 10:58, 05/07/2020 [^] [^^] [^^^] [ответить]
| –4 +/– |
Их и так называют pussy.exe. Возможно я один из первых кто предложил этот термин более 10 лет назад, а возможно и нет.
| | |
|
|
| |
| |
| 4.48, Аноним (48), 13:07, 05/07/2020 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> А какое ДЕ на твоей free bsd?
У меня просто иксы, WM, панелька и набор самых удобных для меня, абсолютно независимых от тулкита или ЯП программ - вместо так любимого линуксоидами (особенно из ютубных видео выше) почти религиозного самоограничения "зато однообразно, красиво и прям как в венде или макоси!".
Кстати, неплохой уход с темы тулзов для администрирования убунты ))
| | |
| |
| 5.49, Аноним (38), 13:12, 05/07/2020 [^] [^^] [^^^] [ответить]
| +/– | |
Ну я свои убунты и чентоси администрирую с кубунты и манджары(с кедами тоже). Эти же машины админят суровые бздшники с вантузов, ибо вынуждены. Этот комментарий пишется с кубунты.
> почти религиозного самоограничения "зато однообразно, красиво и прям как в венде или макоси!".
мне на это плевать. Не тулкит красит программу, а программа - тулкит.
| | |
| |
| 6.55, Аноним (-), 15:18, 05/07/2020 [^] [^^] [^^^] [ответить] | +2 +/– | Оно и видно по предыдущим комментаторам, как пингвиноидам на это плевать Инфа... большой текст свёрнут, показать | | |
| |
| 7.86, Аноним (-), 15:13, 07/07/2020 [^] [^^] [^^^] [ответить] | +/– | А ты, Гена, гений Я правильно понимаю этот вопль души Эта ниправильные линукса... большой текст свёрнут, показать | | |
|
|
|
|
|
| 2.69, bOOster (ok), 05:48, 06/07/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Типичный линухсоид, не понимающий какие сервисы работают в его системе.. Позор.
| | |
| |
| 3.78, Аноним (-), 12:31, 07/07/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Типичный линухсоид, не понимающий какие сервисы работают в его системе.. Позор.
Зачем местным линухоидам Putty или OpenSSH, если у них для локалхоста есть Prallels и WSL, а для ремота - вебпанелька?
| | |
|
|
| 1.2, Аноним (2), 23:17, 04/07/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– | |
> Те кто проверяют отпечатки ключей проблеме не подвержены.
А вот поди проверь его! Если сервер за том конце шара)
И никакой псевдографики не показывается.
| | |
| |
| 2.13, Аноним (13), 00:12, 05/07/2020 [^] [^^] [^^^] [ответить]
| +/– |
И причём тут псевдографика? Если вы про рисунок, сопровождающий отпечаток, так он именно дополняет, а не заменяет строковое значение.
| | |
| 2.15, An0n (?), 00:26, 05/07/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Речь же о MITM, то есть на сервер то вы попадёте, только через злоумышленника. Ну а там уже можно и проверить.
| | |
| 2.36, Аноним (36), 10:29, 05/07/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
 А зачем Вам подключаться в первый раз к серверу через хакерский Wi-Fi? Да ещё и не проверив fingerprint через сторонние ресурсы. Уязвимость в стиле: а вот была бы у него подпись VerySign...
| | |
| 2.44, YetAnotherOnanym (ok), 12:42, 05/07/2020 [^] [^^] [^^^] [ответить]
| +/– |
 А пароль для входа на этот сервер вы знаете? Или ключик ваш как-то прописан на сервере? Если так, то возможность узнать отпечаток ключа сервера у вас точно была.
| | |
|
| 1.3, Онаним (?), 23:18, 04/07/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> Те кто проверяют отпечатки ключей проблеме не подвержены.
Ну и басиньки.
| | |
| |
| 2.4, Онаним (?), 23:20, 04/07/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Это вот к тому, что меня тут где-то кто-то упорно вопрошал - а зачем вам закрытая сеть и несколько уровней доступа, включая VPN. Ведь КЛАУД! ДОКЕР! СМУЗИ!
Вот затем и нужен, чтобы желающие подменить ключ менее опытным пользователям пошли на хрен ещё на этапе доступа к трафику.
| | |
| |
| |
| 4.74, Аноним (74), 15:54, 06/07/2020 [^] [^^] [^^^] [ответить]
| +2 +/– | |
Нуб!
Host *
StrictHostKeyChecking accept-new
UserKnownHostsFile /dev/null
| | |
|
| 3.31, Аноним (35), 09:41, 05/07/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Всё бы ничего, но вот только докер позволяет сделать клауд в закрытых сетях реальностью. И всякие кроваво-ынтырпрайзные финтехи этим давно уже пользуются. Посмотри на HSBC, Mr. Cooper, Deutsche Bank... Ну это те, в которые я деплоил всякую кубернетщину. Насчёт смузи - покупаю иногда.
Так что, я бы вам порекомендовал немножко разобраться в теме, прежде чем писать такие комментарии.
| | |
| |
| 4.33, Онаним (?), 10:09, 05/07/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Приведённый списочек в каком-то плане показателен :)
С Deutsche Bank наверное больше всего работали, нет?
| | |
| |
| 5.34, Аноним (35), 10:15, 05/07/2020 [^] [^^] [^^^] [ответить]
| +/– |
В этих местах крутится одно из наших решений, да. Самый показательный - это HSBC.
| | |
|
|
|
|
| |
| 2.11, DerRoteBaron (ok), 23:54, 04/07/2020 [^] [^^] [^^^] [ответить]
| +6 +/– |
 Уязвимость в том, что можно определить, кого MITM'ить есть смысл, а у кого хост уже известен и MITM наверняка вскроется
| | |
| 2.53, Аноним (53), 14:19, 05/07/2020 [^] [^^] [^^^] [ответить]
| +3 +/– | |
Уязвимость в том, что народ наконец изучил матчасть, и понял, что само по себе SSH как "крест животворящий"(с) от MITM не защищает. А чтобы всё работало нужно на первом этапе сверить отпечаток ключа.
Вернее это было всегда, но вот теперь нашли способ отделить первое подключение от уже существующих и сильно не палится.
Ответ от OpenSSH прекрасен. Парни явно не хотят костылить, а предпочитают решать проблемы, и протокол на данный момент уже имеет средства решения, и ими просто нужно пользоваться если нужно доверенное соединение.
| | |
|
| 1.10, Аноним (10), 23:39, 04/07/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
Сколько программ, столько и уязвимостей! Возможно ли написать программу без ошибок, если ты не робот? Сомневаюсь...
| | |
| |
| 2.17, Аноним (17), 00:27, 05/07/2020 [^] [^^] [^^^] [ответить]
| –6 +/– |
Можно и даже было бы нужно, но это в идеальных условиях, неограниченное время и команда собранная из профи с образованиями не меньше докторского из нормальных западных универов с опытом лет 10 прод разработки. А не веб мака с опытом работы 1 неделя жабаскрипта и оптимальным манагером который урезает и так уже короткое время и требует всяких разных фичей которые кроме как для промо мало кому нужны. Ну или делаются каким-то дорком дома на колене под пивом
| | |
| 2.19, doctorishe (?), 01:03, 05/07/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Если ваша программа написана без ошибок - позовите системного программиста - он исправит ошибки в компиляторе :)
| | |
| 2.40, КО (?), 11:31, 05/07/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Это не ошибка в программе. Это организационная ошибка.
Выдавать пользователю кучу цифробукв и спрашивать - оно? Путь к успеху.
В данном случае для строгой проверки клиент не должен был спрашивать оно или не оно, а спрашивать просто отпечаток у пользователя и если не оно говорить - аяяй! Но это же влом и муторно будет пользователям. Посему упрощенный вариант.
| | |
| |
| 3.68, с (?), 03:20, 06/07/2020 [^] [^^] [^^^] [ответить]
| +/– |
А винда не спрашивает при первом подключении по рдп? (спрашивает вообщето)
Нет тут ошибки, это узкое место, да, но или так, или еще большие и не однозначные костыли.
Обычно, человек проверяет чего он там (доступ) создал, из своей сети, и нет необходимости ничего сверять, все промежуточные узлы подконтрольны.
и если надо тиражировать, - создаем "профиль", в котором та самая путти с теми самыми ключами хоста.
У меня так 200 человек ушло на удаленку, 2 дня писал скрипты, которые создают пользователя, генерируют ключи, генерируют батники, собирают "профиль" и пакуют в exeшник по нажатии кнопочки на специальной страчке, у эникеев просто нет шанса накосячить, как и у юзера.
| | |
|
|
| 1.21, Anonymouz (?), 03:50, 05/07/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Баг очевидный, наверняка многие знали или догадывались, странно что написали только сейчас. Использовать можно только когда в запасе месяц-другой времени, т.е. вряд ли юзабельно в целях наживы например.
И да, даже админы очень серьезных контор не проверяли и не будут проверять отпечаток.
| | |
| |
| 2.22, Аноним (22), 04:05, 05/07/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
У меня кстати всегда холодок пробегает, когда патти спрашивает при первом коннекте... я думаю, но потом не перепроверяю ;(
| | |
| 2.25, Anonym123 (?), 04:20, 05/07/2020 [^] [^^] [^^^] [ответить]
| +/– |
я не " админы очень серьезных контор", но да, при внезапном изменении отпечатка - обязательно проверяю. страшно патамучта.
И если по какой-либо причине меняю ключ на сервере - предупреждаю коллегу.
Не, не параноик.
| | |
| 2.27, Аноним (27), 08:11, 05/07/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Баг очевидный
Бага в OpenSSH - НЕТ!
> Атака строится на беспечности пользователей,
Проблема из-за "человеческого фактора".
| | |
| |
| 3.37, Anonymouz (?), 10:40, 05/07/2020 [^] [^^] [^^^] [ответить]
| +/– |
Баг приводит к утечке информации. CVE выдали, пример атаки с его использованием есть, о чем тут спорить?
| | |
| |
| 4.51, Аноним (51), 14:03, 05/07/2020 [^] [^^] [^^^] [ответить]
| +/– |
Дайте CVE. Мне очень интересно почитать на неисправленный баг в человеческом мозге (днк) из-за которого у людей все еще сохраняется неисправленная "feature" развивающая беспечность
| | |
|
|
| 2.59, Аноним (58), 17:32, 05/07/2020 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> даже админы очень серьезных контор не проверяли и не будут проверять отпечаток.
Админы серьёзных контор подписывают хостовые ключи, поэтому у них нет необходимости проверять их глазами.
| | |
| |
| 3.66, Anonymouz (?), 22:55, 05/07/2020 [^] [^^] [^^^] [ответить]
| +/– |
Где-то хуже где-то лучше, некоторые стараются добавить все в known_hosts и раскидать по серверам, но все равно один админ с гарантией когда-нибудь полезет не проверив, возможно даже не на сервер а на домашнюю систему, где у него настроен туннель до работы, через который контору и хакнут. Например для Яндекса это сработает.
Это если не говорить об инсайде, там возможностей для гадости больше.
| | |
| |
| 4.72, Аноним (58), 14:51, 06/07/2020 [^] [^^] [^^^] [ответить]
| –3 +/– |
>> подписывают хостовые ключи
> некоторые стараются добавить все в known_hosts и раскидать по серверам
Читать и понимать написанное научись.
| | |
| |
| 5.75, Anonymouz (?), 21:27, 06/07/2020 [^] [^^] [^^^] [ответить]
| +/– |
>>> подписывают хостовые ключи
>> некоторые стараются добавить все в known_hosts и раскидать по серверам
> Читать и понимать написанное научись
С этом скорее к Вам. :-P Вы там у себя подписывате, а рядом админы компаний подходят к вопросу по-разному, иногда никак, иногда используют схему с puppet+known_hosts или что-то еще более странное... пентерстеры об этом много могут рассказать (но не станут).
| | |
|
|
|
|
| 1.24, Lex (??), 04:17, 05/07/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –10 +/– | |
Итак, в библиотеке, связанной с сертификатами и шифрованием спустя много лет нашли очередную эпическую дырищу:
-Если проект написан на JS - “ууу, вебмакаки!!111 школу вначале закончи!! А что ещё от JS ожидать ?))»
-Если проект написан на Си / Плюсах и является чуть ли неотъемлемой частью юниксовых систем, открывая хорошую такую дырень для «желающих» - «ненуачо, бывает. Просто шифроваться получше надо было и защит там всяких побольше приделать. И вообще, не бывает кода без ошибок».
| | |
| 1.26, Аноним (26), 04:25, 05/07/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Не пойму, зачем вообще менять порядок алгоритмов при аутентификации, когда ключ закеширован. Если настройки сервера и клиента не менялись, то при повторном соединении, как и при первом, выберется одинаковый алгоритм, и никакого предупреждения о смене ключа не будет. А если менялись, то предупреждение закономерно, и для хоста надо закешировать второй ключ или обновить первый.
| | |
| |
| 2.41, КО (?), 11:40, 05/07/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>Если настройки сервера и клиента не менялись, то при повторном соединении, как и при первом, выберется одинаковый алгоритм
Это еще если версии пакетов не менять и пр. А то может оказаться что в версии N+1 добавят еще один алгоритм (причем более предпочтительный) и фигакс - у тебя предупреждение, что ты лезешь на другой сервак вместо своего. При частых ложных предупреждениях, ты их начнешь игнорировать. :(
| | |
| 2.60, Аноним (58), 17:34, 05/07/2020 [^] [^^] [^^^] [ответить]
| +/– |
На сервере могли сгенерировать новый ключ для нового алгоритма, например.
| | |
|
| |
| 2.52, Аноним (51), 14:05, 05/07/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Запрещали, запрещали да, потом поняли что бессильны и разрешили при первой же возможности. Кажется это про телеграм, но не суть, применимо к любому и везде. Извините если что.
| | |
|
| 1.47, YetAnotherOnanym (ok), 12:48, 05/07/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
> будет применена попытка применения не соответствующего прокэшированному ключу алгоритма с выводом предупреждения о неизвестном ключе
Я чота не догоняю - почему нельзя воздержаться от вывода предупреждения до тех пор, пока не перебраны безуспешно все алгоритмы?
| | |
| |
| 2.54, olan (?), 14:41, 05/07/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Протокол аутентификации не позволяет перебирать алгоритмы. Там схема простая: клиент и сервер предлагают списки поддерживаемых алгоритмов, и после получения этих списков выбирается первый алгоритм из списка клиента, который поддержан сервером. Если аутентификация не прошла, соединение рвётся. Чтобы выбрать другой алгоритм, надо повторно соединиться и прислать алгоритмы в другом порядке.
И потом, отсутствие ключа в кэше клиента - это не безуспешная попытка с точки зрения протокола. Это как раз говорит о том, что у сервера поменялся ключ.
| | |
| |
| 3.63, YetAnotherOnanym (ok), 18:54, 05/07/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> соединение рвётся
Я чота не догоняю - почему нельзя воздержаться от вывода предупреждения до тех пор, пока не перебраны безуспешно все алгоритмы, совместно поддерживаемые сервером и клиентом, с установкой отдельного соединения для каждого алгоритма?
| | |
|
| 2.70, КО (?), 08:58, 06/07/2020 [^] [^^] [^^^] [ответить]
| +/– |
Т.е. пользователя надо спрашивать подряд
это ли правильная подпись - да/нет?
это ли правильная подпись - да/нет?
это ли правильная подпись - да/нет?
это ли правильная подпись - да/нет?
...
это еще более странное поведение будет.
| | |
| |
| 3.71, YetAnotherOnanym (ok), 14:09, 06/07/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> спрашивать подряд
Чёрным по светло-оливковому написано: "воздержаться от вывода предупреждения до тех пор, пока не перебраны безуспешно все алгоритмы". То есть, после перебора выдать запрос: "алгоритм X - хэш такой-то, алгоритм Y - хэш такой-то, алгоритм Z - хэш такой-то. Закэшированный хэш такой-то. Решай сам."
| | |
| |
| 4.88, КО (?), 10:45, 08/07/2020 [^] [^^] [^^^] [ответить]
| +/– |
Нету никакого перебора есть первое подключение.Речь про выбор сертификата для формирования ключа шифрования по подписи. вы предлагаете установить N шифрованных каналов, чтобы задать вопрос и потом N-1 закрыть?
| | |
|
|
|
| 1.50, Аноним (50), 13:28, 05/07/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ну по факту уязвимость условная. Да, она даёт понять, есть ли у человека захешированный ключ или нет. Те кто не проверяют ключ, они и в первый раз не проверят, и в случае изменения его не проверят нажмут yes/
| | |
| |
| 2.62, КО (?), 18:31, 05/07/2020 [^] [^^] [^^^] [ответить]
| +/– |
Как раз в случае изменения и заметят. Ибо изменение это неожиданно.
Как-то мне это помогло обнаружить конфликт ip адресов в локалке. Включаю сервак все ок. Потом что-то у него с сетью, а по ssh уже другой ключ.
А то, что в первый раз должен быть какой-то ключ - это нормальное поведение.
| | |
|
| 1.67, Аноним (67), 23:09, 05/07/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Кстати, разрабам, юзающим ssh исключительно для пуша открытых репозиториев на GitHub должно быть пофиг: выдача себя за сервер для клиента не позволит атакующему выдать себя за вас для сервера и закинуть бэкдор, но позволит принять пуш, который содержит и так публичные данные. Но вот с пуллом засада - пулл как раз атакующий может подменить, поэтому пуллить желательно по https.
| | |
|
