Спустя менее недели с момента обнаружения прошлой проблемы (https://www.opennet.ru/opennews/art.shtml?num=49142) в OpenSSH, позволявшей удалённо определить существует ли пользователь с данным именем в системе, выявлена (http://openwall.com/lists/oss-security/2018/08/28/2) ещё одна аналогичная уязвимость (CVE-2018-15919 (https://security-tracker.debian.org/tracker/CVE-2018-15919)). Проблема присутствует с 2011 года и проявляется в том числе в несколько дней назад опубликованном выпуске OpenSSH 7.8.
Предложенный метод основан на различном поведении кода аутентификации на базе API GSS2 для существующих и не существующих пользователей. В частности, если пользователь не существует, то повторяющиеся попытки аутентификации приводят к обрыву соединения с возвратом ошибки "Too many authentication failures". Для существующих пользователей подобная ошибка не выводится.
Дополнительно можно отметить выявление (http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2018q3/002...) возможности определения существования пользователя в SSH-сервере Dropbear, который часто применяется на встраиваемых устройствах и домашних маршрутизаторах. Выявленная в Dropbear уязвимость (CVE-2018-15599) повторяет прошлую проблему (https://www.opennet.ru/opennews/art.shtml?num=49142) в OpenSSH (эксплоит для OpenSSH работает для Dropbear).URL: http://openwall.com/lists/oss-security/2018/08/28/2
Новость: https://www.opennet.ru/opennews/art.shtml?num=49197
ну узнали они что есть допустим root. и что дальше-то???
Ни байта врагу!
И подбираем твой ключ несколько миллиардов лет чтобы после взлома включить тебя в единую сеть.
Ваш ботнет отстой! Вот у нас каждый подключён к нашему ботнету через Android, Apple и Windows 10.
Мб некоторые ставят слабый пароль на обычного юзера в расчёте на то, что 1) атакующему неизвестен логин, 2) юзер без рутовых прав не так опасен.Понятно что оба прероложения обходятся уязвимостями. В частности вот этой из новости.
В любом случае, угадать логин и пароль значительно сложнее чем перебрать логины а потом пароли к найденному логину. (да не услышат меня писатели ентерпрайзных полиси и да не заэнфорсят ограничения на простоту логинов)
Дальше удовлетворятся этим знанием и распилял бабла)
Рубежи обороны"... а еще они узнали что в системе Х есть юзер с тем же именем что и в системе У, и попробовав пароль из системы У, смогли войти в систему Х"
А ещё, зная пароль пользователя в системе Y, можно сразу попытаться войти в систему X с именем пользователя и паролем из системы Y. Вне зависимости от того, точно известно, что в системе X есть такой пользователь, или только предполагается.
Что лучше - подбирать по словарю существующего пользователя, или вероятно не существующего?
дальше пробуются пароли для аналогичного ника, утекшие через какой-нибудь форум.
> ssh
> паролиССЗБ.
У всех у кого не рвота вместо мозга - либо ключи, либо сертификаты с своим PKI.
почти никто не отклчючает аутентификацию по паролю, разместив свой ключ на машине. это раз. два - по моим представлениям( субъективным ощущениям ) людей живущих исключительно на паролях - в районе половины. тобишь как не крути...
Для того чтобы отключить что-нибудь ненужное, надо сначала включить это ненужное. Зачем устанавливать юзеру пароль, если можно сразу поставить публичный ключ?
Тоже есть обратная сторона. Ключ так же можно угнать. А на 100 серверов 100 ключей запароленных держать - это мало кто возьмётся.
ты похоже не пользуешься ключами( не понимаешь как они работают ).
А как они работают?
> А как они работают?Они лежат на диске клиентского компа и поэтому могут оказаться недоступны в критический момент если этот комп внезапно и случайно сдох. И ты остаёшься без связи со своим сервером, к которому мог бы подключиться по SSH с любого утюга, если бы не запретил логины по паролю. Примерно как-то так они работают.
Ох, малыш. Про то, что можно иметь несколько ключей в разных местах хранящихся ты не слышал, да?
У меня вот уже больше 10 лет на всех серверах запрещен ssh по паролю и ни разу не было проблемы с тем, что я не могу зайти.
а мой старый ноут как раз 11 лет проработал и сдох HDD. а флешку с ключами запасными постирал случайно в ст. машине с неделю назад. пришлось вспоминать детский матерный стишок из 10 строчек, который в лат. раскладке и был у меня паролем. но моя мораль совсем из др. оперы:
ключ Можно Быстро уничтожить вслучае чего. а пароль в любом случае восстановят. с терморекральным то криптоанализом. и не дорого это.
если ты мог подключиться с утюга - значит на нем есть копия приватного ключа, на случай если у тебя сдох комп. вот с него и заходи, с него и восстанавливай приватный ключ.
> с утюга - значитС утюга - значит любого устройства, подключенного к сети и имеющего экран и клавиатуру. Из интернет-кафе, например. Естественно, двухфакторная авторизация была бы уместна, но на совсем крайний случай можно зайти и просто интерактивно и поменять себе пароль на дамп из /dev/random, чтобы обильно протрояненные кейлоггерами компы из кафе не обогатились твоим паролем.
За копию приватного ключа нужно бить по роже. На каждом девайсе должен быть свой ключ чья публичная часть должна быть на сервере.
Всё верно сказал. Я как-то почти наступил на эти грабли и осознав последствия хожу по случайному паролю из 20 символов.
Ключ удобен если скрипту надо лазить на другой хост периодически.
А то что брут форсу теперь легче логин подобрать.
Шаг 1. Проверяем наличие Лузера по имени
Шаг 2. Брутфорсим парольчик
Шаг 3. ...
Шаг 4. ПрофитДа да... количество всяких там уников с 2048+ ключами можно в 8-битный int записать. Все остальные пользуют пароли, дай бог не просто одно словарное слово по дефолту (тут должна быть ссылка к адинам на работе которые на root ставят слово из словаря, но ее не будет ибо жало если кто-то за 3 дня подберёт единый пароль от систем за $12м ).
Чото странное в новости, у меня все новые sshd всегда ругаются на too many даже при наличии пользователя
У вас просто версия выпущенная до 2011 года.
Ну так весь фикс в том, чтобы система обрубала соединение при множестве ошибках аутентификации при любом раскладе, есть такой пользователь или нет.
Спасибо за толковый совет!
Извиняюсь за оффтоп, но может быть кто-нибудь знает, можно ли на манке настроить возможность подключения по ссш когда пользователь не залогинен графически?
Можно. Я настроил.
Я уже разогреваю masscan и hydra, лаовай.
Хорошо у всех машин на облачном хостинге есть пользователь root с паролем из 32 символов.
Дальше что?
Есть пользователь root с passwd -l. и PermitRootLogin no. И еще по 30-50 пользователей с такими же параметрами. Удачи в переборе.
Не люблю когда меня определяют. Я сам решаю, определяться или нет, а вот когда майор влезает и начинает чего-то определять за меня, шпионством заниматься, то это такое...
> Я сам решаю, определяться или нет, а вот когда майор влезает и начинает чего-то определять за меняНу ты хватил. Ещё товарища генерал-майора бы вписал. В современном мире это задача уровня не выше ефрейтора.
На всякий случай: очень, очень мало существует ПО, которое аналогично SSH реально пытается противодействовать атакам на определение факта существования пользователя (то есть не просто возвращают одинаковое «access denied», а нивелируют как минимум тайминг-атаки). Так что если это считать реальной уязвимостью, то что тогда делать с 99% других сервисов, позволяющих получить аналогичную информацию ровно такими же методами?
Это считается просто раскрытием информации но никак не критической уязвимостью. В oss-security уже обсосали. Весь шум подняли параноики не разобравшись в вопросе. В том же Apache таких дырок по 30 штук в год находят и всем (ну почти) нет до них дела.
> Это считается просто раскрытием информации но никак не критической уязвимостью. В oss-security
> уже обсосали. Весь шум подняли параноики не разобравшись в вопросе. В
> том же Apache таких дырок по 30 штук в год находят
> и всем (ну почти) нет до них дела.Истинно так.
Специально для параноиков:
Crazy workaround - создать пару десятков тысяч пользователей с disabled login.
Ну и классику в виде изменения id 0 на foobar/toor/doom. никто не отменял.
> Crazy workaround - создать пару десятков тысяч пользователей с disabled login.Это вы имеете виду установить shell для юзера в /sbin/noligin ???
> Ну и классику в виде изменения id 0 на foobar/toor/doom. никто не отменял.
А вот это как реализовать подскажите пожалуйста?
для параноиков не катит - они будут бояться, что какой-то из этих тысяч пользователей сможет залогиниться, несмотря на запрет
У докеристов кровь из глаз не пошла? :)
Уязвимость конечно нужно исправлять.
Но и Fail2Ban уже "изобрели"
> Fail2Ban уже "изобрели"Не в опенврт, например.
Самое обидное что в CentOS до сих пор не бекпортировали исправления из версии 7.8, для предыдущей уязвимости. Хотя о чем это я в Fedora 7.8 есче пока в тестовом репозитории.
>в CentOS до сих пор не бекпортировали исправления изТы хотел сказать, обидно, что редхет не выпустил следующий пойнт-релиз рхела, не подождал недкльку-другую, и выложил src.rpm так необходимого тебе openssh в wault.как его там, а центов не подпереразнапрягся, ежё через недулю-другую!, и и не пересобрал твой насущный патчонный .rpm ???
Обидно, да. Не то слово, прям, как обидно.
Причем тут новый релиз к накладыванию патчей? Если бы я сказал про новые фичи да тут бы был уместен ваш сарказм, и т.д.
И опять же когда intel выпустил новый микрокод RHEL быстро выкатил обновленное ядро, вас это не смущает? А когда была найдена уязвимость в openssh и разрабы выпустили свежую версию с исправлением, RHEL должен по вашей логике сидеть и ждать с моря погоды, вот про новые фичи и т.д я согласен их надо проверить обкатать а уже потом выкатывать в стабильную ветку.
> Причем тут новый релиз к накладыванию патчей? Если бы я сказал про
> новые фичи да тут бы был уместен ваш сарказм, и т.д.
> И опять же когда intel выпустил новый микрокод RHEL быстро выкатил обновленное
> ядро, вас это не смущает?Ты ж про центос там выше "скучал"? Мне казалось, что они из исходников всё пересобирают, а рхел исходники не сразу даёт. Я о них "плохо подумал"?
> openssh и разрабы выпустили свежую версию с исправлением, RHEL должен по
> вашей логике сидеть и ждать с моря погоды,Не rhel. а cantos твой. Так именно и делает, нет?
> фичи и т.д я согласен их надо проверить обкатать а уже
> потом выкатывать в стабильную ветку.Федору не приплетай. Сказал "центос" -- полезай в кузовок.
> Ты ж про центос там выше "скучал"? Мне казалось, что они из исходников всё пересобирают, а рхел исходники не сразу даёт. Я о них "плохо подумал"?Совершенно верно про CentOS, и да из исходников, и да не сразу.
> Не rhel. а cantos твой. Так именно и делает, нет?
CentOS реально ожидает когда RHEL выпустит сорци, я это и не отрицаю. Вот привожу вашу цитату
> Ты хотел сказать, обидно, что редхет не выпустил следующий пойнт-релиз рхела, не подождал недкльку-другую, и выложил src.rpm
на основании которой и говорю что по вашей логике RHEL должен сидеть ждать с моря погоды а не выкатывать пусть и сначала для себя обновленный пакет с исправлением уязвимости. А CentOS этот пакет достанется дня через 3-4 + пусть 2-3 дня они его будут пересобирать и в общей сложности продет 6-7 дней. Да признаю я поспешил орать на перекрёстке ибо прошло всего лишь 5-6 дней.
> Федору не приплетай. Сказал "центос" -- полезай в кузовок.
А я и не отрицаю что я сказал CentOS. Внесу ясность почему я упомянул Fedora. Как известно очередная ветка RHEL базируется на релизе Fedora, и как следствие Fedora является в какой то степени "тестовым полигоном" для RHEL, хоть уже давно и стал самостоятельным и довольно таки стабильным дистрибутивом который некоторые используют для серверов, и довольно таки часто для десктопов. По моей логике RedHat для начала проверяет те или иные фичи на сообществе а потом уже пихает их корпоративным клиентам. (Всё выше сказанное мной это сугубо моё ИМХО и я его некому не навязываю, и да вполне возможно я не прав.)
Что плохого в подключении по паролю к root с 60-значным паролем? Например 82wH7BSVF5oEhVF8c9RvN7Gll2ycFZIorygBsmoSIfYclPTSLHqwmGoq8tPC
Это намного хуже подключения по ключу?
да
Так что плохого-то? Кто сможет перебрать длюннющий пароль, тем более при включенном fail2ban?
Его не нужно перебирать, если у тебя на лэптопе завёлся кейлоггер или еще какая гадость. Конечно троян и ключ может увести, но поменять/ревокнуть ключ на 1000 серверов много проще, чем тоже самое с паролем (они же уникальные должны быть)
>Конечно троян и ключ может увестиС железного ключа (например, Yubikey) - не сможет.
Воспользовался уязвимостью в OpenSSH и с уверенностью могу сказать пользователи существуют ;)
>пользователи существуют
> ;)Тс-с-с! Не пали главную Уязвимость.