Comments 26
На mac OS найдена огромная уязвимость! Оказывается в систему можно войти без пароля! Вы ждете пока жертва залогинится и выйдет в туалет, потом садитесь с рабочий стол жертвы и о ужас! ОС не понимает чюжеродного вмешательства и не спрашивает у вас пароль!
И… Закрытие этой уязвимости приведёт к падению производительности устройств на 40%!
Надо всего лишь докупить AppleWatch и вы будете защищены от этой уязвимости :)
Если учесть, что подавляющее большинство людей сохраняют параметры подключения по RDP в Диспетчере учетных данных Windows, то критичность данной проблемы надумана чуть более чем полностью.
Тут больше применимо для обхода всяких там двухфакторных методов типа Duo Security.
Вот читаешь, вроде страшно, ибо двухфакторка получается уязвима. Но стоит чуть чуть подумать — двухфакторку используют не для того, что бы оставлять систему не залоченной, когда от нее отходят. Двухфакторка административно обязывает, отрывая задницу от стула, блокировать систему. В итоге опять приходим к тому, что критичность данной проблемы надумана чуть более чем полностью.
Ну… Кейсов есть немного. Например, когда RDP на фулскрин развернут. Ты локнул его и пошел себе. Или у тебя куча рдп к разным сервакам и они автолочатся по идл тайму (хотя странный кейс, лучше по идл обрывать Коннект и закрывать сессию). Ну и вообще, культура лочить комп и двухфакторка, как по мне, не очень коррелирующие события. Даже наоборот, не буду лочить, а то потом долго логиниться.
Win+L — глобальная комбинация и относится к консоли пользователя. В RDP не транслируется.
Культура лочить сеанс появляется не из-за строгости Сбшников, а из-за привычки коллег шутить, меняя десктопные картинки на с двумя парнями с надписью «Мы поражены твоим расп#здяйством».
Так что кейсов ничтожно мало, а требование физического доступа к оборудованию, плюс время на захват системы там внутри RDP подключения делают эту «атаку» мягко говоря турднореализуемой, и почти наверняка с 100% определением виновного.
Культура лочить сеанс появляется не из-за строгости Сбшников, а из-за привычки коллег шутить, меняя десктопные картинки на с двумя парнями с надписью «Мы поражены твоим расп#здяйством».
Так что кейсов ничтожно мало, а требование физического доступа к оборудованию, плюс время на захват системы там внутри RDP подключения делают эту «атаку» мягко говоря турднореализуемой, и почти наверняка с 100% определением виновного.
Ой да лдно, в любом фильме про хакеров, это покажут.
Пока юзверь растяпа ходит в туалет, злобный хакер вылезет из под натяжного потолка, войдёт на удаленный сервер и скачает все секреты.
И конечно когда юзверь растяпа вернётся, хакер будет прятаться под столом и только чудом спасётся от обнаружения.
Пока юзверь растяпа ходит в туалет, злобный хакер вылезет из под натяжного потолка, войдёт на удаленный сервер и скачает все секреты.
И конечно когда юзверь растяпа вернётся, хакер будет прятаться под столом и только чудом спасётся от обнаружения.
Проще устроиться админом на 15к рублей и брать работы побольше, за всех работать, все коллеги будут на тебя работу скидывать радостно. Так добираешься до нужного сервера и сливаешь инфу. А потом такой, ой, мне тут на 16к работу предложили, все поцаны, я в другую контору. Никто даже не поймет.
Пока юзверь растяпа ходит в туалет, злобный хакер вылезет из под натяжного потолка, войдёт на удаленный сервер и скачает все секреты.
Ну, если уж серьезно говорить, «хакером» — могут быть вполне ваши коллеги по работе.
Очень наивно предполагать что все сотрудники фирмы априори неподкупны только потому что они договор подписали о секретных данных
Именно по этому нельзя давать свои учетки и пароли другим людям, нельзя пускать коллег по одному пропуску в помещение и т.п. Эти правила прридуманы отнюдь не из-за соображений — помучить персонал
Точно? Я не помню что-то такой настройки. Да и откуда сервер должен знать сохранённый это пароль или введённый вручную?
Но вот на стороне клиента сохранение паролей RDP можно (и нужно) отключить через групповую политику. Через доменную, если машина в домене, или локальную, если не в домене (gpedit.msc).
Но вот на стороне клиента сохранение паролей RDP можно (и нужно) отключить через групповую политику. Через доменную, если машина в домене, или локальную, если не в домене (gpedit.msc).
Можно с сервера запретить сохраненный пароль.
В политиках узел сеансов -> безопасность -> всегда запрашивать пароль при подключении -> включить
В политиках узел сеансов -> безопасность -> всегда запрашивать пароль при подключении -> включить
Сервер и не знает — он просто запрашивает пароль в уже открытом RDP-окне. Своим стандартным логоном, не предусматривающим сохранение.
А клиент достаточно умный, чтобы не запрашивать пароль который всё равно не примут.
А клиент достаточно умный, чтобы не запрашивать пароль который всё равно не примут.
Всё больше и больше уязвимостей требуют прав администратора.
Имхо какая-то «детская» проблема. В том смысле, что обнаруживается на раз-два и всё равно не исправлена.
А вот для автоматизации — пригодится ;)
Чаще всего пользователи RDP не имеют никаких прав, кроме открытия одной программы
Sign up to leave a comment.
Способ обойти экран блокировки Windows на сеансах RDP